Matthew Bass

indieconf, Raleigh’s first conference for freelancers, took place Saturday, November 13th at the McKimmon Center near NCSU. It was, in a word, exceptional. And they had brownies.

I was only able to attend the afternoon sessions, but the content was fantastic. It was even better getting a chance to interact with fellow attendees. Being a Ruby developer, it’s easy to get tied down with a single local network. Attending indieconf gave me the opportunity to interact with an entirely different network of people. The smaller nature of the conference made it feel like I actually had a chance to meet everyone. It was a great experience!

My session was Homesteading for Freelancers. You can read the brief at the link so I won’t repeat it. For those who attended, please download the slides and also consider rating the talk. Any feedback you can provide will help me improve. I appreciate it!

Kudos to Michael Kimsal for organizing the conference. He obviously put a lot of thought, care, and elbow grease into making indieconf a success. Little touches like the smiley/frowney whiteboard for providing feedback were really nice. This is definitely something I want to attend next year. My only regret this year is that I wasn’t able to be there for the full day.

A recent project required the latest YouTube videos from a specific user to be listed inside a Radiant page. There wasn’t an existing extension that did this so I built my own. youtube_tags is based on the excellent twitter_tags extension. It enables inclusion of YouTube videos within Radiant pages using a series of Radius tags. It leverages the youtube-g gem to pull data directly from the GData API.

For example, this is how you would display linked titles for the top 5 videos from my YouTube account (“pelargir”) using the Radius tags provided by the extension:

<ul>
  <r:youtube user="pelargir">
    <r:videos count="5">
      <li><a href="<r:video:url />"><r:video:title /></a></li>
    </r:videos>
  </r:youtube>
</ul>

To install in your own project, visit the youtube_tags profile in the Radiant extension registry.

I built the original Spreedly extension for Radiant a couple of years ago. It’s a nice little package that makes it really easy to integrate Spreedly’s subscription payment system with your Radiant site. You can choose which pages to require a subscription to view, manage subscribers from the admin backend, and so on. It’s long overdue, but I finally got around to upgrading the extension to work flawlessly with Radiant 0.9.1. Check it out and have fun.

I’ll be presenting on A/B testing at tonight’s raleigh.rb meetup. As developers, we use tools like RSpec and Cucumber to verify that our application is functional, but how can we verify that the layout of our home page is user-friendly? How can we determine the ideal size for our signup button? How can we maximize throughput to our signup form? A/B testing is an easy and compelling way to increase the effectiveness of our web applications. Join us tonight to learn how to leverage A/B testing in Ruby using several popular tools.

I just returned from BizConf (a fantastic experience which I’ll be summarizing in a future post) and I have to report one very sad thing: out of four airports I passed through, RDU is still the only one that doesn’t offer free wi-fi. Nashville, Tampa, and Jacksonville all have it. RDU charges. This just doesn’t seem right, especially given that out of the aforementioned cities, Raleigh is known as a high tech mecca. This is RTP for cryin’ out loud. Please fix?

“Affliction comes to us, not to make us sad but sober; not to make us sorry but wise.” — H.G. Wells

Git is a wonderful SCM with some very powerful features. But as a programmer, it’s very easy to aquire a rudimentary working knowledge of Git and never learn anything more. For example, how would we fix our repository if we committed the wrong piece of code? What if our commit had an error in it? How do we fix things without reverting or introducing a second commit?

It turns out this is very easy to do. The latest versions of Git have an amend command. Amend lets us alter the last commit we made. All that’s necessary is for us to arrange our working directory the way we want the last commit to look and then execute:

git commit --amend

This will update the most recent commit based on the state of our working directory. For example, say we changed our README file in the last commit and accidentally introduced a typo. To fix the last commit, we would edit the README again, git add the change, and instead of running git commit which would create a second commit, we run git commit --amend which patches the last commit. This can be repeated as many times as necessary.

Note that rewriting history like this can have serious implications if you’ve already published the most recent commit. But if you’re the only developer using the repository, or if you haven’t published yet, this can be a great way to fix minor mistakes without introducing an entirely new commit.

You can read more about amend in the documentation.

“Hammond is insisting SG-1 needs a socio-political nerd to offset our overwhelming coolness.” — Jack O’Neill, Stargate SG-1

“I love this place at night. The stars… there’s no right or wrong in them. They’re just there.” — Sgt. Elias, Platoon

One of the Rails apps I’ve been working on formats times as HH:MM in the view. No seconds are displayed. This is a pretty common way to format things. When doing timestamp comparisons in SQL, however, the seconds are taken into account. This is bad since it can cause discrepancies in the view.

For example, say I have a table of records with created_at timestamps. My view displays all records with timestamps equal to or before the current time. Let’s assume the current time is 15:00:00 precisely and I happen to have a record with a timestamp of 15:00:00 in the database. The SQL comparison would work fine in this case.

SELECT * FROM records WHERE created_at <= "2010-06-25 15:00:00"
=> 1 row in set

What if the timestamp in the database is 15:00:03 though? Let’s run the query again.

SELECT * FROM records WHERE created_at <= "2010-06-25 15:00:00"
=> Empty set

Since 15:00:03 is greater than the current time of 15:00:00, the record doesn’t get returned. This would be fine if we were displaying seconds in the view, but we’re not. From the user’s perspective, the timestamp on the record is still 15:00 and should appear in the view since it’s equal to the current time. But it doesn’t.

One way to fix this would be to handle the time comparisons in Ruby. This is certainly a legitimate option. For this particular project, though, performance was a big issue. (And we all know that Rails can’t scale.) I needed a way to continue letting the database handle the comparisons while disregarding seconds.

The solution I ended up with isn’t ideal (it relies on a couple of functions built into MySQL) but it works fine and runs fast:

SELECT * FROM records WHERE (created_at - INTERVAL SECOND(created_at) SECOND) <= "2010-06-25 15:00:00"
=> 1 row in set

The number of seconds is extracted from the created_at timestamp and then subtracted from the timestamp. So if the timestamp was 15:00:03, MySQL subtracts 3 seconds to end up with 15:00:00.

This solved the comparison problem for me and made my client very happy. Double win.