歪

■ [Squeak] 長いセレクタ名

長いプロパティ名の話題を見て、sumimさんのこれを思い出した。

今見たらちょっとバージョンが古かったので、SeasideJOnePlusDBの最新のをダウンロードしてきて試してみた。

(Symbol allSymbols asSortedCollection: [ :a :b | a size > b size]) first

=>  #initializeWithName:superclassName:traitComposition:classTraitComposition:category:instVarNames:classVarNames:poolDictionaryNames:classInstVarNames:type:comment:commentStamp:

173文字。さすがSqueak。Monticelloに入ってるMCClassDefinitionクラスのもの。Monticelloが素のSqueak入ってるのかどうかは知らない。いまどきは入ってるのかな？。

ちなみにSeasideJOne初めて触ったけど、拍子抜けするぐらい簡単に試せていいですね。

■ 最近

会社で開発者ブログをはじめました。

プライベートネタはmixi、適当なひとことはtwitterで、技術系ネタをそっちにもってくと、ここに書くことが無いのねぇ。PDF関連の話も、この先はお仕事との境が微妙になってくるので、ここには書きにくい。それでちょっと放置気味です。ごめんなさい。

ところで会社のブログはWordPressにしたんですが、いいですね、アレ。あのお手軽拡張感覚は良い。PHPがちょっと好きになった。いくら拡張性を高くしたって、小綺麗なインタフェースを用意したって、ユーザが拡張したくならなきゃ意味がない。WordPressはユーザに拡張することをアフォードしてるし、それはWordPressがPHPで書かれていることと無関係ではないと思う。

■ [PDF] Hello, World!

だいぶ間が空いてしまったけど、PDFのお勉強再開。前回までに基本的な文書の構造を勉強したので、これからはいよいよ描画系をやっていこうと思う。

まずはお約束のHello, Worldだ。

HelloWorld.pdf

文書カタログとページツリーのルート、相互参照表、トレーラについては、基本的な構造で書いたのとほとんど変わっていないので説明は省略する。

3 0 obj
<<
  /Type /Page
  /Parent 2 0 R
  /Contents 4 0 R
  /MediaBox [ 0 0 100 120 ]
  /Resources
  <<
    /ProcSet [ /PDF /Text ]
    /Font << /F1 5 0 R >>
  >>
>>
endobj

4 0 obj
<< /Length 54 >>
stream
BT
  /F1 12 Tf
  10 100 Td
  (Hello, World!) Tj
ET
endstream
endobj

5 0 obj
<<
  /Type /Font
  /Subtype /Type1
  /BaseFont /Helvetica
>>
endobj

■ 自戒

• ツールに溺れるな。ツールの導入が目的じゃなかったはずだ。高度な統合と自動化をめざすより、メッセで会話しろ。
• テストを重視しすぎるな。仕様という名のテストを書くことが目的じゃなかったはずだ。テストより大事なのは動作するソフトウェアだ。
• 要望を見落とすな。受け入れテストに載ってないからといって、ユーザがそれを望んでいないわけじゃない。盾に使うのは最後の手段だ。
• 優先度の高い割り込みタスクを先にやれ。チケットの期限を守ることが、いつもユーザの利益につながるわけじゃない。変化を抱擁せよ。

■ [TestNG] JDK1.4

TestNGの現時点の最新のリリースは5.8だけど、このバージョンだとJDK1.4環境でテストが実行できない。これはIssue25で指摘されているとおり、Java5から追加されているメソッド（String#contains）がorg.testng.reporters.XMLStringBufferで使用されているから。

trunkですでに修正されている（r629）のだけど、現時点では最新のソースをビルドしても他の部分でひっかかってうまく動かなかったので、XMLStringBufferのクラスファイルだけ5.8の中のものと置き換えて、とりあえず対処した。

ちなみに最新のリビジョンでひっかかるのは、org.testng.reporters.EmailableReporterで、こちらもJava5から導入されたStringBuilderが使用されているから。報告上げたほうが良いのかしら。

■ [Java] javadocの@version

JavaSEのAPIドキュメントは、せっかく真面目に@versionを書いてあるんだから、これとビルド時のターゲットの指定を比較してチェックするツールとかあると便利そうだ。すでにあるかしら？

■ [Ant][Java][TestNG] TestNGの実行結果をメールする

AntでTestNGタスクを利用してテストを自動実行したら、その結果はメールで送るようにしておくと、メーラー上でテスト履歴が一覧できるようになって便利。 TestNGのレポートの出力には、「emailable-report.html」という、メールで読みやすいように整形されたHTMLが含まれているので、これを使用する。

 <!-- antcallでの呼び出し専用target -->
 <target name="test" if="initialized" depends="prepare" description="テストを実行し、テスト結果をメール送信します。">
     <!-- TestNG -->
     <testng classpathref="run.classpath" dumpcommand="true" verbose="3" outputdir="result/${module.name}" sourcedir="src" failureproperty="failed">
       <classpath>
         <pathelement path="${module.path}" />
         <pathelement location="bin" />
       </classpath>
       <xmlfileset dir="." includes="${module.test}" />
     </testng>
  
     <!-- 失敗したらメールサブジェクトに「FAILED!」を入れる -->
     <condition property="subject" value="TestNG - ${ant.project.name} with ${module.name} Module (${os.name}/${os.arch})  - FAILED!!">
       <isset property="failed" />
     </condition>
     <condition property="subject" value="TestNG - ${ant.project.name} with ${module.name} Module (${os.name}/${os.arch})">
       <not><isset property="failed" /></not>
     </condition>
 
     <!-- メール送信 -->
     <mail mailhost="${mailhost}" from="${mail0}" tolist="${mail1}" subject="${subject}" encoding="plain">
       <message src="result/${module.name}/emailable-report.html" mimetype="text/html" />
     </mail>
 </target>

■ [Ant][Java] cobertura-reportの文字化け

Cobertura1.9のAnt用タスク「cobertura-report」は、ソースファイルがUTF-8であることを前提にしているので、Windows環境でShift_JISなんかで書いてたりするとレポートが文字化けする。

ぐぐってみると、日本語対応パッチを書いてらっしゃる方も見つかるのだが（1/2）、ソースがそんなに多くないならUTF-8で一時的にコピーを作っちゃうと楽。Ant1.6以上ならcopyタスクでoutputencodingを指定できる。

<copy todir="${utf8src}" encoding="Shift_JIS" outputencoding="UTF-8">
  <fileset dir="${src}">
    <include name="**/*.java" />
  </fileset>
</copy>
<cobertura-report format="html" destdir="${coverage}" srcdir="${utf8src}" />

■ [BDD] 揮発性

昼飯を食べながら、「揮発性BDD」というのを妄想してみた。

• リリースと同時に消えてしまう儚いSpec/Story。（ツールがxUnitとかなら、消えるのはTestという名の仕様）。
• テストデータの可搬性とかは、BDD中は一切無視。自分とこで動けば充分。定数埋め込みでオッケー。データ重複おかまいなし。どうせ消えちゃうんだから。

そのかわり、

• Spec/Storyは消えちゃうので、リリース後もちゃんとメンテナンスを続けるつもりがあるなら、リリースまでにテストを書き起こさなければならない。
• このテストは回帰テストとして後の開発で使用されることを念頭に、きちんと設計する。シンプルかつ充分なテストデータを用意する。ドキュメント化する仕様はドキュメント化する（これはBDDツールからの出力でもいいかも）。

これは、

• BDD中にテストデータの使いまわしとか卑しいことを考えて、フットワークが落ちるのを防止する。
• 天変地異かよってぐらいの仕様変更が起こったときに、無駄になるものを最小限に抑える。

という効果が期待できると思うのだけど、どうかしら。

■ 結合テスト

当たり前だけど、真面目にユニットテストをやるほうが、モジュールの信頼性は上がるし、結合してから問題は起きにくい。 結合してからのテストが、真面目にユニットテストをやらない場合よりも圧倒的に楽になる。

逆に言えば、真面目にユニットテストをやらないほうが、結合テストを真面目にやる傾向がある気がする。

これは、GUIのユーザビリティなんかに結構影響があって、何べんも結合テストで使っているうちに見えてくる問題点もあるんだよなぁと思う。 いってみればドッグフードを食べてる状態で、リリースまでに改善できる部分がより多くなるんではないか。

■ [Java][Squeak] Javaで5000行以下のSqueakインタプリタ

Weekly Squeakの記事「JSqueak - Smalltalk interpreter written in Java」経由で、JSqueak。実は2006年ぐらいからあったらしい（=>大島芳樹のカリフォルニア日記 - DanのSqueak on Java )。

ちょっとだけ触ってみたけど、これが5000行以下のコードで動くってのはすごいと思った。Java Web Startで、ブラウザからクリック一発で試せるのもうれしい。

今は冗談抜きで忙しすぎるので、落ち着いたらちゃんとコードを読んでみよう。