DEV Community: ccarcaci

Characterization of a plane in the space

ccarcaci — Mon, 30 Mar 2026 14:04:13 +0000

$α\alpha$ is a plane in the space and we've been told in school that its equation in canonical form is:

a x + b y + cz + d = 0

But this doesn't tell us nothing about the plane characteristics and no-one explained us how this equation is formed.

Plane formation

A plane in the space could be identified by a point and 2 non-parallel vectors.

P=(x_0,y_0,z_0)\in \alpha \\ \\ \underline{u},\underline{v}\in \alpha

$u‾,v‾\underline{u},\underline{v}$ have magnitude, direction, and orientation. It's possible to write:

\underline{u}=PQ \\ \underline{v}=PR

Every other point $X$ that belongs to $α\alpha$ could be written as a linear combination of these elements starting from the origin:

OX=OP+s*\underline{u}+t*\underline{v} \\ X=(x,y,z)\in\alpha \\ s\in R \\ t\in R

This clarifies why it is possible to say:

A plane in the space could be identified by a point and 2 non-parallel vectors.

Parametric equations

$X$ can be described by its parametric equations:

x=x_0+m_1*s+m_2*t \\ y=y_0+n_1*s+n_2*t \\ z=z_0+p_1*s+p_2*t \\ \underline{u}=(m_1,n_1,p_1) \\ \underline{v}=(m_2,n_2,p_2)

The goal is to solve this system over $s$ and $t$ reducing it to a linear equation that is satisfied for the points belongings to the plane.

A bit of math

t=\frac{x-x_0-m_1*s}{m_2} \\ t=\frac{y-y_0-n_1*s}{n_2} \\ t=\frac{z-z_0-p_1*s}{p_2}

Equal over $t$ :

\frac{x-x_0-m_1*s}{m_2}=\frac{y-y_0-n_1*s}{n_2} \\ \frac{x-x_0-m_1*s}{m_2}=\frac{z-z_0-p_1*s}{p_2}

$t$ is gone, let's target $s$

\frac{x-x_0}{m_2}-\frac{m_1}{m_2}*s=\frac{y-y_0}{n_2}-\frac{n_1}{n_2}*s \\ \frac{x-x_0}{m_2}-\frac{m_1}{m_2}*s=\frac{z-z_0}{p_2}-\frac{p_1}{p_2}*s

\frac{x-x_0}{m_2}-\frac{y-y_0}{n_2}=(\frac{m_1}{m_2}-\frac{n_1}{n_2})*s \\ \frac{x-x_0}{m_2}-\frac{z-z_0}{p_2}=(\frac{m_1}{m_2}-\frac{p_1}{p_2})*s

A=\frac{x-x_0}{m_2} \\ B=\frac{y-y_0}{n_2} \\ C=\frac{m_1}{m_2} \\ D=\frac{n_1}{n_2} \\ E=\frac{z-z_0}{p_2} \\ F=\frac{p_1}{p_2}

\\ A-E=s*(C-F)

s=\frac{A-B}{C-D} \\ s=\frac{A-E}{C-F}

\\ AC-AF-BC+BF=AC-AD-CE+DE \\ -AF-BC+BF=-AD-CD+DE \\ AF-AD+BC-BF-CE+DE=0 \\ A*(F-D)+B*(C-F)+E*(D-C)=0

\frac{x-x_0}{m_2}(\frac{p_1}{p_2}-\frac{n_1}{n_2})+\frac{y-y_0}{n_2}(\frac{m_1}{m_2}-\frac{p_1}{p_2}+\frac{z-z_0}{p_2}*(\frac{n_1}{n_2}-\frac{m_1}{m_2})=0

a=\frac{\frac{p_1}{p_2}-\frac{n_1}{n_2}}{m_2} \\ b=\frac{\frac{m_1}{m_2}-\frac{p_1}{p_2}}{n_2} \\ c=\frac{\frac{n_1}{n_2}-\frac{m_1}{m_2}}{p_2}

a*(x-x_0)+b*(y-y_0)+c*(z-z_0)=0 \\ ax+by+cz-ax_0-by_0-cz_0=0 \\ d=-ax_0-by_0-cz_0 \\ ax+by+cz+d=0

\underline{w}=(a,b,c)

This is the directional vector of the plane, orthogonal to it.

Geometry

To prove that $w‾\underline{w}$ is orthogonal to the plane, it should be orthogonal to both $u‾\underline{u}$ and $v‾\underline{v}$ .

The scalar product should be 0:

\underline{w}\cdot\underline{u}=0 \\ \underline{w}\cdot\underline{v}=0

\underline{w}\cdot\underline{u}=a*m_1+b*n_1+c*p_1=\frac{\frac{p_1}{p_2}-\frac{n_1}{n_2}}{m_2}*m_1+\frac{\frac{m_1}{m_2}-\frac{p_1}{p_2}}{n_2}*n_1+\frac{\frac{n_1}{n_2}-\frac{m_1}{m_2}}{p_2}*p_1

\underline{w}\cdot\underline{u}=\frac{p_1}{p_2}\frac{m_1}{m_2}-\frac{n_1}{n_2}\frac{m_1}{m_2}+\frac{m_1}{m_2}\frac{n_1}{n_2}-\frac{p_1}{p_2}\frac{n_1}{n_2}+\frac{n_1}{n_2}\frac{p_1}{p_2}-\frac{m_1}{m_2}\frac{p_1}{p_2}=0

\underline{w}\cdot\underline{v}=a*m_2+b*n_2+c*p_2=\frac{\frac{p_1}{p_2}-\frac{n_1}{n_2}}{m_2}*m_2+\frac{\frac{m_1}{m_2}-\frac{p_1}{p_2}}{n_2}*n_2+\frac{\frac{n_1}{n_2}-\frac{m_1}{m_2}}{p_2}*p_2=0

Stereographic equations

ccarcaci — Mon, 13 Oct 2025 09:54:35 +0000

This article is the first of a series that treat math topics.

I've decided to write some articles reporting interesting exercises and demonstrations that are difficult to find in the web.

The stereographic equations demonstration in this article is a good example. For example, the Wikipedia page about Stereographic projection doesn't report the step-by-step process.

I'm quite positive that such demonstration could be found in math books.

Author background

My background on math is limited to what I did during my computer science degree. I'm not an expert, and I'm not an expert on graphical projection.

So, any comment, suggestion, error catch is welcome and encouraged.

The problem

The context is described in the image above. A sphere has its center in the axis origin. The horizontal plane including the origin offers the projecting surface. The projection is made by the function that associates a point onto the sphere with a point on the plane that is the result of the intersection between the plane and the segment between the North pole and the point into the sphere.

In formula:

{\underline{x}\in\mathbb{R}^3 : x_1^2+x_2^2+x_3^2=1 } \\ \underline{x}=(x_1,x_2,x_3)\in S \\ N=(0,0,1) \text{ North pole}\in S \\ f(S)\to\mathbb{R}^2 \\ \underline{y}\in\mathbb{R}^2, \underline{y}=(y_1,y_2), f(\underline{x})=\underline{y} \\

For the sake of making the math simple, the sphere is the unit radius sphere and is centered in the origin.

Considering the perspective of plane Considering the perspective of plane $x_1x_3$ :

Knowing the coordinates of one point in the sphere $x‾\underline{x}$ and knowing that $y‾\underline{y}$ will be on the segment $r⃗\vec{r}$ connecting $x‾\underline{x}$ and $N$ , it is possible to write the following formulas:

\vec{r}: x_3=-\frac{x_1}{y_1}+1

The reason is simple, the segment linking $x‾\underline{x}$ and $r⃗\vec{r}$ intersect $x_3$ axis in $N$ where $q = 1$ and the angular coefficient is:

m=\frac{N_3-y_3}{N_1-y_1}=\frac{1-0}{0-y_1}=-\frac{1}{y_1}

The same reasoning could be done with the plane $x_2x_3$ :

\vec{t}: x_3=-\frac{x_2}{y_2}+1

Now, the goal is to find the coordinates of $y‾\underline{y}$ , and this could be done by reversing the $r⃗\vec{r}$ and $t⃗\vec{t}$ formulas:

x_3=-\frac{x_1}{y_1}+1\implies y_1=\frac{x_1}{1-x_3} \\ x_3=-\frac{x_2}{y_2}+1\implies y_2=\frac{x_2}{1-x_3} \\

Inverse formula

Now, the challenge begin, find the inverse formula of this projection.

In word: given a point in the plane, find the point on the sphere.

In world: given a point in a map, find the real point in the world.

To find the inverse formula the sphere formula is needed, alongside the equations that represents the segment linking the North pole to the point in the map $y‾\underline{y}$ .

By looking the plane $x_1x_2$ the North pole is projected over the origin and the equation that connect the North pole with $y‾\underline{y}$ is:

\vec{v}: x_2=\frac{y_2}{y_1}x_1

By looking the plane $x_1x_3$ the segment connecting the North pole with $y‾\underline{y}$ has equation:

\vec{r}: x_3=-\frac{x_1}{y_1}+1

The work evolves around the equations:

\vec{v}: x_2=\frac{y_2}{y_1}x_1 \\ \vec{r}: x_3=-\frac{x_1}{y_1}+1 \\ S: x_1^2+x_2^2+x_3^2=1 \\

The equation for $S$ could be rewritten as:

x_1^2+(\frac{y_2}{y_1}x_1)^2+(-\frac{x_1}{y_1}+1)^2=1

Then:

x_1^2+\frac{y_2^2}{y_1^2}x_1^2+\frac{x_1^2}{y_1^2}-2\frac{x_1}{y_1}+1=1 \\ x_1^2+\frac{y_2^2}{y_1^2}x_1^2+\frac{x_1^2}{y_1^2}-2\frac{x_1}{y_1}=0 \\

This equation has 2 solutions:

\begin{align} \text{first: }&x_1=0 \\ \text{second: }&x_1+\frac{y_2^2}{y_1^2}x_1+\frac{x_1}{y_1^2}-\frac{2}{y_1}=0 \\ &x_1(1+\frac{y_2^2}{y_1^2}+\frac{1}{y_1^2})=\frac{2}{y_1} \\ &x_1(\frac{y_1^2+y_2^2+1}{y_1^2})=\frac{2}{y_1} \\ &x_1=\frac{2y_1}{y_1^2+y_2^2+1} \\ \end{align}

The same is valid for $x_2$ :

x_2=\frac{2y_2}{y_1^2+y_2^2+1}

Last, $x_3$ is:

x_3=-\frac{x_1}{y_1}+1 \\ x_3=-\frac{1}{y_1}(\frac{2y_1}{y_1^2+y_2^2+1})+1 \\ x_3=1-\frac{2}{y_1^2+y_2^2+1} \\

Delayed events pattern, no more crons

ccarcaci — Thu, 08 Jun 2023 15:43:36 +0000

Once upon a time, there were cron schedulers. The fundamental bricks to implement the scheduled-task pattern.

The scheduled-task pattern was a useful way to schedule activities and guarantee their execution.

Scheduled activities were of two types:

activities to do periodically (i.e. actualize loan interests every two months)
delayed activities to do after a specified time when an event occurs (i.e. after a week, send a survey to the onboarded user)

Using schedulers, it was possible to fulfill these requirements but a lot of architecture drawbacks and bugs surfaced.

Schedulers drawbacks

Just to list some drawbacks that I've encountered during my career:

error handling, if a cron execution fails, how to recover from where the execution failed?
dependencies between jobs, if job X depends on job Y, how to guarantee that job Y ends before job X?
execution management, if we want to do some operations on data we need to wait until the next cron execution
time zone dependency, be careful to check that each machine that runs a cron job is somehow aligned with the desired time zone
monitoring, how to check what will be processed in the next execution?
high-load on resources, when the scheduled task starts it might require a lot of resources (i.e. high load DB query)
delayed activities that should occur after a fixed time need fine-grained cron execution (i.e. hours/minutes/seconds)

Possible solutions

Solutions shall guarantee:

strong error handling
processing transactionality
processing dependencies explicit into the code
controllable configurations (i.e. time zone), monitoring and resources.

Delayed events pattern

Yes, the proposed solution uses event queues.

This pattern is based on two queues: feed queue and tick queue. Although the latter is not fundamental.

Actors

Event source: the system that generates and publishes the event
Feed queue: the queue that gathers all the events that describe periodic or delayed processing
Delayed trigger: the system that orchestrates the execution of the events
Tick source: the source of truth of time (i.e. time-zone)
Processing queue: the queue where the events falls when the processing should occur

Sequence diagrams

How this pattern works is described in this sequence diagram:

The feed queue is fed with the events that shall be processed somewhere in the future.

The delayed trigger stores all these events in an internal in-memory list (batch). But, by now, it doesn't commit the read message back to the feed queue.

When the delayed trigger receives the tick event, it extracts all the events with timestamp < ticktime in its queue. It is important to note that, by using an external tick queue we're making the time an external dependency that we can control and is an invariant for our system. Imagine you want to debug a specific event that occurred in some specific conditions in the past, now you have all the tools. Having the time as an external argument invariant, the unit tests could guarantee more coverage.

For each event extracted from the internal batch, the delayed trigger publishes it into a processing queue, commits it back to the feed queue and removes the event from the in-memory batch.

The systems that process the delayed event now can read them and execute the operations.

For failure resiliency reasons we're using the explicit event commit configuration (as we will see later in the failure paragraph).

An example of delayed event payload is:

{
  "event-time": "1685913444",
  "event-id": "9e34a177-7ac9-49df-8843-cbf6291cf2c6",
  "payload": { ... },
  "operation": { ... },
}

Periodic activities

It might seem that with this pattern it won't be possible to execute operations on data at fixed time. For example, process all the data at midnight every day.

That's not the case, for two reasons.

First, such limitations are symptoms of bad constraints in the system. For example, when using cron, a recurring question is "when we execute this?". This gives the impression that executing operations at a fixed time is mandatory. But, instead, it is a non-functional requirement. All the times I've faced these constraints, it was possible somehow to improve the product by executing things immediately using a queue or a synchronous API. Using scheduled-tasks was just a common way to redistribute the high load when the system was more idle.

Second, it is always possible to specify the right timestamp in the delayed event (i.e. at the next midnight).

Delayed activities

By using this pattern we don't need to execute a cron job in a short-scheduled period. The event will be executed at the right time.

Delayed trigger failure

In this architecture, we're assuming that queues are fail-safe, and also processing systems are reliable.

The only system that is directly involved with this architecture is the delayed trigger. What does it happen if it fails and doesn't work anymore?

It happens that no events are lost. The feed queue will store all the messages, and, when the delayed trigger instance is back, the uncommitted messages are read and processed at the next tick.

What will be experienced is some delays in the results.

At the same time, by managing wisely partitions and consumers, after the down-time it is possible to re-launch multiple instances of the delayed trigger to cope with the accumulated load into the feed queue. A countermeasure that was not possible (or at least difficult) with the scheduled-task architecture.

Scaling

Since the events are independent each others, this architecture is horizontally scalable. There could be multiple instances of delayed trigger system and several partitions (or clusters) of event queues.

Cron solution doesn't offer this possibility. Processing happens in a single tier.

Technology

The best technical solution to provide the event queues is to use a message-broker technology like RabbitMQ.

Although, there are no limitations in using a pure event streaming technology like Kafka.

In any case, to guarantee failover, the explicit commit functionality should be enabled.

Wrap up

This pattern offers a solution to detach as much as possible the moving parts of scheduled-tasks execution.

The processing is managed by independent and bounded events that live on their own.

The delayed events pattern offers also a solution to make the time an invariant concept to enable the possibility to provide all the information as arguments and provide a high level of coverage with unit tests.

Around this, potentially, it is possible also to monitor the events flow and future schedules just by looking at the queues statuses. This possibility is not possible using cron or schedulers since the execution ran all at once and it is difficult to follow logs to understand what is going on in the process.

Operative commit message framework

ccarcaci — Sat, 20 May 2023 07:47:52 +0000

The web is full of articles about "writing meaningful commits"¹ ² ³.

Here is yet another article, written by me. But, this time, I'd like to challenge the benefit of adding the description, the "what", in the commit message, and propose a different framework.

Houston, we have a problem with commits here

If we think about our experience with the commits messages, even the well-written ones, we can spot some problems with them:

no context
the "what" problem
no benefit for merge request

No context

Putting in a commit just the description of "What" the commit does adds no context to understand the reason why the commit exists.

In the following example:

$ git show --pretty=fuller -s HEAD
commit 7b2f87d6174a2d2a53d03e224a25e34ba9288c43 (HEAD -> main, origin/main, origin/HEAD)
Author:     Batman <darkknight@savethepeople.com>
AuthorDate: Mon Apr 01 00:00:00 2023 -0000
Commit:     Batman <darkknight@savethepeople.com>
AuthorDate: Mon Apr 01 00:00:00 2023 -0000

Save user preference about candies

When someone else, or the developer (Batman) in the future, will re-read the comment, the historic memory about the days when the commit was issued is gone.

Why did we need to save the users' candies preference?
What were we doing at the time?

The "what" problem

Going into details on the "context" problem, we fall into the "what" problem.

Writing down only "what" the commit does is just repeating something that could be read from the code. Or, in an even worst scenario, if that part of the code is gone, it will be impossible to relate the current codebase with the commit and its message.

Imagine the "candies preferences save" functionality above has been removed, we have now a completely useless commit message in our repo.

The "what" problem is also about the misalignment between the commit message and the code changes. A lazy developer didn't specify all the "what" details. The reader of the commit will have a difficult time relating some changes to the commit description.

No benefit for merge request

When we review a merge request we have the full list of changes aggregated. We have no visibility on the changes history.

This means that having the list of "what" each commit did could be misleading. For example, a commit description is describing a change that has been reverted in the next commit. Now we're seeing them flattened and we can't recognize the commit description in the code.

Another problem related to the merge requests is that during the creation the developer should recall the job done to guide the readers. But a "lost in translation" is likely to happen, and useful details could be missing in the merge request description. The commit messages should help here.

Overcome the problem

The proposal here is to focus the commit messages more on the context, on the "why", and "how". Ok, no one will blame you if you put also "what" you did.

The commit message template should be

Task reference (unrelated) / implementation
                             test
                             refactor
                             dependencies
                             docs
                             infra
                             revert
Commit context

Whys and hows

Side effects

Command line and operative details

For example

GOTHAM-42 / implementation

We're storing candies preferences for the users because it is important to comfort them with their favourite candies when we rescue them

We store candies names into a non-relational database interfacing with our gotham-memory CQRS system

Possible side effects of this implementation is that if our citizens are gluttonous about candies we can overload the writing part of our CQRS system

To enable the writing endpoint create the Kafka topic with the following command
> kafka create topic candies.cqrs
Check the topics status with this CURL call
> curl http://cqrs.gotham.dev/write/check

In the header, we specify the task identifier (Jira-like in the example) to recall the specific task when the branch is gone or if the team is working trunk based.

In the header, we can specify also the type of the commit (special credits to ¹):

implementation refers to a feature build
test we're providing some tests
refactor the commit contains refactor and code improvements
dependencies the commit is updating the project dependencies
docs update the project documentation
infra modify the infra setup for the project, i.e. database configuration
revert undo some changes done in previous commits

We can also combine multiple types (implementation + refactor), even though a commit should be smaller and address a single type of implementation. The only exception is represented by implementation + test for obvious reasons.

In the bottom of the commit message are specified some operative commands that the developer has fresh in his mind and could help in bug fixing, core review, and writing READMEs and documentation.

Using this framework, when we look back at the commit, we can read the code having in mind the goal of the implementation and how we did it.

We can also be aware of some side effects and, in case of problems, we can easily identify the commit.

Open a merge request

When opening the merge request if we list several commits following this framework we can immediately identify which commits have been reverted, and we can read the implementation flow instead of recalling it from our brain.

In this way, to fully describe the merge request we just need to rework a bit the commit messages list and side-effects and implementation details are already there for reviewers.

Wrap up

The goal of this commit message framework is to have commit messages that are active actors in development. By focusing on context our commit messages will bring meaningful content in the future, for future readers and merge request reviewers.

Commit messages following this framework are helpful also during bug fixing by listing side effects and sensitive implementations. And commit messages are active part also in writing documentation and spreading DevOps knowledge on how to operate the system.

Pull features delivery

ccarcaci — Sun, 14 May 2023 21:09:45 +0000

Back to the good old problem of deadlines in software development.

Deadlines and team velocity in software development is THE trending topic since... well, forever.

History

Back in time, there was waterfall. The waterfall approach is taken from manufacturing and construction buildings. Stages are sequentially organized and it is not possible to go back to a closed phase.

Very soon this became the standard also for software development.

Not so late, the software community understood that software development is not completely predictable and organizable beforehand. The waterfall approach in this context was not applicable.

In the late 90s, Agile Manifesto was born. The Agile Manifesto inspired several frameworks like Scrum, Kanban, Scrumban and other Pokemon-like fancy names.

All these frameworks enforced the feedback cycle and the tradeoffs in the project management triangle: time, scope, and cost (resources).

In any case, for any approach proposed, in-time delivery was something not negotiable, and delays are always a source of complaints, tense retrospectives and unsatisfied middle-to-top management.

Not so late, the software community started to understand that also Agile frameworks was not fitting with software development.

Leaking pipes

No one calls the plumber and ask him to leave leaking pipes because time is up

The quote here makes it clear that in some fields we are ready to accept delays without shrinking the scope (leaking pipes).

Why isn't it the same in software development?

If we go back to the project management triangle, often (99%) time is fixed, the cost can be hardly increased to match the deadline and scope is the only card that could be played.

This is because software development is not a repetitive and fully predictable task, this implies that it cannot be parallelized and adding more resources (costs) means slowing down even more the team's velocity.

At the same time, middle-to-top management wants a predictable delivery date to beat the competition.

Getting back to our plumber example, reduced scope, AKA "Leaking pipes", in software development means:

technical debt, that often no one will repay
unfinished product delivery that does not satisfy the users

Pull delivery in action

Pull delivery methodology could be summarized as

deployment into production is done by product team

This is a strong statement.

Anyway, this statement lives in the usual development team strategy. Scrum teams will continue with Scrum, Kanban teams will Kanban. Pokemon teams will catch'em all!

What this approach introduces is the split of deployment into tiny deployment pieces.

Pull delivery in detail

To illustrate this approach, we take as an example a social network that wants to introduce emoticons in comments and posts.

The task is assigned to a team named "wording team".

The "wording team" brainstorms and details the product and its implementation as usual and starts the first feature iteration which will be 3-week long.

But, this time, decides to follow the "pull delivery" approach.

After reading tons of literature (just this article) they put in place what is needed to follow this approach.

Prerequisites are:

existing feedback mechanism
no ETA
vertical approach
the dev team is committed to providing deployable pieces first
testing and QA environments are strongly aligned with production
test suites alignment
the dev team is unaware of when the users will use the new versions of the product

Existing feedback mechanism

There should be a feedback mechanism that allows the team to steer when new findings are discovered. Feedback often is regulated by the chosen framework. For pull delivery, feedback could ideally "go back" touching all the building phases.

No deadlines

Although the entire team knows that in 3 weeks the first iteration should be closed, there is no deadline for the intermediate tasks. And the fine tracking of intermediate tasks makes the 3 weeks deadline irrelevant for the tech team. The focus is shifted from "how to respect the big deadline" to "how to work on fine-grained activities and provide the best feedback to product team?"

Vertical approach

The dev team should start from a first implementation where the goal is to bring the MVB (Minimum Viable Byte) from the "product entry point" to "the product exit point".

The product entry point is what the user does using the product. In this example use the "wording team" part of the product, the comments. The product exit point is what the user experiences from this action.

From a technical point of view, this means that one byte posted by the user reaches all the intermediate layers, databases, and queues and it is visible back to the user through the product.

Deployable pieces first

The slicing of implementation tasks should be focused on providing small deployable pieces quickly. Deployable pieces are deploying pipeline runs that are consistent and stable for the final product. This means that the code changes, migrations, and config updates are consistent.

Each deployable piece is potentially a new product version.

Tech alignment

To avoid bugs and make the development highly predictable, testing, QA, and even the local dev environment should be aligned as much as possible.

This is even more valid for seeding data into the environments. Updating the seeding data to reflect the production ones is one of the most important traits of this framework. An obfuscating process to feed the production data back to the other environments would be the optimum.

Test suites alignment

Tests should match the real users' behaviors. For example: reproducing the same sequence of API calls for an API service. Or simulate the real interaction of a user in the mobile app.

Dev team unawareness

Developers release tiny pieces every day and hide them behind feature flags or the versioned deployment. The product team decides when to enable flags or bring the new version to the users.

Since the deployment is done without the supervision of the tech team there should be a reliable development and testing process. What the developers and testers experience is the same as the final user experience.

Pull delivery example

Chopping the feature

The "emoticons" task is then chopped into tiny deployable tasks.

Task #1

create a new endpoint to get the available emoticons and their token GET /emoticons
the endpoint will return the smiling face emoticon as svg data into the JSON response payload and the :) token assigned to it
the front-end application will call the GET /emoticons endpoint on the page opening
the front-end application will replace :) with the smiling face when rendering a comment

{
  "image": "...", // SVG encoded content
  "token": ":)",
}

Task #2

the front-end application will parse :) and will replace it with the svg image associated when the user type into the comment box
the front-end application will still send the comment as plain text to the back-end

Task #3

create a back-office endpoint POST /emoticons that allow storing new emoticons into a JSON file
secure it behind a JWT mechanism
Provide access to the storage to all deployments (dev, test, production)

Task #4

improve the GET /emoticons endpoint to make it read the emoticons from the stored JSON
return an array of emoticons instead of the single smiling face

{
  "emoticons": [
    {
      "image": "...",
      "token": ":)",
    },
    {
      "image": "...",
      "token": ":(",
    },
    {
      "image": "...",
      "token": ":eye-rolling:",
    },
  ]
}

Task #5

the front-end application will improve the parse and replace logic accordingly with the upgraded JSON body response

Task #6

the emoticon images will be served through cdns sparse all around the world providing the url into the JSON response
POST /emoticons back-office endpoint will update the cdns all around the world to reduce the overhead of getting the emoticons

Task #7

front-end application will use a local browser cache with expiration time to store the emoticons

Task #8

front-end application will refresh the emoticons through the GET /emoticons endpoint when a :something: token is not recognized

Each of these tasks is deployable independently.

The first task involves the whole stack and, by working on it, the team can discover all the technical details that will affect the rest of the development.

Chopped deployments

For each task, the tech team performs the full testing and QA. The task is deployment-ready and it should be considered "in the hands of the users".

Note how each task has the smallest size possible, the focus at this level is not on providing value to the user, but on providing stable deployments.

The value for the user is delivered when multiple tasks have been released or when the full feature is done. But this choice is in the hands of the product team that has the confidence of releasing stable product pieces.

In case of a bug, break the glass

We don't live in the ideal world.

The product team deploys part of the feature and then a bug is discovered, what to do?

In this case, the feedback mechanism is gold.

The tech team should start tackling the bug, after the mitigation and fix phase there should be a complete review of the technical prerequisites.

If a bug passed undetected to production means that:

a vertical layer has not been included in the development. i.e. a production-only gateway tampered some HTTP headers. Include the gateway also in the other environments (dev and testing)
dev and testing environments are not aligned with production
the data in the dev and testing environments are not reflecting all the production cases
the test suite is not covering meaningful cases

Since we have a list of possible causes it is easy to schedule and work on countermeasures.

Steering

Product released the "Task #1", dev team is working on "Task #3". By watching at data the product team discovers that the feature should steer to a different goal.

Of course, the entire team should gather together and discuss the situation.

Aside from that tech team should stop working on new tasks and it's time to use the time-machine capabilities of VCS (git).

For this reason, deliverables must be consistent per each commit.

Pull deliveries expected results

In this way, developers are no more committed to respecting an unfeasible deadline. They are committed to fine-grained slicing of deployments and consistency of environments.

At this point, one could argue that if we apply fine-grained slicing and estimations to a project we can have a predictable release schedule that could be pushed by developers.

That's not true. The main reason for this is that even if you provide a fine-grained estimation of tasks, the sum of the tasks rarely will reflect the sum of the estimations. When you finish a task, you discover or set some details that make wrong a previous estimation about the next tasks. The highest reliability of development estimations is given when the task is (nearly) finished, and the estimation itself is useless.

With pull delivery, we want to overcome this, generating, by design, some positive side efects:

smaller merge requests
stable and predictable development and testing environments
less "tech debt"
smaller investigation perimeter for new bugs
early discoveries of blockers during the first task
fine-grained feature scope management
smaller reworks for scope reduction
product has full control over what is released, and when
less stress

OOP and procedural programming comparison - part 1

ccarcaci — Mon, 01 May 2023 18:33:53 +0000

Introduction

Everything started when I switched from Java to NodeJS. Years ago, it was 2018, I was using Java (and its derived Groovy dialect) to write code. I started studying Typescript and NodeJS to move to a new company.

In the new company, I've found myself writing the same kind of software as in the old one. But, this time, they were more readable, straightforward and better tested.

Some possible reasons for this:

the new company had a better culture
I suddenly got better at writing code
JS/NodeJS was better than Java/Spring

Possibly none of them

the new company worked even worse in the rush everyday
I was the same developer working in a language/framework with bare experience
it is pointless doing such a comparison as universal truth

Maybe, for the kind of software I was writing in both companies the OOP paradigm was not well suited. Maybe, but exaggerated as a hypothesis.

This was the reason I had in my mind to write an article about programming using OOP nowadays. For 5 years.

The story

One chapter of Clean Architecture (R. Martin) is dedicated to programming paradigms. Structured programming (SP), object-oriented programming (OOP) and functional programming (FP). The characterization done in the book in my opinion is the best I have ever seen.

To summarize: at first, there was Assembler (ASM). By using ASM it was possible, and widely used, to jump into the execution flow. In 1968 Dijkstra constrained the execution flow with statements.

Structured programming imposes discipline on direct transfer of control

OOP was born two years before "structured programming" (procedural), in 1966 by Ole Johan Dahl and Kristen Nygaard. OOP moves around the concept of "pointer to function". Languages allow to define a pointer to a function. In OOP this is constrained using polymorphism.

Object-oriented programming imposes discipline on indirect transfer of control

Functional programming was born 30 years before. In 1936 Alonzo Church invented lambda-calculus around immutability, the concept that symbol values do not change.

Functional programming imposes discipline upon assignment

What happened to OOP?

During the '80s, but mostly during the '90s and early 2000s, Java and OOP became the de-facto standard for enterprise software. At the time, software was mostly monolithic, poorly tested, and developed under a strict waterfall approach with no room to improve it.

Java revisions followed the needs of these past times. OOP became the synonym of "Java programming in monolithic architecture".

Software development felt the urgency to step away from this paradigm and moved to SOA, then SAAS and microservices architecture. The trend was to reduce the scope and simplify responsibilities.

Starting from there, the different Java revisions added support to the last programming features and idioms, moving away from its core, pure, OOP nature. And, at the same time, programmers started being bored and overwhelmed by unmaintainable monoliths done in Java. OOP then suffered the association with Java and Java suffered the association with monoliths. OOP suffered because of unmanageable monoliths.

Community perception and personal considerations

In this paragraph, we take a break to talk about how OOP is perceived by the community. The web is full of articles against OOP.

Like this

or Like this

If I look at what has been written on the web and in books about OOP, I can find easily a burden of articles on both sides, praise and criticism of OOP and procedural approaches.

The problem with these articles is that they are very long essays that barely show metrics and code comparisons. They are often a stream of consciousness of the author about OOP, programming, and the universe. I can agree or disagree with them because I have a good or bad feeling, but nothing objective. And I didn't want to write the N+1 article about "OOP is good/bad! (in my opinion)".

I'm gonna try to provide some in-depth evidence about the situation. Although I know this analysis is partial. I hope, at least, it is a tiny more objective.

Some objective evidence

In the introduction, are reported just some personal feelings like

they were more readable, straightforward and better tested.

How did I perceive the TS/NodeJS code as more readable, straightforward and better tested?

for the kind of software I was writing

Which kind of software?

Well, I'll try to identify some metrics to measure the code I'll show here. The next paragraphs will list them.

Exercise Call center

The metrics are measured over an OOP exercise taken from Cracking the Coding Interview book reported in Chapter 7 "Object-Oriented Design".

The exercise solutions are available in this Github repo.

I've solved it using Java (OOP) and Typescript+NodeJS (procedural).

Call center OOP solution takeaways

I went using the extension paradigm to provide mocks instead of using Mockito or similar libraries. This is because the mock-providing code tells a lot about the paradigm and the language. For example: how overriding and extension work, how interface definition works and how much verbose is the language.

The approach I've followed is top-down, starting from the "dispatch call" feature.

Call center procedural solution takeaways

Similarly to what I did with OOP solution, and for the same reasons, I preferred not to use the Jest module mock capabilities and, instead, create manual mocks that fulfill the interface definition of the modules (in a Go-like style).

Metrics

I'll try here to give some metrics about "readable, straightforward and better tested".

Number of lines of code (LOC)
Number of test lines of code (LOC-t)
Number of classes (OOP) and modules (NodeJS), entities (E)
Number of methods (M)
Indentation levels average (I)
Average cyclomatic complexity per method (C)
Number of average dependencies between entities (D)

Measurements

Metric	OOP value	Procedural value
LOC	194	312
LOC-t	281	499
E	6	8
M	15	8
I	2.67	1.87
C	2.07	2.75
D	1	1

OOP vs procedural approach

As far as I've understood there are some fundamental dichotomies between OOP and the procedural approach.

OOP encapsulates the status into classes and propagates actions.

Procedural propagate status and encapsulate actions into methods.

OOP wraps the status into access and visibility rules.

Procedural makes access rules (methods) to comply with status.

As much as difficult words have been used here we can summarize with "OOP focus on how entities interact, procedural focus on how the status flows between methods" For this reason, in the procedural approach it is very important to identify pure and non-pure functions and always prefer the formers.

Metrics analysis

The core goal of this article is to give some objective evidence about OOP and procedural approaches. The coding exercise proposed here is an OOP-tailored one. We play in the OOP field with the procedural team.

We report here some paragraphs that highlight some traits and comparations between the two approaches.

Conciseness

From the above measurements, it is really clear that OOP outperforms procedural in terms of lines of code. This reflects the possibility to combine objects' behavior resulting in concise instructions.

A great example of this is the respondent selector function. In Java, this is resolved with a single line

respondents.sort(Comparator.comparingInt(CallCenterEmployeeInterface::getManagedCalls));

In procedural this is a fully-fledged function

const selector = (respondents: RespondentType[]): RespondentType | null => {
  if (respondents.length <= 0) {
    return null
  }

  const selectedRespondent = respondents.sort((respondent, respondent2) => respondent.calls - respondent2.calls)[0]
  return selectedRespondent
}

Readability

To evaluate the readability, what comes into play are the indentation levels average (I) and the cyclomatic complexity (C).

Indentation levels average (I) is better in procedural than OOP. The reason is easy to explain: OOP is based on classes, and their definition adds at least one indentation level. In fact, the difference of I measures is 0.8 which is very close to 1.

To evaluate cyclomatic complexity (C) instead, we should take into account the fact that OOP encapsulation saves conditional statements. The example is around dispatcher and escalation implementation.

To escalate a call in OOP the logic is encapsulated within Employee class

if(busy) {
  System.out.println(name + " is busy, routed to supervisor");
  supervisor.pickCall();
  return;
}

In the procedural approach, we defined a specific function with some conditional statements

const maybeEscalate = (respondent: RespondentType, logger: LoggerType): RespondentType | null => {
  if(respondent.busy && respondent.supervisor === undefined) {
    logger.info(`${respondent.name} has no supervisor and is busy, call rejected`)
    return null
  }
  if(respondent.busy) {
    logger.info(`${respondent.name} is busy, routed to supervisor`)
    return maybeEscalate(respondent.supervisor!, logger)
  }

  return respondent
}

This affects the cyclomatic complexity for the worst in the procedural approach.

Mental overload

Mental overload is about how many concepts a developer should keep in mind when working. This aspect is crucial when choosing an approach.

A classification of the metrics that influence mental overload could be direct or indirect. Direct ones influence what a developer sees in the editor, indirect ones are related to the project in general and things that are hidden from the developer's view in the editor.

Indirect metrics are the number of entities (E) and the number of average dependencies (D).

Direct metrics are the number of lines of code (LOC, LOC-t), number of methods (M), indentation levels (I) and cyclomatic complexity (C).

In indirect metrics, OOP tends to perform better because some behaviors could be expressed using composition and encapsulated in classes.

Amongst direct metrics, if we consider the number of methods and the indentation levels as something very close to the experience a developer has when writing code, the procedural approach seems to be better. On the other side, cyclomatic complexity and the number of lines of code add more burden to the brain of developers.

From this point of view procedural approach has the advantage to provide step-by-step recipes, for this reason, has higher cyclomatic complexity and more lines of code. And we might consider paying this drawback to have step-by-step cooking-like recipes.

The procedural approach has also the advantage to provide less syntax on the developers' sight because of fewer indentation levels and less number of methods to keep in mind.

Wrap up

To wrap up, what we can say is that if we want very powerful tools to describe complex domains and encapsulate behaviors then OOP is master. It is a great paradigm to provide concise solutions at the cost of hiding behaviors and increases the mental overload of developers.

The fact that recently the web is full of articles against OOP is that encapsulation, domain modeling and bounded context principles have been shifted away from the code to the infrastructure. The use of microservices, lambda functions and decoupled interfacing like API and queues move the mental load from classes to repositories. But, at the same time, providing contracts and regression tests to relieve this. For this reason, developers need a very simple list of instructions executed into their services and a big chunk of the desired behavior is moved to contracts and services intercommunication.

For the reasons measured here, OOP is not best suited for this duty. It forces the developer to think in terms of classes and how to encapsulate a simple behavior into them. When what is needed is a method with a cooking recipe in it. Oftentimes I've found OOP-based microservices that were a bunch of static methods wrapped into well-named classes (modules). Now I can see the reason.

Part 1... Part 2?

The attentive reader noticed that this article is "part 1" something. Yes, there will be part 2.

This article presented some considerations about a simple programming exercise, limited to the syntax and basic approach to the programming.

What is missing here is how OOP and procedural approaches behave in a real-world like case. In part 2, I'll provide an analysis on a very common transactional implementation that involves API, business logic, and DB layers.

Note for the readers

Due to the grievance nature of the topic, and the different positions in the community, I preferred to take a very practical approach providing, measuring and commenting on code.

I will follow the same approach in the comments, I will not respond to comments that are not provided with code and practical considerations. This is because, without some code attached, it will be impossible to separate personal opinions from practical evidence.

Bonus: design patterns

"Integrity is telling myself the truth. And honesty is telling the truth to other people." (S. Johnson)

I've never understood the obsession with design patterns. There are hundreds of design patterns but only a strict subset of them are used daily.

So, from where this obsession came from?

I think design patterns are used for two reasons:

difficult questions during an interview to make the candidate uncomfortable "Tell me about the Memento pattern, and give me an example where you used it" I was asked once. I've never used it, of course. Next question, please
academic showcase

Both reasons are worthless.

I dare you to tell me how many times in your professional life you used some patterns like AbstractFactoryBuilder, Composite, or Flyweight. For people that don't keep them fresh in their mind (99% of devs), they are less readable than less engineered, but direct, code.

This means that it's OK to USE design patterns. It's OK to go back to read them and, if there is one that could solve our current problem, use it. Attach a comment to the code pattern for the future reader of your code, that with a high probability will be yourself. But making design patterns a discussion argument or an interview question is dumb.

To be honest, this topic is worth a separate article, comparing the usage of a design pattern VS using a very simple yet naive approach.

JSON recognizer is here

ccarcaci — Tue, 25 Oct 2022 06:37:53 +0000

Take a look to my new library.
Recognizes JSONs out of a flow of chars. Built with no dependencies.
New updates are coming.

https://lnkd.in/ds3WFey4

Software engineer path.

ccarcaci — Thu, 13 Oct 2022 20:08:08 +0000

Table of contents.

Introduction.
A journey in software development.
Training and practice.
(My) Correct order of things.
Fundamentals / A Philosophy of Software Design (John Ousterhout).
Fundamentals / UNIX philosophy (Doug Mcllroy et al.).
Fundamentals / Pragmatic Programmer (David Thomas and Andrew Hunt).
Fundamentals / Clean Code (Robert C. Martin).
Medium / Release It! (Michael T. Nygard).
Medium / Domain Driven Design (E. Evans).
Medium / Designing Data-Intensive Applications (Martin Kleppmann).
Medium / Infrastructure as Code (Kief Morris).
Modularization problem.
And OOP? What about OOP?
Contributions.

Introduction.

This is an ongoing article. This article will be updated overtime to gather my thoughts and highlights about software development.
This article is useful for all professionals involved in software products development (developers, architects, engineering managers and even product owners) and, to be honest, it is useful for me to recap my ideas.

During the years I've read many books about software development, I guess around 50. I did this without any advice, just picking books that seemed interesting for my career. After tenths of books and years, I now have a clear idea about what would have been the best order to follow. Some of them are basic, others are specific. Some should be read when facing a particular issue.

Most (quite all) contents of this article are personal opinions.

A journey in software development.

One of the questions, maybe THE question, a young software engineer has is: what can I do to become a good and great software engineer?

The obvious answer is: training and practice.

So, how can we train and practice?

Basing on my experience, I can say that scholar and academic formation is basilar. This doesn't mean that a software engineer must attend high school or college. Absolutely not. This means that a software engineer should embrace the basilar topics of software engineering, no matter about how this is achieved.

Relational model, complexity, binary logic, computer architecture are just some of the basilar topics that are angular bricks on how to get broad knowledge. Just to give an example, it is useless to read "Designing Data-Intensive Applications" without the basic knowledge about databases, transactions, ACID properties and how storage works.

Now, let's assume a just graduated (or self-taught) person wants to start its journey in professional software development. What are the next steps?

Training and practice.

It's easy to understand that the training part will continue all along the entire career. And it's also easy to understand that the practice strongly depends on where one will work. It is also possible to practice in spare time, but this experience is marginal, either because of limited time to dedicate, either because the limited scope of projects. If you're in a company with no possibilities to practice, and you want to, then ask for it. If this doesn't happen, then leave.

For this reason, in this article we will focus on the training part.

(My) Correct order of things.

In the first part of my career (early 2000's), when internet was not a thing, I read more programming languages books: PHP, Java, Visual Basic and so on. It was not yet possible to train on specific languages through internet tutorials. Knowledge was almost exclusively based on books.

In this article, I'm going to focus more about late 2010's and 2020's books. Or books that, despite their age, are still topical.

It's interesting to note how books content evolved from early 2000s to 2020. At first they were more focused on programming languages. Then they moved onto software engineering and (more or less) illuminated authors' ideas.

The following list is in the order I would have liked to read them. The same order is used for the remaining paragraphs of this article.

Fundamentals.

A Philosophy of Software Design.
Unix Design Principles.
Pragmatic Programmer.
Clean Code.

Medium.

Release It!
Domain Driven Design (Only the first part).
Designing Data-Intensive Applications.
Infrastructure as Code.

Microservices.

Building Microservices.
Microservice Architecture.
Building Evolutionary Architectures.
Monolith to Microservices.

I will report some personal general considerations and interesting topics worth to note.

I will also report topics that I've guessed before finding them on books. This means that the specific topic has a sort of common sense meaning. For this reason, it is worth to mention them to put specific focus.

The list is divided into Fundamentals, Medium and Microservices sources. Fundamentals should be known deeply and should be refreshed every time we have a doubt in our code. I suggest to read them twice or more. Medium are worth to be kept in mind and pull out for specific tasks. Microservices are a set of sources that address... well, microservices. The trend of the moment. I decided to list them here because I think multi-level modularity expressed by microservices is a concept that will be actual for a long time.

I am quite sure that in the near future the paradigm will shift to something different from microservices. But the lesson taught by microservices about how to manage modularity from single unit-test element to broad integration-test system will last for a long time.

In this article you'll not find the Microservices books paragraphs. This choice is because they are very advanced topics and are worth reading just if you'll work with microservices, or you want to have a direct touch with modularization at scale.

Being said that, let's start with the first book first.

Fundamentals / A Philosophy of Software Design (John Ousterhout).

In this book the author reported a list of lessons he gathered during his academic career as Software Engineering course professor at Stanford University.

The best words that describe this book are in the Preface:

"[In college] We teach for loops and object-oriented programming, but not software design"

The result was his Software Engineering course.

I put this book first because I think it is the missing step between academic theories and professional software development. Worth to mention that a course similar to the one taught by the author should be mandatory in each college and high school.

This "missing step" is often left to the effort of the fresh graduated engineers. After years of struggling, some good practices come to the surface. Having a book that gathers most of them is gold.

Of course, the book content follows the opinion of the author, and this is valid for quite all the books, but having a more experienced guide is better than having nothing.

A Philosophy of Software Design. Worth to mention topics.

Pass through variables.
Configuration parameters. How to manage configs.
Exception aggregation.
Software trends (agile, unit test, TDD).

Fundamentals / UNIX philosophy (Doug Mcllroy et al.).

Actually there are plenty of books about UNIX philosophy.

I did my journey through set of principles/frameworks: TDD, SOLID, GRASP, 12-factors and others. I am strongly convinced that all of them are direct consequence of UNIX philosophy. Most of them are "just" a rewriting in a different field of software development. Having in mind these principles, and the UNIX development approach, makes natural to embrace the others principles and frameworks.

UNIX philosophy born back in the '70s. But time have no effect on it. It is still actual and this is its power.

UNIX philosophy has been summarized several times during the years by notorious authors. These summaries are worth to follow and brings innovation to the table. In my opinion, the best thing to do is to deeply know the original definition depicted back in 1978 by Doug McIlroy:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

These points are the tools to build a good feeling about what is wrong in our code. With that in mind, it is easy to find alignment with good practices reported in quite all the books about software programming and frameworks.

UNIX philosophy. Worth to mention topics.

I think that UNIX philosophy is too stately and insightful to be "guessed". I can say that my guesses in other reads are just the consequence of understanding UNIX philosophy. UNIX philosophy is worth to mention in its entirety.

Fundamentals / Pragmatic Programmer (David Thomas and Andrew Hunt).

As it is pointed in the preface this book is an everlasting in the programming community. Several editions have been published during the years.

I think this book is the natural extension of the UNIX philosophy. In short: UNIX philosophy principles applied to real development world.

This book seems to come out from the future even though it comes from the (far) past. Because in software development, and life, what you saw in the past is what you'll see in the future. For that reason the authors decided to gather all the good and bad practices they've encountered during their (amazingly long) careers.

The book brings also very detailed code examples and describes side effects and drawbacks of choices.

I've enjoyed a lot the fact that the patterns and behaviours described are really close to the real (programmer) life. There are no theoretical digression about abstract patterns that you'll never see in your life. Everything is sticky to real problems in real life. The fact that the patterns described here are so different from most of the OOP patterns should suggest a lot about academic classes. See the OOP paragraph below.

Pragmatic Programmer. Worth to mention topics.

For this book the same rule about UNIX philosophy matters. I think the entire book is worth and insightful. I've read it after decades of experience and I got an epiphany about revelations in all the pages.

It was like someone that was confirming and revealing a lot of good habit and guesses that it was really hard to reveal in a management-driven world. This because (bad) management is not really opened to listen to blockers and struggles behind technical development.

Fundamentals / Clean Code (Robert C. Martin).

One yelling you might have is:"why Clean Code is not in the first position? Writing clean code should be the first issue for a developer!"

The answer is simple: before even have had the chance to read about fundamentals ideas on software programming which kind of code a developer is supposed to write? What's the matter of writing shaky code but in a clean way?

I think the three sources above are fundamentals to write meaningful code. Now it's the time to write it in a clean way. Of course, you should, you must, start writing code before finishing reading books. Even if not clean code.

In Clean Code there is an extensive amount of good practices that are worth to follow. These practices spread from code syntax to concurrency management. A good exercise is to pass through the Code Smells appendix and check if we're able to spot the problem or mind a case where we faced the same issue.

Being able to "feel" clean or dirty code is one skill that every developer should have. This book explains the basis to start building that feeling in a guided way. This saves a lot of time.

Clean Code. Worth to mention topics.

Meaningful Names.
Small! (Do one thing).
Reading Code from Top to Bottom: The Stepdown Rule.
Don't Repeat Yourself (DRY).
Data/Object Anti-Symmetry.
Law of Demeter.
Write You Try-Catch-Finally Statement First.
Exploring and Learning Boundaries.
Single Responsibility Principle. In my opinion this book provides the best definition of this: one reason to change.
Simple Design Rules.

Medium / Release It! (Michael T. Nygard).

Now that we handle the fundamentals we're ready to deliver our code to the real world. Yes, but how?

Release It! provides a great guidance on how to deal with the production. What I've found very insightful is the broad set of examples and "close to the metal" dissertations. It is a very pragmatic source and talks directly with the code.

The topics covered into the book represent almost the entirety of the cases of building and operating a production system. It starts listing some stability patterns and anti-patterns, the following part is about the prerequisites for a production-ready application. The remainders are about how to deliver (deploy) the system and how to face with systemic problems.

This read is highly suggested and useful to properly operate a production system.

Release It! Worth to mention topics.

Getting Thread dumps.
Socket-based Protocols.
HTTP Protocols.
Session Tracking.
Unbounded Results Sets.
Stability Patterns.
- Timeouts.
- Circuit Breaker.
- Bulkheads.
- Fail Fast.
- Let It Crash.
- Handshaking.
- Test Harnesses.
- Decoupling Middleware.
- Shed Load.
- Create Back Pressure.
- Governor.
The OWASP Top 10.
Schemaless Databases,
Painless Releases (blue/green deployments).
Create Options.
The Simian Army.

Medium / Domain Driven Design (E. Evans).

This book is one of the most popular amongst developers. Quite all of us have read it.

I have strong opinion on it, as I have strong opinion about OOP. The content of this paragraph is strongly opinionated. I expect many of you will disagree about what is written here.

Domain Driven Design brings into the table one of the most important topics in software development: the ubiquitous language. In this book it is reported for the first time the importance of having a well-known and shared language amongst the team and the company. The vocabulary shall be used by tech, non-tech and all the people in the company.

I think this concept is really important. Never forget it.

The rest of the book is focused in refining knowledge, refactor the code and apply specific patterns related with OOP.

My point is that the book is too focused on OOP. When the first version came out in 2004 it was the golden age of OOP and this setup was normal. In my opinion it is worth reading the whole book to get the touch with the process of refactoring and extending our software. In doing this we should keep in mind that the book works with the particular case of domain modeling with OOP. This might not be a valid prerequisite anymore.

The reported patterns will be useless if you use others modelization approaches (functional, modular) but the general dissertation is still valid.

Domain modeling is still a super-valid concept but shall be applied in different manner outside OOP. In my opinion the best approach is to follow a light representation with types and the UNIX principles.

Medium / Designing Data-Intensive Applications (Martin Kleppmann).

A must-have book.

Within this essay is reported the State of Art about data engineering. Starting from the basis to advanced topics in data management.

It is worth nothing that this book explains a topic and suggests some existing market solutions that provides the data management feature exposed.

I use it as "goto" book when I need to address a data engineering problem. I am not a data engineer, but, since every real system needs its data management solution, having this book in the shelf lets me free my mind.

Designing Data-Intensive Applications. Worth to mention topics.

NoSQL.
Relational Versus Document Databases Today.
Graph-Like Data Models.
Hash Indexes.
B-Trees.
Column-Oriented Storage.
The Unix Philosophy. (Not to say)
Idempotence.

Medium / Infrastructure as Code (Kief Morris).

This book is the first source that addresses the problem of modularization in a practical way.

Infrastructure as Code (IAC) is a basilar topic. Having in mind that the infrastructure upon we build our services can be expressed with code (manage everything with text, as a good Pragmatic Programmer) before reading microservice pattern contents is a boost.

The book deep dive into advanced topics of IAC and presents several products and technologies. In my opinion, given the broad topic, mastering IAC and cloud is a full career path.

In the different Agile derived organizational models developers are often accountable to manage the software end-to-end. A developer should work on devops tasks and related skills are required. This book is a must-have. Even though, in my opinion, it is impossible for developers to maintain enterprise-grade systems, it is a full-time duty and the required competencies and skills fulfill the single person capacity.

Infrastructure as Code. Worth to mention topics.

Goals of Infrastructure as Code.
Challenges with Dynamic Infrastructure.
Choosing Tools for Infrastructure as Code.
Practice: Manage Application Code and Infrastructure Code Together.
Continuous Integration (CI).
Continuous Delivery (CD).
Low-Level testing.
Managing External Dependencies.
Using a Local Sandbox.
12-Factor Applications.
Zero-Downtime Changes.
Measuring Effectiveness.

Modularization problem.

Modularization is the main concept a software engineer should have in mind. Modularization problem is the common trait of quite all the software development sources (articles, book). Topics from programming patterns to microservices architectures are all addressing the same problem: modularization.

Going back to the UNIX principles, modularization problem is expressed in the first point:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

Modularization is fundamental because it represents the barebone of divide-et-impera strategy: reduce problems to simple concepts. Mastering modularization let us solve real-world problems.

The modularization problem in the State of Art of software development has been addressed, and still be, using microservices. But, in more recent time, with cloud technologies (lambda functions).

And OOP? What about OOP?

I have strong opinion on OOP. I know that many of you have been taught about OOP in college, high school and courses. Me too.

I think OOP is meaningless for professional software development.

(If you're not convinced with this statement please comment below AND put a Github/Bitbucket link with an example where OOP simplified your life)

I will publish an article about this topic and OOP design patterns: the evil of evils.

Contributions.

Do you have insightful books to suggest? Post it in the comments, I'd like to read them and feedback with an opinion.