我是稱職的顧問嗎?

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

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

留言

張貼留言

這個網誌中的熱門文章

DDD 領域驅動設計文章導讀

圖片
DDD 領域驅動設計文章導讀 pictrue from:https://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80 前言 其實我接觸 DDD 的時間並不長，我進行專案工作的時間幾乎 20 個年頭的我，接觸與真的實務應用 DDD 也不過是 2019 年底左右，當時 Containers & Microservices 正盛起，連帶的讓 DDD 的開發方法論在台灣萌芽（雖然 DDD 與微服務沒什麼直接關係、許多是商業炒作）包括微軟在推的 Docker 與 運行在 Cloud/Azure 的 AKS(Azure Kubernetes)等等，都有許多官方 Docs 文件說明著如何運用 DDD 的設計導向微軟的微服務模型、或是『使用 .NET 設計與實作微服務模型』等等，不過當然，這還是沒什麼直接的關係XD 只不過，你要弄清楚的是，DDD 不是萬靈丹能夠解決你將現有系統無痛的上 Cloud 的 Microservices 環境，而是，透過 DDD 的 Bounded Context/Context Map 概念，可以幫助你切割現有單體式系統中服務的商業體系、像是如何切割 Context、各 Context 之間如何(通信 / 溝通) 等等。 以下，我將先前所有撰寫過的 DDD 相關的文章，依照學習上的順序，為讀者們做個導讀。 學習 DDD 其實有些門檻，以下我列幾種情境供各位參考：  一、寫程式 1-2 年、物件導向基礎還在學習者  二、寫程式超過 5 年、物件導向已熟悉（包括：SOLID, GoF Design Patterns）  三、［延伸第二點］也接觸過 OOA/OOD 並有過專案開發經歷過完整分析設計流程 + 抽象化能力（若有接觸過分析階段的 UML 更加分） 四、已經熟悉 OOA/OOD 與 OOP 也具備上述三點條件，並實作過 Clean Architecture 為什麼第三點我要特別提到『若有接觸過分析階段的 UML 更加分』呢？ (1)分析階段的 UML 是什麼？(2)以及為什麼一定要使用 UML？ 我先回答第二個問題，UML 只是眾多分析階段圖形的一種，像是 BPMN, SysML 也都是業界的商業...
閱讀完整內容

什麼是 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 也完全的跨平台。要在 ....
閱讀完整內容

占空間的Google Chrome暫存檔

圖片
在一次使用CCleaner清除系統的垃圾的時候發現，怎麼Google Chrome怎麼有220M的網際網路快取資料？ 這時突然意會到，平時都只記得清除IE的Temporary Internet Files，卻忘了Google Chrome也是瀏覽器，一樣會產生暫存檔案，還有Google Earth產生的暫存檔居然更高達688M… Orz 因此突然間也非常好奇這些暫存的資料夾的路徑到底在哪裡呢？因為我們知道在Windows Vista/7 之後使用者資料已改在c:\Users 的下面，由於IE的是在"C:\Users\gelis\AppData\Local\Microsoft\Windows\Temporary Internet Files" 、所以我想應該也在這裡附近。果然讓我找到了！ Google Chrome : C:\Users\gelis\AppData\Local\Google\Chrome\User Data\Default\Cache Google Earth : C:\Users\gelis\AppData\Local\Google\GoogleEarth\models 可是突然間又發現Google Earth的資料夾居然是空的！這讓我很疑惑，明明掃出688M，究竟這些檔案是在哪裡呢？筆者的求知慾又非常強烈，每當發現問題如果不找出來是不罷休！因此常常熬夜只是為了找一個問題… 後來上Google才發現，原來我找錯位置，Google Earth的暫存資料是存在LocalLow的下面！不是Local的下面，所以路徑應該是如下： C:\Users\gelis\AppData\LocalLow\Google\GoogleEarth 而且是單一檔案"dbCache.dat"，總算解了疑惑 ^_^
閱讀完整內容