Who’s On Phirst

In the last 10 years, Open Source software has provided an incredible benefit to the software development process. Most open source software projects present quality, well-tested APIs and libraries that can be quickly integrated into a product, providing much-needed functionality that does not have to be developed in-house. While there are too many projects to even begin to mention, the software produced by the Apache Project, and SpringSource provide frameworks and utilities that would take companies man man-years to develop on their own.

There are, however, a few issues that every organization should consider before choosing to include open source software in their commercial products. While these issues are usually not show-stoppers in the decision process, but should be viewed as risk factors. Failure to consider these issues can leave a company with problems that cause development and maintenance nightmares.

First, I would take the time to consider the involvement of the project's community of users and developers. Is work on the project ongoing, or does it seem to be stagnant? Are there discussion forums for the project, and do the developers post to the forum? An active Open Source project community enables you to resolve usage issues, obtain patches, and generally integrate the project more quickly into your product. A less active community can be an indicator that the project has not been well-received, perhaps because of stability, or even issues with its usefulness.

Licensing is a potential Pandora's Box of issues for anyone wishing to include Open Source software in their product. In general, software which fall under BSD or Apache licenses are the safest to use. For example, the Apache License allows free use, modification, and distribution of their software, provided that the appropriate notice is included. A great source of information concerning Open Source licensing issues is the Open Source Initiative. This group maintains the definition of open source software, and vets licenses in order to certify that the license adheres to it. In this litigative age that we live in, no one needs the hassle of a potential lawsuit involving their product.

In my opinion, while there are issues involved in the choice to include open source software in a commercial software product, the benefits far outweigh the drawbacks.

In Open Source
Comment (0) Read More...

In my last post I talked about how virtualization changed test lab creation and management. I’m sure the first thing you did after reading the post was download your very own copy of VMWare Server and replace all your hardware with super flexible virtual machines. You’re now basking in the glow of your long term cost savings, marveling at how easy your lab is to maintain, and using some of that extra time and money to bid on my exclusive line of “VMWare Saved My Marriage” T-Shirts available only at my eBay store.

Eventually your boss will notice you’re no longer cursing under your breath and slamming the door to the lab. It’s inescapable. And when the boss man gets wind of spare cycles, he starts thinking crazy thoughts. He starts thinking you now have time for that automation project that’s been on the back burner since 1996. With a heavy sigh and a final farewell to what will inevitably be known as “The period in my life that was great, thanks to Pete Pickerill,” you turn your attention to how you’re going to build a flexible automation framework that runs just as well on your Unix & Linux systems as it does on your Windows systems.

Have I got an open-source project for you! Software Test Automation Framework (STAF) takes care of all the nagging little odds and ends that have very little to do with testing your software. STAF employs a series of pluggable modules (called ‘Services’). Standard services cover most of what you’ll need: file system operations, environment variable management, process execution, logging, and miscellaneous commands like ‘ping’ and ‘zip.’

The command above may seem a little cryptic, but when you break it down into steps it starts to make sense. In the example above:

• STAF is executed on Server1: STAF Server1
• The Filesystem Service (FS) is invoked to copy the file myFile.exe: FS COPY FILE myFile.exe
• The target directory is given: TODIRECTORY /your/dir/here
• The target machine is given: TOMACHINE System2

That’s STAF in a nutshell. You execute the STAF command locally or remotely, you specify the service you want to use, what you want to execute within that service, and provide the necessary variables to complete the task.

Now you may be thinking, “But, Pete! What if the copy fails due to disk space limitations or network interruptions? What if System2 didn’t boot to a usable state? What if it just up and fails for no discernible reason at all?” There, there buddy! It’s alright! STAF gives you very descriptive return codes. What’s more, these can either be returned to STDOUT if you’re using the cli or a scripting interface or as Java Objects if you’re using STAF in a Java class.

Other cool things about STAF:

• Accessible: Java, Perl, Python, Tcl APIS and an Ant task make it very easy to fold STAF into your automation. There’s also an Eclipse plug-in I haven’t had a chance to check out.
• Extensible: Write your own services in Java, C, or C++ to handle testing peculiarities specific to your software.
• Documentation: STAF is managed by IBM and the documentation is the best I’ve ever come across in the Open Source realm. STAF DOCS
• Active Community: STAF is frequently updated and new features and integrations are added all the time. There’s also loads of info in the mailing list. STAF MAILING LISTS & DISCUSSION FORUM

For more examples and info, check out the STAF website, Agile Testing Blog & Performance Wiki.

In Tips, STAF, Software Test Automation Framework, Open Source, agile testing
Comment (0) Read More...

 Last week I attended the EclipseCon 2008 conference in Santa Clara, CA.  This was my third EclipseCon and by far my best experience.  This year there were a lot more technical sessions to choose from and overall the presentations seemed more professional than in the previous years.  I also liked that the Monday tutorials were included in the overall conference registration fee, rather than an extra charge.

I think the highlight of the conference was the key note speech of Dan Lyon (Fake Steve Jobs).   Here's a quote about Dan from the EclipseCon website.

"At his blog, fakesteve.blogspot.com, Lyons has captured the Zeitgeist, from perhaps the one place it is clearest-the point of view of Steve Jobs. In the tradition of Jonathan Swift and The Onion, he uses a pitch-perfect satirical style to deliver trenchant social commentary, reflecting on everything from the Cult of Steve and the rise of Apple ("Dude, I invented the friggin' iPhone. Perhaps you've heard of it!") to the ubiquitous influence of the tech industry on our everyday lives."

Another key note speaker was Sam Ramji, Director of Platform Strategy at Microsoft.   I think of Microsoft as the Borg and their presence at EclipseCon as another strategy to assimilate the Eclipse Community and open source.

The sessions that I found most interesting were those discussing the Rich AJAX Platform (RAP), The Rich Client Platform (RCP), and the Web Tools Platform (WTP).  I particularly enjoyed the "GWT vs RAP" presentation by Mark Russell and Dan Rubel, discussing the differences between Google Web Toolkit (GWT) and Eclipse Rich AJAX Platform (RAP) development.

If you are a software developer I would highly recommend you check out next year's EclipseCon.                 

In Open Source, Eclipse
Comment (1) Read More...