川口耕介の日記

[book] コーディングを支える技術

「コーディングを支える技術」という本を読みました。著者の西尾さんは、未踏ソフトウェアの関連でお会いしたことがあって、また、ブログにもいつも面白いことが書かれています。

この本も実に西尾さんならでは、という感じです。プログラミング言語そのものにこれだけの興味を持って、色々な言語に関する知識を貪欲に吸収し、そして一冊の本を書いてしまうというのは中々普通の人にはできないと思います。脱帽です。

この本はプログラミングの初級者よりも、多分中級者向けに書かれた本なのでしょう。プログラミングを最初に覚える時は、多分みんな写経（本書のキーワードの一つです）から始めることでしょう。とりあえず決まり事は深く考えずに受け入れて先に進み、知識と知識が繋がって密な知識のネットワークができてからようやっと決まり事の意味を立ち返って理解を深めることができるわけですから。制御構造にしろ型にしろ、プログラミング言語の基本となる概念というのは、ある程度自分で使ってみないとまずは始まらないものです。

そう割りきって、ぜひ西尾さんには初級者向けの説明は割愛して、本は薄くてもいいので内容を濃くした本を書いて欲しかった、と個人的には思うのですが、やはり書籍という媒体だとあんまりニッチすぎる内容はできないのかな...。

さて、この本の帯には、色々な言語を比較するとか、言語に共通の知識を身につけるとか、そういう風に書かれています。でも、僕はそういった視点はこの本の本質を捉えていないように思います。

というのも、仕事でプログラミングをしている人達の間では、言語の選択の自由は限られているでしょうし、言語の技術的な仕様というのはその決定に際しての要素の一つに過ぎないからです。そして、よくできた概念というのはその成り立ちを学ばなくても理解できるものです。ちょうどアラビア数字の記法を覚えるためにローマ数字を覚える必要がないように。

じゃあ、僕に言わせればこの本は断然何が面白いかというと、普段は当然だと思って気にも留めていない事が実は全然当たり前じゃなかったとわかる、という足元に穴が開く感を体験するところです。その点、第七章の名前の話なんかは白眉です。だって変数に名前をつけるとか、みんな当然だと思っているでしょう。

日常を構成するものを分解して再構築するという体験が面白いのは、海外暮らしが面白いのにも共通するところがありますよね。食器をつかってご飯を食べるのは全然当たり前じゃない！とか。

プログラミングに話をもどすと、僕にとって一番「当たり前のことが実は当たり前でなかった」体験は、なんといってもメモリモデルです。僕はアセンブラ→C++と進んだので、僕にとってはメモリというものは０から順番に番号が振ってあって、その番地を使ってMOV AX,[BX+3]などとアクセスするものだったわけです。ハードウェアの仕組みといいCPUの仕組みといい、メモリに番地が振ってあるのは天地開闢以来の当然の決まり事だと思っていました。

ところが、Javaを学んでみると、メモリに番地がある、という決まり事はどこかにいってしまい、それどころか番地を数字として取り扱ったり任意の番地のメモリにアクセスする機能は存在しないわけです。そして、この単純な機能を取り除くことによって、アクセス制御だのバッファオーバーフローの阻止だの、プログラミング環境としてとても優れた幾つかの性質を得ることができます。当時の僕にとってはそれなりの「発見」でした。

大人になってからはこういった「発見」に感動する機会は減りましたが、こういう「発見」を面白いと思う人はぜひ本屋さんでチラ見してみたらいいと思います。

ツイートする

Permalink | コメント(0) | トラックバック(0)

電子立国日本の自叙伝は本当に素晴らしい

fiction

子供の学校の古本市をちらちらみていたら、電子立国日本の自叙伝が全巻セットでたった１＄で売られていたので、買ってきました。

僕はソフトウェアの人なのですが、中学校の頃ちょっとだけ電子工作をやっていたこともあって半導体の話は少しはわかるし、何よりもここに登場する技術者達の生き様があまりに格好良くて、毎晩深夜になるまで読みふけっています。DVD全巻セットも２万円くらいで買えるみたいなので、買おうか悩んでいるところです。プロジェクトXも嫌いではないけれど、ちょっとドラマ仕立てが過ぎることもなくはありません。その点、この本は本当に素晴らしい。

あまりに素晴らしいので、Sunも潰れたことだし、誰かJavaの世界の興亡もこうした本にまとめてくれないかな...と思ったので早速インターネットで探してみたら、

なんと！

ありました！

民明書房刊、タイトルは「Java、その歩み」。著者は不詳で、中古本で第３巻だけをかろうじて入手できました。一部を紹介します。

■第三章 Maven誕生秘話

Mavenの生みの親であるジェイソン・バン・ジルさんをMountain Viewに訪ねた。ジェイソンさんは眼光鋭いカナダ人である。今はMavenの直接の開発からは離れているそうだが、Mavenの事になると鋭い眼光を一層鋭くして語ってくれた。

ーどうしてMavenを作ろうと思ったのですか？

ジェイソン「当時はAnt全盛の時代でしてね。私がその頃コンサルタントとして派遣されていた仕事先でもみんなAntを使ってビルドスクリプトを書いていたんです。これからはMakefileはオワコンだ、ってな調子でね（笑）。ところが、多くの班に別れて作業しているような環境では思ったより効率があがらないように私には思えたんです。」

ー効率があがらない？

ジェイソン「そう。何しろ大きなプログラムを開発していたんでね、そう、300人位はいたかな。だから、両手でも数えきれない位の班が、それぞれの部分を開発していたんです。そうすると、みんながてんでバラバラにビルドスクリプトを書くでしょう。そうすると、同じようなことをしているのにあっという間に全然違うスクリプトができちゃう。

ー１人の人が書くんじゃないですか？

ジェイソン「とても一人じゃ書ききれないですよ、何千行もあるんだし、ビルドスクリプト専属なんてやりたがる人もいなくてね。私も直したことあるけど、良くわからないから適当に誤魔化したりとかね。だから、ビルドスクリプトの部品を共通化してみんなで使ったらいいんじゃないか、って思ったんです。そうすれば、それぞれの班が同じようなことを繰り返さずに済むし、どの班も同じ手順でビルドできたら人を融通しあうのも簡単になるでしょう。だから、最初はそういうところからスタートしたんです。今ではAnt自体にもマクロといって共通部分を部品化する仕組みがありますけどね、私のほうが３年は早かったね。

ー周りの人の反応はどうでしたか？

ジェイソン「最初は私の班と隣りの班のから始めたんです。隣の班の人は私がビルドスクリプトを手伝うといったら鴨がネギしょって来たと思ったみたいでね（笑）、喜んでやらしてくれましたよ。２つの班の共通部分を括り出して行ってね。最初は大変だったけど、２つやったら後はドミノ倒しみたいなもんでうまくいきました。実際にやってみると、うまく部品化するためには班に固有の部分を記述するための方法が必要だとわかってきて、それをPOMと呼ぶことにしました。

ーそれがあの有名なpom.xmlになったんですね

ジェイソン「それはMaven2だからもっと後の話でね。当時はproject.xmlっていう名前だったんですよ。

そういって立ち上がると、ジェイソンさんは引き出しの中を開けてDVDディスクを探し始めた。しばらくして奥のほうから出てきたディスクの中に、当時のプロジェクトが入っていた。

Mavenのところを読んでいたらAntのところも気になったのでちょっとページをめくって見ました。

ーAntは最近は使う人も減ってきているみたいですね

ジェシー「そういう見方もあるとは思います。確かに、antのビルドスクリプトを目にすることは減っていますし、これからもその傾向は続くでしょう。少し寂しい気持ちもないではありません。ですが、目には直接見えないところでantは今もたくさん使われていますよ。例えばGradleというツールをご存知ですか？新しいビルドツールなんですが、これも実際の仕事をしているのはAntですよ。Jenkinsというツールでも使われているし、JSPのコンパイルだってAntを使っているやつがたくさんあるのです。

ー縁の下の力持ちですね

ジェシー「ソフトウェアのビルドにはファイル操作やプロセス操作など、色々OSに依存する処理が必要になります。ですが、Javaは伝統的にそういう処理が嫌いでライブラリを提供していないのです。そのために、AntにはコアのJavaライブラリではできない機能が沢山書かれることになりました。こうしたコードは簡単に置き換えがきかないので、最先端のビルドツールもAntに頼る、というわけなんです。Antを馬鹿にしている人に限って、そういうことに気付いていないんですよ。

ジェシーさんの話しの端々から、彼がAntのことをとても誇りに思っているということが伝わってきた。

ね、面白そうでしょ。全部で何巻あるのか、他の言語のもあるのか、全くわかりませんが、他の巻を書いた人は見つけた人はぜひ教えてください。

（念の為、この本はフィクションで、実在の人物とは何ら関係がありません。）

ツイートする

Permalink | コメント(0) | トラックバック(1)

JenkinsとGerritによるコードレビュー

jenkins, gerrit, book

今月号のWEB+DB PRESSの特集はコードレビューです。（ちなみに、特集３を書いているのはリアルJenkinsさんことikikkoさんです。Cacooは僕の同僚も使っていて「世界で通用する」というのは本当です。）

特に第二章はまるまるGerritというGit向けのコードレビューツールについて書かれています。Gerritは、こちらでも周りで使っている人が多い、ポピュラーなツールです。

この特集ではJenkinsについては一行だけさらっと書かれているだけですが、Gerritを使うならば、Jenkinsを使わない手はありませんね。特にGerrit Trigger pluginを使うと、サブミットされたコードレビューが自動でテストされてそれがレビューに反映されるという仕組みが実現できます。これによって、メインのブランチにマージされるコードがテストに失敗しないということが保証出来ます。

GerritとGitの組み合わせについては、実にタイムリーなことにこないだ日本語の本が出ています。

この本は「入門」と書いてありますが、実際はむしろ入門的な内容は最初の一割で終わり :-)、残りは発展的で高度な内容を取り扱った本になっています。Gerritの他にも、Ruby on Rails、Androidアプリの開発など、特定の状況に向けてプラグインを組み合わせる話などになります。著者の一人、太田さんは前回のJenkins勉強会でこの内容について発表をしてくれました。

Gerrit+Jenkinsの組み合わせはこちらでもポピュラーです。英語ですが、R. Tyler CroyのJUCでの発表ビデオがあります。

ツイートする

Permalink | コメント(0) | トラックバック(1)

Pyrhon Professional Programming

python, book

この本は、Jenkinsコミュニティでいつもお世話になっているさぼてんさんから頂戴した本です。会社はPythonがメインだそうで、ここでの開発方法をまとめたのがこの本、ということみたいです。

Pythonに詳しい人にとっては多分当たり前の事が書いてあるのだと思うのですが、僕自身はあまりPythonでプログラムを書く機会はないので、まさに対象読者層にぴったりです。

なるほど、rvmの代わりにvirtualenvでbundlerの代わりにpipね...という感じで、知っている環境と比べるとスムースに頭に入ります。それにしても、この種のツールの類似性の高さは言語間の垣根を下げるので素晴らしいですね。Javaでも同じような感じのツール群を書いたら面白いんじゃないかと思ってしまいます。いつか暇があったらやるぞ...。

また、Jenkinsの中の人としては、Python開発者がどういう風なツールを使ってどういう風に作業しているかわかるので、「なるほど、こういうツールをサポートすればいいわけね、フムフム」という具合にメモを取りまくりです。これも暇があったらPythonの自動インストーラとかvirtualenvによる環境の自動切り分けとか、ぜひやりたいです。

パッケージの作り方とチーム内での共有の仕方、みたいな話にスペースが割かれているのも大変素晴らしいです。Python入門本というとprintln "Hello world!"とか変数とかみたいな言語仕様の話が多くて、「そんなの仕様書を読めばいいでしょ！」という気になるのですが、この本みたいにウェブ上に散在している部品をどうやって繋ぎ合わせて一人前の環境を作るかというのは、特に他言語からくるプログラマには価値が高いです。

長いこと積んだままでレビューできずにすいませんでした。　

ツイートする

Permalink | コメント(0) | トラックバック(0)

JUnit4実践入門の感想

java, junit, book

JUnit4実践入門を献本してもらったので感想など。

恥ずかしながら、僕はJenkinsでは未だにJUnit3でテストを書いています。JUnit4の新しい機能も一応は知っているつもりでしたが、こうやって系統だってまとめられていると参考になります。思わぬいい勉強をしてしまいました。

目次を見てみるとわかりますが、この本はJUnitの使い方だけではなくて、DbUnitとかAndroidのテストの話とか、MavenやJenkinsでテストをどう使うかという話にも多くの紙面が割かれていて、広範な分野に手を広げている印象です。それでいて、それでもカバーされていない話が色々あります（この点に後で少し触れます）。JUnitというかテストの分野が如何に巨大なエコシステムになっているか、改めて思い知らされます。

こういう風に巨大なフィールドでは、やれHtmlUnitという面白いライブラリがあるよとか、どうやって複雑なデータのマッチングをしたかとか、各論的な話が面白くなってきます。こういう事を議論できるメーリングリストと言うかコミュニティがあるとよいと思うのですが、そういうのはないんでしょうかね。http://junit.org/にもないのがとっても残念なところ。実にもったいない。こういうコミュニティから色々な面白いサブプロジェクトが育っていくのに。

さて、カバーされていない話があるという話をしましたが、その筆頭に挙げたいのがGroovyの話。コラムでちらっと触れられてるだけです。が、僕に言わせれば、JUnitのテストをGroovyで書かないなんてもはやありえないです。なぜなら、

1. production codeじゃないからどんな依存関係を使っても誰にも文句は言われません
2. Javaを使っていない人にもアプローチしやすい文法。throws節の省略とか、テストを書く時にいらない語句を削った身のしまったコードが書ける
3. power assertのおかげでmatcherなんていらない。assertの為の新しい文法を覚える必要はない上に、診断メッセージはより親切。

   Exception thrown
   
   Assertion failed: 
   
   assert 91 == a * b
             |  | | |
             |  10| 9
             |    90
             false
   

4. 複雑なリテラルを書くのが楽。ある値をもったマップやリストを書いたり、オブジェクトのツリーを書いたり。

もう一つ、JUnit4について思うのは、無意味にアノーテーションを使いすぎってところです。例えば、@Testアノーテーション。今までみたいにテストはtestという名前から始まる...でよかったんじゃないでしょうか。その方が短いし、import文を書く必要もないし。@Test(expected=...)みたいに書きたいから一貫性のために、というのはわからなくもないですが。@Beforeと@Afterも同様。基底クラスにメソッドがあってオーバーライドする方式の方が、見つけやすいですよね。JUnit4でテストを書く時、僕は未だに習慣でsetUpとtearDownって名前にするし、この本でもそうするように勧めていますし。せっかく静的型付けがある言語なんだから活用すればいいのに。

Groovyのpower assertの方が優れているHamcrest matcherといい、なんか努力の方向が違っているように思える機能が散見されます。ruleとかいい機能もたくさんあるのですが。

冒頭の話に戻りますが、何でJenkinsで未だにJUnit3を使っているかというと、public abstract class HudsonTestCase extends TestCaseというユーティリティーコード満載のベーステストクラスがあって、これを使って書かれたテストがわんさかとあるからなんですね。このテストを全部JUnit4で書き直すわけにもいかないし。これをルールで書き直すと同じコードが２つできてしまうし。そういうわけで、JUnit3形式のテストの上に新しいruleを足す、とか、HudsonTestCaseみたいなクラスをルールとしてそのまま使えるようにするとか、そういう方向の話がぜひ聞きたいです。こういう悩みをもっている人は多そうです。

JUnitの本の話からJUnit自体の話になってしまったので話を戻します。

Jenkinsの宣伝を日本ですると、結構な数の「でもテストがないんで」という人に出会います。そういう人達にテストを書いてもらうための敷居がこの本でまた一つ下がったかな、と思います。

ツイートする

Permalink | コメント(0) | トラックバック(1)