OGGLOG

I've just released JCROM 1.3. There's lots of new features, and a few bug fixes. The highlights are:

• Lazy loading for child nodes, file nodes, and references (e.g. @JcrChildNode(lazy=true)) is now supported.
• Weak references by path are now supported via @JcrReference(byPath=true).
• Support for dynamic maps of child nodes, file nodes, and references.
• Enum properties are now supported.
• ...and more!

See the full list of resolved issues here. I'll be updating the user guide over the next few days to reflect the new features. In the meantime, you can download it and take it for a spin. The javadoc is here. Big thanks to everyone on the user list that helped out with testing, reporting issues, and requesting features!

Ben French, our sysadmin guru at VYRE, had a knowledge sharing session today, and one of the tricks he showed us was how to colour code the output from ls and format the prompt properly on the Mac terminal. It has made such a difference to my terminal windows that with Ben's blessing I'm going to share it with you here :)

First of all, set your Terminal window settings to something black & white, like the "Pro" setting. Then, add the following lines to .profile in your home directory:

export LSCOLORS=cxexcxdxbxfxfxbxbxcxcx
export PS1="\n\[\e[0;32m\]\w \[\e[0;38m\]\n-> "
alias ls='ls -lhFGv'

This gives you a nice prompt, and it will colour code the ls output, so that directories are green, executables are red, and so forth. Also, all directory names are followed by "/", all executables are followed by "*", etc. The following screenshot shows the result:

Thanks Ben!

This is a very short entry to tell you that I just finished reading a book recently published about the Google Guice framework: "Google Guice: Agile Lightweight Dependency Injection Framework" by Robbie Vanbrabant. I highly recommend it, it was great fun to read.

You can buy the book from Apress here (I bought the e-book).

Guice rocks! :)

I've released JCROM 1.2. This release has many cool new features, such as support for java.util.Map as a child node, array support for properties, auto-serializing (@JcrSerializedProperty), etc. But the coolest one has to be dynamic instantiation of objects from nodes (for programming to interfaces).

See the full list of resolved issues here. I've updated the user guide to reflect the new features (search for "programming to interfaces" on that page to get info on the dynamic instantiation). Go ahead and download it.

Big thanks to everyone on the user list that helped out with reporting issues and requesting features!

I've just released JCROM 1.1. This release has a few bug fixes, plus new features such as support for mapping node references, versioning support in the DAOs, better Spring support, etc. See the full list of resolved issues here. I've updated the user guide to reflect the new features. Head over to the downloads area and get it while it's hot! :)

I've just released the first version of JCROM (pronounced "Jack-rom"). JCROM (which stands for Java Content Repository Object Mapper, I'm not great at naming things) is a lightweight framework for mapping Java objects to/from a Java Content Repository (JCR). It relies on annotations only, so there are no XML configuration files involved. JCROM ensures that your objects are mapped to the JCR according to best practices, meanwhile abstracting the gritty details and making your code clean and readable. Last but not least, JCROM is open source, with an Apache 2.0 license.

Head over to the 2 minute intro for a quick overview, and then continue to the User guide if your're hungry for more detail!

I am aware of the ocm framework that appeared in Jackrabbit 1.4 (the old Graffiti project). I've read the documentation, but I have to admit I have not taken it for a serious test drive yet! I guess it is a lot bigger and more powerful (and heavier) framework, with query service and persistence manager with support for locking, versioning, etc.

I wanted to create a lightweight annotation-based alternative (I am not a huge fan of XML configuration files, although I do realise that they are sometimes necessary), that just handles the mapping of the object to and from nodes (as I found myself writing lots of boiler plate code to achieve this in my applications). Transactions, versioning, locking, are all out of scope, and handled outside JCROM.

Then I added the DAO support classes (with all the CRUD methods implemented), and extending classes can then add custom finder methods (usually just one-liners utilising the protected finder methods from the abstract class). Now I create applications with Jackrabbit and JCROM that require half the amount of code that my old Hibernate applications needed.

There are some discussions on the Jackrabbit dev mailing list regarding JCROM, and it is some people's opinion that using JPA (Java Persistence API) annotations might be a better approach for the future. From my perspective, I did not want to wait for a specification to change, I needed a framework for this right now. Something lightweight and easy to use. Couldn't find it, so I built it. But I am more than happy to look into adding support for JPA annotations to JCROM. I just need to read the JPA spec in more detail...so much to do, so little time :)

I'm building my first application based on Guice, and I must say I'm thoroughly enjoying it. The application is a webapp that uses Jackrabbit as content repository, JCROM for object mapping, Struts2 for actions, and Tiles2 + FreeMarker for the views. There isn't too much documentation around for Guice yet, so I thought it might be a good idea to share some of my findings. I'm going to start by showing you how I inject configuration parameters from a properties file into Java classes using Guice. If you don't know Guice, it might be a good idea to read the Guice User Guide first.

One of the things that all applications have to deal with is loading configuration parameters. Guice provides us with a really elegant way of injecting the configuration parameters once we've loaded them. This is what we need to do:

1. Annotate our Java class with configuration parameters it needs
2. Create a properties file for the configuration parameters
3. Modify our Guice module to load the configuration parameters and inject them

So let's start with the annotations. For this example, let's say we have an application that needs one configuration parameter: theme (this could be a theme for the look and feel of a web application). We have a Java class called ThemeManager, which needs to be configured with the theme name. It looks like this:

public class ThemeManager {

	private final String themeName;

	public ThemeManager( String themeName ) {
		this.themeName = themeName;
	}
	
	//... do stuff using the theme name
}

We need to add Guice annotations to the class, to show Guice that we want this parameter to be injected:

import com.google.inject.Inject;
import com.google.inject.name.Named;

public class ThemeManager {
	
	private final String themeName;

	@Inject
	public ThemeManager( @Named("themeName") String themeName ) {
		this.themeName = themeName;
	}

	//... do stuff using the theme name
}

The changes are in bold. Firstly, I've added an @Inject annotation to the constructor to tell Guice that it needs to inject values here. Secondly, I've added a @Named annotation to the themeName parameter, to tell Guice that it should inject a String with the name "themeName" here. Let's create a properties file, called myapp.properties, and add the themeName property:

themeName = default

The final thing I need to do, is to read the properties file in my Guice module, and inject the parameter. This is how I accomplish that:

import com.google.inject.AbstractModule;
import com.google.inject.name.Names;
import java.net.URL;
import java.util.Iterator;
import java.util.Properties;

public class MyModule extends AbstractModule {

	@Override
	protected void configure() {
		// bind the properties
		try {
			Properties properties = loadProperties();
			bindConstant()
                            .annotatedWith(Names.named("themeName"))
                            .to(properties.getProperty("themeName"));
		} catch ( Exception e ) {
			// handle the exception
		}
	}

	private static Properties loadProperties() throws Exception {
		Properties properties = new Properties();
		String name = "myapp.properties";
		
		ClassLoader loader = MyModule.class.getClassLoader();
		URL url = loader.getResource(name);
		if ( url == null ) {
			url = loader.getResource("/"+name);
		}
		properties.load(url.openStream());
		return properties;
	}
}

No black magic here. The line you need to pay attention to is in bold. After I load the properties, I bind the property value as a constant to everything that has been annotated with the name "themeName". Guice will therefore take this property and inject it into the ThemeManager class. The properties file is loaded from the classpath (I store my properties file in WEB-INF/classes), but you can load it from anywhere.

But it gets better! We can tweak the module code a bit to load all properties, whatever they're named, from the properties file and inject. Guice supports this out of the box via the Names.bindProperties() method. This is how it would look:

import com.google.inject.AbstractModule;
import com.google.inject.name.Names;
import java.net.URL;
import java.util.Iterator;
import java.util.Properties;

public class MyModule extends AbstractModule {

	@Override
	protected void configure() {
		// bind the properties
		try {
			Properties properties = loadProperties();
			Names.bindProperties(binder(), properties);
		} catch ( Exception e ) {
			// handle the exception
		}
	}

	private static Properties loadProperties() throws Exception {
		// ... this remains unchanged
	}
}

Now we can add more properties to the property file, and annotate more classes that need configuration parameters, and those parameters will then be injected automatically without you having to change a single line of code in your module class!

For example, let's say we have another class, RepositoryManager, that needs to be configured with a "repository path" parameter. We just need to annotate the class:

import com.google.inject.Inject;
import com.google.inject.name.Named;

public class RepositoryManager {
	
	private final String repositoryPath;

	@Inject
	public RepositoryManager( 
                @Named("repositoryPath") String repositoryPath ) {
	    this.repositoryPath = repositoryPath;
	}

	//... do stuff using the repository path
}

...and then we add the parameter to the properties file:

themeName = default
repositoryPath = /my/repository/path

And that's it. No need to change the module. Guice will now inject both configuration parameters.

Me and H.Stefan (who is currently setting up his blog site) spent the afternoon today installing Apache Roller on our Amazon Elastic Compute Cloud instance.

I've just finished moving this site from Wordpress to that Roller instance. Why, you ask? Well, for no good reason really. Just figured that since I'm a Java guy I probably should be using Java blogging platform for my site. It's also nice to have full control over the instance (previous version was hosted on wordpress.com): I can tweak the template design, use Google Analytics (which the hosted mode on Wordpress doesn't offer), etc. We decided to go with Roller, since it's being used for the Sun and IBM blogs, so it had to be pretty stable and feature rich.

The transition was pretty smooth, apart from the fact that Amazon EC2 does not offer static IP addresses, that is it cannot guarantee your instance IP address if you shut the instance down. I guess we just need to make sure that the instance stays up :)

Roller is quite simple to set up and use. Had some minor problems with installing themes (got this one from the roller themes website), but figured it out pretty quickly. One thing that annoys me a bit is the fact that Roller does not support multi-word tagging, but I guess they will sort that out soon. Also, I found it a bit strange that even though Roller has support for multiple blogs on one instance, it does not provide support for separate domain names for each blog. Therefore me and H.Stefan had to set up two Tomcat instances and Apache with virtual hosts in front (since we have separate domain names for our blogs). But all in all a good experience...I just hope this will lead to increased blogging activity on my side :)

I attended the first day of the JavaPolis 2007 conference in Antwerp today, after travelling from London via Eurostar, with the VYRE senior developers (Albert, Sindri, Mindaugas, and H.Stefan). We went to JavaPolis last year too, and really enjoyed it, so this is becoming a definite tradition.

The keynote speaker this year was James Gosling, the so called "father of Java". I was really looking forward to seeing the legendary author of the Java programming language, writer of the first compiler and virtual machine, in action. He took the stage wearing a T-shirt and jeans, with his trademark grey beard and big glasses.

His talk was a "tour of the Java landscape". He spoke about the fact that Java was all around us, and most of the time we don't even know about it. Some of the examples he mentioned were sensor grids on bridges in the US, moisture sensors used in vineries in the Napa valley, controllers at the CERN particle physics lab in Switzerland, and the London Oyster cards being Java SmartCards.

He also spent some time talking about JavaFX (which is Sun's answer to Adobe's Flex/AIR and Microsoft's Silverlight), and announced the release of Netbeans 6, Sun's IDE.

Towards the ends he took questions from the audience, but none of the questions or answers are really worth mentioning here.

I have to admit that I thought Gosling was far from being an impressive speaker. He digressed quite often, and seemed overly preoccupied with proud statements about Java being everywhere, without really showing us anything cool or interesting.

His laptop was running Solaris 10, and his slides were handmade using Java 2D. Quite messy and unimpressive. He should have at least hired a designer to go through his presentation, because honestly it looked like s***.

Following Gosling were a couple of demos from Sun. Now this is when it got really embarrassing for Sun. First up, to show us the new and powerful plugin architecture of NetBeans 6.0, a developer from Jasper Reports showed us the Jasper designer as a NetBeans plugin. First of all, his demo was really bad, all he did was tweak some parameters without explaining what they were, and then generate a pie chart with so many sectors that I could not read any of the labels. To make things really interesting, he was chewing gum through his demo, which made understanding his English a bit hard. When Gosling realised that this demo wasn't what he thought it was, he quickly cut it short. Good idea.

Second demo was supposed to really motivate the audience by showing how magnificent Java technology is and how it can be used outside the regular realm. This was done by a team of two, who's job description sounds really good: write cool stuff in Java and then travel the world showing it off. Apparently they were going to show us how JavaFX could be used to control touch screens, but they did not have time to finish that demo, so instead they just did it without the touch screen! The demo was basically a few images scattered around the screen, and I must say the audience wasn't exactly impressed as they demonstrated how these images could be moved, scaled, and rotated. The second part of their demo was using sunspots (Java based micro controllers) to control the movements of a small robot. The sunspots used had embedded gyroscopes and could therefore detect acceleration and direction. So when the Java evangelist raised his hand, the robot raised its hand (albeit quite a few seconds later). That was basically it (they did a similarly unimpressive sunspot demo last year at JavaPolis).

The main issue for me here was that no code was shown. That made a bad demo worse.

But things did get a lot better later in the day.

Next I went to see Bob Lee ("Crazy Bob") from Google give a presentation about Guice (pronounced "juice"), Google's lightweight dependency injection framework. After seeing this presentation, I'm definitely going to run some tests on Guice. I use the Spring framework a lot, and it is great for many things. However one of the things that annoys me a bit with Spring is the huge application context XML files, and the fact that I often end up storing configuration parameters inside the same XML file that declares injected dependencies. Guice seems to alleviate that headache nicely. Dependency injection is defined in pure Java code, making good use of Java 1.5 annotations. I'll post my findings on Guice here once I have had some time to play around with it.

David Nuescheler gave an interesting talk about "AJAX meets JCR". David is the spec lead of both JSR-170 and JSR-283, so he speaks with authority on the JCR subject. I was quite excited to see him speak, since at VYRE have been doing some research about using the Java Content Repository (JCR) specification to move away from our proprietary data model. We've been building web services (SOAP and REST) on top of JCR (we've used the JackRabbit implementation so far), and client APIs in JavaScript, ActionScript, etc. David's talk focused mainly on a projects being incubated by Apache, called Sling. Sling basically provides REST based web services on top of a JCR. David showed JavaScript API (that he called microJAX) for reading content from a JCR (writing was done using HTTP POST), and also handles all the heavy lifting (especially regarding security). He then installed a JCR repository, pumped in some content via WebDAV, and created a JCR-based WebLog in 15 minutes. Very cool stuff, and I recommend you monitor the Apache Sling project closely.

What was also interesting was the points that David made about the JCR standard. In his words, JCR combines the best of the database and file system worlds, and adds a layer of services on top of that (versioning, full-text search, multivalued properties, etc.). He went on to say "I will never use a relational db again". Quite a bold statement, but after using JCR for a few months now, I tend to agree that the data structures of my applications are now designed on JCR node types rather than as tables in the database.

I also saw IBM's Thomas Schaeck's talk about Web 2.0 Collaboration and Social Networking, a topic quite close to my heart these days. He talked about some of the collaboration issues that companies face today, such as hidden information being stored where only a few can benefit from it (file systems, email, etc.), lack of ways to discover people with certain skills within the organisation, and people simply not sharing information and knowledge they possess. He then went on describing the aspects of Web 2.0 that enterprises will benefit from, such as profile management, communities, media sharing, blogging, personalisation, mashups, feeds and services.

In my view, the social networking part of Web 2.0 (profiles, contacts, relationships) with tagging is the glue that binds all the other patterns (blogging, wikis, etc.) together, with search (with saved filters) being the primary interface to all content. IBM is obviously taking Web 2.0 in the enterprise seriously, but their solutions seem a bit fragmented and disjointed, and I got the feeling that to install an Enterprise 2.0 solution from IBM you would need lots of servers with lots of Websphere app servers and portals running many different applications, which means lots of hassle and lots of money. I think we need an application that encompasses what Enterprise 2.0 is all about, and is easy to set up and maintain. It looks like there isn't one on the market at the moment, so there may be a big opportunity there.

I fell asleep at the JSR-318 (Enterprise JavaBeans 3.1) seminar, not because it was that boring, but mainly because I was simply really tired. I then saw the "Future of Computing" panel with big guns like James Gosling, Neal Gafter, Joshua Bloch, and Martin Odersky. Unfortunately the panel was badly moderated in my view, and the discussions never really got off. Nothing exiting really came up, which is disappointing considering the names that were gathered for the panel.

Anyway, overall a great day at JavaPolis, lots of interesting people as always, followed by quality Belgian beer in the evening.

I've been reading the book "Getting Real", written by the good people at 37signals. They've adopted a no-nonsense approach to building webapps, as described in their own words:

"Getting Real is about skipping all the stu? that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential (and most of what you think is essential actually isn’t).

Getting Real is staying small and being agile.

Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.

Getting Real is about iterations and lowering the cost of change.

Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software. Getting Real delivers just what customers need and eliminates anything they don’t."

Now, this approach is not going to work for developing all types of software, but it is a good one for developing web applications focused on the user experience, and applies especially well to small startups. I'm not sure I agree that software design should always start with the user interface (these guys started as a design agency), but I agree that it is very important to understand how the user is going to interact with the application from the start. The ideal situation is to be building software to solve your own problems. You'll be a user yourself and therefore have full understanding and insight into the needs, and you'll have the passion to build great software to fulfill those needs. Unfortunately, most of the time we're building software to solve other people's problems - problems that we don't fully understand - and that's when things go wrong.

I've worked for a software company for almost 10 years now (gosh...time flies), and lots of things these guys have to say really strikes a chord. Keep the team small, less meetings about meetings, less features, get a working prototype running early...these are well known mantras. But the book also offers views that I found refreshing. I'll mention a few:

Constraints drive innovation. Working under tight constraints (budget, time, etc.) forces us to be creative - to find simpler, faster, easier ways of achieving what we want. This should also force us to focus on the things that really matter, the features that are really important, and ignore the rest.

Pick an enemy, take sides. This is so true. When you're building a product, don't look at what the your most successful competitors are doing and then try to copy that and add a few extra features (or lower the price). Pick a product that you don't like, and focus on doing things differently. Get rid of all the unnecessary crap. And most importantly, take sides. The best software has a vision. People are not just buying a set of fancy features, they are buying into an approach. Decide what your vision is, and run with it. If you try to please everyone, you won't please anyone.

Don't be afraid to say no to features requests! It is important to listen to your users, but if you always implement every feature your users ask for, the software will end up in a mess. Always say no initially to a feature request. If it is important, it will keep cropping up, and your users will not forget to remind you. That's when you implement the feature. But remember, once you add a feature, you're stuck with it. So choose your features wisely!

I'm not going to give away all the secrets that the book has to tell, instead I recommend you get your hands on a copy. Getting Real is a good, motivating read for anyone developing web applications, or thinking about starting up a company for that purpose. From here you can buy the PDF, buy the paperback, or read the book online for free.