.NET Walker

2017年底，Line又改了一些東西，比較重要的影響是建立Line bot的入口，過去我們習慣從Line@ Manager那邊進去，現在建立Line Bot建議讀者可以從底下位置: https://developers.line.me 進入後請點選: 如果你還沒登入Line，會跳出一個登入畫面讓你先登入: 登入後就會到選取Provider的畫面： 這個Provider是什麼呢? 你可以建立『公司』或『個人』，這是便於你日後管理Line bot使用，如果只是測試，你可以隨意建立一個。 點選了上圖的Next Page之後，會出現底下畫面： 說明如下： A>你的line bot的Icon B>你的Line bot的名稱 C>說明文字 D>方案，如果你要測試，請選擇Developer Trial，因為這個方案才有Push API，否則Free方案只能回覆訊息，無法主動發送訊息。但Developer Trial方案有50個好友的限制。(但如果你要申請正式帳號，則需要先申請Free，然後再付費升級它成為正式帳號，即可享有Push API的功能) E>帳號類型，依照你的用途選擇即可。 F>管理者Email 完成後按下 Confirm 鈕，接著會出現讓你非同意不可的條款，請乖乖打勾: 然後按下Create，就建立完成啦: 你點選上面這個頭像後，依舊可以看到熟悉的管理後台，包含建立Channel Access Token的位置，設定WebHook的位置，都在: 基本上，這是個沒甚麼真正改變的改變，大致上申請流程都完全相同，就是開發人員可以在單一介面上控管與bot申請、開發、設定有關的 所有工作，重點還是在WebHook的設定以及Channel Access Token的取得，沒什麼太大變化。 ------------------ 相關課程： http://www.studyhost.tw/NewCourses/LineBot 電子書： http://studyhost.blogspot.tw/2017/12/line-bot.html LineBotSDK： https://www.nuget.org/packages/LineBotSDK 如果需要即時取得更多相關訊息，可按 這裡 加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的...

在 上一篇 我們談過了AOP的概念以及如何透過attribute來實作類AOP的機制之後，你一定會想，要說Infrastructure Logic最容易跟Business夾雜在一起的情境，莫過於try…catch了，任何Business Logic中夾雜著try…catch，都很容易造成程式碼的過度相依，我們是否可以透過前面學習到的概念，利用Attribute來處理Exception呢? 我們看底下這段Code: 上面這段程式碼和上一篇我們介紹時的一樣，唯一的差別是第13行我們多加了一個ExceptionNotify的Attribute，這個Attribute會讓Calculate()這個Method發生Exception之後，自動將Ecception的狀態寫入LogFileName指定的log.txt檔。而無須把這樣寫log的程式碼用try…catch的方式寫在Calculate()這個Method當中…怎麼實現的呢? 我們看ExceptionNotify這個Attribute: 我們只需要繼承 PolicyInjectionAttributeBase，建立一個自己的ExceptionNotify，並且override OnException(sender,e)這個Method，在其中進行我們想做的錯誤處理即可。 如此一來，當掛上該Attribute的Method發生Exception時，就會觸發你在OnException中寫的code，將Log儲存到LogFileName所指定的檔案位置了: 如此一來，就再也不需要把處理例外的程式碼雜亂的混入Business Logic程式碼中了，不失為降低相依性的一個好方法。 完整程式碼可以參考: https://github.com/isdaviddong/isRock.Framework.AOP-Examples ----------------- 相關教育訓練: http://www.studyhost.tw/NewCourses/Architecture 若這篇文章對您有所幫助，請點選 這裡 加入FaceBook專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。

這系列的上一篇居然是2013年…沒說錯，是2013，四年前!!! MS Enterprise Library 6.0(一) - Unity Application Block MS Enterprise Library 6.0 (二) - Logging Application Block MS Enterprise Library 6.0 (三) - Exception Handling Application Block MS Enterprise Library 6.0 (四) - Policy Injection Application Block 說真的，如果不是因為開了課，我根本早忘記我曾經寫過上面這幾篇文章。 上週六，是『 團隊開發 與 架構設計 實務 』這個課程的第二天上課，在課程中我們談到了一個框架設計上我常用的技巧，也就是如何透過Attribute來實作AOP(嚴格說起來是廣義的AOP)。如果你不確定明白AOP(Aspect-Oriented Programming)的基本概念，可以參考四年前的 這篇 。(天啊，四年前…) 課程中，我做了一個範例(具體內容後面說)，和某位學員討論的時候，突然看到學員的螢幕上出現了一篇看似有點眼熟的文章，語氣跟我好像…咦? 作者怎麼是我？是了，就是剛才說的四年前寫的 那篇 ， 這篇 文章中介紹了PIAB(policy injection application block)，這是當年我在Tech Days介紹MS Enterprise Library時，特別喜愛的一個application block，它很精采的把Business Logic和Infrastructure Logic做一個非常有效的切割，達成cross-cutting concerns的獨立性。 這一系列的文章或許是因為點擊率不很高，也或者是當時有別的事情再忙…我寫著寫著居然就忘了…也因此這個系列就沒了下文。時過境遷，這次上課的時候，我也不再介紹PIAB，因為這個PIAB Library的nuget套件很不爭氣的始終停留在2013年都沒更新，因此我們只能從底層架構說明透過Attribute實現AOP概念的作法。 不過這樣也好，學員可以從根本理解實現AOP可能的幾個方式 。然而，美中不足的是這樣去實現AOP的Method呼叫時，就得要有另一個Loa...

有一個很讚的網站，叫做 https://clippingmagic.com/ 這個神奇的網站，可以幫助你用簡簡單單的一筆一畫完成圖檔的去背。 你只需要像是上面這樣，用綠筆把圖檔要保留的部分畫起來，再用紅筆劃掉不想保留的部分，就能得到一個去背後的圖檔，剛出來的時候炫爆了。 最近這個網站不炫了，原因是，它…開始收費了。 以前去背靠這網站現在該怎麼辦呢? 雖然其實也不貴，但還是潛意識反射動作的在拿出信用卡前，找找有沒有其他的替代方案…上網查了一下，哇靠，原來我們偉大的PowerPoint內建這個功能!! 你只需要點選要去背的圖檔，然後選擇格式->背景移除，就可以了，它除了會幾乎自動化的幫助完成去背，也一樣可以讓你用綠紅兩色的筆，選擇自己要保留或是移除的部分。 完成之後，把去背成功的圖檔另存新檔就可以了： PowerPoint…還真是不能小看你的啊

有一天上課，講到單元測試，學員聽到VSTS預設的範本就可以在CI/Scheduled Build當中自動運行單元測試，並且產生出測試涵蓋率的報表，大家都很興奮（雖然我不知道為何大家都那麼興奮…) 然後Lab時就開始下手開幹了，Build裡面運行unit test沒問題，出來的結果如下: No Build Code Coverage Data Avaliable???? 什麼鬼？說好的測試碼涵蓋率呢？ 莫急莫慌莫害怕… 請回到Build Step中的Test Assemblies, 預設狀況下Code Coverage Enabled是沒有勾的… 勾上之後，老闆要的測試碼涵蓋率就出現囉… (A:上面那個範例只寫了一個測試，啊是有什麼好涵蓋的啦…) (B:沒關係，讓ＰＭ看到圖就大家開心了…) ----------------------------- 本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html 相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 若這篇文章對您有所幫助，請點選 這裡 加入FaceBook專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。

一般來說，我們在進行VSTS教育訓練時，都透過Azure Web Site做CI後的自動佈署，達成一個基本的CD流程。 要在VSTS的Build中『順便』將Build好的成果佈署到某一個Azure Web Site上，基本跟喝水一樣簡單，因為VSTS的Build definition範本中，預設就有這個功能： 你會發現，建立出來的Build Process當中，有預設的Azure App Service Deploy這個task: 把該填的資料填一下，就可以Build完順便自動將Build好的結果佈署到某個azure網站，這樣很讚，自動到你不知道怎麼回事就完成了。 但，如果你一開始建立的範本忘了選Deploy，也可以手動加上這個Task： 很容易，對不對? 但學員卻常常有一個問題。 公司高層考慮了很久之後，終於想通了願意用VSTS或TFS，但問題是要佈署的網站不是Azure（因為這部分依舊沒想通，覺得在雲上太不安全或太貴了，堅持要用自己家裡或其他hosting的IIS)，那怎麼辦呢？ 沒問題，把Azure App Service Deploy換成FTP就好啦，你可以在 Visual Studio Marketplace中找到一個免費的FTP Uploader套件： 位於 https://marketplace.visualstudio.com/items?itemName=januskamphansen.ftpupload-task ，點選上圖中的Install安裝到你的VSTS或TFS站台之後，你就會在UtilityTasks中看到一個新的FTP Uploader套件: 和VSTS裡面的 FTP Upload task不同的是，它相對的比較直覺，並且會自動幫你過濾掉不該上傳到網站上的一些檔案(例如.cs之類的source code)，我們可以用它來取代原本的Azure App Service Deploy，將一些該設定的參數設定一下，就可以完成自動佈署囉: 留意上面的參數，以我們熟悉的Azure Web Site為例，帳號密碼欄位你不會有任何懸念，而FTP Address指向root即可，Remote Path如果對照Azure Web sites則是/site/wwwroot，而source path可以用下拉的方式選擇，拿asp.net來說，指定Web S...

這個月(還是上個月?忘了)，Line Bot增加了DateTimePicker功能，可以在Template Message當中加入了DateTimePicker Action，當用戶點選之後，即可用手機預設的UI選擇時間日期，並讓開發人員以postback參數的方式取得用戶選擇的日期。 這功能非常有價值，因為自然語言對談的過程中，如果要讓用戶輸入日期，用戶難免自行發揮，格式千奇百怪，對於開發人員來說會是一個困擾。有了這個功能，當Line bot需要用戶輸入日期時，不僅格式統一，且使用者輸入時也可以少按一些，更為方便。 使用此功能不難，您只需要建立一個Template Message，並指定Action的類型為DateTimePicker即可： 上面程式碼當中(A)的位置，就是建立所需要的DateTimePickerAction，而(B)所指定的參數mode，則是跳出時間日期選擇器的類型，可以是date/time/datetime其中之一。 範例中其他的程式碼都跟一般的TemplateMessage建立沒兩樣，完成後發送出訊息，就會看到類似底下這樣的畫面: 一旦用戶選定值並按下『傳送』之後，我們就可以透過WebAPI(WebHook)取得的postback參數來收到這個值，程式碼如下： 請留意上圖中(A)的部分，您可以在收取到的訊息的postback物件中，取得Params底下的datetime/date/time屬性，這個屬性會依照先前你在Action中指定的類型，被填入相對應的值。 例如，剛才我們建立Action時，第一個action是mode=time這個類型，因此，當用戶點選該action，Line會跳出時間選擇框讓用戶選擇時間，用戶選定後，Line bot就會產生一個postback，因此我們的後端WebAPI被觸發，同時間ReceivedMessage.events[0].postback.Params.time會被賦予用戶選擇的值: 整個操作的順序大致如上圖所示。 透過這個功能，當Line bot需要用戶輸入日期時，就更加的方便了，可以預期的，未來不管是GPS座標位置、或是更複雜的選擇項目，都可以透過類似的機制來完成，非常讓人期待。 別忘了 LineBotSDK請升級到 0.6.0-beta 完整程式碼請參考: https://github.com/is...

如果你實際開發過Chat bot，就會發現NLP(自然語言分析)本身就是一個很大的問題，即便現在有LUIS可以幫助我們做語意分析，但實務上分析結果要100%符合用戶(或開發人員)的心意不是易事，倘若可行，在商務應用時，Chat bot與用戶之間的一問一答對談，想要提高可用率，讓用戶以選項的方式回答還是比自然語言對談來的好很多。 舉例來說，在 上一篇 我們介紹的CIC類別當中，如果我們的chat bot要問用戶要請哪一種假別，與其讓用戶自己回答，不如讓用戶用選的乾脆一些。 原本對談的設計是: 但這風險很高，因為我們開放用戶自己用輸入的方式回答。 如果用戶偏偏要回答: 我今天想請事假     或 請婚假     或 什麼根本沒聽過的假… 對Chat bot來說都要做自然語言分析，就算分析的再正確，在開發上難度也提升不少，但如果用底下這樣的ButtonsTemplated Message詢問用戶，用戶只能在底下的選項中擇一回答，那就容易多了: 上一篇 說過，我們要透過繼承自ConversationEntity的LeaveReuqest類別來處理這對話邏輯，而這一版我們加上了支援ButtonsTemplate Message，你只需要使用ButtonsTemplateQuestion這個Attribute即可(注意第3行): 我們新建立的這個LeaveRequestV2，跟上一篇的LeaveRequest很像，但第一個詢問假別的問題，改用了ButtonsTemplateQuestion Attribute(注意，你必須把LineBotSDK升級至 0.5.7-beta )，程式碼就只需要做這一個小小的調整即可。 由於加上了ButtonsTemplate Message，chat bot WebApi Controller主程式碼也小幅修改一下: 只需要配合ButtonsTemplate Message在59-59行針對CIC的Process result，取得ResponseButtonsTemplateCandidat(64行)進行Reply即可。 其他的程式碼跟上一版幾乎完全一樣沒變。 而24-29行只是加了一小段判斷，規定用戶只能選擇事假、病假、公假其中之一…純粹只是寫著玩測試一下。 執行這段對話之後，ch...

開發對談機器人，一直有一個很關鍵的議題，就是如何處理連續性的對話。 這個問題，上課時學員問過、研討會時聽眾問過、公司同事問過、客戶問過、學校老師問過、差不多連路人甲(我是說對開發chat-bot不熟但剛好聽到chat-bot開發的路人甲)都很關心… 舉例來說 舉一個典型的例子，如果我們要開發一個聊天機器人來處理請假，那這對話大約是底下這樣： 請注意用戶開始跟chat-bot說：『我要請假』之後，chat bot進入了一個連續對談模式，在這個連續對談模式中，chat bot以一問一答的方式，跟用戶蒐集請假資訊，依序詢問用戶請假假別、代理人、時間…等資訊。 最後，蒐集完所有資訊之後，進行請假動作(上面的例子是以JSON方式把蒐集到的資訊顯示出來，沒有真的請假，但意思到了)。 需求就是這樣。這有什麼難的?  其實，還真的不很容易。 首先，如果你不想把程式碼寫死，想用同一套框架或邏輯來處理同性質的會話(conversation)，這本身就有不低的難度。其次，每一個一問一答的對談之間，由於是同一個WebHook來處理的，因此要記錄狀態(state)，諸如:這次問的是什麼、用戶回答的答案是對應到哪一個問句、目前的交易是屬於哪一個用戶…，這是第二層難度。 接著，用戶回答的型別如果不符合? (例如問’請假時間’，結果用戶回了一句’事假’) 該怎麼辦?  還有，就算用戶回答的資料型別正確，但邏輯上不合理(例如代理人用戶寫Tom，但公司就明明沒有Tom這個人)，又該怎麼處理? 想起來，如果chat-bot要寫這種會話對談，將會是一段很恐怖的程式。 但，我實在被問過太多太多太多次這個問題了，因此，索性，找了一個心情很差的周末，我嘗試寫一個能夠處理這樣對談的框架。 怎麼用? 假設，你要處理上面這樣的對談，你可以建立一個類似底下這樣繼承自ConversationEntity的類別: 先別指摘我上面這個範例中的類別怎麼會用中文當屬性名稱，這是故意的。這是為了讓讀者更好理解，正式環境你當然可以換成英文。 但，這類別真的很好懂，是吧? 這類別表示了『請假(LeaveRequest)』這個對話將會有五個問句，第一句是問用戶『請問您要請的假別是?』，用戶回答的結果會被放入『假別』這個屬性中。第二句是是問用戶『請問您的代理人是誰?』，用戶回答的結果會被放入『代理人』這個屬性中。 其...

這幾年做教育訓練、顧問服務、和系統導入，發現一件有趣的事情。 有幾次碰到一些客戶(有商業公司、非營利組織、學校…都有)，在開會或課程之後私下跟我說，希望我們在提供建議的時候，可以『直接』告訴我們的team member，這件事情該怎麼做，而不用花太多時間告訴我們這些事情的原則，或是背後的邏輯或原理。因為team member只需要快速地得到答案，加上事情很緊迫，他們也沒有時間去學，說多了徒增困擾(這句話有個潛台詞，建議讀者細想，很有趣…)，顧問(講師)直接告知做法之後，我們就可以比較快進入下一個問題(議題)。 可能有人看了上面這段話不明白意思，我舉其中一個比較具體的例子。 有一次碰到一個軟體開發的資安問題，我花了幾個小時解釋為何程式碼這樣寫不行，為何這有可能帶來風險，從這樣的程式碼我們可以得知外包的開發人員應該有哪些問題…，幾個小時下來，我發現，客戶唯一關心的事情只有一個: 那現在這行程式要怎麼改? 直接告訴我就好。 至於其他的，大夥兒絲毫不在意。 這類的例子最近層出不窮。由於樣本數雖然多但我沒徹底研究，因此目前我無從取得確切的證據，證明背後的原因是什麼? 但推敲之後，能猜個大概。 可能是因為這年頭大家都很忙，碰到問題，只想快速知道答案。而網路的便利性讓許多人變成只願意(也似乎可以)迅速的取得結果，久而久之，慢慢地不願意也沒耐心花太多時間深入理解問題背後的成因。 也就是說，大家並不真的在乎(到願意付上代價、例如時間)來面對問題、或學習解決問題的能力。 許多人變得只想知道，當下眼前這問題怎麼解決。 『告訴我解法就好，其餘的我不想多知道。』似乎已經是網路速食時代的寫照。 這是最近幾年碰到的，以往，大概十年前，這情況比較不常發生。但不用我說大家應該也知道，長久下來這(對企業、或團隊)會導致什麼結果。 再加上，網路時代很多流傳文章，標題長這樣：『OOO的原因原來是XXX』、『解決XYZ的N種方法』、『想要OOO就得XXX』這類的文章都很紅。標題看似一針見血，但內容往往很武斷。大部分的文章(或課程)中提出的見解或解決方案，其實都隱含著一個假設前提，就是你的環境和他(作者)相同，然而你也知道，真實世界中哪有環境都相同的? 礙於篇幅(也礙於其實讀者也沒興趣知道)，因此大多數文章的作者，也不太會詳細敘述案情的成因與環境的背景，導致部分憨直的讀者以為，我照著做就會有一樣的結果，其實不...