As a developer at OpenLogic, I use open source software every day on the job. In fact, without a second thought I can go so far as to say my job wouldn't be possible without open source. But that's not the only reason I love it.

In my last article, "3 and a Half Reasons You Really Need to Scan for Open Source Software", I argued that most development teams might discover open source code in their projects, even when they're not intentionally using any OSS. In the next few articles, I'd like to explore how projects can end up using OSS intentionally and unintentionally.

The short answer is that your Open Source is always outdated. Rod Cope wrote a post recently on strategically watching for your Open Source becoming obsolete and looking for new trends to consider. However, you are likely already using tens or hundreds of Open Source packages daily and these packages are constantly updating, adding new features, increasing performance and fixing bugs. It is very important to keep aware of how the underlying technologies are changing and keep up to date to avoid headaches in the future when massive upgrades are required to play catch-up.

What are your options?

In determining your configuration you must evaluate the resources at hand.  This section will discuss possible options for your resources, without actually taking your resources into consideration. The next section will make suggestions as to which configurations your company may leverage depending on the resources available.

Today’s guest post is by Tim Golden*

_________________________________________________________________________ 

Microsoft continues to be a lightning rod for controversy in the open source communities. A quick Google search (microsoft open source) shows the breadth of opinions on Microsoft's open source involvement.

Like you, developers and architects around the world rely on open source packages every day.  But how do you know when they’re getting stale or obsolete?  Where do you look to find better, newer alternatives to the projects you’re using today?  How often should you go looking around for upgrades?  Let’s take a look at some best practices that will keep you on well-supported packages for the life of your project.  

This post is part 1 of a 3 part blog series that will look at leveraging Apache Tomcat clustering, in order to increase your system’s availability.

As part of our ongoing search to improve the way we deliver software, we recently tried Kanban on a new development effort.  Ultimately, we ended up taking some of the positive aspects and going back to more Scrum-like process, but the effort was very worthwhile.  OpenLogic has been using agile practices for many years now. Like most  things, the results are cyclical. Get comfortable for a while and then something changes and forces a period of adjustment. Thus it is important to continually review in order to recognize when change happens that affects processes (and let's face it, change happens very quickly in this industry). Luckily, as engineers, we embrace change.  We had the opportunity to look at a radical shift  in our agile processes due to starting new development on our CloudSwing product and Kanban fit with some of the ideas we had been discussing. CloudSwing gave us the ability to try out these new ideas without incurring some conversion costs for our much larger codebases.

If you are a web application developer and have never heard of HtmlUnit , it is time to give it a look.

It is a simple API that allows you to write a Java program that can simulate a user traveling through a website. It doesn’t just read the URL into an input stream; it can parse the HTML and allows you to simulate clicking on buttons, clicking on links, firing JavaScript functions, and more.

HtmlUnit for testing

HtmlUnit was intended to be used for UI testing. For example, let’s say you host an eCommerce Java EE application. In order to perform some testing, you would want to simulate the entire life cycle of a user creating an account, verifying the account, logging in, filling up their shopping cart, and paying for the items.

Normal Java testing methods use JUnit and only test the the back-end Java code that runs on the server. This is fine and dandy, but that is not how the user uses the website. You need to use a UI test in order to truly test. While testing the back-end is extremely valuable and should never be forgotten, you are potentially not testing several key things that can only be tested using the actual browser.

For example, here are some issues that cannot be tested on the back end:

• When trying to view the shopping cart, a JavaScript Error occurred and prevented the cart from loading.

• When attempting to make a payment, the user’s session was invalidated and they were brought to the log in screen.

• The "Check Out" button was disabled when it was not supposed to be.

HtmlUnit for Automation of Tasks

Some Limitations

While HtmlUnit is very cool and extremely powerful, it isn’t perfect. As you can imagine, web browsers are extremely complex and have invested 1000’s of hours of development to create them. The open source developers who made HtmlUnit do not have those sorts of resources and therefore are not going to be able to perfectly simulate each web browser.

So apart from the HTML results of web page actions being quirky and a bit different than you’d expect at times, the other common issue is that the JavaScript engine fails to parse the JavaScript on one or more of the pages and throws exceptions. Once the JavaScript fails to parse, you will have to disable JavaScript completely.

So if you find yourself performing mundane website data entry and you get sick of it, or if you need to test the full user experience through your website instead of just the backend Java code… give HtmlUnit a whirl.