はてなブックマーク

前回 の続き。はてなブックマーク300超え は今年どころか 8-p.info 全体で新記録だと思う。ありがとうございます。コメントを読んでいると「いわれてみるとちがうかも…」「それはリンク先にあるのに!」とかいろいろあったので補足です。 そうこうしているうちに、Facebook: Analyzing PHP statically は動画もスライドも公開されていたので、これから見ます。 Hack の型って本当に HHVM は見てないの? 少なくとも parser は読んでるっぽいんだけど… ここは自分の誤認と、誤解をまねく表現があったと思う。元記事にも訂正をいれてある。 Strange Loop のスライド の25ページ目 (“Hack Implementation”) の図で Type Checker が Compiler とわかれているのと、最後の 39ページ目 (“Everyone’s

ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency

groupcache を読む #1 では、外側から groupcache の処理の流れを外側から追ってみた。これで大体、どこに何があるかのあたりがついたので、今回は Comparison to memcached にある memcached に無い機能について、どこで実装されているかを追ってみよう。 Thundering Herd 対策 memcached のような独立したキャッシュサーバーでは、キャッシュが無い場合の処理が、以下のようにだぶってしまうことがある。 クライアント c1 が、キー k1 を get するが存在しなかった。 クライアント c1 は、キー k1 に対応する値を (たとえば MySQL などに問い合わせて) 作りはじめる。 クライアント c2 も、キー k1 を get するが、まだ c1 が作っている最中なので、存在しなかった。 クライアント c2 も、キー k1

groupcache は Go むけのキャッシュライブラリだ。Brad Fitzpatrick が dl.google.com を C++ から Go に書き換えるときに書いたもので、いまでは Google の他のサービスの一部でも使われているらしい。 groupcache は、名前の末尾に “d” がつかないことからもわかるように、memcached のようなデーモンではない。Go で書かれたアプリケーションに組み込めるライブラリで、インプロセスなキャッシュシステムと、複数の groupcache を連携させるためのネットワーク部分から構成されている。 それでは、OSCON 2013 のスライド45ページ目から のサンプルコードをみながら、実際のコード (リビジョン: 0e1c218) を追ってみよう。 groupcache.NewHTTPPool groupcache は、複数のホスト

GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’

Docker はひとつの Linux システムの上で、複数の Linux システムを動かすためのソフトウェアだ。システムの分離には Linux Containers (LXC) を、ファイルシステムまわりには Advanced multi layered unification filesystem (Aufs) をつかっている。 Docker は Go で書かれている。ソースコードは全体でだいたい15,000行で、そのうちおよそ 2/3 が本体、1/3 がテストとなっている。 % cat **/*.go | wc -l 14976 % cat $(ls **/*.go | grep -vi test.go) | wc -l 9797 % cat $(ls **/*.go | grep -i test.go) | wc -l 5179 % Docker Init, Docker Daemo

最近やっと “How Google Tests Software” を一通り読み終わって、あまりに時間をかけすぎたのでまた頭から軽く読み直そうかなあと思っていたところ、Masaki Nakagawa さん経由 で日本語訳が出ていることを知った。 ただ、#rubykaigi バイヤーズガイド ‘13 の これを買うべき人: テストを日常的に書いている人と、テストを書く習慣がない人 というのは、さすがに煽りすぎだと思う。テストを書く習慣がない人は そもそもあらゆるテストが無いなら『レガシーコード改善ガイド』あたりから アプリケーションにテストが無いけど、フレームワークなどの土台部分に支援がある環境なら、あんまり自作しないで、まずはフレームワークを学ぶところから 自分がテストを書く習慣がないだけで、まわりは書いてるなら、まずはまわりを真似るところから はじめるべきであって、その段階で本書に行くの

Q2 になったので月に1回くらいは日本語で書いてみることにした。 ここ数年で Perl に起こった良いことは2つある。 ひとつは PSGI/Plack, cpanminus, carton, cpanfile などいろいろ良いものが他言語から輸入されたことで、Perl で書かなくてはいけない時の面倒が軽減された。それぞれ Ruby でいうところの Rack, gem (1), Bundler, Gemfile に対応している。 もうひとつは Module Counts にみるライブラリ数の推移や、Moose の開発者で Perl 5 にメタオブジェクトプロトコルを入れるはずの Stevan Little が Perl is not Dead, it is a Dead End なんて言い出すくらい、だんだん衰退していることで、なんというか妥当な世代交代だと思う。 Perl で、たとえばなに