我感觉可能只是单纯需求比较少，大部分 ruby 的场景可能用不太到

不行吧，看源码抢锁失败会直接报错，如果把默认的 -e 删了，那不是其他机器 migrate 还在进行，这台机器的新代码就跑起来了。

rails/activerecord/lib/active_record/migration.rb

看源码这里如果强锁失败会报错的，不会影响容器启动吗？

改了一下描述，不是说这个时间，而是说部署的时候，rails 默认是启动容器的时候运行 migrate，分布式部署多台机器就会运行多次，如果凑巧同时运行了是不是存在风险的

但是分布式部署上多台机器会执行多次吧，可能会出问题

应该是 rubymine

请教一下是用的 SPA 吗？因为目前 rails 这套 esbuild/webpack/rollup 想做到给不同的页面加载不同的 JS 文件（懒加载）好麻烦，得一个个文件路径手写到 js 编译工具的配置里面。

还是说所有 js 都放一起，不做懒加载。

现在难受的点是，用了 stimulus-components，stimulus 配合 importmap 的自动懒加载就没了

仔细想了一下，确实除了自己的项目，在工作中从来没用过外键约束，数据库层面最多用一个 uniq 索引，甚至 null false 都很少用，很久之前还觉得这样不优雅，现在看确实能避免很多不好发现的问题 当然另外一个原因是微服务都拆成零碎了，业务最核心的四五张表分别在三个部门的三个数据库里，根本没办法 join

这个有点太简略了 一个方法还好说，有时候根本不知道用什么，只知道需要某种行为，比如我需要在 controller 里面调用 dom_id，我是不知道 controller 里面就有 helpers 这个方法，跟别说去查询了

某互联网大厂，当然技术栈并不是 ruby，只是讨论一下用 db 做缓存这个做法

我目前的业务不能让任何 C 端流量打 DB，峰值几十万的 QPS 打到 DB 就完蛋了，感觉 QPS 不高的项目可以用这个

哦哦，他的意思是是 db 用的是磁盘，redis 用的是 ram，我还以为他会在本机再做一层基于文件的缓存，和 db 组成多级缓存

SolidCache 是多级缓存吗？试了一下会存到 DB 里面去，但我看文章里说的又是磁盘缓存

试了一下 propshaft，js 代码的相对路径引用挂掉了，得换成 import map 的 pin_all_from 'app/javascript/src', under: 'src', to: 'src'，不过改造之后所有的代码提示都没了，得整个 jsconfig 让 ide 识别 import map 的这个 alias

{
  "compilerOptions": {
    "baseUrl": "./app/javascript",
    "paths": {
      "src/*": ["src/*"]
    }
  }
}

听说违规被查到要罚好几万

其实我是想喷他，并不想去改……改了助长这种人的风气，lint 检查都通过了，这种人纯属找存在感。

Go 一般没什么骚操作，就那几个普通用法，强调简洁（简陋），所以没什么太多关于语言本身的讨论。反而你看现在很多新的开源软件，一翻 Github 都是 Go 写的。

大概率是 mac，互联网基本都是发 mac

很多库都只能 class 转 json，但 json 转 class 的能力都缺失

主要太大了，梯子有流量限制的，到时候下点依赖就炸裂了，特别是 node_modules

还行吧，基础功能都有，不要依赖一些骚操作一般没啥问题，作者好几年前确实说自己没精力维护了

js 这边其实很多东西很早很早就有了，而且也经过了超大型项目的验证，比如什么 express，koa，eggjs 之类的。

但一堆人总觉得这些老东西有问题，我们要重新设计“现代化”的 XXXX 库，三年两载就出来一堆新库，与之相伴的还有造一堆新概念。最后大家兴冲冲地跑去用，结果发现一堆问题 还真不如用以前的东西，至少真的能完成任务。

还是老一点的东西好用，这个 prisma 一堆人推荐，结果 issue 长期两三千个，碰到问题就 gg。node 这边老牌的 sequelize 和 TypeORM 都挺好的

去年的 ISSUE，到现在也没啥声音 https://github.com/prisma/prisma/issues/17136

确实不如一些用的多的语言方便，比如 Go、Node、Java 基本下载一个包解压就好，最多再配一个 PATH 就能开耍了。

从成本的角度来看可能就是因为用的人少，没什么新人，所以社区也不太 care 这方面吧。

感觉你没太看明白我的意思 我说的是控制粒度的问题，form 粒度太粗了，需求稍微一复杂就顶不住了

如果考虑后续迭代，其实你的思维更好一点，比如现在是回车搜索，后续如果需求变更，变成了「一边输入一边展示实时搜索结果」，用 form 和 turbo 这一套就很痛苦了。

甚至要求可能还更多，比如节流、防抖、loading 状态展示、如果第二个请求的 response 比第一个 response 先返回了怎么办？这些用 form 表单就没法做了，只能在 js 的基础上进行扩展。

试了一下，确实可以，有的库还要再装一个 postcss

阁下找工作的时候不希望先知道这个组的 wlb 情况吗，还是说阁下就是卷王之王