nDiki : Ant

17:15 Checkstyle を ant に追加

Checkstyle は Java のコードのスタイルや Javadoc 用コメントのチェックをする Java クラス(コマンドラインツール / Ant タスク)。

Debian のパッケージにはまだなっていないので、公式サイトからとってきて .jar ファイルを /usr/local/share/java に放りこむ。 必要なライブラリの ANTLR と Regexp は Debian パッケージになっているので入れとく。

コマンドラインでちょっと試した後 build.xml にターゲット追加して統合。 これで JUnit とあわせて、コードの品質があがるようにがんばろ。

[ Java ] 22:30 Cocoon2 はどうかな?

最近、本サイトの生成フレームワークを一新すべく模索中(現在は XML + 自作 Perl スクリプト)。 今の最有力候補は XML + Ant + Xalan。 他にいろいろ見ていたら、Cocoon 2 はどうかなと。 XML から XSLT 他を用いて HTML とか WML とかを生成する server application なんだけど、ローカルで立ちあげて Wget とかでローカルに静的なファイルとして落とせば、それをサーバに置けるんじゃないかなぁ。 すぐ思いつく問題は、

• 「make 的(必要なファイルのみの)更新」(毎回すべて更新されるとサーバへのアップロードで困る)、
• 「SSI がちょい面倒?」(Coccoon 2 では処理しないでそのまま出力させる)、

「コンテントネゴシエーションまわり」(en, と ja を別々のファイル名できちんととりだせるか)

等々。ドキュメントだけ静的にアーカイブしたものとかあるから、静的なファイルに落とせるんだろうなとは思いつつ。 とりあえず、インストール。 まず先に Tomcat

 cd /usr/local
 tar zxvf jakarta-tomcat-4.0.1.tar.gz

次 Cocoon 2

 cd /usr/local
 tar zxvf cocoon-2.0-bin.tar.gz
 cp /usr/local/cocoon-2.0/cocoon.war /usr/local/jakarta-tomcat-4.0.1/webapps/

Tomcat がデフォルトで 8080 ポートをつかうのだが WWWOFFLE が既に使っている。 Tomcat の方をずらすより、WWWOFFLE の変更の方が勝手がわかるのでそちらをずらす。 で

 /usr/local/jakarta-tomcat-4.0.1/bin/startup.sh

で起動。http://localhost:8080/cocoon/ に Galeon でアクセス。 一発目は非常に遅い。他のページも一度目は閲覧は遅いがキャッシュが効くので次からはそれほどでもない。

とりあえず、ドキュメントを読んでいろいろ調査。

13:00 Ant 用タスク styler

Ant 組み込みの style タスクの強化版 styler を使って 携帯電話向けのページをメンテしようかと。

styler は style に比べて mapper が使えたり XSLT のパイプラインができたりしてお便利。

しかし……XSLファイルでの xsl:output がうまく効かない。styler の type オプションが優先されているようだ。 さてどうするか。

去年の今ごろ

2001年6月1日より。

• 岩本町・東神田ファミリーバザール
  • 今年も昨日から開催されている。昨年行ってみて、どうも自分の趣向と違うようだったので今年は見にいかなかった。
• Doxygen で Document を Generate
  • これはアタリ。今も利用している(タマにだけど)。Ant から doxygen を呼び出す extension や、Emacs から利用するための doxymacs 等いろいろ便利なツールもある(後者はまだ使った事なし)。

Eclipse 2.0.2

遅ればせながら、ればせながら、Eclipse。

2.0.2 (+ NLS SDK 2.0.1 Translations) を Debian GNU/Linux sid ノート PC に入れてみる。 ふむ。Forte より確かに軽快。 しかし GUI Builder はついていないのか。 それだったら、通常は Emacs + Ant で十分だな。

リファクタリング支援機能は便利そうなので、8割 Emacs で書いて気分転換に Eclipse で修正するのが吉か。

Windows 用 GNU Make

Windows だと nmake がやっぱり主流だろうか。 しかし GNU Make とは違う点が多く、使い分けるのも面倒。 かといって Ant というのも面倒。

ということで気軽に使える Windows 用の GNU Make を探す。 Cygwin 版は共同作業者に入れてもらうのが面倒なので却下(Makefile から呼ばれるコマンド群もLinuxと同様のものが入るのでこちらの方が便利といえば便利ではあるのだが)。

MinGW版が 3.80 をポーティングしているし単体でも動きそうなのでこれを試してみることにする。

mingw32-make-3.80.0-3.exe を取ってきて実行。make そのものだと思っていたがマニュアル等を含むインストーラだった。 一旦インストールして、mingw32-make.exe をコピーしてアンインストール。 mingw32-make.exe 単体で動作するので取り扱いが楽でよい(必要なら make.exe にでもリネーム)。

Windows 特有の問題があるかどうかは今後使ってみてチェックだな。

YAMLのJava実装を書く

プライベートで書く事にした。 Eclipse 3.0 も入れたし、即実装開始。 えーと、まずはBOMの処理か。

しかし今だに Java のパッケージングの慣習がわからない。 make dist にあたるものは無いのか? まだ Ant ではスタンダードなスタイルは確立されていないの?

SCons は GNU Autotools のかわりになるか

NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。

• クロスプラットフォーム
• Autoconf、Automake と同様の機能を統合
• LaTeX もビルトインサポート

と興味深いツールになっているようだ。

現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIX、Windows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。

基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。

一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。 結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。

実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。

SCons は Python ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。

ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。

Module::Build でソースパッケージング

ExtUtils::MakeMaker

私が Perl が好きな理由の一つに、標準でExtUtils::MakeMakerという Makefile ジェネレータがついているところである。これを使って Makefile.PL を書くと

 perl Makefile.PL
 make manifest
 make
 make test
 make dist

で <pacakge>-<versionno>.tar.gz というソースパッケージを作ることができ、

 tar zxvf <pacakge>-<versionno>.tar.gz
 cd <pacakge>-<versionno>
 perl Makefile.PL
 make
 make test
 make install

という手順でインストールする事ができるようになる。 パッケージの作り方が確立されているので、容易に新しいパッケージを開発しはじめられる。

逆に Java でプログラムを書くのが億劫なのは、このあたりの準備が面倒だからである。 Ant を使っても結局ここら辺自分でやらなければならないし。

ちょっとしたアーカイブの作成

ちょっとしたパッケージを作りたいと思うことは良くある。 例えばいくつかのデータファイルと、READMEファイルなんかをひとまとめにしてアーカイブにするとか。

本当にちょっとしたであれば、手動でアーカイブすれば良いのだが、

• アーカイブしたいファイル群がバージョン管理下にあって、CVS ディレクトリや .svn ディレクトリがある (除外してアーカイブする必要がある)
• 同じディレクトリにある、作業用のファイルはアーカイブしたくない (除外してアーカイブする必要がある)
• アーカイブする前に、チェック用のリグレッションテスト一式を走らせたい (リグレッションテストをかけられるようにする)
• UNIX でも Windows でもアーカイブ化できるようにしたい。

あたりを考慮しなければならない時は面倒くさくなってくる。

自動化としては

• シェルスクリプト/バッチファイルを書く
• Makefile を書く
• GNU Autotools を使う

あたりがぱっと思い浮かぶ。 しかし、最初の2つは毎回同じようなものを書くのが面倒だし保守もしにくい。 GNU Autotools はちょっとごっつすぎだし、Windows での環境構築も面倒。

ExtUtils::MakeMaker の欠点

ということで最初は ExtUtils::MakeMaker を使うという線で考えてみた。 もともと Perl モジュール用で汎用用途にはちょっと邪魔な振舞いもあるが、使えないことはないと思う。 しかし make (GNU Make あるいは nmake など) に依存しているという欠点がある。

Module::Build で

ということで ExtUtils::MakeMaker の代替である Module::Build ベースで汎用用途に使えないか検討してみた。こちらは pure Perl で make を必要としない。

Module::Build も Perl モジュールビルドにあわせた振舞いがあるものの、ちょっとカスタマイズすれば使えそうだ。 で、いろいろいじった結果、次のような感じにすると使いやすそうだ。

 use Module::Build;
 my $class = Module::Build
   ->subclass(class => 'NonmoduleBuilder',
              code => q{
                        # Don't make blib
                        sub ACTION_code {};
                        # Don't make blib
                        sub ACTION_docs {};
                        # Don't make META.yml
                        sub ACTION_distmeta {
                          # no warning on ACTION_distdir
                          $_[0]->{metafile} = 'MANIFEST';
                        };
                        # Don't add MEATA.yml to MANIFEST
                        sub ACTION_manifest {
                          $_[0]->{metafile} = 'MANIFEST',
                          $_[0]->SUPER::ACTION_manifest(@_);
                        };
                       });

 # Set your archive name and version.
 $class->new(dist_name => 'mypackage',
             dist_version => '1.0.2',
             )->create_build_script;

カスタマイズした部分は以下(Module::Build 0.26 で動作確認)。

• Perl モジュールビルドに特有の blib ディレクトリを作らないようにする。
• META.yml を生成しないようにし、アーカイブに含まれないようにする。

上記のようなファイルを Build.PL という名前で作っておけば

 perl Build.PL
 ./Build manifest
 ./Build
 ./Build test
 ./Build dist

等として、アーカイブ作成が容易にできるようになる。

しばらくこの方法でいろいろ試してみることにしてみよう。

Linux 上で Flex 2 SDK を使った Flash コンテンツ開発を開始

Flash コンテンツ開発については以前から興味があったんだけれど、手元 (Debian GNU/Linux BOX) で開発環境が構築できないので、ほとんど手をつけていなかった。 Ming を試してみたこともあったのだが、全然使いやすくなかったし。

しかしながらここ最近では Flex 2 SDK によって、Linux 上でも Flash コンテンツを開発できるようになった。 ということで技術調査をかねて開発環境構築と、コード書きを始めてみた。

まずはエディタとコンパイラと単体テストフレームワークがあれば開発できる。 Debian GNU/Linux sid 上で用意した環境は以下。

• JDK - sun-java6-jdk (6-02-1 Debian パッケージ)
• Ant - ant (1.7.0-3、Debian パッケージ)
• Emacs 21 (Debian パッケージ)
• Flex 2 SDK (2.0.1、Adobe よりダウンロード)
• Flex Language Pack (日本語、Adobe よりダウンロード)
• Flex Ant tasks (022607、Adobe Labs よりダウンロード)
• FlexUnit (code.google.com よりダウンロード)
• Flash Player 9 スタンドアロン版

エディタは素直に Emacs で。単体テストフレームワークは、FlexUnit (.85) をチョイス。

今回はビルドツールを何にするか迷ったけれど Apache Ant にすることにした。最初は Makefile を使ってサンプルをビルドしていたりしたけれど、今後 Autotools 使うのもどうかなと思って。

ドキュメントについては Adobe から結構な量で提供されているのでこれを見ればたいがい足りそう。

ということでぽちぽちプロジェクト作成。とりあえず SWF ファイルと同じところにあるテキストファイルを読み込んで表示するだけの MXML ファイルを作成して、build.xml を構築。

ほとんどの時間は build.xml 書きと、Subversion リポジトリセットアップに費された。

後は別途ちょっとサンプルで試してみた FlexUnit をプロジェクトに組み込めば発進できそうだ。