OpenMiner已經成為了sourceforge的apPRoval項目。與此同時，我們也開始緊張地對OpenMiner進行了一系列的外科手術。我現在做的主要是服務器部分的裁剪，盡量把OpenMiner的核心做得更加簡單，更加具有擴展性。而OpenMiner現在還沒有可視化的客戶端，另外一個同學grand現在也開始加緊趕制OpenMiner的客戶端，我們的客戶端打算仿造Yale.

    首先的第一個手術就是減掉闌尾。 之前在給教務處做決策系統的時候，為了趕進度，OpenMiner過于依靠了Oracle數據庫，各種數據集的提取，以及挖掘模型的存取，都是基于Oracle的JDBC來訪問的。而Oracle的JDBC非凡是在處理BLOB數據塊的時候，又和標準的JDBC不兼容，于是搞得代碼很不具備通用性。現在的OpenMiner，不僅是需要對ORACLE的很好支持，同時還要能夠對各個方面的數據集進行很好的訪問，當然，練習數據集都是只讀，也就是OLAP.作為一個數據分析，我希望設計處理的服務程序不僅能夠從數據庫中提取數據，還希望能夠從各種文件格式（Excel， xml，等），以及遠程的Socket輸入流來獲取練習數據集。減掉了舊的Oracle處理模塊后，需要新增加的就是一個比較齊全的輸入數據抽象層了。采用設計模式中的抽象工廠Abstract Factory的方式來實現。這樣，對于數據挖掘的算法模塊來說，就只有一個InputDataSet輸入數據集的接口，練習數據就只能從這里面來提取，根本不用去理會這個InputDataSet是一個什么樣的數據來源和怎么樣創建的。于是乎，文件數據，數據庫數據，Socket流輸入數據，就能很好地統一到InputDataSet接口下了。

    其次，關于使用挖掘模型的接口函數，統統從Miner類刪除。因為如何使用一個挖掘完成的模型，是根據應用程序application來決定的。假如OpenMiner來做，并不見得做得能用，而且，使用一個模型的方法千變萬化，OpenMiner做起來也麻煩，于是，最好的辦法就是，不做，統統刪除！

    最后，我考慮將挖掘模型的存儲訪問治理，放在客戶端來進行。原因很簡單，OpenMiner就只做Data Mining的工作，不做Data Mining以外的任何工作。這里所謂的客戶端，并不一定就是用戶實用的客戶端，也可能是應用系統，只是從OpenMiner服務提供者來說的客戶端的意思。如何治理挖掘模型Model這個問題，本身并不能輕率，因為現實企業應用系統中，可能挖掘模型數量成百上千，如此龐大的挖掘結果模型，一般的文件系統并不見得高效，而應該放在數據庫的，針對各種數據庫的訪問，那么就成了一個問題。同時，挖掘模型也可能存在安全性的問題。要讓OpenMiner去這樣復雜的一項工作，很難做得好。既然做不好，最好的辦法就是，不做，統統刪除。

    做了這些過后，OpenMiner的核心服務器的手術基本上可以算完成了。剩下的就是客戶端的事情了。我們現在的這個客戶端功能很大，把以前本該是服務器做的模型治理的工作都移交到了客戶端來做，于是grand現在也忙起來。關于客戶端的開發，我推薦使用NetBeans 5.5RC1來開發。因為Eclipse的VE插件做得太老火了，經常出問題，而且又慢又兼容性也不好（3.1和3.2的VE都不兼容）。而NetBeans本身就自帶了可視化的界面開發功能，速度和穩定性都比Eclipse那種外部插件的好。雖然Eclipse一度成為IDE的典范，但是SUN的新秀NetBeans也有它不錯的有點。隨便說一下，NetBeans也是免費開源的，可以隨便下載。