読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

伽藍とバザール

読書ノート

もっと中央集権的でアプリオリなアプローチが必要になってくる

よいソフトはすべて開発者の個人的な悩み解決から始まる

なにを書けばいいかわかっているのがよいプログラマ
なにを書き直せば(そして使い回せば)いいかわかっているのが、すごいプログラマ

すごいプログラマの大事な特徴の一つが、建設的な面倒くさがりってヤツ

評価してもらえるのは結果であって、そのための努力じゃないってのがわかっていること。そして白紙から始めるよりは、よくできた部分解からはじめたほうがほぼ絶対に楽。

捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから

まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる

ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。

ぼくは基本的に怠け者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」キツネのようなずるがしこい怠けぶり。

はやめのリリース。ひんぱんなリリース。そして顧客の話をきくこと

リーヌスの革新は、これをやったということじゃない(似たようなことは、もうながいことUnixの世界の伝統になっていた)。それをスケールアップして、開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていったということだった。

リーヌスは、ハッカー/ユーザーたちをたえず刺激して、ごほうびを与え続けたってことだ

ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。

目玉の数さえ十分あれば、どんなバグも深刻ではない

同じくらいの専門家(あるいは同じくらい無知な人たち)の意見の平均は、おすいう観察者の一人をランダムに選んで意見をきくよりも、予測精度がかなり高いことを発見している。これをかれらは「デルファイ効果」と呼んだ

「はやめしょっちゅうのリリース」の効果の一つとして、すでにフィードバック済みのバグフィックスをすばやく広めることでそういう重複をなくせるということがある

小規模なプロジェクトでは…リーダーとなるプログラマを選ぶ以外にはややこしいマネジメント構造は必要ない

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる

自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある

古びてきた機能は迷わず捨てること

「完成」(デザイン上の)とは、付け加えるものが何もなくなったときではなく、むしろ何も取り去るものがなくなったとき。

コードがどんどんよくなって、しかも同時に単純になってきたら、それはもう絶対に自分が正しいのが分かる

ものすごく協力なデザイン上のアイデア、あとから考えると、その結果が当然きわまりなく、自然で、事前に約束されていたようにさえ思えるようなアイデアによって、そういう結果に引き込まれなくてはならないんだと思う。そんなアイデアを狙うには、たくさんアイデアを思いつくしかない。

ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。

世界のために書いているんなら、顧客には耳を傾けなきゃ

自分の言語がチューリング的完成から程遠い場合には、構造上の甘さを許すといろいろ楽になるかもね

見せかけだけの秘密には要注意

最後まで面倒を見られないような開発プロジェクトを始めないように、みんなに微妙な圧力をかける。いまのところ、これはなかなかうまく機能してきたようだ

バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ

それをつぶすのではなくちゃんと育てて報酬を与え…

技術革新の根本問題…というのは、そのアイデアをどうやってつぶさずにおくか、ということだ

おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう

開発者たちが自分のコードを私物化せず、ほかのみんなにバグを探したり改良点を見つけたりするよう奨励するようなところではソフトの改善がほかよりも劇的にはやく生じる

プログラマたちはドキュメント作成が大嫌い

開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい

ネットワーク化されたシヤワセな集団プログラマー/アナキストたち

ぼくたちは、もっといいソフトがつくれることを示しただけじゃない。よろこびが資産であることを証明してもいるんだ

自分の仕事のプロセスにびくびくゲロゲロ状態で関わり合う(…)というのは、それ自体が、そのプロセスの失敗を告げるものだととらえるべきだ

オープンソースの成功のいちばんだいじな栄養の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない