勢い余ってKyoto.pmのトークに申し込んだらぎりぎりにも関わらずやらせてもらえる事について発表してきました。
運営のshiba_yu36さんありがとうございました。また、会場を提供していただいたはてなさんありがとうございました。
トーク内容について
正月発火村とかXOClockとかについて話しました。
始まる前からだいぶ緊張してしまっていた事もあり、
発表自体はだいぶぐだぐだになってしまいました。
もっともっとちょっとプレゼンスキル磨きたいﾅｰ。
XOClockは便利に使える場面は多そうだけど、
まだまだ足りない機能が多すぎたり、
設計的にアレな部分があるので、
意見言ってくれる人とか、一緒に開発してくれる人とか募集中です！
atコマンドに対する優位性
yappoさんから指摘されたXOClockのatコマンドに対する優位性については、現状では
- 同時に実行する数を制限出来る
- ネットワーク越しにenqueue出来る
- Job毎にタイムゾーンを一緒に指定してenqueue出来る
の3点です。
configでmax_workersを指定する事により同時に実行される数を制限出来ます。
これによって、年越しの瞬間にJobの発火が集中するといった場合に一気に大量にプロセスが生成されるという事態を防ぐ事が出来ます。
また、atコマンドでは間に何かMiddleware的なものを挟まなければネットワーク越しにJobを登録する事が出来ません。
これが出来ない限り、WebApplication等、他のサーバーに対してenqueue出来るようにしなければならない用途では使えません。
sshすれば良いという話もあるかもしれませんが、個人的には嫌です。
また、atコマンドでは時刻の指定は実行環境のタイムゾーンに依存します。*1
よって、様々なタイムゾーンの時刻でenqueueされた場合に、一度何かを通してシステムと同じタイムゾーンの時刻に変換してやらなければいけないという手間が発生します。
XOClockではenqueue時にtime_zoneを指定すれば、指定されたタイムゾーンで時刻を解釈します。
また、将来的にはDBにJobを保存するように出来たりするようにしたいなーと思っているので、
すけーらびりてぃとかもよくなるかもしれません。
Kyoto.pmについて
お菓子食べながらLTしたり、肉に厳しい人が居たりして面白かったです！
OR Mapperのまわりの話とJob Queueについての話が多かったかなーと思います。
特にOR Mapperまわりの話はアツかった。
終わった後鴨川で餃子カンファレンスが開催されたり楽しかったです！
また、観光地なので次の日も色々回れて面白かった。
適当にぶらぶら散歩してたけど、商店街の中にいきなりお寺が現れたり、
適当に裏路地入ってみたらまたお寺が現れたりして京都！京都！ってなりました！
京都タワーも初めて昇りました！
なんか緩いsinカーブしてる感じの鏡があって面白かった！
面白かったのでまた行きたいなーと思いました。
