The journey was nothing but painful all along the way. It took me 5 hours to do what should have been a few minutes job. The Site developer had the code up and running in a HTML file in a browser and all I had to do was to make it work “as is” within CQ. It seemed like the Force of Nature were working against me and everything I did, had a problem in it. I finally got it up and running (the designs done match off as is still), but it was excruciating pain.
We have been trying to find the right mix of unit testing (Automated) in our project, and I have been looking at various options that Sling has to offer. This was done for development of AEM based projects. I tried to follow a few articles to help me get started and each one of those…
The AEM workflow problem is not really an inefficiency in the handover of HTMLs to CQ developers but how we should have been writing the code to begin with. We start here by seeing where the problem starts and how the code has been written. Unfortunately, we do see the OOTB Code in AEM as provided by Adobe itself are not coded to solve the problem. When I speak with Adobe they make it clear that these are reference sites and are to used as “Self-learning” but little did they know at the time that people will take this a practice and convert this into a culture.
This is a key step, and unless you get all those dependencies and if your project is brand new your project will not compile. If you are using an existing project it may just work if you have added those dependencies, but from experience as we dont compile JSPs those dependencies will not kick in. The code still works on CQ server because those dependencies are available at runtime.
What I want to do here is to compare 3 workflows and see what each one has to offer and what’s the best possible way to remove this inefficiency or improve productivity.
1. Follow the current set of technologies JSP-Java but change the way of working aka different set of tools, trainings and processes
2. Use Sightly ~ the new templating language pushed by AEM
3. Use other templating languages like handlebars or angular which are more platform agnostic and goes beyond just CMS and AEM (old school application development also fits)
In the current world of marketing, where we have clients who want to run campaigns in next 2 weeks, we can’t be slow in how soon we release code. You can only be relevant in the industry if you can move quickly, achieve the Continuous Delivery or at least reach a point when you can get releases out in production with a reasonable speed. Those days where releases used to happen once every 6 months are gone; or at least gone in the environment/market I am operating.
We have to have Self Testing Code, We have to Unit Test, We have to have feedback loops and We have to have feedback loop as soon as possible. There is no avoidance; let’s understand and embrace Or be extinct in a few years.
Not doing Unit Testing (again not saying “automated”), is like someone telling me – Kapil, you are driving to go to your wedding and you are late and now you have to drive faster. But, instead of putting in a few more airbags and giving you better set of wheels, better brakes; We are going to take the 1 Air Bag you have today and also replace your wheels with an older set. Now, go drive else you will not get married. What do you think I would do – Drive faster and risk my life or start driving even slower because I hope that my would be wife loves enough to know that I had no option but to drive slowly. Well you get the point – While I may get married, She is going to stay mad at me for a very long time for ruining her perfect day.
This is a part 2 of a series of articles I have just started to write. I spoke about Think Clients (SPA) and CMS and what sort of problems do we have. World Wide Web had a boost back in 2000s and then more recently there has been a huge surge on web frameworks and more…
Can a technology like Angular be used in the world of a CMS to solve the process problems where it just takes too long to get HTMLs from Site Developers into CQ’s templates and that too with a degree of quality that we are expected to deliver. This article lays down the foundation of what the challenges are and how it has started to impact our day to day life. The answer is not that simple, but at the looks of it, it seems we are using a technology to solve for a problem which is actually a people or a process problem. You can of course introduce a new component in the mix, but I still believe until people are ready to change, this new component wont do shit.
Cache (as defined by Wikipedia) is a component that transparently stores data such that future requests for data can be faster. I hereby presume that you understand cache as a component and any architectural patterns around caching and thereby with this presumption I will not go into depth of caching in this article. This article will cover some of the very basics of fundamentals of caching (wherever relevant) and then will take a deep dive into the point-of-view on the caching architecture with respect a Content Management Plan in context to Adobe’s AEM implementation.
Principles for high performance and high availability don’t change but for conversation sakes lets assume we have a website where we have to meet the following needs.
- 1 Billion hits on a weekend (hit is defined by a call to the resource and includes static resources like CSS, JS, Images, etc.)
- 700 million hits in a day
- 7.2 million page views in a day
- 2.2 million page views in an hour
- 80K hits in a second
- 40K page views in a minute
- 612 page views in a second
- 24×7 site availability
- 99.99% uptime
- Content availability to consumers in under 5 minutes from the time editors publish content
While the data looks steep the use case is not uncommon one. In current world where everyone is moving to devices, and digital there will be cases when brands are running campaigns. When those campaigns are running there will be needs for support such steep loads. These loads don’t stay for long but when then come they come fast, they come thick and we will have to support them.
For the record, this is not some random theory I am writing, I have had the opportunity of being on a project (I cant name) where we supported similar number.
The use case I picked here is of a Digital Media Platform where we have a large portion of the content is static, but the principles I am going to talk here will apply to any other platform or application.
I was that developer. Over course of last few years I have noticed that developers have moved away from doing anything in JS and they look upto Site Developers to write client side code – JS, AJAX and what not. I just told my team that we need to go back to the place where…
The other big takeaway was that working with mongo’s document structure is much more simpler to what RDBMS is. While was I working in mongoshell where I was using JavaScirpt to write code and later when i moved over to Java classes it was fairly simple. It was all about knowing 3 classes (if not 2) and you are done. Working with Maps (or Dictionaries) is pretty simple and using that knowledge in any language cant really be difficult. I was able to go back and learn JavaSciprt all over again and code a logic pretty quick.
a) Pretty quick to get going off the ground. I’d actually use this one instead of a mysql if i am trying a few things and need to use quick-start backend. (where in production – i don’t know yet)
b) If you are taking this course be mindful of not making judgements on the technology or how you’d want to use it especially model your schemas (or shall I say documents). Wait for the now or go and read more.
The objective I started off was pretty simple – “I have worked with RDBMS several times in my life and now I want to know what does a “Document Store” like MongoDB brings to the table”. I hear everyone that we should move over to a NoSQL but I am not convinced in my head what problems it will really solve for me – scale, no-schema or something else. More importantly, I want to form a POV as to what I should be using a RBMS vs. a “Document Store” like a MongoDB.
To sum it up in plain english – Not a lot of rope to hang off of; very little use cases to use and not exciting me as much.
For anything that is enterprise or platform(ish), I won’t go for this. The technical overhead that this framework and what it solves for is not worth the ROI of managing another framework. If I’d come across strongly types content-types, I would consider to use this. The ultimate tie breaker would be how how many of the content-types need to be displayed “as-is”. If all i had to show are several compositions of data (search or what have you) maybe not. But, definitely something to consider
CQ54 is not a a typical RDBMS where I can model a set of relationships in table and soon a pretty picture starts to present itself. CQ54 stores everything in its content repository (CRX) as nodes which follow an entirely different data model i.e. Hierarchical Structure. My experience with hierarchical databases has been with day…
The Language of Risk « The IT Risk Manager | Kapil | Scratch Pad | Java | Architecture | Design | Open Source
The language is important because it helps you think about the problem in the right way. This statement stuck a chord reminding me of an instance not so long ago . She asked me – “why did my project had just a couple of risks?” . She went on to probe us (my PM and…
I was a young budding developers when I was first introduced to the concept of Cache. My Senior Architect then told me Cache is a component that will magically store data so that future requests of that same data will not be to the Remote Server, and hence it will improve the performance of our…
I came across this article which I just want to share with others – I found this a good read. Java EE 6 vs. Spring Framework: A technology decision making process.
I heard about OSGI sometime early last year, but I did not care about it – it meant start thinking about a new way of development and deployment (thats what I heard from my friends) and I did not want to learn something else when Spring worked great for me. And, my colleagues who spoke…