2009年を振り返って

2009年はいろいろと手を広げすぎてJindolf本体の開発スピードがずいぶん落ちました。いろんなことがあった年でしたね。それではいってみよー。


Javaベンダ各社の動向

とうとう2009年中にJavaSE7(Dolphin)は出ませんでしたね。正直、あまり動向は追ってません。後方互換性の観点からは、これといってJindolfのコンパイル/実行に悪影響を及ぼしそうな変更はなさそうに思われます。少なくともあと3年ぐらいはJLS3(JDK1.5でコンパイル可能なJava言語仕様)の文法のみを使ってJindolfの開発を続ける予定です。

多くの方がSun Micro Systems(以下、Sun)製のJREを使ってJindolfを動かしていると思います。そんなSun社が、IBMではなくOracleに買収されることがほぼ決定しました。MySQLの話はさておき、今後のJavaアプリ界隈はどうなるのでしょうか。JCPの運営もそこそこ機能しているようですし、この機に乗じて大手ベンダが昔のMicrosoftのような暴走を繰り返して消費者に混乱をもたらす可能性は薄そうです。今回の買収騒動はJindolf利用者にとっての不安材料ではないと認識していますが、どんなもんでしょ。

MacOSXの新版「SnowLeopard」のリリースとほぼ同時期に、念願のMac用1.6系JREがAppleからリリースされました。ただしIntel64系CPU搭載機用のリリースのみのようです。PowerPC用の1.6系JREをリリースしないのはともかく、なぜIA-32系CPU搭載機に1.6系JREをリリースしない/できないのか、その辺の事情はよく解りません。サーバー用途以外のJava利用から手を引きたがっているのか、OpenJDK系のオープン実装への緩やかなシフトを目論んでいるのか、はてさて。

Sun提供の1.5系JRE実装がEOSL(End of Service Life)を迎えました。重要なバグがあってももう直さないよ、ということのようです。Jindolf利用者にJREバージョンアップを促す説得材料にはなりそうです。最初の1.5系JREリリースが2004年で、それから5年が経ちましたか。Apple社の動向もアレだし、まだ当分の間1.5系JRE利用者を切り捨てる決断は下せそうにありません。JindolfもリフレクションAPIなどを用いて、Webブラウザ連携などの1.6系JREに依存した機能を少しずつ増やしているわけですが。未だに1.4系JREを見捨てないV2CとかのJavaアプリは立派なのです。

動画デモ作成

Jindolfのデモ動画を作ってみました。動画の編集自体初めての経験です。知らないソフトを知ってもらう動画である以上、視聴にログインが必要なニコニコ動画とかは再生ボタンを押してもらうまでのハードルが高いので、気軽に視聴できるYouTubeを配信に利用させてもらいました。

尺を3分以内に納めることは最初から目標として決めていました。YouTubeは動画サムネイル片隅に再生時間が表示されるので、ここを2分台に収めておけば、なんとかクリックしてもらえるんじゃないかと。

Google社のデベロッパ向けビデオレターみたいに、ぶつぶつしゃべりながらマウス操作を録画していけばいいかーとか気楽に考えていました。が、とても視聴に耐えないものができあがりそうになったので、慌てて絵コンテを書くことに。絵コンテ見ながらGUI操作のリハーサルを何回か繰り返さないと、もうほんと見ててイライラする動画ができあがります。ほんの1分前に自分が行ったGUI操作のリプレイ見てるだけで、かなり見苦しいです。

Windows上のGUI操作の動画キャプチャにはCamStudioを、編集ソフトにはAviUtlVirtualDubModNiVEなどのフリーソフトを利用しました。ハイビジョン級ロスレス圧縮動画を編集する用途には、WinXP付属のMovieMakerやMacOSX付属のiMovieは若干力不足だったような。AdobePremiereが使えるネットカフェとかがあれば利用したかったのですがー、見つからんかった、残念。動画CodecにはCamCodecロスレス圧縮を使っています。秋に作業機を64bit環境に移行したのですが、CamCodecを入れる方法が解らず未だ手探り中。これは困った。いざとなればHuffyuvか何かで作り直すかー。

BGMは、ウケ狙いでウルフギャング氏作曲のトルコ行進曲とかフリー素材で探してたのですが、隣接権関係の確認とかが意外に面倒なのです。そんな訳もあり、10年前に購入したループ音源引きずり出して、フリーのループシーケンサーACID ExpressでオリジナルBGMを作曲しました。3分のBGM制作に、120bpmで100小節近くもMIDIシーケンサで作曲するとか、もう絶対無理ですので。 開始早々8秒でチャンネル不足によりアンサンブルが破綻、突然トランスミュージック風に路線が変わるのはご愛敬。キーがAから突然Dに変わってたとか後で気づいたけど気にしない。

できるだけ動画を最後まで見てもらえるよう、動画を8つのパートに分けて、今どこまでパートが進んでるのか視聴者に伝えるクリップを随所に挿入していたりします。

タイトル画面にグラデーションがかかっていたり、イントロのシンセベースで音源定位をいじっていたりするのは、再生画質や音質を手っ取り早く確認するための工夫だったりします。

Web上のサービスの展開

以前から人狼BBSがらみのWebサービスを立ち上げたいとは思っていました。なるべくなら手慣れたJavaで。がしかし、サーバサイドJava環境を格安で利用できるレンタルサーバはなかなか無いのですよね。そんな理由もあり、PHPとかPerlとかRubyとかを習得してJindolfのパーサ部分を移植しようかなと計画していた矢先、Google社がGoogle App EngineのJava版サービス開始を発表。すかさず初回アカウント募集になんとか潜り込みました。

慣れないWebプログラミングでしたが、なんとか進行中の村の状況を表示するWebサイト「JinXML」の運営開始にこぎ着けました。カウントダウン表示のためJavaScriptを書いたのも今回が初めてだったりします。

Atomによる村状況のフィード配信も始めました。GoogleReaderでフィードを購読している人は私を含めたったの3人。他の手段で読んでいる人がこの数倍いるとしても、思ったより需要無いのかなー。プログラムに自動解釈させることを前提にした、XMLによる村状況配信も開始。siro氏のTwitterBot「よあ☆ぼと」の運営のお役に立てているようです。JavaScriptプログラマ向けにJSON配信とかもした方がいいのかしら。

2010年1月1日から著作権法が改正されます。よそ様のサイトをサマライズするサービスなどが運営しやすくなるのではと期待しています。JinXMLでも、もう少し個々のプレー状況に立ち入ったWebサービスを展開するかもしれません。人狼BBSサーバの負荷軽減のため、Jindolfが将来これらのサービスにアクセスすることもありえます。

ライブラリ分離

クラス総数が100を超えてきたこともあって、他のプロジェクトにも融通が効きそうな箇所をライブラリとして独立させることにしました。各国や各キャラクタの基本状況の定義にアクセスするための「JinCore」、人狼BBSサーバから送出されるXHTML文書をパースするための「JinParser」の二つです。

Jindolf本体へのライブラリの取り込みはSubversionの外部参照機能に依存しています。SubversionからMercurialへの移行になかなか踏み切れないのは、この外部参照機能の有無が原因だったりします。そろそろMavenとかによる構成管理を考えたがいいのかも。

Java用の非コピーレフトなJSONライブラリを探しているうちに、いつのまにか自分で作ってしまいました。もうすこし洗練させたらこれも独立化させる予定です。

これらの独立ライブラリをJindolf本体と間違えてダウンロードしてしまう人がいないか、少し心配だったりします。近日中に新プロジェクトとしてSourceForgeに申請を出すかも。

Jindolfスピンオフの登場

hamuhamu氏がJindolfの改造バージョンGrayJindolfのリリースを開始しました。MITライセンスにもかかわらずソースコードも公開してもらっており、オリジナルJindolfへのコードのフィードバックに関しても好意的な言葉を頂いているのですが、ちっともオリジナルJindolfへのマージがはかどっていません。

結局現時点では、オリジナルJindolfがリリースを出すたびに毎回GrayJindolf側で変更差分をマージしてもらっているような形になっています。その中には、hamuhamu氏がGrayJindolfで初めて実現した機能をわざわざオリジナルJindolf側で再発明した形になってしまったものも含まれています。ひとえに私のSCMオペレーションやコードリーディングのスキル不足によるものでしてー、心苦しい限りです。

Subversionのブランチやマージをまじめに勉強し直すか、とっととMercurialのような分散型SCMに移行するか、いろいろと思案しているところです。

プロジェクトのフォーク開始に伴い、いくつかの案件を前倒しで最優先に片付けることになりました。まずはクレジット表記周りの管理を簡素化して独自表記に変更しやすくしたのが一点。あとは各種設定ファイル保存の場所を統一させることでした。これ以上Jindolfを拡張するにあたって、ファイルによる設定保存は避けて通れない道であり、このファイルの格納先仕様までフォークし出すと利用者に混乱をもたらしかねなかったので。

共通アーカイブ基盤整備計画の立ち上げ

XMLを核とした、人狼BBSのプレイデータの交換、加工、分析を盛り上げる計画「共通アーカイブ基盤整備計画」をまとめサイト内に勝手に立ち上げました。

XML Schemaによる村記述のボキャブラリ設計に結構手間取りました。XML SchemaなんてDTDをXMLで焼き直したもんだろぐらいの認識で始めましたので…。

Jindolfから分離したJinParserライブラリを用いて、1つの村の出来事をXMLファイル1つにまとめるアプリケーション「JinArchiver」を開発しました。これも将来Jindolfプロジェクトから独立させる予定です。

なぜかIXを介さずに人狼BBSサーバにアクセスできる秘密のサーバを利用できる状況にありましたので、古国からF国1999村までの全村の全発言をXHTML生データで保存する作業を開始しました。curlを使って1村ずつダウンロードするシェルスクリプトを、3~5分に一度起動することにより、数週間かけて全生XHTMLデータ(6.7GByte)のダウンロードを完了させました。F2000村以降は、100村の区切りごとに自宅のマシンからJinArchiverを用いて発言データをダウンロードしていく予定です。

現時点において、XML化した村データはZIPアーカイブで1GByte弱あり、これが今自宅のハードディスクとDVD内に収められています。これを使って何かWebサービスを始めたくても、なかなか低コストでストレージ1GByteを提供するレンタルサーバが無いのですよね。

XQueryによる各村の統計分析をいざ始めようとしてるのですが、IBMのDB2お試し版eXists等の無償XMLデータベースの使い方を覚えるのに四苦八苦しています。

大量の発言データをMeCabなどを使って形態素解析する取り組みも始めました。人狼界隈独自の用語用に辞書を整備する必要が出てきそうです。

サーバの仕様変更

5月某日、F1945村の消失と前後してF国サーバのXHTML上の時刻表記が変わったために、2.18.2版以前のJindolfが一斉に動かなくなりましたが、急遽2.19.2版をリリースすることにより、12時間以内に対処することができました。たまたま早く気が付くことができたのは運もあるので、次回も早期の対処が可能かどうかはあまり期待しないでね。まとめサイトの出張所かSourceForgeのチケットで報告してもらえれば、早めに気づくかも。

初めてダウンロードした時のJindolfを古いバージョンのまま使っていた方は結構いたようですので、この件で一気にバージョンアップを進めてもらうことができ、Jindolfは今もバージョンアップを繰り返しているソフトであることを認知してもらえたのは収穫だったと思います。

年末に過去ログ提供サーバの集約およびURL変更が行われました。こちらの件はninjin氏により数ヶ月前からアナウンスがあり、新旧サーバがしばらくの間ミラー運用されていました。おかげさまでJindolf側でもシームレスに対処することができました。JEではちょっとした混乱があったようですが、早急にパッチが出回り落ち着いた模様です。

バージョン3への移行

Jindolfは初リリース以降、CSVエクスポート機能などの例外を除き、ローカルファイルへの書き込みをあえて行わない方針を貫いてきました。知名度も信用もゼロのソフトを何とかして試してもらうには、「一切ファイルに書き込みません」というアピールが有効ではないかと考えた上での戦略的判断です。

この方針のために、設定保存ファイルがないと事実上使い物にならないような改善要求を、未解決のままだんだんと抱え込むようになりました。

発言表示フォントのサイズ指定など、どうしても復元が必要と思われる設定に関しては、Javaアプリのコマンドラインオプションによる対処も用意していました。ですが、「java.exeの-jarオプションの前後ではオプション指定の意味ががらりと異なる云々」とかパソコン初心者に理解してもらうのは、ホント大変なのですよね。という訳で、これ以上コマンドラインオプションに頼るつもりはあまりないのです。

初回リリースから年月も経ち、皆様のおかげで人狼コミュニティでの認知度もそこそこアップしましたし、そこそこ格好の付くダウンロード数も得られるようになりました。 そんな事情を鑑みて、今回メジャーバージョンを心機一転「3」に上げるとともに、ローカルディスクへの設定保存に踏み切ることになりました。

最終的には、GrayJindolfなどのスピンオフプロジェクトの登場が背中を押してくれた形になったでしょうか。スピンオフプロジェクト間で設定保存ディレクトリの位置がバラバラとかいう事態はなんとしても避けたかったので。

SourceForgeでの活動

共通アーカイブ基盤整備計画とかに脱線したため、Jindolfの開発ペースは去年に比べ明らかに落ちており、SourceForgeの短期ランキング上位からは外れるようになりました。ただ、長期に渡ってぽつぽつと開発を続けていることが影響してか、年間ランキングではまだ上位に位置しています。オープンソース作者って、意外とみんな短期間で放り出しちゃうのかしら。

SourceForgeでもMercurialのリポジトリサービスが開始されました。複数の外部ライブラリを1つのソースツリーにマージするオペレーションさえ習得できれば、SubversionからMercurialに移行する気まんまんなのですが。MercurialにSubversionの外部参照に相当する機能が無いのは残念。Mavenと併せてなんとかできないか勉強中です。

ダウンロードページにはJindolf以外にもJindolfから派生したライブラリなどが置かれているのですが、Jindolf目当てに訪れた初心者が間違ってこれらのライブラリをダウンロードしに行ってないかが心配です。せめてプロジェクト管理者の手で表示順を指定できればいいのですが。別プロジェクトを申請して、近日中にこれらの派生ライブラリを移動させる予定です。