Currency and BigDecimal
When deciding how to represent numbers (decimal or otherwise) we must first know if we are dealing with approximate or exact numbers.
I'm studying for SCJP - currently tackling a rather dull section on regular expressions. I've just noticed that the exam does not cover BigDecimal. I really don't understand this. BigDecimal is essential for any fixed precision decimal representation and calculation. Put another way: if you're not aware of BigDecimal, you can't effectively represent money in your program. Surely more useful than awareness of the \w, \s and \d regex metacharacters, no?
Maven release plugin
If you’re doing this sort of process manually it will take a while. Instead, it can be done by Maven using two goals – release:prepare and release:perform.
Properly versioning and releasing code can be fiddly if it's done properly. If you're not cutting corners, the process involves several steps. If these steps are performed manually the process is error prone and time consuming. I've often found it's easier just to cut a few corners. Why change the version in the Maven pom when you could perform all releases against a single SNAPSHOT version? Why tag the release build when you could probably work out the release version from a Subversion log? Why put release artifacts in a release repo when you can rebuild from a historic version?
I'm not going to argue that you shouldn't cut corners when creating a release build (all the same, just don't!). I will argue that the process need not be fiddly. So long as a Maven project is correctly set up, the whole thing can be done with a single command. Wire that single command up to Hudson, Jenkins, CruiseControl or whatever and you can create properly versioned release builds in a single click or (if you're so inclined) as a scheduled task.
At the heart of this is the powerful - though slightly inflexible - maven release plugin.
DbUnit and Jailer
Jailer will export data from a single table and all data that is related to it by foreign key references. This can result in far more data being scripted than expected.
The easiest way of creating datasets for DbUnit tests is often to script out values from a real database. This can be done with a few lines of code in DbUnit itself (see DbUnit FAQs) but it's easier to use a database tool that can export to DbUnit dataset files. Jailer is one such tool. In its own words:
Jailer is a tool for database subsetting, schema and data browsing. It exports consistent, referentially intact row-sets from relational databases. It removes obsolete data without violating integrity. It is DBMS agnostic (by using JDBC), platform independent, and generates DbUnit datasets, hierarchically structured XML, and topologically sorted SQL-DML.It's pretty easy to set up and has the advantage that it can flexibly script target data as well as all associated data necessary to satisfy foreign key constraints.
Just tell me what broke!
If I know that there’s a problem with one of my services, I don’t want a heap dump of my whole application nor do I want to guess what class may be causing the issue. I want something that just tells me what broke.
A few years ago, I heard about Glassbox, an automated troubleshooting tool for Java apps. The Google TechTalk seemed interesting (if a little long) and I was reasonably impressed when I plugged it into my own apps and it made (mostly) helpful suggestions on what may be causing bottlenecks. The tagline Just tells you what broke™ summed up the product perfectly. It didn't go into unnecessary detail regarding CPU cycles, memory usage, garbage collections, locks, threads and so on. It just showed nice helpful messages like "Slow operation. Cause: Slow database operation".
Unfortunately, this open source project has ground to a halt and there have been no new releases since 2008. And unfortunately it never quite managed to become completely usable. I've tried installing it again recently on a couple of different setups (WebSphere / IBM JDK 1.5 and Tomcat 6 / Oracle JDK 1.6) but never got it doing anything actually useful.
I now have a new project that I suspect is running poorly. There's probably some problem with the database or nested loops or something like that. I don't know exactly where the problem is though. I'd like to be able to use a tool like Glassbox to point me in the right direction. I don't need it to solve my problem for me. I just need to know what to do next. Do I run a heap analysis or do I check my database indexing? So I've been looking for replacements for Glassbox.
Web service testing with soapUI
soapUI is an essential free tool for testing SOAP and other web service protocols. It was particularly useful for testing the SpannersWS demo as it works well with WSS.
In my previous post regarding Spring-WS and Security I didn't mention anything about testing the resulting SOAP service. Particularly when it comes to secure services, it's vitally important to test. First, we want to make sure that the service is functionally correct - that it returns the correct results. Second, we want to make sure it is secure - that it refuses service to any request that does not meet our security requirements.
With regard to how we test, it's simplest to use some SOAP editor tool that lets us fiddle with the request and press a button to retest instantly. But ideally we want some programmatic test that can be included in the test phase of our build.
This post describes testing the now legendary Spanners WS demo with the following requirements:
- Tests must be functional - they test what the webservice does
- Security is tested
- Tests can be tweaked and rerun instantly
- Tests can be included in build process
The updated source of the Spanners WS demo including the tests described here is available to download.
Rounded corners in CSS / IE Tester
Fortunately IETester exists to quickly test web pages using the rendering engines of IE 5.5, 6, 7, 8 and the IE9 preview
Until Internet Explorer 8 is finally retired we still have to dick about with CSS to make IE behave properly. I'm not a CSS hacker but this is one trick that I suspect I'll need again at least until IE9 becomes standard.
CSS3 includes a property for rounded corners which was (sort of) adopted in Firefox, Chrome and Safari some time ago. I don't use it on this site - someone else did the hard work there using images for the corners. Presumably because CSS3 support was so poor at the time. This new CSS3 property can however be retrofitted to old browsers with a little work.
Spring-WS and Security
Security mechanisms are notoriously difficult to implement. By their nature they’re designed to prevent something from working unless it is used exactly correctly. Having Spring-WS do the heavy lifting makes our application far more likely to work and far more likely to be secure.
Spring Web Services (Spring-WS) are a neat way of declaratively creating SOAP web services using Spring with a minimum of boilerplate code usually associated with web services. I'd recommend it as the best way to create web services for a Spring application. When it comes to WS-Security (message encryption, authentication, signatures and so on) it is absolutely vital. It simplifies the very complicated business of securing messages to a few lines of declarative code.
I found the documentation provided by Spring on writing Spring-WS services and securing Spring-WS services very in depth and thorough but I've not yet found a good simple example app. This demo is about the simplest possible web service with the most standard WS-Security features enabled.
Test Coverage
Using code test coverage analysis we’ve got a new metric we can use to judge the quality of our code. As with any metric though, some discretion is required… I find that this sort of tool is mostly useful to catch dumb mistakes.
I've been looking a lot recently at JUnit (and TestNG) tests on a code base I'm not too familiar with. In many cases I was not convinced that the tests were adequate but it took a fair bit of investigation before I could be satisfied that this was the case. I would need to look at the tests, then look at the code it's meant to exercise, then try to work out in my head if the test covers everything it should. To make this process a bit easier, I've started running code coverage analysis using Emma. While this doesn't tell me if the test is good or not, it does show me at a glance how much code is covered by the test and exactly which lines, methods and classes are missed. This is usually a good first approximation for the quality of the test case.
I've found Emma to be a useful tool to run after I think I've written my test cases and got them working. Running the test case tells me if the code being tested works. Running Emma tells me if I've tested enough of the code. There's no point in having 100% test case successes if the tests themselves only exercise 50% of the code.
DbUnit
DbUnit is a JUnit extension targeted at database-driven projects that, among other things, puts your database into a known state between test runs.
I've decided to revisit the JUnit testing Hibernate and Spring recipe that I posted a while back. A problem with the previous recipe is that it did not provide any means to initialize the test database. This wasn't too much of a problem as I was mostly testing the data insert operations of the DAOs. I then used the same DAO to retrieve the newly inserted data and tested what came back. However this is no good if I don't want insert operations on my DAO (if it's to retrieve read only data from the database) or if I want to test the retrieval operations independently of the insert operations.
This post extends the recipe to include a means of initialising the database using DbUnit.