Jérôme Flesch a écrit 390 commentaires

À mon avis, il y a un domaine où FreeBSD reste utile : l'embarqué proprio. La license BSD est beaucoup plus permissive que la GPLv2 et permet donc à ceux qui font du proprio de moins se prendre la tête. Le code de FreeBSD est très clean et se prête très bien au hacking (je n'ai pas eut encore l'occasion de jouer avec les sources de Linux donc je ne peux pas comparer). Ça me semble un choix tout à fait viable pour ça. C'est d'ailleurs ce que fait mon ancien employeur.

<troll> Par contre, effectivement, coté serveur ou desktop, c'est entre inutile et inutilisable … </troll>

Concernant les labels, je n'ai pas trouvé la possibilité de les créer autrement qu'une fois un document scanné ou importé… est-ce voulu ou c'est moi qui ai mal cherché ?

C'est une limitation technique. Les labels sont stockés dans un petit fichier texte 'labels' dans chaque document. Du coup il faut au moins un document ayant le label pour qu'il puisse exister.
C'est une limitation dont il faudra que je me débarrasse en centralisant les labels dans un seul fichier .. plus tard.

Concernant l'import de plusieurs fichiers d'un seul coup, j'aurai trouvé opportun de pouvoir choisir l'import individuel (chaque fichier représentant un document comme c'est le cas actuellement), ou bien un import groupé (tous les fichiers dans un seul document). Qu'en pensez-vous ?

Pourquoi faire 2 options quand une suffit ?

En fait certaines dépendances peuvent être installées automatiquement par le script setup.py, mais pas toutes, d'où le warning.

Ta distribution n'a pas été reconnue par le setup.py, du coup il n'a pas pu te fournir les noms des paquets exacts à installer. Les paquets Debian correspondant à ceux indiqué dans le warning sont les suivants : gir1.2-gladeui-2.0 gir1.2-poppler-0.18 tesseract-ocr tesseract-ocr-fra . Je ne connais pas les noms des paquets pour Elementary OS.

Lorsque je veux scanner en recto verso avec scanadf je lui donne le paramètre --source "Automatic Document Feeder(left aligned,Duplex)" J'ai l'impression qu'il te suffit de rajouter ",Duplex" et hop!

Je pense pouvoir régler ce problème facilement. Par contre la branche 'stable' est maintenant freezé. Ça sera donc pour la 0.2 (branche 'unstable').

Pourrais-tu créer un ticket sur le bug tracker, en anglais, en précisant la marque et le modèle te ton scanner, s'il-te-plaît ? Aussi, la sortie du script list_all.py de pyinsane pourrait aider :

$ git clone https://github.com/jflesch/pyinsane
$ cd pyinsane
# Allumage du scanner
$ ./list_all.py

La détection de l'orientation semble prendre beaucoup trop de temps. (…) Est-ce possible de désactiver cette détection dans les préférences de l'application?

C'est difficile de proposer cette option sans polluer la UI. Toutefois, une possibilité serait que je mette cette option de façon cachée dans le ~/.config/paperwork.conf.

En attendant, je peux te suggérer cette alternative:

• Désactiver l'OCR dans les préférences (c'est planqué en haut de la liste des langues)
• Faire tout tes scans
• Menu Documents -> Avancé -> Refaire l'OCR sur tout les documents

La détection automatique de l'orientation sera désactivée (dépendante de l'OCR). Tu risques donc de devoir l'ajuster manuellement après certains scans.

Est-ce que Paperwork supporte la fonction recto-verso?

Aucun de mes scanners ne supporte cette fonction, donc je vais répondre non. (si quelqu'un a un scanner recto-verso en rab', je suis preneur :D)

Ça serait aussi intéressant de ne pas avoir à lui indiquer le nombre de pages du document, Paperwork devrait scanner tout ce que je luis donne à manger sans poser de questions!

Tu n'es obligé de lui donner le nombre exact de page. Si tu ne veux pas t'embarrasser avec ça, dis lui de scanner 9999999 pages :)

Je pense que le support PDF existe, mais il doit me manquer une dépendance à installer. Une idée?

L'export en PDF utilise Cairo, qui est une dépendance de Gtk, donc tu as déjà les dépendances requises. Cette option n'est toutefois proposée que quand tu fais "exporter le document" et non "exporter la page".

Oui.

Pour info, les PDFs peuvent être importés en bloc dans Paperwork. Il suffit de :

• les mettre à plat dans un dossier
• dans Paperwork : Menu Document -> Importer un ou plusieurs fichier(s)
• sélectionner le dossier

il faut scripter.

Ok, bonne réponse :)
J'ai rajouté le ticket. Je tacherais de voir ce que je peux faire quand j'aurais le temps et la motivation.

Petite question toutefois, pourquoi l'importation de document est elle si longue ? J'imagine qu'il execute un OCR sur chaque document, peut on désactiver cette option ?

Ça dépend de quelle importation on parle:

• Pour les images, l'OCR est passée systématiquement
• Pour les PDF, l'OCR n'est passée que si il ne semble pas contenir de texte. Il est possible de forcer l'OCR en utilisation l'option Fichier->Avancé->Refaire l'OCR sur le document

Il est possible de désactiver l'OCR dans le dialogue de réglages (Fichiers->Préférences). L'option est cachée dans la liste des langues.

sudo pip uninstall paperwork
sudo pip uninstall pyocr
sudo pip uninstall pyinsane

C'est python-pip sur certains systèmes.

PyOCR et Pyinsane sont des librairies que j'ai écrites pour Paperwork, donc il est peu probable qu'elles soient utilisées par autre chose.

Par contre, je ne crois pas que pip sache supprimer les dépendances non-utilisées automatiquement.

De quelle manières les étiquettes (« labels ») sont-elles enregistrées ?

Un bête fichier texte dans chaque document/répertoire.

Ceci dit, ça peut causer potentiellement des problèmes de synchro dans le cas de coupures brutales de Paperwork lors de la modifications des labels. Donc, à terme, ça sera sûrement déplacé dans une bdd sqlite ou au moins un seul fichier central.

Quid de l'index et de l'OCR ?

L'index whoosh est stocké dans ~/.local/share/paperwork. À noter que les documents (~/papers/) sont la référence pour le contenu de l'index. Autrement dit, le contenu de l'index est toujours mis à jour à partir des documents.

Les fichiers contenant le résultat de l'OCR sont stockés dans les répertoires des documents (papers..words).

Une interface en ligne de commande est-elle prévue ? (pour lancer une recherche par exemple)

Je suis assez septique concernant l'utilité d'une telle fonctionnalité : il faut de toute façon consulter les pages avec un outil graphique au final (la sortie de l'OCR est de qualité variable).

J'ai déplacé ce genre d'infos dans le wiki GitHub du projet :
https://github.com/jflesch/paperwork/wiki#for-developers
https://github.com/jflesch/paperwork/wiki/Work-directory-organization

L'article dans Linux Pratique avait été écrit bien avant cette release et .. juste avant que je change le processus d'installation. :/
En tout cas, je remercie quand même son rédacteur pour la pub. D'ailleurs, ça me fait penser qu'il faut encore que j'encadre et que j'accroche l'article sur mon mûr ;)

Ça a été repris par Google ("An OCR Engine that was developed at HP Labs between 1985 and 1995… and now at Google.").
C'est celui que j'utilise personnellement. Il marche bien dans l'ensemble.

Pour l'heure, je déconseille d'utiliser Cuneiform avec Paperwork. J'ai encore des soucis avec.

C'est un peu dommage si tu n'as jamais étudié ces cas de figures en profondeur, ça pénalise fortement.

Oui mais non. Les questions que j'ai eut en Californie étaient à chaque fois des problèmes originaux (ils ont une énorme collection d'exercices en stock). Ils cherchent justement à éviter les cas déjà préalablement étudiés pour voir comment le candidat va s'adapter.

Mouais, quand tu tentent de passer une dizaine d'entretiens tu ne peux pas t'amuser en plus à faire des exercices et lire des bouquins pour chacun

À mon avis, c'est plus une question d'apprendre à créer des algos performants que d'apprendre par cœur les cas courants (bien que les cas courants sont généralement de bonnes bases de réflexion). Si tu le fais pour un entretien, tu l'as fait pour tous. Au final, je pense que c'est loin d'être du temps perdu.

Pourtant pas mal de boîtes te font passer devant un directeur technique qui te font passer des tests ou te posent des questions techniques pour évaluer rapidement ton niveau.

J'ai eut des tests techniques en France, mais leurs niveaux étaient bien peu poussés par rapport à ceux que j'ai eut en Californie. Ça manquait franchement de "challenge".

Les réaction à mes commentaires vont exactement dans le sens de ce que j'affirmais dans la dernière phrase de mon premier commentaire.

Je reprend donc la dernière phrase de ton premier commentaire :

Bref, un développeur, s'il ne se conforme pas à un certains nombre d'usages, même s'il apporte la preuve que ces usages ne sont nullement nécessaires pour faire du développement logiciel de manière efficace, n'a quasiment aucune chance de passer un entretien avec succès.

De mon point de vue, pour l'heure, le seul moment où tu as prouvé que les tests unitaires sont optionnels, c'est quand on développe un logiciel dans son coin, avec aucune intention de laisser quelqu'un d'autre toucher aux sources. Or en entreprise ce cas n'arrive grosso-modo jamais.
Même en mettant ça de coté, un autre problème, c'est que ce n'est même pas ce que tu me sembles dire dans tes commentaires. Ce que tu me sembles dire, c'est qu'ils sont optionnels, point.

Présenté comme ça, avec moi comme interviewer, effectivement, je te confirme que tu n'aurais pas le job.

que les paramètres passés à cette fonction, quelles que soient les circonstances, soient toujours cohérents, sous peine de se retrouver avec un 'segfault'
(…)
Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation (…) soit détectées et signalées.

Je ne vois pas ce que ça change. Que ça segfault ou que ça remonte une exception non-catchée, d'un point de vue fonctionnel, le problème est le même : le programme est buggué. Lever une exception au lieu de segfaulter n'excuse en rien l'absence de tests.

Vu que tu as ton framework maison, tu le connais par coeur. Tu connais ses points forts et ses points faibles. Tu sais de quel façon il est sensé être utilisé et du coup tu l'utilises toujours correctement. Au final, quand je lis ton post, j'ai l'impression que la fiabilité de tes programmes ne tient qu'à ça.

Est-ce que quelqu'un d'autre a déjà utilisé avec autant de succès ton framework ? Est-ce que quelqu'un a déjà fait des modifications importantes dans ton code sans causer de régression ?

Aussi est-ce que tu as déjà développé un programme en équipe ? Je veux dire à plusieurs sur un même programme ou librairie (et je ne parle pas de pair-programming). D'après mon expérience, dans cette situation, comme chacun ne sait jamais précisément ce que l'autre a codé, les tests fonctionnels et unitaires sont le seul moyen efficace d'éviter des régressions.

Les entretiens d'embauche les plus passionnants (et probablement les plus pertinents) que j'ai eut étaient pour des postes en Californie. Ils étaient concentrés sur l'algorithmique.

En gros, ils partent du principes que le langage et l'API, tout le monde peut l'apprendre sur le tas dans un temps raisonnable. Les bonnes pratiques (utilisation correcte d'un outil de gestion de version, l'écriture de tests unitaires, etc) peuvent être forcées par un passage systématique par la code review et donc elles peuvent être apprises sur le tas.
Par contre, la capacité d'analyse et de réflexion, c'est une autre histoire. En l'occurrence, ils cherchaient des gens capables de se sortir de situations complexes avec des algorithmes aussi peu coûteux que possible. Je ne parle pas juste d'écrire une fonction de tri. Je parle d'algorithmes sur des arbres/graphes, d'algorithmes distribués, etc.

Ces exercices d'algorithmique avaient aussi le mérite de tester l'aptitude à comprendre un énoncé (--> specs). Ils mettaient aussi fortement l'accent sur la capacité à communiquer : tout au long de sa réflexion, ils attendent du candidat qu'il explique sa démarche et discute avec l'interviewer.

Ils conseillent de se préparer fortement avant. Avant l'interview, ils suggèrent divers livres et exercices sur le sujet.

Je n'ai jamais eut d'entretien aussi complet et stimulant en France.

Concernant http://marc.info/?l=linux-kernel&m=137390362508794&w=2 , la réponse de Linus Torvalds vaut des points : http://marc.info/?l=linux-kernel&m=137390810310498&w=2

En résumé, je crois qu'à l'heure actuelle, les choix possibles sont les suivants:

1) Un client lourd : peut être simple à installer, peut être libre, et est généralement réactif
2) Un client léger auto-hébergé : presque toujours compliqué à installer, peut être libre, et est généralement peu réactif
3) Un client léger hébergé par une entreprise tierce : aucune installation, jamais libre, peut être réactif, mais (comme mis en évidence par les histoires de PRISM/NSA récemment) pose des problèmes de confidentialité

Personnellement, je ne pense pas qu'il y ait une solution qui résolve tout les problèmes. J'ai opté pour un mix des 3 en fonctions de mes besoins (confidentialité, simplicité, etc).

Chacun stocke chez soi l'entièreté d'un index mondial des pages web, un peu comme chacun stocke chez soi toutes les transactions précédentes pour Bitcoin ? C'est vraiment difficilement jouable sinon impossible.

Les tables de hashs distribuées pourraient, je pense, servir de base pour résoudre ce problème. Après il y aurait divers problèmes annexes à résoudre (spam, corruption, etc) mais je pense qu'ils ne sont pas insolubles.

Ah ben voilà qui explique. Merci pour cet éclaircissement.

pendant que le monde va dans une autre direction.

Cette fin de phrase me fait tiquer.

Tu es sur Linuxfr, un site dédié à un OS au parts de marché sur le desktop minoritaires voir anecdotiques. Pourtant je suppose que tu postes ton commentaire depuis un poste GNU/Linux ? Du coup, je suppose aussi que puisque tu le fais, tu ne regrettes pas ton choix, bien au contraire ? Je suppose aussi que puisque ce choix te plaît, tu le recommandes aux autres dans la mesure du possible ? Pourtant le monde semble aller dans d'autres directions, celles de Windows, Android et iOS.

Au final, ton propos me semble bien étrange.

Je conclurais juste ma remarque en disant que "des milliards de mouches ne peuvent avoir tord, mangeons de la merde !".

"dans le cloud"

Hm, et il se passe quoi si ton cloud se fait démonter par des pirates et que, comme c'est déjà arrivé trop souvent par le passé, le chiffrage de des données se révèle insuffisant voir inexistant ?

Pour ma part, je stocke ça sur mes machines perso. Ça ne veut pas dire que je suis à l'abri d'un piratage, mais ça veut dire que je sais à peu prêt comment la sécurité de mes mots de passe est assurée. Aussi, à mon avis, il y a quand même moins de chances que mes machines perso se fassent démonter par une attaque ciblée qu'un service de cloud (nettement plus rentable pour un pirate).

À mon avis, le 1er xkcd linké tape parfaitement juste, mais le 2ième oublie une chose : il faut réussir à taper "correcthorsebatterystaple" dans un champ texte qui masque la saisie. Je suis à peu prêt sûr que la plupart gens ont déjà du mal à saisir leur mot de passe de 8 caractères sans typo, alors 26 … Peut-être faudrait-il généraliser la saisie de mot de passe avec le dernier caractère visible, comme elle est faite sur les smartphones ?

Sinon, pour répondre à ta question, moi j'utilise pwgen et pwsafe. Ça me permet d'avoir un master password qui protège ma base de données de mots de passe, et un mot de passe unique par site web. Comme ça, en cas de fuite/piratage/whatever, je n'ai jamais plus qu'un mot de passe à changer.
Il me reste toutefois le problème du login sur mes machines. J'ai le même couple login/mot de passe sur toutes mes machines perso. Pour résoudre ce problème, j'avais un ami qui avait joué avec les one-time passwords (il utilisait son téléphone portable pour les générer). Mais personnellement je n'ai pas eut le temps d'essayer.

Essaye d'importer un dossier qui contient tout tes PDFs. Ça devrait déjà marcher. (importer un dossier de PDF est une problématique nettement plus simple qu'un dossier d'images)