Five ways to prepare for AEM6

So, AEM6 has the option of using MongoDB instead of TarPM, and Solr instead of Lucene. What does this mean to the developers who work with CQ5, those who are looking to get into AEM, and the architects who are designing and planning implementations?

First up, developers should be proactive and research Mongo and Solr. An ideal place to start is Mongo University, who offer free certifications at the base level delivered over a number of weeks via YouTube.

Secondly, go download the software – both Mongo and Solr are open source. We’ll not know the exact versions needed to use with AEM6 until it’s released, but the differences are minor anyway when it’s used for learning. Both are highly documented and popular with plenty of online and printed resources to help learn how to best use their services.

Thirdly, be prepared for a barrage of CVs inbound for AEM roles with only Mongo / Solr experience because of the way some recruiters work by pattern matching. Some of these will be great developers, so don’t turn them away for a lack of CQ skills – if they have any general Java web dev experience they’ll do well. Also expect some CQ developers to take this opportunity to leave the niche and enter a larger market (which also has a skills shortage as far as I can tell). It’ll take a while for this to start, but it’ll happen.

Fourthly, ignore Sightly. It pains me to make that recommendation, but it’s a proprietry language so you won’t be able to really prepare for it’s arrival. 

Finally, expect to do extensive reading on which option to use depending on the situation. It’s a very flexible system using Jackrabbit Oak to orchestrate the persistence and indexing. You’ll probably need to do your own benchmarking and tuning regardless of the general recommendations but it’s better to start with the most likely choice.


A reason to calibrate colours on OS X

I don’t really do much image manipulation but I’ve found a great reason to calibrate colours on OS X – to make it easier on the eyes when doing development. The machine I use most is a five-year-old Macbook Pro – nowhere near the display standard on modern machines but tolerable once configured right.

Open System Preferences, and go to Displays. The second tab is ‘colours’, which shows a list of available calibrations. I find the default settings way off on all three Macs I use, too bright and too low gamma making it look washed out.

Hit the calibrate button, enable expert mode, and follow the instructions. Near the end, there’s an option for gamma [I stick to 2.2], and then option for colour temperature. You can click on the labels or move the slider. For development, I find D50 [5000k] is soft on the eyes, whereas D65 [6500k] has a better representation of greyscales. Anything higher than this looks blue to me.

Whatever you do, make sure it’s comfortable for you. I find that unless all my displays are the same colour temperature and gamma, it’s unpleasant to move between machines. 

The POJO antipattern and data-centric design

The POJO antipattern is established when developers create plain java ‘objects’ that have no behaviour, only getters and setters. It’s an insidious misuse of object orientation and causes application code to be too data-centric in the name of data-modelling, abstraction, and persistence when there are many reasons to avoid this style of coding.

The car analogy.

In a POJO world, imagine an interpretation of a car. Remember that you can only use getters and setters. You might end up with something like:

Car car = new Car();

All this is very well and good, expect it isn’t. By error, it’s possible to set a speed without a driver or a direction. It also doesn’t actually do anything once it’s set, there’s no logic. It’s like a car without an engine.

The worst part about POJOs is that it’s utterly pointless writing unit tests for them, making them an antagonist in the world of TDD. They artificially change coverage percentages purely by their presence, and help hide other code that should be tested.

What should a car do?

A better model of a car is by it’s behaviour; a mode of transport.

Car car = new Car(location);, driver, passengers);

Less code, more validation, better logic, and it’s still can be persisted using serialisable variables if needed.

Why you should avoid the POJO antipattern

Using POJOs in modern code forces the application internals to be data centric, verbose, and obscures the logic and requirements that created the application in the first place.  Instead you should model the behaviour of the object – what it does rather than what it is. Avoiding the POJO antipattern will help in the long term as you model behaviour and not the underlying data, and enables use of advanced software development techniques such as the naked objects pattern for generating user interfaces.