phpのビルドするゲーム

phpのビルドするゲーム最近やってて、完全に飽きちゃう前に書く。

興味とオモシロとphpと自分の能力バランスとるとここしかないかなーとひとのふんどし集めて一ネタにしようとしている。けど、思ったより厳しい。厳しいのは macbook air上のvirtual boxでビルド数時間ずーっと待った上によくわからないままchefがエラー! みたいなのばっかでトライアルエラーが長い。chefのrecipeちょっと設定いじって、今もtravis-ci用の流用してるだけだし、そもそもphpをほぼビルドしたこと無かった。 あと空きディスク容量が3GBちょっとしかないのがつらい。

やりたいことはphpいろんなバージョンのちょっとずつ違う挙動や野良phpを集めて、phpallでゲラゲラーみたいのです。
で、一個ずつパーツを集めていくと、phpenvとphp-build あとphpall 的なやつが必要。あとはphp-buildのdefinitionsにソースから指定できたら野良phpビルド出来るんじゃね? っていう考え。phpenv使ったときのphpallはphpenv-eachでいける。
https://sanematsu.wordpress.com/2012/06/03/phpenv-each-phpenv-plugin-phpall-2012-part2/

./configureなかったら./buildconf 唱えればいいのは手元のmacbookairだとそれでいけたんだけどうかつにpull reqしていいものかよく分からないからそれを自分で使ってみる。
php/php-srcのforkのグラフ中で見たことあるidをpickup。いまこのdefinitionsでトライアルエラーしてる。はてな人力検索質問してみたけどポイント付けなかったから答え無かった。
https://github.com/sanemat/php-build/tree/custom-php/share/php-build/definitions
改造(魔改造)したPHPをいくつかビルドしたいです。たとえば @mor.. – 人力検索はてな http://q.hatena.ne.jp/1338602560

幸先良くanatooのphp-srcはビルドできたんだけど、moriyoshi, rskyのphp-srcがビルドでエラー出て悲しい。travis-ci用のよく分からないミドルウェア組み合わせと謎のconfigureてんこ盛りなのがだめなのかなー。pearのディレクトリがなくてエラー! とか。ヘーとしか言えない。
マルチバイト使えればいいからmbstringだけあればいいんだよね。たぶん。あとバージョンで挙動違ったりバグ埋まってたりするのがあればいい。これもマルチバイトでよさげ。
書いてて今気づいたけど”改造したphp”って新しいメソッド作りましたーよりこんなoperatorつくっちゃいましたーとかこんな構文が!!とかなので普通のphpだと単純にsyntax errorになって終わり? あれ? いやsyntax errorこそphpenv-eachが活きるのか。
anatooのも制御構造から追加してるし、statement_exist() なんて関数無いのだわ。

広告

phpenv-each, phpenv plugin, phpall 2012 part2

You can use rbenv plugin completely on phpenv. This is follow entry of  https://sanematsu.wordpress.com/2012/06/03/phpenv-each-phpenv-plugin-phpall-2012/

Installation “phpenv each” command with CHH/phpenv

$ mkdir -p ~/.phpenv/plugins
$ cd ~/.phpenv/plugins
$ git clone https://github.com/chriseppstein/rbenv-each.git

Usage
You can get help for the each command by passing the -h option.

$ phpenv each -h
Usage: rbenv each [-v] …
-v Verbose mode. Prints a header for each ruby.

You CAN see rbenv as phpenv, each ruby as each php! You have mind’s eye!

Verbose mode will print a header for each php so you can distinguish the output.

Examples:

$ phpenv each -v phpunit
$ phpenv each -v php -r ‘var_dump(“0x1″==”1e0”);’
#=> This is almost phpall command!

phpenv-each, phpenv plugin, phpall 2012

Added: 2012-06-03 8:06
一帆に使われてるであろう CHH/phpenvでのphpall(実質)について改めて別エントリ書いた。
https://sanematsu.wordpress.com/2012/06/03/phpenv-each-phpenv-plugin-phpall-2012-part2/

そのため本エントリは無用です。

—-

phpenvのplugin, phpenv-each書いた。複数バージョンでphpの実行結果を一気に出力できるphpall(実質)の2012版, 中身はrbenv-eachのコピペ。

https://github.com/sanemat/rbenv-each

Added: 2012-06-03 2:58 CHH/phpenv 用とhumanshell/phpenv 用
https://sanematsu.wordpress.com/2012/06/03/phpenv-each-phpenv-plugin-phpall-2012/#comment-101
@hnw ありがとう!!
CHH/phpenv 用 https://github.com/sanemat/rbenv-each/tree/for-CHH-phpenv
humanshell/phpenv 用 https://github.com/sanemat/rbenv-each/tree/for-humanshell-phpenv

phpallってコマンドじゃないですけど気に入らなかったら自分でwrapしてください。あと、実行結果が出力じゃなかったらvar_dumpで囲むとかもないです。

$ phpenv each -v php -r “phpinfo();”

see: phpallコマンドでPHPの全バージョンの挙動を試す – hnwの日記

rbenv-eachと完全別リポジトリにしちゃうのもどうなのかなーという思いとじゃあこれrbenv-eachにpull reqおくるのか?というのがどうしたもんかよくわからなくてとりあえずforkだけでいいや。

Edited: 2012-06-03 3:00 humanshell/phpenvとCHH/phpenvを区別した
あとこれ書いてて気づいたんだけどhumanshell/phpenvとCHH/php-buildで $ phpenv install かぶってんだよ! というの地味にハマったのでissue書いた。
Issue #1: libexec/phpenv-install and php-build’s phpenv-install have same name · humanshell/phpenv
手元では $ rm ~/.phpenv/libexec/phpenv-install でいいんだけどどっちが名前変えたらいいのかはなんか書き方間違った気がする。

Added: 2012-06-03 2:13 みんなが使ってるのはCHH/phpenv だ! https://sanematsu.wordpress.com/2012/06/03/phpenv-each-phpenv-plugin-phpall-2012/#comment-101
CHH/phpenv だと中身はrbenvそのままだから https://github.com/sanemat/rbenv-each/tree/master/bin の rbenv-eachをphpenv-eachで上書きすればそのまま使えそうだけど、ファイル名rbenv-eachで中身はphpenv-eachってそれはだめだろう。

Added: 2012-06-03 2:38
“ファイル名rbenv-eachで中身はphpenv-eachってそれはだめだろう”バージョン作った。
https://github.com/sanemat/rbenv-each/tree/for-CHH-phpenv
RBENV_VERSION=$php これはひどい

魔改造phpがgithub/tarballなどで上がってる人

そのなかでここいちと接点がありそうな人を検索してる。

https://github.com/php/php-src/network

rsky, yohgaki, anatoo, がパッと見ありそう。普通のバグフィックスかもしれないけど。moriyoshi, chobi_e, yoya, super_rti は探せばあるのかな。 うとくてよくわからんぞ。

Edited: 2012-06-02 13:31
はてな人力検索で質問した
改造(魔改造)したPHPをいくつかビルドしたいです。たとえば @mor.. – 人力検索はてな http://q.hatena.ne.jp/1338602560

phpのprojectはじめかた w/ composer and phpunit

php熱が高まる第二期。第一期はphp-buildとtravis-cookbooksな話でした。

で、phpunitでprojectはじめるならこんなかなーっていう。phpunitが野良パッケージなのが結構微妙。イメージとしてはこんな感じ? 普通にいきなりrails書いちゃうこと多いけど。
$ bundle init
$ echo “gem ‘rspec'” >> Gemfile
$ bundle

https://github.com/sanemat/start-phpunit

readmeに手順コピペした

Edited: 2012-06-02 21:13

PHPの外部ライブラリの管理にComposerを使う | Ryuzee.com http://www.ryuzee.com/contents/blog/5681

野良パッケージ使うより、まあ呪文ですがpear channel追加して インストールのほうがいいです。

Edited: 2012-06-02 21:37

json手で編集するなんて頭がフットーしちゃうよー
http://jsoneditor.net/
json editorぐぐったら出てきた

php5.2でテスト動かすの難しくて憤死

php5.2のテストtravis-ciで動かしてphp5.2対応って気軽に言う奴らを憤死させよう!って社内LTしたらさっそく自分で憤死するはめになった
– composer requires php5.3+
– pyrus requires php5.3+
– setupでtest skipのマーク付けてもnamespace付きのコードが混じってるとphp5.2でsyntax error
そしてまだtest failじゃなくてfatalなのがきびしいがそろそろ飽きてきたのでpull requestでadviceもらうことにした

phpenvとphp-build

現時点2012-05-24の印象メモ。phpenvと(travis-ci-)php-buildってイメージ。どうしてもtravisに引っ張られるし最優先で実装されるのはtravisに使うからってのが多そう。ユースケースに牽引される健全ですね。ruby-buildはまあパッチとかはまらなければ 今日時点だとreadlineぐらい? でsnow leopardにも入るぐらいにはこなれてるけどまだそこまでは行ってないかなあって感じ。rvmはこなれてるけどいまや巨大すぎ。rehash。もちろんphpenvとphp-buildは使うべき。Ubuntu 11.10 Oneiric 32bit版から機能実装されるのはそういう理由っぽい。あとはtravis-ci用のきれいな環境が立ち上がるから、合わせ技で確認が同時にできて楽なのもありそう。うまく入らなかったらpull requestなげればいいね。手元のmacbook airだとphp-build使うとまだビルドにしくじるんだけど誰か直して。

My biggest contribution day for php!

Today is my biggest contribution day for php ever! Community people gave me a lot of advices. I’m very very excited!! My piece of code will be part of travis-ci!

– php-build (https://github.com/CHH/php-build)
“Builds multiple versions of PHP.”
Pull Request #59: Add comment out on extension_dir in php.ini. especially for php5.2. by sanemat · CHH/php-build
https://github.com/CHH/php-build/pull/59
All people can use php.ini in php5.2! … php5.2 ;(

– travis-cookbooks (https://github.com/travis-ci/travis-cookbooks)
“collections of Chef cookbooks for setting up, VMs for running tests (CI environment)”
Pull Request #57: Add php.ini suffix. by sanemat · travis-ci/travis-cookbooks
https://github.com/travis-ci/travis-cookbooks/pull/57
All people can use default php.ini on php5.2! … php5.2 ;(

Yeah!

phpmatsuriでTDDワークショップのサポートしてきた

ぼくからみたPHPmatsuri。時系列順にダラダラと。

事前
事前にそれなりに準備したけど、途中でめんどくさくなる。
https://docs.google.com/document/pub?id=1-FRoaPj048otlAVXD3nwllxg3NtTrpwlvnXkZY73GiQ

fibonacci数列のサンプルプログラム書いててはまってテンションも落ちる。

phpmatsuriの俺のファインプレー2つ
– we have IRC channel
遅刻して空いてる席に座ったら右がkrisで左がjoelだったので、 “we have IRC channel #phpmatsuri irc.freenode.net”って書いたテキスト見せたら”おk”って二人ともIRCに入ってきた

– where are you from ?
rubykaigiで見ていいなーと思ってたので空いてたホワイトボードに付箋をペタペタ貼った。まるぱくり。
途中で誰かが日本地図と世界地図を書いてくれて、見た目もかっこいい感じになった。

目標
ursmがhamlのpatchをおもむろに送り付けるという日本hamlの会の活動を聞いたことがあって、そういうのやってみたいと思ってて、よく使うライブラリにいきなりテストコードを送り付けるのをやってみようと思う。
この辺の時点でもうペアプロ祭りをやる気はなくなっていた。題材がうまく選べないし。NetUserAgentMobile や 絵文字なライブラリを眺めてた。

TDDワークショップ
このころ(17時頃)hirocasterがTDDワークショップやりたいっていいはじめて、やぶさかではないし、これはこの人たちをこのままほっといたら死んでしまうしそれはあまりに不憫なので、サポートすることにした。まずお題も決めてない状態で、IRCで、LRUHashとかbowlingとかTDDByExampleのbankとかいろいろアイデアを出して、IRCにいたtenkomaにムチャぶりしたらFizzBuzzでいいんじゃないの、と。だので FizzBuzzでいこう、とはじめる。

hirocasterが「limeでやれるようにlimeとからのFizzBuzzTest.phpとFizzBuzz.phpを用意してみた!」って言ってたので、軽くリポジトリ見てみるとうーんというかんじで、これはこちらに引き寄せないとしんでしまう。limeでfizzbuzzの素振りをして、さらに勢い余ってphpunitでfizzbuzzの素振りをしてみた。

http://github.com/sanemat/PHPMatsuri-TDD
case-lime ってtagづけしたのがlimeで、その延長上で case-phpunit ってtagづけしたのがphpunit。

jirei night終わって帰ってきたhirocasterとどうすすめるかについて、ほんとに軽くミーティング。「どうすすめる?」「どうすすめるのがいいと思う?」「hirocasterのmacでペアプロするのがいいんじゃないの 俺driverするから説明して」「じゃあそれでいこう」よくこれで会話が成り立ったなーと思う。気心知れているのっていいね。

夜中の1時から2時前ぐらいまでTDDのワークショップをやった。

ペアプロにはならずに、ほぼおれがdriver独占してて
http://www.mightyverse.com/media/69aea61b-af58-453a-8faa-dbb1a7426f43

と言われかねない状況だった。

リアルタイムな成果はこのmaster
http://github.com/hirocaster/PHPMatsuri-TDD

FizzBuzzをつかったTDDの説明としてはぼちぼちの出来だったと思う。少なくともだいたいの人にふーんなるほどというところまでは持っていけたと思う。ウソ言ってないかなーとたまにちらちらsizuhikoとtenkomaの方みたけど明らかにおかしい顔はしてなかったのでよしとする。サポートしてくださった参加者の皆さんありがとうございました。

で、この一発目で実装できそうな課題をTDDでやることが目の前のレガシーコードに対していますぐなんの役に立つの?
といわれると難しい。こんなのいいからそこやれよ、という不満の顔もかんじたけど、ワークショップの論点とはちょっとずれるので、みなかったことにした。レガシーコードな現実と闘う方法は各フレームワークのたこつぼのなかで消化していくしか現実的でないと思う。すくなくともsymfony1系の”functional test”についてはまず社内向けにどうにかしてみようかと書いてて今思った。functional といいつつ想定しているのはあきらかにend to endなテストなので用語としてはあやしいsymfonyイディオムので””でくくっておいた。そのへんはjobeetからして用語は意図的に(?)混同しているのである程度は気にしても仕方ない。

これでエネルギーを使い果たして、次の日(phpmatsuri 2日目)とその次の日(月曜日)はぐったりしていて、使いものにならなかった。おしまい。