What to look for when hiring a potential Adobe AEM developer

Adobe AEM is a hot product right now. Finding available, skilled talent is difficult, to say the least.  I get two to three messages on LinkedIn every week about project that is looking for someone with AEM experience. When assembling a team, you have a few options: use professional services consulting, partner with an experienced agency, or build a team of your own in-house.

Assuming you’re building a team in-house and you can’t find someone with AEM experience on their resume, what skills should you look for when hiring a developer to train as an AEM developer?  Developing in AEM is not difficult; however, there is definitely a learning curve around all of the underlying technologies (SLING, OSGi/Felix, JCR, etc), understanding best practices, comprehending all of the new terminology you’ll be bombarded with (DAM, CRX, MSM), and understanding CMS concepts in general.

Here’s a list of skills I look for when I’m building a team of developers who do NOT have AEM experience.  These skills truly lend themselves to molding a solid AEM candidate:

  • Servlet and JSP development  –  All of the templates and components in an AEM project are built using Java Server Pages (JSP), so 2-3 years experience with this is a must.  No JSP experience on the resume? Move on.

“No JSPs? Survey says? Bzzzzzzzz.”

  • CSS, Javascript, HTML – This is more for our front-end/HTML mark-up developers, but having your AEM developer with some CSS/Javascript experience is key, especially when we do AJAX calls or have to create custom Widgets using EXTJS. Also, having the ability to apply a quick style to the component instead of waiting for the Web Developer to do it only saves time for everyone.
  • AJAX/JQuery/EXTJS –  Adobe AEM pre-compiles published pages into static HTML, so dynamic content is pulled-in via AJAX – usually with a library like JQuery.  Additionally, EXTJS is used to create custom widgets for your editor dialogs. Experience with these is in my top 3 must-haves.
  • OSGi/FELIX – Scheduled jobs and services run as ‘bundles’ in the built-in Felix console.  While OSGi-specific experience is not a requirement, experience developing some type of service is required.  See below.
  • Web Services creation and consumption – Any dynamic content ingested from an external  service is usually accomplished by interacting with an service-layer running on an application server like Tomcat or JBOSS. A web services developer will be a key player on the team to assist with this interaction. You need at least one on the team with this skill.
  • CMS development experience – This isn’t a must-have, but understanding the concepts surrounding using a CMS versus traditional MVC (Model, View, Controller) development is helpful.  It helps with the learning curve of using a CMS.
  • Java Content Repository (JCR)/CRX – Getting away from the relational database mindset, where everything is tied together with some sort of key is a hard concept to grasp.  Not a must-have, but having someone on the team understand the underlying data repository who can evangelize it is a nice-to-have.
  • Other nice-to-haves – Eclipse IDE, Maven, SVN, Jenkins, Artifactory, Apache Sling, Lucene, Tomcat/JBoss, Apache web server, analytics tagging

 

Have you found a characteristic in your hiring practice that lends itself to become a great AEM developer? Share in the comments below.

Advertisements

Meet Adobe AEM’s Biggest Enemy: Joe Gunchy

Years ago, I sat down on my first day of a programming course at California State University, Sacramento when Dr. John Gwynn walked into the room carrying a wrinkled, brown paper bag full of books. Dr. Gwynn looked like a mix between Santa Claus and a panhandler. He had a shaggy white beard that was stained beneath his lower lip and long, grey hair poking out of his floppy Gilligan hat.  The room fell quiet as he stood at the front of the room, pointed to an empty chair, and recited this poem:

The semester has started but have no fear,
The student’s best friend Joe Gunchy is here.
Though loved by all, his brain has gone numb,
So stay on the ball and not be that dumb.

The dude was talking about an invisible student sitting in an empty chair!

Dr. Gwynn then explained that his invisible student will “ask all the dumb questions so you don’t have to.”   You see, Joe Gunchy was a complete idiot. He did everything wrong.  But, he made all the mistakes so we didn’t have to.   Throughout the semester, Dr. Gwynn would point to the chair and say, “Now Joe Gunchy might try to do it this way…“, then explain why Joe’s approach was wrong.  Then he would show us the best way to do it.

He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever. – Chinese Proverb (as told by Dr. Gwynn)

The good news is, after many years on campus, Joe Gunchy finally graduated. That bad news is, he got a job, is implementing his first Adobe AEM project and is making a mess of it.  Joe Gunchy is making all the mistakes so you don’t have to!

Sadly, Dr. Gwynn passed away during my senior year, but his lessons stuck with me. So, we’ll follow dumb Joe Gunchy as he works through poor planning, wasted hours, bad design, and ultimately a failed Adobe AEM migration. Then, I’ll show you the best way to do it.

RIP Dr. Gwynn. Long live Joe Gunchy.

From zero to coding your Adobe AEM project in less than 10 minutes

The world’s worst developer, Joe Gunchy (read more about Joe here) is leading a development team. He has 8 developers on the team, all running different operating systems and versions on their  laptops.  The guys wearing the skinny jeans and the hoodies are on OS X, the khaki pants/polo shirt guys use Windows, and “Charlie” uses Linux because he refuses to use an OS developed by “The Man”.   Joe has instructed everyone on the team to download and install the following things: Eclipse, Maven,  Maven plugin, an SVN plugin, Apache, an AEM Author instance, one Publish instance, Tomcat, and a Dispatcher to running in Apache.  No worries, he has 2 days for environment set-up scoped into the project – for each developer!  That’s 128 hours!  Each OS requires a different configuration, environment variables set in different places, and Charlie just can’t seem to get it running at all. It’s been a week for Charlie.

“Works on my machine” – Joe Gunchy

 

Zero to coding an AEM project in less than 10 minutes

Developer environment configuration and ramp-up time consumes many hours at the beginning of a project.  Differences in the developer’s hardware, development IDE set-up time and configuration, establishing connectivity to the source code repository all contribute to precious hours or even days wasted to get the team developing and building in a consistent, repeatable way.

 

What if you could go from zero to coding an AEM project in less than 10 minutes?  Without sounding too much like an ‘infomercial’, you can…

We exclusively use Vagrant images (link) for developing AEM projects.

“Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.”   Put more simply, Vagrant allows you to “create and configure lightweight, reproducible, and portable development environments.

We have one pre-configured Vagrant image with AEM Author and Publish instances, a local HTTP server with a Dispatcher, all connectivity to SVN established, and MAVEN configurations for building – all installed and ready for a new developer to check-out and start coding.  Vagrant runs on top of a variety of Virtual Machine providers, such as VirtualBox and is supported on Windows, OSX, Linux. Best of all, it’s free.

Typing two commands will get a developer ready to code within minutes.

$ vagrant init name/of/image
$ vagrant up

With Vagrant, vagrant up is all you need to work on any project, to install every dependency that project needs, and to set up any networking and synced folders so you can continue working from the comfort of your own machine.

Spent the time up front with your architect to get a single, configured development environment ready and you’ll save numerous hours throughout the rest of the project.

 Vagrant up!

 

Share your results in the comments below.

Develop your Adobe AEM project in this order!

Did you know there is a certain order that most successful Adobe® AEM project are developed?  While this might sound elementary to some,  deviating from this order will certainly increase your development time and you will ultimately lose efficiencies gained by using this order.

From start to finish, your AEM project should be developed in this order:

  1. Static mark-up development
  2. Content page template creation
  3. Site structure creation
  4. Content-managed components (no dynamic content)
  5. Navigation components
  6. Scaffolding creation
  7. User configuration
  8. Services integration (dynamic content)
  9. Content entry
  10. Site search
  11. Workflow configuration and development

Why does this order matter?  Let’s take a look…

 

1. Static mark-up is complete

“Get the mark-up ready or don’t start coding at all.”

Never, ever, ever begin an AEM project without approved creative and a majority of the static mark-up that represents the page content completed. Templates, scaffolding, and components all depend on this structure (or snippets of the mark-up) for their creation.   At a minimum, the mark-up for general content pages containing the navigation, hero-space components, header/footer, right-rail should be ready.  From these, you can create a majority of the components.  I’m less concerned about that one-off Investor Relations page you have hidden in your footer. Get the mark-up ready representing a majority of your site, or don’t start coding at all. There is too much re-work to be done if the structure changes, which greatly outweighs the delay of  simply waiting.

 

2. Content page templates

Which template will get the most usage?  Forget those hidden pages in your footer links for now. Let’s get to the meat of the site where most of the content will be created and develop those templates first.  Once these are created, we can start assembling your basic site structure.  You will use the mark-up created in step 1 to develop these templates.

Do you have too many templates available to your content authors? Be sure to read my upcoming article on Limiting the Number of Templates and Components.

 

3. Site structure configuration

Once you have the basic content page created, you can begin assembling the structure of your site to include language branches and individual section landing pages, like “Products” or “Partners”. There won’t be anything on the pages at this point, but the bones of the site begin to take shape.  We will cover the right way to structure your site to support multiple regions and languages in a future lesson.

 

4. Content-managed components

Always work on the most basic, straight-content managed components before anything that requires services integration or other dynamic content.  These are the easiest components to complete and can be divided up between the development team without much dependency on each other.  Completing these first also allows you to start content entry and functional testing of the content page template and basic components.

 

5. Navigation components

Navigation components are anything that allows the user to, well, navigate around the site. Duh.  These include the main navigation, utility links in the header, footer links, breadcrumbs, language branch switching components, and any ‘calls-to-action’ like buttons, links, lists of links, etc.  Primary navigation and breadcrumb trails should be driven off of the site structure itself, so having this structure in place (as shown in step 3) is key.

 

6. Scaffolding creation

The Scaffolding feature in AEM is under-used and should be used when you create multiple pages of a certain type over and over again.  News and press releases, product detail pages, partner profiles, are great examples of pages that should use Scaffolding. A press release always has a headline, sub-head, author, date, body copy, and likely some boilerplate information about the company at the bottom of the press release.  Forcing a content author to manually assemble a page by dragging and dropping individual components like Title, Rich Text, Image then editing those individual components is way too time consuming.  Scaffolding essentially gives them a single form to fill in, and the values of the form are distributed to the individual components (created in step 4) through code when the page is saved. The effort to create a Scaffolding page and dialog is minimal but the time saved by using it repeatedly is immense.

 

7. User configuration

“Create a Group for each major section of the site.”

Now that you have the basic structure of the site created (including indivual landing pages for major sections of the site), you can configure the Users and Groups that will interact with those sections.   Start by creating a Group for each major section of the site (Products, Resources, Press Releases) and assign the appropriate permissions for the group to allow adding, editing, and deleting pages within that branch of the site.  Create Users and assign them to the Group. So, if “Joe” is a content author who is in charge of creating Press Releases, add him to the “Press Release” group and you’re done.  This way, you do not have to assign permissions to each individual.  These groups will come into play when we configure the approval workflow in step 11.

 

8. Services integration

You now have a decent representation of the site built, and now it’s time to breathe some life into it.   Services integration refers to any content such as stock ticker, Twitter feeds, login and registration services, CRM integration, e-Commerce, Google Maps, etc that gets added to a page that doesn’t involve a content author.   Due to the static nature of an AEM site, where the pages are pre-compiled into static mark-up, the dynamic content shown on the page should be retrieved and displayed using AJAX after page load.  This involves creating intermediate services layer that can retrieve content either from the JCR, or pass through to external service providers to retrieve the content.

 

9. Content entry

We have pages, we have components, we have Scaffolding, and we have services. Now we can enter some real content into the pages.  You’ll need this content for step 10.   This is also a good time to Tag the pages to associate similar content across parts of the site.

 

10. Site search

I recommend doing this near the end of development cycle for two reasons: 1) your services layer is now complete and ready to integrate with either your external search provider or internal search service and 2) we now have actual content to crawl and display in our search results.  Creating search functionality earlier in the project forces you mock up fake results which is really a waste of developer time.  Use real content.

 

11. Workflow configuration and development

I’m lazy, so I love the integrated workflow feature in AEM and use it extensively to automate processes to approve, publish, replicate, ingest content, etc.  Content authors create pages and submit them to the approval workflow for review. Once the content is reviewed and approved, the approving group can  publish the content to the live site automatically by clicking the APPROVE button.  I will explain in detail how to create an approval workflow model in a future article. But think about all the manual steps you do repeatedly during content creation and publishing and 9 times out of 10, these tasks can be automated using workflow.

 

 

Adobe AEM the right way!

Welcome to “Adobe AEM the Right Way”

Since 2008, I have been involved in implementing many large-scale Adobe® AEM (previously CQ5) projects for numerous clients and industries, including the largest hotel chain in the UK, major international airlines, breakfast cereal manufacturers, major credit card companies, and professional sporting leagues at one of the largest global digital marketing agencies in the world.   When I’m not working on our agency-specific projects, I assist other corporations with their Adobe AEM projects through professional services consulting.

People only call professional services in two situations: at the beginning of a project when they’re just getting started, or when they’ve gone off the beaten path and have gotten stuck.  While it might be the shiny, flawlessly executed case study that wins new business for the agency, it’s saving the project in trouble that gives you the experience to execute your future project the right way, every time.  Here I will share all of the insider knowledge gained from these projects in crisis.   I will focus on best practices, performance, and usability so you can learn from other people’s mistakes and avoid them on your site.

Do you know…

  • Your AEM project should be developed in a certain order?
  • You can save 20-30% development time on your next AEM project by using a few basic tips on your current project?
  • 5 components you should create now to start your reusable library of components?
  • The best way to organize and categorize your sidekick and templates for increased author usability?
  • When to migrate content from an existing platform to AEM and when to start over?
  • The correct way to structure your site and Digital Asset Management (DAM) system to support multiple sites, languages, or regions?
  • How to tune your site for performance using a robust caching strategy and simple tips from Yahoo!?
  • The right way to retrieve and display dynamic content?

…you will.

Who should read this?

This site is for architects, IT managers, developers, and business analysts who are starting a new Adobe AEM project and want to do it the right way.