CoffeeScript is happening…

…whether you like it or not. Personally, I’m psyched — it looks like it solves a lot of the annoyances I’ve had with Javascript syntax, and I got a sweet deal on CoffeeScript: Accelerated JavaScript Development during the conference, which I hope to put to good use starting this week.

The Rails Community is Awesome

My wife’s response after she read my tweets upon my return:

“Just wondered, who is this guy? Dinner anyone? Share a cab? You became an extrovert on your mothership.”

It’s true, I did. It’s weird. I’ve never been to Baltimore before (save time spent between flights at BWI), but among my fellow Rails coders, I’ve never felt more “at home.”

As I thought about all of the people I finally got to thank in person for all they’ve done to make my time in the Rails community more enjoyable, it really drove home what an awesome community we have. It’s easy to lose sight of this while working away in Louisville, my little corner of Kentucky.

Aside from this, getting a chance to put a real face to a name, make and receive thank-yous for all the hard work we put in on Rails patches, plugins, and the like, has the effect of re-energizing a developer. I’d go on and list all of the awesome people I got to meet in person here, but I think it’d just make @casron more jealous.

I would like to say, however, that Emilio Tagua (@miloops) has got to be one of the friendliest guys I’ve ever met. I’d hoped to catch up with him to thank him for helping me get commits added to ARel back in the 1.x days that were needed for MetaSearch and MetaWhere. Instead, he ended up two seats over from me at Ignite, noticed I was hacking on a Squeel bug, and introduced himself first. Every time I saw him during the remainder of the conference, he had a smile and a kind word. Just an all-around great guy to have met.

PostgreSQL is awesome, too!

Now, I should have known this. I had started out using MySQL many years ago, when it had solid speed advantages over PostgreSQL, but far fewer features. Somewhere along the line, that balance shifted, but I stuck with MySQL due to familiarity. Nick Gauthier’s KnowSQL presentation has made a believer out of me. I’ll be using PostgreSQL as my RDBMS of choice from here on, and making sure that Squeel works as well as possible with it, too.

The Fundamentals are ALWAYS Relevant

There were tons of talks on design patterns, best practices, and so on, and even as long as I’ve been doing this whole coding thing, there are plenty of areas in which I can improve. In particular, Avdi Grimm’s talk, Confident Code, José Valim’s talk about the design principles behind the Rails 3 refactoring, and the talk on Building Bulletproof Views by John Athayde and Bruce Williams all challenged me to elevate my game in these areas.

HTML5 is sooooo much more than semantic tags

LocalStorage, audio, video, canvas drawing, web sockets, web workers — this stuff is all crazy cool and I can’t wait until more browsers support it. Mike Subelsky’s HTML5 tutorial was a real eye-opener.

That’s about it, for now. What were some of your takeaways from RailsConf this year?

Here is a simple example:

We’ll start with a table named libris_book that contains book entries. The name libris_book won’t really fly with the Rails pluralized table name approach. It’s easy, however, to fix that disconnect in the model:

class Book < ActiveRecord::Base
  set_table_name 'libris_book'
end

Let’s take a look at our data:

~/src/libris$ script/console
Loading development environment.
>> Book.count
=> 1230

Good enough. Now, we’ll be good little coders and write some unit tests using fixtures. We’ll create a fixture file and our test class:

books.yml

test_book:
  title: Life in Lawrenceburg
  author: Darren Day

book_test.rb

require File.dirname(__FILE__) + '/../test_helper'

class BookTest < Test::Unit::TestCase
  fixtures :books

  def test_fixtures
    assert_equal(2,Book.count)
    test_book = books(:test_book)
  end
end

Looks good, but it won’t work!

~/src/libris$ rake test
(in /home/darrend/src/libris)
/usr/local/bin/ruby -Ilib:test "/usr/local/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake/rake_test_loader.rb" "test/unit/book_test.rb"
Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake/rake_test_loader
Started
E
Finished in 0.01133 seconds.

  1) Error:
test_fixtures(BookTest):
ActiveRecord::StatementInvalid: Mysql::Error: Table 'libris_test.books' doesn't exist: DELETE FROM books
...

Ugh. That doesn’t look pretty. After some googling around the following comes together

• Rename books.yml to libris_book.yml. The fixture yaml file has to share the same name as the database table name.
• Change the fixtures declaration to fixtures :libris_book.
• Use set_fixture_class to connect the fixture to the model class.

Here is our new and improved book_test.rb file:

require File.dirname(__FILE__) + '/../test_helper'

class BookTest < Test::Unit::TestCase
  set_fixture_class :libris_book => Book
  fixtures :libris_book

  def test_fixtures
    assert_equal(2,Book.count)
    test_book = libris_book(:test_book)
  end
end

rake tmp:sessions:clear # Clears all files in tmp/sessions

Anyway it was easy enough to clean up the stale ruby_sess files by going into the rails webapp/session directory and then running the following command:

find -type f -name "ruby_sess*" -exec rm -f {} \;

I’m not sure why the app is creating sessions but it isn’t something that stores state so I didn’t have to worry about killing active sessions here. If you do need to worry about that you will probably want to toss a time on the find command.

After looking a little more I found a post about this that has a ruby way of cleaning up the sessions.