At the time of posting this article, Kapsalon Lieve has just launched its website. Having a website helps people find your contact information. 

Under the hood, the website is built with NextJS and a git-based headless CMS: Tina.

Currently, the website is a one-pager mainly for discoverability on the internet. However, the website can quickly scale with the CMS providing the data.

Do you like how this website turned out? Or do you want to talk about it?

Button

A new website for Kapsalon Lieve

Throughout the years, I've worked with all sorts of tooling to keep track of progress and issues within a team.

I've used simple tools like Trello boards, Github issues and post-its. I've also used more extensive tools like JIRA, ClickUp, custom software and many more.

Spoiler alert: As a developer, I am 100% biased, and I haven't much to say about extensive tools like JIRA.Tools like JIRA get a lot of hate. That's because developers mainly don't like having their work parcelled out so precisely. But let's get this out of the way. Tools like JIRA are not for them. It's for stakeholders, managers and people who have to report progress and who are responsible for budgets.

I will not be bashing on Project-Management tools in this post, but I will address what I like about simple tools.

When you accept that PM tools exist for people responsible for budgets, what happens when the budget is a non-issue?

Open source teams can grow enormous, where people worldwide work on the same project. At the same time, people from all over the world can bring issues to the table which need attention.

Those projects seem to manage fine without a mastodont of an application.

The way GitHub manages issues is one of those ways I like as a developer. It's easy; Somebody can use it to discuss things, you can address and tag people, and it keeps track of your codebase throughout discussions.

A Kanban board is the only thing I missed for it to be perfect. That's where the simplicity of Trello was lord and master. Trello was and still is, easy to configure and fully customizable to anyone's needs.

GitHub recently introduced GitHub Planning.

Create issues, break them into tasks, track relationships, add custom fields, and have conversations. Visualize large projects as spreadsheets or boards, and automate everything with code.

That's everything and more of what I'm looking for in a tool. It's simple, elegant and close to the codebase. Best of all, you don't need a half-baked integration that only works if you make your commit history bloated.

We established that extensive tools are made for Project Managers. However, GitHub is a platform created for developers, and they have made a platform that comes developer-first.

It does that by building its solution around the code and not the other way around. The code is the heart of the project, and issues, features and planning come on top of that.

In my opinion, the end user of the system is the developer. They are the people that work with it the most and rely on history for context surrounding a codebase. Unfortunately, they are also the people hating on tooling like JIRA. It is worth listening to those people.

I'm not saying tools like JIRA are redundant because they are not. However, as a developer, I'm convinced that if they rethink their flow and build it developer-first, they will have a better product. And as a result, project managers would also have an easier time.

The love and hate relationship between developers and project management tools

Equilibra just launched its new website. It's one of the first websites I created using the Remix with Sanity stack. I love developing with Remix, mainly because the development flow is smooth.

The website runs fast, with lighthouse scores above 90. Remix powers the website behind the hood, and the CMS system is Sanity.

One of the challenges for Equilibra was the fact they have a lot of different treatments and prices. So it was essential to maintain the overview and clearly show the costs to those looking for them. So we talked things through, and it was clear that there are different kinds of treatments, so we grouped them.

The inspiration for pricing came from how many software products show their pricing because they usually have a way of showing prices that is easy to compare different tiers of pricing. So those are things that are important for Equilibra as well. 

I'm happy with how the website turned out, and most importantly, the customer is too. 👍

A new website for Equilibra

Web development is an area of expertise where things change quickly. But, unfortunately, not much stays the same. In a world where decision fatigue is expected, and the internet throws you stuff at the speed of light, having the proper resources might help reduce the number of triggers thrown at your brain.

Being a web developer and not enjoying web development is a hard thing to do. So if you're a web developer, you should find something to do that motivates you. Businesses are not waiting for you. It's in your best interest to stay up-to-date. Sticking to what you know means falling behind.

I'm not here trying to scare you. I'm in the same boat, and sometimes it feels like a lot is going on to filter through. For one, it's OK not to know everything. It's more important to follow what you like and keep you motivated. An overload of information will do the opposite. I will share some things to stay up-to-date and motivated to learn something. Learning things and going outside your comfort zone once in a while is fun!

There are a lot of developers in the world. And a lot of them are visible throughout the internet. I'm far from the biggest fan of social media, but Twitter is an excellent resource for staying up-to-date with web development. 

, and I started following only those who share web dev-related stuff.

Scrolling through my timeline brings me joy because I discover stuff I wouldn't have had without it. It shows me things I like because I only follow the people who interest me. I also follow the platforms I work with because they share when a new update comes out. In other words, Twitter is just a newsfeed to discover stuff.

Looking at people's GitHub profiles also gives you a ton of information. I discovered prisma.io just browsing someone's profile, and I thought, this looks fun. 🤷  

Podcasts seem to become popular at the moment. That's because they are fun to listen to. Even for web development, there are a lot of podcasts out there. 

 long ago, and I still listen to the same ones. I think listening to people talking about the stuff you love is fun. Sometimes people talk about stuff where you think: Well, I'll look that up!

, you will undoubtedly end up in an issue thread. If it's about a topic you care about, subscribe to it. You can always unsubscribe the moment you stop caring about the issue. Your interests will change with time, so there is nothing wrong with subscribing/unsubscribing.

Discord is well known, especially in the gaming community, but Discord is so much more than that. It's a tool for creating communities.

A lot of open-source projects have got a discord community. And I have been helped fast by asking a question in those. The only problem with Discord is that it does not get indexed by Google and other search engines. As an example, someone helped me with an issue. It will be harder to find a solution when another developer has the same problem. So it's a bit of a golden cage.

Like discord communities, some open source projects have their community based on Slack. However, Slack has similar pros and cons to Discord: you're getting help fast, but it's harder to track solutions to other people's issues.

It's essential to stay up-to-date when you call yourself a web developer. Especially when it comes to new features, technologies, trends, tools, best practices, and so much more, it's OK not to know everything there is to know because otherwise, you will burn yourself out. In other words, it's essential to have the right resources to stay motivated, learn, and, most importantly, keep up-to-date.

I've listed the most significant resources I use, and maybe they inspire you to find your own.

Keeping up to date with the latest web development trends

Commit messages to come in all forms and sizes. Clean git history is not a priority in many codebases, but don't be mistaken. It is essential. It is a way to keep your commit messages uniform and easy to read.

 are a way of writing commit messages that have been around for a long time. And here is an example of what one looks like:

The developer should write the commit from the user's perspective, not the developer's. Slight nuance, but it makes a difference.

You may provide a scope after a type, but it must consist of a noun describing a section of the codebase. feat(datepicker):

Writing a good commit message is food for discussion, and according to conventional commits (and myself), you should write the commit message in the present time.

An excellent way to write a message is to fill in the sentence:

If I commit my code, it will ... (add a magical unicorn)feat(forest): add a magical unicorn

We have covered most ways of writing commit messages, but a message body can still be filled in.

The body can include the motivation for the change and contrast this with previous behaviour.

The footer should contain any information about Breaking Changes.

Breaking Changes should start with the word BREAKING CHANGES: followed by space or two newlines.

A breaking change can be part of commits of any type.

Writing the perfect git commit message

remix.run is the (or not, to be confirmed) hot new Full Stack React framework around the block. A few knowledgeable engineers hype it at the moment. It should be noted that the founders 

 are mostly known for React Router, UNPKG, and Reach UI. Moreover, 

 has recently joined the team as director of developer experience to throw some more wood on the fire. Many developers have used at least one or more things that they made.

In this post, I will be talking about the following:

The entire idea behind Remix is that everything is server-rendered. As someone who has spent much time using things like 

, going mainly SSR is somewhat different.

To begin, their website says: Remix – Build better websites. Saying something like that lifts the expectations and raises the bar to a high level, especially when the competition for creating websites is enormous. NextJS, in particular, is probably the closest competitor for what Remix is trying to do. Moreover, I will not be comparing Remix with something like Gatsby, as Remix isn't a Static Site generator. Instead, the focus of Remix is server-side rendering, and even though you can use NextJS as an SSG, it has server rendering and does a lot of the same stuff Remix does, but differently.

I have mixed feelings about the initial setup. So let me carry you through this. Firstly, you do this in your terminal:

Following this, you see a fancy Remix animation in the console and a menu where you need to choose where to deploy your application. Depending on your pick, you get a project with different configuration files pre-made for the platform you will deploy. On the one hand, if you want to change hosting, you need to think about what needs to change to run it on the other platform. On the other hand, it doesn't feel great.

On the other hand, it does save you configuration time, it's easy, and the animated logo in the terminal looks pretty. 🤷‍♂️ Let's talk about the essential thing about Remix.

Firstly, routes are the most significant thing about Remix. To me, it feels like every route is a server route and conveniently has the option to render a client-side UI if you want. In essence, everything in Remix is about routes, and that's not a surprise if you look at the people that founded Remix.

Every route is a server route and conveniently has the option to render a client-side UI if you want.

Basically, on every route, you have the option to export things. So, for example, you can render a front-end, get data from somewhere, generate an RSS feed, or submit a form based on those things.

Just going over the basics, these are things you can expect from a route:

I'm not going to elaborate on the functionalities of Routes (nested routes, parameters, …), but those are things you want to take a look at once you know the basics.

Loaders are the backbone of the route, as they do all the heavy lifting. Therefore, you want to return to everything related to the data you need in this function's front end.

The idea behind a loader is that you can do more than return data for a route. You can send complete responses, including cache control headers. When you set cache headers on your response, the same route will get the cache if the route has already been fetched.

If loaders are the backbone, the client-UI is the frontal bone. In particular, the part you export as default is where you render your front end. So if you have fetched some data inside your Loader, you can get it here and render it for your visitors.

Getting the data from the Loader is pretty straightforward:

Everything else in the default export is basic JSX, putting components where you want them, and so on.

At this point, you could make your entire full-stack application with just these two things. In addition, RRemix makes the communication between the front- and back end pretty darn easy. You can fetch data from any API, and since it is server-side-rendered, you can fetch data with secret keys without worrying about exposing your secrets.

Remix makes the communication between the front- and back-end pretty darn easy.

Last but not least, actions. Actions are where things get interesting. Action is a server-only function where you can handle actions. It is the same as Loader; the only difference is when it's called. The action is called before the loaders if a non-GET request is made to your route (POST, PUT, PATCH, DELETE).

For example, an action could be submitting a form to subscribe to a newsletter.

First, we create a simple form like this:

Remix <Form> works identically to HTML <form>, with a few goodies. If JavaScript is turned off, the form will still work. Remember, the default form only supports GET en POST, so you should probably stick to those if you’re using a form.

And then, we create a server-side Action to handle the form submission. When no `action` is provided to a form, it will submit to the page itself.

To get back to the front end, you can receive the responses from the action in a few ways, one of them being useActionData.

When a POST is made to a URL, multiple routes in your route hierarchy will match the URL. Unlike GET to loaders, where all of them are called to build the UI, only one action is called.

Forms without an action prop (<Form method="post">) will automatically post to the same route within which they are rendered.

My first thought was: Oh, you can build an entire API like that. Nice. It’s the `/api` folder in NextJS (if you are familiar) but throughout the entire routing folder. Moreover, every route has the option to render a front end. That’s amazing.

With loaders and front-end rendering, you have all the basics to make an application. Everything else is improving the UX of the application.

Remix doesn’t stop at Loaders and Actions. My first impressions do, however. If you want to know more about Remix (like nested routes, Error handling, and so much more), I would strongly suggest looking at their website: 

Honestly, I can say that I’m hyped. I am a fan of serverless and JAMStack, so I started sceptically. Remix.run, to me, feels like you are working inside a web framework, not a React framework. You so happen to be, are working with React on top of it. Moreover, I have learned about Javascript in my adventure learning Remix, and I’m not done using it. It is promising - without a doubt.

In conclusion, a lot of things make sense. Thinking about what happens on the server and what doesn’t is something extra to think about, but that might be a good thing.

If you are a fan of magic, I recommend you to stick to NextJS (or Gatsby for even more magic) or whatever framework you are using now. But if you like bare-boned where you have control over everything, Remix might be your tool.

frrrip throwing remix.run into the mix my first impressions

In contrast to what the title might indicate, this blog post is not the start of a joke. Instead of dad joking around, I want to talk about casing in naming in programming.

Only interested in the short version about how I name my stuff in programming. Skip to the conclusion. If you want to go for the full story, keep on reading. Let’s dive in. 😊

In programming, spaces are a kind of character that is reserved. You can’t use spaces in variables, so we replace the spacing with something that allows us to still read it.

For example, if you declare a variable to indicate the visible item count:

Javascript would try to treat every word as a different concept. This means it treats visible, item, and count as individuals.

In conclusion, removing spaces is something you cannot ignore in programming. In this blog, I will share my thoughts about different kinds of ways to remove spacing from words, but I will mainly focus on how I think you should name your files.

To use camelCase, you strip the spaces from your words and capitalize every word except the first.

This way of capitalizing is commonly used for variable declaration.

To write something in Pascal-Case, you start every word with capital and remove the spacing.

You can write something as kebab-case by turning everything lowercase and replacing spaces with dashes (-).

This is commonly used to write readable URLs (example.com/blog/title-of-the-blog-post).

Camel Case seems to have become the standard for naming files in front-end development. Why is that?

Over the past years, I had a few naming conventions. For instance, I used Pascal Case for components, kebab-case for utilities, and camelCase for everything else. This way, I could expect what was inside the file without opening it. I like the idea, but things get tricky when stuff changes. FYI, file systems that are by default case insensitive, like macOS, have issues when changing caps and submitting them to your repo. It’s a recipe for failure at one point or another. There is always a way to fix it, but in my opinion, it’s not worth the hassle. If I have to rely on the file name casing to know what I would expect inside the file, it would probably mean there are issues in my project structure in the first place.

Over time, I switched to all lower cases (kebab), and I love it. In essence, these are the key benefits of kebab as opposed to camelCase:

To me, it seems like a small tradeoff for a lot of benefits.

In addition, I’m not the only developer thinking this way. For example, Kent C. Dodds replied to a tweet about someone who had an issue with capitalization when his application was deployed to a (most likely) Linux server.

Conclusion: my preferred naming conventions

Long story short, this is how I like to name stuff in my codespaces nowadays:

What’s your preferred naming convention? Let me know! 😁

A kebab, a camel, and pascal walked into a codespace

Contact me

ContactForm

contact

Uptime Kuma is a self-hosted monitoring tool like "Uptime Robot". Installing it on a raspberry pi can easily be done by installing it using docker.

Uptime Kuma is a self-hosted monitoring tool like "Uptime Robot".

installing uptime kuma status checks on docker

Step 2: Download the Convenience Script and Install Docker on Raspberry Pi

Step 3: Add a Non-Root User to the Docker Group

The commands guide you through the installation of docker on your raspberry pi

Installing docker on raspberry pi

Portainer is a visual interface for Docker.

Installing Portainer for Docker

Using the soft flag, you can preserve the changes you want to undo. You'll find the changes as uncommitted local modifications in your working copy.

If you don't want to keep these changes, use the --hard flag. Be sure to do this when you're sure you don't need these changes anymore.

quick commands on how to reset to the previous commit

undo last commit

config to fix eslint issues when having a monorepo in vscode

fix monorepo eslint issues vscode

You still have the repo online and offline, but they are not linked anymore

Git commands collection

If you use a new host or something like `bitbucket.org-clientname` as `host`. You need to add it to your ssh.

Commands to create specific ssh keys for multiple hosts

setting up ssh keys for github and bitbucket

You can read this blog article to see why this is a successful way of branching. In this flow, we have the main branch and a development branch. 

That squashes your PR into one commit on the development branch. If there are conflicts, you need to rebase against development again. To do that, you run the following command in your feature branch.

In this post, I present a Gitstrategy for developing and releasing software.

git flow with rebasing

You can find out what is running on a specific port by running the command lsof -i with the port number, :<PortNumber>.

Or you can kill al processes with the following command:

How do you find what is running on a specific port so you can make it available again?

killing a port on macos

Updating packages is essential to get the latest features and reduce security issues. npm-check-updates is an npm package that makes the process of updating packages easier. Here's my flow of how I update packages.

If you don't want to install the package globally, you can run it with npx.

When you run the command below, you will get an overview of all packages that have updates available. 

We will be updating packages in turns. First, we update the least impactful, followed by minor versions and last but not least, the packages that have breaking changes.Before moving to the next step, we run npm i, checking if something breaks.

A change in major versions usually indicates that there are breaking changes. So look up the package and go and check the release notes. Once you do, you have two options. You could update all the major versions with 

, but it's better to update them one by one.

 lets you filter the packages you want to update. After that, you can proceed to the next major package that needs an update.

Updating packages is essential to get the latest features and reduce security issues. npm-check-updates is an npm package that makes the process of updating packages easier. This post shows what's my flow of updating packages.

Safely update your packages

Note apps on Fly require a globally unique name. We've used the name of the current directory, plus four random characters. You can change this at any time BEFORE you deploy.

In development, it's better to use a local database, The easiest way to do this is using Docker. To start your Postgres database, first make sure you have Docker running, then run the following command:

That may take a moment to start up as it needs to get the Postgres image from the Docker registry. After it is ready, you'll need to migrate your database. With the database prepared to accept connections, open a new tab and run this:

When this finishes successfully, it will say "All migrations have been successfully applied".

If you prefer not to use Docker, you can also use Fly's Wireguard VPN to connect to a development database (or your production database). You can find the instructions to set up 

With your Postgres database up and running in one tab and set up with tables for your data model via Prisma, you're ready to start the dev server. But first, run this command in a new tab in your terminal:

That command starts your app in development mode, rebuilding assets on file changes.

Using GitHub actions, you can automatically deploy your application to fly.

Before your first deployment, you'll need to do a few things:

Make sure you have a FLY_API_TOKEN added to your GitHub repo. Go to your user settings on Fly and create a new token, then add it to your repo secrets with the name FLY_API_TOKEN. Finally, you'll need to add a SESSION_SECRET to your fly app secrets. To do that, you can run the following commands:

If you don't have OpenSSL installed, you can also use 1password to generate a random secret. Just replace `$(openssl rand -hex 32)` with the generated secret.

afterwards, you'll need to connect your database to each of your apps

Fly will take care of setting the DATABASE_URL secret for you.

Everything is ready, and now you can commit and push your changes to your repo. Every commit to your `main` branch will trigger a deployment to your production environment, and every commit to your `dev` branch will trigger a deployment to your staging environment.

Guideline on how to deploy an app with a Postgres db to fly.io

Deploying to fly with a postgres db

There are two options to do this. You can find the first way on 

. We will handle the second way when we come to it.

Always create a backup of your current network settings. Then, if something were to go wrong, at least you can go back to the previous settings.

The IP configuration of the network adapters is saved in the configuration file dhcpcd.conf in the /etc folder. Open the file with the nano editor:

At the bottom of the file, add the following lines:

Once you have changed the file, save the adjustments with Ctrl + X, y, enter`.The changes will not be visible immediately. So you're probably better of restarting your raspberry pi at this point.

After the restart, you can find the raspberry pi on the IP address you have configured.

That's it. Your Raspberry Pi is now accessible via SSH. Ensure the device is connected to the internet before establishing an SSH session.

Essential configuration of my raspberry pi's

Contact me

You can email me

Get in touch