關於 #Ruby 的內容

Kobako：Handle 機制對許多支援腳本語言的專案並不算太特殊的機制，但是 Block 概念算是 Ruby 語言特有的能力，如果使用沙盒（Sandbox）時無法善用，那就太可惜。

然而，像這樣的寫法真的做得到嗎？

1sandbox.bind("Seq::Map", ->(items, &blk) { items.map(&blk) })
2sandbox.eval("Seq::Map.call([1, 2, 3]) { |x| x * 2 }").value
3
4# => [2, 4, 6]

我們竟然可以在沙盒裡面用一個 Block 接收外部的呼叫。

最近 Kobako 更新到 v0.28.0 後，改善了原本對 MessagePack 高度依賴的設計，這是從八月 COSCUP 結束後的第一個大改版。

然而，當我們要迎接明年（2027 年）的 AI 應用時，在 Ruby 生態系還缺少怎樣的能力，我認為答案再次回到四月份我在日本 RubyKaigi 和朋友分享的「虛擬檔案系統（Virtual Filesystem）」上，因此 Kobako 也即將支援這個特性。

在 Kobako：執行腳本已經看過一個完整的運作是怎樣設計的，但是現有的設計還有一些不方便的地方，當我們想將一個 Ruby 的物件在沙盒（Sandbox）中呼叫時，卻很難直接使用到那些回傳值。

當我們有了標準輸出能力後，執行腳本是否正常就可以順利地被驗證，這表示我們可以開始真正的來把 Ruby 跑在 Kobako 的沙盒（Sandbox）環境下。

解決 mruby 在 WebAssembly 執行的基本條件後，是時候開始考慮能夠有更多實際的應用方式，至少要讓一個腳本可以執行，然後順利看到 Hello World 這樣的訊息，但是 mruby 本身的設計並沒有考慮 WASI（WebAssembly System Interface）環境，因此有很多 Gem 是無法使用的。

在 Kobako：WebAssembly 的記憶體交換中解決了 Ruby 和 WebAssembly 互動的問題，也讓 Ruby 和 mruby 的數值能夠有互相交換的能力，基本上已經把「沙盒（Sandbox）」的問題處理乾淨。

然而 Kobako 的開發仍在非常初期，因為還有許多實際使用才會遇到的問題需要解決，其中一個就是「決定怎麼停下來」這樣的問題。

Sumitsubo 是我用來將「規格」變成實際可驗證程式碼的工具，在 Sumitsubo：把規格做成 Linter 的初期試做中採用了 JSON 來描述規格，然而在調查有沒有相似工具時，意外發現直接讓 Markdown 變成結構化的資訊來源，就可以用寫文件的方式來設計工具。

開發 Kobako 的過程到中後期，一直讓我對於「規格有沒有對齊」這樣的問題困擾著我。理論上規格驅動開發（Spec-Driven Development）是很理想的，但語言模型本身就不是確定性的設計，即使有規格參照也還是會偏移，或者遺漏。

因此 Sumitsubo 這個專案就在最近被設計出來，作為一個通用的檢查工具。

前幾篇說明了選擇 MessagePack 的過程，然而使用 WebAssembly 還要能夠互動，跟原生的套件互動方式有一點不太一樣。

理由是我們要打造的是沙盒（Sandbox）來隔離不安全的程式碼，這表示操作基本上是接近單向的，在沙盒中執行的程式，是不能碰到任何宿主（Host）的記憶體，那麼原本預想的方法呼叫，就需要一些特別的方式來處理。

上週末我在 COSCUP 的演講「讓 AI 接管你的應用，打造微秒級無縫的 Ruby 安全沙盒」分享 Kobako 設計過程中的一些考量，後續的提問被問到在 AI 時代不太需要考慮語言時，為什麼要選 Ruby 呢？

簡單地回答，單純就是「我喜歡用 Ruby 這個語言」然而在 Kobako 的設計，還有很多更深層的考量。