トーク

サービスを運用していると利用しているミドルウェアのアップグレードや巨大なデータベースのテーブルへのインデックスの追加などメンテナンスを入れて行わないといけないオペレーションが出てきます。
本発表では私が行ったデータベース(Amazon RDS)のメジャーアップグレードを例に、運用サービスのメンテナンスをどのように計画、実施したのかを紹介します。
またメンテナンスでの反省から学ぶ、準備と対応の重要性、メンテナンスの計画/実施したことない方にもイメージしやすいようメンテナンス時に考慮すべき点についても紹介できればと思います。

話すこと

• 行ったRDSのメジャーアップグレードについてのついての紹介
• メンテナンスまでに行った準備
• メンテナンスの反省点
• これからメンテナンスを行う人に向けて気をつけるべき点の紹介

みなさまPHP "以外の" 言語を書いていますか？
書籍「達人プログラマ」では1年に1言語あたらしいプログラミング言語を学ぶことを奨めています。
目の前の課題が同じでも言語が変われば別のアプローチになるのはよくあることです。さまざまなアプローチを学ぶためにもさまざまな言語を学ぶのは良いことです。

ところが、そうやって学んだ「他の言語でよくやるやり方」をそのままPHPに持ってきても上手くいかないものです。
言語を超えて適用できるベストプラクティスとはどのようなものか、PHPで推奨されるPHPらしい書き方とはどんなものなのか、このトークで一緒に考えてみませんか？

プログラムの本質的構造を示すAST（抽象構文木）に変化がなければテストを省略できる場合があることに着目し、ASTのハッシュ値を比較することでPHP 8.1からPHP 8.2にバージョンアップする作業の一部をスムーズに進められることが分かりました。ASTを取得および比較する方法や、事前に行った対象箇所の特定およびファイル更新方法などに関する具体的な手順や使用したソフトウェアを紹介しつつ、ASTがPHPのバージョンアップ時にも役立つことを解説したいと思います。

テストコードを書いていますか？
テストを書いた方が良いと誰しもが思いテストを整備していると思いますが、中にはテストコードを書く時間が作れない、意味を理解してくれない、テストコード実装の優先度が下がる、様々な理由でテストコード実装が出来ていない現場もあるかと思います。
今までテストコードを書かなかった開発現場が、テストコードを整備し開発・運用面・リリースの状況が変わった話や、効果を数値化した話、社内でテストコード導入を広めていくために沢山の手段の中からテストコード研修を実施するに至った話をします。

• テストコードが無かったアプリケーションの実態と現場状況
• 多くの時間を割いていたQAテストをテストコードでカバーできるか網羅率や整備コストを出し、効果を数値化した話
• テストコード整備後のリリース数や開発工数変化
• テストコード必須とした導入フローを検討の末、研修実施へ至った話

今までバッチ処理について雰囲気でやってきていませんか？僕は少なくとも雰囲気でやってきました。
もちろんバッチ処理なしで実装できるに越したことはありませんが、運用としてすでにそうなっているところも多いのではないでしょうか？
実際そんなに困ることねーし・・・！とそう思っていたそのとき！困る時がやってきます・・・。(震え声)
基本的にバッチ処理を避けた方が良いパターンについて言及しつつ、バッチ処理が必要な際にどのようなことを考えれば良いのか？どう見直す道筋を立てるのか？
TechTrainで実装するときに失敗したな・・・。と思った経験を踏まえてお話しします。

対象者

1. すでにバッチ処理があるが、どう見直したら良いのかわからない方
2. なんかバッチ処理でいけそう！と初手で考えてしまう方
3. バッチ処理書いてみたんだけど、良いのかわからない方

Docker の登場で、開発環境の構築はとても容易になりました。
コンテナを利用することで、実行環境の差異を隠蔽できるほか、複数の異なるバージョンの環境を 1つのマシン内で実現することもできます。

一方で、実際に PHP 製のアプリケーションを Web サーバー上で動かす際には、動作環境についての理解が必要です。
特に、フレームワークを利用したアプリケーションが、手元では動作するのにデプロイ先で 500 エラーを返す、といった経験はないでしょうか?

本トークでは、 PHP の動作環境を一から構築する方法についてお話しします。
PHP の本体だけでなく、 Web サーバーやデータベースといった、 Web アプリケーションを動かす上で必要不可欠な要素についてもお話しします。

手軽に動作環境を構築できるようになった今だからこそ、あえて PHP の動作環境を自分で構築してみませんか?

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。アジャイルを実践した今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして始め方についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話すること

• アジャイルのはじめかた

お話しないこと

• アジャイルにまつわる開発手法

PHP 8.1 で readonly property、そして PHP 8.2 で readonly class がサポートされるようになりました。

近年様々な言語でサポートされることが増えた「不変」であることが保証された変数やクラス。
PHP でもこれらの機能がサポートされたことで、中〜大規模なアプリケーションにおいて、バグを生みにくく、保守しやすい「堅牢」なコードを書けるようになりつつあります。

本トークでは readonly class を使う理由、そして実際に使って日々開発をする中で得たリアルな知見をお伝えしたいと思います。

話すこと

• readonly class とは
• readonly class を使う理由
• readonly class を使う場合の辛さ

※ PHP Conference 2023 でお話した内容をアップデートしたものです。

PHPerKaigiでは、タイムゾーンの雰囲気実装を抜け出すための話をしましたが、タイムゾーンは政治的な理由でよく変更されたり、tz databaseの過去の設定が実は間違っているなんてことが実はあります。実際に変更された時に僕たち実装する人がどう対応していかなければならないのか？危ないケースはないのか？について、お伝えします。

過去のPHP(特に５系まで)では、型システムが未熟であり、型の変換や関数の引数や返り値の型が厳密に管理されなかったため、関数を利用する際に適切な型の値を渡すことが難しかったり、返り値の型を信頼できない場合がありました。現在名前ベースで一致を調べる型システム(nominal type system) を採用していますが、他の言語と比べて、どうなのかを次の観点をベースにお伝えします。

1. 採用している型システムの考え方のメリットデメリット(nominal type systemなど)
2. 型コンパイルのタイミングが異なることによる影響
3. 1,2では難しいポイントを各言語ではどう問題解決しているのか？
4. 型システムの違いが及ぼす業務コードを書くことへの影響

文法のミスからビジネスロジックの違反など、コードを書くうえでは様々な例外が発生します。

本セッションでは、例外処理の機能であるカスタム例外を活用することで、
コードの責務を明確にし、より理解しやすく保守しやすいアプリケーションを構築する方法を紹介します。

こんな方にオススメ:

• カスタム例外の使い所を知りたい
• どの例外をcatchすべきか知りたい
• 例外を使ったテストコードの書き方を知りたい

主に話すこと:

• カスタム例外の効果的な定義と使い方
• カスタム例外を使ったテストコードの書き方
• どこで例外をthrowしてcatchすべきか

プログラムのインターフェースは適切に設計できれば柔軟で、再利用しやすく保守性の高いプログラムを生み出せる一方で、設計が不適切だと不要な複雑性をプログラムやその周辺に生み出し、その保守性に大きな悪影響を及ぼしてしまいます

今回のトークでは名著と名高いA Philosophy of Software Design(APoSD)の内容を追いかけながらソフトウェアの設計とその先にあると著者が示唆する「深いモジュール」について考察し、理解を深めていきます

お話する内容

• インターフェースという言葉の意味
• 良いインターフェース／悪いインターフェース
• 「深いモジュール」とは？

想定聴講者

• A Philosophy of Software Design（APoSD）を読んだことのない方

curlはさまざまな通信規格に対応しているデータ転送ソフトウェアであり、PHPにもcurl関数が用意されています。本発表では、PHPでHTTPS接続する方法の1つとしてcurl関数を利用できることだけでなく、常時SSL/TLSが普及した現代においてあらかじめ知っておきたいcurl関数のオプションや、サーバー接続テストを行うためのcurlおよびopensslコマンドの使い方、Webサーバー設定時のポイントなども紹介する予定です。

現在HTTP Cacheに関するRFCは7234...ではありません。2022年に改訂され、RFC9111 HTTP CachingとしてInternet Standardになっています。
本発表ではRFC9111、特に共有キャッシュについて見ていきます。
プロキシサーバのアップストリームに位置するWebアプリケーションとしてどうすればキャッシュをしてくれるのか、もしくは拒否できるのか。理解すれば、実装にはよりますが少なくともRFCに沿った議論ができるようになります。
発表者はRFC9111に沿ったキャッシュミドルウェアを実装しています。
https://github.com/2manymws/rc
そのため、実装経験に基づいた紹介ができます。
（なお、2024年3月現在rfc9111で検索して出てくるのは我々のリポジトリだけ）

この機会に「RFC9111完全に理解した」になりましょう！

Laraveler のみなさん、アプリのセキュリティ、気にしてますか？
何となく「Laravel がよしなにやってくれてる」で片付けてませんか？
安心してください、私もです。
XSS、CSRF、SQLインジェクション、セッションハイジャック、ファイルアップロード脆弱性、ログイン機構に対する攻撃、etc。
今回は、これらそれぞれの攻撃に対して、Laravel が何をしてくれているのか、その実装を追っていきたいと思います。
思わぬ落とし穴も見つかるかもしれません。

オープンソースソフトウェア（以下OSS）は現代において非常に重要な役割を担っています。業務として、あるいは趣味として、すでに貢献している方やこれから貢献したい方がいると思います。
ところで、OSSへの関わり方は非常に多様です。簡単なものでは誤字脱字の指摘から、機能追加やバグ修正、果ては自作OSSの開発まで、正解はありません。
発表者は機能要望や誤字脱字の修正からOSSに関わり始めました。その後個人的な目的のために小さなOSSを自作するようになり、自身の技術力向上に伴い有名プロジェクトへの機能追加もするようになりました。現在は一定のユーザーを抱えるOSSプロジェクトを運営するようになり、私以外のコミッターと一緒に開発しています。この発表では私個人の経験を通じて、多様なOSSへの関わり方を考えていただく一助にしたいと思います。

認知負荷 や ワーキングメモリ という概念があります。
「良いコード」や「プロジェクトチームの管理」といったお話の中でも、しばしば取り上げられるものです。
見聞きした事がありましょう？

ソフトウェアや組織、対人関係──とかく我々の日常は、形のないものに溢れ返っていて、
「いかに認知が生まれ、阻害され、思考が展開するのか」は、非常に重要な事柄です。
ここで一度、「認知負荷」や「ワーキングメモリ」について、基礎の基礎をおさらいしてみませんか？
その上で、我々の現場に立ち返っての「ヒント」を共有します

キーワード・こんな事に関心がある人へ

• なぜ注目すべきか。どんな背景で提唱されてきたのか
• どのような性質・種類のものがあり、思考・行動に影響するのか
• 「低ければ低いほど良い」とも言えない？なぜ？
• ソフトウェアや組織の問題に、どう関係するのか・対処していくか

「余裕ができたらリファクタリングしたい」と思ったままいつまで経ってもリファクタリングできないまま、そんな経験は多くの開発者に共通するのではないでしょうか。リファクタリングがあたりまえではなくなってしまった場所でリファクタリングの火を灯すにはいったい何からはじめるといいのでしょうか。このトークでは、まだリファクタリングの成功体験が少ない人や、やりたいと思っているが最初の一歩がわからないという人の背中を押せるような、リファクタリングのはじめかた、そしてリファクタリングをあたりまえにする生き方について、ふだん考えていることをお話しできればと思います。

Webフロントエンドのテストは書けていますか？

去年は「DOMのテストがどんどん書きたくなる Testing Library の世界への招待」 という発表をさせていただきました。
あれから1年経ち、「本番でユーザーに使ってもらう」に近づけたテストをおすすめしたことは、やはり間違っていなかったという思いを新たにしています。Webフロントエンドのテスト文脈で台頭しつつある新興のツールも、そのようなアプローチに寄ったものが増えてきているからです。

このトークでは、去年の発表から重要なエッセンスを取り出したうえで、新興のツールの潮流から、フロントエンドのテストはどこへ向かっているのかということを考えてみたいと思います。特定のライブラリやツールのハウツーではなく少しメタ的な話になると思いますが、テストについて改めて考えるきっかけを提供できれば幸いです。

Web アプリケーション開発に携わっていると、一度は OAuth という技術を耳にしたことがあるのではないでしょうか?
特に、 Laravel Passport のような、フレームワークの認証ライブラリについて調査しているときに OAuth という単語も見かけることがあると思います。

OAuth は 認可のためのプロトコル です。
しかし、そもそも認可とは何で、どのような機能を実現するものでしょうか?
そして、どのような場面で利用されるものなのでしょうか?

本トークでは、 OAuth について触れたことがない方を対象に、以下の内容についてお話しします。

• OAuth とは何か
• OAuth の使いどころ
• PHP で OAuth を実現する方法

本トークを通じて、 OAuth がみなさんの課題解決に役立つかを判断する助けになれば幸いです。