I've been involved with Cognifide's work with AEM for the best part of a decade and as a result I've spent a fair amount of time over the years on finding and nurturing AEM developers. Initially this was about helping Cognifide itself to grow, but more and more we are finding that our clients also need help in building successful AEM development teams. Two things have become very clear. Firstly, fully grown AEM developers are pretty hard to find off the shelf, and, secondly, it takes longer than you think to grow them from seed.
It seems that, at least in the past, it's been pretty hard to get started with AEM, and, once you have got started, pretty hard to be sure that you're actually heading in the right direction. Over the last few years though, things have got a whole lot better than they used to be. The documentation
is much better than it ever was, and Adobe are focussing on helping developers to understand best practices and solve problems, through developer forums
and blog posts
. Companies like Cognifide are stepping forward and helping to build a vibrant community of AEM developers, through blogging and user groups and events. Our AEMHub event last year was hugely successful, bringing together developers and speakers from Adobe, Cognifide and other companies that specialise in AEM in an event where the content was real, detailed and technically interesting.
This year we're moving AEMHub
to a new (and very cool and funky) venue, but we're keeping the same very high standard of content. It's an "expert" conference, with presentations that are "by AEM developers, for AEM developers". But do you need to be an "expert" to attend? Does this conference have something to offer the new, or at least not so very experienced, AEM developer? I think the answer is "hell, yes", but in this post I thought I would try to justify that in terms of the kind of help that a budding AEM developer needs.
Help to grasp the fundamentals
AEM is a weird beast. It doesn't work the way you probably think it's going to work. If you've come here from the world of MVC web applications and relational databases it's going to seem a bit outlandish at first. However, this isn't because AEM is based on obscure, proprietary ways of doing things. It's actually based on a set of very clear open standards. You need to understand standards like OSGI and JSR-283. Above all you need to understand how HTTP works (yep, I mean really understand how HTTP works). And you really really need to 'get' REST. This year we are super-privileged to be hosting a talk by Roy Fielding on 'REST in AEM'. Roy is to REST what James Brown is to Funk1.
Help to separate the myth from the reality
Just because you read it on the internet doesn't necessary make a thing true. This applies to Adobe marketing as much as it does to everything else. AEMHub
gives you the chance to hear from people who have actually done stuff, real stuff, with AEM, rather than from people who want to sell you licences. We'll have talks like Jakub Otrząsek and Holger Marsen's 'Adobe Marketing Cloud Integration - Myth or Reality
' which will help you get beyond the marketing messages.
Help in sorting out the good from the bad
We all want to write beautiful, testable, maintainable code don't we? That's fine when we're working in an area where there are clear, industry accepted ways of doing things well. With AEM sometimes it's not so clear. There seem to be multiple ways of doing things and some of them are not as good as others. It doesn't help that the first examples of AEM code that developers are likely to come across are the Geometrixx example components, which are quite tricky to read and which haven't all been rewritten to reflect current best practices. At Cognifide, we've always had a strong focus on engineering quality and you'll see that on show at AEMHub. For example Tomasz Niedzwiedz will be showing in 'When Sightly meets Slice' how you can combine the Cognifide Slice framework with the AEM Sightly language to write code which is both beautiful and maintainable.
Help to understand what you can customise
AEM is very very open to customisation. You can change almost anything. This is partly the result of the way in which AEM is built upon open standards and frameworks. But of course to do that customisation you need to get to grips with some of these frameworks. We'll have talks like Mateusz Chromiński's 'Touching the AEM component dialog' which will get you started with this.
Help to avoid the pitfalls
Sometimes decisions you make when you're building an AEM site come back and bite you on the bum later on when you least expect it. You don't want this. A couple of things in particular spring to mind. The first of these is caching (and performance in general). You really really want to get this right. Jakub Wądołowski's talk 'When dispatcher caching is not enough' will look in depth at your options for caching. Another pitfall that can really hurt is designing an architecture that won't scale, often because you're trying to make AEM do too much work. Maciej Majchrzak, in 'Microservices architecture for AEM', presents an architectural pattern for integrating services with AEM which will help you steer clear of this particular problem.
Help to engage with people who can help you
Finally, and I think really importantly, AEMHub is about building up your own personal support network. It's a chance to meet some of the technical stars of Adobe and also to make contact with other developers who face the same challenges as you do.