其他

支援 Resharper 7.x 2012/11/28 昨天收到一個留言，說到Resharper 6 已經出來了，上次發布的 5.0 keygen 已經不能使用了，所以這次更新了下，讓其支援 6.x ；和 5.x 的版本不能混用。Resharper 6.x ：/Files/Chinasf/Resharper6Keygen.rarResharper 5.x

終於在下班前趕完了，略去了一些不重要的地方。感覺很多地方都沒有翻譯明白，不過倒是自己在翻譯的過程中有了更多的理解。翻的不好，大家見諒了，還請大家多多指教。先祝大家新年好原文見：Code Generation FAQ  註：本文翻譯未經過任何許可，僅用作學習，請勿用作商業用途

只展示部分說明性代碼取系統的硬碟分區的盤符，用API函數：GetDriveType [DllImport("kernel32.dll", EntryPoint="GetDriveType")]public static extern int GetDriveType (string nDrive);調用：string [] dirs = Environment.GetLogicalDrives(); //取得所有的盤符foreach(string dir in dirs){ if (

看到這篇文章，關閉指定的IE執行個體：http://www.c-sharpcorner.com/Code/2002/Mar/CaptRunIEInstances.asp自己想了另一個辦法來作先修改註冊表：HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Service\\PerfProc\\Performance下的：Disable Performance Counters

主鍵的選擇：1.有意義的鍵和無意義的鍵：   有意義的鍵：例如社會安全號碼。索引值是唯一的，而由人來指定是不可靠的，有可能會出現重複，雖然資料庫可以檢測出來，但是在資料進入系統之前不會被發現。所以有意義的鍵是不可靠的。   無意義的鍵：本質是資料庫構造的並不打算供人使用的一個隨即數。對應小系統或穩定的情況，應優先考慮。2.簡單鍵和按鍵組合：  按鍵組合：在一個表和另一個表上下文相關時更便於使用。比如：訂單號加上順序號來作為訂單的索引值。 

MES系統總體系統目標MES系統通過控制包括物料、裝置、人員、流程指令和設施在內的所有工廠資源，最佳化從定單到產品完成的整個生產活動，以最少的投入生產出最優的產品，實現連續均衡生產。MES系統通過與ERP、DCS系統的全面整合，為企業搭建一個生產製造整合平台，實現對生產全過程的管理。系統總體建設目標如下：整合可用資源：聯結企業的計劃層和操作層，整合資訊孤島最佳化生產流程：通過項目實施來梳理、最佳化現行生產商務程序完善管理手段：將製造過程中的生產計劃、進度安排、物料流動、物料跟蹤、過程式控制制、過

前兩天談論的bug管理的問題，大家列舉了很多bug跟蹤軟體，我覺得工具是一部分，但是主要還在bug管理的流程上。 在這些bug管理工具裡，bug的一個最重要的屬性就是“狀態”，一般又有“新增（New或Active）”，“處理中（in progress）”，“已修正（Fixed）”，“重新開啟（reopened）”，“關閉（Close）”等幾個，這幾個狀態一看就很明白一個bug從發現到排除要走哪些流程： 1.測試人員發現bug，提交。bug狀態為New 2.開發人員接收bug，bug狀態為in

在學使用CodeDom來動態產生.cs檔案，使用協助裡的例子，代碼居然編譯不通過自己修改，調試通過，整理後主要代碼如下：命名空間：using System.CodeDom;using System.CodeDom.Compiler;using Microsoft.CSharp;using System.IO;  private void button1_Click(object sender, System.EventArgs e)  {   CodeCompileUnit

親和力是什嗎？親和力串連：親和力串連用來請求，它是報表格服務進程（BIBusTKServerMain）一部分（可以理解為線程）。親和力根據一個請求是否分配給特定的服務還是分布式環境中可以分配給另外一個服務。親和力在請求和服務之間，它負責確保請求會被傳遞到合適的伺服器上去執行。親和力請求類型分為三種：絕對親和力、高親和力、低親和力。絕對親和力請求：每個報表進程中除了高親和力請求和低親和力請求，還有絕對親和力請求。絕對親和力請求只能在特定的報表格服務上執行，不管是否有負載平衡。取消報表操作是最好的例

代碼產生原則Top101.        對手寫代碼給予合適的尊重儘管代碼產生可以免去許多重複的工作，提高開發效率，但是你必須知道無論你的產生器有多麼強大，多麼靈活，都有很多特殊情況存在，這些可能都在你的代碼產生器可歸納的範圍之外。所以，雖然你使用了代碼產生器，但是手寫代碼仍然是必需的。2.        應當首先考慮手寫代碼。即使有必要使用代碼產生，也要在你確定你瞭解你的架構的時候再開始使用它。3.       

聽說這個工具好用，找了一個下下來，試了試，別的都好了，就是匯入Opml檔案不行，老是提示說什麼未能識別的標記或者xml文檔有錯誤什麼的，倒騰了半天，最後還是上網查了查，終於搞明白了。就拿部落格園來說：從首頁進入部落格列表http://www.cnblogs.com/Opml.aspx  開啟頁面後右鍵，查看源檔案，然後另存新檔，編碼要選Unicode，儲存後再使用SharpReader的匯入功能，就OK了，原來是檔案的編碼格式倒的鬼。不過這東西可是夠占記憶體的

發現在csdn首頁上居然有了連結“IronPython入門”！督促自己再寫些東西在前兩個隨筆的基礎上又加了些東西，讀入，寫出一個文字檔，不過讀入，寫出的部分都是用python裡就用的東西，沒有用.net framework中的System.IO命名空間下的類，單從這兩個功能上說，代碼確實比.net 要簡單，.net還要先調用建構函式，然後再調用相應的方法。由於沒有IDE，介面作的不怎麼好看，另外也沒有作異常處理下面是對應的.py檔案內容：#匯入名空間from

    這兩天關於Borland出售IDE業務的訊息鬧的沸沸揚揚。看大家討論的熱火朝天，忍不住說說自己的想法。 可以說，微軟的.net卡住了Delphi和C++Builder的脖子，而Eclipse則擊敗了Jbuilder，更可怕的是Eclipse的向心力還有增大的趨勢，看看Eclipse的外掛程式的發展，已經在向PHP，python等領域延伸。   

昨天我把機器上的Rational XDE和Visio都卸載掉了，因為我們四個月前畫的UML圖，自從它們被完成後我就沒有再看過，也沒有使用過XDE的同步功能。這些圖對我已經沒有意義了，因為我更傾向與使用代碼錶達，而不是UML圖示或大量文檔。而我們作這些文檔只不過是管理層的要求，儘管我們曾經有的文檔已經足夠了。當然，並不是說UML不好，沒用，問題在於，它是否適合你現在項目的情況，它對於你的項目來說是否太複雜了，是否已經夠用了，是否值的去花時間去搞清楚它的每個細節，是否要按部就班的去畫各種各樣的圖示。

兩年前剛入行的時候，為了提高自己閱讀英文資料的能力，找了一篇文章翻譯了一遍，後來才知道作者就是大名鼎鼎的Kent Back。現在不知把Doc文檔丟到哪裡了，只保留了一個列印的稿子，現在把這個又敲了一遍，作為一篇文章《可變範圍規約》，由於文章比較長，所以在這個Post裡作一個連結過去。當時對很多東西也只是有那麼一點點概念，翻譯它用了近一個星期時間，但也只是逐字句的翻譯，很多地方都表達或理解不清楚。文章本身沒什麼，還是作為一段經曆吧。也是從這裡開始，我才慢慢瞭解到除了傳統軟體工程，CMM等還有XP

What is the CLS: Common Language Specification ？Brad Abrams提出了一個有趣的說法：CLS是程式設計語言設計者和類庫設計者之間的一個約定The CLS (or Common Language Specification) is a simply a contract between programming language designers and class library

可能的情況有：從一個類繼承，從一個或多個介面繼承，從一個類和一個或多個介面繼承。使用Type類的BaseType屬性來取得類從哪個類繼承。GetInterfaces方法來取得類都實現了哪些介面。測試代碼如下：類庫代碼：using System;namespace GetInterface{  public class Class1 : Class2,BaseInterface,BaseInterface1 {  public Class1()  {     }  public void aaa(

在測試過程中，經常碰到測試和開發的版本不一致的問題。 常見的現象就是測試部門發現了bug，但是這個bug已經由開發人員自己發現並解決了，還沒有發布新的版本，而在雙方沒有及時溝通的情況下，會作一些無用功，如果經常出現這種問題，有時會讓人覺得很不耐煩。我覺得要避免這種情況，就要盡量保持測試和開發雙方的版本一致。 這裡我想到敏捷式軟體開發 (Agile Software

支援四種語言：IL，VB.net，C#，Delphi，是對DataTable的AcceptChanges反編譯的部分不知道用混淆器後會是什麼結果http://www.aisto.com/roeder/dotnet/ 補充：昨天試了，這個軟體現在可以直接下載，沒有什麼其他的步驟

據說有一位程式員，寫了6000多行的彙編代碼，自己Review了近100遍，最後到測試的時候沒有發現一個bug，後來這件事被公司樹為樣板。對於這件事有幾點不合理的地方，首先，程式碼數並不能體現軟體的複雜度，相同長度的代碼，邏輯複雜的寫起來肯定要難些，這無需多說。其次，使用程式碼數這個指標隱含的意思就是不鼓勵代碼複用。你可以在多處寫相同的代碼來擴充代碼規模，而並不在乎軟體的可維護性，可重用性等等。這樣就使得使用代碼複用的程式員看起來也不比那些能寫超多代碼的人工作得更出色。我們可以列舉許多的理由來說