栞/#dev
「キラーアプリを開発するときの費用対効果に優れた少数精鋭式よりも、平均的な成果物での費用対効果に優れ、リソースの追加削除をタイムリーに行えるクラウド的な開発体制の方が向いています。」
「優れた言語やフレームワークはコードの読みやすさをもたらしますが、『読み辛いコードが書かれることを抑制する』ことに関しては無力なのです。」
「『Webを素晴らしいものにする』なんて気持ちは，個人の『ただ楽しく使いたい』という気持ちに比べたら小さいものなのかもしれない．」
「シンプルさ・やりすぎてない感が大事です。あ、これなら自分でも直せるな・何かあっても自分でもやれるな、そういう感覚です。僕個人も案件やるなら、巨大なフレームワークよりそういうのを選ぶことでしょう。」
ImageMagickから派生、OpenMP使う、Flickrで使われてる。
「デバッグよりもはるかに重要なもの、それはデータ構造の選定。」
ソースのコメントを含めてドキュメントにきちんとその実装をしたwhy/理由を残しておくこと。
「オブジェクト指向なんだから、どんな値が OK な値なのかはオブジェクト自身が知っていなきゃいけないんじゃないのかな？」
コンシステント・ハッシュのアルゴリズム。
チケット駆動開発とTracのワークフロー。
Railsアプリを高速化してスケールアップする方法いろいろ。Railsに限らず有効な部分多し。
Base64の仕組み。
「ウェブアプリケーションフレームワークとは、ウェブアプリケーションを書く上で、アプリケーションの本質的なもの以外のことを一手にひきうけてくれるもの、じゃないかな。」
仕様書において否定表現はあいまいな表現。
DBは人手をかけないと劣化するということが理解されてない、同意。
オーライリーが電子書籍を。ただし「このEbookは、印刷、テキストのコピー、ページの抽出、内容の変更を行うことができません。」
「他人がソースコード作る様子を見るのが，よりそいプログラミングです。」上級者の様子を見ること。教育目的によさげ。
携帯サイトの作り方、株式会社セルバによる。
IPv6に対応する方法。fixdapを例に。
「もしあなたが統合のプロトコルをSQLからHTTPに変えたら、それはあなたがデータベースを統合データベース(リンク)からアプリケーション・データベース(リンク)に変えられるということです。」
RDBMSからの脱却とか。流れとしては同意だけど。
コードを書く姿勢として気をつけること。塊を小さく。PHPに限った話じゃないけど。
「プログラムは、結局動いてナンボで、動きの違いが最優先であって、記述の美しさや自分とのポリシーの違いは、目をつぶったほうがいい。」
http://misko.hevery.com/code-reviewers-guide/ の翻訳。
何がしたいのかよくわからない条件分岐は悪。
開発コストをどう考えるか。JavaScriptの場合だと対応ブラウザの話が大きい。
「データバインディングがやりやすいかどうかはリッチなアプリの開発がやりやすいかどうかにジワジワと利いてくる。このため、データバインディングは『地味だが意外と無視できない』代物と言えるのではないか」
「難しいことをいってて損しているフレームワークは結構ある。」
短い単位で計測、チューニングを繰り返すこと。
規模が大きければいいというものでもないということ。少なくとも誇るべきものではないと思う。