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

Thu, 20 Apr 2006

Tips for Writing a Ruby On Rails Database Adapter

I've been working on a Ruby database driver for Ingres. Most of the work has been in C, but I finally have my Ruby code (via C) fetching data from the database.

Now I'm starting on the Ruby on Rails portion. It involves adding a lot of additional calls that I didn't have in place. It's actually a pretty big test suite to get your head around. I'm sure it'll be simple once I understand it all. :)

I met Mike Laster at a local Ruby meetup. He's writing a Rails adapter too (small world!) and he's been giving me a few hints. I thought I'd pass on a few of them.

Build against the stable version first so you don't have a moving target. Once you pass 100% of the tests, then work on integrating it into the trunk code.

When you run the unit tests, it is easier during development to focus on one unit test at a time instead of getting flooded with thousands of errors at a time.

The trick I use is:

- Change to the rails/activerecord/test directory
- run "ruby -I "connections/native_frontbase" adapter_test.rb -v

adapter_test.rb seems to be a good one to start with. If it doesn't pass 100% there is no hope of any other test functioning.

The first few that I remember needing to pass were:

The other tests tend to fall into place once these are working.

Hopefully this will help out a few other people as well.



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

Looking For a Job? Evoca is Hiring.

One my college buddies, Eric Star is at Evoca, a very cool startup. I'm not going to try to tell you everything they do... I'll just say that they let you post audio "blogs" and make them searchable. There are free accounts and professional level accounts as well.

Here's an article about them over at TechCrunch.

Eric and I recently talked and he asked if I knew anyone looking for work. He wants some JSP experience as well as some database background. Telecommuting doesn't sound like it would be a problem for the right candidate.

Here's an Evoca clip of Eric describing the job himself. :)


Here's a text description as well.

Evoca.com is Seeking a Java/JSP Developer Our startup (warning, marketing term follows :-) ) web 2.0 team is looking for 2 Java/JSP Developers (full time hours) who can join us to help develop and enhance an existing web application. The developer should have a solid understanding of developing web applications and be able to solve bugs and generate new developments based on project scopes. This position requires the ability to use your own computer as a development environment since the position would mostly involve telecommuting. We are still in "seed money" stage and are aggressively seeking VC so this will not be a top dollar gig and all positions at this point are Contract based.

posted at: 08:52 | path: | permanent link to this entry

Sun, 02 Apr 2006

Finally Got My Dual Core Mac Laptop

I finally got myself a MacBook Pro. This is the first Mac I've every owned or spent any serious time on, so I guess I'm what the Mac folk call a "switcher". Given that I've spent a lot of time on Windows and Linux boxes, I thought my impressions might be of interest to others thinking about this new Intel Mac platform.

Let me first say that it's decently fast but not blazing... but let me qualify that statement. I'm very picky about what I call fast. Compared to a G4 Mac laptop, it's blazing. Compared to my now dormant 1.8 ghz Celeron HP laptop, it's a speed demon.

Compared to my existing desktop, it's decent. My desktop, which I planned to replace with the MacBook Pro, has dual 1.4 ghz Opterons, 2 gigs of memory, and an Nvidia 6800 GS video card. And compared to my desktop, the MacBook is decent. It doesn't blow me away, but it holds it's own. In my mind, that's a serious endorsement for a laptop.

The GUI isn't as snappy as I'd like, but that's probably due to all the eye candy I haven't learned how to turn off yet. :) A fresh install of Windows XP is the same way. On the other hand, it doesn't really get bogged down either.

I bought the box with the stock 512 megs of memory and I could see it drag when I had too many programs open. Then I dropped in another gig of memory (obligatory plug for Crucial.com. They guaranty compatibility.) and all the dragging went away. I've ordered another gig so I'll have an even two gigs. I'm told having matching memory sticks lets the Mac double your memory bandwidth. At any rate, I think it needs at least a gig just for standard usage. It was dragging for me with email, web surfing, and tinkering.

Having the dual core process in place means that you really have two processors in a laptop. And it shows. At any time you and I are running dozens of programs. We've got an operating system, graphics drivers, anti-viral software, network stacks, and the list goes on. A modern computer has to do dozens of things at a time. Having a second CPU (or core) lets the computer devote one of them to you. This translates to a very responsive computer. Software doesn't hang or drag even if another program is pegging the processor.

If you buy a laptop this year and you intend to anything beyond mail and web surfing on it, I'd suggest you shop for a dual core system. I don't think you'll regret it.

Let me speak to the Mac experience for a moment.


The first I always do after installing Windows is start fetching utilities. Adobe Acrobat. WinZip. A DVD player. We all have our list of favorite apps we refetch. On the Mac, all the apps were already installed. It can read PDFs, play DVDs, handle MP3s, and so on. The list of pre-installed software is impressive, but it doesn't wander off into what I call "junk software". That's the garbage that most computer manufacturers stuff onto your computers in the hopes that you'll think it's a better PC. The Mac has enough to use the computer but not tons of junk. It reminds me of a Kubuntu install, but better. It's got more programs and everything is already configured.

I did have to add a few things. X11 isn't installed by default but it's on your install/restore DVDs, so that was easy. I had to install a newer version of Ruby as well.

I love the ability to have all the eye candy and then drop to a terminal and type "ps aux | grep ingres" or "kill -9 1827". That's just amazing. Visually it's where I was never able to get Linux. I think it's possible but I never invested the time to tweak everything "just right".

All the hardware works out the box. The bluetooth even talks to my cell phone! I'm used to installing Linux and then having to tweak a few things. It's very nice to just turn it on and use it

The remote. This laptop comes with a remote. I thought this was silly at first. Now I keep my music playing through the laptop when I'm in my home office and control it from the remote. It can skip iTunes forwards and backwards through songs, adjust the volume, and pause. I've been shocked at how much I love this single feature. I never thought I'd use it but now I'm hooked.

It has a built-in camera and some nice software to tinker with the pictures called Photo Booth. My daughter (age 7) loves playing with the "silly pictures". It's truly a blast.

The built-in wireless has a much better range than either of my PC wireless cards. Areas that my laptop would drop connectivity in don't slow me down on the Mac. I don't even notice a slow web experience. It must have a very decent built-in antenna.

I really like the wide screen display. I'm used to having two monitors and I like my screen real estate. However I'm finding I use the wide screen format of the laptop as if it's two monitors. Instead of maximizing everything like I do on a square monitor, I'm actually using the windows paradigm. Nice.

The MacBook Pro also has an external monitor jack. It's an LCD output but it has an adpator for us old-time CRT users. When I plugged in an external monitor I expected some sort of configuration screen. I started clicking through various system configuration utilities. Then I looked over and realized that the second monitor was on and my desktop had been extended on to it. Just like that. No configuration or set up. It just saw it and set it up. Nice.

On the dual monitor note, you can set the relative position of the two monitors in a GUI configuration utility. Unlike Windows though, you can put the two monitors anywhere you want, not just left or right. I set up my external monitor about 20 degrees above the laptop screen. This approximated the difference between the actual positions of the two monitors. It felt weird to actually move the mouse to where the screen was instead of just moving right until I showed up on the next screen. Another nice touch.

I plugged in a USB printer and had it configure itself the same way. Silently and in the background. I'm used to seeing a hardware dialog. I think I like this way better.

The flip side was that the driver for my HP printer wasn't the best one available. I couldn't set print quality, check ink levels, etc. I ended up going to HP and downloading 96 megs of OS X utility goodness. Now I can specify paper type, print quality, and so on.

The magnetic power plug works just like advertised. It's difficult to pull straight out but if you pull it sideways (simulating a three year old's feet kicking the cord), it comes right off. And it attaches with a very satisifying "Click". I suspect every vendor will have something similar inside of a year.

The laptop is very thin. An inch (at most). It's light. The design is very elegant. I can't tell you how many co-workers have commented on how good the thing looks.

And it's quiet. Absolutely quiet. It doesn't seem to have any fans in it.

What about downsides? There are a few.

Remember my comment about how quiet it gets? No fans? Well, it gets quite hot. On a flat surface it will get too hot to comfortably touch on the bottom. The feet on the bottom simply aren't tall enough. I keep it propped up half an inch when it's on my desk to let the heat escape. At the moment I have a small (and quiet) fan blowing air over it sideways. I've seen no problems with the heat, but there's a hard drive in there. I've never seen a hot computer with a hard drive that didn't fail.

On the other hand, when I use it as a laptop, it's fine. As long as you keep set it on your legs and let the bottom have plenty of air, it doesn't get too hot. I used to sit on the sofa and rest my Windows laptop on a pillow in my lap. That doesn't work with this laptop.

I still hate the default key mappings. For me copy is "Control-C", not "Apple-C". The keyboard isn't laid out to make that an easy keystroke. I've been using it heavily for a week and I still can't do a one-handed copy. Cut, paste, and undo (Ctrl-X, Ctrl-V, Ctrl-X) are the same, as are "select all" and save. So far I've resisted remapping those keys (can I do that on a Mac?). I'm trying to learn the "right way" to work in the Mac environment but it's frustrating. It's obvious that the two OSes are copying one another. (Who was first? I don't know or care. It's like Sun's refusal to put a ".txt" extension on their Readme files. When you're different just to be different, it's the users who gets annoyed, not your competition. Sorry... that rant just jumped out!)

All-in-all, it's an incredible machine. It's not perfect, but I think it's worth the money. I plan to use it to replace my desktop so that I can be productive when I'm on the road, I'll have a full development environment with me whether I'm in the hotel or the airport. And this box will do that easily.


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

Mon, 27 Mar 2006

Short Article in Methods and Tools

A short article I wrote entitled The Cornerstone of a Great Shop was published in the spring edition of Methods and Tools. It's a great online only magazine, available via PDF or HTML.


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

Sat, 25 Mar 2006

Blending C and Ruby

A project that I've been working on has involved calling C code from Ruby code. It was much easier to do than I anticipated and I thought others might find it interesting.

Why would you do this? Suppose you have a bit of Ruby code that's too slow in a key portion of your program? You can easily move that bit of code out to C. This gets all the speed of execution in C where you need it combined with the speed of program creation that Ruby provides.

This would also be an easy way to wrap your legacy C code, access hardware with a C interface, etc. The possibilities are literally endless.

So how do you do this? First, let me tell you that these examples are on Linux, but they are pretty simple and I don't think you'll have much trouble duplicating them on Windows. I just don't have a C compiler installed on my Windows box at the moment. If enough people ask for it, I'll set up the environment and run this to Windows, but I don't see how an example this simple wouldn't translate directly.

Another caveat, I'm skimming this topic very lightly. I'm not explaining the "why" behind most of these directions. If you want to go deeper, check out the pickaxe book, avaiable in both the second edition (new, improved, and up to date) or the original first edition (online and free). The pick axe book has an entire chapter on extending Ruby with C.

You need three files to do this work. The first is your C code file, the second is your Ruby code file, and the last is a configuration file called "extconf.rb". Extconf.rb is used by a Ruby utility called mkmf (makes your Makefile). It creates your rather complicated build file for this project.

Let's start with the Ruby file. Here it is.

#include "ruby.h"

static VALUE cSampleC;

static VALUE exec(VALUE self) {
        printf("\n\nExec, written in C, was run from within the Ruby code \n\n");
        return Qnil;

void Init_SampleC() {
        cSampleC = rb_define_class("SampleC", rb_cObject);
        rb_define_method(cSampleC, "exec", exec, 0);

What do we have here? First, you must include ruby.h to make your C code ruby aware.

Next, you need a static variable to hold your object reference. That's cSampleC.

Your C routine has to return the type VALUE. This is equivalent to a Ruby Object. You need to have (at least) a single argument VALUE self. You can have more, but this one is required.

Finally, return Qnil if you really want a void type.

The last block, init_SampleC declares your C objects so that Ruby can see them. This code maps your C to Ruby.

rb_define_class creates a Ruby object for you. In my example, it's "SampleC". NOTE:This object must start with an upper case letter. I worked with "ingres" for nearly two hours before I tried "Ingres" and everything just worked. :( The second argument in this method is your static VALUE object that holds the referenc to this object.

Finally, create a mapping from your routine to your Ruby object. rb_define_method does this for you. The arguments? First, the static VALUE object again, then your Ruby object name, your C method name, and finally, the number of arguments you're passing in (don't count "self").

Okay, we're done with the C file. Let's create a Makefile.

Here's my extconf.rb file:

require 'mkmf' create_makefile("SampleC")

Complicated, but I think you can handle it. :) This file can get a lot more complicated, but this one does all we need.

To invoke this, type:

ruby -r mkmf extconf.rb

If all goes well, you'll see

creating Makefile

Now you can type make, then make install.

At this point, we should have a Ruby object we can run!

The Ruby code is pretty straightforward as well.

require "SampleC"

Of course, you can run this from within irb as well.

That's it. You can now run ruby testMyCode.rb and see

Exec, written in C, was run from within the Ruby code

I'm using this feature to include some database libraries. Let me know if that interests anyone. If it does, I'll write that one up. It's a bit more complicated (and not finished yet!), but if there's some interest, I'll get it posted in a few weeks.



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

Wed, 22 Mar 2006

AJAX: What is it and Where do I learn more?

In a meeting today AJAX was mentioned and several people asked what it was, so I thought I'd pass on a just a little bit about AJAX.

AJAX just means that the web page you are hitting is getting updated without reloading the entire page. Think about most web sites. If you click on a link, or a tab, or anything, the entire page reloads... or a new page loads. This happens even if 90% of the page didn't change. With AJAX, only the parts that change get updated.

The idea here is that you can click a link and only have some of the page's content refreshed... just like an installed application. :) Dave Thomas' Ajax with Ruby on Rails talk has a very simple 12 line example.

For years people have been doing the same thing with the clever use of frames, but lately the idea was finally named (Asynchronous JavaScript And XML). After the idea was named, toolkits started popping up to make it easier to write AJAX-ified applications.

Once Google Maps was released and people really saw the benefit to an AJAX framework, the idea really took off. Google Maps does background fetches of maps that are off your screen. Then when you scroll in any direction, the data is already there and waiting for you. This lets you scroll smoothly instead of waiting for more data to stream down in response to your scroll action.

These days, not using AJAX means your web apps are slower and less responsive. You suck up more server bandwidth and have higher server resource peaks. A good AJAX apps will not resend the same information over and over. Also, by fetching smaller bits of data asynchronously, it spreads out the server side load as well. Otherwise your application must ask for more data at one time, causing less than desirable spikes.

You can read more about Ajax on the Wikipedia AJAX page... however, if you need to move a bit faster, you might want to spend some time with guys who've spent more time with Ajax. There's a Pragmatic Studio: Ajax coming up in Chicago in April. Justin and Stuart are great instructors and have the real world experience to help move your project past the classic beginners problems and straight to solving the problems your customers care about.

Of course, since it's a Pragmatic Studio, you already knew it was good, right? :)


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

Developing Software: The Eclipse Way

I saw a great post on Ed Burnette's ZD Net blog about developing software The Eclipse Way. It had some great quotes and the ideas can be applied nearly anywhere. It's not Eclipse specific by any means. It's about developing good software.

Some of the good quotes:

Project health is stronger than saying "quality". It's the state of a project over time, not just at a point in time. Staying healthy is a team responsibility. No single individual can make a project healthy by himself or herself.

One health indicator is how quickly the community adopts milestones. This means the community can give very up to date information, plus it means the community feels it's stable enough to use. A healthy milestone is consumable.

What does healthy collaboration look like? Good collaboration doesn't guarantee a project's success but poor collaboration almost always guarantees a project's failure. Each team is different but all the teams have to agree on some basic process elements (milestones, bug tracking, continuous integration). All teams (within Platform at least) share the same milestones.

More on UI health: slickness matters. Consider what is possible, and make it real. Finally, you can achieve a lot of stuff in the "spit and polish" time during the last 2-3 weeks.

Have your infrastructure in place early (SCM, collaboration, build, etc.). Realize your early milestones help you calibrate and establish expectations for later milestones. Build what you're shipping right off the bat, and do early coverage of as many parts as possible. Some early work will be discarded, and some deliverables will take longer. But keep the rhythm by breaking deliverables up into milestone-sized chunks.

The primary focus for making "The Eclipse Way" better has been improving the existing tools (individual productivity). For example, developers noticed that plug-in development was a challenge, so over time they've made ongoing improvements for finding API violations, etc.. It's important to both build your own tools and consume them. Then upgrade from individual productivity to team productivity. Empower the team, and tool the process. Make transparent what's going on in a team: how do you integrate things? how healthy is the project?

Wow... did I quote that much? :)

Enjoy! There's more in the original blog entry. Have at it.


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

My Long Week: The Missing Story

I was so tired the week that I wrote My Long Week that I left off the best story. I wouldn't have even remembered it but I told it to someone at work and he reminded me.

Again, as with the original story, if you disgust easy, don't read this one. If you want a hint, just look at the Google Adsense ads I have on the site now. :)

It was Thursday morning. Elisabeth (our 2 year old) was up at 6 am, maybe earlier, it's all a little fuzzy. Since I knew that Debra and Hannah had been up very late (I went to bed at 2 am and they were still going strong), I took Elisabeth downstairs to keep her quiet. I gave her some food, a bottle of milk and turned on one of the kid's channels (Disney maybe?). I laid down on the sofa with Elisabeth. As I drifted off, she was leaning against me, eating, drinking and watching The Wiggles... or something. :) It was a very nice way to fall asleep.

Sometime closer to 8 am Hannah (our 7 year old) comes downstairs. She wakes me up with the question "Do you know what Elisabeth is doing?"

Without putting on my glasses, I peer across the room. "She's watching TV" I reply.

"No" says my oldest daughter. "She's playing in cat throw-up."

As I sat up, shook off the sleep, I put on my glasses as my youngest daughter turned to smile at me. Her hands and sleeves were quite brown. She held up a vile pile of brown... stuff.

And with a beaming smile she says "Daddy look! PLAYDOH!"


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

Tue, 14 Mar 2006

The abuse of SOA and Web Services

Over the last two weekends I've been at conferences in St. Louis and Boston. (I've got to get another hobby!) At both locations I was involved with the Birds of a Feather session for architecture.

I found it very interesting that in both cities, SOA and it's usage was discussed. Teams using SOA technologies (like Web Services for instance) to pass larger data sets are finding SOA works very well.

Other teams that are wrapping very small bits of data in a Web Service are finding them to be cumbersome, ugly, and useless.

The problem is the same abuse of EJB that occurred a few years ago. People took a technology that's designed to handle large, coarse-grained chunks of data (something like getCustomer) and using it for fine-grained data queries (like getFirstName). The technology wasn't designed for setters and getters, it was designed for documents or datasets.

People who abused EJBs thought they weren't very useful either. :)

The trend was very pronounced. Everyone implementing SOAs with fine-grained access thought SOA was a buzzword compliant boondoggle mandated by clueless management. Everyone using coarse-grained SOAs access loved the technology and saw it filling a real need. During both discussions light bulbs went off all over the room. People saw what they were doing right or wrong.

It came down to the concept of what Mark Richards called an application interface versus and enterprise interface. Fine grained access should be available in a light-weight way from within an application. You don't move that to RMI, Corba, or a web service. However, when you have an enterprise interface, it gets shared via Corba or Web Services, and because of that scope and cost, you only share the bigger document requests through those interfaces.

This is just an observation on what I find to be an interesting trend. I think it's significant because Boston and St. Louis are in completely different parts of the country and (primarily) host different types of industry. Yet, they're already bumping into the same issues.

The principal here is to learn the new technology or tool, but don't use it just because you can. Don't use it if you don't understand it. Most of the technology we use falls into the category of YAGNI. You Aren't Going to Need It. New technologies are still good to learn so that you understand when they are appropriate to use, but abusing a new technology just so you can use it tends to cause more problems than it solves.


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

Mon, 13 Mar 2006

My Long Week

Last week was a Long Week... and the story is pretty funny, so I thought I'd share it. However, be forewarned... this story is not for those with a weak stomach. :)

Last weekend I was in St. Louis on my first NFJS conference of the year. I called my wife Sunday morning to say good morning and she was in tears. She had gone to a fund raiser for our daughter's school and caught a stomach bug. She was throwing up all night long. At this point she didn't know if she was going to be sick all day while the kids were awake. I hate it when my wife or kids are sick and I can't be there! Also, our three year old had a fever. Turns out that Debra's stomach was done for the day and things went a little smoother after that.

My flight that evening didn't get me home until after 11 pm. By the time I collected luggage and drove home it was late and I didn't get unpacked and into bed until 1:30 in the morning... but this turns out to be one of the better evenings of my week.

Monday went okay... Debra didn't feel well and was still running a fever, but no-one else had gotten sick, so we thought it was "only" food poisining at this point.

Tuesday... Elisabeth (our 2 year old) was very fussy. In fact, she was up, on and off, until 3 am. She had "horses in her tummy", but she never actually got sick. We're beginning to wonder if Debra had food poisining or caught a stomach bug.

Wednesday comes... today is Debra's birthday and she finally feels human again. We went out to Red Dragon, a Chinese restaurant that we've loved for years, but it only had a location in downtown Raleigh. They've opened a new location a few miles from our house! We're excited, the food is great... it's a good evening!

Finally, the kids are in bed. Debra and I have crashed in front of the television. At 11 pm, just as we were shutting down for the night our seven year old Hannah comes downstairs to announce that she has "sneezed out her rice". I wisely clean up my daughter and send Debra upstairs to investigate the bed. Hannah has thrown up in her sleep, something I've never heard of before, but apparently can actually happen. With her younger sister (Elisabeth) sleeping just a few feet away Hannah appears to have deposited a ~lot~ of Chinese food on the sheets. Ewww! Debra just pulled the sheets off the bed and puts them in the garage. We decide that Debra didn't have food poisining last weekend. Food poisining isn't contaigious.

As a quick aside, Hannah announces several times that she's never going to eat that restaurant again. (sigh) Debra and I have been eating at this restaurant (in it's Raleigh location) longer than Hannah's been alive, but when you've gotten sick after eating a certain food it can ruin it for you for years. We realize that we've probably lost our latest favorite eating spot after a single wonderful meal. Whimper.

Since Debra's been sick and I've been out of town, we're out of the groceries that sick people need, like Gatorade, Sprite, Ginger Ale, and crackers. So, at nearly midnight, I head out to the grocery store.

When I return, I put the groceries in the kitchen, including a cardboard box containing twelve cans of Sprite. It's the type of can that you can put on a shelf in the refrigerator and just grab one can at a time. Debra started to open the box when Hannah called for a trash can in a way that you don't ignore if you like clean carpet... so Debra grabbed the trash can and ran to Hannah.

As Hannah threw up into the trash can I heard a different sound from the kitchen.

Roll-roll-roll-clunk-slpooosh! Roll-roll-roll-clunk-splooosh! Roll-roll-roll-clunk-slpooosh! Roll-roll-roll-clunk-splooosh!

You get the idea. Debra opened the Sprite box slightly more than she intended to and the cans were rolling to the floor, where most of them detonated. I dashed into the kitchen in time to save four.

Out of a twelve pack of sodas, only four were usable. Of the others, four were completely empty and the others were dented beyond opening. Some were leaking, some were not... I just couldn't tell. It was a pile of bubbling might-have-been soda goodness in the middle of the kitchen floor.

So, at some point between midnight and one am, I start mopping up soda from the kitchen floor while Debra sits with Hannah through another round. Soda is sticky on linoleum. It's sticky on cabinents and dish washers too.

Debra and I start doing the math on the timing of Hannah getting sick. We realize that Saturday to Thursday is four days. That means I could get sick on the following Saturday or Sunday. That would put me in the middle of speaking at a conference in Boston. Things are looking grim. I have visions of getting sick on a two hour commuter flight with a single bathroom on it. Not a happy thought.

I finally finish cleaning up, putting groceries away and I go to bed at two am. Debra and Hannah were up until five.

Thursday was a better day. Hannah has a fever, but is feeling better. Debra is feeling great. Even Elisabeth, the tempermental two year old is having a great day. We all got into bed at a decent time. Things were finally looking up.

At 3:27 am, I awake to the breif squeal of a fire alarm. Fortunately, it wakes no-one in the house but me, so I investigate. We have three alarms at the top of the stairs. One is a fire alarm wired to the house electricity, one is battery powered and one is a CO2 alarm. Since I don't know which alarm woke me, I assume that the battery powered unit was just letting us know it's battery was low. I pulled the battery and return to bed.

At 4:07 am, I awake to the same squeal. This time, I unplug the fire alarm that's on house power.

To be fair, we're paranoid about fire alarms and CO2 alarms. We have an additional fire alarm downstairs, one in my office, and another CO2 alarm downstairs. Since only unit is chirping, I felt pretty good about ignoring it. :)

At about 5:15 am, the alarm comes back on and stays on this time. It turns out to be the CO2 alarm at the top of the stairs. It wakes up Debra, but not the girls. I finally realize that pulling the unit apart makes the sound stop. :) Good.

I open a few windows (just in case), but since we don't have a gas stove, our hot water heater and furnace are outside the house, and the gas fireplace doesn't even have a pilot light running, we go back to bed. (The downstairs CO2 unit never alarmed, so we weren't being completely stupid.)

We realize the next day that the replacement battery/CO2 detection unit that we bought on eBay had expired last year. That was probably what caused the problem.

Finally on Friday I was packing my clothes and leaned over Debra while she stood up. Her forehead smacked my face and busted my lip. It was a good one too... bled quite a bit. :) I sit on the sofa for an hour with ice packs so I don't look too goofy for the conference in Boston. :)

It was a long week, but it seems to be behind me, but if you came to the conference in Boston (Danvers, technically), and I seemed a little tired, or had trouble remembering your name, it wasn't you.

I just had a long week.


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

Fri, 03 Mar 2006

Keystrokes Per Concept: Now That's a Metric!

Ted Neward's blog has an interesting entry on evaluating a language based on the number of keystrokes (not even lines) that it takes you to express a concept. This should, naturally, lead to a more productive team, since more of the details are wrapped up the well-tested language libraries, not code that you've re-written.

He includes code examples for Java, C-Sharp, Ruby, and Scala. (Scala is a language that Ted's been looking at lately.)

It's a very cool read... and pretty cool how short the Ruby and Scala are for such a simple concept. :)

Here's the link.

btw, here's the Scala reactions followup blog entry.


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

Thu, 02 Mar 2006

Mock Client Testing as a Product Feature

Lecando's Haven product is a continuous integration and continuous testing system; it runs your tests in parallel across many different machines. This looks great for anyone who wants commercial support for their continuous integration systems as well as massively parallel testing. It looks like a great idea, and like many great products, it came out of their own need for the product.

But my favorite part was on the features page. I liked the part that said:

Haven provides an easy to use toolkit for writing tests for web applications, only limited technical knowledge is needed. Since the toolkit is JUnit based it can easily be extended to provide customized types of testing if needed.

Can easily be used to create mock client tests.

That's right folks. Enabling Mock Client Testing is now a product feature. This is a trend I like!


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

I'm Not Dead Yet! JRuby Lives

Not only is it still alive, it's getting better! For those of you wanting to run Rails in a Java runtime, do not despair. Charles Nutter posted today with a JRuby Progress Updates: JRuby on Rails, IRB, and the Future.

It's a great read on several different levels. If you are porting any of the scripting languages to Java, this is a good read. I find it interesting to read about what particular operations were moved from Ruby to C and why it's so hard to duplicate some of those operations in Java.

Having a viable Ruby runtime inside of the Java VM opens up many interesting possibilities and also brings together two of the most vibrant development communities today. Here's hoping!



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

Tue, 28 Feb 2006

Author's Blogs on Amazon

If you haven't seen it, Amazon Connect is a new feature on Amazon that just recently went live. It's author's blogs hosted on the Amazon book page. It's a pretty neat idea, but I doubt that most of the people who are reading this would need to visit the Amazon page to track me down. :)

On the other hand, there are a lot of people who don't know what a blog is but would read a book page for reviews or a writer's comments. The Amazon Connect idea might open up author's blogs to a whole new audience. It also pushes out the blogs to the Amazon home page of people who've bought your book. It's a new way to keep in touch with your audience.

I've put a few posts up on the Ship It! A Practical Guide to Successful Software Projects page. Some of it is reposted content from this blog, but I'm starting to add new posts that are only for my Amazon page. I'm curious to see how it will turn out.


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

Mon, 27 Feb 2006

Apple's Developer Connection Posts a Ruby on Rails Tutorial

Courtesy of Digg.com, here's a tutorial on Apple's Developer Connection titled Using Ruby on Rails for Web Development on Mac OS X.

This Rails thing is getting more and more mainstream every day! ;) I think it might make it.



btw, it seems that Mike Clark is the author.

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

Fri, 24 Feb 2006

Diving Deep: Introducing a New Technology or Language

Bruno Melloni passed on his experiences introducing a team to a new language or technology. It's good enough to pass on, so here you go.

So, with Bruno's permission...

Thank you! Ship It! rocks.

For the last 15 years I have been following the principles you describe in the Ship It! book. And for 15 years people told me that I was nuts, even though they brought me success after success in my projects. It is unbelievably satisfying seeing those principles finally recognized in print. Thank you!

I'd also like to suggest an extension to Tracer Bullet development that I used in 1996 when I had to rewrite a system that had no documentation, no original source code, no past experts... just the system's output as a model, the target language was Java, I was the only developer that knew Java and all of the other team members only knew C++:

After the skeleton, interfaces and stubs are created, do a code deep dive - from UI to database - on a small slice of the application. Or in other words, write the full and final code of that slice before even bringing in the rest of the team (or done by a team with lots of code reviews to optimize the result).

A deep dive, when done with readability in mind serves as a template for junior and new developers. As a consequence those C++ developers were fully productive writing Java code within a week! And because method names, variables, and even logic were chosen to make them easy to understand, we were even able to show code to the business experts who could then validate our assumptions.

The net result was that in 6 months we successfully duplicated a system that nobody knew how it worked, made it run 10 times faster (yes, on interpreted Java!), discovered bad data that had not been detected in years and cleaned it up, and the company went from outsourcing 80% work to insourcing lots of work because of the new excess capacity. As far as I know, the system is still happily in operation after 10 years... All of this thanks to the Tracer Bullet and Deep Dive combination of approaches.

Bruno Melloni

Thanks Bruno! I like the idea of Diving Deep. I suspect many others will too!

By the way, this note came to me via the Pragmatic Publishers's feedback page about Ship It! Feel free to pass on your experiences via that form or on the Ship It Mailing List.



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

Thu, 23 Feb 2006

Ruby is so cool

I'm going through Dave and David's Rails book and parts of it just amaze me. How much code would it take in your language of choice to do the following:

  1. Pull all the data from a database table
  2. Filter out the data by some value on a single column
  3. Sort the data

Granted, this isn't rocket science. Any beginner programmer should be able to do this. But in the Rails book, it's four lines of code... and it could be one. It's written on four lines to be readable.

This is a routine that returns all the items that can be sold now. Can you read it?

def self.salable_items
   find (:all,
         :conditions  => "date_available <= now()",
         :order       => "date_available desc")
I know, some of the magic is ActiveRecord, the Ruby OR layer... but in my mind I'm running through all the JDBC driver trappings, the selects, the sorting. Maybe if I'd tinkered with Hibernate, I'd know a four line way to do this in Java. Maybe....


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

Tue, 21 Feb 2006

Rails Videos and Tutorials

I've had two people today express an interest in Rails and I've ended up pointing them both at the Rails video page, and that's my limit. Once I've sent information to two people in a day, it gets posted here. :)

The page starts with Show, don't tell: Seing is believing" and then has links to several very impressive screencasts of people creating Rails applications while you watch.

This type of productivity isn't staged. I've seen Dave Thomas (the pragmatic guy, not the hamburger guy) do this at a software conference and it's truly mind boggling to watch. I'll grant you that Dave isn't the typical coder. He's extremely talented and knowledgable, but it's still amazing what he can do with Rails.

There are other videos at the bottom of the page and lots of other resources on the site. The Get Better page has links to books, tutorials, and online resources. Tons of information.

If you're digging into Rails, you need to be very familiar with the site. It has all you need to learn about Rails and then (if you decide to pursue it), the tools to get you rolling are also available.

By the way, if you know of some other storehouses of Rails videos, let me know and I'll post them. There's something about a webcast that feels more accessible to many people. Many who won't read an article or a tutorial will watch a video. Funny isn't it? But if it works... do it! :)



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

A Dull Work Environment Damages Your Brain

This is a great bit from the Creating Passionate Users site. It deals with recent discoveries that show new input and different experiences can actually help to improve your brain. It also covers how a lack of new experiences can wither your brain! Use it or lose it isn't just for arm muscles.

Here are some great quotes from Brain Death By Dull Cubicle:

You always knew that dull, boring cubicles could suck the joy out of work, but now there's evidence that they can change your brain. Not mentally or emotionally, no, we're talking physical structural changes. You could almost say, "Dull, lifeless work environments cause brain damage."


"Eight years after Gould defied the dogma of her field and proved that the primate brain creates new cells, she has gone on to demonstrate that the structure of the brain is incredibly influenced by one's surroundings."

One of the most interesting (and, in hindsight, "doh!") discoveries was that one of the main reasons researchers kept finding NO evidence of new neuron development in their test primates is because they kept them in an environment which shut that process down. In other words, it was the caged-living that stopped the neurogenesis process. By giving her animals a rich, natural enviornment, Gould "flipped the switch" back on, allowing their brains to work normally, and sure enough--the happier, more stimulated animals showed a DRAMATIC increase in neurogenesis as well as dendrite density.


"Complex surroundings create a complex brain."

What can you do this week to exercise your brain? It sounds like travel literally expands your mind. Might be time for a short day trip... or maybe a new video game? When's the last time you picked up crayons and drew a picture?

I'm not trying to limit your selection, but rather I'm trying to stir your creative juices. Sure, it's a neat article. Now act on it. :) Try to pick two new things to try this week. Pick something that will work your brain in a different way.

For myself, I'm digging in deep on Rails. I'm about to order a Mac laptop so I'll have to learn OS X. Heck, you could go cheap put a new Linux distribution on some old hardware. Learn Free BSD.

These are longer term changes though. I recently picked up a set of cheap colored pencils and a pad of drawing paper. When I write an article or start designing software, I'm starting to use mind maps. These tools aren't magic, but they involve a different experience for my head.

How about some new art in your office or cube? New music? Learn to play music?

What will you do this week to expand your mind and improve your brain?


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

Mon, 20 Feb 2006

Even a thief takes ten years to learn his trade

Another gem from Esther Derby's blog.

Jerry Weinberg on the AYE blog

From the post:

Jerry Weinberg finds wisdom in Japanese proverbs in this post on the AYE blog

If I were to give advice to a young professional starting out in the world, I could do no better than quote three Japanese proverbs:

We learn little from victory, much from defeat.

So, do not think in terms of Win or Lose, because you cannot always win. Think instead of Learn, for Win or Lose, you can always learn.

Even a thief takes ten years to learn his trade.

There is no quick road to success. Be prepared to persist through some hard times, and you will outlast your competitors who burn themselves out with too quick a start.

If you believe everything you read, better not read.

Take my books, and the books of others, as if they were tempting meals. Taste everything, but swallow only what tastes right to you.

Good stuff!


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

Continuous Testing Conference

Jeffery Fredrick and Paul Julius, both CruiseControl committers, are hosting a weekend conference that will focus on Continuous Integration and continuous testing.

I can't attend because I'll be speaking at another conference that weekend but I thought I'd post the information here to pass the word along. It will be a chance to spend time with some very smart people who are doing a lot of the same types of testing that I've found very effective.

Invitation to Continuous Integration and Testing Soiree

It will be held in Chicago on April 7th and 8th.


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

Sun, 19 Feb 2006

Public Speaking and LIPs

Since we finished writing Ship It! A Practical Guide to Successful Software Projects I've gotten a number of opportunities for public speaking. Since, like most folks with a technical bent, I've not been crazy about giving presentations, I needed some work.

After putting in a lot of work, I'd like to think I've gotten pretty decent. I'm realizing that, just like writing software, there are some basic principals that you can follow to improve your craft. And, just like development, we all have different areas we need to improve.

As I practice and get feedback from live talks, I've isolated three areas that I need to be remember. A great way to remember something is to write about it. Another great way is to put it on your blog so that people who come to hear me talk know what my weak points are. This way I'll have to improve. :)

I formulated an acronym to remind me of the areas that I need to watch the most.

LIP stands for:

The first item is Lock. It's a simple rule. You may not talk to your laptop, your notes, your slides on the big screen, or the back wall. You aren't allowed to talk unless you have eye contact. If you don't have eye contact, just pause, take a breath, and scan the room. (Note that "pause" is item three!)

The benefits here are huge.

Eye contact lets you connect with a person and have a conversation. This isn't the dreaded "public speaking" torture, but just talking to someone. I've been shocked at how much of the nerves and shakiness just goes away when I talk to a person in the audience.

But don't talk to just one person. If you did that you'd leave out the rest of the audience. Move from person to person and deliver a sentence or a thought. If it's a list share it. One major point per person. This keeps you moving across the room, includes people, keeping them awake and engaged, and forces you to pause between thoughts.

What if no-one will look at you? Well, if they're reading your slides, wait for them to finish. And next time, put less text on your slides. Put a few key thoughts on them to remind you... and your audience later. If there's a picture on the slide, give them time to absorb it. Don't just "run past them" and start talking.

If you don't have a set of eyes locked, you shouldn't be talking.

The second point is Intonation. I'm told I have a very soft, comforting speaking voice. Apparently I'd make a great air traffic controller, but not the best speaker. "Aircraft 356, please come to 35,000 feet immediately or you'll hit that mountain. Have a nice day!"

I have to focus on taking my voice higher, adding inflection, going loud and soft. Every class or review session I've been in has mentioned this.

I'm slowing learning that what sounds outrageously loud and "over the top" to me sounds fine to my audience. This seems to be true for most people.

If you have a chance, practice this one a few friends. See how loud you can get for an empty room before your audience thinks you're getting too loud. Over emphasize every vocal intonation. When I do this I always feel like I'm shouting and my audience is telling me I finally sound strong.

The last item is the awesome Pause. So many speakers just don't pause. Many times we throw out a great point or show an awesome slide, then, while the audience is going "Wow!", we keep talking. Instead of letting the audience absorb your hard work, you're dragging them off to the next point.

Waiting for an eye lock will help with you with this one. The Lock and the Pause seem to be tied pretty closely. If you're doing the Lock right, the Pause usually falls into place without much work.

Click a slide. Deliver a point. Then do a three to five second count in your head. This pause will feel like an eternity at first, but you'll get used to it very quickly. And I've never had an audience complain. In fact, people who've heard the same talk more than once have liked the "pause heavy" talks the most.

The Pause gives you time to think as well. When you're on the stage and you bring up a new slide or point the three second pause gives you all the time you need to organize your thoughts.

Too often, when we're doing public speaking, we get faster and more nervous the longer we go. We think we're doing poorly so we try to think faster, to get caught up... instead we start talking even faster to match the rate of our thoughts. It's a bad downward spiral that's ruined a lot of presentations.

Instead of spirally down, deliver a single point (or though, sentence, or slide), then wait. Count to three. Wait for eye contact. Then proceed.

By the time you finish your first talk with this format, you'll find you fall into a rhythm that's very comfortable. I really enjoy giving talks when I remember these points. Of course, there are many other points to remember, but everyone will have a different area they need to remember.

Why is this in a largely technical blog? Because most techies are just flat out dumb when it comes to public speaking. They don't think they need the skills so they don't cultivate them. Then they have to give a presentation and they bomb. Somebody with less technical talent passes them by because they present themselves better.

But you don't give presentations you say? Bull. Failing to recognize it doesn't change it. Here are a few examples.

Maybe you haven't done any of these things, but if you have and you've failed, it may have been your presentation instead of your message.

Don't ignore your own UI. Remember your LIPs.


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

Thu, 16 Feb 2006

The Rails debate makes Digg

There were two great posts on Digg today. One talked about all the problems with Rails and why it wasn't so great. The second post walked through the critique and answered it point by point.

First, it's a good indicator for Rails that both posts made the Digg front page in a single day. Since it's a user voting system, the topic has to be popular to get that kind of traction.

Second, an old proverb says "Always listen to your enemies. They'll tell you things your friends never would." I think having a flat out listing of problems (or failed expectations or misunderstandings or ..) is great. If no one complains loudly, the problems can't be fixed or avoided. Maybe the user's expectations can be changed.

This type of public "discussion" is good for Rails and, more importantly, it's good for us. It helps us to know the system a little better, both the good and the bad.

Anyway, here are the two links.

First the bad: Rails' Ridiculous Restrictions, a Rant (posted anonymously).

Second, the response: Regarding Rails Restrictions (signed)

Read them both. Think for yourselves. See if you can find something about Rails that you didn't know before.

Enjoy! Jared

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

A Rails Configuration Bug: How Ironic!

I started tinkering with Rails again and ran into a problem getting the Rails app talking to the database. I was copying DHH's blog video, so I was sure the Rails code was okay.

I tinkered with the setup long enough to get frustrated, upgrade MySql, add users, etc.

Then, turning to Google for the third or fourth round of searches, I found a gem. This blog entry.

It solved my problem. Which was only fair, since I'm the Jared mentioned in the post as providing the same answer last summer. :) What can I say? That was August. It's February. I've slept since then.

So, to the Rails team... I'm sure this "just works" on your Macs, and I'm getting one soon, but shouldn't the defaults be correct on the most prevalent operating system on the planet? Shouldn't the convention take over if the configuration is absent?

Add the port number to the database.yml file! Please!

Actually, I supposed I should find a page on the Rails web site and see if I can report the problem first... (this page looks like a good starting point) but I wonder how many people gave up after trying to get the database working with Rails after fifteen minutes and didn't discover the gem that is Rails?


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

Sun, 12 Feb 2006

Problems with Test Automation

When I spoke at Adobe last week the title of my talk was It's All About the Platform. The presentation was about how to effectively leverage test automation and continuous integration to validate your platform products. After the talk a former Microsoft employee asked me why I didn't talk more about the problems with test automation.

I think I addressed the concerns at the time, but it's a good question that bears repeating.

First, you can only cover so much in a sixty to ninety minute talk. I already had more material than I could do justice. Trying to present the case for test automation, then continuous integration, then presenting some counter-points... it was beyond the scope of the talk.

Secondly, I've never encountered a shop that wasn't top-heavy on manual testing. In my experience, there aren't many shops abusing automated testing. So I present on topics like this I try to push hard towards automation, not because I think it's all you need, but because I'm trying to restore balance.

If your shop has only manual or only automated tests, you lack balance. You need a good mix of both. In pushing people towards test automation, I'm trying to establish that balance, not wipe out manual testing.

That leads into another good point. Test automation can't replace a skilled interactive tester. It can eliminate a lot of boring, repetitive work. It can keep the basic product rock solid, freeing up the (presumably) smart, creative human to look for another class of problem. You need testers and test automation. Neither stand-alone.

It takes a different sort of mind to do interactive, manual, black box testing than it does to do programming or test automation. Some people take a shot at programming and they just Get It. Other people are the same way when it comes to intelligently probing a program's limits. When your company decides to initiate an automation effort, please don't blindly convert your interactive testers to test automaters. Just because both titles contain the word test doesn't mean they require the same skill set. Some people may overlap the two jobs, but many others will not. If you do a blank convert of an entire department, you'll likely condemn your effort to fail and frustrate some good people along the way.

Remember to provide some structure when you start creating automated tests. A little design and architecture has been known to greatly increase the value of software. ;)

On the other hand, turning a dozen people loose to write automated tests (for the first time in their life) might create some really bad tests. Be sure to adopt a strategy that can guide the team and make sure they are doing the best job they can do. Blitzkrieg Testing is a great starting point for providing that structure.

Test automation is an extremely powerful tool that I rarely see properly utilized. It's not a magic wand or silver bullet, but it's a tool that you can use in your shop everyday.

So, when's the last time you wrote an automated test? When's the last time you wrote one?


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

Thank You Adobe for the Warm Hospitality

I spent some time last week on our west coast. San Jose to be exact. The good folks at Adobe invited me to speak at their QA Summit at the San Jose Convention Center (thanks to Jordan Dea-Mattson and Serena Zhou). It was an eye-opening experience for me. Adobe devotes an entire week to a series of technical conferences each year, and brings together their employees from all over the world, as well as a few external speakers like myself. I'm told Tim O'Reilly spoke earlier in the week... I really hate that I missed that!

Some managers fail to understand the value of getting their people together to talk, share, and learn, but Adobe "gets it." When I gave my keynote on platform validation, the room was packed... there were five to six hundred QA professionals in the room. Then we moved to an adjacent room for a series of round table discussions. Even though I led one of the tables, it was fascinating to watch Adobe employees from Ottawa sharing solutions and ideas with employees from India and Seattle. I answered some questions, but I also listened to a lot of good information being shared.

You have to admire a company that makes such a strategic investment into their employees. Ultimately this investment pays off company-wide. Way to go Adobe!

Does your company do the same for you? Are they as successful as Adobe? Don't you think there might be a correlation?


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

Mon, 06 Feb 2006

JBoss at Work Authors to be Featured at JavaRanch!

JavaRanch is featuring the great book JBoss at Work: A Practical Guide

From time to time they feature a book, host the authors on one of their forums, and give you the chance to drop in a chat, ask questions, and pick the author's brains. JavaRanch hosted Will and me last August for Ship It! and it was a blast. Lots of good questions with lots of people besides us jumping in with great answers.

I wrote a quick review of the book in December. Here's the link. It's a great introduction to the entire Java J2EE stack, from installing a JRE, setting up Ant, using XDoclet, all the way up to coding, deploying and using Web Services.

I consider it a must-read book for anyone in the Java space, but especially anyone trying to learn the area. Java covers a lot of ground these days. This book can help you come up to speed.

From the announcement:

We are thrilled to have Tom Marrs and Scott Davis on the ranch to promote their new book, "JBoss At Work". The promotion will be held in the JBoss forum which can be found here.

Participate in this week's giveaway by asking Tom and Scott a question or two and you may win a copy of their book!

The giveaway starts on Tuesday, February 7th.

The drawing will be held on Friday, February 10th.

Visit our Book Promotion page to see how to win and to see the other exciting promotions coming up.

The Book Promotion page


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

Sun, 05 Feb 2006

The Rule of Three

How many points can you pack into your presentation to the boss before he or she starts forgetting them? Good question. If you provide a 20 point plan for improving the software process, odds are you'll sound confused and disorganized. Disagree? Read on...

Last year in a communication class my instructor really hammered this point home with two simple questions. Let's see how you do.

First, name the three stooges. Easy, right?

Now, name the seven dwarves.

Convinced? (grin)... In a class of nearly twenty people, no-one could remember all seven... unless you count the guy who worked at Disney when he was in high school.

If you really want people to walk away with all your points, then anytime you pitch or present keep the points brief. Whether you are trying to get a raise or pitch a new project, it matters.

By the way, I saw a good blog entry this evening over on the Mills Wyck blog that reminded me of this point and reminded how important this is and what happens when you don't respect the rule of three.


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

Mon, 30 Jan 2006

I Love My Job.... I Love My Job...

I got this via email today. It's an urban legend of questionable authenticity, but it's funny, so here you go anyway...

This is even funnier when you realize it's real! Next time you have a bad day at work...think of this guy...

Rob is a commercial saturation diver for Global Divers in Louisiana. He performs underwater repairs on offshore drilling rigs. Below is an E-mail he sent to his sister. She then sent it to radio station 103.2 on FM dial in Ft. Wayne, Indiana, who was sponsoring a worst job experience contest. Needless to say, she won.

Hi Sue,

Just another note from your bottom-dwelling brother. Last week I had a bad day at the office. I know you've been feeling down lately at work, so I thought I would share my dilemma with you to make you realize it's not so bad after all.

Before I can tell you what happened to me, I first must bore you with a few technicalities of my job.

As you know, my office lies at the bottom of the sea. I wear a suit to the office. It's a wetsuit. This time of year the water is quite cool.

So what we do to keep warm is this: We have a diesel powered industrial water heater. This $20,000 piece of equipment sucks the water out of the sea. It heats it to a delightful temperature. It then pumps it down to the diver through a garden hose, which is taped to the air hose.

Now this sounds like a darn good plan, and I've used it several times with no complaints.

What I do, when I get to the bottom and start working, is take the hose and stuff it down the back of my wetsuit. This floods my whole suit with warm water. It's like working in a Jacuzzi.

Everything was going well until all of a sudden, my butt started to itch. So, of course, I scratched it. This only made things worse.

Within a few seconds my butt started to burn. I pulled the hose out from my back, but the damage was done. In agony I realized what had happened. The hot water machine had sucked up a jellyfish and pumped it into my suit.

Now, since I don't have any hair on my back, the jellyfish couldn't stick to it. However, the crack of my butt was not as fortunate.

When I scratched what I thought was an itch, I was actually grinding the jellyfish into the crack of my butt. I informed the dive supervisor of my dilemma over the communicator. His instructions were unclear due to the fact that he, along with five other divers, were all laughing hysterically.

Needless to say I aborted the dive. I was instructed to make three agonizing in-water decompression stops totaling thirty-five minutes before I could reach the surface to begin my chamber dry decompression. When I arrived at the surface, I was wearing nothing but my brass helmet. As I climbed out of the water, the medic, with tears of laughter running down his face, handed me a tube of cream and told me to rub it on my butt as soon as I got in the chamber. The cream put the fire out, but I couldn't poop for two days because my butt was swollen shut.

So, next time you're having a bad day at work, think about how much worse it would be if you had a jellyfish shoved up your butt.

Now repeat to yourself, "I love my job, I love my job, I love my job".

Enjoy! :)


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

Wed, 11 Jan 2006

William Shatner DVD Club

Be the first to own the hit DVDs as selected by music legend William Shatner! Seriously. http://www.shatnerdvdclub.com

If you remember his brief stint as a singer a few years ago, you'll understand my attempt at a joke. My favorite part of the page is the line "Own the Underground Hits No One Else Has!" I also like the weekly poll in which you can select the Star Trek movie with Shatner's finest performance.

If you're a huge Shatner fan, you'll love this opportunity to own hand-picked DVDs for about four dollars each. And who knows, they might be good. Regardless of whether or not you sign up, the site is quite entertaining. :) This was just too good not to pass along.



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

Mon, 09 Jan 2006

Physical Feedback at Microsoft

As a follow-up to my early blog entry on Physical Build Notifications with Continuous Integration, I'd like to pass on another jewel.

John Brown sent me a link to a video titled Microsoft's We Share Your Pain (WSYP). It's a great program that could make a real difference in product quality in many different companies. I wonder if they'll license the system?

It's nice to know that all those error reports we send in are actually put to good use!



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

Observations on Corporate Culture and Agile Methods Adoption/Adaptation

Esther Derby had a great blog entry today on various corporate cultures and how they advance or impede agile software development. It's a very well-written bit.

Observations on Corporate Culture and Agile Methods Adoption/Adaptation

I see myself as a mix between Achievement and Relationship and bumped heads recently with someone firmly in the Bureaucratic camp. It's amazing how much easier it is to see the other person's point of view when understand how they view the world.



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

How to Write Really Bad Code

A humorous look at writing code that no one else can understand. This is a great way to start the week ~and~ remind you of a few practices that you hadn't thought of recently.


How To Write Unmaintainable Code

Here's one of my favorites so far...

Thesaurus Surrogatisation

To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean "write to a file", "put ink on paper" and "display on the screen"). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.

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

Wed, 04 Jan 2006

Physical Build Notifications with Continuous Integration

David Starr wrote one of the best defenses of, ahem, proactive CI techniques that I've ever seen. It's a must-read for any Continuous Integration aficionado.

Physical Build Notifications

If you don't laugh out loud, read it again. You missed something. ;) Enjoy!


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

Tue, 03 Jan 2006

Dual core laptops are imminent, Apple and otherwise

In a previous blog entry I speculated on the possibility of Apple announcing dual core laptops at MacWorld (next week).

Here are a few more rumors and a little information slipped in. :)

Intel is now shipping Yonah chips. There is one single core version (T1300) but the rest are dual-core (T2600, T2500, T2400 and T2300). See The Register for a good write up.

Next, Acer has a dual core laptop in the wings and it looks VERY NICE. A 2 gigahertz dual core CPU, 2 gigs of RAM, and, get this, 512 meg of ram on the video card!! I'm surprised the disk drive in only 120 gig at 5400 rpm. That's a slow drive... but with 2 gigs of RAM, you cache everything anyway. Check it out on Notebook Review.

NEC has announced a dual-core laptop, but the release doesn't seem like it'll be here until second quarter.

Another dual-core is allegedly available from Widow PC, but it's a monster laptop with a base price around $3,500 and is designed as a gaming machine, not a mass-market, lightweight laptop.

Be sure to visit OSx86.org, the article that got me rolling tonight.

It seems that the dreams of countless geeks, to have dual CPUs in their laptop will be a reality. I realize it's not quite the same of a full-blown dual CPU for some memory intensive tasks. But, in my experience, my wife's dual core AMD 3800+ chip holds it own against my dual Opterons system. It's just as response in every way. I think this will redefine the multiprocessor experience for all the people who insist it doesn't make things any faster if the application is still threaded (as most apps are). They'll realize the rest of the OS and all their background apps, like anti-virus scanners, are on that second processor, leaving you work in a pure, clean, and most importantly, responsive environment.

My prediction for 2006? As long as they are priced reasonably, they'll fly off the shelves.



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

Windows exploit fix

Not everyone has heard about the Windows exploit making the rounds. To summarize, if you view a web page with one of these images, you can be infected.

Yes, it's that bad. And the infection means a remote hacker can take over your machine. Apparently rootkits have been installed with this method via advertising banner images. So even a trusted site that serves up banner ads from another site can infect your box.

Here's the quick fix:

  1. Click on the Start button
  2. Click on Run...
  3. Type regsvr32 /u shimgvw.dll
  4. Click OK

This disables the DLL that's being exploited. You lose the ability to see thumbnail previews on your system until you reload the DLL. To reload the DLL, just type:

regsvr32 shimgvw.dll

This exploit is a bad one. I'd suggest you "patch" your boxes this way until Microsoft has a fix released.



Matthew Bass sent me a note about a patch for the exploit. If you'd prefer to use it, you'll find it at GRC along with lots of good information about the situation.

Thanks Matt!


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

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.


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.


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!


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.


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