.NET Walker

古時候，有個字叫做 人機介面 ，也就是人和機器溝通的通道。一直以來，人和機器的溝通是不直接的。 操作電腦，你得透過滑鼠、鍵盤、或觸控螢幕，而不是像你跟身邊其他人溝通時，可以透過對話和語言來進行。 這是一種阻礙，即便由來已久，即便你已經習慣，這仍是一種阻礙。 然而阻礙帶來了限制，但也帶來了機會。 所以開始有 程式設計師 這個行業，程式設計師把人們的需要，翻譯成電腦可以看得懂的程式碼，操控電腦來進行人們想實現的功能。自從電腦誕生以來，這個活兒就沒消失過。 上週，我去集英信誠和百敬老師聊天(其實是錄影)，從ChatGPT談到哲學和宗教，中間有一個話題，我們談到了人機介面即將改變。在過去，開發人員必須得把輸入(input)變成結構化的資料，例如表單、欄位、這樣電腦才有機會能夠理解，從而進行處理和運算。 先不管ChatGPT輸出的正確性如何(如果你上完我們的課就知道，現階段根本不該期待一個 生成式AI 所產出的東西是正確的，它只是依照格式產生看起來像樣的內容，而非正確的內容，內容的正確性得靠你的加工)，但這一波ChatGPT會造成轟動的潛在原因是， 它似乎聽得懂你說的話，而這才是重點 。 Chat Bot幾年前早過炒過一波了，結果如何? 成功了嗎? 別問我，你自己說說你對現在哪一家銀行的AI助理或是聊天機器人滿意的? 幾乎沒有。而過去Siri能夠回應你的，也總是那麼幾個簡單的指令，複雜一點的對談，整個就不行了。 但這一波ChatGPT帶來的第一個驚訝，是你發現，它似乎還真聽得懂你說的話。 沒錯，ChatGPT從去年11月底問世到今天才半年，你跟它的溝通大致上不會讓你失望，對吧? 也就是說，ChatGPT對於自然語言的理解(NLU)，好過市面上可以見到的大部分ChatBot。它能夠清楚地抓到你的intent和entities，並且對前後文的理解有很高的掌握度。 這也是我上周六在彰化小聚的時候，分享的重點之一。 ChatGPT對於ChatBot最大的價值是，這是有史以來第一次，NLU開始讓社會大眾滿意(相當高比例的可以接受)，並且API成本還算是負擔的起。 ChatBot開發人員，終於有機會突破過去的制約，讓你的ChatBot有機會真的理解用戶在說些什麼(至少讓用戶這樣覺得)，而且是透過自然語言，不用再去管傳統的表單輸入或結構化資料輸入了，這是人機介...

最近不只一次被問到這個問題。 在應用程式(或前端展示層App)呼叫API(或微服務)的時候， 雖然都會有攜帶API KEY來驗證呼叫者(App)的身分，但若是要知道用戶的身分(就是誰操作這個App來呼叫API的?)，又該怎麼辦呢? 一般來說，當我們討論微服務開發時，大多不一定會包含UI(套句Uncle Bob說的，UI是細節)。因此，在實作用戶端(End-User)的身分驗證時，往往只會做到UI(展示層)為止。但實務上，不管是多層式架構或是微服務架構，UI(展示層)又會需要呼叫微服務(或應用層API)來實現系統功能。 像是底下這樣: 但在UI呼叫微服務(應用層API)時，被呼叫端需要確認呼叫端(UI/展示層)具有呼叫微服務(或API)的權限，這一段，大多只會採用API KEY來驗證。 例如: POST / APIName HTTP / 1.1 Host : domain . com Content - Type : application / json ApiKey : 3126616e - c14b - 4ba8 -8617 - d7349541ce40 Content - Length : 23 { "data" : "infomation" } 然而，若某些微服務(或API)運作時還需要得知用戶端身分，又會怎麼做呢? 簡單一點的作法，是直接透過JSON Body告知API當前用戶是誰(前提當然是API信任這個呼叫端)，這樣既暴力又簡單，如果想更嚴謹一點，可以在Header攜帶先前用戶已經驗證過的Access Token/JWT Token來實現： User Web App (UI) Microservices(API) 登入(Cookies/JWT/OAuth) 登入成功(保留User Token) ...若不須用戶身分資訊... 發送請求 呼叫API (帶上API Key) (API確認呼叫者是哪個App)返回結果 顯示結果 ...當需要用戶身分資訊... 發送請求(帶上User Token) 呼叫API (帶上API Key, User Token) (API確認呼叫者是哪個App, 哪位User)返回結果 顯示結果 User Web App (UI) Microservice...

最近重讀 Sam Newman的『建構微服務』，覺得實在精彩。真心以為，想作微服務系統的開發人員，都值得花點時間讀一下第一章，絕對值回票價。 我把讀完的感想和摘要寫在下面，希望能夠幫助大家釐清什麼是微服務(以及什麼不是)。 傳統來說，古典的單體式應用(Monolith)大多意指在同一個行程內運行的應用系統，底下是典型的單體式應用程式與其變形。 古典的單體應用程式 一個應用程式，後面搭配一套DB，但上面這樣的系統已經愈來愈少了，只剩下像是手機app或是極端傳統的desktop app。 如今大部分的單體式應用系統(不管是desktop或web)，大多會是底下這樣： 模組化單體式應用程式 模組採用同樣(或近乎類似)的開發技術。 模組間有共用的基礎設施(infrastructure)，像是log, security…etc. 即便模組可以獨立運行，但依舊必須一起佈署。 單體式應用系統的優點 相較於微服務，單體式應用系統其實有很多優點: 簡化開發人員工作流程 簡化監控、故障排除、與測試 這是事實，但Sam Newman強調『最近人們開始將單體式系統視為「時代遺產」的同義詞，仿佛這種系統有著什麼本質上的問題，是一個需要避免的東西…』 但其實，單體式架構只是一種選擇，甚至是一種有效的選擇。Sam Newman認為：『這是一個作為架構風格合理的 預設選項(我欣賞這句話) 』，換句話說，我也認為，面對架構選擇，人們應該尋找一個能被說服使用微服務的理由… 微服務架構 我們很久以前就談過微服務，但到底什麼是微服務? Sam Newman在書中，對微服務的核心概念做了說明，我覺得包含幾個重點: 可獨立佈署：微服務的每一個單元應該能夠單獨部署，而不需要依賴其他服務。這種可抽換性使得應用程式更加靈活，可以更快地部署和更容易地維護。這也意味著， 當你抽換一個微服務、另一個微服務不該受到影響。 圍繞著Business Domain塑模： 每個微服務都應該圍繞一個具體的Business Domain來設計，而不是根據技術或企業組織架構來劃分 。這種業務驅動的作法使得應用程序更加緊密地與業務相關，並能夠更好地支撐業務需求的變化。(這一點很多公司其實先天就無法做到，參考底下『架構和組織的調整』) 大小：微服務應該要足夠小，以便能夠單獨佈署和管理...

跟以前同事吃飯… 這位朋友在幾年內，從公司的副理升到副總，最近買了新車，讓人挺羨慕的。 本來吃飯只是閒聊技術問題，席間不知道為何，談到目標設定。這主題我在上敏捷課程時，多多少少也有涉獵，看他這幾年事業突飛猛進，我不禁好奇地問，他對目標設定的看法，我心想 : 會不會還有什麼我還不知道的秘訣? 朋友說：『首先，目標設定要明確。』我心裡想，這個自然，這我很清楚。 因此我說：『要有時間、有數量、我上課時也這麼跟學員說。』 『對，就像你若是跟上帝禱告要有錢，但什麼叫做有錢呢? 每個人都有錢啊，一塊錢也是錢。你要很清楚地寫下來，你要多少錢?』他說。 我心想：『恩，有時間，有數量、雖然感覺很容易，但這一關其實很多人已經做不到了。白紙黑字寫下來，確實是有力量的。也能夠幫助自己認真面對和思考。』 他接著說：『不管是個人還是我的團隊，我都是這樣做的。一般來說，一定會有一個數字，例如今年要賺多少錢，存多少錢之類的。』『幾年前我換工作時也是，希望不要距離太遠…那多遠? 幾公里，我就寫下來，然後開始找這個距離以內的所有公司…』我聽得嘖嘖稱奇。 我繼續追問: 『就這樣? 還有其他秘訣嗎?』 『沒有啦，只剩…』他語帶保留的讓我好奇，我立刻追問『甚麼秘訣?』 朋友說 : 『寫下來具體目標之後，每天早上起來就看著大聲唸。』 『啊?』我有點不相信：『真的嗎?你每天都有唸?』 他有點不好意思的說：『呵，也不是每天啦，但…一年365天大概也有300天吧。』這回換我訝異了，其實即便只是300天，也很不可思議。 他說，大部分人即便訂了一個清晰的目標，結果卻還是沒做到。常常因為他們都『忙到忘了』。我們每天生活中有太多太多的雜事，和『看起來重要』的緊急事項，如果你沒有每天唸一次自己當初訂下的目標，常常很容易忘記哪些才是你真正重要的。 這個做法其實很簡單，我也跟很多人分享過，然而大部分人都不會真的去做。但是我覺得，它對我幫助很大… 『每天唸?』…這倒是我之前沒有做到的事情。 我心裡開始想…明確可量測的目標、有時間、有數量，這些我早就有做到，沒問題…但確實，我還是常常因為其他看起來更重要的緊急工作，打亂了一周甚至一個月的規劃。讓自己忘了已經訂好的目標，在努力的事情上走偏了。讓自己忙的焦頭爛額，卻把時間花在當下看起來重要，但對整體目標不痛不癢的事情上… 每天唸，其實就是校正羅盤的方向...