退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
Daiku and Daikufile are now production ready | おそらくはそれさえも平凡な日々
https://metacpan.org/release/Daiku Daiku, building tool by perl now support many features inspired by rake and I released version 1.00. We can automate building or any tasks in your project by using Daikufile and daiku command. Addtion, you can create your original automate tool by use Daiku; in your scripts. Most of DSLs (ex. desc, task, rule, file, sh and namespace) are taken from rake then, you
DBI->connectの第4引数の内容は設定ファイルに書かないほうが良い | おそらくはそれさえも平凡な日々
Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
レコードがなかったら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
Gitのマージ済みのリモートブランチをカッとなって一括で消す方法 | おそらくはそれさえも平凡な日々
% git branch -r --merged | grep -v origin/master | perl -pE 's!^\s*origin/!!' | xargs git push --delete origin あとは、git fetch --pruneとかやれば、git branch -r もスッキリして良い。 --mergedにorigin/masterとかが現れるので、grep -v origin/masterとかやって無理やり抜いてある。git flowとかでdevelopブランチとか作ってる場合はそれも抜いてやる必要ありそう。 その辺の--mergedの判定がよくわからない(どこかにマージ後にコミットが発生したブランチとかもリストされちゃうとか？)、うっかり思わぬブランチを消してしまうかもしれないので、とにかく「カッとなった」時に自己責任でオススメ。 あと、github
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でマルチバイト文字の文字幅をAmbiguousWidthも考慮して取りたいときのTips | おそらくはそれさえも平凡な日々
08/06 17:45 追記 tokuhiromがText::VisualWidth::PP 0.02を出してくれました。 これには、$Text::VisualWidth::PP::EastAsianというフラグ変数が加わっていて、これにtrue valueをセットすることでAmbiguousWidthの扱いを変更できます。つまりこれでいける。 use Text::VisualWidth::PP; $Text::VisualWidth::PP::EastAsian = 1; my $chr = '…'; print Text::VisualWidth::PP::width($chr); # 2 これで変なバッドノウハウを避けられて万事解決な感じです。tokuhirom++ tl;dr 曖昧幅も全角幅とみなして幅を取りたい場合は以下のようにすれば良い。tokuhiromに指摘を受けて修正しま
最近のPerl例外厨事情 | おそらくはそれさえも平凡な日々
言及してくれていたのをずっと放置していた。 http://soh335.hatenablog.com/entry/2013/06/04/114954 最近結構例外厨で、事あるごとに例外投げたくなってる。結局エラー文字列を正規表現で引っ掛けるより、オブジェクトで引っ掛けたほうがエラーメッセージとかが変わった時に対応が少なくて楽だし、例外を階層化して置いたほうが色々捗る感じがしているので、丁寧に例外オブジェクト投げるように色々ラップしたほうが良いなーとか思ってる。 他言語の人にとっては何を今更みたいな話かもしれませんね。 例えば、Tengの場合だとこんな感じで、Tengはエラー投げるところがhandle_error()で一本化されているので、そこをオーバーライドすれば自分の好みの例外を投げ分けるとかができる。この場合だとユニークキー制約に引っかかった場合は異なる例外を投げるようにしてある。My
おそらくはそれさえも平凡な日々: memcachedのflagsってのが何のためにあるのかっていう話
memcachedで値をセットするときに以下みたいな感じでセットするわけですが、 この<flags>ってのが何のためにあるのかいまいちよくわかってなかったわけです。 set <key> <flags> <exptime> <bytes> <data> で、Cache::Redis書いてた時にCache::Memcached::Fastの実装を見てたら、 あーこれ大事だわってなった。C::M::Fだと、ストアされているデータが シリアライズされてるか否か 圧縮されてるか否か 文字列か否か みたいな情報をこのflagsに持たせています。 C::M::Fはオブジェクトやリファレンスはシリアライズして、 単一スカラ(数値や文字列やバイナリ)はシリアライズせずに値をストアするように なってます。これはデフォルトのシリアライザであるStorableが単一スカラをシリアラ イズできないというのもあります
おそらくはそれさえも平凡な日々: 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 と打ってコマンド
おそらくはそれさえも平凡な日々: Perlの引数の渡し方の想像上の歴史
一般的な以下の様な渡し方について。 func($foo, $bar); func({foo => $foo, bar => $bar}); func(foo => $foo, bar => $bar); 昔は1だったけど、2って書けるのも分かりやすくて良くね？ってなって、1でも2でも指定できるような書き方が出てくるようになった。 だんだんこの場合は1にすべき2にすべきっていう住み分けができてきて、両方の指定ができるみたいなのが減ってきた代わりに、じゃあ3の書き方で良くね？ってなってきた。今度は、2でも3でも指定できるみたいな書き方が出てくるようになった。 僕は最近は3決め打ちで良くね？って感じてきている。MouseとData::Validatorを便利に使わせてもらってるんで結果的には両方いける感じになっていることが多いけど。 値をhashに詰めるのとhashrefに詰めるのどっちが好きか
おそらくはそれさえも平凡な日々: 「仕事に対する愛と情熱とプライド」若しくは新卒に向けたスピリチュアルな話
そろそろ新卒研修とかどうしようかとかで、エンジニア陣でわたわたしたりしています。「Songmu先生にはスピリチュアルな話をしてもらわないといけませんね」みたいなことを言われてなんかスピリチュアルキャラとして定着しているのもどうかと思います。 去年も「『仕事に対する愛と情熱とプライド』ってお題でソーシャルゲームチームの新卒向けに話してください」とか研修担当の人に言われて、なんでそんな熱いキャラとして認知されてるか謎だったんだけど、それで30分くらい話しました。 それが結構評判良かったみたいで、直接はあまり言われなかったんだけど「研修の時の先輩の話の中で一番印象に残っている」って言ってくれている人が多いって話を2年目の人から又聞きで知って嬉しく思っていました。 とか思っていたら、hisaichi5518の人は「なんかすごくいい話してた覚えはあるんですけど内容全く覚えてません」とかsoh335の
おそらくはそれさえも平凡な日々: 運用におけるcrontabのテストとParse::Crontab
Vixie cron形式のcrontabをparseするモジュールをリリースしました。 Vixie cronと言えば、けんじおじさんに「カビ臭い」とかdisられそうな代物ですが、なんだかんだで利用している人は多いでしょうし、僕も使っています。 https://metacpan.org/release/Parse-Crontab 最近携わるプロジェクトではcrontabはリポジトリ管理しているのですが、それをあまりちゃんとテストをしてなかったので、それを解消すべく書きました。 以下の様に、crontabのテストを書くことが可能です。 use strict; use Test::More; use Parse::Crontab; my $crontab = Parse::Crontab->new(file => 'data/crontab.txt'); ok $crontab->is_vali
おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました
主催の皆様素晴らしいイベントの提供本当にありがとうございました。 まさかの2連覇ですが、@fujiwaraの恐ろしさを再認識するとともに、@typesterのチート性能を見せつけられた感があります。 まずは個人的な反省点から 去年よりかは大分成長しているつもりだったのに、@fujiwaraとの力関係が何もかわっていなかったことに衝撃 @typester(Redis期)がRedis使ってくることはわかっていたのに、競技中に brew install redisとかやってるのはダサすぎ ということで、isucon2を振り返ります。 事前準備 事前にIRCチャンネルを作っておいてnopate botを呼んでおいたくらい。カヤックから別チームも出ていたので、お互いのチャンネルには入らないという紳士協定。 去年の経験から、revサーバーに直接gitリポジトリを作れれば捗ることは分かっていたので、その
おそらくはそれさえも平凡な日々: たとえばgetを避ける
プログラムでは複数の意味を持ちうる単語は避けるというのがある。noとかrightとかが良い例だ。個人的に最近はgetも気をつけたほうが良いと思っていて、メソッド名にgetを使いたくなったときは大体間違えている。 Javaなんかのgetter/setter的なやつは、オブジェクト指向以前のパラダイムの名残でしかないと思ってる。手続きの内容をメソッド名にしているという、手続き型のパラダイムを引きずっている感。 例えば、 user.get_money みたいなコードがあった場合に、ユーザーがお金を獲得するのか、ユーザーの所持金額を取り出したいのかが分からない。オブジェクト指向的には前者が正しいのだけど、歴史的経緯から後者の意味合いで使わえる事が多い。プロパティの値を取り出すことが期待されてしまう。それが気持ち悪いので、getは極力使わないようにしている。 オブジェクト志向では、メソッド名はオブジ
おそらくはそれさえも平凡な日々: Plack::App::DataSection is released!
ちょっとしたpsgiアプリを公開するときに、画面の体裁をCSS等で軽く整えたいと思うことがあると思います。そういう時に静的ファイルをどのように配信するかが悩ましいところです。 そこで、ディレクトリの中身をモジュールファイルのDataSctionにpackしてそれを簡単にpsgiアプリとして使えるようにPlack::App::DataSectionというものを公開しました。 使い方は簡単です。cpanmした後、以下の様なファイルを準備してください。 package MyApp; use strict; use warnings; use parent 'Plack::App::DataSection'; 1; __DATA__ @@ index.txt あいうえお このファイルを保存すれば以下のように利用可能です。簡単ですね。 % plackup -MMyApp -e 'MyApp->new
おそらくはそれさえも平凡な日々: DBIx::CSVDumperっての作った
DBIx::CSVDumper SQLの結果をそのままCSVで出力したいと思って作った。使い方はSynopsisまんまだけどこんな感じ。 use DBIx::CSVDumper; my $dbh = DBI->connect(...); my $dumper = DBIx::CSVDumper->new( encoding => 'cp932', # 出力エンコーディング(デフォルト: utf-8) ); my $sth = $dbh->prepare('SELECT * FROM item'); $sth->execute; # プレースホルダーなければ省略可能 $dumper->dump( sth => $sth, file => 'tmp/item.csv', #fh => $fh # ファイルハンドル渡したりも出来る ); 別にシェルでゴニョればできるしPerlでやる必要はなさそう
おそらくはそれさえも平凡な日々: Kyoto Tycoonでmemcachedプロトコルの圧縮オプションを有効にすると捗る
最近、セッションストレージはKyoto Tycoonを使っています。ゲームだとFlash生成時の情報をセッションに突っ込んだりするので、セッションデータが大きくなりがちです。それをユーザーごとに頻繁にGet/Setされると結構バカにならないトラフィックになったりulogがすごい勢いで溜まったりします。 Kyoto Tycoonはmemcachedプロトコルで使うことが多いでしょう。実はmemcachedプロトコルには、データを圧縮して通信するオプションがあり、Kyoto Tycoonでもそれを使うことが可能です。 Cache::Memcached::Fastだとこんな感じで指定できます。 my $kt = Cache::Memcached::Fast->new({ servers => [...], compress_threshold => 500, compress_ratio =>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitにマルチバイト名のファイルをコミットさせない方法 | おそらくはそれさえも平凡な日々