React and Angular do not fit everywhere

Last few years have been fascinating with several front-end frameworks coming up. I am not going to compare them; neither am I going to talk about The Good or The Bad on them. The buzz words, the new technologies are so shiny that almost everyone I speak to today wants to work on the new stuff. And they also tend to believe that you can solve everything by just writing a front-end application, make some API calls and it’s done. The focus of this post will be that React, or Angular or Vue.js or anything similar is not one size fit all frameworks and Servers Side Code still has a place in this world.

The false security of Notifications

it’s like jumping into my car and every time i see the dashboard every light in there is brightly lighted up – to the point that one day i stop caring. eventually, someday something will fail – i just hope it’s not the day when I am driving to someplace in an emergency.

Most of our Notifications and alerting strategy is more than a brightly lit Dashboard. We cant any more tell what’s gonna fail when.

It’s a false hope we live with.

This part of my life is called “Chasing Quality”

We will see how this goes. But, for now the 5 rules for quality for me stand even today are:

– Deliver an artifact and ensure no one can find a defect;
– I can refactor the code knowing it won’t break anything;
– Code commits work like a charm and i can deliver code in environments quickly and with certainly;
– When I send this application to my dear friends in operation, they don’t hate and curse me;
– Quality meant, once my work is done it’s done

Making Thread Dumps Intelligent

When you have to spend hours and hours and mostly on night, weekends and your anniversaries you ask yourself what could I have done better during development to make this all go easy on me.

Thread Dumps are you best friend when a production application (Java) crashes and if you can enable it to tell you something about the application then thats something. Here I have explained how and have included a bunch of Java Code you can reuse.

Just Write away…

This article is my POV and what I want to tell the readers, and not what this reviewer thinks and what he wants to get out. This is not just an “edit” on punctuations and language but on my thoughts is my biggest deterrent on writing for any other publication and I realized that those 2 articles have been sitting in draft mode for 18 months now. It just gets “uuggghhh…”

Unit Testing in AEM (thinking loud)

Unit testing is an art – an art that doesn’t need to be confined to boundaries drawn decades back. AEM has made unit testing even more tough with its evolution and people are still trying to find the best fit aka what will work for them.

This article tries to explain some of my thoughts and what ways i would like to tackle unit testing in AEM and it’s not traditional in any ways.

I dont think there is one right way of doing it and this is just a beginning….

High availability design

Of course, eventually with many fixes over time you will eradicate a lot of cases that led to failures but it would have taken you so long and the reputation that the brand holds do dear is already damaged. You can chose to design for High Availability or you can chose to be just like Indian Railways – always delayed and always cancelled – a perspective that will i don’t think will ever be fixed no matter what they do.