This post discusses easy ways to integrate Google Analytics Event Tracking in your website. Event Tracking is a tool that broadens your ability to track user interaction with your website. Prior to event tracking, using Google Analytics gave you rich information about your page views. With Event Tracking you now have a wealth of information about usage on your non-page reloading events such as AJAX calls, hover events, mouseovers — anything you would like to define and track. (Just make sure you have an account first).

It’s dead simple and, after setup, takes a one-line call to a JavaScript method supplied by Google:

pageTracker._trackEvent(category, action, opt_label, opt_value);

You just have to get the right arguments to that method, so you know what you’re tracking. In the Google tutorial the example is predicated around sending the arguments to the _trackEvent method inline on an onclick event. Instead of doing that, which will create redundant script tags in our views, let’s label our markup in such a way that we can grab a collection of trackable elements via JavaScript and submit them automatically, on a click (or other) event.

(keep reading…)

Often times when we use Cucumber and RSpec (and by ‘we’ I refer to Rails developers, sorry for the narrow focus here), we use them from within a Rails environment.

Here are some instructions on how to set up Cucumber and RSpec for a multi-file Ruby project in a non-Rails environment. Note: if you’re here because you want to make your own gem, stop reading and check out jeweler instead. Jeweler will take care of it all for you with one command:

jeweler name_of_gem --cucumber --rspec

If you are not making a gem and just want to bootstrap your own project, here are instructions — with explanations of what is what. Some may be obvious, but I find that when we are used to using generators it can be easy to overlook what they generate and why. It’s the old “the gui made me dumb” syndrome. Therefore, I choose to both err on the side of verbosity in this post and include a link to a bash script that does it for you, at the bottom.

(keep reading…)

The process was pretty straightforward, though I went through it twice. I thought a quick write up might be helpful for someone else since there were a couple points that gave me pause.

I bought the Snow Leopard CD from Apple for $29. I decided to reformat my drive entirely rather than simply upgrade — my mac is coming on three years old, why keep around all that cruft that’s gathered over the years.

A few posts I read said you needed restart the computer while holding down “c” with the CD installed in order to reformat: I did not need to do this the first time (when I was still on Leopard). I did need to do this the second time, when I had already upgraded to Snow Leopard and wanted to repeat the process.
(keep reading…)

Is where new features go when you forget to scope and prioritize them, relying instead on the deluded fantasy that the new feature you are talking about is just “this small thing” that we’ll do “now”.

It is easy to fall into this delusion because the meeting discussing the new feature was very genial.

You can tell a feature has been stashed in that forsaken crawl space when:

1. It has no story cards or to-dos attached to it — it’s just something you’re “taking care of”.
2. Alternately, it has one card — with few or no details. The title of this one card could translate without too much trouble into “Write Big New Feature”. If you were questioned about that card you would grudgingly admit that it could be an umbrella for ten or twenty other cards, including things like: figure out what this feature actually does, CRUD all the resources (once it becomes clear what the resources are), and design UI.
3. Other cards or to-dos are left open and unfinished while you “take care of this quick thing”. Leaving them open supports the delusion that you’re only gone for a second — to the corner store, as it were, and not fleeing to Argentina to start a new life.

Other things you might also find in that crawl space when you start poking around it are:

1. The fictional project deadline someone in your company insisted on having set in stone (that is conspicuously about half the time it will take to complete the project).
2. The unfinished tails of “completed” features, e.g., “Yeah, the widget is done! I mean, it doesn’t work in Safari yet and the we’re gonna change the background image from a gremlin to a frog, but essentially, it’s done.“
3. The chocolate bar that had no calories because you ate it standing up.

Ok, so let’s say you have some code from some guys you worked with once, some really really smart guys, and the code is… well, no, the code is awesome. It extends Rails in such a way that you can do all sorts of hitherto unheard-of magical transformations that make your life so much easier, and your code so much easier to read. And to write. And to understand.

OK, now, when you say it extends Rails, you don’t actually mean like a patch or anything. And, actually, you don’t even mean like a plugin or a gem. But it extends Rails in a really really awesome way.

OK, so what if the code is untested, really…dense, difficult to read, impossible to understand (even if you really really wish you understood it), and reliant on many other files? And so what if the other files the code depends on aren’t in a plugin or a gem. Well, technically, some of them are. But some of them aren’t! Which is fun! Because then it’s not all conventional-like. Just super magical. I mean, who cares?

Because this is awesome. It gets even awesomer, because as you’re busy using these magical transformations — you don’t even have to learn how to do things the regular way. You can just awesome it up and go home.

Which is fucking great. Until you decide to upgrade your application into the future, where everyone else has been living for a while. You know, Rails 10.11 — or something really awesome like that.

And then, wait a minute, all the code breaks.

The app doesn’t start. The code is no longer compatible. And worse, it’s no longer compatible in a really really obscure way. That you really wish you understood. But you don’t.

How awesome is that?

This is a quick writeup about getting started with git branching via github.com. It covers creating a github repository then branching and pushing changes to it from multiple machines (work computer and a laptop).

While I have had a github account for a while, I hadn’t explored branching until recently when I wanted the ability to branch our Rails app. Because the company where I work is redesigning and adding features to our application, we need the ability to maintain a master branch for the next few months that can be deployed to production on a moments notice but at the same time be able to do new development safely in a separate location (with its own deploy environment). This was enough to merit switching the app from subversion to git and figuring out how to do the basic branching that I would need to do.

(keep reading…)

I’ve used Cucumber a few times before. For one, I coded the Mastermind puzzle in the RSpec book, adding a few extra features for my own game-playing edification. This was done initially in the service of an assignment and became a learning exercise.

Secondly, in my first venture into pair programming, we used Cucumber to drive out some features of a Rails project I am working on. I had already set up a few scenarios, but they were basically languishing until this pairing session. It was a pretty smooth session: not only were the features easy (essentially basic CRUD and view logic), but my partner was an expert at Cucumber, quickly pointing out a bunch of time-saving features like tags and inline tables to pass data. Learning from doing, with someone else, is so much more thorough than learning from a book. Also, since I’m a one-key aliasing fetishist, we set up aliases to run the features: u for all the features; and f for those tagged @focus. I love that. The session made Cucumber feel intuitive and easy to use.

But, still. It’s a new framework and new to me and I’m still in the slog-through phase — “getting” some of it and furrowing my brow at other parts. As well as having a bunch of opinions and an earful of opinions from other users on both sides of the fence. So I’ve decided to use it this week to drive out a rewrite of the authentication process on an existing site. I am also using it for as-yet unwritten features on a new app. So as I start the process, I thought I’d write down some of my existing impressions, and then track how they change (if they do) during the next week or so.

(keep reading…)

I had a great time pair programming last weekend. It was the first time I had done this in a formal, our-computers-are-connected-and-we’re-typing-at-the-same-time kind of way. I’ve programmed with people at the same computer, collaborated with people on different computers in a casual throw-ideas-back-and-forth kind of way, and done the passing-the-laptop-around thing, as well. But, a lot of my development time has been alone. For instance, I had a job for six years where I not only worked alone, but I telecommuted. During this time I lived in Brooklyn, Austin, Denver and Chicago (though not all at the same time). This was great and terrible at once: I had wonderful freedoms and benefits (cross-country travel and NY salary with TX income tax rates, to name a few), but I missed having other developers to learn from and play with.

(keep reading…)

This is a brief entry on how to populate the MIT / SIMILE timeline with dynamic data culled from a Rails application via a controller action that returns JSON. There is a plenty of existing solid information on the timeline itself, as well as a tutorial on integrating it with Rails and one focused on a simple html implementation. All these sources are clearly written and give basic usage tips. I recommend them and will not duplicate them here.

However, none of the sources demonstrated how to get dynamic data into the timeline via URL (they focused instead on creating the JSON / XML inline in the view via iterating through collections, or having it pre-existing as an external text file), I’m adding that information here in the hopes that someone else building in Rails finds it helpful.

(keep reading…)

I love daily standups, but what happens when you’re standing (working) alone? Or it’s not in the organizational culture? Even if you’re lucky enough to have a standup meeting at work, you still have to find the thread of continuity from your work yesterday to your plans today and be able to communicate it in just a minute or so.

Personally, I find it hard to get a focused start on a workday if I don’t know where I am on my road map of things to do and have a list of tangible discrete tasks. It’s easier to feel overwhelmed or just kind of vague about what needs to be done. Also, when diversions occur, as they always do — an unexpected bug or meeting — it’s easy to lose track of where the time went. People can get overwhelmed, let things pile up, veer down a different path without fully acknowledging the trade offs, or buy Getting Things Done and leave it unread on the shelf for a year. :)

(keep reading…)