牙牙窩

初衷是希望有一個簡便，不需要配置文件的辦法，提高數據層的事務處理能力。以及對連接池的支持。

解決思路是通過修改Spring框架，修改BeanFactory的類搜索機制，默認載入相應的類。

并采用繼承的方式，在基類中提供默認方法，允許Spring注入在對象實例中。然后再對象實例中調用。

    最近項目組要求使用普元EOS進行項目開發，使用了兩個月左右，雖然說有一些心得（這個以后會寫出來），但更多是看到了不足的地方，在這里就討論一下一個成熟的應用框架到底應該有哪些因素。

底層技術：
    Application Framework（下稱應用框架）是為解決問題而生的，無論是基于JAVA、C++、Ruby等等語言，都必須有基礎技術的支持。如JAVA就有經典的Struts+Spring+Hibernate的組合，因此，一個成熟的應用框架，必須擁有完善的MVC框架，以及完整的業務組件管理容器，還有一個成熟的數據訪問框架。這個是一切的基礎。

權限管理：
    擁有一個成熟基礎權限架構能夠為應用框架增色不少。如果能夠和框架本身更好地融合，這樣更好。其實目前有很多實現是俄可以借鑒的，如：ACEGI和Spring。

UI：
    標簽已經非常流行，擁有完善的標簽庫是必不可少的，Struts是個很好的典范。
    Ajax大行其道，如果沒有整合一些方便易用的AJAX控件，估計也算不上是一個好框架。
    另外還有類似于Freemarker、Velocity之類的簡化UI開發的好東東，整合一兩個，對于減少開發、提高維護性有很大幫助。

開發工具：
    提供敏捷快速的開發工具是一個成熟應用框架所不可或缺的。使用一個成熟的應用框架的開發工具進行開發，可以讓開發者最大程度減少對于技術上的瓶頸，讓開發者很輕松就可以完成高質量的代碼，剩下的精力可以用于專注于業務等其它方面。
    另外還有像：單元測試、應用部署等等方面，都是必不可少的一部分。（PS：我是非常痛恨維護幾百行ANT的build.xml代碼的人）
    這里不得不稱贊一下普元，普元提供的開發環境和它自身的底層技術融合的非常好，對于開發者而言，是非常方便的，可以不需要很多的培訓就可以使用IDE開發出完整的應用。而且測試和部署都很方便。

代碼生成器：
    其實這個應該和開發工具放在一起，但是因為比較重要，所以單獨提出來說。
    一個好的代碼生成器可以省去開發人員很多不必要的麻煩，能夠非常大地提高開發效率。普元的代碼生成器是個不錯的典范。
    我們公司自己也有一個JOP的應用框架，但非常簡陋，和普元的設計思想不可同日而語。呵呵～～有點扯遠了，但能夠看得出，代碼生成器對于應用框架是必不可少的。

協同開發：
    整合一個好的協同開發和版本管理工具，能夠最大程度地降低溝通成本。除了能夠支持類似SVN或VSS之類的代碼版本管理工具之外，還應該融合進類似Visual Studio Team的任務管理和缺陷管理工具。最好擁有一個可以進行自我積累的知識庫的實現。WIKI是個不錯的主意。

設計器：
    我提出這個是因為看到了IBM的RUP，擁有一個能夠從設計到代碼實現乃至后面的測試這樣一個全流程開發工具，一直是IT人員的一個美好夢想。
    一個好的設計器，可以很輕松地在設計圖和代碼之間相互轉換，對于需求變更，設計管理、甚至項目后期的文檔都有很重要的意義。
    這里又要提到普元，普元在這方面很聰明，走了一條不同的路，它把代碼變成一個個圖標時，本身就實現了對于設計圖和代碼之間互轉關系。（當然，實現的方式有點土，而且沒有辦法支持標準的UML）

運行容器：
    大家可能覺得奇怪，容器為什么要單獨提出來說，很多JAVA開發者都會說，只有遵循JAVA標準就可以啦～。其實不然，一個成熟的應用框架當然要考慮其兼容性，但是有時候，過多考慮兼容性往往會犧牲效率。事實上，很多應用框架被開發出來，都是有一定的局限性的使用場景，針對使用場景的環境進行優化，絕對比使用通用的方法效率要高的多。如我們公司的移動項目使用的是WebSphere，我們的框架就有一個針對WebSphere優化的版本，但同時也存在一個通用版本。
    當然還有其它方面也可以引用這種思路，比如使用Oracle自帶的一些JDBC類，其效率就比使用JAVA標準的JDBC類要高得多。

    其實應用框架被創造出來的目的就是快速、高效、低成本地解決問題，這個大家都知道，但是何謂“成熟”，估計100個人應該有100個答案，這里我的理解就是開發快捷、較低的學習成本、運行穩定，就是一個成熟的應用框架。

PS：上面好像說了一些不少普元的好話，大家千萬不要以為我是普元的“托”，晚點我再寫遍罵它的文章吧～～呵呵～～。其實我更喜歡SpringSide，但是除了“底層技術”這塊之外，在其它方面還有很長的路要走，希望江南白衣兄能夠堅持下去。

    今年真的是郁悶透頂了。項目組居然叫我去做我從來沒有做過的接口方面的編程，搞得我焦頭爛額。

    因為沒有經驗，寫的代碼亂七八糟，出了好多問題，不過，也學了不少東西。

    首先就是Socket的編程，我只是在學習JAVA時寫了一些socket方面的例子，從來就沒有仔細研究過，組長居然叫我設計一個JAVA的接口平臺。胡弄了一通之后，系統上線了。但是問題就來了。

    首先第一個問題，長連接必須有心跳。因為之前協議中沒有定義心跳協議，而我又沒有經驗，所以等真正上線之后才發現，如果長連接沒有心跳，很容易導致在Socket連接中，長時間沒有通訊的話，就會導致連接雖然保持，但不能正常通訊的問題。

    第二個問題，必須加入流量控制。這個問題出現在業務高峰期時，會接收到大量請求，這時業務系統的處理速度跟不上請求發起方，導致大量請求積壓在Socket服務器端，導致JVM崩潰。這個問題我之前是使用了JAVA5中所帶的ExecutorService，通過設置固定的線程池數量的方式做流量控制，后來發現不行，線程會不斷增加，導致JVM崩潰。不知道是我代碼問題還是ExecutorService本身的問題。建議使用BlockingQueue來做隊列，我目前用起來還是比較穩定。

    第三個問題，是由上面的問題衍生出來的一個問題，就是效率問題。我之前的線程處理方式是每接到一個請求，會在主線程實例化一個線程實例，再把線程放到線程池中運行，這個方式除了導致上面的問題以外，而且效率很慢，我稱之為“推”的方式。現在經過改良后，在服務起來之后，先事先運行固定數量的線程，然后所有線程都從同一個BlockingQueue中獲取指令，我稱之為“拉”的方式。這種方式讓程序效率提高了很多，省去了每次生成對象的過程。而且這個設計本身也實現了處理量的控制。

    第四個問題，就是指令的返回問題。在處理每個異步指令的過程時，對于返回指令，通常的做法是將返回結果指令放入隊列中，然后再逐一返回。這個做法就存在了一個隱患，就是當服務器的進程core掉，或者因其它原因中斷，所有的返回指令都會丟失。建議的做法是在得到返回指令之后，將要返回的結果指令持久化，通常是放入數據表或者緩存文件中，然后再操作，這樣的話，當重啟進程，也可以重新讀取返回指令，最大可能保證接口的數據準確性。

    第五個問題，其實跟上面有一些接近，就是做接口程序，有一個大原則，就是一切有跡可尋。在受理時要寫日志，執行業務時要記錄、返回結果時要入庫。總之讓運維人員可以很方便的定位問題，排除問題。否則，只能麻煩自己啦！

    至于其它錯誤我就不一一羅列了，總之在錯誤中進步，還是學到不少知識。呵呵～～

???非常有幸能調到公司的J2EE基礎架構組，負責為公司預研一套完整的架構模型。主要是引入SOA、WorkFlow、AJAX等新技術。
???
???做了開發人員這么久，也做了這么久項目，根本就沒有時間好好坐下來研究一下新技術。現在必須先跟一跟潮流，看看那些流行的技術以及概念了，呵呵。。。。。。

???研究主要是分三個方向：UI、BPM/SOA、構件化。希望能在這幾個方面有所收獲吧！努力努力！！！

1 ：毛巾擦身的鍛煉減肥
把毛巾浸在冷水 ( 自來水 ) 中擰掉 大部分水后，依次推擦上肢、下肢、腰部、后背、頸部、腹部、胸部，每一部位反復推擦 10—20 次。在推擦中反復浸洗毛巾，以保持一定的低溫及濕度。
冷水擦身可以消耗大部分熱能。熱能是身體內的糖、脂肪所轉化，故消耗熱能，即是消耗糖和脂肪，促進糖和脂肪代謝，起到調膚美顏的作用。（現在是冬天了哦 ^-^ 不知道你能不能堅持。還可以抗感冒的） —— 我估計這個方法我是不成了，麻煩不說，身處北方還要用冷毛巾，我只能給自己一個結論 —— 找死。

2 ：曲米茶

把粳米像炒瓜子一樣炒至焦黃再煮成粥，這個叫曲米茶。聽說原理是破壞主食中的淀粉，變成了活性碳，還能刮油呢。聽說還能緩解便秘。我在夏天的時候吃過，雖然沒有大的感覺，但是我想總比吃過多的主食擔心發胖要好。

3 ：拍打局部

哪里胖就拍打哪里，打紅了為止，還要配合揉、捏、推擠等手法，總之讓肉動起來。要是有貝貝油就好了，減少點摩擦肚子還能好受一點，要不會很疼。

懶人減肥食譜

1 ：早餐，曲米茶一碗。 早飯與午飯之間蘋果一個，要切成小瓣，分幾次吃掉。橘子半個吧。

2 ：午餐，曲米茶一碗，中午適當的吃些蔬菜，但是不能多。 午飯與晚飯之間蘋果一個，橘子半個。

3 ：晚餐，曲米茶一碗，配合適當的蔬菜。 睡覺以前最好什么都不吃，要是餓了呢，就喝牛奶 120 克 ，多了浪費。

減肥期間少吃含鹽高的食品，減少喝水次數。別人我是不知道，但是我自己我非常清楚，喝水基本對減肥起不到好的作用，還很有可能誘發濕疹，曾經有過一次慘痛的教訓。白水改為紅姜茶，有排毒功效。配合一天兩次的局部按摩，主要集中在身體中段，主要針對我的 3 層游泳圈。

健康的減肥計劃即將開始了， 堅持就是勝利！！

??????? 這個題目有點老土，因為別人用過了。但經過這段時間的觀察，發現聚合的能力

已經開始慢慢延伸，已經成為了一種文化。已經沒有人能躲開這個大潮的來臨。

??????? 既然不能躲，那就迎上去吧！

??????? 關注Web 2.0，其實就是關注網絡的走向。冒昧的說一句我的理解：Web 2.0 = 聚合力

　面對電腦時間長了不好，那該怎么辦？其實每天四杯茶，不但可以對抗輻射的侵害，還可保護眼睛。

1.上午一杯綠茶：綠茶中含強效的抗氧化劑以及維生素C，不但可以清除體內的自由基，還能分泌出對抗緊張壓力的荷爾蒙。綠茶中所含的少量咖啡因可以刺激中樞神經，振奮精神。不過最好在白天飲用，以免影響睡眠。
2.下午一杯菊花茶：菊花有明目清肝的作用，有些人就干脆用菊花加上枸杞一起泡來喝，或是在菊花茶中加入蜂蜜，都對解郁有幫助。
3.疲勞了一杯枸杞茶：枸杞子含有豐富的β胡蘿卜素、維生素B1、維生素C、鈣、鐵，具有補肝、益腎、明目的作用。其本身具有甜味，可以泡茶也可以像葡萄干一樣作零食，對解決“電腦族”眼睛澀、疲勞都有功效.
4.晚間一杯決明茶：決明子有清熱、明目、補腦髓、鎮肝氣、益筋骨的作用。

轉自：http://javasky.bloghome.cn/posts/3382

??????自從在《程序員》里提出Web 2.0 的到來，以及AJAX的出現，新的網絡開發模式將漸漸到來。

以往的編程方式是從C/S到B/S的過渡，將代碼封裝服務端。然而在未來的兩年，語言的開發平臺將會由

現在的針對B/S的服務端編程逐漸轉向RIA的轉變。

??????現在已經出現了許多RIA的支持者，比如大名鼎鼎的Micromedia、以及Google等著名的IT公司。

RIA的解決方案也層出不窮，其中各有優劣。

??????RIA有許多好處，比如現在的B/S模式將所有的業務邏輯和操作都封裝在服務端，而用戶必須忍受

不斷刷屏的痛苦。在使用的Rich Client開發的模式，可以將復雜的邏輯處理在客戶端處理，真正交互時

再提交到后臺。而且利用XMLHttpRequest的特性，把交互的動作進一步封裝，這樣在用戶體驗上會大大

提高。因此，面向瀏覽器編程會漸漸成為B/S系統的主流編程方式。

??????在各種客戶端腳本語言中，Javascript無疑是最優秀的。申請這個blog就是希望開始留意Javascript的

發展，以及記錄自己的學習軌跡。