新出现的东西没看出来哪个解决了 Rails 没有解决或者解决的不足的问题。至于 react，vue，前后端分离，这些跟 rails 又不矛盾。

目的不太一样。Model 里能做更复杂的验证，有友好的报错。数据库是为了在守住关键底线，限制功能要弱一些。

如果你这个字段，不存在并发访问等绕过 Model 的情况，你可以不做数据库层面限制。

方法调用，还有 lambda, proc 等，在 Ruby 里是不一样的东西。至于为什么这样设定，这是作者是这样想的。对我个人来说，没有什么好与不好。如果与 JS 等语言比，方法、函数、lamba 其实就是一个东西，确实是更一致，但是 JS 也有 JS 不一致的地方。

实际上，Ruby 因为有 block 的存在，很多时候并不像是 JS 一样，是函数传来传去的，它是传 block。以你的例子（我帮你格式化了，不知道是不是你本身的意图）

tt = ->(fn, arg) {
  fn.call(fn.call(arg))
}

aa = ->(arg) {
  arg << '!'
}

tt.call(aa, 'ok')

首先在 Ruby 里我们可能不太会去定义高阶函数，而会去使用一个私有方法。在我接受高阶函数的概念后，我也尝试在 JS, Scala 里用高阶函数来封装局部逻辑，但是事实证明是这带来了代码可维护性的降低。因为本身这种需要局部高阶函数的函数，逻辑就很复杂，这时候使用高阶函数，相对于另一个私有方法，本身就在增加复杂函数的长度。

如果我把你的 tt 当成是一个方法，而不是一个高阶函数，那可以这样写：

def tt(arg)
  yield(yield(arg)) # 这里我不清楚你的意图，一般应该不会这样做，我只是复制你的逻辑
end

tt('ok', &block) # block是这个调用tt的方法的一个block参数

是不是相对你的版本好看一些？

JS 里的

var hide = function() {
  // ...
}

本来在 Ruby 里，我们就会用一个方法来代替的，所以就基本不存在你说的连环a_lambda.call()的调用。

Ruby 3.0 现在动向如何？有什么进展？对于实现 3x3，目前采取了哪些优化方案？

人工的智能识别

苹果支持 DP 1.2 Multistream 有问题，从 10.9 一路拖到 10.13，还给我发邮件说“修好了！”结果带来更多问题，到现在 10.13.3 还没修完

整个互联网上对于 REST 的迷惑，最终就落到了这个“超媒体作为应用状态引擎”（HATEOAS：Hypermedia As The Engine Of Application State）上，其他几条都没有问题。而按照 REST 原意，没有这一条就不能叫做 REST，因为它是“约束"。

在尝试了好几个项目，以及看了很多资料之后，我还是非常困惑如何在 API 方面做到这一点。这一点似乎是专门为面向人类的 HTML 阅读器：浏览器而设计的：因为如果你把链接（超媒体的要素）放在文档里让客户端使用，那么前提是客户端知道如何去使用这个”链接“。而“客户端”并不是一个人而是一个程序，它如果知道如何去使用这个链接，那么这个链接对客户端来说就是已知的了：我写过这个链接的代码，测试过它。超媒体给我的唯一信息，是我在此时可以或者不可以去使用这个链接。

举例说如果我有

<!-- GET /posts/1 -->

<post>
    <title>一个大新闻</title>
    <content>...</content>
    <link rel="like" href="/posts/1/like" /> <!-- 为这个帖子点赞的链接 -->
</post>

试想开发一个客户端的的时候，如果我看到这个链接，那么我的客户端需要能完全理解这个链接的含义：为这个帖子点赞，于是我必须事先写好，能像用户说明这个功能的 UI，比如一个点赞按钮，并且我需要用适当的手段向我的用户说明这个按钮的意义，而这一切都必须是事先准备好的。这样来说，如果 API 更新，加入了一种新的动作，例如关注，那么在我客户端不更新的前提下，我是不可能支持这种新的动作的。

然而作为浏览器，它的使用者直接是人，情况就大不一样。因为负责说明这个新动作关注的任务，就已经包含在这个返回的文档里，人类看到这个文档（浏览器的渲染）后，就已经能理解这个新动作了。

这样一来，虽然说我在编写客户端的时候，没有事先写死一个链接模板比如/post/:id/like，但是我对这种类型的链接，必须是实现有所准备的，因此虽然我可以处理超媒体，但是我能理解的超媒体控件数量，取决于我客户端软件的版本。这样一来，我认为超媒体最重要的一个意义就失败了，就是允许客户端使用超媒体去发现 API 新的能力。

如果是这样的话，那么我就无法理解为什么这一条是 REST 的一个必备条件。理论上，在上面例子当中，点赞这个动作，我可以依赖服务器在运行时给我返回一个动态的链接，但是这对客户端来说，仅仅是链接的地址有无事先约定，而链接的处理方式则是必须事先约定好的。实际使用的时候，这个链接地址动态变化所产生的不同是微乎其微的。

2018 年招聘，欢迎捧场

这也太慢了

#9 楼 @chenge 是我说错了，我本来应该指的是他说 Don't Repeat Yourself 会增加耦合度。至于 Convention over Configuration 他本来意见也比较弱

没有觉得 Rails 跟图上画的一样，跟业务逻辑交织在一起，完全就是个错误的论断。

刚看了下他的一些文字，，他连 Convention over Configuration 都可以站出来反对，说这会“增加耦合”，实在是无语。估计这位同学是 J2EE 的卫道士——不依赖任何外部库，所有东西都手写，方法都是静态的，最符合其要求。

#6 楼 @flemon1986 目前来说在 rails 里面，仍然是 coffeescript 比较顺畅，配置容易，同时兼容内嵌和外联，跟 sprockets 集成的好。Coffeescript 解决了低版本 JavaScript 的一些棱角，虽然不如 ES6 先进，但是在 Rails 工具链上胜出。

#4 楼 @flemon1986 Vim 党万年问题：Coffeescript 的优质高亮。我看了一下 coffeescript.vim，暂时没太明白

#1 楼 @greatghoul 这两个很有帮助。Vim 里是 Rails.vim 已经包含着两个功能了