PhpStorm Archive

http://shin1x1.hatenablog.com/entry/environment_for_writing_books

PhpStorm 8 が、リリースされましたね！

PHP 5.6 や Laraevel の blade 対応など気になる新機能があるのですが、その中でも、注目なのが、PHPUnit by Remote Interpreter です。

この機能を使うことで、Vagrant VM にインストールされている phpunit をホストの PhpStorm から直接実行することができます。Vagrant による開発が普及してきた今では必須の機能といえるでしょう。

利用するには、いくつか設定が必要となるので、その手順を書いてみます。

対象の PHP アプリケーション

このエントリでは、以下の環境で PHP アプリケーション開発しているという想定で進めていきます。

• Vagrant VM で PHP アプリケーションを実行
• PHPUnit は、Composer でインストール
• PHPUnit の設定は、phpunit.xml に記述

PHP Interpreter の設定

はじめに PHP Interpreter に Vagrant VM の php を指定します。

Preferences – PHP を開いて、Interpreter プルダウンメニュー横にある ... をクリックします。

クリックすると Interpreters ダイアログが表示されます。まず、左上にある ＋ をクリックして、Remote...を選択します。

Configure Remote PHP Interpreter ダイアログが表示されるので、Vagrant を選択します。選択すると、Vagrant 用の入力フォームに表示が変わり、各フォームに自動で値が入ります。ここでは編集せずに進みます。もし必要があれば変更して下さい。

OKを押すと、Vagrant VM と通信して、設定項目が妥当か検証が行われます。問題無ければ、ダイアログが閉じます。

Interpreter ダイアログの左側ツリーには、追加したRemote PHP 5.5が表示されます。右側フォームの General には、Vagrant VM にインストールされている PHP と Xdebug のバージョンが表示されるので、念のため確認しておくと良いでしょう。

OKを押して、ダイアログを閉じます。

PHP に戻ると、設定した Interpreter が選択されています。OKをクリックして、PHP Interpreter の設定は完了です。

PHPUnit By Remote Interpreter の設定

次に PHPUnit の設定を行ないます。Preferences – Project Settings – PHP – PHPUnit を開きます。

PHPUnit ダイアログの左上に ＋ があるので、これをクリックして、By Remote interpreterを選択します。

PHPUnit By Remote Interpreter ダイアログが開きます。Interpreter に先ほど登録したRemote PHP 5.5を選択して、OK をクリックします。

ダイアログが閉じると、右側に PHPUnit の設定項目が表示されます。

PHPUnit 関連のファイルは、Composer のオートローダーから読み込むので、PHPUnit library には、Use custom autoloader を選択します。Path to script が表示されるので、Composer の autoload.php のパスを設定します。なお、この設定は VM 内でのパスを指定する必要があるので注意して下さい。（テキストボックス横の ... をクリックすると、VM 内のパスを GUI で指定することができます。）

次に、Test Runner の Default configuration file にチェックを入れて、phpunit.xml のパスを指定します。（phpunit.xml を利用していない場合、これは不要です。）ここのパスも VM 上のパスになります。

設定が完了したら、Apply もしくは OK をクリックします。これで、PHPUnit By Remote Interpreter の設定は完了です。

Run/Debug Condigurations での PHPUnit 設定

最後に、IDE からテストを実行するために、Run/Debug Configurations にて PHPUnit の設定を行ないます。

画面左上にある ＋ をクリックして、PHPUnitを選択します。（PHPUnit on Server ではないので、注意して下さい。）

Name には、それと分かる名称を記述します。ここでは PHPUnit on Vagrantとします。

次に、Test Runner の Test scope を選択します。ここでは、前項で phpunit.xml へのパスを指定しているので、Defined in the configuraion fileを指定します。（テストディレクトリを指定したい場合は、Directoryを選択して、対象のディレクトリを記述して下さい。）

OKをクリックして、設定は完了です。

PHPUnit の実行

いま設定した PHPUnit を実行してみます。ウィンドウメニューバー右上にて、下記のように設定したPHPUnit on Vagrantを選択した状態で、右側の矢印をクリックするとテストが実行されます。（ Run を実行すれば良いので、メニューから選択しても、CTRL + R でも良いです。）

テストが実行できました！

IDE から Vagrant VM の PHPUnit を実行する良さ

実際に使ってみて良かった点です。

1. 操作が楽

これまでテストを実行する時は、ターミナルアプリケーション に遷移して、phpunit コマンドを実行していました。それが、PhpStorm 内で CTRL + R だけで実行できるようになりました。ちょっとした手間ですが、同じウィンドウで済ませられるので楽です。

2. diff が見やすい

アサーションでテストが失敗した時に、期待した値と実際の値と差分を表示することができます。この差分表示は、コードの変更差分と同じ形式で、左に期待した値、右に実際の値を表示してくれます。これは phpunit コマンドの実行結果に比べて、分かりやすいです。

3. 各テストの実行時間が分かる

テスト全体の実行時間だけでなく、各テストケースの実行時間も記録されているので、一覧で確認することができます。もちろん、実行時間で並べ替えもできるので、遅いテストの確認なども簡単です。

さいごに

PHPStorm 8 の PHPUnit By Remote Interpreter を使って、PhpStorm から Vagrant VM にある PHPUnit を実行してみました。

上でも書きましたが、設定して、開発サイクルでテストを実行すると、想像していた以上に楽です。テストの実行が気軽にできますし、結果も分かりやすいです。

Vagrant を使って、PHP アプリケーションを開発しているなら、ぜひ設定してみて下さい。

参考

http://confluence.jetbrains.com/display/PhpStorm/Running+PHPUnit+tests+over+SSH+on+a+remote+server+with+PhpStorm

PHP には、PSR が策定されたおかげで、これをベースにコーディングスタイルがある程度整ってきました。

ここ近年開発がはじまったプロジェクトなら、PSR-1/2 をコーディングスタイルとして採用しているプロジェクトも多いのではないでしょうか。

せっかく採用したなら、実際に書くコードはできるだけこの基準に沿うようにしたいものです。ただ、ここにあまり手間をかけるのも本末転倒です。そこで、手間をかけずに、コーディングスタイルに従えるような方法を模索してみました。

開発環境には、PhpStorm を使う前提です。

PhpStorm の PSR1/PSR2 ルール

まず、PhpStorm の Code Style で、PSR1/PSR2 をルールとして設定しました。

プロジェクト毎に規定したいので、Scheme はProjectにして、set from...をクリックして、Predefined Style から PSR1/PSR2を選択します。

これで、PSR-1/2 のルールがコーディングスタイルへ設定されます。

コーディングスタイルによるコード整形（Reformat）

PHP コードを書いていけば、インデントやブレース位置など自動で適用してくれます。

また、フレームワークで自動生成されたコードなど既存のコードに対して、整形する機能があります。それが Reformat Codeという機能です。

Search Everywhere（⌘ ⌘)から、「reformat」と入力して、選択しても良いですし、⌘ + option + enter でも ok です。

Reformat Codeを実行すると、下記のようなダイアログが表示されます。適用範囲の選択やオプションが選択できます。Optimize importsにチェックを入れておくと不要な import文を削除してくれたりすので、チェックしておくと良いでしょう。Rearrenge entriesにチェックを入れると、メソッドの順序を並べ替えたりするので、これは外しておきます。

Runを実行するとコーディングスタイルに従って、コードが整形されます。

例えば、下記のようなコードがあるとします。

class Foo{
    public function hello($show=false) { if($show){print "Hello".PHP_EOL;}
}    
}

これを Reformat Code すると、以下のように整形されます。

<?php

class Foo
{
    public function hello($show = false)
    {
        if ($show) {
            print "Hello" . PHP_EOL;
        }
    }
}

Reformat Code は、単一ファイルだけでなく、特定のディレクトリ以下の全てのファイルに対して行うこともできるので、一括で整形するのも簡単です。

PhpStorm PSR1/2 スタイルへの違和感

設定も簡単で良かったのですが、Reformat Code でコード整形すると、これだけは気になるというコードがあります。

それは、クロージャをメソッドの引数に渡すコードです。

例えば、下記のようなコードがあります。

Route::post('/', function() {
    return View::make('index');
});

これを Reformat Code すると、下記のようになります。

Route::post(
    '/',
    function () {
        return View::make('index');
    }
);

うううん、これは気持ち悪い。。。Reformat する前の方が読みやすいし、行数も少なくて済みます。

コード整形のルールは、Code Styleの設定次第なので、該当箇所を特定して変更していました。

環境毎にいちいち設定？

日頃 iMac と MBA を使って開発しているので、PhpStorm はそれぞれの PC にインストールしています。設定は共有していないので、こうしたカスタマイズを行うと、それぞれに適用する必要があります。

また、PhpStorm は、時折うっかり設定を忘れてしまうようで、たまに再設定を行ったりします。

そして、チームで開発する際は、メンバーがそれぞれ該当箇所を設定するする必要があります。（チームメンバーで設定を共有するような仕組みが PhpStorm にあれば、良いのですが、まあそれは未来に期待して。）

設定自体はそれほど大変ではないですが、全ての環境で行うには手間がかかります。

PHP Coding Standards Fixer

じゃあ、PHP Coding Standards Fixer で、自動変換すれば良いじゃないかと思い、.git/hooks/pre-commitに仕込んだりしたのですが、これもそれぞれの環境で仕込む必要があり、それもまた手間です。

ちなみに、以下のような設定を書いてました。これは自動変換ではなく、コーディングスタイルに合致しないコードがあれば、警告を出して commit を reject する仕様になってます。

#!/bin/sh
#
# An example hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.
#
# To enable this hook, rename this file to "pre-commit".

#
# php-cs-fixer
#
PROJECTROOT=`echo $(cd ${0%/*}/../../ && pwd -P)`/
FIXER=php-cs-fixer.phar

if [ ! -e ${PROJECTROOT}${FIXER} ]; then
  echo "PHP-CS-Fixer not available, downloading to ${PROJECTROOT}${FIXER}..."
  curl -s http://cs.sensiolabs.org/get/$FIXER > ${PROJECTROOT}${FIXER}
  echo "Done. First time to check the Coding Standards."
  echo ""
fi

DIRECTORIES="app bootstrap public package"

for d in ${DIRECTORIES}; do
  php ${PROJECTROOT}${FIXER} fix $PROJECTROOT/src/${d} --verbose --dry-run --fixers=indentation,linefeed,trailing_spaces,unused_use,short_tag,visibility,php_closing_tag,braces,extra_empty_lines,include,controls_spaces,elseif,eof_ending,function_declaration
  if [ $? -ne 0 ]; then
    exit 1
  fi 
done

もう、PSR1/PSR2 そのままで良いんじゃないか

しばらく悶々としながら開発していたのですが、もう人間の好みは捨てて、ツールに委ねる方が良いのでは、という考えに至りました。

PhpStorm デフォルトの PSR1/PSR2 を適用すれば、かなりの部分は読みやすいコードに整形してくれます。クロージャの部分も読みにくいというより、好みではない（なんとなく気持ち悪い）という程度なので、これは慣れれば、どうということはなさそうです。

結果として、PhpStorm の PSR1/PSR2 をカスタマイズせず、そのままコーディングスタイルとして利用するようになりました。

コーディングスタイルを自動で適用

せっかくのコーディングスタイルですが、毎回、手で Reformat Code を実行するのは手間です。そこで、commit 時に自動で適用するようにしています。

Commit を実行した際に表示されるダイアログの右にある Before Commit の Reformat codeとOptimize importsにチェックを入れておけば、commit 前にこれらを自動実行して、整形済のコードを commit してくれます。

さいごに

本文でも書いたように、現在は、PhpStorm 標準のPSR1/PSR2ルールを利用しており、commit 時に自動で整形されるようにしています。IDE やエディタが複数混在していたり、人数が多くなると、CI などで一括管理した方が良いかもしれませんが、設定の手間と効果を考えると、今のところ、この運用で十分です。

PhpStorm の Reformat Code はなかなか良くできており、多少の好みくらいならカスタマイズせずに、ツールに寄り掛かる方が良いと実感しました。将来フォーマットが変わるかもしれませんが、それはそれで自動整形すれば良いだけです。

これだけツールが良くなると、コーディングスタイルを人間が気にすること自体が無駄な気がしてきて、ツールが勝手に決められたルールに従って整形してくれれば、それで良いという考えになってきました。

ちなみに、件のクロージャのスタイルは時間が経つにしたがって、気にならなくなってきました。引数が多い場面などは、かえってこの方が読みやすいんじゃないかという気さえしてきたので、まあ慣れの問題ですね。

PhpStorm から Vagrant で構築した VM の PHP アプリケーションをリモートデバッグする方法です。Web アプリケーションだけでなく、CLI アプリケーションでもリモートデバッグできるように設定していきます。

VM スペック

• 192.168.33.41 を private network で設定
• PHP + Xdebug がインストール済み
• ホストと VM は、synced folder でディレクトリを共有（/path/to/src -> /share）

0. Xdebug によるリモートデバッグの仕組み

リモートデバッグを設定する前に PhpStorm と Xdebug がどのように通信するかを見ておきます。これを理解しておくと設定がスムーズです。

下記は、Xdebug の公式サイトに掲載されている図です。ここでは、左の「IDE」が PhpStormが起動しているホスト、右の「PHP/Xdebug」が Vagrant で構築した VM と考えて下さい。

VM に HTTP リクエストが来て、PHP スクリプトの実行がはじまると、PHP/Xdebug が IDE（xdebug.remote_hostで設定したホスト）に DBGP connect の通信を行います。PhpStorm ではこの通信を受け取り、以後は DBGP で相互に通信してリモートデバッグを実現します。

ここで大切なのは、PHP/Xdebug（VM）から、PhpStorm へ DBGP connect の通信が来るという点です。これは Web でも CLI でも同じで、PHP スクリプトが VM で実行されると PhpStorm へ DBGP connect が送られてきて、リモートデバッグを開始することができます。（xdebug.remote_autostart= Onを設定した場合）

もし、うまく動かない場合などは、この点を意識して調査すると良いです。

では、実際に設定を行っていきましょう。

1. VM での設定

まず、VM にインストールされている PHP にリモートデバッグ用の設定を行います。通常は、VM を構築する際に実行するプロビジョニングに以下を含めておきます。

Xdebug が必要になるので、下記のコマンドなどで、インストールしておいて下さい。

$ yum -y install php-pecl-xdebug

1-1. php.ini(xdebug.ini)

Xdebug の設定を php.ini 等で以下のように設定します。

xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.remote_host = 192.168.33.1

• xdebug.remote_enableで、リモートデバッグを有効にします。
• xdebug.remote_autostartを On にすることで、リモートデバッグが常に開始されるように設定します。任意のタイミングだけ開始することもできるのですが、開発環境なので、VM側では常に開始されるようにしておき、実際にデバッグを行うかどうかは PhpStorm 側で操作します。
• xdebug.remote_hostで、デバッグクライアントの IP を指定します。Vagrant の private network で 192.168.33.xxxを設定しているので、ホスト側の IP として192.168.33.1を設定しています。

1-2. 環境変数

CLI アプリケーション（phpunitコマンドでのテストを含む）でのデバッグを行うために、環境変数PHP_IDE_CONFIGを設定します。

CLI アプリケーションを実行するユーザでPHP_IDE_CONFIG環境変数を定義したいので、ここでは、vagrant ユーザの ~/.bashrc に設定しておきます。

192.168.33.41の部分には、VM の IP を指定しておきます。

export PHP_IDE_CONFIG="serverName=192.168.33.41"

もし、apache ユーザで CLI アプリケーションを実行するなら、httpd.conf 等の SetEnv などで設定すると良いでしょう。

2. PhpStorm での設定

PhpStorm でリモートデバッグクライアントの設定を行いましょう。

2-1. PHP Remote Debug

まず、メニューの [Run] – [Edit Configurations…] をクリックして、[Run/Debug Configurations] ダイアログを開きます。

次にダイアログ左上にある [+] をクリックして、[PHP Remote Debug] を選択します。すると、下記のように PHP Remote Debug の設定フォームが表示されます。ここでリモートデバッグの設定を入力していきます。

Name には、この設定の名称を指定します。ここではVagrantとしています。

Servers には、PHP サーバをプルダウンで選択するのですが、まだ設定が無いので、後ほど設定します。

Ide key は、今回は設定不要なのですが、何かしら値が必要なので、ダミー値を入力します。

2-2. Servers

Servers にサーバを追加するために、Servers のプルダウンメニュー横にある「…」ボタンをクリックします。クリックすると、[Servers] ダイアログが開きます。

[Servers] ダイアログでは、PHP アプリケーションが動作しているサーバの情報（ここでは Vagrant VM）を設定します。

ダイアログ左上にある [+] をクリックして、新規サーバを入力します。

Name には、名称を入力します。名称は何でも良いのですが、ここでは VM の IP を入力します。この値は、VM で設定した環境変数PHP_IDE_CONFIGの中で記述するserverName=の値と同じ内容にする必要があります。

Host には、VM の IP を入力します。

Use path mappings にチェックを入れます。ここでは、ローカルのファイルパスと VM でのファイルパスをマッピングを設定します。

この Vagrantfile では、ローカルの /path/to/src を VM 上では /share というディレクトリにマウントしているので、File/Directoryで /path/to/src を選択し、その右にある Absolute path on serverに /share と入力しておきます。

設定例は下記になります。

[OK] をクリックすると Servers ダイアログが閉じます。この時に [Run/Debug Configurations] では、Servers には、現在設定したサーバが選択されています。

最後に [OK] をクリックすると、設定が保存され、ダイアログが閉じます。これで設定は完了です。

3. 動作確認

では、実際にリモートデバッグを試してみましょう。

PhpStorm でリモートデバッグを有効にするには、[Run] – [Start Listen for PHP Debug Connections] をクリックします。クリックすると [Stop Listen for PHP Debug Connections] という表示に切り替わります。この状態で、再度クリックするとリモートデバッグが停止します。

今回の設定では、VM 側は常にリモートデバッグ可能な状態になっているので、PhpStorm でのこの操作でリモートデバッグを行うかどうかを切り替えることができます。

リモートデバッグが動作しているか確認するのに、[Break at first line in PHP scripts] にもチェックを入れておきます。

3-1. Web アプリケーション

では、ブラウザから、VM にある PHP スクリプトにアクセスしてみましょう。（ここでは、Laravel アプリケーションを動かします。）

http://localhost/ にアクセスすると、処理が停止して、PhpStorm のデバッガが起動しました。

これは [Break at first line in PHP scripts] にチェックが入っているためで、一番はじめの行で処理が停止するようになっています。[Step Over] や [Step into] で、順にコードを実行して、PhpStorm 上で実行されている行が正しく遷移するか確認すると良いでしょう。

確認が終わったら、[Run…] でコードを実行する、もしくは [Stop] で停止させましょう。

3-2. CLI アプリケーション

CLI アプリケーションについてもリモートデバッグができるか確認しましょう。

vagrant ssh で、VM にログインして、何か PHP アプリケーションをコマンドラインで起動します。ここでは php artisanコマンドを実行します。

$ php artisan

すると、Web アプリケーションと同じく、はじめに実行される行で処理が停止し、PhpStorm のデバッガに制御が移ります。

PHPUnit なども実行して、同様になるか確認しておくと良いでしょう。

これで、Web でも CLI でも PHP アプリケーションでリモートデバッグができるようになりました。あとは順に実行するなり、任意のコードにブレイクポイントを仕掛けるなり、デバッグを行うことができます。

なお、動作確認用にチェックしておいた [Break at first line in PHP scripts] ですが、アプリケーション実行の度に停止するのは面倒なので、普段はチェックは外しておきましょう。

4. トラブルシューティング

4-1. デバッガが起動しない

おそらく基本的な設定ミスなので、手順を再確認します。

• xdebug 関連の設定変更後に Apache/php-fpm の再起動を行う
• PhpStorm で[Start Listen for PHP Debug Connections]を行う

4-2. デバッガは起動するのに、ステップ実行できない

PhpStorm の [Servers] 設定のパスマッピングの設定を見直します。

4-3. Cannot accept external Xdebug connection: Cannot parse the value of ‘$_SERVER[‘PHP_IDE_CONFIG’]’

CLI アプリケーションでリモートデバッグを行う際に発生しました。
環境変数PHP_IDE_CONFIGが正しくセットされていなかったので、VM 側の設定を見直します。

さいごに

PhpStorm から Vagrant で構築した VM へのリモートデバッグ設定について見てきました。

はじめは面倒に見えますが、慣れてくればかなり楽に設定できます。VM 側の設定は、プロビジョニングに記述しておくと良いでしょう。

やはり、処理の流れはデバッガを使った方が掴みやすいので、ぜひ活用してみてください。

参考

http://www.jetbrains.com/phpstorm/webhelp/run-debug-configuration-php-remote-debug.html
http://www.karakaram.com/phpstorm-vagrant-remote-debug
http://blog.jetbrains.com/webide/2012/03/new-in-4-0-easier-debugging-of-remote-php-command-line-scripts/