Good Java Fish

The Agile Manifesto states that you have to value individuals and interactions over processes. I'm pretty sure that when a customer repeatedly fails to arrange a meeting to discuss basic things, then using Agile actually ensures faster failure of the project. I am also sure that it is a good thing. The faster you admit that a doomed project is a failure, the less time you spend actually failing. As a result, you'll have more time to do something really good and useful.

Recently I have stumbled upon a "floating" (randomly appearing and disappearing, the nastiest kind) bug in the legacy code of an in-house financial system: a pie chart, drawn by Google Chart API, sometimes disappeared from the report. After a quick investigation I found out that requests URLs to the API were too long. First, I thought about converting request to POST. Thanks to the Good Empire, they added the POST support to their Chart API.

The JSR-303 validation is great. Yes, really. But sometimes it is just too great. Imagine yourself having to do some complex validation on a single data-transfer POJO. Maybe you are collecting the data from a web-form and you need to show an error somewhere, but the default validation rules just don't fit, your to-be-enforced constraints are just too complex to be enforced using default constraints. It can be as simple as having to check for a string to be submitted, if, and only if, a checkbox is selected, but yet it is too complex to achieve using the default rules. Yes, you can define a custom annotation, write a validator, a unit-test for validator, then define a message for the validation error in your Validation.properties file and so on. Do you really have to do all that? If you are going to reuse the code – yes. But if it is really just a one-time shot? Then a simple short-cut can do the trick: just define a method in your POJO class that will do the validation, then an