トーク

世の中のプロダクトは、二つに大別出来ます。 「ライブラリ・フレームワーク」と「アプリケーション・サービス」 です。

この二つには何の違いがあるのでしょうか？それは、 「インターフェースであるか、ドメインであるか」 です。

一方は多くの開発者に向けて汎用的に作られたもの、もう一方は特定のエンドユーザーに向けて専門的に作られたもの。

この二つの目線を見分けることで、様々な諸問題と正しく向き合うことが出来ます。

このトークでは、インターフェースの目線とドメインの目線、二つの目線で技術に対することで得られるメリットをご紹介します。 「技術的負債」 とは何なのか。 「技術選定」 はどうすればいいのか。 正しい目線で物事を見極めたい あなたに、是非ご覧いただきたいと考えています。

Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

このトークでは

• Interfaceを設計するとはそもそもどういうことか？
• 良いインターフェースの条件
• インターフェース設計の先にあるもの

といった切り口に対して

• サンプルコード
• 有名な設計原則
• 書籍の引用

などを用いながら「良いInterface設計」とその効果について解説します

プログラミングの現場で、顧客の要求する仕様をクラス設計していくと、共通する機能が出てくることがあります。
そこで聞かれる
「共通する機能ってスーパークラスに実装するのと、インターフェースにするの、どっちがいいんですか？」
という疑問。
それにお答えします。
より現場にありそうな問題を取り上げて、ドメイン駆動設計の入り口まで紹介します。。

＜対象者＞
・プログラミングを始めて2，3年以上
・オブジェクト指向でプログラミングをしている
・オブジェクト指向のプログラミングを理解はできるし、自分で書いているが、うまく書けているか自信がない

成長、できていますか？
皆さんは今年どんな成長をし、来年はどんな成長を計画しているのでしょうか？

このトークでは30代半ばでの初めてHello Worldから異業種からの転職を経て、「エンジニアとしての経験年数に対してパフォーマンスが高い」と評価を受けることが多くなった現在まで、「一貫して意識してきたたった１つのこと」についてお話します。

自身のスキルに悩んでいる方、成果を出せるように成長したい方のヒントになれば幸いです

新しく加入したメンバーの皆さん、チームに馴染めていますか？
新しいメンバーを迎えた皆さん、メンバーに馴染めてもらえていますか？

一説によるとWebエンジニアの平均在籍年数はおよそ3〜4年だそうです
ということは、最初の半年〜1年である程度新しいメンバーを戦力化できないと、エージェントに支払う費用などを考えると企業としてはよくてトントン、悪いとマイナスになってしまいます

このトークでは「馴染む速さ」に定評のあるいち個人が最近の転職で経験した

• 「オンボーディングされる側」として意識していたことでうまくいったこと
• 自分が組織に馴染む速さを支えてくれた会社の文化
• 上記を２つを支えていると感じた社内の仕組み

についてお話させていただきます。

採用する側、される側双方にとってのROIの最大化のヒントになれば幸いです

TLS/SSLについて暗号化と証明書のチェックをする程度という理解でも困ることは少ないですが、もう一歩踏み込んでどのようなプロトコルになっているか、公開鍵の署名や共通鍵の暗号はどう選ばれ使われているのか、これらのレイヤーを詳しく見ていくと非常に興味深い世界が広がっています。
このセッションでは、そんなTLS/SSLの内部構造に迫り、技術の楽しさを共に味わいたいと思います。

数ヶ月前の私も、TLSについては漠然とした理解しか持っていませんでした。しかし、PHPでTLS1.2を実装する中でその複雑さが実に面白く、やがて「完全に理解した！」と言える境地にたどり着きました。

本セッションでは次の内容を発表する予定です

• TLSの基礎
• PHPでの実装ポイント
• 車輪の再発明の面白さ

15年間誰も手をつけられなかったレガシーシステムを、どのようにしてバグゼロでリプレースに成功させたのか、その実践的な戦略をお伝えします。
私の考えたオリジナルの手法をはじめ、シャドーテスト、カナリアリリース、ダークローンチ、ランダムテスト、フォールトマスキングなど、多彩な手法を駆使し、リスクを最小限に抑えながら安定したシステム移行を実現しました。
特に、これらのテクニックを組み合わせることで、予期せぬトラブルを未然に防ぎ、計画通りのリプレースを成し遂げたプロセスを詳しく解説します。
他のプロジェクトでも応用可能な、実践的な知見を共有しますので、システム刷新を検討している方にとって必見の内容です。ぜひご参加ください。

弊社M&Aクラウドでは会社や事業を売却したいユーザーと、その会社や事業を買いたいというユーザーがマッチングするプラットフォームを提供しています。
そのシステムでは、マッチングした場合のみに特定の情報が閲覧開示されます。
しかし既存の実装ではほとんどUIに近い層で情報をコントロールしていたためヒヤリとする実装となっていました。
このトークでは情報の開示レベルを制御する設計方法を紹介します。
PHPStanも活用し、コーディングの時点で開発者が迷うことなくオブジェクトを利用できる設計を紹介します。

Doctrineは、Symfonyフレームワークの標準の構成でも採用されているPHP製のORMです。

Laravel全盛の現代、Doctrineには全く馴染みがないという方も多いと思いますが、
いつSymfony案件にアサインされるかもしれません。備えあれば憂いなしです。
それに、普段と異なるパラダイムに触れることは学びの面でもとても有意義だと思います。

この機会にDoctrineを完全にマスターしておきましょう！

このトークでは、

• 「Active Record」と「Data Mapper」の違い
• Doctrineがデータを扱う仕組み（「Doctrineの世界」という感覚）
• エンティティマネージャー、Unit Of Work、リポジトリなどの要素概念

などについて25分で可能な限り詳しく、そして分かりやすく解説します。

SOLID原則の中でも最重要と評されることも多い「依存性逆転の原則」。

• 上位モジュールは下位モジュールに依存してはならない
• 抽象は具象に依存してはならない

という説明は100万回ぐらい聞いたけど、正直いまだにピンと来てない・・・という人も多いのではないでしょうか。

このトークでは、そんな掴みどころがなく理解しにくい「依存性逆転の原則」について、

• 適用する前後の具体的なコードを示しながら
• 適用しないと具体的にどんな問題があるのか
• 適用すると具体的に何がどう嬉しいのか

をとことん分かりやすく解説します！

このトークを聞けば、今まで何となく知識として知っているだけだった「依存性逆転の原則」が、
実際に日々のプログラミングの中で使いこなせる道具に変わるはずです。

乞うご期待！

API Platform は、Web APIの開発に特化したPHP向けのフレームワークです。
エンティティクラスにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう手軽さを持ちながらも、
本格的なWeb APIの開発に必要な機能を幅広く備えており、PHPでWeb APIを開発する際の有力な選択肢の一つとなっています。

このトークでは、API Platformの導入方法から、State Provider・State Processor・OpenAPIドキュメントのカスタマイズといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

ユニットテストにおいて、テストダブルをうまく使うことは必要不可欠です。
しかし、それらの違いや使い分けを誤解していることも多々あります。
PHPUnitでも、モックやスタブを適切に使わないことで、意図が伝わりにくい不明瞭なテストコードが生まれてしまいます。

このセッションでは、具体的な例を交えつつ、PHPUnitにおけるテストダブルの適切な使い分けについて話します。
プロダクトコードだけでなく、テストコードにおいても可読性は大事です。
良いテストコードを書くために、良いテストダブルの使い方を知っていきましょう！！

話すこと
・モックとスタブの違い（基本の部分）
・PHPUnitにおけるテストダブルの使い分け
・使い方が間違っているケース（具体例）

Tests as Documentationという考えがあります
自動化テストは、コードの動かし方と、どう動作するかを示す文書のようにある(べき)です
つまり、他者を意識して何かを伝えるのを助ける存在とも言えるでしょう

もっと言えば、受け取る側と伝える側がいる”Test as Communication"とも呼べそうです
例えば、プルリクエストを送る場面。レビュアーに「伝えるため」のテストになっていますか？
何を理解して欲しいか、どこを気にして欲しいか、そのために何を強調するか──

テストコードを「伝わりやすくする」ため気をつけている事を、 主観や好みや癖を盛り盛りで話します

例

• 一時変数・メモ変数で「名前」を与える
• データプロバイダーをどう使うか
• カスタムアサーションの導入
• 読まなくて良いモノを奥に押し込む

Laravelでbladeを書く際に、 @csrf という「おまじない」を書いた経験が誰しもあるかと思います。
この @csrf は CSRF攻撃を防止するためのものですが、CSRF攻撃とは具体的に何で、@csrfを書くことでLaravelが裏でどのようにCSRF攻撃を防いでいるかを説明できるでしょうか？

このセッションでは、

• CSRF攻撃について改めて復習
• @csrf はなにをしているのか？
• LaravelはどのようにCSRF攻撃を防いでいるのか？

についてお話しできればと思います。

現在時刻に関するテストの話題、よくありますよね。
ユニットテストでは現在時刻に関するテストも可能な設計にしているかと思いますが、
QA環境で、たとえばプロダクトマネージャーやその他企画職の様なエンジニア以外の方が、
未来の日時に始まるキャンペーンをテストしたい場合、どのようにされていますでしょうか？

DBのキャンペーン開始日時のデータをいじる？
　→DBじゃなくてソースコードにハードコーディングされていたら？
ソースコードに書かれている開始日時を修正しちゃう？
　→それもいいけど、間違えてデプロイしない？それに何度もやるのはめんどくさい。

など簡単な手段はありますが、デメリットもあります。

これらのデメリットを解消し、誰でも簡単に現在日時を変更して検証できるようにした（前半は現在時刻に関する一般的な設計テーマ、後半はSymfonyを使った実装アプローチについて）話をしたいと思います。

Webサービスは、検索エンジンのクローラーから脆弱性を狙った攻撃Bot、さらには転売目的の在庫探索Botまで、様々なBotによるアクセスにさらされています。検索エンジンのクローラーはサイトへのアクセス増加というメリットをもたらしますが、その他のBotアクセスはサービスの安定性やセキュリティに深刻なデメリットを引き起こします。
このセッションでは、Pythonを利用した機械学習を用いて、これらのBotアクセスを効率的に判別し、効果的なアクセス制御を実現した事例についてご紹介します。特に、PHPで構築されたWebサービスやWordPressを運用している方にとっては、脆弱性を狙った攻撃からの防御が他人事ではないと感じていることでしょう。
実際のデータを元に、どのようにしてBotアクセスの特徴を捉え、機械学習モデルを用いてこれらのアクセスを分類・制御するかについて、具体的な方法論を紹介します。

ある程度複雑なWebアプリケーション機能を作るとき、ユニットテストを書くべきか、結合テスト（aka 機能テスト, FeatureTest, FunctionalTest）を書くべきか？
カンファレンスに参加する意識の高いPHPerの皆さんは「テストコードがあるだけでありがたい」は平成で卒業して、プロダクションコードだけでなくテストコードも保守しながら持続可能なアプリケーション開発を目指していることと思います。「このクラス、どうテスト書けばいいですかね？モックを使ったユニットテストでも書けるし、DBデータを使ってユニットテストすることもできるし、呼び出し元のコントローラに対するテストでも書けるんですが…」
最近、チームに新しくjoinしたメンバーと議論したのをきっかけに、私が自分なりに定義し直したテストコードの「要はバランス」についてお話しします。

PHP Standards Recommendations 、通称 PSR と呼ばれる、 PHP エコシステムで共通のインターフェースを宣言し、それに準じて実装することで再利用性・可搬性を向上させる施策があります。

その中でも今回は PSR-15 に焦点を当てて、この PSR が 誰のために作られ、どうやって使っていくことが求められているのか をインターフェースから解説していきます。

handle という 1 メソッドだけが宣言されたこのインターフェース、一体どう使えば良いのでしょうか？ PSR-7 に批准していない Laravel(Symfony) ユーザーはどうこれをとらえれば良いのでしょうか？

PSR-15 批准フレームワークを 自作 して得た PSR との向き合い方をご紹介します。

結婚準備クチコミ情報サイト「Wedding Park」は今年でクチコミサービス開始から20周年を迎えたウェブサイト。
このレガシープロダクトでは、幾度もPHPで動くシステムのバージョンアップやシステムリプレイスのプロジェクトが生まれてきました。

・PHPのバージョンアップ
・Laravelフレームワークへのリプレイス
・オンプレサーバからAWSへの移行
・コンテナ化　など

システム運用者として定期的にアップデートしていきたい想いと、長期にわたる大規模プロジェクトとなり頻度高く実施ができない。そんな悩みとぶつかっていました。

その歴史の中で約10年、アプリケーションエンジニアとSRE、各視点で向き合って運用・開発してきた経験を基に、

・これまでのシステム改善の変遷と知見
・運用と開発視点でのプロダクトとの向き合い方
・新たな価値を継続的に提供し続けるための長期計画
をご紹介します。

PHP を書く上で、静的解析ツールは必需品となりました。コードを実行する前に型を解決し、問題を明らかにすることで、開発イテレーションを大きく向上することが可能です。

静的解析ツールはいくつかありますが、その中でも PHPStan は非常に強力なツールとして利用されています。その PHPStan で最も細かく解析してくれる level: max を使うと、 mixed 型や array-shapes を含め 全ての変数に型を明示する必要があります 。

このトークでは、自作 PSR-7 実装を通して、どのようにして level: max な PHPStan で 型安全 に実装するか、そして その費用対効果がどれほどなのか を紹介します。

レベルマックスな PHP ユーザーは一体どうなるのか？解き明かします