nDiki : WikiPage

2004年6月10日 (木)

[ WiKicker ] Acceptor とか ロックとか

HTMLレンダリングなどは WikiPage の構文木に対する Visitor パターンで行っている。

かなりの回数呼ばれるダブルディスパッチ部分、現在は accept の中で 'visit_クラス名' を呼ぶようにしている。 Acceptor クラスの accept メソッドでインスタンスのクラス名を取得してディスパッチしているのだがもったいない。

各サブクラスで明示的に accept をオーバライドするのが面倒なのでそうしていたのだが、今回は Acceptor モジュールを use した時にそのパッケージに accept 定義を作ってしまうように修正してみた。

ロックの方

アクセスが連続的にある時はDBに対して共有ロックがかかり続けるため、書き込みのための排他ロックがなかなか取得できない。 現在はDB全体でロックしているのだが、そろそろ「ページ名リスト」と「各ページ」を別にロックするようにした方がいいかもしれない。

スポンサード リンク
[ 6月10日全て ]

2004年8月17日 (火)

Linux Feed Reader Liferea

RSS巡回用に入れてみる。

とりあえず NaneyOrgWikiはてなアンテナRSSを登録。 これだけだとあまり良さがわからないな。 記事自体がRSSに含まれていれば、それなりに面白いのかもしれないが。

WiKicker では description に WikiPage 上部の数行を概要として出力しているのだが、ここはページの変更部分をのせた方が良いのかもしれない。

[ 8月17日全て ]

2005年2月11日 (金)

WiKickerFlickr 関連機能追加

WiKicker / DiKickerFlickr 上の画像ファイルを貼れるように WRN scheme を追加。 Flickr では

 画像ファイルURL:
    http://photos番号.flickr.com/画像ID_文字列(_サイズ).jpg
 画像ページURL:
   http://www.flickr.com/photos/アカウントエイリアス/画像ID/

となるようだ。画像サーバ名と文字列部分の割り当ては推測できないので、画像ファイルURLは直接指定する他ないか。 後はアカウントエイリアスを指定すれば2つのURLが生成できる。 幸いアカウントエイリアスは : を含まない ([a-zA-Z0-9_-]+?)。

以上から WikiPage の中では

  [[flickr:アカウントエイリアス:画像ファイルURL]]

のように指定できるようしてみた。 www.flickr.com はレスポンスが悪いのだが画像サーバ自体のレスポンスは良いようで、試しに nDiki に貼ってみたが特に問題はないようだ。

画像からのリンク

WiKicker では YukiWiki を真似て WikiPage に貼ったインライン画像はその画像URLにリンクするようにしていたのだが、今回やめることにした。

Flickr や ASIN リンクのようにリンク先が決定できる時のみリンクにするようにする。 以前から、バナーを貼る時などのために「画像URLとリンク先URLの両方」を指定できるようにしたいのだが、いい記法が思い浮かばないのでいままでずっと実装しないままになっている。 何かうまいWRIを考えたい。

[ 2月11日全て ]

2005年4月10日 (日)

Windows 上での Apache 2.0.53 では PATH_INFOシフト JIS

WiKickerWindows 上での動作確認の続き。 WiKickerPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。

既に手元で PPM パッケージ化済みなので、これもインストールしておく。

後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。

 TZ=JST-9

CGI プログラムとして実行。 お、表示できた。 書き込みはと。

エラー

予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。

これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。

PATH_INFOシフト JIS で渡される

WiKicker では UTF-8 文字列をURIエスケープして WikiPageURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。

Windowsファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。

将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。

現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。

対策案:

  • Apache 1.x 系を使う (まだ未確認だが、こちらだと勝手に変換されないらしい)
  • WiKickerPATH_INFO を使わないオプションをつける(URI Query Component は勝手に変換されない)
  • WiKicker 側でシフト JIS から UTF-8 に変換する
[ 4月10日全て ]

2005年6月6日 (月)

[ WiKicker ] Storable 永続化データの互換性

fkimura 氏から WiKicker の障害レポートをいただいた。 Perl 5.8.6 へ移行した環境で WiKicker 0.26 を試してみたところエラーになってしまうとのこと。

 "Error
 action: do_read: Byte order is not compatible at blib/lib/Storable.pm
 (autosplit into blib/lib/auto/Storable/thaw.al) line 366,
 at /usr/local/lib/perl5/site_perl/5.8.6/WiKicker/DB/File.pm line 161
 at /usr/local/lib/perl5/site_perl/5.8.6/WiKicker/CGI/AbstractController.pm line 93"

(FreeBSD 4.11-RELEASE-p9)

Storableエラーを吐いている。 Storable データ形式に互換性のない環境 (Perl and/or Storable) 変化があったようだ。

例えば Storableマニュアルによれば 64bit integer をサポートするように構築された Perl 5.6.0 や 5.6.1 で Storable 2.02 以前を使って書き出したデータを他の環境で読み出すと 'Byte order is not compatible' エラーが出るとある。

確認したところ前のバージョンは Perl 5.6.2 だそうなので、もしかしたら上記の非互換性にあたってしまったのかもしれない (FreeBSDPerl って 64bit integer サポートでビルドされるようになっている?)。

WiKicker での対応方法

WiKicker で使用している Perlアップグレードで上記問題にあたった場合、一番簡単な方法は Storable で書き出しているページ情報ファイルを一旦全部消してしまうという方法。

WiKickerデータベースディレクトリ (wikicker.database.directory プロパティで指定しているディレクトリ)の下の、info/basic/* を全て消してしまう(一応バックアップとしてコピーした方が良い)。

この場合、各ページの「最終更新時刻、最終更新者名、要約文」が消えてしまうが、これらの消えてしまった情報は次にページを更新した時に最新の情報で上書きされる。

WikiPage そのものおよび古いリビジョンは影響がなく全て残っているので、通常の運用ではまあ許容できる範囲の対処方法か。

情報ファイルを消したくない場合は、コンバートする必要があるけれど古い Storable データを読み出せる環境で export して、新しい形式で書き直す必要があるので作業する人にとってもちょっと面倒かもしれない。いや、新しい Storable ならば $Storable::interwork_56_64bit あたりを使えば両方をきりかえて読めそうであるので、新しい環境だけあればいいのかな。

[ 6月6日全て ]

2005年9月13日 (火)

[ WiKicker ] hell mode - HTMLタグ付けブロックの導入

WiKicker では、直接 WikiPageHTMLタグを記述して表示に反映させる機能を提供していない。

HTMLタグ付けを許すのは嫌だ

HTMLタグ付けを許すと

  • 入力ミスによるトラブル
  • 悪意ある入力によるトラブル

が起きやすくなるし、ページのソースの単純さが大きく失われてしまう。 レンダリングしてHTMLにした時に、正しいHTMLを出力されることを保証することが困難になるとともに、HTML以外へのレンダリング/コンバートもかなり難しくなる。

この機能を導入すると、Wiki の良さの半分(あるいはもうちょっと沢山か、もうちょっと少なめ)が失われてしまう。

でも

とはいえ欲しいという声があることも事実。 オープンな WikiForum では全くお勧めできないが、閉じたユーザグループの中ではまぁ必要悪なのかもしれぬ。

また正直ちょっとした表現を追加したい時に、WiKicker 用のプラグインを書くのも面倒だというのは確かにある。

WiKicker では開始・終了マーカによる複数行にまたがるブロックを表すための文法は(閉じ忘れを避けるため)意図的に排除してある。 このため、複数行にわけて書きたいような長いデータを扱うような拡張も導入しにくい。

ちょっと手抜きして「生HTML書けちゃえば」という誘惑はなくはない。

大人の事情

ということでまあ自分に言い訳をしつつ、標準ではオフというかたちで HTMLタグ付けブロックを導入することにした。 スイッチは hell mode とかにしたい (今回は syntax.html というプロパティ名にしたけれど)。

記法は単純に、

 normal wiki syntax text...
 <html>
 html tagged text...
 ...
 </html>
 normal wiki syntax text...

のように行頭が <html> である行から、行頭が </html>である行までをHTMLタグ付けブロックとすることに。 このため、<html>ではじまる段落が書けなくなるという小さな非互換が発生するが、いたしかたない。

サニタイズ

HTMLタグを直接使えるようにするとはいえ、全てを許してしまうのはあまりに危険で非人道的すぎる。 有効なHTMLタグや属性は限定的であるべきだ。

このあたりの処理は面倒だが、幸いにしてCPANにモジュールがある。 今回は HTML::Scrubber を使うことにした。 HTML::Parserを使って parse し、指定したルールに従ってサニタイズしてくれる。

ちょっと使ってみた範囲では日本語(UTF-8UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。

ということで、これを採用することに。

どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。

[ WiKicker ] destination anchor を打てるように

WiKicker には終点アンカー(HTML だと name and/or id属性付きA要素)をページ中に書く機能がない。

  • 直観的ではない。この機能を知らない人が WikiPage を編集しようしたときに、ソーステキスト中にこれがあるのはよろしくない。HTMLを知っている人なら問題ないかもしれないが、そうでない人にはわかりにくい。
  • アンカー名の一意性の保証が面倒
  • 終点アンカーを書いて、他からご丁寧にリンクしても Wiki の正確上誰かが編集してすぐ無くなっちゃうかもしれない (そういってしまえばページそのものもそうであるが)。

等の(自分なりの)正当な理由で追加していなかったのだが、まぁ必要になったのであっさり追加することにした。 アンカーテキストに WiKicker のインライン要素を書けるようにするかどうか迷ったが、HTMLでレンダリングする際にA要素のネストを避けたりするのが大変なので書けない仕様にすることにした。

 [[anchor:anchor_name]]
 or
 [[anchor:anchor_name][anchor_text]]

という表記 (WRN scheme)を追加。 アンカー名の一意性の保証はまだ未実装。 やっぱやらんといかんかな。

[ 9月13日全て ]

2005年9月22日 (木)

skkinput がよく落ちるので uim-skk に乗り換え

メインのノート PC (Debian GNU/Linux sid)では XIMサーバとして skkinput を使っているのだが Firefox で入力をしていると、Firefox を道連れによく落ちてしまう。 何かの登録のためにフォーム入力していたり、WikiPage の編集をしているときに落ちてしまうとかなり辛い。

ということで遅ればせながら uim を試してみることにした。

インストール

ほぼ「Japanese - Debian GNU/Linux スレッドテンプレ」の通りに設定。

SKK用の辞書などは既にはいっているので

 apt-get install uim uim-skk

として uim 関連のファイルをインストール

~/.xinitrc の skkinput 関連の部分をコメントアウトして、

 if type uim-xim &> /dev/null ; then
   uim-xim &
 fi
 XMODIFIERS=@im=uim ; export XMODIFIERS
 GTK_IM_MODULE=uim ; export GTK_IM_MODULE
 UIM_IM_ENGINE=skk ; export UIM_IM_ENGINE

を追記。

これで Firefox でも問題なく uim-skk日本語入力ができた。

ツールバー

Window Manager 用システムトレイとして docker を使っているので、uim-toolbar-gtk-systray を使う。

 uim-toolbar-gtk-systray &

Emacs 用に設定を変更

初期状態だと C-j でも uim-skk がオンになる。 これだと Emacs を使っている時によろしくない。

uim-skk の方は Shift-space でトグルすればよいので、uim-pref-gtk 上の 「SKKキー設定1」の「モード遷移 - [SKK]オン」から Control-j を外しておいた。

追記

Java アプリケーションでの入力。

J2SE (1.5.0_04) 上で日本語入力ができないのに気がつく。

~/.Xdefaults に

 *inputMethod: uim

を追加して入力できるように対応 (2005年9月24日追記)

[ 9月22日全て ]

2006年4月21日 (金)

第1回 社内 Perl 勉強会

この間教材として選定した「初めてのPerl 第3版」を使って第1回目の社内 Perl 勉強会を実施した。

プログラミングのクラスなんて大学(および TA)以来なので、進め方は手探りである。 まずは以下の様にしてみた。

目的

Perl プログラミング、および一般的なプログラミング・開発のスキルアップを目指す。

進め方

  • 私が進行役。
  • 自由参加 (私の指定プロジェクトメンバは必須)。プログラマでも、コンテンツデザイナーでも。
  • 書籍「初めての Perl 第3版」を教材とする。
    • 本は社内に1冊ある。ケンカしないでうまく回して読むように。
  • 1週間に1章ずつ進める (最初の回は1・2章)。
  • 各自事前に独習すること。業務の支障にならない範囲でうまく進めること。
  • 章末の練習問題を課題とし、勉強会の前に解答を作成してみること (書籍末に回答があるが見ないようにすること)。
  • 独習の上でわからない点は適宜、誰かに質問してできるだけ解決をはかること。

勉強会

  • 毎週金曜日に勉強会を 16:00 - 17:00 で開催。
  • 練習問題の解答ピアレビューを中心に行う。その場で本読みはしない。
  • 課題がプログラムの場合は、プリントアウトして持参すること (あまりに長い場合はのぞく)。
  • 参加希望者は事前に 社内 WikiPage に、参加意思を表明すること。
  • 練習問題別に、チェック項目や補足情報を追加した資料を開始時に配付。

実施

第1回は私を含めて6人による勉強会となった。

プログラミングを学ぶのはやはり実践が一番であるので、事前に練習問題に取り組むというスタイルにしてみた。勉強会では他人のコードを見たり意見交換したりすることで理解を深め新しい発見ができればと考えている。

皆それぞれの業務を抱えているので、忙がしい人については事前の課題取り組みについては厳しのではとの不安もあったが、初級者・中級者にかかわらず全員準備してきていた。 びっくりするとともに嬉しかった。 参加者は皆それぞれチャレンジ心を持ち、何かを得ようとという熱意があるようで素晴しい限りである。

今回は練習問題も簡単だということもあり、全員解答できたようである。 今回気がついた点:

  • プログラムのプリントアウトについては以下のようにするのが望ましい。
    • プログラム毎にプリントアウトを分ける (1枚に複数のプログラムを掲載しているとレビューしにくい)。
    • フォントは適度な大きさで (小さいと見づらい)。
    • 今後プログラムが長くなってきた時のために、行番号を入れるのが望ましい。
    • 可能ならばプリティプリンティグを (皆にツールを紹介する必要あり)。
    • 今回は皆1セットづつしかプリントアウトしてこなかったが、これだと皆でレビューしにくい。人数分プリントアウトしてしまった方が効果的ではないだろうか。他人のプログラムで興味深いものは持ち帰りたいし。その場合はプログラムの先頭にコメントで問題番号と作成者を書いてもらうのが良いだろう。
  • そういえば書籍末の正解の確認をしなかった。今後問題が難しくなってきたら確認した方がいいかもしれない。
  • 教材の本は予算で買った1冊とスタッフ私物の1冊で現在2冊。ちょっと足りないかな。もう1冊ぐらいあった方が良いかもしれない。

1時間の予定であったが10分オーバーで70分。 時間的にはこれぐらいか。90分ぐらいあった方がいいのかもしれないけれど、業務とのかねあいもあるし。

本社

そういえば今回は東京オフィスで希望者向けのものだったので特に本社には連絡しなかったんだけれど、1名ここ(nDiki)の記事を見て羨しがっていたらしい。

リモートでの参加までは考えていなかったので今回は準備できなかったけれど、希望があるならなんか方法を考えていきたい。

また来週

さて、本格的にプログラミングっぽくなってくる次回からが楽しみである。 目指せ総 Perl プログラマ化。

[ 4月21日全て ]

2006年4月29日 (土)

WikiPage 編集画面で Ctrl+S を押すとプレビューするようにしてみる

「ついつい保存しようとして Ctrl+S を押して Web ブラウザの保存ダイアログを開いてしまうんだよね。Ctrl+S で (WikiPage を)保存してくれると嬉しいんだけれど。」

WiKicker を使用している同僚からのアイデア。 自分にとって C-s は Incremental search forward (`isearch-forward') であって保存ではないので、あまり関係ないといえばないんだけれど、その気持ちは良くわかる (C-p で 印刷ダイアログが開くのうざい)ので、試しに実装してみることにした。

ただしいきなり Ctrl+S で保存はちょっとデンジェラスなので、プレビュー画面に移動するようにしてみる。

例によって Web ページ上の JavaScript におけるイベント処理は、Web ブラウザ依存バリバリなのね。 テストが面倒(自分でできない/自動化困難)なので、できるだけ近付きたくはないのだけれども。

とりあえず、Firefox 1.5.0.2 on Debian GNU/Linux と、Internet Explorer 6 on Windows 2000 では動くことを確認するところまできた。

喜べ松下君。

[ 4月29日全て ]

2006年5月22日 (月)

WiKicker 0.30 リリース - トップページのページ名を変更できるようにするなどの機能追加

2006年2月13日以来、3カ月ぶりのリリース。

  • コメント書き込みでも書き込み禁止パターンが適用されるように改良。
  • WikiPage 編集画面で Ctrl+S を押すとプレビューするように改良。
  • WiKicker の トップページのページ名を変更できるように改良 (toppage.pagename プロパティ)。
  • トピックパス表示で常にトップページを先頭に表示するオプション (topicpath.showtop プロパティ) を追加。
  • エラー時の HTTP レスポンスコードを 503 にした。
  • テストスクリプトの改善。

セッション管理/認証/承認機能のコードを書きはじめてパッケージには含まれているけれど、まだ完成していないので有効になるようにはなっていない (あ、ちょっと中途半端になっているかも)。

[ 5月22日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.06066s / load averages: 0.72, 0.64, 0.69
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker