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

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

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

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

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

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

    人適應(yīng)項目，還是項目適應(yīng)人
    大公司，往往是來了一個項目，趕快招人，人來適應(yīng)項目。小公司呢，我現(xiàn)在的看法是，項目適應(yīng)人。小公司，往往一個項目做砸，公司就面臨解散。所以，我認為，最好還是按照開發(fā)人員的擅長，保證功能質(zhì)量，最快的速度上線。另外，為了達成進度，可以在上線初期砍掉不太重要的欄目或功能。
    我在這個上面栽過跟頭的。比如開發(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。但我還是覺得目前是最好的選擇。
    如果最低層次的用戶需求目標都達不到，直接考慮代碼怎么有可擴展性、可維護性，對于小公司就是找死。
    另外，尊重和信任、支持開發(fā)人員的技術(shù)選擇，往往是一種激勵、增強團隊凝聚力的方式。萬眾一心，比什么目標、進度更有效、實際。
    我們應(yīng)該培養(yǎng)一種團隊成員的內(nèi)部創(chuàng)業(yè)心態(tài)，而不只是敬業(yè)。

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

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

   溝通:命令式還是征詢式
   在溝通，特別是下達任務(wù)或做決策這類事情上。應(yīng)該說中國絕大多少管理者都是用命令式。我過去經(jīng)常在用，但一直在試圖改正，改用建議式和征詢式。管理者最需要、最難開口的一句話是：Do you think so？命令的方式，經(jīng)常出現(xiàn)下級不能理解上級的意圖，嚴重的出現(xiàn)抵觸。每個人，其實都喜歡別人按自己的想法做事，但你怎么知道自己的想法或決策是對或不是偏頗的，怎么讓團隊愿意去執(zhí)行？去征詢團隊其他成員的意見，讓他們參與，往往能夠培養(yǎng)其主人翁意識、責任感、向心力，還能夠完善自己的想法。但要將員工參與意識，轉(zhuǎn)化為一種習(xí)慣，太難。
    當大家都沒有主見時，需要領(lǐng)導(dǎo)者的果斷、魄力和強勢，但這種機會并不多，而且這種情況，需要團隊成員對領(lǐng)導(dǎo)者的信任。
   
    遵守制度，還是建立信任
     在大公司，往往是告訴你怎么去遵守公司制度。在小公司，我認為最基礎(chǔ)、最核心的一件事，就是建立信任，讓團隊信任你的人品(說到做到)，信任你的能力(能夠把大家?guī)У揭粋€新的高度)。建立了信任后，下一步的核心工作，怎么將你的個人目標，也就是團隊目標，轉(zhuǎn)化為每個成員的個人目標。
    有了信任這個基礎(chǔ)，才會有了團隊建設(shè)的第二個核心：激勵。
    是激勵，而不是約束、監(jiā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套視頻，還看過幾遍。他那種人本理念我還是很認同，只是，他在大公司、規(guī)范公司的做事情方法和風(fēng)格，完全照搬拿到小公司，非常危險。你能夠拿幼兒園那種教育方法來教育成年人嗎？小公司不具備大公司那種職業(yè)化的環(huán)境，也不具備大公司在行業(yè)中的市場地位及資金實力。
    如果說大公司講究做事方法、流程，如SWOT分析法、BCG矩陣，小公司更看重靈活性、市場適應(yīng)性。小公司應(yī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è)平均值），但最重要的，還是不要低于當事人的期望值，因為最核心的是滿意度，而滿意度決定于期望值和實際值的差距。對于小公司，往往一個人技術(shù)人員的成本和收益，和其工資差距非常大，有可能10倍。所以，我們的關(guān)注點，應(yīng)該是怎么一開始留住這位人才。然后，怎么讓其充分發(fā)揮潛力。小公司往往不是因為節(jié)省那幾千幾萬的工資成本死掉的，而是充分利用這位人才才活下去了。

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

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


我將我的一個回復(fù)放在這個地方，特示警醒：
原文地址：http://www.javaeye.com/topic/646406      摘要: 開發(fā)和架構(gòu)的界限難以捉摸。有些人告訴你它根本不存在，架構(gòu)只是開發(fā)者們所做的設(shè)計過程的簡單擴展。 另外一些人認為這是一個鴻溝，它只能由那些做到高度抽象，而且不會陷入實現(xiàn)細節(jié)的開發(fā)者才能跨越。通常，在這兩個極端的觀點中間某處有個可操作的平衡點；不論如何，怎么從開發(fā)轉(zhuǎn)換為架構(gòu)師都是個有趣的問題。

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

即使這能夠幫助區(qū)分軟件開發(fā)和架構(gòu)，它并不能幫助理解某人如何從開發(fā)提升到架構(gòu)。 并且，它也不能幫助識別誰能夠成為一個好的軟件架構(gòu)師，如果你想雇人的話你如何去尋找他們以及你是否是一個軟件架構(gòu)師。
  閱讀全文      摘要: 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。  閱讀全文      摘要: 代碼檢查是白盒測試的一種靜態(tài)測試方法，是眾多軟件測試方法中發(fā)現(xiàn)軟件缺陷最有效的方法之一。本文結(jié)合國內(nèi)外學(xué)者在相關(guān)領(lǐng)域的研究情況，介紹代碼檢查相關(guān)的基本概念、過程和分析方法。  閱讀全文      摘要: 為什么需要對參數(shù)進行編碼？相信有過開發(fā)的經(jīng)驗的廣大程序員都知道，在Web中，若是直接在Url地址上傳遞參數(shù)值，若是中文，或者+等什么的就會出現(xiàn)亂碼現(xiàn)象，若是數(shù)字或者英文的好象沒有什么問題，簡言之，傳遞過來的參數(shù)是需要進行編碼的。 在這里，也許有人會說，為什么不直接用Server.UrlDecode和Server.UrlEncode這兩個來進行編碼和解碼的操作呢？ 的確，這兩個服務(wù)器端對象很...  閱讀全文      摘要: Spring Framework最得以出名的是與Hibernate的無縫鏈接，基本上用Spring，就會用Hibernate。可惜的是Spring提供的 HibernateTemplate功能顯得不夠，使用起來也不是很方便。我們編程序時，一般先寫B(tài)usinessService，由 BusinessService調(diào)DAO來執(zhí)行存儲，在這方面Spring沒有很好的例子，造成真正想用好它，并不容易。  閱讀全文      摘要: Spring Framework從誕生之日起，受到了越來越多的關(guān)注。最近，新的開源項目大多支持Spring Framework。國內(nèi)目前也有專門的網(wǎng)站（http://spring.jactiongroup.net/）。那它為什么如此受歡迎呢？

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

 

Chasing an OSGi vision

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

     摘要: 金山軟件事業(yè)部的技術(shù)總監(jiān)許式偉常常稱自己是一個計算機的狂熱愛好者。對于他深厚的軟件開發(fā)經(jīng)歷，他只簡單的分成了桌面開發(fā)階段、服務(wù)器開發(fā)階段。但我想這每一個階段中都蘊涵了很多關(guān)于他奮斗故事。  閱讀全文      摘要: 中國人大都喜歡用武俠小說來比較軟件開發(fā)，但是在實戰(zhàn)武功中，只有葵花寶典才是最厲害的，也只有掌握了葵花寶典，才能稱為"不敗"。

……

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

這樣加快并不會讓你短命，相反，你有更多的時間來享受生活和鍛煉身體。你的生活將更有品質(zhì)，更豐富，更有意義。面對變化，你將立于不敗之地。我們都是和自己賽跑的人，需要跑得比昨天的自己更快。  閱讀全文      摘要: OpenCore純插件體系結(jié)構(gòu)中的核心概念包括：微內(nèi)核、插件與服務(wù)。  閱讀全文      摘要: IDG全球高級副總裁兼亞洲區(qū)總裁熊曉鴿曾在一篇文章中建議Web 2.0的創(chuàng)業(yè)者們“不要把融錢當成最重要的事”，并且給出了IDG選擇互聯(lián)網(wǎng)公司的標準：“首先看創(chuàng)業(yè)者，它要能創(chuàng)造一些服務(wù)和技術(shù)，而且這些服務(wù)和技術(shù)要能取代現(xiàn)有常規(guī)產(chǎn)業(yè)，或促進其達到巔峰；第二，不管提供產(chǎn)品還是服務(wù)，有終端消費者都是最重要的。”如何才能達到這樣的標準呢？這就要求我們把目光從美元轉(zhuǎn)到用戶、甚至是轉(zhuǎn)到自己身上。想想看，廣大的用戶在日常生活中，遇到什么樣的具體問題？或者是涌現(xiàn)出哪些新的需求？而且這些問題和需求是可以借助Internet來解決的？有時候，找對要開的鎖比找對鑰匙更為重要。當然，鎖找對了，還是要能夠想出開鎖的辦法。接下來的“指導(dǎo)篇”，就是告訴您怎么樣去找到合適的鎖，又怎么樣打造開鎖的金鑰匙。  閱讀全文      摘要: 當前web2.0革命風(fēng)起云涌，web2.0強調(diào)服務(wù)，而服務(wù)最基本的要求是速度快和穩(wěn)定，離開這兩個談功能強大和易用性都沒有任何意義。本文介紹一些關(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)化也是從上自下而來。
  閱讀全文      摘要: Google架構(gòu)
Amazon的體系結(jié)構(gòu)
eBay的架構(gòu)
YouTube網(wǎng)站架構(gòu)
Facebook 詳解  閱讀全文      摘要: Web2.0的最大特征就是信息生產(chǎ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)虛擬的對話。
  閱讀全文      摘要: Blog——博客、blog
Podcast——播客
RSS
Tag——標簽
Wiki
Digg

  閱讀全文      摘要: 1、在你開始之前，先定一個簡單的目標。
2、鏈接是最基礎(chǔ)的思想。
3、數(shù)據(jù)應(yīng)該屬于創(chuàng)建它的人。
4、數(shù)據(jù)優(yōu)先，體驗與功能其次。
5、做好積極分享一切的準備。
6、Web是一個平臺；要讓它成長。
7、理解與信奉“階梯性”。
8、任何東西都是可編輯的。
9、Web上的身份是神圣的。
10、了解流行的標準并且使用他們。
11、遵循無意使用的規(guī)律。
12、粒化你的數(shù)據(jù)與服務(wù)。
13、提供用戶能夠單獨受益的數(shù)據(jù)和服務(wù)。
14、讓用戶組織并過濾信息。
15、提供豐富的用戶體驗。
16、信奉并支持快速改進和反饋。
  閱讀全文      摘要: 普通的系統(tǒng)，在編譯發(fā)布之后，系統(tǒng)就不允許進行更改或擴充了，如果要進行某個功能的擴充，則必須要修改代碼重新編譯發(fā)布。使用插件可以很好地解決這個問題。  閱讀全文 第一篇：IIS安裝
Quote:

第一篇我們就不說了，怎么安裝IIS網(wǎng)上到處都是，我們直接開始第二篇吧。

第二篇：PHP安裝
Quote:

1、程序下載：
建議到PHP官方網(wǎng)站
網(wǎng)址：http://cn2.php.net/get/php-5.2.0-Win32.zip/from/a/mirror


2、程序安裝：



解壓或者未解壓后，能看到php-5.2.0-win32-installer.msi文件時，雙擊文件，彈出下列對話框，我們再單擊Next（下一步）：




在這一步，他會要你同意一個協(xié)議，不同意是沒法繼續(xù)安裝的。同意就同意唄，反正這個東西是開源的，（應(yīng)該是的吧）呵呵：




在這一步選擇安裝文件夾，如果要更改，單擊Browse（瀏鑒）。這里，我建議不要改更。第一，PHP文件不大；第二，由于這個本來不是Windows下的文件，更改不知道會不會有什么不能用的地方。：




選擇你的WEB服務(wù)程序，建議選擇IIS/PWS 3。這個選項在XP的IIS下，也就是IIS5.5下測試通過。：




程序安裝組界面，別急點點下一步，看清楚下面的說明：




在上圖中顯示的Extensions（擴展）前面的“+”號點開，然后拖動滾動條，一直到下圖位置。在GD2上右擊，然后選擇安裝此功能（選擇中的第一個或者二個）。
其實，第一個跟第二個的區(qū)別在這個地方不大。如果有下屬選項時，選第一個，只會安裝一些默認的功能，而第二個是完全安裝。懂英語的朋友就不要笑話我了，呵呵  




同理，拖到mysql那一項，與前面一樣的操作。如果你的mysql版本比較高，建議把mysqlli也裝上，就是在mysql下面的那一個。  




需要的人還可以到下面這個地方，按照上面兩步的方法安裝PHP幫助文檔與PEAR。然后單擊Next（下一步）



單擊Install（安裝），開始正式安裝PHP




安裝過程，等待



安裝完成，單擊Finish（完成）結(jié)束安裝





到這里，我們的PHP算是裝完了。休息一下，我們馬上開始講第三篇，PHP與IIS整合

第三篇：PHP與IIS整合
Quote:

說起來，這一點應(yīng)該是PHP安裝最重要的一個環(huán)節(jié)了，如果這一步?jīng)]有成功，其他的都白搞了，呵呵。



打開IIS，然后在你要支持PHP的網(wǎng)站名稱上右擊，選擇“屬性”。當然，如果你要所有的網(wǎng)站都支持PHP，也可以在“網(wǎng)站”上面右擊，選擇屬性。




這是彈出來的網(wǎng)站屬性對話框，我們要選擇的是“主目錄”選項卡。   




選擇“主目錄”選項卡后，再點擊這個選項卡下面的“配置”




彈出應(yīng)該程序配置選項卡，這里時候，我們要選擇“添加”   




這步比較關(guān)鍵，這個是點擊添加后彈出來的。
在“可執(zhí)行文件”后面，我們選擇“php-cgi.exe”，前面的路徑是你的PHP安裝路徑。
而這個，在很多以前的參考上，都是一個DLL文件，而這個版本是php-cgi.exe。
“擴展名”填“.php”，別把那個點“.”丟了。
后面就是一直“確定”到最后了。呵呵





最后，我們來寫一個測試程序“test.php”，然后打開測試。如果你看到了跟我圖片中類似的內(nèi)容，那么恭喜你，PHP安裝成功了！
test.php內(nèi)容：

Copy code

<?php
     phpinfo();
?>

 

     摘要: 作者 : Stephen Covey


It will change your life (at least the way you react to situations).

它將改變你的一生（最低限度，它將改變你對不同情況的反應(yīng)）。


What is this principle? 10% of life is made up of what happens to you. 90% of life is
decided by how you react.

90/10 的定律是什麼？生命的 10% 是由你的際遇所組成，餘下的 90% 則由你的反應(yīng)
而決定。
  閱讀全文      摘要: 在很多企業(yè)應(yīng)用中有時需要在特定的時間運行一段代碼，比如銀行需要在晚上系統(tǒng)相對空閑的時間內(nèi)進行日結(jié)的對帳，到了規(guī)定時間系統(tǒng)需要觸發(fā)對帳服務(wù)，運行對帳程序，通過WebSphere Application Server和EJB定時器服務(wù)能解決這個問題。

  閱讀全文      摘要: 當您需要強大而靈活的可擴展 J2EE 應(yīng)用程序時，可以利用 WebSphere? 集群環(huán)境。本文描述了在 WebSphere Application Server 集群環(huán)境中設(shè)計基于 Web 的應(yīng)用程序時需要考慮的事項，包括應(yīng)用程序文件更新和同步、會話對象的序列化和動態(tài)緩存。  閱讀全文      摘要: 中間件廠商對分布式網(wǎng)絡(luò)環(huán)境的定義和理解并非完全相同，因此不同的中間件產(chǎn)品實現(xiàn)集群時所使用的概念和方式也有所不同。本文基于較為普遍應(yīng)用的中間件產(chǎn)品 IBM WAS ND v6.1 講述集群及分布式網(wǎng)絡(luò)環(huán)境的相關(guān)概念，并且使用一個實例來演示集群環(huán)境的完整實現(xiàn)過程。  閱讀全文      摘要: 本文通過兩個實際場景，介紹如何從頭搭建一個WAS ND水平集群環(huán)境以及如何將一個已有的單節(jié)點（或三節(jié)點）Web環(huán)境擴展成五節(jié)點的集群環(huán)境。  閱讀全文      摘要: J2EE集群的本質(zhì)  閱讀全文      摘要: 本文目的在于分析Jetspeed支持集群的現(xiàn)狀。首先介紹了集群計算的背景知識，然后使用tomcat作為例子配置了一個集群，接著分析了 jetspeed對集群的支持現(xiàn)狀，提出了解決這些問題的辦法，最后詳細解釋了jetspeed保存sesson數(shù)據(jù)的操作，這將對jetspeed的改造有幫助。  閱讀全文      摘要: 本文對Spring框架中所包含的AOP思想以及事務(wù)管理進行了分析，并通過對一個業(yè)務(wù)對象實現(xiàn)加鎖/解鎖的操作
  閱讀全文

設(shè)計目標：

 

1.       開發(fā)效率

2.       性能、預(yù)算

3.       符合OO設(shè)計

4.       避免復(fù)雜性

5.       可維護性、可擴展性，可重用性

 

 

分布式應(yīng)用

 

不足：

1．  增加了應(yīng)用的復(fù)雜性

2．  對性能會造成一定的影響

3．  給OO Design帶來一定的困難

優(yōu)點：

1．  能滿足多類型客戶端的需求（applet, swing）

2．  能同時將組件部署到不同的應(yīng)用服務(wù)器

采用前提：

1．  客戶端需要使用J2EE技術(shù)，比如Swing

2．  為了與已有的分布式應(yīng)用集成， 需要將J2EE組件部署到多個應(yīng)用服務(wù)器

3．  實現(xiàn)對多應(yīng)用組件部署進行控制，提高系統(tǒng)靈活性、可靠性

 

 

可選技術(shù)：

可通過集群和負載平衡（remote interface調(diào)用單服務(wù)器應(yīng)用）來實現(xiàn)分布式應(yīng)用的健壯性、靈活性

 

 

EJB技術(shù)

 

缺點：

1．  測試困難

2．  部署麻煩（classloader復(fù)雜、部署描述符復(fù)雜、開發(fā)－部署－測試周期長）

3．  采用remote interface的EJB不符合OO Design

4．  技術(shù)復(fù)雜，可能將簡單需求變得復(fù)雜開發(fā)

5．  減少了應(yīng)用服務(wù)器的選擇

優(yōu)點：

1．  能遠程訪問組件

2．  能將應(yīng)用組件部署到不同服務(wù)器（分布式應(yīng)用）

3．  支持多客戶端訪問

4．  使用到異步消息模式的時候可以采用message driven bean

5．  能實現(xiàn)復(fù)雜的事務(wù)管理

 

 

采用前提：

1、  對EJB底層比較熟悉

2、  需要使用EJB的角色安全訪問

3、  需要使用EJB的事務(wù)管理

4、  需要使用EJB的線程安全管理

5、  需要使用基于RMI/IIOP的分布式架構(gòu)

 

 

4種J2EE基本框架

 

一．非分布式框架

 

1、(Web UI tier + Business Logic tier) + implement tier + DBMS

 

實現(xiàn)簡單、能滿足大部分需求，是中小型J2EE項目中采用最多的框架，雖然沒有使用EJB，但是層次清晰。

優(yōu)點：

1．簡單

2．速度快

3．符合OO設(shè)計

4．容易測試

缺點：

1．僅僅適用于Web UI

2．自己管理事務(wù)

3．無法實現(xiàn)高并發(fā)處理

4．無法使用entity bean

5．不支持多JVM應(yīng)用

2、Web UI + local EJB + DBMS

 

稍微復(fù)雜，能使用EJB容器的事務(wù)，線程管理，沒有采用分布式特性，性能比遠程調(diào)用稍好

優(yōu)點：

1．降低了EJB的復(fù)雜度

2．不會對基礎(chǔ)框架造成影響

3．本地調(diào)用對性能有一定優(yōu)勢

4．可以使用EJB容器的事務(wù)和線程管理

5．可以使用entity bean

缺點：

1．比純web應(yīng)用復(fù)雜

2．單JVM運行

3．單客戶端（web）支持

4．測試困難

 

 

二．分布式框架

 

1．基于遠程調(diào)用的分布式

 

架構(gòu)最復(fù)雜，對有遠程訪問客戶端的需求是理想選擇，健壯、靈活，但是不容易維護、測試、實現(xiàn)困難

優(yōu)點：

1．  多客戶端支持

2．  可將應(yīng)用組件部署到多臺服務(wù)器（JVM）

缺點：

1．增加了復(fù)雜度

2．影響性能

3．調(diào)試困難

4．必須在EJB容器中運行

5．異常處理復(fù)雜

6．OO設(shè)計困難

2．基于Web Service的分布式

 

對非J2EE客戶端調(diào)用適用性好，無分布式調(diào)用，往往作為第一、第二架構(gòu)的變體。

優(yōu)點：

1．  通用標準，能支持更多客戶端類型

2．  提供的Web service接口比RMI接口更好

3．  Web service傳輸協(xié)議比RMI更友好

缺點：

1．  性能差

2．  需要作object與xml之間的轉(zhuǎn)換

3．  相對于java client來說，性能也不好

 

 

UI框架部分

 

選擇UI的幾個決定性因素：

1．  用戶的實際需求

2．  項目的性能要求

3．  當前開發(fā)人員技術(shù)水平

 

 

 

 

J2EE框架設(shè)計幾個需要強調(diào)的觀點

 

簡單

可維護性

性能

開發(fā)效率

 

 

J2EE框架設(shè)計通用法則

1．  使用J2EE，而不是讓J2EE牽著鼻子走（因需而用，而不是因有而用）

2．  萬不得已不要使用EJB（謬論：把EJB視為J2EE核心）

3．  萬不得已不要采用分布式架構(gòu)

4．  企業(yè)應(yīng)用不要僅僅局限于J2EE技術(shù)（業(yè)務(wù)知識，.NET技術(shù)）

5．  J2EE不僅僅是一個規(guī)范

6．  謹慎處理數(shù)據(jù)庫通用性，數(shù)據(jù)比J2EE應(yīng)用的壽命更長

7．  利用好JDBC(SQL)技術(shù)

8．  不要忽略數(shù)據(jù)庫的能力

9．  簡單即是美

10．有時候使用EJB的好處可能來自于無狀態(tài)Bean

11．在項目啟動初期就應(yīng)該考慮到性能問題

12．在設(shè)計的時候考慮應(yīng)用在集群環(huán)境下運行的可能性

13．好的J2EE設(shè)計來自于好的OO設(shè)計

14．使用輔助類來隱藏底層API實現(xiàn)

15．在web UI層采用MVC框架

 

 

J2EE框架設(shè)計成則

1．  底層設(shè)計必須著眼當前可用規(guī)范而不是未來新規(guī)范

2．  沒有針對實際需求的簡單例程參考價值有限

3．  對框架進行詳盡的測試

4．  對代碼進行詳盡注釋

5．  盡可能早的對風(fēng)險加以解決

6．  項目啟動時就確定所采用的服務(wù)器

7．  在項目早期實現(xiàn)自動測試和構(gòu)建

8．  在項目啟動時雇傭J2EE設(shè)計專家

9．  避免重復(fù)發(fā)明輪子

10．統(tǒng)一設(shè)計和編碼風(fēng)格 

     摘要: 大量的負載均衡相關(guān)文檔鏈接，在這里收集起來，以備后用  閱讀全文