一句話總結

一日配送：能有多難？

本月亮點

• 在提供一日配送選項上遇到了意想不到的困難。
• 參加了 Handmade Seattle 研討會。
• 嘗試了 Zig 與一個開源 AI 聊天機器人。

目標成績

每個月初，我都會設定當月想完成的目標。以下是本月目標的達成情況：

盡快將製造轉移至委外製造商

• 結果：轉移已完成。
• 評分：A

委外製造商現在生產的 TinyPilot 裝置品質與我們自行組裝時相同。製造商現在直接將裝置運送至我們的 3PL 倉庫，這讓 TinyPilot 不再那麼需要擁有自己的辦公室。

進行五通客戶訪談電話

• 結果：我們聯繫了三位客戶，但沒有完成任何一通訪談
• 評分：F

這次我忘了把這件事列為優先。由於參加研討會與假期旅行，我損失了將近兩週的時間，客服團隊的可用人力也比平常少。我應該更積極地與團隊追蹤以優先處理此事，因為為了企業的長期永續發展，我們需要持續在此投入。

清空 TinyPilot 辦公室內所有舊庫存與備用零件

• 結果：我決定暫停此計畫
• 評分：不適用

結果發現房東對於我們何時搬離相當寬鬆，所以關閉辦公室的急迫性不如我想像的高。此外，不把所有東西直接丟掉就清空辦公室，比我預期的還要困難。我們有數十件每件價值 1 至 50 美元的物品，但每種通常只有少數幾個。

舉例來說，我們有三塊用過的 Arduino Uno 開發板，每塊零售價為 28 美元。我們或許可以在 eBay 上以總價 30 美元賣掉這三塊，但從頭到尾處理流程大約需要兩個小時。因此耗費的員工薪資會比賣板子賺到的錢還多。

我的新計畫是等到接近搬離時，再公告一個時段讓大家來免費拿取想要的東西。

TinyPilot 數據統計

獲利數字看起來很嚇人，但這只是因為轉向委外製造讓我的支出變得比較「爆發性」。10 月時我沒有任何原物料帳單，但在 11 月，原物料支出達 57,000 美元。我其實應該將這些列為銷貨成本，但目前我只是呈現簡單的現金收支差額。

8 萬至 10 萬美元是 TinyPilot 正常的營收區間，我們仍穩穩落在其中。我本來或許會想把握黑色星期五／網路星期一的機會，但由於製造轉移導致庫存偏低，我們沒有足夠的庫存可以降價促銷。

一日配送：能有多難？

在 TinyPilot 營運的大部分時間裡，我們並未提供隔夜或一日配送。

當我們自行出貨時，辦公室每週有六天有人處理訂單，但每天只有一個人在場。我沒有提供一日配送，是因為我知道總會有有人生病或休假的情況，導致無法在一天內完成出貨。

當我們將出貨改由第三方物流倉庫（3PL）處理後，人力不足的脆弱性就消失了。3PL 的人力備援比我們充足得多，因此無論如何，訂單都應該能在一個工作天內寄出。

改用 3PL 後，我們終於能夠提供一日配送選項了！

複雜的運送技術架構

轉用 3PL 後，管理運送選項的邏輯變得更複雜。我們過去向 TinyPilot 顧客呈現運送選項的方式如下：

1. 我選擇要讓 Shopify 向顧客提供哪些運送選項。
2. 顧客在結帳時選擇一種運送方式。
3. 我們透過 Shopify 購買與顧客選擇相符的郵資。

在這套系統下，Shopify 端到端掌控了整個體驗，而且做得很好。

我們的 3PL 使用一套名為 ShipStation 的（不太好用的）倉儲管理系統。該工具與我們的 Shopify 商店整合，因此現在的架構變成這樣：

1. ShipStation 向 3PL 提供一份其支援的運送選項清單。
2. 3PL 從這份清單中選擇要提供給其客戶（TinyPilot）的運送選項。
3. Shopify 向 ShipStation 查詢 ShipStation 與 3PL 雙方共同同意的運送選項。
4. 我再從 Shopify 中挑選要向顧客開放的運送選項。
5. 結帳時，ShipStation 會不透明地猜測哪些選項對顧客「最好」，並將運送選項縮減至僅剩兩或三個。
6. 顧客在結帳時選擇一種運送方式。
7. 3PL 透過 ShipStation 或其他供應商購買與顧客選擇相符的郵資。

有這麼多參與者，就有無數出錯的可能，也有無數互相推卸責任的機會。

我嘗試啟用一日配送，卻發現當設定從 3PL 經 ShipStation、Shopify 一路傳遞到我這裡時，已經沒有任何一日配送選項可用。

經過數個月的來回溝通，我們將問題縮小到 ShipStation。他們不顯示一日配送選項，是因為他們認為一日與二日配送選項「相似」，但二日選項總是比較便宜，所以他們永遠不會呈現一日選項。

是的，你沒看錯。ShipStation 這家主要業務是販售包裹郵資的公司，竟然無法理解為什麼有人會在二日配送比較便宜的情況下仍選擇一日配送。

由於 ShipStation 問題太多，我決定改回舊的架構來向顧客呈現運送選項。現在，我們只透過 Shopify 向顧客顯示運送選項與費率，根本不再向 ShipStation 查詢費率。

把 ShipStation 排除在結帳流程之外的問題在於，3PL 是以較高的 ShipStation 費率購買郵資，但 Shopify 卻是以較低的 Shopify 費率向顧客收取運費。因此，顧客可能只付了 30 美元的隔夜運費，但透過 ShipStation 的實際郵資卻是 100 美元。TinyPilot 必須自行吸收這 70 美元的差額。

儘管如此，這個解法讓 TinyPilot 能夠提供我們想要的運送選項，而不會被 ShipStation 傻呼呼地覆蓋掉。而且吸收 70 美元的額外運費，總比完全做不成這筆生意來得好。

一日配送的顧客要求多四倍

大多數時候，3PL 會在一個工作天內寄出我們的訂單。偶爾會遇到狀況需要兩個工作天，有時（非常少見）甚至要三天。我們在網站上標示最多需要三天的處理時間，但顧客似乎不太注意這點。

90% 的情況下，選擇一般陸運或二日配送的顧客對於處理時間延遲一天不會有任何反應。

黑色星期五過後的星期一，UPS 出現了一個奇怪的問題，他們沒有更新任何已取件訂單的追蹤資訊。倉庫信誓旦旦說 UPS 已經取走所有包裹，但 UPS 的追蹤系統卻什麼都沒顯示。

這個 UPS 追蹤錯誤影響了五位要求一日配送的顧客。在 24 小時內，其中兩位就來信抱怨延遲。也就是說，40% 的一日配送顧客提出抱怨，相較之下，一般陸運或二日配送的顧客中，只有約 10% 會注意到延遲。

我完全能理解。當我用一日配送下單時，我會急著想收到貨，如果商家拖上好幾天才出貨，我也會很惱火。

這些一日配送的顧客是一把雙面刃。如果他們願意付五倍於一般陸運的費用來求快，他們很可能是會推升 TinyPilot 銷售額的大客戶。但我也發現他們要求相當高，會讓我們的客服團隊壓力倍增，因為他們有著多數顧客所沒有的急迫性期待。

我的第一場 Handmade 研討會

11 月，我在西雅圖參加了第一場 Handmade 研討會。這是一個為從事低階軟體工作者舉辦的獨立研討會。

以下是我的研討會心得。

熱門技術堆疊之外還有其他選擇

David Foster Wallace（大衛·福斯特·華萊士）在他著名的 2005 年 Kenyon College（肯尼恩學院）畢業典禮演說中，以一個關於魚的笑話開場：

有兩條小魚一起游著，遇到一條迎面游來的老魚，老魚向牠們點頭說：「早啊，孩子們。水怎麼樣啊？」兩條小魚繼續往前游了一會兒，然後其中一條終於看向另一條說：「水是什麼鬼東西？」

對我而言，網頁瀏覽器就是水。

我已經太習慣把軟體想成是使用者最終透過 HTML 與 JavaScript 互動的東西，以至於幾乎忘了還有其他可能。我已經很久沒有想過，圍繞著一項在 90 年代為了呈現靜態文件而創造的技術來設計一切，是多麼奇怪的事。

但在 Handmade，我遇到的大多數開發者根本完全不碰網頁瀏覽器，也沒使用任何我習以為常的技術。

我遇到了 MobileCode 的創作者，這是一款可在手機和平板上寫程式的應用程式。我問他用什麼語言，原本以為他會說 Flutter 或很可能是 React Native，結果當他說「C 語言」時，我簡直驚呆了。

不僅如此，他還說用 C 語言做行動開發的體驗很不錯。他可以直接在 iOS 與 Android 上呼叫原生圖形 API，而不必透過現代框架中層層的抽象。

不懈的獨立野心

我最初聽說 Handmade 的原因，是因為我追蹤 Andreas Kling（安德里亞斯·克林），他是 SerenityOS 的創作者。他獨自一人、在沒有任何第三方函式庫或相依套件的情況下打造了最初的作業系統，並於 2021 年在 Handmade 上發表了他的專案。

Handmade 也吸引了許多關於 Zig 的演講，這是一個我關注已久的獨立程式語言。Zig 的創作者 Andrew Kelly（安德魯·凱利）在 2021 年登上 CoRecursive 播客，談到他想用 Zig 取代全世界所有的 C 語言程式碼。

Adam：當你擊敗 C 語言後，世界會是什麼樣子？

安德魯·凱利：喔，那會很美。世界看起來大致相同，只是你所有的應用程式都運作得稍微好一點，比較不會當機，記憶體用量更少，跑得更快……

當教科書想展示作業系統或嵌入式裝置如何運作時，會直接假設你會用 Zig 作為範例程式碼，因為那就是大家都在用的東西。

我覺得安德魯·凱利這種對軟體的野心與熱情非常酷、令人振奮，而這正是我來 Handmade 想尋找的東西。

Handmade 回應了我對獨立野心的期待。這場研討會頌揚「重新發明輪子」的實踐。

在軟體界，指責某人「重新發明輪子」通常是貶抑之詞，但在 Handmade 卻擁抱這種做法。為何不重新發明輪子呢？也許你的輪子會比大家都在用的輪子更好。而且光是嘗試重新發明輪子，你就能更了解輪子是如何運作的。

Cameron Riekes（卡麥隆·里克斯）還是一名大學生，他發表了關於打造 2D 角色扮演遊戲的內容。但接著他「順便」從零開始寫了自己的 3D 遊戲引擎。

Yasser Arguelles（亞瑟·阿古雷斯）在二十出頭，正在開發 Tilde，這是一個從零開始打造、要取代 LLVM 的專案。補充一下：LLVM 是一個已持續開發 20 年的編譯器後端。在他的發表中，亞瑟提到自己並沒有編譯器背景，但他在 Handmade 的討論中看到最熱門的需求之一就是尋找 LLVM 的替代方案，所以他想：「好啊，那我來做吧。」

而且我還見到了安德魯·凱利，他人非常好。這次對話最終也激勵我去嘗試寫一些 Zig 程式碼。

對大型科技公司的極度懷疑

我對這場研討會的一個抱怨是，其對大型科技公司的批判語氣到了我覺得不理性的程度。

整場研討會的論調是，大型科技公司基本上就是毒藥。他們生產的一切都充滿錯誤、臃腫、不可靠且定價過高。

根據講者的說法，更多人沒有意識到大型科技公司缺點的原因，在於大型科技公司掌控了軟體研討會。他們禁止講者誠實地談論大型科技公司軟體的問題。我曾在幾場中型研討會上發表演說，從來沒有人告訴我不能批評大型科技公司，所以這說法對我而言聽起來很不真實。

我同情反大型科技公司的觀點。只要可行，我也偏好獨立技術，但我也認為大型科技公司在很多方面做得很好，並且在推動技術前進上承擔了大部分的重任。我認為只是對其嗤之以鼻、並假設獨立技術永遠比大型科技公司的等價物更好，是一種錯誤。

其他會後紀錄

• Carl Sverre

如果你知道其他會後紀錄，請告訴我，我會加上連結。

業餘專案

WanderJest

WanderJest 是我幾年前開始的一個網頁應用程式，旨在幫助人們找到附近的現場喜劇表演。我在 COVID 疫情爆發時將它擱置，但之後仍不時斷斷續續地修修改改。

WanderJest 最大的挑戰之一是取得即將舉行之演出的資訊。一場喜劇演出的權威資訊通常就是一張像這樣的海報：

表演者不想做好海報後，還要把所有資訊再重新輸入到別處，所以我一直在思考如何「免費」從海報中取得這些資訊。

我的第一個想法是打造一個幫助演出製作人製作海報的工具。我嘗試了幾天，但第一位我去提案的喜劇演員並不感興趣。我還沒有完全放棄這個想法，但也還沒有足夠的熱情去繼續迭代。

但隨著 AI 影像辨識技術的進步，我的另一個想法是去搜集演出的海報，然後使用開源 AI 工具來擷取演出資訊。

當我讀到 Simon Willison（西蒙·威利森）關於使用 Llamafile 的 文章時，我意識到現在實驗具備影像理解能力的聊天機器人是多麼容易，因此我決定試著解決海報的問題。

可惜的是，LLaVA 1.5 在影像上的準確度似乎還不足以滿足我的需求。當我給它一張喜劇演出海報並提問時，它的回答準確率只有約 70%：

我試著盲目地調整設定，但無法改善結果。

儘管如此，我對於這個領域中開源解決方案的進展與競爭仍感到興奮。更多詳情請見：

• 使用 Llamafile 與 LLaVA 1.5 的粗略實驗

總結

完成了什麼？

• 發布了 TinyPilot Pro 2.6.2
• 參加了 Handmade Seattle 研討會
• 解決了與一家關鍵供應商之間的運送匯出問題

經驗教訓

• 一日配送會吸引願意花更多錢的顧客，但這些顧客也更加挑剔。

下個月的目標

• 完成 TinyPilot 授權驗證的設計工作。
• 建立對每批新裝置進行抽檢的流程。
• 處理 TinyPilot 年底的稅務工作。