2008年4月11日
這方面的文章網絡上一搜一大堆。偶也不引用了。
偶的感覺是python的安裝和組件安裝亂七八糟。ruby的安裝和插件安裝感覺比較爽。其理念是學習linux的port和apt的包管理思路。
昨天準備離職了。
其實在這家公司里面，項目leader對我很不錯，時間也是比較寬松的。給了我很多的機會學習。甚至曾經我有整整一個星期的時間去完整的學習ruby。對此我還是非常感激的。不過因為項目的原因以及各種管理上的不如意，我感覺自己始終不開心。
索性這次終于解放，于是我想先靜下心來，思考一下人生未來的路。順便學習一下我所喜愛的ruby和python。上次學習ruby已經是幾個月以前的事情了，學完以后基本上沒有得到什么使用的機會到現在基本上忘記了。這次一并將python也學了，并比較列出。
幾乎所有的語言，都包含以下幾個部分
1，數據類型 ————被處理的
一般包括數字，字符串，可能還包括布爾類型；復雜數據類型；對oo的語言還要包括對象等。
2，對數據的處理 ————語法部分，
a，操作符和表達式
b，條件判斷語句
c，循環語句
d，跳轉語句
f，異常處理
3，代碼的組織
a，文件的組織
b，函數
c，對象
4，類庫
a，標準輸出入庫
b，文件庫
等
以上前三個部分，是一個語言基礎的部分。但是對一個語言深入的了解，還必須結合這個語言的背景，哲學理念，才可以達到比較深刻的地步。是以我們對python和ruby的學習將從這個地方開始。
我曾是個技術粉絲
但是多年的開發經驗，使得我對技術的本質認識的越來越清楚。至少對企業軟件開發人員來說，純粹的技術coding是沒有多少價值的。如同建筑行業一樣，真正有價值的東西在設計階段已經完成了。
和傳統建筑行業開發不同，軟件開發行業不光是技術設計，還包括業務的設計。業務和技術摻雜在一起，構成了軟件開發的復雜性。
在業務上，在技術上，尤其是在技術和業務的鴻溝之間，存在了太多太多因素。使得我們本來對相對簡單的軟件開發不敢抱有那么大的樂觀。更何況真正一個成功的項目還需要市場，客戶等等各個方面。
作為一個軟件開發人員，真的應該放棄軟件自大的心態，客觀的去看待軟件開發技術在整個軟件開發工程中的位置和地位。以一種推動企業發展，推動項目發展和成功的心態和目的去看待整個項目。就明白了軟件開發的真正意義和任務。也就能更好的完成自己的工作，甚至可以改變項目的成敗。
所以成敗不由技術，成敗由你我的視野和努力。
最近公司項目經理派我研究工作流并考慮在項目中使用。很有一些心得。工作流應用我將之分為狹義工作流和廣義工作流。對狹義工作流而言，你可以將之理解為在工作流設計器里畫畫節點以及方向箭頭，設置好就節點數據，動作就差不多了。（具體可以參見jbpm的websale這個demo)。
廣義的工作流是對服務之間的整合。核心問題是業務節點和工作流節點之間的映射，以及業務數據和工作流數據之間的映射，和普通工作流一樣還有流程判斷等等服務。實現了這些，各個業務模塊之間的數據就可以通過服務，以定好的方式（進行方向控制和格式轉化）在各個節點之間流通，達到了服務整合的目的。
IBM為ESB定義了四個必備的功能:“路由器”——根據信息內容，在不同應用和服務之間進行信息傳輸和路由;“轉換器”——進行應用之間的通信協議轉換;“翻譯機”——進行應用之間的消息格式轉換;“收發室”——處理來自不同渠道的業務事件(同步傳輸，異步傳輸，發布/訂閱等方式)。
其中“路由器”和“收發室”都是針對服務的重用而設計的，而“轉換器”和“翻譯機”則專門用來解決異構的通信問題。
針對重用和異構這兩個難題，倪曉兵認為ESB提供了兩個核心的功能，服務的管理和數據的轉換。
我們DEC項目的目標就是建立一個全能服務倉庫（暫時我在DEC設計人員zy哪里得到的信息），而服務之間如何路由，如何轉換，語義的協調都沒有考慮，而后者卻是成敗的關鍵。
最關鍵的語義翻譯這一點，就現在的技術上來說還不能做到（需要很高的機器智能才能達到使得不同的系統的業務詞匯可以正確的映射，更何況是在所有的系統之間進行映射，同時應用在企業級的應用環境中）
也許真的有這樣的幻想，但是真的能夠做到這一步么？我深深的懷疑。就目前的技術手段，如果要達到數據映射的高度正確性，必須由人不同系統之間需要協調的數據進行語義確認方能進行有效的映射。
當考慮到還必須做到ESB系統對其接入的所有的服務數據的語義都這樣做時。我懷疑真的需要做到協調所有的服務么？
也許ESB的應用范圍就是在公司內部或者有限范圍內的整合目標明確的業務節點之間業務的整合。