对于这个问题，我是觉得程序员在实现一个功能之前还是有必要了解一下客户的需求是什么（哪怕这个需求滑稽得让你无法忍受）这有助于一个程序员对自己开发的功能或者说整个系统有进一步的了解，对于一个程序员来说我觉得是有好处的，可以在某种程度上让一个程序员有那么一点产品的意识。

我不太清楚你们有产品经理的公司是怎么运作的？总不会说产品经理对接完需求之后然后让我们做什么就做什么就只需要关心写代码的事情？

读了文章之后要思考，哪些步骤更具备可行性 对于这点我比较同意。

另外关于产品经理的问题我觉得还是看公司的情况不同而定吧。像我的公司是资讯外包公司，一般都没有自己的产品，目前也就没有产品经理。如果需要理清需求还有客户对接一般是项目经理或者对应项目的负责人负责，开发人员也因此要承担更多的责任，虽然一般不需要与客户直接对接但还是需要更多去理解客户的需求。据说之前也有招过产品经理，不过大部分时间都是闲置着了。

确实没有产品经理。

如果真要选的话，其实个人比较倾向于后者，虽然个人写前者比较多。 审阅代码的人压力也没那么大。

多谢分享。

好像没什么所谓。

是好书的感觉，不过似乎只有二手了。

多谢提醒，PG的Array我稍后会看一下。

这点不太理解，你的意思是不用上述的标签系统查询的时候就不用join表了？ 而一般的业务场景下拿数据应该都会分批拿，比如会做分页等的，不会一次搞上千条数据出来，你所说的那种场景是否能详细描述一下？

求长文。

了解。

不过全文搜索的东西我还没接触过，感谢提醒，我稍后找时间了解一下。

总算收到书了，比想象中要厚重。

哈哈，我就提个建议，目前还没有跳槽的打算。感谢你的反馈 。 要不顺便加个头像吧。

在taggings上面做分类就行了吧。

不是，这篇文章是我刚写的。刚好在自己的项目中有用到ActsAsTaggableOn 。

看了一下https://ruby-china.org/topics/20243 这个你四年前发的帖子，顺便就四年前的帖子发表一下看法。

往年的列表

好像内容都差不多啊。文字也没怎么换，这方面如果走点心就好了。或者挂一些你们团队的作品或者哪怕用Rails建个简单的官网也好，这一方面真的能够让别人知道你们的实力，你们是做什么的，最起码让有意愿的人了解到这个团队到底是一个team还是仅仅是一个团伙。

说实在现在房价越来越高，在中国程序员是目前比较有可能能够远程工作的人群，你们能够给2-3线城市的人提供就业机会这点个人是很认可的，但是正如楼上 @kevinyu 所说的，某些方面真的要走点心。

没毛病。

无意冒犯，但贵公司的网站的设计很国企范，sans-serif与serif字体混着用，布局感觉也不太走心，也没上https，估计很多Ruby程序员点进去就失去兴趣了。CTO的书特意去搜了一下，我也没看过，不敢妄加评论，应该是早期的Ruby大神，But在招聘贴上放进去似乎意义不大，毕竟我觉着百分之50以上的Ruby程序员应该都是自学的吧 。

我觉着作者定义这个标准其实就是想更好地管理资源，虽然有时候restful确实冗余信息太多。比如你所说的，我们都知道动物是属于动物园里面，或者说动物园数量很少的时候我们或许直接采用

/zoos/animals/:id

甚至是

/animal/:id

就足够了，但是有的资源哪怕在数据库里是平级关系但是他们的父级资源是数量是很庞大的，比如我有1000篇文章，然后每篇文章都有1000个评论。那么api写成

posts/999/comments/100

个人感觉就会比

/comments/100

更有层次感，可读性更高也能够清晰的知道当前资源的归属地，这条评论是属于id为999的文章的，这对于开发而言是有好处的。

如果加上slug就更清晰了

/posts/post-about-docker/comments/100

对restful来说第一种场景是冗余，但是在第二种场景我觉得是很恰当的用途，往往现实生活中第二种场景应该会比较多。具体要怎么定我觉得还是分情况来看吧开发者自行权衡。Rails也只是给了我们一个通用的约定，让我们更容易地去定义restful 的API，但并没有限制我们的手脚，我们依然可以很容易地自定义自己想要的路由。虽然听起来不符合规范，不过你说的三种我都有在项目中用到。

我对数据库也不是很熟，我试了一下两种方法都可以

class CreateExampleTable < ActiveRecord::Migration[5.1]
  def change
    create_table :example_tables do |t|
      t.integer :my_id1
      t.integer :my_id2
    end
  end
end

class ChangeColumn < ActiveRecord::Migration[5.1]
  def up
    change_column :example_tables, :my_id1, :integer, limit: 2
    change_column :example_tables, :my_id2, :bigint
  end

  def down
    change_column :example_tables, :my_id1, :integer
    change_column :example_tables, :my_id2, :integer
  end
end

第一种方法是用于限定它的最大长度，就像你设置成8，它就会是bigint，我后来把它换成2它就是smallint， 文档在这，PS：我是在PG上面做的尝试。

第二种方法是直接把它设置成bigint了。

跑我给的脚本，结果如下

my_id1 | smallint |
my_id2 | bigint   |

建议：以后这种问题最好还是自己动手去试一下，随便一个migration就可以试出来了。社区里面的高手都很忙，他们也不可能知道所有东西，所以他们要回答你的问题如果没有相关的经历可能都需要自己试了一遍才能够回答，懒得试的估计就直接忽略你的问题了。而这部分工作应该你自己来做，真的遇到问题再把问题和代码贴出来，这对大家都有好处。提问的话建议参考管理员的 提问的智慧。

我在京东上下单了，采购ing .

店里已经卖完了？

感觉可以搞一本看看。