トーク

あなたのアプリケーションでは外部APIを参照していますでしょうか。
あるいは、あなたの作ったAPIを開発者に利用してほしいと考えていますでしょうか。

外部システムをプログラミング言語から使いやすくするパッケージはSDK(software development kit)と呼ばれることもあり、HTTPリクエストの発行やPHPクラスへのマッピングが主な責務になります。

基本的にはマニュアル通りの設定をしてメソッドを呼び出して使えるようにれば最低限使えるSDKができますが、開発やテストのしやすさという観点ではそれだけでは不足です。

このトークでは開発者とSDKユーザーの立場から、2023年現在で考えられるSDKの理想形とテスト手法について手短かに紹介します。

キーワード

• PSR-7, PSR-18, Asynchronous request
• 🙅🏻‍♀️ 不用意にGuzzleに依存しない
• HTTPlug Discovery

本稿の前提となる議論についてはPHPからのHTTPリクエスト (2016年版)にも掲載しているので、予習にどうぞ。

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

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

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

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

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

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

話すこと

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

Webフロントエンドのテストは書けていますか？テストを書いたほうがいいのはわかっているけど面倒でサボりがち、UIを変更するたびにテストも壊れてしまうし、いずれメンテナンスされなくなるくらいなら最初から書かないほうがいいんじゃないか...そんな気持ちになったことがある人も多いと思います。
このトークではDOMのテストに特化したオープンソースのJavaScriptテストユーティリティライブラリ Testing Library を紹介します。
Testing Libraryのおかげで、これまで億劫だったDOMのテストは、むしろ真っ先に書きたいテストに変わるかもしれません。テスト駆動開発との相性も抜群です。さらに、Testing Library を使ってテストを書いていくとWebアクセシビリティの改善にも役立ちます。
普段あまりDOMのテストを書いてない人もDOMのテストに苦手意識がある経験者もぜひ知ってほしい、Testing Libraryの世界を案内します。

※本トークの内容は PHP に関連しません。

万人を虜にし、数多くのエンジニアを型に嵌めたフレームワークという存在。某WordPressをはじめ、全世界のアプリケーションインフラを支える大黒柱ではあるが、彼らも時代とともに変わっていく。

自分自身も毎年脱皮を繰り返す彼らを業務上で付き合っていく中で、四苦八苦することがあるが、果たしてどのように関係を保てばいいものだろうか。

コントリビューターたちの軌跡を常にキャッチアップするほど、我々に時間は与えられていないし、業務は待ってくれない。

業務を通して、かつ、フレームワークの複雑さや進化と付き合ってきた、僕なりの方法をお話します。

・Laravelを使った開発における注意点
・PHPUnitを用いた設計・実装における勘所

近年のWebアプリケーションに求められるUI/UXはどんどん上がってきており、SPAアプリケーションを構築する機会が増えてきていると思います。
「フロントとバックエンドが疎結合！」という甘美な響きの裏には、スキーマ管理・リポジトリ運用・API認証など様々なオーバーヘッドが存在しており、
中小規模アプリケーションの場合はSPAはコスト高で選択肢から外してしまったことはありませんか？

Laravel8から登場したInertia.jsを使うと、これまでのBladeを使ったシンプルなレンダリングと同じ手法で、お手軽にSPA開発が可能になります。
Controllerから変数をセット、レンダリングするビューを指定するだけで、認証やスキーマなどを意識せず、JavaScriptページコンポーネントへとデータが渡りSPAとして動作します。

この構成をInertia.jsの公式サイトでは「現代のモノリス」と呼んでいます。
APIを構築せず、密結合な構成にすることで生産性の向上を提唱する新しいWebアプリケーションの開発手法の1つです。

このセッションでは、そんなInertia.jsの概要の説明と簡単なチュートリアルをしながら、
実際のお仕事に導入した際に感じたメリット・デメリットも交えてご紹介していきます。

話すこと

Inertia.jsとは
LaravelでのInertia.jsの使い方と例
導入して感じたメリット・デメリット

皆さんAPIシナリオテストを書いていますか？

単体テストでコントローラーまでは書くけれど、APIをE2Eテストは実際のクライアントから叩いたり、curlで実行する方が大勢かと思います。
E2Eテストを書くのは色々ハードル高そうというイメージで諦めていませんか？
確かにフロントエンドを含めたE2Eテストは実装と維持が凄く大変です。
そこでAPIにフォーカスしたテストに絞ってみて書き始めてみることをオススメします。
個人的に非常にコストパフォーマンスが高いテストだと感じています。
このセッションではAPIシナリオテストを導入検討して導入してから感じたことを紹介したいと思います。

プロジェクトを成功させるためには、「効率よく仕事を進める」「手戻りや足止めの時間を減らす」みたいな事を頑張りたいですよね。
タスク間の依存関係をほぐしたり、属人性の高いタスクにスペシャリストが良いタイミングで着手できるように整えるのは、いわゆるプロジェクト管理といわれる領域の成果であり責務です。
それと同時に、いかにソフトウェアを設計するか？によっても、プロジェクト管理のリスクのコントロールに影響します。すなわち、設計次第で「手戻りやタスクのブロックを軽減する」ことに繋がるのです。
これは、突き詰めると「変更容易性」「開放閉鎖原則」で説明することが可能です。

このトークでは、「どのようにして、ソフトウェア設計の観点からプロジェクト管理の難しさを和らげるか」について共有します。
設計と、スケジュール管理と、チームによる分業を総合して考えることで、よいプロジェクト人生を手に入れましょう！！

話すこと

• 「どこから作っていけば良いのか」で考えるPJの進め方
• 「ハリボテ」を活用して、実装の意思決定を遅延させる
• それでも「後回しに出来ない実装」にチームで如何に立ち向かうか

主な参考書籍

• アジャイルソフトウェア開発の奥義
• ライティングソフトウェア
• 実践テスト駆動開発

Interfaceって...

• 具体的な実装が書けないし、何のためにあるのかよく分からない
• 先輩に言われてDIする時に使ってるけどなんでそうするのかはよく分かってない
• ライブラリとか作る人じゃないと使わないんじゃないの？
• Repositoryパターンの概念は分かったけど、実装を差し替えるなんてそうそうなくない？

そんな風に思っていたりしませんか？
私は思っていました！

このトークでは自称中級PHPerが上記のような状態を脱するきっかけとなった経験を元に、Interfaceの使い所や有用となりそうな場面などについてロガーライブラリのデファクトスタンダードであるMonologを題材に考察してみます。

このトークのゴール

「Interfaceよく分からない...」から「機会があれば使ってみようかな？」と思えるようになること

対象者

• Interface書いたことない方
• 書いたことあるけど、よく分からんという方
• 抽象とか部分型とか言われても分からん！もっと簡単に説明してくれ！って方

非対象者

• Intefaceバリバリ書いてるし理解してるぜって方
• 抽象とか型理論を肴にお酒が飲めるレベルの皆様方

皆さん。
皆さんは型を書いていますか？
私は書いています。

なのに、いつの間にか型情報は消えているんです。
mixedになっているんです。
不思議ですね？

最近のPHPはバージョンアップのたびに型付けに対するサポートがどんどん厚くなっています。
それに合わせて開発環境が型情報をもとに補完候補を適切に表示したり、
静的解析によるチェックが高精度になり、
開発体験・開発速度が良くなっているはずです。

なのに、大切な型情報は消えてしまいます。
悲しいですね？

そこで、
どんな時に型情報が消えるのか、
どうやって回避するのか、はたまた回避は無理なのか。

主にLaravel・PHPStanとVSCode環境を例に最近の型にまつわる開発支援環境について発表します。

太古の昔、サーバーの設定をいじるとなると、プロフェッショナルなインフラエンジニアにお任せだったと聞きます。
我々（PHPer）の手に負えない程大きくなったインフラの管理は、それこそ職人技だったのだと想像できます。

一方現代、インフラの多くはクラウドです。
皆さんもAWSなどを活用していると思われますが…形だけのクラウドになっていませんか？
クラウドの登場で誰でもポチポチ簡単にサーバーを建てれるようになりました。が、"本番環境にそびえ立つ謎のサーバー"や"誰も設定がわからないLB"などオンプレ時代とそう変わらない問題を大なり小なりどの現場も抱えているかと思います。
我々はいつまでコンソールの画面をポチポチしてサーバーを作るのでしょうか？

昨今IaC呼ばれる便利ツールが流行っています。ただ、メリットがわかっていても、「キラキラでなんか怖い！」「うちには導入できない！」と思われて二の足を踏んでいる方もいることでしょう。
大丈夫です。我々が「ポチポチコンソールによるAWS」から「IaCによるAWS」にマイグレーションした過程をお話します。
「最初からすごい人がいたんじゃないの？」と思われるかもしれませんが、そんな事ありません！移行の過程で一つずつコード管理を進めました。
いまあるサーバーを動作させながら少しづつIaC化しましょう！

本トークでは
・TerraformなどIaCをつかうメリットを紹介
・アプリケーションエンジニアがTerraformを使えると良い理由
・ポチポチコンソールで作成した現在稼働中のサーバーを、Terraformで管理する方法・Tips
を話したいと思います。

※話さないこと
・ツールのインストール方法や、チュートリアルレベルのお話
・PR TIMESのAWS移行時の具体的な作業の説明

本トークを聞き終わった後に、PHPerのみなさんが「自社のサーバーをIaCツールで管理したい！俺らの手でやるぞ！」と思えるトークを目指します！

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

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

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

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

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

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

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