栞/#dev
- 2008年7月
C++で書かれた全文検索エンジンのライブラリ。Perl/Python/PHP/Javaなどのバインディングあり。del.icio.usの検索で使われてる。
「毎週木曜日、渋谷TKビル9F ディノセミナールームを19:30〜22:00まで使用」おお。
仕様書/設計書が不要なんてことはないよね。
コーディング規約の話題。不要コードのコメントアウト…まだあるのか。
「tDiaryは当時普及前段階にあったRubyを広めるために、プログラマだけでなくエンドユーザにもアピールするマーケティング戦略をとっており、そのためにはコードに数々の妥協をしている」
「もっと効率的にやるには、最初からやらないことをある程度決めてしまったほうがよいんじゃないか」
OSSを使用できる仮想環境を提供。
- 2008年6月
「コア部分を実装し確定させたら仕様を明記することで、まわりからの理解や貢献なども得やすい状況を作っていくことが、 ユーザさんだけでなく自分達にとってもより良い状況なんじゃないかな」
ミニマルなセットとしてのフレームワーク。機能追加は重要だけど、余分な機能がないのも重要。プラグイン対応で解決するのもありかも。
APIとかフレームワークとかライブラリのユーザビリティについて考察。
「フレームワークがもたらす最大の利点は生産性じゃなくて、保守性にあると考えてます。」「規約ベースは規約が5個を超えるあたりから、正直覚えるのもつらい。あとはしかけが見えにくいのも適切じゃないと思う。」
アーキテクチャとフレームワークの違い。アーキテクチャは枠組み/プロセスそのもの、フレームワークは実際に使うもの。
書きました。
「すごくセンスのある人がいて、ビックリするようなテクニックを使って追いにくいコードを書く人がいます。すごいな〜とは思うけど、できればやめて欲しいですね。」
livedoor PICS、「最初のコメントを書いてみませんか？」のメッセージで「4月にはコメントが3倍、5月には4.5倍に増加」
- 2008年5月
「日本の技術系プレゼンテーション参加者のためのハブサイト」
IT関連の勉強会を集めた公開Google Calendar。
「バグバグなコードは、それだけでメンテに定常的な出費を産む。書き直せばそのコストはいらないのに。バグバグなコードはあらゆる危険性を産む。」「実は怪しいコードは負債である」
トランザクションスクリプトで十分な点に同意。Page/Action + Service + Daoな分け方も自分と同じだなー。
「先に書いておくことのメリットはほとんど無く、想定が外れたときの修正コストやモチベーション低下などのデメリットはばかでかい。」