邊城愚人

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

     摘要: 繼承是面向對象中很重要的概念。如果考慮到Java語言特性，繼承分為兩種：接口繼承和實現繼承。這只是技術層面的問題，即便C＋＋中不存在接口的概念，但它的虛基類實際上也相當于接口。對于OO的初學者來說，他們很希望自己的程序中出現大量的繼承，因為這樣看起來很OO。但濫用繼承會帶來很多問題，盡管有時候我們又不得不使用繼承解決問題。  閱讀全文

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

     摘要: 本文通過一個“Hello World”級別的橫切性功能介紹Spring1.X中AOP的使用，并結合Spring的經典的聲明式事務管理給出Spring AOP配置中的經典方案。在Spring2出來以后，Spring1.X的AOP使用方式已經“不合時宜”了，因此如果你是在新項目中采用Spring AOP，建議使用Spring2中的AOP使用方式。關于Spring2.X中AOP的使用，參考該文的姊妹文章Spring2.X中AOP的使用。

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

     摘要: 1）MVC模式

當年做JSP生產實習時，印象最深也最困惑的模式就是MVC模式了。那時候Struts剛紅，幾乎每本Struts書中都會有大篇幅的MVC介紹。這個模式最早出現在GUI，后來在Web服務器端紅火起來，先前在Ajax書中也看到Web客戶端的MVC介紹。說實話，在我看了很多人的MVC解釋后，我仍有些糊涂，這里說說我的理解。

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

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

     摘要: 最近在學Acegi，就試著運行一個小例子，不成想拋出下面的異常
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提供客戶化映射類型接口，使用戶能以編程方式創建自定義的映射類型來將持久化類任意類型的屬性映射到數據庫中。使用客戶化映射類型，需要實現org.hibernate.usertype.UserType接口。這是個強大的功能，也是Hibernate的最佳實踐之一。我們經常提到 ORM中很困難的一點便是O的屬性和R的屬性不能一一映射，而Hibernate提供的UserType無疑給出了一個很好的解決方案。本文給出使用客戶化映射類型的兩個例子，算是對Hibernate初學者的拋磚。  閱讀全文

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

關聯級別檢索策略有立即檢索、延遲檢索和迫切左外連接檢索。對于關聯級別檢索，又可分為一對多和多對多、多對一和一對一兩種情況討論。  閱讀全文

     摘要: JDK內建的任務調度工具類有Timer和TimerTask類，對于簡單的任務調度，JDK的Timer就能夠勝任。一般來說，Timer應該隨程序啟動后一直運行。如果是web程序，可以通過listener加載Timer實例。對于普通的應用程序，需要將Timer設置成非后臺線程才行。  閱讀全文

     摘要: 本文主要介紹如何使用簡單的Spring郵件抽象層來實現郵件發送功能，對于JavaMail中的API并不做介紹。通過對比JavaMail的API和Spring的郵件抽象層，我覺得，Spring的郵件抽象層優點就是簡化了代碼量，并能充分利用IOC功能；缺點就是要使用部分Spring API，使程序與第三方框架耦合。關于這方面的內容，可以參考Spring的參考手冊。  閱讀全文

     摘要: call和execution的指示符分別為call（Method-Signature）、execution（Method-Signature），匹配方法簽名的方法或構造函數的執行。對于call來說，調用的連接點位于方法調用點的調用代碼處；對于execution來說，執行的連接點位于方法執行的位置。也就是說，call和execution的重要區別在于它們傳遞了哪些類型給AspectJ編譯器以用來與aspect進行鏈接。  閱讀全文

     摘要: target切入點格式如下：target（［Type｜Identifier］）。Type指示對連接點處的對象類型提供一個靜態編譯時評估，并采用完全限定類名的形式（也就是說，Type不能是使用通配符的類型聲明模式）。Identifier提供了一種方法，可通過它來評估連節點處的運行時對象的實際類型，而不僅僅是靜態類型。 Identifier在運行時動態地賦予合適的對象。  閱讀全文

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

[modifiers] [returnTypePattern] [DeclaredTypePattern.]methodName([Parameters])[throws TypePattern]，其中方括號中的簽名組件是可選的。modifiers 為修飾符模式，returnTypePattern 為返回類型模式，DeclaredTypePattern 為類型聲明模式，methodName 為方法名稱，Parameters 為方法參數，throws TypePattern 為throw字句。該文僅僅介紹 DeclaredTypePattern，因為相比之下其它模式比較簡單的多。

  閱讀全文

     摘要: 經常地，你必須遍歷一個對象集合并基于一些條件（criteria）來過濾它們。JDK提供了有用的機制來排序集合，即Comparator接口。然而，JDK缺少過濾集合的機制。

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

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

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

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

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

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

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