Samurai Frameworkにおけるデバッグのススメ(console.log)
お久しぶりです。智史之介です。前回のブログから大分時間が空いてしまいました。 そして、今回はPHPのお話です。しかも、拙作フレームワーク「Samurai Framework」に関するお話です。
え、興味ない?
ごもっとも。だけど気にしない。
Samurai Frameworkって?
PHPほどフレームワークが乱立している言語ってあるんでしょうか? symfony、cakephp、CodeIgniter、FuelPHP、laravel…。 こんなにも多くのフレームワークを排出している言語で思いつくのは、javascriptくらいです。
多くのフレームワークが現れては消え、消えては現れ、群雄割拠、栄枯盛衰、諸行無常の響きあり、といった風情でございます。
少し古いフレームワークでは、ethna、mapleといったものがありました(ヤダ!年齢がばれちゃう!)。 最近のモダンなエンジニアの方々はその名前すら知らないであろう、過去の遺物です。
私、そのmapleでコミッタをやっていたのですが、kunitさん依存の強いプロジェクトで、kunitさんが動けないと前に進めないという状態で、いつの間にか自然消滅してしまったのですね。 そのmapleの「DI Container」の思想を受け継いで、細々とコーディングを続けていたフレームワークが、そうです、「Samurai Framework」です。
symfonyがようやっとこさ大々的にDIを行ってきましたが、そのはるか前にDIに目を付けていた漢達が日本にいたのです! これは、きっと誇っていいことです。
var_dumpデバッギング
一番好きな関数は、だって?もちろんvar_dumpだろ!
この世の全てのphperは、ご多分に漏れず、みんな口を揃えて同じ回答をするはずです。
我々は、javascriptで実装するときにおいても、無駄にfunction var_dump
を作成し、変数をdeepに展開する無駄機能の実装をしたりなんかするのです。
そんなかわいそうな人々が我々phperなのです。
しかし、そろそろ、みんな気づき始めているはずです。あれ、、、こんなことやってるの、もしかして我々だけ?と。
xdebug
随分前から、意識の高いphperの方々は、xdebugを活用して、リモートデバッギングを行っておりました。 正しい姿勢です。breakpointを置き、そのポイントでの変数を展開して確認できるxdebugはまさにphpにおけるデバッギングの真骨頂。完全体です。
ただし、自堕落で自分に甘い我々は、「ちょっと面倒だけど」と、これだけ親切に色々展開してくれるツールを尻目に思うのです。
いやあ、人間って本当にろくでもない生き物です。
もっと、こう、流すだけ流すからさ、後で見させてよ、的なやつ、、、ほら、いたじゃん、javascriptに。 そう「console.log」的なの!
console.log
前置きが長くなりましたが、ここが本題。Samurai Frameworkでは、console.log的なものをサポートしてみました。
こう書いておくと、それが、ブラウザ側のコンソール画面と…、
built-in serverのログに表示されます。
ブラウザのコンソール画面の方は、javascriptを間に噛んでいるので、text/htmlベースの出力時にしか使用できないのが玉に瑕。 何かしら、header領域を通してのロギングが可能にならないと、全通信を網羅することは難しいのじゃないかな?
最後に
今回、なんの前置きもない、突発的な記事になってしまいましたが、これから、samurai framework頑張ってみて、 「made in japan」のフレームワークが、そこそこ世界でも認知されるようになるといいななんて思っています。
もしSamurai Frameworkに興味が湧いたら、少しでもいいのでいじってみてもらえると嬉しいです。 pull reqとか投げてもらえたら泣いて喜びます。