其他

 現在c#的介面只是一個簽名，也就是簽名一樣就可以用不同的實現。但是我認為這個介面模式還不是理想的模式，我認為介面應該是一個規則，而不只是一個簽名。也就是要滿足特定規則的實現，才是符合該介面的。規則包括對資料的定義，輸入輸出的關係等。從實現角度，就是介面簽名外，增加代碼測試功能。也就是，任何一個實現，都應該符合介面的簽名（文法），同時通過它的測試（語意）。為何我有這個想法，因為大多數情況下，單單簽名相同就認為是一個實現，這種約束太低了，反而實用價值不大。比如一個功能組件，建立的目的不是為了滿足某

映射是一個很簡單很實用的數學技巧，用得好經常能達到清晰明了的效果。其中，映射到整數是經常用到的。映射簡單的離散量比較平凡，如果映射能結合序列可以做到很不一般的效果。比如最近做過的一道題目：1000瓶水，其中一瓶有毒，小白鼠喝了一個星期死亡，要多少只小白鼠才能在一個星期內找到這瓶水？思路一、1000瓶水映射到小白鼠，大概就要1000個吧，死哪個老鼠，自然知道是哪一瓶水。思路二、以上映射做得很基礎，得到的答案雖然是對的，但答案比題目要求的要多很多資訊。題目要求知道那一瓶水有毒，需要知道的是一瓶的情況

文章目錄 一、實值型別和參考型別二、特殊類型三、委託類型和介面類型

            流言: 在實際使用中，使用不同的ε值來比較浮點數沒有什麼區別                    正確性: 錯誤    通常當你在包含浮點數計算的任務的SRM之後到Round Tables看看你會看到有人發出像“我把精度從1e-12改成1e-7就通過了practice room所有的系統測試”這樣的訊息。    這樣的討論的例子還有： here, here, here, here 和 here.（它們都是值得一讀的，從其他人的錯誤中學習要比從自己當中少痛苦一點）   

lambda是匿名函數，因為沒有名字，也沒有關鍵字引用自身，因此遞迴的編碼就成了問題。一、最簡單有效方案是：Func<int,int> f =null; //變數須先賦值才能使用f = n=> n==0?1:n*f(n-1);f(11);

 到底何謂有價值的工作？這在有些人看來根本就不是問題，因為他們會覺得工作就是為了賺錢，為了養活自己，不管什麼工作，能賺到錢，不辛苦就是好工作。但是我認為是錯誤的思想。人生必然需要工作，否則無法生存，不需要工作的人生不在我等討論之列。工作確實服務於人生，但是人生卻又不能獨立於工作之外，工作也是人生的一部分。因此工作並不只是一個賺錢的技術問題，也是一個人生觀的問題。假如我們用了年輕的40年去痛苦的工作，最後10年終於可以退休了，你喜歡這種人生嗎？因此談論工作的價值，絕對不是文藝腔，不是無病呻吟，而是

文章目錄 一、應用場合二、成員和可訪問性三、泛型和介面四、類和結構的實際例子

 現在設計模式很流行，但我覺得什麼模式並不是重點，重點是對代碼的語感，也就是我說的基礎技巧。模式是需要經驗，而不能囫圇吞棗，簡單模仿。很多時候，你不需要什麼模式，只需要堅持一些“美感”就足夠。閑話少說，代碼設計的幾個基礎技巧如下：一、防止重複不要重複自己，也不要重複代碼。當你發現重複的時候，就想想用一個標識符去取代具體的內容。如果是常量，就用常量標識符，如果是變數，就用變數標識符，如果是程式碼片段落，就用函數封裝，如果是資料單元的集合，就建立相關的資料結構封裝，如果是狀態和調用的集合，就建立對象

 比特幣去中心化，是防止被發鈔機構濫發貨幣。貨幣貶值，主要原因就是各國的發鈔機構在濫發貨幣，而濫發的貨幣就相當於從貨幣持有人那裡征貨幣稅，導致貨幣價值降低。要改革現狀，發揮貨幣更大的效能，我認為應該建立一種更加合理的發鈔機制。假設發行1億“諾貝幣”，人們可以用人民幣一對一購買我這個貨幣和銷售我這個貨幣。當諾貝幣銷售完畢後，宣布和人民幣脫離綁定，並禁止人民幣流通，而只能用諾貝幣流通，讓或諾貝幣成為市場流通的主要貨幣。因為市場在發展，而諾貝幣總量不變，因此必然就導致物價下降，貨幣升值。當物價下降到原

0/0 =100-100/100-100 =10·10-10·10/10·10-10·10 =10^2-10^2/10·(10-10) =(10+10)(10-10)/10·(10-10) =10+10/10 =20/10 =2 我們都知道，0不能做除數，為什嗎？只是被告知是規定如此。因此很多人就試圖解釋0做除數的意義。以上就是一個例子。不過我從中也複習了一個知識點：分數中分子分母可以約去的邏輯是：ab/ac = b/c * a/a = b/c * 1 =

一、主函數一個程式解決一個問題。那麼就可以用一個主函數解決這個問題。二、子程式這個函數會變得很長，讀起來很辛苦，咋辦？分解成若干子程式，讓主函數調用他們。那麼怎麼劃分？基於什麼原則？子程式的劃分，基於邏輯層次；閱讀是基於一定層次的，比如事件的概要和事件的細節的差別；文章的目錄和文章的內容的區別；要想快速的瞭解一件事，只需要知道概要便可以。主函數就是記錄概要的地方，而子程式是具體的內容；假如子程式還是太複雜，那麼還能細分成子子程式，由子程式在它的層面上去提取概要資訊。是否可以無限的細分下去？直到子

.Net4.5引入了基於任務的並行編程。並行編程大家都覺得複雜，這次.Net引入新的編程模式，相信引起了大家的關注。我在學習的過程中，做了一個小小的實驗，下面和大家分享。以前大家做效能分析的時候，用到的計時器千奇百怪，而這次我發現System.Diagnostics.Stopwatch 類很好用，只需要幾步就能解決時間統計問題：Stopwatch stop = new

文章目錄 一、委託是什嗎？二、事件是什嗎？三、運用委託 這個主題是關於委託的。一、委託是什嗎？委託是用delegate定義的函數指標（其實並不只是一個指標，而是包含一組相關資料）。委託類型定義委託變數，委託變數可以用“函數名”、匿名函數和lambda賦值。而委託變數可以調用該函數。二、事件是什嗎？事件是對委託的封裝，類似屬性對欄位的封裝。事件施加的限制是：一、規定委託的類型，void (Object, EventArgs 或其子類 )；二、

設計本身也要有"源"才行,憑空出現的設計那不過是空想,也是不符合實際需要的.沒有一個設計可以滿足所有需求,因此設計本身就要根據"需求"源頭來做.第一,先有需求這裡要說何謂需求,需求籠統來說就是業務,你對業務的理解是一個不斷加深的過程,這個過程不是設計出來的,而是你的見識,經驗,聯想,對比其它產品,尋找靈感的過程. 總的來說就是你的認識,行動上表現為 "幻想",總結,分析,對比,收集資料等.需求不是設計, 也不是編碼,需求是一切之源頭(除了你賺錢的慾望),但是需求並不反對編碼.

 一、語言習慣的問題排列和組合的差別是，排列的元素與位置有關，而組合的元素對位置無要求。我們的日常問題絕對不會出現這樣的問法：某組元素的排列數是什嗎？不管是排列還是組合，日常用語都會用“組合”這個詞，因此我們要分析一個問題是排列還是組合，要基於問題的前提，分析元素的位置是不是問題需要考慮的因素，如果元素位置不是問題所關心的，那麼這個就是組合，否則就是排列。為了顧及語言上的誤導性，一般專業的數學題都不會在涉及排列的時候出現“組合”二字，因為“排列”或者“組合”都是經過數學嚴格定義的術語。這造成學生

 看到很多人喜歡寫注釋，當然也有很多人不喜歡寫。很多人喜歡寫複雜的文檔，甚至做了漂亮的圖片來說明問題，花了相當大的精力去文檔上面。為什嗎？寫文檔又不能運行，對不？寫文檔的作用我想主要是用來整理思路。人類的智力有限，尤其是記憶力有限，因此需要很多外部儲存體來協助我們緩衝“中間資料”。那些精心製作的文檔，看上去好像沒啥作用，純浪費精力，但是如果沒有這些精美清晰的文檔，你的思路會一團糟，結果花了更多時間在debug之上。做文檔的人都是聰明人，任何時候，寫文檔都比寫程式要容易得多，因為文檔可以容錯，格式

人類的智慧有時候並不高，很容易被誤導。對於一些數學問題，往往搞錯了對象，沒有抓住關係作用的主體是什麼。這並非是數學問題，而是語文問題。其實計算，公式都是很簡單的數學，錯誤的關鍵是搞錯了主體，想當然的亂套對象，結果當然是錯的。比如：小明是小紅的兩倍高，小紅50厘米，小軍身高多少？很多小學生就50*2.或者：小紅是小明的兩倍高，小紅50厘米，小明升高多少？很多小學生也是50*2.沒有搞清楚描述的關係針對的主體是什麼，而只是單純的直譯公式。這在簡單問題上會顯得有點滑稽，但是只要問題描述複雜一些，很多人

小弟愚鈍，總結的不好，希望各位大蝦糾正、補充。 1、  瞭解系統整合方面的知識 硬體基礎知識網路基礎知識行業的最新知識軟體工程基礎知識    我覺得一個架構師的知識面應該非常寬廣，遇到難題，總能夠想到最佳的解決方案，也即最合適的設計。所謂“複雜的系統，一流的設計”，一流的設計往往是最合適的設計，比如說分布式應用，可以使用WebService、Remoting、J2EE，架構師會方根據實際的情況做出最合理的選擇。   2、  精通物件導向、設計原則、設計模式        

數學的作用是減少環節，簡化計算。如1+1+1 =

.net的效能瓶頸，毫無疑問是在記憶體管理上面。自動記憶體回收解決不了所有的問題，反而會製造效能問題。所以大批c++專家都不贊同在c++內部添加類似.net的記憶體管理機制，只是有保留的通過程式庫來支援相關技術。java老愛說c/c++管不好記憶體，容易泄露。但是其實本質上還不是將本來該由終端程式員自己處理的事情，交給了架構開發人員來處理了。既然都是程式員，憑什麼說你這些架構開發人員就不會出現人為錯誤？他們是專家，對大部分菜鳥層級的程式員來說，這個策略有點協助，這是當然。但是從根本上，交給架構開