Month: November 2011

100% code coverage, Hibernate Validator and Design by Contract

Code coverage in unit testing was one of the first things I learned in my software engineering career. The company I worked at taught me that you should have 100% coverage as a goal, but achieving it does not mean there are no bugs in the system. At that time, I worked at a company whose big thing was that they delivered very reliable billing software to telecomms operators. We used to invest as much time writing unit tests as we did writing the code. If you included unit tests, integration tests, system tests and acceptance tests, more time was spent testing than designing and implementing the code which ran in production. It was impressive and I have never worked with or for a company with that kind of model since, although I am sure there are many companies which operate like that. The other day I was thinking back to those days and reading up about unit testing to refresh myself in preparation for a unit testing course I'm attending soon (don't want the instructor to know more than me!) and I started to wonder about what kind of code could be fully covered during unit testing, but which could still contain a bug. While I learned that 100% coverage should be the goal, in over 10 years I have never worked on a project which achieved that. So I have never surprised to find a bug in code which I thought was "fully" tested. It's fun write whacky…

Read more

A really simple but powerful rule engine

UPDATE: Version 2.2.0, JavaScript (Nashorn) rules in the JVM - see here. UPDATE: Version 2.1.0, Java 8, Maven, GitHub - see here. UPDATE: Version 2.0 of the library now exists which supports Scala. It is a breaking change in that "Action" instances as shown below are now "AbstractAction", and the "Action" class is only supported in Scala, where functions can be passed to the action constructor instead of having to override the AbstractAction. Scala collections are also supported in the engine. I have the requirement to use a rule engine. I want something light weight and fairly simple, yet powerful. While there are products out there which are super good, I don't want something with the big learning overhead. And, I fancied writing my own! Here are my few basic requirements: Use some kind of expression language to write the rules, It should be possible to store rules in a database, Rules need a priority, so that only the best can be fired, It should also be possible to fire all matching rules, Rules should evaluate against one input which can be an object like a tree, containing all the information which rules need to evaluate against Predefined actions which are programmed in the system should be executed when certains rules fire. So to help clarify those requirements, imagine the following examples: 1) In some forum system, the administrator needs to be able to configure when emails are sent. Here, I would write some rules like "when the config flag…

Read more

JSR-299 & @Produces

I've been reading JSR-299 and I have a few thoughts. First, a quote from chapter 1: "The use of these services significantly simplifies the task of creating Java EE applications by integrating the Java EE web tier with Java EE enterprise services. In particular, EJB components may be used as JSF managed beans, thus integrating the programming models of EJB and JSF." The second sentence made my ears prick up. Do I really want EJBs to be the backing beans of web pages? To me that sounds like one is mixing up responsibilities in MVC. Sure, there are people out there who say that an MVC Controller should be skinny and the model should be fat (youtube ad). Perhaps I'm old school, but I prefer my JSF page to have a backing bean which is my view model and deals with presentation specific logic, and when it needs transaction and security support, it can call through to an EJB which deals with more businessy things. The JSR then goes on to introduce the @Produces annotation. I don't like that annotation and the rest of this blog posting is about why. When I need an object, like a service or a resource, I can get the container to inject it for me. Typically, I use the @Inject, @EJB, @Resource or @PersistenceContext annotations. In the object which has such things injected, I can write code which uses those objects. I let the container compose my object using those pieces and other beans.…

Read more

When tool strategy gets on your nerves

In the beginning A long time ago, before the days of code prettifiers like Jalopy, we wrote code and we tested code. That code was fun to write. And because it was fun to write, we were motivated to write it well and test it well. Welcome Jalopy It was around 2008 when a powerful tool which auto-magically reformatted our code was forced on us. In the beginning we rejoiced, for this tool added "TODO: Document me!" to all methods missing Javadoc (lots). It made it very easy to see where programmers had failed to document their code. The numerous TODOs were also great, because they made it impossible to find the real meaty stuff that still needed to be done. And in classes where our constants were defined, in a specific order so that it matched our documentation, Jalopy kindly reordered the constants alphabetically, making it hard to match code to the documentation. Enter Sonar A while later, realising that programmers program bad code even though Jalopy is present to save the world, we had Sonar forced on us. It is a great tool, because it tells us how bad our code is and what we need to change in order to make it good. Ahhh, what is "good" I hear you ask? Well that is defined by a central department who knows nothing of our projects and who doesn't care about architecture (where our real problems lie). The people who work there only want drones who all program…

Read more