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 been stuck with this issue and couldn't take it out of my head. Hence, ended up putting in some heavy hours solving it. But hopefully it is worth it. THE CONTEXT: I am implementing a MVC solution for an existing Sitecore 8.0 implementation which uses Castle Windsor for it's dependency resolver. Let's say a a tiny microsite. I had to implement a SPEAK app as per one of the requirements. Below are the 2 most important things behind why I ran into this issue in the first place: I needed to call a WebApi from my SPEAK app. 2. I decided to take MVC Area approach for my "tiny microsite" on a completely different sets of dlls For example the dlls for my "tiny microsite" are MyTinyApp.Web.dll, MyTinyApp.Business.dll whereas the main website's dlls are BigWebsite.Web.dll, BigWebsite.Business.dll etc.  WHY MVC AREA: The reason I took the MVC Area approach was to completely separate my "tiny microsite" so that I don't ...

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 ...