在讀完資訊科學中三個錯誤的想法之後，ㄚ琪要繼續讀由使用者端自動取得當機回報，哇！這篇正在翻譯徵求校對中，那ㄚ琪先去註冊並且校對看看囉！
很奇怪一直出現Warning: Parameter 1 to SimpleCaptcha::confirmEdit() expected to be a reference, value given in /usr/local/www/mediawiki/includes/Hooks.php on line 117，是不是驗證的功能有錯？
先把校對一些的文章備份在這：
我曾經受僱於在美國一間最大的互聯網服務供應商撰寫客戶端應用程式，所開發的產品擁有數以百萬的用戶，即使一個最罕見的錯誤都可能影響數百甚至數千的用戶。雖然如此，每次當我們決定按下按鈕以釋出最新版本的程式時我還是充滿信心。我還記得我曾經告訴我爸「這次的試用版本看起來棒極了。昨天我們在北美洲只收到十二個錯誤報告。」
十二個，嗯？還是十三個？
不，是十二個。我們應用了一種日漸普及、由用戶端自動報告錯誤的技術。所得的報告都記錄到錯誤追蹤資料庫內彙總成摘要，以便開發人員尋找並修正只在用戶端發生的錯誤。這類錯誤往往難以在我們的測試實驗室內偵測的到，因為事實上我們不可能在我們客戶所有超乎尋常的電腦上再一次弄出那樣的設定。
錯誤偵測及報告功能正日漸普及。現在互聯網瀏覽器和視窗系統都已經內建這類功能，而且客戶也開始期待他們的桌面應用程式可以處理回報自己的錯誤。
能夠知道世界上每一個角落找到的每個錯誤，對於建立一份你所開發的產品能在這個瘋狂的世界上安然無恙的信心而言非常重要。尤其對於像開發消費者應用程式領域的我們而言更為重要。很多時候你不能倚靠客戶告訴你他們所遇到的錯誤，他們可能沒有足夠的技術背景,更重要的是,要是沒有自動報告錯誤的機制,他們根本不會有興趣在忙著幹自己重要的工作時還抽空給你發一份完整而有用的錯誤報告。
現在我創立了自己的公司,更深深地相信自動收集用戶端錯誤的重要。差不多所有我們在Fog Creek Software編寫的程式都有好些方法能透過我們的FogBugz錯誤追蹤資料庫回報錯誤。我們的產品CityDesk之內的產品,以至FogBugz本身(一個安裝在客戶端的網頁伺服器上的網頁應用程式)都內建了這項功能。兩者皆可以透過互聯網匯報錯誤。就連我們為內部開發的應用程式,比如說營運Fog Creek網上商店的電子商務程式,都會用相同的方式通知開發團隊程式運作期間所遇到的錯誤。 == 剖釋錯誤 == 好吧,你的程式當掉了。在幾乎每個程式執行環境下,總有些方法能讓你由某個地方回復、重新開始作業。以往我們只會讓程式在出問題的的地方乖乖掛掉,現在我們選擇彈出一個對話框。
這麼多年來我學到一件事,就是你所問的問題越多,想回答的人就越少。所以現在我們只會問最少的而又能幫助分析錯誤的問題。比如說「你正在做什麼?」、「你的電郵地址?」我們強調提供電郵地址是自願性質,以排解關於個人隱私的疑慮。令人意外的是有些盲目恐懼是如此深入民心而且根深蒂固。在消費者市場內,許多人都已經被十一點鐘新聞報導教育成永不要交出他們的電郵地址以避免收到垃圾郵件。結果是,如果你需要人們匯報錯誤的時候填寫電郵地址,他們就乾脆不提交報告。
基本上所有你所需要的資料都可自動取得,例如作業系統的版本,系統擁有的記憶體大小等等。 == 數據收集 == 接下來的問題是,要收集什麼樣的數據才可以幫助我們的開發人員找到造成錯誤的地方?我們很難抗拒把所有抓得到的數據都抓起來的這種誘惑。抓下每個你可以抓到的位元資訊,抓下用戶系統內所有DLL及COM控制項的版本,以至把所有記憶體內的資料都倒出來製作一個備份(有些會叫這做核心轉儲Core Dump)。
然而在做了開發人員幾年後、以及在從不知道自己拿著份核心轉儲資料可以幹些什麼的情況下,我終於發現這些都是非必要的數據。以下都是我們實際上會收集的數據: *產品版本 *作業系統版本及微軟Internet Explorer版本(有相當多的視窗功能都是來自Internet Explorer和它的元件,以致這項資料對於了解包括圖象介面應用程式在內的程式對視窗作業系統上的表現非常重要) *發生錯誤的程式檔以及程式碼行數 *錯誤訊息文字 *獨一無二的錯誤碼 *來自用戶關於他們正在進行中的作業的描述 *用戶的電郵地址
有這些就足夠了!這些年來我們發現單是知道發生錯誤的程式碼行數就已經足夠幫助修正大部份的問題。在少數以這項資訊不足以解決問題的個案上,你可以透過直接聯絡遇上問題的用戶以取得更多的資訊幫忙解決問題。收集少量資訊的好處在於令回報錯誤的程序變得非常快速,進而減少用戶對回報問題感到不耐煩的機會。單是檢查所有DLL和COM控制項的版本就可以花上好一段時間,如果數據是由數據機上傳的話就又得花更多的時間,而這些數據是可以提供幫助修正錯誤的有用資訊。即使你發現錯誤只會在程式應用一個微軟系統DLL的某個版本時才會發生,你又可以做些什麼?你仍然需要改寫程式來避開錯誤。 == 致電回家 == 感謝上天互聯網的無處不在，在大部份情況下透過網頁傳送資訊都是把資訊送回家的最佳方法。只要送出一個標準的HTTP需求,你的錯誤報告幾乎可以穿越於客戶環境內任何種類的防火牆。更妙的是，現在幾乎每一種編程環境都有內建的程式庫支援發送HTTP需求及讀取回應。舉例來說，在視窗平臺上你就可以在WININET程式庫內找到內建的函數式去利用Internet Explorer的網絡傳輸程式碼來傳送HTTP需求和讀取回應。利用這些函數式最好的是，如果用戶曾經設定他的瀏覽器透過代理伺服器來在防火牆內傳取數據，WININET呼叫程序會自動採用相同的設定操作，而過程中你無付出任何額外的努力更改或設定你的程式就能正常發揮功用。
我們的FogBugz在收到HTTP需求送來的錯誤報告後，會傳回一個很短的XML文件表示已經收到錯誤報告，文件亦同時包含一個展示給用戶的訊息。關於這點，稍後我將會談得更多。
如果你的應用程式是一個網頁瀏覽器應用程式，你可以採用一個更簡單的做法：展示一個包含一張可遞交資料到伺服器上的表格的網頁。你只需要將表格的行動路徑指向你的錯誤追蹤資料庫即可。請參考圖象2。
在好些種類的應用程式當中，你或許會想將錯誤報告先寫到檔案或登錄內，等到用戶重新啟動應用程式時才送出，而非在錯誤發生時直接送出。我稱呼這種技巧為延遲傳送。這種做法雖然會延後收到報告的時間，但好處是一旦發生的錯誤嚴重至令你的應用程式癱瘓到無法送出錯誤報告時，你仍然可在稍後取得報告。
現在所有要送交Fog Creek的錯誤報告都會送抵一個位於我們公眾服務伺服器上的URL。而我們的錯誤追蹤資料庫則由透過這個URL接收錯誤報告。事實上這個URL是公眾可以接觸到錯誤追蹤資料庫的唯一路徑。除了接收報告以外的所有功能都已被鎖死，客戶可以提交錯誤報告，但無法讀取資料庫內的任何資料。
圖象3展現的是當一個錯誤報告抵達我們的資料庫時的模樣。我們可以設定將收到的報告自動送給開發團隊內的其中一位工作人員，不過最近為免打擾同事，我們選擇將報告都送到被建立的虛擬人”CityDesk New Bug”手上。每次我們想要過濾出收到的報告，只需找出那些被分派到虛擬同事手中的錯誤，然後再逐一決定是否需要跟進修正。所有需要修正的錯誤將會被派到真實存在的同事手上。 == 辦認重覆的錯誤 == 應用自動錯誤報告收集時很重要的一點是，同一個錯誤可以在許多不同的人手上發生許多次，而你絕不會希望每次同一個錯誤被報告時都會在你的錯誤追蹤資料庫內製做一個新的錯誤記錄。我們應付這個情況的方法是以錯誤資訊內的重要資料為錯誤報告編上獨特的識別字串。
字串的編碼方法十分謹慎，分別來自兩個用戶的同一錯誤必須獲編相同的識別字串。在好些實驗以後，我們發現最好的編法就是在字串內加入錯誤碼、檔案名稱、函數式名稱、錯誤行數和產品版本。圖象3內展示了識別字串”Error 91 (global:IsRoot:0) V1.0.32″。字串說明檔案global.bas於執行函數式IsRoot位於第0行的程式碼時發生91號錯誤，而產品的版本為1.0 build 32。相當偶然地，我們總是將編譯版本數目為雙數的產品編為內部使用版本，而編譯版本數目為單數的則是會送交到客戶手上的版本，這樣我就可以一眼知道某個錯誤報告到底發生在開發人員或客戶身上。
FogBugz往後遇到識別字串相同的當機回報時，會自動附加到這個案例中，並不會重開一個新案例。這樣能讓程式員在同一個地方看到所有相同的當機狀況。
識別字串的格式設計得花點心思。我們以前會把當機錯誤訊息整個含在識別字串裡。不過很快就發現錯誤訊息會被譯成不同的語言，於是每種錯誤都會分散成英德西法及其他幾種我認不出的語言。我們解決的方法是把錯誤訊息放在當機報告內，但是把不隨語言而變的錯誤識別碼放在報告的標題中，這些重覆的回報就少多了。
另外標題也經過特別安排，可以方便搜尋特定問題。由於我們在標題中使用「檔名:函數名:行數」的格式(注意其中的冒號)，所以只要搜尋「:函數名:」就很容易找出某函數相關的問題。我們基於相同的原因在版本號碼前加上字母V，這樣就能搜尋V1或V1.0或V1.0.32。如果沒有這個V字母，想找版本1時就會找出所有標題裡剛好有1字元的錯誤報告了。
當錯誤被確認時，我們可以把某個旗標(FogBugz介面裡的Scout Will)由「繼續回報」改成「停止回報」，之後就會忽略識別字串相同的當機回報。我們甚至可以設定一串文字訊息(在FogBugz介面裡是針對自動送出的案例中出現的Scout Msg)，可以自動傳給往後遇到相同當機狀況的使用者。當我們要使用避開錯誤的作法(workaround)時也會用這個功能提出建議。就像是「嘿，下次你要存檔前要記得先拍拍自己的頭再摸摸自己的肚子！」
重複回報的常見原因之一，就是當在當機處理程式本身。這並不一定是說當機處理的程式有問題，或許只是因為原先的當機太嚴重，以致再也沒有程式能正常運行。 —- [[Category:ChineseTraditional]]