あーありがち

過去の日記 2017-08 2017-07 2017-06 2017-05 2017-04 2017-02 2017-01 2016-12 2016-10 2016-09 2016-08 2016-07 2016-05 2016-03 2016-02 2016-01 2015-12 2015-10 2015-09 2015-04 2014-10 2014-07 2014-06 2014-05 2014-02 2014-01 2013-12 2013-10 2013-09 2013-08 2013-07 2013-06 2013-05 2013-04 2013-03 2013-02 2013-01 2012-12 2012-10 2012-09 2012-08 2012-07 2012-06 2012-05 2012-04 2012-03 2012-02 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ 作業スペースと集積スペース

いつも思うことだが、バックアップや世代管理を個人の作業に期待するのは愚策である。基本的にはそんなにマメに世代バックアップを用意するなんてばからしくやってられない。しかしだからと言って共同の作業スペース（Windows や Mac のファイル共有をイメージすれば分かりやすい）上のデータをすべて世代管理するなんて、膨大すぎて非現実的である。

「いわゆるコード」の場合、CVS で管理していれば working copy と repository は自動的に分離される。したがって repository そのものが爆発することは、まぁ運用ポリシーにもよるがそんなにないだろう。しかし repository と working copy が同居しやすい場合((例えば Zope や WebDAV 経由の Subversion なんかがそういう状態になりやすいだろう。実際には working copy と repository はイコールにはならないが、手軽なので「確認用の環境を用意しない運用になりやすい」んじゃないかと思う。))、リポジトリの爆発という問題とどうつきあうのかという、けっこう深刻な問題が発生する。

あ、cvs admin みたいにこの revision は必要ないから削除とか、そういう操作ができればいいのか？（もちろんすべてのファイルについてそんなことやっちゃいられないが。） Subversion は次世代のバージョン管理として期待値はでかいが、クライアント環境をあまり選ばない（CVS みたいに面倒なことを気にしなくてよい）分、repository の管理能力を問われそうな感じだな。あ、Zope + Subversion てのも手かな？ 普段 Zope にどかどか突っ込んでいって、ちゃんとしたバージョンの段階で Subversion に突っ込んで publish、ZODB のサイズを見て不定期に pack を行う。あ、これいいかもしんない。

• Zope + CVS
• Subversion + CVS
• Zope + Subversion
• Subversion + Zope

なんかの組み合わせがなくはないのかな？ とりあえず操作性や柔軟さを考えて CVS をフロントには置かないってことで。

_ VikiWiki を上げる

優先度は高くなかったはずなのだが、VikiWiki のバージョンを上げた。理由は Farm 機能。Farm 機能の運用実績では Hiki が筆頭だが、Hiki はやはり書式が貧弱なので、PukiWiki 互換の書式を使うことができる VikiWiki で Farm を起こそうと考えた。

_ mod_ruby 化

AddModules の記述は必要

公式サイトのドキュメントでは

#AddModule mod_ruby.c

が書かれているが、実際にはコメントアウトしてるとソース垂れ流しになってしまう。

実行属性は必要

これは実に残念。でも Forbidden になるのでソース垂れ流しにはならない。

どこかのサイトで見つけたこの記述

AddHandler ruby-script .rbx .rbx

は要らなかった

ファイルの拡張子に応じて SetHanlder する記述が必要

<Files *.rbx>
  SetHandler ruby-object
  RubyHandler Apache::RubyRun.instance
</Files>

結果

VikiWiki は mod_ruby 化したら確かに速くなったが、permission の関係でエラーがあちこちで出るようになった。setup.rb に頼らず自力でそのままファイルを展開した方がマシだったろうか？ 本家に mod_ruby でも動くと書いてあったからやったのだが、鵜呑みにしすぎか？ 面倒くさくなってきたので今日はこの辺で。

mod_ruby の本当のおいしさはやっぱ embedded ruby、eRuby なんだよな。<% %> なのは ASP も睨んでのことですね。確かに ASP での利用も可能なようです。

_ つーか

開発スピードと完成度と、ドキュメントの分かりにくさを考えると VikiWiki はステた方がいいのか？(^^;

_ Snort ユーザーズマニュアル日本語版

• 日本 Snort ユーザー会
• Snortユーザーズマニュアル日本語版公開

へぇ。んーでもこれ man じゃーないんだな。

_ ネットワーク的な距離はどうやって調べたら

ネットワークの接続が変わった。

firewall がきつくなった。

traceroute できなくなった。

うーん。

ring の TENBIN では 九州ギガポッププロジェクトが近いそうだ。どこそれ。プロジェクトで扱っているネットワークの図を見ても ring サーバはどこだか分からないし。

_ メディアビジョンごとなくなったの？

むりくりDT blog: メディアヴィジョンって、こっそり＊＊されていたのですね。

げへ。

Kacis シリーズが e-frontier の製品になってて、kacisbook.net には終了のお知らせ、mvi.co.jp は正引きできなくなってますな。

まぁ個人的にはプロノート/マイノートが発売される前後くらいから情報の整理は Wiki に移行していたので、あとは過去の資産をどう整理するかだけなのですが。

あー。サイト直さないといけないんだな。なんかオススメしてたような気がするし。つーか高くなってないすか、これ。