其他

 在傳統的軟體開發模式中，系統類比運行一般都只發生在軟體實現以後，很少有人會在需求和設計階段做這個事情。這其實是國內大部分大型軟體系統開發失敗，或者開發成功後使用者卻不買帳的原因。這個經驗其實來之於我剛工作不久的一個ERP項目，整個ERP項目團隊才4-5個人，由於第一次做這麼大的項目，我們比較謹慎，

    記得在我前一陣子的blog中寫了關於jdk1.5的pool的記憶體溢出問題，這次乘著新的memcache用戶端的使用，做了一次全面的壓力測試。jdk採用1.5的壓力測試結果壓了一個周末回來就無法響應了，看了看它的GC輸出：全都是[Full GC [Tenured: 786431K->786431K(786432K), 3.4802480 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)]

Open API分析、實踐和思索Author：文初Email：wenchu.cenwc@alibaba-inc.comBlog：http://blog.csdn.net/cenwenchu79 一.  Open API 的介紹... 2Open API的發展... 2Open API的形態... 2Open API的類型... 3Open API互動的資料格式... 4當前國外的Open API使用狀況... 4二． Open API的實踐... 5兩類基礎授權控制...

    今天，有一個使用我最佳化的Memcached cache Client給我發了郵件問到一個參數的作用，覺得還是比較重要的一個參數，因此也說一下，同時也在這裡說一下，當前最佳化過的用戶端已經作了幾次小的升級，修複了一些邊界資料的問題，大家如果在使用的話，最好能夠升級。（http://code.google.com/p/memcache-client-forjava/）   郵件如下：   你好：<socketpool name="pool0" failover="true"

    下周一應該是我今年最後一次參加內部培訓了,所要講的內容也是我這大半年來都在專註的技術:Open API&SIP。由於文章要在程式員1月刊發表，因此文章暫時不能放在Blog上，不過下周一的培訓PPT還是可以分享一下的。有興趣的集團的同學也可以來阿里軟體聽。同時也很高興的看到在csdn的blog在年底衝過了10w，希望明年有更多的分享能夠貢獻出來^_^    csdn

    前幾天，看了白鴉的“一匹更快的馬”，感受最深的一點就是：很多時候經驗就給自己就地畫了一個圈，限制了自己的思維方式，扼殺了創新的萌芽。從開發人員，到架構設計實現，到架構設計，豐富的經驗積累是每個程式員的財富，但是如何使用好經驗，在什麼時候用經驗，正式這筆財富價值最大化，再次積累的關鍵。      就程式開發三個方面簡單說一下經驗使用的想法：      需求分析：站在使用者的角度看問題，做一個普通人（拋開技術經驗）   設計：     

說實話，我對Spring技術還是不算很瞭解，IOC的技術我在Entity

    下午在談交易類服務的時候，除了認證做數位簽章以外，也談到了重放攻擊的問題。    對於重放攻擊可以通過序號的方式來判斷。    序號從頒發角度分成：1.服務調用者自身頒發。2.服務提供者頒發。    序號產生方式分成兩類：1.不重複，隨機頒發。2.遞增。3.時間戳記。     

下面我們利用附加屬性，將我們準備好的Action集合能作為附加屬性出現在xaml中：1）附加屬性類：/// <summary>    /// 附加屬性定義類，注意必須是靜態，這有點類似於給類增加擴充方法。    /// </summary>    public static class WPFTestDettach    {       /// <summary>       /// 註冊附加屬性。       /// </summary>    

Silverlight4的屬性綁定支援索引器，利用這個特性就可以實現VM對V提供更為方便的支援，而且對於基本類型的字典還可以穿越WFC RIA服務，對於DataTable之類的動態資料，就可以利用這個特性不僅可以穿越服務，還可以動態綁定到Silverlight用戶端.動態實體：public class DynamicEntity{      Dictionary<string,string> Fields{get;set} //欄位名-Caption對     

下面的演算法實現基於隨機化快排，有一個前提是需要假設所有的元素都不相等，否則演算法不成立。下面是具體實現：1）隨機劃分演算法與快排一樣：  /// <summary>        /// 快速排序的分隔，即:對於一個指定的主元x,找到位置i,使得i的左邊元素都小於等於x,右邊都大於等於x.        /// </summary>        /// <param name="A"></param>        /// <param

    非虛模式的是將調用介面與實際執行函數分離，調用介面不支援繼承(沒有多態功能),而將實現多態的功能交給具體的保護性執行函數，這樣就使得調用介面統一，同時不損失多態的好處。具體做法如下：    /// <summary>    /// 基類    /// </summary>    public class Base    {        /// <summary>        /// 對外公布的介面，注意這裡不採用虛方法，主要是為了控制統一調用入口。

      接觸雲的概念不算很短，但始終感覺那是一朵浮雲，為啥就叫雲呢？這段時間，經過梳理，對雲有了更為清晰的瞭解。當然，也頗有些感慨，有些人忽悠人的能力咋那麼強呢？下面，我來談談我所理解的雲。    

計數排序利用的是數組的隨機訪問特性，將要排序的數k轉換成數組的下標K，該數組中以k為下標的值A[k]代表這個數K的個數。這種排序非常快，但應用條件比較苛刻。主要受需要排序的序列規模（n),序列最大值(max(n))影響，如果max(n)過大，演算法空間複雜度比較高，也是該演算法的一個制約因素。下面是兩種方式實現:1) 第一種方式速度比第2種快，但沒有穩定性，而且不能用於基數計數排序。private void CountSort(int[] A)        {            List&

M是模型層，實際上就是用戶端得資料服務層，而V是頁面，即視圖層，VM是視圖的模型層，也可以看做是M和V之間的橋接層。我們知道在資料庫編程中，特別是Delphi中的資料庫編程中，資料感知控制項一定令人印象深刻：介面控制項只要設定一個資料來源(DataSource)，然後設定本控制項要綁定的欄位，那麼這個控制項與資料集之間就建立起了一個聯絡，資料集的資料發生變化會立即反饋到介面控制項，而控制項中的值如果發生改變（使用者輸入或修改），也可以自動更新到資料集中。Silverlight頁面控制項的資料繫結

如所示： 類,即代表類也代表函數表,我們看是怎麼調用的.注意如下規則：1、每個類的資訊都儲存在記憶體裡（類型載入後);2、每個類都會儲存其繼承的父類或實現的介面的類型指向。3、每個執行個體都保持一個對執行個體實際類型（類類型）的指向（指標），  

最近在做許可權訪問的封裝，我們的許可權分為使用者(角色)，對象，操作，行級4個層次。在許可權資料方面，我們的處理方式是一次性擷取相關許可權資料（SQL比較複雜一點），並按對象，操作，行級組織成階層，然後對這部分資料進行了緩衝，而且是用戶端和伺服器端同時緩衝，這樣做雖然便於使用者權限存取方法的處理，但也有個問題，有些許可權資料其實訪問的頻度不是很高，特別是行級部分，整個使用者線上期間都不會訪問一次。而且這種處理方式對於sql的技巧要求相當高，其實也是不便於以後維護的。另外一種方式，當然是可以不緩衝

“省了14塊9毛”      

從接觸iOS開發到正式做千牛用戶端斷斷續續已經有10個月左右了，網路通訊，檔案系統，多線程，壓縮，加密，通知，手勢，視圖，IAP，Appstore上架...都正正經經的做過一遍了，有些感觸（當然在手機端這行我還是“涉世未深”，所說的僅僅是自己感受到的）如果不想向著設計師角度發展，那各種優美的互動和動畫就全當作自己的興趣愛好去玩（如果你仔細看過蘋果的HIG，就能深刻體會到開發一個好的APP如何找到設計的度是最重要的，強烈建議不論是否是無線開發的同學去看看蘋果的HIG文檔，能夠給產品開發人員非常深刻

1、實體應該要簡單，層次最好平面化，這樣有利於實體在各種通訊中穿越(比如Webservices,WCF,Remoting,WCF RIA等);2、雖然實體應該平面化，但並不代表不能有繼承層次，因為這種層次可以獲得很多管理和架構的好處      但要注意兩點：1是盡量採用介面 ，而且介面的方法或屬性主要目的是提供統一訪問實體的標準介面       2是屬性的代碼不要複雜，不要對外依賴，而方法更應該如此，能在操作類或者其它輔助類完成的盡量不要安排在實體類完成。