論劍歸來（一）

應朋友邀請，周六早從上海出發往杭州參加阿里巴巴網俠大會。同行四人，有銳道的macro chen、楊光（還是我師弟）、移動的王偉旭（特長是linux和網絡安全，也是中國linux推廣的先驅）。一路上，言談甚歡。老莊給我們訂的票，他一早腸胃有恙，仍然堅持把票送到火車站，之后去吊鹽水，下午又出現在會場。確實精神可嘉，建議阿里巴巴頒發“最佳精神獎”。

到杭州已是中午，錯過了上午大會。下午Robbin進行Java技術展望和RoR實現REST的演講，既然是朋友，肯定是要捧場的。Robbin旁征博引，以其深厚的技術功底和對新技術的敏銳洞察贏得了聽眾。

晚上一堆人去聚會，各路豪杰紛至：有阿里巴巴的，有自己創業的，有技術大牛，還有媒體（Infoq），出版社（博文的周總領3員大將赴會）。大家互換名片，認識的不免寒暄幾句，不認識的也很快就熟捻了，還不時有“原來你就是×××”的驚呼，原來網上就“互通心曲”，只是一直沒機會認識罷了。

席間觥籌交錯，具體內容暫且不表，只說一件令我感受頗深之事。一個阿里巴巴的員工表現出對公司的無比忠誠，講起公司的獎懲制度，說是一個員工的績效不僅跟所在項目相關，還與部門、其它部門甚至整個公司的業績相關。所以只要是對公司有利的事情，即使與自己現在的工作無關，他們也會去做。按常理來說，這有點不公平，我只能努力做好自己的事情，而如果別人不努力，我就是白做。但如果大家都努力，又變成了共贏。

這里讓我講一個簡單的博弈問題，就是“囚徒困境”。A和B兩個同犯被抓，因為沒有其它任何證據和證人，只能讓2人分別交供。如果A和B都矢口否認，那么兩人無罪釋放。如果A承認，B不承認；A是坦白從寬，判1年；B抗拒從嚴，判5年，反之亦然。如果2人都承認，ok證據確鑿，各判2年。如果2人都是理性人，且沒有互通消息，按照博弈，每個人的最優解就是承認，也就是各判2年。其實對2人真正有利的就是打死不承認然后都無罪釋放，而這種狀態在理性人的假設下是很難實現的--除非有一個教父，一直灌輸他們不要出賣同伙。

馬云就是這個“教父”！

卡內基有篇文章，我總結成一句話就是：用崇高的理想打動別人。據說馬云一直是以個人魅力及“創造中國電子商務的明天”類似的理想，激勵員工的。有了統一的企業文化，員工都不計較個人得失，努力奮進，最終企業和所有員工取得共贏，這絕對是擺脫“囚徒困境”的典型案例。

話說回來，阿里巴巴能讓你感受到團隊的力量，一群精英在一塊做很有價值的事情，對每個人也是很好的鍛煉。個人認為，如果有吃苦耐勞的打算，眼光放長遠點，又沒有其它方面的束縛，阿里巴巴的確是不錯的選擇。（得向阿里巴巴收代言費，呵呵！）

第二天聽了多場論道，主要是SAAS，搜索，分詞方面。結合阿里巴巴的戰略，我把幾點融合起來講一下。這個下篇再細細道來。

 

 

posted @ 2007-05-21 20:35 pesome 閱讀(1133) | 評論 (1) | 編輯 收藏

sitemesh的問題及解決

再說 sitemesh 的問題，同樣是做 openfans 網摘功能出現的。做好了 IE 插件，有 fans 反饋說彈出頁面太大，這也難怪，用了 sitemesh ， head 和 footer 都在頁面上，想縮小頁面，肯定得把 head 和 footer 都去掉，做個干凈點的。既然用了 sitemesh 肯定是希望最方便的搞定這個，而不用動任何邏輯（包括頁面邏輯）。這個好辦，文檔里有說，通過在 sitemesh.xml 中增加

就能搞定，這樣只需要使用參數如 saveSnippet.html?decorator=simple&confirm=true ，就能讓它使用指定的 decorator 。然后做一個去掉 head 和 footer 只保留必要的 js 和 css 引用的 simple.jsp 頁面，同時在 decorator.xml 中配

就應該可以搞定。

但怎么測，就是不使用這個 simple decorator 。沒辦法，只好跟進 sitemesh 源碼中去調試，進入 ParameterDecoratorMapper 類，它繼承了 AbstractDecoratorMapper 類，然后有一個 init 方法一個 getDecorator 方法。各打一個斷點， init 方法在 tomcat 啟動就會執行，也正常初始化了， getDecorator 方法卻始終不調用，一時想不出辦法。看到篇文章說不自己寫 sitemesh.xml 而使用自帶的 com/opensymphony/module/sitemesh/factory/sitemesh-default.xml 也可以，于是備份并刪除我寫的 sitemesh.xml ，居然成功了。為什么我寫的就不行呢？差別一是我的簡化了很多，只有

< mapper

???? class ="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper" >

??????????? < param? name ="config" ?value ="${decorators-file}" ? />

??????? </ mapper >

和剛加的

ParameterDecoratorMapper ，二就是順序，我的 ParameterDecoratorMapper 放在了 ConfigDecoratorMapper 后面，會不會是順序原因呢，調換一下，果然成功了。問題是解決了，原理呢？再花點時間跟一下代碼了解下原理，原來使用了 Factory ，它會調用各個配置的 Mapper 的 init 方法，并放入 map 中，然后到時選擇一個 Mapper ，如果符合條件就使用，否則繼續往下找。這里就有了順序的問題，因為我在 decorator.xml 中使用了

<decorator?name="default"?page="default.jsp">

????????<pattern>/*.html</pattern>

????</decorator>

，這樣如果 ConfigDecoratorMapper 放在前面，他就先找這個 Mapper ，一看 saveSnippet.html?decorator=simple&confirm=true ，符合 pattern 啊，就使用它了，另一個 ParameterDecoratorMapper 根本得不到機會，所以也進不了它的 getDecorator 方法。換了順序就是它先進去，所以執行，其它的 url 也是先找它，但不匹配，就又交給 ConfigDecoratorMapper 了。呵呵，問題也解決了，對 sitemesh 的認識又進了一步。

posted @ 2007-03-11 22:54 pesome 閱讀(2991) | 評論 (0) | 編輯 收藏

中文問題的解決

這次給 openfans 做網摘功能，主體程序倒是很快就寫完了，另外要做個 IE 插件，卻碰到了不少問題。 IE 插件其實很簡單，就是用 js 獲得頁面的標題、 url 和選擇的內容，然后通過彈出窗口，將其送到服務器。這里就有中文的問題了，開始使用 escape ，如 escape(title) 形式， request.getParameter 碰到中文就為 null ，網上搜了一通，說是可以通過 java 編碼搞定，但拿到就為 null 了，還怎么換編碼？忙活了好幾個小時，又是 alert ，又是 document.write ，看上去也沒什么問題。不 escape ，直接在瀏覽器中輸入帶中文的 url ，拿到的不為 null 了，拿到后，通過 new String(str.getBytes("ISO-8859-1"), "UTF-8"); 還真顯示正常了。但用 window.open 又出亂碼了。看到文章說還有 encodeURIComponent 方法可用，就試了下，把 escape 換成 encodeURIComponent 居然搞定了，服務端還是得用 new String(str.getBytes("ISO-8859-1"), "UTF-8") 進行處理。注意這里用的 tomcat ，它的默認編碼就是 "ISO-8859-1" ，如果改了編碼程序也得做相應的改動了。

posted @ 2007-03-11 22:51 pesome 閱讀(1042) | 評論 (0) | 編輯 收藏

hibernate native sql的小技巧

為了性能考慮，使用了 native sql 。因為需要分頁，需要 2 個 sql ，一個獲取 list 一個取得總數。獲取 list 很好寫：

?

?

獲取總數查了下 hibernate 的 reference, 試了幾次才明白用法 :

?1 private ?BigInteger?getCountByNativeSQL( final ?String?sql)? {
?2
?3 ??????? return ?(BigInteger)?getHibernateTemplate().execute(
?4
?5 ?????????????? new ?HibernateCallback()? {
?6
?7 ?????????????????? public ?Object?doInHibernate(Session?session)
?8
?9 ????????????????????????? throws ?HibernateException? {
10
11 ????????????????????? return ?(BigInteger)?(session.createSQLQuery(sql).uniqueResult());
12
13 ??????????????????}
14
15 ??????????????} );
16
17 ????}
18

這里的

sql 是“ select count(*) 開頭的”。這里大家可能要問，為什么要使用 BigInteger ，因為如果用 uniqueResult() 默認就返回 BigInteger ，而 BigInteger cast 成 Integer 會出錯。那么如果我就是要返回 Integer 呢，可以通過下面的辦法實現：

?1 private ?Integer?getCountByNativeSQL( final ?String?sql)? {
?2
?3 ??????? return ?(Integer)?getHibernateTemplate().execute(
?4
?5 ?????????????? new ?HibernateCallback()? {
?6
?7 ?????????????????? public ?Object?doInHibernate(Session?session)
?8
?9 ????????????????????????? throws ?HibernateException? {
10
11 ????????????????????? return ?(Integer)?(session.createSQLQuery(sql).addScalar( " count " ,?Hibernate.INTEGER).uniqueResult());
12
13 ??????????????????}
14
15 ??????????????} );
16
17 ????}
18

大家注意粗體的部分，這里是給一個

alias 賦予類型，那么 sql 就需要變成以 ”select count(*) as count ” 開頭了。

posted @ 2007-03-02 10:52 pesome 閱讀(5255) | 評論 (2) | 編輯 收藏

php5+mysql5+apache2需要注意的幾點

今天為了在本機裝個wordpress玩玩，搞了搞php5+mysql5+apache2。網上搜了一篇文檔，很快就讓php與apache跑起來了，但連mysql始終不行。報錯：Call to undefined function mysql_connect()。查了一下半天，就是php關于mysql的ext沒配好，但我改了php.ini啊，也把"extension=php_mysql.dll"放出來了。查了好久，看到一篇說php5需要加上"extension=php_mysqli.dll"，試了下果然好了。
???? 然后需要以index.php作為默認的welcomefile(不知道怎么叫，web.xml里是這個)，需要在"DirectoryIndex index.html index.html.var"后加上 index.php就行。
然后飛快的裝了phpmyadmin、dvbbs的php版。發現php應用的安裝的確很是方便，解壓，拷貝到htdocs下，馬上就能運行了，比java應用簡單的多，更別提復雜的要死的企業應用了。這點上java要好好向php學習啊。

posted @ 2007-01-14 17:34 pesome 閱讀(1292) | 評論 (0) | 編輯 收藏

開始研究電子支付

項目需要，開始研究電子支付。國外的電子支付提供商，得好好研究它的文檔和api。全是e文，只能慢慢看了。

posted @ 2007-01-12 15:41 pesome 閱讀(1292) | 評論 (1) | 編輯 收藏

準備給openfans添加spring2.0支持

? 學習了下spring2.0。對openfans而言，有2個比較重要的改進。首先是aspectj的支持，可以方便的使用aspectj語法定義aspect和pointcut了，openfans準備在domain object的自動注入上和權限等方面使用aop。另外就是spring form標簽庫的引入，現在springmvc也有自己的標簽庫，以前自己給checkbox和radio寫的request.getParameter可以改寫了。

posted @ 2006-12-28 15:15 pesome 閱讀(1135) | 評論 (1) | 編輯 收藏

一個定時更新cache框架

     摘要: 應項目需要做了一個定時更新的 cache 框架，采用 spring+quartz 很方便的實現，可以適用任何需要定時才更新的地方，比如靜態網頁 cache 等。代碼很簡單： ---------------------------------QuartzCacheHandler-------------------...  閱讀全文

posted @ 2006-12-13 14:46 pesome 閱讀(4131) | 評論 (7) | 編輯 收藏

這次做portal的一些總結（二）

接著前面的寫。上文主要寫了 ajax 在 portal 中的使用，這篇寫集群方面的體會。現在比較流行的架構就是前端 F5 做負載均衡，后面 2 臺 websphere server 做成集群，各自都有 HttpServer ，每個 HttpServer 都向 2 臺 was 做轉發。這樣每臺都能獨立完成從 HttpServer 到 was 的流程。一臺出現故障， F5 首先進行切換，只向正常 server 的 HttpServer 發起請求，這臺 HttpServer 再進行切換只向同一臺 server 上的 was 做轉發。這次 portal 就是采用的這種架構，不妨稱為架構 A 。

另一種簡單點的架構就是只做 F5 負載均衡，不做 was 集群，每臺 websphere server 上的 HttpServer 接受 F5 轉發的請求，只向本 server 的 was 轉發。這樣每臺 websphere server 保持獨立，相互間沒有數據交換和轉發。不妨稱為架構 B 。

架構 A 和 B 各有優劣，適合不同的需要，下面進行些比較：

????????? 從應用部署上看：

A 使用了 websphere 集群，由一個 DeployManager 進行分發，部署應用，只需部署一次，由 DM 分發到幾個節點上。而 B 每個 server 都是獨立的，部署應用只能一臺臺部署，如果 server 較少差別還不明顯，如果達到 10 臺以上，一臺臺部署將是一個比較痛苦的事情。

????????? 從 session 上看：

A 使用了 websphere 集群，可以使用集群提供的 session 復制，對于一些關鍵應用（某臺服務器宕機， session 也必須保持的應用）很有必要。而對于一些能夠允許 session 丟失的應用，才可以使用 B 。當然 A 也可以關閉 session 復制，因為 session 復制不管是使用數據庫方式還是內存方式，總會消耗一定的性能。具體消耗多少性能，就要看不同的 application server 的 session 復制方案了，想深入了解，可以看集群方面的文檔，我也只記得一個比較簡單的 round robbin 了。

????????? 從架構復雜性看：

B 更為簡單，因為沒有 DM 的概念，每臺 server 都保持獨立。而使用了 DM 有時也會出現莫名奇妙的問題，這當然是由于不了解 DM 的機制所致，但總歸也增加了復雜度，這點在后面的教訓中進行說明。

????????? 從水平擴展性上看：

B 肯定更勝一籌。只要 F5 能支持，多少臺 server 都沒關系。而 A 多臺 server 做集群，要看 websphere 支持的節點數量，應該不會太大。這個如果哪位同學知道，敬請告知。

當然 A 和 B 在服務器較多的情況下是可以共存的，可以考慮幾臺機器做集群，然后集群間做負載均衡，這樣既可以減少部署的復雜度，又可以帶來較好的水平擴展。由于沒做過更大型的項目，這個也只是我的假象，請做過的同學斧正。

?

說一說集群中碰到的問題。

????????? 首先是對各節點的同步：

有時為了方便測試，我們只對其中一個節點進行更改，測試通過再放到其它節點。而如果測試周期較長，有時就會造成節點的不同步，出現各種各樣莫名其妙的問題。一個經驗就是：無論如何，在每天下班前要保證各節點的同步，不同步的現象不要過夜。

????????? 然后是對 DM 的理解：

我現在還只是實踐階段，沒有看過相關文檔。從意義上看，它控制了相關的配置文件，如果進行節點同步，就會由它把配置文件同步到它管理的節點上。這對配置文件的修改提出了要求。我們開始只修改節點的配置文件而沒有修改 DM 的，結果進行節點同步就會覆蓋修改的配置文件，帶來很多不必要的工作。經驗就是：或者修改 DM 的配置文件，然后進行節點同步，或者直接同時修改所有節點和 DM 的。

????????? 還有關于 cache 的：

Cache 是性能優化的一個有效手段。在單機環境下，最簡單的就是內存 cache ，使用 static 的 Map 就行。而在集群環境中， cache 就變的比較復雜了。首先還是從應用需求入手，是否要保持每臺機器的 cache 同步。如果只是信息展示等要求不高的 cache ，不需保證 cache 的同步，問題也比較簡單，自己寫內存 cache ，或者使用開源的 cache 組件如 ehcache,oscache 等就可以很好的解決問題。而如果需要 cache 在幾個節點保持同步，就需要特殊的機制了， ehcache 等號稱支持分布式 cache ，但好像需要 jgroup ，配置比較麻煩，我沒有用過，有用過的同學請指教。我本來想使用 session 保存，然后進行 session 同步，后來 IBM 建議使用數據庫 cache ，即自己寫代碼， cache 在數據庫中。這樣不需要 session 同步，對象不大，性能也能得到保證，現在用下來效果還可以。

?

posted @ 2006-12-13 13:39 pesome 閱讀(3803) | 評論 (9) | 編輯 收藏

這次做portal的一些總結（一）

這次做 ibm 的 portal ，算是臨危受命。做了幾個月的 SA 離職，留下一個功能和性能都有很多問題的項目，臨時讓我頂上。經過一個多月的緊張工作（經常加班，上班上不了網，也沒時間上網），總算功能和性能上都能達到客戶要求了。而我也由一個不懂 portal 的人，經過項目中實戰，不說成為高手，一般的概念、開發、配置、優化等也都有了很多體會。

這次技術上值得推薦的就是合理的使用 ajax ，既加快了首頁的 load 速度，又帶來了很好的用戶體驗。開始首頁上所有 portlet 都是串行加載，有的 portlet 比如新郵件，依賴于 mail 系統提供的接口。開始這個接口在較大壓力下就出現性能瓶頸，后在我們的要求下替換了協議，性能也在 1s-2s 之間。如果采用常規的辦法，加上 wps 驗證、運算，顯示主題、皮膚，加載所有 portlet ，響應時間肯定在 10s 以上。

我在 openfans 中使用了 ajax ，有些經驗，所以決定采用異步加載：首頁 load 時一些 portlet 直接顯示正在 loading 的字樣，在 body onload 時再使用 ajax 填充內容；使用 iframe 的 portlet ，也是 src 先指向一個靜態的正在 loading 頁面， body onload 時再替換 src 到實際地址（這是 ajax 模式的一種）。這樣首頁登錄實際上只經過 wps 內部的驗證和顯示，所有業務邏輯都是加載成功后再并行進行。實際表現效果就是：頭上的主題很快出來，一塊塊區域顯示正在 loading 字樣，性能快的 portlet 很快出來，需要幾秒的 portlet 隨后出來，而不是讓用戶傻等 10 多 s 再一下全部顯示。

使用 ajax 同時也能解決頁面刷新問題和獲取返回值的問題。比如前面顯示新郵件的 portlet ，用戶點擊了一封郵件，新郵件數應該減 1 ，剛點擊的郵件也應該上頁面上消失。原始的做法就是刷新整個頁面，既加大服務器壓力，又帶來很差的用戶體驗。使用 ajax ，在點擊后 1s （或者更長，這取決于郵件系統對點擊操作的響應快慢）刷新 div 的內容，用戶甚至感覺不到內容已經更新。其它 portlet 也不需要重新載入，大大減輕服務器的壓力。有的操作需要提交給其它系統，而且可能成功可能失敗，這就需要獲得返回值。如果使用普通的 form 提交，需要更新整個頁面。而使用 ajax 提交，可以方便的獲得其返回值，進而顯示不同的提示。

另一個架構上的特點就是 portal 服務器職責單一 。開始所有的業務邏輯都是寫在 portlet 里，加重了 portlet 服務器的壓力。我進來后做的一個大的規劃就是，把業務邏輯抽離到其它 server 上，然后通過 ajax 加載到 portlet 中。這樣既可以充分利用服務器資源（新的 server 使用單獨的內存空間和線程池），又使得 portal 服務器職責更單一：僅進行驗證、權限控制、主題、皮膚和 portlet 的展示。

先寫這么多。因為使用了 2 臺 server 做集群，在分布式環境下，開發也有了更多的要求（比如 cache ），后一篇文章再細細道來。

posted @ 2006-11-28 14:49 pesome 閱讀(3659) | 評論 (9) | 編輯 收藏

程序之外

難得有空，寫篇程序之外的文章，關于壓力的，也是自己近來的親身體會。

眾所周知軟件這行壓力是很大的。各種各樣的問題層出不窮，每天上班工作內容都是排的滿滿的，遇到突發問題就得加班。如果不及時進行疏解，積累到一定的程度，就可能產生一定的負面問題，比如上班精神狀態差、注意力不能集中、遇事喜歡逃避等等。我就親身經歷了這樣的狀況，明知自己工作積極性差、效率很低，但也很難一下子找回自我。

一次偶然的出游讓我從中很快走了出來。一個親戚考上廈大的博士，我請了 2 天的假，利用周末時間順便去廈門旅游。廈門依山傍海，的確是旅游的好去處。晚上到海邊，涼風習習，光腳沿著沙灘走過，任起落的潮水在腿上腳上留下層層薄沙。內心也變得平靜，能夠感受到海的呼吸。天地間仿佛只剩下我和大海，在進行心靈的交流，俗世煩擾皆拋諸腦后，只剩下對海的依戀。白天去爬南普陀山，并不太高，慢慢爬到山頂，整個思明區盡收眼底，遠處一艘快艇在海面掠過，留下一條美麗的浪花。然后順山而下到植物園，途徑無數奇花異草、層天老樹，走得累了，找個湖邊石凳休息一下，人也覺得輕松愉快。

經過大自然的洗禮，回到單位，人的精神面貌煥然一新，抱著積極的心態處理事情，很多問題迎刃而解。壓力測試做的很累，經常要熬夜，但通過一輪輪的測試，逐步定位到性能問題所在，自己也學了不少相關知識，想想也就沒那么煩了。

做事的方式，也有了長進。我現在信奉人一時只做一件事效率最高的原則。事情再多，也是一件件做，每天安排好近日的工作，并排個優先級，什么是要親自處理的，什么是讓別人處理的，什么是需要預先通知他人的，需要什么資源，每件事情的預計時間如何，需要如何 check 等等。做好一件事就打個勾，做到心中有數。如果事情有延誤，分析是什么原因，該如何補救，而不要有太大的心理負擔，自己盡力了就好，是自己的責任就要勇敢扛下，死不了人的。這其實是很簡單的原則，誰都能夠學會，但的確很管用。

總結：壓力是無處不在的，關鍵在于如何應對和排解。用積極的心態和恰當的方法面對，壓力也就沒那么大了。感覺壓力積累到一定程度，在還未影響正常工作之前就先想辦法排解，出去旅游、運動等都是緩解壓力的好辦法。

posted @ 2006-11-06 22:27 pesome 閱讀(1169) | 評論 (2) | 編輯 收藏

關于代碼的一些比喻

最近對項目組的一些較差的代碼進行了些重構，同時靈光一閃，對代碼有些比較形象的比喻。

壞的代碼就象揉面團，管什么接口什么實現全揉成一團，一個方法幾百行，注釋寫再多也是面團（夾了些小紙條而已）。然后需要重用了，就是從中抓起一把面團，然后放到其它的面團里繼續揉。這樣重復代碼一堆，什么易讀性、擴展性、可維護性都是無從談起。

好的代碼就象堆積木，接口實現定義清清楚楚，每個接口只做一件事情，重復代碼都是通過更細的接口來消除。重用就是把積木塊往該放的地方堆，這樣的代碼，幾個大塊幾個小塊一目了然，只要方法命名規范，連注釋都可以省去。這樣耦合性低，易讀性、擴展性、可維護性都可以得到保證。

把面團變成積木并不復雜，定義好模具，面團一團團往里面填充，待穩定下來，就成了一塊塊積木。這里關鍵就是模具的制作，推薦制作寶典： martin fowler 的那本重構。還得有模具的丈量工具，就非 junit 莫屬了。

posted @ 2006-10-30 17:42 pesome 閱讀(1473) | 評論 (0) | 編輯 收藏

數據庫同步trigger的記錄

??? 項目需要寫了幾個數據庫同步用的 trigger ，就是記錄用戶的操作到一個 temp 表，然后每天通過 webservice 同步到其它系統，同步成功清空該 temp 表。自認為寫的還行，做個記錄。是 db2 的。

?

-- 用戶組新增觸發器

--DROP TRIGGER TG_USERG;

CREATE TRIGGER LIBING.TG_USERG AFTER INSERT ON LIBING.TM_USERG

? REFERENCING NEW AS NROW

? FOR EACH ROW

? MODE DB2SQL??

? BEGIN ATOMIC

?

? declare @groupId integer;

? declare @name varchar(30);

? declare @descn varchar(100);

? declare @syntype varchar(4);

? declare @ddlsql varchar(1024);

? declare @isprimary char(1);

? declare @updateTime timestamp;

? declare @createTime timestamp;

? declare @createBy integer;

? declare @updateBy integer;

? declare @groupType integer;

? declare @adminType integer;

? declare @appId integer;

?

? declare @oldGroupId integer;

?

? set @groupId=NROW.GROUP_ID;

? set @name=NROW.name;

? set @descn=NROW.descn;

? set @syntype=NROW.syn_type;

? set @ddlsql=NROW.ddlsql;

? set @isprimary=NROW.isprimary;

? set @updateTime=NROW.update_time;

? set @createTime=NROW.create_time;

? set @createBy=NROW.create_by;

? set @updateBy=NROW.update_by;

? set @groupType=NROW.group_type;

? set @adminType=NROW.admin_type;

? set @appId=NROW.app_id;

?

? INSERT INTO TM_USERG_TEMP(GROUP_ID,NAME,DESCN,DDLSQL,ISPRIMARY,UPDATE_TIME,CREATE_TIME,

? ?????????? ?CREATE_BY,UPDATE_BY,GROUP_TYPE,ADMIN_TYPE,APP_ID,ACTION) VALUES (@groupId,@name,@descn,

????????????? ?@ddlsql,@isprimary,@updateTime,@createTime,@createBy,@updateBy,@groupType,@adminType,@appId,'INSERT');

? END;

?

? -- 更新用戶組數據的觸發器

?-- DROP TRIGGER TG_USERG_UPDATE;

? CREATE TRIGGER TG_USERG_UPDATE AFTER UPDATE ON TM_USERG

? ?????????? ?REFERENCING NEW AS NROW

????????????? ?FOR EACH ROW

????????????? ?MODE DB2SQL

????????????? ?BEGIN ATOMIC

????????????? ?

????????????? ?declare @groupId integer;

? ?????????? ?declare @name varchar(30);

? ?????????? ?declare @descn varchar(100);

? ?????????? ?declare @syntype varchar(4);

? ?????????? ?declare @ddlsql varchar(1024);

? ?????????? ?declare @isprimary char(1);

? ?????????? ?declare @updateTime timestamp;

? ?????????? ?declare @createTime timestamp;

? ?????????? ?declare @createBy integer;

? ?????????? ?declare @updateBy integer;

? ?????????? ?declare @groupType integer;

? ?????????? ?declare @adminType integer;

? ?????????? ?declare @appId integer;

????????????? ?

????????????? ?set @groupId=NROW.GROUP_ID;

? ?????????? ?set @name=NROW.name;

? ?????????? ?set @descn=NROW.descn;

? ?????????? ?set @syntype=NROW.syn_type;

? ?????????? ?set @ddlsql=NROW.ddlsql;

? ?????????? ?set @isprimary=NROW.isprimary;

? ?????????? ?set @updateTime=NROW.update_time;

? ?????????? ?set @createTime=NROW.create_time;

? ?????????? ?set @createBy=NROW.create_by;

? ?????????? ?set @updateBy=NROW.update_by;

? ?????????? ?set @groupType=NROW.group_type;

? ?????????? ?set @adminType=NROW.admin_type;

? ?????????? ?set @appId=NROW.app_id;

????????????? ?

????????????? ?-- 如果已經有 update 則只記錄最后一條 update

????????????? ?IF EXISTS(SELECT GROUP_ID FROM TM_USERG_TEMP WHERE GROUP_ID=@groupId AND ACTION='UPDATE') THEN

????????????? ? ???? UPDATE TM_USERG_TEMP SET GROUP_ID=@groupId,

????????????? ? ???? ? ??????????? NAME=@name,DESCN=@descn,DDLSQL=@ddlsql,

?????????????????????????????????? ISPRIMARY=@isprimary,UPDATE_TIME=@updateTime,

?????????????????????????????????? CREATE_TIME=@createTime,CREATE_BY=@createBy,

?????????????????????????????????? UPDATE_BY=@updateBy,GROUP_TYPE=@groupType,

?????????????????????????????????? ADMIN_TYPE=@adminType,APP_ID=@appId,ACTION='UPDATE'

?????????????????????????????????? where GROUP_ID=@groupId AND ACTION='UPDATE';

????????????? ?-- 如果有 insert 則把后面的 update 當作 insert

????????????? ELSEIF? EXISTS(SELECT GROUP_ID FROM TM_USERG_TEMP WHERE GROUP_ID=@groupId AND ACTION='INSERT') THEN

???????????????????? UPDATE TM_USERG_TEMP SET GROUP_ID=@groupId,

????????????? ? ???? ? ??????????? NAME=@name,DESCN=@descn,DDLSQL=@ddlsql,

?????????????????????????????????? ISPRIMARY=@isprimary,UPDATE_TIME=@updateTime,

?????????????????????????????????? CREATE_TIME=@createTime,CREATE_BY=@createBy,

?????????????????????????????????? UPDATE_BY=@updateBy,GROUP_TYPE=@groupType,

?????????????????????????????????? ADMIN_TYPE=@adminType,APP_ID=@appId,ACTION='INSERT'

?????????????????????????????????? where GROUP_ID=@groupId AND ACTION='INSERT';

????????????? ELSE????? INSERT INTO TM_USERG_TEMP(GROUP_ID,NAME,DESCN,DDLSQL,ISPRIMARY,UPDATE_TIME,CREATE_TIME,

? ?????????? ? ??????????? ???CREATE_BY,UPDATE_BY,GROUP_TYPE,ADMIN_TYPE,APP_ID,ACTION) VALUES (@groupId,@name,@descn,

????????????? ? ??????????? ?? @ddlsql,@isprimary,@updateTime,@createTime,@createBy,@updateBy,@groupType,@adminType,@appId,'UPDATE');

????????????? end if;

????????????? ?END;??????????

?

?

-- 刪除用戶組觸發器

--DROP TRIGGER TG_USERG_DELETE;

CREATE TRIGGER TG_USERG_DELETE AFTER DELETE ON TM_USERG

?????? ? REFERENCING OLD AS OROW

?????? ? FOR EACH ROW

?????? ? MODE DB2SQL

?????? ? BEGIN ATOMIC

?????? ?

?????? ? declare @groupId integer;

? ??? ??declare @name varchar(30);

? ??? ??declare @descn varchar(100);

? ??? ??declare @syntype varchar(4);

? ??? ??declare @ddlsql varchar(1024);

? ??? ??declare @isprimary char(1);

? ??? ??declare @updateTime timestamp;

? ??? ??declare @createTime timestamp;

? ??? ??declare @createBy integer;

? ??? ??declare @updateBy integer;

? ??? ??declare @groupType integer;

? ??? ??declare @adminType integer;

? ??? ??declare @appId integer;

????????????? ?

?????? ? set @groupId=OROW.GROUP_ID;

? ??? ??set @name=OROW.name;

? ??? ??set @descn=OROW.descn;

? ??? ??set @syntype=OROW.syn_type;

? ??? ??set @ddlsql=OROW.ddlsql;

? ??? ??set @isprimary=OROW.isprimary;

? ??? ??set @updateTime=OROW.update_time;

? ??? ??set @createTime=OROW.create_time;

? ??? ??set @createBy=OROW.create_by;

? ??? ??set @updateBy=OROW.update_by;

? ??? ??set @groupType=OROW.group_type;

? ??? ??set @adminType=OROW.admin_type;

? ??? ??set @appId=OROW.app_id;

?????? ?

?????? ?? -- 如果沒有操作記錄，則插入 delete 記錄

?????? ?? IF NOT EXISTS(SELECT GROUP_ID FROM TM_USERG_TEMP WHERE GROUP_ID=@groupId) THEN

?????? ?? ? ??INSERT INTO TM_USERG_TEMP(GROUP_ID,NAME,DESCN,DDLSQL,ISPRIMARY,UPDATE_TIME,CREATE_TIME,

? ?????????? ?CREATE_BY,UPDATE_BY,GROUP_TYPE,ADMIN_TYPE,APP_ID,ACTION) VALUES (@groupId,@name,@descn,

????????????? ?@ddlsql,@isprimary,@updateTime,@createTime,@createBy,@updateBy,@groupType,@adminType,@appId,'DELETE');

????????????? ?

????????????? ?-- 如果有 insert 記錄，則整體結果相當于沒有進行任何操作

????????????? ?ELSEIF EXISTS(SELECT GROUP_ID FROM TM_USERG_TEMP WHERE GROUP_ID=@groupId and ACTION='INSERT') THEN

????????????? ? ??????????? DELETE FROM TM_USERG_TEMP WHERE GROUP_ID=@groupId and ACTION='INSERT';

????????????? ?-- 如果沒有 insert 記錄，則只需記錄最后的 delete 操作

????????????? ?ELSE

????????????? ? ???? ? UPDATE TM_USERG_TEMP set ACTION='DELETE' where GROUP_ID=@groupId;

?????? ?? END IF;

?????? ??

?????? ?? END;

posted @ 2006-10-30 17:06 pesome 閱讀(1412) | 評論 (0) | 編輯 收藏

關于重用

在項目中碰到一些重用上的問題，有些想法，就先寫一點。

重用應該是高層的復用，邏輯的復用，接口的復用，而不是具體實現的復用。 我們項目開始講復用，就是大家把別人的代碼拿過來，可用的地方就用，不同的地方改改，結果問題一堆。說到底就是接口沒有定義清楚的，很多該復用的邏輯隱藏在了具體的實現中。這樣導致無法進行接口的復用，轉而使用具體的實現復用。從程序員的角度看，他們總會使用成本最小的方法完成任務。所以我們要時刻思考如何能讓最正確的方法在他們看來同時也是成本最小。

這里有一個較為簡單的辦法，就是盡量使用方法封裝實現，使接口的粒度最小。如果一個實現需要幾百行，且其中包含多個邏輯，就最好抽取出多個方法，然后在主體接口內進行調用。這樣的代碼邏輯清晰易讀，可重用性也高。看看大師們對代碼的不斷重構，很大程度上就是重構出粒度最細，復用性最高的接口。

如何達到最大程度的復用，其實是非常復雜的問題，還需要在今后的項目中不斷體會。

posted @ 2006-10-15 23:13 pesome 閱讀(481) | 評論 (0) | 編輯 收藏

最近做壓力測試的總結

最近做 portal 的壓力測試，一個字“累”。其中犯了不少錯誤，白白加了幾天班，也有一些體會，就記錄下來，希望對大家有所幫助。

首先講壓力測試環境。這個很是關鍵，我們就是在這個上面吃了苦頭。我們用的 loadrunner ，原理也很簡單，一臺主控機，控制多臺客戶機，模擬并發用戶訪問應用。然后需要能實時監控各相關應用服務器， ldap 服務器等的性能。這里每臺客戶機最好能使用同樣的配置，使用足夠帶寬的網絡，給予同樣的負載（模擬同樣數量的用戶）。同時要注意監控客戶機的 cpu 和網絡狀況，時刻保證 cpu 和網絡利用率低于 100% 。我們犯的很大錯誤就是使用各自的筆記本，而且都使用的是一個 10M hub 牽出的網線，這樣導致實際的網絡阻塞，既沒有給予服務器足夠的負載，又導致報告的響應時間比實際更長，從而帶來了后續很多的無用測試。

然后講測試方法。用的較多的還是持續壓力測試，就是持續給予服務器一段時間的并發量（一般為 5 到 10 分鐘），然后看平均響應時間是否在可以接受的范圍內。這個“可接受”要視應用類型和實際的并發用戶而定，如何估計并發就要靠經驗了。對于 portal 而言，由于要與眾多的應用接口，如進行 SSO ，獲取數據等，有很大程度也依賴于其它應用的性能，其性能要求不會太高。我們測試首頁的性能，在放上全部的 portlet 的情況下， 100 個并發的平均響應時間就在 17s 左右，這肯定是不能接受的（ 10s 只能算勉強可以）。接下來就是發現性能瓶頸，并嘗試進行優化了。

初步的發現瓶頸的方法也很簡單，通過對 portlet 的增減，發現最影響性能的 portlet ，然后不斷優化，直至達到可以接受范圍。發現瓶頸所在了，就得進一步確定是什么原因：是我們本身程序的問題，還是其它應用接口性能不佳等等。這里光靠猜是不行的，要講數據講事實，記錄時間日志就是簡單有效的辦法，我們對各個時間點打印了日志，比如 doview 方法的全部執行時間， jsp 的載入時間，具體接口的執行時間等。有些接口可能在壓力較小的情況下性能不錯，而在大壓力情況下出現性能隱患，所以一定要在進行壓力測試后查看日志。我們就是這樣發現了性能隱患，同時更進一步對各方面進行優化，直至達到客戶可以接受為止。

由于不是專門的測試人員，很多地方都是實際項目中的體會，也沒什么理論基礎。有什么不對的地方，大家多交流。

posted @ 2006-10-15 23:13 pesome 閱讀(2517) | 評論 (1) | 編輯 收藏

項目應該提倡的一些做法

接著昨天的寫。今天寫我認為的一個 javaEE 項目中應該提倡的做法。

1.?????? 開發流程盡量簡化，采用迭代增量的模式，做適合項目需要的文檔。很多時候千言不如一圖，原型開發我認為也非常重要。

2.?????? 采用成熟的框架， ssh 組合或更多 full-stack 的框架如 seam 等都是不錯的選擇。如果一定要用公司的框架，至少 SA 要非常熟悉這個框架，在出現問題時要能快速的解決。

3.?????? 對業務的分析做到越細越好，如果有條件讓更多的開發人員參與業務的分析，同時形成項目通用的業務語言（實在不行，精簡的 user story 也可以）。對于每個達成共識的業務都要能記錄下來，并能方便的進行查閱。業務模型和業務規則要始終與當前需求、代碼和數據庫保持一致。

4.?????? 在團隊的建設上，需要更多的投入。不要為了節約成本，讓很多程序員老后面才加入團隊。一個穩定、團結、有沖勁的團隊能比松散而人數更多的團隊，完成的更快更好。然后要加強溝通，比如每天開個小的茶話會，大家交流下各自的工作情況，有什么困惑和疑難，提出來大家一起解決，避免大家各自做相同的邏輯（很多東西經過抽象可能就是一個）。在工作之余大家一塊吃吃飯，打打游戲等都是增進感情的好方法，大家彼此熟悉了，工作上也能更好的協作。

5.?????? 對程序員要有更高的要求， SA 有責任讓程序員了解更多的東西，如面向對象的 5 大原則、一些模式、 junit 、重構等，這些其實并不是什么高深的東西，僅僅是掌握一些方面也能對代碼質量和開發中的愉悅度產生很大促進。要激發他們對技術的熱愛和對代碼質量的追求，因為最終受益的還是他們。 XP 所提倡的結對編程也是快速進行知識傳遞的好辦法。

6.?????? 采用 wiki 進行項目進度跟蹤和一些文檔的展示。這次用 excel+cvs 的方式感覺很是麻煩，在 spring 翻譯中我們采用 wiki 的方式就感覺很好。

暫時先想到這么多，有更多體會，再來補充！

posted @ 2006-09-21 15:59 pesome 閱讀(1025) | 評論 (2) | 編輯 收藏

用Maven做項目管理

     摘要: 在程序員發表的一篇maven文章，跟大家共享。用 Maven 做項目管理 在 Java世界中我們很多的開發人員選擇用 Ant來構建項目，一個 build.xml能夠完成編譯、測試、打包、部署等很多任務，但我們...  閱讀全文

posted @ 2006-09-21 11:37 pesome 閱讀(18689) | 評論 (10) | 編輯 收藏

從錯誤中學到更多

開發進行到尾聲了，但 bug 仍然層出不窮。總的來說，算是一個比較失敗的項目，原因很多，有外在因素也有我作為一個 SA 不可推卸的責任。正好借加班的時間寫點總結，也算是在失敗總吸取教訓，從錯誤中感受更多吧。

首先是開發流程。我是 xp 的堅定支持者，但在項目中由于外界原因還是采用了傳統的開發流程，沒有迭代，就是需求 -> 設計 -> 程序員進場開發 -> 改 bug 。由于程序員進場時間較晚，一上來就開始開發，沒有時間進行培訓和團隊的融合。然后開發中缺少溝通，就是一個人負責一塊，開發完了再做其它。結果開發到現在，還有人不清楚我們項目的全貌，到底是為了解決什么業務。

然后是開發框架。使用了公司的框架，而我們作為 SA （我們是雙 SA ），都是第一次接觸，程序員也就一個人用過。我們最早是達成共識采用 SSH 的組合（我至少還算是了解吧，其它人也都用過），但由于上層因素沒有實施（這也導致我好長一段時間進入不了狀態）。開發前期大家都在探索這個框架（的確很難用，出錯機制較差，配置文件很多，耦合較強 ... ），在一堆莫名奇妙的問題中摸索前行，花費大量的精力。而比較搞笑的是，在大家開始學習這個框架之時，我作為 SA ，因為要寫一堆只為應付客戶的設計文檔（后面就沒人看過），錯過了和大家共同進步的機會，后面總是感覺“低人一等”。

在業務方面也存在很多問題。很多業務邏輯并沒有以很好的載體保存下來，在需求文檔中很多邏輯并沒有體現。我維護了一套 pd 的業務模型，從概念模型 -> 物理模型 -> 數據庫，這解決了后面的一些溝通問題，但由于更多體現的是靜態的實體及關聯，對于一些動態的業務流程沒法體現。我們 SA 之間有時在一些問題上的理解還存在分歧（討論過也達成過共識，但沒有記錄下來，后面可能就忘了），程序員就更是無所適從。談到這，我更感受到 DDD 這本書的價值，他所提倡的開發人員參加模型的討論，形成項目的模型語言，并不斷隨著業務進行演化。。。好多理念都是項目經驗的結晶啊。

在開發管理上我也是無所作為。 Junit 都沒有推廣下去，更別說 TDD 了，這也與框架相關，它就沒提供寫 test case 的地方，等我搞明白一堆配置文件，做出脫離 web 容器的 test 框架，都開發一大半了，說起 test 的好處，大家也表示不理解（或者表示理解但沒時間 = 沒理解），就讓他們慢慢 debug 吧！代碼的質量也沒有保證，程序員不明白代碼的味道，更別說理解重構的意義以及進行恰當的重構了。一個函數寫上 100 多行，什么邏輯都混在一塊，但由于時間較緊，我也只好睜一只眼閉一只眼“功能完成就行吧！也不是我一個人在管”，到現在很多代碼混成一團，展現層直接調用 dao （又是框架惹得禍），相同的邏輯 copy 到 n 處，我也是后悔莫及。

今天先寫失誤，明天寫從中學到的東西，從錯誤中學到的也許更多！

posted @ 2006-09-20 21:24 pesome 閱讀(890) | 評論 (1) | 編輯 收藏

對領域模型的認識

最近看了看領域模型驅動這本書，只看了前面幾章，但也深切的感受到了模型的重要性。通過與代碼同步的模型，能夠維護一個很好的知識共享的空間，包括設計者與程序員之間，客戶與設計者之間 …… 而且模型應該盡可能簡單，讓不同背景的人都能夠很快學會，并都能對模型有所增益。

那么這個模型應該是什么樣的？書我沒有細看，只說說自己的體會。關于設計，很早就有數據驅動和對象驅動的提法。在 Without EJB 里， Rod 也有講：數據驅動或者說面向數據庫設計更成熟，工具更多；而對象驅動更符合面向對象程序的特性，但由于掌握的人較少，風險較大。而通過模型驅動，我認為很大程度填補了 2 種方式的鴻溝，核心是模型，具體是對象模型還是數據模型并不重要，重要的是這個模型能夠與需求、代碼、數據庫保持一致。

說到這里，順便談一談我對文檔的理解。我一直是 XP 的堅定支持者，甚至有點偏執。而由于文檔不易閱讀和溝通，且經常會出現與設計和代碼的脫節，導致其可讀性更差，所以我一向對文檔不大感冒，更傾向于使用代碼說話。但在目前的公司項目中，由于更多采用傳統的軟件過程，我也寫了很多的文檔，包括需求規格說明書、概要設計文檔、詳細設計文檔等等。從對項目的幫助來看，文檔作用并不太大，或者說是付出收益比太低，更多的是給客戶寫的，而不是給程序員寫的。從程序員的需要來看，他關心的是每個實體的屬性和關聯，核心的接口、輸入和輸出，頁面間的跳轉和數據流，然后有一個統一的框架和編程模式。我的體會是：如果以文檔為核心，很難描述清楚這些東西，且難以應對變化。

而通過以模型為核心（項目現在采用的 power designer 的概念模型為基礎），輔以適當的描述，既能夠加快大家對項目的認識（程序員是后面才加入），又能夠節省一些寫文檔的時間，更早投入開發。

說到 power designer ，我也比較慚愧。用了好久，一直只是把它當成看數據庫的工具。項目一開始就是從物理模型入手，結果舉步維艱。后面從概念模型入手，就感受到了它的好處。使用概念模型，不用考慮太多關聯表、外鍵什么的，而是從實體出發，然后確定相互間的關聯，是一對一、一對多還是多對多。然后自動轉成物理模型，并直接與相應的數據庫掛鉤。從這點上看與從對象設計出發真的非常相似。其實這也是合情合理的，正體現了這個世界的統一性吧（物理學界不也在搞什么統一場理論的證明嗎）。 Power designer 也做了 conceptual model, physical model, object-oriented model 和 xml model 的自動轉換，我現在還沒全部摸熟。

openfans 則是從對象入手，并通過 hibernate 建立與數據庫的聯系，也體現了一定的方便靈活性。但比較糟糕的是，只有代碼和配置文件，沒有清晰的便于交流的模型，誰要想參與只能先去慢慢看代碼。所以我先通過 together reverse 出來一個類圖，然后適當加以文字進行說明。類圖已經做好，但比較亂，還需要更多的圖例加以說明。文字說明就是下一篇 blog 的工作了。也算是預告吧！

posted @ 2006-08-13 17:41 pesome 閱讀(3643) | 評論 (3) | 編輯 收藏