REST 相關文章表列

先由這裡開始吧!

用 SOAP 像 REST 一樣
http://blog.tcchou.org/Members/tcchou/tech/use_soap_as_rest
http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=11623

SIP/IMS網路中的Representational State Transfer (REST)
http://dev2dev.bea.com.cn/bbsdoc/20060529259.html

Building Web Services the REST Way
http://www.xfront.com/REST-Web-Services.html

Representational State Transfer
http://en.wikipedia.org/wiki/Representational_State_Transfer

How to Create a REST Protocol
http://www.xml.com/pub/a/2004/12/01/restful-web.html

一定要這樣玩弄技術名詞嗎?

xmpp erlang ...是什麼? 這些名詞不斷被提起,然而;這好像是在用嘴巴描述一件事不關己的事情,或是把它當成是飯後閒聊般的講述一次又一次沒有營養且毫無意義的東西,別這樣好嗎? 技術是需要深層的理解與思考的,沒有深度的探討 務實的探究 只是在浪費時間,無病呻吟是完全沒有意義的,技術的本身需要花時間去理解如果停滯不前,有再多的理由都沒有意義,不要一直在不著邊際的地方隔靴搔癢好嗎?這真是要不得的致命傷,無聊透頂了...

erlang 會成為下一個java ?

erlang 會成為下一個java ?
文章連結

其實應該說是functional language 的時代快來臨了,或是已經來臨
文章連結1
文章連結2
文章連結3

Erlang-China
http://www.erlang-china.org/

我跟他的觀點截然不同

我跟他的觀點截然不同
從高鐵售票系統談大型公共建設軟體開發專案 (我一直在不斷的強調,真正高負載的系統是不會使用RDBMS的,而高鐵的問題是Critical Section的問題,跟系統本身使不使用RDB是完全無關的)

1.不要猜問題所在

一個大的系統出問題時;常常很難有一致的答案,有時候表面上看起來是那樣,改完後也確實改善問題,但事實上問題並不出在這邊,這樣的事情常常發生週而復始,因此;當系統出問題時,需要猜測問題的所在,而且應該假設有錯誤的地方不在表面上看到的那樣,最後需要一針見血的猜測(排除絕對不可能的部份,試圖讓問題縮小,然後找到最可能的原因),絕大部分的問題一開始我們都不能知道答案,尤其是我們往往假設,我們所使用的工具是正確的

2.解決問題的心態

這個觀點也是錯誤的,事實上開發人員並不是在大型專案中試煉自己的技能,不斷的調適、熟練的過程...,這些應該是平時應該要做的工作,因此;我們希望RD至少有1/3 的時間在做研究 2/3 的時間來作發展,事實上我們還希望把比例顛倒過來,當一個開發人員,有了純熟的技能,自然能夠避免犯下不可彌補的錯誤,甚至在開發的一開始就能避免很多不必要的浪費,而且能夠開發出強壯且靈活有深度的架構,因為他平常已經練習好,而且它有很多時間練習,而不是把作專案或是產品當成是練兵
========================================================
上回遇到NOVELL 的外聘開發人員,我把我自認為RD 為軟體公司核心的理論跟他交換意見,結果他卻要自斷經脈,他說RD通常不懂市場...,寫出來的東西不知道要賣給誰,我聽完當場昏倒,我想請教的是軟體公司的核心如果不在技術,而創造技術的不是RD ,那麼這家公司確定是軟體公司嗎? 一個出色的RD 必然理解市場脈動,至少他會有一個值得參考的產品技術觀點,只有三流的軟體開發人員才會自甘墮落淪為高級打字員心裡想著何時要轉為PM...,真正出色的工程師不僅解決問題,他還能引領整個公司的發展方向,我們要看5年後的技術將往哪發展,我們要創造公司的技術研發的沿革歷史,而不僅是今年公司要賺多少錢