景氣寒冬中的小聖誕樹

一年當中，我覺得最讓人喜歡的節日莫過於聖誕節了，對我來說，聖誕節一直以來都是有著多重意義的，這個節日不僅讓人覺得溫馨，也有一點數算過去一年的點點滴滴，然後把希望寄放在即將來的另一年的感覺，好不容易，緊繃了一年，一切的勞苦愁煩似乎轉眼成空，終於在一年中剩下的幾天當中可以放下忙碌，讓腳步緩一緩，從容地深深吸一口氣，讓自己準備好心情迎接另一年的開始...

很有趣的是，每一年這個時間，不管你在台北街頭的哪一個位子，商家們總是很有默契的，一起放出了聖誕歌曲，讓你想忘了這個節期都很難，大家一同把塵封了一年的聖誕樹重新擺出來，景氣好的時候，樹一顆比一顆大，有一年，我特別抽了一天空，當天什麼事情都不做，就在台北街頭找聖誕樹進行David私人票選，看看哪一棵樹最大或是最亮眼...

這張照片，是周末的傍晚，我在園區的一家西雅圖咖啡寫稿，老實說，店裡面冷清到不行，幾個和我差不多年紀的客人，盯著NB螢幕的專注地盯著螢幕，喝咖啡看書的也鮮少抬起頭，不過我最喜歡這種店，不會有人吵我，所以儘管西雅圖的美式咖啡老實說今天真的難喝到不行，但我依舊有機會就來消費算是支持它，免得店家撐不下去又倒掉(別怪我烏鴉嘴，天知道這邊已經倒了多少家Starbucks，有些你喜歡的店，現在要常去支持，否則消失得很快，才一陣子沒去，店門口就變成招租的廣告)，回到店裡，戶外其實很冷，約莫15度上下，但是店裡頭瀰漫的溫暖和咖啡香，我面前有顆小小的聖誕樹，店裡面也播放著聖誕歌曲，從喜樂的普世歡騰到寧靜的平安夜，我久違了的聖誕歌曲，在我30好幾的歲月當中，有連續著好幾年，聖誕節我是在充滿著溫暖的聖誕聚會當中度過的，我很喜歡那種外面冷冷的，但是屋子裡滿是溫情的感覺，它會讓你忘掉一年的煩惱，放開一些困擾你的不如意，讓你暫時避開煩心的事情，可以有餘力回過頭來，看看自己的人生是否真如自己期待的那樣，一步一步地往前邁進...

景氣寒冬中的聖誕樹，其實和往年一樣閃爍，並沒什麼特別黯淡之處，店裡面的客人少，但是服務員卻相對的熱情多了，我和我的NB在一角，欣賞著聖誕樹、欣賞著落地窗外來往的人群，牽著手的情侶、趕著公車的婦人、假日在外遊玩到不捨得回家的學生...

最近新聞上，沸沸騰騰的幾乎都是景氣不好或是裁員的消息，300人、500人、上千人，有時候我想，企業是迫於無奈可以理解，但是想到居於弱勢的基層員工，因為對公司的價值低，難逃被拋棄的命運，外面已經夠冷了，每一個被迫離開公司的人，也都有家人、妻小、房子搞不好也有貸款、子女的學費還是得張羅，想到，不免令人有些感傷...

歲末，回頭看，2008年對台灣來說甚至對全球來說都是辛苦的一年，對我來說也是，今年發生好多事情，著實讓我經歷了人生挺艱苦的一個部分，明年呢? 明年又會如何呢? you never know...yep, 呵呵... 那句話怎麼說來著?

Life is like a box of chocolates, you never know what you gonna get.

也許因為景氣不好，聖誕樹變小了，但是我想無論多小的聖誕樹，總是依舊可以給人一種溫馨穩定平安的感覺，或許重點一直都不在樹的大小，而是究竟我為自己留了多少時間來欣賞它...也或許，該是把自己心裡也清出一點空間，擺上心裡的聖誕樹的時候了。









如果你不喜歡太小的樹，這邊也有稍微大一點的，這是經過客戶公司的大廳時，順手拍的樹...能擺這麼漂亮的聖誕樹的公司，今年應該不會裁員了吧 ^_^

Silverlight Toolkit中的圖表繪製功能 - 透過程式碼來繪製圖表 與 資料繫結

這一篇，我大致介紹了如何透過程式碼來繪製圖表，在這個影片當中，也同時介紹了圖組如何與特定的資料物件進行資料繫結，Silverlight這個功能相當有意思，過去我在研討會上有介紹過Silverlight資料繫結的觀念，和ASP.NET不同，Silverlight的資料繫結機制原則上是進行在用戶端的，主要是讓記憶體中某個物件的Property與前端Silverlight UI element的Property之間進行繫結，和ASP.NET透過宣告式語法讓前端介面與資料庫進行繫結的觀念不盡相同。這是因為對於Silverlight來說，資料庫在遠端，所以Silverlight無法直接和遠端的資料庫進行繫結(這樣做也沒意義)，但是卻可以透過WCF將遠端的資料以物件的型式傳送到用戶端的記憶體中再與UI element進行繫結。

anyway, 我們先來看怎麼透過程式碼繪製圖表，接著我會再陸續把其他關於Silverlight toolkit的範例和教學影片放上來，希望對各位有幫助。

[下載影片]

Silverlight Toolkit中的圖表繪製功能 - 透過XAML碼來繪製圖表

在12/4微軟的研討會當中，我Demo了如何透過Sivlerlight Toolkit來繪製圖表，你會發現透過
Sivlerlight Toolkit可以很輕易的建立出和使用者可以互動的圖表功能。相關Demo請參考上一篇BLOG。

不過，萬丈高樓平地起，我們先來看怎麼透過XAML繪製圖表，底下是Silverlight Toolkit中的圖表繪製功能的第一篇 - 『透過XAML碼來繪製圖表』，時間允許的話，我會再陸續把一些範例和教學影片放上來，希望對各位有幫助。

[範例下載] [下載影片]

研討會：利用Silverlight Toolkit豐富你的Web應用程式 - 投影片 與 範例展示

先前提到過的 12/4 在台灣微軟舉辦的『利用Silverlight Toolkit豐富你的Web應用程式』研討會 的相關 投影片 與 其中那個DataGrid與Chart的資料繫結範例展示 請點選下載。

很感謝當天現場參與的每一位朋友, See you next time ^_^

BTW, 有學員問到先前幾場研討會的相關投影片，請參考台灣微軟網站：
http://msdn.microsoft.com/zh-tw/aa570302.aspx

利用Silverlight Toolkit豐富你的Web應用程式

12月4日，將在台北微軟 7樓舉行一場MSDN研討會，重點將放在Silverlight Toolkit，對Silverlight有興趣(或是對如何在網路上建立圖表、或是數位儀表版...等有興趣)的開發人員請千萬別錯過囉，除了會場中所分享的內容之外，如果時間允許的話，或許我還可以提供一些額外的Resource，總之，到時候見啦。

搶先報名吧：http://www.microsoft.com/taiwan/msdn/events/webexperience/event081204.htm

議程：
Silverlight 2.0 開發技術簡介
Silverlight 控件 與 User Control 的使用與開發
Silverlight Toolkit 介紹與使用技巧
內容：
　　眾所期待，Silverlight 2.0 終於在 2008 年底正式與我們見面，在這個版本當中，除了原有的 Web 動畫影音技術外，還大幅增加了資料繫結、遠端資料存取、控件、樣板樣式、多執行緒…等開發人員所需的各種功能，一舉將 Web 應用程式開發帶向另一個嶄新的里程碑。
　　隨著 Silverlight 2.0 的上市，微軟同時提供了 Silverlight toolkit 這一套內含原始程式碼的控件集，讓開發人員在架構 Silverlight 應用程式時免費使用，透過這組控件可輕易的產生各種互動式圖表、使用諸如 TreeView, AutoCompleteBox, DockPanel, UpDown, ViewBox…以及未來多達數十種控件與UI外觀樣式。 在這一個場次當中，我們將透過實際的範例，帶領學員進入 Silverlight 應用程式開發的領域、體驗 Silverlight Toolkit 當中豐富的控件，讓您將 Web 應用程式開發帶向另一個全新的未來。

技術的變與不變之間...Silverlight 3.0的驚鴻一撇

今天在公司開會的時候，一位作者好友透過MSN通知我Scott的BLOG上果然開始出現了Silverlight 3的消息，我一聽不得了，第一時間看了Scott的BLOG，大意是說，Silverlight 2在今年推出正式版之後，在一個月內，已經有超過100 million(哇哇，超過一億? 會不會太誇張??? 應該是很多機器overlap的重新計算了吧，像是我，至少裝了30次)機器安裝了Silverlight 2(不過，聽起來微軟好像對這個數字很爽的感覺^_^)。

而且，還有很多Sivlerlight 2使用在產品中的真實案例(嘿嘿，當然，內舉不避親，其中我覺得最重要的，就是K2的blackpoint，如果有人對這個產品有興趣，可以跟我聯絡)，足以證明Silverlight 2是一個可以真實應用的開發工具。

接著Scott趁勝追擊的說，將在next year推出下一個版本的Silverlight 3，令人興奮的部分是，在大家開罵了很久之後，終於，終於，可以在Visual Studio和Visual Web Developer Express當中以所視即所得的方式設計Silverlight了，Data Binding的部分也有工具(Wizard)可以設定，而不需要手動去下Code(剛好這件事情就是那天去參加好友的seminar後，在路上和他討論的問題，嘿嘿，沒想到他還真有先見之明)，另外加上對3D的支援，以及對H.264 video格式的support...總括一句話，就是功能越來越強就對了(老實說，就是Silverlight的WPF化)，然後Scott暗示大家趕快投入開發的行列，因為早晚有一天，Silverlight會把Fl?x幹掉(後面這句話是我自己加的...^_^)

看了這一篇BLOG之後，我挺有感概，技術變化得太快了，對於寫書的作者來說，會不會是一個很大的打擊呢?Silverlight 1.0的書才剛出，Silverlight 2.0就馬上Beta 1，現在Sivlerlight 2的書還沒出，馬上就有Silverlight 3的消息，是怎樣?拼進度嗎?

回頭想想，到底是哪個環節出問題? 是外國人太快，還是我們太慢? 老實說，我相信大家都沒什麼內幕消息，而且現在到處都是BLOG，訊息非常透明，要有秘密也不容易,也就是說，這些Roadmap是大家早已知道的，而且三五不時釋出一些消息早已是常態，所以開發人員應該要習慣這樣的狀況。

ASP.NET不也是這樣? ASP.NET 2.0出沒多久，又多了一個ASP.NET AJAX 1.0(而且回想一下，AJAX 1.0出之前，Altas炒了多久?)，又沒多久ASP.NET Futures出現了，然後接著是ASP.NET MVC Preview…、然後是ASP.NET 3.5，出了不到半年，馬上來個ASP.NET 3.5 SP1，然後PDC剛過，ASP.NET 4.0的Roadmap就丟了出來…搞什麼???

無言，改版更新已經是常態，從過去的一年、一個月、變成一季、每個月、加上BLOG推波助瀾，你會覺得幾乎每周都有新的東西，資訊是自由流通了，開發人員其實是很幸福的，隨手就能掌握最新資訊，有點蓋茲當年說『資訊隨手可得』的味道…

技術變更的那麼快，是不是真的會讓開發人員很辛苦呢? 仔細想想，其實不盡然，因為變與不變之間，是有那麼一條線存在的。

如果你追的是技術，我要說確實，你可能真的會追得很辛苦，開發技術是一直在變的，學會特定的技術不見得會幫助你成長，頂多只能幫助你『解決問題』。是的，這些技術都是在解決特定的問題，有問題、有解決方案、有新問題、有新的解決方案，如此而已。

技術會過時，毫無疑問，會的，但是累積的經驗不會，過去的COM過時了，過去的DAO、RDO、ADO過時了，甚至Web Services可能也要過時了，但是當面對新東西、面對ADO.NET、面對LINQ、面對WCF、REST…，我要說，如果過去你學的扎實，你會知道為什麼這些新技術會誕生，每一個技術的誕生都是為了解決過去的問題，彌補不理想的部分、如果過去的底子厚，新技術難不倒你，你會觸類旁通，久而久之，你會從技術的follower變成forerunner，最後成為技術的Leader。

但是如果一開始學習時，只是速成式的囫圇吞棗，如果你只知道怎麼用一們技術，卻不明白為何需要這個技術，例如：很多人知道『物件導向』，卻不知道為何需要『物件導向』或是『物件導向』技術的目標與優點，那問題就很大了，同樣的，你上面把這句話中的『物件導向』四個字，換成LINQ、WCF、WF、Silverlight…，換成哪一個term都行，因為放諸四海皆準)

知其然而不知其所以然，會有蠻大的問題，在學習的過程當中，這些技術沒有『內化』成你的一部分，這會是一個很大的問題，在ASP.NET技術中，很多部分也是這樣，有很多工具我們都會用，但是不盡然知道為什麼，當然我能理解，因為現在專案的特性，需求變動大、結案時間短，架構、規畫這些東西根本不在很多開發人員的考量當中，許多開發人員只是希望能夠盡快用自己熟悉的技術做完專案，然後結案領錢，說實在的，因為規模不夠大，所以也不見得有辦法用足夠的預算談規格，如果是價格標就更有可能是這樣。

所以我們手上有很多速成式的開發工具，很快速的幫助你完成一個系統，它的取向是速成，但是卻拋棄了架構和延展性，ASP.NET中的幾個XXXXview控件就是典型的例子(不過我要強調，它不見得是這些控件不支援，只是很多開發人員選擇走捷徑，把SqlDataSource和xxxxView拉一拉了事，完全不管這樣的結果會如何)。

這讓我想到『尼可拉斯凱吉』演的『氣象人』，其中有一段話，因為主角常被路人拿速食(例如熱狗、漢堡、可樂…)ㄎㄟ，他不明白為什麼，後來靜下心來，他發現自己就像速食，每天在電視台上報氣象，短短五分鐘，沒什麼營養，但是卻能夠馬上吃飽，看起來有模有樣，年薪很高，但是骨子裡卻很空洞。

我發現這個對速食的描述真是太好了：『很快能吃飽，但是卻沒什麼營養』。在我們這個時代，實在有太多東西是這樣的了，我們很快的兜出一個解決方案，迅速滿足客戶的需求，客戶在煞那間似乎覺得飽了，但是老實說這樣的解決方案沒啥營養，不能長久的徹底的解決問題，但是似乎大家也接受了。我們的學習也是這樣，速食導向，在學校裡學了很多的技術，把大家餵的飽飽的，但是是不是很有營養，真的很難說，有多少技術出了學校就在也沒用過了，或許我們要學的是觀念，而不只是技巧…

我自己也檢討了一下，是不是我們寫書時也會掉到這樣的陷阱中，塞了很多東西把讀者餵飽，頁數厚厚的，感覺很超值，但是營養卻不夠，很快的，大家就餓了。

過去這一年，我花在寫書的時間上很少，因為我對技術書有蠻強烈的消耗品的感覺，一張好聽的CD，我可能可以保留很多年，但是隨著資訊技術演變的速度，現在一本書放在架上可能不到一年半就要say goodbye了，讀者買了佔書架，搬家的時候也累，讓我覺得有點罪惡感，當然，我不是說寫書不好、或是大家不應該看書，反而我覺得大家應該多買書、多看書、不然很多全職的作者很辛苦的，而且如果好的書沒有被鼓勵，那有心的作者會越來越少…

而對我來說，我希望能慢慢調整，能夠寫一些可以長久的書，不會隨著技術的演變和改版而凋零的書，當然，新技術我們還是會介紹，但是BLOG不是比書來的迅速多了嗎?

以前我記得老師在指導我們如何蒐集資料時，提到一個觀念，如果大家希望找到最新的第一手資訊，那期刊或許可以滿足你的需求，但是如果你需要觀念，需要完整的引導、需要奠定基礎，那書本永遠是最好的選擇，一本書是作者『經年累月的經驗累積』。

『一本書是作者經年累月的經驗累積』，我對這句話很有感覺，我希望自己寫作，能夠在書本當中呈現的是經驗的累積，而非只是技術的介紹，畢竟現在以BLOG介紹新技術是最好的選擇，想到隨手就寫，沒有時間空間的限制。

而出一本書，我真的不想再被版本趕著跑，對讀者來說，我可能要Say Sorry(對出版社我也得說聲Sorry)，我很想寫的快，但是我更希望寫得好，畢竟一本可以對讀者長久有幫助的書，總比曇花一現的排行榜冠軍對我來說意義大的多。

面對新的技術，面對快速變動的技術，我真的覺得開發人員不需要擔心，因為經驗依舊是會累積的，開發人員的價值必須彰顯在你的經驗上，對於開發架構、對於規畫、對於專案運作的熟悉，比起對於特定技術的了解，更會是你與別人不同的競爭力和利基。

對於初學者，我想特別說句話：了解怎麼使用一種技術很重要，但是了解背後的原理、架構、和『為什麼』，一樣的重要…千萬別只是學會用一種技術，而不知道為何要用這種技術…

以WCF來開發RESTful風格的服務

　　在上周『從Web Service到RESTful WCF的心情』一文中，我提到了對REST的感想，而這一篇，則是介紹.NET 3.5 中對REST的支援，說明如何透過WCF開發RESTful服務，不過，當.NET開發人員要透過WCF來開發RESTful的服務之前，有一些基本的觀念需要釐清。所謂的REST技術，其精神是透過Uri來描述存在於網際網路上的資源，例如：

　　　　http://www.studyhost.com/Eshop/Products/Nokia5130

　　上面這串網址可表示一個產品資料表中的產品，產品名稱為Nokia5130，若我們想取得資料，可透過HTTP GET方法，以上述網址來取得。

　　若我們想刪除這個資料，則一樣是上面這串網址，但是對IIS伺服器送出的動作則是HTTP DELETE。如果我們想建立一筆新的資料，則可透過HTTP POST方法，至於要修改，則透過HTTP PUT方法。

　　也就是說，描述資源是透過Uri，而對資源要進行的動作，則是透過HTTP verb來進行。有了這樣的觀念之後，我們就可以開始嘗試建議建立RESTful的 WCF服務。我們建立出的WCF服務，只需要遵循上述的 REST風格，即可讓所有的開發人員存取。　　

　　一直說REST風格而不說REST規格，主要的原因是REST並非是一種哪一個機構或是協會設計出來的規格，由於架構簡單，它僅僅是一種設計風格，就是兩個要點，用Uri來描述資源位置，用四種Http Verbs(包含GET, POST, DELETE, PUT)來決定對這個資源要進行的動作，甚至當我們用調用某一個RESTful的服務時，該服務回傳的資料也沒有一定要以XML型別回傳，也可以是單純的文字或是HTML。總而言之，它就是簡單導向。

　　而HTTP Verbs到底是什麼呢?這對於絕大部分時間僅僅使用瀏覽器的開發人員來說，可能有點陌生，HTTP Verbs是HTTP協議定義出的規格，HTTP共有八種動作，包含：HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT，過去我們常用且熟悉的應該是HTTP GET和HTTP POST，當你在瀏覽器上輸入一個網址，對於IIS伺服器下的指令其實就是HTTP GET，而當你在瀏覽器上按下某一個Submit按鈕(或是ASP.NET的postback)，其實就是對瀏覽器下HTTP POST指令。

實際建立RESTful的WCF服務

　　由於.NET 3.5的支援，我們可以透過相當簡單的方式來建立RESTful的WCF服務，若開發人員想透過WCF技術，來開發RESTful的Service，只需要在VS2008 SP1的專案範本中，選擇AJAX-enabled WCF Service即可：

接著，您會看到底下的程式碼：

　　如果您將最上面註解的『WebGet()』槓掉，該服務就會是一個RESTful的服務，支援 HTTP GET方式。

　　不過要讓這個服務能夠正式運行之前，我們必須針對Web.Config作一些調整，請把區段中的『enableWebScript』取消：

　　另外，請開啟RESTfulWCF.svc檔案，在.svc頁面的網頁前置詞當中，加入『Factory="System.ServiceModel.Activation.WebServiceHostFactory"』，如此一來，這個RESTful服務才能夠正常運行：


　　有了這些概念之後，我們立刻來嘗試建立一個簡單的例子，請建立一個GetData Method，該Method具有一個參數Name，接著在Method上，加入WebGet修飾字，給定UriTemplate即可，相當的簡單：


　　UriTemplate是指這一個RESTful服務的呼叫方式(嚴格說起來是描述該資源的Uri位置)，是要以何種Uri來表達，透過這種方式建立出來的WCF服務，就直接支援了REST型態的遠端呼叫方式。
　　例如，上例中我們給定的『UriTemplate』是"User/{name}"，則這個資源可以透過底下的網址來取得：

http://localhost:56712/RESTfulWCF.svc/user/david

　　其中的『david』是UriTemplate中的{name}參數，而這個參數可透過我們定義在GetData()中的name參數取得，目前我們在GetData()中僅是將這個參數加上一些文字然後回傳，表示回應了用戶端對資料的呼叫，而呈現出的結果如下圖。我們可以在瀏覽器上直接以HTTP GET來測試：

　　很簡單的，就建立了一個RESTful的服務。