Hihi 讀者好，
earth.fm 這個網站邀請熱愛生態的錄音師、攝影師、生態學家等等，錄製全世界各地森林的聲音，讓身為地球子民的你我可以隨時漫遊到沁涼的森林裡，聽聽大自然。
使用者可以按照地圖挑選你想傾聽的地點，編輯聽了來自台灣陽明山夢幻湖的青蛙奏鳴曲，不由自主想加入這些動物一起合唱，推薦你一定要聽聽看！（歡迎與我們分享除了青蛙之外你還聽到了哪些動物 😉）
lily
[Podcast] 星箭廣播 EP170 | 創業不去矽谷了？台灣創業者前進德州奧斯汀（ft. 林宜儒）
《星箭廣播》又要連線到新的城市啦！這次的特別來賓是連續創業者 Lawrence ，他曾經在 100 集〈就是一個創業紀錄片的概念〉分享再度創業的故事。這次他從德州奧斯汀連線、以創業者角度跟我們聊聊在美國生活半年來的見聞。
Lawrence 會先分享一些剛搬去奧斯汀生活的經驗，接著從創業者的角度跟大家談一下為什麼要去美國。在節目第三段，Lawrence 會聊聊他對於「從台灣出發」的新創公司走向國際市場的想法，然後再從創業者經營公司的角度，淺談他這段時間對美國「創業基礎建設」——各種 SaaS 工具的感受，並且在下一集節目繼續這個話題。
你有看過七月時美國太空總署 NASA 發布的韋伯太空望遠鏡宇宙照片嗎？看到的當下是不是很感動？除了「哇，好美」的嘆詞之外，我們應該如何觀看外太空的照片？NASA 為這些照片的「替代文字（alt text）」作足準備，詳細的描寫了這些照片的特徵與意義，不只友善視障者，所以人都能運用各種輔助科技如閱讀、語音朗讀，更深刻地觀看這些照片，理解宇宙。來看看「內容親和力」可以發揮什麼作用吧！
「每日站立會議（stand-up meeting）」是敏捷開發團隊彼此保持同步、為下一步調整的必經環節，不過常常淪為不知為何而開的例行公事。本文作者 Lucas F. Costa 舉出五個站立會議正在失去作用的症狀，如果超過三個，那有可能就代表根本在浪費時間。
- 站立會議老是超過十五分鐘
- 談話主題圍繞做了哪些工作，而不是以目標為核心
- 老是有人缺席
- 大家都彷彿在跟主管報告，但不是很在乎同事
- 如果主管或 scrum master 不在，就乾脆不開了
作者在文中解釋為何站立會議會逐漸變得無用，也提出了讓站立會議重新產生意義的六個方式，首先大家都要停止漫無目地的閒聊，正視在讓拖動專案無法前進的障礙（blocker）等等。每個方法都有詳細的說明，有興趣的讀者可以參考。
[英] 低預算為技術部落格配圖，我用 DALL·E 2 的十個心得
選圖對技術型文章來說是大難題，尤其對又要寫文章又要想配圖的工程師來說又是多了一件麻煩事，你能想到談論 Docker、gRPC 等等專業工程文，應該配置哪些圖才吸引人嗎？Deephaven 這間數據軟體公司嘗試用 DALL·E 2 自動產出的圖像，為部落格中的 100 多篇文章重新配圖，45 美金的成果可說是讓他們感到頗為滿意。
他們在這篇文章中分享了十個使用心得，儘管說是「自動產出」，但餵給 AI 的文字材料（prompt）還是很仰賴人類的創意跟聯想力，而且是需要練習的。文中也提供了豐富的前後對照圖，讀者可以點進去看看 AI 產出的圖還是圖庫照片比較吸引你？圖庫網站還有存在的價值嗎？本文作者也提出了他的看法。
SQLite 被認為是全球最多人使用的資料庫產品，使用者平常不會注意到，但許多軟體裡總能找到「.db」結尾的 SQLite 資料庫檔案。假如 SQLite 有重大 bug，全球許多電子產品和嵌入式設備可能都會出問題。本文原是一系列 tweetstorm，簡述了 Dwayne Richard Hipp 開發這個傳奇資料庫的故事，作者 liyafu 將之整理成一篇短文。
一開始 Richard 是美國海軍的軟體外包商，由於當年使用的 informix 很不穩定，成為他在 2000 年開發 SQLite 的契機。那時還沒有維基百科，Google 才成立沒多久，Richard 為了驗證與測試，開始把 SQLite 發表到網路上，「接下來的故事和 Linux 誕生有點類似了」。文章提到，SQLite 由於採用者（許多是工業界的大公司）對穩定性要求很高，故開發上的測試也出名的嚴格，流程也受到航空業知名的軟體安全性指南《DO-178B》啟發。但其實最初 Richard 並沒有開發資料庫的經驗，事後來看也是遵循了所謂的第一性原理，他也去讀了 Donald Knuth 寫的《The Art of Computer Programming》⋯⋯
相信許多軟體使用者或開發者對於「README」文件並不陌生，本文聚焦於軟體開發時 README 的撰寫原則，主要是從 Node 開發的角度去談，強調 README 是給 module 開發者和使用者閱讀的，但也適用於其他程式語言生態系。閱讀此文會讓人意識到「把 README 寫好」背後代表的其實也是開發者對文件的態度。（本文也有被翻譯成簡體中文。）
如果沒有 README 文件，等於是要求其他開發者必須要直接閱讀程式碼。與其他許多類型的寫作要點類似，README 文件同樣要求清楚、簡短，可以採用「知識漏斗」的寫法：從寬大的部位開始往下寫到細節。文章也提醒，README 文件的壽命可能比很多網路服務都長，假如有圖片之類的東西就要特別注意，盡可能把使用者需要的東西都包進去。文章最後除了提供多篇優秀案例，也列了一份 README 寫作的檢查清單。
（文章代表圖：Photo by DeepMind on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出