Today, just a quick message outlining the future of Rails Coach.

Rails Coach

Reboot

CoffeeScript is a language written by Jeremy Ashkenas that compiles to Javascript. Its syntax is much more friendly than native JavaScript. Especially if you're used to languages like Ruby or Python. As or Rails 3.1, CoffeeScript is available by default and a coffeescript file is created in /app/assets/javascripts every time you run the scaffold generator. A few of my favorite features of the language are: I can ignore parenthesis (mostly), semi-colons, and curly braces Function notation Objects with nested notation Variable safety (not creating globals) Splats on lists Classes Always returns last expression String interpolation I don't like: Operator aliases Resources: CoffeeScript Webpage CoffeeScript Cookbook CoffeeScript Basics (video) CoffeeScript: The Cool Parts (video)

032 RC CoffeeScript

A generator is a way of creating code from the command line. Rails has several of these built in, including generators for models, controllers, tests, helpers, scaffold (models, views, and controllers that support Rails' RESTful routing), and much more. Generators are actually relatively simple. They are made up of two parts. The generator itself, and the generator's templates. In the Ruby on Rails source code there's an assets generator and the javascript template and stylesheet templates it uses. I've also created a model generator for my Sandra ORM. You can find it here. Understanding how models work, you can see how simple it is for the Rails Core Team to build in generators for other things like models, controllers, helpers, tests, assets, mailers, etc. To see the full list of generators available in a Rails application run `rails generate` or `rails g`. To create your own generators in your project, put them under /lib/generators or better yet, use the generator for generators like this: `rails generate generator widget` and you'll get a widget generator all set up for you in the /lib/generators folder that's ready for you to customize.

031 RC Generators

NoSQL is a terrible term for a collection of widely varied databases. You have key-value stores like Redis, Tokyo Cabinet, Memcached, etc. You also have document databases like couchDB and mongoDB. Finally you have column based systems like Cassandra. And still others like HBase. In a lot of cases, there are gems for these. I've used several of them such as the gems for managing Cassandra, couchDB, and mongoDB.

030 RC NoSQL

I've been using Backbone.js for a few weeks and really like the way it helps you manage your data on the client side. It's also a terrific way to keep your UI in sync when your data changes through Javascript events.

028 RC Backbone.js

One of the most handy websites out there for people trying to find specific API's in Ruby is ruby-doc.org. From the main page, you can search or select your Ruby version. From the core page, you can narrow down the class or method you're looking for. From the std-lib page, you can read docs and see where different aspects of the programming language are implemented. On each class' page, you can find the specific functionality you need in the menu on the left.

029 RC Ruby-doc.org

I've been using VIM for a while to do my development. It's a terrific text editor that has been around for quite some time. Here's the rundown of what I've got set up. MacVim: http://code.google.com/p/macvim/ Janus: https://github.com/carlhuda/janus I've also found a few resources to help me get better with Vim as well. Here are some of my favorites: VimCasts: http://vimcasts.org/ VimGolf: http://vimgolf.com

027 RC Vim

A counter cache is a handy way to speed up queries where you only need the number of an associated model rather than the entire collection. In your code, you might see something like this: @post.comments.count When you run this code, you wind up with another query to the database to get that number. That's not a big deal until you have that count being called for each post in your stream. To avoid this, you can use a counter cache. To use the counter cache, add a _count to the primary model's table. In this example, it would be called "comments_count". class AddCounterCacheToPosts < ActiveRecord::Migration def change add_column :posts, :counter_cache, :integer end end With that migration in place, all you need to do from there is add :counter_cache => true to your other model—in this case Comment. class Comment < ActiveRecord::Base belongs_to :post, :counter_cache => true end Now, whenever you create or delete a new comment for a post, it'll update that counter_cache column on the posts table. A few things to keep in mind are: If you're adding this to an existing system, you'll probably have to add a data migration to set the counts. This number is not checked each time it's changed, so if you change the number, you'll get results in the future relative to that number.

026 RC Counter Caches

Eager loading is a terrific way of speeding up your response times. Let's consider a piece of code that pulls a list of associated objects from the database. For example, a view that displays the posts written by a given user: (I know that partial has a collection option for things like this. I feel that this code sample is more expressive for our discussion.) In this case, assuming that @user was loaded by calling User.find(1), your Rails application is going to go to the database for each post. So, if the user has 40 posts in the system, the Rails application will make 40 trips to the database to get the posts. The problem is that if there is any latency on the database connection, it adds up. The fix for this is the use of the 'includes' method when querying for the user. User#includes tells the query to pull in whatever associated records you specify in its arguments. So, if we found @user by calling User.includes([:posts]).find(1), it would pull the user's record and all of the user's posts records and cache all of the user's posts on the user's object. The argument for 'includes' is an array. The objects in the array can be symbols or hashes. Symbols represent that associations the Model has. Hashes are used for including nested associations. For example, if we wanted to pull all of the comments on the user's posts. Here's another example: # In the controller @user = User.includes([:address, :phone_number, {:posts => [:comments]}]).find(1) # In the view    

025 RC Eager Loading

Assets in Rails before version 3.1 were kept in the /public folder. In Rails 3.1 they've been moved to /app/assets and function in a slightly different way. Here are some of the highlights: Javascript assets written in Coffeescript will now be compiled to Javascript. CSS assets written in SASS or SCSS will now be compiled to CSS Other templating languages like ERB can be used in assets JQuery is now the default Javascript framework in Rails 3.1 You can combine Javascript files with the new directives Pre-compiled assets When compiling from SASS, SCSS, CoffeeScript, or ERB, you simply add the appropriate extension to your .js or .css file. (.sass, .scss, .coffee, or .erb respectively) To combine several Javascript files into one file, (for example application.js) just do something like this. //= require jquery //= require jquery_ujs //= require_tree . //= require_directory tooltips   For several CSS files, it's the same commands, just *= instead of //= and wrapped in /* ... */. Here's a quick example: /* *= require reset *= require base *= require_tree . *= require_directory tooltips */   require pulls in a file. require_tree gets everything in the specified path. require_directory pulls in all the files in a given directory (no nesting). You can precompile your assets by running bundle exec rake assets:precompile (For example, if your server doesn't have a Javascript runtime on it capable of compiling Coffeescript.) Here are some resources for CoffeeScript: The Coffeescript Website CoffeeScript Basics (video) CoffeeScript: The Cool Parts (video)

Rails 3.1 Asset Pipeline

About a month ago, I talked about ActiveRecord Callbacks. Observers are a way of moving callbacks out of the Model. Usually this is done to adhere to the Single Responsibility principle. So, for example, programmers will move sending an email when a record is updated or created to an Observer. class UserObserver < ActiveRecord::Observer def after_create(user) UserMailer.sign_up(user).deliver end end   Observers should be included in your app/models folder and named using the same convention as your models. So in this case, this observer would be saved to /app/models/user_observer.rb. To load the observer in your application, you need to include this line in your config/application.rb config.active_record.observers = :user_observer   Finally, you can observe more than one model with the same observer. class SignUpObserver < ActiveRecord::Observer observer :user, :admin def after_create(user) UserMailer.sign_up(user).deliver end end   I personally like Observers when they help keep you from repeating code or increase code readability. In many cases, I simply keep callbacks in models and violate the Single Responsibility Principle.

ActiveRecord Observers

I’ve been working on an ORM for Cassandra. One of the things I’ve been using to build the ORM is ActiveModel. ActiveModel gives you modules you can add to your class that makes it behave like an ActiveRecord Model. Here are some of the features you can add to your classes with ActiveModel. Attribute Methods Callbacks Dirty Attributes (knowing which attributes have changed) Naming (allows you to reference the class and model by the object) Observers Serialization (to JSON or XML) State Machine (a really basic one) Translation Validations So, if you’re looking to add your Ruby class to a Rails app, or want this sort of behavior in Sinatra, etc. this is a great way to get it.

ActiveModel – Making Ruby Classes Behave Like Models

Building web forms in Rails was something that confused me when I was new to the framework. This is probably due to the fact that there are some methods that are a lot alike and there are a couple of ways of instantiating a form that do different things. The first way of building a form that is probably the most common is by using the ‘form_tag’ helper and the form helpers to build forms. Here’s an example. Pretty straightforward and it builds a standard login form. I’d get confused because there are also helpers that correspond to ‘label_tag’, ‘text_field_tag’, and ‘password_field_tag’ that do something very similar. Here’s a user signup form that use these similar tags: You’ll notice that these helpers use two parameters to build the form’s elements. It effectively scopes or namespaces those form parameters. They’ll be named “user[username]”, etc. If you’ve gotten that much, then ‘form_for’ won’t be too much of stretch. ‘form_for’ takes a model object as a parameter and binds the form to that object. It does the namespacing implicitly, which means that ‘label’ and ‘text_field’, etc don’t need two parameters to name the element. Just one. So, you’ll notice that the ‘form_for’ passes a parameter to the block. That parameter is a FormBuilder that contains the object, scopes the elements, and sets their values. Finally, go sign up for the Rails course at http://railscoach.com/ruby-on-rails-courses/.

Web Forms in Ruby on Rails

Rails has the concept of Polymorphic associations, which are associations that can be of different data types. For example, let’s say we have a Comment model. A comment in your app can be on a post or a page. Rather than creating a PostComment model and a PageComment model, you can set up your Comment model to have a polymorphic association to a Page or a Post. Generally people call these associations “something-able”. In this case, it would be commentable. Here’s a quick code sample: class Comment < ActiveRecord::Base belongs_to :commentable, :polymorphic => true end class Page < ActiveRecord::Base has_many :comments, :as => :commentable end class Post < ActiveRecord::Base has_many :comments, :as => :commentable end The only other thing you need to know is the database structure. On the database, you need two columns. A [polymorphic-association-name]_type string column and [polymorphic-association-name]_id integer column. In this case, it would be “commentable_type” and “commentable_id”.

Polymorphic Associations

ActiveRecord models are based upon tables in relational databases. This, of course, means that they can be relational. Models can associate in three main ways: one to many, one to one, and many to many. One to many is usually achieved by calling has_many on the model representing the “one” to state that it “has many” of its counterparts. The model that represents the “many” calls belongs_to . Here’s an example: class User < ActiveRecord::Base has_many :posts end class Post < ActiveRecord::Base belongs_to :user end In addition, the model that represents the “many” needs a reference column or foreign key for the “one”. In this case, the posts table would have a user_id column. One to one works the same way one to many works except it uses has_one instead of has_many. Many to many is implemented in one of two different ways. The first--and generally default--way of doing this is has_and_belongs_to_many. As you can imagine, this is used just like has_many or belongs_to except you call it in both models. class Tag < ActiveRecord::Base has_and_belongs_to_many :posts end class Post < ActiveRecord::Base has_and_belongs_to_many :tags end

hubhopper

Rails Coach

hubhopper