I’m ambivalent about the value of blogs. Not the value of communication, certainly not the value of writing. I write everyday, and I write everything. Supervisors and colleagues notice (and query and tease). My partner says I make more notes than anyone else he’s ever known. I’ve written since I was 12 years old; it’s how I know what I think. Writing objectifies my experience, allowing me more, better perspective. And writing serves the function of best friend without having to bore my actual best friend with the tedious but necessary side trips between ordinary Monday curmudgeonlyness, and brilliance. Which is another way of saying – most of what I write, most of what I think, is crap. Crap processed becomes interesting, sometimes. That processing, for me, takes place in draft after draft, over years and years, that never gets seen. Consequently, most of my ideas never have a life outside my mind at all and that’s a good thing.

Agile development processes grow in popularity both within companies and also within successful open source projects.  Agile places a priority on customer feedback and better accommodates the manner in which engineers naturally work.  But what about quality assurance in an agile world?  A few edicts of agile development have a large impact on the way quality assurance operates:

   1. Agile requires quicker and smaller increment releases that steers away from the long QA cycles required at the end of a waterfall process.
   2. Agile requires instant feedback to the development team about the most recent enhancements or fixes.  Development should not move to other tasks until the quality of the previous task is assured.
   3. Agile emphasizes customer feedback.  Customers should play a large role in the quality process and should see the product at least once per iteration.

The quicker and smaller incremental releases and the need for instant feedback to the development team will present the largest challenge to a traditional QA team.  A traditional QA team would demand full-regression testing every time functionality is changed that could impact the system.  The agile process usually cannot afford a week of testing for every iteration.  Developers need instant feedback, and should not continue on new tasks until testing is complete.  For all but trivial software application this quick testing feedback cycle can only be accomplished with automated testing.

Certainly a project can remain agile without automation; if the project has enough dedicated testers to perform full-regression testing as each developer assignment is finished.  For most projects this impractical: ten QA testers waiting for each engineer to finish will usually not be affordable.

Given that automation is almost a certainty in an agile environment, what is the best approach to automation of testing?  Usually the first line of defense is unit tests created by engineers.  A unit test will force engineers to prove that new code works properly and will also create a development atmosphere where code is better designed in order to allow it to be more testable.  Even with unit tests in place, when all components are placed together, the resulting integration may fail.

You've probably seen the big news in the Open Source world already. Oracle is hijacking Red Hat's Linux distribution and will ship a version named Unbreakable Linux, undercutting Red Hat's support pricing. Thanks for doing all the work Red Hat, we'll take it from here. To me, it appears that Oracle cares nothing about the open source community. The open source community thus far has thrived using a culture of collaboration and friendly competition (competition of alternative options). Oracle is getting into open source with the mentality of cut-throat competition. They previously bought the company behind the transaction engine that MySQL used, forcing many to reevaluate if they could rely on MySQL features owned by another proprietary database company. And the problem I see is not that they are going to offer a competitive Linux distribution at a lower price point. It's that they don't even have the decency to build their own competing distribution like Novell/SUSE.

Perl is a must have tool on every system. I use it almost every day to manipulate data from command lines and to write small utility scripts. I made the jump to Ruby a number of years ago and concede to the readability and cleanliness of it's object oriented language over Perl. Anything that I can do in Perl I can also do in Ruby. That said, I still use Perl because of the huge repository I have of legacy Perl scripts and the sheer number of scripts available on the net. Ruby will ( in my opinion ) surpass Perl in this regard, but until that day comes, I will still be writing some Perl.

...go together like peas and carrots.

We recently announced indemnification coverage for intellectual property infringement on each of the more than 160 open source products included in the OpenLogic Certified Library.  While most media coverage of our announcement has been overwhelmingly positive, a few have questioned the relevance of indemnification. What these individuals don’t understand is that enterprises specifically ask us for indemnification coverage.  In fact, eight out of every ten sales opportunities in which we’re involved require indemnification at some level to move ahead.

They've proven again that hard work, not talent is the secret to success. Secrets of greatness: Practice and hard work bring success - October 30, 2006

The creators of "Micro Helicopters" are pushing the technology envelope by integrating lightweight, powerful batteries and motors, carbon fiber materials, and miniature electronics into tiny controlled flying machines.

It's the 'HP way' or the highway | CNET News.com

If you believe that people are more design-conscious lately, it's not a great leap to also believe they look for it everywhere - not just in the consumer electronics they buy. Don Norman wrote one of the best books on design, The Design of Everyday Things, and after you read it, you'll be ruined. For better or worse, you won't look at your world in the same way. I highly recommend reading the book, but you've been forewarned that you might be dissatisfied with life as you know it afterwards.

Wow, this Japanese employee is getting some of the royalties from a product that uses a patent he developed ... while working at the company.   Hitachi pays out in patent dispute with employee | Channel Register

Up until a few days ago, I saw no reasons to change the shell prompt on my systems. It all looked a little different, but I was ok with it. Well, that changed last night while I attended a presentation at the Boulder-Denver Ruby Users Group. Ara, the presenter, had modified his prompt to show whether the previous command had succeeded or not. I decided to do the same to my systems. I came up with the following code added to my .bash_profile (with a lot of help from the Bash Prompt Howto) :

It's been a big month for open source - quite a few companies have announced open source plans, and I'm not just talking about using more open source software but actually open sourcing software, data or APIs.

Wal-Mart's latest exploit in the blogging world has given them a lot of grief.  Here's what I understand happened:

IT Manager's Journal has an interesting article on open source and women, Opening doors to open source for women. (It's a topic I've blogged about before, Women (or lack thereof) in Computer Science, a problem or not?)

It seems an eternity ago. I hadn't begun kindergarden yet. We were living in a fairly large (or it seemed at the time) development complex in Laval, near Montreal. I still had training wheels on my bicycle. Many of my friends were rid of their training wheels. I wanted be just like them, riding a bicycle without the training wheels. I did convince a friend to let me try to ride his bike, and after a few false starts I was riding his bike. After a few days, my mom did notice that I was doing ok, and soon the training wheels came off.

There are some corners of the open source constellation and pockets of innovation you might not be aware of....some totally wicked stuff that will blow your lid when you see it and when you think about the trajectory these harbingers represent.

For the past six weeks I had the unique experience of not having to check my calendar daily (or multiple times a day.)  It turned out not to be a good experience for me - I forgot the few things that were in my calendar because I never checked it.  So last week, when I was trying to figure out my schedule (vacation vs work vs Frank's hunting trips vs ...), I was looking for a calendar of all the open source events.  (I wanted to make sure I didn't schedule any vacations over my favorite conferences. :)  I couldn't find one, so I created one on Google Calendar, the Open Source Calendar.  You can subscribe to it and you can send events (invite it) if you know of any other open source events.  Enjoy!

I'm back at work and happy to be here.  A lot is happening both at OpenLogic and in the world of open source.  At OpenLogic the first thing I noticed is that we've hired and we're hiring (in particular we are hiring software engineers, sales engineers and support engineers.)  As soon as I finished making sure I knew everybody's name, the next thing I noticed is that we've got lots of new customers and lots more in the pipeline!  Business is good.  Oh, and our blogging software and look and feel changed.  Do you like our new look?  (I do!)

Open source businesses are different than traditional software companies in many ways, but how much do the differences matter from a management perspective?

Hi all, I'm new to the blogosphere, although not a new blogger. I used to write blogs way back when they were called op-ed back in my salad days. So, I may be a little rusty, but here goes.

Matt Asay’s blog always gets me thinking.  One comment I really love comes from this entry: “Open source is a better model for customers. Period.”

Monitoring Your Network Devices the Open Source Way