トーク

世の中のエンジニアでマネージメントをしている方は、たくさんいるかと思います。
私もその中の一人です。
普段、業務の中でコードを書くことができず、かといってメンバーのマネージメントに
技術力が必要ないか、というと、そういうわけでわけではありません。
そこで、CDDです。
業務以外にコードを書く習慣、モチベーションを保ち、エンジニアのQOLをあげる
方法をお話できればとおもいます。

PSRはPHP-FIG(PHPフレームワーク相互運用グループ)が発表する勧告群です。
その中ではHTTPについての勧告としてPSR-7, PSR-15, PSR-17そしてPSR-18が発表されており、これらはWebアプリケーションのモジュール間のインターフェイスとして活用できます。

今回は社内独自のフレームワークをPSR-7/15/17実装として置き換えた事例をとって、PHPとHTTPリクエストの関係およびPSR-17を実装したWebアプリケーションについて説明します。

このトークを見るにあたって、過去のPHPカンファレンスでの発表を含む「PSR-HTTPシリーズを理解するための情報源」を読むことを強く推奨します。
https://scrapbox.io/php/PSR-HTTP%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E6%83%85%E5%A0%B1%E6%BA%90

Track ID: Track2-3
Discord Channel: #track2-3-psr-http-web

新型コロナウイルスにより私たちの生活は一変しました。私が所属するコネヒト株式会社ではもともとリモートワークは行っていなかったのですが、例に漏れず緊急事態宣言が発令される少し前にフルリモートワーク体制に踏み切りました。
今後どうなるかは分かりませんが、突然リモートワークに踏み切った会社がこの9ヶ月の間に経験したこと、上手くいった取り組み、逆に上手くいかなかった取り組みを1つの事例としてお話出来ればと思っています。

評価や目標の制度に対して、皆さんはどんなイメージを持っていますか？程度の差こそあれ、皆さん一度くらいは不満を持ったことがあるのではないでしょうか？
私が所属するコネヒト株式会社では今年度から評価制度をフルリニューアルしました。本セッションでは、何故フルリニューアルすることになったのか？どのような評価制度なのか？どのように運用しているかなど評価制度の仕組みや裏側をお話させていただきます。
評価制度は技術的なトピックと比べるとまだまだ普段なかなか表に出ることのないトピックではありますが、エンジニアの仕事の中で重要な要素の1つだと私は考えています。ですので、本セッションを通じて評価制度についての議論やナレッジの交流が前進するように失敗談も含めてお話出来ればと思っています。

皆さんは普段DIコンテナを使っていますか？DIコンテナはそのメリットとデメリットを理解し、正しく使いこなせばソフトウェア開発の効率を高めてくれる非常に強力な仕組みです。
しかし、よく分からず使っていると却って、それっぽいだけでメリットを享受出来ていないソフトウェアが出来てしまう可能性もあります。
本セッションでは、CakePHPに新たに搭載されるDIコンテナの仕組みをもとに、そもそもDIとは何なのか？その上でDIコンテナとは何なのか？を紹介し、DIコンテナの導入によってもたらされる効能についてお話させていただきます。
また、これまで何故CakePHPがDIコンテナの仕組みを用意していなかったのか、何故このタイミングでDIコンテナが導入されることになったのかについても読み解いていきたいと考えています。

Track ID: Track3-4-B
Discord Channel: #track3-4-b-cackephp-di

PHP 8 の新機能のふるまいを、php内部のテストコードを通じて、理解する時間を提供します。

PHP 8 がもうじきリリースされる昨今で、 PHP 8 についての新機能についての関心も高まってきました。さまざまな新機能の抑え方がありますが、ひとつが、テストコードを通じて対象システムを理解する方法です。

phptというものがあります。これは、 PHP 内部コード、つまり php-src の自動テストスクリプトです。
ここには、PHP という言語自体の comitter たちがどういう振る舞いを PHP に与えたのか、それがレアケースのユースケースも含めて記述されています。

テストコードを書く皆様であれば、 Test as Document 、仕様を伝えるドキュメントとしてのテスト、を自身が運用するアプリケーションに対して書きますよね。phpt は PHP 8 の新機能に対するテストコードも含んでいます。

コードの読み手が、テストコードを通じて、 PHP 自体の振る舞いを理解する。phpt に記述されたコードを通して、次の2つを学びましょう。

1. phpt とは何か、その読み方がわかる
2. PHP 8 の新機能を抑える

具体的には、PHP 8 の新機能を題材にします。想定しているお品書きは以下です。

• Named Arguments
• Match expression v2
• Nullsafe operator
• Union Types v2
• Mixed type v2

※ もし、時間が許せば、上記の機能を実現するために、PHP内部の zend_compiler などにどういう変更があったか、まで軽く紹介します

Track ID: Track5-4-A
Discord Channel: #track5-4-a-phpt

Google Cloud SpannerのPHPのライブラリにはSession Poolが実装されています。
これは、複数のプロセス間でキャッシュされたセッションを共有するを実現しています。
本セッションでは、どのように、プロセスをまたいで、Session Poolを実現しているのか？
また、Cloud Spanner以外の応用についてご紹介します

アプリケーションに自動テストを組み込むのは今では一般的なことになりました。
しかし、テストにはUIテスト、統合テスト、ユニットテストといった種類があり、どこまでをどのテストでカバーすべきなのか、実際にどうやって書けば良いのかについては、まだまだ手探りの方も多いのではないでしょうか？

テストの設計には正解はないと思います。それはどれくらいのコストをかけて、どれくらいのリターンを得ようとするかがチームによって違うからです。それでも、実際に業務でテストを書いている経験から、どのようにテストを分割するべきか、モックはどのように使うべきか、という知見を話せたらと思います。

OpenAPI PSR-7 Message (HTTP Request/Response) Validator^1 というやや新しめのライブラリがあります。
定義された REST API 仕様に即しているかをチェックしてくれるのですが、これを Laravel の Middleware に組み込むという取り組みをしました。その結果、

• レスポンス^2 のみならずリクエストに関してもAPI仕様に即しているかをチェックできるようになった
• API ごとに テストメソッドを作らなくても良くなって、テスト実装負荷が少なくなった

といったメリットを得ることができました。
一方で、未解決の課題もあり、応急処置としてリクエスト・レスポンス両方を Validate するクラスと、レスポンスのみを Validate するクラスに分けるといった苦し紛れなこともしました。

本LTでは、この実装における良いところ悪いところを紹介して、ライブラリ活用についての何らかの知見を共有できればと思います。

「Laravel開発者の負担・工数を減らす」を掲げて、約10ヶ月前にリリースした「 LaravelDB.com 」。誰もが無料でお使いいただけます。
ER図を書けばそのとおりのMigration（最新バージョンではテーブル設計どおりのValidationも生成します）ファイルが生成されます。ER図は保存が可能なので、何度でもER図を呼び出して変更加えたり、コピーして別のプロジェクトを作成することも可能です。このツールの勘所を端的に解説する予定です。操作方法を知って少しでも楽に開発ができるように、少しでもLaravel開発者の皆さんの手助けになれば幸いです。

Track ID: Track4-1-B
Discord Channel: #track4-1-b-laraveldb-com

GraphQLをご存知でしょうか。名前は聞いたことあったり、実際に使用した経験のある方も多いかもしれません。
GraphQLは2015年にFacebookにより開発されたRESTとは異なる新しいAPIフォーマットです。
クエリ言語を用いてデータを操作することで、取得過剰や取得不足と言ったRESTの問題を解決し、本当に必要なリクエストを得られるようになると注目を浴びていました。

しかしながら2020年現在、PHPが得意とする領域においてはまだまだRESTが使用されているアプリケーションの方が多いかと思います。
今回は実際にLaravel + Lighthouseを用いてGraphQLによるWebアプリケーションを開発した際に得られた知見をもとに、なるべく実装コストや学習コストを下げた開発方法や実装する際の注意点、アンチパターンなどをお話しさせていただきます。

PHPでのGraphQL APIの開発はここまでやりやすくなったよ！というのを皆様にお伝えできればと思います。

Track ID: Track4-4-B
Discord Channel: #track4-4-b-laravel-lighthouse

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

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

「○○言語は汎用プログラミング言語だけど、PHP は Web 特化で Web 以外には不向き」

もう長いこと、PHP はこのような評価を与えられ続けてきました。
そしてそれは今や過去の話になろうとしています。

PHP は "PHP: Hypertext Preprocessor" の略[1]ですが、この 25 年間で Web は高度化し、複雑化し、それに伴い Web サイトを作るための言語にも、いっそう複雑な機能が要求されるようになってきました。

昨年リリースされた PHP 7.4 には Preloading や FFI など、多くの機能が導入されています。

そして今年の PHP 8 では、満を持して JIT コンパイラ が導入されます。
典型的な PHP アプリケーションは I/O バウンド（DB バウンド）です。JIT はそのような既存のアプリケーションのためというより、これまで PHP が使われてこなかった、また使えると思われてもこなかったような、新たな領域への扉を開くものとして、FFI や Preloading との組み合わせを念頭に提案されたものです[2][3]。

一方、世間の CPU は着実に多コアの時代へと進んできました。今の時代にある程度 CPU を使うアプリケーションを作るというのは、JIT を使うというだけの話では済まず、何らかの並列処理機構を用いてこの多コアの CPU とも向き合う必要があります。

このトークではそんな新時代における PHP を使って、

• FFI でシステムコールを呼び出して外部プロセスのメモリをのぞき見したり
• ローカルマシンで動作する（非 Web の） GUI ライブラリを利用してデータを可視化したり
• ext-parallel によりプログラムをマルチスレッド動作させたり
• スレッド間の通信処理に非同期処理を用いたり
• スレッドの動作を効率化するため preloading を活用したり
• JIT によりそのようなプログラム全体の動作を高速化したり

するという、これまでとは一味違った PHP の利用方法への挑戦を紹介するとともに、そこで得られた知見、現状の制限についてをお話します。

[1] https://www.php.net/manual/en/intro-whatis.php
[2] https://wiki.php.net/rfc/jit
[3] https://externals.io/message/102415#102415

Track ID: Track5-5
Discord Channel: #track5-5-php8-non-web

PHPer なら多くの人が経験するフォームの開発。
バグのないちゃんと動くフォームを目指すのは勿論、折角作るならより多くのユーザーに最後まで使ってもらえるフォームを作りたいですよね。そのフォーム、ちょっとした気遣いでもっと使いやすくなるかもしれません。
ユーザーの入力エラーを減らす、エラーになっても最後まで使いやすいフォームを一緒に目指しましょう。
フォームの開発やデザインを始めたばかりの方に向けて、すぐに取り組めるポイントをお話しします。

私が携わっているシステムでは、過去に既存PHPアプリケーションにLaravelを導入した経緯があり、bootstrap処理の中で独自設定を施しています。
これによってLaravelのデフォルト設定を都合が良いようにカスタマイズして使っています。
Laravelのデフォルト設定がどうなっていて、どういうカスタマイズをなぜやっているかをベースに、既存アプリケーションへの適用についてお話しできればと思います！
これから導入を考えている、設定をいじりたい、フレームワークのソースコードに興味があるという方の一助になれば幸いです。

私の所属する組織では、10年以上に渡って「小さなお葬式」というWeb集客型の葬儀サービスを提供し続けています。
サービスを構成するWebサイトや基幹システムをはじめ、関連するほぼすべてのシステムをPHPで開発しています。
本セッションでは、事業の急成長とともに肥大化・複雑化していった基幹システムをドメイン駆動設計を足がかりにリプレースした話を軸にして、
レガシーコードやレガシーシステムと向き合ってきた私達の過去〜現在〜未来についてお話させて頂きます。

株式会社ウエディングパークでエンジニアリングマネージャーをしています。

このプロポーザルを書いている10月からSREへジョブチェンジすることを決断しました。
私のこれまで歩んできたキャリアは、サーバサイド→マネジメント→QA→SREと、あらゆる職種を渡り歩いてきました。

PHP界隈のエンジニアを初めとして、昨今のエンジニアにおいてのキャリアパスは多岐に渡っており、
自分がどこに進めばいいか？何を極めていくべきか？どういう人材でありたいか？は頭を悩ませている人も多いはず。

今回は、私が10年間のエンジニアとしての歩んできたキャリアを1つ1つ棚卸しをしながら、
それぞれの分岐点で何を考えてきたか、失敗と成功例、キャリア整理の仕方など、
実際に経験し、実践をしてきたことをお伝えできればと思います！

コンテナネイティブ時代に突入した昨今、PHPer の皆さんはコンテナ化は済ませましたか？
Chatwork 株式会社では2020年に PHP アプリケーションをコンテナオーケストレーションツールのデファクトスタンダードである Kubernetes に置き換えました。

そこで、これからコンテナ化を行おうと考えている PHPer の方々向けに

• なぜ、PHP アプリケーションでコンテナを使用するのか
• コンテナ化、Kubernetes 化では何をする必要があり、何に注意する必要があるのか
• 開発環境でも Kubernetes を使うべきか

など、Chatwork の事例を元に解説します。

1. そもそも Kubernetes とは？ ～ 導入のメリット
2. コンテナ化の流れ ～ PHP アプリケーションの Docker イメージ化
   　- 設定を注入しよう (Env / File)
   　　- 環境差異を設定で吸収する方法
   　　- 整合性の検証方法
   　- ログ管理を行おう
   　　- 標準出力 (stdout) の取り扱い
   　　- TIPS: decorate_workers_output/log_limit の取り扱い
   　- 外部サービスと認証管理
3. Kubernetes 化の流れ ～ コンテナのオーケストレーション
   　- PHP アプリケーションにおける構成例
   　- Pod のライフサイクル (Readiness / Liveness)
   　- メトリクスの収集方法
   　- ロードバランサーの配置
4. 開発環境としての Kubernetes はどう評価できるか？
   　- パフォーマンスと安定性
   　- PHPStorm との連携はどうするか？
   　- Kubernetes Manifest の複雑性
5. まとめ

Track ID: Track3-2-B
Discord Channel: #track3-2-b-kubernetes

テスト駆動開発やビヘイビア駆動開発に代表されるように、PHPUnitなどのテスティングフレームワークを用いて開発時に自動テストを書くことは、今や当然のように行われています。
しかし一方で、長く開発が続けられてきたレガシーシステムにおいては、まだまだテストコードが書かれていないケースも珍しくないことでしょう。
そうしたシステムに一気にテストコードを書くことはできなくても、一部の機能から自動テストの導入を始めてみませんか？
このトークでは、13年続くレガシーシステムの改修案件で、PHPUnitを導入し既存ロジックをリファクタリングしながらテスト駆動で新機能を開発した事例をお話しします。