Jenkins勉強会で実にいいプレゼンを見た。

実にいいプレゼンでした。Java言語とかビルドツールとかではない方向から、しかし継続的デリバリーの本質に迫る、しかしほんわかとした、いいプレゼンでした。

20121019-jenkins-akiko_pusu.pdf from akiko_pusu

その他のまとめとか：

• 第6回Jenkins勉強会を開催しました - Linoブログ
• 2012/10/20 第六回Jenkins勉強会 #jenkinsstudy - Togetter

.settingsフォルダや.projectファイルをVCSで管理すべきか

eclipse上のプロジェクトとしてソースコードをむさぼった後、さて、SubversionかGitにコミットする段になったとします。コミットダイアログ上では .settings/foo.bar.xml とか .project とか .classpath といったeclipse用の制御ファイルもコミット対象としてチェックボックスがオンになっています。

あなたは迷わずそのままコミットボタンを押しますか？それとも、その前にignore（無視、除外）の設定にかかりますか？

この問題に対する行動は、案外、人によって違うようです。たとえば、svn - Which eclipse files belong under Version Control - Stack Overflow 2008.12（どのeclipseファイルをバージョン管理の対象とすべきでしょうか？）という質問には、下記の回答のポイントが高いようです。

project-dir/.project
project-dir/.classpath
project-dir/.settings/*

should be in your SCM.
（訳：上記のファイルはバージョン管理下におくべきだ）
The goal is that anyone can checkout/update his/her SCM workspace and import the eclipse project into the eclipse workspace. （訳：誰もが自分のSCMワークスペースにチェックアウトまたは更新できて、eclipseワークスペースにプロジェクトをインポートできる、それがゴールだ）

こんなＱ＆Ａもあります。 java - Should Eclipse-specific files in an VCS be ignored, if using Maven? - Stack Overflow 2011.11 これはビルドツールとしてmavenを使っているプロジェクトの話のようです。

With the team's I've worked on, the general rule has been that you don't check in anything that is generated by or obtained by Maven. Since the pom.xml contains everything you need to create the .project, .classpath, and .settings files, we don't check them in.
訳：私のチームでは、mavenが生成または監視しているファイル以外は（VCSに）チェックインしないのが共通のルールです。.projectや.classpath、.settingsファイル群を作るための情報はpom.xmlに含まれているからです。だから、それらをチェックインすることはありません。

実際、eclipseにm2eプラグインを入れておけば、pom.xmlのdependenciesタグに沿って必要なライブラリを自動的にビルドパスに入れてくれます（＝.classpathファイルが自動的に書かれる）。その他の制御ファイルもそうです。

一方でこんなエントリも見かけました。 a little madness » Blog Archive » Setting Up An Android Project Build

Make sure you don’t forget to check in the hidden Eclipse files .classpath, .project and .settings. By structuring the projects so they live under a single top-level folder, it should be easy to add them to the version control server of your choice.
訳：eclipseの隠しファイルである.classpath, .project, .settingsをチェックインするのを忘れないでください。一つの最上位フォルダの下にプロジェクトを構築すれば、これらのファイルをバージョン管理サーバに追加するのは簡単です。

androidのネイティブアプリを作るプロジェクトで、ビルドツールとしてantを使っているケースのようです。androidの公式サイトでの解説でも、プロジェクト直下にbuild.xmlというantのビルド定義ファイルを作ることになっています。（ただし、eclipseの制御ファイルをどうするかまでは触れられていません）

個人的には、mavenを使っている／いないに関わらず、eclipseの制御ファイルをsvnやgitで管理することには抵抗を覚えます。一人で仕事をしているのならいいのですが、他人と協力して構築してゆくプロジェクトの場合、eclipseのバージョンや環境を横並びにそろえる必要があります。しかし実際はeclipse3.7を使っている人もいればeclipse4.2を使っている人もいるのです。必ずトラブルになるでしょう。

諸君、私はJenkinsが好きだ

諸君 私はJenkinsが好きだ

諸君 私はJenkinsが大好きだ

Email-ext pluginが好きだ
Cobertura pluginが好きだ
Maven repository server pluginが好きだ
HTML Report pluginが好きだ
Gradle pluginが好きだ
Job config history pluginが好きだ
Build pipeline pluginが好きだ

Javaアプリのビルドで
Mavenリポジトリへのdeployで
PHP Unitの実行で
Geronimoへのdeployで
バッチ処理サーバへのscpとsshで

この地上で行われる ありとあらゆるJenkinsのビルドが大好きだ

スレーブを従えたJenkinsの一斉ビルドが
轟音と共にビルドキューを吹き飛ばしていくのが好きだ
空中高く放り上げられたソースコードが
FindBugsでばらばらになった時など心がおどる

Jenkinsの操るビルド手順が
ソースコードツリーを撃破するのが好きだ
悲鳴を上げて燃えさかるリファクタリング済みソースを
JUnitとHTML report pluginが薙ぎ倒した時など
胸がすくような気持ちだった

ルールをそろえたCheckstyleの横隊が
ソースコードを蹂躙するのが好きだ
恐慌状態のプログラマーが シカトぶっこいてたeclipseの
checkstyleプラグインをあわててactiveにしている様など
感動すら覚える

SCMに乱雑にコミットされたソースコードたちを
ビルドジョブビューにつるし上げていく様などはもうたまらない
俺を先にポチってくれと泣き叫ぶビルドジョブ達が
Bulk builder pluginの振り下ろした号令とともに
次々と立ち上がるスレーブにばたばたと薙ぎ倒されるのも最高だ

哀れなプログラマー達が雑多な変更を健気にもコミットしてきたのを
Jenkinsのコミットフックビルドトリガーがchengeset番号と
コミッターのアカウント名ともにBUILD FAILUREで
つき返した時など絶頂すら覚える

後任のビルドエンジニアにJenkinsのビューを
滅茶苦茶にされるのが好きだ
必死に整理したビューが蹂躙され
無関係なビルドが追加されそこにあるはずのビルドジョブが
「すべて」にしか現れなくなる様はとても悲しいものだ

ビルド状況の雨雲の洪水に押しつぶされて殲滅されるのが好きだ
E-mail通知に追い回され 500kbを超えるコンソールログを
血眼で追うのは恥辱の極みだ

諸君 私はJenkinsを 地獄の番人の様なJenkinsを望んでいる
諸君 私に付き従う戦友諸君
君達は一体 何を望んでいる？

更なるJenkinsを望むか？
情け容赦ない 冷酷なJenkinsを望むか？
鉄風雷火の限りを尽くし 三千世界の鴉を殺す 嵐の様な執事 Jenkinsを望むか？

「Jenkins !! Jenkins !! Jenkins !!」

よろしい ならばJenkinsだ

我々は満身の力を込めて今まさにポチらんとする握り拳だ
だがこの暗い闇の底で半世紀もの間耐え続けてきた我々に
ただのビルドではもはや足りない!!

大Jenkinsを!! 一心不乱の大Jenkinsを!!

我らはわずかに一個大隊 千人に満たぬビルドチームにすぎない
だが諸君は一騎当千の古ビルド職人だと私は信仰している
ならば我らは 諸君と私で総力100万と1人の軍集団となる

我々を忘却の彼方へと追いやり 眠りこけている連中を叩き起こそう
デスマーチの葬列から引きずりだし 眼を開けさせ思い出させよう
連中に自動ビルドの味を思い出させてやる
連中にJenkinsのコンソールログの自動スクロールを思い出させてやる

プロジェクトマネージャとプログラマーのはざまには
奴らのWBSでは思いもよらない事があることを思い出させてやる

一千人のビルド職人の集団で世界のソースコードを燃やし尽くしてやる

「最後の大隊 大隊指揮官より全空中艦隊へ」
目標 法政大学 市ヶ谷キャンパス

Jenkinsユーザーカンファレンス 2012 Tokyo 状況を開始せよ

征くぞ　諸君



Inspired By 諸君 私は戦争が好きだ

HELLSING 1 (ヤングキングコミックス)

posted with amazlet at 12.07.27

平野 耕太
少年画報社

Amazon.co.jp で詳細を見る

ソフトウェア開発自動化が目指すべき姿

自動化ツールを使ったプログラミングレスなシステム開発、という流行病（はやりやまい）は数年おきに出現します。10年ほど前で言えばCASEツールがありました。もっと大昔では、シグマ計画（プププ）ではSPACEなるプログラミング自動化システムが最上位ツールの一つとされていたようです。

何らかのツールに一定の形式で要件定義情報を入力すると、アプリケーションのソースコードが完全に自動生成される、というのが、最近（昔から？）よく見かけるソフトウェア開発自動化ツールの見果てぬ夢幻です。本当にそれをやろうとすると、一定形式の要件定義情報を書くこととソースコードを書くこととの複雑さの差があっという間に埋まってしまって自動化ツールの存在が無意味化するだろうということは、きちんとしたプログラミング経験のある人間であれば誰でも本能的に察知できます。

gccやjavacのようなコンパイラがソースコードをマシン語に変換する自動化ツールであるならば、その進化形として、一定の人間語で書かれた文章と図面をソースコードに変換する自動化ツールもあってしかるべきだ、というレトリックもときどき見かけます。残念ながらそれも、中国の古い故事で言うと論理の飛躍です。ソフトウェア開発はそれほど単純なものではありません。

しかし意外にも、そうした銀の弾丸と青い鳥を探し求める傾向を、ITを使う側でではなく、IT業界の内側でちらほら見るので世の中不思議です。ITの使い方を知らないIT業界人も思いのほか存在するのです。

逆に、ITの使い方を心得たうえで自動化ツールをうまく使う企業や個人もいます。と書いてから自分のことを書くのはものすごくおこがましい（ので深くはつっこまないでほしい）ですが、私の開発したmixer2では、JDK6に標準添付されているxjcコンパイラというツールを使って自動生成したJavaソースコードを大量に使っています。XML(XHTML)という分野では非常に有効な自動生成ツールの一つだからです。

著名なプログラマの一人である小野さん率いるアプレッソ社の主力製品は、DataSpiderというデータ連携のための自動化ツールです。特定の分野において、自動化ツールを使う側ではなく自動化ツールを作る側に立ち、しかもその価値を認められて10年以上にわたり生き残っていることこそ、ITにおける自動化のなんたるかを正しく心得ている証左でしょう。ちなみに彼のブログで個人的に好きなのはバグは夜更け過ぎに仕様に変わるだろう(2007年)です。

10年ほど前、インターネットバブルに踊り莫大な赤字を垂れ流す怪しげな本屋がありました。彼らは、物理的な電子回路と仮想的な電子回路とをリアルタイムに相互変換するという不可思議なツールの価値を正しく見抜き、使い方を磨き、その結果、世界有数の先進的なITサービス企業へと変貌を遂げました。Amazon Web Serviceです。大した根拠もないピーク予想値と少ない予算という不条理のなかで、HDD容量を自動見積もりするexcelシートと向き合い納品リードタイムを気にする必要はなくなりました。ハードウェアを、いや、ミドルウェアをも、ボタン一つで増減できる自動化ツールがそこにあるからです。

10年ほど前、一人の日本の若者が渡米し、XMLというデータ形式を取り扱うコードを書きまくりました。それが現在のJava6のJAXB-APIであり、先述のxjcコンパイラもその副産物です。その道程で、彼は自らの仕事に集中するために、逆に本質的ではない煩雑で退屈な仕事を自動化するためのツールを作り上げ、親しみをこめてhudsonと名づけました。現在のJenkinsです。バックエンドデータストアとしてRDBMS等に頼らず、XMLそのものの柔軟性を最大限に生かすことによって、導入と運用のハードルの低さを実現した自動化ツールの登場です。優秀な執事たるJenkinsにビルドとテストを任せることはこの業界のデファクトとなりました。来週に迫ったJenkinsユーザ・カンファレンス2012東京（at市ヶ谷 法政大学）の参加者は1000人を超えつつあります。

ソフトウェア開発自動化が目指すべき姿とはなんでしょうか？

ここまでのように私がクドクドと書くまでもなく、先人がすばらしい示唆を残してくれています。それを紹介して、このエントリを終わりましょう。

ソフトウェアアーキテクトが知るべき97のこと オライリージャパン (2009) より クリエイティブコモンズ 表示3.0に基づく全文の転載。（太字は転載者によるものです）

煩雑なことを非属人化し、創造性を高める
萩原正義

ソフトウェア開発の完全な自動化は目指すべきではありません。

DSL（ドメイン特化言語）のスコープを十分に小さくし、生成コードの実行をWebアプリケーションの特定フレームワークに限定すれば、完全な自動化は可能となるでしょう。しかし、この自動化はDSLのスコープが限定された小さな問題領域と特定の実装技術に対してのみに有効であって、一般のソフトウェア開発が対象とする広範な問題領域、実装技術の選択肢に大して有効な解とはなりません。

それでは、問題領域を小さな部分問題に分割して、それぞれの部分問題を解くためのDSLを複数組み合わせる方法や、逆に1つのDSLのスコープを広げて汎用性を高める方法でのソフトウェア開発の完全な自動化は 可能でしょうか？

前者は分割したDSL間での依存関係や相互作用がまったく存在しない「直交化」した問題に関しては可能となるかもしれませんが、一般にはこのような単純な問題は少ないでしょう。後者は、DSLはもはや汎用開発言語の範疇になり、一般のプログラミングによる開発となんら変わりがなくなり自動化は難しくなるでしょう。

DSLやその他の開発ツール、モデル駆動型開発は、繰り返し起こる煩雑な開発を自動化することで省力化を行うためであって、ソフトウェア全体を自動化する目的で使うべきではありません。それほどソフトウェア開発は単純なものではありません。 また、問題領域あるいは解決領域のスコープ自体も、ビジネスの進化、ソフトウェア技術の進化、要求の変化によって、固定的な定義で収まるものではありませんから、ソフトウェア開発の自動化の対象領域自体の前提も成立しなくなります。進化しないソフトウェアはいずれ価値を失い、自動化の有効性はなくなるでしょう。

このように間違った目的を目指して技術を適用しようとしても失敗することは歴史が証明しています。進化するビジネスや技術、変化する要求の中で、不変の規則、原理を発見し、この規則と原理に基づき自動化するならば有効な解となるでしょう。不変の規則と原理は繰り返し現れるので、煩雑さを非属人的な 方法で省くことが可能となります。

その上で、創造性や進化が求められる部分に人間の知的作業を集中させることで、ソフトウェア開発の工業化が可能となると考えます。ソフトウェア開発の工業化を大規模な製造の自動化と考えるのはよく見られる誤りです。ソフトウェア開発での工業化は、人による創造性や知的作業と自動化の分担で実現し、その意味では、ソフトウェアは完全な工業製品というより、むしろ人の創造力を含んだ工芸品を目指しているといえなくもないでしょう。

技術と創造力を融合したソフトウェア開発の在り方は、筆者の考える「ソフトウェア工芸」の捉え方の基になっています。

mixer2がjavax.cache (JSR-107)に対応

mixer2 1.1.3をリリースしました。既にmavenセントラルリポジトリから利用可能です。

まだ一部ですが、javadocを英語と日本語の併記にしたほか、 ロードしたテンプレートをキャッシュして性能向上させられるなりました。 JSR-107として規格化されつつある javax.cache.Cache の実装クラスのインスタンスをMixer2Engine内にsetするだけで使えます。 詳しくは javadoc に。

とはいっても、実は、手元でいろいろためしたのですが、キャッシュを使ってもそれほど性能はあがりません。＾＾；） いまのところおそらく唯一であろうJSR107の実装であるehcache-1.4.0beta1を使ってテストしたのですが、 mixer2が普通にhtmlテンプレート文字列をロードしてHtml型オブジェクト化するのと、キャッシュからHtml型オブジェクトを取り出すのとではそれほど大きな性能差が見られませんでした。

見方はいろいろですが、mixer2の性能はもともとそれほど悪くはないと言えるのかもしれませんし、ehcacheの今後の改良次第で差が現れてくるのかもしれません。いずれにせよJSR-107を実装するキャッシュフレームワークはどんどん種類が増えてくるはずですので、今後に期待しましょう。

Jenkins IPMessenger Pluginを作ってみた

勉強がてら、JenkinsがIPメッセンジャーでビルド結果を通知してくれるプラグインを作ってみました。 https://wiki.jenkins-ci.org/display/JENKINS/IPMessenger+Plugin

実装はゴールデンウィーク中に出来ていたのですが、jenkins-ci.orgへのdeployやwiki執筆に至る前に時間切れになってしまったので告知が遅れました。

とはいっても少々やっつけ感のある実装です。しかもまずいことに、テストを書いてませんｗ。 外部の通信先を必要とするようなコードのテストケースって書きづらいんですよね。受け取り側のSocketのフリをしてくれるMockとか、あるのかしらん。

メッセージの内容は設定画面である程度カスタムできます。$JOB_NAMEとか $BUILD_ID といった、メール通知なんかでもよく使われるマクロが使えます。

ただ、通信先はIPアドレスかホスト名（Windowsマシンでいうコンピュータ名で可）でしか指定できません。 これは、IPメッセンジャーの設定ユーザー名やグループ名などの情報を得るには、メッセージを送る前にまずLAN内にブロードキャストを投げて反応があったマシンから各種の情報を事前に受け取っておかなければならない、という実装部分をはしょったからです。^^;)

誰かパッチ書いてくれたらマージしますんでよろしくお願いします。

mavenからAmateras Step Counterを使う設定サンプル

最近のAmateras StepCounterはantタスク対応＆mavenリポジトリ登録（※セントラルではない）などにより、 mavenからも使いやすくなったようです。 作者の方に感謝！

  
   amateras
   Project Amateras Maven2 Repository
   http://amateras.sourceforge.jp/mvn
  
 
 
  
   
    org.apache.maven.plugins
    maven-antrun-plugin
    1.7
    
     
      jp.sf.amateras.stepcounter
      stepcounter
      3.0.1
     
    
    
     
      package
      
       run
      
      
       
        
        
         
          
          
         
        
       
      
     
    
   
  
 

これでtargetディレクトリ配下にstepcount.csvというファイルが出来上がります。 csvのカラムは左から順にファイルパス、タイプ、カテゴリ、実行行数、空行数、コメント行数、合計行数、のはずです。

mixer2をmavenのセントラルリポジトリに登録しました

とりあえず最新版を登録しました。 http://search.maven.org/#artifactdetails|org.mixer2|mixer2|1.1.0|jar です。 以後、バージョンアップはすべてセントラルに登録していきます。

これまでは独自リポジトリでやっていたので、repositoryタグに http://mixer2.org/mvn/ を指定する必要がありましたが、 これからは普通に dependencyタグを書くだけで利用できます。

ソースコードも、プロジェクト自体をgithubに置いて晒すことにしました。 https://github.com/nabedge/mixer2です。 readme.mdファイルはそのうち作るつもりです。 これまでも*-sources.jarの形で公開はしていたのですが、これでみなさんにforkしてもらいやすくなりました。 ライセンスはApache License 2です。

詳しい説明は http://mixer2.org/site/にあります。 これからも、ごひいきに！

タリーズ行ったら7000円くれた

年末恒例福引大会とかそういうことではないです。残念。

普段、タリーズのプリペイドカードでコーヒーを買っているのですが、昨日、レジで僕のカードをバーコードリーダーでピってやったらレジのお姉さんの顔が変わって店長！とか言いだしたのです。

なに？オレおたずね者？イスにコーヒーこぼしたの見られてた？うわごめんなさいごめんなさい。

ということではなくて、この前来たときお釣り7000円をお姉さんが渡し忘れたらしいとのこと。
タリーズコーヒーで7000円て！？

思い出しました。確かにプリペイドカードが残高不足だったので3000円チャージしようとして1万円札を渡した気がします。 （ちなみに３０００円チャージするとコーヒー一杯無料件がもらえる）

あとで気づいた店側が、僕のプリペイドカード情報にフラグつけて、レジ通した瞬間アラートが出るようにしてあったようです。店長さんが、いやあ、また来ていただけてホントよかったです、と言いつつ７０００円くれました。１万円札出してお釣りもらうの忘れる自分も自分だなとあきれつつ、タリーズえらいなあ、と思いました。

springの設定ファイルをWEB-INF直下に置くとテストが難しくなる

Spring + Struts あるいはSpring + SpringMVCといった組み合わせでWebアプリケーションを作る場合、
src/main/webapp/WEB-INF/applicationContext.xml
のような位置にspringのbean定義ファイルをつくる例が多いようです。実際、巷の書籍やIT系サイトの記事などでもそのようなサンプルがよく公開されています。

しかし、この配置方法には実は大きな問題があります。JUnitなどのテストケースを実行するとき、その設定ファイルをロードできません。なぜならWEB-INFの直下はクラスパスではないからです。

• @ContextConfiguration and loading contexts from /WEB-INF [Archive] - Spring Community Forums （2009年ごろのSpringの公式フォーラムでのスレッド）

このスレッドでもほぼ同じ問題について議論されていますが、このときは結論はでていなかったようです。 結局、似たような設定ファイルをsrc/test/resources配下等に置いて二重管理するといった、気の進まない方法に頼ることになってしまいます。

eclipse上でsrc/main/resources/applicationContext.xml のようなビルドパスの通っている位置に移動させたうえで、web.xmlのほうには

    
        org.springframework.web.context.ContextLoaderListener
    
    
        contextConfigLocation
        classpath:mainContextConfig.xml
    

のようにclasspath:記法で書いておけば、クラスパス配下の設定ファイルをロードしてくれる（実体はWEB-INF/classes/mainContextConfig.xmlのようになる）。。。 はずなのですが、そうはとんやかです。

詳細は不明ですが、ContextLoaderListenerは強制的にWEB-INF/直下の設定ファイルを探しに行ってしまいます。 結果、FileNotFoundExceptionを吐いてWebアプリが起動しません。 これを防ぐため、たとえば

    
        contextConfigLocation
        WEB-INF/applicationContext.xml, classpath:mainContextConfig.xml
    

のように書いておき、applicationContext.xmlには<beans><!-- dummy! --></beans>のような無設定のダミーを仕込んで、本来の設定をすべてclasspath:mainContextConfig.xmlのほうに書いておくことで対応できます。