先日Jekyll と Middleman の比較をして、Jekyll の方が拡張はやりやすそうという結論を出したわけだけど、実際に書くとなったら公式のドキュメントを読んでるだけだとピンとこない部分があって、それが Generator.
Generators | Jekyll • Simple, blog-aware, static sites
いきなり Generator に site オブジェクトを突っ込んで、そこから Page を生成する例が出てくるんだけど、なんでこれでうまくいくのかがよく分からない。
この理由はそもそも全体の流れが説明されていないから。ということでコードを読んでみることにする。
対象バージョンは現行の Jekyll 3.8.5
まずはcommandから
jekyll の操作は
$ jekyll <command>
から始まる。これを担うのが commands/ 以下のコマンド群だ。
exe/jekyll
を読むと command 群は init_with_program が呼ばれるのが分かるので、例えば build.rb で追っていくと
def init_with_program(prog)
prog.command(:build) do |c|
c.syntax "build [options]"
c.description "Build your site"
c.alias :b
add_build_options(c)
c.action do |_, options|
options["serving"] = false
Jekyll::Commands::Build.process(options)
end
end
end
中で process を呼び、process では
def process(options)
..
site = Jekyll::Site.new(options)
..
build(site, options)
build を呼んでて、
def build(site, options)
..
process_site(site)
process_site は superclass の
def process_site(site)
site.process
で、Jekyll::Site オブジェクトにたどりつく。
すべてを司るJekyll::SiteオブジェクトからGenerator#generateが呼ばれる
Jekyll::Site#process はこれだけ。
def process
reset
read
generate
render
cleanup
write
print_stats if config["profile"]
end
これを見るとピンとくるのが
Hooks | Jekyll • Simple, blog-aware, static sites
ですね。ここでようやく全体の流れが分かる。これを見ると Generator は Reader と Renderer の間で仕事をしていることが分かる。
generate の中身は
def generate
generators.each do |generator|
start = Time.now
generator.generate(self)
Jekyll.logger.debug "Generating:",
"#{generator.class} finished in #{Time.now - start} seconds."
end
end
登録された Generator それぞれの generate メソッドに Jekyll::Site そのものが渡され、site を書き換えることでコンテンツを増やし、その後 render, write が仕事をすることで実際のファイルが生成される、という流れになる。
なるほど。
Generator間の依存関係はpriorityで調整
generator の初期化は site.rb の #setup の中の
self.generators = instantiate_subclasses(Jekyll::Generator)
からの
def instantiate_subclasses(klass)
klass.descendants.select { |c| !safe || c.safe }.sort.map do |c|
c.new(config)
end
end
で、ここの sort で plugin.rb の
def self.<=>(other)
PRIORITIES[other.priority] <=> PRIORITIES[self.priority]
end
が呼ばれて、priority の高いものから並ぶようになっている。
※ ちなみにこの setup が実行され終わる時に after_init に register した hook が走るようになっている。
したがって、例えばカテゴリやタグといった情報をもとにイマドキのリッチなスライドっぽいリンクを並べた一覧ページを作りたいということになったら、
- Page をなめて content から data ( Front Matter ) の中に最初の heading や paragraph, img など、リンク生成時に使いたいデータをまとめ直す処理を行う
- 1 のデータをもとにカテゴリやタグの Page を追加する
この際に 1, 2 の順になるように priority を調整する、という感じで利用することができる。
※ これくらいならひとまとめでもよさそうだけど、他の generator で生成したコンテンツも利用できるようになっていた方が都合がよいかもしれない。分かってくると Ganerator は応用範囲が広い感じがする。
MiddlemanのproxyのようなものもGeneratorで解決できる
考え方は以下のような感じ。
- site.data, site.pages などから必要なデータを取得して
- 取得したデータをもとに Jekyll::PageWithoutAFile を継承した Page を生成
- この際、Page#initialize とはリスコフの置換原則を破るようにしないと page 独自の data は渡せないことに注意が必要。
def initialize(site, base, dir, name)
適当に keyword args 足せばいいと思う :p
layout はいちいち指定してもいいけど、_config.yml の defaults で一気に指定するようにした方がたぶん他のものと整合性が確保できてよい感じになる。
Front Matter Defaults | Jekyll • Simple, blog-aware, static sites
相性問題勃発。
nadoka を単なる bot として使ってる分には問題ないというか気づかなかったが、proxy として使おうと思ったら意外な問題が複数発覚。
- ircd-hybrid のサーバに置いといた proxy にクライアントで接続しても channel に join できない
- IRCnet のサーバに置いた proxy に繋いだ場合はイケる
- proxy としての nadoka に X-Chat Aqua で繋ぐと PONG メッセージが延々と出続けてうざすぎる
- nadoka 側の設定にも X-Chat 側の設定にもこれを消す方法はとりあえず見当たらない
- nadoka:252 から続くスレッドなどでガイシュツで、自分の環境だけの問題ではなさげ。
ircd-hybrid サーバの方には proxy として使えなくても直接 tunnel で繋げるからいいとして、IRCnet サーバへの proxy として使おうにも X-Chat と相性が悪いっつーのはかなり痛い。
検索エンジンとかソーシャルブックマークとかについては考えてませんが、通常のサイトでは、
- リダイレクトさせたいのはユーザーじゃなくてサイト
- サイト側でユーザーの動向を把握したい URL は、自分のサイトと直接的に何らかの関係のあるサイトのはず
- したがって任意の URL へジャンプできるリダイレクタではなく、サイト内で確認済みの URL へのリダイレクトだけを許可
するようにしたらダメなんでしょうか？ つまり、リダイレクタに URL が与えられたら、それが内部に登録済みのものかどうかを検証してからリダイレクトする。（つかそうなってないと集計とかしにくいでしょ？）
もちろんユーザーが自分で URL を登録できる場合は危険な URL を登録されるかもしれないのでこれだけではダメなんですが、ちょっとそれを考え始めるとややこしいんで今回は除外します。
個人的にはリダイレクタは脆弱性だ！なんてことを言う気はないけど、問答無用で任意の URL にリダイレクトできるということであれば、それはちょっとアレだと思うなぁ。
[2007-01-30 追記]自サイト内で生成したリダイレクト用の URL かどうかは HMAC を利用して検証するのが性能面ではよさげ。DB にアクセスしなくても妥当かどうか判定できる。もちろん内部でのカウントなどの処理のためには、実際にリダイレクトする際には DB アクセスは必要（あるいはログを吐くだけという手もあるか？）なんだけど、パラメータの妥当性はその前段階で検証できるので、DB の負荷が減るということですな。しかしそうなるとリンクの際の URL はどんどんかっこ悪くなっちゃうんだな。そこはアプリというかサイト側の工夫の見せどころか。
IBMのPC事業売却が正式決定–売却額は17.5億ドル (CNET Japan)
20% 近くの株式を保有する形なのですか。ジョイントベンチャーってのがなんだかよく分からないけど、
Lenovoは、IBMからPCに関する優先サプライヤーの扱いを受けることになり、また5年間にわたって「Think」ブランドを含むIBMブランドを使用できることになる。
この部分、前は5年経ったらもう Think ブランドが消えるのかーと思っていたけど、逆に5年経ったら IBM しか Think ブランドが使えなくなるのかもしれないし、いい方向に考えることも可能な気がしてきた。少なくともパソコンなんか儲からないことはやんないぜ、っていうことだけではないのは間違いなさそう。
不安が消えるわけではないけど、思ったほど単純な売却話ではなさげで、少しほっとしたかも。でもなぁ、サポート体制とか全部ひっくるめて ThinkPad クオリティですから。その部分の低下は避けられないんだろうなぁ。PC 会社に売却ってことになると PC 事業としての収支は前より厳しく判断されるのは間違いないもんな。
東大生の家庭は高所得とは限らないらしい。
例の OECD 調査で日本は
- 読解力が落ちた
- 勉強する意義を見失ってる
- 学校・教師への信頼感がない
という傾向らしい。
学校・教師への信頼感のなさは前からだと思うけど、読解力が落ちたのってなんで？ 活字離れがいちばんひどい年代に当たった？ でも活字離れもずいぶん長いしな。
このネタふっかけて飲んだら面白そうだなぁ。
from textfile.org
なにゆえって書いてあるけど、要するにコンテンツ流通業の寿命を延ばそうってことだと思う。でもそんなことするとコンテンツ流通業はまた本気の生き残り策を考えなくなるからやんない方がいいと思うな、個人的にはね。今生きている著作者とともにコンテンツを作る努力をしましょうよ。発掘しましょうよ。いつまでも古いもんにしがみついてると新しい文化が育ちませんよ？
えーと。言い訳するわけじゃないですが、わたしゃお笑いの感度は低い方ではないと思います。割と幅広く笑えます。落語からふかわりょうまで笑えます。あと、流行りモンがきらいっつーのはありますが、別にお笑いブームだからお笑いにケチつけたいわけでもありません。
でもねぇ、最近のお笑いは、「昔だったらただの漫才のフリに使われていたようなものを使った一発コメントの変形版とコントばっかやんけ！」という状況でしょう？ 言ってみればだいたひかるも長井秀和も波田陽区も基本はみな同じ。1しかもコンビなのにピンと同じレベルだよ！というものまで。実際には客のレベルに合わせてるのかもしれないけど、レギュラー！君らそれでいいのか？ 日テレが悪いんだろうけど、なんか疑問を感じずにはおれん。「あるある探検隊だけ」やったらコンビの意味ないやんけ。
あと、アンガールズは絶対コントやる前の方が面白かった。
ところでオンエアバトルで爆笑編を11時から、熱唱編を1時からとかいう変則的な編成はできないんでしょうか。最近はもうオンエアバトルの時間まで起きてられません。
長井秀和は話芸としてレベル高いと思う。もっと長いネタをやっても耐えられるだろう。 ↩
電池が減ってきたと思ったらいきなりなくなる。
最近の携帯ってみんなこんなもんなのかなぁ？ ずいぶん機種変更しなかったから（何しろ初めてのカメラつきだ）最近の事情がよく分からない。でも talby は本体を小さくするためにバッテリを犠牲にしてるってのは十分にありそう。
ただ残量表示をもう少しうまく調整しておいてほしかった。「いきなり感」は調整でなんとかなるんじゃないかと思う。
出ちゃったですが。
今回は Firefox と違って日本語版が同時に出てません。なんかこれだけ見ても Thunderbird と Firefox の力の入り方の違いが分かりますな。日本での力の入り具合という意味でもそうだけど、世界各国版を同時にドーンと出したいという要求が本家側にないという意味でも。だってああた、仮にも Mozilla Japan のある日本で母国語版が同時にリリースできてないんですよ。なんじゃそりゃですよ。Mozilla Japan なんかあったって全然本家に重視されてないじゃん。
あと UI がちょっと。IMAP 対応してるのに、それが分かるのって新規にアカウントを作成するときだけってのはもったいない。アカウントの設定のところにも IMAP で使えるって分かるような何かがほしいと思う。
まーそれよか POP before SMTP 付けてくれっつー話なんですけど。テスター不足なんですかねぇ。やっぱり。