JOGG's

來自 Youtube的一個 影片 1. 決定腦力激盪的 目的 2. 選定一個 腦細胞活躍的時間 3. 擬定 目標藍圖 和 創意發想的重點 4. 補充 腦力食物 ，用食物解放思緒 5. 舒適空間 讓思考有交流的空間 6. 書寫刺激想法、記錄網住靈感 7. 指定目標追蹤的負責人      - 認可創意人的點子是最大的鼓勵；扼殺士氣最快的方式就是，從不執行創意人提出的好點子。  

最近在測試官方版的 xmlbuilder 寫法有兩種 1. with x = XMLBuilder with x.tag_name('value', attr1_name=attr1_value, ....):    with x.tag_name('value', attr1_name=attr1_value, ....):      ... 這樣分層下去 2. << x << (tag_name, value, {attr1_name:attr1_value, ...})      記錄一下

接下來談的是一些關於測試的伎倆。 1. 學弟建議的 code Coverage 程式碼涵蓋範圍     這是用來計算程式碼有被執行的的比例，占的越多不表示程式碼品質好， 但占的少表示測試品質差。這就像是很多條路徑，要怎麼設計多組cases來 走完全部的路徑。 2. 邏輯涵蓋範圍     去計算全部的邏輯運算式中，所走過的有幾個。這表示，假設一段程式碼 有6個if, else, for, ... 等等等判斷式，則至少需要6個test cases 3. 資料流程測試(我覺得稱做資料生命周期測試比較合適= =a)     一個資料它可以分成三個型態：     已定義- 已初始化但尚未使用     已使用- 已在運算中     已停用- 表式運算結束     另外對於從 已定義->已使用中間可以插個 已進入，     以及從 已使用->已停用中間插個 已離開，做為進一步描述。     一般正常的資料流程是 定義、使用到停用，這都沒有問題。     但是常出包的地方就是發生在一些情況：     a. 已定義-> 已定義         重複定義，雖這不一定會出錯，但可能造成問題，應避免。     b. 已定義-> 已離開         一般變數沒使用就離開，是挺奇怪也不合理的。     c. 已定義-> 已停用         表示這是個多餘的變數     d. 已進入-> 已停用          表示在進入時，就停用，但尚未定義或使用。這樣對於區域變數會有問題。     e.  已進入-> 已使用          這仍然會有些問題，因為需先保證使用前已定義。     f.  已停用-> 已停用    g.  已停用-> 已使用    h.  已使用-> 已定義 4. 對等分割     這是指若兩個測試會抓出相同的錯誤，則我們僅需要針對一個。     ex. if a < MaxNumOfBalls,  a有大魚或小於MaxNumOfBalls，但若測試部分只要擇一測試便是。 5. 邊界分析 就是找出臨界值或極端值來測試。 6. 錯誤的資料類別 a. 資料太多或太少 b. 資料類型錯誤 c. 資料大小錯誤 d. 未初始化 7. 良好的資料類別 a. 預設的最大、最小值 b. 與舊資料間的相容性 嗯...

下午試了一下Crypto的東西，來寫一下筆記 參考 1 From Crypto.Cipher import DES shared_key = '12345678'    # 這個一定要是8的倍數 obj = DES.new(shared_key, MODE_ECB ) plain_text = 'hello, welcome to the world'   # plain_text 應為8的倍數 #encrypt padding = '$' extra = len(plain_text) % 8 if extra:    plain_text += padding * (8-extra) ciph_text = obj.encrypt(plain_text) #decript origin_text = obj.decrypt(ciph_text) print origin_text.strip('$') 註1：可以在sharedkey上動手腳，改為 binary string 註2：strip() 是去掉所有的 padding, 所以先確保該padding不在plain_text中

工作即將進行到測試階段，但老實說我從未做過相關工作，所以看了本書 Code Complete ，這裡來寫一些筆記+心得。 這本書提到測試依層次有分幾類： 1. 單元測試:  這是用來測試某一個完整類別中的函數或變數而常使用的一個方法 2. 元件測試:  用來測試一個完整類別、封裝。 3. 整合測試: 用來測試複數類別、元件或子系統。 4. 迴歸測試: 重覆已執行過的test-case，藉以找出先前測試中未察覺出的缺失。 5. 系統測試: 讓軟體在最終設定下執行，並與其他軟硬體結合，包括安全性、效能、資源損耗、計時問題以及其他無法在低階段整合中測試的問題。 其實還有一堆，像是客戶接受度、效能、設定、平台、壓力及可用性測試等等等，太多了。 知道一堆名詞後，我還是不知道怎麼著手。 一般人將測試分為兩類：黑箱測試及白箱測試，這大家都懂。 然而測試的目的為何? 測試與除錯的差異? 為何測試對於大部分的開發人員來說相當困難? 書上解釋了幾項原因： 1. 因為測試的目標與當初開發的目標正好相反。     測試的目標：找出可能的錯誤，讓軟體掛掉     開發的目標：除去所有臭蟲，讓軟體順利執行 2. 測試無法證明錯誤不存在。     (ㄜ... 這是表示錯誤是NP-H嗎 = =+) 3. 測試本身不能提升軟體品質。     這應該是倒過來說，測試的結果可以做為品質的一種評估指標，但無法提升其軟體品質。 4. 要假定你自己的程式碼中存在錯誤。     (這不是廢話嗎... 但要揪出他又是另外一回事了xD) 了解什麼是測試後，書上建議了一些測試前的準備工作： 1. 測試相關需求，確認需求實做是否存在。     這裡指的應該是客戶需求那玩意。書中也提到可以針對那些需求中，常被遺漏的部分，像是安全性、storage、安裝程序即系統可靠性測試，因為這些常是在需求階段被忽略的東西。 2. 對於1的問題，撰寫即規畫test-case 3. 使用基本測試。 4. 在檢查清單中記錄在過去開發中曾犯的錯誤。 另外也提到了測試的順序應該是邊寫邊測還是最後再測? 書中建議是- 事先寫做test case, 有助於debug所需花費的時間。 理由不外乎是早期發現早期治療、若測試寫的不順表示需求設計可能不良等。 預防勝於治療，啦哩啦雜只解釋了測試的冰山一角....

讀書這檔事，雖然大家都會，可是真要問問自己，自己學習的效率好嗎? 有沒有存在一種"正確"的學習方式，可以讓讀書這苦差事(大部分的人應該都覺得讀書很苦XD) 更有趣、更有效率? 一般人學習方式都是: 1. 看懂它  2. 確定沒有遺忘它 hmm... 在過去的念書裡，很少人會告訴我一些學習，所以我總習慣於追逐頁面上的文字在玩文字遊戲，導致花了很多時間在玩文字遊戲，這種人叫做"head-first"，表示他做任何事前習慣先將頭探出去，是指那種做事情未事先深思熟慮的人。 今天看到一些不錯的學習首則，希望之後對於自己的學習方式能多留意： 1. 盡量視覺化     在Mr. Brain裡頭也提到了，人類對於顏色的敏感度勝於文字。而影像相較於文字對於人類更容易記憶，可以提升學習效率，甚至將回想及轉述效率提升至89% ( 根據認知學習理論中的雙通道假設，人類學習主要藉由視覺及聽覺，唉... 難怪我學習能力很差，因為我近視破千加上輕度聽障 = =.... ) 2. 對話格式 + 人性化風格     根據統計，使用第一人稱或對話方式來教學比起正常中規中矩的方式，學生學習效果可以提升至40%。所以若閱讀時(甚至回顧時?!)，以說故事的方式、用口語來表達所看到的文字，更能挑起自己的注意力。 3. 學習深入思考     我覺得這個很難，究竟要怎做呢? 首先必須被驅使強迫自己參與其中、產生好奇心、並自發地解決問題、做出結論、最後產生知識。這個說易行難阿!  需要有人來問你問題引誘思考、並用活動或測驗來活化左右腦。 4. 保持注意力    5. 試著被感 動    至於如何思考? 我也不知道，但是網路上很多答案，目前覺得最中肯的是從 這個網頁 看到： 1.   跟頂尖的人做朋友        這個真的是除了砍掉重練外最快的方式 = = 在研究所這一年多裡我見識狠多，不管是學長或學弟，真的都超優秀的... 2. 多看書     說到這點我真的很慚愧，以前我超愛看書的...  但自從看教科書加上工作性質的關係後，我變得很少看課外書... 要多提醒自己再忙也要花時間看書!!! 3. 對於手邊資訊的判斷     這點超重要的。台灣的資訊氾濫已不可言喻，加上平面媒體雜誌慣於加油添醋或憑空捏造以求收視率，因此搞得人心惶惶。作者說的好，我們真的要多方收集資訊並加以分析

今天跟學弟討論XML的document object 屬性數目問題。 首先回憶一下python DOM所描述的XML由上到下分成 Document -> Element(s) ->NodeList -> Node(s) 在python 裡頭，因為Document object是minidom lib自己建的， 取出某個Node的Attr或Text很容易。 而在TinyXml 裡頭要找做到相同的事情： 0. TiXmlDocument doc('mytest.xml') 建立Document obj 1. 使用 doc.Parse('mytest_xmlstring') 讀入xml並建立XML-tree 2. 要取得Element(s)可用     TiXmlElement *elem = doc.FirstChildElement() or     TiXmlElement *elem = doc.FirstChildElement('selected_element_name') 3. 要找某個Element obj裡頭特定Node的Attr or Text 可用   *Assume only one Element in elem   sp_attr_name, sp_attr_value    TiXmlAttribute *attr = elem->FirstChildAttribute('specified_element_name')   while (1):       if (!attr) break;       else{            if (attr->Name() == sp_attr_name) and (attr->Value() == sp_attr_value){                fprintf(stdout, "match.");                break;            }            attr = attr->Next();           } 但若欲找的Element object不只一個，只好再包一層Loop了... (有夠麻煩) 我的問題

剛剛同學問我的問題，我也沒在linux上實做c，但總覺得這問題一定很常見， 所以就把他註記下來。 主要步驟是 0. include curses.h  [ getch()在裡頭 ] 1. 使用initscr() [ WINDOW *W = initscr() ] 2. ch = getch() 3. endwin() 另一個則是透過posix實做 getch() http://heresy.spaces.live.com/blog/cns!E0070FB8ECF9015F!5092.entry

有些詞我一直記不住它真正的意思，第一個就是 邊際效應 marginal effect 。 今早又想到它，所以這次來寫點東西，希望能夠最後一次忘記它。 網路上 是這麼形容的，他說就好比吃東西，當吃第一口的時候覺得非常好吃， 第二口的時候還不錯，等到第五、第六口的時候那種滿足感漸漸不再那麼強烈， 而邊際效應就是最後一個單位比前一的單位的效用。以上面這個例子來說，此 邊際效應是遞減的。 不過以微積分的角度，這不正好是微分的觀念嗎。    [ f(x0+1) - f(x0) ] / 1 = [ f(x0+h) - f(x0) ] / h = f'(x=x0) 而一般分析的經濟問題常將離散型的函數(成本函數)連續化，所以成本函數  Cost(x) 的邊際成本即是它的導函數(一次微分)。 而通常我們想求最大淨利時，邊際成本 = 邊際收益。 Profit(x) = Earn(x) - Cost(x)  => To maximize P,  find minimum of Cost(x) => 發生在微分 C' =0處。 另外貼個五個人性定律 [出處]  http://www.newscientist.co m/article/dn18301-five-law s-of-human-nature.html?ful l=true 最近一直在檢討人生的意義，找到了個有趣的玩意，是討論 人的五個習性定律。 "You are so predictable!" 哈，挺有趣的起頭。 1. Parkinson's Law 這是在說人們總是會在自己空餘的時間內塞工作進去，搞得 自己行程滿檔。 Parkinson 同時也提出另一個定理：Law of triviality. 這是說開會時討論某件議題所花的時間總與它的重要性成反 比。 * Parkinson有推導出inefficiency coefficient, 並定義一次開會最多的人數為 19.9~22.4. 超過此range則表示此會議將不會得到任何結論。 2. Student syndrome If it weren't for the last minutes, I wouldn't get anything done. 哈哈，這當過學生的都知道，非到最後一個moment