An image of Berlin from Wikipedia

In September 2016 I’ve attended adaptTo() the third times in a row.

adaptTo() is a technical meetup amied at developers using the Apache Sling, Jackrabbit/Oak and Felix stack. 2016 was the sixth edition. Sessions also covered commercial implementations such as Adobe Experience Manager, with a particular focus on how these products leverage the architecture.
adaptTo() 2016 had 25 talks plus lightning talks and a playground session, and about 200 participants
The slides and source code (if applicable) can be downloaded from the adaptTo() web site: https://adapt.to/2016/en/schedule.html

Below are my take aways from the conference.

Devops

• Look into the slides on realizing unattended AEM installations for a lot of best practices and hints on how to setup your delivery pipeline. E.g. ready check, auto installation of packages, snapshots vs. text based server definitions, …
• AEM is assumed to be an antipattern for docker by many people, but there are helpers like external filesystem, mongomk, …
• At least 3-4 presentations mentioned Varnish as a possible alternative or addition of the good old Dispatcher. Look into Varnish when you run into limitations with AEM dispatcher and need more caching flexibility.
• It is worth having a look on the Jenkins multi-branch plugin in case you want to setup CI/CD for projects using Git or Github flows.
• For storage optimization reason, stop using nt:resource. Instead, use oak:resource when a file doesn’t need to be referenceable.
• If you feel that JCR is a good fit for your persistency requirements on any project, look into using Oak.
• Using binaryless replication, setting up separate authors on each market, separating ‘WIP’ DAM assets from public assets are good patterns to follow on large, multinational projects. See more complicated customer cloud scenarios in the Adobe Managed Services’ presentation. This session covered AEM version upgrade scenarios, too.
• As a rule of thumb, follow Adobe’s guideline on page loading response times.

IoT

• The industry is moving to container based deployments and monolithic applications are split up into separately runnable smaller pieces, microservices. OSGi and Apache Sling provide an ideal foundation.
• A natural fit for IoT, the OSGi programming model builds applications in components that can dynamically interact, thus offering the re-use of software components and dynamic updates. OSGi already covers many of the features required for an IoT platform since OSGi was originally created for the remote and dynamic management of a broad variety of home automation devices, residential gateways and embedded systems.
• The twelve-factor app methodology (manifesto) is worth familiarizing with on how to build software as a service. The 12 factors – among others – cover codebase, dependency mgmt, config, service integrations, lifecycle management, dev/prod parity, etc.
• Sling Remote Services could be a standard pattern for consuming (micro)services using the Sling Resource API, but the solution is still in PoC shape.
• OSGi R7 looks really cool. In addition to the evolution of the core framework, there will be features like clustering, config encryption, remote service support, …

Testing

• It is worth looking into the Sling HTTP Testing Framework, specifically the Hypermedia API Tools, which could be used as a tool for testing microdata (nesting structured data within HTML).
• AEM mocks are great helpers that AEM devs could use on AEM 6+ to deliver their tests faster, without having to write so many expectations prior to writing the relevant test code.
• Users of Sling Mocks should update to latest version to get the newest features (osgi r6, node type registration from CND, one liner adapter factory mocking, fluid/fluent syntax for building resource tree, etc.).
• In order to do TDD on AEM projects, you need the right tools, testing library and AEM mocking in place, otherwise you would focus on how to test rather than what to test. It is important to ensure that test setups cost virtually nothing.

Tools, helpers, accelerators

• Forget what you knew about AEM 5.x Social Communities (SoCo). AEM Communities changed the way how skinnability of the components is done, how UGC can be stored. (+ Handlebars support)
• The presented AC tools make the maintenance of ACEs clean and easy.
  • AC tool seems a better fit for unattended deployments (yaml, run mode support, install hook, …)
  • AEM Permission Management tool has a nice GUI with code completion, flexible grammar, exposed api
• Sightly was renamed to HTL (HTML template language) and the tooling support is growing (HTL compiler, Sling IDE support).
• Sling IDE tooling is under active development. Recently they’ve added HTL support.

PoCs, customizations, outlook

• The Sling Context Aware configuration was first released right after the conference. The presentation also gives a great overview of 3-4 existing AEM compatible solutions that are ready for use.
• Why should we integrate AEM with various JS libraries, frontend build systems if we have HTL, the good old client library manager, etc.? Why using React components, Handlebars templates, Thymeleaf in AEM? There were several sessions discussing these questions, and presenting solutions.
• Sling pipes are a viable alternative of solutions like Groovy console, for e.g. automated content refactoring.