トーク

何度も遭遇する PHP の「Allowed memory size of ...」。しかし、結局解決方法がわからず、最後には「ini_set('memory_limit', -1)」でその場を凌ぐという苦い経験をした方も多いのではないでしょうか。
PHP ではガベージコレクションもそれなりに発達しており、メモリを気にしないで書けるから良いと思っている人も少なからずいらっしゃると思います。
しかし、裏を返すと、メモリについてあまり考える機会がないとも言えます。PHP7.4 から弱参照といった機能も入り、メモリ管理に少しずつ関心が寄せられてきているのではないかなと思います。
そこで本トークでは、PHP でどのようにすれば省エネにメモリを使えるか、書き方のヒントまで含めてお話できればと思います。

皆さんお世話になっているPHP、そのソースコードを読んでみませんか？

プログラミング言語のソースコードを読むのはハードルが高いと思われがちですが、方法さえ知っていれば意外と読めたりデバッグできたり簡単な改変もできちゃったりします。

本トークではphp-srcを読む上で必要なC言語の知識から、php-srcのコードの構成、ビルド・デバッグの方法などphp-srcの読み方をご紹介します。プログラミング言語のソースコードを読むのは夢ではありません。PHPの深淵の入り口に招待いたします。

PHP では言語に対する変更に対し必ず RFC (Request for Comments) 文章を作成し、投票で一定数以上の票を獲得する必要があります。
またその提案に対する議論は必ず Internals ML と呼ばれるメーリングリストにて英語で行う必要があります。

上記のようなハードルの高さからか、比較的 PHP の利用率が高い日本からの新機能の提案、実装の例は少ない印象ですが、実際にやってみるとどうなのでしょうか。

今回は RFC を作成、実装し、 PHP 8.2 で実装が決まった Random Extension 5.x を例に PHP への新機能追加・変更を行っていくまでの道のりについてお話できればと思います。

概要

私が Symfony フレームワークを使っているとき、たまに目にしていた Serializer （シリアライザー）という言葉。これはフレームワークの一部でもあり、独立したライブラリでもある「Symfony Serializer Component」がその実体です。

Serializer が「PHP オブジェクトと JSON や CSV などの各種フォーマットとの相互変換をするもの」というのは、すぐに理解できるのですが、その使い方や応用方法については、ドキュメントを眺めてもパッと理解できるものではありませんでした。

それもそのはずで、公式ドキュメント [1] には「Serialization is a complex topic （シリアライゼーションは複雑なトピックです）」と書かれています。複雑な処理に関してのライブラリなので、理解にもちょっと手間がかかるというところでしょうか。

PHP での開発現場では、オブジェクトから JSON や CSV に変換したり、その逆を行なったりすることも多いと思います。そのような基本的、かつ、少し面倒な処理は、信頼のおける Serializer ライブラリ [2] に任せ、自分の時間はその他の重要なビジネスロジックの設計や実装に使いたいと思いませんか？

このトークでは、その複雑な内容を紐解き、Serializer Component についての理解を深めることにチャレンジしてみようと思います。

対象者

• PHP オブジェクトから JSON や CSV を出力する処理を書いたことがある開発者（フレームワークは問いません）
• 既に Serializer をマスターしている方も、発表者が間違った解釈をしていないかどうか、チェックしてくださると助かります 🙂

参考リンク

1. 公式ドキュメント
2. Serializer Component は多くのプロジェクトで採用されている

資料

• 発表スライド
• サンプルコード

テスト書いてますか？
テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。

テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。
サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。

■ 概要
・なぜテストコードを書くのか
・レガシーコードとは、テストのないコード
・テストはコストが安いフィードバックループである

■ 実践編
・テストケースは日本語で書こう
・いろんな assertion を知ろう
・arrange / act / assertion のテストコード実装パターン
・set up / tear down を使って前処理/後処理をする
・dataProvider でテストをまとめる（ただし早すぎる抽象化に気をつけよう）

私はこの数ヶ月、趣味プロジェクトとして1980年代に栄華を誇った名作CPUであるZ80のハードウェアエミュレータを開発しています。
これはZ80で動作しているハードウェアからZ80を取り外して、代わりに自作のZ80ハードウェアエミュレータを取り付けて動作させるというもので、Raspberry Pi に自作のハードウェアを接続した形になっています。

PHP Conference Japan 2019で "「CPUとは何か」を PHPで考える" というタイトルで「プログラム実行環境としてのCPU」「エミュレート対象としてのCPU」「電気回路としてのCPU」という3つの立場から「CPUとは何か」について解説しました。
このトークではその続編として、Z80のハードウェアエミュレータの設計と実装を通してハードウェアエミュレータから見るとCPUはどう見えるかをお話します。

このトークを通じて、CPUに興味を持ち、CPUについて語る仲間が増えることを期待しています！

HTTPとPHPは切っても切れ離せない関係があります。

PHPもその周辺のミドルウェアもHTTPを正しく理解することで、さらにその力を発揮する事が出来ます。

そんなHTTPに関するRFCが2022年6月に新たに公開されました。

HTTPは実際にどのようなメッセージを送信、受信していてそのメッセージにはどのような意味が込められているのか、
PHPerにとって知っておくべきHTTP仕様をこのタイミングでRFC911*から振り返ってみましょう。

• 想定する聴講者
  • HTTP仕様について興味がある方
  • HTTP Messageの中身、やり取りについて知りたい方
  • HTTP header による挙動変化について知りたい方

年に1度(数年に一度？)巡ってくるPHPのバージョンアップという大仕事。

今回PHPのバージョンを8系にバージョンアップするための作業を実施したのですが、そのためにはまず依存ライブラリのバージョンアップと向き合う必要がありました。

小さくコツコツ手をつけておけばよかった・・・そんな気持ちと戦いながらもバージョンアップをなんとか完了させました。

1つ1つ丁寧に目の前の課題・問題点を洗い出し、対処していけば必ずバージョンアップを完遂できると思いますが、本トークではPHPバージョンアップのための依存ライブラリ更新とどのように付き合いながらPHPのバージョンアップしたか、PHPのバージョンアップ後の依存ライブラリ管理についてお伝えさせていただければと思っております。

今回参加されている皆様は、普段のお仕事でPHPでWebアプリケーションを書いている方が多いと思います。
しかし、どのような仕組みでサーバ内でPHPが動作してブラウザに返却されているか正確にイメージできている方はいますでしょうか？
この仕組みについて、実際のコードを交えながら時間の許す限り解説をしていきたいと思います。

日本でも大人気のウェブアプリケーションフレームワーク「Laravel」
ある程度のデータ量までは、割と速い速度で動いてくれる Laravel をあの手この手で低速化させてみようという試みです。どのようなコードが Laravel を低速化させるのかを学ぶことで、逆説的に Laravel の速度劣化を防ぐソースコードの考え方が身につきます。

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

• ミドルウェアによって Laravel を遅くする方法
• インフラ環境によって Laravel を遅くする方法
• ソースコードの書き方によって Laravel を遅くする方法
• 遅くしないで妥当な書き方をした Laravel の処理スピード計測

※こちらのトークは、リモート登壇になります。

想定課題

開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。
そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。
その際にこのようなことを言われがちではないでしょうか？

• 今動いているものを直す必要ある？
• 効果測定どうやんの？
• 費用対効果はどれくらい？

パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。

本セッションの目標

以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。

• State of DevOpsとは
• Four Keysとは
• 27のケイパビリティとは

ライセンスの都合でローカル環境での開発環境構築が不可能な、CMSに密結合したWebサービス。
CMSの仕様に引っ張られてトリッキーな実装がされることもしばしば…といった状況もありました。

そんなJava製CMSを利用して構築していたサイトを、2年間かけてPHP + Laravel にリプレイスしました。
ソースコード管理もGitで管理でき、EC2で動いていたサイトをDockerを用いてローカルでの開発も同時に実現しています！
ステージ環境やプロダクション環境はAWSサービスである、Fargate、Codeシリーズを活用でき、柔軟にスケーリングできるようになりました。
CMSに密結合していた部分もLaravelに変更することで、モダンなサイト開発体制に近づけることができました。

この発表では、10年以上運営されている大規模な求人サービス「はたらこねっと」でのリプレイスプロジェクトにて、工夫した点や苦労した点についてお話しします。画面は数百単位、PHPのコードだけで数千単位、単体・結合テストの項目数は数万単位のプロダクトです。
コード面やアーキテクチャでの工夫、継続的な開発を意識したCI/CDの活用、監視体制の改善など様々なチャレンジをしながら、リリースを実現しました。
本トークは中〜大規模なサービスリプレイスをお考えのオーディエンスにとって参考になるトークになるものと思います。

またリプレイスや現在の開発・運用も協力会社の方とともにやっています。
大規模なプロダクトなので、参加人数が多くなりチーム体制やマネジメントといったところも試行錯誤しています。
現状の開発体制も踏まえ、協力会社と一緒に開発するという組織づくりやチーム体制についても参考になれば幸いです。

このリプレイスを通して特に活用できた技術は下記です。

• PHP
• Laravel
• PHPInsights
• Docker
• DataDog
• NewRelic
• AWS
  • Fargate
  • CodeBuild
  • CodeDeploy

現在、正規化という手法はDB設計においてよく知られている手法となっています。

しかし、現場では以下のようなテーブルを見かけることは珍しくありません。
・1 つのカラムに複数の値が入ったテーブル
・カラム数が多いまたは、1 つの情報変更で更新処理が多く必要なテーブル
・JOINすると期待通りの結果が得られないテーブル

これらは低次の正規化により一定解決できます。もちろん闇雲に分割すればいい訳ではなく、
正規化の概念を正しく理解した上で分割を行う必要があります。

そこで本セッションでは、リレーショナルデータモデルが集合論に立脚していることから、数学的背景に着目して第１〜第２正規化について紹介します。
具体的には、RDBの用語(候補キー・関数従属性・情報無損失分解・正規形)を適宜厳密に解説しつつ
実際の正規化の例を通して、PHPer が向かうべきテーブル分割の手法を持ち帰っていただきます。

本セッションでは、FLEXY（フレキシー）が定期開催しているオンラインイベント「CTO meetup」の出張特別編として、Makuake、BASE、pixivと国内トップクラスのサービスを展開する3社に登壇頂きます。

ユーザー数やサービス実績を伸ばし続ける3社が、安定的かつ継続的にプロダクト開発を進める上で工夫してきた点はどこか。
また、サービス拡大に伴い組織も大きく成長するなか、どのようにチームパフォーマンスを最大化させたのか。
PHPをはじめとする技術活用の手法から、外部人材活用や開発体制構築といった組織戦略の話まで、実践テクニックを語って頂きます。

Makuake
「生まれるべきものが生まれ 広がるべきものが広がり 残るべきものが残る世界の実現」をビジョンに掲げる、アタラシイものや体験の応援購入サービス。
会員数が約220万人（2022年7月時点）、Makuakeに掲載した各プロジェクトに対する応援購入総額は年間200億円規模と国内最大級の実績と人気を誇るプラットフォーム。
登壇者
CTO／生内 洋平さん
Twitter: https://twitter.com/ikunai

BASE
「ネットでお店を開くなら」でお馴染みとなっている、誰もが簡単にショップ開設できるネットショップ作成サービス。
充実した機能や使い勝手の良さから、5年連続ネットショップ開設実績No.1、累計180万以上のショップの開設実績を誇る。
登壇者
CTO／川口 将貴さん
Twitter: https://twitter.com/dmnlk

pixiv
イラスト、マンガ、小説作品の投稿プラットフォームで、今年9月にサービス開始から15周年を迎える。
昨年9月時点で登録ユーザー数7,100万人以上（うち半数近くが海外ユーザー）、累計投稿作品数1億超えという実績をもつ国内最大級のクリエイタープラットフォーム。
登壇者
開発リーダー／宇佐美 健太さん
Twitter: https://twitter.com/tadsan

オンプレミスにて提供しているサービスをパブリッククラウドへ載せ替える際に注意しながら取り組んだ点を紹介します。

また、私たちのサービス価値を維持するため、競合との競争力を失うわけにはいきません。
そのため、パブリッククラウドへマイグレーションを行うプロジェクトと並行しながら、
如何にサービス改善を行ったかを紹介します。

さらに、EOLを向かえたWebフレームワークを利用していたため、クラウド環境に移行するにあたり、SymfonyからLaravelへWebフレームワークのマイグレーションをいかに効率的に実施したのかも合わせて紹介します。

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

現在私が所属するGrowfit株式会社ではLaravelで作られたStraym(ストレイム)というアート作品のオーナー権販売サービスの開発・運用を請け負っています。

自分が参画したのは2020年頃で、コードを見たところルールや方針もあまりなく、技術的な負債に対してあまり改善ができていない状況でした。
すぐにでも改善したいところですが、開発体制はCTO+私の2名(たまに助っ人)体制で新機能開発/保守運用の全てを行っており、かつ成長途中のプロダクトということもあり新機能開発が最優先で負債を解消していく時間を別途確保するのは難しい状況でした。

それでも負債をそのまま放置せず、機能開発と並行しながら負債と向き合い、少しづつではありますが継続してリファクタリングを行うことで保守性の向上に努めています。

この発表では、参画してからの2年で行ってきた少人数チームでの負債との向き合い方や実際の取り組みについてお話しします。

「なんかXXXの機能が開かないんだけど、、」
深夜に自分がリリースしたものが原因で次の日に全企業に響く様な障害を起こしてしまいました。

本トークでは以下の2軸をお話していきたいと思います。

■ なぜ障害が起こったのか
根本原因は「フレームワークの機能を使わなかった」からなのですが、なぜそうなってしまったかを
実際にコードリーディングしながら解説します。

■ 我々の組織の障害フロー
障害かな？から障害対応、そのあとのポストモーテム方法を取り決めています。
これにより良くなったこと・改善できたこと、などをご紹介します！

自分が起こした障害ゆえ発表するのも恥ずかしいのですが、、、言わぬは一生の悔い！！
ぜひ今後の人生の教訓にどうぞ。

※こちらのトークは、9/24 Track3 15:15 から、9/25 Track4 13:20に移動しました

私が担当するSaaSプロダクトは15年続くサービスで、メインシステムはいわゆるレガシーシステムになっています。
そんなプロダクトで、新機能実装にあたり新たに小規模なサブシステムを構築することになりました。
メインシステムとはある程度切り離されたシステムなので、せっかくならモダンな技術を存分に取り入れたい！と思いつつも、環境面の制約や既存資産の流用、チームメンバーの学習コストといった課題も考慮しながら技術選定やアーキテクチャ設計を行う必要がありました。
そして検討の結果、既存資産を一部活用しながらも、新規要素としてフレームワークにはSlimを採用し、アーキテクチャはオニオンアーキテクチャ（風のアーキテクチャ）を取り入れることにしました。

このトークでは、Slimを使ったアプリケーション構築の一例として、サブシステム構築時に考慮した技術選定・アーキテクチャ設計のポイントをご紹介します。

みなさんモビングしてますか？
モビング（モブプログラミング、モブプロ）とは複数人でプログラミングを行うことを意味します。
なぜモビングをやるのか？ どうやるのか？ ペアプロとなにが違うのか？ 結局生産性はあがったのか？
ずっとモブプロするのか、ときには並行作業するのか？

マーク・パール著「モブプログラミング・ベストプラクティス 」を実践してみて学んだことをギュッと圧縮してお話しします。

明日から役立つモブプロのエッセンスをお伝えできたら幸いです。