Laravel.shibuyaは渋谷の5人のイカしたLaravelギャングどもが今年の5月から定期開催するミートアップです。
よくあるセッション中心の技術勉強会とは異なり、Laravel.shibuyaはIRT(Interactive Round Table)、つまり座談会による参加者同士の議論が主体の構成です。参加者は複数の会議室に分かれて、それぞれ少人数で議論を行います。今回は「PHP IRT」「Laravel IRT」「PHP Beginner IRT」「Laravel Beginner IRT」の4つに分かれ、20分のターンを3回繰り返す構成です。参加者は休憩時間に別の部屋に移動することができます。
PHP Track
私はLaravel JP Conference 2019の当日スタッフを請け負って懇親会LTまで引き受けてしまったものの、それ以来ずっとLaravel赤ちゃんのまま渋谷に来てしまったので、本日はPHP Trackに参加することにしました。IRTはsli.doというツールを使って各参加者が記名または無記名で書いたお題を相互に投票し、上位で参加者の合意がとれたお題について話していきました。
以下は議論の議事録ではなく、議論を経た上での私見をまとめたものです。元からの私の意見と、参加者の発言を私なりに咀嚼したものがないまぜになっているものです。
IRT1: デプロイ環境
最初の議題では「PHPのデプロイ環境を学びたい」という話題でした。PHPのようなWebアプリにおける「デプロイ」とは通常のソフトウェアの「リリース」に相当するもので、開発したソフトウェアをネットワーク越しに利用者が利用可能な状態に提供することです。
PHPでもっとも伝統的なデプロイとは、レンタルサーバを借りてFTP(近年であればSCP/SFTP)でPHPのファイル一式を転送することでしょう。このようなレンタルサーバは現在でも小規模なWebサイトのホスティング用途としては非常に根強い選択肢ですが、スケーラビリティが低い、変更が多い場合にはダウンタイムなしでのデプロイができないといった課題があります。現在のところ、レンタルサーバでその次に運用が容易な選択肢はHerokuのようなPaaSでしょう。Herokuでのデプロイ作業は基本的にgit pushだけで完結するもので、とても簡単なものです。それに次いでLOLIPOP! マネージドクラウドなどはSCPを使った従来のレンタルサーバに近い使用感を持ちながらスケーラビリティの問題を解決した、大変すばらしいプラットフォームです。
ところで、もとの相談者が解決したい課題は、デプロイ環境を学んで職業として活かしていきたいということでしたので、ここで解決したい課題は「簡単なプラットフォームでPHPを動かす」ことではなく、PHPのアプリケーション一式がデプロイできる運用環境を構築できるようになることにあるのではないかと思います。私はDockerなどを使ったアーキテクチャについては特に意見がないので積極的な意見を述べることはできません。しかし、はじめの一歩としてはローカルのサーバや仮想環境などでMySQLなどのミドルウェアを含む、本番運用環境をある程度意識した実行環境を設定・構築できるようになり、その環境を対象にアプリケーションのデプロイができるようになると良いのではないかと思いました。
この時点でGNU/Linuxの環境構築のためにUbuntuを選ぶかDebianを選ぶかCentOSを選ぶか、あるいはRDBMSにはMySQLを使うかPostgreSQLをを選ぶか、HTTPサーバとPHPの組み合せにはnginxからリバースプロキシでPHP-FPMを使うか、Apache+mod_phpを使うかなどの判断も求められます。今日ではHTTP/2ということばもちらついてきます。決めることはたくさんありますが、仕事の道具を選ぶということはそのようなことである気もしてきます。
一度PHPの実行環境ができてしまえば、あとはDeployerのようなツールを使ってデプロイできれば最低限のデプロイ環境は構築できたことになります。これをAmazon EC2やLightsailなどに対して行えば、まがりなりにも「AWSにPHPをデプロイした」と言えます。どうもこれではEC2のメリットが出ていないというか、レンタルサーバと同じことをEC2でやっているだけのように感じますが、実際にはここまでやれば、この記事で書き漏らされている、かなりいろいろなことを学び取っているはずです。ここまでくれば、その先はPHPとミドルウェアについてもうすこし理解を深めていくか、AWSのような環境を活用するか、コンテナを使った環境構築に向かうかといった次への選択肢が生まれていると思います。
IRT2: コーディングの手を早くしたい
パフォーマンスをチューニングする際の鉄則は、何事も始めに計測ありきです。問題に着手してから解決されるための時間を消化した支配的な要因が何だったかを見定めるのです、純粋に手作業に時間が掛かっているのだとしたら、それを解決するためのツール、IDEやエディタなどの理解を深めることが現実的な解決策になると思います。
ただ、今回の相談者の場合は純粋な作業速度の遅さよりも、コーディングに取り組む自身の姿勢に悩みがあるように感じられました。各人がどうやってプロフェッショナルの開発者としての自信と自覚を得るかは難しい問題ですが、本を読んで原理原則に触れるというのは解法のひとつかもしれません。ここではリーダブルコードや、オブジェクト指向の概念と実践を学ぶための本として現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法、そして洋書ですが富所さんが最近イチオシの書籍としてA Philosophy of Software Designが勧められました。また、ほかの参加者からは「とりあえずSOLIDだ」「デザインパターンは破ってもいいがSOLIDは守って」といった声が聞かれました。
IRT3: 開発環境(エディタ)について
ちょうどこの場にはVSCode、Atom、PhpStorm、Emacsなどの利用者が揃っており、とても良い情報共有の場になりました。
現代的なコーディング環境に期待される要素としては入力補完やコードジャンプ、リアルタイムでのコードインスペクションなどが挙げられるでしょう。PHPの静的解析機能の精度と付随する機能の充実を見ると、現在ワンパッケージで活用できるPhpStormがバランスとして最高であることは、ほとんど疑いがないように思えます。その上で最近はVSCodeから利用できるIntelephenseがPhpStormほどではないものの十分な水準のLSPとして機能しつつあります。特にPHPと同時にTypeScriptなどのフロントエンド環境も利用している場合はPhpStormよりも総合的に軽量かつ十分な機能を持つ魅力的な選択肢でもあります。
現状は静的解析ツールとしてPhanやPHPStan、PsalmあるいはPhpactorといったツールも十分な機能を持っています。私はPHP勉強会などでこれらのツールを紹介したり、Friends of Emacs-PHP developmentでEmacsと統合する活動を行ってますが、PhpStormほど性能としても可用性としても容易に導入をすすめられるかと言うと、総合的にはまだいささか厳しいものがあります。
私はPhpStormであっても抽象に対して依存されたコードでは実装を調査しようとしたときにインターフェイスや抽象クラスを指し実際に動作する実装クラスへは用意にジャンプできないのではないかと考えていましたが、これは誤解のようです。また、富所さんはかつてはプラグインに頼ったVimを使っていたが、スパルタンVimを読んで以来極力プラグインに頼らないようになり、VimとPhpStormを使い分けていると言ったのが印象的でした。
道具や機能には習熟や慣れ不慣れもあるものなので、ほかの便利なツールにある機能を知りつつも、自分の慣れた道具を手足のように活用することも大切な要素です。個人的にはEmacsが最高の道具だとも考えていないので、ほかのツールにも継続的に触れながらEmacsに還元できるものは順次取り入れようとしているところです。
またPhpStormのような静的解析についてもまだフレームワークによってサポートが完全ではないところを、ちょうど先日PHPカンファレンス北海道2019で川島さん(@nazonohito51)がCakePHP2でもPhpStormがコード補完してくれるようにした話という話をしていた件を紹介しました。
また別件ですが、最後の若干の空き時間では「ORMが好きか嫌いか」という話題が出ていました。この際にこちらもPHPerKaigi2019で川島さんが発表した単方向依存を実現する静的解析ライブラリのご紹介 / Analyze PHP Dependenciesというツールが活用できるのではないかという言及をしました。やっぱすごいな川島さん…
感想
LaravelをやってなかったとしてもLaravel.shibuyaは楽しくてためになるミートアップでした。あと主催者の5人(今回は4人だったけど)のホスピタリティがすごい。
