其他

在昨天的博文《WPF/Silverlight的資料繫結設計的真糟糕》中，分析了三大應用情境下WPF/SL下綁定的缺陷。我的應用程式中有95%以上（甚至99%以上）的綁定都屬於那三種應用情境，因此無法接受WPF/SL繁瑣的綁定機制。罵不是目的，想辦法解決問題是駭客精神的所在。知道缺陷之後，就可以來彌補。剛才花了兩個小時時間用擴充方法寫了一套新的WPF/SL綁定機制。本文只是一份簡單的草案和思路探索，可以證明了這種機制的可行性。最近時間緊張，暫時還無法給出一份完備的解決方案，有興趣的朋友可以沿著本文

記得在很久以前，部落格園上一個哥們抱怨.net的源碼寫的太爛，到處都是switch，我當時就做過一個測試，證實了switch比if效能高許多。今天又看見這個話題，呵呵，那就再做個測試吧。代碼: CodeCode highlighting produced by Actipro CodeHighlighter

沒有最好的架構，只有最合適的架構。循證架構是《Expert One-on-One J2EE Development without EJB》一書中推崇的架構思路，用俺們的話說就是摸著石頭過河，找最適合自己的架構。俺現在soho，大活不多，小活不斷。我的工作具備以下特點：（1） 根本沒摸清楚需求的時間。需求都是從原型到Demo到版本1到版本2探索出來的。經常需求變化非常大，因此，必須以敏捷方法為基礎；（2） 一般沒多少資料需要儲存，頂多百萬級；（3）

同樣的演算法，為什麼會有數量級的效能差異？問題起源於幾個月前與一位網友的探討。這位網友在寫婚紗摳圖程式。一般來說，婚紗攝影的映像都較大，甚至大至幾千萬像素。這位網友使用C#開發，他的問題就在於效能。當時建議他使用XNA開發，但問題又出來了：載入一副映像的時間竟需要好幾秒！而我自己寫的C#載入幾千萬像素映像及映像轉換操作，都是瞬間完成。為什麼會有如此大的差別呢？這就是本文要說的。問題主要處在程式的局部性和快取命中上。我們把映像類抽象一下：Bitmap {    

文章目錄 6.3.1 BCL——基底類別庫6.3.2 FCL——架構類庫6.6.1 程式集概述6.6.2 運行程式集 .NET架構本書是一本講解.NET技術的書籍，目標讀者群也是在.NET架構（.NET

        飛林沙 在《for和foreach，N個人N種結論的選擇》一文中通過例子測試了 for與foreach的效能。這篇文章重點探討下他那個測試本身。        其實那個測試本身就是一個錯誤的測試。        為什麼這樣說呢？讓我們來仔細分析，為求簡單，只分析迴圈體內為空白的測試。         原測試代碼： Code highlighting produced by Actipro CodeHighlighter

我對金色海洋的“架構”的最大批評是它的緊耦合。有沒有可能即便捷、又松耦合呢？先整理下海洋的目前需求：（1） 盡量用滑鼠拖拉，操作盡量簡單（2） 要整合許可權管理，不同的許可權看到的項不一樣，能進行的操作也不一樣（3） 要整合驗證（4） 要有一個TreeView類似的控制板（5） 要有一個List模式的項列表，要有分頁（6） 要有一個DetailList或FormView模式的單項查看、修改、插入的東東（7） 強大的搜尋選擇框（8） 客戶需求發生變化了，要能夠很方便的更改在此基礎上我再加幾條：（1

當你想要快速的開發系統原型，用於示範功能、探索需求、消除風險時，用db4o吧；當你的程式的資料量不算特別大，而又想最快的提高開發速度時，用db4o吧；當你不想在程式的可配置資訊的儲存、解析上花費時間時，用db4o吧；當你不懂sql也不想學sql時，用db4o吧。Db4o是對象資料庫，有java和.net兩個分支。這裡沒有sql，沒有表，一切都是原生對象。官方網站對Db4o的描述是：•完全原生於Java和.NET•100% 物件導向,

51CTO編輯訪談錄51CTO的一位編輯在讀過《談談離職和跳槽》這篇文章以後，聯絡到了我。因為時值龍年將盡，想請我再談一些關於這方面的話題。我在想，權且當是自己對這些問題的思考和總結，就答應了這位編輯，如果還可以給其他人一些參考那就再好不過了。51CTO編輯：您提到過您不看學曆，不看年齡，在如今的簡曆上，很多人的簡曆造過“假”，這個現象尤其是在剛畢業的大學生和沒有多少工作經驗的程式員中，他們簡曆上很多技術都用到了“精通”二字。相信您對這兩個字應該已經有一些免疫了吧，那麼您看簡曆時哪些內容會讓您產

概要：·LINQ的實質是什麼·LINQ的問題是將複雜的問題簡單化，讓簡單的問題複雜化·LINQ喧賓奪主：- Lambda的抽象能力和描述能力大於LINQ- 擴充方法給程式員帶來的好處也是強於LINQ的·目前C#中的Lambda和擴充方法是半完成的半吊子狀態 上面這些觀點我以前的隨筆中也出現過，這次乘著討論LINQ的東風，詳細深入的討論一下。 （1）

在文章的前面，先定義一下，這裡談的“語言”（A）指的是“語言以及使用該語言可以很容易調用的基本類庫及可免費或低代價獲得的第三方類庫及開源類庫”（B）。在很多情況下談“語言”和談“語言”的選擇時的語境，都是指的B。選擇多語言混合開發的一個目的是為了使用其中某個語言的某個類庫或重要特性。比如，在OpenCV中，計算量不大的部分使用了很多的C++的STL中的資料結構和演算法，而不是自己用C去實現一份。我最近在研究Sift運算元。一份C#寫的Sift代碼處理一張600×600的映像的處理時間大概在一分鐘

類型不是類。大多數程式員都知道類是啥，卻根本不知道類型是啥。《標準答案-有多少人能分得清實值型別和參考型別?》中的答案是完全正確的。而《有多少人能分得清實值型別和參考型別?》這篇文章中的這道面試題是完全沒問題的，看似簡單但要真正弄清需要極深功底。因為大多數程式員都知道類是啥，根本不知道類型是啥。很多情況下，簡單的概念往往是最難搞清楚的。比如說，什麼是價格？什麼是企業？1991年諾貝爾經濟學獎得主科斯兩大貢獻之一就是回答“什麼是企業”（《企業的本質》）。====類型是一個古老的詞，這個詞的真正含義

對股份的簡單理解股份代表了對一個公司的 所有權，所有權包含了兩層意思，一個是 利益分配權（分紅權），一個是 投票權。先從一個簡單的例子來看，假設公司只有兩個人，這兩個人既是合伙人，共同創業開辦了這家公司，同時又是股東，各佔50%股份。假設當年公司除去包括工資在內的所有開銷後，淨利潤為100萬元，那麼 股東1 和 股東2 各享有50萬，即擁有利益分配權。假設公司面臨一項重大決策，此時兩個人都具有投票的權力，如果兩個人一個投A，一個投B，由於大家所持股份一樣，那麼就只能協商解決，因為誰也沒有決策權 

大道至簡，職場上做人做事做管理大道至簡，越是根源和基本的問題，道理實際上越簡單。關於如何做人、做事、做管理的書很多，我看得不多，但是我覺得這些書更多是側重技術和實現細節上的，而很少從人的思想和觀念去講。實際上，從根本上去說，如何做人做事是世界觀的問題，也是一個哲學話題。很多人和我一樣，已經到了快30的年紀，是需要去思考一下應該如何做人如何做事的，也需要一套簡單、有效、完整的體系來指導自己，而這套體系將是讓自己安身立命於這個世界的基石。職場上如何做人關於在職場上如何做人，我只謹記兩個字－－服務。你

臨近下班，一同事突然問到：“如何用DotNet動態產生代碼的類？”噫，靜態語言要實現動態產生類,有點意思，不過這又有什麼實際的應用呢？隨手查了一下.Net Framework中提供的類庫，看到Microsoft.Csharp命名空間，其Compiler類已經實現了編譯器的託管封裝。這下方便了，先實現代碼看一下：using System;using System.IO;using System.Text;using Microsoft.CSharp;namespace TestProject{  

今天才在msdn上發現: In C# 2.0, single-dimensional arrays that have a lower bound of zero automatically implement IList<T>. This enables you to create generic methods that can use the same code to iterate through arrays and other collection types.

目前反群發的主要技術措施有：（1）       帳號控制：有帳號才能發，同時限制帳號的發送頻率（2）       IP控制：限制指定IP的發送頻率（3）       協議控制：採用非開放協議（4）       驗證碼控制 本方案主要是突破上面的（1）、（2）兩點，同時對（3）、（4）兩點提供第三方支援服務點 本方案的口號不是不作惡，而是以最小的作惡來達到群發的目的。 如果一個群發軟體裝機量達到一定量，這些裝機軟體形成了一個龐大的p2p網路的話，則這個p2p 網路可以提供以下資源： （1）    

WPF/Silverlight的資料繫結體系設計的真糟糕，幾乎每用一次就要在心中罵一次，不知道是哪個傢伙設計的，就像Asp.Net中的ViewState一樣，拙劣得很：（1）很難用，一些常見的簡單場合使用起來很麻煩；（2）想整個搞清楚很殺腦細胞，不是循序漸進的過程；（3）不整個搞清楚就用不好，或者用的很彆扭。總之，就是一個這樣的怪胎——簡單的情境下使用很麻煩（增加了很多工作量），複雜的情境下使用很繞彎（也減少了不少工作量）。抄起原子彈當鎚子用。一般的開發，哪有那麼多複雜的情境？大部分情況都是簡單

批量去浮水印是個邪惡的技術，以老趙的衣櫥為例子就更邪惡了。之所以以衣櫥為例子而不以時尚網為例子，是標題需要。實際上，時尚網的浮水印批量去除效果更佳。閑話少說，擺原理，片（代碼就不上了）。======================================通過觀察可以發現，如果以圖片的右下角為基準，很多網站圖片的浮水印位置是固定的，因此，可以通過以下步驟去除：第一步：制定一張mask圖片，這張圖片標記了浮水印的位置。mask圖片可以用photoshop或其它工具做。我最初的想法是讓程式智能

flash程式，在前台修改圖片之後，提供列印和Email功能。這兩個功能都是把圖片發到伺服器上，然後跳轉到Email頁面和列印頁面。Email頁面多做一個動作，就是通過SMTP把內嵌圖片的Html發出去。Email和列印兩個過程對比圖如下： 問題是，列印這個功能一切正常。而Email功能，當成功發送出去一張照片之後，然後再發送同一張照片，就發送不出去了。檢查flash那端代碼沒發現什麼。用Woreshark抓包，發現第二次Email同一張照片時，伺服器返回了Internal Server