今年も 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 qamake 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 qamake 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 上で動作しないというわけではありません。
新しい機能に合わせたインデント等を揃える綺麗な書き方について考慮されていないということです。

環境

実行環境は次の通りです。

  • PHP: 8.0.1
  • PHP_CodeSniffer: 3.5.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を使うにあたり、これまで様々なブログを拝見し参考にさせていただきました。

最終的に、これで行こうというディレクトリ構成を決定したので、それを紹介しようと思います。

長くなってしまって文章も微妙なので、先に結論として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つです。

  • AWS資格もくもく勉強会の開催
  • ライブコーディングの実施
  • 輪読会の開催
  • ペアプログラミングの実施
  • モブプログラミングの実施
続きを読む

第2回社内輪読会として「オブジェクト指向でなぜつくるのか」を読み合ってみた

はじめに

社内有志メンバーで「オブジェクト指向でなぜつくるのか 第2版」の輪読会を行いました。

前回の輪読会の好評がとてもよく、続けようとなったので第2回として開催しました。
前回の輪読会についてはコチラ ohshige.hatenablog.com

オブジェクト指向でなぜつくるのか 第2版

今回の課題図書は「オブジェクト指向でなぜつくるのか 第2版」です。

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

  • 作者:平澤 章
  • 発売日: 2011/04/07
  • メディア: 単行本

普段扱っている言語の関係上、オブジェクト指向を使うことが当たり前になっていますが、一歩引いて「なぜ?」という観点から見れるということでこの本が選ばれました。(たぶん)

輪読会

全体の流れは前回と同様に、日付と範囲を決めて当日までに全員が読んでから参加し、持ち回りのファシリテーターが当日議論を回すというものです。

そして、今回は4月から入社した新卒1年目もメンバーに加えての開催となりました。
参加メンバーの幅がさらに広がり、議論も面白いものになっていたと思います。

また、ほぼコロナ自粛期間だったのでオンラインでの開催がほとんどでしたが、全く問題なかったです。

やってみて

本書は「オブジェクト指向でなぜつくるのか」というタイトルではありますが、それだけにとどまらず、プログラミングの歴史や仕組み、UMやデザインパターン、開発手法、関数型プログラミングについても載っており、守備範囲がとても広かったです。

実際の内容に関しては是非読んでみてくださいという話になってしまいますが、オブジェクト指向やプログラミングの初心者や初級者にとっては幅広く学べるため、とても合っていると思います。
また、ある程度プログラミングをしてきてはいても、メモリの仕組みやデザインパターンについてなど、意外と知らないことにも出会える可能性は高いです。

ただ、歴史的経緯であったり定義であったりの説明が多いので、輪読会の課題図書としては議論の余地があまりなく、やりづらかったかなという印象です。
どうしてもただの感想になってしまう場面が多かったので、そういう点では期待通りとはいきませんでした。
もちろん、議論を目的としない場や個人での読書であれば、上述の通り初心者にはとても良い本だと思います。

さいごに

良書と呼ばれる本でも輪読会(議論の場)の場合は合わないこともあるのだと感じることが多かったです。

個人で読む本と輪読会で読む本と見極めつつさらに続けていこうと思いました。

「みんなで早押しクイズ (みんはや)」でエンジニア力なるものをアップさせるのが楽しいし良さそう

最近、コロナの影響で全く外出できず、暇で暇でしょうがない。
そんな中、みんなで早押しクイズ、通称みんはや、というアプリにハマってしまいました。 minhaya.com

みんなで早押しクイズ

みんなで早押しクイズ

  • Takatoshi Kobayashi
  • ゲーム
  • 無料
apps.apple.com play.google.com

競技クイズのようなものを1対1だったり複数人だったりで対戦するアプリなのですが、細かい紹介はたくさん紹介記事等あるようなので省略します。

ここで紹介したいのは、「作問」という機能がとても良いということです。
作問機能として、問題と解答を入力して自分だけのオリジナル問題集を作ることができます。
みんはや内のフリーマッチを見ると、たしかに様々なオリジナルの問題で楽しまれていそうです。

作問してみたいと思い作ったのが、コンピューターサイエンスの基礎から我々の職種に関わるような用語に関するクイズです。
新卒1年目が配属されたもののリモートで一緒にやりづらく技術レベル感を把握しづらかったり、業務としては活躍しているけれど意外とCSの基礎を知らないメンバーがいたり、単純に暇だったり、ピッタリかもしれないと思い、作問しました。

例えば、次のように幅広く問題を作ってみました。

1バイトは何ビットでしょう?

「あるクラスやモジュールやコンポーネントに任せる仕事は1つであるべきだ」という原理原則を日本語で何というでしょう?

整列済みのリストや配列に入ったデータに対する検索を行うにあたって、 中央の値と検索したい値との大小関係を比べて、その結果を踏まえて中央より前半か後半のいずれかを調べて、と繰り返していくアルゴリズムを日本語で何というでしょう?

機械学習アルゴリズムにおいて、グルーピングやクラスタリングなどの構造を見つけ出すことを目的として、入力のみからモデルを構築するものを何というでしょう?

サーチエンジンの検索結果で上位表示するために、Webサイト内のコンテンツや構造を最適化する施策のことを、アルファベット3文字で何というでしょう?

このような問題をただ一覧を眺めて勉強するのもつまらないと思います。
みんはやでクイズ形式で競争しながらやることで、楽しみながらもレベル感を把握でき勉強にもなるという仕組みです。

実際に数名でやってみましたが、とても盛り上がりました。
一番楽しんでいたのはみんなが解答している様子を見ている自分だった可能性はありますが。

是非一緒にやりましょう!