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)