1、Dropbox
2、ZumoDrive

《前言》

由於剛購入 Desire 時，身邊最大的 microSD 卡只有 4G，又因為抓到的很多 apk 檔根本不夠放，只好存在電腦中… [無奈]

PS: 因為原先還是 2.1 ROM，所以有很多 App 都是要用才安裝，免得每天都會收到警訊(空間不足)

可是既然拿了智慧手機在外，就是想要想到要用的時候就可以馬上下載安裝阿！所以就動腦筋到原先就有在用的 Dropbox 身上。
可是除了公司和家裡電腦要共用外，還要再放手機的資料（除了應用程式外，也放了照片和部份文件），導致空間不夠使用，所以才會去尋找其它類似的產品。

講了那麼多廢話後，接下來就是正式介紹本篇要講的軟體啦！

主要以基本內容、功能、空間與分享等四項功能來分享。

==================== 我是分隔線 ====================

《軟體功能》

一、Dropbox

1、基本內容：

在本地端（電腦）是以資料匣的型式，我是拉到”我的最愛”去方便使用，開啟軟體後，Dropbox會自動同步資料，不管是新增或刪除都會很快速的同步完成，這一點是我對 Dropbox 印象特別好的一點。

2、功能：

主要是同步不同電腦間的檔案，所以很方便把公司和家裡電腦同步（只要把文件放到 Dropbox 資料匣中即可），不過也由於此特性，所以刪除檔案並且同步後，該檔案就會消失。

至於在手機上則不是用同步的方式（這樣會很佔空間），而是當你安裝了 Dropbox 的 App 後，可以依資料匣去下載檔案到手機中。

3、空間：

基本空間有 2GB，透過完成階段任務及分享後可以逐漸提高空間（可額外再增加 8GB）。

4、分享：

可以邀請朋友加入，並且分享特定的資料匣，大家一起共享檔案。

==================== 我是分隔線 ====================

二、ZumoDrive

1、基本內容：

在本地端是以一個獨立的磁碟代號（可指定）存在，檔案是存放在雲端主機上（不在本地電腦中），因此相對來說同步的速度較慢。

2、功能：

主要是在備份檔案，可以把檔案存放一份在雲端，比較不怕不小心把整個檔案刪掉。

另外 ZumoDrive 在手機上支援即時聽音樂、看影片，所以在某些需求上還是很方便。

3、空間：

基本也是 2GB 空間，可以特過邀請朋友加入來增加空間（可額外再增加 5GB）。

4、分享：

可以特過開啟連結的方式，來分享特定檔案或資料匣給所有人。

==================== 我是分隔線 ====================

《軟體比較》

一、相同處：

1、一樣是 Windows、Mac、手機（Android、iPhone、iPad）都可以使用。
2、基本空間都是 2GB，都可以透過邀請朋友來增加空間。
3、每邀請一個人可以增加 256MB。
4、都是可以透過一般操作習慣使用（本地端電腦資料匣）。
5、都有 Web 介面。

二、相異處：

1、Dropbox 存放實體在電腦上，並且以資料匣方式呈現；ZumoDrive 則是存放在雲端主機上，以獨立磁碟方式存在。
2、在手機上 Dropbox 以檔案列表方式呈現；而 ZumoDrive 則是會依檔案類型區分為檔案、影音、相片等形式。
3、Dropbox 在不同電腦間同步速度較快；而 ZumoDrive 同步時間比較久。

==================== 我是分隔線 ====================

《使用推薦》

一、如果你是偏向自己使用及需要多台電腦間檔案同步的人，那麼 Dropbox 會比較適合。

二、若只是需要一個網路硬碟，存放一些自己的東西，也沒有那麼需要同步，偶而會分享檔案給朋友的人，就可以使用ZumoDrive。

不過使用 Android 手機的人一定會有許多疑問，會覺得 Android 手機怎麼會好多功能都沒有？連要抓個手機畫面，好像都很困難一樣？
我也做了不少功課，對於讓手機發揮更大的效能，在網路上也爬了非常多的文章，甚至還一度想換手機… Orz

其實 Android 作業系統還算是一個包裝不完整的系統，但是反過來說，也可以說是擁有了許多彈性，讓使用手機的的人，可以客製出自己想要的，專屬自己的一個完美手機。所以接下來，就是要一系列來介紹（或記錄）有關於 Android 手機上的功能，達到成為一個手機達人的境界。

首要的第一件事，我覺得怎麼抓手機螢幕是非常重要的一件事，在網路上交流時，能有清楚的畫面對於解決問題有很大的幫助。

可是怎麼抓畫面呢？用另一個相機拍也不是不行，不過這樣感覺有點小蠢。如果手機裡可以安裝一套軟體，讓手機自動擷取螢幕存成圖檔，這樣是不是很方便呢？

當然啦，Android 手機是可以做到這樣的，只不過要付出的研究真的不少喔…

接下來就分兩篇介紹怎麼抓手機畫面的文章：

• 透過 Android SDK 和連結電腦。
• 透過在手機裡安裝應用程式。

另外要顯示 Tab 或 Space 時，可以依以下操作打開設定：

• 1xx – 參考資訊 (Informational)
  這些狀態碼代表主機先暫時回應用戶端一個狀態，所以在接收一般的回應之前，用戶端應準備接收一個或多個 1xx 的回應。我以前在寫 ASP 的時候比較有看到 IIS 使用到這些狀態碼回應，在 Apache 的環境我還未曾遇到過。
  • 100 – 繼續。
  • 101 – 切換通訊協定。
• 2xx – 成功 (OK)
  這類的狀態碼表示伺服器成功接收到用戶端要求、理解用戶端要求、以及接受用戶端要求。
  • 200 – 確定。 用戶端要求成功。
  • 201 – 已建立。
  • 202 – 已接受。
  • 203 – 非授權資訊。
  • 204 – 無內容。
  • 205 – 重設內容。
  • 206 – 部分內容。
  • 207 – 多重狀態 (WebDAV) — 這好像只有在 IIS 中才有，HTTP/1.1 並沒有定義這個狀態。這狀態會出現在可以包含多個不同回應代碼 (視子要求數量而定) 的 XML 訊息之前。
• 3xx – 重新導向 (Redirection)
  用戶端瀏覽器必須採取更多動作才能完成要求。例如：瀏覽器可能必須重新發出 HTTP Request 要求伺服器上的不同頁面。
  • 301 – 要求的網頁已經永久改變網址。此狀態要求用戶端未來在連結此網址時應該導向至指定的 URI。
  • 302 – 物件已移動，並告知移動過去的網址。針對表單架構驗證，這通常表示為「物件已移動」。 要求的資源暫時存於不同的 URI 底下。 由於重新導向可能偶而改變，用戶端應繼續使用要求 URI 來執行未來的要求。 除非以 Cache-Control 或 Expires 標頭欄位表示，此回應才能夠快取。
    ASP.NET 預設的 Response.Redirect 方法，就是以 302 Found 做回應。
  • 303 – 通知 Client 連到另一個網址去查看上傳表單的結果(POST 變成 GET)，當使用程式作網頁轉向時，會回應此訊息。
    在 ASP.NET 中要輸出 HTTP 303 轉向的程式碼如下：

    Response.StatusCode = 303;
    Response.RedirectLocation = "/PageB.aspx";

  • 304 – 未修改。用戶端要求該網頁時，其內容並沒有變更，應該回傳 304 告知網頁未修改。此時用戶端僅需要取得本地快取(Local Cache)的副本即可。
  • 305 – 要求的網頁必須透過 Server 指定的 proxy 才能觀看 ( 透過 Location 標頭 )
  • 306 – (未使用) 此代碼僅用來為了向前相容而已。
  • 307 – 暫時重新導向。要求的網頁只是「暫時」改變網址而已。
• 4xx – 用戶端錯誤 (Client Error)
  這代表錯誤發生，且這錯誤的發生的原因跟「用戶端」有關。例如：用戶端可能連結到不存在的頁面、用戶端的權限不足、或可能未提供有效的驗證資訊(輸入的帳號、密碼錯誤)。下次看到 4xx 的回應千萬不要傻傻的一直查程式哪裡寫錯誤了(不過也有可能是程式造成的)。
  • 400 – 錯誤的要求。
  • 401 – 拒絕存取。 IIS 定義數個不同的 401 錯誤，以表示更詳細的錯誤原因。 這些特定的錯誤碼會顯示在瀏覽器中，但不會顯示在 IIS 記錄檔中：
    • 401.1 – 登入失敗。
    • 401.2 – 因為伺服器設定導致登入失敗。
    • 401.3 – 因為資源上的 ACL 而沒有授權。
    • 401.4 – 篩選授權失敗。
    • 401.5 – ISAPI/CGI 應用程式授權失敗。
    • 401.7 – Web 伺服器上的 URL 授權原則拒絕存取。 這是 IIS 6.0 專用的錯誤碼。
  • 403 – 禁止使用。 IIS 定義數個不同的 403 錯誤，以表示更詳細的錯誤原因：
    • 403.1 – 禁止執行存取。
    • 403.2 – 禁止讀取存取。
    • 403.3 – 禁止寫入存取。
    • 403.4 – 需要 SSL。
    • 403.5 – 需要 SSL 128。
    • 403.6 – IP 位址遭拒。
    • 403.7 – 需要用戶端憑證。
    • 403.8 – 網站存取遭拒。
    • 403.9 – 使用者過多。
    • 403.10 – 設定無效。
    • 403.11 – 密碼變更。
    • 403.12 – 對應程式拒絕存取。
    • 403.13 – 用戶端憑證已撤銷。
    • 403.14 – 目錄清單遭拒。
    • 403.15 – 超過用戶端存取授權數量。
    • 403.16 – 用戶端憑證不受信任或無效。
    • 403.17 – 用戶端憑證已經過期或尚未生效。
    • 403.18 – 無法在目前的應用程式集區中執行要求的 URL。 這是 IIS 6.0 專用的代碼。
    • 403.19 – 無法在這個應用程式集區中執行用戶端的 CGI。 這是 IIS 6.0 專用的代碼。
    • 403.20 – Passport 登入失敗。 這是 IIS 6.0 專用的錯誤碼。
  • 404 – 找不到。
    • 404.0 – (無) – 找不到檔案或目錄。
    • 404.1 – 無法在要求的連接埠上存取網站。
    • 404.2 – 網頁服務延伸鎖定原則阻止這個要求。
    • 404.3 – MIME 對應原則阻止這個要求。
  • 405 – 用來存取這個頁面的 HTTP 動詞不受允許 (方法不受允許)。
  • 406 – 用戶端瀏覽器不接受要求頁面的 MIME 類型。
  • 407 – 需要 Proxy 驗證。
  • 412 – 指定條件失敗。
  • 413 – 要求的實體太大。
  • 414 – 要求 URI 太長。
  • 415 – 不支援的媒體類型。
  • 416 – 無法滿足要求的範圍。
  • 417 – 執行失敗。
  • 423 – 鎖定錯誤。
• 5xx – 伺服器錯誤 (Server Error)
  這代表錯誤發生，且這錯誤發生的原因跟「伺服器」有關。伺服器因為發生錯誤或例外狀況(Exception)而無法完成要求(Request)時，就會回應 5xx 的錯誤，且這肯定跟伺服器有關。
  • 500 – 內部伺服器錯誤。
    • 500.12 – 應用程式正忙於在 Web 伺服器上重新啟動。
    • 500.13 – Web 伺服器過於忙碌。
    • 500.15 – 不允許直接要求 Global.asa。
    • 500.16 – UNC 授權認證不正確。 這是 IIS 6.0 專用的錯誤碼。
    • 500.18 – 無法開啟 URL 授權存放區。 這是 IIS 6.0 專用的錯誤碼。
    • 500.19 – 此檔案的資料在 Metabase 中設定不當。
    • 500.100 – 內部的 ASP 錯誤。
  • 501 – 標頭值指定未實作的設定。
  • 502 – Web 伺服器在作為閘道或 Proxy 時收到無效的回應。
    • 502.1 – CGI 應用程式逾時。
    • 502.2 – CGI 應用程式中發生錯誤。
  • 503 – 服務無法使用。 這是 IIS 6.0 專用的錯誤碼。
  • 504 – 閘道逾時。
  • 505 – 不支援的 HTTP 版本。

出處：The Will Will Web

POC, Proof of Concepts, 從字面的意義來解釋的話，即為 “概念性的驗證”。

既然是需要驗證(Proof)，所以 POC 是一種 “解決方案(Solution)”，是針對 “概念” 所提出的解決方案，而架構的 POC，目的即在於擷取出最精要、核心的解決方案(Solution)，以作為解釋架構的概念依據。

我與 Ringle 聊到 POC，他原來對 POC 的認知是對客戶所提出的一種解決方案，所以主要滿足對象是 “客戶”。不過，對於架構的 POC，我不太認同對象是客戶，我會以為，會希望能透過某種概念性的解決方案，而對架構有整體、全貌性的認知者，那才會是架構 POC 的對象。

所以，誰負責撰寫架構 POC？ 我認為是 “架構師(Architect)”，誰想瞭解及驗證架構 POC？我以為是開發團隊所有成員與利益關係人(Stakeholder)。

架構 POC 的對象釐清後，再來是瞭解其呈現的具體樣貌是什麼樣子呢？底下是架構 POC 具化的幾個可能樣貌。

• 解決方案所需運用的相關技術(Framework, Pattern …)。
• 利用 UML 語法建構概念模型草圖(Sketch)，以表達某一解決方案。
• 利用模擬(Simulation)的方式提出解決方案。
• 可以被執行的原型 (Prototype)。

我個人傾向利用可以執行的原型(Prototype)來作為架構 POC 的具體樣貌，因為：

• 架構師以 “原型” 做為與開發團隊與利益關係人的溝通、達成共識的橋樑，然後才著手執行。透過原型，大家比較容易對概念(Concept)產生共鳴，並致力改變尚未成形的東 西。
• 原型協助架構(Architecture)的建立，讓大家能容易看到整體、更具宏觀的角度來看待複雜系統。並因此而避免一頭就栽進種種的細節 (Detail)。
• 原型可把目標清晰地描繪出來，並且讓每個利益關係人(Stakeholder)都更容易提供意見，進行改革。

而且，架構原型可以：

• 在架構落實以前，讓團隊成員能自由表達看法，並進行討論、提出建議。
• 讓團隊成員隨時表達意見，有機會影響你正著手進行的方案。
• 不斷加快前述兩個步驟(一般稱之為「快速建構原型」)。

對了，架構原型除了比較容易協助團隊成員一窺系統的整體全貌外，對系統內部的結構(Structure)分析與設計的呈現，也能有一番基本的認知。

所以，架構原型的內容，我會擺上表達整體系統的使用案例模型；實做兩、三個具代表性的使用案例，並畫上概念性的類別圖與循序圖；同時，我還會加上與 .NET or J2EE 等平台相依的細部類別與循序圖；實做面，確實可以產出可以執行的程式碼與測試碼；最後，我會利用簡單的 UI(User Interface) 作為執行畫面的呈現與說明。

原型，並非是 “粗糙”，或是 “應付性” 的，它是一個框，是可以被驗證的，但並非僅利用外表美美的圖形使用者介面來對系統作概念性的驗證。架構原型，反而不是重視圖形介面，它要強調的是一種對系 統的整體觀與結構觀。至於圖形介面與企業流程的功能，反而不是那麼重視。精密與細節、正確性的工作，是對系統的整體有了正知與正覺，往正確的大方向走後， 才確定要做的細節性工作，可以把它作對。人們，尤其是組織性的團隊，最常犯的錯誤是：「把不必要的事情作太好」。

出處：Kenming’s 鮮思維

不過由於為了節省費用，另外還希望沒有那麼多限制，所以一樣選擇了主機在國外的主機商（lunarpages），雖然服務很好、回應即時，但是畢竟是在國外。在開放給客戶使用測試網站，或者是上傳大量程式檔案時，常常會因為速度太慢而導致需要重新連線…等許多麻煩。

在歷經多方考慮之後，也在域名過期了三個月的時間，重新在國內找到了這個還不錯的主機商（G型主機），同時間也順利取回原先 magic-wind.net 的域名。因此在慎重考量下，重新將原先的【Magic-Wind.NET】魔風網，正式命名為【Design-Wind.NET】設計風，也讓原先的 magic-wind.net 轉為備份網站。

巧合的是，這次正式成立的日期是在四月一日（愚人節），不過還是記錄一下這個重大的事件。