ブログ移転準備中または Take the Hugo!

移転の理由

ここのブログは MTOS（Movable Type Open Source）を使っているのだが，既に皆さんご存知の通り， MTOS を含む MT5.2 系は2015年9月末で最終的なサポートが切れる。つまり来月以降，深刻なセキュリティ脆弱性が発見されたとしても MT5.2 系については改修は行われない。

とはいえ，これは前々から分かっていたこと。回避する方法としてはこんなところだろう。

Movable Type を 6.1 以降に上げる
他の CMS 製品に乗り換える
CMS をホストするサービスに乗り換える
ブログなんて時代遅れ。やめちゃえば

最後は割と魅力的だったのだが，私の場合，ものを書く習慣をつけとかないと本格的にダメ人間になってしまいそうな気がする。ブログをホストするサービスについても（Wordpress.com や Movable Type Cloud は論外だが），Tumblr, note, Medium，など渡り歩いてみたけど，どれも「帯に短し襷に長し」な感じでピッタリはまらない。そういうわけで，結局自分で作ることにしたわけだ（つまり2番めを選択）。

（というか，Twitter や Tumblr 以降のこの手のサービスは「共有する」ことに主眼が置かれていて，大昔のテキストサイトや Web 2.0 時代のブログのような「わたしんち」な感じがない。サービス・プロバイダにしてみれば，さしてお金を取れるわけでもないブログ・サービス（もどき）で情報をマネタイズするためにはコンテンツを持ち主から切り離していくしかない。そうすると自然に「共有型」のサービスにせざるを得なくなっていく。 Tumblr や Medium では特にこれが顕著で，多分いいことである。って考えると，つくづく Tumblr は分岐点だったんだなぁと思う。 Yahoo! に買収されてからはどんどんダメになってる気がするが）

で，最初は Jekyll/Octopress あたりにしようかと思ったが，今更 Ruby を入れるのが面倒くさかった（今の私の環境には Ruby は入っていない）のと「Jekyllが許されるのは小学生まで」らしいので， Hugo を試してみることにした。

と思ってたら，仕事が意外に忙しくて今まで放ったらかしにしてしまった（というか夏に Go 言語で遊びすぎただけなんだが）。

まぁでも，寝かせてた間に Hugo に関する優れた記事を書いた方がおられて，感謝感激が雨あられと降ってくる。

Hugoサイト構築 | Watanabe-DENKI Inc. 渡辺電気株式会社

というわけで早速サイトを立ち上げた。

text.Baldanders.info

サブタイトルは『帰ってきた「しっぽのさきっちょ」』。まだ色々と試している段階だが，10月初までには正式オープンする予定。

Hugo について

Hugo に関するブックマーク - text.Baldanders.info

Hugo については移転先でいろいろ書こうと思うけど，まずは簡単な感想を。

Hugo は「静的サイトジェネレータ」などと呼ばれている。これはサーバサイドで動的にコンテンツを駆動するのではなく，事前にコンパイルしたものをサーバサイドに送るからだと思われる。 EC サイトのような動的コンテンツには向かないが，ブログ程度のものなら十分である。先に紹介した渡辺電気株式会社のサイトは Hugo で組まれているそうだが，この規模のサイトなら楽勝である（デザインのセンスは別問題で，私のような人間には楽勝ではないが）。

この手のものは昔からあるが（例えば nDiary），最近の特徴は，入力フォーマットが Markdown 形式でほぼ統一されていること（ただし Markdown 形式はサービスごとに「方言」がある）と CI（Continuous Integration）ツールと組み合わせてコンパイルからデプロイまで自動化できる点だろう。

Hugo のもうひとつ特徴は（いや Hugo 以外でもそうかもだけど），サイトのエミュレーション環境を簡単に構築できることにある。 Hugo にはサーバモードがあって，コンパイル結果をブラウザ等で直接確認できる。しかも --watch オプションを付ければファイルの変更を検知して一瞬でリコンパイルしてくれる。この機能があれば，ひとりで作業する際でもローカルに簡単に環境を作れるし，複数人の場合は開発用サーバで Hugo をサーバモードで起動させれば，簡易 CI として機能する。

こういった芸当ができるのは Hugo が「爆速」と言われるほど処理が速いおかげである。はやいのは悪いことだけじゃいんだよ（←下品）。

これはおそらく Go 言語の特徴だと思うけど，複数の機能を任意に結合してひとつの実行モジュールを生成しているものが多いように思う。

Goのバッチで統計を取得するAPIを用意しておくと便利 - Qiita

Ruby や Javascript/node.js などのスクリプト言語ではこういったことは珍しくないが，コンパイル言語では珍しいと思う。

（これは昔の UNIX 哲学などと呼ばれているものからも少し外れている。昔は実行バイナリを作成するのは少しコストが高かったので，実行バイナリの機能を最小化する代わりにスクリプト言語（shell スクリプトなど）で機能を組み合わせていた。いわばコンパイル言語（による生成）とスクリプト言語（による実行）は相補的な関係だったのだが，今やこの関係は崩れつつあると言っていいだろう。スクリプト言語だけで大規模アプリケーションを組むことは珍しくなくなったし， Go 言語のようにコンパイル言語で複数の機能を任意に結合するやり方も出てきた）

（Linux などの UNIX 系の環境で本当にうんざりするのはツール間の依存関係が多すぎることだ。例えば Windows で Linux のツールをリコンパイルしたいだけなのに，大抵は gcc & make だけで完結することはなく，最近では Python まで要求するものもある。したがって MSYS2 のような「怪獣」を導入せざるを得なくなる。私が最近 Go 言語に傾倒しているのも，その辺に理由がある。多すぎる依存関係は，ユーザを縛りつける。

Hugo の Theme について

Hugo は Theme の少なさが欠点と言われてきたが，最近は充実してきている。

spf13/hugoThemes : スクリーンショットもあるよ

私もいくつか試してみたが，どうもぴったり来るものがない。ので，フルスクラッチでイチから作ることにした。

spiegel-im-spiegel/hugo-theme-text

一応， CC License にも対応している（これがない Theme が多い。こと自体 Hugo があまり使われてない証なのかねぇ）。

でも，やっぱりう～んな感じ。

Theme を作るとなると最大公約数な機能しか実装できないため，痒いところに手が届かない。痒いところに手が届く記述をしようとしたらどうしても Theme から外れるコードになってしまう。たとえば Pagination の機能を入れたくても Theme としては（汎用性が薄れるため）入れられない。

というわけで以下の方針にすることにした。

hugo-theme-text Theme では Shortcodes や Partial Template など「部品」を中心としたものを格納する
それ以外のページデザインに関する部分はビルド環境で上書きする

実は Hugo ではビルド環境と Theme の環境は同じディレクトリ構成になっていて，コンパイルの際にはビルド環境 → Theme の順で必要なファイル・データを探すようになっている。なので Theme の構成をビルド環境で完全に上書きすることも可能なのだ（そうすることに意味は無いけど）。

text.Baldanders.info のビルド環境も正式オープン前には repository を公開する予定。

さて

MTOS が期限切れになる前にブログが移転できますように。

そうそう。このサイトは「本家」としてこのまま運用を続ける予定（ブログ更新がなくなるだけ）。過去の記事もそのまま残す。 PHP とか動的ページにしなくて本当によかったよ。トラックバックは効かなくなるけど，いまどき意識的にトラックバック使ってる人なんかいないよね。コメント機能は Disqus に外出しにしているので無問題。

では，来月をお楽しみに。