YAPC::Asia にご参加いただいた皆さん、ご参加いただかなかった皆さん、とにかく話題にあげていただいてありがとうございました！今年は合計で 1,131名もの方にご参加いただきまして。 参加者の皆さんとかの感想エントリはこちらにまとめ中。このエントリに「おつかれ」「ありがとう」などブクマする暇があったら参加者の方は感想エントリを是非書いてください。嘘ですブクマしてください。 YAPC::Asia 2013 感想エントリまとめ（募集中） | YAPC::Asia Tokyo 2013 というわけで、運営側としてYAPC::Asiaに関わるのは今年で最後となったので、凄く楽しかったこととか大変だったこととか思い出とか、運営側として、企画側として、忘れないうちに残しておきたい。 以下、1万2000文字の目次付きポエム。お時間ある時にどうぞ。 YAPCの歴史 Perlは衰退していると言われなが

YAPC::Asia にご参加いただいた皆さん、ご参加いただかなかった皆さん、とにかく話題にあげていただいてありがとうございました！今年は合計で 1,131名もの方にご参加いただきまして。 参加者の皆さんとかの感想エントリはこちらにまとめ中。このエントリに「おつかれ」「ありがとう」などブクマする暇があったら参加者の方は感想エントリを是非書いてください。嘘ですブクマしてください。 YAPC::Asia 2013 感想エントリまとめ（募集中） | YAPC::Asia Tokyo 2013 というわけで、運営側としてYAPC::Asiaに関わるのは今年で最後となったので、凄く楽しかったこととか大変だったこととか思い出とか、運営側として、企画側として、忘れないうちに残しておきたい。 以下、1万2000文字の目次付きポエム。お時間ある時にどうぞ。 YAPCの歴史 Perlは衰退していると言われなが

前提: ゲームに限らずランキング機能が必要になるケースは多い つまり需要はある だが、MySQLで高速なランキング表示は難しい 具体的に言うと、以下の要件を満たすのが不可能 １行の更新コストが要素数Nに対して O(log N) 以下 任意のランキング位置周辺のSELECTコストが O(log N) 以下 ならば、専用のストレージエンジンを作ればいいのではないか いつやるか？　今でしょ！　以下理由 MySQL 5.5以降?だとストレージエンジンをまたぐトランザクションがまともになってるはず*1 ランキング専用でいいから、テーブル構造とか固定でいい（つまり実装が簡単！） ランキング専用だから、テーブル・ロックで十分（つまり実装が簡単！） 更新すると順位がずれる（つまりテーブルの大部分に影響がある）ので行ロック実装するメリットが小さい*2 ランキング専用でいいから、全データをメモリにもっても問題

http://mrubysearch.ongaeshi.me/ RubyKokubanを作るにあたってmrubyのソースやmgem(mrubyのRubyGemsみたいなやつ)に登録されたソースコードを簡単に読めるようにしたいなあ、と思い作ってみました。 一日一回レポジトリを最新に更新してインデックスの再構築を行っています。新しいmgemが追加された時は今の所手動で対応しています(そのうち自動化したい所です)。 自分が追加した(もしくは検索したい)mgemが追加されていない！って人はリクエスト頂ければ追加するので教えて下さい。 mgemじゃなくてもmrubyに関係がありそうなソースコードでしたら追加しますので是非。 ※ 個人サイトのため突然停止したりするかもしれません、ご了承下さい。 使い方の例1 - "!"付きのメソッドはどうやってバインドするの？ 例えばgsub!のような!マークのついた

Linux のシステムコールである write(2) の ドキュメントを読むと Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. This is useful when there are multiple writers sending data to a single reader. Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}. This volume of