其他

這幾天總是加班，忙的暈暈的，早上同事告訴我一個新聞吉林化工廠發生劇烈爆炸 產生強毒氣3公裡戒嚴，讓我嚇了一跳，因為那個地方離我們這裡也就是幾公裡而已，後來想想也挺有趣，雖然同在一個城市，但是這麼大的事故同事竟然是通過網路獲得的，而我卻是通過同事獲得的，由此想到了團隊的開發，其實溝通是最重要的，有些東西需要從互連網獲得，而有些也許問問隔壁的帥哥，也許就會更好，所以團隊開發中的溝通中傳統與現時都是有用的，只要有效就好。

昨晚已經和老婆安排好5.1的行程，希望可以美美的睡上幾天，5.1可以好好的休息一下了。但是今天早上客戶打來電話，說需求有變化，真是搞得一團糟。剛開始的時候，大家都有點不知所措，畢竟這個需求的變更對系統的影響是比較大的，更讓大家感到鬱悶的是這個變更就是我們以前建議他們採用的一個方式，可是客戶以前看過別的公司的軟體，非讓我們參照那個模式進行開發，我們怎麼說都沒有用，反而覺得我們的建議很差勁。但是讓我們害怕的就是這個致命的需求變更，大家的抵觸情緒很強，關鍵下午就要放假了，心思早都飛跑了。但是牢騷歸牢騷

先談幾個技術問題： 1：先來一個技術問題,今天在修訂系統的程式中發現一個問題,就是需要需要遍曆Excel中Chart的的ChartType,查看了一下協助,只能使用Enum

前些天看了《道法自然》這本書，感覺還是相當不錯的，讀書的筆記也記在了公司內部的網站上，其實物件導向這個東西是一個循序漸進的東西，急不得。在和同事們聊天的時候突然發現了這麼一個問題，就是在《道法自然》中根本就沒有提到資料建模的問題，因為書中的項目是一個FlasUI，我認為是一個類庫而不是作者所說的架構的東西，這個東西是不需要資料建模的，所以自然也就沒有提到。但是在我們真正的開發中，資料建模是很重要的一環，我想我們很多人的程式多少都是需要資料庫的吧。因此，我想提醒大家，在看這本書的時候，一定要將資料

繼承已經是一個古老的話題了，不過最近又在一些地方看到有人討論它，加上自己也有一些想法，因此形成了這篇文章。繼承好不好？經典的OO理論說：繼承是物件導向的三大基石之一。現代的OO理論說：組合優於繼承。這兩種說法顯然是彼此衝突的。如果組合優於繼承的話，那麼為什麼組合沒有取代繼承成為OO的基石呢？哪一種說法更有道理？對這個問題，簡單的說哪個比哪個更好其實是沒有多大意義的。我們應當從技術發展的曆史角度去看，這兩種說法各自是在什麼時期產生的，它們形成的背景是什麼，才能對此問題有一個更加深刻的理解。物件導向

最近在自己的項目裡嘗試使用了WPF，說實話，感覺並不好。這裡想談談目前碰到的最主要的問題，即：Grid指定儲存格的設計方式並不合理。回想一下我們在網頁裡是怎麼指定儲存格的。文法大概是這樣：Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--><table>    <tr>        <td></td>  

ROR

問：哪家公司最希望把瀏覽器端做大做強？答：是Google、是Mozilla、是Adobe，但總之，不會是微軟。 問：為什嗎？答：一言以蔽之，瀏覽器如果過於強大的話不符合微軟的戰略利益。 其實這個道理想一想就明白了。如果什麼事情都可以在瀏覽器裡搞定了，那使用者還會在意下面是什麼作業系統嗎？如果別人開發出了基於瀏覽器的、又好用又便宜又不用安裝維護的Office，那麼MS

UML已經誕生有十幾年歷史了。但是從現在的種種跡象看，UML非但沒有流行起來，反而有漸漸從開發領域隱退的跡象。 在過去的幾年，主要的出版商（Wrox、Manning、Orielly、Apress等） 幾乎沒有再出版什麼關於UML的專著，而國內也只看到一本UML大象書。出版界似乎對UML失去了興趣。UML圖在一些技術書籍中仍然存在，但通常只是作為類結構的輔助說明，佔有的比例非常之小。在各種技術部落格、論壇、使用者組，也鮮見有人討論UML。如果要說明某些技術概念，我發現絕大多數人寧願直接給出代碼。 

我們的系統需要實現這麼一個功能，即以矩陣的形式顯示使用者權限分配的情況。最終的顯示效果如下：這個功能實現起來不是那麼容易。當然，要為DataGrid動態添加列很簡單：只要知道所有要添加的列，產生一堆DataGridColumn再放到一個數組裡就好了。但問題是，DataGridColumn只能簡單的指定一個itemRenderer，那麼這個itemRenderer如何知道自己應該屬於哪一列呢？答案在於itemRenderer這個屬性的類型。它不是一個簡單的資料，而是一個要求實現了IFactory介

我們知道，XAML中實際上是可以放置任何對象的，而系統將按照如下的規則管理嵌套的內容：1. 如果對象實現了IList，那麼嵌套內容將通過IList.Add添加到父物件；2. 如果對象實現了IDictionary，並且元素用x:Key指定了索引值，那麼嵌套內容將通過IDictionary.Add添加到父物件； 3. 如果只有父物件用ContentPropertyAttribute聲明了內容屬性，那麼嵌套內容將被賦值為到該屬性。

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 RIA（Rich Internet Application）為何而產生，它的意義何在？流行的說法是：為Web應用提供豐富的操作體驗，提高系統的友好性云云。這種看法不能說錯，但是我希望從另一個角度來理解：

我們在項目中使用了Silverlight

客戶是垃圾。客戶不專業。客戶連需求都說不清楚。好吧，今天又看到了這樣的文章，這回我倒是想說點什麼了。撇開軟體這個行業不談，在其他經濟領域，我們這些開發人員也是客戶。大到房子、車子，小到電腦、手機，甚至一隻牙刷，一塊肥皂，在日常生活多數情況下我們自己也是掏錢購買消費品的人。那麼我想問一問了，在這麼多消費領域，有哪一個廠家要求你作為使用者自己提出產品需求呢？就算你自己能夠提出需求，你敢保證只要廠家嚴格按照你的需求去蓋一間房子，或者製造一輛車子，造出來的東西一定就是自己想要的嗎？如果購買任何消費品之前

關於對Silverlight進行國際化的方法，以前已經有過不少文章，我瞭解到的比較詳盡的應當算是TerryLee的這一篇（http://kb.cnblogs.com/page/42913/）。正如這篇文章所指出的，Silverlight對國際化的支援存在不少小瑕疵，不過我最無法接受的問題是文法實在太過冗長：Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-

看了老趙的 我的TDD實踐：可測試性驅動開發（下），我認為這種開發方式並無問題，不過我感到奇怪的是何以老趙會認為用TDD來完成這個工作就會顯得尷尬？下面我用TDD的方式來完成同樣的工作，讀者可以自行比較和老趙的方法有何區別。首先需要說明兩點：1. 我不熟悉ASP.Net MVC，自己的機器上也沒有裝此架構，所以代碼僅作為示意，並未編譯測試，大家能明白意思就好；2. 我不能說自己的方法一定是正宗的TDD，

不知道是不是Silverlight社區根本沒有這個需求，人家Flex Style Explorer已經出來N年了，Silverlight這邊還找不到一個對應的工具，難道大家全部手寫介面都沒有一點怨言？我們在上個項目中使用了Silverlight，但是大家知道Silverlight現在那個設計器根本只能算文字編輯器，沒什麼可視化功能，我們在調整介面的時候哪怕只修改一個像素，都要重新編譯運行程式才能看到效果，時間一長實在是苦不堪言。剛出來的Expression

我對Silverlight的布局系統一直感到不滿，原因無他，太過羅嗦爾。它靈活是足夠靈活了，但對於介面布局並沒有提供一個簡潔的表達機制，使得即使非常常見的介面也總是產生一大坨又臭又長的XAML，寫得累，看的人更累。特別是和競爭者Flex的布局機制比較，Flex可以說既靈活又簡單，Silverlight則是既靈活又麻煩。Silverlight裡面常用的版面配置容器幾乎都可以挑挑毛病：Canvas：只支援絕對座標布局使得Canvas在應用程式布局方面純粹是個雞肋，要求稍微靈活一點的介面就派不上用場了

為了說明這個問題，假定我們需要實現一個具有特殊功能的按鈕控制項。編寫Xaml檔案如下：Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--><Button x:Class="TestWpf.XamlButton"    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 

假定我要用Silverlight類庫實現一些通用控制項，然後在應用程式中引用這個控制項陳列庫。當然，控制項通常也要訪問其他一些第三方或開源的開發包，例如Silverlight Toolkit。於是這個項目的依賴關係如下： Silverlight Application => Silverlight Control => Silverlight Toolkit。在Visual Studio中建立好項目之間的參考關聯性：  然後在類庫項目中建立一個簡單的控制項，比如：  Code