投稿元:
レビューを見る
話そのものの意図するところよりも、その中で紹介されているエピソードがかなりおもしろかった(^^)
印象に残ったところ
P16 「プログラマーは1ではなく0から数字を数える。」あらためて言われて見れば一般の人から見たらおかしいよなぁ(^_^;)
p102 「ヴァンロッサムによればPythonのプログラムはCやむC++と同じタスクを三倍、五倍、あるいは10倍も短いコードで実行できる」
P104 「ヴァンロッサムとウォールが始めてあったのは90年代半ばである」
P105「Pythonのコードは…もろく…インデントは電子メールでは消えてしまうことが多いし、別のOSに…移植すると変わってしまう」
P135「オブジェクティブC」
P140「バッテリー同梱とバイソン信奉者はよく言う。しかし、これほどたくさんのバッテリーがついしていたら、誰が全部を管理できるというのだ」
P156「カーボーイコーダー ルールに逆らい、孤独を好み、一か八かの仕事を選ぶプログラマー」
P197「プログラムを書くより、プログラムを書くのに役に立つプログラムを書きたい」
P205「プログラマーには、ユーザーの立場に立って何が重要かほを想像する資質が備わっているとは限らない…プログラマーがあたりまえだと思っている概念が、ほかの人間にはまったくなじみのない場合もある」
P230「時間が無くて物事が行き詰ることはめったにない。やり方が定義されていないからむ行き詰まるのだ」
P270「2[プログラマーが作業を始めたときにあるものを意味した名前が、無数のバグを修正した後では別のものを意味するようになる」
P271「ハンガリアン記法には、実は二種類あったのだ」
P354「すぐれたプログラマーは、制約があるにもかかわらず成功するのではなく、制約があるからこそ成功するのだ」
P357 Ruby on Rails
P372「ジョエル・スポルスキも言うように、ほとんどのプログラマーは自分たちの専門分野に関する本をあまり読まない。そのため自己の対する無知の無限ループにはまり込むのだ」
P413「コードは書くよりも読むほうが難しい」
P415コメントにモンク
P455「優れたプログラムを開発するには永遠の時間がかかるが、優れたプログラムは同じぐらい長く存続する場合がある」
投稿元:
レビューを見る
開発者ではないですが、ソフトウェアに日々身近に接しているので、あーなるほどという部分も多々あり、なかなかおもしろかったです。大規模なほど困難であり、金はある、人はいる、納期はないという理想的に思えたこのプロジェクトも当たり前と思えるような原因で泥沼にはまっていきます。
プロジェクトのドキュメンタリーと並行して、プログラマーとはどういう人間かとか、「人月の神話」等のソフトウェアプロジェクト管理やソフトウェア工学の話なんかも交えつつで、読み易かったです。
投稿元:
レビューを見る
http://blog.setunai.net/20091025/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AE%E3%82%B8%E3%83%AC%E3%83%B3%E3%83%9E-%E5%A4%A2%E3%81%A8%E7%8F%BE%E5%AE%9F%E3%81%AE%E7%8B%AD%E9%96%93/
投稿元:
レビューを見る
チャンドラーというPIMソフトウェア開発を軸としてソフトウェア開発の難しさや様々なプロジェクトの葛藤を描いています。世界を変えるPIMを目指し、非常に優秀な開発者が開発進めていくうちに、どこにでもありそうな計画の変更、機能の削除への葛藤などに陥っていく状況が非常にリアルでした。
チャンドラーは今OSSで提供されているので、一度使ってみようと思っています。
投稿元:
レビューを見る
去年の夏休みの課題図書をようやく読み終わった。
ソフトウェア・プログラミングが根源的に持つ複雑性と、コンピュータと現実世界のギャップが生む複雑性に真正面から挑んだと言えば聞こえは言いが、「プログラマ以外の一般人にも理解できる」著作を目指したせいか、Chandlerプロジェクトを逸脱した冗長な記述が目立ち、今一つだった。Joel がなんであんなに絶賛していたのか、理解に苦しむ。「闘うプログラマー」と比較されることも多いが、「闘うプログラマー」がひたすらカトラーとそのチームの混迷を描き、物語をもって語らしめていたのに対し、この「プログラマーのジレンマ」は、ちょっと直截的な記述が目立ち過ぎ。そうは言っても、ところどころに示唆に富む記述が見られたため、星3つ。
なお、2001年のプロジェクト開始から迷走を続けた Chandler は、2008年に ver.1.0をリリース、その後も開発は続き、現在の stable version は 1.0.3 だが、必ずしも「活発」なオープンソースプロジェクトとは言い難い状態が続いている。
投稿元:
レビューを見る
ソフトウェア発展の歴史と、あるオープンソースプロジェクトの開発過程を、平行させながら話は進んでいきます。
「期限が迫ったプロジェクトに火を噴きながら突進していく」デスマーチプロジェクトの話はよくみるけれど、「どこに向かうべきかわからず全てが泥沼にはまっていく」的な切なさを感じさせるオープンソースプロジェクトの変遷を追えるのは、なかなか興味深かった。
全体的には「ソフトウェア開発は本質的に火を噴くものだ」というトーンで書かれているので気が滅入る・・・ けれど、同じ業界で働いている人たちにとっては「ここは、俺ならこうしないぞ」と思える発見や洞察に溢れているので、読んでおいて損はないんじゃないかなと思います。
投稿元:
レビューを見る
[○11/01/03完読]プログラマとして大きな感動と共感を得ることができた。論調は熱くもなく冷めてもなく淡々とした感じ。その筋(?)の人には名著だと思うのでそれなりにお勧め。プログラマーだのシリコンバレー(名声、栄枯盛衰)だのの雰囲気を味わえるこの手の本を久々に読んだのだけど、やはりこの辺の米のカルチャーは面白い。この感じに憧れてこの業界に入ったのを思い出した。この数年はOSSから遠ざかっていたので初心に帰るのにもよかった。ソフトウェアに改めて熱意が湧く。チャンドラー開発の進みも悪く、中盤は若干だるいが後半や開発にまつわる種々のうんちくは特に興味深い。う~んそれにしてもワクワクした。
投稿元:
レビューを見る
2011年12冊目。
491頁。
地元の図書館で借りる。
シリコンバレーを舞台に、天才プログラマーのドリームチームが挑んだオープンソース開発プロジェクト「チャンドラー」立ち塞がる難題、時間の壁、去り行く同志―混迷する3年間に密着した長編ノンフィクション。
(Amazon内容紹介)
本書を本当に理解できるのは、きっと僕がプログラマとしての経験を何年か積んだ後になると思う。しかしそれでも、本書を読んでよかったと思う。システム開発の過酷さやプログラマの抱える葛藤に触れることが出来た。それだけで十分だと思う。
≪本文引用≫
p.19
米国標準技術研究所の2002年の調査によると、ソフトウェアプロジェクトの三分の二が大幅に納期に遅れるか予算をオーバーするか、あるいは完全に中止せざるをえなくなり、ソフトウェアの欠陥のためにアメリカ経済は年間約595億ドルを負担している。
p.31
ブルックスは、「人と月を交換可能なものとして扱えるのは、多数の労働者の間でコミュニケーションをとらずに作業を分担できる場合のみである」としている。ソフトウェアのようにプロジェクトごとに性質が異なり、絶えず変化の起きる世界では、チームに要員を加えるたびにベテランが自分の作業を中断して新人の面倒を見なければならず、全員で作業を割り振り直して新人の仕事を作ってやる必要がある。
p.39
「よいプログラマーは、何を書くべきかわかっている。偉大なプログラマーは、何を書き直すべきか(そして再利用すべきか)わかっている」。
p.79
世界を変えたければ、イタリアの急進論者、アントニオ・グラムシの有名な言葉のように「知性の悲観主義、意思の楽観主義」が必要である。現代のソフトウェア開発者は、どういうわけかこの二極的な考え方を受け継いでいる。
p.85
ソフトウェアは抽象的なものであるため、限りなく順応性があるはずだと思われやすい。ところが、ソフトウェアはエーテルのように柔軟でありながら、しぶとく腹立たしいほど扱いにくく、その融通のなさにはいつも驚かされる。
p.167
「昔からこう言うんだ。早く作るか、安く作るか、うまく作るか。どれか2つだけ選ぶことができる、と」
p.206
誰も気の毒なユーザーのためにものを言わない。この問題については申し合わせたように押し黙っている。……ちょっと気をつけてみれば、人びとはこの装置は難しくて使えないと言えずにいることがわかる。自分の方が悪いと思っているのだ。……私の知り合いはみな(私も含めて)、少なくとも週に1度は、この腹立たしい機械を窓から放り捨ててやろうかという衝動に駆られる。……。ソフトウェアが使いにくく、プログラムのデザインが貧弱なことは、この業界の隠れた恥部である。……何をすべきなのか。コンピュータの専門家自身が、すばらしいユーザー体験を生みだすことに責任を負うべきである。概念上、最も重要と思われる措置は、コンピュータという工芸品の創造にあたって、プログラミングと対等なものとしてのデザイ��の重要な役割を認識することである。そして、コンピュータにかかわる職業の最も重要な社会的進化は、ユーザー体験の擁護者としてのソフトウェアデザイナーという役割を作ることであろう。
p.326
ベストプラクティスの処方箋は、2回目には効き目がない。銀の弾丸は、再充填できない。
p.357
「柔軟性が過大評価されている。制約が自由を作るのだ」
p.404
すべての作家が個人の「会社」をもっていて、メルビル会社の人間しか『白鯨』を読めず、ヘミングウェイ会社の人間しか『日はまた昇る』を読めないようなものだ。このような状況で、優れた文学が生まれることが想像できるだろうか。このような条件下では、文学のカリキュラムも組めないし、文章術を教える方法もない。それなのに、これと同じ状況でプログラミングを学ぶことを期待するのか。
投稿元:
レビューを見る
序盤はおもしろかったけど、
発散してまとまりの無いまま終わった感がする。
ソフトウェアの困難な現場の雰囲気を知るにはいいかもしれないけど、
逆に言えば、そういう系の本を読んでいる人にはありきたりな話の一つかも。
投稿元:
レビューを見る
プロジェクトって大変だなと感じる本。
ただ、今後生かせる改善点や発見などが出来る良い本かと。
働いてないから多分としか言えない。
投稿元:
レビューを見る
2003年頃の少し古いかもしれない部分はありますが、昔も今と変わらず、部外者の自分にも分かりやすく書かれています
コードに詳しい方ですと、もっと楽しめるかもしれません
副題と原題がしっくりくる内容ですが解決法が書かれているわけではありません
投稿元:
レビューを見る
ページ数が多く読むのに気合が必要だった。内容は一般の方に、という出だしではあるが理解は難しいと思う、同じような職種、知識を持っていないと難しい。しかし同じような人種にはなかなか面白かった。
投稿元:
レビューを見る
「Javaスクリプト」という表記は初めて見た。
「パイソン」「ルビー」など違和感のあるカタカナ表記をしているところを見ると、一応非プログラマに向けて書かれているようでもあるが、プログラミングの経験のないとなかなか理解できない内容だと思う。
Chandlerというオープンソースソフトウェアの開発に密着取材。物語は淡々としていて内部的にはそれほど劇的なことも起こらない。しかし、良く知られたソフトウェア開発に関する様々な知見を、Chandlerの開発で起こったことや、その最中に業界で起こった大きな出来事に適用して、ソフトウェア開発一般における問題に置き換えようとしている。そういった知識が得られるところが良い。
Chandlerの開発は終了しているよう。