#7 楼 @syutran 😀

#8 楼 @placeintime 这个厉害了

用过 corntab 也用过 rufus-scheduler 一直很稳定啊

awesome_nested_set

很赞成一哥们儿的说法：幻想学好 Rails 后能够一劳永逸，最容易过时。

#6 楼 @pengedy 充当的角色会比在大公司丰富，不过楼上补充的很到位

2.18

氛围

喜欢这个 2.4+5+pg+hd

#3 楼 @pinewong 是的，没毛病

#4 楼 @lwd369 qq 音乐啊

#1 楼 @lgn21st westlife 的

#30 楼 @hbin 目前考虑的只能在原有的基础上进行改动

#28 楼 @huacnlee 还好吧，每个 model 基本只定义了 index_json 和 show_json，目前没有遇到维护上的难题

#26 楼 @huacnlee 有什么想法？

最近在尝试一种新方案：重写 as_json 的 json_options，根据业务需求去自定义它的 json 结构如下：

self.json_options = {
    only: [:xxx],
    methods: [:xxx],
    include: {
      xxx: {......}
    }
  }

然后 controller 层 index 如下：

render json: {users: @users.as_json}

如果特殊的接口可能需要自定义一些 json 格式

class_attribute :show_json_option
self.show_json_options = {
    only: [:xxx],
    methods: [:xxx],
    include: {
      xxx: {......}
    }
  }

然后 controller 层 index 如下：

render json: @user.as_json(User.show_json_option)

把重 model 发挥到极致

#1 楼 @phoenix 赞，资料之前看过

有人正在挖坑

用过 jbuilder 也用过 grape 现在正在用直接用 controller 做 api，不过直观感受是以前用 jbuilder 做 API，随着版本的升级业务的扩展，文件变得越来越多，难以维护 (可能是因为能力问题)

建议：调用方法时用.，不建议用::，因为通常情况下::是用来调用一个常量的

去年面试过，环境一级棒，有兴趣的 boy 可以去试试

#2 楼 @IChou 好吧，我想起了之前遇到的问题

在代码可读性还说得过去和对性能优化没有影响的的重构显然是没有多大意义的，切记不要一味的追求高大上的代码

我认为可读性差的代码都是质量不太好的代码，就比如你给的例子。

接口还是以资源 (model) 为单位会好管理一些吧

然而 ruby 是面向程序员的

35？笑话！现在哪有一个 90 后活到 35 了

#25 楼 @Trump 厉害了

你们搞编程不是为了生活吗？

之前看过你们的职位要求感觉没什么问题，投了一次简历，等了好长时间没有给回复，想法设法的要到你们 HR 的微信号，但是还没有给面试机会可能贵公司要求真是太高？不！这可能是我简历写的有问题