Kevin Dreams of Ruby

Yesterday, Eric, one of the Experience Engineers here at Launch Academy came up with a little challenge for everyone in the cohort: Given an MD5 hash and a set of hints as to what the decrypted message is constrained by, write a brute-force program that will crack the hash and return said decrypted message.

MD5 hash: b354e9b8c7a5fb1e073670a28f957032

• All lowercase letters
• No spaces
• No underscores
• No numbers
• No characters other than letters a-z
• 6 characters long

(the original, by Eric, can be found here.)

I personally love these types of challenges – fun little puzzles that require understanding of not only programming, but some cryptography as well. There was even a tasty prize for the first person to not only solve it, but also actually have Ruby code to back it up (so no cheating with online decrypters!).

I managed (with some help from Prem of Thoughtbot) to write a six-line program that, after a good 10 minutes or so, does the job. There’s many different ways to implement the decrypter, as others in my cohort have shown, with differing efficiencies. For starters you’ll want to use Ruby’s Digest::MD5.hexdigest method. Give it a try, it’s actually really fun. If you manage to solve it, see if you can get the code down to as few lines as possible (hint: there are Ruby methods for permutations), or, even harder, how to reduce the time it takes to decrypt. I’ll post a Gist of the solution sometime later.

I, unfortunately, did not figure it out before fellow Launcher Ben Calegari did. Kudos to him and him receiving his just reward: a delicious cannoli.

I attended the Boston Festival of Indie Games (or more exactly, the Game Jam part of it) held at MIT last Saturday. It was my very first hackathon and despite feeling the often-hard-to-avoid symptoms of Imposter Syndrome. Why did I suffer from Imposter Syndrome you might ask? Well, I honestly thought this Game Jam was going to be a room filled with super-smart, highly-proficient and experienced programmers. As a beginner, would I be able to join a team? Did I even belong here? This is, afterall, MIT (and indeed there were MIT students participating).

So imagine me, having only a couple months of coding experience and absolutely no experience in game development, walking into a room filled with people who I assumed to be, in this context, better than me.

Read on →

Red, green, refactor. NOT red, green, red, green, red, green, refactor, refactor, refactor, refact…

(Michael has informed me that he actually got that from somebody’s tweet)

When performing test-driven-development, there aren’t many rules to follow, but the hard part is actually following them. One of the main rules you pretty much always want to live by is, work in small increments. Number two, you always want to do the simplest thing that gets you to green. This can be as simple as just hard-coding a return value in a method so that you’re getting a unit test to pass.

This may seem a rather contrived way to go about things, but that’s how TDD works; you work incrementally, and rather than getting overwhelmed by the magnitude of the whole program you’re trying to write, you’re zeroing in on a small part of it, steadily improving it and assuring that you are progressing because you’re passing your tests.

Let’s take a look at a simple case that helps illustrate these concepts. Let’s say you want to write a program that takes in an array of numbers and performs some statistical calculations on it (e.g. largest number, average, standard deviation, etc.). We’ll start by writing a RSpec test for it:

Read on →