PHP Conference Japan 2021
2 - 3 Oct 2021 at Online (YouTube Live)

The opening ceremony for PHP Conference Japan 2021.

今年リリースされるPHPの最新バージョン8.1における機能強化・変更点を中心にPHPの開発に関する最新の情報，PHPコミュニティに関する話題について紹介します．PHPの最新動向に興味がある方向けに，初心者の方にもわかりやすい解説にしたいと思います．

5Gは色々なトピックで話題になっています。皆様も5Gに繋がっていますでしょうか。 5Gは無線、コアネットワーク共に4Gから大きな技術的進歩を遂げています。 モバイルネットワークの技術はWi-Fiにもその技術が応用されるようになりました。 本セッションでは、5Gの無線、コアネットワークの進歩とそれによって私達がどう幸せになるのかをお話します。 トラーナのビジョンである幸せな親子時間を増やすことに絡めてお伝えできればと思います。

AWS Fargateを利用した大規模サービス開発におけるインフラ設計のポイントや工夫していること、デプロイフローなどについてお話しします。 [想定する聴衆]現在Fargateを利用されている方、オンプレミスやEC2からコンテナサービスへの移行を考えている方

ローンチ当初は少人数で依存や実装に関するルールを整備せず、都度コミュニケーションを取りながらスピード重視の開発をしてきました。結果サービスは急成長し、開発人数も増えてきたため、アーキテクチャの導入を進めることとなりました。 アーキテクチャ導入前にはどういった問題があり、導入後はどのように変わってきたのかをお話します！ 技術レベルは初心者〜となっております。同じような状況に置かれている皆様のご参考となれば幸いです。

こちらでは初心者向けのPHPプログラマを対象にPHPのコーディング規約(PSR)と自動整形についてお話したいと思います。 自動整形ツール php-cs-fixerとphp_codesnifferの挙動を一緒に見ていきたいと思います。 ■アジェンダ ・そもそもコーディング規約はなぜ必要なのか ・PHPにおけるコーディング規約 ・自動整形 ・php-cs-fixerとphp_codesnifferの違いについて 少しでも皆さんの手助けになればと思います。 ※サンプルはLaravelを使用したものになります

ユーザからのお問い合わせに対して適切な回答を行うことは、様々なサービスを提供する上でとても重要です。弊社ではその中でも技術的なお問い合わせについて、Slack上で問い合わせ担当エンジニアへ調査を依頼する業務フローが存在します。現在、問い合わせ担当エンジニアは当番性であり、担当領域以外の問い合わせについても対応しています。この業務フローに関して、新しいお問い合せのうち、一部は過去に対応したお問い合わせと類似したものや一致するものが存在し、回答の参考になることがあります。 本セッションでは、新しいお問い合わせについて、過去のお問い合わせから類似するものをAmazon Elasticsearch Serviceを使用して自動で抽出し、同時にKibela Web APIを使用して関連するドキュメントを検索した上で、Slackのスレッドに投稿するシステムについて導入した話を紹介します。

### トーク概要 自作フレームワークの話になります． 趣味で開発をする際にLaravelを多用していますが，Laravelの内部構造について「よくわからない」という感情を持ちながら利用しており，その内部構造を理解するために実際に自分でフレームワークを作りながらLaravelのようなフレームワークを作ってみるというお話をさせていただきたいと思っております． 他にも，オブジェクト指向や自作フレームワークについて，まだまだ勉強することはたくさんありますが，自分なりに実装をしてみたり，たくさんのかたに相談をして実装を進めており，その中で，これまでに得た知見を発表したいと思っております． ### トーク対象・分野 オブジェクト指向，フレームワークなどの初学者がメインとなりますが，ベテランの方からのフィードバックもいただきたいと思っているため，対象や分野は広く取りたいと考えております． ### その他 大きなカンファレンスなどに登壇するのは初めてです．

PHPのメジャーバージョンアップは変更点が多く、歴史が長くコードベースの大きなサービスでは対応に手間が掛かることが度々発生します。 弊社ではPHPのEOLを避けつつサービスの品質を担保するために、PHPのメジャーバージョンアップを2年に1回は必ず行っています。 そのため、今年EOLを迎えるPHP7.3からPHP8.0へのバージョンアップを行いました。 今回、対象となったサービスは2008年から続いてるレガシーシステムであることと、PHP8.0の変更点が多いことが重なり過去にないレベルの修正が必要となりました。 PHP8に対応するあたり発生する、次のような課題と、それに対する解決事例をご紹介します。 ・影響範囲の調査と対応範囲の検討 ・後方互換性の無い変更に対する対応 ・静的チェックが難しい変更点に対する対応 ・品質担保 息の長いサービスがPHP8対応する際に注意すべき点、大きな課題を発見した際にどのように解決したのかを具体的に紹介します。 これからPHP8対応を行う方々の一助となれば幸いです。

Hameeでは"ネクストエンジン"というプロダクトをPHPを使って開発・運用をしています。 ネクストエンジンは13年の開発・運用を重ねて成長してきた一方でたくさんの課題も抱えており、その課題を解決するため日々改善活動を行っています。今回は監視の観点から弊社アプリケーションエンジニアとSREエンジニアの二名が現場から生の声をお届けします。 * どんな問題があり監視を行っているのか * どのような監視を行って改善しているのか * アプリケーションエンジニアとSREエンジニアでどう連携を行っているか 対象 * まだ監視していない人 * 監視しているけど、うまく運用できていない人 * 13年物のプロダクト開発・運用に興味がある人 Twitter: 日野陽平 (https://twitter.com/money166) 大嶋淳司 (https://twitter.com/atsusics)

Yappliのサービスの一部は独自フレームワークなPHPで実装されています。この独自フレームワークはトランザクションスクリプトかつinclude Orientedで、重複コードが多くテストコードも無いなど様々な課題を抱えていました。その結果、開発や運用の心理的な障壁となっており、不具合が発生しやすく保守性の低いシステムとなっていました。また、当システムに対する機能追加・改善要望も多数ありました。 そこで、サーバを立ち上げて行う自動テストや静的解析により、既存コードを修正せずに品質を担保し、 autoload化、ライブラリの導入、リファクタリングによる既存コードを修正する改善で、開発・運用効率を上げていきました。 本セッションではヤプリが取り組んできた改善を例として、独自フレームワークPHPアプリケーションを安全に確実に改善していく方法をご紹介します。また、各改善のタイミングや改善を続けるためのメンタル的なTIPSも併せてご紹介できればと思います。

私たちのサービスはローンチから20年を超え、現在も積極的に開発中です。幸いにも今まで多くの方に使われるサービスとなっています。しかし、これだけの年数を経て多くの機能を追加しているため、典型的な「レガシーシステム」となっているのが現状です。 もちろん、開発時にはさまざまな課題があり、完全に解消することは難しいです。それでも、大規模なサービスを維持していくためには開発を継続することが重要です。 本セッションでは、大規模なレガシーシステムを継続して開発していくために取っている戦略の中で、ミドルウェアのバージョンアップに関する戦略を中心にお話します。 ミドルウェアのバージョンアップは、通常の機能開発とは大きく異なります。たとえば、サービス提供を続ける限り避けて通れないものですが、新たな価値を発生する者ではありません。そのため小さな機能追加などで積極的にバージョンアップをすることは難しく、EOLに合わせると、PHPの場合は2年に1度のバージョンアップになります。 そして、広い範囲の既存コードに手を加える可能性があります。バージョンの間が開くと修正箇所も当然増えます。いわゆるレガシーシステムであれば、影響範囲はアプリケーションすべてといっても過言ではないですし。修正が重複する個所すらあるかもしれません。 この影響範囲の広さが、レガシーシステムのミドルウェアバージョンアップを難しいものにしています。 それを考えずに、通常の開発と同じようにミドルウェアのバージョンアップをすることは困難で、正面から挑むだけでは無限の時間とコストがかかります。 現実世界には時間、コストなど、さまざまな制約があります。これはビジネスでサービス提供をしている以上当然避けられず、その中で戦わなければいけません。 となると作り直すのも現実的ではないすし、だからといって場当たり的な対応だけでは、技術的負債を抱え込んで開発の継続が困難になるかもしれません。 広範囲で複雑な問題には、取捨選択が必要です。いまある複雑な問題は、今この場面で対応すべきことではないかもしれません。 このように、普通の機能開発とは異なる困難さ、複雑さをもっています。これに立ち向かうためには、戦略をもって挑まなければなりません。 本セッションは、ミドルウェアのバージョンアップ事例の紹介とそのプロジェクトで採用した戦略についてお話します。 事例紹介では、直近実施した2件のバージョンアップ(PHP,PostgreSQL)の事例を紹介します。その中では現実の制約に沿った形でプロジェクトを推進するためのゴールの設定、事前準備、実際の作業プロセスについてお話します。 そして紹介した事例をより一般化し、レガシーシステムの開発を継続していくための戦略を紹介します。

オブジェクト指向プログラミングがどういったもので、どういうときに役に立つのかについて解説します。 多くの初学者はプログラミングを始めて手続き型の記述に慣れた頃、オブジェクト指向プログラミングに出会います。 クラスやオブジェクトといった用語を学び、オブジェクト指向プログラミングの機能を実際に記述して体感します。 そして、混乱に陥ります。 なぜなら、オブジェクト指向プログラミングを活用することで何が嬉しいのか、機能を体験しただけでは理解できないからです。 道具を使いこなすには、それがなんであるかを学ぶと同時に、その目的を知らねばなりません。 目的を知らずに道具を扱えば、よく切れる包丁で紙を切るといったおかしな事態が起きてしまいます。 本トークでは、オブジェクト指向プログラミングがどういったもので何ができるかを解説するのと同時に、どうしてそれが必要なのかについてを解説します。 ※本トークがカバーする範囲はクラスによるカプセル化とサブタイプポリモーフィズムまでです ■トーク対象 - プログラミング初学者（条件分岐まで理解している） - オブジェクト指向プログラミングの使いどころが分からない方

ORM が高性能になり、SQL (クエリ) を意識の外に置くことも増えてきました おかげでより開発効率も向上し、スピーディ・高品質なコードが書ける率も上がっています しかし…アラートは突然やってきます 落ちるページ表示速度、上がる DB サーバー の Load Average そして大量のスロークエリ もちろん原因はこれだけではありませんが、僕らの日常では、1つのスロークエリが DB サーバーを停止させることも少なくありません SQL は書き方次第で簡単に障害に繋がります また、障害発生時、プログラムがどんな SQL を実行しているのか 実装した SQL は速いのか、遅いのか それがわからないと、障害解析で困る場面も多いです 障害などの緊急事態を回避する以前に、品質の観点でエンジニアには日常的に以下が求められると考えています。 - スローログ監視 - スロークエリ解消 - スロークエリ予防 本セッションは、実例をベースに上記を説明しつつ「現場で使えるスロークエリの倒し方」を持ち帰っていただき、クエリ (SQL) チューニングへの敷居を低くすることが目的です SQL 見よう！ 障害の完全な予測は難しいです だからこそ打てる手は多く持ち、できれば早めに打っておきたい その手の1つとして、実際に行っているスロークエリの見方・倒し方・予防方法をお話しします SQL はチューニングすることで品質の向上が可能です PHPer であっても、SQL を日頃からチューニングしていきましょう！ ## スロークエリの見える化 開発当初は快適に動いていても、スロークエリは突然やってきます では見える化はどうしたら良いのか、を - プログラムレベル - MySQL サーバーのログ（スローログ） の 2 パターンで解説します ## SQL の分析 スロークエリが見つかった場合に実行する主な内容を、項目別に解説します 普段の実装時・レビュー時にも実行することでパフォーマンス劣化の予防もできます - EXPLAIN - インデックス - インデックス管理 ## 改善対応の流れ まずいスロークエリを見つけ、解決していくまでの流れを、2つの事例から解説します - SQL そのものに問題がある場合 - 複合インデックスで解消できる場合 ## スロークエリ予防 普段から予防のために実践していることをお話します - コード・設計・企画レビュー - 勉強会 - ペアプロ

みなさんの運用しているアプリケーションはモニタリング（監視）されていますか？ サイボウズのGaroonではサーバーレベルのモニタリングはされていましたが、アプリケーションレベルのモニタリングは今まで十分には行われていませんでした。 そのため、お客様からのお問い合わせがあって初めて障害に気がつくことが多くなっていました。 また、発生している問題の重大さもうまく把握できていないため、どれくらい優先して障害対応をすべきなのか、本当に障害として対応するべきなのかといったコミュニケーションを、SRE・ビジネスメンバー・サポートメンバーなどの社内の他のメンバーとうまく取れていない、という問題もありました。 そういった状況から脱却すべく、昨年からアクセスログの集計やメトリクスの収集を行い、必要に応じてアラートを飛ばすモニタリングの仕組みを導入しました。 このセッションでは、モニタリングをどのように導入したのか、モニタリングで得られた数値とお客様に与えている不便さをどう結びつけたか、モニタリングによって開発チームと社内の他のメンバーとのコミュニケーションにどのような変化があったか、いまモニタリングで苦労していることをお話しします。

皆さん、PHPのDockerイメージは使ってますか？ 開発手法は人や組織によって様々ですが、ローカルでの環境構築や本番環境へのデプロイにDockerイメージを使うことは一般化しつつあります。ですが、普段使っているイメージの中身をきちんと把握していると言い切れる人は意外といないかもしれません。そこで今回は「PHPのDockerイメージの深堀り」をテーマにお話をしたいと考えました。 ・「何のために使ってるか分かってないけど、依存関係の都合でとりあえず入れてる。」 ・「イメージのサイズが大きくなってきたから軽量化をしたいけど、パッケージの役割がよく分からなくて触りにくい。」 このセッションでは、自信と確信をもってDockerイメージの運用をしたい方へ向けた掘り下げを話していきたいと思います。細かい構成は決まっていませんが、軽量化の話を交えた構成にするつもりです。 ※特定のフレームワークを深堀りする話はしませんが、リアルなDockerイメージを作るためにLaravelやCakePHPを使用する可能性はあります。

トーク概要 PHPそのものにバグがあるということがあります。仕様が変更されたために起こったバグだったり、PHPほどの歴史があるオープンソースソフトウェアだと皆に知られないまま十何年も潜ってしまったバグもあったりしたりします。 バグ報告を行おうとすると、PHPの側がおかしいのか、自分のPHPコードがおかしいのかで切り分けないといけませんし、仮にPHPそのもののバグだとすると、PHPのソースコードの莫大さと、PHPや使用しているライブラリの歴史の厚み、マニュアルにない仕様の変更、頻繁かつ大規模なリファクタリングなどが壁になりがちで意外と大変です。 私が間違っているのか、PHPが間違っているのか。大体は前者です（そして、そうあってほしいのです）が、後者だったときの切り分けの仕方を考えてみませんか。 トーク対象 PHPのバグを見つけてみたい人や、PHPのみならず規模が大きいソフトウェアのバグとどう見つければいいかの参考になれれば嬉しいです。

新規のプロジェクトが始動して開発を始めるとなったら、まず何を行うでしょうか？ GitHubにリポジトリを用意して、Laravelの環境を用意して、すぐに各チケットの本開発に入るのでしょうか？ 新規プロジェクトは最初は純粋無垢の綺麗な状態ですが、雑に開発を始めてしまうと、ある瞬間に何かしらのやばい匂いが漂っていることに気づくことがあります。 スピードだけでなく開発のしやすさなども考慮しつつ、レガシープロジェクトにならないように意気揚々と始めたにも関わらず、なんかおかしいぞ？となる瞬間があります。 そこで、本セッションでは、新規プロジェクトにおいて、少しでも長いスパンで本開発をスムーズに進めるためにまず最初にやるべきことを紹介します。 特に、以下のような内容を話します。 ・コーディング規約チェック機構、静的解析、テストなどの用意 ・CI/CD ・Xdebug ・サンプル構築 ・チーム内コミュニケーション ・READMEやドキュメントの整備

近年、PHP コミュニティでも DDD が大きく脚光を浴びるようになりました。その考え方に触れることで設計手法や実装パターンに興味を持つようになった人も多いでしょう。 DDD に限らず、多くの書籍では様々なパターンが紹介されています。 こうしたパターンは有用なのですが、特に設計パターンにおいては性質上、抽象的な内容となり、それ自体は理解できても自分が日頃おこなっているアプリケーション開発ではどのように適用すれば良いかがイメージできないことがあります。 本セッションでは、あるドメインを題材にして、モデリングから設計、そして最終的に PHP で実装するという一連の流れをご紹介することで、ドメインを中心に開発するイメージを持っていただければと考えています。 実際は、ドメインをモデリングして PHP コードに落とし込むという行為は誰もが日常的に行っているものです。 その手法や視点が異なるだけとも言えるので、こうしたやり方もあるのだなという気軽な気持ちでご参加ください。

速いは正義、アプリケーションは速くあるべきです。 なんとなくやってるパフォーマンスチューニング、 チューニングを行うとPHPWebアプリケーションはなぜ速くなるのでしょうか。 意識的に作った遅いアプリケーションを使い OS、Webサーバー、PHP、RDBMSが遅い原因を知ることで、 遅くなった原因を一つ一つ分解して解説します。 パフォーマンスチューニングを行うに当たり必要な基礎理論を見直し、 なぜ遅いのかを知り、どうすれば速くなるのかを知ることで、 具体的なチューニングをなんとなくではなく、意志を持って選択出来るようにしましょう。 ■想定する聴講者 　- PHPWebアプリケーションのパフォーマンスに興味がある方 　- PHPのインフラを整備するエンジニア 　- なんとなくオススメのチューニング設定を貼り付けてる方 ■お話しないこと 　- パフォーマンス以外の話 　- アプリケーションコードによる改善 　- 劇的なパフォーマンス改善策

みなさんのチームでは日頃からコードレビューはされてますか？ 弊社でもリリースするコードに対して2人以上のコードレビューを必須にしたりと活発に取り組んでいます。 コードレビューには以下のような効果が期待できます 　・ソフトウェア品質の向上とアーキテクチャの統一 　・スキルの向上とナレッジの共有 いかに効果的にコードレビューを実施するかによって、チームの成熟度やプロダクトの品質に影響すると言っても過言では無いかもしれませんね。 しかし、正直なところ自分はコードレビューに苦手意識がありました。 一度のレビューに時間がかかったり、他のメンバーと比較してコードの改善提案をする回数が少ないのです。。。 そんな私が苦手意識のあるコードレビューをどの様に克服していくのか、体験談を踏まえてお話しできればと思います！（現在進行形） ▼お話しする内容 ・コードレビューの概要 ・弊社で取り組んでいるコードレビューの仕組み ・良いコードレビューするためのTips ・苦手意識のあるコードレビューをどのように克服していったのか（体験談） ・チームの過去1年分のコードレビューを分析してみる ・ペアプロならぬペアレビューをしてみる ・とにかくレビューしてみる などなど

SPA開発においてこんな課題ありませんか？ ・フロントエンドとバックエンドで型の整合性を担保したい。 ・SPAのディレクトリ構成ってベストプラクティスを見つけるのが難しい。 そんな人の為に、ディレクトリ構成や静的解析、型チェックで工夫している点をお話します。 具体的には静的解析ではphpcs、phpmd、eslint、stylelintなどを導入。APIのリクエストレスポンスでは、厳密な型チェックを行っています。

バージョン 8 にしてとうとう僕らの PHP にも JIT がやってきました！ が、PHP 8 の JIT は生まれたてで、同じ 8 でも JavaScript の V8 にはまだまだ速度的な面で追いつかない部分があります。 PHP と JavaScript のそれぞれについて、おおむね同等の処理を行うマイクロベンチマークのコードを用い、プロファイルをとりながらああだこうだ言いつつ速さの特性差や PHP の現状の限界、得意な点や不得意な点を探っていきます。 ■ 想定する聴講者 ・典型的な Web アプリケーションは主に I/O バウンドとかそういう現実の話は脇に置いておいて、PHP スクリプトの性能や測定方法が気になる人 ・今後の PHP の性能の伸びしろに思いを馳せたい人 ・しょうもないマイクロベンチマークが好きな人 ■ お話しないこと ・明日から業務に使える役立つ知識

社内勉強会を開催したい！でも運営を続けられるか不安... という方は多いのではないでしょうか？ コロナ以前の2019年から毎月開催しているコミュニティイベント "PHP TechCafe" は、Web や PHP に関わる IT エンジニアがスキルアップを目指して意見交換を行うことを目的としています。 私が運営に参加することを決めたときには、自身の学習モチベーション向上にもつながるだろうと、軽い気持ちで活動を始めました。 しかし、実際に運営を続けると、コンテンツのネタ切れや集客不足、自身の知識の限界による不安など、想像以上に問題点が多く、今も試行錯誤している状態です。 本セッションでは、これから社内で技術系勉強会を開いて盛り上げようとしている方を応援すべく、月一でPHPのイベントを開催するにあたって心がけている、勉強会を継続させるためのポイントやノウハウ、今後考えていくべき課題を紹介します。

Laravel7系から導入されたBlade Componentsと近年注目されているUtility FirstをコンセプトとしたTailwindCSSを利用して再利用性の高いコンポーネントの作り方を紹介します。 Blade ComponentsはVue.jsのSFC（Single File Component）のような使い方をBladeで実装できる機能です。 対象者はこれからLaravelを触る方やまだLaravel7系以前の@extend,@yield,@sectionを利用してレイアウトを作ってる方となります。

Closing greeting for Day1

The opening ceremony for Day2

- PHPerと言っていますがPHP関係なくサーバサイドアプリケーションエンジニア向けの内容です。 - MySQLとインデックスの話をベースに、仕組みよりは「理屈は置いておいてやり方」にフォーカスします。 - 参考: 仕組みの話 ⇒ MySQLとインデックスと私 - Speaker Deck https://speakerdeck.com/yoku0825/mysqltoindetukusutosi - スローログを出して、集計して、EXPLAINにかけて、インデックスを足す、のプラクティスを紹介します。 - これの続きかもしれません: 片手間MySQLチューニング戦略 https://www.slideshare.net/yoku0825/mysql-80571224 目標は、「クエリーレビューで怪しげなSQLを先回りして直す」！

近年、PHPの機能強化により型宣言だけで安全に書ける範囲が広まっています。 その一方でPHPStanやPsalmといった静的解析ツールはPHPでは表現できない強力な型を提供することでコード品質向上の価値を高めることが可能です。PhpStormはPHPプログラマに静的型の恩恵をもたらした一方、先述のツールと比べサポートする型について見劣りする点がありました。 ところが最近リリースされた待望の新バージョンである2021.2はこれまで静的解析ツールの専売特許だった型のいくつかがサポートされるようになり、型検査だけでなく入力補完などの恩恵を受けられるようになりました。そこで追加された型のひとつがジェネリクス（総称型）です。 本発表では、PHPの型についての基礎知識（[今日からできる安心型付け入門](https://tadsan.fanbox.cc/posts/2558149)）があることを前提として、[PHPにジェネリクスは入るのか？](https://zenn.dev/tadsan/scraps/b943c7f29f6dea)の内容を軸に、PHPの型宣言では現時点で賄えない部分、特に配列の型およびジェネリクスの概念、class-string型の概念、そしてジェネリクスを実際に活用するためのテクニックを説明します。

会員登録を求めるWebアプリでの初期アバター、ECサイトに商品を登録したときの初期画像。 こういった画像は固定のものを1つ用意しておいても良いのですが、Webアプリケーションの実行時つまりHTTPリクエストを受けたタイミング等で生成することができれば、そのWebアプリはもっとリッチなものになることでしょう。 SVG画像はXMLつまりテキストで書かれるものであるため、生成のために必要な特殊技術は少なく、また現代ではほとんどのブラウザで表示可能であることから、アプリケーション実行時の生成に大変適しています。 このセッションでは、PHPでSVG画像を生成する手法について解説します。以下のものの一部または全部を含む予定です。 - SVG画像の基礎知識 - SVG画像の生成手法その１：文字列処理 - SVG画像の生成手法その２：DOMツリーの処理 - SVG画像生成のパフォーマンス - ラスタライズ（PNG画像化等）の方法や注意点 - 生成する画像にランダム要素を入れる（色、形、etc...）

Have you still not upgraded to PHP 8? We will learn all the great features PHP 8 has to offer. Let's dive into all the details on PHP 8 and 8.1 features. We will also talk about what is deprecated so you can upgrade your code. Let us upgrade to the best version of PHP yet.

PHP8利用していますか？ フォトウエディングサービスのアプリケーションをPHP7.2から8.0.2に上げた時の奮闘記を話します。 アプリケーションの言語バージョンアップって勇気入りますよね。 サービス運用・開発エンジニアとして担当サービスのアプリケーションは常に最新言語バージョンにしていきたい！と思いますが、 案件開発の優先度でどうしてもバージョンアップには手が付かない事もあると思います。 PHPバージョンアップを遂行し、開発者だけじゃない事業に関わるチーム全員が得られた素敵な話をしたいと思います。 * バージョンアップする意味を考える（メリット・タイミング・モチベーション） * 優先度の持ち方。事業担当者理解への手配。 * 準備、実対応、リリースの話 * 効果とその後の開発記 【トーク対象】 ・webサービス運用エンジニアの方 ・アプリケーションのPHPバージョンを上げたいと思っている方 【その他】 大きなカンファレンスなどに登壇するのは初めてです。

At the recent years, I used a lot PHP to develop my web crawlers and save my life to make some duplicated works automated. I also research them and write a book (it's written in Mandarin). And the book link is available here: https://www.books.com.tw/products/0010882656 This book tile translates to English is: PHP Web Crawler Development:From beginner to advanced web crawler technique guides. In this session, I will present following topics: - The motivation about writing this book. - The guide about web crawler developments and sections introduction - Basic HTTP fundamentals and the tips for inspect HTTP packets and requests via web browser. - The PHP web crawler environment building demonstration. - Using the advanced web crawling techniques. Such as headless Chrome web browser. - Some Labs and live demonstration about developing crawler. - The feedback and experiences about publishing this book. - Extended references and other advanced crawling tips that not included in books. - Inspecting HTTP packets and requests via non-web browser. - Advanced extract/decode CAPTCHA codes.

新しいサービスを始めるにあたって、機能やアイデアを検証する『プロトタイピング』。みなさんは、どのようにしてプロトタイプを開発しているでしょうか？この度、はじめてプロトタイピングの開発に携わらさせてもらう機会をいただき、さまざまな学びや気づきがありました。 今回は協働開発した、たなかひさてるさんと共に、携わったプロトタイプ開発の体験をベースとして、クリーンアーキテクチャを考慮して実践した手順や考えをお話しいたします。 以下の内容をお話しする予定です。 - 開発環境・ツールの選定や構築 - 開発の過程 - クリーンアーキテクチャの導入 - テスト、 レビュー

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デフォルトの機能で手が届かなかった点を改善する方法(実際にセッション中に拡張を作ります!) について話します

小学校でプログラミング教育が必修化される中、「Scrach」のような ビジュアルプログラミングは注目されています そんな中、LOVOT（https://groove-x.com/）と呼ばれる 『役に立たない、でも愛着がある” 新しい家庭用ロボット』がコンセプトの ロボットに、「LOVOT STUDY ビジュアルプログラミング」という ブラウザを用いてビジュアルプログラミングし、LOVOTを操る仕組みが提供されています "ビジュアルプログラミング"でできることは、PHPでもできる！ことを 実証するために、 本来、ビジュアルプログラミングで操作するLOVOTを 直接PHPのプログラムから操作してみました(非公式) まずは、ビジュアルプログラミングを解析する過程、そして 解析内容を元にPHP（Ampを用いて）で再実装する過程をお話しします Let's PHP programming！

1

In recent years, more and more PHP developers are interested in asynchronous frameworks, like Swoole. However, Swoole brings to PHP not just asynchronous programming; there are a few mind-blowing features in Swoole that many developers are not yet aware of. In this talk, I will discuss how to use Swoole to build an application server to serve web requests, to handle cron jobs, and to process job queues without relying on any third-party applications or software.

普段開発しているコードベースでは PHPStan で静的解析をしているものの Lev.1 に留まっており、レベル上げをしようとすると大量のファイルがあって膨大な数のエラーが出てしまい手付かずの状態でした。静的解析が弱い分、ユニットテストや手動テストを主にして検証を行っていますが、手動テストの終盤で型エラーが起きてやり直しになるなど、非効率なことが起きていました。 その状況を改善すべく、モジュール毎に静的解析レベルを設定することで独立したメンテナンスを可能にし、比較的新しいモジュールからレベル上げをしていきました。 本セッションではその取り組みやつまずいたポイント等について紹介し、これから静的解析を強化していく方の参考になれば幸いです。 ・解析対象と実行方法の整理 ・PHPStan, larastan バージョンアップ ・PHPStan, Laravel IDE Helper のコードリーディング、修正 ・静的解析レベル上げ ・レベルを上げてからのコードの書き味

私はこの数ヶ月、趣味プロジェクトとして、1990年代にアーケードゲームやハイエンドパソコンで輝きを放ったYAMAHAのFM音源チップ、YM2151を制御するためのハードウェアとソフトウェアの開発をしています。 こう言うと難しく聞こえるかもしれませんが、実はハードウェアの世界にも私たちソフトウェアエンジニアが「API」や「プロトコル」と呼びそうな決まりがあり、その決まりに従って音源チップに命令を与えることで音を鳴らすことができるのです。 このトークでは私が開発しているYM2151制御ハードウェア・ソフトウェアを題材に、コンピュータシステムの周辺ハードウェアがどの様に制御されるか、そしてその制御をソフトウェア的にどの様にするかを解説します。もちろん制御ソフトウェアはPHPで書いていますのでPHPerのみなさんであればスッと読めると思います。 このトークを通じてコンピュータシステムの動作について興味を持っていただく方が増えることを期待しています！

株式会社M&AクラウドではPHP、LaravelとAWSを使ってM&Aのマッチングプラットフォーム「M&Aクラウド」を開発しています。サービスリリースから徐々にアプリケーションとして成長していく過程でどの様な技術を組み合わせて課題を解決してきたかを、短い時間ですがご紹介させていただきます。

ランサーズは10年以上利用されているクラウドソーシングサービスになります。 PHP7.3 + CakePHP2.10 までバージョンアップが完了し、引き続き、CakePHP2→CakePHP4へのジャンプアップを実践中です。 本LTではその内容についてお話いたします。

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開発チームの経験を是非お聞きください。

2020年10月24日に、Composer 2.0がリリースされました。 Composer初のメジャーバージョンアップデートですが、どんな新機能が増えたのでしょうか？ そこでComposer2.0で新しく実装された機能について、時間が許す限りご紹介・解説いたします。 時間の都合で全ての機能について触れられない可能性がございますが、以下の機能について触れる予定です。 * パフォーマンス向上 * アーキテクチャの変更による依存関係の更新プロセスの改善 * ランタイムの新機能 * 依存関係のエラーレポートの改善 * パッケージのバージョンの部分的な更新 * その他便利なオプションなど

1

PHP 8.1 brings Enums, one of the most requested features in PHP. Enumerations allow creating strict and type-safe structures for fixed values. An Enum structure can hold a number of values that can also be backed with integer or string values. In this comprehensive session, we will discover what Enums are, why they are useful, how to apply them on PHP applications. Audience This session is for those who are familiar with modern PHP practices such as Object Oriented Programming, principles such as Liskov Substitution principle; familiarity with such concepts can help a lot. What you will learn - What are Enums. - Why Enums are useful. - How to use Enums - Migrating from magic constants/values to Enums. - Backed Enums and storing/fetching Enum values with a database. - Using Enums in a Drupal context. - Caveats when using Enums. ## Author Ayesh Karunaratne is the author of PHP.Watch (https://php.watch), where he provides in-depth articles and documents on PHP and latest changes to the language. - PHP 8.0: https://php.watch/versions/8.0 - PHP 8.1: https://php.watch/versions/8.1 - Enums: https://php.watch/versions/8.1/enums

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

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

OpenAPIにはリクエストやレスポンスだけでなく、求める型や正規表現も記述して利用することができます。コードの自動生成についても盛んに行われていることもあり、最近のプロジェクトでは採用されることが多いのではないでしょうか？ とはいえ、OpenAPIを自分たちで書かなければいけない場合はめんどくさいと思います。 そこで、このセッションではLaravelからOpenAPI仕様書を自動生成する方法を紹介します。 また、生成したOpenAPI仕様書を閲覧用として利用するだけではなく、LaravelのE2Eテストやバリデーションに生かす方法についても話します。 このセッションで話す内容 - LaravelでOpenAPIを半自動生成する - LaravelのE2EテストのアサーションをOpenAPIに沿った形で行う - LaravelのFormRequestにOpenAPIを使う - (予定)今回の内容を業務で利用してみた感想 想定するレベル感・技術的な要素 - OpenAPIやSwaggerを知っている - Laravelを使ったことがある

非同期処理、IO多重化、平行、並列...これらの言葉は、同期処理がメインのPHPウェブアプリケーション開発者にとっては理解が難しく、近寄りがたい雰囲気を持っています。しかし、コンピューターの資源を余すこと無く使って、資源利用効率の高いアプリケーションへの要望は高まってくるばかりです。近年のPHP界隈においても Swoole , Amp, ReactPHP, RoadRunner 等、非同期処理を行うためのツール、フレームワークがたくさん生まれています。また、PHP 8.1 においては軽量スレッドと呼ばれる Fiber も実装されます。 本トークでは、仕事で同期処理ばかり書いているエンジニアが、Echoサーバーのような簡単なサンプルプログラムの作成を通して、非同期処理を理解するための第一歩を踏み出す方法を紹介します。 このトークでお話すること - 非同期処理とはなんなのか - Swoole, Amp, ReactPHP は何を目指しているのか - Generator とは何か - Fiber で何が出来るようになるのか

速度は求めたい。ユーザのためである。 設計方針は崩したくない。開発者のためである。 「速度も求めつつ、既存の設計方針を守り、ユーザに価値を届ける。そんな方法が欲しい。」 こちらはそんな思いから生まれたテクニックを紹介するセッションです。 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)に陥らないようにするテクニックである。

Xdebugを活用していますか？ステップ実行の機能については、利用経験者も多いかと思います。 公式サイトを開き、トップページを見ると「Step Debugging」「Improvements to PHP's error reporting」「Tracing」「Profiling」「Code Coverage Analysis」と主要機能が列挙されています！ 「知らなくて使っていない」のと「使っていはいないが知っている！」では、大きく違います。 まだ試してみたことが機能がありますか？ 本セッションでは、これらの機能を紹介しながら「実際にどう使うものなのかな？」を共有していきます！

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 を使ってきて得られたノウハウを交えてお話できればと思います。

1

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

シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。

Input-Output (otherwise known as I/O) is commonplace in daily programming but is quite arduous. PHP, though robust, offers sequential, blocking I/O solutions that require one to await completion of one task before starting another. Blocking I/O is somewhat inefficient, especially in modern applications that are computationally intensive in nature. Enter ReactPHP, a PHP-userland affable suite of technologies - complete with an event loop, a NodeJS-akin server, and Promises. ReactPHP offers the advantages of non-blocking I/O - present in runtimes like Node.JS - to the PHP developers who use it. It provides, via the Reactor pattern, a means of efficiently running I/O operations in an event-driven domain. My talk titled Asynchronous Programming in PHP with ReactPHP is an attempt to distill asynchronous non-blocking I/O concepts for a PHP audience. The first part is an introduction to non-blocking I/O and describes the advantages of adopting event-driven approaches. The second part is a description of streams, promises, and the event loop. Lastly, the third and fourth parts - the respective focus points being usage and application of ReactPHP - conclude the session.

昨今のE2Eレベルのテストではその自動化テストのツールとしてSeleniumに代表されるようなブラウザ操作ライブラリが使われます。 Seleniumなどを使ったことがある人は多いでしょう？ではその裏側で行われている仕様については知ってますでしょうか？ 本トークでは、PHPで実際にSeleniumのようにブラウザを動かすツールを自作するプロセスでそれらの仕様を理解する場を提供します。本トークで得られることは以下です。 * ブラウザ操作するために必要なWebDriver * WebDriverについてのW3C勧告の標準化仕様 * WebDriver Wire ProtocolというInterface仕様 * PHPでWebDriverとコミュニケーションをしブラウザを動かす方法 本トークを経て、WebDriverについての理解が深まることで、ブラウザ操作の自動化についての技術的理解が一段深まるお得な4分間にいたします。

In this presentation, we will show how to use Elasticsearch with PHP. We will give a short introduction to Elasticsearch showing how PHP developers can benefit from its usage. We will present how to connect to Elasticsearch, how to index data, how to search and aggregate information. We will also present some advanced features, such as fuzzy search, highlighting and the recent schema on read available from Elasticsearch 7.12.

PHPといえば、Web開発。 Web開発と切っては切り離せないのが「データベース」と「SQL」です。 このトークは、オライリー・ジャパン出版の名著「SQLアンチパターン」で紹介されている25のアンチパターンを「超特急」で学ぶものです。 わずか4分のLTで、25個のアンチパターンをおさらいします。 東京2020オリンピックのピクトグラムパフォーマンスのようなスピード感のある超特急LTをお楽しみください。 大事なところだけをギュッとして、明日からすぐ使える知識としてお届けできたら幸いです。

PHP-FPM（FastCGI Process Manager）の設定項目を「なんとなく」「デフォルトのまま」にしていませんか？ 不適切な設定は充分なパフォーマンスが発揮できないばかりか、障害の原因にもなりかねません。 本発表では PHP-FPM の子プロセス制御方法と設定項目の意味、適切な設定値の判断方法について説明します。

2021年8月に開催された「ISUCON11予選」に参加してきました。 GopherやRubyistが巣食う予選で、PHPerはどれだけ成績を残せたのでしょうか...！ 本トークでは、予選に参加する過程で生まれたエピソードや成果をご紹介します。 例えば、以下のような話題を扱う予定です。 * 予習って何をやった？ * 過去問って docker-compose でPHP参考実装が動かないじゃん！ぷんぷん！！！ * 過去問ってどんなフレームワークで書かれてるのか調べてみました！

スタッフに興味あるけど「スタッフってつよつよエンジニアばかりなんじゃないの？」とか「自分なんかにできるのか？」なんて不安を感じて応募を躊躇ってしまっていませんか？ いつもお世話になるばかりだった私が、当日スタッフに応募しようと思った動機と、実際にやってみてどうだったかという話をしたいと思います。 そして「次回は応募してみようかな」と思った方が一人でもいたら嬉しいです。

皆さんリリースの頻度はどれくらいでしょうか? 毎日、毎週、もしかして毎秒だったりしますでしょうか。 一般的に我々開発者が顧客に望まれるプロダクトを作るためには高頻度のリリースは必要不可欠です。 しかし、それを実現するためには完全に作り込んだ機能が実現できてないといけないのでしょうか。 今回は未完成の機能をプロダクション環境に混ぜ込むための、フィーチャートグルの概念、効能をご紹介します。加えてlaravelに組み込んだ例もご紹介します。

みなさんのアプリケーションのデプロイは高速ですか？ 昨今のWebアプリケーション開発では、UIはVue.jsやReactなどを使ったSPAとして提供し、PHPはAPIとしてデータを提供してSPAと連携する構成がよく見られます。 ただ、この構成で長く提供されているWebアプリケーションであればあるほど、UIの変更や更新が頻繁に行われるSPAのコードの中身は複雑になり、ビルドが少なくない時間を取ってしまってデプロイフローの開始から完了までの時間が長くなってしまう問題が発生してきます。 今回は、そういった課題が発生したWebアプリケーションのデプロイを高速化するために、PHP側の改善はもちろんのこと、フロントエンド目線でnode_modules周りやフロントエンドビルドツールまで手を加えた際のTipsをお話できればと思います。 このトークをお聞きいただき、高速なデプロイを手に入れて、高い開発体験とWebアプリケーションを使ってくださるユーザーさんに対して価値提供の高速化を実現する一助になれば幸いです！ PHP Conferenceの参加は初で、大きいカンファレンスでの登壇経験は浅いので、なにとぞお手柔らかにお願いします！

開発したプロダクト、その価値を届けるにはいわゆるDeployを行わなければなりません。 このLTでは、デプロイ先の環境でアプリケーションがDocker上で稼働することを前提として、 デプロイ時に利用できる便利なCLIツールをいくつか紹介します。 現場によって様々な事情やユースケースがそれぞれあると予想されるので、「こういうときに使うのが適切」という観点での事例や見解を交えてお話しします。 プロダクトに関わる皆さんの今後の運用・成長に有益となる情報を提供できれば幸いです。 https://fortee.jp/phpcon-2021/proposal/e7f97e1f-dd7e-4b9e-9ff6-a314a09a6c3f

【トーク対象】 ・LaravelのSessionについて知りたい ・障害発生時の原因特定から対策までの流れが聞きたい 【分野】 運用、データベース 【トークの概要】 webアプリケーションでCookieを利用したSession管理を行うことが多いと思います。 最近のフレームワークはSessionをとても簡単に活用できるためその維持管理について特に考えないことが多いです。 Laravelで構築したwebアプリケーションで、急激な性能劣化が発生して原因の特定と対策をすぐに行わなければいけない状況が発生しました。結果的にLaravelのSession設定を変更することで劇的にパフォーマンスが改善しました。 本セッションでは、なぜSessionが原因で性能が劣化したのか、また改善した理由について、経緯を踏まえてお話します。PHP/Laravelでのセッションの大まかな仕組み、性能劣化の要因、対策方法について説明します。

PHPerKaigi2021でベストフィードバッカー賞をいただきました。 これは「フィードバックの数 x 愛」が1番だったという賞ということでした。 カンファレンス中に合計21個のフィードバックを送っていました。 正直見たセッション全てには送れていないです。 実際みんなあんまりフィードバック送ってないのかな？と思ったのでこのLTの時間を使って ・フィードバックって大事だよね ・フィードバック送ってみようかな？ って少しでも多くの人に思ってもらおうと思いプロポーザルを投げました。 大きなカンファレンスでプロポーザル採択による登壇はしたことがありません。 よろしくおねがいします！

The closing for PHP Conference 2021

The social event for PHP Conference Japan 2021 at Zoom. You can join from: https://phpcon.connpass.com/event/223622/