トーク

みなさんは普段からPHPやGo, JavaScript, Java などいろいろな言語でプログラムを書いて実行させていると思います。言語によってコンパイルの様な事前作業が必要だったり、書いたプログラムの実行方法が違ったり、実行速度が違ったりしますが、その違いはどこから来ているでしょうか。そしてそもそもプログラムを実行した時にコンピュータの中では何が起きているでしょうか。

このトークではみなさんがプログラムを実行した時のコンピュータの動作を電気回路から画面表示までに分けて解説します。
このトークを通じてCPUやその他のハードウェア、コンパイラなど「コンピュータの低レイヤ」と言われる領域に興味を持ち語り合える仲間が増えることを期待しています！

2021年6月に出版された「PHPフレームワーク Laravel Webアプリケーション開発 バージョン8.x対応」の11章「テスト駆動開発の実践」を、著者自らデモを交えて解説します。TDDを始めたいけれどどうやって始めたら良いのかわからない、実際にどんな感じになるのか想像ができないのでほんとに意味があるのかわからない、なんか面倒くさそう、など、TDDへの興味はあるけれどなかなか最初の一歩が踏み出せない、という方にぜひ見ていただきたいです。（2018年のPHPカンファレンスでのセッションをブラッシュアップし、2020年代のTDD初心者の皆さまに向けて改めてお送りします）

現在多くのWebサービスではメールアドレスをIDとしてユーザー情報を管理しています。
このようなユーザーを管理するDB設計はWeb開発の基礎とも呼べるもので、多くのWebフレームワークも基本機能として備えています。

このようなサービス運用のためにいくつかの考慮事項があります。

• ユーザーのメールアドレスの入力ミスによる機会逸失を防ぐ
• 特定の条件のユーザーからの登録を阻止する

要約するとたった二点ですが、実際の要件はサービスの運用形態や提供したいユーザー体験に併せて様々に異なってきます。
たとえば、同じユーザーからの複数回の登録を許容しない、特定のドメインからの登録を禁止するなどです。

明確な要件に見えても、現実にはそう単純に実装できない要素がいくつもあります。
メールアドレスや関連仕様、DB製品とCollation、メール配信サービスプロバイダ、ユーザー認証プロバイダなども影響します。

今回のトークではメールバリデーションライブラリの実装を通じて、アカウント管理に必要な観点についてみつめなおしましょう。

昨今ソフトウェア開発においてモデリングの重要性が解かれています。
ですがそれらは業務知識に結びついた話になりやすいです。
対象への理解がないと自分ごととして捉えづらい（ピンと来ない）でしょう。

そこで理解しやすい図形「三角形」を題材にし、共通認識をもったうえでモデリングの練習をしてみましょう。

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

しかしながら、ある程度以上複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあるように思います。

このトークでは、まずはAPI Platformの導入方法から、Data Provider・カスタムコントローラ・Data Persisterといった重要な基本機能の概要までを、実際に動作するデモをお見せしながら丁寧にご紹介し、さらに、よくあるユースケースで必要になるワークアラウンドなど、実戦投入に向けた実装のテクニックをお伝えします。

API Platformの実戦投入、あるいはその検討の一助になれば幸いです！

■ 発表内容
チーム開発に効果的なアジャイルのプラクティスとその実践例を紹介します。

■ ストーリー
「ゴールデンウィーク明けまでにこの機能を作ってほしい」と社内向けの新規機能の開発を任されたとあるチーム。このチームは4月頭に組成されたばかりであり、開発する機能はビジネスの成長ドライバーになることを期待されている。期間は1ヶ月しかない。ただし、その1ヶ月に根拠はない。

チームの構成はプロダクトオーナー1名、エンジニアマネージャー1名、エンジニア6名。不確実性に対処しつつ円滑にリリースを行うべく、アジャイルのプラクティスを実践して開発に立ち向かっている（6月上旬にリリース予定日が立てられて、6月下旬にその日通りにリリースできた）。確かに当初の予定よりは遅れている。

しかし、チームのエンジニアの誰一人として疲弊しきっていない。むしろ、組織の中で偉いAさんは「遅れていても、着実に進んでいることがわかる上に、遅れの理由が納得できるので安心感がある」と言い、スクラムマスターBさんは「このチームではスクラムがうまく回っている。もしそうでなければ、リリースはさらに1ヶ月以上遅れていただろう」と述べている。

なぜそれが可能なのか。何がうまくいっているのか。チームで実践したアジャイルのプラクティスとその実践例を紹介します。

■ 発表内で登場するキーワード（予定）

• DevOps → セキュリティのシフトレフト、トランクベース開発、同期レビュー、継続的なデリバリ
• XP → 全員同席、ペア・モブプログラミング、TDD、インクリメンタルな設計、コードの共有、本物の顧客参加
• スクラム → プロダクトバックログ、プロダクトレビュー
• 実装 → クリーンアーキテクチャ、戦術的DDD
• その他 → 荒ぶる四天王（時間・スコープ・予算・品質）、リファクタリング、イテレーション、フィードバックサイクル