可以试试这个，帮你封装了一些很便捷的方法，省去不少事。

https://github.com/westonganger/spreadsheet_architect

好像流利说和 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.

99 美刀啊，可以考虑，你看过吗？

求出书

对于这种只会用到基础功能的命令，我一般会直接搜 xxx cheat sheet，这样就不用去过一遍文档了。^0^

要是想 DIY 的话，middleware 用 warden，加密用 BCrypt，然后自己写几个 strategy 和 controller 就可以了。

身经百战 人生经验 谈笑风生

贴代码

创业公司职位描述：

期权奖励 = 我们工资没那么高

工资 15K-25K = 我们工资就是 15K

工资根据能力不封顶 = 要工资前请先看看你自己的水平

有转正机会 = 我们只要临时工

感觉不能小看只 select 部分字段所带来的维护成本

增量测试肯定不行的吧，不可能保证新功能和老功能之间没有耦合。不过我觉得楼主可以娶她，这样以后测试用例就可以自己来写了。

SPA 是楼主前女友？

年终福利，闪总女装秀。

兄弟 要不要这么文艺啊

写普通代码的时候碰到的过度抽象问题放大到应用环境就是微服务面临的问题吧。

这个贴和以前有一个 200 块找高手移植 Redmine 的有点像。

+1

真不靠谱，连 markdown 格式都整不好。

个人的做法：

关掉手机所有 APP 的推送（只留下网易邮箱、微信、丁丁，饿了吗和支付宝有时候会开，并且群聊等等设置为免打扰）。微信公众号除了几个必要的，全部取消关注，朋友圈刷屏党一律屏蔽，避免被无意义的东西分散精力。新闻类资讯基本都是垃圾，要么是为了宣传口径修改过的，要么就是蹭热度的标题党，所以不看。

订阅 ruby-weekly，去豆瓣找找高分电影和高分书籍，知乎 follow 一些质量高的收藏夹。

总结来说就是不要为了节约时间去吃那些别人主动推送给你的“屎”，尽量找一些已经被初步筛选过的东西的来看。

不正好可以利用提交代码的时间上 ruby-china

像梦想马上就会实现那样去期待，去努力。像梦想永远不会实现那样去耕耘，去生活。