關心的，我原來也改過mediawiki的代碼，等你寫出來，咱們交流交流。

握手，握手！

學俄語的苦啊，有幾個人能明白呢？

@不要出來搞笑

不要出來搞笑，謝謝。

@wolfsquare
這的確是個問題，不過如果是在招人的時候，還是盡量不要讓人家做太多GUI相關的demo，這樣的demo，也不容易評價水平的高低。

如果是一個GUI為主的demo，那也只能靠人工判斷了。

開源就開源，別老是拉著大旗出來跳舞。

要是代碼難看，舞姿也難看，就傷人的眼睛了。

to:Rami

我前面是這么寫的：
－要有創意
－在功能創意與時間進度之間，自行平衡

to:mis98zb
基本素質、價值觀念、發展意向、職業規劃

是重要，但是這不是我招人的考察依據，而是招進來以后，如何管理的參考因素。

而且這些要緊的東西，往往很難在1個小時的面試時間里了解，只能在實際的項目協作中，才能看出來。

to:dfinger
我招過人

to:killvin
1、什么叫實在不妥？
沒有完美的代碼，但是有沒有bug的代碼。如果你沒有見過這樣的代碼，只能說明你的見識不夠。

2、我給他時間，在這段時間內，我也可以學那些新技術呀。大家都是零起點，我如果比他慢，還有什么資格招他進來呢？

再者說，技術有新舊，對于代碼質量的要求，是很穩定的。

3、每件事情，都可以總結，甚至是你在學校里學的一門C++的大作業，做得如何，如何能夠做得更好，這樣的總結，一樣是經驗。Coding的能力，在學校里也是可以提高的。

4、是不是片面判斷這一點上，我認為這樣的選擇方式，才是最客觀的。

to:隨我突突突
3*2=6
這是一個例子

to:Water Ye
這種招人方式，主要是相對于筆試、面試的招聘方式。
成本似乎比較高，但是回報也的確是很不錯。

to:dowei,tony_chow,工具并不重要，

謝謝三位的意見，我現在是一個普通的項目組里的程序員，埋頭寫好自己的code，不問其它。

無論管理、文檔還是過程，都不再是我的考慮范圍。

明天，我們會再次開會，重新商量進度計劃，因為，好多需求都已經變了。當然，我就安心做一個旁觀者吧~~~

to:與笑凌
我看了你的blog，回頭我會寫一篇blog，再聊聊找工作這個話題。
另外，我現在所在的公司，我并不負責招人~~~

to:mis98zb
我招人，可不是想要招苦力。比如公司讓我招兩個3K的程序員，我發現有一個小伙非常棒，我會建議公司，就招一個人，然后給他6K。因為我相信，一個6k的程序員的工作效率，往往會超過兩個3K的程序員。

to:Edward
別人會不會做，是人家的決定，我想你肯定是不會做的，這樣最好！

很簡單，不愿意做一個demo的，肯定就不是我想招的，這樣也能淘汰不少了。

to:不曾真實
謝謝你的回復和勸誡。

1、談判的前提是，談判雙方處在一個能夠對談的地位上，現在的問題是，我們的老板幾乎不接受任何建議和意見。當然，我也應該嘗試更加有策略的言談方式，不過，希望不大。

2、辭職不是我的選擇，因為這個項目我不是負責人，也可以說，這個項目，由于混亂，目前還沒有一個負責人。“寧愿辭職也不愿成為導致自己的軍隊失敗的工具”，這句話的前提是，這個軍隊是自己的，目前的情況是，沒有人覺得這個項目是自己的。

3、所以，以我的經驗，這個項目一定會延期，一方面是因為進度要求本來就非常的離譜，另一方面，現有的管理并未理順各種混亂，而是在制造更多的混亂。所以，我在其中，更多的是一種“盡我所能，不為所累”的態度，如此而已。

4、這的確是一個考驗智慧的挑戰，我想，這個機會從更加正面的意義而言，是很難得的。

to:scud

沒辦法呀，我去的時候，已經一團亂麻的，現在也沒見好轉～～～

to:寒晴天
法西斯？我們大老板就是典型的“獨裁式管理”，而亂源也就出在這里。
你們那個Leader真不錯，是條漢子！

to:黃金時代已過
謝謝你的建議，非常的中肯，保持強悍的心靈和認真負責的態度來開發程序，等待項目延期。
這就是我目前的基本心態了。

to:非魚
你怎么把我的話里的XP，都改成UP了？惡搞吧:)

to:匿名
"既然樓豬是這么厲害的人物，為什么你的團隊也這么糟糕呢？"

這不是我的團隊，這正是無奈之處啊。
另外，我非常不喜歡你回帖里的那種罵人的小花招！
一個只敢匿名的家伙，我就不來跟你計較了！

to:netfishx
我的確是羨慕啊

to:renyfox
UP是一種過程管理工具，而XP不是～～～
這是我要提請GHawk注意的地方，當然也提請你注意這一點。

to:nake
放心，我工作還是不會耽誤的

to:wolfsquare
謝謝你的支持

to:mixlee
我們倆說的是不相干的兩件事

你這個比方，簡直就是......

湯的味道，不需要什么過程控制，如果他味道不對，那是因為做湯的人，寫的測試用例不夠穩定。

如果能夠使用代碼化的測試用例，而不是僅僅依靠自己的舌頭，或者盲目的遵循所謂的菜譜文檔。

這樣才能確保每一次做出來的湯，都是一種味道。

老兄，聽說過TDD嗎？XP運用TDD，以保證代碼質量，而不是用量杯，也不是寫菜譜。

再說一句，XP不僅僅是一種軟件開發過程，而是一種思想，如果你有機會，聽聽最近一次BEA上海User Group中的Charls的演講錄音就好了。

to:jelly-ll

http://forum.javaeye.com/viewtopic.php?t=20063

正好可以推薦你看看這篇帖子

to:charon@xxx

不是因為他是在校教師，所以我看不起他。而是因為他的話，我認為不正確，所以一開始將其歸結為在校教師的“和稀泥”。以我的經驗，大多數學校教師，教別人軟件開發的老師，對于當前軟件開發中的很多實踐，并無深入的認識。

UP是正楷、XP是草書，這種話，毫無意義。因為UP是一種過程管理模式，而XP其實質是一種開發思想。豈可同日而語？

后來WANG又提出所謂的海龜背景，豈不是更加無稽？

to:mixlee
如果一家公司，要做一個以前沒有做過的項目，要涉及以沒有進入過的領域呢？

to:jelly--
注意看我的話

沒有代碼閱讀能力的Leader，不一定管不好項目，而如果他“舍本逐末，認為文檔質量才是項目質量的體現。進而變態地追求文檔完美，以至于浪費了程序員寫代碼的時間。”這樣才會管不好項目。

to：WANG

他在美國打拼怎么了？還有好多土生土長的美國人，也不鳥那什么UP呢？

我為什么要聽一個海龜來上課呢？
這年頭，海龜還不夠多嗎？

現在可以下載了，就是原來的地址。

是有這個問題，現在這個文件只要2M多。應該是9M多，等我重新做好以后，麻煩你再下一次吧。

你在我這個文章下面，問我推薦哪個學校，豈不是錯得離譜？

我的本意，就是建議通過網絡學習軟件開發呀！

說實話，這種學校，我一個都不看好～～～要學東西，就自學吧，至少不會被騙錢。

應該能下載的吧，要不你再試試？

呵呵，謝謝大家

嘿嘿，已經改正了:)

http://groups.google.com/group/dev4server

N的內容，原本是打算書寫完之后，填上去的。

后來發現，得另外重寫，這本書的結構都要作廢了。我又舍不得丟掉，干脆就open出來給大家看看了。

真是好介紹啊，謝謝了～！

我見過這樣的設施，不過不常見。一般是在高速公路的出入口上。

城市普通的道路，這樣的隨意變動，很容易導致司機開錯道的。

林德彰的說法，是一個在校教師，典型的和稀泥的說法，我不同意。

真想和你們一起工作啊
簡直就是肆意的編著自己喜歡的程序。

爽！

嗯，ICE你說的有道理。

原來的JDON，高高的聳立著，現在的JDON，果然是已經矮下去了。

必須承認，我沒有學過smalltalk，所以我對于OO的全部認識，的確都是來自于靜態類型的OO語言。

所以，將我的文章，改為《敲響靜態類型OO時代的喪鐘》，應該是更為恰當的。

剛才跟徐X在MSN上聊，他已經基本上答應寫一個《YAST - Yet Another Smalltalk Tutorial》了。大家都有福了！

哈哈！

to:weide
你這個JavaRSS，本來應該很好的，但是數據更新太慢了。
我搜索關鍵詞“AJAX”，竟然只能搜到34條記錄，而最新的內容，是2005年8月15日。

你讓人家如何喜歡你的網站呀？

對于JDON，我早有評價：“星宿派”，這樣的門派是“不屑與其它山頭并列”的。

又想拍手叫好，又想撇清干系。

嘿嘿。。。

UML三友這樣的偽大師，直接罵就是，何必客氣。

突然想到一個場景：

鹿鼎記里的江湖群豪，前明志士們聚在一起開的那個“殺龜大會”。

再客氣一點說一句，算是幫你們公司的高手說說好話。

當初他們一手一腳的搞AJAX系統，一切都是從頭做起，批評他們過多，也是太刻薄了。

但是現在時間過去了那么多年，好多“好輪子”都出來。比如Dojo，比如Propotype，比如...如果再從頭做起，就太傻了。

在前人犧牲奉獻的基礎上來開發AJAX，其實失敗的可能性，沒有你想像的那么大。

http://michael.nona.name/archives/11

如果你說RIA與Bindows有競爭關系，我就完全同意。

我的感覺是，Web1.0和AJAX不是競爭關系，AJAX和Flash-Based RIA不是競爭關系，RIA和C/S不是競爭關系。

在兵器譜上，他們應該一字排開，分別滿足不同的應用與交互需求的。

目前還沒有和出版社簽合同呢，時間上還定不下來。

如果你的項目只能用IE訪問，那能算是遵循標準？

系統的bug滿天飛，你覺得是正常的？
“系統功能復雜必然會有大量的Bug”，OK，就算會產生大量的bug，這些bug的存活期是多長？如果老bug改不完，新bug又出來，改了老bug，反而引出新bug。那我就認為：水平不到家。

不但是技術水平不到家，而且項目管理的水平都不到家。

不管技術發展到那個時代（不要以Struts還沒有出現作借口），有效的、清晰的分隔不同的功能與模塊，是系統設計的第一原則，MVC模式，在C/S時代就應該已經廣為人知了。無論你基于什么技術來進行設計，無法有效的隔離變化，就是設計水平不夠！

設計水平不夠，也不要把帳賴到AJAX這樣的新技術頭上。

“他們開發、完善了這么些年，至今還不能盡善盡美，這說明什么問題？”

說明他們不過是早早的采用了XMLHTTP技術而已。
用了5、6年AJAX開發的“高手”，卻至今都沒有總結出好的“模式”、“經驗”以及“成熟的AJAX開發手段”。

最近比較流行的幾本AJAX的書，推薦他們去買來看：
Ajax Patterns Best Practices：
http://www.ajaxmatters.com/r/go?id=328

Ajax Design Patterns：
http://www.ajaxmatters.com/r/go?id=305

Professional AJAX：
http://www.ajaxmatters.com/r/go?id=196

為啥又要算到國人頭上？還扣一個“拉幫結派”的大帽子？

這Web標準化組織，又不是中國人先搞出來的。再說了，這敏捷聯盟，W3C，JCP.....難道就不是組織了？

中國的IT界，我看不是組織太多，而是太少了。

如果：

“效果是實現了，程序開發和測試、維護的效率則是大大的下降了。開發就不說了，前期投入巨大，系統復雜性劇增，程序也只能用IE訪問。測試的時候這邊 AJAX的javascript的bug滿天飛，那邊調試這種錯誤極不方便，沒有好的JS的調試器，更看不到實際輸出的html代碼。維護那就糟糕，加個新功能，JSP文件、標簽、JS、后臺類全要過一遍?！?

那么他對AJAX的應用，就算不上登峰造極。只能算是對于IE下的XMLHTTP＆CSS的濫用。
1、不遵循WEB標準的，算不得AJAX
2、bug滿天飛，那就說明是水平不到家
3、加個新功能，JSP文件、標簽、JS、后臺類全要過一遍。就說明系統設計有先天的缺陷

“筆者前一段一直在參與一個國外知名大公司的一個產品的開發”
這大概可以說明，這個國外知名大公司里，沒有一個數得上的AJAX高手。

呵呵，我只是舉個例子。

要是都把各類資源列在這里，那要算是直接給人家魚，而不是給人家網了。