■

Infrastructure as Codeと言いながらnginx.restartとか書けないのは何でなの。実は書けるのかしら。include systemd_commandsとかしたくないのかな。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年4月19日

DSLで十分と言えばそうなのだけど、どうせRubyの精神で行くならコマンドはメソッドにしたいなぁ。

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年4月19日

たしかにDSLでサーバ構成は書けるのだけど、書いててあんまり楽しくないというモチベーション。必要以上に構成管理のコードを綺麗にしても意味はないのだけど、サーバアプリばかり書いている人にとっては、コマンドをメソッド呼び出しとして記述するほうが自然に読めると思う。まともなシステム構成ならプロセスの責務は分かれているし、コマンド体系もおおよそ似たようなものだから、各プロセスをオブジェクトと見立てるのに無理はないのではないか。

と、ここまで書いたところでTLのインフラエンジニアより「Chef / itamae, puppetの哲学は、操作手順を記録することが目的ではなく、最終的なサーバの状態をコードに落としているだけだよ」というツッコミが入り、

たしかに欲しいのはどうやるかじゃなくて、最終的なインスタンスの状態

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年4月19日

という理解をして得心を得た。おわり。

必要なのは手続きではなく状態というのは正しいので、書きやすさの文句を言うならDSLの文法だとか実行環境、ツールの複雑さあたりを対象にするのが筋かもしれない。

inputが多いシステムはOptionalと相性がよい説

— ╹◡╹ ）＜ よく噛んで食べる (@non_117) 2017年4月19日

人間の曖昧さによってユーザ入力は何が起こるかわからないので、特にテキスト入力が多ければ多いほどOptionalを扱える言語が相性よさそう。逆に、曖昧な入力が少なければスクリプト言語でえいやっとやってしまってもよいと思う。

自由な入力はnullとの戦いがつきものなので、武器は多いほうがよさそう。