AntのGroovyタスクを使うときの俺流ベストプラクティス
G* Advent Calendar 2013の12/16担当、@nobusue です。
12/7に続き二度目の登場になりますが、引き続き実務に役立つシリーズでいきたいと思います。といっても、「ビルドはGradleで決まりだよね！」というイマドキの現場ではなく、いまだにAntでがんばっている(ちょっと残念な)現場の方向けです。
最近はMavenやGradleやsbtなんかの新興勢力に押され気味のAnt御大ですが、その安定感からいまだに「Ant以外認めない」という現場も多いと聞きます。(あくまで伝聞ですよ。。。)実際、要件的にはAntで十分というケースも多いでしょう。しかし、やはりAntで無理やりがんばるのはあまり得策ではないケースというのもままあります。例えば、
- テンプレートエンジンを利用して設定ファイルを動的に生成したい(単純なプロパティの置換ではすまない、もしくは日本語を含む文字列を置換したい場合など)
- 環境に応じて動的にビルドのロジックを切り替えたい(ファイルの有無や、プラットフォームの差異によって挙動を変えたい)
- ビルドの中でJavaのクラスを呼びたいが、わざわざカスタムAntタスクを作るのはめんどう
というような場合です。
わたしが今入っている現場では、まさに上記(1)のケースにヒットしてしまいました。(プロパティファイルにUnicodeエスケープした日本語を書いておくと、AntのCopyタスクのfilterでエスケープが解除されてしまい、そのままエスケープなしの状態でプロパティファイルが作られてしまう、、、というややこしい問題です。もう一回native2asciiすればいいんですけど、ダサダサですよね。)
というわけで、今回の内容は「いろいろ大人の事情でGradleに移行できないけど、せめてカスタムタスクぐらいはGroovyで書きたい」という人向けです。たいした内容ではありませんが、意外にまとまった情報がなかったのでまとめておきたいと思います。
AntのGroovyタスクとは?
GroovyのディストリビューションにはAntのカスタムタスクとしてGroovyタスクが内包されています。ですので、Antのクラスパスにgroovy-all-x.y.z.jarを追加し、ビルドスクリプトに以下の定義を追加すればGroovyタスクが利用できるようになります。だまって $ANT_HOME/lib 以下にgroovy-all.jarをぶっこんどくのがおススメです。
<taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpath="groovy-all-x.y.z.jar" />
あとは、以下のようにビルドスクリプト内でGroovyが使えるようになります。
<groovy><![CDATA[ ant.echo level:'info', message:'Hello groovy task!' ]]></groovy>
詳しくは、 The groovy Ant Task とか Antスクリプト内でGroovyを利用する あたりをご参照ください。
モジュール化してカスタムタスクっぽく使う
Groovyタスクは強力ですが、Ant以外受け付けない方に見つかるとお叱りを受ける可能性もあります。ですので、以下のようにしてGroovyコードの部分を隠蔽してしまいましょう。
呼び出し元:
<project name="main"> <import file="./buildUtil.xml"/> <target name="build"> <antcall target="complexTask"/> </target> </project>
呼び出し先(Groovyタスク):
<project name="util"> <taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpath="groovy-all-x.y.z.jar" /> <target name="complexTask"> <groovy><![CDATA[ ant.echo level:'info', message:'Groovy makes easier!' ]]></groovy> </target> </project>
GroovyにはAntBuilderという便利な仕組みが内包されており、Groovyタスクの中からAntタスクを呼び出すこともできますので、Antで用意されているファイル操作なんかはそのまま便利に利用しましょう。
パラメータを渡す
前出のようにモジュール化した場合、当然ながら「呼び出し元タスクからパラメータを渡したい」という要望が出てきます。これ、不思議とサンプルコードが見当たらないのですが、やり方は簡単で以下のようにするだけです。
呼び出し元:
<project name="main"> <import file="./buildUtil.xml"/> <target name="build"> <antcall target="complexTask"> <param name="sourcePath" value="./source"/> <param name="distPath" value="./dist"/> </antcall> </target> </project>
呼び出し先(Groovyタスク):
<project name="util"> <taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpath="groovy-all-x.y.z.jar" /> <target name="complexTask"> <groovy><![CDATA[ def sourcePath = properties['sourcePath'] def distPath = properties['distPath'] ant.echo level:'debug', message:"sourcePath: ${sourcePath}" ant.echo level:'debug', message:"distPath: ${distPath}" ]]></groovy> </target> </project>
要するに、呼び出し側で
ログ出力
汎用性の高いタスクができると、幅広く使われるようになります。そうすると、printデバッグではいずれ限界がきますので、早い段階でメッセージのログレベルをきちんと分けておきましょう。
実は既に小出しにしていましたが、
ant.echo level:'debug', message:"sourcePath: ${sourcePath}"
のように、AntBuilder経由でant.echoをログレベル付きで実行すればよいです。(Taskクラスのloggerを取得しようとしたのですが、どうもうまくいかないのでこの方法にしました。)
ログレベルを分けておくと、開発時はdebugを出力して、運用時はwarning以上のみ出力というような使い分けが可能です。ログレベルはAntのコマンドラインオプションで指定できますので、こちらなどを参考にいろいろためしてみてください。
まとめ
Antに疲れたらGroovyタスクで息抜きしましょう。
次は @nagai_masato さんです!
GroovyでGCログ解析: ちょっと扱いにくいフォーマットを処理するときのパターン
G* Advent Calendar 2013の12/7担当、@nobusue です。
今年は基本に返って、実務に役立つGroovyの利用方法をご紹介しようと思います。(というか実際に業務で使ったのですが。。。)
お題はGCログの解析です。
ここでご紹介するサンプルはOracle JDK7(HotSpot VM)が出力するGCログを想定していますが、仕組みはシンプルなので他のフォーマット(IBM JDK以外)にも多少アレンジすれば適用可能なはずです。
GCログを解析する場合、通常は侍やGCViewerなどのツールを使うことが多いですが、それでは対応が難しい要件もたまにあります。
例えば、「GCログが100本くらい取ってあって、それらを解析して最適なヒープサイズを見積もる」というようなケースです。いちいちGUIツールで一つ一つ開いてられないですよね。。。
そこでGCログをスクリプトで処理してやろうか、と思うのですが、GCログには以下のようなちょっと困った特徴があります。
- 一行で無理矢理情報を階層化しているので、フィールドの分割が単純にいかない
- 設定しているGCのアルゴリズムによってフォーマットがかなり変わる
- CPU負荷が高いとログが壊れてフォーマットが不正になる場合がある
特に3.が厄介で、こいつのせいでまともにパーサーを実装しようとすると例外処理が無駄に複雑になってしまいます。かといって、一行全体をパターンマッチングで処理しようとすると、ものすごく長大な正規表現が必要になり、デバッグに苦しむことになります。(というか実際苦しんだ。)
そこで、現実的なアプローチとして以下の戦略を採用します。
- 一行を区切り文字でおおざっぱに分割する
- 分割した各要素から、正規表現で必要な部分を取り出す
具体的なやり方は以下のようになります。
GCログ出力設定
まずは準備としてGCログを採取します。
JVMの起動時オプションに以下を追加してください。
-Dverbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
これで、JVM起動時のカレントディレクトリに gc.log が出力されるようになります。(+PrintGCDateStampsはJDK6以降でないと使えないので、JDK5以前の方は+PrintGCTimeStampsに変更してくださいね。)
GCログの具体的な出力は以下のようになります。
マイナーGCの場合:
2013-12-07T17:33:31.668+0900: 19.047: [GC [PSYoungGen: 26476K->6407K(30208K)] 59443K->40152K(74240K), 0.0631133 secs] [Times: user=0.20 sys=0.00, real=0.06 secs]
フルGCの場合:
2013-12-07T17:33:31.731+0900: 19.110: [Full GC [PSYoungGen: 6407K->0K(30208K)] [ParOldGen: 33744K->34259K(65024K)] 40152K->34259K(95232K) [PSPermGen: 40231K->39553K(65536K)], 0.1483206 secs] [Times: user=0.36 sys=0.00, real=0.15 secs]
GCログの1行をおおざっぱに分割する
GCログのフォーマットを眺めてみると、以下のような構造になっています。
2013-12-07T17:33:31.668+0900: 19.047: [GC [PSYoungGen: 26476K->6407K(30208K)] 59443K->40152K(74240K), 0.0631133 secs] [Times: user=0.20 sys=0.00, real=0.06 secs] 2013-12-07T17:33:31.731+0900: 19.110: [Full GC [PSYoungGen: 6407K->0K(30208K)] [ParOldGen: 33744K->34259K(65024K)] 40152K->34259K(95232K) [PSPermGen: 40231K->39553K(65536K)], 0.1483206 secs] [Times: user=0.36 sys=0.00, real=0.15 secs]
「Timesの部分は役に立たないので捨てる」という決断をすれば、1行を"["と"]"、および","で区切れば意味のある固まりに分割できることがわかります。
これをGroovyで実装すると以下のようになります。
def items = line.tokenize("[")*.tokenize("]").flatten()*.tokenize(",").flatten()*.trim()
flatten()が２回発生していますが、元のフォーマットが変態なせいですので我慢してください。
これで、「ヒープ領域ごとのMAXを取得する」という目的にかなり近づくことができました。
パターンマッチングで必要な部分を抜き出す
この前の作業で、
[PSYoungGen: 6407K->0K(30208K)]
みたいな文字列を切り出すことはできました。じゃあ、ここから"(30208K)"の数字部分だけ取り出すにはどうすればよいでしょうか？
良い子の皆さんは既にお分かりだと思いますが、正規表現を使うのが一番手っ取り早くお手軽だと思います。でも、いざ使うとなると、サンプルとか少なくて意外に悩みませんか?
こういう場合、私はいつも次のようにしています。
def s = "[PSYoungGen: 6407K->0K(30208K)]" def max = s.find( /PSYoungGen:.*\((\d+)K\)/ ) {all,m0 -> return m0}
何をしているのか簡単に解説します。
サンプルコード
第一引数としてGCログのファイル名を渡すと、
Young Max: 41472K Old Max : 65024K Total Max: 95744K Perm Max : 65536K Total GC pause time: 0.3325945 sec
みたいな感じで、ヒープの各領域のMAXを表示するサンプルがこちらになります。(フルGCが発生していないとOld/Permは取得できないので"0K"になります。そういう仕様なのでご了承ください。)
def srcFile = new File(args[0]) def youngMax=0, oldMax=0, totalMax=0, permMax=0 def totalPause=0.0 srcFile.eachLine{ line -> if( line =~ /^\d\d\d\d-\d\d-\d\dT/) { def gcinfo = parseGC(line) //println gcinfo try{ ym = gcinfo.ym.toInteger() tm = gcinfo.tm.toInteger() pt = gcinfo.pt.toDouble() } catch(e) { return } youngMax = (ym > youngMax) ? ym : youngMax totalMax = (tm > totalMax) ? tm : totalMax totalPause += pt if( line.contains("[Full GC")) { try{ om = gcinfo.om.toInteger() pm = gcinfo.pm.toInteger() } catch(e) { return } oldMax = (om > oldMax) ? om : oldMax permMax = (pm > permMax) ? pm : permMax } } } println "Young Max: ${youngMax}K" println "Old Max : ${oldMax}K" println "Total Max: ${totalMax}K" println "Perm Max : ${permMax}K" println "Total GC pause time: ${totalPause} sec" def Map parseGC(line) { def items = line.tokenize("[")*.tokenize("]") .flatten()*.tokenize(",").flatten()*.trim() //println items def m = [:] items.each{ switch(it) { case ~/PSYoungGen:.*/: m.ym = it.find( /PSYoungGen:.*\((\d+)K\)/ ) {all,m0 -> return m0} break case ~/ParOldGen:.*/: m.om = it.find( /ParOldGen:.*\((\d+)K\)/ ) {all,m0 -> return m0} break case ~/PSPermGen:.*/: m.pm = it.find( /PSPermGen:.*\((\d+)K\)/ ) {all,m0 -> return m0} break case ~/\d+K->\d+K\(\d+K\)/: m.tm = it.find( /\d+K->\d+K\((\d+)K\)/ ) {all,m0 -> return m0} break case ~/\d*\.\d*\s+secs/: m.pt = it.find( /(\d*\.\d*)\s+secs/ ) {all,m0 -> return m0} } } return m }
以上です。
Groovyの便利さを感じていただくことができましたか?
次は@tyamaさんです！
マキタのコードレス掃除機が素晴らし過ぎる件
コード式の掃除機はコードが邪魔で取り回しが悪かったり、ホースが短くて前かがみで作業しなければならなくて腰が痛くなったりで、ついつい掃除が億劫になってしまいがちでした。
以前からコードレス掃除機にチャレンジしてみては、吸い込みが弱かったり、吸い口の形状が特殊だったりして、どうしてもコード式掃除機を完全リプレースするまでには至りませんでした。しかし、今日こちらの商品が届いて、試しに使ってみたところ「素晴らしい」の一言。
- 出版社/メーカー: マキタ
- メディア: ホーム&キッチン
- 購入: 2人 クリック: 36回
- この商品を含むブログ (11件) を見る
- リチウムイオンバッテリー採用で、コード式掃除機と遜色ない吸入力
- 軽量コンパクトで持ち運びが苦にならないフォームファクター
- 極めつけはフックに掛けて収納できる省スペース性
ということで、まさにパーフェクトとしか言いようがありません。
まぁ、通常の掃除はルンバがやってくれてるわけですが、ルンバが処理できない隙間や机の上などはこれでこまめに掃除ができそうです。
- 出版社/メーカー: iRobot (アイロボット)
- メディア: ホーム&キッチン
- 購入: 1人 クリック: 236回
- この商品を含むブログを見る
- 出版社/メーカー: iRobot (アイロボット)
- メディア: ホーム&キッチン
- クリック: 42回
- この商品を含むブログ (18件) を見る
うちみたいに、猫を飼ってて毛玉が家中に散在しているお宅には、特におススメです。
LiquiBaseメモ
昨年秋のJGGUG合宿でもくもくと調べた結果のメモです。今さらですがまとめておきます。
日本語チュートリアル
DBAを救え! DBリファクタリングツール「LiquiBase」を使ってみよう
http://news.mynavi.jp/articles/2007/10/25/liquibase/index.html
ちょっと古いが、チュートリアルとしてはよい記事だと思います。
ChangeSetに指定できるタグのリスト
LiquiBase Extension
LiquiBase Extension Portalに集約されているようです。
https://liquibase.jira.com/wiki/display/CONTRIB/LiquiBase+Extensions+Portal
公式Wikiからのリンクが切れているので、こちらを見てください。
LiquiBase JIRA
ToDo: Groovy DSL
Liquibaseはマイグレーション定義をXMLで記述しますが、Groovyで記述できるようにするためのDSLがあります。ドキュメントが少ないので、使い方から調べる必要がありますね。。。
https://github.com/tlberglund/groovy-liquibase
Grails Database Reverse Engineering Plugin - G* Advent Calendar 2012 -
G* Advent Calender 2012の12/6担当、@nobusue です。
どうも風邪を引いたらしく、体調がやばい事になってます。。。ということで、JGGUG合宿2012の成果まとめで勘弁してください。
Grailsは通常、モデルオブジェクトを作成し、そこからRDB(もしくはKVSなど任意のデータストア)にデータを永続化するという手順で利用します。しかしながら、既存のRDBがあり、そのデータを管理するUIをささっと作りたいというお話は割りとよく聞きます。
そんなときに便利なのが、Database Reverse Engineering Pluginです。
http://grails-plugins.github.com/grails-db-reverse-engineer/
ただ、こいつはちょっと癖があるので、使いこなすにはいくつかコツが必要です。ここでは、私が踏んだ地雷を公表しておきたいと思います。
Pluginのインストール
適当な新規Grailsアプリケーションを作成します。ここでは仮にtestとしました。
Grailsは2.1.1、Database Reverse Engineering Pluginは0.4で動作確認しています。
次に、次のコマンドでPluginをインストールします。
nobusue-MacBookPro:test nobusue$ grails install-plugin db-reverse-engineer Plugin installed.
無事にインストールできました。そう、インストールはね。。。
DBの準備
今回はMySQL5を利用しました。みなさんのお手元では適当なDBを作成してください。(もちろんですがGrailsがサポート対応しているものにしてくださいね！)
データを自分で作るのが面倒だったので、MySQLのサイトで公開されているサンプルデータを利用させていただきました。このデータ、MySQLの記述検定にも使われているそうなので、一度見ておくとよいかもです。
http://dev.mysql.com/doc/index-other.html
今回はDB=worldにworld.sqlを取り込みました。
データソース設定
Grailsのデータソースを設定します。
[grails-app/conf/DataSource.groovy]
dataSource {
url = 'jdbc:mysql://localhost/world'
driverClassName = 'com.mysql.jdbc.Driver'
username = 'root'
password = 'password'
dialect = org.hibernate.dialect.MySQL5InnoDBDialect
}
あと、PluginがJDBCドライバを参照できるように、依存関係を追加してやります。
[grails-app/conf/BuildConfig.groovy]
dependencies {
runtime 'mysql:mysql-connector-java:5.1.20'
}
最後に、Plugin自体の設定を追加します。
[grails-app/conf/Config.groovy]
grails.plugin.reveng.jdbcDriverJarDep ='mysql:mysql-connector-java:5.1.20'
DB Reverse Engineering Plugin実行
さあ、これで準備完了です。DBサーバーが起動していることを確認して、Pluginを実行してみましょう！
nobusue-MacBookPro:test nobusue$ grails db-reverse-engineer --stacktrace Compiling 10 source files.| Error Error executing script DbReverseEngineer: : Compilation Failed (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.) : Compilation Failed at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at DbReverseEngineer$_run_closure1.doCall(DbReverseEngineer:51) Caused by: java.lang.IllegalArgumentException: The includeAntRuntime=false option is not compatible with fork=false ... 3 more Error Error executing script DbReverseEngineer: : Compilation Failed
ということで、残念ながらPluginの実行が失敗します。どうもモデルオブジェクトの自動生成あたりで引っかかっている雰囲気ですが、細かいことを追求するのはやめておいて、ドキュメントにしたがってGrailsとPluginのバージョンを下げてみます。
改めて環境構築
ドキュメントによると、「Grails2.0+Plugin0.4で動かない場合は、いったんGrails1.3+Plugin0.3でモデルオブジェクトを生成し、そのアプリケーションをGrails2.0の環境にマイグレーションしろ」と書いてありました。もっと分かりやすいとこに書いといてくれよ。。。
ということで、Grails1.3.9をインストールし、再びアプリケーションを作成します。
Reverse Engeering PluginがMaven Centralを参照するのですが、Grails1.3のテンプレートでは無効化されているのでリポジトリを追加します。
[grails-app/conf/BuildConfig.groovy]
repositories {
mavenLocal()
mavenCentral()
Pluginのインストール時はバージョン指定をお忘れなく。
grails install-plugin db-reverse-engineer 0.3
grails-app/conf/Config.groovy および grails-app/conf/DataSource.groovy は、Grails2.0のときと同様に修正します。
改めてDB Reverse Engineering Plugin実行
> grails db-reverse-engineer Running script /Users/nobusue/.grails/1.3.9/projects/test13/plugins/db-reverse-engineer-0.3/scripts/DbReverseEngineer.groovy Environment set to development [copy] Copied 3 empty directories to 1 empty directory under /Users/nobusue/.grails/1.3.9/projects/test13/resources [copy] Copying 1 file to /Users/nobusue/.grails/1.3.9/projects/test13/resources [copy] Copied 3 empty directories to 2 empty directories under /Users/nobusue/.grails/1.3.9/projects/test13/resources [mkdir] Created dir: /Users/nobusue/.grails/1.3.9/projects/test13/plugin-classes [groovyc] Compiling 13 source files to /Users/nobusue/.grails/1.3.9/projects/test13/plugin-classes [mkdir] Created dir: /Users/nobusue/work/grails/test13/target/classes [groovyc] Compiling 7 source files to /Users/nobusue/work/grails/test13/target/classes [mkdir] Created dir: /Users/nobusue/.grails/1.3.9/projects/test13/resources/grails-app/i18n [native2ascii] Converting 13 files from /Users/nobusue/work/grails/test13/grails-app/i18n to /Users/nobusue/.grails/1.3.9/projects/test13/resources/grails-app/i18n [copy] Copying 1 file to /Users/nobusue/work/grails/test13/target/classes [copy] Copied 2 empty directories to 2 empty directories under /Users/nobusue/.grails/1.3.9/projects/test13/resources [echo] Starting database reverse engineering, connecting to 'jdbc:mysql://localhost/world' as 'root' ... [echo] Finished database reverse engineering
おおっ、無事に City.groovy, Country.groovy, CountryLanguage.groovy が生成されました。CountryLanguageは複合キーが定義されているため、hashCode()も自動生成されています。すばらしい。
UI作成
モデルオブジェクトさえ手に入ればこっちのもの。試しにscaffoldして動かしてみます。
grails generate-all xxx.City
すると、scaffoldは問題なく終了しますが、生成されたUIを実行するとエラーが出てしまいます。原因はMySQLのテーブル"CountryCode"がフィールド"String countryCode"にマッピングされており、これを改めてGORMに通すとCOUNTRY_CODEをさしてしまうためでした。
対策としては、モデルオブジェクトにmappingを追加するか、フィールド名をcountrycodeのようにcamel caseでないものに修正する必要があります。今回は後者の対応で対応することで、めでたくUIから操作できるようになりました。
次にCountryですが、mapping追加でviewから操作することはできました。
static mapping = {
id name: "code", generator: "assigned"
version false
surfaceArea column: "surfacearea"
indepYear column: "indepyear"
lifeExpectancy column: "lifeexpectancy"
localName column: "localname"
governmentForm column: "governmentform"
headOfState column: "headofstate"
}
しかし、UI上ではリスト表示の際にID列がないため、editのリンクが機能しません。
同じく、CountryLanguageはテーブル名がcamel caseになるので、こちらもmappingを修正して対応します。
static mapping = {
table "countrylanguage"
id composite: ["countryCode", "language"]
version false
countryCode column: "countrycode"
isOfficial column: "isOfficial"
}
ここで気づいたのが、idはマッピングされているのに、scaffoldで生成したviewのID列には表示されていないということ。何か対策があるんでしょうが、調べ切れていないのでとりあえず宿題ということにさせてください。
あと、元のテーブルにはリレーションが設定されているのですが、モデルオブジェクトの関連には反映されていないですね。Pluginの実行時に何か設定が必要なのでしょうか？
まとめ
ちょっと癖のあるDB Reverse Engineering Pluginですが、ベースとなっているHibernate Toolsのことを理解していればもうちょっと使いこなせるかもしれないです。素直なテーブルなら使えると思いますので、ぜひお試しください。(そしてレポートを。。。)
追記
2012/12/6現在でReverse Engineering Plugin 0.5がリリースされてました。。。こちらも確認せねば。。。
次は @nobeans さんです！
継続的デリバリー読書会#5に参加 / DBマイグレーションツール
@kyon_mm さん主催の読書会も第五回になりました。
今回の対象範囲は
- 第10章 アプリケーションをデプロイ・リリースする
- 第11章 基盤と環境を管理する
- 第12章 データと管理する
でした。どの章も本業と関わりが深く、参加されたみなさんとのディスカッションでもいろいろと考えさせられることが多くありました。
個人的には、過去に参加したプロジェクト(開発者20人くらい)で「刻々と変化するDBスキーマとアプリの整合性をどうやって維持するか」という作業に悩まされた経験から、第12章の内容が非常に示唆に富んでいました。ここは今後も掘り下げていきたいと思っていますが、忘れてしまう前に現時点での自分なりの見解をまとめておきます。
マイグレーション用SQLを直接書くケース
MyBatis Schema Migrationsがよさそう。@kyon_mm さんが実際にプロジェクトで利用しているそうです。
http://code.google.com/p/mybatis/wiki/Migration
SQLを直接書けるので柔軟性が高いのがメリットですが、マイグレーションスクリプトがDB依存になってしまうことや、アプリケーション側(Java系言語想定)との対応関係が見えづらくなってしまうことが課題ではあります。
書籍ではDbDeployというツールを紹介していますが、これよりもMyBatis Schema Migrationsの方が高機能かつ活発にメンテされているようですね。
マイグレーション用SQLを直接書かないケース
DBに依存しない何らかの定義ファイルやドメインオブジェクトをベースにマイグレーションを記述する手法になるかと思います。
ER定義をベースとするタイプでは、Jiemamyが使えそうです。(最近滞っているようですが。。。)
http://jiemamy.org/display/PORTAL/Home
ドメインオブジェクトをベースにするタイプはRailsのmigrationが先駆者だと思うのですが、Java系であればGrailsのモデルオブジェクト(GORM)を利用するというアイデアがあります。実際にどこまで使えるかはこれから検証したいと思いますが、既存のDBスキーマからリバースでモデルを生成し、それをGrailsのmigration pluginで扱うことができればSQLレスのマイグレーションができるかも、という話です。
http://grails-plugins.github.com/grails-db-reverse-engineer/
http://grails-plugins.github.com/grails-database-migration/
QUMIのモバイルプロジェクター購入しました
こちらの記事に触発されてAmazonでぽちってしまいました。
http://itlifehack.jp/archives/6478870.html
現物はこちら。比較のために「継続的デリバリー」と重ねてみました。
こんなに小さいボディなのに、解像度は1280x800、かつ数m先の壁に映しても文字が読める明るさです。
カメラ用三脚で固定もでき、台形補正もできるので、ちょっとした打ち合わせや勉強会などで活用できそうですね。超おすすめの商品です。
- 出版社/メーカー: VIVITEK
- 発売日: 2011/10/11
- メディア: Personal Computers
- 購入: 1人 クリック: 71回
- この商品を含むブログ (3件) を見る
