概要

ウェブサイトの「速さ」はLighthouseのスコアだけで決まるものではありません。通信環境やデバイスの制約を超え、フロントエンドの工夫ひとつで「体感速度」は向上させられます

本トークでは、ユーザーの待ち時間をゼロに感じさせるための実装戦略を、「操作前・中・後」という3つのフェーズに分けて紹介します

1. [操作前]先読み：Next.jsやTanStack Queryを用いた、クリック前の予測実行。実験的なWeb APIであるSpeculative Rules APIについて
2. [操作中]段階的表示：初期表示の高速化と、その際に課題となりやすいN+1問題に対するDataLoaderを用いた対策
3. [操作後]楽観的更新：useOptimisticやTanStack DBを活用した、通信待ちを感じさせない書き込み処理

それぞれがどのようなもので具体的にどのように実装すれば良いかついて話します

持ち帰れるもの

• 3つのフェーズ（操作前・中・後）における、体感速度改善を実現する実装イメージ
• 実装コストとUXの向上を天秤にかけるための、状況に応じた高速化手法の選定基準

ソフトウェア開発者の皆さん、上空でのプログラミングに困っていませんか？
飛行中だと、WiFiがなくてChatGPTと繋がらないよ！ (´；ω；｀) みたいなことが起きて困りますよね？

実は、お手持ちのローカル環境で大規模言語モデルを動かす！ という技を使うことで飛行中のプログラミングは解決できるのです！ というのは数年未来のお話です。 現在はまだ実用的ではありません。 しかし、技術的には可能です。 技術的に可能ならやるしかないですよね。
ということで、今回は指定したプロンプトに対して生成された答えを返す、という仕組みをローカル環境で作ってみます。 普段使いのSvelteKitでOllamaを操作し、推しの大規模言語モデルと対話してみませんか？ PHPの活躍にもご期待ください。

※この分野は急速に発展途上中であり、現時点(1月)の内容が発表時の(6月)には、全然そんなことしなくてもよかったのに...となっている可能性もあります。 ご了承ください。

概要

たくさんのアプリで見られる「あなたにおすすめ」という機能は便利なはずですが、時としてユーザーに不気味さや、強引な「押し付け」を感じさせてしまうことがあります。このとき、開発側の意図とユーザーの受け止めの間にある「溝」の正体は何でしょうか。

本トークでは、システム側が一方的に提示しがちな情報を、ユーザーがいかに自分の意志で受け入れ、信頼できるものに変えていくかを考察します。

具体的には、UI/UX設計における「透明性」と「制御権」の2つの観点を深掘りします。メインの題材として、「レコメンドシステム」を取り上げ、有名アプリの事例を引き合いに出しながら、内部ロジックをフロントエンドがいかに「納得感のある体験」として翻訳・実装できるか、具体的なUIパターンを交えて解説します。

持ち帰れるもの

• ユーザーに「操られている感」を与えないための制御権の設計術
• 「なぜそうなったか」を提示し、不信感を払拭する説明可能なUIの設計術

生成AIの普及により、エンジニアはかつてない量のコードを読み、レビューすることが求められています。
これからの時代、コードを「速く」かつ「正確に」読むスキルは、エンジニアの生産性を決定づける最重要能力です。

「速く読むこと」と「正確に読むこと」はトレードオフだと思われがちですが、そうではありません。 読む「目的」に応じてモードを切り替えることで、この2つは両立できます。

本トークでは、シニアエンジニアが経験則として持っている暗黙知を体系化し、コードを「信じる」「疑う」という2つのモードについて、具体的な使用場面を交えて解説します。

認知負荷のハック（信じる技術）： 変数名や構造などの「意図」を信じることで、脳内コンパイルを回避し読む速度を上げる

バグ検知の感度向上（疑う技術）： 「意図（命名）」と「事実（実装）」の乖離に気づくために、入出力やエッジケースを徹底的に疑う

本トークを通じ、ジュニアエンジニアにはコードリーディングの新たな知見を、シニアエンジニアには「なんとなく」読んでいた感覚を言語化するヒントを提供します。

𠮷 ← これは何文字でしょう？
当然、1文字と答えますよね？

では、JavaScriptで'𠮷'.lengthで測りましょうとすると罠に落ちます。
2が返ってくるためです。このときの正しい測り方は何でしょう？

PHPならこんなことにはならないぞ、だってmb_strlenは正しく1を返すぞと反論するとします。
では、 🇯🇵 をmb_strlenで測ってみてください。2と返ってきますよね？
邉󠄀でもいいかもしれません。2と返ってきますね？

本トークでは文字とはなにか、フロントエンドとバックエンドで揃えるときどうするべきか、
そのときに必要になる書記素クラスターの存在を解説していこうとおもいます。

「なぜNginxなどのWebサーバーが必要になるのか」
PHPerが一度は疑問に思うことランキングの上位だと(勝手に)思っています。

このトークでは、NginxになりきってPHPと話してみることで、WebサーバーとPHPがそれぞれ何をやっているのか、を理解することを目指します。

話すこと

• FCGIでPHPと通信し結果を得る方向
• NginxなどのWebサーバーの役割
• 他の言語ではどのようにWebアプリケーションをホストしているのか

他の言語との違いを知ることで、よりPHPの理解を深めることができます。自信を持ってPHPの特徴を説明できるようになりましょう。

基本的な情報

私たちのプロジェクトでは、Lumen FrameworkとCodeception / Specifyを採用していましたが
Codeception / Specify の更新が終了してしまいました。
移行先は pestphp を予定していましたが、１万を超えるテストケースを具体的にどうやって移行するのかが課題になっていました。

これらに、この１年でどう立ち向かったのか、どのように方針転換をしたのかをお話しします。

お品書き

• codeception / specify についての簡単な説明
• 終わりの始まり：テスト用フレームワークの EOL
• Pest への移行
• Rector による置換の試みとその問題点
• 技術の進歩: Agent Skills という光
• まとめ

弊社サービスの検索機能は、検索基盤にAWS OpenSearch Service を利用しており、数百万件規模のデータに対して毎分数千件の検索リクエストが発生します。
現行バージョンのEOL見込みにより移行が必要でしたが、サービス停止時の影響が大きく、アプリケーション側の修正も伴うため低リスクで進める必要がありました。

このトークでは、新クラスターの並走や段階的リリースを活用して安全に切り替え、異常時には即時ロールバックを可能にする手法を解説します。
加えて、 移行する中で顕在化した切替点が分散した設計を、Factory Patternや静的解析などを利用して改善した事例についても紹介します。

Goal

• 本番環境にある検索基盤を低リスクに切り替える
• 切替点を集約し、次回の移行を楽にする設計の型を持ち帰る

Non-Goal

• OpenSearchの機能深掘り

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

技術的負債についての理解が不十分なことから「技術的負債＝悪」というイメージを持ち、無謀なリファクタリングを行う例や、逆に放置しすぎてビジネス面でのリスクが顕在化してしまう例は今なお後を絶ちません。

PHPはその長い歴史から、フロントエンドは流行の移り変わりの速さから技術的負債とは切っても切れない関係にあります。本トークでは「技術的負債とは何か」を言語化した上で、バックエンド・フロントエンドの両方に深く関わってきた経験、さらにAIによって大きく変わりつつある現代の開発環境を踏まえつつ、双方に共通する技術的負債との向き合い方や付き合い方をお伝えします。

Vitestでコンポーネントなどに対してテストを書く際に初学者が躓きやすいAPI通信のモックについて、主要なパターンを3つ紹介します。各パターンのメリット、デメリットを考察し、リファクタリング耐性などの観点についても話します。
また、現在私がVitestにPull Requestを出しているVitest標準のAPIモック機能について、どのような仕組みで実装したのかなどを紹介し、将来デファクトになるかもしれない未来について思いを馳せたいと思います。

再利用性の高いコードを書きたいと考えた結果、
いつの間にか責務が肥大化した「神クラス」を作ってしまった経験はないでしょうか。

多くの場合、その背景には「さまざまなケースに対応できる1つのコード」を作ろうとする考え方があります。
しかし、世の中で再利用されているモノほど小さな目的に特化して作られているという特徴があります。

本セッションでは、
具体的な実装手法や設計パターンを紹介するのではなく、
世の中で再利用されているモノと「神クラス」の違いに着目しながら
「再利用性とは何か」を考え直すことを目的としたセッションです

ifを減らしたい、複雑さを抑えたい、オープン・クローズドの原則に沿った変更に強いコードを書きたい。
しかし「どう設計すれば良いか分からない」と感じたことはないでしょうか。
本セッションはそんなエンジニアに向けた内容です。

分岐が多く保守が辛いコードの多くは、
複雑なロジックを「使う」側で分岐させていることが原因だと考えています。
この設計では機能追加や変更のたびにifが増え、
可読性が低く、テストが辛い、変更に弱いコードになってしまいます。

本セッションでは、
複雑なロジックを「使う」側で分岐するとなぜ辛くなるのか、
「どう使うか」ではなく「どう作るか」で分岐すると、設計がどう変わるのかを整理して解説します。

その上で、「作る」と「使う」を分けることで複雑さを適切な場所に閉じ込め、
オープン・クローズドの原則に沿った変更に強いコードにつながる理由を実践的な題材を通して説明します。

TypeScriptなどを用いた開発の中で、「美しく、保守性の高いコードとは何か」を模索している方は多いのではないでしょうか。
私は業務で先輩エンジニアからコードレビューを受ける中で、その「美しさ」の源泉が関数型プログラミングの考え方に深く根ざしているかもしれない、というお話を聴く機会がありました。「なぜイミュータブルであることが重要なのか」「なぜ関数を最小化すべきなのか」を、概念としてだけでなく「言語仕様レベルで強制される環境」で肌感覚として理解したいと考え、 F#の学習を始めました。
本セッションでは、F#を学ぶことで意識するようになった「所作」や、関数型の思考がなぜ多言語の品質向上に結びつくのかについて吟味し、「綺麗なコードを書きたいけれど、何から学べばいいかわからない」という悩みに対する一つの指針として「他言語学習」の価値と、そこから得られる視点の変化をお伝えできればと思います。

テストコードを書いていれば安心、そう思っていませんか？
プロダクトコードに明らかなバグがあるにもかかわらず、テストが成功を表示し続けることがあります。
これらは開発体験のお邪魔虫に違いないのですが...意図せずこれらを生み出しているかもしれません。
そう、わたしのように...。

このセッションでは「実際の失敗例」を通じてなぜそれが生まれるのか、そしてどうやったらそれが生まれないのかを話します。
昨今ではAIを使ってテストコードを生成することもあるため、生成させるときにどのような点を気に掛ければ良いかについても触れていきます。

テストを書きやすく、かつ壊れやすく（＝正しく失敗するように）するための「テストコードの設計」を追求しましょう!!

話すこと

• わたしの失敗例たち＆どうすればよかったか
• 偽陽性・偽陰性を防ぐテストコード設計
• 良いテストコードを書いてもらうためのAI活用法

ajthinking/archetype というライブラリがあります。
何を持たらすのか？というと、「プログラミングでソースコードを書く」体験です。

PHPのフルスタックFWには、「ボイラープレートベースで、よく使うモジュールのコードを書く」仕組みが備わっている物もあります。
一方、archtypeは、より柔軟かつ詳細な「ソースコードを自動で生み出す」パワーをもらたします。

その裏側にあるのは、「ASTを使い、ソースコードを抽象に扱い生成する」というコンセプト。
単なるテキストベースの雛形を超え、「プログラミングの意味(文法)的に正しい」コード生成をもたらします。

このトークは、「ASTって何？」というメインターゲットを想定し、
「それがどんな物で何を実現するのか」を体感できる15分間にします。

必ず盛り上げます！！！よろしくお願いします！！！