Time of Update: 2018-12-03
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兩類基礎授權控制...
Time of Update: 2018-12-03
最近在做系統架構的時候,一個命令需要同時在多個分布節點上執行命令,但主處理又必須等所有節點執行回來後再繼續處理,因此研究了一下多線程,現分享如下:1)第1種方法,微軟提供的標準教程:利用 ManualResetEvent和WaitHandle.WaitAll:public class Fibonacci { public Fibonacci(int n, ManualResetEvent doneEvent) { _n = n;
Time of Update: 2018-12-03
public class TreeNode { public string Key { get; set; } public object Data { get; set; } public TreeNode Parent; public List<TreeNode> Children { get; set; } public TreeNode(string Key,object Data) {
Time of Update: 2018-12-03
現在的silverlight用戶端綁定支援索引器方式,比如VM有屬性:public Dictionary<string,string> KeyValues{get;set;}在後台CS中我們要訪問某個key的值的方式是:KeyValues["XXXX"],其中XXXX是key.而在xaml中可以如下訪問:Text="{Bindings Path=KeyValues[XXXX]}"只要索引器本身支援get,set還可以實現雙向繫結。但這個雙向有一個缺陷,就是如果KeyValues["
Time of Update: 2018-12-03
採用微軟提供的silverlight+wcf ria service+ado.net
Time of Update: 2018-12-03
昨天看到一個文章,詢問二叉樹遍曆問題,還不錯!貼來: 題目:遍曆n個節點的二叉樹 (每個節點有parent, left, right 資訊 ) 要求: 1)不可以修改二叉樹,即便是臨時的。 2)時間 O(n) 3) 除了二叉樹本身,只使用常數個空間。( 常數不依賴n ) My Answer:首先這個題目,肯定不能遞迴,或者用隊列什麼的,否則空間不滿足要求, 因為有pare資訊,所以,在遍曆時,只要記錄訪問當前節點時,上一次訪問的地方,就可以了: 簡單給個代碼,簡單範例通過,但沒有充分測試:
Time of Update: 2018-12-03
在前面的博文中,如果要能進行修改,都是用strValue進行綁定的,但這隻說明string類型的在datagrid自動產生的列中是可以編輯的,用Object進行綁定一樣也可以編輯,但需要進行一定的處理,而且用strvalue,intvalue分別綁定也不符合開發友好原則,我在樣本中有Object屬性,而且也進行了通知屬性處理,這裡我們利用一個convert來處理object類型的綁定,根據欄位內建的資料類型,其實我們可以做得很通用化。下面是代碼(其它代碼見樣本):1)ObjectAutoConv
Time of Update: 2018-12-03
Spring交易管理的失效和Proxy類型的DataSource 在服務架構中,我們由於需要將DataSource作為第三方服務暴露給其他模組(此處是十分不推薦的,因為如果作為服務那麼首先就要求該服務沒有狀態),因此就採用Jdk的Proxy來實現虛擬DataSource暴露給其他模組以及第三方。 環境: 採用ASF(基於SCA服務架構的應用服務架構)暴露DataSource作為第三方服務,其他模組的Ibatis
Time of Update: 2018-12-03
在大型網站中常常會遇到大流量的資料輸出問題,過於頻繁的輸出到DB、檔案、第三方系統都會帶來不穩定性和低效率。因此需要採用一定的方式來解決這個問題,其實這部分內容的簡單處理架構早就用在實際項目中,不過今天正好有外部的朋友問起我,我就整理了一下作為google的開原始碼放上去了,這裡也簡單介紹一下,有興趣的朋友可以去看看,最好是能夠給一些建議。 情境:
Time of Update: 2018-12-03
三.平台跨的不容易 本來這部分內容應該作為很後面的內容,但是由於工作已經作了,也總結了,那麼就先寫下來貼一下,也算是個分享吧,這部分內容在網上找了很久都沒有,所以也算是不錯的一個實踐。
Time of Update: 2018-12-03
JGroup 使用分享 JGroup是當前被廣泛使用的可靠組間通訊的工具之一。例如OSCache以及JBossTreeCache都是用的是JGroup。
Time of Update: 2018-12-03
下面的演算法實現基於隨機化快排,有一個前提是需要假設所有的元素都不相等,否則演算法不成立。下面是具體實現:1)隨機劃分演算法與快排一樣: /// <summary> /// 快速排序的分隔,即:對於一個指定的主元x,找到位置i,使得i的左邊元素都小於等於x,右邊都大於等於x. /// </summary> /// <param name="A"></param> /// <param
Time of Update: 2018-12-03
前些天跟一個人聊起我自己的一個系統,我說是delphi做的,他說那太落後了,然後說了一堆,我只能汗。雖然我現在主要在dotnet平台上做事情,但我對delphi還是有感情的,畢竟用了那麼多年,而且至今我覺得從開發速度上來說,至少在案頭系統開發方面,無人能及。Delphi至少有幾個地方還是非常的經典:1、UI組織,Delphi的Form是可以繼承的,這個東東非常有用,在提高開發速度方面簡直就一個神器。2、BDE:這個東東的Query和TUpdateSQL結合,再加上datasource可以跨for
Time of Update: 2018-12-03
從接觸iOS開發到正式做千牛用戶端斷斷續續已經有10個月左右了,網路通訊,檔案系統,多線程,壓縮,加密,通知,手勢,視圖,IAP,Appstore上架...都正正經經的做過一遍了,有些感觸(當然在手機端這行我還是“涉世未深”,所說的僅僅是自己感受到的)如果不想向著設計師角度發展,那各種優美的互動和動畫就全當作自己的興趣愛好去玩(如果你仔細看過蘋果的HIG,就能深刻體會到開發一個好的APP如何找到設計的度是最重要的,強烈建議不論是否是無線開發的同學去看看蘋果的HIG文檔,能夠給產品開發人員非常深刻
Time of Update: 2018-12-03
1)測試資料準備://這是我學習treeview綁定時用的,也隨帶給不是很會用treeview綁定的網友們一個例子.A)層級類,樹形結構.public class Folder { public ObservableCollection<Folder> Children { get; set; } public string A { get; set; } public string B { get; set; }
Time of Update: 2018-12-03
什麼事情都有良性迴圈和惡性迴圈,工作也是一樣。程式員這份工作更是如此,特別是你如果和我一樣未來只想走P的道路。 昨天晚上老大給我發了一個郵件,關於規劃部門最近在規劃阿軟的未來技術發展,希望能夠提供關於分散式運算的一些想法和Feature,最近也接觸和實踐了一點,就寫了一點自己的想法。老大很驚訝我那麼快就回了郵件,其實在我看來還是和我讀書的時候老師常說的,“機會總是給有準備的人”,就算中五百萬也需要有承受的心理。
Time of Update: 2018-12-03
下面是依賴對像類的實現:(注,這裡涉及到INotifyPropertyChanged介面,大家可以參考MSDN文檔瞭解). /// <summary> /// 依賴對像,主要提供屬性值和屬性綁定的管理。 /// </summary> public class MyDependencyObject { private IDictionary<MyDependencyProperty, object> _dict = new
Time of Update: 2018-12-03
上一篇,我們建立了一個可用的模型,但我們也看到了它的不足,下面,我們就來繼續完善這個模型:1、首先,因為委託的目的其實是為了與附加責任類進行互動,而掛接了委託的附加責任類才會收到訊息,從這點來看,是一個非常典型的觀察者模式應用情境,因此我們覺得引入這個模式,好處是觀察註冊有專門的類來負責管理,在這裡是代理類行使這個責任(後面的模型會轉到代理類工廠),二是附加責任類以類的身份參與,而不再是簡單的掛接委託,這樣做的好處是目標類可以更多的瞭解附加責任類,可以在需要的時候對觀察者身份進行鑒別,雖然少些自
Time of Update: 2018-12-03
前一篇我把我自己實現動態封裝的工廠類實現貼了出來,這一篇就來講講為什麼要進行動態代理。理由看起來有以下幾點:1、有的時候我們需要為一些類的方法增加一些額外的責任,因為這些責任是額外的,去改動這些類當然是不好的。 對於這點,大家可以很快的想到用裝飾模式或者代理模式去實現。當然,如果責任固定,而且是事先可預料的,可以在代碼中預先進行處理,例如增加一個
Time of Update: 2018-12-03
看了很多書,其中大部分書在討論物件導向和面向過程編程時都喜歡把這兩種編程思想對立起來,我個人覺得不妥,實際上它們之間並不對立,那麼它們之間的關係是什麼呢?我認為物件導向是對面向過程的一種發展與補充,同時也是對同一個事務兩種不同的看法,面向過程將研究對象的功能和資料分開,以功能為主來進行分析和處理,而物件導向則是將這兩個方面統一起來一起考慮,物件導向側重的是宏觀和全域,而面向過程則注重的是微觀和局部,物件導向側重的是一個架構,而面向過程則側重的是實現。在我們實際編程過程中,實際上這兩種思想都很重要