Skip to main content

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

Mutt + ProtonMail

4 min read

Il y a maintenant plusieurs semaines que j'utilise ProtonMail. Bien que rassembler mes 7 adresses précédentes sur une seule m'a grandement simplifié la vie, je ne suis toujours pas satisfait des clients disponibles. Sous Linux, seul Thunderbird est actuellement disponible, à moins d'utiliser de webmail - ce que je fais pour l'instant.

Il y a quelques années, j'avais testé Mutt un peu comme un jeu. La raison pour laquelle j'avais arrêté de l'utiliser était justement le nombre d'adresse que je devais gérer : l'outil était certes intéressant, mais difficile à utiliser avec autant de compte.

Maintenant que j'ai résolu ce problème, j'avais envie de redonner une chance à ce client minimaliste et, par la même occasion, voir s'il était possible de faire cohabiter Mutt et ProtonMail.

Installation et premier lancement

Pour installer mutt, il suffit d'installer le paquet du même nom :

sudo apt install mutt

En lancant pour la première fois la commande mutt, je reçois une erreur :

/var/mail/cedric: Aucun fichier ou dossier de ce type (errno = 2)

Je crée le fichier en question et je lui donne les permissions nécessaire à mon utilisateur :

sudo mkdir -p /var/mail/$(whoami)
sudo chown $(whoami):$(whoami) /var/mail/$(whoami)

J'en profite pour initialiser le fichier de configuration .muttrc

vim ~/.muttrc
set realname = "Your Name"
set header_cache =~/.mutt/cache/headers
set certificate_file =~/.mutt/certificates
set message_cachedir =~/.mutt/cache/bodies

Lancer une nouvelle fois la commande mutt, ne donne plus d'erreur.

[caption id="attachment_4409" align="alignnone" width="1024"] Premier écran du logiciel Mutt - un client mail en ligne de commande. Au moins, c'est épuré :-)[/caption]

Configuration de mutt

Note : je pars du principe que le Bridge pour Linux est installé et lancé.

J'ajoute au fichier de configuration .muttrc les lignes suivantes:

# "+" substitutes for `folder`
set mbox_type=Maildir
set folder=/var/mail/cedric/
set spoolfile=+INBOX
set record=+Sent
set postponed=+Drafts
set trash=+Trash
set mail_check=2 # seconds

# smtp
source ~/docs/keys/mail
set smtp_url=smtp://$my_user:$my_pass@127.0.0.1:1025
set ssl_force_tls
set ssl_starttls

Et dans le fichier ~/docs/keys/mail:

set my_user=EMAIL
set my_pass=MOT_DE_PASSE_DU_BRIDGE

Installation et configuration de OfflineIMAP

J'installe OfflineIMAP :

sudo pip install offlineimap

Puis je crée un fichier de configuration .offlineimaprc :

[general]
accounts = main

[Account main]
localrepository = main-local
remoterepository = main-remote

# full refresh, in min
autorefresh = 0.2

# quick refreshs between each full refresh
quick = 10

# update notmuch index after sync
postsynchook = notmuch new


[Repository main-local]
type = Maildir
localfolders = /var/mail/cedric

# delete remote mails that were deleted locally
sync_deletes = yes


[Repository main-remote]
type = IMAP
remoteport = 1143
remotehost = 127.0.0.1
remoteuser = EMAIL
remotepass = MOT_DE_PASSE_DU_BRIDGE
keepalive = 60
holdconnectionopen = yes

# delete local mails that were deleted on the remote server
expunge = yes

# sync only these folders
folderfilter = lambda foldername: foldername in ['INBOX', 'Archive', 'Sent']

# is broken, but connecting locally to bridge so should be ok
ssl = no

On lance la commande offlineimap, et, si tout s'est bien passé, on peut commencer à voir la progression de la synchronisation avec ProtonMail :

OfflineIMAP 7.2.1
  Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)
imaplib2 v2.57 (bundled), Python v2.7.14, OpenSSL 1.0.2g  1 Mar 2016
Account sync main:
 *** Processing account main
 Establishing connection to 127.0.0.1:1143 (main-remote)
 Creating folder INBOX[main-local]
 Creating new Local Status db for main-local:INBOX
 Creating folder Archive[main-local]
 Creating new Local Status db for main-local:Archive
 Creating folder Sent[main-local]
 Creating new Local Status db for main-local:Sent
Folder Archive [acc: main]:
 Syncing Archive: IMAP -> Maildir
Folder INBOX [acc: main]:
 Syncing INBOX: IMAP -> Maildir
Folder Archive [acc: main]:
 Copy message UID 1 (1/263) main-remote:Archive -> main-local:Archive
Folder INBOX [acc: main]:
 Copy message UID 1 (1/49) main-remote:INBOX -> main-local:INBOX
Folder Archive [acc: main]:
 Copy message UID 2 (2/263) main-remote:Archive -> main-local:Archive
Folder INBOX [acc: main]:
 Copy message UID 2 (2/49) main-remote:INBOX -> main-local:INBOX

Il ne reste plus maintenant qu'à relancer la commande mutt pour visualiser ses mails.

[caption id="attachment_4413" align="alignnone" width="1024"]Mutt est maintenant configuré pour fonctionner avec ProtonMail L'interface de Mutt une fois la configuration terminée[/caption]

Langserver.org

1 min read

" The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool "

My Url Is

1 min read

"My Url Is features a new guest every two weeks to talk about how they got involved with the IndieWeb and what hopes, goals and aspirations they have for the community and for their website. The guests are a combination of those both new to the IndieWeb and those who have helped build it from the beginning."

I Need A Budget - Using YNAB with belgian bank accounts

1 min read

I recently discovered that budgeting might not be as boring as I thought. Better yet, budgeting might help me achieve my goals in life.

The problem is in this pre-PSD2/XS2A world, syncing my bank accounts with YNAB is a real pain and I tried to automate the process to the best that I could.

Current workflow :

  • Downloading my accounts statements in CSV from by bank (BNP Paribas Fortis) (manual - i tried to automate this step with iMacros for Firefox, but failed)
  • Parsing the CSV and converting it to a valid OFX file via https://csvconverter.biz/ (semi-manual, but at least i've got the file just right)
  • Import each file to YNAB through drag'n'drop (manual, but easy)

I started using YNAB only a week ago, I'll probably have a lot more to say about it in the next few months.

AttributeError: module 'ofxstatement.plugins.alfabank' has no attribute 'AlfabankPlugin'

2 min read

I just installed ofxstatement to play around with, but i'm stuck with this error while running ofxstatement list-plugins

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2324, in resolve
return functools.reduce(getattr, self.attrs, module)
AttributeError: module 'ofxstatement.plugins.alfabank' has no attribute 'AlfabankPlugin'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/bin/ofxstatement", line 11, in <module>
load_entry_point('ofxstatement==0.6.1', 'console_scripts', 'ofxstatement')()
File "/usr/lib/python3/dist-packages/ofxstatement/tool.py", line 150, in run
return args.func(args)
File "/usr/lib/python3/dist-packages/ofxstatement/tool.py", line 68, in list_plugins
available_plugins = plugin.list_plugins()
File "/usr/lib/python3/dist-packages/ofxstatement/plugin.py", line 26, in list_plugins
return sorted((ep.name, ep.load()) for ep in plugin_eps)
File "/usr/lib/python3/dist-packages/ofxstatement/plugin.py", line 26, in <genexpr>
return sorted((ep.name, ep.load()) for ep in plugin_eps)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2326, in resolve
raise ImportError(str(exc))
ImportError: module 'ofxstatement.plugins.alfabank' has no attribute 'AlfabankPlugin'
$ python --version
Python 2.7.14

Please let me know if you need additional information

Identifier une régression grâce à git-bisect

3 min read

Enfer et damnation, vous venez de constater un bug dans votre code. Évidemment, il est difficile de savoir à quel moment cette régression est apparue et en trouver l'origine pourrait nous permettre de comprendre et donc de résoudre le bug.

Heureusement, git-bisect vient à votre secours, pour peu de savoir l'utiliser.

On commence donc par signifier à git que nous sommes dans un état "mauvais" du code :

git bisect bad

Vous devez démarrer avec "git bisect start"
Souhaitez-vous que je le fasse pour vous [Y/n] ? y

Il faut maintenant remonter suffisamment longtemps dans l'historique dans l'objectif de trouver l'état du code ou la régression constatée n'existait pas. Un petit git log devrait suffire à identifier le commit-id correspondant.

git checkout <commit-id>

Après avoir vérifié que la régression n'existait pas dans cet état du code, on signifie à git-bisect qu'on a une sous la main une version du code correcte.

git bisect good
Bissection : 132 révisions à tester après cette (à peu près 7 étapes)
[<commit-id>] <commit-message>

En retour, git-bisect nous donne le nombre de révisions à tester (ici : 132), et le nombre d'étapes estimées avant d'obtenir le nom du coupable (ici : 7). Enfin, git-bisect à effectué un checkout automatique sur un autre <commit-id> et attend vos instructions.

Il ne reste qu'a tester le code et à donner comme instruction soit un git bisect good, soit un git bisect bad en fonction du résultat observé. L'opération sera plus ou moins longue en fonction du nombre de commits à tester.

➜  webapp git:(6ae90d246) git bisect good
Bissection : 132 révisions à tester après cette (à peu près 7 étapes)
[49cbe40d5cb63b9f2a036560190983b2848d6df0] Merge branch 'master' into deploy/staging
➜  webapp git:(49cbe40d5) ✗ git bisect good
Bissection : 66 révisions à tester après cette (à peu près 6 étapes)
[dc9c093633ca9af720ae560b01ff455d4bd4fb51] <commit-message>
➜  webapp git:(dc9c09363) ✗ git bisect good
Bissection : 33 révisions à tester après cette (à peu près 5 étapes)
[4f8b4fd5f7ecb71141510823e89f3d941f6d892b] <commit-message>
➜  webapp git:(4f8b4fd5f) git bisect bad
Bissection : 16 révisions à tester après cette (à peu près 4 étapes)
[0e5acfb262de5f692f8383cd51fe5c4bed729b92] <commit-message>
➜  webapp git:(0e5acfb26) git bisect good
Bissection : 7 révisions à tester après cette (à peu près 3 étapes)
[7623848ffee8d72429623e3b5fb8fb1a8040aeed] <commit-message>
➜  webapp git:(7623848ff) ✗ git bisect good
Bissection : 4 révisions à tester après cette (à peu près 2 étapes)
[50f6b9ebf42ff5cda83d33d4489e944829f87c56] <commit-message>
➜  webapp git:(50f6b9ebf) ✗ git bisect good
Bissection : 2 révisions à tester après cette (à peu près 1 étape)
[d763c0336e13cbc91befbe853194dd077775e6cd] <commit-message>
➜  webapp git:(d763c0336) git bisect good
Bissection : 0 révision à tester après cette (à peu près 1 étape)
[c1af98fc24e031d0d87a567caa7615c0c2c3d66c] <commit-message>
➜  webapp git:(c1af98fc2) git bisect bad
Bissection : 0 révision à tester après cette (à peu près 0 étape)
[026f9bf37555815c0efc9dfb16e90473faacf48f] <commit-message>

Une fois la dernière étape passé, git-bisect vous donne l'identité du coupable :

git bisect bad
026f9bf37555815c0efc9dfb16e90473faacf48f is the first bad commit

Pour terminer, nous pouvons revenir à l'état initial du code (HEAD)

git bisect reset