.NET Walker

#世事無絕對 #分久必合 #合久必分 #潮流 如果你是從Basic/C/Pascal那個年代開始學程式設計，印象中老師會暗示學生說 COBOL 是一種相對不受歡迎(或落後)的程式設計語言，那時候大家(主流市場)看起來都很感冒 COBOL 那種縮排式、英文句型式的語法，當時從沒聽過有人覺得 COBOL 的 "高可讀性" 具有任何的可取之處... 我也只是因為好奇寫過一兩次，之後沒多久，它就消失在整個 C like languages 的風潮之下... 正當我以為未來的人生再也碰不到類似的程式撰寫風格時，python出現了...說實話，我真的很難接受不用 { ... } 作為區塊的程式設計語言...我覺得python的走紅估計應該是一個意外... 但，沒多久，我又碰到了YAML...，然後我開始聽到許多人讚揚python和YAML這種 "高可讀性" 的程式設計語法! 這使得我有點混亂了... 這讓我開始懷疑當年厭惡 COBOL 到底是不是一個理智的決定? 還是只是人云亦云的結果? YAML有高可讀性? 怎麼我覺得JSON比較好讀呢? 我猜，這是因為十幾年 {...} 的洗禮下來，老人的腦袋結構已經有些轉變了的原因... 但對於初踏入這個世界的初學者來說，python/YAML或許確實真的比較好讀...(可現在的我真的已經無法體會了 >_< )... 環境氛圍改變了我們的喜好，而喜好和習慣又改變了我們的價值觀。 隨著年紀的遞增，我發現確實有些事情是我沒法理解的。 而無法理解的事情，又怎麼能去評論對錯呢?

做軟體開發很多年之後，常碰到有人問我，軟體公司是怎麼估算一套軟體的價格的? 用開發的人天數來算嗎? No, No, No…『人天數』是一個非常標準的 錯誤答案 。 如果你是軟體開發商，軟體開發的『人天數』可能是你的成本，但絕對不會是報價/售價。 那報價/售價怎麼定呢? 讓我先問一個問題... 對於買方來說，什麼叫做『買貴了一套軟體』? 或者反過來問，什麼叫做『買了一套划算的軟體』? 不好回答? 想一想底下的例子... 如果軟體開發商花5個人月為買方(你的公司)客製化開發了一套系統，然後賣你500萬，對你來說，這貴不貴? 其實我們不知道。因為貴不貴是相對於這套軟體能為你帶來多少價值而定的? (而非開發商花了多少時間) 如果你花了500萬，系統上線後，能每個月為你帶來50萬的效益，那我覺得這500萬算很值了。但...如果系統上線了，一年後都沒法為你帶回幾十萬的效益，甚至還讓你虧錢(請相信我，類似上線後還虧/花大錢的案例你在資訊界隨便問都一票)，那不管這套軟體廠商是花十幾上百個月，對你來說這套系統都是買貴了，一點都不划算，應該說，這軟體一點意義都沒有。 如果你同意這個思維，大概就能理解，軟體開發的報價不該是用人天來算，況且，一個軟體開發高手跟一個會寫程式的菜鳥初學者，兩個人『一天』的產出差異恐怕可以達十倍以上，但你有看過人天報價level差異化到十倍的水準嗎?應該從來沒有吧。 那有沒有覺得很奇怪，如果軟體不該用人天來計價，那為何打從你第一天進到這個產業，一直到今天，都還是會常常聽到人月或人天這個計價單位呢?   有一種可能是，我們其實不怎麼知道(不會、不敢、或不願)去評估一套軟體系統的『價值(Value)』。 很難理解? 其實這就如同大部分的公司其實很難評估一個員工的產值一樣。 若當公司不知道該怎麼(或不願意)去衡量員工的產值時，往往就只好拿 其他看起來很公平客觀的數字 (例如出席狀況和上班工時)來決定員工的價值了。而這正是一種非常古老落後且糟糕的方式。 久而久之，當員工養成習慣用『在辦公室出現的時數』，甚至是加班時數、配合度…來彰顯自己價值時，其實也多半意味著，手上根本沒有一張漂亮的成績單，漂亮到可以拿出來凸顯自己的存在對公司的意義。常常有人說，準時上下班是最基本的，這話一體兩面，準時出現在辦公室確實真的就只是『最基本的』。 時代變化的很...

先前 我們介紹過了 LINE Login這個機制，它可以讓我們的網站像是使用Google帳號做SSO(Single Sign On)一樣，達成單一登入的功能。 一旦完成整合之後，未來你的網站上的用戶，將可以用LINE帳號登入，而不需要記憶太多組帳號密碼。這和透過Google/Microsoft/FB做SSO效果相同，但，整合LINE Login有一個額外的好處，就是你有機會取得用戶的User Id，直接透過Line Bot發(Push)訊息給該用戶。這點是Google/Microsoft SSO無法實現的... 底下這個範例大致展示了如何實現LINE Login的基本功能： https://github.com/isdaviddong/Line_Login_Example 其中有一個常被開發人員問到的問題。 使用LINE Login的時候，可以透過取得的Access Token得知用戶的User ID(這很好用，只要綁定同一個Prodiver底下的LINE Bot，我們就有機會可以直接Push訊息給用戶)和Display Name、頭像…等資訊。 那可以知道用戶的email嗎? 答案是可以的，我們可以取得用戶的email。 不過有一些前提，也不難，只要你在建立LINE Login Channel的時候，Apply一下Email就可以了： 請在上面這個LINE Login後台Channel的選項中，選擇Submit，接著在跳出來的畫面中： 勾選最上方的兩個同意事項(當然，請先看過內容)，然後上傳一個截圖(證明你的Web應用程式或網站有跟用戶說明你會索取用戶的email並且徵求用戶的同意使用)，完成後，會發現它就變成applied： 接著，調整一下你的登入轉址程式碼，在scope部分加上openid與email： 如此一來，你會發現用戶登入時，LINE Login會跟用戶索取email： 當用戶同意，並且成功登入，導回callback URL之後，你可以透過底下這段程式碼，來取得用戶的email： 搞定~看起來超簡單。 如何完成的? 說明一下背景觀念。 這是因為當我們配置了scope=openid%20profile%20email之後，LINE Login回傳的Token JSON之中，包含了id_token這個資訊(請注意，與access_token不同)： 當我們...

令人期待的事情總是拖得比較久。 但MS Bot Framework支援LINE Bot的這一天總算是來臨了。 先說說為何大夥們會希望Bot Framework支援LINE? 其中最基本的因素大概是Bot Framework目前已經支援多種Channel、本身又內建狀態管理機制、可以很方便的串接自然語言對談和撰寫程式碼，這讓開發人員有機會，只需要寫一次Bot核心Business Logic的code，就讓前端同時支援Web/Skype/FB Messenger/LINE/Telegram…等多種IM： 過去Bot Fx是沒有支援LINE這個Channel的，在眾多開發人員的催促下，微軟從善如流的照做了…好，我們這就來看看Bot Fx如何支援LINE? 首先，請在Azure Portal上用最基本的方式(Web App Bot)建立一支Bot： 稍微留意一下底下的輸入畫面： 現在的Azure Portal，常常在我們建立一個資源時，同時建立很多資源。這啥意思? 例如我們要建立一個支援LINE的Bot，但其實他後面有Azure Web App，Storage，甚至LUIS或QnA Maker(看你的選擇)，所以這一建常常一堆資源出現，因此我們都會建議讀者把這些資源建立在同一個新開的資源群組(Resource Group)，以便於日後 要刪一起刪 方便維護，請參考上圖2。 至於機器人範本，我們建議選擇Echo Bot，先維持簡單就好(上圖5)。 建立好之後，我們立刻到這個資源來看看： 到了該資源之後，我們可以先點選頻道，你會看到預設狀況下已經有一個頻道(Web Chat)在跑步了…(唉，跑什麼步啊…是running啦…) 你可以點選在WebChat中測試，系統會用Web UI讓您測試： 沒錯，他跑起來了，就是一個Echo Bot… 接著，我們要讓他支援LINE，請進入頻道設定，輸入下圖中1,2的資訊： 等等，上面的『頻道秘密』和『頻道存取權杖』是什麼? 如果你有建立過LINE Bot應該就知道(沒建立過可以參考 這邊 )，它是你可以從LINE Bot後台找到的 Channel Secret和Channel access token啦(btw, 建立的LINE Bot必須支援Push)： 別忘了，剛才上一張圖中的WebHook URL(標示3)，你必須回填到LINE Bot的...

LINE Bot這一系列，從2016年五月開始，寫著寫著也快30篇了，差不多剛好一個月一篇，如果資訊雜誌還在的話，應該可以是一個專欄。 很久沒有整理索引了，2019年初，再次將這一系列相關連結整理如後： 使用C#開發LineBot (1) - 用c#建立一個LineBot 使用C#開發LineBot(2) - 新版Line@ Messaging API使用心得 (Line Bot v2) 使用C#開發LineBot(3) - 使用LineBotSDK發送Line訊息 使用C#開發LineBot(4) - 透過asp.net輕鬆建立Line機器人WebHook 使用C#開發LineBot(5) - 透過程式碼讓Linebot發送圖片、貼圖 使用C#開發LineBot(6) - 不用申請Bot也能發訊息的Line Notify 使用C#開發LineBot(7) - 使用Line Login實現oAuth SSO(單一登入) 使用C#開發LineBot(8) - 發送Template Message 使用C#開發LineBot(9) - 取得新加入的好友身分資訊 使用C#開發LineBot(10) - 取得用戶上傳給Linebot的照片 使用C#開發LineBot(11) – Chat bot如何處理連續對話 使用C#開發LineBot(12) – 在連續對話中加入ButtonsTemplate訊息 使用C#開發LineBot(13) – 使用Date Time Picker讓用戶輸入日期資訊 使用C#開發LineBot(14) – 新版建立Line Bot流程(2017年底) 使用C#開發LineBot(15) – 當Linebot與我們同在一起, 談群組(聊天室)處理 使用C#開發LineBot(16) – 讓 WebHook 開發更輕鬆 使用C#開發LineBot(17) – 使用新版Line Login v2.1 使用C#開發LineBot(18) - 不寫一行code完成Line bot 使用C#開發Linebot(19) - 建立LUIS服務處裡自然語言辨識 使用C#開發Linebot(20) - 不寫一行code完成Linebot的LUIS串接 使用C#開發Linebot(21) - ImageCarouselTemplate的支援 開發Linebo...

好了， 前面 知道了手動透過LINE@後台設定Rich Menu的方式，接著我們就要來看，如果開發人員打算透過API來動態建立選單，該怎麼做呢? Rich Menu 的使用流程 如果要透過API來建立Rich Menu，建議您依照底下的流程： 準備好一張圖片 2500x1686 or 2500x843 pixels，格式為 .png 透過CreateRichMenu(…)方法來建立Rich Menu 透過SetDefaultRichMenu (…)方法將Rich Menu設定為Default Rich Menu(給所有用戶) 或是 透過LinkRichMenuToUser(…)方法將Rich Menu設定給特定用戶 建立前的準備 好，我們接著就試試看如何透過程式碼來動態建立Rich Menu，我們先準備好一張圖片，類似底下這樣： 它看起來不像選單？對，我們故意用這個看起來比較特別的圖片，你會發現其實當我們用程式碼來建立Rich Menu時，自由度其實比透過LINE@後台要高很多。 如果需要的話，你可以從底下網址下載這張圖片： http://arock.blob.core.windows.net/blogdata201902/test01.png 這張圖片的左右兩塊，分別是兩個按鈕區塊，整張圖片的尺寸是 2500x1686，而這兩個左右區塊的座標，分別是： 左方：(0,0)-(460,1686) 右方：(2040,0)-(2500,1686) 我們待會要建立出一個效果，讓用戶看到這個Rich Menu，可以按下左方區塊按鈕，或是右方區塊按鈕，按下去的時候，分別顯示相對應的文字。 透過程式碼建立default Ruch Menu 有了圖片之後，我們來看怎麼建立這個選單，程式碼如下： 程式碼一開始，我們建立了一個RichMenuItem()物件，然後設置了name和chatBarText這兩個屬性。這兩個屬性都不能是空值。而預設的尺寸是2500x1686，如果你不想改變它，就無需特別設定。 然後接著程式碼建立了兩個Area物件，分別是左方和右方按鈕區塊。例如建立左方區塊Area的程式碼如下： 重點在bounds物件的x,y,width,height分別定位出了該按鈕區塊的範圍，以左上(0,0)右下(2500,1686)的座標型式，而每一個Area物件同時也可以擁有一個ac...

Rich Menu是LINE Bot開發當中一個非常重要的機制，甚至可以說是LINE Bot的特色，它是一個讓我們有機會可以開始把LINE Bot當作資訊系統來操作的重要功能，接下來幾篇文章，我們要來談談這個部分。 什麼是Rich Menu? 一般來說，Rich Menu是一塊像是下圖這樣的選單，可以有不同的區塊分隔設計，每一個區塊可以設計成按鈕或選單的形式，類似像下圖下方框線標示出的區塊這樣： 不一定只能像是上面這樣，將圖示按鈕切割成上面這樣的六塊，也可以是底下這樣三塊的配置： 具體配置方式其實有很多種，我們後面會陸續跟大家介紹。 在這些按鈕上，我們可以賦予不同的功能，像是點選後開啟特定URL，或是幫用戶說一句話，甚至是觸發postback event、開啟DateTime Picker，幫助用戶輸入GPS地址…等。 另外，透過API，我們可以動態的決定特定(或是所有)用戶呈現出的Rich Menu，不僅如此，我們可以非常自由的定義Ruch Menu的外觀，以及按鈕上面的功能與形式。 我們甚至可以實作出類似選單切換的效果，讓一個用戶享有不只一組Rich Menu，如此一來，我們幾乎可以把LINE Bot當作小型的應用系統來玩，特別是搭配了LIFF(LINE Front-end Framework) App之後。 Rich Menu 的功能與手動設定方式 好，我們看過了選單的外觀之後，接著來看看，一般來說，要如何設計這個選單呢？ 目前有幾種不同的選擇，可以透過LINE@後台『建立圖文選單』的方式來設計，也可以透過API來動態設計。 從LINE@後台設計的方式其實很簡單，可以從LINE@後台 https://admin-official.line.me 這個網址登入，然後找到你的Bot，點選後，可以看到該Bot的左方選單中有一個建立圖文影音內容的選項，你可以在其中找到『圖文選單』： 點選後即可設計，它分為兩種設計方式，一種是以圖片的方式製作，另一種是以『文字和圖標(其實就是圖示)』的方式製作。 如果你選擇後者，畫面上會出現上面兩種版型，你可以選擇其中一種分隔方式。 選好之後，下方會出現相對應的『選單內容設定』： 你可以在上圖A的部分選擇你要設定的是哪一個區塊，B的部分則是讓你選擇按鈕的圖示，C的部分則是要呈現的功能，有三個選項可以選擇，如果你選擇網址，則用戶點選該按...

Microsoft Cognitive Services (0) - 讓你的App走進人工智慧的大門 Microsoft Cognitive Services (1) - 使用Computer Vision API辨識人臉 Microsoft Cognitive Services (2) - 使用Vision API進行OCR Microsoft Cognitive Services (3) - 在你的app中直接加入語音辨識 Microsoft Cognitive Services (4) - 使用Speech API讓你的電腦說話 Microsoft Cognitive Services (5) - 使用Translator Text API翻譯文字 QnA Maker 微軟認知服務(Cognitive Services)中的QnA Maker 系列文 x 6 微軟認知服務中的QnA Maker– (1) 什麼是QnA Maker? 微軟認知服務中的QnA Maker– (2) 建立QnA Maker服務 微軟認知服務中的QnA Maker– (3) 測試與訓練 微軟認知服務中的QnA Maker– (4) 與LINE Bot整合 QnA Service的Knowledge Base加上共同管理者 建立QnA Maker時的小陷阱 Bot Framework相關: 關於bot framework (1) - 緣起 關於bot framework (2) - 建立一個最基本的bot(v1舊版) - 已過時 關於bot framework (3) - 建立一個最基本的bot (v3新版) 關於bot framework (4) - 使用LUIS，讓你的bot理解用戶輸入文字的意義 關於bot framework (5) - 透過.net SDK使用LUIS 關於bot framework (6) - 如何分辨WebChat用戶並保護Secret key 其他 關於Skype Bot (1) - 建立

最近我們有很多案子大量地使用到Cognitive Services當中另一個很好用的服務，那就是 Translator Taxt API。這一組服務可以幫你識別文字的語系，當然也可以翻譯文字，用法相當簡單，只需要透過REST API呼叫即可。 使用前同樣需要在Azure站台上申請Translator Text服務(有免費方案)，你會得到一組Key，可以從底下位置取得： 好了，有了需要的Key之後，我們就可以透過這組雲端服務來實際來撰寫翻譯程式了。 辨識輸入文字的語系 我們先看文字語系識別的部分，我們一樣透過Windows應用程式來示範，執行結果如下： 上方的文字方塊是我們輸入要辨識的文字，按下『判斷語系』鈕之後你會發現系統告訴我們，最有可能的語系是zh-Hant也就是繁體中文。 這算是相當正確的了，因為句子中有些中英夾雜，這樣的效果算是挺讓人滿意了。 我們來看程式碼，主程式只有兩行： 上面這段程式碼沒什麼內容，純粹就只是呼叫一個Detect方法，該方法是我們撰寫來透過http post呼叫遠端的辨識服務的，程式碼如下： 上面這段程式碼其實也非常簡單，透過HttpClient進行一個http post呼叫，呼叫的endpoint是： https://api.cognitive.microsofttranslator.com/detect?api-version=3.0 然後把要辨識的文字text轉成JSON以body傳給該endpoint。比較需要注意的是，必須把剛才申請的key以Ocp-Apim-Subscription-Key這個header name一併傳遞過去。 取回結果後，我們再反序列化為物件，就完成了唷。由於辨識可能會有多種結果，所以回傳的物件result，我們取第一組辨識結果result.FirstOrDefault()，透過language屬性取得語系，透過score取得分數： 這個分數是辨識的可靠度，倘若用戶輸入的文字可能符合多個語系，可以透過這個score取得最符合的語系。 即時翻譯輸入的文字 接著我們來看文字翻譯的功能，使用的方式也非常簡單，我們先看執行的結果： 當我們按下翻譯鈕，底下出現的是翻譯後的結果，由於我們的目標語系是en(英文)，Translator Text API很順利的把上面的文字翻成英文囉。 主要的程式碼如下： 我們建...

先前介紹過Imgur.com可做為開發人員的圖檔上傳位置之後，就有學員們敲碗，要我們具體DEMO一下如何把Chat bot用戶上傳的照片或圖檔存到Imgur.com中。 別急，我們這不就來了嗎? 回頭先討論一下這個需求的背景，過去我們曾介紹過，在開發LINE Bot時若要抓取用戶傳來的圖檔或是照片時，由於該圖檔其實是保存在LINE的伺服器中，且有七天的保存期限，因此若我們要永久保存該圖檔，或做一些加工處理，所採用的方法是，將該圖檔(的binary資料)從LINE取得後，在我們WebHook所在的IIS伺服器上，直接複製儲存一份，然後取得該實體檔案的相對路徑轉為網址。 一般來說這樣做具體可行，但如果考量的進階一點，可能會有一些需要注意的問題，舉例來說，IIS伺服器的硬碟空間如果不足，可能就會發生意外狀況。或是，該WebHook希望能夠支援HA(High Availability)做負載平衡時，也可能會發生問題。雖然，這都是系統架構比較大的時候，才會碰到的狀況，但也不可不重視。 此外，有些圖檔根本是我們的Chat bot在跟用戶對談的過程中動態產生的，產生完後就Push/Reply給用戶，用戶看完可能根本就不打算再看一次(例如即時產生的圖表、照片…等)，這類的圖檔儲存在WebHook所在的伺服器根本浪費空間，還得定時去清理，非常不經濟。 那這樣，我們有沒有其他更好的方式處理? 其實，我們可以考慮把圖檔上傳(保存)到第三方的雲端空間，而Imgur.com正好就符合我們的需求。開發人員可以透過Imgur提供的API，把圖檔上傳到Imgur.com並取得該圖檔的URL，如此一來，我們連空間和位置都無須擔心。 具體Imgur API該怎麼使用呢? 這個部分讀者可以參考底下連結： https://studyhost.blogspot.com/2018/12/imgurcom-api.html 在了解其API的使用方式之後，我們就來看如果要把LINE Bot從用戶收到的圖檔上傳到Imgur.com上，該怎麼做。 我們先看底下這個範例的執行結果： 你會發現最上面一開始用戶傳來一個圖檔，接著LINE Bot把該圖檔上傳到Imgur並取得URL後，將URL顯示給用戶(同時也再一次把該圖檔顯示出來) 看來很不錯，該展示的功能都出現了，怎麼實現呢? 首先，參考上面連結的貼文，你必須先申請好I...