トーク

みなさんはDDoS攻撃代行サービスというものが存在することをご存知でしょうか？
DDoS業界は価格破壊が起きており、お手頃に攻撃できる時代となっています。
そんな簡単に攻撃可能な時代に突入しているのであれば、ある日突然あなたが管理しているサーバーが攻撃の標的になってもおかしくはありません。
私は最近までDDoS攻撃は「大量にリクエストが来るヤバイやつ」くらいの認識で正直ナニモワカラナイといった状態だったので、本セッションでは以下のような疑問について発表いたします。

• DDoSとはどんな攻撃で防ぐことは可能なのか？
• F5アタックや金ロー見ながら日本中で唱える滅びの言葉はDDoSなのか？
• Nginx、Lambda、LaravelのRate Limiting設定は意味があるのか？
• CDN、WAFの効果は？
• iptables、セキュリティグループなどのパケットフィルタの効果は？

私はコンピュータサイエンスの学位も海外留学の経験もない普通のエンジニアです。
そんな私が今年6月にLaravelのコアチームに加わり、グローバルなチームのなかで尊敬するメンバーたちと共に日々開発に携わっています。
このセッションでは、私が2014年にLaravelに出会ってからコアチームに加わるまでの経緯や、グローバルなLaravelコミュニティでどのような活動をしてきたか、そしてコアチームに加わってからの活動についてお話しします。
特別な経歴がなくても、行動することで可能性が大きく広がるということを、私の経験を通じてお伝えできればと思います。

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

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

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

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

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

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

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

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

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

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

計算量とは、アルゴリズムが問題を解くために必要とするリソース、特に時間やメモリの量を指します。プログラムはただ動けばいいだけではありません。膨大なデータを扱う現代において、計算量はアルゴリズムのパフォーマンスを左右する重要な要素です。皆さんのコードはどれだけ効率的ですか？計算量の基本から、時間計算量や空間計算量の理解を深めることで、あなたのプログラミングスキルを次のレベルに引き上げましょう！

本トークで話す内容

• 計算量とはなにか？
• 時間計算量、空間計算量
• 実装時に意識すること

例外処理って「エラーをキャッチするもの」と思いがちですよね？
でも、実はもっと重要な役割があります。例外を使うことで「自分のコードがどこまで責任を持つべきか」を明確にし、処理を他に委任することができるんです。

このセッションでは、例外を活用してエラーハンドリングを整理し、過度なキャッチによるコードの複雑化を防ぐ方法をお伝えします。
さらに、フレームワークが担うべき役割や、ビジネスロジックを表現するカスタム例外の作り方も紹介します。

ぜひチームでのディスカッションに活用してみてください！

話すこと

• 例外の型の使い分け
• ビジネスロジックを表現するカスタム例外
• 例外をハンドリングする方法