嗨嗨各位讀者，
這幾天編輯迷上「mmm」這個網頁組合工具——與其說是工具，不如說是玩具——因為它並不是要你設計一個正經八百的 landing page 或部落格，而是要你當成剪貼簿，拼貼你創造的或你覺得有趣的內容，創造獨一無二的頁面。
mmm 的開發者 XH 說，我們其實一直在創造內容，但少了一個空間來收納、展示它們。 「mmm」就提供了一個超自由、超簡單，可以說是更無腦的方式，讓你自由拖拉、拼貼、組合作品，無論是 Instagram 圖片、YouTube 影片、GIF 跟文字，再適時畫出幾個幾何圖形點綴，加上自己的社群連結，完成後就能生出一個網址分享出去。「messy」（弄亂一切）是它的精神，大家放膽玩起來吧 🤾🏼♂️
Liz
| [英] 大神級 Google 工程師是怎麼工作的？ 這是一篇 2018 年的文章，作者 James Somers 也是一位程式設計師，他跟在人工智慧領域大神級人物 Jeff Dean 與他的搭檔 Sanjay Ghemawat 身邊，記錄兩人平時是怎麼工作的。文章裡面詳細描述了一次他們 pair programming（結對開發）的工作情形。兩人的個性和寫程式的風格剛好有點相反：Jeff Dean 個性外向，Sanjay 內向；前者程式寫得很快，程式比較難理解，後者的程式則「比較社交」。 本文開頭的故事非常吸引人，在講 Google 2000 年時遇到的一個大問題：他們的網路爬蟲故障了，使用者的搜尋結果很多都是好幾個月前的。當時 Larry page 跟 Sergey Brin 正在跟 Yahoo 協商搜尋引擎的授權，如果失敗可能會讓成立不到兩年的 Google 損失一大筆收入。最後就是 Jeff Dean 與 Sanjay Ghemawat 找出問題所在。他們兩人在 Google 共事時間超過 20 年，都是 Level 11 的 Google Senior Fellows。不過到了 2018 年，Jeff Dean 大部分的時間都花在領導人工智慧相關的專案，跟 Sanjay Ghemawat 每週只會一起寫程式一次，後者的工作類型則是我們在 280 期介紹過的「個人貢獻者」（individual contributor）。 |
| [英] 打字很簡單，但要把文字正確地顯示在螢幕上很艱難 文字要正確的呈現（渲染，render）在電子螢幕上，有多困難？曾在 Mozilla Firefox 工作的 Alexis Beingessner 說，真的、超級難！ 在 2019 年發表的「文字渲染討厭你（Text Rendering Hates You）」這篇文章中，Alexis Beingessner 細數文字被放到螢幕前的複雜性。每個文字都像要參加時裝周的模特兒、或被陳列在博物館的展品一樣，必須經過「造型」、「布局」、「塑形」、「網格化」，最後才是「組成」，裡面還有許多細節，以 emoji 來說好了，emoji 通常是由一連串的「連字」（ligature）組合而成，有些舊字型無法辨識這些連字，你想要呈現的是「🤦🏿♀️」，結果卻是「🤦 🏿 ♀」。 再舉一個例子，尼泊爾語言中的「連字」是很幽微的存在，為它們上色、添加樣式的時候，幾乎所有瀏覽器無法正常顯示。作者以「पन्ह पन्ह त्र र्च कृकृ ड्ड न्हृे إلا بسم الله」這段文字為例，Firefox 的表現是表現最好的，但也只是把一段文字全部平均起來上色，而非在正確地在獨立的字符上色，Chrome 雖然可以顯示正常字段，但有些顏色消失了，Safari 則是全面崩壞，多出不該存在的符號。 這是一篇讓編輯大開眼界的文章，原來將遍佈在網頁上的文字正確顯示出來，居然需要如此大費周章！有興趣的讀者不妨也花時間了解 text rendering 的奧秘，以後打字、使用 emoji、裝飾字體會更心懷感恩。 |
| [中] Gene Hong／AMP 過期了嗎？還可以吃嗎？ 讀者有沒有注意過每次在 Google 上搜尋，有些標題或圖卡前面會顯示一個閃電符號，這個符號代表該網頁是由 AMP 格式製作，用以加快讀取網頁速度，有時候排名最前面的都是 AMP 網頁，尤以新聞內容最常見。不過，今年四月 Google 宣布，將把 AMP 格式將從網頁評分標準中移除，有些媒體標題寫道「Google 殺死 AMP」。這代表什麼意思？又，現在網頁到底該不該繼續保留 AMP 版本呢？ SEO 專家 Gene Hong 解釋，Google 並未真的殺死 AMP，只是把 AMP 從網頁排名因子（Ranking factor）標準拿掉，改採 Core Web Vitals（CrUX，網站核心體驗指標）為基準，由裡面的綜合指標來衡量網頁使用體驗，而把 AMP 剔除。不過這不代表你的網站就不需要 AMP，除非網站的 PageSpeed 拿高分，而且 CrUX 也通通拿到健康的綠色評分，有效網址達到 90% 以上，那麼的確不用考慮 AMP。不過如果你的網站體質很差，那就要慎重評估，是要精進上述各項指標，還是使用 AMP 促進網頁體驗提升了。 |
| [英] 一個新創公司的前 18 個月，要做哪些事？ 前陣子 Mighty 這個預計每月收費 30 美元的瀏覽器引起討論，其創辦人兼 CEO Suhail Doshi 其實 20 歲就創業，打造知名數據分析平台 Mixpanel。本文是他分享 2019 年開始創辦 Mighty 的領悟，特別是在剛起步的這一年半內，值得創業者們參考💡 這 21 條經驗包括：跟「問題」結婚而非「技術」；公司的第一個目標可以很小，像 Mighty 就訂在收穫 10 個開心的使用者；住在很無聊的區域、減少會議、沒有要籌資就不要和投資人見面，才能確保自己有最多的深度工作時間；以及最重要的一點，和使用者對話。他也提醒和他一樣是第二次創業的人，要忍住「把一切都搞定」的那股衝動。 |
| [Podcast] 星箭廣播 EP110 | 在網路時代重建一座亞歷山大圖書館 你有沒有過一種經驗：以前逛過某個網頁（還存成書籤保存），但需要時回去找卻發現網頁不見了。此時通常可以求助 Internet Archive，看看能否把網頁「撈」回來，本集《星箭廣播》要聊聊這個企圖像西元前 300 年亞歷山大圖書館那樣保存全人類知識的計劃。 Liz 跟 Titan 除了聊到 Internet Archive 的故事，還會帶大家看看他們旗下各種有趣的計畫，想知道 2001 年 Apple 發表第一部 iPod 時網站長什麼樣子嗎？試試「Wayback Machine」；想回味以前的軟體或電視節目也沒問題，然還有他們的圖書館計畫：掃描全世界的書讓大家免費借閱。（Google 只做了一半。）最後，Liz 跟 Titan 除了分享他們使用 Internet Archive 的經驗之外，也會聊聊世界上其他有意思的保存計畫，其中一個就在台南市善化區哦。 |
| [中] Anne Hsiao／在日本當產品經理的經驗分享：網路新創產業觀察、PM 工作文化差異 經常在網路上分享 PM 工作心得與方法論的 Anne Hsiao，這幾年到了日本工作。最近她發表了一篇文章，先分析了日本整體的網路新創產業環境，再回到她所任職的公司文化，以及在公司中 PM 的角色與團隊成員的合作情況，內容豐富長達 6000 字，可以說是一本迷你教戰手冊了。 編輯覺得本文最有趣的是，日本內需市場大，小眾題目不難存活，也可以容納大量的新創團隊。但日本人對於「快速驗證」的接受度不高，信賴感難以建立，端出一個雖然可用但陽春的新東西給他們，可能只會碰壁連連。因此美國乃至於台灣流行的 MVP 概念在日本窒礙難行。想當然爾，日本也不太流行敏捷式開發，而遵循先制定好完整文件規格才落實的法則。 文中還有 Anne Hsiao 提供身為「不會說日文」的 PM，該怎麼在團隊裡生存的心法，以及團隊合作的狀況。對日本 PM 工作有興趣的讀者務必參考～ |
| [中] jameshwc／[DevOps] 初階 DevOps/SRE 工程師是如何煉成的 作者在新加坡的 ByteDance 擔任 SRE（Site Reliability Engineer），在本文介紹初階 SRE 的技能樹，像是程式語言方面，他就建議至少 Python、Go、JavaScript 三者中各精通和熟練一種。另外也談到架站、CI/CD、容器（Containers）、接觸開源、儘量接觸多人開發或大型專案等等。 或許讀者對 DevOps/SRE 的印象是較吃重經驗，他也分享 ByteDance 的面試官認為一個 SRE 應該具備的特質，對這個領域有興趣的讀者也能藉此了解如何入門囉！ |
| [中] Lynn／這個設計很美所以請幫我加上去：最嚴重的網站設計迷思之一 想設計一個網站或 app 該從哪邊著手呢？作者觀察，如果拿到一個需求規格後就按個人偏好來做設計，或老闆一開始就指定特定的顏色或功能，原因是喜歡、感覺不錯，但最後做出來的「藝術品」沒有實際營運的目標與成效，也無法在後續衡量並檢討原因。 尤其是當網站越來越龐大且複雜，這時如果要擴編新的頁面，怎麼維持視覺和功能目標的一致也是挑戰。所以本文點出這個很常見的設計迷思，幫助凝聚團隊共識，確切判斷即將上線的功能或元件是否符合使用者需求，討論才不會失焦或是只憑老闆感覺啦。 |
（文章代表圖：Photo by Guus Baggermans on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出