一周热榜

来自官方Zig源的包管理器，即“zig fetch”，让我感到非常烦恼。我讨厌必须先从一个URL获取项目，然后将代码复制到build.zig中，接着又没有智能提示，只能猜测我需要写什么，不需要写什么。这真是一团糟。 所以我解决了这个问题，构建了自己的包管理器zeP。 https://github.com/XerWoho/zeP 这是一个简单的包管理器和Zig版本管理器。 那么我学到了什么呢？首先，构建一个包管理器需要进行大量的规划。目前我仍处于预发布阶段，这里会有很多重大变化，但我已经做出的许多重大改动让我意识到，在承诺某件事情之前，我必须先停止编程，开始思考。 例如，我的可执行文件命名为zeP，这对Linux用户来说是个问题。他们总是必须输入带有大写P的zeP，这实在令人烦恼。 在此之前，我在zeP中有一个Zig版本管理器，在安装Zig版本或切换版本后，会更改可执行文件的路径。也就是说，每次安装或切换时都会添加一个新路径。 ~/.zig-0.15.1/x86-windows/:~/.zig-0.13.0/x86-windows:~/.zig-.... 可以想象，经过一段时间后，PATH变量会变得多么臃肿，而且不仅如此，这完全没有用，因为我会检查路径是否在PATH变量中，如果在，我就不会再添加它。也就是说（以上面的例子为例），zig 0.13.0将永远不会再被使用，因为它被0.15.1所覆盖。为了解决这个问题，我使用了符号链接。只在主路径~/.local/bin内，zig会在安装和切换之间进行符号链接。 符号链接对我来说非常好，因为我发现了pnpm的工作原理。pnpm使用符号链接，减少了安装、延迟和文件大小，因为有一个主文件夹包含所有文件，并且这些文件在项目之间进行链接。但是，有一个问题。如果你卸载一个包，它会删除主文件夹中的包，这意味着所有可能安装了该包的其他项目将会有一个悬空的符号链接。 再次，解决方案很简单。一个manifest.json。在这里，我们存储所有包及其链接的项目。这个文件会检查链接的项目，如果该包没有链接的项目，才会删除该包；否则，它只会解除项目的链接。 不用说，我遇到了许多需要测试的问题，并且亲自使用zeP。只有通过使用我自己的产品，我才能确定其他人可能遇到的问题。但有些人也提供了反馈，之后我修复了一些问题。 zeP有自己定制的打印结构。它接收数据，然后通过清空整个屏幕再重新打印。这是为了让我可以显示进度条等内容。然而，有用户讨厌zeP会完全占用整个屏幕。因此，现在zeP只会清除自己的行，而不会影响其他内容。 构建一个包管理器不仅需要我这边的测试，还需要社区的反馈。

每次我搜索谷歌时，都会立即被重定向到ChatGPT。他们是不是安装了什么恶意软件？

这带来了什么后果呢？就我个人而言，我曾经在疲惫、匆忙以及处理一些令人厌烦、设计糟糕的软件时，错误地执行了 `rm /bin/<i>` 而不是 `rm ./bin/<i>`，幸运的是，那不是一个重要的系统。我在邮件中也犯过很糟糕的拼写错误，但我侥幸逃过一劫……

在事故发生时，团队往往浪费时间打开10多个状态页面，并争论问题是内部故障还是供应商故障。Depsy 汇总官方供应商状态信号，并返回一个单一的、标准化的 JSON 响应（缓存且快速），这样您的仪表板、运行手册和值班人员可以立即回答“是我们的问题还是供应商的问题？” <p>现场演示</p> GET <a href="https://depsy.io/" rel="nofollow">https://depsy.io/</a> <p>供应商</p> 从常见的关键服务开始：Slack、Salesforce、HubSpot、Cloudflare、AWS、Stripe、Shopify、Twilio、Atlassian、GitHub……目标是覆盖2000个以上的供应商。 <p>我们正在寻找希望将此集成到其事故工作流程中的早期用户（接下来是警报和网络钩子）。</p>