プロジェクト名とか考える、ほか

この記事は筆者が見た夢を一人称視点で叙述した内容です。事実ではなく、実際の人物等とは一切関係ありません。

プロジェクト名とか考える、ほか

  1. 自作ブログソフト?
  2. URI設計と実装

自作ブログソフト?

よく考えたらJigってWeb関連でちょー有名なソフトがあったんだった…。すっかり忘れてたよ。 つーわけで、とりあえずMayとでも命名する。←ギャグじゃない。

  • 5月にはじめて形になったから
  • 「たぶん」とかいろいろ助動詞的な
  • 「めい」っていう名前が好き

いろいろあるけどこれで頑張れる。主に最後の理由による。

逆にこれくらい氾濫している言葉だったら商標とかにひっかからないだろ、という算段。ひっかかってたらワロス。

ほんとはMay2で「メイメイ」って読ませて「命名に悩んだのでメイメイで!」というギャグみたいなほんとの話で受けを狙おうと思ったら、某所で同じ名前の看板娘がいるのでいろいろな意味でやめといた方がいいと思ったとか、そんな話。

URI設計と実装

興味深いエントリ。

ただ、http://aereal.org/foo/bar//foo/bar/というディレクトリへのアクセスと考えて、Index of的な表示を行っているんだったら、/foo/barでアクセスすると挙動が違うのはあんまりスマートじゃない気がする。

  • foo/
    • bar(.html)
    • bar/

確かにこんなディレクトリ構成がありえないわけじゃないけど、Apacheでは/foo/bar/というディレクトリがあると、/foo/barというリクエストを/foo/bar/へリダイレクトする機能を提供するmod_dirというモジュールがあるわけで。しかもオンになっていることが多い。

そういう事情を踏まえると、ありえないわけではないけどあんまりよろしくないディレクトリ構成なんじゃないかな、と思うわけで。そういうわけで、/hoge//hogeで振る舞いを変えるのはどうなんでしょ。ただ、実質的な振る舞いは同じとみることもできるので、こんな風に突っ込むようなことじゃないのかもしれない。

ただ、似たような機能 (仮想ディレクトリ構造を提供する) を持つアプリケーションを開発しているので乗っかってみたかったんです。ごめんなさいごめんなさい。

しかし、やはりネットは広大だなあ。別に自分がやろうとしていることは目新しいことだと思っているわけではないけど、それでも日本の中で自分が知り得る範囲でいくつか同じ様な実装をしているアプリケーションでブログとか日記とかそういうものを構築している人はいるもんだ。

実装の構想は大体固まってきたけど、保存する媒体に悩む。

ファイルで保存するとURIに束縛されて、どちらかが変わると何かを変えなきゃいけなくなる。実装かファイルのロケーションかURIか。つまり取捨選択。

データベースで保存すると今度は実装がめんどい。SQLとか勉強しなきゃいけないし。ただ、XMLデータを取得するキーを複数持てるのはいいと思う。例えば日付やカテゴリやタグや作者。

どちらにせよ、該当エントリ数が多くなりがちな年間/月間アーカイヴ、記事の一覧はXMLデータの最小単位を日やエントリにすると生成コストがとても高くなる。気がする。

  1. リクエストURIをパースする
  2. パースした結果をもとにDB或いはファイルからXMLデータを取得
  3. XSLTプロセッサにかける
  4. 適切なヘッダと共にレスポンスをかえす

エントリや日単位だとこれだけのステップで済む。しかし、月間アーカイヴなんかだと増える。

  1. リクエストURIをパースする
  2. パースした結果をもとにDB或いはファイルから複数のXMLデータを取得
  3. XPathやらDOMやら使って取得したXMLデータ群を走査し、アーカイヴのXMLデータを生成
  4. XSLTにプロセッサにかける
  5. 適切なヘッダと共にレスポンスをかえす

たった1ステップだけど明らかに怖いステップだ。キャッシュを実装していないUAやそもそもキャッシュを持っていないUA (=初回アクセス) なんかのリクエストが集中したらあっという間にDEAD.

これがダイナミックパブリッシングの痛いところだよなあ。

結局、バックエンドにDBを据えるかファイルを据えるかは別にして、月単位以上のアーカイヴはサーバサイドキャッシュとしてあらかじめXMLデータをスタティックに生成するのが一番いいように思う。