Not having email access for most of a morning was good for me. I did a little office tidying, got caught up on some blog reading, and finally got around to a task I promised to do a long time ago.

When I moved older Ruminations from my qualitytree.com site to here some months ago, I skipped a few articles. Mostly I skipped things that were out of date or that I felt, in retrospect, were too lame to repost. But some of the posts were neither out of date nor lame, just difficult to move over.

One of those, “Flush Specific Stack Fiercely” involved an old Perl script that I just didn’t want to port over to the new site. Why would a blog post involve a Perl script? Because the Perl script illustrated how to generate random test scripts using nouns and verbs.

My colleague Ken Pugh asked me to put the article back up weeks ago. And I told him “soon.” My definition of “soon” may be questionable, but Ken finally got his wish. You can find the article, along with the random scenario generator re-implemented in JavaScript, here. Enjoy.

I’ve been on the road and over-dosing on work lately, so this last holiday weekend I took a rare break from my email.  Three blissful days of connecting with humans (mostly family) in realspace.

Turns out, the spammers did not follow my lead.  They’ve been extremely active.  And once again, one or more of them used qualitytree.com in the return address (e.g. “randomaddresshere@qualitytree.com”).  The result: as we speak, my email client is pulling down thousands of bounce messages to the tune of 37Mb worth of “I’m sorry to have to inform you that your message could not be delivered to one or more recipients.”

My email client thinks it will be done in 3 hours.  It will then take me quite a while longer to dig out of the mess.  Yuck.  And that means that if you are waiting on email from me, it will be a while.

This also means that I need to spend some time figuring out a better email management strategy.  And that’s not quite as simple as it sounds for a variety of reasons related to how I manage email aliases and the options available with my current ISP.

Oh joy.

Ironically, a friend was just telling me how his 15 year old daughter hardly uses email at all.  She uses IM & Facebook instead.  The only emails she gets are from her parents.  Apparently email is so 1990s or something.

I’ve been saying for a long time that Open Source testing tools are our future. It seems at least one test tool vendor agrees with me.

I recently had the opportunity to speak with Rafi Benami of RadView. In April this year, Radview, long a vendor in the performance and testing tool industry, announced that they’re joining the open source revolution: they released their WebLOAD product under GNU General Public License (GPL). You can find it online at SourceForge.

They still offer a commercial enterprise class version of WebLOAD, “WebLOAD Professional.” The professional edition contributes to the company’s revenue stream, and also enables the company to serve a broader set of customers including those who need full support and services, or are still skittish about open source.

Of course, RadView isn’t the first company to adopt an Open Source business model. But they’re the first established, commercial, software testing tool vendor to do so that I am aware of. (By the way, if you know of other established commercial software test tool vendors who have gone Open Source, drop me a line in the comments.)

Interestingly, Rafi reported that the hardest part about open sourcing WebLOAD was making the decision to do so. Once the decision was made, the rest was just a matter of bundling up the product in a way that would work for the open source community.

But the decision? That was hard, he said. They had to figure out how RadView could offer their product for free and still make money.

I can only imagine some of the internal discussions that must have taken place. Rafi, being very professional, didn’t share the details of those confidential internal meetings. But I can still imagine the conversation:

So why open source? As Rafi explained it, RadView chose to open source WebLOAD to:

1. Reconnect with the professional testing community.
2. Leverage the power of the community to improve the offering. Or, as Rafi put it: “We contribute to the community; and the community contributes to us.” It’s a virtuous cycle.

And in order to foster that community spirit, RadView has created a WebLOAD community site.
As hard as the decision must have been, I think they’re already seeing the benefits. Rafi mentioned that RadView saw a lot of traffic come through their booth at STAREast. And many of the people who stopped by did so to express their admiration for the decision to open source WebLOAD, and also share horror stories of over-priced shelfware from competitors.

In short, RadView wants to build software that practitioners like, that they use, and that they have a stake in. Imagine that. A vendor that would rather sell their tools in the test lab than on the golf course. A vendor listening to the community of practitioners.

Go RadView! Hope your competitors are watching…

I just got back from CITCON where I met an amazing group of incredibly cool people.

At dinner after the conference, a group of us compared “First Programming Experiences.” Me, I wrote my first lines of code in BASIC on a trash-80 when I was in 8th grade. The guy sitting to my right, Zach, wrote his first code on a Commodore 64. The guy across the table, Matt, wrote his first lines of code in HTML on a Windows laptop when he was something like 9. That should you an idea of our relative ages.

Matt learned to program in an entirely different era than Zach and me. Back when Zach and I were learning to program, we couldn’t just Google for an answer. We couldn’t order a tech book from Amazon. Wikipedia wasn’t an option. We couldn’t even post our question to a news group. (If we’d happened to have tech savvy parents, we might, maybe have had access to a BBS. But neither of us were so lucky.) We could ask the people around us for ideas answers. But if you happened to be the only geek with one of those early personal computers among your circle of friends, the chance of getting an answer was pretty slim.

In telling us the story of how he learned to code, Zach lamented: “The one thing I could never figure out was how to do a raster interrupt.”

It occurred to me that with about 30 people assembled, many of them geeks about our age, surely one of them knew how to do raster interrupts on a Commodore 64. “Let’s try a social experiment,” I suggested. “Write your question down and we’ll send it around the group to see if anyone knows the answer.” So Zach wrote his question on a cocktail napkin (the only thing handy). And we sent it around.

Most people just shook their heads and laughed. But one person hollered back down the table, “Who wants to know how to do a raster interrupt on a Commodore 64?”

“I do,” Zach hollered back.

“Well I don’t remember the exact syntax,” came the reply. “But you access the upper level memory registers. There wasn’t much documentation on them at the time, so figuring out the right numbers was a bear.”

Behold the power of community. Put your questions out there, and someone in the community will have an answer.

(Oh, and for the curious, Google also does a good job of finding the answer: address 53274 ($D01A).)