学ぶ、考える、書き出す。

Web Speed Hackathon 2026参加記

2026-03-30T12:00:00.000Z

3月20日から21日にかけて開催されたWeb Speed Hackathon 2026に参加しました。

結果は 764.80 / 1150点 で、issueに記録された時点では暫定32位（132人中）になりました。最終計測で自己最高スコアを出せました。

ただし、レギュレーション違反によりランキングから除外されてしまいました。レギュレーション違反していなければ5位になれていた可能性があったんですけどね。トホホ〜。

どこでレギュレーション違反になったか

違反の原因は、ユーザープロフィールのヘッダー背景色が初期状態と異なっていたことです。

UserProfileHeader.tsx でプロフィール画像の平均色をTailwindの動的クラス bg-[${averageColor}] として適用していましたが、@tailwindcss/browser（ランタイム）を @tailwindcss/postcss（ビルド時コンパイル）に置き換えたタイミングで、動的に組み立てたクラスが検出できなくなっていたことに気づけませんでした。

ビルド時コンパイルに置き換えるなら style={{ backgroundColor: averageColor }} のようにインラインスタイルに切り替える必要がありました（averageColor 自体は useState() で管理されています）。

とはいえレギュレーションに即しているかどうかを判定してもらえる点数を超えることはできたので、そこに至るまでの道のりを書きます。

スコアを伸ばした段階

今回スコアを伸ばした段階は大きく3つあります。

1日目 18:08時点「219 → 498.75点」

初期ロードに関わる改善をまとめてデプロイした結果です。積み上げた改善によってユーザーフローをテストする閾値（300点）を超えました。

1日目 18:57時点「498.75 → 576.6点」

FFmpeg/ImageMagick WASMのdynamic importを実施し、数十MB単位でバンドルファイルを初期読み込みから除外したのと、ReDoSの修正を入れました。

1日目 22:26時点「576.6 → 750.85点」

GIF→MP4変換（TBT 6.7s→2.5s）、波形データの事前計算によるAudioContextデコード排除（TBT 2.5s→49ms）、JPEG→AVIF変換+リサイズ（画像容量93%削減、LCP 42s→7.3s）が中心です。

とりあえずこの3つをやった上で、より改善を積み重ねつつ、テストも継続的に実行して、レギュレーション違反しないかが重要です。それは毎年変わらないですね。

リポジトリのクローン

まずリポジトリをクローンしてきたときに、リポジトリのサイズがおかしそうなことに気づきました。412個のオブジェクトに対して407.12 MiBは大きく感じます。

remote: Enumerating objects: 412, done.
remote: Total 412 (delta 0), reused 0 (delta 0), pack-reused 412 (from 1)
Receiving objects: 100% (412/412), 407.12 MiB | 9.07 MiB/s, done.
Resolving deltas: 100% (39/39), done.
Updating files: 100% (354/354), done.

これは後述しますが、シードデータのメディアファイルが合計334MBあり、これがリポジトリサイズの大半を占めていました。内訳は以下の通りで、GIFとJPEG形式のファイルが入っていて、まずここが最適化できそうということが分かります。

動画（GIF）179MB
画像（JPEG）89MB
音声（MP3）66MB

初期状態のアプリケーションをデプロイする

スコア計測はアプリケーションをデプロイしないことには始まりません。

しかし、運営が用意したfly.ioの環境は競技開始直後に認証周りで問題があって、ちょっとの間デプロイすることができなかったのと、自前の環境のほうが問題は少なくなりそうだったので、早々にfly.ioアカウントを作ってそこにデプロイすることを決めました。

fly apps create {アプリ名} でアプリを作成し、fly deploy --app {アプリ名} でデプロイしました。特に詰まることなくデプロイできたので良かったです。

Lighthouse CIによる継続的パフォーマンス観測をする

最適化の効果を定量的に追跡するため、Lighthouse CIを導入しました。

ローカルで実行するために @lhci/cli をdevDependencyに追加し、pnpm lighthouse でローカルサーバーに対してLighthouse CIを実行できるようにしました。

# application/ でサーバー起動後
pnpm lighthouse

改善施策の実装前後でこれを実行して、ターゲットのメトリクスが実際に改善したか確認していました。

また、特定のページだけ計測したい場合に備えて lighthouse:page スクリプトを用意し、--collect.url でURLを渡して個別に計測できるようにしました。

# ホームページだけ計測（1回実行）
pnpm lighthouse:page -- --collect.url="http://localhost:3000/"

# 検索ページだけ計測
pnpm lighthouse:page -- --collect.url="http://localhost:3000/search"

ただ今回に関しては公式のscoring-toolが提供されていたため、これを実行すれば良かったです。ここはなぜか見落とした私のミスです。

パフォーマンス改善サイクルを自動で回す

パフォーマンス改善の進め方として「仮説→計測→変更→計測」のサイクルをClaude Codeのルールにして、このサイクルが自動で回せるようにしていました。

ルール化したことによって、Claude Code上で「この部分が遅くなってそう」とプロンプトを投げて、それに基づきClaude Codeが「何が遅いか、なぜ遅いか、どのメトリクスに反映されるか」といった仮説を立て、Lighthouse CIによる計測で裏付けてから変更を入れた後にもう一度計測をして、ターゲットのメトリクスが改善しなければrevertするフローが割と自動化できました。

ここまでやったところで、パフォーマンス改善をやっていきます。

バンドルサイズ分析

webpack-bundle-analyzerでバンドル構成を可視化して main.js が108MBという異常なサイズであることが分かりました。

サイズの大きい順に以下の通りです。

FFmpeg WASM (ffmpeg-core.wasm?binary)：動画処理用
ImageMagick WASM (magick.wasm?binary)：画像処理用
@mlc-ai/web-llm：AI推論エンジン
negaposi-analyzer-ja (pn_ja.dic.json）：感情分析辞書
highlight.js / refractor：シンタックスハイライト（全言語入り）
kuromoji / katex：重量級ライブラリ群
moment / lodash / jquery / core-js / bluebird：現代基準でいらないライブラリ

Webpack→Rspackへ移行し、複数の問題をいっぺんに解消する

Webpackの設定も問題が多かったです。一部を紹介すると以下の通りです。

mode: "none"：minification無効
optimization.minimize: false：圧縮無効
optimization.splitChunks: false：コード分割無効

問題は他にもありますが、こういった問題を1つずつ直すより、Rspackに移行して設定をいい感じにするのが手っ取り早いと判断し、Rspackに移行したのち設定をいい感じにしました。

Rspack移行後に変えた設定は以下の通りです。

builtin:swc-loader の使用
mode: "production" への移行
splitChunks: { chunks: "all" } でコード分割
devtool: false でソースマップをバンドルから除外
エントリーポイントから core-js, regenerator-runtime を除去
CSSは CssExtractRspackPlugin + css-loader + postcss-loader
HtmlRspackPlugin で inject: true にしてJS/CSSを自動的に注入

これによる結果は以下の通りになりました。

ビルド時間：15秒以上 → 0.9秒
エントリーポイント合計：108MB → 12.3MB
- FFmpegやImageMagickは別バンドルとして出力されるようになった

初回スコア計測

ここまでやった段階でスコア計測をして、以下の結果になりました。

テスト項目	CLS (25)	合計 (100)
ホームを開く	20.75	20.75
投稿詳細ページを開く	25.00	25.00
写真つき投稿詳細ページを開く	24.75	24.75
動画つき投稿詳細ページを開く	23.50	23.50
音声つき投稿詳細ページを開く	25.00	25.00
検索ページを開く	25.00	25.00
DM一覧ページを開く	25.00	25.00
DM詳細ページを開く	25.00	25.00
利用規約ページを開く	25.00	25.00

合わせて219点でした。ユーザーフローテストは通常テストのスコアが300点未満だと計測されない仕様で、まずは300点を超えるのが最初の目標という感じです。

Phase 1: 219→498点

サーバーのgzip圧縮

サーバー側でレスポンスの圧縮が一切入っていなかったので、Expressに compression ミドルウェアを追加してgzipによる圧縮を有効化しました。

+import compression from "compression";
 import Express from "express";

 export const app = Express();

 app.set("trust proxy", true);

+app.use(compression());
 app.use(sessionMiddleware);

ついでにレスポンスヘッダーを確認したところ、全レスポンスに付与されていたヘッダーにも罠がありました。

-app.use((_req, res, next) => {
-  res.header({
-    "Cache-Control": "max-age=0, no-transform",
-    Connection: "close",
-  });
-  return next();
-});

no-transform: プロキシやCDNによる変換の無効化
max-age=0: ブラウザーキャッシュの無効化
Connection: close: HTTP Keep-Aliveの無効化

3つとも意図的な妨害コードで、レスポンスデータの容量を増やしたりリクエストを無駄に飛ばしたりする効果があるので丸ごと消しました。

静的ファイルのcontenthashと長期キャッシュ

アセット類をキャッシュしようとして、Rspackの出力ファイル名にハッシュが付いていないことに気づきました。内容が変わったときにキャッシュが無効化されるよう [contenthash] を追加して長期キャッシュを使えるようにしました。

// rspack.config.js
output: {
  filename: "scripts/[name]-[contenthash].js",
  chunkFilename: "scripts/chunk-[contenthash].js",
},
// CssExtractRspackPlugin
{ filename: "styles/[name]-[contenthash].css" }

そしてルーター側で /scripts, /styles, /assets に対し Cache-Control: public, max-age=31536000, immutable を設定しました。

// routes/static.ts
staticRouter.use('/scripts', (_req, res, next) => {
  res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');
  next();
});

認証が必要なAPIレスポンスと、ハッシュを付けなかった静的ファイル（index.htmlなど）にはキャッシュヘッダーを付けていません。

InfiniteScrollの不要な繰り返し判定の除去

InfiniteScroll コンポーネントで、スクロール位置が最下部に到達したかの判定を2 ** 18回繰り返していました。

「念の為」というコメントが付いていましたが、window.innerHeight + Math.ceil(window.scrollY) >= document.body.offsetHeight は同一イベントハンドラ内では毎回同じ値を返す純粋な比較式で繰り返す意味がありません。

この判定は scroll, wheel, touchmove, resize の4イベントすべてで発火するため、スクロールするたびに約26万回のDOM参照と配列生成が走り、TBTを悪化させていました。

- // 念の為 2の18乗 回、最下部かどうかを確認する
- const hasReached = Array.from(Array(2 ** 18), () => {
-   return window.innerHeight + Math.ceil(window.scrollY) >= document.body.offsetHeight;
- }).every(Boolean);
+ const hasReached = window.innerHeight + Math.ceil(window.scrollY) >= document.body.offsetHeight;

この実装は以前のWeb Speed Hackathonでもあったので、早めに「念の」でgrepしていました。こんなキーワードでgrepするのはWeb Speed Hackathonくらいな気がします。

Reactマウントのloadイベント待ち除去

index.tsx を見ると、window.addEventListener("load", ...) の中でReactをマウントしていました。

loadイベントは全リソースの読み込み完了後に発火するため、バンドルファイルのダウンロード＋パースが終わるまで描画が一切始まりません。

-window.addEventListener("load", () => {
-  createRoot(document.getElementById("app")!).render(
-    <Provider store={store}>
-      <BrowserRouter>
-        <AppContainer />
-      </BrowserRouter>
-    </Provider>,
-  );
-});
+createRoot(document.getElementById("app")!).render(
+  <Provider store={store}>
+    <BrowserRouter>
+      <AppContainer />
+    </BrowserRouter>
+  </Provider>,
+);

Tailwind CSSのビルド時コンパイル

index.html で @tailwindcss/browser@4.2.1 をCDNから同期スクリプトとして読み込み、ブラウザー内でCSSをコンパイルしている構成でした。

外部スクリプトのダウンロード＋パース＋CSSコンパイルで描画をブロックするので、@tailwindcss/postcss を導入して、ビルド時にCSSを生成するように変更しました。

そしてここまで変更をおこなったところで、ようやくパフォーマンス計測を行いました。結果は以下の通りです。

ビルド時コンパイル化後の計測結果（ホーム画面）:

指標	Before	After
Performance	0.17	0.15
FCP	0.36	0.47
LCP	0	0
CLS	0.53	0.40
render-blocking-resources	2件	1件
unused-javascript	2件	1件

FCPが0.36→0.47に改善しました。Performanceスコア自体は0.15に下がっていますが、個別のメトリクスが改善（FCP +0.11、CLS +0.13）していたので、改善を適用した状態にしました。

結果的にこの変更がレギュレーション違反の原因になるわけですが、当時の自分は気づいていませんでした。

ルートベースのコード分割

全ルートのコンテナコンポーネントが AppContainer.tsx に静的importされており、巨大な単一バンドル（なんと12MB！）になっていました。

ホーム画面の表示に不要な /crok（web-llm, katex, react-syntax-highlighter）やNewPostModal（含むFFmpegとImageMagick）まで全て初期ロードに含まれている状態だったので、React.lazy + Suspense で全ルートコンテナとモーダルを遅延読み込みに変更しました。

const TimelineContainer = lazy(() => import('@web-speed-hackathon-2026/client/src/containers/TimelineContainer'));
// ... 他のルートも同様

<Suspense>
  <Routes>
    <Route element={<TimelineContainer />} path="/" />
    {/* ... */}
  </Routes>
</Suspense>;

コード分割後の計測結果（ホーム画面）:

指標	Before	After
Performance	0.15	0.23
FCP	0.47	≥0.9 (warning消失)
render-blocking-resources	1件	0件 (warning消失)

main.jsが12.3MiB→462KiB（96%削減）となり、FCPが大幅改善してwarningの閾値以下になりました。

CoveredImageをネイティブ`<img>`に置換

CoveredImage コンポーネントを調べると、画像表示のために毎回 jQuery.ajax でバイナリをフェッチし、image-sizeでサイズ計算、piexifjsでEXIF抽出、Blob URL生成という重い処理を踏んでいました。これらは <img> + object-fit: cover に置き換えれば全部不要になります。

EXIFからのalt取得は「ALTを表示する」ボタン押下時のみ動的にインポートして実行するように変更し、loading 属性をpropsに追加した上で、ファーストビューに入る画像のみ eager、それ以外は lazy に設定しました。

<img alt="" className="h-full w-full object-cover" loading={loading} src={src} />

置換後の計測結果（ホーム画面）:

指標	Before	After
Performance	0.23	0.23
offscreen-images	28件	1件
uses-responsive-images	47件	34件
lcp-lazy-loaded	-	解消

Performanceスコアは変わっていませんが、offscreen-imagesが28→1件に減りました。画像がJS経由ではなくブラウザーネイティブで読み込まれるようになった効果です。

jQuery → native fetchへの置換

fetchers.ts を見ると、全HTTPリクエストを $.ajax({ async: false }) で実行していました。async: false は同期XHRなのでリクエスト中メインスレッドがブロックされます。これをネイティブの fetch APIに置き換えました。

置き換え後に気づいたこととして、fetchers.ts 内のFetch APIラッパーである sendJSON がリクエストボディをgzip圧縮した上で Content-Encoding: gzip ヘッダーを付けてリクエストしようとしたときに、Fetch APIを使うとDM送信と投稿が失敗していました。

Constructing a Response with Content-Encoding? · Issue #589 · whatwg/fetchで書かれていますが、ブラウザー（Chrome）側でレスポンスデータは自動解凍してくれるにも関わらず、リクエスト時には自動圧縮してくれないという一貫性のなさがあるようです。

とはいえRequest時に Content-Encoding を付けることは比較的まれという記述もissueにあって、実際に私もRspack設定内の ProvidePlugin から $ と window.jQuery を削除することで問題がなくなりました。

Fetch API置換後の計測結果（ホーム画面）:

指標	Before	After
エントリーポイント	462 KiB	377 KiB
deprecations failure	あり	解消
charset failure	あり	解消

エントリポイントが85KiB縮小し、jQuery由来の非推奨API warningも解消されました。

web-llmのdynamic import化

TranslatableText コンポーネントが createTranslator をstatic importしていた影響で、依存していた @mlc-ai/web-llmがタイムラインのチャンクに存在していました。翻訳機能はユーザーが「Show Translation」ボタンを押した時のみ使われるため、クリック時にdynamic importするよう変更しました。

dynamic import後の計測結果（ホーム画面）：

指標	Before	After
Performance	0.20	0.24

web-llmがタイムラインのチャンクから分離され、ホーム画面の初期ロードに含まれなくなったことでパフォーマンスの値が上がりました。

momentの除去

複数のコンポーネントで日付フォーマットに momentが使われていましたが、使い方を調べたところ3パターンしかありませんでした。

moment(date).locale("ja").format("LL") →「2026年3月20日」
moment(date).locale("ja").fromNow() →「3時間前」
moment(date).locale("ja").format("HH:mm") →「17:30」

なので Intl.DateTimeFormat と Intl.RelativeTimeFormat で置き換えて、momentの依存をなくしました。

ただ相対的に他と比較してパッケージサイズが小さいため、パフォーマンス改善にはつながりませんでした。

Phase 2: 498→576点

ReDoS脆弱性の修正

クライアント側の正規表現を調べたところ、3箇所にReDoS（Regular Expression Denial of Service）パターンが仕込まれていました。いずれもネスト量指定子によって指数関数的にバックトラッキングが増えていました。

auth/validation.ts：/^(?:[^\P{Letter}&&\P{Number}]*){16,}$/v → /^[\p{Letter}\p{Number}]*$/v（パスワードの記号チェック）
search/services.ts：/since:((\d|\d\d|\d\d\d\d-\d\d-\d\d)+)+$/ → /since:(\d{4}-\d{2}-\d{2})$/（日付抽出）
search/services.ts：/^(\d+)+-(\d+)+-(\d+)+$/ → /^\d+-\d+-\d+$/（日付形式判定。変数名が slowDateLike だった）

ReDoSはユーザー入力時（フォームバリデーション）で発火するため、ユーザーフローテストのINP/TBTで効果が出ました。

Phase 3: 576→750点

動画のGIF→MP4変換

メディアファイルの最適化に着手しました。最初にリポジトリを取得したときにデータ容量が大きいことには気づいていたので、ここを改善することで各種指標が上がりそうという肌感がありました。

まずは動画です。動画は全てGIF形式で保存されていて、15ファイルで合計179MBとなっていました。

GIFは PausableMovie コンポーネントでfetchした後 gifler + omggif でフレーム単位にデコードしてcanvasへ描画する実装になっていて、メインスレッドでのデコード処理がTBTを悪化させていました。

そのため、まずはシードGIFをFFmpeg CLIでMP4 (H.264) に事前変換するスクリプトを作成して、動画をMP4形式にしました。

# `-movflags +faststart` オプションを追加して、moov atomをファイル先頭に配置し、ダウンロード完了前からストリーミング再生できるようにした
ffmpeg -i "$gif" \
  -c:v libx264 \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -an \
  -loglevel warning \
  "$mp4"

また PausableMovie コンポーネントをネイティブのvideo要素に置き換えて gifler, omggif の依存を削除しました。

<video ref={videoRef} autoPlay className="w-full" loop muted playsInline src={src} />

その他にソースコード内で点在した拡張子を変えることで、GIFからMP4へ置き換えられました。

GIF→MP4変換後の計測結果（ホーム画面）：

指標	Before	After
Performance	0.22	0.25
LCP	147s	43s
TBT	6.7s	2.5s
SI	3.4s	0.55s

TBTが6.7s→2.5sに大幅改善しました。gifler/omggifによるフレーム単位のデコードがなくなり、指標改善に寄与しました。LCPも147s→43sに短縮しましたが、とはいえまだまだパフォーマンス改善の余地がありすぎる状態です。

また動画のファイルサイズも元のGIFが合わせて179MBあったところ、73MBまで減りました。

音声の波形事前計算とビットレート削減

次に音声の最適化です。SoundPlayer コンポーネントがMP3ファイル全体を取得した後に、SoundWaveSVG がArrayBufferをAudioContextを使ってデコードし波形データを作成するための計算をしていました。この一連の処理がメインスレッドをブロックしていて、TBTの悪化原因になっていました。

これを解消するため、FFmpegでMP3をPCM（signed 16-bit LE, stereo）へデコードした上で、左右チャンネルの平均を取って100チャンクへ分割し、各チャンクの平均値を事前にJSONへ保存するようにしました。

SoundWaveSVG はAudioContextの decodeAudioData と lodash による波形計算を丸ごと消して、事前計算済みの波形JSONを fetchJSON で取得する形に変更しました。

SoundPlayer もArrayBufferへの読み込みとBlobURL生成（useFetch + fetchBinary）をやめて <audio src> に音声ファイルのパスを直接渡す形にして、lodash と standardized-audio-context の依存を無くしました。

MP3のビットレートもSNS用途としては高かったため、128kbpsに再エンコードし直すことで総容量を66MBから38MBに削減しました。

波形事前計算後の計測結果（ホーム画面）：

指標	Before	After
Performance	0.25	0.56
TBT	2.5s	49ms
SI	550ms	501ms
LCP	43s	42s
total-byte-weight	106MB	79MB

TBTが2.5s→49msに改善しました。

AudioContextによるデコードを排除したことで、メインスレッドのブロックがほぼなくなっています。Performanceスコアも0.25→0.56に上がり、いくつかやった改善の中でも特に大きな変化となりました。

音声投稿の個別ページでもTBTが448ms→0msになりました。

画像のAVIF変換とリサイズ

最後に画像です。画像は全てJPEGで配信されているかつ、ページ内で使われるサイズに対して解像度が高すぎたことから、なんらかの最適化をする必要があることは自明でした。

ここではAVIFを選択しました。WebPより圧縮効率が高い点と2024年1月時点でBaselineのNewly availableに達している点が判断材料です。

sharpを使って、投稿画像をメインコンテンツの最大幅である1280px、プロフィール画像を256pxへリサイズしつつ、AVIF (quality 75) へ変換するスクリプトを作り、ソースコード内の拡張子を .jpg → .avif へ変更して、元のJPEGファイルを削除しました。

// 投稿画像は最大幅1280px、プロフィール画像は256px（128px × 2 for Retina）
await sharp(inputPath).resize({ width: maxWidth, withoutEnlargement: true }).avif({ quality: 75 }).toFile(outputPath);

AVIF変換後の計測結果（ホーム画面）：

指標	Before	After
Performance	0.56	0.56
LCP	42s	7.3s
total-byte-weight	79MB	35MB
TBT	49ms	0ms

AVIF変換後の計測結果（画像投稿ページ）：

指標	Before	After
Performance	0.73	0.96
LCP	12.7s	1.0s

投稿画像は86MB→6.1MBで93%の削減、プロフィール画像は3.2MB→416KBで87%の削減となりました。また、画像投稿ページのLCPが12.7s→1.0sになり、Performanceスコアが0.96に到達しました。

メディアのキャッシュヘッダーとcompression除外

メディアファイル（/images, /movies, /sounds）に Cache-Control ヘッダーが付いておらず、serve-static のデフォルト max-age=0 が適用されていました。さらにAVIF/MP4/MP3のような圧縮済みバイナリにも compression がgzipをかけようとしていたので、キャッシュ設定の追加とcompression除外の両方を対応しました。

メディアパスに Cache-Control: public, max-age=86400 を設定し、compression ミドルウェアのfilterでメディアパスを除外しました。serve-static のデフォルト max-age=0 がミドルウェアで設定したヘッダーを上書きしていたので、cacheControl: false も必要でした。

// static.ts
for (const path of ['/images', '/movies', '/sounds']) {
  staticRouter.use(path, (_req, res, next) => {
    res.setHeader('Cache-Control', 'public, max-age=86400');
    next();
  });
}

キャッシュヘッダー設定後の計測結果（ホーム画面）：

指標	Before	After
Performance	0.56	0.56
LCP	7.3s	7.3s
TBT	0ms	0ms

Lighthouseの単発計測ではスコアが変わりません。キャッシュは2回目以降のナビゲーションで効果が出るため、初回アクセスのみを計測するLighthouseでは差が出にくいです。

画像ALTテキストのEXIF往復を廃止

手動テスト項目に「画像のEXIFに埋め込まれたImage DescriptionがALTとして表示されること」という要件がありました。調査の結果、既存の実装は以下の流れでした。

クライアント：WASM版ImageMagickで画像を変換し、img.comment からEXIFのImageDescriptionを取得
クライアント：piexifjsでJPEGのEXIFにImageDescriptionを書き戻し
サーバー：JPEGバイナリをファイルとして保存
表示時：CoveredImage が画像バイナリ全体を再取得し、piexifjsでEXIFを読み取り

alt用のテキストをバイナリメタデータとして往復させている流れです。convertImage の中で img.comment からalt用テキストは取得済みですが、EXIFに書き込んで、アップロードして、また取り出すということをしていました。

なので、altをデータベースに保存した上で文字列として取得する方式に変更しました。

元のJPEGからpiexifjsで全ImageDescriptionを抽出し、images.jsonl に書き込んで seed:insert でSQLiteに反映
convertImage の戻り値を Blob → { blob, alt } に変更。img.comment からaltを取得し、piexifjsによるEXIF書き込みを削除
NewPostModalPage で変換結果のaltを保持し、NewPostModalContainer の sendNewPost で images: [{ id, alt }] として POST /api/v1/posts に送信
サーバー側は Post.create の include: images でImageレコードを作成して、altをDBに保存
CoveredImage はpropsで alt を受け取り、APIレスポンスの値を直接表示。バイナリfetchとEXIFパースを削除

Phase 4: 750点以降

AspectRatioBox を CSS aspect-ratio に置き換え

AspectRatioBox コンポーネントは、JSで clientWidth を読み取り setTimeout(500ms) 後に高さを計算して setState する実装でした。これにより初回レンダリングから500ミリ秒の間、コンテンツが非表示になるとともに、高さが0から計算値に変わるタイミングでLayout Shiftが発生していました。

これをCSSの aspect-ratio プロパティに置き換えることで、CLSを解消するとともに無駄な遅延をなくしました。

// Before: JS で高さを計算、500ms 遅延、resize リスナー付き
<AspectRatioBox aspectHeight={9} aspectWidth={16}>
  <div>...</div>
</AspectRatioBox>

// After: CSS aspect-ratio で即座にサイズ確定
<div className="w-full" style={{ aspectRatio: "16 / 9" }}>
  <div>...</div>
</div>

aspect-ratio 置き換え後の計測結果：

ページ	CLS before	CLS after	Score before	Score after
`/`	0.433	0.029	0.56	0.75
`/posts/fe6712a1...` (画像投稿)	0.098	0.004	0.94	0.96
`/posts/fff790f5...` (動画投稿)	0.199	0.099	0.66	0.73
`/posts/fefe75bd...` (音声投稿)	0.006	0.000	1.0	1.0

フォントの最適化（OTF → サブセット woff2 + font-display: swap）

利用規約ページで使用されるカスタムフォント「Rei no Are Mincho」がOTF形式（各6.3MB）で配信され、font-display: block が指定されていました。フォント読み込み完了までテキストが非表示になるのでLCPに直接影響しています。

これは以下の修正をすることでフォントファイルのサイズを100KB前後にしました。

TermPageで実際に使われている471文字だけに絞ったサブセットフォントを生成（pyftsubset）
OTF → woff2に変換

またフォントの表示方法を font-display: block → font-display: swap に変更しています。

なお、最初はフォントをwoff2形式に変換しただけで、サブセット化まではやっていなかったですが、これによりLCPが645ms → 3,645msに悪化していました。

原因は font-display: swap によりフォールバックフォントで即座にテキストが描画され（FCP）、カスタムフォントがダウンロードされた後の再描画がLCPとして計測されたためで、これによりサブセット化も実施することを決めました。

利用規約ページの計測結果：

指標	Before	After
FCP	204ms	206ms
LCP	645ms	730ms
SI	204ms	206ms
CLS	0.018	0.019
Score	100	100

タイマー系サボタージュコードの除去

setTimeout / setInterval の使用箇所を調査したところ、パフォーマンスに悪影響を与えている箇所が3つ見つかりました。

DirectMessagePage の setInterval → ResizeObserver

DMページで setInterval(..., 1) を実行し、その中で getComputedStyle を1ms間隔で呼び続けている箇所がありました。強制リフローが連続発生するのでTBT/INPに悪影響があります。

useEffect(() => {
  const id = setInterval(() => {
    const height = Number(window.getComputedStyle(document.body).height.replace('px', ''));
    if (height !== scrollHeightRef.current) {
      scrollHeightRef.current = height;
      window.scrollTo(0, height);
    }
  }, 1);
  return () => clearInterval(id);
}, []);

これを ResizeObserver に置き換えました。ResizeObserver はブラウザーのレイアウト処理完了後にコールバックが呼ばれるため getComputedStyle のような強制reflowを引き起こしません。

useEffect(() => {
  const observer = new ResizeObserver(() => {
    const height = document.body.scrollHeight;
    if (height !== scrollHeightRef.current) {
      scrollHeightRef.current = height;
      window.scrollTo(0, height);
    }
  });
  observer.observe(document.body);
  return () => observer.disconnect();
}, []);

crok SSE の 3秒 sleep 削除

/api/v1/crok のSSEレスポンス開始前に await sleep(3000) がありました。AIチャットの応答開始を3秒遅延させる意図的なサボタージュコードだったので削除しました。

crok SSE の sleep 削除

さらに1文字ずつSSE送信する際にも await sleep(10) が入っていました。sleep(10) を削除し、sleep 関数自体も除去しました。

1文字ずつイベントとして送信する構造は維持しており、Node.jsのI/Oバッファリングによりクライアント側ではストリーミング表示として見えると判断しました。

不要ポリフィル・レガシーコードの除去

bluebird、lodash、buffer polyfillの3つがクライアントバンドルに残っていたので除去しました。

ポリフィル除去後の計測結果（ホーム画面）：

指標	Before	After
Performance	0.75	0.76
SI	497ms	325ms

ホーム画面におけるLCPの画像をpreloadで読み込む

ホーム画面のLCPが3.8秒で、内訳を見るとLoad Delay（ブラウザーが画像を発見するまでの遅延）が3.308sかかっていました。

SPAアーキテクチャでJS実行→API→Reactによる描画という直列のチェーンを経て初めて <img> タグがDOMに挿入されるのが原因でした。

なので、サーバー側でHTMLを返す際にDBから最初の画像付き投稿を取得し、<link rel="preload" as="image"> を <head> へ注入するようにしました。

// application/server/src/routes/static.ts
staticRouter.get('/', async (_req, res, next) => {
  const posts = await Post.findAll({ limit: 10, offset: 0 });
  const firstPostWithImage = posts.find((p) => p.images?.length > 0);
  const firstImageId = firstPostWithImage?.images?.[0]?.id;
  // index.htmlの<head>に <link rel="preload" as="image" href="/images/{id}.avif"> を注入
});

改善後の計測結果（ホーム画面）：

指標	Before	After
LCP	3.8s	3.4s
Load Delay	3,308ms (87%)	0ms (0%)
Render Delay	339ms (9%)	3,326ms (96%)

Load Delayは解消し、LCPも改善はされましたが、Render Delayにボトルネックが移動するだけになって、あまり効果はなかったです。

useInfiniteFetchのサーバー側pagination対応

useInfiniteFetch フックを調べると、API呼び出しのたびに全件取得してクライアント側で slice していました。

APIは limit/offset パラメータに対応しているのにクライアントが使っていなかったので、サーバー側paginationに変更しました。

// Before: 毎回全件取得してクライアントでslice
void fetcher(apiPath).then((allData) => {
  data: [...cur.data, ...allData.slice(offset, offset + LIMIT)],
});

// After: サーバー側paginationで必要分だけ取得
const paginatedPath = `${apiPath}?limit=${LIMIT}&offset=${offset}`;
void fetcher(paginatedPath).then((pageData) => {
  data: [...cur.data, ...pageData],
});

改善後の計測結果（ホーム画面）：

指標	Before	After
LCP	3.4s	3.4s
Render Delay	3,326ms	3,205ms
Performanceスコア	81	82

思ったより効果は小さいですが、全ページで不要なデータ転送を削減する修正になるはずだったのでそのままにしました。

Font Awesome SVG sprite の軽量化

Font AwesomeのSVGスプライトファイルにすべてのアイコンが入っていて無駄だったので削減しました。合計で約1.2MBから8.6KBになりましたが、この変更がパフォーマンス改善に直接は効きませんでした。

ファイル	Before	After	備考
solid.svg	639KB (1002アイコン)	7.4KB (17アイコン)	使用アイコンのみ抽出
regular.svg	107KB (458アイコン)	1.2KB (1アイコン)	calendar-altのみ使用
brands.svg	458KB (458アイコン)	削除	コード中で未参照

最終計測

ここまで書いたことや、書いていない細かい修正もやった上で、競技終了8分前の18時22分に計測をしてスコアが 764.80点 となりました。詳細は以下の通りです。

テスト項目	CLS (25)	FCP (10)	LCP (25)	SI (10)	TBT (30)	合計 (100)
ホームを開く	25.00	8.00	8.75	3.20	0.00	44.95
投稿詳細ページを開く	25.00	8.80	17.00	8.40	29.40	88.60
写真つき投稿詳細ページを開く	25.00	9.20	17.75	9.20	29.70	90.85
動画つき投稿詳細ページを開く	25.00	9.20	17.75	8.70	23.10	83.75
音声つき投稿詳細ページを開く	25.00	9.30	17.75	9.80	30.00	91.85
検索ページを開く	25.00	8.90	0.75	9.40	8.10	52.15
DM一覧ページを開く	25.00	8.80	16.00	6.90	23.70	80.40
DM詳細ページを開く	25.00	9.10	13.00	5.40	0.00	52.50
利用規約ページを開く	25.00	9.20	19.25	9.20	8.10	70.75

ユーザーフローテスト	INP (25)	TBT (25)	合計 (50)
ユーザー登録→サインアウト→サインイン	25.00	9.00	34.00
DM送信	-	-	計測できません
検索→結果表示	25.00	25.00	50.00
Crok AIチャット	25.00	0.00	25.00
投稿	-	-	計測できません

計測できませんと出た部分に関しては運頼みとなりました。

振り返り

最初に書いた通り、レギュレーション違反によりランキングから除外されました。レギュレーション違反したことは純粋に悔しいです。

違反の原因を振り返ると、VRTの実行頻度がそこまで頻繁ではなかったこと、Tailwind CSSの置き換え時に元の挙動が維持されているか検証しなかったことに帰結します。

表示・動作を壊していないことを確認する仕組みもワークフローに組み込む必要がありました。たとえばClaude Codeのhookを使ってVRTを実行できていればよかったかなと感じています。

あとはテストケースを事前に読んでおき、修正前後で動作を担保する仕組みを作れれば良かったです。

AIエージェントを使う前提になった結果

今までのWeb Speed Hackathonと比較して変更を多く入れることができて、コミット数は初めて100を超えました。これはAIエージェントによる高速な実装ができたためだと考えています。Lighthouseを逐次回していた影響で並列化はあまりできなかったですが、改善を並列でやっていればより多くの変更を入れられたはずです。

ただ、パフォーマンスチューニングをする・しないといった判断はまだ人間側に委ねられていると感じました。手当り次第に改善をしても指標の向上につながらないことはあります。どの指標が改善につながるか推測するのは、まだ人間の仕事だと感じます。

個人的にはどうしてもデータベース周りが弱くてインデックスを貼る思考に至らなかった反省があります。

一方で来年には景色が変わっていそうです。2025年3月時点ではCursorなどからAIを使うことが一般的だったところから、Claude CodeやCodexを中心としたCLI中心の世界になって、さまざまなツールとの連携もできるようになってきたという変化もありました。

2027年にもWeb Speed Hackathonは開催されるでしょうが、その頃には、AIエージェントがより安全に自律して動けるようになって、提案を積極的にしてくるようになり、人間はAIエージェントが自律的に動く間に次の手を打つということが当たり前になっていそうです。

Claude CodeのSkillsでWeb機能のBaseline対応状況を確認できるようにした

2026-03-02T00:00:00.000Z

Claude Codeで使えるSkillsの仕組みを使って、Web Platform BaselineをClaude Codeから参照できるようにしました。

「XX機能の対応状況はどんな感じ？」と聞くだけで、Baselineの状態やサポートブラウザーのバージョンが出ます。

スキルは以下のリポジトリで公開しています。

https://github.com/kubosho/my-skills

導入方法はClaude Code上で完結するものとスタンドアロンの2種類あります。

Claude Code上で完結する方法では、以下のコマンドを実行します。

/plugin marketplace add kubosho/my-skills
/plugin install kubosho-skills@my-skills

スタンドアロンの方法では、リポジトリをcloneして ~/.claude/skills/ へシンボリックリンクを張ります。

git clone https://github.com/kubosho/my-skills.git
ln -s /path/to/my-skills/skills/baseline ~/.claude/skills/baseline

なぜ作ったのか

開発する中で「この機能のブラウザー対応状況はどんな感じだっけ」と気になった場合、今までは以下の手段で確認していました。

Can I useを開いて検索する
MDNの互換性テーブルを確認する

しかし、どちらもブラウザーに切り替えて検索する必要があって、コーディング中の流れが途切れるので嫌でした。

技術的な話

Baselineの情報を取得するためにWeb Platform Status APIへリクエストしています。このAPIは GET https://api.webstatus.dev/v1/features?q={query} というエンドポイントで、ある機能のBaseline状態やブラウザーのサポート情報を返します。

リクエスト時に使えるクエリを一部紹介すると、以下のような演算子が使えます。

name:grid のようにキーワードで機能名を検索
baseline_status:widely で広くサポートされている機能を絞り込み
available_on:chrome や -available_on:firefox でブラウザーごとのサポート有無でフィルタ

AND条件はスペース区切り、OR条件は +OR+ という記法を使うことで指定できます。例えば name:grid baseline_status:widely で「Widely availableになっているgrid関連の機能」を探せます。

Skillの構造

今回作成したSkillでは、APIのエンドポイント・演算子の一覧・入出力・制約だけを定義しています。ツールの使用や、機能の詳細情報をどこまで表示するかはAIエージェントに任せています。

出力フォーマットは情報量に応じて変更しています。結果が少なければBaselineの状態・サポート日時・ブラウザーバージョンなどを詳細に表示し、結果が多ければサマリーテーブルに切り替えています。

また、10秒経過後にタイムアウトさせるのと、同時リクエスト数の上限を最大3リクエストにするといった制約も設けています。

使ってみて

新しめの機能を使いたいときに「これ大丈夫だっけ」とすぐ聞けて良いです。

特に「主要ブラウザーでまだ使えない機能は？」と自然言語で質問した場合に、AIエージェント側でよしなにクエリを構築して検索できるのが良いです。

あとは最新の状況を知る目的でも使えます。Claude Code上で「2026年にwidelyまたはnewlyへ達した、CSSやJSの機能はある？」という質問した時の応答は以下の通りです。情報は2026年2月26日時点の情報です。

⏺ Skill(baseline)
  ⎿  Successfully loaded skill

⏺ 2026年のbaseline到達状況を調べるね。CSSとJavaScriptそれぞれ、widelyとnewlyで検索する。

⏺ Fetch(https://api.webstatus.dev/v1/features?q=baseline_date:2026-01-01..2026-12-31%20baseline_status:widely%20group:css)
  ⎿  Received 35 bytes (200 OK)

⏺ Fetch(https://api.webstatus.dev/v1/features?q=baseline_date:2026-01-01..2026-12-31%20baseline_status:newly%20group:css)
  ⎿  Received 5.8KB (200 OK)

⏺ Fetch(https://api.webstatus.dev/v1/features?q=baseline_date:2026-01-01..2026-12-31%20baseline_status:widely%20group:javascript)
  ⎿  Received 35 bytes (200 OK)

⏺ Fetch(https://api.webstatus.dev/v1/features?q=baseline_date:2026-01-01..2026-12-31%20baseline_status:newly%20group:javascript)
  ⎿  Received 2KB (200 OK)

⏺ 2026年（現時点まで）にBaseline到達した機能をまとめたよ。

使ったクエリ:
- baseline_date:2026-01-01..2026-12-31 baseline_status:newly group:css
- baseline_date:2026-01-01..2026-12-31 baseline_status:newly group:javascript
- widely は CSS・JS ともに 0件だった

---
CSS — Newly available (5件)

すべて 2026-01-13 に newly 到達。最後のブラウザが Firefox 147。

┌────────────────────────┬───────────────┬────────────────┬──────────────────┐
│        Feature         │    Chrome     │     Safari     │  Firefox (最後)  │
├────────────────────────┼───────────────┼────────────────┼──────────────────┤
│ Active view transition │ 125 (2024-05) │ 18.2 (2024-12) │ 147 (2026-01-13) │
├────────────────────────┼───────────────┼────────────────┼──────────────────┤
│ rcap unit              │ 118 (2023-10) │ 17.2 (2023-12) │ 147 (2026-01-13) │
├────────────────────────┼───────────────┼────────────────┼──────────────────┤
│ rch unit               │ 111 (2023-03) │ 17.2 (2023-12) │ 147 (2026-01-13) │
├────────────────────────┼───────────────┼────────────────┼──────────────────┤
│ rex unit               │ 111 (2023-03) │ 17.2 (2023-12) │ 147 (2026-01-13) │
├────────────────────────┼───────────────┼────────────────┼──────────────────┤
│ ric unit               │ 111 (2023-03) │ 17.2 (2023-12) │ 147 (2026-01-13) │
└────────────────────────┴───────────────┴────────────────┴──────────────────┘

rcap/rch/rex/ric はルートフォントに基づく相対単位。Firefox 147 での実装で全ブラウザ対応になった。

---
JavaScript — Newly available (2件)

┌───────────────────────────────┬────────────┬───────────────┬────────────────┬──────────────────┐
│            Feature            │ Baseline日 │    Chrome     │     Safari     │  Firefox (最後)  │
├───────────────────────────────┼────────────┼───────────────┼────────────────┼──────────────────┤
│ Map.prototype.getOrInsert()   │ 2026-02-14 │ 145 (2026-02) │ 26.2 (2025-12) │ 144 (2025-10)    │
├───────────────────────────────┼────────────┼───────────────┼────────────────┼──────────────────┤
│ JS modules in service workers │ 2026-01-13 │ 91 (2021-05)  │ 15 (2021-09)   │ 147 (2026-01-13) │
└───────────────────────────────┴────────────┴───────────────┴────────────────┴──────────────────┘

Map.prototype.getOrInsert() は TC39 提案の機能で、キーが存在しなければ値を挿入して返す。Chrome 145 が最後の実装で newly に到達。

---
まとめ

- Widely 到達: CSS・JS ともに 0件（2026年はまだ2ヶ月しか経っていないので、これから増える可能性がある）
- Newly 到達: CSS 5件 + JS 2件 = 計7件
- Firefox 147 のリリース（2026-01-13）が多くの機能の baseline 到達トリガーになっている

ブログにダークモードを実装した

2026-02-02T03:00:00.000Z

このブログには元々ダークモードがありませんでした。

ブログをはてなブログから独自のシステムに移行した2019年は、Android 10やiOS 13でダークモードへの切り替えがリリースされて、ようやくダークモードが一般層にも広がる素地ができた年でした。

このブログにも2020年5月の段階でダークモードを導入したいとissueは作っていました。そこから構想5年を経て、重い腰を上げダークモードを実装しました。嘘です。ずっと構想していたわけではありません。

今回の実装で考慮した点や、今後の課題についてまとめます。

モードの切り替え実装

今回は data-theme 属性をhtml要素に付与し、CSSでライトモードとダークモードのスタイルを定義する方法を採用しました。

/* 実装サンプル */
[data-theme='light'] {
  --color-neutral-background: oklch(0.97 0 0);
  --color-neutral-text: oklch(0.21 0 0);
}

[data-theme='dark'] {
  --color-neutral-background: oklch(0.28 0 0);
  --color-neutral-text: oklch(0.97 0 0);
}

読者がブログのテーマを選べるようにしたかったため、data-theme 属性でモードを切り替える実装を採用しました。OSの設定に従う「システム」と、明示的な「ライト」「ダーク」の計3つから表示モードを選択できます。

テーマを切り替えるUIではPopover APIを使っています。

<button type="button" popovertarget="theme-popover">
  <!-- アイコン -->
</button>

<div id="theme-popover" popover>
  <button data-theme-value="system">システム</button>
  <button data-theme-value="light">ライト</button>
  <button data-theme-value="dark">ダーク</button>
</div>

Popover APIはJavaScriptを使わなくともポップオーバーの表示・非表示を切り替えられます。他とえば前述のコードだと popover="auto" を指定した状態になり、ポップオーバー領域の外側やEscキーを押すことでポップオーバーを非表示にできます。

またポップオーバーの位置決めにCSS Anchor Positioningを使っています。Baseline 2026なのでようやく主要ブラウザーの安定版で動作するようになった機能です。

.TriggerButton {
  anchor-name: --theme-trigger;
}

.Popover {
  position-anchor: --theme-trigger;
  top: anchor(bottom);
  left: anchor(left);
}

ポップオーバーの位置は今までJavaScriptで位置計算をして実装するしかなかったですが、Anchor Positioningが出てきたことでCSSだけを使ってポップオーバーの配置を決められるようになったのは便利だと感じました。dialog要素が登場した時と同じ感覚です。

モードの設定はCookieに保存しています。ページ読み込み時にCookieからテーマを読み取り、html要素の data-theme 属性に反映しています。

<html lang="ja" data-theme="system">
  <script>
    (() => {
      const match = document.cookie.match(/(?:^|; )theme=([^;]*)/);
      const theme = match ? match[1] : 'system';
      document.documentElement.setAttribute('data-theme', theme);
    })();
  </script>
  <!-- ... -->
</html>

OKLCH色空間の採用

色の定義にはOKLCHを採用しました。従来のHEX値やHSLではなく、OKLCHを選んだ理由は知覚的な均一性を得られるためです。

OKLCHの色空間を使うことで、色を比較したときに一方の色が沈んで見えたり、色が違って見えるといった問題が起きにくくなります。OKLCH Color Picker & Converterといった直感的な色調整ツールがあるのも良いです。

ただ、色の選定には想定以上に時間がかかりました。ライトモードの色をそのまま反転させても違和感のある配色になります。結局、ライトモードとダークモードの両方とも一から色を選び直しました。

コントラストの調整

コントラストの基準はWCAG 3で採用予定のAPCAを満たすようにしました。測定にはAPCA Contrast Calculatorを使いました。

今回の調整で一番苦労したのはメインの色です。今までは #003760 ——OKLCHでは oklch(0.329 0.0888 248.18) を使っていましたが、ダークモードの背景 oklch(0.28 0 0) と合わせたときにコントラストがLc 0となってしまうため色を変えなくてはいけませんでした。

個人的には深みのある青色の象徴として #003760 という値を暗唱できるくらいには気に入っていましたが、コントラストの関係で色を調整せざるを得なくなり、ライトモードでは oklch(0.43 0.119 253) を使い、ダークモードでは oklch(0.51 0.141 253) を使うようにしました。とはいえ、新しい色もすでに慣れました。

まとめ

ダークモード対応は思った以上に奥が深いものでした。結果的に配色を一から考え直すことになりました。その分、個人的には気にいった見た目になりました。もしダークモードを使っている人がいれば、見え方のフィードバックをもらえると嬉しいです。

参考リンク

ブログにいいねボタンを実装した

2026-02-01T10:30:00.000Z

このブログにいいねボタンを実装しました。以下の構成で実装しています。

LikeButton (UI)
↓
React custom hooks (SWRフック、楽観的更新、デバウンス + バッファリング)
↓
POST /api/likes/[id] (Astro APIエンドポイント)
↓
PostgreSQL

フロントエンドはReactコンポーネントとカスタムフックを組み合わせて、APIリクエストとUI更新を担い、バックエンドはAstroのAPI Routesを使っていいね周りのAPIを実装し、PostgreSQLを使ってデータを永続化しています。

なぜ実装したのか

ブログ記事を読んだ人から反応が欲しかったためです。

いいね機能は、コメント機能と比較して、読者が手軽に反応を示せる手段だと考えています。読者は「参考になった」「面白かった」という気持ちをワンクリックで伝えられます。また、書き手である自分にとっても、どの記事が読者に響いているかを把握する指標になる可能性があると考えました。

いいねボタンを連打可能にした理由

実装にあたっては、ログイン不要で読者が何度でもいいねできる仕様にしました。気軽に連打できる体験をさせたかったのと、個人ブログにわざわざログインをする人はいないと考えたためです。

完璧を求めない判断

また「いいね数が多少失われても問題ない」という前提で設計しました。

たとえば、いいねのリクエストのリトライキューの実装にlocalStorageではなくsessionStorageを使っています。いいねの送信や反映が失敗して無かったことになったとしても、不要なリトライキューがブラウザーに残り続け、リクエストが繰り返されてしまうことを防ぐようにしました。

フロントエンドの実装

まずはフロントエンドの実装から見ていきましょう。

LikeButtonコンポーネント

いいねボタン用のコンポーネントは、React組み込みのフックやカスタムフックを組み合わせて、拍手アイコンといいね数を表示している構成です。

Astroのコンポーネントでコンポーネントを作らなかった理由は、Share state between Astro components | Docsというドキュメントを見て、Astroで状態を管理するためにNano Storesというライブラリを導入しないといけないことを知り、それが若干面倒に感じたためです。

では実装を見ていきましょう。

export function LikeButton({ entryId, likeLabel, onClick }: Props): React.JSX.Element {
  // 状態・カスタムフック定義
  const [clapping, setClapping] = useState(false);
  const { counts, handleLikes, isLoading } = useLikes({ entryId });
  // ...

clapping はクリック時に表示するアニメーション用の状態です。useLikes フックではいいねの数と操作用のハンドラーを定義しています。

// ...
const handleClick = useCallback(() => {
  handleLikes();

  setClapping(false);
  requestAnimationFrame(() => {
    setClapping(true);
  });

  onClick?.();
}, [handleLikes, onClick]);
// ...

クリック時に requestAnimationFrame を使い、アニメーションが毎回実行されるようにしています。

  // ...
  return (
    <div className={styles.container}>
      <button type="button" className={styles.button} aria-label={likeLabel} onClick={handleClick}>
        <span className={clsx(styles.clap, clapping && styles.clapping)}>
          {/* アイコン */}
        </span>
      </button>
      <span className={styles.count} aria-live="polite">
        {counts}
      </span>
    </div>
  );
}

いいね数を表示する要素に対して aria-live="polite" を指定することで、いいね数をスクリーンリーダーで読まれるようにしています。

楽観的UI更新

ユーザーがいいねボタンをクリックした瞬間に、サーバーからのレスポンスを待たずにUIを更新しています。

データ取得にはSWRを使っています。TanStack Queryを使うことも考えましたが、今回はいいね数の取得とUIの更新に使うだけなので、APIがシンプルなSWRで十分と判断しました。

まずSWRを使っていいね数を取得し、バッファリング用のカスタムフックを読み込みます。

export function useLikes({ entryId }: UseLikeParams): UseLikeReturn {
  const { data, isLoading, mutate } = useSWR<LikesOnGetResponse | null>(
    `/api/likes/${entryId}`,
    fetcher,
    {
      revalidateOnFocus: false,
      revalidateOnReconnect: false,
    }
  );
  const { updateLikeCounts } = useLikesBuffer();
  // ...

タブがフォーカスされた時やネットワーク再接続時の自動再検証は必要ないので、useSWR のオプションに revalidateOnFocus: false と revalidateOnReconnect: false を指定しています。

いいねボタンがクリックされた時のハンドラー定義は以下の通りです。

  // ...
  const handleLikes = useCallback(() => {
    // 即座にUI更新
    void mutate({
      id: entryId,
      counts: countsRef.current + 1
    }, { revalidate: false });
    // バッファに追加
    updateLikeCounts(entryId, 1);
  }, [entryId, mutate, updateLikeCounts]);

  return { counts: countsRef.current, handleLikes, isLoading };
}

SWRの mutate 関数を使ってローカルのキャッシュを即座に更新しています。revalidate: false でサーバーへの再検証リクエストを抑制しています。同時に updateLikeCounts でバッファにいいねの回数を追加し、後でまとめてリクエストをするようにしています。

バッファリングによるリクエスト最適化

いいねボタンを連打した場合、ボタンを押した回数分そのままAPIリクエストした場合に、無駄なリクエストが増え、サーバーとユーザーどちらにも嬉しくない事態になります。そこで一定時間内はいいねボタンの押した回数をバッファリングしておき、いいねを押した回数だけいいね数を加算してリクエストを送信するようにしています。

以下のコードでは、バッファリング用の定数とrefを定義しています。

const FLUSH_TIMER = 1_000;

export function useLikesBuffer(): UseLikeBufferReturn {
  const bufferedIncrementsRef = useRef<Map<string, number>>(new Map());
  const debounceTimerRef = useRef<ReturnType<typeof setTimeout> | null>(null);
  // ...

bufferedIncrementsRef は記事IDごとのいいね数の増分を保持し、debounceTimerRef はデバウンス用のタイマーを管理しています。

いいね数を更新する関数は以下の通り定義します。

  // ...
  const updateLikeCounts = useCallback((entryId: string, increment: number) => {
    // 現在のバッファに増分を加算
    const currentIncrement = bufferedIncrementsRef.current.get(entryId) ?? 0;
    bufferedIncrementsRef.current.set(entryId, currentIncrement + increment);

    // 既存のタイマーをクリア
    if (debounceTimerRef.current != null) {
      clearTimeout(debounceTimerRef.current);
    }
    // ...

いいねボタンが押されるたびにタイマーをリセットすることで、連打中はリクエストを送信しないようにして、連打が止まってから送信されるようにしています。

最後に、タイマーを発火してバッファに溜めたいいねの数をサーバーに送信します。

    // ...
    debounceTimerRef.current = setTimeout(() => {
      const totalIncrement = bufferedIncrementsRef.current.get(entryId) ?? 0;
      bufferedIncrementsRef.current.delete(entryId);
      void sendLikes(entryId, totalIncrement);
    }, FLUSH_TIMER);
  }, []);

  return { updateLikeCounts };
}

ここまでの実装によって、1秒以内に5回いいねボタンを押された場合に5回リクエストするのではなく、payloadに increment: 5 というobjectが入った状態のリクエストにまとめられます。デバウンスの間隔は実際に連打してみて、1秒くらいが「連打が止まった」と判断するのにちょうど良い体感でした。

リトライキューの実装

ネットワークエラーでリクエストが失敗した場合を考慮して、sessionStorageにリトライキューを保存しています。

export function saveToRetryQueue(entryId: string, increment: number): void {
  const storage = getStorage();
  if (storage == null) {
    return;
  }

  const queue = loadRetryQueue();
  queue.push({ entryId, increment, timestamp: Date.now() });
  storage.setItem(LIKE_SEND_RETRY_QUEUE_KEY, JSON.stringify(queue));
}

ページを再読み込みした時にリトライキューを読み込み、失敗したリクエストを再送信しています。

バックエンドの実装

次にバックエンドの実装を見ていきます。

いいね数を保存するためのテーブル定義

Drizzleを使って以下のように定義しています。

export const likes = pgTable('likes', {
  id: serial('id').primaryKey(),
  entryId: varchar('entry_id', { length: 255 }).notNull().unique(),
  counts: integer('counts').default(0).notNull(),
  createdAt: timestamp('created_at').defaultNow(),
  updatedAt: timestamp('updated_at').defaultNow(),
});

記事IDにはユニーク制約を付けていて、記事ごとに1レコードとなります。PostgreSQLのホスティングはNeonを使っています。無料枠の存在が決め手でしたが、無料枠がなくなった場合は料金次第で移行するかもしれません。

APIエンドポイント

AstroのAPI Routesを使って、GETとPOSTのエンドポイントを実装しています。

// GET: いいね数の取得
export async function GET({ locals, params, request }: APIContext): Promise<Response> {
  const { id } = params;
  if (!isValidEntryIdFormat(id)) {
    return createClientErrorResponse({ type: 'invalidEntryId' });
  }

  const exists = await entryExists(id);
  if (!exists) {
    return createClientErrorResponse({ type: 'entryNotFound' });
  }

  const counts = await getLikeCounts({ context: locals, entryId: id });
  return new Response(JSON.stringify({ id, counts }), { status: 200 });
}

いいね数の登録・更新

いいね数の登録・更新には、Drizzleで定義されている onConflictDoUpdate（いわゆるUpsert）を使っています。

export async function incrementLikeCounts({ context, entryId, increment }: IncrementParams): Promise<number> {
  const db = getDbClient(context);

  const result = await db
    .insert(likes)
    .values({ counts: increment, entryId })
    .onConflictDoUpdate({
      target: [likes.entryId],
      set: {
        counts: sql`${likes.counts} + ${increment}`,
        updatedAt: new Date(),
      },
    })
    .returning({ counts: likes.counts });

  return result[0]?.counts ?? 0;
}

Cloudflare Cache APIによるキャッシュ

GETリクエストの結果はCloudflare Cache APIを使ってエッジでキャッシュしています。

const cache = locals.runtime?.caches?.default ?? null;
const cacheKey = createNormalizedCacheKey(request);

const cachedResponse = await cache?.match(cacheKey);
if (cachedResponse != null) {
  return new Response(await cachedResponse.text(), {
    status: cachedResponse.status,
    headers: cachedResponse.headers,
  });
}

POSTリクエストでいいね数が更新された際には、該当するキャッシュを削除して、次回のGETで最新の値が取得されるようにしています。

セキュリティ対策

セキュリティ対策の一部は、AIエージェントに指摘されて追加しました。自分だけでは見落としていた観点です。

入力値のバリデーションと記事IDの検証は、AIエージェントからの指摘で「確かにDevToolsやcURLによるリクエストでゴミデータが増えたり、不正にいいね数が増えたりする」と認識しました。

レート制限

Cloudflare WorkersのRate Limiting APIを使って、短時間での大量リクエストを制限しています。

export async function checkRateLimit({ clientIp, entryId, rateLimiter }: Params): Promise<boolean> {
  try {
    const rateLimitKey = JSON.stringify({ clientIp, entryId });
    const { success } = await rateLimiter.limit({ key: rateLimitKey });
    return !success;
  } catch (error) {
    console.error('Rate limit check failed:', error);
    return false;
  }
}

入力値のバリデーション

リクエストボディのバリデーションにはValibotを使用しています。バリデーションを実装する過程でAstroではZodをデフォルトで使えることに気付きましたが、見ないふりをしました。

export const likesOnPostRequestSchema = object({
  increment: pipe(
    number(),
    integer(),
    minValue(1, 'Increment must be at least 1'),
    maxValue(MAX_INCREMENT_VALUE, `Increment must be at most ${MAX_INCREMENT_VALUE}`),
  ),
});

記事IDの検証

存在しない記事IDに対するリクエストを弾くため、記事IDの形式チェックと存在確認を行っています。

const MAX_ENTRY_ID_LENGTH = 100;
const ENTRY_ID_PATTERN = /^[a-z0-9][a-z0-9-]*[a-z0-9]$|^[a-z0-9]$/;

// 形式チェック：100文字以下の英小文字、数字、ハイフンのみ許可
export function isValidEntryIdFormat(id: string | undefined): id is string {
  if (id == null || id === '' || id.length > MAX_ENTRY_ID_LENGTH) {
    return false;
  }
  return ENTRY_ID_PATTERN.test(id);
}

// 記事の存在確認
export async function entryExists(entryId: string, getEntryFn: GetEntryFn): Promise<boolean> {
  const entry = await getEntryFn('entries', entryId);
  return entry !== undefined;
}

まとめ

今回のいいねボタンの実装では個人ブログという規模に合わせた判断をしました。「いいねボタンを連打可能にする」のはその1つです。

一方で実装するにあたってAIエージェントも使ってさまざまな点を考慮しました。たとえば以下の点です。

楽観的UI更新による即時フィードバック
バッファリングによるAPIリクエストの最適化
レート制限と入力値バリデーションによるセキュリティ対策
sessionStorageを使うことで、不要なデータの残留を防ぐ

こういったどのように実装するか自分ですべて判断し実装できるという点で、個人ブログの開発は面白いです。

個人の技術ブログをリニューアルした

2025-12-28T12:00:00.000Z

個人の技術ブログ（今あなたが見ているブログ）をリニューアルしました。

見た目はそこまで変わっていないですが、内部はいろいろと構成を見直したり機能を追加したりしました。

システム構成の変更

以前は、Next.jsベースでブログを作り、microCMSから記事を入稿し、Vercelでホスティングしていました。その時のシステム構成はNext.js + Vercel + microCMSなどを使ってほぼ無料でブログを運用するで書いています。

しかし、いくつか問題がありました。

静的コンテンツが多いブログに対して、Next.jsがオーバースペック
CMSで管理したくなるほどコンテンツ管理が複雑化していない。やはりオーバースペック
Vercelにロックインされるのが、なんとなく嫌だった

そのため、現在はAstroで大部分のコンテンツをSSGするようにして、専用のリポジトリで記事を管理し、Cloudflare Workersでホスティングしています。

なおロックインという観点では、Cloudflareの機能にだいぶ依存しているので、依存先が変わっただけと言えます。ロックイン解消という観点では移行した意味がないですね。

いいねボタンの設置

noteのいいねボタンや、catnose's notesの拍手ボタンに触発されて、読者が簡易的なフィードバックを送れる手段として設置しました。

最近はnoteで日々の心がけといった記事を書くことが増えています。noteはいいねの数がPV以外の指標として分かりやすく、記事が読まれている実感を得られる点が良いです。下衆な話をすれば、承認欲求が満たされるとも言います。

そういった体験を自分のブログでも得たくなったのが開発のきっかけでした。

いいねボタンの技術的な話

APIの実装にはAstroのServer Endpointsを使用しています。

GETリクエストはCache APIでキャッシュして、CloudflareのEdge and Browser Cache TTLのデフォルト値を適用しています。

キャッシュのinvalidationはPOSTリクエスト時の cache.delete() で実現していて、キャッシュヒット率向上のためにクエリパラメータを削除したURLをキーにしています。

POSTリクエストに対しては、Rate Limiting APIで一定のレートリミットもかけています。アクセス数は多くないので不要そうですが、攻撃対策として一応入れています。

いいね数はNeon上のデータベースに保存しています。Neonは無料枠の存在が嬉しいですが、もし無料枠がなくなったら移行するかもしれません。

またリクエストのバリデーションにValibotを使っています。Astroでは astro/z を介してZodが使えることをAstro v5へ更新したときに知りましたが、開発を一段落させることを優先してValibotをひとまず使うことにしました。

シェアボタンの設置

以前は、SNSの喧噪と距離を置くため意図的に設置していませんでした。

しかし、記事をより多くの人に見てほしいという欲が出てきたのでシェアボタンを設置しました。シェアボタンを設置することによって、すぐにシェアが増加して承認欲求が満たされてウハウハ！とはならないですが、まずは設置することが重要と考えました。

いろいろと試せる場があると楽しい

個人の技術ブログは自分の好きなようにできますし、やりたいことをやる気になったらすぐ試せます。いろいろあーでもないこーでもないと格闘できるのが楽しいです。

そういった場の存在を保つためにも、この個人の技術ブログを無くすことはないでしょう。

なお、実装がどうなっているのか見たい方は、ソースコードをkubosho/blog.kubosho.comに置いているので見てください。

eslint-plugin-importによってVitestの設定ファイル上でエラーが発生する場合がある

2022-11-23T05:16:24.348Z

vitest と eslint-plugin-import に依存している環境では、vitest.config.ts内で vitest/config をインポートすると Unable to resolve path to module 'vitest/config'. eslint(import/no-unresolved) と表示されることがあります。

これはnode_modules/vitest以下にconfig.d.tsのみが存在し、config.jsの実体はdist/config.jsにあるのが原因です。ディレクトリ構造を示すと次のようになります。

/node_modules/vitest
|-- dist
|   |-- config.cjs
|   |-- config.d.ts
|   |-- config.js
`-- config.d.ts

vitest/config.d.tsの内容はvitest/dist/config.jsでexportしているものをそのままexportしています。

export * from './dist/config.js';

解決方法

ESLintの設定ファイルで import/resolver 内の node.extensions の値に d.ts を追加すると d.ts 内のモジュール読み込みが解決できるようになり、ESLintの import/no-unresolved のエラーが無くなります。

settings: {
  'import/resolver': {
    node: {
      extensions: ['.js', '.jsx', '.ts', '.tsx', '.d.ts'],
    },
  },
}

Next.js + Vercel + microCMSなどを使ってほぼ無料でブログを運用する

2022-08-24T10:26:59.603Z

当ブログのシステム構成について紹介します。構成を真似することでほぼ無料（後述）でブログを運営できます。

当ブログの構成概要

いわゆるJamstack構成です。構成を画像で示すと次の通りです。

microCMSまたはブログのリポジトリに変更がある場合、VercelのDeploy Hooksを使ってVercel上の環境を更新するようにしています。

Next.js上でビルドするときに、ヘッドレスCMSのAPIを使ってブログの記事などを取得し、Next.jsのgetStaticPropsを使ってStatic Site Generateをできるようにしています。

ブログのコンテンツはVercelが提供しているCDNによってキャッシュされます。

また画像などはAmazon S3上にアップロードしたものを、CloudFrontでキャッシュして配信するようにしています。

どうしてブログをJamstack構成で作ろうと思ったか

もともとこのブログははてなブログ上で書かれていました。

はてなブログを使っていた理由としては、WordPressなどのCMSを使った場合に、本体やプラグインの更新管理が面倒だったのと、投稿画面が使いやすかったためでした。

素振り環境が欲しくなった

はてなブログでブログを運用するうちに、Webフロントエンドやサーバーサイドも含めた素振り環境が欲しくなりました。

そうした思いと、はてなブログProで提供されている機能のうち独自ドメインくらいしか恩恵を受けていないことに気づき、ブログを自前で作ろうと思い立ちました。

そこでブログを作り出した当初は、サーバーサイドも含めて作っていました。

ただ作業する中でいつまで経っても完成しない未来が見えたので、サーバーサイド側を作りこむのは諦め、Next.jsを使ってさくっと作って公開することにしました。

どのような技術スタックになっているか

使っているサービスやフレームワーク・ライブラリーを表にしました。

技術	リンク
フレームワーク	Next.js
ヘッドレスCMS	microCMS
ホスティング	Vercel
画像ストレージ	Amazon S3
画像CDN	CloudFront
i18n	Rosetta
マークダウンプロセッサー	unified, remark
HTMLコンバーター	rehype
テスト	Vitest

この中からヘッドレスCMSの変遷について話します。

最初はヘッドレスCMSにContentfulを使った

はてなブログからNext.jsベースのブログに置き換えたとき、Contentfulを使っていました。

しかし自動保存のタイミングでIMEが確定されて書いた記事の文章がめちゃくちゃになる現象が出た結果、ContentfulからGitリポジトリにMarkdownファイルをコミットして、事前に記事の情報をまとめたJSONファイルを作る形式に変更しました。

Markdownファイルをコミットする形式からmicroCMSへの移行

なんで移行しようと思ったかは覚えていないですが、6時間くらいかけてmicroCMSに記事を移行できたようです。

だいたい 6 時間くらいでブログのシステムを Markdown を直接更新する形式から microCMS で記事を入稿する形式にできた
— kubosho (@kubosho_) October 25, 2021

どれほどの料金がかかるか

今年実際にかかった料金を表にしました。

名前	プラン	料金
microCMS	Hobbyプラン	￥0
Vercel	Hobbyプラン	￥0
Amazon S3	従量課金	￥0
CloudFront	従量課金	$0～$0.01

今後どうしていきたいか

最後に当ブログの展望を示します。

OGP imageの自動生成

現在は記事がSNSなどにシェアされた場合、固定の画像が表示されます。

これを多くのCGMサービスで導入されているように、ブログのテーマに沿った画像を自動生成して使うようにしたいと考えています。

デバフの導入

今はサードパーティースクリプトなどが少ないので表示速度が早いですが、広告のスクリプトやWebフォントなどを導入してそれでもなお表示速度が早いというブログにしたいと考えています。

ただVercelのhobbyプランは広告を扱うと商用利用扱いになってProプラン以上の契約が必要になります。そのため広告のスクリプトを導入するなら、VercelのProプラン以上を契約するか、商用利用可のホスティングサービスへ移動します。

ブログのパフォーマンス指標の継続的な測定

広告のスクリプトやWebフォントの導入に伴って、パフォーマンス指標の継続的な測定を何かしらでして、パフォーマンス向上施策がどのくらい効果あるのか見られるようにしたいと考えています。

Googleアナリティクスの活用

今はただGoogleアナリティクスを導入しているだけですが、コンバージョンの設定なども入れてPV数などを上げるための参考指標を作りたいと考えています。

継続的にブログ更新できる仕組みづくり

なるべくブログの記事投稿を楽にしようと思い、ブログの投稿フォームや画像アップローダーを作っています。

ブログの投稿フォーム - https://github.com/kubosho/instant-blog-post-form
画像アップローダー - https://github.com/kubosho/s3-image-uploader

最後に

この記事が参考になったらブログのリポジトリにスターお願いします！

kubosho/blog.kubosho.com: My personal blog. Built with Jamstack technology stack.

ブログ記事を投稿するためのフォームを作った

2022-07-16T14:36:56.557Z

はてなブログのMarkdownによる記事編集画面やesa - 自律的なチームのための情報共有サービスのように、本文の編集画面とリアルタイムプレビューが横並びになるような投稿フォームが個人的に好みです。

ですが、ブログで使っているmicroCMSの投稿画面や、普段使っているマークダウンエディターのObsidianにはプレビューを横並びにするようなオプションが無かったため、自分で記事を投稿するためのフォームを作ってみました。

技術スタックとしては次の通りです。仕事では使っていないものばかりですが、いろいろ使ってみたかったものを揃えてみました。

実際の記事投稿画面は次の通りです。

備えている機能

今回作った投稿フォームの特徴は次の通りです。

ページの左側に本文編集フォームがある
ページの右側にリアルタイムプレビューがある
下書き状態・公開状態の切り替えが可能
- ただmicroCMSはPOST APIにクエリーを付けたい場合はTeamプラン以上の契約が必要になる……（作った後の動作確認で気づいた）
ページを再読み込みしてもタイトル・URLのパス・本文の状態が保持される

これから作りたい機能

いま考えていることとして、次に挙げる機能を作りたいと思っています。

記事を投稿するときに確認画面を表示する
記事の投稿が完了したら完了と分かるような表示を追加する
記事の投稿に失敗したら失敗と分かるような表示を追加する
タグの追加ができる
カテゴリーの追加ができる
プレビュー画面のスタイルをhttps://blog.kubosho.com/と同じものを適用する
fukayatsu/esareaやesaの本文編集フォームのように、tabキーやenterキーを押したときにマークダウンの記法が自動で挿入される
textlint · The pluggable linting tool for text and markdownを導入して、記事を書いているときにエラーを出す
何かしらのホスティングサービスにアップロードして、いろんなデバイスからアクセスできるようにする
- 認証機能を作る必要がある
本文編集部分とプレビュー部分のスクロール同期をする
Vimモード
画像アップロード

まとめ

もしこの記事を見て良いなと思ったら、リポジトリへのstarとwatch登録お願いいたします。

kubosho/instant-blog-post-form: Blog post form for https://blog.kubosho.com.

ファミリーマート公式X（Twitter）の投稿からより良い画像の代替テキスト(alt)を考える

2022-07-07T02:01:43.978Z

ファミリーマートの公式X（Twitter）の投稿に、画像の代替テキストを改善できそうな投稿がありました。

この記事では画像の代替テキストのどういった点が惜しいのか、またどのように改善すればいいのか、私見を書きます。

※貶すつもりは全くなく、あくまで投稿を元にどういった代替テキストを書けば良いのかを考える記事です。

どのような投稿か

ファミリーマート公式X（Twitter）の該当投稿を引用します。

これが、からあげの正解。
ファミから。

そのこだわりのすべてをALTでチェック。 pic.twitter.com/TalY56q5PX
— ファミリーマート (@famima_now) June 9, 2022

※投稿が削除されたのでインターネットアーカイブに残っている投稿を貼っておきます。

投稿を一目見ただけだと、ファミからというファミリーマートで売られている唐揚げの写真が4枚並んだ投稿です。

ただし投稿にもある通り、ファミからのこだわりが代替テキストに書かれていて、投稿の画像上にあるaltボタンを押すとこだわりが見られる投稿になっています。

なぜ代替テキストの使い方が惜しいのか

4枚目のお皿の上に唐揚げがたくさん乗っている画像の代替テキストとして「食べてください」を連続して書くことは、画像と代替テキストの内容が一致せず、特定の状況・状態では正しい情報が伝わらなくなります。

また、1枚目の湯気が立ち込めた唐揚げを切った断面のドアップ画像・2枚目のファミからのパッケージ画像・3枚目の唐揚げが中央にあってドアップになっている画像は、画像で示している内容も代替テキストに書かれていますが、画像にはない情報や宣伝文句のような文章も書かれています。

画像と代替テキストの内容が一致していないのは、テキストが画像の代替という役目を果たせないことになります。

また画像にない情報や宣伝文句も代替テキストに含んでしまうと、TweetDeckや非公式アプリを使っている晴眼者は代替テキストに書かれた文章を見れず、伝えたい情報を伝えられないことになります。

そもそも画像の代替テキストとは？

画像の代替テキストはなんらかの状況・状態で画像が使えないときに、設定した代替テキストが使われます。

どういった状況・状態で代替テキストが使われるか一例を挙げます。

スクリーンリーダーを使っている場合に、画像の代替テキストが読まれる
通信速度が遅く画像表示まで時間がかかる場合に、画像の代替テキストを表示する
CDNに障害が起きて画像が表示できない場合に、画像の代替テキストを表示する
Webブラウザーで特定の画像形式に対応していない場合に、画像の代替テキストを表示する
w3mやLynxなどのテキストベースのブラウザーで、画像表示に対応していない場合に画像の代替テキストを表示する
検索エンジンのクローラーが、画像の代替テキストを元に画像の情報を得る

HTMLにおいては、img要素のalt属性の値に画像の代替テキストを設定します。

画像の代替テキストの書き方としてHTMLの仕様には次のように書かれています。

One way to think of alternative text is to think about how you would read the page containing the image to someone over the phone, without mentioning that there is an image present. Whatever you say instead of the image is typically a good start for writing the alternative text.

同じ部分を日本語訳されたHTMLの仕様を見てみると次のように書かれています。

代替テキストを考える1つの方法は、画像の存在があることを言及することなく、電話で誰かに画像を含むページをどのように読むかを考えることである。通常、画像の代わりにいうものは何でも、代替テキストを記述するための良いスタートである。

さてX（Twitter）の話に戻ると、画像の代替テキストのことを「画像の説明」という言葉で説明しています。

X（Twitter）のヘルプにある良い画像の説明を作成する方法を引用すると、「画像の説明は、目の不自由な方や弱視の方、ユーザー補助テクノロジーをご利用の方、低帯域幅の地域にお住まいの方、さらなる背景情報を求めている方の一助」向けの機能と書かれています。

X（Twitter）の画像の説明も、HTMLのimg要素のalt属性に指定するような文言を書くことを意図していそうです。

どのように代替テキストを改善するか

ここまで書いたことを踏まえて、ファミリーマートの投稿の画像の代替テキストを考えてみます。

投稿で何を伝えたかったのかを考える

ファミリーマートの投稿ですが、製品の美味しさやシズル感を伝えたかったと推測します。

製品のストーリーを伝えることで製品開発者の熱い思いがこの投稿を見た人達に伝わって、好意的な印象を持つことで実際の購入に至ってほしい考えがあったと考えます。

こういったストーリーをX（Twitter）で書くには、X（Twitter）に投稿できる文字数では足りないでしょう。ただストーリーを別途書くための特設ページを用意できなかった可能性があります。

そのため、altボタンを押すと見られるようにすればいいというX（Twitter）運用担当者の工夫があったと考えられます。

また4枚目のお皿の上に唐揚げがたくさん乗っている画像の説明では「食べてください」を連続して書くことで、altボタンを押した人達を驚かせたり、クスっと笑わせたりという公式アカウントがおちゃめなことをしているというギャップを感じさせたかった気持ちがあったのでしょう。

実際リプライでは4枚目ホラーで草という投稿があり、これはX（Twitter）運用担当者が意図した反応だと考えられます。

代替テキストの改善例

というわけで、自分が考える代替テキストの改善例を書きます。まずもう一度投稿を引用します。

これが、からあげの正解。
ファミから。

そのこだわりのすべてをALTでチェック。 pic.twitter.com/TalY56q5PX
— ファミリーマート (@famima_now) June 9, 2022

※投稿が削除されたのでインターネットアーカイブに残っている投稿を貼っておきます。

この投稿にある画像の代替テキストを書くのであれば次のようにするかもしれません。

画像1枚目の代替テキストは「唐揚げの断面がドアップになっていて、断面から湯気が出ている様子」
画像2枚目の代替テキストは「ファミから醤油味とファミから塩味のパッケージ」
画像3枚目の代替テキストは「唐揚げが中央にあり、その唐揚げから湯気が出ている様子」
画像4枚目の代替テキストは「白いお皿の上に唐揚げがたくさん乗っていて、その後ろに付け合わせの野菜がある」

電話口の相手に伝える感じだと、こんな感じで書けば伝わりそうです。

また4枚目の「食べてください」を連呼する形式を活かすのであれば、スマートフォンのメモアプリに「食べてください」とひたすら書いたものをスクリーンショットという形式で投稿して、代替テキストに「食べてください」をひたすら書く形式がありそうです。

おまけ: 自分が良いと感じた代替テキスト

まず全農広報部【公式】日本の食を味わうの投稿が挙げられます。

フライパンでできるサラダチキンの作り方、ご紹介しています。今月の広報誌エプロンです。サラダチキンは鍋で茹でるイメージでしたが、フライパンでできるんですね。夏場、お湯を沸かすと思うと一気に腰が重くなりますがフライパンなら…なんとか…！(フライパン大好き民)https://t.co/5EWrikEpd2 pic.twitter.com/7vtZqbhX2z
— 全農広報部【公式】日本の食を味わう (@zennoh_food) July 5, 2022

画像の内容が代替テキストでも過不足無く表現されていると感じます。

他の投稿だと、にじさんじ所属のVTuberである壱百満天原サロメの投稿が挙がります。

きょうのおまんが、ホラー回と言われていてにっこりしてしまったので、おまけですわ😊 pic.twitter.com/nfShKjKWw7
— 壱百満天原サロメ💯🦂 (@1000000lome) July 4, 2022

画像の内容を全て書いているわけではないですが、漫画で伝えたいことを表現できている代替テキストで百満点ですわ～！

まとめ

代替テキストは人によって考え方にばらつきがありますし、状況によっても代替テキストの内容が変わるので、一概にこれが正解とは言いづらいものです。

しかし何かしらの代替テキストを設定することで、より多くの状況・状態にある人へ伝えたいことを伝えられるようになります。

代替テキストを設定したことがない人は、とりあえず代替テキストを一度設定してみましょう。

参考リンク

ブログを国際化対応した

2022-06-16T00:00:03.004Z

当ブログのUIで使う文言を国際化対応しました。

Introduce i18n by kubosho · Pull Request #933 · kubosho/blog.kubosho.com

国際化対応にはrosettaという軽量の国際化対応ライブラリーを使いました。

文言だけを各言語に対応させる分には必要なAPIが揃っていたのと、bundle sizeが426バイトだったのでJavaScriptのサイズが大きくならないのも良いと思い、rosettaを選択しました。

きっかけとしては、Androidアプリでの開発ではLintで文字列に都度IDを振って文字列リソースとして記載するよう指摘される旨の投稿を見て、Webでも同じ対応を入れていいはずと感じたためやりました。

Androidはこの辺しっかりしてて、「文字列は都度IDを振ってres/values/strings.xmlに文字列リソースとして記載しなさい」というのがAndroid Lintの指摘事項になってるんだよね。おかげで日本語をUIの中にベタ書きしない習慣を身につけやすい。
（まあ僕もWebだとベタ書きしてしまうのだけど） https://t.co/ZSONvK7u1d
— なかざん💉💉💉 (@Nkzn) May 30, 2022

正直あまり深く考えずにやれそうだからやりますわ～という感じでやりました。

感想としては、文言が特定のディレクトリに集約されたため、文言を変えるときに作業が楽になるなと感じました。

多言語対応という意味では現状日本語しか対応していないため、国際化対応によって何か得られたというのは無いです。

今後はブログの記事も多言語で書けるようになっていきたいです。

AVA上でsinon.useFakeTimers()を複数のテスト内で実行するとエラーが出る

2022-05-20T00:57:40.873Z

Sinon.JSのバージョンをv14.0.0に上げた際、エラーが出てテスト実行が失敗するようになりました。

この記事では対処方法を書いていきます。

事象

たとえば次のようなテストがあったとします。

sinon.useFakeTimers はドキュメントにある通り、setTimeout や clearTimeoutなどを置き換える関数です。

import test from 'ava';
import sinon from 'sinon';

test('test', (t) => {
  const fakeTimer = sinon.useFakeTimers();
  t.pass();
  fakeTimer.restore();
});

test('test2', (t) => {
  const fakeTimer = sinon.useFakeTimers();
  t.pass();
  fakeTimer.restore();
});

2回目の sinon.useFakeTimers() を実行するとき、先ほどのテストファイルで言うと test2 を実行するときに次のようなメッセージが表示されます。

TypeError {
  message: 'Can\'t install fake timers twice on the same global object.',
}

原因

書き換えられたグローバルオブジェクトを戻すために sinon.useFakeTimers と fakeTimer.restore() を対になる形で実行しないといけません。

うっかり fakeTimer.restore() を実行しないまま sinon.useFakeTimers を実行すると、元の日時に復元することが難しくなります。

// サンプル
const sinon = require('sinon@12.0.0');

console.log('Original time: ' + new Date().getTime()); // "Original time: 1653007080412"
let fakeTimer = sinon.useFakeTimers(Date.parse('2014-06-05T12:07:07.662Z'));
fakeTimer = sinon.useFakeTimers(Date.parse('2018-04-11T14:08:00Z'));
fakeTimer.restore();
console.log('Restored time: ' + new Date().getTime()); // "Restored time: 1401970027662"

今回のサンプルコードの場合はまだ復元できますが、これがより回数を重ねて sinon.useFakeTimers を実行してしまうとより復元が難しくなります。

この問題が、Impossible to restore fake timers in certain situations. · Issue #2449 · sinonjs/sinonで報告されて、対応として @sinonjs/fake-timers 側でProhibit faking of faked timers by cjbarth · Pull Request #426 · sinonjs/fake-timersというPull Requestがマージされました。

Pull RequestのSolutionに「If an attempt is make to fake a timer that is already faked, an exception will be thrown.」と書いてある通り、timerがすでにfakeだった場合に再度 sinon.useFakeTimers を実行した場合に例外が投げられるという変更がされました。

この変更により、複数のテストで sinon.useFakeTimers と fakeTimer.restore を実行していた場合に、AVA上でテストが並列で実行されることもあって fakeTimer.restore が実行される前に sinon.useFakeTimers が実行される場合が出てきました。

その結果として「Can't install fake timers twice on the same global object.」というエラーが出力されるようになりました。

解決策

解決方法は2つあります。

まず1つは、テストコード側で並列実行をやめて直列実行にすることです。具体的には次の通り書くとテストが成功します。

import test from 'ava';
import sinon from 'sinon';

test.serial('test', (t) => {
  const fakeTimer = sinon.useFakeTimers();
  t.pass();
  fakeTimer.restore();
});

test.serial('test2', (t) => {
  const fakeTimer = sinon.useFakeTimers();
  t.pass();
  fakeTimer.restore();
});

または test.before や test.after といったテストファイル内の最初と最後のテスト前後で実行されるフックを使って、fakeTimerを使うのも良いです。

import test from 'ava';
import sinon from 'sinon';

let fakeTimer = null;

test.before(() => {
  fakeTimer = sinon.useFakeTimers();
});

test.after(() => {
  if (!fakeTimer) {
    return;
  }
  fakeTimer.restore();
});

test('test', (t) => {
  t.pass();
});

test('test2', (t) => {
  t.pass();
});

AVAのように並列実行がデフォルトのテストフレームワークだと同じ問題が起きそうですが、他のJestやVitestなどはどうしているのか気になります。

自分がアクセシビリティ向上に力を入れる理由

2021-11-02T00:00:03.024Z

いま自分は、担当サービスのアクセシビリティ向上を推進する「アクセシビリティタスクフォース」を率いる立場になっています（アクセシビリティタスクフォースについては AbemaTV ABEMA iOS版アプリのアクセシビリティ向上支援｜事例紹介｜株式会社コンセントで少し触れられています）。

現在、アクセシビリティ向上の文化やプロセスを社内に浸透させていくため、さまざまな施策を考え実行しています。

ただそうやって活動していくうちに、ふと気づいたことがありました。自分はなぜアクセシビリティ向上に力を込めているかという言語化をしていないことです。

アクセシビリティ向上の推進は、個人でやるには大変で、組織としてやっていくのが一番良いと思っています。

ただ、組織としてアクセシビリティ向上をやっていくように伝えていく中で、個人の思いというのは活動の原動力として大事だと思っています。ここをあやふやにしてしまうと、ふとしたときにくじけてしまい折れてしまう気がします。

自分がそうやってくじけて折れてしまわぬよう、ここで自分のアクセシビリティ向上に対する思いを言語化してみます。

元々の自分の考え

自分は元々「かけがえのないモノをつくる」というビジョンを持っています。

「かけがえのないモノ」の定義は自分の中でも定まってはいないですが、現時点だと「社会インフラになるもの」を作りたいという考えです。

また高校生のときからHTMLとCSSを書いてきた経験もあり「インターネットを基礎とした社会インフラをつくる」ことを自分の理想として掲げています。

その「インターネットを基礎とした社会インフラ」の中で、自分の基盤がHTMLとCSSというのもあって、Webフロントエンドで貢献したいという考えを持っていました。

聴覚障害者からのサービスに対するツッコミ

さてここで、2年前の Japan Accessibility Conference digital information vol.2（以下、JA11YC）での体験を話します。

ABEMA Prime という番組内で、かつて補聴器ユーザーの苦悩と葛藤（リンク先では期限切れで動画視聴できず）というテーマを取り上げたことがありました。

この番組を放送したあと、聴覚障害者の方から「字幕をつけないのはなぜか。聴覚障害者を排除することに自覚がないのか、自覚があってもやるべきことをしていないのはなぜか（要約）」といった意見をもらいました。

そしてこの意見を書いた人が、JA11YCの場にいてそこで話をしました。

話した内容自体は2年前ということもあり忘れてしまっています（これに関しては申し訳ないです）。

ただ、ここで自分は「サービスを楽しめない人を出してしまうなんて自分で自分が恥ずかしい」という気持ちになり、サービスのアクセシビリティ向上をやっていくという思いを強くしました。

視覚障害者を誘導する体験

JA11YCに参加したあと、視覚障害者の人を渋谷駅まで誘導する機会がありました。どういう流れで誘導することになったか詳細は思い出せないですが、自分から手を挙げた気がします。

ただ誘導するのは初めてということもあり、果たしてちゃんと誘導できるのか少し緊張しました。

渋谷の道玄坂のほうは点字ブロックがほとんどありませんでした。そのため、点字ブロックに沿って歩けず、ほぼ自分に頼って歩かないといけない状況でした。なので自分は口頭でいまどの辺りにいるかを、場所の名前や道路の形状なども交えつつ案内しました。

結果的にはなんとか渋谷駅まで誘導することができて、電車に乗ったところまで確認しました。

誘導し終えたあとは、正直いつもは感じない疲れを感じましたが、「視覚障害者を誘導して気づいた点」で後述するように自分の中では良い経験でした。

なお道中で前から来た人がすれ違おうとしたときに、あまり避けずに軽く肩を当てた後こちらが悪いかのように軽い舌打ちをしたときは、何様だと感じました。相手側ももしかしたらイライラしていた、もしくは気持ちが良くなかったと推測はできます。しかしその気持ちを自分達に向けるなとこちらも相手にイラつきました。

視覚障害者を誘導して気づいた点

この経験は自分があまり意識してこなかった点に気付かされたという意味で、良い経験でした。気づいたことを挙げると次の通りです。

渋谷駅周辺は点字ブロックがほぼ無い。駅内は割とあるが、路上は皆無
渋谷駅周辺の道路は人の多さに対して、歩道が狭かったり分かれ道があったりで、視覚障害者に限らず視覚にはほぼ問題ない自分も歩きづらい
ざわざわしているところを歩くのは、歩くのに必要な手がかりが聞きづらくなるという意味で大変そう
歩いているときに前から来た人が避けてくれるとは限らないのが、大変そう
前述のカンファレンスに参加するため、行きはタクシーで来たということで、タクシー代が余計にかかりそう

自分が気づいていなかっただけで、不自由な部分は多く転がっているのを感じました。この経験が元となり、せめて自分が関わるところはアクセスしやすくしたいと考えるようになりました。

なぜ、いまの会社・サービスでアクセシビリティ向上をやるのか？

自分の考えとしてはこれまで書いた通りですが、ではなぜ、いまの会社・サービスでアクセシビリティ向上を推進するタスクフォースを作ってまでアクセシビリティ向上を推進しているのでしょうか？

その理由としては、最近会社でパーパスが発表されたことにあります。

パーパスは存在意義を示すものです。発表されたパーパスは「新しい力とインターネットで日本の閉塞感を打破する」という内容で、アクション的な項目の中に「新しい未来のテレビABEMAを、いつでもどこでも繋がる社会インフラに」があります。

そうです、会社としてABEMAを社会インフラにすることを明言しています。これによって、自分のビジョンと会社の向いている方向が合致していると感じるようになりました。また、アクセシビリティタスクフォースを立ち上げたときに「いつでもどこでも繋がる」というのは考えていて、それが会社としても明言されるようになり嬉しくなりました。

これらを踏まえて、いまの会社・サービスでアクセシビリティ向上を推進していき、やがては担当サービス外にも影響を及ぼせる様になりたいと思いました。

アクセシビリティ向上を推進する上で気をつけていること

Webエンジニアとしていま知っておきたい Webアクセシビリティというスライドにも書かれているように、特定の個性・状況・環境だけを考えて倫理観に訴えるのではなく、自分も含めたみんながもっと便利に使えて、結果ユーザーが増えていくようなベストな方法を考えていくことを意識しています。

アクセシビリティ "対応" と書くと後ろ向きな感じになりがちなのと、特定のユーザー向けに特別対応をすると捉えがちというのもあるので、アクセシビリティ "向上" を一貫して使うのも気をつけている点です。

また自分たちだけでアクセシビリティ向上をやれるところからやっています。例を出すとWCAGの達成基準を満たしているかチェックしたり、アプリをVoiceOverやTalkBackを有効にした状態で触ってみたりなどといったことはやってきました。

ただ自分たちだけでは留まらない領域もあります。例を出すと字幕対応などが最たる例でしょう。

そういった部分では自分たち以外の社内の人ともっと対話して、お互いにとってベストな物を出していきたいと考えています。

なお、いまも自分たちだけで話を閉じているわけではなく、Slackのチャンネルでアクセシビリティについて話したり考えたりするチャンネルはあり、そこである機能のアクセシビリティをより良くするための相談などがされます。

しかし相談されるなどといった受動的なコミュニケーションだけでなく、能動的なコミュニケーションをより取っていこうと考えています。

X（Twitter）の右側サイドバーを消す

2021-03-06T00:00:00.000Z

X（Twitter）のトレンドは見るたびにイラつきを覚えます。そんなにイラつきを覚えるようなら見なければいいし、そもそもX（Twitter）をやめろという話でしょう。

ただ次の投稿にある通り、ある意味で期待通りの報酬を得られる行為となります。

インターネットでQOLを1番下げる行為は、間違いなく「嫌いな人間/集団/コンテンツを自分から見に行って、嫌なものを見つけて、嫌なのを確認する」事なんだけど、これはある意味で「期待通りの報酬を得られる」行為なので、常習化を招きやすいんだよな。人生には得てはいけない成功体験があるというな。
— rei@生きてるだけで疲労困憊発売延期 (@rei10830349) September 30, 2019

そのためX（Twitter）のトレンドを見てしまうことが多くトレンドを見るたびに後悔していました。ただやめられなくなっていて正直なところ常習化していました。

なぜX（Twitter）のトレンドを見てしまうのか

X（Twitter）のページをWeb上で見ると自然とトレンドが目に入ってきます。普段見ているX（Twitter）の画面は画像の通りです。

左サイドバーにナビゲーション、中央に投稿一覧、そして右サイドバーにX（Twitter）内の回遊リンク一覧がある構成です。

この構成だと右サイドバーのX（Twitter）内の回遊リンク一覧が目に入ります。特に「いまどうしてる？」というタイトルが付けられたX（Twitter）内のトレンド一覧が目に入ります。

これはX（Twitter）側でトレンドを見てもらうことでX（Twitter）内を回遊してくれて、結果としてX（Twitter）内で追っているKPIを達成できるというデータがあるのでしょう。なのでトレンドが目に入りやすい位置へ配置されていますし、トレンドの先頭は広告枠になっているのでしょう。

ただX（Twitter）のトレンドを目に入れたくない立場からすればとにかく消えてほしいものです。あとついでにおすすめユーザーも邪魔な気がしてきました。

X（Twitter）のトレンドを視界から消す(ついでにおすすめユーザーも)

ということでX（Twitter）のトレンドを視界から消します。

今回はStylusを使って、X（Twitter）側で定義されているCSSを上書きしてX（Twitter）のトレンドのみならず右サイドバーごと非表示にしました。

なおX（Twitter）のトレンドを消す方法として、Chrome向けのX（Twitter）拡張機能であるおだやかX（Twitter）やSimplified Twitter/Xを入れる方法や、地域を変更してトレンドのみ表示できないようにする方法もあります。

X（Twitter）の右サイドバーを削除するときの課題と解決方法

X（Twitter）はReact Native for Webを使っています。

If you use X（Twitter） Lite you're now using a web app rendered by React Native for Web
— Nicolas (@necolas) September 29, 2017

これは今も変わってなさそうでHTMLに定義されているクラス名はランダムな文字列です。

このためクラス名を元にスタイル定義をすると、将来の変更でスタイルが適用されなくなりそうです。

そのためStylus上で data-* 属性のセレクタに対してスタイル定義をすれば将来的に壊れにくくなりそうという考えを持ちました。これに従って書いたCSSは次の通りです。

[data-testid='primaryColumn'] {
  max-width: 600px;
}

[data-testid='sidebarColumn'] {
  display: none;
}

このCSSを適用したX（Twitter）のスクリーンショットを見てみましょう。

見事にX（Twitter）の右サイドバーを非表示にできています。今回の目的を達成しました。

まとめ

正直X（Twitter）を見ないようにしたりアカウントを削除して何もかも見れなくしたりしたほうが手っ取り早いです。

しかし他サービスのログインに使っていたり、DMでやり取りしている人がいたり、拡散される役目をX（Twitter）に依存しがちだったり、いろいろやめられない状況でした。なので今回は妥協案として右サイドバーを非表示にしました。

プレミアム会員向けにトレンドなどを削除する機能を作ってほしいですが、広告枠の扱いなども考えると難しそうです。

PreactとTypeScriptを使った環境でStorybookを使う方法

2021-01-14T00:00:00.000Z

PreactとTypeScriptを使った環境でStorybookを使おうとしたら以下のエラーが出ました。

原因はStorybookを使うために必要なパッケージとBabelの設定が足りなかったことでした。

なので、storybook/lib/cli#Manually specify project typeを参考に、次のコマンドを実行します。

npx -p @storybook/cli sb init --type preact

そして .babelrc.js を次のような設定にします。

const presets = ['@babel/preset-env', '@babel/preset-typescript'];
const plugins = [
  [
    '@babel/plugin-transform-react-jsx',
    {
      runtime: 'automatic',
      importSource: 'preact',
    },
  ],
];

module.exports = { presets, plugins };

これでYarnを使っている環境であれば yarn storybook をターミナル上で実行することで、Storybookが表示されるようになります。

参考にしたページ

Uncaught ReferenceError: h is not defined · Issue #541 · preactjs/preact-compat

WindowsでもmacOSのようなキー操作を実現する

2020-08-30T00:00:00.000Z

前からmacOSのようにWindowsでもCtrlキーを使ったカーソル移動をおこないたいと思っていました。
またmacOSのショートカットはCommandキーを使うことが多いため、Windowsでも各種ショートカットにWindowsキーを使うようにしたいと思っていました。

今回これらを実現するべく、レジストリエディターとAutoHotkeyを使って、キーボードショートカットを望む形にしました。

レジストリエディターを使って、左の Windows キーを F13 キーに変更する

Push To Talk Fix - Remapping keys to F13内にある「Remap Left Windows Key to F13」を適用します。
次のレジストリ情報を任意の場所に .reg 形式で保存して実行したあと、PCを再起動すれば左のWindowsキーがF13キーに変わります。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,64,00,5b,e0,00,00,00,00

AutoHotkey を使ってキーボードショートカットを実装する

キーボードショートカットの設定は次の通りになりました。

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
#UseHook, On
#SingleInstance, force
; F13 & Warn  ; Enable warnings to assist with detecting common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

; macOS like keymap
F13 & /::^/
F13 & ,::^,
F13 & 1::^1
F13 & 2::^2
F13 & 3::^3
F13 & 4::^4
F13 & 5::^5
F13 & 6::^6
F13 & 7::^7
F13 & 8::^8
F13 & 9::^9
F13 & 0::^0
F13 & a::^a
F13 & b::^b
F13 & c::^c
F13 & f::^f
F13 & h::^h
F13 & i::^i
F13 & k::^k
F13 & l::^l
F13 & n::^n
F13 & p::^p
F13 & q::!F4
F13 & r::^r
F13 & s::^s
F13 & t::^t
F13 & v::^v
F13 & w::^w
F13 & x::^x
F13 & z::^z
F13 & Enter::^Enter
F13 & Space::#s
; https://superuser.com/questions/1246946/autohotkey-remapping-altshifttab-to-lwinshifttab
F13 & Tab::
    AltTabMenu := true
    If GetKeyState("Shift","P")
        Send {Alt Down}{Shift Down}{Tab}
    else
        Send {Alt Down}{Tab}
return

#If (AltTabMenu)
    ~*F13 Up::
        Send {Shift Up}{Alt Up}
        AltTabMenu := false
    return
#If

; Windows keymap
F13 & e::#e
F13 & Up::#Up
F13 & Right::#Right
F13 & Down::#Down
F13 & Left::#Left
#IfWinNotActive, ahk_exe WindowsTerminal.exe
Return
#IfWinNotActive

; Emacs like keymap
#IfWinNotActive, ahk_exe WindowsTerminal.exe
^p::Send,  {Up}
^f::Send,  {Right}
^n::Send,  {Down}
^b::Send,  {Left}
^+p::Send, {Shift}+{Up}
^+f::Send, {Shift}+{Right}
^+n::Send, {Shift}+{Down}
^+b::Send, {Shift}+{Left}
^a::Send,  {Home}
^e::Send,  {End}
^d::Send,  {Delete}
^h::Send,  {BackSpace}
^m::Send,  {Enter}
^k::Send,  {Shift}+{End}{BackSpace}
Return
#IfWinNotActive

先ほど左のWindowsキーをリマップして作り出したF13キーをふんだんに使って、WindowsのControlキーを使ったキーボードショートカットをF13キーを使うように変更しています。
ControlキーについてはEmacsっぽくカーソル移動のショートカットに割り当てています。
Windows Terminalを使っているときはショートカットを無効化したかったため、[AutoHotKey]#IfWinActive で対象ウインドウを指定する | Output 0.1を参考にしてショートカットを無効化しています。

まとめ

Windowsをメインで使い始めてだいぶ経ちますが、ようやく思い通りの操作ができるようになって嬉しいです。

ブログの記事管理をContentfulからGitリポジトリに変更した

2020-05-18T00:00:00.000Z

このブログは最初はてなブログで書いていて、1年前にこっそりNext.js + Contentfulという仕組みに変えて運用していた。今回仕組みをふたたび変えて、MarkdownファイルをGitリポジトリにコミットしていく形式にした。

コミットしたMarkdownファイルはGitHub上へpushするとVercelのGitHub integrationによってVercel上にデプロイされる仕組みとなっている。その辺の仕組みについてコードを読みたい人は entryConverter.ts と entriesJsonBuilder.ts を読むと良い。

なぜ Contentful から Markdown ファイルを編集する形式に変えたのか

理由は3つある。

1. Contentful の Markdown エディタの挙動が信用できなくなった

リモートワーク体制になって変わったこと・変わらなかったことの記事を書いていたときに、下記の事象に遭遇した。

Contentfulのエディタで記事を書いていたら自動保存のタイミングでIMEが確定されていたようで、文章がめちゃくちゃになっていた。そしてその状態がエディタに表示されてなかったので、何も対策できなかった…https://t.co/IDBnTnzZf6
— kubosho (@kubosho_) April 22, 2020

Contentful Community にも同様の問題が報告されていた。Markdownエディタを使ってフルスクリーン状態で記事を書いていたらこの問題が発生した。後日問題が再現するか試したが、再現しなかったので複合的な要因でバグる可能性が考えられる。

とはいえ、記事を書くときに「記事ちゃんとした形で保存されているのかな…」といった余計な思考が混ざることで記事を書くことを億劫にさせるし、安定した環境で書きたくなった。

2. Contentful の編集画面が気に食わない

ブログ記事を書くときに自分は本文部分とプレビュー部分をそれぞれ横並びに表示したい。どういうことかは次に示すはてなブログの編集画面の画像を見てもらうと分かる。

だがContentfulの編集画面は1カラムになっている。次に示すContentfulの編集画面の画像を見てもらうと分かるように自分の理想とするレイアウトになっていない。

一応Contentful上のContent modelから本文のエディタをMarkdownエディタにしたうえでフルスクリーンモードにすると、編集画面とプレビュー画面が横並びに表示されるようにはなる。ただこの表示にすると、先ほど書いたように本文がとんでもないことになることがあるので詰んでしまう。

またMarkdownエディタにした場合、エディタ部分のfont-familyに font-family: SFMono-Regular,Consolas,Liberation Mono,Menlo,monospace!important; が指定されているため、特にWindows環境だと文章を書く気力を失う見た目になる。

3. 思ったよりいろんな環境でブログの記事を書かない

いつどこでもブログの記事を書けるようにしたいがWordPressは導入が面倒だなと思って、裏側をHeadless CMSひいてはContentfulにしてみたものの、スマホやタブレットでブログの記事を書くことはなかった…

実際に運用してみたらほぼパソコンからしか記事を書いていなかったので、だったら使い慣れたテキストエディタ上で記事を書けたほうが筆は進むのではと思い、移行に至った。

実際この記事も使い慣れたVisual Studio Code上で書いているが、使い慣れているだけあって頭のリソースを100%文章に向けられている。これで良かった。

まとめ

ちゃんとユースケースを考えよう。

WSL上のChromiumでPDF出力をする

2018-08-05T00:00:00.000Z

Windows Subsystem for Linux(WSL)上でHeadless Chromeを使って、PDF出力をしてみました。
やり方としては次に示すコマンドを実行すれば、Cドライブ上のTempフォルダの中にGoogleをスクリーンショットした output.pdf が出力されます。

sudo apt install chromium-browser
chromium-browser --headless --disable-gpu --print-to-pdf=/mnt/c/Temp/output.pdf https://www.google.com

TypeScriptでsetInterval()の型が合わない理由と解決方法

2018-07-18T00:00:00.000Z

@types/node に依存した状態で以下のようなコードを書いたときに Type 'Timer' is not assignable to type 'number'. というエラーメッセージが出ます。

export class ExampleClass {
  intervalId: number;

  constructor() {
    this.intervalId = 0;
  }

  start() {
    this.intervalId = setInterval(() => {
      // do something
    }, 1000);
  }

  stop() {
    clearInterval(this.intervalId);
    this.intervalId = 0;
  }
}

原因

@types/node に依存している場合 setInterval() の返り値が NodeJS.Timer となるためです。@types/node に依存していなければ setInterval() の返り値は number になります。

@types/node の型定義： https://github.com/DefinitelyTyped/DefinitelyTyped/blob/010a8de/types/node/timers.d.ts#L73-L76
TypeScriptの lib.dom.d.ts の型定義： https://github.com/microsoft/TypeScript/blob/3431912/lib/lib.dom.d.ts#L16739

解決方法

1. `setInterval()` を使う箇所で `window.setInterval()` とする

window オブジェクトにある setInterval() の返り値の型は number となっています。なので window.setInterval() が使える環境であれば window.setInterval() と書き換えることで解決します。

参考： setInterval - Type 'Timer' is not assignable to type 'number' · Issue #1053 · TypeStrong/atom-typescript

2. `setInterval()` の返り値を入れるプロパティの型を変更する

window.setInterval() と書き換える方法は、SSRをしているときには使えません。たとえばNext.jsを使っている場合にはエラーが出ると思われます。

この場合は以下のように intervalId の初期値に null を入れておいて、clearInterval() を実行するところで setInterval() の返り値が this.intervalId に入っているか確かめる方法があります。

export class ExampleClass {
  intervalId: NodeJS.Timer | null;

  constructor() {
    this.intervalId = null;
  }

  start() {
    this.intervalId = setInterval(() => {
      // do something
    }, 1000);
  }

  stop() {
    if (this.intervalId) {
      clearInterval(this.intervalId);
    }

    this.intervalId = null;
  }
}

3. `setInterval()` 全体を `Number()` で囲む

关于typescript的定时器setInterval()坑_ollin2012的博客-CSDN博客_ts 定时器类型で紹介されている手法を多少改変して、setInterval() 全体を Number() で囲んで number 型にtype assertionする手法もあります。

export class ExampleClass {
  intervalId: number;

  constructor() {
    this.intervalId = 0;
  }

  start() {
    this.intervalId = Number(
      setInterval(() => {
        // do something
      }, 1000),
    );
  }

  stop() {
    clearInterval(this.intervalId);
    this.intervalId = 0;
  }
}

まとめ

手癖のように intervalID が入るところで初期値として 0 を代入していましたが、TypeScriptではハマる可能性が高いので気をつけましょう。

Atomic Designを実案件に導入して運用してみた結果はどうなのか

2017-12-18T00:00:00.000Z

かつてAtomic Design の考え方と利点・欠点という記事を書きました。この記事内で日本ではAbemaTVで使われていると書きました。そして今でもAbemaTVではAtomic Designの考えに基づいてコンポーネントが作られています。

AbemaTVでの経験を通じて、Webアプリケーションのクライアントサイドの開発者という立場からAtomic Designはどうなのかについて書いていきます。

なおAbemaTVではビューライブラリとしてReactを使っているので、React前提の話になります。

Atomic Design に基づくのは実際どうなのか

基本的には良いです。良い点について書いていたらAtomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comやAtomic Design powered by React @ AbemaTVに書いてある内容と似てきたので、良い点についてはこれらの資料を見てください。

ただし問題点もあります。いま思いつく限りでは大きく2つ問題があると考えています。

人によってコンポーネントの粒度が違う

Atomic Designにおいて atoms はそれ単体で使うことはなく molecules や organisms 内に取り込まれた状態で使われます。

また molecules にあたるコンポーネントは単一責任の原則に基づくのが良いとされています。

しかしコンポーネントによっては props が多すぎるものもあります。特に molecules の一部コンポーネントは props が22個あります。実際に該当のコンポーネントは挙動を変更する理由がいくつかある状態です。

この場合は責務ごとにコンポーネントを分割すれば良かったでしょう。もしくはHigher-Order Components - Reactを取り入れても良さそうです。

デザイナーとデベロッパーのコンポーネントの粒度も違う

今だとデザイナーがSketchのSymbol上に構築したコンポーネントの粒度とデベロッパーが実装したコンポーネントの粒度が違うものもあります。

デザイナーとデベロッパーのどちらかの考えに粒度を合わせるのが良いでしょう。この場合、基本的にはデザイナーの考えに合わせたほうが良いです。morishitter の CSS の書き方（2016 年夏） - morishitter blogにもある「デザインの意図を正確に理解した上で書かれたCSSは破綻しない」です。

とはいえ、自分もあまり余裕がなかったため「なぜこのデザインなのか」をあまり聞けていません。Slack上でどのデザインにするかやりとりしているときに「これが良いですねー」とか反応するくらいです。

Pattern Lab のデモに作りたいコンポーネントのカテゴリーがあったらお互いそれに沿うのがいいでしょう。たとえば blocks だったら molecules で sections だったら organisms という感じです。

コンポーネントのテストが面倒

コンポーネントのテストを書く場合は enzyme を使って find() などを用いて要素があるかを探し、表示されている文字が期待のものと合致しているかなどをテストします。

この場合テストとは直接的に関係ないコードがテストコード内に存在してしまいます。テストを書くときにVirtual DOM内をいちいち探索しないといけなくなるため、そこまでテストコードが書かれていないコンポーネントが増えることにもなります。また各コンポーネントがどのような props を持っているか調べないといけないため特に organisms にあたるコンポーネントのテストは面倒になるでしょう。

そのためJestのSnapshot Testingのように、スナップショットとなるコードを書いてテストコード側でそれと合致するか確かめるようにする流れができつつあります。

この記事はAbemaTV Advent Calendar 2017の17日目の記事でした。

CSSを破綻させない

2016-12-14T00:00:00.000Z

12/3（土）にCSS を破綻させないという内容をbuilderscon tokyo 2016で話しました。

そこで使った発表資料の内容を編集した上で、CSS Advent Calendar 2016 14日目の記事として公開します。

CSS は破綻しやすい

OOCSSの提唱者Nicole Sulliban氏も"CSS is too fragile"と2008年のイベントで言いました。なぜ破綻しやすいのか。それはCSSの特性が絡んでいます。

CSS の特性

CSSの特性としておもに3つあります。

はじめに、記述を間違えてもエラーにならないことです。ブラウザで表示確認をおこなって初めて見た目がおかしいことに気づきます。

次に、スタイルが適用される条件としてルールセットを書く順序は関係ありますが、常に関係があるわけではない点です。

ちなみにルールセットはCSSのセレクタ・プロパティ・値の定義をまとめたものです。
分かりやすい図としてCSS ルールセット構造図 · terkel.jp内の画像があるので引用します。

最後に、ルールセット間で同じプロパティが定義されている場合、順序・詳細度・重要度にもとづいて適用されるスタイルが決定されます。CSSをややこしくしているのはここですが、意識して書かないと容易に破綻します。

ここからは実際にCSSが破綻した例を見ていきます。

CSS の破綻

CSSの破綻はいくつか種類があります。これらの要素のうち2つ以上が複合して起きていると手がつけられないCSSになります。

スタイルの上書きが複数ある

スタイルの上書きはBootstrapなどCSSフレームワークを使うときに独自の見た目を実現しようとすると起こりがちな問題です。スタイルの上書きが多くなるとどんな見た目になるのか予測できなくなり破綻します。

.button {
  border: 1px solid #ccc;
}

/* ...長いコードの後や別ファイルなど... */

.button {
  border: 1px solid #666;
}

/* ...長いコードの後や別ファイルなど... */

.article .button {
  border: 1px solid #00c;
}

前に書いたセレクタの詳細度が高い

前に書いたセレクタの詳細度が高くてスタイルが上書きできないことも破綻の一因になります。先ほどのスタイルの上書きを多くしていると起こりがちな問題です。これがもたらす結果としては !important の濫用です。

/* 詳細度はa=0, b=4, c=0なので0.4.0となる */
.container .form .form-group .form-submit-button {
}

/*
  詳細度はa=0, b=1, c=0なので0.1.0となる
  上書きできない。つらい
*/
.form__submit-button {
}

命名規則がバラバラ

よくあることとして単語の区切りがケバブケース・キャメルケース・スネークケースのようにバラけていると、どの規則に合わせればいいのか分からずいつまでも命名規則が統一されません。

.account-login-button {
}

.commentSubmitButton {
}

.form_submit_button {
}

CSS の破綻まとめ

ここまでCSSが破綻する理由について書きました。まとめると次のとおりです。

詳細度が管理されていない
ルールセットの分割粒度が明確ではない
命名規則が決まっていない

CSS を破綻させない

ここからはCSSを破綻させないためにはどうすればいいのかを書いていきます。

詳細度を管理する

CSSなどのファイルを分割するときはファイル内で下へ行くにつれて詳細度が高くなるようにします。またセレクタ定義やIDセレクタを書きすぎないようにするのも重要です。

例を挙げるとフォーム共通のスタイルを適用するときにセレクタを定義しすぎないことです。これにより少ないセレクタ定義で適用したスタイルを上書きできて秩序が保てます。

/* 詳細度はa=0, b=2, c=0なので0.2.0となる */
.form .form-button {
  margin: 0;
}

/* ... */

/*
  詳細度はa=0, b=2, c=0なので0.2.0となる
  記述の順序が後なので値が上書きされる
*/
.comment-form .form-button {
  /* 上書きできる */
  margin: 10px auto;
}

ルールセットの分割粒度を明確にする

スタイルの上書きを減らすためにルールセットの分割粒度を明確にすることも重要です。これはさまざまな方法が提案されていて、たとえばFLOCSSやSMACSS、ECSSなどがあります。

これは作るものによって適しているものは違ってきます。そのため一概にどれがいいか言えません。スタイルを適用したいときにルールセットをどこに置けばいいのかチーム内で迷わないようにするのが重要です。

命名規則を決める

命名規則もMindBEMdingやECSS、SMACSSなどさまざまなものがあります。これもチーム内で使う命名規則を一致させることが重要です。

CSS を破綻させないまとめ

ここまでCSSの破綻を起こさないためにどうしたらいいか書きました。まとめると次のとおりです。

詳細度を管理する
チーム内でルールセットの分割粒度を明確にする
チーム内で命名規則を決める

しかしこれらを実践する前により大事なことが1つあります。それはデザイナーとの認識合わせです。

これはデザインの意図を正確に理解した上で書かれた CSS は破綻しないという言葉があります。

デザイナーが作ったSketchやPhotoshopのファイルを見て質問や提案をおこない、デザイナーとUIを実装する人で意図の認識を合わせることが重要です。もっと言うならSketchやPhotoshopなどでUIデザインを作る前のプロトタイピング段階から関わるとお互い意図の認識がしやすくなります。

これを踏まえてまとめると、チームで議論して良いCSS設計を考えようになります。

CSS がすでに破綻している場合は？

buildersconのQ&Aで「途中から入ったプロジェクトのCSSが破綻していた場合どう改善したらいいのか？」というのがあったのですが、今のところチームで話し合って設計指針を決めて1から書き直すしかないと考えています。

参考資料

Atomic Designの考え方と利点・欠点

2016-07-19T00:00:00.000Z

Atomic Designはデザインシステムを作る方法論となります。デザインシステムというのはスタイルガイドやブランドのガイドラインなどを指すようです。

日本だとAbemaTV（アベマ TV）で使われています。（Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comより）

Atomic Designは今までのページ単位と違いコンポーネント単位でデザインカンプを作る考え方です。作ったコンポーネント同士の組み合わせでページを作ります。

Atomic Designはコンポーネントの単位を5つに分けています。その5つの単位はAtoms（原子）・Molecules（分子）・Organisms（有機体）・Templates（テンプレート）・Pages（ページ）です。各コンポーネントの詳細は次のとおりです。

Atoms（原子）

Atoms（原子）は、UIを構成する基礎的な要素が該当します。

フォームでいうと、画像で示すようにラベル・入力部分・ボタンの各要素がAtomsとなります。他の要素では、カラーパレットやフォント、アニメーションがAtomsに入ります。

Atomsに振り分ける基準としては、対象の要素が機能的にそれ以上分割できない 場合、Atomsへ振り分けます。フォームで例えると、ラベルはそれ以上機能的に分割できません。また入力フォームやボタンもそれ以上機能的に分割できません。

Atoms単体だと抽象的でどういう意味を持つかは分からないです。入力フォームだけ見ても、それがアカウント登録フォームもしくはコメント入力フォームという情報は読み取れません。

Atomsはコンポーネントの基礎部分になります。それは、Atomsを組み合わせてより大きなコンポーネントを構成するという点から言えることです。

またAtomsを俯瞰できるページを用意しておくことで、そのページがどのようにデザインされたかという雰囲気を感じ取ることができます。それによりページデザインに一貫性を持たせることができます。

Molecules（分子）

Molecules（分子）は、Atomsを組み合わせて作る要素です。このAtomsを組み合わせてMoleculesを作るというのは「単一責任の原則」やUNIX哲学の「1つのプログラムは1つのことをうまくやる」に基づいているようです。

Moleculesになることで意味を持つ要素となります。たとえば、Atomsであるラベル・入力フォーム・登録ボタンという3つのコンポーネントがあってもそれら単体は意味をなしません。しかし、これらの要素を組み合わせることにより「ラベルで示したことに応じて、入力フォームに何かを書いて、登録ボタンを押す」という意味が示せるようになります。

Moleculesはできるだけ単純にして、再利用性やUIの一貫性を高めます。

Organisms（有機体）

Organisms（有機体）は、AtomsやMolecules、また他のOrganismsを組み合わせて作る要素です。今までのAtomsやMoleculesとは違い複雑な要素になります。ヘッダーやフッターと呼ばれる要素はこのOrganismsになります。

たとえば画像で示すようなヘッダーは「タイトル」というAtomsと、「ナビゲーション」「SNSのボタン群」というMoleculesが組み合わさって、ヘッダーというOrganismsになっています。

Organismsからそのページの特色が出やすくなります。

Templates（テンプレート）

ここからAtoms（原子）・Molecules（分子）・Organisms（有機体）といった化学的なものに例えることをしなくなります。これは仕事の依頼元や上司・同僚に見せるものということを明確にするため、より一般的な言葉を使います。

Templates（テンプレート）の説明に移ると、Templatesはページ構造を説明するものです。TemplatesはMoleculesやOrganismsを組み合わせて作ります。

Templatesの段階ではページ内容がまだ仮となります。Templatesを言い換えるなら「ワイヤーフレーム」になります。

Pages（ページ）

Pages（ページ）は、Template内へ実際の文章や画像などが入ったものとなります。

ここまで5つの要素について概要を書きました。要素の振り分けかたについて、どのように考えたらいいかはAtomic design is for user interfaces内のInstagramで例えたものが分かりやすいです。

Atomic Design の利点

さて、Atomic Designを実際に適用した結果、次に挙げる3つの利点があると感じました。

名前がついている

Atomic Designはコンポーネントの大きさによって、それぞれAtoms・Molecules・Organisms・Templates・Pagesという名前がついています。この名前がついていることで、Atomsは「それ以上分割できないコンポーネント」ということや、Moleculesの「Atomsを組み合わせた意味があるコンポーネント」という特徴が共有されやすくなります。

デザインの変更に対応しやすくなる

Atomic Designの考え方でコンポーネントを作ると、デザイン変更に対応しやすくなり再利用性も高くなります。特にAtomsやMoleculesへ振り分けられるような細かいコンポーネントはデザイン変更にも強いです。

今回適用したページはそこまでデザイン変更が起こりませんでした。それでもデザイン変更があったときはいつもと比べて他コンポーネントへの影響を考えずに対応できました。

セレクタの詳細度が平坦に近づく

Atomic Designを適用するとセレクタの詳細度が平坦になるようです。

次の画像は今回Atomic Designの考え方を使って作ったCSSの詳細度を示したグラフですが、割と平坦なグラフになっています。

またAtomic Designを採用しているAbemaTVのCSSも突然詳細度が上がることなく平坦なグラフです。ただこれは中の人になって分かったことですが、CSS Modulesの仕組み（css-loader）を取り入れているためCSSは各コンポーネントごとにスコープが閉じた状態で書くことができます。そのためセレクタの詳細度をあまり上げなくてもスタイル宣言をできるため、詳細度が抑えられています。

Atomic Design の欠点

利点ばかりではなく、Atomic Designの欠点も見えました。

デザイナーがどのようにデザインしていけばいいか分からない

Atomic Designは「小さい単位でコンポーネントを作り大きいコンポーネントにしていく」というデザイン手法です。そのため、フロントエンド実装では利点があります。

しかしデザイナーからすると、Atomic Designの考え方でデザインすることは難しそうです。デザイナーにAtomic Designについて説明しましたが、いきなりの手順変更は難しかったため、デザインしてもらうときはコンポーネント単位ではなくページ単位でデザインしてもらう従来の方法をとりました。

デザイナーによるページデザインの段階でAtomic Designを取り入れることに関しては、どうしたらいいのかまだ分かりません。

欠点に対しての対応

今回はコンポーネントリストを作りました。以下のjsfiddleではかなり簡略化したリストですが、以下のようにAtoms・Molecules・Organismsとコンポーネントを分けて見せるようにしました。

デザイナーには通常通りページ単位でデザインカンプを作ってもらいました。そして、自分のほうでそのデザインカンプを見つつ、Atomic Designの各単位に要素を切り出し、コンポーネントを作りました。

作ったコンポーネントリストをプランナーやデザイナーに共有しておくことで、実機でどのように表示されるか分かりやすくなることと、開発者にも共有しておくことでコンポーネントを使うことを促し、結果としてコード量や実装の工数を減らすことを目論みました。また、コンポーネントリストは作っておくと、どのようにコンポーネントを分割するか意識できます。

まとめ

今回初めてAtomic Designの考え方でページを作ってみました。結果としては、思ったより良い感じにハマった感があります。今後もAtomic Designの考え方に照らし合わせてコンポーネントを作り、変更に強く分割されたコンポーネントを作っていきたいです。

出典

Chromium のチャンネル間で変更された点を確認する方法

2016-05-13T00:00:00.000Z

とある事情により、Chromiumのstableとbetaチャンネル間で変更された点から、バグが直されたコミットはどれなのか確認する必要に迫られました。
その時どのようにして目的のコミットにたどり着いたのか書いていきます。

Chromium の各チャンネルのバージョンを確認する

OmahaProxy - Google Chromeというページで確認します。
これは各OSのChromeのチャンネルごとに現在のバージョンを表示しているページです。

Chromium のチャンネル間で変更された点を見る

実際に先ほどのページからstableとbetaチャンネル間で変更された点を見てみます。それには画像内でも矢印で指していますが、任意のチャンネルのchangelog部分にある「cr」というリンクをクリックします。

すると、選択したチャンネル（以下の画像ではdevチャンネル）の前と現在のバージョンで変更された点が見られます。

ここからstableとdevチャンネル間で変更された点を見るにはアドレスバー上で以下のようにURLを書き換えます。

https://chromium.googlesource.com/chromium/src/+log/:start..:end?pretty=fuller

たとえば2021/3/6現在のstableとdevチャンネル間で変更された点を見たい場合は :start にstableチャンネルのバージョンを :end にdevチャンネルのバージョンを入れます。

https://chromium.googlesource.com/chromium/src/+log/50.0.2661.102..51.0.2704.47?pretty=fuller

すると、以下のような感じでstableとbetaチャンネル間で変更された点を見ることができます。

あとはブラウザのページ内検索機能を使い、適当な語句で検索して目的のコミットを見つけるだけです。

Nicoのこれまでとこれから

2015-12-08T00:00:00.000Z

Bootstrap Advent Calendar 2015 8日目の記事です。ここではBootstrapのテーマの1つである、Nicoのこれまでとこれからについて書きます。

これまで

まずはNicoができてから、現時点の最新バージョンであるv3.3.6-1.1.0までの軌跡を振り返ります。

はじめにNicoを作ったきっかけとしては、現在冬コミに向けて執筆中のサイト制作のSTART:DASH!!という同人誌です。同人誌の目的上、ラブライブ！のアニメにでてきたラブライブ参加者募集サイトを実際に作る必要がでてきました。ただ1からCSSを書くのが面倒と感じた自分は、Honokaをforkし、オリジナルのBootstrapテーマを作ることにしました。

このラブライブ参加者募集サイトですが、図1のアニメ画像キャプチャを見て分かるように配色がピンク系となっています。配色がピンク系ということは、にこしかいないということで、名前がNicoに決まりました。

しかしHonokaをforkしてできあがったNicoですが、リポジトリーのファイルを見ているうちにいろいろと作業環境を整えたくなりました。そのためまずは作業環境を整えました。

作業しやすくするためのSTART:DASH!!

主にやったことは3つあります。

1つめは、Gruntをなんとなく気分的にグローバルインストールしたくないと思ったため、npmのrun-scriptでラップしました。

2つめは、scssファイルがちゃんとできるか自動で確認したかったので、Travis CIを導入しました。

3つめは、Travis CI導入に関係していますが、HonokaだったりNicoの公開用ファイルをgh-pagesブランチに上げる際は手動で上げないといけませんでした。
しかし手動は面倒だと感じたため、よしなにgh-pagesブランチへpushしてくれるシェルスクリプトを書きました。

Nico襲来

これで作業がしやすくなったので、ようやく配色をHonokaからNico仕様にしていきます。
配色を考える上で真姫・凛・花陽・絵里・希のイメージカラーを入れたいと思い、考えた結果次のような配色になりました。
dangerが紫色になっているのは、希のイメージカラーを入れたいためだったのですが、一応根拠もあります。
それは、天気予報で特別警報の配色が紫色というところから来ています。

名前	カラーコード	色
default	`#f3d4df`
inverse	`#ff50ac`
primary	`#ff50ac`
success	`#4caf50`
info	`#5cfaf9`
warning	`#ff5052`
danger	`#ac62ff`

そしてNico v3.3.5aをリリースという流れになります。

なんとかしなきゃ！

リリースした後は、Honokaのバージョン更新に追従していくだけだったのですが、ある時自分の中で事件が起こります。それは、商用利用無料！Bootstrap 3, Bootstrap 4をベースに最近のUIデザインのトレンドを取り入れた新作テーマのまとめ | コリスという記事にHonokaとUmiは掲載されたのですが、Nicoが掲載されなかったことです。最初は自分で使うために作ったとはいえ、せっかく作ったし他の人にも使ってほしいと思った自分にとって、ショックを受けた出来事でした。

この時にはHonokaのサイトからNicoがリンクされていたので見てないということはたぶん無いはずですが、それでも掲載されなかった理由を考えて、配色的に使いづらさがあったという結論に至りました。

特にinfoの色が強すぎること、またwarningとdangerの色が元のBootstrapだったり、Honokaとかけ離れているのが原因でしょう。そのため、v3.3.5-1.0.0より次のような配色にしました。基本Honokaを踏襲しつつ、モノクロで見たときにprimaryよりsuccessの色が強くなるよう調整しました。またinfo > warning > dangerの順に色が強くなっています。

名前	カラーコード	色
default	`#f3d4df`
inverse	`#ff50ac`
primary	`#ff64b1`
success	`#0faf20`
info	`#a27dac`
warning	`#ff7302`
danger	`#f45042`

なおdefaultとinverseも色を変えれば使いやすくなりそうですが、これを変えてしまうとNicoがNicoで無くなってしまうため、変える予定は今のところありません。

これから

というわけで必要に迫られて作り、いろいろと更新したNicoですが、これからの展望としてはHonokaの変更にできる限り付いていきたいです。なんだかんだでBootstrapは便利ですし、しばらく廃れないはずです。このNicoやHonokaを通じてBootstrapがどのように進化していくのかを見ていきます。

なぜ CSS や Grunt はつらいと言われるのか

2015-11-12T00:00:00.000Z

少し主語を大きく書いてしまいましたが、*.css と gruntfile.js についての話です。

「CSS に死を！」と言われたり、「CSS 勉強するのはだるい」と言われたりしますが、これらを見ていると「Gruntがつらい」という話と共通項があると感じました。

どちらも設定ファイルである

自分の考えとして前提を書くと「*.css と gruntfile.js はそれぞれ「どのような見た目にするか」「どのようなタスクを実行するか」を定義するための設定ファイルである」という考えです。

その前提のもと、設定ファイルであるという利点と欠点をこれから書いていきます。

利点

少ない行数の時の見やすさ

*.css や *gruntfile.js は200-250行くらいまでなら、ソースコードの全体が少ない時間で把握でき、何をしているものなのかすぐに分かります。

敷居の低さ

CSS・Gruntともに、ブログやQiitaなどに上がっているソースコードをコピペしてくれば、なんとなくそれっぽい見た目になったり、タスクが実行できるようになります。

欠点

破綻しやすい

CSSはすぐに、無計画にルールセットを増やしたことによるファイルサイズの肥大化、スタイルの思いもよらぬ上書き（それに伴う !important地獄）、必要ないルールセットの放置などが発生します。

Gruntも、無計画にタスクを増やしたことによるファイルサイズの肥大化、必要ないタスクの放置が発生しやすいと感じます。

ファイルサイズの肥大化については、CSS・Gruntともにファイルを分割すれば良いという話ですが、CSSは @importを使うとCSSファイルの読み込みが並列でおこなわれないため、全てのCSSファイルを読み込むための時間がかかってしまう問題を抱えています。

また、GruntもloadTasks() を使えば別ファイルに分割したタスクを読み込むことはできます。しかし、定義されているタスクの一覧性が悪くなるということと、読み込んだタスクが何をやっているのかを見るのが若干面倒という問題を抱えています。

手法が複数ある

CSSはMindBEMdingだったり、SUIT CSSだったり、セレクタの設計手法が複数あります。

また、画像置換の手法についても、昔ながらの text-indent: -9999px; とする手法から、text-indent white-space overflow を組み合わせる手法、擬似要素を使う手法など複数あります。

Gruntも例えばSassをCSSにコンパイルしたいといった時に、gruntjs/grunt-contrib-sass を使えば良いのか、sindresorhus/grunt-sass を使えば良いのか、分からなくなります。

複数ある手法から最適解を求めたいところですが、そこに至るまでの時間が長くなりがちで、それがだるさに繋がります。

CSS が gulp から学べる点はなんなのか？

と、書いてみたものの、特に思い浮かばないので、ここは任せました。

fs.exists()がdeprecatedになった理由

2015-09-20T00:00:00.000Z

wearefractal/vinyl-fs の dest(folder, [opt]) が出力先のディレクトリが無い場合でも、そのディレクトリを作ってくれないということで、自分で「ディレクトリの有無を確認して、無い場合はディレクトリを作る」という処理を作る必要がでてきました。

そこで File System Node.js v4.1.0 Manual & Documentation を見て、ディレクトリの有無を確認するのに使えそうな fs.exists() というAPIを見つけたのですが、「Deprecated: Use fs.stat or fs.access instead.」ということで、他のAPIを使うように書かれていました。

「ファイルの有無を確認するAPIがdeprecatedになるのはなぜ？」と疑問に思い、調べた結果をまとめます。

本題

まず fs.exists() ですが、ドキュメントを見ると下記のようなコードが載っています。

fs.exists('/etc/passwd', function (exists) {
  console.log(exists ? "it's there" : 'no passwd!');
});

この中のcallback関数を見ると、引数として、与えられたパスが存在しているかどうかを示す真偽値が入っていますが、この引数の形式が他のFile SystemのAPIのように err が第一引数になっていないため、規則に沿っていないということで、fs.exists does not follow node conventions · Issue #8369 · nodejs/node-v0.x-archive というissueが作られています。

しかし、2つ目のコメントで事態が変化しています。

fs.exists does not follow node conventions · Issue #8369 · nodejs/node-v0.x-archive

この2つ目のコメントについてはid:yosuke_furukawaの投稿を見たほうがどういうことか分かりやすいです。

@kubosho_ exists はrace condition に沿わないのでdeprecatedですね。存在チェックした後で消されたらどうするのっていう。普通に読み書きしたエラーでいいはずだし、どうしてもチェックしたかったらaccessかstatを使うというのが通例ですね。
— Yosuke FURUKAWA (@yosuke_furukawa) 2015, 9月 19

この投稿の「存在チェックした後で消されたらどうするの」というのを処理の流れに落としこむと、fs.exists() で与えられたパスが存在しているか確認し、fs.exists() のcallback関数内で fs.unlinkSync(path) としてファイルを削除した後に、callback関数の exists 引数を使って exists がtrueだったら、ファイルを開くというソースコードを書いて実行すると no such file or directory のエラーが出力されます。

実際のソースコードは下記の通りとなります。これなら fs.open(path, "r", callback) として、ファイルの有無で処理を分けたほうが入れ子を浅くできます。

話を「Nodeの規則に沿っていないというissueが作られた」というところに戻すと、issueでやりとりがあった後、fs: deprecate exists() and existsSync() by cjihrig · Pull Request #8418 · nodejs/node-v0.x-archive というPull Requestが作られます。

このPull Requestは元のタイトルが「fs: add errback style support to exists()」とあるように、互換性を保ちつつ、callback 関数の第一引数に error が入るようにしたものがコミットされていました。

Pull Request内でコードレビューがおこなわれ、Function.length のパフォーマンスが悪いという指摘があったりしたのですが、それらの指摘を踏まえてPull Requestをopenしたcjihrig氏はいくつか提案をしています（何もしない、互換性がある、または壊す形で第一引数の err をサポートする)。

しかし、再び事態が変わります。fs.exists() を deprecate にして代わりに fs.access() を使うようにするというコメントがされました。

そして、そのコメントが流れを変えて、fs.exists() は第一引数の err がサポートされることなくdeprecatedになりました。

@kubosho_ そうですね。その例の他にもNodeと無関係な全く別なプロセスからファイルが削除される事もあるから、exists => read みたいな事やろうとするのって筋悪なんですよね。突き詰めていくとexists自体の必要性が怪しくて、deprecatedっていう。
— Yosuke FURUKAWA (@yosuke_furukawa) 2015, 9月 19

まとめ

「ディレクトリの有無を確認して、無い場合はディレクトリを作る」という処理を作るために fs.exists() を使おうとしたらdeprecatedになっていて、なぜだろうと思い調べたら、fs.exists() がdeprecatedになった経緯が分かった話でした。結果として「ディレクトリの有無を確認して、無い場合はディレクトリを作る」という処理は「ディレクトリを作るように試み、既に存在したら（エラーになったら）作らない」という処理になりました。

具体的なソースコードとしては、最初は fs.exists() を使っていたため、下記のようなソースコードでした。

これを「ディレクトリを作るように試み、既に存在したら（エラーになったら）作らない」という考え方で書き換えて下記のようにしました。

結果的に、fs.exists() というdeprecatedになったAPIを使う必要がなくなり、また入れ子は浅く、ソースコードも短くなりました。

MindBEMding の Modifier は元のクラス名と一緒に指定するべきか否か

2015-05-11T00:00:00.000Z

MindBEMdingのModifierを定義する際、単一のクラスセレクタで書く方法と、複数のクラスセレクタで書く方法があります。

実際のHTMLで示すと以下のような感じです。

HTMLの複数クラス定義

<table class="mod-table-01 mod-table-01--line-color-green">
  <tr>
    <th>foo</th>
    <th>bar</th>
  </tr>
  <tr>
    <td>baz</td>
    <td>foobar</td>
  </tr>
</table>

HTMLの単一クラス定義

<table class="mod-table-02--line-color-green">
  <tr>
    <th>foo</th>
    <th>bar</th>
  </tr>
  <tr>
    <td>baz</td>
    <td>foobar</td>
  </tr>
</table>

multiple class とコメントで書かれているほうでは、クラス名は mod-table-01 と mod-table-01--line-color-green の2つが指定されています。

single class とコメントで書かれているほうでは、クラス名は mod-table-02--line-color-green のみ指定されています。

上記のHTMLに対し、CSSでルールセットを書く場合は以下のようになります。

CSSの複数クラス定義

.mod-table-01 {
  border: 1px solid black;
  border-collapse: collapse;
  margin: 10px auto;
}
.mod-table-01--line-color-green {
  border: 1px solid green;
}

CSSの単一クラス定義

.mod-table-02,
.mod-table-02--line-color-green {
  border: 1px solid black;
  border-collapse: collapse;
  margin: 10px auto;
}
.mod-table-02--line-color-green {
  border: 1px solid green;
}

この2つの指定方法のうち、果たしてどちらが良いのかというのを考えたので、以下に利点と欠点を書いていきます。

HTMLに単一のクラス名を指定する際の利点・欠点

利点：複数のクラスを指定するより、若干簡潔になる

MindBEMdingの考えでセレクタに名前を付けた場合は名前が長くなりがちです。複数のクラス名を指定した場合は、上記で示したHTMLの例を見ると分かるように冗長感が否めません。

その一方、単一のクラス名で指定した場合は、HTML側の指定は複数のクラス名指定より、簡潔になります。

欠点：スタイル定義が複雑になる

下記のJSFiddleの例を見ると分かるのですが、単一のクラス名を指定するほうが、複数のクラス名を指定するより、スタイル定義が複雑になっています。

これは例えば、後からプロジェクトに入ってきた人がCSSファイルで定義されている内容を見た時に、理解を妨げる原因になるのではという考えがあります。

欠点：CSS のファイルサイズが大きくなりがち

文字数カウント（文字バイト数チェック）で測ると分かるのですが、単一のクラス名をHTML側で指定してスタイル定義をしていく場合、複数のクラス名をHTML側で指定するより、CSSのファイルサイズが大きくなります。

HTMLに複数のクラス名を指定する際の利点

利点：スタイル定義の見通しが良くなる

再び先ほどのJSFiddleの例を引っ張り出しますが、複数のクラス名を指定する場合、単一のクラス名を指定するよりCSSのルールセット定義が簡潔になっています。

欠点：HTML上でのクラス名の指定が単一のクラスを指定するより若干冗長になる

単一のクラス名を定義する時はHTMLでは prefix-table-01--line-color-green とだけclass属性の値に書けばよかったですが、複数のクラスを定義する場合は prefix-table-01 prefix-table-01--line-color-green と若干冗長になります。

結果どちらを使ったほうが良いのか

単一のクラス名を指定するほうはHTML側が少し簡潔になりますが、複数のクラス名を指定するのと比べCSS側が複雑になりがちというのは先ほど書いたとおりです。

その複雑になりがちというのが自分ではあまり許容できなかったので、複数のクラス名をHTMLのclass属性の値として指定して、スタイル定義をしていくのが良いかなと思いました。

他の参考記事

マルチクラス設計について物申している記事もあるので、よかったらこちらも参考にしてみてください。

CSSプリプロセッサーのextendの悪いところ - morishitter blog

GitHub の Contributions を Ingress の Resistance 色にする Chrome 拡張を作った

2015-04-06T00:00:00.000Z

GitHubのContributionsを眺めていて「これってEnlightenedの色だよね」と思ったので、Resistanceの色に置き換えるようなChrome拡張を作ってみました。

Resistance Contributions - Chrome ウェブストア

ソースはこちらにあります。

kubosho/resistance-contributions

ちなみに自分はEnlightenedです。

編集しやすいCSSにするために自分が心がけている事

2015-02-23T00:00:00.000Z

CSSは、書くのが怖いと自分は感じます。

ある程度運用したサービスやアプリとなると、自分の変更した点が思いもよらぬところに反映されてしまい「しまった」と思った事はあることでしょう。

とはいえ、運用していく上で何も変更しないというのはありえません。CSSを変更する恐怖からなるべく解放されるために自分が心がけている事を書いていきます。

コメントを書く

自分の場合は、そのセレクタがどこで使われているかという情報を書く事が非常に多いです。例としては下記のような感じです。

//------------------------------------------------------------------------
//    Common: サイト上部のヘッダー
//------------------------------------------------------------------------
.prefix-global-header {
  background: #000;
}

このようにする事で区切りが分かりやすくなると思っています。また、ルールセットがどう書かれているかが、より頭の中に入ってくると自分は感じています。

ちなみに上記の区切りは、SassやLESSでしか使えない（コメントアウトに // を使っているため）ので、CSSでも区切りを付けたい場合は、inuit.cssの下記の区切りが良いなと自分は感じています。

/*------------------------------------*\
    はうはう
\*------------------------------------*/

class 名や id 名を意味のある名前にする

極端な例ですが、下記のように「要素名をそのまま繰り返しただけのclass名」というのは意味が無いです。下記の例では、いっそ要素型セレクタでスタイル指定したほうがいいでしょう。

JS Bin

では、自分はどのように名付けるかという話ですが、今は神獄のヴァルハラゲートの CSS 設計でも書いたように、MindBEMdingを使った命名にするかなという感じです。

例えば .header としているところなら、.prefix-global-header か .prefix-top-header といった命名をします。

`!important` を使う時は注意深く使う

CSSを書いていく上で、どうしても !important を使いたくなる時があります。そんな時は !important を使わないようにCSSを書き直すよりも !important を使ったほうが、時間がかからなかったり複雑にならない可能性が高いと感じています。

とはいえ !important を乱用してはいけません。改修に時間がかからなそうだったり複雑にならなそうであれば、使わないほうが良いです。

なお自分が !important を使う時は、なぜ !important を使うのかというコメントを絶対書いています。それは下記の理由です。

意味が書いてない !important は消すのが怖いため
- 消したらどこかに悪影響が出るのではという恐怖が生まれる
将来CSSを書き直した時に消せる可能性があるため
- 上記でも書いたように、なるべく使わないようにしたい

style 属性を使う時は注意深く使う

!important と同じく、乱用すべきものではないですが、かといって、ある機能に関するページが10ページくらいあったとして、そのうち1ページでしか使わない（かつスタイルを適用させたいところも少ない）となると、CSSファイル内でスタイル指定をするよりも、style属性でスタイル指定をしたほうが、時間がかからなかったり複雑にならない可能性が高いと感じています。

それ以外では、style属性を使わないほうが良いです。

最後に

ここまで、CSSを書く際に心がけている事を書いてきましたが、こういう心がけは下記の思いがあるためです。

ドキュメント残しておかないと、身軽になれないし、あとは気をつけていても病気とか事故にあって長期離脱という可能性は 0 ではないので、そうなった時に引き継いだ人が積むし、自分への恨みが起こると思うので、ドキュメントは出来るだけ残しておきたいと自分は考えている。

background-imageは仕様上アニメーションを適用できない

2015-01-15T00:00:00.000Z

CSSで @keyframes に background-image プロパティを指定してクロスフェード効果で背景画像の表示が切り替わるという動作を実装しようとしました。

実際にChromeでは期待通りの動作をしました。ただFirefoxとAndroid Browserではアニメーションどころか画像自体が表示されずなぜそうなるのか謎でした。

クロスフェードされないコードを確認するためのJSFiddle

そもそもbackground-imageはアニメーション不可能

@o_ti @kubosho_ background-image はアニメーション不可能なプロパティでだからではないですか？
— xl1blue (@xl1blue) 2015, 1月 15

！？

@kubosho_ @xl1blue ホントだ。Animatable: no だった。http://t.co/JopFQtOO5F
— 越智 (@o_ti) 2015, 1月 15

なん……だと……？

background-imageは仕様上アニメーション不可能なプロパティですが、Chromeが仕様に準拠していませんでした。

なので仕様に沿う形で書き直しました。

各ブラウザーでクロスフェードされるように書き直したコード

HTML

<div class="test-01">
  <img src="https://picsum.photos/id/0/400/200" alt="" />
  <img src="https://picsum.photos/id/1/400/200" alt="" />
</div>

CSS

.test-01 {
  position: relative;
}

.test-01 img:first-child {
  position: absolute;
  animation: crossfade 5s linear 0s infinite alternate;
}

@keyframes crossfade {
  0% {
    opacity: 1;
  }
  100% {
    opacity: 0;
  }
}

クロスフェードされるコードを確認するためのJSFiddle

神獄のヴァルハラゲートの CSS 設計

2014-12-09T00:00:00.000Z

CSS Architecture Advent Calendar 2014 9日目の記事になります。

神獄のヴァルハラゲートのCSS設計方法について振り返りつつ、こうしているということや、上手くいったところ、改善したいところを書きます。

アプリの規模

ASP.NET MVCを使っていて、View側はRazorテンプレートを使っているのですが、Razorのファイルを検索してみると以下の量となります。

find ./ -name "*.cshtml" | wc -l
    1674

実際には、これにフィーチャーフォン向けのファイルや、部分的なViewファイルも含まれています。

なので、実際CSSを適用しているファイルの量は、この検索結果よりは格段に減りますが、それでも約600ファイルはあります。

ちなみに、今年のはじめに同僚の@mayukiが、ソーシャルゲームのフロントエンドと ASP.NET MVC (Lite)というタイトルで、めとべや東京#3 (Room metro Tokyo #3)にて発表したのですが、そこには「View数は400超」と書いてあるので、1年間の運用で約200ファイル増えています。

対応端末、ブラウザー

スマートフォンでは、以下の環境でアクセスされることを想定して対応しています。

OS

iOS 6 or later
Android 2.3.x
- 重要な機能だったら、Android 2.2.xにも対応することも…
Android 4.0 or later

ブラウザー

iOS
- Safari
- WebView
Android
- Android Browser
- Google Chrome
- S Browser

iOS 6やAndroid 2系はそろそろ対応端末から外したいなと思っています。来年の今頃は対応しなくて良くなってたらいいですね。

命名規則

BEMを採用しています。ただし、セレクタの命名規則は以下のように変えています。

[prefix]-[block]_[element]-[[Modifier-Key]-[Modifiler-Value]] {
  // property: value;
}

今年のネーミングルール #CSS 設計 - < /gecko >とだいたい同じですが、以下の点が異なります。

BlockとElementの区切り文字は「_（アンダースコア）」
複数の単語を連結する場合は「-（ハイフン）」を使う
ModifierはCamelCaseを使う。例は以下の通り
- foo-Bar-Baz ([block]-[Modifier-Key]-[Modifier-Value])
- foobar-Baz ([block][element]-[Modifier-Value])
prefixは、共通で使うルールセットはプロジェクトのコードネーム、各機能のみで使うルールセットはその機能名を使う
- ガチャならprefixはgachaという感じ

あとは、hiloki/flocssのMindBEMdingの章にあるように、JavaScriptで操作されるような「状態」を表すようなModifierについては、SMACSSのStateパターンの命名のように、is-*プレフィックスを付けて.is-activeという感じにしています。

.is-activeには直接スタイル指定をすることを禁止しています。

// これはOK
.block_element.is-active {
  display: block;
}

// これはNG
.is-active {
  display: block;
}

良いところ

--や__という区切り文字より、セレクタ名が醜くならない（個人の主観です）

あとは構造が分かりやすいだったり、class名が衝突するということが少ないという、BEMやMindBEMdingを採用した人ならだいたい感じることでしょうか。

改善したいところ

prefixのところで世代管理をしなかったのは間違いだった
- 今年のネーミングルール #CSS 設計 - < /gecko >を読んで気づいた…
- 古いセレクタ名と、上記の命名規則を適用したセレクタ名が混ざっていて、辛くなることがある
Modifierを使っているclass名で、Modifier-Keyがないclass名というのは、分かりにくいのではと思った
- この章を書いて気づいた…

ディレクトリ構成

hiloki/flocss に基本は準拠しています。「基本は」と書いたのは以下のディレクトリ名を自分の好みで変えているからです。

foundation → base
object/project → object/page

使っている CSS プリプロセッサーやライブラリー

LESS
Normalize.css

LESSな理由ですが、ソーシャルゲームのフロントエンドと ASP.NET MVC (Lite)の7ページにも書いてあるように、Visual Studioとの相性が良かった（新規ファイル作成時に*.less形式でのみファイルが作れた）ことが要因です。

とはいえ、MSDN BlogsのAnnouncing new Web Features in Visual Studio 2013 Update 2 CTP2にも書かれているように、Visual Studio 2013 Update 2（ちなみに今はUpdate 4が最新）から公式にSass(*.scss形式）のファイルも新規作成できるようになったので、Visual Studioユーザーでも好みでLESSかSassかを選べるようになったと言えます。

ライブラリーはNormalize.cssくらいしか使っていないです。これはやはり同僚の@mayukiが入社したての頃に、汎用classをゴリッと書いてくれたので、ライブラリーを使う理由があまり無くなったという感じです。

CSS プリプロセッサーの機能について

extend

CSS プリプロセッサの Extend - hiloki/flocssに書かれているように、モジュールで完結するextendは許容し、それ以外は禁止しています。むやみにextendを多用すると、どこにそのルールセットが書かれているか分からなくなり破綻する、というのが大きな理由です。

ルールセットの入れ子

CSSプリプロセッサーのほとんど（全て？）はルールセットの入れ子がおこなえますが、入れ子の深さは二段階までと定めています。具体例としては以下のコードです。

.foo {
    border: 1px solid #003760;
    color: #000;
    background: rgba(0, 0, 0, 0.5);

    .nest-01 {
        font-weight: bold;

        .nest-02 {
            color: #f00;
        }
    }
}

なぜ、二段階までに抑えているのかというと、制限がなかった場合、出力後のCSSのセレクタ部分がとても長くなってしまう可能性があるということが挙げられます。

具体例を書くと、以下のようなLESSのコードがあったとします。

// Uuuugly!
.foo {
    .nest-01 {
        .nest-02 {
            .nest-03 {
                .nest-04 {
                    .nest-05 {
                        color: #333;
                    }
                }
            }
        }
    }
}

上記のコードをCSSにコンパイルした場合、以下のようになるでしょう。非常に長くて醜いです。

.foo .nest-01 .nest-02 .nest-03 .nest-04 .nest-05 {
  color: #333;
}

また、実際に挙動を確かめられていないですが、多くのサイトで「ブラウザーのセレクターの解釈として、右から左に解釈される」と書かれています。

とすると、上記のCSSは「.nest-05 → .nest-04 → .nest-03 → .nest-02 → .nest-01 → .foo」と解釈されることになります。「.nest-01 → .foo」という構造よりも解釈に時間がかかりそうです。

ちなみに、古い記事（2011年）ですが、CSS セレクタによる高速化、実際のところ « LINE Engineers' Blogに実際の計測結果が掲載されており、そこには以下のように書かれています。

スタイルを当てる要素にはできるだけclass又はIDを指定する。

子孫セレクタは重いのできるだけ減らす。
という施策に一定の効果はあるようですが、その効果が如実に現れるのはHTML、CSSのコードが非常に大きいページに限られるようです。
そのなかでも、子孫セレクタを減らす施策よりも、スタイルを当てる要素にはできるだけclass名を指定する施策のほうが、効果があるようです。

ということで、MindBEMdingの考え方を適用し、あるBlockの中でスタイルを当てたい要素には、.block_elementだったり、.block_element-Key-Valueという感じでclass名を指定し、スタイルを適用しています。

まとめ

ソーシャルゲームというのは、最初から機能が数十種類あったり、Viewのファイル数が数百ファイルを超えるということは珍しくありません。

そんな中で、CSSを書く上での指針がないと、時間が経つにつれ運用が苦痛になってきます。

例えば新しい人が入ってきたり、自分に何かあって他の人が一時的にプロジェクトに入ってきた場合、CSSを書く上での指針が無いと、どのようにCSSを書いていけばいいのか、理解に時間がかかることになります。

なのでCSSを書く上での指針を定め、それをGitHubのWikiなど目に入りやすい場所へ残しておくのが重要と、自分は考えています。

明日はotiさんです。

記事内で紹介した GitHub のリポジトリや記事

colgroup 要素や col 要素は適用できる CSS のプロパティに制限がある

2014-12-01T00:00:00.000Z

やりたかったこと

<table>
  <colgroup span="1" style="padding:10px; background:#66c; color:#fff; text-align: center;" />
  <tbody>
    <tr>
      <td>10</td>
      <td>foo</td>
    </tr>
    <tr>
      <td>20</td>
      <td>bar</td>
    </tr>
    <tr>
      <td>30</td>
      <td>baz</td>
    </tr>
  </tbody>
</table>

というHTMLを書いた際に、縦1列目にpadding, background, color, text-alignの指定が適用される想定でした。

問題

上記の HTML を書いた JS Binを見ると分かるように、backgroundの指定以外は適用されていません。なぜ？

分かったこと

W3C の CSS 2.1 の仕様書内にある Tables 17.3 Columnsを見ると分かるのですが、table-columnやtable-column-groupのプロパティが指定されている要素（col要素とcolgroup要素）には、下記4つのプロパティのみ指定できるようです。

border
- table要素にborder-collapse: collapse;が指定されている時のみ適用される
background
width
visibility

まとめ

自分が適用したかったスタイルはcolgroup要素やcol要素では適用できないことが分かったので、colgroup要素やcol要素は使わないことにしました。

その代わりに、縦1列目にclassを指定して、そのclassに適用したかったスタイルを指定することにしました。

カラーコードを正規表現を使って判定する

2014-06-15T00:00:00.000Z

カラーコードを判定するための正規表現を書きました。

^#([\da-fA-F]{6}|[\da-fA-F]{3})$

カラーコードの正規表現が合っているかどうかの検証に使った文字列は次の通りです。

// match
#339
#251
#aaa
#fff
#AAA
#cdf
#Abc3Fc
#F9012b
#afdcbf
#987345
// mismatch
#9af#f6f
339
621345
af89f8
#ggg
#fgf
#delcmi
#3r9
#-12345
#jjjjjj
#aaaaaaa
jkhfng
ff8iju

matchに挙げた文字列はカラーコードと判定されることを確認しています。またmismatchに挙げた文字列はカラーコードと判定されないことを確認してます。

正規表現の検証に使ったページ

regex101: build, test, and debug regex

学ぶ、考える、書き出す。

Web Speed Hackathon 2026参加記

どこでレギュレーション違反になったか

スコアを伸ばした段階

1日目 18:08時点「219 → 498.75点」

1日目 18:57時点「498.75 → 576.6点」

1日目 22:26時点「576.6 → 750.85点」

リポジトリのクローン

初期状態のアプリケーションをデプロイする

Lighthouse CIによる継続的パフォーマンス観測をする

パフォーマンス改善サイクルを自動で回す

バンドルサイズ分析

Webpack→Rspackへ移行し、複数の問題をいっぺんに解消する

初回スコア計測

Phase 1: 219→498点

サーバーのgzip圧縮

静的ファイルのcontenthashと長期キャッシュ

InfiniteScrollの不要な繰り返し判定の除去

Reactマウントのloadイベント待ち除去

Tailwind CSSのビルド時コンパイル

ルートベースのコード分割

CoveredImageをネイティブ<img>に置換

jQuery → native fetchへの置換

web-llmのdynamic import化

momentの除去

Phase 2: 498→576点

ReDoS脆弱性の修正

Phase 3: 576→750点

動画のGIF→MP4変換

音声の波形事前計算とビットレート削減

画像のAVIF変換とリサイズ

メディアのキャッシュヘッダーとcompression除外

画像ALTテキストのEXIF往復を廃止

Phase 4: 750点以降

AspectRatioBox を CSS aspect-ratio に置き換え

フォントの最適化（OTF → サブセット woff2 + font-display: swap）

タイマー系サボタージュコードの除去

DirectMessagePage の setInterval → ResizeObserver

crok SSE の 3秒 sleep 削除

crok SSE の sleep 削除

不要ポリフィル・レガシーコードの除去

ホーム画面におけるLCPの画像をpreloadで読み込む

useInfiniteFetchのサーバー側pagination対応

Font Awesome SVG sprite の軽量化

最終計測

振り返り

AIエージェントを使う前提になった結果

Claude CodeのSkillsでWeb機能のBaseline対応状況を確認できるようにした

なぜ作ったのか

技術的な話

Skillの構造

使ってみて

ブログにダークモードを実装した

モードの切り替え実装

OKLCH色空間の採用

コントラストの調整

まとめ

参考リンク

ブログにいいねボタンを実装した

なぜ実装したのか

いいねボタンを連打可能にした理由

完璧を求めない判断

フロントエンドの実装

LikeButtonコンポーネント

楽観的UI更新

バッファリングによるリクエスト最適化

リトライキューの実装

バックエンドの実装

いいね数を保存するためのテーブル定義

APIエンドポイント

いいね数の登録・更新

Cloudflare Cache APIによるキャッシュ

セキュリティ対策

レート制限

入力値のバリデーション

記事IDの検証

まとめ

個人の技術ブログをリニューアルした

システム構成の変更

いいねボタンの設置

CoveredImageをネイティブ`<img>`に置換

2. Contentful の編集画面が気に食わない

1. `setInterval()` を使う箇所で `window.setInterval()` とする

2. `setInterval()` の返り値を入れるプロパティの型を変更する

3. `setInterval()` 全体を `Number()` で囲む