.NET Walker

在知道了如何建立LineBot的WebHook之後，許多朋友開始有了另一串問題。其中我最常被問到的就是，如何在用戶加入你的bot為好友的時候，取的用戶的身分xk7。 這個問題中有兩個關鍵: 用戶加入你的bot時，你如何得知? 如何取得特定用戶的身分資訊? 這兩個動作都不難，都可以在我們的WebHook中取得。 首先，當有一個新的用戶加入你的Bot為好友時，我們可以從WebHook取得的JSON得知，透過我們的SDK，你可以很簡單的以底下的程式碼判斷: if (ReceivedMessage.events.FirstOrDefault().type == "follow") { … } 因為新加入好友或是被解除封鎖，都會收到type是follow的event，因此上面的程式碼很容易判斷出有新的好友來了… 而得知新好友(用戶)來了之後，我們可以透果底下這一行取得用戶資訊: var userInfo = bot.GetUserInfo(ReceivedMessage.events.FirstOrDefault().source.userId); 得到userInfo物件之後，你可透過 displayName 輕鬆取得用戶暱稱，也因此，我們把用戶暱稱顯示出來: bot.ReplyMessage(ReceivedMessage.events.FirstOrDefault().replyToken, $"哈，'{userInfo.displayName}' 你來了...歡迎"); 得到的結果就是: 當用戶加入某個bot為好友，或是解除封鎖，都會收到follow，我們上面的程式碼抓到用戶名稱，顯示出來，結果就是上圖這樣。 很容易吧，試試看囉… hope enjoy it… 此範例原始程式碼位於 : https://github.com/isdaviddong/LineBotExample_GetUserInfo/blob/master/LineBotExample_GetUserInfo/Controllers/LineBotController.cs -------------------------------------------- 相關課程: http://www.studyhost.tw/NewCourses/L...

很久沒有聊聊asp.net了，但畢竟asp.net跟我緣分不淺，或許該找個時間來談談。不過，今天我們試試看換一種方式，也讓大家自我挑戰一下，題目來囉... 我們說asp.net是一個web開發框架(framework)， 現在的asp.net framework提供了三種不同的方式(途徑、架構、風格)來建立網站，分別是哪三種? 這三種分別有哪些特性(或優缺點)呢? 這三種可以混用嗎? 來公布答案。 首先，千萬別執著對錯，因為我這題目本身就很爛(題意不清)，其實我們應該把.net core和asp.net分開來看...這題談的不是asp.net core, 但題目沒說清楚，會讓人誤會。 因此，重點不是對錯，而是我們要藉著這題目來釐清整個asp.net的架構與觀念。 首先，題目與答案都在這邊: ASP.NET is great for building standards-based websites with HTML5, CSS3, and JavaScript. ASP.NET supports three approaches for making web sites. ASP.NET Web Forms uses controls and an event-model for component-based development. ASP.NET MVC values separation of concerns and enables easier test-driven development. ASP.NET Web Pages prefers a single page model that mixes code and HTML markup. You can mix and match these techniques within one application depending on your needs - it's all One ASP.NET. 上面這段話的來源是: https://www.asp.net/get-started/framework 所以，從這邊我們可以知道，先撇開.net core不談，asp.net framework (on windows)，主要approaches Web Sites的方法有三，分...

這功能一點都不特別，但很重要，而且我記得我是在用了很久Visual Studio的TFVC版控之後，某一天偶然發現的。 我不知道是否每個人都跟我一樣，我自己在寫程式的時候，習慣在程式碼Check-in之前，對比一下這次修改了哪些東西? 確認無誤之後再Check-in ，會養成這習慣，是因為這小小的動作救了我很多次。 有不只一次，當我這麼做時，留意到了一些原本沒注意到的細節，諸如…在Method裡面忘了檢查參數內容是否正確? 沒有判斷空值或null是否合理? IO處理可能發生exception的地方沒有掛上try…catch…等等，太多了，只要養成review自己的code的習慣，你會發現，常常能購找到可以改善之處。 這個動作會迫使我在簽入前重新看一次剛才自己寫的code，有點自己review自己程式碼的感覺。所以，現在每當我程式寫到一個段落之後，都會習慣的在要比較的那隻程式碼檔案上，點選一下滑鼠右鍵，選擇Compare…比較一下和上一個版本的差異… 但這樣可能會漏掉了某些改過的檔案沒注意到，因此，最好的習慣是在Check-in的那一刻，在該檔案上點選Compare with … 因為版控機制幫你列出了所有修改過的檔案，如此一來，你就不會錯過哪一個檔案。 一般來說，過去在簽入程式碼到伺服器端前，我肯定會一個一個逐一比對，看看和伺服器端的檔案有何差別。(確認改了哪些東西)。 但有時候，Visual Studio會把附屬性質的檔案(例如.aspx.cs, .aspx.designer.cs，當作已修改，但其實它並沒有被改到，真正改到的只有.aspx而已。這時候，一個一個比對很煩人。(浪費時間) 不知道從哪一天開始，我突發奇想，難道Visual Studio不能一次比對多個檔案，先幫我確認哪些檔案有改過，讓我只review有改過的檔案嗎? 有了這個想法，當場嘗試看看能不能用滑鼠Mark多選幾個要簽入的檔案，發現，居然可以耶… 但，卻不能比較(Compare選單disable了) 不死心，又突然想到，那如果選擇資料夾呢? 咦? 可以耶，快來試試看。 你會發現，點選Compare後，會出現底畫面: Visual Studio真的去幫我對比整理出了所有該資料夾下的檔案，僅列出有修改差異的部分，你還可以在該檔案上double-click，看到細部的差異比較: 這節...

接著，我們來看如何在TFS/VSTS中使用Git形式的版控。 同樣的，請先建立一個支援Git版控的Team Project，與TFVC版控的Team Project不同，建立好該專案之後首先納入眼簾的是底下的畫面: 你可以透過SSH連線的方式來連接，也可以點選上圖(2)的地方，產生連線所需的帳號密碼。 如果你用開發工具是Visual Studio，那你可以很大方的按下上圖(3)的位置，即可直接Clone該專案並且設定Mapping的用戶端資料夾位置，如果你用的開發工具並非Visual Studio，但也是知名的開發工具，則可點上圖(4)的下拉清單，看看是否也支援直接Clone: 從VS2017連接TFS/VSTS上的Git版控伺服器 當然，你也可以用類似我們開啟TFVC版控專案的方式，直接從Visual Studio當中建立連線，請注意一樣是選擇Connect to Project，在出現的畫面中找到要連結的專案與repository: 接著，成功的連上之後，在Team Explorer中一樣會出現讓我們選擇用戶端Mapping版控檔案的儲存位置，也就是你要把雲端的原始程式碼Clone到用戶端的哪個資料夾。 請選定資料夾後(下圖A)，按下Clone鈕即可: 如果伺服器端已經有其它開發人員先前push上去的程式碼，會被一起下載下來，但由於我們是建立一個新的專案，因此目前還沒有任何檔案被Clone下來。 我們可以點選下圖A的New，建立一個新專案: 你會發現預設的資料夾，應該也是先前我們Clone時設定的資料夾，你可以直接按下OK，建立該專案。完成後，切換到Solutions Explorer視窗後，會看到類似底下這樣的畫面，這時請留意，和TFVC版控有些許不同: 你會發現，在上圖A的位置，標示出了有12個檔案已變更（或新增），你可以點選該數字，會出現Commit程式碼的畫面。 將程式碼Commit並Push到伺服器端 你會發現，在下圖A的地方，和TFVC版控類似，也會讓你輸入此次Commit的Comment，而B的地方有三個選項，分別是Commit All, Commit All & Push, Commit All & Sync: 所謂的Commit，和TFVC的Check-in不同，Commit並...

我們先看採用TFVC的部分，請先建立一個以TFVC為版控的Team Project: 當你在VSTS/TFS中把專案建立好之後，首要工作就是從用戶端的Visual Studio連上伺服器，請開啟Visual Studio，找出Team Explorer視窗: 在Team Explorer視窗中，最上方(上圖1)的位置，有一個連線按鈕，點選後接著會出現Manage Connections選項，理論上會有兩個，一個是上圖2的『Connect to Project』，另一個是『Connect to Github』。 上面的Project指的就是VSTS/TFS的TFVC或Git Repository，而Connect to Github指的當然就是網路上那個Guthub。 請注意，不管你在team project建立時，選擇的是TFVC或Git版控，都是點選上圖2那個『Connect to Project』 接著會出現底下這樣的畫面，這是VS2017的UI，你會看到所有你的登入帳號可以連上的TFS Server或VSTS站台: 留意上圖，其中(1)的部分是你的連線帳號，由於該帳號可以連上我建立於區域網路的TFS以及internet上的VSTS，因此上圖(2)和(3)分別就是TFS伺服器以及VSTS站台，而展開的項目當然就是Team Project(上圖6)，而(4)和(5)所指的分別是位於VSTS站台上的Team Project裡面的Git版控的repository和TFVC repository。 新版VS2017的連線UI設計的很完整，一次把所有需要連線的對象全列了出來，你只需要點選後，按下Connect鈕即可。 Mapping工作區並下載檔案 當你連上了伺服器端之後，會看到類似下圖的畫面，由於範例是剛建立的Team Project，因此下圖中你會看到還沒有其他開發人員先前已經簽入(Check-in)的source code，只有一個預設的資料夾: 由於第一次連上，你必須先Mapping你的Workspace，你會發現上圖(2)的地方，可以設定你的用戶端工作區位置，一但設定，未來該位置就可與伺服器端做同步，設定後按下『Map & Get』，如果先前有其它開發人員已經簽入程式碼，也會被下載下來。 你也可以點選下圖(1)的地方，也可...

原始程式碼對於軟體公司來說是一種資產，Source Code被納入版控不足為奇(沒有才奇怪)，但我常常看到企業內的MIS/IT，認為自己開發的專案只是小型專案，或是開發人員只有『一個』，所以要控管什麼版本呢? 因為一切都在自己的腦袋裡啊。 不，千萬別這樣想。 在這個時代，任何專案，那怕從頭到尾都只是一個人開發的，都應該要簽入到版控系統當中。不管是任何一種專案，不管是因為任何目的原因所撰寫的，不管它能夠在企業中活多長，只要有需求，有程式碼，需要維護，就一律必須納入版控。 如果非要我在兩者中選擇其一，我會說，軟體專案成敗的關鍵常常不在開發，而在維護。在這個時代，幾乎沒有寫完程式碼後可以不用維護的專案，也沒有你可以大聲喊『Close!』結案之後就再也不管它的程式碼，幾乎所有的Projects都會持續衍生、修改Bugs、調整需求。如今想要很快的生出一個可以動的網站太容易了，但隨著需求的變更，對程式碼的修改常常才是軟體開發真正內涵的開始。況且廣義的說，專案還沒有交付前所作的任何需求變更或修改，也都得算是維護的一部分。 如果你敢在寫好程式碼編譯成.dll之後，立馬把source code丟掉，我就承認這世界上有不需要維護的專案，但我們從來不敢這麼做，對吧? 不管一個專案再混亂、或是你開發的是根本是拋棄式的應用程式(用一次就不會再用)，原始程式碼都至少還要留上一段時間，甚至永久保存下去。 而如今這些需要無限期永久保存的程式碼，慢慢的逐漸移動到了雲端環境上，我們到了一個版控雲端化的時代。當然，保存原始程式碼不是為了安全感，TFS/VSTS的版控可以幫助我們解決那些實質問題？ 版本控管的價值 有沒有發生過底下這些事情? 某位團隊中的程式設計師改了某一個bug，結果另一個原本好的功能卻壞掉了? 沒改過的地方怎麼會錯呢? 客戶突然告訴你，你剛才改好的某個功能他不要了，他要回到上上上個版本的那個狀態! 團隊成員結婚去度蜜月了，但不幸的是，他手上負責的某個案子，客戶發現了一個安全性的漏洞，嚴厲指責這估計是他結婚前一個月的某次修改時造成的，但...那段程式碼在哪呢? 你同時是三個軟體開發專案、兩個維護案的程式碼設計師，面對客戶和專案經理天馬行空的需求，你的大腦常常必須在2-3個案子之間切換，剛剛才改完維護案的bug，下午要開發另一個專案的新功能，但是…昨天…我程式碼寫到...

當專案啟動後，我們會用VSTS來管理專案中的每一個Features/work items，以及source code。 Source code管理的部分我猜大多數的開發人員比較熟悉，畢竟版控這幾乎是開發人員吃飯的工具，我們就暫且先不說了，主要是因為有用過TFS的開發人員肯定知道怎麼用，而VSTS在版控上的操作完全相同，因此不需贅言。 但由於最近幾次的改版之後，VSTS除了過去支援的TFVC，現在還支援GIT，因此似乎也必須稍微整理一下，如果以後有機會我再補齊，讀者可參考後面的篇幅。 因此，這一個部份我們先focus在work items在iterations中的處理。 回顧先前所提過的，敏捷開發的核心精神之一，就是把開發周期縮短成多個iterations，在Scrum中我們叫做Sprint。(其實想一想，我覺得不管是不是敏捷開發，只是要面對需求快速變更的近代軟體開發專案，都應該盡可能的切分出iterations) 前面曾經說過，這個Sprint可能是 1-4 周，一般來說我自己喜歡用2周。但這個長度完全取決於你希望專案有多透明，衝刺有多密集。 經驗上來說，2周是一個比較舒服愉快的周期，1周多半意味著Team Members和PO/PO, Stakeholders都得要上緊發條；但 3 or 4周我自己覺得有些鬆散了，比較適合人數比較多、或是整個專案時程預估會超過一年以上的開發團隊，或是長期抗戰永無休止日的軟體產品開發團隊。 要在VSTS當中設置iterations相當容易，你會發現當一個新的專案被建立起來之後，就已經建立好了預設的迭代了，只是系統還沒有幫你安上迭代的時間日期: 當你點選專案主選單的『Work』選項(上圖1)之後，會發現初始建立的專案已經有預設的Sprint1-6(上圖2)。但每一個Sprint的日期則還沒設定(上圖3)，而中央黃色區域的地方則是輸入工作項目的位置(上圖5)。 這別請特別留意，上面的『Sprint 1』這個名稱，是依照你選的流程版型Scrum而定，如果一開始你選的是Agile或CMMI，則Sprint會變成Iteration 原則上每一個迭代(Sprint)的週期應該一樣長 ， 當專案建立好之後，你其實可以直接修改預設已經存在的迭代名稱和日期區間: 動作很簡單，請依照上圖的操作順序，最後點選(1)的Set ...

前面 我們看過了如何免費申請VSTS站台與建立專案，接著，我們要在專案中添加成員。專案的成員在VSTS當中都是以Microsoft Account來添加的(如果你有Azure AD，也可以是AAD帳號)，在新增帳號前，有幾件事情你應該要知道… VSTS的帳號類型有三種，分為: basic(五人以內免費), MSDN Subscriber(視為已付費), Stakeholders(免費) 由於未來我們的Source code control、Work Items整個都在VSTS當中，包含bug tracking、document、unit test...等全都透過VSTS。因此，理論上所有與開發相關的人員，都必須添加進去成為專案的Member，我們可以提供這些團隊成員basic類型的帳號。Basic類型的帳號五人以內免費，如果超過五人，則需要從Azure Portal購買額外的帳號權限。 如果你的團隊成員當中，已經被指派(或購買)有MSDN訂閱，則該Microsoft Account可以選用MSDN Subscriber權限，毋須占用免費的basic權限。 如果並非Developer，且只是要觀看Work Items(像是Features, Backlogs, Tasks…等)的Stakeholders，也可以加入VSTS Members，毋須占用basic帳號，可選擇免費的Stakeholder身分即可。 要新增用戶，你可以先點選VSTS左上角畫面的Logo(下圖1)，會進入到該站台 (Collection)的管理畫面，請找到Users(下圖2): 進入該畫面之後，你可以點選(1)的部分，會出現讓你輸入email增加用戶的介面，請於(2)的地方輸入該用戶的email(必須是Microsoft Account)，Access Level請參考前面的說明，選擇三者其中之一: 請注意，我們現在新增的是整個站台(Team Site)的用戶使用權限，待會這裡新增完成之後，接著才針對專案(Team Project)來新增用戶權限。 順帶一提，也因此，VSTS的五個免費basic用戶，指的是站台，而非專案，請留意。 請依照底下的操作順序，即可把成員加入站台: 添加專案成員 當用戶被成功的加入站台之後，接著我們就可以針對專案來添加成員。 一般來說，...