摘要: 最近都實在憋不出什么花團錦簇的大塊文章，還是安心在微博里碎碎念算了。
地址： http://t.sina.com.cn/calvin1978 ，大家互相關注一下哦。   閱讀全文

     摘要: 大眾搬屋版里, 不斷將工作項目中的代碼片段移植過來，而且這種搬運的幸福感估計還會下面的幾個版本中延續。  閱讀全文

     摘要: 現在的書都好厲害，《高效程序員的45個習慣》，《軟件架構師應該知道的97件事》.....但總覺得自己就是個FIFO的管道，看完后基本沒記住什么。

或許這個喧囂而碎片化的年代，惟有屈指可數的東西，才能可能真正被時時記起，踐行吧。在公車上強迫著自己從十多年輕輕重重的實踐中，砍剩最后的幾樣非如此不可，且無處不可的實踐：

  閱讀全文

     摘要: Hmm...居然還差半個月就有半年沒發新版了，long time no see 啊。 至于原因嘛，與Tim講的?有點相似。

好在公司的新項目選型都與SS接近，所以新代碼里其實有很多是親愛的同事們的手筆, 不再是一個人在戰斗了。


BTW. 回頭一看，這里好像只剩下SpringSide的更新記錄，其余的連草都沒有了。
現在工作穩定，是時候出宮了。  閱讀全文

     摘要: 最近國內的開源項目非常生猛，與Play!Framework有些相近的斗魚，也是要替代SSH的Nutz, 已經支持Spring 3.0與iBatis 3的Rapid framework 3.0, 在這個好像特別寒冷的年末，儼然一道鮮亮的風景。
SpringSide也發新版了，相比之下創新性有點欠奉，更像是一本日記，將這兩三個月里遇到的代碼記錄下來與大家分享。  閱讀全文

     摘要: 作為3.1系列的最后一個版本，3.1.8版的代碼質量在 Hudson + Sonar 雙塔控制下，慢慢開始好轉了.  閱讀全文

     摘要: SSO方案中太多平行對稱的分支選擇，就像博而赫斯那小徑分岔的花園。剛手寫完一個超迷你勁袖珍的SSO，順著 SAML2.0和OpenID的規范，記錄一下這些分岔點。  閱讀全文

     摘要: 又過一年了，更新一次自己的ESB筆記，內容實在，枯燥無味，濃縮即精華....年度最大發現應該是Fuse ESB 4.0吧。  閱讀全文

     摘要: 背景音樂：《要不要就一起加入GCD》，唱：陳珊妮，詞：夏宇。

JDK5是一個巨大的轉折點(泛型，Annotation，并發...)，而JDK6就是一個可安全升級的加強版，對新項目是不升白不升，白升誰不升，而對舊項目就是升了也白升，不升也沒啥損失吧。  閱讀全文

     摘要: 年又過年，去年在寫在譯的書又長出了一茬，又是時候訂一份今年的讀書計劃。  閱讀全文

     摘要: 3.1.2是連跳了3.1.0和3.1.1兩個版本后的GA版本，一邊忙著Mini-Example這一畝三分地的升級，一邊開始Showcase的演示......  閱讀全文

     摘要: 沒人知道多如牛毛的傳統MVC框架中哪個是最好的，但就像硬件界買IBM不會犯錯一樣，Struts2.1也應該是未來一段時間里安全的選擇，特別是企業里有N多開發團隊和開發人員的時候。

  閱讀全文

     摘要: 年末最后一天，昭事上帝 ，聿懷多福，祈望來年的Java社區爭氣一點，實現偶們小小的愿望...  閱讀全文

     摘要: 對于演示原型 ，上午要下午給的快速交付，或者某些不知道到底一年有多少個人點進去的網站角落，或者極少數管理人員才用到的管理功能，在恨不能php,ror的時候，你會想起jsp+jdbc的溫暖。

又或者你請到了只會寫jsp和sql的極品，又想讓他明天開始干活.....

所以另做了這個extreme-web風格示例?， 在簡化到no config file的jsp+jdbc同時，仍然是個可堪一觀的MVC，仍然基于親愛的Spring.
  閱讀全文

     摘要: 懷胎十八個月的SpringSide 3.0 終于低調的發布了。
這個版本里的SpringSide，終于放棄夢想，不再奢望做一個框架，或者一個像RoR/Gails那樣極簡的、創新的封裝，唯余對如何用不輕也不重的主流選型、編程實踐來開發JavaEE企業應用的老老實實的總結。  閱讀全文

     摘要: GC調優是個很實驗很伽利略的活兒，最后服務的處理速度從1180 tps 上升到1380 tps，調整兩個參數提升17%的性能還是筆很劃算的買賣.....  閱讀全文

     摘要: 與Mule 2.0抵死纏綿了兩周，喜憂摻半。但只在2.0之后，Mule才算真正站到了ESB的起跑線上。

完整的筆記見我的Wiki: http://wiki.springside.org.cn/display/calvin/Mule , 這里主要列一下實際的升級感受。
  閱讀全文

     摘要: 江湖上多的是功能華麗的項目原型/骨架生成工具，但最后，反而是功能簡單的Maven Archetypes漸漸有了一統的希望。

無它，先把自己收拾得簡單易用，然后作為一個江湖大佬(maven)的"官方"小弟，再有另一些江湖大佬(appfuse,strust2,cxf)使用示范一下，就是現在的上位秘訣。
  閱讀全文

     摘要: ICP的審查員們都嚴查謠言去了么？最艱難的一次ICP注冊，讓SpringSide關站至今。4月份里填錯了兩次接入商，而5月份就一直靜止在"待管局審核"的階段。

6月份，終于通過了。

http://svn.javascud.org/svn/springside/springside3/trunk  閱讀全文

     摘要: TerraCotta? 通過將POJO對象在群集內下的共享，讓POJO不再局限于SNA(Share Nothing Architect)的架構，比較透明的支持了集群模式，可謂POJO開發模型的最后一塊拼圖。   閱讀全文

     摘要: 為了2007年的目標，列了下面待讀或重讀的書單。
不在書單里的，小部分是我漏掉的，大部分是我覺得對于架構師不太重要，或者不夠好的。
奇怪國外真正的好書來來去去也就那么幾本，emule加上國內出版社的努力，我們看的東西和老外已差不多，為什么老外看完就那么生猛，我們看完就還是半桶水呢。  閱讀全文

???[摘要]Spring發了2.0，Struts發了2.0，SS也來湊湊2.0的熱鬧。下載地址：http://www.springside.org.cn/download.php

??? SpringSide 2.0改用了Pragmatic版的Struts作為MVC主打框架，重寫了所有的代碼，增加了新項目生成的命令和構件化的開源棧，還增加了方便新手入門的Helloworld示例。

??? 隨著Java開源社區的日日進步，SpringSide升級了包括Spring 2.0的AOP事務配置， Hibernate3.2的annotation模式，XFire1.2.2的最新簡約配置及JSR181模式，以及ActiveMQ4.1 的Message Driven POJO新模式。

??? 另外，還增加了iBatis數據訪問模式和一系列Ajax Widgets，并全面推行了Selenium集成測試。

??? 全文地址：http://blog.csdn.net/calvinxiu/archive/2006/11/28/1417730.aspx

 

   這篇文檔是專門寫給那些編程狂熱者，在Ant里編程時要留意的重要Task。

    不知為何，老外的各種腳本都寫得格外漂亮。從Appfuse里學到很多，在編寫SpringSide2.0的構件安裝腳本時又被迫自學了不少，這里作下總結。

   全文地址：http://blog.csdn.net/calvinxiu/archive/2006/09/07/1187329.aspx

     摘要: 雖然現在已是Web Server, Web Service的天下，但偶然還是會因為性能苛刻，或者需要自定義協議的原因，很無辜的要自己做一個Multi-Thread，Multi-Client的Tcp Server。 超簡單的QuickServer，讓你專心編寫自己的業務代碼， 不用編寫一行Tcp代碼。[閱讀全文]  閱讀全文

     摘要: Nutch是一個基于Lucene，類似Google的完整網絡搜索引擎解決方案，基于Hadoop的分布式處理模型保證了系統的性能，類似Eclipse的插件機制保證了系統的可客戶化，而且很容易集成到自己的應用之中。

Nutch 0.8 完全使用Hadoop重寫了骨干代碼，另外很多地方作了合理化修正，非常值得升級。[閱讀全文]
  閱讀全文

     摘要: 這個版本將是SpringSide1.0范圍內最后一個跑馬圈地，開疆拓土的版本。從下一個版本開始，將會把主要精力放在代碼的細化，文檔與測試用例的補充，以及在實際項目中的應用。

這個版本除了繼續跑馬圈地外，也對代碼結構作了很多遍重構，終于使復雜的項目以比較順眼的方式組織起來了。

  閱讀全文

SpringSide是一個以Spring Framework為核心，Pragmatic風格的企業應用開發基礎和最佳實踐展示。 為使用Spring框架的開發者提供一個非Demo版的復雜、正式且體現最佳使用實踐的參照系統。為JavaEEer必須面對的問題提供合乎Pragmatic原則的解決方案。

當然，要等待大家拍磚過后，上述表述才會成立。

SpringSide主要包含四個部分--

• BookStore-Sample: 一個Full Feature的書店示例，兼有有書店前臺和后臺管理，作為典型企業應用的微縮版。
• SpringSide-Base：SpringSide的核心封裝代碼與構建一個CRUD管理后臺所必需的full-stack代碼庫。用戶在其基礎上能快速搭建出自己的管理后臺及安全管理程序。 (建設中)
• SpringSide-Modules： 以modules形式提供了其他的企業特征如XFire WebService，JBoss Rule engine，BIRT report，用戶可以快速復制應用到自己的項目。 (建設中)
• Rails-Generator： 自動整合SpringSide-Base/Modules生成項目，生成CRUD代碼的Eclipse?Plugins 和Ant 腳本。?(建設中)

官方站點：??http://www.springside.org.cn
下載地址： http://www.springside.org.cn/download.php
演示站點：? http://demo.springside.org.cn:8080/springside/
升級概述：終于從春天走到了夏天第二版，上一個版本的發布比較匆忙，Bug一堆，1.0 M2版作了大量補救的工作，改進了JBoss Rules ,Compass, Acegi部分使它們貼近了一點"best practice demo"的目標。另外還有很多很多的文檔補全與Bug修正。

盡管代碼里還是有Bug，但為了把SpringSide用于實際項目的1.0M3計劃的開始，先把1.0M2發布出來，希望大家能幫忙數數bug，提提建議，更歡迎大家加入到SpringSide的開發團隊?。

主要更新：

• Compass更新： 使用簡單的Annotation代替復雜的xml映射文件，再換上Compass提供的默認的Index和Search Controller，使得Lucene的使用成本降到平民團隊的程度。另外還加上了復雜查詢的Demo，完整的文檔，So Cool。
• JBoss Rules更新：JBoss Rules出到正式版3.0.1，官方文檔也已經補全。在讀完官方文檔后，改進了之前的封裝和Demo。
  不過JBoss Rules的Road Map告訴我們，它還在升級規則存儲管理的模塊，暫時不用自行擴展。
• Acegi 更新： Acegi出到正式版1.0，在訂單管理部分初步加入ACL控制，還有JCaptcha驗證碼的加入及登陸超時，Logout Filter等特征的使用。
• 其他實用性改進：比如可用Propertity修改的Base Constants；增加了一個查詢屬性如圖書名有沒有重復的通用函數；增加一個historyable接口，BindObject函數會自動為實現了該接口的ceate/modify user 和create/modify time，并用Hibernate Event Listener偵聽修改記錄；增加了前臺Ajax分頁的簡單演示。

其他修改：見 團隊開發日志

其他依賴包升級：

• extreme components 1.0.1 看半天，收獲就是每個<ec:table>?里不需要再定義imagePath了，在properties文件里定義即可，ec會自動為其加上contextPath 如/springside。
• Commons-Validator 1.3 + SpringModules-validation 0.4 使用hotfix的springmodules版本，兩者的最新版終于走在一起了。

本期開發人員介紹：

• 差沙：本期MVP隊員，為SpringSide加入了JCaptcha驗證碼和訂單管理的Acegi ACL實現，ACL的實現側顯了差沙強勁的編碼爆發力，而JCaptcha的引入過程暴露了差沙無物不破的Fix Issue能力。最后差沙已正式升級為SpirngSide核心開發團員。
  
• 地獄男爵：接過nkoffee的棒，把Compass的Feature表現得簡單而強大。?
  
• cac（陳俊）：SpringSide的大內總管，承擔了SpringSide大部分的代碼改進，Bug修正和頁面優化的工作，尤其在1.0M2的最后發布階段，每天熬過半夜連續挑掉了無數問題。
  
• 李李：補充了WebWork的文檔，簡化了Webwork的應用，bba96框架也升級到bba96-tiger1.0-beta3。
  
• schweigen：補充了JBoss Rules的文檔。
  
• 江南白衣：咳。

重要的1.0 M3 開發計劃見http://jira.javascud.org/browse/SPRINGSIDE?共23個任務，其中核心任務有SpringSide-Base建設、Acegi應用的再次升級、BIRT應用的再次升級、JBpm的加入、dojo和Sun的Html widgets 集成taglib大加入、Spring 2.0RC1的升級。 歡迎大家加入SpringSide開發團隊，湊個熱鬧，共襄盛舉。

最后特別感謝scud的JavaScud開源服務平臺(http://www.javascud.org) 為 SpringSide提供的系列服務.

     摘要: Prototype.js 是Javascript編寫者的一把小軍刀，提供了很多Ruby風格簡寫語法和實效的函數，更難得的是完全跨瀏覽器，讓大家舒舒服服寫出又精簡又不用愁心兼容的的JS代碼，springside 已經離不開它了。  閱讀全文

1.TheServerside.com? 依然是地位無可動搖的CCTV1。

2.InfoQ.com Floyd Marinescu 在離開 TSS 后另起爐灶，2006年中最重要推薦。視野不再局限于Java 而是包括Java,.Net, Ruby ,SOA, Agile方法等熱門話題。

3.JDJ的電子雜志?在JDJ首頁的最底處訂閱，文章質量不低于5-7的傳統三強。

4.SWik.net? 收集了大量OpenSource Project的資源聚合。其中如Spring，Hibernate的更新度非常高，出現什么和Spring有關的blog,article,project都會馬上被聚合。

5.IBM DeveloperWorks?傳統、穩定的Java文章來源地。

6.JavaWorld 傳統、穩定的Java文章來源地。

7.OnJava? 傳統、穩定的Java文章來源地。

8.Artima.com?類似于TSS而略遜，其中Spotlight 文章值得關注，而Java News是聚合了所有其他Java站點的大聚合。

9.JavaLobby? 站內的Announcements?是大大小小Java? Project的發布聲明區，Trips and Tricks?有很多的Tips。

10. No Fluff Just Stuff 的Blogs 聚合 一直缺一個所有優秀Java Blogger的rss總聚合，NFJS這里勉強算一個。

     摘要: 作為一個架構設計師，只應該上述的第2，3項特征，一是在框架類里配合使用反射和泛型，使框架的能力更強； 二是采用收斂特征，本著對人民負責的精神，用泛型使框架更加類型安全，更少強制類型轉換。
同時，老被人罵的擦拭法其實避免了Java的流血分裂。  閱讀全文

     摘要: 因為Retrotranslator的出現，SpringSide 1.0終于放心升到JDK5.0，并保證仍然100%可以運行在JDK1.4的服務器上。
和Retroweaver一樣，大家直接用JDK5開發，最后通過ASM轉換到JDK1.4的字節碼，部署到JDK1.4的運行環境。但它不僅支持JDK5的語法，還支持JDK5的新增API。  閱讀全文

     摘要: 當王家衛遇到杜可風，Spring遇到Ruby。想出這個題目的Crraig Walls 絕對也是個八卦種子，宣傳的是Spring 2.0m2集成動態語言的feature。  閱讀全文

     摘要: 《Effecitve Enterprise Java》的一個實踐。  閱讀全文

     摘要: 看著log4j-2.13.jar被每個項目每個版本里一次又一次無限下載，你就會覺得用Maven2 管理Library實在很環保。
而且，Java的類庫也急需擺脫這種無身份無地位一個jar包隨處擺放的境況。Maven給Jar以名份是一個好方向。
  閱讀全文

     摘要: 有個地方恰似美好未來，就是被趕鴨子上架的springside了。
  閱讀全文

     摘要: SourceForge用了許多年，最近才靠springside混進了它的后臺。八卦一把去sf混個房間有什么好處，還有它以什么規則，維持這么大一間善堂的運作。  閱讀全文

     摘要: 似乎老外有這個習慣，逢年過節都會推薦一些書大家在家里充電。  閱讀全文

   作者：江南白衣     

  JDBC有夠慢的，出到了3.0了才有個Rowset能類似于windows下ADO的概念，卻還是達不到ADO.net的水平。幸虧Java里ORM這塊比較爭氣，趁著C#的ObjectSpace跳票，可以繼續耀武揚威。

  Rowset對比于ResultSet，除了不用保持Connecton外，更重要特點是能夠類似于ADO的編程方式，直接對Row賦值來進行Insert與Update， 而不用寫SQL語句。   在windows編程中經常可見這種模式，特別是ADO.net用的好時，ORM也只能算是錦上添花....

     在oracle的sample代碼中，rowset02.java完整demo了RowSet的ADO模式。
     簡化后的代碼如下：

    作者：江南白衣    
 
   上次FB的吹水摘錄：

     除JDBC外的數據訪問技術包括EJB，Hibernate，JDO，iBatis等，但凡是ORM的總要面對相同的困境，如果透明持久化的，苦惱就更多 --Java數據訪問技術依然在緩慢跨越鴻溝，.Net社區的同學用不著眼熱心跳：

     1.查詢語言--紛紛重回原來極想擺脫的sql，但實現得又不如SQL成熟。
        因為QueryObject，Criteria API的可讀性太差，最后所有技術方案都回到它們原來一力想擺脫的SQL的路上。而且，因為是重新倉促設計，都不如sql 的成熟，總有很多做不到的地方。像剛開始的EJB QL，幾乎什么都做不了，而hibernate 3.0 HQL把h2的代碼拋棄了重新實現才達到相對滿意的水平。

    2.積極載入和懶惰載入--不能如sql般每次隨需定制
       ORM與jdbc訪問的區別，就是以包含關聯對象的對象，而不是以sql自由定制的ResultSet，作為數據載入的主體。

       積極載入策略在載入訂單對象時，會接著載入顧客對象、產品對象，而如果產品對象又包含類別對象時.....整個數據庫被拖了一小半出來。即使不玩連連看，clob對象的胡亂載入就夠頭痛了。

      與此對應的就是懶惰載入策略，比如EJB的初始版本，據聞每個屬性查詢一次數據庫，數據庫往返次數多得嚇人。

      ORM方案會讓用戶自行定義這兩種策略來達到平衡。一般默認采用積極載入，在一對多關聯上定義lazy load，還有統一定義積極載入的層數。到了hibernate 3，更可以在列級別上定義lazy load。

      問題是，上述的定義都在hbm文件，每種對象的載入策略只能定義一次。而不能像jdbc那樣，根據不同的情況select不同的結果列。

      順帶一個問題是那些信息不完全對象，比如產品只有序號和名字，不帶其他信息時，在一個純面向對象環境里不好表示，hibernate提供的component方案也不是太好。

3.透明持久化--對POJO的一些臨時操作也會被持久化
     因為持久化是透明的，很容易就會誤用，對POJO進行的一些臨時操作，一不小心就被保存進數據庫中。再加上Session，事務的混亂，遠遠沒有用jdbc跑DML語句那么容易搞清楚發生的事情。

    而且，不是每個程序員都能習慣新的透明持久化環境，都對所用ORM系統的持久化策略理解深刻。何況這些策略以及整合它們的框架如Spring，還經常毫無提示的在升級時發生改動!!!

    所以，每個使用ORM的團隊，在項目過程里總會有鬧鬼的幾天......

  從晚上六點開始聊到十一點，一群恐怖的聊天動物，隔壁桌的三姑媽六姨婆都無奈先撤了。

  記憶力超強的david.turing記得的Topic包括：Hibernate，Spring，iBitas，Strut，SOA，BEA產品(Wls, Wlp, Liquid Data)，JDK1.5，設計模式，泛型，數據庫事務，Java控件，RichClient，XML，WebService，反編譯技術，代碼重構，比較.Net和Java在開發過程中的區別，UML，代碼控制，反射機制，Oracle/SQLServer，手談的AI設計，Web數據竊取......
   一群gay birds包括：Sparkle，Yok，WaterYe，江南白衣，Cyt，timiil，Char，Alex，瀚海，oo豆豆豬。

  PS.英文不好的同學用詞霸查一下gay bird，切勿自誤。

   

  

 

作者：江南白衣???

??? SpringSide--Pragmatic Enterprise Application KickStart and Common Library Stack，這么長的一個名字下來，不用解釋大家都知道是做什么的了----以Spring Framework為core，提供一個Pragmatic的企業應用開發基礎和最佳實踐展示。

? ?定位：為使用Spring框架的開發者提供一個非Demo版的復雜、正式而體現最佳使用實踐的參照系統。

?? 目標：囊括JavaEE必須面-對的所有問題的合理的、合乎實踐標準的解決方案，采用Plugins形式組織，使開發者可快速定位所需的參考方案并做加法到自己的系統。
?
????項目網站：http://www.springside.org.cn?
??? or http://springside.sourceforge.net
??
??? 1. Featrue List???

• Spring 2 - J2EE Framework.
• Hibernate 3 - ORM, support EJB3/JPA1.0 in future.
• Spring MVC?/WebWork - Multi-Action Web framework.
• JSP2.0 - View Template.
• XFire - Web Service.
• Acegi - Security, RBAC ana ACL.(doing)
• Eclipse BIRT 2 - Report Engine.(doing)
• Drools?3 - Business Rule engine.(doing)
• ActiveMQ ,Jencks - JMS Message Driven POJO.
• Quartz - Enterprise job scheduler.
• DWR 2 , Prototype.js , TrimPath JSTemplate ? - Ajax
• Compass - Search engine use Luecene .(doing)
• Groovy - Dynamic script language.(doing)
• Openi - BI web application for OLAP Report.(doing)
• ServiceMix - ESB(Enterprise Service Bus) and JBI.(doing)
• Commons Validator - client and server side validation.
• SiteMesh web-page layout and decoration framework.
• OSCache - Web cache solution.
• ExtremeTable - JSP Tag Libraries.
• Log4j - Logging tool.
• Ant , Maven2 , JUnit, EasyMock?- Build and Test tools.
• UTF-8 and I18N.
• Intergrate with Weblogic , Tomcat , JBoss , Geronimo.
• And we are choising the Workflow solution.

?
??? 2. SpringSide與Appfuse有什么不同？
??? 1.SpringSide較完整的演示了企業應用的各個主題，而Appfuse只有簡單的登陸界面和用戶管理。

??? 2.SpringSide是深受Ruby on Rails影響的Pragmatic型的方案。

??? 3.Appfuse主要目的是展示各式mvc、orm方案與Spring的結合，有些技術屬于高手玩具，而SpringSide展示的是一個國內項目的實際形態，并帶中文手冊與大量中文代碼注釋

????4. 腳本細節
??SpringSide的基本結構是JDK1.4 + Spring 2.0 + hibernate3 + Spring MVC multi-action + JSP2.0。

??? 使用 XFire提供WebService訂書的服務端接口和 Java版/.Net版的客戶端示范代碼。

????店員是個兼職的學生，所以系統會為每張訂單發一封通知郵件給店員。為了不影響顧客下單的速度，發信的動作由jms異步進行。
???
??? 系統還會用 Quartz定時掃描缺貨的圖書，用郵件通知店員。
????
??? 老板只負責看一些色彩豐富，帶圖的報表。Eclipse Birt2.0提供日常報表 ， Openi提供BI OLAP的。

????基于Lucene的 Compass做的圖書全文搜索。

??? 基于 Drools規則引擎的訂單滿100元免運費，會員積分制等。??????

? ? 店面演示Ajax效果與 OSCache的Web Cache，SiteMesh的渲染效果使用。

??? 一些非關鍵業務，用 Groovy動態語言來快速開發。

??? log4j系統將重要操作員日志異步寫入數據庫，使它們可管理。

??? 綜合的Acegi i安全權限管理。

??? utf-8, i18n的國際化項目。

???ServiceMix ，WorkFlow的故事設計中。

??? 5. RoadMap
??? Road Map in? JIRA Issue Checker ,歡迎大家提出更多Topic
????.
??? 6. 團隊成員列表 (排名按加入順序)
???
???? 歡迎朋友們加入。人多速度快是很重要的事情。

???參加方式有3種
?? 1.幫忙codereview提意見
?? 2.到JIRA里面領任務
?? 3.到JIRA 提出新任務?

??真正貢獻了力量的同志自然會成為開發人員.

???
????Team Worker：
???? 江南白衣，cac，@_@，wuyu，charlse, efa，yimlin??
???? Contributor：
???? water?ye ，totodo，david.turing，pesome，oofrank
??
???? 長老供奉：
????? 莊表偉，Robbin

???? (排名按加入時間）

7. 交流區

演示站點

開發RoadMap

Spring中文論壇專區

團隊開發日志

開發者QQ群：15690287 (only for Springside developer)
用戶QQ群: 21601442

   作者：江南白衣    

    Spring再強大，也要面對降臨的問題--因為Spring不是Weblogic、Tomcat般的頂層容器，Servlet和EJB對象不由它創建，所以它必須要降臨到Weblogic、Tomcat所在的位面。
     初學者一般不用管那么多，照著Spring+hibernate+Struts之類的Sample就做了，但慢慢的，也許就要開始在jsp+javabean體系，土制框架，singleton類等環境下使用Spring了。
     《Professional Java Development with the Spring Framework》第3章有"Managing the Containe"一節講這個問題。一般可以分為直接召喚系與IoC fashion兩類。

     1.直接召喚系--Singleton的Application Context
      最簡單的，就像在UnitTest里那樣，直接構造Application Context：

    
      在Web環境里，會使用ContextLoader構造ApplicationContext后，壓進Servlet Context。
      由ContextLoaderListener或ContextLoaderServlet，在Web應用啟動時完成。
      然后在Jsp/Servelet中，可以通過Servlet Context取得ApplicationContext：
     
      但像singleton類或者EJB中，就沒有Servlet Context可用了。
      如果全部像UnitTest那樣直接構造，速度就會很不堪。自然的，就想到把ApplicationContext做成單例。 
      Spring提供了ContextSingletonBeanFactoryLocator這樣的物體。
      先搞一個beanRefFactory.xml，里面寫上所有的applcationContext-*.xml文件名，并把Context命名為"default-context"：
  然后讓loactor去找它，但代碼有點長：

    上面的代碼實在是太靈活，太麻煩了。
    還不如自己實現一個簡單的Singleton，擴展ContextLoaderListener類，在Web系統啟動時壓入Singleton。

    新的ContextLoaderListener類重載如下，ContextUtil中包含一個靜態的ApplicationContext變量：

   用家可直接取用：


2.IoC fashion
    如果所有地方都使用直接召喚系，那就反而是在打Rod的耳光了。因為他一直都反對代碼與框架深耦合的。
    所以，更好的方法是寫一些glue code、base class來完成Spring的降臨，而不讓應用代碼察覺Spring Application Context的存在。
    不過，因為各個框架的結構不同，Rod也沒辦法講出一個通用的整合方法，所以建議大家盡量學習已整合的各種框架，如Spring MVC、Struts的種種方式，寫出自己的簡單整合代碼來。

    只有不確定的調用某些Singleton類，不適合過早ioc的情況，可以使用直接召喚系。

作者：江南白衣 

每年的全球四大Java研討會，它們的agenda，給大家提供了一個捉摸Java時尚風向的便利。
每年花幾天看一遍它們的報道和share出來的slides，是CTO該做的事情。

PS. 如果你被邀在哪里做講演，又想不到給下面那些似睡似醒的豬頭說什么的，可以從中參考一二。
PS2.在迷宮一樣的網站中翻滾了半個小時，把agenda和slides的鏈接都整理了出來，便人便己。

TheServerSide Symposium 對很多人來說，TheServerSide才是真正的Java官方社區--06年的agenda。

JavaPoils 歐洲最大的Java研討會--05年報道，04年完整Slides，05年(1)pdf陸續補全中，05年(2)pdf，04年的talk (需簡單注冊）。

Java One 官方，官方.....--05年報道，05,04年的ppt。

No Fluff Just Stuff tour  簡稱NFJS的大馬戲團，最近的Spring Experience也是和它一起搞的
--05年某次的報道，過往的Agenda，Spearker的blog聚合。

    作者：江南白衣 

　俗話說得好，沒吃過豬肉不要緊，沒見過豬跑路就很沒面子了。新公司上班一周，主要就是看豬跑路，2005年末，一個典型的Java EE項目，場景是這樣的：

    1.一臺內存強得變態的Sparc呼哧呼哧的在跑Oracle 10g。

    2.它的一個兄弟，共享T3陣列，靜靜的跑vcs 為它做著雙機熱備份。

    3.兩臺Weblogic 9做群集負責后臺管理。
　   編程模式是最老土的struts+spring+hibernate，再蹭一點Ajax。

    4.四臺Weblogic 9做群集負責前臺門戶。
　   最直接的jsp + javabean，用weblogic的tag作了頁面Cache。
　   weblogic還發布了一堆Web Service接口，也不時調用一下合作伙伴提供的WS。
　   最后還有一伙定時Task在奔跑，有些是自動改變帳單狀態，有些是自動把數據導出，ftp到合作伙伴那。

    5. 一臺Crystal Reports XI 的報表服務器。
　   邏輯都用PL/SQL封裝在SP和中間表里，設計報表時直接取用便是，不沾一絲Java代碼的煙火。
　   PS. 這臺也是唯一的Windows Server，

    6. 還有一些跑Tomcat（省錢)的獨立小應用，一些C寫的任務，零散的分布在上面9臺服務器的角落。


 

   作者：江南白衣 

   今天CSDN的頭條是微軟DSL 對決 UML，雖然不是什么新聞了，但還是很開心。因為我實在很不喜歡基于UML2.0的所謂MDA。
    某人說，世界上沒有無緣無故的愛，卻有無緣無故的恨，尤其在網絡上。
    所以我很不喜歡UML三友。
    因為(非魚批：不是說無緣無故么?) UML中除了Class圖、順序圖、交互圖，其他如部署圖之類的，根本就是急就章，估計也就花了三友寶貴的十分鐘設計出來的，也沒多大用處。而Class圖和順序圖，換作諸位看官，回家憋幾天也能設計出個八九不離十的式樣出來。就這么點東西，值得捧到高高的神壇上坐這么久不下來么？

    第二不喜歡基于UML的MDA。UML作為溝通工具還好，但想用tagged value表達整個系統作為代碼生成的依據，就像想拿XML來描述整個商業系統、商業邏輯一樣。看這些年來，工具開發商浪費了這么多人月，除了實際幫了不少研究生的畢業論文外，再沒多少成果了。（那些有限的生成效果，隨便一個xml文件或者PowerDesigner放開手腳做一下也不差多少)

    但就是這個三友和UML，把業界向更高一級語言邁進的希望死死綁在一輛戰車上一綁就是好幾年，現在終于有一個出來搞局的了，而且還是手臂足夠粗大的微軟，就象Spring 搞了EJB2的局一樣，怎不叫我這種蠻夷拍手叫好？ 
    甚至不用管微軟的設計最后是否成功(不過開發領域，微軟還沒有過完全失敗的產品)，只要把局搞亂，我就很高興。何況，我也是個DSL愛好者。

作者：江南白衣 

2005就這樣完了，ONJava的年終總結: 2005 Year in Review。
TSS年初開會時講得專家們自己都開始有點厭倦的EJB3，JSF1.2，Ajax，AOP的三宗合一，SOA和ESB，Groovy，還是沒有一個stable的東西出來。

眼看2006，又是繼續將這些話題變成產品的一年，讓我們繼續討論厭煩：

*Full stack Application Framework: Spring 2.0  
  Spring 2.0吹風會兼FB大會剛剛開過。夜觀星象，Spring氣數未盡，開源社區里也只它有資格不斷整合別人。
  另一個Stack名曰RIFE，不過比較獨。
  另外，JBoss搜刮的JEMS (JBoss Enterprise Middleware)和JSF+EJB3的Seam也會繼續發音。

*Web Framework：JSF 1.2
  最怕別人問現在開項目用哪個Framework好，選來選去暫時還是投靠標準好了。
  不知道Struts Ti，Struts Shale，Spring MVC的2006會怎樣。
   而Continuations這個名詞明年也許會閃亮一下。

*Persist Framework： Hibernate 3.1 (EJB3/JPA1) 
  在RoR的Active Record刺激下，annotaion 和default mapping終究要替代xml描述文件。
   另外，除了麻煩的ORM，也很希望有一個極簡的JDBC Framework，不知道JDBC4.0和Spring跑JDK1.5的SimpleJdbcTemplate什么樣子。

*Web Service Framework：XFire (JAX-WS2.0、JAXB 2.0)
  SOA 風潮下的next-generation SOAP Framework，支持JavaEE 5的JAX-WS2.0、JAXB 2.0與annotation，還拖上了Spring的手。
  Axis的事實標準地位該不保了吧。

*JBI-ESB：ServiceMix 
  2006年的新大熱名詞--JBI(Java Business Intergrade)與ESB(Enterprise Service Bus)。

*Java Rule Engine與JDM 2.0：Drools
   Rule Engine和Data Mining 已經說了很久，不知道明年又如何。但Drools則演繹了一條標準的成名路：
   1.先入CodeHaus再入Jboss
   2.（號稱）集成Spring
   3. 提供Eclipse的插件

*動態語言嵌入：Groovy 
  期待在Ruby的不斷刺激下，1.0正式版發布后的正式用家。

*some Ajax Framework
   Buffalo, Prototype, Dojo, MochiKit, DWR 混戰之下總該有脫穎而出者吧？

*AOP三宗歸一
  雖然大家還很少在應用中使用它，AOP在Spring 中的作用卻非常明顯。不知道Spring2.0是否可以三宗歸一，給出一個框架設計時使用的簡單方案。

  作者：江南白衣 

  今天的一條八卦，在Asp.net 2.0與Rails系 RoR/DJango/Turbogears的兩面夾擊下，Java Web Framework的大佬們終于看到狼來了，坐下來，吃個包，開始商量合作。
   消息在TSS主編Dion Almaer的Blog上看到，再看這個Java Web Alignment Group ，果然陣容鼎盛，36個Member，江湖上大部分大佬都到齊了。Yahoo Group免費參觀，不過他從2005.11.10號開始就已經沒有貼子---歇菜了。

Framework	Group Members
Beehive	Rich Feit
AppFuse	Matt Raible
JavaServerFaces	Ed Burns, Kito Mann, Craig McClanahan, Roger Kitain, Jacob Hookom, James Mitchell, Adam Winer
MyFaces	Bill Dudney, Ted Husted, James Mitchell, Travis Reeder
Seam	Gavin King, Jacob Hookom
RIFE	Geert Bevin, JR Boyens, Keith Lea
Spring MVC and Web Flow	Alef Arendsen, Keith Donald
Stripes	Tim Fennell
Struts Classic	Don Brown, Ted Husted, James Mitchell, Hubert Rabago, Niall Pemberton
Struts Shale	Craig McClanahan
Struts Ti	Don?, Rick?, Patrick?, James?
WebWork	Patrick Lightbody
Wicket	Eelco Hillenius

   上面的名單已成歷史，唯一有趣的是Tapestry并不在列。
   這個Group的最后成果就是Struts和Webwork上演了一出你的名字我的名字的Struts Ti 。---"以Struts為名字，Webwork為核心，加上Beehive的annotataion和pageflow，再提升與JSF的集成能力"。可惜Spring MVC暫時不會加入，而JSF系如何合并還未知。最期待的，是它的Phase 2--zero congfig file。

  作者：江南白衣   

  一年前，RIA新浪潮。
  1.以新的Web控件代替復雜dhtml對控件的模擬；
  2.以重返C/S的用戶體驗代替傳統http的提交-返回模式，開發模式上甚至可以直接調用商業對象。
  RIA一出現就盡獲民心。但，Flex因為收費，XUL因為終端，XAML因為無期，OpenLaszlo因為出身與性能.......漸漸退出了大家的嘴邊，他們也的確不爭氣，又一年過去了，都沒再弄出大的聲響。

  這一年大家做什么呢，是忽然走紅的ajax，來實現RIA中不刷新頁面的承諾，還有高級如DWR，JSON-RPC，同樣實現RIA中對商業對象的直接調用。
  之前有ECHO2，而最近出現的一個框架叫ZK1，開發人員用XUL來開發，然后臂大力雄的框架會把XUL渲染成dhtml+ajax，算是一種有趣的思路。
   但我還是覺得，瀏覽器應該升級，而不是靠復雜的dhtml+ajax來模擬，我是革命派，不是改良派，相對于全體民眾花在模擬上的成本，瀏覽器的升級要簡單得多。

  前幾天因為想在blog上弄點小花樣，去了基于OpenLaszlo的blogbox。再回頭，發現OpenLaszlo已經發布到3.1版本。

  OpenLaszlo 3.1版本升級良多，已解決性能與中文問題。
  *新版本可以編譯為Flash 6、7、8的格式，性能上突飛猛進，不再是以前吃資源的巨怪。
  *支持Unicode，支持中文了。
  *支持SOLO deploy了，也就是不再要求Servlet Container，也可以deploy到IIS和Apache。
  其他還有Drawing API，Charting Components，Dynamic Libraries，Ajax API等一系列升級。

 OpenLaszlo3.1的編程體驗
 1.不愧曾是.com的產物，在Windows 下點了兩下next就裝完了，而且已有了整套的開發環境，10秒鐘之后，我開始在my-apps目錄寫我的helloworld.lzx，然后刷新頁面看結果。
 
 2.XML格式的控件定義，JavaScript作為腳本語言，再加上完備的tutorial、reference文檔和demo code，又和wxWidgets那樣，基本上沒什么特別要學的東西，直接可以開始編碼了。

 3.為什么RIA要比模擬RIA要好？
 開篇兩點之外，OpenLaszlo還可以自由定義控件的layout，比用table、div的做法自由。
 另外，OpenLaszlo還可以簡單的利用現有控件，定義新的控件和式樣。

 對OpenLaszlo有不滿意嗎？
  有阿，用戶社群太少。還有控件的默認式樣也比Flex的差一截，雖說可以自己customize，但不是每個人都那么有空的呀。還有那個IBM友情客串的IDE，啥時候才弄得像個樣嘛。

  Flex ,XUL又在做什么？
  Flex2 擺出的陣仗顯然勝于OpenLaszlo：
  Flex Framework 2, Flex Builder 2,Flex Enterprise Services 2,Flex Charting Components 2
  但，公無收費，公竟收費，&*(^%，當奈公何。

  XUL呢，新出的Firefox1.5只是Firefox1.0的補完，看不出FF2.0的痕跡，一年了。

?? 作者：江南白衣?

?? 反射、Proxy和元數據是Java最強的三個特征，再加上CGLib (Code Generation Library)和ASM，使得Java雖然沒有Ruby，Python般后生可畏，一樣能做出強悍的框架。
???Proxy可以看作是微型的AOP，明白提供了在繼承和委托之外的第三個代碼封裝途徑，只要有足夠的想象力，可以做得非常好玩，Spring的源碼里用Proxy就用得很隨便，看得我非常眼紅。可惜Proxy必須基于接口。因此Spring的做法，基于接口的用proxy,否則就用cglib。AOP么，一般小事非compoent一級的就不麻煩AspectJ出手了。

????cglib的Enhancer說起來神奇，用起來一頁紙不到就講完了。
??? 它的原理就是用Enhancer生成一個原有類的子類，并且設置好callback到proxy， 則原有類的每個方法調用都會轉為調用實現了MethodInterceptor接口的proxy的intercept()?函數：

?在intercept()函數里，你可以在執行Object result=proxy.invokeSuper(o,args);來執行原有函數，在執行前后加入自己的東西，改變它的參數值，也可以瞞天過海，完全干別的。說白了，就是AOP中的around advice。

??? AOP沒有出現以前，該領域經典的設計模式是Decorator，像Java IO Stream的設計就是如此.不過，如果為每個DAO, 每個方法的寫Decorator函數會寫死人的，所以用上cglib的好處是一次過攔截所有方法。?

???? 另外，cglib除了Enhancer之外，還有BulkBean和Transform，都是Hibernate持久化的基礎，但文檔貧乏，一時還沒去看怎么用。

1.AOP里講了一百遍阿一百遍的log aspect在cglib是這樣做的:

??? 應用的代碼:

2.而在Spring的管理下應該略加修改的高級Decorator
?? 上面的例子用return?enhancer.create();創建子類實例，但在Spring管理下，一些Bean的實例必須由Spring來創建和管理，而不由enhancer來創建的。所以我對上述用法略加修改，使它真正當一個Proxy的角色，請對比黑體字的部分



可見，原來模式里在getDao()時由enhancer創建dao，而?調用intercept時則將enhancer創建的dao以Object o參數傳回。
而新模式里，dao在getDao()時從外面傳入，enhancer.create()返回的是一個proxy. 而調用intercept時，實際會用之前傳入的dao進行操作，而忽略Object o參數傳入的proxy.

有點遺憾, intercept函數里MethodProxy的Signature是固定的 , 即客戶如果調用foo(String),你不可以用proxy.invoke偷換成foo(String,String);


系列文章：
Java下的框架編寫(1)--序
Java下的框架編程(2)-對泛型的無聊用法和為擦拭法站臺?
Java下的框架編程(3)--關于反射的碎話?
Java下的框架編程(4)--Annotation vs XML vs Interface 最新一Round?
Java下的框架編程(5)--cglib應用
Java下的框架編程(6)--asm(待寫)

作者：江南白衣 

1.因為兩者的用途不同，所以Annotation與XML應該并存

　Anootation vs XML 到了現在，在Spring和EJB3各占一邊的持續演示下，各自的用途已清晰。
   雖然兩者之間完全可以相互替代，沒有絕對不能做的事情，但卻存在好不好的問題，兩者的用途不同，應該并用：

   "size=10，db_user=ito"這樣的參數，仍然適合放在XML，YAML(ruby)，properties，ini文件里。
    而Annotation中所放，是真正程序的一部分，是舊編程體系中所缺的那一塊東西。
　看看編程語言的發展：
    一開始只是函數的封裝；
    到了OO語言，對象有了自己的屬性和方法；
    到了框架滿天飛的年代，這些屬性和方法又有了自己的屬性，來告訴框架如何為自己提供服務。比如Spring和EJB3，POJO就用配置信息來告訴框架無侵入的提供服務。整個進化的過程非常自然。

    因為這些信息本來就是程序的一部分，所以應該仍然放在Code里頭，Spring把它割裂到XML明顯影響了代碼的閱讀。

2.Anotation/XML PK Interface，Spring 無侵入性的基礎
   切爾斯基的Blog講了Annotation/XML 對Interface的PK。這次PK，也可以認為是Spring 對 EJB2.1在框架無侵入性上的一次PK。
   在EJB2.1時代，POJO必須通過接口來向框架聲明一些東西，這就造成了框架的侵入性，強迫POJO實現一堆接口。而Spring，把這些元信息搬到了XML配置文件。
　在Spring里隨便就可以舉個例子。比如一個POJO，在Spring為它進行依賴注入A和B后，需要根據A和B來裝配一個內部屬性C，這樣就需要再跑一個init()函數。Spring提供兩種方式，一種侵入性的，實現InitializingBean接口的afterPropertiesSet()函數供Spring調用。   而另一種是無侵入性的，在Bean的xml節點里面自行定義init函數的名字。

３.Annotation目前的弱點
　一是Hibernate、Struts、三姑媽、四姨婆的annotation如果一股腦兒的全堆在可憐的POJO上很沒人道，如果三姑六婆都搶Transation這個Anontation就更慘了。
    二是annoation的表達能力有限，不如XML的強。

4.JSR250 - Common Annotations for the Java
    Final Draft已經發布，八卦回來一看，也只是多定義了幾個Common Annotation而已。
   1.Generated  自動生成的代碼要用此聲明，而且必須說明工具的名稱，如@Generated(“com.sun.xml.rpc.AProcessor”)

   2.Resource/Resources 就是EJB3里面用的資源引用。

   3.PostConstruct / PreDestroy 聲明那些如題的函數。
  
   還有一些安全方面的annotation，不關心。


文章：
Java下的框架編寫(1)--序
Java下的框架編程(2)-對泛型的無聊用法和為擦拭法站臺 
Java下的框架編程(3)--關于反射的碎話 
Java下的框架編程(4)--Annotation vs XML vs Interface 最新一Round 
Java下的框架編程(5)--cglib應用
Java下的框架編程(6)--asm(待寫)

  

   作者：江南白衣 

   不知道明年今日，會不會出現一隊只會用Ruby On Rails的畢業生，像當年的asp、jsp、php迅速剿了C++/perl的CGI那樣，把我們給剿了。同好們勸我，根據大公司經濟學，這基本不會發生。

    在茫茫的框架之海認出一個Rails框架，基本上靠四個特征
    1.一門動態語言
    2.一個extreme simple to use的ORM框架
    3.一個extreme simple to use的MVC框架
    4.一些自動生成代碼的命令、模版
    其余ajax、web service、i18n等特性自由擴展

   1.Ruby: Ruby on Rails
      Rails系的旗手，一己之力搞得J2EE陣營雞飛蛋打。
      旗手的作用表現在：
      *最接近1.0的版本，目前已出到最后一個RC版 1.0 rc4(0.14.3)
      *擁有一本amazon超級暢銷的《Agile Web Development with Rails》，而且這本書的組織也好，part I是一個漸進的sample application 讓你快速入門，partII是幾個重要領域的深入介紹。
      *擁有自己的IDE: RadRails ，基于Eclipse但獨立成軍，目前出到0.5。(是不是怕慘了Eclipse的多變，現在這些IDE的發行版本開始反包含了Eclipse在內。)

    2.Python: DJango、turbogears
       認識不深，所以DJango請看limodou的blog，turbogears看xlp123的。

    3.Groovy: grails
       如果能順產，絕對是J2EE陣營里感情分最高漲的項目。因為它語言用Groovy，ORM用annotation版Hibernate，MVC用Spring。不用擔心它換湯不換藥，因為經過extreme的封裝，再結合Groovy，絕對不再是原來的Spring+Hibernate，而是和RoR差不多的一樣東西了。不信可以看看他的Sample。
       不過這個項目的源碼目錄樹非一般的亂，也還沒有0.1版釋出。還有一樣奇怪的事情，這個Groovy項目，大多數的class代碼都是Java寫的。

    4.Php: symfony ,cake
       據說cake比symfony弱非常多，所以沒看。
       symfonys是基于php5的項目，成功整合了Propel(ORM)、Mojavi3(MVC)，再配合自動生成的腳本打造而成。看他的sample，最后整合出來的東西也很Rails了，除了ORM層的xml文件。
        還有一個發現是Php項目現在可以用pear來安裝，很像Ruby的gem，Java的Maven要努力了。
        這樣就裝完了symfonys和propel&croel, mojavi3,還有用來運行腳本命令的pake(php make)，PHing(php ant?)，一大堆東西。

  佩服david turing，獨自張羅了BEA廣州User Group這臺一百二十人的大戲。

  如果有什么意見，就是這一百二十對目光，太嚴肅了。所以今天能頂住這么多眼鏡反射，站到講臺上的都是好兄弟(姊妹)。

   而我期望的UG有一種更relex的style，一面喝酒一面聽歌一面看日落，超過千人鴉雀無聲的呆望咸蛋黃般的落日悄然沒入大海，當最后的陽光消失時，全場千人竟然一齊拍手喝彩，有如目擊歐洲杯黃金入球，場面好鬼"娘"......   很明顯，剛才說的是Cafe del Mar。轉回現場實況報道：今天群里出現了cyt、rayman、pqf、ytam、GTM、小小強、yok、sparkle、瀚海、翱翔和我，剛好夠一桌。

講演報道

    去得比較晚，沒看到Bea工程師的講演。看到身為Promgrammer粉粉團家嫂的shallon講Spring(由于彭羚同學慣稱商臺家嫂，所以cyt偶像的shallon親愛也可稱為...照片在dev2dev)，講稿是一份非常Professional的內部培訓材料，力挺之下，被david.turing誤報為too simple，特此勘誤:(

    另一位是Hongsoft同志，不過隔行與隔山，工作流方面完全不懂，ppt上都是一堆不認識的名詞，遂十分欽佩之(如果你在演講過程中不要老點我名字我會更欽佩你，下次輪到我講的時候，嘿嘿....)，并理解為是在講軟件命名風水學，哪個旺，哪個不旺，最后是BPEL勝出。(但cyt偶像隔完又隔了幾行之后，仍然覺得像是為了兼顧到場領導的科普教育，too simple，這就是當偶像的資本）

全場笑位
     全場最大的笑位hongsoft剛上來，很謙虛的講，“本來想趁剛才的時間復習一下講稿的，但因為前面的演講太精彩，所以我... ” ，“睡著了...” ytam忽然接了一句。方圓幾米內笑倒一片。這個故事告訴我們，當下面有ytam這么恐怖的存在時，有話一定要一次說完。

其余八卦
    茶會開始的時候，GTM說，明白為什么有的同志坐到山頂了，原來那里才是上菜位。我們這些坐一二排握手位的反而......于是一幫人又接著去澳門街FB，而且消滅的速度一流。
    還有，因為GTM上次偷拍的失手，今天大家看到GTM的手機都像見到鬼似的.....
    還還有，今天cyt偶像拿到了ytam那本絕版的《C++ Template Complete Guide》 中文版，我也想要阿。以后大家可以多點利用聚會的機會交換東西。
    

    作者：江南白衣 

    充分體驗到知識循環再用的好處，原本對Python、wxWidgets沒有接觸的，天黑天亮之間，已經作了一個半成品的桌面程序出來。

    1.選型
    通常選型之后，都會迫切的告訴別人自認為正確的原因，這時候路過的人就比較不幸了。
    我選Python和wxWidgets，是因為.......

    因為是發布到網上的小程序，要它很小，Java和.Net這兩個還算當紅但要裝虛擬機的笨家伙最先out了，而Python在py2exe之后壓成rar才3M，如果有心思還可以弄得更小。
    選wxWidgets是因為它可以通行于Windows，Linux兩個位面，另外Fox也能通用，不過wxWidgets是像SWT一樣用Native Widgets的，在WinXP上比較好看。
    用Python而不是C++，是為了快速開發。當然，心底里其實是貪好玩。本來喜歡Ruby的語法更純潔一些，可惜wxRuby已經太久沒更新了。

   2.wxWidgets
   所謂GUI框架，萬變不離下面幾點：
   1.框架結構
      拿個HelloWorld一看就懂，又是Application->Frame->Menu 的標準架構。

   2.wxWidgets用法
     來來去去還是Text框，選擇框，按鈕幾個老面孔，在wxPython上把wxPython2.6-win32-docs-demos-2.6.1.0.exe檔下載回來，就有C++版本的API手冊與python版本的每個widgets的Demo Code。

   3.控件與頁面的Layout
      一種方式是C# Winform和Swing那樣在程序里生成組件和layout，經歷過SWT手寫代碼畫頁面的折磨，再看到一層又一層的Container代碼（wxWidgets里是Sizer)已經不覺得麻煩了。也有所見即所得的工具如BOA，不過畢竟沒有Visual Studio for WinForm那么好，難以真正使用。
      一種是像Delphi, VC或未來的XAML那樣把控件和layout記在XML文件里。但我沒有用。

  4.事件分發機制
     像 EVT_BUTTON(self,ID_UPLOAD, self.onUpload)這樣的代碼，挺簡單的。

  可見，只要有過GUI編程的經驗，再學wxWidgets 很容易。
  參考書：《Cross-Platform GUI Programming with wxWidgets》
                  《wxPython in Action》

   3. Python 
   手邊放一本Python的參考書，只要對動態語言有點感性認識，對著Sample Code能能猜就猜，猜不到就拿chm版的參考書來索引，也很容易入門。

   最難的地方發生在遍歷目錄，那時候已經有點困了：
    這是什么見鬼語法阿！！
    原來os.walk('C:/projects") 的返回值是一個tuple。在C++ Boost庫中接觸過這個概念，平常函數都只能返回一個值，而tuple可以讓你返回多個（這樣就不用利用傳址的參數來返回啦），所以就有了for root,dir,files in os.walk()這樣的句子。
    還有 print join(root,name) for name in files，原來python還有這種把閉包寫在for的前面的簡寫法。

   IDE最后還是用了Eclipse的插件PyDev，畢竟Eclipse看著比較舒服，其他編輯器做得那么難看，怎么還好意思收錢。

4.美化界面  
    因為wxWidgets用的是native widgets，不像Delphi,C# 和Swing有專門的look and feel 美化控件，所以美化的主要方式是為Toolbar和Button配上好看的圖標，還有修飾整個軟件的配色。
    推薦Tango一個圖標庫：http://tango-project.org/  to make open  source software beautiful...說出了我的心聲啊，"頂尖兒的程序員必有完美主義藝術家之傾向。"，目前的圖標還不多，迅速更新中。

作者：江南白衣?

記者：你最討厭記者問什么問題？
黃偉文：嗯，那些問題里面帶最字的.....

所以，題目里面那個"最"字可以完全忽略不計，本文是用來記錄那些自己喜歡，但名聲沒有Spring、Hibernate般響亮的項目:

Xfire：http://xfire.codehaus.org
? Next-generation SOAP Framework，使用Stax，支持JavaEE 5一系列最新標準，支持各種Binding和自己最簡單的Aegis Binding，還拖上了Spring的手做到非常簡單的發布。Axis的事實標準地位該不保了吧。

Grails: http://grails.codehaus.org
?????Groovy On Rails，底層使用封裝過的Hibernate和Spring，Javaer們最最親切的Rails--見?各系Rails大點兵

Drools： http://labs.jboss.com/portal/jbossrules
??? 開源規則引擎里最好的了，雖然比不上死要錢的ILog。但加入了JBoss陣營已經很強悍，有IDE，有很流氓的DSL寫法，語法也已非常貼近ILog.
??? 找個好靠山，支持Spring，增加IDE Plug-in，這幾乎成了每個開源方案的成名之路。

ExtremeTable: http://www.extremecomponents.org
?????DisplayTag 的Killer。沒想到TagLib日漸式微的時候，還有Extreme Table這么設計優良，身光頸靚的尤物 new born，實在鼓舞人心。目前的功能已經強了DisplayTag好多個馬位，但站長依然雄心勃勃的繼續著RoadMap。

Pentaho:??www.pentaho.org
?????商業智能方案，最核心還是基于Mondrain+JProvit的經典窮人OLAP通用方案，但在整個流程和工具上花了很多功夫。
??
Compass: http://www.compassframework.org/
???? 基于已成事實標準的Lucene，又和Spring，Hibernate搞在一起的全文搜索方案，是集成方案，not only 引擎。

Daffodil Replicator:? http://www.daffodildb.com/replicator/
?????通用的多數據庫synchronization方案，能夠通過配置策略解決數據庫異構和數據沖突。

LifeType:?http://www.lifetype.net/
????php的成熟多用戶Blog應用，原名Plog，有著很好的插件機制，對php的OO、模板、adodb應用都非常成熟，是個學習php應用的藍本。Javaer整天忙著換框架，根本沒時間沉淀出這樣成熟的應用。

Joomla:?? http://www.joomla.org/
???? php的CMS 方案?Mambo的開源分裂版，基礎的MVC架構比XOOPS弱，但長得好看就是她的資本。


????隨時更新中.....

     反射，所有教科書都正兒八經的講了，這里只能再隨便講兩句。

     反射是一種讓框架能夠根據 "以字符串形式存在的信息" 來調用對象的屬性和函數的技術，是Java對C++最大的進步之一---讓框架編程真正走向平民化。MFC年代，無論侯捷如何深入淺出，還在念大學的我就是搞不懂那些注冊"消息--函數映射"的魔法宏。

     不過Java的反射也就是對著C++比較自豪而以，因為C#,Ruby,Python甚至php都標配了反射的功能。而且，人家的反射語法都是內嵌在基礎Object類的，拿最弱的php來看：
     而Java，卻搞出了Class，Methed, Field，Constructor這么一大堆類出來。本來這是Java設計師很嚴謹，很cool的體現，問題是它居然不提供一種集成的簡便的寫法......相同的情形還出現在Java的I/O 類庫里。
    微軟這方面就做得好些，懂得討好開發人員。

    因為Java的無情，就搞得大家的項目里要自制BeanUtils了。幸虧Apache Jakarta Commons 已經做了一個比較好的，可以直接使用--以前寫的介紹文章。
    另外Spring也做了一個。

    閑得沒事做的，還可以emule一本〈Relection in action〉回來看。

    而C++下面的"反射"，見我偶像di文章。另還有一個比較BT的C++框架叫ACDK的，把自己整得和Java很像，有反射和垃圾收集，甚至和JSDK差不多的線程，Unicode，I/O，網絡，XML API。可惜的是，即使到了C++0x, B大叔還是不準備在語言級支持反射。

系列文章：
Java下的框架編寫(1)--序
Java下的框架編程(2)-對泛型的無聊用法和為擦拭法站臺 
Java下的框架編程(3)--關于反射的碎話 
Java下的框架編程(4)--Annotation vs XML vs Interface 最新一Round 
Java下的框架編程(5)--cglib應用
Java下的框架編程(6)--asm(待寫)

    作者：江南白衣
　從8i到10g，Oracle不斷進化自己的SQL Tuning智能，一些秘籍級的優化口訣已經失效。
   但我喜歡失效，不用記口訣，操個Toad for Oracle Xpert ，按照大方向舒舒服服的調優才是愛做的事情。

1.Excution Plan
     Excution Plan是最基本的調優概念，不管你的調優吹得如何天花亂墮，結果還是要由Excution plan來顯示Oracle 最終用什么索引、按什么順序連接各表，Full Table Scan還是Access by Rowid Index，瓶頸在什么地方。如果沒有它的指導，一切調優都是蒙的。


2.Toad for Oracle Xpert
    用它來調優在真的好舒服。Quest 吞并了Lecco后，將它整合到了Toad 的SQL Tunning里面：最清晰的執行計劃顯示，自動生成N條等價SQL、給出優化建議，不同SQL執行計劃的對比，還有實際執行的邏輯讀、物理讀數據等等一目了然。


3.索引
   大部分的性能問題其實都是索引應用的問題，Where子句、Order By、Group By 都要用到索引。
   一般開發人員認為將索引建全了就可以下班回家了，實則還有頗多的思量和陷阱。

3.1 索引列上不要進行計算
      這是最最普遍的失效陷阱，比如where trunc(order_date)=trunc(sysdate), i+2>4。索引失效的原因也簡單，索引是針對原值建的二叉樹，你將列值*3/4+2折騰一番后，原來的二叉樹當然就用不上了。解決的方法:
　 1.　換成等價語法，比如trunc(order_date) 換成

　 2.    特別為計算建立函數索引

    3.    將計算從等號左邊移到右邊
　這是針對某些無心之失的糾正，把a*2>4　改為a>4/2；把TO_CHAR(zip) = '94002' 改為zip = TO_NUMBER('94002');

3.2 CBO與索引選擇性
     建了索引也不一定會被Oracle用的，就像個挑食的孩子。基于成本的優化器(CBO, Cost-Based Optimizer)，會先看看表的大小，還有索引的重復度，再決定用還是不用。表中有100 條記錄而其中有80 個不重復的索引鍵值. 這個索引的選擇性就是80/100 = 0.8，留意Toad里顯示索引的Selective和Cardinailty。實在不聽話時，就要用hints來調教。
     另外，where語句存在多條索引可用時，只會選擇其中一條。所以索引也不是越多越好：）

3.3 索引重建
     傳說中數據更新頻繁導致有20%的碎片時，Oracle就會放棄這個索引。寧可信其有之下，應該時常alter index <INDEXNAME> rebuild一下。

3.4 其他要注意的地方
      不要使用Not，如goods_no != 2，要改為

      不要使用is null , 如WHERE DEPT_CODE IS NOT NULL 要改為

3.5 select 的列如果全是索引列時
   又如果沒有where 條件，或者where條件全部是索引列時，Oracle 將直接從索引里獲取數據而不去讀真實的數據表，這樣子理論上會快很多，比如

當order_no,order_time,shop_no 這三列全為索引列時，你將看到一個和平時完全不同的執行計劃。

3.6 位圖索引
     傳說中當數據值較少，比如某些表示分類、狀態的列，應該建位圖索引而不是普通的二叉樹索引，否則效率低下。不過看執行計劃，這些位圖索引鮮有被Oracle臨幸的。
 

4.減少查詢往返和查詢的表
這也是很簡單的大道理，程序與Oracle交互的成本極高，所以一個查詢能完成的不要分開兩次查，如果一個循環執行１萬條查詢的，怎么都快不到哪里去了。

4.1 封裝PL/SQL存儲過程
　 最高級的做法是把循環的操作封裝到PL/SQL寫的存儲過程里，因為存儲過程都在服務端執行，所以沒有數據往返的消耗。

4.2 封裝PL/SQL內部函數
  有機會，將一些查詢封裝到函數里，而在普通SQL里使用這些函數，同樣是很有效的優化。

4.3 Decode/Case
　 但存儲過程也麻煩，所以有case/decode把幾條條件基本相同的重復查詢合并為一條的用法：

4.4 一種Where/Update語法

5.其他優化
5.1RowID和ROWNUM
     連Hibernate 新版也支持ROWID了，證明它非常有用。比如號稱刪除重復數據的最快寫法：

 

6.終極秘技 - Hints
   這是Oracle DBA的玩具，也是終極武器，比如Oracle在CBO,RBO中所做的選擇總不合自己心水時，可以用它來強力調教一下Oracle，結果經常讓人喜出望外。
   如果開發人員沒那么多時間來專門學習它，可以依靠Toad SQL opmitzer 來自動生成這些提示，然后對比一下各種提示的實際效果。不過隨著10g智能的進化，hints的驚喜少了。

7. 找出要優化的Top SQL
    磨了這么久的槍，如果找不到敵人是件郁悶的事情。
    幸虧10g這方面做得非常好。進入Web管理界面，就能看到當前或者任意一天的SQL列表，按性能排序。
    有了它，SQL Trace和TKPROF都可以不用了。

   作者：江南白衣 

   除開五大或者ThoughtWorks這種要什么有什么，進去做打字也能光耀門楣的不談。如果是嫁到一個普通軟件公司，怎樣的環境才能最快的成長呢？
   首先基本的公司項目管理水平是必要的；其次是穩健而不保守的公司技術選型和一班能溝通的同事。

    更重要的，是要有一個嚴苛的環境，那些古訓說的都沒錯，越是嚴苛，成長越快。 然后有些引導與助力，讓你在嚴寒中節省體力，過得好些的，就是最佳的成長環境了。

    一，最復雜多變的業務規則，最難侍候的客戶
         大多數人碰上這兩樣東西都是愁眉苦臉，天天抱怨。其實應該把它視為入門鍛煉的：
        第一階是努力用細密的編碼迎合復雜的業務，以金牌服務的態度接受客戶的善變和每樣需求都要24小時有取的bt。充分打磨過的眼耳口心，才是個合格的IT人。如果業務規則都清的像水，項目時時都是以我為主的，反是在做toy application，不算入了IT的門。
       打磨之后，如果肯靜下心來總結，設計架構如何適應改變，流程如何做到快速更新部署，就是第二階段的進步了。
       一直做ERP，自問有足夠復雜的業務(因為不熟悉業務，有些不復雜的也變復雜了)和麻煩的客戶(自己不是大公司，麻煩的客戶就會很多)，但在第二階段還是不很靜得下心。

    二，最嚴格的性能要求，準確性要求，錯誤恢復要求
        最好是那種每天N萬人訪問，幾億條數據。還有準確性很嚴格，分分鐘幾十萬上下，如果崩機又要迅速完全恢復狀態的項目。
         每天幾萬人訪問的項目沒做過，遺憾。
         幾千萬條數據的項目倒是每天面對，優化學了一點，但沒有充分利用嚴格的環境去追求改進，遺憾。
         ERP的報表倒是經常會搞到幾十萬上下的差額，但一直重視不足。
         崩機恢復是最近的項目要求，更爽是這個項目澳國政府居然有一份規范，我說的助力就是指這些了，不用自己慢慢摸索而且經常摸錯地方。

    三，最底層的編碼
         不要老是高高在上的搞ERP搞.com，偶然嘗試一下用到起碼C一級的語言，和硬件打打交道，直接寫IO口阿，中斷阿，都是有就不要放過的鍛煉。
         沒做過底層編碼，只會純軟件的IT人的感覺是不完整的。
         剛好公司最近的項目有要求，捧一本〈Linux Device Driver〉看看。

    四，最高層的設計
        設計、框架--技術人一聽就眼紅的字眼。但不是每個公司都搞很產品化的項目，或者在項目里自寫類庫重做輪子。所以，除了剛入行的那段瘋狂日子，很高階的設計其實我也沒做多少，多數時間都是應用層的開發。

       雖然自己不寫，但卻經常都要進行框架選型，也算是蒸發智力的一個地方。Pragmatic Programmer里說的critical的態度很重要，Spring好么？一定要想清楚它好在哪里，不要糊里糊涂的看著quick start就入局了，渾忘了without Spring的世界是怎樣的。

       另外，因為有時候開源軟件有bug，或者要增強它來吻合項目需求，或者有錯了不明就里時直接讀源碼會更快找到錯誤。這樣就接觸到不少優秀開源項目的源碼，比如Spring，無形中也會學到他的設計。
        
       如果說Java盛產框架型的項目，php的項目則多是熟透了的Web應用。最近發現php不是以前的php了，應該算入python,ruby一類的動態OO語言，它的那些著名項目一樣有著很好的MVC框架。細看之下學到應用設計方面的不少東西。
       
             
     一陣發呆打了這篇字，其實也是提醒自己，目前的環境可以，應該以更好的心態接受更嚴苛的歷練，那些古訓說的都沒錯。

  作者：江南白衣 

《Modern C++ Design》里的Policy-Base Class是Cpper得意的一樣事情;
  Spring 式IoC container 的依賴注入是Javaer得意的一樣事情;
  Ruby的Mixin特性是Rubyer得意的一樣事情。

  有趣的是，各自得意的事情，指向的是同一個問題：多重行為的組合。

   1 .Policy-Base是混合使用模板與C++的多重繼承達成的：
      最終類多重繼承模版類，由模版傳入實際的行為類(Policy Class)。

    上段代碼，在編譯期把NoChecking類傳入到SmartPtr中，組合成noCheckPtr類。而實戰中，還會用到"template template parameter"....

   2 .Java則緊守最古老的委托模式來達成：
     最終類擁有實際施行各種行為的行為類的指針。所有最終類的方法都將委托給行為類來執行。如果行為多樣時，采用基于接口編程。同時利用Java的反射特質，用IOC Container根據配置實現注入的自動化。

   3. Ruby則倚仗自己的動態特性，直接在語言中內建了Mixin特性。
      
此段代碼將Greetable類Minxin進了Person類里頭，讓其擁有了greet方法。
也多虧了Ruby的動態性，讓Greetable可以打印一個自身毫不知情的，其實屬于Person的屬性age.

就因為同一樣事情還有著C++模板、傳統Delegate和新興動態Minxin的選擇，讓我們這些工蟻，還覺得有些許的自由和左顧右盼的樂趣。

    作者：江南白衣 

     昨天翻翻《程序設計實踐》的Debug一章，里面用C寫的例子早已被風吹的沒了顏色，不隨語言流轉的就只有結尾那幾句經驗談。但大學里向來是連這幾句話也懶得教的，一定要大家從“put print statements in the program to find the bug” 開始，和bugs共同生活幾年后，自個養成條件反射式的debug習慣。

     面對Bug，正確的生理反射應當是找線索而不是直接跳到Step 2蠻干：
        一、找熟悉的模式。人應該了解自己當然也包括自己常犯的錯誤，還有是檢查那些經常犯事的代碼模塊。
        二、最近改過的代碼。
        三、如果錯誤是由特定數據和操作引起的，思考這些輸入的特征。
        四、如果是系統模塊輸出的錯誤，第一時間拷下來google。(不過也要提防有些系統的輸出信息完全不靠譜)

    找沒找到線索，然后都要開始定位錯誤。
    定位的方法，是經典不過的--分而治之：注釋一些代碼，減少、hardcode一些輸入值和中間值，函數返回值等等。
    如果沒有明顯的線索，可單步執行，同時察看多個變量的debug工具就要及早出場，它能讓你看到程序實際的執行情況而不是你思想里早就預設的誤區。
    不過，斷點設在哪里，先注釋、hardcode哪些代碼這種深刻決定debug效率的抉擇，就很講經驗和最近的運勢了！

     如果埋頭苦干都沒有結果，那可能是思維有了誤區，就該拉個人過來和你聊一下天氣和這個bug啦(但是注意別拉到太笨的，雞和鴨講的)。又或者，再回頭看看是不是一些極低級的錯誤，比如鏈接庫的版本錯啦，根本沒有重編譯啦....

     改完bug后，好習慣是再看一眼別的地方中會不會還有同類的蟲蟲沒殺掉。

    ----延伸閱讀《Code Complete 2nd》中Debugging 一章。

   按照SWIG的思路，C/C++是很優秀的library級代碼語言，而寫界面等方面則是Java、C#、Python們占優。所以，swig讓你可以在高階語言里調用C/C++寫的類庫，并且不是簡單的跨語言調用，而是把類庫編譯為宿主語言里Class這樣的一等公民。
    原本擔心這個項目有點邊緣化，一看原來Ruby和Python早就靠它從C/C++里溜東西出來了。對于python, ruby這些家底不厚的新生代來說，C/C++的類庫很有魅惑力。即使是富得不行的Java，也靠swig為SDL搞了個java版。
      
1. 實現原理：
    比如Java吧，有一個JNI機制可以直接調用C代碼，但要求C代碼需如是：

JNIEXPORT void JNICALL Java_HelloWorld_displayHelloWorld(JNIEnv *env, jobject obj) 
{
    printf("Hello world!\n");
    return;
}

   SWIG(Simplified Wrapper and Interface Generator) 為你自動生成了這個冗長的wrapper文件和相應的Java類，其中還妥善完成了類型轉換，函數指針、模板這些C++功能在其他語言中的轉換等諸般工作，善舉阿。

 2.操作過程： 
    很簡單，特別在VC里dsp文件都寫好了，把選項設為Release，rebuild一下就搞定。
    如果要拆成慢動作，在一個Java項目里是這樣的：
   1.編寫interface文件example.i
     如果api有頭文件就更簡單了，下面的代碼定義一個example類
  

%module example
%{
#include "example.h"
%}
%include "example.h"

    2.  swig -java example.i  
     生成符合JNI語法(見上)的C文件： example_wrap.c
     生成Java類文件：exampleJNI.java，example.java

    3.VC把example_wrap.c 和example.c 打包成dll. 

    4.在普通java程序里使用example.java
 
  3.總結
    當你山窮水盡，準備要重新發明輪子的時候，總該想起有個swig，可以把C/C++的輪子，換裝到你的語言上。

   當GM向我拍下一張使用Linux與C的游戲單子時，眼前頓時冒出了蘭波的名篇.......   
   幸好，一切墮落都有一個美好的開始:

   1.另類唯美的SuSe Linux 10
       Windows與Linux的百年大戰中，桌面系統這塊向來是Windows最高枕無憂的鐵桶江山。不過這次，另類的Suse 在上面輕輕的撬了一塊磚。
       首先是界面，選了KDE、Suse-default的外觀主題后，在我這樣的美學形式主義者看來，Suse PK WinXP絲毫不落下風，對上Win2000就是穩勝。
       更重要是Suse的易用性也做得很足。每次點右鍵總有貼心的功能出現，WinXP可能得裝上Power Toys之類插件才能相若，還有美麗的Yast控制面板，還有所有軟件包的自動在線更新。
       而且，Suse帶的一系列K字頭的軟件也不含糊，寫字板Kate可以匹敵UltraEdit，Konsole是很好用的console，KDE 即時通信能同時連通MSN等im軟件.....雖然應用的數量還是不夠，但現在google和它代表的主義橫行，越來越多應用移到了互聯網上，只要FireFox持續更新，微軟在桌面應用上的優勢就會被稀釋。
 
       不過，Suse Linux 應該算是Linux中的一個另類。看一下Redhat的fedora core 4，就能發現丫還很忠實的保留著Linux桌面難看難用的傳統。不過這個另類唯美者可沒兼有低調的美德，google一下就能看到"Novell揚言Suse 9.3要讓Windows下課" 的宣傳。我覺得，那至少先要解決桌面程序的運行速度問題。

  2. 萬年不變，詭異莫測的make
       雖然Suse很好，但很快又要面對make這個家伙。在我經歷里，能夠順順利利輸完下面這三行指令，然后安裝完畢的程序太稀有了。
 
       這次要裝一個使用SDL庫的游戲，果然又是如此。
       首先報找不到libSDL_image.so，結果發現原來/usr/lib里這個so帶了版本號:libSDL_image_1.2.so，加link搞定。然后又報找不到SDL_image.h，跑去SDL主站下了源碼補上...
       都2005年了，問題還是這樣層出不窮，飄忽不定，團隊里如果沒有久經摔打的老將，經常會被搞得手足無措，目光呆滯。

3.復雜化的趨勢讓人很害怕的內核模塊HelloWorld
       因為要直接操控IO口，所以稍稍看一下內核模塊的東西。天降一本〈Linux 設備驅動程序  2nd〉中文版，hello.c 很簡單，而且gcc -c hello.c 就能完成編譯。
      但輪到我gcc的時候，卻出來兩屏的錯誤。沒想到自己的人品值急降到這個程度，愣了好一陣，才發現這本"中文版"講的是linux kernel 2.4的事情，到2.6已經變天了。只好重新emule一本講kernel2.6的第3版，再配合google，才明白2.6里hello.c變了，還需要預裝kernel-devel，更需要使用新鮮kbuild系統來編譯：
       首先寫一個不明所以的不完整Makefile：
    
       然后用這條指令來編譯，才得出新的hello.ko 文件:

       更倒霉的是我一開始用的Suse 9.3居然沒帶kernel-devel.rpm，搞得我又要用kernel-source，配置、編譯一遍內核....
  
      都一把年紀了，還要為了個helloword被這樣拖著滿場飛奔，實在是糟糕透頂的經歷，而且，2.4->2.6里復雜化的趨勢更讓我還在門外就覺得有點涼意。  
       如果程序世界不是越來越簡單，而是越來越復雜；越來越多東西不能靠過去的經驗發揮同理可證的作用而需要完全重新學習，那我們這些老家伙的飯碗不是很危險嗎???