Outline

At my current project, some of the webservices we need to connect to are running in a non-firewalled environment. In order to prevent unauthorized clients from connecting to these services, the administrators decided that is was a good plan to use mutual authentication using SSL. Since these are all connections running within the intranet environment of my customer, the certificates are not signed by a globally trusted certification authority (like VeriSign) but by an internal certificate authority which is not trusted by default.

Globally, the picture looks like this:
[WAS]--https->[[IHS]--http->[WAS]]

WAS = Websphere Application Server
IHS = IBM HTTP Sever (Apache with extra’s)

We have webservice clients running in WAS which use Apache CXF, an open source services framework, to communicate with webservice providers. These providers are running on another WAS instance. The HTTPS connection terminates at the IHS which runs on the same machine as the WAS instance to connect to. The WAS instance then is configured to allow only connections from localhost.
 Read more

The metaphor technical debt was introduced at the OOPSLA conference in 1992 by Ward Cunningham. The phrase was:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…
The danger occurs when debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

The following picture shows how this “stand-still” described by Ward Cunningham is achieved.

http://theagileexecutive.com/2010/09/20/how-to-break-the-vicious-cycle-of-technical-debt/

In most discussions/blogs on the internet the following causes are mentioned and most are code related:

• the business forces the development team to take shortcuts, aiming to get the requested functionality life as soon as possible.
• the development team thought they didn’t need to design.
• the development team was incompetent/didn’t bother to write maintainable/changeable code.
• the development team  recognizes later for example by incorporating a change, that they made a suboptimal decision in the past (difficult to avoid).
  

Martin Fowler summarized this very well in his blog “TechnicalDebtQuadrant“. He distinguishes between reckless vs. rational behavior and  deliberate vs. carelessly/naively choices. But this is still mainly code related.

But if you look at the forms of technical debt in real life situations, you’ll see that these are not only code related. Technical debt may manifest itself in the following form to us:

• Code form (as mentioned already), e.g. duplication, high McCabe index, high unit-length per method, high number of parameters in methods, wrong comments, unclear naming of objects, methods, variables and properties, etc.
• Architectural form, e.g. violating separation of concern, the choice of not using a third party framework but build your own, not changing/adapting your architecture to the changes (gradual or abruptly) in the world around us.
• Testing form, e.g. a decision to not do automatic testing, while testing the system by hand is to complex or takes to much time, to conclude after testing that everything is OK.
• Deployment form, e.g. when a deployment is arranged in such a way that it costs a lot of time and is error prone, thus limiting the number of releases in a period in time.
• Documentation form, e.g. it is unknown how the system should react in certain situations because it is not functionally described. This makes future functional wishes time-consuming to fulfill.
• Functional form, e.g. by business requested and by the development team invented functionality that is not really needed and makes things unnecessary complex for the upcoming change.
• Project form, e.g. distribution of experienced people vs. not experienced people in your team, same applies to skills in the team, onsite/off-shore team distribution, etc.
• Organizational form, e.g. not asking your software (application) provider what kind of quality assurance policy they apply and if they can provide any quality figures based on a ISO maintainability-standard.

All these technical debt forms result in less changeability, more costs and delay in bringing new features life. All forms can be plotted on the TechnicalDebtQuadrant of Martin Fowler. Whether technical dept is categorized as deliberate, inadvertent, reckless or careful, it is good to be aware of this and see how you want to cope with it strategically.

Conclusion

Technical debt is not only technical and has several forms other then code form.  The metaphor “technical debt” is invented to visualize the problem of decreasing productivity in the life cycle of the software product. People  can communicate with the metaphor more easily about the problem it addresses. This way the concept became known by development community, and unfortunately less known in other areas listed above.

Management familiar with the metaphor, can use it as an advantage by making strategic decisions regarding technical debt, because they understand the concept of normal debt. But for strategic decisions the management should be aware how much technical debt there currently is (like a normal debt) and the chances of a technical credit crunch leading to possible technical bankruptcy….

So is technical debt only technical. No, it is not.

Introduction

We all know the rule in some form or another: three times and you automate. And although I try to apply it, I find myself repeating some things with every new project, like creating a new CI server.

One solution would be to have a centralized server for all your projects, but customers are mostly not willing to depend on services outside of their network, which means you are often stuck with having to create a local solution for each project.

Having done this three times, I decided to start a repository to store scripts to automate development machine setup. One command to get you a fully functional system you only need to tweak to suit your needs. This blog will show you how to quickly set up a Jenkins server on a local virtual machine.

 Read more

Most ESB example start from some HelloWorld use case, where you have to send a message to the ESB and it will print it to the console. In this post I would like to show that you can do a lot more with an ESB, for example reading and analyzing data from social media like twitter.

The example below will demonstrate how you can use JBossESB to retweet every message containing a certain hashtag. If you want you can extend the example and store all the messages to database, or keep track of those users who have posted the most amount of messages with a certain content.

Prerequisites

• JBoss AS 6.1 installed
• JBoss ESB 4.10 integrated
• Also add the twitter4j library to the JBoss library folder

Step 1) Create a scheduler using JBossESB
When you want to retweet all messages containing a certain hashtag, you need some kind of scheduler that is fired every second, minute or hour. In the jboss-esb.xml file you can do this by using a ‘schedule-provider’.

 Read more

2011 has been an interesting year for cloud computing. Traditionally, cloud computing can be divided into three categories:

• Software-as-a-Service (SaaS)
• Platform-as-a-Service (PaaS)
• Infrastructure-as-a-Service (IaaS)

While SaaS has been around for some time (Salesforce.com started in 1999!), we are seeing an increase in adoption of IaaS and some heavy development in the PaaS world.

Now that 2011 is coming to an end, this is also the time for lists. So here are my 3 top 3’s of cloud computing.

 Read more

As pointed out in an earlier post the importance of testing can not be understated.
In this post we will delve into BDD of Android apps.
There are a number of other testing tools for Android out there, such as Robolectric and Calculon. Robolectric improves the speed of running the test by executing it outside of the emulator. Calculon is a DSL for testing views and activities. As Robotium seems to most mature and reliable, it is my preference.

Robotium.org

 Read more

Last weekend the public beta of JavaFX 2.0 came out. I’ve much anticipated this release, as you might guess from my previous posting on JavaFX 2.0. I’ve downloaded the JavaFX-runtime, SDK and Netbeans-plugins the following evening from Oracle’s JavaFX page and started trying out JavaFX by viewing and running the examples from the SDK from Netbeans.
I’m quite enthusiastic, read on the learn more!
 Read more

Since a couple of months I’ve been developing mobile applications, some are for the business at home (girlfriend-shopping-list app that actually works and augmented reality garden iPad app) and some are for work. I have experienced that TDD and Continuous testing (Test Driven Development) is a way of working that leads to fewer bugs and regression problems and better design in my software, it’s my preferred way of programming, not testing.

And to start off, here’s how I benefit from doing TDD:

1. Robust
2. Better code design, no really!
3. Find regression problems early on

and you can read more on TDD and Continuous testing here.

The thing is, writing a mobile app takes about 20% of the time it would take me to write a web+client+server based app. Which of-course is really nice, because I can write lots of apps. It also means that whenever i need to fix a bug or add new functionality, I need to have developed it in a TDD fashion, otherwise i cannot guarantee reliability. So let me explain why…

 Read more