トーク

BtoBなWebアプリケーションを開発してSaaSとして提供していると、お客様から「弊社の業務フローの都合でここを変更して欲しいのですが」という相談？要望？恫喝？を受けることがあります。
もちろんお金を払ってくれる大事なお客様なのですべての要望にお応えしたいのですが、無秩序にすべてを受け入れてカスタマイズすればコードもプロダクトもどんどん複雑になって、カオスと化してしまいます。

• 自社のプロダクトの軸
• 今後の他のカスタマイズの余地

を考えながら個社カスタマイズを実装していく考え方をお話しします。

IaC（Infrastructure as Code）は、クラウドインフラストラクチャの自動化と効率化に欠かせない技術となっています。クラウドベンダーの一つであるMicrosoft Azureには、TerraformやARMテンプレート、BicepなどのIaCツールが用意されています。それぞれのIaCツールには特徴や利点があり、どちらが優れているかは状況によって異なります。
また、GitHub CodespacesはWebブラウザ上で開発環境を構築できるクラウドのエディターです。GitHub Codespacesを使うことによりローカル環境を汚さず手軽に環境を整えることができます。
本セッションでは、初級者向けにGitHub Codespacesを利用して、Terraform、ARMテンプレート、BicepのIaCを比較してみます。

AzureでPHPの環境を整えることを例にあげ、それぞれのIaCツールの利点や欠点を比較していきます。また、GitHub Codespacesでの開発環境構築の手順や利点についても解説します。
本セッションを通じて、AzureにおけるIaCの比較とGitHub Codespacesの活用方法について学び、より効率的なクラウドインフラストラクチャの構築に役立てていただけると幸いです。

ChatGPTやOpenAI APIを使って何か作ってみませんか？openai-php/clientを使えば、PHPアプリケーションから簡単にOpenAI APIを呼び出すことができます。このトークでは、OpenAIで使えるAPIの機能紹介、openai-php/clientのセットアップ方法、OpenAI APIを使ったサンプルLaravelアプリケーションの実装を共有します。

• OpenAIで使えるAPI
  • Completions
  • Chat
  • Transcribe
  • Image
  • Embeddings
• openai-php/clientのセットアップ
• サンプルLaravelアプリケーション

皆さんはどこの言語圏にお住まいでしょうか？
（もちろん PHP 言語圏だとは思いますが）PHPer の皆さんの中には，私と同じ日本語圏にお住まいの方も少なくないのでは無いでしょうか？
日本語と言えば？そう．マルチバイトですよね．私達は日頃からマルチバイト文字と呼ばれる文字を扱っています．

一方で，Laravel を始めとする世界で使われている OSS を作っているのはどこの国の人なのでしょう？
OSS のコミュニティを覗いてみると，ドキュメントや Issue はどれも英語で書かれています．もちろんこれは，英語は世界で広く使われている言語だから，というのもありますが，（これは私の体感ですが）開発者の多くは主に英語をネイティブに使っている方のような気がしています．

私が過去に使っていたライブラリやフレームワークも，英語圏の方，つまりシングルバイト文字を日常的に使っている方々が開発しているものが多くありました．そのようなライブラリやフレームワークは，しばしばマルチバイト文字が入力されることを想定していないことがあるようです．
そして，私のようなマルチバイト圏に住むエンジニアからしたら当たり前のことや感覚が，シングルバイト圏に住むエンジニアには伝わりにくいなと感じることがありました．

本セッションでは，実際にライブラリやフレームワークに「マルチバイト文字」に関するプルリクエストを作ったりディスカッションしたりした経験を元に，自分や他の開発者が直面しているライブラリやフレームワークの課題をいかに上手くコミュニティに伝え，世界で広く使われる OSS に少しでも貢献できるエンジニアになれるか，ということについてお話します．

Guzzleに代表されるHTTPクライアントは、PHPからHTTPリクエストを送受信するために便利なライブラリですが、そのまま取り扱うとライブラリとの依存度が高まってしまいメンテナンスコストが上がります。そこで一般的にはラッパーを用意します。
LaravelなどのフレームワークではHTTPクライアントのラッパーが用意されていますが、そんなものは使わず、ラッパー自作しましょう。
自作することで、HTTPクライアントの依存をしっかり見抜く力が付きます。

このトークでは、Guzzleラッパーを自作しながら、HTTPクライアント・リクエスト・レスポンスのそれぞれの持つ情報が何の役割を持っているかを確認し、何に依存すべきかを考え、学んでいきます。

話すこと

• PSR-18と関連するPSRs
• Guzzleのバージョンアップに伴う変更の回避など

話さないこと

• Guzzleの詳細な使い方

いちばん大切なことは「落とし所を決めて前に進める力」でした。
今回は、新卒1年目がPHP5.6から7.4へのPHPアップデートを主担当した中で学んだ「アップデートの難しさ」について語ります。
言語のアップデートはプロダクトに対する変更の影響範囲が極めて大きいです。そのため、プロダクトの技術的側面に詳しくないと壊れるポイントがわかりませんし、事業的側面に詳しくないと壊してはいけないポイントがわかりません。
また、とれる施策がたくさんあり明確に意識しなければやることがどんどん増えてしまいます。これに対応するためにビジネスサイドならびに現場エンジニアとの会話を重ね、「なぜアップデートを行うのか」を明確にしていきました。
今回は、PHPアップデートを行う中で見つけた「こうしておけばよかった」近道を話します。

対象視聴者

• 言語のアップデートを現在進行系でやっている人
• その中で影響範囲が広く、苦しんでいる人
• 周りに相談する人がおらず、一人で苦しんでしまっている人

伝えたいこと

• 「なぜアップデートを行うのか」の確認を最初にする
• プロダクトコードを最初に読むのが大事
• ビジネスを含むドメイン理解があると動作確認とかテストとかのサボりどころがわかる
• テストがあることはめちゃくちゃ大事
• 依存ライブラリのアップデートが厳しいにもかかわらず、言語だけをアップデートしようとするのは茨の道
• 人を巻き込むと良いことがある

型、付けてますか？

型なしは心のゆるみ。プログラマたるもの、型付けは帰宅したら脱いだ靴を揃えるくらい自然に行なう所作です。
入力に型がなければ、すべての処理を安全に実行することはできません。

このトークにおいては標準関数のfilter_var()とPHPStanによる静的検査によって型なしの値に型健全性と実行時安全性を両立させる考え方を解説します。

キーワード

• filter_var() / filter_var_array() / ハイドレーション
• PHPStan / PHPStan extension
• 型安全性(型健全性)

https://www.google.com/search?q="コピペプログラマー"

既存のコードをクリップボードにコピーして、然るべき場所に貼り付けることで、プログラミングを遂行することが出来ます。
それなのに、世の中ではそれを良しとしない風潮もあるぞ！とは、みなさんも感じているところではあると思います。
他方で、 composer require darekano/nankano-package をしても、それを見て「なんなのコイツ」と感じる人は少ない気がするんですよね。

どちらも「目的(要求を満足させるための振る舞い)を実装するために、コードを再利用する」という点では差がないはずです。
同じコードを世の中に増殖させる・・・！
それなのに、なぜ前者は駄目で後者は許容されるのでしょうか・・？不思議です。

駄目と言われるからには、開発者にとって必要な何か(特定の品質特性)を損ねるし、問題があるのでしょう。
良しとされるからには、そうしたダメージを回避しているか、あるいは品質を向上させる働きがあるはずです。

このセッションでは、「みんなが言っている当たり前」を理屈で考えてみようと試みます。

★ コードの再利用とは

• 再利用によって達成できること
• 「悪い再利用」がもたらす悪影響
  • モジュールの結合の観点から
  • 凝集度の観点から
• 「良い再利用」なんて本当にあるのか
  • 移植性の観点から
  • 抽象度の設計の観点から
  • 「seam」「分離」の観点から

★ コードに対する進化、フィードバックとは

• ソフトウェアを進化させるためのフィードバック
• コードの「淘汰」「枯れる」のメカニズムを信頼する
• 「伽藍とバザール」の話と絡めて考える

★ 目先の「書く」ではなく、もっと先の「読む」「書き換える」のための品質を獲得しよう

PHPカンファレンス2023ではトーク募集にforteeというカンファレンス運用支援ツールが採用されています。
そのfortee、2023年3月下旬からトーク応募時にChatGPTによる「AI診断」の機能が付きました。
この機能は、入力されたタイトルと概要からAIがより良いプロポーザルになる様に思ったことを言う機能です。

さてこの機能、本当に役立ったのでしょうか。
ログが取れている範囲で「一度でも機能を使った方のトーク採択率」を計算してその有用性を検証するとともに、forteeへのChatGPT機能実装についてお話しします。

お話しする内容:
・AI診断機能のトーク採択率への影響
・ChatGPT機能の実装方法
・今回forteeで使用したプロンプト
・プロンプトの改善でどの様な変化がでるか

目に見える効果が無かった場合、このタイトルは釣りタイトルとなり、トークは事実上「PHPを使ったシステムへのChatGPT機能の実装方法とシステムに組み込むプロンプトの検証」となります。

前回のPHPカンファレンス福岡2019で「JAMstackアーキテクチャを用いたモダンWebサイト開発」というタイトルでFusicのテックブログにJAMStackアーキテクチャを取り入れた話をさせてもらいました。
あれから約4年ほど経ち、静的サイトジェネレーターをGridsomeからAstroへ移行しました。

Astroは最近注目されているWebフレームワークの一つで、「Astro Islands」というWebアーキテクチャパターンにより、不要なJavaScriot読み込みを無くし、高速なWebサイトを実現できます。

移行によって得られた最適化効果により、ページの表示速度が向上し、Lighthouseのスコアが満点のページ、または満点に近いスコアのページを生成できるようになりました。
体感でのページ表示速度もさらに速くなったと感じます。

本セッションでは、移行の経緯、Astroを選択した理由、移行時の苦労、今後の課題についてお話します。

Github ActionsでDockerイメージをビルドしてデプロイしています。
当初、Dockerイメージのビルド時間がとても長く、デプロイまでに時間がかかってしまっていました。

そこで、Dockerfileを見直しレイヤーキャッシュを意識するようにしたところ、コンテナビルドの時間を短縮することができました。

Dockerイメージビルドにおいて、レイヤーキャッシュを活用することはビルド時間を短縮し、開発効率を向上させることにつながります。

本トークでは、

• Dockerとは
• Dockerイメージとレイヤーキャッシュ
• Github Actionsにおけるキャッシュの利用
• Github Actionsでのコンテナイメージのビルド

という内容に触れつつ、Dockerのレイヤーキャッシュを利用したイメージビルドの方法やビルド時間を短縮するための方法について説明させていただこうと思います。

伝えたいんです。オフラインのカンファレンスの素晴らしさを。

カンファレンスに行ったことがない人、初めて参加した人などからはこういった声をよく耳にします。

• 「カンファレンスってすごい人がいっぱい行くところでしょ？」
• 「私は全然技術力ないし、普段勉強してないから行っても何もわからないし…」
• 「興味はあるけど知り合いが居ないから1人で行ってもなぁ…」
• 「自分はコミュ力無いから話しかけるのとか無理だ…」

そんなとき、私はいつも
「違うんです…！すごい人ばかりが来ているわけじゃないんです…！」
「わからなくても大丈夫！1つ単語を覚えて帰ってきたらそれでいい」
「カンファレンスでの会話にコミュ力は必要ないのになぁ…」
と、思いながらカンファレンスの良さや、初めて参加する人へのアドバイスをたくさんの人に伝えてきました。

このトークはそんな方に向けて、学生時代に初めてカンファレンスに参加したことがきっかけで自分の人生が変わった参加歴6年のカンファレンス大好きな私が、様々なカンファレンスに参加し続けたことで得た「カンファレンス参加者として楽しむためのコツ」をたっぷり詰め込んだトークとなっています。ぜひ聞きに来てください！
また、カンファレンスジャンキーの方も、我々の仲間を増やすためにどういうふうに良さを伝えたらいいんだろう…と悩んでいることでしょう。カンファレンスへの誘い文句の参考になるトークをするのでご安心ください。

※このトークはPHPerKaigi 2023のアンカンファレンスで「カンファレンスで友達を作るコツ」としてLTした内容をブラッシュアップしたものです。

話すこと

• カンファレンスに参加するメリット
• 当日聞くセッションの選び方
• セッションを聞いたスピーカーに話しかけよう！緊張しなくて大丈夫、スピーカーは話しかけられたくてたまらないんだ。
• 参加者同士で話題にしやすいカンファレンスで話しかけるときの鉄板フレーズ集
• それでも話しかけられない？そんなときは〇〇に話しかけよう
• カンファレンスで出会った人との繋がり方、その後のコミュニケーション方法について

オンプレだったPHPアプリケーションをコンテナ化してWEBとバッチをクラウド化（AWS）しました。
今まで全くインフラの仕事はしておらず「インフラをしてないからわからないこと」が怖かったり、課題にぶつかった時に何もわからない自分を変えたい！！と思っていました。
そして機会があったため手をあげてSREと協力しながら実現させました！

今回私がまるっとインフラ周りを経験したので「普段アプリケーションをさわってるけど、インフラもやっていきたいんだよなあ・・・」と思っている人がはじめの一歩を踏めるような「やわらかい説明」でインフラの話をします！

■ 話すこと
クラウド化で発生する作業ってなんだっけ？（ECS / Docker / デプロイ / ... ）
実際のタスクを進める上での悩み・詰まりポイント
クラウド化後に起こった想定外だったこと

■ 想定する聴衆
「インフラ興味あるけどなんもわからん」と思っている1年前のアプリエンジニアの私向けに作ります
総合して初学者向けです

みなさん、テストを書く際にどうやってテストデータを用意していますか？
PHPのフレームワークであるLaravelではfakerphp/fakerを使用し、簡単にランダムなテストデータを生成することができます。また、メールアドレスや人名、絵文字などを作成するように指定することもでき、大変便利なライブラリです。

しかし、何でもかんでもランダムにテストデータを生成していると、テスト対象のロジックをテストの中で実行し、アサーションをするといったことを意図せずしてしまうことがあります。
また、ランダムなテストデータを使っているからといって境界値テストを怠ったり、Property based testingのようなテスト観点が抜け落ちたりすることがあります。

本トークではFaker（ランダムでテストデータを生成するツール）を使用しない方がいいテストや、境界値テスト、Property based testingについてお話しします。

プロジェクトでスクラムに倣った開発をしてみて、私はスクラムマスターとしての役割で半年間運用しています。
チームメンバーはアジャイル開発について言葉は知っていたし、「スプリント」でのタスクの回し方、「レトロスペクティブ（ふりかえり）」などはスクラムっぽく回した経験はありました。それにさらに「リファインメント」「スプリントレビュー」などをやってみました。しかしルール通りにできないところもあり、悩みました。そして自分達のPJにFitするにはどうしたらいいだろう？を考えて工夫して取り組みました。その話をします。

■ スクラムとは（ゆる〜く）
■ プロジェクトで大事にした「アジャイル開発」の要素
■ 定義通りにやれなかったところ、Fitさせるために取り組んだこと
・きちんとしたプロダクトオーナーを依頼できない問題
・スプリント中にぽろぽろ出てくる「考慮不足」「新たなタスク」がでてくる問題
・タスクの依存関係のせいで暇な人がでてくる問題
■ アジャイル開発をキチンと採用してみて解決されたプロダクトの課題

■ 想定する聴衆
アジャイル開発を回している人
アジャイル開発を回してみたい人
アジャイルの概念はなんとなく知っている人

PHPカンファレンス福岡2023へのプロポーザルを提出するにあたり、
社内のメンバーに何か聞きたいことがあるかヒアリングしました。

結果「打ち合わせがすごい」「打ち合わせのコツが知りたい」という声をもらったので
自分の打ち合わせに関する技術を言語化できればと思います。

打ち合わせは非常にコストの高い業務です。
参加メンバーも多く、メンバーの時給を合算すると意外に多額の予算を消費してしまっています。
打ち合わせの品質を向上すれば、業務全体の生産性は間違いなく上がるでしょう。

下記のようなテーマに沿って話せれば良いなと思っています。
例)

• しっかりとした準備が前提。
• 打ち合わせにはいくつかの性質があり、性質を把握して立ち振る舞いを調整する。
• 前提を合わせることにコストを惜しまない。
• いくつかのオプションと撤退ラインを明確にする。
• 情報の粒度やステータス、用語に細心の注意を払う。

エンジニアの生産性には、優秀な人とそうでない人との間に大きな差があると言われています。
その差はどこからくるのでしょうか？
今回は「学習」という側面にフォーカスしながら、生産性の高いエンジニアであり続けるための戦略について考えてみます。

エンジニアの生産性の差は、ひとつには教わるだけの人と自ら学ぶ人との学習姿勢の差が反映されたものです。
自ら学ぶ人は常に教わるだけの人の先を行きます。それどころか「学び方を学ぶ人」はさらにさらに先を行くことになるのです。

技術・環境・ツールの変化が激しく既存のスキルがすぐに陳腐化してしまう現代において、「学び方の学び方」こそが重要なスキルになります。

このトークでは、エンジニアに欠かせない学び方の学び方と、自ら学ぶ集団の作り方について共有し、みなさんと共に考えていければと思います。

数年間で成長してきた自社プロダクトが、増加したトラフィックを処理できない問題に気付き、
AWSインフラをリプレースすることにしました。

2016年に立ち上げられた自社プロダクトは、利用者数と利用コンテンツがどんどん増えていきました。
さらに、利用プラットフォームもウェブとガラケーからモバイルアプリへと拡大し、利用者の利用頻度も急激に増加しました。
具体的には3年で利用組織が6倍、ユーザーが6倍になりました。
それに伴って、サーバーへのトラフィックも急増し、ボトルネックになりそうな状態に陥りました。

しかし、サーバーは今後も増え続けるトラフィックをうまく処理できず、高いレイテンシで応答するか、最悪の場合システムがダウンするほど可用性が低い状態でした。さらに、障害へのトラブルシューティング対策も不十分で、不安が募りました。

そこで、AWSインフラの問題点を洗い出し、対策案を立てました。
固定台数のEC2インスタンスで対応していたサーバーを、
負荷分散と自動スケーリングが可能な仕組みに変更しました。
さらに、サーバーで行われていたさまざまな処理をサーバーレスに移行し、
自動フェイルオーバーの仕組みも導入しました。
特に、数年間継続して運営してきたサーバーを含むインフラを一新するにあたり、
インシデントが起きないようにリリースまでの流れに検証の内容をしっかり盛り込みました。

• インフラ設計 ‐ 草案
• インフラ構築・実現検証 ‐ デモ
• サーバー簡素化
• システム改修
• プロビジョニングツール導入
• 構築・確認・検証 ‐ デモ
• インフラ設計 ‐ 最終版
• 構築・確認・検証 ‐ 本番
• インフラ切り替え
• ヘルスチェック・イベント可視化

その結果、トラフィックが増えてもうまく分散できるインフラが整い、
低レイテンシでサービスを提供することができるようになりました。
また様々な検証のおかげで、プロダクトに障害を起こさずにインフラのリプレースが実現できました。

このセッションでは自社プロダクトでインフラのリプレースを行った背景ときっかけ、そして実際にリプレースを行った流れを紹介させて頂きます。

Pest (https://pestphp.com)はPHPのテストフレームワークです。PHPUnitをベースにしているので、PHPUnitの機能は全て使えますが、Jestのような直感的なシンタックスで書くことができ、PHPUnitにはない便利な機能がたくさんあります。このトークでは、PHPUnitを使っているけどPestを使ってみたいという方を対象に、以下の内容をお話します。

• Pestのインストール
• PHPUnitとのシンタックスの違い
• LaravelアプリケーションをPestでテスト
• Pest v2の新機能

海外カンファレンスに登壇したいと思ったことはありませんか？Laraconは世界中のLaravelユーザーが集まるLaravel公式のカンファレンスです。
Laracon US, EU, AU, India, Onlineなど毎年に世界各地で開催されています。僕は留学経験などありませんが、今までに2回Laraconに登壇する機会をいただきました (Laracon Online 2022の動画)。英語がペラペラでなくても、面白いトピックと熱意さえあれば誰にでも登壇するチャンスはあります。このトークでは、Laraconへのプロポーザルの提出から、採択されてから本番までの準備、登壇本番までの経験談などをお話します。海外カンファレンスでの登壇に興味がある方にとって、一歩を踏み出すきっかけになれば嬉しいです。

• Laraconのトークプロポーザルの書き方
• 採択されたらどうなるのか
• トークの準備、練習
• 交通費、旅費
• カンファレンス前日（ワークショップ、スピーカーディナー）
• カンファレンス当日