你要用就用，谁也不能拦着你。既然有定论了就不用问问题了，直接发使用经验就可以了。有你这么多时间纠结，别人一两个迭代都做出来了。

所谓的“调用者”不是你们自己做的客户端或者网站？你不能控制用最好方案？就算是第三方的，不用先取到座位号就可以下单？你说 A-1 好，但你也要客户端能输入 A-1 而不是甲 -1 之类乱七八糟的格式，难道就不需要中央控制？

再说速度，demo 或小批量数据当然看不出来 A-1 会比 ID 差，数据量大了数据库的索引就不是摆设了。

Javascript 来写都是有局限的，不可能和原生相比。知道局限并且能接受就 ok。

看不懂他的问卷啊。jQuery heard of/read about: 1.7%，never heard of: 0%。这两个指标不应该是 mutual exclusive 么。

@wdezsqyfw 如果你没有思路，告诉你你也实现不了，问了也白问。Google App Engine 说明不了任何问题，可能只透露他们团队比较熟悉 Python 而已。大部分的后端语言都可以实现类似的功能，没有障碍 － 至少在你遇到快乐的瓶颈之前没有。

与其花费时间在网上搜索别人只鳞片羽的技术栈和空泛的提问，不如沉下心来认真琢磨用团队熟悉的语言和框架怎么实现，然后在实现的过程中再一步步改进。要是这个也有困难，就回过头去先把基础打牢。

@rubyonme 这不就是说的 API 吗。POST, 要求：user token, scene_id, seat_id, 成功就主要返回订单号及付款 token，或者其他附属信息比如电影名字，影院座位号等等方便客户端显示，基本的不就可以了。

@rubyonme 对于生成一个订单来说，座位 id, 场次 id, 用户 id(可能还有其他）是必须的，为了凑齐这几个已经需要好几个 query 了，我觉得不必再增加不需要的东西。

可读当然也是必要的，但你可以把附属的信息比如电影院 id, 名字，电影名字，时间，座位号等等在订单生成时存入订单，这样后面可读可查。

这个不是什么可读性的问题，毫无疑问当然是 ID 了。座位号又不是一个独立的资源，每个电影院都有 A-1。你要传座位号的话就得把电影院 id 一起传，后台再找电影院再找座位号，又慢又麻烦。 前端也会很简单，假设用 jquery, 一个座位一个 data-id, 选中直接发送请求，收工。

@pynix 要挂了才知道原因就没法做优化了。

我之前做过类似的排查，也是内存占用稳定攀升。我的做法是，开一个临时 branch, controller action 结束时查询内存占用（可以调用 shell script)，加入 response（用了一个临时的 header)。

然后做一个 rake task，循环调用该 API, 打印内存占用结果。成功重现内存稳定攀升的 pattern 之后就是一个很好的开端了。

后来一步步排查，遇到可疑的代码就替换或暂时去掉。最后的结果是render file: ..有问题，内存不能去掉。其他团队定期在这里拿准备好的 JSON 文件，之前很小的文件不觉得，后来文件越来越大，造成内存攀升明显。摸索着改为 send_file 后一切正常，再大的文件都不是问题了。

一个进程 2 个 G, 别的都没事，怎么可能是 ActiveRecord 或者 MongoMapper 的原因。再说这么成熟的库，要有这样的 bug, 早就一堆人跳起来了。

认真排查吧，看看这个进程跟别的有什么区别，然后再排除、假设、试验。

@cbdfocus 第二条你的理解是对的。

@cbdfocus @maomaoxgg 根本原因在这里：var a = 3. Javascript 里面 var 定义不管是在什么地方，都自动等同于作用域顶部。所以你看似在代码中间定义了 var, 其实 function sth 一开始就知道 a 是一个本地变量了，a=2 其实改变的是本地变量，并非全局。

所以 coding 规范才推荐把 var 定义放在顶部，以免产生误解。

Variable declarations, wherever they occur, are processed before any code is executed. The scope of a variable declared with var is its current execution context, which is either the enclosing function or, for variables declared outside any function, global.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var

@cbdfocus 刚才那个有问题。

都可以，花一天时间把几个主要的编辑器过一遍，自己喜欢哪个就确定哪个。然后深入研究，不再问问题，不再更换，不再后悔。

"有人说 OC 和 swift 要被砍" 这是什么意思

[[preg, max_right].min, 0].max

没什么好想的，肯定直接用原生的或者原生的子集。不用在这个上面浪费时间。

为什么什么都要求别人放源代码。

按目前需求，多进程肯定是必须的，接口 2 已经阻塞一个进程了，系统无法再接受接口 1 的请求。

不知道你对服务器 B 有没有控制，有控制的话可以改为接口 2 直接 POST 图片到服务器 B, 这样会省一个来回，对接口 1 也没有依赖了。

Heroku 上面放项目不掏钱是不可能的。就算你什么 addon 都不加，免费的 Dyno 也只能做 demo 用，根本达不到生产的要求。早晚都要掏钱，不要被这些细枝末节干扰正常的技术判断。

Gemfile 可以指定文件夹作为 gem 路径。这样你就可以在另一个 Rails app 里面调试了。

理论上应用里面的唯一性检查不是百分百覆盖的，但实际上真正需要用到数据库检查的机会极少极少。

你想一想，假设在一个进程处理相关请求的时间是 100ms, 你能有多少机会见到两个或更多的请求在同一时间段内需要同样的 name 值呢？

这种情况我们还真遇见过，还不是一次两次，以至后端同事讨论要不要加数据库限制。后来发现是前端的一个按钮在按下后没有禁用导致重击，所以在极短时间内有重复内容的请求。前端简单解决后再无此问题。

你可能觉得这样双保险是为了严谨。但严谨也不是免费的。索引要占空间，可能影响速度，还要写 migration。如果每个此类需求都要这么做，需要加多少东西。

再想想，你不一定真的需要这么写。

能解决的问题各个框架都差不多，不能解决的脏活累活还得 jQuery 或者 vanilla 来干。

国内邮箱一概不能用，总有人有办法看你的密码。Gmail 是必须的，嫌翻墙麻烦可以用 outlook.com

工作环境好像很危险的样子。

传统 Rails 方式可以加入 edit 路由，或者其他名字提交 edit 表单就行。

不过最简单就 Javascript 了，监听用户点击'cancel'按钮，preventDefault, 跳出文本框和确认按钮，输入理由，确认后在表单里面加入理由项并提交。后端只需要在 cancel 里面接受 reason attribute 就可以了，无需其他改变。

楼主你既然提出了问题，不妨虚心一点。@lyfi2003 其实已经说得很详细了，但你可能还没明白。这种东西不是关系型数据库的强项，influxdb 或者其他类型的 NoSQL 做这些更拿手。

其实访客统计这种功能有大把的解决方案，免费的，付费的，云的，自己安装的，什么都有。如果不是为了学习或者有特殊的要求，没有必要自己做。

重名、加载顺序依赖，这些都是很丑的。别想着怎么调用 A 的重名方法了，要是 moduleA 和 moduleB 都是你写的，赶紧把它们改了，如果 moduleB 对 moduleA 有依赖，那就把加载 A 的部分放在 B 里面，My 只用加载 B 就行了，这些名字什么的由 B 自己去解决。

另外，mixin 本身也不是什么万能的东西。如果复杂到要考虑的太多，你要想想 mixin 是不是真的适合这个场景。

负责招聘的就打打下手，发发广告，整理一下简历，电话联系什么的就可以了。用 Ruby 开发一般就几个人一个团队，老板或者团队负责人来做决定就行了。要这两个人都没时间没兴趣，那只怕很难找到合适的人。