topfunky/peepcode's "16 Ruby on Rails Solid Workflow Tips"

mvc_summary.md

http://www.codercaste.com/2011/02/11/10-ruby-on-rails-3-tips-that-will-make-you-a-better-rails-programmer/

Understand What a Model, Controller, View, and Helper are

Rails heavily depends on the model view controller (MVC) design pattern. Every one of them has a specific job and jeopardizing them is never a good idea. A controller is responsible for handling Rails requests and passing data from a model to a view. You can think of the controller as a manager between the logic of your program and the actual view that a user actually sees. Generally, a controller should have very few code. It should just execute some functions and retrieve instance variables to be used directly in a view. Moreover, it is used to do redirects with redirect_to and the likes.

A model is where your actual business logic is. The body of your main functions should always lie inside a model that is responsible for handling that data. Since a model operates on data, it’s pretty sensible that a model actually represents a database table and the operations that can be done on that. Always make sure that your functions and core code is inside your models.

A view is where data is represented to the user. You should never (really, never) include logic inside your views. If you feel that you need to include some sort of code inside your views, chances are high that you will be executing more database queries than actually needed. If you feel that you can use a hash instead, do it; although a bit more code to write, it’s the superior choice.

Some people may believe that a helper is the way to elegantly include code in your views. However, that is not really the case. A helper is actually (or should be) sort of a formatting underlying task. For instance, suppose that you have a hash that contains the costs of 4 different products, that you need to present to your view. If you would like to present some of the prices in euros and some in dollars, you could use a helper that would create a string like “this costs 20 dollars” or a string like “this costs 18 euros”, based on the helper function input.

Always put code having this priority in your mind :

1. model

2. helper

3. controller

4. view

ror_workflow_tips.md

http://nubyonrails.com/articles/massive-list-of-rails-development-tips

#Full Chapters

• Store sessions in the database (or at least not on disk, which is the default). Use a custom configuration file for passwords and API keys instead of storing them in your Subversion repository. I use YAML and mirror the style of database.yml.

• Use constants where needed. Instead of repeating strings like the address of your customer service reply email, set it once in a constant (in environment.rb or the appropriate environment file) and use that throughout your application.

• Keep time in UTC. A no brainer, and easy to do.

• Don’t loop through ActiveRecord models inside other models. Use eager loading if you need to work with multiple associated models. Better yet, write a custom SQL query and let the database do the work for you.

• Beware of binary fields. By default, all fields are returned with queries, including the full contents of any binary fields. Use :select to pull out only the fields you need.

• Write tables to cache data for reports that span months and years. It’s much faster than re-generating a year’s worth of reports every time a page is loaded.

• Create a table with a list of country names. By default, Rails uses strings for selects and lists of countries, which doesn’t work well for reporting or database consistency between models.

• Avoid bloated controllers. Instead of piling actions into a controller, limit yourself to 10 actions per controller, then rethink your design.

• Keep your controllers and views skinny. In general, most of your code should be in your models, not your controllers or views.

• Don’t store objects in the session. Use integers or short strings if necessary, then pull the appropriate object out of the database for the duration of a single request.

• Avoid heavy response processing. Can you mark a record as needing to be processed, then use a cron job or a messaging server to do the long-running work? BackgroundRB is also an option. (I use this technique for filtering SPAM comments on this blog).

• Use ar_mailer to queue bulk emails instead of sending them during the Rails response cycle.

• Monitor your servers with the exception_notification plugin, munin, monit, or other tools.

• Don’t cut costs on hardware. You’ll quickly lose the money you thought you were saving if your developers have to spend even one day a month on unexpected server maintenance due to poor backups or cheap hardware.

• Test-drive your development.