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 ;)
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.
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.
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 !".
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)
Il est possible d'importer des images. Il n'y a toutefois pas de recadrage automatique. Paperwork permet juste une édition minimaliste des pages/images : rognage et rotation de 90/180/270 degrés.
Maintenant, je ne suis pas sûr qu'utiliser son téléphone pour scanner des documents soit une bonne idée. J'ai déjà entendu et lu plusieurs personnes se plaindre du temps que ça prend pour scanner les piles de papiers qu'ils avaient accumulées jusque là avec un scanner. Je ne peux qu'imaginer le temps que ça prendrait avec un téléphone (temps de transfert sur l'ordinateur et import dans Paperwork, photos partiellement floues à refaire, etc).
Tu te représentes la quantité de travail? Alors qu'avec un poil de volonté du développeur on pourrait avoir un paquet par distrib à faire
Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique. À ma connaissance, c'est toujours un package par librairie ou programme. Il me semble clair que pour eux, il est hors de question de faire un paquet contenant un programme et 10 librairies. Sinon l'intérêt des dépendances se perd, et on en arrive à ce que font les installateurs Windows ou PC-BSD.
Au final, que je package ou pas Paperwork avec ses dépendances n'aidera en rien les packageurs des distributions.
Portabilité ? : Le logiciel est en Python, donc il pourrait potentiellement viser Windows et/ou Mac OS
Nop. Mon poil dans la main est trop gros pour supporter des OS propriétaires. Si quelqu'un veut le faire, qu'il se fasse plaisir, mais je ne le ferais pas. Par contre, je veux bien faire du support pour cette personne si elle en a besoin et je ne suis pas contre l'inclusion de patchs ayant pour but la portabilité.
Gestion du projet : La gestion des dépendances (Quelles libs on utilise? Quelles libs on peut virer? Quelles versions?), c'est le développeur qui doit les faire, j'espère qu'au moins la dessus on est d'accord. Seulement si le développeur ne tient compte que du code et pas du packaging, le logiciel peut vite devenir une horreur à packager. Par exemple si le dev choisi d'intégrer une lib originale que personne n'utilise à chaque release.
Sur ce point on est d'accord. C'est pour ça que j'essaye de maintenir une liste des dépendances aussi complète que possible. C'est aussi pour ça que j'essaye d'éviter les dépendances ésotériques et que je favorise autant que possible les librairies déjà disponibles dans Debian. (je n'aime pas plus qu'un autre avoir 25 librairies installées en dehors de mon gestionnaire de paquets)
Je n'ai jamais dit que je comptais en faire un logiciel dédié Debian. J'ai juste dit que Debian est la distribution que j'utilise et sur laquelle je le développe, et que c'est donc la seule dans laquelle ça m'importe vraiment de voir Paperwork packagé. Si d'autres le packagent aussi, tant mieux, sinon tant pis.
Pour info, je teste aussi de temps en temps Paperwork sur Fedora et Ubuntu.
Si tu veux des testeurs, il faut qu'ils puissent installer en dehors des repos officiels
Le fait est qu'un certain nombre de personnes ont déjà réussi à l'installer. Essentiellement des utilisateurs de Debian, Ubuntu et Fedora je présume. ArchLinux est plus problématique vu que la version par défaut de Python sur cette distribution est Python 3. C'est là encore un problème qui se résoudra de lui-même quand je ferais le passage à Python 3.
Le mieux que je puisse faire est de documenter la liste des dépendances, et pour les distributions les plus courantes, indiquer comment les installer. Je n'ai définitivement pas l'intention de me prendre la tête à faire un meta-package volumineux qui ne fonctionnera que sur une distribution sur deux. Je n'ai pas non plus l'intention de faire moi-même des paquets pour chaque distribution/architecture.
Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.
tu remarques que ce sont les premiers rapports de "bugs" de ton logiciel
Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.
Certaines des dépendances sont abandonnées en upstream
La seule que je connaisse qui semble abandonnée est PIL (corrigez-moi si je me trompe). J'ai l'intention de la remplacer par Pillow.
Si tu en as vu d'autres, ça m’intéresse.
« Je n'embarque pas les dépendances, car je ne veux pas ré-inventé la roue ».
Ta formulation est mauvaise,
En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.
Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.
Je comprends qu'actuellement toutes ces dépendances sont problématiques. Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.
Je suis toujours ouvert à la discussion. J'invite ceux qui ont des idées à venir en discuter sur la mailing-list (en anglais, please). Pour l'IHM, l'idéal serait d'en discuter mock-ups à l'appui. Glade, bien qu'un peu buggué, peut être assez pratique pour ça.
Pour les dépendances Python, disons juste que je préfère en avoir beaucoup plutôt que de réinventer la roue. Après, à terme, ça sera aux gestionnaires de paquets de résoudre ce problème.
Pour les 13 dépendances, c'est juste une question pour moi de ne pas réinventer la roue. Quant à la pérennisation de la base de données, pour l'heure, la question ne se pose pas : l'organisation du répertoire de travail est très simple et fait usage de bêtes fichiers JPG et hOCR (text/html) (cf la doc de hacking). C'est ce répertoire qui fait référence, et l'index est automatiquement mis à jour en conséquence au démarrage de Paperwork.
Pour les noms: L'objectif est "scan&forget", pas "scan&name&forget" :). Déjà devoir labeliser les documents est une étape de trop à mon goût (mais j'ai quelques idées pour arranger ça). Je ne souhaite pas encourager les utilisateurs à nommer systématiquement leurs documents. D'après mon expérience, les miniatures suffisent à reconnaitre un document bien plus vite qu'un nom.
Il est toutefois possible, au besoin, d'ajouter des mots clefs sur le document, mais pas de le nommer. Si tu y tiens vraiment, tu peux renommer le dossier contenant le document différemment de la nomenclature normalement adoptée. Dans ce cas, Paperwork utilisera le nom du dossier tel quel sans essayer de le parser. Ça va faire des misères pour ordonner ensuite les documents mais bon.
Pour les exports PDF, le texte n'est pas encore inclus dans le PDF généré. À noter aussi que lorsqu'on exporte en PDF un document qui était un PDF à l'origine, Paperwork se contente de faire une copie. (c'est vrai que je n'ai pas vraiment pensé au cas du PDF qui a l'origine ne contient pas de texte mais que une image)
Actuellement il est déjà possible d'importer des images et des PDFs dans Paperwork.
Par contre l'import d'un dossier d'images complet est plus compliqué, vu que chaque personne aura sa propre façon d'organiser le-dit dossier à importer. J'ai quelques idées sur comment importer ce qui sera vraisemblablement les organisations les plus courantes, mais ce n'est pas prévu pour la 0.1.
En attendant, pour ceux qui savent scripter, c'est un problème qui peut se résoudre à grand coup de scripts shell. J'ai inclus les informations nécessaire dans la doc de hacking pour ceux que ça intéresse. En fait il suffit d'arranger et nommer les fichiers dans le répertoire de travail de la même façon que Paperwork.
Je ne les sélectionne pas :)
En fait je passe le texte tel-quel à Whoosh. C'est lui qui se charge de l'indexation, de la recherche et des suggestions.
Pour Scribo, je ne connaissais pas. Je vais voir pour l'intégrer à PyOCR. Pour ce qui est de l'interaction, actuellement, c'est fait de façon relativement crade: Paperwork (via PyOCR) exécute tout simplement Tesseract comme commande shell. Je suppose que Scribo peut aussi être lancé depuis le shell, donc je ne devrais pas avoir de soucis pour l'intégrer.
En fait, Tesseract fournit aussi une librairie C++, mais du coup ce n'est pas simple à binder sur du Python (du moins sans rajouter une autre dépendance), et je n'ai trouvé aucune documentation expliquant comment l'utiliser. Donc j'ai juste laissé tombé (pour le moment)
[^] # Re: Très bien
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Sortie de Paperwork 0.1. Évalué à 2.
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 ;)
[^] # Re: ocr
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Sortie de Paperwork 0.1. Évalué à 7.
Ç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.
[^] # Re: Algorithmique
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1.
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.
À 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.
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".
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 4.
Je reprend donc la dernière phrase de ton premier commentaire :
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.
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 5.
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.
# Algorithmique
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 10. Dernière modification le 19 juillet 2013 à 17:25.
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.
# Mouarf
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Linus is evil…. Évalué à 10.
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
# Un choix à faire
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 1. Dernière modification le 18 juillet 2013 à 11:28.
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).
[^] # Re: Concentration des commentaires sur linuxfr
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 1.
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.
[^] # Re: Traduction de la traduction
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 2.
Ah ben voilà qui explique. Merci pour cet éclaircissement.
[^] # Re: Traduction de la traduction
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Qui a vraiment besoin d'héberger soi-même ses données ?. Évalué à 6.
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 !".
[^] # Re: KeePassX
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Sécurité des mots de passe. Évalué à 2. Dernière modification le 10 mai 2013 à 15:43.
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).
# Pas entièrement d'accord avec xkcd
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Sécurité des mots de passe. Évalué à 6.
À 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.
[^] # Re: PKGBUILD pour Arch Linux dispo dans AUR
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 1.
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)
[^] # Re: purge
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2.
Pour la catégorie de document, un label devrait faire l'affaire, non ?
[^] # Re: Import de photos
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 4.
Il est possible d'importer des images. Il n'y a toutefois pas de recadrage automatique. Paperwork permet juste une édition minimaliste des pages/images : rognage et rotation de 90/180/270 degrés.
Maintenant, je ne suis pas sûr qu'utiliser son téléphone pour scanner des documents soit une bonne idée. J'ai déjà entendu et lu plusieurs personnes se plaindre du temps que ça prend pour scanner les piles de papiers qu'ils avaient accumulées jusque là avec un scanner. Je ne peux qu'imaginer le temps que ça prendrait avec un téléphone (temps de transfert sur l'ordinateur et import dans Paperwork, photos partiellement floues à refaire, etc).
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2. Dernière modification le 06 mai 2013 à 13:56.
Je ne connais pas les politiques exactes de chaque distribution, mais je suis presque sûr que pour une distribution comme Debian, c'est une violation de leur politique. À ma connaissance, c'est toujours un package par librairie ou programme. Il me semble clair que pour eux, il est hors de question de faire un paquet contenant un programme et 10 librairies. Sinon l'intérêt des dépendances se perd, et on en arrive à ce que font les installateurs Windows ou PC-BSD.
Au final, que je package ou pas Paperwork avec ses dépendances n'aidera en rien les packageurs des distributions.
Nop. Mon poil dans la main est trop gros pour supporter des OS propriétaires. Si quelqu'un veut le faire, qu'il se fasse plaisir, mais je ne le ferais pas. Par contre, je veux bien faire du support pour cette personne si elle en a besoin et je ne suis pas contre l'inclusion de patchs ayant pour but la portabilité.
Sur ce point on est d'accord. C'est pour ça que j'essaye de maintenir une liste des dépendances aussi complète que possible. C'est aussi pour ça que j'essaye d'éviter les dépendances ésotériques et que je favorise autant que possible les librairies déjà disponibles dans Debian. (je n'aime pas plus qu'un autre avoir 25 librairies installées en dehors de mon gestionnaire de paquets)
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 5.
Je n'ai jamais dit que je comptais en faire un logiciel dédié Debian. J'ai juste dit que Debian est la distribution que j'utilise et sur laquelle je le développe, et que c'est donc la seule dans laquelle ça m'importe vraiment de voir Paperwork packagé. Si d'autres le packagent aussi, tant mieux, sinon tant pis.
Pour info, je teste aussi de temps en temps Paperwork sur Fedora et Ubuntu.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 2.
Le fait est qu'un certain nombre de personnes ont déjà réussi à l'installer. Essentiellement des utilisateurs de Debian, Ubuntu et Fedora je présume. ArchLinux est plus problématique vu que la version par défaut de Python sur cette distribution est Python 3. C'est là encore un problème qui se résoudra de lui-même quand je ferais le passage à Python 3.
Le mieux que je puisse faire est de documenter la liste des dépendances, et pour les distributions les plus courantes, indiquer comment les installer. Je n'ai définitivement pas l'intention de me prendre la tête à faire un meta-package volumineux qui ne fonctionnera que sur une distribution sur deux. Je n'ai pas non plus l'intention de faire moi-même des paquets pour chaque distribution/architecture.
Par contre, une fois la 1ère release faite, j'ai l'intention d'aller discuter avec les mainteneurs Debian, pour voir si l'un d'entre eux serait assez charitable pour packager Paperwork et quelques-unes de ses dépendances. (pourquoi Debian ? Parce-que c'est la distribution que j'utilise). Si l'un d'entre eux le fait, tant mieux, sinon tant pis.
Euh non. Les 1ers rapports de bug sur Paperwork sont bien plus vieux et n'ont rien à voir.
[^] # Re: Dépendances rédhibitoire
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 3.
La seule que je connaisse qui semble abandonnée est PIL (corrigez-moi si je me trompe). J'ai l'intention de la remplacer par Pillow.
Si tu en as vu d'autres, ça m’intéresse.
En même temps, je n'ai jamais formulé ça de cette façon. Ce que je disais était "si j'ai beaucoup de dépendances, c'est parce-que je ne veux pas réinventer la roue". La question de les embarquer / packager avec Paperwork ne m'a jamais été posée jusque là.
Quoiqu'il en soit, je continue à penser que les dépendances sont un problème qui se résoudra tout seul grâce aux gestionnaires de paquets. Si les packageurs font leur travail, un simple "apt-get install paperwork" (par exemple) suffira à l'installer.
Je comprends qu'actuellement toutes ces dépendances sont problématiques. Mais dans l'ordre des choses, le packaging et la distribution de Paperwork ne sont pas de mon ressort.
[^] # Re: Forces et Faiblesses
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 4. Dernière modification le 06 mai 2013 à 10:34.
Je suis toujours ouvert à la discussion. J'invite ceux qui ont des idées à venir en discuter sur la mailing-list (en anglais, please). Pour l'IHM, l'idéal serait d'en discuter mock-ups à l'appui. Glade, bien qu'un peu buggué, peut être assez pratique pour ça.
Pour les dépendances Python, disons juste que je préfère en avoir beaucoup plutôt que de réinventer la roue. Après, à terme, ça sera aux gestionnaires de paquets de résoudre ce problème.
[^] # Re: petits retours rapides
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Paperwork : besoin de testeurs. Évalué à 5.
Pour les 13 dépendances, c'est juste une question pour moi de ne pas réinventer la roue. Quant à la pérennisation de la base de données, pour l'heure, la question ne se pose pas : l'organisation du répertoire de travail est très simple et fait usage de bêtes fichiers JPG et hOCR (text/html) (cf la doc de hacking). C'est ce répertoire qui fait référence, et l'index est automatiquement mis à jour en conséquence au démarrage de Paperwork.
Pour les noms: L'objectif est "scan&forget", pas "scan&name&forget" :). Déjà devoir labeliser les documents est une étape de trop à mon goût (mais j'ai quelques idées pour arranger ça). Je ne souhaite pas encourager les utilisateurs à nommer systématiquement leurs documents. D'après mon expérience, les miniatures suffisent à reconnaitre un document bien plus vite qu'un nom.
Il est toutefois possible, au besoin, d'ajouter des mots clefs sur le document, mais pas de le nommer. Si tu y tiens vraiment, tu peux renommer le dossier contenant le document différemment de la nomenclature normalement adoptée. Dans ce cas, Paperwork utilisera le nom du dossier tel quel sans essayer de le parser. Ça va faire des misères pour ordonner ensuite les documents mais bon.
Pour les exports PDF, le texte n'est pas encore inclus dans le PDF généré. À noter aussi que lorsqu'on exporte en PDF un document qui était un PDF à l'origine, Paperwork se contente de faire une copie. (c'est vrai que je n'ai pas vraiment pensé au cas du PDF qui a l'origine ne contient pas de texte mais que une image)
[^] # Re: Et sans scan connecté ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Tout à fait :)
[^] # Re: Et sans scan connecté ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Actuellement il est déjà possible d'importer des images et des PDFs dans Paperwork.
Par contre l'import d'un dossier d'images complet est plus compliqué, vu que chaque personne aura sa propre façon d'organiser le-dit dossier à importer. J'ai quelques idées sur comment importer ce qui sera vraisemblablement les organisations les plus courantes, mais ce n'est pas prévu pour la 0.1.
En attendant, pour ceux qui savent scripter, c'est un problème qui peut se résoudre à grand coup de scripts shell. J'ai inclus les informations nécessaire dans la doc de hacking pour ceux que ça intéresse. En fait il suffit d'arranger et nommer les fichiers dans le répertoire de travail de la même façon que Paperwork.
[^] # Re: Comment ca marche ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Paperwork : Besoin de testeurs. Évalué à 2.
Je ne les sélectionne pas :)
En fait je passe le texte tel-quel à Whoosh. C'est lui qui se charge de l'indexation, de la recherche et des suggestions.
Pour Scribo, je ne connaissais pas. Je vais voir pour l'intégrer à PyOCR. Pour ce qui est de l'interaction, actuellement, c'est fait de façon relativement crade: Paperwork (via PyOCR) exécute tout simplement Tesseract comme commande shell. Je suppose que Scribo peut aussi être lancé depuis le shell, donc je ne devrais pas avoir de soucis pour l'intégrer.
En fait, Tesseract fournit aussi une librairie C++, mais du coup ce n'est pas simple à binder sur du Python (du moins sans rajouter une autre dépendance), et je n'ai trouvé aucune documentation expliquant comment l'utiliser. Donc j'ai juste laissé tombé (pour le moment)