一昨日実装した、 複数のキーワード集合による、AutomaticLinkモジュールを WiKicker CGI プログラムから使えるようにしてみた。
ローカルにおいておいたキーワードリストファイルを読み込み AutomaticLink 処理(WikiForum 内で AutomaticLink でマッチしていない部分文字列に対して)。 マッチした場合は InterWiki を使ってURIに変換しリンク化する。
あわせてIndexPage.txtでWiKicker WikiForum 内の PageName を取得できるようにした。
これで例えば、2つの WiKicker WikiForum が cron で互いの IndexPage.txt を定期的に取得し、AutomaticLink するようにすれば、相補的に連携する事ができるようになる(ただし AutomaticLink のみ。WikiName や BracketName は依然としてその WikiForum 内のみ)。
AutomaticLink でのリンク先は(指定した)任意の InterWiki で定義できるので、あるキーワード集合について Google の検索結果ページや「はてなダイアリーキーワード」への自動リンクも実現可能(はてなダイアリーキーワード自動リンクAPIはキーワードリストではなく正規表現を返してくるので、元に戻す必要有り。またあれだけ巨大なキーワードリストだと毎回 AutomaticLink のために、trie 再生成するのも辛いのでもう一工夫必要)。
Windows で「最後がピリオド(.)で終わるファイル名」を新規作成する。 最後のピリオド(ドット)が無くなる。
……。
8.3形式の名残なのか? Explorer 上で作成しても、プログラム(Perlスクリプト)から作成しても駄目。
環境は Windows XP Home Edition SP2 + NTFS。 Windows 2000 + NTFS でも同様。
これは WiKicker のテストをしていて気がついた。 WiKicker では「PageName の base64 を生成し 『/』 を 『.』 で置き換えたもの」をファイル名にしている。 例えば UTF-8 で「タ」は
44K/
となるので、ファイル名は 「44K.」となる。 で最後の文字が消えてしまうので、デコードするとおかしくなると。
これを機会に Windows 環境でのエンコーディングは RFC3548 「4. Base 64 Encoding with URL and Filename Safe Alphabet」を使うように変更するか。
本当は全てこれに変更したいのだけれど、すでに動いている WikiForum の事を考えると移行は難しいかも。
WiKicker では、直接 WikiPage に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-8、UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。
ということで、これを採用することに。
どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。
相変わらず www.naney.org 上の WikiForum (NaneyOrgWiki) にも毎日のようにリンク spam 書き込みがある。
気がつき次第削除と、その URL や関連キーワードの書き込み禁止文字列ブラックリストへの登録を行っているが、手間でしょうがない。
これらのリンク先に貢献するのは腹立たしいのでリンク (A 要素)へ
rel="follow"
属性をデフォルトで設定するように WiKicker を書き換えた。 ようやく。
あわせて、検索エンジン対応もしていおくことにした。
編集ページや履歴ページは検索エンジンに登録してもしょうがないので、インデックスから除外されるように HTML の HEAD に
<meta name="robots" content="noindex,nofollow">
を追加するように修正。
クエリ付きの URL のページで noindex した場合、クエリ無しや他のクエリを持つ URL のページまで一緒にインデックスから外されてしまわないかちょっと心配で、今まで保留にしていたのだけれど、Wikipedia などを見ても大丈夫のようだ。
[ SEO ]
2002年10月19日から開発を始めてしばらく公開・運用をしていた WikiEngine だけれど最近は WikiEngine そのものは使っていなくて、今はそのコードをベースに作った日記システム の DiKicker 部分しか使っていない。DiKicker の方は自分自身で今後も使っていくんだけれど、さすがにいろいろ古いのでそろそろ大改修しようかなと。基盤部分的には
などをして今後も使っていけるようにしたい。既に使っていないアプリケーションとしての WikiEngine 部分は移行させていく手間をかける必要はないと思うので、コードを削除していくことにした。WikiForum 立てるなら既にいろいろ他の選択肢があるしね。
CVS での管理もやめて Git 管理に変更。最後の公開 tarball を展開して git init して最初のコミットとし、その後に変更した作業ディレクトリを Git 側の作業ツリーに上乗せしていったんコミット。あらためて最後の公開コードの上に差分を積んでいくつもり。
先週の金曜日からテキストファイル todo.txt でタスク管理をするアプリを試してみています。
1行に1タスクを書くシンプルな todo.txt フォーマットが定義されており、それら対応した Todo.txt CLI やスマートフォン向けアプリ、デスクトップアプリ、エディタのプラグインなどがいろいろ作られています。
これらを使ってタスクを追加・編集していきます。もちろんテキストエディタで簡単に追加・編集できます。Dropbox を使うことで複数のデバイスでも問題なく運用できます。
まずは以下のアプリは使うことにしました。
仕様上サブタスクという概念はありません。「+プロジェクト名」という記法でタスクをタグ付けできるのですが、これだけだと見にくいので
# プロジェクト名 h:1 (A) タスク1 +project1 @office (B) タスク2 +project1 @home
のように書いてみています。「h:数字」は hidden を表す key:value で、各アプリはこれが書かれたタスク(行)を隠すことができます。一方 Markdown 対応テキストエディタで見出し扱いにしてくれるので視認性が良くなります。
コンテキスト(@文字列)やプロジェクト(+文字列)をタスク文中に埋め込める点、そしてそれらが空白は許さないことから WikiForum に書き込んでいるような感じがしました。
いわゆる開始日指定にあたる threshold や繰り返しのための rec などが指定できるため一通りのことはできそうです。 Remember The Milk から一部タスクを移して運用してみます。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。