2010年11月22日
#
摘要: 之前遇到幾次現(xiàn)場故障，都是和class文件有關(guān)，比如版本不兼容造成Bad Version錯(cuò)誤之類，需要檢查class文件的編譯版本信息。 今天無意中發(fā)現(xiàn)， jdk自帶的javap 命令其實(shí)可以方便的搞定這個(gè)事情
閱讀全文
摘要: 前幾次的編碼最佳實(shí)踐系列，我們都著眼于Java代碼，今天我們換個(gè)話題，看看另外一個(gè)領(lǐng)域，和Java代碼大相徑庭的SQL。
閱讀全文
摘要: 本期的案例依然是來自實(shí)際項(xiàng)目，很尋常的代碼，卻意外遭遇傳說中的Java"內(nèi)存溢出"。
閱讀全文
摘要: 昨晚繼續(xù)折騰俺的小站http://www.javauniversity.net，準(zhǔn)備給它加上SEO支持，安裝了SEO tools模塊和相應(yīng)的依賴模塊。
結(jié)果安裝完成之后就陷入重定向循環(huán)了，每個(gè)頁面都被重定向到新地址，然后新地址再次被重定向。chrome瀏覽器會(huì)稍后報(bào)錯(cuò)說太多重定向，而ie則傻傻的一直在死循環(huán)。
閱讀全文
摘要: 折騰了兩天，終于將Java University這個(gè)站點(diǎn)開通，過程真不容易的，決定寫下來吐吐 糟，以紀(jì)念TIANCHAO和諧之光普照下P民的美好生活
閱讀全文
摘要: 這是一個(gè)來自實(shí)際項(xiàng)目的例子，在這個(gè)案例中，有同事基于jdk中的LinkedHashMap設(shè)計(jì)了一個(gè)LRUCache，為了提高性能，使用了 ReentrantReadWriteLock 讀寫鎖：寫鎖對應(yīng)put()方法，而讀鎖對應(yīng)get()方法，期望通過讀寫鎖來實(shí)現(xiàn)并發(fā)get()。
閱讀全文
摘要: 這里將要講述的是一系列的類似案例，都是在各個(gè)產(chǎn)品進(jìn)行performance tuning時(shí)被發(fā)現(xiàn)的，非常具有普適性。可以說在日常開發(fā)中，有非常大的概率遇到相同或者類似的情形，因此需要對其保持警惕以便避免陷入類似的性能問題。 我們從JAXBContext這個(gè)對象開始...
閱讀全文
摘要: 這是一個(gè)真實(shí)案例，曾經(jīng)惹出碩大風(fēng)波，故事的起因卻很簡單，就是需要實(shí)現(xiàn)一個(gè)簡單的計(jì)數(shù)器，每次取值然后加1......
閱讀全文
摘要: 最近在公司內(nèi)部做了一些收集和整理的工作，關(guān)于trouble shooting和performace tuning 中遇到并解決的典型問題，做了一些內(nèi)部分享。我整理了一下，準(zhǔn)備陸續(xù)放上來分享給大家。
這些問題，單個(gè)看每個(gè)問題都不算復(fù)雜或高深，但是都是在實(shí)際項(xiàng)目開發(fā)中出現(xiàn)并一度造成困擾的，而且?guī)в幸欢ǖ钠者m性，具體表現(xiàn)為不知道這些問題的同學(xué)很容易在日常開發(fā)中中招。因此我們開了一個(gè)專題，叫做編碼最佳實(shí)踐，似乎名字起的有點(diǎn)大......
先來看看第一個(gè)，如何做compare。
閱讀全文
摘要: 今天用jetty做嵌入式web container，來做web項(xiàng)目的integration test，結(jié)果發(fā)現(xiàn)出現(xiàn)在渲染使用EL表達(dá)式的jsp頁面時(shí)出現(xiàn)異常：
javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory;
檢查了一下，發(fā)現(xiàn)javax.el.ExpressionFactory.newInstance()這個(gè)方法是EL2.2版本之后才有的方法，而在EL2.1之中是沒有這個(gè)方法的，問題很明顯：org.apache.jasper中試圖調(diào)用2.2版本的EL，當(dāng)時(shí)提供的EL的版本是2.1版本，所以解決的方式無非就是兩個(gè)，要不降低org.apache.jasper的版本，要不提升el的版本。考慮到現(xiàn)在使用的jetty已經(jīng)是最新的版本8.1.2.v20120308，因此提升EL的版本為2.2更為合適。
閱讀全文
摘要: 在jenkins上建立了一個(gè)job，通過標(biāo)準(zhǔn)的maven命令來執(zhí)行打包測試和上傳artifact到nexus倉庫。隨后發(fā)現(xiàn)有些性能問題：sonar的job執(zhí)行時(shí)，需要重新update SCM，然后需要再次執(zhí)行test，之后才能進(jìn)行真正屬于sonar的任務(wù)如代碼檢測等。明顯update SCM 和執(zhí)行test是重復(fù)了原有job，純屬浪費(fèi)。這個(gè)重復(fù)執(zhí)行問題隨著測試案例和測試執(zhí)行時(shí)間的增加，會(huì)越來越明顯。因此需要考慮消除這里的重復(fù)問題，減少build的時(shí)間，并節(jié)約jenkins的資源。
閱讀全文
使用maven填寫依賴的時(shí)候，常會(huì)遇到需要查一下groupId/artifactId和version，有時(shí)候還要看看有沒有新的版本更新。
原來一直用http://mvnrepository.com/ 這個(gè)網(wǎng)站來搜索，最近發(fā)現(xiàn)maven官網(wǎng)也提供了類似的功能，http://search.maven.org/。
簡單試用了一下search.maven.org，功能基本和mvnrepository.com相同，而且界面更簡潔友好。推薦使用。
摘要: 初學(xué)gradle，一切都還在摸索的過程中。今天剛剛試圖將之前基于ant + ivy的一個(gè)小項(xiàng)目轉(zhuǎn)移到gradle下，結(jié)果在和sonar集成時(shí)出現(xiàn)問題.
閱讀全文
摘要: 雖然easymock中提供了大量的方法來進(jìn)行參數(shù)匹配，但是對于一些特殊場合比如參數(shù)是復(fù)雜對象而又不能簡單的通過equals()方法來比較，這些現(xiàn)有的參數(shù)匹配器就無能為力了。easymock為此提供了IArgumentMatcher 接口來讓我們實(shí)現(xiàn)自定義的參數(shù)匹配器。
閱讀全文
摘要: 在easymock中，對于mock對象的同一個(gè)方法，可以為每一次的調(diào)用定制不同的行為。在record階段easymock會(huì)精確的記錄我們錄入的行為，基于每一次的方法調(diào)用。
閱讀全文
摘要: 前面的教程中，我們看到easymock可以通過expect方法來設(shè)定mock方法的返回值或者異常，但是注意這些案例中設(shè)置的返回值都是在調(diào)用被測試的類的方法前就已經(jīng)確定下來的，即我們其實(shí)在測試類的代碼運(yùn)行前(實(shí)際是在EasyMock.replay()方法調(diào)用前)就已經(jīng)"預(yù)知"了返回結(jié)果。
但是在某些情況下，我們可能無法預(yù)知返回值，比如我們需要根據(jù)輸入的參數(shù)值來決定返回什么，而這個(gè)參數(shù)可能無法在record階段獲得。因此在mock方法中我們無法在record階段就決定應(yīng)該返回什么。
對于這種場景，easymock提供了IAnswer接口和andAnswer()方法來提供運(yùn)行時(shí)決定返回值或者異常的機(jī)制。
閱讀全文
摘要: easymock中提供對于類的mock功能，我們可以方便的mock這個(gè)類的某些方法，指定預(yù)期的行為以便測試這個(gè)類的調(diào)用者。這種場景下被mock的類在測試案例中扮演的是次要測試對象或者說依賴的角色，主要測試對象是這個(gè)mock類的調(diào)用者。但是有時(shí)候我們需要將這個(gè)測試類作為主要測試對象，我們希望這個(gè)類中的部分(通常是大部分)方法保持原有的正常行為，只有個(gè)別方法被我們mock掉以便測試。
閱讀全文
摘要: easymock中提供了非常多的方法來實(shí)現(xiàn)參數(shù)匹配，基本能滿足一般參數(shù)匹配的要求。
閱讀全文
摘要: 在創(chuàng)建mock對象的時(shí)候，我們可以命名mock對象。
命名mock對象有什么好處呢？其實(shí)就是一點(diǎn)，即在當(dāng)測試案例因?yàn)槟硞€(gè)mock對象的狀態(tài)或行為不符合要求而失敗的時(shí)候，在異常信息里面可以輸出這個(gè)mock對象的名稱。
閱讀全文
摘要: 對于mock對象上的mock方法的調(diào)用,easymock支持指定次數(shù)，默認(rèn)為1.同時(shí)easymock提供了其他的方法，用于指定具體調(diào)用次數(shù)或者放寬調(diào)用次數(shù)檢驗(yàn)。
閱讀全文
摘要: easymock并不是萬能的，在使用easymock時(shí)有一些限制需要注意。
閱讀全文
摘要:
前面教程中有個(gè)章節(jié)討論到mock和stub的概念差別，一般來說easymock如其名所示，主要是用來做mock用的，但是easymock中也提供有對stub的支持, 主要體現(xiàn)在andStubAnswer(),andStubDelegateTo(),andStubReturn(),andStubThrow()和asStub()等方法的使用上。
閱讀全文
大家都知道sonar是個(gè)好東東，在有CI支持的情況下，使用好了可以非常好的控制代碼的質(zhì)量，諸如代碼覆蓋率，代碼規(guī)則檢查等。
而解決violation的辦法，除了正統(tǒng)的修改代碼來滿足規(guī)則外，還有一個(gè)變通的方法， NOSONAR。這個(gè)標(biāo)記本意是在一些特殊情況，有不得已的理由不得不違反規(guī)則，為了避免sonar繼續(xù)報(bào)錯(cuò)而不得已做了一個(gè)"變通"。
NOSONAR本意雖好，但要是有人濫用，變通就會(huì)變成取巧，因?yàn)榻鉀Qsonar violation的最簡單的方法，就是直接NOSONAR！
當(dāng)問題很簡單時(shí)，一般人都會(huì)選擇正常的方式修改代碼，如果只是舉手之勞基本上還是能遵守規(guī)則的。但是當(dāng)問題復(fù)雜時(shí)，或者說當(dāng)解決問題不再是舉手之勞時(shí)，每個(gè)人都要受到NOSONAR的誘惑。而NOSONAR的底線在哪里？沒有人定義，沒有人檢測，自然不會(huì)每個(gè)人都堅(jiān)守，NOSONAR的底線隨著一個(gè)一個(gè)的NOSONAR慢慢的在降低。退五十步的人，是沒有資格笑百步的。
返回到現(xiàn)實(shí)代碼中，不知道是大家都沒有頂住誘惑，還是說我們開啟的規(guī)則不大合理，總之越來越頻繁的在代碼中看到NOSONAR了，雖然還沒有到泛濫的地步，但是已經(jīng)讓我有些不安了。簡單搜索了一下剛才讓我感覺到很多NOSONAR的project，結(jié)果是58個(gè)。
更糟糕的是，每個(gè)NOSONAR后面都不會(huì)帶有注釋說明為什么要NOSONAR，因此一個(gè)個(gè)飛舞的NOSONAR就變成了一個(gè)個(gè)謎團(tuán)。想知道為什么要NOSONAR嗎？恩，你猜......
我沒有辦法去檢查這個(gè)58個(gè)NOSONAR是不是都合理的，都站得住腳的。出于程序員的習(xí)慣，對于一切不可確認(rèn)性都報(bào)以懷疑的眼光和質(zhì)疑的姿態(tài)，我總覺得這58個(gè)NOSONAR讓我總是沒有底，每次我看到sonar上100%的規(guī)則檢測通過率時(shí)，我總是禁不住在心里浮現(xiàn)NOSONAR的字樣。
好吧，我承認(rèn)，我是個(gè)心里有些陰暗的家伙......