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

by ikuma-t

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

ikuma-t G 株式会社エンペイで働くエンジニS G 普段は React や Go、Rails を書いています3 G 初北海道 from 千葉 G フロントエンドが好きです。田所育真 / いくま / いくまてぃー

Slide 3

Slide 3 text

麺場田所商店武石本店 https://misoya.net/store/takeishi_honten/ 千葉県の味噌の田所さん

Slide 4

Slide 4 text

ikuma-t（田所育真）千葉県の味噌の田所さん

Slide 5

Slide 5 text

個人ブログの度重なる作り直しをどう防ぐかこれまでの個人ブログ開発経験と、現在開発中のブログからの考察今回お話しすること

Slide 6

Slide 6 text

ブログを続けるための習慣術 Googleアナリティクスを楽しみにするとか、毎日1分でもいいから書くとか... お話ししないこと

Slide 7

Slide 7 text

Topics なぜ個人ブログは作り直されるのか？個人ブログを何度も作り直してしまう理由を、ikuma-tの個人ブログ開発経験から考察します。作り直しを避けるためにこれまでの開発を踏まえ、同じような過ちを繰り返さないために、現在どのように開発をしているのかを紹介します。 Topic 1 Topic 2

Slide 8

Slide 8 text

Q. （前提として）作り直しは悪いことなのか A. メリット・デメリットがあるものの、個人のブログなのだから好きにやればよい p メリット p 新しい技術の習得機会が増える（特に0→1で使う知識・技術z p ブログを書くモチベーションが上がn p デメリット p 年に数日がブログ作業で束縛される（それはそれで楽しいけどz p 家族から「またブログ作り直してんの？」と言われ、なんとなく肩身が狭 p リダイレクトを適切に設定しないと、参照してもらっていたリンクが切れn p GitHubに同じような名前のリポジトリが増えていく

Slide 9

Slide 9 text

なぜ個人ブログは作り直されるのか Topic 1

Slide 10

Slide 10 text

個人ブログは簡単に作れる時代 FW・テンプレートを選ぶフレームワークごとにテンプレートがあり、コマンド1つで複製できる自分用にちょっと編集サイト名やら著者名やらを適当に編集お好きなPaaSにデプロイ GitHubと数クリックで連携し、自動プレビュー・デプロイを実現

Slide 11

Slide 11 text

my-blog ブログ前から使ってみたかったXXXを使ってブログを作り直しました。 Markdownで記事を書けばすぐに反映されて、デプロイもコマンド一発でできて非常に開発体験も良かったです！まだ細かいところまでは見られていませんが、思ったよりも簡単にできたの  で、今後も機能追加しつつ、ゆるく記事を書いていこうと思います！ XXXでブログを作りました！作った当初は気に入っている！（とても！）（ここにあなたの好きなフレームワークの名前が入る）

Slide 12

Slide 12 text

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 わたしも何度も気に入っている！

Slide 13

Slide 13 text

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ヶ月

Slide 14

Slide 14 text

気に入っていたのも束の間ブログは破壊と再生を繰り返すだいたい1年もたない

Slide 15

Slide 15 text

ブログはすぐできるし、エディタでそのまま記事も書けるし最高！

Slide 16

Slide 16 text

ブログはすぐできるし、エディタでそのまま記事も書けるし最高！わたし as Developer

Slide 17

Slide 17 text

散歩中にふと書きたくなった...けどスマホで更新できないなあわたし as Writer

Slide 18

Slide 18 text

なんかデザイン気に入らなくなってきたなあ、RSSリーダーだと読みづらいなあ... わたし as User

Slide 19

Slide 19 text

ここの実装方法イマイチだなぁ... あ、突然ビルド壊れた... わたし as Developer

Slide 20

Slide 20 text

時間が経ち、開発時とは異なる環境・立場での課題が顕在化する時間をあけてデプロイされたブログを閲覧してみたら不満コードブロックが読みづらい、ダークモードがない、そもそもデザインが気に入らない、RSSリーダーで読みづらい...etc アップグレード・ビルドエラーの壁を越えられない Gatsbyのプラグインがあげられない、Astroのビルドが突然壊れデプロイ不能に...etc 執筆体験に不満 CMSのエディタが使いづらい、突然モバイルで書きたくなる衝動を抑えられなくなる、登壇のリンク載せるのが面倒...etc 開発当初よりも知識が増えることで誤りが気になる杜撰なマークアップ、大味なコンポーネント粒度

Slide 21

Slide 21 text

「大変でも課題に向き合っていこ？」継続メンテ

Slide 22

Slide 22 text

「新しいフレームワーク使って楽になっちまえよ〜」「大変でも課題に向き合っていこ？」継続メンテ作りかえ

Slide 23

Slide 23 text

「新しいフレームワーク使って楽になっちまえよ〜」継続メンテ作りかえ「個人ブログだし、たしかに作り直した方が早いな！」

Slide 24

Slide 24 text

対応コスト > 作り直しのコストなので、作り直しになるブログを作るのはフレームワークやテンプレのおかげで簡単テンプレートを使えば数分でも完成する明確なユーザーがいるわけでも、利益を出しているわけでもないので、最悪全部消えても問題ないお仕事だったらこうはいかないけど、個人ブログなので...

Slide 25

Slide 25 text

わたし as Developer フレームワーク、エコシステムサポート開発初期の実装効率・満足度はフレームワークや周辺のエコシステムが支えてくれる時代しかしフレームワークの上にどんな要素を載せるかを決めるのは自分

Slide 26

Slide 26 text

作って終わり...ではなく、実際にブログを使う立場とそのシーンを考えることが大事作り直しを避けるために普通のことだ！

Slide 27

Slide 27 text

作り直しを避けるために Topic 2 Topic 2

Slide 28

Slide 28 text

具体的にどこら辺に気をつけるといいか

Slide 29

Slide 29 text

わたし as User わたし as Developer わたし as Writer 自分が耐えられそうなコンテンツ管理方法を選ぶキメラUIを作らないように、体験・情報を考察する雑に作らず普通のソフトウェア開発をやる

Slide 30

Slide 30 text

現在の技術スタック 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 どの技術を使うかはそこまで重要ではなく、自分の手間を減らせるものであればよい

Slide 31

Slide 31 text

補足：Astro についてコンテンツベースのサイトを構築することに長けたJavaScriptフレームワークブログ、マーケティングサイト、Eコマースサイトなどなどコンテンツを管理するための組み込み機能が豊富（例：メタ情報管理、ページネーション...etc）アイランドアーキテクチャでReactやVue、Sveleteといったフレームワークと組み合わせ可能静的ビルドを基本として、SSR、ハイブリッドレンダリングも選択可能

Slide 32

Slide 32 text

自分が耐えられそうなコンテンツ管理方法を選ぶ更新はPCから？モバイルからも？記事のメタ情報のバリデーションは必要？画像の管理は？わたし as Writer

Slide 33

Slide 33 text

コンテンツをどう管理するか自分の場合は手軽さから多くのケースでMarkdownを使用 Markdown（Gitベースいつものドキュメントやコードを書く環境で執筆でき、体験が良い（例：textlint、Copilot サイト自体のソースと一体化するので、ソースや記事が増えるとやや扱いづらh ヘッドレスCMS（SaaS / 自作 e 管理画面によって記事に集中しやすいS e テキストファイルを扱うよりは編集が面倒（複数人向けサービスなので1人だとそう感じやすい）自分が耐えられそうなコンテンツ管理方法を選ぶ

Slide 34

Slide 34 text

Markdownを選択した場合のつらみになりそうなポイント自分が耐えられそうなコンテンツ管理方法を選ぶ基本はただのテキストファイルなので、日付やカテゴリのメタ情報の制約がゆるい中央管理をしていないと、サイト自体の実装で不便。またカテゴリや日付を都度形式に合わせて入力する必要があり面倒画像を配置するのが地味に面倒規定のパスにおく必要があるが、数ヶ月経つとパスの指定方法を忘れるモバイルでの執筆体験は別途考える必要がある GitHub Codespacesをブラウザで開くことはできるが、モバイルに最適化されていない

Slide 35

Slide 35 text

独自ツールで執筆効率を高める自分が耐えられそうなコンテンツ管理方法を選ぶ - 過去にとってきた方法と課題点 https://ikuma-t.com/blog/create-blog-command-4/ https://ikuma-t.com/blog/publish-srcpan/ （作りにもよるが）ブログを作った勢いでデスクトップ前提で作っているので、モバイルで無事敗北ボツ案

Slide 36

Slide 36 text

自分が耐えられそうなコンテンツ管理方法を選ぶ - 過去にとってきた方法と課題点画像の挿入の煩わしさ（そもそもアップできない）や、メタ情報の形式を忘れて結局PCを開くことになり敗北 GitHubモバイルアプリをエディタとして使うラベル付与 PRマージテンプレで作成ボツ案

Slide 37

Slide 37 text

メタデータの管理：Astro Content Collection を利用自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案採用中 zodスキーマでMarkdownのメタ情報を定義できる。型が異なるとビルドエラーとして検知 enumにない値を指定したので、開発画面でエラー

Slide 38

Slide 38 text

編集用のエディタアプリを別に持つ自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案採用中 GitHubで管理しているMarkdownをベースに、Gitベースで動作するPages CMSを採用

Slide 39

Slide 39 text

エディタ外の執筆体験 - 編集用のエディタアプリを別に持つ自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案採用中 yamlファイルでエディタと一覧の表示項目を定義（ファイル直接でもGUIからでも編集可能）

Slide 40

Slide 40 text

画像のアップロード - 編集用のエディタアプリを別に持つ自分が耐えられそうなコンテンツ管理方法を選ぶ - 現在の案採用中画像のアップロードはyamlで「Gitのパス：記事に埋め込むパス」を定義してGUIから実施可能

Slide 41

Slide 41 text

わたし as Developer 雑に作らず普通のソフトウェア開発をやる CIを整備する、変更を意識して設計・実装しておく

Slide 42

Slide 42 text

CI を構築する雑に作らず、普通のソフトウェア開発をやる一般的な Lint / Test / Build / Deploy をめんどくさがらずに最初に整備しておく特に静的ビルドでビルドがぶっ壊れると終わりな割に、たまに壊れるのでCIでチェックしておく通常の開発のCIと合わせてライブラリアップデートは自動化しておくプラグインがあげられなくなったが最後、そこには作り直しの未来が待っている（実情）アクセシビリティのチェックを組み込んではいるものの、全部対応できていない Astro の Devtoolsでも a11y やパフォーマンスのチェックができる

Slide 43

Slide 43 text

Astroでのテスト（.astro コンポーネント）雑に作らず、普通のソフトウェア開発をやる - CIを構築するレンダリングの仕組み的にコンポーネントは基本E2E。もう少しでコンポーネント単位でテストできるかも v4.9 で登場した Container API（experimental）の進化、StroybookのReact Server Component対応的なハックを期待こんな感じのutilを作っておき、HTMLのスナップショットテストを実施可能ただし script が含まれないので、ふるまいのテストはできない。

Slide 44

Slide 44 text

【テスト対象】全文RSSの生成ロジック Content Collection で管理しているデータを取得し、 AstroContainerで全文レンダリングしている【テスト】テスト用記事を使って値を検証あらかじめdraft:trueな記事を本番ビルドから除外しておくことで、実際の記事を用いてVitestでテストする雑に作らず、普通のソフトウェア開発をやる - CIを構築する Astroでのテスト（Content Collectionに依存したユーティリティ）本番ビルドから除外する記事を用いてテストする

Slide 45

Slide 45 text

モジュール・コンポーネントを適切に分割・凝集しておく雑に作らず、普通のソフトウェア開発をやる - 変更を意識して設計・実装しておく盛大なアーキテクチャはいらないが、雑に作れるからと言ってPageに全部書かないいつもどおりコンポーネント志向でちゃんと書くコンテンツ取得のロジックは一箇所にまとめておく数箇所でもブログ記事取得を各所で書くと、後々の編集が面倒になる（キャッシュ効かせたい時や、リファクタしたいとき）

Slide 46

Slide 46 text

テーマ設定は最初にやっておく（例：ダークモード） dark 修飾子で各所で設定するコンポーネント集やテンプレートを利用するとよくある。統一感が出にくく、修正が面倒。 CSS Variablesで一括で設定する見た目に対する期待値は絶対に変わるので、一括で設定しておいたほうが作り直しのコストは下がる。雑に作らず、普通のソフトウェア開発をやる - 変更を意識して設計・実装しておく

Slide 47

Slide 47 text

キメラUIを作らないように、体験・情報を考察するわたし as User

Slide 48

Slide 48 text

キメラUIを作らないように、体験・情報を考察するキメラUI = 世の中にある良さそうな感じのサイトから、気に入った部分を寄せ集めてできたUI ライオンの頭、蛇の尾、ヤギの胴をもち、口から火を吹く完成されたUIを使うのはユーザーにとってもプラスなじみのあるUIは操作しやすい一方で自分が提供したい情報に対して、参考にしたUIがあっているかは考えたい著名な人のレイアウトを真似てみたものの、自分にはいい感じのポートフォリオもないし、仕事の依頼とかも欲していない

Slide 49

Slide 49 text

どんな情報を提供したいか / できれば良いか考えてみるキメラUIを作らないように、体験・情報を考察する「どういうことを書きたくて、それをどんな人が読むか」を基準に必要なコンテンツを決める

Slide 50

Slide 50 text

提供したい情報と照らしながら、既存のUIの情報構造を参考にするキメラUIを作らないように、体験・情報を考察するタイトルこれはさすがに必要かなサマリ入稿するとき面倒くさくなって適当になりそう。だとすると不要？ OGP（画像・絵文字・縮小版の記事）画像はめんどう。でも一覧でみた時にイメージ記憶呼び出しやすい。公開日（絶対・相対、日付・時間）技術記事だと絶対日付の方が個人的には嬉しい。著者自分しかいないのであまり情報は増えないかも。タグ・カテゴリ絞るには便利だけど、こちらの分類が読者に役立つか文字数・想定読了時間飛ばし読みとか全然ある。それよりも見えるコンテンツが多い方がいい？例：ブログ記事

Slide 51

Slide 51 text

現在のブログはこんな感じです。キメラUIを作らないように、体験・情報を考察する UIはどうしてもどこかでみた感じにはなってしまうけど、表示する情報は絞れているので、運用しやすい（はず）

Slide 52

Slide 52 text

個人ブログのスクラップ&ビルドにどう立ち向かうか Topic 2 まとめ

Slide 53

Slide 53 text

Slide 54

Slide 54 text

作って終わり...ではなく、実際にブログを使う立場とそのシーンを考えることが大事作り直しを避けるために普通のことだ！

Slide 55

Slide 55 text

Slide 56

Slide 56 text

わたし as User わたし as Developer わたし as Writer 自分が耐えられそうなコンテンツ管理方法を選ぶキメラUIを作らないように、体験・情報を考察する雑に作らず普通のソフトウェア開発をやるどうやってコンテンツを管理するか、どこから編集する予定か CIを整備する、変更を意識して設計・実装しておく自分がどんな情報を提供したいかをベースにUIを考えていく

Slide 57

Slide 57 text

ありがとうございました現在の ikuma-t.com が1年以内に作り直しされないか、見守っていてください