在進到本期雙週報的主要內容前,想跟大家分享一個 ExplainThis 最近的大事 — 我們開發的 AI 產品 ChatBun 正式上線了!會想開發 ChatBun 這個產品,最主要是想解決過去我們觀察到很多人使用 ChatGPT 的兩大痛點。
一個是用 ChatGPT 還要先學會提示詞,非常麻煩。ChatBun 底層使用 ChatGPT API,但是內建了指令打造各類 AI 角色與工具,讓大家能享受 ChatGPT 的人工智慧,但是免去用 ChatGPT 時遇到的麻煩!舉例來說,這個 OKR 產生器,讓你不用去找 OKR 的相關的提示詞,也能馬上由 AI 幫你產出 OKR。
另一個痛點是,ChatGPT 訓練資料不包含過去一年的最新資料,但許多人想要讓 ChatGPT 根據自己的最新資料回覆。要做到這點,可以用 Fine-tuning 或 Retrieval Augmented Generation (RAG) 等技術,但是這對非技術背景的人門檻太高;我們期望透過 ChatBun 用最簡單的方式,讓人可以客製化自己的 AI 聊天機器人。
目前每天都有 10 個免費額度,歡迎大家玩玩 (連結),也請幫我們推薦給身旁的朋友們,以及幫 ChatBun 的粉絲專頁按個讚 🙏
[前端工程] ChatBun 的前端技術選擇
從技術的角度看 ChatBun,我們可以區分成前端、後端與生成式 AI 這三個部分。在這一期我們來聊聊 ChatBun 的前端技術選擇,以及我們透過哪些開源的工具加速 ChatBun 的前端開發。
在選擇前端框架時,必須說目前的前端框架都已經足夠成熟,雖然各家框架有不同的特點與開發體驗 (DX),但其實如 Rich Harris 說過的「選哪一個都很好」。我們在開發 ChatBun 時選擇了 App Router 版本的 Next.js。主要原因有二,一個是我們用 React 開發的經驗還是比較多一點,所以速度比較快,ChatBun 是希望能快速推出到市場驗證,所以我們選讓我們能快一點開發完成的;第二個是 Next.js App Router 主打 React Server Component,讓我們在互動低的部分 (首頁、價格頁等以資訊呈現為主的部分) 可以更快渲染頁面。
在 UI 元件庫的部分,我們選擇了 Tailwind UI 與 shadcn/ui。Tailwind UI 主要用來處理資訊呈現類的頁面 (首頁、價格頁、常見問題頁),而 shadcn/ui 則是應用程式的頁面 (假如不清楚 shadcn 的強大,可以參考先前我們寫過的這一篇)。
在開發聊天機器人的部分,我們非常推薦 Vercel 的 AI SDK 與 AI ChatBot 這兩個開源專案。前者把處理與模型商提供的 API (例如 OpenAI API) 串接的部分都處理掉;後者則是把開發 AI 聊天機器人的大量前置作業的處理掉 (例如在前端處理串流進來的文字)。我們並沒有直接用這兩個開源套件,而是基於他們的原始碼來開發。最主要是我們要客製化的部分不少,所以只取了這兩個套件中我們要的部分出來用。非常推薦大家平時可以多讀一些開源程式碼,這樣會有能力去從開源套件中原始碼,取自己要的部分,而不會被整個套件綁住。
至於前端開發最依賴的狀態管理,我們使用 React Query,React Query 強大的地方在於,讓處理伺服器狀態與快取,變得非常非常簡單。React Query 作者之前把該套件改名為 TanStack Query,然後開始支援 React 以外的框架,所以現在 Vue、Svelte 等也都可以用。因為 ChatBun 要管理的狀態,幾乎都是伺服器端的狀態 (server state),所以我們並沒有額外用管理客戶端 (client state) 的狀態管理套件 (如果不知道為什麼的人,推薦讀這一篇)。
以上這些是我們主要有使用的開源套件,基本上我們能在極短的時間完成 ChatBun 的開發,完全是仰賴這些開源套件。假如你也想要自己做一個 Side Project,或者是開啟一個應用程式創業項目,在 2023 年,幾乎可以在開源的世界找到你需要的前端工具。只能說身為現代開發者的我們真幸福!
[後端與系統設計] 系統設計五大心法 (2) — 快取 (Cache)
在上一期我們談到均衡負載 (load balancing) 這個系統設計的心法,這一期我們將來討論第二個系統設計心法 — 快取 (cache)。
所謂的快取是指將運算完的結果,存放在可以更快取得的地方。當使用快取時,請求資料時會比從主要儲存位置來得快,同時可以免去重複已經做過的運算。因此,快取可以達到兩個顯而易見的好處 — (i.) 加快響應速度 (ii.) 避免重複運算,藉此能提高資料源頭的乘載量
在實際的應用程式開發中,通常是會採用多層快取的策略,來大幅增加應用程式的併發量與響應速度。舉例來說,可以在資料庫前放一個快取,這樣伺服器可以直接跟快取拿資料,這會比跟資料庫拿還快,而且可以降低資料庫的負載;同時我們可以在 HTTP 層做快取,這樣客戶端要跟伺服器端請求時,可以透過快取來加速,同時減少伺服器的負載。甚至我們可以直接在客戶端 (例如瀏覽器) 快取,更進一步加速響應速度。
雖說快取好處很明顯,但也有必須注意的問題。在軟體工程界有個名言是「電腦科學只有兩件困難的事,一個是快取失效管理,另一個是命名 There are only two hard things in Computer Science: cache invalidation and naming things」。快取失效 (cache invalidation) 的意思是指判斷什麼時候不該繼續用快取,而是要再去源頭取資料,然後更新快取 (revalidate cache)。這個困難點在於,每個應用有不同的屬性,所以沒有一個通用的標準,需要工程師隨著應用的特性去做判斷。
除此之外,在系統中加入快取石,千萬不要把快取當成資料庫。在快取背後,務必要有一個最終的資料來源 (source of truth),因為你沒辦法保證負責快取的機器會不會故障或出問題,因此要有帶著「快取的資料可能會丟失」的角度思考,這時就會有意識要有一個最終的資料來源。
以上是針對快取的介紹,在系統設計時快取是不可或缺的重要環節。如果是要準備系統設計面試的人,務必要對快取有一定的掌握,特別是對不同層級的快取,都需要進一步去了解。
[科技業職涯] 反思軟體工程師的強者文化
這週社群上許多人轉貼一位台大資工系校友,對台大資工系「強者崇拜文化」的思考。原文很長但是很值得一讀 (連結)。在讀完原文、反思我們自身的經驗後,有一些不同視角的觀點與大家分享。
先引述原文中讓我們非常有感的這一段,作者談到
「你說不要競賽,去做其他資訊領域的東西有沒有用? 沒有,一點用都沒有。當年我學測72級分在校成績大概一百多名,在資訊競賽不是特別有成果,但帶著我從小累積的熱情,為高中社團自己架BBS站,去考推甄程式組直接被刷掉了,連個備取也沒給我。上了大一當班代,我直接問了當時的系主任跟副系主任,當年的副系主任告訴我,程式組要的就是有奧林匹亞選手等級的學生。我才知道原來我人生從四歲開始玩電腦做的一切在老師們的眼中這麼微不足道。」
這一段作者在談台大資工系對極度專業知識的崇拜,讓即使從小就碰電腦,甚至高中幫社團架 BBS 站的人,推甄台大資工時連邊的擦不上。這讓人想到,假如馬克祖克柏要推甄台大資工系,大概也會是連邊的擦不到。
雖然新聞媒體早年給祖克柏冠上「天才駭客」的稱號,但是祖克柏在進大學前並沒有什麼了不起的程式競賽 (competitive programming) 成績。反倒是他在進哈佛前就做了一系列軟體應用程式。後來創業做臉書也是應用程式起家,不是什麼程式競賽的產物。
有美國鄉民曾經去爬祖克柏在 TopCoder 上的競賽成績,也不過是在中段而已。換句話說,他是那種做出很多軟體應用,但是沒什麼程式競賽成績的類型,也就是推甄台大資工程式組會被刷掉的類型。
假如你用程式競賽的尺來衡量,祖克柏雖然比一般人強,但絕說不上最頂尖。只是那重要嗎? 對祖克柏來說,我相信他這一生應該不會有一刻懊悔過自己沒在程式競賽有好成績,或是懊悔沒拿過資訊奧林匹亞獎牌。這邊不是要反過來說程式競賽沒有價值,而是當那變成唯一有價值的事,這個教育系統顯然是有問題的。
不只是在入學面,原文作者下面這一段談論業界與學校之間巨大的落差,同樣讓人非常有感。她談到「一直到去咕狗工作之後,我才越來越明白,這些陽剛的強者崇拜有多沒有意義。學術工作少的可憐,學術環境問題一大堆,很多人讀完博班也不過就是來業界工作,而在業界工作根本碰不到什麼了不起的東西,每天在處理的可能不完全是技術面的問題,要改的程式碼也不會用到什麼了不起的演算法。但是我工作之後就很明白,我從小到大做過的每一件事情,他都在我的工作某處用得上。因為真實的世界有很多變化,要走進真正的問題之中快速找到方法處理,而我的博班訓練給了我整套跟使用者互動的基礎,理解他們的問題,而我在大學吐司跟大家一起辦活動,經營社團做事的經驗也給我立足點去參與經營方向的討論。」
在工程師職涯中,寫程式只是其中一環,是必要但不充分的一環。意思是,你要成為軟體工程師,你需要會寫程式,但假如你只會寫程式,你當不了好的軟體工程師。每當談這個點時,就必須推薦 vgod 前輩寫的《軟體工程師的修煉與成長》系列文。
vgod 前輩是靠奧林匹亞獎牌保送進臺大資工系,然後再到 MIT (麻省理工學院) 拿到電腦科學博士。進到業界工作時,一個人負責系統前端到後端,程式寫得又快又好。但是卻接連升職失利。
為什麼?
在他的系列文中,他提到他主管跟他說的,原文寫道「他很快點出我雖然可以一個人抵多個人用,但完全沒表現出領導能力。L4 的中階工程師和 L5 的資深工程師最大的差別不是在程式能寫得多快多好的技術能力,而是能不能帶領幾個人一起完成一個專案解決一個大又模糊的問題。」
沒錯,要成為工程師你需要會寫程式,但要成為資深工程師,程式是否寫得快又好不是重點區別。然而,要成為資深工程師所要具備的,在傳統資工系的教育中沒有被推崇。
這導致一個弔詭的現象,就是在學校時能解出別人解不出的東西會被叫電神,但真的進到業界,才發現當好軟體工程師,你需要一堆「電」以外的軟技能。先前 Google Chrome 的 DX 負責人 Addy Osmani 出過一本叫《Software Engineering - The Soft Parts》的書,就是因為他看過太多工程師在職涯無法突破,是「軟」技能缺乏所致。
你可能會說,台大也是很重通識教育的學校,甚至有棟樓叫「博雅」,為什麼資工系的學生會如此聚焦在極度專業知識崇拜? 其實這也非資工系學生特有,只是不同科系的體現方式不同,例如同樣的場景換到管理學院,學生們變成追求誰實習做的多、誰實習過的公司名氣更響亮。
所以或許真正該問的,是為什麼台大讓學生進到某個系之後,對於強或者成功的價值觀變得如此單一? 就目的上,台大各個系所本身往該領域去鑽深本身沒有什麼問題。問題是整個大學系統的設計讓人把身分認同固著在自己的科系,進而讓人生變得只用單一指標衡量自己。
我們還在讀台大時,當時基本上每個系都有所謂「系核」、「系邊」的概念,用來描述在系上活躍與邊陲的兩類人。為什麼這個劃分是以「系」為單位? 為什麼不是每個人有自己在的核心,只是每個人的核心不同罷了?
關於這些問題,台大並非沒有在思考或改變,起碼我們畢業的前一年,台大成立了 D-School 試圖要打破穀倉,讓跨領域的整合得以成為學習體驗中的一環。事實上,ExplainThis 的共同創辦人們就是七年前在 D-School 認識的。
D-School 是一個超脫系所的存在,在那邊再也沒有所謂的「系邊」,因為大家從各個不同學院系所來,自然沒有核心與邊陲之分;也沒有單一且狹隘的「強者」定義,蘋果與橘子本來就難比較,每個人在課程的專案中都有獨特貢獻。
如果沒有當年在 D-School 被鼓勵嘗試走出自己的路,現在的我們大概也不會有勇氣投入 ChatBun 的創業中,可能會一輩子都選擇安逸地當個大廠的軟體工程師。
在畢業後幾年,看到 D-School 開出自己的學位,覺得現在的學生真的比當年的我們幸運多了。不過 D-School 畢竟在台大還是一個相對小眾的地方,要讓整個體系改變,相信還有一段很長的路要走。畢竟光是大型的軟體系統要遷移就不容易,學校體系牽涉到更多利害關係人,遠比軟體系統還要複雜,要完全遷移肯定是以年為單位。
這個議題的討論,還有非常多可以展開的面向。最後想推薦 Y Combinator 創辦人 Paul Graham 的 《Cities and Ambition》 一文,裡頭提到每個城市有不同的氣息,劍橋是知識、紐約是金錢、矽谷則是新創,除非你清楚知曉自己要什麼,不然在年輕時最好多到不同地方遊歷。
世界很大,強的方式很多種,願我們都能以自己理想的樣子發著光。
本期推薦
過去在開發時要引入字體,多數人會想到 Google Fonts,但最近多出了不同的選擇。 Cloudflare 前陣子推出了 Cloudflare Fonts,在發布的部落格文中,Cloudflare 團隊談到為什麼 Google Fonts 的加載效能差,以及 Cloudflare Fonts 做了什麼來提升加載速度,非常值得一讀 [連結]
最近在社群很紅的多人協作開發平台 PartyKit 宣布種子輪募資。如果你是想開發像是 Notion 那種可以多人同時線上編輯的軟體,過去多半需要花很大的時間精力在處理基礎設施。但現在有了像 PartyKit 這樣的工具,開發者可以更專注在產品特色的開發 [連結]
Vite 也要投入 Rust 的懷抱了!Evan You 在最新的 ViteConf 中宣布 Rolldown,找來前 rspack 的核心成員,目標是讓 Vite 的效能再更上一層樓 [連結]
年初宣布後醞釀了半年, Google 的 Web Component 元件庫 Lit 預發布 3.0 版本。Web Component 是近年越來越多人的選擇,如果你有在考慮要不要試試 Web Component,等 Lit 3.0 正式發佈後,或許是個好時機 [連結]
提到元件,許多前端工程師的面試,可能會問如何打造一個 Toast 元件,這篇文章 Emil Kowalski 的這篇文章非常值得一讀 [連結]
SQLite 資料庫工具 Turso 宣布免費版現在可以用 500 個資料庫,假如你正在考慮開始一個新的項目,Turso 免費版的方案,讓你可以在拆分資料庫上更有餘裕。特別是現在 GDPR 等不同規範,拆資料庫、讓資料庫獨立變得更重要,Turso 這舉真的頗吸引人 [連結]
ExplainThis 致力讓全端雙週報保持永久免費閱讀。為了能更永續經營這份電子報,我們開放電子報開頭的版面贊助。目前電子報有超過 1500+ 位讀者,平均開信率 > 60%,受眾主要是對軟體全端開發、軟體業職涯感興趣的讀者。如果你有認識合適的廠商,還請推薦給我們 🤝
另外,雖然電子報為免費訂閱,但我們將留言發問保留給付費訂閱的讀者,在電子報的留言我們都一定會回覆。如果你有任何問題或想交流的,都歡迎在留言區發問 🙂