Literal Testing – Justifying API’s

Literal testing

a BOF I went to listen handled about how one should create user documentation for a framework or API. The speaker (Peter Arrenbrecht)  had an interesting view on that: “For a certain use case, first write a tutorial and use a lot of examples, then from these examples build your API. This will result in an API with more understandable methods and classnames for your API.” To elaborate a bit. Because you write your tutorial with real examples your API comes forth of the tutorial which forces you to think about the way the API is build.

There are 2 approaches in this, code first and prose first.

in code first you write use case oriented tests which can be used as example in  tutorial. With a tool like bumblebee you can transform your usecase oriented tests javadoc to a tutorial document.

In prose first you write the documentation and with e.g. JCite you mark parts in your tests through annotations and when running JCite it will pick up the parts and put them in your documentation.

JCite is actually good for that. because when you start refactoring stuff in your code (hence also in your tests) and parse it again with JCite it will warn you about things that changed, somehow forcing you to take a look at the documentation of the parts you refactored/changed and triggering your brain to see if the change made sense.

see this post for links

Tools and stuff to remember from devoxx university

frameworks worth to checkout

kauri a restfull web application framework that does not need to run in an EE or servlet container.

lilly a HBase – solr based scaleable storage and retrieval system with versioning and mixing.

geomajas – a web mapping framework java backend – gwt frontend (I already knew that but hey.. advertisement )

SOLoist – design uml – compile to java and gwt as front end, kinda cool idea but I will not use it

tools

JCite – a java source code citation tool, very cool for creating manuals from your framework for developers

Bumbelbee – a tool that transforms your javadoc written in tests to a manual for developers

lzPack – installer tool

Hibernate & JPA 2.0

I started to follow this session after the break so missed the first part.

Just after the break of JPA 2.0 by Emmanuel Bernard, Karel Maesen pops up. He’s giving an introduction to Hibernate Spatial. It seems that development on it is increasing again. With on going implementation of support for more databases (like Ms SQL server and DB2) furthermore in hibernate 4 the rumour is that hibernate-spatial will be included in hibernate’s core. (making it bigger … is that good? perhaps it’s better to leave it seperate)

Karels talk was just an intermezzo. Emmanuel continues with Hibernate Envers. A framework for versioning your data. It can be used in any existing hibernate application. There will just be some more tables (the history tables). Add @Audit to your @Entity classes and they will be versioned. With every crud operation in normal hibernate the changes are transactionally applied to the history tables. This of course comes with a reduce in crud speed.

The versioning is done with revision numbers (like svn? ), the revision number sequence is stored in a separate table together with a time stamp and optional additional data defined by developer.

Envers provides some helper classes/queries to retrieve the historical data through the AuditReader. You can retrieve objects by revision number or between different revision numbers and/or dates. In the example this is all done with Java code, like the CriteriaBuilder in JPA 2.0

Emmanuel goes on about the Hibernate Validator which is actually now a standard in EE6 (the Bean Validation spec) now. It works in JPA entity persist, update, remove and on presentation layers like JSF 2, Wicket and more. There is even a project to integrate Bean validation with Flex. Hibernate will reflect the constraints to the database if you let it generate your tables.

One could easily creates is own specific validation annotations with Hibernate Validation. Validator also adds the possibility to add ConstraintMappings to it. More ongoing parts are the method level validations allowing you to use the validator not only for Entities. (Just like Bean Validation in EE6 I thought…

Another project is Hibernate OGM where the idea is to store indexes from Hibernate Search into Infinispan. They didn’t think it would work but why wouldn’t it… Hibernate Search would delegates the search to OGM which stores the results in Infinispan and afterwards Hibernate Search retrieves the results from Infinispan. This is an ongoing project. So not yet released. Note because Infinispan is used, this is automaticly distributed!