衒思力発電所

dvorak.jp システム変更完了

http://dvorak.jp/

冬休み終了と共に無事に終わりました．本当にありがとうございました．まあまだコンテンツはスカスカのままなんだけど，前のより俺比 16 倍くらい楽に更新できるようになったんで今後に期待．

そしてさりげなく tsuikyo_js の正式版を公開してるよ．だけどドキュメントとかはまだなんで，うん，まあ焦るなって． 前小出しにしてた版から OO にして全部ローカルスコープに押し込んだり，キャンセル入力と普通の戻れないタイプの柔軟入力と表示そのままの打ち方しか許可されない超剛直モードとを動的に切り替えれるようにしたりローマ字テーブル基本のもの内蔵したり^*1 30% くらい高速化したり jQuery 依存やめたりと大分変更は大きい．

システム乗せ換えについて書こうかと思ったけど，疲れたので，作業中のメモをそのまま載せて代えることにする．

dvorak.jp KinoWiki に乗せかえメモ

強力なCMSは小規模サイトのために弄るのめんどそうなイメージで敬遠
Python の勉強かねて Python 製 Wiki クローンでも使うかと思ったら KinoWiki (PHP) ソース美しい！　という情報を見てコロっと死亡

http://kinowiki.net/index.php/%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89
で v2.1 安定版らしきものを落とす

index.php を編集して基本設定
とりあえずスキンとかテーマとかデフォルトのままで。
hideableディレクトリの名前変えようかと思ったけど .htaccess で deny from all なってるからいいや

hideable/{data, templates_c} に write パーミッション
templates_c って Smarty な

ブラウザアクセスしてみる
とりあえず動く
が、default テーマが貧弱ってレベルじゃねー css 適用されてるのか疑いたくなるレベル
hatena-sepia にしたら気分落ち着いた
デフォルトサンプルがはてダスタイルっていうのがいい香り

さてどこから弄ろうか
方針：汎用性とか犠牲にしてガシガシ専用に手抜き工事

html 出力の雛形は
hideable/skin/default.tpl.htm
これか。 Smarty とか知らんけど雰囲気でなんとかなる
dvorak.jp の html テンプレートとして移植、テストおｋ

html ソースみてみる
段落が <div class=”paragraph”><p>hoge</p></div> と出力されてきてキモい
意図は知らんが div は解き放ってしまうことにする
hideable/htmlconverter.inc.php 内 visitT_Paragraph() がやってる。内部表現を出力文字列に変換する処理はこのファイルにまとまってるのね
div で wrap してる部分コメントアウトしてテスト。おｋ。
レンダリングもまあ問題ないきがする……？
テーマによるのかもしれんが切り替えたりしないだろうから無視

次にページURLが全部 http:// で始まる上 index.php に引数渡すのとかご丁寧に書いてあって要するにクソ長いのをなんとかする
hideable/kinowiki.inc.php 内で SCRIPTURL を絶対URLで define してこれを使いまわしているもよう
ドメイン直下に置くんで define(’SCRIPTURL’, ”); としてみる
default テーマ崩壊ｗｗｗｗｗ
テンプレートファイルが参照してる $theme_url とかが影響で死んで css 読めてないせい
$theme_url 使うのやめて直接 theme ディレクトリへの絶対パスをテンプレートに書いてしまう
ページリンクは正しく出力されたが index.php に引数を与える目的で href=”?cmd=hoge” とかなってると動かないね
Smarty で使ってる $script が SCRIPTURL 依存っぽいのでそちらを修正
hideable/smarty.inc.php 内で $script を SCRIPTURL . ‘/’ とする。
解決

考え直すと絶対URLが http://dvorak.jp/hoge/page とか微妙
拡張子 htm つけて静的にみせかけるのちゃんと徹底しよう
アーミーナイフこと mod_rewrite にがんばってもらう
後から意図しないURL書き換え起こって嵌るの怖いけど明日のことは明日考えることにする
ページ URL 末尾に .htm 足すのは hideable/func.inc.php 内 getURL() に変更
出力、アクセスどちらも問題なし

さて次
あいまいリンクとかオートリンクとか重そうだし必要ないし邪魔げ
でも設定でOFFにできない様子。
KinoWiki の一大特徴だって？ ……あらら。
hideable/parser.inc.php 内 T_Text->parse() でリンクノード作ってたのでコメントアウト。
おかげでパーサとコンバータの動きがわかったぜありがとうさようなら AutoLink

しかしページ遷移重い
出力をキャッシュしてない？
PEAR::Cache_Lite がご丁寧に library/pear 下に同梱されてるんだから使えばよくね
なんか毎回動的なことするプラグインとかのこと考えてやってないんだろうな
汎用性とかねーよと割り切って導入して後から困ればいいですねはい
http://riaf.jp/lang/php/app/KinoWiki　参考にしてキャッシュ導入

html 受信完了まで 550ms -> 240ms くらいになった
今回線しょぼくて静的テキストの読み込みで 180ms くらいかかってるからこんなもんかね

と思ったらやっぱ不具合
footnote は render 直前につくみたいで参考 URL の方法のままじゃキャッシュ利用時に footnote 消えちゃう
キャッシュにするデータを cmd/show/show.inc.php 内ではなくて
hideable/renderer.inc.php の render() でやって plugin とか独立 cmd とかの出力も
キャッシュにぶち込むようにして解決
このままだとアクセスカウンタとかを KinoWiki プラグインでやるとカウンタの数値まで
ページの last-modified 依存でキャッシュされるという残念なことになるけどまあそこまで KinoWiki 依存はきもいからやらんだろ

次
ユーザ管理して一般閲覧者は編集できないとかそういう機能
……は標準ではないみたいね php 弄るのめんどがってメタに解決
俺だけ編集できりゃいいので編集関連 API をごにょごにょして隠蔽
ついでにないよりまし basic 認証も
edit とか new とか show とかリクエストに応じる各処理は cmd/ 内 Command からの派生クラスファイルちぃおぼえた

汎用関数入れ場らしき hideable/func.inc.php に認証 or DIE するメソッド定義、
アクセス制限したいコマンドサブクラスの do_url() で呼ぶ
平文をネットワークに垂れ流しつつも動くのでおｋ

html ソースが汚いのもうちょっとなんとかしてみるょ

<p> 内で改行いれてほしくない　→　htmlconverter.inc.php 内 visitT_Paragraph() で置換

wikiソースでの空行を出力htmlに反映してほしくない　→　同ファイル内 visitT_Body() で空行は $ret に push しないようにする

インデントレベルをテンプレートに合わせたい　→　Smarty の機能にあるっぽい {$html | indent: 4: ‘ ’}　とか

ふぅ
だいたい KinoWiki ソース全容を把握できた気がする
Singleton パターンかわいい

でもパース部とかをキャッシュ使ってスルーするようにしてもいまいちサクサクとはいかんのな
あー plugin とかを使う使わないに関わらずフォルダ構造から全部列挙して new するもよう
恐らくネックこれ cmd 15個、plugin 49 個とかあるし
どれか使おうとした時点で一度限り全体が初期化される恐るべき Singleton に管理されている

まあ速度犠牲にしても便利さ拡張性優先ってことだよ wiki だし
さすがにこれはしょうがないか 放置

調子乗ってキーワードツールチップっつーかポップアップっつーかをフルスクラッチすることにする
前までサーバサイドでパースから埋め込みまでやってたんだけどぶっちゃけクライアントにやってもらいたい
あとツールチップのために非同期通信とかもサーバかわいそすだから遠慮したい
js の中に単にキーワード内容入れといてロード完了時に DOM 操作でいいか
いやポップアップ内容も楽に弄れるべきだなあ
ツールチップもどきはその辺にサンプルあった jQuery 万歳これつかおう

やっぱせっかく wiki なシステムを使ってるんだから無理やり連携させてしまうことにする
ツールチップだすキーワードを定義するページを決めて、そこに定義リストで書いたものを json にして KinoWiki が js のソースを書き換えにいくという若干きもい連携ができた
html に js ファイルとして KinoWiki に独自コマンドリクエストなげる URL 書いて KinoWiki がページ読んでから js ソース動的生成、というのも考えたけど js のリクエスト時にまた重たい KinoWiki がよっこらしょと動くかと思うと嫌だったのでやめて、あくまでも js 自体は静的ファイルでってことでこうなった

まとめ
・対象キーワード情報はサーバサイドが js ソース内に静的な形で埋め込む
・ドキュメントにはツールチップ用の情報は何も含まない
・クライアントサイドで対象キーワード探してポップアップ内容を指す id を span つかって付与
・hover で js 内のデータ参照して表示

サーバサイドでキーワード用 id 付与しておいてクライアントサイドはその id を使って hover 時に非同期通信で内容取得っつーのがありがちな方法だけどそれを意地でもやりたくなかったっていう
なんでこの方針がマイナーかっていうと想像するにクライアント側に毎回キーワード探させる処理が普通にやると重いからだろ JK
キーワードの数が多くなってくるとキーワードひとつごとに順に頭から置換かけるとかいう頭の悪いアルゴリズムでは死ぬ気がする

ということでその問題はなんとかしたい
なんとかなってるのか？
まあとりあえずキーワード増やして測ってみてから。。。

キーワード数 100 少々たまったのでパフォーマンステスト。
letsnoteR5。ユーザの平均スペックくらいだと思うことにする

本文サイズ 50 KB、キーワード密度は並だと IE7 で 230ms。Fx3 だと 167ms
本文サイズは 15 KB、キーワードぎっしり 400 個くらいなページ IE7 164ms Fx3 107ms

キーワード数馬鹿みたいに増やさなければ今の実装のままでも使えなくもないかなと思えなくもないかなとも思わなくもない
でもキーワード無駄に入れて遊びたい そのためのツールチップ
なのでもうすこし頭よさそうな一度の走査で置換完了できるようなアルゴリズム考えて実装してみる　倍速くらいにはしたい

超苦労したけどなんかできた
きっとなんか名前がついてるアルゴリズムの劣化版なんだろうけど自力で考えたところに意義があると信じる

50KB 大容量ページ IE7 230ms -> 235ms Fx3 167ms -> 56ms
キーワードぎっしりページ IE7 164ms -> 280ms Fx3 107ms -> 53ms

IEかえって遅くなってやがるうううう
ハッシュアクセス多用とか書き方がネックになって愚直アルゴリズムの方が逆に速いという IE クオリティなんていうチャチなもんじゃ断じてねえものを垣間見た
でも Fx3 とか Safari とか Chrome とかオブジェクト操作が速いモダンな感じのブラウザでは目標であった倍くらい速くなった上に本文サイズ増加しても前ほど計算量増えなくなったので長文が書けて幸せ
なんか知らんが Opera はIE 並に遅い なんでかなー

満足できないのでアルゴリズムはそのままで、色んな builtin 関数のベンチを取りまくりながら鬼リファクタリングに GO

の結果
大容量ページ
IE7 (230ms ->) 235ms -> 130ms
Fx3 (167ms ->) 56ms -> 26ms

キーワードぎっしりページ
IE7 (164ms ->) 280ms -> 163ms
Fx3 (107ms ->) 53ms -> 23ms

これなら IE でもなんとか改良といえるんじゃね！（微妙）
しかしリファクタリング前にひどかった Opera も含め Fx とか Chrome とか Safari とかは爆速化したな （20msちょい）
これで IE 以外は置換対象キーワード数百個突っ込んでも数十msに収まる　IE を除けば目標はオーバーアチーブしたといえよう
IE の人はその重さを痛感すればいいとおもうよ！

しかし後半はアルゴリズムじゃなくて各ブラウザの js 実装と戦って内部でのメモリ管理こうなってるんじゃねとか地味なこと考えながら手動最適化してただけなので割と不毛というか得るもののない努力　しかしそれが僕には楽しかったから

まあどいつもこいつもまだプロパティアクセス控えるようにするだけでかなり速くなるぜーとかそういう残念な感じなので今後はなんも考えなくても JIT とかで最適化してくれるようになるといいね
なる予定はあるらしいね あと一年もすればマシになってるか

まあおなかいっぱいになった
午後を費やしましたみたいな雰囲気で書いてるけどキーワードポップだけで三日くらいやってるからねこれ
仕事じゃあるまいしありえない

wiki いじり残りやる
メニュー部に単体ページ割り当て。やった
css いろいろ。やった
<kbd>タグ生成 KinoWiki プラグイン書いた。 <kbd>Ctrl+A Del H O G E</kbd> とか楽して書くとちゃんとそれぞれ <kbd> で括ってくれるというどうでもいいプラグイン
本体弄りまくった後にプラグインとか書くとすごく楽で見通しも利いてて幸せな気分になれる　デフォで入ってる del プラグインを参考にしたとはいえ 1 分で書いてこういう拡張が適用できるのはいい
おまけで html ソースそのまま出力するプラグインも書いた こちらはコピペに 10 秒，ソース書くのに 5 秒ですね
うむ これが Wiki の真価

でコンテンツ移植
ぼちぼちやったがまだ終わらないっていうか日記ログとか手ではやるきしねー気が向いたら俺手打ち html to KinoWiki 逆コンバータ書いてやらせるかいやそんなんいらんでも正規表現がんばれば半自動くらいはなんとかなるけどどのみち人間が見直さなくちゃいけないよね

コンテンツはともかく CMS 的な何かとしてはほぼ完成
旧 dvorak.jp バックアップ後に新システムに置き換え

ok まあ動くしいいんじゃない
きっと使い出すとまた色々思うことあるだろうけどそれはまた随時やればいいのさ
って言ってるとやらないんだけどね、往々にして

残りやりたい気はあったけどまだやってないこと、いつかやる気がでたとき用メモ

• 多段ツールチップとかツールチップ内リンク（ツールチップ部そのものは拾ってきたものつかってるんでその改良）
• キーワードクリックでキーワードページ該当部に飛ぶ（なぜかやってない）
• KinoWiki 管理外の画像の簡単な埋め込み記法（デフォであるだろとおもったらないっぽいの。別に html 直にかけばいいけどさ）
• エディット環境をもうちょい便利に
• 簡易コメントフォームとかいかにも Wiki 的な何かを試す（本体いじりまくってて動くか不安だったので使ってみてない）
• アクセス統計（google analytics はるお）

うーん、感想というかひととおりやってのひとこととしては、
KinoWiki を元にしたのはあんまり正解ではなかったかな、という
なんつーか玄人ぶりたい人向けのものではないって雰囲気だった 使ってほしい層が
KinoWiki らしい機能ほとんどうぜーとかいって無効化してるし作者様に申し訳がたたない感じ

でもまあソース綺麗でどこでなにやってるかとかわかりやすいのは確かだった
php のソース読んでもねぇ、とか思ってたけどそうでもなかった なんかのデザインパターンがっちりって感じで
うーん他人の書いたコード読みまくるような習慣つけないとね
あとツールチップとかいうどうでもいいことに時間使いすぎ でも楽しかった

そして冬休みが終わった

1. 配列屋とか IM オタク相手じゃ需要ないんで，普通のゲーム向け需要に迎合． [↩]

Trackback URL

コメント (2) to dvorak.jp システム変更完了

コメントをどうぞ