第一個低潮來自於轉職，因為跑道轉換，以往所培養的整套開發工具與流程，裡面的許多節點，不再適宜繼續使用，因而變得支離破碎。結果就是，做什麼都卡卡的，不斷地得重新製造螺絲。慶幸的是，螺絲僅須重新製造，無須重新發明。

不過，匆促地重新製造螺絲，也不是好事，畢竟從頭開始，是個很好的機會，檢討改進原先不良之處。還好，目前的工作環境，鼓勵使用適合的外來組件，重視的是達成目標，既沒有 not invented here 症狀，亦對新事物 open minded，所以一切尚可。再加上在 linux 上開發軟體，一整個輕快方便，不像在 Windows 上那樣，總之就是一個爽字。

不過我敗了新 Mac，這是夢想已久的玩具，入手一天多來，發覺真的有很多東西需要慢慢習慣。舉例來說，Mac 的鍵盤與 PC 不甚相同，現在我用 irssi 上 IRC，要切到 window 11 的時候，總會習慣性地不小心按成 ⌘-Q，把 Terminal.app 關掉。

因為要習慣以前沒碰過的 mac 環境，因此我發覺，生產力又陷入了第二個低潮。雖然說 Mac OS X 可以說是最適合 developer 的系統，但是在習慣之前，使用效率一樣還是很差啊。

因此，在最近總是接到很趕的工作項目的時候，這台新 mac 暫時變成了雞肋，越摸越會拖慢開發速度的玩具。還好換到新工作後，坐捷運的通勤時間比例變長了，也幾乎都能有位子坐，讓我有玩耍雞肋的時間，慢慢把生產力培養起來。

將要去的公司，是當年找國防役時，我的第一志願。隨然時過境遷，現在與當年，篩選公司的條件與想法，已經完全不同了，再也沒有志願一說，只剩各種選項的權衡。不過，未來的公司，還是很令我滿意。至少，那應該會是一個，聽得懂我的專業的公司。

交接的工作，已經快要告一段落。我寫文件的速度其實不甚快，但零零總總，至今也寫了七十多頁。如此，應該算是已經盡到責任了吧。Brain copy 是不可能的，文件也只能夠作到提示與方向指引。

話說，內湖捷運就要通車了呢，結果待了五年，我要離開內湖了。公司有供應午餐，在地下室，搞得這些年，其實對內湖不太熟。要不是結婚後有在內湖住過一陣子，我對內湖的印象，可能還是模模糊糊的吧。

換工作，就像換情人一樣。慢慢地把與舊情人的牽扯濾清，不要留下遺憾，也不要留下怨懟。應該要把一個乾乾淨淨的自己，交到新情人手上。

嘿，我，加油喔。

碎碎念一則。頭部用嘴巴做管理，基本上 OK，但若是講太快手跟不上，那是一定會出問題的。

哼哼，一切都是註解太多的錯。

另一個錯的是 Windows Programming 的 style，要不是已經把 error handling 另外濃縮處理過了，否則不含註解的部份，還要再膨脹個 5 倍左右。

在工作上，有時候會聽到這樣的怒吼：「吼～又是你的 assertion 把程式當掉。」可是，細查之後卻又發現，之所以會 assertion failure，是某個應該存在的值不存在，或某件事情在之前就失敗了，於是當程式執行到 assertion 處，一檢查就發現問題，然後把程式當掉。

Assertion 之所以存在，為的就是希望能夠揪出，所有不應該存在的異常情形，是故，assertion 其實應該是多多益善，埋的越多，越有機會揪出程式的不良之處。所以，我很喜歡埋 assertion，凡是無法處理的特殊輸入、必須存在的情境參數，甚至是失敗就等於整個程式根本無法運作的 API 呼叫，我都會使用 assertion 以便盡早地把程式當掉，輔助我們揪出錯誤的發生點。

問題是，當 assertion 發生時，總是要有某個人負責去找出問題的成因，而理所當然地，在只有 assertion failure 這條線索的情況下，問題就被丟給寫 assertion 的人。但因為 assertion 通常是用來抓「不是在此處發生的錯誤」，因此產生了這麼一個吊詭：

越認真地(寫程式)使錯誤顯現的人，反而越容易領到爛攤子，必須承擔解決(多半)不是其程式所造成之錯誤的責任。

一般來說，程式設計師比較喜歡寫新程式，而不喜歡維護舊程式，更討厭的就是負責維護不是他寫的舊程式，所以上述的吊詭，等於是在懲罰認真的人，而且是越認真(埋 assertion 炸彈)，等著的是越多的爛攤子。

也就是說，可以討論的，應該是 assertion 的標的是否合適，而不是 assertion 是否應該把程式當掉。只要標的合適，當程式當掉時，我們該慶幸，assertion 讓我們發現，程式會當掉，而不是等到移交給客戶後，隱藏的炸彈才一個一個爆發。

面對體無完膚，多個臟器破裂，到處都是還沒找到的破洞，在這個情況之下，這種內出血嚴重的程式模組，code review 已經沒有用了。

更別提原作者在會中，一直嚷嚷，看起來都沒問題啊。XD

2009-03-23 13:00 更新：補一下這篇《The only valid measurement of code quality: WTF/m》。

Do not call error handling function with new thread, that will cause chance dead lock after foo().

還有這句：

Call client RPC for tell stream initial done.

雖然說缺乏註解是常態，所以看到的機會不多，但每次一入眼，臉總還是會微微抽動。

與秀才辯論，敗了也沒關係，真理通常是可以辨得出來的，只要把持心中的那把尺，不放棄，即使不如初衷，但也更合道理。

但是面對兵，不值得花上一絲一毫的腦力。能夠直接忽略最好，但如果不行的話，千萬別傻到動手去證明自己是對的。

愛用 .lib 嘛... 爆炸吧！

愛亂用 global variable 嘛... 爆炸吧！

愛亂 call function 嘛... 爆炸吧！

愛 copy & paste 嘛... 爆炸吧！

喔耶，我聽到 windiff 了，爆炸吧！爆炸吧～～～

2007-05-16 更正：不是「愛用」.lib，而是有原因的。雖然說那個原因在不知不覺中，已經消滅了。

煉獄指數：45

你覺得目前的工作有些貧乏，也似乎到了一個瓶頸。有時覺得這份工作不算太差，有時覺得自己真要這麼繼續過生活嗎？換工作跑道是心中一直猶豫的議題，不熟悉的職場領域和環境、擔憂自身能力不足、不知道未來會不會更好，這些都是心中拉扯的因素。建議你多和工作場合以外的人接觸，拓展你的生活領域，相信你會從這些人得到一些對未來的啟發和靈感，以及找到屬於自己的勇氣。

你的職場瓶頸會發生在三種狀況：一、老闆沒有授予你足夠的權力，讓你好好發揮，使你心生鬱卒；二、工作上權力的鬥爭讓你窮於應付；三、老闆信任你的能力，賦予你過多的期望，導致工作量過大，身心難以負荷。

你具備強烈扭轉劣勢的能量，因為你是一個樂觀正向、不逃避問題、善於面對自我的人，因此當困在職場上時，你的韌性會為你贏得最後的勝利。

據說下一個案子我可能要和大陸的 RD 同事合作，忐忑不安中。:-p

確實，我是有很多「可是」的，但我也知道，這些都可以算是藉口...

• 文件上沒寫，誰知道 GetSystemTime() 在 WinCE 裡抓不出 milliseconds？配上 eVC 那超慢的 download 速度與超高的失敗率，以及 99% 會失效的 debugger，兩天的時間就這樣浪費掉了。
• Porting 當然是要按照原本 function 的 behavior 改寫，按照原本程式的介面邏輯，在目標平台找尋對應 API 完整重寫。這當然是「正確」的事，可惜卻是屬於「政治不正確」的一種。Conceptual Integrity 在某些目標導向的情境下，常常是可以被犧牲的一項。以結果論英雄以證明抄捷徑才是正確的，我可以預見未來必定沒有機會補洞，但我沒有權力反對。
• 有時候碰到那種，說起來很簡單，但其實挺複雜，但對主管來說，又只需要知道很簡單的部分的東西時，還真的是挺讓人無奈只好硬吃黃連的。結果可想而知：「這不是很簡單嗎？不就是在那段 code 的前後記一下時間，相減取得所耗費的時間，為什麼會搞得這麼複雜，還花上半個星期的時間弄？」是啊，但是我必須為了 porting 找解法、測試，為了讓結果能夠印出來，思考良久以決定究竟該不該打洞抄捷徑，更別提中間還穿插為了與正因興起而被大整頓的 Visual SourceSafe repository 之間同步程式碼，而不得不斷地被打斷的開發過程，以及額外支援的抓網站小程式。
• 平心而論，對於同期或後期的同事，基本上其實我確實是沒有把來自他們的 coding request 放在心裡很重要的地位。但相對來說，雖然說看起來我未來暫時只會有一個頭頭，實際上的情形仍然將會是，來自前輩的交辦事項，還是得認真回應。單一擋箭牌的好處在單一，但缺點也在單一。讓我感到落寞的，正是在此。花了一年學懂了在三個頭頭下做事的方法，可惜又花了一年，才從錯誤中領悟到無兵之將的真正意涵：無兵之將還是兵。未來我有辦法在一個頭頭之下，用對方法態度行事嗎？我不確定，在必須將大部分精力以工程師性格的方式展現的情境下，能有多少心思保護自己不再吃暗虧。

工程師的宿命是，要不就 work longer (加班)，然後讓肝爆掉，要不就 work harder (拼命)，讓胃穿孔。Work smarter 真的是藝術啊，還是讓別人的肝爆掉，胃穿孔才是王道。怎麼說呢？好歹自己也念了兩年資管，算是和管理有沾到邊了，然後這幾年看著老爸念 EMBA，我漸漸地有了這樣的想法：因為學管理的比較懂做人，所以作管理時就拼命地教下面學做人。會這樣想當然是覺得這是不對的，怎麼做事，和怎麼做人，是一樣重要的。問題只是，做事的人多半不懂得做人，而會做人的人，則多半不懂得做事，如果只是讓專業的傲慢決定做事或做人何者重要的話，那的確是會變成裡外不是人。

其實，「政治正確」我也不是嗅不出來，對於自保用的心機，我也不是一無所知。但在個性與價值觀的雙重作用之下，我也許還得再經過多年的挫折，才能學懂如何在專業的堅持與工作的目的之間取得平衡，又或是學曉如何放棄。

拜讀 Jserv 的這篇《思索 C++》，裡面引的這句「just say "No" to bad old platforms」挺有意思的，可惜在軟體工程上，決定一切的通常不是技術因素，而是「錢」。「錢」最為優先，次之為「人」，最後才是「技術」。

小弟我有幸身在一個比較沒有市場壓力的研究單位，因此不需要直接面對「錢」的問題。但相對地，「人」的問題，便首當其衝。這兩年來的整理思考，讓我明瞭了，在實務工作上，除了常要 cross platforms 外，還常常需要 cross programmers，不僅 platform 要跨，連 programmer 也要跨。期待所有會使用到你的程式的 programmers 都能具有某些基本能力，就跟期待碰到的 platforms 可以支援基本的 C99/C++98 一樣，緣木求魚。

更慘的是，我們無法 just say "No" to bad old programmers，因為，不僅 team members 會碰觸到你的程式，你的 customer 也有可能會碰到你的程式。在客戶至上的大前提下，是沒有可能因為客戶不懂 template，就 just say "No" to dummy customers 的。最終，還是得弄出一套 pure C 版本朝聖才行。喔，客戶的問題可能還好解，大不了另外寫個 library 包一下就好了，更可怕的是，你完全有可能會碰到你的 mentor 這樣跟你說：「能不能不要用 C++ 寫，我看不懂。」

十八般武藝，樣樣俱全，我總是這樣地期許自己，所以自大學時代開始，便東摸摸，西摸摸，舉凡 C/C++/Java 等一拖拉庫語言，到資料庫、物件導向、軟體工程、網路應用、UNIX/Windows programming、System Administration，有機會摸的至少都摸了兩下，摸到現在，總算是混到個雖樣樣不精，但也能得過且過的樣子。但直到現在才發覺，真正的十八般武藝，根本不是這些。作為一個 programmer，我們還需要一點口才，好說服老闆，唬弄客戶，教育同事，也還需要一點行銷技能，以避免 sales 的敷衍與出賣，更需要懂些法律，以便自保也保公司。

這年頭，日子真難混。

1. 使用 __stdcall 搭配 .def 檔製作 DLL VC 製作 DLL 的方法。

有兩種方法。

第一種方法是使用 __declspec(dllexport) 宣告要 export 的函式，讓 VC 幫忙製作 stub library，這時預設使用的 calling convension 是 __cdecl。這樣宣告後，VC 會產出 libFoo.dll 與 libFoo.lib 兩個檔案，其中後者就是所謂的 stub library，VC 會自動於 stub library 裡製作對應到 libFoo.dll 裡 _funcFoo 這個 symbol 的 __imp_funcFoo。

這個方法的好處是，在 VC 裡的 project 有 dependency 時，會自動 link 所 depend 的 .lib 檔，使用起來非常方便。

第二種方法是使用 __stdcall 而不用預設的 __cdecl calling convension。Windows API 即是以 __stdcall 的形式存在，若有 #include <windows.h>，也可以用 WINAPI 這個 macro 代替。使用 __stdcall 就不需用 __declspec(dllexport) 宣告，而是必須自行製作 .def 檔案，詳列要 export 的那些 symbols。

由於 VB 只能接受使用此法製作的 DLL，所以我們必須選擇此法。缺點是，製作 .def 檔，當函式一多時，非常麻煩，且對於要 export 的 C++ class，更是複雜，畢竟我們很難人工處理 VC 的 C++ name mangling。

2. 處理 VB 到 C/C++ 之間的型別轉換

VB 與 C/C++ 兩者之間的型別對應，詳見 MSDN，記住幾點原則即可。

首先，VB 的 ByRef 相當於 C/C++ 的 indirect by pointer。所以 C/C++ 的參數若為 pointer 型別，在 VB 便用 ByRef 對應。不過我不清楚像 int*** 這種型別，究竟該怎麼對應就是了。

再來就是，C/C++ 的 char* 對應到 VB 直接是 ByVal As String，因為 VB 的 String 採用 BSTR 的機制，與 C/C++ 的 string 可以相容。只有兩點必須注意：

• VB 的 String 不以 '\0' 結尾，而是前冠以長度的 header。因此，從 C/C++ 的 DLL 獲得 String 後，必須用 foo = Left(foo, InStr(foo, vbNullChar) - 1) 將 '\0' 之後的部分去掉。
• 若要傳 output string buffer 進 C/C++ 的 DLL 時，記得必須先製作好該 buffer，否則若 VB 的 String 只有宣告就拿來用，便只是相當於只是傳入一個 NULL。製作 buffer 的方法為：foo = String(BUF_SIZE, vbNullChar)，其中 BUF_SIZE 為 buffer 所需的長度。

3. 記得設定 C/C++ DLL 的 locale

在 VB 裡，會自動依據所處的 OS 所設定的 locale 而設定 locale，但若呼叫的 DLL 內需要正確的 locale 環境時，便會有問題。因為 VB 設定的是他自己的 locale，而不是 C/C++ 的 locale，因此雖然在 VB 裡的 locale 是對的，但在 C/C++ 寫成的 DLL 裡，locale 仍然是錯的。因此，要記得在 DLL 裡提供對應到 setlocale() 的 export function，讓 VB 可以事先呼叫，設定 C/C++ 的 locale 讓 DLL 用。

第三點害我今天花了半個下午 debug，累，不過總是把技術問題都搞定了。

 Error 53: File not found libFoo.dll

的訊息。

後來查到《Bugs: Error 53 when calling functions from custom DLL》這個網頁才知道，是 libFoo.dll 所需要的 libBar.dll 忘了複製過來的緣故。 不過，這什麼鳥蛋 error message 啊，一點提示效果都沒有，難怪查到的網頁要用 Bugs 開頭。

看了一下 MSDN 裡 VB6 的 error code 列表，少的可憐。寫 VB 真的要自求多福才行。

• Incremental construction - 有用到的 feature 再加，慢慢累積。
• Homogeneous across languages - 橫跨若干 programming language，不同於 C# 的 CLI，只求用法、API 長相差不多就好。目前用到的有 C/C++、Perl、PHP、SH 等程式語言。
• Cross-platform if possible - 盡可能地隱藏 cross-platform 的細節，目前可以橫跨 FreeBSD/Win32 以及 GCC3/MSVC6。不過因為 incremental construction 的發展準則，尚未 porting 的功能，會產生 pre-processor-time 或 run-time error。
• Privode both C/C++ interface if possible - 盡可能地為 C/C++ 推出不同介面，對應功能的版本。

就在剛剛，我做了第一千次的 commit。因此趕緊來賽豬公一下：

SHELL> svn log -r 1 svn+ssh://mmi.jeffhung.idv.tw/svn/libMMI
------------------------------------------------------------------------
r1 | jeffhung | 2004-04-19 17:45:19 +0800 (Mon, 19 Apr 2004) | 2 lines

*** empty log message ***

------------------------------------------------------------------------
SHELL> svn log -r HEAD svn+ssh://mmi.jeffhung.idv.tw/svn/libMMI
------------------------------------------------------------------------
r1000 | jeffhung | 2005-08-12 13:17:46 +0800 (Fri, 12 Aug 2005) | 2 lines

Add ::mmi::util::version class.

------------------------------------------------------------------------
SHELL> svn export svn+ssh://mmi.jeffhung.idv.tw/svn/libMMI/trunk/libMMI
...
SHELL> cd libMMI
SHELL> sloccount .
...
SLOC    Directory       SLOC-by-Language (Sorted)
13093   test            cpp=12669,ansic=424
10787   include         cpp=8838,ansic=1949
5764    src_top_dir     cpp=5764
2750    src_mmi         cpp=2750
1898    perl            perl=1898
1123    src_mmi_locale  cpp=1123
912     evaluating      cpp=912
857     src_mmi_string  cpp=857
363     top_dir         ansic=255,sh=108
183     php             php=183
122     src_mmi_utils   cpp=122
34      src_mmi_textproc cpp=34
11      sh              sh=11
0       doc             (none)
0       image           (none)
0       xsl             (none)

Totals grouped by language (dominant language first):
cpp:          33069 (87.26%)
ansic:         2628 (6.93%)
perl:          1898 (5.01%)
php:            183 (0.48%)
sh:             119 (0.31%)

Total Physical Source Lines of Code (SLOC)                = 37,897
Development Effort Estimate, Person-Years (Person-Months) = 9.09 (109.08)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.24 (14.87)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 7.34
Total Estimated Cost to Develop                           = $ 1,227,939
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount is Open Source Software/Free Software, licensed under the FSF GPL.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."

可惜 Subversion 沒有如 cvsplot 的工具，要不然就可以畫漂漂圖了。

Core library 還真的只作核心的功能，幾乎毫無控制的機制，搞得我必須自己同時維護兩個 thread，各自有各自的 task queue 要持續不斷地進行任務，同時還要必須隨時能夠暫停、復行、終止、啟動、新增任務、插隊、任務重新排序，以及取得目前工作狀態。

另外還有永遠列不完，寫不完的內容修正規則要弄。而這一切，必須要在一個禮拜之內完成，而這一個禮拜裡，有一半的時間必須抽出來，去支援另外一個專案的文件撰寫，零零總總加起來共一天的時間要用來開會，一天颱風假放掉了。就算我有能力在這一年半裡，除了主要的專案之外，另外寫一個五萬行的多語言輔助程式庫，也沒有能力在不到兩天的時間內，寫完這所有的功能啊！

不行，明天得先找老闆談談才行。不過想到要跟老闆解釋，這裡面的複雜性，好難。:-(

貓部大概是無意間逛到了我的 Blog，留了個言，提到：

而事實上, 花很多心思去榨出那5%, 10%的效能, 花的時間力氣可能遠超過說服老闆用好一點的hardware/software, 這是很悲哀的. 有時不如花這些時間去跟老闆social一下, 對前途還比較有幫助, 哈….工作這麼多年有感.

之前也有類似的經驗。因為我們的辨識引擎還不夠快，所以資深同事打算用 SIMD 靠硬體架構拼效能。我很不以為然，不是因為這樣就會與硬體相依，而是因為在現在的 CPU 架構裡，pipeline、prediction 一大堆，cache 機制、大小也各有巧妙，我才不相信自己搞可以搞的好。

果不其然，在效能瓶頸處改用組語寫 SIMD，結果讓程式的整體速度更慢了。所以我就推薦改用 Intel C/C++ Compiler 試試，在網頁上申請之後，可以有一個月的試用期。如我所料，要靠硬體拼效能，手算是比不上 compiler 算的。換 compiler 帶來的，是 10% 的效能增進，執行速度比 MSVC++6 編譯出來的執行檔，還要少了 10% 的執行時間。

Intel C/C++ Compiler 才一、兩萬台幣，可以永久使用，加買 Support Services Renewal 的話，期限內還可以免費升級。比起 case-by-case 讓工程師花昂貴的時間ㄍㄧㄣ效能，還不一定能夠成功，要來得划算多了。