PHP8.1では、いくつかのリソースがobjectに移行しました。
例えば
pgsql result リソース → PgSql\Result オブジェクト
pgsql link リソース → PgSql\Connection オブジェクト
などです。

私が開発しているMaildealerは、すでに開発から20年以上経過しているレガシープロダクトです。
その中に存在する PgSQL 用の独自ライブラリは、すべてがリソースで扱うことが前提のコードになっていました。

マイナーリリースで気軽に入れられた変更が、レガシープロダクトに与えた影響と、その解決方法をお話します！

※このLTは、PHPConference関西2024と同じ内容になる予定です

本セッションでは、高負荷下でのPHP WEBアプリケーションのパフォーマンスを支えるために、nginx+ngx_mrubyプロキシとGo言語で構築した仮想待合室サーバをどのように統合し、活用しているかを具体的に解説します。

トラフィックのピークをクールに処理し、ユーザーエクスペリエンスを最大限に高めるためのチューニングの詳細、通知、ダッシュボードを用いた運用プロセスを含めて紹介します。

実際に運用している環境から得られた貴重なデータを基に、PHP開発者が同様の問題に直面した際に役立つ実践的なソリューションを提供します。このセッションは、高トラフィック時の対応策を模索するPHP開発者やアーキテクトにとって、必見の内容を含んでおり、技術的な深堀りとともに、ビジネスの継続性と成長を支えるインフラとしてのPHPアプリケーションの強化方法を提案します。

オンラインカウンセリングサービス「エキサイトお悩み相談室」は、
2023年11月に定期的にご利用いただいているお客様に向けてよりお得にご利用いただけるよう、コインの定期購入機能をリリースしました。
毎月決まった金額で自動で購入され、二回目以降金額に応じた特典コインが付与される機能です。

購入方法はサービスの特性によって様々存在します。
ECサイトではクレジットカードによる都度購入、動画配信サイトではサブスクリプションなど、多岐にわたる選択肢が存在します。

これらの多様な購入形態を体系的に整理しつつ、コインの定期購入機能の開発事例を紹介いたします。

お客様にスムーズにサービスをご利用いただけるよう、我々がどのように購入方法を進化させてきたのかをお伝えいたします。

Outline
・よくあるサービスの購入形態のおさらい
・当サービスの概要と、用意されている購入方法の説明
・11月にリリースしたコインの定期購入機能の開発談の共有
　- 定期購入フロー
　- 既存仕様とのすり合わせ方法
・学びの共有
・まとめ

Target Audience
・サービスの購入形態について興味のある方
・オンラインカウンセリングサービスについて興味のある方

Webアプリケーションには多くの「良い」とされるデザインが存在します。
例えば、インターフェースである画面やAPI、その実装であるアーキテクチャのデザインなど。
そして、持つ機能が発展していくにつれて適切なデザインも変わります。
では、CLIツールはどうでしょうか？
手元での実行が主だったり、Webアプリケーションと比べて複雑なビジネスロジックを持つことも少ないです。主なターゲットは開発者です。
だからと言ってデザインを疎かにして良いわけではありません。
発表者は多くのCLIツールを開発、メンテナンスをしています（ https://github.com/k1LoW ）。
機能も想定実行ケースも様々です。また、Webアプリケーションほどではありませんが、5年を超える開発をしているものもあります。
本発表ではその経験を元に、CLIツールの開発をする上で考える様々なデザインを紹介します。

レガシーなコードを触る場面は、エンジニアなら多くの方が経験しているかと思います。
例えば、コメントが嘘をついていたり、関数名変数名がわかりにくかったり、データベースのカラム名が何を保存しているのかわからなかったり...
私も15年前とかのコードを触る機会があり、そういったことを新卒で入社してから1年半ほど良くしようとしてきました。
その際に実際にあったレガシーコードを紹介しつつ、学んだことやどうやって直していこうとしたかをご紹介できればと思います。

「遅いのを早くしたい！」って思うじゃないですか。
そんな時に、「phperでも並列処理したい！！」と叫びます。

ある時、easy-coding-standardのREADMEを見ていたら、こんな文章を見つけました。

Acknowledgment
The parallel run is heavily inspired by phpstan/phpstan-src by Ondřej Mirtes. Thank you.

なんと！あの素敵なプロダクトも、PHPStanの実装に触発されて参考にして、並列処理を実装している！？
・・・つまり、phperにとって「あの処理を並列パワーでどう早くするのか」の野望を叶えるヒントが、そこにある！！！

そうと分かれば、飛びついてみたくなるのが性ってやつです。
PHPStanのパワーの源を、読んで・試してみました！

こんな話

• PHPStanの並列処理、どんな風に動いているのか(利用者目線)
• どのように実装して、実現しているのかな
  • ReactPHPの利用プロダクトとしてのPHPStan
• 実装したら、テストはどんな感じに書いているんだろう？

「テストがないコードはレガシーコードだ！」
Webアプリ開発において、PHPUnitなどでテストコードが書かれることは一般的になりました。

ですが、テスト完走までにかかる時間は適切でしょうか？
テストにかかる時間は生産性に直接的な影響を及ぼす重要な要素です。早ければ早いほど良い。
本トークでは、PHPUnitで書かれているテストを高速化するテクニックについてお話します。

対象観客

• 開発生産性を上げたいと思われている方
• テストの実行時間が長くてキレそうな方

お話すること

• 「phpunit-speedtrap」プラグインを使って遅いテストを検出する
• Googleが提唱する「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• makeやparatestを使ったテスト実行の並列化
• (Laravelの場合) DatabaseMigrations Traitは遅いので出来るだけ使わないほうが良い
• テスト時でもOPcacheは効くのか

速さは正義。Googleもそう言っている。

Webページの表示速度はユーザ体験に直結し、ひいてはビジネスKPI (購買率、アクティブ率、解約率、etc...) にも影響を及ぼします。
本トークでは、Instagram分析ツール 「SINIS for Instagram」 のページ表示速度を約1/3にした事例をもとに、どうやって課題を見つけ、何の改善を試み、その結果どうなったのかについてお話します。

想定観客

• 自分のWebサービスの表示速度が何か遅いんだよな〜と思われている方 (高速化したいけど何からやっていいか分からない方)
• パフォーマンスチューニングコンテスト「ISUCON」が好きなかた

お話しすること

• Core Web Vitals
• ベンチマークツール Vegeta
• index見直しやSQL組み換えによるクエリチューニング
• XDebug x Webgrindでプロファイリング
• GraphQL Schema Caching
• PHP OPcacheでPHPバイトコードのキャッシュ

php-srcのIssueの中に、「マルチバイト対応のtrim関数を作ってくれないか」という機能要望(Feature request)がありました。
しかし、様々な事情で長らく膠着状態だったため、ぼくがpingをしてみたところ「自分で作っちゃえば？（意訳）」と返事が来ました。
そうと決まれば実装するのみです。
PoCとRFCを記述し、RFCの投票によって、mb_trim, mb_ltrim, mb_rtrimの3つの関数はPHP 8.4（多分）で入ることになりました。
本トークでは、これら3つの関数の使い所と、どうやって実装したのか、RFCの書き方などを共有したいと思います。

だいぶ市民権を得てきたフリーランスという働き方。
Web開発者界隈でも人気のキャリアになりつつあると感じます。

本トークでは2019年にフリーランスになって4期目を迎え、酸いも甘いも経験してきたわたくしがフリーランスのWebエンジニアとして働くということのメリット・デメリット、理想と現実についてお話します。

想定観客

• Webエンジニアとしてのキャリアに悩まれている方
• フリーランスという働き方に関心がある方
• フリーランスになるか迷っている方

お話しすること

• そもそもフリーランスとは何なのか
• 正社員との働き方の違い
• 理想と現実
• どういう人がフリーランスに向いている、向いてないのか
• どうやって仕事を取るか
• いつまでフリーランスとして働けるのか
• みんな大好きお金の話
• 住宅ローン組める組めない話

その他

かいつまんだものをテテミートLT会でお話しました。
https://speakerdeck.com/pinkumohikan/about-freelance-web-engineer-for-tetemeet-vol4

私も含め知っている中小企業で働くエンジニアは、経験年数が2 ~ 3年を超えてくると役職としてリーダーとなることが多いです。

私はリーダーとなった1年間は、自分以外のプロダクトに関係する人のことを考える機会が増えました。
その中で、多くの細かい失敗もしました。

しかし、心理学を知っていくことで、これらの失敗の原因もより違う観点で見え、再現性を持った失敗を少なくする考え方ができました。
それら実例を交えながら解説し、心理学を身近に感じてもらえたらと思っています。

日々会社で開発していると、こういうことよく起きませんか？

• 設計方針を固めたけど、気づいたら乗っ取っていない
• 確認を投げたけど、返信が遅い
• 業務時間に良い方法を思いつかなかったけど、散歩中に良い案を思いついた

こういうあるあるは、自分だけに起きるのではなく、色んな人が経験しています。
つまり脳や心の働きとして、そういう行動をとってしまう傾向があるとも言えます。

それらの現象を心理学から学び得ることで、日々の開発体験に活かしてもらえたらと考えています。

ライブラリの管理やクラスのオートローディングはどのようにされていますでしょうか？
多くの現場ではComposerを使ってライブラリの管理やクラスのオートローディングを行っていると思います。
しかし、レガシーシステムではComposerを使っていないという現場も存在するのではないでしょうか？
レガシーシステムにComposerを導入した際の課題と効果について紹介します。

・Composerを導入するメリット
・Composerのオートロード機能の紹介
・レガシーシステムにComposerを導入するためのTips
・独特な開発環境による課題
・導入後から半年の効果と課題

すでにComposerを導入している方も、Composerの仕様をより知ることでより効率的にComposerを使えるようになるかと思います。

「WebAssembly」という技術が、さまざまな領域で耳目を集めています。
WebAssembly を実行する仮想機械 (VM; virtual machine) を PHP で作成し、その動作原理や注目が集まる理由について話します。
WebAssembly だけでなく、PHP などの任意の言語の処理系についても、そのおおまかな内部構造を知るきっかけになればと思います。

話すこと

• WebAssembly とは
• VM とは
• 作ってみる
• WebAssembly に注目が集まるわけ
• WebAssembly を拡張する提案 (WASI、WASIX など)
• 作った VM の上で WebAssembly にコンパイルされた PHP 処理系を動かす

対象者

• WebAssembly について知ってはいるが、技術的な詳細や使用シーンについて知らない方
• プログラミング言語の処理系の構成を知りたい、作ってみたい方

PHPでJSONを扱う場合は、json_decode(), json_encode()といった関数の利用が一般的です。
この2つの関数の利用にはJSONの定義済み定数の理解が欠かせません。
JSONの定義済み定数を用いることで2つの関数の挙動を細かく制御したり、発生したエラーの詳細を把握したりできます。
このLTではJSON定義済み定数をすべて紹介しながら、PHPのJSON関数の少し進んだ使い方を紹介します。

私は自社で開発運用している「はたらこねっと」というサービスの開発を行っております。
私が所属しているチームでは新機能の開発、ABテストの実装、バグや不具合の修正など、日々様々な開発業務を行っています。
そんなチームで開発者である私がサービスのSLI/SLOを策定してみてどう思ったかを語らせていただきます。

開発者がサービスの信頼性について考えることで得られる新たな視点とサービスに対する考え方の変化や、策定にあたってのビジネスサイドとのコミュニケーションと策定時に意識した要点についても併せてお伝えします。

本トークを聞いていただくことで、"開発者が"サービスの信頼性について考える重要性やメリットについて認識していただけると思っております！

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試しています。
まだまだ実験途上の試みではありますが、私がどういう不便を解消したいと考えているのか、その不便を解消するために使っているツールのアップデートの履歴、PHPerKaigi2024当日までの成果を発表したいと思います。

Composer使っていますか？使ってそうですよね！

パッケージマネージャーの魅力は、
「色々な環境や操作者に対して、画一的な成果物(依存解決)を提供できること」はもちろん、
「継続的なメンテナンスやアップデートを実現容易にすること」にもあると考えています！

前者はcomposer.lockによって自動的に実現され、後者は「良いcomposer.jsonを作ること」が肝です。
そして、composer.jsonの美しさが、Composer中級者としての実力を語るのではないでしょうか！？

このトークでは、私が「実際にComposerを使っているプロジェクトに関わる際に、意識していること・使っているツールや操作」を紹介します

お話する内容の例(一部)

• @stableや@dev、使ってますか？
• require-devに入れる？それとも、composer-bin-pluginを使う？
• config.jsonに書いておくと良いこと、CLIコマンドのオプション
• depends / prohibits で差がつくComposer運用
• Packagist Semver Checkerは良いぞ

アプリケーション開発を行う際、OSS（オープンソースソフトウェア）はなくてはならない存在となっています。
そんなOSSにも脆弱性はあり、日々攻撃の脅威に晒されています。
私のチームでは、Garoon（ガルーン）という20年ものの製品をより安全に、そして継続的に提供するために、セキュリティの観点からOSSのアップデートを行っています。
このLTでは、私のチームでOSSのアップデートをどのような基準で行っているのか、ということについて共有します。

話すこと

• OSSの脆弱性をどう検知するか
• この脆弱性って対応すべき？をどう判断するか

チームのタスク管理について、以下のようなお悩みはありませんか？

・ タスクの優先順位がよくわからず、大事なタスクが締め切り直前なのに終わってない！
・ タスクが属人化してしまい、タスクが計画通りに進んでいるのか、なにか問題を抱えてしまっているのかを把握するのが難しい！

私のチームは、この対策としてチームの開発効率と生産性を向上させるアジャイル開発手法の一つ、スクラムを始めました。
スクラムを活用することで、タスクの優先順位や進捗がチームで共有され、柔軟に見直すことが可能になりました。
また、アジャイルのマインドセットが身につき、日々のタスクへの向き合い方にも良い変化がありました。

こんな良いことづくしのスクラム、軽い気持ちで始めてみませんか？

【このLTで話すこと】
・ スクラムってなに？
・ なんでスクラムを始めたの？
・ スクラムの始め方
・ スクラムを始めたことによるチームの変化