邊城愚人

          如果我不在邊城,我一定是在前往邊城的路上。

            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            31 隨筆 :: 0 文章 :: 96 評論 :: 0 Trackbacks

          2012年7月16日 #

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

          2007年9月3日 #

               摘要: 繼承是面向?qū)ο笾泻苤匾母拍睢H绻紤]到Java語言特性,繼承分為兩種:接口繼承和實現(xiàn)繼承。這只是技術(shù)層面的問題,即便C++中不存在接口的概念,但它的虛基類實際上也相當(dāng)于接口。對于OO的初學(xué)者來說,他們很希望自己的程序中出現(xiàn)大量的繼承,因為這樣看起來很OO。但濫用繼承會帶來很多問題,盡管有時候我們又不得不使用繼承解決問題。  閱讀全文
          posted @ 2007-09-03 10:08 kafka0102 閱讀(2717) | 評論 (5)編輯 收藏

          2007年8月30日 #

               摘要: 在結(jié)束了上一篇Spring 1.x中AOP的使用之后,我用馬不停蹄的打開Eclipse,做著Spring2.X下了AOP的Sample。在上一篇文章中的配置過程中,由于對自動代理不是很熟,出現(xiàn)了循環(huán)引用的異常信息。當(dāng)初在閱讀PicoContainer源碼時看到循環(huán)引用不以為然,后來在學(xué)習(xí)AspectJ時小有印象,這次在折騰了半個多小時后可加深了印象。  閱讀全文
          posted @ 2007-08-30 08:42 kafka0102 閱讀(2301) | 評論 (2)編輯 收藏

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

          一提到AOP的應(yīng)用,人們就會本能地提起日志功能,它就像一門語言的“Hello World”一樣被人們無數(shù)次提起。也許有人會疑問除了“不實用”的日志功能,AOP還能做些什么?可能在很多時候我們并不需要自己實現(xiàn)一個AOP功能,尤其是在擁有了很多優(yōu)秀的AOP應(yīng)用框架來解決通用的橫切性問題的情況下(比如Spring的事務(wù)管理、比如Acegi的安全管理、比如WebWork的攔截功能)。但問題總是層出不窮的,總會有些問題可能需要我們自己AOP一下。  閱讀全文
          posted @ 2007-08-30 08:38 kafka0102 閱讀(2369) | 評論 (1)編輯 收藏

          2007年8月23日 #

               摘要: 1)MVC模式

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

          有人提到MVC模式時說MVC代表了模型層、視圖層、控制層,我覺得這是不對的。在經(jīng)典的J2EE三層架構(gòu)中,三層是分為Web層、業(yè)務(wù)層、持久化層;這個經(jīng)典分層是基于分布式應(yīng)用(EJB)的,也就說,Web層物理上是在Web服務(wù)器中,業(yè)務(wù)層和持久化層物理上是在應(yīng)用服務(wù)器中。在這種情況下,MVC只是屬于Web層這一層的,而不是分為三層。在這種分布式應(yīng)用中,視圖就是JSP(如果采用的話),控制器就是Servlet(如果采用的話),而模型就是就是調(diào)用業(yè)務(wù)層的在Web層中的樁子。假如我們采用輕量級的SSH技術(shù)架構(gòu),視圖還是JSP,控制器是Struts,而模型就是Spring+Hibernate。這里最難理解的就是模型的概念。我覺得模型是有狀  閱讀全文
          posted @ 2007-08-23 10:00 kafka0102 閱讀(1604) | 評論 (0)編輯 收藏

          2007年8月21日 #

               摘要: 今日發(fā)現(xiàn)一名為savage100的同學(xué)問我關(guān)于范型效率的問題的留言,抱著負(fù)責(zé)任的態(tài)度,想給那位仁兄做個回復(fù),不成想未發(fā)現(xiàn)blogjava有回復(fù)功能,而且也未找到savage100的博客。唉!于“百忙之中”以此文作解,也算盡了我回復(fù)之責(zé)任。  閱讀全文
          posted @ 2007-08-21 22:47 kafka0102 閱讀(707) | 評論 (0)編輯 收藏

               摘要: 最近在學(xué)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:  閱讀全文
          posted @ 2007-08-21 21:55 kafka0102 閱讀(24605) | 評論 (15)編輯 收藏

          2007年8月15日 #

               摘要: Hibernate提供客戶化映射類型接口,使用戶能以編程方式創(chuàng)建自定義的映射類型來將持久化類任意類型的屬性映射到數(shù)據(jù)庫中。使用客戶化映射類型,需要實現(xiàn)org.hibernate.usertype.UserType接口。這是個強大的功能,也是Hibernate的最佳實踐之一。我們經(jīng)常提到 ORM中很困難的一點便是O的屬性和R的屬性不能一一映射,而Hibernate提供的UserType無疑給出了一個很好的解決方案。本文給出使用客戶化映射類型的兩個例子,算是對Hibernate初學(xué)者的拋磚。  閱讀全文
          posted @ 2007-08-15 10:32 kafka0102 閱讀(1529) | 評論 (0)編輯 收藏

          2007年8月11日 #

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

          關(guān)聯(lián)級別檢索策略有立即檢索、延遲檢索和迫切左外連接檢索。對于關(guān)聯(lián)級別檢索,又可分為一對多和多對多、多對一和一對一兩種情況討論。  閱讀全文
          posted @ 2007-08-11 13:33 kafka0102 閱讀(1045) | 評論 (0)編輯 收藏

          2007年7月19日 #

               摘要: JDK內(nèi)建的任務(wù)調(diào)度工具類有Timer和TimerTask類,對于簡單的任務(wù)調(diào)度,JDK的Timer就能夠勝任。一般來說,Timer應(yīng)該隨程序啟動后一直運行。如果是web程序,可以通過listener加載Timer實例。對于普通的應(yīng)用程序,需要將Timer設(shè)置成非后臺線程才行。  閱讀全文
          posted @ 2007-07-19 09:50 kafka0102 閱讀(2939) | 評論 (4)編輯 收藏

          2007年7月15日 #

               摘要: 本文主要介紹如何使用簡單的Spring郵件抽象層來實現(xiàn)郵件發(fā)送功能,對于JavaMail中的API并不做介紹。通過對比JavaMail的API和Spring的郵件抽象層,我覺得,Spring的郵件抽象層優(yōu)點就是簡化了代碼量,并能充分利用IOC功能;缺點就是要使用部分Spring API,使程序與第三方框架耦合。關(guān)于這方面的內(nèi)容,可以參考Spring的參考手冊。  閱讀全文
          posted @ 2007-07-15 20:41 kafka0102 閱讀(2705) | 評論 (1)編輯 收藏

          2007年7月12日 #

               摘要: call和execution的指示符分別為call(Method-Signature)、execution(Method-Signature),匹配方法簽名的方法或構(gòu)造函數(shù)的執(zhí)行。對于call來說,調(diào)用的連接點位于方法調(diào)用點的調(diào)用代碼處;對于execution來說,執(zhí)行的連接點位于方法執(zhí)行的位置。也就是說,call和execution的重要區(qū)別在于它們傳遞了哪些類型給AspectJ編譯器以用來與aspect進行鏈接。  閱讀全文
          posted @ 2007-07-12 09:50 kafka0102 閱讀(4170) | 評論 (6)編輯 收藏

          2007年7月9日 #

               摘要: target切入點格式如下:target([Type|Identifier])。Type指示對連接點處的對象類型提供一個靜態(tài)編譯時評估,并采用完全限定類名的形式(也就是說,Type不能是使用通配符的類型聲明模式)。Identifier提供了一種方法,可通過它來評估連節(jié)點處的運行時對象的實際類型,而不僅僅是靜態(tài)類型。 Identifier在運行時動態(tài)地賦予合適的對象。  閱讀全文
          posted @ 2007-07-09 09:17 kafka0102 閱讀(2714) | 評論 (3)編輯 收藏

          2007年7月7日 #

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

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

            閱讀全文
          posted @ 2007-07-07 14:54 kafka0102 閱讀(1757) | 評論 (2)編輯 收藏

          2007年6月30日 #

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

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

          僅列出標(biāo)題  下一頁
          主站蜘蛛池模板: 深圳市| 祁东县| 山西省| 河曲县| 潮安县| 霍山县| 仲巴县| 东乌珠穆沁旗| 永和县| 彩票| 嵊泗县| 商丘市| 甘泉县| 石楼县| 安徽省| 亳州市| 辽中县| 房产| 定边县| 西林县| 重庆市| 通渭县| 梁河县| 宝山区| 鲜城| 祥云县| 图们市| 乌鲁木齐市| 蒙自县| 安义县| 临夏县| 呼伦贝尔市| 大冶市| 开鲁县| 湖北省| 崇阳县| 中西区| 台中市| 东辽县| 山西省| 南投县|