なぜ必要なのか
公開サイトに一貫した記事を増やしたいのに、HTML全体を複製すると共通の修正が遅くなり漏れも出ます。多くの訪問者に同じ内容を返すためだけにサーバーを動かすと運用も増えます。ページを再現可能な手順で準備し、必要な操作を別に追加する方法が必要です。
どう解決するのか
- 記事三件と共通の型一つで始めます。本文と一緒に題名、要約、言語、安定した識別子を持ちます。そのデータから一覧と記事URLを作ります。共通ヘッダーを一度直すと全出力へ反映されるか確認します。数を増やす前に、反復作業を一か所で管理できるようにします。
- 公開の往復を試します。段落を直してビルドし、出力をプレビューします。深いURLへ直接入り再読み込みし、画像、言語リンク、不明なページを確認します。開発サーバーで読めるだけでは、実際のホスト上の経路は証明できません。最後に届ける成果物を検査します。
- 公開後の操作を分けます。メニューやローカルの絞り込みはブラウザーのJavaScriptで動かせます。個人の保存一覧には認証付き保存経路や適切なサーバー機能が必要です。生成済みの公開ファイルだけでは、読者ごとの非公開アカウント状態を保持できません。
- 同じサンプルで編集の費用を比較します。Astroは静的な内容に選択した操作部分を加え、Hugoは原稿とテンプレートから生成し、JekyllはMarkdownとレイアウトをRubyの作業系で処理します。編集者の技能、多言語要件、ビルド環境を確認し、ホストの対応経路や拡張機能は現在の条件を調べます。
- 鮮度と復旧も決めます。静的な出力の変更には通常、新しいビルドが必要です。原稿の履歴と正常だった出力、または戻せる公開経路を保ちます。ビルド失敗で稼働中のサイトを不完全なファイルへ置き換えず、公開を止めます。誰が確認し、再公開するかも決めます。
記載した手順で新しい記事を追加し、本番用出力の期待するURLで読めることを完了条件にします。JavaScriptを無効にしても主要な本文が読めるか確認します。内容中心の画面では、読めることと操作機能の成功は別の確認です。検索や保存などの追加機能も、それぞれの結果を確かめます。
Markdown↓ build
HTMLCSSJS
この選択を話し合う
コメントは全言語で共有。投稿にはGitHubログインが必要です。