I like stuff.

To my surprise, Post.all in Rails 3 performs the query immediately. It does not do lazy loading, as Arel’s where method does.

def index
  @posts = Post.all     # not lazy; returns Array
end

It turns out this is by design. See Force loading – all, first & last.

So: what do you use if your view has fragment caching and you want your controller’s index method to delay the query until you’re sure you’ll need to use it?

At first I did this:

def index
  @posts = Post.where('1=1')  # returns ActiveRecord::Relation
end

But the documented way is to use the scoped method:

def index
  @posts = Post.scoped        # returns ActiveRecord::Relation
end

Another alternative I recommend, which lets you do lazy execution queries in any version of Rails: move the queries to helper methods.

I recently started a new project in Rails 3.0 and decided to try SQLite as the development database. In the past I’ve always used MySQL for my Rails projects. I’m hosting the app on Heroku so it’s PostgreSQL in production, making this my first time using SQLite and my first time using different databases in development and production.

At first I was having fun with SQLite. It’s lightweight, doesn’t use much memory, runs fast on a local dev machine. A single database is stored in a single file. No server to configure, no nothing. Nice.

But I gave up on it after about five days because of an annoying limitation that bit me twice: if you add a NOT NULL column (:null => false in your migration) to an existing table, SQLite requires you to specify a default value—even if the table is empty.

It makes sense to require a default value on a NOT NULL column if there are already rows in the table. All relational databases require that. But if you don’t want to specify a default and the table is empty SQLite shouldn’t force you to.

I found discussions where people suggested a workaround of “Can’t you just drop the table and create a new one? As the table is empty, you won’t be losing any data.” Sure, but it’s far more error-prone to recreate the table because it’s not an incremental change. You have to carefully reconstruct the table and all indexes from all past migrations, which became unwieldy for me even in a 5-day-old project. It really is more error-prone: I tried it and screwed up a couple of times. That was it for me, so I decided it’s time to switch back to MySQL for local development.

The other experiment—using different databases in local development and production—is still going fine. We’ll see what snags I hit that make me change my mind about that too. I still wouldn’t do that on a big project but this is a little ol’ thang.

Mark Nottingham is on a tear. Last week he sent me a pull request for a bunch more changes he made to the exportiphoto app that lets you export iPhoto events or albums to folders.

The most notable changes:

• It uses less memory. This matters if your iPhoto library is huge, because you will no longer overwhelm your Mac’s memory when exporting the photos to folders. It now uses a SAX parser so it no longer has to load the entire iPhoto XML file into memory.
• It shows better progress than before, telling you how many events/albums it has processed so far and how many there are total.
• If you want, it can copy photo metadata (image name, description, keywords, faces, and rating) into the exported photos.

In July I blogged about the script Derrick Childers wrote to export iPhoto events to folders. Yesterday, Mark Nottingham made some improvements to the script. The best change is that you can now pass in parameters on the command line instead of modifying the script to change the parameters.

I’ve pulled his changes into the script on my github repo.

After being hosted for a couple of years at a subdomain of WordPress.com, my “I like stuff” blog finally has its own custom domain.

Announcing: http://ilikestuffblog.com

I wanted to export my iPhoto library to a folder structure and was disappointed to see that iPhoto has no built-in way to do it.

I found a nice little script written by Derrick Childers (scroll down to his comment; don’t use the original shell script) that did almost exactly what I needed. Derrick’s original version exported all events by year, except it didn’t work in all cases because it was based on the year of the photo’s filestamp, which might be different than the year it was taken (e.g. if you went back to retouch a photo). Guillaume Boudreau added support for exporting albums and removed the year folder because it didn’t work well, but I put it back and fixed the it to generate the year based on the event date.

(Update: I changed it to generate more than just the year. I generate the entire date of the event, followed by the event name.)

I tested it with:

• Leopard 10.5.8
• Python 2.5.1
• iPhoto 8.1.2

Derrick tested his original with:

• Snow Leopard 10.6.2
• Python 2.6.1
• iPhoto 8.1.1

I’ve posted it to Github. Feel free to fork and modify to your taste.

I just read a fascinating history of HTML, up to HTML5 by Mark Pilgrim.

One sentence keeps repeating in this essay:

“The proposal was never implemented.”

Pilgrim’s point is that shipping software wins over specs and ideas. Or in his words, “The ones that win are the ones that ship.” (Although he points out that shipping code is necessary but not sufficient for success.) A number of times HTML was “retro-specced” to match what had already been implemented.

I like that. In 2006 I coined the term “Action-Oriented Programming” on a Joel on Software discussion board:

Regarding motivation to get started implementing a product idea once you have one:

Whatever you do, do something.

Us programmers, we tend to overanalyze things. Lots of up-front design, trying to decide if it’s the right thing to do, not sure if we have enough education yet, etc. But from what I’ve read about successful entrepreneurs, they are DOERS. They’re Action-Oriented.

So I’m inventing a new term:

Action-Oriented Programming: writing the damn program instead of thinking about writing it.

The HTML spec evolved through Action-Oriented Programming. Read the History of HTML essay and you’ll see why.

P.S. Hey, I know I didn’t invent the idea of favoring working code over detailed specs. But I like the name I gave it. :-) I’m pleased to see that Action-Oriented Programming has become popular with the rise of agile techniques and “Getting Real.”

On the weekend while I was stuck in traffic trying to take my son to his (and my) first monster truck jam, I listened to this podcast about the Go language. It helped me understand why Google would invent a new language. Then I looked at the language spec a bit.

Here are some first impressions. I’ve only read lightly about the language so please correct me if anything is factually incorrect.

I’m not super-pumped about using Go, but if I were still using C/C++ every day I probably would be. I now think of Go as C (runs about as fast as C, strongly typed, compiled, pointers) but with a few especially nice enhancements:

• garbage collected (yay!)
• memory-safe – the pointers can’t go out of bounds and I think arrays also can’t go out of bounds if you use “slices”
• extremely fast compiles.

It is missing some of the things I like about C++. E.g.,

• You can’t use integers or pointers as Boolean expressions
• I don’t think it has a convenient syntax for getters+setters with a default backing variable, like Property in C# or attr_accessor in Ruby. (It bugs me how verbose Java is when creating simple bean properties. I hope Go will avoid this problem.)
• I don’t yet see a way to do automatic cleanup when a variable goes out of scope–a feature of C++, C#, and Ruby that I love because it helps reduce code duplication and add robustness

It appears not to be OO, at least not in the way we’re used to. It doesn’t have classes but it does have interfaces. It seems like if you want to make a class you define an interface and then create an instance of it. It doesn’t have traditional inheritance but it does have “embedding,” which is a nice alternative. If you embed someone else’s implementation of an interface into your type, your type now exposes that implementation without having to delegate all the methods one by one.

Lately I’ve been into Ruby, which has different strengths than Go. But if I were to start doing systems-level programming again and needed a good mix of raw performance and garbage collection I would definitely give Go a close look.

I am Brian Morearty. Welcome to my blog.

I’m a software engineer living with my wife and three kids in the San Francisco Bay Area.

I plan to blog about stuff like software development, things that strike me as funny, etc. The technology that currently has my interest is Ruby on Rails and Flex but that may change over time. For most of my career in software I’ve been working on Windows, and I’m also a fan of most Microsoft developer technology (WPF, ASP.NET, and so on.)