トーク

最近、ぼくはメガベンチャーのプロダクトデザイナー（兼フロントエンドエンジニア）から、
０->1な事業開発を推進するキャリアへ舵を切りましたが、開発に対しての考え方も変わりつつあります。

画面設計、UIコンポーネントの選定はもちろん、品質への考え方、開発スピード、プロジェクトの進め方など...
それらへの思考は、事業ドメインや、事業成長のフェーズによって大きく変化します。

ただ、どのフェーズでも営利活動において、モノづくりをする理由はただ一つ共通しているはずです。
それは「事業・ビジネスに貢献する」ことです。

本トークでは「事業におけるフロントエンドのあり方と考え方」をお話ししようと思います。

趣味サイトくらい
新しく技術を試したいじゃないか

こんなプロトコルでデプロイしよう
HTML のこの要素を試してみよう
CSS はこんなふうに書いたら楽しいな
JS はあの機能が気になってたんだ

そんな夢のような個人サイトを作った話

202X 年になればみんな見れるかな
見れるといいな
ちょっと先取りしすぎたかな

あなたはこのサイト
表示できますか？

事業上の要請で、Webアプリとして提供しているサービスでプッシュ通知等のネイティブ特有機能が必要になり、モバイルアプリ版を新たに出すことはよくあると思います。その場合、フルスクラッチで開発するとめちゃくちゃ大変です。まずは最小限の工数で通知許可率等を計測し、モバイルアプリのポテンシャルを検証したいですよね。

本セッションでは、Capacitorを用いて既存のNext.jsアプリをそのままモバイルアプリとして動かし、プッシュ通知のようなネイティブの機能を利用するまでをステップ・バイ・ステップで解説します。また、このアプローチで700万MAUのサービスを3年間運用した経験を元に、単一のコードベースでWebフロントエンドとモバイルアプリを運用する上でのTipsも紹介します。

Web開発者が事業を前進させる現実的な選択肢としてモバイルアプリ開発を検討するきっかけになれば幸いです。

Viteがいま流行っています。
React系ではRemixが、Vue.js系ではNuxtが、Svelte系ではSvelteKitが、、、Viteを利用しフレームワークを構築しています。

この背景には、esbuildを利用した速さや、ESModulesを活用した開発環境など開発体験に基づく理由も大きいでしょう。
ですが、これ以外にも優れたインターフェイスを備えたプラグインシステムが大きな理由の１つになっていると考えています。

本発表では、Viteとその元になったRollupのプラグインシステムおよび、その優れたインターフェイスを確認し、Viteの優位性を確かめます。

昨今Rust製のツールチェインが流行り、ESLintの代わりにBiomeやOxc(oxlint)を採用するケースも増えているのではないでしょうか。
ですが、これらは未だ独自のカスタムルールを利用することはできません。

対するESLintでは、非常に優れた拡張性を持っています。
中でも no-restricted-syntax というプリセットのルールは、簡単に独自のカスタムルールを作成することが可能です。

本発表では、 no-restricted-syntax を利用した実用的なカスタムルールを作りながら、ESLintの有用性を再確認します。

ブログなどのコンテンツを投稿できるWebサービスを開発する際、コンテンツを編集するためにエディターを開発することがあります。tiptapは、WYSIWYGエディターを開発するためのツールキットです。

このトークでは、Tiptapを使ってエディターの機能を開発する方法と、より高度なAPIであるNode viewsやProseMirror Pluginsを使ってオリジナリティのある機能を開発する方法について話します。

対象者
・ tiptapによるエディター開発の初心者・中級者

フロントエンドで発生したエラーのトラッキングをしたいと思った時、Sentryのようなツールを導入することで解決しようとしている組織は少なくないのではないかと思います。

しかし、エラー監視はどれだけいいツールを使っていたとしても、実際に運用していく体制がずさんではあまり効果を発揮することができないと考えています。

そこで、わたしたちは「cop当番制度」というものを導入することで、エラー監視の負荷が特定のメンバーに集中するといった問題を発生させることなく、レポートされたエラーをしっかりトリアージしきることを実現しています。

本LTではどのようにしてフロントエンドのエラー監視体制を運用しているのか、技術面ではなく運用面にフォーカスしてお話しします。

1つのNext.jsアプリケーション用として運用していたリポジトリをモノレポへ移行した話をします。

プロジェクトごとにリポジトリを分けるポリレポに対して、モノレポでは「プロジェクト間でコードの共通化がしやすい」「プロジェクト間の依存関係が見やすい」といったメリットがあります。
しかし目的の異なるコードベースを1箇所にまとめるためメリットの反面、複雑さが増す部分もあり、例えばCI/CDが遅くなる・余分に実行されるなどの問題が発生しました。

このセッションでは、実際にモノレポへ移行した流れと発生した問題、その解決策をお話しします。

お話しする予定の内容

• pnpm workspaceを使ったモノレポの始め方
• dependenciesの管理方法
• モノレポツールの必要性
• GitHub Actions, Dockerfileの最適化

僕はよく、ソフトウェアから独立したテストを用意します。クライアントサイドのテストを書く時はブラウザテストを書き、サーバーサイドのテストを書く時は fetch もしくは cURL でエンドポイントを叩きます。データベースにテストデータを挿入する際もORMなどを使わずにSQLドライバーそのものを使います。つまり、対象となるソフトウェアについて無知な前提でテストを用意します。

このやり方はライブラリのテスト支援機能を使えないので開発速度は落ちますが、テンプレートを作れば十分にカバーできます。そして何よりも、将来別のライブラリや言語に移行するときに、テストケースをそのまま使いまわせるという利点が生まれます。つまりテストが生きた仕様としてソフトウェアから独立してくれます。

このようにソフトウェアから独立したテストケースを作るテクニックやモチベーションについて、このトークでは話します。

Redux Toolkitは、ステート管理ライブラリであるReduxをより使いこなし、効率的にアプリ開発をするためのライブラリです。

我々のサービスでは、複雑なフォームを提供する画面にReact、ReduxおよびRedux Toolkitを使用していました。
ある時、Redux Toolkitのマイナーバージョンアップを行うと、フォーム入力時の再レンダリングにかかる時間が約4倍になってしまいました。
もちろん、バージョンアップ以外に実装は何も変わっていません。

普通はマイナーバージョンアップでそんな劇的な変化は起こらないはずです。皆さんは、マイナーバージョンアップで何が起こったのか想像できますか？

4月に行われたCloudflareのDeveloper WeekではデータベースやAIの製品発表に隠れるように「JS RPC」という機能が追加されました。JS RPCでは、Cloudflare上のWorkerからWorkerを呼び出すのがRPCで行うことができるようになる。これはセキュリティと開発者体験を向上させます。外部Web APIを叩く時、一般的にはエンドポイントのURLと認証トークンを書きますが、それをRPCで、それもJavaScriptネイティブで呼び出すことができる。CloudflareではD1やR2などのミドルウェアをBindingsという方法で呼びますが、つまりそれを自分で作れる。例えば、Discord APIを呼び出すBindingが作れるし、もしかして、ユーザーが作ったカスタムBindingsが流通するMarketができるかもしれない！そんな楽しい話をします。

最近、テクニカルライターとして Docusaurus と睨めっこしています。
ドキュメントを提供する上で、時にはインターネットにアクセスできないお客様のためにPDF化が必要になります。
Docusaurus には PDF を生成する 3rd party のプラグインもありますが、Docusaurus自体のバージョンアップに追従する難易度や、メンテナビリティを考慮して採用を控えました。
代わりに、E2E テストツールである Playwright を悪用しています。
Playwright にはテストのスナップショットを生成するためにPDFを生成する機能が付いています。
嬉しいことに撮影範囲はセレクタで絞り込めます。
このトークではそのような Playwright の目的外利用をどのように実現したかお話しします。

GraphQLクライアントとして、Apollo Clientを使用している事例は数多くあると思います。
他の有力な候補としてRelayやurqlが挙げられますが、それらと比較した場合、機能面や開発者体験においてApollo Clientが若干遅れを取っている印象がありました。
しかし、直近のApollo Clientのアップデートや周辺ライブラリの進化により、その差はかなり縮まりました。

このトークでは、その変遷を過去3年間の開発における事例を交えながら紹介し、さらに今後の展望についても話します。

具体的には下記の内容を紹介する予定です。

• Apollo Clientについての簡単な説明
• ライブラリ選定と開発スタイルの変遷の事例
  • graphql-anywhere、client-preset、useFragmentなど
• 直近の大幅なアップデートと今後の展望

esbuildやswcの登場を皮切りに、近年のフロントエンドツールはJavaScript（TypeScript）以外の言語で実装されることが増えています。特にRustはゼロコストの抽象化機能を備えており、アルゴリズムの複雑さとメモリ割り当てに気をつけるだけで良く、パーサーやASTを用いた網羅的な実装が頻出するフロントエンドツールの開発に向いていると考えられています。

oxcはハイパフォーマンスなフロントエンドツールのコレクションであり、biomeやrolldown、rspackなどの実装で使用されています。

このセッションでは、oxcがなぜ高性能なのか、その背後にある技術を解説します。また、oxcがフロントエンドツール開発の未来をどのように変えていくか、その可能性についてもestreeなどの既存技術との比較を通して探ります。

storybookをベースにVisual regression testやアクセシビリティーのテストができるらしい！
ぜひやりたいが手元にはSPAではなくtemplate engineベースのMPAしかない！そんな時に役立つテクニックをご紹介します。

近年、フロントエンドにおいて、Rust製のツールが増えてきました
一方で、フロントエンドエンジニアの多くはJavaScriptやTypeScriptが中心で、Rustはあまり馴染みがないのが現状です
私自身、スクリプト言語を中心に使ってきた普通のWebエンジニアですが、フロントエンドツールチェインをより深く理解し、パフォーマンス改善やOSS貢献ができるようになりたいと考え、Rustの学習を始めました
簡単なCLIツールを作成したり、普段Node.jsで書いているような処理をRustで置き換えたりすることで、少しずつ言語に馴染んでいきました
このトークでは、私の入門の過程をご紹介しながら、Rustを学ぶメリットについて考察します
Rustに興味はあるけれどまだ始められていない方にとって、入門のきっかけになれば幸いです

昨年度、弊社では新規プロダクトの開発プロジェクトがスタートしました。
その際、技術スタックの変更—Vue.jsからReact(Next.js)への変更を決定しました。
しかし、Reactに関する実務経験があるメンバーは社内におらず、専任のデザイナーも不在であるという二重の課題に直面しました。

そのような状況下で約1年間のプロジェクトをどのように進め、完遂させたのかを共有します。
・設計(コンポーネント設計)
・開発フロー(デザインチェック)
を中心に、下記記事[1]をよりパワーアップさせ、プロジェクトで得られた知見を詳細にお話しさせていただきます。

特にスタートアップや新規事業を担当するスモールチームに関わる方にとって、
開発プロセスの改善や技術選定の参考になれば幸いです。

[1]https://zenn.dev/recustomer/articles/9c50a5c21f3000

ここ数年、新卒研修でWebプログラミング講師を担当しています。
研修は受講者の経験レベルもバラバラで時間も限られますが、実施するからには次のことを学んで欲しいと思いました。

• ブラウザはアクセスしたURL以外にも、タグに書かれているURLにアクセスする
• サーバーは特定のパスに該当するアセットやデータを返す
• ヘッダーフィールドはTCPの上でHTTP通信を実現するためにとても重要
• サーバーは動的なページを返せる

これらをなるべくWebの仕様そのものに沿って教えるとなった時に、Rubyが適していることに気づきました。
RubyはTCP通信や動的HTML生成を標準ライブラリだけで素直に実装可能で、HTTPはリクエストラインから仕様通りに書き下せて、Macに最初から入っています。
このトークではRubyを使ってWebの基礎を学ぶのにちょうど良いサーバーを作るところをお見せします。

みなさんはブロックチェーンアプリケーションを開発したことがありますか？
おそらく開発したことがない方が大部分だと思います。

ブロックチェーンと言うと投資や投機、ファイナンス領域で使うものでは？
スマートコントラクトとかブロックチェーン特有の概念が多くて難しいのでは？
特にブロックチェーンである必要がないんだけど？

などなど、いろいろ思って手を出さない領域だと思います。とてもわかります。
ただ、それはとても勿体無いです。特にフロントエンド開発においてはデータの保存先の選択肢が1つ増えるので、一度は触って知って欲しい領域です。

そこで、本セッションではSolanaというチェーンを題材に、チェーンの概要、扱うメリット、開発するときの注意点などをもとに、ブロックチェーンアプリケーションの楽しさ、魅力を紹介します。

2023年の12月、『timer.team』というWebアプリをリリースしました。開発にはTypeScriptを採用し、ランタイムとしてDenoを、フロントエンドフレームワークとしてFreshを選択しました。開発記録をまとめた記事[1]には注目が集まり、Zennのトレンドにも掲載されました。

本発表では、Denoのエコシステムを活用した開発の具体例を踏まえて、Freshの選択により大きなメリットを享受したことを示します。また、Deno Deploy上での実際の運用事例、BroadcastChannelからDeno KV watch API [2]へのリプレース結果など、Zennの記事のその後についても発表します。

[1] https://zenn.dev/lef237/articles/8e4eb3112928d6
[2] https://deno.com/blog/kv-watch