nDiki : YukiWiki

YukiWiki

結城浩氏が開発されている、Perl で記述された WikiEngine。 国内で開発された多くの WikiEngine に影響を与えた。

www.naney.org でも、当初 NaneyOrgWiki のエンジンとして YukiWIki 2.0.5 を修正して使用していた(現在は WiKicker に移行)。

YukiWiki をベースにした WikiEngine

スポンサード リンク

2002年3月6日 (水)

[ www.naney.org ] 14:00 YukiWiki日本語 WikiName

一昨日YukiWikiWiki をたちあげてみた。

なかなか面白い。 YukiWiki だと日本語 WikiName は [[なまえ]] のように '[['、 ']]' で囲む。 編集する時にはわかりやすいけど、表示される時はちょっと見にくいかな。 ということで、文中に表示される日本語 WikiName は括弧を外すようにしてみた。 この程度なら、編集する人もとまどわないでしょ。

[ 3月6日全て ]

2002年8月27日 (火)

[ www.naney.org ] YukiWiki 2.0.5 追従

NaneyOrgWikiYukiWiki 2.0.4 -> 2.0.5 の差分を適用。

[ 8月27日全て ]

2002年10月19日 (土)

WikiEngine 開発開始

YukiWiki2 をベースにちょこちょこいじってきた NaneyOrgWiki であるが、コードもこみいってきた。そろそろ、フルスクラッチしたくなってくる季節。

ということで、さっそくコーディング開始。 名前は WiKicker研究社の新和英大辞典をめくりつつ、

  • WikiName になり、
  • 'Wiki'、またはそれに準ずる名前で、
  • 既出でないもの。

kicker はいわゆる、「蹴る人」という意味以外に、

  • 批判家
  • 船外機 (WikiEngine と エンジンつながり)
  • 刺激を与えるもの (Wiki って刺激的?)
  • 以外な難点、思わぬ何問題

なんていうのもあって、まそれなりによさそげだし。 Kicker ならアイコンを作ろうと思った時に抽象的でないから作りやすそうというのもメリット。 地肌に優しい。 ただし手がまだ覚えていないのでつい、WiKicler とミスタイプしてします。

WiKicker への移行の主なポイントは、

あたり。

[ 10月19日全て ]

2003年4月22日 (火)

[ WiKicker ] リビジョンが追加されていかない

あれ、NaneyOrgWiki のリビジョン管理(RCS)がうまくいってないみたい。 リビジョン番号があがっていくページもあれば、そうでないページもある。 Why?

で確認してみると、RCS の lock まわりの問題。 CGI プログラム経由の ci/co を呼び出しはユーザ名 root でロックをかけようとするのか。 suEXEC で作成されているファイルの権限は naney になっているので、locker も当然 naney になっていると思ったのだけれど、勘違い。 このため、

  • WiKicker に移行した後、新規作成されたページ → CGI プログラム経由で root による lock 獲得が成功しリビジョンが上がっていく。
  • ユーザ naney で import ツールを使って YukiWiki2 からコンバートしたものは、naney によって lock がかかっているので、CGI プログラムからは lock が獲得できず check-in できない。

という事になっているようだ。 とりあえず naney で

 rcs -U RCS/*

して、non-strict モードに。 これで、どのページもリビジョン管理できるようになったはず。 しかし、現状だと

  • import したもの non-strict mode / locked by naney
  • 今日まで新規作成されたもの non-strict mode / locked by root
  • 今日以降新規作成されるもの strict mode / locked by root

となり気持ち悪いなぁ。 今は、常に lock 状態になるようにしているんだけれど、non-strict mode + 非 lock 状態というふうになるようにすべきかも。

[ 4月22日全て ]

2003年4月23日 (水)

[ WiKicker ] (続)リビジョンが追加されていかない

昨日修正したつもりだったがまだ駄目だった。 モードを変更するだけではなくて、 naney 権限で

 rcs -u -M RCS/*

して実際に unlock しておかないと駄目だった。

今回の敗因はCGI プログラムからのアクセスと同じ条件で YukiWiki2 のデータを import しなかった事。

[ 4月23日全て ]

2004年2月10日 (火)

Wiki文法の標準化

今まで触れなかったが、やはり文法拡張する際は気になる存在。

各方面で出ている賛否どちらの意見もうなずける点が多く、自分の思いつく点もだいたいどこかで語られている感じ。

私が最初に Wiki の存在を知ったのは、やまだ君からだった。 当然「記法(文法)は?」というのがまず気になった点だったが、その時すでに「Wiki文法WikiEngine毎に異なる」という事だった。

WiKicker という新しい WikiEngine を作る際には、もちろん各 Wiki文法を調べたのだが、それはもう様々で。 「見出し」記号など単純に流派的なものと、ブロックプラグインなど設計思想に依存するものがあって、特に後者はどれかを統一して選択するのは難しいと感じた。

WiKicker では(もともと利用していた) YukiWiki2 に emacs-wiki の [[A][B]] を加え、その他の文法要素と表記は、

  • 見やすさ
  • メジャー度
  • WiKicker のベースの文法と衝突しない
  • 行指向を採用(行を越えた、開始・終了を利用者が明記しないで済むように)
  • 構文解析しやすい (実装の容易性は、高速化・独自ツール作成時に重要)

あたりをポイントに決めた。

将来標準(ができたとして)に準拠する?

多分しないな。 面倒だし。

[ 2月10日全て ]

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日全て ]

About Me

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

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

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

follow us in feedly

月別インデックス
Process Time: 0.12431s / load averages: 2.02, 0.88, 0.55
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker