前期真的是最佳策略啊。先人工 后智能。

我还在想下一个公司项目要不要试一下 Java 呢，以前是真的挺讨厌 Java，现在是不排斥也不喜欢。就最近不少前同事跟我说它们加的 Spring 做得不错，开发效率也还行。想着调研试试看。

我应该介于 Type2 ~ Type3 之间吧，但我不会喷 Type1 啊，自己做不到罢了。只能尽量向 Type2 靠拢了。

我也准备用了，有空跟你取取经。

我是打算，

1. 后台业务就继续保持现状，可能会像 @hooopo 所说的看情况针对 LIKE 搜索加索引。
2. App 端业务的所有搜索都依赖 ES 了。客户体验应该会好很多。

主要是搜索依赖的字段太多，索引维护起来有点费劲呢。

是这个理。

没想到支付老司机能亲自回复，荣幸至极，也是缘分啊。我们这边是有一定开发能力的，为了解决二清问题已经换了很多种解决方案，最后才选择汇付。

1. 老实说我也不知道汇付有没有乱收费 ，第一年 5w 我感觉也合理，Mallbook 也要 4w，我们最近聊的另一家也是开价 5w，只要后面流水各方面达标第二年开始就可以免年费了。就感觉还好，没啥意外应该能达标的。
2. 我们后面想接 Ping++，也是跟看中了您说的好处“原生的微信/支付宝 App 支付和 H5 支付接口获得更好的体验”，微信要跳转到小程序支付，还有支付宝通过支付链接跳转支付，体验还是不太流畅。但问题就是沉淀资金不够。完全没机会。
3. 银行的条件是很高，平安银行要求我们一年有 10 亿的流水，还有点距离。最近有个厦门国际银行找到我们，门槛不高，能达标，小银行。不过不知道为什么他们似乎不是银行账户体系的。他们有自己的聚合支付，跟汇付的模式差不多。也是不能走原生的微信/支付宝支付。不知老司机能否给我解解惑？要是这样我们就感觉没太大必要去换了。性价比不高。总体成本也不低。

“可能你当初找汇付的时候没有看到我的知乎文章，汇付的优点我们全有，缺点比他们少。如果技术开发能力不错的话可以考虑切换，直接免年费” ，这个我们感有兴趣呢，不知道是不是可以私聊一下呢？方便的话能否把微信发到我邮箱呢？[email protected]，我们加个微信详细聊如何？

没毛病

哈哈。你这个很有参考价值啊。当然自己不去折腾一下是不知道的。

心态好，头发可浓密了。

哈哈，Ruby 似乎不太好招人，没人愿意学。很难才拉来几个。可能以后会考虑 Go，Java 吧。

您看我行吗？

准备搞视频教程？

哈哈哈，我们还想着要不要 Ruby 转 Java 了。没想到有人愿意转 Ruby。

[email protected]

哈哈

后期有这个打算了。不过现在感觉上容器还有点早。

当然可以啊。

哈哈

魅族还是可以的。

我前期也想停掉。

ubuntu 省事。Github action 缓存比较折腾。不过到了一定地步肯定要弄了。我们现在都自建 Gitlab 了。主要是 Github 之前有段时间网络不稳定，小伙伴建议用 Gitee。我......

招啊。有合适的话

主要看你是哪种类型的缓存，一般的话缓存如果命中了，会少很多数据库请求。

不用啊。开启了就行。

最简单的方式就是，内省一下。

Rails.application.config.cache_store 

有配置缓存存储器就行。如果是 file_store 的话对应的缓存目录下会有缓存文件。没有配置缓存的话，内省会返回null_store

没有啊。回头一起探讨一下？我们刚准备上呢。我也是一头雾水。你的镜像会不会有优化的空间？ 有时间优化搞个轻量级的镜像可能能省下不少网络传输时间呢。

要来份简历看看吗？

了解，这个我权衡一下哈。我们现在的体量，其实我感觉直接用 memory_cache 都差不多了。Redis 就继续用来存 kv 数据。我是打算等上了 k8s 之后再考虑用外部的缓存服务。

>  bootsnap/ -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -nr
 261655 compile-cache
      1 load-path-cache

看着还好，相比起来不算什么。准备把缓存引擎换成是 redis，然后部署脚本多加一个删除缓存的指令Rails.cache.clear 应该能缓解不少。