org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set to 1024
    at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:165)
    at org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:156)
    at org.apache.lucene.search.PrefixQuery.rewrite(PrefixQuery.java:53)
    at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:408)
    at org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:138)
    at org.apache.lucene.search.Query.weight(Query.java:94)
    at org.apache.lucene.search.Hits.<init>(Hits.java:42)
    at org.apache.lucene.search.Searcher.search(Searcher.java:45)
    at org.apache.lucene.search.Searcher.search(Searcher.java:37)
    at com.toodou.searcher.search.PodcasterSearcher.searchPodcaster(PodcasterSearcher.java:238)
    at com.toodou.searcher.search.PodcasterSearcher.doPodcasterSearch(PodcasterSearcher.java:66)
    at test.com.toodou.searcher.search.PodcasterSearcherTest.testdoPodcasterSearch(PodcasterSearcherTest.java:57)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:585)
    at junit.framework.TestCase.runTest(TestCase.java:154)
    at junit.framework.TestCase.runBare(TestCase.java:127)
    at junit.framework.TestResult$1.protect(TestResult.java:106)
    at junit.framework.TestResult.runProtected(TestResult.java:124)
    at junit.framework.TestResult.run(TestResult.java:109)
    at junit.framework.TestCase.run(TestCase.java:118)
    at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

可以通過設(shè)置：
BooleanQuery.setMaxClauseCount(10000);
來解決問題，但是這樣帶來的問題是會使得內(nèi)存開銷加大。容易出現(xiàn)OutOfMemory的異常
所以需要非常謹慎處理。

查詢MySQL會出現(xiàn)："java.sql.SQLException: Server shutdown in progress"的異常

問題原因：數(shù)據(jù)有自動腳本，會將執(zhí)行時間超過30秒的進程殺掉。
這樣的話，Java的應(yīng)用就會拋出這樣的異常。

CAS Server 3.1 M2 Released

CAS Server and Client 3.1 Milestone 1 Released

phpCAS 0.5.0 RC5 Release

CAS 3.0.7 Final Release

Inclusion of Abstract Ticket Registry

CAS 3.0.6 Final

這里面有幾個更新很重要：
1.Upgrade to Spring 2.0.1, Spring Web Flow 1.0 and Spring LDAP 1.1.1

2.Introduction of JBossCacheTicketRegistry
    支持后JBossCacheTicketRegistry就可以方便大并發(fā)量的網(wǎng)站的水平擴展問題。

軟件過程方面

     我們team采用的軟件開發(fā)過程是借鑒了UP的迭代開發(fā)過程。堅持迭代的漸進式開發(fā)，每次迭代都是小步進行的，一般都是保持2周一次迭代。在開發(fā)過程中重視需求，要寫清楚UseCase描述，而不是僅僅畫出UseCase圖。測試也是我們非常重視的，包括了單元測試和集成測試。

 

軟件開發(fā)方法

     我們采用的是OO的設(shè)計和實現(xiàn)方法。通過一些開源框架的使用，提高效率和代碼的質(zhì)量。在設(shè)計的時候會用一些經(jīng)典的設(shè)計模式來優(yōu)化設(shè)計，為以后更好地滿足需求變動做好準備。單元測試是我們非常重視的，要求必須寫單元測試，而且要能夠覆蓋盡可能多的分支和邊界。

     我們團隊還會采用一些XP的開發(fā)實踐例如：TDD、重構(gòu)、CodeReview、結(jié)對編程、持續(xù)構(gòu)建，通過這些實踐卻是能夠極大提高代碼的質(zhì)量，進一步提高軟件產(chǎn)品的質(zhì)量。

 

軟件開發(fā)工具

     我們也非常重視工具的使用，使用工具來幫助我們更好的提高質(zhì)量，首先一定要有版本控制系統(tǒng)，可以使用CVS或者SVN。通過checkstyle這樣的工具可以幫助我們檢查代碼是否規(guī)范。通過findbugs這樣的工具幫助我們發(fā)現(xiàn)一些bug。使用一些自動化的測試工具，提高測試的效率和回歸測試的質(zhì)量。使用測試覆蓋率工具檢查單元測試的覆蓋率。我還會使用一些性能測試工具測試系統(tǒng)的性能，發(fā)現(xiàn)一些性能問題。

我主要結(jié)合項目管理的九大知識領(lǐng)域來說明，需要說明的是在我接觸的項目中，九個領(lǐng)域的內(nèi)容有一些沒有接觸過的我就略過。

 

范圍管理：

     首先會有產(chǎn)品經(jīng)理提出我們要開發(fā)一個什么樣的軟件，有那些功能，基本上就是一些FeatureList，然后給出vision and scope文檔。軟件開發(fā)的項目經(jīng)理會根據(jù)這份文檔，通過溝通，來寫出SRS。其中主要包括了UseCase和非功能性需求以及一些約束條件。有了這些內(nèi)容后，會開一個需求確認會，來確認已經(jīng)明確的需求，會議上可以對不明確的需求進行討論和完善。

 

時間管理：

     項目經(jīng)理在接到軟件項目開發(fā)任務(wù)后，就要制定出一個大致的項目計劃，然后有了軟件的需求文檔之后，可以進一步細化項目的計劃。在做項目計劃的時候同時會牽扯到任務(wù)的分工。在項目進行的過程中嚴格按照項目計劃進行。

 

采購管理

     項目的前期，項目經(jīng)理需要明確軟件安裝需要多少服務(wù)器，服務(wù)器的配置是什么樣的。什么時候必須到貨，預(yù)算的經(jīng)費是多少等。如果項目的人手不夠，同時要考慮進行軟件外包。

 

人力資源管理

     主要是提高團隊的士氣和凝聚力，讓每一位團隊成員都有清晰一致的目標，從生活等各個方面關(guān)心開發(fā)人員，幫助他們解決一些實實在在的問題。如果有軟件外包，還要統(tǒng)一得管理好外包的軟件開發(fā)人員。

 

溝通管理

     經(jīng)常開項目小組會議，保持信息暢通，通過wiki等工具保持信息共享。每天都有晨會，周報發(fā)給小組的所有成員。通過聚餐、喝茶等方式增進交流。針對不同的員工可能需要采用不同的方式，例如：有的人喜歡面對面的溝通，有的喜歡email溝通，有得喜歡msn等等。

 

風險管理

     我認為比較重要的是抓住開發(fā)過程的幾個環(huán)節(jié)，例如：需求分析、界面的設(shè)計、接口的設(shè)計、數(shù)據(jù)庫的設(shè)計等。每天項目經(jīng)理都要確認項目的進度是否正常，檢查項目的質(zhì)量，盡可能早的發(fā)現(xiàn)一些問題。經(jīng)常得跟產(chǎn)品經(jīng)理交流，確保開發(fā)的軟件產(chǎn)品符合需求。

 

成本管理

     對于我接觸的項目，牽扯到成本管理的主要就是開發(fā)人員的成本，分配好任務(wù)，把握住進度，提高開發(fā)團隊的效率就能夠為公司節(jié)省開支，從而達到控制成本的目的。

 

質(zhì)量管理

     我認為質(zhì)量管理應(yīng)該貫穿于整個的軟件開發(fā)過程中。比較典型的有，首先就是要保證SRS的質(zhì)量，只有需求的質(zhì)量控制住了，整個項目才有保障。軟件的編碼要規(guī)范，有詳細清楚的注釋，要求寫單元測試，定期的進行代碼review會議，要有集成測試和系統(tǒng)測試。對于我們的互聯(lián)網(wǎng)產(chǎn)品，由于產(chǎn)品環(huán)境比較復(fù)雜，所以一定要有相應(yīng)的系統(tǒng)測試，也可以稱為線上測試。

診斷 Java 代碼: 輕松掌握 Java 泛型

診斷 Java 代碼: 輕松掌握 Java 泛型類型，第 2 部分

診斷 Java 代碼: 輕松掌握 Java 泛型，第 3 部分

診斷 Java 代碼: 輕松掌握 Java 泛型，第 4 部分

Java 理論和實踐: 了解泛型

多角度看 Java 中的泛型

Eclipse V3.1 中的 Java 泛型支持

介紹 JDK 5.0 中的泛型

編譯時使用 Generic Java 捕獲更多的錯誤

1.9 到 2.0 的改動不是很多，主要是廢棄了一些 API ， 2.0 起了一個過渡的作用。

2.1 是在 2.0 基礎(chǔ)上做了很多的改進，提升了性能，修復(fù)了一些 Bug 等。

?

Lucene2.1 在索引的格式上做了一些改進，所以舊版本的 Lucene 是無法訪問 2.1 版的索引文件。但是 2.1 版本的可以讀寫舊版本的索引文件。保持向下的兼容性。這點需要我們在使用時注意。

?

下面簡單的列出一些新的特性：

1.?????? 's' 和 't' 從默認的 stopwords 中移掉了。但是依然還有 'a' 也可以會有同樣的問題，所以分詞需要針對自己的應(yīng)用進行自定義。

2.?????? 更新了 StandardAnalyzer 中的針對 CJK 的 Unicode 代碼范圍。用處不大，因為我們中文需要自己開發(fā)分詞。

3.?????? 允許在 QueryParser 的最前面使用通配符 (*, ?) ，之前是不允許的。這個比較有意義，可以實現(xiàn)一些模糊搜索。

4.?????? QueryParser 默認使用 ConstantScoreRangeQuery 執(zhí)行范圍查詢。增加了 useOldRangeQuery 屬性允許在需要的情況下使用舊的 RangeQuery

5.?????? 對于 WildcardQuery ，如果一個 term 不包含任何的 ? 或者 * ，之前會拋出異常，現(xiàn)在會執(zhí)行一個 TermQuery 。

6.?????? 去掉了 deprecated 的 doc.fields() 方法和 Enumeration

7.?????? write lock 現(xiàn)在默認的位置是索引的目錄，簡單命名為 write.lock

8.?????? 新的 FieldSelector API ，相關(guān)的 IndexReader 和實現(xiàn)都發(fā)生了變化。新的 Fieldable 接口被用作字段的延遲加載上。

9.?????? 使用 MultiFieldQueryParser 的時候可以為不同的 field 指定不同的 boosts

10.?? 新的方法 IndexWriter.addIndexesNoOptimize() 在新添加一個新的 segments 的時候，只進行合并，不進行優(yōu)化。

11.?? QueryParser 允許在引號和短語中使用反斜線

12.?? 增加了方法 RAMDirectory.sizeInBytes(), IndexWriter.ramSizeInBytes() 和 IndexWriter.flushRamSegments() ，允許應(yīng)用程序控制索引時緩存文檔對內(nèi)存的使用，這些蠻有用的，可以用于監(jiān)控索引的過程。

13.?? QueryParser 解析 *:* 為匹配所有的內(nèi)容

14.?? 可以通過命令行在已經(jīng)存在的索引文件中修改和刪除 field

15.?? IndexWriter 增加了方法來高效得更新 documents 。增加 IndexWriter.flush() 方法將內(nèi)存的內(nèi)容刷新到文件系統(tǒng)。

??? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 小兵 2007-3-22