Saturday, December 1, 2012

SpringToolSuiteでSAStrutsとSpringMVCのHelloWorldを作るまで

Spring Tool Suite(以下STS)はeclipseをベースにしたIDEです。ライセンス料等はかかりません。

eclipseをベースとしているので見た目も操作感もeclipseそのものですが、ノーマルのeclipseと違ってサーバーサイドJava開発に必要なプラグインやmavenコマンドなどが初めから標準搭載なので、開発環境を手っ取り早く作るにはもってこいです。もちろんEclipseマーケットプレイスなども普通に使えるのでお好みのプラグインを追加することも可能です。

2012年10月に公開されたSTS3.1.0はeclipse3.8ベースのものとeclipse4.2ベースのものの両方が公開されています。両者ともmavenコマンド本体とm2eプラグイン、m2e-wtpプラグイン等が同梱されています。 公式ブログによると、eclipse3.xと4.xとでUIプラットフォームの違いからくるいくつかの問題があったようです。

eclipse3.8ベースのほうのSTSでSpringMVCとSAStrutsのプロジェクトを試作してみたところ、安定して開発ができそうな感じが得られました。今回はその手順を細かめに紹介します。

準備するもの

  • JDK6以上がインストール済みのPCが必要です。JREではなくJDKです。 mavenコマンドがコンパイル作業をすることがあるのでJDKが必須。
  • Tomcatは同梱されていませんのでこれもあらかじめインストールしておいてください。 Apache Tomcat - Apache Tomcat 7 Downloadsからzipをダウンロードして解凍するだけです。ここでは C:\apache-tomcat-7.0.33 に解凍済みだとして解説します。7ではなくてTomcat6でも大丈夫です。

STSのインストールと起動

  1. Tool Suites Download | SpringSource.orgからspring-tool-suite-3.1.0.RELEASE-e3.8-win32.zipをダウンロードします(64bitOSの人はwin64のほうを)
  2. お好みの位置でzipを解凍します。
  3. STSを起動します。解凍したフォルダのspringsource\sts-3.1.0.RELEASE\STS.exeを実行するだけです。緑色のスプラッシュが見慣れないかもしれませんが、起動したアプリをよく見るとそれはeclipseそのものであることがわかると思います。

mavenのWebプロキシ設定

これから作るHelloWorldアプリはmavenプロジェクトとして構成されます。 mavenコマンドはインターネット上のセントラルリポジトリサーバーから必要なjarを自動的にダウンロードしてきますが、このとき、Webプロキシを通過させる必要があるLAN環境の場合には、mavenの設定追加が必要です。

${user.home}/.m2/settings.xml というファイルを作成し、 http://maven.apache.org/settings.html#Proxiesで解説されている形で設定を書いておきます。 ちなみに ${user.home}/.m2/settings.xml というのはWindows7で言えば C:\Users\[OSユーザ名]\.m2\settings.xml にあたります。

もちろん、直接インターネットに出られるマシンの場合にはこの設定は不要です。

パースペクティブの変更

これは必須ではありませんが、この後の説明の画面キャプチャがJavaパースペクティブになっているので、それにあわせておいてください。

Tomcatの登録

STSの(というよりeclipseの)WTPプラグインを使ってeclipse内でTomcatと連携できるようにしておきます。

  1. Window→Preference→Server→RuntimeEnvironmentのダイアログを開きます

  2. Addボタンでサーバ追加用のダイアログが出ますので、ApacheTomcat7を選択してNextをクリックします

  3. あらかじめ展開しておいたTomcatのフォルダを指定して、Finishボタンを押せば完了です。

SpringMVCによるHelloWorld Webアプリの作り方

これで開発環境の準備が整いました。いよいよWebアプリを作ってみましょう。SpringMVCフレームワークを使う場合はプロジェクトの新規作成ウィザードで、SpringMVCテンプレートを選択するだけです。

  1. File→New→SpringTemplateProjectをクリック

  2. SpringMVCプロジェクトをクリック

  3. プロジェクト名とJavaパッケージ名を決めます。ここではmyspringmvc, パッケージはcom.example.myspringmvc としました。

  4. これでHelloWorldプロジェクトの完成です。ここでもしも赤いバツ印が出ていてもあわてる必要はありません。eclipse上で再ビルドすれば直ります。Project→Cleanしてください。(メニュー上のBuild Automaticallyのチェックはオンにしておいてください)

  5. いよいよTomcat上で起動してみましょう。プロジェクトを右クリックしてRun on Serverをクリックします。

  6. まだTomcatサーバがeclipseに無いので作ります。manually define a new serverのラジオボタンをオンにして、Tomcat7を選択し、finishをクリックします。

  7. tomcatが起動し、Hello World画面が表示されます!

SAStrutsによるHelloWorld Webアプリの作り方

私はSpringMVCも好きですが、SeasarプロジェクトのSAStruts(エスエーストラッツ/SuperAgileStruts)も、驚くほど使い勝手が良いので気に入っています。

STS(Spring Tool Suite)は文字通りSpringフレームワークをベースとしたアプリケーションを作るための開発環境ですが、元はeclipseなので、Srping以外であっても何でも開発できます。

STSにはmaven連携プラグインはもちろんmavenコマンド本体も初めから同梱されているのがポイントです。sastruts公式サイトでの説明にあるとおり、mavenコマンドをコマンドラインから実行してプロジェクトを作ってみましょう

  1. Windowsコマンドプロンプトを開きます。まずJAVA_HOME環境変数を設定しておきましょう。
    set JAVA_HOME=C:\jdk1.6.0_33
    
  2. 次に、mavenコマンドでアーキタイプからプロジェクトを新規生成します。 (下の例ではSTSがC:\springsourceの配下に展開されていると仮定しています)
    C:\springsource\apache-maven-3.0.4\bin\mvn.bat archetype:generate ^
     -DarchetypeRepository=https://www.seasar.org/maven/maven2/ ^
     -DarchetypeGroupId=org.seasar.sastruts ^
     -DarchetypeArtifactId=sa-struts-archetype ^
     -DarchetypeVersion=1.0.4-sp9.1 ^
     -DgroupId=com.example ^
     -DartifactId=mysastruts ^
     -Dversion=1.0-SNAPSHOT
    
  3. コマンドプロンプト上にBUILD SUCCESSFUL と表示されれば成功です。 上で指定したartifactIdと同じ「mysastruts」というフォルダにプロジェクトが生成されています。
  4. しかし、実は、sastrutsのアーキタイプには、.settingsフォルダや.tomcatpluginファイルのような、古いeclipseで使用する制御ファイルも含まれています。STSを使う場合にはこれらは必要ありません。 STSにインポートする前に以下のフォルダ/ファイルを消しておいてください。
    • .settingsフォルダ
    • .tomcatPluginファイル
    • .amaterasファイル
  5. こうして出来たプロジェクトをSTS上にインポートします。

  6. Existing Maven Projectを選択し、先ほど作ったmysastrutsフォルダを選択すると、自動的にpom.xmlを読み込んでMavenプロジェクトを認識してくれます。

  7. これでSTSのパッケージエクスプローラ上にmysastrutsプロジェクトが見えるようになっているはずです。 しかし、まだエラー(赤バツ印)が出ているはずです。 実はsastrutsのアーキタイプは非常に古いeclipseに対応するための設定がpom.xml上に書かれていますが、それらはSTSのような最近の開発環境では不要です。そこで、pom.xmlを開いて、<build>タグ内の下記の部分を全てコメントアウトまたは削除してください。
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  8. pom.xmlを変更した場合には、STSのmavenプラグインでUpdateProjectしておきます。

  9. これで準備完了です。上のSpringMVCのときと同じように、mysastrutsを右クリック→Run as→Run on Server でTomcatを選択して起動してください。
  10. SAStrutsのHello World画面が表示されました!

いかがでしたか?Java開発の世界では事前準備が結構大変なのですが、 STSにはサーバーサイドJava開発に必要なツールが全て同梱されていますので、すぐにプログラミングにとりかかれます。 あとからSTSに追加すべきプラグインをしいて挙げるとすれば、我々マルチバイト言語な人間にとっては必須なのはプロパティエディタプラグインくらいなものではないでしょうか。

ところで、もっと高機能なテンプレートを公開している方もいます。詳しくは STSでSpringMVC+SpringDataJPA+HibernateなPre-Configuredテンプレートプロジェクトをクイックスタート! #jsug - BLOG.IK.AMをご覧ください。それではHappy hacking !

Friday, November 2, 2012

Spring MVC: from JSP and Tiles to Mixer2

This post is inspired by Spring MVC: from JSP and Tiles to Thymeleaf | SpringSource Team Blog. Of course, This post is not a parody but my honest opinion as the comitter of Java Template Engine mixer2.

Plain JSP

Let us get started with the below code sample:
<html> ...
 
Table is empty.
First Name Last name
${user.firstName} ${user.lastName}
</html>

And Mr Michael Isvy saying that:

2) Verbosity
Our users page is fairly small because it simply displays a list of elements. We already have 50 lines of code (the above code sample has been slightly reduced). You can imagine how big it would be if we had to display a lot of content.

3) HTML/CSS compliance
This page is not HTML/CSS compliant. Suppose a Web Designer has prototyped it, you would have to rewrite it completely in order to use intrusive JSP syntax.

I completely agree above. Also, I agree the solution of Thymeleaf template engine. But today, I suggest another solution, mixer2.

This is template file of mixer2.

<html> ...
 
Table is empty.
First Name Last name
john doe
</html> ...

This is Controller code of Spring MVC with mixer2.

@Controller
public class HomeController {

    @Autowired
    Mixer2Engine mixer2Engine;

    @RequestMapping(value="/userList", method=RequestMethod.GET)
    public ModelAndView mixer2test() 
        throws IOException, TagTypeUnmatchException {

        // load template html
        File file = ResourceUtils.getFile("classpath:userList.html");
        Html html = mixer2Engine.loadHtmlTemplate(file);

        // getting user data from database...
        List<User> userList = ....

        // remove <div id="ifempty"> tag
        html.removeById("ifempty", Div.class);

        // clear "john doe" tr/td tags.
        Tbody tbody = html.getById("users",Table.class)
                              .getTbody().get(0);
        tbody.getTr().clear();

        // embed user data
        for (User user : userList) {
            Tr tr = new Tr();
            Td td1 = new Td();
            Td td2 = new Td();
            td1.getContent().add("Lady");
            td2.getContent().add("Lady");
            tr.getThOrTd().add(td1);            
            tr.getThOrTd().add(td2);     
        }
        // above code is verbose 
        // but you can do KAIZEN by TableBuilder.
        // see http://mixer2.org/site/ja/tablebuilder.html

        Map<String,String> model = new HashMap<String,String>();
        model.put("htmlString", mixer2Engine.saveToString(html));
        ModelAndView modelAndView = new ModelAndView();
        modelAndView.setViewName("view-for-mixer2");
        modelAndView.addAllObjects(model);
        return modelAndView;
    }
}

and JSP becomes so simple. (you need only one jsp. src/main/webapp/WEB-INF/views/view-for-mixer2.jsp)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
${htmlString}

note: Above code is verbose. now I am writing "Mixer2ViewResolver" for mixer2 on SpringMVC.

Pros and Cons

On the bright side:

  • Web designer friendly template. because there are no jsp custam tag, no other name space but only html/css. 100% pure html/css !
  • You can write View of MVC by java code. You need not to learn about jsp custom tag nor tiles tag. You must only learn pure java. Ctrl+Space key on eclipse can help you.
  • You can write test case for view by pure JUnit because the view code is written by pure java code.

On the down side:

  • Mixer2 is a small open source project. not so popular now.
  • JSP or Template code is less. But java code becomes fat.

If you are a programmer, and starting on a new project with another web designer, I strongly encourage you to compare both Mixer2 and JSPs in order to figure out which one is more suitable to your needs.

other reference:

Saturday, October 20, 2012

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

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

その他のまとめとか:

Saturday, October 13, 2012

.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ワークスペースにプロジェクトをインポートできる、それがゴールだ)

こんなQ&Aもあります。 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を使っている人もいるのです。必ずトラブルになるでしょう。

Thursday, July 26, 2012

諸君、私は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 諸君 私は戦争が好きだ

Sunday, July 22, 2012

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

自動化ツールを使ったプログラミングレスなシステム開発、という流行病(はやりやまい)は数年おきに出現します。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やその他の開発ツール、モデル駆動型開発は、繰り返し起こる煩雑な開発を自動化することで省力化を行うためであって、ソフトウェア全体を自動化する目的で使うべきではありません。それほどソフトウェア開発は単純なものではありません。 また、問題領域あるいは解決領域のスコープ自体も、ビジネスの進化、ソフトウェア技術の進化、要求の変化によって、固定的な定義で収まるものではありませんから、ソフトウェア開発の自動化の対象領域自体の前提も成立しなくなります。進化しないソフトウェアはいずれ価値を失い、自動化の有効性はなくなるでしょう。

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

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

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

Sunday, May 27, 2012

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を実装するキャッシュフレームワークはどんどん種類が増えてくるはずですので、今後に期待しましょう。

Sunday, May 13, 2012

Jenkins IPMessenger Pluginを作ってみた

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

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

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

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

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

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

Sunday, April 22, 2012

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のカラムは左から順にファイルパス、タイプ、カテゴリ、実行行数、空行数、コメント行数、合計行数、のはずです。

Thursday, March 15, 2012

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/にあります。 これからも、ごひいきに!