DEV Community: Quentin Delcourt

Opinions worth sharing

Quentin Delcourt — Fri, 07 Aug 2020 22:46:40 +0000

Very often in my career, I was faced with colleagues or managers' decisions that I thought would bring some trouble.

There is sometimes an opportunity, before the decision starts actually triggering real life effects, where there is still time to raise your voice and share your concerns with your team.

I am not an extrovert and convincing people has never been my forte, which sometimes prevented me to speak when I should have spoken.

I once heard about a decision to change a legacy CMS to replace it with a brand new, also custom CMS. On top of bringing absolutely zero new advantage to the end users, I also knew about Spolsky's law, aka you never rewrite a software from scratch.

I tried to fight it, but struggled to make my point. I gave up pretty quickly and thought that maybe the people leading the decision knew better. Despite my gut feeling. And of course I was very wrong.

I should have make my voice heard and share my opinions. The decision led us to many performance problems and a system that was not necessarily better than the previous one. And no gain for the end users. Hence, by not raising my voice, I brought myself in a very uncomfortable situation.

When you think something is not right, don't keep it to yourself, share it with your colleagues. You might thank you later 🙂

Cover photo by Oleg Laptev on Unsplash

Computer science students: do you have classes about tools?

Quentin Delcourt — Tue, 04 Aug 2020 19:24:11 +0000

I'm talking about things like version control, the command line, IDEs, etc.
Things that are wonderfully explained in the following MIT course, "The Missing Semester of your CS Education"
https://missing.csail.mit.edu/

And I'm wondering, since I got out of school in 2004 and such classes weren't in the cursus: is it still the case? And is there a difference between "classic" schools and bootcamps?

Vim Survival Toolkit

Quentin Delcourt — Tue, 30 Jun 2020 12:48:28 +0000

TL;DR Skip to the commands.

I used to hate Vim.

Back when I was in CS school, teachers took great pleasure in forcing us to use this dinosaur tool that you can only despise after 5 minutes of use. But nowadays I can thank my teachers for getting all this knowledge into my head.

Indeed, you don't always have the opportunity to have an Atom, a VSCode or a PHPStorm to edit a file.
Sometimes, you have to log in with SSH on a production server to remove a "," from a configuration file that is currently rendering the said server unusable.
And then the ony editor at your disposal might be Vim.

There are people who use Vim as an IDE, but I'm not among them. Instead, I have a basic knowledge of it that allows me to do only
the very necessary and most simple stuff. Editing, moving around, saving, and most importantly when it comes to Vim: quitting.

The commands below are, in my humble opinion, the only essential commands you need to know in order to survive with Vim.

Editing

i 👉 start editing at the current position
a 👉 same but moves the carret to the next char

Exiting

ESC 👉 gets you back in "command" mode and stops edition of the file
:q↩️ 👉 quit
:q!↩️ 👉 quit even if changes were made
ZZ↩️ 👉 save and quit

Searching

/something↩️ 👉 Finds "something" in the file and moves the carret to the first found occurrence
n 👉 Finds the next occurrence of the word you searched for and moves the carret to it
N 👉 Previous

Undoing

u 👉 Undo
Ctrl + r 👉 Redo

Moving

G 👉 Go to the end of the file
gg 👉 Go back to the start of the file

Playing with lines

o 👉 Insert a new line below the carret
O 👉 Insert new line above the carret
dd 👉 Remove the current line
5dd 👉 Remove 5 lines starting from the current line (but you can enter any number you want)

These commands have allowed multiple production servers to be saved over the last 15 years 😁

Don't call jsonSerialize() explicitly

Quentin Delcourt — Wed, 24 Jun 2020 22:58:07 +0000

TL;DR don't call jsonSerialize() directly, always pass the object implementing it to the json_encode function.

JsonSerializable is a handy PHP feature that was introduced in PHP 5.4.
It lets you define how an object should be transformed into JSON when passed to the json_encode function.
For example, if you were to order a box of chocolate and send a preview of it to someone you offer it to,
you might want to show the content of the box but not its price.

By defining an array of properties (but the return value could be anything that could be serialized to JSON), you get to decide what information will be returned in the resulting JSON:

final class ChocolateBox implements JsonSerializable
{
    private int $price;
    private array $chocolates;

    /* Magic code to build the box... */

    public function jsonSerialize() : array
    {
        return [
            'chocolates' => $this->chocolates,
        ];
    }
}

So far, so good.
And then, in the client, usually a controller, I sometimes see this:

final class ChocolateBoxController
{
    public function indexAction(Request $request, ChocolateBoxService $chocolateBoxService) : Response
    {
        $chocolateBox = $chocolateBoxService->getRandomBox();

        return new Response(
            json_encode($chocolateBox->jsonSerialize())
        );
    }
}

👆 Can you spot the problem in the code above?

We're calling json_encode and passing it the result of the jsonSerialize method.
That's not the idea... json_encode actually knows about the existence of the function if the object it's being passed
implements the JsonSerializable interface.

Therefore, simply passing the object to json_encode is enough:

json_encode($chocolateBox)

👇 gives us

{
    "chocolates" => [/* delicious list of chocolates */]
}

It even works when you bury the object in another structure, such as an array:

json_encode([
    'data' => $chocolateBox,
])

👇 gives us

{
    "data": {
        "chocolates" => [/* delicious list of chocolates */]
    }
}

By implementing the interface you allow json_encode to get what it needs out of an object.
Your work stops right after that, let json_encode do the rest...

Originally published on quentin.delcourt.be

Deploy an Eleventy website using GitLab CI

Quentin Delcourt — Tue, 11 Feb 2020 13:07:30 +0000

Here's how to use GitLab CI to easily deploy a static website to a virtual private server.

When choosing a hosting solution for a static website, there are free and very powerful solutions like Netlify or GitHub.
The former especially excels in providing very easy and lighting fast solution to deploy a website in matter of seconds.

But what if you want to develop on a good old VPS or metal server, going the self-hosted route?
You might already need your server for other applications and use it as well for static content hosting.

Wen you used a few automation tools, there is no way back to that time where we were uploading manually our files using (S)FTP.

Fortunately, you can avoid the chores of manual upload by using a tool such as GitLab CI.
This allows you to, for example, trigger a copy of the changed files whenever the master branch is updated.
Most of GitLab CI configuration is not done via the GitLab app but rather using a YAML file (it seems most things these days are configured using YAML files).

This is the GitLab CI configuration (.gitlab-ci.yml) I created to automatically push changes to the server.

stages:
  - build
  - deploy

eleventy:
  stage: build
  image: node:lts-buster
  cache:
    key: "$CI_JOB_NAME"
    paths:
      - node_modules/
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/
  only:
    - master

rsync:
  stage: deploy
  image: instrumentisto/rsync-ssh
  script:
  - mkdir "${HOME}/.ssh"
  - echo "${SSH_HOST_KEY}" > "${HOME}/.ssh/known_hosts"
  - echo "${SSH_PRIVATE_KEY}" > "${HOME}/.ssh/id_rsa"
  - chmod 700 "${HOME}/.ssh/id_rsa"
  - rsync -avH dist/* -e ssh ${SSH_USER}@${SSH_HOST}:${WEBROOT_PATH}
  only:
  - master

There are two main things happening here:

Eleventy generates the static files.
The changes are copied to the server.

Defining the order of stages

stages:
  - build
  - deploy

The block above will tell GitLab CI to execute all jobs from the build stage first, then the deploy stage.
You can declare several jobs in the configuration file and assign each of these jobs to a particular stage.

Build stage

The build stage is for installing all node.js dependencies and run Eleventy to generate the static files.

We define a "eleventy" job and assign it to the "build" stage:

eleventy:
  stage: build

image is to attach a specific container image to the job. Here we'll use a long term support node version:

  image: node:lts-buster

The cache is really important to make the deploy faster: it allows us to keep the node_modules folder from
one deployment to the other. Here we use the job's name as key for the cache, so that only this job
retrieves the cache, it will not be used on other cases:

  cache:
    key: "$CI_JOB_NAME"
    paths:
      - node_modules/

Now we define the job's work by defining a set of bash instructions to be executed.
We install the node modules and run eleventy:

  script:
    - npm install
    - npm run build

Our files are generated, we need to store them somewhere to send them on the server.
To accomplish that, GitLab CI provides the "artifacts" system.
We can define the files that will be saved in the artifact and reuse them in another job:

  artifacts:
    paths:
      - dist/

Finally, we ask GitLab CI to run this job only when a commit is pushed to the master branch:

  only:
  - master

Deploy stage

To deploy the files on my server I use a combination of Rsync and SSH.
The good news is that there is a Docker container that has these two dependencies installed directly, no need to install them at runtime 😎
So let's declare a new job and, for this one, we'll use this new image:

rsync:
  stage: deploy
  image: instrumentisto/rsync-ssh

The first part of the job is to create an SSH configuration within the new container:

  script:
  - mkdir "${HOME}/.ssh"
  - echo "${SSH_HOST_KEY}" > "${HOME}/.ssh/known_hosts"
  - echo "${SSH_PRIVATE_KEY}" > "${HOME}/.ssh/id_rsa"
  - chmod 700 "${HOME}/.ssh/id_rsa"

All of these information are very sensitive, that is why we don't store them directly in the .yml, which will
be commited in the repository. Instead we can make use of GitLab CI's environment variables.
To define these variables, you can go in your repository's settings on GitLab and add the necessary variables there.

The second part of the script takes care of using rsync to send the changes over SSH:

- rsync -avH dist/* -e ssh ${SSH_USER}@${SSH_HOST}:${WEBROOT_PATH}

The dist folder will be available to this job, as it was declared as an artifact in the eleventy job.

Finally, we once again ask GitLab CI to run this job only whenever a change is pushed on the master branch:

  only:
  - master

And... voilà!
Now we can push our changes on master and they will be automatically deployed on the server, nothing more to do! 🎊 🎉

You can find a complete copy of this script on gist:

https://gist.github.com/kant312/da097ad3f91ecc110792df54a95ed82f

The Demo Effect

Quentin Delcourt — Wed, 29 Jan 2020 10:36:46 +0000

Developers worldwide share a few common fears: the time when a project manager
asks for an estimate, the fear of being an impostor, the fear of not delivering
on time for a deadline. And then there's a very scary thing that is known in the
development world as the "Demo Effect".

The Demo Effect happens whenever you need to present your (supposedly finished,
or almost) work to a client, an N+1 or any other kind of spectator.
You will, with pride, show the features you've been working on for
[weeks|months|years]. You feel very confident, you tested it all before,
and all of a sudden, the
application crashes in front of your audience.
This is the Demo Effect.

Why is it happening? We developers tend to be biased and use data that will
fit our best case scenarios. Once we start fiddling with more realistic data
for the sake of our presentation, that's where the cracks in our programs
begin to appear.

DDD: Demo Driven Development

My company recently adopted a new habit, which is the "Friday demo".
The format is quite simple: each department has someone on their team
doing a little, 5 minutes presentation. This is a good idea as the short
format reduces the pressure (it's not like you're doing a one hour talk).

Our team was asked to present something, and I thought that
I could demo one of our most advanced, but still in development feature.

I tested many things beforehand and thought that the feature was
ready to go to QA. So naturally I thought this would be a piece of cake.
And of course I was very wrong.

I started inserting records with real names of real people. With extended
latin characters. That's where I noticed there were collation problems
with the database.

I started having more than 10 records in my test DB, which showed problems
with the pagination system.

I started using the application a lot, instead of testing it, which showed
me there were some async problems, and some other bugs.

I later explained that to my colleagues and, as a joke, said we could now do
DDD: Demo Driven Development. But it might be a really good thing to keep doing
that once in a while, as it helps us get into the users shoes.

I might start doing Demo Driven Development from now on, and overcome my fear
of the Demo Effect.