I had a really nice birthday today.

I was alone in my office and away from son who is too sick to go to school, so I was a bit sad about that. But then someone on Twitter remembered it was my birthday, and as other people noticed they wished me a happy birthday. I was on a conference call with a client and they broke into a happy birthday song at the end of the call.

I put a good day in and got some stuff done, but I’m leaving a bit early to spend the rest of today with my family.

I briefly mentioned it in our last State of the Shake but this has been a very challenging couple of months for us as we split our time between contracting and working on MLKSHK. When I left my job I signed up for challenging so it’s to be expected, but this was a nice way to end the month.

Thanks, friends.

I had an idea a couple weeks ago and so I tweeted about it:

Screen Shot 2011 09 25 at 6 59 10 PM

Nobody took up the challenge. So after finding a couple hours of my own, and wanting to get better with Backbone.js, I made it. (Wrote mostly with CoffeeScript because OMG CoffeeScript)

laterspam.org (note, this is on the most anemic, cheap, virtual machine Amazon offers, it’s not quite ready for heavy use so be gentle.)

It looks something like this.

In my experience there isn’t much of a spam problem on Twitter. Yes, it’s annoying to mention something about your iPad and have a spam bot or two tell you how you can get a free one just by “clicking this URL,” but I feel like that happens once or twice a month at most.

I normally just mark the thing as spam and move on. But the last time it happened I clicked over to see the account’s timeline and saw they had been at it for quite some time. Even tweeting innocuous tweets in between the mention spam which I guessed was to throw off Twitter’s own spam algorithms.

I didn’t make this because I am fed up with Twitter’s spam. I made it because after spending a few weeks now dealing with MLKSHK’s own spam problem I was curious about Twitter’s rate of discovery. For the most part I’m curious how long after I report spam that an account is deactivated. As I got deeper into my spam problem I found myself enjoying figuring out ways to deal with it, how quickly my algorithms caught and removed it, and mostly just because I‘m a sucker for seeing my code automatically take care of admin duties.

So I built laterspam.org because I thought people might get a little satisfaction out of marking something as spam and knowing Twitter did something about it.

Icon For the last couple of weeks I’ve spent hours solving, playing, and re-playing a game called The Last Rocket by Shaun Inman.

The main game itself could probably be finished in one sitting if you have a bit of time. The controls are very simple to understand, but require a play through to get enough practice to have the timing right. Once you get the two ways to control the main character figured out the game gets even more fun.

Quickly: the style of the game is commonly referred to as retro or 8-bit. The music is appropriately chip-tuned. The graphics are some of the best pixel animations I’ve ever seen. There is so much animation in these little characters that part of the entertainment is just watching them cycle through.

Of all that TLR has going for it, it’s the genius in the level design and timing of the elements inside of them where I was won over. Once you’ve played a level many times, and return to it trying to get a different achievement, the level feels completely brand new. This sort of planning is amazing when you see it.

I’m kind of in awe that this game exists. There is so much stuff in it worth going on about but I didn’t want to give too much away. I wrote this because I wanted to make sure anyone who likes this style of gaming doesn’t miss out on this game. It’s easily one of my favorite iPhone games I own. More here.

This past _why day an email made the rounds that _why had sent two years prior to someone asking how they could become a better programmer.

The crux of the email was: if you follow the rules you are not going to maximize your risk and your creativity will suffer. Programming, for him, was about experimentation and discovery versus adhering to rules to produce objectively good code. He didn’t write tests. He didn’t follow any particular style or convention. He did some pretty amazing things. (And then he disappeared.)

The entity/story/folk hero that was _why is one of my favorite subjects to talk about when I’m drunk and talking about Ruby or Rails. If you haven’t read about _why you really should start with his Wikipedia page and definitely his book: Why’s (Poignant) Guide to Ruby. (I’m a fan of _why, can you tell?)

BUT…here at Simpleform one of our (and I will use this word even though my Catholic mother would give me a dirty look for using it that way) religions is testing. The other is shipping. We love shipping. Shipping is what makes your day worth it and if I leave my office having not shipped anything I mope.

The shipping is the fun part, the work is the testing. Testing builds trust amongst our team and with our clients. Without testing we’re potentially handing our clients a time-bomb, and worse, we’re charging for it. I hate this feeling.

So we test because we want to ship. And we ship because we want to make our clients happy. And if we can’t ship then nobody is happy. So we adhere to a set of standards and styles guides on how to test and how to organize our code.

There’s this line religious people use when they encounter atheists: “Without religion, where do you get your morals from?” Which is hilarious because I responded the other day to someone, “Without tests, where do you get your confidence in the code from?” and then realized what I was sounding like and laughed and laughed—but really I don’t get where the confidence comes from.

I used to think I was good enough to write code without tests. And to be honest, I never experienced a problem so major that data was lost or leaked. At FM every engineer was responsible for their own code and that plan mostly worked. Nothing catastrophic ever happened. But in the back of my mind there was always a worry that it might. It would only be a matter of time before something bad happened and I always felt a little nervous when I’d hear something wasn’t working correctly.

Even worse, changing a critical part of the application was always an arduous task of user testing and re-testing. It wasted time. It created a lot of worry and even when it was done I’d never feel great about it. Automated testing means you can make those changes and feel great when you ship.

And we love to ship.

When you’re done reading _why’s email, you’ll notice the top comment that was voted up is:

“As someone who maintains _why's code these days, please, write some tests.”

Back during SXSW Caterina posted about FOMO. The Fear Of Missing Out. I'm a big consumer of social media but sometimes I realize I’m consuming because of FOMO rather than having time or an interest in what people are sharing at that moment.

When I first read her piece we were deep into MLKSHK and trying to get it out the door. It stuck with me that I was very likely helping to create FOMO for our users and I wanted to be sure we gave them some control over that.

One feature of MLKSHK is the bookmark. It looks like this:

A bookmark gets automatically generated when you first hit MLKSHK and will (try) to stay in that location even if adjacent files are deleted.

The part that says “You started reading here 5 minutes ago” is how it launched about two months ago. As you read through your paginated stream you would run into your previous location and know that you had caught up. The problem with this is that it sometimes felt like a bottomless pit. When am I going to hit the end?

We just added the second part: “Jump to previous”. This allows you to jump back in time to your last bookmark and begin reading forward. You’ll be able to get an idea how far back you are by the post times on files.

We have a lot more ideas on how to combat FOMO. I hope to be showing you some more of them in the coming weeks as we roll them out.

I pulled my head out of MLKSHK the last two months and had a bit of a revelation about the future of web apps—at least, any web app I work on in my future. I present to you my new starting markup:

<html> <body> </body> </html>

Well, throw a <head> tag in there pointing to some JavaScript (generated by CoffeeScript of course) and perhaps a DIV with an id of “app” and that’s about it. I just don‘t see a need to manage “page” markup when so much of my markup is now in jQuery templates/snippets I can swap out very easily.

I resisted hash-bang paths and client-side apps for so long until I started working on a project where it made perfect sense. Since then I’ve just gotten more comfortable with the idea because:

  1. It’s easier for me to think about the server-side app as an API with your browser-view one type of client. Side-effect: your mobile app just got easier to make.
  2. This divides testing into server side and client side. Working on the UI doesn’t mean you have to flip over to the server-side tests to ensure it’s working.
  3. I think I love CoffeeScript.
  4. Marshalling data for a specific view is tedious.

I feel like separating these clients from the back-end means less time tinkering with data as it moves from your db out to your views. There is so much traversing code when you build a site and I now think if you can cut your trips into smaller loops you‘ll spend less time wrestling with data, markup, and CSS (boring) and more time writing useful functionality (fun!).