如果你的Windows Azure 應用程式執行時得到這個錯誤訊息

<= SDK 1.2改到SDK 1.3WebRole Hosting的差異圖示

 

 

 

被連續問了幾回，特別在這裡說明一下:

如果你的Windows Azure 應用程式執行時得到這個錯誤訊息:

“SetConfigurationSettingPublisher needs to be called before FromConfigurationSetting can be used”

這是因為SDK 1.3版已經可以支援完整的IIS功能，也就是執行程序又交回給標準的W3WP.exe 程式了，這個時候請將原本寫在WebRole.cs內的 OnStart()

讀取 RoleEnvironment.GetConfigurationSettingValue 的程式區塊移到 Global.asax 的Application_Start()內就可以了。

搬移後的Application_Start()如下:

• void Application_Start(object sender, EventArgs e)
  {
  // configuration settings change in the service configuration file.
  CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
  {
  // Provide the configSetter with the initial value
  configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
  });
• }

另一個新的問題: 403 – Forbidden: Access is denied.

這也是SDK 1.3 之後才有的現象，原因是 Azure的web-site 不會自動抓取設定起始網頁(當然改成default 也可以),

所以當你吃到這個 error 之後只要在URL 最後在加上正確的網頁名稱就可以了，也就是你要能指向正確該啟動的網頁，

例如:

• http://soainput.cloudapp.net/startup.aspx

甚麼是完整的 IIS 功能，說穿了就是一開始是Windows Azure 自己的一支程式在做這件事(叫作 WaWebHost.exe)，現在改回來由IIS來 Hosting了(W3Wp.exe)，

當然就不需要在webrole.cs內做 OnStart()時做 configure  值的設定了.

可以參考Marx 的說明:  http://blog.smarx.com/rss

OData 是微軟近年來名字取得最好的一個傢伙了…

OData 是微軟近年來名字取得最好的一個傢伙了…

全名是Open Data Protocol,
代表名稱是WCF Data Service；但實在看不出來它哪一點跟WCF扯上關係了。但好東西就是好東西值得推廣一下。

It’s an open web protocol for querying and updating data.

它是一個開放的網絡協議，專門運用在查詢和數據的更新。

(透過Http回傳Atompub、JSON、XML)

http://www.odata.org/developers/protocols/overview

到目前為止，已經可以由 SQL Server、 SharePoint 和Windows Azure 平台上運用OData取得資料儲存的資料表，而且可以使用OData來建置便利讀取的API也已經有SDK了(http://www.odata.org/developers/odata-sdk)。如上所述，Microsoft 達拉斯專案(是尋找和查詢資料的雲端服務)也公開的表示會使用 OData 通訊協定。你或許會擔心OData可能只限於Microsoft 產品，但IBM最近宣佈WebSphere 7.0 產品現在也開始支援OData通訊協定。

是標準的RESTFul，並運用ATOMPub規範來傳遞XML資料，

前途一片光明嗎??? (但實在好用)

可以到OData（http://www.odata.org）網站。直接讀取它的OData服務：http://services.odata.org/website/odata.svc。它就會回覆你一個 XML文件，列出不同的實體集可供選擇：(我用IE9的developer tools 查看回傳的JSON值，顯示如下)

圖 http://services.odata.org/website/odata.svc

實際用一下，我們來試一下直接讀取Twitter的查詢關鍵字Silverlight 的傳回值(長長的XML看起來就會有一點複雜???)

這一串XML你可以輕易地讀出來的，但XML當然不是給人看的，應該由以下程式碼來解譯:

1. // 用LINQ 讀到後放到這個Collection內
2. private ObservableCollection<Tweet> _tweets = new ObservableCollection<Tweet>();
3. private void GetTweets_Click(object sender, RoutedEventArgs e)
4. {
5. WebClient client = new WebClient();
6. client.DownloadStringCompleted += (s, ea) =>
7. {
8. XDocument doc = XDocument.Parse(ea.Result);    // 用 XDocument 讀取回傳的XML資料
9. XNamespace ns = “http://www.w3.org/2005/Atom";  // 一定要再補上NameSpace
10. var items = from item in doc.Descendants(ns + “entry")      // 選取 entry 的區塊
11. select new Tweet()                // 這裡我們只要 title 及 link 二個資料項
12. {
13. Title = item.Element(ns + “title").Value,
14. Image = new Uri((from XElement xe in item.Descendants(ns + “link")
15. where xe.Attribute(“type").Value == “image/png"
16. select xe.Attribute(“href").Value).First<string>()),
17. Link = new Uri((from XElement xe in item.Descendants(ns + “link")
18. where xe.Attribute(“type").Value == “text/html"
19. select xe.Attribute(“href").Value).First<string>())
20. };
21. foreach (Tweet t in items)
22. {
23. _tweets.Add(t);         // 填到 Collection 內
24. }
25. };
26. // 運用webClient 非同步讀取Atom 傳回的資料
27. client.DownloadStringAsync(new Uri(“http://search.twitter.com/search.atom?q=silverlight"));
28. }

結果顯示為:

有興趣的人可以去http://msdn.microsoft.com/en-us/library/ff478141.aspx

欣賞一下，一定值回票價的。

回頭看了一下這篇文章，真糟糕!  OData 好像被我寫複雜了，但實質上它是為了Web上簡易查詢所出現的服務，尤其在RIA 上可以施得上力，我是在準備 Silverlight的課程範例時找到的寶。這是在這一陣子的Web Service 風潮下的精緻產物，也可以作為研究生的研究對象，相信它對雲端的資料傳遞會有著巨大的影響的。

我們公司裡沒有測試團隊怎麼辦?

我們公司裡沒有Test Team

原本就一直想寫一篇有關軟體工程測試的文章，尤其在參觀過Will 公司裡的Scrum開發團隊之後，實在按奈不住手癢的心，就有了這篇文章。

 首先要稱讚一下Will公司裡的Scrum開發團隊，真是一群用功的年輕人…

 Scrum 裡頭沒有明確的規劃測試團隊

但這不代表Scrum 就不適用在測試團隊，別忘了! 它是 Agile 的一員；因此早已將測試融入開發團隊中了，但這也引出了一個現象，這種擁有高度彈性的理論所衍生出來的效應，有一派人士重新為Scrum 加入各種測試的腳色，讓 Scurm 的精神融入測試團隊中。但也有另一派人士直接將Scrum的腳色套用在測試團隊內，也沒有重新定義任何核心的腳色，看來是在各說各話；但實質上卻也都能解決一堆特定的問題，都是有價值的東西。 

• 重新為Scrum 加入各種測試的腳色: http://www.docin.com/p-55727339.html
• 直接將Scrum的腳色套用在測試團隊: http://qa.taobao.com/?p=3987

看來看去都OK， 這就是 Agile 敏捷理論ㄚ! 沒有絕對的對錯，而是視運用的環境來彈性的做調適，重點應該放在是否能解決在軟體開發上的問題才是王道。

 言歸正傳；Visual Studio 的Team Foundation Server 採用了Scrum 的開發模式，那有關測試的部分怎麼做呢?

要在成立開發團隊時也成立測試團隊嗎?

這樣做會不會成本太高了呢?

國內的中小型軟體開發公司有人願意這樣做的嗎?

 這些問題才是本文想探討的； 我們都知道新的軟體開發教本上，明確地跟我們說測試是開發的一環，一旦需求分析出來時測試就要開始動起來了，測試人員要依據出爐的需求文件去撰寫、設計測試案例。

 (記得有一回百敬問我；誰最應該負責寫測試案例呢?

答案是: 負責測試的QA人員)

 話是這樣說沒錯啊! 但就這麼區區的 3、5 個開發工程師，人力都明顯地不足了還能另外成立專職的測試人員啊!  這；不是太不可思議了嗎?

 但；這就是品質的代價!

解決之道: 在團隊中；加入一位較年輕的Associate Engineer負責 QA測試

通常我會建議，在團隊成立之初，想辦法加入一位較年輕的Associate Engineer負責專職的測試工作, 此舉能在不讓成本提升太多的情況下又能按部就班的培養新人。要知道；測試的工作是最能培育優秀程式設計人員的搖床，尤其是還沒有很多壞習慣的年輕工程師，讓他多綜合的看一下資深工程師的程式碼，是絕對有用的。

 記得多年以前在宏碁的R&D裡我們是採用不同的開發團隊交互測試的方式，讓團隊互相測對方的產品，這樣做是可以省下一些開銷的，而且又能促進相互了解對方的產品，也是可以採行的一種方式。但；一旦大家都很忙的時候，成效就要大打折扣了。

 切記! 怎麼做都成…就是不要不做測試，或是只讓工程師自己做自己的測試工作，那就等於原來的品質了，對品質保證而言；並沒有再加分或有所提升的地方，這些新一代的軟體工程理論，也就幫不上你的忙了!

 其實；我真正想說的是，如果你只是單獨去運用TFS所提供的各項測試功能，而沒有融入MSF agile 5.0 內所提供的 Scrum理念來處理複雜的軟體專案開發上的問題的話，就享受不到新一代軟體工程所帶來針對軟體開發的改善成果了。在這裡要呼籲一下，已經裝好TFS的Visual Studio 用戶，如果你還沒受過 Scrum的洗禮；請到這裡去一下吧:

Scrum Alliance:  http://www.scrumalliance.org/resources/270

身為父親的反省，也跟facebook及噗友們交代一下行蹤

好久沒上Facebook 及Plurk 了，若跟你們講真話，鐵定會挨罵的! 但下面講的是實話。

因緣際會; 上完中央大學軟體工程的課後，有一種持續放不下的感覺，終於發覺給自己孩子們的時間太少了，我總是埋怨他們作息不正常，晚起然後凌晨3、4點才睡，但這不是我沒機會跟他們聊天的藉口。我可以在私底下回答一群跟他們年齡相似的小朋友們(那五所大學可愛的孩子們)的一大堆問題，卻一個星期沒跟自己的孩子聊上幾句話，這個父親做錯了，我錯了! 所以該用心的經營這段父子之間的關係才是，所以；我把上Facebook 及Plurk的時間都挪出來了，只要想到要上噗浪的時候，就想一些可以為孩子們多做一些的事，那怕只是清理一下他們的房間(這是苦差事…)，並常常跟他們聊到深更半夜，這件事讓我們之間的生活突然變得更有趣了許多。雖然最近事多又忙著救火，但真得救的過頭了，把一大堆的事都攔下來自己做，但也因此跟孩子們的作息變得更接近，嘗試著盡量不在書房趕工，把深夜的工作挪到餐廳去做，無形中跟孩子們碰面的機會變多了許多，也感受到他們的關懷，真舒服…。

應該多停下來靜靜地聽他們說話才是，我總是太急著下結論了，或是急著給他們一些建議，其實；應該讓他們去自己嘗試去創造自己的生活才對，不要老是把期望掛在臉上，這樣會給他們過大的壓力的，多相信他們一點、再多給他們一些自由的空間，會更好的。

這陣子沒上Facebook 及Plurk，使得生活好像突然間少了些甚麼，那些有趣的事兒少掉了許多，當然一些該自己回答的問題也都沒去回答(一定被罵太懶了)，但能夠多給孩子們一些個關懷，這些損失是值得的，相信不久的將來自己一定可以找到這中間的平衡點，再回來好像不難，但跟孩子相處在一個屋簷下的時光卻越來越少了，要珍惜! 這是在跟五所大學的學生們上課時自己體會到的，4天共24小時的課程，加起來比這幾年跟自己孩子們講的話還多ㄟ，真慚愧，該回過頭來彌補一下了，也向跟我作同行的講師們說一下，再多給自己的孩子一些時間吧!

獻給 中央大學軟體工程課程 — 軟體測試之道

Ruddy Lee

這篇文章是獻給犧牲了連續四個星期六；來上課的同學們的(包括:中央大學、輔仁大學、海洋大學、台北科技大學、台中教育大學)。

我想跟你們說: 能跟你們在一起上課是我的榮幸，你們在課堂上問的問題，讓我又覺得自己跟我的三個孩子之間的距離變近了許多。這些問題好像是他們早該提出來問我的。但卻錯過了，這都應該歸咎於我的疏忽吧! 沒能做好一個父親應該扮演的角色；沒能及時跟他們一起討論未來，但；或許還來的及…，這一點要特別感謝大家。

首先；我決定開始留長髮了! 背負著這個所謂的『國父的形象』好多年了，今天感受到你們的朝氣，好舒服、真愉快，年輕真好…，很想再年輕一次，雖然這是完全不可能的，但心智上卻是一定要做到的，所以就讓那一簇還能長長的髮根，繼續爭扎的活下去，變長吧! 上課時；有一些個問題是我即時回答後，自己一直覺得沒能好好描述的，藉著這篇文章，希望整理出一些規則來，讓有相同困擾的同學有所依循，請參考。

問題: 面對一個龐大的軟體程式(原始碼)，我該從哪裡開始呢?

問的真實在，作為一個軟體工作者而言，我們大概都會有經常遇到這種問題的機會，到底該如何處裡呢? 說來話長；底下這本書就是完全在談這件事的，一定要看。

『軟體構築美學』

原文: Brownfield Application Development in .Net

作者: Kyle Baley ‧ Donald Belcham

中譯: 蔡煥麟、張簡才祿

我不想長篇大論來談閱讀這本書後的心得，這一點就留給你們自己來吧! 我只想分享一下自己多年來的習慣，供大家參考。

步驟一、先從外觀開始，先了解它的基本設計理念，弄清楚它為何會長成這個樣子。這一點如果可以直接從文件或是輔助說明上看到，那可以算是相當幸運的事了。雖然正確與否難免還要花上一番手腳之後才能見真章，但有文件可以閱讀已經可以算是一個好的開始了。

步驟二、接下來便是運用『探索性測試』的時機了。先由主要功能試起，一路玩到次要功能，再到不起眼、容易被忽略的邊界問題去走走，記得一定要做筆記，記下你探索後的發現，千萬不要急著做一些破壞性的測試，企圖很快找出問題的作法，往往會演變成見樹不見林的效應，反而把時間花在一些個不起眼的細微錯誤上，相當浪費時間。所以要先記下來，事後再看筆記時就比較容易分析問題的輕重及影響的大小了。

步驟三、試著降低程式的相依性，然後才是減少程式的複雜性。在動手改程式之前，一定要先有單元測試來支撐你的重構動作。所以先針對想要拆解的程式模組，進行所謂的單元測試，再做好單元測試之後便可以大膽的進行重構了。千萬不要一次就做一大堆單元測試，然後才去做程式的重構動作。最好是針對相關的模組，一次做完三、五個單元測試後便進行一次重構，才不會發生浪費一再的重複對同樣的程式重疊的作重構的現象。

步驟四、試著問自己，如果採用相同的程式架構(framework)下，重寫一次需要花你多少時間? 若是重新改個新架構時，是不是會更好或是更省時間呢?這是我一向最喜歡採用的徘徊在抽象與明確之間的交錯判斷方式，這種在巨觀與微觀之間的來回思索方式，往往可以讓人對整個專案看得更清楚更容易客觀的做出決定。

步驟五、一定要不斷持續的進行整合與部署。不要一意按部就班的在進行大幅度的程式修改，經常回過頭來將整個程式做一個完整的整合的動作，絕對是值得的一件事，它可以讓你及早發現不該犯的錯誤，並即時的回頭。

步驟說完了，但好像意猶未盡，有緣的話；下回見了… 不知道；到時候我的頭髮可以長到多長了，哈!

!