其他

1. 在應用領域培養開發人員    協助開發人員對應用領域有一個基本的理解。這樣可以減少開發過程中的混淆、誤解和返工。2. 定義項目前景和範圍    前景（vision）說明使所有涉眾可以對產品的目標達成共識。    範圍（scope）則定義了需求是否屬於某個特定版本的界線。3. 使用者群分類    將產品的使用者分成組，已避免出現某一使用者群的需求被忽略的情況。4. 繪製關聯圖   

假設我們對如下Block中的紅色線段做了標註，那麼這個標註的兩個錨點(Anchor Point)分別為紅色線段的2個端點當我們旋轉這個Block後，我們自然希望這個標註也跟著物體旋轉的，調整到如下合理的位置，   現在的問題是如何為這個標註求得變換矩陣。一開始我以為只要根據紅色初始位置，跟終止位置，求得它的變換矩陣，再作用到標註上就可以了。

兩條非平行線段， 如何合理的標註角度。比方說對於下面2條初始線段： 根據當前滑鼠所在位置的不同，我們可能得到如下不同的標註方式：   本人求標註的思路大體思路是：首先求出圓弧（Dimension Line）的兩個端點, 然後根據這兩個已求得的端點，分別計算出兩條引線（Witness Line）的端點。 求圓弧端點的演算法：我們把問題簡化下，對於任意2條相交的射線，以下均以銳角為例(鈍角求解過程完全一致)： 以2線段所在直線交點作為圓心，

1. 對使用者和管理者進行需求培訓    培訓可使他們明白重視需求的意義；需求活動包括哪些活動，要提交什麼樣的結果；忽略需求過程會導致什麼風險。2. 為需求建立模型    模型能夠揭示不正確的、不一致的、遺漏的或冗餘的需求。這類模型包括資料流圖、實體關聯圖、狀態轉換圖或狀態圖、對話圖、類圖、順序圖表、互動作用圖、決策表和決策樹等。3. 管理需求風險以及編寫需求文檔    可組織自由討論，找到方法來減輕或避免這些風險。實施減少風險的活動，以及跟蹤它們的進程和效果。4. 使用需求管理工具   

1. 定義需求開發過程    將你的組織如何擷取和分析需求、編寫規格說明和驗證需求的步驟編寫成文檔。可以協助分析員做好工作，還能夠使規劃項目的需求開發工作單位、進度和所需的資源變得更為容易。2. 以需求為基礎指定計劃    當範圍和詳細的需求變得清楚時，應反覆斟酌項目的計劃和進度表。3. 需求變更時重新討論項目承諾    當將新的需求合并到項目中時，如果不能兌現當前的進度和品質承諾，應將項目的實際情況報告給管理層，協商制定新的、可行的承諾。

文前聲明：小生對“次層網域”、“分站”這類概念不是很清楚，本文若是對各位多少有點用，就留個笑臉；若是不才，各位認為完全時垃圾，也敬請拍磚。如果，閣下有更好、更簡便的方法，也可以提出來，以供大家（特別是我）學習學習......這幾天，外賣匯網站開始需要實施其他城市的擴充（目前就杭州站有，正在準備上海站的開通），可是遇到一個問題（不說大家也知道了），就是如何通過次層網域指向不同的城市網站。目前外賣匯的網域名稱是waimaihui.com,希望將http://hz.waimaihui.com/指向杭州

LINQ中的Distinct方法能夠協助我們輕鬆地剔除集合裡面相同的元素。 它提供了2個重載函數，其中一個允許我們傳入IEqualityComparer<T> 介面， 給我們充分的自由來決定2個元素是否相同。為了實現剔除一堆string集合中相同的string，我寫下了如下的代碼。 註：不區分大小寫source.Distinct(new StringComparer()); internal class StringComparer :

在<<敏捷式軟體開發 (Agile Software Development)>>一書中講解Mediator模式舉的是如下關係的一個例子:用一個JList和一個JTextField構造了一個QuickEntryMediator類的執行個體.QuickEntryMediator向JTextField註冊了一個匿名的DocumnetListener.(沒有系統學過Java,這點上文法不是很清楚,但大致也知道在做什麼).

1. 分析可行性    在允許的成本和效能的要求下，分析在指定的運行環境下實現每項需求的可行性，明確與每項需求實現相關的風險，包括與其他需求之間的衝突、對外界因素的依賴以及技術上的障礙。2. 建立術語表    定義應用領域專業名稱的術語表可以減少誤解。3. 編寫資料字典    資料字典中包括系統用到的所有資料項目和結構的定義。使參與項目開發的每個人都使用統一的資料定義。方便客戶和Team Dev之間的交流。4. 觀察使用者執行工作的過程   

文章目錄 前言功能一：繁簡轉換功能二：時間差計算結束語 前言     

從上海出差回來（2.17）到現在整好過了兩個月，這兩個月一直在開發外賣匯2，直到昨天終於在伺服器上部署了一個測試版本。儘管，兩個月的時間比預期的要長了些（預期應該是在3月底四月初到這一步的），但是至少是走到了這一步。兩個月來，一直辛苦地在做這個項目，幾乎每天都加班，卻還是一直努力著。多少次，肩膀痛得實在是抬不起來了；多少次，希望能到西湖邊散散步，身子卻實在是累得厲害；多少次，即使餓著，也不願離開座位......只為著能夠早一點完成這個項目，或者說能夠讓它早一點上線。有時候也會懊惱，懊惱只有我一個

 小孩子在5,6歲的時候是很有創造力和想像力的,而且很喜歡"跟風",看見鄰居家小孩買了新的玩具,一定要嚷嚷著父母給買一個.父母坳不過就買吧,今天一輛小汽車,明天一個大房子,於是乎沒完沒了了,幾個月下來小孩子屋裡全是玩具. 有一天父母給他買了一套積木,可把小孩給樂的,每天在屋子裡不停的擺停著,一會組裝個小橋,一會組裝個小汽車出來,玩的不亦樂乎啊,從此父母得到了消停. 看來現在的大人們早已深知組合的魅力啊!孩子們呢從組合中開發了思維,又樂在其中.

最近在做一個Silverlight的項目，一直用的是FF，卻發現預設情況下FF無法調試Silverlight。困擾了我n久，今天總算是搞定了~貼出來跟大家分享下：Try these steps...Type "about:config" into FF's address bar Accept the warning (if applicable) Search for the entry "dom.ipc.plugins.enabled.npctrl.dll" Change its

首先,Managed 程式碼由GC自動回收，不代表託管應用程式就沒有記憶體泄露問題其次, 程式不總是精確知道哪些託管對象是垃圾，這就代表著沒有一款工具，一運行就能給你一個報表，說某某對象沒回收，某某地方發生了記憶體泄露。再次, 工具只能dump出當前應用程式的記憶體快照，有沒有記憶體泄露還需要你敏銳的眼光。比如說下面的例子，當某個文檔被關閉後，這個文檔對象及其它引用的資源依然包含在Dump的記憶體快照中，我們就可推斷出此處有記憶體泄露。 Tool:I used the .Net Memory

1. 重用需求       多重專案可以重用那些符合一個組織的商務規則的需求。2. 應用品質功能調配    品質功能調配（QFD）將產品功能、屬性與客戶的重要性聯絡起來。該技術提供了一種分析方法以明確哪些功能最能滿足客戶的需要。QFD將需求分為3類：期望需求——客戶或許並未提及，但若缺少卻會讓他們感到不滿意的需求；普通需求；額外需求。3. 衡量需求的穩定性   

1. 培訓需求分析員    所有將要成為需求分析員的團隊成員都應該接受需求工程方面的基本培訓。熟練的需求分析員應具備以下特點：       耐心，思維條理性強，有良好的交際和溝通能力，理解產品應用領域，並且掌握豐富的需求工程技術。2. 為每類使用者選擇代言人    使用者代言人提供某一類使用者的需求，並代表他們作出決策。3. 建立核心隊伍    把產品早期版本或同類產品的使用者代表召集起來，收集他們對正在開發的產品功能和品質特性的意見。4. 建立原型（使用者介面和技術原則）   

文章目錄 .NET Quiz  老趙一出手，又引來無數跟帖。詳見 我在面試.NET/C#程式員時會提出的問題小弟不才，只被面試過，從未面試過別人。所以想從被面試方的角度來談談，在我心中理想的面試應該是咋個樣的。前陣子lzprgmr同學，站在面試官的立場上談了談他的感受，見

以前曾看見過這樣一個問題：Managed 程式碼會不會導致記憶體流失。自己對GC的瞭解也不是很深，但還是比較贊成這樣的觀點：Managed 程式碼不會產生記憶體流失，除非你沒有正確釋放非託管資源。今天看到一個非常有趣的例子，關於沒有釋放事件的Handler導致的記憶體流失。以前對於釋放Handler的觀念是一點也沒有，這主要因為沒此方面的意識，沒有養成好的習慣。只知道當關心這個事件的時候就註冊一下，

花了一天的時間，整理了下需求工程方面的有關方法。並對這些方法的實現難易度以及效果進行了分類。供大家參考討論影響高 難度高定義需求開發過程以需求為基礎制定計劃重新討論項目承諾難度高 影響中對使用者群和管理者進行需求培訓為需求建立模型管理需求風險使用需求管理工具建立需求跟蹤能力矩陣召開需求萃取討論會難度高 影響低重用需求應用品質功能調配衡量需求穩定性難度中 影響高確定用例指定品質屬性確定需求優先順序採用SRS模板定義變更控制過程建立CCB審查需求文檔給子系統分配需求記錄商務規則難度中

類是資料類型的實現，而對象是類的執行個體。類的成員是聲明在類裡面的實體。C#類的成員共有六種：欄位、屬性、索引器、方法、事件和巢狀型別。C#的欄位用const修飾，表示他只能在聲明的時候被初始化；用readonly修飾，表示只能在聲明時或建構函式中初始化。兩種情況下欄位的值在初始化之後都不能再改變。在對象開始使用之前，所有實值型別的欄位都必須初始化，即必須在物件建構結束之前被初始化。有兩種方法初始化：在類中聲明時直接初始化；在類的建構函式中初始化。