2008年7月25日 星期五

重要的事情先做

從事IT行業多年,我一直有一個深刻的感覺,資訊科技日新月異,要能夠掌握足夠的資訊技術,並且讓自己能夠在業界不至於被淹沒甚至能夠在眾多的強者中異軍突起,所需要花費的精神和時間有時候已經讓人喘不過氣。不管是哪一個領域,MIS、SI、Vender site、User Site、Consultant、Trainer我大多都有扮演過這些角色、或多或少也都能夠體會不同角色中的辛苦。

不過也可能是因為IT相關領域(特別是Developer)所需要涉獵的知識一直在變和增加,這些部分已經讓人耗費心力,使得IT人員在一些基礎的管理技能上,顯得有些缺乏。說真的,我認識的IT人員很少不是聰明人(意思就是大多數都是聰明人...我真怕現在很多人看不懂這樣的中文寫法...),我覺得大家都很Smart,但是往往由於缺少了一些基本的管理知識,在專案中常常變成無頭蒼蠅,忙碌,卻不一定能夠產生預期的效益。

關於這部分,我最近和一個同事提起,對於IT人員,不管是系統開發人員,或是MIS、你要妥善規劃你的時間,有一個很關鍵的技巧,就是把重要的事情放在前面,重要的事情先做,一直是時間管理當中很重要的一個部分。

不知道你有沒有讀過一本很不錯的管理書,作者把事情分為四種,急迫但不重要的(P2)、重要但不急迫的(P3)、不急迫也不重要的(P4),即重要又急迫的(P1)。


我記得我以前曾經提過這個觀念,這個觀念對我有非常大的幫助,我一直想找時間與大家分享,回頭想想這四種事情,你會先做哪一種? 你在哪一類的事情上你花了比較多的時間???

一般人P1一定會先做,這個毫無爭議,典型這類的工作是:家裡失火、急病住院…不過這些事情都不常發生,更具體一點的工作像是明天要交付驗收的專案、下午會議要用的報表…等,都屬於P1的範疇。

P1類型的工作往往不會佔用你絕大部分的時間,但是如果你發現自己手上每天的工作全都是P1,這表示你每天都在救火(我就看過這樣的MIS部門和專案公司,我可以肯定的告訴你,你絕對在這家公司待不久,搞不好這家公司或這個部門自己也撐不了多久,碰到這種公司,我會建議你趕快準備104…),如果手上的工作大部分都是P1,不用懷疑,你(或你們)的時間管理絕對有問題。

P1類型的工作,我認為在正常的公司當中一週不應該超過一、兩件,每件應該也都要能夠在三小時內解決。(否則他就不是P1,而是P3轉換成的P1,我待會解釋)

先談P4,你可能以為一般人應該不會把時間花在P4這類不重要又不急迫的事情上,但是你錯了,其實往往在工作上不是這樣,P4類型的時間花費多半都有一個特質,就是有趣、但沒意義

你一定會發現身邊很多人在工作時一直邊打MSN、跟同事作無建設性的閒聊,陪客戶聊天(好像很重要,但是其實並不是只陪客戶聊天就可以爭取到訂單)、或是作些可有可無沒有建設性的外交,打一些沒意義的電話(純粹是因為不想要把VS2005打開進行專案的Debug,所以先找一些其他事情做做,你問他說為什麼不快點Debug,他會跟你說要…醞釀Debug的心情和氣氛),和同事分享小道消息…這是P4的典型的例子。

我要說,如果你花了大量的時間在P4類的事情上,則肯定會慢慢邁向失敗。和客戶溝通有兩種,有建設性的我不會放在P4, 但是無效的溝通和閒聊就變成P4了。

這邊有一個迷思,休閒活動(例如打電動)算不算P4? 如果打完電動之後,讓你得到壓力的紓解、心情變得更輕鬆、腦袋開始更靈活,那就不是P4,因為它有意義,但是如果你熬夜打電動,或是打的廢寢忘食,結果導致該交付的工作無法交付,那就是P4了。

我建議大伙想想,你一天的時間當中,有多少時間花費在P4項目上。如果說過多的P1是讓你感到心力交瘁、逐漸疲乏的關鍵,那P4類型的時間花費絕對是讓人生邁向失敗的指標。

接著,我們來看一個重點,P3,重要,但不急迫的事情。
很多時候,所謂重要的事情,往往不會花你太多的時間(例如你的weekly report,還有應該要在準時交出來的管理計劃,甚至個人的生涯規劃、UAT時間的安排、test script的撰寫…),很多重要的工作一開始絕對都不急迫,這也是我說P1工作其實不應該多的原因,但是請注意,如果你不把重要的事情P3放在前面先做,這些事情自動就會慢慢的變成P1,然後你會發現自己每天的工作都在救火,都在趕進度,都被大家追債,常常會有人質疑你的工作能力和效率,這些都是P3沒有先做的後果。不要懷疑,在資訊界中,我看過其實很多人是這樣的(包括我自己偶而也都會這樣)。

請謹記,重要的信件先回,重要的工作先做,多留一點時間給重要的工作。重要的工作特別是包含了一些計劃、規畫、預防性的工作,很多主管也往往都略過這些工作,而等事情發生了(變成P1,例如專案Delay、客戶抱怨、老闆抓狂…)才跳進去動手處哩,你有沒有發現,這些工作一開始往往都不急迫,但是是很重要(這就是典型的P3),如果你不先做,它們自己就會慢慢自動升級成P1,會有人(上級單位、或是客戶、或是你自己)逼著你立刻要完成,但是往往到了P1的時候,會發現已經火燒眉頭,而且沒有時間提供一個好品質的成果,你會覺得能趕出來已經很不容易了,但是到這時也已經同時給了別人不好的感覺,由於時間有限,所以只好趕出來,但是你也知道,趕出來的品質大概只有60分上下,交付了,卻讓人不滿意,接著大家會開始對你(或你的公司)的工作品質打問號。

然而,其實這些工作一開始都是P3,也就是它們本來都不急,你也有時間可以慢慢作,卻因為放太久,使得它變成P1…導致這種結果。

順帶談一個觀念,個人的健康檢查和保險,是典型的P3,如果你放著不做,有一天發現生病了,非得去住院就變成P1,關於這點,我最近感觸很多,提醒大家注意自己的身體。

所以請記得,重要的事情先做

我們會放著P3不做,往往是因為我們不喜歡這些工作(很像學生的暑假作業,總是到最後一天才寫),還有一個可能的原因是我們不知道該怎麼作,當對工作有疑惑不知道該怎麼作的時候,請主動尋求解答(尋求解答這件事其實也是P3-雖然不急但是卻很重要),很多人都怕跟老闆溝通,可能是怕讓老闆知道自己原來不會這些,或是不能理解老闆的心意,或是怕節外生枝,所以都放在心裡不講,不與老闆溝通的結果是只能揣摩上意,導致工作失準或是只能擱著,放到不能再放的時候才和老闆溝通,往往這時候已經太晚了…

Anyway, 如果你真的開始注意自己每一天的工作習慣,然後把這個觀念用在每一件工作上,分析你的每一個工作到底是P1-P4中的哪一種,並且去改變他,突破這個循環,你一定會發現這個觀念可以有效的提高你的工作效率和成果…

希望對你有幫助。

2008年7月22日 星期二

Silverlight 廣告

不知道大家有沒有看過這個...在網路上找到這個廣告...
嗯...我猜這應該算是廣告吧...好像有點無厘頭...不過算是挺有趣的...
呵呵,它的精神是...有了Silverlight之後, 一切都變得更簡單了...

2008年7月19日 星期六

關於如何選擇VB和C#

有一位讀者在幾周前來信詢問到這個問題,我答應他要在BLOG上好好討論這個部分。

我相信很多初學者最近特別碰到這個問題,面對在.NET上要採用哪一種開發語言而困擾。在回答這個問題之前,有一個前提是要先確定的,關於效能的問題在這兩個語言之間的選擇是幾乎不存在的,特別是由於硬體設備的關係,因此效能問題很容易補強,若要說效能,到目前為止中高階語言當中C++依舊是效能最好的,Assembly依舊是效能冠軍,但是你會不會用這兩種語言來開發資料庫應用程式,答案是你絕對不會,因為這樣太辛苦了,好,我們的討論就從這一個point開始。

正如同你不會用C++來開發資料庫應用程式一般,除非沒得選擇(某些平台上只能選擇C++),否則有太多更適合用來開發資料庫的語言,C#, VB, Java, delphi...幹嘛選C++?

但是有沒有人會說C++語言不好?不會的...因為大家心裡都明白,不是好不好的問題,而是適不適合的問題!!!
那問題來了,如果答案這麼明確,為何還會有人討論C#和VB到底要選哪一個呢?不是就是適合不適合的問題嗎? 對,但是有一個小麻煩,是C#和VB都是.NET的官方語言,而兩種語言能做的事情幾乎一樣,花的工也差不多,那就讓人困擾了,到底要VB和是C#?

好,探索這個問題之前,我們要明白語言的背景和特色,C#是C Like語言,從C, C++之後,出現了很多C Like語言,C#和Java都是其中之一,他本質上是C的語法,但是沒有C++那麼難,C++當中有很多古時候C語言保留下來的特殊語法,這些語法相當簡約,例如A++,這代表A=A+1,除了A++之外,還有++A這種語法(難倒你了吧,很多人不知道兩者之間的差異...)。C語言又加上物件導向的觀念之後,難度瞬間提升幾十倍吧,很多專家腦袋裡想出來的許多天馬行空的可能,都在 C++上實現了,像是多重繼承這類的觀念,導致原本已經很簡約的C語法,變的進入障礙更高。

PS.你知道C語言為何要那麼簡約嗎? 因為在C發展的那個年代,很多時候無法用鍵盤直接輸入程式執行的,是透過讀卡機把程式輸入電腦裡,而字寫得越多,讀卡紙片就越厚,所以大家盡量把語法搞得越簡單越好...

而Java的出現,簡化了C/C++複雜的語法和架構,有那麼一點去蕪存菁的意味,更貼近商用(注意,是商用)領域,加上那一年internet盛行,所以謂為潮流,Java一直改變,MS卻只有VB和C/C++的開發環境,當年還沒有所謂的Visual Studio,就只有簡簡單單的VB 5,不過話說回來,那時候VB已經有一點點OO的觀念,加上還支援控件等reuse技術,支援事件驅動,支援視覺開發,已經是了不起的成就,那幾年的VB Programmer爆增,全美數幾百萬人跑不掉,幾乎有一半的商用程式是用VB開發的,但是VB卻有著過去的包袱...

說包袱可能不公平,因為VB本來就是設計給初學者用的,進入障礙低,簡單好用,可以快速的開發出一套應用程式,因為這樣,所以VB的語法很簡單,舉例來說,用VB開檔,可能就是簡簡單單的一行程式:
Open "filename" for Output as #1 <-- span="">
任誰都知道上面那行程式是用來開檔的,而且檔案還是用來輸出
如果是C,我記得是...
FILE *f;
f=fopen("xxxx","w+");
不是我在講,當年光那個*f的指標,就搞得我七暈八素,總是忘了加上*導致成是錯誤。你沒有辦法從人類的邏輯搞懂為何開檔的回傳值是一個指標,而運算式的回傳值卻是一個變數,這純粹是為了配合Compile而設計的語法,這不是為人類設計的。

那個年代後期微軟推出了 Visual Studio 97,其中上得了檯面的開發工具包含了Visual Basic 5.0、Visual C++ 5.0及Visual FoxPro,著時謂為風尚了好一陣子。當年同時間還有一個Delphi也很風光, 走的是Pascal路線,我還認真的學過一兩年,Delphi把Pascal發揚光大,但畢竟不是MS這種大公司的敵手,風光了一陣子之後,慢慢就開始有走下坡的趨勢。

而Java則慢慢開始一飛衝天,這時候讓MS陣營很多人發現了Java的好處,比C/C++簡單,能力強,可以跨平台,學習曲線有沒那麼高,豐富的類別函式庫...說不完的優點和前衛的設計,讓MS陣營的開發人員心動,java紅了好一陣子...

MS面對internet痛定思痛,決定來個絕地大反攻,在2002年推出內建.Net Framework 1.0的Visual Studio .NET,這是一個釜底抽薪的改變,一舉把MS開發工具帶向了整合interner、OO以及新的開發框架上,這個改變很重要,但是卻...帶來一場災難。

很多VB開發人員水土不服,改變太大了,ASP開發人員也不買單,ASP.NET被接受的程度不高,產品有一些待解決的問題,這些造成MS很大的壓力,那一年的改變是一個關鍵,他帶領MS的開發人員走向新的世界。那一年,也才是C#剛推出的時候...很多人還在觀望...

到2003年,微軟推出支援.Net Framework 1.1的Visual Studio .NET 2003,狀況才開始慢慢好轉,C#開始被大家接受,VB當中一些死硬派還停留在VB 6.0,也有一部份慢慢移轉到VB.NET上(主要的問題是VB 6.0的程式碼和觀念,幾乎和VB.NET不同)。

而2005年推出.NET Framework 2.0以及Visual Studio 2005(有沒有注意到MS把.NET兩個字拿掉了),則開始奠定如今的基礎,ASP.NET開始大紅(在台灣比較紅),ASP開發人員無可避免的選擇了升級到ASP.NET上,與Java分庭抗禮的時代開始出現,C#開始爭取到不少C/C++/Java/Delphi開發人員,而部分VB 6.0的developer也發現勢不可檔,所以跳入 VB.NET(後來就不叫VB.NET了)的懷抱中。

好,故事是這樣的,真的好長...打字都累了...
那,到底你要選C#還至VB?

這關乎你的目的,從上面的背景你可以發現,VB有悠久的歷史,但式設計VB的專家也一直盡力維護一個分寸,就是VB要符合底下幾個原則:
1.容易上手、學習曲線低。
2.與舊版VB語法大致相容。(現在越來越難了)
3.可以輕易的開發出一套程式。

所以你會發現,依照上面這樣的邏輯,VB具有C#沒有的My Class,這不奇怪,因為My Class很沒道理,不符合OO架構也濫用了靜態型別,有可能導致一些程式設計上的風險。VB的語法似乎比較鬆散,變數的型別轉換比較不嚴謹,但是這些聽起來是缺點,其實換另一個角度想也是優點。

如果我要很快的開發出一套程式,我不是程式設計師背景,不是所謂的科班出身,我也沒打算寫架構很大或很偉大的系統,我可能是數學系的、電機系的、念財務管理的、念工程的...我用VB寫一個小程式是非常非常理想的。沒道理要我用C#,變數的型別對我來說幾乎沒意義,只要程式能跑,算出我要算的東西,或是記錄我要記錄的資料,以後可以查詢,就好了,寫程式幹嘛那麼龜毛?

但,如果你是業界的程式開發人員,這是你吃飯的工具,你倚賴這個謀生,你寫的程式必須可長可久,比較有架構和嚴謹的C#會是比較好的選擇,(不過我要在這邊補一句,在台灣這種需求真的不多,因為沒什麼系統可以活過3年,reuse這個夢坦白說也很難實現,架構很漂亮,但是每次程式幾乎還是重寫,這樣架構再漂亮也沒用,這不是程式設計師的問題,也不是語言的問題,這些問題出在人身上...以後有機會再談),因為設計出的程式比較安全,發生exception的機會比較低,程式比較有架構未來交接維護也方便。(重點在交接,因為developer流動率真的很高)

如果你是MIS,沒有需要開發很大的系統,程式只是你的 "工具" (例如寫個程式進行佈署、建立AD Account,撈資料做報表,算出老闆要的資訊...等),我覺得用VB是比較好的選擇,因為老闆幾乎都要求快,希望很快看到結果,沒人管你架構,不需要為了簡單的一個小程式畫UML、一個下午或是一兩週就可以完成的小程式,靈活和快速是最重要的。

如果你是賣方(軟體廠商、SI、會把你寫的程式當作產品賣出去的),你可能就需要考慮以C#來開發,因為程式設計師的流動率很高、程式的效能要計較(因為客戶會計較)、未來的維護要持久...因為種種原因,讓程式設計師辛苦一點也沒啥不好,所以C#是一個比較好的選擇。

所以如何選? 我認為看需要...
要學哪個? 我覺得都要會一點...

我常跟學員說,在這個時代,我認為你必須要具備雙語(或多語)能力,一法通萬法通,所以VB和C#是開發人員的左右手,沒什麼道理只學其中一種,標準是,你不需要全部會,但是你至少需要看得懂別人寫的Code,如果你習慣用其中一種語言(例如我習慣VB),我覺得那沒什麼關係,每個人都會有自己的習慣,但是若你害怕用任何一種語言或是denial任何一種語言,那就不可以了,你必須對C#和VB都無所懼怕,依照你當時的需要選擇你要開發的語言。

VB當中的新語法(四) - Lambda

這個世界上很多東西是沒有道理的...不知道你是不是也會這樣覺得。

老實說,過去寫程式寫慣了的人,一開始看到Lambda運算式會覺得怪怪的,我先講它的意義,官方說法是,Lambda運算式可以簡化程式碼的寫法、增加可讀性(老實說我覺得簡化程式碼的寫法這件事情很少跟增加可讀性可以一起發生,通常程式碼越簡化,可讀性就越差...),對Lambda運算式來說,簡化程式碼寫法可能是做到了,增加可讀性我就很猶豫了,不過如果真要說起來,Lambda運算式的出現(或是為什麼在這個版本出現)其實說穿了還是跟LINQ有關...

先寫一個簡單的Lambda:
Function(para1 As Integer) para1 + 1

MSDN上說,Lambda運算式是沒有名稱的函式,所以上面名稱不見了,return也不見了,其實你可以想成:
Function 函式名稱(para1 As Integer) Return para1 + 1
上面這樣的簡寫,只是把函式名稱和teturn拿掉,這樣就比較容易懂了。

例如,原本應該寫成
  '計算身高體重的BMI值
  Function BMI(height As Single,weight As Single)
    Return weight / ((height / 100) ^ 2)
  End Function
就變成(拉成一行)
  Function(height As Single, weight As Single) weight / ((height / 100) ^ 2)

對照著寫就比較容易理解了,函式名稱不見了, 自然End Function也不見了,Return也不見了,差不多這樣,就是Lambda運算式了。
注意:另外一個很重要的是,函式寫在程式碼區塊外面,Lambda運算式則混雜在一般的程式碼裡面。(往下看,就會知道意思)

好,定義出來的Lambda運算式怎麼用呢?
最簡單的方式是在Lambda運算式的外面加上( ), 變成(Lambda運算式)然後再把參數給進去,所以就變成:
(Lambda運算式)(Lambda運算式需要的參數值)
例如:
  Dim ret As Single
  ret = (Function(height As Single, weight As Single) weight / ((height / 100) ^ 2))(170, 60)
  意義是→接收值=(Lambda運算式)(Lambda運算式需要的參數值)

差不多就是這樣,但是,這樣很難用對不對....對!!!

所以,大多數人就寫成這樣:
  Dim BMI = (Function(height As Single, weight As Single) weight / ((height / 100) ^ 2))
  Dim ret As Single
  ret = BMI(170, 60)


其中的BMI我們稱為委派變數,BMI是一個變數,但是在記憶體中是一個函式的位置,所以我們可以呼叫他(傳入170, 60)計算出一個BMI值,再用ret這個Single變數去接收,完成,就是這樣。

不過問題開始浮現,如果要這樣搞,那為何不乾脆一開始就直接建立一個BMI函示就算了?幹嘛用Lambda建立了一個沒有名稱的函示,又要用另一個變數去委派呢???

這還是有原因的,原因也還是跟LINQ有關,我們看一段點底下的程式碼:

  Function test()
    Dim a() As Integer = {1, 2, 3, 4, 5, 6, 7, 8, 9}
    Dim b = From item In a Where item > 3
    Return False
  End Function

其中的變數b的來源值是一段LINQ語法,這段語法會被Compile成:
Public Shared Function test() As Object
  Dim a As Integer() = New Integer() { 1, 2, 3, 4, 5, 6, 7, 8, 9 }
  Dim b As IEnumerable(Of Integer) = Enumerable.Where(Of Integer)(a, New Func(Of Integer, Boolean)(Nothing, DirectCast(Module1._Lambda$__1, IntPtr)))
  Return False
End Function

你會注意到,其中就有呼叫到一段Compile幫你自動產生的Lambda運算式。你會發現,Lambda有大半在這個版本的.NET中會出現的原因跟LINQ有著密不可分的關係。所以你會慢慢了解,為何從很多文件和名家的BLOG當中都這麼說,從.NET 2.0之後,其實本質上.NET Framework已經沒有太大的改變,而其他的部分.NET 3.0中的WPF, WWF...等,是額外加上去的,疊在原本的架構之上,同樣的.NET 3.5當中所提供的LINQ機制,也就是NameSpace位於System.Linq底下的,則是在.NET 3.5當中疊在3.0之上的一塊,骨子裡都一樣,所以為了實現LINQ這樣而外加上去的特殊語法,所以增加了Lambda,讓你開發的時候可以很輕鬆的撰寫 From item In a Where item > 3 這樣的語法,再由IDE與Compile通力合作,把要完成的功能隱藏在這段所謂的LINQ語法後面,再透過Lambda和其他的技巧實現,完成現在你看到的偉大工作。

2008年7月12日 星期六

最後的演講(The Last Lecture)

最近買了一本書,最後的演講(The Last Lecture),老實說,最近發生的事情讓我對人生的不可測開始有著另一層看法,有時候營營汲汲,所換來的回頭看看實在也不知道到底值得不值得,不過說真的,事情發生了,才會有這個想法,有些事情不是臨到頭了,恐怕一輩子也沒那個感覺。

回頭說這本書,書附贈了一片DVD,其實已經很多人在網路提起這個故事,我想說的是,當你看這個影片的時候,主講者在台上侃侃而談自己的故事時,你不知道的是,其實他有數次感到身體相當不舒服,幾乎要倒下,但還是硬撐完了全程,所以你看到的,是一個看似正常人一般的演說者,而不是一個生病的人。

讓我想到我小時候的英文老師,外表看起來很像一個糟老頭(年紀很大、臉上有點像是沒剃乾淨的白色的鬍鬚),他第一次走進教室我還以為是工友走錯了,但是沒想到他就是我們的英文老師,進門第一句話就是道道地地的帶有英國腔的英文(如果我沒記錯他是留學英國的),說真的,事隔多年,我對他沒什麼印象了,只記得他不只一次的說如果他可以選擇,他希望要死在講台上(因為他覺得自己教書很多年了,老囉~),他說他當了一輩子的老師,再也沒什麼比死在講台上(例如突然間心臟病發作)更圓滿的了...

自己有幸當講師之後,開始覺得也許站在講台上真的是需要一點對演說、教育由衷的喜好和興趣的,特別是和學員之間的互動,往往是吸引講者能夠一直努力下去的動力,我喜歡帶稍微小班一點(就是我有機會可以跟每一位學員說話的那種編制)的學員,很慶幸絕大部分的資訊課程都是這個編制,在這個過程中,其實是很愉快的,如果同時又真的能夠給學員一些幫助,那我覺得就更加的完美了。

每一個工作都能夠對社會有一些幫助,不過很少像教育工作那麼立即和明顯,我相信有一天回頭看,應該會讓自己感到安慰。人生並不長,時間有限,在埋首程式堆裡面的生活當中,偶而能夠和其它的開發人員有一些互動,又能不時幫助人,其實是蠻令人欣慰的。

BTW,這本書和影片可以買來看看,挺讓人深省的。我們有太多的書籍告訴我們怎麼寫程式、怎麼賺大錢、不過關於怎麼過日子的書籍,恐怕相對的少了很多,有時候放在書店的架上也不是非常顯目,不過,留一點時間給自己,看看這類的書籍,對自己好一點,因為有時候人生,並不全然會照著我們自己所編寫的劇本上映。



VB當中的新語法(三) - 擴充方法

在VB的幾個新語法當中,擴充方法也是很有趣的功能之一,某種角度來說,它讓我在上課時幾乎已經要丟一在一邊的Module關鍵字又重新開啟了另一個重生的機會。

簡單的說,擴充方法就是以額外的程式碼替原有的Class(不管你有沒有這個Class的原始程式碼,不管是原本系統的Class或是你自己寫的)增加新的Method。

作法是開啟一個新的Module檔案,並在當中建立一個Method,例如:
Module IntergerExtensions
  <System.Runtime.CompilerServices.Extension()>Public Sub Show(ByVal para As Integer)
    MsgBox(para)
  End Sub
End Module


請注意,一定要宣告在Module當中,並且加上<System.Runtime.CompilerServices.Extension()>特徵關鍵字 。由於這個函式的參數是Integer,如此一來,就會自動幫原有的Integer類別增加了一個Show方法,因此你在撰寫主程式的時候,會發現只要用到integer的變數,打個點,就可以自動帶出Show方法:


當然,並不是Integer就真的有這個新的Method,更不是繼承的觀念,純粹只是Compiler和IDE進行某種程度的 "混淆視聽" 之後的結果。IDE負責讓你在開發的時候有intellisense可以用,Compiler則負責去解讀這種特殊的語法轉換成一般呼叫函式的程式碼。

使用的方法就是那麼簡單,即可讓原有的Class增加新的功能,別忘了,使用前要在主程式中Import這個Module。例如:
Imports WindowsApplication1.IntergerExtensions
(由於我的程式的root Namespace是WindowsApplication1,而Module Name是IntergerExtensions,因此我會這樣寫)

說真的,這個功能我覺得放在Module當中還蠻有點道理的,因為擴充方法其實是Public Shared 型別,且實務上我們可以把一些常用的Method(Sub或Fucntion)集中在一個或數個Module當中,賦予適當的Module Name做為區分,這樣在撰寫程式的時候不需要回頭找這些Method放在哪一個NameSpace底下,然後再去呼叫它,反而可以像上圖一樣,用到Integer的時候就直接呼叫我們幫Integer撰寫的擴充方法,因為它根本已經變成(長的像而已,不是真的是)特定型別物件(例如上面例子中的Integer)的方法,所以想用的時候 "隨手" 就可以用,撰寫程式碼時,只需要在該型別的物件旁打個點,就會自動帶出符合該型別的物件可用的Method,相當好用。

如果你熟悉泛型的觀念,可以繼續往下看,底下這段程式碼很有趣:
   Public Sub Show(Of T)(ByVal para As T)
    MsgBox(para)
  End Sub

我們把原本的Integer換成了泛型寫法,透過這樣的方式,我們在使用擴充方法的時候也更加的方便了:
  Dim a As Integer = 60
  a.Show()

  Dim b As String = "test"
  b.Show()


總的來說,擴充方法的出現,讓程式設計的自由度與靈活度又提高了。

2008年7月6日 星期日

從Silverlight 2.0的新功能,遙想Web的未來


  Silverlight 2.0比起1.0令人驚艷不少,在1.0當中幾個過去被談到缺少的機制,在2.0大幅度補齊,其中與開發資料庫應用程式有關的,莫過於Data Binding技術以及IsolatedStorage機制。

  透過Silverlight 2.0當中的Data binding技術以及IsolatedStorage機制,我們可以很輕鬆的建立出類似左邊這樣的用戶端資料處理介面(按這裡試用看看),不僅程式碼相當簡單(不到百行吧),而且在UI上更勝ASP.NET與傳統的WinForm程式一籌。

  除此之外,程式碼的撰寫以及維護和除錯,都比ASP.NET要容易不少,過去很多台灣和大陸地區的開發人員對於在Silverlight 1.0當中的中文字顯示和輸入問題的疑惑,相信在看到這個2.0的範例後這些疑慮你可以一掃而空。
  透過IsolatedStorage機制,讓開發人員可以大方的把需要保存的資料存放在用戶端,不需要在意它的存放位置。若您不喜歡這樣的方式,你也可以透過WCF從伺服器端將需要的數據下載,暫存在用戶端的記憶體或是HD當中,透過程式碼來操作。
  除了UI絢麗性與親和度大幅超過ASP.NET之外,我個人比較喜歡的原因是靈活性和自由度,有點讓我回想起從前開發WinForm的隨心所欲的日子.....
  說真的,HTML給ASP.NET Developer的限制,以及為了模擬WinForm或是提高Web開發環境中的UI的效能而硬生生所加入的AJAX技術,已經讓原本應該要 "簡單輕巧" 的Web應用程式變的龐大而複雜不已,面對這樣的問題,有兩派不同的路線正在彼此較勁。

  如果你觀察ASP.NET這幾年來的演變以及ASP.NET 3.5 extensions的出現,你會發現這一派儼然已經透過種種疊床架屋的技巧,把原本簡單的ASP.NET演變成可以開發大型應用程式的技術平台。本來ASP.NET在2.0前的訴求就真的比較適用於開發小巧的網頁或是輕量級的企業入口網站或是portal應用(OK,也因為這樣很多case被JSP搶去了),但是現在在3.5 extensions當中加上了LinqToSQL(以及ADO.NET Entity framework),加上了Data Services、加上了Dynamic Control、加上了MVC,一切就會不一樣了...

  這一派的人讓 ASP.NET搖身一變成為具有高延展性和彈性的開發架構,你可以設計出給兩萬個User使用的Web Application、你可以透過Dynamic Control或是MVC將敏捷開發以及多層式架構的開發觀念帶入微軟的Web開發領域、你可以透過這些機制、認真的、放心的建構大型(真的是大型的,不是那種同時使用的User只有幾十個人的)應用程式。到了這一步,ASP.NET才真的可以抬頭挺胸的登堂入室。

  另一派,則根本放棄了HTML這個煩人的架構,釜底抽薪了換成了WPF for Web或是Silverlight,這一派的人認為,Web上的RIA才是未來理想的Web應用程式解決方案,其他的只是緣木求魚。

  這派的人認為,因為我們已經跟ASP.NET奮戰了很久,從一開始HTML就不是讓人寫程式用的(那幹嘛用的?其實很多人忘了,HTML是文件的格式,本來就不是用來呈現UI的介面),從CGI、ASP、一路到ASP.NET,現在你開發一個WebForm應用程式,少不了要接觸幾種幾乎不同的技術,ASP.NET、AJAX、HTML(與CSS),這還只是展現層的部分,如果你需要開發出比較有 "層次感" 的應用程式,那VB或C#的OO觀念恐怕是必修的課程,除此之外,你可能會硬生生的把SQL崁入完全無關的ASP.NET Code behind程式碼中,然而這對於過去習慣開發n-tier架構甚至client-server架構的程式設計師來說,根本是近乎荒謬的程式寫法。

  但是...天知道有多少ASP.NET開發人員是這樣幹的,是,我承認,包含我在內的幾乎每一本坊間書籍都是這樣寫的,原因很簡單,這與過去ASP時代的背景有關,在過去我們希望透過簡單的script來解決問題,而到今天我依舊認為,ASP.NET非常適合用來開發輕量級的Web Application,讓開發人員相當容易的就上手,反而JSP則包袱太多,要寫一個像樣的應用程式,少不了要在架構上下足功夫,相對的初期產能就低(高產能要在過了一定程度陡峭的曲線之後才慢慢出現)。但是優點也是缺點,對於開發高延展性需求的web應用程式,可能ASP.NET在3.5 之前都是不及格的。

  當年發展ASP的團隊,恐怕打從心底沒想過ASP會搞得那麼的偉大吧,拜internet之賜,WebForm某種程度的變成主流。但是要當主流不容易,UI要夠精緻,AJAX技術非上手不可,偶而為了讓網頁有畫龍點睛的神來之筆,還得崁入一個Flash(現在我們就用Silverlight),大哉Web開發技術!#%@!$!#%*!*$&

  也因此,從這一派的角度來說,把HTML根本性的拋棄可能是釜底抽薪的好方法,在WPF for Web或是Silverlight上重新開始一個嶄新世界,恐怕會更令人期待。

  這兩條路線,我們現在看到是同時並行的,最主要的原因是,市場不會一夕之間改變,而微軟有的是能量同時經營這兩條路線,在某些專案當中,兩種技術並用也是一個很好的選擇,而未來呢? 很多人都有自己的想法,我也有,只是畢竟我是凡人,不是那種會一眼看到未來的能人異士,連明天會發生什麼事情我都不知道,也無法控制,未來,在我的腦袋裡恐怕有的也只有一些些無關緊要的推測了...

2008年7月5日 星期六

Silverlight 2.0 中的 UserControl 開發與使用方式

先前介紹過的Silverlight 2.0 中的 UserControl 開發與使用方式的教學影片已經上檔了,請參考底下網址,而詳細的內容說明在本期的RunPC當中介紹。http://www.microsoft.com/taiwan/msdn/elearning/Teaching/Silverlight/video10/


關於Microsoft .NET Framework 3.5 Service pack 1 Beta與ASP.NET 3.5 Extensions

Ok, bate 1 出現了,那距離正式推出又邁進了一大步。

Microsoft .NET Framework 3.5 Service pack 1 Beta當中有什麼呢?對於 ASP.NET開發人員來說,其中包含了一些相當重要的部分:
ASP.NET Dynamic Data
ASP.NET AJAX 增強功能
ASP.NET AJAX script combining
ADO.NET Data Services

The ADO.NET Data Services Framework
上面這些玩意兒根本就是從ASP.NET 3.5 Extensions搬過來的,正如同我們過去說的,目前MS的改版越來越快,ASP.NET 3.5這個版次其實有點吊詭,儘管跟著NET Framework把版本編號帶到了3.5,但是在新功能上卻沒有太大改變,而真正石破天驚的則是ASP.NET 3.5 Extensions, 如果依照目前我們所看到的態勢,ASP.NET 3.5 Extensions中的上述幾個功能,將會出現在.NET 3.5 Service pack 1 當中。

在三月的時候,我曾在微軟的研討會當中跟各位介紹ASP.NET 3.5 Extensions,接下來我會在 BLOG上花更多的篇幅討論關於ASP.NET 3.5 Extensions(也就是.NET Framework 3.5 Service pack 1 )的部分,ASP.NET更多的新功能看來正要開始出現。