トーク

皆さん、ちょっとしたコードの動作確認をしたい・サクッとRDBを参照/書込する作業をしたい、等の場合に何を使っていますか？

コードを対話式で実行できるREPL(Read Eval Print Loop)は書き捨てのスクリプトを作ったりせずにコードを実行でき、開発を大いに助けてくれます。

PHPではphp -aコマンドで起動されるランタイム同梱のインタラクティブシェルや、より高機能で補完機能やコード実行結果の自動出力機能などを備えたPsySH (bobthecow/psysh)などがあります。

また、laravel/tinkerやcakephp/replなど特定の用途向けに作成されたREPLも存在し、筆者は簡単なRDBの読み書きであればREPLから行うこともあります。
実はそれらのREPLはPsySHをベースとして開発されています。

そんな便利、かつ他のツールの基盤となっているPsySHはPHP製のOSSです。
そう、PHPerが普段使い慣れた言語で作られているのでコードを読めば仕組みがわかります。

この発表では、REPLの基本である「入力の読み取り (Read)」「評価 (Eval)」「出力 (Print)」を軸に、PsySHがどのように実装されているのか・laravel/tinkerなどがどのようにPsySHを拡張しているのかを深掘ります。

• 発表の対象
  • PsySH（やそれを拡張したツール）のREPLとしての機能
• 話さないこと
  • REPL以外の機能 (デバッガ、コマンドライン引数で受け取ったコードの実行など)
• 対象聴衆
  • 普段REPLを使っている人
  • (普段REPLを使っているかどうかは関係なく) REPLの仕組みに興味がある人

DKIM、DMARC、SPF
これらを説明できるでしょうか？

これらの技術はメール認証技術であり、フィッシングやスパムから守るために重要な役割を果たします。
2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。

運用中のPHPアプリケーションに後からCDNを導入する際、特に歴史的な経緯により、複数のカスタムドメインを使用している場合、移行作業には慎重な計画が必要です。このセッションでは、AWSのCloudFrontを例に、複数ドメインを持つ既存アプリケーションにCDNを導入する際のベストプラクティスを解説します。

まず、複数ドメインで運用している環境で効果的なCDN導入が難しい理由を整理します。たとえば、静的リソースのURLがハードコーディングされている場合や、既存のキャッシュ制御ヘッダーが正しく設定されていない場合、移行中にアクセス障害やパフォーマンス劣化を引き起こすリスクがあります。これらの課題を特定し、解決するための準備ステップを紹介します。

次に、CloudFrontを活用して既存のアプリケーションにCDNを導入するプロセスを具体的に解説します。CloudFrontのディストリビューション作成方法、複数ドメインを扱うためのカスタムオリジン設定、HTTPS対応のためのACM（AWS Certificate Manager）の証明書設定について実例を交えて説明します

さらに、移行中の段階的なテスト方法についても触れます。たとえば、特定のリクエストのみCloudFrontを経由させる設定や、デバッグ用にキャッシュを一時的に無効化する方法など、移行時に安全性を確保するためのテクニックを共有します。

このセッションは、複数ドメインで運用中のPHPアプリケーションを対象に、後からCDNを導入する際の手順と注意点をわかりやすく解説します。AWSを活用した実践的なアプローチに興味があるエンジニアの方に、移行作業をスムーズに進めるための知識を提供します。

クラウドネイティブやマイクロサービスアーキテクチャの普及に伴い、アプリケーションは複雑化し、
従来のモニタリング手法では原因特定が困難な障害やパフォーマンス劣化が増えています

こうした状況下で注目されるのがObservability（可観測性）です
Observabilityは、システム内部の状態や相互作用を可視化し、迅速な問題解決や改善策の立案を可能にします

本セッションでは、業界標準化が進むオープンソースプロジェクト「OpenTelemetry」を活用し、
PHPアプリケーションにObservabilityを導入する手順を段階的に解説します
Observabilityの基本概念をMonitoringとの違いを交えつつ明確化し、実際のトラブルシューティングシナリオを示します
これにより「なぜObservabilityが今必要なのか」を理解します
さらに、OpenTelemetry自体が何なのか、その本質と狙いをOpenTelemetryの特徴やコンポーネントをわかりやすく整理します
公式SDKのセットアップ、計測ポイントの挿入、外部サービスとの接続方法をサンプルコードを交えながら示し、PHPアプリへの適用ステップを紹介します

このセッションで参加者が次の開発・運用プロセスでOpenTelemetryを用いてObservabilityを導入できる一歩目を提供します

• 想定する聴講者
  • OpenTelemetryを知らない方
  • OpenTelemetryが何故必要とされているか知らない方
  • OpenTelemetryを利用してみたい方

本セッションではTerminal IDEを、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能をVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
  -Terminal IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング

システム設計における「美しさ」は単なる見た目や感覚の問題ではありません
それは設計を維持し、守り、そして未来へ導くための重要な基盤です
本トークでは「美しさ」を設計の中心に据える意義と、それがアーキテクチャ全体の秩序や一貫性をどのように支えるのかを深掘りします

美しいコードやシステムに触れ、感動を覚えたことはないでしょうか
技巧を凝らしたコードに感嘆し、理路整然としたシステムの完成度に心を打たれた経験があるかもしれません
美しさには人の本能に訴えかける抗いがたい魅力があります
この魅力はアーキテクトが最も大切にする「システムの未来を形作る力」を秘めています

本トークでは以下の内容をお話します

• 美しさの価値：美しさがなぜ有用で、アーキテクトにとって欠かせない要素であるのか
• 審美眼の鍛え方：美しさを見極め、活用するために必要な視点やアプローチ
• 実践的な活用法：美しさを設計プロセスに組み込み、システムの秩序を守るための具体的な方法

対象者:

• システム設計やアーキテクチャに関心のあるエンジニア・リーダー
• 持続可能な設計を目指す方
• チームでの設計文化を改善し、秩序あるアーキテクチャを構築したい方

美しさが設計にもたらす力を探求し、設計の未来を描くインスピレーションを手にしましょう

皆さんはパスキーと聞いて何を思い浮かべますか？
なんか新しいすごいやつ、パスワードがいらないやつ、顔認証するやつ、デバイス間で同期してくれる、公開鍵暗号、チャレンジ………

このトークでは、近年GoogleやGitHubなど主要なWebサービスでも採用されてきている新しいユーザー認証方法「パスキー」に入門します。

• パスキーとは何か
• パスキーで何ができるのか
• なぜパスキーが推されているのか
• 従来のユーザー認証と何が違うのか

などのような基本的な部分から、

• パスキーでログインをするために必要な実装
• パスキーを実装する上での注意点
• パスキーを運用する上での注意点

など発展的な部分まで、一通りパスキーでの認証ができるようになるレベルを網羅します。

このトークがお勧めな人

• パスキーに興味がある人
• ID / パスワードによる認証とさよならしたい人
• よりセキュアなユーザー認証を実現したい人

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

• パスキーの仕組みの理解
• パスキーの実装方法
• パスキーの運用のあれこれ

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれ、多くの人にとって大変で辛い作業と思われがちです。
しかし、サービスの歴史を辿ることで当時の設計思想や変化の過程を知ることができ、それ自体が良い設計を体験し、学べる貴重な機会でもあります。
私の実体験としても20年もの歴史のあるWebサービスの考古学からは学べることがたくさんありました。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤したことをお話しします。

お話すること

• 古いコードベースを読み解き改善を行った事例とその課題
  • Webメディアの広告運用のための管理画面改修
  • 歴史の塊のバッチ処理をPerlからPHPに移行する
• 全体を知るための「鳥の目」と細部を観察するための「虫の目」の考え方
  • 鳥の目で意図や構造を理解する作図ツールなどを使ったコードの読み方
  • 虫の目で詳細を把握するためのデバッグ方法
  • 「どこまで深掘りするか？」の判断基準
• ソフトウェア考古学の経験から学んだこと
  • 理解しやすいコードを書くコツ
    • 自分が書いたコード、その後どうなった？上手く行ったこと、行かなかったこと
  • ソフトウェアの健全な変化を助けるドキュメントとは？

話さないこと

• トークの中で出てくるツール自体の詳細な使い方
• リファクタリングやデータ移行といったソフトウェア改善に伴う手順の詳細

聴いてほしい人

• コードベースが古い環境で悩んでいる人
• 歴史のあるコードを改善したいと思っている人
• プロダクションコードに初めて触れ、規模の大きさや複雑さに圧倒された経験のある新卒の人たち

PHPはCGIからPHP-FPMへと実行環境を移行し、最近ではFrankenPHPが登場しました。
本セッションでは、PHP実行環境の歴史を振り返り、初期のCGIからPHP-FPMへの進化過程を簡潔に解説します。
また、各環境の移り変わりにより、パフォーマンスやスケーラビリティ、セキュリティがどのように改善されてきたのかを具体例を交えて紹介します。
さらに、最新技術として登場したFrankenPHPの誕生背景やアーキテクチャ、特徴を紹介し、PHP-FPMとの比較を通じてそれぞれの利点と欠点を明らかにします。
本セッションを通じて、プロジェクトに最適な実行環境を選択するための基礎知識と視点を提供できれば幸いです。

ソフトウェア開発を行うエンジニアで「『技術的負債』という言葉を知らない」という方は今日においてほとんどいないと思います。その一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くないように思います。その相手が非エンジニアであればなおさらです。

また、技術的負債についての理解が不十分なことによる誤解や偏見も散見されます。例えば「技術的負債＝悪」というイメージから無用・無謀なリファクタリングを行ったり、逆に放置しすぎた結果、ビジネスにおけるリスクが表面化してしまうこともあります。

このトークを通じて技術的負債についての理解を深め、技術的負債とどのように向き合えばよいのか、その具体的なアプローチを考えるきっかけにしていただければと思います。

お話しすること

• 技術的負債とはなにか
• 技術的負債はいつ・どうして生まれるのか
• 技術的負債を放置することで発生するビジネス面・技術面でのリスクとは
• 技術的負債を最小限に抑えるいくつかのテクニック
• 技術的負債とどう付き合っていくべきか