施星宇

科技巨頭在創新與可靠間的觀察

Sun, 16 Aug 2026 00:40:00 +0800

過去待過 Microsoft 和 Meta 這兩間公司，觀察到這兩間公司有一個有趣的差異，也就是一間公司到底是希望大家覺得它是一間「可靠」、「值得信任」的公司，還是希望大家認為是一間很「有創新能力」、永遠在嘗試新東西的公司

當然，這兩件事情並不是互斥的，一間公司可以同時很可靠，也可以同時很創新，應該幾乎所有科技公司都會希望兩個都有，但我是這樣覺得，當一間公司的規模越來越大之後，這兩件事情其實存在某種程度的 Trade-off，也就是說，當你越想讓整個組織保持快速改變的能力，相對來說就一定會增加一些不確定性，而當你越希望自己的產品、方向和承諾都是穩定而且可以預測的，很多時候就不可能像一間新創公司一樣，想到什麼事情就立刻去做，而我待過的兩間公司，Microsoft 和 Meta 在這件事情上，我覺得剛好是兩個蠻不一樣的例子

當「可靠」本身就是產品的一部分

如果要形容我在 Microsoft 感受到的公司文化，我感覺它是一間相對比較保守的科技公司，我先說我講的保守並不是說 Microsoft 不做新的東西，事實上從 Azure、AI 到各種開發工具，它當然還是持續有很多新的產品和技術，只是相較於很多消費型網路公司，我覺得 Microsoft 做事情的邏輯，會很明顯把安全性、穩定性、相容性，以及長期的可靠度放在比較高的位置，而這其實跟 Microsoft 現在的商業模式有很大的關係，以前很多人對 Microsoft 的印象可能還是 Windows 和 Office，但是今天 Microsoft 很大一部分的業務已經建立在企業客戶上，包括 Azure、Microsoft 365、各種資安方案，許多政府機關和大型企業的基礎設施，本身就建立在 Microsoft 的產品上，而當你的客戶是這些公司的時候，大家對你的期待其實會跟一般消費型產品非常不一樣，舉一個比較簡單的例子，如果今天我做的是一個手機應用程式，我把某個功能拿掉或者重新設計，使用者可能覺得很難用，也可能上網抱怨，但是最多就是換一個應用程式，可是如果今天是一間銀行已經有幾百套內部系統建立在你的平台上，或者一間公司已經把整個基礎設施搬到你的雲端上，那這時候你突然改變一個 API、停止支援一個功能，甚至只是一個原本沒有預期到的破壞性變更，對客戶來說都可能是一件非常大的事情

對這些企業來說，他們買的其實不只是產品本身的功能，而是某種程度上的承諾，也就是我今天選擇你的產品之後，我相信三年後、五年後，甚至十年後，你不會突然告訴我這個東西不能用了，即使技術一直在變，你也會提供足夠的向下相容性、遷移方案，或者長期的支援，讓我不用每隔幾年就重新把整套系統做一次，這也讓我以前在 Microsoft 工作的時候，常常會感受到公司非常在意信任這件事情，有時候從工程師的角度來看，確實會覺得很多事情做得很慢，一個功能可能要經過很多審查，有些東西明明技術上早就可以換掉了，但是因為還有客戶正在使用，所以還是要繼續支援，甚至有些看起來很簡單的改動，最後牽涉到的安全性、法規遵循、相容性問題可能比實際寫程式碼還多

以前我會覺得這是一種大公司的官僚流程，但反過來看，這些官僚流程有一部分其實就是可靠度的成本，因為當很多公司願意把自己的業務建立在你的產品上，他們願意相信的並不是 Microsoft 每一年都一定會做出最酷的新功能，而是它是一間相對不會亂來的公司，對 Microsoft 來說，「可以被信任」本身其實就是產品價值的一部分

相容性的另一面，是不斷累積的複雜度

不過，相容性做得好也不代表產品就一定比較好用，當舊的功能不能隨便拿掉，舊的操作方式需要繼續支援，新的需求又不斷加進來時，產品就很容易變成一層一層往上疊，每一次增加的東西都有它當時合理的背景，但是過了幾年之後，使用者看到的可能就是更多選項、更多入口，以及好幾種看起來很像、實際上又不完全一樣的做法，我自己觀察到 Power BI 對就是個明顯的例子，它的功能很多也需要照顧不同時期、不同使用情境和不同企業客戶的需求，但整個介面和概念也容易變得複雜，有些東西之所以還留在那裡不一定是因為它仍然是今天最好的設計，而可能只是因為已經有人依賴它，不可以直接拿掉

所以 Microsoft 這種做法的代價，很多時候不是功能突然消失，而是歷史包袱會慢慢累積，它讓使用者比較能相信原本的東西明天還會存在，卻也可能讓整個產品變得疊床架屋，需要花更多時間理解

即使已經是一間大公司，還是希望自己可以 Move Fast

相比之下，我到 Meta 之後感受到的是一個蠻不一樣的文化，Meta 今天當然已經不是一間新創公司了，它已經是一間有非常多員工、產品也影響全球數十億使用者的大型公司，但是很有趣的是，它內部到現在還是非常努力想要維持一種新創公司的精神，其中最明顯的當然就是大家都知道的 Move Fast，我以前在外面看到這個口號的時候，會覺得它可能就只是公司文化宣傳的一部分，但真的進到公司之後，會發現它其實會反映在很多做事情的方法上，例如公司如果覺得一個方向很重要，組織和資源可以很快速地往那邊移動，一個專案可以很快開始，方向也可能很快改變，而如果後來發現這件事情不值得繼續做，也可以很快把資源重新移到其他地方，這種文化的好處其實非常明顯，就是一間公司不會因為自己已經變得很大，就完全失去改變方向的能力，因為科技產業本來就是一個變化非常快的產業，如果今天一間公司所有事情都希望等到百分之百確定才去做，那很多時候等你確定的時候，市場可能早就已經往下一個方向走了

我覺得 Facebook 後來改名成 Meta 就是一個非常典型的例子，不論現在回頭看元宇宙這個方向是不是完全正確，光是從一間大型企業做決策的角度來看，這其實是一件蠻驚人的事情，Facebook 這個名字已經累積了非常大的品牌價值，但當上面認為下一個運算平台可能會往另一個方向發展時，它真的可以直接把整間公司的名稱改掉，然後投入非常大量的人力和資源去做 VR、AR 和相關技術，這種事情如果放在一間更傳統的大公司，可能光是討論要不要做就要非常久，更不用說真的把整間公司的方向往那邊移動，所以我覺得 Meta 特別之處就是它即使已經是一間非常大的公司，還是很努力不要讓自己變成一間「因為已經成功，所以什麼事情都不敢改」的公司，但這樣的文化其實也一定會有它另外一面的代價

快速改變的另一面，是不斷重新適應

如果說 Microsoft 的難用有一部分來自歷史包袱，那 Meta 則是另一種程度的難用，不是舊的東西留下太多而是東西變得太快，有些今天還能使用、也已經熟悉的功能可能過一陣子就不見了或者被移到另外一個地方，內部的工具、介面和流程也可能持續調整，每一次改變單獨來看都有讓系統變得更好、更一致，或者更符合新方向的理由，但對實際使用的人來說還是需要不斷重新適應，這種做法可以減少長期累積的包袱，讓團隊有機會直接換掉不再適合的設計，可是它同時也降低了可預測性，使用者不一定要理解十年前留下來的所有選項，卻要接受自己今天學會的東西，明天不一定還能照同樣的方法使用

所以從易用性的角度來看，Microsoft 和 Meta 並不是一個好用一個難用，而是兩種不同的成本，一種是為了相容而累積的複雜度，另一種是為了快速迭代而產生的不穩定性

對公司來說是快速改變，對合作的人來說可能是不確定性

同一間公司這特性從內部和外部去看，感受會完全不一樣，例如從 Meta 自己的角度來看，如果一個方向不對可以快速調整方向，這絕對是一個優點，因為代表公司的資源不會一直浪費在一個已經知道沒有機會的專案上，但是如果你今天是間正在跟 Meta 合作的廠商，而且你已經投入了一批人力在共同開發某個東西，那你最在意的事會是：「你們明年還會不會繼續做這件事？」，所以就是對公司本身而言，改變的能力是一種彈性，但是對依賴這間公司的人來說，改變有時候就是一種風險，這點其實不只是在公司合作上，對員工、開發者，甚至投資人來說都是一樣的

今天一間公司很願意嘗試新的東西，對裡面的工程師來說可能代表有很多新技術、新產品可以搞，但也可能代表組織和專案可以很容易改變，甚至哪天突然就被公司砍掉了，而一家公司願意投入大量資源去嘗試一個還不知道會不會成功的市場，從創新的角度來看當然很好，但從投資人的角度來看，問題可能就會是這些資源什麼時候能夠轉換成營收，所以這並不是單純「哪一種公司文化比較好」的問題，而是不同的人在意的東西本來就不一樣，而你到底比較相信哪個

創新和可靠度其實有一點一體兩面

創新和可靠度這兩個看起來都是非常正面的詞，其實在某些情況下有一點一體兩面，創新的本質本來就代表你要去做一些以前沒有做過的事情，而只要是一件以前沒有做過的事情就一定會包含某種程度的不確定性，你不知道市場會不會接受，不知道技術最後能不能成功，也不知道現在投入的資源最後有沒有辦法產生回報，如果一間公司完全不能接受這些不確定性，那它當然很難做出真正很新的東西，因為所有討論最後都會變成：「有沒有過去成功的案例？有沒有資料可以證明一定會成功？」但問題是，如果真的已經有足夠的資料可以證明一件事情一定會成功，那很多時候它可能也已經不算是一件多創新的事情了

反之，可靠度很大一部分的價值，其實就是降低不確定性，一個企業為什麼願意簽長期合約，為什麼願意把基礎設施搬到你的平台上，本質就是因為它相信未來的結果在某種程度上是可以預測的，從這個角度來看 Microsoft 和 Meta 的差異，不是哪間公司比較厲害，而是兩間公司在不同的地方做了不同的取捨，Microsoft 因為有大量企業客戶，所以它需要讓客戶相信：「你今天把重要的東西交給我，未來我不會突然改變規則」，而 Meta 很大一部分的業務還是消費市場，它面對的競爭則是：「下一個平台出現的時候，我是不是還跟得上？」這兩個問題本身就造就出非常不一樣的公司文化

介在兩者中間的公司

如果要再加入另外一家公司，我自己會覺得 Google 是一個蠻有趣的案例，因為它某種程度上好像剛好介在 Microsoft 和 Meta 中間，以前的 Google 給人的印象其實是一間非常創新的公司，而且有很多東西都是先把技術做出來再看看可以拿它來做什麼，它有很強的工程文化，也做過非常多實驗性的產品，這一點我覺得比較接近 Meta，但 Google 這幾年也慢慢開始進入更多企業市場，包括 Google Cloud、Google Workspace，這些東西的客戶跟一般搜尋引擎或 YouTube 的一般使用者是非常不一樣的，如果今天一間公司真的把自己的基礎設施搬到 Google Cloud，它當然也會開始問跟 Azure 客戶一樣的問題，這個服務五年之後還在不在，API 會不會改，你們會不會哪天覺得這個產品不值得繼續做，就把它關掉

而我覺得這也是為什麼當一間科技公司越來越大、企業業務越來越重要的時候，它很多做事情的方法可能就會慢慢往 Microsoft 那一側移動，這不一定代表公司失去了創新能力，而是當越來越多人開始依賴你的產品之後你能夠隨意改變的空間本來就會變小，這也是一間新創公司變成大型企業之後不太能避免的事情

大公司為什麼最後都會變慢

所以現在回頭看，我覺得所謂的「大公司病」可能也不完全只是因為公司的人變多了，或者管理階層變得比較官僚，而是一間公司成功之後需要負責任的對象也變多了，新創公司最怕的是沒有改變，如果今天產品沒有人用，最合理的做法可能就是明天直接改方向，因為反正原本的東西也沒有什麼人依賴，但是當今天有幾億、幾十億個使用者，有企業客戶、有開發者、有合作夥伴，甚至有政府機關都建立在你的產品上時，一次產品方向的改變影響的就不只是你自己的公司

所以很多大型企業後來會開始出現更多流程、審查、法規遵循、資安要求，我覺得其中當然還是會有一些沒有必要的官僚流程，但是也不能說這些東西全部都沒有意義，有一些其實只是因為你犯錯的成本已經跟以前不一樣了

最困難的可能是，長大之後還能不能同時保留兩件事情

所以不單純是「Microsoft 比較保守，所以 Meta 比較創新」這麼簡單的方式去看這兩間公司，我反而覺得比較有趣的問題是，一間公司在成長的過程中，到底要怎麼同時保留創新和可靠度，如果一家公司太偏向可靠度，所有事情都必須先證明沒有風險，那它很有可能會慢慢變成一間穩定，但是很難再創造新東西的公司，可是如果一家公司所有事情都只追求快速行動，方向一直改，那不論是客戶、合作夥伴還是員工，長期下來也可能不知道自己到底能不能信任今天的方向，所以真正難的但是關鍵的，是要分清楚哪些事情是可以快速試錯的，哪些事情則是一旦承諾之後就不應該隨便改變，一個新的產品方向可以快速實驗，但是已經提供給客戶的 API 可能不能說改就改，內部專案可以快速停止，但如果合作夥伴已經在上面投入很多資源，那對外的承諾就需要另外考慮

如果真的能把這個界線切清楚，那一間大型科技公司或許才有機會在變得越來越可靠的同時，還是保留原本改變自己的能力，而我覺得這可能也是 Microsoft、Meta、Google 這些已經非常成功的大型科技公司，接下來都會一直面對的一個問題：當一間公司已經大到很多人開始依賴它之後，它還能不能在讓別人信任自己的同時，繼續保有冒險和改變的能力？

我覺得這件事情，會比單純比較哪一間公司「比較創新」還要有趣呢

關於 Mutex、Semaphore 與 Spinlock

Sat, 15 Aug 2026 19:48:32 +0800

起源

今年年初在準備一些嵌入式系統相關的面試時，又遇到了 Mutex、Semaphore 跟 Spinlock 這三個東西，其實之前在面一些大廠時就有被問過，像是某薯條公司或是某水果公司，但當時沒什麼準備，所以答得也不是很好，所以趁著準備面試時再來複習一下，有修過作業系統的人對這三個名詞應該不陌生，只要碰到 RTOS、Linux Kernel 或是多執行緒程式之後多少都會遇到

其實如果沒有特別去記，大多人的印象都是：

「Mutex 不就是鎖嗎？」
「Semaphore 好像也是鎖？」
「那 Spinlock 又是什麼鬼，為什麼已經有 Mutex 還要再多一個 Spinlock？」

而且三個東西印象中都像是在做同一件事情：不要讓大家同時碰同一個東西，所以這篇一樣想用一個超級白話的方式把這三個東西整理起來，以免哪天又忘記 Mutex、Semaphore 跟 Spinlock 到底差在哪裡，就可以快速回來複習一下

所以為什麼會需要這些東西？

我們先不要管 Mutex、Semaphore 跟 Spinlock 這些東西各自在幹嘛，先設想一個情境好了，如果今天寫的是一個超級簡單的 Bare Metal Firmware：

1
2
3
4
5
6
7


main()
{
 讀 Sensor
 控制 Motor
 更新 LED
 ...
}

CPU 就這樣一件事情一件事情照順序做下去對吧，其實很多時候根本不會需要到什麼 Mutex 或 Semaphore，這就是我們在 MCU 上最常見的寫法，也不太會有什麼問題，因為同一個時間基本上就只有現在這段 Code 在執行，可以自由使用系統裡的資源

但如果我們今天需要系統有多個執行緒分別去跑不同的邏輯，開始使用 RTOS，例如 Zephyr、FreeRTOS、ThreadX，那情況就不一樣了

我們假設系統裡面有三個 Thread：

1
2
3


Sensor Thread
Motor Thread
UI Thread

通常 MCU 只有一個 CPU Core，而 RTOS Scheduler 會在不同的 Thread 之間快速切換，例如說系統裡可能同時有用來收集 Sensor 資料的 Sensor Thread、用來控制馬達狀態的 Motor Thread 跟用來顯示裝置狀態的 UI Thread，Scheduler 會讓它們輪流使用 CPU，雖然這些 Thread 並不是真的同時執行，但只要其中一個 Thread 做到一半時切換到另一個 Thread，另一個 Thread 就有機會碰到還在被前一個 Thread 使用的資源，在 Single Core 上，前一個 Thread 雖然已經暫停執行，但資源可能仍處於使用中的狀態，而在 Multicore 上則真的可能發生同一個資源被兩個跑在不同 Core 上的 Thread 同時存取，所以問題就來了：如果兩個 Thread 同時想要操作同一個東西怎麼辦？

例如 Motor Thread 跟 UI Thread 可能同時修改 Motor 的控制狀態，或是 Sensor Thread 跟其他 Thread 同時存取某一塊 Shared Memory，這時候如果沒有適當的保護就會出問題

我們先從一個最簡單的狀況開始，假設有一個很單純的變數：

1

counter++;

看起來只是一行，但 CPU 實際上通常需要先讀取 counter、加一，再把結果寫回 Memory

如果 Thread A 跟 Thread B 都在差不多的時間讀到 counter = 10，它們最後就可能各自寫回 11，明明執行了兩次 counter++，結果卻只增加一次，這個大家在作業系統課程裡應該都有學過，這就是很典型的 Race Condition，而 Mutex、Semaphore、Spinlock 這些東西，本質上就是為了解決這類 Concurrency / Synchronization 問題而存在的

嚴格來說，並不是說「Bare Metal 就絕對不會有這種 Race Condition」，實際上只要有 Interrupt、Multicore 或其他非同步的 Execution Context，其實 Bare Metal 一樣可能碰到 Synchronization 問題，只是說一般在嵌入式韌體開發中，這些搶佔情形比較常出現在開始使用 RTOS、Linux 或其他有 Thread / Scheduler 的系統之後，即使只有單核心 CPU，只要系統存在 Preemption，一個 Thread 在 Critical Section 中被另一個 Thread 搶走 CPU，一樣可能產生 Race Condition，Linux Kernel 的文件也特別指出，即使只有一顆 CPU，Preemption 仍然可以造成類似的 Race Condition（Linux Kernel Documentation — Locking）

所以回到 Mutex、Semaphore 跟 Spinlock，這些可以理解為是作業系統為了管理這種搶佔狀況而提供的同步機制，也就是說如果我們今天只是用 Bare Metal，那通常就沒有 RTOS 直接提供的現成 Lock 可以用啦，如果需要就要自己在系統裡去刻出來了

OK，所以知道問題從哪裡來之後，接下來就看看這三種東西到底分別在幹嘛，以及想解決什麼問題吧

Mutex：這個東西現在是我的，你們先不要碰

先從最好理解的 Mutex 開始，Mutex 全名是 Mutual Exclusion，從名字就差不多知道它想做什麼：

同一個時間，只允許一個 Thread 進來

假設 Motor Thread 跟 UI Thread 都可能修改同一顆 Motor 的狀態，我們不希望其中一邊正準備把轉速設成 1000 RPM，另一邊突然把它改成 200 RPM，兩個 Thread 一起修改 Driver State 或 Hardware Register，最後控制結果很容易亂掉而且出現不可預測的隨機狀態，很可怕，這時候 Mutex 就上場了

Thread 在操作 Motor 之前要先取得 Mutex，拿到之後，其他 Thread 就不能進入同一段程式，這段只有 Lock 持有者能執行的區域，就是作業系統課程裡常聽到的 Critical Section

1
2
3
4
5
6


mutex_lock(&motor_mutex);

motor_set_speed(1000);
motor_set_direction(FORWARD);

mutex_unlock(&motor_mutex);

等 Thread A 操作完 Motor 並 Unlock 之後，Thread B 才能取得 Mutex 繼續執行，這樣兩個 Thread 就不會同時碰同一個硬體資源了，Zephyr 對 Mutex 的建議用途也是讓多個 Thread 互斥地存取同一個資源，像是保護一個 Physical Device（Zephyr Project Documentation — Mutexes）

當然，Mutex 保護的不一定是硬體，也可以是 Shared Memory、Linked List、File、I2C Bus、SPI Bus、UART 或 Driver State，總之呢，只要某個東西同一時間只能讓一個 Thread 操作，第一個可以想到的通常就是 Mutex

這時候一定有人會好奇說，那如果 Mutex 已經被別人拿走，系統又是怎麼調度 Thread B 呢？

其實做法很直接，RTOS 會把 Thread B 從 Running State 移到 Blocked State，接著讓 Scheduler 從 Ready Queue 裡挑選其他可以執行的 Thread，例如 Sensor Thread，這段期間 Thread B 不會一直檢查 Mutex，也不會繼續消耗 CPU

等 Thread A 呼叫 mutex_unlock()，RTOS 再把 Thread B 移回 Ready State，如果 Thread B 的 Priority 比目前執行中的 Thread 高，就可能直接搶占 CPU，否則就留在 Ready Queue 等待下一次調度，所以這也是 Mutex 跟後面 Spinlock 很重要的一個差別：Mutex 等不到的話，可以睡

一個實際的例子是 Linux Kernel 裡的 Mutex 就屬於 Sleeping Lock，拿不到 Mutex 時，Task 可以 Suspend，讓 CPU 去執行其他工作（Linux Kernel Documentation — Locking）

Semaphore：我不是在鎖東西，我是在數「還有幾個」

接下來來說說 Semaphore，中文通常翻作「信號量」，這個名字第一次看到其實不太容易懂，其實可以把它想成一個裝著 Token 的盒子，假設盒子裡有三個 Token，Semaphore Count 就是 3，每當 Thread Take() 一個 Token，Count 就減一；有人 Give() 一個，而且 Count 還沒有到上限時，Count 就加一，所以 Semaphore 最核心的東西其實就是：一個 Counter（Zephyr Project Documentation — Semaphores）

如果 Count 一開始是 3，Thread A、B、C 各自拿走一個之後，Count 就會變成 0，這時 Thread D 再呼叫 Take()，就只能等到有人 Give() 一個回來，這種可以記錄多個 Token 的 Semaphore，就叫做 Counting Semaphore，如果 Count 只有 0 或 1，則稱作 Binary Semaphore

看到這邊可能會冒出一個問題：「等等，Binary Semaphore 最大就是 1，那不就跟 Mutex 一樣嗎？」

沒錯，表面看起來真的很像，但兩者想表達的概念不太一樣：

Mutex 在意的是 Ownership：這個 Resource 現在是誰的？
Semaphore 在意的是 Count / Signal：現在有幾個 Resource，或者發生了幾次 Event？

Mutex 通常有明確的 Owner，也就是哪一個 Thread Lock，就應該由那一個 Thread Unlock，而 Semaphore 則不一定有這種 Ownership 關係，以 FreeRTOS 為例，Mutex 額外具有 Priority Inheritance，而 Binary Semaphore 沒有，因此官方也建議 Resource Mutual Exclusion 與 Synchronization 分別使用不同的 Primitive（FreeRTOS Documentation — Mutexes）

這個差別看起來還是有點抽象，所以我們直接來看一個嵌入式很常見的例子吧

假設今天有一顆 Sensor 不斷取樣，並且把資料暫存在自己的 FIFO，當 FIFO 裡的資料到達某個 Threshold，Sensor 就拉起 Interrupt，通知 MCU：「我這邊累積了一些資料，記得來讀取喔」

MCU 進入 ISR 之後，當然可以直接讀 Sensor Register、搬出 FIFO 資料，再做 Filter 與後續運算，但通常不會想這樣做，因為 ISR 最好越短越好，比較常見的做法，是讓 ISR 只負責 Give Semaphore，再由 Sensor Thread 執行真正耗時間的工作：

1

Sensor Interrupt -> ISR -> Give Semaphore -> Sensor Thread -> Read FIFO

概念上，ISR 只做很少的事情，下面是方便理解的通用寫法，實際使用時仍要換成該 RTOS 允許在 ISR 中呼叫的 API：

1
2
3
4


void sensor_isr(void)
{
 semaphore_give(&sensor_sem);
}

平常 Sensor Thread 則停在 semaphore_take() 等待通知：

1
2
3
4
5
6
7


while (1)
{
 semaphore_take(&sensor_sem);

 read_sensor_fifo();
 process_sensor_data();
}

沒有 Interrupt 時，Semaphore Count 是 0，Sensor Thread 會保持在 Blocked State，不需要一直輪詢 Sensor 有沒有資料，當 Interrupt 發生後，ISR 將 Count 從 0 加到 1，等待中的 Sensor Thread 就會被喚醒；它 Take 掉這個 Token，再去讀取 FIFO

這樣分工就很清楚：ISR 負責通知，Thread 負責真正做事情

Zephyr 官方文件也把這列為 ISR Offload Work 的典型方法：ISR 可以透過 Semaphore 等 Kernel Object 去 Signal 一個 Helper Thread，把比較耗時間的工作留到 Thread Context 執行（Zephyr Project Documentation — Interrupts）

所以從這個例子就很容易看出 Mutex 與 Semaphore 的語意差別：

Mutex 比較像：「廁所有人了，你先不要進來」
Semaphore 比較像：「現在有一件事情要處理」
Counting Semaphore 則可以表示：「現在累積有三件事情要處理」

這邊還有個細節是，如果使用 Binary Semaphore，它的 Count 只會是 0 或 1，假設 Sensor Thread 還沒開始處理，Sensor 又連續觸發了三次 Interrupt，最後的 Count 可能仍然只有 1，也就是說，Binary Semaphore 比較接近「有事情發生了」，而不是精確記錄「事情發生了三次」

如果你的系統需要每一次 Event 都不能遺失，就要考慮使用 Counting Semaphore 並設定足夠的 Count 上限，甚至改用 Queue，Semaphore 可以代表可用的 Resource 數量，也可以代表等待處理的 Event 數量，會比 Mutex 更泛用

Spinlock：反正應該馬上就好了，我站在這邊等

最後來看看 Spinlock 吧，前面說過，Thread 拿不到 Mutex 時可以進入 Blocked State，讓 RTOS 的調度策略去把 CPU 交給其他 Thread，這聽起來很合理對吧，但 Context Switch 其實不是免費的

系統需要先保存目前 Thread 的 Register、Program Counter、Stack Pointer 等 Execution Context，再載入另一個 Thread 的 Context，這些動作當然都有成本，假設 CPU 1 上的 Thread B 正拿著 Lock，但它只剩下 shared_data++ 這種非常短的操作，可能再幾個 CPU Cycle 就會釋放，這時如果 CPU 0 上的 Thread A 立刻 Block、儲存 Context、重新排程，忙了一圈之後，Thread B 搞不好早就把 Lock 放掉了

所以另外一個想法就出現了：

既然我猜它馬上就會用完，那我乾脆站在這裡等

這就是 Spinlock，概念上它會不斷檢查 Lock 是否已經被釋放，也就是直接佔住 CPU 做 Busy Waiting：

1
2
3
4


while (lock_is_taken)
{
 // Busy waiting
}

等待期間 Thread 不會進入 Sleep State，它所在的 CPU Core 也不會去執行其他 Thread，而是一直嘗試取得 Lock，它一直在原地「轉」，所以才叫 Spin Lock

Linux Kernel 對 Spinlock 的描述也是這個概念：拿不到 Spinlock 就持續嘗試；相較之下，拿不到 Mutex 則可以 Suspend，讓 CPU 去做其他事情（Linux Kernel Documentation — Locking）

那 Spinlock 不是超級浪費 CPU 嗎？沒錯，所以 Spinlock 有一個非常重要的前提：Critical Section 必須非常短，否則就會讓等待這把 Lock 的 CPU Core 白白浪費在那邊

例如下面這種很快就結束的操作，才適合使用 Spinlock：

1
2
3
4
5
6


spin_lock();

shared_state++;
update_pointer();

spin_unlock();

如果持有 Spinlock 時去 Sleep、執行很慢的 I/O，或等待 Hardware，其他正在等待同一把 Lock 的 CPU Core 就只能一直空轉，除了浪費 CPU，在許多 Kernel Context 中，持有 Spinlock 時 Sleep 本身就是不允許的

所以可以很粗略地記成：

等待時間可能比較長，而且允許 Sleep：考慮 Mutex
Critical Section 非常短，而且不能或不適合 Sleep：考慮 Spinlock

這就是 Spinlock 最基本的 Trade-off：拿 CPU Time 換掉 Context Switch 與 Sleep / Wakeup 的 Overhead

看到這邊通常就會覺得，哦，所以 Spinlock 是只會在多核心系統上出現對吧

當然 Spinlock 在多核心系統上特別好理解，假設 CPU 1 正在修改 Shared Data，而 CPU 0 也想修改，CPU 0 即使原地 Spin，也不會妨礙 CPU 1 繼續完成手上的 Critical Section；只要 CPU 1 很快 Unlock，CPU 0 就能接著取得 Lock

不過這邊有個很容易誤會的地方：Spinlock 並不是只有 Multicore 才有意義

Linux Kernel 裡還有 Thread Context、SoftIRQ、Hard IRQ 等不同的 Execution Context，其中有些 Context 根本不能 Sleep，如果 Interrupt Handler 拿不到 Lock，我們不能叫它先睡一下，因此 Mutex 這種 Sleeping Lock 就不適合，反而需要 Spinlock 或其他不能 Sleep 的 Synchronization Primitive，Linux Kernel 也因此提供了 spin_lock_irq()、spin_lock_irqsave() 等不同形式（Linux Kernel Documentation — Locking）

所以更完整地說，Spinlock 常見的使用條件是：Critical Section 很短，而且目前的 Execution Context 不適合或不能 Sleep，Multicore 只是這個需求最直覺的一種情境，另外，在某些單核心 Linux Kernel Configuration 中，Spinlock 甚至不一定需要真的 Spin，例如系統沒有 SMP，也沒有 Preemption 時，就不存在另一個同時執行的 Task 可以搶走這個 Critical Section；Linux Kernel 會依 Configuration 對 Lock 做不同處理（Linux Kernel Documentation — Locking）

補充一下，Linux 的 PREEMPT_RT 會改變 spinlock_t 的實作語意，真正會在所有 Kernel Configuration 中維持 Spinning Lock 語意的是 raw_spinlock_t，這篇先用一般 Spinlock 的概念理解就好（Linux Kernel Documentation — Lock Types）

所以 Mutex、Semaphore、Spinlock 到底差在哪？

前面講了一大堆，最後其實可以用三句話快速記：

Mutex：「這個東西現在是我的，你們先不要碰」主要用來保護 Motor、I2C Bus、Shared Data、Driver State 或 File 等 Shared Resource，而拿不到時通常可以 Block / Sleep
Semaphore：「現在有幾個 Event 要處理？」主要用來做 Synchronization、Signaling 或 Resource Counting，而且不一定有 Owner
Spinlock：「它應該馬上就好了，我站在這邊等」主要用來保護非常短的 Critical Section；拿不到時不會 Sleep，而是持續佔用所在的 CPU Core 等待

當然現實世界沒有這麼絕對，不同作業系統對搶佔的實作機制也可能有差異，調度策略可能也不太一樣，但如果只是想快速判斷，可以先從下面三個方向想：

我要保護一個 Resource 嗎？先想到 Mutex
我要通知另一個 Thread「有事情發生」嗎？先想到 Semaphore
我要保護一個非常短的 Critical Section，而且這裡不能 Sleep 嗎？考慮 Spinlock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


 要解決什麼問題？
 |
 +---------------+---------------+
 | |
 保護 Shared Resource Event / Resource Count
 | |
 v v
 Mutex Semaphore
 |
 |
 拿不到 Lock 怎麼辦？
 |
 +-----+------+
 | |
可以 Sleep 不能/不想 Sleep
 | |
 v v
 Mutex Spinlock

結語

總之大概就是這樣了，Mutex、Semaphore 跟 Spinlock 第一次看的時候，很容易覺得三個東西長得差不多，反正都在避免多個 Execution Context 互相干擾，但真正去看它們想解決的問題，思考當初發明這些東西的人的核心思想，就會覺得還真是精妙啊，各自對應不同 Thread 之間的互動情境

Mutex 比較偏向 Ownership / Mutual Exclusion 強調資源的唯一性，Semaphore 比較偏向 Count / Signaling 更適合當有事件發生時的提醒信號，Spinlock 則是在 Mutual Exclusion 的問題上選擇 Busy Waiting，用 CPU Time 換掉 Context Switch 可能造成的額外成本

這些經典機制會被廣泛運用在不同的作業系統中，而它們背後其實都在處理不同的問題，理解這些機制以及它們背後想解決的問題，也能讓我們在設計系統時靈活運用這些作業系統提供的功能

希望這篇對大家有幫助啦

Reference

關於 Aligned Memory Allocation

Thu, 30 Oct 2025 21:48:32 +0800

起源

由於在這個東西上吃了大悶虧，至於是什麼虧就不細究了，總之是我當初在看到這東西的時候沒有認真摸透，就趁著這個機會好好還債了我想要用一個超級白話的方式讓人快速可以理解，下次遇到這個議題再回來看就能快速回憶起來

什麼是 Aligned Memory Allocation？

設想一個情況，今天程式運行到一個地方，如果我需要一些額外的記憶體來儲存新的資料，在 C 語言中我們一定會用到 malloc() 來跟系統要額外的記憶體空間

舉個例子，我現在突然需要 32 bytes 的空間，所以我就使出 malloc()，然後系統就翻啊翻找啊找，最後在記憶體中找到了 32 bytes 的空間，並把起始的記憶體位置傳回來。這個起始的位置可能很隨機，像是 0x08004321，不過這也無傷大雅，總之我現在有了 32 bytes 空間，我現在想對他幹嘛就幹嘛。

然而然而，在某些情況（至於是哪些情況後面再講），我們會希望我們得到的記憶體的起始位置是「對齊」的。那什麼叫做對齊呢？

舉個例子，如果你用一些 Hex 檔案的預覽工具，你會看到左邊的起始位置很整齊以 32 bytes 間隔，像下面這樣：

1
2
3
4
5
6
7
8
9


一般隨機分配 (未對齊):
0x08004321 | Data...
 ^ 起始位置很隨意

32-byte Alignment (對齊):
0x08000000 | Data...
0x08000020 | Data... <-- 0x20 就是 32
0x08000040 | Data... <-- 0x40 就是 64
 ^ 起始位置都可以被 32 整除

所謂的 Aligned Memory Allocation，就是我在要新的記憶體空間時，想要拿到一個起始位置可以被 32（或是其他數字）整除的記憶體空間

OK，所以說到這邊應該對這個 Aligned Memory Allocation 是什麼應該有點概念了，這樣就成功了一半了。因為大多數人第一次聽到應該都比較難想到這是什麼，又或者知道這是什麼，但不知道有什麼用

所以，這個有什麼用呢？

為什麼需要 Alignment？

會需要 Alignment 大多是受到硬體設計的限制，例如：

向量指令集 (如 AVX)，當執行這類指令集的時候，會要求目標的記憶體位置是對齊的，沒有對齊的話得要拆成兩步去處理，或是直接出現錯誤，那為什麼不設計成指令集可以讀取任意位置起始的記憶體呢？我覺得大多是成本考量，如果能從驅動程式端去解決，又何必浪費昂貴的硬體空間呢

其他像是 CUDA 中 GPU 透過 PCIe 抓取資料時，使用 DMA 也會要求記憶體要對齊，又或者 GPU 指令抓取他自己記憶體的資料也會要求對齊，另外在 STM32 這類單晶片上使用 DMA 時，buffer 的記憶體位置也會要求對齊，才能夠被 DMA 正確寫入或讀取

這時候一定有人跳出來說：「我平常用 CUDA 或是在 STM32 上用 DMA 都沒遇到這問題啊！」

那是因為 CUDA driver 或是 HAL library 之類的會幫你處理好，所以當然沒感覺，反過來說，如果你今天寫的是 driver 或是 bare metal 開發，那一定要小心記憶體對齊這東西，不然可能連動都動不起來

所以該怎麼做到 Alignment？

前面說了這麼多，那要怎麼才能做到記憶體分配時 Alignment 呢？

設想今天我們目標要一塊新的 64 bytes 記憶體，並且要求 32-byte 對齊。如果今天 malloc 給的起始位置剛剛好就是 0x08000040，是 alignment block 的起始位置，這樣就中大獎了，但實際上當然不會那麼幸運，他可能給你的起始位置是 0x08000041（偏移了 1 個 byte），也可能起始是 0x0800005F（偏移了 31 個 bytes）

但沒關係，這時候就會想到，只要malloc的記憶體夠長，從中找到一個 Alignment Block 的起點並從那邊開始存資料，這樣也算對齊吧

那麼問題就回到，我們該要多長的記憶體呢？觀察前面的例子，如果做 32 bytes 的 alignment，偏移的量最多就是 0 ~ 31 bytes。所以我們要 malloc() 的空間至少要是 size + alignment - 1

等等，好像少了什麼？這樣的話要怎麼才能 free 掉 alignment 起始位址前面的那些空間呢？我們需要紀錄真正原本 malloc 出來的起始位址，所以還需要再多一個位置去存這個指標，這個需要的空間是 sizeof(void*)

總結來說，我們真正要 malloc() 的長度是： size + alignment - 1 + sizeof(void*)

記憶體結構示意圖：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


實際 malloc 得到的區塊 (Original)
|
v
+-------------+---------------------+-------------------------+
| padding ... | 原始指標 (Stored) | 使用者拿到的指標 (Aligned)|
+-------------+---------------------+-------------------------+
 ^ ^
 | |
 這格存著 original 符合 32-byte 對齊
 的地址 我們回傳這個地址

然後我們只要找到這裡面 alignment 的起始位址，並且把「原始的起始位址」存在 alignment 起始的前一格。這樣在 free memory 時，只要從 alignment 位址往前找一格，就可以找到我們應該要釋放的記憶體起點。

原理概念上就是這樣了，那麼就來看看要怎麼實作吧。

C 語言實作

以下用 32-byte alignment 為例子，可以把 32 換成任意想要的正整數 alignment（通常是 2 的次方）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


#include <stdlib.h>
#include <stdint.h> // 為了使用 uintptr_t

void* aligned_malloc(size_t size) {
 // 1. 計算需要的總空間：
 // size + (alignment - 1) 的調整空間 + 存放原始指標的空間
 void *original = malloc(size + 32 - 1 + sizeof(void*));
 
 if (!original) return NULL;

 // 2. 算出 alignment 的起始位置
 // 先預留一個 pointer 的空間給我們存地址
 uintptr_t raw = (uintptr_t)original + sizeof(void*);
 
 // 利用 Bitwise 操作進行對齊
 // 原理：(address + mask) & ~mask
 // 注意：這裡要用 ~(32 - 1) 也就是 ~31 才能遮掉後五位達到 32 對齊
 uintptr_t aligned = (raw + (32 - 1)) & ~(32 - 1);
 
 // 其實也可以用(void*)(original - (original % 32));去算
 // 只是用bit manipulation感覺比較優雅

 // 3. 把原本 malloc() 的起始位址存到 alignment 位址的前一格
 ((void**)aligned)[-1] = original;

 // 4. 最後回傳 alignment 的起始
 return (void*)aligned;
}

void aligned_free(void *ptr) {
 if (!ptr) return;
 
 // free 的時候，去找到 alignment 位址前一格存的原來 malloc 的位址
 void *original = ((void**)ptr)[-1];
 
 // 然後把它釋放就行了
 free(original);
}

結語

總之就是這樣，Aligned Memory Allocation這個東西重要又有一些實作小細節，藉由這個機會算是有搞懂他了，以後忘了也可以快速回來複習一下

Reference

所有原生Leica M Mount相機列表

Sat, 16 Aug 2025 17:10:00 +0800

自從 Leica M3 在 1954 年發表，Leica M 卡口正式問世，至今已經走過了七十年的歷史。
這個卡口不僅承載了 Leica 自家的經典 M 系列旁軸相機，也吸引了許多其他品牌（Minolta、Zeiss、Konica、Voigtländer、Rollei、Epson、Ricoh、Pixii 等）陸續推出相容的機型，形成一個龐大的 M 卡口生態圈。

很多愛好者一定會好奇：「所有的 M 卡口相機到底有哪些？」
以下的表格整理了從 1954 年 Leica M3 一直到 2024 年最新的 Pixii Max，涵蓋了 Leica 與各大品牌的完整 M 卡口相機清單。

廠牌	名稱	發表年份	停產年份	成像方式	備注
Leica	Leica M3	1954	1966	35mm 底片	首款M系列；德國Wetzlar製造；0.91×取景器。
Leica	Leica M2	1957	1968	35mm 底片	M3的簡化與廣角化版本；德國Wetzlar製造。
Leica	Leica M1	1959	1964	35mm 底片	無測距與無測光的技術版；德國Wetzlar製造。
Leica	Leica MD	1964	1966	35mm 底片	無取景器、為科學/技術用途；以M2為基礎。
Leica	Leica MDa	1966	1976	35mm 底片	無取景器技術版；多用於顯微/測量用途。
Leica	Leica M4	1967	1975	35mm 底片	德國Wetzlar製造；快速回片搖把與斜角回捲。
Leica	Leica M5	1971	1975	35mm 底片	首款TTL測光（擺臂式CdS）；德國Wetzlar製造。
Leica	Leica CL	1973	1976	35mm 底片	與Minolta共同開發；日本大阪Minolta工廠代工（Leitz Minolta CL）。
Leica	Leica M4-2	1978	1980	35mm 底片	加拿大Midland（Ernst Leitz Canada）生產；新增熱靴與馬達相容。
Leica	Leica MD-2	1980	1986	35mm 底片	M4-2的無取景器技術版；多用於顯微/工業用途。
Minolta	Minolta CLE	1980	1985	35mm 底片	Leica-Minolta 合作款；日本大阪 Minolta 代工；支援 M 卡口、AE。
Leica	Leica M4-P	1981	1987	35mm 底片	多數為加拿大Midland製造；新增28/75mm框線。
Leica	Leica M6	1984	1998	35mm 底片	內建TTL測光；後期德國Solms製。
Leica	Leica M6 TTL	1998	2002	35mm 底片	增大機頂並改進TTL閃燈；德國Solms製。
Konica	Konica Hexar RF	1999	2003	35mm 底片	M 卡口自動曝光旁軸；內建馬達、最高 1/4000s 金屬快門。
Voigtlander	Bessa T	2001	2004	35mm 底片	Cosina 日本製；首款M卡口 Bessa；無內建觀景器，需外接取景器；測距器基線長。
Leica	Leica M7	2002	2018	35mm 底片	電子控快門與A光圈先決。
Rollei	Rollei 35 RF	2002	2002	35mm 底片	Cosina 日本製，基於 Voigtländer Bessa R2 的 Rollei 版。
Voigtlander	Bessa R2	2002	2004	35mm 底片	Cosina 日本製；M卡口；基於Bessa R 改良，金屬機身；與 Rollei 35 RF 共用設計。
Leica	Leica MP	2003	未停產	35mm 底片	機械式純手動；現行生產（德國Wetzlar/部分零件葡萄牙）。
Zeiss	Zeiss Ikon ZM	2004	2012	35mm 底片	德國設計、Cosina 日本製；2004 發表、2005 起販售；長測距基線，支援 AE。
Voigtlander	Bessa R2A	2004	2013	35mm 底片	Cosina 日本製；M 卡口；AE（0.7× 取景）。
Voigtlander	Bessa R3A	2004	2013	35mm 底片	Cosina 日本製；M 卡口；AE（1.0× 取景）。
Epson	Epson R-D1	2004	2007	數位（APS-C CCD）	全球首台數位旁軸；Cosina 日本製；M 卡口。
Leica	Leica M8	2006	2009	數位（APS-H CCD）	首款數位M；1.3×裁切；感光元件需外掛IR濾鏡。
Epson	Epson R-D1s	2006	2009	數位（APS-C CCD）	R-D1 韌體版功能更新的量產版；JPEG+RAW、長曝降噪等。
Voigtlander	Bessa R4A	2007	2015	35mm 底片	Cosina 日本製；M 卡口；AE；內建 21/25/28/35/50 框線（廣角專用）。
Voigtlander	Bessa R2M	2007	2015	35mm 底片	Cosina 日本製；M 卡口；全機械快門。
Voigtlander	Bessa R3M	2007	2015	35mm 底片	Cosina 日本製；M 卡口；全機械快門。
Voigtlander	Bessa R4M	2007	2015	35mm 底片	Cosina 日本製；M 卡口；全機械；內建 21/25/28/35/50 框線。
Leica	Leica M8.2	2008	2009	數位（APS-H CCD）	M8改良版；更靜音快門、藍寶石LCD。
Leica	Leica M9	2009	2012	數位（全片幅 CCD）	首款全片幅數位M；Kodak KAF-18500 CCD。
Epson	Epson R-D1x	2009	2014	數位（APS-C CCD）	系列最終款；加大 LCD、SDHC 支援；2014 年停產。
Leica	Leica M9-P	2011	2014	數位（全片幅 CCD）	M9衍生款；無紅點、藍寶石玻璃。
Ricoh	Ricoh GXR A12 M Mount	2011	2013	數位（APS-C CMOS 模組）	GXR Mount A12（M 卡口）模組；內建微透鏡補償；GXR 系列 2013 後停產。
Leica	Leica M (Typ 240)	2012	2017	數位（全片幅 CMOS）	首度加入Live View與1080p錄影；可配R鏡轉接。
Leica	Leica M-E (Typ 220)	2012	2015	數位（全片幅 CCD）	M9的入門版；後續由M (Typ 262)接替。
Leica	Leica M Monochrom	2012	2015	數位（全片幅黑白CCD）	基於M9；專用黑白感光元件。
Leica	Leica M-P (Typ 240)	2014	2017	數位（全片幅 CMOS）	M240衍生款；2GB緩衝、藍寶石LCD。
Leica	Leica M-A	2014	未停產	35mm 底片	機械式純手動；移除測光元件。
Leica	Leica M (Typ 262)	2015	2018	數位（全片幅 CMOS）	簡化版M240；無錄影、操控更純粹。
Leica	Leica M Monochrom (Typ 246)	2015	2020	數位（全片幅黑白CMOS）	基於M (Typ 240)；支援Live View與影片。
Leica	Leica M-D (Typ 262)	2016	2018	數位（全片幅 CMOS）	無背屏設計；專注拍攝。
Leica	Leica M10	2017	2020	數位（全片幅 CMOS）	更薄機身；僅照片（無影片）。
Leica	Leica M10-P	2018	2020	數位（全片幅 CMOS）	更靜音快門、觸控螢幕；去除紅點。
Leica	Leica M10-D	2018	2020	數位（全片幅 CMOS）	無背屏設計；支援Leica FOTOS連線。
Leica	Leica M-E (Typ 240)	2019	2019	數位（全片幅 CMOS）	M240世代的短期入門款；2GB緩衝，限量販售。
Leica	Leica M10-R	2020	2022	數位（全片幅 CMOS）	40MP高解析版本。
Leica	Leica M10 Monochrom	2020	2022	數位（全片幅黑白CMOS）	新40MP黑白感光元件。
Leica	Leica M11	2022	未停產	數位（全片幅 BSI-CMOS）	三重解析度輸出（60/36/18MP）；內建儲存；USB‑C；移除底蓋。
Leica	Leica M6 Reissue	2022	未停產	35mm 底片	基於Leica M-P的技術重新生產；外觀同小盤M6。
Leica	Leica M11-P	2023	未停產	數位（全片幅 BSI-CMOS）	首款內建Content Credentials（C2PA）數位簽章的Leica相機。
Leica	Leica M11 Monochrom	2023	未停產	數位（全片幅黑白BSI-CMOS）	M11世代專用黑白感光元件。
Pixii	Pixii+	2023	未停產	數位（APS-C BSI‑CMOS）	法國 Pixii；無顯示螢幕、內建儲存；M 卡口；A2572+ 版。
Leica	Leica M11-D	2024	未停產	數位（全片幅 BSI-CMOS）	無背屏的M11世代。
Pixii	Pixii Max	2024	未停產	數位（全片幅 BSI‑CMOS）	法國 Pixii 首款全片幅相機；28mm 寬視野光學觀景窗。

如有需要補充或是更新資訊的，歡迎來信告知。

Product、Program、Project Manager比較

Mon, 05 May 2025 14:52:00 +0800

前言

PM大概是科技業中最容易讓人搞不懂的職稱之一，Product Manager叫PM、Project Manager也叫PM，後來又冒出一個Program Manager還是叫PM，三個職稱看起來差不多，實際工作卻可能差了十萬八千里。更麻煩的是每間公司對PM的定義都不太一樣，有些公司的Product Manager做的其實很像Project Manager，也有些職缺乾脆只寫一個「PM」，等進去面試後才發現工作內容跟想像中完全不同。

我以前也很直覺地認為Product、Program與Project是從策略一路排到執行，Program Manager大概就是一次管理很多Project、職級也比較高的人，然而自己實際做過Technical Program Manager（TPM）後，才發現事情沒有這麼簡單。這三種角色並不是一條由上到下的指揮鏈，比較像是站在不同角度處理同一件事情，而在公司規模不大或分工沒有那麼細的地方，更常是一個人把三份工作全部包走。

因此這篇並不是要給三種PM下一個放諸四海皆準的定義，畢竟這種定義大概也不存在，而是希望用比較接近實際工作的方式，解釋三者通常在意什麼、每天都在處理哪些問題，以及新人看職缺時到底該看哪裡。

Product Manager｜產品經理

Product Manager最重要的問題是：「這個東西到底該不該做？」

假設一間影音平台想推出家庭訂閱方案，Product Manager不能只是收到老闆一句「Netflix有家庭方案，我們也來做一個」，接著就把需求丟給工程師。他得先弄清楚究竟是哪一群使用者有這個需求、他們現在遇到什麼問題、願意付多少錢，以及這個方案對公司的生意是不是真的有幫助。要是辛苦做了半年，結果沒人想用，就算準時上線、程式也沒有Bug，仍舊很難說是一個成功的產品。

為了回答這些問題，Product Manager可能會訪談使用者、看產品數據、研究競品，跟設計師討論操作流程，再找工程、法務、行銷與客服確認各種限制。由於想做的東西通常永遠比工程資源多，他還得決定第一版要先做什麼、哪些需求可以晚一點、哪些看起來很酷但其實先不要浪費時間。

而且產品上線並不是下班的時候，反而只是另一個階段的開始。多少人真的開通家庭方案、有多少人用過一次就不再使用、訂閱收入有沒有增加、客服又收到了什麼奇怪的抱怨，這些都會影響下一步的產品方向，因此Product Manager通常會關注使用率、轉換率、留存率、營收或使用者滿意度等結果。

Product Manager經常被稱為「產品的CEO」，這句話聽起來很威風，但老實說也很容易誤導新人。多數Product Manager並不是任何人的主管，沒有辦法命令工程師一定要做什麼，也不能無視成本與技術限制亂開支票；他真正需要的能力，是在資料永遠不完整的情況下做出還算合理的判斷，再想辦法說服一群不歸他管的人一起把產品做出來。

Project Manager｜專案經理

如果公司已經決定家庭訂閱方案非做不可，Project Manager接下來關心的就是：「要怎麼在有限的時間與資源內把它做完？」

一個看似簡單的功能，背後可能牽涉會員系統、付款、App、網站、客服工具、法務條款與行銷素材，其中只要一個環節慢下來，上線時間就可能整個往後延。Project Manager需要把事情拆成可以執行的任務，找出負責人與前後依賴關係，排出Milestone，再持續確認專案是不是還走在原本的計畫上。

當然，現實中的計畫幾乎沒有照表操課這回事，工程師可能突然發現原本的設計做不出來、法務審核比預期多了兩週、老闆在上線前又多塞了三個需求，甚至原本答應支援的人直接被別的專案搶走。Project Manager的價值就是在這些事情真的把專案炸掉以前先看見風險，把影響攤開來讓大家知道，再協調出可以接受的做法。

所以Project Manager確實會排時程、追進度與開會，但如果只把這個角色理解成每天問「好了沒」的人就太可惜了。好的Project Manager會讓每個人知道現在的目標、決策與責任是什麼，問題出現時也知道該找誰處理；催進度只是表面，減少意外與混亂才是這份工作的核心。

Project Manager通常會在意專案能不能準時完成、預算是否超支、需求範圍有沒有失控，以及最後交付的品質是否符合標準。不過這些結果也不是他一個人能控制的，專案管理做得再好，碰到需求每天改三次或資源根本不足的組織，一樣只能努力不要讓場面變得太難看。

Program Manager｜計畫經理

Program Manager應該是三者中最難只用一句中文解釋的角色，因為Program究竟有多大、包含什麼，在不同公司中的差異非常大。

回到家庭訂閱的例子，如果公司的真正目標是「拓展全球付費會員」，那麼家庭方案可能只是其中一小塊，整個Program還包含新的付款系統、跨國定價、家長控制、隱私與法規、客服流程和上市行銷，而這些工作分散在不同國家與團隊，各自又有自己的目標與時程。Program Manager要處理的就是這些工作之間沒有人單獨負責、但不處理又一定會出事的空隙。

例如付款系統什麼時候可以支援新的方案？各國法規不同，要不要分批上線？兩個團隊同時需要同一批工程資源時，哪一邊應該先做？一個團隊延遲會影響到多少下游工作？這些問題通常不是多開幾場進度會議就會自己消失，Program Manager得先建立大家共同理解的目標與Roadmap，再整理跨團隊的Dependency、風險與決策，必要時把Trade-off帶到更高的層級解掉。

因此Program Manager不一定是一次管很多Project Manager的人，更不代表他必然比Project Manager高一階。Program描述的是問題的範圍與複雜度，而不是組織圖上的上下關係。有些Program是一項有明確終點的大型產品上市，有些則是雲端遷移、隱私合規、開發流程或營運效率這種持續多年的能力建設，兩者都可能由Program Manager負責。

至於Technical Program Manager，簡單來說就是處理的Program具有相當程度的技術複雜度，因此除了Program Management能力外，也需要理解系統架構、技術限制與工程團隊的語言。這不代表TPM每天都要下去寫Code，但至少不能在工程師講到API、Database、Latency或System Design時立刻進入放空狀態，不然很難判斷風險，更不用說協助團隊做選擇。關於TPM實際面試會遇到什麼，我之前也寫過一篇Google Technical Program Manager面試經驗。

所以三種PM到底差在哪？

說了這麼多，可以先很粗略地記成下面三句：

Product Manager在意的是「為什麼做、替誰做，以及該做什麼」
Project Manager在意的是「由誰來做、什麼時候做完，以及如何順利交付」
Program Manager在意的是「多個團隊與專案要如何合作，才能達成更大的共同目標」

這個分法雖然不可能涵蓋每間公司的情況，但至少比「Product負責策略、Project負責執行、Program負責管理很多Project」來得接近現實。因為Product Manager一樣需要處理大量執行問題，Project Manager也不可能完全不參與策略，而Program Manager更不是只要把幾張專案進度表疊在一起就算完成工作。

在小型新創公司，一位Product Manager可能從使用者訪談一路做到排時程與追進度，實際上同時兼了Product與Project Manager；到了分工細的大公司，三種角色可能一起出現在同一個Program中，甚至還有Product Operations、Delivery Manager、Engineering Program Manager等更多令人眼花撩亂的名字。台灣的情況又更有趣，軟體公司的PM可能偏產品，系統整合公司的PM可能主要面對客戶交付，硬體公司的PM則可能每天處理供應鏈、試產、認證與量產時程，光看兩個英文字母實在很難知道他到底在幹嘛。

新人該怎麼看PM職缺？

比起研究職稱，最有用的方法還是把Job Description打開來看，而且不要只看那些「善於溝通、積極主動、可以在快速變動的環境工作」之類每間公司都能複製貼上的句子，可以特別找下面幾件事：

這個角色最後要對什麼結果負責，是產品成長、單一專案交付，還是跨部門的整體成果？
平常最常合作的對象是使用者、設計與工程，客戶與供應商，還是公司內的多個團隊？
工作中有多少產品與需求的決策權，又有多少時間是在執行別人已經決定的方案？
公司用什麼方式判斷這個PM做得好，是營收與留存、時程與預算，還是效率、成本與組織能力？
這個職位上一個人一週通常怎麼過？這題在面試中問下去，通常比職稱本身更容易挖出真實的工作內容。

如果你喜歡理解使用者與商業問題，願意在模糊的資訊中做取捨，Product Manager可能比較適合；如果你擅長把一團混亂整理成可以執行的計畫，對細節、風險與時間很敏感，Project Manager可能比較對味；如果你喜歡處理跨團隊的複雜問題，能在沒有直接管理權的情況下推動一群人往前，而且看到一堆Dependency不會先頭痛，那Program Manager也許是可以嘗試的方向。

不過Program Manager，尤其TPM，通常比較需要既有的產業或專案經驗，原因也很直接：如果自己還沒有看過幾個專案是怎麼成功、又是怎麼爆炸的，就很難提早看出一個大型Program究竟會在哪裡出問題。

結語

Product、Project與Program Manager並不是三條完全分開的路，也不是固定的升遷順序。實際工作中大家都會碰到產品判斷、專案執行與跨團隊協調，只是每個角色花費的比例不同，而這個比例還會隨著公司、產業與團隊一直改變。

如果真的只能用一句話總結，我會說Product Manager確認問題值不值得解決，Project Manager想辦法讓解法順利交付，而Program Manager則確保一群彼此牽連的團隊最後真的能產生結果。

所以下次看到PM職缺，先不要急著被職稱騙進去，問清楚每天到底在解決什麼問題比較實在。

Build U-boot for QEMU

Thu, 30 Jan 2025 20:56:58 +0800

Install Dependencies

1
2
3
4


sudo apt install \
bc build-essential git libncurses5-dev \
lzop perl libssl-dev bison flex \
swig libyaml-dev pkg-config python3-dev

Clone U-boot Source

1
2
3
4


git clone https://github.com/u-boot/u-boot.git
cd u-boot
make distclean
make qemu_arm64_defconfig && make -j8

make distclean This cleans the repository by removing any previous build artifacts, generated configuration files, or object files. It ensures you have a completely fresh start, especially useful if you built U-Boot for a different target earlier.
make qemu_arm64_defconfig This sets the default configuration for building U-Boot specifically for a QEMU ARM64 (AArch64) virtual environment. Defconfigs are baseline config files that initialize a bunch of standard options for a given architecture or board in U-Boot.
make -j8 Builds U-Boot with 8 parallel jobs, leveraging multiple cores to speed up compilation. The output of this step will typically produce u-boot.bin and other binaries needed to run U-Boot (like u-boot.elf or u-boot.map).

Run U-boot with QEMU

1
2
3
4
5
6


qemu-system-aarch64 \  
-M virt \
-cpu cortex-a57 \
-m 1024 \
-nographic \
-bios u-boot.bin

-M virt: Specifies the QEMU “virt” machine model, a generic machine typically used for virtualizing ARM systems.
-cpu cortex-a57: Defines the virtual CPU core type. Cortex-A57 is a common 64-bit ARM core.
-m 1024: Allocates 1024 MB of memory (i.e., 1 GB) to the virtual machine.
-nographic: Disables graphical output and directs all console I/O to the terminal.
-bios u-boot.bin: Instructs QEMU to use the u-boot.bin file as the “BIOS” or firmware image. Essentially, QEMU treats this binary as the initial code that runs at system reset, simulating the environment where U-Boot is the first piece of software to execute.

Output

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


U-Boot 2025.04-rc1-00020-g021baf7b08cc (Jan 30 2025 - 14:41:56 +0000)

DRAM: 1 GiB
Core: 51 devices, 14 uclasses, devicetree: board
Flash: 64 MiB
Loading Environment from Flash... *** Warning - bad CRC, using default environment

In: serial,usbkbd
Out: serial,vidconsole
Err: serial,vidconsole
No USB controllers found
Net: eth0: virtio-net#32

starting USB...
No USB controllers found
Hit any key to stop autoboot: 0
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
--- ----------- ------ -------- ---- ------------------------ ----------------
Scanning global bootmeth 'efi_mgr':
Cannot persist EFI variables without system partition
Missing TPMv2 device for EFI_TCG_PROTOCOL
Missing RNG device for EFI_RNG_PROTOCOL
Scanning bootdev 'fw-cfg@9020000.bootdev':
fatal: no kernel available
No USB controllers found
scanning bus for devices...
Scanning bootdev 'virtio-net#32.bootdev':
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (13 ms)
*** Warning: no boot file name; using '0A00020F.img'
Using virtio-net#32 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename '0A00020F.img'.
Load address: 0x40400000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
No more bootdevs
--- ----------- ------ -------- ---- ------------------------ ----------------
(0 bootflows, 0 valid)
=>

常見 Real-Time OS 介紹與比較

Mon, 06 Jan 2025 15:32:31 +0800

介紹

即時作業系統（Real-Time Operating System, RTOS）是一種專門為即時（real-time）應用而設計的作業系統，強調「在特定時間限制內（deadline）對事件進行回應」，試想一個情境在工業的領域若機器某部分突然產生故障，需要在極短的時間內停止所有馬達的運作，若此時使用的是傳統的作業系統如Linux，依OS內核的調度策略，最終馬達停止的動作會有些許延遲，相較之下RTOS則可以有較彈性的執行緒搶佔，讓緊急情況的處理可以更快被執行

本質上來說RTOS的內核使用起來的效果是大同小異的，基本上能做到多個執行緒的建立、輪詢執行、優先序搶佔、互斥鎖、內核級的中斷等功能，進階一點的則有可以動態記憶體管理、多核心的支援，這些RTOS主要的差異大多是在外圍模組的支援、周邊的開發生態系等，以下就分別介紹目前主流常見的幾種RTOS:

FreeRTOS

FreeRTOS 是由 Real Time Engineers Ltd. 及 Amazon 維護，完全開源並且在全球廣受使用，FreeRTOS 可以說是最最最常見的一種RTOS，成功之道大概在於早早就開源，早早就被各家IDE整合，各家晶片的SDK也都可以看到他的影子，我最早接觸他是在Arduino IDE，FreeRTOS早早就出現在Arduino library list中，使用起來也夠簡單，沒有什麼複雜的設定，加一兩行code就可以實現多執行緒，讓初學者很容易就可以踏入RTOS的世界。他背後的金主爸爸是 Amazon，後來也整合了不少 AWS 上IoT相關的功能，由於早早就開源，周圍的模組也不少。

AzureRTOS (Threadx)

ThreadX 是由 Express Logic 開發的即時作業系統（RTOS），後續被 Microsoft 收購並推出更名版本 AzureRTOS 並開源，從名字就可以看出來未來應該是要跟微軟的 Azure 搭配做一些IoT的功能，但目前好像還沒看到什麼殺手級的應用。由於開源的時間比較晚，周圍的套件比較少，像BLE、Wifi這類的Stack能用的東西好像比較少，但相信有微軟原生的支援應該可以成長的很快，我會碰到 AzureRTOS 是因為 STM32 官方原生支援 AzureRTOS，很有趣的是 STM32 的開發環境也有支援 FreeRTOS，但支援度是遠遜於 AzureRTOS 的。

Zephyr

Zephyr 是由 Linux 基金會（Linux Foundation）主導的開源即時作業系統（RTOS），Zephyr雖然出現很久了，但算是這幾年才突然紅起來，主打一個跨平台的相容性和完整的開發工具鏈，有像是West這種很好用的工具、也有像是DeviceTree者種為跨平台設計的架構，可以說要用Zephyr就要連著這一整串工具鏈一起用才會好用，不過好像也是因為綁著工具鏈跟相容性的原因，好像各家晶片雖然說有支援，但好像又支援的沒那麼好，特別是牽涉到很底層的硬體設定(像時鐘樹設定)就會變的特別麻煩，如果沒有這種需求就蠻好用的，很多設定、初始化都幫你省略了。會碰到Zephyr是因為使用 Nordic 的藍牙 SoC，最新的的 nrf connect SDK 基本上是建立在 Zephyr 上的，而 Zephyr 通訊相關的套件也很完整，很適合給 Nordic 的晶片用。

RT-Thread

RT-Thread 是一款由中國團隊主導開發的開源即時作業系統（RTOS），在中國的嵌入式系統開源社群算蠻熱門的，對中國製MCU(特別是一些RISC-V的晶片)支援度很好，但其他地方就比較少看到有人在用，跟Zephyr一樣也有蠻多工具可以使用，我自己還沒有用過，但讓我印象深刻的是RT-Thread社群有一個可以一鍵生成 STM32 bootloader 的工具，不過要使用要註冊帳號，而且還限定用中國的電話才能註冊…，就對中國以外的開發者不是很友好。

比較

幾種RTOS的差別

名稱	AzureRTOS (ThreadX)	FreeRTOS	Zephyr	RT-Thread
維護者	- 原為 Express Logic 開發，現由 Azure (Microsoft) 管理 - 被微軟購買後開源	- AWS（Amazon）及大社群共同維護 - 開源專案，有廣大社群支援	- 由 Linux Foundation 托管 - 眾多主要產業贊助商與貢獻者（如 Intel、Nordic 等）	- 中國嵌入式廠商與RT-Thread 社群
授權	- MIT 授權 (開源版本)	- MIT 授權 - 完全開源、商業可使用	- Apache 2.0 授權 - 完全開源	- LGPL 授權 - 可商業使用，但需遵守 LGPL 條款
主要特色	- 小巧的記憶體佔用 - 高效能可搶先式多工 - 整合除錯功能、其他外設控制模組	- 模組化設計，可高度客製化內核 - 協同式及可搶先式多工 - 詳細文件與巨大社群，支援度高	- 跨平台相容性好 - 追蹤與分析工具完善 - 與 Percepio Tracealyzer 整合	- 輕量化設計與微核心架構 - 效率高，啟動速度快 - 著重模組化與易用性
使用門檻	- 門檻中 - 提供專門的 API 與工具鏈 - 原生支援STM32，其他晶片支援則較少	- 門檻低 - 文件全面且社群龐大 - 新手上手相對容易，維護成本低	- 門檻高 - 須熟悉成套的開發工具鏈 - 社群與企業資源豐富，難度取決於應用深度	- 門檻中 - 設計較為精簡易懂 - 模組化讓功能可彈性擴充，但仍需對 RTOS 原理有基礎理解
社群與生態	- 因 Microsoft Azure 加持，工業界支持度高 - 開源時間較晚，社群支援相較少	- 擁有極為廣泛的使用者社群 - 豐富的第三方套件與論壇資源	- 企業和開源社群雙管齊下 - 大型廠商投入資源開發並提供硬體支援 - 文件與套件工具逐漸成熟	- 亞洲市場擁有極大用戶基礎 - 社群不斷壯大，第三方資源也逐年提升
適用範圍	- 消費電子、工業設備 - 高度資源受限或需要高效能的應用	- 廣泛用於各類微控制器與嵌入式裝置 - 適合中小型專案或原型開發	- 高度跨平台相容性的產品 - 需要整合多種通訊協定的裝置	- 小型物聯網裝置、家電產品、工業控制等 - 適合資源有限且需高即時性的情境
範例	- 高度整合 SoC 平台 - 網路裝置、醫療器械、消費性電子設備 - 資源特別有限但需穩定度的系統	- 物聯網邊緣設備 - 小型感測器、可攜式產品 - 工業自動化控制	- 高速通訊設備 - 需要完整追蹤與調試能力的工業設備 - 精密儀器及高可靠度應用	- 嵌入式微控制器 - 智能家居與可穿戴式裝置 - 需要快速啟動、高效率排程的場景

內核功能層面的差異

名稱	AzureRTOS (ThreadX)	FreeRTOS	Zephyr	RT-Thread
內核架構	- 輕量級、模組化設計 - 單核心即時系統 - 提供 preemption-threshold	- 單核心設計 - 透過設定檔自由啟用/停用功能 - 針對 MCU 移植方便	- 類微核心（microkernel）概念 - Kconfig 編譯時可裁剪/擴充 - 可支援多核心 (SMP)	- 微核心 + 模組化 - 通過 Packages 擴充 - 預設核心輕量、啟動速度快
排程機制	- 可搶先式多工 - 優先順序排程 - preemption-threshold 降低不必要的搶先	- 可搶先式或協同式多工 - 時間片 (time slicing) 可選 - 任務通知提高效能	- 可搶先式/協同式混合 - 支援多核心下的任務搬移 - 彈性設定時間片與搶先策略	- 以優先順序為基礎的可搶先式 - 切換開銷低 - 適合時限嚴苛的應用
中斷管理	- 提供快速中斷響應 - ISR 中可使用 IPC 原語 - 建議複雜邏輯放在 Thread	- 有完整的中斷優先級設定規範 - 提供「FromISR」API 與核心互動 - 避免高優先級中斷封鎖 RTOS 服務	- 針對不同架構有對應方法 - 允許在 ISR 後半段做較複雜處理 - 支援 `irq_offload`	- 中斷入口/出口簡潔 - 可在 ISR 裡做任務喚醒或 IPC - 建議將重任務放在中斷後處理或 Task
任務通訊與同步	- 提供 Semaphore、Mutex、Event Flags、Message Queue - Block Pool / Byte Pool 作為底層資源	- 有 Queue、Semaphore、Mutex、Event Group、Task Notification - Queue 是核心溝通管道	- 提供 Queue、FIFO、LIFO、Pipe、Mailbox、Semaphore、Mutex 等多樣化機制 - 信號（Signals）/事件等高階通訊	- 提供 Semaphore、Mutex、Event、Mailbox、Message Queue - 模組化 API，易於擴充
記憶體管理	- Block Pool（固定大小） - Byte Pool（彈性分配） - 適合小型系統	- 多種 heap 實作 (heap1~heap5) - 依需求選擇靜態或動態配置 - 須注意配置 Semaphore / Mutex 以確保多任務安全	- slab、mempool、heap 等多種分配策略 - Kconfig 可細調 - 需在編譯階段做良好配置	- mempool、heap 二分法 - 預設輕量動態分配算法 - 可搭配自訂或高階 alloc 演算法
除錯與追蹤	- 可使用 TraceX 等工具 - 整合度高，針對 Thread、Event、IPC 做可視化	- FreeRTOS+Trace、第三方 IDE 追蹤工具多 - 與 Percepio Tracealyzer 深度整合	- 統一的 Tracing 子系統 - 可連接 Tracealyzer、LTTng、SystemView 等 - 追蹤支援度豐富	- RT-Thread Studio 或其他插件 - 提供簡單 log 系統與線上除錯機制 - 社群亦有類似 FreeRTOS Trace 的追蹤方案
可移植性與擴充性	- 官方主要支援多數 ARM、RISC-V、MIPS - Microsoft 收購後社群逐漸擴大	- 幾乎所有 MCU 都有移植 - 大量第三方套件與驅動 - 可透過 AWS FreeRTOS 延伸雲端功能	- 原生支援多家大廠硬體 (Intel、NXP、Nordic…) - Kconfig + Devicetree 與 Linux 類似 - 企業支援與社群並重	- 在亞洲（特別是中國）用得廣泛 - 與國產 MCU、RISC-V 平台整合度高 - Packages 方式讓功能彈性擴充

總結

總結一下前面提到的四種RTOS：

AzureRTOS (ThreadX)：以高效能與小巧佔用聞名，擅長在嚴苛的資源受限環境中執行，另有良好的除錯工具與商業案例，對STM32的支援度好。
FreeRTOS：擁有巨大開源社群與靈活的擴充性，適用於廣泛的微控制器與嵌入式應用，在學術或商業專案皆常見，初學者適合。
Zephyr：受到 Linux 基金會與多家企業的大力推動，硬體支援廣泛，並有強大的追蹤與分析工具，適合需要高可靠度及詳細監控的中大型嵌入式應用
RT-Thread：架構輕量化、模組化明確，啟動速度快，適合物聯網及其他對即時性與資源效率要求高的場景。

Zephyr RTOS 兩種建立Thread的方式

Sun, 05 Jan 2025 22:20:31 +0800

Zephyr RTOS 兩種建立Thread的方式

Thread (執行緒)

在 Zephyr OS中，每個獨立的功能或任務可以放在不同的執行緒中執行，內部使用了輕量級的排程器，可以根據不同執行緒的優先級，以及執行緒本身的狀態（ready, running, pending 等），來決定哪一個執行緒能夠先被 CPU 執行，執行緒可以有以下幾個性質：

執行緒優先級（Priority）：數值越小表示優先級越高（Preemptive scheduling 的情況下）。
堆疊大小（Stack Size）：每個執行緒必須設定自己的堆疊空間，Zephyr 會在執行緒切換時儲存或恢復執行緒的上下文。
執行緒生命週期（Lifecycle）：可以在編譯期就被預先配置好，或在執行期動態配置與建立。

Zephyr 建立執行緒的兩種常見方法

在編譯期間（Compile Time）建立執行緒

Zephyr 提供了一個巨集 K_THREAD_DEFINE() 用於在編譯期就宣告並建立執行緒。只要程式一開啟並初始化 RTOS 後，這些執行緒就會自動被建立並進入排程器的管理。

K_THREAD_DEFINE()

1
2


#define K_THREAD_DEFINE(name, stack_size, entry_fn, p1, p2, p3, \
 prio, options, delay)

name：此執行緒的識別名稱，同時會生成一個 k_tid_t 型態的變數。
stack_size：此執行緒的堆疊大小（以 byte 為單位）。
entry_fn：此執行緒進入點函式（thread function），開始執行時要跑哪個函式。
p1, p2, p3：最多可傳入三個參數給進入點函式使用（都為 void* 型態）。
prio：優先級（數值越小，優先級越高）。
options：執行緒選項，通常先給 0 表示沒有特別的額外設定。
delay：執行緒開始之前的延遲時間（ticks 或毫秒），若填 0 表示不延遲，立即就緒。

在執行期間（Run Time）建立執行緒

另一種是在程式運行期間建立執行緒，使用 API 函數k_thread_create() 建立執行緒。這種方法在有些情況下會更具彈性，例如依據狀態或條件，動態啟動或終止執行緒，以免靜態建立過多浪費資源。

k_thread_create()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


k_tid_t k_thread_create(
 struct k_thread *new_thread,
 k_thread_stack_t *stack,
 size_t stack_size,
 k_thread_entry_t entry,
 void *p1,
 void *p2,
 void *p3,
 int prio,
 uint32_t options,
 k_timeout_t delay
);

new_thread：指向使用者自行宣告的 struct k_thread 物件，用來儲存此執行緒的控制區塊。
stack：指向此執行緒對應的堆疊空間（需先以 K_THREAD_STACK_DEFINE() 靜態或動態配置）。
stack_size：此堆疊的大小。
entry：執行緒執行的進入點函式。
p1, p2, p3：最多可傳入三個參數到執行緒函式。
prio：優先級。
options：執行緒選項，常用為 0。
delay：執行緒開始前是否要延遲。

範例

以下兩段程式碼，分別示範用 K_THREAD_DEFINE()（在編譯期間）或 k_thread_create()（在執行期間）建立兩個執行緒，分別執行 LED 漸亮漸暗（fade_led）與 LED 閃爍（toggle_led）的功能 github repo 以下是在Nucleo-F303K8的執行結果，左邊LED執行toggle，右邊執行fading

在編譯期間（Compile Time）動態建立執行緒範例

K_THREAD_DEFINE(fade_tid, 512, fade_led, NULL, NULL, NULL, 5, 0, 0);
- 建立一個名為 fade_tid 的執行緒，堆疊大小 512 bytes，執行函式為 fade_led，優先級 5。
- p1, p2, p3 都填 NULL，表示不需要傳遞參數。
K_THREAD_DEFINE(toggle_tid, 512, toggle_led, NULL, NULL, NULL, 5, 0, 0);
- 同樣建立名為 toggle_tid 的執行緒，stack大小、優先級參數與上面一致，執行函式為 toggle_led。

這些執行緒在編譯的時候就已經被「靜態配置」了，所以當系統啟動並執行到 main() 時，它們也就由排程器自動啟動並不斷執行。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76


#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>
#include <zephyr/device.h>
#include <zephyr/drivers/pwm.h>
#include <zephyr/drivers/gpio.h>

void fade_led(void *p1, void *p2, void *p3);
void toggle_led(void *p1, void *p2, void *p3);

// 利用 DT_ALIAS(pwm_led0) 與 DT_ALIAS(led1) 取得裝置樹中的設備訊息
static const struct pwm_dt_spec pwm_led0 = PWM_DT_SPEC_GET(DT_ALIAS(pwm_led0));
static const struct gpio_dt_spec led1 = GPIO_DT_SPEC_GET(DT_ALIAS(led1), gpios);

// 這裡定義一些常數用於控制漸亮漸暗的速度或節拍
#define NUM_STEPS 256U
#define SLEEP_MSEC 5U
#define SLEEP_TIME_MS 500

// 在編譯期間靜態建立兩個執行緒
K_THREAD_DEFINE(fade_tid, 512, fade_led, NULL, NULL, NULL, 5, 0, 0);
K_THREAD_DEFINE(toggle_tid, 512, toggle_led, NULL, NULL, NULL, 5, 0, 0);

// fade_led 會透過 PWM 設定脈寬來控制 LED 的亮度，製造 "呼吸燈" 效果
void fade_led(void *p1, void *p2, void *p3)
{
 uint32_t pulse_width = 0U;
 uint32_t step = pwm_led0.period / NUM_STEPS;
 uint8_t dir = 1U;

 while (1) {
 // 設定當前的脈寬
 pwm_set_pulse_dt(&pwm_led0, pulse_width);

 // 調整脈寬，控制 LED 往漸亮或漸暗方向
 if (dir) {
 pulse_width += step;
 if (pulse_width >= pwm_led0.period) {
 pulse_width = pwm_led0.period - step;
 dir = 0U;
 }
 } else {
 if (pulse_width >= step) {
 pulse_width -= step;
 } else {
 pulse_width = step;
 dir = 1U;
 }
 }
 k_sleep(K_MSEC(SLEEP_MSEC));
 }
}

// toggle_led 會透過 GPIO pin toggle 的方式，使 LED 閃爍
void toggle_led(void *p1, void *p2, void *p3)
{
 while (1) {
 gpio_pin_toggle_dt(&led1);
 k_sleep(K_MSEC(SLEEP_TIME_MS));
 }
}

int main(void)
{
 // 檢查 PWM 裝置是否 ready
 if (!pwm_is_ready_dt(&pwm_led0)) {
 printk("Error: PWM device %s is not ready\n", pwm_led0.dev->name);
 return 0;
 }

 // 設定 GPIO pin 為輸出
 gpio_pin_configure_dt(&led1, GPIO_OUTPUT_ACTIVE);

 // main 函式結束後，兩個 K_THREAD_DEFINE 建立的執行緒依然會持續執行
 return 0;
}

在執行期（Run Time）動態建立執行緒範例

若想要在程式執行的過程中（例如：由某個事件觸發）再建立執行緒，可以使用以下的做法： 1. 用 K_THREAD_STACK_DEFINE(my_stack_area, STACK_SIZE); 定義stack。 2. 定義一個 struct k_thread my_thread_data; 作為執行緒控制區塊（Thread Control Block, TCB）。 3. 呼叫 k_thread_create()，傳入上述的stack、控制區塊、進入點函式及其他參數來完成建立。

以下是一個範例，展示如何在 main() 函式中動態建立執行緒（此示例僅顯示與執行緒有關的部分，省略週邊初始化等重複程式碼）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


\* 
前面的程式碼相同
*\

// 宣告執行緒stack size
static K_THREAD_STACK_DEFINE(fade_stack, 512);
static K_THREAD_STACK_DEFINE(toggle_stack, 512);

// 宣告執行緒控制區塊
static struct k_thread fade_thread_data;
static struct k_thread toggle_thread_data;

// 這兩個函式和之前範例雷同
void fade_led(void *p1, void *p2, void *p3)
{
 // ...
}

void toggle_led(void *p1, void *p2, void *p3)
{
 // ...
}

int main(void)
{
 // 在執行期動態建立 fade_led thread
 k_tid_t fade_tid = k_thread_create(
 &fade_thread_data,
 my_fade_stack,
 K_THREAD_STACK_SIZEOF(my_fade_stack),
 fade_led,
 NULL, NULL, NULL,
 5, 0,
 K_NO_WAIT
 );

 // 在執行期動態建立 toggle_led thread
 k_tid_t toggle_tid = k_thread_create(
 &toggle_thread_data,
 my_toggle_stack,
 K_THREAD_STACK_SIZEOF(my_toggle_stack),
 toggle_led,
 NULL, NULL, NULL,
 5, 0,
 K_NO_WAIT
 );

 // k_thread_create 回傳 k_tid_t，可用於後續管理 thread
 // 例如 k_thread_suspend(fade_tid), k_thread_resume(fade_tid), k_thread_abort(fade_tid)...

 return 0;
}

比較

建立方式	特點	典型使用時機
Compile Time 建立	`K_THREAD_DEFINE()`	一開始已知需要的執行緒，以及系統資源充足時
Run Time 動態建立	`k_thread_create()`，在程式執行時期再分配資源	不確定需要多少執行緒，或需要彈性創建／釋放

如果確定在整個系統的生命週期中，執行緒數量固定，或是系統比較單純（例如一個簡單的多任務控制），用編譯期方式能減少程式碼的複雜度，也能讓程式一啟動就快速就緒。
如果系統中會動態產生／取消某些任務（如：偵測到新裝置才開新任務等），就可以使用動態建立的方式，提高系統彈性。

總結

靜態（編譯期）建立執行緒：
- 使用 K_THREAD_DEFINE()
- 簡單、快速、程式架構清晰
- 適用於固定且少數的長期執行緒
動態（執行期）建立執行緒：
- 使用 k_thread_create()
- 需要自行管理堆疊、控制區塊等
- 適用於需要彈性創建和銷毀大量或不定數量執行緒的應用場景

嵌入式系統常用的幾種MCU

Mon, 21 Aug 2023 19:32:31 +0800

嵌入式系統常用的幾種MCU

最近在實作嵌入式系統時因為系統需要更強的運算功能，決定捨棄原本常用的Atmega328p，尋找其他32位元MCU開發平台，選擇平台是件大事，每個平台的適用場景跟開發環境都不同，藉此機會來分析一下。

ATMEL系列 (如ATMEGA328P)

Atmega328p是ATMEL公司(美國)生產的8位元AVR架構MCU，常用於Arduino UNO板上
優點:容易入門且文檔完整、社群支援完整(Arduino生態系建立的很好)、良好的功耗效率(這點沒實測過但聽說很不錯)
缺點:與其他32位元MCU相比，處理能力有限、較少的內置記憶體和RAM、以他的性能來說小貴(35元上下)
適用場景: 初學者入門的專案(例如Arduino教學、簡單的嵌入式專案)、低功耗低成本的家用電子裝置

ESP系列 (如ESP32-C3)

ESP32-C3是Espressif Systems公司(中國)的產品，基於32位元RICS-V或Xtensa架構，自帶WiFi和藍牙功能
優點:直接包含WiFi和藍牙不用外接模組所以CP很高(一顆35-50元)、也是很多人在使用社群支援算完整、有內涵SPI flash的版本很方便
缺點:較高的功耗(雖然有深度睡眠功能)、系統穩定性聽說不佳
適用場景: IoT (物聯網) 需要WiFi或藍牙連接的設備、智慧家電、智慧穿戴裝置、不是很關鍵的東西。

STM系列 (如STMF103C8T6)

STMF103C8T6是STMicroelectronics公司(瑞士)的32位元ARM Cortex-M3微控制器
優點:運算功能強、具有多種接口、有低功耗模式的版本，具有較高的性價比(範圍大20-60元都有)、有很完整的開發除錯工具、在工業產品中比較常用
缺點:開發環境較為複雜、較少的RAM和Flash
適用場景: 複雜的嵌入式專案、需要強大的處理能力、工業自動化、無人機、高階的感測器系統

STC系列 (如STC89C52)

STC89C52是STC Micro公司(中國)生產的8位元8051微控制器。
優點: 8051架構非常的古老、具有廣泛的應用和大量的資料支援、價格超便宜(10-50元)、開發環境算簡單。
缺點:超舊的架構，處理能力有限、較少的內存和RAM、可以看作是人弱化版的Atmel系列、但因為功能單純，家電之類的很常用到
適用場景: 傳統的嵌入式系統，如家用電器控制、教育用途，學習8051微控制器的原理和程式設計、簡單的LED顯示、鍵盤輸入等基本IO操作

RASPBERRY系列 (如RP2040)

RP2040是Raspberry Pi基金會(英國)開發的32位元ARM Cortex-M0+微控制器
優點:高效的處理性能、RAM算大、開源資源和社群支援、簡單的開發環境(Micropython)、CP值也很高(35元)
缺點: 較新的產品，可能存在與硬體不穩定的問題有些Bug可能還沒有解法
適用場景: 要求高性能處理的嵌入式專案、影音運算、影像處理、複雜的演算法運算、大數據處理、跑TinyML模型等等

2023 Google Technical Program Manager 面試經驗

Fri, 07 Jul 2023 12:00:18 +0800

Google Technical Program Manager 面試經驗

前言

一直有許多Google SWE的面試經驗分享，然而Technical Program Manager(TPM)的面試經驗則幾乎沒有，其實不光是Dcard國外各大網站TPM的面試經驗分享也很少，因此來分享一下，雖然沒有拿到Offer，但有面到最後，經驗應該可以參考一下。

過去學經歷是112電資相關學碩，今年當完兵之後在比Google略大一點的公司當TPM。以前就有想進去Google，去年也投了Google SWE的面試，面完過HC等Team match時就遇到Hiring Freeze，詳細經歷可以參考：Google SWE 面試心路歷程，直到今年景氣變好才又開始Fit talk，結果連match了三個team都沒中，心灰意冷之際就收到另一個HR寄來TPM的面試邀請，抱著打聽情報的心態就跟HR排了個1:1，其實本來是對Google TPM缺沒什麼興趣，但在會議中被HR一波洗腦後，抱著那就試試的心態就接下面試邀請了。

時間

5/12 - 收到HR的TPM面試邀請
5/23 - 跟HR約1:1了解職缺
6/13 - VO:Technical Judgement*2
6/20 - VO:PgM + GCA
6/30 - 跟HR1:1通知面試結果: not move forward

面試

Google TPM的VO面試總共有五關，每關45分鐘:

兩關的Technical Judgement面試
一關Program Management related(PgM)面試
一關General Cognitive Ability(GCA)面試
一關Googleyness面試

可能因為之前已經面過Googleyness，所以這關就直接跳過了，實際上只面了四關，考慮到我技術能力可能比PM能力好一點，HR先幫我排了兩場Technical Judgement面試，結果不錯的話再排PgM和GCA，後來也證明這是正確的策略。

根據網路上的情報跟HR提供的文件，我認為Technical Judgement面試可能像是技術面試，可能會問Codeing，也可能會問System design，為此還翻出leetcode刷了幾題暖身；PgM可能會問跟經驗相關的問題；GCA則可能問解決問題的邏輯，但這部分當下也想不到有什麼準備方向，所以我只把HR給的參考資料看完，再多回想幾個小故事，由於實在想不到要怎麼準備，我也想辦法跟HR要些Hint，不過HR看起來已經給我全部能給的東西了，那就硬著頭皮上吧，學習嘛…。

順帶一提，TPM的面試是全英文的，四關差不多兩小時都在不停的說英文，這樣的要求也是可以理解，在Google這種公司Cross-function的溝通是極度仰賴英文的，這點也跟SWE面試很不一樣，SWE只有兩關英文，而且不會一直講話。

Technical Judgement 老實說聽到第一個問題時就開始懷疑人生了，我原本已經擺好寫Code的姿勢了，結果第一個問題是：「你最成功的專案什麼？」(詳細題目記不得了，反正是類似這的問題)，是那種我以為應該在PgM或GCA面試會問的問題，還好之前已經準備了不少小故事，姿勢一換搬出從大學、研究所到工作時做的還算有技術深度的案子，講解要解決的問題、我在團隊扮演的腳色、技術的選擇、克服的問題等，過程有來有回，面試官聽也還算滿意，不過一連的幾個問題也都是差不多這種類型，讓我有種我是不是走錯棚的錯覺，結束時還問了一下：「請問這個是Technical Judgement Interview嘛？」面試官愣了一下回：「是阿」，「Ok…」瞬間好像懂了甚麼又覺得甚麼都不懂，第二場Technical Judgement也是差不多的情況，總之自認表現還行，後來HR的feedback也是說Positive。
Program Management Related Knowledge(PgM) 有鑒於Technical Judgement面試問題實在出乎意料，因此再次問HR有關PgM面試的細節，HR還是回說他給的文件已經有資訊了，那就只能自行腦補了，既然名字叫Program Management那應該就是問PM相關能力吧，那應該多往PM的腳色去回答就行，果然不其然，面試的題目跟Technical Judgement幾乎一樣，而我就搬出之前做專案時怎麼定Scope、怎麼寫Spec、怎麼drive project、怎麼溝通協調，面試官看起來還算滿意我的回答，結束面試前小聊了一下這個position的情報，面試官覺得跟我目前的經驗差距頗大，不過還是祝我Good luck。
General Cognitive Ability(GCA) 到了GCA，我是真的想不到要怎麼準備了，如果是問解決問題的邏輯好像也很難準備。果然這關又問了跟前三關差不多的問題，然後我先從執行面去回答，但感覺面試官不太滿意，因此我又換一條路從技術面切入回答，面試官還是不太滿意，並建議我應該先從更High level的架構回答，因此我再給出了一個這方向的答案，不過沒有想得很透徹，應該是Bug滿滿，自己覺得答的超級爛，有感自己答的很爛，結束前後臉皮的跟面試官請教了一回，他也人很好跟我解釋了每一個問題的回答重點，大方向的概念是要先想出一個解決問題的框架，再將這個框架套入回答問題的框架去依序回答才有辦法打到得分點。

結果

後來再跟HR約了一次1:1，結果跟想像的差不多，前面表現都還不錯，主要掛在GCA，沒辦法再move forward，只能回去等還有沒有team match的機會了。

後來想了一下這次的面試確實有很多可以改進的點，除了現在真的菜，能講的經驗還太少外，就是對TPM面試回答的框架還不夠熟，這邊指的框架像是: 面對PgM的問題可以依序從以下幾點下手:

專案範疇與組織
專案執行
溝通與影響力
釐清模糊不清的情況

面對GCA的問題可以依序從以下幾點下手:

理解問題
蒐集資訊
找出解決方案
支持解決方案的證據
良好的溝通

下次要再嘗試Google TPM的面試時，應該要多花點時間打磨手上的案例，想辦法塞進這些框架組織，然後熟練使用這些框架回答問題，某種程度上也算是刷題吧。

結語

個人覺得TPM的面試比SWE面試還要難而且複雜，即便如此Google似乎很想找有EECS背景且有PM能力的人進去當TPM，只是這類人不多又或者沒興趣所以一直找不到人，如果有相關背景的人有興趣可以去嘗試看看。

如果有看完這篇對你有幫助，就順便祝福我早日拿到Google Offer啦。

附一張今年去101蹭飯的照片，好想進Google呀。

玩遍老鏡頭-Hasselblad Carl Zeiss CB 60mm f3.5

Sat, 13 May 2023 23:52:00 +0800

玩遍老鏡頭-Hasselblad Carl Zeiss CB 60mm f3.5

前言

在相機消費性市場中，在鏡頭領域的王者除了Leica之外，Carl Zeiss的鏡頭也是同樣出色，有著光學巨人之稱的Zeiss，透過強大的光學設計實力開發出各式各樣經典的光學結構稱霸至2023年的今日。

我的第一顆Zeiss鏡頭是為Nikon F卡口設計的Distagon ZF 35mm f2，經典的反望遠結構有著極佳的形變控制，經典的Zeiss T*鍍膜將反差與銳度控制的恰到好處，只可惜碩大的鏡身實在讓人難以接受，使用了一段時間後就將這顆鏡頭出手了。儘管如此，我依舊期待著重回Zeiss懷抱的一天，所以我後來就被輕易推坑了哈蘇 Hasselblad。關於我怎麼被推坑哈蘇的可以參考這篇：哈蘇A12片盒上片方法。

說到Hasselblad，不得不提到的就是Carl Zeiss為其設計製造的一系列中畫幅經典鏡頭，直接讓Hasselblad的相機躋身光學巔峰的相機之列，成了風景與商業攝影的神器，甚至在後來連著鏡頭一起帶到了月球去，由此可見Zeiss鏡頭的威力。

在Hasselblad的世界中最常見的即是那顆經典的80mm f2.8標準鏡頭，在中畫幅上等效約為50mm，有著較大的光圈已經熟悉且好掌握的焦段，成了Hasselblad最受歡迎的入門鏡頭。然而我並沒有選擇這顆鏡頭，主要原因在於這顆鏡頭在市場中的溢價太高了，此外焦段太過常見，我想要與他人較不一樣的畫面，就在一些機緣巧合下我不小心碰到了這顆CB 60mm f3.4，等效35mm的小廣角符合我街頭攝影的需求，此外這顆也被稱為是Hasselblad系統中較鋭的幾個鏡頭，在綜合考量下就選擇了這顆鏡頭當作我的Hasselblad 500C/M的掛機鏡頭。

我的哈蘇相機與鏡頭

介紹

Zeiss蔡司不愧是光學巨人，有著一項項經典的光學設計來克服各種工程上的難題，而Distagon的光學結構在蔡司的鏡頭歷史上與Biogon、Planar一樣令人印象深刻，Distagon是蔡司的反望遠結構，由於單眼相機如Nikon FM2與哈蘇在鏡頭後必須要有一塊反光鏡將鏡頭的影像反射至觀景窗中，法蘭距意即相機的鏡頭卡口與焦平面的距離，會將較旁軸相機如Leica徠卡來的長許多，這對於長焦鏡頭來說影響不算大，因為長焦鏡頭本身的設計能使得鏡頭的最後一鏡片遠離焦平面，然而這對於廣角鏡頭來說則困難許多，如施奈德經典的Angulon設計在Leica上鏡頭的最後一片鏡片幾乎是貼著Leica相機的快門簾，要是這種鏡頭用在單眼相機上肯定會被翻動的反光鏡打到，因此一種能夠挪出鏡後距又能夠達到廣角效果的結構勢必要被發明，也因此出現了Distagon這類反望遠的結構。

Leica的Super-Angulon 21mm f/4鏡頭¹

反望遠結構顧名思義就是相對於望遠結構的相反，設計是以倒置的望遠鏡光路為基礎，傳統的望遠鏡通常使用一組凸鏡來收集並將光線集中在一點，然後使用一組凹鏡來將這些光線散開，以放大觀察者看到的影像。然而，反望遠鏡頭的設計則採用了與此相反的概念，在鏡頭的前端使用一片凹面鏡搜集盡可能廣的光線，再將光線集中後再鏡尾用凸透鏡展開。這種設計允許鏡頭更好地糾正像差，並且能夠使入射的光線更接近垂直於感測器的平面，從而提供更清晰、更精確的影像。²

左邊是Leica 135mm APO的望遠結構，右邊則是蔡司的Distagon反望遠結構 ³⁴

然而反望遠結構的缺點也很明顯，由於需要使用大量的鏡片修正，使得這類的鏡頭體積都比較大，跟長焦鏡頭的大小有得一拼，此外越多的鏡片也帶來越多的像差，反望遠鏡頭能夠達到的廣角形變效果仍不如那些緊貼著焦平面設計的廣角鏡頭來得好，也因此後來哈蘇還專門為蔡司的Biogon鏡頭設計了專門的機身也就是Hasselblad 903 SWC，有此可見這樣的設計仍有Distagon無法取代得地位，更有如帶有極高傳奇色彩的蔡司Hologon鏡頭，僅用四片鏡片就做到了近乎完美的15mm廣角結構是天才一般的設計，可惜無法使用在單眼相機上，而不如Distagon來的實用，總而言之Distagon結構提供單眼相機的愛好者一探廣角世界的機會，只要你不怕那又大又重的鏡頭。

Hasselblad 903 SWC⁵

回到我所擁有的這顆Hasselblad CB 60mm f3.5鏡頭上，如同大多數的Distagon鏡頭一樣，這並不是一顆很輕便的鏡頭，相較於Planar結構的80mm f2.8，長度長了一點，重量也重了一點，60mm的焦段等效換算至135片幅約是35mm鏡頭的畫面，是個不折不扣的小廣角，有玩過Leica的都知道Leica的玩家鍾愛35mm的鏡頭，如七枚玉、八枚玉在Leica的世界是極品一般的存在，其中有部分來自於35mm小廣角的特性能接近人物並將人物與周圍的景物一並記錄下來，有相當好的寫實公用，這類的鏡頭也很自然就被定位為人文鏡頭，而在實際使用這顆給哈蘇的60mm鏡頭後也確實覺得用來拍攝人文會比拍攝風景來的小果好，而這與打多數人心中認為的用哈蘇進行風景攝影有點不同。

60mm這個焦段並非只出現在CB這個系列中，從最早的C系列鏡頭到後來的CF、CFi系列都可以看到60mm f3.5的身影，除了外觀一代一代的換，裡面的光學設計則是始終如一，而60mm f3.5與100mm f3.5更是被推崇為哈蘇中最銳利的兩顆鏡頭。儘管CB系列的鏡頭一直被認為是CF系列的廉價替代品，也確實在快門的功能上少了給哈蘇200F系列使用的F快門，但在哈蘇500系列上這顆鏡頭的使用體驗是與CF系列完全相同的，甚至光學鍍膜上可能比CF系列來的更先進，因此這仍舊是一顆在預算不足下非常棒的選擇。

實拍

說了這麼多來看看實際拍攝的樣子吧

先來張使用Fujifilm Pro400h拍攝的自由廣場大門，可以看出來仍有很輕微的廣角形變，而蔡司的光學美學一罐的高銳利度與高對比度，可以注意後方國家音樂廳的紅色柱子被凸顯出來。
再來看看使用Fujifilm Provia100f正片拍攝的效果：傍晚的天空泛著唯美的紫色，60mm的小廣角剛好可以把正個北車麥當勞收盡港式燒臘店懸掛著的物品，中焦後紋理都很清晰在菜市場中的場景，蔬果的鮮豔與標示牌的字凸顯了Zeiss鏡頭的特色，特別是蔬果的色彩被很好的還原出來，不得不說這個鏡頭非常適合這樣的場景拍攝，中畫幅本身的空間感加上60mm的小廣角讓人非常有身入其中的感覺
使用哈蘇當然還是要當一回風景攝影師，來看看以下用Fujifilm Pro400h拍攝的澎湖風景中規中矩的澎湖大橋在七美島上某一側海灘的建築，60mm的鏡頭可以很好的把前景跟背景融合再一起有趣的橘色石墩跟藍綠色的海相互襯托，60mm的鏡頭把地平線置於中央時前景的地面佔比就會較大這張更像是鏡頭測試了，可以看出在邊緣是有點形變的透過將前景的亂石與背景的建築融合，更能凸顯島上的荒蕪廣角鏡頭難以突現遠處的風車，天空的比例會變得太多
最後再來兩張在低光源下的黑白照片，是用ILFORD FP4拍攝讓我更堅決這個就是個人文鏡頭無誤…

結語

選擇一顆鏡頭需要考慮他的應用場景，這也是為何我對這顆CB 60mm f3.5是又愛又恨，愛他是因為35mm是我鍾愛的焦段，我非常喜歡人文、街頭主題的攝影，可惜他是一顆哈蘇鏡頭，哈蘇他又大又笨鐘的機身注定了他是一台操作非常耗時的相機，適合慢節奏的攝影，而對於街頭快速的變化，我覺得哈蘇很難適應，哈蘇注定是一台為風景、為商業攝影而生的一台相機，在這樣的情景下小廣角鏡頭就顯得不上不下，不如那些超廣角鏡頭畫面來的震撼，也不如長焦鏡頭能夠專注在某一小塊範圍的景物，或與對我而言哈蘇搭配長焦鏡頭會是更適合我的選擇，所以在2022年的年底就將這顆鏡頭轉讓了。

以此文紀錄曾經擁有的這顆鏡頭。

科技業台商與外商公司暱稱

Sat, 06 May 2023 14:52:00 +0800

科技業台商與外商公司暱稱

台商

IC設計 (豬屎屋)

項次	公司名稱	Ptt、Dcard暱稱	說明
1	聯發科	發哥、發弟、M、大M、麥當勞、篤行路麥當勞	分紅多的時候就是發哥，少的時候就變發弟，因為被稱為M，員工自嘲為篤行路麥當勞打工仔，去上班謙稱為鏟薯條。叫大M是因為曾經有小M(晨星)
2	聯詠	滷肉、N	聯詠的英文是Novatek音似「滷肉」
3	瑞昱	螃蟹、R、帝王蟹、寄居蟹、海產店	Realtek、Logo就是一隻螃蟹，帝王蟹專指分紅特別多的部門，如果分紅少，鄉民就鄙稱寄居蟹，因為是螃蟹所以也有人稱海產店
4	群聯	全聯、P、請支援收銀	群聯音似全聯
5	慧榮	S
7	奇景	海馬	Himax音似海馬¹
8	達發	客運、發哥子公司	發哥的一家子公司，英文名是Airoha發音似早期的阿羅哈客運
9	瑞鼎	鼎王	取鼎字。由於鼎王麻辣鍋是相較昂貴的餐廳，故這是分紅好的意²
10	矽創	洗窗	取矽創的諧音
11	敦泰	保全	有一家保全公司叫敦泰保全
12	奕力	一粒、粒粒	奕力的諧音。或取粒字，源自《憫農詩》：「誰知盤中飧，粒粒皆辛苦」，為員工自嘲工作辛苦²
13	華邦電	邦邦
14	信驊	股王
15	新唐

品牌廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	宏達電	紅茶、紅茶店、Hㄒㄈ、阿姨	紅茶店是取諧音，阿姨是指雪紅阿姨
2	華碩	石頭	華碩品質，以卵擊石
3	宏碁
4	微星	小星星、中二龍、微薪、G星	微薪是只薪水給的不多
5	技嘉	雞排店	英文名字是GIGABYTE，GIBYTE發音跟雞排很像²
6	群暉	亞東Google	公司在捷運亞東醫院站附近，跟Google一樣吸引很多軟體頂尖人才

面板廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	友達	戀人、戀人未滿	取名稱：友達以上，戀人未滿
2	群創	包子	之前與奇美電子合併，因奇美包子而得名

系統廠

項次	公司名稱	Ptt、Dcard暱稱	說明
1	和碩	皮卡	音似其英文名Pegatron
2	廣達	肉鬆、肉鬆店	有一家肉鬆廠叫做廣達香肉鬆
3	緯創	W、大W
4	緯穎	小w、we win	因為是緯創的子公司
5	仁寶	寶寶
6	光寶	點燈	英文名字LITEON，表示light-on²
7	研華
8	華擎	小石頭、妖擎	因為華擎是由華碩分家出來的所以叫小石頭，又專門生產一些奇怪的主機板和產品(妖板)
9	台達店	三角、三角形	Logo是一個三角
10	鴻海	海公公（取海字）、海邊、海底、紅海	取海字。《烏龍派出所》的阿兩常說：「你家住海邊啊！」這句話意指「多管閒事」（因為海邊鎖管(小卷/透抽)很多）。之所以稱鴻海為海邊，是暗指公司管很多²
11	英業達	小英	名字裡有英字
12	啟碁	道士	取諧音，道士會起乩

半導體製造

項次	公司名稱	Ptt、Dcard暱稱	說明
1	台積電	台GG、GG、護國神山、神山、大哥、祖墳冒煙	因為台灣有台積電因此中國不敢隨便打台灣，所以稱之為護國神山。祖墳冒煙是在說能近台積電的人都是有祖先保佑
2	聯電	二哥、U、大碩	因其員工常以該公司為跳板跳槽至台積電，近似研究所補習班「大碩」而謔稱之
3	世界先進	仙境、RO	取先進兩個字的諧音
4	日月光	神教	出自金庸小說《笑傲江湖》的虛構組織日月神教²
5	南亞科	牙科
6	華亞科	滑牙科
7	矽品	三口、三口組	三個口、很多口的那間、三口組 (因最後一個字品，而被鄉民取這些名稱 )
8	力積電	假G、小GG	叫假G是因為名稱跟台積電很容易混淆

軟體、電信、銀行

項次	公司名稱	Ptt、Dcard暱稱	說明
1	中華電信	種花、種花電信、種花點心、小公司（出自徐旭東）	取諧音，加上工作很悠閒
2	台灣大哥大
3	遠傳	大公司	為網友呼應其老闆徐旭東之言論而謔稱之
4	趨勢	亞洲最大純軟
5	國泰	大樹、花椰菜	Logo是一顆大樹，大樹長的很像花椰菜
6	Dcard	豬腳、低卡、低能卡	取諧音、又Dcard上的發文通常太過浮誇很低能故稱低能卡
7	愛卡拉	卡拉雞

外商

IC設計製造

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Qualcomm(高通)	Q
2	Marvell(邁威爾)	漫威		Marvell發音跟漫威一樣
3	Nvidia(英偉達)	NV
4	Intel(英特爾)	牙膏廠	牙膏廠、藍廠	core i系列每一代效能都高一點點就像擠牙膏
5	AMD(超微)	推土機廠	推土機廠、紅廠	AM3時代處理器名稱
6	Micron(美光)	光光、發光、人生發光		來自徵才標語「加入美光，人生發光
7	Texas Instruments(德儀)
8	Broadcom(博通)
9	NXP(恩智浦)

品牌與軟體設計

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Google(科高)	G	G社、狗家	狗家取字Google的諧音
2	Microsoft(微軟)	M$、MS	巨硬、巨嬰³	M$是指微軟什麼東西都要錢，巨硬來自於微軟字面上的相反
3	Meta(臉書)		臉家、M社	Facebook翻譯為臉書
4	Amazon(亞馬遜)		亞麻、雨林、香蕉廠³	亞馬遜以對員工小氣聞名，公司福利只願意提供香蕉給員工
5	Apple(蘋果)	阿婆	A社、水果家
6	IBM(國際商業機器)	外星科技	大藍	據說真的有從事外星科技
7	Netflix(網飛)		N社、網飛
8	Tiktok(抖音)	父母白養	字節	取自「抖音一響，父母白養」
9	Dropbox		D社、丟盒子
10	Airbnb
11	Salesforce		賣力
12	Orcale(甲骨文)		烏龜殼
13	Sony(索尼)	$ony、大法		相機技術很厲害，就跟魔法一樣
14	Dell(戴爾)	呆鵝
15	騰訊	企鵝		騰訊的Logo是一隻企鵝
16	百度		百毒	中國網友慣稱呼，諧音
17	Uber		黑車
18	Uber Eats	吳柏毅
19	Foodpanda	熊貓
20	Garmin
21	Samsung(三星)	三爽

半導體設備商

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	ASML(艾斯摩爾)	A4ML	阿斯麥	A4ML是只這家公司給的分紅很少，阿斯麥是中國ASML的翻譯
2	TEL(東京威力科創)
3	ASM(先藝)
4	AMT(應材)
5	KLA(柯磊)
6	LAM(柯林研發)

系統廠

項次	公司名稱	台灣暱稱	對岸暱稱	說明
1	Supermicro(美超微)
2	Lenovo(聯想)

知名企業家

項次	名稱	暱稱	說明
1	郭台銘	果凍
2	Lisa Su(蘇丰姿)	蘇媽
3	Jason Huang(黃仁勳)	老黃、皮衣刀客、AI教父
4	Sundar Pichai	皮柴
5	Elon Musk	鋼鐵人、馬投顧	其言行對加密貨幣很有影響力
6	Sam Altman	奧特曼
7	蔡力行	Rick	聯發科CEO

湖口裝甲五八四旅聯兵二營二階段訓心得

Fri, 05 May 2023 17:05:31 +0800

湖口裝甲五八四旅聯兵二營二階段訓心得

時間過得很快，距離我離開五八四旅 (2022/10/26~2023/01/06) 也已經四個月了，隨著時間一點點遠去軍中的記憶也一點一點的流逝，是時候將這段時間的記憶記錄下來。

前言

這段故事大概要從新訓尾巴時的抽籤開始說起，對於新訓的經驗有興趣的人可以看我的上一篇文章，還記得抽籤時大家盤算著各式的抽籤技巧，像是分析籤筒中目前還剩的單位、往籤筒的哪個方向摸比較容易有好籤等等，我們這梯分因為都是台北兵，相對好的籤就如關指部、後備指揮部等位在台北周邊的部隊，這些單位放假最容易回家，差的就如馬防部、花防部這些回家非常麻煩的地方，而像21砲、584旅就是不上不下的一群，而偏偏這部分的籤又是最多的，而我剛好就抽到了584旅的補給兵。

還沒下部隊大家就各種從班長、營長打聽各種跟抽到的部隊相關的訊息，而584大概就是中規中矩的那種，戰車營、實兵部隊可能會很操、吃的可能不錯，聽起來就不是特別爽的單位，位於新竹湖口雖然離高速公路很近，但也沒有到非常容易回家，不過想到還有更慘的花防部，心理也就比較能過得去了。

結訓假回來的第二天，在新訓同梯彼此的道別下；帶著重重的黃埔包跟難吃的超商麵包，坐上了前往584旅的巴士，其實還一位新訓同床的也抽到這單位，再加上同連也有十幾人，這一路上並不孤單，巴士早上十點多從台中成功嶺出發，三四個小時後開進了湖口營區，開始了我在584旅的生活。

關於二階段的生活

二階段的生活跟新訓天差地遠，新訓時沒有自由，而二階段有了部分的自由，舉個例子：手機，有了手機讓我多了點心靈慰藉可以撐過剩下的兩個半月。

波折的入營

當從成功嶺的大巴緩緩的開進位於湖口的營區時我們以為已經抵達了我們的新家，實際上這趟旅程才剛要開始。抵達時大巴停在542旅營區一個集合場，看著其他車的同梯陸續下車，心中開始疑惑不是已經抵達了嗎？大約等了十分鐘大巴又再次啟動，奇妙的事情發生的，大巴竟然緩緩開出了營區，此時心中忽然想起：湖口有好幾個營區，我們應該是要去另一營區對吧，果然幾分鐘後我們抵達了位在湖口另一側的584旅營區，映入眼簾的是跟成功嶺差不多老舊的房舍跟餐廳，心中不禁OS：說好的新營舍呢…，停車後我們便被叫下車至餐廳集合，並開始分配單位，也同時觀察著被叫到的人去了哪裡，又等了一段時間終於輪到我們了，被叫出去後原本以為會步行至我們的營舍，結果我們被安排搭上了一輛中戰，接著讓人疑惑的情況再次發生，我們竟然又離開營區了，此時又突然想起先前好像有長官說過584旅還有一個營區在桃園，心中一驚：不會吧，我們要去桃園了！？

中戰緩緩的開，慢慢穿過湖口的巷弄，約莫過了20分鐘，中戰開進了一個想都沒有想過的地方：陸軍北測中心，開進大門時還忍不住看了一下手中的籤，我抽到的是584旅沒錯啊，不得不說對於北測中心的第一印象是不錯的，這裡沒有灰灰黑黑的房舍或是迷彩的掩體，相對的是紅色外觀的大樓跟一大片整齊漂亮的草皮，比起軍營這裡更像是一間學校，真是還好被分配到這裡，不用再忍受向成功嶺那樣破舊到不行的營舍。後來經由長官解釋，由於584旅的歷史因素，我們被分配到的聯兵二營要暫時寄居於在北測中心。

中戰輪車的外觀

關於五八四旅

為中華民國國軍駐守於臺灣新竹縣的陸軍部隊，編配在陸軍第六軍團指揮部，裝甲五八四旅隊名「登步部隊」，前身為陸軍步兵第二八四師，在精實案解編前本師長期駐防在金門南雄防區，因此又有「南雄師」之稱。

裝甲五八四旅，從名稱就知道我們是一個裝甲車部隊，所以除了一般軍車外，部隊裡還有非常多的甲車跟戰車，甲車主要是負責運送步兵到作戰地點，有時也能提供少量的火力支援，戰車主要就是負責輸出火力，因為有裝甲部隊在此，每天都可以聽到戰車在營區繞圈圈的聲音，還蠻壯觀的。

這是甲車

五八四旅又有另一個名稱，叫做 「登步」部隊，傳說在國共內戰時期曾經在中國沿岸的登步島打勝仗，後來就被授予登步的名稱，由此也可以看得出來五八四旅是個充滿歷史的部隊，服役期間剛好碰到隊慶，順道去參觀了隊史館，是很特別的經驗，也對國軍有更深的認識。五八四旅也是非常精實的部隊，在來湖口之前部隊是駐紮在金門，位在國防的第一線，對於戰力的要求非常的高，而在民國八十幾年時才因為種種原因轉移回台灣駐紮在新竹湖口，在來之前湖口本來就是軍事重地，有數個旅在這邊駐紮算是非常壅擠，而五八四旅算是新鄰居，因此只能分散寄生在湖口的幾個營區中。

我所在的營稱為 「聯合兵種第二營」，因為種種原因目前駐紮在陸軍北測中心，這個地方是給用來測驗戰力用的，也因此經常會看到許多部隊帶隊來此進行戰鬥、體能之類的測驗，北測中心位在湖口的勝利路上，大部分湖口人應該都知道勝利路的一側從北到南全部都是軍營，要抵達這並不如成功嶺容易，成功嶺離高鐵站很近，五分鐘的車程，甚至走路都能到，而湖口營區距離新竹高鐵站至少二十分鐘車程，比較近的車站是湖口火車站，但速度就不如高鐵快，從新竹高鐵站出來後只要跟司機說要到勝利路上的第一個遇到的營區(但正式的名稱是湖口四營區)就行，路程會經過一段曲折的爬坡，最後彎上湖口的勝利路，從高鐵站到營區比較容易，但從營區到高鐵站就很麻煩，大多時候叫不到車，就算叫到了也可能要等個二三十分鐘，對於只有少少假期想急著回台北的義務役來說並不是很友善。

登步隊徽¹

兵種與單位分配

我們這梯抽到584旅的大概有以下幾種兵種：步槍兵、文書兵、補給兵、汽駕兵，那這些兵種跟二階段在做的事情有什麼關係呢？答案是完全沒有關係，管你抽到什麼兵，那怕是名字很帥的六六火箭彈兵到二階段的部隊後全部都是步槍兵，主要是我們在新訓階段也只受過步槍的訓練，所以只能操作步槍。

雖然說都是步槍兵，但做的事情還是不太一樣的，而主要跟分配到的單位有關，你會分配到甚麼單位跟抽到的兵種無關，單純跟新訓時所在的連有關，我猜他們應該只是很單純的按照各單位人員需求的排下來，也因此新訓同連的人到584旅後也有很大的機會會在同一營跟同一個連中，像新訓時我所屬的連隊是火力連，而大多數火力連中抽到584旅的人後來也都分配到了聯兵二營的戰支連，只有少數人被分配到隔壁的聯兵二營的火力連。二階段所做的事情很大程度會跟所在的連隊性質相關，在聯兵二營中有單純提供火力的連如：火力連、戰一連、戰二連…，也有單純支援性質的戰支連，戰支連全稱為戰鬥支援連，負責作戰時的支援工作，除了進攻火力支援也要提供如伙食、醫護、通訊、維修相關的支援，就日常生活來說單純提供火力的連操課多，而戰支連則是雜事多，能被分到戰支連事很幸運的，每每看到其他連隊的人每天要把槍械彈藥搬出來備戰傍晚在搬回去，就會覺得還是做做雜事比較爽啦。

由於戰支連要支援的事務很多，因此內部又分為數個排，每一個排負責一項業務(伙食、醫護、通訊、維修)，而我所分配到的排稱為營部排，主要在協助營級長官處理各種雜事，我在期間有接觸到的有像幫長官打飯、打掃衛生、影印資料、搭建指揮所等等，都不算事非常粗重困難的工作，不過因為會第一線接觸營級長官，做事要如何讓營級長官開心是很重要的。

二階段一定要帶的東西

二階段突然間多了許多可以做自己的事情，生活不再像新訓時那樣單純，也因此多了許多需求。

消費

零錢 - 二階段會突然多了很多機會可以用錢，你會有很多時間可以上營站(基本上休息時間都可以去，只要營站有開)，營站除了有各式各樣的零食飲料可以讓你感受外面世界的美好外，還有熱食部，如果不想吃伙房提供的午餐也可以試試營站的炒麵、滷肉飯、雞腿排，這些大多都是付現，帶個一兩百元幾天內就會花掉，除此之外有些班長對志願役很不錯，也很願意幫義務役外帶外食，你想想昨天吃肯德基今天又吃Pizza hut，這是新兵時完全無法想像的事。
可以自動加值的悠遊卡 - 那種整合悠遊卡的悠遊卡簡直就是小叮噹的法寶，除了有部分飲料機可以用之外，營站、或是遠一點走到542旅營區的OK便利商店都可以使用悠遊卡，想買什麼就買什麼，非常的方便。

食物

泡麵 - 當你的行動範圍擴大到整個湖口營區時，幾乎沒有什麼日常用品是買不到的，泡麵也是一樣的道理，不過如果有特定口味想吃的還是可以事先從外面帶進去囤貨，深夜時寢室內泡個來一客真是邪惡，偶爾拿泡面去孝敬長官搏感情也能換來一點點輕鬆。
零食 - 同理，大多數零食也都能買到，大多數時候你會懶得走那麼遠取買東西，所以提早帶進去囤著比較方便，還可以賣給臨兵。
飲料 - 飲料在營區內的選擇比較少，而且還有很多那種在外面完全沒有看過的奇怪飲料，相對的那種利樂包的飲料選擇也很少，只有OK有少量，如果想要和特定的幾款也建議收假時帶回去。

衣物

外套 - 平常操課時間是不能夠穿自己的外套的，除了早上集合跟運動時間，我二階段的時候是11月到1月，這段時間新竹風大又冷，真的很需要有一件保暖的外套，新兵發的白綠色外套真的很爛，如果是在冬天入營的務必要帶。
保暖衣物 - 冬天入營的話一定要帶，特別是天氣特別冷的幾天晚上睡覺真的會被冷醒，所以有一些厚的長褲或是衛生衣是很必要的。
運動鞋 - 二階段的運動時間也可以穿自己的運動鞋，所以如果覺得工發的鞋子很難穿或是穿壞了，那也可以帶自己的運動鞋進去。
運動褲 - 新訓時運動短褲只有發一件，因為短褲每天都會穿，所以通常一個禮拜才洗一次非常噁心，二階段時運動時間就可以穿自己的短褲了，這樣就可以避免一件褲子穿好幾天的情況，自己的褲子也比較舒服。
洗衣粉 - 新訓時洗衣服是要洗的衣服用洗衣袋集中後找外面的廠商來統一送洗，二階段由於這樣的需求沒有很大，預設是直接用營上的洗衣機自己洗，那當然洗衣粉的部分就要自己帶了。不過我們二階段時同梯的義務役比較多，有跟長官提想要統一送洗，所以後來長官也幫我們找到廠商處理，不用自己去搶洗衣機有人幫忙洗好真的很方便。

餐具

碗公 - 二階段時上完餐廳餐具都會統一回收保管，二階段時碗盤等則是自己保管，如果覺得營上提供的餐盤很難用、很難洗，也可以自己帶大碗公，裝菜裝飯會方便很多。

寢具

棉被 - 折棉被絕對是當兵起床時最痛苦的事，新訓時對棉被的要求很高力求有稜有角，花個二三十分鐘摺棉被不誇張，二階段後不在會有長官要你一定把棉被攤開，又或者你跟本可以直接蓋自己的棉被，白天時在再把完全沒攤開過的棉被擺回去，自己的面被塞回內務櫃裡。
很多的行動電源 - 我們連上的規定是晚上可以使用延長線接手機充電頭充電，但白天就只能用行動電源充電了，千萬不要小看手機的使用量，由於在營區內太無聊，一天手機使用時間是十個小時起跳，想當然行動電源也是隨身帶著，通常有兩個行動電源可以確保每天至少有一個行動電源是有電的。
電源轉接頭 - 要充手機或是行動電源那當然需要那種110v轉type-c的變壓頭，最好多帶幾個備用以免不見。
有線耳機 - 在軍中原則上不能帶藍芽耳機，只能帶有線耳機，二階段後耳機也是隨時都會用到，除了跟家人女友講電話會用到，無聊時想要低調的看看劇、看看youtube也是很好用，只是在操課時間戴耳機務必要低調，被長官看到還是會生氣的。還有耳機也建議多帶幾條，由於使用的機會很多，壞掉的機會也多，我在營區時就有不小心拉斷一條，又沒有準備備用的，導致那一周要講電話或是看影片都變得很麻煩。

藥物

感冒藥 - 一到了二階段突然就變得很容易感冒，有可能是跟臨兵帶在密閉空間的機會變多。感冒時北測中心雖然有醫務室，但醫官蠻不給力的，除了開點綜合感冒藥外就只會轉診而已，所以如果症狀不是太嚴重那就自己吃吃感冒藥就好。
防蚊液 - 二階段長官也不會要求你一定要掛蚊帳，雖然晚上睡覺窗戶都會關起來，但難免會有蚊子偷溜進來而且趕不走，這時候就只能靠防蚊液或是一些止癢的藥了。

每日的行程

相較於新訓每一個環節都被規劃的好好的，二階段的生活相對下彈性許多，除了集合時間很固定外，每日的集合時間、休息時間、吃飯時間則沒有那麼固定，大多會根據當日的操課、業務內容而有不同，相較新訓時那種分分秒秒都很關鍵的生活，二階段真的壓力小不少。每日的行程差不多如下：

06:00 起床 - 我們二階段的時候是按照冬令時間，起床時間比夏令時間的05:30可以多30分鐘的睡覺時間，二階段就不像新訓時會提早個30分鐘起床了，反正對棉被的要求沒有很高，早上大概花個十分鐘就可以搞定棉被跟盥洗。
06:20 集合 - 盥洗完後就可以慢慢移動到集合場集合，這個集合穿平常運動時的一份就可以了，不同於新訓時只有義務役集合，昨日有留守的義務役也會著集合，看著義務役們也是一臉睡眼惺忪很有趣，這個集合就是值星班長大概看一下人有沒有少，沒少的話班長心情好就帶大家做一下操，不過大多時候就直接放大家下去吃早餐，建議集合時就偷偷把碗筷塞進口袋裡帶下來，這樣就不用在多跑回寢室一趟了。
06:00 ~ 06:30 吃早餐 - 相較於新訓時人太多餐廳坐不下，二階後早餐時間餐廳超空，志願役有外膳宿很少近來才吃早餐，我們義務役有時也想要回去偷睡一下，也不一定會想吃，584旅的早餐一開始來的時候很好吃，後來不知怎的越來越差，只剩下饅頭、幾樣小菜、稀飯、跟甜湯，中規中矩吧。
07:30 集合 - 這次集合就要全副武裝(鋼盔、S腰帶)，然後會進行唱歌答數，也就是先來幾個唱歌答數，然後帶唱軍歌像是「為陸軍當家」這種。
07:300 ~ 11:00 操課 - 就看當天的行程是什麼，由於我們部隊正在經歷下基地前訓，因此有不少針對下基地的訓練內容像是CPR、戰傷救護、夜視鏡等等，主要還是訓練志願役為主，義務役就在旁邊充人數，沒課的話就在中山室保槍或是滑手機耍冗，偶爾會被叫出去幫忙。
11:00 ~ 12:00 午餐 - 跟新訓不同，午餐前不會再集合，就下課後各自回寢室卸裝拿碗筷然後自己到餐廳吃飯，吃完就自己回去休息，午餐相較新訓就還不錯，通常會有兩到三個主菜，然後菜量也很足，不會有新訓時菜不夠的情況，另外就是一甜一鹹的湯可以選，有時候會有加菜，可以吃點不一樣的東西像是火鍋。
12:00 ~ 13:30 午休 - 午休就回寢室休息睡覺，不要亂的話愛做什麼就做什麼，沒有人會管你。
13:30 集合 - 一樣也是全副武裝，又再一次唱歌答數，有時候中午有出勤務(洗餐桶之類的工作)的話可以補休到兩點，就可以再樓上寢室偷聽樓下這次軍歌唱的如和，義務役因為經常在練都會唱，但志願役因為平常很忙就都不太會唱，整體就要靠義務役拉高平均值不然就會被營值星罵。
14:10 ~ 16:00 操課 - 繼續做跟早上差不多的事
16:00 ~ 17:00 運動 - 跟新訓不同，二階段有運動時間，有時候連長心情好會來帶體能訓練，不然平常就跑跑步然後去籃球場打球，真的是蠻健康的生活，後來我跟同梯的幾位會一起長跑到542營區，大概三公里，回來的路上順路繞去萊爾富偷買點東西。
17:00 ~ 18:00 晚餐 - 吃的跟午餐是一樣的東西，不過志願役因為有外膳宿，所以會吃的人也不多。
18:00 ~ 19:00 盥洗 - 看你要不要這個時間洗澡，沒洗的話晚點也有機會，不著急。
19:00 集合 - 這個集合就只會集合義務役看看人有沒有少，再找點事情給義務役在晚上做，大多時候就練軍歌練個一小時或是打掃環境，遇到比較好的值星班長集合完就直接放我們下去休息。
19:00 ~ 20:00 夜間課程 - 同上，就練軍歌跟打掃，比較特別的有夜行軍跟夜間射擊，不過只有各一次，但是是很難得的經驗。
20:00 ~ 22:00 自由時間 - 一樣就想幹嘛就幹嘛，這時候還沒盥洗的就去盥洗，不然就在寢室耍廢，看youtube、玩手機、找女友聊天。
22:00 就寢 - 就寢時要關燈，不過要不要睡就是你家的事，要玩手機到天亮也是可以的，有時候也會請外膳宿的志願役在這個時間從外面帶點好料進來吃。

https://zh.wikipedia.org/wiki/%E4%B8%AD%E8%8F%AF%E6%B0%91%E5%9C%8B%E9%99%B8%E8%BB%8D%E8%A3%9D%E7%94%B2%E7%AC%AC%E4%BA%94%E5%85%AB%E5%9B%9B%E6%97%85 ↩︎

Google Taiwan Hiring Event Recording

Wed, 26 Apr 2023 09:00:18 +0800

Google Taiwan Campus Talk, 2023 線上直播校園徵才說明會

Date: 2022/11/11
Title: Google Taiwan Campus Talk, 2023 校園徵才說明會
Agenda:

主題	講者
Welcome & Google Culture
Hear more from the Googlers
Fireside Chat with all the

Recording:

Made by Google: Behind the Scenes Livestream

Date: 2022/11/5
Title: Taiwan Made by Google: Behind the Scenes 2022
Agenda:

主題	講者
Next-gen Google Tensor processor
Fireside Chat : Pixel Camera
Live Q&A and Latest Opportunities @Google Taiwan

Recording:

Google 台灣 Platforms 團隊介紹＆徵才說明會

Date: 2022/07/08
Title: 2022 Google Taiwan Platforms Team Face to Face
Agenda:

主題	講者
Google Taiwan Platforms Team at a glance	Director Platforms HW Test/Quality & Eng Labs
Software & Hardware Engineers in Google Taiwan Platforms Team	Hardware & Software Managers
Google Hiring Process & Tips	Recruiter
All You Want to Know - Q&A & See You at Google!	All Speakers

Recording:

Google 台灣軟體開發及測試團隊分享＆招募說明會

Date: 2022/05/18
Title: Google 台灣軟體開發及測試團隊分享＆招募說明會
Agenda:

主題	講者
解密Google 台灣軟體開發團隊
Googler 分享 - Engineering Manager\Test Engineer\Tech Lead 及 Software Engineer
Google 招募流程
Q&A 時間

Google 台灣 Silicon & CPU 團隊面對面

Date: 2022/04/29
Title: 2022 Google Taiwan Silicon & CPU Face to Face
Recording:

Campus Talk 校園徵才線上說明會

Date: 2021/11/18
Title: 2022 Google Taiwan Tech Campus Talk YouTube Livestream
Recording:

Life@Google台灣硬體工程師篇

Date: 2019/07/19
Title: Life@Google台灣硬體工程師篇
Recording:

成功嶺158T一〇一旅步四營新訓心得

Tue, 13 Dec 2022 13:32:31 +0800

成功嶺158T一〇一旅步四營新訓心得

寫這篇文章的時候距離新訓結束已經一個半月左右，而距離結訓還有一個月，趁著記憶還不算太遙遠，紀錄一下我對新訓的印象以及心得。

前言

實説話，到我當兵的前一個月我還真的沒有想過我會進來服常備兵役，至少從體檢後我還是保持著再多複檢幾次應該可以用扁平足當個十二天補充兵，到了今年一月(2022)拿了幾個預聘研替offer，大概也覺得畢業後我應該只要去替代役營唱唱歌就可以準備去上班了，到後來決定去一家沒有研替的外商，也還是覺得當個補充兵應該是有機會，因爲八九月時BMI一度飆過29，離補充兵標準不遠了，誰知道後來被困在水深火熱的研究所，一紙兵單竟成了畢業密碼，想來也覺得荒謬，從沒想過我有一天會如此的期待兵單的到來。

在我的同溫層中大多對花四個月去當兵是很不以為然的，當過的人無一不認為是在浪費時間，每日不是在拔草就是在打掃，外加看一群白痴長官耍猴戲，有碩士學歷的也會認為去當研發替代役或甚至是六個月的一般替代役也會比沒有自由的四個月來的好，沒當過的人或許還可以說的出四個月一下子就過了這種話，實際進來就會後悔時間怎麼可以過的這麼慢，即便是現在只剩下最後一個月，我還是覺得進來大多是在浪費時間，每月只領6000元，跟外面的薪水比實在有夠悲情。

意外的是家人對於當兵這件事倒是異常的興奮，在他們傳統的觀念裡當兵才是真正的成年禮，對於整天想著以後要出國的年輕人，這或許是培養愛國愛民的心最後的機會，再加上研究所期間日益浮腫的身材，進去鍛鍊鍛鍊對健康應該很友善。當後來兵單下來知道我要去成功嶺新訓時父親更興奮，他當年在成功嶺當了近兩年的義務役士官，成功嶺是個他投入青春、充滿回憶的地方，可惜沒有懇親，不然是個讓他回來回味的好機會。

從知道自己可能有機會去當兵，到確定自己被安排到哪個梯次，再到拿到兵單，這一切在一個月內發生，沒什麼時間思考，也沒時間心態轉換，在跟教授討論後就開始跑畢業流程，中間還卡了個五天的澎湖之旅，以至於在民宿的晚上還在喬口委的時間，澎湖回來花了一週完成口試以及離校手續，並在9/19拿到了畢業證書，接著三天後，9/21就搭上了通往成功嶺的入伍專車，開始了四個月(16週)的軍旅生活。

準備

由於忙畢業已經是夠焦頭爛額了，我是等到拿到畢業證書後才開始思考當兵的事，比起有些同梯可能已經等兵單等了半年，我的準備時間相對非常的少，準備的部分我大致分為物品以及心態，兩者同樣重要。

必帶物品

網路上有人說你其實只要帶個錢包就可以入伍了，因為會用到的裡面都可以買得到或拿得到，此言不假，但如果想過的舒服一點還是多準備點東西好。

盥洗

牙刷 - 建議多帶幾隻，我第一週帶到太舊的用了兩天就斷了，只能跟同梯求救。
牙膏 - 帶大條一點，總比沒得用好
三用沐浴乳 - 愛迪達的不錯用，方便就好別太講究
電動刮鬍刀 - 進去前有人說電動的不能帶，成功嶺好像可以帶，比起手動的方便多了
毛巾 - 不需要帶，床邊的欄杆只能掛公發的

衣物

內褲 - 建議多帶一些，雖然有公發的但可能穿的不習慣，有時候當天可能不能洗。
內衣 - 不用帶，只能穿公發的迷彩內衣
保暖衣物 - 天氣很冷的時候可以穿發熱衣或是外套在迷彩外套裡面
便服 - 放假出去的時候只能穿便服出去
洗衣袋 - 不用帶，裡面會發

藥物

維他命 - 可以帶一些維他命B或是C，比較操的時候可以吃點，恢復比較快
鎮痛解熱錠 - 在裡面很常感冒頭痛，可以吃一點緩解症狀
OK繃 - 受傷或起水泡可以用
撒隆巴斯噴霧 - 肌肉酸痛時可以用
薄荷油 - 頭痛可以用

雜物

濕紙巾 - 帶涼感的濕紙巾天氣熱的時候根本神器，午休前擦一次很好睡
書籍 - 裡面有大多數時間都在等待，拿書出來看通常不會怎麼樣
行動電源 - 雖然使用手機的時間很少，但有行動電源可以避免手機沒電
爽身粉 - 天氣熱可以用
小電扇 - 蚊帳禮通常很熱，而且大多時候冷氣吹不進來
手電筒 - 早上通常都會要提早起來整內務，但又不能開燈，只能靠手電筒
耳塞 - 打靶一定要帶，而且很容易不見，沒戴耳塞打靶會讓你耳鳴一個禮拜，我親身體驗過
筆 - 原子筆跟奇異筆都要，最好多一點因為很常不見，寫大兵或是填資料都會用到

食物

飲料 - 剛進去前幾天通常不給投飲料
零食 - 同樣的道理，想家的時候就吃點
口香糖 - 無聊可以吃，但不要太高調

文件

兵單正本 - 沒帶會很麻煩
畢業證書影本 - 帶最高學歷的就好，因為會用學歷區分抽籤批次
役期折抵證明 - 這個要去學校教官室申請，最好進去前就辦好
戶口名簿影本 - 後來沒用到
私章 - 花點錢去刻一個，進去後會收

錢

雜費 - 第一週會收很多錢，像是洗衣費、剪髮費、公發品費用等等
零錢 - 投飲料機跟講電話會用到
電話卡 - 不要以為有很多機會用手機，新訓階段你只能靠電話卡跟外界聯繫，打手機又很貴，建議準備多點。

心態調整

這很困難

首先當然是要先說服自己為何要來服這四個月的兵，再來就是了解軍中每個階段在做什麼，可以緩解對於無知的恐懼，入伍前我一直在看阿哲當兵的影片，裡面講的很清楚新訓每一週在幹嘛，了解越多能夠說服自己已經度過最痛苦的環節了。
再來可以多跟當完的朋友聊聊，了解如何排解苦悶、如何跟同梯還有長官相處，我覺得我進去時心態也還沒有完全調整過來，也花了很多時間在適應裡面的節奏。
另外就是千萬不要把外面的事帶到裡面去完成，像是準備考試、申請學校或是完成研究之類的事，你會發現在裡面你什麼事都沒辦法做，那種無力感是很可怕的。

生活

我可以很肯定的說，新訓絕對是四個月中最最最痛苦的一段時間，特別是剛進去的前十天，熬過之後會如倒吃甘蔗越當越順。

關於成功嶺與一〇一旅

我的單位

我所屬的梯次是陸軍158T軍事訓練役，被分配到的單位是一〇一旅步四營火力連，據說會叫火力連是因為我們是這個營裡面的第四個步兵連，為了避諱四這個字，所以改叫做火力連，在過去都叫做兵器連，不知什麼原因改成叫火力連。

連上的軍事訓練役大概有150個人，連級有連長、輔導長、連士官督導長，負責管我們的則有數個上士以下士官輪流背值星，可以觀察到的是連上經常處於人手不足的情況，常常150個兵只有兩三個士官在管，可以說是心有餘而力不足，常為他們感到辛苦。

關於成功嶺

成功嶺是老牌的新訓中心，整個營區都在負責接訓新兵，很少很少有實戰部隊，可以感覺的到成功嶺的裝備比較老舊，比較偏向訓練用途。

傳統上成功嶺有三〇二與一〇四兩個旅，後來在一〇一旅被復編後借用了原本一〇四旅的營舍駐紮，成功嶺的營區非常的大，沒什麼特殊原因的話移動都是靠雙腳，打靶的時候經常從一〇四走到三〇二，大概需要走三十分鐘，還要全裝備著重重的T65k2步槍，非常的累。

營舍的一樓通常有販賣機，這是我們唯一可以自由購買東西的地方，營區內也有數個營站跟便利商店，這些通常是看的到買不到，只有在出公差的時候可以凹長官帶我們去，所以出完公差的人口袋都會鼓鼓的。

成功嶺還有個替代役代訓班，去打靶的路上通常會經過，不過建議不要觀察他們的生活，心情會不好，他們的生活是彩色的，而我們是迷彩的…。

成功嶺的交通相較其他營區算是非常非常方便，大門出來走十分鐘能到成功火車站，花個五十元搭計程車，十分鐘內就能到高鐵站，此外成功嶺一次放假通常數千人一起出門，人很多而且門口就是個平交道，防止塞住出大門時通常會用跑的，非常壯觀。

入伍

入伍當天在台北車站大廳集合，集合完區公所的人會統一將大家送上通往成功嶺的專車，那個過程永生難忘，數百名愁眉苦臉的男生聚集在大廳，一看就知道他們接下來要遭遇什麼苦難。

入伍專車是列開的很慢的莒光號，慢到中途還有時間吃個很難吃的便當，請記得這個便當，因為這會是這十天為一能吃到的外面世界的熱食，約三個小時火車就會抵達新烏日站，轉達巴士直接開進成功嶺營區，然後就會集合分配到所屬的連隊。

緊接著會分配座號，大家都會流傳盡量往後站不要站排頭，因為會當班頭，我就這樣很剛好成了005號，第一天的行程會非常緊湊，先是安檢(搜身)、安排編制、領用裝備、安排床位、簡單教大家如何整內務，從這個時間開始我們就要跟我們的手機說掰掰，開始原始人的生活。

入伍專車

行程

部隊的生活非常的規律，如果沒有特別的事情每天的行程都差不多，也因此蠻容易就能掌握接下來會發生的事情，在新訓的期間我們過的是夏令時間，每天的行程差不多如下：

05:30 起床 - 雖然說錶訂是這個時間起床，但通常要更早起床摺棉被、蚊帳以及盥洗，這些工作其實挺花時間的
05：50 集合 - 沒特別的事就穿運動服下樓到連集合場集合(就是營舍門口的那塊地)，建議提早個十分鐘下去，因為05：50是集合完畢的時間，不過每次還是有人遲到
06:00 ~ 06:30 吃早餐 - 因為人很多餐廳會坐不下，因此我們會分兩次梯餐廳，一梯去吃飯時另一梯就會進行環境打掃，早餐通常都是吃一個包子配上一些菜和一個茶，偶爾會有漢堡之類的東西
07:00 集合 - 這次集合就要全副武裝(鋼盔、S腰帶)
07:10 ~ 10:30 操課 - 就會依據當天的課表上課，學的東西大多就是鑑測會考的東西
11:00 集合 - 是的，你會發現什麼事都沒做就又要去吃飯了
11:00 ~ 12:00 午餐 - 午餐吃四菜一湯還有水果，水準就跟國小的營養午餐差不多
12:30 ~ 13:50 午休 - 因為沒什麼事情做只能睡覺或是看書，我通常會在午休前去打個公共電話給女友
14:00 集合 - 一樣也是全副武裝
14:10 ~ 16:30 操課 - 繼續做跟早上差不多的事
17:00 集合 - 又到了吃飯時間
17:00 ~ 18:00 晚餐 - 吃的跟午餐是一樣的東西，菜經常會不夠吃
18:00 ~ 19:00 盥洗 - 這個時候大家會去搶浴室洗澡，150個人搶20間浴室很容易塞車，另外還會在床上架蚊帳，讓晚上就寢時間快一點
19:00 集合 - 這個時間點大多數人都洗好澡了，就穿運動服集合，有時候是在中山室有時候在連集合場
19:00 ~ 21:00 夜間課程 - 大多時候在做一些很冗的事，像是收一些錢、資料或是發裝備，其他時間都在發呆，偶爾會放手機，但機率很低

值星

當周的值星會很大程度的決定你那週過的舒不舒服，值星輪值的順序會公布在課表上，可以了解接下來是誰背值星，有個心理準備，值星通常是每個星期四下午會交接，每次會有一個連值星官負責帶操課進度，會有一個值星班長負責點名以及管理部隊秩序，值星感覺是個很累的活，一兩個人要管150個班兵常常是無法面面俱到，上值星的幹部無一不是想趕快脫離。

好的值星官標準明確，在適當的情況嚴厲，不會隨意玩兵，爛的值星管則標準不一，做事效率差，亂拖大家的休息時間，輪到不好或沒經驗的值星那週就會烏煙瘴氣、怨聲載道。

福利

那些平常很理所當然的事在裡面都會是種福利。

休息時間 - 不要懷疑，他們把給班兵休息當成是種福利，你要越乖才會給你越多的休息時間，請記得班長口中的至理名言：「你配合我，我配合你，你們的休息時間只會越來越多。」
飲料機 - 雖然說每棟樓樓下都有飲料機，但不代表我們有投飲料機的權利，長官會視秩序開放投飲料機，我們是到第三天才開始有投飲料機的權利，而且也不是所有飲料機可以投，只能投自己連上所屬的飲料機。
抽菸 - 我不抽煙，不過還是分享一下，抽煙也是一種福利，我們連上第二天就有讓人抽煙，大家是怕有些人沒菸抽會開始皮。放煙的時間通常是午餐晚餐用餐後，集合到一個地方集體抽煙，由於打火機是違禁品，只能跟班長拿，十幾個人互相借火的畫面非常有趣。
手機 - 放手機時間太少應該是大家最不滿的地方，我們一週應該只使用到手機一到兩次，每次大概用十到二十分鐘，平常手機不能用時都所在手機櫃裡，看的到卻摸不到，這個時代上癮手機的人應該比煙癮的人還多，應該比照放煙的機會放手機才合理。手機需要灌國軍MDM才能夠在營區使用，前幾天的時候會幫大家灌好，MDM軟體會將相機還有GPS鎖住，放假出營區後才可以解鎖，建議盡量不要帶非ios的手機進去，MDM會比較難灌，有時候會影響到你寶貴的手機使用時間。
營站 - 成功嶺有三四個營站，除了進去的第一天會集體帶去買些生活用品外之後應該不會再有機會去，除非是出公差，成功嶺近期在整修，因此有很多搬東西跟打掃的工作需要人力，大多數時候工作完成到一半長官會我們帶去營站買點東西，算是個不成文的福利。

懲罰

有福利就有懲罰，而懲罰可以是集體的也可以是個人的，集體的懲罰就是俗稱的連坐法，群體中有幾人秩序不佳，就會依序剝奪上述的集體處罰，讓那幾人被大家討厭，對於偶發的特別脫序的行為則會有個人處罰，然而自從洪仲丘事件後，軍隊中明定禁止體罰，凡事用跑步、伏地挺身等等當作懲罰的都是很嚴重的行為，應該沒有長官敢冒這個險，因此都採取比較靜態的懲罰，以下就列一下他們能採取的懲罰方式：

自白書 - 這個是所有懲罰的第一步，是一張空白的表格要你填寫你做了什麼壞事，寫完之後長官會視情況做進一步的懲處，有時候可能只是衣服沒穿、集合遲到之類的鳥事，要掰個一千字也是夠痛苦了。也因此常聽到班長會說：「誰再XXX就一人送一張自白書，說到做到喔」
洞八 - 如果做了什麼比較嚴重的錯像是收假遲到，大多懲處都是從放假時間下手，我們新訓的時候大多都是週五18:00前就可以離營，被罰洞八就是隔天08:00才可以離營，想到要一個人孤零零的睡在諾大的寢室就覺得可憐。
罰勤 - 如果你那週是洞八放假，但你又做了蠢事，那有可能會被罰勤，罰勤一次兩小時，所以你可能會變成10:00才能休假，當兵在外自由的每分鐘都很重要，千萬不要拿自己的假開玩笑

如果說已經到了犯法的程度，據說是直接強制留營到退伍，還要接受軍法審判，所以千萬別做壞事啊。

活動空間

在新訓階段，新兵是完全沒有自由的，我們的所有自由活動空間僅限於連隊所屬的那層樓，包括走廊廁所跟寢室，而且也只有在休息時間時才可以活動，想要下樓或是移動到營區的其他地方都要有長官帶，否則被點到會出大事。

此外連之間、營之間都有非常明確的界線，像是不可去使用其他連隊的廁所，不可以走其他連的樓梯，不可以穿其他營的中廊、走其他營的集合場等等。

內務

新訓階段什麼東西都要規定，什麼東西該擺哪裡怎麼擺、棉被該怎麼摺、什麼東西能擺不能擺等等，鞋盤鞋子的順序不能錯，臉盆裡面只能擺牙刷牙膏，牙刷一定要插在髒到不知道多少人用過的鋼杯裡，朝的方向一定要同一邊，毛巾只能掛公發的標籤還要朝內，內務櫃裡衣服只能掛外套跟迷彩服，袖子還要綁起來，櫃子頂只能擺鋼盔跟S腰帶，蚊帳跟棉被有固定的折法，邊邊角角要拉到正正方方像豆腐，唯一可以亂的只有黃埔包內，以上沒做好都算內務不整，太亂的話抱歉08。

招募

義務役是國軍的重點招募對象，在新訓一開始的時候就會有其他單位的人來營上說服大家簽自願役，他們會來介紹他們單位的地點工作還有福利，通常會放上每天吃的好料已經新蓋好的營舍來吸引大家，也會宣傳國軍薪水的穩定以及退休俸的好處，此外也會說現在國軍都有外膳宿，跟外面上班其實差不多，然而實際上是不是這麼好就留給真的簽下去的人去體會了，只知道實際上能忍辱負重撐滿二十年的人少之又少。

整個招募環節運氣好會持續兩三天，這幾天都不用操課，如果你聽完後表現出想簽的意願，招募員會另外拉你出來面談，有時候還會給你用手機、上營站等好處，此外如果你幾乎確定要簽，第一次放假可以放12假也就是週五中午就可以離營，說是讓你會去說服父母讓你簽，所以也有不少人在這段期間假裝自己想簽，盡可能凹些福利。

招募期結束後會看見簽下去的同梯可以享有各種福利像是休息時間使用手機、打球時間，有時也可以不用跟操課，只能說國軍為了吸引大家加入無所不用其極，不過也不用太羨慕他們，他們也就爽這幾天而已，二階段下部隊之後就是另一個世界了。

放假

放假是義務役唯一能回歸外面社會的機會，不像志願役偶爾還可以外膳宿一下，義務役的放假原則上就是見紅就休，所以連假就照放，補班就照補，新訓的話前十天不放假，之後會補兩天假回來，所以前十天是最痛苦的，沒有自由沒有手機資訊完全與外界脫離，我們這梯比較幸運的是剛好遇到雙十連假，再加上沒放到的兩天假，我們前三次假都是連放三天，又考慮到這梯都是台北兵，路途遙遠，前三次放假也都讓我們放18假，因此有幾週只操到四天的課，相較其他梯來說已經過的不錯了，只有最後一週的時候放08假，結果就造成同梯的公憤，不過軍事訓練役的放假時間本來就是週六08，所以也沒什麼好爭的。

成功嶺的放假進出都是走大門，也就是有邁向成功之路的牌子那段，放假會集體帶隊從營舍走到大門，會先分成搭計程車、成功火車站、家長接送三個區塊分別帶隊，如果要去高鐵站就是走計程車這路，然後搭計程車去高鐵站一人50元，短短五分鐘的路程一車塞滿可以載七個人，其實還蠻賺的，高鐵的話來回台北是700，所以每月6000元其實連車費都不太夠。

收假的話則是從另一個比較近的門進入，建議提早搭車到台中高鐵站，有時候人比較多會沒有計程車，而且計程車不能直接開到門口，只能到門口附近下車，剩下的一段路要走進去約20分鐘，所以凡事盡量提早，收假遲到是非常嚴重的，另外休假走進營區的路上也別搞事，會有長官巡邏，被點到也是自白書一張。

操課

由於新訓的時間很短，操課的項目都著重在鑑測的項目上，操課的基本著裝都是鋼盔+S腰帶，大多數操課都不算累，大概就是國中體育課的水準，而且經過一些事件後長官也不太敢亂操兵，你要提出來(頭暈、腳痛等等)基本上都會讓你休息，上廁所也是一樣只要說都會讓你去，他們也怕你投訴他，天候的影響會比長官還可怕，在成功嶺沒遇到下雨，算是很幸運，有聽說有其他單位雨中操單戰，把全身弄得都是泥巴，夏天的太陽是很恐怖的，只能靠喝水消消暑。我經歷到的操課大概有以下這些：

開訓

剛進去的第五天會有一個開訓典禮，就是把所有成功嶺的新兵帶到集合場曬太陽，會有旅長之類的高官來看，期間會要唸一些軍人的宣示詞，為了要順利進行開訓，還會花一整個早上練習整隊跟立正，九月的時候太陽還很大，應該有不少人曬到中暑。

刺槍

刺槍可以說是鑑測最重要的項目，但相較打靶、單戰其實蠻沒用的，同樣一套東西三四十年來沒有改過，這個時代上戰場也應該很難靠刺槍術刺死敵人，用一個團隊表演來理解可能會比較能接受，可以展現團隊的默契跟士氣，可以參考新兵日記刺槍片段。

刺槍整段表演大概五分鐘左右，大概會花三到四個上午來練習，會看到一群人拿著T65k2步槍在計畫場上轉來轉去喊著「殺！」，練刺槍最可怕的在於將槍刺出去的時候手伸直要將槍提住，在練習連續動作時班長有時候會故意不喊下一個動作，步槍非常重，大概四公斤左右，要維持槍刺出去的狀態十分考驗手臂的肌耐力，練完後可以手酸好幾天，此外團隊的默契也需要花時間培養，像是散開與集合，還有刺槍的流程也要熟悉，看其他連刺的時候還是可以看到有人刺錯邊、慢半拍或是跑位時跑錯地方。

手榴彈

手榴彈投擲可以分成兩個部分：基本投擲跟野戰投擲，基本投擲比較簡單，只要把一個大概500公克的練習彈丟進一個扇形區域再臥倒就可以了，實際丟其實蠻有難度的，小小的練習彈比想像中還要沉，平常若沒有再丟東西，很難正確的施力就會丟不遠，也因此有人可以很輕鬆丟很遠有人很用力還丟不進25公尺，操課的時候會先將屆腳步跟投擲的方法，但沒人聽得懂，其實只要可以丟出去，動作亂投也行，但千萬要記得臥倒，沒臥倒的話一定會被班長噴爆，手榴彈課算是很輕鬆，場地只有一個，一個連150個人一人上去丟個一兩次三小時就過去了，其他時間都坐在板凳上看別人丟。

比較有趣的是有時候會去跟別連比賽丟手榴彈，會從連上挑幾個比較強的代表出賽，輸了就全連做個伏地挺身30下，有一次贏了班長還有請上去投彈的人喝飲料，算是無聊中比較有趣的部分。

野戰則是要把手榴彈投進一個正方形的窗戶中，模擬實戰中攻擊敵方躲藏地的情況，野戰投擲沒有練習過非常難投進，畢竟也才摸過練習手榴彈一兩次，要精準的控制投擲的方向與力道非常困難，印象中全連只有五六個人有真的投進去。

打靶

打靶是要用國軍的T65K2步槍射擊人形靶，可以分成25公尺歸零射擊跟175公尺設計，距離越遠射擊難度越高，新訓的打靶都是採臥射，但聽說在實戰上其實用不太到。

由於加上子彈的槍枝非常的危險，靶場上嚴格要求紀律，不能夠隨意嘻笑打鬧睡覺，也要十分熟悉射擊流程，因此打靶前會做好幾次射擊預習，也就是模擬打靶的流程，包括如何正確臥射、如何開保險、如何瞄準、如何壓槍、如何裝子彈、如何清驗槍，還有靶場上的口令像是什麼左線預備右線預備。

確定大家都會之後就會帶上靶場正式射擊，打靶的時候營長連長都會到，通常是連長擔任射擊指揮官，會下射擊口令，靶場上通常會有數個靶位，一個靶位對應一個人形靶，靶位旁邊都會有靶助協助射擊，幫忙接彈殼遞彈夾以及防止你做出出格的蠢事，上去打靶前會排波次靶位，打靶時一波一波的上靶台進行打靶，每次大概會打一到三個彈夾，每次大概六個子彈，打靶前會以為槍枝後座力很大，實際上其實還好，聲音倒是非常大聲，比你聽過的所有鞭炮都還大聲，因此打靶一定要戴耳塞，我有一次打靶忘記戴耳塞，打了第一發就直接耳鳴，耳鳴的感覺一個禮拜才消除。

打靶本身其實不會累，到了靶場大多數時間都在等別人打完，又因為靶場紀律比較嚴，不能聊天也不能做其他事，非常無聊，打靶比較累的是前置作業，事前要先從庫房取槍，然後驗槍，靶場又在成功嶺三〇二才有，從營舍扛著重重的步槍走個三十分鐘，走到都累了，打完再帶隊走回來，再一次驗槍清槍，然後晚上在送槍，有時候還要排槍哨顧槍，為了打個靶常常浪費一整天的時間。

單戰

單戰就是模擬真的上場打仗，算是比較有用的課，新訓都是受步槍兵的訓練，而步槍兵的角色就是在地面上殲滅敵方火力，而單戰就是教大家戰鬥時如何交互火力掩護，朝敵方攻擊前進。

單戰場看起來就是一個樹林，然後會佈置好幾個站，每個站都會有幾個況，像是有鐵絲網、有壕溝要怎麼互相掩護通過，當我方有人受傷的時候要怎麼營救他以及後送他，以及兩軍交鋒的時候要怎麼衝鋒前進，其中會有非常多的報告詞要背，印象中也背了好幾天，結果實際鑑測時跟大家背的又不太一樣，一團亂的跑完所有單戰。

實際做起來會有蠻多需要趴在地上或是匍匐前進的部分，因此要有心理準備會全身弄滿泥巴還有怪蟲會爬到身上。鑑測的時候還會架機槍塔打空包彈跟用TNT模擬迫擊砲，場面非常震撼，能稍微感受到戰場的情況。

鑑測

新訓的最好一週是鑑測週，大概有三天會進行鑑測，鑑測的意義是要測試部隊是否有戰鬥的能力，測驗包含體體能跟戰技，體能就是伏地挺身、仰臥起坐跟3000公尺，戰技就是刺槍術、手榴彈、單戰跟打靶，鑑測在做的事情也就只是把操課做的事在做一次，只是旁邊會有測驗中心的教官來監督，鑑測時長官會嚴格一些，實際上還是在走個過場，畢竟五週的時間實在很難講每一項都練的非常熟練，長官也明白這點，因此也並不會太在意成績，只在乎是否有盡力參與以及秩序是否良好而已。

至於鑑測有過沒過會有什麼差，有一說是有過會比較容易被教召，但也有人說沒過比較容易教召，反正就是個都市傳說，唯一確定的就是鑑測紀錄會留到下部隊、教召直到除役，以後被人家發現鑑測沒過應該會有點丟臉，所以還是盡力拼過比較好啦。至於體內上真的不行或是真的不想曬太陽還有免技測這招，可以找一個身上的痼疾(扁平足、舊傷、高血壓等等)可以去找國軍醫院(注意不是三軍總醫院也不是榮總)開免技測證明，還沒聽過有人失敗的，有了免技測證明這三天就只要看別人技測就行，更絕的也可以鑑測第一天就說自己身體不舒服，長官不會強迫你一定要完成測驗，反正軍人就是講求個榮譽嘛。

公差

我們新訓的那陣子有其他部隊正準備整修營舍，需要有大量人幫忙搬家，剛好義務役就是最廉價的勞工，因此我們有許多機會可以出公差。新訓階段的公差一定要去，因為不去就是要操課，操課的無聊程度還不如搬東西有趣，此外出公差有時候有福利，像是飲料機、放煙、營站等等，也可以藉這個機會到營區的其他地方看看。

抽籤

不知從哪梯開始二階段訓需要去其他單位，就有了抽籤這個環節，抽籤大家最害怕的就是抽到金馬獎，而現在的抽籤制度是會先讓真的想去離島的人優先自願，剩下的名額再讓大家抽籤，很意外的是自願離島報名還蠻踴躍的，大概是覺得去也不過就兩個多月，當作去離島打工換宿應該也不錯，除了離島，可能是考慮這梯都是台北兵，其他的籤幾乎都是北部籤，少數比較遠的則像是花蓮，抽籤的環節就是大家一人上去籤筒抽一個號碼牌，會有人告訴你抽到什麼籤，比較有趣的是抽完後大家互相詢問抽到了什麼以及找下一個單位的同伴，也多少會有點感傷，抽籤就決定了新訓共患難的同伴二階段訓也要分開了。二階段訓相較新訓就會輕鬆很多，所以其實大多數的籤結果其實差不多，頂多住宿環境好一點或是離家近一點，我後來抽到了新竹湖口的裝甲五八四旅，已經算是離台北比較遠的籤了，之後有機會再來寫關於二階段訓的心得。

心得

毫不諱言的說新訓就是這四個月最最最辛苦的一段時光，還記得入伍前女友突然確診無法送我去當兵，讓我接下來的每一天都非每一天唯一的精神支柱就是打公共電話給他的時光，每天除了精實的操課讓人肌肉酸痛，再來就是剛從自由的世界瞬間被剝奪自由，被別人像是小學生一樣管理，真的會讓人懷疑人生，懷疑自己為何要浪費四個月給人管，後悔為何選擇替代役。此外就是被剝奪手機，與外界資訊完全脫節，這一個月裡外面到底發生了什麼改變了什麼什麼都無法知道，缺乏資訊十分令人恐懼，無法時時刻刻與女友、家人、朋友聯絡也讓人焦慮，又剛好鄰近選舉，那位候選人做了什麼說了什麼我們也無法知道，或許就是因為被剝奪自由，讓人更珍惜自由的可貴，珍惜假日的時光，也警惕自己別做壞事。

儘管長官管理的標準不一、做事效率極差，飯菜難吃而且常常吃不夠，這仍然是一段難忘的時光，在艱苦的時候越會記得任何有趣的人事物，沒有進來當兵或許永遠不會認識社會上其他背景的人，很難不帶刻板印象的去與他們交流，而當兵打破了隔閡，讓我對這個社會有了更廣闊的認識，如今再回想起來，一個月的新訓是荒謬卻又有趣，無聊卻又耐人尋味。

入伍後一週的我

以下就紀錄一些新訓中難忘的人事物：

難忘的事

洞六洞洞

冬令時間是6:00起床，每天起床時值星班長都會廣播：「現在時間洞六洞洞，火力連起床。」，這大概是所有新兵最不想要聽到聲音，這代表要離開夢鄉，起床盥洗折蚊帳棉被，迎接又一個無聊的一天，據說退伍後還是有人潛意識中存在著對起床號的恐懼，聽到這個聲音還是不由得緊張起來。

會恐懼這個聲音不是沒有原因，新訓階段不少人都睡的不太好，即便09:30就會強迫大家躺在床上，還是有各種原因可以讓人睡不著，像是天氣熱時蚊帳一掛，冷氣還是電風扇根本吹不進來，會讓人熱到睡不著，還有同梯的打呼聲也經常讓人煩躁，結果實際的睡眠時間只剩下差不多五六小時吧。

板凳

軍事訓練役隨身的裝備除了鋼盔、S腰帶、水壺之外，還有一個必須要隨身攜帶的就是板凳，我們連上提供的是一個塑膠的方形板凳，行進時可以剛好卡緊身體的腰部用左手提著，無論是操課、聽講座招募還是上餐廳吃飯板凳都是必備物品，否則你就只能做地上了，也因此我們會自嘲板凳才是我們真正的建制武器，不愧是七大武器之首啊。

板凳會讓人如此印象深刻，除了陪伴著我們一個月外，還有跟板凳相關的口令，像是坐板凳時不可以直接坐下，要等班長下「至板凳」的口令，將板凳放置在腳跟後手碰著板凳看向班長，聽到「好」才可以起來，這時候肯定有天兵還沒聽到好就起來，就會被班長罵然後回上一動，這樣子置板凳的遊戲有時候可以玩個十幾分鐘。

確診

在正常的世界中一不小心確診covid-19可能會非常的煩惱，因為要被隔離好幾天(那個時候還是隔離七天)不能出門，然而在軍中確診跟本如同中樂透一般，這時候軍中的政策還是一旦確診就是回家隔離七天直到快篩陽性才能回來，此外同床位的密切接觸者一樣也可以隔離七天，可以放個七天的假誰會想要待在無聊的部隊中呢，因此每次集體快篩時無不祈禱自己還是同床位的人的快篩盤上可以出現兩條線，而中的人真的會像中樂透那樣歡呼，一定會被班長罵，但都要出去爽七天了，誰在乎呢。

不得不說軍中真的是大毒窟，一百多人擠在小小的寢室，病毒要不擴散也困難，所以第一週就出現了大量的確診，加上同床密切接觸的大概有60幾人被隔離，我所在的建制班原本有17人，第一週後就只剩下我在內的五人，原本以為是005號的我應該是跟班頭沒什麼關係，結果001-004號都被隔離，我就被迫當了一個多禮拜的班頭，雖然班頭也沒有要幹嘛啦，由於密切接觸會被隔離，連上有人原先是密切接觸隔離七天隔離完發現確診又再隔離七天，七天後還是沒有轉陰性再繼續隔離，結果五週的新訓實際待不到一週，爽的令人羨慕。

飯不夠吃

軍中的伙食大概就是國中營養午餐等級，不會到難以下嚥但也沒有好吃到讓人懷念，比起菜好不好吃大家更在乎的是菜夠不夠吃，全連有150個人就分那少少的五桶菜可謂僧多粥少，需要有人嚴格控管每個人的打菜量，也因此還需要有個特殊的加菜環節讓那些食量比較大的人加點菜吃飽一點，然而也經常有天兵在班長還沒喊加菜的時候偷加菜，後來當然是被罵了一頓。

到了新訓後幾週，菜不夠吃的情況越來越嚴重，不是我們的食量越來越大，而是伙房分給我們的菜越來越少，到後來還不到一半的人盛菜就沒了，也因此有人因此打了1985，1985是國軍的申述電話，就是為了避免洪仲丘事件後長官有不當管教的情況，一旦接到1985的申述，上級的長官就一定要處理這件事，也因此有時會拿來當成報復長官的手段之一，因為菜不夠打1985也有這個意思，也因此事發當天長官也同意帶我們去營站補充的營養，後來這件事鬧到旅部去，連旅政戰主任都來關切這件事，他大概覺得很莫名奇妙連這種事都要打1985，還是說「這是走正常管道反應情況」，但還是希望我們可以先反應給連上長官，他們大概也覺得這種事很煩吧。

放假收假

當兵最難忘的大概就是收假放假的時光吧，放假時慶幸著自己即將獲得短暫的自由時光，而收假時則感嘆為何假期過的如此快，而與同梯一起收放假也讓這件事情變得更有趣，由於從高鐵站到營區要搭計程車，同梯間經常會相約一起到高鐵站集合，一起吃個摩斯漢堡或是麥當勞，享受最後的自由時光，再搭上計程車，走進最不想回去的成功嶺營區，一路上大家一起聊著假期間玩了什麼吃了什麼，然後猜著接下來的一週到底是愉快還是痛苦，在外界大家或多或少都有一番事業，回到營區就只剩一個號碼，這轉變的路上有人陪伴也就沒那麼痛苦了。

掉筷子

新訓階段上下餐廳都要集體帶隊，在行進的過程中只要有人掉筷子，聲音會非常的響亮，這時大家都知道有人筷子掉了，有趣的是從新訓的第一天到最後一天永遠都有人沒辦法沒辦法好好的拿好筷子，看來成功嶺應該要想個辦法讓大家的筷子不掉才行。

班長情緒勒索

班長也是人，有些班長情緒不太好又有玻璃心，新訓的時間非常的短，又要教完許多鑑測項目，對班長而言已經夠崩潰了，其中單戰又是最難的課目，教的時間只有兩個上午，內容又非常的多，而班長教的很累新兵又愛聽不聽，教到第二天時班長大概教的很不開心，就直接說他不想教就跑去抽煙了，後來被值星臭罵了一頓再加上趴在地上趴了三十分鐘，班長才願意繼續回來教完，想當然爾學習的效果很差，鑑測大家都在亂跑。

便秘

軍中的環境很神奇，一旦進來後過好幾天都不會想上大號，大概是因為軍中的生活太緊湊，隨時都要提心吊膽會不會一不小心就錯過集合時間，在有時間壓力下腸胃大概也不太敢造次，另外就是沒有手機陪伴腸胃不太想工作，至少在新訓的這幾個禮拜在營區上大號的次數用手指數的出來，還是在家裡上廁所比較舒服。

難忘的人

由於我們這班太多人被隔離，剩下來的五人有種惺惺相惜的感覺，也因此最先跟這群人熟起來，大概是因為這一梯都是台北兵，大部分的兵家境都非常不錯，學歷也非常好，有八家酒但數量相較其他梯應該少非常多了，以下就紀錄些難忘的同梯：

內務天兵

沒個部隊一定都有天兵存在，而我們的連隊一樣也不例外，最讓人印象深刻的就是某位天兵內務不整到讓長官發飆的事件，每個人的生活習慣都不同，有人喜歡環節整齊，有人習慣混亂的環境，若又剛好不擅長整理，那在軍中真的會很痛苦，那位天兵是打飯班的成員，平常休息時間就相較一般人來的少，因此就沒什麼在整理內務，鋼盔亂擺、黃埔包整袋露在床外、棉被不折內裡還跑出來，亂到同床的看不下去，臨兵也救不了他，想當然被班長罵了一頓，外加自白書一張，後來有稍微改善，但相較其他人還是不及格。

八家酒

軍隊中有形形色色的人，也包括一些只有國中畢業的、身上刺著龍鳳的或者背好幾條前科的人，也因為這些人才發現志願役的標準其實蠻嚴格的，有上述情況的人志願役是不收的，平常這些人會自己聚在一起抽煙，算是物以類聚，一般人少有機會接觸他們。

一次公差意外的在旁邊聽到他們聊天，互相討論著為何會被抓要常常跑法院，一位說他酒駕被抓，另一位說他聚眾鬥毆重傷害，還有一位販毒被抓，被抓是因為吸毒者被警察控制要吊毒販出來，之前就有發現他怪怪的還是強迫要去買，他說不賣的話人家就拿槍指著你。聽他們講才可以感受得到這個社會或許不像我們看到的那麼光鮮亮麗，仍存在許多陰暗的角落，家境不好或是認識不對的人容易讓人走上歪路，這些事若不進來當兵，大概一輩子也不會親身聽到。

超高學歷的同梯

我以為台大電資碩士已經算是很不錯的學歷了，但這梯的學歷實在出乎我預料，我們這班有17人，裡面就包含兩個台大醫學系與一個北醫醫學系、兩個台大畢業，其他也只有兩個人沒有大學學歷，如果升是隨機抽樣的話那真的是蠻大的偏差，再次說明台北兵家裡家境都不錯，也都重視教育。

不會寫中文的同梯

除了學歷很高的同梯外，也有不少人有留學經驗，我們這班裡就有五人有留學經驗，有人高中去德國交換，有人去唸洛桑管理學院，也有人出國做研究跟唸牙醫系，比較特別的是有一位是從小在上海讀國際學校(聽說還因此被身家調查)後大學到美國唸的ABC，雖然會講中文但完全不會讀寫中文，因此我們會需要經常幫他翻譯翻譯，除此以外也經常聽他講美國的種種以及討論未來想去美國工作的憧憬，讓我在這段期間也得知了不少資訊。

結語

一個月多的新訓，在裡面時度日如年，現在看起來其實牙一咬就過去了，以後或許還會懷念與同床徹夜暢談的時光，一同揮汗刺槍、靠北長官的日子，或許是因為都在浪費時間做相同的事，如果要我再去一次我當然不願意。剛進去時還會給自己立下許多目標，像是體能變好、體重變輕等等，過了幾天就會轉念過的爽比較重要，我們離開後的下一梯，同一單位就有軍事訓練役出了狀況，如今我覺得能夠平平安安退伍才是萬幸….。

再見成功嶺～

2022 Google Taiwan SWE 面試心路歷程

Mon, 05 Dec 2022 09:00:18 +0800

一個普通人的Google面試經驗

前言

大學時期正處AI技術火熱發展的幾年，也因此經常有媒體報導AI技術領頭的Google的工作環境，像遊樂場一般的辦公室、吃不完的零食和飲料、五星級的免費三餐、領著百萬年薪上班還可以想睡覺就睡覺，其內部夢幻的刷新我對一份工作的三觀，從那時起對這間公司逐漸產生好奇，儘管好奇，我卻一直抱持著觀望的心態，如此夢幻的企業收人的標準想當然也是異常的高，傳言中只收台大電資的書卷大神或是競賽選手，望向我那慘慘的在校成績，完全不敢想像要如何才能拿到進入Google的門票。

大四那年系上開了企業參訪，地點就是朝思暮想的Google，當下毫不猶豫就報名了，就此開啟了與Google的第一次相遇的緣分，那時候板橋的總部還沒有成立，我們參觀的是位於101的總部，隨著前往76樓的電梯快速上升，興奮的心情難以壓抑，電梯們打開的剎那，迎接我的是我朝思暮想的夢幻國度，原來新聞裡講的都是真的，免費的冰、免費的飲料、免費的五星級三餐，搭配著76樓的高空美景，真有種去度假的感覺，遊樂器材、打盹房也是真的，完全體現了Google對員工的信任，在與帶領我們的員工交流後了解到Google對員工管理的自由，不僅僅是工時上的自由，工作項目上員工也有相當大的主導權，員工甚至可以自行組建小組發起專案，就這樣在震撼中結束了與Google的第一次邂逅，從那之後進入Google成了我的夢想，我深知自己的不足，只能一步步的朝那裡邁進。

大四的暑假有了一次前往美國舊金山的機會，趁著這個機會再次造訪心中的夢想之地，位在山景城的Google總部，不過這次比較可惜沒有人脈可以帶我進去參觀參觀，只能當個觀光客在園區閒晃，雖然說只能從外部看，也能感受到整間公司以Have Fun為中心思想的氛圍，隨處可見的腳踏車、沙灘排球場、還有各式各樣的野餐區域簡直就是個大型的度假中心，後來也去了園區附近的紀念品中心買了不少伴手禮回來，朝聖之旅讓我感受的這間公司迷人的活力與矽谷這個科技業的傳奇之地的魅力，這裡的創造力與帶給世界的改變，我心想未來的某一天，我也希望能來到這裡工作。

回台灣之後進入了研究所就讀，原本就對自己的技術能力不太抱有信心，進入研究所後被各路大神強者環繞，更是讓我深切的感受到想要進入Google還有很長的路要走，在技術能力與研究能力上必須要有更上一層的累積，抱持著這個心態，在被研究進度追趕之餘也儘可能的參與各式各樣的side project、hackathon，也參與了幾個新創專案累積了一些參與新創的經驗，在跌跌撞撞之中夾雜著過人的運氣，在研究所的最後一年極度幸運的拿到了微軟的實習機會，開啟了一年的實習與研究所兩邊跑的生活，儘管這個老牌的軟體公司在Google、Facebook這些當紅的網路公司略顯遜色，但作為老牌卻長青的科技巨頭，仍提供了我不少的成長養分，開發技術能力的提升、專案管理能力的培養，也讓我得以窺見在科技公司中的生活模式。

2021年板橋的Google成立，將會是亞洲最大的硬體研發中心，能預期的是Google在台灣將會有大規模的人才招募活動，進入Google的難度也會較以往稍微容易，我深知想要進入Google這是個非常好的機會，在2021年底我在Linkedin上第一次收到來自Google HR的面試邀約，在與HR面談後了解到這是屬於Google Silicon的Hardware Engineer職缺，招募台灣電機背景或是有硬體開發經驗的工程師，只可惜我完全沒有學過硬體設計，對於verilog是一竅不通，面談後就完全沒有後續消息了…

2022年初聽聞有個學弟進入Google，我厚著臉皮請他幫忙推薦並投了2022年度的Software Engineer校園招募，這一次我總算沒有被拒於門外，順利的拿到了第一次面試的機會，就這樣開始了魔王級的面試挑戰之旅。

背景

112資管系雙主修森林系學士+112電信所碩士，沒有參加過程式競賽，也沒有貢獻過開源專案，只有和幾個朋友做過Side Project和Hackathon，大二修程式設計時因為花太多時間在社團而被當掉，大三重修A+過，資結演算法只能說是普通水準。

準備

差不多從2021年12月左右開始刷題，中間有一段時間在趕研究進度跟過年荒廢了一段時間，過完年後為了要強迫自己刷題買了一年份的Leetcode Premium，現在看起來是很不錯的投資，另外我也有買很多人推薦的Cracking the coding interview不過只有看一兩個不太熟的章節而已，刷題的策略前期我自己是從動態規劃開始練習，那時候是看花花醬的動態規劃終極學習方案系列影片累積思考動態規劃問題的技巧，差不多二月開始開始以寫完Leetcode前100題為目標，首先從Easy開始，然後是Medium，三月時開始以寫完Blind 75為目標，刷完一遍Blind 75後在去看前100題中的Hard題，最後在Onsite前一週努力刷Google面試的高頻率題，不得不說Leetcode Premium都將高頻題整理好了真的蠻方便的(而且真的蠻有用的XD)，這段期間每天會固定上去寫Daily，算是強迫自己每天維持解題手感，刷的題目數量，在Phone Interview前差不多150題左右，在Onsite之前差不多230題左右，相對於各路大神來說應該不算多，不過對我自己而言還算夠，各方面的題型都算是有顧到，自己的感覺是都能夠穩定的解出Medium，Hard則是可以想出可行解。比較可惜的是這段時間沒有找朋友幫忙Mock interview，面試經驗的累積是靠實戰累積，在這之前還面了Amazon、Nvidia。因為Google的Technical Interview至少會有兩關以上的全英文面試，英文也是很重要的一部分，雖然不用到Native specker那樣流利，但至少邏輯要能正確傳達，我英文的部分主要就仰賴實習的時候累積下來的，抱括日常聊天用語與解釋技術的能力，很感謝在這段時間願意跟我交流和我練習英文的人。這一段時間的刷題紀錄

刷題的三圍

時辰

2022/01/20 -> 收到朋友的內推通知信，官網投遞履歷，投的是Software Engineer, University Graduate, 2022 2022/03/07 -> 收到HR來信通知安排面試 2022/03/28 -> Phone Interview 2022/04/07 -> 通知通過Phone Interview，準備安排Virtual Onsite Interview 2022/04/25 -> 第一天Virtual Onsite Interview，兩關Technical Interview + 一關Behavior Interview 2022/04/26 -> 第二天Virtual Onsite Interview，兩關Technical Interview 2022/05/07 -> 通知面試結果most on positive 2022/05/26 -> 得知Hiring政策可能會異動

過程

要說面試有什麼最需要注意的，我會覺得是要保持平常心，這也是我認爲面試最困難的部分，畢竟在跟自己的夢想公司面試，興奮、期待、緊張等情緒交雜，很難保持平常心，在第一次Phone Interview時我甚至前兩天晚上都緊張到睡不著，能做的就是去Youtube上找各種國外講軟體工程師面試的影片來看，提醒自己面試該注意的點，英文類的也順便可以練習英文聽力，以下推薦幾個不錯的影片：

面試流程大解析，用SOP的方式講解軟體工程師面試，淺顯易懂
Google谷歌技术面试经验分享，這個講解面試的過程與注意事項講的很仔細，很有參考價值
How to tech interview Like a Pro，這個用搞笑的方式呈現程式面試的過程，蠻有趣的

Phone Interview

我差不多在預定時間的前十分鐘就坐在電腦前等，不過在預定時間點進去時面試官還沒上來，讓我緊張了一下以爲是不是記錯時間，等了差不多十分鐘後面試官終於來了，很抱歉的表示因為前面有一個會有一點耽擱到。面試官其實是一個親切的中國的小姊姊，一開始問了一個類似字串比對的問題，差不多是Easy等級，基本上一看到題目想到解法了，陳述了解法後面試官也同意這個解法，就花了10分鐘左右完成這題的coding，接著他表示有Follow up，比較像是會重複使用到第一題的概念屬於Medium等級，在思考這題的時候我原本以為只需要重複使用第一題的解法就行，結果發現我第一題使用的解法並非最佳解，到這邊其實有一點慌了，還好小姊姊人很好，不斷引導我去思考更好的解法，最終想出一個更佳的解法並花了幾分鐘實現，面試結束前小姊姊表示其實還有更好的解法，因此又花了幾分鐘請教一下，不過他表示這個解法他自己也沒有想到。個人評價，整體來說面試表現還行，解題並不是很流暢，中間卡了一下，但算是有解出來，所以也不到差。後來是通過了這一輪面試。

Onsite Interview

Technical Interview #1

這一關是一個人很不錯的中國的大叔，也沒有遲到，問了一題排序的變化題，一開始以為是Easy，但實際解下去後發現有Medium難度，完全錯估了這題的深奧程度，最一開始提了一個可行解，但面試官希望我提出最佳解，就這樣在這討論解法的30min中我至少提出了五六種解法，並分析在輸入範圍不同的情況下複雜度的差異，但我都沒有提出最佳解，後來在面試官的提示下想出了最佳解，但時間基本上已經用完了，我只能快速的將想法實作出來，後來想想自己實作的演算法是有Bug的，還好面試官人很好，並沒有很急著要結束面試，反而盡可能多留一些時間讓我完成面試，最後面試官回應我認為這是個很有趣的討論，認爲我提出了許多有趣的想法。有了Phone Interview的經驗後，並沒有讓我比較不緊張，反而一直很擔心面試官一上來就會來一題Hard，就面試情形而言自己覺得表現是比較糟糕的。

Technical Interview #2

這一關是一個懶得說話的小哥，問了一個類似尋找子字串的問題，他先請我思考一個brute force solution我基本上看完題目就有想法直接給出了解法，他聽完後也覺得可以因此就請我實作，我差不多花十分鐘實作完成並解釋了一下時間複雜度，接著希望我提出最佳解，對於最佳解自己其實沒什麼把握，只感覺字串應該可以用prefix tree來處理，因此提出了自己想法，沒想到他回應這是正確的思路，因此接續的想就給出了最佳解，還算順利的完成這一關，難度大概是Medium。在第一關爆掉之後這關心情反而輕鬆許多，有一點隨他去的感覺，大概是因為心情放鬆不少，反而思緒比較清楚，果然緊張才是大魔王。

Behavior Interview

這一關是一個中國的姊姊面試，首先問了一些蠻常見的Behavior question像是團隊的合作以及如何溝通，詳細題目網路上有蠻詳細的資訊，比較特別的是面試官問了一題有點類似產品設計的題目，因為事前完全沒有預料到，只能憑想像回答，但感覺面試官似乎沒有很滿意，面試最後有給個feedback認為我回答的沒有很深入，但他覺得我可能缺少工作經驗，因此回答的不深入也算預料之內。整體來說回答的算尚可，至少都有給出個穩健中庸的答案。

Technical Interview #3

第三關開始就變成了用英文面試，面試官還是中國小哥，不得不說跟同樣母語是中文的人用英文溝通難度真的低很多，可能是因為背後的思考還卡在中文的框架下。面試官問了一個tree traverse然後output路徑的題目，高度相似於leetcode上某題Google高頻題，剛好前幾天刷題有寫到，幾乎是秒想出最佳解，當然看到原題還是很興奮的，大概花了15分鐘講解完以及寫完code之後面試官給了我一個follow up，表面上是上面這題的延伸，但實際上已經轉換成BFS尋找兩點最短路徑的題目，還算是有趣的Follow up，這個變化在leetcode上就找不到了，這題同樣也是medium難度。

Technical Interview #4

第四關是一個沒有什麼表情的中國小哥，問了一個類似blind 75 pacific atlantic water flow的題目，看完題目後第一反應就連想到blind 75這題，事後也證明用同一題的方法可以解決這題，大概花了20分鐘講解跟寫完code後面試官同樣也給了follow-up，不過這個follow-up就沒有前一關有趣，只是單純數量上的增加，用同一題的方法改一下code就解決了，這題難度大概Medium。結果後來反而是這關的面試官認為我寫的code有些微的瑕疵，果然看到熟悉的題目還是不能太大意啊。

後續

我面試的時間已經算是Google 2022Campus Hire的末端了，大部分的缺都已經招完了，所以後來就變成直接沒有Headcount可以進行Team match，因此那時就有心理準備可能會需要等到下一年度的campus hire在繼續。

後來就如同大家所見的，在美國升息的壓力下各大公司開始被迫精簡人力，台灣這邊的campus hire也延到11月才開始，而headcount也必須要等到明年初人力政策確定後才會比較確定，好在面試結果可以保留一年，就祈禱明年還有機會可以繼續進行面試流程。

雖然尚未成功的進入我的Dream company，但這一路上還是很感謝許多人提供的機會以及幫助，此外也感謝協助我的Google HR不厭其煩的提供招聘流程的各種資訊。

玩遍老鏡頭 - Leica Summicron-C 40mm f2

Fri, 22 Jul 2022 14:52:00 +0800

玩遍老鏡頭 - Leica Summicron-C 40mm f2

前言

在這個時代窮學生想要玩M系統有很多選擇，便宜實惠的七工匠、銘匠；選擇多樣的voigtlader；畫質完全不輸Leica的Zeiss；甚至還有成群的上古時代M卡口、L39卡口老鏡可以選擇，50mm焦段大多數只要10000出頭就可以收的到，每一顆都很不錯，每一顆都充滿故事。

2020年的某天下雨的午後，窩在暗房沖片，一邊與其他社員交流器材，還記得一位朋友神神秘秘的從包裡拿出他的Leica M3讓我摸摸，那沈甸甸的手感、扎實的快門，突然明白為何總說摸過了就回不去了，回去的好幾個晚上總是心心念念著這台相機，過了不久我也買了人生中第一台Leica底片相機，只是買下它就花了大部分的積蓄，只能夠隨便弄一顆七工匠的35mm f2來充充飢，即便外人說這顆鏡頭CP值有多高，心裡仍然很不滿足，也確實拍出來的照片也很普通，都用上Leica的機身了，怎麼也得搭一顆Leica原廠鏡頭，至少我想要感受感受什麼叫做「德味」什麼叫做Leica美學。

後來就在網路上的交易平台遇到了這顆Leica Summicron-C 40mm f2，品項不算是太好，掉漆鍍膜刮傷等等的問題都有，價格也因此不太貴印象中是14000上下，實打實的德國製造、Leica卡設計。

介紹

這顆鏡頭當初就是走一個低價路線，主要是設計給Leica當年的M系統平價款Leica CL使用，Leica CL也是相當有故事的一台相機，在Leica最落魄的年代與minolta合作生產有較多電子零件的機身以吸引用戶，希望讓更多人感受到Leica的魅力而購買Leica的其他產品，結果大眾反而只願意購買價格較低的Leica CL而不願意購買當年的Leica M5，只得讓Leica早早停產這台相機，而Summicron-C 40mm也只隨相機生產個幾代就停產了，雖然說只生產幾代，但產量還是蠻大的，至今市面上還算是容易看到，相較其他M機型更小的身形也讓很多人喜愛。

[1]

隨然說是平價款，但這顆Summicron-C 40mm的成像還是不差，也算是比得上當時Leica的其他標準鏡，也因此大家寧可買這顆平價款，這顆鏡頭的用料也比得上Leica其他鏡頭，規格如下：

編號：11542
生產年份：1973-1979
數量：54,350
卡口：M mount
鏡片：六片四組
光圈：f/2 - f/16，10片
重量：120g

說到這枚鏡頭有些人會稱之為小七枚又或者是窮人的七枚玉，無非是相似的焦度圖個美名，但個人認為跟真正的七枚玉仍有不少的差距，要說比較接近的話應該是Leica六枚玉，兩顆鏡頭同樣都是雙高斯6片4組的結構，生產年份也十分接近(1971-1979)在鍍膜的技術上應該也會十分接近，除了焦段差別兩顆鏡頭其實十分相似，只可惜六枚玉一直被人戲稱為八枚玉的cost down版本畢竟少了2片，而且產在Leica最落魄的年代，回到Summicron-C 40mm，用六枚玉1/2的價格買到媲美六枚玉的光學，不香嗎。銘環上的C字標示了的他的命運，很難不讓人想到~~Cheap~~，就像iPhone 5c一樣(現在能說出這台手機的人好像也不年輕了)。

[2]

體積也是這枚鏡頭很大的優勢，這顆鏡頭完全可以被稱為餅乾頭，體積比Voigtlander出的那些Color-Skopar鏡頭還來的小，而且而且而且還有f2的光圈，據我所知，這應該也是Leica鏡頭群裡最小的Summicron鏡頭，不得不佩服Leica玩轉雙高斯結構的能力。

由於他太優秀了(跟六枚玉太像了)，Leica不得不對他做了一點點小改造，一個是濾鏡口雖然通樣是39mm卻不能使用一般的39mm濾鏡而是使用特殊的S5.5螺距的濾鏡，不過要硬上一般39mm的濾鏡還是可以，只是可能會把螺牙弄壞，或是拆不下來，另外這顆鏡頭也搭配了遮光罩，不過是橡膠製的伸縮遮光罩，可能方便但真的很醜，我收鏡頭的時候沒有附這個遮光罩，有的話我大概也不會裝，後來找來了一個仿萊卡的遮光罩裝上去，外觀看起來就有模有樣，我是一個有遮光罩就覺不會用鏡頭蓋的人，在旁軸相機上鏡頭蓋忘記拿下來真的是惡夢，有遮光罩多少可以防止我摸到鏡片。

另一個差別則是卡口，這顆鏡頭裝到M機身上的話會自動帶出50mm的匡線，有一說是Leica為了讓這枚鏡頭在M機上比較難用而做的小心機，不過這個小心機是可以透過一點手工將它避免的，也就是將圖片中最下面的插刀磨掉一點就可以讓他帶出35mm匡線了，Leica的35mm匡線是比較接近40mm焦段的，因此有35mm匡線會方便許多。

其他的差別像是對焦板手有別傳統的月牙改成一個奇特的三角形，光圈環帶有一點點的阻尼，不過Leica的鏡頭每一顆的光圈手感都不太一樣，即便是同一系列的鏡頭都有點差距，不愧是純手工組裝跟調教的鏡頭。接下來就來看看這顆鏡頭實際拍攝的樣子吧。

實拍

先用Portra拍幾張，試試看最強的負片表現如何

可以發現在光線充足的情況下，鏡頭的銳度、散景基本上不需要擔心

在低光線下人像的表現依舊很不錯，可以注意的是光圈全開的時候，在亮部的地方會出現小小的光暈，可來自於那個年代鍍膜技術的缺陷，有人也會稱為聖光。

在用valvia 100f拍幾張，試試看在正片上的表現在室內的表現也很不錯，顏色濃濃的韻味

換個場景試試看風景照如何

最後是在Provia 100f正片上的風景照

結語

作為我的第一顆Leica鏡頭，他陪我走過許多地方，我也用他記錄下了許多回憶，不得不說他是一顆好鏡頭，也讓我透過他認識了Leica的美學，但他也有些許缺點，像是不近不遠的40mm焦段、聖光等等，後來入手了Summicron-M 35mm ASPH後就將Summicron-C 40mm轉售賣出了，畢竟兩者的光學表現還是有很大的差距，還是期待未來有一天有機會可以再買回來這個對我而言充滿回憶的鏡頭。

參考

機械相機系列 - 哈蘇A12片盒上片方法

Mon, 11 Jul 2022 17:10:00 +0800

機械相機系列 - 哈蘇A12片盒上片方法

前言

前陣子被朋友推坑敗了一台哈蘇500cm + CB 60mm 3.5f，作為中片幅底片單眼相機，其機械結構的精妙不言而諭，即便不帶出去拿在手上把玩依舊很過癮，從觀景窗看出去，蔡司的光學之美展露無遺，唯一的缺點就是碩大的機身跟重量實在不太方便帶出門，買了好一陣子卻一直被我冰在防潮箱，最近終於下定決心要用它好好來拍照，心血來潮就記錄一下如何使用哈蘇A12片盒更換底片，對於初次使用哈蘇攝影的小白才驚覺還有許多細節需要注意，完全不如135底片相機來的無腦，一不小心就可能毀掉一捲底片跟辛苦累積的12張攝影作品。

從一位老師傅那裡收過來的黑色塗裝Hasselblad 500cm，一般人印象中的哈蘇有著銀色不銹鋼的外邊，有種古典工藝品之美，全黑的哈蘇則有種現代感也更為低調，CB 60mm 3.5f則是從品光攝影購入的原本是想搭個中規中矩的80mm，可惜當時市面上的80mm價格太過嚇人，CB 60mm算是CP質很高的選擇，銳度畸變都很完美，視角也接近135片幅的35mm鏡頭，不過實際拍攝給人的透視感就完全不同。

開始裝底片

拆片盒

首先要做的是將片盒從機身上拆下來，將片盒上的圓鈕往圖片左邊的方向撥就可以解開卡楯將片盒拆下，要注意如果豆腐刀沒有插回片盒上時卡楯是撥不動的，硬撥的話可能會造成機械損壞喔，片盒拆下來後要小心不要碰到機身後的兩片長得像門一樣的遮光板，否則弄壞造成漏光就不好玩了。

抽出上片機構

接下來要將裡面的上片機構取出來，但在取出來之前務必先確定一下裡面是不是還有底片，如果有的話確認一下是不是已經完成回片，如果貿然取出上片機構的話會造成裡面底片漏光就慘了，再來只要將片盒一側的旋鈕從左邊的樣子轉成右邊的樣子在向外拉就可以將上片機構拉出來了，有時候可能會拉不出來，大多都是因為插刀叉反了卡住上片機構，所以記得插刀也是有方向性的。

交換片軸

拆出來的上片機構長這樣，原來在左側的是舊的片軸，需要將他換到右邊去，所以舊的片軸不要弄丟，如果弄丟也只能去~~找底片沖洗店家要了~~，哈蘇的片盒在拍完後會將底片回卷到舊的片軸上，所有每次都回留下上一次拍的底片的片軸。

底片

今天要裝的是Kodak的Portra 400底片，這捲應該是在底片種類越來越少的年代少數能讓人滿意的底片，色彩的寬容度與細緻度都比新的Gold 200還要好上許多，而且還有400度的ISO能提供比較高的快門速度，除了價格偏高外應該算是120彩色的首選了。

拆開120底片包裝後，需要撕開底片外部的紙封條，拉出來的這一段其實不是底片而是背紙，是120底片和135底片最大的差別，120底片因為沒有片殼，要防止底片意外曝光就需要靠背紙遮光，真正的底片是夾在背紙中間，拉到某一個位置會將真正的底片一起拉出來，真正的底片跟背紙是用一段紙膠帶黏起來的，詳細的結構可以參考這篇：120底片結構。

安裝底片

首先我們將底片安裝到右側原來放片軸的位置，請注意背紙拉出的方向，是從下方拉出的，不要將底片的方向裝反，接著將背紙拉到上片機構的背面。

將背紙繞到背面後，請注意在上片機構上有一個用來夾住背紙的結構，這個結構在拉出上片機構的時候是卡緊的，我們需要先將上片機構的旋鈕轉回原位這樣這個夾背紙的結構就會鬆開，才方便讓背紙從下面通過。

背紙通過之後在將上片結構的旋鈕轉回開啟的狀態，這個結構就會再夾緊背紙。

將背紙的末端穿過舊的片軸中心的孔洞。

最後我們旋轉另一側片軸下方的旋鈕收緊背紙，持續旋轉直到新底片側出現START箭頭(不一定有START)，這個箭頭會對齊片盒上的紅色箭頭，這樣就完成底片的安裝了。

裝回上片機構

裝回的時候請注意上片機構旋鈕的位置，需要將夾背紙的機構收緊上片機構才裝的進片盒中，裝進去後再將旋鈕轉回原位完成上片機構的安裝。

哈蘇的片盒需要將底片預先捲至最後一張，可以理解為哈蘇片盒是從最後一張開始拍的，因此需要選轉片盒另一側的旋轉把手直到片盒左下角的小窗出現數字1。

最後將片盒裝回機身就可以開始拍攝了，記得在裝回機身時確定機身已經是過片狀態了，否則裝上片盒再上片會讓底片少拍一張。

拍攝的時候要記得拔出片盒插刀，不然快門是按不下去的。

從觀景窗看出去的畫面，蔡司光學的成像真美呀。

實拍

附上一些Portra 400實拍的畫面給大家參考，紫羅蘭沖掃

遠東軟體園區正在蓋的Google新大樓

Google板橋辦公室門口的Logo

Google板橋大樓

Google辦公室樓下的貳樓餐廳

內湖往野柳的小路

風櫃嘴的展望

A12片盒的一些奇淫巧技

Docker使用小筆記

Mon, 30 May 2022 14:56:58 +0800

Docker使用小筆記

前言

Docker可以說是雲端技術中非常重要的一項專案，這個專案實現了Container技術，使得軟體的執行可以不在受系統環境限制，更加速了雲端技術中Microservice概念的發展，以下就簡單介紹常用的Docker指令。

基本操作

離開但不關閉container：

1

crtl+p crtl+q

連著打

查看container列表

1

sudo docker container ls

進入container

1

sudo docker attach <ID>

關閉container

1

sudo container stop <ID>

Docker Image操作

查看image列表

1

sudo docker image ls

下載image

1

sudo docker pull <hub path>

1

sudo docker run <--gpus all> <-it> <-p 80(local):80(docker)> <-v /data(local):/data(docker) <images> <command>

image commit

1

sudo docker commit <ID> <images name>

Reference

https://larrylu.blog/step-by-step-dockerize-your-app-ecd8940696f4

在沒有sudo權限使用docker： https://docs.docker.com/engine/security/rootless/
docker儲存： https://peihsinsu.gitbooks.io/docker-note-book/content/docker-save-image.html
docker run 操作： https://noob.tw/docker-basic/
docker port： https://www.runoob.com/docker/docker-run-command.html
nvidia docker： https://gitlab.com/nvidia/container-images/cuda/blob/master/doc/supported-tags.md https://www.celantur.com/blog/run-cuda-in-docker-on-linux/ https://docs.docker.com/engine/reference/commandline/run/#access-an-nvidia-gpu error解法： https://github.com/NVIDIA/nvidia-docker/issues/1243
x11 firefox docker： https://stackoverflow.com/questions/16296753/can-you-run-gui-applications-in-a-docker-container
指令大全： https://github.com/docker-library/php/issues/359
沒有中文的解法： https://github.com/docker-library/php/issues/359

Linux終端機視窗管理工具tmux筆記

Mon, 30 May 2022 13:32:31 +0800

Linux終端機視窗管理工具tmux筆記

前言

一般在操作遠端的Linux主機時通常會使用SSH連線進去操作，然而若遇到需要執行一個不可中斷的指令但又不得不中斷SSH連線時，一般情況下會將該Process拉到背景執行或是使用視窗管理工具screen，而tmux則是另一個非常強大的視窗管理工具，可以在終端機中模擬視窗操作，包括視窗的切換、視窗的切割等等，以下就列出一些tmux常用到的一些指令。

基本

進入tmux

1

tmux

列出tmux視窗列表

1

tmux ls

連接tmux使窗

1

tmux attach -t 0

1

tmux attach -t database

建立一個名為database的視窗

1

tmux new -s database

更改名稱

1

tmux rename-session -t 0 database

水平切割

1
2


ctrl+b
%

垂直切割

1
2


ctrl+b
"

建立新視窗

1
2


ctrl+b
c

上一個視窗

1
2


ctrl+b
p

下一個視窗

1
2


ctrl+b
n

依照編號直接切換（編號顯示於狀態列）

1
2


ctrl+b
<number>

視窗選單

1
2


ctrl+b
s

滑動視窗

1
2


crtl+b [
q (離開)

進階

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


# 新增
$ tmux
# OR
$ tmux new -s <your_session_name>

# session 列表
$ tmux ls

# 重新連線 session
$ tmux a -t 0
# OR
$ tmux a -t <session_name>

# 刪除 session
$ tmux kill-session -t 0
# OR
$ tmux kill-session -t <session_name>
# OR
$ tmux kill-session -a # 全部

# 刪除 tmux server
$ tmux kill-server

# 重新命名 session
$ tmux rename-session -t 0 <new_session_name>

# 快捷鍵/視窗管理
# C-b ? Help
# C-b c 新增視窗
# C-b， 視窗命名
# C-b w 視窗列表
# C-b f 尋找視窗
# C-b & 刪除視窗
# C-b % 垂直分割區塊
# C-b “ 水平分割區塊
# C-b <方向鍵>
# C-b p 上一個視窗
# C-b n 下一個視窗
# C-b <number> 依照編號直接切換（編號顯示於狀態列）
# C-b d 離開 session
# C-b x 關閉 Pane
# C-d 關閉 Pane
# C-b z 讓一個 Pane 變成全螢幕，在輸入一次則回到剛剛的尺寸

Reference

ssh自動連進tmux https://stackoverflow.com/questions/27613209/how-to-automatically-start-tmux-on-ssh-session
與iterm結合 https://medium.com/@wancw/iterm2-ssh-tmux-73d3fcf9dac6

Google Interview Leetcode Question Challenge

Mon, 30 May 2022 11:41:18 +0800

Google Interview Challenge

https://www.1111.com.tw/1000w/fanshome/discussTopic.asp?cat=FANS&id=301667

https://www.gushiciku.cn/pl/gyQP/zh-tw

https://hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed

https://docs.google.com/spreadsheets/d/1yRCOJ8KysRVkq0O9IlDriT01tC6lzPapmFO4PCmDJQA/edit#gid=126913158 Google面試準備刷題類型

Arrays
Binary Search Tree
Binary Tree
Dynamic Programming
Greedy
Graph – BFS、DFS
Heap
LinkedList
Recursion
Searching – Binary Search、Quick Select
Stack
String
Sorting
Topological sorting
Trie

Google面試經典題目

coin change
coin change 2
Unique path
Unique path 2
Permutation
Permutation 2
subset
subset 2
search in rotated sorted array
search in rotated sorted array 2
word break
word break 2
jump game
jump game 2
word search
word search 2
combination
combination 2
meeting room
meeting room 2
number of islands
number of islands 2
number of distinct island
number of distinct island 2

BQ準備 Imagine you worked in a project or a team that had a problematic culture Tell about the leading experience of a group project Thinking about a time you were given a large amount of work to complete under the tight deadline Tell about a time you face a problem without having clear solution How do you solve the conflict that happen in the team

Array

Binary

Dynamic Programming

Graph

Clone Graph
Course Schedule
Pacific Atlantic Water Flow (M)
Number of Islands
Longest Consecutive Sequence (M)
Alien Dictionary (Leetcode Premium) (H) Key: directed graph + DFS or BFS
Graph Valid Tree (Leetcode Premium) (M) Key: Check edges number first and then check unconnected component (Graph theory), Union Find!
Number of Connected Components in an Undirected Graph (Leetcode Premium) (M)

Interval

Insert Interval
Merge Intervals
Non-overlapping Intervals (M) Key: greedy
Meeting Rooms (Leetcode Premium)
Meeting Rooms II (Leetcode Premium)

Linked List

Matrix

String

Longest Substring Without Repeating Characters
Longest Repeating Character Replacement
Minimum Window Substring (H) Key: Optimized Sliding Windows!
Valid Anagram
Group Anagrams
Valid Parentheses
Valid Palindrome
Longest Palindromic Substring Key: Manacher’s Algorithm
Palindromic Substrings (M) Key: Manacher’s Algorithm
Encode and Decode Strings (Leetcode Premium) (M)

Tree

Heap

Tips

https://hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed

Funny One

Count Unique Characters of All Substrings of a Given String Key: really special solution
Find the Duplicate Number
Find Leaves of Binary Tree
Split Array Largest Sum Key: Binary Search!!!
Trapping Rain Water
The Skyline Problem Key: Select the building with heapqueue
Largest Rectangle in Histogram Key: tricky Apply with stack!!!
Subtree of Another Tree Key: Markle Hash
Substring with Concatenation of All Words Key: Sliding Window
Longest Valid Parentheses key: Two pointer or DP or Stack
Best Time to Buy and Sell Stock IV Key: Tricky One pass solution (DP or O(k) space)
Design HashSet Key: Multiplicative hashing
Unique Binary Search Trees Key: Catalan number!
Shortest Path in a Grid with Obstacles Elimination Key: BFS + A*
Student Attendance Record II Key: hardhard DP
Guess the Word Key: Game theroy, compare with previous
Min Cost to Connect All Points Key: minmun spanning tree!! (Prim’s or )
Path With Minimum Effort Key: Binary search space
132 Pattern Key: stack+min array

我的台大魔幻之夜之路

Sun, 19 May 2019 16:50:00 +0800

我的台大魔幻之夜之路

前言

睽違三年再一次坐在台下欣賞台大魔夜有別於當上下桌、表演者、核幹時看魔夜的各種緊張我又再一次被這奇幻的晚會感動回想大一時初次踏入社課看著鼎皓變著馬戲團騙術轉眼間即將披上領巾準備畢業四年來魔術社是家、是生活的重心、是不可分割的一部分那麼就以這篇心得文來總結一下吧

魔夜之路

起源

故事的開始起源於高中時一位魔術社的學長給我看了化內在Le plus的影片影片放著而他滔滔不絕的說著：在遙遠的台大魔術社有一群很厲害的魔術師而且沒人知道為什麼他們這麼厲害這讓我非常好奇後來我得知這些人都曾上過台大魔幻之夜那究竟是個怎麼樣的舞台呢是不是真的跟傳聞一樣厲害？

19魔《表演者聯盟》

機會很快的來臨在寒假的Magic is Concept活動中意外的抽中了兩張19魔的門票然後我遊說了詠辰還有社團的朋友一起去看在那個只能看魔幻達人秀欣賞魔術的環境台大魔幻之夜讓我看見魔術的新世界九個厲害到爆表的表演和從頭讓人爆笑到尾的主持這真是太厲害了我總有一天一定要站上這個舞台

20魔《Lumos》

高三下即使成為指考戰士仍弄了張20魔的門票無奈九點半只演完半場只能打消看完魔夜的念頭後來聽到下半場各種精彩真的是十分後悔若知道下一次能坐在台下看是四年後大概會更後悔QQ

21魔《21Hero》

然後就懞懞懂懂的上了台大懞懞懂懂的加入了台大魔術社懞懞懂懂的看著昀恆變魔術(昀恆抱歉QAQ我社課頗常消失…) 不知不覺的留給魔術的時間越來越少直到有一天我還真的相信對魔術的熱情大概就到這了然後詠辰突然告訴我他被找去當魔夜上下桌在那裡他看到了很多厲害的東西出於好奇後來我也填了當上下桌也很幸運的被選中踏入二活這神聖的地方我看見了許多不可思議的事最初震撼我的是楊詒強到不行的表演緊接著是各個表演者在長老日以繼夜的精雕細琢下在極短的時間內快速的進化、蛻變變成一個個屌炸天的表演再次讓我相信要成為台大魔夜的表演者並不是什麼遙不可及的夢想

22魔《魔法師與他們的產地》

在魔夜症候群的驅使下考了教學接受了一整年當幹部的洗禮算是補了之前當新生時沒學好的種種然後匆匆忙忙的完成了甄選程序過了甄選後浪費了到一驗前的時間開啟了各種趕進度的魔夜之路經過了五驗的崩潰後終於完成了自己還算滿意的程序最後站上了台大魔幻之夜的舞台完成了高中時對自己得承諾一路上要感謝的人太多了首先一定要感謝辛苦的核幹們感謝你們相信我能夠上魔夜並給予我機會

感謝明翰感謝你給我許多美感上的建議還記得六驗後某一天我很崩潰時你看我跑完後默默的說了一句：跑的不錯當下真的有種噴淚的衝動
感謝昀恆感謝你給我許多動作上的建議也給我許多燈光上的建議你的嚴格絕對是我們進步的動力
感謝張騰感謝你幫我解決道具上的疑難雜症也感謝你時常鼓勵我給予精神上的支持
感謝芃雅感謝你時常帶許多東西來給我們吃每次看到你來都有種被救贖的感覺
感謝宣伯在魔夜前期沒有方向的時候幾乎是以你的表演作為模板也感謝後來不厭其煩的給我許多服裝上的建議到了魔夜後期也花了不少時間幫我修程序沒有你的幫忙我不可能生出這套程序
感謝彥彥感謝你總是能在各種時候給予鼓勵縱使課業很忙也還是空出時間來幫我修程序讓我的程序越來越符合我心目中的樣子
感謝小梅給你修完之後總有突然進化的感覺真的很喜歡你修的東西也感謝你教我許多動作設計上的觀念至今仍受用無窮
感謝柏誠高中時期就幫助我很多的學長感謝你魔夜時幫我解決各種手法上的難題
感謝化內高中時期的偶像雖然早就聽說你很嚴格但我早已迫不及待請你幫我修程序了感謝你幫我挑出許多動作上的瑕疵也在程序初期決定方向時給了我許多很有用的建議
感謝小鬼感謝你總是能詳細且面面俱到的回答各種問題每次驗收後根據影片給予的意見也是受益無窮也感謝你解決了一些道具上的問題
感謝 En-Jui Shang 高中時期的偶像之二感謝你抽空幫我修程序你就如傳聞中一樣厲害總能把看次普通的效果提升到另一個層次
感謝子袁感謝你常常出現在二活看我跑程序也總能在我跑完後給予不少建議
感謝小邱感謝你總是默默出現在二活看我們練習也總是不厭其煩的幫我們解決各種程序的bug
感謝凌宇感謝你時常來二活給予我們鼓勵
感謝元廷感謝你在程序初期給我許多建議
感謝楊詒感謝你給了我許多跳脫框架的建議
感謝 Michael Yang 感謝你在甄選前給予我道具上的意見
感謝白菜感謝你抽空幫我修程序
感謝俊緯感謝你在我做不出道具時給予協助
感謝晉豪感謝你陪我一起研究各種電路雖然最後沒有用到QQ
感謝 Hsieh Kai Kai老師感謝你能量滿滿的鼓勵
感謝御伶感謝你時常來二活陪我們練習有你在的時候二活總是充滿快活的氣氛
感謝昱先在程序前期的時候很熱心的給我許多建議
感謝教學組的各位感謝每次預講的各種歡樂總能紓解魔夜時的壓力
感謝詠辰能認識你真的太好了從高中互相鼓勵一起上成發到大學互相提攜一起上魔夜不的不說你真的給了我很多上魔夜的動力期待未來能我們能在各方面繼續發光發熱
感謝 How Jiun Hsu 感謝你當教學長總是那麼carry 也很佩服你在魔術上總有無窮無盡的想法
感謝昌錦總是在預講時提出許多想法
感謝宣諭感謝你總是那麼認真努力激起了對魔術的熱血
感謝杰勵感謝你的各種梗總能讓人會心一笑
感謝22魔的大家感謝祐增、翁鈞、德彥(BIMF加油餒)、 Davin Dai、彥霓、宥任、孟豪、晴晨、皓屏因為有你們 22魔才可以如此精彩

感謝台大眾多長老們的幫忙我才得以站在台上所有幫助過我的長老我都銘記在心經歷過了魔夜才明白一人單打獨鬥是不足以撐起魔夜的魔夜是長老們集體智慧的結晶少了一點就不會如此完美了

23魔《不能說的秘密》

又一次魔夜症候群發作我接下了核幹十分感謝上一屆核幹相信我能夠勝任這份工作當核幹是我在魔術社裡學到最多東西的地方包括各種行政事務、危機處理如何辦好一場活動、如何規劃一場好的晚會如何帶領一屆表演者從什麼都不會到最後站上台大魔夜的舞台而過程仍舊是要感謝台大眾多長老的幫忙

感謝核幹夥伴

感謝社長皓鈞感謝你總是如此的carry讓人放心所有無解的問題到了你的手上似乎自然有了答案
感謝副社長宣諭你細膩的心思總是能直接且俐落的給予表演者們心靈抑或是實質上的協助也感謝你義無反顧的接下了舞台總監的位置
感謝執秘彥霓感謝你在處理行政事務上的不遺餘力也感謝你總是能給予表演者們精神上的鼓勵

感謝上屆核幹

感謝昀恆即便你課業繁忙仍然投注大量的時間給魔術社從給予表演者意見並協助表演者完成程序到各種行政上的問題沒有你23魔就不會如此順利
感謝張騰依舊感謝你各種道具力的支援以及魔夜當天燈控的各種協助沒有你魔夜不會這麼好看
感謝明翰感謝你協助宣傳品的製作還有幫忙做帥翻天的開場片
感謝芃雅感謝你各種行政上的支援

感謝常回來的長老們

感謝胖子感謝你為這屆表演者費盡心思還有你的炸海苔
感謝白菜感謝你時常回來幫忙盯表演者練習
感謝小邱也是感謝你時常回來幫忙盯表演者練習
感謝詠辰你就如同第五位核幹處處協助著我們
感謝所有長老在百忙中撥空回來協助表演者沒有你們不會有23魔
感謝凱昇老師你是台大魔夜的守護神

最後恭喜各位23魔的表演者恭喜你們完成目標站上台大魔夜的舞台感謝你們的堅持

感謝荐泓從什麼都不會的新生到最終能獨當一面站上舞台的表演者讓人看了真的很欣慰
感謝 Aaron 你真的是天才總是能自己想出許多有趣的演繹也不太需要我們擔心
感謝家立感謝持續不懈的努力最終的表演也無愧於你的努力與長老的幫助
感謝晉璿你絕對是23魔最認真的表演者從暑假到甄選前的練習你從未有過任何怠惰而你流暢的表演至今讓我印象深刻也是不太需要核幹擔心的表演者
感謝中漢 23魔喜劇擔當比起帥氣的變魔術搞笑大概更適合你從準備甄選時就看得出你的積極也很高興最後終於找對路爆氣全場
感謝御伶感謝你一直以來對台大魔術社的熱愛也恭喜你最終完成一套屬於你的而謝非常精彩的表演
感謝雷邱感謝你一直以來對魔術的熱情也完成了一套相當厲害的程序期待你之後的發展
感謝謙煜又是一個天才你的霸氣是自然流露出來的真的很厲害也感謝你撐起了壓軸這個位置也最終爆氣全場相當精彩
感謝主持昱翔、家儀、晏榆、莎莎感謝你們經常熬夜改劇本也絞盡腦汁想出許多很不錯的梗魔夜當天讓我從頭笑到尾真的是非常好看的

當核幹輕不輕鬆見仁見智但壓力肯定是不會小的畢竟一直以來台大魔夜以高水準著稱而如今也輪到我們扛著這份壓力但當看到最後的成果時一切的付出皆值得了

24魔《魔法師與理想國》

卸下了核幹的身份有更多的時間嘗試自己想嘗試的事物睽違三年再一次坐在台下欣賞台大魔夜回到了初學魔術時那樣興奮又期待的心情而看完魔夜的那份感動讓人久久不能自已果然只有台大魔夜才能超越台大魔夜台大魔夜就如同一場好長好長的夢當它醒來之後你會知道是時候好好面對自己的人生了感謝這屆的核幹感謝富淼、師傅、Aaron、晏榆感謝你們竭盡餘力撐起社團感謝這屆表演者感謝你們撐過了各種驗收與考驗各種辛苦將化為甜美的果實希望你們都有享受到這充滿奇幻與魅力的舞台感謝所有長老、凱昇老師我們又再一次完成如此好看的晚會

致謝

重要的人總是要放在最後感謝父母感謝你們容許我投注時間在魔術社上僅管為了魔術社已經很久沒有回家吃飯很久沒有好好跟你們說話你們卻不曾阻止過我也感謝你們在能力有限的情況提供我資源讓我有能力去嘗試去挑戰無論如何你們才是我最該感謝的人感謝家儀感謝你總是容許？我三不五時往魔術社跑感謝你在我上魔夜時支持我專注於準備表演感謝你在你上魔夜時沒有怨懟我時常要求你來練習感謝你一直以來無條件的支持我、相信我謝謝你感謝施星宇感謝你堅強的心感謝你不放棄的靈魂最後感謝台大魔術社當初的一個好奇一不小心就花了四年的時間來探索彷彿是一抸眼卻說短也不短了真的是一趟奇妙的旅程呢

Datacube 函式筆記

Fri, 22 Mar 2019 00:58:25 +0800

Datacube 函式筆記-基礎

API函式

可以參考這個網站：https://nbviewer.jupyter.org/github/opendatacube/datacube-core/blob/develop/examples/notebooks/Datacube_Summary.ipynb 官方函式說明：https://datacube-core.readthedocs.io/en/latest/_modules/index.html 調整圖片顏色：http://xarray.pydata.org/en/stable/plotting.html 範例包：https://nbviewer.jupyter.org/github/opendatacube/datacube-core/tree/develop/examples/notebooks/ xarray用法：https://xarray.pydata.org/en/stable/generated/xarray.Dataset.html#xarray.Dataset https://xarray.pydata.org/en/stable/api.html#dataarray

：Datacube class，建立一個Datacube項目，用來導入Datacube資料庫時會用到

1
2


class datacube.Datacube(index=None, config=None, app=None, 
env=None, validate_connection=True)

範例：

1
2
3
4


import datacube
dc = datacube.Datacube(app = 'my_app', config = 
'/home/localuser/.datacube.conf') 
#基本上就看你用的Datacube裡面的資料位置在哪，建議直接用

：Datacube.list_products() & Datacube.list_measurements()

Datacube.list_products()：列出所有的衛星資料
Datacube.list_measurements()：列出衛星資料所含有的波段種類

範例：

1
2
3
4
5


list_of_products = dc.list_products()
netCDF_products = list_of_products[list_of_products['format'] == 'NetCDF']
netCDF_products
#list_of_products的參數就照上面設，我也不知道差別在哪
#印出來就一個表格

1
2
3


list_of_measurements = dc.list_measurements()
list_of_measurements
#可以直接印出來，印出來也是一個表格

：Datacube.load()，建立一個xarray.Dataset用來儲存要撈的資料的各種參數

1
2
3
4


Datacube.load(product = None, measurements = None, output_crs = None, 
resolution = None, resampling = None, dask_chunks = None, 
like = None, fuse_func = None, align = None, 
datasets = None, **query)

範例1：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


import datetime
# define geographic boundaries in (min, max) format
# 用兩個變數來儲存要找的經緯度範圍(方框)，我也不知道多邊形怎麼用
lon = (120.3697, 120.5044)
lat = (23.6686, 23.7476)

# define date range boundaries in (min,max) format
# 用datetime格式來儲存要提取資料的時間範圍
date_range =(datetime.datetime(2016,1,1), 
datetime.datetime(2017,6,30))

# define product and platform to specify our intent to 
#load Landsat 8 sr products
platform = 'LANDSAT_8' 
# 衛星資料的模板，其實可以不用打，要打就不要打錯
product = 'ls8_lasrc_taiwan'
# 用來辨識讀取哪一個衛星的資料，絕對不能打錯


# define desired bands. 
desired_bands =
['red','green','blue','nir','swir1','swir2','pixel_qa'] 
# 要提取的波段資料
# 以Landset8的話共有coastal_aerosol、blue、green、red、nir、swir1、swir2、
# lwir1、lwir2、pixel_qa、sr_aerosol、radsat_qa這些波段，我們只提取了其中幾個，也可以在加
# 輸出的順序會按照陣列的裡的排列出現

# load area. Should result in approximately 15 
#acquisitions between 2014 and 2016 
landsat = dc.load(product = product,platform = platform,
lat = lat,lon = lon,time = date_range, 
measurements = desired_bands)
landsat
# 然後實際把資料load出來，回傳的格式是xarray.Dataset

範例2：

1
2
3
4
5
6


dc.load(product='ls5_nbar_albers', x=(148.15, 148.2), y=(-35.15, -35.2), time=('1990', '1991'),
# 時間座標等也可以用上面這種表示法
x=(1516200, 1541300), y=(-3867375, -3867350), crs='EPSG:3577'
# 也可以這樣，只是就要附註crs
# 時間也可以用上面那種方法
output_crs='EPSG:3577`, resolution=(-25, 25), resampling='cubic')

：Datacube.find_datasets()、Datacube.group_datasets()、Datacube.load_data()

Datacube.find_datasets()：列出符合條件的影像資料位置，以list方式回傳
Datacube.group_datasets()：將上面find_datasets()回傳的list裡的資料group起來，也可以自己弄一個符合格式的檔案路徑list，然後一樣嘢可幫你group起來
Datacube.load_data()：把剛剛group起來的資料load出來

1
2
3
4
5
6
7
8
9


Datacube.find_datasets(**search_terms)
# 參數的部分要輸入一種特殊的Query型態，不過datacube怪怪的，不能import這種格式
# 所以等下範例有直接輸入參數的方式
Datacube.group_datasets(datasets, group_by) # 放棄嘗試這個函式XDD 主要是不知道group_by參數要填什麼
# 就是傳入上面那個find_datasets return 的東西
# 會回傳先前看到的xarray.DataArray格式
Datacube.load_data(sources, geobox, measurements, resampling=None, fuse_func=None, dask_chunks=None, skip_broken_datasets=False)
# 也是放棄嘗試這個函式XDD
# 傳入剛剛group_datasets弄好的xarray，然後傳出xarray.Dataset

範例：

1
2


dc.find_datasets(product = 'ls8_lasrc_taiwan', time = ('2016-01-01', '2017-01-01'))
# 然後就會回傳一個list，裡面有所有符合條件資料的位置

：加入crs資料其實這步可以不用做，基本上就是把讀取的參數整合

1
2
3
4
5
6
7


import xarray as xr 
import numpy as np
# xarray是用來儲存讀取資料的格式
combined_dataset = xr.merge([landsat])
# Copy original crs to merged dataset 
combined_dataset = combined_dataset.assign_attrs(landsat.attrs)
combined_dataset

：實際撈資料

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


import time # 裡面有把時間轉為字串的函式
import rasterio # 將點狀資料轉成圖塊
from dc_utilities import write_geotiff_from_xr # 這蠻重要的，可以將xr格式轉成geotiff格式

def time_to_string(t): # 將時間轉為字串
 return time.strftime("%Y_%m_%d_%H_%M_%S", time.gmtime(t.astype(int)/1000000000))
 # 就採用`time.strftime`函數將時間轉為字串，等等用來加入檔名當中

def export_slice_to_geotiff(ds, path): # 將資料轉為實際的tiff檔案
 write_geotiff_from_xr(path,ds.astype(np.float32),list(landsat.data_vars.keys()),crs="EPSG:4326")
 # 在這裡引用了write_geotiff_from_xr()函數，path是新建的tiff檔案的路徑和檔名，
 # ds.astype(np.float32)是將原來資料裡的整數值轉為浮點數值，大概是因為這個函數只接受浮點數，
 # list(landsat.data_vars.keys())則是將這裡面所有的屬性質(就是nir、red、blue那些)轉成list形式而已
 # 最後crs就不必說惹，可以試一下怎麼直接從原來那個xarray.Dataset讀取這個資料，手動輸入實在很智障

#For each time slice in a dataset we call export_slice_to_geotif
def export_xarray_to_geotiff(ds, path):
 for t in ds.time: # 接著就根據xarrayDataset.time裡面的時間資料list一筆一筆抓出來處理
 time_slice_xarray = ds.sel(time = t) 
 # 先是搞一個新的xarray，然後把裡面的time換成單一的值(有點像是從一層抽出一片的感覺)，以便等會用write_geotiff_from_xr轉換
 export_slice_to_geotiff(time_slice_xarray, path + "_" + time_to_string(t) + ".tif")
 # 然後就呼叫export_slice_to_geotiff，其實就是write_geotiff_from_xr()函數
#Start Export
output_dir = "/home/localuser/Datacube/data_cube_notebooks/NTUF_Hsing-Yu/ToTiffTest" # 存檔的路徑

if not os.path.exists(output_dir): # 資料夾存在就直接存，沒有就新建一個
 os.makedirs(output_dir)

export_xarray_to_geotiff(landsat, "{}/{}".format(output_dir,product)) 
# "{}/{}".format(output_dir,product)的用法還沒有研究

：資料繪圖plot() 在xarray.Dataset的格式下可以直接呼叫plot()函數匯出影像

範例1：

1
2
3
4
5


autumn = nbar.green.loc['1991-3':'1991-5'] # 圖檔的話好像只能用單一波段繪圖， 所以這邊要選擇你要的波段
# 這邊是選綠色，然後後面那邊可以設定時間區間，似乎也是可以不用設定！？
autumn.shape # 看一下格式這樣
autumn.plot(col='time', col_wrap=3) # 然後印出圖形，橫軸按照時間排列，每一排三個
# 印出來之後就向下圖這樣

範例2：去除nodata的版本：

1
2


autumn_valid = autumn.where(autumn != autumn.attrs['nodata']) # 新建一個變數，用來儲存去除nodata的資料
autumn_valid.plot(col='time', col_wrap=3) # 然後一樣輸出

範例3：去除雲 在landsat5以後的衛星資料會提供一個pixelquality波段，通常是用來表示該相素的含雲量，有幾個特定的值是表示該像素是可以用的，不過我忘了

1
2
3
4


pq = dc.load(product='ls5_pq_albers', x=(149.25, 149.35), y=(-35.25, -35.35)) 
# 一樣先load做出xarray.Dataset ，可以注意到這邊load的版本是ls5_pq_albers，跟前面load的nbar版本不一樣
pq_autumn = pq.pixelquality.loc['1991-3':'1991-5'] # 然後一樣，只是改成以pixelquality波段作圖
pq_autumn.plot(col='time', col_wrap=3) # 顯示出來就像下面那樣

可以注意到有特殊顏色的就是含雲量較高的像素，正常應該是黃色，所以等等要將這些有色區塊去除這邊會用到masking工具，可以從datacube.storage中取出來

1
2
3
4
5


from datacube.storage import masking # 取出masking工具
import pandas
pandas.DataFrame.from_dict(masking.get_flags_def(pq), orient='index') 
# 這裡的masking.get_flags_def(pq)，是從原來的xarray.Dataset找到如何判斷pixelquality值的表
# 然後就會得到一個對照表

1
2
3
4
5
6
7


good_data = masking.make_mask(pq, cloud_acca='no_cloud', cloud_fmask='no_cloud', contiguous=True)
# 接下來要建立一個新的mask，mask上顏色不同的地方就是判定有雲的地方
# 根據前面的表，只要把cloud_acca和cloud_fmask這兩個變數都設為'no_cloud'，而contiguous=True則是表示這個pixel還含有其他波段，
# 可以試試設成false會怎樣
# 這樣就可以做出一個mask
autumn_good_data = good_data.pixelquality.loc['1991-3':'1991-5'] # 然後再一次實際套用到剛剛的xarray.Dataset上
autumn_good_data.plot(col='time', col_wrap=3) # 印出來就如下圖

可以發現，現在不是黃色就是紫色最後拿去跟一開始有綠色波段且做過nodata處理的那張圖疊

1
2


autumn_cloud_free = autumn_valid.where(autumn_good_data) # 就跟用來疊nodata的作法一樣
autumn_cloud_free.plot(col='time', col_wrap=3) # 印出來就像下面那樣

可以發現原本有雲的地方都變成無資料了，因為mask裡面，有雲的地方，數字被設為0，沒有雲的地方為1

後來發現mask不給力，landsat8的資料不太能用，因此我就直接用where取出pixel_qa為322的資料範例：

1
2
3
4
5
6


autumn = combined_dataset.green.where(combined_dataset.pixel_qa == 322)
# 取值為322的資料，這是landsat8中品質最好的資料
autumn_valid = autumn.where(autumn != autumn.attrs['nodata'])
# 一樣清除nodata
autumn_valid.plot(col='time', col_wrap=10)
# 印出來就像下面那樣(顏色沒有調得很好XDD)

：將圖群組化(超重要！！) 有時候因為衛星軌道的關係，一個地區的影像會被切成兩三張圖放，用Group可將時間相近的圖整合成一張

範例：

1
2
3


nbar_by_solar_day = dc.load(product='ls5_nbar_albers', x=(149.25, 149.35), y=(-35.25, -35.35), group_by='solar_day') 
# 大部分跟之前用load()的方式差不多，只是在最後加了group_by='solar_day'就是根據太陽日的範圍群組化圖
len(nbar_by_solar_day.time) # 看一下圖是不是真的變少了

1
2


autumn2 = nbar_by_solar_day.green.loc['1991-3':'1991-5'] # 一樣取出綠色的波段作圖
autumn2.shape

1

autumn2.plot(col='time', col_wrap=3) # 一樣畫出圖，就變下面那樣

可以發現原來切掉的部分不見了！！！ 8. ：算ndvi 就用red和nir這兩個波段算出ndvi，大概就是可以反映出地面物是不是植物這樣 red就是紅光，nir就是近紅外光

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


two_bands = dc.load(product='ls5_nbar_albers', x=(149.07, 149.17), y=(-35.25, -35.35), time=('1991', '1992'), measurements=['red', 'nir'], group_by='solar_day')
# 跟前面使用load()的方式差不多，不過這次要用measurements，同時只load'red', 'nir'這兩個波段，一樣要記得用group_by
red = two_bands.red.where(two_bands.red != two_bands.red.attrs['nodata']) # 然後去除nodata
nir = two_bands.nir.where(two_bands.nir != two_bands.nir.attrs['nodata']) # 也是去除nodata
pq = dc.load(product='ls5_pq_albers', x=(149.07, 149.17), y=(-35.25, -35.35), time=('1991', '1992'), group_by='solar_day')
# 然後load另一個圖(是pq版本的)，等等用來做could free的mask
cloud_free = masking.make_mask(pq, cloud_acca='no_cloud', cloud_fmask='no_cloud', contiguous=True).pixelquality
# 用之前坐的那張圖做一個mask，一樣取出pixelquality的部分
ndvi = ((nir - red) / (nir + red)).where(cloud_free)
# 拿nir和red這兩張圖算一下ndvi，然後跟cloud_free疊加，去除雲的部分
ndvi.shape # 看一下資料量
ndvi.plot(col='time', col_wrap=5) # 印出來，就像下面那樣

其實還是有很多地方被切掉XDD，而且圖像的品質參差，接下來可以取出影像品質比較好的幾張，也就是含雲量較少的

1
2
3
4


mostly_cloud_free = cloud_free.sum(dim=('x','y')) > (0.75 * cloud_free.size / cloud_free.time.size)
# 簡單來說就是找含雲量前25%少的圖
mostly_good_ndvi = ndvi.where(mostly_cloud_free).dropna('time', how='all') # 然後拿去跟原來的疊，刪掉雲多的圖
mostly_good_ndvi.plot(col='time', col_wrap=5) # 印出來

就發現只剩清晰的圖了以下是我用先前桃園市的資料算的ndvi

1
2
3
4
5
6
7
8


red = combined_dataset.red.where(combined_dataset.red != combined_dataset.red.attrs['nodata']).where(combined_dataset.pixel_qa == 322)
nir = combined_dataset.nir.where(combined_dataset.nir != combined_dataset.nir.attrs['nodata']).where(combined_dataset.pixel_qa == 322)
# 跟上面差不多，取出red和nir兩個波段，然後用where取出pixel_qa為322的地方
ndvi = ((nir - red) / (nir + red)).where(ndvi <= 1).where(ndvi >= -1)
# 套個ndvi的公式
ndvi.shape
ndvi.plot(col='time', col_wrap=5)
# 印出來

接下來挑選一下雲含量比較少的圖

1
2
3
4
5
6
7
8
9


cloud_free = combined_dataset.pixel_qa.where(combined_dataset.pixel_qa != combined_dataset.pixel_qa.attrs['nodata']).where(combined_dataset.pixel_qa == 322) / 322
# 這邊就用先前pixel_qa的圖，抓值為322的部分，rescale為1，偽造成一個mask
#cloud_free.plot(col='time', col_wrap=3)
mostly_cloud_free = cloud_free.sum(dim=('latitude','longitude')) > (0.75 * cloud_free.size / cloud_free.time.size)
# 然後去算裡面不是雲的資料的比例，其實就是把它加總這樣
mostly_good_ndvi = ndvi.where(mostly_cloud_free).dropna('time', how='all')
# 然後疊一下圖
mostly_good_ndvi.plot(col='time', col_wrap=5)
# 印出來

第一張圖估計是系統弄錯惹，都是雲，但值是322，將就著看吧接下來ndvi還可以組一張中位數的圖，有點類似平均值的概念，可以看大範圍完整的樣子，不會受到圖片卻失的影響

1
2


mostly_good_ndvi.median(dim='time').plot()
# 就是取出每一個pixel的中位數，組成一張圖，這個函式還蠻厲害ㄉ

印出來就像這樣，顏色較深的地方大概就是沒有植物啦哈哈 p.s.為什麼不用平均數呢？因為平均數會受到nodata的影響然後也可以做一張std的圖，表示變化程度

1
2


mostly_good_ndvi.std(dim='time').plot()
# 概念跟剛剛median差不多

顏色較淺的地方就是變化量較大的地方，ndvi會隨季節變化，這個大家都知道ㄉ，所以一樣，亮的地方就是有植物的地方

然後也可以抓單一一點的ndvi變化，所以我隨便用google map選了一點引用sel函式，後面輸入參數，可以讀出該座標上每個時間的值

1

mostly_good_ndvi.sel(latitude=24.958132, longitude=121.126085, method='nearest').plot()

畫出來的圖，某種程度上還是會受到nodata的影響

下面這個是範例的奇妙用法，好像是抓出ndvi趨勢的感覺，詳細機制還要再研究

1
2


mostly_good_ndvi.isel(latitude=[200], longitude=[200]).plot()
# 那個兩百我不知道是要幹嘛的，我有試試看其他值，但跑出來的圖都怪怪的

這張圖就可以很明顯的看到ndvi的季節性變化了

接下來也是範例的奇妙用法，可以固定緯度，將不同時間的情況列出來

1
2


mostly_good_ndvi.isel(longitude=30).plot()
# 30的意義好像是代表longitude的第30個pixel

這樣一比對還真的可以看出明顯的季節變化

另外還可以抓出特定幾個點比較時間的影響

1
2


mostly_good_ndvi.isel_points(latitude=[0, 10, 20, 30, 40, 50], longitude=[20, 30, 40, 50, 60, 70]).plot(x='points', y='time')
# 同上那些數值也是以座標而言的第幾個點這樣

：多頻譜製圖(不是做成tif) 玩久了之後還是會想要做一張彩色的圖自爽一下以下的方法就可以惹

1
2
3
4
5


rgb = dc.load(product=product, lon=lon, lat=lat, time=date_range, measurements=['red', 'green', 'blue'], group_by='solar_day').to_array(dim='color').transpose('time', 'latitude', 'longitude', 'color')
# 前面坐過很多次了，就不贅述，紅綠藍波段一定要load近來，load了其他波段我不知道會怎樣，有空再試試
# 後面就是新建一個dim為新的color
zip(rgb.dims, rgb.shape)
# 有沒有做這個zip其實沒差

1
2
3
4
5
6
7
8


fake_saturation = 3000
# 這個是用來當作影像值得上限，超過就用3000取代
clipped_visible = rgb.where(rgb < fake_saturation).fillna(fake_saturation)
# 上面這邊就是這樣做，透過fillna()函式可以填入值
max_val = clipped_visible.max(['latitude', 'longitude'])
# 然後找最大的scale
scaled = (clipped_visible / max_val)
# 設定scaled

1
2
3


from matplotlib import pyplot as plt
plt.imshow(scaled.isel(time=19))
# 最後就印出來，記得要import該import的東西

選了一張被雲遮比較少ㄉ

：將xarray.Dataarray製成Dataset http://xarray.pydata.org/en/stable/generated/xarray.DataArray.to_dataset.html https://stackoverflow.com/questions/38826505/python-xarray-add-dataarray-to-dataset
：Dataarray or Dataset中的資料型別轉換 http://xarray.pydata.org/en/stable/generated/xarray.DataArray.astype.html
：不想要用.varibales的替代方案.get() https://github.com/pydata/xarray/issues/1801
：將matplotlib畫出的東西輸出成png https://stackoverflow.com/questions/9622163/save-plot-to-image-file-instead-of-displaying-it-using-matplotlib

Datacube 函式筆記-進階

WOFs

Datacube 函式筆記-其他

文件解壓縮在可以使用sever Shell的情況下，通常將文件打包(.zip)上傳之後再用Linux下的unzip解壓縮，不過新版的jupyter介面將Shell的功能關惹，所以只能用python內建的函式庫解壓縮，程式如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import os,zipfile
def un_zip(file_name):
 """unzip zip file"""
 zip_file = zipfile.ZipFile(file_name)
 if os.path.isdir(file_name + "_files"):
 pass
 else:
 os.mkdir(file_name + "_files")
 for names in zip_file.namelist():
 zip_file.extract(names,file_name + "_files/")
 zip_file.close()
un_zip("utils.zip")

使用方式：先用%指令切換到正確的工作目錄，然後啟動run上面的程式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import os, zipfile
#打包目录为zip文件（未压缩）
def make_zip(source_dir, output_filename):
 zipf = zipfile.ZipFile(output_filename, 'w')
 pre_len = len(os.path.dirname(source_dir))
 for parent, dirnames, filenames in os.walk(source_dir):
 for filename in filenames:
 print(filename)
 pathfile = os.path.join(parent, filename)
 arcname = pathfile[pre_len:].strip(os.path.sep) #相对路径
 zipf.write(pathfile, arcname)
 print()
 zipf.close()

make_zip(r"E:\python_sample\libs\test_tar_files\libs","test.zip")

Jupyter使用終端機指令雖然終止了shell的使用，但一樣可以在Jupyter使用Linux指令，不過一樣會受到權限限制 ex:

1
2
3


% ls
% cd ~
% pwd