Forem: Nathanaël CHERRIER

Optimize your SwiftUI code: Two ways to avoid duplication

Nathanaël CHERRIER — Sat, 24 Jun 2023 14:19:20 +0000

Code duplication is a real problem in applications. Having a lot of duplicate code means “complicated maintenance” but also a catastrophic experience.

I have two methods to avoid this problem in my Swift applications. I'll tell you all about them in this article.

Custom components for greater SwiftUI code modularity

As you would with other frameworks, SwiftUI allows you to create views in a declarative/descriptive way.

The views are composed of other views and the pattern can be repeated endlessly on several levels.

struct SignInScreen: View {
    var body: some View {
        VStack(alignment: .leading, spacing: 10) {
            Text("Connect")
            Spacer()
        }
    }
}

In the example above, the SignInScreen view is composed of a VStack view, a Text view and a Spacer view. Same operation therefore as a web framework or the global component will be composed of several smaller components.

Since views are just assemblies of views, we too can create our own views to bring together repeating elements.

struct SignInScreen: View {
    var body: some View {
        VStack(alignment: .leading, spacing: 10) {
            TextField("Email address", text: $email)

            DividerCustom()

            Button("Connect") {
                // action
            }
        }
    }
}

struct SignUpScreen: View {
    var body: some View {
        VStack(alignment: .leading, spacing: 10) {
            TextField("Email address", text: $email)

            DividerCustom()

            Button("Sign Up") {
                // action
            }
        }
    }
}

struct DividerCustom: View {
    var body: some View {
        HStack(alignment: .center) {
            VStack {
                Divider()
                    .frame(height: 1.0)
                    .background(.green)
            }
            Text("or")
            VStack {
                Divider()
                    .frame(height: 1.0)
                    .background(.green)
            }
        }
    }
}

The DividerCustom view combines three other views and thus forms a view that is called in the SignInScreen and SignUpScreen view.

Modifying the DividerCustom code will update the element in both components where it is used. This prevents the code from being duplicated several times in the application.

Optimization with modifiers and `ViewModifier`

Sometimes, what is duplicated is not a set of components but a set of modifications on a single view.

struct Buttons: View {
    var body: some View {
        Button {
            // action
        } label: {
            Label("Connect with Google", image: "GoogleLogo")
                .frame(maxWidth: .infinity)
        }
        .padding()
        .frame(minWidth: 300, alignment: .center)
        .background(backgroundColor)
        .foregroundColor(foregroundColor)
        .cornerRadius(30)
        .font(.Theme.regular(size: 16))

        Button {
            // action
        } label: {
            Label("Connect with Facebook", image: "FacebookLogo")
                .frame(maxWidth: .infinity)
        }
        .padding()
        .frame(minWidth: 300, alignment: .center)
        .background(backgroundColor)
        .foregroundColor(foregroundColor)
        .cornerRadius(30)
        .font(.Theme.regular(size: 16))

        Button {
            // action
        } label: {
            Label("Connect with GitHub", image: "GitHubLogo")
                .frame(maxWidth: .infinity)
        }
        .padding()
        .frame(minWidth: 300, alignment: .center)
        .background(backgroundColor)
        .foregroundColor(foregroundColor)
        .cornerRadius(30)
        .font(.Theme.regular(size: 16))
    }
}

In the example above, we want to display three login buttons for different services.

We don't want to change the behavior of a classic button or even associate it with other views so that they work together. What we want here is to modify the design of the button so that all the buttons look the same.

We will end up with 6 lines of modifications of a button which are duplicated each time a new button is created.

If I ultimately want to change the button's maximum width, I'll have to apply the change manually for each button!

One solution to avoid code duplication (and simplify application maintenance) in this situation is ViewModifiers. This is a very simple way to apply modifiers to multiple views:

struct BasicButton: ViewModifier {
    let backgroundColor: Color
    let foregroundColor: Color

    func body(content: Content) -> some View {
        content
            .padding()
            .frame(minWidth: 300, alignment: .center)
            .background(backgroundColor)
            .foregroundColor(foregroundColor)
            .cornerRadius(30)
            .font(.Theme.regular(size: 16))
    }
}

A ViewModifier is a struct with a body function. It is this function that will apply the styles to our views.
To use it, we use the generic modifier modifier() as follows:

Button {
  // action
} label: {
  Label("Connect with GitHub", image: "GitHubLogo")
    .frame(maxWidth: .infinity)
}
.modifier(BasicButton(backgroundColor: .black, foregroundColor: .white))

And that's it!

BasicButton will apply the styles to our Button view with no more effort.

To make the code a little more elegant, here is a little trick:
And we call this function from our Button view like classic modifiers

Button {
  // action
} label: {
  Label("Connect with GitHub", image: "GitHubLogo")
    .frame(maxWidth: .infinity)
}
.withSteplyDefaultStyle()

We first add a function to the View class that will call the modifier.

extension View {
    func withSteplyDefaultStyle(foregroundColor: Color = .white, backgroundColor: Color = .blue) -> some View {
        modifier(BasicButton(backgroundColor: backgroundColor, foregroundColor: foregroundColor))
    }
}

Note also the use of optional parameters, so you don't have to mention them if they do not change.

You can also limit the use of this modifier to the Button view by extending the Button class rather than View, as we have done here.

The downside is that you will only be able to call the modifier directly on the view. It cannot be chained after other modifiers because this one returns an object of type View and not Button.

Conclusion

As already discussed, avoiding code duplication is not only a good practice to make your code look “pretty”. Rather, it's one of the easiest ways to optimize your code to reduce development time and application maintenance time.
Do not hesitate to use the ViewModifier or the creation of custom components to optimize your SwiftUI code.

How to connect to a distant server using SSH

Nathanaël CHERRIER — Mon, 20 Feb 2023 13:44:27 +0000

Using SSH to connect to its servers seems like a basic thing, but for many, SSH remains an obscure software/protocol. We will clarify all this, and we will take the opportunity to go a bit further.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

What is SSH?

Here is the definition given by Wikipedia:

Secure Shell (SSH) is both a computer program and a secure communication protocol. [...] All TCP segments are authenticated and encrypted. It therefore becomes impossible to use a sniffer to see what the user is doing.

Simply put, SSH is a secure “Shell” that allows us to take control of our remote servers.

It also allows you to do a multitude of other things, but we won't see them here.

Installing SSH

To be able to use SSH, you will have to install it on the server machine and on the client machines.

On most Unix machines (including Linux and Mac) SSH is a package installed by default. If however on your machine this is not the case, you can launch a command like:

sudo apt-get install ssh

Change the package manager and its syntax to that of your distribution.

For those who have a Windows client machine, you can install SSH clients like PuTTY or OpenSSH.

Configuration

Now that you have installed SSH, you will need to configure it.

By default, all users on the server can initiate a remote connection with SSH. That means we can already use our machine remotely. On the other hand, we wouldn't want some smart guy to be able to log in as root on our server.

To prevent this, we will start by creating a new user on the server.

# Serveur
adduser userName

Answer the questions posed by the utility, and your new user will be created and usable by SSH.

# Serveur
adduser userName sudo

We add our new user to the list of users who have the right to perform certain tasks normally dedicated to the superuser without being one.

Connection using keys

Many attacks using the SSH protocol use the “brute force” method. Because of this, password-based logins are less secure than key pair-based logins.

Let's give our user the ability to login by keys.

# Client
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

This command creates an RSA encryption key of 4096 bytes. ssh-keygen generates a public key and a private key. The private key should never leave your machine and should never be shared with anyone.

# Serveur
mkdir ~/.ssh

The public key we just created must be transferred to the remote server and added to the list of keys authorized to connect with the new user.

# Client
ssh-copy-id -i adresse/de/votre/clepublique.pub user@server

If you do a test now (ssh user@server) SSH should not ask you for a password to initiate the connection.

If you are prompted for a password, it means something went wrong with the steps above. I advise you not to move on without having solved the problem.

☝️

If the connection fails for no apparent reason, verify that the key PubkeyAuthentication is indicated as yes in the file /etc/ssh/sshd_config.

Small additional security tweaks

Now that our new user is ready, let's prevent root from logging in and change a few things.

# Serveur
vim /etc/ssh/sshd_config

Change Port to any numeric value (retain it) above 1024, PermitRootLogin and PasswordAuthentication to no. You should have :

Port 2923
PermitRootLogin no
PasswordAuthentication no

Thus, hackers who try to connect to your server on port 22 will fail. They also won't be able to log in directly to root and have all rights too easily.

The last line prevents password authentication. So, no more “brute force” attacks, attempts by clever little guys who think they have found your password. Anyone who wants to connect to your server must have their public key (or one of their keys) saved in your machine.

To sum up:

# Client
ssh user@server.com -p 2923 # to log in 

ssh user@server.com # doesn't work
ssh root@server.com -p 2923 # doesn't work

`.ssh/config` : simplify your life

Imagine that you have several servers to manage, that for each one you have a different pair of keys, a different user: it is easy to see the mess that can become. A solution exists, the file ~/.ssh/config.

# Client
vim ~/.ssh/config


Host sous.domaine.com
  IdentityFile /home/user/.ssh/privatekey

Host domaine.org
  IdentityFile /home/user/.ssh/privatekey2

Thanks to the IdentityFile key, SSH now knows which private key to use for domain.org and sub.domain.com hosts.

Host sous.domaine.com
  IdentityFile /home/user/.ssh/privatekey

Host nomPersonnalisable
  HostName github.com
  IdentityFile /home/user/.ssh/privatekey3

Host nomPersonnalisable2
  HostName github.com
  IdentityFile /home/user/.ssh/privatekey2

If you have two accounts on GitHub (or two users on any server) and different key pairs for each account, you can add the HostName key with the domain name value and change Host to a customizable name. Thus, you can have two different SSH configurations for the same server.

Host gitserver
  HostName git.com
  User userName
  Port 2923
  IdentityFile /home/user/.ssh/privatekey2

Two other interesting keys to know are the User and Port keys. Their name couldn't be clearer, and the example speaks for itself.

It's a simple config that allows us to connect to our server by typing:

ssh gitserver

You can compare both versions of the connection command, the last is obviously simpler.

How to secure a web server (VPS)

Nathanaël CHERRIER — Thu, 12 Jan 2023 05:00:03 +0000

There are several reasons why a developer would want to manage their own servers. Servers, especially VPS (Virtual Private Server), have become very affordable resources. They allow us to test, build, host our projects and do many other things.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

Whatever use you make of a server, it must be protected, because an intrusion could have serious repercussions. In this article, I explain how to secure a VPS simply in 5 simple steps.

☝️ I assume that you have just purchased your VPS and that you have never connected to it before. But, most of the steps are feasible on an already running server.

1/ Update your system

This may sound basic to you, but one of the primary reasons for finding flaws in web servers is system obsolescence. Not updating your systems regularly is a real danger for your business.

Even if you have just requested the installation of your VPS from your host, you will benefit from updating your system before moving on to the rest of this article. Indeed, hosts often use backups or snapshots to create new servers. So, there is a good chance that the packages on your system need updates.

Run the following commands:

$ sudo apt update
$ sudo apt upgrade -y

2/ Change `root` password

I'm not sure it's worth explaining. Change your root password.

$ sudo su
$ passwd
New password: 
Retype new password: 
passwd: password updated successfully
$ exit

The root account is the “super-administrator” account. He has all the rights. If there is an account that we refuse to leave in the hands of hackers, it is this one.

But changing the root account password is not enough. You will see that a little further in the rest of the article.

3/ Create a new user

Another tip to avoid problems on your server: don't use root. I see at least two reasons for this:

everyone has a root user on their machine by default. It's easy for a hacker to guess
root has all rights on the machine. If a person finds the root account password, he can do anything on the machine

☝️ Some hosts, to limit this problem, change the name of the root account. Don't think you're protected, though! As explained above, because of the automation of their process, they often give the same names to all customers. It is therefore enough to know who your host is to know how it works, and therefore to know how to attack your machine.

The best solution to prevent this problem is to use a different account to manage your machine. To do this, use the following command:

$ adduser nameOfTheUser
Adding user `nameOfTheUser' ...
Adding new group `nameOfTheUser' (1001) ...
Adding new user `nameOfTheUser' (1001) with group `nameOfTheUser' ...
Creating home directory `/home/nameOfTheUser' ...
Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for nameOfTheUser
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []: 
        Work Phone []: 
        Home Phone []: 
        Other []:
Is the information correct? [Y/n]

After answering all the questions of the utility, let's tell the system that this new user will be able to perform actions usually dedicated to the superuser without being one.

The idea is to be able to say “I'm not a superuser, give me no rights” but temporarily, when the situation requires it, tell the system “in fact, I'm the superuser, let me do this one-time action”.

$ adduser nameOfTheUser sudo
sudo adduser nameOfTheUser sudo
Adding user `nameOfTheUser' to group `sudo' ...
Adding user nameOfTheUser to group sudo
Done.

Now you will be able to type the sudo command from your new user account without receiving a system denial. You can also connect in SSH directly with this user.

4/ Change SSH access

Now that only you know the password for the root account, and you no longer use it to connect to the server, it's time to go a little further.

What are the problems we might encounter? Brute force attack. You no longer use the root account, but it is still usable. Using randomly generated passwords until one works is a method that still works today.

The method would also work on the second account that we created above.

To remedy this, we'll modify the SSH configuration somewhat to log in using an RSA key rather than a password. To be able to log in with a key, you first need... a key.

So let's generate ours on our local computer (not the server).

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

-t allows you to indicate the type of key you want to create. We want an RSA key.
-b specifies the size of the key. I usually put 4096 so that it is twice as long, complex and solid as the default 2048 bites. But, you can put the size you want. Just tell yourself that depending on the power of your computer, the more you ask for a long key, the longer it will take to generate (and use?) it.
-C allows you to add a comment to facilitate your organization.

The command will ask you for a passphrase. It is a sentence that must be indicated to use the key. A kind of password to protect the key. You can leave it out, but it is strongly recommended that you do put one.

Once the key is generated, you will find two new files on your local machine.

$ ls ~/.ssh
id_rsa id_rsa.pub

id_rsa is your private key. Not to be communicated under any circumstances. It must not leave your machine and allows you to decrypt the data that is sent to you.
id_rsa.pub is the public version of your key. To communicate to those with whom you wish to communicate. It does not make it possible to decrypt the data, but only to encrypt them. In other words, it allows people to write messages that only your private key can decrypt.

As I just said, the private key will not move from your machine. However, to be able to communicate with the server, the server must have your public key. So, we have to send it to him.

No need to open the file and copy-paste anything, there's a command for that:

$ ssh-copy-id -i ~/.ssh/id_rsa nameOfTheUser@ipOfTheServer

This command will create the ~/.ssh folder in your user's account on the server. Then, it will create the file ~/ssh/authorized_keys in which it will add the public key linked to the private key id_rsa.

Normally, this command sends all public keys from your local machine to the server. To avoid this, we use -i to tell it which key to send.

You can now connect without passwords to the server by doing ssh nameOfTheUser@ipOfTheServer. Only the passphrase will be requested if you have specified one.

Since it is possible to log in without passwords, all we have to do is disable the login with passwords. Thus, the risk of brute force will be eliminated. To do this, on the server, edit the following lines in the /etc/ssh/sshd_config file to have these values:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

With these settings, it will be impossible to log in with the root account whether you know the password or not. All other accounts will be inaccessible with a password, but accessible if you have the correct RSA key.

Last detail, the standard port used by SSH is 22. It means that everyone knows this port. To make the access a little more complicated, a good practice is to change this port to a value between 1024 and 6665.

In the same /etc/ssh/sshd_config file, modify the following line with the value of your choice:

Port 5489

To validate these changes, restart the SSH agent as follows:

$ sudo systemctl restart ssh

Your server now looks a bit more like a fortress. ssh nameOfTheUser@ipOfTheServer will no longer work. You will need, in addition to the user and the IP, to indicate the port that you have chosen previously. The password will not be requested, you will need the RSA key to be able to connect.

$ ssh nameOfTheUser@ipOfTheServer -p 2345 -i ~/.ssh/id_rsa 
Enter passphrase for key '~/.ssh/id_rsa':

☝️ I agree that for greater security, we have largely sacrificed the simplicity and usability of this command. But, it is possible to simplify it again thanks to the file ~/.ssh/config.

5/ Enable a firewall

The firewall allows you to control who can connect to your server and how. The idea is to avoid leaving windows open in our fortress. We will therefore explicitly specify what we allow as a connection to our server.

Most Linux distributions have iptables and ufw installed by default. I use UFW. I will therefore explain to you the basic rules that I apply for the security of my servers. To learn more about how this tool works, I recommend this article from DigitalOcean.

We start by disabling the firewall while we make our changes:

$ sudo ufw disable

Next, I change the default rules so that all incoming connections are denied, and all outgoing connections are allowed:

$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

Next, we'll allow SSH connections. Otherwise, we will no longer have a way to connect to the server.

$ sudo ufw allow 2345/tcp

Change 2345 to the port you chose for SSH in the previous step.

⚠️ UFW knows the default ports for services and offers helpers like ufw allow ssh. But don't use it for SSH precisely, because you no longer use the default port 22. You risk blocking all SSH connections since SSH no longer listens to port 22.

Now we can activate the firewall.

$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

As we no longer use the default SSH port, if you still have connections using port 22 (on another terminal, for example), UFW warns you that you may lose your connection.

☝️ You can verify that your rules are correct before activating the firewall using the ufw status verbose command.

Now you have all the basics to secure your servers. There are of course many other things that one can implement to secure a server, but with the 5 steps in this article, you will have a server that is much less vulnerable to attacks.

I have also prepared for those who wish it a print which includes all the commands of this article, a glossary and an explanation of the changes of the sshd_config file. Nothing more than what is in this article, but the idea is to have a cheat sheet to quickly secure your server.

If you are a premium member of the blog, download it below. Otherwise, you can find “VPS/server security cheatsheet” on the store.

How to code a basic HTTP server using NodeJS

Nathanaël CHERRIER — Wed, 23 Nov 2022 17:28:00 +0000

A good method to learn and progress in programming is to try to re-code existing projects. This is what I propose in this article to learn more about Node.js.

This article is aimed at beginners without dwelling more than necessary on the basic notions of this environment. Feel free to visit the list of articles on Node.js and JavaScript to learn more.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

When I started learning Node.js, the HTTP server was the typical example that was quoted in all articles, blogs and other courses. The goal was to show how easy it is to create a web server with Node.js.

const http = require('http')

const server = http.createServer(function (req, res) {
  res.writeHead(200)
  res.end('Hello, World!')
})

server.listen(8080)

"Hello, World!" de NodeJS

Well, we quickly realize that it takes a little more code to have a real website, thanks to Node.js. This is why backend frameworks for Node.js have multiplied rapidly. The best known of them is called Express.

Express is easy to use, quick to set up and has a very large community.

const express = require('express')
const app = express()

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(3000)

"Hello, World!" by ExpressJS

Without further complicating the code, the code above allows you to return a string for an HTTP method and a specific route. It is very simple to add routes in the same way as for /.

Express is very lightweight. It uses a middleware system that increases the capabilities of the framework.

For example, to allow Express to understand the JSON in the body of an HTTP request, you must use the bodyParser middleware.

How does Express work?

For those who already knew Express before this article – and even those who are discovering it now – have you ever wondered how Express works?

What if we code a small web framework to understand how our tools work? Don't misunderstand my intentions. The purpose of this article is not to code yet another framework in an ecosystem that is already saturated with them, and even less to produce production-ready code.

Besides, I advise you in general not to “reinvent the wheel” in your projects. Node.js has a rich universe of open-source modules for all your needs, do not hesitate to dig into it.

On the other hand, even if in everyday life it is better to use an existing backend framework, that does not prevent you from coding one for purely educational purposes!

Let's code a backend framework in Node.js

As I put the “Hello, World!” code of Node.js and Express, I will also put mine for you. This will serve as our goal.

import { createServer } from './lib/http/create-server.js'
import { url, router } from './lib/http/middlewares/index.js'
import { get } from './lib/http/methods/index.js'

const server = createServer(
  url(),
  router(
    get('/', () => `Hello, World!`),
  )
)

server.listen(3000)

"Hello World!" of our "from scratch" framework

This code does exactly the same thing as the one in Express. The syntax differs a lot — it is greatly inspired by RxJS's .pipe() — but it's still about displaying “Hello, World!” when the user goes to / and to return a 404 if going to an unknown route.

In the idea, we find the Express middlewares through which the request will pass to create a response to return to the client (the user's browser).

It's a very simplified diagram, but you get the idea.

You may have understood it, thanks to the syntax (and the reference to RxJS), I would like us to manage to have a rather functional approach with this project. When done well, I find it produces much more expressive code.

The HTTP server

The first function to implement is createServer. It is just a wrapper of the function of the same name in the http module of Node.js.

import http from 'http'

export function createServer() {
  return http.createServer(() => {
    serverResponse.end()
  })
}

createServer creates the server and returns it. We can then use .listen() to launch the server.

The http.createServer() callback function can take an IncommingMessage (the request made by the client) and a ServerResponse (the response that we want to return to it) as parameters.

One of our goals is to have a middleware system that will each in turn modify the request to gradually build the response to be returned to the client. For this, we need a list of middlewares to which we will pass the request and the response each time.

import http from 'http'

export function createServer(middlewares = []) {
  return http.createServer((incommingMessage, serverResponse) => {
    for (const middleware of middlewares) {
      middleware(incommingMessage, serverResponse)
    }

    serverResponse.end()
  })
}

To retrieve the middlewares and have the same syntax as the .pipe() of RxJS, I use the rest parameter that we saw in a previous article.

import http from 'http'

export function createServer(...middlewares) {
  return http.createServer((incommingMessage, serverResponse) => {
    for (const middleware of middlewares) {
      middleware(incommingMessage, serverResponse)
    }

    serverResponse.end()
  })
}

Thus middleware such as url and router can modify incommingMessage and/or serverResponse by reference. At the end of our modification pipe, we trigger the .end() event which will send the response to the client.

A few things still bother me about this code:

incommingMessage and serverResponse are directly modified. I would prefer that they were not to stay closer to the philosophy of functional programming.
All middleware must be called in our implementation, but Express allows you to stop the “pipe” of modifications if necessary. This is useful for an authentication middleware, for example.
Some middleware might need to block the execution of the modification “pipe” to perform slightly longer tasks. Currently, our code would not wait and the execution of certain middleware could overlap in time.

So let's fix all that. First, the last point. It's the easiest to set up.

import http from 'http'

export function createServer(...middlewares) {
  return http.createServer(async (incommingMessage, serverResponse) => {
    for (const middleware of middlewares) {
      await middleware(incommingMessage, serverResponse)
    }

    serverResponse.end()
  })
}

Thus, if the middleware is executed asynchronously, we will wait for the end of its execution to move on.

To avoid the modification of incommingMessage and serverResponse, I think the easiest way is to use the return value of the middlewares. These are simple functions, let's use them as such: input values that must not be modified, but which are used to construct the return value. This return value is then used as the input value of the following (middleware) function. And so on.

import http from 'http'

export function createServer(...middlewares) {
  return http.createServer(async (incommingMessage, serverResponse) => {
    let requestContext = {
      statusCode: 200,
    }

    for (const middleware of middlewares) {
      requestContext = await middleware(incommingMessage, requestContext)
    }

    serverResponse.writeHead(requestContext.statusCode)

    if (requestContext.responseBody != null) {
      serverResponse.end(requestContext.responseBody)
      return
    }

    serverResponse.end()
  })
}

I created a requestContext which is a working object for middlewares. It is passed as input value to all middleware alongside the request.

The middlewares process these values and create a new context, which they then returns. We overwrite the old context with the new one which is more up to date.

When we are done modifying the context by the middlewares, we use it to emit the response from the server.

Finally, to be able to stop the pipe in the middle, I found nothing better than a small boolean. We can add it to the context. If a middleware changes it to true, the pipe is broken and the response is sent directly with the current context:

import http from 'http'

export function createServer(...middlewares) {
  return http.createServer(async (incommingMessage, serverResponse) => {
    let requestContext = {
      statusCode: 200,
      closeConnection: false
    }

    for (const middleware of middlewares) {
      if (requestContext.closeConnection === true) {
        break
      }

      requestContext = await middleware(incommingMessage, requestContext)
    }

    serverResponse.writeHead(requestContext.statusCode)

    if (requestContext.responseBody != null) {
      serverResponse.end(requestContext.responseBody)
      return
    }

    serverResponse.end()
  })
}

Parse the request URL

Let's move on to writing our first middleware: url. Its purpose is to parse the URL of the request to provide us with information that other middlewares might need next.

export function url() {
  return (incomingMessage, requestContext) => ({ ...requestContext })
}

The middleware API is simple in our framework.

This is a function that can take as parameter everything it may need for its operation or to allow the user to modify its operation. Here url does not take any parameters.

This function will then return another function which will be executed later in the for loop (const middleware of middlewares) of the createServer callback. It is this function that takes incommingMessage and requestContext as parameters and then returns a new version of requestContext.

export function url() {
  return (incomingMessage, requestContext) => ({
    ...requestContext,
    url: new URL(incomingMessage.url, `http://${incomingMessage.headers.host}`),
  })
}

The url middleware adds to the context of the request a url attribute which contains a parsed URL object.

We can therefore make requestContext.url.pathname and have access to the pathname of the request.

The router of our framework

The router of our framework will also be a middleware usable with createServer.

To make it simple, we will define a route as follows:

const route = {
  method: 'GET',
  pathname: '/',
  controller(incommingMessage, requestContext) {
    return `Hello, World!`
  }
}

This object is made up of three essential pieces of information for our router:

the concerned pathname
the HTTP verb used
the function capable of generating something to return to the client

As input to our router middleware, we will take an array of routes.

export function router(routes = []) {
  return (incommingMessage, requestContext) => {
    for (const route of routes) {
      if (route.pathname !== requestContext.url.pathname) continue
      if (route.method !== requestContext.method) continue

      return {
        ...requestContext,
        responseBody: route.controller(incommingMessage, requestContext),
      }
    }
  }
}

Each time a client makes a request to the server, the router will scroll down the list of routes and check which one matches the client's request. As soon as it finds one, it stops the loop and executes the controller function of the route.

What the controller returns can then be added to the context as a responseBody. This is what the server returns to the client.

export function router(routes = []) {
  return (incommingMessage, requestContext) => {
    for (const route of routes) {
      if (route.pathname !== requestContext.url.pathname) continue
      if (route.method !== requestContext.method) continue

      return {
        requestContext,
        responseBody: route.controller(incommingMessage, requestContext),
        closeConnection: true,
      }
    }

    return {
      ...requestContext,
      statusCode: 404,
    }
  }
}

To make the client understand what happens when the router can't find the requested route, I added 404 error code handling after the loop. The return in the loop stops the function completely, so if the function did not stop in the middle of the loop, it is necessarily that we did not find a match in the declared routes. We therefore return a context with the statusCode at 404.

With this function, we can declare our routes as follows:

router([
  { 
    method: 'GET', 
    pathname: '/', 
    controller() { 
      return `Hello, World!` 
    } 
  },
])

Everything works fine and we could stop there, but we don't have exactly the same code as the one I showed you at the beginning of the article.

All that's missing is syntactical sugar: code that will only serve to make our features easier and more enjoyable to use.

export function get(pathname, controller) {
  return {
    method: 'GET',
    pathname,
    controller,
  }
}

This function is only used to return the “route” object needed by the router function. Nothing complicated here.

export function get(pathname, controller) {
  if (typeof controller !== 'function') {
    throw new Error('The get() HTTP method needs a controller to work as expected')
  }

  if (typeof pathname === 'string') {
    throw new Error('The get() HTTP method needs a pathname to work as expected')
  }

  return { method: 'GET', controller, pathname }
}

Another advantage of this function is that it allows us quite simply to test our data without complicating the code of our router.

The router is now used as follows:

router([
  get('/', () => `Hello, World!`)
])

We are very close to the result we want to achieve. The last changes are to be made in the implementation of router itself.

export function router(...routes) {
  return (incommingMessage, requestContext) => {
    for (const route of routes) {
      if (route.pathname !== requestContext.url.pathname) continue
      if (route.method !== requestContext.method) continue

      return {
        requestContext,
        responseBody: route.controller(incommingMessage, requestContext),
        closeConnection: true,
      }
    }

    return {
      ...requestContext,
      statusCode: 404,
    }
  }
}

I only modified the routes parameter so that it is no longer an array, but a rest parameter as for createServer.

Thus, we have achieved our goal and ended this article. Appreciate your hard work:

import { createServer } from './lib/http/create-server.js'
import { url, router } from './lib/http/middlewares/index.js'
import { get } from './lib/http/methods/index.js'

const server = createServer(
  url(),
  router(
    get('/', () => `Hello, World!`),
  )
)

server.listen(3000)

If you want to go a little deeper into the concepts seen quickly in this article or go further, I advise you:

What is the JAMstack and why should you use it?

Nathanaël CHERRIER — Wed, 16 Nov 2022 05:00:12 +0000

I still remember the first websites I sold. Simple static sites that no one would want today. However, the last few years have seen the emergence of a technology (or rather an approach to website development) that comes very close to it, but which claims to be much more powerful: the JAMstack.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

I tested it and adopted it. The JAMstack is also what I used to code the latest version of the www.travel-and-food.com site. I explain here what the JAMstack is and why you should give it a try.

From static site to static site

There have been great periods in the world of the web. The first of these is that of the static site. It wasn't called that at the time. It was a site made up entirely of static files: we wrote the structure in HTML, the design in CSS, we potentially added a little animation with JavaScript, and we stored all this on a server which was content to serve the files at the time requested by the visitor.

Basic. Simple.

But, very quickly, there were limits. It was finally quite complicated to maintain. To modify a site, it was necessary to touch the code. And, annoyingly, the site never changed without developer intervention.

In itself, the static site is fine for displaying documentation, but it is impossible to build something advanced with it.

The world of the web has therefore moved on to a second period, that of the dynamic site. It was a big upheaval. Thanks to technologies like PHP, Java, etc., the server was no longer going to just serve the same page forever. These languages make it possible to generate a new page as soon as a visitor requests it thanks to data stored in databases.

It changed a lot of things. For the first time, people were starting to code smart and useful applications. From the blog to the e-commerce site, everything has been made possible thanks to dynamic sites. Once the site was coded and deployed, ~~Muggles~~ non-developer could modify the content without help from the developers.

Unfortunately, these sites have grown to be cumbersome and slow. Each time the visitor reloaded the page, it was completely rebuilt on the server before being sent. Servers having access to more and more content and services, and doing more and more processing, the increase in loading times could become exponential.

We move on to the third great period of the web universe: dynamic interactive websites. The idea behind this barbaric name is to no longer be forced to generate a page entirely to obtain information, and to no longer be forced to reload a page completely to update the information it contains.

The JavaScript language can update the DOM, but it can also request information directly from the server. If we combine these two capabilities, we get AJAX technology.

This technology has helped to relieve the heaviness of dynamic sites by allowing a web page to be partially updated without having to reload it. Dynamic sites had become even more dynamic!

This led to the different technologies we know today, such as the Single Page Application. Server technologies stay on the server (PHP, etc.) and are used to respond to client requests. The display of the client is done directly in the browser thanks to client technologies (JavaScript and its frameworks). The two parties discuss together through APIs.

With interactive dynamic websites, other problems have arisen. In particular, referencing, because the site being generated on the fly by JavaScript, it is impossible for a search engine to retrieve the content.

To sum up, we have:

The static site:

✅ SEO friendly
✅ very little resource-intensive
✅ fast loading time
🚫 requires knowledge of development to update the site

The dynamic site:

✅ SEO friendly
🚫 slow loading time
✅ no development skills needed to update the site
🚫 resource intensive

The interactive dynamic site:

🚫 not SEO friendly
✅ loading time (average) faster than the dynamic site, but 🚫 slower than a static site
✅ no development skills required to update the site
✅ less resource intensive (average) than a dynamic site, but 🚫 more than a static site

It is clear that the static site retains, despite its simplicity, many advantages for him. Of course, this summary is not true in all situations. It's oversimplified and generalized for the purposes of this article, but you get the idea.

Still, the advantages of the static site have pushed part of the web community to find another solution to these disadvantages than going through dynamic sites. They chose to generate the web pages before deployment instead of doing it at request time like dynamic sites do.

This technology is called the Static Site Generator. The idea is to decouple the data from the site code itself. The static site generator is therefore based on data (often Markdown, text files) to generate a site that will ultimately be entirely static. No need to know how to code to modify the content of a static site while enjoying all its advantages.

The patchwork of the best of the web

Of course, the world didn't stand still while we focused on static and dynamic sites. Many things have happened. Technologies have emerged. They have evolved. And some died.

Why are we talking about this? Because the JAMstack is actually a patchwork of many technologies working together. That's why “stack” in the name. Let's talk a bit about these technologies.

The elements that make up the JAMstack

Web APIs. We already talked about it a bit above. They became essential when we started to want to make machines to discuss between them and later separate the frontend from the backend. They are therefore used to communicate. Many standards exist. The most widely used today is REST, which is based on the operation of the HTTP protocol.

CMSs. I am talking here about Content Management Systems in the broadest sense. Just a system that allows you to manage content whether it's text, products or something else. They have the advantage of being specialized, of simplifying content management, of being known to their niche users and often of offering tools specific to their audience. For example, an e-commerce CMS will know how to manage a product and its variants, taxes on it, currency conversion, delivery conditions, etc.

Continuous integration and deployment pipelines, also known as CI/CD, have been making a lot of noise. They are part of the Architecture as Code movement. They allow to describe build, test, and deployment processes of a project that can be played and replayed as much as necessary. They have many advantages and uses, but we won't dwell on them here. What should be remembered is that they allow you to automate the different steps that we have just listed.

Frontend frameworks have simplified development by taking care of a lot of repetitive tasks for developers. They have helped make the development of more complex sites possible. These are also the frameworks that brought to the frontend a form of stability that already existed at the backend. They have improved website performance by optimizing rendering and display tasks. Last advantage, they make the site more dynamic since it runs directly in the user's browser.

Static site generators. As we explained above, these are tools that will generate a complete static website from an external data source in one build step.

JAMstack: a CI/CD pipeline rather than a new technology

I think you see where I'm coming from. People had the wonderful idea of putting all these technologies together to solve most of the problems listed at the beginning of the article.

Diagram of a JAMstack architecture

There are two ways to update our site:

edit website code (for travel-and-food.com everything is on GitHub)
edit site data from the CMS (for travel-and-food.com, I used the Ghost CMS)

These two systems are linked to a continuous integration platform. All software forges have their own version these days (GitHub Actions, GitLab CI, Bitbucket Pipelines, etc.) but there are independent ones like Netlify or Jenkins Pipeline. Travel & Food uses Netlify, which is also its host.

It is the CI/CD platform that will then, as a conductor, take care of all the rest of the process. The CI/CD will therefore run the build of the static site generator. For Travel & Food, I decided to use GatsbyJS as generator. Pendant son build, GatsbyJS connects to Ghost (the CMS) to retrieve the data and loop over it to generate each page of the website.

The static site generator produces a folder containing an HTML file for each page of the site as well as JavaScript and styles. When the build is complete, the CI/CD sends this folder as is to the host.

There is no longer any process that then runs at the host level. Since the site consists of static files, they are served as is when a visitor requests them. No modification or other processing is performed on the files. As a result, we have a huge gain in performance. This also affects SEO and the cost of the project.

When the JavaScript is loaded on the user side, the site “comes to life”, the frontend frameworks take over. We don't have to have non-interactive pages just because it's a static site. Thanks to the JAMstack this is no longer the case.

As frontend frameworks such as ReactJS or Angular support Server Side Rendering (SSR) techniques, a fully static first version of the JavaScript application is available in HTML even before the JavaScript is loaded. Which means that the pure performance as well as the SEO of the site would be better compared to the same site without SSR.

The advantages of the JAMstack

Let's go back to our pros/cons list for the JAMstack:

✅ as SEO friendly as a static site
✅ as fast as a static site
✅ no development skills required to update the site since we use a CMS (or several CMS)
✅ very little resource-intensive

We fill in every point on our comparison list. The JAMstack can have yet another benefit – and we'll end on this – and that is to improve team cohesion!

I'm barely kidding. If you think about it, the content creator is happy because he uses his favorite CMS, the developer is happy because he can use his favorite technology and the marketing manager is happy because the site has good SEO performance.

Trip to Lisbon for Web Summit 2022

Nathanaël CHERRIER — Wed, 09 Nov 2022 05:00:31 +0000

It is only the third event I attend since COVID-19. Still feels weird to meet so many other people at the same time. For the Web Summit 2022 it is around 71 000 people meeting to learn from awesome speakers. In this post, I'll make a full summary of my trip including thoughts about the talks and other useful information about the places, the city, the organization, etc. Will be similar from what I did for the Git Merge in 2019.

Table of Content

How was the event?

From open source to Unicorn: How to build on a project
How do we tackle software's crisis of trust?
Bad data is eating your time
Fundraising for developers: How are technical companies doing right now?
The good, the bad and the automated

Lisbon is a wonderful city

Where I stayed during the conference
A grasp of the city
How was the venue for the Web Summit?

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

How was the event?

This event, as expected, was really great. It is not surprising that so many people travelled there from so many countries. The organization was great, and I learned a lot from all talks I managed to watch.

I'll tell you about all the other aspects of this event later in the post, but for now, I want to share with you my notes from the talks. Keep reading.

From open source to Unicorn: How to build on a project

🧑‍🏫

Speaker: Milin Desai (Sentry), Tim Crino (Inc. Magazine)

As any other businesses, open source needs to make money. The goal of any companies is to make money. So, even if the company is based on an open-source project, it needs a strong business model to succeed.

Most companies choose to have an open source core model. This means they provide the core software as open, but implement some features only for premium customers on their SaaS platform.

Sentry decided to go another way: they provide the complete software as open source. They make money by providing a no-brainer hosting service.

If the customers see the value of your product they are gonna pay for it

Sentry did try to sell premium features like other companies, but they decided to move back on this decision because they felt that paid customer were biasing how they built their product.

Sentry thinks that making the product open source has allowed a strong community to be built around it. That community has helped a lot to build Sentry in many ways. For the company to not feel fake in this community, Sentry is giving back a lot to the open source. They sponsor the best contributors and developers who build tools they use internally. They encourage their employees to contribute to the open source.

How do we tackle software's crisis of trust?

🧑‍🏫

Speakers: Amanda Malko (G2), Tim Crino (Inc. Magazine)

Users do not trust software programs (and most likely the companies behind them) anymore. Studies show that users will trust more other customers reviews than marketing and information provided by the company via its website or a salesperson.

60% of people say they will contact a salesperson only after asking their pairs some insight. They often already decided to buy when they call the salesperson.

Two great options to rebuild trust today are:

Building a community around the brand or the product. If people are looking for pairs' review before deciding to buy, why not facilitate that?
Being transparent and clear about data privacy. Users need clear communication about what data need to be used and what they'll get in exchange for giving their data.

Users want to know if they can trust what they see on a website. Twitter/Musk example is a good example of that it is hard to build trust, but is easy to lose trust.

Two key learnings from Twitter/Musk example:

Human moderation is still essential for the user to build trust
UX is definitely part of the best practices to build trust. This includes feedback loops where users will give feedbacks to companies.

Bad data is eating your time

🧑‍🏫

Speakers: Barr Moses (Monte Carlo), Jennifer Strong (MIT Technology)

Data is becoming unprecedentedly important for the companies and societies using them. We never saw companies investing that much money into data and data-driven organizations before now!

But unfortunately, Barr Moses saw many data-driven companies failing because they couldn't really trust the data they were using. For instance, a big insurance company applied bad credit scores because of the data they used. This resulted in millions of people that lost access to mortgage, and other important contract in the life of an individual, etc. That's why Barr Moses founded Monte Carlo.

She knows the developer/engineering ecosystem. For decades, we have had plenty of tools and automations to help us monitor that things are still working correctly in our systems.

Data are created, updated and transit through those systems, but data analysts do not have the same tools as DevOps to monitor if the data are still correct at any point of time.

The industry needs to understand that having tools to monitor the system that use the data is great, but we lack automated tools to monitor the data in themselves.

Fundraising for developers: How are technical companies doing right now?

🧑‍🏫

Speakers: Max Howell (tea), Rashmi Gopinath (B Capital Group), Eamon Leonard (Broadstone)

The talk used many examples of the open-source world, but most advice could be applied to any business model.

Open source often drives better and more robust software. Plenty of people join forces to build something useful for the community. But it also empowers individuals:

If you're truly dedicated and really want to build something great, you'll find someone on the internet who will want to invest in it.

That's something the “tokenization and decentralization” world proved. No matter the project, you can find someone with whom it will resonate and who will want to put some penny in.

Other pieces of advice:

Do not build a different product for users and for investors. You'll disappoint both.
Do not try to take back your open-source features to make them a paid feature. The open-source community might be offended, and you'll lose users.
Instead, think about enterprise feature like support, SSO, etc. that you can sell to companies.

The good, the bad and the automated

🧑‍🏫

Speakers: Pam Murphy (Imperva), Adam Bluestein (Fast Company)

There are not only human beings on the internet. There are also bots.

Bots help us do a lot of different tasks that doesn't require human brain anymore. But there are good bots and bad bots. And the latter is a big issue of this decade.

The talk tries to sensibilize us to the need to use bots management system to protect our software programs and websites.

Two examples were used to help us understand how bad bots can impact businesses.

First, the PS5 case: the demand for the console was so high that bad actors created scrapping bots to buy quickly most of the available stock on retailers' websites (before real customers). The goal for them was to sell overpriced console on other websites.

Those bots created a lot of frustration for real customers. It ended up becoming a reputation issue for Sony and the retailers, who didn't know how to differentiate human beings from bots.

It also created a financial issue for the retailers. Since the price of the console is given by Sony, retailers do not make a lot of money if they sell a console. Most of their margins come from the additional sale of accessories. But bots don't buy accessories. So even though more PS5 were sold than other consoles, retailers made less money due to the lack of accessory sales.

Second example: Twitter being bought by Elon Musk. Musk asked how many users of Twitter are actually bots. He asked for new investigation about this number of bots on the platform. Why was he that concerned by bots?

Twitter doesn't make money by selling subscriptions, but by selling ads. What makes an advertiser choose Twitter instead of another social media is the amount of real users he can reach. In other words, the more there are bots on the platform, the fewer advertisers will spend money to show ads on Twitter.

This leads to bad revenue or a decrease in the revenue stream. When you invest in a company, you want to make sure you'll be able to have the money back at some point. Hence, the Musk's questions and concerns.

Long story short: bad bots are a real issue for companies and need to be fought.

Lisbon is a wonderful city

As I said, I never went to Lisbon before. Everything was new to me, so I wanted to see the more I could. And that's what I did.

I travelled with EasyJet (for the plane part) and SNCF (for the train part). I have to admit that this last-minute trip to the Web Summit 2022 was a bit hectic. I was so tired when I arrived in Lisbon… You can't imagine how happy I was to find my bed at the B&B!

To summarize the trip, I did:

Châtellerault ⇒ Poitiers ⇒ Paris ⇒ Lisbonne
Lisbonne ⇒ Paris ⇒ Châtellerault

At the airport I decided to use the shuttle service of my B&B hotel to avoid being too late for my check in (I landed at 22:45) but there is public transport service (subway and bus) that allow to commute directly from the airport to the city in approximately 45 mins. I used public transports the other days.

Where I stayed during the conference

I stayed at Asul B&B, a cozy Bed and Breakfast private room. It was perfect to rest before and after days of talks. The owners were very kind and welcoming.

My plane landed late at night, so I used their shuttle service to commute from the airport to the B&B. Everything was great and well managed. Expensive if you compare to local transportation service, but you don't have to worry about ticket, directions, etc. Since it was late, I wanted things to be as simple as possible.

My private room at Asul B&B

There was a shared kitchen in the B&B where everything was at the disposal of the customers. In the morning, someone was paid to prepare breakfast for everyone.

The shared kitchen at Asul B&B

As I said, it was a last-minute trip and the hotel's rooms prices were far too high and mostly fully booked. Looking at the other options available (not so many given the dates), I found this B&B. Even though I didn't have the full house for me, it was cheaper and comfy, clean and with everything I needed to have a good experience there.

Unfortunately, I did not have a lot of time to visit the city. But on my way to and back from the venue, I took some pictures to give you a grasp of Lisbon.

A grasp of the city

I would say it is definitely a beautiful city, but it was rainy during my trip. The weather doesn't give it justice on my pictures.

The Saint Paul's place and some other places around

It looks like a beautiful and old European city with some particularities: colors! You can see it on my pictures, most of the walls aren't only gray or white.

One other specificity of the city (you can see it in Lisbon, but it is a Portugal thing) is the Azulejos. It is like a terracotta tile covered with an opaque glazing. They used it a lot to cover and decorate walls.

It is traditionally white and blue as you can see it on my first picture. But the modern Azulejos have more colors, like the one you can see below. It is exposed in Lisbon's subway station.

Some of the things that must be seen in Lisbon are part of the public transport service of the city. They have the “carris”, which is a nice vintage tramway and many piece of art through the subway station.

How was the venue for the Web Summit?

The venue was one of the biggest I ever saw for a tech conference. It is impressive to see that many people at the same place and a place that can hold them all.

Many actors of the tech industry were here, including some of the brand new “web3 side of the internet” actors like Polkadot or Filecoin.

The web3 and the metaverse was really a strong topic based on the amount of stand and experience dedicated to that topic.

There wasn't only web3 company represented, fortunately! Truth is there were so many stands and talk stages, lounges, etc. that it made navigation a bit complicated.

👍

I would also mention the good quality of the Web Summit mobile application, which really helped me navigation through the 5 pavilions and 71k people… Usually, the conference's apps are awful, but this one is great, so I thought it was worth a mention here.

Let's talk about food now. Food is always a big topic during conferences. There are always discussions about food quality, food quantity and the organization of the lunchtime. Bad organization of the lunch can ruin all the conference from an attendant perspective.

On quantity, Web Summit couldn't make more. There were food trucks and stands everywhere: between each pavilion and around them. This made things easier for attendants to find something to eat without waiting hours in queue.

Food quality was also great at Web Summit. I ate a delicious burger with good quality meat + a coke.

My burger for lunch + the free snacks of the developer lounge

One thing to note though, it is the first time for me that the lunch meal isn't included in the price of the conference (more than 900 euros per person). I went to countless conferences before, they were all way less expensive, but I never paid for my lunch meal during those.

I'm not saying we should or not pay for lunch at conferences. I'm just stating facts here, so you know.

That being said, in the developer lounge, local snacks and coffee were free. I guess it was the same in other lounges too.

Now you know everything about the Web Summit 2022! I truly hope this post will help you if you plan to attend Web Summit in Lisbon in the coming years. Or maybe it already helped you decide whether you want to attend or not.

How to unindex committed files

Nathanaël CHERRIER — Wed, 02 Nov 2022 05:00:15 +0000

Git is a powerful tool that can seem complicated if we know it badly. In this article, we will see the particular case of bad indexing.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

This is a case that can very easily occur when the tool is poorly mastered, but don't panic, there is nothing irreparable. You can make mistakes, correct yourself, start over and learn at your own pace with the trick in this article.

Avoid indexing bad files

There are files we would rather not version with Git. For example, project dependencies (the node_modules directory for a Node.js project), files containing environment variables, or other autogenerated/temporary files.

The .gitignore file allows us to specify to Git the list of files that we do not want it to consider. Create it at the root of your project.

You can specify files, folders or globs there like this:

.env
/node_modules
npm-debug.log*

Once added to this list, the offending files will be invisible to Git. There will no longer be any way to add them accidentally.

Delete file from index

But sometimes we realize that a file should not be indexed only after committing it. An unfortunate git add . or not using git status regularly enough can easily lead to this situation.

If this happens, a simple command exists: git rm.

git rm -r --cached name_of_your_file

Then you just have to commit the deletion of the index:

git add name_of_your_file
git commit

Voilà. The unwanted folder or file should no longer bother you. On the other hand, remember to add it to your .gitignore file so as not to commit it mistakenly again. I refer you to the first part of the article to know how to do it.

7 ways to make money as a developer

Nathanaël CHERRIER — Wed, 26 Oct 2022 04:00:06 +0000

Knowing how to code is a definite advantage in our modern life. Of course, one of the perks that most people care about when I talk about it is money. It's no secret that coding can pay off big. Let's talk about it.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

How to make money when you know how to code? The easiest way is to get hired as a developer. It's easy because the market is in high demand for this type of profile. And, you know the law of supply and demand.

So, if you want job security and don't mind working for a supervisor, go for the full-time employee option. It’s paying well right now (supply and demand still).

But, since most of my readers are developers, they already know that you can earn money as a permanent developer. So, I imagine the question that I often receive must be understood: how to earn money other than by working a 9 a.m. to 5 p.m. for a boss when you are a developer? Or how to earn money in addition to your full-time job when you know how to code?

1. Become a freelancer

Becoming a freelance means setting up your own company and invoicing your clients directly, instead of letting a boss do it and take the bulk of the figure for him.

Well, freelancing can take many forms for a developer. It can be very similar to the employee experience: working at the client's premises to reinforce a development team that the client has formed himself. Finally, only the contract changes (and potentially the salary too) but that changes little of the employee situation and this activity will require a full time. Impossible to do it while being an employee of another company.

However, the freelancer can decide to break away from the employee model by not charging for hours, but for services. For example, coding and selling websites for companies that need them. And, instead of billing monthly for the hours you spent on the project, sell the project itself as a development service. This way the customer is not buying a person (or a person's time) but a service provided by a company, regardless of which human being provides that service, etc.

A small showcase site that cost 5,000 euros can easily be coded on evenings and weekends. You can also get organized with other freelancers to take advantage of each other's strengths / expertise and form your own team of people you want to work with.

It is also possible to step in for a specific functionality on a client's project. This is often called firefighter mode. In this case, the client typically wants you to work fast and well. It pays off.

If, despite the similarities with salaried work, you want to start freelancing, look here:

The marketplace for digital freelancers: www.freelancer.com
The Ghost CMS Expert Catalog: Ghost Experts

2. Sell themes for CMS

If you like the frontend development and want to go for the product approach rather than the service approach, you can develop and sell themes for WordPress, or for Ghost, or for any other CMS.

The good thing about the product approach is that the sale is repeatable. Once the theme is developed, you can sell it to 10,000 people, it won't cost you more time or energy. On the other hand, a product generally sells for less than a service.

Another advantage of themes for CMS: you can go at your own pace, there is no client deadline to respect. You occupy your evenings and weekends as you see fit.

Some useful links:

One of the best-known theme shops: Themeforest
Shopify theme documentation
Ghost Theme Marketplace

3. Sell plugins for CMS

If you don't like the frontend development, CMS still has plenty to keep you busy. Instead of coding themes, why not code plugins that will improve the experience of users of these CMS. Most CMS / platform allow you to sell the plugins you develop in one-time or subscription.

For example, many developers offer apps for the Shopify platform and live off the revenue generated!

To know more:

4. Code a SaaS application

This option is a level above the creation of plugins for CMS. You remain in the creation of utility tools, but you are completely independent of a specific platform.

A well-coded project can then bring you regular income without requiring a lot of time on your part. Even if there will be maintenance, it will not necessarily be useful to add a 1001 new features every four mornings.

Another thing: creating a SaaS application is fun. It is a side project that you will surely have a lot of fun coding. Will you be the next Netflix or the next Stripe?

I advise you to read Monica Lent's blog to continue learning more about the subject. She lives from her SaaS tools.

5. Start a blog

If you like to talk about your knowledge and share it, launch your blog! It's a great hobby, and you'll meet plenty of exciting people.

There are many ways to monetize a blog:

advertisement
paid content
affiliate marketing
guest posting

Moreover, you will build an audience. And, an audience is the basis for launching many other businesses:

sale of t-shirt for developers
sale of courses and trainings
influencer marketing (it started on blogs, not social media).
etc.

However, I'm not going to lie to you, blogging is a long-term investment. It will be almost impossible to make money from the first month of writing. But in the long run, a blog can pay off big and long.

Last advantage for the blog: it allows you to be independent of other web players and to sustain the income streams that you have managed to put in place.

To read to dig deeper into the subject:

An article I wrote for Welcome to the Jungle on this topic: How to Create a Personal Blog as a Developer
The blogging resource library from the Ghost team. These articles are excellent and very formative.

6. Sell courses

We've already talked about it a bit, but a developer can also teach others to code. It is of course easier when we already have an audience that gives us credit. However, it is quite possible to sell courses online without having an audience beforehand.

For this, think of platforms like Pluralsight, tuto.com, Khan Academy, Linkedin Learning, Udemy, etc. These are video training platforms that have allowed hundreds of trainers (including developers) to experience the training they created.

The training can also take the form of an e-book or a book. And, even, a website that you would have created for the occasion.

If you would rather not depend on one platform to sell your training/book, and you already have an audience, read on.

7. Launch an e-commerce site

Why not actually sell products? You can create hundreds of objects about the world of code and development. Then you can sell them on your own online store.

On your store, you can also sell books, cheat sheets, or other training materials.

In fact, an e-commerce site potentially complements many of the options we discussed above. You can, for example, sell your WordPress themes directly on your own store!

On the other hand, the shop will surely be the least technical option of all. If you like to be dirty, apart from coding your store yourself, launching an e-commerce site is not the best idea.

Some tools to help you set up your e-commerce site:

These are not all the ways to make money as a developer, there are surely many more. On the other hand, these are the first seven that have come to mind and which seem to me to be relatively easily achievable.

I also noticed that I had already tested several of these activities and that I have good memories of them. In any case, I hope that you will find what you are looking for in this list, whether you want to increase, replace or diversify your sources of income. Good luck!

Understand recursive functions

Nathanaël CHERRIER — Wed, 12 Oct 2022 04:00:57 +0000

Recursive functions are one of my favorite development techniques. It's not a complicated thing. On the contrary, they are only functions used differently.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

When we learn recursion, and more broadly, iteration in programming, we always stop at the classic iteration structures, loops. But they do not have a monopoly on iteration! In this article, I'll quickly tell you about another recursion structure.

😅

I thought for a long time that I wrote an article here on recursive functions. I discovered today that this is not the case, so I corrected that.

Recursion and loops

When we talk about recursion or iteration, we are usually talking about repeating things. In computing, it is the ability to repeat a defined quantity of instructions.

As we said, the classic way is to use loops for this. Programming languages generally offer several types of loops:

while loops
do...while loops
for loops

But, there are still others. In JavaScript, for example, we can add these to the list:

for...in loops
for...of loops

Generally, the loops added by the languages, in addition to the first three, are ultimately only specific variations of the first three loops.

I'm not going to explain loops to you here. They could be the subject of an article on their own. What must be remembered here is that loops are iterative structures offered by a language to allow a set of instructions to be repeated.

const list = ['one', 'two', 'three']

for(const element of list) {
  // everything between the two braces 
  // will be repeated as many times as 
  // there are elements in list
}

Example of loop in JavaScript

Recursion and functions

Unlike loops, functions are not iterative structures as such. They make it possible to separate a sequence of instructions from the rest of the code in order to be able to execute them again later, on demand.

This last sentence looks a bit like an iterative structure, but here are the main differences that can be noted:

A defined function may be called only once, or even never.
If there is repetition (execution several times), it will be neither immediate nor linear unlike a loop.

A function is therefore not an iterative structure provided by the language. What will make a function recursive, and therefore allow iteration, is the use that the developer will make of it.

Let's see how to make a function recursive.

function addOne(base, times = 1) {
    let result = base

    for (let i = 0; i < times; i++) {
        result += 1
    }

    return result
}

addOne(5, 3) // === 8

Function that uses iteration through a loop

This function is not recursive. It adds 1 to a number given as a parameter as many times as specified by the times variable.

How to do now, to have the same result without the loops?

function addOne(base, times = 1) {
    if (times <= 0) return base

    const result = base + 1
    return addOne(result, times - 1) // everything happens here
}

addOne(5, 3) // === 8

Function that uses iteration through recursion

The recursive function does not change signature. It always takes the base and times variables as parameters. It always returns a number.

What changes here: the function calls itself. That's all.

Let's go through the steps again with the parameters base=5 and times=3 to understand:

Is times less than or equal to 0? No, it is equal to 3, we continue.
result is equal to base plus 1, i.e. 5 + 1, i.e. 6.
We pass the result and times - 1 to the addOne function and we will directly return its return value when done.
Is times less than or equal to 0? No, it is equal to 2, we continue.
result is equal to base plus 1, i.e. 6 + 1, i.e. 7.
We pass the result and times - 1 to the addOne function and we will directly return its return value when done.
Is times less than or equal to 0? No, it is equal to 1, we continue.
result is equal to base plus 1, i.e. 7 + 1, i.e. 8.
We pass the result and times - 1 to the addOne function and we will directly return its return value when done.
Is times less than or equal to 0? Yes, we return base, which is equal to 8.

By doing it step by step, we better understand how a recursive function can completely replace an iteration structure like the loop.

☝️

No solution is better between recursive function and loops. Everything depends on the situation. Think of it as an additional tool that you can use for some particular algorithms.

The secret to mastering recursive functions is practice. Below you will find some exercises that I have prepared for you to progress on the topic 👇

You can also get the Training Sheet: Recursive Functions as a one-time-purchase on the shop.

What is Ubiquitous Language?

Nathanaël CHERRIER — Wed, 05 Oct 2022 04:00:56 +0000

The ubiquitous language is a concept that is based on the fact that the different actors of a project need a common language that allows them to understand the data model without ambiguity and approximation in order to be able to work correctly together.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

In a project team as we understand it here, there are all the people likely to participate in the development of an application. We will therefore find developers and architects, but also users and business experts: as many technical and non-technical profiles. As a result, this often results in misunderstandings related to the terms used to designate the different elements of our model.

The heart of my application is its data model. The data model is business-based. The business is not mastered by the developers or the architects , but by the business experts, who are generally the customers.

This is why it is critical to agree between the production team and the business team on the terms to be used in the model and the code. The best thing is to discuss, argue and define the terms belonging to the ubiquitous language at the beginning of the design phase in order to be able to apply it to the data model and to use it in the code of the application. The code produced will thus be much more expressive.

When a developer talks about the data model and business rules, business experts and even users need to be able to understand exactly and unambiguously what is being said.

Ideally, it should be possible to present the data model of the application to a person totally outside the project, with a non-technical profile: this person must understand how the application works.

The advantages and disadvantages of working for a liberated company

Nathanaël CHERRIER — Thu, 01 Sep 2022 04:00:00 +0000

Today, more and more companies are liberating themselves. The rise of the knowledge society and new technologies has led to changes in the way businesses operate. As a result, employees began to demand a new type of working relationship, one that focused on performance and personal growth rather than restrictive hierarchies.

This article will give you an overview of what a liberated company is, why it has become so prevalent today, and the pros and cons of working for it.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

What is a liberated company?

A liberated enterprise is an organization that has embraced the principles of “free company” with an emphasis shifted from managing resources to managing the people who work there.

The fundamental difference between a liberated company and a conventional company lies in the relationship between employees and management. Conventional organizations are run by the resources they possess, while a liberated business is run by the people who work there. A liberated company is driven by the well-being of its employees and not just by the assets it owns.

The liberated enterprise is driven by relationships, not hierarchies. This shift in focus is what sets it apart from conventional business.

Why do companies free themselves?

The business world has changed dramatically over the past decade, and the traditional workplace is no longer able to meet the challenges of the new competitive environment.

In a world where work organizations are being transformed by the Internet, artificial intelligence and automation, management believes that controlling employees and their time is no longer effective.

The concept of free enterprise is not new. It has been experimented with by hippie communities, tech companies like Google, and New York City taxi drivers since the 1970s. In the 1980s, Japan became the first country to adopt this business model in its entirety to compete with the West, where work structures are very hierarchical.

With economies around the world becoming more service-oriented, the need for creative and collaborative work has increased. As a result, the traditional workplace, driven by the need for efficiency, has been replaced by a freer mode of organization, better able to cope with change.

The advantages of working for a liberated company

Belonging feeling

When you feel like you're part of something and your efforts are appreciated, you're more motivated to work harder. In these companies, you will have the feeling of belonging to a team. Even if you are an individual contributor, you will feel the support of your colleagues because they are there for you.

Personal development

Working in a liberated company means you will have the opportunity to grow, both professionally and personally. There will be no barriers between you and your colleagues. You will have the opportunity to learn from them, and they will be there to help you whenever you need them.

Also, liberated companies often make it possible to change roles and positions. So, it is possible to learn plenty of new skills. And this, even if they are completely unrelated to your core skills.

Increased innovation

When you have the freedom to explore your ideas and share them with your colleagues, you will have the opportunity to innovate. You won't feel like your creativity is limited or that you have to go through hierarchical barriers. Your ideas will be heard and explored by other members of your team, and you can do the same.

Better work-life balance

As work in a liberated company is more organized around individuals, it is easy for the people who work there to achieve a better work-life balance. Since there are no set times or hierarchy, you can decide for yourself when you want to start and finish your work. You will have the opportunity to set your own goals and explore new ideas, as you can collaborate with your colleagues whenever you want.

For example, I sometimes work on weekends or evenings. Not because I'm too busy or not working fast enough. But rather because sometimes I'm not in good shape or not motivated enough during normal working hours (9 a.m. to 5 p.m. Monday to Friday). Truth be told, I work when I'm most productive.

The disadvantages of working for a liberated company

Hierarchy is replaced by bureaucracy

A liberated company is a democratic workplace where there is no hierarchy. Unfortunately, bureaucracy is a natural side effect of this type of organization. To get things done, you will have to go through a bureaucratic process.

By “bureaucracy”, I mean, for example, much more written and oral communication. Since there is no longer a manager who will centralize the information and ensure that it is transmitted to the right people, the information must exist somewhere where everyone can come and consult it.

No fixed hours

While this may sound positive to some people, to others it may be a negative aspect of working in a liberated company. If you're a person who likes to have structure in your life, you might find it difficult to work in a company with no fixed hours.

What allows the balance between work and private life, can also be what will remove this balance. Be careful that this is not the case. Put safeguards in place.

Conclusion

Working for a liberated company can be a great experience, especially if you're someone who enjoys feeling valued and being challenged. If you are passionate about your work and want to feel like part of a team, a liberated company is the perfect place for you.

There are many advantages to working for a liberated company, but there are also disadvantages that you should be aware of. Before accepting a job, make sure you understand the type of company you will be working for.

The best comments are the ones we don't write

Nathanaël CHERRIER — Sun, 07 Aug 2022 09:34:10 +0000

I've read several articles on “good comments”, I've written some, I've read technical books about “good comments” and I work on a JavaScript project where everything must be commented (jsdoc). I changed my mind about that matter.

⚠️ Read more of my blog posts about tech and business on my personal blog! ⚠️

Self documenting code

What I've learned from my experiences and my reading can be summed up by the title of this post.

The best comments are the ones we don't write.

When you feel the need to write a comment, it's usually because your code isn't as clear and clean as it should be.

Compare this :

function main() {
  let imageName = 'test.png'

  // Get the extension off the image filename  
  let pieces = imageName.split('.')
  let extension = pieces.pop()
}

The comment in itself isn't a bad thing. The developer may judge that we could need them later to understand the code better. He puts a comment, it's nice.

But it kind of looks like an excuse : "My code is ugly/complicated but it's not that bad, I'll explain it in a comment" instead of cleaning it.

function main() {
  let imageName = 'test.png'
  let extension = getFileExtension(imageName)
}

The name of a function is already supposed to answer the question of what a code part does. Why not use this possibility?

Too much comments suffocates the code

As indicated above, on my current project we have to document everything. Everything must be commented with jsdoc.

There's nothing bad about it. But in the end, most written comments are comments used solely to pass tests. They're redundant and useless.

/**
 * Get the extension of the file
 * 
 * @param {string} filename - The filename
 * @return {string} the extension of the file  
 */
function getFileExtension(filename) {
  let pieces = imageName.split('.')
  return pieces.pop()
}

Tell me there's an info in that comment you didn't get while reading the code?There's none.

On the contrary, the fact that the function returns the extension of a file is repeated thrice : once in the name of the function, once in the function's description and once in the @return tag.

What is the added value of this comment? There's none.

When you keep seeing useless comments, your brain learns to ignore them. You've probably experienced this before : on a project where there are many comments and a majority of comments like the one we've seen above, you end up not seeing or reading the comments anymore.

Unfortunately, the few interesting comments get lost in the sea of useless ones and aren't as useful as they should.

Code coverage by documentation

As for unit tests, there are a bunch of tools that exist now to measure the code coverage for comments by documentation.

And as for unit tests, you're quickly tempted to reach the 100% coverage.

And as for unit tests, I'm not sure this is something worth doing. For unit tests, a high coverage isn't reliable and isn't a proof of quality ; for documentations, a high percentage of coverage isn't counter-productive and suffocates the code.

By forcing developers to write documentation everywhere, we force them to write lame documentation.

Where the code is clean, the comment will be useless, and your brain will soon ignore it. Where the code is messy, the developer will use the comment as an excuse to not upgrade its code.

I write less comments

… and it's not a bad thing. The code is easier to read. It forces me to make my code as self-explanatory as possible : thus, the code is cleaner. Readers will pay more attention to the few comments I write.

The only problem I'm facing today is in the context of a project with an auto-generated public documentation. How to avoid redundancy while making sure the documentation generated from my comment is complete.

To dig deeper, here's a more recent post that goes deeper into explaining the concept/idea presented here. It follows the feedback and questions from readers :

La documentation sera toujours utile

Forem: Nathanaël CHERRIER

Optimize your SwiftUI code: Two ways to avoid duplication

Custom components for greater SwiftUI code modularity

Optimization with modifiers and ViewModifier

Conclusion

How to connect to a distant server using SSH

What is SSH?

Installing SSH

Configuration

Connection using keys

Small additional security tweaks

.ssh/config : simplify your life

How to secure a web server (VPS)

1/ Update your system

2/ Change root password

3/ Create a new user

4/ Change SSH access

5/ Enable a firewall

How to code a basic HTTP server using NodeJS

How does Express work?

Let's code a backend framework in Node.js

The HTTP server

Parse the request URL

The router of our framework

What is the JAMstack and why should you use it?

From static site to static site

The patchwork of the best of the web

The elements that make up the JAMstack

JAMstack: a CI/CD pipeline rather than a new technology

The advantages of the JAMstack

Trip to Lisbon for Web Summit 2022

Table of Content

How was the event?

From open source to Unicorn: How to build on a project

How do we tackle software's crisis of trust?

Bad data is eating your time

Fundraising for developers: How are technical companies doing right now?

The good, the bad and the automated

Lisbon is a wonderful city

Where I stayed during the conference

A grasp of the city

How was the venue for the Web Summit?

How to unindex committed files

Avoid indexing bad files

Delete file from index

7 ways to make money as a developer

1. Become a freelancer

2. Sell themes for CMS

3. Sell plugins for CMS

4. Code a SaaS application

5. Start a blog

6. Sell courses

7. Launch an e-commerce site

Understand recursive functions

Recursion and loops

Recursion and functions

What is Ubiquitous Language?

The advantages and disadvantages of working for a liberated company

What is a liberated company?

Why do companies free themselves?

The advantages of working for a liberated company

Belonging feeling

Personal development

Increased innovation

Better work-life balance

The disadvantages of working for a liberated company

Hierarchy is replaced by bureaucracy

No fixed hours

Conclusion

The best comments are the ones we don't write

Self documenting code

Too much comments suffocates the code

Code coverage by documentation

I write less comments

Optimization with modifiers and `ViewModifier`

`.ssh/config` : simplify your life

2/ Change `root` password