lbom

昨日年終總結會，公司總裁給出IT產業未來發展的幾個新趨勢，值得我們這些從事軟件工作的人員沉思，現對他的發言摘錄如下：
1）管理虛擬化：有形的組織型管理和虛擬的IT流程管理相結合管理模式；
2）制造虛擬化：由生產線工人和由程序控制的機器人相結合的生產模式；
3）渠道虛擬化：由實體銷售店和虛擬的網上銷售相結合的渠道管理模式；
4）服務虛擬化：實體保養維修和遠程診斷，軟件更新相結合的服務模式；
5）組織虛擬化：垂直的組織機構和橫向的項目型組織機構相結合的企業組織模式。

今天，花費1個小時，研究了一下在Windows下，使用Telent登錄至UNIX的腳本，現將其貼下，以供下次使用（tt.bat）

 

 

@echo off
echo set sh=WScript.CreateObject("WScript.Shell") >telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------UNIX IPAddress
echo sh.SendKeys "open 10.0.18.100{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------userID
echo sh.SendKeys "root{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------password
echo sh.SendKeys "root{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs

echo sh.SendKeys "ls {ENTER}">>telnet_tmp.vbs

start telnet

cscript //nologo telnet_tmp.vbs

rem del telnet_tmp.vbs

 

1)啟動LiveWriter客戶端

2)添加Blog帳戶:

3)設置日志類型：

4)連接測試

很久沒有動手寫WebService了，這次，借項目間隙，對系統進行一個小改造，將一部分功能使用WS進行封裝，為下一步異構系統集成打下基礎。

但在WS化時，由于日久生疏，一個小小的WS化變動，卻花了整整好幾天時間！為此，狠下以來，將其過程進行記錄，以便下次參考。

 

WS整體流程：

以下分別介紹：

1、設計和實現WebService服務端功能組件，用于統一處理針對本應用系統所需進行WebService化的邏輯實現。并將系統邏輯處理中的對象轉成序列化后的String對象，以符合WebService交互標準。

2、根據SBPApi.java，生成WSDL等：通過Eclipse右鍵菜單中的WebService-->Create Web Service項。完成后，會在web目錄下建立wsdl目錄和SBPApi.wsdl，在WEB-INF目錄下建立（改寫）server-config.wsdd等文件,并完成對web.xml的修改。其操作流程示如下：

3、根據SBPApi.wsdl，生成WebService客戶端開發包和部署文件：

1)為不影響已有項目，可另建java Web項目；

2）將wsdl目錄復制至新項目對應的web目錄下；

3）通過eclipse已提供的webService插件（右鍵）功能，生成客戶端開發包所各文件。此時，所生成的文件與服務端對象文件結構一至。

4）調整關聯引用文件，將其調整至客戶端開發包，從而避免與服務器端的引用路徑重復而引發不便，并將服務器SDK中已有文件刪除。

5）建立客戶端的快速使用代理SBPClient.java，對WebService服務端交互工作的SBPApiSoapBindingStub.java進行客戶端封裝，并根據服務端中交互對象進行反向工程，其示例結構如下：

6）將clientApi下的所有文件打包后，加入測試項目進行測試。此時，因客戶端所使用的服務端對象未包含在WebService客戶端開發包中，因此需要將服務端對象也一同打包。

7）測試。

4、開發環境：Eclipse3.3.1.1 + JDK1.5.06 + Apache Axis version: 1.4

在一次基于多線程的編碼測試中，發現繼承Runnable接口的線程實現類在運行時并未按預計啟動多線程，經分析和比較后，找出問題所現，現將其記錄下來，以供分享。

Java中，多線程編程中的線程編寫，有兩種方式，即擴展Thread基類或繼承Runnable接口；例如：

public class T extends Thread {

public void run() {

……

}

}

public class R implements Runnable {

public void run() {

……

}

}

對于擴展Thread的實現類T，可以使用T.start()來啟動此線程；如

public static void main(String[] args) {

Thread t = new T();

t.start();

}

但對于繼承Runnable接口的實現類R，因接口中并沒有提供直接啟動線程的start()方法，只有一個線程主邏輯運行的run()方法。此時，如執行run()，會因為R.run()只是作為此線程實現類的一個方法，并未在主線程之外，啟動另一個線程，從而導致R.run()阻斷主線程繼續向下執行；并未達到多線程運行的目的。

錯誤啟動代碼如下：

public static void main(String[] args) {

R r = new R();

r.run();

}

那么，如何使用另外線程來啟動繼承Runnable接口的實現類呢？以下就是它的正確的使用方式：

public static void main(String[] args) {

R r = new R();

Thread t = new Thread(r);

t.start();

}

此時，需注意，在主線程執行時，需等待子線程執行，否則，當主線程結束后，子線程也將結束。

需求：

系統A與系統B分別部署在不同域的兩臺服務器中，但它們的身份都統一在身份認證服務器中；身份認證信息以Session方式存貯于各自系統中，并輔以cookie進行使用。

當用戶在A系統登錄后，訪問B系統時，由于是跨域訪問，導致身份信息不能正確的傳遞到B系統中，從而致使用戶需在B系統中重新登錄。

解決方案：

處理這類跨域訪問時，我們最先使用從B系統向C通過HttpRequest(類AJAX請求)的方式獲取身份信息，此方式好處是同步處理，方便用使用；但其限制諸多，如需設置信任站點、用戶訪問確認等，甚至，在對應用服務器作了一次安全升級后，根本無法訪問了。因此，需另行開辟途徑，于是，在同事建議下，我們使用IFrame內嵌跨域驗證網頁，來解決此問題。

1、原理設計：用戶在訪問B系統時，先使用一內置的iframe，并將iframe的src指向身份認證服務器系統代理驗證接口；如果用戶已經在A系統中進行過登錄，即A域了中已存在著身份認證信息后，身份認證服務器中也將具有其身份信息將其附帶著身份認證信息后重定向訪問B系統代理接口；B系統代理驗證接口在接收到由A系統傳遞而來的身份認證信息后，通過身份認證服務器驗證后，在B系統所在域重建身份認證信息。

2、實現邏輯貼碼：

1）B系統代理驗證接口：

（1）IFrame邏輯貼碼：

（2）JS檢測是否通過認證邏輯貼碼：

2）身份認證服務器端接口（JSP）：

3、注意事項：

1）由于身份認證中心使用cookie作為身份標識，因此，需要用戶在瀏覽器中允許使用cookie的設置；

2）由于在iframe中進行跨域重定向，因此需在IE安全中的跨域瀏覽子框架項設為啟用：

4、源碼文件：

……

在windows下進行j2ee項目開發和部署時，常需要對系統存在問題進行更深入的分析。由此，實時的javacore就是分析的最佳方式之一。但如何以最方便直接的方式產生javacore文件，就是這項工作必需做的準備工作了。

1、通過dos窗口，進入至jdk安裝目錄下的bin目錄中；

2、運行jconsole.exe，并設置信息輸出的目標文件，以便于分析，否則將直接輸出至屏幕上；

3、連接正在運行的目標jvm；

4、連接后的jconsole如下：

5、通過通過Ctrl+Break組合鍵，產生javacore至指定文件中。

6、下一步就是對所產生的javacore文件進行具體的分析和使用了。

某日，公司進行年度一次的體檢！

在連續查出10個脂肪肝后，醫生對第11個進來檢查的人說：“等會，我們的B超機好像出問題了，等檢修后再進行”

這是一個真實的事件，我們這些IT行業的從業人員，多坐少動，壓力大，時間長，導致體質差的邊醫生都懷疑機器了！

唉！

一、項目建立及應用實現

1、建立J2ME項目

2、在完成開發后，進入Application Descriptor編輯界面

3、因默認情況下，Application Descriptor文件中未定義MIDlet啟動對象，因此需使用EditPlus或記事本等文本編輯器，編輯Application Descriptor文件（位于項目根目錄下），并添加以下項目，如：

4、運行Application Descriptor編輯界面中的Lanuch as enumlated Java ME JAD，進行測試

5、在步驟4之后，會在項目根目錄下的.mtj.tmp中生成LaunchFromJAD子目錄，其中的worm.jad和worm.jar即是手機程序的安裝文件

6、將worm.jad和worm.jar復制至手機中，運行worm.jad進行安裝后，即可使用

二、問題分析：

1、如報【文件不完整】錯誤，則檢查worm.jad中的項目是否完整。在Eclipse中使用Lanuch as enumlated Java ME JAD測試通過，并自動生成的此文件，一般都是完整的，不需作任何修改。

2、如報【版本錯誤】，則檢查您在Eclipse中使用的的模擬器版本是否是您手機所支持的，出現此錯誤后，將模擬器版本調低試試。其位置如下

三、開發環境：

1、java JDK1.6.0_10；

2、EclipseV3.3.1.1；

3、sun公司J2ME-WTK開發包：sun_java_wireless_toolkit-2_5_2-ml-windows.exe

4、Eclipse移動應用開發包：eclipseme.feature_1.7.9_site.zip

 

 

消息中心產品簡介

產品簡介

在XXX產品框架中，我們根據產品發展規劃和業務領域需要，使用基于JMS技術，通過應用WEBService，開發了消息中心中間件（簡稱MC）。通過消息中間件，我們可以實現各系統間的異步數據交換和事務處理、執行不需前臺使用人員干預的如后臺業務和數據同步工作，也可用來處理一些受到安全和其它一些因素制約，導致無法直接通過數據庫或應用系統進行處理的受限業務。

消息中心中間件，包括消息總線和消息客戶端兩部分：消息客戶端負責業務類消息實例的產生、發送消息實例到消息總線、接收從消息總線轉發而來的消息實例、將收到的消息實例交由其載體應用系統進行與之對應的業務處理等活動；消息總線負責接收從消息客戶端產生并發送而來的消息實例、消息重建、根據消息配置進行消息實例重建,將重建后的消息實例轉發至對應的消息客戶端等活動。

消息客戶端與XXX各應用系統集成在一起，并通過應用系統開放WEBService端口進行消息的發送和接收等，從而避免單獨部署和發布所帶來的困難和額外資源消耗。消息總線可單獨部署，也可和消息客戶端一樣，與XXX應用系統集成部署，在XXX產品框架下，有且只需要一套消息總線即可滿足需要。消息配置中心，其作用包括配置和管理消息中心各組成部分的部署方式和訪問信息，以此將消息中心各部有機的聯系起來；同時，各消息業務應用，也使用配置文件進行配置化管理，并與消息中心各組成部分進行關聯配置，從而形成一個統一且開放的整體；其它的如性能優化處理、日志記錄等也在配置中心進行配置和管理。

應用現狀

在消息中間件V1.0版本開發完成后，我們即將其投入實用。在XXX各分子系統這近一年時間的運行和使用過程中，消息中心很好的完成了預定任務，其可靠性、可擴展性和適用性得到很好的驗證。以此為據，通過使用消息中心，開發出基于消息中心的客戶化應用和業務活動也在持續的增加中，到現在為止，已經有包括網絡檢測、信息同步、配置更新、電子目錄樹更新、權限同步等諸多應用是基于消息中心應用開發，并很好的使用在XXX各分子系統的測試和內網正式環境中。

問題出現、描述、分析與處理記錄

問題出現

在XXX系統正式接入外網后，通過對業務進行跟蹤，發現外網用戶（系統）所產生的消息實例無法正常的到達指定的消息總線及消息客戶端。最主要的體現是權限同步消息應用無法正常完成的問題，導致外網用戶權限未得到及時更新。對此過程中消息中心所涉及部分進行分析發現：所有的權限同步消息實例在產生后，不能正常的將此消息實例發送至消息總線，分析失敗原因，只有一種，那就是”connect time out”。從此信息可看出，應該是外網系統所發出的消息無法通過WEBService送達指定的消息總線接收端所至。但從內網發出的同一類消息，其發送和接收卻又都是正常的。

分析過程記錄

1、先分析我們系統的整體部署方式，如下圖所示：

根據外網用戶可正常登錄和訪問系統，并可通過系統準確及時的發出執行指令操作，完成其所需的業務活動來看，網絡方面和系統和硬件方面都不存在問題。

2、在外網環境下，直接進行各消息客戶端和消息總線的服務的檢測，所發請求都能夠正確的到達指定目標，WEBService的響應也正常且正確，也就是說，各應用系統加載的消息服務運行也正常。

3、根據本次檢測需要，另行開發消息中心專用檢測工具，為本次和今后的行的消息中心檢測和問題分析，作好更充分的準備。

4、通過檢測工具，發現，外網環境下，消息客戶端和消息總線之間不能夠聯通，從而找到問題所出：即不知是何原因，導致外網消息與外網的消息總線間聯絡不通！

5、對外網用戶消息產生和發送的過程和邏輯實現進行分析：我們發現，為了滿足應用系統外網訪問的需要，我們對消息系統配置信息中服務地址的ServerName進行了偽處理，即在運行時，根據用戶瀏覽器的請求頭來判斷用戶使用的是哪一個WEB服務器地址，并將此地址動態的代替消息配置中的各ServerName信息，從而保證各使用用戶只能夠訪問其指定的WEB服務器，從而避免因WEB服務器的不匹配而影響其訪問速度、處理效率等故障的發生。此方式已在我部門多套同時服務于內外網絡的系統中得到可靠的驗證。

那么，會不會因為ServerName在動態解釋過程中，因多并發情況下，因后訪問者將前訪問者的ServerName改寫而導致錯誤的解釋，即將不同網絡用戶的消息地址進行張冠李戴而導致消息無法正常發送呢？

分析消息中心各部分WEBService生成和使用機制：因系統的并發性要求較高，在高峰期其在線用戶可達3000人，并發用戶在300以上，且系統穩定性要求極高。為提高系統的性能和穩定性，在系統啟動時即將消息中心各部的WEBService連接進行創建和緩存，以提升消息中心資源利用率，并提升其訪問性能。

當存在多網絡用戶訪問時，可能因消息中心存貯的WEBService連接并不是其用戶所使用的那個網絡的WEBService服務地址，此時，消息肯定是無法送達至此用戶所需要的目標的。因此，報”connect time out”錯誤就成必然的了。

既然已找到問題的可能原因，我們立即進行著手分析和解決：根據部署要求，我們對對消息服務連接服務進行了升級，即將服務請求進行分類處理和實現，并在消息配置中對所使用的部署方式、代理實現后，交由測試人員進行部署和測試。

測試結果：令人失望的是，此問題依然存在！在通過外網WEB服務器訪問的系統，其消息還是無法發送至消息總線。由此得知，此種分析方向是錯誤的！

至此，好像已經走入了死區,能想到的方式都已經想到了，但問題到底出在哪呢？

問題解決

在一次與同事聊天的過程中，忽然想到一個問題，那就是：我們的消息的產生和應用都是由應用系統和與之集成在一起的消息客戶端自動產生和處理的，此過程中完全不受人工干預和影響。而應用系統是部署在應用服務器中，WEB服務器僅是用來處理用戶的HTTP請求à將此請求轉發至對應的應用服務器后à將應用服務器的響應返回給用戶。

在此過程中WEB服務器并未對用戶業的http請求進行過任何業務上的處理！那么，問題會不會出在WEB服務器端呢？檢查一下消息中心的配置不管是使用ServerName還是寫死IP和域名，我們的消息中心配置的地址都是指向WEB服務器。而在應用系統發現消息時，其所在位置是應用服務器。而應用服務器是無法直接訪問部署于外網IP中的WEB服務器的，當然，消息無法發送至目標就成為必然了。

既然已經找到問題，那就動手，將消息中心的配置信息指向應用服務器后，重啟應用系統后測試，問題果然解決！

通過應用服務器進行后臺自動處理的，進行HTTP或WEBService活動，其目標必需是它能夠訪問的有效地址！這個問題在以前也曾經碰到過，只是由于時間隔得太久，且這些場景應用出現太少，而導致再次發生。

補充與心得

1、    基于應用系統或后臺自動觸發的一些業務邏輯，如其中存在著系統間相互訪問或遠程調用等，必需以應用系統自身為根，進行連接測試；通過外層包裝或其它代理，進行訪問時，必需先剝離過外層包裝或其它代理后，再進行連接測試，并以測試結果，作為決策的依據！此舉適用于各類系統的架構設計和邏輯實現過程中。

2、    基于中間件產品應用，及時開發與之配套的檢測和使用工具，是一件必不可少的工作，此舉將為后期的實施和問題分析節省大量的工作量。

    幾天前，偶爾和鄰居聊天，她說要去買頂蚊帳過夏，不由的也動了心。是啊，在小時候，那家不是用蚊帳來保證漫長夏的良好睡眠呢！現在隨著科技發達，家家戶戶，特別是城市住戶都已經將蚊帳扔掉而改用蚊香或蚊片了。
    于是等夫人下班回家，和其商量，卻是死活不同意，理由如下：1）影響臥室美觀；2）擠占空間；3）拆洗不便。。。。。。
    沒辦法，為了達到目的，我只得絞盡腦汁，想出各種理由，以期望能夠說服夫人：
    1）身體牌：我對蚊香有過敏，因此，在夏天，我們是不能點蚊香的；再說，各種滅蚊產品其主要成份都有毒性，不管其含量多少，都對身體無益。
    2）經濟牌：在重慶，一年有6個月的夏天，以每晚一片滅蚊片計算，一年下來，加上電熱滅蚊器最少需要投入120元以上才能保證夏季無憂，三四年下來，就可以買個較好的蚊帳了；再說，滅蚊片用久后，還得防止蚊子產生的抗藥性；但使用蚊帳卻不需要用電，一年下來，其電費也能節約不少，還可防止可能因電熱滅蚊器散熱不良而導致的用電風險的發生；
    3）環保牌：在臥室支個蚊帳，即溫馨又浪漫，還無滅蚊產品的各類化學合成的氣味，最環保不過了；
    4）衛生牌：在床上支個蚊帳，將有效的減少灰塵降落，也免了蜘蛛等小蟲在晚間不意間打擾我們的安眠，多好的一件事！
    。。。。。。
    啰啰嗦嗦，直說的口干舌燥，并許下一堆好處之后，終于換來老婆的點頭。于是二話不說，拉上夫人，直奔商場，在東挑西比之后，買下一款合意的落地式蚊帳。
    至此，我的環保蚊帳計劃就此實現！
 
    所以，回歸和懷舊，并不都是倒退！

        在一周前，項目組碰到一個大問題：NTKO Office Activex控件在上傳文件及提交頁面信息時，其提交的頁面元素輸入中文值變成了無法識別的、也不屬于已知編碼中的任何一種編碼格式的亂碼；但在NTKO Office Activex控件包裝項目組提供的的測試項目中，此問題并未出現，因此判斷是項目兼容性所導致。
       在項目組功能開發員和控件包裝組成員進行近一周的努力后，也未解決此問題。最后，此問題交由我來做最后分析和處理。
       經過三天時間對問題項目的分拆、組裝、分析、測試后，終于找到問題所出，現將此過程進行記錄，以備參考：
        1）以控件包裝組測試項目為基準，建立項目級測試項目，并保證在此測試項目中不存在兼容性問題；
        2）檢測web.xml：將問題項目的web.xml代替測試項目中的web.xml，未出現兼容性問題，從而排除因web.xml的差異而導致的兼容性；
        3）測試問題項目中的項目依賴：將問題項目的項目依賴關系復制至測試項目中，發現兼容性問題未出現，從而排除項目依賴導致的兼容性；
        4）檢測支持包：將問題項目中的支持包（各jar）代替測試項目中的支持包，未出現兼容性問題，從而排除因支持包的差異導致的兼容性，也就排除了各servers,servlet,listener等導致的兼容性問題；
        5）檢測js支撐：將問題項目中的所有相關js文件取出，代替測試項目中的相關js文件，未出現兼容性問題，從而排除因js支持文件的差異導致的兼容性；
        6）檢測css支撐：將問題項目中的所有相關css文件取出，代替測試項目中的相關js文件，未出現兼容性問題，從而排除因css支持文件的差異導致的兼容性；
        7）檢測tld,xml文件：將問題項目中的tld,xml文件取出，代替測試項目中的tld,xml文件，未出現兼容性問題，從而排除因tld,xml的差異導致的兼容性；
        8）至此，正常解決的兼容性措施都已用完，還是未找到問題所出！如何辦？
        9）開始使用非正常手段進行排查：
            <1>對比檢查.project和.classes未發現異常，從而排除基本項目配置導致的兼容性；
            <2>將問題項目的web項目設置文件(.settings)代替測試項目的web項目設置文件(.settings)，問題出現了！繼續排隊分析，發現問題出現在文件org.eclipse.wst.common.component中，
問題項目的設置為：
                                    <?xml version="1.0" encoding="UTF-8"?>
                                    <project-modules id="moduleCoreId" project-version="1.5.0">
                                       <wb-module deploy-name="XXX_IC">
                                       <wb-resource deploy-path="/" source-path="/web"/>
                                       <wb-resource deploy-path="/WEB-INF/classes" source-path="/src"/>
                                       <wb-resource deploy-path="/WEB-INF/classes" source-path="/test"/>
                                       <property name="java-output-path" value="build/classes"/>
                                       <property name="context-root" value="XXX_IC"/>
                                   </wb-module>
                                   </project-modules>
測試項目設置為：
                                    <?xml version="1.0" encoding="UTF-8"?>
                                    <project-modules id="moduleCoreId" project-version="1.5.0">
                                       <wb-module deploy-name="test">
                                       <wb-resource deploy-path="/" source-path="/web"/>
                                       <wb-resource deploy-path="/WEB-INF/classes" source-path="/src"/>
                                       <wb-resource deploy-path="/WEB-INF/classes" source-path="/test"/>
                                       <property name="java-output-path" value="build/classes"/>
                                       <property name="context-root" value="test"/>
                                   </wb-module>
                                   </project-modules>
且無論如何修改"XXX_IC"，都會導致兼容性出現，最后沒辦法，將下劃線"_"去掉，奇跡出現了。
        原來NTKO Office Activex控件在提交數據時，是通過scoket模擬Http進行文件和頁面元素的提供，如提交的頁URL完整路徑中包含了"_"等字符時，將導致無法識別，從而導致兼容性的產生。

 

從小到大，椰子已經吃過很多次了，但在這些吃椰子有經歷中，我只知道一種吃法：開孔à插吸管à喝椰汁à丟椰殼à完事！

       但在今天，事情有了些變化，于是產生的椰子的第二種吃法。

我和夫人在散步時，順便準備到超市買點水果，看到水果區的椰子又大又好且正在打特價。心中一動，就挑了個大的，買回家準備細細品嘗一番。在按通常吃法吸光椰子中的水汁后，突然想起，我們平時很喜歡吃超市中的一種叫椰角小吃的，又甜又韌很有嚼勁，但椰角是長大哪的呢？不會是椰子樹上的另一種產品吧！看著椰子開口的硬殼下面的白色軟組織，我們就突發奇想，這白色軟組織會不會就是那椰角呢？

說動就動，先用刀將空椰子殼砍開，發現其內層確實是一層約0.8cm厚的白色果肉。小心的切下一小塊嘗一嘗，味道淡淡的，很有韌勁，確實就是那椰角的源料。這就是我發現的椰子的第二種吃法了。

在生活中有很多事：你沒經歷，就不會想到；當你想不到時，美好的事情就可能錯過！
    這就是生活。

                                                                                    2009/5/5夜

 

在我們公司的軟件研發體系中，存在著三種截然不同的軟件開發方式。而我，作為公司最老同事之一，也是這三種開發模式的親歷者，曾不只一次的被公司同事問過我關于這三類方式之間的異同點。于是利用空閑時間，對其進行一番整理、分析和對比。

1、全能型

部門經理在接到項目之后，將此項目交給部門內的熟練程序員后，此程序員就自動被委任其為項目經理。從此開始，程序員將根據項目售前方案和銷售合同內容，在項目進行過程中分別擔當起項目經理、功能設計師、數據存貯設計師、程序員、測試員和項目實施人員等諸多角色。并在項目進行的過程中，帶領少量其它程序員和輔助資源來完成此項目的所有工作。

此類項目其功能單一且不復雜，只是為了幫助用戶提升某一項工作的工作效率或解決客戶在其工作中的一些問題，如工作日志信息的采集和分析業務項目、辦公用品的申請和領用等。它們因為其涉及范圍小，使用人員不多，從而具有項目總費用少、開發和實施周期短、對性能要求不高的特點。

在此類開發模式中，程序員由于其工作的全面性，使他們在進入項目組后，能夠得到很快且全面的提升，并會在與客戶交往的過程中，建立起良好的客戶關系處理經驗，為其今后的成長和發展打開良好的基礎。

由于項目需要，程序員需要掌握全面技能，容易造成其在項目開發過程中需要全面的接觸項目管理及人際關系、需求分析、數據庫及對象設計、人機交互和用戶體驗設計、系統設計和開發、測試和系統提升、應用實施和售后維護等諸多截然不同的領域范圍；所以，作為此類程序員，其工作壓力之大，事務之復雜、綜合素質要求之高，是其它模式的程序員所無法對比的，這也是造成此類項目按時完成率極低、尾款回收困難、項目售后工作難做、用戶滿意度差、二次項目獲取困難的根本原因。

同時，由于程序員被大量的非開發性事務所干擾，造成他們無法專心致力于專業技能的學習和提升，也就無法造就一支高效率、高穩定性、配合默契的開發隊伍，這也是造成公司內此類人才大量流失的重要原因。

2、英雄型

       部門經理在接到此類項目后，按項目所涉及的領域范疇，將其按領域進行分工。以企業信息協同系統為例，我們將進行如下分工：門戶信息的獲取、聚合、交互和展現工作交給專職于門戶開發的程序員；內部郵件系統的分析、設計、和實現將給郵件開發程序員；日程和事務的設計交給日程開發程序員；工作流應用工作交由工作流客戶化開發程序員等等。

       在此類型的開發模式中，程序員將會是某一領域內的英雄式人物！由于他長期且相對穩定的負責著這個有限領域范圍內的一切事務，可以幫助他在一定時期內進行系統而穩定的業務研究和分析工作，進而成長為此領域內的業務專家。而且，通過持續的對其工作進行迭代式開發、升級和完善，可使此產品在產品品質、適用性和用戶體驗等方面得到穩定的提升，進而提升了整個產品的品質。

       如果此領域內的工作產品能夠得到合理的規劃和實現，進而將其進行單獨的封裝、應用集成和推廣，就有可能形成一個具有相當競爭力的產品，從而為公司獲取新的銷售機會和利潤點。

       但是，此類開發模式中的分工也容易造成程序員涉及業務領域單一和適應性窄的缺陷：由于其長期面對和研究著單一業務領域內的業務活動，而無法更多的接收和參考來自于用戶、企業和其它行業內的非它業務發展需要和趨勢，從而對其在產品領域內的發展產生限制，并造成其產品方向上的不準確或錯誤定位；由于其長期的在單一領域內工作，并在此領域內獲得了公司內的認可，這也將限制他在領域間的流動性。當公司或部門的產品方向和需要調整和改變時，此類程序員就需要被迫改變甚至放棄其在原領域內的所有積累而重新開始，從而造成巨大的浪費。

3、專業型

       項目經理在接到項目之后，根據項目組成員的能力、特長職業規劃，對他們進行適當且專業化分工：由業務規劃人員負責項目的需求收集、業務規劃和需求分析；由系統架構師對系統的進行技術構架和支撐性技術的規劃和引進；由數據庫專員負責數據庫對象的設計和性能調優；由功能分析員在人機交互人員輔助下負責功能設計和人機交互模式；由業務邏輯實現專員根據功能設計進行高性能的業務邏輯處理實現和外部接口的設計和實現；由頁面開發人員負責實現人機交互；測試人員負責對系統進行全過程的測試和質量監督；專業化實施人員可快速高效的進行系統實施和在線維護，售后服務工作也將由專人負責；

       通過恰當和合理的分工，將軟件研發過程中的各個環節進行拆分，從而將復雜的軟件工程分解成一個個相對獨立且又緊密關聯的工作項，從而有效的降低了軟件開發過程中的困難度和風險性；項目經理把分解后的工作項交給項目組中的合適項目成員，并根據項目組成員的能力、工作難度和工作量，制定出科學的項目計劃；同時，項目組成員在項目經理的協調和管理下進行密切的分工合作，此舉即能調動項目組成員的其工作積極性，又能使他們將工作、興趣和個人職業成長規劃進行有效的結合，從而使其在技能、收入和社會認可度等諸多方面得到快速成長，達到人盡其材，材盡其用的目的。通過使用專業的人做專業的事，公司將在人員分工、資源使用和業務拓展等領域走向專業化、規模化，最終成為專業且強大的產業實體。

       但此開發模式也具有相當的局限性！其一，如何合理的利用項目組資源？項目組成員因其性格、能力和興趣各有不同，如何能將他們按項目分工和角色組成需要，進行專業化訓練和培養；其二，因項目組成員長期單一職能的工作，與其它環節的交叉和交流都受到限制，對其未來的全面發展和綜合成長都很不利；其三、各角色之間的分工、合作與工業化生產中的生產線相似，那么，建立與之相適應的質量保證體系，保證各工序之間生產產品的質量，從而從事實上提升軟件產品的整體質量？

       通過對這三類開發模式的分析，我們可以看出，它們各有合理性，也又具有的相當的局限性。

       全能型開發模式是早期的CS類項目開發的主要模式，其適用于哪些規模小，程序員少的小規模IT開發企業進行小型項目的開發中。但對于那些工期較長、業務范疇廣、復雜度較大的項目，此種開發模板將采用將導致風險最大化，失敗幾乎是其唯一的結局。

       英雄型開發模式，因項目組成員領域化的分工和合作，使它在通用型復合類產品開發中具有優勢。通過對產品的各組成部份進行持續的改進和迭代性開發，使產品在功能、性能、用戶體驗等方面得到持續的改善和提升，從而有利于產品拓展并在此過程中做大做強，最終取得競爭優勢。但此開發模式也將導致項目組成員之間的工作協調、技術互用等方面存在諸多不便；另外，因領域的專業性和不可替換性，也就限制了公司在處理關健人員的流動性方面存在諸多困難，并在核心競爭力的保證方面存在著很大風險。

       專業型開發模式，通過對人員進行專業化分工，從而在軟件開發過程中最大的利用了人力資源，提升軟件的生產效率，并降低了軟件的從業門檻。此方式在新形式下的項目開發和產品研發中都具有相當的競爭力，也易有利于保證公司的核心競爭力。但采用此種開發模式時，需要完善內部的人員激勵機制，保證各角色的從業人員都有與之適應的職位規劃和發展模式，并能根據項目組成員所處階段的需要，提供相應的技能培訓和交流機會，從而促進其成長，激勵其上進。

       總之，采取何種開發模式，要根據公司的實際業務情況，發展規劃和人員構成，進行科學的分析之后，再采取行動、從而得到具有延續性和競爭性，并與自身相匹配的軟件開發模式。

                                                               2009/4/20夜

         

今天，在陪夫人逛街回來的路上，看到一幕慘劇的發生：一位中年男子，從家中跳樓而下，墜落于堅硬的水泥地面上，當場身亡！

人生為何？為已？為親？還是為他？

人生為已，就應該珍惜自己的生命，為自己這短暫的一生中，充實、幸福和快樂的活著，而不能因為暫時的挫折、失敗而絕望和放棄；人生漫漫而無現存路，需要自己去探索和開拓，在此過程中，必然會經歷曲折和無法避免的挫折。但是，不經歷風雨，如何能見彩虹！挫折過后，往往就伴隨著一段平坦的直道；人生艱難，生活、事業、家庭、社會各種矛盾在我這會聚，理不清也扯不斷！既然如此，何不干脆看開，將不可調和的矛盾進行暫時地休眠，讓時間這個解決矛盾的最好的潤滑劑來慢慢解決它。

人生為親，為父母：他們含辛茹苦的將你從無到有、從幼養成，而你卻要在他們需要照顧和看護的年齡離他們而去！你忍心嗎！為妻：相汝以沫幾十年、同床共枕伴一生！鍋碗瓢盆一屋住，酸甜苦辣是生活。你就忍心在她人生路中間，正需你堅強的肩膀作支撐時，卻拋下她一人孤苦的走在這漫長的人生路上，你安心嗎？人生為子：父親是兒女的榜樣和偶像，他們需要借助你那成熟的智慧來打開事業的大門，也需要你那豐富的閱歷來開拓自己的人生路，更需要你成功的經驗來保護雛鳥并解決初飛時所遇到的種種風險！在這種關鍵的時候，你卻拋棄了他，你放心嗎？

人生為他，為朋友兄弟：有多少美好時光值得回憶，有多少美妙經歷值得回味，又有多少坎坷擔當值得珍惜！你就此離開，從此兄弟聚首少一人，朋友舉杯缺一環！為事業：你正值人生當年，恰逢事業當期，失敗你經歷，成功應有你，酸甜苦辣都嘗遍，還有什么過不去？為社會：當今社會多少不平事，何必事事放我心！不必為人先，也不全落后；比上我不足，哪我就比下，實在比不過，阿Q一把也不錯！

生命如此脆弱，稍有不慎就將墜落：走在路上被車撞死，走下樓下被東西砸死，乘車墜橋而死，去醫院被錯藥藥死，上班被累死，下班被煩死，既然如此，何必再來一個自己尋死呢！

請珍惜生命，愛護自己！

 

20090330于家中

        項目組使用潤乾報表已一年多了，說實話，潤乾報表在國內同類產品中屬于非常不錯的最好的報表開發和應用產品。相應的支持也比較到位，使用人員及交流社區也開展的很合適。在這先給它們作個廣告！！！
        在項目中使用潤乾報表，對數據進行專業的報表應用和開發，我對其作簡單總結：
        1）對其服務器運行系統進行項目性客戶化開發，從而利用項目中的權限管理和模塊，實現對報表進行訪問控制。否則，這對企業級應用將是一個非常大的考驗。
        2）潤乾報表自帶的參數生成模塊、報表運行載體的樣式、風格都極其簡陋，與項目的實際風格可能存在很大的差距。因此必需對其進行深入的擴展和開發。我們項目組的經驗就是單獨開發參數生成模塊和潤乾報表載體，如此才保證了報表中心與項目的用戶體驗和交互性的一致性。
        3）為了更好的利用項目組資源，我們將潤乾報表開發人員獨立出來，形成專門的報表開發團隊。此團隊負責根據業務的需要，利用潤乾報表開發工具進行報表開發，即開發.raq報表文件。此部份人員可從項目組的普通成員和新進人員中進行培養，而無需占用大量的項目組中中高級開發人員資源，從而節約了項目組的資源。
        4）潤乾報表對過JSP標簽包含在jsp頁面中進行加裁我運行。我們稱此jsp頁面為潤乾報表運行載體。我們根據潤乾報表的運行載體進行了科學的分類，并根據分類開發出統一的報表運行載體頁面（jsp）。從而避免針對每個報表文件而開發與之對應的運行載體。此舉也大為減少了項目組的JSP開發人員的工作量。
        5）建立潤乾報表運行專用配置文件，將報表參數生成模塊、運行載體及潤乾報表三者之間的關系進行配置化管理，并以此為紐帶，將潤乾報表開發人員、JSP開發人員（開發報表運行載體和報表參數生成功能）聯系起來。

         在開發過程中，我們碰到并解決了如下問題：
         1）填報類潤乾報表在進行數據驗證時，其提示信息（以js的alert("...")方式提示用戶）成亂碼顯示：此問題是由于潤乾報表在V4.1以后，統一使用UTF-8作編譯編碼。因此，要解決此問題，需要將項目的編碼也改成UTF-8
         2）在潤乾報表的參數賦值需按序依次進行賦值，而不能采用參數名進行統一賦值。因為，如果在潤乾報表的SQL中使用了重復的參數進行賦值時，會報參數找不至的錯誤。
         3）在參數生成模塊中將中文參數值傳遞給潤乾報表時，會導致少量的參數值在傳遞過程中發生改變，如“機油”變成了“箕油”。此問題是由于在urlEncode和urlDecode的bug導致，請在開發時需特別注意。我們是通過自己對信息進行加碼和解碼來解決此bug。
         4）潤乾報表的運行環境與應用服務器的編碼方式有關：我們項目和報表中心的編碼方式為UTF-8，但運用服務器（WAS6.1）的編碼方式為GBK時，通過參數生成功能將中文參數傳遞給潤乾報表時，會出現亂碼問題。在將WAS的輸出和運行編碼改成UTF-8后，才解決此問題。

        前段時間，項目組安排同事進行項目移植，并考慮在其過程中進行技術預研等相關工作，以對項目進行優化；
        在此過程中，有同事誤解面向對象化開發的精髓，在匆匆了了解JavaScript面向對象的方法和示例后，對項目中的公共門戶頭以對象的方式進行重寫。結果，將原30行的單一文件代碼變成了400多行，并分布于多個文件了。
        在拿到此結果之后，我是哭笑不得，于是得出了：“新技術的引入必需能夠提高生產效率或降低工作難度，否則，沒有引入的必要”這句話。