1. What are all naming conventions I need to be aware of?
db表是复数形式，模型是单数形式，控制器是复数形式.所以你有一个由users表支持的User模型，可以通过UsersController表看到.
文件应命名为类名的宽壳版本.所以FooBar类需要在一个名为foo_bar.rb的文件中.如果使用模块进行命名空间，则命名空间需要由文件夹表示.所以如果我们说的是Foo::Bar级，应该是foo/bar.rb级.
2. How should controller actions be structured and named?
控制器操作应该是RESTful的.这意味着您应该将控制器视为公开资源，而不仅仅是启用RPC.Rails有一个成员操作与资源收集操作的概念.成员操作是对特定实例进行操作的操作，例如，/users/1/edit将是用户的编辑成员操作.收集操作是对所有资源进行操作的操作.所以/users/search?name=foo将是一个收集行动.
上面的教程描述了如何在routes文件中实际实现这些 idea .
3. What are the best ways to render information in a view (via 100 or render a partial) and what are ways I shouldn't use?
当您希望能够将html从内部模板附加到外部模板时，应该使用content_for，例如，能够将视图模板中的内容附加到布局模板中.一个很好的例子是添加特定于页面的javascript.
# app/views/layout/application.rb
<html>
<head>
<%= yield :head %>
...
# app/views/foobars/index.html.erb
<% content_for :head do %>
<script type='text/javascript'>
alert('zomg content_for!');
</script>
<% end %>
partials要么用于分解大文件，要么用于多次呈现相同的信息位.例如
<table>
<%= render :partial => 'foo_row', :collection => @foobars %>
</table>
# _foo_row.html.erb
<tr>
<td>
<%= foobar.name %>
</td>
</tr>
4.What should go into a helper and what shouldn't?
模板中应该只有basic个分支逻辑.如果你需要做更激烈的事情，应该找个助手.视图中的局部变量是对世界上一切美好和正确事物的厌恶，因此这是一个很好的迹象，表明你应该成为一个助手.
另一个原因是纯粹的代码重用.如果你一遍又一遍地做着同样的事情，只是有轻微的变化，把它拉到一个助手(如果它是完全相同的事情，它应该在一个部分中).
5. What are common pitfalls or something I need to do correctly from the very beginning?
partials应该直接引用instance(@)变量，因为它会阻止后续的重用.始终通过:locals => { :var_name => value }参数将数据传递到渲染函数.
将与渲染视图没有直接关系的逻辑排除在视图之外.如果你可以 Select 在视图中做某件事，然后在其他地方做，那么10次中有9次在其他地方做是更好的 Select .
我们在rails中有一个口号是"胖模特，瘦控制器".一个原因是模型是面向对象的，控制器是固有的过程.另一个是模型可以跨控制器，但控制器不能跨模型.第三，模型更易于测试.这只是个好主意.
6. How can you modularize code? Is that what the lib folder is for?
lib文件夹用于跨越模型关注点的代码(即不是模型，但将由多个模型使用的代码).当你需要把东西放进go 的时候，你就会知道，因为你不知道该放什么模型.在这之前，你可以忽略lib.
需要记住的是，从rails 3开始，lib不在自动加载路径上，这意味着您需要在其中输入(或重新添加)任何内容
自动要求lib目录中所有模块的方法:
#config/initializers/requires.rb
Dir[File.join(Rails.root, 'lib', '*.rb')].each do |f|
require f
end