静的HTMLへの移行方法について考える

公開:2014-08-04 19:44
更新:2020-02-15 04:37
カテゴリ:node.js,nginx,wordpressから静的htmlへ,ブログ,javascript

大風呂敷を広げてみたものの

Webの世界は広大である。HTML5 APIもさまざまなものがあり、全貌を把握するにはまだ至っていない。今日もHistory APIというものを見つけた。まずは規格書を読むのがよさそうだが、じっくり読んでいくと死ぬまでかかりそうだ。今回移行後のサイトは過去のしがらみを捨て、HTML5 API以降のみの技術で構築するつもりである。過去の互換性は考えない。ある程度ライブラリが吸収するくらいにとどめる。さらにモダンブラウザの中でもChromeをまずはファースト・ブラウザとして考えようと思う。でもChromeも規格通りの動作かどうかは保証されないからそのあたりのPolyfillも必要だろうし、HTML5 APIも過渡期だから規格通りに作っても改訂されるからしばらくは修正を行っていかなくてはいけないだろう。Chromeは随時自動アップデートされるのでそれに合わせて確認・修正していく形で進めていこうと思う。

Q を使用して移行スクリプトを書き換えてみる

今node.jsを使って移行スクリプトを書いている。昨日からQを使って非同期処理を書き直してみた。 Qは非同期処理でよく出てくるPromiseとかFutureとか言うのをサポートしている。Defferdとかともいうのかな。これによって非同期処理をシーケンシャルに書き下すことができるようになり、コードの見通しがよくなる。node.jsはノンブロッキングI/Oが基本だから、コールバックを多用する。コールバックが多いとシーケンスが進むにつれてネストが深くなって非常に見づらくなる。 機能詳細はまだよくわかっていないけれども、Windows Store App + pplで学んだ非同期プログラミングの経験(というほどのものではないが)役立っている。 関数もbindで引数束縛とかもできることを今日知って、これもC++とかのbindの知識があったので結構すんなりと頭に入る。ただ引数のプレースホルダとかの考え方はないけども。

次バージョンのnode.jsでは本物のPromiseやyieldが実装されているそうなので、Qを使わなくてもよくなるかもしれない。ただQは同期・非同期両方をthen()のチェーンに入れることができるし、まあQ側でJSネイティブの実装へのサポートも行われるだろうから、とりあえず使っておくことにする。

実装中のコード。

今のところMySQLでコンテンツを読んで、/年/月/のディレクトリを作りそこに静的HTMLもECTでレンダリングして保存し、さらにそれをgzip化して保存するところまではできている。 ただ私用のコードだからエラー処理は例外投げっぱなしでリカバリーとかはあまり書いていない。 今ファイルとパーミッション設定部分で問題が起きている。fs.chmodだとちゃんと動かない。何か問題があるのだろう。もでfs.chmodSyncだと動いたりするので不思議である。今はコメントアウトしていて、ノードで実行後シェルでパーミッションやオーナーの変更を行っている。この方が楽だったりする

nginxでURLを書き換える。

WordpressのURLをそのままリダイレクトして静的コンテンツに誘導するコンフィグもちょっと書いてみている。 WordpressのURLは基本的に/年/月/(記事名)/となるように設定している。今回のコンテンツは/年/月/(記事名).htmlとする予定なのでurlを書き換える必要がある。 方法としては2つあり、rewrite(リダイレクト)する方法とproxy_passするときにURLを書き換えて渡す方法がある。rewriteはリダイレクトし、proxy_passは見た目リダイレクトしていないように見える。

最初の方法は以下のような感じで書く。

location /blog/ {
   rewrite ^(.*)/$ $scheme://$host/$1.html permanent;
}

2番目の方法はnginxのドキュメントに書いてある。

When the URI is changed inside a proxied location using the rewrite directive, and this same configuration will be used to process a request (break):

location /name/ {
    rewrite    /name/([^/]+) /users?name=$1 break;
    proxy_pass http://127.0.0.1;
}

In this case, the URI specified in the directive is ignored and the full changed request URI is passed to the server.

私は2番目の方法で行こうかなと思っている。