最近の PHP コードは意外と型の恩恵が得られます。
PHP 7.0 でのスカラ型宣言、7.1 での nullable、7.4 でのプロパティ型宣言、 8.0 での Union や明示的 mixed の導入といった言語自体の機能追加もあるのですが、psalm や phpstan といった静的解析ツールを利用することで、静的型検査や mixed の排除、Type Erasure な Generics の利用といったことさえできます。
このトークではそんな最近の PHP の型事情、ツールについてのお話や、実際に静的解析ツールを最高レベルで利用し型をガチガチにしながら PHP コードを書く際の注意点についてお話します。

「プロダクト開発が、メンバーの技術力を高めるのか」「メンバーの技術力向上が、プロダクトの品質や可能性を高めるのか」
皆さんは、この「鶏が先かと卵が先か」に似た構造を持つ問題についてどのような考えをお持ちでしょうか？

本セッションは、自分自身の取り組んでいることを紹介した上で、
オーディエンスの皆さんからの視点や経験を織り交ぜたフィードバックと議論を集め、『共有知』を生み出す試みとしたいと考えています。
(折角のオンライン＆録画発表なので！)

この課題を選んだ背景

プロダクト開発や(Web)サービスの提供を行う会社において、
Webエンジニアに求められる主要な成果は「プロダクトを良くする」ことだと思います。
プロダクトをよく出来るエンジニアとは、どういう存在でしょうか？
実は、「プロダクトをよく出来るエンジニア」になるには「プロダクトを開発する以上の技量」が要求されるのではないでしょうか。

ここには大きな矛盾があると考えています。
「プロダクトを良くし続けるには、プロダクトに必要なレベルの技量では足りない」という矛盾です。
これについて、自分自身が、所属先の企業でのロールが変化したのをきっかけに取り組むようになりました。
組織の姿が「プロダクトを作れる」を超えた「プロダクトの未来を作れる」ようになるにはどうすればよいか・・？と現在進行系で考えています。

紹介するお話

例えば、以下のような取り組みが「自分なりに考えたこと」でした。

• 「技術力」を定義する
• プロダクトと技術力の関係
• 自分自身が「技術的な成長」を感じた瞬間を構造化して捉える
• その「良いフィードバックの獲得の仕方」を組織的に再現できないか？

こうした話を「議論のネタ」として提供したいと考えています。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。
テストケースに振る舞いを自然言語で併記しながらテストコードを書くことで結果としてテスト仕様や要求仕様のドキュメントで実現するようなアプローチもあります。
私もシステムやコードからドキュメントを生成するようなツールを少なからず作ってきました。
そういった経験から、本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えていきます。
そして本発表を通じて皆さんが「Documentation as Code」に興味を持ってもらえればと嬉しいです。

比較的モダンなフレームワークでは、例外処理や例外発生時の検知・ロギングが仕組まれていますが、PHPでは検知をすり抜けてアプリケーションを終了させる手段が多数存在します。本セッションではPHPのプログラム実行の仕組みから、どのようにすれば検知の網の目をすり抜けることが出来るのかを解説します。この知識を得ることによって、逆にどのようにアプリケーションを作成すれば、比較的安全を担保できるのかが理解できるようになります。

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

• PHPの例外検知機構と検知不能が発生する仕組み
• 最後の悪あがき「register_shutdown_function」の仕組み
• 検知不能状態を検知する方法の提案

バージョン 8 にしてとうとう僕らの PHP にも JIT がやってきました！
が、PHP 8 の JIT は生まれたてで、同じ 8 でも JavaScript の V8 にはまだまだ速度的な面で追いつかない部分があります。
PHP と JavaScript のそれぞれについて、おおむね同等の処理を行うマイクロベンチマークのコードを用い、プロファイルをとりながらああだこうだ言いつつ速さの特性差や PHP の現状の限界、得意な点や不得意な点を探っていきます。

■ 想定する聴講者
典型的な Web アプリケーションは主に I/O バウンドとかそういう現実の話は脇に置いておいて、PHP スクリプトの性能や測定方法が気になる人
今後の PHP の性能の伸びしろに思いを馳せたい人
しょうもないマイクロベンチマークが好きな人

■ お話しないこと
明日から業務に使える役立つ知識

新規サービス開発において、PHPウェブアプリケーションを実際に世界に向けて動作させるためのインフラが必要になります。では、一体どのようにしてインフラを選定したら良いのでしょうか？プログラミングの世界ではDRYやYAGNI等の格言や、アーキテクチャー選定の考え方が浸透していきていますが、インフラにおいては、基準が曖昧です。本セッションでは、ウェブアプリケーション初期構築時のインフラについて実例を紹介しつつ、妥当なインフラを選択するための基準を紹介します。

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

• 選択可能なインフラ環境
• 選定時の基準
• 各環境の利点と欠点

bugs.php.net は PHP の公式 issue トラッカーで、処理系本体と公式バンドル拡張、PECL 拡張をあわせて現在 2000 以上の未解決のバグが登録されています。

古いものでは PHP4 時代のチケットで残っているものもあり、現在サポートされている処理系バージョンにおいてすでに解決済のものや、そもそもバグではないもの、当初は明らかにバグだったとしても 10 年以上その挙動が続いたことで、もはや仕様としてしまった方がよいのではないかと疑われるものなど、色々なチケットがあります。

そんな bugs.php.net の古くからある塩漬けチケットについて、現在サポートされている PHP 7.4 以降でも再現するか、レポート内容が妥当かなどを検証しつつ、修正可能なものについては PR を投げ、修正不可能であったり修正の必要がないものについてはコメントを追加して現在の状況を付記する、という清掃活動に取り組んでみました。

bugs.php.net 自体やチケットの調べ方について紹介しつつ、見つけて面白かったチケット、実際に対応したチケットについてお話します。

Everything Will Be Serverless.
そんな未来は来ないかもしれません。
しかし、私はそんな未来を信じてお話します。

話者は昨年AWS上でFull Serverless SPAの構築を行いました。

今までサーバーを意識したPHPのWebアプリケーションを作成する事が多かったの話者が、
サーバーやRDBMSを使わないFull Serverless なWebアプリケーション構築を通して学んだ知見を共有します。

ServerlessなGo APIとReactのSPA構成を構築して実感した所感もお話できればと思います。

■利用言語、フレームワーク

• Go
• React x TypeScript

■利用AWS リソース

• AWS Lambda
• Amazon DynamoDB
• Amazon S3
• Amazon CloudFront
• Amazon Cognito
• AWS Amplify
• Amazon Athena、Amazon S3 Select
• Step Functions、AWS Batch

■想定する聴講者

• Serverlessに興味がある方
• AWSが好きな方
• 理論はわかるけど実際に構築したことが無い方

■お話する内容

• 実際の構成について
• ServerlessなSPAの開発手法について
• APIとフロントエンドの結合部について
• 開発からリリースまでで実感した所感

PHPに限らずエンジニアとして日々技術情報をインプットすることは重要です。
技術情報はただインプットするだけでなく議論を通して様々な角度から捉え直すことで、より深い知識を得ることができます。
そのような深い技術知識をインプットするために、弊社ではPHP関連の最新情報について語り合うイベント「PHPTechCafe」を毎月開催しています。
イベント運営には様々な試行錯誤がありましたが、PHPerKaigiをはじめとしたコミュニティの取り組みを参考に自社イベントを継続した結果、参加者100人以上、著名なPHPerにも参加して頂くなど、イベントの成長と拡大を実感できています。
私自身、イベント内で参加者同士の議論に参加できるように海外のニュース記事やホットな技術情報を積極的に収集していくうちにPHPエンジニアとしての成長も感じられるようになりました。
この発表では、自社イベントの運営スタッフを経験していくうちにイベントの成長とともに自分自身もPHPエンジニアとして成長を実感できた経験とその取り組み事例をお話します。

Nuxt.js は Vue.js をベースにした SPA や SSR が比較的簡単に実現できるフレームワークです。
Laravel の Blade のようなテンプレートシステムで構築していたフロントエンドを Nuxt.js のようなフレームワークに移行する際、あるページは Blade を、また別のページは Nuxt.js を使って構築するというように両者が共存する状況が起こりえます。

このような少し込み入ったアーキテクチャのシステムにおいて、 A/B テストの基盤を自前で構築する機会がありました。
Laravel と Nuxt.js の両方で同様に機能させるための設計、ユーザーの振り分けロジックの実装、 A/B テストの結果の集計方法といった知見をこのセッションで共有できればと思います。

はじめてのアクセス制御の導入でCasbinというライブラリを使ってみたらすごくよかったので紹介します。

Casbinを用いたロールベースのアクセス制御の導入を例に挙げて、
権限モデルの種類やCasbin、CasbinのLaravel向けパッケージであるlaravel-authzなどについて話します。

元々パッケージとして開発していたソフトウェアですが、リライトせずSaaS化をしたという話です。

qiitaで途中まで書いた話です。
https://qiita.com/Rei_okawara/private/ec0dfe9bf552f7d78101

みなさん N+1 問題ってご存知ですか？DB への接続をループ分で N 回実行し、+1 はカウントで全件数を取ってきたりすることを総称して N+1 問題というかと思います。他にもループ分で N 回実行しているコードだけのものも総称して N+1 問題と言ったりしますね。言葉の真意は神のみぞ知るですが、概ねこういった理解の方が多いのではないでしょうか。もちろん N+1 は DB に限らず外部リソースへの接続も同様と理解すべきです。外部リソースといえばキャッシュ用の Redis もそうですし、全文検索エンジンの Elasticsearch も同様です。1 回の接続であれば目を瞑ることもできますが、ウェブアプリケーションとして稼働している場合、そういうわけにもいきません。そして、N+1 問題はパフォーマンスチューニングにおいて重要なファクターの一つにあげられることも多いかと思いますが、具体的な改善方法は中々調べても出てきません。そこで、本トークでは N+1 問題をそもそも生み出さない方法はどうするのか、既存のアプリケーションから N+1 問題を改善するためにはどうしたらいいのか、といった今後あなたが開発をしていく上での一つの引き出しになれるようなトークを私の今までの経験を交えてできればと思います。

何らかの理由によって「既存のクラスやAPIの使い方が変更された、それに対応しないといけない！」という場面が、
しばしば開発の現場には発生します。
その時に、なるべく「人間の目と手で作業する」という負担は避けたい・・面倒くさいな・・と思うのが人の心情ではないでしょうか。

https://github.com/rectorphp/rector は、既存のPHPコードのリファクタリングやアップグレードを自動実行するツールです。
こいつを上手く使えれば、あの退屈で機械的な作業を真の意味で「機械の作業」にする夢が叶うかも知れません！！

本セッションでは、Rectorについて紹介し、具体的に活用するための方法を話したいと思います。

おしながき

• Rectorってなに？
• どういう仕組で動いてるの？
• 具体的にどうやって使われてるの？ 〜CakePHP4の アップグレードコマンドを例に〜
• 独自ルールを作ってみる

普段の開発において、OSSのライブラリやフレームワークの利用は欠かせません。
そこで「これはどう動くんだろう」「何でこんな動きをするんだ」と思った時にできること・・・公式のドキュメントを読んで見る、インターネットに公開されているブログ等の情報を探してみる。
そして「ソースコードを読んで見る」、「マージまでの経緯を読んで見る」ことです！
ソースコードを読むためには、多少ボリュームのあるソフトウェアからでも「目的の場所を手早く見つけてみる」のが重要です。
また、OSSならではの利点として、コードだけでなく「そこに至るまでにどんな議論があったか」という情報にもアクセスすることができます。ここでもまた、多少のコツを掴んでおくと便利です。

今まで「フレームワークのコードを読んでみるのは苦手だ」「ググって欲しい情報に近い解説やQ&Aが出てこなかったら諦めちゃう」という日々を過ごしていたあなた！
私の周りにも、「ライブラリのコードを読むのは怖い」「面倒くさそう、億劫だ」という人がチラホラいるものと感じます。
もし「ドキュメント探すよりコード読んだ方が早いわ」という選択肢を手に入れられたら、きっと楽しいことになりますよ・・！

明日からは「もっとライブラリと仲良くなれるぞ♡」な日々を歩んでいきませんか？
本セッションが、そのための勇気をもたらす最初の一歩となれればと思います！

プログラミング覚えたての時、電卓を作るといったことをした方や、今現在プログラミングを学習中で電卓を作っている方もいらっしゃるかと思います。
電卓を作るといえば「1+1」と入力したら単純に「2」が出力されるイメージでしょうか。作っているうちに、「あれ？「((1 + 2) × 3)-((1 + 2) × 3)」みたいな式はどうするんだ？」と疑問に思った方も少なくないと思います。そこで本トークでは3分間という短い時間で、複雑な式を計算できる、もう一段階上の電卓を作る方法についてお話します。

ふと「別の言語も学んでみたいけど、とっつき方がわからない」と思う方も多いのではないでしょうか。
特に近年よく使われる TypeScript などを触ってみたいけど、難しそうと思いなかなか手を出しづらいと思っている方もいらっしゃるかもしれません。
TypeScript をチョットワカルようになるだけでも、業務の分野が広がり、フロントエンドエンジニアの業務がどういったことをやっているのか理解しやすくなります。
ちなみに、私は TypeScript を初めて触ったときに作ったものは、ハムスター監視システムでした。
そこで、PHPer である私がどのように TypeScript を学習し、ハムスター監視システムを作り、そして業務レベルまで扱えるようにしたのか本トークでお話させていただければと思います。

ふと「別の言語も学んでみたいけど、とっつき方がわからない」と思う方も多いのではないでしょうか。
特に近年よく使われる Go などを触ってみたいけど、難しそうと思いなかなか手を出しづらいと思っている方もいらっしゃるかもしれません。
Go をチョットワカルようになるだけでも PHP にはない新鮮さ、楽しさを感じることができます。
ちなみに、私は Go を初めて触ったときに作ったものは、ハムスター監視システムで、もともと PHP で作られていたシステムを学習の意味も含めて Go にリプレイスしました。
主に大きい学習としては非同期に処理ができる WebSocket サーバーの実装をゼロから作り上げた点です。もともと Go は既にいろんな WebSocket のサードパーティモジュールが提供されています。しかし、あえて茨の道を進むことにしました。
そこで PHPer である私が Go を歩むにあたってどのように学習をして、WebSocket サーバーの実装を行っていったかを本トークでお話できればと思います。

去る9/19〜9/21にiOSDC Japan 2020という技術カンファレスがオンラインで開催され、60本のトークと20本のLTが実施されました。
実施された60本のトークはすべて事前収録され、それを当日に再生する形でカンファレンスを開催しましたが、60本の動画の編集にかかった日数は3日ほどでした。動画編集に詳しい方であればちょっと驚く期間かと思います。

この高速編集を支えたのはPHPでした。

このトークでは私がどの様にPHPでオンラインカンファレンス向け録画システムを構築したのか、そして、同じ様なシステムを作りたい方のためのサービス連携のコツをお話しします。

• Zoom, YouTube Live, Dropbox を連携させた収録システムの作り方
• GD, ffmpeg を使用したオンラインカンファレンス用動画編集システムの作り方
• PHPでサービス連携するためのコツ

このトークを聞いたみなさんが、PHPで高度なシステム連携アプリを作るきっかけになることを期待しています！

参考:
iOSDC Japan 2020
https://iosdc.jp/2020/
iOSDC Japan 2020 トーク動画
https://www.youtube.com/playlist?list=PLod2oSGQp3W4BV6sLUdMwlZD0NHt9mHP7