weblog.masukomi.org

UPDATE: I’ve created a new subdomain for the FizzBuzz Overthink project ( http://fbo.masukomi.org ), updated the links below to reference it instead and modified the Readme in the project (and the default page of the site) to reflect the new goals of the project

UPDATE 2: There’s a JavaScript example in there now too which, of course, includes unit testing. More details here.

I was talking with someone the other day who mentioned, in passing, how they wished they had some good examples of how to do unit tests for his co-workers. There are, of course, plenty of examples of how to do unit tests but I haven’t seen many online that show them in the context of a complete but simple application. This conversation made me remember my FizzBuzz Overthink (FBO) that I’d written in Java, and it occoured to me that it would make a great teaching application. Translating an existing FBO into a language you’re trying to learn is also a great way to get your head around it.

This flow chart will only make superficial sense unless you’ve read the Triage section of my Best Practices for Web Developers essay, which I happen to have just updated with an expanded Triage section.

Click on the thumbnail for the full-sized verison. If you’d like, the Dia file is also available if you feel like tweaking it.

For the most part web developers spend our time guessing what features people might want and how said features should be integrated. Frequently we guess wrong and that wastes time and sometimes frustrates users. But there are tons of users out there who also happen to be developers and they’re actively implementing new features for their favorite sites with Greasemonkey. UserScripts.org has over 6,000 scripts. That’s 6,000 features with working implementations for popular sites at no cost to those sites! Free I say.

If you build this I will buy it.: Ergonomic Dvorak keyboards are effing expensive. Dvorak keyboards are hard to find in general and software remapping in the OS has a variety of…. issues. I want a USB dongle that remaps keystrokes from a QWERTY keyboard to Dvorak. Even better put a switch on it to turn off the remapping. I will pay up to $25 for such a device.

Currently web frameworks are all about the page. This is starting to change a little thanks to Ajax but mostly just towards the idea of page snippets. But why? “Pages” are a metaphor taken from books, but books are linear and the page serves to restrict the layout. Things like Yahoo Widgets have shown us that there’s no need for layout to be bound to the “page” metaphor and we’ve known for a long time now that webapps are rarely linear, and when they are people don’t like it. Essentially we’re writing glorified “choose your own adventure” games that still say “To open the door on the left go to page 65. To open the door on the right go to page 27. Rails, and it’s clones, even number the “Pages” like that. We need a new metaphor. What if, instead of writing frameworks that are all about serving and managing pages, we started to think of webapps more like pinball machines. There are 5 major parts in every modern pinball machine (other than the ball):

The CharlieCard, as some of you know, is the MBTA’s reusable pass for subway / buss access. The only problem with it, aside from the fact that the system is constantly breaking, is that it’s as big as a credit card so, if you’re like me, it tends to not be in a readily accessible place as you approach the station. My keys are always accessible and I have little plastic frequent shopper type cards from six other companies there. “Wouldn’t it be nice”, I thought, “if i could find the chip in the card and then cut down the card without cutting the chip so that I could put it on my keyring.” Well, I found the chip (in a strong light you can see it’s imprint in the green bar under the guy with the blue hat) and when March had passed and April’s pass was yet to be added to it (in case things went wrong), I proceeded to cut it down to a key-fob size. Alas, it didn’t work.

Using Darcs with Subversion / CVS

Some of you have gotten the distributed version control religion (If you haven’t, you should read my Best Practices essay) but are stuck with Subversion (or CVS) either because that’s what they use at work or because some part of your deployment systems use it. You may also want to combine them simply because of the power of svn externals which lets you pull in some of your code from constantly updated , Subversion Based, 3rd party repositories. Using SVN with a distributed version control system also gets you a cannonical, no doubt about it, central repo, instead of just a repo that everyone agrees to call the central one, plus you can utilize all those nifty notification and stats tools people have written for svn.

I wrote this essay a while ago and have been tweaking it based on the feedback from those I’ve sent it to (thanks guys). There are a few things I’d like to change still but I’m going to go with the “Release early. Release often” mantra on this one. I think it’s more important that it get out there than it being perfect.

Best Practices for Web Developers introduces the idea of Heuristically Driven Development ( HDD ) as it applies to web development, but honestly almost everything in there is applicable to all forms of development. There’s an HTML version and a PDF version and your feedback would be greatly appreciated and help to make the next iteration of the document better.

You really don’t want to become a programmer.

How do I explain to you that programming is an endeavor of passion?

You look at it and see text on a screen and a good paycheck.
I see problems begging for solutions.

You see tasks to be completed.
I see mountains to be scaled, and wells to be dug.

You think, “I could sit at a desk and poke at a computer all day.”
I forget there is a desk, what day it is,
or that my chair’s been broken since I started here.

Raganwald suggests, with good reasons, why you shouldn’t over-think FizzBuzz. Obviously I took a different view of it and yet I still agree with all of his points.

So, I’d like to counter with some reasons why you should over-think FizzBuzz, and why I did, because I don’t think I did a great job of explaining that in my last post. But first, lets assume you’re not being asked to solve it on a whiteboard while the interviewer waits. In that case my 400(ish) line solution is completely inappropriate. In fact, anything but a quicky solution is inappropriate. Lets also assume that in submitting an over-thought solution to FizzBuzz you make it perfectly clear that you know it’s over-thought and what you were hoping to achieve by going to such ridiculous lengths in your creation.