仔细想了一下，确实除了自己的项目，在工作中从来没用过外键约束，数据库层面最多用一个 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 情况吗，还是说阁下就是卷王之王

登陆解决不了信任度问题，就算不仅要登陆，甚至加上了人工认证某某公司在职，用户一样可以胡编上报

还可以啦，备份一个稳定状态就行，有问题随时回滚

确实性能好，这个不得不说，我这 i7 14700k 编译 ruby 的时候速度贼快。但我个人感觉用 vscode 写 ruby 本身就没什么性能开销 现在 CICD 流程都在云上运行了，本机基本也就跑 IDE，再加上 ruby 弱类型没啥代码提示，IDE 的压力也小的很

我之前也没遇到过，最近刚换了电脑就遇到了

我一般直接 f12 进 console 来转

附上一段对话：

- 用户

我有一系列的服务包，比如internal/service/user、internal/service/blog，但是这样常见的包名很可能会出现重复的变量名。import 时我应该如何重命名它们？

- GPT

在 Go 中，当导入具有可能与局部变量名称冲突的通用名称的包时，常见的做法是使用重命名导入。这有助于避免命名冲突并提高代码可读性。鉴于您的包路径，您可以在导入时重命名它们，以使它们的用途更清晰并避免冲突。

考虑有效的 Go 文档和 Google 的 Go 风格指南中的最佳实践，您可能希望使用包含父目录或基于包功能的更具描述性的名称的命名约定。这种方法可以提高包的作用或相关性的清晰度。

例如：

• 对于internal/service/user，您可以将其导入为 userService 或 userSvc。
• 对于internal/service/blog，您可以使用 blogService 或 blogSvc。

这些重命名的导入清楚地表明了包的用途及其服务性质，同时还防止与可能只是用户或博客的本地变量名称发生冲突。请记住，关键是选择具有描述性且在代码库中保持一致的名称。

- 用户

Go 语言不是建议使用纯小写来命名包名吗？这里为什么要用小驼峰法呢？

- GPT

Go 约定建议使用小写字母作为包名称，这是正确的。但是，这里的上下文是关于导入别名，而不是包名称本身。在 Go 中导入包时，特别是为了避免命名冲突或明确目的，可以使用别名。此别名不必遵守与包名称本身相同的严格小写约定。

effective Go 文档和 Google Go 风格指南重点关注包名称的小写和简洁，但它们对导入别名的规定较少。在实践中，为了可读性，经常会看到使用混合大写（通常称为“驼峰法”或“小驼峰法”）的导入别名，特别是当别名是多个单词的组合时，例如 userService 或 blogService。这种方法有助于在代码中更清楚地区分包的功能。

总而言之，虽然包名称确实应该是小写的，但导入别名可以使用不同的命名样式以保持清晰并避免冲突。

GPTs 有 plus 订阅就可以了，不需要 api key，plus 可以去 appStore 或者谷歌商店美区订阅。