トーク

動画と連動してプログラムを実行させたいと思ったことはありませんか？
srt.jsは、津田塾大学の栗原一貴教授が開発した、YouTube動画の任意の時間でJavaScriptを実行できるフレームワークです。動画と連動する作品を簡単に創出できます。srt.jsでは、動画に字幕情報を追加するためのSRT形式のファイルに、実行したいJavaScriptコードを書き込みます。動画に合わせてアラートを出したり、WebAPIにアクセスしたり、モータなどの外部デバイスを動かしたりすることができます。テスト用の実行環境が用意されており、ファイルを用意するだけですぐに試すことができます。
LTでは、srt.jsの使い方や活用例を紹介します。動画はもう見るだけではありません！モノと繋がることで五感を刺激する体験を創り出しましょう！

Tanstack Tableは検索、ソート、ページネーション、行・列の選択などが備わったテーブルが簡単に作れるHeadlessなUIライブラリです。

このLTでは、TanStack Tableで作ったテーブルの検索やソートなどの状態をURLパラメータに同期できるライブラリを作った話をします。

以下が話す予定の内容です。

• ライブラリの設計で考えたこと
  • Reactの各種フレームワークで使えるようにするためのURLパラメータとの同期の仕組み
  • 数行で簡単に使い始められる設定の少なさと、細かいカスタマイズ性
• issueから学んだ設計の甘かった部分
• 初めての自作ライブラリでの学びや感想

React用のライブラリの話ですが、Reactを使ったことがない方でも楽しめる内容になる予定です。

フロントエンドエンジニアであれば、 一度は Google Tag Manager（以降、GTM）を利用したことがあるのではないでしょうか。 基本的な使い方はご存じでも 「どのようなユーザー行動を把握したいか」によって、 タグの設計や仕込み方は大きく異なります。 GTMを活用したユーザー行動の分析は、 toC領域における現代のWebフロントエンド開発において欠かせない要素です。

本セッションでは、以下の2点を中心にお話しします。

1. 弊社におけるGTM活用の実例
2. BigQueryに蓄積したデータの活用方法

実際のコード例やBigQueryとの連携を通じて、 フロントエンドエンジニアの視点から、 ユーザーのリアルな行動をどのように捉え、 プロダクトマネージャーと連携しながら活用していけるのかをご紹介します。

パソコンを開いた瞬間、「にゃーん」と鳴くねこちゃんが大量に襲いかかってきたら……。

本セッションでは、そんな“無限増殖ねこちゃん”をJavaScriptで実装する過程を通じて、macOSの自動起動・再起動制御・UI操作をLaunchAgentとJSだけで行う方法を紹介します。

JSだけでOSと仲良くなる方法を、かわいいネコと一緒に学んでいきましょう！

Next.jsの中にHonoを入れてAPIを組んでいたところ、テストのたびにハンドラをMockするのがだんだん面倒に感じてきました。とはいえ、大げさな設計を持ち込むのも違う…。そこで「ちょうどいい依存性注入（DI）」の形を探りながら、Hono側に必要な依存を注入できるようにすることで、無理なくテストを書ける構成を目指しました。

このトークでは、なぜMockがつらいと感じたのか、DIするために工夫したファイル構成や責務の分け方、Next.jsでやる上で気をつけたこと、そして「ここまではやってよかった」「ここはやりすぎだった」といった実感ベースの話を共有します。

HonoをNext.jsで使っている方、テスト設計でモヤモヤしている方、あるいは「ちょっとしたDI」を試してみたい方にとって、肩の力を抜いて聞いていただける内容になればと思います。

Vitestは今やフロントエンド開発に欠かせないテストランナーの一つですが、「モック」機能がどう動いているかを深く知る機会は意外と少ないのでは？
このセッションでは、Vitestがどのように関数やモジュールを“すり替え”、テスト時に挙動を偽装しているのか、その内部のしくみを追いかけます。

ESMの制約、Viteとの連携、vi.mock()がやっている魔法、spyとの違いなどを解き明かしていきます。
「ただの便利なAPI」が、実はどれだけ緻密な仕組みの上に成り立っているのかを一緒に覗いてみませんか？

想定する聴講者
-VitestやJestを普段から使っているが、内部動作までは知らないフロントエンドエンジニア

• テストツールやバンドラの裏側に興味がある方

2021年のMaterial Youやそれに続くMaterial You Expressive、そしてiOS 18のTinted Icon ── モバイルOSはユーザー主導のダイナミックUIへ大きく舵を切っています。生成AIの発展により、インターフェースを個人にパーソナライズさせていく流れは今後も続くでしょう。

一方、Webでは依然としてサービス提供者が決めたある一つのテーマのみが提供されることが多数派です。色覚特性を持つユーザーに向けて最適な配色を提供したり、物語の投稿サイトで文脈に応じた配色を提供したりするなど、クライアント側で自由にテーマを操作できるメリットは十分にあると考えます。

本LTでは生成AIとテーマ生成を組み合わせ、ユーザーの嗜好やWebページのコンテンツに応じて、「LLMでCSS変数の値を生成」というアプローチで、最適な配色やデザインを提供するデモを示します。

「スピナーよりスケルトンスクリーンの方が早く感じる」という体験をしたことはありませんか？
物理的にはスピナーと同等の待機時間でも、ユーザーはスケルトンスクリーンを「より早い」と感じる傾向があります。
この現象は偶然ではなく、人間の認知特性に基づいた心理学的なメカニズムによるものです。
ただし、すべての状況でスケルトンスクリーンが最適というわけではありません。どんな場面で使うべきか、逆に避けるべきかの判断も必要になります。
本LTでは、スケルトンスクリーンが早く感じるメカニズムや、使用する際の留意点についてご紹介します。

ID/パスワードを使わず、指紋や顔認証で安全かつ簡単にログインできる「パスキー認証」は、信頼性の高いFIDO技術を基盤としています。
このパスキー認証をフロントエンドで支えるのが、Web APIの「WebAuthn」です。
WebAuthn自体は数年前から存在する技術ですが、最近ではその利用可否チェックの関数が簡略化されたり、TypeScript 5.8から関連する型定義がサポートされるなど、開発環境が格段に整い、ぐっと利用しやすくなりました。
そして何より、フロントエンド側の実装は思った以上にシンプルです。

本LTでは、WebAuthn APIの実装例と共に「パスキー認証、意外と簡単！」を実感していただくことを目指します。

現代のフロントエンド開発では TypeScript を用いることが多く、開発者は型の恩恵を享受しながら本質的な開発に集中できます。

しかし、REST API を挟んだ「外界」との接続点において「型安全」は必ずしも担保できるわけではなく、仮初めの型定義に頼った開発を余儀なくされる場面も少なくありません。
あるいは、バックエンドから書き出したスキーマから TypeScript 用型定義を生成する手もありますが、開発においてバックエンドが先行する必要があるなどの難点を抱えています。

このトークでは、

• 「REST API 型安全は誰の嬉しさなのか」という原点に立ち返り
• バックエンドと協調しながら双方が嬉しい「API 仕様」の共有を実現する手法について
• 技術面だけでなくドキュメンテーションの観点からも

「REST API 型安全」を考え直すきっかけとなることを期待してお話します。

大規模なNextjsプロジェクトにおいて、一つの修正をした際に「どこに影響が出るのか」を正確に把握することは面倒ですよね？

本トークでは、ts-morphを活用して修正箇所の影響範囲を自動分析・一覧化し、手動でのコード追跡作業を削減します。GitHub Actionsに組み込むことで、PR作成時に影響範囲が自動コメント表示され、レビュアーが影響箇所を意識したレビューができ、PR作成者も想定外の影響箇所に気づけます。開発チーム全体で安心してリファクタリングできる環境を作っていいきましょう！

Reactのアイコンは核反応、Hydrationは直訳すると“水分補給”？

既知の概念にたとえて新しい概念を説明する試みは、アナロジー（類推）という言葉で呼ばれています。
実は、フロントエンド領域では化学実験や物理学に関するアナロジーがしばしば用いられてきました。これらのバックグラウンドを持つエンジニアには直観的な理解の助けとなる一方、英語に非ネイティブな我々の多くにとってはあまりピンと来ていないようです。

学部では工業化学を専攻した発表者が、これらフロントエンドの概念の「元ネタ」を、その背後にあるコンテキストとともに解説します。

この発表を聞いた人は同僚に雑学自慢できるだけでなく、これから新しい概念が登場した時でもスムーズに理解ができるようになるでしょう。

Web上でまるで魔法のようなビジュアル表現を実現したいと思いませんか？
本トークでは、その夢を現実にするWebGLシェーダーの魅力と、その魔法の呪文とも言えるシェーディング言語「GLSL」の面白さをお伝えします。
シェーダーを使えば、従来の常識を超えるインタラクティブなアニメーションや、美しいエフェクトを生み出すことが可能です。
GLSLの数行のコードが驚くようなグラフィックを生み出す様子を、実際のデモを交えながらご紹介します。

「ReactでRPGって作れるの？」そんな思いつきから始まった個人開発プロジェクト『ケイタMAXの冒険』。フロントエンド技術を学ぶ中で、自分自身が一番ワクワクできるアウトプットを作りたいと思い、RPGをNext.jsで作成しました。

本セッションでは、なぜ作成したのか、どんな工夫をしたのか、そしてReactでどのように実装したのかを紹介します。
Cursorを使用しての開発や、PWAとしての配信、Jotaiを使ったステート管理などの開発体験を共有します。

Reactを学習したい方、技術学習を楽しく続けたい方、そしてちょっとRPGが好きな方にも楽しんでもらえる内容です。

使用技術・ツール
• Next.js
• React
• Jotai
• PWA

コードゴルフ大会に参加し、とても楽しかったため、「自分の会社でも実施したい！」と思い立ち、実際に開催しました。結果は大成功で、とても楽しい時間を過ごせたので、その時の話をします。

コードゴルフの内容は、「FizzBuzz」問題や、1時間で解ける程度のの難易度のものを採用しました。言語はTS、PHPを使用しました。

具体的には以下のような内容を話す予定です。

•コードゴルフ大会を実施するにあたって、コードゴルフができるWEBアプリをどのように作成したか
•コードゴルフ大会の雰囲気や参加者からの評判
•参加者たちの感想
•コードゴルフ大会を定期的に開催していることでの社内への影響
•コードゴルフ大会を開催した私自身の感想

皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか？僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。
そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマはReactなど、日々の学びや実践で得た知見です。
「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。

内容
・どんな内容の記事を書いたのか
・毎日投稿して感じたメリット
・デメリットや大変だったこと
・投稿を通して得られた成長
・やってみて感じた素直な感想

アウトプットって実際どうなの？毎日投稿ってどうやるの？といった疑問に、僕なりの答えを届けられたらと思います。
「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！

概要
サービス開発・運用をする上で最早テストは必須と言って過言ではありません。
私は普段業務でエディター開発を行っているのですが、構成の複雑さが相まって気がついたらとある機能が壊れていた・動いていなかった、画像表示のデザインを修正したらそれとは別の画像表示のデザインが崩れていた、といった事態が起こりやすい環境です。
そんな環境でも自分たちにとって安全に、安心してエディター開発ができるよう実装と共にテストの作成を行っています。

本セッションでは、
・VitestとPlaywrightの両方が必要な理由
・実際にテストで担保している機能の例
をベースにどのようにしてエディターの品質を保っているのかを解説します。

内容：React のアップデートを振り返り、現在の開発環境と比較を行う
対象者：初学者、若手フロントエンジニア、中級者

React は 2013 年の登場以来、Web フロントエンドの在り方を大きく変えてきました。
しかし、自分を含めエンジニアを始めた時には既に React が存在し、多くの開発現場で使用されている環境では、React がどのような歴史を辿って今の開発体験が得られたのか知らない方も多いと思っております。
そのため、本セッションでは、React の歴史的なアップデートを振り返りながら今の開発体験がどれほど快適になったかを見ていきたいと思います。

業務で Server Component を使った時にハマったことと解決のために工夫したことを共有します。

(1) Suspense 入れたら Storybook が壊れた
パフォーマンス改善のために suspense を使い始めたら、サーバー専用ライブラリ（ex. Prisma）を使っていたため、Storybook がエラーで起動できなくなった。でもサーバー専用ライブラリを空のモジュールにモックすることで解決！

(1) Server Component でもクライアント側の操作をしないといけない
Server Component として設計したトップレベルのコンポーネントで状態管理が必要になってしまった。 でも Renderless Component を使って状態操作だけを分離することで解決！

これから Server Component 触る皆さんのお役に立てたら嬉しいです！

TypeScript は「構造的型付け（Structural Typing）」を採用していると言われます。
つまり、型に定義されていないプロパティが存在しても、それが使用されなければ基本的にエラーにはなりません。

ですが、そうでもない別の型チェックシステムがあるということみなさんご存知でしょうか？
実は構造的型付けとは異なる文脈で働く TypeScript の型チェックの仕組みが存在します。

オブジェクト型のプロパティがすべて任意の場合弱い型（weak type）のチェックと、
オブジェクトリテラルに型注釈をする場合実行される余剰プロパティチェックがその例です。

今回の LT では このように Typescript の基本思想と違う型チェックシステムを紹介します！
Typescript 型システムへの理解をもっと深められる機会になると思います。