其他

整體來看Silverlight由2部分構成:Core presentation framework（下面簡稱core部分）和 .NET Framework for Silverlight（下面簡稱.net部分），前者是用C++編寫的SL的核心，後者則是用C#編寫的編程架構。是安裝了SL3之後，SL所在檔案夾中的dll檔案：agcore是Core presentation

難得寫篇和工作有關的東西，隨著WinCE6.0 R3（請看馬寧老師為我們第一時間帶來的Windows Embedded 6.0 R3開發初體驗）的發布，咱這一直想說不敢說的嵌入式UI架構終於可以隨便亂講了。作為一個早期使用者，此處我來貢獻點基礎知識，發個FAQ來讓大家有個印象：Q1：Silverlight for Embedded是什嗎？A1：Silverlight for Embedded是一個在WinCE6.0

文章目錄 1.把大象關進冰箱裡問題2.3.語言特性和編程範式完全是兩碼事4.給10個按鈕改變顏色5.範式是認識世界的方法論 1.把大象關進冰箱裡問題面向過程：把大象關進冰箱裡：    把冰箱門開啟=>    大象放冰箱裡=>    冰箱門關上物件導向：冰箱.開門()冰箱.放入(大象)冰箱.關門()函數式：關進（冰箱，大象）: 

原型模式的意圖經常被誤解為複製對象，本來我覺得設計模式完全無必要（也不太敢）寫任何文章，GoF書裡寫的清晰準確，還有無數例子，但我看到過無數文章把原型模式徹徹底底地變成了從已有對象方便地複製一個新對象，所以決定趟趟渾水也來白話一篇，說的不對的地方歡迎大家拍磚，猛拍，狂拍，往死裡拍……在我自己廢話之前，還是先抄GoF，意圖：用原型執行個體指定建立對象的種類，並且通過拷貝這些原型對象建立新的對象。什麼意思呢，我覺得應該把這個短語裡面的形容詞部分去掉：指定種類，建立對象。這樣就容易理解多了，這個模式的

在網上常常能看到文章講物件導向的三大基本特徵"繼承"、"封裝"、"多態"，我以為這是坊間流傳的最不靠譜的一個說法。本文先談談其中講到的一個特性：多態。多態是一個跟物件導向完全正交的概念，兩者之間可以說沒有任何必然聯絡。當然口說無憑，下面是我經過很長時間尋找到的一些來源比較可靠的資料對多態的說法。最早可查證的關於多態的說法是一篇叫做 Fundamental Concepts in Programming

今天來談談C#語言中函數的設計問題——這是除了效能問題之外，C#語言設計哲學中另外一個嚴重的問題——不必要的臃腫。C#函數總共存在以下４類問題： 1. C#函數沒有抽象性函數並非程式的基本元素，並不反映程式的關鍵抽象。資料區段儲存程式執行狀態，代碼儲存執行指令？函數算什麼，壓棧幾個元素然後改變EAX寄存器的值嗎？  2. C#函數沒有通用性絕大多數程式沒有函數的設計需求，不會實現函數。3. C#函數的實現效能比較低下　　 a.函數調用的背後是壓棧，然後由EAX傳回值，棧的操作效率遠遠低於寄存器 

原文：Introduction to Model/View/ViewModel pattern for building WPF apps http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx作者：John

文章目錄 基本概念定義文法——BNF/EBNFLL與LRLR(1)狀態機器構建下篇：LR(1)分析過程 討厭英文的同學，請點我碰碰運氣

隨著時代的進步，說.net就是拖拖控制項的人越來越少了，作為一個抱有"就是喜歡拖控制項"想法的人，我還是不得不研究一下完全沒有IDE的情況下怎麼生存。 國內的大部分無知而淺薄的".net程式員"，完全是被橫行的盜版IDE慣壞了。VS的確提供了一條產生和組織程式的捷徑，但是它並沒有把正路堵死。 這裡我就來說說如何像編寫linux程式那樣編寫.net程式 俗話說巧婦難為無米之炊，即使我們想要像Linux程式員那樣寫程式，首先我們還是要下載一套最新版SDK 最新版 Microsoft Windows

代碼寫的比較粗糙 各位看官湊合著看看兩層迴圈搞定 代碼寫的不算物件導向 用了class但用在資料結構上了話說我真是老了 一個非遞迴搜尋寫了一個小時CodeCode highlighting produced by Actipro CodeHighlighter

OAuth2是基於HTTP的認證API，一般與OAuth2搭配的API也是基於HTTP的REST風格API（比如新浪微博和github），很多人一定想過是否可以直接從瀏覽器端調用REST API。我最近做了一些這方面的研究，因為OAuth2中有secret key的存在，所以純粹的用戶端是不行的，但是服務端僅僅參與認證過程，由瀏覽器去調用REST

文章目錄 語義比UML重要1000倍一些其它的模式和誤解結語  太久不寫部落格，都不知道咋開頭了。主要是現在這設計模式的文章太多，而且各種爛各種曲解，看的人心煩，煩到忍不住想自己寫一個系列把它們說清楚——但是呢，轉念一想，我寫的再怎麼清楚能有GoF清楚呢，怎麼能有GoF的影響力大呢，GoF明明白白地擺著，還有這麼多人亂搞，我又能做什麼呢？所以想了半天，我覺得就寫一篇文章來吐槽好了。 -

文章目錄 對象與類分類與歸類物件導向設計設計實踐

最近微博上看到一些關於電子書的討論，尤其是這條微博裡的一些言論，頗有感慨，所以作此篇短文。微博評論中不少人哭喊叫窮，譬如以下(名字隱去)：作為準碼農表示經常下載pdf，專業書真不便宜啊讓我們這群買不起書的學生怎麼活偏向於支援保護著作權, 但對此還是表示中立. 盜版是很不該,

(很多同學看到大段的數學公式就會發昏，我以人格擔保，這裡面的數學公式簡單的不能再簡單了......)transform的原理是電腦圖形學中的2D矩陣變換，在開始之前，首先來複習下一個簡單的線性代數知識：矩陣與向量乘法。太複的用不到，只需要3維向量與3x3矩陣的乘積：接下來我們來說說transform跟矩陣乘法的關係，我們的任何一個html元素渲染完成後可以得到一張位元影像，把這張位元影像上所有的點都做一次矩陣運算，將得到一張的新的位元影像，這就是transform的基本含義。首先來看最簡單的tr

文章目錄 margin collapsing現象margin collapsing與方向無關margin collapsing僅僅發生在BFCmargin collapsing可能跨元素margin collapsing不能跟padding(內邊距)摺疊margin collapsing不能跟跨越BFC 讀過李松峰老師翻譯的新書中《CSS設計師指南（第3版》的外邊距疊加部分(

文章目錄 MODELSVIEWSCONTROLLERSEDITORS 原文：http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf譯者：winter(http://winter-cn.cnblogs.com)譯註：本文是MVC最初提出並確定概念名稱的論文MODELSModel表示知識，一個Model可以是一個單獨的對象（真沒意思-

面試中純粹考演算法的問題一般是讓很多程式員朋友痛恨的，這裡分享下我對於解答演算法題的一些思路和技巧。一般關於演算法的文章，都是從經典演算法講起，一種一種演算法介紹，見得演算法多了，自然就有了感悟，但如此學習花費的時間和精力卻是過於巨大，也不適合在部落格裡面交流。這一篇文，卻是專門講快捷思路的，很多人面對演算法題的時候幾乎是腦子裡一片空白，這一篇文章講的就是從題目下手，把毫無思路的題目開啟一個缺口的幾種常見技巧。（一）由簡至繁事實上，很多問題確實是很難在第一時間內得到正確的思路的，這時候可以嘗試一

加引號是因為我不知道是否真是微軟面試題。題目是這樣的： 有一車在某無限長公路上行駛，其起始位置和單位時間內速度均為有限大整數（正負不確定）， 現有一儀器，在每一時間單位內可以探測1次車是否在指定位置，求一方法能在有限時間內求出車的速度和初始位置。 答曰：解此題目分為兩個步驟，第一個步驟，探測到車一次第二個步驟，求出車的速度和位移。 先解答第一步驟， 顯然，假設車位移為s，速度為v，在時間t時車的位置必定為

文章目錄 緊湊性抽象能力動態性文法噪音結語 最近微博上各路大牛又開始爭論語言問題,引發了我寫水文的衝動,遂寫篇文章談談我的看法。首先我的觀點是，對程式設計語言客觀合理的評價不該是個A比B好還是A比B差的問題，我認為程式設計語言應該從以下幾個特性去評價：緊湊性所謂緊湊，就是有限的文法和運行時機制所容納的特性，緊湊性是一種優點。在這一點上做得最NB的是Lisp，它的文法定義極度簡單，以下幾行就是Lisp的全部文法了：s_expression =