• 第56回PHP勉強会＠関東で PHPUnit について話してきた
• 第57回PHP勉強会＠東京で開発環境構築について話して来た

今回は通常の発表枠で自作の MapReduce フレームワーク MyMR について紹介し, 懇親会でもスライド無しでの LT をさせていただきました.

PHP と MySQL でカジュアルに MapReduce する

最近書いたブログ記事と全くのどうタイトルで発表させていただきました.
内容的にも大体はそこに書いてあることで, 特に新しい内容は特に入れてません.

SlideShare 上では既にはてブがたくさんついていてありがたい限りなんですが, Hadoop もやったことないのに MapReduce を語るという大変イタい内容なので, 間違いなどがあれば @yuya_takeyama までご指摘いただければ幸いです.

MyMR についてはの紹介記事はこちらです.

• PHP と MySQL でカジュアルに MapReduce する
• もっとカジュアルに PHP と MySQL で MapReduce する

Symfony Console 用テストライブラリ SpyOutput と Test Spy パターン, またはその命名問題について

こちらは懇親会 LT でスライド無しで発表しました.
即興と言えば即興ですが, 内容としてはブログにまとめた内容からになります.

• Symfony の Console の出力をテストする SpyOutput 書いた

大体以下のようなことを話しました.

• モックを使ってテストを書いた結果後悔する, ということは起こりがち
• テスト項目が実装の詳細に寄ってしまいがち
• Test Spy で済ませられるならその方が低コストで可読性/メンテナビリティの高いテストが書ける
• SpyOutput の紹介
• モックを使わないと書けないテストがあることも確か
• これは本当にモックを使うべきなのか, については熟考する必要がある

この日は @fivestr さんによるモックオブジェクトフレームワーク Phake についての発表があって, そこに触発された部分もあります.

以上前半の半分が発表で, 後半はこちらから会場に向かって質問させていただきました.
これも内容は SpyOutput の記事中に書いたもので, 「Symfony 等を拡張する単機能ライブラリを書いた場合, そのベンダープリフィクスはどうするべきか」というものです.

いただいた意見は以下のような感じです.

• 自分の名前を使う
• カッコいい名前を考える
• 自分の名前を使ったカッコいい名前を考える

いずれにせよ命名センスが求められるようです…

結論としてはとりあえず Symfony 本体に Pull Request を送ってみて, ダメならそこでベンダープリフィクスを検討する, という方向で考えています.

終わりに

今回は懇親会でもデザインパターンについてなど, いろいろ会話の場を持てて大変楽しい勉強会となりました.
主催の @gusagi さん, 会場提供の株式会社 VOYAGE GROUP さん, 本当にありがとうございました.

あわせて読みたい

• PHP勉強会@東京#58でPhakeの紹介をしました
• Phakeで簡単モックオブジェクト作成
• 入門 PHP 5.4 / Introduction of PHP 5.4
• PHP勉強会@東京 #58 で「入門PHP5.4」の話をしました
• 第58回PHP勉強会@東京を開催しました
• 第58回PHP勉強会@東京に参加してきました

この記事では変更点等について紹介します.

MyMR の仕組みなどについては前回の記事を参照してください.

• PHP と MySQL でカジュアルに MapReduce する

ビルダーによる Mapper/Reducer の定義

元々はクラスにメソッドを定義する形で行っていた Mapper/Reducer の定義を, ビルダーを使って定義できるようにしました.

この方法を使った場合, Mapper も Reducer も無名関数だけで定義できるようになったので, よりカジュアルになったと言えるでしょう.

また, クラスベースの定義では, 入出力のテーブルをコマンドラインオプションで指定していましたが, こちらではビルダーで指定できるようになりました.
なので設定ファイルの別出しすることもできるようになっています.

また, コマンドラインで指定した場合はそちらが優先されるので, テスト時はテスト用のデータベースを使う, ということもできます.

無名関数以外でも, call_user_func_array() で実行できるもの (PHP 5.4 で言うところの callable) であれば何でもいいので, インスタンスメソッドなどを Mapper として定義することもできます.

簡単なものは無名関数でサクッと定義してい, 複雑なものはユニットテストされたクラスのメソッドで定義する, といった使い分けができるようになっています.

クラスベースの定義も一応残していますが, ビルダーの方が圧倒的に使いやすいように思えるので, そのうち消すかもしれません.

コマンド名の変更

以前は mymr execute コマンドでクラスベースの MapReduce 定義を実行していましたが, ビルダーによる定義の追加に伴い mymr class コマンドに変更しました.

Emitter の切り出し

Mapper はもともと \MyMR \Base クラスの emit メソッドを $this->emit($key, $value) として読んでいましたが, 無名関数で同様のことをやるには PHP 5.4 以降の Closure::bindTo() を使用する必要が出てきてしまうため, Emitter クラスを別に作り, Mapper に引数として渡すようにしました.

これにより, Mapper のテスト時には Emitter をモックオブジェクトや Test Spy オブジェクトに差し替えてテストする, ということもできるようになりました.

進捗の表示

元々は実行しても無言で終了していましたが, Map と Reduce それぞれで進捗を表示するようにしました.

進捗の表示

今回 \MyMR \Progress という形で実装しましたが, これ自体の MyMR との結合は緩く, Symfony の Console コンポーネントの OutputInterface にしか依存していないので, 別で公開できればと思っています.

まとめ

遊びで作り始めたものですが, 少しずつ様になって来ました.
まだまだ開発が安定しないので, インターフェイス等は大幅に変わる可能性があると思いますが, 引き続き開発を続けて行きたいと思います.

MyMR については, 3/27 の第58回PHP勉強会@東京で発表する予定なので, 後日スライドを公開する予定です. (今からつくる)

あと, MySQL Casual Talks Vol. 3 の LT 枠でも喋りたいと思っているんですけど, これってもう募集していないんでしょうか…

その Console コンポーネントを使った際に, 出力のユニットテストを行うための SpyOutput というものを書きました.
これは xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)) でいうところの Test Spy という方法を使ってテストを行います.

yuya-takeyama / console-output-spyoutput

Test Spy とは

分類についてちゃんと理解できていない可能性もあるので, 今の所の自分の理解として書きます.

Test Spy オブジェクトはモックやスタブ同様, テストのために使用する偽物のオブジェクトの一種です.
本来使うべきオブジェクトの代わりにテスト対象に差し込んで, テスト対象の動作を行ったあとで, Test Spy に問い合わせることで検証を行う, というものです.

説明だけではわかりにくいと思うので以下の PHPUnit によるテストコードをご覧ください.

Application クラスはコンストラクタで OutputInterface (Console コンポーネントに含まれるインターフェイスです) を実装したオブジェクトを受け取り, 出力はそのオブジェクトに委譲します.

本来であれば ConsoleOutput 等をセットするところを, 代わりにこの SpyOutput をセットしています.
SpyOutput は OutputInterface を実装しているので, タイプヒンティングで OutputInterface が指定されていても問題ありません.

ConsoleOutput は write() や writeln() といったメソッドに文字列を渡すことで, その文字列を標準出力に出力しますが, SpyOutput は代わりにインスタンス変数内に溜め込みます.

Application オブジェクトの実行が完了したあとに, getMessage() メソッドで SpyOutput オブジェクトに問い合わせることで, 本来であればどのような出力がされるところだったのか, を問い合わせることができます.

車輪の再発明では無いのか

作ってから気づいたのですが, Console コンポーネントには既に出力をテストするためのクラスが存在していました.

• ApplicationTester
• CommandTester

Console コンポーネントはそもそもの謳い文句が “Console eases the creation of beautiful and testable command line interfaces.” となっており, いわばこれらのクラスもひとつのウリである, と考えられます.

ちょっと考えましたが, それでも SpyOutput は私にとって必要だと思いました.

これらは Console コンポーネント標準の Application や Command といった, 粒度の荒い単位でのテストを想定して作られたものであり, それより粒度の細かい単位のコンポーネントがある場合は適用することができません.

そもそも私がこれを必要としたのは, あるコマンドラインアプリケーションにおいて, その進捗状況を表示する Progress というコンポーネントを書いていて, そのテストに必要だった, というのがあります.

Progress の使用イメージは大体以下のような感じです.

これを Command という単位でテストしようとした場合, Progress とは関係の無い出力までそこに含まれてしまう可能性があります.

その可能性をできる限り排除するには, Application でも Command でもなく Progress 自体をユニットテストするのが良いでしょう.

このように, SpyOutput を使うことで, Progress だけをテストすることができました.

Progress は Symfony の Console コンポーネントの Application や Command のことは知らず, OutputInterface のみにしか依存していません. 進捗表示機能を SomeCommand 自体に持たせるのに比べると, 疎結合で, 再利用性の高い設計と言えるでしょう.

命名問題

長々と SpyOutput について説明してきましたが, 実はこのライブラリまだきちんとしたリリースができていません.
というのも, ベンダープリフィクスをどうすべきか迷っていて, 今のところ Perl っぽく X をつけて SymfonyX などとしているためです.

Symfony のためのライブラリとはいえ, 勝手に Symfony というベンダープリフィクスを使うのは多分ダメだろうし, そうなると何というプリフィクスを付けるべきでしょう?
どなたか教えてください.

(Symfony 本体に Pull Request 投げて取り入れてもらえると楽なんだけど…)

まとめ

この記事では Symfony の Console コンポーネントの出力をテストするライブラリ SpyOutput と, Test Spy というテスト手法について説明しました.
命名問題が解決したら, Packagist 辺りに公開するつもりです.

便利そうだったので PHP でも実装しました.
Packagist に公開したので Composer でインストールできます.

• yuya-takeyama/retry-handler-php
• retry-handler/retry-handler

何をするものかというと, 例えば HTTP リクエストなど, 失敗する可能性のある処理をリトライしよう, というときの処理を抽象化するためのものです.

インストール

Composer を使用するので, 適当なディレクトリに composer.json を用意します.

そして以下のコマンドを実行すると Composer 自体をインストールした後, Composer で RetryHandler が ./vendor ディレクトリにインストールされます.

使い方

無名関数をラップして, リトライしたい処理を Proc オブジェクトとして生成します.
retry() メソッドを呼び出すと引数に呼び出した数だけリトライ処理を行い, 全て失敗した場合は RetryOverException がスローされます.

リトライ対象の例外を指定する

デフォルトでは RuntimeException かそのサブクラスがスローされた場合のみリトライを行い, それ以外 (例えば LogicException など) の例外がスローされたら強制的に終了となります.

あるライブラリがスローする例外のみを想定してリトライし, それ以外はエラーとする, といった場合は accepted_exception オプションを使用することで実現できます.

待ち時間を入れる

リトライの前に待ち時間を入れたい, というときは wait オプションを使い, 待ち時間を秒単位で指定できます.
デフォルトでは 1 秒になっています.

まとめ

元の Ruby の実装だと Parallel や Thread を使ったとてもクールな実装になっていて, 素の PHP だとそこまではできなさそうな感じではありますが, リトライ処理自体は PHP でも割とやると思うので, 奇麗に書けるといいんじゃないかと思います.

RetryHandler はとりあえず動いた, 程度のレベルで, まだまだ使えない (例えば, Proc の中の値どうやって取るんだ, とか) と思うんですが, その辺りは今後気まぐれで改善していければという感じです.

ところで 2 年程まえにちょうど同じような需要があって作った Retrial というものがあるんですけど, 今見るととても酷いコードで, テストも何がやりたいのかわからない感じ.
まぁこの頃よりはまだマシなコードが書けるようになったんだなと自分を納得させています.

はてなブックマークボタンのトラッキング問題で高木浩光先生が決別ツイートをするに至った経緯まとめ

ところでこの NAVER まとめページを見ていると, *.microad.jp へのトラッキングリクエストが複数行われるのは何なんでしょうか?

microad へのトラッキングのキャプチャ

このブログに行った対応

• はてなブックマークボタンの削除 (WP Social Bookmarking Light というプラグインの設定)
• Zenback のはてなブックマークボタンの削除 (Zenback の管理画面から)
• Zenback のはてなブックマークコメントの削除 (Zenback の管理画面から)

同様の対応を GitHub Pages で書いている殴り書きブログ Scribble にも行っています.

はてなブックマークボタンにはトラッキングするものとしないもの があって, WP Social Bookmarking Light ではトラッキングするもの, Zenback により埋め込まれるものはトラッキングしないものになっていました.
ところが, Zenback のログアウト状態でのトップページに行くとはてなブックマークボタンがあり, これはトラッキングするもので, track.send.microad.jp へのリクエストが確認できました.

このブログでははてなスターも使っていますが, これはそのままにしてあります.
特にトラッキングっぽいことをしていわけでは無さそうだということもありますが, テンプレートに直書きで入れてて外すのが面倒だというのもあります.

また, WordPress では例えば WP Super Cache といったキャッシュプラグインを使用している場合はキャッシュに残っていることがあるので, 削除しておく必要があります.
これは WP Super Cache の管理画面からすぐできました.

個人的に行った対応

• ローカルマシンの /etc/hosts を書き換えて *.microad.jp のいくつかを 127.0.0.1 に向けた
• Chrome のはてなブックマーク拡張をアンインストール

/etc/hosts には以下のような行を追加しました.

CDN っぽいのは別にいいような気もしますが, js ファイルを拒否しておくのは効果がありそうなのでやってみました.
数もそんなに多くないし.

これを追加してからは Wireshark に microad っぽいパケットが引っかからなくなりました.

Wireshark による microad のキャプチャ

…といってもリクエスト先の IP がデタラメなだけでリクエスト自体は行われているはずなので, Destination が 127.0.0.1 のものが引っかかりそうな気はするんですが, やり方が悪いんでしょうか.
どなたか教えていただきたいです.

トラッキングされるものとされないものの違い

トラッキングされないものの埋め込みコードを確認したところ, script タグで指定しているファイルが違うだけでした.

• トラッキングされるもの

  http://b.st-hatena.com/js/bookmark_button.js

• トラッキングされないもの

  http://b.st-hatena.com/js/bookmark_button_wo_al.js

要するにファイル名に _wo_al があるかないかだけの違いなので, はてなブックマークボタンを使い続けたい場合は _wo_al をつける (もしくはそうなっているか確認する) という手段もあるでしょう.

WP Social Bookmarking Light について

前述の通り, WP Social Bookmarking Light では行動履歴がトラッキングされるタイプのはてなブックマークボタンが使用されるようになっていたので, Pull Request を送らせていただきました.
これが取り込まれれば, WP Social Bookmarking Light を使ってはてなブックマークボタンを表示させても, それにより行動履歴のトラッキングは行われなくなります.

とはいえそれがいつになるかはわからないので, 取り急ぎは前述の通りプラグインの中身で _wo_al を付加した js ファイルを指定する方法を取るのがいいでしょう.

まとめ

私自身ははてなブックマークをそんなに利用している方では無いと思いますが, 今回の問題は残念としか言いようがありません.
最近のアップグレードが素晴らしかっただけに, 特にそう思います.

この件について聞いてからもしばらくははてなブックマークを使っていましたが, 何らかの対応が行われるまではしばらく使用をやめるつもりです.

とはいえ, はてなブックマークが提供する機能自体は素晴らしいものだと思いますし, 代替も特に思いつかないので, 良い形でまた利用できるようになればと願っています.

2012-03-11 19:20 追記

/etc/hosts で microad のホストを 127.0.0.1 に向けたあとに Wireshark でキャプチャできなくなった件ですが, キャプチャしているのが LAN パケット (en0) だったせいでした.
ループバックパケット (lo0) をキャプチャすることで, 127.0.0.1 から 127.0.0.1 への *.microad.jp のコンテンツを要求する HTTP リクエストを確認できました.
itsango さんありがとうございました.

2012-03-11 22:50 追記

WP Social Bookmarking Light に送った Pull Request が取り込まれ, WordPress のプラグインポータル側にも反映されました.
最新の 1.7.1 以降であればトラッキングしないタイプのはてなブックマークボタンに置き換わっています.

素早い対応をしていただいた作者の @utahta さんに感謝します.

「始めよう」というタイトルを冠していながら, まったく始められる感の無いスライドになってしまいました.
元々は PHPUnit を使ったことが無いしユニットテストとかも書いたことが無い, という人に PHPUnit に興味を持ってもらうことを目標として作っていたはずなので, それを考えると駄作もいいところ.
ターゲットを明らかに見失っている.

ですが, ここ最近ずっと感じつつも, なかなか言語化できずにいたことをアウトプットできた, という意味では多いに価値があったと思います.
42 ページ目以降の「蛇足 : オレはこう思う」が主にこのスライドで言いたかったことなんだと思います.

継続的に改善を重ねることで絶対精神にプリズムジャンプ, できるような環境を作って行きたい.

移行などを考えると, とりあえずは namespace も Closure も使わずクラス名は Foo_Bar_Baz とかアンダースコアで区切る PHP 5.2 なスタイルで書きつつ, PHP 5.3 や 5.4 でも動作するようにライブラリを書く, という選択肢を取ることになりますが, 全部の環境でテストするのは面倒くさい…
というあなたのための Travis CI というサービスについては以前書きました.

Travis CI で PHP 5.4 も CI する, PHPUnit も Behat もやる

そんな Travis CI ですが, PHP 5.2 に mbstring が入っておらず, そのせいで PHP 5.2 だけテストが通らない, なんてことが起こっていました.

mb_strwidth が無くてテストがコケる

ですがそれも今は昔の話, いつの間にか mbstring 入りで PHP 5.2 環境が用意されるようになったようで, 問題無くテストが通るようになっていました.

テスト通った!

コミット識別子を見ると, どちらも同じコードに対してテストが実行されていることがわかります.

この修正は, Travis CI の PHP 対応に尽力なさっている Loïc Frering さんによるものです.
他にも PHP の新しいバージョンが出るたびに定義ファイルを用意してくれたり, 足を向けては寝られない思いです. (ちなみにフランスの方らしいです)

ところで通常 Travis CI によるビルドを実行するには GitHub に対して push する必要がありますが, 今回の場合のようにコードに変更は無いが再度実行したい, という場合は, 以下の方法でできます.

1. GitHub のリポジトリの Admin から Service Hooks, Travis と辿る
2. Test Hook ボタンを押す

GitHub 上の Travis CI の Service Hook 管理画面

これで push したときと同様の通知が行われ, Travis CI 上でのビルドを強制的に実行することができます.

そういうわけでまだまだ PHP 5.2 な方もどんどん Travis CI を作っていきましょう.

ところがインデックスの作成が上手くできませんでした.
Padrino x Mongoid という構成では, インデックスの作成に以下のコマンドを使います. (長い)

コンソール上では特に問題無く終わったかのようにみえるのですが, 実際は何も起こらずに終わっていました.
MongoDB のコンソールを見ても, 特にインデックスの作成が試みられたようなログは残りません.

調べた所, rake タスク自体に問題がありました.

これはモデルクラスを探索し, 見つかったものを Class オブジェクトの配列として返すものなのですが, モデルクラスのファイルの位置の指定に間違いがあり, 常に空の配列が返って来ていました.
これだと, 探索が行われるのが app/models/*.rb と /models/*.rb となってしまいますが, 実際には models/*.rb を探索する必要があります.

1 Byte の追加でうまく問題が解決しました.
テストはもともと無かったし, ファイルシステムが絡むからめんどいなーと思って書いてません.
すいません…

GitHub で報告したらすぐに取り入れられました.
gem でのリリースはまだですが, これもそんなに時間はかからないと思います.

どうも Padrino のモデルクラスの置き場所が, ./app/models から ./models に移ったようで, そのときの変更のときからずっと壊れていたようです.
多分 7 ヶ月間ずっと動いていなかったみたいなんですが, Mongoid ってあんまり使われていないんでしょうか…

ウェブサービスを作ろうとするとフレームワークのバグにハマり, それの修正で満足してしまって結局ウェブサービスが完成しない, という現象に名前が欲しい.

社内で, 主に MySQL 初学者を対象とした勉強会をやってきました.
社内勉強会ということで, というと言い訳になりますが, いつも以上にゆるふわな内容となっています.

改めて見るとソースどこだよ? っていう情報がいくつかあるので反省.
(「RDBMS を使いつつ, NOSQL で最適化というパターンがほとんど」とかどこのことだよと. まぁ Tumblr とかはそれにあたるみたいですが)

あと, インデックスの仕組みを単純化して話すために B-Tree じゃなくて Binary Search Tree について紹介してますが, この辺も詳しい方の突っ込みが欲しい所です.

ところで勉強会に参加していてよく思うのですが, 勉強会というのは自分で発表してナンボだということです.
これは勉強会で人の話を聞くのは意味が無い, ということではなくて, 自分で調べたときの方が 30 倍ぐらい身に付くんじゃないか, という感覚によります.
どう考えても発表した方がコストパフォーマンスの高い学習ができる.

自分のスキルアップに繋がるからそれはそれでいいんですが, やっぱり社内でとなると, 貴重なみんなの時間を使わせてもらうことにもなるので, 出来る限り聞いてる人の身に付くような工夫を心がけたいなと思います.

そこで今回は, みんなで Binary Search Tree を作る, という参加型の企画を仕込んでみました.
作る, といってもいきなり実装するのはハードルが高いので, ひとりひとりに適当な名前 (タロウとかハナコとか) を順に挙げてもらい, ホワイトボードに Binary Search Tree を書いていくというものです.
(今思えばこれ写真に残しておけばよかった)

思いのほか盛り上がったし, ちゃんと理解してもらえたようでした.
Head First データ構造という感じでおもしろかったです.

あと, スライド中で紹介しているんですが, ハーバード大学のコンピュータサイエンスの授業の動画はオススメです.
教授のテンションがやたら高くて白熱教室という感じ. (ついていくのが大変そうな感じではある)

今回の発表では, Binary Search の文脈で 4:30 辺りの, 電話帳で Binary Search と Linear Search をやってる部分をみんなで観ました.

しかしそれをどう見せるか, ということを気にしだすと, これが何気にめんどくさい.
集計時にメールで報告しつつ, 管理ツールのダッシュボード的な画面でも閲覧可能にしたい, という要求はどこにでもあると思いますが, そのときどきで書いていると, クエリを書く何十倍もの時間がかかってしまったりします.

そこで, 例えば RDBMS の結果セットを与えると, それをサクッと見やすく出力してくれる Tablr というのを書きました.
The MIT License にて GitHub で公開しています.

yuya-takeyama/Tablr – GitHub

今どき PHP5.2 で書かれていますが, その辺は何となく察して下さい.
大した機能は無いですが, 個人的にはこれで日頃の問題をいくつか解決できそうなので, 明日からの仕事に使っていく予定です.

使用例

以下は二次元の配列をもとに, プレーンテキストの表を出力するスクリプトです.

ちょっと長く感じますが, require_once や表のデータの部分を除けば, 表の出力に関しては 5 行ほどしかありません.
ここではデータを直接記述していますが, 実際は RDBMS に対して SELECT クエリを発行したときの結果セット等を与えることを想定しています.

これを実行すると以下のような表が出力されます.

以下では Tablr の機能についてより詳細に紹介します.

フォーマッタ

二次元の配列をもとに, いくつかの形式に出力するためのものです.
これが Tablr を作りにあたっての一番のモチベーションとなっています.

現在利用可能なフォーマッタは以下の 2 つのみとなっています.

• プレーンテキストフォーマッタ
• HTML フォーマッタ

アグリゲータ

それぞれのカラムで集計を行い, テーブルのフッタにその行を追加します.
現在利用可能なアグリゲータは以下の 2 つのみとなっています.

• 合計アグリゲータ
• 平均アグリゲータ

とりあえず必要最低限の機能を実装した, という感じで, 作り込みはかなり甘い感じです.
使えそうな感じであれば, またさらに改善して行きたいと思います.