Posted on

UUID’s in Java

UUID’s are useful for making unique reference numbers of things.  In an ideal world these UUIDs are so long, they never collide.

The first place to discuss UUIDs would be RFC 4122.  The next part would be the wikipedia entry for a more concise version.

So why generate UUID’s?  One reason could be to generate a unique code to identify a particular PC (mac address?).  Another is to identify points in time (and can include the machine aka node’s mac address that created the UUID).

Further refs:

Java 6 api UUID entry
Blog that touches on UUID support in Java

Posted on

Lessons in Jasper (i)Reports

I had some great fun today playing around with iReport. I used Dynamic Jasper before iReport so it was an interesting experience seeing the platform first hand and seeing all the capabilities it offered via the properties panels in iReport for the various report components. It was interesting to see the layout capabilities of a Jasper report and how Dynamic Jasper worked with these.  A quick refresher, a Jasper report is split into different bands: Title, Page Header, Column Header, optional group headers, various detail bands, optional group footers, optional column footer, Page Footer, Last Page Footer, Summary, a No Data and a Background band. DJ follows closely to the Jasper specification & its capabilities. There are some things it can do better than iReport and some it cant.  The most obvious DJ benefit is the programatic table layouts, which is all through code and means your dependent properties are known in advance when you refactor a business class – you should be able to know when your report is going to break.  One issue I’ve had with DJ is that laying out components doesn’t always happen as beautifully as you’d expect.  Sometimes the width of columns totals is too small with unexplained wrapping or sometimes the layout is just wierd.   And there is no way of knowing until runtime that the seemingly simple change has broken the layout of your wonderful report. iReport on the other hand is comprised of datasources, sql or xml, and a jrxml template you design.  You aren’t fixed into a particular table structure, you can have multiple group variables on the same field without any kind of reprocrussions and the WYSIWYG editor and preview allows you to quickly play with report layout and styles and know what you are getting.  You can also start with a SQL query as your datasource to prototype and then at runtime inject a proper JRDataSource (the same DynamicJasper uses) – easy! But in the end of the day both of these compile down to .jasper files that Jasper Reports then fills in with your data and turns into these jrprint files – effectively a softcopy of your final report that you can turn into PDF or feed into a screen viewer.

Column Headers above Group Headers

One neat feature that Dynamic Jasper provides is the ability to put the column labels in a tabular format report below the group label via its setGroupLayout() method. I didn’t realise that the only thing that Jasper supports is having a column header band above the group header band. So in iReport, this means you cant have group title followed by the column headers. The way around this in iReport is that in your Group Header, you move the column headers into the last Group Header band you want.  That way each time the group header gets displayed, so too will your Column header, underneath the Group label.

SubReports for non-data areas

The other trick I learnt was that when generating subreports that dont normally have data in them, for example a Header and Footer section, you need to be change the subreports ‘When No Data’ value to something like ‘All Sections, No Detail’ so that it doesnt simply show a blank page when you preview it and include it in a master report.

One thing that doesn’t work is that you can’t put the total page count in a subreport since its evaluated at report completion time and the subreport is already processed by the time its done.

You can’t do that on Television

Layout wise the iReport stuff really starts taking a big lead over DJ.  The biggest case in point was the Sales Report dashboard demo that shows a 2 x 2 panel dashboard with a graph, table, pie chart and timeline chart.  The right column isn’t as wide as the left and there are also some neat tricks about using the REPORT_COUNT variable thats in each jasper report to limit the size of the dataset to do Top 5, Top 10 style reports.   The video is worth watching just so you know some other little tricks.  For example a foreground alpha channel percentage setting that gives pie charts a futuristic look is worth knowing about.

Pain in the bum Error Messages

Here DJ is better than iReport.   One frustrating experience I had with iReport is an error message about an expression with unexpected ‘+’ token.  I looked through all the expression fields I could find, searched the XML but couldnt find the place it was talking about.  In the end I started the report again from scratch and slowly recreated the components from the old one trying to eliminate which was the problematic component.  One thing that I noticed in the screencasts is that the designers use the Preview button frequently after any change that introduces a new variable, param or field, or datasource, or whatever.  There are a lot of silent traps you can get into and therefore a lot of checks you need to do across the way. Dynamic Jasper is a bit better since

  1. you are limited in what you can do somewhat, you aren’t generally going to get a compile error,
  2. the error messages are a little clearer but not always,
  3. you have the source code and its a little easier to understand.

Conclusion

iReport and DJ both offer various views into the Jasper Reports framework.  Its certainly knowing both.  Since you can combine them, you can use iReport to do the complicated formating and embed DJ reports.

References

http://www.opentaps.org/docs/index.php/Tutorial_iReport
http://www.jasperolap.org/plugins/espforum/view.php?group_id=83&forumid=101&topicid=13489
http://jasperfor
http://jasperforge.org/plugins/mwiki/index.php/Ireport/Tutorialsge.org/uploads/publish/ireportwebsite/IR%20Website/tutorials/Getting%20started%20with%20iReport/Getting%20started%20with%20iReport.html

http://jasperforge.org/plugins/mwiki/index.php/Ireport/Product_Tour
http://jasperforge.org/plugins/mwiki/index.php/Ireport

Posted on

Apache Commons reflectionHashCode builders

This was my response to this short post about using reflectionHashCode to implement your objects hashCode method dzone.com – overriding equals() and hashcode() – best practice

I’ve come to love the Apache commons builders over the last couple of years and use them where possible.  They avoid a lot of boilerplate.

Wanted to raise something with regard to the hashcode builder.  Today I watched a webinar, ‘Hash hash, away it goes’ (http://www.javaspecialists.eu/webinars/ and also described in text here: http://www.javaspecialists.eu/archive/Issue031.html) which was about writing hash code methods on your objects and using them as key objects in your HashMaps – and what happens when they arent written properly causing elements to not be retrieved from the map! 

One of the summary points of this article was that hashCode methods should be as fast as possible and one of the participants asked about the apache commons reflection hashcode builder.  Because the reflectionHashCode uses reflection it wont be the fastest possible implementation possible that you can write, so if you are concerned about performance, then you should consider using the other non-static implementation of HashCodeBuilder (granted not so dynamic).  The javadoc for HashCodeBuilder (http://commons.apache.org/lang/api/org/apache/commons/lang/builder/HashCodeBuilder.html) mentions reflection is slower than testing explicitly.

One thing you could do is if using dynamic fields though (say in a language like Groovy that allows fields added at runtime) is consider the fields which are immutable identity fields and have your hashcode builder just combine the hashcodes for those.  Presumably (and its a big presumption), your fields that are being added dynamically arent immutable and arent defining the identity of the object.  So the question is, do you really need to add those fields to your hashcode method in the first place?  You could then just define a hashcode builder on the immutable id fields that are in the base class and it shouldnt change how your HashSets and Maps behave regardless of dynamic fields added.  But if your new fields are added from subclasses to a parent domain, there is the appendSuper method on the HashCode builder

Posted on

An introduction to jQuery

Everybody loves jQuery – well except for me, I wasn’t much of a web person myself until recently – but recent teaching in Grails have shown how jQuery can up the ante on interactive elements in your webapps.  Its been around for a while now and I admit I’ve been late to the party here, but heres a great resource I found recently to get up to speed: http://www.ryanjeffords.com/blog/entry/jquery-a-crash-course-for-beginners-part-1-an-introduction-to-jquery

Posted on

Groovy for Java Devs

http://live.eclipse.org/node/888

This presentation talks about Groovy in general and goes thru the general Groovy constructs.  It also talks about the Groovy plugin for STS / Eclipse (though I’ll keep my IntelliJ thanks).  But its a great intro for anyone who wants a refresher of Groovy and also touches on the common frameworks (eg Grails) at the very end.

Posted on

CouchDB

Much like Neo4J I blogged about recently, there is also CouchDB from Apache.  CouchDB is a document database which isn’t a graph database like Neo4J, but what that exactly means I’m not sure yet – the purpose seem to overlap a fair bit. Both are aimed at the goal of no need to map objects to a relational schema and both claim to support the direct mapping of OO code to a DB entity.  Additionally both have REST api’s.

At this early stage, I will probably say that the Graph DB (Neo4J) provides data about the relationships between nodes, whereas the document DB (CouchDB) is a collection of documents with an ID and named fields – ok that is not much different from Neo4J other than the associativity type, direction and properties aren’t specified and each record must have a unique ID in CouchDB)

Unlike Neo4J, CouchDB is licensed under Apache License V2 so uptake will probably be easier for a non-open source project to consider.

More info for CouchDB is available in their Intro and Overview pages on their site. 

There was a recent BerlinBuzzwords conference which got mentions for interesting CouchDB and Neo4J talks.  Many twitter peers who attended tweeted to the fact that the presentations were interesting though they arent yet up.  The intent is that slides and vids should be up shortly for these.  It also inspired the InfoQ article that suggested that Couch could be used as a Personal Database, something that SQLite prevoiusly gets top honours for.

If this is true, then CouchDB sounds like a suitable small database for development uses that can scale up quite easily to other types.  The most important thing for me right now is that there is a Grails plugin to allow me to try it out. 🙂

Posted on

Hyperic HQU Monitoring

As a software dev who worked with an ISP, I learnt monitoring is a big thing.  Customers have availability metrics we need to meet, and more importantly customers are paying for a service.  When it goes down, they shouldnt have to be the ones to call it up to let you know, and they should also find out about an outage as early as possible.  Well before their bosses come knocking on their door.  And regardless of size, monitoring is still a big deal for any sized company and support team, and glad to say of interest at the company I work for now.

In the last 12 months I’ve been getting to know the Hyperic Monitoring Platform.  It has an open source community edition with an automatic free barrier to let small teams monitor what is important.  Additionally it is easily configurable via a web UI, which allows non-technical staff to add monitoring, setup alerts and that sort of thing.  Most importantly it is configurable via an api (or two).  There is the HQ API which is a REST api, and the Groovy API. 

I haven’t need to venture into the API at all to date but did recently get asked the question if HQ was able to export views and reports.  The good news after watching this vid is that you can.

The interview with Jon Travis reveals that the API is not only capable of exporting its information, but it also allows developers to add screens into their HQ installs.