ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

Asakusa Gradle Pluginを試してみた

2013-11-23 21:16:40 | PG(分散処理)

Asakusa Framework0.5.2で試験的に導入されたAsakusa Gradle Pluginを試してみた。

AsakusaFWはWindowsには正式対応していないが、GradleプラグインにはWindows用のバッチファイルも含まれているので、Windowsからも使うことが出来る。
Mavenをインストールする必要が無いので、Windowsから使うにはとても便利(笑)
(特に、WindowsにはJinrikishaが無いから、余計にw) 

ダウンロードしたアーカイブを解凍してそこのコマンドを実行するだけ、という手順はシンプルで分かりやすい。
Windowsに正式対応していないが故にアーカイブ(プロジェクトテンプレート)はtar.gzファイルしか提供されていないので、解凍するにはCygwinなり解凍ツールなりが必要になるが。Windowsに正式対応すればzipファイルも提供されるだろう。

あと、Windowsに正式対応する際には、Eclipse用の定義を生成する際にJavaソースのエンコーディングをUTF-8にしてくれると嬉しい。
(WindowsではデフォルトがMS932なので、手動でプロジェクトの設定を変える必要がある)


ちなみに、プロジェクトテンプレートは現時点では2種類提供されている。
空プロジェクト(プロジェクトのディレクトリーと定義ファイルだけあってソースファイルは無い)のみのもの(asakusa-project-template)と、今までのサンプルアプリケーションを含んだもの(asakusa-example-project)。

ただし、前者を使ってEclipseのプロジェクト定義を作ろうとすると手順が若干複雑になるでの、自分のページには後者のものだけ記載した。

前者だとどうなるかと言うと。
「gradlew eclipse」を実行すると、その時点で存在するディレクトリーだけを使って.classpathを生成する。
実際にはDMDLコンパイルによって生成されるディレクトリーも必要になるので、先に「gradlew compileJava」を実行する。
しかし空プロジェクトではdmdlファイルが1つも無いので、DMDLのコンパイルでエラーになる^^;

つまり、最初に「gradlew eclipse」を行ってEclipse定義を作り、その後に(DMDL EditorXを使ってw)dmdlファイルを作ってから再度「gradlew compileJava eclipse」を実行する等の、段階を踏む必要がある。 


DMDLのコンパイルやバッチアプリケーションのアーカイブ(~batchapps.jar)を作る為のコマンドは、さすがにだいぶ変わった。
基本的には出来る事が細分化された感じ。

例えば、今まではDMDLのコンパイルを行うとModelクラス類のJavaソースの生成とテストデータを記述するためのExcelファイルの生成が両方とも行われた。
しかしExcelファイルの生成はそう頻繁に必要になるわけでもないし、データモデルの数が多くなるとExcelファイルの生成時間も馬鹿にならない。
今回のGradleのコマンドでは、それが分離された。 


ついでに言うと、今まではファイルの生成先はtargetの下だったと思うが、Gradle版ではbuildの下になっている。
targetを探しにいくと、「あれ?無い?!」ということになる(笑)

あ、それから、Mavenを使わなくなったのでpom.xmlは無くなったし、ついでにbuild.propertiesも無くなった。
そこに書いてあった情報はbuild.gradleに移っており、記述量がだいぶ減って見やすくなっている。(デフォルト値の設定は記述が省略されているという面も少しあるが、Gradleがシンプルだという事だろう) 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AsakusaFW0.5.2 Gradle対応!

2013-11-20 23:32:37 | PG(分散処理)

今日Asakusa Framework0.5.2がリリースされたので、例によってちょっと見てみる。
リリースノートChangelogs

一番大きなのは、やはりGradle対応(#301)だろうなぁ。まだ実験的(experimental)な機能という扱いだけど。
今までMavenを使ってプロジェクトを作ったりコンパイルしたりしていたが、Mavenを使わずにGradleで実行できるようになるらしい。今度の週末に試してみよう(笑)


次に大きなのは、Direct I/O CSVDirect I/O TSVのデータ圧縮解凍機能。(#305)
Direct I/OなのでHDFSとAmazon S3が対象。
ネットワークとCPUを比べてネットワークの方がボトルネックになっている場合は、ファイルを圧縮しておくと実行速度的に有利になる可能性がある。
別の視点として、Amazon S3は格納しているファイルサイズとダウンロード量に応じて課金されるので、圧縮しておくとその分安くなる(笑)

個人的に重大なのは、この圧縮機能は、DMDLの属性(@directio.csvおよび@directio.tsv)にcompression要素を指定して使う、という事。
DMDL EditorX(DMDL Editor Eclipseプラグイン)の属性追加ウィザードにこれを追加しないとイカン(笑)
ただ追加するだけなら簡単なんだけど、単純に追加するとAsakusaFW0.5.2より前でエラーになってしまうので、バージョンを見ないといけない。が、バージョンによって仕様が変わると思ってなかったので、そういう仕組みになってない(爆)から、作りこまないとイカン^^;

(あー、そういえば、JinrikishaDMDL Editorプラグインの紹介ページもDMDL EditorX用に修正してもらいました(笑))


Amazon S3関連でもうひとつ変わっている箇所がある。(#308
0.5.1ではDirect I/OをAmazon S3(EMR)で使う際の設定例でcom.asakusafw.directio.s3.fragment.minに-1を設定していたが、0.5.2では設定例から削除された。

EMRだかHadoopだかの古いバージョン(つまりAsakusaFW0.5.1の頃)はS3上のファイルのデータ分割が遅延する問題があって、それを回避する為に入力データを分割しない指定が推奨されていたが、今は直っているので、分割の指定はデフォルト状態(設定例に記載しない)になったようだ。 


TestDriverに関する修正(#303)も目を引いた。
これってたぶん、AsakusaFWのMLにあったFlowPartTesterでのエラーの件の修正じゃないかと思う。 


個人的にもうひとつ良かったのは、#300の修正。
DMDLで「a=b;b=c;c=a;」みたいな循環参照を定義すると当然エラーになるんだけど、エラーメッセージ中のエラー箇所を示す部分がnullだったんだよね(笑)
そうするとDMDL Editorでエラー箇所を示せないから困ってたので、この修正は嬉しい。
まだ試してないけど、DMDL Editorでもちゃんとエラー箇所を示せるようになった
はず^^;

循環参照のデータモデルを定義する人がどれくらいいるのか疑問といえば疑問だけど(爆) 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AsakusaFW DMDL・インポーター・エクスポーター

2013-11-16 20:34:24 | PG(分散処理)

Asakusa FrameworkDMDLについてまとめてみたら、意外と多かった。
逆にインポーター・エクスポーターについて書いてみたら、意外と少なかった^^;

DMDLはレコードモデル(普通のやつはそういう名前だったw)や結合モデル・集計モデルは直感的に見て分かるからそんなに苦労はしないと思う。
属性(「@」から始まるやつ)を今回改めて見てみたけど、Direct I/OのTSVやWindGateのTSVも増えてた。
namespaceとauto_projectionの存在自体は前から知ってたけど、DMDLエディターEclipseプラグインでは対応してない^^;
auto_projectionは射影モデルを全て取り込むらしいので、「全部」を探すと遅くなりそうなので、対応したくないんだよなー(爆) 

インポーター・エクスポーターは、それぞれのメソッドに書く内容はDirect I/OやWindGateといった種類によって違うので、一般的な例だけ書いてもあんまり役に立たないってことが分かった(苦笑)

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AsakusaFW Operator DSL

2013-11-04 18:07:47 | PG(分散処理)

Asakusa Framework演算子の一覧を自分なりにまとめてみた。

AsakusaFW本家のサイト(演算子リファレンス)は、(当然のことながら)必要な情報を全部載せているので、かなり大量なんだよね。
自分は自分が必要だと思うことだけに絞ったので、本家よりはコンパクトになったかな?
と言っても、一覧にしてみるとやはりそれなりの量になった^^;

しかし、AsakusaFWを使う上で一番悩むのが「どの演算子を使えばよいか」ということだと思うので、自分なりに整理してみたけど、分類してみたら意外と選択肢は少ない(というか、利用できる場面が限定されている)ということが分かった。

これがAsakusaFWを使う人の参考になるといいんだけど^^; 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

GradleでJavaコンパイル

2013-11-02 14:39:57 | PG(Java)

これに関して特に本文に書く内容が無いので、要らない前書きを長々書くけど。

MSX時代ではアセンブリ言語(Z80)のソースをアセンブルしてたけど、これはバッチファイル(*.bat)に書いてたので、ビルドツールとは言わないような気がする^^; 

という訳で、ビルドツールを初めて使ったのは、X68000時代のmake(makefile)になるかなぁ。
C言語のソースのコンパイルと、独自ツールを実行するのをmakefileに書いていた。

次いでJavaを使うようになったので、Ant(build.xml)を勉強。
(その前にVC++を使っていたが、これはIDEが勝手にコンパイルしてたという意識なので、ビルドツールは勉強していないという扱いw)
依存ライブラリーは、jarファイルとかを手動でダウンロードして配置。その場所をjavacタスクに指定する必要がある。

Asakusa Frameworkを使うようになってMaven(pom.xml)に触った。
依存ライブラリーを自動でダウンロードしてくれるのは便利。ディレクトリー構成が決め打ちなのは最初は戸惑ったけど。

で、社内ではGradleが流行りつつあるので、Gradle(build.gradle)の書き方をちょっとだけ調べてみた。
Mavenのいいところ(依存ライブラリーを解決してくれるとか)は受け継ぎつつ、記述が最小限で済むのは確かに便利だ(笑)

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする