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 ，以下也會簡單介紹一下。
在現代開發環境中，熟練掌握各種工具的快捷鍵能顯著提升工作效率，本筆記整理了自己常用開發工具的基礎操作與進階快捷鍵，幫助更高效地進行開發工作。由於自己現在開發主要環境都是使用 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 為主要說明，但也會筆記分析了解其他不同策略的優缺點。
用 Git 來做版本管理時，偶爾會需要撤銷某些操作，但對於已經推上遠端 Github / Gitlab repository 的程式碼，並且該分支已經有多人協作的時候，如果要修正的話其實有蠻多需要注意的事情呢 ; 再來 Git 是有蠻多功能和一些命令的，有時不常用的話也會忘記或者錯估使用場景。在開始筆記之前先把一些名詞定義好，一般來說 Git 的操作會涉及到幾個區域 ：
- 硬碟區 disk : 檔案存放的一般資料夾，也會被稱為 workspace
- 暫存區 staging : 保存
git add紀錄的地方，也被稱為 index- 本地端 git local : 保存
git commit紀錄的地方，也被稱為 repository- 遠端 git remote :
git push的倉儲，如 Github、Gitlab 等等而各個之間狀態變化的簡單關係如下圖所示 :
我們都知道 Python 是一個動態的語言，代表每一個 variable 是什麼型別是在 runtime 的時候決定的，雖然很靈活可是當 code 量級上去之後因爲類型不正確引發的錯誤也會逐漸增加。但 Python 也是可以做到型別要求的，就是使用 「 Type Hint 」 或者叫 「 Type Annotation 」，中文稱呼蠻多種的例如「型別標註」、「型別提示」等等。 若有寫 Type Hint 的話，比較現代的 IDE 都會有一些自動顯示或補全輔助 :
Python 的 Type Hint 是從
3.5開始萌芽逐漸引入直到現在，故有一些發展的歷史脈絡和演變，有一些寫法也漸漸更替，故簡單介紹和分析一下。
