RubyConf China 2024 参后感

Ruby 大会上做的记录太过松散，又懒得整理，就让AI润色（记住这里，后面要考）整理出了两篇 blog。除了自用，也能给没来参会的人了解下大概。

本来这就完事了，但是好奇心驱使下打开了浏览器，谷歌搜索了关键字“2024年 RubyConf China”，发现文章搜不出来，没有被收录进去。倒是发现了别人写的参会报告，点进去一看，内容简活，总结到位，还带了自己的一些看法。

正巧从 SEO 界大佬的分享中了解到谷歌在年初的搜索算法更新中，明确表明不欢迎 AI 批量生成的低质量内容。回过头来看那两篇blog，也不能说质量低，就是内容上更多是表面性的陈述，缺乏个人思考。

于是燃起了熊熊斗志 (`Д´*)9：一定要写一篇被收录的文章！主要还是督促自己多动脑子 _(:з」∠)_

Morden Monolith 和开发架构范式

刚入职头两年，公司普遍还在用 ActiveAdmin 开发管理后台。得益于组件的封装和约定大于配置等特性，创建页面速度很快。不过也因为封装得太过，导致遇到一些个性化需求时就很难修改。即使一个简单的修改显示位置的需求都变得很难突现。后来我们把管理后台也分离出来，这就要求我们多维护一套用于数据交互的接口，处理用户 Authentication、跨域等问题。不过这次架构转换成本不大，公司本来就有一套处理用户端的，照搬过来就行。

会上学到了一套新的前后端分离的解决方案：利用 Next.js 请求转发技术实现登录，实时数据订阅等功能，而不需要额外维护一套接口和 JWT token 信息。这的确能帮我们减少一部分工作，不过也可能引入 CSRF 跨站伪造漏洞。这也不是不能解决，要么还是使用 JWT，要么自己维护 CSRF Headers。暂时只能想到这些 _(:з」∠)_

接着，噔噔噔！一个既不会产生前后端分离，又能结合使用任何熟悉的前端框架的现代单体架构 Rails + Enertia.js 出现了。一个很完美的开发架构不是吗？不过它也有不适用的场景，比如 Inertia.js 不支持服务端渲染，不适用于 SEO 优化应用。所以还是根据实际业务情况选择合适的架构吧。

TailwindCSS 框架

会上被安利 TailwindCSS 框架之后，发现公司已经有很多项目在用这个工具了。上官网看了下，发现只需添加 class 就能用上封装好的样式，真的挺方便的 ｂ( ￣ω￣)ｄ。

Ruby 异步编程

类似 Vue 中的 Promise，Ruby 也可以实现异步并发操作，比如用于速度比较慢的 LLM 查询、IO 存取等。Rails 7.1 在 ActiveRecord 中扩展了 async 异步查询，用多线程实现的，与原生 ruby 异步机制不太一样，ruby 用的是 Fiber 纤程机制。后续再出篇两者的比较 _(:з」∠)_

生产事故排查

很认同演讲者的观点：先恢复服务，再排查根因。

遇到生产问题时，我总会特别紧张，急着找到原因然后修复它。这是大忌来着，先不说紧张会影响大脑思考，难以客观排查问题，最夸张的时候脑袋真的是一片空白，稍不慎还容易引入新的 bug。还有一些隐蔽的问题，比如 OOM 也不是说一时半会就能找到原因的。

最后提到自动化排查问题的实现，这个构想不错，不过如果能举例说明下就更好了。

先到这里吧，最后留一句勉励自己。─=≡Σ(((つ•̀ω•́)つ

多听、多看、多学、多思。(๑´ㅂ`๑)