【科技新聞】毛氈


毛氈
Felt

評論

登陸頁面有十幾個使用 OpenStreetMap 數據的演示和渲染,但在我打開交互式地圖之前,我在任何地方都看不到一個歸屬聲明。

即使是渲染圖和圖片也需要署名。

我對毛氈感到興奮。 (以及任何前來參加比賽的人。)

這主要是因為我認為(他們也必須這樣做)“製作地圖”是每個人都會做的事情(在我們的頭腦中;口頭上;在廢紙的背面;在隨機的汽車地板紙板上釘在路標上),但很少有人能輕易做到- 可訪問的軟件工具曾經試圖以數字方式促進。

我主要對他們創建的用戶體驗感興趣,以將我們的“人類影響”添加到“現有”地圖(如註釋、相關點、線、方向)。我真的被它吸引了。

他們將大量精力投入到事物的數據層方面,考慮到復雜性,我認為這是令人欽佩的,而且似乎很成功。我不確定人們會如何使用這些東西,因為我認為我們的思維導圖通常不需要額外的數據。

我還要補充一點,他們精心策劃的一組示例使用是一個很好的模型,用於向人們展示如何使用他們可能不知道該怎麼做的產品。

胡說些什麼!看完這篇就放棄了。

""" 典型的互聯網地圖在每次平移和縮放後需要 30 多秒才能加載 """

什麼典型的地圖在談論?


Bun:用 Zig 編寫的快速 JavaScript 運行時、轉譯器和 NPM 客戶端
Bun: Fast JavaScript runtime, transpiler, and NPM client written in Zig

評論

一年多前我開始構建 Bun,大約 20 分鐘前,它處於公開測試階段

我很興奮的一件事是 bun install。

在 Linux 上,它為簡單的 Next.js 應用程序安裝依賴項的速度比目前可用的任何其他 npm 客戶端快約 20 倍。

 hyperfine "bun install --backend=hardlink" "yarn install --no-scripts" "npm install --no-scripts --ignore-scripts" "pnpm install --ignore-scripts" --prepare="rm -rf node_modules" --cleanup="rm -rf node_modules" --warmup=8 Benchmark #1: bun install --backend=hardlink Time (mean ± σ): 25.8 ms ± 0.7 ms [User: 5.4 ms, System: 28.3 ms] Range (min … max): 24.4 ms … 27.6 ms 76 runs Benchmark #2: yarn install --no-scripts Time (mean ± σ): 568.4 ms ± 15.3 ms [User: 781.6 ms, System: 497.4 ms] Range (min … max): 550.8 ms … 604.5 ms 10 runs Benchmark #3: npm install --no-scripts --ignore-scripts Time (mean ± σ): 1.261 s ± 0.017 s [User: 1.719 s, System: 0.516 s] Range (min … max): 1.241 s … 1.286 s 10 runs Benchmark #4: pnpm install --ignore-scripts Time (mean ± σ): 1.343 s ± 0.003 s [User: 601.3 ms, System: 151.6 ms] Range (min … max): 1.339 s … 1.348 s 10 runs Summary 'bun install --backend=hardlink' ran 22.01 ± 0.85 times faster than 'yarn install --no-scripts' 48.85 ± 1.51 times faster than 'npm install --no-scripts --ignore-scripts' 51.99 ± 1.45 times faster than 'pnpm install --ignore-scripts'

過去幾個月,我一直在關注 Jarred 在 Twitter 上的進展,他分享的各種性能基準確實令人印象深刻:

https://twitter.com/jarredsumner/status/1542824445810642946

很容易將其視為“另一個 JS 構建工具的東西,為什麼我們需要更多這樣的眼球”,但我認為這值得一看——關注性能方面付出了多少努力真的很有趣。

如果有一條評論或推文讓我關注他,那就是這個 [1]

“1ms 對計算機來說是永恆的”

您最後一次聽到 Web 開發人員、前端、後端或 Web 工具開發人員這樣說是什麼時候? [2] 總是,哦,網絡延遲占主導地位,或者數據庫響應時間占主導地位。沒關係,它只有十分之一秒(100ms)。 TM夠快的

[1] https://twitter.com/jarredsumner/status/1477775398700158980

[2] 實際上,Nick Craver 在他的 StackOverflow 時代做了很多事情。


荒謬的電車問題
Absurd Trolley Problems

評論

這種突出了電車問題的微妙交互設計或用戶體驗組件。

電車問題的一部分是在行動或不行動之間做出選擇。但是這些問題,或者至少是第一個問題,有兩個按鈕。

所以你要做出選擇。是的,有些人可能會認為這是技術問題。但是,如果您將“什麼都不做”選項放在計時器上怎麼辦?

如果你把它變成一個異步的“今日問題”會怎樣。一天結束時沒有任何動作會觸發什麼都不做,等等。

許多很酷,有趣的設計選擇。有一個未說明的微妙最後通牒隱藏。在這些問題中,但仍然很酷。

對不起,搞砸了。

20級很奇怪。這是讓手推車正常運行(“排放二氧化碳,在 30 多年的事故中造成 3 人死亡”)或將其撞到磚牆並退役之間的選擇。出於某種原因,更多的人選擇了後者。所以,他們只是不喜歡公共交通?當每個人都改用汽車時,排放和死亡率如何?

去展示一個問題的上下文和確切的措辭是多麼容易影響人們的意見。


留言討論區