土曜日の勉強会 [プログラマー現役続行]
今まで、私自身が主催する社内向けの技術書の勉強会は、平日の朝に行うことがほとんどでした。例外としては、かなり前に開催した『Understanding Linux Kernel』の勉強会です。
今は、『Linux Kernel Developement, 3/e』の読書会が終わって『コンピュータの構成と設計』の読書会が続いています。しかし、参加者の拠点が多数になってしまったためと私自身も勤務地が変わったため、今月からは土曜日の午後に開催することにしました。
土曜日の開催は、平日の朝と異なり、参加者は様々な予定があったりして、どうしても参加者が少なくなってしまうという問題を抱えています。しかし、やはり、顔を合わせながらその場で学習していく方が、音声だけでの多拠点からの参加よりはやりやすいであろうということにしました。それと、多拠点を接続するための準備が面倒になったというのもあります。
今は、『Linux Kernel Developement, 3/e』の読書会が終わって『コンピュータの構成と設計』の読書会が続いています。しかし、参加者の拠点が多数になってしまったためと私自身も勤務地が変わったため、今月からは土曜日の午後に開催することにしました。
土曜日の開催は、平日の朝と異なり、参加者は様々な予定があったりして、どうしても参加者が少なくなってしまうという問題を抱えています。しかし、やはり、顔を合わせながらその場で学習していく方が、音声だけでの多拠点からの参加よりはやりやすいであろうということにしました。それと、多拠点を接続するための準備が面倒になったというのもあります。
JavaOne 2007のコラージュ写真 [Java]
長い間使用していなかったので忘れていたのですが、FX Palo Alto Laboratoryが運営していたStainedGlass Collageのサービス停止の案内がきました。ほとんど利用していませんでしたが、作成していたコラージュの写真をダウンロードしました。下のコラージュは、2007年にサンフランシスコで開催されたJavaOneへ参加した時の写真です。
写真の1行目の左から、David Geary氏です。私が大変お世話になった「Graphic Java」の著者です。JavaOneで初めて会い、この後、彼の『Google Web Toolkit Solutions』を翻訳することになります。その右の写真は、JavaOne会場のBookstoreで、『Java Puzzlers』にサインをしているNeal Gafter氏とJoshua Bloch氏です。その右の写真は、左が私であり、右はDavid Holmes氏です。『プログラミング言語Java第3版』の翻訳を通してメールのやり取りは7年ぐらいしていたのですが、この時初めて会いました。一番右の写真は、Neal Gafter氏です。
2行目の左から最初の写真では、左から、私、Joshua Bloch氏、Bill Pugh氏（FindBugsの生みの親）です。右端の写真は、左から、Maurice Naftalin氏（『Java Generics and Collections』の著者）、Joshua Bloch氏、私です。
3行目の左から最初の写真は、JavaOne会場とは全く別の場所でGoogleが主催していてパーティ会場の入り口の写真です。招待制となっていました。このパーティの前に、Google Web Toolkitチームによる技術セミナーがあり、私は、そこで初めてGWTを知りました。パーティ会場には、この写真に写っている人はほとんどいました。次の写真は、左の人の名前は忘れたましたが、その隣りは、David Holmes氏です。その次は、Bill Pugh氏とJoshua Bloch氏です。最後の写真は、Brian Goetz氏とJoshua Bloch氏です。
StainedGlass Collageのサービスは、この頃に始まったサービスであり、JavaOneの後にFX Palo Alto Laboratoryを訪問した際に、説明を受けたのを覚えています。
写真の1行目の左から、David Geary氏です。私が大変お世話になった「Graphic Java」の著者です。JavaOneで初めて会い、この後、彼の『Google Web Toolkit Solutions』を翻訳することになります。その右の写真は、JavaOne会場のBookstoreで、『Java Puzzlers』にサインをしているNeal Gafter氏とJoshua Bloch氏です。その右の写真は、左が私であり、右はDavid Holmes氏です。『プログラミング言語Java第3版』の翻訳を通してメールのやり取りは7年ぐらいしていたのですが、この時初めて会いました。一番右の写真は、Neal Gafter氏です。
2行目の左から最初の写真では、左から、私、Joshua Bloch氏、Bill Pugh氏（FindBugsの生みの親）です。右端の写真は、左から、Maurice Naftalin氏（『Java Generics and Collections』の著者）、Joshua Bloch氏、私です。
3行目の左から最初の写真は、JavaOne会場とは全く別の場所でGoogleが主催していてパーティ会場の入り口の写真です。招待制となっていました。このパーティの前に、Google Web Toolkitチームによる技術セミナーがあり、私は、そこで初めてGWTを知りました。パーティ会場には、この写真に写っている人はほとんどいました。次の写真は、左の人の名前は忘れたましたが、その隣りは、David Holmes氏です。その次は、Bill Pugh氏とJoshua Bloch氏です。最後の写真は、Brian Goetz氏とJoshua Bloch氏です。
StainedGlass Collageのサービスは、この頃に始まったサービスであり、JavaOneの後にFX Palo Alto Laboratoryを訪問した際に、説明を受けたのを覚えています。
コードレビューの視点 012 [コードレビューの視点]
言語固有の命名規約に従う
『Effective Java 第2版』の「項目56 一般に受け入れている命名規約を守る」は、Java言語に関する命名規約が説明されています。昔は、1つの言語だけでプログラミングをすることが多かったです。しかし、2つ以上の言語を使用して開発をすることが普通になってきています。複数の言語間を行ったり来たりする際には、使用している言語で一般に受け入れている命名規約に従うことに注意しなければなりません。
複数言語を使用しなくても、新たな言語を学んでプログラミングする際には、慣れ親しんだ言語の命名規約を一度忘れて、その新たな言語の命名規約を学ぶ必要があります。
コードをレビューしていると、言語固有の規約に従っていないコードに出会ったり、無頓着な開発者に出会ったりします。
「Go Conference 2013 spring」へ参加しました [プログラマー現役続行]
4月13日（土）にオラクル青山センターで開催された「Go Conference 2013 spring」へ参加しました。
https://github.com/GoCon/GoCon/blob/master/2013spring.rst
Go言語の日本で初めてのカンファレンスです。内容については、 @mattn_jpさんのブログを参考にされると良いかと思います。
参加申し込みをした半数近くの人がGo言語でのプログラミング経験は初めてということでした。午後3時までは、ハンズオンということで、3つのグループに分かれてもくもくと各人でプログラミングをしました。最初どのグループに入るべきかちょっと迷いましたが、「C. 上級者向け」に入り、前から少しずつ作成していた「並行に検索を行うgrepプログラム」をもくもくと作成していました。
「A. 初めての人向け」のグループでは「A Tour of Go」を行っているようで、私の隣に座っていた@atottoさんが提供している「A Tour of Go」の日本語版へのアクセスが急上昇していました。
午後3時からは発表者によるプレゼンテーションが行われ、最後の@derekcollisonさんによるApceraのケーススタディは興味深い内容でした。
全体として、ある程度Go言語に関する知識がないと十分に理解するのが難しい部分もあったりしましたが、今後日本でGo言語が広まるきっかけなったのではないでしょうか。次回の開催は、summerかfallでしょうか？
今回の参加者の8割以上がMacBook （AirかPro）でした。日本でも開発者といえばMacBookという時代になっているのを感じました。ちなみに、私は2009年末に購入したVAIO Xを相変わらず使用しています。2010年にから毎月開催しているGo言語の勉強会の参加メンバーも私を除いてMacBookです。
【Go言語に関する書籍】
正誤表：http://takashi-yokoyama.blogspot.jp/2011/12/go.html
正誤表：http://www001.upp.so-net.ne.jp/yshibata
https://github.com/GoCon/GoCon/blob/master/2013spring.rst
Go言語の日本で初めてのカンファレンスです。内容については、 @mattn_jpさんのブログを参考にされると良いかと思います。
参加申し込みをした半数近くの人がGo言語でのプログラミング経験は初めてということでした。午後3時までは、ハンズオンということで、3つのグループに分かれてもくもくと各人でプログラミングをしました。最初どのグループに入るべきかちょっと迷いましたが、「C. 上級者向け」に入り、前から少しずつ作成していた「並行に検索を行うgrepプログラム」をもくもくと作成していました。
「A. 初めての人向け」のグループでは「A Tour of Go」を行っているようで、私の隣に座っていた@atottoさんが提供している「A Tour of Go」の日本語版へのアクセスが急上昇していました。
午後3時からは発表者によるプレゼンテーションが行われ、最後の@derekcollisonさんによるApceraのケーススタディは興味深い内容でした。
全体として、ある程度Go言語に関する知識がないと十分に理解するのが難しい部分もあったりしましたが、今後日本でGo言語が広まるきっかけなったのではないでしょうか。次回の開催は、summerかfallでしょうか？
今回の参加者の8割以上がMacBook （AirかPro）でした。日本でも開発者といえばMacBookという時代になっているのを感じました。ちなみに、私は2009年末に購入したVAIO Xを相変わらず使用しています。2010年にから毎月開催しているGo言語の勉強会の参加メンバーも私を除いてMacBookです。
【Go言語に関する書籍】
- 作者: 古川 昇
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2012/11/21
- メディア: 単行本（ソフトカバー）
Go言語プログラミング入門on Google App Engine
- 作者: 横山 隆司
- 出版社/メーカー: 秀和システム
- 発売日: 2011/12
- メディア: 単行本
- 作者: David Chisnall
- 出版社/メーカー: ピアソン桐原
- 発売日: 2012/10/04
- メディア: 単行本（ソフトカバー）
書籍『テスト駆動開発による組み込みプログラミング』 [本]
テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計
- 作者: James W. Grenning
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/04/24
- メディア: 大型本
英語原著は約2年前に出版された本で、その英語原著を使用した勉強会のメンバーにより、翻訳のレビューが行われた翻訳本です。
ハードウェアを直接制御するような組込システムは、テスト駆動開発は難しいと思われることが多いです。この本では、そのような組込システムにおいてどのようにテスト駆動開発を実現するかが説明されています。
2年前に読んだ時には、公開ＡＰＩヘッダーに関数のプロトタイプを定義するのではなく、（それまで私自身が思い付かなかった）関数へのポインターを宣言することで、その関数のスタブを容易に入れ換えられると説明されている点が新鮮でした。機会があれば、実践してみようと思ったのですが、まだ機会がないです。
ハードウェアを直接制御する組込システムでは、テスト駆動開発は無理だと思っている人は、読んでみてもらうと良いかと思います。テスト駆動開発を導入するためのヒントが得られるのではないかと思います。
Jolt Awards: The Best Books （２） [プログラマー現役続行]
以前紹介した時（「Jolt Awards: The Best Books」）には、細かく読まないで見落としていたのかもしれませんが、改めてよく読むと2012 Jolt Awardは、次の本でした。
なお、Jolt Finalistに選ばれているElemental Design Patternsは、翻訳本がすでに出ています。
Specification by Example: How Successful Teams Deliver the Right Software
- 作者: Gojko Adzic
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2011/06/28
- メディア: ペーパーバック
なお、Jolt Finalistに選ばれているElemental Design Patternsは、翻訳本がすでに出ています。
エレメンタルデザインパターン―パターンの基礎を学び、より有効に活用する
- 作者: ジェイソン・マク スミス
- 出版社/メーカー: ピアソン桐原
- 発売日: 2012/12
- メディア: 単行本
オープン・クローズドの原則（OCP：The Open-Closed Principle） [ライブラリ、フレームワーク、アーキテクチャ設計]
Bertrand Meyerによるオープン・クローズドの原則（OCP：The Open-Closed Principle）は、クラスや関数を設計するだけでなく、アーキテクチャ（システム設計）においても重要な役割を果たします。1997年に出版されたBertrand Meyerの著書Object-Oriented Software Constructionで紹介されています。
私自身の経験から言えば、1996年に発売されたFuji Xerox DocuStation IM200では、当時のデジタル複合機（ＭＦＰ）の基本サービスに加えてペーパーユーザインタフェースと呼ばれるサービスが搭載されていました。この開発においては、様々な工夫を私自身が考え出して組み込みました。特に、サービスを任意に追加できるようにする必要性を強く認識して、以下の2点を実現するように設計しました。
こう説明すると当たり前のことにように思えるかもしれませんが、下手に設計すると、すべてのモジュールを静的にリンクして、たとえば、ユーザが指示をしたコピー操作をどのサービスモジュールが行うのかをシステム側がハードコードするような設計をしないとも限りません。私自身はそのようなシステムを多く見てきました。
IM 200の開発では、製品ではないサービスモジュールを色々と作成して、私も含めて開発者が遊んでいました。私自身は、デジタル時計サービス（操作パネル上にデジタル時計を大きく表示）やメッセージ表示サービス（自分のPC上で動作するMessagingToolから送ったメッセージが操作パネル上に表示される）など作成したりしました。
Fuji Xerox DocuStation IM 200を含むブログ
ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いて（オープン：Open）いて、修正に対して閉じて（クローズド：Closed）いなければならない。大規模なシステムにおいて、ある機能を追加しようとする場合に、既存のモジュール群を多数修正しなければならないのであれば、この原則に反していることになります。もし、追加される機能が小さなものであっても、既存のシステムを多数修正しなければならないとなると、システム設計が誤っているのかもしれません。
オープン・クローズドの原則（OCP：The Open-Closed Principle）
私自身の経験から言えば、1996年に発売されたFuji Xerox DocuStation IM200では、当時のデジタル複合機（ＭＦＰ）の基本サービスに加えてペーパーユーザインタフェースと呼ばれるサービスが搭載されていました。この開発においては、様々な工夫を私自身が考え出して組み込みました。特に、サービスを任意に追加できるようにする必要性を強く認識して、以下の2点を実現するように設計しました。
- 個々のサービスを実装しているモジュールはすべてダイナミックロードされる。
- システムは、個々のサービスがどのような機能を提供するのか一切知らない。
こう説明すると当たり前のことにように思えるかもしれませんが、下手に設計すると、すべてのモジュールを静的にリンクして、たとえば、ユーザが指示をしたコピー操作をどのサービスモジュールが行うのかをシステム側がハードコードするような設計をしないとも限りません。私自身はそのようなシステムを多く見てきました。
IM 200の開発では、製品ではないサービスモジュールを色々と作成して、私も含めて開発者が遊んでいました。私自身は、デジタル時計サービス（操作パネル上にデジタル時計を大きく表示）やメッセージ表示サービス（自分のPC上で動作するMessagingToolから送ったメッセージが操作パネル上に表示される）など作成したりしました。
Fuji Xerox DocuStation IM 200を含むブログ
13冊目の翻訳を始めました [プログラマー現役続行]
「12冊目の翻訳本」で紹介した本が書店に並ぶのは、5月下旬頃だと思います。実際の翻訳作業のほとんどは、1月末で終わっていましたが、その後の最終調整と印刷の関係で遅くなっています。タイトルは、『Objective-C明解プログラミング』（ピアソン桐原）の予定です。
2月と3月は、翻訳は行っていませんでしたし、特に次に何かを翻訳するということもなく過ごしていたのですが、3月末に今までに仕事をしたことがない出版社よりある本の翻訳の打診がありました。内容的に興味深いこともあり、翻訳を受けることにしました。今回もそれなりにページ数があるので、翻訳書が書店に並ぶのは年明けになるのではないかと思います。
2月と3月は、翻訳は行っていませんでしたし、特に次に何かを翻訳するということもなく過ごしていたのですが、3月末に今までに仕事をしたことがない出版社よりある本の翻訳の打診がありました。内容的に興味深いこともあり、翻訳を受けることにしました。今回もそれなりにページ数があるので、翻訳書が書店に並ぶのは年明けになるのではないかと思います。
ビルドやテストも考慮したアーキテクチャ設計 [ライブラリ、フレームワーク、アーキテクチャ設計]
大規模なソフトウェア開発では、ビルドやテストも考慮したアーキテクチャ設計（あるいはシステム設計）が必要です。どのモジュールから順番にビルドして、テストできるかは、プロジェクト全体の開発効率に非常に大きな影響を与えます。
レイヤ構成のアーキテクチャであれば、当然、下位レイヤからビルド/テストを行い、それが上手く行けばその上のレイヤをビルド/テストするという順番で行うことが可能となります。
一方で、上手く出来上がった時には、確かに全体として機能するはずであるけれど、ビルドやテストが非常に面倒なシステム設計も可能です。このような設計では、ビッグバンインテグレーションが行われることがあったりします。そして、ちょっとした仕様変更でも多くの工数を必要としたりします。
アーキテクチャの検討において、ビルドやテストも考慮した議論が行われずに、単純に「機能が実現できるかできないか」という視点に陥る場合があります。ソフトウェアはどのような作り方をしても、工数さえ問わなければ、機能を何とか実現できます。しかし、実際の開発では、様々な要因が開発工数と品質に影響を与えます。下手すると、機能追加が非常に面倒なシステムが出来上がるかもしれません。
ソフトウェア開発では、ビルドやテストが困難なアーキテクチャ設計（システム設計）は、何かが間違っているのではないかとか、同じ機能を提供するもっと良い設計はないのかと考えてみる必要があります。
レイヤ構成のアーキテクチャであれば、当然、下位レイヤからビルド/テストを行い、それが上手く行けばその上のレイヤをビルド/テストするという順番で行うことが可能となります。
一方で、上手く出来上がった時には、確かに全体として機能するはずであるけれど、ビルドやテストが非常に面倒なシステム設計も可能です。このような設計では、ビッグバンインテグレーションが行われることがあったりします。そして、ちょっとした仕様変更でも多くの工数を必要としたりします。
アーキテクチャの検討において、ビルドやテストも考慮した議論が行われずに、単純に「機能が実現できるかできないか」という視点に陥る場合があります。ソフトウェアはどのような作り方をしても、工数さえ問わなければ、機能を何とか実現できます。しかし、実際の開発では、様々な要因が開発工数と品質に影響を与えます。下手すると、機能追加が非常に面倒なシステムが出来上がるかもしれません。
ソフトウェア開発では、ビルドやテストが困難なアーキテクチャ設計（システム設計）は、何かが間違っているのではないかとか、同じ機能を提供するもっと良い設計はないのかと考えてみる必要があります。
書籍『APIs: A Strategy Guide』 [本]
- 出版社/メーカー: O'Reilly Media
- 発売日: 2011/12/19
- メディア: Kindle版
一昨年出版されている本ですが、Kindle版で通勤電車の中で読みました。下記の目次から分かるように、Web APIを提供する上で検討すべき項目がガイドとして上手くまとめてあります。
Chapter 1. The API Opportunity
Chapter 2. APIs as a Buisness Strategy
Chapter 3. Understanding the API Value Chain
Chpater 4. Crafting Your API Product Strategy
Chapter 5. Key Design Principles for APIs
Chapter 6. API Security and User Management
Chapter 7. Legal Considerations for Your API Strategy
Chapter 8. Operating and Managing an API
Chapter 9. Measuring the Success of Your API
Chapter 10. Engaging Developers to Drive Adotpion
Chapter 11. Epilogue: Just the Beginning
著書（PDF）
翻訳本（Kindle版）
翻訳本（PDF）
