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.
This post is part 2 of a 3 part blog series that will look at leveraging Apache Tomcat clustering, in order to increase your system’s availability.
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.
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.
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:
If you read a post on The Enterprise OSS Blog, please leave a comment. Let us know what you think, even if it's just a few words. Comments do not require approval, but they are moderated.OpenLogic reserves the right to remove any comments it deems inappropriate.