2007/07/31 11:02:00
さて、そろそろ出そうかな。Subversion配下での初めてのリリース作業になる。
2007/07/30 11:37:00
matzにっき経由「人気のAPI／フレームワークを作るための39カ条」。客観的に見てKahuaにはけっこう厳しい条件かも。API/フレームワークは使われてナンボだから、こういうのも真摯に受け止めないとなぁ。
少なくとも、APIはもうちょっと整理しないとあきまへん。
2007/07/29 09:37:00
無事Subversionへのリポジトリ移行が完了。リハーサルを繰り返していたのでトラブルはなし。svnsyncを使ってコミットごとにスレーブリポジトリを同期する仕組みも作り、なかなかいい感じに仕上がった。
もうひとつ。Anonymous SVNでリポジトリを公開したので、Kahuaに手を入れてみたい人にとってはぐっと便利になったと思う。以前外の人だった頃、Anonymous CVSが公開されていなかったせいで、Kahuaに不具合を見つけてパッチを作って送ったり、プライベートな修正点をKahuaの更新に追随させるのが非常に面倒だったことをよく憶えている。何しろ、ViewCVSからtarballとしてダウンロードするしかなかったのだから。当時の事情を知るメンバーに、何でAnonymous CVSでのリポジトリ公開をしていなかったのかを聞いたら、当時 pserver のセキュリティホールがいくつか発見されて、その穴をついた大手オープンソースプロジェクトサイトのクラッキングが話題になっていたために避けたのだということだった。
これで、サーバ機の刷新やそれにともなう環境整備は一段落した。心置きなくKahuaの開発に没頭できると言うものだ。
2007/07/27 16:20:00
さんざん悩んだり議論したりした結果、当初の予定通り'''今週末にKahuaプロジェクトのソース
リポジトリをCVSからSubversionに移行する'''ことにした。理由は以下の通り。
- CVSの後継として広く使われている
- CVSリポジトリからのコンバートプログラムもかなり安定している
- 継続的に開発が行われている
- SCMとして必要充分な機能を備えている
- ライブラリ化しているので、付加的な機能を加えるのが楽
- URLによるリポジトリの表現や、リビジョン番号の考え方が直観的
- SVKを使えば、分散リポジトリ的に使うこともできる
- 個人的に慣れているし、経験上CVSのユーザならすぐに馴染めると考えた
darcsは真の意味での分散リポジトリを実現しているし、そのコンセプトは極めて明快で魅力的なのだけど、Kahuaプロジェクトの新しいサーバでソースリポジトリを管理するには、いくつか難点があった。
- GHCがNetBSD/amd64(x86_64)をサポートしていないため、ビルドできない。NetBSD/i386なマシンでstatic linkなバイナリを作って持って行ったら動いたから、これは決定的な難点ではないけど。
- コンセプトや操作体系が大きく違うため、CVSユーザが乗り換えるには敷居が高い
- フックスクリプトのサポートがないため、コミット通知メールを送れない
- コミット通知メール代わりに、メールによるコミットを使用するには、現状では技術上の敷居が高い(OP25Bの回避など)
個人的には、nobsunやjmukさんにかなりほだされて、darcsに傾きかけたのだけど、やはり保守的にいくことにしたわけだ。
なお、Subversionに移行後は、Anonymousユーザ向けにもリポジトリを公開するので、Kahuaをちょろっといじってみたい人にとってはよりやりやすくなるんじゃないかと思う。
2007/07/21 14:30:00
2ヶ月くらい前に新しいサーバ機を調達して以来懸案になっていた移行作業をようやく終えた。こういう機会じゃないとサイトの構成その他を見直すことはなかなか難しいのでヘタに悩んでしまったのと、単純に怠惰なのとでこんなにかかってしまった。まぁ粘った甲斐あってかなりいい感じのサイト構成になったと思う。
また、ここkarettaでもおなじみの、「mod_rewriteを駆使してURLを短縮」ハックを組み込んでみた。以前から、/cgi-bin/kahua.fcgiなんてのがURLの中に含まれているのが甚だ目障りだったのだ。本当はAJPブリッジを開発しようとか、いろいろと野望はあった(今でもある)のだが、ブリッジ自体はFastCGIを利用している。だいぶ見た目がすっきりした。さらに、古いURLから新しいURLへのリダイレクトもmod_rewriteで実現した。細かいところでハマったけど(ScriptAliasに渡った後、スクリプトの引数にあたるパス要素が再びrewrite処理にかけられるとは思わなかった)、mod_rewriteの強力さを実感できたのは収穫だった。
ということで、http://www.kahua.org/ にアクセスすると短いURLでブラウズできると思います。IPアドレスを変更した影響が多少(DNSキャッシュが残ってたりとか)あるかもしれないのですが、うまく表示されない現象があるようなら教えてもらえると助かります。
2007/07/11 21:11:00
Kahuaのオブジェクトデータベースを再設計するためにいろいろ調べて行く中で、Oracle(以前はSleepycat) Berkeley DBについても調べているのだけど、びっくりするくらい高機能であることを知った。実はBerkeley DBをまともに使ったのは、10年以上前が最後で、たぶん1.85とかそういうバージョンの頃なのだよね。いわゆるold dbmと大差ないくらいのものとして使ったことがあるだけ。その後、知識としては一応ハッシュもB-Treeも使えて、トランザクション機構もあるらしいくらいは知っていたのだけど、実はMVCCを実現していて、カーソルが使えて、セカンダリデータベース(インデックスオブジェクトのようなもの)やジョインカーソルなんてものまで使えて、レプリケーションまでできるらしい。まったく、RDBMSと見まごうばかりの高機能ぶり。恐れ入りました。
;; AllegroCacheが当初はBerkeley DB上に構築されていたというのもわかるような気がした。
2007/07/09 10:23:00
shiroさんのところより「チームでの集中」。見出しではないのでアンカーしづらいな(笑)。チームプレイが苦手なおいらはどちらかというとconcentrationという価値の方に重きを置くから、集中したい時はヘッドフォンかけて話しかけられても無視するクチだね。以前の職場では、パーティションごしに話かけられることが非常に多くて(立場上仕方なかったのかもしれない)、若気の至りで「くだらない話だったらコロすぞ」と凄んで、えらい問題になったりした(凄んだ相手が上司だったのだ)。今だったらさすがにもうちょっと紳士的に振る舞う。今の職場はそういう類いの割り込みはほぼないので、そういう意味では快適だ。
ところで、communication大事、というのは非常によく言われることなのだけど(ある種の金科玉条と化している)、会話だけがcommunicationじゃないだろ、と思う。メールやチャットや、というくだらない話ではなくて、話しかける前に相手の雰囲気を察する(今この用事で話しかけてよい雰囲気か読み取る)ことも含めてcommunicationなわけですよ。ぐぐれば3秒でわかりそうなことを、人が集中の極みにあるのを妨げてまで問いかけるような振る舞いをcommunicationとは言わないんじゃない? 相手の時間を自分のために割いてもらうだけの価値が自分の話にあるのか自問するところから始めて欲しいもんだと思う。
ちなみに、最近は本気で集中したい仕事は自宅で早朝にやることにしている。これなら理想的な環境で割り込みなしでできるからね。オフィスはそういう作業には向かないものだと割り切ったわけですな。
2007/07/08 06:16:00
Karettaが吐くRSSのdesciptionは、エスケープもせずに生でHTMLの断片を埋め込んでいた。昨夜それが修正されて、きちんとエスケープされるようになったのだが、そのおかげで今は
kahua-webのrss-includeのdescriptionの扱いが手抜きであることが露見してしまった。タグを含むテキストもそのまま表示してしまうので、結果的にタグをエスケープした状態で表示されてしまうのだ。この影響で、今朝方まで4時間ほど、LL魂のブログページの表示がおかしなことになっていた。
仕方がないので、desciptionのcontentをパーズして、パーズできたらその結果を、だめだっ
たらそのままをテキストとして表示するようにした。今は正常に機能していると思う。
うーん。rss-includeはもともときわめてやっつけ色の濃い代物で、シンプルなのが取り柄だったのだけど、すっかり老舗の日本旅館みたいな風情になってきた。そろそろ抜本的に見直さないといかんかも。
2007/07/07 16:47:00
matzにっき経由で知ったholeless cache。正直どこらへんがストロングポイントなのかよくわからない。コメントでも指摘されているけど、普通あるファイルをバックアップを取りつつ安全に書き換える時のオーソドックスな手法って(UNIX系OSというかファイルシステムの場合ね)、
(begin
(sys-link current-file old-file)
(receive (out new-file) (sys-mktemp a-tmpl)
(write something out)
(close-output-port out)
(sys-rename new-file current-file)))
ってな感じになるんじゃないのかなぁ。キャッシュをこれで書き換えるのと、holeless cacheと呼ばれている手法との間でパフォーマンスの差が大きくあるとは思えないのだけど(実際にはもちろん実験してみない限りわからない)。
2007/07/06 10:02:00
2つのサイトでfull-descriptionなRSSを配信するようにしてわかったのは、descriptionのないRSSはクソだということ。情報量がまるっきり違う。当たり前のことだけど、よそのサイトのRSSではなく自サイトで運用してみないと実感できなかったのだ。ただ、full-descriptionも善し悪しで、LL魂サイトやKHeadのようなサイトの場合、1ページの分量を勘案すると、ほぼ配信最初の1〜2エントリくらいしか見てもらえないだろう。もうちょっと各ページをコンパクトにするか、やはり変更の要約をdescriptionにした方がよいと思われる。やはり変更メモをdescriptionにすべきだろうか。悩むところだ。
2007/07/05 22:24:00
LL魂のサイトでもRSSにfull descriptionを含めるようにしてみた。もともとこの機能は、rss-includeしているブログ(LL魂ブログ)が更新されたら
自サイトのRSSも意味のある形で更新したいというのがモチベーションとなって付け加えたんですな。
2007/07/05 17:35:00
Kahua、kahua-webともに思わぬところにまで手を入れるハメになってしまったけど、とりあえずページコンテンツ全体(といってもmain-paneの中だけ)を含められるようになった。
KHeadにて運用中。
2007/07/04 23:36:00
結局、rss-include/rss-title/rss-date マクロに :rss-update? #t を渡すとそのサイト自身のRSSに反映されるという、何とも姑息な仕様に落ち着きそうだ。何だかなぁとは思うが、まぁ仕方あるない。
ところで、kahua-webのように、ページ(ドキュメント)ごとでしか更新情報が得られない場合、RSSのアイテムごとのdescriptionには何を入れるべきだろう。一応、フルコンテンツを含めては見たのだけど、さすがにちょっと1アイテムが長くなりすぎるきらいがある。kahua-webでは、更新時に1行メモをつけることができて、それは履歴情報を参照する際に表示されるのだが、これをRSSのdescriptionに使うというのも悪くない手だと思う。
2007/07/04 11:37:00
うーん。ページデータの処理の際、「現在のページ」というコンテキスト情報を使用するのだが、これとRSSを生成する処理との相性がよろしくない。RSSはページじゃないので。
どうしたものだろうか。
2007/07/04 11:25:00
すっかり話がMixじゃなくなってるが... 静的コンテンツへの書き出しのタイミングをどうしようか。現状はページを保存した時にいっしょにRSSファイルも更新しているのだが。うーむ。
2007/07/04 10:12:00
別に混ぜなくてもいいことに気づいた。要はrss-includeしたRSSが更新されていたら、rss-includeしているページを自分のところのRSSに登録すればいい。ついでに、RSSにdescriptionを含めれば問題なかろう。
そうしようそうしよう。
2007/07/04 08:52:00
ある人から、kahua-webのrss-includeで読み込んでいるRSSの内容を自サイトのRSSに混ぜ込めないかという要望が出た。いろいろ考えてみるがなかなか整合性の取れる仕様を思いつかない。kahua-webはコンテンツをページ単位でしか扱ってないけど、rss-includeされたRSSの各itemは1つのページの中にぶちまけられちゃうからね。
うーん。どうしたものか。思案中。
2007/07/01 22:21:00
ちょっと遅れてしまったけれど、Kahua-1.0.5をリリースした。特にメモリキャッシュの不整合問題や、インデックス値の変更を他のワーカが検知できなかった問題などを修正しているので、アップグレード推奨だ。
これで、今度こそHEADの作業に集中できるといいな。そうできるくらいには安定してくれたと思っている。
