A-Listers

140字に収まらない海外テックネタヘッドライン

Posts Tagged ‘考え方

ORMがアンチパターンである11の理由

with 4 comments

サンフランシスコのプログラマ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

Written by yandod

2011/06/16 at 19:00

あなたのソフトウェアプロジェクトが破滅する10のサイン

with one comment

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

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

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

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

Written by yandod

2011/06/10 at 18:00

カテゴリー: Uncategorized

Tagged with ,

起業する10の理由と起業しない10の理由

with one comment

おそらく野心のあるプログラマーやクリエイターなら起業を考えた事はあるのではないでしょうか?ソーシャルやゲーム関係に関する話題などを取り上げているVentureBeat上に掲載された「起業する10の理由と起業しない10の理由」が話題に挙っていました。書き手は投資銀行に勤めているMegan Lisa Jones氏です。

さて記事内で紹介されている起業する理由としない理由は以下の通り。

起業する10の理由

  • 基本的な条件を満たしたアイデアがある
    大きく成長している市場で、マネタイズする方法が明らかで、協力するパートナーが居て、長期的なポテンシャルがある。
  • あなたが自身の金銭的、業務的なリスクをコントロールする余裕がある。
  • あなたが不安定で長時間労働ができる。
  • あなたがその市場、製品、サービスに愛情がある。
  • あなたにその業界への情熱がある。
  • あなたが職を必要としている。(かつ職を探すよりも魅力的)
  • あなたが確かなスキルやコネクションを持っている。必要な競合調査などの考えうるリサーチも済んでいる。
  • 信頼できる他人にあなたのアイデアを確認してもらっている。
  • ビジネスの立ち上げが既に趣味の一環になっている。
  • 犠牲を払ってでも、素晴らしい会社を作りたい。

起業しない10の理由

  • 良いアイデアはあるが、十分なリサーチをしていない。
  • みんながそれで儲けているように見える。
  • マーク・ザッカーバーグのようになりたい。それに彼はただの若僧だ。
  • すぐに大金を得たい。
  • 素晴らしい次の時代のキラーアイデアを見つけたから。(何故、誰もやっていないのだろうか?)
  • 職が必要で他にどうしたらいいかわからない。
  • 今実行しなければ、キャリアが行き詰まってしまう。
  • あなたが自分の上司や業界や配偶者を嫌っている。
  • 自由なスケジュールで働きたい。
  • 創業者として名声を得たい。

非常に手厳しいリストですが、Meganさんは「スタートアップは決して簡単ではなく、理由やアドバンテージ、リスクを評価した上で何か優れたものを作りましょう」と締めくくっています。スタートアップを評価する側の人の意見なので冷静ですね。

via:http://venturebeat.com/2011/06/08/10-reasons-to-start-a-company-and-10-not-to/

Written by yandod

2011/06/09 at 20:00

カテゴリー: Uncategorized

Tagged with , ,

ゲーム開発から学ぶコンセプトを共有する4つのポイント

with one comment

Demiurge StudiosでデベロッパをしているEddie Scholtzさんが書いたゲーム開発を始める際の心がけが話題に上がっていました。EddieさんはShoot Many Robots、Borderlands、Rock Band Country Track Pack、Rock Band Metal Track Pack、Godfather 2などの開発に携わったそうです。

そんなEddieさんによると最初に大事なのは下記のポイント。

  • そのゲームが面白そうに見えるかどうかのフィードバックをなるべく早く得る
    大量の開発費をリスキーなアイデアに費やすなら、コンセプトビデオを公開して反応を見てみる。
  • 開発チームに確かなビジョンを伝える
    ドキュメントを読んだだけでは開発者はそれぞれ異なるイメージを抱くかもしれない。
  • 詳細を早く伝える
    100ページもあるドキュメントよりも数分の動画が効果的
  • 説明が難しい機能はイラストを書いて説明してみる
    誰も実現しなかったアイデアは説明しづらい

エントリには実際にヒットしたゲームのコンセプトビデオの実例が示されていました。ゲームという事でやや特殊ではありますが、リッチなアプリケーションのコンセプトを伝えるのには動画を使うというのはいいアイデアかもしれませんね。特にユーザーインターフェースについては言葉や文章でうまく説明できなかったり、スライドではどうもイメージが伝わらないという経験には心当たりがありませんか?この例に学ぶなら動画というのが1つの処方箋になりそうです。

ヒットしたゲームのコンセプトビデオの例

via:http://www.eddiescholtz.com/entry/starting-a-game

Written by yandod

2011/06/08 at 10:30

カテゴリー: Uncategorized

Tagged with ,

良いデベロッパになる為の13のTIPS

with one comment

読みやすいTIPSのリストが話題になるのは洋の東西を問わず見られる現象です。ハンガリーのブタペストのデベロッパ、Csaba Okronaさんが書いた記事が話題になっていました。さっそくその項目を見てみましょう。

  • レッスン1 全体像を理解せよ
    コーディング作業だけに囚われず、ビジネスやプロジェクト等の面からも理解する。
  • レッスン2 自分の時間を確保せよ
    残業や早出は結局バグを招く。スピードは良いデザインと正しいアーキテクチャから生まれる。
  • レッスン3 間違った時は考え方を変えるチャンス
    既存の技術で問題が遅くなってきたような場合は新しい技術へ移行する。ただし既存の技術がうまく行っている場合にただトレンドを追ったりはしない
  • レッスン4 脳を鍛え続けろ
    日々のタスク以外の鍛錬を行え。コードゴルフなどはよい例
  • レッスン5 人生を大事にする
    特に重要。残業が続けば燃え尽きるのも早い。
  • レッスン6 集中
    マルチタスクを避け、1つの事に集中する。
  • レッスン7 自己を貫け
    一度や二度の失敗でくじけずに失敗から学ぶ。ずっとうまく行かないならば別の方法を考える機会(レッスン3)
  • レッスン8 計測せよ
    推測だけで方法を決めずにベンチマークなどをとって判断する。人間の感覚は当てにならない
  • レッスン9 コードのパフォーマンスだけに拘らない
    550ミリ秒を500ミリ秒に短縮してもユーザーには分からない
  • レッスン10 機能を落とす事も考える
    どうしても期日に間に合わない場合は必要性が低い部分を切り落として後に回す事もできる。実際この業界では良くある事だ。
  • レッスン11 コーディングスタンダードを守れ
    たとえチームで開発をしてなくてもコードに一貫性を持たせろ
  • レッスン12 テストせよ
    テストも仕事の一部。テスト用の環境やツールを使えるようにしておく
  • レッスン13 ユーザビリティ
    ユーザーインターフェースを開発する時は常にユーザーの利便性を頭に置く。

Csabaさんの10年の経験の中で感じた経験則だそうですが、とても自然なリストですね。今年現場に入ったような新人のエンジニアにあなたが伝えたいと思う事とかなり共通する部分もあるのでは?遠くハンガリーの地でもこんな事を考えている人(ちなみに漫画好きで仏教徒らしい)が居ると思うのも面白いなと思います。あなたが自分の経験から伝えたい事はなんですか?

via:http://blog.mostof.it/being-a-better-developer/

Written by yandod

2011/06/03 at 20:00

カテゴリー: Uncategorized

Tagged with ,

成功するスタートアップのパターン

leave a comment »

「こんなサービスを運営するスタートアップを企業したら、どうなる?」という脳内起業に日々忙しい皆さんに面白い情報です。先日公開されたStartup Genome Reportが複数の媒体(TechCrunch, GigaOM)で話題になっていました。この記事ではスタートアップについていくつかの視点からみた面白い考察を提示しています。いくつか面白そうな所を抜粋します。

業種別、ステージ別の収益の推移パターン


発見期、確認期、効率期、拡大期の4つのステージでの収益のパターンを業種別に示した図です。たとえば購読モデルの場合、サービスの拡大の時期に大きく収益の成長が望めることになります。

企業の動機の内訳


企業のマインドにはいろいろな性質があるという分析のチャートです。4時間労働ライフスタイルだけバランスが突出しているのが気がかりですが、性質の具体例は下記のような感じ。

  • 自動化推進家(手作業が必要だったものを自動化して提供する)
    Google, Dropbox, Eventbrite, Slideshare, Mint, Pandora, Kickstarter, Hunch, Zynga, Playdom, Modcloth, Box.net, Basecamp, Hipmunk.
  • 社会変革家(一般多数のユーザにリーチし、寡占になりやすい)
    eBay, OkCupid, Skype, Airbnb, Craigslist, Etsy, IMVU, Flickr, LinkedIn, Yelp, Aardvark, Facebook, Twitter, Foursquare, YouTube, Mechanical Turk, MyYearbook, Prosper, PayPal, Quora
  • 構築家(スモールエンタープライズ向けに成功例のあるプロダクトをリビルド等)
    PBworks, Uservoice, Mixpanel, Dimdim, HubSpot, Marketo, Xignite, Zendesk, GetSatisfaction, Flowtown
  • 野心家(エンタープライズでの売上を注視)
    Oracle, Salesforce, MySQL, Red Hat, Jive, Ariba, Rapleaf, Involver, BazaarVoice, Atlassian, BuddyMedia, Palantir, NetSuite, Passkey, WorkDay, Apptio, Zuora, Cloudera, Splunk, SuccessFactor, Yammer, Postini

その他、リポートからピックアップされていた5つのポイント。

  • 変化を恐れない
  • 師匠を探せ
  • 投資家を気にしすぎるな
  • 技術サポートを受けろ
  • ふさわしく計画する

なんというかあまたの星になっていったスタートアップ達の事が考慮されていない気もしますが、夢を描く時に参考にする事ができそうです。また列挙されている具体例ひとつひとつについて調べてみても新たな発見がありそうですね。他にも面白そうなチャートがありますので原文をご覧になってみてください。

同じレポートの記事の和訳記事
http://www.startup-dating.com/2011/05/startup-genome/

via:http://gigaom.com/2011/05/28/startup-genome-map/

Written by yandod

2011/05/30 at 11:13

カテゴリー: Uncategorized

Tagged with ,

データ=富の時代

with one comment

Stephen O’Gradyさんによるデータこそが重要であるという主旨のセッションの資料が話題になっていました。IBM、マイクロソフト、グーグル、FacebookといったIT界のトッププレイヤーの移り変わりを4つの段階に分類しています。曰く。

  • 第一世代(IBM) ハードウェアが富であり、ソフトウェアではない
  • 第二世代(マイクロソフト) ソフトウェアが富である
  • 第三世代(グーグル) 富はソフトウェアの中にはないが、差異を作っている
  • 第四世代(Facebook Twitter) ソフトウェアは差異ですらなく、価値はデータである

ソーシャルグラフの重要性などは広く知られていますし、たしかにサービスやソフトウェアの機能の差というのは少なくなって来ている気がしますね。スライドにはグラフなどもあります。

via:http://redmonk.com/sogrady/2011/05/24/the-age-of-data/

Written by yandod

2011/05/26 at 22:39

カテゴリー: Uncategorized

Tagged with

%d人のブロガーが「いいね」をつけました。