デブサミ壇上リリース Jiemamy v0.3.0

Jiemamy event

昨日一昨日と、デブサミ2011だったわけですが、Jiemamyはそのキックオフセッションを担当させていただき、Jiemamyの新バージョン v0.3.0 を発表しました。壇上の回線をつかって、リリースさせて頂きましたｗ 昨日一昨日はぐだぐだに疲れていたのでご報告が遅れましたが。以下セッション資料。

DevelopersSummit2011 【17-E-1】 DBも変化せよ - Jiemamy

Jiemamyも、もうすぐ4歳なんすね。この間、なかなか思うように作れず、作っては壊しで3回目です。各バージョンを一言で表せば、v0.1系は未熟な構成、v0.2はやり過ぎ黒魔術、v0.3は鉄壁の正統派、というイメージですね。

ソフトウェア再利用の神話―ソフトウェア再利用の制度化に向けて (Professional Computing Series)

ソフトウェア再利用の神話―ソフトウェア再利用の制度化に向けて (Professional Computing Series)

出典は今ググって知ったのですが、「ソフトウェア再利用の神話」という本には「再利用可能なソフトを開発するには，3回は作り直す必要がある」と書かれている*1そうです。…確かに。本当にそう思います。3度目でやっと、バランスの取れたものが作れたなぁ、と思っている次第です。

今後は「書いては壊し」を（やっと）やめて、プロダクトの機能拡大*2と品質向上の路線を進む所存です。

v0.2系から何が変わったの？

Jiemamy Eclipse Pluginから見ると「少々のUI変更」にしか見えません。maven-jiemamy-pluginから見ても、pomに書く設定が少々変わったな、という感じだと思います。v0.3になって変わったのは裏側の世界で、表向きはあーんまり変わってないのです。それでいいんです。

ただし、データファイルのXML形式（スキーマ）は変わり果ててしまいました。XMLの進化的設計ェ…。

あ、あとv0.2にあった「ドメイン」と「インデックス」の機能がありません。デブサミには間に合いませんでしたが、近々に整備して追加します。ドメインは我慢すれば何とかなります。インデックスは「終了スクリプト」あたりで対応できると思います。

なぜ裏側を変えたのか？

建物を建てるのにたとえて。v0.1ではプレハブ小屋ができました。しかし、作っているウチに「…欲しいのはもっとでっかい建物だな＞＜」ってのが分かってきました。これ以上プレハブ小屋を増築できませんでした。

そして作り直してv0.2。インテリジェントビルの1Fができあがりました。高機能なのはいいんですが、高機能なりの不安定さと固さがあり、柔軟性に今ひとつ欠ける結果となりました。

ということでv0.3。無垢材を使って昔ながらの「百年住める家」が出来た感じです。やっと基礎に納得がいき、これから続くメンテナンスに耐えうる基礎だと感じられました。この上に、さらなる機能を組み立てていけます。

簡単に新バージョンへのアクセスパスを紹介

プロダクトの詳細はあらためて順次書いていきますが、以下にダイジェスト。適当ですんません。これじゃあ「分かってる人」にしか伝わらないのは分かってますｗ ドキュメントの整備も（id:regtanを中心にｗ）進めていきますね。

【Jiemamy Eclipse Plugin】
更新サイト http://eclipse.jiemamy.org/release/

Jiemamyインストールガイド

まずはプラグインを触ってみましょう。インストールしたら、新規ウィザード（CTRL+N）から「Jiemamy ER Diagram」を選び、作成先を選びます。そするとエディタが開くので、エディタ右端にあるパレットを開き*3ます。

背景部分を右クリックして「プロパティ」を選ぶ*4と基本設定画面が出てくるので、ここでDBなんかを選びます。

あとは直感でいけるはずです。

【maven-jiemamy-plugin】

まずはチュートリアルをチェックアウトして、様子を見てみましょう。いつも私がセッション中にデモする奴です。

http://svn.jiemamy.org/products/metis/jiemamy-tutorial/tags/jiemamy-tutorial-0.3.0/

m2eclipseが必要なので、インストールしておいてください。で、あとはREADME.txtを読めばできるはずです。

【Jiemamy API】

相変わらず、APIもありますよ。

Maven repository http://maven.jiemamy.org/release/
groupId org.jiemamy
各artifactId jiemamy-core, jiemamy-sql, jiemamy-diagram,
jiemamy-diagram-mysql, jiemamy-diagram-postgresql
各version 0.3.0
【裏技】

前述の通り、API以外はv0.2.0とあんまり変わっていません。どうしても急ぐ方は、v0.2.0のドキュメントを見てしまうのも一つの手です。v0.2.0のドキュメントは意外と頑張って作ってます。v0.3.0も同じようなドキュメントを提供する予定。

http://docs.jiemamy.org/release/0.2.0/

質問・バグ報告など

何かありましたら、

あたりで。個人的には上の方の選択肢ほど嬉しいですｗ

*1:3回作ればいいのか、3回作り直すからトータル4回なのか…。まぁ、そんな話じゃないと思いますがｗ

*2:肥大じゃないすよ。目的としている機能はまだ色々あるのです。

*3:上の部分にある△をクリックすると開きます。

*4:この時、テーブル等のノードが選択状態になっていない状態にしてください。

デベロッパーズサミット2011に登壇します

etc event

ご無沙汰してます。何をしていたかというと、Jiemamy作ってました。意外と形になってきていますが、まだちとバグがあるかな、という状況です。（αテスター募集中！ 詳しくは @daisuke_m に@なりDなり）

で、ですね。デブサミでJiemamyについてお話させて頂けることになりました。枠番は17-E-1です。Jiemamy Projectでは、このデブサミに合わせて新バージョン(v0.3.0)のリリースを予定しています。新バージョンのご紹介をいち早くお伝えできることを嬉しく思います。

http://codezine.jp/devsumi/2011/

初日の朝一のセッションですが、もしよろしければ会場までお越し頂ければと思います。

# 新春一発目に「MacbookAirが欲しい」とかエントリを投げつつ放置しすぎでしたすみません。

互換性維持とリファクタリング

etc

互換性とは

ソフトウェアは、広く使われれば使われる程、互換性が大事になってきます。ここでは、ソフトウェアライブラリ・フレームワーク等の互換性を考えてみまよう。互換性は以下の2つに分けて考えることができるようです。

  • 上位互換性：ライブラリのバージョンを新しくしても、このライブラリに依存したソフトウェア（クライアント）が正しく動くこと
  • 下位互換性：ライブラリのバージョンを古くしても、このライブラリに依存したソフトウェア（クライアント）が正しく動くこと

ライブラリ等のバージョンにおいては、古いバージョンに切り替える機会よりも、新しいものに切り替える機会（とモチベーション）の方が多いため、一般的に上位互換性の方が重要視されます。（ただ、Excel等のアプリケーションが吐き出すデータファイルは、下位互換性が求められることも多いです。つまり、Excel2000で作ったデータはExcel97でも読める、等）

互換性が重要なケース

広く一般に使われるライブラリ（API）は、なるべく上位互換性を維持しようと務める必要があります。例えば、commons-langが互換性を失ったら、バージョンアップした時に、かなり多くのクライアントが壊れるでしょう。

ちなみに、commons-httpclient は、v4系のリリースのタイミングで、互換性を捨てました。v3系を使って組んだアプリケーションはv4系にバージョンアップするのに大きなコストが掛かります。まぁ、互換性が重要とは言え、一定のタイミングで互換性を捨てる、という作戦もあるのです。これは「技術的負債の返済」とも言えるでしょう。

そして仮に、Java自体が互換性を失ったら、もっと大変なことになります。従って、Javaは「上位互換性を大事にしている」と言われています。Java1.0時代に書いたコードやコンパイルしたクラスが、Java6でも普通にコンパイルできる・実行できるのは、互換性が最大限に考慮されているからです。「バージョンを上げても壊れない」という実績の積み重ねが信用につながり、これがJavaの利用領域拡大に一役買っているのは間違いないでしょう。

互換性が重要ではないケース

しかし、互換性を維持する、というのはコストのかかる作業です。例えば、一度リリースしたライブラリについて「このクラス名、よくなかったなー。名前変更のリファクタリングを掛けよう」ということは、おいそれと出来なくなるのです。名前が変わったら、クライアントのコンパイルは通らなくなりますからね。

そんなわけで、個人的に使うようなライブラリや、特定の狭い範囲のみで使うことを想定したものであれば、互換性はそこまで重要視されません。というのも、バージョンを切り替えた結果、クライアントが正しく動かなくなったとしても、それに対応するようにクライアント側を修正すれば済むからです。また、範囲が狭ければ狭いほど、なぜ互換性を失ったのか、どのように直せばいいのか、というナレッジが共有しやすい為、という理由もあります。

このように「互換性の維持（＝信用の積み重ね）」と「リファクタリング（＝設計の改善）」はトレードオフです。そのソフトウェアの性格や、開発方針、リファクタリングの重要度等を検討して、互換性を維持するかどうかを決定しなければいけません。

Jiemamyはどっちだ？

いやー、Jiemamyでも長い間「互換性維持」を意識してきました。しかしまぁ、毎度のバージョンアップで「ごめんなさい、やっぱり互換性維持はできませんでした」ということになるのですが。最近は気持ちを切り替えています。Jiemamyの本質はバージョン互換（安定したAPI）ではなく、開発プロセスにあることを再確認しています。だから、互換性を意識しすぎて開発が進まないのは、ちょっと本末転倒だったな、と。こだわりすぎるのも良くない。

という気持ちで。現在新しいAPIを鋭意開発中です。

baseunitsはどっちだ？

逆に、baseunitsに関しては「互換性維持」は重要なことだと思っています。APIを広く使ってもらいた、と考えていますし、初期から「安心して広く使ってください」と喧伝しているプロダクトです。厳しく考えれば、「MavenのgroupIdを変更する」だけでも、見知らぬ誰かのプロダクトを壊すことができるんです。

というわけでbaseunitsでは、このようなことがないように、以下のポリシーに従います。

  • 一度リリースしたバージョンは、その内容を一切変更（修正）や削除（公開停止）しない。
  • なるべく互換性を失わないバージョンアップを心がける。
  • 互換性を失う場合は、@Deprecated等で事前に警告する。
  • 互換性を失うタイミングはメジャーバージョンアップのタイミングに限る。


つまり、こちらは名前の変更などよりも、互換性が大事なプロダクトです。余程のことがない限り、互換性の維持に努めます。安心してご利用ください。

UnsupportedOperationExceptionと相続拒否

Java オブジェクト指向

昨日ご紹介したbaseunitsですが、そのコードを社内コードレビューに掛けた際、id:cobonasからこんな指摘がありました。

package jp.tricreo.baseunits.util;

import java.util.Iterator;

/**
 * 明示的に、対象のコレクションに対する操作ができないことを表す反復子。
 * 
 * @param <T> 要素の型
 */
public abstract class ImmutableIterator<T> implements Iterator<T> {

    @Override
    public void remove() {
        throw new UnsupportedOperationException("sorry, no can do :-(");
    }

}

https://github.com/tricreo/baseunits/blob/master/src/main/java/jp/tricreo/baseunits/util/ImmutableIterator.java

これって「相続拒否」的な話ですかね？あんまりよろしくないとどこかで見た気がする。

続きを読む

Baseunits Library

Java DDD

さて、Java Advent Calendar -ja 2010 : ATND 10日目。昨日は、id:yuroyoro でした。二日連続で真っ黒な魔術が紹介されたので、ここは真っ白で実用的な奴をひとつ。

最近Domain Driven Design（DDD）っていう設計手法が、自分の周辺一部で話題になっている。当然、賛否両論なんだけども*1、個人的には好きな考え方でして。ま、詳細は色々な方がブログに書いているので割愛します。興味あれば本読んでみましょう。洋書*2だけどｗ

Domain-Driven Design: Tackling Complexity in the Heart of Software

Domain-Driven Design: Tackling Complexity in the Heart of Software


で、前置きはここまで。本題いきます。

Javaで「時間」や「日付」を扱う時、みんなどうしてます？ まぁ、大抵 java.util.Date とか java.util.Calendar を使うんじゃないかな、と思います。でもこのJavaの時間ライブラリっつーのは、意外とあちこちでdisられがちです。Deprecatedなメソッドだらけだし、Mutable(可変)だったり、継承関係が無茶だったり。まぁ正直使いにくい。

例えば2010年12月22日っていう暦日（日付）を扱いたいだけなのに、「2010/12/22 00:00.00 を java.util.Date で扱って時間部分を無視」とかしてませんか？ 時間要素のない、単なる「暦日(ex. 2010/12/22等)」クラス欲しくないですか？ 逆に日付要素のない、単なる「時刻(ex. 16:10等)」クラス欲しくないですか？ Immutable(不変)なクラスとか欲しくないですか？ 「期間(ex. 2010/09/20〜2010/12/22等)」とか「時間量(ex. 3分間, 4ヶ月間等)」クラス欲しくないですか？（ｒｙ

昔から、なぜApache commons-dateみたいなライブラリが無いのか、不思議でならんかった。まぁ今でも不思議だ。commons-langにDateUtilsってクラスがあって、少々便利なユーティリティを提供してくれているけど、まぁ全く根本的な解決になっていない感じ。

しかしまぁ、このイケてなさはJavaユーザの間ではほぼ共通認識ではあるようで。JodaTimeやら、それを元にしたJSR-310やらで、日時関連のAPIを整備しようという流れはあるわけです。ただ、このJodaTimeも結構曲者。いわゆる過モデリングなんだと思いますが、あらゆる可能性とニーズに対応しようとするあまり、通常は要らない概念がもりもり入っていて、まぁそれはそれで使いにくいらしい。使ったことないけど。

*1:正直、ヘビーウェイトな考え方だとは思う。

*2:訳本情報もあります。 http://twitter.com/#!/kohsei/status/17106115712000000

続きを読む

「区間」のソートあれこれ

etc Java

註：本エントリは等幅フォントで見ないと訳の分からない部分があります。Firefoxではきちんと見えるのですが、Google Chromeではなぜかmonospaceが等幅になりません…。というわけで、本エントリはFirefox推奨。SafariでもOKでした。IEは知らん。

さて、昨日の続きです。昨日は区間とは何かということを主に書いてきたのだが、今日はこれをどのようにソートしたらいいのか。あれこれ考えた結果、むしろ多分数学的に優位（有意？）なソートロジックってのは多分存在しないので、主観的にどれが一番理に適っていると感じるのかなぁ、というところをつついてみたい。

そんなわけで、解答はないので、ブクマとか※で、どれが一番イケてると感じたか*1、教えてほしいなぁ。今日は技術とか理屈の紹介じゃなくて、読者をアンケートに付き合わせて俺が考えを整理したいだけです、すみませんがお付き合いをば…。

*1:つまり、主観だ。

続きを読む