Let’s start with the 800lb gorilla in the room, Java. Why Java? Well, let’s start off with the fact that it’s got a ton of community support and documentation everywhere. If you Google a programming problem, chances are within the first three results you will see an example using Java. There is also a plethora of amazing editors available. A good editor is not a replacement for knowing the tools available in a language, but it can help you in learning.
ActiveMQ is a great messaging broker. However, using the default configuration is not recommended. This article will explain how I determined the appropriate ActiveMQ memory settings for one of our clients.
After years of being immersed in Java development, I must admit that I got spoiled by its strong and mature ecosystem. Hence, whenever I want to pick up a new technology or programming language the following must be there:
Support by my favorite IDE (Eclipse or IntelliJ IDEA)
Mature building framework. It does not have to be Maven or Gradle but it needs to be at least better than Ant.
Easy TDD. This could be the trickiest one to achieve because not only do I need a testing framework, but it must also be supported by my IDE and build tool. Moreover, it must have an adequate mocking framework.
Groovy easily satisfies those criteria right out of the box. It has awesome support by IntelliJ IDEA, Gradle is written in Groovy and you can write JUnit 3-style unit tests.
Starting in Spring Security 3.2, developers gained an easy solution to their Cross-Site Request Forgery problems with Spring’s implementation of the Synchronizer Token Pattern. Spring’s documentation does a great job of explaining Synchronizer Token Pattern and their implementation, so rather than talk about all of that, I’m going to show you how to tweak their configuration so you can have greater control over the urls that are protected.
Error handling is tricky. Not because it’s especially hard to do, but because everyone (operations, the business team, fellow programmers) seems to have a different idea of how a particular situation should be handled. A web service is down? No problem. You should try again every five seconds, but no more than 10 times. If the service doesn’t respond, send Operations an email, but don’t send me an email every time you fail to message it, just the 10th time.
These special requests result in “little gems” of code that are sprinkled throughout your application. They’re really important when everything is going wrong and ignored the rest of the time. It’s a shame really, some of the ridiculous stuff above is harder to write (and test) than some of the production code we’ve all written.
I know I’ve said this before, but I like Camel. It makes all the silly requests above trivial, and it gives me a mechanism for testing that I wired everything up correctly. Let’s look at a few ways to deal with errors that occur in your Camel routes.
Now we will cover the fun stuff for which we’ve been waiting. In this post, I’ll go over how to setup Sonar for a Java project that utilizes Ant for its build. I’ll go through the basic steps for installing and running a Sonar instance, and how to use a MySQL database for collecting metrics. Then I’ll go into some details around analyzing a Java project using Ant and Sonar. This involves writing Ant script, pointing to the source codes, analyzing the binaries, analyzing JUnit test cases, analyzing Ecl Emma coverage, etc.
In my previous post I covered the reasons why software quality metrics should be collected and why improvements to the code should be made based on those metrics. In this post I’ll be illustrating how Sonar can fulfill the job of collecting metrics and driving decisions.
Sonar goes beyond just collecting and displaying metrics:
Sonar can answer the following questions:
What are our most critical code quality issues?
Where is the highest concentration of code issues?
How many working hours will it take to fix the issues?
What does the metrics trend look like over the past year?
Sonar can be used to track work tickets assigned to team members.
In short, Sonar helps us analyze the situation, take actions, and quantify the improvement.
I want to share an experience that my colleague, Travis Klotz, and I ran into recently.
I was trying to manually test a Java web application running in debug mode. It was running really slow, taking several minutes to launch after the compile was finished. And when it did eventually start, using the application was very slow. Pages would take almost a minute to render. So Travis and I started trying to determine the cause. Continue reading →