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語言表層下的那個計算環境的基本概念，是成為一個優秀程序員的必由之路。
當然了，我沒有萬般皆下品，唯有讀書高的意思，我的路還很長，我不想就這樣把自己禁錮在一個過于狹窄的圈子里，我的理想就是萬能程序員，在任何平臺上，使用任何編程語言，寫出任何用途的程序，要做到這一點，我就得珍惜我目前能抓住的所有的寫代碼的機會。我想夢想不是用來實現的，而是用來追隨的，對吧。

http://www.paulgraham.com/love.html
The essay was made by Paul Graham, I am afraid many of us don't know the man very well, and so do I. The article is very long and I have not finished it by far. But I expect we could get something useful from it.

    基本上轉換erwin的xml文件的python程序已經就緒了，但是在寫程序和考慮問題的這幾天里我反而有些糊涂起來，關于程序的設計和設計的選擇一直困擾著我。
    說到那個python程序，我已經重寫了很多遍了，Martin最初的那個程序其實很簡單，他的需求其實也沒有那么難，但是我把程序寫過幾遍以后發現了一個問題：我每一次都可以用完全不同的思路來解決這個問題，以至于我的程序都完全不一樣。我可以完全使用python內置的dict和tuple對象來存儲所有的Entity、Attribute、Key和Relation的信息，我也可以做一個Classitis，把所有能看到的結構都映射成為class defination，我甚至也想過functional的解法：利用一個map結構，讓每一個節點的數據通過一個方法的管道，然后在管道的另外一邊讀取我需要的信息……
    在Java里面，一切都很簡單，我只需要定義interfaces，他們必須遵守的契約，然后我可以在實現類里面實現我的解析過程，構造出我想要的對象結構，一切都順理成章，我可以利用interface來隔離各個模塊之間的耦合，比如對某一個parser的依賴關系，對于特定dom版本的依賴關系，對于dom的依賴（我想這個需求是合理的，因為我們完全可能因為內存消耗的原因而轉換到sax），甚至對于xml文件的依賴（當然，這樣我的設計就走得太遠了），然后通過IOC的方式把他們粘合在一起，我的程序就完成了。甚至于我可以這樣說，也許我的實現是naive的，也許我的代碼是低效的，但是我的思路是正確的，至少，reasonable。
    在python里面我找不到這種感覺：我覺得無論哪一條路都是可行的，OO的方法,functional的方法，甚至于過程化的方法都是可行的，然而又都是不太完美的，我也許可以使用在java里的經驗，但是我隱隱約約覺得會有更好地解決方案，由于這樣的原因（也許因為懶惰），我沒有做那樣的嘗試，怎么說呢，我覺得那樣興師動眾的方法在一個動態語言里太——不優雅了。在我多少了解一點functional語言和方法之后我尤其感到如此，那么我是不是在一條正確的道路上行走呢？我是不是應該繼續我的杞人憂天，還是埋頭在代碼之中，直到“理性之光”突然降臨呢？
    總有一天，我會弄明白的。

http://www.xprogramming.com/testfram.htm
基本上覆蓋了單元測試的每一個大的方面，使用smalltalk描述和實現，雖然語法比較奇怪，但還是能看出和JUnit和python的unittest framework的一脈相承的結構和思想，一個如此簡單的框架和思想，能夠在如此廣泛的范圍內影響軟件的開發，確實不簡單。