プロポーザル

「CSSが思った通りに動かない」 「とりあえずコピペして、値をいじって直す」
そんな「雰囲気実装」から卒業しませんか？ CSSの挙動はプロパティに使われている英単語の「原義（本来の意味）」を知ることで格段に理解しやすくなります。

例えば、flex-shrinkは「flex（柔軟に）」「Shrink（縮む）」という言葉の意味を知っていれば、「親要素が狭くなった場合はコンテンツを柔軟に縮める設定」だと直感的に理解できます。

本LTでは、CSSの挙動を支配する「10の英単語」を厳選して紹介します。
align, justify, inheritなど英語としてあまり聞きなじみはないのに、ＣＳＳでよく見る英単語の原義をＣＳＳプロパティを踏まえて説明します。
初学者の方にはＣＳＳを理解するきっかけを提供し、ベテランの方にはＣＳＳプロパティを原義から振り返ることができる発表にします。

複数のバリデーションが1つの巨大な関数に詰め込まれ、フラグで状態管理し、UIへの反映と判定ロジックが混在している
そんなコードに出会ったことはありませんか？
この問題を解決するのが「Railway Oriented Programming（ROP）」と「Result型」です。
ROPはエラーをthrowせず「値」として返すことで、副作用のない純粋関数としてバリデーションを記述できます。
fp-tsやneverthrowもありますが、限られたスコープではシンプルな自前実装が「ちょうどいい」選択になることも多いです。
本セッションでは、以下のブログをベースに、ROPの概念と自前実装の設計判断を加えてお話しします。
https://kaminashi-developer.hatenablog.jp/entry/typescript-rop-result-validation-design

ActivityPubの勉強と新しい技術に触れるべく、AIと共に開発をしてみたら、意外と1人OSSを生み出せるという気持ちになりました。
そして生まれたRoxについて、できるまでのところをすこしお話しできたらいいなと思っています。

長期間運用されるプロダクトにおいて、「良かれと思って行った部分的な改善」が、逆にプロジェクトの寿命を縮めることがあります。
本セッションでは、失敗談をベースに、「開発のリズム」を戦略的に維持するための具体的なアプローチを提案します。

過去、レガシーなコードに対し中途半端にモダンな設計を持ち込んだ結果、全体の一貫性が崩壊し、後の全横断的な機能追加を阻害する事態を招きました。
この経験から、リソースが限られた状況下では、「あえてレガシーなリズムに合わせる」ことこそが、全体最適解になり得ると学びました。

局所的な「正しさ」よりも、プロジェクト全体の「ノリ」や「一貫性」を最優先する。そのためにコピペすらも戦略として使いこなす。
「綺麗なコード」ではなく「次に触る人が迷わないコード」を残すために、エンジニアが持つべき「全体調和のための技術的妥協」という選択肢を提示します。

SPAが主流となった現在、フロントエンドは複雑化しがちですが、「HTML-over-the-wire」という別の選択肢があります。
本セッションでは、サーバからHTMLを送信し、最小限のJavaScriptでUXを構築するこのアプローチと、その代表例であるHotwireの思想を紹介します。
HotwireはRails専用の技術と思われがちですが、本質はフレームワーク非依存の設計にあります。
デモではRailsを使用せず、Express.js上でTurboを動作させ、Turbo Drive / Frames / Streamsの仕組みを解説します。
また、SPAとは異なるアーキテクチャであるため、状態管理やCSRF、XSSなどセキュリティにおいて考慮すべき観点も異なる点について触れます。
SPAと比較しながら、HTML-over-the-wireが有効な場面と設計上の判断軸を整理します。

CSSは長らく「見た目を整えるための言語」とされてきました。しかし近年、：has（）、
Container Queries, Popover API, Custom Properties などの登場により、CSSはUIの状態や振る舞いを表現できる言語へと進化しています。
本セッションでは「モダン CSS はJavaScript を置き換えるのか？」という問いを起点に、CSSが実際に置き換え始めている領域と、依然としてJavaScriptが担うべき責務を整理します。
単なる機能紹介にとどまらず、「どこまでをCSSで書き、どこからをJavaScriptに任せるべきか」という設計上の判断基準を、実例を交えて紹介します。

Canvas APIはGoogle SheetsやFigmaなどリッチなWebアプリを支える技術ですが、Reactなどの宣言的UIフレームワークとは設計思想が異なり、組み合わせに悩むポイントが多くあります。
本トークでは、実務でCanvas APIを用いたテーブルUIの開発経験をもとに、以下の内容をお話しします。
・ReactのライフサイクルとCanvas描画の責務分離
・useRefやカスタムフックを活用した設計パターン
・Branded Typeによる座標・サイズの型安全な扱い方

「Reactと組み合わせると設計に迷う」という方に、明日から使える設計指針を持ち帰っていただけるトークを目指します。
https://diggle.engineer/entry/canvas-table
https://diggle.engineer/entry/branded-type