PHPから派生し独自進化を遂げたHackを使ったアプリケーション開発では、
PHPと異なり、静的型付け言語のような堅実なアプリケーション開発をサポートする強力な機能が多く用意されています。
本セッションではそれらを使い、アプリケーションアーキテクチャ設計と、
Hackならではの実装コードに落とし込んでいくヒントを紹介します。

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

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

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

おしながき

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

アプリケーションのモニタリングしていますか？
デプロイした後のパフォーマンスチェックしてますか？
障害が起きてから監視ツールを眺めていませんか？

ライセンス形態が大きく変わり、監視プラットフォームとして使いやすくなったNewRelicを利用して
NewRelicはAPMの印象が非常に強いですが多くのソリューションが存在します。
それらを少しずつ使って自分達のオブザーバビリティプラットフォームを作り、プロアクティブにモニタリングしていきましょう。
APMに始まりNewRelic logsによるlog収集、Browserによるフロントエンドパフォーマンス監視、InfrastructureによるAWS監視、Syntheticsによる一歩進んだ外形監視。
そしてそれらの監視をダッシュボードにまとめていく、といったところまでをお伝えします。

概要

「PHPで何かを作ろう」と思った時に「今風のコードを書くのに必要なもの」を考えてみました。
新しいプロジェクトをスタートする時に、「こういうのがあったら良いのでは」という案を
みなさんと共有して、知見を育みたいです。

過去に個人ブログにも投稿した内容をベースに、「狙い」や「考えたこと」を紹介します。
PHPお手軽スタートキットを作った - 大好き！にちようび

イントロ

人は、熱しやすく冷めやすい生き物です。
例えば、あなたが「あ！ちょっとこういうライブラリを作ってみよう！！」と思ったとします。
その時に、ゼロから「必要なもの」を考えますか？
「まずはphpunit.xmlを用意して、あと静的解析も入れたい。PHPStanのルールってどうやって書くんだっけ？CIも入れなきゃ・・あ〜GitHub actionsのworkflowの書き方がさぁ・・・」
そんな事に煩わされている間に、どんどんと「腰が重く」なり、「着手が遅れ」、そして「熱が冷め」てしまう。

そんな経験はありませんか？
私は、過去に何度も「README.mdだけコミットしてある空レポジトリ」を消したことがあります。

やったこと

この「腰の重さ」を支えて、「浮かんだアイディアを試すためのコードを書き始める」までを軽減したいと思ったのです。
そこで、「このくらいの要素が揃っていれば、気持ちよくPHPアプリケーションの開発をスタートできるだろう」という、
「ぼくのかんがえた さいきょうの いまっぽい PHPのツールたち」を揃えてみることにしました。

お話したいこと

まずは、「PHPアプリケーションのボイラープレート」に含めた内容を紹介します。
この内容をモチーフにして、「今日におけるPHPの開発体験を高く保つためには」というテーマに触れられたらと思います。

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

■ 想定する聴講者

• PHP スクリプトの行レベル / VM 命令レベルでの性能や測定方法が気になる人
• 今後の PHP の性能の伸びしろに思いを馳せたい人
• しょうもないマイクロベンチマークが好きな人

■ お話しないこと

• 明日から業務に使える役立つ知識

「重い処理を早くしたい」といえば、処理の非同期化です。
「PHPで非同期」というと、「Swooleだ」「pcntlを使って」といった声が聞こえて来そうです。
あるいは、(HTTP)リクエストについてならば、「guzzleのasyncで」「curl_multiで」と耳にします。

さて、「MySQL 改良版拡張モジュール MySQLi」を皆さんは活用できていますか？
昨今の一般的なPHP環境であれば、こいつを使えば「重いSQL処理をMySQLにパラレルで投げておく」が可能になるわけです！！

本セッションでは、今一度、改めて「MySQLiを使って非同期処理を行うには」という方法について学んでみたいと思います。
(そんなに高度ではない内容です)

想定する聴講者

• あんまり mysqli::pollやmysqli::reap_async_query という文字列にピンとこない方
• 「何が何でもレイテンシを下げたいんだ、しかし必要なSELECTが多すぎて・・・」と悩んだ事がある方

おしながき(仮)

• PHPで書いたコードでの「非同期処理」の制御の仕方
• 「MYSQLI_ASYNC」モードを指定した時の動作
• 実用性のあるコードで利用可能にする

Composer の普及により、PHP における Web アプリケーション開発において外部ライブラリやフレームワークを活用にするのは一般的になりました。みなさんもアプリケーションで要求される機能要件、非機能要件の観点からライブラリを選定して利用しているでしょう。

今抱える課題を解決するため、欲しい機能を実装するために導入したライブラリですが、アプリケーションに組み込むということは、これからアプリケーションが動き続ける長い道のりを共に過ごすということになります。

導入した当初はその時点における安定したバージョンや最新バージョンであったとしても、時間の経過と共にライブラリはバージョンアップを続けていきます。それに逐次追随できれば良いのですが、いつもそれが簡単にできるわけではありません。特にメジャーバージョンアップにより、後方互換性を失う変更が入った際は容易ではありません。そのライブラリを利用している箇所全てが影響を受けるので、単に composer update すれば済むという話ではありません。

このようにライブラリの導入は容易ですが、その後の長い運用を想定してアプリケーションにどのように組み込むかという視点が必要となります。

本セッションでは、下記のようなトピックを交えて、アプリケーションにおけるライブラリの活用戦略を考えていきます。

• ライブラリへの依存
• PSR に準拠したライブラリなら良いのか？
• 要求をインターフェイスにする
• フルスタックフレームワークとオリジナルフレームワーク

速いは正義、アプリケーションは速くあるべきです。

PHPWebアプリケーションを構成する要素として、
パフォーマンスを向上させるポイントはどこにあるのでしょうか。

今回はPHPWebアプリケーションを速くするポイントを
PHPに限らず幅広い視点で見直してみようと思います。

OS、Webサーバー、PHP、RDBMS等の見直すべき要素に関して触れ、
愚直に改善を行うべき場所を再考し、
堅実にパフォーマンスを改善する方法をお話しようと思います。

■想定する聴講者
　- PHPWebアプリケーションのパフォーマンスに興味がある方
　- PHPのインフラを整備するエンジニア

■お話しないこと
　- パフォーマンス以外の話
　- アプリケーションコードによる改善
　- 劇的なパフォーマンス改善策

ステートレスなHTTPをステートフルに変えてくれる仕組みがセッションです。ユーザのログイン、リダイレクト後のエラーメッセージの表示、CSRF対策等、現代のウェブアプリケーションで多用されているセッションですが、セッションがどのように動いているかと聞かれた時に正しく答えられますか？
初心者に近いPHPerがセッションを多用すると、中堅クラスのエンジニアから「セッションは危ないから多用しないように」とアドバイスされることも多いと思いますが、それは何故でしょうか？

本トークでは、ウェブアプリケーションにおけるセッションについて、その正体を分かりやすく解説します。また、セッションの正体を知ることで、ウェブアプリケーションのアーキテクチャーに対してセッションが及ぼす影響についても解説します。セッションにまつわるアレコレを解説することで、初心者とベテランエンジニアの間に存在する知識と経験の差を少しでも埋めることが狙いです。

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

• セッションの仕組み
• Laravelにおいて無意識に利用されているセッションの例
• Laravelが独自のセッション管理を行う理由
• セッションが本番アプリのアーキテクチャに与える影響

今でこそPHPはRubyと比較されることは少なくなりましたが、PHP5の時代はよくRubyもしくはRuby on Railsと比較され、そしてときにディスられもしました。

時は流れPHPはバージョン7を経てバージョン8へと進化し、Webアプリケーションフレームワークとして洗練されたLaravelも台頭してきました。今ではプログラミング言語人気ランキングでPHPはRubyより高い位置にランクインしています(*1)。

本発表は改めてPHPとRubyを比較することで見えてくる＜PHPらしさ＞に着目して、＜PHPの良さ＞の再発見をしたいと考えています。

本発表の想定オーディエンスは下記の通りです。
・Rubyに興味があるPHPer
・Rubyをちょっと書いたことのあるPHPer
・元・RubyistなPHPer
・元・PHPerなRubyist

*1 TIOBE Index https://www.tiobe.com/tiobe-index/

※発表者はPHPもRubyも好きなエンジニアです。発表の目的は、言語に優劣をつけることではなく、あくまでも言語比較・Webアプリケーションフレームワーク比較を通してPHPの良さを発見することを目的としています

PHPではIDEとして普及しているPhpStormのほか、静的解析ツールを活用することで実行なしでコードの問題点を検出できます。

さらには、Phan, PHPStan, Psalmなどの静的解析ツールが提供するタグや機能をPHPが本来持っている以上の能力を持った型を記述できます。
今回のトークではPHPが持つ基礎的な型と静的解析ツールが独自に提供する型、そして、これらだけでは解決できない型付けの問題についても紹介します。

みなさんは億単位のレコードが存在しているMySQLテーブルをみたことがありますでしょうか？
もし、そのうち大半のレコードが不具合によって生み出されたものだとしたら、きっとDELETE文を実行したくなると思います。
でも待ってください。ただDELTE文を実行しようとしても、トランザクションは非常に大きくなり、ディスクIOやテーブルロックなどが原因となって、性能問題が生じてしまうでしょう。
このセッションでは安全に億単位の不要レコードを削除する方法をお話しします。

弊サービスは今年で14年目となりました。
そんなサービスをずっと支えてきたオンプレのデータベースOracle、これをAWSのPostgreSQLに移行することになりました。
これは、弊社全体としてクラウド移行が推進されるなかでの、私たちチームのクラウド移行プロジェクトの第一弾です。
データベースはアプリケーションよりも寿命が長いと言いますが、積年のデータの詰まったデータベース移行はサービスの中心にあるためいきなりラスボス級の難易度です。
本セッションでは、オンプレのOracleからAWSのPostgreSQLへの移行に伴って行った意思決定や方針・やり方をご紹介します。

主に、以下の内容をお話します。
・弊サービスの構成と移行方針
・なぜラスボス級のDB移行を先に行うことを決めたのか
・移行に役立つAWSサービスのDMSとSCTの軽い紹介
・アプリケーション(PHP)の修正の方針
・移行に伴うあらゆる罠

以下の内容についてはお話しない予定です。
・AWSサービスの詳細な説明
・Oracleの詳細な説明
・PostgreSQLの詳細な説明

移行を検討している、移行の進め方が気になる、どんな罠があるのか知りたい、といった方々に聴いていただきたいと思っています。

最近ではフロントエンド側をJavaScript(typescript)を使用して開発するケースがかなり増えていると思います。
私もここ数年、いくつかのフロントエンドアプリを作ってきました。

しかし、フロントエンドの開発環境は、進化・変化が早くキャッチアップするのがなかなかに大変です。

このセッションでは、PHPer/Bakerの私が最近気に入っている、React/Next.jsなどを利用したSPAフロントエンドの開発環境、技術要素、開発方法などについて紹介します。

昨今インタラクティブなwebアプリケーションの需要が高まっています。

その需要を満たすため React, Vue.js, Angular 等の JavaScript Framework を使いこなす必要がありますが、フロントエンドの学習コストの問題でなかなか手をつけられない人も多いのではないかと私は推測しています。

Laravel Livewire はそういった問題を解決するために開発されたライブラリで、フロントエンドの多くの処理をサーバーサイドで記述することができます。
本セッションでは Laravel Livewire の紹介と、実際のライブコーディングをあわせてその便利さを体験してもらいます。

MAMPやvagrant、Dockerなど、PHPアプリケーションを開発・検証するWebサーバをつくるにはいろいろな方法があります。
いずれも便利なツールですが、"Symfony CLI"でも簡単に開発Webサーバをつくることができます。
Symfony CLIを使って、そこそこ快適な、壊しやすい開発Webサーバのつくり方をご紹介します。

エンジニア夫を見送る側、見送られる側、両方の経験をしてきました。
独り身の時には気軽に参加していた勉強会やカンファレンス。
パートナーができたら？子供ができたら？
いつまでも今までと同じように参加できると思っていたりしませんか？
長年イベント参加するには家族の理解を怠ってはいけません。
送り出す側の気持ちを伝えたいと共に、子育て真っ最中の方やこれから子育てする若い方々に、エールを送りたいと思います。

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

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

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

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