ブログのネタが無いならPHPの発展に貢献してみればいいじゃない
これは エキサイトホールディングス Advent Calendar 2021 の9日目の記事です。
結論
アドベントカレンダーとして何を書こうか？
↓
色々やってきたけどどれもしっくり来ないな
↓
PHP Foundation に寄付するか！
↓
寄付しました！
PHP Foundation とは
主な経緯はここに書かれています。
blog.jetbrains.com
契機となったのは、Nikita Popov さんという PHP に多大な貢献をされてきた方が、所属先の JetBrains を離れて、PHP から Rust や LLVM により集中することになったというものです。
そして、このタイミングで、いくつかの企業が協力して Open Collective で PHP Foundation が設立されました。
opencollective.com
Open Collective に他にどういうものがあるのか全く知らなかったのですが、Vue.js や Yii Framework もあるようです。
寄付してみる
PHP には大変お世話になっていますし、とても好きな言語でもあるので、今後のさらなる発展を願ってささやかながら寄付をしてみようと思います。
めちゃくちゃ簡単ですが、以降で流れを説明します。
まずは Open Collective に登録します。
登録したメールアドレスにリンクが届きそれをクリックする形でログインする、パスワードレスです。
続いて、PHP Foundation のページから、カスタムコントリビュート「寄付」を選択します。
単発なのか定期なのか、いくら寄付するのかを選択できるので、好きなものを選択します。
私は、1回の100USDにしました。
（この寄付額でやっている方が多かったので単純に真似してみました）
支払い方法は、クレジットカード、PayPal、銀行振込が選べるようなので、好きな方法で支払います。
支払いが完成すると「Thank you! 🎉」と言われ、プロフィールページにも貢献内容が表示されるようになりました。
終わりに
PHPを普段使っているので少しでも貢献できればと思い寄付しました。
（ブログネタに困ったからではないです！）
1USDから寄付できるそうなので、少しでも余裕があれば貢献してみるのはいかがでしょうか？
PHP Foundation のトップページにコントリビューターが載っているのですが、寄付額と寄付日時の降順のよう（たぶん）なので、そこに表示させたい場合はより高い金額を寄付すると良いかもしれません。今現在なら、101USD以上だと載るかもしれません。
PHP の発展にも繋がりつつ、コントリビューターとして表示されやすくなるので、一石二鳥ですね。
参考
特に PHP Foundation の経緯など、より詳しい話はインフィニットループさんのブログに書かれているので、是非ご覧いただきたいです。
インフィニットループは PHP の継続的な発展を目指す The PHP Foundation に寄付をしました | 株式会社インフィニットループ技術ブログ
PHP Conference Japan 2021 で「環境整備やろうぜ」という内容で登壇しました
はじめに
今年も PHP Conference Japan 2021 に参加しました。 phpcon.php.gr.jp
今年は参加するだけでなく、発表もさせていただきました。
LTでの登壇はありましたが、25分のセッションとしては初めての登壇です。
ちなみに、前回のLTについてはコチラです。
ohshige.hatenablog.com
「次回はトーク枠で」と言っているので、次次回になってしまいましたが、達成したということで。
新規プロジェクトの開発スタート前にやっておくべき環境整備たち
今回は、「新規プロジェクトの開発スタート前にやっておくべき環境整備たち」というタイトルで、初めて25分のセッションで登壇させていただきました。
とても簡単に要約すると、こんな感じです↓
- 本当に集中したいことに集中するために、最初のうちに環境整備しちゃいましょう
- 環境整備にもたくさんあるので環境やチームに合わせて取捨選択しましょう
- コードの環境整備の提案
- QAツールとCI化
- Dependabot
- Xdebug
- .ideaの共有
- コミュニケーションの環境整備の提案
25分枠なのに、こんなに簡単に要約できるなんて...
って思ってしまいます。
登壇してみて
資料を作っている段階から（それどころかいつもですが）思っていましたが、全然まだまだ力が足りないなと思う瞬間が多々ありました。
資料で言語化できないってことはちゃんと理解してなかったり、そこへの思いが足りてなかったり、と思ってしまいますし、25分が長くて何を話そうかってなるってことは、まだまだ浅い知識しかなく提供できるようなものが全然ない、と思ってしまいます。
いざ資料ができて登壇となっても、内容として資料自体のクオリティとしても、もっと頑張れば良かったなとか思ってしまいます。
とにかく、自分の力不足を実感した登壇になりました。
が、やってみないことには始まらないので、良い経験になったと思います。
もっと精進していきます。
いずれにしても、リアルタイムで視聴いただいた皆様、Discordにコメントいただいた皆様、あとからアーカイブや資料を見ていただいた皆様、ありがとうございました！
さいごに
配信時、トラブルか何かで音が良くなかったようです。
それ自体は残念なのですが、実は全く違うオンラインでの登壇（のようなもの）でも配信トラブルがあり、私のときだけ音と映像が固まるということがありまして、もうそういう運命なのかなと感じています。
資料内の参考リンク
- Quality Assurance Tools for PHP | Toolbox | PHPQA
- GitHub - mheap/phpunit-github-actions-printer
- GitHub - staabm/annotate-pull-request-from-checkstyle: cs2pr - Annotate a GitHub Pull Request based on a Checkstyle XML-report within your GitHub Action
- GitHub - reviewdog/reviewdog: 🐶 Automated code review tool integrated with any code analysis tools regardless of programming language
- 依存関係を自動的に更新する - GitHub Docs
- Xdebug: Documentation » Xdebug 2 から 3 へのアップグレード
- How to manage projects under Version Control Systems
- Discussions · laravel/framework · GitHub
- ディスカッションを使用してコミュニティとコラボレーションする - GitHub Docs
- テンプレートを使用して便利な Issue やプルリクエストを推進する - GitHub Docs
今年も PHPerKaigi 2021 に参加しました！（そして自責）
はじめに
オンラインでの開催となった PHPerKaigi に今年も参加しました！
iwillblogということで、個人的に印象に残っている発表を備忘録的に超簡易メモ的にまとめようと思います。
一部、直接発表を見たわけではなく、タイムシフト視聴で飛ばし飛ばし見たり、資料だけ見たりというのもあるので悪しからずです。
phperkaigi.jp
去年のはコチラ。
例年ほどの内容を今年はちゃんと書けないのが悲しいです。
ohshige.hatenablog.com
今回はPHPerチャレンジが無くてちょっと安心してます。
ちなみに、今年も弊社はスポンサーです。
個人的に印象に残ってるものリスト
大規模サイトにおけるSEO観点でのURL設計
大規模サイトにおけるSEO観点でのURL設計 by 前川昌幸 | トーク | PHPerKaigi 2021 #phperkaigi - fortee.jp
speakerdeck.com
まとめではなくただの個人の感想
- THEメディアでなくてもSEOは常に付きまとうし、身近な業務例としても良く遭遇するので親近感
- どうしてもビジネス側のSEO担当者の指示待ちになってしまうことが多いので、エンジニアもある程度は知っておくべきなんだろう
- canonicalの設定とかちゃんとしようと思うとめちゃくちゃ大変だし、1つでもミスなり変なURLがあるとクロールされて困るし
- URLパスで説明的にする方が良いとわかりつつもクエリパラメータで妥協してしまうこともあって反省
ユースケースシナリオのススメ
ユースケースシナリオのススメ by 丹賀 健一 | トーク | PHPerKaigi 2021 #phperkaigi - fortee.jp
speakerdeck.com
まとめではなくただの個人の感想
- 今まさに『ユースケース駆動設計実践ガイド』の輪読会をしているのでかなりタイムリー
- それだけに、ICONIXプロセスについて少しだけ期待したので残念
- ユースケースは図ではない → 図を書くことに集中してしまいがちだけど大事なのは記述だよねとは思う（そういうことではない）
- 文書そのもよりも記述中に発生するコミュニケーションが大事 → 超納得
PHP でもアーキテクチャテストしたい！
PHP でもアーキテクチャテストしたい！ by かわなみゆう | トーク | PHPerKaigi 2021 #phperkaigi - fortee.jp
speakerdeck.com
まとめではなくただの個人の感想
- 「こんな悩みありませんか？」にうなずきすぎてやばい
- phpatは現プロジェクトに導入しようと思ったけどあらゆる理由により断念してしまい、再度挑戦しようと切に思った
- ホワイトリスト的に書く方が良い感じがしたのでphptracも試してみたい
- アーキテクチャテストに失敗したらただの実装ミスもあるけどアーキテクチャの再設計のタイミングだったり議論を誘発したり、なるほど
そのコード、フレームワークの外でも動きますか？
そのコード、フレームワークの外でも動きますか？ by 菱田裕美 | トーク | PHPerKaigi 2021 #phperkaigi - fortee.jp
speakerdeck.com
まとめではなくただの個人の感想
- 教育の一環としてモブプロで「FWに依存しないコア部分を書いてあるFWから別のFWに移植するところまでやってみる」というのをやっているので、まさにタイムリー、むしろこの発表を見ればモブプロ不要になった説まである
- もちろん正解は1つではないにしても、より本物に近い背景の正解の例（UseCase、Service、Fetcher、各種インターフェース）を実際に見れたのは良かった
データベースを利用したテストを軽〜く実行したい時の味方: vimeo/php-mysql-engine
データベースを利用したテストを軽〜く実行したい時の味方: vimeo/php-mysql-engine by きんじょうひでき | トーク | PHPerKaigi 2021 #phperkaigi - fortee.jp
speakerdeck.com
まとめではなくただの個人の感想
- 単純に導入を検討しても良さそう
- 外部キー、サブクエリ、UNION周りの問題？もあるらしいのでとりあえず動かしてみる
自責とリベンジ？
実は今回は当日スタッフとしてのお手伝いもやっていました。
が、お手伝いとは言いつつ、諸事情あってday2に参加することができなくなり、全く役立ってない奴になってしまいました。
それがかなりの心残りというか自責の念というか申し訳ないという思いでいっぱいでした。
来年にチャンスがあればリベンジではないですけどお手伝いができればと思っています。
おわりに
全日程の参加はできなかったですが、やはりカンファレンスは楽しいものですね。
特に今回はdiscordも活用されていて、オフラインのときよりも発表後の盛り上がりを強く感じました。
次は一般参加なのかスタッフリベンジなのかわかりませんが、登壇も視野に入れて、来年を楽しみにしようと思います。
PHP 8.0 + Laravel 8 + Xdebug 3 + PHPCS + PHPStan on Docker な環境を作ってみた
はじめに
PHP 8.0 をどうしても触りたく、Docker環境を用意したくなりました。
どうせなら何かを作りたいのでLaravelの環境も同時に整えたくなりました。
デバッグも楽に行いたいのでXdebugも標準化したくなりました。
コーディング規約と静的解析を最低限行いたいので、PHP_CodeSnifferとPHPStanも欲しくなりました。
PHP_CodeSnifferは欲張らずにPSR12準拠、PHPStanは欲張ってRun Level Maxでやりたくなりました。
よし、作ろう！ということで作ってみた結果、動くものはできたので公開しようというお話です。
作った結果
ひとまず、動くものはできました。
github.com
ほんの少しだけREADMEにまとめましたが、clone後は、
$ make init $ make up
を実行して、 http://localhost にアクセスするだけです。
残念ながら、諸事情によりDBは用意していないです。
必要になれば追加しようと思います。
Docker
Docker Composeを使っており、以下の4つのサービスで構成されています。
php
php-fpmがXdebugのデバッグモードonで起動します。
基本的にはブラウザで動作確認をするために利用されることを想定しています。
php-cli
php-cliとcomposerが起動します。
基本的には 静的解析やユニットテストなどのコマンドラインでの実行や、PhpStormに設定するインタープリター用サービスとして利用されることを想定しています。
こちらにもXdebugは含んでいるので、明示的にデバッグモードをonにして実行すれば、Xdebubによるデバッグが行えます。
nginx
何の変哲もないnginxです。
php-fpmとの通信は、UnixソケットではなくTCPで行っています。
node
本当に何の変哲もないnodeです。
Laravel 8
基本的に composer create-project laravel/laravel=8.5.9 を実行してできたディレクトリ・ファイル構成をそのまま使っています。
一部、composer.jsonや、後述のPHPCSとPHPStan周りの変更をしています。
Xdebug 3
Xdebugを使ったデバッグを行えるようになっています。
以下の設定がされているので、PhpStorm周りの設定をすればOKです。
[xdebug] xdebug.client_host=host.docker.internal xdebug.client_port=9003 xdebug.idekey=PHPSTORM xdebug.start_with_request=yes
2021.1 EAPも出ている現時点では大丈夫かと思いますが、PhpStorm 2020.3.1よりも前のバージョンだとXdebug3がうまく扱えないようなので、2020.3.1以降のバージョンで使用してください。
https://youtrack.jetbrains.com/issue/WI-56947
PhpStorm 2020.3.1 Release Notes - PhpStorm - Confluence
PHP_CodeSniffer
PSR12に準拠したコーディング規約の検証を行えるようになっています。
以下の設定がされているので、 make qa や make cs make cs-fix などで実行できます。
<?xml version="1.0"?>
<ruleset>
<rule ref="PSR12"/>
<file>app</file>
<file>tests</file>
</ruleset>
ただ、デフォルトのLaravelはPSR12の規約チェックに失敗します。
些末なものなので、自動修正と手動修正により通るようにしました。
修正箇所は以下の通りです。
clean: composer cs-fix · ohshige15/docker-laravel@34370bb · GitHub
clean: composer cs 対応 · ohshige15/docker-laravel@afef5fa · GitHub
また、少なくともリポジトリに上がっている状態であれば通らないなどの問題はないのですが、 squizlabs/php_codesniffer: 3.5.8 だと一部PHP8.0の記法に正確に対応していないため、注意が必要です。
ohshige.hatenablog.com
PHPStan
Run Level Maxで静的解析を行えるようになっています。
以下の設定がされているので、 make qa や make analyse などで実行できます。
parameters:
level: max
paths:
- app
- tests
ご覧の通り、 larastan や phpstan-mockery などの extension は含めていません。
必要になれば追加しようと思います。
ただ、extensionやignoreの設定が無い状態では、デフォルトのLaravelはRun Level Maxの静的解析に失敗します。
基本的には以下のような array の型が厳密に定義されていないというエラーがほとんどです。
------ -------------------------------------------------------------------------------------------------
Line app/Console/Kernel.php
------ -------------------------------------------------------------------------------------------------
15 Property App\Console\Kernel::$commands type has no value type specified in iterable type array.
💡 See: https://phpstan.org/blog/solving-phpstan-no-value-type-specified-in-iterable-type
------ -------------------------------------------------------------------------------------------------
フレームワークの自動生成によるファイルたちが原因なのでignoreしても良い気がしますが、気になるので手動で修正しました。
修正箇所は以下の通りです。
clean: composer analyse 対応 · ohshige15/docker-laravel@aeb9525 · GitHub
正直なところ、こういう修正をしているような例がほとんどなく、これで本当に良いのか自信がありません。
が、間違っていればそれに気づいたときに修正すれば良いだろ精神でいこうと思います。
おわりに
表題で掲げたような構成があまり見つからなかったので、勢い余って作ってみました。
PHPStanがRun Level Maxで通るように修正した箇所が心配です。
また、DBが構成に含められていないのも心残りです。
何か進展があれば続きをやっていこうかなと思います。
参考
Laravel on Docker と言えば
最強のLaravel開発環境をDockerを使って構築する - Qiita
PHP 8 の一部の新機能について PHP_CodeSniffer が期待した動作をしないので 3.6.0 を待つ
はじめに
PHP 8.0.0 がリリースされてしばらく経ちました。
各種ライブラリや FW も PHP 8 対応されており、PHP 8 ライフも順調です。
ただ、お世話になっているPHP_CodeSnifferで一部まだうまく動作しない部分があったので紹介します。
先に言ってしまうと、PHP_CodeSniffer の 3.5.7 や 3.5.8 などの早い段階ですでに対応はなされており、基本的に PHP 8 上で動作しないというわけではありません。
新しい機能に合わせたインデント等を揃える綺麗な書き方について考慮されていないということです。
環境
実行環境は次の通りです。
また、コーディングスタンダードとしては個人的に一番お世話になっている PSR12 を採用して、以下の通りに実行します。
phpcs --standard=PSR12 /path/to/code/myfile.php続きを読む
正解が未だに見つからないTerraformのディレクトリ構成を考えてみた
これは XTechグループ 2 Advent Calendar 2020 の9日目の記事です。
はじめに
弊チームでは Infrastructure as Code として Terraform を使っています。
一部、サーバレス部分ではSAMを使っていたり、そのままCloudFormationを使っていたり、例外もありますが、基本的にはTerraformを使っています。
Terraformにはmoduleやworkspaceという機能があり、自由度高くコードを管理できます。
さらには、必要なインフラ環境は、プロジェクトによって微妙に異なるのはもちろん、会社が変わればルールや制約も違って求めるものも大きく異なります。
そのような理由からか、Terraformのデファクトスタンダードなベストプラクティスなディレクトリ構成というものはあまり無いような気がします。
（もしあれば知りたいので教えていただけるとありがたいです）
チームでTerraformを使うにあたり、これまで様々なブログを拝見し参考にさせていただきました。
- Terraformにおけるディレクトリ構造のベストプラクティス | Developers.IO
- Terraformのベストなプラクティスってなんだろうか | フューチャー技術ブログ
- Sansan Labs 開発での Terraform ディレクトリ構成 - Sansan Builders Blog
- Terraformのディレクトリ構成の模索 - Adwaysエンジニアブログ
- Terraformなにもわからないけどディレクトリ構成の実例を晒して人類に貢献したい - エムスリーテックブログ
- Terraform導入への第一歩 - BASEプロダクトチームブログ
最終的に、これで行こうというディレクトリ構成を決定したので、それを紹介しようと思います。
長くなってしまって文章も微妙なので、先に結論として3行でまとめます。
- 環境差異はworkspaceではなくディレクトリの分離で解決している
projects->usecases->elementsという3層構造で、module機能を使って共通化できる部分は共通化している- 運用の方針として、既存の共通部分の修正の影響範囲が大きすぎて大変な場合は似たような共通処理を作ることを厭わないようにしている
チームの成長のためにこの1年で取り組んできた5つのことと秘訣
これは XTechグループ Advent Calendar 2020 の1日目の記事です。
はじめに
エキサイトのLife&Wellness事業部でエンジニアをしている おおしげ ( @_ohshige ) です。
XTechグループとしては初めての試みとなる Advent Calendar の記念すべき1日目を任されました。
XTechグループの Advent Calendar として、弊エキサイトはもちろん、Radiotalk社、iXIT社、クロスマート、イークラウド、さらには内定者まで、様々なエンジニアが至極の記事を執筆する（らしい）ので今後もご覧いただければ幸いです。 qiita.com
この1年で取り組んできたこと
私自身の最近の目標として、チームの技術力向上を掲げています。
ビジネスとは直接的には関係のない技術に関する「何か」をやることで、自分も含めてチームに良い影響を与えられるのではないかと考えて、この1年でいくつか取り組んできました。
既にこのブログ内で紹介しているものもありますが、1年を振り替える意味を込めて包括的に改めて紹介しようと思います。
この1年で私が主催者としてやってきたことは、主に以下の5つです。
続きを読む