I have found some more usages of “special case pattern” coined by Martin Fowler and I have tried to name them rhetorically to make you remember – dummy, dead, and deformed.
In the beginning, I had a hundred problems creating beans, and spent hours to understand how spring works. I produce a lot of modules and libraries and separate everything by features. So, my applications don’t have a simple model-view-controller folder-set as I have hundreds or even thousands of classes in enterprise solutions. And, I was facing issues with setting up my libraries which were not in the application package in spring. By application package I mean where the Spring Application class resides in and all the sub-packages.
So, what happens when packages are outside? – the beans are not created, the spring annotations do not work! The solution is pretty easy but hard to find unless you are already familiar with “spring keywords“. But, the only way to get familiar with spring terminology is to become a master of it first! Anyway, so my goal here is to write tutorials which would be easy to find with common keywords like “my beans are not working in spring”.
I have been sharing book titles with my colleagues for over a year now – to help them increase productivity, building up habits, defining goals, etc. Unfortunately, I found a common pattern which is very ineffective – reading as fast as possible. Most of us tend to complete a book as if they were reading a story, or they are supposed to finish it. Here are some facts that we need to remember when reading these kinds of books:
Let’s say we want to add a full-text search engine to you application. Apache solr is a open source and popular choice for search engines. Now, I am going to share a simple architecture to synchronize data between the primary data-store (like mysql, mongodb, etc) and solr engine.
I am going to start writing a new series on “white hacks” that I frequently make as makeshift solutions to exigent problems. Many a times these solutions are not ideally the best approach to solve problems, but they are highly valuable when you are working on projects which have tight schedule constraints. People need the software first, then the performance.
These hacks will be found in the WHack Category.
The day I started learning refactoring, I fell in love with it. I got so addicted to it that I have developed a new habit automatically which not only makes refactoring an easy task, but also saved a huge amount of time when I write some complex algorithm or business logic. It’s a refactoring-integrated process of programming.
I am not a bookworm, no way! But I have interests in some subjects which led me to read some really really great books. So, I am starting a new series on the books that I have read and would like to recommend to my friends and colleagues. They cover different subjects such as Software engineering, Team management, Personal development, Psychology, Strategy and Management, autobiographies, etc.
There are some underlying theories behind software architecture and structure that every software engineer must know. On the face of it, a developer may not face a situation where this knowledge is applicable, but there are situations in development where one may have any idea where the problem exactly hides. If you really want to know why overdriving yourself and your team is not helping you to get things done and dusted, I recommend you to study some subjects.
I am borrowing an example from Tom Mitchell’s video lecture to share some ideas on how we can effectively and objectively use MAP. Here goes the equation for outcomes of coin flips where our coin may not be an ideal coin (that’s the only reason we are making an intelligent machine to find probabilistic outcomes):
θMAP = arg maxθ P(D|θ) P(θ) = (α1 + β1 – 1) / (α1 + β1 – 1) (α0 + β0 – 1)
How we choose β values from our previous knowledge of coin can have interesting facts.