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

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

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

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

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

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

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

    在進度把控上，我現在更傾向于強調我們的項目目標和緊迫性，而不是他們的任務。因為我希望大家的關注點是項目，而不是他的上級，他應該對項目負責，而不只是對上級負責。

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

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

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

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

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


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

經常被用來區分軟件架構和軟件設計開發的關鍵幾點包括 伸縮性和抽象程度的增加以及作出正確設計決策意義的增強。軟件架構是通過一個全局的觀點，宏觀的視角來理解軟件系統作為一個整體如何工作。

即使這能夠幫助區分軟件開發和架構，它并不能幫助理解某人如何從開發提升到架構。 并且，它也不能幫助識別誰能夠成為一個好的軟件架構師，如果你想雇人的話你如何去尋找他們以及你是否是一個軟件架構師。
  閱讀全文      摘要: Flashback 技術是以Undo segment中的內容為基礎的， 因此受限于UNDO_RETENTON參數。要使用flashback 的特性，必須啟用自動撤銷管理表空間。
在Oracle 10g中， Flash back家族分為以下成員： Flashback Database， Flashback Drop，Flashback Query(分Flashback Query,Flashback Version Query， Flashback Transaction Query 三種) 和Flashback Table。  閱讀全文      摘要: 代碼檢查是白盒測試的一種靜態測試方法，是眾多軟件測試方法中發現軟件缺陷最有效的方法之一。本文結合國內外學者在相關領域的研究情況，介紹代碼檢查相關的基本概念、過程和分析方法。  閱讀全文      摘要: 為什么需要對參數進行編碼？相信有過開發的經驗的廣大程序員都知道，在Web中，若是直接在Url地址上傳遞參數值，若是中文，或者+等什么的就會出現亂碼現象，若是數字或者英文的好象沒有什么問題，簡言之，傳遞過來的參數是需要進行編碼的。 在這里，也許有人會說，為什么不直接用Server.UrlDecode和Server.UrlEncode這兩個來進行編碼和解碼的操作呢？ 的確，這兩個服務器端對象很...  閱讀全文      摘要: Spring Framework最得以出名的是與Hibernate的無縫鏈接，基本上用Spring，就會用Hibernate。可惜的是Spring提供的 HibernateTemplate功能顯得不夠，使用起來也不是很方便。我們編程序時，一般先寫BusinessService，由 BusinessService調DAO來執行存儲，在這方面Spring沒有很好的例子，造成真正想用好它，并不容易。  閱讀全文      摘要: Spring Framework從誕生之日起，受到了越來越多的關注。最近，新的開源項目大多支持Spring Framework。國內目前也有專門的網站（http://spring.jactiongroup.net/）。那它為什么如此受歡迎呢？

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

 

Chasing an OSGi vision

OSGi技術的研究和討論

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

……

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

這樣加快并不會讓你短命，相反，你有更多的時間來享受生活和鍛煉身體。你的生活將更有品質，更豐富，更有意義。面對變化，你將立于不敗之地。我們都是和自己賽跑的人，需要跑得比昨天的自己更快。  閱讀全文      摘要: OpenCore純插件體系結構中的核心概念包括：微內核、插件與服務。  閱讀全文      摘要: IDG全球高級副總裁兼亞洲區總裁熊曉鴿曾在一篇文章中建議Web 2.0的創業者們“不要把融錢當成最重要的事”，并且給出了IDG選擇互聯網公司的標準：“首先看創業者，它要能創造一些服務和技術，而且這些服務和技術要能取代現有常規產業，或促進其達到巔峰；第二，不管提供產品還是服務，有終端消費者都是最重要的。”如何才能達到這樣的標準呢？這就要求我們把目光從美元轉到用戶、甚至是轉到自己身上。想想看，廣大的用戶在日常生活中，遇到什么樣的具體問題？或者是涌現出哪些新的需求？而且這些問題和需求是可以借助Internet來解決的？有時候，找對要開的鎖比找對鑰匙更為重要。當然，鎖找對了，還是要能夠想出開鎖的辦法。接下來的“指導篇”，就是告訴您怎么樣去找到合適的鎖，又怎么樣打造開鎖的金鑰匙。  閱讀全文      摘要: 當前web2.0革命風起云涌，web2.0強調服務，而服務最基本的要求是速度快和穩定，離開這兩個談功能強大和易用性都沒有任何意義。本文介紹一些關于筆者運營一個web2.0網站的優化心得和經驗，希望能夠和大家共同探討。

Web2.0網站不同于以往以靜態信息為主的網站架構，以往的結構大體分為2層，一個是客戶端瀏覽器，一個就是web服務器；而web2.0以動態和交互為主，一般是3層或者4層，在靜態信息網站的結構上的web服務器后端會增加應用服務器和數據庫。一般會把瀏覽器和web服務器歸為最上一層即為web層，應用服務器為中間一層，數據庫為最底層。從優化角度來講，越上層優化獲得益處越大，優化也是從上自下而來。
  閱讀全文      摘要: Google架構
Amazon的體系結構
eBay的架構
YouTube網站架構
Facebook 詳解  閱讀全文      摘要: Web2.0的最大特征就是信息生產的革命，大大促進了網絡內容的個體生產，從而引發了微內容的海量產生。

從方軍的《網絡大圖景:人、物與討論》汲取到的分類思路，微內容可以分為三大分類。

圍繞人的。也就是人與人之間的連接、關系，這也是SNS網站所產生的微內容。

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

交互的。泛指人與人之間的虛擬的或真實的討論。比如因為一個新聞引發的網絡地震，就既包含了小范圍內的真實討論，也包含了大范圍內虛擬的對話。
  閱讀全文      摘要: Blog——博客、blog
Podcast——播客
RSS
Tag——標簽
Wiki
Digg

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

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

第二篇：PHP安裝
Quote:

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


2、程序安裝：



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




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




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




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




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




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




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




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



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




安裝過程，等待



安裝完成，單擊Finish（完成）結束安裝





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

第三篇：PHP與IIS整合
Quote:

說起來，這一點應該是PHP安裝最重要的一個環節了，如果這一步沒有成功，其他的都白搞了，呵呵。



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




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




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




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




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





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

Copy code

<?php
     phpinfo();
?>

 

     摘要: 作者 : Stephen Covey


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

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


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% 則由你的反應
而決定。
  閱讀全文      摘要: 在很多企業應用中有時需要在特定的時間運行一段代碼，比如銀行需要在晚上系統相對空閑的時間內進行日結的對帳，到了規定時間系統需要觸發對帳服務，運行對帳程序，通過WebSphere Application Server和EJB定時器服務能解決這個問題。

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

設計目標：

 

1.       開發效率

2.       性能、預算

3.       符合OO設計

4.       避免復雜性

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

 

 

分布式應用

 

不足：

1．  增加了應用的復雜性

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

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

優點：

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

2．  能同時將組件部署到不同的應用服務器

采用前提：

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

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

3．  實現對多應用組件部署進行控制，提高系統靈活性、可靠性

 

 

可選技術：

可通過集群和負載平衡（remote interface調用單服務器應用）來實現分布式應用的健壯性、靈活性

 

 

EJB技術

 

缺點：

1．  測試困難

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

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

4．  技術復雜，可能將簡單需求變得復雜開發

5．  減少了應用服務器的選擇

優點：

1．  能遠程訪問組件

2．  能將應用組件部署到不同服務器（分布式應用）

3．  支持多客戶端訪問

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

5．  能實現復雜的事務管理

 

 

采用前提：

1、  對EJB底層比較熟悉

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

3、  需要使用EJB的事務管理

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

5、  需要使用基于RMI/IIOP的分布式架構

 

 

4種J2EE基本框架

 

一．非分布式框架

 

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

 

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

優點：

1．簡單

2．速度快

3．符合OO設計

4．容易測試

缺點：

1．僅僅適用于Web UI

2．自己管理事務

3．無法實現高并發處理

4．無法使用entity bean

5．不支持多JVM應用

2、Web UI + local EJB + DBMS

 

稍微復雜，能使用EJB容器的事務，線程管理，沒有采用分布式特性，性能比遠程調用稍好

優點：

1．降低了EJB的復雜度

2．不會對基礎框架造成影響

3．本地調用對性能有一定優勢

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

5．可以使用entity bean

缺點：

1．比純web應用復雜

2．單JVM運行

3．單客戶端（web）支持

4．測試困難

 

 

二．分布式框架

 

1．基于遠程調用的分布式

 

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

優點：

1．  多客戶端支持

2．  可將應用組件部署到多臺服務器（JVM）

缺點：

1．增加了復雜度

2．影響性能

3．調試困難

4．必須在EJB容器中運行

5．異常處理復雜

6．OO設計困難

2．基于Web Service的分布式

 

對非J2EE客戶端調用適用性好，無分布式調用，往往作為第一、第二架構的變體。

優點：

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

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

3．  Web service傳輸協議比RMI更友好

缺點：

1．  性能差

2．  需要作object與xml之間的轉換

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

 

 

UI框架部分

 

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

1．  用戶的實際需求

2．  項目的性能要求

3．  當前開發人員技術水平

 

 

 

 

J2EE框架設計幾個需要強調的觀點

 

簡單

可維護性

性能

開發效率

 

 

J2EE框架設計通用法則

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

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

3．  萬不得已不要采用分布式架構

4．  企業應用不要僅僅局限于J2EE技術（業務知識，.NET技術）

5．  J2EE不僅僅是一個規范

6．  謹慎處理數據庫通用性，數據比J2EE應用的壽命更長

7．  利用好JDBC(SQL)技術

8．  不要忽略數據庫的能力

9．  簡單即是美

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

11．在項目啟動初期就應該考慮到性能問題

12．在設計的時候考慮應用在集群環境下運行的可能性

13．好的J2EE設計來自于好的OO設計

14．使用輔助類來隱藏底層API實現

15．在web UI層采用MVC框架

 

 

J2EE框架設計成則

1．  底層設計必須著眼當前可用規范而不是未來新規范

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

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

4．  對代碼進行詳盡注釋

5．  盡可能早的對風險加以解決

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

7．  在項目早期實現自動測試和構建

8．  在項目啟動時雇傭J2EE設計專家

9．  避免重復發明輪子

10．統一設計和編碼風格 

     摘要: 大量的負載均衡相關文檔鏈接，在這里收集起來，以備后用  閱讀全文      摘要: 簡介
　　即使是經驗豐富的 Java Web 開發人員也會驚訝于開發門戶這一如此巨大的飛躍。最終用戶看到的那個簡單漂亮的界面的背后是像BEA WebLogic Portal 這樣的商業產品提供的強大功能和復雜性。當門戶應用程序處于生產階段時，診斷性能問題就會顯得格外的困難。

　　本文討論了 WebLogic Portal 在性能管理方面存在的一些挑戰，并為在門戶應用程序內進行性能瓶頸調優提供了一個很好的起點。本文假設您對WebLogic Portal的功能和術語已經十分熟悉。

　　一個公司的門戶能讓公司更有效地利用其技術和人力資產，而同時又能為其員工、合作伙伴和客戶提供一流的Web體驗。由于這個原因，門戶應用程序現在對業務來說十分關鍵，并且要能提供可靠的性能和可擴展性。BEA WebLogic Portal 是一種領先的基于Java EE 的門戶服務器，可提供部署和運行門戶應用程序的健壯的解決方案。

  閱讀全文      摘要: 在Web服務器端編程中，會話狀態管理是一個經常必須考慮的重要問題。本文分析JSP/Servlet的會話管理機制及其所面臨的問題，然后提出了一種改進的會話管理方法。
  閱讀全文      摘要: Introducing to Spring Framework 作者：Rod Johnson 譯者：yanger，taowen 校對：taowen 關于Spring Framework，今年夏天你可能已經聽見很多的議論。在本文中,我將試圖解釋Spring能完成什么，和我怎么會認為它能幫助你開發J2EE應用程序。 又來一個framework？ 你可能正在想“不過是另外一個的framewo...  閱讀全文      摘要: 本文詳細介紹Log4j的所有配置屬性。  閱讀全文      摘要: Spring的核心是個輕量級容器（container），實現了IoC（Inversion of Control）模式的容器。Spring的目標是實現一個全方位的整合框架，在Spring框架下實現多個子框架的組合，這些子框架之間彼此可以獨立，也可以使用其它的框架方案加以替代，Spring希望提供一站式的框架整合方案。在某些情況下，利用Spring可以不必考慮設計模式。因為Spring 其實就是遵從了J2EE的設計模式。  閱讀全文      摘要: 3年前，“Spring之父” Rod.Johnson寫了一本在Java界引起轟動的書：《Expert One-on-One J2EE Development Without EJB》。這本書闡述了EJB作為J2EE核心技術所帶來的意義與價值，但作者用了更大篇幅介紹EJB的一些缺陷與不足，并提出了Without EJB的解決方案。正是由于“J2EE Without EJB”這個激動人心的口號及這本書奠定的基礎，導致了Spring Framework這個經典輕量級框架的誕生。

2年前，Ajax開始進入人們的視野。時至今日，Ajax已經成為一個紅得發紫的技術。但是今天，我想說一句：JavaEE without Ajax。   閱讀全文      摘要: Java編程中的異常處理是一個很常見的話題了，幾乎任何一門介紹性的Java課程都會提到異常處理。不過，我認為很多人其實并沒有真正掌握正確處理異常情況的方法和策略，最多也就不過了解個大概，知道點概念。本文就對三種不同程度和質量的Java異常處理進行了討論，所闡述的處理異常的方式按手法的高下分為：

好，不好和惡劣三種。

同時向你提供了一些解決這些問題的技巧。   閱讀全文      摘要: 　　在ChinaITLAB導師制輔導中，筆者發現問得最多的問題莫過于"如何學習編程？JAVA該如何學習？"。類似的問題回答多了，難免會感覺厭煩，就萌生了寫下本文的想法。到時候再有人問起類似的問題，我可以告訴他（她），請你去看看《JAVA學習之路》。拜讀過臺灣蔡學鏞先生的《JAVA夜未眠》，有些文章如《JAVA學習之道》等讓我們確實有共鳴，本文題目也由此而來。
　　
軟件開發之路是充滿荊棘與挑戰之路,也是充滿希望之路。JAVA學習也是如此，沒有捷徑可走。夢想像《天龍八部》中虛竹一樣被無崖子醍醐灌頂而輕松獲得一甲子功力，是很不現實的。每天仰天大叫"天神啊，請賜給我一本葵花寶典吧"，殊不知即使你獲得了葵花寶典，除了受自宮其身之苦外，你也不一定成得了"東方不敗"，倒是成"西方失敗"的幾率高一點。
　　
　　"不走彎路，就是捷徑"，佛經說的不無道理。  閱讀全文      摘要: 接口回調是指：可以把使用某一接口的類創建的對象的引用賦給該接口聲明的接口變量，那么該接口變量就可以調用被類實現的接口的方法。實際上，當接口變量調用被類實現的接口中的方法時，就是通知相應的對象調用接口的方法，這一過程稱為對象功能的接口回調。  閱讀全文      摘要: 本文將介紹如何在程序中使用Log4j。  閱讀全文      摘要: 1．wait、notify、notifyAll
2. producer-consumer
3．線程的終止
。。。  閱讀全文      摘要: Java Timer 應用實例  閱讀全文      摘要: 在Axis2_1.2版本中提供了傳遞Java對象的功能（注：只有1.1/1.2版本提供，更早的Axis2版本沒有此功能）。此項功能稱為傳輸POJO(a Plain Old Java Object)  閱讀全文      摘要: Ant使用更進一步的介紹  閱讀全文      摘要: Ant使用的簡單介紹  閱讀全文      摘要: 可變參數列表的簡單實現  閱讀全文      摘要: 分析一下UML類圖中關聯、聚合、組合三者的定義與關系。  閱讀全文      摘要: 本文將介紹如何使用Tomcat5.0和Apache Axis2開發、部署及測試一個簡單的Web Service應用。  閱讀全文      摘要: 本文介紹 Axis2 的新體系結構，并說明如何通過 Axis2 部署和使用 Web 服務。本文是有關通過 Axis2 運行時開發 Web 服務的系列文章的第 1 部分（共兩部分）。Axis2 是下一代 Apache Axis Simple Object Access Protocol (SOAP) 運行時。  閱讀全文