K.Sasada's Home Page

2014年は色々記念すべき年でした。

• YARV 開発 10年目
• 日本Rubyの会 10年目
• Rubyist Magazine 10年目
• 結婚 1年目

毎月くらいに海外に行っていました。招待してくださった方々には深く感謝いたします。 おかげさまで35になったんですが、まだまだ初めてのことばかりでした。

まとめます。

• 1月　福岡（福岡Ruby大賞・審査会）
• 2月　福岡（福岡Ruby大賞・表彰式）
• 3月　RubyConf.PH（初フィリピン）
• 4月
• 結婚式（初。フィリピンの１週間後で、おなか壊していた）
• Rubyconf 台湾（２度目。故宮博物院が凄くよかった。ほかも色々）
• 5月　小笠原
• 新婚旅行
• 片道25時間の船の旅
• 初シュノーケル、初イルカと泳ぐ、初ウミガメの産卵、初ウミガメの肉を食べる）
• 6月　RedDotRubyConf（初シンガポール）
• 7月　DeccanRubyConf（初インド・プネー、初Visaが必要な国）
• 8月
• 福岡（帰省、あなゆきを見て、我が家であなゆきブームに）
• RubyConf Brasil（初ブラジル・サンパウロ、Visaが必要な国２つ目）
• 9月
• RubyKaigi（東京・船堀。初国内でキーノート）
• UnagiAward 受賞
• 結婚記念日（１年目）
• 10月　引っ越し（東京都江東区→東京都文京区）
• 11月
• RubyWorld Conference（島根県・松江）
• RubyConf（アメリカ・サンディエゴ）
• 2回目のサンディエゴ
• 初ミッドウェイ空母
• Heroku new office（アメリカ・サンフランシスコ）
• SFオフィス引っ越してから初めて訪問
• 初Podcast recording
• 初airbnb
• 12月
• 三鷹Rubyプログラミングコンテスト
• 松江Ruby会議06
• Ruby 2.2.0 リリース（すんなり出たけど、色々と問題は残っていますねえ）
• 福岡（帰省。今ここ）

2.3.0 の目玉機能を、何か考えなくては。

来年も、どうぞよろしくお願いいたします。

メリークリスマス。

職場が丸の内で、まわりがイルミネーションで綺麗で、凄い人出でしたが、今年は全然悔しくない。

ベンチマークの話。パラメータを変えたビルド A とビルド B で、走らせてみると、GC の挙動で予想外の結果。gc_tracer で得られる情報を元に、色々探ってみても原因がわからない。具体的には、incremental gc のアリ無しで major gc 回数が違う。incremental gc 回りを全部オフにしたビルド B に比べて、通常のビルド A の major GC が多い。比べてみると old objects の数が多いし、major GC でもあまり減らない、ので major gc の回数が多い、という話。

incremental gc の step count を思い切り増やして、実質 incremental じゃなくしても（1度で全部終わるようにしても）同じ。何故か、バグか、と思って 1 日調べていたのだけど。

結論はインストールしている gem の個数であった。ビルド B は今回新しくビルド・インストールしたもの。ビルド A は、以前から使い回しているので、関係ない gem が入っていた。

うーん、bundler を使っているから、使わない gem は影響外かと思って、大丈夫だと思ったんですよね。実は、そうでもなかったという。

というわけで、不要な gem は入れない方がいいかもしれませんね。

経費精算は重要な業務である。例えば、海外出張に行くと、山のように領収書が貯まる。とくに、弊社の上司や同僚は、経費精算が苦手な人が多いので、積極的に私が支払って、手間を肩代わりするようにしている。なので、今回の RubyConf の経費が凄いことになった。

弊社では、経費精算に concur を利用している。concur は、経費精算をまとめてくれる SaaS で、領収書をアップロード→経費精算レポートを作成→承認フローに載せ、支払い、まで管理してくれる。

で、これまで領収書のスキャンは、Scansnap で適当にやっていたんだけど、アップロードがえらい面倒だった。のだけど、最近2つの方法を聞いた。まずは、iPhone で写真を撮ってアプリで簡単アップロード。これは簡単そうである。それから、ブラウザ上で、領収書ストアにドラッグアンドドロップでまとめてアップロード。これも楽である。というか、今まで1ファイルずつ、ダイアログを選んでやっていた。

というわけで、最近の主な業務である経費精算レポートの作成について書いてみた。

紙のレポートの提出も、はやく要らなくなればいいのにね。 そういう話もあるようだけど。

今年はつらくなったんで advent calendar やらない（去年も途中で放置してしまった）。

https://bugs.ruby-lang.org/issues/9891 で、どうやら malloc() 失敗の処理が不十分、ということで、failmallocを初めて使ってみた。てっきり、ランダムに落とすだけかと思ってたけど、FAILMALLOC_SPACEを使えば、「一定サイズ malloc() したら、失敗する」ようにできることがわかり、これで用が足りると言うことがわかった。

ただし、総 allocation 量しか数えていないため、free() で解放したら失敗しなくなるわけではない。なので、「メモリ制限のあるシステムのエミュレーション」みたいなことは出来ないことがわかった。例えば、200MB と指定して、200MB 上限に来たら malloc() 失敗 -> GC する、みたいなことをチェックする用途には使えない。

failmalloc() 自体は、200 行くらいの小さなものなので、こういうことを出来るようにするのは、そんなに大変じゃないと思う。例えば、ベースシステムのメモリの逼迫度に応じて fail するように変えてもいいかもね（そっちのほうが、free() をおっかけないでいいから楽かもしれない）。

ちなみに、Ubuntu じゃ、ビルド出来なかったのでちょっと弄った。

void (*__MALLOC_HOOK_VOLATILE __malloc_initialize_hook) (void) = failmalloc_init;

なんか、警告がイッパイ出たけど、この辺 obsolete なんですかね。