AsakusaFW & Tsurugi Advent Calendar 2021の24日目です。
長い名称は略されるのが世の常です。
例えばOracleはora（エラーコードがORA-XXXXX）、PostgreSQLならpg（PL/pgSQL等）ですね。
では、Tsurugiはどう略されるでしょう？
3文字略称ならやはりtrgですかね。
2文字略称なら？ trかtgでしょうか。PostgreSQLがpgなので、tgが良い気がしますね。TsurugiはPostgreSQLの皮を被っていると言われていますしｗ
AsakusaFW & Tsurugi Advent Calendar 2021の23日目です。
AsakusaFWの実行基盤であるM3BPやVanillaは単一ノード上で実行するので、（推奨される方法ではありませんが＾＾；）System.out.printlnで値をデバッグ出力することが出来ます。
ただし、実行時に出力できるようなprintlnを仕込めるのは、あくまでOperatorクラスのメソッドのみです。
実行途中に出力したくてFlowPartやJobFlowに仕込みたくかもしれませんが、それらのクラスはコンパイル（ビルド）時に実行されるものであり、バッチを実行したときに呼ばれるものではありません。
AsakusaFW & Tsurugi Advent Calendar 2021の21日目です。
アドベントカレンダー14日目で、AsakusaFWのDate・DateTimeとJava8の日付時刻API（java.time）のLocalDate・LocalDateTimeとを変換する方法について書きました。（地道にgetYear()やgetMonth()・getDay()などを使う方法）
しかし、AsakusaFWのDateは基準日からの経過日数（エポック日）、DateTimeは基準日からの経過秒数（エポック秒）で保持しており、個別にgetYear()・getMonth()・getDay()を呼び出すのは、中で変換（割り算）が行われるため、若干不利です。（一方、LocalDateやLocalDateTimeは個別のyear・month・day等で保持しています）
で、LocalDateやLocalDateTimeもエポック日やエポック秒に変換するメソッドを持っているので、それを使う方法も良さそうです。
ただし、AsakusaFWの基準日は西暦1年で、日付時刻APIの基準日は西暦1970年なので、その差は埋める必要があります。コード上のマジックナンバーになっちゃいますけど、それくらいは仕方ないですよね(笑)
AsakusaFW & Tsurugi Advent Calendar 2021の20日目です。
AsakusaFWでは、各処理を並列で実行するので、処理がどこまで進んでいるかというのを確認するのは難しいです。
しかし実行ログでFinishedと出ている処理（vertex）については、それが終了したことは分かります。
ログに出ているvertexの名前は概ねOperatorのメソッド名ですが、AsakusaFWは複数のメソッドを一塊の処理（vertex）としてまとめることがあるので、具体的なメソッドは別途確認してみないと分かりません。
Asakusa CLI（asakusaコマンド）にlist planというサブコマンドがあり、それでvertexに含まれるメソッドを確認できます。
AsakusaFW & Tsurugi Advent Calendar 2021の19日目です。
データモデルのプロパティーが増えるデータモデルに変換するときはcore.extend、減るときはcore.project、増減するときはcore.restructureを使用します。
このcore.srestructureで、一致するプロパティーがひとつも無いときはどうなるかな？と気になったのですが、特にエラーが出るようなことはありませんでした＾＾；
