■ [Hiki][tDiary]プラグインに埋め込まれた表示文字列の言語を選択可能に

昨日の話をちょっと考えてみたのだが、以下のような案はどうだろう。

実は、この考え方自体はtDiary本体が採用しているので新しくはないのだが、プラグインには使われていないので、これを機会にtDiaryプラグインでもこのルールが適用されれば良いなとはちょっと思う...が自分で作ったプラグインを適用させるのはちょっとめんどくさいか(^^;)。

＃すでに切り出されているプラグインがあるとのこと。知らんかった＜アホ

■ 試しに、Hiki-0.5系添付のreferer.rbのshow_refererというメソッドを例に考えてみる。

def show_referer(db)
  s = '<div class="referer">このページへのリンク元<ul>'
 
  referers(db).each do |ref|
    disp = replace_url(ref[0].unescape).escapeHTML
     s << %!<li>#{ref[1]} <a href="#{ref[0]}">#{disp}</a>!
  end
 
  s << '</ul></div>'
end

■ で、これだと思いっきり日本語が埋め込まれてしまっているので英語サイトでは使えない。

■ そこで、表示文字列のみを別メソッドに括りだすというプラグインコーディング上のルールを作る。

def show_referer_label
  'このページへのリンク元'
end
 
def show_referer(db)
  s = '<div class="referer">#{show_referer_label}<ul>'
 
  referers(db).each do |ref|
    disp = replace_url(ref[0].unescape).escapeHTML
     s << %!<li>#{ref[1]} <a href="#{ref[0]}">#{disp}</a>!
  end
 
  s << '</ul></div>'
end

■ 英語で使いたい人は、以下のようなプラグインを別途用意する。例えば、referer_en.rbとでもしてpluginディレクトリに置けば、表示時にはこちらが使われることになる。

def show_referer_label
  'Referrer'
end

■ このreferer_en.rbをプラグイン提供者が用意するのがベストだが、少なくともこの仕組みに準じるように作っておけば、ユーザ自身が作ることもできなくはない。 きたさんの指摘のような場合は仕掛けだけ仕込んで、あとはユーザに任せてしまえば良い...とすればプラグイン作者も少しは気が楽になる...かな。

幸い、このような文字列は１つのプラグインにそれほど数があるモノでもないので対応するのはそれほど大変ではないだろう。

それに、バージョンアップの度にプラグイン自体を書き換えたりする必要がないのは非常に助かる。もちろん、バージョンアップの際に元になる文字列の意味が変更されたり、表示項目が増えたりしたら対応しないといけないけど、それはまぁしょうがないと。

■ ただ、この案で難しいのがRuby-GNOME2のように、１つのHikiで英語・日本語のサイトを運用している場合だ。

そのような場合、上記の仕組みだけだと全部英語（あるいは日本語）になってしまう。

そこで、Hikiを拡張して、plugin/*.rbを読み込む直後に、plugin/#{$lang}/*.rbも一緒に読み込むようにする。$langのディレクトリが存在しない場合は読み込まない。

■ こうしておけば、上記例のreferer_en.rbは、plugin/en/referer.rbとでもしておけば良い。

■ まとめると、

1. Hiki本体としては、plugin/*.rbを読み込んだ直後にplugin/#{$lang}/*.rbを読み込むような仕掛けを用意する。
2. 各プラグインは、日本語文字列を別メソッド化しておく
3. 標準添付のモノに関しては、misc/plugin/en/ディレクトリを作ってそこに上記に対応した英語のリソースを追加してもらえるとよりベター

■ ＃きたさんのツッコミの後にこの文章自体を見直して一部書き直してます。

■ [Hiki] rd+ style

あれからイロイロといじりまして、入力間違い等のエラーに細かく対応しました。例えば、プラグインエラーが発生したときにどのプラグインでエラーが起こったのか簡単にわかるようになりました（さらに、hikiconf.rbに$plugin_debug = trueと書くとプラグイン自体のスタックトレースも出力されるようになりました）。

CVSの最新版で試せますので、興味のある方はどうぞ。

■ [Hiki][tDiary]多国籍化part2

shiroさんのコメントを読んでgettext的なアプローチを考えてみた。Ruby-GetText-Packageをそのまま使うこともできるけど、今のRuby-GetText-PackageはCGIに適用するにはオーバースペックな気がするのであくまでも、gettext的なアプローチを自前で用意することを考えた（って、Ruby-GetText-Packageのメンテナの発言としてはちとイカンな(^^;)）。

いろいろ、試行錯誤したのだが、長くなったので現時点で自分が到達した案のみ。

■ まず、Pluginクラスに以下のメソッドを追加する。

class Plugin
  def initialize
    :
    :
    @mo = plugin/#{lang}/*.resourceを読み込みHash化(ここでは後述のja/show_referer.resource)。
  end
  
  def _(msgid)
    @mo[msgid] ? @mo[msgid] : msgid
  end
end

■ 次に、例として昨日のshow_refererで考える。

show_referer自体は以下のような感じ。英語（らしき何か）はわざと前回例より長文にしてる。

  def show_referer(db)
    s = %Q[<div class="referer">#{_ "The referers for this page."}<ul>]
 
    referers(db).each do |ref|
      disp = replace_url(ref[0].unescape).escapeHTML
       s << %!<li>#{ref[1]} <a href="#{ref[0]}">#{disp}</a>!
    end
 
    s << '</ul></div>'
  end

■ この案のポイントとしては、_()というメソッドを用意するところだ（別にメソッド名はgettext()でも良いけど）。

これで、shiroさんの指摘されている「メッセージ文字列とその使う場所が離れないで済む」ということをクリアしている。

■ それから、plugin/ja/show_referer.resourceは以下のような感じ。形式は別形式（CVS等）でも良いし、文字列のエスケープの仕方とかは別途考えないといけないかな。

上記例ではキーとして英語を使っている。デフォルトは英語という考え方だ。したがって日本語のリソースファイルは必須となる。

  "The referers for this page." = "このページへのリンク元"

■ ここでは、"The referers for this page."という英語をキー項目としている。これをあえて日本語ではなく英語にしたのは、日本語をキー項目に使ってしまうと日本語を読めない人（や日本語を表示できないエディタを使っている人）にはリソースファイルを作ることすらままならないからだ。

そうすると、逆に日本人が主体のプロジェクトできたさんも心配しているように英語を使うことに抵抗感のある人が多いプロジェクトだと、プラグイン作成自体が敬遠されそうになってしまいそうな気がする。

■ というわけで、オレ的には昨日の案の方が（日本人から見ると）やりやすいかなという気がする。対応する必要のある文字列っていったってたかが知れてるしね。

ただ、今後、もし、Hikiが将来本当に多国籍で使われるようになって、英語やそれ以外の言語の人がプラグインを作ったときに、ソースファイルに入れる言語を何語にするかということを悩んでしまうのを避けたいのであれば、最初から英語にしてしまうというのは手ではある。I18N的に考えてもgettext的なアプローチな方がきれいだろう。

■ 蛇足だけど、上記案では、プラグイン単位で文字列（キー項目）を指定することはできない。一つの文字列に複数の意味を持たせる必要を感じなかったのでそのようにしたが、プラグイン単位で厳密に指定しようと思うと結構実装が面倒くさそう。

それから、上記の書き方だとshiroさんの指摘されている２つ目「本体に変更があった時に翻訳を変えるべき場所が自動抽出できること」はクリアできていない。ここまでやるなら、まじめにRuby-GetText-PackageとGNU GetText付属のツール(msgmerge等)を組み合わせて使った方が良いだろうな（と密かに宣伝）。

■ [Misc] WiLiKi

shiroさんのWiLikiはSchemeベースのWiki。もともと、多国語への対応を設計目標としてデザインしてある。っていうか、設計目標がきちんと最初に定義してあること自体がゴイスー。

■ [Misc]ふと思ったこと

なかださんがtDiaryをはじめたとしたら、どういう内容の日記になってどういう人がどのようなツッコミをするのだろう。

ちょっと見てみたい気がする。

■ [Ruby-GNOME2] XML Tree Viewer

\nを\rと変換していたバグを修正した。

■ [Misc]単語にリンク

最近、登録しておいた単語へ自動的にリンクを張るような日記システムやWikiを見るが、なんか見づらいような気がするのはオレだけ？

本当に伝えたいリンク先が埋もれてしまうような気がするんだよね。

＃もちろん、CSSでクラス分ければ良いんだろうけど。

■ オレにとってリンク先とは、そのページが参考にした「情報源」であって、気が向くとその情報源にはどういうことが書いてあるんだろうとリンクをたどって行く。

なんでもかんでもリンクが張られてると、どこをクリックすればよいのか迷うし、また、行った先が単語集だったりするとなんだかなぁと思う。

まだ見慣れていないからなのかなぁ。

■ [tDiary] Matzにっき

Ruby作者であるまつもとさんがtDiaryで日記をはじめられたようです。

スゲー。これでまた一つ楽しみが増えました。

■ [tDiary] 本日のリンク元表示プラグイン

久しぶり（？）に日記を巡回してたら、やまださんのパッチとそれに対するZnZさんの改善案を見つけた。

あてちゃって良いのかな。

■ [Ruby-GNOME2] Simple Text Editor

サンプルスクリプト第２弾です。

今回は、Ruby/GTK2以外のライブラリのパワーも知ってもらいたかったので、あえてRuby/GNOME2とRuby/Libglade2を使ってみました。

サンプルスクリプトとはいえ簡単なUndo/Redo機能・検索/置換機能も付いてるのでちょっとしたUTF-8エディタとして使えるかもしれません。是非、お試しください。

■ サンプルスクリプトという性格上、このツールに関する改善案（特にソースコード）などがあれば教えていただけると助かります。

コードを一から書き直してくれても結構です(^^;)。

＃これだけの機能を１つのクラスで実装しちゃったのはあまり美しくなかったかなぁ。

■ ちなみに、これの開発期間は３日ほどです。一番最初のプロトタイプはアッという間にできたのですが、Undo/Redo, 検索/置換機能とか欲張ってたら３日かかってしまいました(連休中に終わらせるため他にも実装したい機能があったのですがやめときました(^^;)）。

なお、実装にはgeditを参考にしました。ってか、geditをそのままRuby-GNOME2に移植しちゃったりしたら、喜ぶ人がいるかもしれないと思ったりして。

誰かやりません？

■ それにしてもGladeとRuby/Libglade2の組み合わせは慣れると便利ですね。

これだけの機能がついてRubyのコードとしては300step未満なのはスゴイ(自画自賛は良いこと無いかな...）。

■ P.S. 話はちょっとずれますが、どなたかこれをベースに（しなくても良いけど）Ruby-GNOME2を使ったエディタを作ってみてはいかがでしょうか。

■ [tDiary] 本日のリンク元表示プラグイン

昨日のパッチの件ですが、無事、取り込まさせていただきました。ありがとうございます。

なお、ZnZさんの修正を加えるとマッチしなくなったので、やまださんのをそのまま使わさせていただきました。

最新版をCVSからどうぞ（上記リンクからたどれます）。

■ [tDiary] 本日のリンク元表示プラグイン

yoshimiさんに指摘していただいた件ですが、.*?([^a]q|MT)だと、a以外が来た場合、(bq,cq...）にマッチしてしまうので（そういうパターンは無いかもしれませんが）、より厳密に、?, &以外ではマッチしないように.*?[\?&](q|MT)としてみました。

これでどうでしょう。

＃でも、なんでZnZさんのパターンがダメだったのかな。

■ [Misc] 日経Linux 2003/06

tDiaryが紹介されてるとのことだったので立ち読み。アクセスカウンタ表示プラグインがほんのちょっとだけど紹介されてる、うれしいな〜っと、RubyのところでRuby-GNOME2が載ってるじゃないですか！というわけでその場で２冊購入、というのは冗談で一冊購入。

多少なりとも自分が関わってるモノが紹介されると気分がよいですのー。

■ [Misc] Matz日記

さすがというか、しょっぱなからかなり濃い内容の割にオレのような人間にもわかりやすく書いてくれているので毎日楽しく読める。でも、これでRubyの開発が遅れちゃうんじゃないかとちょっと心配だったりもする。

って、まつもとさんをオレと一緒にしてはいけないか。え？オレ？あー、Ruby-GNOME2やんなきゃ...。

■ [Misc] xreaとCookie

yoshimiさんのホームページがわかった(って同じ方ですよね？違ってたらすみません)のでナニゲにTrial(tDiaryの方)を読んでいたら、xreaでCookieが表示されていない問題を解決されている模様。

というわけで、こちら(Linuxビボ〜ろく(^^;))にも以下を仕込んでみました。どんなもんかな。

RewriteRule ^$ index.rb

■ [Ruby-GNOME2] Committerが10人に

その割にはあまりはかどってないけどね〜。たははは。

７人日本人（たぶん）なのでユーザ数（推測(^^;)）からすると、まだバランス悪いような気もするなぁ。

■ [Hiki] URLの永続性

なるほどー。確かに外部からアクセスするときは、%いっぱいの意味不明な文字列じゃわかりづらいですね。でも、いちいち１つのページに２つの名前をつけるのも大変だなぁ。

■ まぁ、これはHikiとかに限った話ではないのですが、それならURLにベタな日本語そのまま書けるようになってくれないかなぁって思うんですよね。

ってかUTF-8だったらもう使っても大丈夫なんだっけ。まだダメ？

■ ユーザビリティという観点から見ても、ページの一貫性という意味でも、Webアプリケーションの実装上も、そうなってくれるのが一番スッキリするような気がするんだよなぁ。

■ URLに英語（というかASCIIの一部のPrintableな文字）しか使わないようにすべきというのもわかるけど、別に日本語の内容しか書いていないページだったらURLも日本語入ってて良いんじゃないのかなぁと思う今日この頃。逆に外国の人にも見て欲しいページだったらURLを英語にすれば良いんだし。

■ というのはひとまず置いておくとして、rd+ styleも対応した方が良いのかな...。

rd+ styleでは元々、キーに対して別名つけれるようになってるから、その別名を固定にしないといけなくなるのか。うーむ。

■ [Misc] URLの永続性(続き)

この世界を実現しようと思ったら、URLの参照元のページはURL参照先と同じ文字コードじゃないと現実的ではないでしょうね。

ZnZさんの指摘にURLに直接他多言語が使えるようになったとしたら、同じようにサーバにどのエンコードで送ればいいのかというのがありましたが、結局、参照元のHTMLではリンクをはる際に他多言語のURLを書く必要が出てくるでしょうから、世界中のHTML自体の文字コードをまずは統一するようにしないと無理じゃないですかねぇ。となると現時点ではUTF-8が一番現実解なのかなと。

もちろん、それを実現するためには関係するあらゆるツールがURLとしてUTF-8に対応しなければならないのでしょうね。現時点でどのツールがどこまで対応してるのかはわかんないですけど今のところは現実的ではないのかもしれませんね。

■ って、今、気づいたのですが、EUC-JPなページで、例えば、

<a href="http://ruby-gnome2.sourceforge.jp/ja/hiki.cgi?さあ始めよう">さあ始めよう</a>って書いておくと、MozillaだときちんとURL Encodeされてからアクセスしに行くんですね。これは知らなかったなぁ。でも、URL Encodeされた後の文字列がLocationのところに表示されたら意味ナイですよね。ここがきちんと日本語で表示されないと。

■ [Hiki] XREAでHikiを

以前、USENのFTTHを申し込んだ話を書いたのだが、未だに導入できていない。USENの営業に聞くと不動産の管理会社か大家が話を止めてるとのこと。

そんなわけで、本当は自前のOpenBlockSSで構築しようと思っていたサイトを泣く泣くXREA上で構築することにした。CPU負荷率が100 -> 1000まで大丈夫になったので負荷的に問題もないだろう。

■ 何人の方がすでにXREAでHikiを動かされているようなので、構築するのも楽勝だろーと思ってたのだが甘かった。

どうにもこうにも動かない。具体的には、ブラウザからアクセスしようとするとダンマリになる。

いろいろやってみて気づいたのが、成功している方のサイトのRubyのバージョンは1.6.8で、ここは1.6.7だったということ。

試しに自分のローカル環境で1.6.7環境を作って試してみたらやはりNG。

■ これかーということでデバッグ。recentプラグインで固まっていたことに気づいたんだけど、その後がとにかく時間かかった。で、以下がパッチ。

diff -ruN ~/hiki.org/plugin/00default.rb 00default.rb
--- /home/mutoh/hiki.org/plugin/00default.rb       2003-05-10 20:05:54.0000
00000 +0900
+++ 00default.rb        2003-05-12 00:49:51.000000000 +0900
 
   s = ''
   c = 0
-  d = nil
+  ddd = nil
 
   l.each do |a|
     break if (c += 1) > n
@@ -49,10 +49,10 @@
     tm = p[:last_modified ]
     cur_date = tm.strftime( msg_date_format )
 
-    if d != cur_date
-      s << "</ul>\n" if d
+    if ddd != cur_date
+      s << "</ul>\n" if ddd
       s << "<h5>#{cur_date}</h5>\n<ul>\n"
-      d = cur_date
+      ddd = cur_date
     end
     t = page_name(name)
     an = hiki_anchor(name.escape, t)

■ 要は、dという変数名をdddと変えただけ（別にdddじゃなくても良いだろうけど）。

それにしても、一体なぜなんだろう。別にメソッド名にdがあるわけでもなし。謎だ。

さらに、Ruby-GNOME2 Project WebsiteはRuby-1.6.7とパッチあてる前のHikiで動いてる。うーん、なぜ、XREAとウチの環境だけNGなんだ...。

■ とりあえず、このバグ取りで力つきたので、実際にXREA上で構築するのは後日。

■ [Misc] Website構築ツールとしてのWiki

Wikiはメッセージ性が強いツールだなぁとつくづく思う。というか、それが先にあって今の実装があるのかもしれないけど。いわゆるWikiWayというやつで、具体的には、

「ある１つのテーマを元に、みんなでよってたかってコンテンツを作っていこう」

というモノだ。コラボレーションツールというのかな。それ自体の考え方を否定するつもりはないけど、今回、オレが構築しようとしているHikiは、編集できるのはオレだけにする予定。

つまり、オレがやろうとしているのは、むとぽん７の移行であって、誰でも自由に参加するための場を提供する訳ではない。

■ 実は、むとぽん７程度のモノであれば、Hikiを導入しさえすれば、Websiteを構築するための必要なことをほとんど全てWWWクライアントから行うことができちゃうんだよね。HTMLを書くより簡単だし、添付ファイルも簡単にアップロードできる。さらに、いろいろなプラグインを使うことでむとぽん７よりも多彩なページを構築することができる。そういった「Websiteを簡単に構築するためのツール」としてHikiを選んだということだ。

■ ちなみに、なぜかタイムリーなことに、たださんのところでWikiの概念が語られている。

確かに、目的別にWikiがあるべきと言う考え方は賛成だ。

ただ、目的別にした場合「一体誰が運営しているWikiにその情報を登録するか」ということが重要になると思うんだよね。

■ オレにとっての判断基準は、そのWikiの運営者が登録されたコンテンツの扱いについてどのように考えているかと言うこと。ちょこっとした情報を載せるのであれば別にどうでも良いけど、それなりに時間をかけたモノは「誰が書いたか」「誰によってその後どのように変更されたのか」と言ったことを明示して欲しいと思っている。そうじゃないと、無責任に書き換えられた文章がオレの書いたことになってしまっていたらかなわないし、間違えを正しく修正してくれた人に対してはきちんとお礼が言いたい。

■ 残念ながら、Hikiのオフィシャルサイトを始め各Wikiサイトで、書き込まれた情報がその後どのように扱われるか明示されていないところが多い（ライセンス等も含めて）。

たぶん、そういうサイトに対して、オレ自身はチャチャを入れることはあっても有用な情報を登録することはたぶん無いと思う。もちろん、オレが書くようなことに有用なものがあるなんてことは滅多にないとは思うので、だからなんなんだという話になると何も言えないけどね。

＃そのようなことが明記されているサイトも当然ある。Ruby-GNOME2 Project Websiteも明記してるしね。

■ それから、話はちょっとずれるけど、上記に関連してオレにとって「こびとさん」というのは非常に気持ち悪い存在なんだよね。「こびとさんありがとう」ってのもなんか好きになれない。

もちろん、現状、そのような存在が効果的に機能しているというのは認めるし、こびとさんが書けないようにするのであればそのWikiを会員制にするしかなく、本来のWikiに望むべきことでは無いのかもしれない。

■ そういうわけで、上記の判断基準が現状満たせていないのでtDiary-users Projectに登録されているオレが書いたコンテンツは全てオレのWebsiteに移すつもりだ。

議論はしたつもりなので移すことに関し今さら問題・影響等は無いと思っている。なんとなくオレの意見に傾きかけたんだけど結局結論出ずという感じで曖昧になってしまっているのでそろそろケリをつけないとだしね。

＃最近、tDiary関連のプラグイン開発が滞っているのは変更したことをtDiary-users Projectに書くのがイヤだからということもある。

■ なぜ、オレの考えがそこに至ったのか知りたい方はこの辺のスレッドが参考になるはず。今読むとオレがスゲー偏屈なオヤジに見えるよ。

まぁ、自分のポリシーを貫くというのはそう言うことなので、それはそれで良いんだけどさ（苦笑）。

■ 最後に蛇足だけど、hikifarm.netを作るのであれば、それはコラボレーションする場の提供ではなく、「Websiteを簡単に構築するためのツール」とそれを実現する場の提供ということにすれば十分アリだと思う。Wikiって名前は隠した方が良いかもしれないけど。

■ Wikiについての雑感

良い機会なのでWikiについてなんとなく考えていたことをとりとめなく書いてみよう。

■ RE: Wikiページの「所有」

まずは、たださんのページに対するオレの意見を述べておこう。

署名入りのWikiページを修正するのは、とても心理的ハードルが高い。

まさにそのとおりだ。実は、Wikiに対する考えはオレ自身、たださんに賛成だ。

■ ただ、オレは、Web(Wikiではない)で公開する文章には、複数の人間がよってたかって書くと効率が良いものと、そうでもない文章があると思う。

前者にはWikiを使えば良いし、後者はWikiに書いてもあまり意味は無い（書いても良いけど）。

＃こ〜りんさんも同様のことを書かれていますね。

たまたま（意図的に）たださんが指摘した例は前者の例だし、オレがtDiary-users Projectから移そうと思っている文書は後者の方であると思う。

だから、現在、（図らずもtDiary-users Projectにあるオレの文書に限定して言えば）そもそもWikiページに書くべきでないものが（一時的に）Wikiに書いてあったということにすぎない。そして、そのことが結果としてオレ自身の（たださんが言うところの）モチベーションを下げまくったのだから、これはもう移すしかないのだ。ただ、このことに関してはオレ自身が最初にきちんと気づくべきだったと反省もしているんだけどね。

■ それから「奉仕の精神」だけど、たださんの指摘はあくまでもWikiWayに従ってWikiに文章を書く人の心構えだ。一般的な「奉仕の精神」と間違えて読んではいけないと思う。インターネットで情報を公開する上で、tDiaryについての情報がtDiary-users Projectに無ければ奉仕したことにならないということはないはずだ。

■ っていうか、オレは奉仕の精神でtDiaryのプラグインを書いたことはないんだけどな。自己顕示欲と言われればそうかもしれないけど、どちらかというとアーティスト（って言えばいいのかな(^_^;)）として自分の中にあるイメージを実現して、それを公開してるだけなんだよねぇ。オレの中では作曲活動と趣味のプログラミング、文章を書くと言うことは全く同じことだ。

■ みんなは奉仕の精神とかでやってるのか...。

■ RE: Wikiページの「所有」(2)

Wikiで署名をするという行為は、フィードバックのチャンスをみすみす逃しているに等しいと思うからである。

確かに、Wikiであれば確率的にはそうかもしれない。 でも、オレはこびとさんがこっそりフィードバックするくらいならフィードバックは不要だと思っているので別にもったいないとかいう発想はないんだよね。
それに、フィードバックをくれる人はメールなりなんなりでフィードバックしてくれてるしね。その方がお礼も言いやすいし。

■ それからもう一つ。以下には全く賛成できない。オレにとってはおもしろくも何ともない。なんでこれがおもしろいんだろう。

十分に発達したWikiサイトの面白さは、個人としての「個」が消えてしまう一方で、サイト全体としての「個」が現れてくるところにあると思う。

逆に、オレは様々なツールのChangeLogを眺めては、あー、この人はここでも活躍してるんだー、とか見てきた人なので、Wikiであってもそういう名前が残っていたら楽しいだろうと思うのだけどな。

■ RE: 蛇足

「読む側」から見ると、「趣味の個人サイト」と「プロジェクトとして複数の人が運営しているサイト」では、後者にある方が安心だと思う。だって、個人サイトはその人が飽きたら、ある日突然消えてしまうかも知れない。

これは同意する。だから、tDiary-usersにオレのコンテンツを置いてもらえるようにアクセス権のあるWikiの提案をしたわけだし。
でも、そのこととオレのモチベーションを維持するのとどちらを取るかということで後者を取ったわけだ。
あと、オレの興味が無くなったときにWebから情報がなくなるというのもおもしろいかもしれない。困る人がいるかもしれないけど。

■ [Misc] Wikiの管理者

ここからはオレの意見だけ。まず、これはWikiに限ったことではないが、複数人で何かを行う場合、最終的な決定権を持つ人間を作るか、最終的な決定を行うためのプロセスを「最初に」決めておいた方が良いと思う。

たとえば、そのWikiにそぐわない内容がWikiに書き込まれたとする。それを削除するか残すかといったことを決めなければいけないかもしれない。こっそり消してしまうと、せっかく良かれと思って書いた人はこびとさんであっても良い気持ちがしないだろうから、削除する場合はその旨をどこかにアナウンスすべきかもしれない。

通常、フリーソフトウェアの開発では「優しい独裁者」が一人いる。このやり方は決定が早いし、オレ的にはおすすめだ。

■ [Misc] Wikiのセキュリティ

近年のインターネット事情においてWikiほど性善説をベースに構築されているツールは少ないと思う。

誰でも書き込めるのだから誰でも不正にコンテンツを書き換えることができる。

もちろん、これ自体は認証なしでやる以上、避けられることではないんだけど、たとえば、以下のようなコンテンツをそのWikiのトップページにそれとなく置かれたらどうだろう。

○○（Wikiによく書き込む人の名前）より
面白いツールを見つけました。○○ユーザだったらこれを試してみる価値ありです。
http://securityhole.com/goodtool.exe
 
 - おー、オレも試してみたよ。まだの人は是非！ ××（こびと１）
 - 入れてみたけどイマイチじゃない？ ■■（こびと２)

■ もちろん、ツールとはウイルスだ。○○さんはそのWikiで信用されている人の名前であればあるほど効果的だ。こびとさんの部分は書かなくても良いけど、書くとそれっぽい。

Hiki等では更新された瞬間に変更内容がメールで飛ばされるので、それを随時監視してさえいればほとんど実害は無いだろう。でも、もし、○○さんが旅行にでも出てたらどうだろう。

こういうのもセキュリティ脆弱性って言って良いような気がするけど違うのかな。教えてエライ人。

■ 実は、tDiaryのツッコミ欄にも同様の問題がある。ただ、Wikiに比べ、「日記」であるtDiaryではその影響は少ないと思うんだけどね。

＃ツッコミ欄に変なリンクがはられていたら、それは安易にクリックしちゃダメだよ。

■ [Hiki] ファイル添付機能

これ書いてて気づいたんだけど、Hikiのファイルアタッチ機能もかなーり危険だ。何せ誰でもファイルを上書きできちゃうからね。

md5sumなんかも(Hiki上に置くのであれば）役に立たないし。特に、Windowsのツールをsetup.exe形式で配布しているHikiサイトは（認証を掛けずに）このような機能は使っちゃダメだろうね。

■ [Misc] Wiki雑感（２）

これで終わりにできるかな。一応、リンクをたどってコメントしときます。

■ まず、koyasuさんとこと、こ〜りんさんとこ。

「Wikiで書くべきでない文書」ってのはちょっと指摘がずれてるような気がする。オレは、お二人がリンクしているオレのページの段落で

ただ、オレは、Web(Wikiではない)で公開する文章には、複数の人間がよってたかって書くと効率が良いものと、そうでもない文章があると思う。前者にはWikiを使えば良いし、後者はWikiに書いてもあまり意味は無い（書いても良いけど）。

とは言ってるけど、だからといって「Wikiで書くべきではない」と言ったつもりはないんだよね...けど、たぶん、お二人ともその後の

だから、現在、（図らずもtDiary-users Projectにあるオレの文書に限定して言えば）そもそもWikiページに書くべきでないものが（一時的に）Wikiに書いてあったということにすぎない。

と書いた部分で上記のように思ったのだとしたら、私の文章の構成力の無さに問題がありますね。すみません。
＃こういうときはこびとさんに直してもらった方がよいのかもしれませんが(^^;)。

単純に、上記に関しては以下のようなことを意図してたんだよね。うむ。そう読めないな。ダメだこりゃ。

だから、現在、私がWikiページに書くべきではなかったものをWikiに書いてしまったのが問題である。

それから、私はその前で、

複数の人間がよってたかって書くと効率が良いものと、そうでもない文章があると思う。

と書いてるけど、私の文章が後者だと言い切ってしまったのは言い過ぎだった。たださんが指摘されてるように私自身がどっちだと決めれることでも無いね。

■ [Misc] 原著者主体 vs コンテンツ主体

今回の議論でおもしろいなと思ったのは、koyasuさんの以下のような指摘に代表されるような気がする。

単純にコンテンツに含まれる情報の価値を比較した場合，Wiki のように原著者の意向を無視して変更を加えたとしてもその価値が下がることはないと思います．特に完全に不特定多数の人間が編集した場合，文書からある特定の人物によるバイアスが抜けるので，むしろ価値が上がるのではないでしょうか．

これは確かに正しいと思う。コンテンツの価値としてはね。
でも、原著者の意向を無視して変更を加えられるのが気持ち悪いんだよね。変えるのであれば何が悪かったのかきちんと言って欲しい。

■ つまり、たださん、koyasuさんの指摘は上記に代表されるように常にコンテンツ主体の考え方だ。そしてそれは正しい。オレも自分の書いたモノでなければむしろ積極的に応援したい(^^;)。

でも、オレがそれなりに時間をかけて考えた文章を公開するのであれば、そのような原著者ないがしろの状況を肯定する仕組みはイヤだ、というわけだ。もし、コンテンツ主体という色メガネでオレのこの日記を読んでるとしたら、理解不能なところが結構あるんじゃないかな。

あと、koyasuさんのところでもう一つ。無視しても良かったんだけど。

これは個人的なお願いなのですが，tDiary-users にあるむとうさんのドキュメント類をむとうさんのサイトに引き上げるにしても，現状のドキュメントについてはそのまま置いておいてくれませんか．個人的に不特定多数による編集でドキュメントの中身がむとうさん個人のものとどれだけ違ったものになるか見てみたいという欲求もありますし．

オレはそう言ったことに興味がないので、ご自身でそのような実験的なドキュメントを作ってみれば良いのではないでしょうか。
＃今までのオレの書いてきたことを見て、なおそのような発言をするとはケンカ売られてるとしか思えないなぁ。ま、別に良いけど。

■ [Misc] ChangeLogはライナーノーツ

たむらさんところ見て、なるほどと思った。確かにオレが指向しているのはフリーソフトという１つのインディーズアルバムを制作することなのかもしれない。

＃でも、最近、ヒマになったんですよ。だから今のうちにとMy IssueList棚卸し中(^^;)。

■ [Hiki] この前のrecentプラグインの修正パッチ

どうも、何人か同じ現象に遭遇してそしてこのパッチで直ってるみたい。環境の問題じゃなかったんだ...。

＃でも、謎。

■ [Ruby-GNOME2] Ruby/GtkSourceView

この前にコミッターになってくれたGeoff YoungsがさっそくRuby/GtkSourceViewをCVSにインポートしてくれた（ってか作業したのはオレだけど(^^;)）。

GtkSourceViewは、GtkTextViewを拡張したテキスト閲覧・編集用ウィジェットで、その名の通りソースコードをカラフルにしたりカッコの前後にカーソルが来たときにその対応関係を強調表示してくれたりするものだ。GeoffはこれをベースにIDEを作るつもりらしい...てか作ってて、実際に動くモノがここに(ScreenShots)。

■ オレもちょっと使ってみたけどなかなか良い感じだ。RubyでIDEを作ってみたい人は試してみる価値はあるよ！

＃GTK+-2.2環境じゃないと動かないので注意

■ [Misc] MUTOPON7 Annexオープン！

ということで、Hikiを使って構築してみました。

ひとまず、tDiary-Usersのコンテンツを移しましたが、思ったより量があって手こずりました(^^;)。でも、これでスッキリ。

むとぽん７の情報も徐々に移していこうと思います。デザインももう少し考えなきゃね。

それから、Hiki上の文書はGFDLで配布するとしてみました。

■ [Ruby-GNOME2] トップページのアイコンを変えてみた

昨日のGeoffがやってるROX Rubyで配布しているRuby-GNOME2アイコンがクールだったのでくれ！といったらSVGファイルを送ってくれた。

SVG Viewerって何が良いの？と聞いたら、Sodipodiを奨められたので、さっそくSodipodiのサイトからrpmをゲットしてインストール。きれいにイメージを拡大縮小できて良いね、これ。というわけでSodipodiを使ってpng化し、トップページのアイコンに使ってみることにした。pngってオレがGimpから生成したヤツは、IEだと背景が透明にならないんだけど今回は大丈夫かな。明日会社で確認しよう。

■ Sodipodiのプロジェクトサイトの下の方にあるスクリーンショットとか見て一瞬、日本人がやってるプロジェクトなのかと思ったけどそう言うわけではないみたいね....(^^;)。

■ [Hiki] hoge.html形式でアクセスできるようにする

MUTOPON7 ANNEXをいろいろといじくりまわす。

とりあえず、hiki-devのかずひこさんのメールを参考に、hiki/hoge.html形式でアクセスできるようにしてみた。当時とちょっとだけhiki_anchorの仕様が変わっているので念のため一応書いておこう。

.htaccess

RewriteEngine on
RewriteBase /hiki/ja
RewriteRule ^([^/]+)\.html$ ./hiki.cgi?$1

plugin/anchor.rb(plugin)

def hiki_anchor( page, display_text )
  "<a href=\"#{page}.html\">#{display_text}</a>"
end

■ [Hiki] XREAでattachプラグイン

XREAでそのままattachプラグインを使うと、一応は添付ファイルの表示ができるものの、ContentTypeがtext/htmlで返されるみたいで都合悪い。

よしみさんとこを参考にさせていただいたのだけど、どうも例のmod_layoutが悪さをしているらしく、それをキャンセルするような指定にされている。ただ、XREAで使う以上、広告はどこかに表示させないといけないので、よしみさんはフッタの部分に表示しているようだ。

まぁ、オレも一番下に広告でも良かったんだけど、Linuxビボ〜ろくに併せて一番上に表示させられないもんかといろいろ考えてみた。で、結論は、以下のようなプラグイン(attach2.rb)を仕込むこと。

$attach_cgi_name = "hiki.xcg"
def attach_anchor(file_name, page=@page)
  s =  %Q!<a href="!
  s << %Q!#{$attach_cgi_name}#{cmdstr('plugin', "plugin=attach_download;p=#{page.escape};file_name=#{file_name.to_euc}")}">!
  s << %Q!#{file_name.unescape.to_euc}</a>!
end
 
def attach_image_anchor(file_name, page=@page)
  s =  %Q!<img alt="#{file_name.escapeHTML}" src="!
  s << %Q!#{$attach_cgi_name}#{cmdstr('plugin', "plugin=attach_download;p=#{page.escape};file_name=#{file_name}")}">!
  s << %Q!</img>!
end

要は、添付ファイルを読み込むときだけ、hiki.xcgを呼び出すわけだ。

■ ホントは、footerプラグインと対になるheaderプラグインがあればそこに広告を置けるなぁと思ったけど、ま、いっか(^^;)。

■ [Misc] Sodipodi

たむらさんときたさんのツッコミを読んで、なるほどー、と思ってちょっと調べてみたところ、OkaさんとYamatoさんというお二人がPrimary authorsってことでクレジットされてますね。Laurisって人がメンテナみたいですけど。

＃だから、セーラー○ーンなのか...。

■ ところで岡さんってGTK Tutorialの和訳の方ですよね。英語嫌いの私にはとても助かりました。

GTK+関係のMLでも活躍されてたと記憶してますが、Sodipodiもやってたのか。スゲー。

＃そういや最近はML自体覗いてないなぁ（って言っても昔もROMしてただけだけど(^^;)）。

■ そういや、ROXってイイんですか？ROX Filerだけ使ってみたけど、元々、私はその辺CUI派なのであまり使わないんですよねぇ（ぉぃ。

でも、前に試したときRuby-GNOME2のサンプルスクリプトからドラッグ＆ドロップできたのは感動したなぁ(^^)。

■ [Ruby-GNOME2] Ruby-GNOME2 Project Website

やっぱりIEだと画像の背景が透明になりませんでした。

いろいろググッてみたところ、「透過PNGをPIXIAで作る」を見つけたので、ここに従ってPIXIAを使って透過PNG化してみました。255色だとイマイチだったので、フルカラーの方で背景色をHTMLのバックグラウンド色とあわせました。IEだと背景色が表示されてしまいますが、Mozillaだったら透過色になっていると思います。

■ [Misc] Sodipodi

安部さんが詳しい情報を書いてくださっています。ありがとうございます。

日本のアニメを使うのって結構あるんですねぇ。知りませんでした。

＃Che Guevaraって誰？と思ってググッてしまったのは内緒です(^^;)。

■ [Hiki] hiki_anchor

かずひこさんから指摘があったのでその箇所を修正しておきました。

■ ただ、escapeに関しては、「呼び出し元が適切にescapeするようにしてから呼び出す」と仕様変更になったので、そのままで良いはずです。

■ [tDiary] 第２tDiary.Net

まだ応募が少ないと言うことなので申し込んでみた。なぜか今日はかずひこさんネタが多いらしい。

■ [tDiary] 本日のリンク元表示プラグイン-2.4.0

もしかしたら気づいていた人もいるかもしれないけど、１週間ほど前からLinuxビボ〜ろくに仕込んでおいた本日のリンク元表示プラグインをCVSにアップロードしました。

今回はzundaさんの本日のリンク元もうちょっとだけ強化プラグインを参考にして、アンテナの表示を分離しました。

＃tDiary-1.5.x系のみの対応です。

■ なお、一部実装を変更したので、disp_referrer.rbの機能を利用したプラグイン（zundaさんのdisp_referrer2.rbとか、sheepmanさんが作られたdisp_referrer_ext_category.rbとか）と一緒に使うとエラーが出るかもしれません(未確認ですが)ので試される方はご注意ください。

■ [Ruby-GNOME2] 誕生日

Ruby-GNOME2 Projectがなんと満１才の誕生日を迎えました。ぱちぱちぱち。

記念にRuby-GNOMEの歴史を書いてみました。でも、あまり昔のことは書けていません。

＃実は私がRuby-GNOME(1)に関わったのってかなり後半になってからだったので....

というわけで情報をお持ちの方は是非教えてください。

■ [Ruby-GNOME2] 誕生日プレゼントは

バグ２件のレポートでした(T_T)。しかも結構めんどくさそうなヤツ。

誰かプレゼントに直してくれたパッチくれないかなぁ...(T_T)。

■ それはそうと、Geoffが粋なプレゼントを作ってくれました。ふふふ。

彼は絵が巧いなぁ。

■ [Ruby-GNOME2] Ruby-GNOME2-0.5.0, Ruby/GtkSourceView-0.1.0

リリースしました....。結局、Ruby/GtkSourceViewのリリースまでやってしまいました。マジで一日がかりです....(T_T)。

＃はよ寝よ。

■ [Misc] A Strolling Programmer

おぉ！

(ZnZさんとこ経由)

■ [Ruby-GNOME2] googleplotを使ってみる

おもしろそうだったのでRuby-GNOME2のサイトに入れてみた → こちら。

どんなグラフになるのか今から楽しみ。

＃ってか、２日目にいきなり減ってるし...(T_T)。

■ [Misc] googleplotをSF.jpで使う

SF.jpにgoogleplotを入れるのはちょっと面倒なので簡単にどんなことをやったかメモしておくことにする。

■ まず、googleplot-0.1がruby-1.8.xのみ対応なので以下のパッチでruby-1.6.xに対応させた。

diff -ruN googleplot-0.1/googleplot.in dev/ruby/googleplot-0.1/googleplot.in
--- googleplot-0.1/googleplot.in        2003-05-22 14:17:54.000000000 +0900
+++ dev/ruby/googleplot-0.1/googleplot.in       2003-05-27 02:22:55.000000000 +0900
@@ -117,7 +117,11 @@
       count = 0
       query = CGI.escape(key)
       Net::HTTP.start(@google_host, 80) {|http|
-        response = http.get("/search?q=#{query}&ie=UTF-8&oe=UTF-8")
+        if RUBY_VERSION >= '1.8.0'
+          response = http.get("/search?q=#{query}&ie=UTF-8&oe=UTF-8")
+        else
+          response = http.get2("/search?q=#{query}&ie=UTF-8&oe=UTF-8")
+        end
         if m = /\bswrnum=(\d+)\b/.match(response.body)
           count = m[1].to_i
         end

(*)ただ単に、http.getのところをhttp.get2とすれば良いらしい。

■ 次にming-0.2aをインストール。とりあえず手元のRedHat8上で静的リンクされたlibming.aを作った。たぶん、Makefileの all: の部分を all: staticしてmakeすればよかったと思う（うろ覚え）。

■ それから、ming-ruby。これはsoファイルを作らないといけないのだが、オレの環境(RedHat8)で作ったming.soは、Debianを使っているSF.jpでは使えなかった(glibcのバージョンが違うと言われる)。

そこで、SF.jpのコンパイリングファーム(cf)を使うことにした。

まず、cf上の自分のホームディレクトリでruby-1.6.7をコンパイル＆インストール。

次にそのrubyを使ってming-rubyの本体であるming.soを作成する。もちろん、このときには先ほど作ったlibming.aとming.hが必要。

といってもそのままruby extconf.rbしてもエラーが出るはずなので、ローカル(RedHat8)で作ったming-ruby用のMakefileを持っていって環境に合わせて書き直すか、あるいはming-ruby用のMakefileを強引に作る。

オレの場合、cf上でming-ruby/ext/ming/ming/extconf.rbをいじって強引にMakefileを生成するようにした。こんな感じ。

--- ext/ming/ming/extconf.rb     2002-06-24 23:12:12.000000000 +0900
+++ extconf.rb  2003-05-28 22:32:20.000000000 +0900
@@ -3,8 +3,7 @@
 
 require "mkmf"
 
-if have_library("ming", "newSWFShape") and
-       have_header("ming.h")
+if have_library("ming", "newSWFShape")
   if have_library("ming", "SWFMovie_setButtonSound")
        $defs.push '-DSUPPORT_PCM'
   end
@@ -14,3 +13,4 @@
   create_makefile("ming")
 end

■ んでもって、ext/ming/ming/配下でruby extconf.rb（libming.aも同じディレクトリに置いたような気がする)。出来上がったMakefileをlibming.aを静的にリンクするように編集して make。できあがったming.soをshellサーバ(cfではない)のgoogleplotと同じディレクトリに配置する。

■ おっと忘れてた。googleplot自体はming-graph.rbとgoogleplot.cssとEfontSerifB.fdbとローカルでmakeしたgoogleplotをshellサーバ上のディレクトリに配置する。このとき、googleplotの330, 335行目くらいにあるEfontSerifB.fdbとgoogleplot.cssのディレクトリを適切なディレクトリ（フルパスが確実）へ変更した。他にも何か修正したかも。忘れたけど(^^;)。

■ ここまでできたら後は実行して試してみる。

うまく動いたら、後はHTTPでアクセスできるようなところに結果を出力するようにして、さらにcrontabを書いて完了。

■ 長い割にはだいぶはしょっちゃったので参考にならんな(^^;)。

まぁ、SF.jpで使うのは結構面倒くさいと言うことで（ってなんぢゃそれ）。

■ それにしても、最近は楽しいRubyスクリプトがいっぱい出てきたので試す時間がいくらあっても足りないのぅ。

■ [Ruby] ming-ruby

なかださんに指摘されてしまった。相変わらず無知っぷりを発揮してしまった結果、ming-ruby作者の池上さんにもご心配をかけてしまった。大変申し分けないです。

そんなわけで、改めて手順を書き直してみた。

これでお許しをm(__)m。

■ mingのコンパイル

今日はcf上でやってみた。ming-0.2a.tgzを取ってきてそれを展開し、そのディレクトリで以下のようにする(ホームディレクトリ直下で作業する例)。

$ cd
$ tar xvzf ming-0.2a.tgz
$ cd ming-0.2a
$ make
$ make static

これで、ming-0.2a直下にlibming.so, libming.aができる。

■ ming-rubyのコンパイル

次にming-ruby-0.1.4.tar.gzを持ってきて展開。

$ cd
$ tar xvzf ming-ruby-0.1.4.tar.gz
$ cd ming-ruby/
$ ruby install.rb config -- --with-opt-lib=/home/users/m/mu/mutoh/ming-0.2a --with-opt-include=/home/users/m/mu/mutoh/ming-0.2a

■ これでext/ming/ming/Makefileができる。ただ、このMakefileだとlibming.soをリンクするようになっているので、以下のようにlibming.aを静的にリンクするように修正した。

--- Makefile.org        Sat May 31 02:45:39 2003
+++ Makefile    Sat May 31 02:47:26 2003
@@ -33,8 +33,8 @@
  
 #### End of system configuration section. ####
   
-LOCAL_LIBS =
-LIBS = $(LIBRUBY_A) -lming -lc
+LOCAL_LIBS = ~/ming-0.2a/libming.a
+LIBS = $(LIBRUBY_A) -lc
 OBJS = ming.o swfaction.o swfbitmap.o swfbutton.o swfdisplayitem.o swffill.o swffont.o swfgradient.o swfmorph.o swfmovie.o swfmovieclip.o swfshape.o swftext.o
swftextfield.o util.o
   
 TARGET = ming

■ で、あとは、ここでmakeしてできたming.soを使うと。

■ これでどうでしょう。まだイケてないところがあるかな。指摘していただければ直しますです。

■ [Misc] RedHat9

あげてみた。gdmからログインしようとすると固まる。なんでかなぁと思っていろいろやってみたら、ATOK X周り(IIimかも)のところで固まっていたらしい。

再度、ATOK Xを再インストールし直したら無事動くようになった。

バージョンアップの度にこれやるの面倒くさいなぁ。

■ [Ruby-GNOME2] RSSViewer.rb

FootNotesのRuby-GNOME2-0.5.0アナウンスの記事のコメントより。

rss/rdf を集めて閲覧するためのRSSブラウザとのこと。

とても良い感じなので試してみようと思ったが、gtkhtml2が無いと怒られる。

上記サイトに「最新だと libgtkhtml2 support のものが必要」って書いてあるけど、Ruby/LibGtkHtml2ってまだRuby-GNOME2 Projectではサポートできてないよな。ってことは、どこかにlibgtkhtml2のRubyバインディングが存在するのだろうか。であれば、（オレ自身で実装しなくてすむし）とても助かるんだけどなぁ。