ふと気付いて実行してみたら便利っぽい使い方ができたので、 前回の続きみたいなエントリー。 daisuki.nichiyoubi.land
自分で使うプロジェクトに関しては、composer でどこからでも叩ける用にDockerfileなんかでパスを通している。
RUN wget http://getcomposer.org/composer.phar && \
mv composer.phar /usr/bin/composer && \
chmod 0755 /usr/bin/composer
みたいな。
"scripts": { "test": "phpunit" },
なんて書いておいて。
こうすることで、ホスト上から
docker-compose run my_service composer test
みたいに、気軽にコマンドを叩くことができるようになる。 CodeSnifferや静的解析だったりとか、そこら辺をすぐに使えるようになるかも？ あと内容によってはgit pre-push hookとかと合わせてもいいのかもしれないなぁ。
というものがある。 Scripts - Composer
あまり「自分らが開発しているPJ」において拡張しまくっていたりはしないものの、 これを「当たり前に使う」ようなレベルまで持っていくと、まぁ便利ではあるんだろうな〜とは思う。 もちろん、各種イベントにフックして実行する手続きをドン！！というのはもちろんとして、 「そうじゃなくても！」だ。
例えば、CakePHPでは以下のようになっている。
"scripts": { "check": [ "@cs-check", "@test" ], "cs-check": "phpcs --colors -p ./src ./tests", "cs-fix": "phpcbf --colors ./src ./tests", "test": "phpunit", "test-coverage": "phpunit --coverage-clover=clover.xml" }
これがあるので、composer check などとするだけでCodeSnifferとtestが走り出すのだ。
個人でやっている内容については、例えるなら.bashrcなどに書くような「便利エイリアス」くらいの働きはしてくれそう。
チームでやっているのであれば「このくらいは、普段から(なるべく)意識しておこうな！」というスタンダードの表明的な役割はあるのではないか。
例えば「○○ツールで静的解析をやるときは、このphp.iniを食わせてからやるぜ！」とかいうのは、
いちいち覚えておくのが面倒くさそう。それが composer check くらいで済むのなら、嬉しくないですか？
もしくは、よくありそうなのはCIに任せたい一連の処理をPHPで記述しておいて、composer経由で叩かせる・・とかか。
なんか使いみちあるかなー
「この機能がいいね」と君が言ったら・・・ 記念日である。
GuzzleHttpを用いてアプリケーションを書いていて、例外処理を行おうとしていて少し困った。
「ClientExceptionとServerExceptionと、あとBadResponseExceptionが来る可能性があるなー」と。
サーバー例外！と変な応答例外！はなんとなく近い気がする(1つの共通クラスで丸っととってこれそうなイメージ)、ただクライアントが変！！のときは、何か違うかな・・・？と。名前から受ける印象。
で、「そういえば」と思ってクラス名を右クリックした結果。
な〜んだ、どちらも RequestException を取っているのね！であれば、それで拾ってしまって良さそうだな。
getRequest() getResponse()どちらも通る前提での実装ができる。
未知のコード・未知の知識として、「正直、細部まで丁寧に読んだり追ったりしている余裕はないぞ・・・」というときに、すごく助けられるな〜と思った次第。
PHP: 例外 - Manual を見ていて。
例えば
UnexpectedValueException クラス ¶ (PHP 5 >= 5.1.0, PHP 7) はじめに ¶ いくつかの値のセットに一致しない値であった際にスローされる例外です。 これが発生する例としては、ある関数が別の関数をコールしていて、 その関数の返り値が特定の型や値である (そして計算やバッファ関連のエラーがない) ことを想定している場合があります。
とか書かれている。
やっぱり「適切な例外を扱えると、気持ちいい」というのがあるので、こういうふうに「どう使うの」が記述されているのは嬉しい。
——
ついでながらPHP: 定義済みの例外 - Manual普段あまり「自分で使わない」ようなものが並んでいるな、と思う。
概ね LogincExceptionかRuntimeExceptionを継承して利用する感じになると思うが、それらはSPLなのか・・・あまり意識していなかったな。(FWを使うと、その例外をそのまま継承することも多いですし。)
このあたりから、「PHPにとって例外とは」というのがなんとなく見えてくるような気がした。
どんな感じなのだろうな？と思い少しだけぐぐってみたら、この記事が興味深かった。 PHPの例外 - Qiita
実際にAuraPHPもSPL例外は未使用で全ての独自例外をPHP組み込み例外\Exceptionから継承していますが、十分にクリーンで機能しています。
なるほど。。Auraの思想は好きだし、最近いろいろと参考にさせてもらっているので、「そういう考え方もあるのか〜」と思う。
ちょーーーーー当たり前かもしれないけど、今日気づいて「なるほど！！！」と膝を打ったので恥を忍んでのメモ。
/var/log にログ落ちてないんだけど〜〜と焦燥した日々でしたよくあるやつ、 ErrorLog "/var/log/httpd/error.log” みたいなのを想像していて、ひたすら /var/log/ 以下を探したんだけど、ないなーと。
でコンテナの中覗いたら ErrorLog "/dev/stderr” って書いてあって、標準エラー〜〜？？てなり。
docker logsDockerコンテナのロギング機能を使ってみる | さくらのナレッジ こんなものがあるのね〜〜〜！ KitematicやPHPStormで「(CONTAINER)LOGS」ってあるのは、これのことか・・・
で、更にこれを docker-composeを活かして良い感じにやるやつがある(会社で隣にいるインフラの人に教えてもらった・・・) docker-compose logs | Docker Documentation
これだと、コンテナにsh実行しなくていいし、「今まで知っていた、よくあるlogファイルの場所を覗きに行く」よりも、むしろ簡単だし分かりやすいし・・・
docker-compose logs -f、さいこ〜！
という思念がある。
着想としては、emoji prefixed commit messageである。
自分が知ったきっかけの記事は、これじゃないのだけど・・・さすがグッドパッチさん〜〜！わかりやすいキレイ〜〜！と思ったのでw このURLを貼る。
「テストを書くと、メソッドやクラスのスコープが意識されて、コードの結合度がいい感じになる」というメリットがあるが。
それと似たような効果で、「このコミットメッセージに、この変更内容は嘘がないか？」という歯止めである。emoji prefix。
で、副次的にでありつつファーストインプレッションとして「エモジ、タノシイ。」がある。
ここにインスパイアされて「楽しい感じで、コミュニケーションの抱える抽象的な難易度 = 人類にメッセージングは早すぎる問題」を何か解消できないか？という話
※別に「人に対して」にかぎらず、ソースコードやプログラムに対しても「対話」をしているものだ、と普段考えているので、ここで用いているのはそのくらいのスコープでの「コミュニケーション」という語。
自分としてコードレビューにおいての難しさの最たるものの1つとして、「温度感を伝えるのがちょっと・・」というのがある。
本気で議論をしたいのか。議論をするまでもなく、絶対にこうしてほしい！というオーダーに近いのか。全然直さなくていいよ〜、でも最初に自分はこう書くかも〜と思った！なのか。
「Pull(ないしマージ)」のリクエストなのだから、それをレビューするということは、最終的には「私の書いたコレに修正が必要かどうか、ジャッジせよ」という要請と返答だと思う。
しかしながら、レビュアーもレビュイーも、コードレビューの中で非常に成長ができる・・・というのは自分の経験として本当に強く思う。職場で、この1年はめっちゃ神経質にレビューをしていた時期があり、(人として)色々と失っている気もするが間違いなく実装力や設計力がついたなーという感覚があり。
その際に何をしていたかというと、「最低限、動けばいいよ〜というレベルでは通さない」し「言いたいことをひとまず全部言ってみる」であり。
その中で、先に述べた「あ〜〜自分ならコッチの書き方が好み！スマートな気がしない？どう？？」的な、投げかけを行った。そういう感覚で放り投げたレビューコメントの方が多いかもしれない、だいぶ厄介・・・
ということで、「これは真剣に言っているので！」とか 「これは、まぁ真に受けなくていいよ！！」みたいな温度感を示す、もしくは「些細なcosmetic changeの依頼です〜」とか「ここは、ついでにサクッとリファクタ入れてくれると嬉しいかも！」とか、「エンバグしてまっせ！！」とか。
そういう、「コメントの性質・内容・アラートレベル」を、メタ情報として付与できれば？と。
大概にして、「コメントされた内容を聞き流す」というのは、PRを投げる側にとっても、精神的な負荷が大きいので・・・
is よりも should みたいなprefixにするかもな〜と思いました！「状態が確定した」というよりも「判定の結果、状態を指示する」的なニュアンスが強いのでみたいな。よくわかんないなー
コネクションコールバックが〜とかポートが〜とか。
いんたーねっとに転がっている「xdebug.iniに、こんな風に書いてくれよな！！」というのを丸呑みしている日々が、続いておりました・・・(恥)
で、「なんかdockerでリモートデバッグが動かないよ〜><」というのを、妥協して怠惰に目を瞑って過ごしていたのですが、この記事と出会い。
見事に問題が解消されました嬉しい・・・！
これをきっかけに、「そもそもどういう仕組で、クライアントに「デバッグ」な情報を送っているのかな〜」というのを、整理したいなと思ったのでした。
なんてことはない、公式のドキュメントのこの図が1番わかりやすい・・・・
さて、この記事を読むのが良いです。 Xdebug: Documentation
「Xdebugは、コードを評価してクライアントと相互にやりとりをしながらデバッグをしていくことを可能にするよ！」「そのやりとりに使われるのが、 DBGp っていうプロトコルなのさ！」みたいなことが書いてあります。
詳細には、こっちで書かれていますね。 Xdebug: Documentation - Protocol - DBGp
こんなにも・・・！
ここが「1番実用的な知識」であり、今このようなメモを残すきっかけとなった本題です。
In order to enable Xdebug's debugger you need to make some configuration settings in php.ini. These settings are xdebug.remote_enable to enable the debugger, xdebug.remote_host and xdebug.remote_port to configure the IP address and port where the debugger should connect to. There is also a xdebug.remote_connect_back setting that can be used if your development server is shared with multiple developers.
ってことだから、ココらへんを見る。
「クライアントに接続しにいかせるやつ、いる？」のOn/Off。
「もし接続が確立できなかったら、この値がOffになっているものとして扱うよ〜」と書いてある、まぁそうですよね。
「接続しに行ってOKなクライアントはどこ！？」の項目。「ここからの通信だけでDBGpでの交渉を許可する」、ってことであっているのかな・・？
書き方は
you can either use a host name, IP address, or 'unix:///path/to/sock' for a Unix domain socket
です。
「接続してきたホストにXGDp接続をしにいくか」。
何かというと「remote_host設定に関わらず(すなわち、設定値を無視して or 設定されていなくても )、リクエスト元をリモートデバッグクライアントとみなして通信しに行く」。
個人的には、 ローカル開発ならコレ使えばいいかな〜と思っていたので、前に晒したDockerfileではremote_hostでなくてこっちをenableにしているのだけど。どうなんだろう〜
もしくは、「チームで利用するリモートの開発サーバー」とかはこれ使う感じかと
There is also a xdebug.remote_connect_back setting that can be used if your development server is shared with multiple developers.
「接続を試みるポート」。
例えば 「macでPHPStormを使っていてDockerコンテナのPHPでリモートデバッグをする」といった場合、「コンテナからmac(ホストマシン)の9000番に接続が来る」と・・・
これ知らなかった。「いつ有効にする(接続を返しに行く)か？」みたいなところ、かな・・？
Allowed values for this setting are "req" (the default) which makes the debugger initiate a session as soon as a script is started, or "jit" when a session should only be initiated on an error.
stormにも記事がある。 https://blog.jetbrains.com/jp/2013/12/19/343blog.jetbrains.com
本来は「特定のパラメータ名」を付与したリクエストが来たときのみリモートデバッギングが始まるところを、この設定がOnになっていると「自動的に始まる」というもの。 冒頭で紹介した記事中でも、autostartが有効化されています。
「特定のパラメータ名」の設定がこれ！
例えば idekey=session_nameだった場合、
simply add XDEBUG_SESSION_START=session_name as parameter to the URL. Instead of using a GET parameter, you can also set XDEBUG_SESSION_START as a POST parameter, or through a cookie.
ということです。
要するに、 http://blog.example.com/post/100 をデバッグしたいときには、 http://blog.example.com/post/100?XDEBUG_SESSION_START=session_name というようにパラメータを付与してリクエストをする必要があるということです。
それによってXDEBUG_SESSION 情報がCookieに保持されます。
GET/POSTで値を渡された or セッション情報が記録されている場合のみ、デバッグセッションに入るといったことです。
※ HTTP Debug Sessionsのセクションを参照してください
先の autostartが有効化されていたら、 even if the GET/POST/COOKIE variable was not present でデバッグが始まるよ〜！となります。
関連: remote_cookie_expire_time
リモートデバッグのみでなく、Xdebug全体の設定項目についてはこちらに。 https://xdebug.org/docs/all_settingsxdebug.org
