Hihi 讀者們好，
地球是圓的，但把地球攤平後，有些區域勢必會被扭曲。像是靠近北極的格陵蘭在地圖上，面積乍看跟非洲差不多，但實際上非洲比格陵蘭大 14 倍 🧐。
這個 MapFight.xyz 將全球國家、區域跟城市一個一個切割出來，展示真實面積，在瀏覽模式下可以看到許多奇妙的形狀。編輯覺得最有趣的功能是可以用選單上的「Compare」，將兩個區域疊加起來比較。（編輯發現 Minecraft 居然也在列表裡面，可以比看看台灣跟 Minecraft 誰大誰小喔 😂）
lily
[英] 技術債不只是技術債
本文探討「技術債」的起源，並且呼籲「技術債」概念應該擴及整家企業，而不只是當成技術部門的問題。作者是 Workhuman 的架構長 Mark Greville。在金融界裡，債務具備三個屬性「本金、利率、償還期限」，但技術被比擬成債務時，這三個重要特色都缺失了：本金跟欠款都沒有約定，也缺乏利率觀念，因為通常每個專案都被當作獨立事件交付，彼此並不互相影響。不若債務，「技術債」很難被精確衡量。
作者認為，技術債若只把它當作技術問題過於狹隘，技術債攸關整間公司的運作，技術債台高築時，甚至可能影響整個社會（編按：想想疊床架屋的公部門網站，也許就能理解作者的意思）。技術成為債務時，除了字面上的比喻之外，就跟企業考察財務、現金流跟銷售管道一樣，以更嚴謹的態度檢視，向社會大眾交代技術債累積的後果。
[英] 800 種顏色的油墨、一部 10 萬公斤的印刷機⋯一本書是怎麼做出來的？（圖多）
不管你看的是紙本書還是電子書，可曾好奇一本擺在貨架上的小說是怎樣在印刷廠裡被製造出來的嗎？《紐約時報》最近製作了一篇圖文並茂的報導，帶大家跟著一本新出版、首刷 15 萬本、626 頁的小說《Moon Witch, Spider King》，看看一家 24 小時營運的現代印刷廠每週怎麼印出數以萬計的書籍。
第一個印製的是書封，通常會使用黑色、青色、洋紅和黃色油墨，但要印製報導裡這本書的封面還要加上 Day-Glo 綠和一種特別的藍色油墨（印刷廠裡大約有 800 種不同顏色的油墨），印好之後還要上膜。機器通常一次吃進 8,000 張紙，另一個需要控制的是空氣，你可以從照片看到一些空氣和紙張溫度的細節（顯然有些按鈕最好別亂動），印刷區特別需要保持溫度和濕度，風扇還會吹著水霧。印刷時通常可以一次印 32 頁，在印刷機末端被切割、折疊，整部印刷機重達 20 萬磅，你可以停六輛半掛式卡車在裡面（你也需要六輛卡車才載得動這台機器）。報導裡有更多細節，而且照片都很好看。編輯的疑問只有一個：為什麼那些白色的書頁在一個四處是油墨、污漬的地方跑來跑去，卻都不會髒掉呢？
[中] yuwen-c／新手上路，真正進入 developer 的世界
剛轉職成工程師的作者 yuwen-c ，比較了獨自練習專案跟真正進入團隊、與同事協作開發的不同之處，裡面提出連專業用語都還一頭霧水的超級菜鳥們，更快進入狀況、跟上節奏的方法。例如，開發環境分成測試、Git flow 的觀念，或者細如「打」API、「上」版、「吃」值，這些剛開始可能摸不著頭緒的常用語，都可以事先練習起來。
值得一提的還有，工程師不是只負責寫程式，也必須了解公司的業務運作，她會藉著跟朋友聊天的機會，將公司介紹給朋友，透過一次次向不同人解說，讓自己更加理解公司提供的服務跟價值是什麼，對於領域知識的掌握度更高。
[Podcast] 星箭廣播 EP148 | 原本要推薦五檔「不科技」Podcast
我們在《星箭廣播》146 集跟大家推薦了六檔科技 podcast，這次要跟大家聊聊「不科技」主題的節目——至少原本的計畫是這樣，但我們把想聊的節目列出來後，發現他們最多只能叫做「不那麼科技」podcast⋯⋯
Julie 要跟大家介紹《遲早更新》、《Nice Try!》與《Build for Tomorrow》等三檔節目；Liz 喜歡的是老牌節目《99% Invisible》；Titan 想推薦的是《滅茶苦茶》。由於我們想要介紹的節目太多了，一集根本講不完，因此我們會分成兩集，假如你還想多聽一些「不那麼科技」的 podcast，記得回來聽續集哦。
[英] 一個 400 多萬訂閱的 YouTube 頻道，怎麼改變一個孟加拉的偏遠村落？
為了上傳一支影片，要跋山涉水 6～12 小時到城裡的網咖才能完成😲但這個超過 400 萬訂閱的 YouTube 頻道 AroundMeBD 仍一週雙更，支撐著一個孟加拉的村子，包括雇用 50 名村民當員工、建造村裡的公設、安置無家可歸的村民和負擔村民的醫療費用。
主打「農村大型烹飪現場」的 AroundMeBD 在 2016 年成立，當時 YouTube 在孟加拉還不流行，創辦人沒拍過影片，還是靠著 YouTube 自學，而且也不是一開始就確立現在的頻道風格。內文提到頻道多數的營運成本都花在進口食材，但目前仍為了維持「真實」而不接業配。
AroundMeBD 的影片最後通常是上百人一起共享這頓料理，而這和南韓的「吃播」又有著極為不同的意義。那這種農村烹飪實境節目為何對觀眾有吸引力？「YouTube 村」在南亞各國也成為趨勢的情況下，頻道的最終理想又是什麼？編輯覺得意外的是，AroundMeBD 最大宗的觀眾來源並不是歐美或孟加拉當地，我就不爆雷啦🤫
[中] Hsuan／A/B testing 的奧妙，我是如何運用在設計過程之中？
作者在電商 SaaS 新創擔任產品設計師，以前認為 A/B testing 是數據分析師的工作，不過這幾年和 A/B testing「糾纏」的經驗讓她的想法有所改變。她以過去的實際專案分享如何把 A/B testing 運用在設計過程，當中藏有許多指標細節要注意。關於實驗沒有顯著結果該怎麼辦？ A/B testing 的時機點和目的又有哪些考量？文中也有詳細的說明。
作者提到所在公司 A/B testing 發展成熟，所以大家進行 A/B testing 都會有完整設置實驗的文件紀錄，方便其他團隊未來找尋靈感和佐證想法用。但當產品處處都在 A/B testing 也不免有些壞處，包括無人知曉產品真實的樣貌、實驗的挫折感和資源損耗等等，那身為設計師，要用什麼樣的心態面對 A/B testing 呢？
[英] 做到這五點，你根本永遠不用「改密碼」
「您已超過三個月未更改密碼，建議您立即更改！」相信有使用銀行等網路服務的讀者，對三不五時要求自己改密碼的提示訊息，應該都十分熟悉。到底該改密碼還是不改呢？改密碼就能確保安全嗎？在科技圈打滾好幾十年的 Glenn Fleishman，最近收到 T-Mobile 要求更改密碼的電子郵件，終於再也無法忍受，寫了一篇文章，破解「定期更改密碼」的三個迷思，並且提出幾項原則，如果做到，你真的可以不用、甚至不該隨便改動密碼。
總是被更改密碼、忘記密碼煩得不勝其擾的讀者，不妨試試作者文末的密碼管理建議事項，從此擺脫改密碼的迷障吧！
[中] Samuel／如何建立好的產品團隊
Samuel 在 Hahow 擔任 Product Owner，也負責團隊建置，經歷從五人到 30 人的成長的過程中有了一些體悟，包括他身為工程師時，曾覺得「產品願景」是件不切實際的事或缺少與公司感同身受的期待，但當自己角色轉換才突然意識到原來不是這樣子的。
作者從過去的協作經驗分享幾個塑造優秀團隊的技巧，像是在和團隊同步訊息時，如何將「資訊的狀態」梳理清楚；在內部整理領域和趨勢的分享時，不是只複製連結貼到 Slack 就結束等等。最後他也列出在 1 on 1 會和夥伴聊到的問題合集，涵蓋團隊文化與工作流程、個人工作學習目標、產品回饋與討論等三個面向。文中有豐富的實際案例可以參考，幫助你在團隊打造和溝通上更有方向🌟
（文章代表圖：Photo by Philipp Katzenberger on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出