@chiangdi 基于类的面向对象语言中，所有对象都得属于某个类别，你得先定义类然后再去“生产”对象。哪怕这个对象只是临时用用。基于原型的语言我不了解其他的，所以就拿 JavaScript 举例。JavaScript 生成一个对象非常简单，接口随便定义，因为本身就没有类的限制。因为没有如何构造对象的限制，如何初始化对象都可以按需求灵活地构造。ES6 class 出现以前 JavaScript 各框架生成对象的 wrapper 千奇百怪，也间接说明了这一点。

另外，原型链的设定中，一个对象找不到的属性去另一个对象上找，这就是天然的 delegator。

var obj = {name: 'David', gender: 'male'}

var delegator = {
  __proto__: obj,
  get name() {
    return `Mr. ${super.name}`
  },
}

最后，我没有说原型和类孰优孰劣，也不想探讨这种话题。能成为主流选择的技术都没什么致命的短板，因此选择什么方式做事更多的取决于个人偏好。

@chiangdi 这看你怎么理解类和继承。就算在面向对象的语言中，类和继承的处理方式也是不一样的。比如 Java 和 Ruby 对类的处理就完全不同。所以这本来就是两个抽象的概念，而不是一种固有的实现方式。

我的理解是：

1. 类是模板或工厂，用于批量创造符合统一规范的对象。
2. 继承是一个对象获得了另一个对象的大部分或者全部能力。

JavaScript 的原型链把两件事情都做了，原型对象既可以当做基础模板，也可以作为传统继承里的 parent。只是……没有一个统一的写法，大家为了自己的目的各写各的，

另外众多 JavaScript 框架也没避讳使用原型，只是原型写起来确实繁琐，ES6 class 正好可以弥补这一点。换句话说，JavaScript 的正统就是写原型，只是到了 ES6 之后更加简单而已。这就是我想表达的：ES6 class 不是把其他语言的类定义搬到 JavaScript 里实现，而是基于原型的一种更方便，更统一的语法 。前者叫模拟，后者叫语法糖。

如果用类的思维（或者说某语言的类思维）去看其他事物，那其他东西都是在模拟。照这样说 Ruby 的 class 也是在“模拟” 。不过如果这样想，难免会疑惑为啥其他语言模拟得不像…… 其实本质上这就没有一个定式。

BTW 如果按流行度去比较某技术好不好，那函数式编程应该算是不怎么好的。不过近几年估计没人觉得不好了。

@chiangdi @jasontang168 我并没有觉得文字里流露出“JavaScript 需要模拟类”的概念。我感觉很多人觉得 JavaScript 一直在努力地模仿类设计，ES6 加入了 class 更是声明了何为“正统”。其实完全不是这回事。这也是我写这篇文章的初衷。ES6 class 的目标更多的在于 在不破坏原型系统的基础上统一类定义的写法 而不是 提倡大家都去用类组织代码 。不然为什么会有 Object.setPrototypeOf 这种 API 的出现？

Object 现有的一些 API 已经足够让开发者对原型链进行各种操作，比如替换已有对象的原型，把某个对象插入原型链中，等等。如果说一个不是继承的例子，AngularJS 的 scope 就是基于原型的，每个 child scope 的原型都是 parent scope。child scope 自然地就可以获取 parent scope 的一切属性。这是一个非常巧妙的用法。

事实如此，无需看好或者看衰。Rails 作为一个发展了这么久的框架，各个方面都非常成熟稳定（包括 Ruby 的生态圈），目前和近几年仍是服务器端 web 开发的主流选择之一，值得投入时间和精力去深入学习。

但是作为开发者，没必要把自己绑在一个固定的技术上，有时可以结合时下的趋势和个人定位学习一些新知识，扩宽视野。我喜欢 David Thomas 说的“你应该始终领先于潮流一点点” ：

如果你的工作和事业是软件开发，你的热情也在于软件开发。那你就必须要不断学习。如果你不持续学习的话，你就会过时，你的技巧会没有用武之地，你也体会不到乐趣。作为程序员，你应该始终领先于潮流一点点。如果大家都在看 Java，你应该学 Ruby，如果大家都在学 Ruby，你应该看 Scala 或者 Elixir，或者其他什么。有的人会说，我上班的时候太忙，没有时间。我要说，这不是你的工作，这是你的事业，这是你的生活。

还不错，代码组织比 Ember 自由一些，Ionic 也还不错，比较坑的是 ion-view 的 cache 机制修改了 scope 的生命周期，顺带导致 controller 的 constructor 和 directive 的 link 函数都不是每次调用了。

其实我接触 Angular 比 Ember 还早半年，之前也是觉得 Angular 自带的 route 完全没法应付复杂场景才尝试 Ember 的，然后发现 Ember 的一些想法挺不错……

1. 定义成新的 Component。需要继承的其他组件可以 extend 它，解决 Mixin 不够灵活的问题，局限是只能给组件用——不过对于处理浏览器事件和操作 DOM／BOM 已够用了；
2. 抽象成 Service。这个等价于 Angular 的 DI，可以由你自己定义丰富的接口来配置和调用，最灵活，适合封装需要的外部接口等等

用 OO 的思路解释，第二点是利用继承，第三点是利用组合。我个人的感觉是组合优于继承，可以提供最大的灵活性。最近在用 Angular 和 Ionic，项目里少数几个能用继承和 mixin 的地方我也准备改成组合的方式。这样每个组合的 Object 可以有自己的依赖，会方便不少。

大部分情况应该用 helper 格式化时间。这里只提供 helper 和 Ember Data 之外的另一种思路。

有时候可能我们需要用 Ember Object 封装 API 传过来的 json，其实这就是 model/decorator 的概念了。你自己可用 Ember Object 定义你想要的类。

let User = Ember.Object.extend({
  createdTime: Ember.computed('created_at', function() {
    return moment(this.get('created_at'))
  }).readOnly()
})

let rawData = {name: "David", created_at: "2015-09-17T20:31:04.000+08:00"}
let user = User.create(rawData)

user.get('name')       # David
user.get('createdTime')  # moment object

另外，Ember 1 时代的 ObjectController 本质上是使用了 Ember.ObjectProxy 来代理属性到 model 的。貌似 ObjectProxy 和 ArrayProxy 都被废弃掉了。所以不建议用它们。

@billy 对用户的调查是按熟悉程度划分百分比的。比如 jQuery

四项加起来正好 100%

有种敲了半天代码结果发现用的别人的键盘的感觉……

如果逻辑基本没改，可以 v1 和 v2 都引用同一个 controller/action 的组合，这样只多加几条 routes。我觉得最关键的还是保证修改代码不会导致老版本 API 行为发生改变或者挂掉。这点只能多加 request 测试，给每个 API response 校验 JSON schema。

@wppurking 是的，很多服务在某些条件下可以免费用（限制时间，功能，少用户量或者访问量等等）。其实 IDE（尤其是 Web IDE）也可以这样搞啊。

补充一点，订阅模式可以让用户以更小的代价尝试产品。这在以前一次性的收费模式下，用户要么花高价去买完整版，要么下载功能受限的试用版。哪一种都不是很好的选择。

其实作为用户，我更倾向基本功能免费，扩展功能和服务收费的模式，像 Pocket 那样。不过这种方式不是对所有产品都适用的。

高质高产啊！你也用不带 ; 的代码风格？如果这样，可以再加上 tailing comma（给每个 object 和 array 的最后一个元素加上 ,）。这样犯错概率更少一点，Git commit 也好读一些。反正 Babel.js 编译时会自动去掉末尾的 , 。

凑个热闹，加一个 .ackrc。仅仅举了几个例子，全部的就不贴了。

--ignore-dir=node_modules
--type-add=css=.scss,sass,less
--type-add=js=.es6,coffee
--type-add=ruby=.ru

作为 Ember 粉，再加一个 Built With Ember 。

@luikore @MrPasserby 这就是 JavaScript 的世界，西部大开发…… 不过也是吸引人之处。真的哪天不折腾了，说明很多问题都有了标准化的解决方案，JavaScript 发展速度也就缓慢下来了，喜欢折腾的人也会去开拓新的蛮荒之地。

如果所有服务都以邮箱作为账号保护的核心，那邮箱当然得选个靠谱点的，Gmail + 两步验证挺有必要。国内的最好绑定个手机。 另外，装个 1Password 吧，别把大部分应用都设置同一个用户名和密码，这点钱花得还是值得的。1Password 除了账号，顺便还可以存下 ssh 密码，Wifi 密码，路由器登录密码之类的信息……

@ericguo 这变化都快赶上娱乐新闻了……官方没有仔细解释为什么啊，是因为 Web Component 规范有些不兼容 Ember 之后的发展么？

pods 小试过一下，我觉得目前的 pods 不是很实用，除了增加目录结构也没什么很大帮助。期望官方给一个好的方案出来。目前项目如果有自定义的需求的话，改 resolver 也不是那么麻烦。

貌似没人提 Ember Data 和 JSON API。其实我还算比较看好这货的。前端方面对数据层一直没什么好的解决方案。目前可能还行的除了 Ember Data & JSON API 就是 Relay 了。不过 Relay technical review 前几天出了，实际应用起来比想象中麻烦，构造一个 Graph QL 的 API server 也不比 JSON API 容易。

Discourse 的解决方法很不错。样例可以参考 这个帖子 。就是不知道在 Ruby China 实现这个麻不麻烦。

Cool!

一个朋友做的产品，人挺靠谱的。支持一下！

最近的项目用 ActiveModel::SecurePassword 和 JWT。做 authentication 和 reset password 都很方便，比 Devise 简单灵活很多。

Rails 默认组件很多都挺好用，比如 ActiveSupport::SecurityUtils 里的 secure_compare 用来对比两个字符串，防止 timing attack。我上面例子里的 JWT 也可以用 ActiveSupport::MessageVerifier 或者 ActiveSupport::MessageEncryptor 来代替。

活动控制器，活动包，活动视图和活动职位都没变化么？我是来灌水的……

@nightire 不得不顶啊。喜欢前端的后端工程师来握个爪。

然而这并没有什么卵用。

有意思的是我前几天我也看到了这个图，不过是在这篇博客：With So Much Rails to Learn, Where Do You Start? 。摘抄一段：

It’s crushing to see a few hundred skills, and know you need to learn them all. Especially when those first few competencies take you weeks or months to pick up. You’ll feel like you’ll never become a professional Rails dev.

The chart’s not wrong. As a Rails dev, you’ll eventually know a lot about most of those things. But we didn’t all start there.

So, start somewhere. Prioritize, and move along the path that leads to your app being built. Branch out to fill in the gaps. And recognize that you’ll get faster as time goes on.

我选书的标准（仅仅技术书籍）：

1. 没多少时间，就挑目前用得上的。有足够时间，就挑自己感兴趣的。
2. 不看国内作者写的，也不看翻译版，只看原版；
3. 电子版优先；
4. 少下载，少买，多扔。

LZ 应该不在乎买错书或者扔书对于金钱的损失，那就说说精神上的损失。精神上的损失本质上就一点：感觉这书不错，但因为各种原因没用，可惜。

实际上如果这是 LZ 权衡了各方面因素之后最终妥协的结果，那没什么可惜的。因为看这书不是你当前最重要的事情，你的时间贡献给了你觉得最重要的事，这反而是个好事情。

人都想获得尽可能多的东西，知识也不例外。但自己时间精力有限，没法做到所有的事情，最终还是需要取舍。对书而言，放弃没什么可惜的，正如 @lgn21st 所说，书不花心思读是没法变现成价值的，而没有变现的价值，就是毫无价值。

懂得放弃也是一种智慧。

@yue @ryan 你说的这个问题不是 token 解决的问题，防治办法不在 token 这边，应该依赖 HTTPS 去加密网络连接。

另外 JWT 的 payload 是没有加密的，它只是用 base64 编码了而已，加密的是最后的数字签名（signature）。数字签名是用来做校验以确保 payload 没有被修改。可以说一个 JWT 的 token 就是包含了只读信息的 token。

挺不错的公司和团队，希望你们招到合适的小伙伴！

@ibachue Sublime Text 现在不知道更新怎么样了。一个人主导的项目总觉得不知道什么时候作者就会不干了…… 我还比较看好 NeoVim 和 Atom，尤其是后者基于 HTML 在 UI 方面是没有任何限制的，这点对发展插件还是挺有利的。如果能解决速度的问题那就是个很好的编辑器了。