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

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

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

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

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

寻寻觅觅， 冷冷清清， 凄凄惨惨戚戚。

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

三杯两盏淡酒， 怎敌他、晚来风急？

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

是啊。

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

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

牛逼

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

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