我是稱職的顧問嗎?

來集英已經快兩年，但...究竟我是不是稱職的顧問?

from gelis 技術隨筆- 點部落 http://ift.tt/1PUNsF6

留言

張貼留言

這個網誌中的熱門文章

AI 時代的軟體架構設計的進化之路

圖片
目錄 前言 當程式都是 AI 撰寫的、軟體架構設計還重要嗎？ 到底什麼是軟體架構設計？ 所謂的『變』與『不變』的部分 軟體技術架構的本質 AI 時代的軟體架構師的角色與定位 結語 前言： 現在 AI/GAI 各式工具如雨後春筍般湧現，現在早上一起床，腦子便想著 AI 世界又有什麼新的新聞/變革？又有什麼新的 GAI 工具誕生？哪一個工作要被取代了？開發人員又有什麼新的東西要學習？現在的開發人員的壓力真的很大，AI 對世界產生的衝擊，似乎軟體開發人員最首當其衝的感覺！？甚至我的岳父，上個月有一次來家裡玩，看到我都順口問我：對了，最近那個 AI 的出現，對你們的工作有沒有影響啊？？.. 這我..哈哈，我的岳父其實對這領域是個大外行，連他老人家都聽聞此訊息與消息，證明 AI 席捲世界並非空穴來風、各行各業都受衝擊、與影響，影響程度多寡、有些只是現在進行式、有些還在觀望，有些還在堅持著硬撐著、看似沒什麼改變，日常仍舊是日常、生活還是要過，話雖如此，了解 AI 的發展趨勢，與 AI 對軟體開發的影響，對於各行各業、甚至對我們軟體開發者來說，這是個終究必須要面對的重要課題。 當程式都是 AI 撰寫的，軟體架構還重要嗎？ 最近市場常常會拋出一些問題出來，像是：軟體工程師終將被取代、〔資訊科系不再吃香，該系畢業生何去何從？〕、〔寫程式的門檻大幅降低，麻瓜都可以寫扣！〕 圖（一）、使用 Claude 撰寫的線上五子棋小遊戲 最近，曾經撰寫程式碼不假於它手的我，漸漸地開始使用 Cursor 或是 GitHub Copilot 之類的 GAI 工具來幫助我撰寫程式碼，我也發現就算我程式撰寫的再快，也快不過 AI，尤其是 LLM 的模型像是先前 Codex 或是增強的 GPT-4、4o、o4-mini 或 Claude Sonnet 3.7/4.0 系列的 Anthropic，撰寫一套五子棋小遊戲是出乎意料的快，然而，你必須知道，此需求屬於不複雜（雖然本身具備演算法、但大家對於五子棋的理解大致上一致） + 所以可算需求精確 + 網路上的現有程式碼邏輯清楚 + 線上現有資源豐富，所以當然撰寫速度自然飛快，但是，在封閉的企業端，軟體設計大都來自商業與市場需求，需求來源大都都為『口述』、某些實際使用者（人類）的想法，加上，執行還多為企業端自己建置的伺服器 + ...
閱讀完整內容

什麼是 gRPC（二）- 來撰寫第一個 Hello World 吧！

圖片
前言 上一篇 什麼是 gRPC ，筆者大致介紹了 gRPC Service 的基本概念，這一次，我們就來小試一下身手，撰寫一個 Hello World （迷之音：嘗試新技術時，總是得先來一個 Hello World ～我不想違背這良好傳統阿阿阿阿） 使用環境 Visual Studio 2019 .NET Core 3.0.100-preview3-010431 開始進行 撰寫 gRPC 除了先準備好基礎環境、選定一種 作業系統／ 程式語言 Language 外、（Framework／SDK／Runtime）等環境備妥後，就可以開始撰寫， (1). 開始撰寫 gRPC 第一步就是先定義 .proto 協議了 上一篇筆者提到，gRPC 的 Server 與 Client 必須使用相同的協議才可進行溝通，一般來說，你應該使用 protoc.exe 編譯器先行編譯過 greet.proto 協議檔，並產出 C# 程式碼檔案後才可繼續，而在 Visual Studio 2019 裡，拜 MSBuild 之賜，已經有人預先寫好 .Target 檔案了 （什麼是 MSBuild ？什麼是附檔名 .Target 檔案可參考： MSBuild .targets 檔案 ） 筆者先撰寫一個 SayHelloWorld 方法如下： 在協議裡，除了在 service Class 撰寫要公開存取的方法外， 必須在提供『傳入訊息型態』、『回傳訊息型態』 ，這邊我先定義兩個 message，一個是『 HelloMyFirstgRPC 』、另一個是『 HelloMyReply 』 在撰寫 proto 協議檔時，建議先決定 message 回傳型態與傳入的型態，那麼 Visual Studio 2019 會有 InteillSense 的完整支援。不得不說 Visual Studio 2019 在 .proto 協議編輯上的支援已經算不錯了。 注意： 一般來說，Visual Studio 2019 會在背景裡自動編譯 .proto 協議檔案，但始有可能不會有任何提示，所以您也可以自行使用命令列工具進行手動編譯，如下圖，若編譯失敗會出現錯誤訊息，如下圖顯示 return 關鍵字錯誤： protoc.exe 編譯器 & 相關 MSBuild Tools 會隨著 NuGet 套件在 Vis...
閱讀完整內容

什麼是 gRPC ？

圖片
圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 ....
閱讀完整內容