本サイトの経緯, 設計 (WebsiteWithPython #1)

icon

本ホームページの構成を紹介する. 一気に書ききれなそう 且つ 適宜変更があると思うので, pythonで作る静的高速サイト というシリーズで書いていく予定.

テンプレートのcodesはGitHub: Website with Pythonで公開している.

#1は本サイトの経緯, 設計について記す.

経緯

ざっくり

WordPressの表示が重かったので静的サイトで構成することにした. 色々模索した結果, 自由度が高いPythonで処理に決めた.

 

詳細 (閲覧不要)

本サイトは3回目のversionである.

1回目: html, cssベタ書きの素朴なサイト

  • 2016/5/11にドメイン取得. 同時期公開.
  • 当初はやる気があったものの管理が面倒で長年放ったらかしに.

2回目: WordPress

  • 2017年から始めたQiitaの記事を移行し, 自分のホームページ兼ブログサイトとして公開

  • ある時期からGoogle AdsenseやAmazonアフィリエイト等も開始.

  • しかし, 設定がわからず (ちゃんと調べず), サイト全域に広告がでまくるように. 知り合いに自己紹介として自分のサイトを紹介した際にトップページですら広告だらけだったことに恥ずかしさを覚える. 後に, 広告の設定が色々あることがわかり, トップページなどの特定のページには広告がでないように設定した.

  • 表示速度の遅さにも辟易していた. ネットで調べて早くなると言われる設定やアドオンなどを試すもPageSpeed Insights で低スコアばかり. 自分でアクセスしても表示されるまでに数秒かかる始末でイライラしていた.

  • WordPress特有の記事形態にも嫌気がさしていた.

    • Qiita時代の癖から, 記事はmdで書くことが性にあっていると感じていた. しかし, 一旦, mdで記事を書き上げたとしても, 結局それをwordpress特有の段落等に当てはめて修正しなければならず, それが非常に億劫だった.
    • 記事に使用する画像が一箇所に集まるため, ちょこちょこ修正したい自分にとってはwordpressにアップしては消し...の連続が非常に面倒で非効率に感じ, 更新頻度が上がらなかった.
    • サイトを作りたいだけなのにheaderがどこにあるのかやテーマやらでWordPressの勉強をしなければいけなかったこと, それをしたところで完全に満足する結果にを得られなさそうであることがWordPressを毛嫌いしていた理由だった
  • 以上の経緯から, 本サイトの経営が滞りがちだったのだが, 自分のメモ書きをためておく場所が定住しなかったため, 再びサイト管理に関心をいだき始めた

移行先の模索期

Typora
  • 移行期間中に某授業資料の作成方法を模索する時期があり, それは結局Typoraを用いたMarkdown形式に落ち着いた.

  • 本質的にはMarkdownであれば何でもよかったのだが,

    • Typoraが一番直感的に書けたこと
    • テーマがcssで自由に自作できること
    • 数式が自由にライブ変換で自由に記述できること
    • 画像の挿入も直感とあっていたこと
    • 出力が安定しており, pdf, htmlなど幅広く出力可能であること
    • クロスプラットフォームで使用可能
    • 無料

    などの点で自分にあっていると感じ, Typoraを気に入って利用していた

  • したがって, Typoraで記事のメイン部分を書いて, あとはよしなに変換してくれるサイト設計が欲しくなった

Hugo等
  • 静的サイトでMarkdownからhtmlを自動生成してくれるツールとしてHugoを知り, 試してみた.

  • しかし, 数式の変換がAjaxだったかを利用しており, 表示がまったく安定せず, しかも表示速度が遅かった

  • その他, Hugoのサイト構造よりも自由に構成したいと感じたり, WordPressの際と同様で, サイトを自分好みに管理したいだけなのに, Hugoの使い方を覚えなければいけない点が億劫に感じ, 採用しなかった

  • その他, Vue.jsやBoostrap等も検討し, 多少試したりもしたが, それら自体への学習コストよりも,

    • まずはとにかくサイトを公開したいという欲が強いこと
    • サイト運営をしていない時点では, 自分自身が自身のサイトにどんなニーズを持っているかわからないため, 最も柔軟に対抗でき, 自分がほぼ完全に把握できているシステムのほうが望ましいこと

    などを考えた

3回目 (現行. Pyrhonを用いた管理)

以上のことから, 上記全ての便利ツールの採用をやめ, 汚くても俺々システムでも良いので, pythonで自分のシステムを自作する方針に決めた

サイト設計

基本方針, 目標

  • 表示が早いこと

    • サイトの最重要方針
    • 自身がユーザであると考えた際, 早く表示されることが一番大事だと考えた
    • 阿部寛さんのサイトの速度が1つの理想
    • 自分が利用したいと思えるサイトであることが1つの重要方針
  • 管理が楽

    • 楽であるほど新規コンテンツを作成する障壁が下がる
    • コンテンツ作成に集中できる
  • サイト構造

    • 固定ページ

      • トップページ, 業績ページなど, 更新頻度が低く, ある程度内容が固定されているページ.
      • 広告なし.
      • 凝った表示も可能
      • 実験的なサイトも対応可能なようにする
    • 投稿記事ページ

      • Tipsなどをquick and dirtyに公開できるページ
      • 同じフォーマット
      • Typoraで作成した記事がそのまま使用可能
      • 広告あり

    の2種類. WordPressのサイト設計に影響されている.

  • 静的サイト

    • PHP, Node.js, Vue.js等だと何らかの処理が入るため表示が遅くなりうる
    • html, cssのみで構成可能ならそれが最適
  • 移行可能

    • もしサイト移行となった場合に再利用しやすいよう構造的なファイル構成であることが求められる
  • クロスプラットフォーム

    • 基本的にはPythonベースに開発しているため, 他のOSでも更新可能
    • ただし, 現状はMacで構築しているため, .commandファイルなどのMac前提の処理も含んでいる.
  • ローカルファイル

    • サイトを構成しているファイル群は全てローカルにファイルとして所有できること
    • 移行可能性とも関連
    • バックアップ, 作業効率性も含む
  • 収益化

    • Google AdSense等の広告を自由な箇所に自由な設定で設置できること
    • 広告が可読性, 表示速度, サイトデザインを著しく落とさないように調整できる必要がある
    • 広告を入れる理由は, サイト運営費をサイト自身が稼ぐようになって欲しいため
    • 無料で全世界の情報が取得できることがWebの大きな利点と考えているため, Noteなどに見られる有料, クローズトな記事はなるべく採用せず, 広告でのサイト運営を目指したい.
    • 寄付はアリかもしれないが未定
  • gitでのversion管理

    • serverでは基本的にgit pullするだけで済むようにし, リモート作業が極力減らす

      • ローカルの方が記事を執筆, 推敲しやすいため
      • server先でVS code, vi, emacs等を用いて記事の修正等は避けたかった
      • markdownでの執筆にTyporaを使用したかった
      • Cyberduckやscpなどによるローカルファイルの手動コピーは面倒且つミスの元のため避けたかった
    • git checkout [hoge-branch] 程度はアリ

    • web制作の勉強も兼ねているため, gitによる変更履歴があった方が自分自身のモチベーションにもなる

  • 共通部分の1ファイル化

    • Header, Footer, Sidemenuなどの共通部分は1箇所にまとめる
    • 共通ファイルを編集すればその結果が全ページに反映されるようにする
    • 作業効率化, 人為ミス回避が目的
  • 記事の索引

    • Sidemenu等に記事索引が表示されることで記事の可読性が上がる
  • 記事一覧

    • 全記事が素早く表示される

      • 10記事ずつ表示され, 次へボタンをクリックして表示を切り替えていく形式の記事一覧ページは検索性に欠け, 閲覧が不便
      • ただし, 記事数が十分増えた場合は変更の可能性あり
    • ユーザが目的の記事を簡単に検索できることが目標

  • デザイン自由度, 柔軟性

    • デザインを自分好みに自由に調整できること
    • 追加機能が欲しい場合に対応できるような柔軟性があること
  • 記事内の画像等は記事ごとにまとまっている

    • WordPressのように画像が1箇所に集まっている場合, ファイル名が複雑になりがちで管理性が低い
    • 記事ごとに画像がまとまっていると記事ファイルが1つのディレクトリに閉じるため, ファイル管理性が高い

 

続く

次回はサイト構造について執筆する