Tag: 软件

Google 有点东西 👍。

今天试用了一下 Google 久负盛名的 NotebookLM。我觉得这是到目前为止最接近 memex 的产品形态——把文本资料吃进去，通过高效的索引方式帮人类找信息。

NotebookLM 的实现路径是借助 ai 的能力做基于内容的分析概括，对生成的内容给出指向资料的索引。没有那种对 AI 能力过于自信的越俎代庖，还是将人类置于内容（笔记）生产的核心位置。这个路径也一定程度上避免了 AI 的幻觉（具体多大程度还得继续用）。

置于生成报告、音频、思维导图，我觉得这些都是属于锦上添花的功能，对于我来说用处不大，反正我目前找不到使用场景。

NotebookLM 现在最适用的场景，就是需要做大量 paper work 的人了。尤其是研究性的工作。也适合拿来读书。把那种不值得细读的书和文章扔进去，问几个问题就能把握整体思路。生成的素材就是读书笔记。NotebookLM 把笔记也纳入了 AI 的内容来源，方便日后检索。

今天还试了 Google 的 IDE—— Firebase Studio。不过它就属于一眼惊艳，然后一言难尽的产品了。

产品思路不错，借着 VSCode 的壳和生态，整合了 Google 自己的云服务，和 Gemini 的 AI 能力，能实现从开发到部署的一站式服务。

起初想尝试正是因为 Gemini 的代码能力和其他大模型相比，更值得信赖。可能是我的技术栈比较冷门吧，试了很多模型，只有 Gemini 每次的回答都相对靠谱。

我导入了我的 murmurs3 项目，IDE 能自己识别项目需要的插件和依赖，自动生成开发环境。

但是这个识别能力非常堪忧。我的项目技术栈是 bun+sveltekit+Tailwind CSS，但生成的开发环境是 node，插件倒是识别到了 svelte，但是自作主张的给我加了 vue，并且，项目里的其他依赖，对应的插件都没识别出来，最基础的 ESLint、prettier 这种前端必备插件都没识别出来。我只能一个个手动下载。对了，这个插件市场不是完全从 VSCode 搬过来的，部分插件还没有，例如 DaisyUI Snippet。

在我搞定了开发需要的依赖以后，尝试运行项目，发现怎么都运行不起来，好不容易成功运行了一次，点开链接直接报错。

目前不清楚具体原因，从输出的报错来看，应该是由于生成的 Nix 容器环境缺乏 rollup 运行的二进制依赖。但是我一直 bun add 添加依赖也不行。

另外就是 nix 的包管理器，支持的包版本太老了。bun 最高只支持 1.0.13。如果想下载最新版本，就会直接告诉你 AccessDenied。

整体用下来，我还需要观望，如果未来兼容性更好，我会毫不犹豫使用，甚至购买增值服务（看价格和服务内容）。

从写代码到部署不用来回切换，在一个界面里全部搞定，这个远景太诱人了。这种端到端全链条的能力，only Google can do 👍

立一个 flag：什么时候 iPadOS 能跑全功能的 VSCode，我就买一台 iPad Pro。

update：看起来不太可能了。刚刚用 VSCode 打开了两个 SvelteKit 前端项目，代码量都不算大，macOS 内存占用（加上交换内存）能到 22~23 gb。

这两天一直在哔哩哔哩和 YouTube 看各种 iPhone rig kit。相机的仪式感在于他只能记录影像。把 iPhone rig up，等于让 iPhone 变成一台只适合记录影像的专用设备。

小小一台手机，装上兔笼、手柄和滤镜，接上外接硬盘和收音设备，加之适宜的软件，就能拍出「cinematic」的视频。我对此毫无抵抗力。比起「专业」设备，我喜欢将出小巧精致的「业余」设备的潜力，完全激发出来。

我觉得这也是一种「美学」。他的「美」不仅仅在于精巧的外在，也包括物尽其用的美德，和一种一目了然的简单性，这也是一种[2025-03-09_12-42-37|便利贴的哲学]。

专业设备就像一个黑箱，你知道它可以拍摄专业级影像，但你不知道它是怎么做到的——满身的按钮和接口，还有眼花缭乱的菜单——你需要化很长时间学习这些东西应该被如何使用。

手机不一样。你本来就知道手机如何拍摄视频，你只需要花 10 分钟看一条视频，就能学会相机 App 的手动模式如何操作，然后你就可以发挥创造力去 rig up 了，外接设备的多少完全按需选择，丰俭由人。这个发挥创造力的过程也十分好玩

想到这里，我突然明白了 React 为什么能成为前端社区第一组件库。React 就是一个组件库，它需要你选择其他部分，将它们组合成一个前端开发框架。React 在这里就是一部「手机」，它使用起来足够简单，但能力有限，你单靠他很难开发复杂的应用。这时，你就可以选择社区里其他开发者创作出的其他库，组合使用，自己将其 rig up，形成自己的 tech stack。

React 的哲学确实吸引人。

但是现在的 React 及前端社区已经被这种自己动手，自由创造的风气带歪了。一个人一种写法，没有能作为标杆范式的框架，没有强有力的规则约束，包含现在的 JavaScript 语言在内，前端社区已经成为了一个事实上的「屎山」。

Anybox 真是精致又优雅。但是我也找到了它的设计不合理之处。譬如：暂存箱——一个读取用户剪贴板信息的功能，居然不是按时间倒序排列的。

For me, programming has always been more than a skill. It’s a way to explore, to tinker, and to satisfy curiosity. From wires and screwdrivers to apps, the tools have changed. But the impulse remains. That’s why I keep coming back to it. It’s my natural way of interacting with the world.

对我而言，编程不仅仅是一项技能。它是一种探索、思考和满足好奇心的方式。从电线和螺丝刀到应用程序，工具一直变，冲动依旧在。这就是为什么我不断回到编程中来，它是我和世界交互的方式。

来源：Why I Do Programming

软件开发领域的「约定大于配置」也是一种自律是人自由。

所谓约定大于配置，就是库或者开发框架作者强行约束一种使用方式，让使用者尽可能少的对库或框架进行自定义配置，这样所有用户的使用方式就是相对统一的，即使遇到问题，大家的问题也会趋同，可以很方便的在网上找到解决方案。

而且，一般来说，这些经验丰富的库和框架作者，约束出来的使用方式，往往就是最佳实践，对于处在学习阶段的人（比如说我），也能在使用的过程中感受到这种设计的精妙之处，也是一种非常直观的学习方式。

今天切身体会到了前端的困境。

最近在算学用 strapi 做官网。前端还是 SvelteKit + Tailwind CSS，打算用 Prettier 做 formatter，简单搜了一下，发现 Svelte 和 Tailwind CSS 都有官方的 Prettier 插件。

照着教程用 npm 下插件，然后把教程里的配置代码复制到了 package.json。

试了一下，不对，有问题。

搜了一下，然后发现是 Prettier 和原来 Svelte 的 VSCode 插件有冲突，需要到 setting.json 里改 svelte 默认的 formatter。

重试，.svelte 文件能 format 了，但是 .svelte 文件里的 Tailwind CSS 代码没有 format。

又查了一下，发现是 package.json 里插件的顺序不对，Tailwind 的插件必须放最后。

改完 package.json 文件，再重试，这次对了，没问题了。

2 个小时过去了，啥也没干，就反复改配置文件去了。

复盘一下问题出在哪儿？

首先，肯定不是我的问题。我遇到的每一个问题都能在 Google 里搜到，GitHub 里关于前述这些坑，每一个都有时间跨度 2 年以上的 issue，说明不断有人踩到了同样的坑里。

我觉得问题还是出在前端生态上。

其实，从我学 JS / TS 开始到现在大半年时间，我已经接受了每一个项目里都必须存在配置文件这件事。

配置文件没有问题，问题是前端技术栈上的框架和 toolkit 太多了，每一个还需要相互兼容对方的存在，如果不兼容就没法用。这些眼花缭乱的配置项只是为了兼容而存在的折中方案。

这是我在此前学习 Python 的 1 年多时间里，从未遇到过的问题。

前端娱乐圈，名不虚传 👍。

Q：node 和 npm 性能糟糕、功能缺失，还有一大堆设计缺陷，为什么不用 bun 和 deno？

A：为了兼容性。就像人一样，棱角分明的性格固然很好，但是为了把事情做成，总得圆滑起来。

加尔定律经常被引用：“一个有效的复杂系统，总是从一个有效的简单系统进化而来。” 但是，它的推论很少被引用：“一个从零开始设计的复杂系统永远不会有效，你必须从一个可以运行的简单系统开始。”

— Stack Staves

这周重写了本站的暗黑模式与通知，虽然看起来没有什么区别，但是代码逻辑更加简洁合理，感觉自己又进步了 👍