非お奨め本

http://d.hatena.ne.jp/heppokoprogram/20060502#1146568716

憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection)

でも、この本はC言語しかやったことのない人が、C++言語に移行しようとして読む場合には、お勧めできる。他のC++の本を読んで、Better Cなコードしか書けなくなってしまうぐらいなら、この本をまず読んだ方がいい。

こういうことは言いたくはないが，はっきり言ってこの本だけは『絶対に』お薦めしない．なぜか「２ちゃんねる」において絶賛されていたらしいのだが，この本のどこが評価されていたのか全くの謎だ．

特にOOP初心者がこの本を読むと完全に間違った認識を刷り込まれてしまい，その後の学習にも支障が出るなど，悪影響が非常に大きい．これは金と時間の無駄使いにしかならない屑本なので，間違って買ってしまった場合はさっさと廃棄処分にするのが得策だ．廃棄処分にしても失った金は戻ってこないが，少なくともそれ以上時間を無駄にしなくてすむ．

初心者が読むのなら多分こっちの方が無難．

C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス (C++ in‐depth series)

あとはこれかな．

Effective C++ 原著第3版 (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

http://d.hatena.ne.jp/hetappi/20060428/1146248760
まだ買ったばかりで目を通してもいないから，内容に関してはコメントできないが，2版は名著ということで定評があっただけに無駄では無かろう．

入門書リスト：http://d.hatena.ne.jp/JavaBlack/20060224#p2
参考：http://d.hatena.ne.jp/JavaBlack/20050909#p1

巷のC++の入門書は、大抵「クラスとは」とか「継承とは」みたいな入り方ばかりしている。それはまあいいんだけれど、C言語とC++言語の間には、そもそも根本的な発想の違いがあって、(以下略)

初心者が「オブジェクト指向とは何か？」から入るのは，簡単なようで実は間違った方法だと思う．

たとえば素人が救命手当を学ぶ時，はたして心臓や肺の構造，肋骨の本数や形，血液中のヘモグロビン量やそれが保持している酸素量，脳死の判定法，人工呼吸器や電気ショックの使い方などから学ぶだろうか？普通は人工呼吸と心臓マッサージの手順を丸暗記するだけだろう*1．いきなり基本的な医学知識を全て理解しようとしても理解できるわけがない．

小学生が円の面積を求める時，微積分や実数論，イプシロン-デルタ論法*2を学ぶだろうか？円周率を求める公式を導き出し，スーパーコンピューターのベクトルプロセッサに最適化されたプログラムを作成して円周率を求めるだろうか*3？するわけがない．素直に円の公式と円周率≒3.1415などと丸暗記するだけだ．

「オブジェクト指向とは何か？」というのは一番基本的な質問なだけに，実は明確に答えるのは意外に難しいのだ．またたとえ明確に答えたとしても，初心者にはその答が理解できない．理解するための知識が不足しているためだ．*4

GoF

オブジェクト指向における再利用のためのデザインパターン

しかし、とにかく和訳がひどい・・・。説明も分かりやすいとはいえないので、設計していて本当に困った経験のある人じゃないと、この本の内容の素晴らしさは分からない。

これは初心者にもお勧めするが，絶対に理解できない本の一つ．

和訳はこなれていはいないとはいえ，特に問題なかったように思う．あくまで内容が難しいだけで訳が間違っているわけではない．少なくとも文章自体はスラスラと読めた．難しかったのはデザインパターン自体を理解することの方で，これについては一つ一つ実践し，その中で理解していく他ないだろう．

*1:例えばこんな感じ：http://www.jrc.or.jp/safety/kinkyu/index.html

*2:http://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%97%E3%82%B7%E3%83%AD%E3%83%B3-%E3%83%87%E3%83%AB%E3%82%BF%E8%AB%96%E6%B3%95

*3:http://www004.upp.so-net.ne.jp/s_honma/circle/circle4.htm

*4:しかも厄介なことに良い入門書が非常に少ない．中には「憂鬱本」と五十歩百歩の屑本も少なくないのが現状なのだ．

「例のPerlの話」の真相

憂鬱本から辿ってみると，意外や意外．今でもあれが名著だと思いこんでいる人が多いことに驚かされる．

例えばここ．
http://d.hatena.ne.jp/naoya/20050924/1127533305

社会人最初の研修で、(「オブジェクト指向プログラミング」ではなくて)オブジェクト指向開発というのを学んで、なんかユースケースだUMLだ、設計書が最初でコードは最後だとわけのわからない言葉や考え方をいっぱい聞かせられて、うはーと思ってた頃に読んでとてもすっきりしたのを覚えてます。C+ + がベースですが C++ を知らなくても普通に読めると思います。平易な言葉で実践的、そして他にはない内容*1、まさに名著ですね。

なるほど．まさにマッチポンプ．いやマッチとガソリンかな？*2

でまあ、これでウォーターフォールなオブジェクト指向開発について学んでへえと思ったわけですが、実践してみるもなかなか難しく悟りの境地に達したのが例のPerlの話です。(j/k)

そりゃ濡れ衣です。

「（間違った）オブジェクト指向を囓ってその通りにやってみたけど，上手く行かなかった．オブジェクト指向は良くないからPerlの方が良い．」最初に学んだ方法論自体が間違っているから，うまくいかなくて当たり前なんです．

初心者だから仕方ないにしても，言いがかりも甚だしいな．

*1:こんなトンデモ理論は他に類を見ない．他にあってたまるか．

*2:初心者に「UMLだユースケースだウォーターフォールだ」と火を付けて，そこに「憂鬱本」というガソリンを注ぐことで見事にプロジェクトが炎上する．合掌．

構造設計系150人の主張「耐震偽装は他人事ではない」

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000798
メモ．

• 発注側の無理な要求「納期・工期を短縮せよ」
• 発注側の無理な要求「とにかくコストを削れ」
• 「こちらの言うとおりにしないと設計事務所を変える」と言われた。
• 一般的には｢不良材｣と判断されている材料（柱）での建設要求。
• ボーリング調査結果の値を変えてほしいなど、データの改ざんを要求されたことがある。また、試験結果の値が思わしくなかったので、試験をしなかったことにしてほしいなど。

よくわかる．

でも一番共感するのは

• 技術開発（プラント）[26歳：男性]　主な対象：配管設備、機械プラント　年収：200万円台
• エンジニアが見れば偽装はわかる
• 現場を知らない建築士が多すぎる：(中略)机上の勉強だけで資格が取れるので、図面はわかっても、現場がわからない建築士ばかりである。

だったりして．

アメリカのゲーム開発会社の給料、環境は？

http://d.hatena.ne.jp/akaiho/20060503/1146608998

それでは日本と同じようにゲーム開発者も200〜300万前後で残業なんてあたりまえ、「昼飯なら昨日食べましたよ？」なんて会話が普通にされるような環境か？ というと、残念ながら違う。

無茶な進行管理や、世間で言われるところの「デスマーチ」というやつを体験してきた人にはわかることだが、労働時間は連続すればするほど、効率（生産性）は反比例していく。かかりっきりになればなるほど、集中力が落ちていく。ルーチンワーク的な仕事であるなら、考えるよりも体が反応してしまうので起きてさえいればそれなりに意味があるが、ゲーム開発をはじめとしたクリエイティブな仕事というのは考えてなんぼで、「なぜこうなんだろう」「もっとよくできないか」「他に方法はないか」なんてひたっすら考える。一つのトピックについて考える時間が長くなればなるほど、いってみれば脳のクロック数はみるみる落ちていく。それだけならまだ良いが、ミスまで増える。

日本も改善されてきてると信じるけど、果たしてどうなんでしょ。

ゲームの現場は知らんが，望み薄じゃないかな．残業時間ベースの成果主義のせいで悪化している所の方が多いかも．

「内側から見た富士通「成果主義」の崩壊」読書メモ

http://nais.to/~yto/clog/2006-05-04-2.html
メモ．
「技術空洞」の方はないのかな？