PLANET Ruby on Rails

On Thursday I presented remotely at RubyFest about MacRuby. I put together a 30 minute video and short demo app.

So, I’ve now been using BucketWise for almost two months, and it’s been fantastic. Admittedly, as the author of the application, I’m willing to overlook a lot of the warts and inconsistencies, but I can honestly say I’ve felt more control over my finances these last two months than I’ve felt in the last 10 years. It’s an awesome feeling!

Tonight, I tagged version 1.1.0 of BucketWise, which (if you haven’t been following along) fixes a few bugs and adds several new features (account reconciliation, memorized transactions, actor name autocompletion, simple budget reporting, and more; I’ll just refer you to the changelog for the full list). It’s really been a fun project to tinker on. The last feature I myself really want is scheduled transactions; I may be hacking on that one in the near future.

I figured this might be a good time to talk a little about how I, personally, am using BucketWise. I’ve been surprised by a few things, both good and bad: some features I’ve found to be less useful than I anticipated, and others have been surprisingly handy!

I’m not sure if this was ever stated explicitly has a preferred practice or not, but for the longest time many of us have recognized that using migrations as a way to populate the database with a base configuration dataset is wrong. Migrations are for manipulating the structure of your database, not for the data within it and certainly not for simple population tasks.

Well, this practice now has a formal support in Rails with the addition of the database seeding feature. Quite simply this is a rake task that sucks in the data specified in a db/seeds.rb. Here are the details:

Add or open the db/seeds.rb file and put in model creation statements (or any ruby code) for the data you need to be present in order for your application to run. I.e. configuration and default data (and nothing more):

Uncle Bob delivered a compelling keynote at RailsConf last week that put forth the argument that what we need most in programming is more professionalism. I loved the delivery, but I disagree with the conclusion.

I originally never wanted to be a programmer exactly because I thought the only type of programmers that existed where the kind that Bob talked about: The engineers with the proud professional practices that never wavered under pressure.

While I deeply respected that stature, it just never felt like a place that I belonged. I didn't identify with the engineering man or the seriousness of the efforts he pursued. Before I discovered Ruby, I felt in large parts that I was just faking my way along in this world. Here at a brief time for rent.

Ever want to know what Rails is doing under the hood during a request? In this episode I show three different profiling tools: New Relic RPM, FiveRuns TuneUp, and Rack::Bug.

So, there it is, we’ve done it, EuRuKo 2009 is over!

It has been a really pleasing experience for all of us on the organization team, we’ve had a really, really good time sharing ideas and code to organize the main european Ruby conference. I have to admit it, we were really surprised to see Spain was proposed as the candidate country last year in Prague. The czech team proposed Madrid as the candidate city to the group of spaniards that were there, and we were excited to hear it. We eventually changed it to Barcelona instead, as Madrid was already quite full holding the Conferencia Rails (that’s the Spanish Rails Conference that is held every November and organized by ourselves by the way: it’s amazing as well )

I’m glad to help announce RailsBridge, a great idea put forth by Mike Gunderloy. Mike invited me (and many others) last week to join his concept for a positive approach inside the Rails community, and so far things look promising.

Authentication can get very complex. In this episode I show how Authlogic can handle this complexity while you stay in control of how it is presented to the user.

Now that the internet hysteria is dying down, I'd love to explore some of the more concrete things that we could do to actually get more women involved. As I've stated earlier, I doubt simply refraining from having saucy pictures of pole dancers is going to do the trick. If that was all it'd take, it'd be easy beans.

There's going to be a session called Women in Rails at RailsConf next Tuesday, which is bound to be focused a lot of this, but there'll undoubtedly be a lot of good ideas outside of that group as well that we shouldn't wait to get going on. Here are a few ideas to get started with:

Share your discovery story
For the women already in Rails, it'd be great to hear what in particular attracted you to the platform. Highlighting areas of the ecosystem that could get even more support. Perhaps there was an especially well-written introduction that just made everything click. Perhaps a screencast or an interview or something else.

This is not the post I wanted to write. The post that I wanted to write, that I in fact have mostly written and would have posted days ago if not for this distraction, was about what a great success Golden Gate Ruby Conference was and how proud we are of putting on a top-notch conference that raised the bar in many ways. But I'm the person who is responsible for the technical program at the conference, and with the astounding level of distress over the presentation Matt Aimonetti gave at my conference, it's clear I need to do something.

First off, I want to apologize. The technical program at GoGaRuCo was my responsibility. I could have done a better job and prevented this from happening. Everyone had the best of intentions and there are good reasons why things happened the way they did, but that doesn't excuse the lapse. As a first-time conference organizer there was a lot that I had to learn as I went, and this is definitely an important lesson. I haven't yet figured out the best way to prevent this from happening again, but I'm determined to find a way to do better next time.

And to be clear, I don't think Matt's talk was appropriate for a professional conference. If an employee of Google or Apple or Microsoft gave that presentation at a company event, he likely would be fired. I know that many people found the talk informative, creative and entertaining, and I'm not arguing against that. But there were people who found the sexual imagery in the talk objectionable or felt alienated by the atmosphere it created, and that's not okay. I think there are ways a talk with that title could have been given that would have worked, but the talk that was delivered didn't.

I just can't get into the argument that women are being kept out of programming because the male programmer is such a testosterone-powered alpha specimen of our species. Compared to most other male groups that I've experienced, the average programmer ranks only just above mathematicians in being meek, tame, and introverted.

When I talk to musicians, doctors, lawyers, or just about any other profession that has a fair mix of men and women, I don't find that these men are less R rated than programmers and that's scaring off women from these fields. Quite the contrary in fact.

When I sit down with any of these groups, I usually find that I'm the one blushing. Yet that atmosphere some how doesn't keep women from joining any of these fields. It's from that empirical observation that I draw the conclusion that this argument is just bullshit.

I've found that the fewer masks I try to wear, the better. This means less division between the personality that's talking to my close personal friends, socializing with my colleagues, and for interacting with my hobby or business worlds.

Blending like this isn't free. You're bound to upset, offend, or annoy people when you're not adding heavy layers of social sugarcoating. I choose to accept that trade because my personal upside from congruence is that I find more energy, more satisfaction, and more creativity when the bullshit is stripped away.

This means that it leaks out that I love listening to Howard Stern, that Pulp Fiction is one of my favorite movies, that I laugh out loud at Louis CK's Bag of Dicks joke, that I whole-fully accept my instinctual attraction to the female body, that I think drugs should be legal, that I really like the word fuck and other gems of profanity, and on and on.

There is a lot more to Cucumber than I showed in an earlier episode. See how to refactor complex scenarios in this episode.

BucketWise is now available! It’s far from “done”, but I’m labelling it “1.0.0” because giving code pre-1.0 version numbers is a coward’s game. (ha!)

At any rate, fork it on GitHub, see what you think, and contribute back if you feel so inclined. The TODO includes a list of unresolved issues and features I’d like to see land someday: knock yourselves out. :)

Note that I’ve tried to document the REST API for BucketWise, too; the first draft is in doc/API.rdoc let me know if any of that is too confusing or not informative enough (I’m sure that will be the case). I’m really looking forward to seeing what people use the API for.

There are often times when you want an update made to one object to be reflected up the object graph as an update of an associated parent object. For instance, if a new comment is created on an article, you may very well want to mark the article as being updated. With the new touch feature of ActiveRecord, this is a whole lot easier. Using our previous example, here’s is how it works:

This is a great way to keep tightly coupled domain models in-sync without resorting to a potential maze of callback logic.

Also, if you have a timestamp field named something other than the standard updated_at or updated_on you can explicitly specify that field as the value to the :touch option and it will get marked instead:

Fixtures are external dependencies which can make tests brittle and difficult to read. In this episode I show a better alternative using factories to generate the needed records.

How to write helper libraries for your Cucumber step definitions and how to upgrade your support libraries from Cucumber 0.2 to 0.3 (released today).

In cucumber, each scenario step in a .feature file matches to a Given, When, Then step definition. The step definitions are normal Ruby code. First class, bonnified, honky-tonk Ruby code. And what’s the one thing we love to do to Ruby code on a rainy Sunday afternoon? Refactor it. Turn messy code into readable “return in 50 years, on the time capsule, and get back to work quickly” code.

In Cucumber we use a special, until-now unknown, magic technique for refactoring step definitions. They are called “Ruby methods”. Oooh, feel the magic. You take some code in a step definition and you refactor it into a method. And you’re done. For example:

Here we are, the week of Golden Gate Ruby Conference 2009. Everything is in good shape, and we're looking forward to having an awesome time. So here is some last-minute information about the conference.

We've got a great program. Really, this is the conference I've always wanted to attend. Check out our schedule and the amazing assemblage of speakers. I want to thank everyone who submitted talk proposals, and also everyone who voted for selecting talks. We couldn't have done it without you.

Our tickets sold out in just four weeks. We'll have a full house of 200 people, and we'll do our best to take care of you so you can get the most out of the conference. We'll be emailing attendees soon with some info about things like parking, the after-hours party and such, so keep an eye on your inbox.

You can improve the readability and remove duplication in RSpec by adding matchers and macros. Learn how in this episode.

“Buckets” is now “BucketWise”. The name was more unique, easier to identify as an application, and just felt better than “Buckets”.

To celebrate the new name, I’ve also made another screencast, this one demonstrating BucketWise’s anti-debt features. It’s a bit more long-winded than the first one: five and a half minutes of me talk-talk-talking:

BucketWise Preview #2 (QuickTime, 5:30, 10MB)