發表文章

[研討會] 你不認識的.NET系列講座 - ASP.NET 4.5升級面面觀 (高雄、台北場)

2014/4/3在高雄、4/7在台北的 『 你不認識的.NET系列講座 - ASP.NET 4.5升級面面觀 』順利完成,今天分享的主題包含: Enterprise Liibrary 6 Visual Studio 與 Nuget的使用, Private Nuget的建立 Visual Studio Project Template 的使用 ... EL 6.0部分的內容您也可以參考 這邊 。影片的部份將會在MSDN or Channel 9公布。

[研討會]MVP Open Day 微軟技術關卡破解日

圖片
  每一場Session,都應該有自己的主題曲。   今年的 MVP Open Day 我第一次分享關於開發人員生涯規畫的主題,這也是從事資訊工作這近25年來,第一次比較完整的整理我在資訊專案或是相關工作中,擔任不同角色時的心情。同時也總結了我對於開發人員相關工作的感想。   其中很多內容,是不太可能在網路上看會後投影片就可以感受到的,我相信今天陪著我在現場的朋友,肯定可以理解我想表達的意思。   也因此,除了謝謝大家今天的參與,我先把底下的連結和影片分享給今天陪我度過一小時的朋友們,謝謝大家共同的投入,讓今天的這場Session圓滿的令人開心...   ref: 你為了什麼寫Code呢??? ref: 重要的事情先做 ref: 專業主義的秘密 - 練習 ref: 關於 如何快速增進程式功力... ref: 持續地改變是必然的趨勢...     ref: 對我的人生有重大影響的幾本書 ref: 力挺你的夢想 ref: 再看New Mondeo的CF與軟體開發人員         (沒有來現場的朋友,可能不明白我這篇分享的意思,不要緊,下次,希望在會場見到你) 2014/4/14 udpate... 現場復刻版video

發生問題 unable to start debugging. the silverlight developer runtime is not installed

圖片
由於我想台灣寫Silverlight的人口已經不多了,所以這則訊息我還是PO一下吧。 如果你原先使用VS2012但同時安裝了VS2013可能會碰到底下狀況:     但是你參考146060會發現他要你下載安裝Silverlight Developer Runtime,但你明明已經裝了,所以裝不起來。這時,請您到控制台移除Microsoft Silverlight(其他的別移): 接著,到底下網址: http://www.microsoft.com/en-us/download/details.aspx?id=40633 下載安裝 20913.00\Silverlight_Developer_x64.exe 版本(應該沒有人用x86了吧) VS2012和VS2013都可以正常運行了。

在Windows Phone (WP8) 中使用SignalR

圖片
ASP.NET SignalR【幾乎】讓我想丟掉Push Notification,你就知道它把訊息傳遞這件事情弄得有多簡單方便了。在這一篇我說明一下如何在WP8中使用ASP.NET SignalR,同時也稍微解釋一下 這兩天 寫的Code。 請回憶一下我們昨天的情境: 我們在伺服器端透過ASP.NET以SignalR寫了一組服務,主要是用來做聊天室(基本上是範例啦)的功能,包含了接收用戶端傳來的訊息(姓名、聊天文字),以及把訊息主動推送給用戶端(姓名、聊天文字),這樣的功能。 而用戶端就很單純的呼叫或傾聽這個服務。呼叫Send方法可以把用戶端使用者想要說的訊息傳給伺服器端,而伺服器端收到,則執行broadcastMessage這個動態方法,把訊息推送給所有傾聽的用戶端。 透過ASP.NET SignalR要寫這個服務端的機制,很簡單。 首先,建立一個Empty WebForm專案(當然你用MVC也行,之所以用WebForm,原因在 這裡 ),接著透過NuGet引用ASP.NET SignalR: 然後在專案中Add New Item,請找到Hub Class(VS2012 Update 4或VS2013): 建立出來的Class如下: public class MyHub1 : Hub { public void Hello() { Clients.All.hello(); } } 該類別繼承自Hub,這個Hub就是SignalR服務的Bass Class,你可以在其中建立自己的Method,如上圖中的Hello。 我們修改此類別,建立一個聊天室中,接收用戶端傳來訊息的Method,名稱為Send, 其程式碼如下: public class MyHub1 : Hub //SignalR主要部分 { public void Send(string name, string message) //接收傳送來的訊息 { //傳送訊息到用戶端 Clients.All.broadcastMes...

在WPF中使用SignalR

圖片
 假日,在等著接送家人的時間空檔,順便寫了一個最近工作上會用到的範例,不知是Windows Client端的技術用的人越來越少還是如何? WPF的使用情境似乎沒啥網友討論,所以範例寫完之後順便放上GitHub,如果有需要的朋友們可以參考。   大概的需求如下圖,基本上非常簡單,用WPF與WP8作為用戶端( WP8的範例 我晚一點寫),存取以asp.net SignalR所寫的服務,底下先寫WPF的部份:      會寫這個,主要的原因是,我們公司有不少先前已經搭建好的ASP.NET WebSite(Web Services),這些個WebSite是以WebForm的方式開發的,而用戶端不僅僅只有browser,還有不少WPF/Windows應用程式。所以雖然打算用SignalR做訊息傳遞,但又不是現在大家比較常見的ASP.NET MVC Site(不過說真的, 其實MVC或WebForm根本沒差)。再加上Client端(consumer)又不是Web,而是WPF(和WP8),所以稍微寫個簡單例子整理一下,好讓公司的開發人員可以接手去做後續的部分。   先把寫好的範例放在 這裡 ,有需要的朋友可以參考。   背後的需求很常見,過去我們有很多以WPF或是XAML(不管是Silverlight/WP8/Windows 8 App...etc)開發的Application,在沒有導入SignalR之前,如果需要知道伺服器端的狀態或訊息,要嘛就是走web services polling、要麼就是走socket,不然就是用push notification(但只有Windows Phone/Windows 8 App才能享用)。因此,傳統的Windows/WPF應用程式(不知道現在還有多少人在寫?),要透過http方式來接收伺服器端主動推送過來的訊息不是非常容易。(搞polling的效能當然是差到不行,又得自己做些手腳提高效能,挺費力)   但SingalR讓開發人員現在 不用大腦就 可以很輕鬆地解決這個問題。   所以我們打算在Windows/WPF/Silverlight應用程式當中快速地加入一些由伺服器端推送訊息到用戶端的功能,因此...

China TechED 2013 北京、上海,順利完成

圖片
早上,順利完成了 China TechED 在北京與上海的場次,本來昨天測試的HDMI投影整片花花的狀況幸好沒再發生。由於China場次只有60min,原先在台北講了近兩個多小時的架構設計,只能挑著重點講,很拚。 不過至少沒有發生嚴重超時的問題,感謝上海與北京的朋友們熱情捧場,在早上第一個場次的時段,依舊給予相當熱情的支持。 課堂中的案例檔案可由此處下載: http://arock.blob.core.windows.net/blogdata201312/Examples.zip 相關的範例與影片可以參考底下連結: http://studyhost.blogspot.com/search/label/Enterprise%20Library 後續我會陸續把每一個範例以及China場次的內容更完整的整理後,再在這邊跟大家分享。

專業主義的秘密 - 練習

圖片
先前和朋友聊到,最近同時間看一套日劇 Dinner 和 著名的 The Clean Coder  一書,被其中的專業主義感動到不行。 The Clean Coder  剛看完第六章,章名是我從來沒有跟大家分享過,卻是我奉行已久的關鍵字 - 練習。 我絲毫不想透漏Dinner的劇情,以及Robert C. Martin在The Clean Coder ㄧ書中提到關於練習的描述。這些東西(看Dinner這部片以及The Clean Coder這本書)將是屬於你這個月最頂級的享受,我不忍心剝奪它。但我忍不住要說,Dinner男主角在每天下班後忙到深夜的事情、和Robert C. Martin用了一整章說的故事,說到底,都只有簡簡單單卻始終被大家忽略的一個字,練習。 這年頭,很少程式設計師會進行"練習"了,而且是重複的練習。但你絕對沒有意識到,這件是有多麼的重要...老實說,如果不是因為要上課,我自己大概也沒有機會有這麼深的體會。但是,在這邊我要跟大家分享的,就是這近十年來,我擔任教育訓練人員、作者、或是顧問時,一直奉行不渝的 -- 練習。 練習什麽呢? Robert在書裏面有說,像是kata, wasa之類的(這你要看書才知道,說過了,我不想剝奪你的樂趣)。但我想跟大家說我自己的經驗,那就是『研討會前的練習』。 如果你熟悉我,你就會知道我講話的速度應該不算慢,在研討會上,我盡可能在兼顧清楚的情況下,以最快的速度跟大家分享,同時間,每一場次的研討會,我都要求自己,要盡可能地與學員互動。 我們也都知道,大夥兒希望看到Live Demo,也因此,我的每一場研討會,幾乎都會有Live Demo的部分,拿今年TechDay Taiwan 2013的例子來說,架構設計的場次中,我簡單Demo了應用程式的分層開發、Unity Application Block的例子、Logging Application Block的例子。在WP8的場次中,我介紹了動態磚、Lock Screen、NFC、App Communication,其中都不乏Live Coding。 一場研討會的時間是70分鐘,其實講師們都清楚的知道,只要Live Demo當中,有一個環節不正確或出現意外狀況,幾乎就有可能讓整個Session毀掉,你不可能讓台下的學...

如果人人都能寫程式???

圖片
今天早上看到這一篇文章: http://share.inside.com.tw/posts/2775 還有以前的一兩篇文章 http://mrjamie.cc/2013/10/17/programming-generation/ 讓我忍不住想講一些自己的觀察(感受),當然,從很久以前我就知道我其實是屬於少數人那一掛的,也就是說,當網友們極力反對或贊成某些事情時,我常常不知好歹的站在另一邊。最近我也常常FB一些其他人不太同意的論調...不過慶幸我生在一個還算和諧的時代,我不會因為這樣就被燒死...( 因此請大家也別太認真,我的論點絕對有可能是錯的,甚至很多時候,我也曾故意寫過一些些不是那麼精準和正確的內容... ) 早上看到的那篇文章,讓我直覺地想到,未來幾年我們很可能會開始活在一個人人都能寫Code的時代。說人人有點誇張,但比例勢必會大幅提升,原因很簡單,你有沒有發現,現在大家都在教別人寫程式??? 而且只要你願意,幾乎可以不用任何成本的學會寫一套程式(大概只需要花點錢買NB、和上網) 最近這十年,Coding這件事情有幾個重大的改變: 開發人員年齡層與進入門檻持續下降(年輕駭客、或是年輕億萬富翁比比皆是) 軟體開發資源突然間變多(拜internet普及、全球化資訊自由流通之賜) 通用軟體價值(實際售價)開始變低(這有個歷程,從30年前硬體收費軟體免費,變成20年前軟體很貴硬體便宜賣,到最近10年又有點變成軟體免費或隨著硬體銷售的趨勢) 軟體以服務的面貌收費 特別是第四點,很多人覺得似乎沒什麽,ASP或是SaaS都講了很久了,但這十年的改變異常之大,讓人措手不及。 以前獨立開發人員,可以在車庫裡面寫出一個mail收發軟體,然後放上BBS網路銷售,或是讓網友donate這個軟體。但這幾年這樣的模式還是有,但越來越限於特定族群、特定領域的應用程式。才不過五年前,大家搶著寫App賺錢,現在卻又說App不用IAP就賺不了錢!!! 終端消費者(End-User)開始視軟體為免費是理所當然的事情。 過去三十年來所建立的軟體有價的概念,隨著internet on line services普及而開始崩解,現在的終端消費者,越來越覺得軟體應該不能收錢,如果要跟我收錢,那最好你能提供像Google一樣的服務再說,否則程式設計師想收錢? 門...

MS Enterprise Library 6.0 (四) - Policy Injection Application Block

如果說 Unity Application Block 可以算得上是一份美味的佳餚,那 Policy Injection Application Block 絕對稱得上是開發人員最華麗的盛宴了。 要介紹Policy Injection Application Block之前,得提醒讀者,建議您先熟悉先前介紹過的 Exception Handling Application Block 以及 Logging Application Block ,因為我們待會要利用 Policy Injection Application Block 來作一個應用大集合。 首先,請你回憶一下Exception Handling Application Block,以及想像一下Exception Handling Application Block會怎麼用在你的系統中,以及怎麼幫助你以一個單一的例外處理模塊來管理你開發的系統的Exception... 不要偷懶,想像一下... ... ... ... ... ... 好,接著我們回到現實面,你會發現,我們前面說過,可以透過Exception Handling Application Block來管理例外,提供一個統一的方式來處理各種不同可能的例外...這樣很好,我們的系統透過這樣的設計,已經大幅的將耦合性降低,並且提高了重用性,這樣還有什麽讓人不滿意的地方呢? 有的,當程式碼愈趨鬆耦合時,我們開始看try...catch不太順眼。此話怎說??? 請看下面這塊典型的try...catcah: public void MethodA() { try { int a = 10, b = 0; a = a / b; } catch (Exception ex) { //以Config檔案中的 "Policy" ExceptionPolicy設定來處理 var rethrow = ExceptionPolicy.HandleException(ex, "Policy"); //如果設定檔說要重丟例外,就重丟 if (rethrow) throw; ...

MS Enterprise Library 6.0 (三) - Exception Handling Application Block

圖片
有時候心情好,忍不住就多寫幾篇Blog。(當然,心情比較差的時候,可能十天半個月沒辦法安安靜靜的把一些東西整理出來) 前面錄了兩段 Enterprise Library 的介紹影片,分別談了 Unity Application Block 和 Logging Application Block ,這一篇緊接著談Exception Handling Application Block。 由於時空的限制,我現在所在的位置沒法錄製影片,所以只好乖乖用寫的了。 如果可以讓我選擇,我喜歡錄影片遠超過寫文字,原因很簡單,因為我話多,blog有時候忍不住就多寫了幾百字,但這年頭大家都不看字的,害我覺得寫了很無聊。寫了沒人看不打緊,花的時間很多,年紀大了越來越懶,用講的比較快,還可以當作上課的彩排甚至教材,所以我喜歡錄影遠超過寫文章。 岔題了。 Exception Handling Application Block,顧名思義就是系統中處裡例外的模塊,大家都知道,我們會在程式碼中加上try...catch來處理例外,程式碼常常會像是這樣: try { int a = 10, b = 0; a = a / b; Console.WriteLine("done!"); Console.ReadKey(); } catch (Exception ex) { //如果發生例外...就... } 這樣的程式碼沒啥太大的問題(除了因為是範例所以一定會發生例外之外...)。 但如果像上面這樣的程式碼一多,我們就會發現,每一個try...catch裡面都是另一段不受管理的複雜的錯誤處裡邏輯,可能是寫log、可能是發mail、可能是retry...,不僅如此,一旦例外處理區塊寫死之後,例外處理區塊常常本身就是一個大累贅。 還有,發生例外的可能性和類型很多元,上面這段程式碼非常簡單,只可能得到一個 "除以零" 錯誤...