• 好像流利说和Strikingly内部也用的是gitlab-ci

  • 这个括号高亮真的需要,不然一大堆括号真的看起来很累。

    另外感谢你推荐的书,基本看完了。面很广,内容十分实用,覆盖了很多我的知识盲点,看的时候很有趣。👍

  • 不是很了解nodejs,个人觉得Rails的衰弱并不是因为其他更优秀竞品的出现,而是和它自身的特点以及时代发展有关。不过话说回来,要是现在让我起手一个web项目,第一选择还是Rails,最大的原因当然是因为——我只会这个。

  • 感觉楼主已经达到了第三重“看山还是山”的境界。

  • 寻寻觅觅, 冷冷清清, 凄凄惨惨戚戚。

    乍暖还寒时候, 最难将息。

    三杯两盏淡酒, 怎敌他、晚来风急?

    雁过也, 正伤心, 却是旧时相识。 满地黄花堆积。

  • 是啊。

    知名度其实很重要,大家认为学这个以后能够进大公司、赚大钱,才会有人学。多数人都是这样的,靠少数爱好者社区只能勉强维持,很难继续壮大。然后这种情况下能入坑的大多数是一些geek,干了一段时间他觉得技术上没有新鲜感了,于是就会跑去折腾别的东西。大多数公司需要的是能花时间把公司的业务梳理得更清楚的码农,技术能力够用就可以了,太geek有些时候弊大于利。招几个新手来培养一下吧,也不简单。元编程、惯例优于配置等等,写起来是比较爽,但是维护起来就不是那么回事了。本来依靠静态分析或者在编译时就可以发现的问题,现在要依靠CI,或者纯脑力去发现。一些静态语言,只要学会基本语法,自己去跟代码,最后总能找到问题点。普通的Rails新手,要是调用接口的结果和自己的认识不一致,就很难了,要成为即战力恐怕至少得三个月。种种原因都造成了Rails招工难的问题。

  • 就现在这个行情,使用Rails给公司节约出来的人力成本很快就会被额外的招聘成本所抵消掉吧。

  • 牛逼👍

  • Why Sometimes I Write WET Code at 2018年09月09日

    DRY应该是被迫的,就是你写着写着发现这里可以抽象出一个公共的方法,不然代码就显得很重复,那么就去抽象一下好了。而不是提前就把内部的抽象层级以及依赖设计完整,再去挨个实现它这样。其次我觉得二楼说的这个命名的问题确实很重要,如果抽象出的方法在业务上确实是同一件事,用同一个方法名称可以准确表达出它的涵义,DRY并不会影响其他程序员维护你写的这段代码,这时这个抽象就很合适。

  • Repeat after me: I will not optimize anything in my application until my metrics tell me so.

i love my wife & ruby