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

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

In the early days of development, where technical approaches and feasibilities were depending on "is there any solution available", lots were happy connecting a database using a web front end. Decoupling and abstraction layers were built to hide the complex persistence API. Ugly web wrappers were also tried to decouple. In the end, you got lots of framework stuff, just because there wasn't anything else.

Today it evolved. Spring hides and provides lots of functionality. Enterprise Java provides API's for nearly everything that modern applications use: Persistence, Web control, Web-Services. But somehow, thinking did not change much since then. Today we see tons of mappings, abstractions and decoupling layers. Is it really necessary to build data access objects in case you use JPA? Do you need mappings and tons of layers for exposing database data using a REST API?

It's worth rethinking. Just because we always did isn't the right answer.