Solist Work Blog

ソフトウェアエンジニア / IT navigator

なぜhugoでblogを書くのか

論文は100年後も読めることが望ましいと思います。 100年後マイクロソフトが無くなっていても論文がWordで読めなければ用をなさないでしょう。 あなたがWordを大事に保存していてもOSが変われば読めなくなります。 PC-98のソフトウェアでしか読めない論文を想像してみてください。 Wordで論文を書いてはいけない理由がここにあります。 論文ほどではないにしても書いた文章が誰かの役にたつのであれば100年後も読めることが望ましいでしょう。 100年後も文章が読めるフォーマットとはどんなものなのでしょうか。

テキストベースであることの価値

100年後も文章が読めるフォーマットはテキストベースのフォーマットである可能性が高いでしょう。 バイナリベースのフォーマットのWordなどは不確実性が高く2018年時点で2118年を予想することは難しいといえます。 ではテキストベースのフォーマットのなかで文章を残すプラットフォームとして何がよいか考えます。 まず、書いた文章は無料で読めることが望ましいでしょう。 シュリニヴァーサ・ラマヌジャンのようにインドの貧しい村に生まれて大学を卒業していなくとも数学者になれなければ、それは人類にとって損失でしかありません。 GitHubで優れたソフトウェアを書いている開発者の出身地と人種も偏りがなく、各地域の1%くらいのソフトウェアエンジニアが特筆すべきソフトウェアを書いています。 どんなに貧しい場所に生まれてもソフトウェアエンジニアになりたい人間がそれを実現できないならば、それは人類にとって損失でしかないのです。 そうさせないためには良質な文章が無料で読めなければいけないでしょう。 また、そのプラットフォームはおそらくオープンソースでなければ実現できないと思います。

広告モデルのBlogサービス

どこかの企業がやっているBlogサービスはその会社が倒産すれば終わってしまいます。 広告モデルは会社が継続すれば文章の作者がいなくなった世界でも文章が残る可能性がありますが、 倒産しない広告モデルの無料ブログサービスを2018年時点で判断するのは難しいでしょう。 Yahoo!ジオシティーズも2019年3月末で終了しますし、未来を予測することができたならノーベル賞どころの騒ぎではないと思います。 それに100年後の世界で広告モデルが継続しているかどうかもわかりません。 倒産しないまでも経営者が事業を売却してだめになることもしばしばあります。 ジェームズ・ゴスリンがEmacsを売り払ったのでリチャード・ストールマンはいちから現在のEmacsを作るはめになったなどこの手の話は枚挙に暇がありません。リチャード・ストールマンGNUプロジェクトを始めたのはこのことがきっかけでしょうが、そのような幸運な事件がおこることは確率的にいって稀だと思います。

インフラになる条件

文章を置いておく無料のサーバーなど存在しないではないかといえばそうでしょう1。ですから、簡単にサーバーやサービスを乗り換えることができなければいけません。 GoogleはKubernetesを自社に囲い込むことができる立場にいたにもかかわらず、KubernetesはGoogleCloudから簡単に他のプラットフォームに乗り換えられるように設計しました。 簡単の他のプラットフォームに乗り越えることができるのは長く使われるインフラストラクチャとなるものの条件です。

なぜWordPressがだめなのか

そして維持費用は限りなく安くなるアーキテクチャでなければ100年後に無料で文章が読める確率は低いでしょう。 この時点で条件を満たしそうなものはstatic site generatorに絞られてきます。 なぜWordPressがだめなのかといえばstatic site generatorより高くつくからです。 サーバーの負荷はstatic site generatorよりかなり高く、何よりphpで作られているためにWebにログイン画面を晒すことになるので、 セキュリティの保守なしでは文章は置いておけません。データベースも必要ですし、人件費がかかるものが100年生き残る確率は低いでしょう。 static site generatorでビルドされたhtmlだけサーバーに置いておくならほとんど負荷がなく、例えば大学のサーバーに置いておいてもさして問題にはならない程度の小さなものです。 清華大学にはたくさんのソースコードを保管するサーバーがありますし、アカデミックな世界はこの手の問題の担い手の一つになる可能性があります。 また、ビルドした後はhtmlになるのでセキュリティの保守も心配ありませんから人件費はほとんどかからないのも良い点です。 ホストに必要なApachenginxH2OなどのWebサーバーはオープンソースなのでなくなる心配はなさそうです。

Hugoの速さとGo

static site generatorであればどれもよい感じですが、さらに考えるとまだ優劣はあります。 快適にビルドできることもたくさん文章を書くなら必須です。 調べてみるとstatic site genratorの中でビルドが一番早いのはHugoでした。2 今後もHugoより速いものはそうそう現れないでしょう。 単一スレッドの性能ではC C++ Rustで作るのが最速になるでしょうが、GoでできているHugoマルチコアを使い切るアーキテクチャなのでこの方法が使えるGoで作られたstatic site generatorでなければ追い越すことはできないと思うからです。 たくさん文章を書くならHugo以外ありえないでしょう。

Hugoの安定さとGo

ビルドの安定さもHugoが一番でしょう。Goでできているという性質からHugoバイナリ一つあればビルドできる環境ができます。 これは他のプログラミング言語にはない性質です。 プログラミング言語が動作する環境を作らなくていいので最もハンディであると言えます。 そして、手元にMarkdownさえあれば引越が簡単にできるのが長く使われるインフラストラクチャの条件を満たしています。

Hugoの運用

とりあえず現時点で最も安いか都合のよい場所で文章を公開しておき、状況が変わったら引っ越せばよいのです。 以上の性質はMarkdownの原稿とHugoソースを公開するとコピーサイトを簡単に作られてしまうという副作用がありますが、 ある段階を超えるとそれは文章を100年後に残すには都合がよくなります。 例えば引退するなどしてコピーサイトが作られても問題ない状況になったらMarkdownの原稿とHugoソースをどこかに公開すればよいのです。 これからもディスク単価は下がっていくでしょうし、プログラムのソースコードは価値があると認識されているので無料でホストするサイトがなくなる可能性は低いと思います。 Markdownなどで書かれた文章もソースコードと同じく価値があると思うので、適切なタイミングで公開されるとよいのではないでしょうか。

Hugoの不満を解消する

以上のような考えからstatic site generatorのHugoを使うようになりましたが、まだ不満がありました。 普通のBlogみたいに画像を簡単に貼り付ける機能がほしいですし、 大学の教授なら学生に課題を用意してタイマーで0時に公開したいでしょう。 プレビューやサーバーに公開するコマンドをたたくのも面倒だし、複数のサイトを管理するのも面倒です。 httpサーバーとsshでつながっている場合はワンタッチで公開したいし、 現在よく使われる公開場所にキータッチ一つで公開したいですし、 好きな公開場所に公開するためシェルスクリプトを少し書くとどこにでも簡単に引越ができ、それをワンタッチで使えるようにしたい。 ワンタッチで原稿とソースコードをリポジトリにコミットしたり、記事を書き始めたりしたい。 難しいことを覚えなくても誰でも使えるようにヘルプを見ながら操作したい。 これらすべてが簡単にできるブログエディタのようなものが欲しい。 このような不満がたまってきたので自分でつくることにしました。3

Hugo用ブログエディタをEmacsで実装する

ブログエディタのようなものを作るにあたってEmacsで作ろうと考えた理由は、 Emacsが現在開発されているオープンソースプロジェクトのなかで最も長く生き残っているからです。4 30年以上も開発されていて現在も活発に開発されているのですから100年後も使える可能性が高いです。 EmacsLISP処理系であるEmacsLispで作られているのも100年後も使える可能性が高い理由です。 LISP処理系はプログラミング言語のなかでも最も作りやすいものです。 Emacsの15%くらいがC言語で実装されていて、C言語で実装された部分が少ないので移植が比較的簡単であるという性質があります。 LISPを設計したジョン・マッカーシーLISPは理論上の存在で実装可能であると考えていなかったくらいですから、極限まで抽象化されておりLISPの構文はこの30年ほとんど変わっていません。5 また、LISPにはmacroがあって好きなようにプログラミング言語を拡張できるのでLISPの基本構文を変える必要がないということもあります。6 こういった性質によってEmacsは100年後にも動くプラットフォームである可能性が高いでしょう。 また、SpacemacsEVILの存在があるため、Vimユーザーにも使えるプラットフォームです。それ以外のユーザーにはキーバインドをカスタマイズすれば対処できますし、ヘルプを見ながら原稿を書けるように作ったのでなんとかなると思います。

easy-hugoとEmacsは難しくない

easy-hugoの画面

このような要望を満たすeasy-hugoをつくったところ、狙いどおり大学の教授7などがeasy-hugoを使ってくれているようです。 論文を書いている教授なら文章が100年後に無料で読めることに気を使っているはずですし、アカデミックな世界で使われるようになると大学のサーバーで論文以外の良質な文章を長期間に渡ってホストしてもらえる可能性がでてきます。 こういうわけでソフトウェアエンジニアでない人でも簡単に使えるように作っておくのは大事であると思います。 Emacseasy-hugoも難しくないということをもっと宣伝していかなければいけないかもしれません。

easy-hugoを使わなくてもHugoは100年後にも無料で良質な文書が読める可能性を高めるプロジェクトだと思うのでもっとたくさんの人々にHugoで文章を書いてもらいたいと思います。 自分は良質な文章が書けないと謙遜されている方もいるかもしれませんが、たくさん書いて書き直していくうちに良い文章がかけるようになると思いますし、腕一本で勝負してきた職人がどのような工夫をしてきたかなどの文章は読みたいですし、残す価値があると思うのです。


  1. 正確にいうと現在無料で文章を置いておける場所はありますが、永久に無料でそのサービスが続く保証はないという意味です。現在Hugoで使用できるもので無料で文章を置いておけるのは | GitHub Pages(月間転送量100GBを超えると追い出される) | GitLab Pages(おそらくGitHubPagesと同じ条件) | Firebase hosting(月間転送量10GBまで無料) | netlify(月間転送量100GBまで無料) | などです。
  2. 実際にこのサイトはこの記事の公開時点で10万文字くらいの規模ですが、文字を修正した時にかかる時間はeasy-hugoでビルドしてUSのGoogleCloudに同期してブラウザが立ち上がるまで3秒くらいです。現在はnetlifyを使っています。
  3. これらの要望のなかにはGitHubのissueでもらったアイデアもあります。オープンソースはアイデアももらえるのですばらしいですね。
  4. 自分が使っていて好きなものであるという単純な理由もあります。ブラウザで文章を書くのは苦行でしかないので文章はテキストエディタで書くべきであるという理由もあります。ソフトウェアエンジニアがTwitterばかりやっているのはブラウザで長文の文章を書くことが苦行であることを端的に示していると思います。
  5. car cdr cons eq atom cond quote define nil t これだけでLISPのevalが実装できます。これらを基礎にしてあらゆるものがLISPで実装可能になるため他の言語のように構文を変える必要がないのです。
  6. EmacsLispはemacs24になる時にレキシカルスコープに変更されたのですがうまい方法で乗り越えました。この変更によりダイナミックスコープであることが原因でクロージャを使えなかった問題が解決したのです。
  7. Hugoは数式も扱えるのが理由かもしれません

タグ一覧

お仕事のご相談などはこちらからどうぞ

お仕事の依頼はこちらからどうぞ