Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 一月 2011

開發Windows Azure 程式的小偏方 tips and tricks

leave a comment »

把回答大陸網友的幾個問題綜合一下,在這裡跟大家報告了。

(喔!  提醒一下: Silverlight 在Loading 時,若你想用MessageBox.Show作 debug,這是不一定會 Work的。  )

如果你認為Windows Azure 的Unittest 不 Work了,那你就錯了!

請試著在方案之下加入一個新的專案(記著: 只能挑選Console 應用程式,因為當程式上傳到了雲端只有他不會造成錯誤而使得整個專案不能正常工作,通常就是完全沒有回應了,也就是著名的雲端白畫面),然後運用這個專案去呼叫你想要測試的邏輯物件。這個時候;你會發現又可以使用Visual Studio自動幫我們創建的測試專案了,然後;在專案裡挑選你想測的 function 接著按下右鍵,一如往常地交給Visual Studio去創建你的測試專案及測試程式了。

一直覺得把專案變成雲端程式後,一切的執行動作都變得慢了下來!

這是因為你一直執行在 Development Fabric 的離線模擬狀態下,因為多了一層模擬環境,所以執行起來會慢一些。建議你在正要開發的程式下按右鍵,選擇它做為啟動程式,而不要把雲端專案設為啟動程式,這樣就會快上許多,尤其當你只是在撰寫邏輯元件時,請務必這麼做,而且應該運用 Console程式來進行單元測試。

將既有程式轉成雲端程式後,就必須維護二套程式了嗎?

這是程式人員在作業上的迷失。實際上;你可以在Visual Studio內切換『啟動程式』的方式來做腳色的更換。當然囉! 如果一旦你開始採用雲端才有的功能或是元件時,這一點是無法避免的,勢必會漸行漸遠,產出二套不同的程式碼,也使的維護上變得較麻煩許多。

但是有一點你必須記住的,就是在架構的設計上運用SOA的技巧,讓服務成為比較能夠獨立運作的單元,總是盡量採用鬆耦合(loosely couple)的方式來設計介面,如此可以避免在雲端與非雲端的 相同功能程式 的部分去維護二套不同服務的程式庫,這一點正是微軟在2004年所提出來的 Software Plus Services( S+S 請參考: http://en.wikipedia.org/wiki/Software_plus_services). 這一點尤其在軟體公司大事將既有的程式搬上雲端時更應該要注意的事,也就是;先把架構弄對了,接著一切就都可以輕鬆處理了。

如何確定既有程式已經能在雲端上正確無誤的運行了呢?!

上回在北京講 TechEd2010 的時候,有題到將既有程式搬到雲端的幾個等級,

(A).最初級的就是,將 ASP.net程式的一堆呼叫到的相關程式庫都搬到雲端上頭,讓程式可以在 Windows Azure上執行起來,就認為大功告成了。這是最多也是普遍的一種方式。老實說;還真是可以稱它為: 身在雲端而沒有享用雲端功能的程式。因為這種轉換的方式,並不能享受到橫向擴充instance時的運算能力,為甚麼呢? 不急,看看第二級就能意會。

(B). 第二級的做法就是把state 再考慮進來,除了把web 程式搬到雲端去執行以外,在統一將原本屬於IIS session manager 負責的狀態及變數資料一併改成雲端的provider 來處理(那就是將他們放到SQL Azure上或是Blob 的Table 內去統一儲存)。這麼做是為了Windows Azure 的前端自動做 Load Balance 的關係,因此資料一定要統一存取。(請參考: http://blogs.globallogic.com/aspnet-application-migration-to-windows-azure,MSDN上也有完整的說明: http://msdn.microsoft.com/zh-tw/windowsazure/gg442342)

(C). 再高一級的話就是將原來的架構,改寫成雲端 Web Role 及 Worker Role 分開處理 UI及邏輯運算的方式,這才是真正能夠發揮 Windows Azure 效能的一種正確方式(當然還是有人把這種架構運用得錯的一蹋糊塗,例如: 把WF4 放到Work Role 裏頭去)。
當然,絕對不只這三種等級了,雲端程式的架構是比傳統程式更需要嚴謹的加以規畫的,這一點我們有空再聊。

覺得意猶未盡的人可以參考: SOA with .NET & Windows Azure Realizing Service-Orientation with the Microsoft Platform這本書,是 Prentice Hall 出版的: http://www.amazon.com/NET-Windows-Azure-Service-Orientation-ebook/dp/B003V4ATGW 寫得好極了。

至於要怎樣來確定搬上去的程式已經能在雲端上正確無誤的運行了呢? 那當然只有一種方法能夠確定了,那就是對它進行【測試】。

MSDN有一篇好文章: 使用 IntelliTrace 偵錯已部署的服務: http://msdn.microsoft.com/zh-tw/library/ff683671.aspx

廣告

Written by ruddyllee

2011 年 01 月 29 日 at 21:31:32

過年要給孩子們甚麼?

leave a comment »

<= 按一下,看看屬於你們的世界…

過年要給孩子們甚麼? 紅包會比去年再多一點點 … 請放心!

但我好想像 David Dong 一樣,在課堂上show一段運用 Visual Studio 開發 WP7 的程式給你們看,然後說:『你們看,就是這麼簡單!』但是要注意;創意才是最最重要的,未來幾年的世界;就是要求新求變。

你們可能沒那個耐心坐下來欣賞老爸的表演…唉!

好想跟你們說【個人雲端運算】的時代來臨了,讓我把上課時的講義,過濾出最珍貴的一段,用自己最拿手又輕鬆的方式Show給你們欣賞,然後說:『請在新的一年來臨時,好好規劃個人的雲端生活吧!』

我要說:  雲端是甚麼呢!? 就是網路的消費創造啊!

  • 消費:  先從好好的想想你可以24小時的不停的,隨時隨地的獲取資訊,你要找甚麼?你要知道些什嗎?用在哪裡?
  • 創造: 接著才是思考如何用它來創造財富、名望…等等。

在個人雲端運算中,你要先由思考自己的口袋雲端(Pocket Cloudlet,從自己開始)。
你看那些在捷運上,還來不及坐下來就急著拿出口袋裡的 iPhone 的人們。用手指頭左刷右撇的動作,它代表甚麼呢? 我跟你說: 它代表著資料的搜尋。在茫茫的網際網路上尋找著她(他)想要看的或是有趣的新奇的資訊,或是消遣或是急切的想找到問題的解答,這是必要的嗎? 我也不知道,或許會帶來資訊焦慮症…或是其他新的鬼毛病,但是;這就是個人雲端時代的起手勢!

要學會規劃你個人的雲端運算,其實就是: 資料生活
從你希望把資料放在哪裡怎麼拿到? 如何做到同步開始。 再延續到怎麼來分門別類,目的是把隨手可得的資料變成有用的資訊來處理。記住: 要讓這一切成為改善你生活的助力,只有追求卓越;財富與名望才會自然而然進來的。

效率是雲端時代的表率
效率不是要表現給老闆看的,是要讓你無形中就活得比別人長些。同樣的路程能比別人早一點到達目標就是效率,因此也可以有更多的時間來嘗試別的東西,生活也自然能夠過得更精彩些,生命也自然會更有意義一些。

不是只有用金錢買來昂貴的連線設備(iPhone、iPad …)才會擁有個人的雲端生活的。雖然資訊是必須的;沒錯。但就好像開發雲端上的程式一樣,離線執行的能力是必須的,而模擬(simulation)及虛擬化(Virtualization)更是絕對必要的,它們不但可以增加效率,又能讓你從中學習到許多東西,是雲端時代必備的絕活。

要學會有耐性
好像再寫下去,你們就更不會看了,這是雲端時代的後遺症,人們只能吸取簡而有力的訊息,大家都急著一開頭就看到故事的結局是甚麼? 要知道;這樣的戲怎會好看呢,這樣的詩又怎能充滿著生活的美呢?要注意,智慧是生活的點滴累積而來的。想要擁有像史恩康納萊一般的智者形象嗎! 那就要細細品味一些需要思考的東西。要知道;好的東西總是越嘗越有味道的。

祝你們;新年快樂!

Written by ruddyllee

2011 年 01 月 25 日 at 11:02:31

張貼於未分類

Tagged with

讀取Windows Azure 上傳狀態的簡易console程式

leave a comment »

上一篇文章,沒有附上Source Code 被抗議了一下,好 ~~~ 這裡補上! 希望當你屢傳失敗時可以幫上一點忙…

這是我認為 最簡單讀取上傳狀態的程式 (Windows Azure Service Management API 中的 Get Deployment),比起上一篇乖乖的去讀 getOperationStatus 要簡單些,可以不用去讀取http header內的Request-id.

// 這是一支讀取 deployment 狀態的 Windows Azure Service Management API 程式

using System;
using System.Collections.Generic;
using System.Linq;
using System.Xml.Linq;
using System.Text;
using System.Security.Cryptography.X509Certificates;  // using X509 certificate
using System.Net;
using System.IO;

namespace ConsoleApplication_AzureApi
{
class Program
{
static void Main(string[] args)
{

// 查詢 Deployment 的指令
var request = (HttpWebRequest)WebRequest.Create(“https://management.core.windows.net/<subscription-id>/services/hostedservices/<service-name>/deploymentslots/staging“);
request.Headers.Add(“x-ms-version:2009-10-01“);       // Version 一定要加
request.ClientCertificates.Add(X509Certificate2.CreateFromCertFile(“C:/cer/XXXXX.cer“));  // 存放在Local 的 認證

try
{
var respStream = request.GetResponse().GetResponseStream();   //沒有Reponse 就會吃error
var xml = new StreamReader(respStream).ReadToEnd();
Console.WriteLine(XElement.Parse(xml));      // List 出來
}
catch (Exception err)
{
Console.WriteLine(err.Message);
}
Console.ReadLine();
}

}
}

附上原文的使用說明如下:

The Get Deployment request may be specified as follows. Note that you can return information about a deployment either by specifying the  deployment slot (staging or production), or by specifying the deployment’s unique name.

To generate the request URI, replace <subscription-id> with your subscription ID, <service-name> with the name of your service,
<deployment-slot> with staging or production, and <deployment-name> with the unique name of your deployment:

https://management.core.windows.net/<subscription-id>/services/hostedservices/<service-name>/deploymentslots/<deployment-slot>/

有興趣的話,運用PowerShell 也能輕易地讀取這些訊息,也是一個好的選擇。如果你想做自己的工具的話,這裡有一篇文章可以做個開始的參考: http://blogs.msdn.com/b/mikekelly/archive/2010/03/05/a-powershell-cmdlet-for-managing-windows-azure-diagnostics.aspx

PowerShell for Windows Azure Service Management CmdLets: http://code.msdn.microsoft.com/azurecmdlets

Written by ruddyllee

2011 年 01 月 22 日 at 22:34:43

張貼於未分類

Tagged with

上傳Azure 應用程式,傳一半失敗了怎麼辦?

leave a comment »

上傳Azure 應用程式失敗後的回應

基於Google 瀏覽器上傳Azure 應用程式失敗的回應,程式設計人員可能要更進一步去看上傳時的狀態。也就是說;如果你的程式在上傳作業時就出了問題,那怎麼辦呢?!

(線上偵錯: Windows Azure SDK 1.3 已經可以運用IntelliTrace來進行雲端的偵錯了,

可以參考: http://www.dotblogs.com.tw/code6421/archive/2010/06/09/15741.aspx)

查看的方法: 寫程式,運用HTTP 1.1 Request method 來讀取目前非同步作業的上傳狀態(透過Windows Azure Service Management API):

採用Http的 Get 方法:

https://management.core.windows.net/<subscription-id>/operations/<request-id>

參數:   subscription-id: 你的 subscription ID,request-id: 在return 的 http header 內

一直到回傳值: 200 表示作業完成。 (在response的body 內會回傳: InProgress, Succeeded,Failed)

但如果Failed了呢? 只好去看回傳值了。

請注意: 所有的Service Management API都是透過HTTPS的而且一定要跟著你的 subscription ID.

當然,你也可以呼叫: GetDeployment 的API 來取得更多訊息。(http://msdn.microsoft.com/en-us/library/ee460804.aspx)

範例:  請參考Programming Windows Azure .Programming the Microsoft Cloud by: O’Reilly 出版的96頁( http://oreilly.com/catalog/9780596801984 ) 或是線上的http://books.google.com.tw/books?id=ANqnTECyE9oC&pg=PA101&lpg=PA101&dq=sample+azure+Update+Deployment+Status&source=bl&ots=vkmxxv6Sy0&sig=MScEUtIswn2YnP0aLnyNwW4nEsg&hl=zh-TW&ei=4zs6TaGRG4bqvQPf-I2kCg&sa=X&oi=book_result&ct=result&resnum=5&ved=0CDwQ6AEwBA#v=onepage&q&f=false

(範例,我正在寫…就在下一本Windows Azure Service Management API的書內,但以我的寫作速度的話…可能就遙遙無期了,不用等了!)

讀到Request之後,對照一下回傳值吧:

【回傳值: Bad Request (400)

1. MissingOrIncorrectVersionHeader

說明: The versioning header is not specified or was specified incorrectly.

2. InvalidXmlRequest

說明: The request body’s XML was invalid or not correctly specified.

3. MissingOrInvalidRequiredQueryParameter

說明: A required query parameter was not specified for this request or was specified incorrectly.

4. InvalidHttpVerb

說明: The HTTP verb specified was not recognized by the server or isn’t valid for this resource.

5. BadRequest

說明: A parameter was incorrect.

【回傳值: Forbidden (403)】

1.     AuthenticationFailed

說明: The server failed to authenticate the request. Verify that the certificate is valid and is
associated with this subscription.

2.     SubscriptionDisabled

說明: The subscription is in a disabled state.

回傳值: Forbidden (404)】

1.     ResourceNotFound

說明: The specified resource does not exist.

【回傳值: Conflict (409) ConflictError】

說明: A conflict occurred to prevent the operation from completing.

【回傳值: Internal Server Error (500)】

1.     InternalError

說明:The server encountered an internal error. Please retry the request.

2.     OperationTimedOut

說明: The operation could not be completed within the permitted time.

【回傳值: Service Unavailable (503)】

1.     ServerBusy

說明: The server (or an internal component) is currently unavailable to receive requests. Please retry
your request.

關鍵的SDK 1.3 版的Microsoft.Samples.WindowsAzure.ServiceManagement.dll可以在安裝完Windows Azure Platform Training Kit 1.3版後找到。
(http://www.microsoft.com/downloads/en/details.aspx?FamilyID=413e88f8-5966-4a83-b309-53b7b77edf78&displaylang=en)

有關Windows Azure Service Management API 請參考:http://msdn.microsoft.com/en-us/library/ee460799.aspx

Written by ruddyllee

2011 年 01 月 22 日 at 11:09:39

團隊工作最重要的是溝通 — Scrum的每日會議

leave a comment »

團隊工作最重要的是溝通。                                                  —  Scrum

  • 上級最想知道的是專案的進度是否符合既定的時程?
  • 專案經理最想知道的是每位團隊成員是否都依照預定的行程在工作?有碰到甚麼難題嗎?
  • 工程師最想知道的是『這個問題』別人是否遇到過?

— 所以;良好溝通的管道是專案成敗的一大要素。

早期在網路還不是很普及的時代(二十多年前;那是我還在宏碁研發部的時代),程式員經常被要求要每天填寫工作進度報告,當然也常常因為忘了填寫而被責難。就為了怕被責難;我發起了研發部同仁養成在桌面的右上角留下一張每日工作單的習慣,每天一大早到辦公室;一邊喝著咖啡一邊就把寫在工作單上昨天的一些工作事項回顧一下(勾勾:做完的,叉叉: 已經沒意義的,或是錯誤研判的。當然再多加上一點註解也無妨) ,然後再填上今天準備要做的工作事項,然後才是放下咖啡開始工作。到了週末就由部門助理把單據收一收統一鍵進去就OK了,這個主意還被部們主管稱讚了一番(想當然爾;當然沒人會理我,只有我們這個小組的成員有照著作了,其他人就繼續忘記填寫工作單囉)。但是這些單據我都留下來了,一直到我離開宏碁的時候,看著厚厚的一疊單據,有著工程師的多少辛酸;耐人回憶。

那時我的主管總是喜歡在我不在的時候逛到我的桌前,停下來順手拿起右上角的單據,細看一下便清楚的知道我的工作狀態了,無形中我們做了最快最簡單的工作報告,面對面直接溝通的時間也就減少了許多(怪不得我後來就離職了),但這是老闆很喜歡的一種方式,我經常在轉角處偷瞄他看的津津有味的樣子,經常都不好過去打擾(其實是逃避一下害怕被質問)。

現在不用這麼大費周章了,Visual Studio有幾種方法可以提供團隊做好協同作業的模式,TFS提供專案專屬的網站就可以算是很精彩的一環,但可惜的是人們上網的慾望多半是瀏覽遠勝於工作上的溝通,因此除了專案經理人很在意之外,團隊成員多半還是有一搭沒一搭的,除非在異地分工的作業上確實是發揮異常的成功的。

我想說甚麼?

  • Scrum的每日會議為何又稱為站立會議呢? 目的就像老闆站在我的桌前一樣(其實任何團隊的成員都可以過來瀏覽;它是公開的),他當場不能發問,只有單向欣賞的餘地,因此我可以忠實的報告出來那些只做了一半還在嘗試階段的東西。以每日做為一個單元回報的作業控制方式,是避免方向偏離需求跟障礙排除的絕佳作法。
  • 國內團隊運用團隊專屬網站的比例太低了,敏捷理論上強調小組開發及工作環境大小的目的正是為了能有順暢的溝通,但是大部分的專案經理人卻忽略了隨手可得的管道沒有妥善加以經營,失去即時的溝通效果,真是可惜。Visual Studio的開啟RSS(Really Simple Syndication)自動讀取設定,是專案即時公告的一個好去處,許多的宣導或外部資訊都可以輕易的在這裡實踐, 建議您不妨加以運用。

Written by ruddyllee

2011 年 01 月 06 日 at 11:49:36

張貼於未分類