Promiseについて、「分からん！」から「そんなものもあるんだ」を経て、「そういう風になっていて、そう動くのか」に至るためのトークです。
Promises/A+の世界観や、概念レベルの「何を課題とし、どう解決を試みるパターンなのか」の共有から入り、
PHPでの実装例を参考にしながら「こうやるんだね」を見ていきましょう。
最後には、低機能で愚直なPromiseオブジェクトを生み出す所まで話を進めます。

PHPを利用した普段の開発では、 Promise を目にすることはあまり無いかも知れません。
しかし、ライブラリの中身などを読んでいると「意外と出てくるよな」と私は感じました。
guzzlehttp/promisesやreact/promiseといったPHP実装が、しばしば登場します。
コイツと仲良くなれたら、少し幸せになれるのではないか…？と感じたので、解剖してやろうと考えたのです。

特に、「Guzzle使っていてPromiseクラス出てきたけど良くわかんないで雰囲気でやっているなー」という人には役に立つはずです。

概要

Promiseパターンについて興味がある人に向けて、概念の説明とPHPでの実装例を示します

このトークで得られるもの

• Promiseについて知る
• 「PHPでできること」「PHPっぽい実装」について知る

あまり話さないこと

• ライブラリ自体の詳細、活用法

対象とする人

• 「Promiseって聞いたことがある気がするな」レベルの人
• 「ふんわりとは知っているけど、PHPでの実装は考えたことがなかった」という人

おそらく対象外であろうと思われる人

• JavaScriptやPythonなどの他言語で、日常的にPromiseを扱って精通している人

LaravelはWebアプリケーションを簡単に早く作成できる人気のフレームワークの１つです。Laravel本体の機能は非常に充実しており、3rd partyライブラリを使わなくても柔軟な開発ができます。しかしながら、デフォルトの設定や機能だけではLaravelの強みを十分に活かしきれません。例えば、マジックメソッドを多用したフレームワークなため、コア機能だけではEloquentモデルのプロパティやFacadeメソッドのコード補完が効きません。そこで laravel-ide-helper のライブラリを使うと自動生成されたヘルパーファイルによりコード補完が効くようになり、開発効率が上がります。不正なプロパティ・メソッド呼び出しもPHPStan/Larastanなどの静的解析ツールを入れることで事前検知ができ、より堅牢な開発ができます。

本トークではLaravelのアプリケーション開発で入れるべきツールや設定について紹介します。コード補完、静的解析、ロギング、パフォーマンス改善、デバッグ、フロントエンド、フォーマッター、ライブラリの定期アップグレードなど、それらを導入する理由やできることを紹介します。

このトークで紹介するツールや設定により、皆様のLaravelアプリケーション開発がもっと効率的で堅牢で楽しいものになれば幸いです。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

メンター「力がほしいか、、、？」
私「ほしい！」
メンター「ならばLaravelを写経せよ」
私「？？？」

会社のメンターに実力をつけたいと相談したところ、自分の使っている道具を細部まで知ることによって、誰よりも強くなれると教えられました。
幅広く使ってもらうように作るフレームワークとそのフレームワークを使って作る業務に特化したアプリケーションでは、そもそも作るときの思想が違うのでは？と一度は思った私でしたが、そういう言い訳はやってから言わないといけないと思い、素直に写経を行うことにしました。

そこで写経の際にどのような順番で取り組み、その都度どのようなことを考え、そこで学んだこと、そして写経に意味があったのかどうかという、この挑戦の足跡を伝えていきたいと思います。

皆さん、昨年度はどのように成長しましたか？
そして、今年度はどのような成長を計画していますか？

このトークでは、以下の方を対象に

• キャリアに悩んでいるジュニア層の方
• 「伸び悩んでいる」と感じている中堅の方

私自身が学習の速さにおいて一定の成果を上げてきた経験をもとに、次のような内容をお届けします。

• 短期的に素早くキャッチアップするために実践してきた具体的な方法
• 中期的に無駄なく成果を上げるために意識している戦術
• 長期的に自身の価値を高め続けるために考えている戦略

このトークを通じて、皆さんが自身の成長を加速させるためのヒントを得られることを願っています。

PHPのInterface、使っていますか？

このトークでは

• PHPはある程度読み書きできるが、オブジェクト指向や設計パターンに不安がある
• 「抽象に依存する」という考えがいまいち理解できていない
• Interfaceの使い方がいまいち腑に落ちていない

といった方を対象にサンプルコードをによる実践的な使い方を通して、
その根底にある原理原則を解説し、言語機能としてのInterfaceへの理解を深めると共に

• Interfaceがどのような場面で有用なのか？
• 良いインターフェースとはどんなものか？
• なぜInterfaceのような抽象的なものが必要になるのか？

を解説します

Interface、コワクナイヨ！

テストコードを書く中で、「モックとスタブの使い分けが分からない」「どちらを使うべきか迷う」と感じたことはありませんか？その原因は、テストコードの書き方そのものではなく、オブジェクト設計の曖昧さに起因している場合があります。

本トークでは、モックやスタブを「どう使うか」を直接学ぶのではなく、オブジェクト設計のアプローチを通じて、結果として自然に正しい使い分けができる状態を目指します。

具体的には、次のステップを通じてオブジェクト設計を進め、テストコードを構築する方法を解説します：

1. 依存するオブジェクトを明確にする
2. コマンドメソッドとクエリメソッドを明確に分離する
3. システム境界を超えるときにモックやスタブを使用する

これらのステップを経ることで、モックとスタブの選択が「意図した設計の結果」として整理され、テストコードを書く際に迷う必要がなくなる状態になるでしょう。

「ライブラリが古いせいでやりたいことが出来ない」なんて経験はありませんか？

古いライブラリは技術的負債であり、セキュリティリスクにもつながります。
本トークでは定期的なライブラリバージョンアップを続けている実体験をもとに、継続的バージョンアップのメリットや始め方についてお話します。

想定観客

• ライブラリのバージョンが古いせいで苦しんでいるかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

Laravelの魅力の一つであるORM「Eloquent Model」。
雰囲気でも動くものが書けてしまう反面、実は正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのメソッド、返り値nullableにつき
• 全件取得による富豪的プログラミングにご注意
• データベース泣かせのN+1問題
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

スクラム開発において「振り返り」と「スプリントゴール」は、単なるイベント以上の意味を持ちます。これらを形骸化させず、しっかり活用することでチームのパフォーマンスは大きく向上します。

本セッションでは、振り返りを通じて課題を具体的な改善アクションに変える方法や、スプリントゴールを設定する効果を説明します。

これらを実現した現場での成功例や失敗例を交えながら、スクラムの本質的な価値を掘り下げ、明日から実践できる具体的な方法論をお伝えします。スクラム開発を採用してもしていなくても、このセッションを通じてチームの開発プロセスを改善することができるでしょう。

サービスを作る上で、維持費と収益を獲得できるかどうかは、非常に重要な要素です。
StripeのDeveloper Relationsとしてユーザーや社内のプロジェクトに関わった経験と、
前職や個人開発におけるマネタイズに関する経験と想いを元に、ウェブサービスを開発する際のマネタイズ手法や料金モデル、そしてリリース後に発生しがちな請求管理に関するアレコレを紹介します。

トピックの例
・初期フェーズで決済・サブスクリプション機能の開発をやるべきか否か？
・開発工数と売上は比例しない話
・本当にあった、サブスクリプション請求管理で頭が痛くなる話

オブジェクト指向を学ぶ私たちは、必ず一度は「SOLID原則」に触れる機会があると思います。
私も何度も学習を重ねる中で、その原則がもたらす恩恵や、守ることの重要性を徐々に理解してきました。

…ただ、「リスコフの置換原則（LSP）」だけは「これを守るとどう良いのか？」がいまいちしっくりきていませんでした。
「同じ気持ち！」なあなたに向けて、このセッションでは、以下のようなお話をします。

・LSPとは何か？よくある例と「なぜピンとこないのか」
・実際に私が遭遇したLSP違反の具体例
・LSPと"継承"の関係性をしっかりと理解する

「なるほどLSP完全に理解した！」といってもらえるようなトークにします！