Latest

前陣子上了小賴老師《給網站工程師的網路課》，沒多久又上了《Docker 實戰指南》，此篇即為筆者參加 2025 年 5/10、5/17 小賴老師在五倍學院的課程心得，也感謝同事 Joel、Chenyuan 響應我的團報課程邀約。 身為一個前端工程師……不，應該說是 Web 工程師，即便沒實際用過 Docker，肯定也聽過它的大名，知道它是用來解決什麼問題的。但工作中會不會真的用到，又是另一回事了。 而且退一步說，即便公司有用到，在部門專業分工的情況下，Dockerfile 或 yml 檔案也不一定是由 Frontend Team 的人來修改。 一次正式站爆炸的反思 某次公司網站在工程師們沒做任何操作的情況下，正式站 Client 突然爆炸，事後的排查其實是 GTM 被外部門注入了有問題的行銷程式碼，細節不多說了。 而在排查的當下，其中一個方向是基礎環境建設的問題，例如

基於 TCP 的 HLS 為何還會延遲或卡頓？ 雖然 HLS（HTTP Live Streaming）是基於 TCP 傳輸協定，能保證資料不丟失且順序正確，但它天生具有「緩慢啟動、嚴格順序交付」的特性，會導致：啟播延遲（Startup Delay）、再傳延遲（Retransmission Delay）、突發性網路問題容易影響流暢性。 RTT（Round Trip Time）過高 RTT 是封包從客戶端傳送到伺服器再回來的總耗時。 * RTT 高 → Initial connection 慢：尤其 HTTPS handshake 或 CDN 的 chunk 請求階段會很明顯。 * 多個小請求的串流格式（如 HLS）會被放大影響：

這篇文並不是要批評現職，並不是要此地無銀三百，而是這篇文是早上搭公車上班時想到的，然後我就很興奮(?)的分享這些議題給同事與 LINE 技術社群的朋友，在經過一些多方對話後，我再把一些討論後的內容汲取出來並加上自己心得。 關於團隊文化的議題，有時候我們會聽到一句話： 部門文化不能強迫建立，尤其是技術分享，強迫是沒意義的。 這句話乍看是沒錯的，但真的完全正確嗎？其實文化建立需要一點微小的強制力推動(或者說提醒)，就舉個我們部門的例子來看： 例子：開會中在白板上畫圖溝通 在平常工作會議中，常看到某些 Sr 工程師或主管，會議討論主動用白板畫圖，不管是流程圖、時序圖還是概念草圖，這樣的行為幾乎已經變成習慣。 觀察一下就會發現，除了 Sr 或主管以外，真正主動在開會中用白板的人還是極少數。 如果 Jr 工程師不懂流程、UI 或架構就算了，大部分狀況下 mid 工程師們其實知道，只是可能害羞的關係（?)，大家習慣口說而不敢拿筆用視覺化方式溝通，反而劈哩啪啦一直講，這過程很容易產生溝通誤會。 多數情況下要由 Sr 或主管對同事開口說：「要不要你來畫一下？

什麼是 EME？ EME 是簡稱，全名 Encrypted Media Extensions （加密媒體擴充 API），它現在是瀏覽器標準內建的 Web API，讓瀏覽器可以播放受 DRM 保護的影片。使用它的核心目標是讓 HTML5 <video> 支援加密內容，並確保只有合法授權的使用者能夠解碼和播放影片。 要注意的是： EME 不負責解密影片，它只是 API，提供 Interface 與電腦底層 DRM 系統溝通的機制。 為什麼需要 EME？ 早年大多數的線上影音網站使用 Flash 或 Silverlight 來播放影片（這些技術也有實作 DRM 的保護機制，例如 Flash 的 Flash Media Rights Management、

最近看到一篇有很趣的文章：AI is Stifling Tech Adoption 這篇文在探討工程師的「技術選型」被 AI 給影響了！ AI 雖然增加了開發者效率，但也在重朔技術的發展(和開發者的技術選型)，原因是 AI 訓練數據的時間性問題，還有其技術偏好導致。 作者認為生成式 AI 的訓練數據都不是當下即時資料，而是基於過往資料訓練，所以當某個主流套件更新到新版，AI 回應往往無法回答最新版本套件的資訊，這可能讓 Jr 開發者較難採用新技術，而是習慣性地使用 AI 熟知的版本。 AI is Stifling Tech AdoptionAI coding assistants are React evangelists.Vale.RocksDeclan Chidlow 並且 AI 有預設「技術偏好」，像是

本文並非批評任何人，而是嘗試從組織運作與職位差異的角度出發：在拿到 Senior Title 後我對於辦公室政治與決策議題更有興趣了，而這篇文就是紀錄我目前觀察到中層技術主管們在企業內如何建立影響力。 畢竟每個職級、每個部門都有其任務與立場，我認為這都沒有對錯，只是台灣中大型企業日常運作的一部分。 首先定義什麼是「三明治」，這裡的三明治是泛指在台灣公司體制「 CXX」某某長之下、基層員工之上的所有夾在其中具管理職的員工。 中層主管如何在企業內建立存在感與影響力？ 對於身處公司「三明治」的中層技術主管而言，上有高層期待績效與可見成果，下有工程團隊承擔技術落地與維運負擔，要在這樣的夾縫中求生存，最常見的做法之一，就是主動解決跨部門的「痛點」問題。 這類專案看起來像是流程改善、內部工具開發，甚至某種戰略功能的 MVP，其實本質是向平行部門經營關係、向高層展示價值的一種方式：透過這些專案提升部門能見度，也讓中層主管在公司中建立了影響力。 然而這些更高層主管「看得見」的成果，往往會帶來「看不見」的技術債。中層主管們或許心知肚明，但在績效與人事評估的現實考量下，這些隱藏成本多半被選擇性