既然是找存在感，你何必还想着喷他？无视就好了啊

单身狗运算符，没记错的话是 2.3

Rails 的 where 方法最终是生成 sql 查询语句执行的，所以只要是 sql 支持的方法还是可以使用的，例如想要在查询时忽略大小写：

TradeMark.where('lower(name) = ?', name.downcase)

https://guides.rubyonrails.org/active_record_migrations.html#creating-a-migration

增加索引列用于查询就是挺好的方案呀

如果说通过匹配身份证号，还勉强可以完成出生年月、性别的查询，要直接通过拼音查询数据库的中文汉字，还真想不到具体的做法

但是即使有，也不建议在查询过程中引入过于复杂的逻辑而消耗性能，毕竟谁也不愿意在查询的时候等很久，对吧

大概只是开发者的习惯吧，你可以查一下 rails 文档：https://guides.rubyonrails.org/active_record_validations.html#conditional-validation

说一个我自己在实践中使用 GraphQL 的感受

先说结论：如果是应用在完全公开的，仅提供查询功能的接口上，且前端同事明确的知道自己应当如何使用 GraphQL 的情况下，是完全 OK 的。

1. 权限控制问题： 使用 GraphQL，权限控制（大概）只能做在资源侧，当面对各种资源嵌套调用的时候，权限控制的实现简直是个灾难。

2. 查询复杂度问题： GraphQL 可以自定义查询条件，如果不对查询复杂度进行约束的话，你无法想象前端会写出一个多么复杂的 query，由此还可能引发内存泄漏问题，最后他们还会怪你性能做的不行。

前两年被朋友种草 UHK，墙裂推荐

个人经验：使用 JWT 的时候，最好要声明 exp 时间，这样可以保证时效性；另外再处理好有效期内的唯一性，避免重放攻击。这样整体就比较安全靠谱了

写在一起没有什么弊端，但是部署在一起有你提到的，例如性能差异、访问控制等问题

所以把同一套代码，按角色分开部署，并通过路由分流到对应部署中就好了呀

可以准备一个 Excel 模板，在模板中构造好你需要的下拉选项

是啊，程序员大概多少都有点强迫症吧

看到提醒就会回复啊

既然抽不中还要来当分母，稀释别人的中奖概率，太坏了，不如直接下单

#13 楼 @huacnlee 我觉得 11 楼的建议不错，我也想听听这个故事

#2 楼 @hging 还好吧，该回调的逻辑逃不了啊

可以考虑用状态机来处理订单状态的迁移，并且每次状态迁移都是可以触发回调，你可以在回调里写自己的逻辑。 去看看 aasm 吧

#10 楼 @hging 嘿嘿，被鄙视了吧

#23 楼 @luolinae86 差别很大啊，intel 的是通过传感器识别，大疆的纯粹通过摄像头的画面捕捉啊

#4 楼 @zhaozijie 子杰还在跟他们的项目吗？

不可错过的好公司，这里的大牛都很随和，可以学到很多！

@hging

#18 楼 @roceys 你是有多无聊，翻到这么久远的帖子

A.joins(:cs).where(cs: {id: [c2.id, c3.id, c4.id]})

这样子应该可以

#6 楼 @hging 雷锋

#7 楼 @bright 不需要啊，controller 是所有请求的入口，不需要对系统外部开放的 model 可以不用 controller，例如：多对多的中间表 model；相对的，也不是每个 controller 都需要 model，刚刚说的 session 就是一个例子。具体还是看项目需求吧，多接触接触，不难理解的

#4 楼 @bright 不要把资源仅仅理解成 model，虽然我一开始也是这么理解的，举个简单的例子：通过 session 处理用户的登录退出操作。用户登录则 post，创建 session；用户退出则 delete，删除 session。然而你并不会为 session 创见一个 model

每次需要使用稍微复杂的命令行都要 Google，是时候亡羊补牢，点击技能点了 ＋1