As engineers, we learn from the very beginning that bundling too many things together is bad. Be it writing a huge function or a class file, having thousands of lines. The same holds true for non-technical aspects such as project documentation, project tickets, etc.
I have been writing my projects' documentation as code for some time now and have recently discovered Mkdocs and its framework Mkdocs Materials.
It allows you to quickly and effortlessly generate your documentation as a website.
The large number of themes and plugins can help you add tons of functionality to your site, and the results look very professional.
* Disclaimer: When talking about DDD in this context, I mainly mean the use of an expressive and rich model.
During my career as a web-developer, I have noticed a repeating antipattern related to front-end code. For some reason most of the best practices that we usually use on the backend code are rarely applied in the front. This looks especially true for DDD and TDD principles.
I wanted to write this article after being onboard for some time now on the "AI hype train" as many of us are since the release of ChatGPT 3.5 in late 2022.
Even though I am a "tech-savvy" person and a developer, I quickly bit the bait and started imagining a completely automated world with AI agents understanding everything we want and performing any possible action etc.
Nowadays, it seems that everyone is working with LLM, and I wanted to get on that boat before it sails too far into the deep.
My idea of internet freedom is for users to be the owners of the data and software they use. To be able to run these tools at home and control who has access to the information they operate on and such.
We all have heard of the "cloud", this new promising compute power that provides out-of-the-box solutions and seemingly endless storage and scalability. IT specialists and regular users alike, we all have used it in one form or another - streaming services, cloud computing, file storage etc.
I have recently decided to try to improve the code base we have been working on for 4 months or so by installing some static code analysis tools. The two main libraries in question are PMD1 and Checkstyle - old classics of the Java world that still get regular updates despite their age.
Besides those two, we also have a more modern testing library called ArchUnit2 to add some architecture rules and guidelines to the project.
Summer was arriving, and we were all very thrilled to go on vacation. As usual, every preparation for the long trip abroad was done at the absolutely last possible moment.
One of the many things in the TODO list was to ensure that our 10 or so houseplants survive for 1 month without us watering them.
I wanted to write this article about an obvious antipattern that I keep encountering over and over again in my career. It is sort of related to the Anemic Design Anti-Pattern1 but on a scale beyond the development part of a project.
It also turns into a cocky semi-rant at the end (you have been warned).
I have worked with many junior team members over the past years and tried to help them get better on their job and also make sure the project we work on stays clean and neat. Sometimes I needed to explain architecture layers, sometimes dependency injection, other times code and framework specifics and so on.