書籍『ドメイン特化言語』

ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目

• 作者: マーチン ファウラー
• 出版社/メーカー: ピアソン桐原
• 発売日: 2012/05/02
• メディア: 単行本（ソフトカバー）

2010年に原著が出た本ですが、翻訳本が出たようです。

プログラミング言語Go関連の書籍 （3）

Go言語（http://golang.org/）のリリースに合わせて執筆された本として以下の3冊が出ています。

Programming in Go: Creating Applications for the 21st Century (Developer's Library)

• 作者: Mark Summerfield
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2012/05/11
• メディア: ペーパーバック

こちらは、kindle版はまだ購入できないようです。ソースコードやサンプル頁は、こちらからダウンロードできます。
http://www.qtrac.eu/gobook.html

The Go Programming Language Phrasebook (Developer's Library)

• 作者: David Chisnall
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2012/05/09
• メディア: ペーパーバック

Kindle版はこちらです:The Go Programming Language Phrasebook (Developer's Library)
サンプルコードやサンプル頁は、こちらからダウンロードできます。
http://www.informit.com/store/product.aspx?isbn=0321817141

この本は、Acknowledgments（謝辞）のページを読んでもらうと分かりますが、すでに私の方でほぼ翻訳が終わっています。しかし、残念ながら出版は未定です。

The Way to Go: A Thorough Introduction to the Go Programming Language

• 作者: Ivo Balbaert
• 出版社/メーカー: iUniverse
• 発売日: 2012/03/08
• メディア: ペーパーバック

Kindle版はありませんが、電子版はこちらで安く購入できます：
http://www.diesel-ebooks.com/item/9781469769165/Balbaert-Ivo-The-Way-to-Go-A-Thorough-Introduction-to-the-Go-Programming-Language/1.html

ハッシュテーブルの季節

一年間のプログラミング言語Java教育を行っていると、「ハッシュテーブルの季節」と私が呼んでいる時期が到来します。どういうことかと言うと、テキストである『プログラミング言語Java第4版』の第3.8節「Objectクラス」（86頁）にhashCodeメソッドの説明があるのですが、その内容に関する質問を解説するために「ハッシュテーブルとは何か」ということから説明しないといけません。特にその節の最後の段落でIdentityHashMapの解説があり、その節になると誰も理解できていないのが毎年の恒例となっています。

そもそも、ハッシュテーブルとハッシュコードを、大学時代あるいは会社に入ってから研修で習っていないのか、習ったけど内容が浅かったのか、習ったけど覚えていないのか、どちらにせよきちんと理解している人は毎年皆無に近いです。

拙著『プログラマ”まだまだ”現役続行』の第6章「コンピュータサイエンスの基礎力」で次のように述べています。

O表記が何であるかを説明できなかったり、ハッシュテーブルがなぜO(1)なのかを説明できないでソフトウェア開発を行っている人が、開発の現場では圧倒的に多いのではと危惧しています。実際、Javaを用いた開発でHashMapクラスを多用していても、その仕組みを全く知らずに開発しており、そのためにhashCodeメソッドを実装する理由を説明できない人ばかりだったりします。

現場の（若手）ソフトウェアエンジニアがハッシュテーブルを全く理解していないという現実に、私が初めて気付いて驚いたのが1998年か1999年頃です。残念ながら今でも状況は同じです。

今年も、1時間費やしてハッシュテーブルを説明しました。

（「ソフトウェア開発組織が持つべきカルチャー 002」）

---

スポンサーリンク

コードレビューの視点 008

エンジニアのレベルが分かる

コードをレビューすることで、コードを書いたエンジニアのレベルがある程度分かってしまいます。たとえば、以下のことが大体分かってしまいます。

• 使用しているプログラミング言語をどれだけきちんと学習しているのか
• コードの読みやすさにどの程度注意を払っているのか
• 必要な基礎知識を持っているのか
• マルチスレッドに関する知識は持っているのか
• etc

これらのことから、実際には本人がどの程度本を読んで学習しているのかとか、サラリーマンエンジニア（「ソフトウェア開発が好きでないサラリーマンエンジニア」）なのかとかもある程度分かってしまいます。

エンジニアのレベルが分かってしまえば、与えた仕事の難易度が本人に適切かも分かることになります（「技術者のレベルとソフトウェア開発の難易度（9）」）。

もちろん、分かると言ってもレビューアーの方がスキルレベルが高い必要があります。

プロセス中心ではなく、スキル中心（4）

ソフトウェア開発は人が行う活動であり、手を動かしてプログラミングするという点では一種の家内手工業です。そのため、従事する人のスキルによって生産性、品質、および、技術的負債というのは大きく左右されます。したがって、本質的には個々のエンジニアのスキルを長期的に向上させることを組織として行っていく必要があります。

しかし、スキル向上は目に見えないし数値として測るのは難しいため、長期的視点に立ったスキル向上のための活動をソフトウェア開発組織としては避けたりする場合があります。代わりに、スキル向上以外の対策を真剣に検討することになります。たとえば、コードの品質を測るために静的解析ツール（カバレッジ測定、複雑度測定、FindBugsなど）だけに頼って品質を向上させようとします。そして、ツールが示す数値が開発プロセス内でのフェーズ移行基準として決められたりします。

本来、それらの指標は、開発者自身が客観的に自分が作成したコードの品質を確認するのを助けるためのツールであり、基準値をクリアーすれば品質が高いことを保証するものではありません。たとえば、コードカバレッジが100%というのはコードの品質を保証するものではありません※。
※ バグがあったり、品質が悪くても、コードカバレッジを100%にすることは可能です。

開発者が自分のコードの品質を確認すると言っても、開発者自身のスキルが高くなければツールが示すコードの状態を正しく解釈できなかったりします。たとえば、FindBugsが警告している内容の本質が分からずに、警告を消すための誤った修正を行ったりすることになります。そして、スキルの低いエンジニアは、コードの品質以前に指標をクリアーすることに注力することになります。

結果として、そのようなツールの導入だけでは、思ったほど品質が上がらなかったりして、結局は「ソフトウェアエンジニアのスキル」問題に戻ってしまいます。毎年、経験の浅い新卒新人の人達がソフトウェア開発組織には入ってくる訳であり、一時的にはツールやプロセスなどでスキル問題を回避しても、また同じ問題に直面することになります。

「プロセス中心ではなく、スキル中心（3）」

11冊目の翻訳本

2000年に『プログラミング言語Java第3版』の翻訳を始めてから、改訂版も含めて10冊の技術書を翻訳したことになります。

http://www001.upp.so-net.ne.jp/yshibata/#BOOKS

今月末までに英語原著が発売になる予定の技術書を、昨年末から3月まで翻訳していたのですが、売れるかどうか不明ということで出版は見送りとなっています。

それで、現在は別の技術書の翻訳を行っています。こちらは、出版することは確定しているのですが、ページ数が600頁弱とかなりの量です。

平日は、仕事をしながらの翻訳作業は長距離走です。毎日、出社前に2、3ページを訳して、週末は多めに訳すことを何ヶ月も続けることになります。