To target VS 2005 using the older .net framework, try Jomo's work around - http://blogs.msdn.com/jomo_fisher/archive/2005/04/22/410903.aspx
Also check out Robert's workaround, although it's not working for me:
http://www.longhornblogs.com/robert/archive/2005/06/03/14156.aspx
http://www.hanselman.com/blog/BuildingNET11ProjectsUsingVisualStudio2005.aspx
The MS supported version is coming soon:
http://blogs.msdn.com/msbuild/archive/2005/11/09/490817.aspx
http://blogs.msdn.com/clichten/default.aspx
每日我們在外努力，沒有良好的品質，沒有良好的服務做後盾，
一切效果會打折扣，對客戶的承諾都會跳票，我們便成口才一流、
品質二流、服務三流的公司。
四、如果
（1）有罵沒有稱讚、有懲罰沒有獎勵。
（2）對企業有利的，不立刻行動。
（3）經常把"再看看"、"再研究"掛在嘴邊。
那麼，我也只能偷偷的說，你不是一個稱職的老闆。我不能多說，畢竟你還是我的老闆。
誰都會寫程式碼！幾個月的編程經驗可以讓你寫出「可運行的應用程式」。但在開發團隊的運行模式下，以最有效率的方式編碼、能被小組成員順暢承接的程式碼就必需要下更多的功夫！
要知道，大多數程式設計師在寫「可運行程式碼」，而不是「高效率程式碼」。寫高效程式碼是一項藝術，必須靠紀律及學習來實踐。建立一個高效率、有默契的開發團隊更需有一定的規範及標準流程。
想要讓開發出來的程式碼穩固且容易維護，除了有必要適當地採用設計模式 (Design Patterns) 之外，也有必要採用編碼原則 (Coding Guidelines)，做為寫程式時依循的準則。設計模式是在設計階段進行的，主要由系統設計者 (System Designer)負責，所以和程式員的關係比較不是那麼密切。至於編碼方針，就和程式員的關係相當密切了。
程式碼命名及格式規範的目的為建立開發團隊的默契以及效率。檢視一篇與自己撰寫風格相同的程式碼不但能減少無謂的猜測，也能快速暸解程式碼，立即進入程式撰寫的狀況。
輔助工具
在Google搜尋keyword :: "Code formatter, code beautifier"，你可找到一票自動化的輔助工具。對C#來說，最重要的編程方針是美國微軟MSDN網站上的Design Guidelines for Class Library Developers。reSharper則是目前我們使用的自動化工具。
將近三十年的財經新聞採訪經驗，讓我有機會接觸無數的台灣企業名人，近距離觀察體會他們的言行、經營奧秘。但是唯獨現在的台灣首富郭台銘，因為他竄出檯面太晚，我已經退居幕後，一直沒有機會一見。
也因為如此，許多的疑問，一直在我心中繚繞，鴻海的擴張動力及速度，為何如此巨大且快速？遠看像個獨裁者，而獨裁者又何以能有效統治龐大的鴻海帝國？這是個以速度取勝的公司；而他內部快速膨脹的團隊，又何以能手眼協調，有效運作？郭台銘應該是個高效益的經營管理者，而他的經營奧秘何在？
有亞歷山大大帝般的企圖心
這一連串的疑惑，隨著一個偶然的機會而解開，鴻海內部流傳的一百餘則「總裁語錄」，道盡了一切，我確定了一件事：郭台銘是台灣五十年來僅見的經營奇才，魄力與能力都是我淺薄的識見中的第一人。先談魄力，魄力解釋了鴻海的快速成長、永不停息。語錄第一二八則：「成長來自什麼∣胸懷千萬里」；語錄第一三○則：「心胸有多大、舞台就有多大」；語錄第二十二則：「真正的英雄，是戰死在沙場的人，而不是來領勳章的人」；語錄第一一五則：「除非太陽不再升起，否則不能不達到目標」。
從這些話，我看到古代亞歷山大大帝的身影，郭台銘用想像構築了他的企業舞台，台灣只是起點，他的隊伍要到達他所能想像的地方，而且一定可達成、要達成，否則絕不終止。大多數的台灣企業家，以台灣做舞台，也以台灣為限制，但郭台銘心中無懼，以意志為方向，他的舞台是世界！
能力來自於細節的累積
看起來戰鬥也是他的樂趣，崇拜馬革裹屍的英雄，這說明了「鴻海再大，仍太小」是郭台銘心中沒說出來的話。或許在最近的電視訪問中，他提出「鴻海上兆，我就要走」的退休預言，是他可以接受的目標。
「魄力」與「想像力」只是起點，「能力」則是郭台銘帶領鴻海走到今天的關鍵。
語錄第一二八則：「心思細如絲」，是郭台銘能力的原點，一切從細節出發，把細節做好。語錄第十八則：「關鍵（KPI）：魔鬼都藏在細節裡」；語錄第一三四則－「對事情的觀察：望遠鏡／放大鏡／顯微鏡」。在整個郭台銘經營語錄中，我們處處看到他從細節著墨，也仔細研究細節，親力親為帶領鴻海團隊追根究底每一個細節的痕跡。
不論是企業經營四大管制：工管、品管、生管、經營到生意型態，到PC產業技術問題，到HR人資管理，他都有他獨到的觀察和洞見，我們不能想像以他這樣規模的老闆，竟然能如此清楚每一個作業流程的細節，唯一的解釋是：鴻海成長太快，他脫離黑手老闆的時間很短，親力親為每一項細節的經驗猶新。
拆解經營問題中的十面埋伏
一旦老闆知道每一個細節，組織裏就沒有任何模糊的空間，工作者更沒有打混的空間。這就是鴻海讓外界感覺一切上緊發條的原因。追根究底問細節，只是郭台銘的態度，其方法則是「拆解」與「簡化」。他把每一件事、每一個流程都予以拆解。例如，語錄第六十則：解決問題九大步驟。第十三則：系統七分類。第六十一則：生管系統七階層次。第六十六則：主管每天要做的四件事。第十九則：「桌子的顏色」，更清楚看到郭台銘的拆解事物的邏輯，他認為：桌子的表面是我們看到的顏色，但要真正瞭解，只有把桌子拆解才知道。
問題、流程經過拆解之後要再簡化。語錄第五十五則：簡化的對象包括：客戶、料號、流程、管理策略與組織架構，簡化的方法則是簡單化、合理化、標準化……任何事情經過簡化後，就變成響亮的口號。例如：第一二○則：成功的途徑：○抄、○研究、○創造、○發明。再如：第一三二則：三對—選對的公司、選對的人、做對的事。
仔細想想這不就是尋找Best Practice（最佳實務）的過程嗎？鴻海不只在流程上如此，在觀念、思考、方法上也都要有共識，這或許是「總裁語錄」的最大功用吧！
獨裁，卻害怕成功！
郭台銘用「細節、拆解、簡化」最後建構標準化的制度，而落實制度的基本精神則是紀律。第九十五則：工廠管理的理念∣走出實驗室，沒有高科技，只有執行的紀律。第一一五則任何事都要誓死達成任務。至於郭台銘本人，則像是政治學上的獨裁者－「哲君」。第一一七則：領導者須有獨裁為公的決斷勇氣。郭台銘的指令，貫穿鴻海的每一個角落。每天主管向郭台銘的報報，被稱做「面聖」、「上朝」，而這個哲君，則帶領鴻海一再創造奇蹟，攀登高峰。
不過在語錄中，我們也看到郭台銘的害怕：他害怕成功。第一三九則：成功是很差勁的導師，它給你無知與智慧，成功是失敗的媽媽，輕而易舉的成功則是事業大忌。這說明郭台銘居高思危的態度。
郭台銘也考慮到接班的問題，第二十四則：接班人三要件：品德、責任心肯做事、太聰明者則婉拒。但是鴻海的接班布局似乎只在「條件說」，但真命「太子」尚未出現。
這或許是鴻海最值得觀察的未來。如果郭台銘真的退休，沒有哲君的帝國會如何？郭台銘的語錄提供了過去與現在的解答，但未來，要時間來解答。
David Berlind‧唐慧文 2005/01/07
全球資訊網上的聯合供稿(Web syndication)技術種類繁多。一如諺語所述的情況：標準最棒的地方在於標準太多了。
若真要把RSS 1.0、RSS 2.0(其實接續的不是RSS 1.0版，而是0.94版)、Atom和其他林林總總沾得上邊的網際網路聯合供稿技術理出個頭緒，恐怕需要做碩士論文級的研究。如果在規格的層次上就有問題、而且沒辦法解決的話(依我之見有些衝突是被新聞界誇大了)，那麼我們怎能指望第一線的應用會變得容易上手？本文將討論使用者設法把現有技術湊合著用的情形。
我碰到的一個RSS 2.0問題是，網路出版者通常使用不同的慣例，來刊登以RSS(真簡單聯合供稿)系統傳送的資訊。雖然這種彈性正是RSS 2.0最棒的優點之一，但如此一來，把多重RSS feeds標準化以便匯整呈現的負擔，就轉移到閱聽者這一端。儘管終端使用者應用程式(包括RSS閱讀器在內)通常內含人工智慧，可補救所處理檔案格式紊亂不一的問題(這也意味處理RSS的應用軟體前景相當不錯)，但我懷疑RSS會不會也證明軟體商要兌現諾言極為困難 -- 他們承諾提供為平常人開發的軟體，讓技術生手只用游標和滑鼠點選和拖曳，也能打造出複雜的、交易性(transactional)、伺服器端的應用。
畢竟，RSS是當今最能展現可延伸標示語言(XML)對普羅大眾有何用處的範例，也象徵大多數人與XML最接近的接觸。基於RSS的人氣日盛，大有可能演變成所有資料(不論結構嚴謹或鬆散)賴以採集的主要方式 -- 不論用途僅為瀏覽最新的網誌(Weblog)更新內容、檢索電子郵件(嘿，那不就終結垃圾郵件了嗎？)，或是透過複雜的工作流程傳遞交易資料。就此而論，RSS也可能被當作「點選式程式設計」(point-and-click programming)的一大試金石。
為了鼓勵透過ZDNet網誌領域進行線上協同作業，我們已建立一個內部的Wiki。日後或許內容會更豐富，但目前我們的Wiki首頁比較像是共享的書籤陳列室。我倒是建了一個次級網頁，展現出多重使用者系統的威力：在上面可把我所屬工作群組必須追蹤的網誌一覽無遺。我用Twiki標題外掛程式把以RSS為基礎的聯合發稿內容匯整到同一網頁，基本上該網頁相當於在網誌領域的一個角落設立入口網站，以便我們觀察我認為不該遺漏的網誌。我稱之為我們的雷達。
我加入擷取自Robert Scoble、Jonathan Schwartz、Tim Bray、Bob Frankston、Slashdot、Groklaw等網誌的內容，不久之後，ZDNet.com副總裁Stephen Howard-Sarin又在這個網頁添加了一些，取自於Dan Bricklin、Jon Udell、Dan Gillmor、Phil Windley、Doc Searls等人的網誌。儘管這還稱不上是「點選式伺服器端程式設計」，我認為已十分接近。
但我不滿意這個外掛程式預設的內容擷取格式，以及在網頁上呈現的方式。所以，為牽就我們的需要，我在外掛程式之外添加了一些選擇參數(optional parameters)，以確定最後顯示出來的網頁是純文字(為了效能起見)，而且只從各種內容來源擷取最新的五則標題。以圖示來呈現這類選擇參數、自動產生編碼，並且把程式碼嵌入網頁，這些正是我期待「點選式程式設計」能夠為我代勞的事，而不是凡事都得用硬碼(hard-coding)方式來做(我目前的作法)。
在Wiki普遍成為政治正確的作法之際，Howard-Sarin也在添加網誌內容時仿效我採用的格式。由於欠缺更簡單易用的工具，他只用剪貼方式把程式碼拷貝過來，然後提供不可或缺的替代品。對一群非專業程式設計者來說，能做到這種地步已經很不錯了吧？短短幾個鐘頭，我們兩人同心協力製作了一個入口網站，提供有意義的資訊，而且會隨每次網頁重新整理更新內容。現在，就等其他ZDNet使用者共襄盛舉，把他們喜愛的、不重複的網路內容丟進這個網頁即可。
可是，還有個問題。有些內容無法正常顯示，害得我耗費比原訂計畫更多的時間。比方說，Jonathan Schwartz網誌裡的每一篇內容，都以異於他人的方式呈現 -- 在他以XML為格式的內容中，每一篇不重複的網誌內容(稱為一個item) 都省略連結欄(link field)。大多數的內容，例如擷取自ZDNet的本文，都用連結欄來儲存通用資源識別碼(URI)，以直接連上個別的item(就本文為例，指的是一篇新聞報導，而不是網誌裡的一則日誌)。省略掉連結欄，Schwartz依賴GUID (全域唯一性識別碼，讀音「gwid」) 欄附帶的選項(稱為「permalink」)，來儲存常駐的連結，以連上個別的網誌文章。這麼做是有道理的，因為要跨越整個網際網路連上某則特定的內容，使用專屬的連結是你所能找到、最獨一無二的方法。或許你能想出別的辦法，但何必花這個腦筋呢？基於此理，幾乎人人都把導向自己每則內容的直接連結存在GUID裡。對許多人來說，這意味在GUID裡找到的資料，與在連結欄(若他們採用的話)裡尋得的資料，是一模一樣的。
這些很重要嗎？嗯，就我而言，我覺得很重要，因為我試著想出一種可輕易重複使用的外掛程式參數組合(用「點選式程式設計」術語會稱之為「物件」，但我要等到親眼目睹才會信以為真) ，來建置我們的入口網頁，而那套組合要能夠用同一方式對待本網頁所觀測的各個內容來源。如果某物件在「普通人用的點選式程式設計」現實世界裡只是偶爾才管用，那麼沒多久，一般人就會棄滑鼠投降。
參照TWiki文件編寫採用連結欄的範例，我開始嘗試用它來提供入口網站使用者一個可回歸原始內容出處的連結。這很合理，不是嗎？然而，一旦連結欄被省略，如同Schwartz網誌的情況，即便我在入口網頁上一一附上連結，也不過是死的連結。為了研究這個問題，我進一步探討RSS的弱點 -- 我不認為其他只為體驗網路聯合供稿威力的使用者必須探究得這麼深入。我發現，如果Schwartz的網誌把每則內容專屬的URI存進GUID的話(他是這麼做的)，那麼我就可以倚賴GUID的目錄把使用者導回內容的原始出處。就可重複利用的能力而論，我考慮把這種作法全面套用在我們監看的所有內容上。
以下這一段是RSS 2.0的規格範例，由此可說明連結與GUID未必相同，也證明我傾向採取的解決辦法是對的：
「有關<guid>s的一個常見的問題是與<link>s該怎麼區分，不就是同樣的東西嗎？沒錯，在內容系統裡是如此，但在其他的系統就不見得。在某些系統，<link>s是連上網誌篇章的permalink。但在別的系統，每一個<item>是全文的摘要，<link>s指向該文，而<guid>s則是連上該則網誌內容的permalink。不論在什麼情況下，都建議你提供guid，並儘可能讓它以permalink呈現。這麼做可避免匯整器重複擷取相同的item，儘管這些item可能因為有修改過而有所不同。」
以上是專家建議的最佳範例，無疑是大勢所趨，也隱約暴露出許多內容供應系統依循不同慣例的問題。這正是我遭遇的問題。現在，可重複利用性已被判出局，而我甚至還沒開始嘗試用滑鼠作「點選式程式設計」咧。就每一個我加進入口網頁的內容來源而言，現在我會先研究它的XML，再決定該用哪一套參數。
但GUID相對於link的問題，並不是我們面對的唯一挑戰。
有些內容供應feeds，像是Dave Winer的Scripting News，也丟出一個變化球。Winer的網誌文章不附標題。這是個麻煩，因為要建置含20多個出處、一目瞭然的入口網站，我們決定最簡單的作法便是只顯示item的標題，然後附上導向全文的連結(使用前文提到的item連結或GUID，視哪一種比較適用而定)。但是，就Winer的XML來說，能擷取的東西有限。沒標題可選，只能擷取其他三種 -- GUID、item的發表日期(pubDate)、或是item(敘述)的全文。但item的全文長度從寥寥數字到堂堂數段不等，沒道理拿它來當作超文字連結(hyperlink)。
如同Schwartz的網誌，Winer的GUID也是連上全文的URI。換言之，能供我們用來當連結的文字只剩下發表日期。顯然Mozilla.org對無標題item的感受和我們一樣。Firefox瀏覽器採用一種稱為Live Bookmarks的功能，用來追蹤RSS feeds；該瀏覽器在碰上無標題item時，為了產生可點選的內容連結選單，也提供發表日期作為連上原文的線索。事實上，在處理規格不一的RSS應用方面，Firefox的表現一級棒，就連碰上在同一網誌裡有的item附標題、有的又不附標題的John Robb頻道時，也能機動應變。把Robb的網誌加入Firefox的Live Bookmark後，產生的選單即顯示出Firefox從每一item就地選材，有的擷取發表日期，有的擷取標題。這印證前文所言，就網路聯合供稿而論，供應端所做的選擇，其衍生的後果一概由閱聽者這端承擔。換句話說，控制權從供應者這方轉移到內容出版者這方。值得注意的是，此現象似乎與全球資訊網的走向背道而馳。(基於Internet Explorer使用者眾多，和許多網站用Firefox無法正常顯示，以後見之明來看，即可驗證供應端總是會順應需求端來作調整。)
同理，再度驗證通常軟體會代使用者做複雜的決定和演算法，Dave Winer的網站內容匯整器也作了令人讚許的貢獻，就是把各式各樣的內容慣例標準化，形成單一介面，再透過該介面把源自不同頻道的文章攙雜在一起，按照匯整器擷取的時間倒序排列。比方說12點15分時，某頻道可能顯示出五則，但其中最早刊出的一則也許不比排在它前面、出自另一頻道的文章來得新。不過，不論是哪一則，都是根據終端使用者所在地的時區來顯示發表時間。網路匯整器可不可能自動判知終端使用者的時區，我不清楚；但就Firefox和Newsgator這類美國境內執行的RSS匯整器而言，是辦得到的。看出未來的成長空間了嗎？
起初，我暗地咒罵Winer竟然不附標題。但一旦開始追蹤Winer的網誌後，我就領悟到這種抉擇自有道理。他的網誌只是意識流似的日誌。人在思考時，會先下標題嗎？不會吧。Winer不會，也無此必要。他和別人的網誌之所以可讀性高，與附標題的新聞報導與眾不同，就是因為網誌就像日記一般。這些網誌有許多篇章是想到什麼就援筆立就，若是作者必須停下來先為每一篇定個標題，可能就跟不上奔馳的思緒。這些是特例。另一人氣鼎盛的網誌，作者是微軟的Robert Scoble，就不管每則篇幅多短，都一律冠上標題。以最近談微軟執行長Steve Ballmer評論蘋果iPod的那一則為例，標題幾乎與全文等長。如果他給網誌文章下的標題少一些，或根本不定標題，或許我們更能深入了解Scoble腦子裡的想法。
為了建置一套可重複利用的參數(以便別人只需剪剪貼貼即可)，我不得不緊盯著Winer的內容，我愈是瞪著它瞧，就愈發現自己掙扎於兩種選擇之間的取捨：該用發表日期作為我們TWiki架構入口網站的連結文字呢，還是乾脆把他的全文(儲存在各個item的敘述欄內)下載並顯示在我們的入口網頁呢？畢竟，我們內容顯示的程度僅止於最新的五則，而Winer每天定期刊出五則以上，所以若是列出一串發表日期，除了告知每一則何時刊出以外，提供的資訊聊勝於無。我們真正需要的訊息，是全文的內容為何。碰到Winer這種不附標題的內容，我們唯一的選擇，就是擷取全文(端視外掛程式允許的容量而定)。
事實上，一口氣完整的擷取(包括GUID、敘述、發表日期和某來源提供的其餘材料)，逐漸看來是最適合我們入口網站的通用方法。就這麼搞定。我總算可以回頭做我日常的工作了吧？哎，還不行。
誠如Winer告訴我的，那種作法可能也行不通，因為和許多網誌不同，新聞網站通常在每篇報導的敘述欄裡提供摘要，而不是完整的全文。更糟的是，就算也把敘述抓過來，我發現TWiki的標題外掛程式無法處理超文字標示語言（HTML）格式，而網路新聞幾乎清一色都用這種格式編寫。
這個實驗計畫就像舊時卡通裡會漏水的水壩。就在你以為所有的漏洞都堵好了的時候，另一處漏水又泉湧而出。最後我只好許願，但求聰明人發明只要點選一下就可解決問題的辦法，就像軟體開發業者向來承諾的那般。只是，就現在的進步速度來看，我懷疑那可能要再苦等數年。
但本文仍算是一篇談論RSS優點的報導 -- 也附帶闡述RSS特有的彈性為什麼會讓企圖在亂中求序的人士(比方說軟體開發者)日子難過。畢竟，混亂本是網際網路的常態。
by Patrick M. Lencioni "Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so powerful and so rare..."
Kathryn Petersen, Decision Tech's CEO, faces the ultimate leadership crisis: Uniting a team in such disarray that it threatens to bring down the entire company. Will she succeed? Will she be fired? Will the company fail? Lencioni's utterly gripping tale serves as a timeless reminder that leadership requires as much courage as it does insight.
Throughout the story, Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team. Just as with his other books, Lencioni has written a compelling fable with a powerful yet deceptively simple message for all those who strive to be exceptional team leaders.
有同好有一樣的困擾 - 如何使用自己的data logging軟體，因此寫了這篇來分享我的簡易改裝。 Background 雲豆子 MERCURY roaster 烘豆機的設計是使用自行開發的軟體，來：1. 操控風門/火力; 2. data logging/自動烘焙。 ...
