入門 ソーシャルデータ ―データマイニング、分析、可視化のテクニック

非常に実践的なソーシャルデータ解析入門書。ソーシャルデータの処理は、理屈はともかく実際にデータを取ってくるところでいろいろと知識が必要でなかなか先に進まなかったりするわけだが、この本はその辺りを埋めてくれる。対象は電子メイル、Twetter, LinkedIn、FacebookPythonのコードが掲載されているので、それを使えばとりあえずスタート地点に立つことができる。Pythonが書ける気の利いた卒論生なら、年末にこの本を与えれば1月末までになんとか卒論が書けるんじゃないだろうか。

ちょっと気になるのは日本語処理に関する観点が抜けてること。実際に日本人が使おうとするとそこでひどい目に会いそうだ。

また、2011年発行ということ仕方がないと言えば仕方がないのだが、ちょっと古いところがある。Twitterretweet検索のところで公式RTに関する言及がなかったり、Google Buzz (!)などという懐かしい単語が乗ってたり。

どうでもいいけどこの本、翻訳者1名に、監訳者5名となっている。逆ならまだわかるけど、一体何が起こったんだろうか。。


RDBMS解剖学 よくわかるリレーショナルデータベースの仕組み

  • 鈴木 幸市, 藤塚 勤也

翔泳社DBマガジンに連載された記事をまとめたもの。2005年の発刊なので相当に古いのだけど、
基礎的な内容なのでそれほど古くなった感じはしない。SQLもDBの使い方も知っているけど内部構造を知らない人に向けて、内部構造の概要を解説している。
非常に平易な言葉で書かれており、わかりやすい。文系出身でCSのバックグラウンドはないのだけどSEをやっていて普段からSQLは触っているような人でもすんなり理解できるのではないだろうか。なかなかこうは書けない。

内容は、SQLのパース、論理プラン、物理プラン、トランザクション、ログによる性能向上、クラスタリングと幅広い。その分全体的に食い足りないけど、入門の入門ぐらいの感じとしては非常によくかけてるといえるだろう。ページ数は200ページ弱。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Dustin Boswell Trevor Foucher

プログラムをきれいに書こう、という話はよくあるが、「きれい」というのは基準になってるようで なってない。なので、ついついリファクタリングやりすぎて無駄に抽象クラス作ってみたり、 無駄にファクトリクラス作ってみたりしてしまうわけだ。 この本のポイントは、「きれいに」ではなくて第三者が「読みやすい」「理解しやすい」ように コードを書くべきだ、としているところ。ある意味あいまいだが、基準としてはわかりやすく、 プログラマの立場としてはわかりやすい。

変数名のつけかたから、コメントのかきかた、制御文の順番など、いちいち具体的でおもしろい。 ある意味、当たり前のことばかりなのだけど、自分でこれができているかというと 相当あやしい。。プログラムがひと通り書けるようになった人に、ぜひ読んでもらいたい一冊。


デバッグの理論と実践 ―なぜプログラムはうまく動かないのか

Andreas Zeller

未だに個人的な技芸の域を脱しきれていないプログラミングと言う過程の中でも特に 属人的な要素の強いデバッグという過程に対して、「科学的」な手法を適用すれば システマティックにデバッグできることを示している、かなり画期的な本。 個別のデバッガを使ってどうこうする、という話ではなく、 どのように仮説を立て、それを検証していくのか、という戦略の立て方を論じている。

著者のAndreas Zellerは、デバッグ関連の一流研究者なので、デバッグの研究が 今どこまで進んでいるのかを知るという意味でも役に立つ。 もともと大学(院)のテキストとして書かれたものなので、若干敷居は高いけど 特に前半の戦略を議論している部分はすべての実務プログラマにとって有益なはず。 全体的に若干やり過ぎ感はあるけど、今後進むべき方針を示しているということで。

圧巻なのは14章。gcc2.95.2 にあった特定の式の最適化で無限ループに陥るバグを 全自動でピンポイントに特定している。基本的にはgdbスタックトレースをとって、 各段階でブレークポイントを設定してメモリグラフをgdbをつかってとりだして、 うまくいく場合と行かない場合のメモリグラフを比較するという手法なのだけど、 gccのような大規模なシステムでもちゃんと動くっていうのはインパクトある。

実はこの本、縁あって監訳させていただいたのだけど、 翻訳って本当に難しい。技術的な内容を100%理解した上で、 原文のニュアンスを尊重したうえで、日本語として自然な文章を 書かなければならないのだけど、そんなのほとんど無理だよなあ。。 せめて技術的にはミスがないように心がけたつもりだけど、 何かありましたらお知らせください。。

2週間でできる! スクリプト言語の作り方

千葉 滋

Javaスクリプト言語を作る本。著者は、畏友 千葉さん。お忙しいのに本まで書いて頭がさがる。

体裁は割りに軽めだが、中身はすごい。まずは普通にインタプリタで作り、その後仮想コードコンパイラに仮想コードインタプリタを組み合わせ、さらに型解析までして静的型付けしてJavaバイトコードコンパイル、と大変に盛りだくさん。

parser はParser Combinatorライブラリを自作しているし、構文木のevaluation はお手製アスペクト言語のGluonJを使ってWeavingでやってるし、とやりたい放題。2週間でできるわけないだろ!という。

学生との対話が入る形式は「アスペクト指向入門」と同じ。これで随分読みやすくなっていると思う。機会があったらこの手法を私も使ってみたい。

ところどころに入っている漫画が無駄に本人に似ていて笑える。

よくもこれほどの内容を、このページ数に収めたものだ。一点問題を指摘するとすれば、ソースコードにほとんどコメントがないこと。コメントをいれるだけで随分読者層が広がるのではないか。


さくらクラウド復活

パブリックベータ状態にもどって課金なしとなっていたさくらクラウドだが、あたらしいストレージの性能にめどが立って、10/1より課金を再開するとのアナウンスがあった。なにはともあれめでたい。

publickeyによると、当初の予定とは異なり、完全な自社開発サーバのみでなく、他のベンダ(オラクルではない)のストレージもつかわれているとのこと。また、infinibandではなく10G Ether。iSCSIならこっちのほうがよさそうな気はする。

新規募集再開はまだちょっと先らしい。現在の利用者の様子を見て再開で年内を目標に、とのこと。がんばれー。

Amazon の6月の障害

2012年6月にあったAmazon AWS の障害について。publickeyさんから、備忘録としてさらにまとめてみる。

6月14日にもあったようだが、こちらは比較的単純な電源断。ケーブル障害に発電機のクーリングファン障害が重なったというもので、障害時間も2時間弱。

一方2012年6月29日に起きた障害は、やはり電源障害に端を発しているが、もう少し話がややこしく、障害の範囲が広い。publickeyでは前編後編に分けて書かれている。

何が起きたのか

きっかけは、電源障害。UPSへ移行するも発電機の起動に一旦失敗、UPS作動停止10分後に発電機起動、20分後に復電ということで、電源断時間はわずか20分間。

EC2/EBS への影響

EC2/EBSはデータベースで管理されているが、このデータベースは当然複数のAZに複製されたプライマリ・スタンバイ構成になっている。障害時にはスタンバイへ切り替えるのだが、不完全な状態での切り替えを防ぐために、そこにマニュアル操作が必要な設定になっていた。このため切り替えに時間がかかり、その間リードオンリーの状態になりEC2の操作が全リージョンでできなくなっていた。

ELB への影響

ELBはロードバランサ。複数のAZのインスタンスへのロードバランスを行うモジュールだが、AZ障害時にはそちらのインスタンスへはリクエストを割り当てないようにする役割を果たす。内部的にはELBも仮想計算機インスタンスで実装されているらしい。ELBに関してはこの記事が参考になる。

ELBはAZへの電源断に対して正常に動作した。しかし、復電時にバグがトリガーされ、ELBインスタンスをより大きいインスタンスと切り替える動作になった。同時に、電源断に対応して生きているAZ上にELBインスタンスを起動する要求が入っていたため、キューにバックログが大量に溜まってしまった。このキューはリージョンで共有されているため、このリージョンのELB操作全体が遅くなった。

RDS への障害

RDS(Relational Database Service)は、複数のAZにまたがってプライマリ・スタンバイを構成することができる。プライマリのAZが落ちると、スタンバイが昇格することになっている。
多くのインスタンスではうまく行ったのだが、特定の通信障害パターンでトリガされるバグがあって、いくつかのインスタンスでは手動でフェイルオーバを完了させなければならない状況になってしまった。

所感

AWSほどの巨大システムになると、ひとつの障害の影響の範囲が非常に読みにくいことが分かる。とくに復電時。後発のクラウド事業者も同じ道をたどって学習していくんだろうか。大変そうだ。。