2023年11月23日に PHP 8.3 がリリースされます。本トークでは、追加が確定している新機能を紹介すると共に、その機能がどんな議論を経て追加されたのか、この先の展望も含めてわかりやすく解説します。

また、要望はされたものの却下された機能の話や、現在議論中の機能についても紹介します。

本トークで話す内容

• 現時点で追加が確定している機能
• これから追加される見込みの機能
• 要望はあるものの追加されなかった機能

Notionはとても優れたドキュメンテーションサービスであり、ある程度使い方を覚えてしまえばこれまで様々なWebサービスを組み合わせて仕事していたものが使い方次第でNotionだけでそれらが行えて便利なことから、自身が所属する会社においても導入後はエンジニアに限らず様々な職種の方々が利用しています。

自身が所属する事業部内で私は複数のサービスを運用するチームにも所属しており、そこで最も利用しているNotionの機能はデータベース機能です。Notionのデータベース機能とは単なるページの集合体ではなく、フィルター機能や各種ビュー機能などが備わっていることから、複数のサービスの仕様や運用マニュアルなど膨大な量のドキュメントを分類して管理するのにとても便利な機能であり、すでにサービスの運用を行う上では欠かせないものとなっています。

しかしそのようなデータベースをここ2〜3年管理する中、ドキュメントやデータベースが日々増加してきたことで以下のような課題や要望が発生してきました。

• 問い合わせ対応をする上で運用マニュアルを管理するデータベースから知りたい情報がうまく見つけられない場合がある
• 仕様や運用マニュアルなどコンテキストごとに複数のデータベースを作成しているが、それらの情報が連携できておらず欲しい情報にうまくたどり着けない
• 普段Slackで運用メンバー同士がコミュニケーションをとっているのでそこからNotionの情報にシームレスにアクセスしたい
• サービスの仕様などサービスにとって重要なドキュメントはレビューした上で更新したい

このような課題や要望を解決するために運用しているルールや利用しているツールなど、自身が所属する組織においてどのようにNotionを活用してサービスを効率的に運用しているかについての知見を共有したいと思っています。

近年、PHPプロジェクトの品質を高めるためのツールとしてPHPStanのような静的解析ツールが導入されるケースが増えています。

しかしながら、PHPStanをただ単に導入しただけではバグを完全に潰すには足りません。
PHPStanに新たなルールを加え、更に厳しくするためのPluginがphpstan-strict-rulesです。

PHPには厳密性に欠ける関数が散在します。
例えば、 in_array に第三引数を渡さないと厳密性が損われるので警告を出してくれるといったものです。

phpstan-strict-rulesを普及すれば、誰もが安心して開発できる環境が整うと信じています。

対象

• 既存のPHPStan level maxでは満足できない身体になってしまった人
• PHPStanでは捕捉しきれないバグに遭遇したことのある人
• 型に厳しい別言語から来た人

コードの問題点は見た目にはなかなか表れません。
長年の経験でピンとくる場合もあるかと思いますが、多くの場合知らず知らずのうちによくないコードが増えていき、気付いた頃にはそれは「レガシーコード」と呼ばれるようなコードになっているかもしれません。

ではどのようにして問題点に気付くことができるでしょうか？？

そのための1つのアプローチがコードを計測することだと考えています。
コードを計測することで得られる情報は多岐にわたります。例えば、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などです。これらの情報を取得することで、コードの状態を明らかにすることができます。

計測した数値はそれ単体で問題点を示すわけではありません。
その他の数値と組み合わせたり、実際にコードと照らし合わせて判断することが必要です。

本トークでは、主にコードをツールで計測することによって得られる結果に着目し、どのようにしてコード改善にアプローチするかをお話しします。

本トークでは主にコードをツールで計測することによって得られる結果に着目しながら、どのようにコードを改善に対してアプローチをすることができるか？をお話しさせていただきます。リファクタリングやコード改善に携わる方々にとっての一助となればと思っております。

私は、10人のメンバーが所属するチームのチームリーダーをしています。
エンジニアリングもする、いわゆるプレイングマネージャーというやつです。

リーダーになったのは約5年前。
当時は、組織改変に伴ってリーダーができそうな雰囲気の人を捕まえて、
「リーダーできる？できるな！？君は次からリーダーだ！いい感じに頑張れ！以上！」
といった具合でリーダーが任命されており、みんな手探りでマネジメント業をやっていました。
あなたの会社も同じような感じだったりしませんか？

リーダーになったからにはマネジメント業に対してもお給料が出ているので、しっかりやりたいところです。
しかし、マネジメント業を学ぼうと思って本を漁ってみると、「がんばらなくていい、自分の色を出して頑張れ！」と書いている心意気の本や、フィードバック手法やらコーチングやら進捗管理やらの具体的なノウハウが書かれた本が目立ちます。

しかし、まず最初に知るべきは「マネジメント業という仕事の本質」です。
自分が何をしようとしているのかを知らずして、さまざまなノウハウを学んでもそれは単なる付け焼き刃なのです。

本セッションでは、私がリーダーになる前に知っておきたかったマネジメント業という仕事の本質を、自身の経験も交えつつ共有できればと思います。

対象者

• 上長がどんなことをしているのかを垣間見たい方
• これからマネジメント業をしようとしている方
• マネジメント業を担っているけどどうしたらいいかわからず迷子になっている方

プログラムにおいては処理の結果を何らかの方法で伝達し、成功と失敗を切り分けたいことがないでしょうか。

PHPにおいても、ファイルを読み込む file_get_contents() 関数は string|false のような型宣言になっています。
標準関数においてはそれ以外にもエラーや例外など異常事態を伝えるための機構が組み込まれています。

そのほかにも、成功と失敗を表現するにはその他にも数多くのアイディアがあります。
このトークにおいては、PHPでは馴染みのない手法も含め、事態をより安全に異常と正常を切り分けて扱うための方法を扱います。

キーワード

• エラー・検査例外
• 型安全・静的解析・PHPUnit
• 直和型・ユニオン型・タグ付きユニオン

もっとデプロイを増やしましょう。
ここ数年、国内のPHPコミュニティの勉強会やカンファレンスでも、Four keysを始め「開発組織の生産性・健全性」の計測や向上に関心が高まってきているのを感じます。
その源流となるのは、DevOpsのムーブメントでしょう。
「開発と運用が分離されていることが、天井になっているのではないか」というDevOpsの精神は、自ずと「もっと高速にデプロイ出来る、頻度をあげられる、それによってプロダクトの提供価値を増やせるはずだ」という夢を追う事になります。

翻って言ってみれば、それほど「DevとOpsは反対の動機で行動しかねない」というリスクを背負うということです。
すなわち、「安定して、信頼性が高いソフトをデリバリーして欲しい」と願うOpsと、「思い描いた機能を、速やかに出していきたい」と願うDevの対立です。
結果として、「対岸」の怖い人に迷惑を掛けたくないし、あるいは「同じ側」にいる人のためにも信頼を損なうような事をしたくない・・・・「デプロイ恐怖症」のトラップに陥っていきます。

そうした背景が、現実世界には存在する事は想像に難くありません。
ですが、それは突破できると嬉しい世界が広がるはずの、突き破るべき天井です。

私の職場では、この半年〜1年ほどで「デプロイ数を今までに何倍にも出来た」「最近はデプロイするのが怖い！って気持ちが減った」という声を、開発メンバーからチラホラと聞くようになりました。何が起きたのでしょうか？

主に「開発者の心理的な面」の改善・向上に焦点をあてて、その変化をもたらした要因やプラクティスについて共有します

主なトピック

• やっぱりマージまでを早めよう！デプロイの粒度もちっちゃくしよう！は大事
• 「壊れても気付ける」という安全のためのシートベルトを用意していく
• 「もし欠陥があっても対処できる」という自信、「大騒ぎにならずに沈下できる」というanti-緊張感を備える
• 開発に歓びを取り戻すのじゃ！！

仕事をしている時など、「ムッ」とする場面はありませんか？
そうした際に誰かを悪者にしていませんかね。
悪者って、何でしょうか？──自分の目的達成や生存に対して、阻害をもたらす存在だとします。
イラッとすることがある、上手く行かないことがある、それらを「誰かのせい」にすることで、ギクシャクしてしまったり衝突を起こしたり・・・そんな経験はないでしょうか。その多くは、望んで起きた結果ではなく、望まずして生じて避け難かった「事故」のようなものである事も。

「問題の外在化」という技法があります。
これは「(問題を起こした)誰か」や「自分」に疑問を向けるのではなく、「問題を起こさせた要因があるはずだ」と考えることで問題そのものと人とを切り分け、本質的に「問題と向き合いやすくする」というものです。
「スプリントゴールが達成できなかったのは、Aさんの実装が遅かったから(Aさんが悪い)」ではなく「チーム全体でのコミュニケーションが以前より減っていて、アラートに気づけなかったから(チームが悪い)」「コミュニケーションが減っているのは、「執務室で会話を減らせ」と伝達を出してきたから(環境が悪い)」といった形で、問題の構造を変えさせます。

このような視点も含め、「解決したい問題が発見された時に、その背景や出どころに働きかける」という考え方として「システムズ・アプローチ」と呼ばれるアプローチがあります。
「誰か」から「仕組み」に意識の向け先を変更することで、憤りや不満と言ったネガティブな感情を和らげ、それまで「問題の主体」と考えられていた人物も含めた関係者で一体となって「コトに向かう」「他責的に考えず、当事者として解決可能な課題として扱う」ようになりやすいと言われます。

プログラマー職は「問題を解決する」「仕組みでどうにかする」が得意な職種だと思うので、この思考はとても相性が良いはずです。また、自然と「システムの問題として捉える」ができると、効果的な改善施策やアクションが浮かびやすくなります(例えばレトロスペクティブの場面などを想像してみてください)。
結果、深く広い学習のループが進むようになり、強いチームを手に入れられるようになるのです。

本トークでは、そんなシステムズアプローチの世界に触れつつ、「問題をシステムで捉えること」「実践しやすくするための視点・発想法」を共有します

ソフトウェア開発は複数人が関わる事が多く、特に業務の場合は単独の開発者で完結することは少ないでしょう。

人が複数集まると、「組織」となり「社会」が成立します。
そうした集団の力が、うまく活きれば強大なものになり、そうでなければ摩擦や抵抗により低減します。
うまく「チーム」で動いて行きたい、あるいは自分を取り巻くチームを良い方向に動かしていきたい…そう思ったことはありませんか！

「なぜ他人は動かないのか」「人はどうしたら動くのか」の両方向の力学を知っておくことが、ヒントになるはずです。
私は、マネジメントやリーダーの立場から、いくつかのチーム・個人に対して内外から関わっていく中で、「どのようにして、目の前の他人を前に進ませるか」を探求するようになりました。
本トークでは、チームやコミュニケーションに関する理論や考え方を紹介しつつ、協働するチームを築くための働きかけの技術について紹介します

伝えたいこと

• チームとグループの違い、目的を共有する集まりになることの重要性
• 進みたい方向性を示す・具体化し共有する、ただし他人に何かを「押しつけ」ないようにする
• 人ではなく課題に向き合うようにする
• 他人を尊重する、それと同じくらい自分も尊重する

参考書籍・関連分野

• あなたのチームは、機能してますか？
• なぜ人と組織は変われないのか
• 他者と働く
• プロフェッショナル・ファシリテーター
• ファシリテーター完全教本
• インターベンション・スキルズ
• プロセス・コンサルテーション

世の中から「クソコード」は無くせるものでしょうか？
せめて、地球や宇宙の全部とまではいわなくても、「私の身の回りにある世の中」であれば可能でしょうか？

私は、なるべく「クソコードなんて視界に入ってこないで欲しい」と考えています。
一体どうすれば奴らはいなくなるのか。すごく難しそうです。
ですが、「新しくクソを生まないようにしよう」というのは可能でしょう。

そのための一歩として、「クソコードと呼ばないようにする」ことを本トークにて提案したいです。

「心理的安全性が高いチーム」「人として、周りに気を配れる」「社会性フィルター！オン！！」
どれも大事ですね。とても大事です。
ですが、私は、もっと利己的な理屈をもって「クソコードと呼ばない」というムーブメントに取り組んでいます。
「温かい空気を作るため」ではなく、「もっと自分が技術者として成長するため」に、「クソコードなんて言葉は使わないぞ！」と決めたのです。

コードや成果物に対する「批判」は大事です。しかし、それは決して「あげつらう」ことではありません。
共有可能な価値観を提示し、それに照らし合わせて、より適正な在り方を目指す・・・そうした「批判」です。

「なんでこんなコードを書くのだろう」。
その根本にあるのは「コードの書き主が知らないことがある」「自分が見落としている事がある」の何れかです。
ここで「それはクソコードだ」と言ってしまえば、思考は停止してしまうと思います。
もっとダイブ出来るはずです。書き手の気持ちを考えよう。「なぜこの書き方を？」「どういう思考プロセスを経てこの書き方をしたのか？」「自分だったら、どこで”こうじゃない”と気付くはずか？」「単に書き手の技量不足だろうか。その足りない知識は、自分がわかりやすく説明できるだろうか？」クソコードから学べることは多いと考えます。
自分で納得できるまで「そのクソコードの生まれた歴史」を突き詰めていますか。

改めて、クソコードを超越した開発者になりたいと強く念じます。
極めて個人的な主張、理屈になってしまうかも知れません。
ですが、このセッションを通じて、こらからの未来に1回でも多くの「クソコード」発言が減らせたら幸いです。

あなたの組織はアジャイルですか！スクラムのフレームワークやXPのプラクティス、スクラムパターンや組織パターンを利用して独自のパターン・ランゲージを構築したりしていますか！！
こう聞かれると、「うちはアジャイルかどうか」を考えたり、あるいは「全然できていないのでは…」「本当のアジャイル教えてよ」なんて少し寂しい想いが湧いてくるかも知れません。
私の身近でも、「私のはアジャイルか」「あなたのはナンチャッテでは」と気を揉む様子が見られる場面があります。

個人的には、「良い事をやろうとしている人は、それだけで自信を持って良いし、幸せでいて欲しい」と思います。自分が取り組んでいることを「まがい物だから」と卑下したり、疑念を抱いて凹んだりして欲しくないのです。
「アジャイルになるぞ」と「アジャイルかどうかは気にしなくて良い」の精神性を両立することが必要だと感じていまず。実際、それは可能なはずです。

私は、独学でアジャイルについて学びを深めたり(コレとかコレとか)、Scrum Allianceの認定研修(CSM、CAL-1)での教育を受ける中で、そして組織の中で考え実践し他者との対話を重ねる中で、「定義や形式に拘り過ぎる必要はない、地に足をついた活動と理想を探求することは矛盾しない」と思うようになりました。

「be agile」へのジャーニーは、一朝一夕で成るものではなく、果てしなく長い終わりのない旅路です。
ましてや、booleanで「である」「ではない」を判断できるものでもないでしょう。

─では、アジャイルを意識して理想に向かい前進しよう！！とする時に、何が大事なのでしょうか。

このトークでは、「アジャイルソフトウェア開発宣言 / 背後にある原則」「XPの価値基準」「スクラムの理論と価値基準」「モダンアジャイルの原則」を改めて眺めてみて、我々が意識すべき「ありたい姿」を探っていきます。
その上で、マインドセットとプラクティスの面で「アジャイルリーダーとして、明日からあなたが取り組めそうなこと」を提言します。

今年 3 月に開催された PHPerKaigi 2023 にて「いろいろなフレームワークの仕組みを index.php から読み解こう」と題して 4 つの Web アプリケーションフレームワークの共通点から、（PHP の）Web アプリケーションフレームワークと呼ばれるものがどうやって動作するのか、一般に何の役割を担っているのか、というお話をしました（https://fortee.jp/phperkaigi-2023/proposal/e68c1ed6-8fb4-4ff9-9d99-99214d9dba8d）。

ならば今度は「共通点」ではなく「差異」に着目し、各フレームワークが提供しようとしている価値や設計思想の違いについて比較、考察した結果をお話します。
今回は index.php にとどまらず、フレームワークが備える機能やエコシステム、公式ドキュメント等も比較の材料として扱います。

本トークで扱うフレームワークは以下の通りです。

• CakePHP
• Laravel
• Slim
• Symfony

Google App Engine はリリース当初の2009年よりPHPをサポートするPaaS基盤です。
第一世代と呼ばれる言語仕様に制限のあった状態で PHP5.5 のサポートが行われてきました。
その後言語アップデートに関しては無料枠のあるスタンダードエディションから、有料で利用できるFlexエディションで実施されるようになり、次第にGAEの注目度は下がっていたように思います。

しかし2018年、GAEはgVisorベースの第二世代によってPHP7.2をサポートするようになり、それ以来最新の言語バージョンに追従するようになりました。

このセッションでは、GAEをご存知でない方や、第二世代のGAEを利用したことがない方に向けて、PHPアプリケーションをGAEのスタンダードエディション第二世代を動かすための概要やメリットを紹介します。

また、私も第一世代よりGAEを使って長年個人サービスを運営していますが、このたび2024/1/30をもって第一世代および第二世代のPHP7系ランタイムサポートが終了されるアナウンスがありました。
これにより私の第一世代で運用しているPHP5.5アプリケーションも一気にPHP8.1へジャンプアップする必要性も生じています。
こちらの移行の最新状況や、どのように移行しているかも含めた、GAEに興味がある/使っている人に向けたセッションになります。

PHPのDockerfile、秘伝のタレとなっていませんか？なんとなくのコピペになっていませんか？特定の人だけが触っていませんか？

【この発表のゴールについて】
Dockerfileの書き方を解説し、効率的なPHPのDocker環境を構築を迷いなくできるようになることを目指します。

【発表内容】
PHP8.2の実行環境を構築するということを前提に、以下の内容に触れます。

1. Dockerfileのお作法:
   Dockerfileの機能をおさらいしながら、最新の書き方が出来るよう解説します。

2. ベースイメージの選定方法:
   DockerHubにて公開されている公式PHPイメージにはいくつかの種類があり、タグ付けされています。(例えば8.2.4-alpine, 8.2.4-apache,8.2.4-fpm,8.2.4-cliなど) それらの違いを理解した上で適切なベースイメージを選べるように解説します。

3. PHPの各種拡張機能について:
   公式のPHPDockerイメージだけではアプリケーション開発は難しいです。拡張機能やパッケージを追加する必要があります。公式のPHPDockerfileを読み解きながら、何があり、何が追加で必要なのかを解説します。

【対象者】

• 自信をもってDockerfileをかけるようになりたい人
• PHPの拡張機能について理解を深めて行きたい人

【触れないこと・想定しないこと】

• Docker、Docker composeの詳細な説明やそのメリット・デメリットについて

みなさんはこういった経験が無いでしょうか。

「PHPStanのレベル5まで対応完了！よしっ！」
「つづいて、レベル6っと、ッターン！」

Method xxx() return type has no value type specified in iterable type array.

「ふぁっ！？」

、、、はい。あると思います。
そんなときはArray shapesなりで、ひーひー言いながら対応すると思いますが、泣きながらこう思った人も少なからずいるのではないでしょうか？

「PHPStanはLevel6で何を見ているのだろう」と。

今回のトークでは、そういった疑問をソースコードリーディングを交えながら、みなさんと一緒に解き明かそうと思います。
PHPStanが見ている世界を知ることができれば、PHPStan(ひいては静的解析ツール)ともっと仲良くなれるはず！

■ 話すこと

• PHPStanのレベル6について
• レベル5とレベル6での解析方法の違い
• 字句解析, 構文解析, 評価 について少し

■ ターゲット

• PHPStanの対応(特にレベル6)で苦労したことがある人
• PHPStan(静的解析ツール)と仲良くなりたい人

概要

プロダクト開発激化時代において、 より魅力的で競合優位性のあるプロダクト開発をしていくために組織育成は必要不可欠であり、その中でも特に育成が重要であること。
開発組織の開発力、生産性を上げるために避けては通れないエンジニア一人ひとりの技術力アップをどのように推進しているか。
私がEMとしてここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について整理して話します。

トーク内容

プロダクト開発におけるエンジニア教育の効用
良いプロダクトを作るために必要な組織の特徴
組織を作るために欠かせない採用と教育
エンジニア教育する際のマインド、モチベーションをいかに引き出すか
質とスピードはトレードオフでは無いが、成長機会とトレードオフである
表面的なスキルからより基礎、より根幹のマインドが大事なワケ
レベルごとの教育スタンス（ティーチング、コーチングの使い分け）
教育にまつわる理論（認知特性やラーニングピラミッドを活用する話）
カンファレンスでしか得られない栄養
個のスキルから組織のスキルへの転換の仕組みづくり

想定視聴者

組織のエンジニア教育にミッションを持ち悩んでる人
エンジニアとして今後の成長方針に悩んでる人
教育に興味がある人

補足

本セッションは https://tech.willgate.co.jp/entry/2022/12/24/113000 に投稿したものを加筆し、よりブラッシュアップしたものになります。

含まれないもの

エンジニアに必要な個別技術の習得方法
エンジニアとしてどのような個別技術を学ぶべきか

リアルタイムOSとは特定の事象が発生してから、決められた時間内に処理を実行できるシステムを構築するためのOSです。
多くの場合、組込みシステムで用いられていて、例えば自動車や飛行機、産業制御装置などのシステムに利用されます。

リアルタイムOSには以下のような特徴があります。

・複数の実行コンテキスト(タスク)を持つことができる
・タスクには優先順位を設定でき、優先順位の低いタスクに割り込む形で、優先順位の高いタスクを実行できる
・タスク間でメッセージをやり取りしたり、リソースを排他制御する仕組みがある

本トークではリアルタイムOSの一つであるAmazon FreeRTOSを題材に、タスクの動作や各機能の活用方法、リアルタイムシステムの設計方法についてお話します。

このトークでは、技術同人誌を知らない人や初めて執筆する人に向けて、技術同人誌を頒布するまでのステップを説明します。多くの人が執筆に興味を持ちながら、何から始めれば良いのかわからなかったり、完成までの道のりが遠そうだと感じて二の足を踏んでいたりするかもしれません。

実際には、技術同人誌を製作するのはそこまで難しくはありません。各種ツールを活用することで、つまづきポイントを回避しながら書籍を製作することができます。

私自身、これまでいくつかの技術同人誌を頒布してきました。技術記事を書くことや技術イベントに登壇することとは違った魅力があるため、同じ技術発信でも技術同人誌を作ることをおすすめします。完成した紙の本を手にしたときのワクワク感は、何度でも味わいたいと思えるほどです。

技術同人誌は、書きたいと思ったときに書き始めるべきです。このトークを聞いて、ぜひあなただけの技術同人誌を製作しましょう。

昨今、SNSやWebsiteビルダーによってインターネットでの情報発信の敷居が低くなっています。また、インターネットでの情報発信が当たり前だからこそオリジナルなポートフォリオサイトやコーポレートサイトを作る機会も増えていると思います。そのような場合、サイトオーナーが更新できる環境として、WordPressをレンタルサーバーにインストールしてカスタマイズする構成が多く採用されていると思います。

WordPressは多くのプラグイン、大きなコミュニティというエコシステムが便利ではありますが、サイト構築のためのソフトウェアです。一方で、第２の脳と呼ばれるNotionは、散り散りになったWeb上のツールを一つに集約し生産性を高めるソフトウェアが人気を博しています。Notionを使う前提になりますが、インターネットの情報発信に使うコンテンツもNotionで管理し、そこからNext.jsを使ったStatic Websiteとしてビルドすると、安価でハイパフォーマンスなサイトが構築できるというわけです。また、Notionのデータベースは非常に柔軟性のあるカラム定義ができるため、Websiteの仕様に応じて設計することができます。

Notion APIからStatic Websiteを作るのは骨が折れます。なぜかというと、Notionに埋め込まれた画像やデータはNotionの認証に守られているため、ローカルにダウンロードする必要があります。また、Notionには何百という外部サービスの埋め込み機能があるからです。ですので、その苦労を肩代わりしてくれるNotionateを使うと手軽に先述のことができるのです。

Notionateは私が開発しているソフトウェアです。その開発においての苦労や工夫した点をご紹介します。例えば、Notion APIのRatelimitにかからないように何をしているか。サイトが大きくなるとビルド時間が比例して長くなります。その緩和のための差分ビルドをどのように実現しているか。などです。また、Static Websiteだけでは補えないケースを、PHPで作ったAPIの例もご紹介します。

https://github.com/linyows/notionate

皆さん単体テストを書いていますか？

Webサービスを保守・運用していると、追加開発する際に機能の冪等性（べきとうせい。何度同じ操作をしたとしても同じ結果を得られるという性質）が求められることもあると思います。特にインフラにAWSを利用している場合、AWSリソースへのアクセス部分のテストをどのようにするか悩みますよね。

LocalStackを利用すると、ローカル環境でAWSクラウドサービスをエミュレートして、アプリケーションのテストを実行することができます。更に、GitHub Actionsで単体テストをまわすことが出来ると素敵ですよね。
今回は、Laravel（PHP）にフォーカスを当てて、LocalStackでAWSリソース（S3、DynamoDB、RDS、etc）の効率的なローカルテストを実現するとともに、GitHub Actionsで単体テストを自動化するところまで説明したいと思います。

主な対象：
・AWSを利用してWebサービス開発をしている方
・Laravel（PHP）を用いてWebサービス開発をしている方
・疎結合、密結合の単体テストの作り方で悩んでいる方

話すこと：
・LocalStackの紹介
・コンテナサービスの比較
・LocalStackを利用したAWSリソース単体テスト for Laravel（PHP）
・GitHub Actionsによる単体テストの自動化