Toad Editor 2017

Asakusa Framework Advent Calendar 2017の19日目、拙作Toad Editorの今年の振り返りです。

Toad EditorはAsakusaFWのフローをグラフィカルに編集し、Javaのソースを生成したりJavaソースへジャンプしたりすることが出来るツール（Eclipseプラグイン）です。
逆に、Javaソースから図（フローグラフ）を生成することも出来ます。

実際の業務でAsakusaアプリケーションを開発する場合、設計段階でフロー（グラフ・図）をVisio等で作成します。
これを、「Visioの代わりにEclipse上で図を描けば、そこからJavaソースが生成できるのでは？」という発想で作ったツールです。

が、実際に使ってみると使い心地はVisioに及ばないし、設計段階では省略するような細かい事もソース生成の為には記述する必要があり、設計書を描くツールとしては失敗した感があります(苦笑)
（ただ、AsakusaFWのフローがどんなJavaソースになるかを試すツールとしては便利かもしれません(笑)）

そういう訳で昨年は全くToad Editorのソースは触っていなかったのですが、今年使った人から「グラフの生成がエラーになる」と言われ、超久しぶりに修正しました。
Asakusaコンパイラーが実行基盤毎に異なっていたのが、AsakusaFW 0.9.2である程度統一され、その影響で今まで使っていたコンパイル用クラスが無くなったのが原因です。

まぁ、他にもAsakusaFW 0.10.0で導入されたGroupView・@Once・@Spill等も対応していないのですが＾＾； 要望があったら対応するかどうか考えたいと思いますｗ

Asakusa Framework 0.10.0 FlowPartTesterでラムダ式

Asakusa Framework Advent Calendar 2017の18日目です。

2017/11/29に出たAsakusaFW 0.10.0（→リリースノート）の機能を紹介していきたいと思います。
今回は一時的なフロー記述による演算子のテストです。

AsakufwFW 0.10.0から、フローのテストを行う為のFlowPartTesterに、Runnableを受け取るメソッドが追加されました。Runnableを受け取るということは、そこにラムダ式が書けるという事です。
FlowPartTesterでは、そこにFlow DSLを書くことが出来ます。

今まで、フローのテストを行う場合はFlowPartクラス（あるいはJobFlowクラス）を作り、それを指定する方法しかありませんでした。Operatorの演算子をフロー経由でテストしたいだけの場合でもFlowPartクラスを作る必要がありました。（例えばOperatorの単体テストでは@Keyの内容をチェックできないので、やるならテスト用にFlowPartを作るしかなかった）
今回、メソッドに直接Flow DSLを書くことが出来るようになったので、FlowPartクラスを作らなくてもテストを書くことが出来るようになったわけです。

検証データ（期待値）や検証ルールもJavaでコーディングできるので、テスト用のExcelファイルも不要です。（これは以前から出来たことですが）
（ただ、Excelで記述するのとJavaで記述するのは、どちらが分かりやすい・コード量が少ないかは別です＾＾；）

Asakusa Framework 0.10.0 Parquetの変更

Asakusa Framework Advent Calendar 2017の17日目です。

2017/11/29に出たAsakusaFW 0.10.0（→リリースノート）の機能を紹介していきたいと思います。
今回はParquetのフォーマット変更についてです。

ParquetはHiveで使われるバイナリーファイルフォーマットです。
これのDECIMALに関する問題を解決する為の修正が行われたようで、それに伴い、以前のバージョンで作ったParquetファイルが正しく読み込めなくなる可能性があるそうです。もしParquetを使っていたら、結構おおごと。
（何が問題だったのか、リリースノートを見ても判然としないのですが＾＾；）

ちなみに自分はParquet（Hive）を使っていない（CSVの方が直接ファイルの中を確認しやすい）ので気にしてなかったんですが、AsakusaFWのHive連携ってまだ試験的機能だったんですね…。

Asakusa Framework 0.10.0 M3BPとWindGate

Asakusa Framework Advent Calendar 2017の16日目です。

Asakusa on M3BPでは、ファイルアクセスを行う為にHadoopのライブラリー（HadoopのFileSystemクラス）を使用する為、実行環境にHadoopが必要となります。
ただ、わざわざ実行環境にHadoopをインストールしなくても、AsakusaアプリケーションにHadoopライブラリーを含める方法が用意されています。

ところが、M3BPのアプリケーションでWindGateを使っている場合、AsakusaFW 0.10.0より前は、WindGateはAsakusaFW同梱のHadoopライブラリーを使用できず、別途M3BPマシンにHadoopクライアントをインストールする必要がありました。
（M3BPのDirect I/Oでローカルファイルシステムにアクセスしている場合、Hadoop（HDFS）は全く無関係なのに、WindGate（DBアクセス）の為にHadoopクライアントをインストールする必要があったのですorz）
しかしAsakusaFW 0.10.0ではWindGateもAsakusaFW同梱のHadoopライブラリーを使用できるようになったようです。

AsakusaFW 0.10.0で同梱のHadoopライブラリーを使用する設定の「hadoop.embed」の設定名に「m3bp」等の実行環境名（フレームワーク名）が入っていないのは、全体に影響のある設定だからだと思います。（従来の設定名は「m3bp.useSystemHadoop」でした）

Asakusa Framework 0.10.0 M3BP-Hadoop連携方法の変更

Asakusa Framework Advent Calendar 2017の15日目です。

2017/11/29に出たAsakusaFW 0.10.0（→リリースノート）の機能を紹介していきたいと思います。
今回はM3BPとHadoopの連携方法についてです。

Asakusa on M3BPであっても、Hadoopのライブラリー（HadoopのFileSystemクラス）を使ってファイルアクセスを行う為、実行環境にHadoopが必要となります。
ただ、わざわざ実行環境にHadoopをインストールしなくても、AsakusaアプリケーションにHadoopライブラリーを含めてしまうという方法が用意されています。

そして、デフォルトでどちらかのHadoopを使うのかがAsakusaFW 0.10.0で変更になりました。
従来はデフォルトで（実行環境のHadoopを使わず）AsakusaFWに同梱されるHadoopライブラリーを使うようになっていましたが、0.10.0では逆になり、デフォルトで実行環境のHadoopを使用するようになりました。

また、これらを切り替えるために従来はbuild.gradleでuseSystemHadoopを設定していましたが、0.10.0でこの設定は無くなり、hadoop.embedに変わりました。