http://wiki.woodpecker.org.cn/moin/ThePythonParadox

http://forum.javaeye.com/viewtopic.php?t=21245&sid=75490b7bdd393902d2f1775079ba67f2

將近兩個月沒有寫任何東西了，上一篇東西還是四月在匈牙利的時候寫的，發了一陣牢騷以后，就被卷入了無休無止的會議，文檔和debug過程中。
所幸做這些事情的時候到還比較順利，我們在匈牙利用的是迭代開發，反饋的非常及時，在開發和設計的過程中受到的壓力和干擾非常小，結果也不壞，回來的時候軟件已經能夠正常工作了，只是有一些輕微的bug。而采用了很多過程、方法和手段的另外一組卻遇到了很大的麻煩：用了一些不很合適的人手，在實際的開發之前浪費了太多的時間寫文檔和開會，在編碼的時候遇到了很多沒有預料到的問題……基本上都是人的問題。無論如何不應該把開發者只當作開發環節上可以隨時替換的零件，就是我對目前這個項目的體會。
年初的計劃看來要落空了，心里也千頭萬緒的，還老是勸人該這樣那樣，自己還沒有別人走的踏實，想來真是慚愧。工作以后沒有人監督，做事情也變得有一搭沒一搭的，堅持寫點東西應該是個不錯的主意，可惜沒有堅持住。還有小半年時間，抓緊時間吧。

以下宣言來自http://agilemanifesto.org.

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.
我不知道被標紅的這四條在今天還有多少人持反對的態度，對于我而言，敏捷宣言帶來的軟件開發價值觀念實際上是一種價值的回歸，我們需要能夠工作，運轉良好的軟件，我們需要為客戶帶來價值，我們需要適應這個變化多端的世界。軟件的內在復雜性決定了我們只能運用我們的聰明才智來克服開發過程中的種種艱難險阻，所以我們強調人的協作和互動，強調個人的充分發揮和團隊的緊密配合的和諧統一，強調代碼作為設計最終體現的重要意義，強調軟件設計的簡單和靈活性的完美結合。說到底軟件的開發是為了最終的使用，為了不斷的提供價值，為了不停的適應變化，為了給客戶帶來更大的經濟效益，離開了這些直接而赤裸裸的指導原則，一切的所謂文檔、流程、計劃和工具都是空對空的扯淡。換言之，如果像TDD,結對編程、持續構建這些XP實踐不能給我帶來實質性的好處，沒有讓我們的軟件能夠更加容易的開發，能夠為客戶提供更多的價值，我為什么還要做一個XP的實踐者？
如果簡單的贊成或者反對敏捷而沒有任何的經驗或者證據來支撐我們的觀點，無疑我們會落入非此即彼的認識怪圈，我們會成為所謂大師言論的奴隸和盲從者，如果沒有認真的思考和仔細的觀察，我們永遠也不會得到對我們自身真正有益的東西。在這一點上，敏捷宣言也無法幫助我們，我們必須更加仔細的尋找適合的開發方法，用一種更加實用的眼光來看待我們的軟件開發和新的工具、方法和開發理論。保持懷疑不是一件壞的事情，在日新月異的技術領域尤其如此。
說到這里，我覺得有一點跑題了，但是我本來要表達的意思已經很明確了，在SCIP的教學錄像里面，professor Sussman有一句話很有意思，作為今天的結束吧：Computers to make people happy, not people to make computers happy。

http://blog.donews.com/limodou/archive/2006/04/02/808281.aspx

最近的任務是做一個jni的接口給我們用java開發的產品使用，于是有機會體驗了一把Win32 API。
不得不說一句的是，MSDN確實是個巨大的寶庫，其他公司、組織、開源社區的文檔資源，確實無法和windows平臺相提并論。
首先找了幾本書看看，基本上都是按照侯捷先生網站推薦來看的，基本的概念都是了解的，缺少的就是實戰編碼和排錯的實踐，所幸任務也不是很艱巨，java和本地的Win32 api的接口非常簡單，所有的任務就是查找API，然后寫代碼，編譯測試。
我的c編程經驗基本上都是紙上談兵，雖然也看過c traps and pitfalls這樣的進階讀物，也仔細的做過The c Programming Language上大部分的習題，可是確實沒有任何實際的跟平臺相關的編碼經驗。在java里面工作的時間看來是過于長久了，牽涉到自己管理內存的地方就會非常的沒有自信，總是害怕會出什么亂子，幸虧MSDN上面的例子極為全面，參考書也是非常權威，有看著像的代碼，先貼到編輯器里編譯一下看看再說，就這么邊學邊做了。
最大的感覺是know how在Windows平臺上也是一件不太容易的事情，因為Windows操作系統本身就非常復雜的這個事實，蔡學鏞的“lots of APIs”成了一件讓人羨慕的事情，如果沒有IDE和MSDN的幫助，找到需要的API還真是一件讓人無比頭疼的事情，這個沒有什么辦法，程序寫得不夠，也只能摸著石頭過河了。
其次是對于基本概念的理解。這個差不多是重點中的重點，如果關于計算機的基礎知識能夠再厚實一些，如果對于編譯器工作的原理和鏈接的原理有一個扎實的認識，如果對于c語言外表下的那個馮諾伊曼體系有一個更扎實的理解，我想在任何平臺上都能寫出高效漂亮的程序。從這個角度上來講，c語言的高手會輕視其他高級語言程序員的這種心態，多少是可以理解的，也可以這么說，精通c語言和c語言表層下的那個計算環境的基本概念，是成為一個優秀程序員的必由之路。
當然了，我沒有萬般皆下品，唯有讀書高的意思，我的路還很長，我不想就這樣把自己禁錮在一個過于狹窄的圈子里，我的理想就是萬能程序員，在任何平臺上，使用任何編程語言，寫出任何用途的程序，要做到這一點，我就得珍惜我目前能抓住的所有的寫代碼的機會。我想夢想不是用來實現的，而是用來追隨的，對吧。