先日の Middleman 4.2.1 + External Pipeline + Parcel 1.12環境を作れた - あーありがち(2018-11-23) に続いて Ruby の静的サイトジェネレータと Parcel を組み合わせる実験。

Middleman の評価については別に話があるんだけど、それは置いておく。

Jekyll には Middleman の External Pipeline のような仕組みは存在せず、各位で頑張って webpack を使う boilerplate が何個もできているような状態だったりする。

Search · jekyll webpack

これはこれで参考になるんだけど、できるだけ生で Webpack を触りたくないということで今回は前回に引き続いて parcel を使ってみることにした。

素材

• jekyll/jekyll: Jekyll is a blog-aware static site generator in Ruby
• envygeeks/jekyll-assets: Asset pipelines for Jekyll.
• parcel-bundler/parcel: Blazing fast, zero configuration web application bundler

ディレクトリ構成

前回と同様に

+- bin/
+- assets/     parcelが処理するもの
+- source/     jekyllが処理するもの
    +- assets/ parcelの処理結果かつjekyll-assetsのサーチパス

とした。

npm scriptsとnpm-run-allで処理を制御

Jekyll には External Pipeline のような賢い仕組みは存在しないので、build の際には

1. parcel
2. jekyll

の順番でコマンドが実行されるようにしてあげないといけない。

serve の際には npm-run-all で parallel に実行してあげれば両方ともいい具合に watch して rebuild してくれるのでそんなに気にする必要はない。

assets/ 以下を編集 → parcel が処理して source/assets/ に反映 → jekyll が処理して _site/assets/ に出力

が自動的にグルグル回ってくれる。

なぜJekyllAssetsか

サーバに依存しない cache buster のため。

Jekyll 自体には cache busting を支援する仕組みはなく、いろんな組み合わせがあり得る。例えば Web サーバを直接設定できるのであれば、revision を適当に URL に埋め込んで処理するという方法もある。

• Cache-busting in Jekyll, GitHub pages
• kylekirkby/jekyll-cache-buster: A simple Jekyll cache buster with all credit going to https://gist.github.com/daneden/7027258

しかしせっかく静的サイトを生成するのであれば Web サーバには依存したくないというのが正直なところで、例えば S3 + CloudFront で似たようなことをやろうと思うと Lambda 使ってくださいみたいな話になっちゃって、静的サイトでサーバ要らずとはなんだったのか？という気持ちになってしまう。

注意すべきはjekyll-assetsのファイル名の扱い、特にparcel watchと組み合わせた時

parcel にも HTML からまとめて build させるとすべて同じディレクトリにフラットにぶちまけられてしまう問題があったが、jekyll-assets には

assets/ 以下のパスをいい具合に検索する機能

があるおかげで、

同じ名前のファイル名があるとどっちが正なのか分からなくなる

という致命的な問題がある。

どういうことかというと、例えば

assets/js/site.js
       css/site.js

があった場合に

{% asset site.js %}

と書くとどっちの site.js を読み込んでよいのか分からなくなってしまうという問題だ。

上の例だと「そんなことやるわけじゃないじゃん？」と思うかもしれないが、parcel は CSS に対しても HMR 用の JS を吐くので、意図せず同じ名前の JS が生成されてしまうことはあり得るのですよ。

ということで、

parcel + jekyll-assets を使う場合はファイル名のルールをちゃんと整えるべし

と思ったのでした。

ただ、そこさえ考えておけば必要な設定がほとんどないというのはやはり魅力。そこは JekyllAssets も Parcel も優秀だと思う。

例によって成果物

wtnabe/jekyll-v3-example-with-jekyll-asset-and-parcel

こんな感じ。

やべぇ。いつもの肩こりのようなフリをして首から頭までピシピシ痛みのくる症状が出てきた。（ものすごく痛いのでこれに無策で対応することはできない。）ちゃんと気をつけてるんだがなぁ。今日の夜は出かけなきゃなんないっつーのに。

自宅サーバも NFS を活かしてリプレイスすんぞーと思っていたら、昼間試していた Debian と /etc/exports の書き方が全然違う。なんだこりゃーと思ったら Debian で入れたのはたぶん

http://unfs3.sourceforge.net/

かな？（※ 違いました。）

なんだこりゃーと思ったのは、FreeBSD の /etc/exports では同じファイルシステム（たぶんパーティションて意味だろう）のディレクトリについては1行で記述しなければならないってことで。これはパーティション1つ丸ごと（例えディレクトリは違っても）同じオプションでしか export できないってことだと思う。よく分かってないけど。

試した Debian の exports では同じパーティション内でも細かくオプションを変えて export できるので、徐々にデータやサービスを移行していくときにすごく便利。FreeBSD で同じことをしようと思ったらこの UNFS3 でやった方がよさそうだなと思うんだけど、全然具体例が見つからない。そんな細かいやり方をしようと思う自宅サーバなんかお呼びでないってことか？

むー。Linux の NFS はダメダメだぞーっていう古い情報は見つかるんだけど、そんな情報がほしいんじゃねーやい。

[2005-12-05 追記] 遅かったのは user space で動くのが理由？ Debian の package で探してみると nfs-user-server ってのと nfs-kernel-server があって、user-mode NFS は遅いぞって書いてるだけだな。実運用でパフォーマンスを気にするならやっぱ kernel-mode の方がいいんだろな。

ports から入れてみたはいいけど、今のところどうやって使うのか全然分かってない。unfsd っていうバイナリしかないので、portmap や mount は標準で付属してるものを使うのか？ そんなことできんの？ 悩むの面倒くさくなってきたんで、ディレクトリ構成を変更して id を気にしなくても移行できる形にしようかと検討中。

手元にずいぶん前にもらった図書券があったので FreeBSD Expert 2005 を目指して出かけた。、、、んだけど、パラパラと眺めているうちにうーん、と唸る。ぶらぶらと巡っていたんだけど、どうも最近読みたい本がないらしい。

散々迷った挙げ句買ったのは『増補改訂版 Java言語で学ぶデザインパターン入門』。とりあえず積んどく。テストとか設計の本にも興味あるし哲学的な本にも興味あるんだけど、最近全然食指が動かないのはなんでかな。

作れる、作る、作った　(textfile.org)

元ネタは高林さんなんだけど、結城さんの感想を含めて。

例え当たり前のことでも形にするのは案外に難しい、とワタシは常に感じています。これはワタシのデキがよくないということもおおいに意味するわけですが、日本語でもシステムでも同じじゃないかと感じています。

あ。

形にすることに対する障壁を取り除くシステムやノウハウを自分が持っている（あるいは作れる）のなら、それを表に出して行きたい、これが自分が Web 上にだらだらとモノを書き連ねたり、システム管理的なことにどうしても手を染めてしまったりする一つの出発点なのかも。

なんか思ったより簡単だった。

• ID 属性で要素を特定
• これを DOM オブジェクトとして JavaScript で持つ
• .style.display を block にしたり none にしたり

するだけ。今回は block 要素しか ON/OFF しなかったのと、visibility でいじると IE, Opera で table に対して継承されないので。その代わり HTML の方が ID 属性細かく入りまくりになるけどこれはしゃーない。汎用の Event オブジェクトから始めるとまた実装の違いを気にする必要があれこれ出てきて面倒なので今回は見送り。できあがりは以下の通り。

// 指定コンテンツの表示を ON/OFF する
function toggle_visibility( id ) {
    var obj = document.getElementById( id );
    var self = document.getElementById( 'switch_' + id );

    if ( obj.style.display != 'none' ) {
        obj.style.display = 'none';
        set_textnode_value( self, '＋' );
    } else {
        obj.style.display = 'block';
        set_textnode_value( self, '−' );
    }
}

// 指定要素の textnode を value にする
function set_textnode_value( obj, val ) {
    var ret = 0;
    var i   = 0;
    for ( i = 0; i < obj.childNodes.length ; i++ ) {
        // textNode は nodeType == 3 で判別
        if ( obj.childNodes[i].nodeType == 3 ) {
            obj.childNodes[i].nodeValue = val;
            ret = 1;
            break;
        }
    }
    return ret;
}

これをトグルさせるときにクリックする HTML の要素は

<a href="javascript:void(0)"
   id="switch_element"
   onclick="toggle_visibility( 'id' );"
   style="border: 1px solid;">−</a>

こんな感じ。表示を切り替える要素は

<div id="element">

...

</div>

こんな風にして囲んでおく。

• ON/OFF したい要素の ID を X とすると
• ON/OFF させるための要素の ID を switch_X とする

ルールにしときました。

＋と−の文字を使って今コンテンツが表示されているかの状態を示しているのは、見出しの前に置いて中身が折りたたまれているかどうかを分かるようにするため。ま、よくあるやつです。全角うぜーと思ったら適当に書き換えるよろし。

Mozilla の JavaScript コンソールがあると楽だなぁ。

FreeBSD Expert

2005.

買っておくかなぁ。

Firefoxに続け–バージョン1.0公開が迫るモジラの電子メールソフト

from CNET Japan

あかんやろ。

Thunderbird は Firefox に比べると雑すぎる。中身を見たわけじゃないけど、1.0 までのペースが速すぎるし、かなり「かゆいところに手が届かない」シロモノなのは間違いない。まー自分は使ってるけど、とても Firefox 1.0 のようには他人に薦められない。少なくとも日本では POP before SMTP には対応してくれないとね。

Space Saver II の CapsLock の引っかかりがあまりにひどいので DELL の PowerEdge についてきたキーボードと取っ替えてみた。このキーボードは柔らかい感触でけっこう好み。

（ちなみに、PowerEdge 400 付属のもの。1400 も同等だったと記憶しているが、1600 は明らかに質が落ちた。最近の DELL のサーバ付属のものはきっとみんなコストダウンのあおりを受けているに違いない。）

しかしトラックポイントのないキーボードはやはり非常に使いづらい。勢い、マウス操作をきらい、すべて一つの terminal の中で screen で切り替えて使いたくなるってものだ。でもそれもそんなに使い勝手よくないしなぁ。こうなるとタブ切り替え式の terminal がほしくなるのか。確かに local のサーバに繋ぐ分には screen である必要はあんまりないしなぁ。

うーーーーーん。