NW Pie - 老吳的技術探索 Blog

 最近公司使用 AWS Lambda Function 來當基礎服務, 而且越用越多。我也呼應寫了一個 AWS Lambda Serverless Web API, 還加碼寫一個 Client Package 來打這個 API (對, 只有一個 .cs 檔案幫忙做 HTTP Request ...)。但由於 HTTP 回應實在太慢了, 我決定稍微做個併發 Request 測試, 花了些時間, 但大家應該 5 分鐘就可以知道結論了 : 一定要避免 冷啟動 (Cold Start) 問題 ( 6~8 秒才能回應, 不管 Request 方是在 AWS 環境內還是外) 若機器全數在 AWS 雲內, 可得到平均回應 51 ms ~ 61 ms, 還算行 (畢竟我們已經獲得 Lambda 開發與佈署的好處了) 若需要最穩健快速的 Server 回應體驗, 就別用 Lambda 吧 (一般而言, 應該也沒有冷啟動問題了) 疑 ? 好像只花了不到 1 分鐘 ! 前置準備 用 AWS Lambda Serverless for VS 模板寫一隻 AspNetCore API, 一鍵佈署到 AWS, 並獲得一個 API Gateway 的 Public HTTP 網址 測試工具可以抓  Netling , 是用 AspNetCore3.0 寫的, Git 下載, VS 編譯並執行看看 當然, 要有 NetCore 3.0 Runtime 環境 測試腳本 設計情境: 2 個 Threads, 併發跑 10 個 Requests .\Netling.ConsoleClient.exe https://{xxx}.execute-api.us-west-2.amazonaws.com/{xxx} -t 2 -c 10 外網機器發動請求 (測試程式不在 AWS 雲內) Run 1 ( 冷啟動 , Max: 6191 ms, Min: 153 ms) 10 requests in 10.86s     Requests/sec:   1     Bandwidth:      0 mbit     Errors:         0 Latency     Median:         541.385 ms     Std

為什麼要發明 HTTP ? HTTP 是全球資訊網 (WWW) 的資料通訊的基礎 ! 「全球資訊網」就是 World Wide Web, 就是大家熟知的 WWW, 而 HTTP 就是為了能夠讓資料在這個網際網路流通所訂定的通訊協定。我還有印象, 大學教授曾說中國的狼煙就是最早的通訊協定; 透過煙的顏色, 數量, 來告知遠地的人信息, 把網際網路擴大解釋, 中國是鼻祖 (疑?)。 HTTP 是全球資訊網 (WWW) 的資料通訊的基礎 查詢到「UCLA 舉辦了網際網路的30歲慶生會」這個標題時間是 1999/09/12, 才知道網際網路已經發展將近 50 年了 (1969 ~ 2017 截稿)。 1969 年, 網際網路 (Internet) 之父, 美國 UCLA 教授 Leonard Kleinrock 將 UCLA 與 Stanford 兩個實驗室的電腦, 試連成功 1971 年, Internet 首度連到美國以外地區, 如英國、挪威 1973 年, TCP/IP 通訊協定被提出 1984 年, 美國國防部將 TCP/IP 作為所有電腦網路的標準 1990 年, 英國的 Berners Lee (瑞士粒子物理實驗室) 成功的提出與開發了全球資訊網 (World Wide Web)，被稱為「WWW 之父」 1991 年, Berners Lee 在瑞士歐洲核子研究組織建立了 HTML、HTTP 1990 年 ~ 1999 年間, 網際網路風靡全球, 直到 2000 年網路泡破。 2016年, 有個有趣的事, 美聯社認為「網際網路」已和「電話」一樣成為一件一般的事物, 不具有專屬商標的意義, 於是開始在其格式手冊中規定「internet」和「web」一詞全部小寫, 紐約時報也隨後跟進。今年已經 2017 了, 記得 i 跟 w 都要小寫 ! HTTP 是 TCP/IP 的應用層協定 HTTP 不管從網路 OSI 模型 7 層, 或是 TCP/IP 4 層來看, 都是基於 TCP 層 (傳輸層) 與 IP 層 (網路層) 的應用層, 但事實上只要符合 HTTP 的 RFC 標準, 是可以基於其他傳輸方式來溝通的。參考  wiki  整理下表, 可看出 HTTP 與 TCP/IP 的相對層級。

將 ASP.NET MVC 的 Controller 資料要傳給頁面, 或是頁面再轉只給其他頁, 有很多方式, Data Passing Mechanism in MVC Architecture  對於不同的資料拋轉方式整理出非常明確的結論, 在開始介紹代碼之前我們先有基本認知 : 在 ASP.NET MVC 中, 沒有 view state, 沒有 code behind, 沒有 server controls。我們仍需在 MVC 架構中傳遞數據, 有一些機制來傳遞數據如下, 如ViewData, ViewBag, TempData, Session。 ViewData ViewData 是 ControllerBase 類的 property ViewData 用於 Controller 將資料傳遞給對應的 view (Controller to View) ViewData 生命週期只存在於當下的請求, 導頁後就被清掉了 (null) ViewData 是 Dictionary 類別, 繼承 ViewDataDictionary 纇, 要注意字典資料轉型跟 null 問題 Example - ViewData["Key"] = "Value" ViewBag ViewBag 也是 ControllerBase 類的 property ViewData 操作方法須對每個資料使用中括弧, ViewBag 簡化為點運算式 ViewBag 基本上是 ViewData 的包裝類別, 也是用於 Controller 將資料傳遞給對應的View (Controller to View) ViewBag 是 C# 4.0的 dynamic 型別, 可在執行期再判斷真正型別 (C# reflection) ViewBag 生命週期也只存在於當下的請求, 導頁後就被清掉了 (null) Example - ViewBag.Key = "Value" TempData TempData 也是 ControllerBase 類的 property TempData 生命週期除了當下請求, 導頁後仍可續存 (如action to action, controller

這是經典的概念題。要寫出能動的程式很簡單, 要去解釋背後的記憶體管理運用原則, 還是需要一點時間內化。而且不知道為什麼, 一般的軟體工程師跟架構師來說這兩個詞, 那個講起來那個味道就是不太一樣, 有時候面談別人時, 還會覺得有些求職者有獨到的見解。 簡單來說, 從記憶體配置的角度, 用一個二分法 stack 用於靜態記憶體配置, 大陸翻譯為棧, 棧, 棧 (why ?) heap 用於動態記憶體配置, 大陸翻譯為堆 抱怨一下, 堆跟棧我一直覺得命名混亂, 用 Google 翻譯也會發現 stack 跟 heap 都翻譯為堆疊的「堆」, 連 Google 都搞錯了, 所以後面還是用英文來說吧。 這張 All-in-one 的圖是我目前最喜歡的圖像解釋, 來源是  Six important .NET concepts: Stack, heap, value types, reference types, boxing, and unboxing  : 首先記得這個範例, 圖片是由上而下逐行介紹, public void Method1() { int i = 4; //Line1 int y = 2; //Line2 Class1 cls1 = new Class1(); //Line3 } 總結是 : value type 的變數, 包括指標變數會放在 stack reference type 的變數 (如 string, object) 本身也會放 stack, 然而他的值 (value) 則是放 heap box 就是 value types to reference types 的過程, 所以 value 會被放到 heap 中, 而產生一個 object 變數來指向這個 value, 變數指標則是在 stack unbox 是  reference types to value types 的過程,  所以原本 object 所指向的值 (heap 中) 會被複製到 stack 中並賦予明確 value type 型別 深入 Stack 現在回到最原點, 我們略懂 stack 與 heap 的區別了, 但還是沒有一個「感覺」對不對 ? 因為我們不懂 why。我個人建議有空可以 K

類別、介面、抽象這些詞, 應該算是物件導向的基礎知識, 但由於他有一點抽象, 很多人還是覺得跟他們有些距離, 解釋也不一定到位。面試時大家又很愛問, 似乎想要知道你對物件導向的認知到哪邊。小弟有幸在 10 年前參加公司的讀書會討論這兩本書 :《物件導向設計模式 - 可再利用物件導向軟體之要素》與《Effective C++ 3/e 中文版 - 改善程式與設計的 55 個具體作法》看完之後雖然還是沒有具體答案, 但肯定直到現在都有一個「物件導向感覺」的。 以下請謙虛參拜。 Object 物件 《物件導向設計模式》 物件導向程式是由物件所構成。物件將資料和可施於其上的程序包裝在一起, 此處的程序通常較作 method 或操作 (operation)。當物件收到客戶端 (client) 送來的要求 (request), 或稱為訊息 (message) 時, 就會執行對應的操作。 訊息是唯一可令物件執行操作的管道, 操作則是唯一可改變物件內部狀態的管道。有了這些限制, 物件內部狀態可說是被妥為封裝了起來 (encapsulation) : 無法接觸及, 無法自外界窺伺。 Interface 介面 《物件導向設計模式》 介面是物件導向系統的基石。 物件所宣告的每一個操作, 都得訂出該操作的名字、參數、回傳值, 也就是該操作的外貌簽名 (Signature)。所有已訂定的物件操作之 Signature, 稱為此物件的介面  (Interface)。 物件的介面, 界定出能送給此物件的訊息類型; 只有符合物件介面的 signature, 才能送給此物件。想辨識物件, 只有靠介面這條路; 若不知道介面, 便無從得知物件的資訊, 也無法叫他做任何事。物件介面並不含任何時做事項 — 物件有權自主決定該如何時做這些操作。 兩物件即使介面完全一樣, 也可能會有完全不同的實作。  《Effective C++》 對於其他語言轉換至 C++ 陣營的程式員而言, 另一個可能造成困惑的術語是介面 (interface)。  Java 和 .NET 語言都提供 interfaces 為語言元素, 但 C++ 沒有。當使用術語「介面」時, C++ 通常談的是函式的簽名 (signature) 或 class 的可存取元素 (如 cla

任何「生命週期」的探討都是一門學問,  ASP.NET MVC Life Cycle 的官網以及網路文獻也很多,今天找到一個淺顯易懂的版本  ASP.NET MVC - Life Cycle 。 他將所謂的生命週期分兩個來探討, 然後再配上圖片 : The application life cycle The request life cycle Web Application 的生命週期是起於 IIS (或其他 web server) 運行應用程式, 終止於服務暫停, 回收或關閉。但細部的 process 是: 當第一個請求發出時, 觸發 Application_Start() 事件 (Global.asax.cs 文件中), 做應用程式初始配置、路由設定等等載入工作。但當 web 服務器回收應用程序或在一段不活動狀態 (InActive) 或超過 cpu、memory 閾值之後, Application_End() 事件將觸發, 接下來的請求將被視為第一個請求, 並且再次觸發 Application_Start() 事件。 request 比較複雜, 但對 MVC 有概念的人大方向應該可以抓出一個順序: request → routing → controller → action → result → response。 提醒兩點, 應該有看到一個 Controller Intialization ? 順便分享一下, 過去曾有專案有效能問題, 結果是 Controller 建構子做了一些 AutoMapper.Attributes 的 mapping 動作, 天真以為他只會初始化一次。但 sorry, 是每一個請求都會進入構造函式, 這邊慢, 大家就一起漫步了。第二點, 不是每個 result 都需要 view engine 處理, 我們也可以回傳一個字串, JSON..., 對吧 ? 所以上圖 Result Execution 才會有兩種處理方式。 System.Web.Mvc / MvcHandler.cs 的  程式碼  也滿值得欣賞一下。是由 IControllerFactory 類來創建 Controller 實體去執行後續動作 : protected internal virtual void Proce

第一版 jQuery 在 2006 年發布, 支持跨瀏覽器。有人會以為 jQuery 是一個 Framework, 但其實他歸類為 JavaScript Library。 wiki 也是這麼解釋: jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML. 寫在前頭, 由於 JavaScript 是很靈活的直譯式語言, 只要在 <head> <script> 參考一隻 js 就完成 jQuery 載入, 但是 1.6 版前後, 有 .attr() 與 .prop() 的差異; 以及 2.0 版以後不再相容 IE 6, 7, 8。有些開發者在維護舊系統時為了避免新舊版本衝突, 在獨立開發頁面載入較新版本, 久了造成單一站台共存 jQuery 版本, 這是非常不具維護性的做法。為了與時俱進, 建議逐漸換為新版, 並配置唯一版本的 jQuery 到 master or layout 頁統一管理。企業內若對 IE 愛不釋手, 就避免追到 1.9 版以後。因為這樣寫其實滿醜的。 <!--[if lt IE 9]> <script src="jquery-1.9.0.js"></script> <![endif]--> <!--[if gte IE 9]><!--> <script src="jquery-2.0.0.js"></script> <!--<![endif]--> jQuery History 縱看 jQuery 的版號跟出版日期, 非常活躍, 發展已經超過 10 年 (2006 ~ 2017截稿), 每年都有一次以上的版本更新, 而且還能保持精簡, Production 檔案大小約在 100 KB 內。 ver release date note 1 2006-08-26 First stable release 1.1 2007-01-14 1.2 2007-09-10 1.3 2009-0