Ravi Pal aside from being a dear friend is someone I respect a lot; he is a technologist who wows me every time I talk about something. I recently came to know he has been writing a blog. I managed to read only 1 post till now and the very first post is amazing. I’d to share with […]
Guess what – you are stuck with it. So you can chose to let the underlying system handle it or you can chose to dictate how your traffic should flow.
Do not let the illusion of control dictate the performance. Be the one who needs to control and manage the traffic
We sacrifice the art of writing good and performant code for the short term gains of improving developer productivity.
Annotations can be powerful but only when used to add context and information to the code. But trying to configure your application with them is nothing less that a crime.
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.
Use Annotations to anything is is core to the application and defines the core structure of the application. Anything that would need a code change is okay to sit as an annotation. Rest everything else should be XML.
People will soon realize that your method works (because you succeed more often) and disrupting your process makes you ineffective and no one wants to do that.
It’s interesting how when we have to select a bunch of people to be on our projects we immediately latch onto the skilled ones whether or not they are motivated and the average guys are first ones to go even if they have a vested interested in our success (as they succeed along with us). […]
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 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….
When we see a problem on a project why don’t we take the time and fix it? Why do we get afraid of telling stakeholders that something has gone wrong and we need to course correct which might lead to an increased cost or a bit of a delay in schedule?