大概是幾年前，偶然間接觸到Yujin的備長碳系列轉蛋後，開始迷上日本的轉蛋盒玩，那些小小的可愛的Q版造型，每每看到就令人愛不釋手。也常覺得在日本的愛好者真幸福，能有一個龐大的動漫產業支撐，讓如此多公司不斷的輸出這種可愛的東西。

台灣最能引起公仔迷討論跟話題的 恐怕大家馬上會想到霹靂系列，我還記得激鬥一出的時候，跑遍我家四周幾家超商，沒一家有貨的情況。激鬥二也是相同，跟朋友走了七八間超商沒買到一隻，那時心中的怨啊(雖然對激鬥二比較沒那麼欣賞，可是還是很嘔的)。

以上可以算是廢話，進入正題吧，公仔交換天地(https://www.ragic.com/gashaou/gasha-exchange)這網站怎麼用？首先如果是依我給的網址進入網站的話，你的畫面應該會像這樣：

左下角是各功能的頁籤，如果你是要發徵求文，或是要交換的話，點擊對應的頁籤就可以到各功能去了。因為三個功能操作其實都差不多，這篇文章主要就用賣公仔來說明這個網站的使用方式。

承上圖，在網頁右下角的地方可以看到【簡明】跟【試算表】兩個連結，點選這兩個連結可以切換顯示模式。現在看到的圖是簡明模式(預設也是簡明)，按下試算表這個連結後畫面會變成像Excel那樣。大家可以依自己的喜好來切換試試，我個人是比較喜歡試算表的顯示方式…。

以上都是功能切換的部份，接下來是重點，如果我想要賣一隻公仔，這時候可以直接按下網頁左上方的新增一筆，就可以直接進入資料的登記頁面，如下圖所示：

其實網頁上我有寫了一些說明了，應該很容易就了解，不過在圖裡還是把可以輸入的地方用紅框標示出來，目前我發現交易狀態這個欄位好像有些朋友會漏填，不太確定是因為欄位的位置不明顯導致漏選，還是其他什麼原因(有人能來信跟我說嗎 XD)，總之建議要選喔，這樣其他人要搜尋會比較方便。另外也建議把物品狀況跟你所能接受的交易方式寫清楚，相信我，這會大大增進交易效率的。

說實在，這麼簡單的功能，我還蠻佩服自己能把說明寫得這麼囉嗦的。另外要提醒大家，對交易的內容跟對象還是要有警覺心，如果發現情形不對就停止交易吧，畢竟現在詐騙太多了。

說到這裡，有沒有注意到到目前為止，所有功能都不需註冊就可以使用…:p，其實是因為根本沒有註冊功能…開玩笑的。請大家看網頁右上角吧，想註冊的朋友點下那個註冊連結，輸入帳號密碼跟email就可以註冊了。

那註冊了能做什麼?

單純以我做的這個站來說，目前有註冊的好處是可以修改自己過去輸入的公仔資料(例如前面說的，交易狀態漏打，有註冊可以回來修)。其他比較重要的就跟 Ragic這個平台所提供的功能有關，這可能就不是 一篇文章可以講完，以後一定會多介紹的(總是要給作者外出取材一下吧…)。

P.S. 以後公仔交換平台有什麼更新或是新增功能，我都會在這個部落格介紹的，謝謝大家收看，下回再見。

我從高中時看五月天、阿妹的演唱會到現在，不知不覺也十個年頭囉！當年為了搶票、佔好位子，在大太陽下排整天的隊，好青春啊！現在表演場地比較好了，都有劃位，不必一早排隊等進場。不過票還是一樣難買！然而跟據我的經驗，其實一開始沒買到也不用太傷心。接近表演時間，還會有些朋友會臨時有事要忍痛割愛。我之前都會到該歌手的 Ptt 看板來找這些資料，不過看到板主手動幫忙整理這些資料，只能大力讚賞板主的熱心，真的是太辛苦了。

而接觸到 Ragic Builder 這個方便的開發工具之後，我就馬上想到可以做個平台讓大家交換門票。
成品在這邊：http://www.ragic.com/ptt/ticket
大家可以依照欄位條件快速篩選出自己想要的資料。有需求的人可以新增資料上去，用自己的 E-mail 做身份認證，之後不需要申請帳號也能再修改資料或更改交易狀態。

介面操作還滿直覺的，不清楚的可以參考這個教學「五分鐘上手Ragic」：
http://dev.ragic.com/wiki/index.php/Ragic_in_5_Minutes/zh

針對短時間資料量比較大的活動，像演唱會之類的，我另外做了一個相似的平台可以讓大家安裝，能夠針對活動客製化，可以幫管理者省下不少工夫，大家搜尋資料也可以更有效率，就不必在推文海中看到眼睛要脫窗。現在也已經上線可以安裝了！

這邊可以試用系統：
http://www.ragic.com/gallery/community/ticket/Exchange?d=TEX

下面說明怎麼把系統裝到網路上讓大家用：
1. 先到 Ragic 的網站註冊一個帳號 http://www.ragic.com/。
2. 進入自己的桌面後，從「資料庫展覽」->「社群」->「票卷交換平台」來選擇安裝。
3. 進入資料庫後從下方選到「場地票價」，先把各場地的票價跟區域輸入進去，之後大家就可以用下拉選單來選擇。
4. 再到「演出場次」把各場次跟演出場地的資料輸入進去。
5. 把標題用「編輯描述」的方式改成你的活動名稱。

如此就完成設定了，可以先輸入幾筆測試資料測試一下，沒問題就可以把連結給大家，讓大家來使用了！
連結大概會長這樣 http://www.ragic.com/[你的帳號]/[你安裝的位置]

在設定過程中你可能要修改下拉選單，不知道怎麼操作可以參考這邊：
http://dev.ragic.com/wiki/index.php/Input_Type/zh

編輯標題、描述的方法可以參考這邊：
http://dev.ragic.com/wiki/index.php/Editing_Descriptions/zh

有問題歡迎回覆討論喔！祝大家使用愉快！

常常在系統裡面都會有一些工作執行起來特別花時間，比如說寄送e-mail，或是寫入複雜資料到資料庫中等等。在一般系統中如果沒有特殊處理的話，會造成使用者在使用的時候感覺很慢才有回應，而回應其實只是一個簡單的執行完成的確認。

這時候非同步處理這個好用的技巧就派上用場了，如果我們 能夠讓使用者執行這個動作的時候，不用真的等到他完成再return回去給使用者，其實只要被呼叫的程式確認已經收到了指令跟參數，就可以回應了，而實際 上執行工作的任務就交給另一個thread來處理即可。

要怎麼做到這點呢？筆者過去看過了不少有趣的解決方式，常常看到一些資料庫的愛用者的作法，就是開一個table，然後把一筆一筆要執行的指令內容塞到這個table，然後由另一個thread來定期掃這個table未執行過的指令， 找到還沒執行的指令就把他執行。這也是一種解決方式啦，只是感覺為了執行指令還要維護一個table麻煩了點，而隨時去掃瞄table效能也差了一點。

比較聰明一點的開發者就會想了，那我們在記憶體裡面作一個queue來記錄包成物件的要執行的指令就好啦，就不必寫在資料庫裡面。但是執行方式也是一樣，我們開一個thread每一定時間執行一次來掃這個queue執行還沒執行過的工作。這樣效能是不差，但是還是沒辦法達到趨近於及時的效果，也就是說至少都還是得等一定時間系統才會來執行這樣的工作。

其實有一個更簡單的解法，這樣的queue通常根本不必自己寫，有一種東西叫做 Blocking Queue，也就是說他是一個會把thread lock住的一個queue，什麼時候會lock住呢？就是在這個queue東西被清光的時候。

也就是說，這個queue的使用方式很簡單，我們要執行的工作包成物件跟之前一樣就把他丟到這個Blocking Queue裡面，而另外我們起一個thread在一個迴圈裡面不斷的從Blocking Queue中取得下一個要執行的工作，如果queue裡面已經沒有工作可以給這個thread作了，這個thread就會被queue停住，直到有下一個工作丟入queue中，才會把thread叫醒，繼續執行工作。Java文件中有的簡單用法大概如下：

class Producer implements Runnable {
   private final BlockingQueue queue;
   Producer(BlockingQueue q) { queue = q; }
   public void run() {
     try {
       while(true) { queue.put(produce()); }
     } catch (InterruptedException ex) { ... handle ...}
   }
   Object produce() { ... }
 }

 class Consumer implements Runnable {
   private final BlockingQueue queue;
   Consumer(BlockingQueue q) { queue = q; }
   public void run() {
     try {
       while(true) { consume(queue.take()); }
     } catch (InterruptedException ex) { ... handle ...}
   }
   void consume(Object x) { ... }
 }

 class Setup {
   void main() {
     BlockingQueue q = new SomeQueueImplementation();
     Producer p = new Producer(q);
     Consumer c1 = new Consumer(q);
     Consumer c2 = new Consumer(q);
     new Thread(p).start();
     new Thread(c1).start();
     new Thread(c2).start();
   }
 }

這樣的blocking queue其實自己實做起來還算滿簡單的，筆者當初想到這種解法的時候便自己implement了一個Blocking Queue來達到這樣目的，不過一陣子後就發現Java 1.5以後，standard library裡面就給了一個Blocking Queue來給你使用。就更省事更不會出錯啦！

最近常常有朋友問筆者：你們一個月租伺服器花多少錢？而回答以後朋友總是一副無法置信的表情……怎麼會這麼便宜？其實沒錯，就是真的這麼便宜！（我好像在拍廣告）

過去租伺服器，從買主機、主機代管、租網路專線，都是一大筆費用，因此很多比較資深的資訊人員已經很習慣性的認為維護一台伺服器的成本就是這麼高。但是近年來虛擬化的技術成熟的相當快速，一台機器可以透過類似Xen等工具，切成幾個到幾十個虛擬主機來出租，每一個虛擬主機在功能上使用起來，都跟租了一台自己的獨立主機一模一樣。但是價格卻是過去的一點點而已。

這種服務就叫做VPS (Virtual Private Server)，也就是虛擬的私人主機。過去專用伺服器其實多半有個問題，真正會把一台server資源隨時快要用完的人很少，大家使用量變化都很大，常常一天甚至一個月都沒有什麼負載，但是有事情負載一來就會多到應付不來。在VPS上面有一個好處，大家都是鄰居，如果大家都閒閒的沒在用CPU，那如果有人突然很需要CPU，其實就可以暫時把沒在用的CPU power借給他使用，反正自己也沒吃虧，有一天自己需要比較多的CPU cycle的時候，運氣好就要的回來啦！

VPS還有一個很大的好處在於你的系統都是跑在一個一個的image上，因此隨時要換伺服器都非常快速方便，筆者使用Linode的經驗，換伺服器多半在半個小時以內就可以執行完畢，並且原本所有安裝的東西都會一模一樣的狀態拷貝到新的伺服器上，因此其實可以隨時根據使用量，來搬到適合大小的伺服器，達到最好的經濟效益。不必為了怕一兩年後一堆人要來使用，就得先用一台很貴的伺服器。

VPS 其實特別適合安裝起來比較複雜的系統，一般如果單純寫PHP/MySQL，或是架Blog，用PHP的hosting就很便宜很夠用了。但是如果是寫比較複雜或特殊的系統，有一些hosting沒提供的設定跟安裝，那麼使用VPS可以說是你唯一的選擇。跟一般的shared web host的最大差別就在於，使用VPS你可以有系統的root權限。同樣的，你必須懂得如何管理一台Linux伺服器，相反的來說，優點也應該是你會去漸漸熟悉如何管理一台Linux伺服器。

而目前兩家筆者過去稍微比較過，也都實際用過的VPS，一家叫做Linode(http://www.linode.com)， 另一家叫做Slicehost(http://www.slicehost.com)。 他們的方案多半是月租，然後以你使用的VPS裡面有多少記憶體、硬碟、每月網路傳輸量，來決定你一個月多少錢。實際價格我就不多說了，只要點進這兩家的網頁就會有他們的價目表。

筆者目前主要租用的是Linode，感覺品質跟服務都還算滿不錯的，如果有興趣的話，可以用以下的連結來購買，讓筆者賺一點點介紹費囉！
http://www.linode.com/?r=29b631ced0c63bf8e83307740b40cff789d4153d

好幾次筆者跟一些有滿多年Java開發經驗的朋友聊到如何去診斷系統為什麼會卡住、系統為什麼會突然很慢、為什麼突然會一直吃掉100%的CPU等問題。 滿驚訝的發現，不知道怎麼使用thread dump這樣的工具來確認系統停在哪一行的人，比率還相當的高！有了這樣的工具，可以大大簡短系統問題分析的時間。

Thread dump簡單的說就是把目前所有JVM裡面正在跑、正在等待的thread執行的stack trace通通印出來，就跟一般我們在作Exception.printStackTrace印出來的東西類似。但是你可以在系統正在執行的狀態，去主動叫系統印出這樣的資訊，這時候我們就可以看每一個thread目前正在執行什麼東西，有哪些看起來比較可疑，可能是出問題的地方。

首先要怎麼樣產生thread dump呢？在Linux底下，可以使用” kill -QUIT <process_id>”的指令，針對目前正在執行的Java程式process id來下產生thread dump指令。如果在Windows底下，就在正在執行這個java程式的視窗底下，按下<ctrl><break>，便會產生 他的thread dump。而thread dump通常會出現在系統的標準輸出裡面。

要怎麼樣來研讀stack trace呢？以下是一個thread dump的例子：

"Thread-5" (TID:0xee703b78, sys_thread_t:0xee261db8, state:R) prio=5
        mythread.stopper(exec3.java:10)
        mythread.run(exec3.java:16)
    "Thread-4" (TID:0xee703bb8, sys_thread_t:0xee291db8, state:R) prio=5 *current thread*
        mythread.stopper(exec3.java:10)
        mythread.run(exec3.java:16)
    "Finalizer thread" (TID:0xee700220, sys_thread_t:0xee2c1d b8, state:R) prio=1
    "Async Garbage Collector" (TID:0xee700268, sys_thread_t:0 xee2f1db8, state:R) prio=1
    "Idle thread" (TID:0xee7002b0, sys_thread_t:0xee3c1db8, state:R) prio=0
    "Clock" (TID:0xee700088, sys_thread_t:0xee3f1db8, state:CW) prio=12
    "main" (TID:0xee7000b0, sys_thread_t:0x693a0, state:CW) prio=5
        exec3.main(exec3.java:32)
Monitor Cache Dump:
    mythread@EE703BB8/EE74E190: owner "Thread-4" (0xee291db8, 1 entry)
    mythread@EE703B78/EE74E270: owner "Thread-5" (0xee261db8, 1 entry)
    <unknown key> (0x693a0): <unowned>
        Waiting to be notified:
            "main" (0x693a0)
Registered Monitor Dump:
    Thread queue lock: <unowned>
    Name and type hash table lock: <unowned>
    String intern lock: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class loading lock: <unowned>
    Java stack lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Has finalization queue lock: <unowned>
    Finalize me queue lock: <unowned>
    Monitor IO lock: <unowned>
    Child death monitor: <unowned>
    Event monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
        Waiting to be notified:
            "Clock" (0xee3f1db8)
    Sbrk lock: <unowned>
    Monitor registry: owner "Thread-4" (0xee291db8, 1 entry)
Thread Alarm Q:
    sys_thread_t 0x693a0   [Timeout in 9997374 ms]

首先我習慣找的是，裡面有沒有正在執行我們自己寫的程式，畢竟錯出在自己身上的機率，常常還是比較大一些。接下來可以找有標明*current thread*或是state=R (Runnable)狀態的thread，這代表他們正在執行中，系統的問題也可能出現在他們身上。

有時候這樣還是沒辦法來確認問題到底出在哪，畢竟常常比較大型一點的系統，同時在跑的thread非常多，要猜說問題在哪裡可能要猜很久。另外一個會使用的技巧是，在系統正常的時候產生幾個thread dump，另外在系統不正常的時候也產生幾個thread dump。如此一來我們可以比對一下系統正常與不正常的時候的差異，有哪些thread在某些行的程式特別會出現在有問題的系統狀態，而這往往會是問題的 來源。

過去筆者用了這樣的方式省去了非常多分析系統問題的時間，無論是找找到底是哪個豬頭（自己？）弄了一個跑不完的無限迴圈，還是被剛剛更新的某個library害的。Thread dump相信會是您分析這類型比較非功能性的系統問題的好工具。

話說常常在一些徵求程式設計師或發案子的文章中，都能夠偶爾看到LAMP和WAMP這兩個字眼，一些沒看過的人真的會是一頭霧水，怎麼完全沒有聽說過這兩種技術？這到底是程式語言？還是什麼新技術？

結果，江湖一點訣，講破就不值錢啦！原來就只是作業系統(Linux)、網頁伺服器 (Apache)、資料庫(MySql)和程式語言(PHP)的合體而已啦(如下方解釋)！一點也不是什麼太複雜的東西，下次再看到它，可別被唬得一愣一愣的，只能回答：「我不會」。

LAMP: Linux + Apache + MySql + PHP
WAMP: Windows + Apache + MySql + PHP

說完了名詞解釋，當然還得補一點好東西，不然太混的話，下次可能會被站長抽稿。現在就來看看，怎麼樣輕輕鬆鬆建置LAMP或WAMP的執行環境 – XAMPP。雖然說看到一堆有的沒的什麼P，不過XAMPP這可真的是好東西，行家、老手和像我一樣的懶鬼應該都很愛用，畢竟它實在是太方便了，尤其過去 XAMPP還沒有出來之前，在Windows平台上整合Apache加MySql加PHP真的是讓人很頭大的事情，現在只要輕鬆的點點下一步，就可以開始 寫程式了，讓人忘卻了過去那一段痛苦的日子。

http://www.apachefriends.org/zh_tw/xampp.html

簡單地說，XAMPP是一套幫你把LAMP或WAMP環境整合好的安裝程式。上面網址是XAMPP的中文官方網站，目前它支援Linux、Windows、 MacOS、Solaris四種作業系統平台，其中我最愛用的就是Windows平台的啦！只要安裝完畢，WAMP的環境立刻完成！甚至它連 phpMyAdmin都已經幫你搞定了，只要再設定一下虛擬目錄跟資料庫的安全性就可以馬上開始寫程式了，非常地方便！我們也可以在官網上看到，事實上它幫我們裝上去的真是什麼死人骨頭…嗯…什麼寶貝都有，連OpenSSL都有，只要會用，這真的是一個很猛的神兵利器，以後再也用不到這麼方便的軟體怎麼辦啊！

下次再遇到LAMP、WAMP傻傻分不清楚的人，記得再幫他們多介紹一個XAMPP啊！讓他們更不清楚，才能顯得出我們的價值咩~

繼上週許多讀者表示對於「用Gmail產生到處註冊用的E-mail帳號」感覺非常有用，這次再來介紹一個筆者已經使用很久的非常好用的技巧，也就是如何用一個Gmail帳號管理所有你其他的E-mail信箱。

我相信絕大多數資訊從業人員都有著多於一個E-mail信箱，甚至像是作者一樣基於各種需求，從大學、研究所、工作、等等其他需求以來，可能有超過十個E-mail帳號。當然把這些信箱通通設定在Outlook或是其他收信軟體，不是一件困難的事情，但是作者常常在外面到處跑，每次用的電腦不一定都是同一台，甚至iPhone等手機都可能來來收信，所以不太喜歡把信真的下載下來，直接使用Web Mail其實是相當方便的一個選擇，所有信件隨時都可以在線上查閱，甚至搜尋。

另外，不是所有的信箱都有著完善的垃圾郵件功能，Gmail的垃圾郵件篩選功能感覺上算是比較適中，不會太嚴格，實際收到的垃圾信數量還算可以接受的範圍。配合上自訂的篩選條件長期用起來相當合用。

所以如果我們希望能夠使用Gmail來當作我們統一的收發信介面，要做的事情有兩件：第一個就是要讓Gmail能夠收其他信箱的信，第二個就是要讓Gmail能夠以其他信箱的身份來發信。

要讓Gmail收其他信箱的信有兩種方法，最簡單的是如果其他信箱有提供轉寄的功能的話，就可以直接在其他信箱設定轉寄，例如Gmail本身就有可以設定把所有信轉寄到其他信箱的功能。(設定的位置在：設定=>轉寄和 POP/IMAP=>轉寄)。如果你想收信的那個信箱沒有提供這樣的功能的話，Gmail還是可以透過設定，主動到你的信箱幫你把信抓回來！但是你必須提供你信箱的帳號跟密碼給Gmail。（設定的位置在：設定=>帳戶和匯入=>以 POP3 檢查郵件）但是你只能設定五組e-mail帳號。

如果你的五組pop3收信用完了的話，在這邊還是有一個小技巧可以使用，您可以多申請一個Gmail帳號，專門來收多出來的e-mail信箱，然後在Gmail裡面再設定自動轉寄到你統一使用的信箱就可以啦！

而要怎麼樣用Gmail寄信，但是看起來你好像是用你其他的信箱寄的呢？在設定=>帳戶和匯入=>以這個地址寄送郵件，可以設定其他信箱的身份，設定以後Gmail會寄一封認證信到你設定的其他信箱去，確認你是不是真的要讓Gmail來以你這個信箱的身份寄信。設定完成以後，每次你在寄信的時候，就會多出一個「寄信人」的選項，來確認這封信你是要用哪一個信箱的身份來寄信。

Gmail還有一點相當聰明的地方，就是當你收到一封信要回信的時候，他會自動選擇別人寄給你所使用的那個信箱，來當作預設你的回信身份，如果你想要特別修改的話，再來變更就可以了！

以上是一些筆者Gmail信箱使用多年的一些經驗，在Gmail之前其實換過非常多次信箱，每次都在用了一陣子之後，被大量的垃圾郵件攻破，而用不下去，在轉為這樣的使用模式之後，都還算用起來滿愉快的，而且多年下來似乎也沒什麼問題。E-mail這種日常生活常用的工具，就是以方便好用穩定為最重要的原則囉！

三、法則2: 應妥善處理前端錯誤訊息, 應引導使用者排除問題

如果您不希望天天有客戶打電話進來客訴, 就得讓錯誤訊息, 能引導使用者自已排除問題, 這項需求的確認比較麻煩, 可能需要透過與下包商情境的商談來事先定義, 並透過第一線客服人員或直接由使用者試用。當然, 最好是錯誤訊息可以不用透過修改程式, 直接以 config file / resource file 的方式, 由維運人員依上線後的客訴情況來微調錯誤訊息。

但要注意, 詳細的引導可能會讓你的系統更新困難, 因此一些常變動, 但分散在各頁面的部份, 像客服電話號碼, 或某個常變動的權限申請程序, 應要求廠商讀取相同 config, 或 Link到同一則 FAQ。

四、法則3: 應妥善處理前端錯誤訊息, 不可透露程式安全細節

有時程式錯誤, 廠商為了方便debug, 會把程式哪行出錯的訊息dump在畫面上, 甚至還包含了IP, DB Account, Password 等資訊, 不禁叫人捏一把冷汗。近年來一些 Application Server 已支援 “開發模式” 與 “上線模式”, 上線模式時會自動隱藏錯誤細節。但無論透過什麼方式, 廠商必須遵守 “catch 所有可能錯誤” 的原則, 畢竟沒有一位高階主管在看到系統彈出醜醜的 “Http 500 Interal Server Error” 時, 會覺得你負責的系統做的棒極了!

五、法則4: 後端錯誤log應越詳細越好

為了追蹤問題, 後端錯誤log當然應越詳細越好。若系統流量很大, 為了分析方便, 可考慮要求廠商log應該是 “可被匯入DB分析的”, “具備自動rotate或灌爆警示的功能。完整的記錄欄位除了發生錯誤的trace stack之外, 還可依需求包含來源IP、案件代號、發生時間、輸入資料等資訊, 以便連結到特定客訴使用者行為, 或進行錯誤類型的統計。

一、魔鬼降臨

在總裁一句 “人事凍結” 的命令下, 身為一間大企業的MIS工程師, 展開了與外包商長期的角力。”魔鬼就在執行的細節裡” 一句話點破了外包管理省工省事的神話。為了避免包商拿了錢一拍兩散的常態, 或千拜託萬拜託卻另外要你簽個 25% MA。因此驗收合約的精細度就變得很重要, 今天要和大家談的就是規範Error Handling和Return Code這檔事。

參與專案外包工作已經十個年頭, 從三五人的小公司到號稱遵循CMMI/ISO制度的大公司, 幾乎沒看到有專案, 在需求文件中對包商交付系統的 Error Handling 做規範。因此當專案結束, 維運人員接手一段日子後, 才發現原來系統傳回 “帳號密碼錯誤”, 有時候事實上是 “資料庫連線失敗” 或 “伺服器磁碟已滿”。搞得維運人員灰頭土臉, 三不五時被老闆叫去罵系統寫的爛。其實探究原因, 這是由於開發系統時, 工程師常以工程的角度去做Error Handling, 而非以維運角度去處理。

“那要如何在合約中簡單的規範下包商的處理方式呢?” 下面將建議幾個法則。 (這裡我們不談 “throw early, catch late” 之類的程式編寫原則, 那是下包商工程師撰寫上的藝術, 我們在合約中不需多加干涉。)

二、法則1: “用責任區來編Error Code”

對工程師來說, 處理一個錯誤, 最重要的就是 “技術上這是哪類的錯誤?”, 分類方法可能是 DB, AP, Network, … 但對維運人員來說, 看到一個錯誤, 最重要的就是 “誰該處理?”, 分類方法是 “使用者密碼錯誤-使用者要處理”, “排程匯入供應商的產品資料格式有誤-供應商的錯”, “網路中斷-喂!網管醒醒”, …

為了強迫包商工程師改變思考習慣, 避免他不分青紅皂白的全部 “try…catch…” 起來傳回同一個錯誤。進而變成有效的下包商驗收準則, 你必須先找出與這系統相關的 “責任區”, 如果Error Code有4碼, 第一碼可以是責任區的代號, 像：

1xxx-代表使用者操作問題 – 像帳號密碼有誤。
2xxx-代表供應商介接系統問題 – 可能是匯入資料格式有誤, 或根本連不到供應商的主機。
3xxx-代表系統基礎環境有問題 – MIS部門要check是否磁碟已滿, 或網路設備異常。

其它三碼則由下包商工程師自行編排分類。 相信我, 這時間花的值得, 這樣工程師在寫程式時就會試著去判斷問題的原因, 發生錯誤時, 你手下可憐的維運團隊也不需要再推敲追查半天, 你也不需要無助的找大老闆坐鎮, 來開那種永遠沒結果的跨部門推責大會。另外, 當程式歸責錯誤時, 也可以明確指出是程式 “defect”, 要求下包商修正。下包商再也沒有理由說 “這個是新需求, 要再算錢!”。

到哪裡都要註冊帳號給E-mail，搞的垃圾郵件一大堆，很討厭對吧？

我們常常會發現，一個信箱一開始註冊，都還很乾淨，沒什麼垃圾信。 但是用久了難免開始這邊在論壇註冊一下，要填E-mail帳號，那邊想要看偏文章詳細內容，也得給一下E-mail帳號，甚至連去大賣場參加個抽獎，也要填寫個E-mail帳號。到處給別人E-mail的結果就是，垃圾信一天比一天多，筆者比較舊的信箱已經到了每天會有好幾百封垃圾郵件的地步了。

可是有時候就真的不得不給啊！怎麼辦呢？這時候跟各位分享一個Gmail裡面稍微比較少人知道的小技巧：在你的E-mail後面用「+」的符號來產生出一組新的E-mail。

今天我去了BalaBala論壇，想註冊一個帳號，又怕他以後把我的E-mail賣掉，假設我的E-mail是 ITVitamin@gmail.com，我就留ITVitamin+BalaBala@gmail.com，Gmail針對「+」後面的字完全會省略， 也就是說：

ITVitamin+BalaBala@gmail.com 等於 ITVitamin@gmail.com
ITVitamin+SpamSender@gmail.com 等於 ITVitamin@gmail.com
…

這時候這些加工過的E-mail帳號，一樣能夠把信正確的送到你的信箱，但是一陣子以後你發現有一堆垃圾信是寄到 ITVitamin+BalaBala@gmail.com的時候，你就可以分辨出是BalaBala論壇把你的信箱賣掉啦！這時候你就可以利用簡單的設 定Gmail 篩選的功能，把所有寄到ITVitamin+BalaBala@gmail.com的信通通送進垃圾信資料夾，一網打盡！

不過有時候有些網站在註冊的時候，會不準你填「+」這個符號在信箱裡，怎麼辦呢？Gmail還有另一種方式可以派上用場：所有在E-mail裡面的「.」也 就是句號都會被忽略，也就是說：

IT.Vitamin@gmail.com 等於 ITVitamin@gmail.com
IT.Vita.min@gmail.com 等於 ITVitamin@gmail.com
…

這時候你可以把某種特殊的「.」句號點法的信箱，當作專門給送垃圾信的人，未來還是可以用跟上面描述的一樣方式，把註冊後所衍生的垃圾信，一網打盡！