horensoというcronやコマンドラッパー用のツールを書いた | おそらくはそれさえも平凡な日々
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
レコードがなかったらINSERTして返すみたいなのを確実にやる | おそらくはそれさえも平凡な日々
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
Carton考2014 | おそらくはそれさえも平凡な日々
こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 本番環境と同じアーキテクチャ 本番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull
おそらくはそれさえも平凡な日々: Perlでフィボナッチ数列の高速化とか無名関数の再帰とか
簡単にfibを高速化する方法を読み、おおっと思って、Perlでやってみた。 #!/usr/bin/perl use strict; use warnings; use feature qw/state/; use Benchmark qw/timethese cmpthese/; sub _fib_ret2 { my $n = shift; if ( $n == 1 ){ (1,1); } else { my ( $aa, $bb ) = _fib_ret2($n-1); ($aa+$bb, $aa); } } sub fib_ret2 { (_fib_ret2(shift))[0]; } sub fib_memo { state @cache; my $n = shift; $cache[$n] ||= $n <= 1 ? 1 : fib_memo($n-2) + fib_memo($n
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
SQL::Translator::Producer::Tengを書きました | おそらくはそれさえも平凡な日々
https://metacpan.org/module/SQL::Translator::Producer::Teng TengのSchemaは手で書くのがタルいので、Teng::Schema::DumperなりTeng::Schema::Loaderなりを使ってごにょったりしていたのですが、無理やりだし、自動生成すればいいよねとは思っていたので、書きました。 Kyoto.pmでも先日のYAPC::Asiaでも「SQL::Translator::Producer::Tengみたいなのがあればいいかもしれないけど特に不便を感じてないからやってない」とか言っていたのですが、書いてみたら案外サクッとかけたので、CPANizeした次第。 以下の様なSQLファイルがあったとして、 CREATE TABLE `user` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT
最近のPerl例外厨事情 | おそらくはそれさえも平凡な日々
言及してくれていたのをずっと放置していた。 http://soh335.hatenablog.com/entry/2013/06/04/114954 最近結構例外厨で、事あるごとに例外投げたくなってる。結局エラー文字列を正規表現で引っ掛けるより、オブジェクトで引っ掛けたほうがエラーメッセージとかが変わった時に対応が少なくて楽だし、例外を階層化して置いたほうが色々捗る感じがしているので、丁寧に例外オブジェクト投げるように色々ラップしたほうが良いなーとか思ってる。 他言語の人にとっては何を今更みたいな話かもしれませんね。 例えば、Tengの場合だとこんな感じで、Tengはエラー投げるところがhandle_error()で一本化されているので、そこをオーバーライドすれば自分の好みの例外を投げ分けるとかができる。この場合だとユニークキー制約に引っかかった場合は異なる例外を投げるようにしてある。My
おそらくはそれさえも平凡な日々: Teng::Plugin::SearchJoinedとSQL::Maker::JoinSelectとKyoto.pmの話
https://metacpan.org/module/Teng::Plugin::SearchJoined https://metacpan.org/module/SQL::Maker::Plugin::JoinSelect N+1問題という近年まことしやかに語られるようになった言葉があります。当たり前の事象に大げさに名前をつけるのどうなのかと思ったりもするわけですが、名前が付いていると案外説明に便利だったりして「名前重要」だなーとか思ったり思わなかったりするわけです。 最近はTengを便利に使わせてもらっているわけですが、Tengはシンプルな分、何も考えないで使うとN+1問題が多発してしまいます。そう言う思想なわけです。 クエリ数を抑えるためにJOINしたクエリを投げたくなるわけですが、そうなると自分で投げるしか無くて、それはまだいいとしても、普段Rowオブジェクトを使い慣れているゆる
おそらくはそれさえも平凡な日々: Perl製のWebアプリケーションをherokuで3分で動かすの法
PSGIアプリなら簡単にherokuで動かせます。 Miyagawaさんのbuildpack(https://github.com/miyagawa/heroku-buildpack-perl)を 使います。使い方もREADMEに書いてあったけど、以下にも書きます。 アプリ側の準備 deployしたいアプリケーションのgitリポジトリ上で以下をやります。 cpanm --installdeps . で依存モジュールがちゃんと入るようにする(cpanfile使うのがオススメ) アプリ起動用のapp.psgiを配置する herokuにアカウントを作る https://www.heroku.com/ toolbeltを入れる https://toolbelt.heroku.com/ インストールが終わるとherokuコマンドが使えるようになります。 % heroku login と打ってコマンド
おそらくはそれさえも平凡な日々: App::Xaicron構想
タスクの定期実行としてcronが使われ続けていることに問題意識を抱えている人は数多く居れども、多くは惰性で使い続けている。何を隠そう私もその1人である。 そんな中、近年ではcronの代替としてjenkinsを使うという斜め上の発想が蔓延りつつあるが、 そんなことをすると「cronに500Mもメモリ使ってられるかー」と椅子が飛ぶこと請け合いなので非常に難儀するものである。 斯くの如く問題意識を抱えていたものの、やはり惰性でcronを使い続けていたのだが、 昨日、代替cronのネーミングとして “xaicron” という非常に格好良い名前を思いついてしまったので、 この際代替cronについて考えてみることにする。 懸念事項としては、将来RPMパッケージ化などされた時に、実行ユーザーとしてxaicronが作られてしまって、 万が一xaicronというユーザー名を使っている人がいた場合に困るという
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
おそらくはそれさえも平凡な日々: 2013年のGetopt::Long
完璧な引数処理モジュールなどといったものは存在しない。完璧なGetopt::Longが存在しないようにね。 バッドノウハウの宝庫として有名なGetopt::Longですが、なんだかんだでデファクトで、gnu parallel等、名の知れたコマンドラインツールで使われていたりします。標準モジュール縛りでサクッとコマンドラインツールを書くこともあるでしょうし、そうではなくても、Getopt::Longで片付くことも多いので、個人的なベタープラクティスとかtipsとかを書きます。 Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 大事なことは上の記事に書いてあるので、まずはこれを読んでください。 サンプルコード 僕がスクリプトを書くときのの雛形は大体以下の様な感じ。 #!/usr/bin/env perl =head1 DESCRIPTI
おそらくはそれさえも平凡な日々: PerlのIdiomをCPANモジュールを使って可読性を高くしてみる
今年からKayac技術部では以前以上にPerlを推進する方向で進めています。そんな中でこれまでPerlを書いたことのないエンジニアにもPerlを書いてもらうことも多くなってきたのですが、PerlのIdiomがやはりわかりづらいんだなぁということを感じています。 割りとサクッとやっつけでコードを書くことが出来るのもPerlの良い点ですが、まあ分かりづらいよね...、と言うことで最近はPerlに慣れない人に対しても可読性が高くなるように多少心がけています。 てことで、PerlのIdiomとそれを読みやすくしたものを幾つか。 ファイル一気読み こんな感じで書いてしまうことが多いと思います。 use autodie; も併用することが多いので、or dieとかも書かない感じ。 my $content = do {local $/; open my $fh,'<:utf8',$file_name;<
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
