The Git Version Control System has taken over most of the Ruby world. Simply put, if you're going to develop with Ruby you have to learn Git.
A full Git tutorial is beyond scope here, but there are many great resources out there already:
| # Remember the current directory | |
| if [ `type -t cd` == builtin ]; then | |
| cd () | |
| { | |
| builtin cd "$@" | |
| pwd > ~/.working-directory | |
| } | |
| else | |
| # Alias the cd function (needed if you run RVM) | |
| eval "$(echo "__cd_without_cwd()"; declare -f cd | tail -n +2)" |
| class Product < ActiveRecord::Base | |
| attr_accessible :title, :price, :description, :image_url | |
| validates_numericality_of :price, :only_integer => true | |
| def price=(data) | |
| data.delete!("$") | |
| super | |
| end | |
| end |
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
| --- | |
| :benchmark: false | |
| gem: --no-ri --no-rdoc | |
| :update_sources: true | |
| :bulk_threshold: 1000 | |
| :verbose: true | |
| :sources: | |
| - http://rubygems.org | |
| :backtrace: false |
| # app/models/user.rb | |
| def apply_omniauth(omniauth) | |
| case omniauth['provider'] | |
| when 'facebook' | |
| self.apply_facebook(omniauth) | |
| when 'twitter' | |
| self.apply_twitter(omniauth) | |
| end | |
| authentications.build(hash_from_omniauth(omniauth)) |