make のパチモンを作ったので公開します。
なぜか
そこそこ手順の多い作業（ワークフロー）をツール化するとき、エラー処理とかリトライ処理が問題になる。
入力されたデータが手入力されたゆるふわデータなので、ツールで処理しても当たり前のようにコケる。
個々の入力ミスにツールがいちいち対応していたら手間がかかって仕方ないので、ツールがコケたら手でデータを修正して続きからリトライするのが気軽で現実的な対応策になる。
実現する方法として make という巨人の肩を借りることにした。
make はビルドツールとして知られているが、ワークフロー制御ツールとしても使うことができる。
当然「普段使用している windows PC」に make などあるはずもなく、それらしいものを自作することになる。
make とは
Wikipedia から引用。
make（メイク）は、プログラムのビルド作業を自動化するツール。コンパイル、リンク、インストール等のルールを記述したテキストファイル (makefile) に従って、これらの作業を自動的に行う。
複雑に関連し合ったファイルの依存関係を解決するのが make の長所である。例えば、A というファイルを処理して B というファイルを生成するとき、make はそれぞれのファイルの更新時刻（タイムスタンプ）を参照し、A が B よりも新しいときには作業を行うが、B が A より新しければ作業は不要と見なして何もしない。ファイル数が増え、依存関係が複雑になっても、make は makefile の記述を頼りに必要最低限の作業だけを自動で行う。Autotools という別のツールを使う事で makefile の自動生成が可能である。
UNIX系ソフトウェアは、ソースコードの形で配布されることが多いが、そのビルド作業にはほぼ必須のツールといえる（ごくまれに make を使わないソフトウェアも存在する）。
なお、make はプログラムコードのビルド以外の用途にも使用可能である。例えば、LaTeX のソースファイルから DVI 形式のファイルを生成する作業などにも使用することができる。バッチ処理の簡略化にも使うこともできる。
手順
意識的ではないけど以下のような方針で作っていたような気がする
- 要件を決める
- 最低限の機能を実装する
- 装飾する
1. 要件を決める
make らしきものを作るにあたって、要件として以下のようなことを考えた。
- Makefile を初めて見た人がウッとならないこと（YAML採用）。
- ansible とか digdag とか汎用的で良いよね（モジュール機構採用）。
ここで一番悩んだのは、Makefile を YAML フォーマットで再現する方法。
YAML フォーマットが自由すぎて色々拡張し放題になっていた。
ただ、結果として以下のような感じに落ち着いた。
拡張については後日検討する。
Task1:
desc: task description
from:
- Task2
- Task3
exec:
- cmdline
- module:
module_arg1: "hoge"
module_arg2: true
ここまでで8割やること終わった感がある。
2. 最低限の機能を実装する
最低限の機能として、以下のような機能を実装。
Import-YAML は既に実装が終わっているので手抜きをした形になる。
- YAML 形式の Makefile を読んで依存関係を解決できること（DAGの構築）
- 依存関係に従って適切な順番でタスク（コマンド）を実行できること(グラフ探索)
- 実行済みのタスクはスキップできること。
- タスクが失敗するとフローが止まること。
基本的に教科書通りの再帰するコードなので構造単純 200 行ぐらい。
最初から色々実装しても無駄が多い気がするので最低限に留める。
必要な機能は必要になってから実装。欲しい機能は暇になってから実装。
凡人の先見性を当てにしてはいけない。
プログラムの速さだとか、メモリ効率だとかも後で良い。手作業よりも十分に早いことが期待できるのであれば問題ない。
コンピュータが 10 秒で終わる処理を 1 秒に短縮して喜んでいるから IT 業界は儲からない。
3. 装飾する
利用者のターゲットに、こんぴゅーたよくわからない人を含むので、装飾は必須。
ただでさえコマンドラインツールは評判が悪い。
コンソールに表示される実行ログは読みやすくする。当然、文字は色付き。
タスクの呼び出しはグリーンで、余計なタスクがスキップされたらイエローで、コマンドの実行結果はホワイト。
また Get-Help に対応する。よくわからない人に「自分で調べる」ことを覚えてもらうチャンスを逃してはいけない。
書き方はやはり MSDN が参考になる。
まとめ
どちらかというと品質よりも生産性を重視した形になりましたが、プロトタイピングの第一歩ということで、次回のコミットから品質は上がっていきます多分。