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.
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.
Handling null can be problematic in code organization and management. So, there are two very common patterns used by experienced developers now and then. One is “Null object pattern”, where you return an object which states a missing object, and another is “Special Case Pattern”. This article is to “How you can write effective objects for those patterns and why you should use them instead of returning null or throwing exceptions”
I read through many discussions related to Singleton Patterns, and different developers dislike it for different reasons. Not all the reasons make a pattern evil, because many of those reasons doesn’t really make your software really bad. I will be writing here each of the reason, and try to explain whether the reason is justified to call Singleton Evil:
I would enlist here the list of articles which explains why DI is important in designing software today satisfying a few goals like
- Code management
- System learning curve / Ambiguity Management
- API Dependency management
- Application Life Cycle
Interfaces were built to create public API and minimize client code to access fungible objects. I do use interfaces heavily for all the purposes you probably are familiar with. Today I would like to introduce a new and opinionated way I am using interfaces which helps me to create consistent structures of similar classes.
Yes, these are not the same terms, and I would say they are quite different in modern software architecture. It’s very frequent to see asynchronous and non-blocking terms are used interchangeably. Especially, when creating a thread to do some background task and letting the calling thread to continue without waiting for the new asynchronous thread.
But non-blocking now has a very deep meaning, better be said as “how much blocking our applications are”.