「herokuでDocker使えるよ」って言うから試そうとしたらハマった
Heroku container registryっていうのができたんだ！！っていうから、喜び勇んで飛びついた俺たちは・・・
php:php72-apacheでやろうとしたが、「MPMモジュールが複数あるから！！」などと言われ、そのままでは使えず。
ログを見ると、
AH00534: apache2: Configuration error: More than one MPM loaded.
となっている。
しかしそのイメージはローカルだと正常に動いたんだぜ！！という気持ち。
heroku run zsh --type=web で、コンテナに入れるよ〜っていうから見てみたら確かに、思っていたんと違うファイルがある。。。mods_enabledの中身が違う。
謎すぎて心折れた
俺がPHP環境作っていてXdebugが動かない(DBGpからのコネクトバックが来ない？)と思った時のメモ
掲題のとおりです作業メモです。 昨日今日から zendframework/zend-stratigility 触ってます楽しいですしかしブレイクポイント貼れないのがストレスどうにかするぞ、と思ったときのメモです。
xdebug食っているか見る
- php自体が食っていてもサーバー側(Apacheとか)が食っていないみたいな自体があったら嫌だから確認しましょう
phpinfo()するかphp -i |grep xdebug
Dockerイメージ、php:7.2-apache でやった時は
RUN pecl install xdebug-2.6.0 && docker-php-ext-enable xdebugを忘れずにね/usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.soにモジュールあるよ
DBGpからのコネクトバックが来るか確認
- コンテナ側で「9000番に飛ばしていますか」を見る
sudo tcpdump -nn dst port 9000
正解例:
root@8a529e47bb64:/var/www/html# tcpdump -nn dst port 9000 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 09:59:17.461157 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [S], seq 1168735218, win 29200, options [mss 1460,sackOK,TS val 65964320 ecr 0,nop,wscale 7], length 0 09:59:17.466740 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [.], ack 452897992, win 229, length 0 09:59:17.466918 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 0:490, ack 1, win 229, length 490 09:59:17.469833 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [.], ack 38, win 229, length 0 09:59:17.470018 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 490:713, ack 38, win 229, length 223 09:59:17.473338 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 713:934, ack 73, win 229, length 221 09:59:17.476681 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 934:1158, ack 113, win 229, length 224 09:59:17.477883 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1158:1389, ack 158, win 229, length 231 09:59:17.479941 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1389:1610, ack 193, win 229, length 221 09:59:17.481909 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1610:1806, ack 210, win 229, length 196 09:59:17.483123 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1806:2020, ack 222, win 229, length 214 09:59:17.484186 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2020:2320, ack 237, win 229, length 300 09:59:17.485338 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2320:2548, ack 295, win 229, length 228 09:59:17.486849 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2548:2777, ack 350, win 229, length 229 09:59:17.488071 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2777:3046, ack 409, win 229, length 269 09:59:17.491217 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 3046:3311, ack 468, win 229, length 265
xdebug.remote_host をいじってみる
docker.for.mac.host.internal で動くはずなんだけど。
デバッグのときの前提は「素直な気持ちになれ」「先入観を捨てろ」なので、「より確実に動く方！！」に近づいていきましょうってことでhostを決め撃ちしてみる。
tcpdumpで「宛先」がわかっているはず
ちなみに動くxdebug.ini
これで今は動いてる。
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so xdebug.remote_enable = On xdebug.remote_autostart = On xdebug.remote_host = docker.for.mac.host.internal xdebug.remote_port=9000
Serversの設定について
うまく接続が返ってくれば、自動的に設定ダイアログが開くのでソレを待っても良い気がする。
やったこと・書いたもの{2018,5}
PHPでAWS SESから(添付ファイル付き)メッセージ送信をしようとしたらハマった
Fix a typo by o0h · Pull Request #12122 · cakephp/cakephp · GitHub すごく些細なtypoの修正、単独で送るのはあまりお行儀よくないよなぁ〜・・って気がする・・とりあえず見つけてしまったので投げてみた系の。
会社で作ったプラグインがawesome-cakephpに掲載してもらえて嬉しい
プラグイン公開時にリアクションをくださった方が、他薦してくれた様子で。
使い方についての質問Issueを投げてくれていた人。自分が書いたソフトにThanks！！とか言われながらコメントもらえるのうれしいですねぇ〜
作っている途中は、ここに名前が載ることを1つの目標にはしていたものの、CONTRIBUTING.md を読んで「要件満たしてないかもな〜」と思って諦めていた次第。
それが、dereuromarkさんがすぐに +1くれていたりで、テンション上がってたw
特に議論やネガティブぽい指摘もなく、無事にとりこまれた〜〜って気づいて嬉し〜
わがままを言ってだいぶ時間を費やさせてもらって書いたプラグインだったので、少し報われたかな〜なんて勝手に思ったり。
今年は社内外でOSSを意識的に作っていきたいなと思っているのと、「もっと切り出せるな〜」って思っている部分があるので、引き続き色々と試していきたい
Composerの更新 -> PRを作る、をCI上で自動的に実行するプラグインを作った(作っている)
業務で利用しているAWFの更新を、チームメンバーでローテで回しているのだがレポジトリの数が増えてくると大変だ。
私も先日、1つのレポジトリの更新作業担当になったことがあった。「手が空いたらやっておいてね」もしくは「スプリントの狭間くらいでやっておいてね」である。
恥ずかしながら機会を逃しているうちに数日が経ってしまい、むきーーー！というところでした。どちらかというと、普段は「更新しようぜ！！」と煽ち立てる役回りだったので立つ瀬がないという事はこの事。
転んだのにタダで立ち上がるのは癪なので、どうにか「CIで自動的にPR作るところまでやってくれ〜〜」という事をするようにした。
前提として、「こまめにupdateしていけると、修正対応とのコストは劇的に下がる(ほとんどのものは、互換性を保ったまま動いてくれることのほうが多い)」という立場です。
AWF本体の更新というのは大掛かりな部類と考えるが、それですら「ビルドバージョンごとに最新に追従していく」戦略をとることで、これまで大きな問題の発生を避けられているという体感がある*1。また、テストカバレッジも高めに保ててている〜という背景があるのに支えられていると感じる。
てな訳で、「更新しておいたわ！サマリーつけておくから、軽く確認しておいて！！」というPRをCIが自動的に出してくれ・・・という夢を、形にした次第です。
これは結局のところComposer Pluginという形に落ち着いたのだけど、当初はスタンドアロンに「Composerを使役する側」の何かを書こうとしていた。
- そもそもはyarnにはそういうのあるらしいよという話を聞いて、「composerでもできるっしょ！！」と思ったのがとっかかり
- お、gemにもあるじゃん
- どうやるかな〜composerコマンドをスクリプトで叩く感じかな〜
- まぁshでもgoでもいいよね〜
- updateしたあとにdiffをとって、内容をPRに書くのは必須だなー。
- hirakuさんのcomposer-diff-pluginは凄いわかりやすい、便利
- diffを取るのはcomposer使うとすぐできたりするかな・・？
- あー、じゃあPHPで書くかー
- どうやって差分取るんだ？composerソースコード読んでみるか・・
Commandクラス作ってinvokeしたりするのか〜- 結構大変そう・・・どうしたものか・・
- 今回のスコープはあくまで「CI上で動くようなもの」、なら「更新する」って仕事自体はCIに任せちゃっていいな。composer cli。
- そういえば、composer-diff-pluginがプラグインになっているってことは、「更新があったときに結果を受け取ってゴニョ」ができるってことだな
- なるほどcomposer-plugin、アリだな・・・！
という思考プロセス。
結果としてcomposer-pluginとか、普段からあんなにお世話になっているcomposer本体への興味が向いたのが凄く収穫に感じた。
何度も読んだスライド ↓↓
「いちおう動く」なところまでは行ったので、ひとまず(私が更新を忘れてしまって、かわいそうな・・)会社のレポジトリで試してみる。
テストとか静的解析を入れられていないので、書いた本人ですら「開発途中っていってもテストゼロってやばくない？糞ダサエンジニアじゃん・・・」ていう敗北感が強いのだけど。どうやってテスト入れたら良いのかなーーーーという感じ。*2
やれるところからやっちゃおう、という感じも勿論ありつつ。
そのあたりを形式だけでも整えてしまって、そしたらv1.0.0タグを打ってQiitaとかに使い方紹介記事みたいなの書こうかなーという算段
業務前とか業務後に時間を取ってやったので、それも毎日ではなかったということで、あまりまとまった時間を集中的に取る！！ということはできていなかったのだけど。
2週間前に思い立ち、2日めくらいに「そうか〜composer pluginなら行けそう！」と方針が変わり、最初の1週間で7割位のとこまで行って、実際にtravisのdaily cronで叩いたりして様子を見つつ、いまちょうど2週間目終わりかなって感じ。
1,2週間くらいでひとまず形になる〜〜〜ていう規模のペットプロジェクトは良いのでないかな、と思ったしリフレッシュになりそう
