とりあえずNP_CommnetContorol + NP_Blacklistの環境を、NP_SpamCheck + NP_Moderate + NP_MultiRBLに載せ変えてみることにしました。

† 結局、とりやめ

結論を先に書いておきますが、僕は現在のところ移行は取りやめることにしました。機能的にもまだNP_CommentControl + NP_BlacklistのほうがNP_SpamCheck+その他よりも優れているみたいなので。

以下が導入の手順と感じたことです。

† 1.NP_CommnetContorol と NP_Blacklistをアンインストール

[BETA] NP_Moderate: comment moderation, NP_Akismet: antispam

Warning: for now you must uninstall BlackList, CommentControl and SpamCheck plugins before using this plugin!!!

フォーラムの注意書きにNP_SpamCheckを入れる前に、NP_CommnetContorol と NP_Blacklistをアンインストールしろとあるので、まずこれらをアンインストール。

† 2.NP_SpamCheck + NP_Moderate + NP_MultiRBL

NP_SpamCheckをウェブからcopy/pasteしてサーバにインストール。その後、同様にNP_Moderate + NP_MultiRBLについてもインストール。ここまでは何のエラーもなく完了できます。

† 3.動作チェック

NP_SpamCheckはphp4.4.0/5.0.5からの埋め込み定数参照の仕様変更に対応していないようなので、このあたりのエラーを修正しないと動作させることができませんでした。

NP_Moderateについては、languageファイルを作らないと日本語版を使っている場合には管理画面に表示がされないのでそのあたりにも注意が必要です。でも、スキン中Moderateを待っているコメントがあるかどうかを表示できなかったりと、まだまだ荒削りな感じです。

やっぱりまだ時期尚早な印象がぬぐえません。

† 際立つ、作り手の都合

NP_SpamCheckっていうのは、キッチンシンクアプローチで肥大化したNP_Blacklistを分割再構成しようっていうプロジェクトなんでしょうけど、なんかイマイチですね。それによって利用者が得られるメリットがなさ過ぎるんじゃないかと。

確かにソフトウェア的な美しさを追求するのであれば、そのほうがHigh Cohesion^*1でLow Coupling^*2なプログラムを実現できるわけです。簡単に言えば、プラグインの変更や拡張が容易になりバグが出にくくなる構造になるということです。でも、ちょっと還元主義的な考え方をしすぎ（かつ、還元した結果にユーザビリティの視点が抜けている）なんじゃないかと。

それとNucleusではよくあることですが、機能が多くなってくると複数人での開発体制になるのですが、コードの共有環境がないので実質的にはプロジェクトをフォークしたような状況になってしまうことがあるのですが、それを防ぐことができるというのが大きいのかなとも思います。

このあたりはプラグインの開発の中心となるCVSなんかを作って、そこでみんな作業するみたいな形になればいいだけなのかもしれないですけど。でも、Nucleus関連のかたがたでCVS使っている人は少ないようですし、誰がコミッタになるとか調整はなかなか大変そう。

† 参考

＠IT：連載：.NETで始めるデザインパターン　第2回 うまくデザインパターンを使うための心得

凝集度とは、個々の部品内の機能的な結び付きの尺度である。例えば1つの部品が、互いに関連のある機能だけで構成されていれば、凝集度が高くなり、部品が持つ役割や意図が明確になる。逆に関連のない機能の寄せ集めで部品が構成されていれば、理解しにくく、要求の変更にも対処しづらいものとなる。

結合度とは、個々の部品間での結び付きの尺度である。ここでの結び付きとは、部品間の物理的、意味的な関連のことである。例えば2つの部品が強く関連し合っていると、結合度は高くなり、片方を変更すればその影響が他方にも及び、両方を変更せざるをえなくなる。そこで、ソフトウェアを構成する部品は、互いに低い結合度で関連し合っていることが望ましいとされるのである。

• ^*1: 高凝集度
• ^*2: 低結合度