2020-20 / ブログ再構築
随分と久々に書きます。久々に新しい記事を書くのでまずはこのブログのことから。
ブログについて
過去ログを見ると、ブログを書き始めてからもう10年ほどになるのだが、引越し魔よろしく様々なプラットフォームに乗り換えてきた。
- エムペ!(高校時代の
黒歴史私的なもので削除済) - FC2ブログ
- はてなダイアリー
- Wordpress
- Note
- はてなブログ
- Notion
- はてなブログ(出戻り)
これまで媒体を変えてきたのは様々な原因があったが、今回ほとんどの問題を解決するに至ったので、改めてブログを再開しようと思う。
概要: 使ったもの
めちゃ長くなったので使った技術だけ先に書いておく。以下気になったところを適当に読んでもらえれば。
- 記事管理: GitHub
- 画像管理: Git LFS
- サイト生成: GatsbyJS
- サイトホスティング: Netlify (デプロイプレビュー)
- 記事執筆: Gitpod
- テンプレート作成: GitHub Actions
- 依存管理/更新: Dependabot
課題1: 情報としての粒度がバラバラ
ブログはその名の通り「ログ」なので、フローに当たる情報になる。元々ブログ自体、私の思想やその時どう考えたか？を書きたかったので、これ自体は問題ない。 ただ、ある程度一定期間流れない情報、つまりストックとなる情報を選別し、特に長期間変わらないであろう”原則”のようなものや、そういった質の良い情報を置く場所が欲しかった。
それを考えると、現行のブログ1本体制はやや厳しいものがあると感じ、フローとストックをそれぞれ貯められるサイトを作りたいと感じるようになった。
どうしたか？
当初は、フローとストックのページ階層を分けて分別するだけにしようと考えていたが、うまくハマる方法がなかったのでサイト構成を分けることにした。 これを2サイト構成に整理することを考えて、既存のブログサイトに加え、wikiサイトを別に作ることにした。 今回はGWで時間もあったので、それぞれのサイトロゴも手作りした。イメージをなるべく揃えるためにデザインはかなり近いものにした。 ダークモードなどにも対応できるよう、かなりシンプルなロゴになっている。
また、ロゴのアイコン部分はFont Awesomeをそのまま使っている。CC BY 4.0で使えてSVGで配布されていて汎用性が高く、個人サイト用としては十分と感じたので採用。
課題2: 書きにくい、汎用性がない
各ブログサービスのエディタはそれぞれ個性があるが、前使っていたはてなブログが一番厳しかったのは、長文の対応があまりよくなかった点だった。Markdownで長文を書くと、どうしてもプレビューが遅くなり、場合によってはプレビューが常時失敗するような挙動をされることがあった。私の場合、ブログでそこそこ長い文を書くのでこれが致命的で、一度公開をしないと長文がストレスなく書ける状態にはならなかった。
どうしたか?
まずははてなブログを止めることを前提に考えた。他のブログサービスがそんなに書きやすいか？となったので、次の課題の中でまとめて手法を整理することにした。
課題3: 保管方法
各社によって提供されているブログサービスは機能がまちまちだが、そのどれもが「サービス終了」という壁がある。例えば「Yahoo!ブログ」は前年サービス終了となったが、この際に移行ツールが提供され、一定期間後にデータを廃棄することが明記されている。
折に触れてよく話すことではあるが、私は自分が必要以上に長く生きることについて否定的な思想である。そのため、いくら医療が進歩しようが不老不死になるなんてごめんだし、それは次に生まれてくる生命の居場所を奪うことにもなる。とはいえ、自分という存在がいたことはどうにかして形に残したい。つまり自分という存在がいたことは、数十メガバイトの文書ファイルになって残っていれば、私はそれだけで、それだけで良いのだ。
人は、いつ死ぬと思う・・・？ ・・・人に、忘れられた時さ・・・！！！
- 出典：ONE PIECE／尾田栄一郎 集英社
とはいえどこかのサービスを使い続ける限り、自分がもし交通事故でなくなったら、自分の生きた痕跡は数十年後にこの地球上から抹消されるだろう。現在の日本の役所では、戸籍の保管期限は150年とされており、それ以降になってしまうと日本の戸籍上から名前が抹消されてしまう。絶対に、というのは難しいが、少なくとも数千年程度はこの地球に爪痕を残しておきたいと思うようになった。
どうするか?
現時点で、一般人が使える一番信頼できるアーカイブ方法を利用すべく、GitHub Archive Program を利用して管理することを考えた。これは、米マイクロソフト傘下であるGitHub社が提供しているもので、ソースコードを複数の媒体を使って超長期間保管してくれるもので、最長の期限であるProject Silicaに至っては、10,000年間保管ができるようになっている。
もちろん、1万年間保管できる保証などどこにもないし、戦争が起き、過去の遺産を理解しない為政者によって、我々のコードも何もかもが破壊されることはあるかもしれないし、保管媒体が性能を発揮できず、せいぜい数百年で壊れてしまうかもしれない。1万年前と言えば私たちからすれば新石器時代であり、そんな時代の文章など今の私たちの役には立たないだろうとも思う。
ただ、もし1万年後。未来の誰かやロボットが私の書いた文章を見つけ「こんな人がいたのか」と思いを馳せるかもしれない、これ以上の”浪漫”がどこにあるだろう！ 私はこの浪漫にこそ自分のソースコードと文章を預けたいと考える。
課題その4: 執筆方法・コンテンツ管理(CMS)
GitHubを利用するということは、Gitリポジトリとしてブログ記事を管理するということになるが、iPadなどでの記事執筆が非常に難しいという問題があった。Macでは普段の仕事で使っているGit環境をそのまま使えるが、iOSで使えるGitクライアントはかなり少なく、 WorkingCopy くらいしか選択肢がない。
また、ブログでは画像などのでかいファイルが大量に発生するため、今後画像の質が向上し、全てをGitリポジトリにコミットすると1リポジトリ100GBのサイズ上限に引っかかってしまう。
加えて、エディタで書くのも微妙に感じることはあり、GitHubをソース源にしながらAPI的にやりとりする、いわゆるヘッドレスCMSを検討できないかと考えていた。特に Contentful, NetlifyCMS などを利用すれば、より書きやすいエディタ環境を手に入れられるかも？とも思い一通り試した。
だが結果的に、これは全て難しいものだった。WorkingCopyは高性能だが、エディタという意味では起動するまでが面倒だし、Contentfulは一定以上の記事数になると毎月の維持費用が高い。Netlify CMSはiPadのSafari上で日本語入力ができない致命的な問題があった。
どうしたか?
Git LFSを使った管理を実施するようにした。現時点ではLFSのサイズ上限は1GBで対して使い物にならないのだが、少なくとも数年経てば容量も上がるだろうし、仮に有料のサイズ帯になって自分が死去した場合でも、内容を消去することはないとのことなので、ここも丸ごとソースコードとして保管できるソリューションになる。
また執筆方法としては、VSCodeライクなエディタをブラウザ上で起動できる Gitpod を利用することにした。ブラウザで起動するので、iPadだろうがどこでも執筆ができるし、GitpodのエディタはKubernetes上で立ち上がっていることから、Dockerイメージとして整備することができ、git lfsやyarnなどのシェルコマンドも走らせることができる。
将来的には、先日発表された GitHub Codespaces なども乗り換え先として良いかもしれないが、現時点ではまだ使えないのでひとまず Gitpodで執筆することにする。
課題その5: フレームワークについて
ソースコードで保管するからと言って、流石にHTMLを直書きするわけにも行かない。エンジニアというのもあるし、できればMarkdownで書いたものを”static site generator”的な何かに食わせて出力したHTMLとassetsをデプロイするような構成にしたい。
当初は少し仕事で使っていた mkdocs などを見ていたが、ドキュメントに特化した部分を考えるとできれば他のものを選定した方が良いかと考えた。
これは当初、自分がGoの知見があることから Hugo を利用しようと思っていたのだが、後から GatsbyJS が気になってしまい、この2つを最後まで悩むことになった。
どうしたか?
結果としては GatsbyJS を採用した。
決め手になったのが「プラグイン」に当たる部分のエコシステムの差だ。Hugoは元々「テーマ」というサイト全体を覆うエコシステムが大きく発達しており、その面では GatsbyJS に大きく優っているのだが、「Template」や「Hugo module」といった細かい追加モジュールのエコシステムが未熟で、ユーザによって作られたスニペットがブログで細々と紹介されており、それを手作業で追加して対応すると言ったものが多い。長い目で見るとこのロードマップが欲しいが、そもそもhugo modulesやthemeはパッケージング方法が一貫しておらず、git submoduleやgo modulesで別々に依存関係を整備することになり、根本的な構造のせいでかなり難しい課題を孕んでいる。
これに対して GatsbyJS は真逆の進化をしており、先に plugin のエコシステムが十分に成熟した後にテーマについての枠組みが成立した。そのため、テーマ自体はまだまだどれも使い勝手が悪いのだが、pluginとしてのエコシステムが十分に出来上がっていた上にテーマの概念をそのまま継承したことで、依存関係の枠組みが非常に洗練されている。ページ表示速度も申し分ない。加えてフロントエンドJS(React)を最初から根本に据えているので、NPMで全ての依存関係を一元管理できる。Nodeで依存関係が管理できるので、 Dependabotでテーマを自動更新することもできるようになるわけだ。
この差は言語的な問題も大きく関わっているので早々ひっくり返らないだろうなというのと、自分自身、Reactを使ったコンポーネントを触ることがほとんどない部署にいるので、FE技術の勉強の意味でも、これを選定しておくのはスキルアップに良いだろうと考えた。
ただ、選定した後に苦労したのがビルド時間だ。hugoはやはり軽量でビルドに時間がかからないのですぐにプレビューできるが、GatsbyJSはそこそこかかる。そのため、基本Markdownで書いてからプレビューをどうするかという課題が残った。
課題その6: どこにホスティングするか？
これまでは各サービスにホスティングを任せていたが、作られるものは単なるHTMLなので、適当なhttpdサーバが立っているところであればなんでも良い。とはいえ、なるべく管理を楽にしたいということで、Netlify と GitHub Pages を対象として検討した。元々Netlifyはここ以外でもたくさん使っており慣れていたが、GH Pages でカバーできるならそれでも十分かなと思えていたので、改めて検討することにした。
どうしたか？
Netlify を採用した。決め手になったのはデプロイプレビューで、PullRequestを送った時に、デプロイした結果がどうなるのかを本ちゃんのサイトと別にデプロイしてプレビューできるようになる機能。先ほどのGatsbyの問題もあり、ここでそれが解決できるのは僥倖！ということで採用した。
ちなみに、DNSのカスタムドメインや、Let’s Encryptを使ったSSL証明書の自動付与(https化)などでは、ほぼ両者に違いはなくなったので、デプロイプレビューさえあればPagesでも普通によかったかもしれない。(Netlify的にはたくさん違いあるよ！とアピールしてたので一応提灯記事を貼っておく。確かにリダイレクトやコンテンツ最適化はよかったと思う)
課題その7: どうやってgit commitするか？
せっかくPR時のプレビューがあるのだから、できればPullRequestで記事を書いていくようなフローを構成したい。ただ、毎回Gitpodを開いてからブランチを切り、ディレクトリを作るという作業を挟むのは面倒臭い。できればここをあらかじめ作っておく、つまり自動化したいと考えた。
どうしたか?
GitHub Actionsを使って、毎週月曜日に自動的に記事のテンプレートが作られるようにした。 こんな感じで毎週月曜日に次の日曜日に書く記事のブランチとテンプレ、PullRequestを自動作成するようにした。
Gitpodでは、PullRequestやブランチごとにワークスペースを分離するため、ブランチ名を起動時のURLに組み込めばそのままブランチを指定してエディタを起動できる。
これを活用して、AlfredやShortcut（iOS）で今週の週番号を計算し、すぐに対象のブランチのGitpod URLが開けるようにした。
課題その8: ドメインについて
最後に残った課題がドメインだ。元々自分のサイトをよく見る人は気づいているかもしれないが、数年前から自分のホスティングしているサイトは、全て lkj.io というドメインを使って構成されている。人生で何度もタイプすることになるドメインが使いづらいものでは…という思いからこのようにしたが、 io ドメインはイギリス領インド洋地域を表すもので、ccTLDはSEO的に不利だし、変えた方が良いのでは？と.info系のドメインを漁っていたりした。
どうしたか?
結果的には見ての通り、 lkj.io のままとした。Googleでも確認したのだが、ioドメインは他のグローバル企業でも使われる事例が多いため、ccTLDだが実質的に gTLDとして扱われるらしいので問題ないみたい。
ただ、ioドメインが維持費用が結構高いのがネック…(年間7,000円)。とはいえ、1年でそれだけタイプ数を減らせるなら悪くない投資だとは思うし、閲覧者にとってのメリットにもなるので、高いがそのまま使い続けることにした。
その他地味に困ったこと
- はてなブログ flavored な markdown 構文(100記事分)をMDXに書き換えるのにだいぶ苦労した。これだけで丸々3日くらいかかっている。なかにはFC2ブログ時代の構文が残っていたりして地獄だった…。結局地道にsedで差し替えるなどした。
- 記事に使っていたイメージも全てダウンロードし、適切なディレクトリにコピーして、
git lfs管理にするところまでもなかなか長かった。 - ダークモード対応。ロゴをダークモード対応で白黒反転させるためにSVGと仲良くなった。SVGRは神。
- Notion時代に困っていたのがslug（ページURL)が無作為に振られてしまう件だが、これはテーマ任せなので動くか不安だった。今使っているNovela では結構自由が効くのだが、反面バグが多いテーマなのでどの程度ついていけるか次第。
あえてやらなかったこと
- 共有ボタン。自分の記事を届けたい層は恐らく使わないのではないか？と考えて廃止した。はてなスターは欲しいかも 。
- コメント欄。Facebook/Twitterで十分観測できるからいらないなーと感じたのでなし。
- 過去記事検索。恐らくGoogleのドメイン指定で十分賄えると判断した。
残った課題
これでかなり自分の理想に近い環境にはなったが、まだいくらか微妙なところがあるので今後修正しようと思う。とりあえずこれでだいぶ書きやすい環境が整ったので、今後はまた毎週のペースに戻していきたい。
- GoogleAnalyticsがまだ入ってないので導入したいが、GDPR周りのルールをまだキャッチアップできてない。プライバシーポリシーをどこかに静的ページでおく必要がある理解。
- 意外とGitpodでMarkdownの長文を書くと動きがカクつく。Codespacesはよ…。
- Qiitaを辞めたいので、どこかで記事をインポートして統合させたい。
- はてなブログにリダイレクトを設置して誘導する。
- 肝心のwikiサイトはまだ未着手なのでまた構造を作る。
bookmark
-
大体いい感じになるKeynote・Googleスライド用無料テンプレート『Azusa 3』作った - SANOGRAPHIX BLOG
-
Infrastructure as Codeのこれまでとこれから/Infra Study Meetup #1 - Speaker Deck
activity
最近はおいしいお店のテイクアウトが多くて助かってます。