Zend Engine 初心者による, Zend Engine 初心者のための発表という感じで話してきました.

今年に入ってから, scribble というなぐり書き用のブログを始めました.
GitHub Pages 内で Jekyll というツールを使って書いているんですが, Markdown で書いて git commit して git push するだけでサクッと公開できるのでとても気に入っています.

今のところ主に PHP 本体や, そのコアであるところの Zend Engine のコードリーディングが中心で, 今回の発表はこれらの記事をまとめた内容です.

闇 PHP 勉強会でのその他の発表はというと, PHP 製のパーサコンビネータとか, OpenCL とか, 魔改造 PHP とか様々で, こんな中でハッシュテーブルの実装について話し手も釈迦に説法なんではないかとかいろいろ危惧しましたが, わかりやすかったという声ももらえたようでよかったです.

この発表では, 既に scribble でも紹介している hashtable_dump という PHP Extension についても紹介しています.

本当は HashDoS 問題を解決したという Perl や Ruby におけるハッシュテーブルの実装についても調べて発表したかったんですが, 今回は間に合いませんでした.
次回の闇 PHP 勉強会があれば是非それらについて発表できればと思っています.

最後に, 主催の @anatoo さん, 会場提供のアシアル株式会社さん, 楽しい勉強会をありがとうございました.

内容はほぼ最近のブログ記事をまとめた感じです.

• php-build で PHP 5.4.0 beta1 をビルドする
• phpenv で複数の PHP 環境を管理する

一度ブログに書いたものを敢えて発表ネタにしたのにはいくつか理由があります.
(もちろん, 一度記事にまとめたネタなのでスライドに起こしやすい, というのもありますが…)

• もっと色んな人に知って欲しい
• もっといろんな人に使って欲しい
• まだまだこなれていない部分があり, フィードバックが必要
• フィードバックやパッチによりもっと改善されるはず

というわけで皆さんどんどん使いましょう.

類似のツールについて

php-build および phpenv と類似の機能をもったツールは他にもあります.
勉強会でも, 例えば phpall とはどう違うのか, という質問がありました.

結論から言うと, 私は他のツールは特に使ったことが無いのでよくわかりません.
ですが, もともと rbenv は Ruby コミュニティではかなり人気のツールですし, 便利な機能はいろいろと揃っており, 比較的失敗の無い選択肢だと考えています.

また, phpall の違いとして, phpall は各バージョンのバイナリをそれぞれ php-5.2.8 といった, バージョン番号付きのファイル名にしているようですが, phpenv は php コマンド自体を自由に切り替えます.
特定のコードを複数のバージョンで一気に実行する, というときには phpall が便利そうですが, ライブラリの開発等には phpenv の方が適していると思われます.
また, phpenv においては pyrus, phar, phpunit といったコマンドも各バージョンごとに試すことができる, というのも大きな利点です.

phpenv のプラグイン機能について

元々, これまでのブログ記事をまとめただけの発表にするつもりでしたが, ひとつだけおもしろい機能を見つけたので, そこだけ新ネタです.
phpenv の元になっている rbenv にはプラグインという機能があり, 専用のディレクトリにシェルスクリプトを配置するだけで簡単にサブコマンドを登録できる, というものです.
当然 phpenv でも使える機能です.

phpenv each によるコマンドの一斉実行

rbenv のプラグインとして公開されているものの中で, とりあえず rbenv-each というものをつかってみました.
これは rbnev (もしくは phpenv) の管理下にある全てのバージョンのバイナリで, 指定したコマンドを実行する, というものです.

とりあえず, php -v によるバージョンの確認を試してみました.

phpenv each によるバージョンの一斉確認

これ自体はあまり意味の無い例ですが, 例えば PHPUnit によるユニットテストを, 複数のバージョンの PHP で一斉に実行できるすれば, ライブラリ作者に取ってはかなり便利なのではないでしょうか.
それについてはいずれ調べて, また記事にしたいと思います.

このように, php-build と phpenv にはまだまだ便利な使い方がたくさんあるはずです.
利用者が増えることで, そういったノウハウが発掘され, 共有されることを心から願います.

最後になりますが, 今回の勉強会の主催の @gusagi さん, そして会場提供の株式会社 VOYAGE GROUP さん, 楽しい勉強会を本当にありがとうございました.

最近 HTML5 化した Slideshare ですが, エラーで表示できないスライドが多すぎてまともに閲覧できないようです.
この記事に掲載している Flash 版は今まで通りの問題なく表示できるのですが…

スライドが完成したのが勉強会への出発 15 分前で, 通しで練習することすらできず, 発表はかなりひどいものとなっていまいました.
最低限, スライドの流れぐらいは頭の中に入れて発表すべきですね…

スライドだけ見てわかるような作りにはなっていないので, 以下で補足したいと思います.
ただし, 序盤は省略し, 本論となる書法編とパターン編についてのみとなります.

それぞれ該当するスライド番号も付記してありますので, よければご活用ください.

書法編 1: ヘルパーメソッドを使う (25 ~ 30)

テスト対象のオブジェクト, それを生成するのに必要な依存オブジェクトの生成には, ヘルパーメソッドの使用を検討しましょう.
new するだけで済むものであればそれでもいいのですが, 生成に複雑なステップを踏む必要がある場合に威力を発揮します.

これは一般的なプログラミングにおけるサブルーチンみたいなものだと思って問題無いと思います.
ただし, 可読性を問題にするのであれば, 多少長くても説明的でわかりやすいメソッドの命名を心がける必要があります.

テスト対象の生成が複雑だと, 複数のテストの比較が大変になります.
ヘルパーメソッドを使うことで, テスト A とテスト B はどこに有意な違いが有り, 結果に違いが生まれるのか, ということがわかりやすくなります.

書籍 xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) では, Fixture Setup Patterns において Creation Method という名前で紹介されています.
また, これの応用として, 引数付きの Parameterized Creation Method というものも紹介されています.

書法編 2: テストメソッドを分割する (31 ~ 36)

ひとつのテストメソッド内で, いろんなことをテストしようとすると, 何をテストしようとしているのかがわかりにくくなります.
例え同じメソッドを対象にしたテストであっても, 前提条件等が違うのであれば, 分割するべきです.

分割することで, それぞれのテストメソッドには, より具体的な名前をつけることができます.
これもまた可読性に寄与すると言えるでしょう.

これは癖のレベルの話なので, 普段からテストを書いている人であれば無意識にそうなると思います.
まずは 1 つのテストメソッドにおいてアサーションは 1 つまで, というルールを課すことで自然とそういう書き方に近づくと思います.

パターン編 1: 依存性は外から差し込む (39 ~ 49)

スライドでは, フレームワークによくある Request クラスを例に, $_SERVER といったスーパーグローバル変数を使ったときに起こる問題について説明しました.

$_SERVER を使った実装でもちゃんと動作するので, 問題と見なさないこともできます.
しかし, 問題はテストを書こうとしたときに顕在化します.

スーパーグローバル変数に限らず, グローバル変数を利用した実装だと, 複数のテストが影響し合う可能性が生まれます.
スライドではコードで例示しているので, 具体的にはスライドの該当箇所を参照してください.
スライドのように unset($_SERVER['HTTPS']) とすることで回避できますが, コードベースが巨大化すると, 暗黙的なコンテキストが肥大化し, テストを書くのがだんだんと困難になります.

その代わりにどうするのかというと, スーパーグローバル変数 $_SERVER を直接参照するのではなく, コンストラクタやセッターメソッド等で, 引数として差し込む, という方法を採ります.
Dependency Injection (DI, 依存性の注入) というパターンです.
DI を採用することで, 再利用性が高くなるので, テストを書くことで設計が向上する例としては比較的よく挙げられます.

パターン編 2: 外部への依存を避ける (50 ~ 62)

ひとつ前の話を逆に言っているだけですが, 別の側面から解説しています.

外部への依存としては, 例えば以下のようなものが挙げられます.

• グローバル変数/スーパーグローバル変数
• ファイルシステム
• Web API やデータベース等のネットワーク

しかし, もちろんこれらを完全に避けてのアプリケーション開発は考えられません.
それではどうするのか, ということで, スライドでは Active Record の問題点と, それを解決したパターンとしての Data Mapper を例に説明しています.

ここでいう Active Record というのはパターンとしての Active Record で, 書籍 Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler)) で紹介されています.
Ruby on Rails の ORM としての ActiveRecord は, それを実装したものです.

Active Record においては, 1 つのレコードが 1 つのオブジェクトにマッピングされ, それぞれのレコードはデータベースを知っています.
なので, $record->save() といった操作が可能になります.

Data Mapper でも 1 つのレコードが 1 つのオブジェクトに, という部分は変わりませんが, それぞれのレコードはデータベースのことを知りません.
例えば users というテーブルであれば, User クラスがその 1 レコードを表し, UserMapper はテーブルを表します.
(実際にはテーブルをラップしたクラスとして実装されることが多いと思いますが, ここでは単純化しています)
レコードはデータベースのことを知らないので, レコードを保存する際は $mapper->save($record) といったようにする必要があります.

それでは Active Record の何が問題なのか.
Active Record ではレコードがドメインロジック (ビジネスロジック) を持ったドメインオブジェクトとしての側面と, データアクセスを行うオブジェクトとしての側面を持つことになります.
それぞれは全く違った関心事なので, 関心事の分離 (SoC) や単一責任原則 (SRP) といったソフトウェア開発の原則に違反することになります.
テストに関していうと, データベースへのアクセス無しにドメインロジックをテストできない, といったことが起こりやすくなります.
(もちろん, 実装によりますが)

逆に Data Mapper ではドメインロジック (上の例でいうと User クラス) をデータベース無しでテストできます.
データベースに対してテストを書きたいときもありますし, そのためのテクニックもいろいろとありますが, まずはそれらを無視してテストできるようなクラス分割を行うことで, 低コストで確実にテストを書くことができます.

パターン編 3: Singleton を避ける (63 ~ 71)

Singleton は GoF のデザインパターンの中では最も理解しやいもののひとつで, よく使われるパターンのひとつです.
しかし, 同時に批判的意見の多いパターンでもあります.

Singleton ではクラスの static プロパティとしてオブジェクトとその状態がグローバル空間に残ってしまいます.
これはつまり, グローバル変数と同様の性質を持っている, ということができます.

また, グローバル変数と違って, 容易に上書くこともできないので, テストをする上ではさらに厄介な存在といえます.

対策としては以下が考えられます.

• 状態を初期化するためのメソッドを用意する
• アプリケーション本体では getInstance() といった, 常に同一のインスタンスを取得するメソッドの使用を規約化し, テストでは new でそれぞれ独立したオブジェクトを生成し, テストする

また, PHPUnit にはこれらを回避するための –process-isolation オプションであったり, @runTestsInSeparateProcesses アノテーションといった機能もあるのですが, それらについては説明しませんでした.
Singleton を使わなければ, これらの機能について理解する必要もなくなりますし, これらは Slow Test (テストの実行が遅くなる) 問題を引き起こします.

Singleton で実装したくなったとき, 本当に Singleton である必要があるのかについては, 一度考えてみる必要があるでしょう.

参考文献

スライド中に挙げたものです.
書籍へのリンクにはアフィリエイトタグをつけています.

• xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
  xUnit とというのは SUnit (Smalltalk), JUnit (Java) といったナントカ Unit 系テスティングフレームの総称です.
  例として示されるコードは Java のものが多めですが, PHPUnit も書き方を含めて xUnit と呼べるものなので, この書籍で挙げられている考え方やテクニックは, ほぼそのまま適用できます.
  鈍器として人を殺せる程の分量がありますが, 気になるトピックをつまみ食いすることもできます.
• Real-World Solutions for Developing High-Quality PHP Frameworks and Applications
  PHPUnit の作者 Sebastian Bergmann を初めとする豪華な著者陣による, PHP アプリケーションの品質, テスト, 設計についての書籍.
  Symfony の作者 Fabien Potencier による章もあります.
  ソフトウェアの品質についての解説などは他の PHP 本にはまず無いものですし, 非常に刺激的な 1 册です.
• Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))
  アプリケーションのアーキテクチャパターンについての書籍.
  全体的な分量からするとほとんど読めていないのですが, スライド中の Active Record や Data Mapper について参考にしました.
• PHPによるデザインパターン入門
  GoF によるデザインパターンを PHP に翻訳して紹介している書籍.
  新卒の頃に読んで衝撃を受けました.
  残念ながら絶版なので買うことはできませんが, 原稿が公開されているので, 読むことはできます.
  是非電子書籍化して欲しい 1 冊です.

こちらはスライドです.

• Dependency Injection with PHP 5. 3
  
Symfony の作者 Fabien Potencier によるスライド.
  序盤は Dependency Injection の基礎についての説明で, そのあとに PHP 5.3 における DI コンテナの実装について説明しています.
• BEAR DI
  リソース指向のフレームワーク BEAR の作者の @koriym さんによるスライド.
  序盤は前のスライドを日本語訳しつつ引用し, 後半では BEAR の DI コンテナについて説明しています.
• Clean PHP
  PHPUnit の作者 Sebastian Bergmann によるスライド.
  これだけ見て何かを理解するのには向きませんが, Active Record と Data Mapper の比較についてはこれを参考にしました.
• Singletons in PHP – Why they are bad and how you can eliminate them from your applications
  
Singleton の問題点について, 詳細に説明されています.

また, 当日 Ustream で配信された動画はこちらにアーカイブされています.
動画中の一番最初がボクの発表です.
Lightning Talk

この LT では DSL のサンプルとして Paml というテンプレートエンジンを紹介しています.
また, オチとして, [] で DSL だけじゃなく汎用言語も実装できる, ということで PHP で実装された Lisp ライクな言語 LisPHP を紹介しています.

いずれも GitHub にリポジトリを公開しているので, 興味のある方はご覧ください.

• Paml
• LisPHP

結構ネタ的な要素も強いのですが, この発表でボクが割と真面目に主張したかったのは以下の点です.

1. PHP 5.4 では [] が配列リテラルとして導入された
2. PHP の array は他の言語と比べて特殊なデータ構造である
3. その特性を DSL 的に活用することができる

スライドのまとめと若干表現が違っていますが, 大筋は変わりありません.

LT の 5 分間ではこれらについて説明しきれなかった部分があるので, この記事で補足しようと思います.

(なお, 同カンファレンスで他の方の発表を聞いての感想などは改めて別の記事に書くつもりです.)

1. PHP 5.4 では [] が配列リテラルとして導入された

特にこれ以上の説明は必要ないとは思いますが, 念のため.

今までは配列を以下のように記述していましたが,

PHP 5.4 alpha 3 以降からは以下のように置き換えることができます.

見ての通り, array() を [] に置き換えることができるようになった, というだけで機能的な変化はありません.

いわゆる Lightweight Language はその多くが配列リテラルとして [] を採用していますが, PHP では長らく使用することができませんでした.
パッチを送った @rsky さんを始めとする開発者の皆様のおかげでようやく使用することができるようになったので, 感謝をもって使用しましょう.

2. PHP の array は他の言語と比べて特殊なデータ構造である

これはスライド中でもそのまま説明していますが, PHP が持つ特徴として, 配列とハッシュに区別が無い, ということが挙げられます.
PHP における array は配列っぽさとハッシュっぽさを持った, 特殊なデータ構造であり, それらを混合して記述することができてしまいます.

これもスライド中で紹介していますが, PHP では以下のような記述が問題なく通ります.

そしてこちらはスライド中に一度入れて後に割愛したものですが, 要素の順序を入れ替えたらどうなるか.

表示上の順序こそ記述した通りの順番に変わっていますが, 集合としては等しい値であることがわかります.
0 番目の要素のあとに foo という要素を追加して, さらにもう一つ要素を追加しても, その要素には添字として 1 が割り当てられます.

3. その特性を DSL 的に活用することができる

これらを踏まえて, [] で奇妙なデータ構造を記述して, DSL っぽく活用することを思いつきました.

いきなりですが, スライドで紹介したテンプレートエンジン Paml を例に出します.
Paml には REPL (インタラクティブシェル) が同梱されており, Paml のコードを HTML に変換して出力することができます.

入力としての Paml (まぁ配列なんですが) の要素は順番が入れ替わっていますが, 出力はいずれも同じになっています.

もちろん, プログラムがそういう実装になっているというのもありますが, 前提としてこの 2 つの配列は集合として等しい, ということが重要です.

実装の詳細としては, この配列とハッシュが混合したデータ構造から, 配列とハッシュをそれぞれ取り出してから処理するようになっています.

スライドでは, より現実的なフレームワークへの応用として, モデル定義の記述に活用することを提案しています.

例えば, phpDataMapper (なんかここ数日アクセスできない状態ですが) という O/R マッパーのモデル定義は以下のようになっていますが,

これを以下のようにしてみてはどうか, ということです.

違いとしては, array() の代わりに [] を使っているのもそうですが, 後者ではデータ型の指定時の type という添字を使っていません.

イメージとしては, 第一引数に型名を指定して, そのあとにはさらなるオプションがキーワード引数として指定できる, といったような感じです.
型名はどのカラムにも指定する必要で省略不可能なので第一引数としていますが, 後は全てオプションなのでキーワード引数にする, といった具合です.

おまけ: LisPHP の紹介

スライド上ではコードとその出力を出しただけですが, ちゃんと実装しています.
以下は円周率 PI と円の面積を計算する関数を定義し, 実際に計算する例です.

その他, examples ディレクトリには LisPHP のサンプルコードもあります.
フィボナッチ数列による再帰の例 (スライドに掲載したものです) もあるので, ご興味のある方は是非.

LisPHP の特徴は以下の通りです.

• PHP の array をコードとして扱う (code as data)
• PurePHP で記述されている (ただし, PHP 5.4 alpha3 以降が必要)
• 同梱の REPL とインタプリタは PHP の eval を利用することで字句解析も構文解析も PHP まかせ

実はこれにも元ネタがあって, 元は Python で書かれた Lispy というものです.
こちらは string.split とかで超お手軽に字句解析・構文解析はしていますが.

((Pythonで) 書く (Lisp) インタプリタ

発表時, スクリーン上に LisPHP のことが出ていたのはたったの 5 秒間でしたが, 思いのほか笑いを取れて満足しています.
同カンファレンスにスピーカーとして来日していた方にもウケていたとのことで, 発表前日夜に思いついて, 5 時間ぐらいかけて実装した甲斐があったというものです.
(逆に Paml へのリアクションは思いのほか薄かった. これもネタだったのに)

まとめ

人前で LT をやるのは初めてで, とても緊張しましたが, とりあえずは満足する形で終えることが出来て良かったです.
素晴らしい機会をくださった PHP カンファレンス 2011 実行委員会の皆様, そして会場で聞いてくださった皆様に感謝致します.

なお, 次回があれば 30 分ぐらいで現場の役に立つ話がしたいと思っているので, 来年以降の開催も楽しみにしています.

Advancing Net::HTTP by @wycats さん

* net/http は並列化できない
* 並列化するためにフォークして net2/http というのを作っている
* 並列化するにあたって Reactor パターンを採用した

ergをすごく偲んで by @m_seki さん

* カスタマイズは誘惑する
* 安易にオプションを増やすことは「仕様の議論からの逃避」

Visual Glitch, using Ruby by @ucnv さん

* とっさにグリッチが必要なときは sed が便利
* チェックサムを壊したりすると表示自体できなくなることがある
* 安全にグリッチするにはどうするか
* 仕様に従って壊すのがマナー
* 動画はキーフレームを抜くことでいい感じに壊せる

ネタ的な発表かと思いましたが, 技術的には思いのほか真摯であり, とても参考になりました.
発表者の方は GitHub に aviglitch というライブラリを後悔されていますが, API, ドキュメント, spec など, あらゆる面で well-mannered な印象です.
純粋に, Ruby でカジュアルに低レベルなバイナリ操作をする上で参考になりそうです.

Ruby遺産とレガシーコード修理技術 by @hsbt さん

* tDiary のコミッタ
* tDiary は 25 年使われる予定
* 既に 10 年使われている
* 各レイヤごとのテスト
** ユニットテスト
** エンドツーエンドテスト
** インテグレーションテスト
* 機能の追加は慎重に削除は大胆に
** プログラマが知るべき97のことにおける @miyagawa さんの言葉
* 継続的インテグレーション
** travis-ci を使えば GitHub リポジトリで CI できる

長期にわたってソフトウェアを育ててきた経験に基づく, 実践的なお話.
機能の追加に慎重になる, というのは, 特に業務だといろいろなしがらみがあって難しいけど, 常に意識して行きたいものです.
No と言える力重要.

O/R Mapper を支える技術 by @makotokuwata さん

* プログラミング言語の機能は分解, 結合, 抽象化
* SQL にはそれらが欠けている
* それらを補完するのが O/R Mapper
* Ruby で SQL を組み立てること自体は抽象化ではない
* named_scope で抽象化しよう
* プログラミング言語の進化は抽象化機能の進化
* モダンな O/R Mapper の機能
** QueryObject の操作
** Collection のように振る舞うこと
** SQL の抽象化
* N + 1 問題
** DataMapper の Eager loading はうまくやっている

去年ぐらいから仕事で O/R Mapper 的なものを PHP で実装していることもあり, 実装寄りの話では一番参考になりました.
スピーカーの桑田さんのお話は去年の Kwartz についてのものもそうでしたが, 洞察に溢れているだけでなく, 非常に明瞭でわかりやすく, とにかく引きつけられました.

まとめ

昨年から引き続き参加しましたが, レベルの高い技術者の考えに触れることができ, 多いに刺激を受けました.
また, 英語を使いこなし, 海外からの参加者と対等にコミュニケーションを取っている方も多く, その店でも自らの力不足を実感させられました.

スピーカー, スタッフ, 参加者の皆様, お疲れさまでした!

主催者が凄い

主催者である桑田氏は過去に、RubyKaigi、PHP Conference、YAPC など様々なイベントにおいて講演を行っている。Web サイト kuwata-lab homepage においては、Python 向けのテンプレートエンジン pyTenjin を始め、多数の開発者向けプログラムを提供している。根っからのプログラマーという印象。

間口の広さが凄い

タイトルの通り、PHP ユーザーを対象とした講習会であり、プログラミングはある程度できることが求められるものの、「Python に関しては全く知らない」という人でも参加できるようにプログラムされている。それでいて、最後には Google App Engine 上で、Big Table を利用したプログラムを動作させるところまで行く。

反面、ある程度 Python が書ける人に取っては、退屈な部分もあったかもしれない。講習会前に 3 日ほど予習していただけの私でさえ、最初の数時間は既に覚えた文法のおさらいがほとんどという感じ。

ただ、桑田氏の、プログラミング一般や、Python 言語仕様に関する理解は凄まじいものがあり、「オブジェクト指向の仕組み」や、「メソッドの名前解決の優先順位」などの、興味深い話も聴けるので、Python がある程度書ける人にも、十分楽しめる内容だったことでしょう。

スケジュールが凄い

10:00 ~ 21:00 という予定で、実際にはそれも少しオーバー。それだけの長時間を、桑田氏ひとりで進める。もちろん休憩はあるものの、全員心地よい疲労感とともに講習会を終えたことと思います。

テキストが凄い

講習会は、桑田氏自作のテキストをベースに進められる。その量、PowerPoint で 200 ページ超。Python と PHP を比較しながらの解説も大変わかりやすい。

コストパフォーマンスが凄い

上記のテキストを始め、準備にはかなりの時間が割かれていることと思われますが、それでも参加費は 1 人 500 円と格安。元が取れないわけがない。

また、女性、カップル、中学生以下は無料となるそうです。

まとめ

初心者にもやさしく、全員が一定の目標を達成に到達でき、主催者がともに喜んでくれる、楽しい講習会でした。そんなわけで、次回も是非参加したいと思っています。
(ですが、次回はもうちょい早めに終わって、懇親会とかもあればと思っていたり。)

仕事で Python を使う、という人は、日本にはなかなかいないかと思いますが、純粋にプログラミングが好きな人は、是非次の機会に参加してみてください。

関連リンク

• Python4PHPer on Google グループ
• #python4phper on Twitter
• kuwata-lab homepage

その他の参加者によるブログ

• 「Python4PHPer 第2回講習会 PHPユーザのためのPythonとGoogle AppEngine勉強会」にいってきた by @kazumeat
• Python4PHPer勉強会　第２回に参加してきました by @mo4ri
• Python4PHPer 第2回講習会参加してきました。 by @k_kaeshima

2 時間という短時間で、ものすごい数の書籍を次々に紹介していくというスタイルで、詳細にはあまり触れない。基本 1 冊に 10 秒もかけずに、次々と進めていく。もちろん、中にはつっこんだ説明があったり、各出版社の編集・営業担当者からのコメントがあったりもするものの、「量が質になる」だけの閾値は超えていたんじゃないだろうか。1 冊平均 60 秒としても 2 時間で 120 冊。とてもライブ感のある、楽しい 2 時間だった。

出版社側からは、WEB+DB Press 編集の稲尾氏 @inao や、404 Blog Not Found における献本御礼でお馴染みのオライリー・ジャパン矢野氏をはじめとする方々。それぞれ何冊か担当して、書評を述べたりするんだけど、オライリー矢野氏がとくに凄かった。

矢野氏は、オライリーよりもむしろ他社の書籍の紹介が多く、ある意味「オライリーらしい」感じ。書評はすっきりしていてわかりやすく、興味を惹かれた。フリー~〈無料〉からお金を生みだす新戦略については、出版業界人という立場から、これからのメディア論もからめ、簡潔に大筋を説明。さらにそこから著者のクリス・アンダーソンについてのうんちくへ繋ぎ、オライリーの雑誌 Make: の宣伝でオトす。鮮やか過ぎて、まったくいやらしさがなく、会場思わず拍手。さらに、美少女ゲームシナリオバイブルについては、「分析と、受け入れられる物の作り込みは、ビジネス的にはおもてなし、ホスピタリティの参考にもなる」という持論を展開するなど、さすがにオライリースタッフは伊達じゃない思った。

気になった書籍

マスタリングTCP/IP 入門編 第4版
エンジニアの教養として、おさえておきたいところ。

まつもとゆきひろ コードの世界‾スーパー・プログラマになる14の思考法
『プログラミング言語 Ruby』とあわせて読めば、Ruby のバイブルになるとのことなので。

デジタルコンテンツをめぐる現状報告―出版コンテンツ研究会報告2009
業界研究。

プログラミングのための確率統計
今の仕事の役に立つんじゃないか。

実践バグ管理―プロジェクトを成功に導くための
これも仕事に直結する内容かと。

ケータイサイトのレイアウト 企業・キャンペーン・サービス・ブランディング……240pxのデザインテクニック
インターフェイスは大事。

アクセス解析によるWebサイト改善術 問題解決モデル30
実践的な仮説検証の本としても読めるとのことなので。

IA100 —ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計
IA についても教養程度にはおさえておきたい。

PHP 逆引きレシピ (PROGRAMMER’S RECiPE)
PHP 本では珍しく、「この人はわかっている」という内容で、安心して読める、とのことなので。

美少女ゲームシナリオバイブル
オライリー・ジャパン矢野氏がビジネスマンに推薦するホスピタリティの参考書。

去年おもしろかった本

2009 年に読んだ本からのリストなので、必ずしも新刊ではないですが。

JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス
JSON の提唱者である著者の、JavaScript 愛がひしひしと伝わる美書。

JavaScript 第5版
サイ本。JavaScript の言語仕様について網羅的に書かれている。

プログラミング言語 Ruby
サイ本と同じく David Flanagan 著。Ruby の強力な表現力を知ることができる。まだ読み深め中。

Rubyによるデザインパターン
GoF パターンだけでなく、Ruby に特化したパターンも含む。

PHPによるデザインパターン入門
パターンで作ることの楽しさ、パターン化されていることの便利さを教えてくれた本。

オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―
オブジェクト指向に至るまでの、プログラミングの歴史。それは抽象化の歴史でもある。

モバイルユーザビリティ・デザイン Web制作者が身につけておくべき新・100の法則。
モバイルについては初学ということもあって、ある意味刺激的におもしろかった。

ウェブユーザビリティの法則 改訂第2版
ユーザビリティについてのインデックスを与えてくれた本。

デザイニング・ウェブナビゲーション ―最適なユーザーエクスペリエンスの設計
インターフェイスの大事さを教えてくれた本。

関連リンク

• ジュンク堂書店 池袋本店 PC 書 on Twitter
• このコンピュータ書がすごい！ 2010年版 on Ustream
• gihyo.jp によるレポート