邊城愚人

推酷是面向IT領(lǐng)域的個(gè)性化閱讀產(chǎn)品（www.tuicool.com），關(guān)于產(chǎn)品的更多信息請(qǐng)參考網(wǎng)站的關(guān)于頁(yè)面。 推酷目前加入到國(guó)外一家孵化機(jī)構(gòu)的孵化計(jì)劃，該孵化計(jì)劃于8月到10月這3個(gè)月在大連進(jìn)行集中開發(fā)（提供住宿）， 之后會(huì)返回北京繼續(xù)開發(fā)（亦解決住宿問(wèn)題）。目前推酷正處于熱烈的第二階段開發(fā)中，預(yù)計(jì)今年11月初能正式上線推廣。 為了把推酷各方面做得更好更專業(yè)，推動(dòng)推酷更快的發(fā)展，現(xiàn)誠(chéng)邀熱愛(ài)技術(shù)的朋友加入。 推酷目前需要的技術(shù)主要有以下三方面： 1）前端開發(fā)，即html/css，少量的JS應(yīng)用，會(huì)些簡(jiǎn)單的UI設(shè)計(jì)更好。功力方面，至少要比現(xiàn)在的頁(yè)面做的更專業(yè)些。 2）Web開發(fā)，即Ruby on Rails開發(fā)，如果有其他語(yǔ)言的Web開發(fā)經(jīng)驗(yàn)，有志轉(zhuǎn)向ROR亦可。 3）Android開發(fā)，有扎實(shí)的Java經(jīng)驗(yàn)亦可。 對(duì)于上述技能，擅長(zhǎng)其中某一方面即可。你可以沒(méi)有多年的開發(fā)經(jīng)驗(yàn)，但還是需要有一定的項(xiàng)目經(jīng)驗(yàn)基礎(chǔ)， 并且能自我驅(qū)動(dòng)學(xué)習(xí)，持續(xù)不斷地提高自己的技術(shù)。在推酷，你可能會(huì)獨(dú)立負(fù)責(zé)某一方面的開發(fā)， 這會(huì)使你在技術(shù)方面更快的成長(zhǎng)。當(dāng)然，我這個(gè)零號(hào)員工還是可以給予一些指導(dǎo)的。 因?yàn)槭莿?chuàng)業(yè)初期，目前推酷可以提供的月薪在3000-6000元（這個(gè)工資水平確實(shí)不夠給力， 考慮到創(chuàng)業(yè)的機(jī)會(huì)與風(fēng)險(xiǎn)，如果想找個(gè)穩(wěn)當(dāng)些的工作，推酷就不太合適了）。 如果你有創(chuàng)業(yè)熱情，并認(rèn)同推酷的價(jià)值，作為初創(chuàng)成員會(huì)給予你豐厚的干股。 推酷也歡迎實(shí)習(xí)生加入，但要求能全職的實(shí)習(xí)4個(gè)月以上。 就組團(tuán)理念來(lái)說(shuō)，推酷希望能組成3-4人的技術(shù)型小團(tuán)隊(duì)，在個(gè)人技術(shù)發(fā)揮、工作時(shí)間安排等方面，都會(huì)更加的自由開放。 如果你有加入推酷的意愿，可以將個(gè)人簡(jiǎn)歷發(fā)給我（不用太正式，就別寫自己用過(guò)什么eclipse、svn等工具啦）， 郵箱是kafka0102@163.com。 打造忒酷的個(gè)性化閱讀產(chǎn)品的路上，我在等你。

     摘要: 繼承是面向?qū)ο笾泻苤匾母拍?。如果考慮到Java語(yǔ)言特性，繼承分為兩種：接口繼承和實(shí)現(xiàn)繼承。這只是技術(shù)層面的問(wèn)題，即便C＋＋中不存在接口的概念，但它的虛基類實(shí)際上也相當(dāng)于接口。對(duì)于OO的初學(xué)者來(lái)說(shuō)，他們很希望自己的程序中出現(xiàn)大量的繼承，因?yàn)檫@樣看起來(lái)很OO。但濫用繼承會(huì)帶來(lái)很多問(wèn)題，盡管有時(shí)候我們又不得不使用繼承解決問(wèn)題。  閱讀全文

     摘要: 在結(jié)束了上一篇Spring 1.x中AOP的使用之后，我用馬不停蹄的打開Eclipse，做著Spring2.X下了AOP的Sample。在上一篇文章中的配置過(guò)程中，由于對(duì)自動(dòng)代理不是很熟，出現(xiàn)了循環(huán)引用的異常信息。當(dāng)初在閱讀PicoContainer源碼時(shí)看到循環(huán)引用不以為然，后來(lái)在學(xué)習(xí)AspectJ時(shí)小有印象，這次在折騰了半個(gè)多小時(shí)后可加深了印象。  閱讀全文

     摘要: 本文通過(guò)一個(gè)“Hello World”級(jí)別的橫切性功能介紹Spring1.X中AOP的使用，并結(jié)合Spring的經(jīng)典的聲明式事務(wù)管理給出Spring AOP配置中的經(jīng)典方案。在Spring2出來(lái)以后，Spring1.X的AOP使用方式已經(jīng)“不合時(shí)宜”了，因此如果你是在新項(xiàng)目中采用Spring AOP，建議使用Spring2中的AOP使用方式。關(guān)于Spring2.X中AOP的使用，參考該文的姊妹文章Spring2.X中AOP的使用。

一提到AOP的應(yīng)用，人們就會(huì)本能地提起日志功能，它就像一門語(yǔ)言的“Hello World”一樣被人們無(wú)數(shù)次提起。也許有人會(huì)疑問(wèn)除了“不實(shí)用”的日志功能，AOP還能做些什么？可能在很多時(shí)候我們并不需要自己實(shí)現(xiàn)一個(gè)AOP功能，尤其是在擁有了很多優(yōu)秀的AOP應(yīng)用框架來(lái)解決通用的橫切性問(wèn)題的情況下（比如Spring的事務(wù)管理、比如Acegi的安全管理、比如WebWork的攔截功能）。但問(wèn)題總是層出不窮的，總會(huì)有些問(wèn)題可能需要我們自己AOP一下。  閱讀全文

     摘要: 1）MVC模式

當(dāng)年做JSP生產(chǎn)實(shí)習(xí)時(shí)，印象最深也最困惑的模式就是MVC模式了。那時(shí)候Struts剛紅，幾乎每本Struts書中都會(huì)有大篇幅的MVC介紹。這個(gè)模式最早出現(xiàn)在GUI，后來(lái)在Web服務(wù)器端紅火起來(lái)，先前在Ajax書中也看到Web客戶端的MVC介紹。說(shuō)實(shí)話，在我看了很多人的MVC解釋后，我仍有些糊涂，這里說(shuō)說(shuō)我的理解。

有人提到MVC模式時(shí)說(shuō)MVC代表了模型層、視圖層、控制層，我覺(jué)得這是不對(duì)的。在經(jīng)典的J2EE三層架構(gòu)中，三層是分為Web層、業(yè)務(wù)層、持久化層；這個(gè)經(jīng)典分層是基于分布式應(yīng)用（EJB）的，也就說(shuō)，Web層物理上是在Web服務(wù)器中，業(yè)務(wù)層和持久化層物理上是在應(yīng)用服務(wù)器中。在這種情況下，MVC只是屬于Web層這一層的，而不是分為三層。在這種分布式應(yīng)用中，視圖就是JSP（如果采用的話），控制器就是Servlet（如果采用的話），而模型就是就是調(diào)用業(yè)務(wù)層的在Web層中的樁子。假如我們采用輕量級(jí)的SSH技術(shù)架構(gòu)，視圖還是JSP，控制器是Struts，而模型就是Spring＋Hibernate。這里最難理解的就是模型的概念。我覺(jué)得模型是有狀  閱讀全文

     摘要: 今日發(fā)現(xiàn)一名為savage100的同學(xué)問(wèn)我關(guān)于范型效率的問(wèn)題的留言，抱著負(fù)責(zé)任的態(tài)度，想給那位仁兄做個(gè)回復(fù)，不成想未發(fā)現(xiàn)blogjava有回復(fù)功能，而且也未找到savage100的博客。唉！于“百忙之中”以此文作解，也算盡了我回復(fù)之責(zé)任。  閱讀全文

     摘要: 最近在學(xué)Acegi，就試著運(yùn)行一個(gè)小例子，不成想拋出下面的異常
org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: 23 in the generated java file
The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory

Stacktrace:  閱讀全文

     摘要: Hibernate提供客戶化映射類型接口，使用戶能以編程方式創(chuàng)建自定義的映射類型來(lái)將持久化類任意類型的屬性映射到數(shù)據(jù)庫(kù)中。使用客戶化映射類型，需要實(shí)現(xiàn)org.hibernate.usertype.UserType接口。這是個(gè)強(qiáng)大的功能，也是Hibernate的最佳實(shí)踐之一。我們經(jīng)常提到 ORM中很困難的一點(diǎn)便是O的屬性和R的屬性不能一一映射，而Hibernate提供的UserType無(wú)疑給出了一個(gè)很好的解決方案。本文給出使用客戶化映射類型的兩個(gè)例子，算是對(duì)Hibernate初學(xué)者的拋磚。  閱讀全文

     摘要: Hibernate的檢索策略包括類級(jí)別檢索策略和關(guān)聯(lián)級(jí)別檢索策略。
類級(jí)別檢索策略有立即檢索和延遲檢索，默認(rèn)的檢索策略是立即檢索。在Hibernate映射文件中，通過(guò)在上配置lazy屬性來(lái)確定檢索策略。對(duì)于Session的檢索方式，類級(jí)別檢索策略僅適用于load方法；也就說(shuō)，對(duì)于get、qurey檢索，持久化對(duì)象都會(huì)被立即加載而不管lazy是false還是true。一般來(lái)說(shuō)，我們檢索對(duì)象就是要訪問(wèn)它，因此立即檢索是通常的選擇。由于load方法在檢索不到對(duì)象時(shí)會(huì)拋出異常（立即檢索的情況下），因此我個(gè)人并不建議使用load檢索；而由于中的lazy屬性還影響到多對(duì)一及一對(duì)一的檢索策略，因此使用load方法就更沒(méi)必要了。

關(guān)聯(lián)級(jí)別檢索策略有立即檢索、延遲檢索和迫切左外連接檢索。對(duì)于關(guān)聯(lián)級(jí)別檢索，又可分為一對(duì)多和多對(duì)多、多對(duì)一和一對(duì)一兩種情況討論。  閱讀全文

     摘要: JDK內(nèi)建的任務(wù)調(diào)度工具類有Timer和TimerTask類，對(duì)于簡(jiǎn)單的任務(wù)調(diào)度，JDK的Timer就能夠勝任。一般來(lái)說(shuō)，Timer應(yīng)該隨程序啟動(dòng)后一直運(yùn)行。如果是web程序，可以通過(guò)listener加載Timer實(shí)例。對(duì)于普通的應(yīng)用程序，需要將Timer設(shè)置成非后臺(tái)線程才行。  閱讀全文

     摘要: 本文主要介紹如何使用簡(jiǎn)單的Spring郵件抽象層來(lái)實(shí)現(xiàn)郵件發(fā)送功能，對(duì)于JavaMail中的API并不做介紹。通過(guò)對(duì)比JavaMail的API和Spring的郵件抽象層，我覺(jué)得，Spring的郵件抽象層優(yōu)點(diǎn)就是簡(jiǎn)化了代碼量，并能充分利用IOC功能；缺點(diǎn)就是要使用部分Spring API，使程序與第三方框架耦合。關(guān)于這方面的內(nèi)容，可以參考Spring的參考手冊(cè)。  閱讀全文

     摘要: call和execution的指示符分別為call（Method-Signature）、execution（Method-Signature），匹配方法簽名的方法或構(gòu)造函數(shù)的執(zhí)行。對(duì)于call來(lái)說(shuō)，調(diào)用的連接點(diǎn)位于方法調(diào)用點(diǎn)的調(diào)用代碼處；對(duì)于execution來(lái)說(shuō)，執(zhí)行的連接點(diǎn)位于方法執(zhí)行的位置。也就是說(shuō)，call和execution的重要區(qū)別在于它們傳遞了哪些類型給AspectJ編譯器以用來(lái)與aspect進(jìn)行鏈接。  閱讀全文

     摘要: target切入點(diǎn)格式如下：target（［Type｜Identifier］）。Type指示對(duì)連接點(diǎn)處的對(duì)象類型提供一個(gè)靜態(tài)編譯時(shí)評(píng)估，并采用完全限定類名的形式（也就是說(shuō)，Type不能是使用通配符的類型聲明模式）。Identifier提供了一種方法，可通過(guò)它來(lái)評(píng)估連節(jié)點(diǎn)處的運(yùn)行時(shí)對(duì)象的實(shí)際類型，而不僅僅是靜態(tài)類型。 Identifier在運(yùn)行時(shí)動(dòng)態(tài)地賦予合適的對(duì)象。  閱讀全文

     摘要: 讓我好好想想，AspectJ中最常用的切入點(diǎn)是什么？哦，也許是call（Method-Signature）吧。這是個(gè)相對(duì)簡(jiǎn)單的方法簽名。實(shí)際上，方法簽名的完整形式如下：

[modifiers] [returnTypePattern] [DeclaredTypePattern.]methodName([Parameters])[throws TypePattern]，其中方括號(hào)中的簽名組件是可選的。modifiers 為修飾符模式，returnTypePattern 為返回類型模式，DeclaredTypePattern 為類型聲明模式，methodName 為方法名稱，Parameters 為方法參數(shù)，throws TypePattern 為throw字句。該文僅僅介紹 DeclaredTypePattern，因?yàn)橄啾戎缕渌Ｊ奖容^簡(jiǎn)單的多。

  閱讀全文

     摘要: 經(jīng)常地，你必須遍歷一個(gè)對(duì)象集合并基于一些條件（criteria）來(lái)過(guò)濾它們。JDK提供了有用的機(jī)制來(lái)排序集合，即Comparator接口。然而，JDK缺少過(guò)濾集合的機(jī)制。

這篇文章描述了一個(gè)僅由一個(gè)類和一個(gè)接口組成的簡(jiǎn)單機(jī)制，它允許你快速和靈活地過(guò)濾集合。當(dāng)搜索一個(gè)集合時(shí)，該機(jī)制提供了與SQL中的select語(yǔ)句相同的功能。它的隱含的概念是，在遍歷集合和過(guò)濾集合中的對(duì)象時(shí)，達(dá)到職責(zé)的分離。
這里提出的方法有下面的優(yōu)點(diǎn)：
1、一個(gè)核心的過(guò)濾器組件的復(fù)用產(chǎn)生更清晰的代碼。
2、通用過(guò)濾組件的復(fù)用產(chǎn)生更免于錯(cuò)誤的代碼。
3、從過(guò)濾邏輯中分離出迭代邏輯使你任意地增加和刪除過(guò)濾器而不影響到其他代碼。
4、對(duì)于大集合和多個(gè)criteria能夠獲得性能提高。  閱讀全文

     摘要: 對(duì)于沒(méi)有使用過(guò)Calendar的程序員來(lái)說(shuō)，再次處理日期時(shí)不妨使用Calendar而不僅僅是Date和SimpleDateFormat等類。這篇文章根據(jù)幾個(gè)使用日期的場(chǎng)景來(lái)說(shuō)明如何使用Calendar等類。
在數(shù)據(jù)庫(kù)編程時(shí)，我們通常將java日期字段選作Date型的（一般是java.sql.Date，繼承于java.util.Date，使用方法是類似的），當(dāng)然也可以存儲(chǔ)為字符串甚至是long型的time，但我們這里只討論date型的。如果存儲(chǔ)的時(shí)間是系統(tǒng)當(dāng)前時(shí)間，我們可以使用Date d = new Date();就得到想要的時(shí)間；以前我編程時(shí)也指定存儲(chǔ)日期的格式，但現(xiàn)在想來(lái)不是很有必要，完全可以在讀出數(shù)據(jù)時(shí)指定格式。另一種可選的方法是使用 Calendar類，方法如下：  閱讀全文

     摘要: 最近在看一個(gè)程序，該程序的圖形界面采用SWT編寫。想要將程序運(yùn)行起來(lái)首先需要做的就是將swt（jface）包放到類路徑上，swt包可以從http://www.eclipse.org/swt下載（其中除了swt包還有和操作系統(tǒng)相關(guān)的文件），和swt開發(fā)相關(guān)的插件為VE。一切就緒，運(yùn)行程序發(fā)現(xiàn)了“Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3232 in java.library.path ”的錯(cuò)誤（我的操作系統(tǒng)為Ubuntu7.04）。解決方案有多種，這里只介紹我使用的一種方法。  閱讀全文

     摘要: 哈夫曼樹又稱最優(yōu)二叉樹，是一種帶權(quán)路徑長(zhǎng)度最短的二叉樹。所謂樹的帶權(quán)路徑長(zhǎng)度，就是樹中所有的葉結(jié)點(diǎn)的權(quán)值乘上其到根結(jié)點(diǎn)的路徑長(zhǎng)度（若根結(jié)點(diǎn)為0層，葉結(jié)點(diǎn)到根結(jié)點(diǎn)的路徑長(zhǎng)度為葉結(jié)點(diǎn)的層數(shù)）。樹的帶權(quán)路徑長(zhǎng)度記為WPL=(W1*L1+W2*L2+W3*L3+...+ Wn*Ln)，N個(gè)權(quán)值Wi(i=1,2,...n)構(gòu)成一棵有N個(gè)葉結(jié)點(diǎn)的二叉樹，相應(yīng)的葉結(jié)點(diǎn)的路徑長(zhǎng)度為L(zhǎng)i(i=1,2,...n)?？梢宰C明哈夫曼樹的WPL是最小的。
構(gòu)造哈夫曼樹的算法如下：
1）對(duì)給定的n個(gè)權(quán)值{W1,W2,W3,...,Wi,...,Wn}構(gòu)成n棵二叉樹的初始集合F={T1,T2,T3,...,Ti,..., Tn}，其中每棵二叉樹Ti中只有一個(gè)權(quán)值為Wi的根結(jié)點(diǎn)，它的左右子樹均為空。
2）在F中選取兩棵根結(jié)點(diǎn)權(quán)值最小的樹作為新構(gòu)造的二叉樹的左右子樹，新二叉樹的根結(jié)點(diǎn)的權(quán)值為其左右子樹的根結(jié)點(diǎn)的權(quán)值之和。
3）從F中刪除這兩棵樹，并把這棵新的二叉樹同樣以升序排列加入到集合F中。
4）重  閱讀全文

     摘要: 設(shè)有主串s和子串t，子串t定位是指在主串s中找到一個(gè)與子串t相等的子串。通常把主串s稱為目標(biāo)串，把子串t稱為模式串，因此定位也稱作模式匹配。模式匹配成功是指在目標(biāo)串s中找到一個(gè)模式串t。

傳統(tǒng)的字符串模式匹配算法（也就是BF算法）就是對(duì)于主串和模式串雙雙自左向右，一個(gè)一個(gè)字符比較，如果不匹配，主串和模式串的位置指針都要回溯。這樣的算法時(shí)間復(fù)雜度為O（n＊m），其中n和m分別為串s和串t的長(zhǎng)度。

KMP算法是由Knuth，Morris和Pratt等人共同提出的，所以成為Knuth－Morris－Pratt算法，簡(jiǎn)稱KMP算法。KMP算法是字符串模式匹配中的經(jīng)典算法。和BF算法相比，KMP算法的不同點(diǎn)是匹配過(guò)程中，主串的位置指針不會(huì)回溯，這樣的結(jié)果使得算法時(shí)間復(fù)雜度只為O（n＋m）。下面說(shuō)說(shuō)KMP算法的原理。  閱讀全文