ダウンロード出来ない。2012-10-27(Sat)18:09:45アップロードしなおしておきました。2012-10-27(Sat)18:38:03ありがとうございます。ダウンロードできました。index.phpの37行コメントアウト忘れているような気がします。2012-10-27(Sat)21:38:10すみません!中国語版のWebサイトはhttp://weiji.meyito.com/に変更されました。ご清聴ありがとうございました!私は中国語の翻訳に貢献して頑張りたいと思います。2012-11-04(Sun)14:21:52ありがとうございます。利用者が増えるとフィードバックが多くなり開発の参考になるため助かります。2012-11-05(Mon)02:25:59wikiに共通してあって欲しいんですけれど。ページ単位にデータを保持する為の領域を持ってはいけないもんなんでしょうか。プラグインも記事内からマッチさせて探し、書き換えみたいな徒労が多く。膨大なデータになるとmatch自体が速度のボトルネックになって来ますよね。プラグインも作りにくい・メンテしにくい・カスタマイズしにくい。プラグイン次第でwiki以外の形式(例えばBlog形式やBBS形式)も実装し易く、応用も多く出来ると思うんです。実装としてDBを実際に使うか、それともwikiページデータに内包するかはどっちでもいいと思いますが。編集側についてはwikiのコンセプトどおり上部タブの「編集|凍結|差分|~」の序列からそのデータ自体を編集者が書きかえれる事も出来たほうが良い(場合によってはデータ部分のみの凍結とかも)。製作的には、記事内で#plugin_hoge('keyName');のような形式で設置させて。プラグイン内でその情報をハッシュにでもして渡してくれれば記事を作って返すだけ。後はwikiが#plugin_hogeを表示上置き換えれば適用も問題ないと踏んでいるんですけど。2012-12-27(Thu)06:18:14ついでに。送信時にえらい重い環境だからか、二重送信をついしてしまいがちです。これは環境依存の問題ではありますが、UIの観点から防止すべきと思います。「変更をサーバーに反映しますか?」と聞くぐらいなら、送信中を明示させる程度の対応がWeb2.0的ではないでしょうか。2012-12-27(Thu)07:47:56一応、二重送信を禁止するシステムは備わっています。他にも送信ボタンを押したあと、送信ボタンを無効化するってことも考えていましたが、不具合が多かったので見送ってますが。ソースを見る限り、重たい処理はアンチスパム関係ですね。ページ内の追加されたURLをチェックする処理とか重いようです。このへんは、設定内容をキャッシュ化したり、ロジックを変える方向で考えています。2012-12-27(Thu)12:47:07ええ。マッチさせてrequireで読み込む形式なので、確かにボトルネックが多いと感じていました。今回autoloadを用いた実装1に変えている理由がまさにそれです。必要となったタイミングで読み込まれるためその分ボトルネックが減ると考えています。顕著な例ですと、そのBugTrack。これはリストを作るときイチイチ記事を読んできて、内容をマッチさせて値を拾ってくるもんだから、100件を超える内容を抱えると、恐ろしいぐらいリソースを食う。なんというか構造的に超不毛ですよね。どこかにインデックスをファイル出力するか、隠しページにでも書きこんどきゃいいか、って方法に(自分の低脳では)なるんですが。これも根本的解決には程遠いというか美しくないんですよね。事、『記事単位でDBライクな領域を持っとけばいいんじゃないの?』ってのが個人的見解なんです。