Bookmarks, Blogs and Software Design

I am finally cleaning my bookmarks. And this gives me a chance to re-read and share some of my favorite posts. At the same time I also want to share some thoughts on programming and software design.

Time Series Analysis: Resampling and Interpolation

The first bookmark is a post by Caleb Welton. It shows how to perform Timeseries Analysis with PostgreSQL and how to interpolate values:

In early 2017 I had to deal with a lot timeseries data and tried to convince people to not leave SQL. And the post showed me how to work with SQL lag and lead operators and how to use Common Table Expressions (CTE) to make queries simpler.

I have to credit the post with getting me started with PostgreSQL again, because after reading the post I wrote PgBulkInsert and PostgreSQLCopyHelper to understand how the Postgres COPY Protocol works.

Time-series data: Why (and how) to use a relational database instead of NoSQL

In 2017 a new Time series database also hit the scene: TimescaleDB. The blog post showed me, that you do not necessarily have to leave your SQL comfort zone for processing large amounts of Timeseries data:

My priorities at work shifted and I wasn't able to go much further. But TimescaleDB always stuck in my mind until 2019 when I finally found time to evaluate various Time series databases:

Frontend Development or... Everything Easy is Hard Again

In late 2017 I got into Web Development again and my bookmarks suddenly saw a lot of good articles on Frontend development:

Honestly, as a developer being proficient in various programming languages it was quite a frustrating fight to get "comfortable" with the JavaScript ecosystem. But it's not only the JavaScript ecosystem, but the modern Frontend stack in general: webpack, npm, SCSS, JavaScript, ...

Position two elements next to each other? Do I use display: flex? display: grid? Does Edge support it? IE? Firefox? Chrome? 😭 npm install? Why do I have 1794 dependencies for a Hello World? Oh dear... 😭

At the time an article by Frank Chimero restored a little faith in humanity:

On the bright side, Visual Studio Code makes Frontend development a little less painful though.

From JavaScript Fatigue to Graph Databases

It's hard to not get tired when doing modern Frontend development for weeks. Javascript Fatigue anyone?

This is put nicely in in a quote shared by Eric Clemmons:

Saul: "How's it going?"

Me: "Fatigued."

Saul: "Family?"

Me: "No, Javascript."

So after a month of struggling with JavaScript frameworks professionally, I needed a small side project to turn frustration into code. 💪 Around this time I stumbled upon a Youtube Video by Nicole White. It's a great introduction to neo4j and the Cypher query language:

In the video Nicole explains how to model a Graph with neo4j and designs a schema for querying flight data:

The video got me interested in neo4j and as a C# programmer I evaluated how to use it with .NET:

Professionally I deal with the Microsoft SQL Server a lot, so it also got me interested in the Graph Database of SQL Server:

Microservices and Monoliths

We replaced our monolith with micro services, so that every outage could be more like a murder mystery. (Honest Status Page)

I live in an Anti-Microservices Filter Bubble. Please don't jugde! 😌

So most of my bookmarks have been in favor monoliths of course:

Software Architecture

I have thought a lot about software architecture in my career, so my bookmarks are full of links on software architecture.

You name an architecture and chance is good I experimented with it:

But it's like this ...

Developers talk too much about architecture. (Pokémon Architecture)

Domain-Driven Design

There has been a lot of talk in the industry about Domain-Driven Design (DDD). And over the years I have read most of the blogs and articles I could find on DDD.

But at the bottom of my heart I am still a programmer. I want to see code. I want to see the elegance in the architectures using the sacred Domain-Driven Design methodology. And once you start digging a little deeper you will notice, that real DDD examples are a scarce good. 🤔

The only somewhat larger .NET application I know of, that employs DDD / CQRS pattern is Microsofts eShopOnContainers project:

And if you ask me if I'd rather maintain a DDD or a CRUD version of a Catalog Service:

Oh Boy...

Then I am a 1000% in the CRUD camp!

On Layered Architectures

After reading about and experimenting with software architecture and being in various teams I came to the following two conclusions:

  1. 99% of the projects should start with a dead simple Layered Architecture.
  2. 99% of the projects should start with a Relational Database.

Why?

  1. Everyone in a project understands Layered Architectures.
  2. Everyone knows where to put things in a Layered Architecture, even if it's a huge Service or Manager "anti-pattern" class using Anemic Domain Model "anti-pattern" classes.
  3. Everyone understands ER-Diagrams and I am able to explain the domain.
  4. Everyone can learn a little SQL to play around & make sense of data.

And giving up on Atomicity, Consistency, Isolation, Durability guarantees of a Relational Database early in a project is outright dangerous.

There is a reason, why the Google Cloud Platform blog says:

Because what happens when you introduce Eventual Consistency in a CQRS/ES application? What happens when using a NoSQL database, that doesn't have strong consistency guarantees?

To take advantage of "transactions" in database systems that have limited or no strong consistency across documents/objects/rows, you have to design your application schema such that you never need to make a change that involves multiple "things" at the same time. That’s a huge restriction and workarounds at the application layer are painful, complex, and often buggy. (Google Cloud Platform Blog)

Does a Layered Architecture scale? Probably not.

But know what?

I will handle the problem, when the problem is real.

Conclusion

Full Stop.

In the past I have read a lot articles on Software Development, Software Architecture and Project Management. I was constantly thinking about how to improve. Improve the code. Improve myself. I have spent countless hours reading discussions on Hacker News and /r/programming.

You know what made me a happier programmer after all?

I stopped overthinking things:

  • I started writing small libraries like FcmSharp or TinyCsvParser, that make my life a little easier and hopefully yours.
  • When designing software I make sure everyone in a team understands the design and knows where to put things.
  • I try to get something done and not aim for the perfect abstraction. I stopped worrying about future, non-existing problems.

Finally ...

Stop talking about code and start writing code!

How to contribute

One of the easiest ways to contribute is to participate in discussions. You can also contribute by submitting pull requests.

General feedback and discussions?

Do you have questions or feedback on this article? Please create an issue on the GitHub issue tracker.

Something is wrong or missing?

There may be something wrong or missing in this article. If you want to help fixing it, then please make a Pull Request to this file on GitHub.