Another five interesting links I found in past weeks. This time, I found a recurring theme while reading Hacker News: burnout, caring and statisfaction.
The Forty-Year Programmer
This post contains all the insights of 40-years a lifetime working as a programmer. These are some of my favorites:
“Advice is expertise with all the most important bits removed.”
“The work is good. If it stops being good, you’ll stop too. If it stops being good, that’s an emergency: you need to take a vacation…“
“Don’t confuse work with your career. They’re not the same thing. They’re only barely related.”
This post reminded me about an ex-coworker that says that using the same skills, architecture, and tools is like being an architect who always design the same house over and over. What worked yesterady won’t work tomorrow, I guess.
“…Technology is changing all the time, but developers like to create software with the knowledge and skills they already have.”
Apart from social interaction, this is another challenge when working remotely. In the old days, we just tapped somebody else’s shoulders. These days of remote and asynchronous working, communication is more challenging. And we’re not teaching that when onboarding new hires. I still get plain “Hello” messages. I just ignore them.
This article shows a solution: “high resolution writing.” But, there’s another challenge with that. Often, we work with non-native speakers of the language used at work (pretty much, English everywhere). And, writing is a separate skill to master. Even for native speakers writing in his native language.
I’ve seen an increasing amount of Hacker News posts about burnout and job-related problems. These are some of them:
Tips to relearn how to care about my job?: “I got a high paying job at a recognizable tech company, but plagued with exhaustion and lack of motivation, which is killing me daily life. Anything you guys have done to dig out of a rut?”
How to deal with burnout and its consequences?: Speaking about burnout: “I really don’t know how to get over this and how to move past it. I feel quite literally incapable of working…I’m trying to figure out what my future even looks like and how to move past this and any advice would be really appreciated.”
A lot of good adive in there.
What “Work” Looks Like
I think we’ve all been to those meetings where nobody cares or even listens to what the organizer says. Especially, those where the organizer reads a document, he could have shared in the first place. This article shows an alternative to collaborative brainstorming. Spoiler alert: it’s away from computers. Read full article
Voilà! Another Monday Links. Have you experience burnout? How did you overcome it? What’s different about work after burnout? What are you doing to prevent burnout?
This book won’t teach you how to write a unit test step by step. But, it will teach you how unit testing fits the larger picture of a software project. Also, this book shows how to write integration tests and test the database. These are my takeaways.
1. What is a unit test?
“The goal of unit testing is to enable sustainable growth of the software project.” “It’s easy to fall into the trap of writing unit tests for the sake of unit testing without a clear picture of whether it helps the project.”
A successful test suite has the following properties:
It’s integrated into the development cycle,
It targets only the most important parts of your codebase: the domain model,
It provides maximum value with minimum maintenance costs.
A unit test is an automated test with three attributes:
It verifies a small portion of behavior (a unit),
does it quickly, and,
in isolation from other tests
There are two groups of developers with different views about “isolation”: the London school and the Classical school.
For the London school, isolation means writing separate tests for separate classes. If a class has collaborators, we should test it using test doubles for every collaborator.
On the other hand, for the Classical school, it’s not the code that needs to be tested in isolation, but the tests. They should run in isolation from each other. It’s ok to test more than one class at a time if the tests don’t affect others by sharing state.
“A test—whether a unit test or an integration test—should be a simple sequence of steps with no branching”
A good unit test has these four attributes:
Protection against regressions: “Code that represents complex business logic is more important than boilerplate code.”
Resistance to refactoring: “The more the test is coupled to the implementation details of the system under test (SUT), the more false alarms it generates.”
Fast feedback: “The faster the tests, the more of them you can have in the suite and the more often you can run them.”
Maintainability: “How hard is to read a test” and “how hard is to run a test.”
Types of Code by Complexity and Number of Dependencies
There are four types of code:
Domain logic and algorithms: Complex code by nature
Trivial code: Constructors without parameters and one-line properties
Controllers: Code with no business logic that coordinates other pieces
Overcomplicated code: Complex code with too many dependencies
Write unit tests for your domain model and algorithms. It gives you the best return for your efforts. Don’t test trivial code. Those tests have a close-to-zero value.
“Your goal is a test suite where each test adds significant value to the project. Refactor or get rid of all other tests. Don’t allow them to inflate the size of your test suite”
3. What is an integration test? And how to test the database?
An integration test is any test that is not a unit test. In the sense of verifying a single behavior, doing it quickly and in isolation from other tests.
Write integration tests to cover the longest happy path and use the same code that the “controllers” use.
Before writing integration tests for the database:
Keep the database in the source control system. It keeps track of changes and makes the code the single source of truth
Make reference data part of the database schema
Have every developer roll a separate instance
Use migration-based database delivery. Store your migrations in your version control system.
When writing integration tests for the database:
Separate database connections from transactions. Use repositories and transactions.
Don’t reuse database transactions or units of work between sections of the test. Integration tests should replicate the production environment as closely as possible. This means the Act part shouldn’t share connections or database context with anyone else.
Clean up data at the beginning of each test. Create a base class and put all the deletion scripts there.
Don’t use in-memory databases. They don’t have the same set of features. Use the same database system as production.
Extract technical, non-business-related parts into helper methods. For Arrange parts, use object mothers. And, for Assert parts, create extension methods for data assertions, like, userFromDb.ShouldExist().
Test only the most complex or important read operations. Forget about the rest.
Don’t test repositories directly. Test them as part of an overarching integration test suite.
Voilà! These are my takeaways. Although this book has “Unit Testing” in its title, I really liked it covers integration tests, especially testing the database and data-access layer. I’d say this isn’t a book for beginners. You would take more out of this book if you read The Art Of Unit Testing first.
If you want to read more about unit testing, check my Unit Testing 101 series where I cover from what unit testing is to unit testing best practices.
Ready to upgrade your unit testing skills? Write readable and maintainable unit test with my course Mastering C# Unit Testing with Real-world Examples on Udemy. Learn unit testing best practices while refactoring real unit tests from my past projects. No tests for a Calculator class.
If you’re new to Domain-Driven Design, this book is a good starting point. It’s a “hands-on” book. It walks through a sample marketplace for ads. It shows from what Domain-Driven Design is to how to evolve a system. Also, it contains a couple of chapters with a good introduction to Event Sourcing. These are my takeaways.
DDD and Ubiquitous Language
The main point of Domain-Driven Design (DDD) is sharing the domain language between domain experts and developers in meetings, documentation, and even in code. That’s what we call a “Ubiquitous Language.”
In our code, we should make all domain concepts explicit and express intent clearly. For example, in a software system to register Paid time off, what do StartDate, EndDate, and HalfDate mean? Does StartDate refer to the last day at work or the first non-working day? What about: FirstDayNotAtWork, CameBackToWork, and LeftDuringWorkday?
A ubiquitous language makes sense in a context. For example, a product doesn’t mean the same thing for the Sales, Purchasing, and Inventory departments.
Therefore, we should avoid God-classes like Product or Customer with properties for all possible views of the physical object, since not all properties need to be populated at a given time.
Does your architecture make you cry too? Photo by K8 on Unsplash
Onion Architecture and CQRS
This book advocate using the Onion Architecture and Command-query Responsibility Segregation (CQRS) when implementing DDD.
When following the Onion Architecture, the Domain is the center of everything, and everything depends on it. Application services and Infrastructure are layers around this core. Apart from standard libraries and some base classes, the Domain shouldn’t have any references.
“A good rule of thumb here is that the whole domain model should be testable without involving any infrastructure. Primarily, in your domain model tests, you should not use test harnesses and mocks.”
CQRS distinguishes between write and read operations using commands that mutate the system and queries that return the system state.
CQRS commands and queries flow
To implement CQRS, we can use database-mapped domain objects to mutate the system and SQL queries to retrieve the system, ignoring the domain model.
DDD Mechanics
To implement a domain model in code, DDD has some recognizable types of objects like entities, value objects, events, and services.
Entities should have an Id, accessible from the outside. IDs are database unique keys or GUIDs. We shouldn’t change an entity by changing its properties from outside the entity.
Value objects should be immutable. Two entities are the same by their identity but value objects by their value. To validate entity invariants, we can use a EnsureValidState() method.
Events are reactions to executions of commands. Events represent data in commands and other details from the changed entity, like the Id. Events should only contain primitive types. With events, we can notify changes in one part of the system.
Application services accept commands and use the Domain to handle the operation. An application service is responsible for translating primitive types to value objects. Often, all application services follow a similar script: they retrieve an entity from the database, mutate it and update the database.
Aggregate Roots work like a parent entity that changes its state as a whole. We should only reference, access, and manipulate child objects of an aggregate through the aggregate boundary.
Queries, Repositories, and Databases
“A domain model exists on its own, and it is designed to deal with business rules and invariants, and not to deal with the database.”
There’s a distinction between repositories and queries. Repositories deal with the aggregate state. In a ClassifiedAdRepository, we only should get ClassifiedAds. For all other data access, we should use queries.
We should write queries using the Ubiquitous Language too. For example, let’s write GetAdsPendingReview() instead of GetAds(ad => ad.State == State.PendingReview). And we can access the storage directly on our query handlers. That’s fine.
For example, this is a query to return active classified ads. We can put it inside the API layer directly,
publicstaticclassQueries{publicstaticasyncTask<IEnumerable<PublicClassifiedAdListItem>>QueryPublishedClassifiedAds(thisDbConnectionsomeDbConnection,QueryModels.GetPublishedClassifiedAdsquery){awaitsomeDbConnection.QueryAsync<PublicClassifiedAdListItem>("Plain old SQL query",new{State=(int)ClassifiedAdState.Active,PageSize=query.PageSize,Offset=Offset(query.Page,query.PageSize)});}}
Voilà! Those are my takeaways. I’d say it’s a good book to learn about DDD for the first time. There are things I liked and didn’t like about this book.
I liked that the book contains a practical example, a marketplace for ads, not only theory. If you want to follow along with the code sample, read these chapters: 4, 5, 6, 7, and 9. Skip most of chapter 8 if you already know how to set up EntityFramework. Skim through all others.
I liked how the sample application doesn’t use interfaces just for the sake of it. I’ve seen so many single-implementation interfaces to only use a dependency container and test it with mocks. And I also liked how query handlers use SQL statements directly instead of using another layer of indirection.
But, I didn’t like that the sample application ended up with “application services” instead of “command handlers.” I was expecting a command handler per each command and API method. The only sample application service has a huge switch statement to handle every command. Argggg!
Last month I followed the NDC Conference on YouTube. In this Monday Links episode, I share some of the conferences I watched and liked. I don’t know why but I watched presentations about failures, aviation disasters, and software mistakes. Well, two of the 5 links aren’t about that. Enjoy!
Improve working across time zones
Prefer document-based over meeting-based documentation. Only schedule meetings for discussions and have a clear agenda for everyone to review before the meeting. After the meeting, share the conclusions with people in different time zones who couldn’t join. Read full article
Mayday! Software lessons from aviation disasters
This is a conference from NDC. It shows two case studies from aviation disasters and how they relate to software engineering. For the first case study, after an incident, a security expert asked his team these questions to identify the cause of the incident:
How can I prove myself wrong?
What details might I be ignoring because it doesn’t fit my theory or solution?
What else could cause this issue or situation?
Experts traced the root of the incident ten years before the crash: counterfeit parts. This makes us wonder about counterfeit code: code we copy from StackOverflow, blogs, and documentation. We’re responsible for every line of code we write, even for the ones we copy and paste.
The second case study teaches us some good lessons about communication.
Failure is Always an Option
From space accidents to the British Post Office to a Kenya money transfer company, this talk shows how new businesses and branches of Science come out of failures and unanticipated usages of systems. Inspired by and contradicting one line in the Apollo 13 movie, “Failure is not an option.”
This talk claims that the single point of failure of modern cloud-based solutions is the credit card paying the cloud provider. LOL!
Hacking C#: Development for the Truly Lazy
This talk shows a bag of tricks to make code more readable. It shows how to use C# extension methods to remove duplication. Also, it presents the “Commandments of Extension Methods:”
No business logic
Keep them as small as possible
Keep them generic, so you can use them with any object
Keep them portable
Use them where there is boring and repetitive code
Make them useful
Ah! I learned we can make indexers receive multiple indexes. Like something[1, 3, 5].
Programming’s Greatest Mistakes
I had a coworker that always said: “Nobody is going to die,” when somebody else was reluctant to change some code. It turned out we weren’t working on a medical or aerospatial domain. But often, oops cause businesses to lose money. I bet you have taken down servers because of an unoptimized SQL query. That happened to a friend of a friend of mine. Wink, wink!
It starts by showing one stupid mistake the author made in his early days using a sarcastic name for one of his support tools. The support team ended up shipping it to their clients. Y2K, a missing using in a mission-critical software, null, and other mistakes.
Voilà! Do you also follow the NDC Conference? What are your own programming’s greatest mistakes? Don’t be ashamed. All of us have one. Until next Monday Links!
So far we have covered some of the most common LINQ methods. This time let’s cover three LINQ methods that work like set operations: Intersect, Union, and Except.
Like the Aggregate method, we don’t use these methods every day, but they will come in handy from time to time.
1. Intersect
Intersect() finds the common elements between two collections.
Let’s find the movies we both have watched and rated in our catalogs.
varmine=newList<Movie>{// We have not exactly a tie here...newMovie("Terminator 2",1991,4.7f),// ^^^^^^^^^^^^^^newMovie("Titanic",1998,4.5f),newMovie("The Fifth Element",1997,4.6f),newMovie("My Neighbor Totoro",1988,5f)// ^^^^^^^^^^^^^^^^^^^^};varyours=newList<Movie>{newMovie("My Neighbor Totoro",1988,5f),// ^^^^^^^^^^^^^^^^^^^^newMovie("Pulp Fiction",1994,4.3f),newMovie("Forrest Gump",1994,4.3f),// We have not exactly a tie here...newMovie("Terminator 2",1991,5f)// ^^^^^^^^^^^^^^};varweBothHaveSeen=mine.Intersect(yours);Console.WriteLine("We both have seen:");PrintMovies(weBothHaveSeen);// Output:// We both have seen:// My Neighbor TotorostaticvoidPrintMovies(IEnumerable<Movie>movies){Console.WriteLine(string.Join(",",movies.Select(movie=>movie.Name)));}recordMovie(stringName,intReleaseYear,floatRating);
This time, we have two lists of movies, mine and yours, with the ones I’ve watched and the ones you have watched, respectively. Also, we both have watched “My Neighbor Totoro” and “Terminator 2.”
To find the movies we both have seen (the intersection between our two catalogs), we used Intersect().
But, our example only shows “My Neighbor Totoro.” What happened here?
If we pay close attention, we both have watched “Terminator 2,” but we gave it different ratings. Since we’re using records from C# 9.0, records have member-wise comparison. Therefore, our two “Terminator 2” instances aren’t exactly the same, even though they have the same name. That’s why Intersect() doesn’t return it.
To find the common movies using only the movie name, we can:
pass a custom comparer to Intersect(),
override the default Equals() and GetHashCode() methods of the Movie record, or,
varweBothHaveSeen=mine.IntersectBy(yours.Select(yours=>yours.Name),// ^^^^^^// Your movie names(movie)=>movie.Name);// ^^^^// keySelector: Property to compare byConsole.WriteLine("We both have seen:");PrintMovies(weBothHaveSeen);// Output:// We both have seen:// Terminator 2,My Neighbor Totoro
Unlike Intersect(), IntersectBy() expects a “keySelector,” a delegate with the property to use as the comparing key, and a second collection with the same type as the keySelector.
Union() finds the elements from both collections without duplicates.
Let’s find all the movies we have in our catalogs.
varmine=newList<Movie>{newMovie("Terminator 2",1991,5f),// ^^^^^^^^^^^^^^newMovie("Titanic",1998,4.5f),newMovie("The Fifth Element",1997,4.6f),newMovie("My Neighbor Totoro",1988,5f)// ^^^^^^^^^^^^^^^^^^^^};varyours=newList<Movie>{newMovie("My Neighbor Totoro",1988,5f),// ^^^^^^^^^^^^^^^^^^^^newMovie("Pulp Fiction",1994,4.3f),newMovie("Forrest Gump",1994,4.3f),newMovie("Terminator 2",1991,5f)// ^^^^^^^^^^^^^^};varallTheMoviesWeHaveSeen=mine.Union(yours);Console.WriteLine("All the movies we have seen:");PrintMovies(allTheMoviesWeHaveSeen);// Output:// All the movies we have seen:// Terminator 2,Titanic,The Fifth Element,My Neighbor Totoro,Pulp Fiction,Forrest GumpstaticvoidPrintMovies(IEnumerable<Movie>movies){Console.WriteLine(string.Join(",",movies.Select(movie=>movie.Name)));}recordMovie(stringName,intReleaseYear,floatRating);
This time we gave the same rating to our shared movies: “Terminator 2” and “My Neighbor Totoro.” And, Union() showed all the movies from both collections, showing duplicates only once.
Union() works the same way as the union operation in our Math classes.
LINQ has a similar method to “combine” two collections into a single one: Concat(). But, unlike Union(), Concat() returns all elements from both collections without removing the duplicated ones.
.NET 6.0 also has a UnionBy() method to “union” two collections with a keySelector. And, unlike IntersectBy(), we don’t need the second collection to have the same type as the keySelector.
3. Except
Except() finds the elements in one collection that are not present in another one.
This time, let’s find the movies only I have watched.
varmine=newList<Movie>{newMovie("Terminator 2",1991,5f),newMovie("Titanic",1998,4.5f),// ^^^^^^^newMovie("The Fifth Element",1997,4.6f),// ^^^^^^^^^^^^^^^^^newMovie("My Neighbor Totoro",1988,5f)};varyours=newList<Movie>{newMovie("My Neighbor Totoro",1988,5f),newMovie("Pulp Fiction",1994,4.3f),newMovie("Forrest Gump",1994,4.3f),newMovie("Terminator 2",1991,5f)};varonlyIHaveSeen=mine.Except(yours);Console.WriteLine();Console.WriteLine("Only I have seen:");PrintMovies(onlyIHaveSeen);// Output:// Only I have seen:// Titanic,The Fifth ElementstaticvoidPrintMovies(IEnumerable<Movie>movies){Console.WriteLine(string.Join(",",movies.Select(movie=>movie.Name)));}recordMovie(stringName,intReleaseYear,floatRating);
With Except(), we found the movies in mine that are not in yours.
When working with Except(), we should pay attention to the order of the collection because this method isn’t commutative. This means, mine.Except(yours) is not the same as yours.Except(mine).
Likewise, we have ExceptBy() that receives a KeySelector and a second collection with the same type as the keySelector type.
Voilà! These are the Intersect(), Union(), and Except() methods. They work like the Math set operations: intersection, union, and symmetrical difference, respectively. Of the three, I’d say Except is the most common method.
Want to write more expressive code for collections? Join my course, Getting Started with LINQ on Udemy! You'll learn from what LINQ is, to refactoring away from conditionals, and to new methods and overloads from recent .NET versions. Everything you need to know to start working productively with LINQ — in less than two hours.
