トーク

「本当にやりたい・集中したいビジネス・機能要件に集中する」ための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のケイパビリティとは

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

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

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

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

話すこと

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

主な参考書籍(一部)

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

概要

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

想定する対象者・レベル

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

イントロ

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

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

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

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

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

本セッションで話すこと

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

※こちらのトークは、9/24 Track3 15:15 から、9/25 Track4 13:20に移動しました

私が担当するSaaSプロダクトは15年続くサービスで、メインシステムはいわゆるレガシーシステムになっています。
そんなプロダクトで、新機能実装にあたり新たに小規模なサブシステムを構築することになりました。
メインシステムとはある程度切り離されたシステムなので、せっかくならモダンな技術を存分に取り入れたい！と思いつつも、環境面の制約や既存資産の流用、チームメンバーの学習コストといった課題も考慮しながら技術選定やアーキテクチャ設計を行う必要がありました。
そして検討の結果、既存資産を一部活用しながらも、新規要素としてフレームワークにはSlimを採用し、アーキテクチャはオニオンアーキテクチャ（風のアーキテクチャ）を取り入れることにしました。

このトークでは、Slimを使ったアプリケーション構築の一例として、サブシステム構築時に考慮した技術選定・アーキテクチャ設計のポイントをご紹介します。

コンピューターの処理性能が向上したこと、より大容量で安価なストレージが多く開発されたことにより、大量のデータを活用することが可能になった。
その大量のデータを活用する手段として様々なNoSQLが開発された。
なぜNoSQLが必要なのかを切り口にNoSQLについて色々とお話しします。

話すこと

・NoSQLとは何なのか。なぜ必要なのか。
・NoSQLにはどのような種類のものがあるのか。
・どういう場面で活用すべきなのか。

プログラミングを始めてから、一定のペースで「プログラミング歴」が伸びています。
最初の1年、暫く経った5年、それすらも超えて10年・・・と時間は流れていきますが、それでも変わらないのは「学び続ける課題がある」という事です。
環境の変化も伴いながら、それでも学び続けるのです。
例えば「後輩や部下に対して指導するようになった」とか「マネジメントの仕事が増えて、業務でコードを書く時間や必要性が減った」など。

学習方法や身につけるべきスキル・知識などは千差万別で、一般化して語ることは難しいですが、「いちヒントとして、どのような姿勢で学びを得ていく事が出来そうか」を本セッションで共有します。

参考にしそうな書籍など(仮)

• アプレンティスシップ・パターン
• スーパーエンジニアへの道
• ソフトウェア職人気質
• Clean Craftsmanship
• プログラマが知るべき97のこと

PHPでWebアプリケーションを作る場合はデータをPostgreSQLやMySQLのようなデータベースで管理することが多いと思いますが、
その中で取引記録、センサーから取得したデータ、システムに対する操作といった時系列データを扱いたい場合があります。

しかし時系列データには以下の特徴があり、データベースで扱うことが難しい場合があります。

・時間とともに保存するデータ量が増える
・一日のデータ量が多いかつ保存期間が長い場合はデータ量が膨大になる
・データに対する操作は追記と削除のみで更新は必要ない

リレーショナルデータベースはトランザクション機能や違う種類の入ったテーブルを結合するなど複雑なデータ処理が得意ですが、
トランザクションや結合の必要ないログのようなデータを扱うには機能過多かつデータ量が増えるたびに処理が遅くなると
いった問題があります。

私が開発に参加しているサービスはPHP + PostgreSQLで開発していますが、システムに対する操作をPostgreSQLに保存しています。
通常のユーザの操作では記録されるログの量は多くありませんが、バッチ処理やデータインポートが多い環境では一日あたり数百件
のログが記録される場合があります。

このような環境ではデータベースのサイズの半分以上がログになる場合があり、処理やメンテナンス作業の遅延が発生します。

そのため、このログが増える問題に対してPostgreSQLの拡張機能であるTimeScaleDBで対応できないか検討しました。
TimeScaleDBには時系列データを管理するための以下の機能があります。

・テーブルパーティショニングによる処理の高速化
・一定期間を過ぎたデータの圧縮

また、PostgreSQLの拡張機能であり、既存のSQLをそのまま使えるため、アプリの改修無しで適用することができます。

このセッションではTimeScaleDBの仕組みや適用した場合の効果について検証した結果を紹介します。
時系列データをすでにデータベースで扱っている方や、今後扱う予定がある方の参考になれば幸いです。

PHPerが Serverless を利用してアプリケーションを構築するときに障壁となっているのが、クラウド側のPHPのサポート状況が不明であることと、使い慣れたPHPフレームワークをどのように Serverless でも利用していくかがよくわかっていないこと、という声をよくいただきます。

PHPを AWS Lambda 上で使う方法についてはWEBで調べれば多くのブログがヒットするものの、情報が溢れており様々なやり方がある中で、何がベストなのかを探っていくのは困難な状況になっています。

このセッションではシンプルに Lambda 上で PHP を動かすところから入って、既存のPHPフレームワークをどのように Lambdaの上に乗せていくかまでをお話ししたいと思います。

<想定聴講者>
以下のモチベーションがあるデベロッパー

• PHPをクラウドネイティブで使っていきたい
• モダンなアプリケーションを構築したい
• PHPで培った経験をもとにクラウドでも力を発揮したい

<トーク内容>

• AWS Lambda のおさらい
• Lambdaの上でPHPを動かす
• dockerコンテナを使ったPHPアプリケーションのデプロイ
• Lambdaの上でPHPフレームワークを動かす

ライセンスの都合でローカル環境での開発環境構築が不可能な、CMSに密結合したWebサービス。
CMSの仕様に引っ張られてトリッキーな実装がされることもしばしば…といった状況もありました。

そんなJava製CMSを利用して構築していたサイトを、2年間かけてPHP + Laravel にリプレイスしました。
ソースコード管理もGitで管理でき、EC2で動いていたサイトをDockerを用いてローカルでの開発も同時に実現しています！
ステージ環境やプロダクション環境はAWSサービスである、Fargate、Codeシリーズを活用でき、柔軟にスケーリングできるようになりました。
CMSに密結合していた部分もLaravelに変更することで、モダンなサイト開発体制に近づけることができました。

この発表では、10年以上運営されている大規模な求人サービス「はたらこねっと」でのリプレイスプロジェクトにて、工夫した点や苦労した点についてお話しします。画面は数百単位、PHPのコードだけで数千単位、単体・結合テストの項目数は数万単位のプロダクトです。
コード面やアーキテクチャでの工夫、継続的な開発を意識したCI/CDの活用、監視体制の改善など様々なチャレンジをしながら、リリースを実現しました。
本トークは中〜大規模なサービスリプレイスをお考えのオーディエンスにとって参考になるトークになるものと思います。

またリプレイスや現在の開発・運用も協力会社の方とともにやっています。
大規模なプロダクトなので、参加人数が多くなりチーム体制やマネジメントといったところも試行錯誤しています。
現状の開発体制も踏まえ、協力会社と一緒に開発するという組織づくりやチーム体制についても参考になれば幸いです。

このリプレイスを通して特に活用できた技術は下記です。

• PHP
• Laravel
• PHPInsights
• Docker
• DataDog
• NewRelic
• AWS
  • Fargate
  • CodeBuild
  • CodeDeploy

みなさん、フレームワークや独自実装を用いて、ファイルのアップロードを対応しているプロダクトも多いのではないでしょうか。
実は私は、画像や音楽ファイルを含めたファイルのアップロードが、おそらくプロダクト開発をする上で苦手だなと感じることが多々あります。
「$_FILES を参照するだけでいいじゃん」そう思う人もいると思います。しかし、ファイルのアップロードというのは、より気を使わなければいけないことが多々あります。拡張子だけで、特定のファイル、例えば image.jpg というファイルの中身が png で送られている場合などもあり得ます。これはまだかわいいレベルです。そしてこれよりも悪質なものをアップロードされてくる場合もあり得ます。
以前、PHP を用いたファイルアップローダーサービスを一時的に運営しておりましたが、実装の際に、気をつけていた脆弱性や攻撃などを、フレームワークや独自実装において気をつけるべきアップロードされたファイルへの対応についてお話できればと思います。

スキーマ駆動開発してますか？

一応OpenAPI(Swagger)書いてるけど、実装と乖離して放置されてませか？

レスポンスクラスなどをきれいに書こうとしたものの、データクラスが増えて面倒になっていませんか？

これまで2年以上開発してきた経験から、スキーマ駆動開発の勘所をご紹介します。

正しくOpenAPIを書いて、OpenAPI GeneratorやPostmanを使いこなせば、リクエスト&レスポンスのデータクラスやAPIクライアント、テストコードが自動生成できます。

本トークでは最大限OpenAPIを使い倒して、楽に効率化することを目指します。もちろんスキーマと実装の乖離は絶対におきず、複雑な設定ファイルは必要ありません。

PHPを前提に話しますが、多くの部分は他の言語で応用可能です。結合テストの実行で少しDI（Dependency Injection）が出てきますが、DIの考え方など基礎的な内容に触れません。

■話すこと
・スキーマ駆動開発とはなにか
・スキーマ駆動開発のメリットとデメリット
・OpenAPIとは
・OpenAPI GeneratorでAPIクライアントの自動生成
・スキーマと実装をずれないようにする
・Postman（Newman）で結合テストの自動生成
・DIで副作用を防ぐ

■話さないこと
・OpenAPIの詳しい書き方
・DIの考え方
・DIのライブラリについて
・npmについて

■想定対象者
・スキーマ駆動開発をやってみたい人
・スキーマ駆動開発をしているが、実装がスキーマとズレて困っている人
・APIの結合テストを自動作成したい人

『個人情報漏洩』
おそらく多くの方が経験したくないインシデントのひとつでしょう。そんな個人情報漏洩が起こってしまった後、開発者にはどんな影響があるのでしょうか？
これは1人の開発者が個人情報漏洩事件の後に感じた、開発者への影響と心境の変化のおはなしです。

※個人の感想です
※企業の被害や対策内容についてはお話ししません
※PHPのコードが1行も出てこない可能性があります

みなさんモビングしてますか？
モビング（モブプログラミング、モブプロ）とは複数人でプログラミングを行うことを意味します。
なぜモビングをやるのか？ どうやるのか？ ペアプロとなにが違うのか？ 結局生産性はあがったのか？
ずっとモブプロするのか、ときには並行作業するのか？

マーク・パール著「モブプログラミング・ベストプラクティス 」を実践してみて学んだことをギュッと圧縮してお話しします。

明日から役立つモブプロのエッセンスをお伝えできたら幸いです。

PHP に新機能を追加したい！そう思ったことはありませんか？
もちろん PHP にはそれを実現してくれる Extension の機構がありますが、"言語として必要な機能だから PHP 本体に入れたいんだ！" ということも...

今回は PHP 8.2 に対する Random Extension 5.x を例として、 PHP に新機能を提案・追加するプロセスについてお話します。

※ このセッションは次のロングセッションのプロポーザルから RFC 周りに焦点を絞った短縮版となります
https://fortee.jp/phpcon-2022/proposal/c39b64af-506c-4b05-996c-bdb6df21ddc6