日記/2019/01/02/ブログとYakiBikiの今後について

このブログのために自作したYakiBikiだが、PHP4の最後の時代に作ったこともありいい加減古い。
PHP5にキャッチアップできてないのと、それゆえに、PHP7では多分動かない。

それ以外にも機能/設計面で厳しいところも多い。例えば・・・

• 記事の更新時にACLキャッシュを再生成するため重い。
  • これが割とクリティカルで、気軽に記事を作れない・・・。
• 常にACLを参照するのと、生成したHTMLのキャッシュ更新が走るため、記事を表示するだけでもレスポンスが重いときが多い。
• プレビュー画面が無いのがいい加減しんどい。
• 記事表示画面でも編集系アイコン・リンクを出力してるが、Google Botなどがこれらを辿った結果、ときどきGoogle Analyticsで大量の403アラートが出る。
• Markdown対応してない。

もともとYakiBikiを作るときの目標として、小～中規模IT企業における社内Wikiという活用方法を想定していた。
そのためACLに注力し、その結果としてACLのキャッシュという形を仕込んだわけだが、これがnon-DB(独自ファイルストア)と相まり、1,000件を超えたあたりから記事の更新が数秒かかるようになってしまった。
それでもプレビューがあればまだマシだったが、プレビュー機能は手抜きで作らなかったし・・・。
そうなると、個人利用でSEOも気にしたパフォーマンスそこそこ出す必要のあるブログとしては、もはや時代遅れも大概な遺物となってしまっている。

社内Wikiというか社内ナレッジサイトなら、今なら esa.io もあるし、GSuite や Office365 などでクラウドストレージ兼ドキュメントシステムもある。
タスク/プロジェクト管理やナレッジ共有 Backlog もあるしオンプレなら老舗のredmineでも戦える。メンバー構成によってはGitHub系も選択肢に上げられる。

自分自身も、働く会社が、受託系で細かくACLを気にする必要のあるSE/PG中心SIerではなく、ある程度の期間自社メンバーと一緒に働く場所に身をおいていることもあり、ACLの必要性が薄れてしまった。
そうなると、ACLを重視したYakiBikiはもうオーバースペックというか要望的にアンマッチであり、会社で使うことも将来的にまず考えられない。

で・・・じゃぁ、どうすんねん？だが、方向性としては以下のいずれかが考えられる。

1. PHP7へのマイグレーション & ACL機能削除による軽量化 & プレビューと下書き機能追加
2. 別のOSSブログシステムへの移行 (WPとかその他OSSのシステム)
3. GitHub Pages への移行(= Jekyll ベースの静的サイトジェネレータ)
4. Qiitaやはてなブログや WordPress.com など外部ブログASPへの移行

ここでどうしても死守すべき要件は次の一点。

1. 今のサイトのURLは死守する。(はてなブックマークや、現行URL資産で参照している外部サイトの価値を保全したい)

全く新しいサイトを新規作成して、そこで新しい記事を書いていく・・・のは、それはそれで問題ない。
が、「今のサイトのURLを死守」というのは別のOSSブログシステムやGitHub Pages(Jekyll)や、ましてやはてなブログ/WP.comでは実現できない。
(多分静的サイトジェネレータの一部では .htaccess 調整でリダイレクト対応とかできるかもしれないが、現行URLは1,000を超えており、.htaccessでそれだけのエントリのrewriteを管理するのは不可能)

つまり、「今のサイトのURLを死守」＝「今のサイトを引き続き独自アプリでメンテしてく必要がある」ことを意味する。

まぁ実際問題、"/"区切りの記事の階層化とか、プラグイン記法によるナビゲーションや階層化記事の一覧機能など、機能としてはそこそこ便利だし引き続き使いたい機能はある。
これを完全に捨て去るのは、個人的にも惜しい。

外部ブログASPについては・・・

• プログラミングの記事であればQiitaで申し分無いが、ちょっとしたメモや、プログラミング/IT系以外の記事については書けない。よって、どうしてもQiita以外も併用する必要が出てくる。
• はてなブログは、無料版はキーワードリンクが厄介。CSSとかで事実上無効化はできるが・・・。広告も消すには有料版が必要。ただ、有料版といえども、そもそもサイトの表示が（個人的な主観だが）微妙に重いときもあり、個人的に使うときに「個人的に好み」かと言われるとイマイチなところがある。
• WordPress.com : 論外。
• どちらにしても死守要件は適用できない。
  • 一応はてなブログではWP/MTの記事をインポートできるようにはなっているが、そもそも現行記事データは現行Wikiフォーマットの固まりでインポートしようが無いし、WP/MT形式のエキスポート機能自体が無いので作らないといけないしで超面倒臭そう。

つまり死守要件は適用できないので現行サイトには使えないし、新しい記事についてだけ外部ASPを使おうとしてもそもそも個人的に気に入ったASPが無い。

GitHub Page など静的サイトジェネレータへはどうか？これも .htaccess のrewrite問題 + 過去記事互換性問題が立ちはだかるのと、新しい記事についてだけ～というパターンでも、やっぱり静的サイトジェネレータだと執筆環境がWebではなくて、サイトジェネレータ + アップロードという手間がかかるので個人的には厳しい。

結局のところ、現行サイトのURLと記事生成の仕組み(現行Wikiシステム)を維持する以上、何を選んでも「現行システムのPHPマイグレーション」は避けられない。
プラス、現行Wikiシステムは今後も使いたい。
となれば、YakiBikiの軽量化 & モダナイズが総合的には最も満足度の点からも、コストの点からも優れている。(結局マイグレーションしなければいけないなら、その見返りとして現行Wikiシステムのメリットを享受し続けたい)
ただし、引き換えに、また5～10年後に同様にマイグレーションの必要が生じる。
が、まぁ、それはそれで、いいかな・・・と。なかなか難しいところはあるけれど、現行資産の保全が割と優先度高いので。

現行 "/view/(数値)" URLを Permanent Redirect で "/view/(数値).html" にしておいて、もしものときの静的HTMLアーカイブ対応に備えておく、というのも考えたが・・・
まぁ、しておくことはしておくが・・・
次回または次次回のマイグレーション時の検討課題として残しておく。

要するに、超長期的には静的HTMLアーカイブした上で GitHub Pagesなどにごっそり上げる方向で考えたい。
しかし、そのための中期～長期のURL移行期間が必要なのと、その数年～十年単位の間での技術革新によりまた選択肢が増えることもあり得る。
そのため短期的にはPHPマイグレーションを主目的にしつつ、超長期に向けた移行期間への備えとして軽量化＆モダナイズを実行し、いざというときの静的HTMLアーカイブに対応しやすいようにシンプルなサイト構成となるよう改造する。

軽量化&モダナイズ&機能強化のアイデア例：

• ACL機能削除, グループ機能削除
  • マルチユーザは残しておくが、単に「執筆者」以外の機能は持たず、記事の公開アクセス範囲には関連しない。記事はワールドワイドに公開するか、下書きか、どちらかで、下書きについても執筆者であれば全員が見れる。
  • このへんを削れると、性能面でだいぶ改善されるはず。
• 画像/ファイル/URLアップロードについて、検索や最新一覧での表示対象外にしたい。
  • 今は一覧に出てしまうので、気軽に画像やちょっとしたファイルをUPできない・・・。それか、完全にdiscloseして、そういうのは外部ストレージに回したい・・・。
• Markdown対応、現行Wiki記法の細かなバグ調整など
• 下書き・プレビュー機能
• カテゴリ管理や編集時の設定のモダナイズ
• 記事のpermanent url を "/view/(数値).html" に変更
  • これが超長期に向けた、中長期の移行を見据えた短期的に実施可能な布石。
• 検索機能を単純な一覧化 & タイトルやカテゴリ検索を、フロントエンド側のJSフィルタリング機能として実装しなおす。
  • フロントエンド側にカタログデータを出力して、ブラウザJS側でタイトル/カテゴリフィルタリングする形にしても実用上問題ない。SEOとしてそこまで追っかけてほしいわけじゃないし。
  • つまりサーバサイドレンダリングとしては単純なWiki一覧が出てくればよくて、まぁソート機能付きならベスト。で、検索というかフィルタリングとしてはブラウザのフロントJS + フロント用のフィルタリング結果を返すAPIで動的に行い、それは別にSEO考えなくていいのでOK。という形にする。
  • こうすることで、将来静的HTMLで凍結しやすくしておく。

→ここでの問題として、「現行、ワールドワイドには非公開の記事をどうするか？」問題が残っている。
これについては、現行のデータを洗い出した上で、非公開記事データは現状自分しか見れない状態なので、HTML or 記事そのままのテキスト状態で、Google Driveに入れておく、という程度で問題ないと思う。