| 哈囉讀者： 前陣子我開始在 Twitter 上看到許多含有「🟨🟩」emoji 的貼文，長得像這樣： Wordle 207 5/6 🟨🟨⬜️⬜️⬜️ ⬜️🟨🟨🟨⬜️ 🟨🟩⬜️🟩⬜️ ⬜️🟩⬜️🟩🟩 🟩🟩🟩🟩🟩 後來才知道原來那是拼字遊戲「Wordle」的玩家們在分享自己的成績。這個突然爆紅的遊戲設計看似簡單卻富有巧思，規則是你有六次機會憑空猜出由五個字母拼成的英文單字，灰色代表單字裡沒有這個字母，黃色代表字母對了但位置錯誤，綠色則是完全正確，每天只會有一題。 這個遊戲原本只是開發者 Josh Wardle 開發給喜歡拼字遊戲的伴侶玩的，他發現網友開始在社群網站上以彩色格子 emoji 在不爆雷的情況下分享遊戲分數，於是後來也加上這個設計。遊戲提供色盲模式，喜歡暗色系的網友也可以選暗黑主題，或是你也可以挑戰「困難模式」，快來跟我們分享成績吧！🟨🟩 Titan |
| [Podcast] 星箭廣播 EP141 | 神力搜尋框：解決「這個功能在哪裡？」的介面設計（同場加映好用 App 推薦） 我們在138 集聊到 macOS menu bar（功能列表）的設計跟一些相關工具，這集 Titan 跟 Liz 要跟大家聊聊他們很喜歡的一種設計「神力搜尋框」（power bar）。進入正題前，Liz 會先分享她前陣子趁著節慶特價訂閱的 Setapp。兩位主持人也會分享他們對這種「軟體吃到飽」模式的看法。 Power bar 這個被我們稱為「神力搜尋框」的設計，指的是在軟體中以快速鍵叫出搜尋框，輸入你要執行的功能名稱來執行。這個源自「command palette」（指令面板）可能開發者們都很熟悉，但不寫程式的 Titan 跟 Liz 為什麼也喜歡這種設計呢？它有什麼好處？節目後段，Liz 會跟大家分享她愛用的番茄鐘工具，而受不了 Dropbox 越來越「笨重」的 Titan 前陣子改用第三方 Dropbox app「Maestral」，順便聊聊前陣子 Dropbox 惹毛 Mac 使用者的事件。 |
| [英] 給前端工程師的命名指南 「電腦科學領域中兩個最令人頭痛的事，其中之一是處理快取失效（cache invalidation），另外一個則是命名（naming）。」90 年代知名軟體公司 Netscape 工程師 Phil Karlton 曾經留下這句經典名言。本文作者 Frank M. Taylor 分享了前端程式命名的簡易指南，分成 CSS class、CSS pre-processor 與 JavaScript 三大部分，羅列命名時應該考慮的問題，例如函式的作用是回傳值還是執行功能，就有不同的命名方法。 作者 Frank M. Taylor 說，「別讓團隊成員因為爛透了的命名詛咒自己，別忘記未來的自己也是團隊成員」如果明明邏輯沒問題，但老是在命名上卡關，或常常因為當初的隨便命名而讓後來的自己後悔莫及，這篇文章應該頗值得參考。 |
| [中] 董福興／數位出版中的 Accessibility 作者董福興多年深耕 W3C（全球資訊網協會），其中一項重要業務即是「無障礙」的推廣，同樣一種數位素材，在科技的輔助下，如果能夠規範化，就能以多元的形式呈現，讓使用者可以選用閱讀或聆聽模式吸收。 本文解釋了「無障礙」在網頁與數位出版實際執行層面上的差異，以及歐盟無障礙法的簡史，數位出版（EPUB 格式）的達成要件。文章最後也提到台灣制定無障礙，並且提出了「無障礙」並非做愛心、而是「完善基礎建設」的心態。推薦給對無障礙推廣感興趣的讀者。 |
| [英] 跟 Alan Kay 一起吃午餐是什麼樣的體驗？ 這是 2019 年的文章，作者 Steve Krouse 經營一個程式社群 Future of Coding，他意外得到一個跟 Alan Kay 共進午餐的機會。這位電腦界傳奇人物在餐桌上發表了許多有意思的觀點，（他們吃了五小時。）我們在此簡述幾句，詳細的內容請大家閱讀內文。 Alan Kay 認為大學教育雖有缺點，但仍比自學更好，前者恰好能強迫你學習自己不喜歡或是沒有意識到其重要性的知識。Alan Kay 覺得作者對維基百科、Scratch、Python 和 Linux 等非營利工具的欽佩是種「錯置的達爾文主義」，把「受歡迎」跟「好」畫上等號。Alan Kay 批評了幾件事：膚淺的程式推廣教育其實有害，各種「code for all」運動就像「吉他英雄」（之於學習彈奏吉他）；今日的電腦科學家活在一種流行文化裡，對領域的歷史並不瞭解；他很擔憂創投跟新創公司的「矽谷心態」，覺得人們不必「move fast and break things」，相反地，應該像建築師以百年為尺度建造大教堂那樣，慢慢地打造可以長久存續的美好事物。Alan Kay 還警告，年輕人過早立下目標可能會窄化視野，因為他們甚至不知道自己不知道什麼。 有趣的是，Alan Kay 看起來對作者一無所知，也沒說明為何他願意來吃這頓飯，作者試圖從飯局中的談話推敲出原因，也許這就是為什麼大神們會跟網友們見面吃飯？XD |
| [英] Uber 跟麥當勞有什麼共通點？它們都是 API 的集合體 許多熱門但功能大異其趣的 app，從 Google Maps 到 Excel，說穿了其實都是 API 的集合。本文作者 Justin Gage 解釋了 API 的基本原理、API 在前端、後端的「合作」上扮演什麼角色，儘管 API 大致的概念就是提供資料輸入、輸出的介面，但每個人口中的 API，意思可能還是不太相同。 除了僅供內部使用的 API、以及開放外部運用的 API，他們大多用來執行特定功能，但也有一種 API 是程式碼介面，如 JavaScript 中的 `array.sort() method` 也是一種 API。這篇文章進一步釐清 API 的類型與任務，也提供了簡單的手繪圖表，推薦給對 API 概念還有點模糊的讀者 👾 |
| [英] 打字速度快是一項高投報率的技能 Brian Lovin 在 GitHub 擔任 Staff Product Designer，他說不管是對設計師、工程師或 PM 來說，打字慢都會干擾思緒，變成進入心流的絆腳石，他認為打字速度是技術領域最高槓桿（high-leverage）的技能之一。 他把打字慢比喻為「背著一個打開的降落傘跑步」，雖然是在跑步沒錯，卻剝奪了跑步本身的樂趣——所以打字速度快會帶來「自己可以控制這台機器」這種神奇的感覺，有讀者可以共感嗎？（我打字超龜速，好想體會一下喔😂）他也說當打字跟得上思維的速度，就會啟動一個強大的正向循環。本文分享幾個加速打字和幫助你練習的訣竅，但在這之前，他建議要先認知到自己打字很慢。（作者有提到他是怎麼辨識的） |
| [中] Mark Liang／【職場日常】設計團隊的打造歷程 作者剛加入 KKBOX 時並沒有設計團隊或設計主管，所以他擔任設計主管這一年來花了不少時間做基礎建設，他回顧這個過程中的嘗試與階段性成果，包括文化塑造、品質與效率的確立與設計影響力的發揮。 初期先有週會以及每月一定要和成員 1:1，後期他則新增相對非正式的 Happy Designer’s Friday（不過為什麼他說這個機制也有缺陷呢？）。另外，年初導入 Figma 如何幫助團隊並建立產品的設計系統？怎麼貢獻產品開發的主導能力，進而激起團隊整體士氣？好奇打造一個設計團隊會經歷哪些事的讀者不妨參考這篇分享⚡️ |
| [中] 卡米哥／軟體開發者的培養 作者接觸程式的資歷約 20 年，本文從他的學習歷程聊聊，剛入門的軟體開發者到成為資深軟體開發者會經歷什麼、價值觀會有哪些變化，以及互相衝突的價值觀該如何取捨、排出優先程度？ 像他一開始認為最短程式碼的解決方案就是最佳解，不過接著就開始重視執行、修改、理解和測試程式碼的成本；他一開始以為只會用套件做東西的人很弱，但現在不這樣想了。過程中也逐漸養成「通靈」、維護任何技術等級的程式碼的能力等等，最後作者分享過往帶人經驗中，自己體會到培養新進軟體開發者的眉角和心態。 |
（文章代表圖：Photo by Melanie Deziel on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出