駒形電産

phpenv + php-buildよりphpbrewの方が良さそうです。（rbenvとぶつかる）

インストール

wgetはcomposerのインストールに必要。

$ brew install automake autoconf curl pcre re2c mhash libtool icu4c gettext jpeg libxml2 mcrypt gmp libevent wget
$ brew link icu4c --force

ふむふむ。

$ curl -L -O https://github.com/phpbrew/phpbrew/raw/master/phpbrew
$ chmod +x phpbrew
$ sudo mv phpbrew /usr/bin/phpbrew
$ phpbrew init
$ echo "source ~/.phpbrew/bashrc" >> ~/.zshrc
$ phpbrew lookup-prefix homebrew
$ sudo phpbrew install -j `sysctl -n hw.ncpu` 5.6.8 +default+mysql+apxs2
$ phpbrew --version   
phpbrew - 1.18.5
cliframework core: 1.10.0
$ phpbrew switch php-5.6.8
$ php -v
PHP 5.6.8 (cli) (built: May 12 2015 17:33:22) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

composerとphpunitインストール。さりげ嬉しい。

$ phpbrew install-composer
$ phpbrew install-phpunit

レガシーがらみで気になったのでサポートに聞いてみた。

マネージドサーバーHDDプランの契約を検討しております。

PHPのバージョンが4.4, 5.2～5.4となっていますが、これはどの5系の場合はどのバージョンになるのでしょうか?

現在PHP公式では5.4未満はサポートが行われていません。 セキュリティパッチなどは御社が独自に提供していただけるのでしょうか。

以下、サポートからの返答。

この度は弊社サービスをご検討いただき、ありがとうございます。

PHPのバージョンは4.4、5.2～5.4の中から任意にお選びいただけます。特に お客様にて設定が行われなかった場合は5.4が適用されます。

セキュリティパッチについては弊社にて独自に作成し、対応を行っております。 ご安心ください。

ご不明な点やご質問等ございましたら、本メール返信にてお問い合わせ ください。

今後ともさくらインターネットをよろしくお願いいたします。

公式のサポートが切れているPHPのバージョンにもセキュリティパッチを当て続けている！？

第89回 PHP勉強会＠東京に行ってMac・Windows共通のPHP開発環境 // Speaker DeckというLTをさせていただきました。

会場は株式会社リジョブさんの咲くらぼというスペース。人工芝に座って人工桜を見ながらビール飲んで勉強会とか最高かよ。

咲くらぼ TECH 勉強会サポート | 咲くらぼTECHブログ - 株式会社リジョブ

また、じゃんけん大会でLaravelエキスパート養成読本をいただきました。ありがとうございます。

LT内容を箇条書きにまとめるとこんな感じです。

• レガシーPHP改善はまずは共通開発サーバーの撤廃からはじめるとよい。
• WindowsでのPHP開発環境をMac上のVirtualBox内のWindowsでサクッとできるとか思うなよ。
• shin x blogは神。
• ansibleはlocalで使え。
• VirtualDocumentRoot + PHPには罠がある。
• xip.ioを活用せよ。
• chocolateyは神ツール。

足ばやになってしまった質疑応答に対する補足。

Q. AnsibleはWindows対応してなかったっけ？

A. provision対象としてはサポートしてるけど、clientの実行マシンとしてはサポートしてません。

Installation — Ansible Documentation

Currently Ansible can be run from any machine with Python 2.6 or 2.7 installed (Windows isn’t supported for the control machine).

Q. Windows対応してないなら何でAnsible？chef-zeroは？

A. ごもっとも。chefは個人的にキモい（ネーミングとかberkshelfとか）。私がruby好きなのでrubyで何でもできるchefをPHPの会社に導入するとやり過ぎてしまうのが怖かった（vagrantはいいのかよ　＞　俺）。など。後は小規模ではchef-zeroよりansibleの方がシンプルで覚えるのも簡単だと思う。

私の構成管理ツールについての苦悩のエントリーはこちら。

構成管理ツールについて - komagata

Q. 技術的な内容ばかりだけど、レガシーPHP改善は「このままでいいや」というみんなのマインドセットを変えることの方が重要なのでは？何か工夫していることは？

A. おっしゃるとおり。答えは例えばみんなを誘ってPHP勉強会に来る、発表する。（３人来ていただけました。ありがとうございます！先月はボッチで行った！）

レガシーPHP改善日記 シーズン2 エピソード1 - komagata

流行りの環境うんぬんは単なる手段であり、"経営陣を含めたマインドセットの更新が大事"ってのはありますが、そんな話みんな読みたくないでしょ？

エピソード1ではこんなこと言ってますがちょっとだけ・・・。

プレスコットのピクルス原理

「漬け水がキュウリに漬かるよりは、キュウリが漬け水に 漬かるほうが早い。」これは、「長いものには巻かれろ」という 世渡り術指南の、ちょうど逆を意味する。 すなわち、大きな仕組みに影響を与えようとして、 接触を続けている小さな個(自分)は、結果として、むしろ自分のほうが変えられてしまう可能性が高い、ということを警告している。

ピクルス原理によれば私が一人息巻いて乗り込んだところでレガシーPHPシステムは変わりません。むしろこっちがレガシー寄りになる。

シーズン1からお読みの方はご存知の通り、レガシーPHP改善にとってPHPコミュニティーと会社をつなげることは既定路線であり、必須のメソッドです。

今回は内容をブログに書くということも了承を得てからお仕事を受けています。（ほう、経験が生きたな）

ピクルスを漬けている瓶に穴を開ける。そしてPHPコミュニティーという大きなプールにピクルスの瓶ごと突き落とす。そして割るぐらいのことをしないとマインドセットは変わらないと思います。

逆にいえば人間はピクルス原理のように周囲の環境に急激に馴染むという性質をもっています。PHPコミュニティーという良い漬け水に浸かれば急速に周囲に馴染んでいき、良いPHPエンジニアになれると思います。（良きキュウリは別の瓶に移って行ってしまうという別の法則もありますが…）

レガシーPHP改善でうかがってはじめに取り組んだのがslackの導入です。それまでIP-Messengerやメールで密書のようなやりとりをしているところにslackを導入し、何かにつけPHP界隈の情報を流しました。

先月も今回の勉強会も1時間前まで「まだ定員に空きがあるのでお時間がある方は是非」などと「こいつウゼェ・・・」と思われても仕方ないぐらい必死の勧誘をしました。

また、今回参加された方がいたことで変化に前向きな方々＝心強い味方を見つけることができました。そういった方々に協力をおねがいして、参加できない方も巻き込むために社内で開催するぐらいの勢いでやる必要があります。

今回唯一の誤算はレガシー改善はまだ途中であり、会社名は改善が成ってから公開予定だったのですが、自己紹介で「今、自己紹介されたkomagataさんと一緒にやっている（略）」と会社名が思い切りバレたことです。

そりゃあそうなるわなと思いました。何が誤算だよ　＞　俺

関連：レガシーPHP改善日記シリーズ

先月になりますが、PHP勉強会@東京に行ってきました。数年ぶり。

第88回 PHP勉強会＠東京 - PHP勉強会@東京 | Doorkeeper

発表

Let tested using a mock with PHPUnit // Speaker Deck

phpunitは当たり前になったけどmockをもっと使おうという話。

PSR-2でLintした結果を見えるようにして、コード品質の最低限を上げる

PHP_CodeSnifferやphp-cs-fixerでPRにLint結果をコメントとして投稿する言語非依存な静的解析コマンドラッパーのSaddlerを作ったという話。

HoundCIとかはdiffのみから警告作ってるから速いのだそうです。saddlerはファイル全体を見ることで可能になるもっと詳細な静的解析を出してくれる。

Laravelの美容口コミサイトへの導入事例（スライドは未アップ）

cakephp使ってたけどlaravelで中規模サイト作ってみたらすごく良かったという話。Googleトレンドでも上昇中らしい。本ももうすぐ出るらしい。

感想

全員自己紹介のテーマが「好きなエディター」だったが、PHPStormが有料にもかかわらず圧倒的に多かった。次点でvim, sublime text2, atom, eclipseと言った感じ。（KLabでは全員にPHPStormが支給され、git clientも内蔵しているそうです。）

laravelは現状のphpフレームワークで一番良さそうに見えた。

powを別マシンから使う時に出てきたxip.ioがクッソ便利なことに今更気づいた。

% ping 192.168.0.1.xip.io
PING 192.168.0.1.xip.io (192.168.0.1): 56 data bytes

xip.ioの前にIPつけるとそのIPを返してくれる。

ってことはvagrantデフォルトの192.168.33.10を返すようにしたら便利だ。

% ping 192.168.33.10.xip.io
PING 192.168.33.10.xip.io (192.168.33.10): 56 data bytes

その前にIP以外のものを付けても同じIPを返してくれる。

% ping foo.192.168.33.10.xip.io
PING foo.192.168.33.10.xip.io (192.168.33.10): 56 data bytes

ってことは設定無しで好きなIPでVirtualDocumentRootが使えるってことだ。

Macに複数サイトに対応したPHP環境を簡単に作る - komagata

ここんとこレガシーPHP改善日記がらみで仮想化技術や構成管理ツールをいじってました。（Xen、VirtualBox、Chef、Ansible、Dockerとか）

結局、"ほぼすべてを使ってみて、そして全て捨てたあとでさあどうしよう"という感じです。こんな苦労はしたくなかった。

全体的な傾向

古いものは大がかりで新しいものは無駄が少ない。

1. 実用的な機能を備えたツールが出る
2. パワーアップ版が出る
3. ミニマル版が出る

イメージ方式（別名秘伝のタレ方式）とレシピ方式がある。

これはプログラム言語でいうとイメージ方式のSmalltalk vs レシピ方式のC言語みたいな構図にある。

イメージ方式は作成が楽で自由度が高い反面、分割再利用が難しい（秘伝のタレ化）。また成果物がデカイ。

レシピ方式は分割再利用が容易な反面、作成が辛い。また成果物は小さいが実行する必要があるので遅い。

現実

• 他人のイメージ／レシピはなぜか使わない。（書き方をパクって自分のレシピに入れることはする）
• 結局全部自分で作る／書くことになる。
• PCセットアップ時に一回取ってくるぐらいなのでサイズどうでもいい。

結論

こと開発環境については何を選んでも苦しみはなくならない。ブッチギリの優位性もない。なので好きなの使え。（環境を導入する側が楽なツールが比較的良いですねぐらい）

PHPでハマったことをPHPの落とし穴と題して逐次書いていきたいと思います。

問題

ログインができない！動いている環境とPHPのバージョンも合わせたのになぜ！？

$_REQUESTに$_COOKIEの値が入ってないぞ。

原因

$_REQUESTの中身はphp.iniのrequest_orderディレクティブの値に依存する。デフォルトではCookieのCが含まれてない。

PHP: コア php.ini ディレクティブに関する説明 - Manual

解決策

php.iniのrequest-orderディレクティブにCを追加する？

そうではなくCookieを使いたい場合はこういった環境依存のある$_REQUESTではなく$_COOKIEを使うべき。コードの意図も伝わりやすい。

しかし、一度大量に混入したcookie用途の$_REQUEST利用を全て修正するのは難しそうだ。単純にreplaceはできないので$_REQUESTでgrepして、文脈から判断するしかなさそうだ。

明確な理由がない限り$_REQUESTはおすすめできない。$_GET, $_POST, $_COOKIEを使うべきだ。

PHPのスーパーグローバル変数（$_から始まるやつ）の扱いは名前が表す通り注意が必要だと思いました。

関連：レガシーPHP改善日記シリーズ

以前書いた下記を使ってport forwardしといてhttp://foo.lvh.me:8080/とかにアクセスする。

Macに複数サイトに対応したPHP環境を簡単に作る - komagata

virtualboxでprivate networkを使うとスマホ確認ができないし、public networkだとboxのポータビリティが下がるし、port forwardだとsslの確認ができないし（rootで起動して443で立ち上げらればいいけど非推奨だし）痛し痒しな感じ。

synced folder遅い問題も、docker使った場合も同じだけどみんなどうしてるんだろう？

週1日のペースで出社して作業してるんですが、なかなか手強いですね。

サイトが沢山問題

でかいレガシーシステム一個と戦うのではなく、30個ぐらいのサイトがあって、それをメンテしなきゃいけないので大変です。

システム的には殆ど同じなので、大元があってそれをコピーして使っています。コピーしたあとはそれぞれのサイトでカスタマイズが入るので分岐していきます。

これは壮大なコピペと同じことなのでメンテ対象のコード行数が増大していきます。一刻も早くこれをしないですむように設計しなおさないといけません。

共通開発環境問題

社内サーバー上に共通開発環境が一つあって、そこに上記の30近くのサイトが並んでます。そこをみんなでいじって、誰かが代表としてsvnにコミットします。

共通開発環境には、誰か一人が開発環境を作ればいいという利点がありますが、二つの問題点があります。

1. 誰が変更したのかわからないのでレビューできない。一つ一つの変更がいい加減になり、いらないファイルが放置されて散らかりっぱなしになる。（スラム化）
2. 複数人が同時に作業していると変更点が衝突する、壊れる。

進捗

とにかくまずはテストを書かないことには変更もできないのでテスト環境の作成を進めています。しかし、固定のパス設定などポータブルになっていないのでローカルやCircleCIで動くようにするまでが一苦労。

最近のPHPだと動かない機能を使っていたら修正。最近のMySQLだと動かない書き方を修正。結局、まずは共通開発環境と全く同じOSをVirtualBox上に用意して動作させることにしました。

これでphpunit + seleniumのテストはなんとか動きそうです。

悩んでいること

テストが動き、コードレビューを機能させるには各自が自分の環境を持つ必要があります。Windowsでは動かない機能も使っているのでVirtualBoxに環境を作ってそこで各自が上記の30超のサイトを開発しなければなりません。

VirtualBoxのSynced Folersは遅いのでWindowsの場合はsmb、Macの場合はnfsを使って・・・など、僕は構わないですが結構敷居が高くて、

「みんなホントにこれで開発してるのかな？」

と不安になってきます。

共通開発環境問題の問題点を解決しつつ、環境構築の手間を少なくする方法は何かないもんでしょうか・・・。

みんなどうしてるのか気になって仕方ないので次回のPHP勉強会東京に参加登録しました。

第88回 PHP勉強会＠東京 - PHP勉強会@東京 | Doorkeeper

関連：レガシーPHP改善日記シリーズ

下記でVirtualDocumentRootを使ってPHP環境を作りましたが、apacheの環境変数的には変わってないようで、デフォルトの値が入ってしまいます。（CentOS 6.6に入っているapache 2.2.15で確認しているので新しいのでは治ってるかも）

Macに複数サイトに対応したPHP環境を簡単に作る - komagata

すごく困るんですが、下記のようにPHPで無理やり書き換えればOK。

<virtualhost *:80>
    VirtualDocumentRoot /srv/%0

    # Ref: http://joshbenner.me/blog/quick-tip-get-proper-document-root-when-using-mod-vhost-alias/
    php_admin_value auto_prepend_file /srv/set_docroot_hack.php
</virtualhost>
<directory /srv/*>
    Order allow,deny
    Allow from all
</directory>

/srv/set_docroot_hack.php:

<?php
$_SERVER['DOCUMENT_ROOT'] = str_replace($_SERVER['SCRIPT_NAME'], '', $_SERVER['SCRIPT_FILENAME']);

なんか危ういですね。