《科技創業週報》是由 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”，並非用錢買成長，而是承受短期的虧損，快速鞏固創新商模，以達長期的營利。他在文章也提醒，並非每間公司都適合採用此策略。 |
