Some time ago I got in touch with one of my 2006 written applications. I got flashed at the moment I looked into my code.

My intention was to perform some improvements. 2006 had very few frameworks to deal with HTTP interfaces. The most common interface types were GUIs (JSP/JSF) and some SOAP Services. Writing HTTP interfaces for API use (calls from JavaScripts and so on) was still a hard way in Java applications. In most cases servlets were used. Those servlets received either Query- or Form-Params to perform the processing. Sometimes they even accepted/produced some XML. Let me show you some examples and how to solve them using current technology.

Read more ...

Once someone has written a software and he wants to sell it, ideas of licenses and copy protection arise. There are several ways, how software can deal with that: No license control at all, license keys, serial numbers, online activations, encrypted source code. Every type has its pros and cons.

Read more ...

It’s a common problem almost which every application has: Where do I put my configuration? Lucky you, rich clients and standalone applications. For most rich client/standalone apps it’s somehow easy, because you have to have somewhere a starter, so you can deploy the config somewhere along the starter. 

Read more ...

In Continuous Delivery you deliver often and to different environments. When it comes to configuration files you have to maintain multiple instances at a time. You can’t just have one fits it all. The Configuration Server is built to support you in this scenario. Basic idea of the Configuration Server is: Serve configuration based on your host for multiple artifacts and versions.

Read more ...

In my last post about Integrationtest-driven development/Test-driven integration I was talking how to get started with integration testing. Sometimes it comes to the point, where your integration tests need more than only a database and a running system: You have additional dependencies like EJB's or Web-Services. What now? You can't always rely on test-systems: Sometimes there aren't any or only shared instances exist. Sometimes it's even harder to simulate a specific scenario using real services because of data and logic dependencies.

Read more ...

TDD (test-driven development) is a well known development process for now. You start with a idea of a solution and the test. Then you proceed within a cycle of writing production code, then test code again, start over.

Read more ...

I’d guess, nearly every developer, who assisted on releasing and go-live of his software ran into the same issue: How to deal with sensitive configuration data such as passwords, keys and tokens? Hard-coding of passwords it out since the late '90s. Writing passwords in plain-text into config-files is as well a security breach. Encrypted passwords within config files are much better but demand you to implement some kind of encryption. Still you have then the problem: Where to put the encryption key?

Read more ...

JUnit test are inherent to almost every professional Java project. Some utilize JUnit more than others, some use it for integration tests. But nearly all of them have similar issues. As soon as they reach the testing boundaries, they have either to take care of expensive test setups or rely on some infrastructure stuff such as databases or remote services. One way is truly keep going on with the known procedure. A different approach is the usage of test dummies. Either as stubs (i.e. sub classing to simulate the desired behavior) or mocking. Mocks are instances of your classes or interfaces which can be told how to behave in a certain scenario.

Read more ...