Bonjour à toutes et tous,
Un petit journal (mais pas tout à fait bookmark) pour annoncer la présence d'un sprint de développement de preview-generator à pyconfr.
Sprint preview-generator à PyconFR 2019.
Si vous développez en python et que vous recherchez un sprint auquel participer jeudi et vendredi, n'hésitez pas à venir nous voir (et si vous ne voulez pas participer, venez nous voir quand même :)
Nous développons le module python preview-generator développé sous licence MIT et dont le développement est intégralement géré à travers la plateforme github.
preview-generator, c'est un module python qui permet de générer la prévisualisation (jpeg, pdf, html, json, texte) de fichiers et documents à travers une API unifiée.
On a 50 étoiles sur github sans avoir fait la moindre communication dédiée, et on a même un contributeur qui est core developer python (ça c'est la classe)
Pourquoi participer à notre sprint ? Pour améliorer le logiciel pardi ! ;) Et puis aussi parce qu'il est relativement facile d'entrer dans le projet pour par exemple implémenter le support d'un nouveau type de document. Par exemple, si vous connaissez un peu python et que vous connaissez ffmpeg et/ou mediainfo, en 2 jours il est tout à fait envisageable d'intégrer le support de la prévisualisation de vidéos (par exemple générer 10 miniatures de la video qui permettront de "parcourir" la vidéo manuellement)
On a pas mal de sujets à traiter : le support de nouveaux formats de fichiers, des bugs à fixer, des implémentations à améliorer de la doc à compléter… tout est indiqué dans la présentation du sprint preview-generator
La suite du projet
Actuellement, preview-generator est un module python qui s'intègre relativement facilement dans n'importe quel projet python. Il permet de générer une prévisualisation de documents bureautique, images et autres formats de fichiers "standards" (inkscape, svg, zip, …), et ce en différents formats (cf ci-dessus).
Une évolution relativement naturelle du projet serait de proposer un outil "clé-en-main" sous forme d'image docker par exemple proposant une API rest et une API CLI pour générer des prévisualisations d'un maximum de formats (en particulier, je suis en train de réfléchir/travailler sur le support des formats CAO 3D, vidéo) et de proposer un "player web" multi-format
Vous en pensez-quoi ? Utile ? Pas utile ? Sans opinion ?
# utile
Posté par fsx999 . Évalué à 2.
l'idée de l'api rest est vraiment top. Dommage que je ne puisse pas venir cette année à Pyconfr
# Et PIM
Posté par Philippe M (site web personnel) . Évalué à 2.
En plein projet de mise en place d'un PIM (https://fr.wikipedia.org/wiki/Product_information_management) je suis confronté à la gestion des médias (images, vidéos, office…) et on me demande d'avoir une vignette pour chaque médias. L'idée de preview-generator dans un docker qui va bien et qui devient interrogeable depuis n'importe qu'elle appli j'adore !!!
Born to Kill EndUser !
[^] # Re: Et PIM
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Bonjour Philippe,
Je serais intéressé d'échanger par rapport à ton projet et à l'idée d'une image docker pour comprendre comment ça pourrait s'intégrer (confronter mon idée avec la tienne). Est-ce que c'est envisageable ? Si oui, tu peux me contacter à travers le formulaire de contact de algoo ou damien point accorsi arobase algoo point fr ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et PIM
Posté par Philippe M (site web personnel) . Évalué à 1.
Je préfère continuer à échanger sur le sujet ici, ça pourrait intéresser d'autres personnes ;)
Le PIM (Akeneo) est en charge de gérer les médias (entre autres). Les images (jpg) apparaissent directement depuis la navigateur pour les autres formats d'images (eps, ai, psd, tiff, en cmjn…) elles sont considérées comme des fichiers et, au même titre qu'un fichier pdf, doc, xls, … sont proposés au téléchargement.
Toujours basé sur ce PIM j'ai eu besoin de pouvoir intégrer dans un fichier office (Excel) une vignette des images géré par le PIM automatiquement. Un coups de VBA (https://blogoflip.fr/pim-akeneo-importer-des-images-dans-excel-en-vba), de l'API et un dev d'Akeneo m'a orienté vers Flyimg (http://flyimg.io) qui permet de générer à la volé une vignette via une url. Le problème de cette solution est qu'elle se limite aux images au format jpg (à priori). Donc exit les formats orientés graphismes.
C'est là qu'intervient ton projet. A l'image de Flyimg un conteneur qui expose via une url avec une série de paramètres pour générer la prévisualisation qui va bien. En théorie rien de bien compliqué, dans la pratique je ne maîtrise pas du coups Python et je ne me rends pas compte de la complexité du projet.
Born to Kill EndUser !
[^] # Re: Et PIM
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
En fait ma suggestion d'échanger était de pouvoir échanger de vive voix ; il n'y a pas de problème pour restituer ici le résultat, c'est juste plus fluide d'échanger de vive voix.
Clairement preview-generator se positionne comme un outil générique et pas "juste une api de crop et resize d'images".
Tes fichiers sont stockés (ou accessibles) en ligne via une URL ou sur le système de fichier ? Tu as besoin de gérer du cache ? Par exemple si tu fais 2 fois la même requête, est-ce que tu regénère la prévisualisation ou bien tu veux la même ? Est-ce que tu mets à jour tes documents en conservant le même nom ? Est-ce que ça doit être géré ?
Les formats de fichier que tu évoques (jpeg, eps, ai, psd, tiff, en cmjn…) sont exhaustifs de ton cas d'utilisation ou tu t'attends à gérer d'autres formats ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et PIM
Posté par Philippe M (site web personnel) . Évalué à 1.
On est d'accord c'est bien comme cela que je vois preview-generator.
Il y a deux moyens d'accéder aux fichiers :
- par l'interface web
- par l'API
Par le FS c'est probablement faisable mais il faut connaître le chemin d'accès complet.
Mon exemple avec Excel j'utilise l'API, c'est Excel qui réalise la requête à Akeneo pour récupérer l'URL d'accès au fichier et ensuite c'est toujours Excel qui l'envoie à flyimg pour qu'il lui génère une vignette de la taille demandé par l'utilisateur. Cette vignette est ensuite intégré dans le fichier Excel.
Si la requête est relancé l'idéal serait un cache qui vérifie si le fichier a déjà été "vignetté". Si oui il renvoie la version du cache, si non il en génère une nouvelle version.
Les noms de fichiers peuvent être différents lors d'une mise à jour et je ne sais pas trop comment sont géré les fichiers par Akeneo. Je suppose que pour s'affranchir des limites de nommage du FS/OS qui héberge la solution, un nom est généré (genre un hash) et le vrai nom est stocké en base de données. Lors de la requête à l'API on récupère tout ce petit monde.
Born to Kill EndUser !
# s/PyconFR 2020/PyconFR 2019/
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 30 octobre 2019 à 11:16.
Je me suis un peu emballé sur la date ; si un modérateur pouvait rectifier ça serait top :-p
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 30 octobre 2019 à 11:36.
Je peux aussi corriger cette phrase "Si vous êtes développeur python" et la remplacer par "Si vous développez avec python" qui sera plus inclusive ?
Quelle date au fait ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par Tit . Évalué à 2. Dernière modification le 30 octobre 2019 à 14:20.
je trouve le terme "corriger" un peu fort, ça sous entend que la phrase est incorrecte ou en tout cas devrait être améliorée. L'auteur peut accepter ta proposition (qui certes peut être vue comme pertinente, je la trouve d'ailleurs très bien) mais aussi la refuser, parce que sa formulation lui convient, et est tout à fait compréhensible, et aux yeux de beaucoup n'excluent pas les développeuses.
modifier ?
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à -4.
De toute façon un modérateur a corrigé la date. Donc cela va rester en l'état et les développeuses sous Python ne sentiront pas concernées.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6.
Je conçois que la formule originale peut être améliorée ; de là à ne pas se sentir concernée… Il faut aussi être bienveillante et considérer que non, toutes les formulations exclusives ne sont pas faites sciemment. On a le droit à l'erreur, qu'on soit une femme ou un homme, non ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Oui on peut reformuler comme ça effectivement. Il n'y a pas de volonté d'exclure les femmes évidemment… Au contraire vous êtes les bienvenues :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à -1.
Je sais bien qu'il n'y a pas de volonté d'exclusion :-), mais si on ne fait pas remarquer qu'on se sent un peu de trop, ça ne changera pas et cela peut poser de gros problèmes.
J'ai modifié. En prime, je trouve que la formulation actuelle plus active et plus élégante. Je trouvais ça dommage parce que vous prenez, soin, d'habitude, d'avoir une rédaction plus inclusive.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: s/PyconFR 2020/PyconFR 2019/
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
La date : c'est demain :-o
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.