我的評論
re: Ruby真有那么好嗎? iceboundrock 2006-12-11 18:29
暈,就這個論據啊,太不堪一擊了。
就算想并發提高處理能力,也不一定多線程吧,多進程也可以嘛。用一個apache/lighttpd+n個webrick不就可以了。
就算想并發提高處理能力,也不一定多線程吧,多進程也可以嘛。用一個apache/lighttpd+n個webrick不就可以了。
re: Java World,為什么你們的國際化實現那么差? iceboundrock 2006-12-07 09:44
Eclipse 3默認是alt+/啊,VS系列才是Ctrl+Space
re: 如何對付令人郁悶的客戶 之 如何處理客戶提出的需求變更 iceboundrock 2006-12-06 17:39
@冷面閻羅
沒錯的,項目經理與客戶溝通是門藝術。
與客戶經常溝通的效果往往勝過合同條款(如果到了非得拿出合同說事的程度,項目基本上就完蛋了)。總之,客戶的目標就是盡量少花錢多辦事。而開發方的目標就是能不改就不改(降低成本啊),即使非得要改,也要說的讓客戶覺得欠了你很大一個人情似的(為下一次他們再提出需求變更做好準備)。中間具體怎么溝通達到雙贏,就看個人的本事了。
沒錯的,項目經理與客戶溝通是門藝術。
與客戶經常溝通的效果往往勝過合同條款(如果到了非得拿出合同說事的程度,項目基本上就完蛋了)。總之,客戶的目標就是盡量少花錢多辦事。而開發方的目標就是能不改就不改(降低成本啊),即使非得要改,也要說的讓客戶覺得欠了你很大一個人情似的(為下一次他們再提出需求變更做好準備)。中間具體怎么溝通達到雙贏,就看個人的本事了。
re: 如何對付令人郁悶的客戶 之 如何處理客戶提出的需求變更 iceboundrock 2006-12-06 15:16
@心內求法
從理論上,這樣是很完美的。但是很難堅持下去,因為一般來說國內的軟件項目,客戶和開發方根本就不平等。所以只有開發方多做一些工作了,經常與客戶溝通,擺事實講道理,呵呵。
從理論上,這樣是很完美的。但是很難堅持下去,因為一般來說國內的軟件項目,客戶和開發方根本就不平等。所以只有開發方多做一些工作了,經常與客戶溝通,擺事實講道理,呵呵。
re: 如何對付令人郁悶的客戶 之 如何處理客戶提出的需求變更 iceboundrock 2006-12-06 11:42
@冷面閻羅
如果客戶提的需求你覺得有問題,你最好把你的想法整理清楚之后去和項目經理談,讓他去說服用戶,或者向更高層的領導匯報。把利害關系分析清楚,我想沒有那個公司想賠錢的。是吧。
但是,如果你一邊覺得有問題,一邊又不說話只是埋頭苦干,那只有啞巴吃黃蓮了。程序員除了技術,溝通也是非常重要的,尤其到了項目后期,溝通的重要性遠遠高于技術。
如果客戶提的需求你覺得有問題,你最好把你的想法整理清楚之后去和項目經理談,讓他去說服用戶,或者向更高層的領導匯報。把利害關系分析清楚,我想沒有那個公司想賠錢的。是吧。
但是,如果你一邊覺得有問題,一邊又不說話只是埋頭苦干,那只有啞巴吃黃蓮了。程序員除了技術,溝通也是非常重要的,尤其到了項目后期,溝通的重要性遠遠高于技術。
re: 如何對付令人郁悶的客戶 之 如何處理客戶提出的需求變更 iceboundrock 2006-12-05 21:44
@冷面閻羅
遇到這樣的,就要給他變更造成阻力,不能讓他隨意變更。
如果客戶給項目造成很多困擾,而項目項目經理搞不定,可以向業務人員反饋。一般來說,業務與客戶的私人關系肯定好過項目經理和客戶的私人關系。他們有他們的渠道來和客戶溝通。
如果業務不管,可以繼續向高層反饋,畢竟項目拖久了,公司也是受害者。
遇到這樣的,就要給他變更造成阻力,不能讓他隨意變更。
如果客戶給項目造成很多困擾,而項目項目經理搞不定,可以向業務人員反饋。一般來說,業務與客戶的私人關系肯定好過項目經理和客戶的私人關系。他們有他們的渠道來和客戶溝通。
如果業務不管,可以繼續向高層反饋,畢竟項目拖久了,公司也是受害者。
re: C++對象的構造、賦值和析構 iceboundrock 2006-11-28 09:50
補充一點關于數組的內容,
如果在C++中聲明一個對象的數組,不像C#,數組中默認的元素都是null,C++的數組中可以容納多少元素就會在聲明數組的時候執行多少次構造函數將實際函數構造出來。
如果在C++中聲明一個對象的數組,不像C#,數組中默認的元素都是null,C++的數組中可以容納多少元素就會在聲明數組的時候執行多少次構造函數將實際函數構造出來。
re: 通過分區(Partition)提升MySQL性能[原創翻譯] iceboundrock 2006-05-07 17:58
如果所有分區都是在同一塊硬盤上面,性能還會有提高么?是否有評測?謝謝。
re: 玩玩Spring之Rod Johnson 與“輪子理論” iceboundrock 2006-05-07 17:05
改進和克隆還是有區別的。我覺得重新發明輪子是一個成本的問題,比如以前我國的兩彈一星,別人是不會輕易share給我們的,不重新發明我們就沒法立足。但是像Spring這樣open source的東東,除非它無法滿足需要,否則重新發明它除了鍛煉自己的技術,實在沒啥價值。當然如果你有足夠的資源做一個全新的東西完全符合你的需要,就沒有問題。
我的觀點是首先要繼承、學習,接著才是創新、改進。
我的觀點是首先要繼承、學習,接著才是創新、改進。
re: [原創]eclipse 3.1.x漢化過程 iceboundrock 2006-05-05 14:16
不錯,不過blog的字體太大了,看起來比較痛苦。
re: 看到MSDN Universal(MSDN宇宙版),想Java Universal 應該長什么樣子? iceboundrock 2006-04-29 12:32
我這幾天用了一下Eclipse+WTP1.01的那個All in One版本,感覺很爽,應該加進去。MSDN最重要的部分不是這些軟件,而是那些技術文檔,可惜Java在文檔這塊一直追不上MSDN啊。咱們先把一些Sun官方的電子文檔加進來把,另外就是Log4j/Ant/Dom4j/Spring/Hibernate等這些東東的文檔。還有Apache里面的一個性能測試工具。大家看看還有啥不?
re: 一個事件的基類,目標為改進j2sdk中的Observer iceboundrock 2006-04-27 14:28
謝謝您的指教,對于這三個方面,我是這么考慮的:
1,j2sdk中的Observer/Observable難道就不類型安全?
沒錯啊,因為接口設計的太粗,所以無法保證回調時一定傳入監聽器需要的類型。
2,多個事件函數的意義在于可以清晰的表明事件的含義,并且提高效率。監聽器不必自己處理所有的事件。
3,TestEvents實現ITestEventHandler的確不夠優雅,不過這是為了程序編寫上的方便。另外因為TestEvents可以實現很多接口,所以把事件處理類型傳遞進去,可以減少一部分工作。您覺得這塊需要如何改進呢?
這個類的目標是改進Observer,我也的確認為對Observer做出了一些改善,所以我保留標題。
1,j2sdk中的Observer/Observable難道就不類型安全?
沒錯啊,因為接口設計的太粗,所以無法保證回調時一定傳入監聽器需要的類型。
2,多個事件函數的意義在于可以清晰的表明事件的含義,并且提高效率。監聽器不必自己處理所有的事件。
3,TestEvents實現ITestEventHandler的確不夠優雅,不過這是為了程序編寫上的方便。另外因為TestEvents可以實現很多接口,所以把事件處理類型傳遞進去,可以減少一部分工作。您覺得這塊需要如何改進呢?
這個類的目標是改進Observer,我也的確認為對Observer做出了一些改善,所以我保留標題。