link[rel='developer']

There’s an emphasis in the Rails community on testing as you write your code. So much so that the built in code generators will generate unit tests right alongside your models. You can even generate integration tests too.

So here we are, merrily generating models, controllers and more. We’re writing code, writing tests and even running the tests to make sure they pass. All is good, right?

Wrong.

How many of you test your reverse migrations? Do they even work? I was bitten by this recently. The column names in a migration were spelled incorrectly so I thought, no problem, I’ll migrate down, fix the script and migrate up again.

Not so fast! The down migration was dropping columns that hadn’t been added yet — an error caused by modifying the migration before reversing it. Another error was caused by a misspelled table name, it wasn’t pluralized.

Since I’m working with mysql, ddl isn’t wrapped in a transaction. My development database is a snapshot of the customer’s data so dropping the whole database to recover from the failed migration isn’t an option either.

My advice: after creating a migration, migrate up, then immediately migrate back down. Make sure it works before moving on. The time you save might just be your own.

Comments Off
Filed under: Rails

It’s been a long time since I’ve worked on VisEmacs.net for varied reasons, the biggest being that I’m still stuck using Visual Studio 6.0. I’ve watched VS2002, then 2003, ’05 and now ’08 get released and I had no itch to scratch.

But you’ve had one. And it’s time that itch was scratched!

Without much further ado, I’m releasing an early version of VisEmacs.NET. It’s a far cry from what I envisioned but it works -mostly. There are a few rough spots that result in your document not being sent to Emacs but no data loss bugs that I’m aware of.

As of this writing, there is no documentation. There is however, an installer. It’s pretty simplistic — it will happily let you install VisEmacs.NET on a system without Visual Studio — but it does get the job done. It does create the right registry keys and register the right interfaces for the addin to be loaded in VS2002 and VS2003. I don’t think it will work in VS2005 due to changes in the automation interface.

Once you have it installed, you need to tell it where to find gnuclientw and gnudoit, unless they’re on the path. Configuration is integrated into the Tools | Options dialog. There are other options there, most of them work with the exception of “Send Build Results to Emacs” — that’s not done yet.

As always, feedback is greatly appreciated. Let me know if you like it, love it, or hate it. If you find a bug, please report it to me at jeff <at> snowmoonsoftware <dot> com. Want a feature? Something not working? Send it in! Add a comment!

Please remember that this software is provided as is, and no warranty nor guarantee is given, express or implied. While I take pride in my work, this is not a finished product and has not been exhaustively tested.

You can download the pretest here (3.8MB).

1 Comment »
Filed under: News, Visemacs

Last time, I promised that we’d make our testimonial application more friendly for users and less so for spammers and that’s what we’re going to do today, among other things of course. Let’s get’r done!

Somehow, we overlooked the user’s name when we created the schema for the testimonial leaving us only the email address to use as an attribution. Fortunately Rails’ migrations makes it trivial to add the new field. Drop into the shell and generate a migration:

script/generate migration AddUserName
     create  db/migrate
     create  db/migrate/004_add_user_name.rb
end

Open that in your editor, and make it look like the following. I think 64 characters is long enough to hold a name for this app.

class AddUserName < ActiveRecord::Migration
  def self.up
    add_column :testimonials, :name, :string, :limit => 64
  end  
	
  def self.down
    remove_column :testimonials, :name
  end
end

Alright, now we’ve added a place to store the user’s name.; we’ll let ActiveRecord handle the CRUD for us but it’s still our task to ask the user to enter their name. To that end, we need to edit the form that is used to edit a testimonial. We factored that out of the add view into a partial named _form.rhtml. Let’s ask for our customer’s name before we ask them to give up their email address, that seems more neighborly, don’t you think? At the top of the form, add the following:

 Read more...

Comments Off
Filed under: Rails, walkthrough