The Tech Blog of Ken

make your own Simpsons avatar

Make your own Simpsons avatar at the Simpsons Movie web site. Not quite as fun as the one on the Wii, but still pretty cool.

awesome: woman tries to buy all the iPhones and gets owned

this is awesome. "No doubt you've seen people all over the country who camped out for hours to get the hot new iPhone. So how did one local guy get the gadget AND eight crisp $100 bills to boot? FOX 4's Steve Noviello watched the money unfold." (via digg)

lazyweb: any good books on testing?

just a lazyweb: I'm looking for some book recommendations on software testing. Books that I can use for training a green QA guy, not books for developers. I'm helping someone get up to speed with general software testing principles. Any suggestions?

Antipattern: Something Stupid and Rapid Development

Every experienced developer knows this scenario - you're coding all day, churning out all kinds of code, feeling really productive, and then WHAM!

You run into a problem that grinds all that productivity to a halt.  Sometimes for the next day or two, or worse. 

I call this Something Stupid, as in "I've been stuck for the last three days on Something Stupid".

by Dizzy Girl

Something Stupid is characterized by some innocuous coding error that creates a severe problem - could be a missing semi-colon, a stray tab character, or a missing XML tag. Something Stupid is usually accompanied by bizarre and misleading error messages and strange behavior. Unfortunately, you don't usually realize it's Something Stupid until you waste a few days diagnosing the problem.

Usually when I'm stuck in the midst of Something Stupid, it seems like some kind of hard problem. Sometimes, I have the hubris to think that there's a subtle bug in some library that I'm using. I remember once in college I was totally convinced that gcc had a bug when it was something in my own code. In Java, 9 out of 10 times it has something to do with something wrong with the classpath.  (Always remember this, java developers.) If the code is dealing with J2EE, it might be 95 out of 100.

Be careful to recognize the signs of Something Stupid and deal with it as such. Use the principle of Occam's Razor to look for low-level problems instead of complex ones. In the worst case, restore your code to the last known working state and redo your changes.

Wasting a lot of time dealing Something Stupid with is often a sign of something wrong with your development process. Maybe you need to use better source control practices, or to create some build/deployment scripts, or should take advantage of unit testing more effectively. Avoid things that generally cause strange problems, like using spaces in file and directory names.

The new breed of frameworks are not immune to this phenomenon. Ruby on Rails has been touted as a framework that offers at least 10X the productivity of other web frameworks. It's been sold as being free from the configuration hassles associated with frameworks like J2EE. It is indeed very fast to develop in Rails, but don't be fooled into complacency - Ruby/Rails is just as prone to Something Stupid. Perhaps even more so. Because of the dynamic nature of ruby and the heavy use of conventions in Rails, Something Stupid can be even harder to hunt down than in other environments.

Cool stuff found at The Rails Edge

I love nifty tools. One of my favorite things about attending a conference is finding out about the latest cool tools that I haven't discovered on my own. Here are a few to look into.

Day 1:
workingwithrails.com - a directory of rails developers
Amazon EC2 - Amazon's grid computing service, start Linux clusters on demand
HomeMarks - very slick Ajax bookmark manager, written by one of the conference attendees using Rails
happycodr.com - a showcase site for Rails apps
rspec - Behavior Driven Development in Ruby, sort of a declarative unit testing framework
mule - another goodie from codehaus, an open source Java Enterprise Service Bus implementation
revolutionhealth - perhaps one of the largest Rails apps currently in production, from AOL's Steve Case

Day 2:
slicehost - Xen VPS hosting, only 256MB of RAM for only $20/month
witch for OS X - window switching for keyboard lovers
flexmock and flexstub - from Rails committer Jim Weirich, mock objects for Ruby
Selenium IDE - a Firefox plugin for working with the Selenium web testing framework
watir - a web testing framework in Ruby
zentest - not quite sure what this does, but one conference attendee was very adamant about this testing tool

Day 3:
visor - a drop-down terminal for OS X, a la Quake
Streamlined - a rich Rails view generator, sort of like scaffolding on steroids
deprec - a set of canned scripts for setting up a standard Ubuntu server with Rails

Technorati Tags: rails, ruby, testing, tools

At RailsEdge

I'm pretty glad to be attending The Rails Edge conference in Reston this week. It looks like it's going to be pretty interesting. The interesting thing about this conference is that there is only one track - meaning all attendees attend all the same sessions. There are a lot more people here than I expected, and lots of glowing Apple logos around, too :)

So far I've gone through a brain-melting session on metaprogramming, which isn't the best thing to try to grok first thing in the morning. Looks like a packed day.

Technorati Tags: rails

Moving from Ant to Maven

I've made the switch from Ant to Maven at work. Ant is an extremely flexible and powerful tool, but I find that most of the time it's TOO flexible when you are working in an environment where you are doing complex builds.

Thinking back over half a decade of Ant scripts, I realize that I always spend a lot of time when I join a new project trying to understand a whole set of different Ant scripts and then getting all of them to look and work in a consistent way across all the components I'm building. Maven uses a standardized build process with hooks at each step in the process for you to customize or add your own behavior. Think about all those standard things you do for a build. Compile some source code, run some unit tests, create a test report, then create a package (jar, ear, whatever). A simple Maven build gives you all that stuff right out of the box, even without having to write any scripts.

The Maven home page uses some intimidating language - what's all this about a "Project Object Model"? That's enough to scare off any prospective user. A POM is simply an XML file where you put the basic information about your builds - jar dependencies, file names, etc - all the same stuff you would have in an Ant build script. It's all declarative, so you don't have to worry about the order of things (sounds like Ant in the early days). Maven uses standard conventions for directory structures to keep things simple to configure (no more arguing with your coworkers about whether to put your source code in 'src' or 'source' or 'java'), and to keep things the same between different build scripts. Of course, you can override these configurations, but it's better to go with the standard just for consistency.

I think some people are in a pretty good comfort zone with Ant and are afraid of learning a new tool for builds. But overall, I think it's faster and easier to start from scratch with Maven. If you're the type of person who likes the use of "convention over configuration" in Rails, then Maven is for you.

And BTW, if you're working with Rails, rake and Capistrano are no-brainers.

Technorati Tags: ant, maven

My Cubicle - hilarious James Blunt parody

An anthem for office workers everywhere.

Which OS Are You?

Which OS are You?

I think last time I took this quiz I was OS/2 Warp.

get <oXygen/> and breathe a sigh of relief!

I've been doing some frustrating maintenance work on some XML/XSLT code. Working with XSLT is awkward enough as it is, but trying to debug XSLT problems without an interactive debugger is just maddening - it's like randomly poking in a black box.

A coworker was complaining about XML Spy, so I thought I'd take a look at the <oXygen/> XML editor. The interactive XSLT debugger is great! You can step through the XSL file, set breakpoints, look at the stack, and even use different XSL processors (choose from Xalan and a few versions of Saxon). I think I've regained my sanity now.

It's a little sluggish on my G4 PB15, but still very usable. The fact that it's java-based and therefore cross-platform is a big plus. My coworker is totally sold on it too - he loves the Outline view, real-time validation, and built-in spell-checker. Cheap, too at less than 50 bucks for a personal license.