One conference and four articles I found interesting in the last month.
CQRS pitfalls and patterns - Udi Dahan
I share the points from this presentation about overarchitecting simple applications when there isn’t a compelying reason for that. I’ve witnessed developers and managers using and promoting Domain Driven Design as the golden hammer to write all aplications, even simple CRUD-like ones. The speaker shares that eventually-consistent CQRS is not for that type of applications.
Althought this talk might seem about coding, it’s more about bussiness and designing software.
Trying to become a better developer by learning more about aviation
I have always been intrigued by planes. We started from the Wright brothers to planes flying by themselves. I have always been interested by software, procedures, and processes that keep planes in the air.
We, as software engineers, have a lot to learn from pilots. For example, “Aviate, Navigate, Communicate” is one of the principles pilots follow during incidents. Their number one priority is keeping the plane flying. We could take that principle to the software engineering world.
How to sabotage your salary negotiations efforts before you even start
Interviewing is another skill to master by itself. One thing I’ve found everywhere online is never say a number first. This article shows common mistakes and sample scripts when negotiating salaries.
Lessons learned as a software developer turned project manager
I really liked this one! I’ve been in teams where project managers have no idea about building software and they only focus on running meetings and other “ceremonies.” I wish all project managers in software companies had a development background. I know I’m asking for the moon.
Some quotes from this article:
“the most difficult challenge in a technical project is the communication between parties”
“the scope of the project and what needs to be done should be clear to everyone”
“don’t ever, ever, call your colleagues or developers resources or FTE’s (full time equivalent), they’re humans, not beans”
If you don’t believe in the career ladder, this one is for you. It contains a questionnaire to help taking the first steps into a different path. “being clear with yourself on what role you actually want work to play in your life is an important foundational step to exploring what’s next”
Voilà! Another Monday Links. Have you seen developers switching to project management too? Do you have any tips to negotiate salaries? Until next Monday Links.
I believe we shouldn’t discuss formatting and linting during code reviews. That should be automated. With that in mind, these days, I learned how to automatically format SQL files with Git and Poor Man’s T-SQL Formatter for one of my client’s projects.
I wanted to format my SQL files as part of my development workflow. I thought about a pre-commit Git hook for that. I was already familiar with Git hooks since I use one to put task numbers from branch names into commit messages.
After searching online, I found a Bash script to list all created, modified, and renamed files before committing them. I used Phind, “the AI search engine for developers.” These are the query I used:
“How to create a git commit hook that lists all files with .sql extension?” and as a follow-up,
“What are all possible options for the parameter –diff-filter on the git diff command?”
Also, I found out that Poor Man’s T-SQL Formatter is available as a Node.js command utility.
Using these two pieces, this is the pre-commit file I came up with,
#!/bin/shfiles=$(git diff --cached--name-only--diff-filter=ACMR)[-z"$files"]&&exit 0
for file in"${files[@]}"do
if[[$file==*.sql ]]then
echo"Formatting: $file"# 1. Prettify it
sqlformat -f"$file"-g"$file"--breakJoinOnSections--no-trailingCommas--spaceAfterExpandedComma# 2. Add it back to the staging area
git add $filefi
done
exit 0
I used these three options: --breakJoinOnSections, --no-trailingCommas, and --spaceAfterExpandedComma to place ONs after JOINs and commas on a new line.
2. Test the pre-commit hook
To test this Git hook, I created an empty repository, saved the above Bash script into a pre-commit file inside the .git/hooks folder, and installed the poor-mans-t-sql-formatter-cli package version 1.6.10.
For the actual SQL file, I used the query to find StackOverflow posts with many “thank you” answers, Source,
Voilà! That’s how to format SQL files automatically with Git. The command line version of Poor Man’s T-SQL Formatter is not that fast. But it’s still faster than copying a SQL file, firing a browser with an online linter, formatting it, and pasting it back.
Poor Man’s T-SQL Formatter might not be perfect, but with a simple change in our script, we can bring any other SQL formatter we can call from the command line.
After this trick, I don’t want to leave or read another comment like “please format this file” during code review.
Blindly following coding principles is a bad idea.
“Leave the basecamp cleaner,” “Make the change easy then make the easy change”…
Often, we follow those two principles and start huge refactoring sessions with good intentions but without considering the potential consequences.
Let me share two stories of refactoring sessions that led to unintended consequences and the lesson behind them.
Changing Entities and Value Objects
At a past job, a team member decided to refactor the entire solution before working on his task.
He changed every Domain Entity, Value Object, and database table. What he found wasn’t “scalable” in his experience.
The project was still in its early stage and the rest of the team was waiting for his task.
One week later, we were still discussing about names, folder structure, and the need for that refactoring in the first place.
We all were blocked waiting for him to finish the mess he had created.
Changing Class and Table Names
At another job, our team’s architect decided to work over the weekend.
And the next thing we knew next Monday morning was that almost all class and table names had been changed. The architect decided to rename everything. He simply didn’t like the initial naming conventions. Arrrggg!
We found an email in our inboxes listing the things he had broken along the way.
We spent weeks migrating user data from the old database schema to the new one.
These are two examples of refactoring sessions that went sideways. Nobody asked those guys to change anything in the first place.
Even there was no need or business case for that in the first place.
I have a term for these refactoring sessions: massive unrequested refactoring.
I believe in the “leave the basecamp cleaner than the way you found it” mantra.
But, before embarking on a massive refactoring, let’s ask ourselves if it’s truly necessary and if the team can afford it, not only in terms of money but also time and dependencies.
And if there isn’t a viable alternative, let’s split that massive refactoring into separate, focused, and short Pull Requests that can be reviewed in a single review session without much back and forth.
The best refactorings are the small ones that slowly and incrementally improve the health of the overall project. One step at a time. Not the massive unrequested ones.
Voilà! That’s my take on massive unrequested refactorings. Have you ever done one too? What impact did it have? Did it turn out well? Remember, all code we write should move the project closer to its finish line. Often, massive unrequested refactorings don’t do that.
In my two stories, those refactoring sessions ended up blocking people and creating more work.
These refactorings remind me of the analogy that coding is like living in a house. A massive unrequested refactoring would be like a full home renovation while staying there!
An emergency fund is enough savings to cover our essential expenses for some time. The longer, the better.
That’s the breathing room until you figure out something.
And it’s the difference between being picky about the next job or accepting anything to pay the bills.
3. Always be ready
Let’s always have our CVs updated. Stay in touch with our colleagues and ex-coworkers. Build our professional network.
Let’s always be ready for an interview. Have our data structures and “tell me about yourself” muscles in shape.
Interviewing is broken, I know! But let’s always be ready to leave.
Don’t wait for a layoff to establish an online presence and grow your network. By then, it will be too late.
Voilà! Those are my thoughts about layoffs. I learned that after losing a job, there’s always a positive change. That takes us out of our comfort zone. “Pastures are always greener on the other side,” I guess.
These days I reviewed a pull request in one of my client’s projects and shared a thought about reading database entities and layering. I believe that project took layering to the extreme. These are my thoughts.
For read-only database-access queries, reduce the number of layers in an application to avoid excessive mapping between layers and unneeded artifacts.
Too many layers, I guess
The pull request I reviewed added a couple of API endpoints to power a report-like screen. These two endpoints only returned data given a combination of parameters. Think of showing all movies released on a date range with 4 or 5 stars. It wasn’t exactly that, but let’s use that example to prove a point.
That project had database entities, domain objects, results wrapping DTOs, and responses. To add a new read-only API endpoint, we would need a request object, query, query handler, and repository.
Inside the repository, we would need to map database entities to domain entities and value objects. Inside the query handler, we would need to return a result object containing a collection of DTOs. Another mapping. Inside the API endpoint, we would need to return a response object. Yet another mapping. I guess you see where I’m going.
This is the call chain of methods I found in that project:
Three layers and even more mappings
And these are all the files we would need to add a new API endpoint and its dependencies:
That’s layering to the extreme. All those artifacts and about three mapping methods between layers are waaay too much to only read unprocessed entities from a database. Arrrggg! Too much complexity. We’re only reading data, not loading domain objects to call methods on them.
I believe simple things should be simple to achieve.
For read-only queries, the HODDD book uses two models:
Query Models for the request parameters, and
Read Models for the request responses.
Then, it calls the underlying storage mechanism directly from the API layer. Well, that’s too much for my own taste. But I like the simplicity of the idea.
I prefer to use Query Services. They are query handlers that live in the Infrastructure or Persistence layer, call the underlying storage mechanism, and return a read model we pass directly to the API layer. This way, we only have two layers and no mappings between them. We declutter our project from those extra artifacts!
We put the input and output models in the Application layer since we want the query service in the Infrastructure layer. Although, the HODDD book places the input and output models and data-access code directly in the API layer. Way simpler in any case!
Voilà! That’s my take on read-only queries, layers, and Domain-Driven Design artifacts. I prefer to keep read-only database access simple and use query services to avoid queries, query handlers, repositories, and the mappings between them. What do you think? Do you also find all those layers and artifacts excessive?
