栞/#dev
- 2006年1月
個々の仕様／設計に対して理由付けをしっかりしておくこと。
ドキュメントの重要性。CPANのドキュメントは構成がわかりやすい。
あてはまる項目多し。なんとかしよう…。
自分の力が足りないのか、単に仕様がまずいのか見極めることも必要。
確かにJava圏とLL圏って雰囲気違う。ぼくはJavaとPHPの両方をやっているわけですが。
役に立ちそうな資料がたくさん。拾い読みしよう。
この連載、実はRuby on Railsについて書きたいだけなのでは…。
不確定要素のリスクを減らせるのがJavaのいいところ。
「アーキテクトの仕事とは『提案したシステムがいかなるもので、どのような形であるべきかをクライアントとプログラマに示す』こと」。言葉できちんと伝えられることが重要。
マーチン・ファウラー、ライトな開発手法について。
LLできちんとシステム実装ができるなら、その能力は評価されるべき。
技術書は自腹で買うことにしています。
カスタマイズ可能であることを謳った方が人が集まる可能性がある。
開発環境について。Linux環境を利用するために、coLinuxとかVMWareとか。
アーリーアダプターとの関係を大切にすること。
ソフトウェアデザインとプログラマの関係。
「Paul Grahamのエッセイ（原文）と、公開されている日本語訳のリスト」。
「50%」を他人や自分への言い訳にしてはいけない。
テスターとしての視点を身に付けさせた上でプログラミングを習得させる。
取り組む姿勢から見る35歳定年説。年齢は理由にならない。