• 新出现的东西没看出来哪个解决了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,目前采取了哪些优化方案?

  • 人工的智能识别

  • Linux、Ruby 不冷没天理! at 2018年02月09日

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

  • 理解本质的 REST at 2018年01月17日

    整个互联网上对于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他本来意见也比较弱