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