隨筆-72  評論-20  文章-0  trackbacks-1
            2008年1月15日
             工作五年,一晃已年過三十了。讀研時,獨立做項目,畢業(yè)頭三年,主要在大公司工作,后來,也就是08年,半創(chuàng)業(yè)。具體點,合伙人吧,自己負(fù)責(zé)IT部門,到現(xiàn)在6人,公司總共20來人,旅游業(yè)。這兩年嚴(yán)酷的創(chuàng)業(yè)經(jīng)歷,讓我越發(fā)覺得管理(做事),以及領(lǐng)導(dǎo)(帶人、待人,不是管人)的重要性。因為,隨著組織的擴(kuò)大,混亂度無形中就會增大,管理和領(lǐng)導(dǎo),就是讓這種混亂重歸有序,重歸單人作戰(zhàn)那種意圖和行動的高度統(tǒng)一。

              說得功利點吧,一個人的財富和其影響力是成正比的。影響力本質(zhì)上就是對他人的價值。比如,郎_xian_評的出場費一天超過15萬。作為技術(shù)人員,如果我們只能影響周邊幾個人,那么我們憑什么拿那么高的報酬,除非我們做的事情影響了很多人,比如楊勃的豆瓣網(wǎng)。所以,我還是覺得,技術(shù)人員往高處發(fā)展,逐漸應(yīng)該有管理意識、培養(yǎng)自己的管理能力。技術(shù)從書本上可以學(xué)到很多,管理還真得實踐,書上看到的,你覺得很弱智的問題,比如盲目擴(kuò)張,自己親身經(jīng)歷時,一樣會犯,也許是行為習(xí)慣在起作用,看書不足以改變行為。

              回到正題上。
              也許是自己曾經(jīng)在較大公司或團(tuán)隊的做事習(xí)慣和視野,剛創(chuàng)業(yè)時,用在這種小團(tuán)隊的商業(yè)項目開發(fā)上,幾乎慘敗。
              先說項目開發(fā)這塊吧。
              大家知道,項目管理和過程管理是兩碼事,前者關(guān)注目標(biāo)和進(jìn)度,成本和收益;后者關(guān)注做事流程、方法。
              項目管理,體會最深的,就是目標(biāo)和任務(wù)分解、進(jìn)度控制,以及溝通。

              項目管理軟件
              從大公司出來的人,我想最喜歡玩的,就是借助于項目管理軟件(核心是甘特圖)。市面上的大多數(shù)知名的項目管理軟件,無論是桌面版還是網(wǎng)頁版的,我都試過。當(dāng)然最后也選擇了一款:ConceptDraw Project,用了一年多,也多少有些用。但最后還是發(fā)現(xiàn),它其實對項目進(jìn)度和質(zhì)量關(guān)系并不大。也許,一個Excel表格更實用。
               項目管理軟件,本質(zhì)上是解決一種溝通和職責(zé)分配的問題。比如,一個項目,折疊成一個三層樹形結(jié)構(gòu),老板只關(guān)心第一層,也就是整體進(jìn)度;中間是項目經(jīng)理關(guān)注的功能層,最后一層,也就是具體的任務(wù),是開發(fā)人員關(guān)注的。想想,如果沒有這玩意,你怎么告訴其它項目干系人進(jìn)度?但又引出幾個問題:
              靠文檔來溝通,還是靠信任? 太在乎文檔,往往導(dǎo)致每天去關(guān)注文檔如何漂亮、有說服力,并為此花大量時間,而不是項目如何漂亮。另外,是否有文檔就可以防止扯皮、兌現(xiàn)承諾?我們是關(guān)于項目目標(biāo),還是關(guān)注彼此的博弈?

              進(jìn)度偏差 創(chuàng)業(yè)型項目,往往都是以前沒有接觸過,其進(jìn)度評估往往有很大誤差,比如業(yè)務(wù)需求的挖掘和變化,技術(shù)難點,開發(fā)人員素質(zhì)。我們是關(guān)注進(jìn)度,還是關(guān)注項目本身的質(zhì)量?兩者都要,但如何兼顧?雖然有方法學(xué),比如砍掉優(yōu)先級低的,但你怎么讓老板相信某個核心功能就得四天時間。
              在我們的進(jìn)度設(shè)計不合理情況下,是否開發(fā)人員完成甘特圖(WBS)下的任務(wù)就ok?遠(yuǎn)遠(yuǎn)不夠,任務(wù)分得太細(xì),往往限制了開發(fā)人員的創(chuàng)造性和自我評估能力,如果提前兩天完成呢?
              我們現(xiàn)在是以項目管理軟件為輔,任務(wù)的下達(dá)主要以郵件傳達(dá),每周一上午的周例會會白板宣布。我發(fā)現(xiàn)白板比投影儀PPT好用。

             關(guān)于規(guī)范
             這也是大公司特別喜歡玩的。
             也許我們前期會制定一個的架構(gòu)、設(shè)計文檔,代碼規(guī)范,這有一個規(guī)范建立的時間成本以及規(guī)范本書的合理性,再說如果一個開發(fā)人員,特別是高手,如果不認(rèn)同你的設(shè)計和規(guī)范,你要強(qiáng)推,他要么走人要么怠工。規(guī)范的本質(zhì)是為了協(xié)作和后期可維護(hù),如果只有兩個人或一個人寫某個模塊,你覺得有這個必要嗎?規(guī)范整潔的代碼,在項目初期,對用戶的價值關(guān)系很小,你會關(guān)心豆瓣網(wǎng)的js代碼寫得很漂亮嗎?我們應(yīng)該關(guān)注代碼的健壯性而不是可維護(hù)性,我們不是在開發(fā)Windows。

              人適應(yīng)項目,還是項目適應(yīng)人
              大公司,往往是來了一個項目,趕快招人,人來適應(yīng)項目。小公司呢,我現(xiàn)在的看法是,項目適應(yīng)人。小公司,往往一個項目做砸,公司就面臨解散。所以,我認(rèn)為,最好還是按照開發(fā)人員的擅長,保證功能質(zhì)量,最快的速度上線。另外,為了達(dá)成進(jìn)度,可以在上線初期砍掉不太重要的欄目或功能。
              我在這個上面栽過跟頭的。比如開發(fā)人員的擅長,如果他擅長jsp開發(fā)模式,而不是Hibernate+Spring的分層開發(fā),就讓他按自己的意思做吧。因為,創(chuàng)業(yè)型項目都不會太大;即使技術(shù)實現(xiàn)你感覺完美了,用戶可能感覺不爽;再說,項目開發(fā),涉及到業(yè)務(wù)調(diào)研、需求分析、原型界面、架構(gòu)、開發(fā)、部署、推廣。開發(fā),也就是代碼實現(xiàn),占去項目時間,也許不到30%。項目如果證實有商業(yè)前景,代碼重新實現(xiàn)一遍,花不了多少時間。
              但我也深深地意識到我們項目管理的級別,就如同CMM1到CMM4。但我還是覺得目前是最好的選擇。
              如果最低層次的用戶需求目標(biāo)都達(dá)不到,直接考慮代碼怎么有可擴(kuò)展性、可維護(hù)性,對于小公司就是找死。
              另外,尊重和信任、支持開發(fā)人員的技術(shù)選擇,往往是一種激勵、增強(qiáng)團(tuán)隊凝聚力的方式。萬眾一心,比什么目標(biāo)、進(jìn)度更有效、實際。
              我們應(yīng)該培養(yǎng)一種團(tuán)隊成員的內(nèi)部創(chuàng)業(yè)心態(tài),而不只是敬業(yè)。

              在進(jìn)度把控上,我現(xiàn)在更傾向于強(qiáng)調(diào)我們的項目目標(biāo)和緊迫性,而不是他們的任務(wù)。因為我希望大家的關(guān)注點是項目,而不是他的上級,他應(yīng)該對項目負(fù)責(zé),而不只是對上級負(fù)責(zé)。

              說說溝通
              項目管理中最難處理好的,就是溝通。以前,我比較關(guān)注于工具,如郵件、文檔、ppt講稿會議,逐漸我關(guān)注效率和效能,特別是態(tài)度。溝通最基礎(chǔ)的就是態(tài)度。如果網(wǎng)站上線后,訂單提交出現(xiàn)一個核心bug,你是直接找開發(fā)人員問責(zé);還是告訴他哪兒出了問題,這個問題的嚴(yán)重,并且自己反省,比如測試流程出了問題。出現(xiàn)這種事情,也許需要負(fù)責(zé)人舉重若輕的氣度。但更深層次的,如果負(fù)責(zé)人能夠培養(yǎng)其員工質(zhì)量意識,危機(jī)意識,才是治本。因為一個有強(qiáng)烈質(zhì)量意識的團(tuán)隊,他自然會去對代碼健壯性、功能易用性精益求精,自然會去配合測試流程。
             剛才那個溝通問題,對開發(fā)人員的態(tài)度,前者是負(fù)面,后者是中立。那么前者,開發(fā)人員的反應(yīng)是如何不讓領(lǐng)導(dǎo)下次責(zé)怪自己,比如只做領(lǐng)導(dǎo)安排的事情;后者的反應(yīng)是怎么去改進(jìn),不讓這樣的事情發(fā)生。
             如果你認(rèn)可創(chuàng)新就可能出錯,如果你認(rèn)可開發(fā)人員都是想做好的。那么所有的事情,朝正向發(fā)展邁出了最決定性的第一步。

             溝通:命令式還是征詢式
             在溝通,特別是下達(dá)任務(wù)或做決策這類事情上。應(yīng)該說中國絕大多少管理者都是用命令式。我過去經(jīng)常在用,但一直在試圖改正,改用建議式和征詢式。管理者最需要、最難開口的一句話是:Do you think so?命令的方式,經(jīng)常出現(xiàn)下級不能理解上級的意圖,嚴(yán)重的出現(xiàn)抵觸。每個人,其實都喜歡別人按自己的想法做事,但你怎么知道自己的想法或決策是對或不是偏頗的,怎么讓團(tuán)隊愿意去執(zhí)行?去征詢團(tuán)隊其他成員的意見,讓他們參與,往往能夠培養(yǎng)其主人翁意識、責(zé)任感、向心力,還能夠完善自己的想法。但要將員工參與意識,轉(zhuǎn)化為一種習(xí)慣,太難。
              當(dāng)大家都沒有主見時,需要領(lǐng)導(dǎo)者的果斷、魄力和強(qiáng)勢,但這種機(jī)會并不多,而且這種情況,需要團(tuán)隊成員對領(lǐng)導(dǎo)者的信任。
             
              遵守制度,還是建立信任
               在大公司,往往是告訴你怎么去遵守公司制度。在小公司,我認(rèn)為最基礎(chǔ)、最核心的一件事,就是建立信任,讓團(tuán)隊信任你的人品(說到做到),信任你的能力(能夠把大家?guī)У揭粋€新的高度)。建立了信任后,下一步的核心工作,怎么將你的個人目標(biāo),也就是團(tuán)隊目標(biāo),轉(zhuǎn)化為每個成員的個人目標(biāo)。
              有了信任這個基礎(chǔ),才會有了團(tuán)隊建設(shè)的第二個核心:激勵。
              是激勵,而不是約束、監(jiān)督,讓團(tuán)隊有戰(zhàn)斗力。但大公司往往喜歡后者。也許,大公司都是職業(yè)經(jīng)理人,反正是打工,太關(guān)注于事。如果說有個所謂的中國式領(lǐng)導(dǎo),我覺得就是以人為本,對人的尊重。人的關(guān)系處理好了,事情就好做。
              加班、考勤、上網(wǎng)監(jiān)控,這類對信任、激勵極具破壞力的行為,也許是工業(yè)型社會對我們這個思考性創(chuàng)造性行業(yè)的侵蝕。知識型勞動者,需要一種與體力型勞動者完全不同的管理模式,這種模式也許需要一個從萌芽、生長到成熟期。現(xiàn)在在目前的中國,還只是剛走出萌芽期。
             
              以前完整看過余世維的11套視頻,還看過幾遍。他那種人本理念我還是很認(rèn)同,只是,他在大公司、規(guī)范公司的做事情方法和風(fēng)格,完全照搬拿到小公司,非常危險。你能夠拿幼兒園那種教育方法來教育成年人嗎?小公司不具備大公司那種職業(yè)化的環(huán)境,也不具備大公司在行業(yè)中的市場地位及資金實力。
              如果說大公司講究做事方法、流程,如SWOT分析法、BCG矩陣,小公司更看重靈活性、市場適應(yīng)性。小公司應(yīng)該適當(dāng)短視、急功近利,否則在你實施一個三年計劃時,第二年還不賺錢可能就撐不下去。
              所以我覺得,在跨國大企業(yè)呆慣了,出來創(chuàng)業(yè)很危險。一個是做事方法不適應(yīng),另外一個就是沒有平臺。如果要出來創(chuàng)業(yè),以前那種大企業(yè)的經(jīng)歷可能更是一種劣勢。 也許有一種情況,你是大公司的高官,拿到一筆很大的風(fēng)險投資,然后出來創(chuàng)業(yè)。
              
              人事招聘
               薪水  如果公司給得起,并且應(yīng)聘者能力差不多。 就不要太在乎那200、300。雖然說至少要不低于行業(yè)平均值(IT人員是IT行業(yè)平均值,而不是本公司所在的行業(yè)平均值),但最重要的,還是不要低于當(dāng)事人的期望值,因為最核心的是滿意度,而滿意度決定于期望值和實際值的差距。對于小公司,往往一個人技術(shù)人員的成本和收益,和其工資差距非常大,有可能10倍。所以,我們的關(guān)注點,應(yīng)該是怎么一開始留住這位人才。然后,怎么讓其充分發(fā)揮潛力。小公司往往不是因為節(jié)省那幾千幾萬的工資成本死掉的,而是充分利用這位人才才活下去了。

               另外,不要以為有多少人才選擇的機(jī)會,小公司往往不受高級人才的青睞。太高級的人才,可能養(yǎng)不起,而且往往太有個性,很難合作愉快,除非在來公司前有很長時間的了解。
               招聘到合適人才后,應(yīng)該讓其忘掉薪水,專注于工作,尋找工作本身的樂趣。當(dāng)然,要做到讓其在薪水上有優(yōu)越感,也許是項目很盈利的那一天,開始時很難。

               人才標(biāo)準(zhǔn) 如果其能力和你預(yù)期相差不大的話,更應(yīng)該考慮其態(tài)度、做事風(fēng)格,甚至是價值觀。因為其能力的發(fā)揮,和這個環(huán)境,特別是他的直接利益相關(guān)者,也就是上司,關(guān)系太大。如果配合得好,一個人可以頂三個。否則,那種內(nèi)耗導(dǎo)致的進(jìn)度延期,由此引起的市場機(jī)會喪失,公司財力無法支撐,往往是致命的。因為一個幾人的IT團(tuán)隊,每一個人的職責(zé)就如同那木桶的一塊板,缺了那塊都存不了水。
               比如關(guān)于質(zhì)量,更確切說是內(nèi)容質(zhì)量,我們目前做旅游電子商務(wù),我認(rèn)為內(nèi)容質(zhì)量很核心。但你招進(jìn)來的同事,始終認(rèn)為先要量,什么都可以抄,而我強(qiáng)調(diào)質(zhì),原創(chuàng)、半原創(chuàng),可以少而精,而不能多而亂。除開項目進(jìn)度,怎么去溝通?最好兩個人一開始都認(rèn)同原創(chuàng)的力量。

               提升一個人的技能不難,但改變一個人的態(tài)度比較難,改變一個人的價值觀幾乎不現(xiàn)實。所以先找志同道合的人吧。    
               別期望人才是可替代的。我們不是大公司,我們?nèi)绷苏l,那一塊就不轉(zhuǎn)。
               大家都知道,松耦合要付出代價,比如SOAP協(xié)議的低性能,AMF私有協(xié)議的高性能。創(chuàng)業(yè)期,不要太多考慮人才替換,而是關(guān)注怎么發(fā)揮人的潛力,留住人,盡快高質(zhì)量完成項目。人才替換的一個假設(shè),可能是你對自己管理的不自信,因為你不相信自己能夠留住人。
              
               這次就寫這么多吧。
               我似乎有這種體會,考大學(xué)、四六級這類資格、證書類考試最好混,因為只要勤奮就可以,再加點方法就可以出類拔萃了。  上班也比較好混,說找工作吧,像我搞技術(shù)的,本身對技術(shù)很狂熱,根本就不愁找不到工作,因為面試時我覺得那家伙應(yīng)該比我牛,正好可以切磋切磋,沒想太多所以沒啥怯場或不自信。工作吧,如果是技術(shù)類,特別是商業(yè)軟件,技術(shù)難度都不大,按上司意思來,很容易搞定。創(chuàng)業(yè)呢,自己要做商業(yè)判斷、業(yè)務(wù)決策,還要協(xié)調(diào)若干人的工作(協(xié)調(diào)的本質(zhì)是協(xié)調(diào)利益)。做事和管事,完全是兩碼事,有些難。不過,創(chuàng)業(yè)還是很有意思,因為你可以按自己的意愿去工作去生活,當(dāng)然也是受限環(huán)境的自由。


          我將我的一個回復(fù)放在這個地方,特示警醒:
          告誡各位處于開發(fā)第一線的朋友,千萬不要受本文的誤導(dǎo),把規(guī)范和設(shè)計文檔不當(dāng)回事。

          我的看法:
          1、文檔的多少和深度決定于項目環(huán)境。
              如果是大項目,比如二三十開發(fā)人員,架構(gòu)文檔、需求文檔、代碼規(guī)范等都是必須,否則開發(fā)人員不能迅速了解項目技術(shù)和業(yè)務(wù)特點,從而無法快速開發(fā),也即是規(guī)范可以降低培訓(xùn)成本和團(tuán)隊溝通;另外,項目開發(fā)中后期可能根本不可控,誰都看不懂其它人的代碼。部署時看到的一些bug無法及時修復(fù),因為到處都有地雷。我以前經(jīng)歷過這樣的項目,最后加班都沒用。

              如果是產(chǎn)品型,規(guī)范更重要。當(dāng)然我說的產(chǎn)品可能是2.0版以后,因為這時候的產(chǎn)品基本得到了市場的認(rèn)可。而在初版時,代碼寫得爛都沒關(guān)系,因為你不不知道用戶會不會買單,也不知道能否按進(jìn)度開發(fā)完成。而在后續(xù)版本,如果沒有規(guī)范文檔,維護(hù)的成本都不亞于重新開發(fā)。特別是處于一線的開發(fā)人員會怨聲載道:為什么要我來收拾殘局?那么,這樣的士氣,開發(fā)效率怎么會高,項目質(zhì)量怎么會高?

          2、成熟型大公司那套做事流程,可能高手受不了,但可能是最優(yōu)的方案。因為,到項目后期維護(hù),往往只是一些業(yè)務(wù)功能的刪減改進(jìn),不需要技術(shù)高手,這個過程可能漫漫幾年,項目維護(hù)成本會非常高,雇傭高手一來他不愿意干二來也不需要這種人,如果項目代碼還維持在一種“秩序”,初中級開發(fā)人員就可以勝任,有什么不好呢?
             項目上線時,是為了追求利潤。項目維護(hù)期,是為了省成本。

          3、剛?cè)氲赖呐笥眩詈檬前匆?guī)范來,就像學(xué)武術(shù),先要學(xué)套路。否則,養(yǎng)成的編程壞習(xí)慣,比如文件名叫Aaa1.java,代碼沒有縮進(jìn)。過幾年非常難改。而好的編程習(xí)慣,可以提升開發(fā)效率,還能讓自己思維清晰。
             學(xué)技術(shù)階段,一定要注意代碼的可維護(hù)性、健壯性及靈活性,只有養(yǎng)成對代碼精益求精的態(tài)度,你才可能成為技術(shù)高手。技術(shù)學(xué)好,做技術(shù)管理就有了基礎(chǔ),而且別人也會服你。

          原文地址:http://www.javaeye.com/topic/646406
          posted @ 2010-05-06 12:35 前方的路 閱讀(539) | 評論 (0)編輯 收藏
               摘要: 開發(fā)和架構(gòu)的界限難以捉摸。有些人告訴你它根本不存在,架構(gòu)只是開發(fā)者們所做的設(shè)計過程的簡單擴(kuò)展。 另外一些人認(rèn)為這是一個鴻溝,它只能由那些做到高度抽象,而且不會陷入實現(xiàn)細(xì)節(jié)的開發(fā)者才能跨越。通常,在這兩個極端的觀點中間某處有個可操作的平衡點;不論如何,怎么從開發(fā)轉(zhuǎn)換為架構(gòu)師都是個有趣的問題。

          經(jīng)常被用來區(qū)分軟件架構(gòu)和軟件設(shè)計開發(fā)的關(guān)鍵幾點包括 伸縮性和抽象程度的增加以及作出正確設(shè)計決策意義的增強(qiáng)。軟件架構(gòu)是通過一個全局的觀點,宏觀的視角來理解軟件系統(tǒng)作為一個整體如何工作。

          即使這能夠幫助區(qū)分軟件開發(fā)和架構(gòu),它并不能幫助理解某人如何從開發(fā)提升到架構(gòu)。 并且,它也不能幫助識別誰能夠成為一個好的軟件架構(gòu)師,如果你想雇人的話你如何去尋找他們以及你是否是一個軟件架構(gòu)師。
            閱讀全文
          posted @ 2010-04-19 16:50 前方的路 閱讀(294) | 評論 (0)編輯 收藏
               摘要: Flashback 技術(shù)是以Undo segment中的內(nèi)容為基礎(chǔ)的, 因此受限于UNDO_RETENTON參數(shù)。要使用flashback 的特性,必須啟用自動撤銷管理表空間。
          在Oracle 10g中, Flash back家族分為以下成員: Flashback Database, Flashback Drop,F(xiàn)lashback Query(分Flashback Query,Flashback Version Query, Flashback Transaction Query 三種) 和Flashback Table。  閱讀全文
          posted @ 2010-04-14 17:38 前方的路 閱讀(558) | 評論 (0)編輯 收藏
               摘要: 代碼檢查是白盒測試的一種靜態(tài)測試方法,是眾多軟件測試方法中發(fā)現(xiàn)軟件缺陷最有效的方法之一。本文結(jié)合國內(nèi)外學(xué)者在相關(guān)領(lǐng)域的研究情況,介紹代碼檢查相關(guān)的基本概念、過程和分析方法。  閱讀全文
          posted @ 2010-03-25 18:17 前方的路 閱讀(2466) | 評論 (1)編輯 收藏
               摘要: 為什么需要對參數(shù)進(jìn)行編碼?相信有過開發(fā)的經(jīng)驗的廣大程序員都知道,在Web中,若是直接在Url地址上傳遞參數(shù)值,若是中文,或者+等什么的就會出現(xiàn)亂碼現(xiàn)象,若是數(shù)字或者英文的好象沒有什么問題,簡言之,傳遞過來的參數(shù)是需要進(jìn)行編碼的。 在這里,也許有人會說,為什么不直接用Server.UrlDecode和Server.UrlEncode這兩個來進(jìn)行編碼和解碼的操作呢? 的確,這兩個服務(wù)器端對象很...  閱讀全文
          posted @ 2009-06-16 10:34 前方的路 閱讀(1076) | 評論 (0)編輯 收藏
               摘要: Spring Framework最得以出名的是與Hibernate的無縫鏈接,基本上用Spring,就會用Hibernate。可惜的是Spring提供的 HibernateTemplate功能顯得不夠,使用起來也不是很方便。我們編程序時,一般先寫B(tài)usinessService,由 BusinessService調(diào)DAO來執(zhí)行存儲,在這方面Spring沒有很好的例子,造成真正想用好它,并不容易。  閱讀全文
          posted @ 2008-08-14 15:15 前方的路 閱讀(262) | 評論 (0)編輯 收藏
               摘要: Spring Framework從誕生之日起,受到了越來越多的關(guān)注。最近,新的開源項目大多支持Spring Framework。國內(nèi)目前也有專門的網(wǎng)站(http://spring.jactiongroup.net/)。那它為什么如此受歡迎呢?

          我想最重要的是,EJB讓每個人都痛恨。要編寫一個EJB,需要寫LocalHome, RemoteHome, Bean, LocalInterface, RemoteInterface,需要一個標(biāo)準(zhǔn)描述符,一個特殊廠商描述符(Weblogic、WebSphere都不一樣),如果是Entity Bean,還需要Mapping文件。如此之多,實在麻煩。但EJB最重要的是解決Transaction問題,沒有Spring之前,沒有其他方法能夠描述式的解決它。每個人、每個公司為了解決Transaction的問題,編程的寫法都不一樣,百花齊放。于是,在最需要它的時候,Spring出現(xiàn)了。  閱讀全文
          posted @ 2008-08-14 15:13 前方的路 閱讀(299) | 評論 (0)編輯 收藏
               摘要: Spring Framework  【Java開源 J2EE框架】 Spring 是一個解決了許多在J2EE開發(fā)中常見的問題的強(qiáng)大框架。 Spring提供了管理業(yè)務(wù)對象的一致方法并且鼓勵了注入對接口編程而不是對類編程的良好習(xí)慣。Spring的架構(gòu)基礎(chǔ)是基于使用JavaBean屬性的 Inversion of Control容器。然而,這僅僅是完整圖景中的一部...  閱讀全文
          posted @ 2008-08-11 10:24 前方的路 閱讀(853) | 評論 (0)編輯 收藏

           

          Chasing an OSGi vision

          OSGi技術(shù)的研究和討論

          posted @ 2008-02-20 16:46 前方的路 閱讀(450) | 評論 (1)編輯 收藏
          使用servlet來下載文件,其原理非常簡單,只要得到文件的輸入流(或相應(yīng)字節(jié)),然后寫輸出流即可。現(xiàn)就其中的幾個細(xì)節(jié)問題展開:
          1. MIME類型的設(shè)置:
          Web 瀏覽器使用 MIME 類型來識別非 HTML 文檔,并決定如何顯示該文檔內(nèi)的數(shù)據(jù)。
          例如EXCEL文件的 MIME 類型是 "application/vnd.ms-excel "。要用servlet 來打開一個 EXCEL 文檔,需要將 response 對象中 header 的 contentType 設(shè)置成“application/vnd.ms-excel ”。
          response.setContentType(contentType);

          2. Content disposition
          HTTP response header中的content-disposition 允許 servlet 指定文檔表示的信息。使用這種header ,你就可以將文檔指定成單獨打開(而不是在瀏覽器中打開),還可以根據(jù)用戶的操作來顯示。
          如果用戶要保存文檔,你還可以為該文檔建議一個文件名。這個建議名稱會出現(xiàn)在 Save As 對話框的“文件名”欄中。如果沒有指定,則對話框中就會出現(xiàn) servlet 的名字。
          servlet 中,將 header 設(shè)置成下面這樣:
          response.setHeader("Content-disposition","attachment;filename="+ "Example.xls" );

          response.setHeader("Content-Disposition", "inline; filename="fliename)
          點擊打開會在ie中打開。


          需要說明的有三點:
          Ø 中文文件名需要進(jìn)行iso8859-1轉(zhuǎn)碼方可正確顯示:
          fileName = new String(fileName.getBytes("GBK"),"iso8859-1");
          Ø 傳遞的文件名,需要包含后綴名(如果此文件有后綴名),否則丟失文件的屬性,而不能自行選擇相關(guān)程序打開。
          Ø 有下載前詢問(是打開文件還是保存到計算機(jī))和通過IE瀏覽器直接選擇相關(guān)應(yīng)用程序插件打開兩種方式,前者如上代碼所示,后者如下:
          response.setHeader("Content-disposition","filename="+ "Example.xls" );
          3. 在研究文件的上傳及下載過程中,有幾點體會
          程序的I/O操作往往是性能的瓶頸所在,java io定義了兩個基本的抽象類:InputStream和OutputStream,對于不同的數(shù)據(jù)類型比如磁盤,網(wǎng)絡(luò)又提供了不同的實現(xiàn),java.io也提供了一些緩沖流(BufferedStream),使硬盤可以很快的讀寫一大塊的數(shù)據(jù), 而Java基本的I/O類一次只能讀寫一個字節(jié),但緩沖流(BufferedStream)可以一次讀寫一批數(shù)據(jù),,緩沖流(Buffered Stream)大大提高了I/O的性能。所以:
          Ø小塊小塊的讀寫數(shù)據(jù)會非常慢,因此,盡量大塊的讀寫數(shù)據(jù)
          Ø使用BufferedInputStream和BufferedOutputStream來批處理數(shù)據(jù)以提高性能
          Ø對象的序列化(serialization)非常影響I/O的性能,盡量少用
          posted @ 2008-02-17 16:32 前方的路 閱讀(337) | 評論 (0)編輯 收藏
               摘要: 金山軟件事業(yè)部的技術(shù)總監(jiān)許式偉常常稱自己是一個計算機(jī)的狂熱愛好者。對于他深厚的軟件開發(fā)經(jīng)歷,他只簡單的分成了桌面開發(fā)階段、服務(wù)器開發(fā)階段。但我想這每一個階段中都蘊(yùn)涵了很多關(guān)于他奮斗故事。  閱讀全文
          posted @ 2008-02-16 21:48 前方的路 閱讀(675) | 評論 (0)編輯 收藏
               摘要: 中國人大都喜歡用武俠小說來比較軟件開發(fā),但是在實戰(zhàn)武功中,只有葵花寶典才是最厲害的,也只有掌握了葵花寶典,才能稱為"不敗"。

          ……

          讓你的思維快起來,你就會區(qū)別于那些反應(yīng)遲鈍的人。如果你不能讓人生的道路變長,就讓它變寬。這世界變化快,需要你變得比它快才行。

          這樣加快并不會讓你短命,相反,你有更多的時間來享受生活和鍛煉身體。你的生活將更有品質(zhì),更豐富,更有意義。面對變化,你將立于不敗之地。我們都是和自己賽跑的人,需要跑得比昨天的自己更快。  閱讀全文
          posted @ 2008-02-03 22:30 前方的路 閱讀(372) | 評論 (0)編輯 收藏
               摘要: OpenCore純插件體系結(jié)構(gòu)中的核心概念包括:微內(nèi)核、插件與服務(wù)。  閱讀全文
          posted @ 2008-01-15 18:26 前方的路 閱讀(778) | 評論 (0)編輯 收藏
               摘要: IDG全球高級副總裁兼亞洲區(qū)總裁熊曉鴿曾在一篇文章中建議Web 2.0的創(chuàng)業(yè)者們“不要把融錢當(dāng)成最重要的事”,并且給出了IDG選擇互聯(lián)網(wǎng)公司的標(biāo)準(zhǔn):“首先看創(chuàng)業(yè)者,它要能創(chuàng)造一些服務(wù)和技術(shù),而且這些服務(wù)和技術(shù)要能取代現(xiàn)有常規(guī)產(chǎn)業(yè),或促進(jìn)其達(dá)到巔峰;第二,不管提供產(chǎn)品還是服務(wù),有終端消費者都是最重要的。”如何才能達(dá)到這樣的標(biāo)準(zhǔn)呢?這就要求我們把目光從美元轉(zhuǎn)到用戶、甚至是轉(zhuǎn)到自己身上。想想看,廣大的用戶在日常生活中,遇到什么樣的具體問題?或者是涌現(xiàn)出哪些新的需求?而且這些問題和需求是可以借助Internet來解決的?有時候,找對要開的鎖比找對鑰匙更為重要。當(dāng)然,鎖找對了,還是要能夠想出開鎖的辦法。接下來的“指導(dǎo)篇”,就是告訴您怎么樣去找到合適的鎖,又怎么樣打造開鎖的金鑰匙。  閱讀全文
          posted @ 2008-01-15 10:00 前方的路 閱讀(344) | 評論 (0)編輯 收藏
               摘要: 當(dāng)前web2.0革命風(fēng)起云涌,web2.0強(qiáng)調(diào)服務(wù),而服務(wù)最基本的要求是速度快和穩(wěn)定,離開這兩個談功能強(qiáng)大和易用性都沒有任何意義。本文介紹一些關(guān)于筆者運營一個web2.0網(wǎng)站的優(yōu)化心得和經(jīng)驗,希望能夠和大家共同探討。

          Web2.0網(wǎng)站不同于以往以靜態(tài)信息為主的網(wǎng)站架構(gòu),以往的結(jié)構(gòu)大體分為2層,一個是客戶端瀏覽器,一個就是web服務(wù)器;而web2.0以動態(tài)和交互為主,一般是3層或者4層,在靜態(tài)信息網(wǎng)站的結(jié)構(gòu)上的web服務(wù)器后端會增加應(yīng)用服務(wù)器和數(shù)據(jù)庫。一般會把瀏覽器和web服務(wù)器歸為最上一層即為web層,應(yīng)用服務(wù)器為中間一層,數(shù)據(jù)庫為最底層。從優(yōu)化角度來講,越上層優(yōu)化獲得益處越大,優(yōu)化也是從上自下而來。
            閱讀全文
          posted @ 2008-01-15 09:58 前方的路 閱讀(417) | 評論 (0)編輯 收藏
               摘要: Google架構(gòu)
          Amazon的體系結(jié)構(gòu)
          eBay的架構(gòu)
          YouTube網(wǎng)站架構(gòu)
          Facebook 詳解  閱讀全文
          posted @ 2008-01-15 09:57 前方的路 閱讀(2976) | 評論 (0)編輯 收藏
               摘要: Web2.0的最大特征就是信息生產(chǎn)的革命,大大促進(jìn)了網(wǎng)絡(luò)內(nèi)容的個體生產(chǎn),從而引發(fā)了微內(nèi)容的海量產(chǎn)生。

          從方軍的《網(wǎng)絡(luò)大圖景:人、物與討論》汲取到的分類思路,微內(nèi)容可以分為三大分類。

          圍繞人的。也就是人與人之間的連接、關(guān)系,這也是SNS網(wǎng)站所產(chǎn)生的微內(nèi)容。

          圍繞物的。這是最通常的微內(nèi)容方向。“物,是一種與人相對的泛指,新聞資訊是物,blog是物,圖書是物,音樂是物,電影是物,旅行過的地方也是物,網(wǎng)摘是物,餐館是物”。譬如豆瓣的對書、電影、音樂的評論、打分、收藏,抓蝦的對blog item的收藏、推薦、分享等。

          交互的。泛指人與人之間的虛擬的或真實的討論。比如因為一個新聞引發(fā)的網(wǎng)絡(luò)地震,就既包含了小范圍內(nèi)的真實討論,也包含了大范圍內(nèi)虛擬的對話。
            閱讀全文
          posted @ 2008-01-15 09:47 前方的路 閱讀(261) | 評論 (0)編輯 收藏
               摘要: Blog——博客、blog
          Podcast——播客
          RSS
          Tag——標(biāo)簽
          Wiki
          Digg

            閱讀全文
          posted @ 2008-01-15 09:45 前方的路 閱讀(464) | 評論 (0)編輯 收藏
               摘要: 1、在你開始之前,先定一個簡單的目標(biāo)。
          2、鏈接是最基礎(chǔ)的思想。
          3、數(shù)據(jù)應(yīng)該屬于創(chuàng)建它的人。
          4、數(shù)據(jù)優(yōu)先,體驗與功能其次。
          5、做好積極分享一切的準(zhǔn)備。
          6、Web是一個平臺;要讓它成長。
          7、理解與信奉“階梯性”。
          8、任何東西都是可編輯的。
          9、Web上的身份是神圣的。
          10、了解流行的標(biāo)準(zhǔn)并且使用他們。
          11、遵循無意使用的規(guī)律。
          12、粒化你的數(shù)據(jù)與服務(wù)。
          13、提供用戶能夠單獨受益的數(shù)據(jù)和服務(wù)。
          14、讓用戶組織并過濾信息。
          15、提供豐富的用戶體驗。
          16、信奉并支持快速改進(jìn)和反饋。
            閱讀全文
          posted @ 2008-01-15 09:41 前方的路 閱讀(257) | 評論 (0)編輯 收藏
          主站蜘蛛池模板: 北安市| 宜章县| 松阳县| 左权县| 郧西县| 湘潭市| 广灵县| 张家港市| 库车县| 晋宁县| 晋州市| 涪陵区| 阜宁县| 宝坻区| 绥德县| 赣州市| 霍州市| 潼关县| 北宁市| 普宁市| 北票市| 苍梧县| 玛沁县| 凤阳县| 柘城县| 鄂温| 垣曲县| 本溪市| 临朐县| 莱州市| 钟山县| 汉源县| 丹寨县| 瑞丽市| 碌曲县| 洛隆县| 黄平县| 扬中市| 浮山县| 仁布县| 桂林市|