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...

I recently read on ecogeek.org, that Apple filed for a patent for “solar cells on portable devices”. I'm a bit skeptical, but solar re-chargeability might be a nice feature for the iPod or iPhone. I still do not see sitting on the grassy bank of Barton Springs Pool with my solar powered Macbook Pro; I might exceed my own geek tolerance and be forever doomed as a “geeko freako” . However, I could put it to use at ACL Festival, for example. Given there is never a shortage of sunlight at ACL Fest, my iPhone should stay charged well into the night. Then, I might avoid wandering around aimlessly; tripping over chairs; looking for my friends because my phone died from the 100 text messages I sent during the day. It also might come in handy while traveling. Instead of worrying about whether I would actually need that tourist map I left on the steps of Gaudi’s La Sagrada Famila, I could concentrate more on the bus that is about to hit me as I attempt to cross Las Ramblas staring at my zoomed in map on my phone. I guess it might have a bad side, Austin, TX has a lot of sunny days and the ole “Honey, I didn’t get your call because my cell phone died” excuse might not work during the summer. Anyway, the more I think about this solar powered Apple gadget, the closer I get to a nerdnirvana!

In Untagged 
Comment (0) Read More...

IBM has begun the WebSphere 7.0 Open Beta program. Here is a snippet from the email notice:

You may review the features and highlights on the Open Beta overview page at this URL:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/

The Code and Library downloads may also be found at these URLs:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/download.shtml https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/library.shtml

For support issues related to this Open Beta program, we have also provided a discussion forum, which you may access from this URL:
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/
wasndv7/support.shtml

 

The first thing I noticed about this release is the VMWare images. IBM has included SuSe images with WAS 7 previously installed. Just download the images, point your VMWare Player or Server at them, and test drive WAS 7. (Hint: root password is ‘password’.) I hope this means that IBM will be releasing other WebSphere based applications as VMWare images for evaluation, such as WebSphere Portal.

After starting my standalone Profile and visiting the Admin Console, I was struck by how similar to the WAS 6.1 console the WAS 7.0 console is. There was quite a bit of change from WAS 5.1 to WAS 6.0 and some marginal change in WAS 6.1. But, it seems that WebSphere has stuck with the same layout. That’s very good news for companies that rely on manual deployment.

However, there is cause for concern. The following MBeans have been removed:

 

• SIBJMSConnectionFactory
• SIBJMSProvider
• SIBJMSQueue
• SIBJMSQueueConnectionFactory
• SIBJMSTopic
• SIBJMSTopicConnectionFactory

Of course, this might simply be an oversight that the Open Beta program is meant to address. Or, it appears the JMS aspects of the Service Information Bus have been removed.

We’ll do some sleuthing on our end to see where they went to. But, this marks a change in how IBM has done WebSphere releases in the past. In fact, they still have WAS 4.0 MBeans in WAS 7.0 (e.g., WAS40ConnectionPool, WAS40DataSource). Heck, they still have it in the Admin Console, too!

In WebSphere 7.0, Open Beta Program
Comment (3) Read More...

When I started working with Eclipse in 2003 I would just download the plug-ins I needed from the Eclipse website, unzip them into my plugins directory, and restart Eclipse. Sometime later, the Eclipse Update Manager was introduced to help you configure your Eclipse development environment providing the ability to update your existing features and plug-ins and search for new features. I have always found the Update Manager dialogs difficult to understand and use. Customizing the Update Manager to work with my Rich Client Platform (RCP) applications has also been very difficult.

When I heard about the new Equinox p2 provisioning system at EclipseCon this year I was excited that the Update Manager was finally being replaced. However, one thing I have learned when working with Eclipse is to take a “wait and see” approach before adopting the newest and improved APIs and methodologies. So, I have been reading various blogs to see what experiences developers are having implementing p2 in their products. Here are a couple of postings that make me think that p2 may not be quite ready for prime time:

Why Eclipse Equinox P2 Update Manager Sucks

Why Eclipse Equinox P2 Update Manager is not good enough for me yet #2

If you have had a positive experience replacing Update Manager functionality with p2 in your software product I would love to hear about it.

-Shawn

 

In Eclipse
Comment (0) Read More...

Beginning in the 90’s, American software companies began farming out development work to companies overseas, or "off-shoring". These efforts mirrored what had been taking place for quite some time in other industries, such as textile manufacturing, and sent tremors through the software community. The heady days of the dot-com boom gave way to fear and gnashing of teeth in the early part of this decade. CEO’s were pictured riding astride elephants in India, and executives were predicting that soon all non-design development work would take place off-shore. Would there be any jobs left for American software developers?

Now entering the latter part of this first decade of the 21st century, the software development community state-side finds itself in what appears to be a better situation, jobs-wise. What happened? Why did the gloom-and-doom scenarios not play out?

A couple of realities have become apparent as the decade has played itself out. First, globalization of software development has actually worked against itself, as the cost of doing business in countries like India has increased to the point where the cost savings benefit is in question. Software developers are able to demand more money there, as the need for them has increased.

But secondly, and I believe just as importantly, companies seeking to off-shore their development made critical mistakes in choosing the products that they would send overseas. The products they chose were mostly mainstream, legacy products, which tend to be, by their sheer longevity, much more complex and intricate. From my experience in this business, I have found that "old" does not equal "simple". In fact, just the opposite is true. This software has generally been developed over the years by hundreds of developers, all with different programming styles, and do not always follow textbook patterns. Asking primarily inexperienced developers to maintain or enhance these products without day-to-day guidance from at least a few senior developers is tough. Couple this fact with the risk of losing market share for these products (oh yeah, they’re probably still profitable, why else would development continue?), and you have a recipe for disaster.

What seems like such a great idea when discussed at cocktail parties 8 years ago, should now be one that should be considered with at least some trepidation.

In Untagged 
Comment (0) Read More...

A long time ago, I was on a NOLS adventure in the middle of the Olympic mountains. My group was resting one day high above the tree-line in a snow covered area when we found a small, but steep bank of snow ... perfect for headfirst nosedives. It all seemed harmless at the time, until our guide angrily reminded us that whatever choices we make, the fact remains, we must weigh the risk versus the reward. Shocked at first by his reaction, we all suddenly had the realization that given our surroundings and circumstances, the risk we were taking was much greater than the reward.

This article about Twitter recently reiterated to me some real risks with Ruby on Rails. Whether or not Twitter is abandoning Ruby on Rails, the risk of a severely flawed framework remains.

Ruby on Rails is a language and platform that makes web application development quicker and more maintainable. One of its strength is that the Rails Framework enforces consistency in style and encourages code reuse. Past that, Ruby as a language is just another language. Rails is an innovative framework, but it is only a framework. Many arguments are made regarding the technicalities of Ruby and other languages.

I do not wish to rehash these arguments; but instead, I make an assertion that by choosing the Ruby on Rails platform in an "Enterprise" environment, your organization is taking unnecessary risks considering its surroundings.

For the last two years or so I noticed a new wave of energy surrounding Ruby on Rails. I encountered some very strong proponents of Ruby on Rails who wanted to use it in an Enterprise setting -- I always had one simple concern:

Ruby on Rails is a two tiered platform; thus, fundamentally flawed. A Ruby on Rails application is doomed to scalability issues. So while it may be fun implementing a web application using a new innovative platform, it will not be fun when your company is finally on the verge of success only to discover it has a severely under-performing application on a platform that provides few options to scale. Twitter anyone?

Now, consider the recent support that companies such as IBM have put behind a long time leading web application language, PHP. By leveraging PHP, a developer can now overcome many of the "ease-of-development" drawbacks of developing a traditional multi-tiered Java based web application, but still have the facilities of a highly scalable application server environment such as WebSphere XD.

Much like sledding down a hill, creating a simple web application using Ruby on Rails has its advantages. However, when you consider the surroundings of an Enterprise Environment, it is hard to consider any situation that Rails is worth the risk.

In Twitter, Ruby on Rails, PHP
Comment (4) Read More...

As a software developer, maintaining concentration is something that requires discipline, and sometimes the aid of a good set of headphones, and some music.  While this usually does the trick, I find that familiar music can be its own distraction, since I find myself jumping to some memory that the song brings back.  In addition to this, transporting CDs back and forth from home to work is a pain.

For these, and other reasons, I've looked for alternative listening sources, and one I've found very enjoyable are the Internet radio channels streamed at Soma FM.  This full-time, Internet-only station began as a pirate radio broadcast at the Burning Man festival in 1999, and now streams 16 different channels.  My personal favorites are Groove Salad, which plays music in the Ambient genre, and indie pop rocks!, playing new and old tunes.  In listening to these two channels, I've discovered a lot of new music (which is harder to do the older I get), but at the same time, I find that I'm able to keep my focus on my development work, since I'm not as familiar with the bands.

If you're looking for some really great music to work by, check them out.  I think you'll find some great music which just requires an Internet connection to enjoy.

In Untagged 
Comment (0) Read More...

We are pleased to announce that Phurnace's flagship product, Phurnace Deliver™ is now directly integrated with IBM® Rational® Build Forge®. We invite you to hear all about it in our upcoming webinar - Accelerating the Software Development to Deployment Lifecycle Are you ready for one process to compile, build, deploy and configure your applications?

In this webinar, we will show you how to do that with IBM® Rational® Build Forge® and Phurnace Deliver™ products. We will explore how to use Build Forge and Deliver together to have a uniform, fully automated build and deployment process without the use of scripts or manual intervention. We will discuss how to use the combined products to check-out, build, deploy, and configure your JavaEE applications automatically. In addition, we will discuss how to preview configuration changes, keep logs of configuration and code deltas, compare configurations across servers, as well as how to manage the sometimes chaotic process of building and deploying complex enterprise applications.

Date: Friday, May 9, 2008
Time: 2:00PM - 3:00PM CST
Location: Online
Presenters: Leigh Williamson, Distinguished Engineer, Rational Software Architecture and Development, IBM & Daniel Nelson, Vice President of Products, Phurnace Software
Registration: Please register here to reserve your space.

We hope to see you there!

In Deployment, Configuration, Build Forge
Comment (0) Read More...

There are quite a few toolkits available for Java developers. Let me help point you in some directions and maybe save you some research time.

Many of you will be familiar with the Abstract Windows Toolkit (AWT) that is available with every Java Runtime Environment (JRE). AWT is the original Java GUI toolkit developed by Sun Microsystems. AWT is a peer-based toolkit meaning that each AWT control is dependent upon a host operating system control. AWT usage is limited because it was designed to only support controls which are available in all Java host environments. For example, AWT does not support Trees and Tables.

Swing is another Java GUI toolkit developed by Sun Microsystems and was designed to work with AWT and is built on top of AWT components. Unlike AWT, most Swing controls are emulated. This emulation makes user interfaces written in Swing portable across all operating systems and supports Sun’s “write-once, run anywhere” motto. One disadvantage to Swing is that the emulated controls often don’t result in a native looking application. Swing’s answer to this problem is provided by look-and-feel emulators that attempt to change the appearance and behavior of their components to adapt to a particular operation system or theme. Another disadvantage to Swing is that the emulated controls tend to run slower than peer-based controls.

The Standard Widget Toolkit (SWT) is another peer-based GUI toolkit. IBM designed SWT to solve some of the problems that have limited the usage of AWT. SWT provides a different Java implementation for each operating system platform using Java Native Interface (JNI) calls. One disadvantage for SWT is that developers are required to dispose of OS-dependent objects within their application code.

JFace is a GUI library that was developed to compliment SWT and simplify common GUI programming tasks. SWT and JFace libraries are used extensively throughout the Eclipse IDE.

As a Java user interface developer I have used each of these GUI libraries and I find the combination of SWT/JFace my favorite choice because of the native look-and-feel of the components. I also find the SWT and JFace APIs cleaner and easier to develop with than AWT and Swing. My two cents, comments welcome.

In Java GUI Toolkits, Java GUI, java, Abstract Windows Toolkit
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...