トーク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

※ このトークはリモート登壇になります

みなさんはWeb Assembly はご存知でしょうか？
ブラウザで利用するケースはもちろんのこと、最近ではサーバーレスアプリケーションで活用できるようになってきました。

このトークではPHPとWeb Assemblyに関連するエコシステムの紹介と可能ならデモも紹介します。

trait は当初 2008 年に PHP の言語開発者コミュニティへ提案され、長い議論期間を経て 2012 年リリースの PHP 5.4 で導入された機能です。
それから 10 年がたち、trait は「ちょっと試しに使ってみよう」というものから、各開発現場において使われる中で少しずつその立場を変えてきました。

さて、実際どのように変わったのでしょうか？

先日、今年に出る PHP 8.2 へ向けて言語機能追加の RFC を提出しました。PHP の trait で定数を定義できるようにするというものです。
静かな議論期間を経ての RFC の投票開始後、PHP の開発者向けメーリングリストから最初に得られたのは驚くべきリアクションで、要約すると次のようになります。

「trait は言語にとってまったく不要なものであり、使われるべきでないものを改善すべきではない」

続々と RFC に No の票を投じる人が現れ、一時は Yes が 3 票に No が 10 票というような圧倒的劣勢の局面を迎えます。

さて、なぜこのようなことになったのでしょうか？
何がこの 10 年で trait をこうも徹底的に嫌われる言語機能としてしまったのでしょうか？

このトークでは PHP によってプログラム部品を構成する言語機能としての trait に焦点をあて、来歴とその性質、適切な使いどころと、他の言語機能とくらべての弱点を紹介します。そして trait 定数の RFC が結局どのような顛末を迎えたのかを踏まえて、trait の将来の可能性について検討します。

なおトークの本題は言語機能としての trait の性質についてで、trait 定数の RFC 自体については「なぜこの話を今するのか」の舞台設定として早口で触れるくらいとする予定です。

※ ちなみに trait 定数の RFC の投票結果が出るのは PHP カンファレンス 2022 のトーク募集締切から 3 日後で、このトーク概要を書いている時点ではまだ確定していません

『ウマ娘 プリティーダービー』は、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の概要を知っていただき、少しでも興味を持っていただければ幸いです！

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュート（アノテーション）を1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、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を利用したマイページ実装方法

決済と検索を数回のAPIコールで手軽に実装・連携させる方法を紹介します。

Stripeには、販売する商品や提供するサービス・サブスクリプションの情報をストアすることができます。
また、2022年にリリースされたSearch APIを利用して、商品データの検索が可能です。
しかし大規模なEコマースサービスやCtoCのマーケットプレイスなどでは、
商品価格を上限・下限で指定するなど、複雑な検索が求められます。

このトークでは、Stripeに登録したデータをWebhook経由で全文検索FaaSのAlgoliaに同期し、
Algoliaを利用した検索システムを顧客に提供する方法を紹介します。

◆現在予定しているトピック（変更する可能性があります）
・AlgoliaにStripeの商品・料金データをインデックスさせる方法
・Algolia Instantsearch.jsを利用した検索UIの作成方法
・検索結果とStripeの決済ページやカート機能と連携させる方法

オンラインサービスに欠かせない、課金・請求システムのTipsを紹介します。

Laravelを利用してアプリケーションを開発している場合、
Cashierを利用することで、Stripeを使ったオンライン決済機能を組み込むことができます。
また、AWSやGCPなどのクラウドサービスは、
作成したアプリケーションを複数の環境・用途にデプロイする作業を効率化します。

このトークでは、「Laravel Cashierを利用したStripeの決済組み込み方法」についてと、
「AWS App Runnerへのデプロイ方法」の２つを簡単に紹介します。

現在予定しているトピック（変更する可能性があります）
・Laravel Cashierのセットアップ
・Stripeアカウントでやっておきたい設定
・Stripeの便利機能をCashierまたはStripe APIから使う方法
・AWS App RunnerへのLaravelアプリケーションデプロイ
・AWSからStripeを利用する際のTips

現在私が所属するGrowfit株式会社ではLaravelで作られたStraym(ストレイム)というアート作品のオーナー権販売サービスの開発・運用を請け負っています。

自分が参画したのは2020年頃で、コードを見たところルールや方針もあまりなく、技術的な負債に対してあまり改善ができていない状況でした。
すぐにでも改善したいところですが、開発体制はCTO+私の2名(たまに助っ人)体制で新機能開発/保守運用の全てを行っており、かつ成長途中のプロダクトということもあり新機能開発が最優先で負債を解消していく時間を別途確保するのは難しい状況でした。

それでも負債をそのまま放置せず、機能開発と並行しながら負債と向き合い、少しづつではありますが継続してリファクタリングを行うことで保守性の向上に努めています。

この発表では、参画してからの2年で行ってきた少人数チームでの負債との向き合い方や実際の取り組みについてお話しします。

弊社の運営しているサービスに、フィーチャートグルを導入して約１年が経過しました。
15年以上の歴史を持つこのサービスは、テストも無く、独自フレームワークで書かれたレガシーコードとなっています。そのため１年前までは、一つの機能追加に大きく時間を費やしてしまっていました。
そこに導入されたフィーチャートグルは、必要最低限の質素な実装でしたが、リリースまでの時間は大幅に減少させ、開発速度を大きく向上させました。
そこから１年経過した今、脱レガシーに向かう新しいコードに合わせて、フィーチャートグル自体の実装も少しずつ変更を加えてきました。

本トークでは、レガシーコードにフィーチャートグルを導入して得た効果や、導入から現在に至るまでの実装をご紹介します。

話すこと

• 弊社サービスにおけるフィーチャートグルを導入した効果
• フィーチャートグルの導入〜現在に至るまでの実装
• 導入後にテストを可能にするための改善

話さないこと

• 自分が経験していない事（他社の導入事例など）
• ライブラリの紹介

アプリケーションを安定的に運用していくには、安定した実行基盤を構成する必要があります。
プラットフォームの選択肢として Microsoft Azure というクラウドをオススメしたいです。

「PHPとAzure」についての情報はそれほど多くないため、親和性はあまり良くないんじゃない？と思う人もいるかもしれません。
しかし現在の Azure は様々なサービスが提供されており、PHP 製のアプリケーションでも PHP を普段使っているエンジニアでも、様々なシーンで Azure を利用することができます。
PaaS (Platform as a Service) を中心としたアーキテクチャーを構成することで、運用の作業負荷を軽減し、エンジニアが本来の役割や作業に専念するための環境を作ることができます。

アーキテクト（アーキテクチャーを考える人）やアプリケーション開発者を対象に、Azure で実現するクラウドアーキテクチャーについて紹介するセッションを行います。

【取り上げる予定のキーワード】
パブリッククラウド、Microsoft Azure、PaaS、GitHub、コンテナー、CI/CD、サーバーレス、DevOps、NoSQL、開発環境

※こちらのトークは、リモート登壇になります。

想定課題

開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。
そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。
その際にこのようなことを言われがちではないでしょうか？

• 今動いているものを直す必要ある？
• 効果測定どうやんの？
• 費用対効果はどれくらい？

パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。

本セッションの目標

以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。

• State of DevOpsとは
• Four Keysとは
• 27のケイパビリティとは

私は普段、CakePHP2をCakePHP4にバージョンアップする仕事をしています。
その中で得られたCakePHP4を利用した開発におけるモダンなテクニックについてご紹介します。

皆さんはコードを読む時の工夫って、どんなものがありますか？
私は「脳内にスタックトレースを溜めておくの大変だぜ〜、すぐ混乱するぜ〜」となるので、その辺りは便利な道具で補いたいなあと思っています。

ここ暫くは、デジタルホワイトボードツールのMiroというサービスがお気に入りでして、ある時に「これは自分の思考を整理したらアイディアを繋ぎ止めておく時に使うツール・・・という事は！何かの複雑なコードを読む時にも、大活躍してくれるのでは！？」と閃きました。

実際に使ってみると、とても良かったのです。

本トークでは、実際にどんな風に使ったの？どう便利だったかな？？を、体験談を盛り込みながらお話します。
複雑なコードや難しいソフトウェアも、これで少しは読みやすくなるかもです。

ソフトウェア開発、色々な場面で人とのコラボレーションを求められがちですよね？
例えば、アジャイル系のフレームワークやプラクティスを採用している・していないに関わらず、ふりかえり(retrospective)を行っているチームは増えてきていると思います。
それ以外にも、チームビルディングの場面だったり、プロダクト開発のためのブレインストーミング、もしくはポストモーテムにおいても参加者それぞれの視点が出揃うことが求められます。

理想的なのは、そこにいる全員が同一の目的を持って主体的な意思表示と議論に参加できている状態です。
そのために、場をファシリテーションする人には「発散」と「収束」を効果的に行うことが求められます。
しかしながら、単純に意見を求めるだけでは達成が困難な事も多いです。その壁を破るためには工夫や知見が必要になります。

どのようにしたら、参加者に思考を促し、高いレベルでのコラボレーションが実現されるでしょうか。
思考を促進するための接し方として、「問いかけ」や「発問」と呼ばれるものがあります。
ファシリテーターが、これらの概念や観点・技法を自らの引き出しに入れておくことで、今までとは少し違った議論が生まれるかも知れません。

本セッションでは、テクニックと態度の両面から「どのように場を回す工夫をするか」を共有します。

話すこと

• 参加者の主体性を引き出すための会議の基本設計
• 「問いかけ」とは何か
• 創発的な場作りのためのいくつかの工夫、引き出し

主な参考書籍(一部)

• 問いのデザイン / 問いかけの作法
• ファシリテーター完全教本
• ゲームストーミング
• アジャイルレトロスペクティブズ
• 会議のマネジメント

概要

• xUnit Test Patternsって、どんな本なの？どんな事が分かるの？を紹介します

想定する対象者・レベル

• ユニットテストを書いているけど自信がない/しっかり勉強したことがないかも・・という人
• その本の名前は聞いたことがあるけど、実物は見たことがない・読んだことがないぜ・・という人
• 「良いテスト」あるいは「テストを書く時に考えるべきこと」を言語化したい、理論を身につける術を探している・・という人

イントロ

現代的な開発において「テスト」は欠かせません。
そして、「ソフトウェアテスト」あるいはその中の「自動化テスト」といっても、それぞれに様々な手法や戦略、ねらいと目的、それらを実現するためのツールなどがあります。

その中でも、普段の開発において、我々のような開発者・プログラマーにとって最もなじみ深いのは「ユニットテスト」ではないでしょうか。
この分野における古典的ともいえる名著の一つに、「xUnit Test Patterns(xUTP)」があります。名前だけは聞いたことがある・・という人も沢山いるかと思います。
一体どんな本なのでしょう？内容が気になるものの・・・気軽に手を出すには、分量的にも価格的にも重い一冊と言えます。

読んだ方が良いぞ！！！と思っていても、未読のままの人も多いのではないでしょうか。
重い本を読むための勢いが欲しいですよね。
まずは、「どんな事が書かれているのか」「(頑張って読むことで)どんな知識を得られそうなのか」という期待値設定のための案内があれば嬉しい・・・と思いませんか？
本セッションは、そんなガイドとなるべく、「xUTPの入り口まで近づいて見てみる」をテーマに話をします。
xUTPが、テストに強くなりたいあなたの味方になるかも知れません！！

本セッションで得られること・ゴール

• 「有名だけど読んだことがないメッチャ重そうなあの本」について、内容を把握できる
• それによって、今の自分に必要か？が想像できるようになる

本セッションで話すこと

• xUnit Test Patternsとはどんな本なのか
• 各パート・各章にはどんなことが書かれているのか
• 書名にもなっている「パターン」は、どんなものが書かれているのか
  • サンプル的にいくつかのパターンの紹介
• どんな時に読むと良いか。どんな使い方をすると良さそうか

Circle CI, Travis CI, GitHub Actions, AppVeyor, ...
いろんなCIツールが存在していますが、皆さんはどれがお好きですか？

私の担当するSaaSプロダクトでは、もともとJenkinsでCIを動かしていました。
しかし、CIの活用を拡大していくにあたり、GitLabとの連携や設定の管理といった点で課題が出てきました。そこで、そうした課題をクリアすべくGitLab CIに乗り換えることを決断しました。

このLTでは、GitLab CIを選択した理由、移行を進める上でのポイントについてお話しします。