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.

You might suspect an overzealous critical faculty, that surely I have more worthwhile ideas than make it past my trashcan. You might be right (that pesky editor). But, in a world full of solid thinkers, solid writers, I’m loathe to add something mediocre to the mix. You don't need to be particularly interested in information trends to note the terrible volume that needs to be digested in order to stay current in our varied roles. There’s too much coming from “official” sources for to keep track; honestly, I’m overwhelmed by the idea of keeping up with blogs as well. I resist: I don’t have time. Not to weed through all that each person that can hit send might have to say about It, whatever it is.

Now, in this argument with myself (and with my colleagues, no mean writers themselves), I go right to the myriad articles and news stories that have shown up recently on how blogging challenges conventional notions of journalism, the control of repressive, censoring governments and how corporate blogs provide insight into a corporation’s culture (This article, published by Intercom, is available to members only. E-mail me if you’re interested and I will obtain permission to give you a copy.). I’m sure the topic has arisen elsewhere and I’ve missed it.

And those are all good things. I especially like the idea of a less closed commercial publishing world, particularly right now when I’ve got to truck back into Denver to return a copy of a book I found unreadable despite the hype. I’m frustrated and suspicious when badly written books that happen to be written by fashionable critics get a lot of good press. I wonder if the critical community – yes, those same that I rely on to do some information filtering for me – are pandering, afraid getting the treatment Jonathon Franzen recently got. Maybe blogging, like self-publishing, provides a way for ambitious thinkers with interesting ideas to make it past Them and become available to Us.

But I’m not sure. This is only draft three, I’ll let you know where I get with these thoughts in a year. Or two. In the meantime, I’ve learned to use this technology. Check that off my list. Whew.

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.

Automated functional tests are the next line of defense in assuring quality and providing quick feedback to the developers.  It is my opinion that functional tests should be added as new features are completed, but in most case not added until the customer has approved of the latest features. Once fully automated unit tests and functional tests are in place, full-regression testing becomes turn-key.  If full regression testing cannot be automatic and quick, then the project may not fit into the agile paradigm.

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.

I've never really been a big fan of Oracle software myself, mostly because of the big monolithic lump that they ship. It's not exactly a light solution. I've also always found their claims of having the most used application server a bit dubious considering they seem to count every cd they ship whether someone uses the app server or not.

I'm sure they'll get some traction in the corporate world. There is still a great divide between the corporate open source circles and the technical open source community. Companies will be willing to lump their Linux support in with that giant Oracle contract that they already have. It will be interesting to see how the technical community reacts to this news though. I don't think the community traditionally supports this kind of behavior. I think we'd all be better off if we could foster more cooperation between corporate and community groups.

One thing I find very ironic is that Red Hat just purchased the JBoss Group, which made waves by proclaiming they owned open source by buying up projects such as Hibernate and listing (Apache) Tomcat as one of their projects on their website. I've heard that Oracle has been making similar proclamations that they wanted to own open source as well. No wonder they were trying to buy JBoss before.

Perhaps some good will come of this. There are many companies that are dumping their products into the OSS space. Some are trying to give new life to an uncompetitive product. Others are "donating" code they don't want to maintain into groups such as the Eclipse Foundation to try to get publicity. Then there are companies open sourcing projects that truly add value to the whole community. This creates so much noise out there that you sometimes have to look deep to find the gems that are available. Hopefully this event will make other companies think long and hard about why they are considering open sourcing their projects so that both the company and the community benefit from the contributions.

And in the end, a little disruption to force companies to improve can be good thing. Just watch out for those sharks in the pool.

BTW, CentOS has been producing a non-Red Hat branded version of RHEL for a long time making the core features of RHEL available to everyone (This is great for product testing). I wonder if Oracle has poached some of the CentOS developers or if they are launching this initiative with an internal team.

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.

Even more recently I have been writing a lot of Groovy code. Groovy is a great Java scripting language that has access to the entire Java API. It is incredibly useful language and I highly recommend giving it a try. 

All that said, lets get on to the subject at hand.. Transportable Perl.  Ok, what the heck does that mean? Perl scripts are generally transportable from system to system and can even, within some limits, move from OS to OS. What I am referring to, is the ability to move the Perl executable from one place to another on your system without recompiling Perl. Why would you want to do this? Well, several reasons spring to mind. Out of space on a primary disk. Disk restructuring. You work for a company that delivers OSS content to the desktop, and you want to be able to install Perl anywhere the end-user wants to specify, without making them recompile. 

And that, is the exact reason why I have been looking at the issue.

When you compile 'C' projects you can ( and frequently do ) specify the install directory where the build artifacts will reside. [ - - prefix during configure on Unix systems ]  That is very handy. However, lets say you precompile perl to the install directory of c:\toolbox\perl.  Then you bundle that compiled binary and place it on a different computer say in c:\tacklebox\perl.  The Perl interpreter will work. It will run perl scripts and everything will be fine.

Unless….  you want to extend that install of Perl. You just found a cool new module on CPAN, and you want to install it and play with it. Now, you have an issue with that new path. The original path                  ( c:\toolbox\perl ) is compiled into, and configured into that Perl distribution. Even if you have the right tools to compile that module on your windows ( yuck! ) box, it will install it into that old path, rather than the new path you would rather have. 

We need some tool that can fix that inbred old path turning it into the new  path that we really want.  What tool should we use to do that? Perl, of course,  it is a great language to data parsing and replacement.

The first  thing we need to do is find all of the places were that old path is lurking. 

Most module builds will use the Perl module ExtUtils::MakeMaker and Config to generate the Makefile that will be used to install the module. That module creates / uses several files by which it generates the makefile. Those files are the key to moving the Perl install. With just a few one liners you can fix the install path. The first file to work on is in the Perl source, it is config.sh.

We want to reset the "head" of the Perl distribution so an example one liner to do that would be.

perl -p -i.bak -e 's/c:\\toolbox\\perl\\lib/c:\\tacklebox\\perl\\lib/g' config.sh 

Then we would do the same command on the file Config-heavy.pl. ( Found in the lib dir of Perl )

We need to do the same on the Config.pm file, but as we look in it, we see that it uses double slashes rather than singles for referencing directories. ( man, that is a pain in the neck!!) So, we would modify our  one liner to look like this :

 perl -p -i.bak -e 's/c:\\\\toolbox\\\\perl\\\\lib/c:\\\\tacklebox\\\\perl\\lib/g' config.sh

And viola!! you should have a working set of files. There are some gotchas along the way here. If you are using a UNIX style perl distribution, you will have the lib dir under the Perl src directory, you will need to make a copy of that and move it to lib. Also, Windows nmake will look for a config.h file in the src directory that does not exist. It does not have to have anything in it, but does need to be created.

Once you pull down a module, then you can run : perl Makefile.pl.   This should create a correct makefile for the new perl path and allow you to then run nmake, and build the module. nmake install && nmake test should both work ( if present in that particular module ) 

Additionally, the PERLLIB and PERL5LIB environment variables need to be set correctly for the new Perl location. 

The next steps would be to roll the changes into one "Fix" script. ( Creation of the environment variables, conifg.h file, in place edits of the config scripts ) Actually, in my case I have built these changes into the OpenLogic Enterprise software package, such that when a user of our software request an install of Perl, we can install a pre-compiled version of Perl, and then restructure the compiled elements to live anywhere on that users system that they request.

…go together like peas and carrots.

I have read a few articles lately from people discussing and describing productive work environements (see Productive Workspaces and The Joel Test: 12 Steps to Better Code, step #8), and our setup here at OpenLogic does not meet any of the criteria (however, the articles do not specifically address collaboratvie work environments, which is what we have). Regardless of our setup not meeting any of the "productive" criteria, I think open, collaborative work environments are great. We deliberately setup an open floor plan to allow and encourage collarboration amongst the engineering team. If anyone has a question, all they need to do is turn around (or not in some cases) and the whole team is available to help. I like having access to everyone on the team if I need it, but I don't like the reality of it when you have people collaborating, shifting around, walking by, talking on the phone, eating, etc., all of which can be very distracting when you are trying to concentrate on a difficult problem.

Joel states in his blog: "There are extensively documented productivity gains provided by giving knowledge workers space, quiet, and privacy," and "We all know that knowledge workers work best by getting into "flow", also known as being "in the zone," where they are fully concentrated on their work and fully tuned out of their environment."  

So how do you balance the pros and cons of the collaborative work environment and the need for developers to get "into the zone" or find "quiet, and privacy?"  Que the noise-cancelling headphones.

Headphones are the keystone in the archway that is the productive collaborative work environment. Without it (them) the whole thing falls down. My office, my private space, my inner sactum within which i get "into the zone", is my noise-cancelling headphones (i have these). When i put them on, the whole office disappears and i can fully concentrate on the task at hand.  Several other people in the office also have headphones and make use of them frequently, which in and of itself helps boost the productivity of the office environment because people with headphones on are usually not making any noise. At least none that i can hear.

So, you can keep your productive work environment criteria (see Stormy's Productive Workspaces entry, "your workspace is 50-75% enclosed by walls or windows") and your office setup (see Joel's 12 Steps, "Now let's move them into separate offices with walls and doors."). I will take my open, collaborative environment, but not without my headphones.

r.

What is it about technical support that support personnel think that if they simply provide an answer, even if it's wrong, they have done their job? I find it really odd and a sad comment on the state of our society that this passes for customer service. First off, a caveat. Our company blog site is managed by the marketing department and they act as the in-house support liason to those of us who are blogging. The marketing people then route our support questions to technical support from the company that designed our website because they did the WordPress install for us. (WordPress is the software we use to host the blogs.) Our in-house marketing people are really helpful and responsive, and I know they are only telling us what the tech guys are telling them. So, this blog in no way includes the in-house support staff in my general comments about technical support. So, here's the scenario. For my very first blog, I wanted to write about Groovy and include a code snippet. Well, the editor page for WordPress mangled the formatting. So, I called tech support to figure out the problem. Now as I mentioned, the in-house support has been great (Thank you Greg!), but unfortunately still hasn't been able to solve the problem in a satisfactory way. The techs said that I can't use the <pre> tag. In my opinion this is a bizarre answer to the problem. It's like the old joke where a man goes to the doctor and says, "It hurts when I lift my arm like this." And the doctor responds, "Then don't do that." Considering that a blog is just an html page, and the <pre> tag is a perfectly valid tag, why can't I use it? It seems to me the problem is with the WordPress blog editor, especially because this is not the only problem with the editor. The editor barely works on Linux and Mac, both of which I use, and many of the developers in our company use. The editor page itself doesn't display correctly. It doubles up the Post text area. Fortunately, the functionality still works basically, so what I write in either Post box does get published, but it's rather annoying that the page doesn't operate as it should. Additionally, most of the tools such as inserting a link or indenting text, etc. don't work and the html formatting is bizarre and reformats things in unexpected ways. It reminds me a lot of MicroSoft Word. And that's never a good thing. So, how did we solve the problem? First, our in-house support made a jpg of the code snippet and inserted that in the blog. That's a great short-term solution, but is not really a workable long-term plan. Second, I went out and bought a blog editor. I know, I know, I never thought I'd say something like "I bought a blog editor", but for 18 bucks I got this program called ecto. (In fact, I'm using it to write this blog right now.) It's great. It works. So, I fixed the code snippet and used a <pre> tag even. And this makes the WordPress editor smell even more, since, the published post works just fine with the <pre> tag. So the WordPress editor is clearly the culprit. Which gets me back to technical support. The tech gave me the wrong answer, didn't own up to the fact that the WordPress editor is lame, and I'm sure he clearly felt his job had been done, even done well. It's no wonder that most people hate technical support. I work in a software company as a developer, and so I at least know enough to know when the techs are trying to pull a fast one, and it still makes me angry. It's really just sad. So, to all of you non-technical people out in the world, you are *not* alone. Tony

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.

As more and more Global 2000 companies turn to open source as a viable alternative to all kinds of commercial software products, they examine open source products using a familiar set of ground rules like price, support and indemnification.  The fact of the matter is that Global 2000 enterprises are expected—by shareholders as well as executive management—to exercise a reasonable standard of care when it comes to the software tools they acquire, whether open or closed source.  Failure to do so can have serious repercussions down the road. 

It’s one thing to have a couple of open source products brought into the enterprise by a developer.  It’s another thing altogether when an enterprise forms a clear strategy based on the significant cost savings and productivity increases that can be achieved by proactively moving to more open source.  And more open source is a good thing as long as the products are right for the job and the benefits outweigh the risks. 

When this happens, large enterprises look for the same assurances they’re used to getting from commercial vendors: they want SLA support agreements, confidence that the software will work they way it’s intended to, and indemnification against potential IP risks.  This is where OpenLogic bridges the gap.  We provide the products and services enterprises expect from commercial vendors, including a library of over 160 certified open source products.

OpenLogic provides a “security blanket” for open source so that enterprises can either adopt open source with confidence or step on the gas with a more aggressive strategy.  Dana Blankenhorn raises some interesting questions about indemnification coverage, but our experience with the Global 2000 tells us that it’s in integral part of our solution.

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

Research now shows that the lack of natural talent is irrelevant to great success. The secret? Painful and demanding practice and hard work

Even when you are talking about people like Tiger Woods and Warren Buffett.  I think this is really hard for people to accept.  Maybe it's hard to accept because then we'd have to accept that we aren't billionaires or star football players because we didn't work hard enough at it. 

I'd bet that success is greatly tied to interest.  It's hard to work really hard at something you aren't interested in.  But if you like writing code, you enjoy solving that puzzle, then you do it a lot and you get good at it.  Once you are good at it, people give you kudos, and maybe even pay you, and that motivation makes you feel good, and so you do it some more, and you get better at it.  Sooner or later you're really good at it because you've been "practicing" hard for a long time.

 (So that's why, if you aren't good at writing blog posts or comments, you should keep at it!)

The article also points out to be good you not only have to practice, but you have to get lots of feedback and you have to incorporate that feedback into your practice.

So that's why the open source community writes such good code and produces good hackers.  They write lots of code (i.e. practice a lot) and get lots of feedback. 

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.

Weighing in at 6.9 grams after almost 6 years of effort and refinement, Alexander Van de Rostyne has pushed the size and weight of the Pixelito down about as low as possible. The little chopper is controlled by an infrared signal and uses a very lightweight, 1mm carbon continuous frame that comprises the skids and the canopy protection around a very simple motor and flight mechanics design.

Check out this video of the little fellow flying around a living room.

There's a really nice library of links, Collective Ptich, on R/C helicopter technology. These machines are an incredible combination of mechanical engineering, electronics, materials, and ingenuity. I think it's fascinating to see what people are doing with them. Here's a video of a guy who took his micro-helicopter, a "Piccalo", into an inverted hover and then landed the skids on the ceiling of the room he was flying in. A good website selling micro (and traditional sized R/C) helicopters is helihobby.com

Helicopters have been a great way to introduce various physics lessons to my 8 year old son (plus his old-man gets a big kick out of them, too.) He's starting to learn Newton's 3rd law through asking why a helicopter has to have a tail rotor.

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

Carly Fiorina talks about the collective attitude at Hewlett-Packard during her time as CEO, and how diversity can enhance the workplace. In HP's case, she says, change was not openly accepted, which proved to be a challenge while she led the computer giant.

 That's interesting because I always thought that she didn't realize how much change she was asking for.  Personally, I thought a lot of the changes were good but some were a very big change from the way "things used to be done" and she didn't allow a lot of time for people to buy-in to the changes.