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