Et si github fermait ?

Que feriez-vous ?

Le titre est provocateur. Pour ceux qui n’utilisent pas github, je me doute que vous ne ferez rien. Quoique…

Comme vous le savez, github est un service de gestion de projet utilisant git. Comme tout service administré par un tiers (qu’il soit libre ou non, ça ne change rien), sa pérennité n’est pas assurée.

Contrairement à beaucoup de services du "cloud", l’utilisation de github n’est pas le mal absolu, car étant basé sur un gestionnaire de version décentralisé, chaque contributeur possède une copie locale avec l’historique du code.
Théoriquement, si github fermait, nous devrions pouvoir tout reconstituer avec ce que nous avons sur nos disques.

Dans la pratique, s’assurer d’avoir des copies à jour de ce qui nous intéresse, ce n’est pas du luxe. Joey Hess, l’un des développeurs dont j’apprécie le travail, a développé github-backup.
Le logiciel est codé en Haskell et publié en GPL. L’utilisation est triviale, il suffit de lire le README.

Le principale avantage de ce logiciel est de récupérer les tickets ainsi que les forks (aspect de récursivité). C’est donc une sauvegarde complète. La limite provient de l’API de github, qui limite les requêtes. Il faut donc lancer parfois plusieurs fois le script, surtout lors de la première copie. Ensuite, naturellement, ça fonctionne en "diff".

Pour ma part, j’ai mis ce code python en trois minutes et lancé en tâche cron sur mon serveur. a, b et c sont bien entendu des dépôts fictifs.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Author: Francois Boulogne
# License: GPLv2+

import os
from subprocess import call
import random

repos = ['a',
        'b',
        'c',
        ]
random.shuffle(repos)

backup_dir = os.path.expanduser('~/github_backup')

soft = 'github-backup'

for repo in repos:
    backup_path = os.path.join(backup_dir, repo)
    os.makedirs(backup_path, exist_ok=True)
    os.chdir(backup_path)
    call([soft, repo])

En quelques mots, le fonctionnement. Je mélange ma liste de dépôts. De cette manière, je ne commence jamais par le même dépôt, et j’évite qu’un dépôt sature le compteur de l’API de github et empêche ainsi la sauvegarde d’autres dépôts. Pour le reste, je crée des répertoires et je me place dedans pour synchroniser. Il faudrait que je maintienne un log pour être propre, avec le sortie de la commande.

On pourrait ensuite mettre en place une interface web là-dessus comme gitweb pour avoir un miroir visible par d’autres.

A titre personnel, je synchronise mon espace, mais aussi les projets que j’apprécie et qui sont hébergés sur github. Ce sont parfois de petits codes qui ne font pas la une de linuxfr, mais j’y accorde beaucoup d’importance.

Pour ce qui est de la question original, j’essaie de me poser systématiquement la question sur ce qui m’environne. Et si ça disparaissait ? Comment serait-je affecté ? Comment puis-je l’anticiper pour que ça se passe au mieux ?

Des logiciels pour être efficace

Depuis que j’utilise des logiciels libres, je me suis tourné vers la programmation mais c’est aussi parce que je voulais faire cette apprentissage que je suis passé à GNU/Linux. De cette expérience, je tire différents savoirs nouveaux et au final, je me demande si je n’ai pas appris d’avantage concernant les éléments périphériques que sur la programmation elle-même… Je fais cette introduction pour dire que l’efficacité sur une machine, telle que je la conçois, je la tire de cette expérience et des logiciels qui y sont liés.

Je vais donc faire une liste des logiciels qui me semblent décupler mon efficacité mais aussi mon plaisir à travailler.

ZSH

L’un de mes premiers apprentissages, lorsque je suis passé à un OS libre, fût d’apprendre à utiliser la console. Comme je pense la majorité des gens, j’ai commencé par Bash. Bash, c’est bien, mais c’est peu palpitant. J’ai lu beaucoup d’avis positifs sur ZSH alors j’ai testé et aujourd’hui, je ne peux plus me passer de

• sa complétion

•  l’usage de jokers récursifs

GNU-Screen/Tmux

Nous voilà doté d’un shell digne de ce nom, passons maintenant à la dimension du dessus, l’organisation du terminal.
Ouvrir des fenêtres à chaque fois que l’on a besoin d’un prompt, c’est rapidement fatiguant. Des multiplexeurs de terminaux comme screen ou Tmux (fonctionnalités très proche, l’un ou l’autre fait l’affaire généralement) nous facilitent la vie. Je le considère pour ma part comme étant un gestionnaire de fenêtre, tout aussi important que d’avoir Gnome ou openbox. Je peux ainsi avoir un équivalent de bureaux virtuels, que je peux nommer pour me repérer. Par exemple, une fenêtre avec le fichier de conf, une avec le code, et une autre pour parcourir les répertoires où sont écrites les données. D’autres arguments dans la suite.
Avec Screen, je n’accorde plus vraiment d’importance à l’émulateur de terminal parce que je n’utilise aucune de ses fonctionnalité, si ce n’est une seule : qu’il puisse apparaître en plein écran et disparaître par l’action d’une touche (console top/down). J’utilise tilda, mais ça pourrait être autre chose.

VIM

Editer des fichiers, en console, c’est pour le moins fréquent. Dès mes premiers pas, j’ai voulu apprendre autre chose que nano. Pour couper court au débat, je n’ai jamais utilisé emacs et avec vim, je suis certain qu’il sera disponible sur 99,99% des machines que je rencontrerai. Il a une large panoplie de greffons, les possibilités sont infinies.
Ca permet de faire de l’adminsys, de la rédaction, du développement…

SSH

SSH est juste un outil incontournable. Bien sûr, ça permet de joindre une machine distante, mais pas que. C’est aussi le moyen d’envoyer des fichiers, d’établir un proxy ou de passer à travers un réseau NATé. C’est rapide et sécurisé.
Lorsqu’on utilise SSH, on apprécie de savoir utiliser Screen ou Tmux.

• si la connexion lâche, screen se détache et la mise à jour critique en cours n’est pas plantée au milieu, et là, on est heureux.

• si on a travaillé sur une machine localement et qu’on souhaite s’y reconnecter par le réseau plus tard, on peut récupérer la session screen restée ouverte. Autrement dit, je retrouve exactement le même environnement qu’en local.

Git

Ca, c’est un gestionnaire de version qu’on ne présente plus. Je gère mes projets avec, mais aussi ma synchronisation de fichiers et un wiki comme ça (j’en ai parlé ici déjà). Je ne connais même pas le 1/100e de ses possibilités et il m’est néanmoins indispensable.

Python

J’ai codé dans un certain nombre de langage. Je ne peux pas dire que je les maîtrise (même python) car je ne suis pas un développeur expert par manque de temps plus que d’envie. Après avoir codé pendant un certain temps en bash mes scripts systèmes, j’ai découvert Python, et aujourd’hui c’est mon couteau suisse :

• scripts systèmes

• code scientifique

• petits utilitaires

La syntaxe est claire, ce qui fait du code maintenable. Les bibliothèques sont très variées ce qui permet de couvrir un grand nombre de besoin. Enfin, c’est suffisamment haut niveau pour écrire rapidement un code fonctionnel et c’est important ; on n’est rarement là pour faire des exercices de style. En clair, investir dans un langage polyvalent comme celui-ci, ça permet de se sortir de problèmes lourds rapidement et sans trop d’effort.

Conclusion

Ces outils, je les utilise tous les jours, sans exception. Il n’y a que pour le courriel et le web où je suis resté sur des outils "populaires" avec Firefox et Thunderbird.

Le dénominateur commun à tous ces outils :

• c’est austère. Oui, mais c’est épuré, et ça a l’avantage que le contenant ne distrait pas du contenu.

• ça demande un apprentissage qui peut être parfois long. En contre-partie, ce sont des outils que l’on verra encore probablement pendant quelques décennies.

 

Mat : supprimer les métadonnées de fichiers

mat est un logiciel libre (GPLv2) utilisable en console et en interface graphique. Il permet de supprimer les métadonnées présents dans des fichiers (images, documents, multimédia). Ces métadonnées peuvent contenir des noms d’auteur, des numéros de série d’appareil ou encore des données de localisation.

Je suis le mainteneur du logiciel pour archlinux. Mat est écrit en python, il utilise la bibliothèque hachoir permettant le lire les informations dans des fichiers binaires (le nombre de format pris en compte est impressionnant).

Dans le cadre de publications de ces documents (comme une galerie photo statique), on peut vouloir éviter de donner ce genre d’information (et en plus, ça fera toujours des photos plus légères !)

Pour voir l’effet sur des photos, vous pouvez utiliser l’outil exiftool. (licence GPL, il fonctionne d’ailleurs sur de nombreux formats dont pdf).

Bon nettoyage !

wiki versionné avec git

Dans la vie numérique, j’aime git et j’aime les wiki que ce soit pour un usage collaboratif ou personnel.

Celles et ceux d’entre vous qui me suivent savent que j’utilise zim afin de conserver mes notes privées ou n’ayant aucun intérêt à être divulguées. Zim se définit comme un wiki de bureau.

Il se trouve que je viens d’avoir un nouveau besoin : répertorier des petits bouts de code présentant des syntaxes ou des usages de bibliothèques que j’ai cherché au moins une fois. Zim ne propose pas de coloration syntaxique pour ça et la demande de colorisation de texte est un bug ouvert (d’après mon souvenir).

Bref, toujours curieux, toujours prêt à tester de nouvelles solutions, je me suis mis à chercher des wikis en ligne avec git comme gestionnaire de version. En effet, je veux retrouver les avantages que j’ai avec Zim à savoir :

•   reposer sur des fichiers textes avec de préférence une syntaxe non ésotérique

•   être accessible hors ligne, ce qui signifie avoir une copie locale complète

Ce dernier point étant important, car si mon serveur tombe ou si je n’ai plus de moyen de me connecter, je veux toujours accéder à mes données.

J’ai trouvé et testé deux solutions. Il en existe peut être d’autres qui m’ont échappé. La première se nomme gitit. C’est codé en haskell, ca ressemble beaucoup à mediawiki. L’installation sur un serveur debian s’est passée sans encombre à l’aide du paquet fourni et de la doc. J’ai été vraiment séduit à l’usage notamment par le support de différents langages de balisage léger, l’export dans N formats (epub, pdf, tex et j’en passe), c’est pandoc qui est derrière, donc du costaud. A noté aussi le support mathml et la possibilité de faire des slides en html5 (j’ai trouvé ça génial).
J’ai été déçu quand je me suis rendu compte que le support coloration syntaxique demandait de recompiler le logiciel (sauf si j’ai raté quelque chose, le paquet debian ne semble pas avoir ce support). ce n’est pas insurmontable, mais sur le coup, je n’ai pas eu envie.

Retour moteur de recherche et je suis tombé sur ikiwiki. Après un coup de ménage sur le serveur, j’installe donc ce palindrome. Là aussi, paquet + doc rendent ça très facile. Au passage, heureusement que les lib perl sont empaquetées, il y en a une belle quantité.
Je n’ai pas pris l’installation manuelle, la version "automatique" + ajustement ultérieur m’a semblé suffisant. L’interface par défaut est moins sexy que gitit, mais on peut trouver quelques css. Il existe aussi une foule de greffons dont un qui gère des refs via bibtex. Pas encore testé, mais ça m’intéresse grandement. Coté fonctionnalité, j’ai presque l’impression que c’est le négatif que gitit. J’aimerai voir tous les avantages que j’ai cité dans gitit chez ikiwiki. Notamment, pas de mathml mais un greffon qui fait du dvipng
Ikiwiki fait un build des pages grâce à un hook git, donc dès que vous poussez votre version, ça reconstruit un html statique à partir du (des) fichier(s) modifié(s) servi par votre serveur web. Etant donné les langages et le plus grand nombre de greffons, ikiwiki remporte mon intérêt. En effet, je peux coder un peu en perl et j’ai vu qu’il est possible de coder des greffons en python.

Une remarque importante est que ikiwiki peut être utilisé comme un blog statique. J’ai remarqué qu’un certain nombre d’auteurs retournait sur ce genre de solution après une expérience de CMS comme wordpress. Il est vrai que la légèreté (important pour les lecteurs aux faibles débits et les auto-hébergés) et l’atout rédactionnel déporté sont intéressants. L’intérêt que je verrai à ikiwiki pour cet usage serait les commentaires gérés sans service externe (cf ce blog à titre d’exemple).

Même si je n’ai pas encore rendu Zim, je me rend compte que ikiwiki serait plus adapté à mes usages. Zim m’aide beaucoup en tant que wiki, mais peu en terme d’utilisation et de fonctionnalité. Je n’aime pas l’éditeur d’équation, l’import d’image ou l’absence de support syntaxique.

Si certain(e)s ont un expérience dans ce domaine, je suis preneur ; autrement je vous laisse décrouvrir

Détection de cercles par une transformation de Hough dans scikit-image

Au détour de quelques questions que je me posais que la détection de forme, j’ai découvert les transformations de Hough. Ces transformations permettent, en jouant avec la géométrie de détecter par exemple des droites ou des cercles dans des images. Le principe est basé sur un accumulateur construit dans un espace réciproque à l’image dont les maxima marquent les formes probablement existantes dans l’image binarisée.

En quelques mots, pour des droites, l’idée est de balayer toutes les pentes et toutes ordonnées à l’origine et de compter le nombre de pixels matchant la droite de test avec l’image.

Scikit-image est une bibliothèque sous licence libre pour Python spécialisée dans la traitement d’image trouvant son socle technologique dans numpy et scipy. La transformation de Hough pour les lignes existait déjà, mais pas pour les cercles.

J’ai donc implémenté cette détection dont l’image ci-dessous illustre le résultat sur une photographie d’une série de pièces de monnaie. Dans l’exemple, on fait une tentative en précisant 2 rayons et en récupérant deux possibilités par rayon. Un des intérêts que je vois dans cette méthode est l’estimation de la position du centre de cercle qui peuvent être importants pour d’autres traitements postérieurs.

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches

from skimage import data, filter
from skimage.transform import hough_circle
from skimage.feature import peak_local_max

# Load picture and detect edges
image = data.coins()[0:95, 70:370]
edges = filter.canny(filter.sobel(image), sigma=2.8)


fig, ax = plt.subplots(ncols=1, nrows=1, figsize=(6, 6))
ax.imshow(image, cmap=plt.cm.gray)

# Detect two radii
radii = np.array([21, 25])
hough_res = hough_circle(edges, radii)

for radius, h in zip(radii, hough_res):
    # For each radius, keep two circles
    maxima = peak_local_max(h, num_peaks=2)
    for maximum in maxima:
        center_x, center_y = maximum - radii.max()
        circ = mpatches.Circle((center_y, center_x), radius,
                               fill=False, edgecolor='red', linewidth=2)
        ax.add_patch(circ)

plt.show()

Petite remarque. J’ai appris aussi à cet occasion l’algorithme permettant de dessiner des cercles ou des lignes (Bresenham) et que celui-ci présentait le défaut ne pouvoir faire des cercles concentriques formant un disque plein. L’algorithme d’Andres est alors la solution pour ça (il supporte mieux la rotation aussi). Le premier était implémenté dans Scikit, pas le second, ce que j’ai corrigé. A noté que j’utilise Bresenham pour Hough car il me semble plus approprié (moins de redondances locales)

Test continu de la compilation d’un document *tex avec python

Rédigeant mon manuscrit, je ne me voyais compiler toutes les cinq minutes mon documents pour voir si je n’ai pas fait une erreur. En effet, détecter une erreur rapidement permet de la corriger facilement surtout que les compilateurs latex et consorts donnent parfois des erreurs peu facile à décrypter.

L’idée est donc de compiler le document automatiquement à chaque dois que je l’enregistre. Une bulle (lib notify) est affichée de manière à prévenir du succès ou de l’échec. Faire ça en python, c’est très simple avec watchdog et pynotify. Quelqu’un avant moi a déjà pensé à faire quelque chose comme ça.

Dans mon cas, je n’utilise pas de makefile. Je fais donc mon appel xelatex directement. J’utilise subprocess.check_call() afin d’avoir le code de retour de xelatex.

Avec pynotify, j’ai une exception gobject.GError qui est parfois levée. Je n’ai pas d’idée de la raison. Si quelqu’un a une idée… sinon, je chercherai plus tard (ça reste Quick & Dirty).

import subprocess
import os
import time

import pynotify
from gobject import GError

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler


class ChangeHandler(FileSystemEventHandler):
    """React to modified .tex files."""
    def on_any_event(self, event):
        """If a file or folder is changed."""
        if event.is_directory:
            return
        if os.path.splitext(event.src_path)[-1].lower() == ".tex":
            pynotify.init("Mon appli python")
            try:
                subprocess.check_call(['xelatex', '-halt-on-error' ,'thesis.tex'])
            except subprocess.CalledProcessError:
                message = pynotify.Notification("Build failed.")
            else:
                message = pynotify.Notification("Build done.")
            try:
                message.show()
            except GError:
                pynotify.uninit()  # methode brute !
                print('Gerror')
                pynotify.init("Mon appli python")



def main():
    handler = ChangeHandler()
    observer = Observer()
    observer.schedule(handler, '.')
    observer.start()
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()


if __name__ == '__main__':
    main()

Script python pour retailler des images et plus si affinité

Prenons ce cas d’école où on est en possession d’une large quantité de photographies que l’on doit traiter. Dans mon cas, ces photos sont prises avec un Nikon D300 dans un format tif. Je prends une image par minutes sur 7 à 48 heures. Le script présenté ici ne fait qu’un découpage des photos sur une zone d’intérêt et les enregistre sous un format png. D’autres actions peuvent être ensuite enchainées, selon les besoins. Le code est donné en fin d’article, son contenu me semblait suffisamment intéressant pour en faire une billet.

Le "crop" se fait avec la bibliothèque PIL. Puisqu’elle n’est disponible qu’en python2, on écrira le script dans cette version. Cette partie est réalisée par la fonction crop_pic()

L’étape suivante est de récupérer la liste des images à traiter et le répertoire de destination. J’utilise la bibliothèque argparse même si quelque chose de plus léger comme cliz pouvait suffire. Ainsi, je spécifie un répertoire source et un répertoire de destination.

Dans le répertoire source, je récupère à l’aide de glob la liste des fichiers. On pourrait être plus restrictifs en imposant une extension tif. Le nommage est plus ou moins complexe, mais il comporte au moins un numéro. La liste des fichiers est donc triée avec sorted (Vous allez comprendre dans un instant pourquoi). Il faut faire attention, car si les fichiers sources comportent des numéros comme 1, 2, … 11, 12, …, un tri sur cette liste mettra 11 avant 2. On spécifie donc une clé pour avoir un tri naturel. J’ai dû récupérer ce bout de code un jour sur stack overflow.

Une fois ceci fait, il faut générer de nouveaux noms, le nombre se référant au temps. J’ai choisi d’écrire un générateur dont je peux spécifier la première valeur. Mes numéros sont sous la forme 00001 pour avoir un tri naturel avec un ls par ex. On pourrait spécifier un pas dans le cas où la période d’acquisition aurait été différente de 1 minute pour avoir ainsi un indicateur temporelle correct dans le nom.

On passe enfin à l’action en lançant les crop sur chaque image. Le processus étant un peu lent avec une alternance de charge processeur et d’IO, il est plus efficace de traiter des images en parallèle. Pour cela, j’ai choisi d’utiliser une pool de tâches. On la remplit, et une fois vidé, on admire nos belles images traitées.

#!/usr/bin/env python2
# -*- coding: utf-8 -*-


from PIL import Image

import glob
import os
from multiprocessing import Pool

import re
import argparse


def get_name(path, start=1):
    """
    Generator for pictures
    :param path: dir path for the picture  
    :param start: first number
    :returns: filename
    """
    i = start
    while True:
        pngfile = os.path.join(path, str(i).zfill(5) + '.png')
        yield(pngfile)
        i += 1

def crop_pic(filename, output, box):
    """
    :param filename: name of the picture   
    :param output: destination file
    :param box: crop box (tuple)  (x_1,y_1,x_2,y_2)
    """
    print(" Processing... %s \n\t to... %s" % (filename, output))
    basename, ext = os.path.splitext(filename)
    name, ext = os.path.splitext(filename) 
    im = Image.open(filename)
    region = im.crop(box)
    region.save(output)


def tryint(s):
    try:
        return int(s)
    except:
        return s

def alphanum_key(s):
    """
    Turn a string into a list of string and number chunks.
    >>> alphanum_key("z23a")
    ['z', 23, 'a']
    """
    return [ tryint(c) for c in re.split('([0-9]+)', s) ]


if __name__ == '__main__':

    box = (1130,220,3600,2450)
    start = 1

    #Arg parsing
    parser = argparse.ArgumentParser(description='Crop!', epilog='')
    parser.add_argument('-s', help='Source dir', metavar='SOURCE', required=True)
    parser.add_argument('-d', help='Dest dir', metavar='DEST', required=True)
    args = parser.parse_args()

    #Dirs
    cwd = os.getcwd()
    source_dir = os.path.join(cwd, args.s)
    dest_dir = os.path.join(cwd, args.d)
    os.makedirs(dest_dir)

    #List of pictures
    pic_list = glob.glob(source_dir + '/*')
    pic_list = sorted(pic_list, key=alphanum_key)

    #Create a pool
    pool = Pool(processes=4)
    generator = get_name(dest_dir, start)
    for im in pic_list:
        output = generator.next()
        pool.apply_async(crop_pic, args = (im, output, box, ))

    pool.close()
    pool.join()

 

Format d’écriture pour petites quantités de données

Il est fréquent d’avoir à manipuler des données qui sont trop nombreuses pour être traitées à la calculatrice, et pas assez pour mettre en place des fichiers binaires complexes. A vrai dire, c’est 99% des cas chez moi. Le big data est à la mode, les petites quantités sont mon quotidien. Je n’ai rien contre netcdf, mais c’est franchement sur dimensionné, sans compter que les formats binaires, ce n’est jamais pratique pour les petits usages.

Il y a les gens qui utilisent des tableurs, et il y a les autres comme moi qui n’aiment pas ce genre d’outil trop étriqué. Alors, les premières fois (il y a toujours une première fois), j’ai écris mes données dans un fichier texte, j’ai écris un parseur qui lit ligne par ligne, et je stockais ça dans un tableau. Je travaillais avec les données pour ensuite écrire les résultats dans stdout ou un fichier. C’est bien, mais trop long et trop fastidieux.

Ensuite, j’ai découvert les fichiers .ini. C’est normalement destiné à la configuration, mais ça peut faire son job. Pour ceux qui voudraient essayer : non, je n’écrierai pas de l’xml à la main.

Entre temps, j’ai découvert YAML pour yet another markup language. C’est lisible par tout un tas de langage dont python, ce qui est bien quand on veut faire du calcul scientifique rapide et efficace. Il y a sans doute tout un tas d’autres usages qui ne sont pas les miens.

Voici un fichier avec des données :

lame1:
    epaisseur: 3
    largeur: 10
    longueur: 100
    masse: 50
lame2:
    epaisseur: 4
    largeur: 20
    longueur: 300
    masse: 200

Le problème est simple : j’ai des lames au labo, je dois les caractériser. J’ai pris les dimensions et les poids. Je commence par deux, mais je serai amené à en ajouter d’autre au fur et à mesure de mes pérégrinations. Disons que je veux connaitre la densité.

import yaml
with open('data.ml', 'r') as data:
    doc =  yaml.load(data)
    for lame in doc:
        masse = (doc[lame]['masse'])
        epaisseur = (doc[lame]['epaisseur'])
        largeur = (doc[lame]['largeur'])
        longueur = (doc[lame]['longueur'])

        densite = masse/(epaisseur*largeur*longueur)

        print("Densité de la {0}: {1}".format(lame, densite))
 

Je vois pas mal d’avantage. Mon fichier est bien structuré, donc lisible. C’est du texte, donc versionable, facilement éditable, interopérable, durable, mangeable…

L’exemple est ici simplet, le format yaml et son utilisation avec python sont illustrés ici.

Export Mediawiki pour Etherpad-lite

Au sein de l’April, nous utilisons deux outils complémentaires pour rédiger des notes : mediawiki et etherpad-lite que beaucoup auto-hébergent (lqdn, framapad ou le pad de l’april). Au cours d’un échange de courriel avec Marianne, j’ai appris qu’elle avait dû utiliser l’export DokuWiki de framapad pour déposer son texte sur le wiki de l’April. On a été vite convaincu de l’intérêt d’avoir un export pour mediawiki, surtout que c’est un moteur de wiki plutôt répandu.

Un rapide coup d’oeil au code m’a indiqué que c’était du javascript — que je ne connais pas — mais que ca semblait simple d’adapter l’export dokuwiki en export mediawiki. En deux bonnes heures, j’ai fait tourner le code en local et j’ai réussi à la modifier afin d’avoir un premier export. Quelques peau-finages plus tard, j’ai fait un pull-request dont l’enthousiasme du premier commentaire fait extrêmement plaisir [Edit : le pull request a été repris ici]

Il manque un coup de graphisme pour y mettre la bonne icone (j’ai utilisé pour le moment celle de dokuwiki, je suis mauvais dans ce genre de gimperie)

Il y a donc de bonnes chances de voir un export mediawiki dans le futur

Gérer sa bibliographie : base de donnée et prise de notes

Dans la série des choses auxquelles on pense lors de sa thèse, il y a la gestion de la bibliographie. Pour donner une idée, j’ai accumulé plus de 350 fichiers en deux ans. On sent bien qu’une gestion correcte est nécessaire et qu’il vaut mieux s’y prendre au jour le jour plutôt qu’à la fin

Jabref

LaTeX étant la référence dans le domaine scientifique, avoir une base de donnée sous format bibtex est un choix évident. Format ouvert, lisible par l’humain, versatile… je n’y vois pas d’inconvénients. Gérer une telle base à la main serait acrobatique, c’est pour cela que des outils existent. J’ai pour ma part investi dans jabref. Les revues fournissent souvent les références sous format bibtex, ris, endnote. Jabref les comprend et les injecte dans un unique bibtex avec un beau formatage. On peut lier des URLs, des fichiers, un moteur de recherche est intégré : on accède rapidement à une ressource qu’on a en tête.

Recoll

Néanmoins, entrer des mots clefs pour chaque entrée, avec une taxonomie  intelligente est fastidieux et peut nécessiter parfois des refactoring. On m’a conseillé le logiciel recoll qui permet de faire de la recherche plein texte. Ca aurait été un comble que d’avoir à faire le travail du bibliothécaire du 20ème siècle.

ZimBibliographer

Ceux qui suivent ce blog savent que j’utilise beaucoup Zim, un wiki de bureau qui me sert à prendre des notes. J’ai notamment déjà parlé ici d’un outil que j’ai écrit (ZimArchivist). Récemment, je me suis fait la remarque que je ne prenais pas suffisamment de notes sur la biblio que je pouvais lire alors que j’ai cette bonne habitude pour tout ce qui touche l’informatique. Rapide analyse et le résultat fût que je n’avais pas de moyen de lier facilement le document (des PDFà 99%) à mes notes et je n’aime pas les informations éclatées. J’écris donc plutôt sur des versions papiers, pas mal ; mais je n’ai pas de moyen de mettre en relation les divers documents (autrement qu’en les étalant sur mon bureau).

La solution a été de passer une partie du code de ZimArchivist dans une bibliothèque python pour la réutiliser dans un nouveau projet ZimBibliographer. J’ai bien conscience qu’il faudrait intégrer tout ça en plugin zim, mais je me suis rendu compte trop tard que Zim est encore en python 2 (donc ZimArchivist non compatible) et j’ai eu un code utilisable plus rapidement, ce qui était le but premier : satisfaire le besoin. L’idée est d’écrire des cite{Toto1942} et qu’ils soient convertis en un lien vers le fichier qui va bien. L’étiquette du lien contient auteur, journal et année, ce qui me permet de savoir de qui on parle dans les notes. Les informations proviennent du parsing du fichier bibtex. J’ai assez longtemps chercher à parser performant. Le meilleur que j’ai trouvé est celui d’un projet de l’OKF. Si vous aussi vous chercher à parser un bibtex en python, voilà ce qu’il vous faut !

Au passage, ZimArchivist s’améliore petit à petit, les curieux peuvent aller voir.

N’hésitez pas à partager vos bonnes pratiques pour la gestion de votre biblio en commentaire.