AEM 6.5+ modernized Components
When I first started to work with AEM back in the AEM 6.1 days, I have to admit I was a little disillusioned with the few paltry OOTB components that came with very basic ExtJS-based “Foundation Components” that worked primarily in “ClassicUI”. AEM 6.2 was the first version that started really pushing a transition to the new “TouchUI”, even though it was already there in beta since CQ 5.6 and considered mature by Adobe (though not well-documented until much later leading to some hesitation in adoption) since AEM 6.1. As a result, we ended up with quite a mess in our codebase which we are constantly struggling and toiling to cleanup as best we can, but we’ve ended up in the following situation where way too many frameworks were mixed and matched based on different Devs/teams that worked on specific features (i.e. the high Technical Debt output situation with all the hallmarks of a “Feature factory”):
It was AEM 6.2 and beyond where TouchUI became the preferred Authoring experience and companies scrambled to build their Components to work well within both ClassicUI and (more importantly) TouchUI. Then, since AEM 6.3+ the platform introduced the concept of “CoreComponents”, which are basically a collection of open source general-purpose, highly authorable, reusable and extensible AEM Components available OOTB that will replace the legacy “Foundation Components” implemented using ExtJS which are now being phased out.
Having been elbow-deep in trying to migrate as many parts of our legacy AEM 6.1 codebase as possible to the latest and greatest AEM 6.5 platform capabilities, I’ve had plenty of “in the trenches” experiences trying to get things modernized. Recently, I was tasked with writing some backend and (optionally) frontend code to show how I would build a “fully modernized” AEM custom Component, the tempting if not perplexing “green field” conundrum for developers:
An example modernized component that can lookup Users from a specific 3rd party API could look something like the following hierarchy:
- Jackson databind POJOs (JSON/XML-to-Object mapping)
- UserLookupService (interface)
- UserLookupServiceImpl (with OSGi R7 Declarative Service annotations)
- UserLookupServlet (WebService that implements via @Reference)
- UserLookupModel – Sling Model (backend Component, rather than WCMUsePojo that implements via @OSGiService)
- User Lookup custom component (in “<APP_NAME>/src/main/content/jcr_content/apps/<APP_NAME>/custom/user-lookup” path)
- user-lookup.html (HTL/Sightly component structure)
- /js/user-lookup.js (client-side code could be vanilla JavaScript, framework-specific JS, SPA/PWA, Typescript and/or ES X syntax)
- /css/user-lookup.less (styling could be LESS, SASS or vanilla CSS 3+)
Aside from creating these backend elements:
- OSGI Service that can be used in multiple contexts
- Servlet to proxy API calls through
It is also useful to experiment with:
Read the rest of this entry »A closer look at Apache Mahout (JAVA Recommendation library)
There’s been a lot of changes to the Mahout library since it was first introduced through the Apache software foundation back in 2009.
I first looked at this project through the excellent tutorial on classifying and recommending Seinfeld episodes (perhaps not the easiest task of differentiating episodes, keeping in mind it was a show that prided itself on being “about nothing”). This really showed the strength of the suite of libraries and algorithms, which can be ranked and compared for performance and relevance more easily than ever in its current release.
Unfortunately, the folks involved in that project got a takedown notice to no longer provide the Seinfeld episodes’ full scripts that were being used to classify the episodes.
Looking for another alternative interesting dataset, I’ve looked through the following commonly used public data sources:
- Million Song Dataset: http://millionsongdataset.com/
- MusicBrainz: https://musicbrainz.org/
- MovieLens: https://movielens.org/
- Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Database_download#English-language_Wikipedia
- TVDB: https://www.thetvdb.com/api-information
- IMDB: https://imdb-api.com/
Seems like I’ve settled on just “” for now, but will likely look at unique ways to combine all of the above at a later date.
The scope of the problem will start out fairly modest; given a list of 10 users with very distinct tastes, can we recommend relevant new music to them (either by specific song, or, artist) that they’re likely to enjoy. It’s not like this is a new problem area, but I do feel there’s not been much innovation in this space for a while since the early days of WebJay, RACOFI & MyStrands to the “middle ages” of Songza, LastFM & Pandora and now into the modern era of Apple’s iTunes/Music offerings along with Spotify & YouTube pretty much having a three-party oligopoly on both ad-supported streaming and paid digital music (whether pay-to-download/own or subscription-to-stream).
The premise of this effort will be, given minimal inputs about a user, try to chart out
To DevOps or not to DevOps (its no longer an option)
Although I would tend to agree with 6 out of 7 points in the above opinion piece… shipping should not be optional and in DevOps its not a company nor “business” decision rather a delivery team decision (they’re mistaking Agile for DevOps there)… for instance Scrum insists on “potentially shippable” increments each 1-4 week Sprint/cycle, we chose 2-weeks as our timebox, but then the decision is deferred to the Product Owner as to whether or not the company desires releasing whatever has been completed.
7 DevOps Myths Busted
No offense to its author, Sara Miteva (she seems like an ambitious person with a passion for both Marketing & Technology from her recent bootcamps), but just like you would not take Medical advice from a really good painter, one should look to the trenches of IT for technical perspectives and ideas for solutions in terms of both the definition of DevOps, and how to acheive it:
Companies who entrust their delivery teams to build reliable Continuous Delivery & Deployment automated pipelines following the DevOps model that best suits the team, actually achieve single-piece flow (micro-sized, incremental, “non-existent risk” releases) rather than putting arbitrary wait times resulting larger/unpredictable/riskier batch sizes or ill-informed bureaucracy/red-tape in their way (which DORA and similar research initiatives have shown) are arguably > 200x more productive in terms of platform stability and change efficiency (as measured in Lead Times, arguably the most important metric other than not accumulating let alone paying down of Technical Debt):
https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
Sometimes folks removed from the work can reach indecision on whether its safe to proceed so better to remove the “pain of deciding” away and move that decision into the request process not release process, so if its been requested it goes when ready, if no longer needed it gets removed or flagged off…. summary “if its not important enough to ship immediately upon completion, its probably not going to have any noticeable impact on company performance, and so… should we really be working on such things”
As we know sometimes the answer’s still “yes that is worth working on” if only to avoid “Feature Factory-ism” (to make up a term), and of course to take a proactive TechDebt paydown approach whose benefits are the hardest to measure, but who is in a better position to decide those, the team implementing or someone 2-3 degrees removed from the work (or suffering/toil when things inevitably go wrong if TechDebt is allowed to accumulate)…
Some things I think we would pretty much all agree on…
the current code sucks (but “mostly works”)
every line in the entire codebase once started out as a PR at one point or another… or else it wouldn’t have made it into our git repo
if we had our way, we would change most of that code to be better (readable/maintainble, design patterns, UX/A11Y, Performance, Security, etc)?!
almost anything is better than what we have now…
we’ve all gotten better at coding/reviewing/fixing over the past 4 years
we have a tendency to as Wilson Philips said “Hold On for one more day” and squirrel away code, far too often suffering in silence, leaving big gaps in when the rest of the team can checkout progress and provide feedback
Continuous Integration is more than just an ideal to strive for, its become industry standard practice for a reason… everyone integrates what they’ve got all the time (daily at least, but more frequently is in fact better)
the opposite of “Continuous Integration” is “Sporadic Divergence”
to change the code and make it better, first you need a PR
if a PR is incomplete, we trust the reviewers to flag any of the more concerning imperfections, so that additional things can be improved… should be considered bonus if PR submitter points out some areas themselves they already know need further improving.
BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.