トーク

PHP で書いたコードをいち早く世に送り出すために、 AWS では昨年から次々と新しいサービスをリリースしています。その中から、フルマネージドのコンテナ実行基盤 AWS App Runner と、自動でデータベースがスケールできる Amazon Aurora Serverless v2 をご紹介します。

Mercari JPでは、全社的にマイクロサービスアーキテクチャへの移行、関連するサービスの Kubernetes化に取り組んでおり、新しいサービスは Golangでの開発、Kubernetes環境で運用しています。

一方で創業期から存在するモノリスサービスはPHPでオンプレミス環境で運用されていたため、言語の違い、環境の違いにより、学習コスト、メンテナンスコストに問題があり、Kubernetes移行に取り組んでいました。

2022年6月に完了したMercari JP のモノリスサービスのKubernetes移行を以下の視点で紹介したいと思います。
・どうやっておこなったか
・どんな困難があったか
・PHPならではでの問題にどう対応したか
・そして、今後どうなっていくか

※ こちらのトークはオンライン登壇になります

本年、Chatworkはリリースから11周年を迎えました。Chatworkで使われているプログラミング言語といえば、Scalaのイメージが強いかもしれません。
しかし、サーバーサイドのコードをPHPで実装されて以来、PHPコードは今でも現役でChatworkを支え続けています。

Chatworkではcommit毎に約6000ファイルのテストケースを実行しています。しかし、型エラーなどが発生していたとしてもテストでカバーしきれないところは、最悪の場合そのまま本番環境へリリースされてしまうという問題がありました。
それによって過去実際にユーザー影響のある障害が発生してしまったこともあり、Chatworkを安定稼働させ続ける上でも大きな問題点でした。

上記のような課題感から、PHPアプリケーションのCIに静的解析ツール(PHPStan)を導入し、コード品質の向上に役立てています。

本セッションでは、歴史の長いPHPで実装されたプロダクトコードにPHPStanを導入するにあたり、「導入に当たっての障害」「開発チームにスムーズに受け入れられるために取り組んだ事」「導入して得られたメリット」などに焦点を当てて紹介したいと思います。

TiDBはスケールアウト可能なMySQLプロトコル互換データベースです。負荷やデータ量に応じて、柔軟なスケールアウトが可能となっています。
さらに、マネージドサービスなTiDB Cloudをご利用いただくことで、サーバーインフラの管理を行わず、データベースをご利用いただくことができます。

本トークではTiDBの優れたアーキテクチャと、TiDB CloudとPHPでのWebアプリケーションの組み合わせについてご紹介します。

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

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

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

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

初学者に向けてPHPの翻訳が何をしているのかを解説します。
以下の内容を予定しています。
・自然言語処理で自動翻訳が進んできたけどいまだに辞書に基づいた翻訳処理のニーズはある
・PHPの翻訳処理の書き方基本（bindtextdomain, gettextとか）
・Cの処理をPHPがラップして処理している話
・結局上記の処理はmoファイルという翻訳ファイルを読み込んでいる話
・moファイルがどのようにできるのか（pot ->po->mo）
新規：xgettext, msginit, msgfmt
追加：xgettext -j, msgmerge, msgfmt
・EmacsのPOモードとかもあるけど実際に導入する際にどうやってガバナンスをとるべきかの話
（翻訳者は非エンジニアなので、翻訳のやりとりを同管理するか）
・翻訳処理を使用している身近な例（WordPress, PostgreSQL, 他あったら）

依存ライブラリの更新、定期的に実施できていますか？

恥ずかしながら担当プロダクトで更新ができていないケースがありました。
そしていざ更新を試みると対象ライブラリがいくつもあり、大幅なバージョンアップが必要なものも・・・

このような状況はまずいと感じ調べたところRenovateという依存ライブラリの自動更新を行うツールを知り、導入を試みましたが、更新を怠っていたプロジェクトでの素直な導入は難しいと判断。
そこで導入までにステップを置き、ライブラリのバージョン更新・Renovateの導入、そこから定期的に更新するという運用の流れを構築し、現在はライブラリの更新が健全にできていると感じています。

本トークでは依存ライブラリの更新を怠っていたプロジェクトにRenovateというツールを導入した流れと導入後の運用状況をお話させていただき、皆様の依存ライブラリ管理の一助となればと思っております。

いかに簡潔で当意即妙なコードを書くかはプログラマーにとって永遠の課題であり、実装パターンや標準ライブラリなどの知識と経験がモノをいうところです。逆に古いPHPの経験が長く最新のPHPをキャッチアップできていないと、現在では単純な関数呼び出しで済むものを冗長でパフォーマンスの悪い方法で書き続けてしまうということもありえます。

PHPには数多くの標準関数とシンタックスがありますが、その中には使いどころのわかりにくいものもあり、関数リストを全て読むといった学習法はあまり効率がよくありません。
今回のトークでは筆者がコードレビューやオンライン上の技術記事へのコメントを通じて指摘した内容を軸に、押さえておきたい関連知識を紹介します。

• PHPマニュアルの見方と標準関数について
• 古いイディオムとパフォーマンスについての考えかた
• 標準関数を使ったイディオム
• 静的解析 vs 標準関数
• オンラインサンドボックス環境の使いかた
• さっぱりを捨てるとき 〜 避ける余地のある標準関数

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

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

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

オンプレ稼働していたPHPアプリケーションをクラウドに移行するにあたって、
バッチのアーキテクチャを変えることになりました。
そこで私が採用したのがEventBridge＋ECSの構成でした。

■ EventBridge＋ECSで実現した仕組み
■ 他に考慮したAWSアーキテクチャ/ なぜこの構成にしたのか

のような軸でお話できたらと思います！

コロナ禍でフルリモート転職して一年が経ちました。
一度も会社に行ったことがないまま入社を決め、入社日もリモート出勤。誰も知ってる人がいない会社にフルリモートで入るのは、より緊張感があり、戸惑うことも多々ありました。
そんな中、自分なりにコミュニケーションを工夫し、「そういえばフルリモートだったっけ」と言われる程に仕事ができるようになりました。
今回は、リモートで仕事をするメリット・デメリットを中心に、転職したてにはどのような制度が助かったか、リモートで困った事とそれにどう対応したのか、などをお伝えできればと思います。

こんにちは。やまゆです。

月日が経つのは本当に早く、私が PHP を志してからもう 8 年近くが経過しているらしいです。
8 年もあれば、色々と変わるものですよね。 PHP もバージョン 5.3 から 8.1 まで大変遷を遂げました。

今回、様々あった 8 年間の PHP との 愛憎劇（？） を振り返ってみたいと思います。

• 5.3 => namespace の到来と、 composer の誕生
• 5.4 => trait
• 7.0 => 型宣言
• 8.0 => アトリビュートと constructor property promotion
• 8.1 => readonly
• (8.2) => readonly class

たくさんの進化を経た私と PHP の歴史を見て、 「 PHP いいなー」 と思っていただければ幸いです。

あるアプリケーションをコンテナ化することになりました。
Composerの使い方を試行錯誤していく中で「ど、DockerfileでのComposerの記述は、色んなパターンがある・・・！」という学びと、彼らとの絆を得ました。
そして自分の中でなんとな〜く使っていたComposerのことがほんの少しわかるようになりました！

「なんとなくcomposer install打ったらいい感じになるよね」「なんかDockerfileに書いてあるよね」という方が、このセッションを聞いてComposer、そしてDockerfileともうちょっと仲良くできるような発表をします！

話そうと思っていること
■ Composerってなんだっけ？
■ Dockerfileにどうやって書こう？
■ 最終的に採用した方法とその理由

「オブザーバビリティ」や「可観測性」という言葉は、耳にしたことがある人は増えてきていると思います。
あるいは、「全く知らない、想像もつかないよ」「また新しい "ﾅﾝﾁｬﾗlity" が出たんですか？」なんて人も多そうです。

PHPを趣味や仕事で使っている人は、Webサービスやモバイル等のバックエンドを提供しているケースが中心でしょうか。
「今もどこかの姿が見えない誰かが使っているかも知れない」「その人たちが、自分たちが提供しているサーバーにアクセスしている！！」
というのが、Webサービスの難しさであると同時に単純・嬉しいところでもありますよね。
すなわち、「何が起きているか」は「自分たちの目の届く所に集約されている」と。

オブザーバビリティとは、「いかに状態( = 上手くいっていること・問題が起きていること)が把握可能になっているか」という性質です。
放っておいても実現されるものではありません。
意識して、設計して、運用して・・・初めて手にすることができるものです。

これは単なる「ツール」「技術」の話ではないのです。
チームないし文化まで含めて、「どう向き合っていくか」を突き詰めた先にオブザーバビリティがあると考えています。

本セッションでは、「継続的に、かつ自信を持ってサービスを提供し続ける」ために大事なことを、
書籍「Observability Engineering」の内容をベースにしながら紹介していきます。
「SRE」「インフラ」「運用」 ではない 人達に向けた 、どうしてアプリケーション開発者が向き合っていくべきなのだろう・・？という話です。

こんにちは。やまゆです。

みなさん、 new してますか？私は、最近はあまりしていないです。なぜなら、インスタンス化はほとんど DI コンテナ に任せてしまうからです。お客様のプロダクトにも DI コンテナが含まれているのではないでしょうか？活用出来ていますか？

昨今の PHP は今や素晴らしい言語になっていると感じています。その一つが private readonly SomeRepositoryInterface $someRepo とコンストラクタに書けるという話です。

今回は以下の内容を話してみたいと思っています。

• 具象依存と抽象依存の違い
• PHP で具象依存を避けるにはどうするか
• DI コンテナとは何か
• Reflection による autowire を実装してみよう

こんにちは。やまゆです。

そこの方もあちらの方も、一度は 「PHP でフレームワーク作りたい」 と思った、または 実際に作ってみた のではないでしょうか？
私も例に漏れずフレームワークを作っていました。それも 二つ 。
メンテナンスはしていないですし、そもそもプロダクトに採用していません。 完全に趣味 です。
では、何故作ったのか？使わないものを作るのは一見無駄に見えますが、実はとても重要な作業だと私は考えています。

• フレームワーク作りで得られる知識
• フレームワーク作りの勘所
• フレームワーク と PSR

今回はこの三点を共有したいと思います。

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

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

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

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

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

フレームワークの利用方法がわからない…
そんな時にドキュメントを見に行くことになると思います。

フレームワークが内部で何をしているかは理解できないけど利用方法はわかる。
今回はそこから一歩踏み込む為にソースコードリーディングをオススメします。

利用方法がわかることはもちろん、
PHPのフレームワークの内部で行われている処理の理解や
Webアプリケーションが行うべき振る舞いについて学ぶ事が出来るので
より確実にフレームワークを利用することが出来る様になります。

今回はLaravelに関してのソースコードリーディングを例に、
フレームワーク作者の追体験をしてみましょう。

• 想定する聴講者
  • PHPフレームワークを利用する人
  • フレームワークの中身を気にした事がない人
  • よりフレームワークの理解を進めたい人

Webアプリケーションを運用する上で、監視の仕組みは欠かせません。
それはWebアプリケーションとして動作する事が多いPHPでも変わりません。

SREの文脈で特に重要性が高まるアプリケーション監視ですが、世の中には様々な監視サービスが存在します。
今回は特にAmazon CloudWatchをコアに据え、どの様にWebアプリケーションを監視する事が出来るのかを考察します。

PHP利用したアプリケーションに対してAWS以外のオンプレミスも対象とした、
コストメリットも含めた監視サービスについてお話します。

• 想定する聴講者
  • 普段AWSを利用していない方
  • Webアプリケーションの監視を始めたい方
  • 監視を行う上でのメリットを学びたい方

フルサーバーレスな構成を取る場合、様々なクラウドサービスの知識に加え
実践的な利用方法が求められます

またAWS上でフルサーバーレスなアプリケーションを作成しようとしても、
AWS LambdaのネイティブランタイムにPHPはありません

フルサーバーレスの恩恵を受けたいが、その第一歩が難しい
その悩みをAWS Amplifyは解消してくれます

普段はPHPで実装するバックエンドをAWS Amplifyに任せることで、
React + GraphQLで作成するログイン付きのサンプルWebアプリケーションを作成する流れについてご説明します

具体的な手法をなぞることでフルサーバーレスなアプリケーションを作成手法を学びましょう

• 想定する聴講者
  • フルサーバーレスアプリケーションに興味がある方
  • 具体的なフルサーバーレスアプリケーション開発の始め方を知りたい方