Heimdallr 1.04alpha3をリリースします。
安定版ではありません。
Heimdallr 1.04alpha3
安定版はHeimdallr 1.03です。
変更点は以下の通りです。
既読ボタンの大きさ変更機能はさらに次のバージョンに持ち越しになりました。
Heimdallr 1.03から比べて、GUI周り（色変更対応のため）とファイルダウンロード周り（記事更新時間短縮のため）というHeimdallrの中核をなす機能のうち2つに大きな変更が行われました。
うまく動くかどうか結構心配です。
不具合を見つけたり、新しい機能に対する意見がありましたら、コメントお願いいたします。
ちょっと前の話ですが、RSSリーダーがインターネット渋滞の元凶になるという記事がHotWiredに掲載されていました。
HeimdallrというRSSリーダーを開発している身にとって、他人事ではないので、ちょっと考えてみることにしました。
今のHeimdallrは、上記記事にあるような
RSSリーダーは通常、前回のアクセス時以降、RSSファイルが更新されたかどうかをチェックする仕組みになっている。もし更新がなかった場合、ウェブサイトは「no」(なし)というごく小さなメッセージをRSSリーダーに返す。
というようにはまったくなっていません。
記事の更新を行う際、毎回コンテンツを全部ダウンロードしています。
いやぁHeimdallrは素行の悪いRSSリーダーですね。
RSS Feedって画像やらなんやらの重たいコンテンツが含まれていないので
取得回数が多くても平気だと思っていました。
しかし、現実に問題が発生しているサイトがある以上、無視するわけにもいかないでしょう。
といっても、実際の所、Heimdallrは、更新間隔は30分以下には設定できないようにしてありますし、
デフォルトの更新間隔は60分となっていますし、
なによりマイナーなので使用者が少ないため、
問題を引き起こす可能性は少ないでしょう。
しかし、Heimdallrがもし爆発的に普及すると（ありえなさそうですが）、
Heimdallrのせいでサイトが落ちたとか言われかねません。
そこで、上記の仕様のとおりに実装し、サーバーに大きなコンテンツを要求する回数を減らすようにしようと思いました。
ところが、技術的にどう実装すれば良いのか良く分かりません。特に分からないのがこれ。
ウェブサイトは「no」(なし)というごく小さなメッセージをRSSリーダーに返す。
これってどうやればいいんだろう・・・。誰か何かご存知でしたら教えて下さい。
良く分からないので、ちょっと考えた挙句、以下のような仕様にすることにしました。
実は、現時点でほぼ実装が終わってテスト中です。
サーバーへの負荷がどうなったのかは良く分かりませんが、更新するのに必要な時間がだいぶ短くなりました。感覚的には1/3以下ですね。
次のバージョンであるHeimdallr 1.04alpha3ではこの機能をお披露目できると思います。
このサイトではいくつかのソフトウェアを公開していますが、
バイナリだけでなく、ソースコードも一緒に公開しています。
ソースコード公開には、そんな深い意図があるわけではなく、
ここで公開しているソフトウェアのある機能を見て、どうやって実装するのかな？と思った人が、ああなるほど、と参考にするため、という程度のものです。
コード自体はあまり綺麗なものではなく、例えば、一番新しいHeimdallrでさえ、
開発途中から新しいライブラリ(boostライブラリ)を導入したので、
それより前のコードと後のコードではだいぶ書き方が違います。
コーディング規約も、時々変えているので、
コードによっては古いコーディング規約と新しいコーディング規約が混ざって理解し難かったりします。
しかも、恐ろしいことに公開されているソースコードにはライセンスに関するドキュメントがありません。
ですので、今のところこのソースコードの扱いは、デフォルトのライセンス、すなわち法律に従うことになります。
私は法律に詳しくは無いので、法律に従うとすると、どのような扱いになるのかは、よく分かりません（ヒドイ話ですね）。
何か要望があったり問題があったりしたら、BSD修正ライセンスあたりをベースにライセンスドキュメントを付加しようと思いますが、今のところ要望や問題どころか質問さえありませんので、まあこのまま何もしないで良いかな。と。
Heimdallr 1.04alpha2をリリースします。
安定版ではありません。
Heimdallr 1.04alpha2
安定版はHeimdallr 1.03です。
Heimdallr 1.04alpha2では、設定ファイルの形式が変わりました。
内部で新しい形式に勝手に変換するので、ただ使うだけならば意識する必要がありませんが、
古いバージョンに戻してしまうと正常には動かなくなります。
つまり、Heimdallr 1.04alpha2を実行してしまうと、もう古いバージョンへの後戻りは効かなくなります。
安全をお求めの方は、設定ファイルのバックアップを取っておくと良いでしょう。
マイドキュメント\SutoSoft\Heimdallrフォルダを丸ごとどこかへコピーしておけばOKです。
機能面の変更点は、
という2点です。
色設定を変更するためのユーザインターフェースはあまり良いものではありませんが、
追々機能を向上させて行きたいと思います。
あとはビューのGUI周りのコードをかなり書き換えています。
そのため単純な操作でも色々とバグあるかもしれません。
何か気が付いたら報告して頂ければ幸いです。
既読ボタンサイズの変更オプションと、Ctrl+クリックによる既読化機能は、
次のバージョンである1.04alpha3で実装する予定です。
RSSリーダーの開発なんぞをやっていると、数ある他のRSSリーダーと比べてどうなのか、というあたりがやっぱり気になります。
そこで、HeimdallrのライバルとなるRSSリーダーと、Heimdallrの人気を比較をしてみたいと思います。
といっても、機能などの違いを日本語で説明しても、主観が入りまくって歪んだ結果になると思いますので、
できる限り主観が入らない方法で比較してみることにします。
まずは、Heimdallrのライバルと考えているRSSリーダーを列挙します。
対象となるのは、デスクトップに常時張り付いて情報を表示し続けるいわゆるティッカータイプのRSSリーダーです。
ココログのRSSリーダーリンク集によると、ティッカータイプのものはHeimdallrを除き以下の3つです。
比較方法として、次の2つの方法を用意しました。
計測日時は2004/05/25の0時です。
| ソフトウェア名 | Googleヒット数 | Vector順位(日付) |
| Rabbit Ticker | 239 | 6(2004/01/27) |
| Headline-Deskbar | 130 | 9(2004/05/02) |
| パラボラミニ | 73 | 登録無し |
| Heimdallr | 43 | 14(2004/05/08) |
とりあえず結論。
現状ではRabbit Tickerが一番人気があるようです。
しかし、Headline-Deskbarは、最近公開された割には人気がとても高いので、勢いがあるようです。
肝心のHeimdallrはどうなのかって？うーん。とりあえずビリですね。Mostマイナー賞です（いらねー）。
というわけで悲しいながらHeimdallrの人気は大したものではありません。
恐らく、他のRSSリーダー開発者からはライバルと思われていないでしょう。ライバルと思っているのはこちらだけだと思われます。
ああ、なんて悲しすぎる結論なんだ・・・
本サイトを訪れた人の中には、Vectorの作者紹介ページから来た人が大勢いると思いますが、
本サイトで公開しているのは今のところHeimdallrとLancasterだけです。
Ray Fighter、断面Golf、DogFight、SBookは本サイトでは公開しておりません。
というのも、現在開発Ready状態（いつでも要望に応えて機能追加やバグ修正ができる状態）にあるのはHeimdallrとLancasterだけだからです。
他のソフトウェアは、現在開発Suspend状態（機能追加やバグ修正をするためにいくつのも作業が必要であり、すぐには何もできない状態）です。
Ray Fighterと断面Golfは、何世代か前の古い開発環境及び古い技術で作られたものであり、これから改良するのは大変ですが、
SBookとDogFightは、一つ前の開発環境で作られたものなので、
開発Ready状態にするのはそれほど大変ではありません。
ですので、SBookとDogFightについては、要望があれば開発Ready状態にした上、
本サイトで公開したいと思います。要望が無ければ今のまま開発Suspend状態です。
さて、私はHeimdallrというソフトウェアを開発しています。
ここで、改めてHeimdallrの最大の特徴について考えてみたいと思います。
作者だったら最大の特徴なんて把握していると思われるかもしれませんが、
意外と作者でも分かってないものです。
私は、最初Heimdallrの最大の特徴は、記事のタイトル確認から概要確認、全文確認までが
少ない操作でスムーズにできることだと思っていました。
しかし雑誌での紹介文などを読むと、
どうやら、
マルチウィンドウ
の方が最大の特徴と言われることが多いようです。
良く考えると、記事一覧を表示するためのウィンドウをいくらでも増やせるRSSリーダーって
あまり無いようです。
開発当初は、ジャンル分けくらいには利用できるかな、と言う感じで
マルチウィンドウ機能を実装したのですが、
最近は、分かりやすいジャンル分けができるというということは結構重要なのではないかという気がしてきました。
ソフトウェアが作者の思惑と違うところで評価されるのもそれはそれで結構楽しいです。
まあそもそもHeimdallrは月間ダウンロード数500位のマイナーRSSリーダーなので
評価されていると言って良いのかどうかは良く分かりませんけどね。
このサイトは、各ページ毎にアクセスカウンタが付いていて、
どのコンテンツが一番人気があるのか分かるようになっています。
現在一番人気があるコンテンツは、作品集のHeimdallrです。
アクセス数がトップページの半分以上あり、このサイトを訪れた人の半分以上がHeimdallr目当てであることが分かります。
良く考えて見ると、このサイトでもっとも独自性のあるコンテンツって、ソフトウェアなんですよね。
開発日記やらなんやらも、それなりに頑張って書いているのですが、そもそも私に独自性がある文章を書く力が無いため、ソフトウェア以外のコンテンツは、やっぱり（残念ながら）似たようなものがあちこちにあります。
結局の所、こういうことですか。
ソフトウェア開発者はソフトウェアでものを語れと。
壁紙に張り付くようなウィンドウの作り方です。
最初に、ウィンドウクラスCXxxWndにWM_WINDOWPOSCHANGINGの メッセージハンドラを追加します。
次に、メッセージハンドラの内容を以下のように記述します。
void CXxxWnd::OnWindowPosChanging(WINDOWPOS* lpwndpos)
{
CXxxWnd::OnWindowPosChanging(lpwndpos);
lpwndpos->hwndInsertAfter = HWND_BOTTOM;
}
以上で完了です。
Heimdallr 1.04alpha1をリリースします。
安定版ではありません。
Heimdallr 1.04alpha1
安定版はHeimdallr 1.03です。
1.04alpha1では、1.04の目玉機能である既読ボタンを実装してみました。
デザインは置いておいて、とりあえず機能面でのコメントを頂ければ幸いです。
細かいコメントも歓迎します。
既読ボタンの使い方は2つあります。
最近、VisualSourceSafe(以下VSS)の分岐機能とマージ機能を使ってみました。 これらの機能を使った感想や、うまく使うコツを書いてみたいと思います。
分岐とマージは、ソースコード管理の世界では一般的な単語だと思いますので 説明は省略します。
過去のバージョンからの分岐。
VSSエクスプローラーから分岐させたいプロジェクトを選択し、メニューから以下の通りに操作します。
プロジェクトの履歴→分岐するバージョンのラベルを選択→共有→共有後に分岐をチェック
→適当なプロジェクトを選択（分岐するプロジェクトの親プロジェクトが良い）→新しい名前を適当に選択（プロジェクト名＋分岐時点のラベル名が良い）
「共有後に分岐」のチェックを忘れた場合は、後で分岐しておきましょう。
分岐できたら、分岐したファイルを編集してバグ修正や新機能の追加を行います。 編集が完了したらチェックインしておきましょう。
ビジュアルマージのOFF。
マージを行う前に、コンフリクトの発生に備えます。
VSSは、GUIでコンフリクトの解消が行えるビジュアルマージというツールを用意してくれています。
しかし、コンフリクトの解消というのは開発者が一行一行チェックして行わないとうまく行かない微妙な作業であるのに対し、ビジュアルマージは、分岐元のコードを取り込むか、分岐先のコードを取り込むか、両方のコードを取り込むか、などといった大雑把な選択しかできません。
そのためちょっと使い物にならないので、ビジュアルマージを使用せず手動でコンフリクトの解消を行うことをお勧めします。ビジュアルマージはメニューから以下の操作を行うことによりOFFにできます。
ツール→オプション→全般→ビジュアルマージの使用→いいえ
分岐先のソースの分岐元へのマージ。
次に分岐元を編集して分岐先に加えた変更を取り込みます。
最初に、分岐元のソースを全部チェックインしておきましょう。 マージ直前ということでラベルを設定しても良いです。
次に、分岐先でどのファイルを編集したのか確認しましょう。 編集したファイル名を全て覚えていれば良いのですが、全部は覚えていない場合、 分岐先のプロジェクトの履歴を見て、レポートをファイルかクリップボードに出力しておくと良いでしょう。
次に、先ほどのレポートに記述されているファイル一つ一つに対し、
VSS上で分岐元のファイルを選択し（分岐先のファイルではありません。分岐元です）、以下の操作を行いマージします。
ソースコード管理→分岐ファイルのマージ →分岐先プロジェクト選択→マージ
分岐ファイルのマージはファイル一個ずつ行なうしかないようです。
ファイルがたくさんある場合はどのファイルをマージするべきか分かり難く大変ですが、
先ほど出力したレポートを見つつ一つずつマージしていきましょう。
マージした際、「コンフリクトのない状態でマージされました。ここでチェックインしますか ?」というメッセージが表示されてそのままチェックインできることがありますが、
ここではチェックインせず、「いいえ」と答えてチェックアウト状態のままにしておきましょう。
これは、VSSが自動的に結合を行った結果、特に問題なく結合できたということを意味していますが、VSSはプログラミング言語を解釈した上で結合したわけではないので、
VSSでは問題がなくても実際にコンパイルすると問題は山ほど出てきます。
そんな問題があるコードをチェックインしてはいけません。
さて、レポートに書いてあるファイルを全てマージしたとします。 その時点では、マージしたファイルは全てチェックアウト状態になっているはずです。 とりあえずビルドしてみましょう。 コンパイルエラーがわんさか出てくるはずですので泣きながら地道に潰していきましょう。
場合によっては、ソースコード中に次のような文字列が挿入されていることがあります。
<<<<<<< ======= >>>>>>>
これはコンフリクトマーカーと呼ばれるもので、 コンフリクトが発生してVSSがうまく結合できなかったことを示しています。 このマーカーがある周辺は、特に注意しながら修正してきましょう。
なお、マージ直前のコードは拡張子orgとなって残されているので オリジナルコードを見たいときには参照しましょう。
コンパイルエラーが全てなくなったら、テストの1つでも行なった後チェックインしましょう。 このとき拡張子orgのファイルは削除されます。これでマージ作業は完了です。おめでとうございます。
アプリケーションの初期化シーケンスをもう一度走らせたい場合など、 アプリケーションが、自身を再起動させたいときがたまにあります。 それを実現する方法です。
手順は以下の通りです。
サンプルコードを載せておきます。
再起動を行う部分のコードは以下の通りです。
TCHAR strPath[MAX_PATH];
::GetModuleFileName(AfxGetInstanceHandle(), strPath, sizeof(strPath) / sizeof(TCHAR));
TCHAR strCurDir[MAX_PATH];
::GetCurrentDirectory(sizeof(strCurDir) / sizeof(TCHAR), strCurDir);
// 元プロセスのコマンドライン引数を継承する必要があるか検討して下さい。
DWORD dwProcessId = ::GetCurrentProcessId();
CString strCmdLine;
strCmdLine.Format("/waitterminate %u", dwProcessId);
::ShellExecute(NULL, NULL, strPath, strCmdLine, strCurDir, SW_SHOWNORMAL);
// アプリケーションを終了する。
AfxGetMainWnd()->SendMessage(WM_COMMAND, MAKEWPARAM(ID_APP_EXIT, 0), NULL);
CXxxApp::InitInstanceに以下のコードを追加します。
BOOL CXxxApp::InitInstance()
{
bool bWaitTerminate = false;
DWORD dwWaitProcessId;
for (int i = 1; i < __argc; ++i) {
if (!(__argv[i][0] == '/' || __argv[i][0] == '-')) {
continue;
}
if (_tcsicmp(&__argv[i][1], "waitterminate") == 0) {
if (++i >= __argc) {
continue;
}
dwWaitProcessId = static_cast(_ttoi(__argv[i]));
if (dwWaitProcessId != 0) {
bWaitTerminate = true;
}
}
}
if (bWaitTerminate) {
HANDLE hWaitProcess = ::OpenProcess(SYNCHRONIZE, FALSE, dwWaitProcessId);
if (hWaitProcess != NULL) {
// 10秒待っても前のプロセスが終了しない場合は、アプリケーションを終了します。
if (::WaitForSingleObject(hWaitProcess, 10 * 1000) == WAIT_TIMEOUT) {
return FALSE;
}
}
}
// CXxxApp::InitInstanceの残りの処理を行う。
}
アイデアそのものはMFCに依存していないので、
ちょっと変更すればMFCを使わなくても実現できると思います。
無事にHeimdallr 1.03がリリースできたので、
1.04以降をどうするのか考えてみます。
現状、Heimdallrには大きく分けて次の二つの課題があります。
1.04では、後者の課題を解決したいと思います。
前者も、背景色の変更位はやりたいですが、できるかどうかは分かりません。
上記したことと重なりますが、現状の細かい要望リストを載せておきます。
上に書いてあるものから優先的に実装していきます。上からいくつか実装した時点でバージョン1.04としてリリースします。
実装する際の難易度を難、普、易の三段階で評価し、効果を大、中、小の三段階で評価します。
バージョンアップをすればするほど重たい要望だけが残るようになりますねー。
しばらく前、ニュース記事の見出しをネット上で無断配信され著作権を侵害されたとして、読売新聞東京本社がデジタルアライアンスを訴え、敗訴したという話がありました。
記事の見出しを扱うRSSリーダー(Heimdallr)を開発している私にとっては、見出しに著作権が無ければ色々なしがらみが無くなり楽になる言うこともできるのですが、敗訴したのは、正直、残念です。
というもの、適切な見出しを考えるのはとても大変なのです。ですので、私は適切な見出しを考えた人にはしかるべき敬意を払うべきだと思っています。
見出しに著作権が無いという判決には、見出しを考えた人への敬意が全然感じられません。
しっかりと仕事をした人にしっかりと敬意が払われないと、手抜き作業が蔓延するようになります。
その結果、世の中から適切な見出しが少なくなっていくのではないかと心配しております。
がんばれ読売。
Lancaster 1.03をリリースします。
安定版です。
Lancaster 1.03
Lancaster 1.03ソースコード(Visual C++.NET 2003用)
変更点は以下の通りです。
Lancasterは、LANで接続された複数のWindowsマシンでチャットを行うためのソフトウェアです。
以下のページからダウンロードできます。
Lancasterリリース
以下のような場所で使うことをお勧めします。
Lancasterは以下のような特徴があります。
なお、以下のようなことはできませんので注意して下さい。
ちょっと昔に作ったものですが、要望がありましたので紹介記事を復活させます。
試しにWeblogでソフトウェアのリリースをしてみます。
Heimdallr 1.03をリリースします。
安定版です。
Heimdallr 1.03
Heimdallr 1.03ソースコード(Visual C++.NET 2003用)
変更点は以下の通りです。
私はHeimdallrというRSSリーダーを開発しています。こういうものを開発していると、
さまざまなRSS Feedを見かける機会があるのですが、結構、不適切なRSS Feedがあります。
不適切なRSS Feedとは、RSS Feed提供者が提供したいと思っている情報と、
RSS規格を厳密に適用して解釈した結果とが食い違っているRSS Feedのことです。
例えば、こんなRSS Feedを見かけました。
一応前もって言い訳しておきますが、もしかしたら私が勘違いしているだけで上記のRSS Feedは適切なのかもしれません。
しかしここは不適切であるとして話を進めます。
こうしたRSS Feedに対し、RSSリーダーはどう振舞うべきか。それはとても難しい問題です。
RSSに限らず、不適切なデータに対し、どのように振舞うべきか、という問題は昔からあります。
例えば、Webブラウザ開発においても、不適切なHTMLファイルに対してどう振舞うべきか、と悩んだことがあったと思います。
どう振舞うか、といっても実際のところ方針の選択肢は2つしかありません。
現状、Heimdallrは、前者の方針で解釈してます。私は、世の中のRSSリーダーはすべて前者の方針で解釈するべきだと思っています。
そうすれば、不適切なRSS Feedは、すぐに不適切なRSS Feedであることが判明し、提供者が修正します。これにより、世の中から不適切なRSS Feedがなくなります。
しかし、現実には後者の方針で解釈しているRSSリーダーが既に存在します。例えば、InfoMaker様が提供するHeadline-Readerです。
Headline-Readerは、RSS Feedをフランクに解釈しているらしく、
上記したような不適切なRSS Feedからもしっかり情報を読み取ってくれます。
Headline-ReaderのユーザはHeimdallrのユーザよりも遥かに多いため、(桁が2つ以上違う)、Headline-ReaderでRSS Feedを解釈できるかどうかだけしか
確認していないRSS Feed提供者は大勢いるでしょう。そういうRSS Feed提供者は、RSS Feedに潜む問題を発見できないわけです。
また、後者の方針も、多くのRSS Feedが解釈でき、多くの情報を得ることができるという利用者側の利点があるため、簡単に否定することもできません。
また、RSSには多くのバージョンがあり、それぞれのバージョンを厳密に解釈するのは難しいという開発側の問題もあります。
つまりは、どちらの方針も利点欠点が色々あり、さらにはRSS自身が抱えている問題もあって状況は複雑になっています。
どちらの方針が良いのか考えても結論はでないので、RSSの世界が、技術面から見て、これからどのように進めば理想的か、というのを考えてみます。
まず最初に、山ほどある今のRSSの仕様を統一した仕様を策定します。
次に、統一RSS仕様に準拠しているかどうかを検証する検証ソフトを普及させます。
次に、統一RSS仕様に準拠したデータをどのように解釈し、どのように振舞うべきかを定めたRSSリーダーの仕様を策定します。
最後に、RSSリーダーの仕様に準拠したRSSリーダーを開発し、普及させます。
しかしまあこんな感じでうまく進むことは無いと思います。
RSSは、大勢の人がそれなりの思惑をもって関わっていますので、
そう簡単に統一仕様が決まるとは思えません。ましてやRSSリーダーの仕様なんて誰も決められないでしょう。
いやはや世の中難しいですねぇ。
ちょっと便利なVisualSourceSafeの小技集です。
キーワード展開。
以下のようなキーワードをソースコード中に含めておくと、
VisualSourceSafe(以下VSS)がログなど色々なテキストを追記してくれます。
/* * $Log: $ */
但し、VSSアドミニストレータを起動して、「オプション→全般→キーワードを展開するファイルの種類」に、 「*.cpp;*.h」のようにキーワード展開するファイルの種類を指定する必要があります。 Log以外にも色々なキーワードがあります。詳細はVSSのヘルプを見て下さい。
プロジェクト名の変更やプロジェクトの移動。
VSSエクスプローラーからプロジェクトを選択して「ファイル→移動」や「ファイル→名前の変更」で変更や移動が行えます。
間違えたプロジェクト名をつけたからといっても諦めないで下さい。
ラベル名の変更。
「プロジェクトの履歴→ラベルが設定されたバージョンを選択→詳細情報」からラベル名の変更や削除ができるようです。
ラベル名を間違えても泣くことはありません。さくさく修正してしまいましょう。
プロジェクトのクローク。
「プロジェクトを選択→プロパティ→クロークプロジェクトをON」とすることにより、
プロジェクトをクロークにすることができます。クロークになったプロジェクトは、「最新バージョンの取得」や「チェックアウト」処理を
再帰的に行ったとき、操作の対象から外れます。
私は、自分に著作権が無いソースコードは適当な名前のサブプロジェクトに格納し、そのサブプロジェクトをクロークにすることにより、
ソースコードを公開したときに自分に著作権が無いソースコードまで公開されないようにしています。
Heimdallrは、壁紙のようにデスクトップに貼り付けることができるRSSリーダーです。
以下のページからダウンロードできます。
Heimdallrリリース
機能は以下のとおりです。
こんな方にお勧めです。
以上、宣伝させて頂きました。
パラボラミニやRabbit Tickerに匹敵するくらいの出来には仕上がっていると思います。
ディスプレイとにらめっこして仕事をしている方にはお勧めの一品です。
はじめまして。
ここは、MASATOがソフトウェア開発を行ったときに色々と感じたことなどを
書いたWeblogです。
このWeblogの目的は以下の通りです。
古い開発日記は下記のURLにあります。
http://www.sutosoft.com/oldroom/devdiary/
WeblogはMovableTypeを使って書いています。
まずはMovableTypeをインストールしてみた感想を書いてみます。
第一印象は、インストールが簡単だなぁ、ということです。
パーミッション等が設定されたUNIX用アーカイブファイルが提供されているのも便利ですし、
初期化を行ってくれるCGIスクリプトが用意されているのも便利です。
インストール手順が書かれたドキュメントも分かりやすかったですし、
夫々のCGIがエラーメッセージを分かりやすく表示してくれたのも良かったです（エラーが発生するとInternal Server Errorとしか表示しないCGIスクリプトの多いこと多いこと・・・）。
日本語化パッチの説明も分かりやすく、普通ならば色々とトラブルが発生するはずの
インストール＆パッチ宛作業が、ほとんどトラブル無しで行えました。
いやーCGIパッケージはこうありたいものですね。