trac

2ヶ月ほど前から、プロジェクト管理を GForge から trac に乗り換えました。
Wiki ベースのプロジェクト管理ツールで、Subversion との連携は抜群。バグトラッカであるチケットシステムもシンプルでなじみやすいです。
乗り換えた最大の理由は、 trac が Python で書かれていること。
GForge は PHP4 で書かれており、GForge を使うためだけに サーバーに mod_php4 を入れていました。
apache2.0.x を使っているので、mod_php4 の使用は推奨されてないんですよね。。
また、最近は PHP で開発することもほとんど無くなり。。。必要性がかなり薄れておりました。
とりあえず、すっきり PHP とオサラバしたかったのです(笑)
最近は、 trac で開発を行っているプロジェクトもよく見られるようになってきました。国内では Meadow とか、 Namazu など。
WWDC 2006で存在明らかにされたMac OS Xの次バージョン「Leopard」に搭載予定のカレンダーサーバーである、 Darwin Calendar Server も trac で開発が行われるようです。
日本語の情報が、まだまだ少ないようなので、時間があったら少しずつでも、ノウハウまとめていきたいと思っておりますが。。。
できるのか?(汗)

広告

Java で Ajax が書ける!

Google Web Toolkit
これすごい。
Java 使いにとっては朗報。
いまのところ、実行環境が Windows と Linux のみのサポートだそうで、 Mac 使いにはちょっとツライ。
でも、しつこく試してみたところ、実行環境は動かないけど、 Java のソースコードから、 HTML と JavaScript のコードは生成出来る模様。
このあたりは Java で動いているみたいです。
もちろん、それをブラウザで開けばちゃんと動きます。
試してないけど、 Debugging in Hosted Mode なんてものもあるので、 Eclipse 使えば動くのかな?
使い方覚えれば、かなり使えるかなと。
いま使っている、 Struts ベースのフレームワークと、どう連携させようか・・・。
落ち着いたらまた書きます(汗)

基本。

フォームに入力すると、見積書とか、請求書が PDF で自動的にできるソフト作ってくれーとの依頼入る。
Webベースにして、Java で作ることに。
Webベースにすることで、PCにインストールする手間が無くなり、ブラウザなら誰でも簡単に扱えるという利点がある。
ていうか、以前作ったことあるので、ちょっとカスタマイズするだけでできるのだが、くそまじめに作ろうと思い立ち、設計書から作ることに。
大規模なプロジェクトになると、概要設計→基本設計→詳細設計→製造→結合テスト→Quality Assurance(品質保証テスト) という流れは必須なのだが、小規模なアプリなら、ざっとER図とかクラス図を書いたりして、簡単に設計して、コーディングというように省略してしまう。
しかし、今回は、ちょっと基本をみっちりやろうと、概要設計から作っております。
設計書は、Excel、Word、PowerPoint等で作ることが多いと思いますが、僕はテキストベースで、Subversion 使って管理したいのです。
テキストベースにすることによって、プラットホームやバージョンの依存性が無くなり、Excel が入ってないからみれないとか、長い年月が経ち、作ったソフトが廃止され、ファイルが開けないということもなくなります。
いまやってるプロジェクトでは、APT(Almost Plain Text)というのを使っており、
Aptconvert is a command-line tool that can be used to convert the APT format to HTML, XHTML, PDF, PostScript, (MS Word loadable) RTF, DocBook SGML and DocBook XML.
ということで、かなりいろいろなフォーマットへ変換でき、大変優秀であります。
ベースとなるテキストファイルも Wiki に似た文法で、そのままでも読みやすい。
しかし欠点がただ一つ。
表が非常に書きにくいこと。
*+-:|を駆使して、表を書かねばならんのです。

*----------|--------:
|こんな        | 感じ      |
*----------|--------:

これ、超面倒(ーー;
かといって、LaTeX で書くほどのものでもないし・・・。
なんか良いツールは無いかと探していたところ、 SmartDoc はっけん。
前から知っていたのだけど、業界標準と言うほど使われておらず、デザインの柔軟性がちょっと乏しいかなと思い、敬遠しておりました。
また、僕は XHTML で出力したいので、これがないのがネックでした。
でも、それは、まだ SmartDoc が0.6とかのバージョンだった頃のお話。
現在、1.2b となって、かなり使えるツールになっております。
-html4.xhtml:true というオプションをつけると、XHTML で出力できるし、オプションと CSS を駆使すれば、かなり柔軟に HTML出力可能。
また、 PureSmartDoc 形式で書き出せば、XML DB と連携したり、 Java と連携したりと汎用性抜群。
ということで、いま、 SmartDoc を使ってごそごそ基本設計書を作っております。
で、いま作ってる帳票アプリは、機能が安定してきたらオープンソースで公開しても良いかなぁと思ってます。
PDFに出力する部分は、 JasperReports 使います。
こういうのは、一度作ってしまえば、割と楽なんですが、最初はなかなか敷居が高いですからねえ。。
とりあえず、基本に返って地道に頑張ります。。

ソースコードとドキュメントの管理

僕の開発環境(いちばん多用しているもの)

OS
Mac OS X 10.4
開発言語
Java SE 5.0
IDE
Eclipse 3.1.1
モデリングツール
Jude
SCM
Subversion

と、こんな感じなのですが、最近頭を悩ませているのは、ドキュメントの管理です。
いままで、適当にテキストファイルを作ってまとめていたのですが、どうも効率が悪い。
かといって、Wordみたいにバイナリファイルができるのは、バージョン管理しにくいのであまり好きじゃない。
Subversion を使っているので、バイナリでも差分でバージョン管理できるのだけも、diffつかって差分とれないから、あまり好きじゃないのです。
開発の上流行程の鍵を握るのは、ユースケース記述だったりするので、このあたりをしっかりまとめたいのです。

  • テキストファイルで管理できること
  • 大規模になり、大量の文書を抱えるようになってもメンテが楽なこと
  • 視覚的にわかりやすいこと
  • バージョン管理できること
  • 変更に強いこと
  • できれば、独自実装ではなく、すでに作られたもの。オープンソースで管理されているもの
  • Emacs で書けること

条件をあげると、これくらいでしょうか。
UMLモデリングツール Jude Professional には、ユースケース図にユースケース記述を連携させて記述することが可能です。
しかし、ASCIIファイルで管理できないことが難点です。XMIに出力するとASCIIで管理できますが、ユースケース記述はサポート外となってしまいます。
いま、XMLでうまく管理できないか考えてます。
XSLスタイルシートを使えば、見やすく表形式にもできますし。
DocBookもいいかなぁ。
この辺はもっと勉強せねば。。。

続きを読む

Eclipse Web Tools Platform(WTP)

なにやらいろいろつまっていて便利そうです。
以前は、インストールが大変そうだったので、敬遠していたのですが、eclipse.org の更新サイトからダウンロードできるようだったのでインストールしてみました。

  • JSP、XML、HTML、CSS、DTD、JavaScript Editor
  • XML Schema のグラフィカル編集
  • Webブラウザ、TCP/IP Monitor、Tomcat Debug
  • データベース操作、SQL Editor

と、いろいろ便利そうです。
でも、データベースや、SQLはまだまだみたいね。。
JSPとか、HTML、CSSは、Dreamweaver 8がすこぶる快適だし、XML関連は、XMLStudio2(開発テストに参加していただいたもの)があるので、WTPはほとんど使わなかったりする^^;
でも、TCP/IPモニタやデバッガなんかは便利そうなので、いろいろ使ってみようかと思います。
DreamweaverでJSFが使えるようになると強いんだけどなぁ。

続きを読む

ファイルアップロードの罠

お昼頃、「画像がアップ出来ないんだけど」というクライアントさんからのお問い合わせ。
ちゃんとテストしたのになと思いつつ、こちらからはアップできることを確認。
でも、「できないんですよ」とのお答え。
よく調べてみると、Windows の IE からはアップできない事を確認。Safari からは OKだったのに。。。
ソースとにらめっこしていると、 form タグの enctype が、 multipart/form-data でなくてはいけないのに、 application/form-data になっているのをはっけん(自爆)
そりゃアップできないわ。。でも、Safariってこれでもアップできちゃうのね。。
あと、画像の縦横サイズ取得のために、 InputStream#mark(0) して、ImageInputStream を取得し、 ImageReader から width と height を取得した後、 InputStream#reset() して、ファイルをアップロードしています。
でも、画像のサイズが大きいと、 InputStream#mark(0) not support って例外が発生するケースを発見。
この辺どうにかしなきゃな。。
以下、そのあたりのコードです。

public ILargeObjectImage add(InputStream inputStream,
ILargeObjectImage iLobj) throws SQLException {
Connection conn = getDataSource().getConnection();
conn.setAutoCommit(false);
int oid = 0;
if (iLobj.getContentType() != null) {
if (iLobj.getContentType().equals("image/pjpeg")) {
iLobj.setContentType("image/jpeg");
}
Iterator iter = ImageIO.getImageReadersByMIMEType(iLobj
.getContentType());
if (iter.hasNext()) {
ImageReader reader = (ImageReader) iter.next();
try {
inputStream.mark(0);
ImageInputStream iis = ImageIO
.createImageInputStream(inputStream);
reader.setInput(iis, true);
iLobj.setWidth(new Integer(reader.getWidth(0)));
iLobj.setHeight(new Integer(reader.getHeight(0)));
inputStream.reset();
} catch (IOException e) {
conn.rollback();
throw new SQLException(e.getMessage());
}
}
}
try {
long image_id = SQLOptions.getNextId(conn, getSequenceName());
iLobj.setImageId(new Long(image_id));
iLobj.setFlags(Boolean.TRUE);
oid = addLargeObject(conn, inputStream);
iLobj.setOid(new Integer(oid));
addMaster(conn, iLobj);
conn.commit();
return iLobj;
} catch (SQLException e) {
conn.rollback();
throw e;
} finally {
DbUtils.close(conn);
}
}

もうちょっとリファクタリングしたいな。。ていうか、仕事しよ(汗)

JavaMail + velocity + ActionForm で「〜」が文字化け

Struts で メールフォームを作って、 velocity を使ってメールの本文を生成、 JavaMail で送信という処理をする際、 Windows から入力した 「〜」などの一部の特殊記号が文字化けしてしまうことがあります。
ちなみに、エンコーディングは、 Java や JSP、velocity のテンプレートがすべて utf-8、メールは iso-2022-jpです。
Mac からの入力は問題なし。
Windows から入力された「〜」等の一部の特殊記号は、 Windows-31J のエンコーディングで送信され、 Servlet で utf-8 に変換、 JavaMail で MimeMessage に入力する際、 iso-2022-jp に変換されます。
このとき、 Windows から入力された「〜」の character code は、 iso-2022-jp や、SJIS、EUC での「〜」である、\u301c とは違い、 \uff5e であるため、コード変換が出来ずに文字化けしてしまいます。

参考 – Javaの日本語関連コンバータにおけるマッピングの違い

http://www.ingrid.org/java/i18n/encoding/ja-conv.html
この問題を対処するため、 Windows-31J や MS932 といったコードで入力した際、文字化けを起こす特殊文字の character code を iso-2022-jp や EUC で使用されている character code へ変換するメソッドを作りました。

public static String winToJIS(String input) {
StringBuffer sb = new StringBuffer();
char c;
for (int i = 0; i < input.length(); i++) {
c = input.charAt(i);
switch (c) {
case 0xff3c: // 「\」 を変換
c = 0x005c;
break;
case 0xff5e: // 「〜」を変換
c = 0x301c;
break;
case 0x2225: // 「‖」を変換
c = 0x2016;
break;
case 0xff0d: // 「−」を変換
c = 0x2212;
break;
case 0xffe0: // 「¢」を変換
c = 0x00a2;
break;
case 0xffe1: // 「£」を変換
c = 0x00a3;
break;
case 0xffe2: // 「¬」 を変換
c = 0x00ac;
break;
}
sb.append(c);
}
return sb.toString();
}

これで文字化け解消です。

2008-03-23 追記

古い記事で恐縮…
はてなとリンクするテスト.
http://d.hatena.ne.jp/nanasess/20080323/1206255766