Solargraph is a Ruby Language Server. It’s meant to add code completion and inline documentation onto IDEs.

We have to install the gem first

gem install solargraph

Within Sublime Text Control Panel (CTRL+Shift+P) :

  1. Find Package Control: Install Package
  2. Then LSP
  3. Hit enter

By default, the ST plugin will look for rvm, not rbenv. We have to force the settings Preferences > Package Settings > LSP > Settings, and paste this :

Note : you need to adjust the value of the path on line 8. You can find the exact installation path of solargraph on your system with the following command

which solargraph

Finally we can enable the server via the Sublime Text Control Panel (CTRL+Shift+P)

Rubocop is a static code analyzer and formatter for Ruby. Long story short : it helps you to write better code.

Installing it pretty straight-forward :

gem install rubocop

Within Sublime Text Control Panel (CTRL+Shift+P) :

  1. Find Package Control: Install Package
  2. Then Rubocop (currently v2018.
  3. Hit enter

By default, the ST plugin will look for rvm, not rbenv. We have to force the settings Preferences > Package Settings > Rubocop > Settings - Users, and paste this :

Now we can have a list of the available options by typing rubocop withing the Control Panel (CTRL+Shift+P).

Yesterday I had to clean some very old branches on a project’s codebase. Here’s a few git tricks I had to use.

List merged branch (excluding master and staging) :

git branch --merged | egrep -v "(^\*|master|staging)"

Delete them locally :

git branch --merged | egrep -v "(^\*|master|staging)" | xargs -n 1 git branch -d

Delete them remotely :

git branch -r --merged | grep -v "origin/master$" | grep -v "origin/staging$" | sed 's/\s*origin\///' | xargs -n 1 git push --delete origin
git remote prune origin

Source :

Display branches with oldest commit datetime :

for branch in `git branch -r | grep -v HEAD`;do echo -e `git show --format="%ci %cr" $branch | head -n 1` \\t$branch; done | sort -r

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='' -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 (, 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.