これで最後にしたい！ Astroと立ち向かう 6度目の個人ブログ再開発

TechRAMEN 2024 Conference の登壇資料です！

https://techramenconf.net/
https://fortee.jp/techramen-24-conf

Transcript

1. Tech RAMEN 2024 Conference これで最後にしたい！ と立ち向かう 6度目の個人ブログ再開発 Astro ikuma-t
2. ikuma-t G 株式会社エンペイで働くエンジニS G 普段は React や Go、Rails を書いています3 G 初北海道 from 千葉 G フロントエンドが好きです。 田所育真 / いくま / いくまてぃー
3. 麺場 田所商店 武石本店 https://misoya.net/store/takeishi_honten/ 千葉県の味噌の田所さん
4. ikuma-t（田所育真） 千葉県の味噌の田所さん
5. 個人ブログの 度重なる作り直しをどう防ぐか これまでの個人ブログ開発経験と、現在開発中のブログからの考察 今回お話しすること
6. ブログを続けるための習慣術 Googleアナリティクスを楽しみにするとか、毎日1分でもいいから書くとか... お話ししないこと
7. Topics なぜ個人ブログは作り直されるのか？ 個人ブログを何度も作り直してしまう理由を、ikuma-tの個人ブログ開発経験から考察します 。 作り直しを避けるために これまでの開発を踏まえ、同じような過ちを繰り返さないために、現在どのように開発をしているのかを紹介します 。 Topic 1 Topic 2
8. Q. （前提として）作り直しは悪いことなのか A. メリット・デメリットがあるものの、個人のブログなのだから好きにやればよいŸ p メリット’ p 新しい技術の習得機会が増える（特に0→1で使う知識・技術z p ブログを書くモチベーションが上がn p デメリット’ p 年に数日がブログ作業で束縛される（それはそれで楽しいけどz p 家族から「またブログ作り直してんの？ 」と言われ、なんとなく肩身が狭„ p リダイレクトを適切に設定しないと、参照してもらっていたリンクが切れn p GitHubに同じような名前のリポジトリが増えていく
9. なぜ個人ブログは作り直されるのか Topic 1
10. 個人ブログは簡単に作れる時代 FW・テンプレートを選ぶ フレームワークごとにテンプレートがあり、 コマンド1つで複製できる 自分用にちょっと編集 サイト名やら著者名やらを適当に編集 お好きなPaaSにデプロイ GitHubと数クリックで連携し、 自動プレビュー・デプロイを実現
11. my-blog ブログ 前から使ってみたかったXXXを使ってブログを作り直しました。 Markdownで記事を書けばすぐに反映されて、デプロイもコマンド一発で できて非常に開発体験も良かったです！ まだ細かいところまでは見られていませんが、思ったよりも簡単にできたの
 で、今後も機能追加しつつ、ゆるく記事を書いていこうと思います！ XXXでブログを作りました！ 作った当初は気に入っている！（とて も！） （ここにあなたの好きな フレームワークの名前が入る）
12. 2022-05-26 Next.js Pages Router 2023-08-07 Remix v2 2023-01-03 Astro v2 2024-03-10 Astro v4.2 2021-08-01 Gatsby.js わたしも何度も 気に入っている！
13. 2022-05-26 Next.js Pages Router 2023-08-07 Remix v2 2023-01-03 Astro v2 2024-03-10 Astro v4.2 2021-08-01 Gatsby.js わたしも何度も 気に入っている！ 10ヶ月 7ヶ月 7ヶ月 7ヶ月
14. 気に入っていたのも束の間 ブログは破壊 と再生 を繰り返す だいたい1年もたない
15. ブログはすぐできるし、エディタでそのまま記事も書けるし最高！
16. ブログはすぐできるし、エディタでそのまま記事も書けるし最高！ わたし as Developer
17. 散歩中にふと書きたくなった...けどスマホで更新できないなあ わたし as Writer
18. なんかデザイン気に入らなくなってきたなあ、RSSリーダーだと読みづらいなあ... わたし as User
19. ここの実装方法イマイチだなぁ... あ、突然ビルド壊れた... わたし as Developer
20. 時間が経ち、開発時とは異なる環境・立場での課題が顕在化する 時間をあけてデプロイされたブログを閲覧してみたら不満 コードブロックが読みづらい、ダークモードがない、そもそもデザインが気に入らない、RSSリーダーで読みづらい...etc アップグレード・ビルドエラーの壁を越えられない Gatsbyのプラグインがあげられない、Astroのビルドが突然壊れデプロイ不能に...etc 執筆体験に不満 CMSのエディタが使いづらい、突然モバイルで書きたくなる衝動を抑えられなくなる、登壇のリンク載せるのが面倒...etc 開発当初よりも知識が増えることで誤りが気になる 杜撰なマークアップ、大味なコンポーネント粒度
21. 「大変でも課題に向き合っていこ？」 継続メンテ
22. 「新しいフレームワーク使って楽になっちまえよ〜」 「大変でも課題に向き合っていこ？」 継続メンテ 作りかえ
23. 「新しいフレームワーク使って楽になっちまえよ〜」 継続メンテ 作りかえ 「個人ブログだし、たしかに作り直した方が早いな！」
24. 対応コスト > 作り直しのコストなので、作り直しになる ブログを作るのはフレームワークやテンプレのおかげで簡単 テンプレートを使えば数分でも完成する 明確なユーザーがいるわけでも、利益を出しているわけでもないので、最悪全部消えても問題ない お仕事だったらこうはいかないけど、個人ブログなので...
25. わたし as Developer フレームワーク、エコシステム サポート 開発初期の実装効率・満足度はフレームワークや周辺のエコシステムが支えてくれる時代 しかしフレームワークの上にどんな要素を載せるかを決めるのは自分
26. 作って終わり...ではなく、 実際にブログを使う立場とそのシーンを考えることが大事 作り直しを避けるために 普通のことだ！
27. 作り直しを避けるために Topic 2 Topic 2
28. 具体的にどこら辺に気をつけるといいか
29. わたし as User わたし as Developer わたし as Writer 自分が耐えられそうなコンテンツ管理方法を選ぶ キメラUIを作らないように、体験・情報を考察する 雑に作らず普通のソフトウェア開発をやる
30. 現在の技術スタック Astro フレームワーク Cloudflare Pages ホスティング・ドメイン Pages CMS CMS Tailwind CSS スタイリング Expressive Code シンタックスハイライト Pagefind サイト内全文検索 Biome Linter / Formatter Playwright E2E Test Vitest Unit Test GitHub Actions Workflow Lint / Test / Deploy renovate dependency management どの技術を使うかはそこまで重要ではなく、自分の手間を減らせるものであればよい
31. 補足：Astro について コンテンツベースのサイトを構築することに長けたJavaScriptフレームワーク ブログ、マーケティングサイト、Eコマースサイトなどなど コンテンツを管理するための組み込み機能が豊富（例：メタ情報管理、ページネーショ ン...etc） アイランドアーキテクチャでReactやVue、Sveleteといったフレームワークと組み合わせ可能 静的ビルドを基本として、SSR、ハイブリッドレンダリングも選択可能
32. 自分が耐えられそうなコンテンツ管理方法を選ぶ 更新はPCから？モバイルからも？ 記事のメタ情報のバリデーションは必要？画像の管理は？ わたし as Writer
33. コンテンツをどう管理するか 自分の場合は手軽さから多くのケースでMarkdownを使用  Markdown（Gitベース„  いつものドキュメントやコードを書く環境で執筆でき、体験が良い（例：textlint、Copilotž  サイト自体のソースと一体化するので、ソースや記事が増えるとやや扱いづらh  ヘッドレスCMS（SaaS / 自作„ e 管理画面によって記事に集中しやすいS e テキストファイルを扱うよりは編集が面倒（複数人向けサービスなので1人だとそう感じやすい） 自分が耐えられそうなコンテンツ管理方法を選ぶ
34. Markdownを選択した場合のつらみになりそうなポイント 自分が耐えられそうなコンテンツ管理方法を選ぶ 基本はただのテキストファイルなので、日付やカテゴリのメタ情報の制約がゆるい 中央管理をしていないと、サイト自体の実装で不便。またカテゴリや日付を都度形式に合わせて入力する必要があり面倒 画像を配置するのが地味に面倒 規定のパスにおく必要があるが、数ヶ月経つとパスの指定方法を忘れる モバイルでの執筆体験は別途考える必要がある GitHub Codespacesをブラウザで開くことはできるが、モバイルに最適化されていない
35. 独自ツールで執筆効率を高める 自分が耐えられそうなコンテンツ管理方法を選ぶ - 過去にとってきた方法と課題点 https://ikuma-t.com/blog/create-blog-command-4/ https://ikuma-t.com/blog/publish-srcpan/ （作りにもよるが）ブログを作った勢いでデスクトップ前提で作っているので、モバイルで無事敗北 ボツ案
36. 自分が耐えられそうなコンテンツ管理方法を選ぶ - 過去にとってきた方法と課題点 画像の挿入の煩わしさ（そもそもアップできない）や、メタ情報の形式を忘れて結局PCを開くことになり敗北 GitHubモバイルアプリをエディタとして使う ラベル付与 PRマージ テンプレで作成 ボツ案
37. メタデータの管理：Astro Content Collection を利用 自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案 採用中 zodスキーマでMarkdownのメタ情報を定義できる。型が異なるとビルドエラーとして検知 enumにない値を指定したので、開発画面でエラー
38. 編集用のエディタアプリを別に持つ 自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案 採用中 GitHubで管理しているMarkdownをベースに、Gitベースで動作するPages CMSを採用
39. エディタ外の執筆体験 - 編集用のエディタアプリを別に持つ 自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案 採用中 yamlファイルでエディタと一覧の表示項目を定義（ファイル直接でもGUIからでも編集可能）
40. 画像のアップロード - 編集用のエディタアプリを別に持つ 自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案 採用中 画像のアップロードはyamlで「Gitのパス：記事に埋め込むパス」を定義してGUIから実施可能
41. わたし as Developer 雑に作らず普通のソフトウェア開発をやる CIを整備する、変更を意識して設計・実装しておく
42. CI を構築する 雑に作らず、普通のソフトウェア開発をやる 一般的な Lint / Test / Build / Deploy をめんどくさがらずに最初に整備しておく 特に静的ビルドでビルドがぶっ壊れると終わりな割に、たまに壊れるのでCIでチェックしておく 通常の開発のCIと合わせてライブラリアップデートは自動化しておく プラグインがあげられなくなったが最後、そこには作り直しの未来が待っている （実情）アクセシビリティのチェックを組み込んではいるものの、全部対応できていない Astro の Devtoolsでも a11y や パフォーマンスのチェックができる
43. Astroでのテスト（.astro コンポーネント） 雑に作らず、普通のソフトウェア開発をやる - CIを構築する レンダリングの仕組み的にコンポーネントは基本E2E。もう少しでコンポーネント単位でテストで きるかも v4.9 で登場した Container API（experimental）の進化、StroybookのReact Server Component対応的なハックを期待 こんな感じのutilを作っておき、HTMLのスナップショットテストを実施可能 ただし script が含まれないので、ふるまいのテストはできない。
44. 【テスト対象】全文RSSの生成ロジック Content Collection で管理しているデータを取得し、 AstroContainerで全文レンダリングしている 【テスト】テスト用記事を使って値を検証 あらかじめdraft:trueな記事を本番ビルドから除外しておく ことで、実際の記事を用いてVitestでテストする 雑に作らず、普通のソフトウェア開発をやる - CIを構築する Astroでのテスト（Content Collectionに依存したユーティリティ） 本番ビルドから除外する記事を用いてテストする
45. モジュール・コンポーネントを適切に分割・凝集しておく 雑に作らず、普通のソフトウェア開発をやる - 変更を意識して設計・実装しておく 盛大なアーキテクチャはいらないが、雑に作れるからと言ってPageに全部書かない いつもどおりコンポーネント志向でちゃんと書く コンテンツ取得のロジックは一箇所にまとめておく 数箇所でもブログ記事取得を各所で書くと、後々の編集が面倒になる（キャッシュ効かせたい時や、リファクタしたいとき）
46. テーマ設定は最初にやっておく（例：ダークモード） dark 修飾子で各所で設定する コンポーネント集やテンプレートを利用するとよくある。 統一感が出にくく、修正が面倒。 CSS Variablesで一括で設定する 見た目に対する期待値は絶対に変わるので、一括で設定して おいたほうが作り直しのコストは下がる。 雑に作らず、普通のソフトウェア開発をやる - 変更を意識して設計・実装しておく
47. キメラUIを作らないように、体験・情報を考察する わたし as User
48. キメラUIを作らないように、体験・情報を考察する キメラUI = 世の中にある良さそうな感じのサイトから、気に入った部分を寄せ集めてできたUI ライオンの頭、蛇の尾、ヤギの胴をもち、口から火を吹く 完成されたUIを使うのはユーザーにとってもプラス なじみのあるUIは操作しやすい 一方で自分が提供したい情報に対して、参考にしたUIがあっているかは考えたい 著名な人のレイアウトを真似てみたものの、自分にはいい感じのポートフォリオもないし、仕事の依頼とかも欲していない
49. どんな情報を提供したいか / できれば良いか考えてみる キメラUIを作らないように、体験・情報を考察する 「どういうことを書きたくて、それをどんな人が読むか」を基準に必要なコンテンツを決める
50. 提供したい情報と照らしながら、既存のUIの情報構造を参考にする キメラUIを作らないように、体験・情報を考察する タイトル これはさすがに必要かな サマリ 入稿するとき面倒くさくなって適当になりそう。だとすると不要？ OGP（画像・絵文字・縮小版の記事） 画像はめんどう。でも一覧でみた時にイメージ記憶呼び出しやすい。 公開日（絶対・相対、日付・時間） 技術記事だと絶対日付の方が個人的には嬉しい。 著者 自分しかいないのであまり情報は増えないかも。 タグ・カテゴリ 絞るには便利だけど、こちらの分類が読者に役立つか 文字数・想定読了時間 飛ばし読みとか全然ある。それよりも見えるコンテンツが多い方がいい？ 例：ブログ記事
51. 現在のブログはこんな感じです。 キメラUIを作らないように、体験・情報を考察する UIはどうしてもどこかでみた感じにはなってしまうけど、 表示する情報は絞れているので、運用しやすい（はず）
52. 個人ブログのスクラップ&ビルドにどう立ち向かうか Topic 2 まとめ
53. わたし as Developer フレームワーク、エコシステム サポート 開発初期の実装効率・満足度はフレームワークや周辺のエコシステムが支えてくれる時代 しかしフレームワークの上にどんな要素を載せるかを決めるのは自分
54. 作って終わり...ではなく、 実際にブログを使う立場とそのシーンを考えることが大事 作り直しを避けるために 普通のことだ！
55. わたし as User わたし as Developer わたし as Writer 自分が耐えられそうなコンテンツ管理方法を選ぶ キメラUIを作らないように、体験・情報を考察する 雑に作らず普通のソフトウェア開発をやる
56. わたし as User わたし as Developer わたし as Writer 自分が耐えられそうなコンテンツ管理方法を選ぶ キメラUIを作らないように、体験・情報を考察する 雑に作らず普通のソフトウェア開発をやる どうやってコンテンツを管理するか、どこから編集する予定か CIを整備する、変更を意識して設計・実装しておく 自分がどんな情報を提供したいかをベースにUIを考えていく
57. ありがとうございました 現在の ikuma-t.com が1年以内に作り直しされないか、見守っていてください