其他

需求概述在伺服器端可以很方便的獲得當前頁面登入的使用者資訊，但是有的時候需要在用戶端利用指令碼獲得當前登入的使用者資訊。使用者YoungSem登入顯示的菜單使用者Jacqueline登入顯示的菜單實現原理利用伺服器端獲得使用者資訊利用WebPart將使用者資訊發送到用戶端在用戶端利用指令碼獲得使用者資訊實現細節產生一個可以獲得頁面登入資訊的使用者控制項；利用KaneBoy的使用者控制項封裝器將產生的使用者控制項封裝成WebPart；發布WebPart到相應的頁面；將“內容編輯Web組件”拖動到頁

前面的一偏《抉擇》，終於有答案了，結果在我預料中！公司又一次發生了變化，自從轉到多媒體後，一批人走了。現在，公司又出現的生存性的選擇，又一批人離開了公司。現在，剩下了大約10人的團隊又一次投入到產品開發中。這個團隊是公司的全部，廈門的成敗就要靠這個團隊，靠團隊每個成員的努力了。隱隱約約總有點從大公司回到小公司的感覺。這次轉變，雖然動作過大，但我這是好的，無論是對我，還是公司。發展的成功案例總是是從小到大的，那有什麼都不懂的情況下，還把公司規劃的那麼大呢？那樣肯定要碰壁的，所以要從頭開始摸索，只有

我最近一個月忙著Coding，好久沒寫東西了。在這一個月裡，過得還算充實。三個人寫了100多K行的代碼。當然，這些代碼都是用VS2005寫的，用TFS來進行Source Control。到現在為止，把VSTS摸點還算熟悉。在HRM中，我主要進行體系和結構的設計，當然還負責Entity和Biz，還少部分的UI。在這個月中，HRM還好有Charles，要不真不知道忙到什麼時候，畢竟經驗還是很重要的。當然還有小蔡，是他糾正了我們UI走的錯路。雖然充實，還很累，因為在這當中還要負責兩個項目的CM的工作。

Ghost然後restore，ghost……restore……今天我不知道弄了多少遍的作業系統和TFS，包括重新安裝Team explorer。但無論如何都在建立Team Project失敗而告終。其原因很簡單，就是第一次建立Team Project的時候，不小心取消了。真不知道為什麼Microsoft不做個象樣的復原。只知道復原失敗，不知道是不是有復原，然到就只有一個tip，“你復原失敗”。而且垃圾的log根本看不出錯誤在哪裡。今天是我絕對鬱悶的一天……

 規範可以指導我們進行有條不紊的開發，在1年前我是這樣子開發的。當我拿到一個課題或系統，首先我會去找找資料，把情況瞭解清楚後，在腦子裡構思一番，然後就上機Coding。情況好點的話，最多我還會在草稿紙上進行亂塗亂畫，做一些簡單的設計和演算法。但是需求和設計是產品工程中最重要的兩個過程，如果處理不好那麼系統將會很糟糕。現在，我開發過程是按照公司體系進行開發，雖然項目的時間比較緊，難免出現文檔和系統脫節。但至少比以前的混沌開發好上幾倍，而且現在的做法還具備可跟蹤性。如果返工的話，也是局部性的，如果設

今天，只有一個人過節日。想起從前，在節日裡，可以喝紅酒，吃火鍋，可以吃很多辣香的東西！說起來，還一幕幕清晰可見。真有點留戀以前沒有珍惜過的充實生活！或許人就是這樣，有理想，自己就會去拼搏。為了理想，可以放棄一切。如果理想實現了，那麼就不會再去珍惜，等失去的時候又會屢屢想起！雖然很多事情可以放棄，但放棄的過程並非自己想象中那麼簡單。曾經傷害過那麼多人，使自己膽怯地不想再涉入這個領域。雖然猶豫的心理還總佔據著。我選擇我自己要走的路，沒有什麼好說的。自己的路上，雖然不平坦，但偶爾也有美景，就象昨天的昨

從學校畢業後，從進藍芒工作整整一周年了。在blog裡留個記號。2005.8-2005.10   藍芒科技               Bluelight4.0                線上主機網域名稱系統2005-11-今          Microlink  Xia'men   ITPro                       SharePoint與Office整合                             Microlink  Xia'men   SEP     

    門面模式要求一個子系統的外部與其內部的通訊必須通過一個統一的門面(Facade)對象進行。門面模式提供一個高層次的介面，使得子系統更便於使用。    Facade Pattern的原理我也不多介紹。這些原理在網上資料也比較齊全，分析也比較深入。下面是典型的Facade

 一、需求和設計的理解對於初學者來說，編寫需求和設計，將面對很多問題，其難度不言而喻。所謂的難度就是不知道需求該寫些什麼，包含那些內容，寫到什麼程度，需求做到怎麼樣才比較合理。對於設計階段，設計則要如何和需求銜接，如何從需求來做出設計。而對與從事多年的IT 的人，他們對編寫需求的難度又是另外一方面，他們所謂的難度是如何去挖掘需求，如何去糾正潛在的錯誤需求，客戶說出的需求未必就是他們想要的。開發需求的難度還在於確定需求的範圍，按需求的優先順序別來劃分需求。所以需求在前期可能只能覆蓋20%-30%，

大多數的大型業務系統都是依據3層模式。最上層為UI層，其基於下層的業務層。業務對象必須儲存到持久對象（資料庫），所以最底層為持久層。如果你想用純物件導向來實現你的業務系統，那麼你必須決定用哪種資料庫來儲存。下面有4中方案：1、物件導向資料庫（OODBMS）。2、O/R(Object/Relational)資料訪問層和關聯式資料庫。3、資料訪問層加關聯式資料庫。4、O/R資料庫加資料訪問層（沒有任何實踐經驗於O/R資料庫，故不做討論）。前3中方案圖如下：這裡將在下面的系列中介紹如何設計和理解O/R

SharePoint是什麼? SharePoint Portal Server和Windows SharePoint Services的區別? document library是什麼? meeting workspace是什麼? document workspace是什麼? web part是什麼? document library和form library的區別? web part zone是什麼? 怎樣進行SharePoint安全管理? 如何開發web parts? 網站定義是什麼?

    Strategy策略模式是屬於設計模式中 對象行為型模式，主要是定義一系列的演算法，把這些演算法一個個封裝成單獨的類。   

Learning Platform介紹，Learning

WSS物件模型：1、訪問資料庫使用對象：SPVirtualServer、SPContentDatabaseCollection、SPContentDatabase2、訪問外掛式主控件使用對象：SPGlobalConfig、SPWebServerCollection、SPWebServer3、訪問網站集合資料使用對象：SPGlobalAdmin、SPVirtualServerCollection、SPVirtualServer、SPSiteCollection、SPSite4、訪問列表使用對象：S

 Declan Galbraith - Tell me whyIn my dream,children singA song of love for every boy and girlThe sky is blue and fields are greenAnd laughter is the language of the worldThen I wake and all I seeIs a world full of people in need(Chorus)Tell me

翻譯來至《Understanding WF in WSS and Office 2007 v1.doc》作者：David Chappell, Chappell &

PetShop4.0是一個很好的源碼學習工具，其內部提供了很多設計模式（Design

作者簡介塗曙光，微軟（中國）有限公司專業解決方案部技術專家，曾獲得兩次微軟SharePoint Portal Server最有價值專家（MVP）稱號。專註於Microsoft Office

翻譯來至《Understanding WF in WSS and Office 2007 v1.doc》作者：David Chappell, Chappell & Associates（鼎鼎大名）翻譯片段，全文請查看：http://www.davidchappell.com/blog/index.html前面已經描述過， WF運行時引擎可以宿主於任何Windows應用。在這方面WSSv3表現最為明顯。引擎的宿主上包含一個或多個工作流程範本,

如果你在前期就知道了結局，而你又不得不按照違背自己的意思去做你會感覺很鬱悶,當然那時候的你，並不會感覺到什麼當你說明了事情並非這樣，而不被人理解"因為需求是這樣的，不是那樣的"最後,終於大白真相了，客戶是那麼的奸詐,明明是那樣的需求，怎麼現在又跑出這樣的需求是的,需求是無止境的，你就得這樣，因為客戶是上帝．屁話.如果在前期就把需求範圍明確了，那就不會鬱悶了客戶喜歡模糊的需求,我可不喜歡，當然我們得挑明的說結果我們沒有說,吃虧的還是我們以後一定得在重要的方面留個記號，有此為證現在也只能那樣了...