Jérôme Flesch a écrit 345 commentaires

Comme quoi, les choses ne changent jamais vraiment (c'est un vieux texte que j'ai en stock qui doit dater de ~2000. Si quelqu'un a la source originale, je suis preneur)

J'oubliais un autre point : niveau ergonomie, les menus sont très peu pratiques. Ils augmentent le nombre de clics requis pour une action, et oblige l'utilisateur à faire preuve de précision à la souris ou à l'écran tactile. Ce n'est donc pas un bon endroit pour mettre les actions les plus courantes d'une application. Du coup, tu ne veux pas rendre les menus rapidement accessibles. Il y a des éléments bien plus importants dans une GUI à rendre accessibles bien avant eux.

La plupart du temps passé sur la machine se fait dans une application

Si tu n'en utilises qu'une, oui. Si tu en utilises plusieurs, non. Personnellement j'ai toujours un paquet d'applications lancées (sur ma tablette aussi bien que mon ordinateur). Ça implique de basculer souvent d'un bureau à autre et/ou d'une application à une autre. Du coup, dans Gnome, je fais très souvent des passages par le menu "Activité".
Ceci dit, ce n'est sûrement pas le cas le plus courant pour Mme Michu.

les menus des applications dans le bas

On parle desquels au juste ? Le lanceur d'applications Android en bas de l'écran ? Les barres d'actions Android ? ou les menus Android (deprecated : remplacé par un bouton en haut à droite de la GUI) ?
Parce-que coté Gnome 3 + app GNU/Linux, il n'y rien en bas de l'écran (enfin hormis la zone de notification dont le design change à chaque nouvelle version de Gnome 3.x). De plus, dans les applications Gnome, les menus classiques sont progressivement remplacés par des "AppMenu". Ces menus sont intégrés à la barre Gnome, du coup ils sont aussi en haut de l'écran.

(Ça va partir en troll mais tant pis …)

Je trouve dommage d'inclure Gnome 3 dans cette liste.
Gnome 3, d'un point vue clavier+souris, est très bien pensé.

Les icônes plus grands sont pertinents aussi bien à la souris que sur un écran tactile.

Ils utilisent aussi abondamment les coins et les bords de l'écran. C'est tout à fait pertinent dans le cadre d'un usage de la souris sur un poste mono-écran. Ce sont les zones les plus faciles à atteindre avec le curseur.
Ceci dit, ça n'a aucune utilité sur un écran tactile. L'utilisation fréquente du bord haut de l'écran sur un écran tactile me semble même être loin d'être optimal : à ma connaissance, lors du design d'une GUI sur écran tactile/mobile, on considère que les mains de l'utilisateur sont en bas de l'écran, pour le tenir. Résultat, accéder au menu "Activité" (action la plus courante dans Gnome 3) implique de déplacer complètement sa main au lieu de juste utiliser son pouce.

Au final, Gnome 3 me semble clairement être une interface plus axée PC que tablette.

le noyau est quasiment le même, et le portable Linux <=> Android est plus que facilité.

Ou pas. La plupart des applications Android sont écrites en Java en se basant sur le framework Android. Ce framework n'est pas disponible sous GNU/Linux.

Il y a un autre problème : même si le framework existait sur les 2 systèmes, une application mobile ne se porterait pas sur un desktop en claquant des doigts. Il y a des différences non-négligeables entre les deux. Essentiellement:

• différences de tailles et de résolutions entre les écrans (d'ailleurs, ils ont déjà le problème entre les téléphone et les tablettes)
• utilisation d'un écran tactile au lieu de clavier+souris

Ces différences impliquent des designs de GUI radicalement différents. Utiliser la même interface graphique sur ces 2 types de système est une très mauvaise idée. Il y a donc forcément un travail de portage à faire.

À 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.