静的サイトジェネレーターとGitリポジトリでブログ
Pagent
Linuxや静的サイトジェネレーターなどで困ったことについて検索していると、Qiitaというサイトを目にする機会が増えた。
博学な人が居るものだと感心していたら、個人でやっているサイトではなく、プログラマー向けの情報共有サービスなんだね。
Qiitaについて - Qiita
記事を参考にさせてもらって助かったことは何度かあるが、自分自身はプログラマーじゃないし、何がどう便利なのか分からないので、利用しようという気にはならないが。
repositoryは「リポジトリ」と表記するのが順当のよう。
「レポジトリ」としていた表記を「リポジトリ」に改めるため、ブログ投稿内で「レポジトリ」を用いているものを調べてみた。
source/_postsで端末を開き、下記コマンドで抽出。
$ grep "レポジトリ" *
*ですべてのファイルを検索対象に。
.mdファイルのみを対象にするなら*.mdに。
またサブディレクトリ以下を再帰的に検索する場合は
$ grep -r "検索ワード" *
たくさんあって手作業で修正するのは大変そうなので、下記コマンドですべての.mdファイル内の「レポジトリ」を「リポジトリ」に一括変換。（元ファイルは拡張子.bakを付けてバックアップ）
$ perl -p -i.bak -e 's/レポジトリ/リポジトリ/g' *.md
正常に変換されたことを確認後、.bakファイルを一括削除。
$ find ./ -type f -name "*.bak" -delete
もし不具合があれば、特定のファイルに対しては下記で復帰可能。
（example.md.bakをexample.mdに名称変更し上書き）
$ mv example.md.bak example.md
ただし、mvコマンドは複数のファイル名の一括変換は出来ないようなので、すべてのファイルを元に戻す場合は、一旦すべての.mdファイルを削除してから、すべての.md.bakファイルの拡張子を.mdに変換。
（renameコマンドは上書きは出来ないようなので）
$ find ./ -type f -name "*.md" -delete
$ rename .md.bak .md *.bak
以前はrename 's/.md.bak/.md/' *.bakでファイル名を一括変換出来てたと思うのだが、rename .md.bak .md *.bakでないと上手くいかない。
（参照記事）
Linuxコマンド逆引き大全 - 【 ファイルから文字列を検索する 】：ITpro
複数ファイル内の文字列を置換して上書き保存する
ーー
（追記）
perlで語句を一括変換する際、複数のファイルを対象にしたい時は、間に半角スペースを入れて列記。
（複数ファイルの時も正規表現が可能）
$ perl -i -p -e 's/置換前の語句/置換後の語句/g' A.html B.xml
$ perl -i -p -e 's/置換前の語句/置換後の語句/g' *.html *.xml *.txt
repositoryは「レポジトリ」だと思い、そう記載していた。
だが「リポジトリ」の方が、どうやら原音に近いようだ。
repositoryの意味 - 英和辞典 Weblio辞書
英語が母国語らしい人の発音でも、人によっては「レポジトリ」に聞こえたりはするが。
日本でも「リポジトリ」の表記の方が一般的のようなので、過去記事の記載をすべて「リポジトリ」に変更した。
今日何度か、GitHub Pagesのこのブログが表示されなかった。
GitHub Pages is temporarily down for maintenance.
と表示されていて、サーバーのメンテナンスのよう。
Down For Everyone Or Just Me -> Check if your website is down or up?で調べた時には回復していた。
pingコマンドでもサーバーの疎通を確認出来るようだ。
コマンドを実行すると延々pingが送信されるが、「CTRL」+「C」キーで停止すると結果が表示されるらしい。
Linuxコマンド【 ping 】ホストとの接続を確認 - Linux入門 - Webkaru
確認した時には「0% packet loss」だった。
初めてだったので驚いたが、GitHub Pagesもメンテナンスするんだね。
ーー
（追記）
その後も落ちたり回復したりの繰り返し。また、見られないページがあったり、Font Awesomeが文字化けしたりと不安定。
静的ページだし、信頼してたのに。
大丈夫なんだろうか。
FirefoxのRSSアドオン「Brief」の調子が突然おかしくなった。
新たにフィードを追加しても、一覧に表示されない。
brief.sqliteをリネームしたり、Briefをインストールし直してみたりしたが、改善せず。
Briefの派生アドオン「Digest」も既に削除されており困ってしまったが、BriefのページBrief :: Add-ons for Firefoxの一番下に「開発チャンネル」というのがあった。
Version 2.0b1となっていて、どうやら開発版のよう。
ダメもとでインストールしてみたら、追加したフィードがちゃんと表示された。
メニューは英語だし、安定性にやや問題があるのかもしれないが、とりあえずは普通に使えるので助かった。
ーー
（追記）
開発版のインターフェースは安定版と少し違っていて最初は戸惑ったが、記事内容を省いてタイトルのみを表示させるボタンがあったりするので、安定版よりも便利かもしれない。
ーー
（追記2）
2014年3月14日現在、安定版のBrief1.7.3は最新版のFirefox 36.0.1には対応していないようで、「BriefはFirefox 36.0.1と互換性がありません。」と表示される。
Firefox 36.0.1でBriefを使うには開発版を使うしかないようだ。
プロファイルに旧Briefのbrief.sqliteファイルが残っていれば開発版もこれを読み込んでくれるが、開発版Briefを新たに使用する時は、適当なサイトのフィードを追加。
フィード追加の際、「このフィードの購読に使用するフィードリーダー」で「Brief」を選択して「購読」。
（「フィードの購読には常に Brief を使用する」のチェックは外しておく）
ブックマーク内の「Subscribed Feeds」（購読済みフィード）フォルダが読み込みフォルダになるので、その後は購読に使用するフィードリーダーを「ライブブックマーク」にしてフォルダを指定。
これで読み込みフォルダの階層化も可能になる。
突然の不具合で購読済みフィードを読み込んでくれなくなり「まだフィードを追加していません。追加する方法を確認しましょう！」と表示された時にも、上記同様新たに「購読済みフィード」を作成し、旧フォルダからライブブックマークを移動することで復旧出来る。
※以前のBriefは設定で読み込むフォルダを指定出来ていたと思うが、最近のバージョンのものはフォルダを自由に選べないようだ。
少し不便。
ーー
（追記3）
その後Briefが更新されて通常版でも問題無く使用出来ていたが、2015年11月に入ってからまたフィードの追加が反映されなくなってしまった。現在の開発版2.0b3をインストールしてみたがやはりフィードを追加出来ない。
Briefの不具合が修正されるのを待つしか無さそうだ。
ーー
（追記4）
2015年12月5日、バージョン 2.1.1.1-let-fixedがリリースされて、フィードを追加出来ないバグがやっと修正された。
設定などが英語表示になっているが、使い方は分かるので問題無い。
見やすいし、週間天気予報や台風情報などもあって便利なので、ネットで天気予報を見る時は「天気予報 - ウェザーニュース」を利用して来た。
だがLinuxに移ってから、Firefoxで「ウェザーニュース」を開くと、とたんに重くなりFirefoxがフリーズする。
システムモニターを見ると、メモリ7.7GiBを使い果たしスワップを利用している。
Flashを使っているからといって、なぜこんなに重くなるのだろうか。
動画サイトでもこんなことはないのに。
Windowsでは大丈夫なので、Linux（Xubuntu）のFlash Playerのバージョンの問題かもしれない。
仕方がないので「ウェザーニュース」は諦めて、「日本気象協会 tenki.jp」を使うことにした。
利便性はウェザーニュースより多少劣る気がするが、いちおう「10日間天気」等もあるし。
普通の計算機で表示出来るのは10桁くらいまでだが、カシオのフリー計算はなんと50桁まで表示される。
高精度な高等関数が使えるフリー計算
たとえば、ヒトヨヒトヨニヒトミゴロの√2も
1.4142135623730950488016887242096980785696718753769
と表示される。
（普通にはコピペ出来ず、「要素を調査」しないとコピペ出来なかったが。）
ヒトナミニオゴレヤ（√3）
1.7320508075688772935274463415058723669428052538104
フジサンロク（に）オオムナク（√5）も
2.2360679774997896964091736687312762354406183596115
他にも色々な計算が出来るようだ。
日常では必要無いと言えば無いのだが。
生まれて初めて見た電子計算機（電卓）も、もちろんカシオだった。
起動時に点滅する緑色の液晶が滅茶苦茶かっこ良かった。
やっぱりカシオはすごい。
思い煩うな。人生など つかの間だ。
以前、「思い煩うな。人生は無意味なのだ。」という名言を見たことがあった。
誰の名言だったかと検索してみたら、どうやら英国の作家サマセット・モームのものらしい。
だが、原文が分からない。
“The secret to life is meaningless unless you discover it yourself.”
（「Of Human Bondage」邦題：「人生の絆」より）
Of Human Bondage Quotes by W. Somerset Maugham
はちょっと違うようだし。
どちらもブログとしての体裁が整っていて、導入したらすぐ始められるHexoとOctopress。
しばらくHexoを使ってみて、Octopressと比較しての感想。（あくまで私見）
長所
・generateが早い
Hexoの長所はなんと言ってもこれだろう。
手動での計測だが、30程の記事ソースからgenerateするのに要した時間は、Octopressの12.5秒に対して、Hexoは2.3秒と5分の1以下だった。
今後、記事数や使っているタグ、カテゴリーが増えれば、Octopressの遅さはかなりのマイナス要因になると思われる。
Hexoはプレビュー時の変更の反映も早い。
・デフォルトで日本語のタグ名（カテゴリー名）を使える
URLがパーセントエンコーディングされると長くなるし何の記事か分からなくなるので、パーマリンクに日本語を使おうとは思わないが、タグやカテゴリーに日本語を使えるのはとても助かる。
Octopressでもカスタマイズすれば日本語のカテゴリー名を使えるようだが、デフォルト状態では漢字は中国語読みらしきローマ字表記に変換される。（たとえば、「未分類」は「wei-fen-lei」に。）
仮名はほぼ正しくローマ字表記に変換されるが、何故か「の」は「false」に。「の（no）」をyes・noの「no」と判別するためか。
・Windowsで使える
あくまで自分の環境でだが、WindowsではRuby（Octopressのプログラミング言語）が正常に動作しなかった。
一方、Hexo（JavaScript使用）はWindowsで使用可能だった。
検索するとWindowsにJekyllをインストールする方法も紹介されているので、環境によってはOctopressもWindows上で使えるのかもしれない。
・コマンドが簡単
hexo new→hexo n、hexo generate→hexo g、hexo server→hexo s、hexo deploy→hexo dのようにコマンドの省略が可能。
辞書登録すればあまり関係無いが。
短所
・SEO
Octopressはデフォルト状態でもsitemap.xmlとrobots.txtを生成してくれるが、Hexoでは導入が必要。
ただ、Sitemapを作ってくれるプラグインは有り、導入も容易。
・中国製？
どうやら中国製のよう。
ソースはGitHub上で公開されていることだし、安全性に問題は無いと思われる。
・FrontMatterの書式がOctopressと違う
他の静的サイトジェネレーターでも、FrontMatter下部だけではなく上部にも---が入るのが一般的のよう。
この先、他の静的サイトジェネレーターに移行する可能性を考えると、ここは合わせて欲しかった。
・ユーザー数が少ない
Static Site GeneratorsのStars（「いいね」みたいなものの）は、2014年12月5日時点で、Octopressの8522に対しHexoは3430とOctopressの半分以下。
（1位はOctopressの本家Jekyllが17578と圧倒的）
何か調べ物をする時にも、特に日本語では、参考になるドキュメントは少なくなる。
Octopressより後発なので、今後増える可能性はある。
・コマンドがかっこ悪い
ことある毎にhexoと連呼しないといけないのが、ちょっとかっこ悪い。
引き分け
・テーマの豊富さ
自分の知る限りでは大差はない。
テーマの変更や微修正の容易さでは、Hexoに分があるよう。
・カテゴリーとタグのあつかい
Octopressの”categories”はHexoでは”tags”に相当する。
複数設定した際、階層ではなく並列になる点からすると、”tags”としてあつかうHexoの方が自然な気はする。
結論
Hexoのgenerateの早さはやはり魅力的なので、今後プログラミング言語がRuby製の静的サイトジェネレーターに積極的に移ろうという気はしない。
他に面白そうな静的サイトジェネレーターが出てこない限り、今後もHexoを使うことになりそうだ。