栞/#dev
ドキュメントの重要性。CPANのドキュメントは構成がわかりやすい。
あてはまる項目多し。なんとかしよう…。
自分の力が足りないのか、単に仕様がまずいのか見極めることも必要。
確かにJava圏とLL圏って雰囲気違う。ぼくはJavaとPHPの両方をやっているわけですが。
役に立ちそうな資料がたくさん。拾い読みしよう。
この連載、実はRuby on Railsについて書きたいだけなのでは…。
不確定要素のリスクを減らせるのがJavaのいいところ。
「アーキテクトの仕事とは『提案したシステムがいかなるもので、どのような形であるべきかをクライアントとプログラマに示す』こと」。言葉できちんと伝えられることが重要。
マーチン・ファウラー、ライトな開発手法について。
LLできちんとシステム実装ができるなら、その能力は評価されるべき。
技術書は自腹で買うことにしています。
カスタマイズ可能であることを謳った方が人が集まる可能性がある。
開発環境について。Linux環境を利用するために、coLinuxとかVMWareとか。
アーリーアダプターとの関係を大切にすること。
ソフトウェアデザインとプログラマの関係。
「Paul Grahamのエッセイ（原文）と、公開されている日本語訳のリスト」。
「50%」を他人や自分への言い訳にしてはいけない。
テスターとしての視点を身に付けさせた上でプログラミングを習得させる。
取り組む姿勢から見る35歳定年説。年齢は理由にならない。
開発用のドキュメントとして必要なもの。作る側として参考に。
「『奢るべきでない場所をちゃんと考えるプログラミング』こそが本来の富豪的プログラミング」
PHPにフレームワークを使うような「真面目な」開発は似合わない。
自分は「火」だと思う。あとちょっと「風」かな。
保守とかバグ潰し作業では重要な技術。
プログラミング能力に必要なこと。言語ができればよいというものでもない。
「『保守担当者もユーザである』という認識があまりにもないんじゃないか」。
コード重要。職人技が使えない言語の方が安全、というのはその通りだと思う。
「埋もれている優秀な人たちが集結するプロジェクトは大企業の中ではなく外にある」
フリーランスという働き方。「フリーランスをうまく使える会社が優位になる」。
プロジェクトのコントロール＝失敗しないようにすること。