栞/#dev
画面仕様書重要。ただし小規模ならプロトタイプベースでもOK。
Rubyはプログラマ性善説、Javaはプログラマ性悪説。
こういうのが公開されているとすごくいい。
「JavaとPHPとの選択基準は20人月と聞いた」、大体それぐらいかな。
よく使うインタフェースを全て実装してしまう方法。クラスは大きくなるが、使いやすい。
実装するインタフェースを最小限度にすることで、役割をはっきりさせる。
基本設計重要。
話が進めば進むほどRuby on Railsでそのまま開発したほうが早いと思ってしまう。
CSVのRFCが出ましたよ。いちいち仕様を決めなくてもよくなるかも。
技術／領域の適切なピックアップができることも才能のひとつ。
ソフトウェア開発手法についていろいろと。
XPと設計の関連性について。マーチン・ファウラーによる。
確かに開発者同士の連携はblog経由で行うとうまくいくことが多い気がする。
適切に行われる継承はとても有効だし、委譲をすればよいというものでもない。
geekさんたちが求めているのは、お金ではないしな。
英語のAPIを読みたがらない技術者はどうかと思う。Jakarta Commonsのとか。
IBMのビジネスモデル。
そのままRuby on Railsで行けばいいんじゃないのか…？
一人で座る場所は絶対必要。フリーアドレスでなくてもいいから、こもれる部屋が欲しい。
フレームワーク側であらかじめWeb APIが使える or 使いやすいようになっているといいかも。
「PHP 5 Power Programming」のPDFがあるよ。他にもいろいろ。
結城浩さんのインタビュー。OOに対するアプローチの仕方とか、考えさせられる。
「何となくSE」。営業も勉強してないのが多すぎ。
ストーリーカードの掲示板がいい感じ。ホワイトボードは必須かも。
机がホワイトボードになっているのはいい。
転職は大切。より高度な人材マッチングが必要になる。
発注者側から見たアジャイル開発。コード以外の成果物（アウトプット）をどうしていくかが課題。
RailsとかCatalystを訳のわかっていない大人数で使うとなったらげんなりする。
責任論を言う人は誰かに責任を押し付けたいだけなんじゃないかと。
たしかに、「必ずしも生産的なことをするとは限らない」。でもうまくその逃避を使えればいいよね。