有很多值得学习的地方。

Rails 增加一个 service 层就是新建一个文件夹那么容易。Rails 的底层就是 Rack，所以我很好奇有什么是 Rack 能做 Rails 不能做的。

Rails 汇聚了大半个 Ruby 社区的智慧，因为一点点问题就自建框架在熟悉 Rails 的人看来只是因小失大，不过这也是个人自由了。

啊，被 dhh 修了🙁 https://github.com/rails/jsbundling-rails/commit/c7f8f8564436de9529250ef6bbd511568ca6339d

我好奇这个分布式事务实现是在哪一层实施，需要框架层面支持？

这应该要确保数据库保存后才入队。入队之前数据库事务 commit 了没？

哎哟，发现 install 脚本的 gitignore 规则写错了，导致 .keep 文件被忽略了。晚上没人提我就去提个 pr。

错误：

/app/assets/builds
!/app/assets/builds/.keep

正确：

/app/assets/builds/*
!/app/assets/builds/.keep

我觉得就是 cpu 和内存太小，以前不用 docker 我也碰到过过 1 G 内存在编译 gem 的时候卡死。

构建镜像的机器性能要好一点，生产环境资源少就不要放在生产环境编译了。编译好 push 到 registry，然后生产环境拉镜像。

builds 内容应该设置 gitignore，在 assets:precompile 之前编译。

云服务商推 k8s 的一个原因是赚钱吧，如果是买云主机，购买前得看着价格再三确认，如果是 k8s 改个配置就开了一堆计算单元，账单月底见。

另外 k8s 那个复杂度并不适合开发人员管理，面向开发者理想环境的应该是 heroku 或者 DigitalOcean app platform 那样的。国内目前只看见 ucloud 的 cube 有点像，但是它如何更新镜像文档写得不清楚。

投入 docker 我觉得是值得，解决了开发和生产环境依赖一致性和更新的问题。如果是部署在云主机，我相信很少人去更新系统依赖，除非不得已有安全漏洞。

因为 k8s 又贵又难用，我目前一个应用是单机用 docker swarm 部署，装多几台加入 swarm 也很简单。

你看最后一个括号，那才是异常的类

你应该把异常的 message 和类搞混了，终端看到的 SQLite3::SQLException 是 message 的一部分。

可以把完整错误栈信息贴上来看看。

类似 https://github.com/Shopify/ess

@jasl 有研究

是啊。

Stimulus 发布了 3.0.0-beta1，从 commit 来看现在是 DHH 亲自管。最近也打了鸡血似的更新 Rails 的前端打包方案。

https://github.com/hotwired/stimulus/releases/tag/v3.0.0-beta.1

希望早点找到前端负责人，但要找到同样级别的不容易。

双输，但只要 Basecamp 没倒闭，人还可以再招。

是要把 json 内容作为 response 输出吗？把上面的 JSON.dump 内容作为 body，conntent-type 设置为 application/json。

这一看大概是 Hash，里面有的值还是对象（非基本类型），要把它格式化为 json 是什么需求？

硬要做的话：

require 'json'

JSON.dump @env

例如 Github 和 Shopify？

看样子是 Sequel 捕获了 SQLite3 的异常，包裹在 Sequel::DatabaseError 里面再抛出，到用户代码这里能捕获的是 Sequel::DatabaseError。

这是特意把所有可选项列出来了，像 db 那里不需要一次学那么多 db。

所谓前后端分离就是 Rails 只写 API，前端放在另一项目，那么怎么搞都可以。如果想彻底一点，Rails 有个 API mode，不加载 view 和 session 相关的组件。

是的。

Rails 加上 Hotwire 就满足很多场景了。

dokcer swarm 有 rolling updates https://docs.docker.com/compose/compose-file/compose-file-v3/#update_config

配合 healthcheck 可以实现无中断更新 https://docs.docker.com/compose/compose-file/compose-file-v3/#healthcheck

我现在用着 rails-ujs 带的 Rails.ajax 方法，看上去以后 rails-ujs 会被抛弃，到时就转 request.js。

简单方法是先用 form_with 生成一个常规 Rails form（带有 csrf token），然后页面内一段 js 提交：

<script>document.getElementById('form-id').submit()</script>

搜 js 提交可能会查到纯 ajax 然后碰到 csrf token 的问题。

自建建议用 jekyll，横行比较别家静态网站生成器，我也觉得 jekyll 维护最好，文档齐全。

马太效应，强者越强。有这个需求的一开始就会选最成熟的平台，缺少人扩展 Ruby 的这一领域。

link_to method: :post 依赖 Rails ujs，是只能在 Rails view 里面使用的辅助方法。邮件内容在邮件客户端打开，没有加载 rails ujs 的前端库，不能使用。

通常做法是在邮件里写一个对应 get 的页面地址，在这个地址内让用户手动或者用 js 自动提交 post 请求。

新的层在 app/ 下新增目录就行了，app/ 下的目录会加到 autoload 的路径里，lib/ 目录还需要配置。