这个以后会被其他人打的。

翻成中文就是：什么？不要钱？

我想请教的也是写上面的问题。比如说你有一个加入购物车的 API, 正常场景就是前端请求，Rails 写入并且返回更新后的购物车。那么在加入了 nodejs 这一层后这类写的流程是怎样的呢？

import { XXX } from 'xxx';' 这种显式引用的写法，每个 JS 的文件顶部一对重复代码，严重违反了 DRY 的原则

全局模块可以用ProviderPlugin定义，不需要重复。

对于局部需要的模块，我是十分喜欢显示引用。至少有了问题可以方便追溯源头。Rails 里面要是加了一些魔法方法，不熟悉项目的话要花好一番功夫琢磨到底是哪个 lib 或者 gem 加入了这些东西。

不可以的，你这么做是开历史的倒车。依靠 global objects namespace, 别的不说，光是加载顺序依赖就够恶心的了。

seajs 没接触过，不知道这个模块定义是不是 require.js 或者照规范来的。如果是，可以直接用 require.js，如果不是可以考虑略作修改用 require.js 或者 CommonJS 系统。

1. 下定决心要重构。要是没有时间没有决心就算了，其实也没有关系，能跑就挺好的了。
2. 把所有这个方法下的代码移到一个单独文件，service object 也好，function 也好（其实最好）。原 class 用@nodes和@interfaces呼叫这个。
3. 把之前的测试移过来，保证通过。要是没有就得写，还得写详细一点。
4. 随便玩，直到满意为止。

可能是我比较挑剔，这里面大部分的例子我看来都是为了写例子而写，既不符合原著 OOP 的风格，也不符合 Javascript 的惯例。看了三分之一，基本看不下去了。

捕获 StandardError 是很糟的做法，用异常来代替流程就更糟。其他的或多或少都有些毛病。先多看多学吧，至少把主要 API 和 style guide 过一遍。不着急总结，更不着急分享。

Built-in classes such as Date, Array, DOM etc cannot be properly subclassed due to limitations in ES5 (for the es2015-classes plugin). You can try to use babel-plugin-transform-builtin-extend based on Object.setPrototypeOf and Reflect.construct, but it also has some limitations. https://babeljs.io/docs/usage/caveats/

@mizuhashi 简单地做我觉得是没有问题，或者是只拉取后端部分大致没有交互的模版都可以。但如果要全局做，还要强交互，那我就觉得很难，而且没有必要，稍复杂一点可能会耦合到不想再看。

真的需要 Python 不妨包装到命令行，或者更复杂一点就加一个服务。两个混在一起不出问题才是不正常。

只有乱乱的人，没有乱乱的代码。什么都可以，精力有限就集中一样。

你真的以为用 Ruby 能写出 Javascript 么？机制都完全不一样。简单的逻辑，套套模版应该是没有问题，稍复杂一点点步步都是坑。与其填这些没必要的坑，不如用合适的工具做合适的事情。

是的。你用了支架肯定要外接，不然手翘着多难受。再说外接键盘比 Mac 的好用。

@cqcn1991 我用的这个http://item.jd.com/1408640.html，很稳定的。

localStorage 等同于客户端的数据库，没有任何清除和过期机制，除非你有代码指挥客户端清除。不熟最好不要碰。用 cookie 就好了，总之是找个地方存然后放到 header，和后端能不能接受 cookie 完全没有关系。

@smartepsh 如果是删除其他的 model, 你可以把它当作一个新增的 batch，都是 POST。

可以做，也不用打破规则。你可以建立一个 batch model 来处理，其中的一个 attribute 接受 array。如果 array 其中一个失败就全部回滚并报错。

干货，赞 👍

对优化版再提两个小小改进意见：

1. init 中有句circle.appendTo($('.main')); 这里先把 circles 的数组做出来最后再一次性插入应该更好。
2. 注意到了你在 updateCircle 里面用到了递归。但是你的递归没有结束条件啊同学！图像显示完了 CPU 还在跑啊！建议加上结束条件。另外最好不用递归，用循环代替会安全和高效一点，因为 Javascript 还没有对递归的优化。

明白了，是反向的。据我所知是没有这样的 gem, 自己手写岂不是比 gem 好。

version 很好啊，很合适的场景。不明白关联的 models 有什么关系，version 不对的时候流程 model 自身都被禁止更新了，更不用说关联的 models 了，不用一个个地过。有什么问题？

不约定你就找老板投诉他

开玩笑的，如果要并行开发，大多数情况下我觉得是可以约定的，这个在很短时间就可以决定，事先有计划也是良好的习惯。如果有实在困难或者后端变数比较多，可能团队也要接受前端需要晚半个或一个周期开发的现实。这样其实也挺好的，很多东西都确定下来了，效率也很高。

前端比后端后完成很正常，很多整合的效果或者 bug 只有在前端做出来后才看得出来。

嫌数据慢有很多种解决方法。比如你可以在本机自己开一个后端的临时 branch, 只要和后端约定好了接口名字和格式，你可以自己在接口里塞入假数据帮助开发。前端也有很多库是可以直接模拟数据的，你都可以考虑使用。全部开发完了你只需要简单更改接口调用到正式版就可以了。

不要想着另起炉灶，重新弄一个后端不是一个不熟悉后端的开发者在玩票级别的时间里面可以解决的。另外两套不同的应用使用同一数据库也不是不行，但里面很多具体的细节比如 transaction, migration 开发维护的成本都很高，我是觉得不值得，随便拼上去能用也只能是个玩具。

我之前用茶轴的，还不错，用多了感觉略有一点费力，声音也有点大。红轴应该会更好。现在用 HHKB Type-S, 就是多了根线，其余感觉更好，不打算再换了。

@zming619 你没有明白我的意思，商品系统做库存的缓存和服务独立一点关系都没有，这个就存在于商品系统自身。

这个只是简单读取，还谈不上高并发。数据主要来自商品信息系统，你在那里做一个库存的 cache 就可以了，一个 id 对应一个库存量，没有就先去库存系统拉。失效按照时间或者库存系统的 enqueue 通知。 按库存排序也不复杂，根据上面的数据再做一个简单数组，失效重新排序，都很快的。读取时按已经排好序的数组的分页，再去数据库或 cache 里面拉具体的商品信息就可以了。

@hooopo 哈哈

@u1453357893 我是觉得没有必要，直接加就可以了。如果你对这个大改动不是很确定，我想最好的决定是推迟决定，直到你被迫一定要决定时再考虑。

你的 cache key 要基于 objects, 这样就是全自动。http://api.rubyonrails.org/classes/ActionView/Helpers/CacheHelper.html

动不动就重构干什么，加一个 boolean field 不就可以了。