uv 是 Astral 公司推出的一款基於 Rust 編寫的「 Python 套件管理工具 」，雖然 Python 的套件管理生態內已經存在多種工具如 pip 、 poetry 、 conda 等等，但 uv 還是有出色表現，由於使用 Rust 進行編寫，uv 工具的速度讓人驚艷 ；且從「 安裝管理 Python 版本 」、「 虛擬環境建置」、「 package 依賴 」以上 uv 全部都統整好了，其目標是取代多種現有工具，為 Python 專案的開發和管理帶來了新的選擇。 uv 也成為 Astral 公司繼 Ruff (Python 程式碼檢查器和格式化工具) 之後，另一個知名的專案了。
前段時間發現自己對 Python 的 Iterable、Iterator、Generator 之間的差別並沒有很熟，我們都知道這些的共同點是均可使用 for loop 來遍歷。再進一步思考一下所謂的
for-loop是怎麼實現呢： 首先用最簡單的 list 來說明，因為有 index 標示位置，故可以指定位置拿出來，蠻符合 for-loop 的使用直覺 ; 但是 dict 也是可以用 for loop 走訪呀，而它並不存在順序 ; 甚至 open 的 file 都可以用 for loop 結構來讀取每個 row ，那為什麼這個也能用 for-loop 呢？ 這背後有兩個核心概念： Iterable(可迭代對象) 和 Iterator(迭代器) 。當我們了解 Iterable 和 Iterator 之後，就可以進一步來了解 Generator ，同時再來把這三個做一個比較整理。
在軟體工程中，有蠻多工作都會需要排程的，而 Linux 排程可透過 crontab 與 at ，而這兩個有啥異同呢？ 我們可以發現工作排程的方式基本上分成：
- 例行性的 : 每隔一定的週期就會需要處理，那就可以使用
rontab這個指令設定的任務循環- 突發性的 : 會訂一個時間點執行，但做完以後就沒有了，那就可以使用
at指令處理僅執行一次就結束的任務Cron 是 Linux 系統下的一個定時任務管理服務，為了要精確表示「何時」執行， 就發明了一個抽象的 Cron 表達式，相信大家都有看過類似
0 12 * * *這種在定時任務中常出現的寫法，像 「 GCP Cloud Scheduler」、「 GitHub Actions」、「 SpringBoot 的 @Scheduled」，都以 Cron 表達式來定義任務觸發時間點。
影音串流已經融入現今生活中，OTT (Over-the-top media service) 此類利用網路來提供影音內容的服務平台也非常普遍了(如 Netflix 等等)。使用者只需有穩定的網路連線與播放裝置，即可在線上隨時收看影音 ; 而內容提供者不需擁有大規模的硬體設備就能將影音內容放置於網路上。自己對於這技術大部份的專有名詞都還有蠻多不了解的。例如說「 MP4 」、「 1080P 」、「 H.264 」 等等，這些名詞基本上都看過，但實際上對於其定義是蠻模糊的，而更進階的 Streaming Protocol (串流協議)，在讀相關資料有也些蠻多名詞冒出來的，以下就把我認為對影片處理需要知道的事情，其資料簡單整理一下。
之前有介紹了 Message Queue 和其常見協定 MQTT 、 AMQP ，而 RabbitMQ 就是一款基於 AMQP 訊息傳遞協定實現的輕量級開源服務，由 Erlang 語言開發，能夠跨進程的傳遞訊息，且對多數主流程式語言如 Python、Java 等都有官方或社群開發 lib。
再來為了方便運維與監控，RabbitMQ 有內建一套 Web 介面，使用者可透過此介面管理檢視 queue 健康狀態，還可以處理使用者權限等操作
為了要把系統架構解耦，改為異步分散式處理，有時會決定使用 Message Queue 的設計來達成目標，其指的是應用程序之間通過在 Message Service 而不是直接調用彼此通訊。對於其落地的產品，常見的開源工具有 Kafka、RabbitMQ 等等或者雲端服務 GCP-Pub/Sub 和 AWS-SQS 等等。作為兩個子系統之間的通信中間層，會需要依靠協定保持有序且有效率的方式實現資訊交換，而目前廣泛使用的協定有 MQTT 和 AMQP ，以下也會簡單介紹一下。
安裝完 Git 之後，可以使用
git configCLI 取得 Git 設定組態參數，git config 是一個記錄了 git 操作的所有基本檔案資料。 比方說 :
- git init 創建時預設的 branch 名稱
- 寫 git commit 的顯示模板
- 當 push github 時的使用者資料
等等設定都可以在 git config 中調整修改。而在不同專案中，可能需要使用不同的 Git username 和 email， 例如個人專案中想使用「私人 Email」 ; 而在公司專案中則需要使用「公司 Email」，若每次切換專案時都要手動更改 Git 配置會十分麻煩。 這時 Git Include 可以根據資料夾自動套用對應的用戶設定，而無需每次手動調整。
軟體開發有許多的已經定義的管理工作流程，例如說 Git Flow、Github Flow、GitLab Flow 等等，而這些共通點是都以 Branch 來區分不同階段的開發狀態 ; 在研發過程中，也經常需要在不同的 Branch 之間切換來處理不同的任務。這時
git worktree就很大程度派上了用場，它可以讓同一個 Git Repository 同時擁有多個工作目錄，且每個目錄綁定不同 Branch，各個工作樹之間是互相獨立的。這樣就不用在「 code 寫到一半 」時，遇到臨時需要切換到不同的分支作業，卻因為「 正在更動的檔案 」與「 目標分支上的檔案」有衝突而要另外處理，故
git worktree很適合拿來處理緊急 hotfix 或者另外的 code-review。
在現代開發環境中，熟練掌握各種工具的快捷鍵能顯著提升工作效率，本筆記整理了自己常用開發工具的基礎操作與進階快捷鍵，幫助更高效地進行開發工作。由於自己現在開發主要環境都是使用 mac os，所以快捷鍵會以 mac 的鍵盤配置為主，筆記會列出的重點工具為 :
MacOS TerminalVisual Studio Code (VSCode)Vim然後可能也會補充一些
Windows PowerShell和IntelliJ IDEA。在日常開發中可有意識的多使用快捷鍵來加深記憶，若遺忘時這裡可以快速查看筆記，鞏固快捷鍵的知識。
雖然使用了 Git 作為版本管理工具，但每個人對於分支的認知可能不同，故造成每次 commit 到不同分支之後，要合併要回哪個分支可能會有歧義，這時就可參考一些已存在的 Workflow 規範，只要團隊遵守這樣的 branch 的 commit 和 merge 規則，就可以有一致性。
每個 Workflow 規範都不太一樣，常見有: Git Flow、GitHub Flow、GitLab flow ，主要都是希望就算 Project 越來越大協作人員越來越多，也能有效管理 Git Branch，那這邊會以 GitHub Flow 為主要說明，但也會筆記分析了解其他不同策略的優缺點。
