前端是不是没学过 Promise（手动狗头）

没必要啊 重复造轮子。。。

不是代码省略的问题 是 foreign_key 的使用场景问题 foreign_key 是个强约束的限制 主要作用是保持数据的一致性和完整性 你需要自己判断是否需要外键作为约束

确实厉害

unless 的逻辑很顺啊

1. 干啥啥啥 除非 怎样
2. 干啥啥啥 如果 不怎样

明显 1 逻辑更通顺吧。。。

APP 中加个 HTTPS 证书验证就能防止 proxy 类的解密了

楼主的问题其实是个业务问题 再严密的网络传输也会有数据被监听的可能 极端情况就是电信机房拿着你 HPPTS 的证书就可以镜像你的流量（当然这个有判头）

这个问题要拆解一下，问题 1 是 如何确保传输过程安全 问题 2 是 如何反爬 这是两回事儿 这里就不提 CSRF 了 跟楼主的实际问题不符

问题 1 用 token+HTTPS+APP 中自己做证书检验 就可以保证传输安全

问题 2 强制手机号码登录 记录访问日志 到达一定访问量直接 ban 设备 或者 不用手机号码登录 用设备码等唯一标识 从业务角度反爬 而不是从安全角度 有 N 种手段能让服务端接口觉得“请求”是从正常 APP 发过来的 所以从安全角度只能提高防护的上限 从根本上无解（魔高一尺道高一丈的逻辑）

按我自己来说 还算活跃吧 就是不怎么发声了

哈哈哈哈哈哈

命名规则神似当年 GitCafe

你说的就是我说的 你这就是单独的 queue 不是混合的 queue

在高并发的时候会遇到 例如某个任务要保证 20 个并发 同时不能靠优先级只跑自己的 worker 其他的 worker 也得进行 混合的 queue 并不能保证单独某一个 worker 的并发是稳定的

如果不做反爬和资源权限控制 UUID 只能是增加爬虫的复杂度 并不实际解决问题呀

看来好多人都记着他。。。

确实 k8s 更好一些。。。

是不是分层是按你复杂度来定的 比如有些跨很多模型才能实现的功能需要复用（当然基本不会出现） 比如你需要提供不同版本的 API，他们之间有共同的功能

对于做逆向的人来说 代码防护永远都有办法解决 所以你的思路肯定也不是保护代码 应该从业务上解决问题 例如：服务部署需要每天向你的在线服务申请一个秘钥 所有数据根据日期和秘钥做加密解密 服务到期以后就没有秘钥不能用了等等等等 对于业务增加不了多少处理时间

HTTParty yyds

哎

说 ruby 性能差的人 用其他语言性能也不会好到哪儿去 web 服务最大的瓶颈在 IO 跟语言的关系很小 IO 的处理更多不是依靠语言

写的很棒

我自己的经验是：

想明白解决什么问题、要什么人

把面试者当朋友，这样即使最后不是你想要的人，面试者也能收获价值没有浪费时间

如果真不行，买卖不成仁义在，面试者只是当下不合适而已，不代表未来不行

是 也挺好

这种加密就应该两个服务拆开 应用服务根据自己的秘钥找加密服务要数据 加密服务根据自己的秘钥和应用的秘钥加密解密存库 加密服务在堡垒里 多一层安全保障

这样应用的服务器被破了也不会影响数据 因为大部分场景都是应用服务被破了 然后代码和数据库连接都被拿到了 不太会出现单破数据库的情况了

用了 5 年 cherry 线性灰了 声音一点都不大啊 因为只需要按下 3mm 就可以触发了 并不会触底 基本没什么声音

还有一个“隐患”就是 json 数据的存放对于后续的数据分析并不“友善”需要数据库支持或者一些插件才能做到 json 直接查询分析 可能会给未来挖坑~ 虽然现在没有需求~

从你遇到的问题来看 其实不是结构化数据存取的问题 就是数据模型的设计问题 体现直接绑定支付宝的关联关系本身就是一个错误的实现方式 必须要创建对应的“镜像”数据来存~

或者你是当成个引子引出你想说的~

用了 6 年 macbook pro 2014 13 寸 8G 从 rails 2.0 写到 rails5.0 去年因为很多 apk 太大了 jadx 内存不够使了 才换了 16G 的 16 寸 mac

不错 帮顶

@kevinyu 你们公司美女好多...

vscode 属性名全靠肌肉记忆

太重了吧

aasm 更适合需要特别严谨的状态机的场景 因为他对状态机的控制非常严格 带来的问题就是太重了 如果只是 待审核 审核通过 审核不通过 这种单向的状态机 不如 enum 自己写一个来的轻快