其他

兩種方法，方法一 尋找註冊表  思路：首先枚舉註冊表路徑"HKEY_LOCAL_MACHINE//Drivers//Active"下的子鍵，從子鍵中尋找鍵項"Key"的值是否包含"Drivers//USB//ClientDrivers//Mass_Storage_Class"欄位，如果包含再取該鍵的鍵項"Name"的值，擷取名字devName後調用如下代碼，實現禁用 HANDLE hnd = OpenStore(devName);//(L"DSK1:")if(hnd ==

   策略模式是一種定義一系列演算法的方法，從概念上來看，所有這些演算法完成的都是相同的工作，只是實現不同，它可以以相同的方式調用所有的演算法，減少了各種演算法類與使用演算法類之間的耦合。   策略模式（Strategy）：它定義了演算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓演算法的變化，不會影響到使用演算法的客戶。   當不同的行為堆砌在一個類中時，就很難避免使用條件陳述式來選擇合適的行為。將這些行為封裝在一個個獨立的Strategy類中，可以在使用這些行為的類中消除條件陳述式。

(Song) 17:10:46想問一下青潤，在分析模型階段，最終是要得到什麼結果？在一個大系統中，需要針對每個用例做分析模型嗎？這一點在你的書中沒有提到呀，也許是我看的不認真吧。 (青潤) 17:11:10這一點，我的書中寫了。 (青潤) 17:11:44不過，不夠明確，這也是另外一個朋友三個月前提出來的。我在我的blog上作了補充修訂。你可以去看看。 (青潤) 17:12:15但是，應該可以從書中看出來的。 (Song) 17:12:37我也是看到了，就是不明白，並且很多用例，雖然業務不一樣，

•       編寫汽車類，要求有汽車、方向盤、車身、發動機、刹車等幾個類。•       類比一次從啟動到結束的過程，並輸出汽車的狀態變化。•       同時實現幾類汽車：奧迪A4、平治C200、奧迪Q7思考：1、將方向盤、車身、發動機、刹車分別寫成一個類；       2、以上類是汽車類的成員；       3、為汽車添加啟動、行駛、停止等過程函數，聲明為virtual；      

2004-12-07 14:41:53 Song青潤，用例的分包，分析模型的分包，以及系統的分包等必須統一嗎？ 2004-12-07 14:43:25 Song系統的分包，我理解是設計模型的分包，與匯出的代碼是一致的，如果與前面的分包保持一致，那這些類混合在一起會很臃腫啊 2004-12-07 14:47:12 青潤不，是需要統一考慮的，而且是一個逐層遞進的關係。用例得分包得到的是子系統。分析模型的分包得到的是子系統下每一個子模組。設計模型的分包劃分的是每一個模組下的類的具體路徑。 2004-1

這裡是幾個常見的uml設計錯誤，文中也是執行個體，因此隱去了相關資訊，圖中遮擋的部分是完全一樣的兩個字，你可以把它考慮成任何東西。一個朋友17:29:39青潤兄，周末的時候讓你指教的地方有沒有看

    本來昨天晚上以為汽車類的作業已經做好了，雖然也覺得自己做得太簡單了因為有太多的工作要做，就沒太在意改進的事情。    昨天上了Delphi程式調試的課程，對偵錯工具有了新的認識。印象最為深刻的有以下幾點：   關注編譯期間的非語法錯誤：Warning 和Hints，這些小東西很可能造成潛在的bug；   斷點有四種類型：普通斷點，條件斷點，資料斷點和地址斷點，而我僅僅使用了普通斷點，其它的都還不會！！！  記錄測試的過程，不僅僅是記錄出現過的問題方便以後查閱，更是要用來明確調試的進度； 

看了《隨筆2：開發工作單位的分解過程》http://blog.csdn.net/CSDNATM/archive/2010/07/12/5730142.aspx後的評論內容，涉及到需求分解和擷取，任務分配和績效管理的內容。slowgrace讓我過來看看，上面這篇文字中提到的內容很多是常見內容，但是根源卻不在撰寫者的內容。下面進行一下我個人的觀點描述：1、“往往因為功能（任務）分解得不夠細緻而造成過程失控”這段文字中的問題其實是因為需求沒有做好的原因。關於最小分解單位可以對應於uc和us的方式，在我

2013-07-29 09:51:10  緣，妙不可言清潤老師，我現在要做 SOA服務治理的 建模，但是這個 基本不是公司專屬應用程式，沒有什麼商務程序，不知道怎麼下手，都是 日誌收集分析、服務發布配置、許可權控制、流量控制、調用次數統計、分析預警、服務依賴關係 查看 這些非互動密集型2013-07-29 10:04:59  青潤這些一般屬於非功能性需求。是需要技術人員根據系統功能，特性抽象提煉出來的，其業務模型只能根據情況來分析,忌盲目照搬和完全拍腦袋，要熟悉全系統業務後加上經驗才能做的較好2

是的，我曾經說過這個問題。這也是目前全程建模或者說是我認為的建模技術目前最大的兩個弱點之一。jsp幾乎沒有自動產生的方法，否則，你設計的工作量會遠遠大於實際編碼的工作量，所以，我建議b/s開發中介面部分通過介面設計引入，然後，手寫完成。目前比較好的做jsp開發的工具我認為是：ibm的wsad，或者採用Editplus，也可以採用dreamwaver與開發工具配合的方式來實現，這就要看具體的操作方式和你個人的習慣了。-----------------------------------------

兩周前去了趟tencent總部，討論了我的可度量績效模型。感覺討論結果有些小的收穫，tencent的專案經理水平還是不錯的。結果讓我也基本上認同：我目前的刻度量績效管理模型在一個項目組內實施應該是沒有問題可以達到預期效果的，或者該公司的所有項目都具有很強的相關性。如果項目類型過於繁雜，可能會讓不同項目組之間的績效對比出現偏差或者難以控制的地方。或者說這個問題的進一步解決需要更為複雜的數學模型和更多的資料基礎積累支援後才能做到。 

    這兩天在做一個映像壓縮處理常式的介面，其中用到了動態載入位元影像。之前只做過靜態位元影像的載入，做動態位元影像載入也花了點時間。下面我就把靜態和動態載入的方法都跟大家分享一下，同時也便於自己查閱，如果大家有更好的辦法也記得共用一下哦！靜態載入位元影像：1.添加控制項：添加Text控制項做為顯示位元影像的控制項，添加“顯示位元影像”按鈕控制項；2.插入位元影像資源，設定ID為IDB_BITMAP1；3.用classwizard為按鈕控制項添加響應函數，並添加代碼如下：void

在理論與推演群中的對話。 愛技術-軟體工程  15:27:36在架構設計過程中進行架構性代碼開發以進一步確定思路，是否違背設計思路？愛技術-軟體工程  15:29:01我始終感覺不做架構性代碼編寫，好像有點空想。一遍寫架構代碼一邊修正架構設計，我感覺更踏實。青潤  15:29:04架構代碼開發，還是快速原型代碼開發，都是可以的。開發過程中一方面要考慮使用者的變化要求，另一方面要考慮如何減少風險。青潤 

        前幾天用EVC寫的測試一些功能得utility,邊學邊作,呵呵1.測試buzzer  2.調節LCD backlight,通過讀寫註冊表實現  3.測試IRDA 通訊 IRDA SETUP: 4.get POWER status  5.set ,read GPIO,能看到GPIO 控製得LED 得亮滅 還要再加一些其他功能得,現在忙著解決其他得issule,過兩天再接著寫這個utility.  

第五屆雲端運算大會參會有感1.  參會過程這次參加雲端運算大會其實是個偶然，雖然在教育台做教育雲相關的項目也有幾年，但是，也看到了雲本身很多的不足和在管理以及安全上的問題，確實，雲端運算或者更準確一點說，應該是雲端服務確實是目前可以看到的一個市場相當廣闊的機會。本來因為工作時間問題，在接到社區和高校俱樂部的邀請函時都沒有提交申請，在6月3號高校俱樂部突然聯絡我說希望能夠在6月6日晚上雲端運算大會後請我參加一下高校俱樂部的活動，考慮了一下時間，隨即應允。這時候，他們問我是否需要雲端運算大會的門票，

 這兩天更新了一下原來的test utilitly,使串口和紅外資料可以定時自動發送,其中要用到定時器.並更正了接受視窗用到的edit box控制項中的一個小問題,在此作個筆記.1.EVC 中應用簡單的定時器在send按鈕的函數裡加入了裝載定時器函數:   //啟動1s定時器,用於定時向com 發送資料   m_timerID1=SetTimer(1,1000,NULL);//第一個參數為定時器ID號:1,第二個參數為時間1000ms

關於科學的探討，涉及到科學基礎的對話和探討，尤其是數學、哲學、物理、化學和生物學，生物學中特殊的意識產生的現象。1發信人: hellowkq (刷！刷！刷！), 信區: Thinker標  題: 探討一個問題，如果要對現在人類的知識做總結的話，哪些 t發信站: 水木社區 (Thu Aug 26 19:26:24 2010), 站內哪些知識是最重要的※ 來源:·水木社區 newsmth.net·[FROM: 123.120.122.*]2發信人: qingrun (青潤), 信區:

     我的人生座右銘是“生命不息，折騰不止”。每每都在最最絕望的時候看到新的希望，不知道這次是不是也是這樣呢。     網上投遞的所有簡曆都石沉大海，招聘會上永遠都是那幾家公司，還要遭受各種白眼。網投行不通，招聘會行不通，工作經驗沒有與應屆生比沒有優勢，不能埋怨任何人，堅持下去，希望就在前方。    

dc 18:38:14呵呵，在QQ上碰到你。 青潤 18:37:55呵呵。 dc 18:39:05我是剛才搜了iTSP群看到你的QQ號的。 青潤 18:38:59呵呵。  青潤 18:42:36最近都在忙什嗎？ dc 18:44:58……青潤 18:44:50……dc 18:48:57被客戶追著一天一個念頭的改code真是煩，我現在聽到電話響就渾身發抖不敢接。 青潤 18:49:14呵呵。這就是無備有患的結果。 dc 18:57:04是啊，但市場決定了，否則就不要我們的方案。 青潤 18:57: