Pyrhon Professional Programming

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

Pythonプロフェッショナルプログラミング

Pythonプロフェッショナルプログラミング

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


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


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


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


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

JUnit4実践入門の感想

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

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

恥ずかしながら、僕は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でテストを書く時、僕は未だに習慣でsetUptearDownって名前にするし、この本でもそうするように勧めていますし。せっかく静的型付けがある言語なんだから活用すればいいのに。


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


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


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


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

Rakuten Technology Award 2012 金賞をもらいました


昨日のRakuten Technology Conference 2012でJenkinsについて楽天テクノロジー・アワードの金賞を頂戴しました。



とても嬉しいのですが、一方でJenkinsはもはや僕個人だけのプロジェクトではないので、何だか他の人の仕事のクレジットの分も僕が頂戴しているようで恐縮です。日本(と世界)のコントリビュータの皆さん、本当にありがとうございました。


日本のJenkins communityは世界の中でも特に稀な結束を誇る素敵な仲間達の集まりです。こういうプロジェクトをやることの楽しみの一つは、みんなと一緒になにかをやる、ということです。どことなく、高校の時の文化祭のような…。なので、今後もどんどん仲間を増やして頑張りたいと思っています。賞状の文面にもありましたが、こういう賞で援護射撃してやるからもっと頑張れよ、と云うことみたいなので。


商品として金色のKoboをもらったので遊んでみます。これってjail breakできるのかな?Javaが走ればJenkins slaveにできるのですが。あとはXFDとして使うとか。



第六回Jenkins勉強会のまとめ

Gerrit Trigger Pluginを使ってJenkinsをコードレビューシステムGerritのレビューアーにしてみよう

今や世界のどこのJenkins meet-up/user conferenceにいっても定番となったJenkins+Gerritの話です。この2つを組み合わせることで、所謂pre-tested commitという、変更を中央のリポジトリに送る前にJenkinsで検査することができます。Eclipseでデモをするというのが僕にとっては新しい部分でしたが、Change IDの自動付与がないみたいで細かいところが通常目にするデモの手順とは違っていて面白かったです。Gerritを使い始めるにはメインのGitリポジトリをGerritの中に移さないといけないので、導入する際にどういう風にチームを説得して…みたいな話を今後更に聞けたらと思いました。

おひとりさまからはじめよう、おひとりさまでもはじめよう。 〜 ある管理部門のJenkins展開への道〜


本日一番人気だったとおもわれる(参考)高野さんの発表。高野さんとは以前からあちこちでお会いしたりお話させていただいたりする機会があって、いつかは発表してください、というラブコールをしていたのがついに叶いました!高野さんが一人でJenkinsを仕事で使い始めて、それがやがて部署の中で重要なシステムになっていく…というそこはかとなく発表がドキュメンタリー風の発表でした。こういう人達のおかげで広まったのね、という印象。


Jenkins User Conference San Franciscoの活動報告・Jenkow pluginの紹介


僕の発表は、Jenkins User Conference San Franciscoでいろいろな人が披露してくれた熱いカスタマイズや独自プラグインの話と、その中から特にJenkowプラグインの紹介をしました。こういうごっついサブシステムをJenkinsに載せてくる突破力の高さというか、大変素敵な感じです。このプラグインを書いているMax Springはバグ報告でもなんでもフィードバックを送ってあげると喜ぶと思うので、よかったらお願いします。

Lightning Talks


田中さんの発表はJavaFXの話NetBeansのプロジェクトをサーバ上でビルドするのが面倒とか、JavaFXをJenkinsが自動インストールするJDKに追加するのが面倒とか、作っている方としては具体的な改善すべき点の指摘をこういう風にしてもらうととても参考になります。



二番手の玉川さんは勉強会の中の人で、いつも裏方で活躍されてますが、今日は発表も。よく使うプラグインを10個位いれたスターターパックを作っているという話に会場の食いつきが。これはそのうち公開されるんでしょうか。ちょうどJenkins PHPをやっているSebastianも「PHPプラグイン」という名前で依存関係としてPHP関連のプラグインを集めたクラスタプラグインを作っているので、こういうのが今後はやるのかも。プラグインの集団を効率良く共有する方法などは今後改善したいと思っています。



三番手岩田さんの発表はパフォーマンステストの自動化です。LTで時間がなかったので「こういう部品を組み合わせてやっています」という概要の話だけでしたが、これはぜひfull-lengthの発表でもっと細かいところも聞きたかった感じです。ついでに、具体的なプロジェクトのひな形とかJenkinsのジョブ設定の情報があれば、それを出発点にしてパフォーマンステストを始めてみる!という人が増えてくれそうな気がします。



トリの今井さんIntelliJの話。どこかでJenkinsの話になるのかなと思っていたら本当に直球でIntelliJの話でした。流石。僕もIntelliJのヘビーユーザーなので、今度JetBrainsからT-shirtかタダのライセンスでもせしめてIntelliJ勉強会とかやったら楽しそう、と思いました。

スタッフ


そしていつもいつも、このイベントを可能にして下さっている運営サイドの皆さん、本当に有難うございます。今回のイベントはNTTデータのJenkins本チームの皆さんとシフトの玉川さんのお陰で無事開催できました。もう佐藤さんには本当に足を向けては寝られないです。

エレベータアルゴリズムの最適化

エレベータに階数表示がないのはなぜかというブログポストを見て、この一歩上をゆく方式がニューヨークで運用されていたのを思い出したので、紹介します。


タイムズ・スクエアのマリオットだったと思いましたが、エレベータホールには、上下ボタンの代わりにテンキーで目的階を入力するキーパッドが付いています。これを押して行きたい階を選ぶと、液晶画面で何号機に乗るのか指示されます。指示されたやつの前で待っていると、やがてドアが開く、という具合です。エレベータ内には階数入力のボタンはついていないので、中に乗ってから目的階を選ぶことはできません。これだと、同じ階で降りる人を同じ箱にまとめて載せることができるので、効率は更に上がりそうですね。


ニューヨークの二箇所のホテルで見たので、結構流行っているのではないかと思われますが、一方でニューヨーク以外では見たことがありません。


追記その後のフィードバックで、ニューヨークだけでなくサンフランシスコなどでも導入されていることがわかりました。東京でももうすぐ!?

追記:そういえば昔Towerという、ビルを建てながら住人やテナントが目指す階に効率良く着けるようにするというゲームがあってよく遊びました。エレベータとかは前に待ち行列が出来て、ストレスが溜まりすぎると怒って帰ってしまうという。これの運行アルゴリズムを俺に設計させろ!と思ったのを思い出しました。

実はもう一回日本に行きます

明日から休暇で留守にするのですが、その休暇が終わると実はもう一度日本に行きます。今度の用事は以下のとおり。


まず、8/22はCEDEC 2012というちょっとawayな環境ですが、Jenkinsで学んだ開発者コミュニティの育て方について講演する予定です。まだセッション一覧には乗っていないみたいなのがちょっと心配ですが、11:20からR301会場で、とシステムには登録されているのでウェブサイトもそのうちアップデートされるはず。Jenkinsの機能とかじゃない話は久しぶりなので楽しみにしています。


次の8/23には豆蔵さんのところで、夜に「豆ナイト」というイベントをやります。JUC TokyoはJenkinsを既に使っている人向けの濃いセッションがてんこ盛りでしたが、こちらはJenkinsの初心者の人向けのイベントです。ちなみに、前回はこんな感じでした。詳細が決まり次第ここに情報がのると思うので、よろしくお願いします。


最後の8/24は、恒例のJenkinsの一日トレーニングをやります。最初のところから複数のジョブの連携みたいな応用の話まで、一日にしては結構濃い内容になっていると思います。僕が講師をやるので、どんな質問でも答えられるので、ぜひ参加してください。

ikikkoさん有り難うございます

Jenkinsでは世界中で色々な人にお世話になってきた。今日はその中の一人、日本のJenkinsコミュニティの大黒柱ikikkoさんの話をしよう。ikikkoさんの事ばかり書くとJenkinsコミュニティの他の人の貢献を過小評価されそうな気もするが、それは別な機会に譲る事にして、今日はikikkoさんの話をしよう。


日本のJenkinsコミュニティは世界でもずば抜けて組織化されている。これが今日あるのはikikkoさんの力によるところが大きい。日本のJenkinsコミュニティを一身に体現する男、それが「リアルJenkinsさん」という愛称の本当の意味だと思っている。決してJenkinsおじさんのようにこき使われているという意味ではありませんよ!


オープンソースプロジェクトというとプログラムを書く人が重視されがちである。でも、実は色々な人が必要なのだ。ikikkoさんが果たしているのはミートアップや勉強会を組織するという活動である。


人間の活動なら何でもそうだと思うが、「これこれこういうソフトウェアを書く」みたいなドライな目標だけよりも、そこに一緒に参加する人達との良い人間関係があると、同じ作業もずっと楽しくなる。オープンソースも全く同じだ。これをコミュニティという。上手く回っているプロジェクトにはコミュニティが必ずある。


Jenkinsではプラグインやアップデートセンターといったようなソフトウェア上の仕組みで開発者のコミュニティを作りやすくして、これが大いに寄与した。勉強会の組織とはユーザーのコミュニティを作るという事で、これに連なるとても大事な仕事だ。


オープンソースのコミュニティ作りで難しいのは、多くの人がボランティアで参加しているという点だ。明確な上下関係もなければ、ゴールさえ一致していない場合も多々ある。それでいて、コミュニティのメンバーの同意をある程度取り付けないといけない。ソフトパワーを駆使して人に働いてもらわなくてはいけないし、何処かで遅滞が生じたらいつでも自分が入って行って解決出来なくてはいけない。このような人間関係は一朝一夕には作れない。だからJenkinsユーザカンファレンスみたいな大きなイベントの開催は、今までの積み重ねの上に成り立っている。今まで5回開催された勉強会があって、その中で得た仲間があって、スポンサーをしてくれる会社があって、その上で初めて可能になったことなのだ。


今回のJenkinsユーザ・カンファレンスには、通常の勉強会の手間に比べて、ずっと手間が掛かっている。部屋ごとに担当者を割り当てたり生放送の手配をしたり、スタッフの食べ物を用意したり、100名規模の懇親会を申し込んだり、スポンサーにお願いをしたり、配布物の管理をしたり、Tシャツやステッカーを作ったり。通常の勉強会では、ikikkoさん自身がこういうタスクを実行するのだが、今回は個々のタスクはスタッフが担当して、ikikkoさんはそれを統括するという管理的な役割をしてくれた。この両方ができちゃうというは素晴らしいことで、ここにikikkoさんの成長を感じた。こういう人を身近に見られるのは大変嬉しい事だ。


ikikkoさんがその手腕を存分に発揮しがいのあるJenkinsという大きな器を作る作業に、僕自身も携わっている事を誇りに思う。やはり職人の道を選んだからにはこうやって尊敬できる人と一緒に仕事がしたい。


ikikkoさんの匠の凄さは外からは分かりにくい。なので、常々この人の素晴らしさを人に伝えなくてはと思っていた。


今日はJenkinsユーザカンファレンスにかこつけて、ようやっとこれを書く事ができた。ikikkoさん本当に有難う。