トーク

初学者に向けて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アプリケーションをクラウドに移行するにあたって、
バッチのアーキテクチャを変えることになりました。
そこで私が採用したのが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

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

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

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

利用方法がわかることはもちろん、
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アプリケーションを作成する流れについてご説明します

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

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

B+木というデータ構造をご存知でしょうか？RDBMSでよく採用されているデータ構造で、ディスクの効率的な利用や、検索を行いやすいなどの特徴があります。しかし、耳学問で聞いてみてもイマイチ特徴がピンと来ないのです。

本トークでは、PHPでB+木のデータ構造を実装して、RDBMSでB+木が採用される理由、インデックスの構造的な仕組み、何故検索が速くなるのか？などなど、データベースの仕組みの根幹を覗いてみましょう。

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

• B+木の特徴
• B+木は何故ディスクの利用効率が高いのか
• インデックスとは何か
• なぜ、データベースはB+木を採用しているのか

Laravel Dacapoという自作のOSSライブラリの話をします。
https://github.com/ucan-lab/laravel-dacapo

・開発初期段階のマイグレーションについて
・マイグレーションで困っていること
・ダカーポを導入するメリット
・簡単な使い方やコマンドのご紹介

みなさんは Feature Flag (Feature Toggle) についてご存知でしょうか？

コード中に Feature Flag の値による条件分岐を仕込んでおくと、その値を切り替えることで機能を有効化・無効化することができます。 Feature Flag を使うことで、機能リリースのタイミングの柔軟な制御や問題のある機能の迅速なロールバックを実現できます。

弊社では Feature Flag を使った開発・運用を1年以上続けてきました。その過程で、 Feature Flag を用いたコードのメンテナンスコストを下げるための工夫や、当初は想定していなかった方法による Feature Flag の活用を行ってきました。

このセッションでは、弊社の事例を中心に以下のようなテーマでお話しします。

• Laravel での Feature Flag の実装例
• 不要になった Feature Flag の条件分岐コードを機械的に削除する
• Feature Flag の値ごとのテストを作成する
• Feature Flag を使って機能のリリースを Slack へ通知する
• Feature Flag を使ってデータとコードの変更を同じタイミングで実行する

～ オフショア先のコード品質向上は難しい ～

オフショアの場合、遠隔地であることだけでなく言語や文化、環境が違うため、お互いに意図を理解できているかや共通の認識を持てているかどうかが怪しくなってしまいます。
特に、コード品質向上のために行ったコードレビューのフィードバックについては、

・正しく内容を理解してもらえているか
・フィードバック内容を次回のコーディングに活かしてもらえるか

など、オフショア先との意思疎通が障壁となって、改善が行えない場合が多くあります。

そこで、私のチームではコードレビュー時に「再利用可能な」情報を提供することで、サービス全体のコード品質向上に取り組んでいます。
このセッションでは、

・どのようにしてオフショア先のコード品質向上に取り組めばいいのか
・オフショア先のモチベーションを保ちながらどのように改善を行っていくのか

などを、PHPのコードを紹介しながらお話しします。

『ウマ娘 プリティーダービー』は、2021年2月24日にサービスを開始しました。
空前の大ヒットと呼ばれ、想定を上回る大きな反響がありましたが、サーバーダウンなく無事にローンチすることができました。

事前に行った負荷試験の約10倍という想定を遥かに上回るアクセスをさばくことができたのは、アプリケーションのボトルネックとなりやすいデータベースに対する処理の最適化を進めたためです。
トランザクションをできるだけ短くする、という考えを念頭におき、N+1クエリの改善、排他制御の方式変更、MySQL 5.7における降順ソートクエリに対応したインデックス作成、といった対策を行いました。

本セッションでは、それらの対策について「『ウマ娘 プリティーダービー』のローンチを支えたサーバーアプリケーションの最適化ノウハウ」と題してお話します。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュート（アノテーション）を1行追加するだけで一瞬でREST APIを生成できてしまう優れもので、Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。

このトークでは、API Platformの導入方法から、Data Provider・カスタムコントローラ・Data Persisterといった重要な基本機能の概要までを、実際に動作するデモをお見せしながら一通りご紹介できればと思います。
皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

PHPでPDFファイルを作る、楽しいセッションです！

このトークでは、以下の内容が含まれる予定ですが、時間の都合で一部省略したり変更したり順番を入れ替えたりする可能性もございます。
・PDFのファイルフォーマットの簡単な解説
・ライブラリを使わずに生のPHPで、簡単なPDFファイルを出力してみる話
・可変長の項目（見積書や請求書の明細行が増えていく様子をご想像下さい）と改ページの話
・文字列の折り返し処理の話
・PDFファイルを作成するための主要なライブラリの機能比較

「本当にやりたい・集中したいビジネス・機能要件に集中する」ためのAWS・Stripe活用方法を紹介します。

新しいサービスやアプリを開発する際、「アプリのコア機能以外の機能」を実装するコストが高確率で発生します。
・顧客の決済情報を入力・管理するための「決済システム」
・顧客が支払い履歴や契約情報などを確認できる「マイページ」
・サービスを安定して提供するための「アプリインフラ」
・外部サービスやDB情報などを安全に管理する方法

これらの「必要だけど、作りたいものに直接関係しない機能」をAWSやStripeを使って最小限のコストで実装する方法を紹介します。

◆紹介予定のトピック（変更の可能性あり）
・Stripe Checkoutを用いたリダイレクト式決済ページ
・３〜５行のコードで、請求ダッシュボードを実装する方法
・AWS Secret Manager / Systems Managerを利用したAPIキーやDB情報管理
・AWS Amplify SDKを利用したマイページ実装方法