Hihi 各位讀者好，
為了要證明自己不是機器人，你除了要會拼拼圖、辨認鬼畫符，還要在九宮格圖片裡面找出哪些有橋、斑馬線或紅綠燈，（我覺得是在考驗眼力👀） 開發者 Miquel Camps Orteza 也覺得這很煩，所以做出 DOOM Captcha——你只要開槍殺死四個怪物就好，驗證過程像玩遊戲一樣有趣多了吧！
他說自己花一天做出 DOOM Captcha，也在 Product Hunt 拿下當天第一，看得出來大家怨念都很深😂（如果有更多有趣的驗證方式就好了🙏）
Julie
| [Podcast] 星箭廣播 EP116 | 「小」是他們故意的：傳奇創投 Benchmark 《星箭廣播》再度邀請程希瑾 Cjin 來分享一本 20 年前的書《eBoys》，此書以貼身觀察的方式記錄當時仍不被大眾所認識的創投工作，我們也會跟大家聊聊書中主角、傳奇創投公司 Benchmark 獨特的模式，以及當年投資 eBay 一戰成名的故事。這家 1995 年成立至今的創投，從早年的 Juniper Networks、Red Hat 和 OpenTable，到後來的 Twitter、Dropbox、Instagram、Uber 和 Snap 等，都在在影響著網路世界的發展與我們的生活。 近年來各大創投不斷擴張，a16z 甚至做起了科技媒體，但 Benchmark 仍然堅持在資金與合夥人數量維持在比較小的規模，他們與 a16z 不僅理念南轅北轍，彼此之間還有一點點「恩怨」呢。除了當年 eBay 的成功案例，Cjin 與 Titan 還會聊到另一個在書中做為對照的經典失敗案例 Webvan，以及 Benchmark 模式遭受到的最新挑戰。 [英] 程式語言的成長與衰退：JetBrains 開發者生態系調查 捷克軟體公司 JetBrains 發表了 2021 年開發者生態系報告，這份橫跨 18 個國家、3 萬名開發者（多數為後端）的調查有著豐富的圖表。其中一張線圖描繪了 2017-2021 年不同程式語言的使用度變化，PHP、TypeScript 呈現正向變化，其他或多或少都下降了。 另外，他們也統計了五種成長最快的語言：Python、TypeScript、Kotlin、SQL 與 Go，最多人正在學習的語言則是 JavaScript、Python、TypeScript、Java 與Go。與你的認知有沒有差異呢？ JetBrains 還順便調查了開發者生活樣貌，例如大家怎麼付錢？從哪個管道獲取娛樂資訊或新聞？不開發的時候都在做什麼（這題很好猜吧）？有興趣的開發者也可以一起參考。 從夢想打造獨角獸到一人公司，Gumroad 創辦人 Sahil Lavingia 不想當連續創業家 14 歲就開始開發 app、17 歲輟學加入 Pinterest、19 歲離職創業、婉拒 Brian Armstrong 的合作邀約，Sahil Lavingia 堪稱人生勝利組，連創業都看似一帆風順——創立的創作者電商平台 Gumroad 在 Stripe 還沒上線服務、Patreon 也還沒誕生的 10 年前繳出亮眼成績單。 Sahil Lavingia 當時意氣風發，最後卻沒當成所謂的創業模範生，更離開矽谷只剩下自己一個人經營公司。10 年過去，他意識到建立一家價值 10 億美元的公司是多可怕的目標，有趣的是 Gumroad 也在他放下對獨角獸信仰崇拜的此刻，迎來有史以來最好的營收表現⋯⋯ [Podcast] Sam Altman 談 AI 政治經濟學 強大的 AI 將會重新分配財富與權力，非營利人工智慧研究組織 OpenAI 共同創辦人兼執行長 Sam Altman 認為，因應之道並不是「無條件基本收入」（UBI），而是藉由稅收——對企業以股權的方式徵稅、對私人土地以現金的方式徵稅——所產生的「股權基金」（Equity Fund），每年定期分配給全國的成年人自由使用。Sam Altman 此法比 UBI「定期定額的現金」更有價值，只要這個國家越來越好，全民都可以得到更多。但主持人 Ezra Klein 提出一個關鍵問題：強大的 AI 將使資本的擁有者更有權力，當我們提出要對這些人採用更激進的方式去徵稅，難道不會遭遇抵抗嗎？因此他指出，在對資源做更好的分配前，必須先更加平均地分配權力。 本集 podcast 談到很多議題，例如世界應該要有兆元富翁嗎？兩個人的看法剛好相反。Ezra Klein 認為 Sam Altman 很關注科技與社會的政策面，對於權力面似乎比較沒那麼關心。兩人也針對先前姜峯楠提出「人類在發明 AGI（通用人工智慧）之前必會像虐待動物一樣對待機器」做了一番討論。跟其他的來賓一樣，Sam Altman 也在節目最後推薦幾篇關於 AI 的短篇故事——不是書，他認為沒什麼關於 AI 的好書。（而且聽眾去閱讀短文的機率應該比較高。） [英] 怎麼打造更好的註冊和登入體驗？這裡有 15 個錦囊 大家應該體驗過沒那麼流暢的註冊或登入流程，像是如果得重打密碼卻搞得原本輸入好的 email 也要重來，發現按錯註冊和登入的時候切換得很不順⋯⋯UX/UI 設計師 Erik Kennedy 從他教學過程中，觀察上百個新手設計師最常踩到的雷，總結出在設計流程上的 15 個重點，並搭配示意圖說明。 包括不要等使用者都填完全部欄位才顯示有填錯的部分；「繼續」（Continue）或「送出」（Submit）的按鈕是在考驗使用者的耐心；“Sign in” 和 “Sign up” 用字太像會讓使用者還要去想該點哪個⋯⋯你對什麼最有共鳴呢？或是有作者沒提到的也歡迎跟我們分享👋 [英] 菜鳥工程師如何進行 code review？ 身為剛加入團隊的菜鳥工程師，「審核」同事的程式碼時（code review）會不會冒出「我憑什麼檢查資深工程師的程式碼」的念頭？Pinterest 軟體工程師 Emma Catlin 描述了這種心境，但她已克服這種心魔，也透過 code review 飛躍式的成長，並對團隊帶來貢獻。 進行 code review 的好處之一是建立正向的回饋循環，當自己對程式碼做出回饋，下次接收回饋時自然也更坦率、更願意聆聽別人的想法。另外她也提到 code review 多提問、觀察團隊在意的審查重點是什麼，也有助於自己寫出更優異的程式碼。 [中] Anne Hsiao／技術團隊有 Pair Programming，那產品經理有 Pair Documenting 嗎？ 開發者常用 Pair Programming（結對程式）來加強程式碼品質與提升開發紀律。擔任產品經理的 Anne Hsiao 最近將這種概念應用到「寫文件」這項任務上，與主管事先擬好文件大綱，並在一個小時內共同協作完成產品開發文件。 Anne Hsiao 詳細描述了 Pair Documenting 的執行過程與技巧，像是有可能是一人寫作、另外一位負責觀察給意見，或是兩者同時產出，一人專注文字、一人繪製流程圖、拉數據。她也認為，這種方式有諸多優點，像是高度專注、速戰速決、立刻取得回饋，也有效提升了文件品質。推薦給有夥伴可以一起嘗試的 PM 讀者。 🎧 軟體工程師團隊怎麼工作？Pair Programming 結對開發實戰經驗談（ft. 資深工程師小朱） [中] 技術：為什麼中文打字會裂掉？ 想要打「筆記」這兩個字卻只會出現「ㄅㄧˇㄐㄧˋ」，怎麼樣都組不成中文字，超擾人！（被 Facebook Messenger 惹毛過的大批使用者之一就在這🙋） 而這個問題是來自編輯器有沒有好好處理「組字事件」（Composition Event）。 HackMD 的 enen 先帶讀者認識「鍵盤事件」（Key Event），並解釋中、日、韓文等等需組字的語言情境，要額外從候選字庫裡選出對的選項，也就是「組字事件」的重要性。他接著談到這些會如何影響協作軟體，包括演算法、想優先帶給使用者什麼樣的體驗都可能干擾組字事件。看完這篇更理解從鍵盤、組字、多使用者到即時輸入文件要能夠流暢進行，或許是比我們想像更複雜的。（難怪編輯用 Google Docs 也很常遇到裂字⋯⋯） 💡 好奇 HackMD 的讀者，歡迎參考這篇有幸被團隊稱為「最動人的解答」：為工程師文件而生的協作平台：HackMD 開發故事 |
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
（文章代表圖：Photo by kaori kubota on Unsplash）