DEV Community: Jakub Stibůrek

Neon + Postgres.js: The Perfect Combo for Your MVP Project

Jakub Stibůrek — Wed, 02 Aug 2023 13:56:30 +0000

I was choosing the tech stack for a small MVP project. I went with a familiar backend framework Nest.js. But I wanted to do something new regarding the DB.

In this particular project I had to develop a feature that would let users import a bunch of CSV files and then generate a huge table out of the data. I knew that the generation itself can be done in a single SQL query (although it was gonna be a fat one).

So instead of choosing a serverless document DB I wanted a standard relational DB and specifically Postgres. But I didn't want the hustle of hosting and managing it. Then I discovered Neon.

Neon, a serverless Postgres

The fully managed multi-cloud Postgres with a generous free tier. We separated storage and compute to offer autoscaling, branching, and bottomless storage.

neon.tech

Serverless connotes effortless deploy, scaling and availability. Serverless functions are quite well known concept now. You probably know the Firebase implementation or AWS lambda functions. Basically it's a piece of code that you don't have to host, monitor, manage... etc. yourself. You write it, ship it and it just works. If it doesn't get traffic, it automatically scales down or completely turns itself off. On the other hand on the occasion of a sudden surge of requests the functions gets more resources allocated automatically and your business continues to make you rich.

Ok so imagine having a database that scales automatically and turns itself off when you don't use it. That's Neon. And if you need to add a few extra billions of rows, no problem the storage scales too.

Branching, a killer feature

Consider how you develop and test changes to the DB, be it the scheme or data migration. You might have a staging environment with some fixtures simulating production DB. You try your change first there then you clench your ass and do the same thing on production. Neon got better solution for that.

At any point of time you can duplicate, branch off, your database. So your new workflow might look like this: create a new branch out of prod. branch (main), run your migrations, test or somehow check that everything went ok, then run the migration on main. Since you've tested your migration on a disposable exact copy of the production DB you can be sure that your change didn't wipe all your business data or whatever hellish scenario you can come up with.

It's similar to how GIT works. So any developer can create their branches and delete them any time. Also it's fast and easy to do so. And now there is a CLI for Neon which makes the workflow easier and can facilitate automation.

There must be more use cases for this feature but I'm not a DB specialist so you tell me (in the comment section).

Still a technical preview but...

Yeah, Neon is still officially in technical preview stage. But the Neon developers basically keep it this way due to their perfectionism. They have a feature list they want to create and until those are done, they won't officially kick the product off. But the main things are done and they work well. Meaning the database itself, scaling and branching.

I've encountered problems with the SQL editor on the Neon dashboard. (The web dashboard overall has this beta feeling to it.) The editor throws syntax errors on me but when I run my scripts in a DB admin on my machine, it works. And as of now there is no feature that would let you gather logs in some useful way, which can be a bummer for many users.

Postgres.js, I choose you (and not an ORM)

Let's use the Neon DB in a Node and specifically Nest.js app.

I don't like to work with ORMs. I'd rather separate the DB from my backend because I'm concerned with separation of different system layers. I consider it a bad practice when data mixes with logic of the system. Coupling them makes it way harder to change anything, more prone to bugs and from a certain size of the project impossible to change or certain decisions.

On top of that I'd rather write SQL then use some kind of builder. I feel like this kind of abstraction is not very helpful. But rawdogging SQL as string is bound to introduce bugs to your code. So I think that library like Postgres.js is a perfect solution. It makes use of JS template strings and checks that your queries make sense. Yes you can still make a typo in a field or table name but that can be solved easily by your IDE. For example I use WebStorm as a DB admin tool and when I have the the DB introspected I get code suggestions when writing SQL.

There are some quirks you need to get used to when using this library and yes it's also a kind of abstraction especially when nesting SQL expressions but it resembles the SQL more then any builder while still keeping you safe.

Implementation in a Nest.js app

Let's get coding! When creating a DB and a branch in Neon you get connection details. Save these details to the .env file and let's build a simple DB service which we can use throughout our application.

# Neon postgres connection  
PGHOST="..."  
PGDATABASE="..."  
PGUSER="..."  
PGPASSWORD="..."  
ENDPOINT_ID="..."

import { ConfigService } from '@nestjs/config';  
import { Injectable } from '@nestjs/common';  
import * as postgres from 'postgres';

@Injectable()  
export class DbService {  
    constructor(private configService: ConfigService) {}  // 1

    private PG_HOST = this.configService.get<string>('PGHOST');  // 2
    private PG_DATABASE = this.configService.get<string>('PGDATABASE');  
    private PG_USER = this.configService.get<string>('PGUSER');  
    private PG_PASSWORD = this.configService.get<string>('PGPASSWORD');  
    private ENDPOINT_ID = this.configService.get<string>('ENDPOINT_ID');  

    private readonly URL = `postgres://username:password@host/database?options=project%3D${this.ENDPOINT_ID}`;  // 3

    readonly sql = postgres(this.URL, {  // 4
    username: this.PG_USER,  
    password: this.PG_PASSWORD,  
    host: this.PG_HOST,  
    database: this.PG_DATABASE,  
    ssl: 'require',  
    });  
}

First we grab the Nest ConfigService which gives us access to the environmental variables
We extract them. (Notice that validation is missing here, so if I forget to provide .env file the app crashes, don't do that)
Here we prepare the URL string
The Postgres.js gets the URL string we've prepared, fills in the variables in place of the keywords like username and returns the postgres.Sql method. (Notice that the ENDPOINT_ID is not one of the predefined aka standard Postgres connection elements so I've just baked it in the string using template string)

Since my app is built using the Nest.js framework I make use of the dependency injection which is a big part of the framework. So this service can be registered as a provider in any Nest.js module. Like so:

@Module({
    imports: [ConfigModule],
    exports: [...],
    providers: [DbService, GetUsersPgOperation],
})
export class InfrastructureModule {}

The ConfigModule from Nest must be accessible to our service in order to reach the environmental variables.

Finally let's use the service to get a list of users.

export class GetUsersPgOperation {  
    constructor(  
        @Inject(DbService)  // 1
        private db: DbService,  
    ) {}  

    async execute(): Promise<User[]> {  
        try {  
            const result = await this.db.sql<UserInterface[]>`select * from users_table`;  // 2

            if (!result) {  
                // handle this  
            }  

            return result.map(...)  
        } catch (error) {  
            // handle error
        }  
    }  
}

Grab the service
Call the sql method, provide return type and the query itself. (Return type must be an array because it represents the rows which our DB will return)

That's it. We have a reliable, serverless Postgres DB available to our application!

Thanks for reading and please let me know what you think about Neon, my implementation or how horribly wrong I'm about ORM in the comment section.

Agile vs. SCRUM

Jakub Stibůrek — Mon, 01 May 2023 11:06:35 +0000

Agile is like communism. It fails because it has never been implemented correctly.

As far as I understand the main driving force behind legends like Cunningham, Beck and Fowler gathering at a mountain cabin and instead of having a nice BBQ party coming up with the Agile Manifesto was frustration. They were working in the corporate environment that was awfully inflexible, punishing and just overall not suitable for developing software. I guess the kind of programmers who have been building their stuff in garage haven't faced the same problems as the manifesto-men. So it was this group of hardened and frustrated programmers who put together these 4 values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

They also have come up with 12 principles but the core values are enough for figuring out why Agile Manifesto exists. Obviously the four things on the left were at the time sidelined in favour of the four things on the right.

Documentation, plan, processes... that sounds like a bridge construction project! The favourite comparison of SW development and bridge-building is a bit flawed. Civil engineering and software engineering are obviously different disciplines but so are mechanical engineering and electrical engineering. The overarching notion should be that each engineering discipline is different and thus the software engineering should be treated accordingly as a separate discipline.

Agile Manifesto was a public movement that has pointed this out and tried to give us a description of what building software is and how it should be approached.

Idea vs. Methodology

The Agile Manifesto is an expression of an idea. A model of software development and how this kind of work should be approached. (Reading the 12 principles now is a good idea.)

The Agile Manifesto is not a prescriptive document. It doesn't give us a todo list that upon completion would grant us the AGILE stamp. It sure does suggest some practices but no methodologies.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

There's nothing about how, when, how often etc. should such conversation happen. It's simply saying that instead of sending an email or memo you should get up, come to your coworker and tell them what you need.

Simplicity--the art of maximising the amount of work not done--is essential.

It's up to you to decide what this means. Minimising premature optimisation? Perhaps.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

There is nothing specific about this principle. It just states that you should confer regularly how you do your work.

What brings specificity to the table are agile frameworks. Unlike the manifesto frameworks are prescriptive. They suggest methodologies that should be practiced in order to use the framework effectively.

For example XP (extreme programming) comes up with things like sprint, pair programming, mob code review, mob programming etc. SCRUM comes up with its ceremonies aka meetings. Kanban is the ubiquitous project board.

In an essence the Agile Manifesto is exactly what manifestos are, an idea. The frameworks are then exercising the idea, interpreting the principles and values and putting them to practice.

SCRUM Ceremonies aren't Agile

Unfortunately SCRUM is almost synonymous to agile these days. Due to that people who would sincerely like to make agile work for their team and coworkers have often no choice but to do SCRUM.

Now, what is a ceremony? For anyone outside the SW development it's probably tight to religion or some social practice. The Cambridge dictionary:

(a set of) formal acts, often fixed and traditional, performed on important social or religious occasions

And here's the definition of ritual which I believe to be very similar to a ceremony:

a way of doing something in which the same actions are done in the same way every time

"formal act", "fixed", "done in the same way every time" well that sounds an awful lot like a corporate process. Let's remind ourselves the first agile value: Individuals and interactions over processes and tools. This is why SCRUM is flawed.

Here's a list of usual SCRUM ceremonies: daily standup, refinement, planning, retrospective, demo.

Standup can last 5-20 minutes the other meetings can take 20 minutes to 2 hours. Often it's about 4-5 hours each sprint doing meta-work = working in order to eventually actually work on the software. On top of that many organisations and teams have company-wide meetings, various guild meetings, interest-groups meetings etc. And to take it to the extreme these meetings tend to be longer when working remotely because of technical problems and the fact that many people in one video-call just slow everything down. And don't get me started on the mental toll that these activities have on people. The ceremonies stress the same muscle as the work we do - the brain.

Simplicity--the art of maximising the amount of work not done--is essential.

In the spirit of agility let's assess the meta-work that ceremonies are and find a way how to minimise the time spent on them.

Daily: if you have a blocker, talk to someone who can help you immediately. For checking the status of work, see the board.
Refinement, planning: in my opinion these are contradictory to the agile principles in the most blatant way. They serve only as micro-management tools.
Retrospective: if you have an idea how to improve the way we do our work, present it to the interested people whenever you have time. You can talk about it at lunchtime.
Demo, review: this is probably only reasonable meeting. Gather the team and the users and show them what's been released and how to take advantage of it.

SCRUM ceremonies are not necessary and definitely not agile. They as a core part of the framework render it as a whole not agile. The amount of focus on meta-work itself is contradictory to agile principles which stress the importance of actually working on the software. Does that make SCRUM bad? Not necessarily but it makes it bad agile implementation.

Agile is like communism. It fails because it has never been implemented correctly. Because everyone tries only SCRUM.

My Few Ideas

for the authors of the Agile Manifesto communication was crucial. But communication must be natural and needs no schedule. Communicate whenever you need it, don't wait for a meeting.
don't do any meta-work. Concentrate maximum of your time on developing and/or discussing the software.
focus on building your own methodology, your own practices and let them naturally surface. Like the nature of the product, the work itself is volatile. Using a prefabricated framework leads to apathy, inefficiency and bad software. Abolish ceremonies.
Consider moving away from sprints. They don't bring much value to software developers or users. They bring value to the management because they introduce subtle deadlines and a way how to measure (although inefficiently) work. Develop whatever you agree on is most important and when you are done just pick another feature and show the finished work to the users.
lastly not working in an agile way doesn't necessarily mean that you have to get back to waterfall. Agile is relying heavily on the face-to-face communication. It can be hard to work that way remotely for example. Just imagine open-source software being built in an agile way. It doesn't work. Agile is meant for small concentrated teams. Don't be afraid to embrace a different approach.

Better keys

Jakub Stibůrek — Wed, 28 Dec 2022 10:25:09 +0000

As a self-taught software engineer I'm quite used to having a different view on certain topics than my peers coming from technical backgrounds. Most often it's about our approach to organising work or communicating rather than the coding itself. One of the first things that have struck me when I started to code, even when I wasn't a professional yet, was the health issues and that a lot of IT professionals ignore them. Working as a SW developer inevitably means hours spent in front of a computer every day. So I looked at my desk and the things that I use to produce code. I saw a monitor, keyboard, computer, table and chair and I thought about the ways I can improve these to not get the carpal tunnel syndrome (or many more health problems induced by this way of life) in 10 years.

I actually started with my monitor and not the keyboard because I was using a laptop back then and I was going to get a second monitor. My primary focus wasn't to get the highest frequency or the best colours. Don't get me wrong I wanted to get the best product I could afford but mainly I wanted a monitor that would go easy on my eyes. I purchased a monitor that can adjust contrast and brightness on the fly based on the conditions in my room. Looking back I would get a different model because I now don't use two or three monitors setup but a single big one (at the office) and the one I have at home is too small for my liking. But still it's quite pleasant to look at it in the evening when the light in my room is dim. My eyes don't hurt even if I don't use a dark theme in my IDE (yes, I'm a light-theme-using psycho). And the monitor can be easily moved up and down to be at the right level for the person using it.

Down the rabbit hole

Soon after I've got myself a second monitor (so I had a laptop and two monitors on my table) I decided that a standalone keyboard would be more practical than using the laptop build-in even though I was pretty content with it. I went to a local computer shop and tried a few displayed keyboards. I found out that there are basically two kinds of keyboards out there: mechanical and membrane. And so my journey to the mechanical keyboard realm has begun. Anyone who owns one must know how treacherous and deep this rabbit hole is.

Well initially I didn't know of course... and I got myself a gaming mechanical keyboard. Low profile stacked with shiny LEDs that would be enough for an entire U2 show. It was kind of expensive compared to a basic 10€ membrane keyboard but still cheap for a mechanical keyboard. And it broke soon. Some keys stopped working and I was pissed. Unfortunately I couldn't return it because I tried to fix it and I messed up and broke it even more. But as I poked the thing and I googled a few things I found out that the switches (that's what goes clickity click when you press a key) are actually not very common even for a low profile keyboard. You see there is two or three common interfaces that connect a switch to a keycap and those I had on my first keyboard were some knockoff that wasn't compatible with anything. So I had to get a new keeb. And I was just starting my research on the mechanical wonderland.

Why?

I'd like to briefly explain how these keyboards work and what kinds are there available but before that I want get to what initially made me buy a mechanical keyboard.

When typing on most membrane keyboards and predominantly on laptop keyboards the feeling of pressing a key can be mushy, sometimes keys respond to any slight touch, some keyboards bend, keys rub one another, etc. the main point is that you get what the manufacturer serves you, like it or not. And I just felt like I want a keyboard that would fit me and my hands. The mechanical keyboards are produced usually in a small quantity by invested people for their peers, you have to often put them together yourself but even if they are pre-built you still have some degree of control. You can choose the size of the keyboard, maybe you don't need a function row or a numpad... you can choose the switches, how hard are they to press, whether they make sound or not, haptic response, how precise are they and so on.

At the beginning I didn't even know what else I can customise, yet I was already sold on the idea of custom keyboard.

Mechanical switch

How does a membrane keyboard work?

Mechanical switch actually predates a membrane keyboards. It was the original way how keyboards were made.

So a pro tip: If you want a mechanical keyboard and you are on a tight budget, just get an old keyboard from 80's or 90's from your local used electronics shop.

Nowadays keyboards are usually membrane. That means that a key is actuated by two thin metal pieces touching. This design has many advantages over the mechanical keyboards. Firstly it's much cheaper, it's thinner and it's quite durable. You can even prevent it from short circuiting when you spill a coffee on it quite easily.

This diagram shows how a membrane key actuates.

How does a mechanical switch work?

You can see how a mechanical switch actuates when pressed on the diagram above. This particular switch is called Cherry MX Red and it's a very popular switch used e.g. in pro-gaming. It's so called linear switch. Meaning that the moving part is traveling from the initial position to the actuating position with no obstruction along the way. These are very precise and that's why they are popular among gamers.

The second kind of a switch is so called tactile, this particular is a Cherry MX Brown. These switches have a little bump on the moving body which upon actuation gives a haptic response to the finger. I personally like the feel of pressing a button which these tactile switches provide and I think they are the best kind for typing.

Source of the gifs

The third diagram shows a Cherry MX Blue which is a tactile and clicky switch. Unlike the linear switch this one is not silent. You can see that the moving body is made out of two parts. The white part jumps when the switch actuates resulting in a quite loud click which you either love or hate. Either way I don't recommend using these in an office. You might get hit by a mere basic Logitech keyboard in the face.

Here is a nice video explaining the difference between a mechanical and membrane keyboard.
Mechanical vs Membrane Keyboards: Are Mechanical Keyboards Worth It?

Layout

Have you ever looked at your keyboard and wonder why is that the letters are arranged in this particular way? Why is the top row widest and the second and third row slightly thiner and kinda shifted to a side? Why is the space button so big? The questions could and should go on. You can find many videos on the internet explaining why QERTY keyboard layout has won the most used layout prize. TLDR is that we just got used to it. But since you have already read all the text above this paragraph you know that can't stop me!

I wasn't ever taught how to properly touch type. I have learnt to somehow type fast and even without looking at the keyboard myself as a lot of people do. This might sound like a disadvantage but actually that means that when you want to learn to touch type properly you can consider yourself a clean sheet. You don't have to limit yourself to a status quo layout, learn some DVORAK maybe.

Yeah there are many alternative keyboard layouts that have been put together by a chance, method of science or compulsive need for symmetry. You can even try to create your own unique layout since you are building your keyboard, you can have your layout as well. I even tried to do it the scientific way. I took my mother tongue (Czech) and got some data on the frequency of letter occurrence and their combinations then I laid those most frequent on the home-row (that's the starting position for your fingers when you lay them on the keyboard, on qerty it's 'asdfghjkl;'). Then the less frequent on the edges and so on. Unfortunately I have never actually tried this layout. I soon realised that I write more English on my keyboard than Czech and I need to write a bunch of special symbols since I'm a programmer. So I gave in on creating my own layout.

And on top of that I realised that even though I'm going to have my own special keyboard I still would from time to time need to use a laptop keyboard or someone else's keyboard and it could be quite hard after I've spent some time learning some totally different layout. So in the end I personally have kept using QERTY on all of my custom made keyboards and I don't have any trouble using the standard keyboards. (Unless they don't have English legends, then I'm lost.)

Nevertheless I strongly support use of alternate layouts and perhaps one day I'll also switch.

BUT you don't have to give in to the peer-pressure all the way. There is still one distinct problem of the standard kb layout. The width of lines and the shift (which is called stagger). It bothered me that to write 'FRV' my left index finger would have to go up and left and then down and right. Try it. This is so unintuitive and awkward. Remove the stagger and align the letters in neat columns and you get an ortho-columnar layout. Much better.

This was but a beginning of my 'ortho' journey. But if this is already something you'd like to use there is this keeb preassembled and easy to program.

End game?

After I've spent some time typing on a mechanical keyboard, but still the standard qerty staggered layout, I've done the aforementioned research. I've found out about alternate layouts, staggerless ortho-columnar keyboards and finally about split keyboards. As I've mentioned before my end goal is to have my keyboard, meaning I wanted a keyboard that would fit me, no factory made standard bs. And one of my biggest concerns from the beginning was health. I knew going in the programming career that I'll spend thousands of hours typing and siting (actually I've a standing desk so some standing is going on as well) in front of the computer and I want to minimise the consequences of this lifestyle. Kinda like sportsmen know about the stress their career puts on their body and so they take precautions.

A split keyboard consists of two halves. They can be completely split and connected via bluetooth or a cable or they can be kinda still together but separated by a few inches of plastic. My keyboard(s) are split and connected by a TRRS cable.

This model is called Kyria and you can get a DIY kit here.

Why have I chosen to build and use Kyria. Such a weird keyboard... it doesn't even have a legend on the keys. Is there enough keys for everything that I have on my laptop keyboard? I get you. I've listened to people admire the weirdness and also to just laugh at it. Let me explain how it works and what are the benefits.

The white keys are standard qerty layout so if you can touch type, you can use this keyboard just right to type. There is no big space because there is no real need for it on a modern keyboard. On this kb space is one of the blue keys in the left thumb cluster. The blue keys are either modifier keys like cmd, shift, ctrl, etc. or a layer swap keys (I'll explain layers soon) or some kind of macro key. I have for example a macro to switch input language to Czech and back to English. I have a macro for signing out of my computer.

The arrangement of the keys, as you can see, is ortho-columnar and I've talked about the benefits of that but they are not ortho-linear. The stagger on Kyria is much different from the standard columnar stagger which serves no real purpose. The linear stagger is used to compliment your fingers because they are, as you may have noticed, not of the same length. So the layout basically copies the shape o your hand. One way of going even further would be to not use a pre-designed kb like a Kyria but to design it from scratch to match your hand exactly. I might once get there.

Now where the hell are numbers, function row, brackets... that's where the layers come in. The idea behind Kyria is that your fingers never have to travel more then one key from the home row to type anything. So using a firmware like QMK or ZMK we can program the keyboard to do anything and one common technique is to create multiple contexts (layers) which change the behaviour of the keys. You then assign some keys (in my case those in thumb clusters) to switch the contexts. So to write down (35-45) I have to switch from my querty layer to brackets, special and numbers characters layer. It takes some learning but in the end it's very effective.

Here are some of the layers that I have programmed for my kbs.

You may think that I've already taken it to the extreme but check this mad lad out.

Is this the end game for me? Have I found the right keeb for myself? At the moment I'm pretty content with what I have. I'm experimenting from time to time with some modifications like a rotary encoder etc. and I was thinking about building another keeb that would have the number row because Czech special characters are quite hard to tackle using the layers or key combos and on standard keyboards the number row is where these are located.

Conclusion

There is many ordinary things around us that we've got used to never change and often changing them would probably bring more harm than benefits. As engineers say "If it works don't change it but pretend like you did.". I'm looking at you Apple. BUT sometimes trying to look at such an ordinary thing as a keyboard from a different angle may pay out. I have to admit that this journey, have it not become my hobby as well, would be tedious. The total customisability always comes with a lot of work. You should consider whether this is a thing that you should spend time on. If you can't or don't want to spend too much time building your very own keeb, there is a bunch of options which are somewhere in the middle, you can customise them but only in some aspects, e. g. Ergodox have a split keyboard that you can program to your liking.

Ultimately I hope this article have entertained you and perhaps gave you some insight in the realm of mechanical keyboards.

Domain-Driven Design by Eric Evans

Jakub Stibůrek — Mon, 08 Aug 2022 07:00:57 +0000

When I took on my current role at Betsys as a Node.js developer, I was quite thrilled to start working in a whole new field, both in terms of programming, since I was a FE developer before, and also from the business perspective since I used to work at a software agency and now I'm working on a product. There were plenty of things that I had to learn, e.g. the Nest.js framework, Angular to help also on FE side of the application, hexagonal architecture and DDD - Domain-Driven Design.

This concept was unknown to me even though it's apparently been around for quite some time and has gained a lot of popularity among those who design robust software systems - the enterprise kind. I did get some introduction to the topic from my team members but that wasn't enough. I then found out the origin of this concept - which is the book by Eric Evans.

This article would be too long if I were to sum up the whole book, so I have focused only on the main principles that you're gonna need if you want to employ DDD. The rest of the book, that I have not covered, is also full of examples which are really helpful, but I don't see the point in copying them here.

Ubiquitous language

Fans of Philip K. Dick should be intrigued when they see the word ubiquitous or shortly Ubik. But in the case of DDD this isn’t a spray that reverses regression of time and space. The ubiquitous language is actually a foundation of DDD. If all you take from DDD is ubiquitous language, then you have already learned an important lesson.

Usually people who work with code, people who design graphical interfaces, people who work with clients… they all tend to have their own jargon, specific vocabulary. One group might refer to a user of an application as a client, other as a customer. Developers can call a group of data a table but to a business analyst these are simply stock items. When these professionals get together their languages may collide. Someone may stand out as a so to speak translator, a person who have learnt multiple of these languages. Then they become a bottleneck of the communication.

The fact that different professions have their way to speak and talk about they work is… well a fact. We would hardly get them to change they jargon and it wouldn’t be much useful. But people naturally, when trying to achieve a common goal, want to and try to communicate effectively. Paying attention to this human trait, cultivating it and investing in it our time and energy bears fruit.

So on a software project different teams have their language but they share a common goal. They want to develop a piece of software and they need to talk about it for various reasons. We also need to realise that the communication is crucial. Software development is a teamwork (mostly) and core concept in teamwork is communication. Key thing to achieving smooth and effective communication is minimising ambiguity and maximising clarity. We all need to be on the same page. Thus we need a common language to talk, write, document, model, plan… our project.

It would be naive thinking that such language can be put together at the beginning of a project and used effectively during the whole life of the project. Ubiquitous language should feel natural so its creation must also be natural and natural processes take some time. Basically the whole team and even clients, everyone involved in the project should right from the beginning at least know that there is a goal of having some ubiquitous language. A bit contrary to the beginning of this paragraph, a significant amount of the vocabulary will be created at the initial phase of the project as the basic form of a model will be put together. Some foundation has to be present when embarking on an adventure that developing software is. But this foundation must be scrutinised. Throughout the project’s life more and more precise language and model will be shaped naturally.

Important notion about the foundation of and ubiquitous language is that it should not be a synthetic mix of different jargons, vocabularies etc. The DDD defines a domain expert, a person who knows the most about the project’s domain. It can be for example a user of the to be created SW. Now the domain expert’s language should be the foundation of the ubiquitous language. We want the whole team to be able to talk about the domain and using an existing language is natural, compared to making up a completely new one probably consisting of a professional vocabulary forced on to the domain. I can even imagine this foundation being right in the beginning of a project altered by let’s say a developer to better reflect how the domain will be represented in the model and the actual code. But this is already initialising the process of creating a working ubiquitous language.

The ubiquitous language is quite similar to what is in linguistics called a pidgin. The pidgin is a kind of made up language. When two tradesmen from different cultures have met for the first time, speaking completely different languages but sharing a common goal - making a deal - they would eventually create a new language, simplified mixture of the two original languages designed only to achieve the common goal.

Practical tips for ubiquitous language

keep an up to date dictionary. It's an easy to maintain documentation of the project and can help immensely to onboard new team members.
discuss and scrutinise the language as often as you can, this way you not only get a consensus but also make everyone consider twice how will they name their next variable, function etc.

Isolating the domain

It can be hard to focus on one thing when another thing gets in your way. How can you find anything in your drawer when there is everything in there. It would be much more practical to have a few drawers one for each kind of things you want to keep there. If you are familiar with the office drawer cabinet you can take that as an illustration of the concept that will unfold on the lines to come.

Understandably the DDD must focus on domain. That is the one thing. But when developing an application there is more things that we have to deal with other than domain. We need to show something to the user, we need to store data somewhere, etc. An quite often in an OOP program the domain is spread in the whole project. There is a piece in the UI, piece in a controller and some of it right at the place where we query our database. At scale this brings a lot of problems. It gets hard to follow the trace and we can easily change the business logic when fixing some UI issue. Much like when we want to get something from a drawer everything in it moves inevitably and uncontrollably.

The solution presented by DDD and a prerequisite for applying the DDD principles is to separate concerns. Most importantly, isolate the domain from the rest of the application. The separation of concerns can be fairly complex but commonly it is done by creating layers. The DDD requires practically just two layers - domain layer and everything else layer - but that wouldn’t be thorough. So instead of such simplistic solution, DDD encourages at least 4 layered structure. The layers are: UI layer, application layer, domain layer, infrastructure layer.

Layer	Description
User Interface (or Presentation Layer)	Responsible for showing information to the user and interpreting the user's commands. The external actor might sometimes be another computer system rather than a human user.
Application Layer	Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
Domain Layer (or Model Layer)	Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.
Infrastructure Layer	Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.

Evans, E. (2004) Domain-Driven Design. p. 70

DDD only really requires one isolated layer which is the Domain Layer.

The "domain layer" is the manifestation of the domain model and all directly related design elements.

Simply because it's impractical to mix the domain with other parts of a program - the domain model must be separated. How we decide to further isolate other parts of the structure is entirely up to us.

Expressing the domain-model in the software

Entity

Basis of any domain model are objects. They describe different actors, patients, commodities etc. of the domain and in OOP they carry the actions that can be invoked on them. Some of these objects are unique. Like a customer for example. We need to be sure that one customer can't be mistaken for another. We need to express and ensure their uniqueness within the program. These objects are called Entities in DDD.

The uniqueness of an Entity mustn't rely simply on its attributes. There can be two customers living in the same building and having the same name. There is thousands of Toyota Corollas yet they are not the same. Each of them has some kind of identifier to tell them apart. Perhaps a VIN number. Similar to that, Entities tend to have an ID (or some other unique attribute, a fingerprint).

To ensure system that is not error prone we need to match Entities predominantly by these fingerprints. Creating such IDs that persist through time and even in distributed or mixed systems is a delicate matter. Still the concern of DDD is to have unique entities identified.

Value Object

Many objects have no conceptual identity. These objects describe some characteristic of a thing. They are not merely missing an identity they are holding a value that can be used independent of its application. E. g. digit 7 doesn't need any ID because it's nothing unique. You can use it in "17" or "57" and we don't care which instance of the digit 7 you have used.

Another example is a child drawing a picture with crayons. If the kid wants to use a yellow crayon to draw sun and there is 3 yellow crayons on the table, the child doesn't care which one they use. Its identity is irrelevant. But if the crayon is a storage item of an art supply store we may want to identify it in some way.

Whether an object is a VO or an Entity is something to be discussed and depends on the context. When we design a model we should ask ourselves do we need this object to be differentiated from others? If the answer is "Yes." then it's an Entity and vice versa.

An Entity may be comprised of VOs. VO can be, since they aren't unique, reused or shared by Entities. For example when two people have a same name we don't need to create a second "John" we can reuse the first one. But to make sure this is safe VOs must be immutable. So to change a value you need to use another VO and not change the original one's value. If John changes his name to Clarence we mustn't change the content of the "John" VO, we need to use the "Clarence" VO.

A Value Object can give information about an Entity. It should be conceptually whole.

Services

In OOP developers fit everything from the domain to objects - attributes and functionalities. The same developers commonly stumble upon a functionality that they can't properly assign to an object because it may fit to multiple objects or none at all. Such functionalities are in DDD called Services. They are independent from Entities and VOs. We keep Services separated in order to not distort conceptuality of Entities and VOs and they hold no state.

Services are also called operations. Each operation should perform one functionality, its name should come from Ubiquitous language. Parameters and results of an operation should be domain objects.

If you are not a fan of OOP you may take this a step forward and separate all the functionality from domain objects. Keep in mind that this article focuses on the book by Eric Evans but DDD is not exclusive to OOP as it may seem in this book. Actually DDD fits well with functional programming and it's compositional principle. You can learn more about that in videos by Scott Wlaschin And feel free not to constrain yourself with the choice between those two paradigms, in fact at our company we mix concepts from both and the result is great developer experience.

Conclusion

This book has a lot more to offer: how to refactor toward a deeper domain insight, practical examples, using DDD in large-scale application... I only wanted to offer you a summary of the main concepts but I strongly recommend you to explore the book yourself.

Rust Journal [0]

Jakub Stibůrek — Sun, 13 Feb 2022 12:40:34 +0000

Today marks the first time ever I have written a Rust code. I have followed “the book”, the official handbook for the Rust language (here it is) , and have written two programs: Hello world and Guess the Number Game.

How have I learned about Rust. I’m actually a web developer and I usually work with JavaScript or TypeScript on front-end. So I develop web UI. I have no CS degree and all the official education in CS I have constists of what they have thought me in high school, which wasn’t much since it was only an electrical engineering school. I’m from Europe and high schools work quite different from those in US here, the high schools here center around a certain goal: e.g. go to University, professional aim etc. I have learned web development on my own and felt pretty acomplished when I’ve succesfully started a career in programming.

Nevertheless I’m at the point now where I feel like what I’m doing isn’t enough. I’m not really sure what I want but I feel like I should try to make something different than another web app or website. So I have investigated what other languages or technologies I might be interested in. And suddenly my favourite YT channel, which focuses on 100 second long (more like 100 sec short) videos explaining various programming topics, published a video about the Rust programming language. And I felt like - wow this is it.

What is it actually that got me so much interested in the language on the first brief sight? I have no idea. But I know that I want to understand it and that’s the only driving force necessary for starting a new learning journey.

So it begins. And I wonder where will this journey get me.

Learning in public

I’m planning on trying the technique of learning in public. Many people online recommend doing it. It supposedely should make me not quit and by trying to explain things make myself understand them better. The second thing I know for sure works because I have worked as a language teacher before, the first thing... we will see. Anyway if you want to follow my journey, I’ll be posting updates here and later on my personal website (that one is under reconstruction at the moment so I’ll share it with you when it’s done).

Goals

I believe that I should have a certain goal or goals in front of me so that I know how far I’m in the progress and what lies in front of me. I’ll try to make up a few points that I feel like are acomplishable in the near future.

[ ] learn the basic syntax
- quite self-explenatory I believe
[ ] make a simple CLI program
- I’ve got the recommendation from another YT person that CLI is a good starting point and I could actually make something really useful to me right from the beginning
- I’m thinking of currency rate calculater or something of that sort
[ ] learn about connecting to the web
- I want to know, eventualy, how to make a REST api, because that’s again something I could really use, e.g. creating a backend for my personal website
[ ] make a simple REST api
- by simple I mean one endpoint or something like that
- maybe I could make the CLI program I would have done by this time accesible on the www
[ ] make new goals
- I know already that it would take me at least a few months before I get here, so nothing further needs to be planned, when I get here I’ll figure out some proper project

Conclusion

I have started to learn a new programming lanaguage. I hope it will be a lot of fun and I’ll get to create amazing things with it and I want to try to do it in public. If you feel like you wanted to start something new lately, join me and learn with me. We can move each other forward.

The book: https://doc.rust-lang.org/book/

The 100 sec channel: https://www.youtube.com/c/Fireship

The Let’s get rusty channel: https://www.youtube.com/channel/UCSp-OaMpsO8K0KkOqyBl7_w

My GitHub where I’ll store my Rust projects: https://github.com/JakubStiburek

Learn the basics of algorithms and data structures

Jakub Stibůrek — Wed, 15 Sep 2021 12:49:09 +0000

For anyone who hasn't gone trough a proper CS program the programming theory is a challenging topic. Learning how to code, learning syntax and just using the chosen programming language is already a challenge. Soon (when one aims to get to a professional level) student finds out about more abstract topics which are not a matter of a particular language but they are shared amongs many. Such topics are programming paradigms like OOP or functional programming, algorithms, etc. Algorithms are particularly important, since we all are using them no matter the language or framework we prefer. As a self-taught developer I have felt that I'm missing out on this fundamental knowledge which is not commonly taught on the internet. So I have researched for a book that would help me understand it at least a bit. Unfortunately most of the theoretical literature consists of thick and hard-to-read books. Well except the grokking algorithms by A. Y. Bhargava.

Contents of the book

It's structured into rather independent chapters covering always one coherent topic (it's always a specific algorithm, except for the beginning of the book ). Depending on the knowledge you already have you can read it in two ways, chapter by chapter: that is obviously best for those with zero knowledge, or you can cherry pick chapters: and this is probably best approach for the second reading or for those who know about some of the algorithms already. But overall it's a book for beginners so experienced programmers will probably find it useless.

Big O Notation

One of the first concepts introduced is a so-called Big O Notation. This is, simply put, a measurement of time efficiency of a given algorithm. Even with the contemporary computers if one chooses a wrong algorithm for the job, they can wait for years for it to finish.

"big o" ---> O(n)

Data structures

Throughout the book you'll learn not only about algorithms but also about data structures. For us, JavaScript, developers this is quite foreign topic. There is an array in JS but what it really is and how it actually works? Well that's a topic for another article. However in this book you will learn what is: array, queue, linked list, stack and hash table.

The algorithms

The author has picked only a handful of algorithms but also the most important or rather most useful ones or even better put those which you might most probably see in the code you work with at work.

Starting with binary search, quicksort going trough Breadth-first search, Dijkstra's algorithm and finishing with K-nearest neighbours.

I've found the book most useful in the early chapters because it helped me to put together scarcely found information on the internet and the latter topics I sometimes had a hard time to grasp and I will definitely get back to them once I will need it.

One of the side-topics is Recursion chapter which I found very important because this is an idea that you build many algorithms on top of and you will most probably use it in a real-life project at some point.

Do the exercises (when you feel like doing them)

The author stresses out multiple times that readers should open an editor and try running or writing the code themselves. The code examples in the text are written in Python but JS being my language I have tried to write some of the algorithms myself.

I do agree that having the code in your hands helps but as I don't usually like to read sitting by the desk I've tried out only a few of the samples and whenever I felt that I don't need to see it on the screen I just skipped and understood it anyway (hopefully).

Conclusion

I haven't really talked about the drawings in the book. This wasn't really a selling point for me because I don't have this type of memory and I'm quite used to learn from textbooks but I can see that it may be an important thing for a lots of readers - so simply put the illustrations are well made, comprehensive and funny.

I really recommend to get a copy of this book and keep it close by to be able to reference it when needed. It helped me a lot to feel comfortable about another theoretical aspect of the programming.

...

This is my first ever article published here and also the first text I have written on a technical topic, so I hope you've found it helpful and enjoyed reading it.