変な日本語 in the Web: Cloudfuji
日本の雑誌などで英語／フランス語などを使ったアルファベットの名前が氾濫しているように、アメリカでも日本語が唐突に使われている事はよくあります。たまにおバカな入れ墨、とか meme 画像で見たことがあるんではないでしょうか。 英語圏のインターネットはその始まりから、日本語を使ってきました。Yahoo の最初のサーバー群は日本の相撲取りから名付けられました。zen とか ninja などはもう完全に英語に定着したと言えるでしょう。求人情報で『急募: JavaScript 忍者』とかは普通にあります。今よく考えてみたら、おかしな話ですね。 というわけで、変な日本語シリーズを初めてみたいと思います。記念すべき第一回は Ruby on Rails アプリのクラウドデプロイ/マーケットプレイスを目指す cloudfuji.com。あんまり情報が web に載ってませんが、価格のページを見る感じだと購読
ORMがアンチパターンである11の理由
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益
スタートアップをグーグルメソッドで始めてはならない
スタートアップのビジネスモデルについて「グーグルメソッドで考えるのはやめよう」と呼びかける記事がスタートアップ向けブログメディア The Startup Foundryに掲載されていました。グーグルメソッドとはつまり、「今はまだ利益があがっていないけど、ユーザーが10万人に達しさえすれば広告で採算がとれるようになるはずだ！」という考え方。 Googleのビジネスモデルについては既にご存知の方も多いと思いますが、同ブログによれば、 Googleは実質的には、マーケットに入り込むために検索を利用している広告の会社である 無料のサービスで注目を集め、実際の製品である広告をより効果的なものにしている といった点で、Googleは多くのスタートアップとは異なるゲームをプレイしている、としています。 一方で、スタートアップ（特に自己資金によるブートストラップ・スタートアップ）は生き延びるためにキャッシ
ニューヨークがシリコンバレーになれない理由（cc: ブルームバーグ市長）
NYC Mayor Mike Bloomberg and NYC Chief Digital Officer Rachel Sterne. May 16, 2011 (Photo Credit: Spencer T Tucker) Ajay Chainani のブログ @ajayjapan’s blog で以下のような持論を展開します。 New York 市の IT業界ではいろんなことが起こってるよ: たくさんの有望なスタートアップ（foursquare, tumblr, groupme… などなど） 多様な産業（そして技術への投資をしている） 才能が集まっている（一番エキサイティングなところ） お金を持ってる投資家（明らか） 同じ IT業界で働く者として Silicon Valley への賞賛はあるのだけれど、なぜ Silicon Valley の成功モデルを New York 市は繰り
2万5千行のpull requestが話題
プログラマにとって欠かせないコミュニティになったgithubで話題になっているpull requestがありました。話題になっているのは正しい仕事の為の正しいツールという触れ込みのJavaScriptフレームワーク集「EveryJS」のリポジトリでそこに送られて来たプルリクエストの差分の量が驚きの426行追加、24623行削除。不必要にJavaScriptを使って表示を行っている部分をhtmlに変える事で動作の速度を向上させる狙いのようです。 またこのEveryJS.comの日本語の情報が無かったので掲載されているライブラリの全32個のリストも紹介しておきます。このリストもなかなか有用そうですしEveryJS.comをブックマークしてみようと思います。 Backbone.js イベントとKVSを結ぶ構造を提供 Benchmark.js 高解像度タイマ対応のベンチマーク Cappuccino
HackerNewsのアクセスがSlashdotをほぼ凌駕
A-Listersのネタ元としてもお世話になりまくっているHackerNewsですが、古くから知られるギークなコミュニティ、Slashdotにそろそろアクセスが追いつくようです。ネタをウォッチしていてもかつて隆盛を誇ったdiggの過疎っぷりなども感じるので、栄枯盛衰を感じるなぁという一報です。 ところでこのブログのテーマ、A-Listersと一緒ですね。 via:http://markmaunder.com/2011/hn-is-about-to-overtake-slashdot/
5行のコードに7倍の免責事項
OracleのサイトにアップされているHello Wolrdの実装がネタにされていました。Hello Worldですからプログラムは５行しかないのですが、全体像はどうなっているか。（お察しください） 追記:さらに別の指摘がありました
データ＝富の時代
Stephen O’Gradyさんによるデータこそが重要であるという主旨のセッションの資料が話題になっていました。IBM、マイクロソフト、グーグル、FacebookといったIT界のトッププレイヤーの移り変わりを4つの段階に分類しています。曰く。 第一世代(IBM) ハードウェアが富であり、ソフトウェアではない 第二世代(マイクロソフト) ソフトウェアが富である 第三世代(グーグル) 富はソフトウェアの中にはないが、差異を作っている 第四世代(Facebook Twitter) ソフトウェアは差異ですらなく、価値はデータである ソーシャルグラフの重要性などは広く知られていますし、たしかにサービスやソフトウェアの機能の差というのは少なくなって来ている気がしますね。スライドにはグラフなどもあります。 via:http://redmonk.com/sogrady/2011/05/24/the-ag
プログラマはプログラミングをしていないという現実
フロリダのRubyプログラマのSteve Clayさんがブログに投稿した「プログラマーはプログラミングをしている、はずが実際はそうでもない」という記事が話題になっていました。 神話：プログラマは一日中、プログラムを書いている。 現実：多くのプログラマは下記の事に多くの時間を費やしている。（順不同） 外部のプログラマーのMLへのメールやテックでない人へのメールを用心深く書く ミーティングに参加、モックアップやDBスキーマの作成、要求された機能へのパフォーマンスの心配 バグレポートを書く、過去のバグを検索 複雑なシステムの障害の原因を何ギガもあるログを探索して調べる ダウンタイムについてユーザーや上司への説明 他人の問題の解決へ協力 ドキュメント、本、ブログ、リリースノート、脆弱性アナウンスを読む 必要な既存の名前の分からないようなコードを探す 見つかったコードが自分の環境に互換性がありライセ
幸せなGIT
3D Amazon Bitcoin CoderDojo craigslist CSS CSS3 drikin.tv gist git github Google HN HTML5 iPad iPhone JavaScript Linux meetup MongoDB Mozilla New York City Node.js NoSQL PaaS PHP Quora rails redis Ruby WordPress アニメーション イベント オフィス オープンソース ギーク クラウド グーグル ゲーム ザッポス ショッピング スキル スタートアップ セキュリティ ソーシャルメディア デザイン デザインパターン データベース ネタ ハッカソン パフォーマンス フェリシア フロントエンド プログラミング プロフィール ベロニカ ベータ ポッドキャスト ミーム モバイル ヤフー ライフスタイ
データベースの間違った使い方10項目
一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。 それによるとデータベースのアンチパターンは以下の通り。 動的なテーブルの作成 テーブルをキャッシュとして使う テーブルをキューとして使う テーブルをログとして使う 分散したグローバルなロック ストアドプロシージャ 使われない項目 JOIN地獄 ORMによって繰り返されるクエリ 負荷のコントロール どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「
ブラウザ上で動く教育用ビジュアルプログラミング環境 Waterbear
ポートランドで開催されたJSConfにて、ブラウザ上で動く教育用ビジュアルプログラミング環境 Waterbearが発表されました。 Waterbearは、MITメディアラボで開発されているScratchに似たアプローチの言語で、制御構造やユーザーの操作をあらわすブロックを繋ぎ合わせることでプログラミングを行います。ベースがJavaScriptなので、ビジュアルに作成したプログラムから生成されたJavaScriptコードを見ることができるのが特徴です。 開発者のDethe Elza氏が目指しているのは、Alan Kay氏がSqueakで目指したものと同様に、 プログラミングの書籍で使われるようになること プログラミングの初学者がよりプログラミングに没入できる環境となること 普通の人がカジュアルなプログラマーとなれること だということです。 実装としては、jQueryやModernizr、Pr
LAMPは死に、そしてNode.jsとJavaScriptの時代
サンフランシスコのスタートアップ、Metamarkets社CTOのMICHAEL DRISCOLL氏がブログ上で書いた記事が話題になっていました。彼の記事によると、それまでのPythonとDjangoで構成されていたサーバサイドアプリケーションをnode.jsで置き換える決断をしたとの事。その理由は「LAMP構成は誕生から20年が経過し既に死んでいる」という事実を理解したからだそうです。またWEBを以下の3つの時代に分けて説明しています。 1991 – 1999: HTML時代 静的なドキュメントがサーバーから公開されていた時代 2000 – 2009: LAMP時代 様々な言語で構成されたアプリケーションがHTMLのテンプレートとデータベースの値を元に動的なコンテンツを公開。ただしクライアントサイドは静的なまま 2010 – ????: JavaScript時代 サーバーサイドアプリケー
僕はアダム、シングルトン中毒から回復したんだ
プログラミングで使われるデザインパターンの一つにシングルトンというのがあります。ご存知の方も多いと思いますが覚えるととても便利でなんでもかんでもシングルトンにしたくなってしまう設計です。このシングルトンを使った設計の問題を訴えたAdamさんのブログが話題になっていました。 Adamさんによるとシングルトンのダメな所は下記のとおり。 依存関係を見えにくくし、コードが読みづらくなる。 ユニットテストを難しくする。外部から渡せないオブジェクトはモックにする事が難しい。 プログラムの再利用性が低下する。一度しか使わないからとシングルトンで作ってしまうと複数のユーザーから利用されるような場合に対応できなくなる。 スケーラビリティが低下する。 良いオブジェクト指向の設計とは言えない。 異論、反論を受付中ということでコメント欄も盛り上がっています。 食べると太るから食べ物は悪だ、みたいな話だ。 Eric
大企業はソースコードの管理に何を使っている？
Facebookの元CTOだったダスティン・モスコヴィッツが立ち上げた質問サイト、Quoraにて大企業がどんなソースコード管理システムを使っているのか？という質問が挙っていました。Quoraは回答の質が高いという触れ込みでスタートしているサービスなのでこれらの情報は多分正しいのでしょう。 Facebook svn (一部の人はgitも使っている) Amazon perforce Zynga svn Netapp Perforce Google git(Android), Perforce Quora git SAP Perforce ebay Clear Case git(実験中) VMware Perforce この内容の限りだとオープンソースではgit、商用ではPerforceという流れがあるようですね。 via:http://www.quora.com/What-version-co
私がオープンソースに参加しない理由 « A-Listers
Brandon Haysさんのブログ、TEHDAILYFLUXにて投稿されたオープンソースに関する記事が話題になっていました。このブログをご覧になっている方はオープンソースで作られたソフトウェアの利用の経験がある人がほとんどかと思いますが、オープンソースのソフトウェアを開発する側に回った事のある方は少ないのではと思います。この記事ではどうしてオープンソースに参加できないのかについての著者なりの理由が列挙されていました。 認定証も表彰も技能章も無い 何処から始めればいいのかはっきりしない ガイドラインはメンテナーにとっては有益だけど、私にとってはそうではない オープンソースは私のような人よりも優れた人の為のものである 参加しようとすると自分が劣っているように感じてしまう 時間がない 孤独感 ここの理由の背景は元エントリにて述べられていますが、とても正直な感想のように感じます。たしかにオープン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
