科技創業週報 #192:用技術麻瓜的語言理解 API

| |

《科技創業週報》是由 Star Rocket 於每週三發送的免費電子報,內容涵蓋創新故事與觀點、產品開發技術與經驗的分享、值得一聽的 Podcast 節目與歷久彌新的經典好文。

每則選文都會加上編輯精心撰寫的引文,非常推薦給工程師、產品經理、設計師,或者是所有對科技產業感興趣的讀者訂閱。(訂閱連結附於文末)

哈囉讀者:

前陣子《星箭廣播》才在跟大家聊數位年代下,我們保有的「不科技」行為。其中一個,就是看紙本書跟電子書的習慣。當時還對電子書持有些疑慮的編輯 Maxine,沒想到在錄完的隔一週,就被推坑收下了朋友二手的 mooInk….(掩面)。

看週報前,我們再次誠摯邀請工程師或設計師的你,分享一篇你最近看過印象深刻的文章給編輯們~

Maxine
[Podcast] 用聽的理解 API:一個早已滲透你我生活的技術

當軟體持續吃掉世界時,API 正在助攻吃掉企業價值鏈。 延續之前週報分享的、讓我們開眼界的 API 文章,編輯團隊透過 podcast 持續挖深這個題目。

本集節目,我們力求讓沒有工程背景的聽眾,也能理解什麼是 API,並且帶著一般人去了解生活中出現的 API,例如天氣 app、公車資訊 app,以及銀行相關的 app 等等,來賓 Lawrence 甚至分享了一段自己如何藉由 API 自行打造了一套「智慧冷氣」系統。
接著,Lawrence 更是在節目中剖析了多個案例,讓大家了解 API 在企業不同的成長階段、不同的商業環節分別可以扮演什麼角色,如 Flickr、Amazon、Facebook、Slack 和 Twilio 等等,接著再詳談善用 API 在跨平台、開放與經營管理上的好處。最後,Lawrence 也會談到他身為創業者,對於 API 如何做為一種思維運用在創業上的看法。
[英] 快的軟體,是最好的軟體

這篇文章最近在 Hacker News 上蠻紅的,工程師們可能這個禮拜在許多地方都有看到人分享。本文作者以「快」(speed, fastness)切入,認為最好的軟體,必須要是從功能到介面都能以流暢速度運作。他認為,一個軟體的速度若能快到讓人感受到無縫不間斷的流暢感,就會產生使用者自然、無負擔地讓產品融入生活,而非抗拒不想使用。

這篇文章有點厲害的點在於,作者分享了自己的使用經驗,分析/比對了超過十種軟體產品,例如寫作軟體 Ulysses, Sublime Text、修圖軟體 Adobe Lightroom, Photoshop, Affinity Photo、設計軟體 Sketch, Figma;又或是為何放棄 Google Maps,以及為何覺得把 iTunes 打掉重練可能是 Apple 最好的決定?
[中] Cjin/有關 Slack 上市和一些 Slack 的故事

Slack 雖然還在虧損,外界卻依然相當看好它,可能的原因是什麼?

最近或許因為 Slack 在今年(2019)6 月 IPO 了,所以相關的好文不少。種子基金 Hustle Fund 合夥人 Cjin 研究了該公司上市文件,對比同樣為 B2B/Saas 類型的 Zoom。雖然 Slack 目前仍未真正賺錢,但營收卻是來自真正的用付訂閱費,而非補貼或廣告。同時,她認為 Slack 有其潛力,是因為「Slack 比較像一個公司在溝通及協作的核心或基礎,而其他 B2B 服務都比較像『工具類』,當工具類的應用有更便宜的或帶有新功能的新服務出現時,比較容易被取代。」
[中] 有物報告/Dropbox 當年進 Y Combinator 的申請文件:你能回答幾題?

《有物報告》在多年前翻譯了 2007 年 Dropbox 申請進入矽谷最知名加速器 Y Combinator 的申請文件(原文件請點這),作者認為,從文件中,創業者不僅可以挑戰看看,自己是否有能力回答,而所回答的又是否能為 YC 所接受;另一方面,也可以思考像 YC 這樣大的加速器,他們是如何問問題?並藉由這些問題及答案來判斷公司的潛力?而你與你開發的產品,在哪個位置上?

補充:作者註解中表示最喜歡的回答,在 YC 提供的原文件中可能被遺漏了,但媒體 Business Inside 過去的報導有提供完整版本。
[英] No Code 是趨勢,還是結果?工程師該如何看待 No Code?

這篇文章由 Product Hunt 創辦人 Ryan Hoover 所寫,他認為 No Code 是個趨勢,而市面上我們常見的產品跟服務,都是種 No Code 的展現,例如快速用 Shopify 開店、用 Wix 建立網頁、使用 Substack 製作電子報。但文中他也提到外界另一種對 No Code 的「質疑」,比方說,一間明明有技術資源、團隊的公司,為什麼要選擇 No Code? 站在組織的角度,可能是更快速、便利,易維護。
[英] 軟體工程師的 podcast 開源專案

這次推薦的不只是單純的 Podcast 節目,而是背後的開源專案。本文作者是位前 Amazon 員工,過去曾參與 Software Engineering Radio 的製作,並發現工程師聽眾是群尚未被觸及的閱聽族群,於是在 2015 開始獨立製作節目《Software Engineering Daily》,從一開始很陽春、一人悶頭規劃採訪、錄音 + 剪輯,在節目中塞廣告,到現在有了自己的小團隊,且營收達每月 6 萬美元。

本文他分享了如何起頭做節目,並在 2016 年「開源」出去。社群的人可以在 GitHub 上看到該節目的 Roadmap,包含後續開發的節目網頁、iOS/Android 的 app,以及 API 等,也可以在上面貢獻節目題材。 有趣的是該節目的網頁,設計的很像傳統報紙(如《紐時》),很復古。工程師讀者不妨挑戰自製 Podcast 看看(?)
[英] Substack,另一種寫作的練習:試著發行自己的電子報?

Google Ventures 合夥人 M.G.Siegler 前幾週宣布他在電子報平台 Revue 經營 3 年的電子報要轉戰到 Substack 上,理由很令人敬佩:他開始使用 Revue 時就是為了親身體驗這個平台的功能跟服務;如今隨著新競爭者 Substack 2018 年從 Y Combinator 孵化而出,又在 2019 年 7 月獲得 a16z A 輪資金,他打算再一次親身實驗。

出於好奇,編輯找了 Substack 的故事,結果有些感動。創辦人之一的 Hamish McKenzie 原是科技作者,有感於媒體難以掙脫廣告商模束縛,於是創辦Substack,發展電子報訂閱制,讓內容創作者專注寫作。他認為,科技部落客 Ben Thompson 已證明訂閱制是可行的,Substack 必須協助降低入門門檻。

與 Substack 類似的服務還有 MailChimp 的 TinyLetter 跟 Revue。工程師 Sam Tsai 曾寫過他使用 Revue 建立電子報的經驗。想練習寫作的工程師,除了部落格之外,電子報可能也是個不錯的方向。
[英] 你的公司應該追求「閃電擴張」(Blitzscaling)嗎?

本文是 Reid Hoffman 寫來回應 Tim O’Reilly 早前對矽谷常見「追求快速擴張」的批評(我們之前週報也有分享過 )。Tim O’Reilly 認為,快速擴張只是爭奪「贏者全拿」跟「護城河地位」,卻忽略健全商模跟永續經營;但 Hoffman 強調,閃電擴張是經過縝密風險評估後的策略,有別於過去達康時代所說的 “get big fast”,並非用錢買成長,而是承受短期的虧損,快速鞏固創新商模,以達長期的營利。他在文章也提醒,並非每間公司都適合採用此策略。
.
Previous

《星箭廣播》15 集 — — API:沒有圖形的介面

《星箭廣播》16 集 —— 如何選擇一本書?

Next

發表留言

Share via
Copy link
Powered by Social Snap