トーク

PHPコーダーの皆さん!型、付けてますか?

PHPStanやPhan、psalmを利用することで、PHPでも実際に実行する前に型エラーを検出することができる事は既にご存知でしょう!(知らなくてもこのセッションを聞けばOKです)

静的解析のライブラリを活用することで、

• int|nullを返却する関数のnullハンドリングを忘れていたり
• '1' === 1といった数字文字列の取りあつかいの間違えを見つけたり
• 存在しない可能性のある配列の中身へのアクセスを事前に検知したり
  することができます

特に、PHP8からは、存在しない配列の中身へのアクセスがWarningからErrorへ変更されており、環境によってはPHP7からのアップデートでアプリケーションが動かなくなる原因の一つである一方、Union型のサポートなど、言語としての型サポートも整っていく傾向があり、アップデート作業の一環としても強力なツールとなります。

既存のPHPプロジェクトに静的解析ツールを導入する際に問題になるのが、

• エラーが多く出すぎる
• アプリケーション内で、文字列でクラス名を扱かっているのでクラスが静的解析で追えない
• 値域を厳密に制限する関数や返却する型が動的に変わる関数では、PHPdocのtypehintを利用した静的解析では、動的な型付けに対応できない
  場面が多くあります。

このセッションでは、PHPStanを用いた型解析について説明した後に、

• ~コミット差分によるエラー検出をし、変更箇所に起因するエラー箇所をciで警告するようにした方法(github actions/gitlab-cilですぐに使えます!)~
• PHPStanのオリジナル拡張を作って、PHPStanデフォルトの機能で手が届かなかった点を改善する方法(実際にセッション中に拡張を作ります!)
  について話します

Discord Channel: #track2-5-a-php-static-analysis-2021

小学校でプログラミング教育が必修化される中、「Scrach」のような
ビジュアルプログラミングは注目されています

そんな中、LOVOT（https://groove-x.com/）と呼ばれる
『役に立たない、でも愛着がある” 新しい家庭用ロボット』がコンセプトの
ロボットに、「LOVOT STUDY ビジュアルプログラミング」という
ブラウザを用いてビジュアルプログラミングし、LOVOTを操る仕組みが提供されています

"ビジュアルプログラミング"でできることは、PHPでもできる！ことを
実証するために、
本来、ビジュアルプログラミングで操作するLOVOTを
直接PHPのプログラムから操作してみました(非公式)

まずは、ビジュアルプログラミングを解析する過程、そして
解析内容を元にPHP（Ampを用いて）で再実装する過程をお話しします

Let's PHP programming！

Discord Channel: #track3-5-a-php-robot

普段開発しているコードベースでは PHPStan で静的解析をしているものの Lev.1 に留まっており、レベル上げをしようとすると大量のファイルがあって膨大な数のエラーが出てしまい手付かずの状態でした。静的解析が弱い分、ユニットテストや手動テストを主にして検証を行っていますが、手動テストの終盤で型エラーが起きてやり直しになるなど、非効率なことが起きていました。

その状況を改善すべく、モジュール毎に静的解析レベルを設定することで独立したメンテナンスを可能にし、比較的新しいモジュールからレベル上げをしていきました。
本セッションではその取り組みやつまずいたポイント等について紹介し、これから静的解析を強化していく方の参考になれば幸いです。

・解析対象と実行方法の整理
・レベル別静的解析の恩恵
・Laravel IDE Helper の問題点とその対応
・レベルを上げてからのコードの書き味

Discord Channel: #track2-5-b-php-static-analysis-max

私はこの数ヶ月、趣味プロジェクトとして、1990年代にアーケードゲームやハイエンドパソコンで輝きを放ったYAMAHAのFM音源チップ、YM2151を制御するためのハードウェアとソフトウェアの開発をしています。

こう言うと難しく聞こえるかもしれませんが、実はハードウェアの世界にも私たちソフトウェアエンジニアが「API」や「プロトコル」と呼びそうな決まりがあり、その決まりに従って音源チップに命令を与えることで音を鳴らすことができるのです。

このトークでは私が開発しているYM2151制御ハードウェア・ソフトウェアを題材に、コンピュータシステムの周辺ハードウェアがどの様に制御されるか、そしてその制御をソフトウェア的にどの様にするかを解説します。もちろん制御ソフトウェアはPHPで書いていますのでPHPerのみなさんであればスッと読めると思います。

このトークを通じてコンピュータシステムの動作について興味を持っていただく方が増えることを期待しています！

Discord Chanenel: #track3-5-b-php-hardware

2019年にGaroon（ガルーン）のレガシーさに立ち向かい改善が行えるようになってきたとお話ししてから2年が経ちました。
https://speakerdeck.com/oogfranz/gai-shan-shi-bai-sitexue-bu-regasipurodakutonili-tixiang-kautimuzuo-ri
このセッションではこの2年間で実施してきた改善内容と、持続的に活動をしていくためにどのようにチームのプロセスを変えていったかについてお話しします。

この2年間、開発チームはバックエンドのController層を改良したり、フロントエンドをES5からTypeScriptに移行するなど、メンバー全員で色々な改善を実施してきました。
もちろん改善活動だけでなく、新機能開発やそれ以前から行っていたPHPのアップグレードなどGaroonを継続して提供していくための活動もしています。
なので、Garoonに必要なタスクをしながらも、改善もできるようになりました。万歳！

...とはなかなかなりません。
開発されてから19年目を迎えたこの巨大な製品には、まだまだ多くの負債が着手されないままに残されています。
また、新機能を開発しながらも多くの負債に立ち向かう中で、どの負債から優先的に対応するのかや人的リソースをどう割り振るかなど、チームとして改善を試みることの難しさに直面しました。
プロダクトのレガシーさに立ち向かえる環境作りはできましたが、それだけではレガシーさに立ち向かうのは難しいのだという当然のことに改めて気付かされました。
そんな中で、より効率的かつ持続的にプロダクトを改善していくために必要だと気づいて取り組んだ課題が、チームのプロセスを見直すことです。
これをきっかけに、問題意識の言語化や各種活動の振り返りが進み、いまチームは「Garoonを開発者にとって魅力的なプロダクトにする」ことを新しい目的として、以前よりさらにワクワクしながら活動し始めています。

そんなサイボウズGaroon開発チームの経験を是非お聞きください。

Discord Channel: #track1-6-a-cybozu

2020年10月24日に、Composer 2.0がリリースされました。
Composer初のメジャーバージョンアップデートですが、どんな新機能が増えたのでしょうか？

そこでComposer2.0で新しく実装された機能について、時間が許す限りご紹介・解説いたします。
時間の都合で全ての機能について触れられない可能性がございますが、以下の機能について触れる予定です。

• パフォーマンス向上
• アーキテクチャの変更による依存関係の更新プロセスの改善
• ランタイムの新機能
• 依存関係のエラーレポートの改善
• パッケージのバージョンの部分的な更新
• その他便利なオプションなど

Discord Channel: #track2-6-a-composer2

このセッションでは求人数1位になったPHPの状況と、いよいよ本番試験開始となった徳丸実務試験とPHP8上級試験の模擬問題解説を行います。WordPressの原理原則を問うKUSANAGI for WordPress認定試験の紹介も行います。

Discord Channel: #track1-6-b-php技術者認定機構

今では当たり前となった、自身の知識や成果をGitHubに公開するということですが、今回は業務内で実際に書いたコードを、問題なく自然な形で公開する一連の流れを私の体験をもとにしてシミュレートしてみます。
今回はファイルのウイルスチェックをする機能がLaravelで書かれた業務コード上に直接実装されている状態を想定してみます。ウイルスチェック自体は業務とは何の関係もないため、何とか機能を分離してメンテナンスしやすくすることを考えます。
まず初めにやることは、InterfaceとDIを駆使して、ウイルスチェック機能を業務コードから切り離しです。
ここからウイルスチェック機能をいったん外部コードとして公開し、Composerを使って業務コードに逆輸入するように修正します。これで、業務に直接関係ないコードをリポジトリの外に追い出せるとともに、自身の実績を外部に公開することができます。
最後に、Laravelとの接続部分とウイルスチェックの本体実装を分離し、特定のフレームワークとの依存性も排除し、より広範囲に使える状態を実現します。
この発表を通して、InterfaceとDIの活用方法や、Composerによる依存性管理の便利さを再認識いただけると幸いです。

Discord Channel: #track2-6-b-composer-interface-di

OpenAPIにはリクエストやレスポンスだけでなく、求める型や正規表現も記述して利用することができます。コードの自動生成についても盛んに行われていることもあり、最近のプロジェクトでは採用されることが多いのではないでしょうか？
とはいえ、OpenAPIを自分たちで書かなければいけない場合はめんどくさいと思います。
そこで、このセッションではLaravelからOpenAPI仕様書を自動生成する方法を紹介します。
また、生成したOpenAPI仕様書を閲覧用として利用するだけではなく、LaravelのE2Eテストやバリデーションに生かす方法についても話します。

このセッションで話す内容

• LaravelでOpenAPIを半自動生成する
• LaravelのE2EテストのアサーションをOpenAPIに沿った形で行う
• LaravelのFormRequestにOpenAPIを使う
• (予定)今回の内容を業務で利用してみた感想

想定するレベル感・技術的な要素

• OpenAPIやSwaggerを知っている
• Laravelを使ったことがある

Discord Channel: #track1-7-a-yumemi

非同期処理、IO多重化、平行、並列...これらの言葉は、同期処理がメインのPHPウェブアプリケーション開発者にとっては理解が難しく、近寄りがたい雰囲気を持っています。しかし、コンピューターの資源を余すこと無く使って、資源利用効率の高いアプリケーションへの要望は高まってくるばかりです。近年のPHP界隈においても Swoole , Amp, ReactPHP, RoadRunner 等、非同期処理を行うためのツール、フレームワークがたくさん生まれています。また、PHP 8.1 においては軽量スレッドと呼ばれる Fiber も実装されます。

本トークでは、仕事で同期処理ばかり書いているエンジニアが、Echoサーバーのような簡単なサンプルプログラムの作成を通して、非同期処理を理解するための第一歩を踏み出す方法を紹介します。

このトークでお話すること

• 非同期処理とはなんなのか
• Swoole, Amp, ReactPHP は何を目指しているのか
• Generator とは何か
• Fiber で何が出来るようになるのか

Discord Channel: track2-7-a-php-async

速度は求めたい。ユーザのためである。
設計方針は崩したくない。開発者のためである。
「速度も求めつつ、既存の設計方針を守り、ユーザに価値を届ける。そんな方法が欲しい。」

こちらはそんな思いから生まれたテクニックを紹介するセッションです。

Domain Repository は Domain Entity もしくはそのEntityのリストのみを返して良いという制約があるとする。
なんらかのリストをユーザに見せる時、アプリケーション層で複数の種類のEntityを取りまとめてData Transfer Object（以下
DTO）として情報を固めて渡したいということがよくある。
愚直にやるのであればアプリケーション層で最初のEntityを取り(①)、さらに他のEntityのIDから他のEntityを取得する(②)という形であろう。
仮に、最初のEntityが1個、次に取りたいEntityが1個、そういう場合は全く問題はないのだ。

しかし、最初に取得するのがEntityのリスト(①)の場合に困ってしまうのだ。このリストを元にループを回して、次に取りたいEntityを逐次取得(②)しDTO を組み上げるとする。そうすると①のリストの長さの分だけ、②のEntityを取得するためのRepositoryを叩くことになる。

理想的にはDomain Repositoryの裏に隠れているインフラの層は隠蔽されており、知ったことではないのだ。しかし、実際のところ多くのケースで裏でDBから取得しているであろう。いわゆるN+1問題だ。

以下のような方法論で問題は緩和されたり、避けられるかもしれない。

• キャッシュをする
  • ②の Repository の get() などにキャッシュを差し込む。N回キャッシュ問い合わせがあることは変わらない
• 一覧にページネーションを追加する
  • Nを減らすアイディア。問題の緩和にはなるが、ビジネス要件によっては難しい。
• Command Query Separation を使う
  • Query で Repository を通さないで DTO を直接取得してしまう方法。一見根本解決ように見えるが、すでに Repository で get 系を書いていると取得処理が重複管理になり、管理不能になりがち

これらの方法には一長一短ある。
私は、Repositoryを使った設計パターンは崩したくない。けど速度は欲しい。そう考えた。

第4の選択肢としてHash Map Attachment法を提唱する。名前は独自命名だ。
Repository から取得したEntityから Query Service で DTO に変換する時にN+1問題とO(N^2)に陥らないようにするテクニックである。

Discord Channel: #track3-7-a-repository-pattern

Xdebugを活用していますか？ステップ実行の機能については、利用経験者も多いかと思います。
公式サイトを開き、トップページを見ると「Step Debugging」「Improvements to PHP's error reporting」「Tracing」「Profiling」「Code Coverage Analysis」と主要機能が列挙されています！

「知らなくて使っていない」のと「使っていはいないが知っている！」では、大きく違います。
まだ試してみたことが機能がありますか？
本セッションでは、これらの機能を紹介しながら「実際にどう使うものなのかな？」を共有していきます！

Discord Channel: #track1-7-b-xdebug

Laravel 公式から非同期処理 HTTP サーバーとして動作する Laravel Octane は PHP8 から使用可能です。Laravel Octane は Laravel を開発しているテイラー自らが開発に乗り出しているものです。

Laravel Octane は非同期処理の話を賑わせている RoadRunner や Swoole に対応した HTTP サーバーで、重たい処理などを非同期に処理をしたいニーズにも満たしています。私自身は Laravel Octane とは別に laravel-swoole と呼ばれる HTTP サーバーを 1 年ほど試してきて、プロダクションで扱う際のノウハウをいくつか得てきました。そこで、Laravel Octane を使うメリット、Apache や Nginx と何が違うのか、使う上での注意点、laravel-swoole を使ってきて得られたノウハウを交えてお話できればと思います。

Discord Channel: #track2-7-b-laravel-octane

日々アプリケーションに向き合って開発している中で、「またこの機能書いてる…以前にも同じ機能を書いた気がする…」となることはありませんか？
このお悩みは、よく使う機能の汎用ライブラリを作っておくことで解消できるのですが、うまく抽象化ができていないと、使いにくい汎用ライブラリになってしまったり・汎用ライブラリを使うたびにカスタマイズ開発が発生したり…という別のお悩みが発生してしまいます。こうなってしまっては、楽をするための汎用ライブラリなのに本末転倒ですね。
過去のプロダクト・今のプロダクト・未来のプロダクトを見据えて、上手に抽象のはしごを登り、使いやすい汎用ライブラリを作るためのコツをサンプルコードを通してお伝えします。

Discord Channel: #track3-7-b-build-generic-library