技術的變與不變之間...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)，我很想寫的快，但是我更希望寫得好，畢竟一本可以對讀者長久有幫助的書，總比曇花一現的排行榜冠軍對我來說意義大的多。
面對新的技術，面對快速變動的技術，我真的覺得開發人員不需要擔心，因為經驗依舊是會累積的，開發人員的價值必須彰顯在你的經驗上，對於開發架構、對於規畫、對於專案運作的熟悉，比起對於特定技術的了解，更會是你與別人不同的競爭力和利基。
對於初學者，我想特別說句話：了解怎麼使用一種技術很重要，但是了解背後的原理、架構、和『為什麼』，一樣的重要…千萬別只是學會用一種技術，而不知道為何要用這種技術…
而且，還有很多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)，我很想寫的快，但是我更希望寫得好，畢竟一本可以對讀者長久有幫助的書，總比曇花一現的排行榜冠軍對我來說意義大的多。
面對新的技術，面對快速變動的技術，我真的覺得開發人員不需要擔心，因為經驗依舊是會累積的，開發人員的價值必須彰顯在你的經驗上，對於開發架構、對於規畫、對於專案運作的熟悉，比起對於特定技術的了解，更會是你與別人不同的競爭力和利基。
對於初學者，我想特別說句話：了解怎麼使用一種技術很重要，但是了解背後的原理、架構、和『為什麼』，一樣的重要…千萬別只是學會用一種技術，而不知道為何要用這種技術…
留言
我很喜歡去比較分析，假如程式照抄可行但我邏輯無法領會的，我會重新改寫。雖然對多數人來說這樣太苛求自我，但從中學到的經驗及體會多更多。
我寫的code不快，但都是經過考量設計，並考量到未來及過去可能會遇到的問題作規劃，所以寫出來的東西很少需要再大修。但staff不是這樣，不常看書卻寫code很快，review其code時是膽顫心驚，因此其中隱憂，很多洋人都撰寫說過了。
不看書不比較分析，當然寫code很快，但寫出來的東西能不能登堂入室，甚至讓新人觀摩學習時看得霧剎剎，我覺得這很丟臉且浪費自己的生命意義。
下載檔案會爆增，考驗網絡頻寬和使用者的耐心，尤其是台灣又貴以慢的獨大頻寬供應商的環境下。
希望不要步上多年前 Java Applet 的後塵，
大幅拖累整個 Web Application 的性能和速度
現在認真的人不多了，能夠先想過，再動手寫程式的人也不多了，現在很多人是先寫再說，結果當然就@(*^#*$&，我相信，成功是屬於認真的人的^_^
是的，這也是我一看到當時就有點擔心的問題，從很多角度看到Silverlight有慢慢WPF化的趨勢，但是畢竟WPF是個很臃腫的龐然大物，如果從跨平台的角度來看確實不妥，顯然這是MS要去努力思考和解決的問題。
以遊戲界來說，當年sony ps2 稱霸，微軟試圖以xobx 挑戰敗下陣來，但是不多時，微軟硬是砸下大錢，推出xbox360硬是靠銀彈攻勢把ps2 打敗，逼的sony 不得不加緊推出ps3。當然，如果今天xbox360同樣被ps3打敗，我想微軟還是會繼續砸下大錢，推出xbox720，試圖再一次以金錢創造的技術來重新取得領導市場的地位。遊戲界如此，軟體界亦然。
不斷不斷的推出新技術，舊的技術還沒學會，又再度推出新的技術。為的也是為了要打擊對手，試圖重新取得技術領先的地位，達成賺錢的目的。
但對於使用者來說，一直追著新技術跑，成為廠商希望創造出的結果，對自己絕對不是好事。真正的高手，就是能夠在不斷的變動之中，掌握那長久不變的，進而使用這些核心不變的本質，去適應不斷變化的環境。
對這些人來說，因為他掌握了核心，所以不管技術怎麼變動，他只要花少少的時間就可以適應掌握運用了，不論新技術再怎麼變化，對他來說都是易如反掌。
反之，如果不能掌握核心，只是不斷隨著廠商的腳步起舞，今推推出新技術A就學A，推出新技術B就學B，這樣的話永遠都只能成為環境變動下的犧牲者，而不能成為時代的創造者。
所以，讀者真正想看的，也就是這種可以超越各種變動技術，並將其一貫連結起來的知識。
學一種觀念知識，就可以適用各種變化的技術。也就是掌握了核心與本質。
而這種知識的整理與掌握，對初學者來說是絕對不可能做到的，這必須仰賴有大量經驗與知識的人，將其整理集中，歸納出所有技術都共用的結晶。如果能夠有這樣的品質保證，那麼這樣一本書才比較能夠不斷變動的技術中生存吧。