Google CyberSecurity Professional Certificate
筆記參與 Google CyberSecurity Professional Certificate 完成課程與取得證照的學習心得。
筆記參與 Google CyberSecurity Professional Certificate 完成課程與取得證照的學習心得。
筆記如何使用鑑識工具操作與進行證據追蹤分析 😮 但其實就是基本的 Email, IIS Logs 以及 Windows Events 分析,以及綜合上述的 Logs 資訊來判斷作業系統是否有遭受到惡意入侵 😉
介紹關於 DevOps 的入門知識與概念,說明 DevOps 工程師與相關的工作內容是什麼,並討論 DevOps 所要追求的文化、精神、價值以及實務的方法與工具使用。
筆記滲透測試的步驟與使用工具,彙整各式的滲透測試工具與方法,綜合而成能夠自我實作的滲透測試步驟,在請滲透測試專業公司進行之前,能夠先以最少的費用來得到報告。
從 DateType 屬於 Value Type 這個事實進而探討 Struct 與 Class 的差別,以及 Value Type 與 Reference Type 的差異所在。
筆記 C# Null Conditional Operator (Null 條件預算子)的使用方式,讓處理物件的 Null 檢查上更為方便(此語言特性為 C# 6.0 所加入)😎
因為業務的需要自主準備 DA-100 證照,參考之前準備AZ-104 的經驗,以 Microsoft Learn Path 為學習素材,並輔佐 GitHub 上的 Lab 來強化實作。準備本證照最大的用意不是證照本身,而是在攻略各個配分項目的同時,提升自己對 Power BI 的認識與理解 💛
筆記準備 AZ-104 過程中,從 Microsoft Learn 中發現的有趣架構圖與實作課程,作為日後要使用相關雲端服務複習或者架構參考的切入點。
原本規劃今年學習雲端服務的方式,是以開發者所需的 Application 以及 Database Host 的方式來進行。但臨時被安排參加了 instructor-led course 同時有考取證照的要求下,放下手邊原本進行中的任何學習活動,專注在從課前到實際考試當天為期一個月的學習計畫。特別筆記關於 Microsoft Azure Administrator (AZ-104) 證照準備過程中,所參加的課程、使用的資源以及備考的策略。 Medium 閱讀版本
將近三週的時間,將近完成重溫進度的 90 %,在最後 Summary 各模式的回顧並且筆記書中所提及的 OOP 原則,並紀錄書中尚未詳細介紹的模式,留待之後繼續實踐。同時也謹記書中最後的提醒:設計模式作為一種在一般性的情境、目標與解決方案下所被發現的結構,模式的使用並不是絕對與唯一,模式背後的 OOP 原則如果就能夠精準且保有彈性的解決問題,未必要加入模式讓專案變得複雜。 之後的學習規劃不以模式本身為主,而是進入 MVC 的框架,從框架的原始碼中發現設計模式,用設計模式理解 MVC 框架,讓兩者相輔相成。
為了要讓自己能夠更熟悉 C# 的語法特性,決定複製自己學習 Python 的經驗,在 Codewars 上專門以 C# 來解決 Kata (題目),並從社群的 Solution 反饋自己值得學習的語法特性並整理成重點筆記。
外觀模式就是將眾多的類別 (整體系統中的一部分,例如整體是播放電影系統與系統部分類別則包括電視機、擴大機、音響、電腦的關係) 利用合成產生一個外觀類別,並令 Client 與外觀類別互動,取代 Client 直接與眾多的類別互動,有使用類別 (表象模式) 封裝類別 (系統的部分) 的概念。
狀態模式和策略模式師出同門,兩者在 UML 的表示上有相同的結構,同樣是利用執行期實作相同介面的不同類別的方法,以多型的方式精簡原本需要用 if else 邏輯來控制的程式流程。兩者的關鍵差別在於使用上的意圖,狀態模式是將物件的狀態封裝為類別,並藉由類別的轉換從而多型地調用方法;策略模式則是在執行期使用依據實作相同介面的不同類別,使用其專有的演算邏輯並避免掉繼承關係所衍生的維護困難。
合成模式就是將類別建構為樹狀的關係,於是樹資料結構的階層關係、遞迴走訪便可以運用在設計系統上。同時合成模式可以與反覆器做結合,客製出強大的類別,保持新增的彈性同時也兼具走訪的便利。
反覆器已經被實踐在許多當代的語言之中,作為集合類型的低階類別所使用。以往並沒有特別感受到 Iterator 的美好,只覺得高階的語法 (python) 方便好用,而有時候得到物件回傳 Iterator 反而不知所措 (例如 Beautiful Soup)。但重溫反覆器模式後,才曉得作為底層的反覆器有多重要,同時理解它也有助於自行實踐整合不同型別的集合類別進行迭代。
轉接器模式常與表象模式進行比較,從使用上的觀點來看,前者是為了將類別能夠配合多型的方法使用,將目標類別以介面的方式,實作一個轉接器來轉換被既有的類別來達成;表象模式則是將龐雜的類別包裝成簡易的介面,讓使用者與龐雜的類別保持低耦合、最小知識,同時易於使用。
命令模式、外觀模式,乍看之下有些相似,但從模式的意義上的分別兩者就可以感受到不同。命令模式是將命令(要求、需求)封裝成物件,並且讓接受命令者與命令的執行職責拆分,類似餐廳點餐從老闆邊接受客人點餐、邊準備料理分為餐廳前台與餐廳後台,同時命令模式可以將命令與執行時間分隔,延後或者指定執行命令的時間;外觀模式則是將繁雜的類別方法,透過一個簡化的控制類別封裝複雜的演算邏輯,對使用者而言僅需要一個方法就能完成所有關聯的步驟。
工廠是物件實體化的工廠,在實體化衍生類別的時候,如果演算邏輯相當複雜或者有改變的需求,可以將其抽出,依需求的情境分別以最基本的簡單工廠包裝生產邏輯,進階的將生產的方法以衍生類別包裝實作,以工廠方法時做,或者更進階地將相同主題類別加以包裝,並以蘊含工廠方法的方式多型地完成生產的工作。
以前第一次看到 Python 的 Decorator 時滿滿的黑人問號,後來有機會接觸裝飾者模式才豁然開朗,但也沒有深究,甚至沒有真的用過 Decorator。但最近重溫才發現其實裝飾者模式和 Python 的 Decorator 並不是完全的等號。Python 的 Decorator 更像是一種語法糖,利用 Python 函式 first class 的特性,能夠有更方便包裝函式的語法,可以為函式前後加入邏輯並且重利用程式碼。而要利用 Python 的 Decorator 也可以實踐 Decorator Pattern ,只是兩者並不是相等的,一個是語法模式,但背後有 Pattern 的精神;另一個則是 Pattern。
設計模式不會讓直觀上開發速度變得更快,反而在開發時會需要夠多的時間進行思考,然後才動手。但它的效益應該是當要維護、要擴充時,才能夠體現的,因為有良好的設計模式,程式碼的架構是充滿彈性且易於回應需求的,相較快速完成的架構可能缺少擴充的彈性,在面對需求時只能砍掉重練,或者是提心吊膽的修改程式碼害怕牽一髮動全身。無疑地如果在有需求變動的情境,使用設計模式先苦後甘是最好的選擇。
設計模式是很需要開發經驗來輔助學習的,一兩年前就曾經翻閱過這本書,只是當時對物件導向的體會仍是懵懂,而僅有物件導向的知識也無法自然的學會設計模式的使用,因為設計模式需要程式開發的經驗累積,在開發中必須實際使用物件導向,同時需要對話、討論,並且實際體驗過擴充、維護的痛楚,才能歸結出設計模式。而直接學習設計模式儼然就是快速增長物件導向的設計功力,但也因為缺少了實際感受到設計模式美好的過程,所以學習容易流於浮光掠影的記憶。 這次的學習除了閱讀本身,更強調實作,除了重新詮釋閱讀素材的案例並改寫成 C# Code外,也將模式前後的差別書寫成部落格,期待讓學習更深植腦中,能夠設計模式真正的成為自己的一部分。
一陣子沒有用 Python ,會使用的機會大多是用來編輯 Scripts 或者作為資料的 ETF 用途。而每當要 ETF 的時候都會回憶起 Stata 的便利,肌肉隱約就可以呼喚出各式操作資料的指令。只是離開學術環境後就不再使用過 Stata,取而代之的是 Python 的 Pandas ,儘管指令上兩者有著極大的差別,但因為 Python 有著更多更方便的 Library,同時語法上也更適合寫 Scripts,何況還是 OpenSource 的,既然如果也沒有什麼好念舊的,認分的學習 Pandas吧。
## 使用的情境 如同學習 Gulp 的經驗,直接用需求情境的方式學習新工具是最有效率的,因為情境的需求是與自己切身相關的,而非代入生冷的範例。 1. 創造屬於自己的情境 2. 跟著情境實際操作 3. 將技能融入自己的日常作業流程
Git 是一個實用的版本控制工具 (VCS, Version Control System),在程式開發的過程中經常有回復特定版本檔案、正式版與測試版分隔等需求,而如果只靠在檔名加註日期、資料夾區隔等方式,或許在簡單的專案與個人的開發環境還能夠勝任。但如果專案的歷程較為複雜以及多人共同開發時,好用的版本工具能夠讓繁瑣的工作井然有序。