小朱® 的技術隨手寫

Intel 對 AppUp 上的各個 App 都有一貫且一致的審核流程 (validation process)，透過審核流程可以有效的確保應用程式的品質以及與 Intel AppUp Center 管理系統的互動，以及確保 App 的開發人員的權益等 … 以上皆是官話 (說的我好像很會打官腔似的)。雖然 App 的審核有其必要性，但有時候卻是會令開發人員覺得 Intel 怎麼那麼 "龜毛" :)

前面的一系列文章中，我介紹了使用 .NET Framework 開發 IADP-Compliant 應用程式的方法，主要使用的語言是 C#，VB.NET 也可以適用，只是語法不同而已。相同的概念一樣可以用在 C/C++ 的程式開發上，雖說是如此，用 C 語言開發卻會比較辛苦一點，因為 C 語言並沒有類別與例外處理 (exception handling) 的概念與語法，只能用傳統的結構化程式設計手法來處理，而 IADP SDK for C 有充份的支援，但寫起來算是比較麻煩那麼一點就是了。

OAuth 的服務實作 ... 動念中。

Intel AppUp Reputation Program 是一個類似於 Microsoft MVP 的一種榮譽制度，在 Intel 的定義中，將開發人員的貢獻分成四級，有點像是空手道的等級制度，分別是綠帶 (Green Belt)，褐帶 (Brown Belt)，紅帶 (Red Belt) 與最高級的黑帶 (Black Belt)。

筆者於前陣子撰寫了一篇自訂 Crash Report (依例外來決定 Crash Report 的內容)，在本機測試時，Crash Report 會寫入到本機中的 Crash Report 目錄，而當 Application 使用 app ID 啟動時，Crash Report 會改存到 Intel AppUp Developer Center 中，開發人員可以在 My Dashboard 中，選擇 Crash Reports 來查詢目前曾經發生過的 Crash Report 的記錄。

Service Management API (服務管理API) 是 Windows Azure 管理工具之一，不過它不是給 IT 管理人員，而是給程式開發人員用的，因為它開放的是 API 而不是使用者介面，開發人員可以撰寫一些簡單的工具來輔助監控與管理 Windows Azure 平台上部署的各式服務，並且可以透過 API 進行服務的部署與管理等，而微軟在 Visual Studio 2010 中加入的雲端專案發行功能，也是利用 Service Management API 來開發的，因此只要練會了 Service Management API 的使用，那麼想要自行開發 Windows Azure 管理工具也不再是夢想。

UAC 一向是在 Windows Vista 之後的作業系統的問題，在 Intel AppUp 的應用程式中，可受支援的有 Windows XP 和 Windows 7 (含 32/64bit)，如果應用程式需要存取受 UAC 控制的範圍 (ex: application configuration) 時，就會受到 UAC 的影響，而可能會導致 UnauthorizedAccessException 的存取被拒問題。

我自己是華人，常用的語言也是中文，而且是繁體中文，日常的溝通都是用中文，所以我的英文並不好，但就算是英文不好，寫程式時我除了註解外統統用英文，我也一直在推廣寫程式或是對資料庫欄位命名時不要使用中文，並不是我歧視中文或是有什麼顏色或是抱外國人大腿什麼的 ...

得知 app 被 rejected 後，今天花了一點時間修補問題，並且新增一個組態的程式來填補 UIX2 的問題，原本在本機測試時是沒有問題的，後來上傳到 Intel AppUp Developer Center 後，有請 IADP 顧問級人物 Bill Chung 幫忙下載測試 (做 beta tester)...

話說昨天才在抱怨說為什麼 Intel AppUp 的審核速度這麼慢，隔天結果就出來了，而且是一個大大的 Rejected (拒絕)，這時就很能體會黃忠成老師在送審 Windows Phone 7 App 一段時間後被退件的感受了。

最近冒出很多寫怎麼上傳 App 的文章，對 App 上傳的程序也已經有很多參考資訊了，所以這部份我就不講太多，不過 Component 倒是很少人寫到，所以我就來騙一下文章數吧。

在 Intel AppUp SDK Developer's Guide 中，有不少的篇幅都是在講應用程式和 SDK 一些函式的整合，以將 AppUp Center 的機能和應用程式整合在一起，像是 Application Registration, Instrumentation (Events), Upgrade 與 Crash Report 等，除了之前我所發表的使用 Exception 決定 Crash Report 的功能外，我們還可以進一步的將 SDK 的函式包裝起來，讓在整合 SDK 和應用程式的過程能更簡單，簡單到什麼程度呢 ... 只要使用一個類別即可，而且相關的 Exception 都會轉換成自訂的 Crash Report。

這是今天碰到的有趣問題。一般我們在使用對稱 (或非對稱) 加密演算法加密資料時，很習慣的就用 CryptoStream，然後用 Write 來加密，用 Read 來解密，而且平常也是用的好好的，一些字串加密的工作其實很容易就做完了。但是如果遇到了檔案型的資料時，很容易會因為檔案大小在加密時發生變化，而導致解密時檔案無法被打開 (ex: Office 2007 的檔案)。如果觀察一下，可以發現原始資料和加密過的資料大小會有不同。

繼前一篇 TFS 2010 部署初體驗後，我在文中也有說明要連接 Visual Studio 2005, 2008 和 2010 到 TFS 2010 時，有不同的處理方式，其中 Visual Studio 2010 Ultimate Edition 內建了 Team Explorer，所以可以直接連到 TFS 2010 (若是 VS2010 Professional 就要額外安裝 Team Explorer)，不過 Visual Studio 2008 Team Suite 與 Visual Studio 2005 Team Suite 並沒有內建 Team Explorer，所以也是要額外安裝 Team Explorer，不過問題來了，已經安裝好 Visual Studio 2005 和 2008 的電腦，是否可以直接以安裝 Team Explorer 的方式來存取 TFS 2010 ?

Visual Studio 家族中的 Team Foundation Server 自從 2005 年開始，就一直處於 Visual Studio ALM (Application Lifecycle Management) 解決方案的核心地位，雖然它在 2005 年只是一個想取代 Visual SourceSafe 版本控制解決方案的功能，並搭配 MSF Solution Framework 流程的管理功能，但它難安裝也是出了名的，尤其 TFS 又綁了不少微軟的產品，像 SQL Server 與 SharePoint Portal Server 等，如果沒按照產品手冊的步驟，是很難部署出一個正式環境使用的，不過在歷經六年的洗禮後，微軟改進了 Team Foundation Server 的安裝流程以及工具，讓它更容易安裝與部署。

Crash Report 的原理部份 Alex Lee 大已經有寫一篇文章說明，這裡我就不贅述，不過如果要為每個錯誤都覆寫一次 DefaultCrashReport，那如果應用程式中有上百種錯誤，那豈不是要寫上百個 Crash Report？累死人也 … 那如果可以把 Crash Report 的資料交由 Exception 來決定，開發人員只要簡單的產生自訂的 Exception 的話，那不就變得很簡單？

Intel AppUp Developer Program 是一個由 Intel 建置的軟體市集，就像 Apple AppStore 或微軟的 AppHub 一樣，可以讓開發人員自由上傳應用程式，並且由使用者於 AppUp Center 中付費或免費下載使用，而且 AppUp Center 不限於 Mobility 應用程式，它也可以支援 Windows 以及 Web (Flash AIR) 應用程式，而且 Windows 程式還可以支援到 .NET 以及 C++ 環境，更好的是現在 Intel 為了推廣 IADP 計畫，免收 $99 美金的註冊費用，對開發人員來說也算是一種好康吧。

今天修練開始，首發 Intel AppUp Developer Program 平台開發的第一篇文章，就先來談談掛在 Visual Studio 上的這個 AppUp Software Debugger 好了。

呼 … 每次整理這個文章都要寫上好幾個小時，因為很多老書都缺圖，基於沒圖沒真相的精神，只有多上 Google 大神的圖片搜尋功能來找圖了，如果找到的又是露天的話，還要把圖抓下來轉存到自己的空間去，才能貼到文章中，我十分能感受到在圖片位置上看到 "露天" 兩個字的錯愕感 :)，能找到的我一定會貼，但找不到的 … 也只能請各看倌多包含囉。

在我前一篇文章中，介紹了很多本當年曾經給我許多重要知識的書，也有不少朋友覺得這是懷古文 … 不過說到古，我也才三十好幾，沒有到可以拿出許多古物出來開博物館的年紀，要說古的話，有好幾位真的是夠古，而且是古到 Apple II, IBM MAINFRAME, 8086, 8088, … 都可以講的出來的 XD，但我就不說是誰了～

今年已是投入軟體開發領域滿十年的日子，這十年來有許多的貴人，好朋友以及不知名的善人們的鼎力支持，我才有今天的小小成就，其中最不可或缺的好朋友，當推現在在案頭以及書架上的這些書籍，個人有 80% 以上的知識都是來自它們，它們有幾個特色，不片段，不偏頗，有系統且充滿作者想充份表達的精神，由這些書中我得到了很多的重要知識，以及在實務上應該要掌握的一些技巧。

今天在論壇上出現了一個提問，還蠻有意思的，因為發問者問了一個平常人比較不會注意到的東西，就是特殊路徑表示法 (special path representation)。

熱情 (enthusiasm) 這個字是來自希臘文的神 (theos) 與內心 (entos) 的字演化而來，在維基百科上也有對這個字的描述，它早期的意義是對宗教的強列情感，也就是有點像是宗教的信徒之類的，不過後來它被用到像是崇拜偶像或是公眾人物 (有點類似 Fans) 的意思，或是對一個領域的事情有著強烈的興趣或是理念，進而在這個領域貢獻所學或是知識，並為這個領域的進步付出一己之力。

自昨天首發 EasyOAuth Library for Desktop Application 後，今天再進一步發表 EasyOAuth Library for Web Application，這個函式庫可以支援 ASP.NET 與 ASP.NET MVC 應用程式開發支援 OAuth 功能的 Web 應用程式，它一樣可以在少量程式開發的情況下讓 Web 應用程式支援 OAuth 的功能，並且與 EasyOAuth Library for Desktop Application 一樣，可支援 Google, Facebook, Yahoo 與 Twitter 四種內建的 OAuth Service Provider。

這是筆者的第三個 Codeplex 開放原始碼專案，承繼前面四篇 OAuth Series 文章的說明，EasyOAuth Library 建構於 .NET Framework 之上，並且可以很容易的將 OAuth 的功能套用到自己的 .NET 應用程式中，並且開發人員可以依照 EasyOAuth Library 開放的介面，為非內建的 OAuth Service Provider 開發介面，以在 EasyOAuth Library 中直接使用。

在前一回完成了整個 OAuth 驗證與授權的流程後，程式應該可以成功取得 Access Token 以及 Access Token Secret，只要有這兩個資料，應用程式就可以以 Access Token 所代表的使用者來與 OAuth 服務的 Private API 來互動，大多數 OAuth 服務上的 API 都會需要先取得 Access Token 後才可以使用 (雖然還是有少數可以不用啦)，所以這篇文章就來說明怎麼使用 Access Token 來存取 Private APIs。

在前一篇文章中，已經大略的介紹過 OAuth 所使用到的各類參數，這些參數的產生與使用將會決定 OAuth 的程序是否順暢，因為在每次針對服務的 private API 呼叫，都會用到 OAuth 的認證標頭訊息，所以怎麼樣產生正確的訊息就是用戶端程式最重要的課題。

OAuth 使用上最難懂以及測試的，莫過於這些 OAuth 的參數，尤其是在 OWASP 的 Web Security Report 之下，又有 Improper Error Handling 的安全漏洞問題，因此在測試 OAuth 時，最容易吃的苦頭就是只知道 HTTP 400 (Bad Request) 或 HTTP 401 (Unauthorized)，有些服務還會提供一些錯誤訊息，但也有一點都不提供的，而且就算有提供，也不一定馬上就可以意識到問題在哪 (ex: Signature Invalid) … 往往都要做很多的實驗才能真正找到問題在哪，我在測試 Twitter 的 OAuth 時就吃了很多的苦頭… Orz。

OAuth，一個讓人又愛又恨的驗證協定，它讓許多主流的社群網站與網路服務打開了封閉已久的驗證大門，它也是在網路上公開個人或私人資訊 (private data) 前最主要的驗證管道之一，重要的是，在這個協定下，所有公開給外界的私密資料會受到兩個階段的保護，OAuth 保障使用者可以在應用程式要求資料前由使用者做明確授權，只有授權過的資源才會開放給應用程式存取用，而且 OAuth 公開的特性，可以讓應用程式在極少量程式碼的變更下，移植到不同的服務繼續使用，而 OAuth 協定也讓服務端精確的控制要開放的服務，並且提供使用者授權的管道以讓使用者能自由控制授權與否，而且用戶端應用程式只要利用 HTTP 協定即可使抈 OAuth 服務。

鎖定的另一種情況，就是當應用程式使用交易 (Transaction) 時，資料庫引擎會啟用交易處理的機制，在 BEGIN TRANS 至 COMMIT/ROLLBACK 間修改資料，在交易進行的期間資料庫引擎會依照適當的方式來進行交易相關資料的鎖定，而在交易之外的使用者讀取或寫入這些交易資料時，會受到交易鎖定行為的影響，資料庫引擎在交易進行期間除了要保障在交易內的所有資料變更都要符合 ACID 規範外，也要避免在交易外的其他並行存取的可能干擾，所以在資料庫引擎中都會設計一個在交易期間將交易資料與一般並行資料間的區隔機制，以保護交易中的資料以及其他並行作業間的交互動作，這個機制就是隔離層次。