Tomasz Fijałkowski's programming blog.
If I had to mention two things that can change the fate of the project, it would have been domain-driven design (DDD) and agile methodology. One of the most popular agile methodology is Scrum which provides product owner role. Unfortunately, I noticed that in many projects, the weakest link of the team was a product owner. This is not because they are generally bad product owners, it’s possible that in other projects they could do a great job. Although it seems obvious, not everyone realizes that the product owner should be the domain expert. Otherwise, She/He can be just a proxy to clients. This is a very uncomfortable situation. A team meetings, for example, often end up with the statement “I have to ask the client, can we finish tomorrow?”. This leads to a delay in the project and a decline in morale. To prevent that, developers skip the product owner and speak directly with the client. It degrades the product owner role to a secretary who adds meetings to a calendar, reserves the room, and so on. However, the essence of process is lost, DDD approach can’t by mixed with scrum methodology when product owner doesn’t known the core domain.
Microservice-base architecture gains in popularity every day. This approach has many advantages. The most important are independent deployments, shortened and simplified deploy pipeline, limiting communication between teams and technology freedom. That core advantages support quick delivery of new features. Microservices, of course, bring also a lot of challenges. Wrong approach to these can ruin the benefits of microservices. It’s also transform an architecture in some kind of a rotten architecture which I call distributed monolith or micro-monolith anti-pattern. Symptoms of that anti-patter are following situations:
Many times I heard that the microservice-based architecture is a solution of modularization issue. This is explained by the statement that monolith is a pure evil with the big ball of mud architecture. Microservices, in contrast, are well separated units of business logic. This biassed point of view is visualized by diagrams like
Understanding data model is sufficient to design good database schema in RDBMS (relational database management system). Having this knowledge you are able to construct normalized tables, add appropriate constraints and finally create indexes to speed up queries. In the world of NoSQL there are no simple solutions, rules and answers. That’s why we can only talk about patterns, tips and hints. MongoDB is not an exception. Besides the comprehension of stored data, deep understanding of an access pattern, how data is searched, inserted and updated by an application is needed.
In its early days, Java has a wide uses of checked exceptions. However, lazy nature of programmers triggered trend to abandonment checked exceptions to unchecked exceptions. This approach causes negligence an error handling and hiding side effects. Additionally exceptions catching is not checked at compilation level.
Java 8 supplies a lot new useful features, unfortunately also new misunderstandings and antipatterns are observed every day. One of that mistake is a wrong use of default method in interfaces.
Programming Chi (or Qi) is a blog about pitiful ideas, bugs and failures I notice every day. Fortunately, besides failures there are also a lot of successes and beautiful solution which I hope I will also write about.
In traditional Chinese culture, qì or ch’i (About this sound qì, also known as khí in Vietnamese culture, gi in Korean culture, ki in Japanese culture) is an active principle forming part of any living thing. Qi literally translates as “breath”, “air”, or “gas”, and figuratively as “material energy”, “life force”, or “energy flow”. Qi is the central underlying principle in traditional Chinese medicine and martial arts.