A-Listers

「飲み会の席などでサービスやアプリのアイデアを出したけど何も作らなかった」なんて経験ありませんか？そんな報われないアイデアが陽の目を浴びる場所を作った人たちがいます。Idea Funnelという使ってみたいアイデアや投資したいアイデアがあれば投票するというサイトが話題になっていました。ここに読者が投稿したアイデアが掲載されるのかはわかりませんが、デザインがポップな感じで印象に残ります。クリック数もそれなりに伸びているようなので今後の展開があるのかないのか。さて。

via:http://www.ideafunnel.co/

サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。

ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない

このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。

• 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
• 確証があり繰り返されている別の解決方法がある。

当初は良さそうに見えたORMがいざ使ってみると問題が明らかになり、しかもその時には切り替えるわけにもいかなくなるというのが彼の主張です。彼による皮肉がたっぷりの論説の最後に付いていたまとめリストは下記のとおり。

• ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
• 効率はどんなプロジェクトでも最初の頃は十分。
• 不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、抽象化は破綻し、開発者はSQLを使わなければならなくなる。
• ORMの抽象化はほぼ100％のプロジェクトで破綻する。
• オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
• 不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
• リレーションを保存する代わりにORMを全てに適用する場合、設計をよく考える必要がある。
• データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。
• データが元々リレーショナルならリレーショナルデータベースに対するオーバーヘッドになるだけ。
• リレーショナルなクエリはモデルレイヤーに隠蔽する。ただしAPIの設計は汎用化の誘惑に打ち勝ってアプリケーションに必要なデータを返すようにする。
• オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。

ORMを使った事がある人にとっては心当たりがありまくりな主張ではないでしょうか。意外と長文なんですが原文を読んでもらう方がORMが良さそうにみえて問題が起こり、そしてその解決方法などのより正確な主張がわかります。また元の記事には現時点で47のコメントが付いており盛り上がっています。
さて、みなさんはORMを次のプロジェクトでも使いますか？

via:http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

関連:
データベースの間違った使い方10項目 « A-Listers
いきあたりばったりのアーキテクチャと教訓 － Publickey

シアトルに住む高校生の少年が自身の企業をActivePerlなどで知られるActiveStateに売却したそうです。話題になっているのはDaniil Kulchenkoさんで彼が起業したのはPerlのPaaSサービスであるPhenonaです。なお買収額は未公表のようです。彼はパートタイムでActiveStateに加わる予定らしく今後要注目のハッカーかもしれませんね。先日のDuoStackの買収もありましたがPaaSに関しては提供できるスタックの種類を揃えるべく早くも統廃合が始まっていますね。

これからPaaSを使うかどうかを考えている我々はどれだけこの少年に遅れをとっているのでしょうか･･･

via:http://www.geekwire.com/2011/seattle-area-15yearold-sells-startup-company-activestate

全世界160万人のベロニカファンのみなさん、こんばんは。今回も恒例の「BestJobEver」からの動画を紹介します。今回美しすぎるギーク、ベロニカが訪れたのは定番モバイルアプリの１つであるEverNoteのオフィスです。おそらくEverNoteを知らないという方は殆どいないと思いますが、その開発の現場というのはあまり話題になっていない所だと思います。

スタッフが増えているという事で広々としたオフィスはパステルカラーで開放的な感じ。映像でもスタッフ同士がオープンにコミュニケーションを取っている様子が伺えます。あと「おーいお茶」らしきペットボトルが散見されるのはたぶん社内の自動販売機か無料冷蔵庫に入っているんじゃないかなと。

Andrew Sinkovさんは会社やEverNoteの概要、自分自身が料理のレシピ収集にEverNoteを活用しているという事例を話してくれます。（その他のスタッフのツイッターアカウントなどの一覧がこのページにありました）

また技術的にはEverNoteは各OSやスマートフォン、開発者向けAPIなど非常に多くのプラットフォーム、言語で開発をしており開発者にとってさまざまな経験が積める職場である事が強調されていました。また逆にいうとクラウド型のプラットフォームのサービスを展開するにはかなりの開発リソースが必要になるんですね。

クラウド型のサービスとクライアントアプリを組み合わせるというスタイルは最近基本の１つになってきたと思いますが、EverNoteの雰囲気やその開発体制などから学べる事が色々ありそうな気がします。公式のブログなどもありますので追ってみるといいかもしれません。ベロニカの様子やオフィスの様子など、動画の方もご覧になってみてください。

via:http://www.youtube.com/watch?v=iA6EBXtDk5c

個人情報がたっぷり詰まったiPhoneにはパスコードをかけていると思いますが、4桁の数字ということでバリエーションが気になります。20万件の調査結果から調べた良く使われているパスコードは下記のとおり。

連番や連続した数字、西暦、アルファベット打ちでのLOVEなどがよく使われているようですね。特にトップの「1234』については全体の15パーセントを占めるということで大変な割合です。
また各桁に使われる数字の頻度を示したヒートマップも掲載されていました。

1桁目に占める1が突出しているのは、「1234」と西暦の影響ですかね。以上を念頭に置いておくと安全な暗証番号を考えるヒントになりそうです。

via:http://amitay.us/blog/files/most_common_iphone_passcodes.php

古参の統計サイト、netcraftが発表したWEBサーバーに関する統計が話題になっていました。ウェブの利用拡大に伴いサーバーの数もやはり順調に増加しているようです。またサーバーに締めるApacheの割合も引き続き増加中のようです。また軽量サーバーのnginxがいつの間にか4番手にまでなっているのも注目するポイントでしょうか。

個人的にはなにかのスライドに使うかもしれない図表としてキープしておきたい感じです。

via:http://news.netcraft.com/archives/2011/06/07/june-2011-web-server-survey.html

週末はやはりリストものという事で、古典的なリストを紹介します。このリストはマイクロソフトでもいくつものプロジェクトを手がけていたDare Obasanjo氏による物です。マイクロソフト繋がりなのかジョエルスポルスキー氏の著作でも見られるような考え方に近いですが、かなり普遍的に当てはまるリストになっています。

• 最初から機能を詰め込みすぎ
• 不確かな技術に依存している
• 稼ぎ頭だったり政治的に強い別な社内プロジェクトと競合している
• 人手が足りない
• 複雑な問題を複雑な方法で解いている
• スケジュールの遅れを報告できない
• スコープが拡大している
• セカンドシステムシンドローム
• プロダクトがエンドユーザーに使われる見込みが無い
• 解決できるかわからない問題がある

このサインを感じ取った所で、実際にエンジニアが打てる対策はあまり無いのが難しいところです。いくつかのサインがあるくらいならまだなんとかなるのでしょうが、大量に当てはまっている状況というのは、、、なんだか身に覚えがあるような・・・。2007年にブログに投稿されたリストですがこのリストも時代を超えて残って行きそうな気配がしますね。

via:http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a76eab63-70f0-48b4-8b75-66c366a651cd