Most of the time simple output statements using warn, raise, or a logger will help you find your issue. But sometimes you need the big guns, and that means ruby-debug.
The ruby-debug package has had some rocky times during the transition from Ruby 1.8.7 to 1.9.2 and beyond. But now, finally, the debugger is reliable and usable.
Not every application starts from scratch, sometime you have to deal with a legacy database. Walking the Rails golden path makes life easy, and there's a perception that stepping off that path is incredibly painful.
It's not true. If your database is well designed and but doesn't follow the Rails naming conventions, it's easy to make them play nicely together. However, if your database structure is crap to begin with, then there's only so much Rails can do for you. ActiveRecord is a mapper between the database and objects, but it's not a DBA-in-a-Box.
In a green-field app, ActiveRecord and the Database fit right together:
Data integrity is an underrated part of proper application architecture. Many of the bugs in production systems are triggered by missing or malformed user data. If a user can possibly screw it up or screw with it, they will. Validations in the model can help!
Before we begin, let's talk about syntax. There are two primary syntaxes for writing validations in Rails 3:
validates_presence_of :price
As your business logic gets complex you may need to implement transactions. The classic example is a bank funds transfer from account A to account B. If the withdrawal from account A fails then the deposit to account B should either never take place or be rolled back.
All the complexity is handled by ActiveRecord::Transactions. Any model class or instance has a method named .transaction. When called and passed a block, that block will be executed inside a database transaction. If there's an exception raised, the transaction will automatically be rolled back.
The controller's job is to work with the request parameters and determine how to activate the domain logic and data to respond to requests. The parameters are key to completing that job.
And, at the same time, parameters are the cause of the most problems in a typical controller. A great action method should be about eight lines of Ruby, but many actions spiral out of control with all kinds of switching based on the input parameters.
First, a small point of order: people commonly refer to params as a variable but it isn't -- it is a helper method provided by ActionController which returns a hash containing the request parameters.
The Rails REST implementation dictates the default seven actions for your controllers, but frequently we want to share functionality across multiple actions or even across controllers. Controller filters are the easiest way to do that.
There are three types of filters implemented in Rails:
before_filter runs before the controller actionafter_filter runs after the controller action
| # requires root permissions in /usr/bin/ | |
| star = String.new | |
| 8.times { star += "*" } | |
| Star = "\n#{star * 3}\n" | |
| def newblock string | |
| puts "\n#{Star}#{string}#{Star}\n" | |
| end |
HTTP is a stateless protocol. Sessions allow us to chain multiple requests together into a conversation between client and server.
Sessions should be an option of last resort. If there's no where else that the data can possibly go to achieve the desired functionality, only then should it be stored in the session. Sessions can be vulnerable to security threats from third parties, malicious users, and can cause scaling problems.
That doesn't mean we can't use sessions, but we should only use them where necessary.
APIs are becoming an essential feature of modern web applications. Rails does a good job of helping your application provide an API using the same MVC structure you're accustomed to.
Let's work with the following example controller:
class ArticlesController < ApplicationController