Jeff Atwood once blogged: “I don’t think it matters how you conduct the postmortem, as long as you do it“.  To that end, here’s my post mortem of the app I didn’t finish.  Ideally  other developers will learn from my successes and mistakes.  :)

The App/Idea: A web version of my iphone app ( Touch Playbook ) called Playbook Nodes.  I learned a lot creating TPB and I figured I’d learn a lot porting the code as well.  I emailed the contest organizers early to make sure I wasn’t going to violate the following rule:

“Of course, feel free to work on the concept for your application before the competition starts: pretty hand-drawn pictures on napkins, angry email threads between team members on two-space or four-space indentation, schema designs, finite state machines.  Just no digital assets including graphic design assets, code, etc.”

~Node Knockout Rules

They gave me the green light, so I starting researching the parts of the app I’d need to understand.  Looking back, here were my mistakes:

Mistake #1: Doing too much
Heading into the competition, my goal was to recreate the entire app.  That includes the user interactions (dragging players, passing the ball, shooting, etc), full replay animation logic, & state management.  On top of that, I wanted to add new features like user accounts and the ability to share pays.  Considering that it took me 5 months to build TPB (1 month to spec / 3 months to implement / 1 month of user testing ), this order was WAY too tall.  In hindsight, I should have simply picked another project.  Anything TPB inspired that’d be worthwhile would simply take too long.

Mistake #2: Assuming that things will simply fit together
I assumed that I’d simply figure out how to elegantly draw paths as the user dragged players (and animate the process later) despite the fact that I couldn’t find good examples of animating the drawing of paths and I’d never done it before using Raphael.  I also assumed Mongoose-Auth would be easily to implement and…well..would just work.  Both of these assumptions cost me precious time.

Mistake #3: Oversleeping
I was hoping to get about 5-6 hours of sleep each night.  Instead I got 7-8 each night.  I felt great, but I wish I had the extra hours to code.

Mistake #4: Failing to achieve a “thin line through” in the first 24 hours
This might be the most telling sign of failure in a 48 hour competition.  It’s really important to get a barebones version of your app working before you continue working on the features in your spec.  The 24 span INCLUDES server setup.

It wasn’t all bad though.  Here are some things I did right:

Success #1: Spec’d as much as I could BEFORE the competition
Mockingbird was super handy way to mock views & my trusty notebook saved my thoughts in the weeks leading to the competition.  Also, I was able to pull my notes from the creation of TPB which helped a bunch.

Success #2: Improved my overall JavaScript skills & got comfortable writing node JavaScript before the competition
I’m new to Node.js, but I’m not new to web development.  I have to shamefully admit that I used to think of JavaScript as a sub-language whose only use were silly DOM tricks.  Fortunately, I started following the works of Douglas Crockford and saw the light.  Not too long after that, I start hearing about NodeJS & I started soaking up examples around the first week in August.  I turned my knowledge harvesting into overdrive & gained the confidence I needed to enter the competition .  Here are some of the things that I did:

• Watched 7.5 hours of Douglas Crockford’s presentations
• Also kept a copy of “Javascript: The Good Parts” close by at all times
• Attending a free training by the co-founders of Nodejitsu, (@hij1nx & @indexzero)
• Watching as many NodeTuts as I possible could and coding the examples in the vids.
• Felix’s Node.js Guide
• Tons of links to helpful content & people to follow (twitter, blogs, etc).
• Watching videos by Ryan Dahl, the creator of Node.js

Success #3: I went with Heroku instead of Linode or Joyent
I didn’t want to lose time configuring a server.  The purpose of the competition is the app that I create, not testing my Sys-Admin skills.  Going with Heroku saved me the headache that many of my fellow participants faced.  Some teams never got their server setup, but I was deploying early and easily.

Success #4: Logging my actions
Every hour, on the hour, I wrote a summary of how I spent my time.  If I started writing a bunch of code, I’d shorten my logging to 30 minute intervals.  This was helpful because it drove me to get small victories at least once an hour.

Success #5: In Backbone.js apps, add a global logging function
I started doing this in every Backbone app that I create.  I add 3 simple methods to my controller/router definition.  This gives me a name-spaced way to log & benchmark events from my controllers, models & views.  It also gives me a clean way to disable logging when I deploy to production & an easy way to toggle the logging once the code is deployed to prod.

• debugEnv()
• The router/controller has a variable called ‘debug’ which is set to true/false.
• The first line of the method looks like this:
  return (this.debug && (typeof console !== ‘undefined’)); 
• logEvent(message)
• This method returns if the controller/router’s debug method is off
  if(! this.debugEnv() ){ return; }  
• Otherwise:
  console.log( (new Date()).toTimeString() + “: ” + message); 
• benchEvent(handle, operand_string)
• This method needs to use console.time() & console.timeEnd() so it makes sure that we can debug AND that the ‘time’ method exists (This is a problem on IE):
  if(! this.debugEnv() || typeof console.time === ‘undefined’ ){ return; }
• Otherwise, depending on the ‘operand_string’, …
  case ‘+’ : console.time(handle); break;
  case ‘-’: console.timeEnd(handle); break;

This makes it really easy to track what my app is doing and provides simple benchmarking.  I find it super helpful! 

Success #6: Entering Node Knockout 2011
The biggest success was taking part in the competition.   I learned so much more about ExpressJS, Jade, Stylus, Mongoose, MongoDB, CSS3 Gradients, and more because I challenged myself.  Was I ready for every single challenge I faced? Absolutely not!  However, failing with focused effort is better than never trying at all.

In Conclusion
I look forward to Node Knockout 2012.  I’m probably going to start spec’ing even earlier and I’ll be more realistic about what can be accomplished in 48 hours.  I also intend to complete PlaybookNodes.  While I didn’t get everything done in 48 hours, I put together a LOT of plumbing and I feel that I’m potentially only a few days away from a finished product.  I hope my experiences help you plan your next 48 coding session better than I did.

Oh, and now that I’m done with NKO2011, Part 2 of the Backbone.JS tutorial is on it’s way!

Till next time, Happy Coding!

Now, if you’re on a Mac or Linux system, just add a symlink inside your dropbox folder that points to the other folder you’d like to sync.

On Windows, if you want Dropbox to sync folders outside of your “My Dropbox” folder, you’ll want to use the mklink command to create a directory junction pointing to the other folder you want synced. For example, if you want Dropbox to sync c:\source_code, open a command prompt, navigate to your dropbox directory (cd “My Dropbox”) and type:

(Assuming you’ve already navigated to your “My Dropbox” folder)
mklink /J source_code c:\source_code

Bam. That’s it. Dropbox is now following the link inside the “My Dropbox” directory and it’s syncing c:\source_code because it thinks it’s just another folder in the dropbox. Enjoy!

Deploying iPhone Apps to Real Devices

Happy hacking!

/Users/[yourname]/[your-app]/vendor/gems: gem unpack [gem name]

It isn’t the end of the world if you don’t do it ahead of time, but it does make life slightly easier.

(2) Remember that when you find a bug, you should write a test for the expected behavior BEFORE fixing the bug.  “The Rails Way” has a great quote about testing:

“It’s not that Rails encourages you to do test-driven development, it’s that it makes it difficult for you not to do test-driven development.” ~Brian Eng

I’ve interpreted this quote into the following mantra:

“It’s not that rails makes it easy to test, it that it makes you pay when you don’t”.

Finding a bug after creating your test suite just means that you missed a test.  Take the opportunity to correct that.

Happy hacking.