Update 1: a number of people over at Hacker News have pointed out major inefficenies in my solution, and various better ways of solving this. At this point, I think it’s fair to say the tldr; is that while my bad solution was prohibitevly slow in Ruby, Go could run it with ease. If you are like me and don’t always come up with the best solutions, you may want to consider other languages for these kinds of situations too.

Update 2: I had originally assumed I had a bug in my solution that was causing the Go program to have the incorrect output, but a Hacker News commenter pointed out that it was probably the integer type I was using. The version of go I was originally running, 1.0.3, defaults integers to 32 bit, whereas version 1.1 and above defaults to 64 bit. After updating my version of Go, this program generates the correct output, but now takes about 2 minutes and 47 seconds to run. Not as compelling an arument as before, but well within the limits required.

This past weekend, I participated in the qualification round of Google Code Jam 2013. It was year is my third time participating, and the third time that I have used Ruby as my primary language.

Since I have no prior experience in actually being competitive in programming competitions and I use Ruby at my day job (it’s one of the that drew me there), I’d never given my language choice much of a second thought. Sure, I knew Ruby wasn’t going to be zomg fast, but I always assumed that if I chose the right solution and wrote in an efficient manner (memoizing, storing values/lookups that would be used later, limiting search spaces, etc), my ability to write code quickly and concisely mattered more than sheer processing speed.

I was wrong.

Crosspost of something I posted on the Vox Product Blog last week - a d3.js visualization of people commenting on SB Nation during the Super Bowl. I thought it was neat, maybe you will too.

As a music nerd, I’ve always enjoyed end of year ‘best of’ lists. They are amusing, but are almost almost always ranked by what album is ‘better’ than another. Unsurprisingly, there is a lot of futzing about what ‘better’ means and pressure to rank something one way because that’s what the cool kids do.

Yawn. What’s more interesting to me is what people people have ACTUALLY been listening to. Fortunately, Last.FM keeps track of exactly that. It’s a great service, and I highly recommend it for music lovers. (By the way, if you are a user, you should add me me as a friend!)

Although Last.FM will tell you what your most listened to albums in the last year are, it doesn’t exactly answer the question I have - what albums did I listen to the most that came out in the last year?

Last week, I participated in the Stripe CTF 2.0 challenge, which focused on web application vulnerabilities. It was my first time participating in a CTF event, and Stripe made the event fun, and relatively accessible, but still challenging. With a bit of determination and help from irc, I’m happy to say I made it through all eight levels.

I was originally planning on writing up a short explanation of each level and how I solved it, but several extensive walkthroughs have already been posted, so I’m not really inclined to do that.

Instead, I figured I’d highlight a few of the things I learned through the event.

Although I had experimented with Vim in college, I didn’t start using it seriously until about two years ago. I was writing one off Ruby scripts and attempting to learn Rails at the time, and primarily working in Ubuntu. I didn’t use much in the way of plugins since I was just editing a single files or small projects that I wrote all of.

When I started working at Vox Media in January 2011, I switched over to the dark side (OSX), but wanted to keep using Vim. One of my coworkers showed me Janus - a highly customed Vim distribution, “designed to provide minimal working environment using the most popular plug-ins and the most common mappings.” Since these plugins seemed useful for the large codebase I would be working in, I started using it.

Janus did deliver in providing a lot of plugins that I found very useful, and it worked great for me for a long time. I’m extremely appreciative of the efforts it’s authors have put into it, but I started to sense we weren’t a great match. Every day, little things about it would bug me.

As promised, another link to something I wrote for the Vox Product Blog. We recently launched our own liveblog tool (called Syllabus), which uses Amazon S3 to handle scaling to hundereds of thousands of users. The post is mosty about the system architecture, which I think is pretty cool.

So here it is - Introducing Syllabus, Vox Media’s S3 powered liveblog platform.

As a side note, working on this project was a perfect example of how much fun it it is to create and launch something with talented people. It doesn’t get much better than that.

As you may know, I’m currently a developer at Vox Media, and a proud member of their Product Team. This is the term we use to describe all of the designers, developers, community/product managers and ops folk that produce the platform that powers SB Nation, The Verge and the upcoming Polygon.

We’ve recently launched a blog to talk about the work we do. I happen to think it’s pretty cool, and you should check it out here.

I wrote one of the inaugural posts entitled Developing with Production Data, which gives a brief overview of a talk I gave at the DC Ruby Users Group in April. Since the post is pretty short, I’ll just say that you should check it out. If you are too lazy for that, the slides are here.

In the future, I’ll probably be writing more for the Vox Product blog, so expect to see some more links back there in the future.

This past weekend, I competed in Round 1 of Google Code Jam, a competitive programming competition. Although it was my second time participating in GCJ, things didn’t really go much better than last year. It should be noted I used the same tools I created last year to test solutions, which was very helpful.

I’ll talk a little about each round/problem to the best of my recollection, and as always, my (attempted) solutions can be found on GitHub here.

This last week I attended Rails Conf 2012 in Austin, which was a welcome contrast to my SXSW experience. I found lots of talks that where interesting and applicable to problems/questions I have in day to day Rails development. If you are curious about specific content, I highly recommend checking out this wiki of presentation notes created by the New Haven Ruby group.

The other thing is that I bought an iPad recently and used the Paper to take notes for a number of the talks. Although the process was a little slow, I’d like to try it with a stylus and expect to continue to do the same thing in the future.

Here are some quick thoughts/notes about talks I found particularly interesting. I took these using the Paper app for iPad, which I quite enjoyed and would recommend.

Having just returned from my first SXSW Interactive experience, it’s time to finally take a breather and reflect on a few things.

It’ a hard event to fully describe, just because of the sheer size of the conference and many other facets of it. To make things a little easier, I’m going to split this into talking about the panels, people, and parties.

SXSW 2012 by cloudioweb, on Flickr