Skip to main content

Triggering a command line on file change

1 min read

Today I was migrating a somewhat old codebase to Ruby on Rails 6.0.0. As per usual, this can be a very tidious job requiring a bunch of depencies to be updated as well. In this case, the Gemfile contains around 150 lines.

When I have to do that kind of job, the first thing I do is commenting out every single gem except for rails itself, then bundle update, then I re-add the other gems to the Gemfile.

It rarely goes smoothly, since every gem has it's own dependencies and sometime the bundle command has trouble to find a way to update everything in one go, so I usually re-add 2-5 gems at once then run bundle update on my modified Gemfile, until all the dependencies have been re-added.

The whole process of going back and forth to editing, saving, running the bundle command is somewhat exhausting, so today I decided to have a look at a more productive way to do this : the following command uses inotifywait to detect whenever I save the Gemfile then run bundle update automagically.

while inotifywait -e close_write Gemfile; do bundle update; done


Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk | Riding Rails

Accélérer l'exécution de la commande bundle et l'installation des gems

2 min read

Il y a quelques jours, j'ai travaillé sur une mise à jour majeure d'une application écrite en Ruby on Rails. L'application tournait sur la version 3.2 du framework, et celle-ci étant dépréciée depuis longtemps, il était largement temps de la faire passer en version 5.2.

Cela signifie donc deux passages de versions majeures et 4 passages de versions mineures. Avec, pour chaque saut de version, la nécessité de mettre à jour les versions des gems utilisées. Autant dire que la commande bundle a été sollicitée.

Le point de frustration était l'approche itérative de bundle (la première dépendance est vérifiée et mise à jour, puis on passe à la seconde, etc) dans un fichier qui comptait pas moins de 137 dépendances. Ce qui m'a poussé à fouiller la documentation de bundle pour y découvrir l'option --jobs qui permet de définir un nombre de processus concurrentiels.

Pour lancer 4 jobs en parallèle, on peut donc lancer la commande comme ceci :

bundle install --jobs=4

Il est également possible de définir cette configuration par défaut pour ne plus avoir à s'en soucier à l'avenir :

bundle config --global jobs 4

En bonus, on peut également demander à ne plus installer les documentations par défaut (soyons francs, tout le monde va chercher la documentation sur Internet, il est inutile d'avoir une version locale). Pour ce faire, il est nécessaire de créer un fichier ~/.gemrc et d'y inclure :

gem: --no-rdoc --no-ri

Why I switched back to Wordpress - even if I always said I hated it

2 min read

Today on -wordpress, I've been asked why, given my technical background, I did not used some of the Ruby based solution to jump in and try the Indieweb principles.

As a reminder, I (re)discovered Indieweb and POSSE a few days ago now, and even if I've been using Ruby and Rails as my main languages for almost a decade now, I choose to setup a new Wordpress blog to play around with it.

There are a few reasons for this :

  1. Setting up a Wordpress was a one-click task with my current host (, thanks for asking)
  2. I read along the Indieweb wiki for a few days, gathering information about how it is supposed to be done, and why everyone should have their own website. In the wiki, most of the tutorials were Wordpress based and it seems to me like a good place to start. To be completely honest I did not even noticed there was a Ruby page.
  3. Even if I do not like Wordpress, I have to admit that the community around it is huge, thus, more chance to find every plugin I would need to setup my new home on the Internet
  4. I never said I'd stick with Wordpress. More likely I am going to play around with it for a few, then find my way back home with a Ruby on Rails solution.