According To Ali

Starting with a monolith application is not really uncommon. But when the demand arises it is important to have a plan or path to go distributed either a Big Bang change or phased approach. I took the phased approach and the phases sort of happened naturally (without even knowing the right technical terms, BUT the concept and vision was clear). I will try to tell the story in this post. Although I will use "sample app" and the tutorials I prepared for this is a "sample app", I have faced the scenarios in real life few years ago and learned a thing or two. I am using Heroku for this "sample app" but this can also be implemented in AWS or Azure. I am sure there's always a better way of doing it, but this is how I have approached it.   Firstly, let's set some functional specification for our "sample app": The app will take request from the user (there's no restriction on how many users can request the app in a given second.) via browser....

Microservice Architecture is the new trend in the industry. When I thought of building a decisioning engine to work as my personal assistant I decided to design it as a swarm of Microservices. The most compelling selling point about Microservice Architecture which resonated well for me was its ease of maintainability and that's a big factor for a hobby project like this which has a lot of custom logic programmed into it and requires a lot of frequent changes. In theory, Microservice should fit right in. I tried doing it in the Monolithic way and I failed !!. So, will Microservices solve it for me? Let's find out. In this post I will do it in the "Software Engineering" way. Background: Few weeks ago I created a wifi controlled water system that I can control via my Home Assistant (using my phone even if I am on the other side of the planet, like Batman). And this is working great for me. Read about that here: Smart wifi controlled irrigation system . Bu...

I have read a bit on BDD. But none of the theory seemed appealing enough that I would be like “hai ! this is cool. Let’s do this”. Probably because I am a lazy tester or more appropriately test case writer (unit test that is J). What supposed to happen ? TDD. Write test cases first àdrive the development from there ( based on whatever model is chosen or appropriate). What actually happens ? As much as the next guy wants to throw theory and technical jargons I’m not really sure how many mid-scale project processes actually follow TDD throughout the entire development phase, let alone maintenance phase(where it’s most important) OR BDD for that matter. What I do mostly? The truth is (at least if I speak for myself) I have not followed through a proper TDD process. Yes there always exist some test cases that are written and thrown into build process so that we can use it in future. Even more sometimes we write the test cases after the feature is developed. But I ...

This is how I would think of an application at the very basic level: Now this works great. But one thing that is missing in this picture is Exception Handling . In many cases we pay very less attention to it and take it as "we'll cross that bridge when it'll come to that". We can get away with this as in many application as exceptions does not stop it from being in the state "is the application working" as long as we code it carefully and at the very least handling the exceptions in code blocks. This works. But we end up having try catch and if else everywhere and often with messy or no direction to what type of exception is to be handled where and how. Nonetheless, when it comes down an enhancement that depends upon different types exceptions, we will end up writing/modifying code every where, resulting in even messier code. I'm sure no one wants that. Even, in scenarios, a custom handler is not the answer either. Cause this w...

​ Okay so this is something I picked up from a recent developer group thingy and have been annoying my colleagues about this since then. Instead of thinking Sitecore as one project (MVC) solution why not treat it like a module/deliverable based implementation. I have created a sample solution which is here: https://bitbucket.org/ali_nahid/sckitchensync   The idea is pretty simple (Just like DDD pattern): You get a rough idea of the entire implementation like what are the  deliverable , functionalities etc etc and group them. Then just like the way you plan renderings on your page you plan bunch of different modules to implement in your solution. In my case I divided my sitecore implementation into the following modules: 1.       The core: This module contains the layouts and core renderings. In my case 1 standard layout that just defines the top level placeholders. Like header, footer, content etc. And a “_Ma...