WEB+DBのPerl Hackers Hubで書かれていた「cron周りのベストプラクティス」を読んだ。かなり参考になった。
経緯としては読みたいって呟いたら感想よろしくと言われたので慌てて読んだ。
@shiba_yu36 「読んだ」なら言ってもいい
— songmu (@songmu) 2014年2月24日
@shiba_yu36 マジに謝られても…
— songmu (@songmu) 2014年2月24日
@shiba_yu36 マジになって感想エントリを書いてください。
— songmu (@songmu) 2014年2月24日
特に参考になったこと
batch.pl
batch.plは非常に良いと思った。というのもcronとかのスクリプトで非常に簡単な事をやっている場合は適当にplファイルを作っちゃって登録するんだけど、得てしてそういうのはテストが無くてバグってて、しかもcronのログをきちんと取るようにしておかないとエラー自体も気づかないことが多い。
そのためこの問題をbatch.plに通さないとcronを実行してはいけないという規約でカバーするのは良いプラクティスだと思った。参考になる。
App::RunCron
良い。自社でも実際にはこういうことをするようなwrapperを使っているのだけれど、外部に向けて公開されていないので、あんまり標準化されていない。
出来るだけソースが公開されたものを利用したいし、それに貢献していきたいとも思うので、今はまだ必要な機能が足りないかもしれないが、是非こっちに乗り換えたいと思った。
規約のテスト
今回の中で「規約をテストする」という部分がさらっと書かれていたが、結構これは良いと思う。
最近開発のドキュメントをどこに置くか問題 - $shibayu36->blog;のような文章を書いたが、ドキュメントの中で規約にカテゴライズされる部分はドキュメントを書くのではなく、テストで気づかせるという方が良いと最近思ってきた。試しに最近はウェブアプリケーションの設定(Config::ENV的な)ものに対して、規約としてのテストを書いたが、これは結構うまくいきそうという感触を覚えている。
テストというのは全ての役割をまぜこぜにしてしまうと非常にわけのわからないものになりすぎる傾向があるが、このように
- 開発を効率的にするためのテスト
- 品質を担保するためのテスト
- 規約のためのテスト
- 非エンジニア向けのテスト(デザイナが作るファイル名のテストなど)
など何をしたいかを考えながらその用途にあったテストを書くと良いなーと思った。
他に知りたいと思ったこと
最近cronサーバを作りなおすときにどうするかということに困ってる。cron止めるのも困るし、二重に走っても困る。どうやってるんでしょうか。
その他感想
env-exec
みんなこういうラッパーを書いてるんだなーと思った。
crontabの時間指定形式
* 5 * * *
このミスあるあるっぽい...
あと曜日指定のハマりどころは知ってたけど忘れてたので絶対ハマる。
PERL5LIB?
PERL5LIBってlocal/lib/perl5/(arch_name)みたいなところには通さなくていいんだっけ...
