科技創業週報 #332:一個恍神失誤,直接把 5.4 萬 GitHub 個打星變不見

| |

Hi hi 讀者好,

你有在看北美的職業體育賽事嗎?經過刺激的附加賽之後,本季 NBA 季後賽已經正式開打,前陣子剛好發現一個純文字體育網站「Plain Text Sports」,令人想起以前高中時期利用下課或午休時間去圖書館看 NBA 官網文字轉播的日子。

Plain Text Sports 有 NBA、MLB、NHL、NWSL 與 MLS 等五種聯盟的賽事資訊,以 NBA 來說,除了基本的球隊戰績、各節賽事比分與球員統計數據之外,還有即時 Play-by-Play 文字轉播,以及顯示雙方比數態勢的「Game Flow」圖形。Plain Text Sports 在手機上也能用,由於是文字介面,速度很快,還有暗黑模式。假如你因為種種原因不能看影片直播,也許可以試試看。我個人希望它以後可以支援歐洲足球賽事 XD

Titan


.

[英] Reddit 前 CEO 奉勸馬斯克:別來淌社群混水,你會精神衰弱的

上週最熱門的科技話題莫過於 Elon Musk 出價收購 Twitter 的消息了。在 2012 – 2014 期間,擔任 Reddit CEO 的(Yishan Wong)黃易山,以過來人的身分奉勸 Elon Musk,以他的角色專注製造火箭、開發汽車對人類的助益無比超凡,但若涉入管理社群平台,每日排山倒海的洶湧惡意,將使他「身心受創」,而且每解決了一個問題,就會產生三個新的問題。

作者描繪了今日社群平台的現象,人們爭相表露最邪惡的姿態,所有政治派別都能控制平台偏袒自己的對立方,而且都可以取出一籮筐文字、影像擷圖佐證。雙方都是對的,雙方都未說謊,而平台方其實對政治糾葛並沒興趣,他們在乎的是錢。如此多方的擠壓牽制,造成社群平台無以為繼的困境,要管理它可得先培養「非人」意志。Yishan Wong 對社群平台的解析頗為透徹,相當值得一讀。

[英] 效率面試工程師:請面試者「讀程式碼」,五分鐘問出技術深度

要怎麼快速有效率地找到「對的」工程師?請他們徒手解題是一種常見方法,但「讀」程式碼的環節,卻常常在面試環節被遺漏了。作者認為,工程師其實 95% 的時間都在讀程式碼,不拿來面試真是太可惜。請面試者「讀」程式碼,通常前五分鐘就能看出面試者對程式碼的掌握度,此外,由於「讀」比「寫」輕鬆一點,輕鬆的環境也讓人較容易發揮實力。

因此他大力鼓吹「讀碼」當面試,也在文末提供了實際作法,例如事先準備一段程式碼,請面試者試著預測輸出結果為何,現場展示正確的結果,如果兩者不符預期,也請他們解釋可能的原因。這時面試官就能初步判斷面試者對解題的掌握能力。下次要面試工程師時,不妨試試請他們「讀程式」。

[Podcast] 星箭廣播 EP154 | 連載再開!從程式設計之道走向軟體工程師的修煉與成長(ft. vgod)

相信許多聽眾對於 vgod〈追求神乎其技的程式設計之道〉系列文章應該不陌生,今年二月他開始連載新的一系列〈軟體工程師的修煉與成長〉文章,這次我們要請 vgod 話說從頭,以國中自學寫程式的故事作為本集開場,一路談到他成為全職軟體工程師後逐漸領悟到「程式設計」與「軟體工程」的不同之處。vgod 還會分享軟體公司裡的「mentorship」是怎麼一回事。如果你可以把自己會的東西交給別人,對團隊和你自己會有哪些影響?

vgod 在未來的節目會陸續談到工程師們在職涯發展上所關注的一些議題,例如以技術在團隊發揮影響力、1 on 1 會議該怎麼談?為什麼 vgod 在職涯發展上選擇「IC」(individual contributor)這條路,而非常見的「EM」(engineering manager)?他怎麼看待這個選擇?不想錯過的話請記得訂閱我們的節目。

[中] Stephanie Kuo/UI介面文字訊息設計準則筆記

UI 文字是使用者跟產品第一線接觸的地方,該用什麼樣的文字跟使用者溝通呢?作者提供許多撰寫 UI 介面文字的原則,像是預留不同語言翻譯的空間、文字簡潔少用俏皮話,程式發生錯誤時,要告知使用者原因與解決方案,如果只是顯示 error code,使用者就得去 Google 或翻閱使用手冊對照,增添麻煩,顯然是需要避免的做法。

比較特別的是,作者認為訊息口吻應保持中立,「抱歉」、「請」這些我們日常口頭用語,在介面上最好避免使用,「我們」也應該用「公司全稱」替代。因為錯誤發生時,不一定是公司的錯,如果介面用了這些客氣禮貌的詞彙,反而成了客戶索賠的利器。本文提供了很多介面文字案例,有許多該注意的眉角,推薦閱讀!

[中] codedump/技術配圖的一些心得

作者一開始會在技術文章內大量配圖,是為了將來自己回看能看懂,但他也認為繪圖能輔助自己思考技術點,如果在交代技術細節和交流時盡量多畫圖,圖畫多了自然比較知道如何透過圖示表達思路。

本文是作者結合寫技術文章的經驗分享製作配圖的眉角,可以歸結爲三個大原則,包括如何區別不同的模塊和組件、表達資料的變化和狀態間的切換、在圖示中加上說明文字等等。文中搭配豐富的範例,提供給撰寫技術文章的讀者參考🙌🏼(註:作者使用的是製圖工具是 OmniGraffle)

[中] Hsin-chieh Yeh/UX 設計與技術的交界線:以使用者權限為例

分享純檢視的文件、給新組員 app 的使用權⋯⋯有別於多數以使用者為核心的設計案,使用者權限設定很技術導向,專注於「安全第一」,沒有技術背景的設計師該怎麼辦呢?擔任 UX 設計師的作者藉由相關經驗分享設計師會需要的資訊及切入點,剖析提升易用性的方法。

其實使用者權限在數位產品中無所不在,卻因為不直接與產品價值掛鉤常被忽略。本文首先介紹權限設計專案的特性和定位,接著帶出設計師最重要的工作主軸。作者還提到,有趣的是,權限頁面很難藉由前期使用者訪談了解需求與目的,但倒是很適合在設計產出後進行易用性測試,可以發現很多按鈕、群組或文案上的盲點。

[英] 一個恍神失誤,直接把 5.4 萬 GitHub 個打星變不見

HTTPie 是一個很受歡迎的開源 CLI HTTP client,很多開發者用它進行 API 測試,該專案在 GitHub 上原本有超過 54,000 個打星,但因為一連串事件,開發者/創辦人 Jakub Roztocil 不小心將專案的 repository 設定轉為為私有(private),於是過去十多年累積的所有星星和超過 1,000 名關注者(watcher)全部都被歸零,事後他求助 GitHub 協助「還原」卻被拒絕。本文就是 Jakub Roztocil 對這次事件的檢討。他先解釋了自己為何「失誤」,簡單來說是他誤以為自己在另一個既沒有星星也沒有內容的 repo,因此將該 repo 設定為私有,但偏偏那個 repo 正是 HTTPie 專案的。

他說自己學到了幾課,像是 UI/UX 與(GitHub)資料庫的設計等等。Jakub Roztocil 在文中展示了將 httpie/.github 與 httpie/httpie 轉成私有時的確認對話框,只有接近底部的地方有幾個字長得略微不同。他認為確認對話框的內容可以更明確,若該項操作(將 repo 轉為私有)會有重大的後果,應避免用抽象語言描述,而是把後果講出來(例如「你即將失去 54,000 個星星!」),反之若只是個空的頁面,就不必寫那麼多。又或者 GitHub 可以考慮以「soft-delete」取代「cascade-delete」,延遲刪除作業的時間,讓使用者來得及反悔。這件事在 Hacker News 有超過 600 個評論,有些人同意 Jakub Roztocil 的看法,但也有人批評 Jakub Roztocil 只是將大部分責任怪到 GitHub 身上。各位讀者你們認為呢?

[英] 我從軟體工程師轉行當全職創作者,這些是我對經營一人公司的建議

Gergely Orosz 在 2020 年底離開 Uber 技術主管一職,他 2021 年 9 月才開始的電子報《The Pragmatic Engineer》目前已是 Substack 付費科技類排名第一。隨著遠端工作在工程師圈內變得普及,越來越多人問他怎麼轉換到創作領域,甚至以此維生。雖然在外界眼中他稱得上是成功的創作者,但作者認為比起目標當「創作者」,應該擴大思考為「一人公司」,並提出扎實的見解。

作者先提供有志於成為全職創作者的人,即使仍在受僱於人的階段也能先佈局或嘗試的多種策略,並說明一人公司賺錢的方式和商業邏輯(他特別指出看似 CP 值不高的「出書」其實⋯⋯)。接著 Gergely Orosz 解釋為何別把社群媒體當作謀生之道、而一人公司也不代表單打獨鬥,最後分享開展一人創業的「保護傘」,提高成功機率。對於任何「想當自己的老闆」的讀者來說,編輯覺得本文很值得一讀~

🚀 目前 Substack 付費科技類電子報第二名在〈明星記者單飛中:值得科技人訂閱的六份 Substack 電子報〉也有詳細介紹哦👈


.

(文章代表圖:Photo by Greg Rakozy on Unsplash

本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
Previous

星箭廣播 155 集——工程師背「船貸」當航海王!科技人的八種極限遠距工作提案

星箭廣播 156 集——在 Y Combinator「加速」三個月是什麼感覺?Heptabase 經驗分享(ft. 詹雨安)

Next
Share via
Copy link
Powered by Social Snap