返回首页
最新
随着最近添加的/hooks和/agents，您目前的设置是什么样的？您有什么推荐的最佳实践吗？
嘿，HN，
我是一名对弹吉他充满热情的软件工程师。（[ivanhsu.co](https://ivanhsu.co)）
在软件行业，我们使用像Markdown和Mermaid这样的简洁文本语法来处理复杂的布局。这让我们能够专注于内容本身，并快速生成格式优美的文档。
乐谱和和弦图不就是音乐世界中的另一种文档形式吗？
这就是我创建Cord Land的原因！[https://cord.land/landing](https://cord.land/landing) 这是一个可以快速生成乐谱和使用纯文本绘制和弦图的网站。
更棒的是，它可以自动转调歌曲！只需写入一个调，就可以瞬间转换为您想要的其他11个调。
我实现了一种新的语法，称为Corduroy，这是一种专为吉他手设计的ChordPro语法扩展。除了在歌词上方显示和弦名称外，您还可以自定义和弦图。例如，`%x32o1o%`将自动绘制一个C大调和弦在第一位置！
欢迎在这里试用：[https://cord.land/landing#playground](https://cord.land/landing#playground)
有关更多使用细节，请参考：[https://cord.land/tutorial](https://cord.land/tutorial)
“Cord Land”这个名字来源于“Cord”和“Chord”的同音词，代表和弦。
让我们在工作之余也保持对弹吉他的热情吧！
Ivan Hsu
嗨，HN，
我想分享一些我在过去几个月里一直在研究的内容，这可能对与分布式架构（例如微服务）互动的开发者们感兴趣。
我是一名后端开发者，在我去年的9到5的工作中，我们开始构建一个分布式应用——我的意思是两个或多个服务通过某种消息系统（如Kafka）进行通信。这是我第一次接触分布式系统。在阅读了Nathan J. Smith关于结构化并发的精彩文章后，我开始注意到这种基于消息的通信所面临的挑战与并发编程以及之前的GOTO编程之间的相似性——远程操作、复杂的故障追踪、同步问题等。我开始怀疑，如果症状相似，根本原因和解决方案也许也会相似。
这促使我设计了一种我称之为“结构化协作”的东西，基本上就是将结构化并发的规则应用于分布式系统所得到的结果。事实证明，这样做有一些相当强大的后果，包括：
- 几乎消除了由于最终一致性导致的竞争条件
- 允许你恢复类似于分布式异常的东西——堆栈跟踪和跨服务边界的堆栈展开等效
- 使得对整个系统的推理变得更加容易
我整理了三篇文章，解释了：
1) 什么是结构化协作（[链接](https://developer.porn/posts/introducing-structured-cooperation/)），
2) 一种你可以实现它的方法（[链接](https://developer.porn/posts/implementing-structured-cooperation/)），以及
3) 为什么它有效（[链接](https://developer.porn/posts/framing-structured-cooperation/)）。
我还整理了一个用Kotlin实现的文档齐全的POC（概念验证）实现，叫做Scoop（在标题中有链接）。我想你可以把它称为一个编排库，类似于Temporal（[链接](https://temporal.io/)），不过我想强调的是这只是一个POC，并不适合生产使用。
我希望能与社区讨论这个想法，看看大家的看法。如果这被证明是一种有用的做法，我会尝试推动在现有库中实现类似的东西（例如前面提到的Temporal、Axon（[链接](https://www.axoniq.io/products/axon-framework)）等——如果你知道其他适合的库，请告诉我）。正如我在文章中提到的，由于技术生态的异构性，我不确定实际构建一个库是否是个好主意，就像构建一个“结构化并发库”并没有意义一样，因为“并发”有很多实现方式。相反，我试图构建一个类似于“参考实现”的东西，供其他人作为构建自己实现的跳板。
除此之外，我认为这也具有教育价值，我尽力让所有内容尽可能易于理解。我认为一些有趣的内容包括：
- 在Postgres之上实现分布式协程
- 同时具有反应式和阻塞实现，可以作为新手学习反应式编程的资源
- 我记录了使用Postgres作为消息队列时出现的各种有趣问题（特别请参见[链接](https://github.com/gabrielshanahan/scoop/blob/09db323bf6c8a72ca34b50392928db13f80dcc15/src/main/resources/db/migration/V2__create_message_event_table.sql#L20)和[链接](https://github.com/gabrielshanahan/scoop/blob/09db323bf6c8a72ca34b50392928db13f80dcc15/src/main/kotlin/io/github/gabrielshanahan/scoop/blocking/coroutine/structuredcooperation/MessageEventRepository.kt#L676)）
请告诉我你的想法。
嗨，HN，
我是CR(D) Wizard的创作者。我想分享一个我一直在开发的项目，旨在解决我在处理Kubernetes时遇到的一个个人痛点。
在使用自定义控制器时，我经常发现自己在不断运行kubectl describe并试图理解庞大的CRD YAML文件的结构时失去上下文。
CR(D) Wizard是我对此问题的解决尝试。它是一个用Go语言编写的单一二进制文件，能够连接到您当前的kubeconfig上下文，并提供两个界面：
1. 一个终端用户界面（TUI），可以快速检查而无需离开命令行（使用Bubble Tea构建）。
2. 一个基于Web的仪表板，提供更直观的概览（使用Next.js构建）。
其核心功能包括列出所有CRD，探索其关联的自定义资源，以及最重要的，将CRD的OpenAPI架构呈现为干净、易于阅读的文档，直接在用户界面中显示。
这是我的第一个发布候选版本（v0.0.0-rc1），所以它非常新。我希望能从社区获得反馈、批评和想法。目标是为开发者和SRE提供一个简单、零依赖的工具，以便快速了解他们的自定义资源。
感谢您抽出时间查看。如果您有任何问题，我很乐意回答。