Rails Coach

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

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)

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.

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.

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.

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.

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

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

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   

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)

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

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.

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/.

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 true end class Page :commentable end class Post :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”.

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