一直有朋友發email來索要那本OpenDoc的源代碼，這里一并給出下載地址。
http://www.tkk7.com/Files/zbw25/code.rar抱歉，拖了這么長時間。
Update：
昨天在BlogJava上傳的文件，今天就不能下載了，比較暈。。。
http://www.javaeye.com/topic/19448這是在JavaEye的發布OpenDoc的地址，里面有下載的Link。
http://www.javaeye.com/topics/download/54f814f5-b77f-46e1-bf61-bd384493f118應該要注冊成為javaeye的用戶后，才能下載。
posted @
2006-10-18 19:45 讀書、思考、生活 閱讀(108324) |
評論 (11) |
編輯 收藏?
?
我寫的總結
?
如果和超級女生這樣的大賽相比的話，
Ajax
大賽應該被稱之為“
Ajax
小賽”吧。
250
名初賽選手，
10
多名復賽選手，三個來自于一個網站“
Ajax
中國”的評委。這樣的比賽意義在哪里呢？
?
僅僅看數量，是看不出來的。
?
Ajax
是
Web
應用的一種，而且可以肯定的說，是
Web
應用中最為復雜的一種，一個
Web
項目，我們通常都會分為“美工”、“
Web
靜態頁面制作”、“
Server
端系統開發”這樣幾個工種。而
Ajax
應用則同時需要
Server
端與
Client
端復雜的端到端編程技術。
?
對于參賽選手而言，這些工作，都得靠一己之力來完成，在
2
個多月之內，做出來的作品，要美觀，要好用，要有創意，要符合
W3C
組織的
Web
標準，還得正確有效的作為一個程序在瀏覽器里運行。真的，不容易！這
11
位（可能會修改）參賽選手，每一位都不容易！
?
我們（大賽組織者、評委和參賽選手）都非常確切的意識到，我們正處在一場變革剛剛起步的階段。
Ajax
可能僅僅是這場革命開始時，最響亮的一個名字。激動人心的發展將會接踵而來，而我們這些人將會自豪的宣稱，我們從一開始就不是旁觀者，而是實實在在的參與者，和有力的推動者！
?
看著選手們的代碼，我們的信心更加充足，這些
Ajax
的愛好者和參與者們，不僅是熱忱的，更是踏實的。不但是嚴肅認真的，更是勇于創新的。由這樣的一群人來推動
Ajax
在中國的發展，實在是一個極好的開始。
?
而
Ajax
大賽，正是這樣一個機會，使得這一群中堅力量，能夠集結、凝聚，進而取得更加卓越的成就。這就是我對于這個比賽意義的理解。
? 說實話，稍微吹了一點
posted @
2006-07-14 21:35 讀書、思考、生活 閱讀(30221) |
評論 (0) |
編輯 收藏“出來混，總是要還的。”這話說得真好。我最近的blog寫得太少了，想寫的東西，其實又實在是不少，一日復一日的堆積心里，又想寫，又不想寫，難受呀。
這篇blog原本還是打算在Word 2007里寫的， 后來作為草稿發上來，發現還有不少不如意的地方，還是在線寫吧。
想說的事情挺多的，一件一件的說吧。
一、敏捷中國大會，6月6日在上海交大舉辦了一場。專門介紹ruby的，昨天在csdn的martin fowler的中文blog上，也貼出了完整的演講全文。《Ruby是一個非常好的開發工具》，《現場演示Ruby編程》，《細數Ruby語言優缺點》。關于這次活動的一篇Blog按理我早就該寫了，但是卻一直沒有寫出來。有兩個原因，一個是那天老馬在開講之前，熊節是打算在邊上當翻譯的，誰知道交大的同學們牛啊，紛紛表示，不必翻譯，都聽得懂的，我一個學俄語的人，在那里抗議也沒什么用，大家都一副聽力很好的架勢，老馬在上面嘰里呱啦的講著，下面的同學們不時的笑著……我呢，也只能隨著大家的笑聲，沖著老馬空洞的笑著……；第二個原因呢，是個原本打算等CSDN的演講的翻譯出來，我也好引用一下，誰知這一等，就是半個月，我都已經換了一個工作了。
說實話，那天老馬的演講，我沒聽懂，不過因為他在那里現場coding，所以我還是看懂了一些代碼。Ruby的代碼給人留下了深刻的印象，而且我不知道是不是Martin故意裝作是一個初哥，反正看起來他對ruby的語法也不怎么熟悉，不過ruby厲害的地方就在于，你就算是個初哥，邊試邊弄，也能把程序鼓搗出來。
原本的計劃是介紹Ruby DSL的，不過時間明顯的不夠用，關于DSL的部分反而講得很少，還好這兩天armlinux-w翻譯了一篇專講Ruby DSL的文章過來：《用Ruby 創建領域特定語言》。當時看到Martin演示的，用Ruby語言描述的配置文件時，腦子里頗有些想法，也寫了問題交上去問，不過老馬也來不及一一回答，后來想想，提的那個問題，也沒有經過自己的深入思考與實踐，不提也罷。
倒是我提的另外一個問題，頗有些價值，當時正好交大的林德樟老師也在，我以前就對林老師的那句語錄有所不滿《XP是草書，UP是正楷，先草書后正楷，就會亂套》。在自己的Blog上也和林老師的門徒們吵過架，如今Martin教主本人既然來了，我等看客正應該把這仗挑起來才是。于是我就提了一個問題，讓兩位專家都來評價一下這句話。可惜的是，后來他們兩人的精彩交鋒，我也沒怎么聽懂，還是林老師還用中文闡述了一遍自己的觀點，我算是了解了一下他的邏輯。
原來我以為，林老師這樣的說法，是出于在校教師“和稀泥”的考慮。這下我才了解到，原來林老師是真的這么認為的。而他這么一種說法的依據，還是慣常的“中國國情論”。或者稱之為“補課論”。因為美國人是現有軟件工程，才有極限編程，而我們現在的軟件產業還落后人家幾十年，所以不把軟件工程這一課不上，是不行的。然后林老師還頗有些“攻擊力”的詢問Martin，當初你先寫了UML，后來又寫了XP，不也是這樣一個心路歷程嗎？老馬如何回答，我也沒有聽懂，但是在我看來，林老師混淆了三個概念，一個是國家級的軟件產業的發展水平，一個是企業級的軟件開發的管理水平，一個是開發人員的技術與理論水平。這三個不同的水平被他攪在一起，用于支撐自己的說法，實在是???????所以，會后我又追上去問林老師，我提出了三個概念混淆了云云，沒想到林老師相當和藹可親的對我說：“嗯，你說的沒錯”，然后又說到關于大學的軟件教育的問題，我在說很多剛畢業的學生，對于軟件開發的理解，往往停留于知識點的積累上，而沒有去思考，我打算把這些知識點，組合起來運用，以達到什么目的。很多學生，只是說我知道什么什么，而不會說，我會做什么什么。林老師又和藹可親的對我說：“嗯，你說的沒錯。我一直跟學生們說，學校和企業是完全不同的，真正的知識，只能在企業里才能學到。”然后我又說，其實軟件學院應該多推薦學生去企業實習，還有就是多鼓勵學生參與Open Source的項目呀。林老師還是和顏悅色的對我說：“是啊，不過現在的企業，要他們肯接收學生實習，不容易的。在美國，每年暑期都會有大量的實習生招聘，這其實就是企業在做慈善呀。再說現在的大學老師，對Open Source的了解，也很少的呀。”然后，我就跟林老師告辭了。作為一個老師，他給我留下了很好的印象，但是，我更加悲觀的發現，要通過學校教育，提高軟件開發人員的素質，好難啊！
會后大家又找了一家小飯店FB了一下，CSDN的霍泰穩也來了，我還給他們提了一個建議，以后CSDN最好能夠搞一個系列的活動，不斷的把世界各地的軟件大師們請到中國來，巡回演講，收取門票，整理成每年基本的《軟件大師在中國》這樣書出版，還有視頻光盤也可以賣錢，各位大師的中文Blog也都建在CSDN，應該是一樁雙贏的好事啊，就看他們是不是打算做了。
(待續)
posted @
2006-06-20 23:05 讀書、思考、生活 閱讀(28451) |
評論 (6) |
編輯 收藏最近一直在討論招人的事情，如何判斷一個人的水平，怎么樣才算是沒有bug，等等等等。也看到一些并不怎么有趣的反對意見，比如：
不要出來搞笑說：
沒有bug的程序？????????
靠，站著說話不腰疼。那個公司可以做出沒有bug的軟件來？
當然，沒有寫過程序的人不出bug!!
估計這位同志不會寫代碼，是個理論專家。
還是不要這么狂的好。
我估摸按你的標準，你是肯定不會被別人錄用的！
123說：
你是編程的嗎？
無“BUG”搞笑吧你
測試是不能查出所有BUG的
而且不是所有測試都能窮舉的
只能是測試覆蓋率達到一個標準
BUG出現的概率達到標準
才算產品
“ZERO-BUG”做夢去吧
說實話，這兩個名字我看都不是用戶名，而且很可能是同一個人，就是所謂的troller。我說的沒有bug，是交給我的demo沒有bug，這樣的要求很高嗎？我還沒有出算法題，要求應聘者的算法效率呢？僅僅要求一個正確實現簡單功能的程序，很過分嗎？
?
在JavaEye還看到另外一篇帖子《
大伙能進來討論下“跳槽”的問題》，有一個小伙子，對自己的代碼有感情，對人有感情，對公司有感情，所以當公司遇到困難的時候，一時間舍不得走。這樣正常的事情，居然頗遭到不少人的冷嘲熱諷，和各種“善意”的勸誡。
?
我就覺得非常奇怪，一個程序員，如果對自己寫的代碼沒有感情，怎么可能寫出漂亮的代碼來？同樣的道理，如果一個程序員，對自己的工作質量沒有追求，又怎么可能成為高水平的程序員？一個前來應聘的人，為了得到offer而寫的demo，就這種情況下，在寄出代碼之間都不認認真真的檢查檢查，這樣粗心大意的家伙，我怎么敢招？
?
總而言之一句話：“對代碼有感情，對質量有追求”，這是成為好程序員的基本前提。
posted @
2006-06-18 02:23 讀書、思考、生活 閱讀(28071) |
評論 (14) |
編輯 收藏 我寫了一篇blog叫做《
招人不難》，很多朋友很贊同，也有的朋友不同意我的意見，他們很懷疑：“有bug的一律不要？沒有BUG的代碼是不存在的...blabla”
?
正好今天又看到一篇轉貼的笑話，叫做《
【轉】從一個笑話看軟件開發管理》，大意是，程序員交出了自以為沒有bug的代碼，然后一切都變得越來越糟糕，而程序員總是會交出自以為沒有bug的代碼。
?
我們今天就來談談，一個程序員，什么時候可以交出自己的代碼，并且可以自豪的對別人說：“我的代碼里面，沒有bug！”。
?
先說傳統的做法，一個負責的程序員，應該在交出代碼之前，自己跑好多次自己的代碼，左看右看，上看下看。直到交出去的時候，沒有一個人能夠發現其中的問題。這樣的能力一般只有天才才能具備，我以前
遇到過一個。但是，如果我企圖以這樣的標準來招人的話，那就是在發瘋，怎么還敢說“招人不難”？
?
說說可行的辦法吧。一個程序員如果足夠的謙虛，時時想證明自己可能犯錯，即將犯錯，或者已經犯錯。那么他就會盡量寫出足夠多的TestCase，以便打消自己的疑慮。直到所有的測試用例全部通過，屏幕上顯示出美麗的綠色長條，他才能確信，自己的代碼沒有bug。
?
所以，我的判斷標準，也很簡單。如果寄給我的代碼，沒有附帶測試用例，我就自己運行他的程序，隨意的亂找，找到一個我認為是bug的，那就是有bug了。如果寄給我的代碼，附帶了足夠的測試用例，我只要Run一次，看到綠條，這一關就算是過了。～～～很簡單吧。
?
也許有人會說，那如果他的測試用例很簡單呢？豈不是不能說明什么問題？怎么不能說明問題呢？首先可以說明：這是一個會寫測試用例的程序員！其次，我會看看他的測試用例的代碼，大概覆蓋了多少的功能特性。當然，這是更進一步的能力判斷。但是至少，他的代碼已經達成了他自己的設計了呀。
?
所以：“有bug的一律不要”，意味著，你最好能夠自己證明自己沒有bug，否則，我如果找到一個bug，你就沒戲了。
posted @
2006-06-11 10:34 讀書、思考、生活 閱讀(29286) |
評論 (10) |
編輯 收藏 孟老師最近有點煩，
面試了一個剛畢業大學生，結果發現那家伙一問三不知。隨后的跟帖也是常見的感嘆：
“現在的大學生過于浮躁”
“真不明白本科都在學什么”
還有一位臺灣同胞說：“本來還以為只有在臺灣有這種情形，原來兩岸的情都相同。”
?
因此，打算寫這篇blog，介紹一下我是怎么招人的。其實，招人并不難。
?
1、寫招聘廣告
2、收簡歷，初步了解背景情況，然后讓加我的MSN
3、在MSN里，就問一個問題：以下幾種技術，你哪一種最熟悉，哪一種最不熟悉
4、你就用最不熟悉的那種技術，做一個demo給我，沒有時間限制，要求如下：
－首先是demo的質量，一定不能有任何bug
－其次是代碼的質量，要干凈，明白，好懂。
－要有創意
－在功能創意與時間進度之間，自行平衡
5、拿到代碼之后，先看看能不能正常運行，看看有沒有bug。
6、在Google里搜索代碼的關鍵段落，看看有沒有抄襲，或者了解一下借鑒的程度
7、看他的代碼，是不是足夠干凈，足夠合理，足夠樸素
8、如果一個人能夠在很短的時間里，自行快速學習一種新的技術，并交出足夠質量的代碼。這樣的員工，我就準備要了。至于面試，無非是談談工資的高低意向罷了。
?
這樣的招人辦法，要點在于：
1、我不關心他的學歷，工作經驗，年齡和技術背景，因為招到一個出色的員工，他會持續的自我學習，不斷的進步。
2、有bug的一律不要
3、代碼最能夠說明問題，其他一切判斷都要在我看過他的代碼之后。一個人，不要玩弄聰明，不要炫耀技巧，寫老老實實，干干凈凈的代碼，合理的貼切的變量命名、方法命名、類命名，合理而不多不少的類間關系。這樣的代碼，就是漂亮的代碼。能寫出這樣的代碼的人，就有足夠好的思維和品性。
4、快速學習的能力要比過去的工作經驗更加重要，因為那么多工作經驗，也要有助于完成今后的工作，才能體現出價值。
5、不抄襲，有創意，這樣的人才很難得。
6、有計劃的實現功能，能夠在功能和時間進度之間合理決斷。這就是有大局觀的人才。
?
當然，這樣招人的基礎是，你自己的代碼水平要夠高。很多公司根本就沒有這樣的水平，只能靠筆試來判斷人家的水平。
?
我工作過的公司，曾經有一個小伙，他的代碼，縮進不是靠Tab，而是“按下空格鍵，任代碼隨意后退”，他的代碼，彎彎曲曲，難看至極。前兩天，他跟我說“我筆試得了90多分，當場拿到了4.5K的Offer。”可見，筆試是毫無意義的測試手段。
?
btw：還有問題，這樣招人效率不是很高，也比較累，緊急招人的情況不適用。當然，緊急招人的項目，通常肯定是搞不好的。
posted @
2006-05-30 16:11 讀書、思考、生活 閱讀(29031) |
評論 (36) |
編輯 收藏 大多數程序員，都極度痛恨寫文檔。Coding是愉快的，而Write是痛苦的。有一部分原因，其實是要歸咎于程序員自身，以我的經驗，很多程序員往往會“艱于表達”，尤其是用“文字、圖表、PPT、Word”之類的Office Document來表達。當然，還有一部分原因，是由于很多項目開發實踐中，文檔的前后矛盾、形式主義、反復修改、歧義重重，常常讓程序員們抓狂。
?
UML是一個比較好的工具，但是，僅僅靠UML，是無法將項目的知識描述清楚的。也有不少項目組在引入了UML之后發現，文檔的工作量不但沒有減少，而是更多了。隨著項目的進展，需要維護的設計文檔數量，也更多了。也因此造成了更多的前后矛盾，形式主義，反復修改。
?
根本的痛苦，并不在于一開始寫一份文檔，而在于所有寫下的文檔，都必須跟隨項目的進展而隨之變化。當我們寫出來的文檔越多，需要被持續維護的文檔也就越多，需要反復檢查文檔間的可能存在的矛盾也就越多，所有扔出去的石頭，最后都會落回到自己頭上。
?
于是，還有不少項目組，將文檔工作與代碼工作截然分開，文檔就寫一次，用來應付上面的管理層，而代碼自管自的繼續開發。對于小型項目來說，這其實是一個不錯的權宜之計。但是一旦項目越來越龐大、復雜。所有的隱性的知識，都僅僅存在于程序員的腦子里，所有成文的東西，都可能是錯的，而真實的情況，卻隱藏在代碼之中。如果代碼質量再糟糕一些，后來維護的朋友，就遭遇火坑了。
?
文檔，寫還是不寫，這是一個問題！
?
還記得測試驅動開發嗎？為自己的每一個方法，每一個類，都寫出單元測試來。不但如此，更加徹底的做法是，在寫代碼之前，先寫測試用例。這樣才能保證不會忘記寫測試用例。更大的好處在于，這樣有助于思考、有助于獲得更加完善的設計，有助于寫出更加高質量的代碼，有助于安全的重構，有助于自動化的持續集成實踐。總之，是好得不能再好的一項開發實踐。
?
這一實踐之所以可行，就在于他將繁雜的集中的測試工作，分解為日常的，必須不斷進行的工作。當你每天都在寫測試用例，當你的每一個測試用例，都能夠與代碼完全對應時，壓力反而減輕了，工作量也更少了，更重要的，一些優良的習慣也因此被養成了。
?
在兩年前，我要開始一個全新的P2P網絡電視項目時，也在考慮關于文檔的問題。當時我發現了Open Source的WikiPedia。這是一個PHP的WIKI，最大的應用是維基百科全書。因此，這個項目的質量就絕對值得信賴。我就將它拿過來，作為我們項目文檔管理的工具。
?
用Wiki來管理項目文檔，基于以下一些考慮：
文檔是項目的知識，這些知識必須集中管理、容易獲取、人人可以編輯。
項目在生長，代碼在增加，文檔也必須能夠跟隨項目自然生長，強行劃分設計階段和開發階段，是不可取的。
Wiki不是傳統的項目文檔，而是一個應交流需要，可能隨時增刪改的知識庫。項目組的成員，遇到問題，就應該首先查看Wiki，如果這是Wiki中沒有，那么他應該找人詢問。而那個知道答案的人，如果他不想再今后不斷的回答同一問題，就應該把這個答案寫入Wiki，這就是Wiki條目增長的自然動力。
傳統文檔最大的問題在于浪費，而Wiki通過持續修改，按需提供的方式，保證了所有寫下的文字，一定有超過一個人需要讀它。
?
在Wikipedia的基礎上，我又做了一些增強，以更好的輔助項目的管理。
Include功能，增加include標簽，可以在一個條目中，引入其他條目的全文，而不是僅僅增加一個link。
文檔的層次結構，當項目的文檔條目逐漸增加，分門別類的條目，更加便于查找，也可以有效的避免條目重名的問題。
一個Click，就能夠創建新一個條目，用于填寫當天的工作安排。
相應的管理制度，也必須建立起來。
每日15分鐘文檔制度，基于“填寫當日工作”的功能，我規定每個項目組成員，每天要花三個5分鐘來寫文檔，早上的5分鐘，填寫當日工作計劃。中午的5分鐘填寫上午的工作情況，下班前的5分鐘，填寫下午的工作情況。這樣，每天的文檔工作相當輕松，但是文檔能夠保證持續的跟隨項目成長下去。更進一步的，這樣的制度，對于項目的進度控制，也很有幫助。
User Case條目驅動，所有分解出去的User Case，在分配到責任人之后，該責任人的第一項工作，就是在Wiki中寫下對于這個User Case的理解。隨后項目進展，也應該持續的維護這個條目。
同時進行Bug的管理，Bug也作為Wiki中的條目，以便于和其他條目項目引用。
每次Check In CVS時，必須寫注釋。這是更加細節的文檔，然后我還做了一個小程序，能夠自動的從CVSTrac中讀出當天Check In代碼的注釋。供每個人在寫當天文檔的時候引用。
總而言之，我對于項目文檔的看法，并不是非此即彼的極端主義者。在我看來，好的項目文檔管理政策，應該有助于集中團隊知識和智慧，同時不要讓程序員痛苦和反感。這樣才叫做有效的項目管理。仿造Martin Fowler的著名文獻《持續集成》，我給這篇Blog起這樣一個名字《軟件開發文檔的持續集成》，希望能夠引發更多的、更深入的思考。
posted @
2006-05-12 14:23 讀書、思考、生活 閱讀(28648) |
評論 (3) |
編輯 收藏