Development

Testing IE with OS X


Javascript · Development · Ie7

We were getting reports that some features of Endorse.me weren’t working on corporate environments, to which I groaned because I knew exactly what that meant: IE is misbehaving[1] and causing some Javascript to break.

We test the site in IE8, but didn’t expect that anyone[2] would be visiting using IE7. Unfortunately, the rumors about corporate America’s IT departments are true, and a good portion of our users were having a terrible experience.

After googling around for a bit for a way to test in an older version of IE without booting up a 5 year old box, I came across ievms, an excellent tool from xdissent which allows you to install a virtual machine for IE6, 7, and 8, in a (nearly) painfree process. A single curl command is not bad.

I was concerned about being able to boot a VM on my 13-inch MacBook Air with all my other applications, but so far, I haven’t had any problems.

So now I can finally test in IE7! Except that also means I just found a bunch of IE7 related bugs that I now have to spend the rest of the night perusing Stack Overflow to find answers for. Ahh, the joy of web development.

[1] Some people will take exception to the use of this term. For those people, I suggest you read “behaving differently”.

[2] By this of course I mean, “a significant enough portion of the population to justify the development time.”

On the Bleeding Edge of Node.js


Javascript · Mongoose · Development · Nodejs · Bcrypt

Developing with new tools is a lot of fun. They’re usually new because they allow you to do something that you couldn’t before, or in an environment that you couldn’t before. 

Node.js is like that. And while a lot of people complain that it is overhyped (and it is, to some extent), it’s just fun to work with. JavaScript can be a good language, and playing with it on the server is something new, and pretty cool. The fact that I can use the exact same validation expression on both sides increases my happiness as a developer.

However, Node is very young, and very immature. There are tons of modules out there, and more coming every day, but the fact is that you will encounter situations that no one else has encountered before (or at least documented). Coming from Rails and PHP, that’s quite the change of pace.

For starters, how do you store passwords securely in a database? Well, you use bcrypt of course! And there is, in fact, a bcrypt module for Node that is excellent…if you’re not using Windows. One of our developers was using a Windows box, and despite trying to figure out how to get it to build for about a day and half, it just wasn’t meant to be. At some point, it’s faster to boot up a Linux VM than to embody the definition of insanity.

Last I checked, the issue was still being actively worked, with an update from the bcrypt author as of about two weeks ago. The community is there, the ecosystem is just young.

But it’s not just Windows. We work with MongoDB for storage, and on Node, you can’t do better than Mongoose. But as I said, it’s young. So the findAndModify behavior wasn’t available in Mongoose. Taking a closer look at the source on GitHub, I found that the edge version of Mongoose did support findAndModify (in the form of findOneAndUpdate for all you Mongoose users). So I did what any overconfident dev might do: I switched to edge in order to take advantage of the new feature.

Unfortunately, there is a reason that it is not a complete release. While findOneAndUpdate works, there was at least one very nasty bug that I encountered in the Mongoose source. That, and the changes to functionality make certain design patterns much more attractive (namely, passing a Mongoose document as the update argument) that aren’t currently supported in Mongoose.[1]

 And these are just the issues I’ve found. And I’ve barely scratched the surface of what Node can do.

But that’s a good thing. That’s what makes it fun. Everything has pro’s and con’s, and to me, the pro’s of what Node can do, and what I see for the future of Node are well worth some time spent here and there digging into the source code of a newer module.

After all, some people find debugging fun.

[1] I’m still working adding tests to my pull requests to get both of these complaints addressed upstream.

Finalizing UX


Development · Ux · Roadmap · Mvp

When I came on board with my latest project three weeks ago, we spent some time defining the sort of minimal functionality that we would need to get the product out the door. We were building a sort of minimum viable product (although not as minimal as Eric Ries might like). The (non-technical) founder had done some extensive user testing with a contracted-out version of the site, and we decided we needed to really strip down the features to the bare minimum.

After defining the requirements, I set out to build a roadmap of feature building. Having never developed with nodeJS before (which we were moving to) and developing on nights and weekends with other developers who were also moonlighting, this was more guesstimating than anything. But when it came down to it, I had put together what I thought was a reasonable schedule to get all of the functionality in there.

I built in a buffer of two weeks (or a 50% increase in the schedule) for something labeled, vaguely, “Finalizing UX”. I knew that after we had built all the basic functionality, we were going to have to make some changes to how everything works based on walking through it as though we were first time users. There are some things you simply can’t vocalize as important until you see them missing from the functionality. So I put in this large chunk of time solely to finalizing the end-user experience, so we could put out a product we were proud of, while still sticking to an aggressive timetable.

Well, week 4 starts tomorrow, and we look like we’re in a position to deliver the basic functionality. But I just got off a 2 hour phone call where we decided that we need to make some changes in order to really clean up the user experience. We needed to tighten up the viral loop, which meant changing some of the approval procedures. We needed to change how posts got displayed (more client-side, less server-side), and we needed to change how we communicated with people (email, facebook, both?).

So, those two weeks will be time well-spent. Sometimes it’s just as important to know what you don’t know (or can’t know) ahead of time, and build it into the schedule anyway. It worked for me (this time).