栞/#dev
「ビジネスロジック」という言葉を人に説明する場合に。
代表作（＝ポートフォリオ）を持とう！
「技術の人間的価値へつなげてやるという作業」重要。
「客にいわれたことをやっている限り、人月で買い叩かれてしまう」。
「Setter/Getterを作るのがめんどくさい言語仕様に疑問を持つべき」。
結局のところ、発注側の意識が変わらないとどうしようもないかもしれん。
技術文書は普通の文書と書き方が違うよね。
設計／システムノウハウについていろいろと。その他の考察も興味深い。
ひがやすをさんの一日。仕事中に散歩ができるのはいいなあ。
「バージョンごとにジャンプしながら進む」Linuxカーネルの開発姿勢。
リーダー経験と技術向上と、どちらを取るか。悩ましいよね。
2005年技術動向まとめ。いろいろな情報へのポインタ付き。
非常にわかりやすいRAIDの解説。
文理系の区別は無意味でしょ。技術屋として評価されるためにはどうしたらいいか。
問題なのは開発内容もわからない人が受注したりしてしまうこと。
日本語プログラム言語のWeb開発環境。打倒PHPとのこと。
徹夜とか残業が当然と思うようになると危ない。
参考に。何をしたいか明確にすること、設計重要。
ひがやすを氏のblogまとめ。
Webアプリケーションのパターン解説。例がPHP。
まつもとさんによるRubyとagileについてのプレゼン資料。
「作者のDHHのアーキテクトとしての視点と決断がすごいと思う。」
新しいものが評価されない、日本国内しか見ていない。
"使える"言語が増えていること。それに伴うメリットとデメリット。
要求定義／基本設計には必ず間違いがあるし、開発は自動車製造より複雑でパーツ数も多いよ。
発注するユーザ側のシステム開発に対する意識が低いかもしれない。
作業のモジュール化は必要。でも、単純にオフショアに投げることがいいとは思えない。
「ビジネスロジック」に関する定義。はっきりさせておいたほうが誤解が生まれないかも。
「『継承』を使わずに、『決め事』として実装しなければならないメソッドを強制する」。
職人プログラマー／プログラム・デザイナー／UIデザイン・プログラマー。