DEV Community: Mohamed Yamani

How to Deploy a Next.js Application to a VPS Using NGINX and PM2

Mohamed Yamani — Sat, 02 Mar 2024 08:00:00 +0000

This was originally published on my blog.

In this guide I explain how to deploy your Next.js application to a VPS as well as the different parts of the process. If you're only looking for the NGINX configuration files, you can find them in this gist.

If you find yourself in a situation (like I did) where your only deployment option for a Next.js application is to self-host on a VPS, this article is for you.

This article does not promote self-hosting your Next.js applications, although I should write more on that in a separate article. It's a great learning experience to deal with servers directly (without the serverless abstraction).

You need to be mindful that you can be limited by client/project requirements on what tools to use, especially for infrastructure. In which case, what do you do?

Note: the Next.js application we will be deploying uses the Pages Router.

Assumptions

You've configured your domain name to point to your VPS' IP address.
You've configured your SSH key(s) to access the VPS and to connect to GitHub.
You're accessing the VPS with root privileges, so I don't need to use sudo in the commands of this article.

This is going to be as straightforward as your understanding of Next.js itself and servers in general.

What's Next.js?

You need to understand what it is your deploying to be able to deploy it.

So what's Next.js? Well, it depends how you're using it.

If you're using the framework to build an SPA (not SSG), your application is essentially a bunch of static files (HTML, CSS and JavaScript).

However, if need SSR/SSG/ISR or any of these features, your Next.js application needs to run as a Node server.

Deployment

Given that our Next.js application is essentially different for different contexts, it's only natural that the deployment of it will also be different.

Deploying static files (static export)

A fundamental concept is in play here. Our application is just a bunch of static files, how do we deploy them?

In order to deliver these files to the client (GUI browser, CLI browser -Lynx for eg-, curl... whatever is requesting the resources), we need a web server. It does not happen magically, everything is deliberate.

(This will apply to any kind of file you want to serve.)

We'll be using NGINX as a web server in this guide, so make sure to install it on your VPS if it's not already installed: NGINX installation guide.

In summary, this is how we'll use NGINX:

After you clone your Next.js project and build it for a static export, an out/ directory will be generated for the static build (at the time of writing. The folder name might change in the future).

The out/ folder contains the static files of our Next.js SPA application. In order for NGINX to serve files, it needs to look into a directory for them. We're going to place our project(s) in the /srv directory.

You'll often see websites placed on directories like /var/www/ or /var/www/html/ etc. It usually doesn't matter where you place your project, especially if you're only hosting one website.

According to the FHS, /srv is used for site-specific data which is served by this system. I like to stick to the standard.

After you cd into your Next.js project, we'll copy the generated out/ directory into /srv with the following command:

cp -r out /srv/<project name>

In addition to copying the out/ directory, the command will rename it to whatever you replaced <project name> with.

Configuring NGINX to serve static files over HTTP

As stated earlier, nothing happens magically, so in order to get the behavior above, we need to configure NGINX accordingly. For simplicity's sake, we're going to only edit the default NGINX configuration file located at /etc/nginx/sites-available/default.

Once you open that file with the text editor of your choice, you'll see some pre-existing configuration, we're going to be interested in the server block. The configuration should look something like this, minus a few comments:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # SSL configuration
    #
    # listen 443 ssl default_server;
    # listen [::]:443 ssl default_server;
    #
    # Note: You should disable gzip for SSL traffic.
    # See: https://bugs.debian.org/773332
    #
    # Read up on ssl_ciphers to ensure a secure configuration.
    # See: https://bugs.debian.org/765782
    #
    # Self signed certs generated by the ssl-cert package
    # Don't use them in a production server!
    #
    # include snippets/snakeoil.conf;

    root /var/www/html;

    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
}

Even if you've never used NGINX before, you can make an educated guess what the configuration does.

It's listening on port 80, which is the default port number for HTTP traffic.
It sets a root directory /var/www/html.
It serves as entry point one of these files (in this order) index.html, index.htm, index.nginx-debian.html. Fun fact, the reason .htm is a valid HTML extension is due to limitations in some systems that accept at most 3 characters for filename extensions.
The location block seems to serve the rest of the static files if found, otherwise return a 404 status code, as the comment explains.

Let's fix it up to serve our Next.js project. Change the root directive to point to our project's build:

root /srv/<project name>;

Change the server_name directive to use your domain name:

server_name example.com;

Change the try_files directive to this, so that when a path is requested, an HTML file is returned with the same name if it exists.

try_files $uri.html $uri $uri/ =404;

To check if your NGINX configuration is correct in terms of syntax, run:

nginx -t

Now we must restart the NGINX service. Make sure to do this after any changes you make to the configuration file:

systemctl restart nginx.service

Your static Next.js website should be accessible now. Let's test it out.

To check if NGINX is serving files correctly, run the following command. This should return the index.html file.

curl localhost

If it doesn't:

Check if NGINX is running with systemctl status nginx.service.
Check if the path you provided in the root directive may be incorect.
Make sure the path you provided in root directive exists and contains your static files.

Let's test out the website using the domain name. Keep in mind that we're still using HTTP.

curl http://example.com

If the command above does not return the index.html, make sure that you configured your domain name's DNS properly to point to the VPS' IP address.

The reason I started with HTTP configuration is to decrease the complexity and the number of factors that come to play with NGINX. Hopefully you've managed to get it setup successfully.

Now it's time to get HTTPS working.

Configuring NGINX to serve static files over HTTPS

Why? Because you don't want your users to use your website on top of an insecure protocol (HTTP), especially if you're dealing with sensitive data. Plus, it's nice to have an SSL certificate. Feel free to read Why Use HTTPS by Cloudflare.

What changes do you reckon we should make to the NGINX configuration to use HTTPS?

It's a different protocol, so a different kind of traffic.
It uses SSL/TLS, so we need to setup certificates and private keys.

To handle the above, we'll use Certbot which is a free utility that generates SSL certificates and configures HTTPS for you.

Install it on your VPS:

apt install certbot python3-certbot-nginx

Now we'll let Certbot do its magic!

certbot --nginx -d example.com

You'll be prompted with a couple of questions, and once you answer accordingly, Certbot should generate your SSL certificate as well as configure NGINX for you.

Once you open /etc/nginx/sites-available/default, you'll see that the configuration Certbot added will be followed with # managed by Certbot.

Here are some of the things that Certbot adds to your NGINX configuration:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

These enables your NGINX server to listen to traffic on the port number 443 which is the default one for HTTPS traffic. Additionally this links to the generated SSL certificate and private keys.

Certbot may also add this to your configuration, which listens on port 80 (for HTTP traffic) and redirects it to HTTPS, enforcing a more secure communication, otherwise return a 404 error status code.

server {
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name example.com;
    listen 80;
    return 404; # managed by Certbot
}

Deploying a Next.js server

This is for projects that require SSR, SSG, ISR, or any of these features. As I mentioned earlier, now your Next.js needs to step up to a Node server to fulfill your requirements.

An illustration of the deployment:

To keep things simple, this time we'll clone our Next.js repository to /srv directory. To run a production build of Next.js application, we don't require all the content of the project, but we'll keep them nevertheless.

After you build your project, run the next start script with whatever package manager you're using. You should be able to get back an HTML file when you curl localhost:3000 (or whatever port you configured). Once you've confirmed that your Next.js application runs successfully, stop it.

Running Node.js applications in production

In a production environment, it's unwise to assume your server applications will continue running ad infinitum. Many things can go wrong which result in shutting down your applications:

Runtime errors may stop the server application from running.
As part of maintenance procedures, your hosting provider may restart your VPS.
Your server may catch fire, or experience an electric outage. Shit happens.

Bottom line is, your application must tolerate this kind of situations, by restarting when it shuts down, and by running on startup after system reboots etc.

A popular tool for the job is PM2, which is a process manager for your Node.js applications.

If you're using npm, install it globally with the following command:

npm install -g pm2

If the installation was successful, this command should return PM2's version:

pm2 --version

After you cd into your project's directory, run your Next.js application through PM2 with the following command:

pm2 start npm --name <application name> -- start

Replace npm with whatever package manager you're using.
The double dash -- indicates the end of the options/arguments list of a command, so that start is considered an argument for npm and not pm2.

You can check if the Node.js process is running with pm2 status.

In order to run your Node.js applications on startup, PM2 itself must be running, in order to do that, run this command:

pm2 startup

This ensures that PM2 runs on system startup.

Similarly, run this command so that PM2 registers the application and run it on startup:

pm2 save

You can read more about this this in PM2's documentation.

Configuration NGINX as a reverse proxy

As illustrated in the image above, NGINX will "forward" the requests it receives to the Next.js application (which is a Node.js server) and returns to the client whatever Next.js returns, acting as an intermediary. This is the basic functionality of a proxy.

Open the configuration file /etc/nginx/sites-available/default, and replace it with:

server {
    server_name example.com;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_pass http://localhost:3000;
        proxy_redirect off;
        proxy_read_timeout 240s;
    }

    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
}

For HTTPS configuration, go through the process mentioned above with Certbot.

Closing thoughts

A couple of weeks ago, I was struggling with this deployment for a client. I never really understood NGINX, because I never worked with it directly before. However I am very glad I was presented with this opportunity!

It took me an entire day to debug its configuration and understand what the directives are doing to get the reverse proxy working. What can I say, I am a masochist, so I enjoy this.

I hope you benefited from it.

Stay in touch

If you'd like to stay updated with my blog, reach out, or see what I am up to, you can find me on Twitter.

Thumbnail picture by Aron Visuals on Unsplash

My First Experience Giving a Talk @Devfest El Bayadh 2023

Mohamed Yamani — Wed, 24 Jan 2024 09:42:53 +0000

Disclaimer: I take you through my thought process as I was preparing for my first talk. This is more personal, so you might not get any value from reading this. It's something to document about my journey, a piece I know I'd love to read in the future.

Context

It was during my final Master's exams that I was contacted by a member of GDG El Bayadh (Google Developer Groups) asking if I am interested in giving/delivering a talk for their DevFest annual event on the 23rd December.

FYI, El Bayadh is a small city in Algeria where nothing happens.

I was pretty stressed at the time, which is interesting, because I am not the kind that ever got stressed over exams before. But this time, I was.

We had 12 exams to go through, thankfully one exam a day. It however spanned across 3 weeks in total (don't ask me how). It was a marathon to cram for every class the night before.

We'd finish exams on the 20th, that's 3 days for preparation (minus 1 to travel back El Bayadh).

So given the masochist that I am, I accepted. And now I need to figure out what to talk about.

Realization and struggle

But wait, what the hell do I know well enough to give a talk about?! My mind was blank.

What do I even do? I freelance as a front end developer, but I am not sure what topic to talk about that would be valuable to the audience. Wait, I completely forgot about the audience...

I've given presentations in the past academically, but it's always to people that were either paid (professors) or forced (students) to be there. But this time it's different. People will come out of interest and/or curiosity.

That changes the dynamics.

After asking the organizers about the demographics of the audience they're expecting, they said they're mostly university students from different backgrounds, as well as high schoolers. So I interpreted this as people that are interested in tech and/or beginners in development.

That ended up being a correct interpretation.

I got the idea to talk about technical writing, which was suggested to me too by some of my friends, but then I discarded it. I found it hypocritical to talk about something I failed to commit to. I've been writing sporadically over the last 3 years, and I only had ~11k views in total.

Then I recognized that I deal with this problem occasionally when I want to publish an article too, seeing myself as not good enough to share my thoughts/experiences or to try to explain a concept.

The way I resolve this is by mainly reminding myself that no matter how bad I think I am or how much I suck, there's surely someone that's worse out there, someone who's just starting their journey for example. That's my target audience. There's a high chance they'd find value in what I say... or so I'd like to think.

So I reverted back to the idea of technical writing, it seems to have a low barrier of entry, and includes a wide range of disciplines, which suits the audience.

Preparation

I started preparing for it the eve of the talk.

I decided to give the talk in Algerian dialect. I wanted it to be more accessible to the crowd. While I would have preferred English to encourage youngsters to learn it more, it was not my objective for this talk.

I never scripted my presentations before, I hated preparing for them too. I like to improvise, it has always served me well.

But this time, I was not sure. It seemed to me that it would be unjust if I spoke nonsense to an audience that actually wanted to attend, especially since the talks are 20min long.

So I started scribbling here and there.

The day of the talk

My talk was the first one, I liked that. It wouldn't be a problem to set the bar low, because I am the first, and I could get done with it and focus on the other talks afterwards, instead of thinking about mine.

The event was planned to start at 8h30 AM. I was there at ~7h30, sitting in front of the stage, waiting. My heart was racing, and I felt sick in my stomach. Very sick. Time was not passing by.

Eventually, the event started after 9AM, and I was up.

Thankfully, the moment I stood in front of the crowd, set up the presentation, I was back to normal. I was myself again.

It went smoothly. I communicated the ideas I wanted to, and 18 minutes later, I was done.

Review

I couldn't tell how the audience took it, but there was one guy who seemed interested that approached me during the coffee break with questions, which lead to a cool discussion.

To me, it takes only one person to benefit from what I share to consider myself successful at it. I'd like to think I was this time.

I am very happy that I got to meet cool people that I knew from the internet (yes. they're real): Karim and Houari. It was a pleasure!

You also get some free photoshoots, and if you don't usually make weird faces, you get to use them. Unlike myself:

Follow my journey on Twitter

You can find me on Twitter @yamanidev where I am most active, documenting my journey and sharing what I learn about software engineering and tech in general.

And lastly,

don't forget to touch some grass.

Take care!

Let's Understand CSS: Inheritance

Mohamed Yamani — Fri, 20 Oct 2023 08:00:00 +0000

Most CSS bugs come from conflicting styles which most people solve by slapping the notorious !important at them, or by resorting to inline styles instead.

The only fix to this is by understanding how CSS deals with conflicting rules, and how to use it to your advantage. This mostly includes 3 fundamental concepts:

Cascade.
Specificity.
Inheritance.

In this article, I'll explain the last concept.

Another equally important concept is the Box Model which I wrote about 2 years ago, that should explain why I describe myself as sometimes a blogger.

I'll be writing more often on fundamental CSS concepts that must be understood for smooth sailing with CSS, otherwise you'll relate to the memes.

If you're someone that doesn't struggle with reading MDN docs, I recommend you skip this article to read the MDN one and wrap up inheritance in a few minutes: Inheritance MDN link.

If you wish to stick around, buckle up.

One of the best ways to learn about tech stuff is by thinking about how to build them yourself. What would be the process like? What decisions and compromises will you make to achieve X?

Even if you're not able to answer these questions -understandably so-, they remain interesting questions to ask and find answers to.

Shifting you thinking to how to build a tool will give you a chance to understand why certain things of behave the way they do, why they were built the way they were etc.

Keeping in mind the properties you know and putting all your CSS knowledge aside, how do you think styling would be like?

How's the architecture of styling web pages like?

The way I see it, it will be very explicit and verbose.

Since styling like this is not an option,

<ul class="cool-list">
  <li>banana</li>
  <li>monkey</li>
  <li>idk</li>
</ul>

.cool-list {
  color: red;
  font-weight: 700;
}

it has to be something like this:

<ul>
  <li class="not-so-cool-li">banana</li>
  <li class="not-so-cool-li">monkey</li>
  <li class="not-so-cool-li">idk</li>
</ul>

.not-so-cool-li {
  color: red;
  font-weight: 700;
}

It would be a nightmare write and worse to maintain. Not so cool indeed.

This is why inheritance was implemented. To make styling web pages compact and clean.

Instead of having to style each HTML element separately, you can style a parent and the styles will get applied to its children at all nested levels.

<body class="cool-body">
  <main>
    <header>
      <h1>Some cool title I bet</h1>
    </header>

    <p>Bla bla bla <span>special bla bla</span></p>
  </main>
</body>

.cool-body {
  color: red;
  font-size: 20px;
  font-weight: 700;
}

Quick reminder:

Regardless of the nesting level of, if element A is in any shape contained inside of element B, then element A is a child of element B.
The level of nesting is what determines if a child is a direct or an indirect one. If it's only nested one level deep, it's a direct child, otherwise it's an indirect one.
<h1> is a direct child of <header> and an indirect child to <main>.
<span> is a direct child of <p> and an indirect child to <main>.

All of the children of <body> will inherit the style declarations of the class cool-body. i.e, everything will look tedious.

How it works

So what happens when different parents have conflicting style declarations? The conflict being having different values for the same CSS property.

One of them must be picked of course.

The algorithm to pick the inherited styles is pretty straightforward: we pick the styles of the closest parent. And since the DOM is a tree data structure, it's easy to do that.

<body>
  <main class="cool-main">
    <header class="cool-header">
      <h1>Some cool title I bet</h1>
    </header>

    <p>Bla bla bla <span>special bla bla</span></p>
  </main>
</body>

.cool-main {
  color: black;
}

.cool-header {
  color: red;
}

<h1> will take take cool-header's style because it's the closest parent.
<p> will take cool-main's style because it's the closest parent.
<span> will take cool-main's style because it's the closest parent.

Thankfully, not all properties are inherited. Can you imagine passing down properties like width, display, border etc?

Most of the inherited properties are typography related, with some other ones you've never heard of. You can find the list of these properties in this Stack Overflow answer.

Hope you learned something!

Don't relate to CSS memes.

Thumbnail by Jr Korpa on Unsplash

Linux Fundamentals: File Permissions and Ownership

Mohamed Yamani — Fri, 22 Sep 2023 08:00:00 +0000

Originally published at https://mohamedyamani.com on September 19, 2023.

In my last article Explaining the ls command and beyond, I broke down the ls command, how to interpret the output, and introduced some command line concepts. It was quite the jargon, and to some of you, it was unfamiliar.

As such, I'll dedicate some articles (like this one) to explain that very jargon, or at least make it a bit less unfamiliar to you.

Linux is a multi-user system, and it does not mean what you think it does (or at least what I did).

A multi-user system is not just a system that allows having multiple users, but one that can also be used by many users at the same time. The keyword here is at the same time.

You might ask yourself, how can a computer be used at the same time by different people? Well, a computer does not require you to sit in front of it to use it. You can remotely access it for example using the program Remote Desktop Connection if you're using Windows. Or using SSH to access the system via the command line. That way, multiple users can work on the same machine, using the same resources.

Try to picture that scenario of multiple user accessing a computer, it's a mess. What's stopping user B from playing around with user A's work? As a person that likes to troll, I would say, nothing. The options are endless, and it stops being fun when you're user A.

It seems that this trolling concern existed in the 70's too. Unix was built with the design of a multi-user architecture; it introduced file ownership and permissions. And Linux naturally inherited this design as well.

Unix multi-user system design

Ownership

Every file in the system belongs to a user and to a group. This is called ownership, and it enables the system to make the distinction between these 3 cases:

A user that owns the file.
A user that belongs to the group that owns the file.
A user that is neither of the above. Which is called other or world as I've explained in the last article.

Permissions

Permissions are who gets to do what with a file. The who part is determined by ownership, it is one of the 3 cases I mentioned above.

Now to the fun part, do what. What can be done to a file? The answer is found in the first column in the output of ls -l:

Read.
Write.
Execute.

These 3 permissions hold different meanings for files and directories. It's one of the things that I found troubling to understand when I was first learning Linux.

Permissions of a file

Read: the file's content can be read. By using cat or opening it with a text editor for example.
Write: the file's content can be changed.
Execute: the file can be considered a program and executed. If you ever downloaded an AppImage before, you're likely to have encountered the error Permission denied. The reason was because the file did not have the execute permission.

Permissions of a directory

Read: the directory's content can be read, you can ls the directory, but you cannot open it graphically by double clicking, I'll explain that in a bit.
Write: the directory's content can be changed, meaning you can create/delete/rename/move files and directories within it.
Execute: you can enter the directory, meaning cd into it. This permission alone is not enough to open the directory graphically too.

So what's up with directories graphically? Well, nothing. Just think about it for a second.

What happens exactly when you double click on a directory? Sounds like a stupid question right? I'll let you be the judge of that.

A window pops up, showing the content of that directory. But another thing happens as well, we enter that directory.

Ultimately, opening a directory graphically makes use of two permissions:

Read permission: because the window lists the content of the directory.
Execute permission: because we entering the directory.

Don't take my word for it though, I might be saying nonsense after all. Open your terminal, and play around with files/directories with different permissions.

Chmoding playground

What better way is there to understand than seeing what you're learning in action, right?

In order to see the effect of the different permissions, you'll need to be able to change them. That's where the chmod command comes into the picture. I'll briefly introduce it, refer to man for more details.

The chmod command supports two syntaxes:

Octal (I won't cover what octal is, or why the syntax was named after it)
Symbolic

Remember how a user can be either an owning user, a user that belongs to the owning group or neither? Well each of those gets a permission.

Octal

The syntax is straightforward:

chmod <XXX> file

Where XXX is a 3 digit number. Reading from left to write:

1st digit: permission for the owning user.
2nd digit: permission for the owning group
3rd digit: permission for others (also called world, anyone that is neither of the above).

Each permission is "represented" by a number:

Read: 4
Write: 2
Execute: 1

To describe a permission as a digit, add the numbers of the permissions you wish to include. For example, the permission of a file that is readable and writable would be described with the number 6. Which is 4 (read permission) + 2 (write permission).

Repeat the same process for the each digit to represent the file's permission for every kind of user.

Say you want your file to be readable and writable for you (the owner), and only readable for anyone else:

chmod 600 someFile.txt

The first digit representing your permission. The second and third digits representing respectively the owner group and others' permissions, which is 0, none.

You change your mind, you open your heart and want to share the file with others, but without having to worry about trolls (like myself). Instead of giving no permission to the group owner and others', you give them read access instead.

chmod 644 someFile.txt

You get the idea.

Symbolic

This one is a bit tricky. You use these symbols to represent permissions:

u meaning user owner.
g meaning group owner.
o meaning others.
r for read permission.
w for write permission.
x for execute permission.

Let's start simple.

chmod +x someFile.txt

This adds the execute permission for everyone. The user owner, the group owner, and others.

chmod -x someFile.txt

Removes the execute permission for everyone.

chmod +rw someFile.txt

Adds the read and write permissions for everyone. So far so good, I hope.

Now it gets, compositional let's say.

chmod u=rwx someFile.txt

Assigns read, write and execute permissions to the user owner.

chmod go=r someFile.txt

Assigns the read permission to the group owner as well as to others.

Etc.

I hope you learned something :)

Keep the trolls away.

Photo by Jr Korpa on Unsplash

Helping Older Browsers Understand HTML5

Mohamed Yamani — Tue, 19 Sep 2023 20:52:36 +0000

Table of content

Introduction
Ancient browsers that do not support HTML5
How do these browsers interpret HTML5 semantic elements?
Okay, so what's the solution?

Introduction

When HTML5 was released it brought semantic HTML elements to the table which in turn frequently replace the famous divs and spans that are notoriously used everywhere.

The use of these semantic elements is very important, some of the reasons behind that being:

Offering people with disabilities a better navigation experience by creating a clear hierarchy of the content of the page for screen readers to parse.
Helps your website's SEO ranking (Search Engine Optimization) by facilitating the indexing of the website by search engines.
HTML elements now give a descriptive meaning to their content. An aside is a lot more descriptive than the general-everywhere-use of div or span.

Ancient browsers that do not support HTML5

Unfortunately though, not all browsers support HTML5 features (fully and/or partially) and that complicates things.

We can't write our HTML twice; one that is semantic for browsers that are compatible and one for the older versions that are not. Because that is resource consuming in terms of authoring and maintenance.

And we obviously cannot neglect the ones that do use ancient browsers (yes, some people do, surprisingly) because that could potentially mean decrease in revenue and visibility since a portion of people won't be able access our website properly.

Now these cursed browsers are (partial to no compatibility for semantic HTML):

Mozilla Firefox version 2 to 20
Google Chrome version 4 to 25
Safari version 3.1 to 6
Internet Explorer version 6 to 9

How do these browsers interpret HTML5 semantic elements?

That's a good question, it's an edge case that needs to be treated.

Naturally, incompatible browsers with HTML5 features won't recognize the new semantic elements like nav, header, footer etc.

So how do they parse them?

Browsers treat them as inline elements. Meaning they would go with the flow of text, they do not start a new line (the same default behavior of img and span for example).

Okay, so what's the solution?

### The "meh" approach

Some of the older browser versions allow CSS rules to be associated with semantic elements (for example IE9 was the first of IE to adopt this), we will be using that to our advantage.

All you have to do is select the semantic elements and change their display (from inline as we said) to block.

An example:

header,
section,
footer,
aside,
nav,
article,
figure {
  display: block;
}

This is not the optimal solution nor the recommended one, it's meh.

### The recommended approach

We get JavaScript involved in the play by fundamentally creating the elements from scratch as such:

document.createElement('nav');
document.createElement('header');
document.createElement('article');
// etc

By the way, this code must be appended in the head element either by linking to an external script or by writing the code inline using script tag.

The problem with this though is there's more than 100 semantic HTML element in the spec. And this code seems pretty lacking and is not reliable on real world projects.

The best way to deal with this is by using html5shiv (there's actually a funny story behind the debate whether it should be called shiv or shim).

The script is in this repo.

There are two ways to get the script (you can check them out in README of the repository), either by using Bower or manually installing it.

I prefer the manual installation via this link:

After extracting the ZIP file, copy either files dist/html5shiv.js or dist/html5shiv-printshiv.js to your project's directory.
Include the copied script in the head element
Add this comment in the head element after all the stylesheets:

<!--[if lt IE 9]>
  <script src="bower_components/html5shiv/dist/html5shiv.js"></script>
<![endif]-->

Problem solved. You can now safely forget about the older browsers!

Thank you for reading!

I hope you learned something new and enjoyed reading!

Follow my blog and my Twitter for more!

Have a nice one.

Photo by Michael Dziedzic on Unsplash

Linux Fundamentals: Explaining the ls command and beyond

Mohamed Yamani — Fri, 15 Sep 2023 08:46:43 +0000

Originally published at https://mohamedyamani.com on September 10, 2023.

If you ever used a Linux system before, chances are you're familiar with the ls command, or at least you know of it. Through understanding the output of this command, you can learn some fundamental concepts in Linux (or operating systems in general) like user management and file permissions. It's kinda fun, I promise.

For those of you that are not familiar with the ls command, I hope you can pick up at least this from the article...

Golden nugget

If you ever find yourself unsure of what a command does, what argument does what, or the syntax of the command, always refer to the system's manual via the man command. You don't know what ls is? Screw Google. Enter man ls in your terminal. Not sure why someone would call a command that outputs text a cat? man cat (stands for concatenate).

Funnily enough, when I was first learning about this, I tried man man right off the bat. Boy was it lovely to see that it worked and indeed returned the manual description of the manual. Don't take my word for it though, try it yourself!

If you feel like sticking around a little bit more, I will try to explain the command for you.

Note: you will encounter the word "directory" in this article, it's a fancier name for "folder" used in Unix/Unix-like contexts.

Level 0

The command ls lists the content of a directory, content like files and other directories. It is the equivalent to the graphical way of double clicking on a folder and seeing the icons of the different folders and files.

So how come ls works even though we didn't provide a directory to list the content of? Well if you read the manual man ls you would know! Develop that reflex my friend, you will need it.

Entering ls without providing a directory will list the content of the current directory by default. What current directory you say?

Well the terminal is always pointing to a directory. By default when you open the terminal, it would be pointing at what's called the home directory, it is usually given the symbol ~ in the prompt which is just a shorthand of /home/<your-username>/. Don't take my word for it though, open up your terminal and enter pwd to check the current directory (use man to learn more about that command!).

Level 1

Great. Now you can use the terminal to check the content of a directory. But now you're getting greedy, you want to extract more information -as you should-. Feel free to explore the arguments you can find in the manual! Some of the most common used ones would be:

ls -a to view hidden items. Notice how the new items all have names starting with a .? That is how files are hidden in Linux/Unix. Neat right?
ls -l to show more details about the listed items.

The last argument shows some cryptic output. That's our key to understanding more concepts!

Level 2

The output of ls -l would look something like this. Let's try to depict it.

You can notice that each item is on a separate line. Each line provides a piece of information about the item in a column, sort of like a table.

Column 1: File type and permissions

The first character denotes the file type:

d for directory.
- for a regular file.
i for a symbolic link (will not be covered in this article).

Notice how I said file type? Including directories? That's because in Linux, everything is a file. A directory is just a special kind of file. I might write an article about that someday! :)

The remaining part of the column indicates the file's permissions. It is divided into 3 parts. The left most part is the user owner's permission, the middle one is the group's permission and the right most part represents the world's (others') permission.

r stands for read. It takes the first position.
w stands for write. It takes the second position.
x stands for execute. It takes the third permission.
- indicates no permission depending on the position. If it's in the first one, it means the file does not have read permission. If it's in the second, it means no write permission, and so on.

I will assume that the notion of a user is familiar. However a group might be a new term.

A group is simply a collection of users. The introduction of such feature facilitates the administration of things like having the same permissions for a bunch of users.

Finally, others, or as some call it world, is anyone that is not the user owner or the group owner.

Notice also how many terms are being thrown here? And we're just getting started! That's what I meant by ls being a key to learning some fundamental concepts. Brace yourself!

Column 2: Hard links count

Quite the confusing name right, it's in fact simple. A hard link is a copy of a file. The number indicates how many copies exist of that file in the file system.

Column 3: User owner

Column 4: Group owner

Column 5: File size

In bytes. You can look up the manual on which argument to use to display the sizes in human readable format. On that note, search online how to properly search for keywords in the terminal manual.

Column 6: Last modified date and time

The timestamp of when the file was last modified.

Finally, column 7: the file name

Level 3

You realize by now how much there's to know. You've asked yourself plenty of questions while reading the article. I sure did while writing it! But that's the beauty of it. Explore away your curiosity, discover what you can!

A lot of what has been briefly explained here could be developed into separate articles. I am planning on doing that someday in the near future :)

Hope you learned something!

Photo by Diane Picchiottino on Unsplash.

My First Experience in Google Hash Code

Mohamed Yamani — Sun, 10 Sep 2023 11:55:05 +0000

We all know how important practicing is for learning crafts and honing skills. You become a better chef by cooking more often, a great painter by drawing and a skilled programmer by writing more code.

What software engineers do -put simply- is solving real world problems using technology. To be a better engineer is to get better at solving problems.

One of the ways you can apply what you've learned is through participating in coding competitions (and there are a lot, annually).

Google for example organizes many competitions every year like Kick Start which is in 8 days, Code Jam that starts in 14 days, Google Summer of Code during summer (applications open next month, keep updated) and finally Hash Code, I will be sharing with you my first experience with this last one.

What is Google Hash Code?

Google Hash Code is a programming competition between teams (2 to 4 people a team) from all across the globe (over 97 countries).

You are given a problem to solve in 5 hours "modeled off a real Google engineering challenge" as Google says.

Prizes

1st place: 4000$ USD
2nd place: 2000$ USD
3rd place: 1000$ USD

Along with some Google products to the top rankings.

Who can join?

You must be at least 16 years old to participate in the contest, and at least 18 years old to be eligible for the final round.

My story

A friend of mine approached me a month before the registrations to participate with him and a friend of his in Hash Code, I had completely forgotten about it at that time, I got so excited and immediately accepted to roll on with them.

Sadly enough, final exams were a week after Hash Code but I regret not giving preparation for the competition enough time nevertheless. The only thing we did to prepare was meeting up a week before the competition to practice past problems (they're easily found in Hash Code's website).

As we tried to come up with solutions to last year's qualification round problem we got very overwhelmed by it, we knew it would be a challenge obviously, but did not expect anything near this difficulty. Still after 4 hours of brainstorming and discussing possible approaches, we did not move an inch and it was depressing, so we just called it a day and went back to studying for school.

Fast forward to the competition day (a week later), it started on 6:30 PM (if I remember correctly) here in Algeria. We met up at my room, installed our setups and prepared everything needed to kickstart and waited for the problem statement excitedly.

We downloaded the PDF and started reading through the 10 pages (it was even longer than last year's which were 5) and it took as around 35 minutes to "absorb" it. Each one of us started thinking through some possible solutions and how to implement them for an hour-ish long. What was weird and funny though is that we all found ourselves forgetting the problem statement mid-way and that costed us a lot of time perhaps due to the many variables, circumstances and conditions to take into account but surely for our lack of practice.

We discovered that one of the test cases given through an example is one of the problems' inputs, so we copied the results of the example's output and submitted it, 1002 points received for that. But guess what, time was already up haha, the scoreboard was frozen, so our score was 0.

So basically, we yet again did nothing, not even a single implementation of the ideas we had.

So why am I telling you this?

I shared my experience with you to emphasize that you do not have to be good at something to try it out, everyone starts somewhere.

If you stumble upon any programming competition, join it immediately without any second thought, figure things along the way and enjoy yourself!

Don't question whether you know the technology X or have the skill Y, join to learn from the experience and have fun!

One thing I sure took away with me is feeling extremely stupid, and I am happy with that feeling because it is humbling, it is a good reminder that there is still a long way to go.

That is what I love most about this field especially, learning never ends, it is part of the journey. You will always remain a student!

Takeaway

Don't feel intimidated by competitions.

The worst thing that could happen is to get a score of 0 (like yours truly did), learn about this type of competitions, and come better prepared next time (like I sure will)!
Now that doesn't sound so bad after all now does it?

Don't ask yourself too many questions about it. Just join!

You have too much to lose if you don't.

You most probably will meet new people, get exposed to different technologies, learn a thing or two and on top of that, have fun!

Thank you for reading!

That was it ladies and gentlemen, I hope you enjoyed the article!

Any feedback or constructive critique is warmly welcomed and appreciated, so please tell me what you think in the comments so I can better the quality. Thanks for reading ❤️!

Follow my blog and my Twitter for more!

Have a nice one!

Photo by Mitchell Luo on Unsplash

How ChatGPT Can Hurt Your Problem Solving Skills: An Anecdote

Mohamed Yamani — Fri, 08 Sep 2023 08:46:10 +0000

Introduction

ChatGPT is one of those tools that are -without exaggeration- revolutionary. With its release, the world enters a completely different phase, which is only natural. With a tool that relieves you of the tedious searching you had to do and digging around the internet for answers, you get your results by prompting it.

Discovery

When it was released, everyone was using it. I started noticing people from my circle ChatGPT'ing their way through everything. From solving math equations, summarizing documents to writing cover letters and presentations. It was wild.

I couldn't blame them, I saw how practical it was, how much time you could save by using it, which is really what tools are for. However, I am personally very slow when it comes to adopting hyped up tools, even when it's as grand as ChatGPT. It would require you to subscribe to releases of shiny new things, which I find distracting as there are new tools getting published very frequently.

Last July, I had my finals. And as per usual, you have to go through ~200 slides of materials per class (we had 8, so that's 1600 slides). After the course of some months, and after seeing how effective ChatGPT has been for my friends and classmates (and occasionally myself as well), I had decided to use it to prepare for exams, since -naturally- I am always behind when it comes to studies. Since I am someone that's somewhat articulate and precise when it comes to learning, most of my prompts where of the sort:

What's the difference between UART and SPI in embedded systems?
What's the difference between security and liveliness in distributed systems?
What's the difference between a service and a thread in android? etc.

Getting hooked

Little by little, I started developing the reflexes to prompt ChatGPT for answers instead of using DuckDuckGo. I started noticing that I am visiting websites like Stack Overflow and GitHub less and less for answers and code snippets, and sticking with ChatGPT for everything. Only to notice 2 weeks ago what my reliance has lead to.

The amount of time I spent thinking of solutions decreased, I would almost always just prompt for the code and paste it with some adjustments. I noticed that my problem solving became troubled and slow, that it has deteriorated.

Trying to get unhooked

I started to consciously fight the urge/reflex to prompt for answers, and try to come up with ones of my own in the traditional way I used to. Thankfully, I am slowly getting back to normal.

The solution here lies not in one of the extremes, either relying almost completely on the tool, or refraining from it, rather it is somewhere in the middle. To find a balance in which you could benefit from the tool without relying too much on it to the point of damage.

I personally found the middle ground is to limit my prompts to a set of questions/scenarios:

Scaffolding projects or libraries.
Comparative questions, especially when it comes to figuring out which tool to pick for which job.
Learning new concepts.

Conclusion

The key takeaway I would say from this anecdote is, to pay attention to how we're using our everyday tools, how much we're relying on them, whether that's a good or a bad thing. Because tools affect us, and as ironic as it sounds, we could very well end up being enslaved by our creation.

Note: Funnily enough, I prompted for a title and a description for this post (they suck, I am going with my own). Guess I have some more work to do...

Originally published at https://mohamedyamani.com on September 3, 2023.

The Migration Adventure: CRA to Vite and npm to pnpm

Mohamed Yamani — Sun, 27 Aug 2023 10:24:46 +0000

As I was migrating a client's project from CRA to Vite I encountered plenty of issues. Some of which were due to certain imports that are specific to Webpack, the other ones were due to me using pnpm as opposed to npm.

That wasn't a smart move, migrating to another build tool as well as another package manager at once. So I switched back to using npm to finish my Vite migration, fixed the errors, all good.

When I tried using pnpm again and installed the packages using it, it kept throwing many errors that package X, Y, Z are not installed, which is weird, because the npm version works just fine!

Via pnpm import, the existing lock files are parsed and pnpm-lock.yaml gets generated, so the lock files should have the same content.

It is true that all the dependencies that are mentioned in the lock files will be installed by pnpm without fault. However, due to how npm installs packages and their dependencies, you will find yourself being able to use a dependency of a package without explicitly installing.

That's exactly what happened, notably with date-fns and some other packages. How npm structures your node_modules/ allows you to import date-fns even if it wasn't present as a dependency in your package.json, as long as some other package depends on it.

Bottom line, explicit is better than implicit.

I downloaded the missing packages like a good boy and life moved on 🙂.

References

I followed this article to switch from CRA to Vite, it was very helpful.

Basic Introduction to the Internet and the Web

Mohamed Yamani — Sun, 14 Nov 2021 06:38:06 +0000

Table of content

Introduction
What is the internet?
How are computers linked via the internet?
The journey of data sent between two devices
How do we surf the web?
Conclusion

Introduction

Similarly to electricity, we use the internet on a daily basis without knowing how any of them function behind the scenes.

As a web developer, having a basic understanding of the internet and its different parts gives you more perspective on the environment you're working on, which broadens your knowledge in this field.

What is the internet?

The internet is a network of networks.

Great, very informative, the hell is a network?

A network is a number of connected devices (computers, phones, or even a smart refrigerator) through Wi-Fi, Bluetooth or cables.

How are computers linked via the internet?

Since the internet is this vast network; a large number of connected devices…

What kind of connection ensures that every single device is connected to every other device in this network?

The answer is, cables!

Yep, long copper or optical fibers under the seas.

Take a look at this map that covers all the fibers in the world! Pretty cool.

These cables get taken care of by your country's telephone infrastructure, and get integrated with the phone-line that reaches every house.

Simply put, internet arrives to your doorstep via the phone-line.

Phone-lines transmit light signals, in order to use the internet, these light signals must be converted to electricity via a modem, which you connect to via Wi-Fi or Ethernet.

The journey of data sent between two devices

In order to send data from a device to another, a connection must first be established.

What ensures successful transmission (which means data sent to the right receiver) are pieces of equipment called routers. Let's take an example:

Person A wants to send a message to Person B through the internet.

Upon Person A hitting send, the message is transmitted via the phone-line to reach a router.

The router receives the data and redirects it to the right receiver (or Person B in this case). That's why they're called routers, they define the correct route data goes through.

The router of this example is one of many special interconnected routers that are part of an ISP (Short for: Internet Service Provider).

An ISP is an organization that sells internet, web hosting etc. It takes care of distributing internet and its services.

How do we surf the web?

We access the web using software called browsers which allow us to view websites and navigate through them.

More formally, a browser is a software that reads website documents (HTML and CSS files) and executes its linked scripts -JavaScript-

The way you navigate to websites is through the address bar, where you write a website's link (more formally, the URL):

URL example: http://www.facebook.com

http: short for Hyper Text Transfer Protocol which is a set of rules for fetching resources (HTML, CSS, images etc.)
www: the sub-domain
facebook: the domain name
com: the top-level-domain

Note:

Usually when we navigate to websites, we omit the http part of the URL, and it works just fine because the browser adds it by default when it is missing because it is an essential part of the URL.

Now that our URL is typed and we press Enter… is where the fun all begins!

Continuing on the URL example www.facebook.com

1. The browser checks the cache for the DNS record

The browser checks in the cache memory for a previous entry of the domain name (facebook.com) in a DNS record.

DNS (short for Domain Name System) is a number of servers that map each domain name to a corresponding numeric address called IP address (short for Internet Protocol).

Just bear with me a little!

Servers are powerful computers running applications that listen to HTTP requests from clients (usually browsers) and serve them with resources (or error codes when something goes wrong. For example a missing resource which returns the famous 404 error code).

IP addresses are unique numeric addresses given to each and every device connected to the internet.

Writing out (and remembering) www.facebook.com is much more easier than 69.63.181.15 (Facebook's IP address). That is why we use DNS which stores mappings of domain names to their corresponding IP addresses, exactly like a phone book.

Regressing back to our explanation.

If the browser finds the corresponding IP address of the domain name in cache memory, it sends an HTTP request to the mapped IP address of the domain name.

If the domain name is not in cache, the ISP's DNS server runs a DNS query; searching different DNS servers on the internet to find the given domain name's IP address, jumping from DNS server to another until it finds it!

2. The browser sends an HTTP request to the website's server to fetch resources

Upon finding the website's server IP address (thanks to DNS), the browser issues an HTTP request to the server to get the necessary documents of the website, from HTML and CSS files to the web page's images.

The server issues a response and sends back the requested resources, if everything goes well (no errors).

All these resources get rendered (read) by the browser and displayed!

Conclusion

That was a brief introduction to functioning of the internet and the web. We barely scratched the surface, and made everything seem simple and cozy, it's not the case.

The infrastructure underneath the internet is much more complex than that and is very interesting, we only covered some basics in this article, maybe we will dive into more complex concepts in the future!

Thank you for reading!

That was it. I hope you learned something new and enjoyed reading!

Any feedback or constructive critique is warmly welcomed and appreciated, so please tell me what you think in the comments so I can better the quality. Thanks for reading ❤️

Follow my blog and my Twitter for more!

Have a nice one.

Photo by NASA on Unsplash

Understanding The Box Model in CSS

Mohamed Yamani — Sat, 06 Nov 2021 05:59:53 +0000

Table of content

Introduction
What's the box model?
Types of boxes
Box sizing
Bonus tip
Conclusion

Introduction

When you're starting off with learning HTML and CSS, things can get overwhelming pretty quickly. At least they did for me.

You find that there's a plethora of HTML elements and CSS properties and values, and you start thinking that you need to start memorizing them all. Or how else would you learn to build web pages, right?

Wrong.

Thanks to google, you can look up things when you need them. Details like how to disable the resizing of a textarea element, or change the type of cursor on an element.

But that does not apply across the board.

There are some important concepts that you must understand very well in order to build a solid foundation to ease your progression and growth in web development.

It is the understanding of these concepts that you should focus on doing. The cascading behavior of CSS, specificity, what browsers are, client/server architecture, all fall into this category.

One of CSS foundational pillars is the box model. It is how every element renders in your browser.

What's the box model?

It's a CSS standard that represents the elements of a document as boxes with certain properties (sizing, positioning, stack of elements...) based on CSS styles.

Put simply, every HTML element is a box of this sort:

Every box has a content area. An element's content could be text, an image, nested elements etc.

In addition to the content area, an element may also have (as shown above):

Padding area: space between the content and the border. The size of this area is defined by padding properties: padding-top, padding-right, padding-bottom and padding-left. Or simply the padding shorthand.
Border are: space between the padding and the margin. The size of this area is defined by the border-width properties (same drill as the padding: top, right, bottom and left).
Margin area: space between an element and its neighbors. The size of this area is defined by the margin properties, negative values can be provided for margins.

Quick explanation of shorthands (feel free to skip if you are familiar with them):

Shorthand properties are CSS properties that combine other properties. We use them to write less code and easily read it.

We'll use padding as an example, the same idea applies for other shorthands as well.

The shorthand property padding can take:

One value: padding: 1rem.

This is the same as writing:

padding-right: 1rem;
padding-top: 1rem;
padding-bottom: 1rem;
padding-left: 1rem;

Two values: padding: 1rem 2rem.

Which is equivalent to:

padding-top: 1rem;
padding-bottom: 1rem;
padding-right: 2rem;
padding-left: 2rem;

Four values: padding: 1rem 2rem 3rem 4rem.

That element is going to look weird as hell but just ignore it, it's for the sake of example :3

It's the same as:

padding-top: 1rem;
padding-right: 2rem;
padding-bottom: 3rem;
padding-left: 4rem;

A rule of thumb to remember this last part is to picture the motion of a clock: it goes from the top, to the right, to the bottom and then to the left.

Types of boxes

Now that we've had an overview of how elements are represented as boxes. We'll now discover how different types of boxes have different behaviors.

The different types of boxes are based on the display values: block, inline and inline-block.

I highly suggest you mess around with this for a bit to get the hang of it.

Block type box

Elements that fall into this type are those that have display property set to block, either by default (like div) or manually (adding display: block to the element with CSS).

Starts on a new line.
height, width, margin, padding are all applied and work as expected.
The element's width will fill its parent container unless otherwise specified.

Inline type box

Elements that fall into this type are those that have display property set to inline, either by default (like span) or manually (adding display: inline to the element with CSS).

If there's remaining space, it gets placed next to the previous element. Otherwise, it starts on a new line.
height and width properties have no effect on the element.
Horizontal margin and padding are applied and work as expected.
Vertical margin and padding are a bit tricky here, so bear with me. Both of the vertical properties are applied (you can check this using your developer tools), but they do not work as expected:
- margin does not have any effect. No spacing takes place between the inline element and adjacent elements.
- padding has an effect. You can test this out by adding a background color, it does not affect adjacent elements though. The padding does not push the other elements.

It is very important to experiment with the above, this kind of details cannot be understood through reading only. Create block and inline elements and play around with their width, height, margin and padding.

Inline-block type box

Yep, you read this right. This box right here is the offspring of the last two types.

Elements that fall into this type are those that have display property set to inline-block, either by default (like button) or manually (adding display: inline-block to the element with CSS).

Behaves like inline: sits next to previous element if there's remaining space, or starts on a new line otherwise.
width, height, margin and padding behave as expected.

Box sizing

box-sizing is a CSS property that defines how the properties height, width, border and padding work together.

It has 2 values (or modes):

We'll have this code examined in both modes:

<div>Banana man</div>

div{
    height: 300px;
    width: 200px;
    border: 3px solid red;
    padding: 1rem;
}

`content-box` (the default)

The rendered dimensions would not be equal to the height and width specified in your CSS.

But rather (for the width) width + padding-left + padding-right + border-left-width + border-right-width.

Visual representation from my developer tools (I use Firefox, this is from Firefox. Use Firefox):

You can see that what height and width did is specify the content area dimensions, but not the overall element size.

`border-box`

The rendered dimensions are exactly the values of height and width specified in your CSS.

To enable this mode, we'll add box-sizing: border-box to our div. We get this:

As you can see, the dimensions of the content area would be computed so that the overall size of our element matches 200px width and 300px height.

This mode is often the most used and is included in CSS resets. This way, it is easy to match your website design pixel-perfectly, letting the browser enjoy computing the difference.

Bonus tip (debugging CSS)

Since everything in a website is a rectangular box, it would be easy to help ourselves visualize that in our websites.

Whenever I encounter a bug, or a behavior I do not understand in my website (layout, positioning etc), I add border: 1px solid red to all the elements I am skeptical about.

I would change the color to differentiate between them though. You get the point.

That way, you get a better picture of the layout of your website, how everything is positioned, the margins, the paddings etc. Without having to check every element individually using developer tools.

Conclusion

TLDR; every website is a bunch of rectangular boxes nested inside other rectangular boxes. Boxes everywhere.

So that was the box model for you. One of the key concepts of CSS. One topic down (hopefully :3), many to go!

Thank you for reading!

That was it. I hope you learned something new and enjoyed reading!

Any feedback or constructive critique is warmly welcomed and appreciated, so please tell me what you think in the comments so I can better the quality. Thanks for reading ❤️

Follow my blog and my Twitter for more!

Have a nice one.

Photo by Kelli McClintock on Unsplash