Skip to main content

When it comes to starting new projects

1 min read



Gazouillis sonnant de moins en moins juste…

… comme mode de déploiement alternatif

2 min read

Going to redeploy my (this) personal website...
I need to allocate more RAM as i'm starting to see starvation coming.

Wish me luck.. Last time I had it re-deployed was last month🍀

The deployment script started around 14h27.

Container build just started 🐋

JavaScript runtime is installed 💛

PHP extensions are being compiled 🐘

(it seemed to take ages in comparison with the other steps)
there might be room for optimization here
no sure how though 🤔

Extensions are being configured now.

JavaScript assets have been installed, minified.

Checks, clean up have started

Website is still up but slow 😌

Ok… I broke everyting 😐

The deployment script failed around 15H36 with an unexpected status.

What did go wrong?

Apparently, what I call the web worker (PHP FPM) could start
because of ill-defined owner uid injected with --build-arg options.

At some point, I had the system user uid modified
without double checking there would not be any regression.

@mereteresa's question surprised me and gives me a interesting idea 💡

En réponse à cela :

J'ai le terminal en face de moi et je crois que la dernière étape m'a tuer

Mais ça me permet aussi de prototyper 😅

La bonne nouvelle c'est que mes autres sites ne sont pas tombés
alors que le reverse proxy a clairement redémarré.

Ah ben je m'en suis douté :P

Terminal où on peut voir une commande comparant le titre d'une page du site déployé différent de celui prévu

Un peu plus tard, j'ai compris qu'une modification récente de la page d'accueil aurait eu un impact sur le test de vérification effectué après déploiement.
Ce dernier était en échec 🚨 mais pour de mauvaises raisons.

C'était aussi de cette manière que je me suis embourbé dans mes tentatives de déploiement d'un correctif.

D'où l'importance de vérifier qu'un test rouge avant une modification (dans le cas contraire, on peut se trouver nez à nez ici avec un faux négatif).

Why not deploying by tweeting something?
It should be pretty easy to deal with such once the connectors are in place…
I'll keep that under wrap for now… Other stuff to take of 😅



Removing ambiguity from command-line application entry points

2 min read

In a series related to development hiccups🥴
here is another one:
this week, I've been repeatedly (for about an hour or so if I recall correctly)
running the following command 
make start with the intent (well 😮‍💨)
to start a development environment

make start

In fact, the aforementioned Makefile target
was an indirection layer
for running npx nuxt start.

That command is not supposed
to run in development
as nuxt help command suggests.

npx nuxt start

nuxt command help output suggesting start is to be run for starting the application in production mode

While this indirection layer
(an intermediate Makefile target)
usually helps me in reasoning
about how I run applications in production
(by keeping in mind there should be a start target).

When I was intending to starting developing something,
my mental model was being abused
and one hour was simply wasted.

Some might be confused about the message
I'm trying to communicate so let's see
what running make help returns as output.

We see here that there is in fact a dev target
for starting a development server
and the start command triggers
a production server start.

Running `make help` show all commands needed are in place (for starting development environment, building production and starting production server)

Even though commands have been thought,
implemented upfront to be working "as intended"
depending on separate environment,
we can never really know how they will be used
("users" are key components of interaction,
be it for web pages or command-line applications).

With regard to our example,
a short message was added to notify users
(i.e. myself) that a production server is about to be started.

At this point, it's too late already (when considering the cost of running a server in production instead of starting a development server)
but it might be a good-enough failsafe considering
such message helps in realizing we're not running the intended target.

Output reading `Make dev`About to start development server

With a message suggesting that we're going to start a production server



About a Blender Python Starting Guide

authored by Félix

1 min read

See Blender Python Starting Guide blog's article,
which i came to be curious about and
in response to what, JRB. said

This is a reminder for asking him in due time
what they're going to show at BCON in next october (BlenderConf 2022)