返回首页
最新
我知道这让很多人感到害怕，但你可以通过质量保证（QA）、评估、发布质量门槛等方式来控制这些问题……我知道短期内我们可能会出现更多的bug，但从长远来看，不关注代码的方向是否是我们应该追求的正确道路呢？<p>几位重要的开发者已经转向了这个新思路，他们都是在生产级项目中工作的（一个例子是Antirez，他刚刚发了一些推文，激发了这篇文章的灵感）。
嗨，HN，我是来自布达佩斯的软件工程师Gábor。
我花了将近十年的时间设计、构建和维护分布式系统，深刻理解了为什么很多人将软件架构定义为“后期难以更改的东西”。改变服务边界、通信协议或序列化器既耗时又风险高。在过去的几个月里，我一直在构建Itara，这是我为缓解这一痛点所做的尝试。
Itara将当前分散在代码库、配置和基础设施中的软件拓扑集中到一个专用的可执行层中。这个专用层将拓扑描述为一个有向图，其中节点是系统的组件，边是它们之间的连接。边具有连接的所有属性，比如使用的传输方式、序列化器、故障处理策略等等。共址组件，即在同一进程中运行的组件，通过直接连接进行建模。
这让我准确地绘制出我的拓扑图，使我能够在不改变业务代码的情况下更改拓扑，并将通信逻辑与业务逻辑分开，同时仍然能直接控制配置，避免网络误区。
在Itara中，每个组件由其他组件可以构建的API和实际实现业务逻辑的实现部分组成。事件驱动设计通过专用事件API得到支持。
对于每个部署单元，接线代理在启动时运行，以准备根据接线配置指定的通信通道。这些通道实现组件API，并被应用程序像常规接口一样使用。除了结构可观察性事件外，没有运行时开销，因为接线代理在启动后会退出。
该项目旨在实现语言无关性。目前的实现支持Java，并且Rust实现处于概念验证阶段。
我收集了一些常见问题及其答案，放在了FAQ中： [https://github.com/itara-project/itara/blob/main/docs/FAQ.md](https://github.com/itara-project/itara/blob/main/docs/FAQ.md)
我准备了一个演示，展示一个由5个组件组成的订单处理系统，其中一个组件是用Rust编写的，通过HTTP和Kafka事件进行通信。演示表明，要更改拓扑，只需更改接线文件和Docker Compose文件，应用程序代码可以保持不变。演示中还包括一个故意不稳定的传输，以展示故障处理。追踪信息使拓扑变化直接可见。
演示链接：[https://github.com/itara-project/itara/tree/main/demo](https://github.com/itara-project/itara/tree/main/demo)
我非常期待您的反馈！这是否解决了您遇到的问题？哪些方向与您产生共鸣，您认为哪些地方还存在不足？
规范、宣言和架构文档在这个仓库中：[https://github.com/itara-project/itara](https://github.com/itara-project/itara)
我在GitHub上尝试了一个新的代码库，进行了一次新的尝试，开发一个类似于C++的程序，但具有与Rust相同的特性。这个项目只是作为一种业余爱好进行的。
网址：
https://github.com/juntz-g1thub/UltraCpp.git
我有几台运行 Debian 12 的服务器，正在使用 MariaDB。这些服务器的配置是将 bind-address 设置为 127.0.0.1:3306，以确保所有数据库连接都是本地的。
今天我升级到了 Debian 12.15，重启后检查了开放端口，以确认所有服务是否正常运行。
令我惊讶的是，MariaDB 不再监听 127.0.0.1:3306，而是有一个 "init" 在 :::3306 上监听。
看起来默认配置已经更改为使用 Systemd 套接字。我想这也没什么问题，但默默地让你的数据库服务器对整个互联网开放，听起来并不是个好主意。
所以，提醒一下，如果你仅依赖 bind-address，请确保重新配置 mariadb.socket 设置。
几年前，我为 Prusa MK4 制作了一个笔绘图仪附件（<a href="https://www.printables.com/model/827264-pen-plotter-attachment-for-prusa-mk4" rel="nofollow">https://www.printables.com/model/827264-pen-plotter-attachment-for-prusa-mk4</a>），当时我没有好的方法将艺术作品转换为 G-code，因此这个项目搁置了一段时间。
最近，我想再次尝试线条艺术，并制作了一个小型浏览器应用程序以简化这一过程。由于 2026 年的智能 AI 工具相当上瘾，这个项目很快发展成了一个更为复杂的东西——一个集成的浏览器 CAD/CAM 系统，专为笔绘图仪设计，涵盖从导入现有艺术作品、从零创建艺术作品、准备绘图到硬件集成的所有内容。它还包括一些独特的功能，比如用于海龟艺术的 Logo 解释器和用于手写合成的 Graves RNN。此外，除了能够模拟笔绘图仪的 3D 打印机外，它现在还支持基于 EBB（AxiDraw）和 GRBL 固件的实际笔绘图仪，通过 Web Serial 进行连接。
如果您拥有 AxiDraw 或 GRBL 绘图仪，我非常希望您能试用一下并提供反馈。由于我没有这些设备，所有测试都是在 STM32 硬件模拟器上进行的，因此我不确定它在实际绘图仪上的表现如何。
源代码和文档可以在 GitHub 上找到：
<a href="https://github.com/tibordp/kurvengefahr" rel="nofollow">https://github.com/tibordp/kurvengefahr</a>