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

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

將近兩個(gè)月沒有寫任何東西了，上一篇東西還是四月在匈牙利的時(shí)候?qū)懙模l(fā)了一陣?yán)悟}以后，就被卷入了無休無止的會(huì)議，文檔和debug過程中。
所幸做這些事情的時(shí)候到還比較順利，我們?cè)谛傺览玫氖堑_發(fā)，反饋的非常及時(shí)，在開發(fā)和設(shè)計(jì)的過程中受到的壓力和干擾非常小，結(jié)果也不壞，回來的時(shí)候軟件已經(jīng)能夠正常工作了，只是有一些輕微的bug。而采用了很多過程、方法和手段的另外一組卻遇到了很大的麻煩：用了一些不很合適的人手，在實(shí)際的開發(fā)之前浪費(fèi)了太多的時(shí)間寫文檔和開會(huì)，在編碼的時(shí)候遇到了很多沒有預(yù)料到的問題……基本上都是人的問題。無論如何不應(yīng)該把開發(fā)者只當(dāng)作開發(fā)環(huán)節(jié)上可以隨時(shí)替換的零件，就是我對(duì)目前這個(gè)項(xiàng)目的體會(huì)。
年初的計(jì)劃看來要落空了，心里也千頭萬緒的，還老是勸人該這樣那樣，自己還沒有別人走的踏實(shí)，想來真是慚愧。工作以后沒有人監(jiān)督，做事情也變得有一搭沒一搭的，堅(jiān)持寫點(diǎn)東西應(yīng)該是個(gè)不錯(cuò)的主意，可惜沒有堅(jiān)持住。還有小半年時(shí)間，抓緊時(shí)間吧。

以下宣言來自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.
我不知道被標(biāo)紅的這四條在今天還有多少人持反對(duì)的態(tài)度，對(duì)于我而言，敏捷宣言帶來的軟件開發(fā)價(jià)值觀念實(shí)際上是一種價(jià)值的回歸，我們需要能夠工作，運(yùn)轉(zhuǎn)良好的軟件，我們需要為客戶帶來價(jià)值，我們需要適應(yīng)這個(gè)變化多端的世界。軟件的內(nèi)在復(fù)雜性決定了我們只能運(yùn)用我們的聰明才智來克服開發(fā)過程中的種種艱難險(xiǎn)阻，所以我們強(qiáng)調(diào)人的協(xié)作和互動(dòng)，強(qiáng)調(diào)個(gè)人的充分發(fā)揮和團(tuán)隊(duì)的緊密配合的和諧統(tǒng)一，強(qiáng)調(diào)代碼作為設(shè)計(jì)最終體現(xiàn)的重要意義，強(qiáng)調(diào)軟件設(shè)計(jì)的簡單和靈活性的完美結(jié)合。說到底軟件的開發(fā)是為了最終的使用，為了不斷的提供價(jià)值，為了不停的適應(yīng)變化，為了給客戶帶來更大的經(jīng)濟(jì)效益，離開了這些直接而赤裸裸的指導(dǎo)原則，一切的所謂文檔、流程、計(jì)劃和工具都是空對(duì)空的扯淡。換言之，如果像TDD,結(jié)對(duì)編程、持續(xù)構(gòu)建這些XP實(shí)踐不能給我?guī)韺?shí)質(zhì)性的好處，沒有讓我們的軟件能夠更加容易的開發(fā)，能夠?yàn)榭蛻籼峁└嗟膬r(jià)值，我為什么還要做一個(gè)XP的實(shí)踐者？
如果簡單的贊成或者反對(duì)敏捷而沒有任何的經(jīng)驗(yàn)或者證據(jù)來支撐我們的觀點(diǎn)，無疑我們會(huì)落入非此即彼的認(rèn)識(shí)怪圈，我們會(huì)成為所謂大師言論的奴隸和盲從者，如果沒有認(rèn)真的思考和仔細(xì)的觀察，我們永遠(yuǎn)也不會(huì)得到對(duì)我們自身真正有益的東西。在這一點(diǎn)上，敏捷宣言也無法幫助我們，我們必須更加仔細(xì)的尋找適合的開發(fā)方法，用一種更加實(shí)用的眼光來看待我們的軟件開發(fā)和新的工具、方法和開發(fā)理論。保持懷疑不是一件壞的事情，在日新月異的技術(shù)領(lǐng)域尤其如此。
說到這里，我覺得有一點(diǎn)跑題了，但是我本來要表達(dá)的意思已經(jīng)很明確了，在SCIP的教學(xué)錄像里面，professor Sussman有一句話很有意思，作為今天的結(jié)束吧：Computers to make people happy, not people to make computers happy。

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

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

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.

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

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