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

First, check that your development machine has both docker and docker-machine installed

which docker
which docker-machine

Create a new droplet on Digital Ocean

docker-machine create --digitalocean-size "s-1vcpu-1gb" --driver digitalocean --digitalocean-access-token YOUR_DIGITALOCEAN_ACCESS_TOKEN invoiceninja-prod

Set up the right environment

eval $(docker-machine env invoiceninja-prod)

Run the container

docker run -d -e APP_ENV='production' -e APP_DEBUG=0 -e APP_URL='http://ninja.dev' -e APP_KEY='SomeRandomStringSomeRandomString' -e APP_CIPHER='AES-256-CBC' -e DB_TYPE='mysql' -e DB_STRICT='false' -e DB_HOST='localhost' -e DB_DATABASE='ninja' -e DB_USERNAME='ninja' -e DB_PASSWORD='ninja' -p '80:80' invoiceninja/invoiceninja

Retrieve your IP

docker-machine ip invoiceninja-prod

Today on #indieweb-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 (gandi.net, 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.