body
  line-height:1.2em

h1
  color:red

This would render a blank document for /public/stylesheets/foo.css.  You won’t get an error about it, you’ll just get a blank document.  Here’s the thing, when you’re declaring a CSS property, you MUST put a space after the colon.  Failing to do so will just wind up in parsing errors on the sass side.

I hope I’ve saved you some head scratching.

/Users/[yourname]/[your-app]/vendor/gems: gem unpack [gem name]

It isn’t the end of the world if you don’t do it ahead of time, but it does make life slightly easier.

(2) Remember that when you find a bug, you should write a test for the expected behavior BEFORE fixing the bug.  “The Rails Way” has a great quote about testing:

“It’s not that Rails encourages you to do test-driven development, it’s that it makes it difficult for you not to do test-driven development.” ~Brian Eng

I’ve interpreted this quote into the following mantra:

“It’s not that rails makes it easy to test, it that it makes you pay when you don’t”.

Finding a bug after creating your test suite just means that you missed a test.  Take the opportunity to correct that.

Happy hacking.

(This applies to Rails 2.3.2 and perhaps earlier versions.)

From the documentation:

project.milestones             # fetches milestones from the database
project.milestones.size        # uses the milestone cache
project.milestones.empty?      # uses the milestone cache
project.milestones(true).size  # fetches milestones from the database

Normally, this is great. However, if you’re not aware of this default caching, you might see some strange behavior in your app or tests and have no idea what’s going on. This default caching behavior had me and Abel stumped until we read about it in the docs.

Working with the same concept as the example in the documentation, where a Project has many Milestones, here’s a more explicit example of the caching behavior in action:

project_1 = Project.find_by_id(1)  
project_2 = Project.find_by_id(1)  
# Load the same Project into two variables
 
project_1.milestones.length   
# - Hits the db's Milestones table.  
# - Caches milestones object on project_1.
# - Returns 0. 
 
Milestone.create(:project_id => 1, :name => 'New Milestone')  
# Adds a milestone to the project. 
# But we don't do it through the project_1.milestones association
# because that _would_ update project_1.milestones's cached value
 
project_1.milestones.length   
# Returns 0 (not 1, like you'd expect) 
# because project_1.milestones was cached when 
# previously requested above.
 
project_2.milestones.length  
# Returns 1, because project_2.milestones 
# hasn't been requested/cached yet.
 
# Note: project_2.milestones is 
# a COMPLETELY DIFFERENT IN-MEMORY OBJECT 
# than project_1.milestones.
# Taking this point further, here's an explicit example:
 
project_2.milestones << Milestone.create(:name => 'Another Milestone')
# Put another milestone on the project through 
# project_2's milestones association.
 
project_1.milestones.length
# Still returns 0, because project_1 already cached it's copy of 
# the milestones association back when there were 0.
 
project_2.milestones.length 
# Now returns 2, because only project_2 knows about the new milestone.
 
project_1.milestones(true).length  
# Returns 2, because ActiveRecord updates the cache 
# when association(true) is present.

Another funny something to note about the association caching behavior is that even when ActiveRecord uses a cached value, it still emits SQL to the log file. So, don’t let that trip you up either.

Given /^I am browsing the site using Safari$/ do
  header "User-Agent" , "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us)"
end

Like me, you may have found out the hard way that this doesn’t work. Webrat does not automagically apply these new HTTP headers to your request – they certainly don’t make it to my controller. What worked for me:

Given /^I am browsing the site using Safari$/ do
  headers["User-Agent"] = "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us)"
end
 
When /^I visit my precious site$/ do
  get '/my/precious/path', my_query_string, headers
end

In the code above, headers is a method call that returns all the HTTP headers for your request. Just tack headers on as the third argument of your request, and you’re good to go.

Thing 1: FasterCSV is really cool!  It’s easy to use and does exactly what it should.  Here’s Scott Becker’s exporting tutorial.  For importing, i’ve hacked together bits from Peter Larkmund’s travels and the FasterCSV documentation.  Thanks to these tutorials, AMB will give users the ability to upload and export CSVs.

Thing 2: Default values for the win!  If you have a table that has a column for an amount, feel free to set the default value to 0.00.  Otherwise you won’t be able to do the following:

a = Account.new
a.amount += 20

…because a.amount will be nil.  You’ll throw an error and if you just updated a bunch of code, you might waste an hour trying to figure out why you’re throwing an exception.  However, if you declare a default value, you’ll be able to avoid any issues.

If you want me to go into further detail on either thing, just leave a comment.

Thanks for reading and happy hacking.

Reduce your feature list
When I first started AMB, I wanted to do a TON of things:

• Implement Calendar & tabular layouts for my transactions.
• Add AJAX sliders, like Kayak.com, which would allow users to view a range of transactions and dynamically update the sum of those transactions.
• Add Dynamic charts of data like Finance.Google.com where users could dynamically add tracked months to the chart to compare trends.
• Create a way to track my checking, savings, & credit cards as individual accounts with individual transactions.
• Create a way to track credit card payments or moves from checking/savings.
• Track an estimated balance & current balance for each month for each account.
• Create a way to display and create recurring transactions.

Yeah…while ambition is important, limits are also important.  Getting all of these things done for v1 is possible of an experienced web team, but as a sole developer trying to scratch an itch and learn something at the same time, it’s not realistic.  Implementing all of these features and fixing bugs would take way too much time.  I needed to remember the original mission of replacing my budgeting spreadsheet.  To help reorient myself with my goal, I took another look at my spreadsheet and compared it against my feature list.  I noticed the following:

• I only have a tabular view of my transactions.
• I don’t have any AJAX sliders.
• I don’t have any charts.
• I don’t track my credit card or savings balances in the spreadsheet.  In fact, 90% of the time I use my debit card so it’s really all coming out of checking anyway.  Once I put money into savings, I don’t touch it again.
• I do track my current monthly estimated and running balances for my checking account.
• I implement next month’s budget by copying the previous month and editing values/dates where necessary.

This really helped to put things in perspective.  V1 really needs to give me the ability to enter and track the transactions of 1 account without any sexy AJAX or Flash.  The 1 feature I did want to implement was recurring transactions, but I’ve worked around this limitation already and clearly it’s not critical for v1.

Do it the wrong way, but get something out
The beauty of web development is that it’s not like building a car.  Car manufactures deploy once a year.  Websites can be deployed and re-deployed every hour on the hour if we want.  Implementing new features and optimizing code is part of the fun.  As a newbie, you’re going to put code that should be in your model in your view or helper code in your controller.  It’s ok.  Getting yourself into the correct mind set for where code lives takes time.  For v1, if you can get the desired effect, call it a victory and move on.  If this project becomes something that you want to maintain and improve upon, you will.
Also, though test driven development (TDD) is ideal, feel free to get something out without it.  TDD is something that you can come back to if you’ve started without it.  HOWEVER, I’d advise that you stop yourself from advancing to v2 without creating a few REAL tests first.

No one will judge you harshly
Well, that’s not true.  There will be jerks to will give you a ton of crap for not having a “MUST HAVE” feature in your app and how you’re dumb for not implementing it first.  Honestly, F@#$ those people.  You have to realize that your first rails app isn’t about pleasing the world.  It’s about the realization of your idea and getting it out the door.  That’s not to say you shouldn’t listen to a good idea here or there, but don’t feel bad if everyone isn’t a fan.

That’s it.  Now get out there and get v1 f@#$ing done and enjoy your release!

Solution: assert_select 'input[name=?]', 'model_name[field_name]'

Thanks to the Boston Ruby Group thread for the answer.

Bonus: Here’s a helpful assert_select cheat sheet.

The Context: We had a table of records were using remote_form_for to output an edit form for each row so that we could allow inline editing of any row via AJAX. The code looked something like this:

-remote_form_for(person) do |f|
  %tr
    %td
      =f.text_field :first_name
    %td
      =f.text_field :last_name
    %td
      =f.submit 'Save'

If you prefer straight HTML, the relevant code looked something like this:

<form>
<input name="person[first_name]" type="text" />
<input name="person[last_name]" type="text" />
<input type="submit" value="Save" />
</form>

The Problem: When submitting an edit on any of the people rows, we would see an ActionController::InvalidAuthenticityToken exception in the server log. This error is usually a sign of a configuration problem with your environment, but our case seemed different. Firebug showed us that the browser didn’t appear to be passing any params to the server during it’s update post and the server log didn’t show any params coming through, either. So, it wasn’t an invalid authenticity token being passed; no token was being pased at all. I would prefer if Rails gave us a MissingAuthenticityToken error instead but I digress.

The Discovery: After whipping up a test case where we had a remote form on a page working fine with no errors, we discovered that the problem only occured when the form was wrapping the record’s table row tag in the view. And, well, this makes a good deal of sense. Here’s what the HTML 4.01 spec says about FORMs and TABLEs (relevant lines from the spec have been pasted below in a convenient order):

<!--ELEMENT TABLE - -
     (CAPTION?, (COL*|COLGROUP*), THEAD?, TFOOT?, TBODY+)-->
<!--ELEMENT TBODY O O (TR)+   table body  -->
<!--ELEMENT TR       - O (TH|TD)+          table row  -->
<!--ELEMENT (TH|TD)  - O (%flow;)*         table header cell, table data cell -->
<!--ENTITY % flow "%block; | %inline;"-->
<!--ENTITY % block
     "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS"-->

If you’re not used to looking at DTDs, all that synax can be hard to grok. Here’s what the relevant parts of it say, in plain English:

• TABLEs must have a TBODY
• TBODYs must have a TR
• TRs must have THs or TDs
• TDs can have any elements inside them as long as those elements belong to the flow group
• The flow group consists of elements inside the block group and the inline group
• FORM elements are part of the block group.

So, what was happening was that the browser saw our FORM element defined as a sibling to the TR. That’s not allowed in the spec, so it makes some bit of sense that the browser wouldn’t pass the form data to the server the way we expect it would. After all, the browser is dealing with invalid markup here.

The Solution: The solution we found was to wrap the form input controls inside one big table that’s wrapped by the form tag, like this:

%table
  -@people.each do |person|
    %tr
      %td
        -remote_form_for(person) do |f|
          %table
            %tr
              %td
                =f.text_field :first_name
              %td
                =f.text_field :last_name
              %td
                =f.submit 'Save'

Again, in HTML:

<table border="0">
  &lt;% @people.each do |person| %&gt;
<tbody>
<tr>
<td>
<form>
<table border="0">
<tbody>
<tr>
<td>
<input name="person[first_name]" type="text" /></td>
<td>
<input name="person[last_name]" type="text" /></td>
<td>
<input type="submit" value="Save" /></td>
</tr>
</tbody></table>
</form></td>
</tr>
&lt;% end %&gt;</tbody></table>

Note: at this point we’re using a table for layout, and it’s nasty as all hell. I don’t recommend that you structure your markup this way.

But, this example illustrates is how you can use a FORM element inside of a TABLE and have it actually work. And, more importantly, now we know why we were getting an InvalidAuthenticityToken error when everything seemed like it should have worked.

Hope this helps anyone else in the same situation.

Well, you might try something like executing each named scope that you have params for and find the intersection of the IDs of all people returned from each named_scope. That might look something like this:

p1 = Person.by_last_name params[:last_name] if params[:last_name]
p2 = Person.by_age params[:age] if params[:age]
p3 = Person.by_sex params[:sex] if params[:sex]
 
people += p1 if p1.length + p2 + p3

What you really want is Ryan Bates’ Scope Builder gem.

Scope Builder lets you “build up named scopes conditionally.”  From the README:

This gem adds the scope_builder method to all Active Record models. A
builder behaves exactly like any other named scope except that calling
other named scopes on it will alter the builder itself rather than
returning a new named scope.

Here’s some example code using that defines Person.search using named scopes for last_name, age, and sex:

class Person < ActiveRecord::Base
  named_scope :by_last_name, lambda { |last_name|
    {
      :conditions => ['last_name = :last_name',
        { :last_name => last_name } ]
    }
  } 
 
  named_scope :by_age, lambda { |age|
    {
      :conditions => ['age = :age',
        { :age => age } ]
    }
  } 
 
  named_scope :by_sex, lambda { |sex|
    {
      :conditions => ['sex = :sex',
        { :sex => sex } ]
    }
  }
 
  def self.search(options)
    scope_builder do |builder|
      builder.by_last_name(options[:last_name]) if options[:last_name]
      builder.by_age(options[:age]) if options[:age]
      builder.by_sex(options[:sex]) if options[:sex]
  end
end

So, now all you need is a People Search form and an action to handle finding the right people.  Here’s what your search action might look like inside PeopleController:

def search
  @people = Person.search(params).all
end

Important note: When using ScopeBuilder as shown above, you’ll have to call #all because, in this case, Person.search returns a ScopeBuilder object, not a collection of ActiveRecord Person objects.  To get at the people collection, you call #all on the ScopeBuilder object returned by Person.search.

So, see?  Isn’t that pretty?  You’ve got a simple search that will find all the people that meet any all of the attributes passed in from the search form.  Ta da!

The solution was quick & dirty (as most solutions are during Rails Rumble), but the results worked, and allowed us to qualify for judging and reach a respectable 28th place finish in the “Completeness” category.

Check out the details after the fold.

Design Constraints

Great Minds is a word game played by 2 or more players. The game is played in a virtual chat Room, containing one or more Players. Players can take various actions, such as submitting a word to the game, chatting, or changing their handle/username. The results of these actions must be transmitted to other players in the room.

Other constraints on the design included:

• No New Technologies: There are tools like Juggernaut that make messaging pretty easy, but we had no hands-on experience with them, and learning a new tool on a 48-hour schedule was deemed a risk to completing the project & qualifying for Rumble judging.
• Broadcast: We needed something more than a simple message queue like Beanstalk; the consumer of a message couldn’t remove it from the queue, as there might be other consumers needing the same message.
• Room State Reconstruction: Someone coming to the room for the first time (or leaving and returning) should be able to see the current room state, including all participants, recently played words, and recent chat.
• Replay: Though we didn’t get around to implementing it, we wanted to offer the ability to review a particularly funny game.

The first two constraints affected our design and technology choices; the second two demanded that the messages be persisted. (Alternatively, we could have saved the room state in some other way, but as long as we had the messages anyway, it seemed simpler to just keep them and reconstruct the state.)

Client Implementation

In the absence of a viable push solution like Juggernaut, we opted for a polling solution: Clients would periodically send a signal that:

• let the server know they’re still alive and connected,
• sent any new messages to the server, and
• requested any pending messages from the server.

On the client side, this meant that every message got packaged as JSON, stuck in a queue, and periodically collected and sent to the server as the optional payload of a keep-alive signal. With some help from Prototype, this was as simple as:

  function SyncMessages() {
          var data = Object.toJSON(MESSAGES_QUEUE);
          var url = '/room/sync_messages';
          var params = {
                  authenticity_token: AUTH_TOKEN,
                  messages: '[]',
                  //messages: Object.toJSON(MESSAGES_QUEUE),
                  last_message_id: LAST_MESSAGE_ID };

          new Ajax.Request(url, {
            method: 'post',
                  parameters: params,
            onSuccess: HandleMessages });
  }

  SyncMessages(); //start first on load
  var message_syncer = new PeriodicalExecuter(SyncMessages, 3);

HandleMessages() updates the DOM based on messages coming back.

The other feature to note is the LAST_MESSAGE_ID token above. Each client is responsible for keeping track of the last message ID it got. On the server side, message IDs are assigned sequentially, so all new messages are guaranteed to have a higher ID.

We could have kept track of each client’s last message on the server side, but this would have been much more complex – we would have needed to store data either in the session (which already held a fair amount of stuff) or in another table in order to keep track of who had received what.

Server Implementation

On the server side, messages were persisted in a table. This table would have relatively frequent inserts, somewhat more frequent reads, and no updates or deletions. For this reason, we went with the default MyISAM table architecture. (We had considered a design that would have updated the table with delivery status information and would have required InnoDB’s row-level locking, but in the end we opted for the simpler design.) The table looks like:

  class CreateMessages < ActiveRecord::Migration
    def self.up
      create_table :messages do |t|
        t.integer :message_type_id, :room_id, :game_id, :user_id
        t.string  :data, :user_handle
        t.timestamps
      end
    end

    def self.down
      drop_table :messages
    end
  end

It also has an index:

  class AddRoomIndexToMessages < ActiveRecord::Migration
    def self.up
      add_index :messages, [:room_id, :id]
    end

    def self.down
      remove_index :messages, [:room_id, :id]
    end
  end

Recall that the client keeps track of the last message it got, and periodically requests all messages since. This index speeds that request - which is just msgs = Message.find :all, :conditions => ['room_id = ? AND id > ?', session['room_id'], last_message_id], rder => 'id'. (Yes, I know that should be a named scope. I hadn't gotten around to learning those yet at the time of the Rumble.)

When the a keep-alive signal hits the server:

• any new messages attached to the signal are added to the messages table,
• any game mechanics related to those messages are executed (which may result in more messages being added to the table), and
• all messages for the caller's room with an ID greater than the caller's LAST_MESSAGE_ID are packaged as JSON and sent back down in the HTTP response.

A note: If you're in a room and you enter (for example) a chat message, there's actually a server round-trip involved (pushing the message to the server and getting the same message back as a response) before that chat message is shown in your browser. We worried about this, but not for long - the interactivity delay turned out to be minimal, and it was much simpler to keep it this way (every message is treated the same for all clients) than to create an exception (you update your DOM with your chat messages immediately, but your own chat messages are somehow filtered from your message stream).

What's Missing?

Obviously, this was a quick & dirty solution, tailored to the immediate needs of a Rails Rumble project. Here's what I'd do differently (and indeed, will do differently, as we have plans for the future of Great Minds - stay tuned):

• Security: We do use the Rails session authenticity_token, but there's still no protection from a server flood from someone who has a token, either by cranking down the polling interval or by fiddling with the LAST_MESSAGE_ID.
• Server Push: Polling is wasteful - requests are made whether or not there are any messages to send or receive. We plan to move to Juggernaut soon.
• Decoupling from Game Mechanics: In the first iteration, message receipt and delivery were too intimately tied to game mechanics, with Message objects being explictly constructed and followed by Message.save! calls. I've already started the process of teasing them apart in preparation for the move to Juggernaut, factoring this into a deliver_message() method.

Questions? Thoughts? Add a comment! I promise to get back to you.