前言 完全不懂 Flask life cycle 我們也可以使用 Flask 建立出一個完整的系統，但是瞭解了之後，我們可以將各種資源的調度放在 Flask life cycle 的各個節點中，這樣可以讓整個系統更有條理，以下內容皆整理自 Flask 官方文件，我也會寫一個範例 Repo 幫助讀者更有效地理解 Flask life cycle。 https://flask.palletsprojects.com/en/3.0.x/lifecycle/ Flask handle request with WSGI server 以下步驟節錄自 Python 官方文件 Browser or other client makes HTTP request. WSGI server receives request. WSGI server converts HTTP data to WSGI environ dict. WSGI server calls WSGI application with the environ. Flask, the WSGI application, does all its internal processing to route the request to a view function, handle errors, etc....

前言 微服務架構設計將單體式架構切成多個小服務，取得開發、部署以及擴容方便的優勢，今天將會簡單比較單體式架構與微服務架構，並且列舉出微服務架構中的元件，透過這些章節好好學習微服務架構。 單體式 vs 微服務 開發階段 單體式: 於開發初期具有開發快速的優勢，但是隨系統越來越複雜，在多個人員協作的狀況下，將會提高溝通成本，延緩開發速度。 微服務: 於開發初期需要更多的系統設計時間，但是在各個功能單純的微服務中開發，可以加快開發人員的開發速度，降低維護難度。 部署階段 單體式: 每次的新版本都需要部署一整個完整的系統，在編譯、測試、部署上都會花費大量時間，但是其中有許多不需要重新部署的元件，相當浪費資源。 微服務: 每一次的部署都是以一個微服務為單元，可以大幅加速部署時間。 維運階段 單體式: 當某個節點出了問題，容易影響到整個系統，無法正常提供服務。 微服務: 某個節點出了問題時，由於我們將多個系統分開來了，所以影響到的部分都是較小較單一的服務，要更新 / 修復都相當快速。 適用場景 單體式: 較為適用在初期較小規模團隊，或是個人開發，需要快速驗證商業價值的場景。 微服務: 適用於規模龐大的系統或是高流量的系統，將龐大的系統切分為功能明確的小單位時，提供了簡單的擴容方法以及有快速的開發 / 部署流程。 微服務元件 以下開始舉例各種微服務架構中會使用到的元件，用於提昇微服務的可用性，提供穩定、高效率的服務 負載平衡器 & 水平擴展 在高流量負載的系統上，只有一台主機負責消化所有流量是不現實的，再怎麼堆 CPU 和 RAM (垂直擴展) 都會有趕不上流量的一天，於是就出現了水平擴展的方式，就算每個人(主機)的力量很小，只要人夠多，就可以應付的來。 水平擴展需要將流量分配到所有主機，不可能手動設定，所以就有了 Load Balancer，透過一定的規則，將流量分發給各個伺服器，這樣就可以達到消化高流量的目的。 相關服務: Load balancer EC2 Load balancer 水平擴展 EC2 Auto Scale Group 訊息隊列 在微服務的架構中，避免單點故障造成的整體故障是一大重點，所以導入了訊息隊列這個元件，訊息隊列透過將請求暫存在一個隊列中，再讓對應的服務去消化掉這些請求，這樣有兩個優點。 平攤流量: 有了中間這個緩衝區，可以避免突發的流量直接打掛一台伺服器，伺服器可以按照他的能力處理請求。 重啟請求: 第二個是當伺服器因為更新或是故障而無法處理請求時，請求也會留在隊列中，只要等到服務回復之後就可以繼續處理先前的請求，避開了剛剛所說的單點故障造成的影響。 但當然得到的不會只有優點，像是如何確保請求不會丟失、不會被處理多次、至少被處理一次都是需要考慮的問題。 相關服務 Simple Queue Service Amazon MQ 結語 透過微服務可以取得許多好處，但同時也帶來了學習成本以及架構設計的挑戰，但是多多學習一定有好處的，遇到不同的場景時可以提出更多的想法以及解決方案。

前言 接續前一篇，這篇是 useCallback，請直接開始閱讀文章！ 官網 文章架構 如上篇，我會按照官方文件的架構，首先講解定義，再用一些簡單的範例講解應該怎麼使用這些 Hooks，最後再講解一些容易犯錯的用例。 定義 用來快取會根據輸入值有不同定義的 function，基本上可以想像成用來快取 function 的 useMemo。 const cachedFn = useCallback(fn, dependencies) 我們可以看到他分成三個部分: 傳入 fn: 傳入一個 function 架構，裡面包含會變動的元素。 dependencies: 用來比較函式是否有變動了的變數陣列。 傳出 cachedFn: 最新的計算好的 function，和其他 hook 提供的一樣都是 read only。 範例 以下是使用 useCallback 的範例。 // ProductPage.js import { useCallback } from 'react'; function ProductPage({ productId, referrer, theme }) { const handleSubmit = useCallback((orderDetails) => { post('/product/' + productId + '/buy', { referrer, orderDetails, }); }, [productId, referrer]); // ....

前言 接續前一篇，這篇是 useMemo，請直接開始閱讀文章！ 官網 文章架構 如上篇，我會按照官方文件的架構，首先講解定義，再用一些簡單的範例講解應該怎麼使用這些 Hooks，最後再講解一些容易犯錯的用例。 定義 用來快取常常需要重新計算的狀態，如果有用過 vue.js 的 computed，應該很容易上手這個 hook。 const cachedValue = useMemo(calculateValue, dependencies) 我們可以看到他分成三個部分: 傳入 calculateValue: 傳入一個 function，用來計算出每次的結果並回傳。 dependencies: 用來關注那些變動了就應該重新計算狀態的變數。 傳出 cachedValue: 最新的計算好的 state，和其他 hook 提供的一樣都是 read only。 範例 以下是使用 useMemo 的範例。 // without useMemo // component need to recalculate todo list, // even props are the same. export default function TodoList({ todos, tab, theme }) { // ... return ( <div className={theme}> <List items={filterTodos(todos, tab)} /> </div> ); } // with useMemo // when props are the same, // component will use cached todos from latest render....

前言 接續前一篇，這篇是 useReducer，請直接開始閱讀文章！ 官網 文章架構 如上篇，我會按照官方文件的架構，首先講解定義，再用一些簡單的範例講解應該怎麼使用這些 Hooks，最後再講解一些容易犯錯的用例。 定義 當元件中具有相當複雜的邏輯，用 useState 會影響你的元件的可維護性，就可以使用 useReducer 來提升元件的可維護性。 const [state, dispatch] = useReducer(reducer, initialArg, init?) 我們可以看到他分成五個部分: 傳入 reducer: 是一個函式，用來定義如何更新 state，有兩個參數分別是 state 和 action，reducer 會透過我們傳入的 action 來更新 state。 initArg: 和 useState 中的 initState 一樣，用來設定一個或多個 state。 init?: 這是用來產生預設 state 的函式，這個函式會被傳入 initArg，用來給 init 函式使用，這個函式回傳才會是最終的 initArg。(可能有點難懂，等等用範例解釋!) 傳出 state: state 就是你儲存的值，一開始會和你的 initArg 是一樣的值，注意這裡和 useState 的 state 一樣都是唯讀的，要改變你的 state 就 dispatch 一個 action。 dispatch: 用 action 來觸發 reducer 更新 state。 範例 以下是一些使用 useReducer 的範例。...

前言 最近正在學習 React，在我學這套框架之前，早就聽過很多人被 Hooks 搞得一個頭兩個大了，於是決定一邊學習一邊把重點寫下來，避免我之後又突然忘記了 XDD 官網 文章架構 這篇會按照官方文件的架構，首先講解定義，再用一些簡單的範例講解應該怎麼使用這些 Hooks，最後再講解一些容易犯錯的用例。 定義 … 範例 … 易錯用例 … 定義 第一個是 useState，用於簡單儲存元件中的狀態使用。 const [state, setState] = useState(initialState) 我們可以看到他分成三個部分: initState: 預設狀態，就是這個 State 的預設值。 state: state 就是你儲存的值，一開始會和你的 initState 是一樣的值，注意所有 State 都是唯讀的，要改變你的 state 就使用 setState。 setState: 用來改變 state，由於 React 採用的是單向資料流，不像 vue 是雙向資料流，可以直接更改 state，所以要透過 setState，告訴 react 你改了這個 state，請幫我更新到畫面上。 範例 以下是一些使用 useState 的範例。 import { useState } from 'react'; function MyComponent() { // init const [age, setAge] = useState(28); const [name, setName] = useState('Taylor'); const [todos, setTodos] = useState(() => createTodos()); // usage // age: 28 // handleAgeChange(30) // age: 30 const handleAgeChange = (newAge) => { setAge(newAge) } // name: 'Taylor' // handleNameChange('John') // age: 'John' const handleNameChange = (newName) => { setName(newName) } // todos: [{todo1}, {todo2}] // handleTodosChange({todo3}) // todos: [{todo1}, {todo2}, {todo3}] const handleTodosChange = (newTodo) => { setTodos([....

前言 Ionic 使用的是 Capacitor，是一套可以用來將打包好的網頁包成 App 的工具，這篇將示範在 m 晶片的 MacBook 上測試編譯 ios 版本的 App，另外這篇會提到一下我編譯過程出現的問題，如果照著這篇有問題可以參考看看。 文件參考 這篇會用到以下兩篇官方文件 環境準備 建置流程 步驟 編譯環境準備 為 Ionic 專案安裝 capacitor 在專案中加入所需系統 ios / android 打開 xcode / 使用 capacitor 指令測試 Step 1 - 編譯環境準備 由於先前就有大部分要求的編譯環境了，所以這裡我會簡單帶過。 Node.js : 官網 到官網下載 mac 版 Node.js，像一般應用程式安裝方式。 homebrew: 官網 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" CocoaPods: 官網 也可以用 gem(ruby package manager)，但這邊推薦用 homebrew 安裝，因為用 gem 安裝在apple silicon mac 上安裝會有架構問題，需要另外疑難排解。 brew install cocoapods Xcode & Xcode Command Line Tools: App store 到 App store 下載 Xcode，安裝完之後因為預設不包含 Xcode Command Line Tools，需要輸入下列指令安裝。...

前言 由於專案用途需要使用到 Ionic 這個框架，這個框架可以用前端三大框架 (Angular, React, Vue)為基底進行開發很好上手，所以想把學習的過程做個筆記，這篇會從建立到運行開發環境做個介紹，編譯部分之後再寫XD 官網供參 https://ionicframework.com/ 步驟 下載 Ionic CLI 建立新的 Ionic 專案 在本機測試預覽 Step 1 - 下載 Ionic CLI 先使用 NPM 在全域安裝 Ionic CLI，這會在後面用於建立專案與運行專案使用。 npm install -g @ionic/cli Step 2 - 建立新的 Ionic 專案 輸入下列指令，然後按照 CLI 提供的步驟 ionic start # Use app creation wizard? n # => 也可以選 Y，但就會使用網頁去建立一個新的 Repo # Framework: Vue # => 選擇要使用的前端框架 # Project name: sample-ionic # => 專案名稱，隨便輸入就好~ # Starter template: tabs # 這裡他會給你四個選項，建議第一次碰 Ionic 可以選 tabs 看看一些基本的用法 選擇完各種選項之後，安裝完各種依賴後，專案就建立完成了。...

目的 前公司在上課的時候超常講到 DI 和 SoC，也就是在 Clean Architecture 中最常用到的技巧，但是感覺沒有好好地刻在我的 DNA 裡，在寫自己的專案的時候還是沒能好好實現 Clean Architecture，於是透過 Uncle Bob 的 Blog 來好好複習一下。 供參 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html 優點 Clean Architecture 用了 DI 及 SoC 來將各層切得清清楚楚的，為系統帶來了好測試、好維護、好更新的架構，這就是 Clean Architecture 帶來的好處。 經典圖解 要看懂這張圖要先知道各個圈圈的意思： 藍色-外部服務及工具 框架、資料庫、服務、系統等，從外部獲得的資料源就是最外圈，這層要處理的是如何讓下一層可以看這些外部服務互動。 範例：事先處理好與資料庫的連線，向下一層提供資料庫連線實體，讓下一層可以從資料庫拿取資料。 綠色-介面適配器 (有沒有更好的翻譯…) 從前一層拿到可以和外部互動的實體後，在這層處理好應該怎麼拿到資料，抽象成規範好的資料格式後提供給下一層使用，透過這層不論是用 SQL 或是 NoSQL 甚至是 gRPC 都不會影響下一層如何使用數據。 範例：將 SQL 寫在這層，讓下一層只需呼叫我們指定的方法與參數就可以得到他們想到的東西，如果為了其他考量換了其他資料庫或是資料來源，就只有這層需要變動。 紅色-使用案例 通常透過函式定義如何操作實體(下一層)或是實體之間該如何互動，也就是商業邏輯。 範例：”建立訂單”這個動作，透過操作用戶及產品產生出新的一張訂單，就是這層在做的事情。 黃色-實體 透過建立各個可以表達業務規則的實體或是函式，不會受到外部性影響。 範例：”產品”作為業務規則的核心，從一開始定義好了會有哪些資訊，基本上也不應該不會有太大的變動。 注意事項 解釋完上面的經典圈圈之後，來講一下注意事項。 各層專注處理好自己要做的事，內層不會使用到外層的任何事物，這樣才能更好地把各層切開，也就是關注點分離。 不依賴任何框架、資料庫或是外部服務，永遠忠於自己的商業邏輯去規劃你的系統，這些外部屬性都是基於需求被放進系統中，隨時可以被淘汰替換。 寫好的系統應該要具有很好的可測試性，像是能夠很好的替換別層元件進行測試，如果做不到的話就應該重新檢視是不是哪裡沒有切好。 不只四層圈圈，這四層只是用來說明基本概念，如果要應用於更複雜的系統或是商業邏輯，就根據需求切出更多的層次。 總結 Clean Architecture 提供了方法論，但是要套用到工作流程還是要多實踐幾次，才能夠融會貫通，而不是一知半解。

撰文動機 由於我從 2023/12 開始成為中華民國國軍的一員，下部隊無聊在看 FB 時一直被 DCARD intern 的貼文洗頻，於是決定來好好準備一下，但是問題來了，怎麼在軍中寫程式rrr，於是簡單爬文了一下就有現在這套配置了，讓我好好介紹一下。 以下以 iPhone 作為載體。 所需配件 一台功能正常的 iPhone ios 版本請不要太舊，我使用的是 i11 一個 Lighting OTG 轉接器 只要上面有 USB A 接口就好，推薦可以另外轉接電源線的版本，這樣邊充邊寫不用怕沒有電 一個功能正常且沒有藍芽功能的鍵盤 我帶了我的客製化鍵盤XD 長官的批准，這個很重要！！ 一顆不怕被側目的心 如何實現 這裡分成兩個部分，輸入以及程式執行環境，以下開始教學及疑難排解。 輸入部分 把轉接器接上 iPhone，再把鍵盤接上轉接器基本上就可以做到用鍵盤輸入了。 程式執行環境 這裡分成兩種情境，刷題以及寫專案。 刷題的話很簡單，下載力叩（中國板 LeetCode）就可以開始你的克難刷題之路了。 寫專案的話就會更加克難了，你需要一台 Server 用來當作程式執行環境，再下載手機 SSH App（我用的叫 Termius） 來連接到你的 Server，接下來就和平常一樣可以在 Server 上用 Vim 來寫程式了。 你會遇到的問題 長官不准 這個無解XDD 卡中文輸入法 這個我也還在解決，如果你有任何解法務必在 4/8 前跟我說（這之後我也不需要了XDD） 結語 搞了這套周邊設備比螢幕大的解決方案後，每次寫都覺得很好笑XDD，但是在這樣的環境下反而又找到一開始寫程式那種解決難題的樂趣（十個工程師九個 M），寫得特別起勁XDD。