super－ 1. 超，超級superpower超級大國 super－ 2. 上superstructure上層建築 super－ 3. 過度，過多superexcitation過度興奮 supra－ 超，上suprarenal腎上腺的 sur－ 1. 上，外，超surcharge超載 sur－ 2. 使成...，加強意義surround包圍 用在r前 sym－ 共同，相同symmetry對稱 用在b,m,p前 syn－ 共同，相同synthesis合成 tele－ 1. 電telecommunication電信 tele－ 2. 遠程telemetry遠距離測量 tetra－ 四tetrachord四弦樂器 trans－ 1. 越過，橫過，超translucent半透明的 trans－ 2. 轉移，變換transport運輸 tri－ 三triangle三角 twi－ 二，兩twin雙胞胎 ultra－ 1. 極端ultrathin極薄的 ultra－ 2. 超，以外ultramarine海外的 un－ 1. 不unfortunate不幸的 un－ 2. 無unmanned無人駕駛的 un－ 3. 非unartificial非人工的 un－ 4. 未uncivilized未開化的 un－ 5. 相反動作，取消unbutton解開鈕扣 un－ 6. 由...中弄出unbosom吐露（心事） under－ 1. 下underworld下層社會 under－ 2. 內（用於衣服） undershirt帖身內衣 under－ 3. 不足，少underestimate估計不足 under－ 4. 副，次underking副王，小王 uni－ 單一unicorn獨角獸 vice－ 副vice－manager副經理 with－ 向後，相反withdraw撤回，撤退 －”s 1. 所有格 (a) today”s今日的 －”s 2. 店舖 (n) greengrocer”s菜場 －a構成複數名詞 (n) stadia體育館 單數以um結尾 －ability可...性 (n) dependability可靠性 －able可...的 (a) inflammable易燃的 －ably可...地 (ad) suitably合適地 －aceous有...性質的 (a) carbonaceou...
發表文章
買腦子都在想理財的應用，看Mr6的小二搜尋引擎，跟之前想的標籤雲的概念很類似。小二搜尋引擎講的是將收集到資料整理成已經可以用的東西。仔細想其實很像資料採礦，這很多人研究但做的出名，我好像沒聽過。他裡面說利用標籤來做整理。但標籤誰來定了，不可能是人工吧。從研究所就看到一堆研究在做網頁語意的檢索了，可用到商業化，好像還沒看到什麼鳥來。但是如果專做一個領域，或許可以做出一些東西出來。金融理財或許是個很賺錢的地方吧！如果搜尋一隻股票，他能整理出他的一份不重複，最完整、最新的東西，直接變成一個完整的報告，而不是散落在不同的文章裡，還要使用者一個一個翻，例如說我搜個台積電，他會像wiki顯示一個錨點秀出他基本資料、技術線圖、看好與看壞的投資分析、持有期間分析、籌碼分析，更重要的是這不是我們提供資料源，而是搜尋所有網路而整理出來的，系統不做分辨這分報告分析的好與壞，由使用者判定，但是分門別類，依時間或標籤做整理，將重複資料與過時刪除或隱藏，做一份完整但簡單的顯示。關鍵技術在語意分析，用人工與系統一起自動貼標籤，是目前大概最多的作法吧！更進階的話，可以依使用者的搜尋習性與思考模式來整理資料，類似之前Mr6提過的以文找文搜尋引擎，因為我們不知道使用者真正的語意與思考模式，由他來評定我們為他找的或整理的資料是不是他想要的，系統紀錄他的思考模式，幫他整理出他想要的資訊，而他不需要一直不停的在相關搜尋頁面翻頁，翻了20幾頁才看到他想要的資料。這完全是我對使用google查詢的抱怨。不過學習系統，這可深奧了。
http://bubbl.us 最近在研究心智圖，我試著找免費的繪圖軟體，無意間找到這個網站。 這個站主要是繪製腦力激盪的圖， visio 也有這種圖。 他非常適合用來討論未確定且需要多方面點子的事情。 這個站酷的地方，就是可以協同作業，也就是可以多人畫一圖。 不過好像還沒辦法即時更新，也就是一邊再作畫，其他人會鎖住。 除非先畫的人離開文件，其他人才能重新取得編寫的權限。 我想到的應用處是像我跟俊賢有一項共同的 KPI 便是訂立部門規範文件， 而我們首要的工作便是訂立部門規範文件項目。 通常一般訂立的作法是，先講好訂立的項目的範圍，就開始提項目。 但是通常 一兩 個小時是很難想出完整項目，常常會卡在那裡不知道有什麼可以做。 而這種網站的好處便是我現在想不到，經過 一兩 天的思考，我或許會想到一些該做的， 當我一想到我便可以上網更新我的想法，而俊賢也可以看到我的新的想法， 他或許會也會有一些新的想法可以加上去，這樣反覆的做，肯定定出來的東西， 想的會比較廣，而時間運用的也較有效率，總比定個時間，兩個想不出東西面對面的發呆的好。 以下是我這個網站做出來初稿。不過我們還沒開過會，訂個範圍。 Best regards, 張丞鈞 Dov Chang 系統工程師 個金產品研發處 System Engineer, Personal Financial Information Products R&D Division 精誠資訊股份有限公司 114 台北市內湖區瑞光路 318 號 T + 886-2-7720-1888 ext 7706 F + 886-2-8798-6020 M + 0913-597-751 www.systex.com.tw
今天改了一個，我之前好像也碰過的一個 bug 。寫一下紀錄一下避免再犯同樣的錯。 程式碼裡面常常利用 vector.size() 來做一些控制，可能要注意一下。 以下是出現 bug 的程式碼。 Int m_nCurrentIndex=-1; if(m_nCurrentIndex >=m_vcsSymbolList.size()) { m_nCurrentIndex = m_vcsSymbolList.size() - 1; } 當 m_nCurrentIndex=-1 時，而 m_vcsSymbolList.size()>0 判斷式竟然判斷正確。 原因是什麼，高手們應該都知道吧，原因很簡單，因為 vector....
http://www.cnblogs.com/babyblue/archive/2004/04/02/5030.aspx 上面這個看起來，比較簡單，好像只要客戶端有裝 dll 就好。 下面兩個沒仔細看。 http://blog.csdn.net/carper/archive/ 2003/04/20 /13736.aspx http://dev.csdn.net/article/66/66438.shtm http://dev2dev.bea.com.cn/bbs/thread.jspa?forumID=97301&threadID=39042&tstart=0 理論上用 web services 就是利用 soap 溝通，也就是要解與寫 xml ，只是他有提供工具可以解和編寫。 這跟利用自訂檔案上下傳沒啥兩樣，只是一個聽起來比較專業。 Bug report 上 我好像是最多 Bug ，關於自選股同步我就先不管啦，我先改 183 的 Bug 。
Cheng-Chun Chang is a master at the Department of Information Management in National ChungCheng University, Taiwan. He was an system engineer at the Systex INC. in Taiwan.His research includes web services, information system reengineering, object oriented techniques ,enterprise application integration and software component techniques.
剛剛跟蘇哥在討論，為什麼不能保留舊介面來測。 根據剛剛討論，我大約了解認知的差異來至對介面修改不同的差異 我講一下我的想法好了。 我仔細想一下，修改介面大致分為三種： 1. 函式名稱修改 2. 函式參數修改 3. 定義變數修改 1.2 的話其實都沒問題，新舊保留應該都 ok 。 如果考慮正確性的問題，那麼提供介面的人應該利用轉藉的方法，將舊函式內容改為呼叫新函式 不過如果一開始就決定一定要拿掉舊介面，這到不用做 4. 單純變數比較沒問題，如果是 enum 其實應該也沒問題，只要提供介面的內部處理也是用變數呼叫而非順序呼叫應該也沒問題 之後拿掉，對其他對應修改的程式也沒多大的影響。 但是如果改的是變數的值，這就麻煩了，但是我覺得不應該這樣改，因為這樣改已經變動了程式的結果。 輸出和輸入結果都可能與原來的介面不同，這就不算是單純替換介面了。 保留舊介面有什麼好處 其實我上次寫的已經說過了。 講講這次主要提的原因，我希望俊彥提供新舊都保存的 dll 理由是我可以不用等蘇哥全部 build 完就可以測試了。 也就是說我 sysset 改完新介面，不用等 Imanager,imain 都改完我就可以測了，我也可以繼續下去其他的工作。 如果考慮新舊的並存的問題，可能造成修改程式碼時漏改，只要俊彥提供給我們的是不含舊介面的標頭檔即可。 這樣就可以利用編譯器檢查了。當然最終版要把舊介面刪除也沒多大的問題，改好的程式應該也不會有問題。 當然可能加重俊彥的負擔（就 mark 舊介面再 build 一次？？） 請注意一個重點，我想表達的是請先用附加新函式或參數，測試無誤 ( 當然指的是包含有用到介面的程式 ) ，再將舊的介面刪除。但是考慮多人共同修改的問題，可以配合給新的標頭檔以配合使用編譯器除錯。 在下 C++ 能力淺薄，如果觀念上有錯敬請各位包含，多多指教。
單元測試終於結束了，雖然之前就預期介面修改會很麻煩，在寫測試計畫與測試時，才真正的體會真的是suffer。僅僅改小小的一段，得了解這段程式碼到底在幹什麼，才知道改了這段對程式有什麼影響，程式碼嘛大家也知道，有時候看半天也不知道到底他為什麼這樣寫，或者他這樣寫會有什麼影響，甚至是自己以前寫的也要花點時間回想為什麼要這樣寫。在寫測試計畫時，在找這段改完會有什麼特徵可以觀察的到。有時候寫在特殊的檢查機制，正常來說不會發生，要測通常得bk配合給錯誤資料或自己在程式碼中作手腳。總之寫測試計畫跟花在改的時間可不遑多讓，有時還覺得毛毛的，有種「這段真的這樣測就好嗎？」的想法。 我一直在想，如果下次要作類似改介面的事，要怎樣作，才能減少測試的成本與錯誤發生的情況。我又重看「重構」這本書有關介面修改和測試的部份。配合「重構」所介紹的方法與我們開發現況，我有幾點建議。 1.舊有的介面暫時不要移除，等整體連結測試完成，再看是否需要移除。 不移除的原因主要有幾點。 a.可階段性修改，測試。 在大幅度翻修介面時，像這次多對多的介面修改，改的初期希望可以先對同樣介面修改 處先作測試，在一步一步修改不同的介面，如果拿掉舊介面，我們必須一次就把他改完才能測試。 b.比對測試。 當舊介面與新介面產生的結果不同時，可以馬上就知道哪裡不一樣，也可利額外的測試函式來進行比對。 c.配合舊有程式邏輯 有時候舊程式邏輯是配合舊介面所得出的資料，而且大部來說更改舊有程式邏輯並不是好的修改方法（太複雜了），通常我們會把新介面的資料改成跟舊介面所得資料一樣，當有舊介面時，我們就可以較容易比對、產生相同邏輯的資料。 當然把舊介面移除有時是控制舊介面的遺毒不要殘留，在「重構」這本書建議說有時介面替換太複雜或牽扯太多，無法一次移除介面，可以利用thorw error的方式並標注不建議使用，來強迫使用介面者必須使用新介面或catch error。不過書中改介面的流程也是在測試完才把舊介面移除。 2.利用中介（轉藉）函式作二段式修改，像GetTWSECategoryIndex(TWSE_SERVID, CBK_CAT_ALL, vcsCat)這這舊函式，vector同時回傳包含長名和短名的資料，遺憾的新介面並沒有提供這樣的功能，因此在改的時候我們通常要將他轉為我們需要的格式，而...