writing-blog-post

name	writing-blog-post
description	ブログ記事を作成する

ブログ記事の作成ルール

content/blog/ の 2026-06-18 までの記事を基準とする。迷ったら 20260618-redis-streams-consumer-group.mdx / 20260615-task-queue-celery-image-resizer.mdx / 20260603-consistent-hashing-from-scratch.mdx の3本を見本にする。

ファイル形式

• パス: content/blog/{slug}.mdx（実装系は YYYYMMDD-{slug} プレフィックス）
• frontmatter:

---
title: "Celery + Redis で画像リサイズの非同期タスクキューを作ってみた"
date: "2026-06-15"
tags: ["backend", "python"]
lang: "ja"
---

• title: 「〜を作ってみた」「〜を書いてみる」「〜してみた」のように、試した・作ったというトーン。「なぜ X か」も可
• description: 書かない。省略すると記事の先頭テキストから自動生成される（resolveDescription → excerpt）。既存記事に残っているものは後方互換のためそのままでよいが、新規では付けない
• tags: 小文字の短い語（["backend", "python"]）

導入（見出しなしの先頭段落）

最初のセクションには見出しを付けない。次の流れで2〜4文。

1. 動機 →何を作ったか（「Pub/Sub の理解を深めたかったので〜を書いてみました」）
2. 使った技術スタックを1文で簡潔に（「FastAPI + Celery + Redis を使っています。」）
3. 前回記事の続きなら /blog/{slug} の内部リンクで参照する
4. 全体構成を text ブロックの ASCII 図で早めに示すことが多い

構成

実装系の典型的な見出しの並び:

（見出しなしの導入）
## 全体の構成 / なぜ X か      ← 仕組み・前提の説明
## 実装                       ← ### Publisher / ### Consumer などに分ける
## 動かしてみる                ← 実際のコマンドと出力を順に示す
## おわりに                   ← まとめ1〜2文 +「〜も試してみたいです」

• 各セクションは「何をするか → なぜそうするか」の流れ
• 「## 動かしてみる」では $ プロンプト付きのコマンドと実出力を貼り、「〜になりました」と結果を確認する
• 「## おわりに」は必ず付ける。学びを1〜2文でまとめ、最後に今後試したいことを書く

コードと図

• 説明はなるべくコードブロックの後に書く。先にコードを見せ、その下で1〜2文で何をしたかを説明する（「まずイベントを2件追記しました。」）。コード→説明の順のほうが読み手は理解しやすい
• 前提や狙いを先に置きたいときだけコードの前に1文添える程度にとどめ、詳しい説明は後ろにまわす
• コード内コメントは日本語で「なぜ」を説明する。1行コメントを積極的に使う
• ASCII アート図を text ブロックで多用する（フロー図、リング図、状態遷移、棒グラフでの可視化など）
• 出力例・棒グラフを貼って数値を地の文で読み解く

文体

• 「です・ます」の敬体で統一する（description のみ常体）
• 丁寧すぎず簡潔に。実験的・軽めのトーンを少し混ぜてよい（「面白いですね」「〜っぽい」「握りつぶす」など）
• 一文を長くしすぎない

根拠とリンク

• 技術用語の初出や主張には公式 Docs / Wikipedia へのリンクを付ける
• リンク先に実際にその情報が記載されていることを確認する。記載がなければリンクを付けない
• 自分で検証していないことを断定しない。検証した範囲を正確に書く
• 公式ドキュメントに情報がなければソースコードへのリンクでもよい

画像

• GitHub リポジトリの画像を参照する場合は raw URL を使う
  • 例: https://raw.githubusercontent.com/ryo-manba/{repo}/main/assets/{image}.png