All Things ROR

A rails controller is usually associated with a model. (RESTful) with a few exceptions.

A rails controller ideally has only 5 methods/actions (create, index, show, update, destroy), before_filters and private supporting methods. Some controllers do not need some actions say, update & destroy if the business logic says so.

The 'before_filters' can be used for authentication & setting instance variables of the corresponding models.

The show, update & destroy actions need access to the instance variables. So you can set them in the before filter.

You can also white-label the params for the update action ( for security reasons ) using the permit parameter. Then you can require some attributes using the require method.

Code without 'conditionals' is a pleasure to read. You can work-around them using ||= 

1. Git Branch Setup & Green Specs:

Identify the base branch you want to work off of

Do the necessary db & test db reset/setup scripts

Run whole test suite

If green proceed, if not voice concern & get them to green

2.Understanding Phase:

While the specs are running,

Go over the story/requirements & take notes

Start the servers, examine the current behaviour and identify the required changes

Identify the execution flow ( from the partials, views, controllers & models )

Refer to shcema.rb/structure.sql for db schema info, foreign key constraints etc

3. Feature Branch

Create a branch with the right naming convention

3. Spec it Out ( Red )

Write specs for intentended functionality & make sure they fail

They need not be perfect.

Can perfect them as you proceed

4. Implementation Phase ( Green )

Update db & relevant schema files

models

contollers

views & partials

Add any additional specs & make sure all green

5. Refactor 

Identify any possibilities for improvements, optimisations or more elegant code

ActiveRecord examines the current state of the database and generates a dump file based on the config setting

config.active_record.schema_format could either be :ruby which generates db/schema.rb or :sql which generates db/structure.sql 

schema.rb is database indepdendent

It is error-prone to deploy a new instance with the entire migration history. Its easier & faster to use load into the database a description of the current schema

This is also how the test db is created

You can use schema.rb to see the structure of a table 

schema.rb cannot express db specific items like foreign key constraints, procedure etc

You can specify them in migrations using raw sql code

Highly recommended to check in these files, as they are an authoritative representation of the db schema

ActiveRecord claims that intelligence belongs in the models and not in the DB

Upgrade:

brew install mysql 5.6.10

Foreign Key:

A key is a foreign key in a table, if it refers to a primary key in another table

Example: Address table has a foreign key person_id ( which is the primary key of the person table )

Now, when you insert a address record, you should provide a valid person_id, that exists in the person table.

Also when you try to delete the person record, it fails

Foreign Keys ensure - Referential Integrity

Useful Queries:

:auto_save - 

Whenever you set the above, the association will be saved, when the model is saved.

touch - 

Dont forget the 

\A  \z  ( start of string, end of string )

Case for State Machines:

Adding a lot of datetime or boolean fields in the db, especially when they depend on each other.

Lot of boolean logic in the model.

Key Vocabulary:

State

Event

Transition

Migration:

Column called 'state' in the table

In the model, add a call to state_machine

Steps:

Run specs

Do some basic reading

Whiteboard the objectives & goals

Examine, Observe & Study all involved parts

A lot of tiny steps

Observe what is already done in great detail

Flow:

Go over what is already done, couple times & know the terminology

Run the specs

Fix the failing specs

Start coding after all green

Run specs

Fix code

Initialization

Initialized automatically to the initial state

Useful Methods:

Callbacks are methods that get called at certain moments of an object's lifecycle.

The problem with after_save is that the callback method might be triggered before the transaction is actually completed.

after_commit ensures that the transaction is either completed or rolled back.

1. Associations in Factories

2. Foreign Key Constraints in Factories

3. should receive in Rspec

Maps the url to the controller action

Also providers helper methods _path & _url to generate paths and urls

Resource Routing: Maps http verb & url to a controller action

Url = Host + Port + Path Prefix + Path

Use Namespace to organize controllers

Nested Resources: Common Practice is not to nest more than 1 level deep

Member Routes ( preview -  /photos/1/preview )

Collection Routes  ( search -  /photos/search )

Non Resourceful Routes - ( match )

Naming Routes

Constraints: Verb Constraints, Segment Constraints, 

Route Globbing: Using wildcards

Article.pluck(:article_id)

Article.maxium(:article_id)

Build software better, together.

Personal Style Choices:

Avoid numbers, like arr[0] arr[1] prefer arr.first & arr.last

Serialization of an object is to convert it to byte stream, for storing, future loading or sending it to another program.

Marshal ships with Ruby, but does do human readable formats

puts $:   Shows the load path

>> puts $:

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/site_ruby/1.9.1

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/site_ruby/1.9.1/x86_64-darwin12.2.0

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/site_ruby

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/vendor_ruby/1.9.1

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/vendor_ruby/1.9.1/x86_64-darwin12.2.0

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/vendor_ruby

/Users/gvinnakota/.rvm/rubies/ruby-1.9.3-p327/lib/ruby/1.9.1