Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS


Jared Richardson Most Popular
Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers



Blog Archive
2005-December
2005-November
2005-October
2005-September
2005-August
2005-July
2005-June

Mon, 26 Dec 2005

Ruby and the Rabid Enthusiasts

Just a thought on the blogosphere storm that came after Bruce Eckel's blog posting entitled The departure of the hyper-enthusiasts.

Hyper-enthusiasts might be another word for "early adopters". The early adopters are the people that jump on bandwagons early. They were all over Java in the early days. The first to PHP, Ruby and OSX, and other technologies. They were the first to own HD television sets. They like to tinker with new things.

Early adopters tend to be very vocal in their support of a new technology. If they tinker with it and like what they find, you'll hear about it. There are early adopters behind most of the up-and-coming languages and tools. That's why the technologies are up-and-coming. :) They haven't arrived but they are moving.

Perhaps some early enthusiasts were a bit too enthusiastic. Doe we throw out the baby with the bad bathwater? I'm thinking no.

Will Ruby replace Java? No. Will they co-exist? Yes. I've heard people say that Java will own the enterprise deployments and Ruby will own the smaller apps. Could be... I don't know but it's a possibility.

This doesn't have to be "us" versus "them". Learn both. Learn PHP, Python, C#, and whatever else you come across. Put the tools in your toolbox and use them when they fit.

Jared

posted at: 12:46 | path: | permanent link to this entry

Wed, 21 Dec 2005

The Copy/Paste Detector

Last week on the Agile Testing mailing list the topic of software metrics came up... several were mentioned and I wanted to follow up on one of them here. There's a nifty tool available to you called CPD. It's simply a Copy/Paste detector but it works on Java, C, C++ and PHP code.

The idea is pretty simple. When someone sees a block of code they want to use, sometimes they create a utility class or a common routine from the code and then use that common code. It's a nice, clean, maintainable solution.

However, most of the time, we just copy over the code and move on.

Why is that a problem? After all, it's quicker to just move forward isn't it? Copying the code into my class makes me productive right now.

The problem comes when the copied code needs maintenance. Perhaps it needs to be faster or tweaked to run with the latest toolkit (JDK 1.5 anyone?). Maybe the original code has a bug.

For whatever reason, you need to update the code. If there is a common routine to use, the code changes go in one place. If the code has been copied a dozen times, someone will waste a lot time trying to find all the code that needs updating. And odds are that some of the code will be missed.

Think about it this way. The last time you fixed a bug, did you search the rest of your codebase to see if the bug existed in other code? I know I usually don't.

Another more subtle reason to use CPD is to keep your code more readable. When your code is littered with aptly-named utility classes, it reads easier and is easier to understand. Instead of reading a for loop to understand what it's doing, you'd see a routine called sort_users_alphabetically or select_unique_values. Any of us would instantly understand what the routine was doing but understanding the for loop might be more of a challenge. Especially given how some people like to write code. ;)

They even have a GUI that runs using Java Web Start. If you have a recent version of Java, you don't even have to install anything. Just click this link and point it at your local code tree. You can't get much easier than that.

Is it a tool you need? I've been amazed at how often blocks of code have been copied not once but dozens of times. I've seen this in code from teams that turn out very good code and teams that don't. From what I've seen it's much more common than most people think.

Here's my challenge to you. Try it. See what it finds.

Then try to justify each copied block to yourself. Does the code really need to be copied or do you have an easy refactoring waiting to happen?

Reducing your lines of code, creating more readable code, and easing your maintenance work all at the same time. Sounds like a good day to me.

Jared

posted at: 22:15 | path: | permanent link to this entry

Eclipse or NetBeans?

I didn't realize there was a huge debate raging over the IDE of choice for Java developers. A friend recently forwarded me several links about the debate. I pass them on for your enjoyment.

Why Eclipse Developers Are Moving To NetBeans

Eclipse vs. NetBeans *yawn*

NetBeans vs. Eclipse - No Real Debate

After reading these entries, I think you'll agree that there is no debate. Everyone seems to agree that there can be only one winner. Now, if we can get everyone to agree on who that one winner is...

Seriously, here are a few observations.

First, competition is good. Having NetBeans chasing Eclipse will keep Eclipse sharp. And the same for NetBeans. Everyone runs faster when they are racing against someone else.

Second, if you're stuck in an IDE and don't know what it's doing for you, then you've done yourself a huge disservice. I strongly encourage you to be able to build your Java projects with Ant, your dotNet projects with Nant, and so forth.

Yes, it's more work at first, but you are buying yourself understanding. When Eclipse or NetBeans won't do what you want, you'll have an alternative. You'll also have a much better chance of understanding ~why~ things break. And it's inevitable that breaks will occur. The only question is whether or not you'll have to depend on your IDE's error messages to understand them. Don't put yourself in the position of having to switch IDEs to get a better error message.

And finally, try the other tool. Whichever one you like, try the other one. Stretch your brain and learn something new. Eclipse doesn't stink. And neither does NetBeans. In fact, I really like them both. I'm actually doing a bit of work in NetBeans today. I haven't used NetBeans in at least a year but it's come a long way.

You know, if there hadn't been a raging debate, I never would've gotten around to trying out NetBeans again.

Thanks everyone!

Jared

posted at: 20:17 | path: | permanent link to this entry

Daily Meetings: Who's Next?

I am involved with two teams who both have short daily meetings (SCRUM style meetings). Over time these meetings can fall into a bit of rut so we try to find ideas to break up the routine a bit.

One way is to have the last person who shared select the next person to share. Of course, this also tends to fall into the same rut. People tend to pick the person to their right or left and you end up going in the same circle you were trying to avoid.

So we created a next person selection rule.

You can't select anyone to your right or left unless there are no other selections available.

Letting people pick the next person is actually quite fun. We got the idea from Matt Bass who learned it while working with Ken Auer. You wouldn't think such a simple change would make much of a difference... who else has a tip or two to share? Mail them in and I'll post a follow-up.

Jared

posted at: 13:44 | path: | permanent link to this entry

But where are the Lava lamps?

Tonight on David Starr's blog I see that he's gotten himself addicted to the CruiseControl.Net Tray application.

I think that's a fine addiction to have David... but do you plan to add Lava Lamps to the mix? These lamps are red and green for the holidays, but the original used plain old Lava Lamps.

You've come this far... it seems a shame to stop now doesn't it? ;)

Jared

posted at: 00:16 | path: | permanent link to this entry

Tue, 20 Dec 2005

"JBoss At Work" Was Named Poorly

I recently met Scott Davis at a software conference. Since we both had new books in our hands, we traded books. I gave Scott a copy of Ship It (which he was kind enough to review) and he gave me a copy of JBoss at Work. Every time I pick this book up I find myself still reading it half an hour later. It's a very easy book to read and a hard book to put down. :)

Let me start by addressing my comment about the naming of the book. The name doesn't begin to do justice to the breadth of the topics in this book. From the title, I expected this to be a book on how to use JBoss. While the book does cover JBoss very well, it does much more as well.

Many people have complained about the size of the Java stack. This book gives you the introduction you need to the entire stack. Starting with Java and Ant, it takes you through cascading style sheets, JSPs, servlets, EJBs and finally into web services. It even gives you some JDBC and Hibernate.

They also provide you with practical tips and examples as they go. For example...

In the first chapter they said they kept hearing "I don't wan to be an expert in it. I just want to make it work." That's what they've delivered. They don't take you into the plumbing of Hibernate or JBoss. They give you what you need to use Hibernate and JBoss and be productive. And many times that's all we need.

This is the best book I've read for providing an end-to-end introduction to the web services space, including the technologies that web services utilize. Also, they make a point of using freely available tools for every example. This is a book you can buy and then follow the examples at home without buying any extra software.

Are you planning on moving into the Java web services space? Then I suggest you get a copy of this book and read it first.

Jared

posted at: 14:53 | path: | permanent link to this entry

Leornard Nimoy Sings "Bilbo Baggins"

I'm not sure what to say... it's humor. Laugh? A great post the week before Christmas... as a break? :)

I found this on Digg.com a few weeks ago but it's not there anymore (that happens a lot!), so here's the direct link to Google Video.

Link

Enjoy... or at least laugh at what people archive for posterity.

Jared

posted at: 11:32 | path: | permanent link to this entry

Unit Tests as a Gateway Drug

As I rule I encourage people to avoid unit testing and write higher level tests. There's nothing wrong with unit tests and I'm not opposed to them, but it seems like we are, as an industry, overly focused on unit tests to the exclusion of other types of tests. I try to encourage people to write tests that exercise more of their application. Mock client tests are my favorite type. They exercise more code than a unit test. When used in a Continuous Integration environment, you still get really good feedback on where problems are. Mock clients are coarse-grained tests in a fine-grained build.

Recently I'm encountering more teams whose code is "untestable". They're convinced that their product isn't testable because it has a browser GUI.

First, that's just flat out wrong.

Do you have a browser front-end? Then look at Watir, Selenium , htmlunit, and others.

But I've also found that unless the entire team gets involved, creating an automated testing suite is more difficult than it needs to be. It's so much easier when there's a team involved. But the idea that "our product isn't testable"... that's a difficult mindset to overcome.

So, in the cases when I don't have the bandwidth to create a suite of tests myself, I'm starting to sidestep the opposition.

Assuming that your product isn't testable from the GUI, your units are testable. So we'll start at a level you can't argue with... unit testing.

So far it seems to be working... my goal is to introduce automated testing via unit tests. Then we'll broaden their horizons a bit. :)

I'll let you know how it works out.

Jared

posted at: 11:16 | path: | permanent link to this entry

Mon, 19 Dec 2005

Dual core Mac laptops in January

OSX has pulled the Mac line from it's traditional role as a niche operating system and positioned it for a strong run this year. I know a lot of people who've converted and aren't coming back. At the No Fluff Just Stuff software symposiums most of the presenters were on Macs. Macs just seem to be popping up everywhere as both a development platforms and desktops.

I've been waiting for the Intel versions of the Mac for my purchase though. I nearly bought a Mac Mini several times because my publisher has a very nice book rendering system that runs everywhere, but it runs more easily on a Mac. :)

However, now I'm now holding out for a Mac laptop. The rumor mill has persistently put the release for these notebooks in January, but the more recent rumors (today from from Think Secret, earlier from Mac Rumors) are saying the laptops will contain Intel's new Yonah processor and be dual core laptops.

From the Think Secret article:

Yonah's launch could mean that dual-core Yonah iBooks, at speeds of 1.5GHz, might be announced in January

Think about that for a minute. As a desktop, a dual core machine is just as responsive as a dual processor machine. That level of power will be in a laptop and it will be a Mac. It won't hang when you compile. It won't drag while you run twenty programs.

Again, OSX has converted many people in the last year. Now Macs will be on a more compatible hardware platform. And they will have the most responsive laptops on the planet.

I'll be in line when they are released. If only they were ready for Christmas!

Jared

posted at: 14:20 | path: | permanent link to this entry

Lisp programming videos

Following the lead of the Ruby on Rails guys, Sven Van Caekenberghe made a Lisp tutorial video.

The site is ~really~ slow. I suspect that Sven is overloading his hosting provider. :) Be patient. It will eventually load.

From the page:

Lisp Movies: Episode 1: HTTP Client and Server My first screencast showing how to use the HTTP protocol as client and server in Common Lisp, featuring the LispWorks IDE on Mac OS X.

Remeber what Dave and Andy say about learning one new language a year? Here's another good jumping in spot. (When's the last time you learned a new technology or language just to stretch your brain and provide a fresh perspective?)

Enjoy!

Jared

posted at: 12:33 | path: | permanent link to this entry

Sun, 18 Dec 2005

Carnival of the Agilists

I stumbled across the Carnival of the Agilists this week. It's a periodic blog with lots of good agile software links.

The Scrum graphic was great.

I also really liked the bit on how to handle legacy code. ;)

Enjoy!

Jared



posted at: 21:22 | path: | permanent link to this entry

Fri, 16 Dec 2005

Ruby on Rails Quickstart Bundles

If you're on OSX and wanting to experiment with Rails, then check out the Locomotive project on SourceForge. (Thanks to Charlie Squires for sending me the link!)

If you're a Windows or Linux user, then check out Instant Rails

In both cases the teams have bundled up Ruby, Rails, a database, and everything else you need to run Rails, verified the versions all work together, and bundled it all into a single package.

From the Locomotive web site:

Locomotive is a flexible one-click solution to Ruby on Rails development for Mac OS X 10.3+. In one self-contained application, it gives you a fully functional Rails development platform including: (but not limited to)

From the Instant Rails website:

Instant Rails is a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all preconfigured and ready to run. No installer, you simply drop it into the directory of your choice and run it. It does not modify your system environment.

This is the best way I know for a Rails novice to get up and running. I haven't used the Locomotive project but I have tried Instant Rails and it works great.

Why post about Rails again? Because your brain needs exercise. Learn something new over the holidays. :)

Enjoy!

Jared

posted at: 20:54 | path: | permanent link to this entry

Found- One Digital Camera. Your Pictures are on Flickr

This is cool. Here's the link

From the Flickr post:

we found a digital camera. if you know any of the folks in these pictures, have them email me with the following info for the return of their very nice camera: tell me where & when I found it/where it was lost (city and particular circumstance), the size of the memory card, make & model and maybe identify some of the other folks on the card (not pictured) and i'll be happy to ship it home. I just feel bad for whoever lost their family photos. Thanks! Camera was found in USA, New York state.

Here's hoping someone gets their camera back in time for Christmas! If you recognize anyone, pass it one. I know the odds are low but this seemed like a nice one to pass on.

Jared

posted at: 07:17 | path: | permanent link to this entry

Thu, 15 Dec 2005

The New Practice Didn't Help

So what do you do when you've introduced your teammates to the latest greatest practice and it didn't do any good? What if it makes things worse?

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

The New Practice Didn't Help

We've talked all through this book about "standing on the shoulders of giants." The best way to do that is to learn the practices that the giants are using and use them yourself. There's always room for improvement in any software shop, so always be on the lookout for better practices that will provide that improvement.

When Not to Introduce a Practice

It seems strange to start here, doesn't it? But many shops add new practices and process when they're not necessary or at a bad time when they'll be disruptive to critical work. They end up causing more problems than they solve. The first question you should ask yourself whenever you're thinking about adding any practice should be, "Is now a good time to do it?"

Don't try to introduce a new practice or process if there isn't a problem that needs fixing. Never introduce a change because it's "the right thing to do." Instead, identify the actual problems in your shop, and then figure out how to fix them. Before you know it, you'll have a smoothly running shop because you've fixed only what's broken.

TIP: Only fix what needs fixing

Be creative when thinking about problems and fixes. "There's more than one way to do it" (The Perl mantra, noted at the bottom of the Perl man page) applies to more than just Perl programs! There are lots of ways to successfully run a software shop. No set of practices and no process will always work for every team on every project. You also need to think about what else is going on in your shop before you introduce a new practice. Three days before a major release is probably not a good time to change your current process. Your team will probably not take kindly to any distractions when they're frantically trying to get the product out the door. A much better time would be a week or so after the product ships, so the team can "catch their breath" before considering the change. So choose a time to introduce the practice that will minimize disruptions to critical activities.

TIP: Disruptive "best practices" aren't

And of course, make sure the practice or process you're considering will actually improve things. If it won't make things run faster and more efficiently, your team won't (and shouldn't!) adopt it. As far as they're concerned, "If it lets me go home at 5 p.m., I'll do it."

How to Introduce a New Practice

Once you've decided to add a new practice to your repertoire, how do you go about doing it effectively? There are two main things you've got to do: demonstrate and persuade. Accomplish these two goals, and you'll have a group of raving fans in no time. You've got to get buy-in from several groups of people. First and foremost are the people who will actually be practicing the new practice, namely, your team. If they aren't excited about it, it won't matter if anyone else is. How many stories have you heard about companies that have mandated from the top down new ways of doing things? And how many of these mandates have produced lasting change for the better? (Answer: not many. Think Total Quality Management, ISO-9000, and the like.)

Conversely, how many times have you heard about technologies and practices that have been brought in at the grassroots level, which then sweep through a group, company, or even industry like wildfire? (Think UNIX vs. mainframes, PCs vs. UNIX, agile development vs. the Waterfall software development model.)

TIP: Innovate from the bottom up

So how do get your team excited about this new idea? Remember we talked earlier about demonstrating? Show them the process or tool; don't just tell them about it. In particular, show them how well it works, especially in comparison with the old way of doing things.

If you know a "raving fan" who has actually used this practice to good effect, bring them in and have them show the group how well it has worked for them. Even better, use it yourself. Build up evidence about how much more productive and efficient you are, and then tell your team about it. You probably won't have to do much talking because the team has probably already noticed how much better you're doing! The key is to prove that this new-fangled idea is everything you say it is.

TIP: Show, don't just tell

Persuading your team to use this new practice is critical. That's not to say that you can completely ignore your management, however. Getting buy-in from your manager makes introducing a practice easier. Your manager can persuade those team members on the fence about the idea to give it a try and can act as a shield from the rest of the company. Such shielding can give your group time to figure out the best way to implement the practice. And obviously, it's easier to work out a change in your group when you don't have to hide what you're doing.

If you can't get management buy-in, don't let that dissuade you from adopting a practice, especially if the team is excited about it. Treat it like a "stealth practice," and use it quietly but fully. Practices like code reviews don't require management buy-in to be effective. You can use them without anyone outside your team being aware that you are having code reviews. You can set up a CI system on your own box and share the results with your team. After you've gotten some experience with the practice, show the practice, along with the associated benefits, to management.

TIP: Cultivate management buy-in



posted at: 20:06 | path: | permanent link to this entry

Tue, 13 Dec 2005

Desktop Linux Today

In this blog entry James Robertson says he doesn't think Linux will ever exist as a viable desktop alternative because things don't "just work".

I'd encourage James and others to check out how far the Kubuntu and Ubuntu projects have come.

Everything on my laptop just works... as well as a desktop machine. Wireless cards, USB keys, etc. For me, it all just works. And since both buntus come with live CDs that you can run boot and run live, trying out the system doesn't require a partitioning or an install to your hard drive.

Out of the box you get an office suite, graphics editors, and a lot more. And they all just work.

Don't get me wrong. I'm a fan of Windows and OSX, but neither comes with all the applications you need out the box.

I've used Linux since Slackware was the only game in town. There was a time that James was right.

But today? I'm not convinced. What do you think James? Willing to give Kubuntu a whirl? It might surprise you!

Jared

posted at: 18:15 | path: | permanent link to this entry

I Hate Email

Really. I do. Somedays more than others. Today? A lot. :)

Email is a very poor medium for communication. It's just flat text after all. ASCII. But it's one of the main communication methods geeks use. Andy Hunt often says that the bandwidth on email is limited and I experience that more somedays than others.

So what's wrong with email?

You can't see the smile or the frown. Whether you're the sender or the reciever, you have no idea what the tone behind the message is. You're left to assume the tone. Sometimes this works quite well. Sometimes it doesn't. When the reader is having a bad day, even a well-composed email can be interpretted poorly.

You can't stop talking in the middle of an email. In a face-to-face conversation I can see you getting angry or annoyed and stop talking. With email, you've got the entire message already typed out and if something strikes your reader the wrong way you can't snatch it back again.

So the tip for the day is this. When you recieve an email and you're just sure the person just attacked you, don't reply.

If you have an overpowering need to reply, remove all names from the To: field... this avoids accidentally sending out the message with a wrong keystroke. Then type up your reply and save it in your Drafts folder. Don't send it.

Then do one of two things. The first and best option is wait until tomorrow. Give it time to cool off and for everyone to get a little perspective. Sleeping on it is a great idea.

Second, walk over. Call. Switch the conversation to a better, richer communication medium. Make a personal connection with the person involved and find out what was really going on.

Assume it was innocent and see what happens. It won't always be a case of misunderstood intentions, but I find it very often is... and it's a very nice surprise when that happens.

Have a comment? Send me mail! :)

Jared

posted at: 12:34 | path: | permanent link to this entry

Mon, 12 Dec 2005

Validate your RSS feeds on line

Here's a handy utility. It's called the Feed Validator. And it does just what the name implies.

About once a week I'll paste in a character from a word processor or from a PDF and that character isn't allowed in RSS feeds. My blog software doesn't mind it, just passes it in the RSS feed. Then I start hearing from people that I've posted a bad feed again. (Sorry about that!)

It's usually one of three problems. First, an angled single paren instead of a straight, proper paren. A good one looks like this '

The second and third errors are double parens. One is the right paren, the other the left. Replace them both with regular parens like this " and you'll be fine.

Just hit this handy url and you can validate your feed (or someone else's) to see exactly what the problem is. And while I've found it doesn't do a great job of pointing out the offending line or character, it always gives the correct error message with the right Hex value to match up to your offending character.

Enjoy!

Jared

posted at: 01:26 | path: | permanent link to this entry

Sun, 11 Dec 2005

Experimenting with Google AdSense

I'm curious to see how Google's AdSense works, so I'm trying this page out.

I'm not sure if this works better than the header block (which may or may not be in the version you are looking at right now). I might remove the image/text mixed ad block and put in a text block (like exists in this blog entry).

Over the next week or so, I'll try out a few different formats and see what is the least intrusive but still effective.

I'm not looking to be a professional blogger, but it would be nice to cover some basic hosting costs and maybe even pay for a toy or two. Google AdSense seems to be the most popular and painless way to experiment with this type of revenue ex blog.

However, since Google won't let anyone talk about how much money they pay out, I have no idea if this is a complete waste of time. But I thought I should at least let everyone know why the ads are appearing. Just an experiment.

I was on the fence until I saw this page which made it sound very simple... and it was.

What do you think? Is it hideous? Does it detract from the message? Annoy you greatly? :)

Seriously, let me know. If I get dozens of emails complaining, they can be removed quickly. I'll take silence as approval or indifference.

Jared

Update: Apparently the way that Bloxsom publishes it's headers has caused the entire blog the RSS feed to look like it was just published. (sigh). The actual blog retains it's orginal order and time stamps. Sorry about that.

posted at: 19:42 | path: | permanent link to this entry

Thu, 08 Dec 2005

Humane Interfaces versus Minimal Interfaces

There's been quite a fuss about Martin Fowler's post on Humane Interfaces. If I summarize his post for the sake of brevity, a larger, more humanly readable API is preferable to a smaller, more cryptic API.

The discussion seems to be falling into two camps. One side says that if you are a ~real~ developer, you'll invest the time to learn the API. Then, as a skilled user, you'll apply that skill and build something.

The other camp seems to feel that with a human readable API, you just skip the "invest the time to learn the API" and move straight to building something.

Hmmmm...

Spend time learning Yet Another Unique API... or write code.

Spend time bulding a smaller, tighter, cleaner, more cryptic API... or make it easier to understand ~and~ use?

In my experience a team writing an API will spend a minimal amount of time adding these additional API calls. But the performance increase I've seen on the teams using this technique is substantion.

Remeber, the API developers wrote the API code. They know it better than anyone. For them, adding a first() and last() routine will take 30 seconds. Literally. The other option is to force your end users to learn the API well enough to know if the last() call should be list.indexOf(list.size() -1 ) or list.indexOf(list.size()). These bits of arcane, useless trivia should not be force fed to your users. It's just inefficient.

What was the argument again?

Jared

posted at: 23:54 | path: | permanent link to this entry

Testing Untestable Code

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

Testing Untestable Code

If you are a developer or tester trying to get an automated test suite set up for your product, you may find yourself in the uncomfortable position of trying to test a product that doesn't have good "hooks" for your test rigs. It's not impossible to test "untestable" code, but the effort involved in test creation and maintenance usually cancels out the benefit of the automation.

For instance, you might be trying to test an HTML page that has a lot of unnamed fields. So instead of using the "name" or "id" tags to locate a field, you count the items on the page and check the value in the fifth item. This is very difficult for someone else to understand and maintain, but the test is also very fragile. Often, changes to the page will break your test.

What's the solution? Tell your manager you want to start test driven refactoring. You want to start adding the simple hooks to your application that make it possible (or feasible) to do good automated testing.

First, create (or borrow) a test plan for the product. Keep the plan simple at first. Don't try to make it perfect on your first attempt. Shoot for a simple pass that exercises basic functionality.

Second, write an automated test. Make the test go as far as you can. When you get stuck, what's the least amount you can add to the product's code to get the test running? Is it just a return code to an existing API or an "id" tag for an HTML field?

Don't try to fix every problem with your first pass. Don't try to add "id" tags to every page in your product; shoot for the one page you need to get the test passing. If your test plan hits a roadblock, don't stop. Remove the part of the test plan you can't test and move on. Remember that you can also add the hard part to your next test plan.

The goal here is incremental improvement and momentum. As you make small improvements, your developers will start learning how to create testable products. As you write automated tests, you'll start learning tricks too. You'll be surprised at how much support you'll get once you've got a basic automation suite in place.

The Tip?
Use test driven refactoring to clean up untestable code

Related blog entries: Test Driven Refactoring and One Test per Feature

posted at: 23:22 | path: | permanent link to this entry

Targetted Skills Acquisition Versus Free Range Chickens

I've had this floating around in my head for a while. It all got started after someone told me that they though conferences were a waste of time. In this person's opinion you never come away learning enough to be useful. The learning is only skin deep and you learn things you shouldn't try to integrate at your day job anyway. If the course is on Spring and your company is using Struts, you've just split the mindshare and possible diverted your project.

This point of view is what I call Targetted Skills Acquisition. Learn only what you need to get through next week. When you need to learn Hibernate, go learn it then. Buy a book, go to a class, or just download something and get to work.

On the other side of the fence, we find Free Range Chickens. A free range chicken tends to browse around, learning a bit over here and a bit over there. They do tend to waste an lot of time learning things that they don't need to know. Most of the tools and technologies chickens learn are never used.

When a problem is encountered, who can solve it the quickest? The chicken can. Someone who browses a wide variety of technologies will immediately know what category of technology can be used to solve a problem. A targetted personality will have to research the problem before they understand how to attack it. However, the chicken has been "wasting" time all along, learning lots of other bits they never use.

When solving a computational intensive problem, a chicken might look to a grid or a distributed solution because they've read about grids and are familiar with the concepts even though they've never used them before.

The targetted skills person isn't familiar with ideas like grids, so they spend a lot of time trying to tune their code to run as fast as it can on a single machine. It's a very traditional approach that prevents the application from scaling to a true enterprise solution.

Another factor to consider is that a chicken who learns about both Struts and Spring is more qualified to evaulate both and understand which one solves their problem better. If you are ignorant of the strengths of alternatives, you can't make an educated choice about the technology. This is why targetted skill types so often pick the wrong technology for a problem. It drives a good chicken crazy just watching it happening.

What is the correct approach?

I am a Free Range Chicken through and through, but I work with some very smart and effective people who are completely Targetted Skills Acquisition.

|'ve seen times in my life when I wonder if a more focused approach wouldn't have served my employer better. Would we have turned out product faster if I had been more targetted? I don't know.

But I also have seen many targetted skills people completely miss the boat with their technology choices. Their lack of broad exposure causes them to re-invent the wheel poorly instead of using a simple, existing solution. They are ignorant of industry best practices so they don't use them.

A few years ago I spoke to an "industry veteran" at the top of his game. This person had more than a decade of software experience but had never heard of MVC. He wasn't dumb- in fact, just the opposite. He understood the concept and it's benefits immediately when I showed it to him. He just hadn't been exposed to it before. He's a very smart person, but extremely targetted. And no, he wasn't coding assembly or device drivers. He was able to use the idea to do his job better.

It's not that a Free Range Chicken type is any smarter than a Targetted Skills Acquisition person. It's that they are more broadly educated.

So, what's the balance? How do we both stay educated and effective?

How much do you strive for targetted learning versus browsing across the free range? The fact that you are reading a blog tells me that you have chicken tendencies. :)

How, as a company, do we encourage both ideas? I'm thinking this is something that Google's policy of letting everyone spend 20% of their time on an independent project might address.

I'm struggle with this topic every day. I wonder what types of solutions others have found?

Jared

posted at: 21:30 | path: | permanent link to this entry

Java Code Coverage Tool Cobertura Released

The open source toolkit Cobertura released a new version this week. They made some major additions, including support for AspectJ compiled code. Cobertura continues to improve with every release.

It's adoption is increasing as well. The SourceForge statistics page says Cobertura's had over 7,000 downloads and more than 400,000 hits on the web site.

Are you using code coverage? A coverage tool will tell you what parts of your source code are being exercised by your test code and what parts aren't. It's the only effective way to knowing what code is completely untested. It formats this information in XML files or, if you prefer, a nice report to make it easy to digest.

Here's a quote from the release notes:

We've just released Cobertura 1.7. We fixed the problems with the merge task, as well as a few other bugs. The full list of changes is below.

If you've never used code coverage, head over to SourceForge and download the latest version of Cobertura. The introduction page will show you exactly how to use it.

Enjoy!

Jared

posted at: 21:10 | path: | permanent link to this entry

Tue, 06 Dec 2005

Google Mapping Made Simple

If you've ever heard Scott Davis speak on the various real world mapping APIs, then you know how easy it can be to get started with your own mapping applications. He really makes the topic come alive with lots of relevant, clear examples. You come away knowing enough to get started immediately with just the sample code from his presentation.

I got to hear Scott at a No Fluff Just Stuff conference in Reston, Virginia earlier this year and it was great. I still have the Power Points on my desk! :)

However, he's now made it easier for everyone to participate. Scott just completed a Friday for the Pragmatic Programmers. A Friday is a short, PDF only document. Friday's are designed to get the information in your hands quickly and easily, so they are short and to the point. They are also much cheaper than a book!

Scott's Friday is called Google Maps API: Adding Where To Your Application and brings the same flavor of his NFJS talks to your desktop The code snippets can be copied right out and the links are clickable.

If you have thought about tinkering with the mapping API from Google, you owe it to yourself to pick up a copy of Scott's paper. I think you'll be glad you did. It's a great way to jump start your mapping work or just learn something new to exercise your brain.

Obligatory disclaimer: the Pragmatic Programmers also published a book of mine.

Enjoy!

Jared

posted at: 21:21 | path: | permanent link to this entry

Java versus Ruby on Rails

Rick Bradley posted an interesting write up of an evaluation of Ruby on Rails. He raises of a lot of good points about both technologies and it's a good piece to make you think.

You'll find the blog entry here

Enjoy!

Jared

posted at: 20:56 | path: | permanent link to this entry

Chainsaw Managers

Kevin Smith forwarded me a great blog entry entitled Ode to a Chain Saw

What can I say? Just read it. :)

Enjoy!

Jared

posted at: 20:29 | path: | permanent link to this entry

Sun, 04 Dec 2005

Help! I've Inherited Legacy Code

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

Help! I've Inherited Legacy Code

You've inherited a legacy product that you will be maintaining and enhancing. What's the quickest way to get a handle on it? Learn to build it, automate it, and finally test it.

1. Build it
First, figure out how to build it, and then script that build process. This task isn't always easy, especially if the code has had only one owner. The code will often build on only one machine because it relies on the surrounding environment. Once complete, anybody can build the product on any machine. After that, it should be easy to automate the builds.

2. Automate it:
Your goal is to automatically build and test the entire product on a clean machine with an absolute minimum of manual intervention. We didn't say no manual intervention; there's a balance here. Sometimes it's easier to manually install and configure a supporting piece of the environment than to write a script to do it automatically. Apps that you install only once are prime candidates (compilers, etc.). Document all the build steps and make this documentation publicly available.

3. Test it:
Figure out what the code does, then begin testing by writing mock client tests for it (see the sidebar on page 45). Once you have the project building cleanly, you'll want to confirm that it works. In order to write the tests, you'll have to learn exactly what the product is supposed to do (no surprise there).

Mock client tests are a good starting point: they test the broad functionality of a product because they act just as a product user would.

4. Test it more:
Figure out the product's innards (things such as structure, flow-of-control, performance, and scalability), and write more tests for it. Unless the product is completely unused, there will be bugs you'll need to fix (or at least document) or enhancements you'll have to make. Normally these changes are a pretty scary thing to do to legacy code, because you're never quite sure what you're going to affect when you make a code change. But you can do this fearlessly because of the mock client tests you wrote as a safety net; they'll keep you from breaking things too badly. (You did write those tests, didn't you?)

Write a new test for every bug you fix and for every enhancement you add to the product (see Defect Driven Test Creation). The type of test you write will depend on what you're changing (e.g., a unit test for a low-level internal change, or a mock client test for a new feature). At this point you're treating the legacy product in the same way you would any other product you support.

After you've done all this, anybody will be able to support this code! They'll be able to automatically build it anywhere and then confirm it's working correctly by running the automated tests on their desktop. And the automated build system will run the build and tests again in a clean environment to be sure that everything is really still working.

The Tip?
Don't change legacy code until you can test it

posted at: 19:21 | path: | permanent link to this entry

Common Problems and How to Fix Them

The last chapter in Ship it! A Practical Guide to Successful Software Projects is called Common Problems and How to Fix Them (also known as the FAQ). The chapter is a series of FAQ-esque entries with some solutions to those problems. I'm going to mix in a few of the topics as blog entries over the next few weeks.

If you've read the book and would like to see a particular entry published, let me know. Also, if you have an entry or answer you'd like to see expanded, this would be a great time to ask. :)

Thanks!

Jared

posted at: 19:19 | path: | permanent link to this entry

Sat, 03 Dec 2005

Military bloggers

I saw a link today on Digg about a site that links to lots of military blogs. The site is MilBlogging.com

I've only looked at a few of them, but it seems to be a refreshing way to get a front line view of various situations world-wide. Seems to be weighted towards Iraq.

It's nice to see what real people are thinking and seeing without the "media" helping to interpret everything. This is what I think about when I hear people talking about bloggers as citizen journalists.

Enjoy!

Jared

posted at: 12:35 | path: | permanent link to this entry

Thu, 01 Dec 2005

Java Sails on Rails

A co-worker of mine posted about a Java version of the ever popular Rails framework. Sails looks very interesting but I haven't had time to play with it myself. The guys involved hang with a very smart crowd though and that alone gives it some credibility with me.

Here's the link to Matthew Bass' blog entry on Sails.

Let me know if you like it. I'm quite curious to hear about how well it works.

Jared

posted at: 19:46 | path: | permanent link to this entry

More on Continuous Sin


A few weeks ago I blogged on Continuous Sin, a very interesting Continuous Integration product.

The idea that a code change can be automaticlly rejected if it fails to pass the test suite is intriguing. I also liked the idea of running on multiple machines to help the system scale.

Casper Hornstrup, the author of Sin (is that a resume line item or what?), saw my blog entry and sent me mail answering a few of the questions I raised. With his permission, I'm posting his reply.

Hi Jared.

At http://www.jaredrichardson.net/blog/2005/09/08/ I see you've found Sin. I'm pleased that you like it as I'm the author of this project. Sin is still in the prototype stage, so it has very few features compared to other CI systems and it is not yet as stable as other of the more mature CI systems.

That said, I've been running Sin on Sin's own Subversion repository for several months now with great success.

Sin does run the Sin NUnit tests in addition to compiling Sin in this set up so this answers your question of whether or not it can also run tests. Actually, Sin has the concept of a verifier. The verifier is a program that will choose whether or not a given change is to be merged to the stable branch. The verifier can be as simple or as complex as required by the set up. A simple version (which is what Sin repository itself uses) can just run GNU make or NAnt which will just process the makefile or NAnt build script and return with an appropriate exit-code. A more complex set up could for instance publish binary images for each revision for easy regression testing. We use Sin to do this at the ReactOS project. See http://svn.reactos.org/iso/. Sin is actually built to solve several problems of the ReactOS project.

If you have any questions, then I will be happy to answer them.

Regards,

Casper

Sounds like it's worth checking out.

Enjoy!

Jared

posted at: 15:57 | path: | permanent link to this entry