【科技新聞】Builder’s Remedy 明天在加州許多城市生效

看看像日本這樣幾乎沒有任何分區法的其他國家，這看起來很棒，我希望它能像二戰前那樣再次導致更多的混合城市和更多的步行/宜居區域。有趣的是，自由的美國土地有如此多的限制，在全國范圍內建立數百個分區法造成了很多壞處，並導致大量城市擴張，導致非常貧窮的城鎮，這些城鎮實際上無法收回成本。我認為我們需要一些分區法，而且我相信這些法律會比人們期望的更快地恢復，主要是由於糟糕的規劃或大筆賄賂。但希望一些有用的分區法能夠堅持下去。

這是一篇關於好消息的好文章（除了第一句話稱它為“鮮為人知的法律”——它一直很有爭議）。

帕洛阿爾託一直在反對這些規則，我很高興它們將得到執行。當我在 80 年代初第一次搬到帕洛阿爾托時，那裡的氣候非常進步：幾棟 SRO 建築，平均收入低於一些鄰近城鎮，許多社會支持計劃，以及明顯不受歡迎的零售業。但是在互聯網繁榮時期出現的大量淘金者讓房地產利益集團控制了市議會，總體上使該鎮變得更加傲慢。 SRO 酒店變成了精品酒店，許多長期居民被驅逐出境。好吧，謝天謝地，那些混蛋正在收穫他們播種的東西。由於新人的湧入，也許我們會恢復一些冷靜的實驗氛圍。

我沒有意識到住房短缺問題可以追溯到幾十年前。它為第 13 號提案設定了一個有趣的背景（基於購買價格的稅基，而不是通常基於評估價值），因為分區規則是如此具有排他性。基本上，表明國家的稅收困難本身就是排除的後果。

我想知道這將如何在密集區域之外發揮作用。例如，卡拉維拉斯縣的人口在減少，但就業和稅收的主要來源是建築業。不限建設，會否掀起新開發的小熱潮，拆毀原始森林，做空開發？

庫比蒂諾有一位與這座城市抗爭多年的開發商，最近變得非常安靜。現在我知道為什麼了。

我懷疑他們有一個在我家後面建造絕對巨大的高層建築的計劃，他們將在明天早上 8 點提交。

我的鄰居們會生氣的。

祝賀 automerge 團隊！這是一項了不起的成就。

我特別喜歡性能改進。我在 18 個月前對 automerge 進行了基準測試，基準測試花了大約 5 分鐘來處理一篇論文的編輯。一些單字符插入佔用了 2 秒的 CPU 時間。從這篇文章來看，整個編輯跟踪（260000 次擊鍵）似乎縮短到了 600 毫秒。這是一個巨大的進步。這意味著 automerge 在性能上與 yjs 相似，這反過來又使 automerge 適用於更廣泛的應用程序集。

我真正喜歡協作編輯空間的一件事是周圍分享了多少想法。高度緊湊的二進制編碼首先在 automerge 中完成，然後在 yjs 和 diamond 類型中復制和調整。使用內部列表而不是樹的想法是相反的——yjs 提出了這個想法，並且這種方法已經在我所知道的所有生產序列 CRDT 中落地。

關於非交錯、BFT 屬性、數據庫互操作性和更多性能調整的工作正在進行中，我們（共同）仍在研究這些工作。但 CRDT 的未來似乎一片光明。幾年後，我希望所有新軟件都建立在本地第一基礎之上。像這樣工作是我們實現目標的方式。

對於所有相關人員，幹得好！保持它的到來！

另請參閱 Autosurgeon（今天發布 0.3.0），它是 Automerge for Rust 之上的更高級別的 API：

我正在構建一個帶有服務器後端的移動應用程序，我正在尋找資源以離線優先的方式構建它們（因為與瀏覽器不同，人們希望盡可能離線使用應用程序，例如健身或習慣跟踪器）。

我發現無衝突複製數據類型 (CRDTS) 的概念很有趣，因為它允許您擁有完全離線的體驗，同時還擁有無衝突的同步體驗。我一直在尋找一些好的庫，遇到了 automerge [0] 和 yrs [1]，但它們都有一些粗糙的 API，因為它們主要是低級 Rust 庫，由高級 TypeScript API 包裝。

Autosurgeon 包裝了 automerge 的低級 API，使其更符合人體工程學，更接近 TypeScript 體驗，但當然是在 Rust 中。例如，您可以使用 `struct`，autosurgeon 將自動序列化和反序列化，這在 base automerge 中不存在，它更側重於字符串鍵和任意值。

我計劃將它與 Flutter 和 flutter_rust_bridge [2] 一起使用，以便在任何地方都使用相同的 Rust 庫。在這種情況下，服務器只是成為另一個（儘管更有特權）客戶端。

[0] https://github.com/automerge/automerge-rs

[1] https://github.com/y-crdt/y-crdt

[2] https://github.com/fzyzcjy/flutter_rust_bridge

非常祝賀 Automerge 的工作人員經過多年的努力交付了這個。在這一點上，Yjs 和 Automerge 都有 Rust 庫和（很快？）綁定更多語言，而不僅僅是保持同步的 JS。

與 Automerge 2.0.2 相比，在 661 毫秒和 22,953,984 字節內存時不穩定的 Automerge 2.0.2 在論文基準測試中引用了 Yjs（純 javascript？）。看起來最新的 Automerge 2 比 Yjs 更快，但仍然使用 2 倍多的內存。

我想知道這是通過綁定比較 JS 的使用情況，還是直接比較兩種不同的 Rust 實現，或者通過 Rust 比較 Automerge 2.0.2-unstable 與通過 NodeJS 的 Yjs。

我仍然不確定我會推薦哪一套工具；我相信 Yjs 更積極地部署在生產中，因為 Automerge 實施到目前為止在性能方面遠遠落後於現在。然而，Peritext 的一位作者（我在 Notion 的團隊中的https://twitter.com/sliminality ）告訴我 Automerge 更擅長文本，因為它不像 Yjs 那樣受到交錯字符的影響。所以考慮用它代替 Yjs！

實際上，我在每種新語言或運行時構建最小的 Redis 克隆，或者當我想探索線程模型時。

這一切都始於https://github.com/rcarmo/miniredis （我分叉添加並試驗 pub/sub），我發現自己一次又一次地這樣做，因為 Redis 是典型的網絡服務：

通過實現它，您可以了解套接字處理、特定運行時的事件循環、線程模型、數據表示、並發性（如果您想做一個多線程版本）等。我的“端口”都不是功能齊全的，但是他們都幫助我整理了上面的一些內容，以及構建工具、打包、依賴項等。

它是核心雲原生微服務的“hello world”，如果你願意的話（而且不必做 REST 或 JSON 的東西）。

一兩個月前，我在 HN 上看到了這個“構建你自己的文本編輯器”[0]，每個人都對它贊不絕口，所以我仔細研究了一下，它真的很棒。學習經驗是無與倫比的。我現在相信“構建你自己的……”指南的想法，我希望這個 Redis 指南和 kilo 文本編輯器一樣好。我肯定會在適當的時候將其加入書籤以進行深入研究。任何其他一流的“建立你自己的”建議將不勝感激。

[0] https://viewsourcecode.org/snaptoken/kilo/

在我為主動性和努力鼓掌的同時，我想敦促作者諮詢一位優秀的校對員。我只是在第 2 章，但我已經遇到了足夠多的糟糕英語形式的摩擦，讓我望而卻步。我認為內容看起來很棒，所以不走最後一英里並通過消除像這樣的明顯錯誤來讓它真正令人愉快地閱讀有點浪費：

“Redis 是服務器/客戶端系統的一個例子。”