RubyConf China 2024 参会报告 - Day 1

Rails + Next.js：一种提升开发者和用户体验的开发架构范式

Rails 写后端非常爽，但是写前端就很痛苦，于是拉上体验更好的 Next.js ，直接有完善的组件、IDE 和社区支持，组合成 Next.js 代理 API 请求到 Rails 的架构。

演讲者还提到一个好处，就是 Rails 基于 cookie 的 session 管理非常完善，通过这个架构就以重用这部分，而不需要搞什么 JWT token 。但是从演讲里看，Next.js 和 Rails 之间交互也没特别方便，例如 Rails 要关掉 CSRF token 之类的东西，这反而可能被利用。

这类涉及前后端开发的问题，肯定又扯出前后端分离、团队搭建的问题。我自己很久没写前端了，所有是偏向于分开的，但是很多 Rails KOL 都喜欢全栈的感觉。

十倍性能提升，原生 Ruby 异步编程机制的思考与应用

这是我挺期待的一个主题，我还做了功课，去看了 Fiber scheduler, evt, async ，测试了用 falcon 跑 Rails 的性能。

演讲者引入异步的原因是因为 LLM API 响应慢，所有如果不异步，那发个 API 请求就要阻塞一个线程，所以异步势在必行，举的例子也主要是用 Fiber 做异步 API 请求，但没细讲（或者本来就不值一讲吧）。演讲者称 LLM 带来了编程范式的转换，其中包括从 CPU 密集型变成了 IO 延迟式，这就有点强行了。后面就是简单的 Fiber 介绍，和 async/await, promise, goroutine 的对比，过于简单，就列表格讲个概念。

我是挺失望的。标题号称十倍性能提升，我希望是有数据支撑的，但是没有。对机制的思考，我以为会讲 Fiber 和 Fiber scheduler 的原理，但这些都简单带过了。而应用也只有 API 请求异步化（还很太快翻过的 concurrency gem 例子，看不清啊）。

就当抛砖引玉吧，最后呼吁大家来共建 Ruby 的 LLM 和异步生态。

SDB: a New Ruby Stack Profiling Tool

一个新的 stack profiler ，在 ruby 进程内通过一个独立线程扫描 ruby 的调用栈，但不获取 GVL 所以基本不影响应用性能。有 data race 的风险，但一点错误不影响性能分析的目标。函数地址和文件名/函数名的关系是通过 ebpf 的 uprobe/uretprobe 记录的，只在方法被定义的时候会记录,不用重复解析。

这个演讲的准备就非常好，提出问题，分析现有方案的缺点，提出改进设计和目标，通过性能对比证明设计的可行性。

下一个十年的 Modern Monolith

这里的 monolith ，是指前后端放一起，所以和第一个主题是类似的，就是为了更好地在 Rails 项目里写前端代码。

通过一个 Todo list 的应用，分别演示 Hotwire, ViewComponent, Inertia.js 的方案。作为 demo 我觉得挺失败的，没有真实演示，只有截图，视图代码也复杂，属于不懂的完全就跟不上的类型，大部分只是浪费时间，还好 Inertia.js 是讲清楚原理的。

最后也有观众问了 monolith 的定义问题，在一个 Raisl 应用里有多个领域的（没拆成微服务），但做了前后端分离还算不算 monolith 。演讲者说是你应用业务逻辑膨胀，这都不能算是技术问题了（大意如此）。

Metasploit 与 Ruby

非常“小众“的主题，演讲者也做了很多准备，PPT 塞了很多内容，,Metasploit 历史，架构，环境，TruffleRuby 什么都有。但是演讲效果不太好，语速飞快，我只能听个大概，感觉内容都是蜻蜓点水，结果就是什么都没学到。

构建基于 LLM 的语音机器人

Demo 效果非常好，也分享了很多工程上的实践，如分层的架构（ ASR + TTS, turn-taking, LLM)，状态的管理，流式性能优化，prompt ，tool calling ，对生成内容的优化……具体还是看回放吧。

激起了我对 LLM 开发的兴趣。

而且看代码其实是 Go 实现的，没有 API 阻塞线程的问题。状态机（演讲者把它叫 Routine ）的实现里，每各状态是一个方法，每 50ms 执行一次，接受参数（例如 LLM 的输出）做逻辑判断，通过返回下一个 Routine 实现状态迁移。有手写 coroutine 的感觉。

A.I-Generated Interactive Narrative Design in Ruby

用 AI 生成游戏剧本，demo 也很有趣，但是为了做出这个效果做了好多工作，都不止是 LLM 的范畴的。

例如实现了一个 DSL （最后是 Blockly 的形式）来写剧本。用 Logica 来验证 Storylet 的逻辑正确性，还能讲一阶逻辑，二阶逻辑。让我意外的是 Logica 生成 SQL 给 PG 查询居然比 Prolog 更快，原因之一是减少了加载数据到 Prolog 的过程，Prolog 有没有类似的 image 或者数据库的持久化功能？

还有白学:)

最后观众讨论的是生成剧情的游戏可能遇到的问题，而且真的有市场吗？