VenC 3.1.1 | Un nouveau générateur de site statique

Posté par  (site web personnel) . Édité par Ysabeau 🧶 🧦, orfenor et Benoît Sibaud. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
46
1
fév.
2024
Python

VenC

On va présenter ici un nouveau générateur de site statique, écrit en python. Il n’est pas exactement nouveau au sens où nous en sommes à la version 3, mais jusqu’ici le projet est resté relativement confidentiel. Nous parlerons également des perspectives d’évolution de ce projet.

Sommaire

Introduction et petit historique

Introducing VenC

VenC est un énième générateur de site statique (libre, évidemment !) dont le nom étrange provient d’un rêve dans lequel je naviguais sur un réseau social appelé « V en C ». Ce rêve, ainsi que la forme et le contenu de ce réseau, m’avaient marqué. Rétrospectivement, ça ressemblait un peu aux premières heures glorieuses de Tumblr / Skyblog avec un petit côté web oldschool.

De gros projets historiques sont déjà bien installés dans le game. Par ailleurs, si j’en crois le nombre d’annonces de logiciels de ce type ici, ça ressemble un peu à un running gag d’arriver avec ma proposition !

Je tenais quand même à présenter l’ouvrage, car il s’agit d’un projet qui me tient toujours beaucoup à cœur et avec lequel j’ai notamment appris le langage Python et pour lequel je continue de progresser. Je l’ai commencé au début des années 2010 précisément quand on voyait émerger ce type d’outil, pour une approche plus “lightweight” du web. Ça n’est que récemment que j’ai ambitionné de rendre ce projet public.

La version 2 est la première que j’ai partagée sur mes réseaux sociaux (Diaspora* et Mastodon). C’était un peu la bêta de la version actuelle, où de grandes restructurations de code avaient été réalisées, fort d’une plus grande expérience en Python. Ça ne m’a pas empêché d’introduire de la dette technique corrigée plus tard, et dans sa plus grande partie je l’espère, dans la version actuelle. J’avais également ajouté une fonctionnalité un peu expérimentale, dont on reparlera plus bas.

Globalement la v1 et la v2 sont restées assez confidentielles. Trop de bugs, pas correctement documentées et pas assez adaptées aux multiples et imprévisibles usages que peuvent avoir les utilisateurs finaux. Certaines questions de choix technico-philosophiques restées en suspens sont encore d’actualité et doivent être décidées par ceux qui l’utilisent. En d’autres termes, je souhaite élargir les possibilités qu’offre VenC en l’adaptant aux besoins des autres, et non plus seulement aux miens.

La version 3.1.0 a été mise en ligne le 30 décembre 2023 et j’estime le projet suffisamment mature (en toute modestie) pour être partagé avec vous. Mon idée étant de proposer l’existant, et de réfléchir avec vous avec les perspectives que j’ai en tête ou que vous pourriez vouloir voir implémentées ! C’est également l’occasion pour moi de bénéficier d’un éventuel retour d’expérience, d’une relecture de code ou de la documentation, et améliorer l’existant.

Que permet de faire VenC ?

Create blog in five minutes !

Il s’agit donc d’un générateur de site statique orienté blog proposant les fonctionnalités suivantes :

  • Des balises VenC permettant une mise en page et une intégration de contenus avancés.
  • La possibilité de créer un agencement de publication en nombre arbitraire de colonnes.
  • Un module et une API JavaScript de défilement infini.
  • Les publications peuvent être organisées par catégories, sous-catégories, par période de dates et par chapitres.
  • La possibilité de désactiver des fils de publications spécifiques.
  • La possibilité de configurer des sous-répertoires pour chaque type de publications.
  • La possibilité d’ajouter des métadonnées au blog et aux publications.
  • Les publications sont triées par ordre chronologique par défaut, mais peuvent l’être aussi en fonction de métadonnées. L’ordre peut être ascendant ou descendant.
  • La génération de flux Atom et/ou RSS pour chaque fils de publications.
  • Des permaliens.
  • Un serveur HTTP simple pour effectuer des tests et prévisualiser le site.
  • La gestion et l’édition du blog peuvent être faites entièrement en ligne de commande, dans un environnement non graphique.
  • Le support de Markdown, reStructuredText, AsciiDoc.
  • La mise en ligne du site peut se faire en FTP via VenC.
  • Le support de pygmentize pour la coloration syntaxique.
  • Le support de l’API oEmbed.
  • Le support de l’API Kroki.
  • Le support de contenus audio et vidéo via les balises VenC.
  • Installation facilitée via pip et pipx.

Faster, smaller, stronger

VenC Install Party

À noter qu’ayant à cœur l’optimisation et la performance, l’essentiel du travail réalisé sur cette version 3.1.0 à été l’intégration d’un mode de génération parallèle pour accélérer l’exportation de votre projet. En fait sur ce dernier point, l’ambition est de faire en sorte que VenC puisse passer à l’échelle en tirant parti des threads Python du module multiprocessing de Python. Nous en reparlerons plus bas.

J’ai passé de longues heures à optimiser l’ensemble du code comme je l’avais déjà fait entre la v1 et la v2. Mon propre site contenant énormément de pages, j’ai besoin d’une application rapide et simple pour générer celui-ci. Il y a quelque chose de très satisfaisant à travailler en ce sens. Tout en mesurant les limites de la chose et en découvrant qu’un excès de zèle rend le code incompréhensible bien sûr… Avec cette v3 je pense avoir atteint un équilibre. En termes de rapidité, la force de VenC réside aussi dans le fait qu’il possède sa propre syntaxe de balisage pour la mise en forme (pas de Jinja donc). Le moteur de template étant ici taillé sur mesure et fortement couplé à l’application, ça tourne très très vite ! Voir la documentation de la syntaxe VenC.

Si jamais ça vous intéresse, il est envisageable de découpler cette partie spécifique du code pour être utilisé ailleurs que dans VenC.

Travaux et réflexion en cours, le futur de l’application

Learning VenC

Le moteur de recherche client-side.

Dans la v2 j’avais introduit une fonctionnalité expérimentale permettant de générer des documents JSON-LD au format JSON ou JSONP. Cette fonctionnalité a été retirée depuis, parce que je ne suis plus sûr de la pertinence de cette technique pour le projet initial : celui d’implémenter un moteur de recherche client-side décentralisé. Ce moteur de recherche devait permettre de chercher du contenu sur un site, mais aussi sur celui des amis, pour lesquels les end-points seraient manuellement ajoutés par le propriétaire du site. Ce faisant, cela permettrait de créer un réseau de site qu’il est possible de crawler pour trouver du contenu.

Il se pourrait que JSON-LD ne soit en fait pas le meilleur moyen pour ce genre d’usage. Mais je n’en sais trop rien, qu’en pensez-vous ?

Intégration avec le Fediverse

Un truc que j’ai toujours trouvé chouette avec Tumblr, c’est le fait d’avoir une page hautement personnalisable qui fait néanmoins partie d’un tout qu’il est possible d’explorer avec le moteur de recherche interne du service. En ce sens, cette idée rejoint celle concernant le moteur de recherche client-side décentralisé.

Avec l’émergence de Fediverse, ça serait en fait intéressant de voir comment il est possible d’intégrer VenC à ce type de réseau. Mon idée initiale était de créer une surcouche de VenC, une sorte de serveur, avec un frontend web, gérant plusieurs sites et capable de répondre dynamiquement à des requêtes des APIs du Fediverse. On comprend ici qu’un tel serveur pourrait avoir à gérer des dizaines, voire des centaines de sites, le parallélisme fraîchement implémenté dans la v3 prend tout son sens.

La question de comment explorer du contenu gérer par VenC de façon décentralisé, modulaire, et interopérable étant le grand axe d’évolution de VenC qui me tient à cœur. Je souhaite recréer ce réseau dont j’avais rêvé il y a longtemps.

Sites statiques, deepweb et smolweb

VenC Is Small

Le smolweb, c’est vraiment cool. Par certains aspects il ressemble aussi un peu au deepweb, lui aussi très intéressant pour d’autres raisons. Les propositions de ces réseaux étant toujours plus d’actualités à mesure que les années passent…

De ce que j’ai pu voir du deepweb, beaucoup de sites sont en fait statiques et d’apparence très sobre, ce qui ne manquera pas de faire vibrer la fibre nostalgique de ceux qui ont connu le web des années 1990 et 2000. Quelle époque ! Dans les deux types de réseau on retrouve deux aspects qui me tiennent à cœur, le green IT pour l’un et la vie privée pour l’autre. Des valeurs dans lesquelles je me retrouve évidemment, et pour lesquelles je souhaiterais que VenC apporte sa pierre à l’édifice.

Une des perspectives d’évolution de VenC serait de pouvoir faire en sorte qu’il puisse générer des sites spécifiquement pour les différents types de smolweb : Gopher, Gemini… Mais je ne connais pas bien le fonctionnement de ceux-là, c’est donc encore à l’étude.

Et le format EPUB ?

Puisque VenC gère le chapitrage de son contenu, ça pourrait avoir du sens de pouvoir générer des documents EPUB. Et comme ce format est en fait du contenu HTML embarqué dans un zip… Il n’y a plus qu’à étudier les spécifications du format, et au boulot. Mais peut-être qu’il existe déjà un module ou package Python pour ce genre de chose ? Tout ça est aussi à l’étude.

Internationalisation des articles

Le besoin étant d’avoir plusieurs versions d’un même article dans des langues différentes, il y a plusieurs façons de réaliser ça… Ça n’est donc pas une feature triviale.

Ça pourrait m’aider de me parler un peu de la façon dont vous voyez la chose pour un blog statique.

Fonctionnalités de base manquantes

La plupart des générateurs de sites statiques ont cette fonctionnalité, mais pas VenC. Pas encore en tout cas, mais c’est dans les tuyaux !

Génération incrémentale et mise en cache.

VenC Is Fast

Au lieu de régénérer tout le site à chaque modification, VenC ne devrait modifier que le strict nécessaire. Une mise en cache des pages à certaines étapes de la génération du site pourrait être mise en œuvre pour accélérer le traitement.

Auto-rafraîchissement lors de la prévisualisation

Cette fonctionnalité va de pair avec la précédente, lorsque le site est prévisualisé il devrait s’auto-régénérer quand une modification est faite.

Ajout de modules tiers écrit par les utilisateurs eux-mêmes

VenC Is Written In Python

Pour le moment VenC n’a pas de greffons autres que ceux déjà prévus par l’application, mais les futures versions bénéficieront d’une API permettant d’écrire vos propres fonctionnalités.

Le mot de la fin

J’ai à cœur de rendre ce logiciel accessible dans d’autres langues, pour la traduction de la documentation et du logiciel lui-même, je cherche des personnes pouvant justifier d’une capacité professionnelle de traduction dans une langue ou une ou autre. L’anglais et l’allemand seraient par exemple un bon début. Ce travail serait naturellement rémunéré. N’hésitez pas à me contacter si vous pensez avoir la compétence requise pour que nous en discutions.

Cette v3 a demandé beaucoup d’efforts, j’espère que ce logiciel trouvera ses utilisateurs ! J’en profite pour remercier les contributeurs qui croient en ce projet et notamment Jérémy Berry pour ses conseils et sa précieuse relecture, Sidoine Baratte qui suit le projet depuis le début et avec qui j’ai affronté les bugs ainsi que benben962 pour sa traduction en anglais de l’ancienne documentation !

Ressources du projet

Illustrations

Les sources des illustrations :

Modules optionnels

  • Mistletoe : Pour l’utilisation de la syntaxe Markdown.
  • Docutils : Pour utiliser la syntax reStructuredText.
  • Latex2MathML : Pour convertir du LaTeX en MathML.
  • Pygments : Pour la coloration syntaxique.
  • AsciiDoc3 : Pour utiliser la syntaxe Asciidoc

Aller plus loin

  • # compilation incrémentale

    Posté par  . Évalué à 5 (+5/-0).

    Y a truc qui gère bien la génération avec la compilation incrémentale, c'est make.

    ça gère les modifications de sources, et les dépendances.

    à voir si cela est adapté à VenC.

    je poste sur la tribune, cordialement

  • # Illustrations

    Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

    Les illustrations sont très chouettes et le projet a l'air sympa même si perso je préfère les sites dynamiques :)

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Illustrations

      Posté par  (site web personnel) . Évalué à 3 (+3/-0).

      Hey ! Merci !

      Dis voir c'est pas toi qui fait de la musique électronique et qui avait fait vers 2010 un morceau expérimental intitulé "Pringles" parce que fait à base de sons de boite de Pringles (du génie par ailleurs) ?

      Si oui, sur ton blog de l'époque tu m'as fais découvrir Idle Sunder, mon all-time-favorite band depuis ! Merci également pour ça !

      • [^] # Re: Illustrations

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        J'ai fait de la musique électro oui mais pas ce morceau désolé :)

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Sympa les illustrations

    Posté par  (Mastodon) . Évalué à 4 (+2/-0).

    Je n'ai pas grand chose à dire sur tous tes questionnements.

    Un jour peut-être je passerai à un générateur statique de site sur mon pc pour mon blog mais je ne suis pas certain que je considérerai sérieusement VenC malgré que le projet a l'air cool. Premièrement, comme je suis assez peu compétent, je crois que je me dirigerais vers un outil plus connu et répandu histoire d'avoir plus de chances de trouver de l'aide en ligne. C'est le problème évidemment pour tout nouveau projet. Mais à mon niveau de connaissance (très très limité), j'ai du mal à voir l'intérêt de cet énième générateur de site statique. En tout cas pour mon cas d'usage. Et c'est là que je me dis que le cœur de cible de ton projet n'est pas très clair dans la communication (tu apprécieras cette phrase en novlangue pseudolibérale ;-)) ou plus sûrement que je n'en fait pas partie.

    Sinon, cool tes illustrations. Et cool même si je ne les utiliserai jamais (quoique) de mettre à disposition les sources de celles-ci.

    Surtout, ne pas tout prendre au sérieux !

    • [^] # Re: Sympa les illustrations

      Posté par  (site web personnel) . Évalué à 3 (+3/-0).

      Salut Tisaac ! Merci pour ton retour !

      En effet la communication n'est peut-être pas très clair en ce sens qu'en l'état VenC ne se distingue des autres solutions que par son moteur de template interne. Il ne fait fondamentalement pas de choses que ne font pas déjà les autres générateurs.

      Mon propos était de présenter l'ouvrage et surtout les perspectives d'évolution du logiciel qui, pour le coup, amènent me semble-t-il une vrai innovation ou au moins amélioration dans ce qui existe déjà. En particulier je crois que rendre encore plus interopérable les réseaux libres décentralisés existant, en intégrant de nouvelle forme de gestionnaire de contenu (comme des générateur de site statiques) contribuerait à fortifier notre écosystème, et c'est vers ça que je souhaite aller avec VenC :)

      Au plaisir de te lire ou te filer un coup de mains pour VenC si jamais tu tentes l'aventure !

      • [^] # typo

        Posté par  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

        En effet la communication n'est peut-être pas très clair en ce sens qu'en l'état VenC ne se distingue des autres solutions que par son moteur de template interne.

        J’en profite pour signaler que la dépêche mentionne, comme opposé, « Jinga » : je suppose que c’est une erreur de frappe et qu’il faut lire « Jinja » …ou alors un petit lien aurait été bienvenue.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Bien intéressant!

    Posté par  . Évalué à 3 (+2/-0).

    Dès que j'ai le temps je vais essayer.

    Actuellement j'utilise Hugo pour mon maigre blog. Peut-on voir des sites déjà créés avec Venc ?

    arnauld

    • [^] # Re: Bien intéressant!

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Ici aussi Hugo.

      Ce qui est bien avec Hugo, c'est la visualisation en temps réel. Tu modifies une page du site, tu sauvegardes, et le navigateur web rafraîchit automatiquement la page concernée pour afficher le rendu final.

      J'ai des pages Markdown assez complexes pour mes sites, incluant du HTML, du CSS, voire des scripts, et c'est très pratique de pouvoir contrôler si tout s'affiche correctement sans avoir à relancer à chaque fois la « compilation » à la mano.

      Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

      • [^] # Re: Bien intéressant!

        Posté par  . Évalué à 6 (+4/-0). Dernière modification le 02 février 2024 à 12:15.

        Personnellement, mon générateur de site web statique maison (une bouillie de scripts au dessus de htp et pandoc) utilise inotity, make et le module https.server de Python pour faire ça en quelques lignes :

        #!/bin/sh
inotify-hookable -t 2000 --no-r -w . -c make &
IHPID="$!"
cd html && python3 -m http.server
kill -INT "$IHPID"

        (où html/ est le sous dossier qui contient le site généré).

        • [^] # Re: Bien intéressant!

          Posté par  . Évalué à 2 (+0/-0).

          Ce dont il est question au dessus va encore un peu plus loin, il communique avec le navigateur et ce dernier recharge la page de lui-même. C'est extrêmement fluide à l'usage, on est très proche d'un WISWIG.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Bien intéressant!

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Bonjour !

      Les blogs de quelques amis :

      • Généré avec l'ancienne version (VenC 2.x) : https://connexions-vivant.ovh/Blog/
      • Généré avec l'actuel version : https://jeremyberry.org/. Le thème a été importé d'un autre blog de mathématique. Il y a un p'tit problème au niveau du footer pour le moment, mais c'est au niveau du CSS/HTML que ça se joue, ce n'est à priori pas un problème directement lié à VenC.

      Des sous-parties de mon site :

      Le site d'un projet de netlabel que j'ai un peu laissé en suspend faute de temps :

      • [^] # Re: Bien intéressant!

        Posté par  . Évalué à 2 (+1/-0).

        J'allais te poser la question concernant ton site (via le lien mon "site web personnel") et son "moteur", voilà, j'ai la réponse. Il est sympa, tant au niveau de son contenu que de son fonctionnement général.

        Donc bravo pour ça et surtout pour ton travail sur l'outil que tu nous présentes ici.

        "Si tous les cons volaient, il ferait nuit" F. Dard

      • [^] # Re: Bien intéressant!

        Posté par  . Évalué à 1 (+0/-0). Dernière modification le 02 février 2024 à 17:50.

        Merci.

        arnauld

  • # Optimisation

    Posté par  (site web personnel, Mastodon) . Évalué à 10 (+8/-0).

    "Au lieu de régénérer tout le site à chaque modification, VenC ne devrait modifier que le strict nécessaire. Une mise en cache des pages à certaines étapes de la génération du site pourrait être mise en œuvre pour accélérer le traitement."

    Ayant écrit mon propre générateur pour mon blog qui comporte près de 900 billets, je peux t’assurer que c’est une optimisation a priori non nécessaire.

    Je me cassais la tête pour savoir comment faire ça puis, un jour, j’ai décidé de faire un prototype sans cache.

    Je viens de tester : 1,68s pour générer 869 posts. Cela comprends la génération de la version HTML, de la version Gemtext (gemini) et de 4 pages d’index (page d’accueil, FR, EN et tous les posts).

    Étant donné que très peu de blogs arrivent à autant de posts et étant donné la complexité du caching et des bugs qui en découlent (car il faut invalider le cache, etc), je peux garantir avec quasi certitute que c’est de l’overengineering et qu’il y a de grandes chances que l’investissement ne soit jamais rentabilisé (le temps de développement de la feature soit toujours plus grand que le temps de processing total gagné par tout tes utilisateurs).

    Mon billet sur le sujet : https://ploum.net/2022-12-04-fin-du-blog-et-derniere-version.html

    Mes sources : https://sr.ht/~lioploum/ploum.net/

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Optimisation

      Posté par  (site web personnel, Mastodon) . Évalué à 2 (+2/-2).

      Je me demande ce que peut être le cache pour un site statique… et pour un générateur de site statique…
      Après, il est dit/écrit « mise en cache des pages à certaines étapes de la génération » ; du coup ça peut s’entendre si la génération est multi-passes… (ce qui n’est probablement pas le cas de ton générateur perso) Ceci dit, je suis d’accord sur la remarque de la complexité de la chose.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Optimisation

        Posté par  (site web personnel) . Évalué à 1 (+0/-0).

        Le cache pourrait être le site statique lui même avant exportation en ligne, si le site n'est pas hébergé localement. Le procédé ici consistant à ne modifier que le strict nécessaire pour minimiser l'I/O. Ça pourrait également avoir du sens si VenC passe l'échelle dans le cadre d'une surcouche pour le Fediverse, cf: Intégration avec le Fediverse.

        Concernant l'autre aspect du cache, il y a bien plusieurs passes pour la génération d'un site avec VenC. Si ma mémoire est bonne il y en a entre 4 et 5 selon les options activés. Pour le moment les étapes intermédiaires ne sont pas stockés de façon persistantes mais ça pourrait être envisageable.

    • [^] # Re: Optimisation

      Posté par  (site web personnel) . Évalué à 5 (+4/-0).

      Salut Ploum !

      Ça se discute en effet, à minima il faudrait que je prenne le temps d'étudier le rapport coût/bénéfice. Ce qui est sûr c'est qu'il y a au moins deux couches consommatrices de temps CPU et d'I/O dans la RAM :

      • Le moteur de template interne de VenC, malgré l'overengineering l'optimisation raisonnable et mesuré.
      • Les moteurs de balisage externe, comme mistletoe pour Markdown.

      Après de nombreux tests et benchmark entre la v2 et la v3 il apparaît que ce sont les véritables goulot d'étranglement du programme. Sauf erreur de ma part ton site dans sa version définitive n'utilise pas (plus?) Markdown, et en ce sens effectivement, de la mise en cache n'est sans doute pas vraiment utile. Dans le cas de VenC, je serai plus nuancé. C'est encore à l'étude !

      En tout cas je vois tout à fait ce que tu veux dire à propos de l'overengineering, j'ai pris d'assez mauvaises décisions dans la v2 qui ont été assez coûteuses à rattraper dans la v3 … Je me retrouve également beaucoup dans ton expérience personnelle témoignée dans ton billet, ainsi que la philosophie qui en découle ! Merci du partage !

      Je conclurais ce message par un petit visuel de ma conception toujours d'actualité me semble-t-il :

      2019_-_Denis_Salem_-_CC_By_SA_-_programming-triangle-of-death.jpg

    • [^] # Re: Optimisation

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Personnellement je ne serais pas si affirmatif.

      Je prends le cas de ce site (un peu mort) que je génère avec Hugo. L’un des avantages (et des arguments mis en avant) de Hugo est qu’il est très rapide, et peut se passer de ce genre de cache. Sauf que je ne génère pas que du HTML, j’ai aussi du ePub et du PDF. Le ePub est encore assez rapide ; mais le PDF passe par LaTeX, qui est extrêmement lent… et là, je serais très heureux d’avoir de la compilation incrémentale.

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: Optimisation

        Posté par  (Mastodon) . Évalué à 3 (+1/-0).

        Je ne sais pas comment tu le génère, mais je vais supposer que Hugo n'est pas en charge des appels LaTeX ou des générations ePub, si ce n'était pas le cas le raisonnement tomberait à l'eau.
        Dans ce cas tu as un processus de génération qui lance plusieurs outils les uns après les autres.

        Est-ce qu'un simple make ne pourrait pas te permettre de ne pas régénérer les ePub et PDF des pages non modifiées ?
        En mettant comme pré-requis les fichiers sources (y compris templates et styles, s'ils changent), et non pas le fichier éventuellement recréé d'office à chaque fois par Hugo lui-même.

        C'est peut-être très compliqué à mettre en place par rapport à ton besoin hein.

        • Yth.

  • # Joli projet, et nous aussi ...

    Posté par  (site web personnel) . Évalué à 3 (+2/-0).

    Très bonne idée, si plus de personne utilise Asciidoc, c'est du bonheur en barre.

    Nous sommes entrain d'imposer ce format (façon dictateur bien-veillant) pour la R&D, les labos et les développements. Et même depuis peu, chez certains de nos dévoués clients, en compétition avec Sharepoint (je crois que tout le monde est TRÈS satisfait)…

    La partie de notre site gérant le contenu statique utilise Asciidoc, via AsciidoctorJ. Le générateur de page (une tâche gradle) n'est pas encore Opensourcé. Il y a la recherche à facette, sur le contenu statique. La structure des menus et dépendant de la langue suivent l'arborescence des fichiers.

    La partie dynamique est déjà Opensource, il manque le composant proposant l'upload via Git et nos extensions AsciidoctorJ utilisant des DSL (en cour de développement).

    J'espère faire un gros journal sur ce sujet d'ici quelques temps.

    Les forces d'Asciidoc :

    • meilleure syntaxe que md (attention, chacun son cas d'usage, c'est selon moi. Elle est moins permissive, tableau + lisible …)
    • l'intégration dans la version Opensource d'Intellij parfaite
      • et supportant les extensions AsciidocorJ et JRuby
      • et du coup, l'auto-complétion de ces extensions ..
    • Utiliser Gnuplot, PlantUML, autres, est du bonheur en bar pour tous en fait…

    Voila, j'espère que ton projet cartonnera.

    • [^] # Re: Joli projet, et nous aussi ...

      Posté par  . Évalué à 2 (+0/-0).

      J'ai entendu le plus grand bien récemment d'Antora. C'est fait pour de la documentation et c'est Asciidoc + ansible + je ne sais plus quel moteur de template (un truc du monde js je présume).

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Comparaison à d'autres outils similaires

    Posté par  (site web personnel) . Évalué à 2 (+1/-0).

    Merci pour cet article de présentation !

    Je suis aujourd'hui utilisateur de Pelican, un autre générateur de site statique en Python. Toujours dans ce langage, il en existe pas mal d'autres : https://wiki.python.org/moin/StaticSiteGenerator

    Ce qui pourrait me convaincre à employer VenC, ce serait un comparatif entre VenC & Pelican (et potentiellement d'autres générateurs), notamment en termes de fonctionnalités offertes.
    Est-ce qu'un tel comparatif existe ? 🙂

    • [^] # Re: Comparaison à d'autres outils similaires

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Sommaire

      Tout d'abord merci de ton intérêt !

      Je dirais que ça dépend de ton besoin. Il n'y a pas de comparatif à ce jour … Mais il y a une liste exhaustive de ce que permet VenC ici : https://venc.software/Fonctionnalites/

      Vitesse d'exécution

      Globalement, ce dont je suis sûr pour l'avoir officieusement benchmarké c'est que VenC est beaucoup plus rapide que Pelican (et que Nikola aussi il me semble). Mais ne me croit pas sur parole : Les tests que j'avais fait date et ça a peut être changé entre temps. Je défend tout de même de la grosse performance pour VenC particulièrement sur de gros site. Je te laisse tester ça :)

      Taxonomie

      Dans la v3.2 de VenC qui arrive le mois prochains, ou en avril, il y aura une fonction de taxonomie avancé comme c'est déjà possible de le faire dans Hugo (tu peux déjà tester ça sur la branche de développement de la v3.2, bon ça n'est pas encore documenté par contre, mais je peux t'aider à tester le truc si tu veux).

      Pour le moment il est déjà possible de trier tes publications par catégories hierarchisé. Ça c'est vraiment vraiment cool, d'autant plus qu'il me semble que ce n'est pas une fonction built-in dans Pelican, mais ça a aussi peut-être changé.

      Pour VenC ça se fait comme ça : https://venc.software/Motifs-de-blog/#getblogcategoriestree

      Si tes publications sont organisés en arbres de categories il est également possible d'afficher un nuage de mot clef qui correspond à une liste "flattened" de ces categories :

      https://venc.software/Motifs-de-blog/#getflattenedblogcategories

      Affichage en nombre arbitraire de colone

      Les habitués de tumblr l'on peut-être remarqué mais il est possible d'avoir ce genre de layout https://denissalem.tumblr.com/ en nombre arbitraire de colonne. Perso je trouve ça super stylé, c'est une des premières features "rigolote" que j'avais implenté pour VenC pour que ça fonctionne sans javascript en pure html/css. Maintenant je ne l'utilise plus sur mon site et il n'y a pas de thème par défaut qui exploite cette approche, mais c'est toujours possible et documenté. Il faut juste crée son layout graphique et ça part en prod ! :)

      Ne pas hésiter à ouvrir une issue sur github ou framagit si besoin d'aide :) J'essaie de me rendre disponible autant que possible.

      Chapitrage du contenu

      En plus de l'organisation du contenu par dates et par catégorie il est aussi possible d'organiser son blog avec des chapitres. La documentation de VenC est d'ailleurs faite comme ça !

      Intégration de diverse API :

      Il est possible de nativement faire plein de chose sympas :

      • du code MathML à partir de la syntaxe LaTeX avec latex2mathml
      • Générer des graphique avec l'API de Kroki (natif, pas besoin de module)
      • Importer des players multimedia genre soundcloud, youtube ou bandcamp avec oEmbed (natif également)
      • Support de la coloration syntaxique si tu install pygments

      À noter que j'aimerais implémenter/intégrer des APIs utiles dans le domaine de la publication scientifique pour que VenC soit aussi un outils vecteur de médiation scientifique.

      J'ai en tête plein de module et API très cool à intégrer dans pas trop longtemps, donc wait and see !

      Balise VenC

      VenC n'utilise pas Jinja2. Parce que je suis un rageux et que j'aime réinventer la roue. C'est un choix technique que je ne regrette pas du tout, ça participe à l'efficience de VenC ! Ces balises permettent la création et la mise en forme de ton projet, mais ça permet aussi de compléter des fonctionnalités manquante dans des langages de balisage comme markdown. Typiquement markdown ne permet pas il me semble de réaliser des tables des matières dans une publication. La faute à des implémentations très variables en nombre de fonctionnalité, de qualité, et de rapidité. VenC permet donc de faire une tables des matières, mais aussi de générer des tableaux, ou de générer des balises span pour styliser plus finement ton contenu. Tout ça en s'efforçant de s'intégrer au mieux à Markdown.

      La liste des balises VenC se trouve ici : https://venc.software/Feuille-de-reference/

      La syntaxe est plus rigide que Jinja2, mais VenC est étudié pour générer du site statique donc l'essentiel des fonctions nécessaire sont déjà présente. Et quand il manque des choses, elles sont rajoutées à la demande des utilisateurs ou de mon propre chef :)

      Pas de support de pages dans VenC

      Il me semble que Pelican gère les pages individuel (qui ne sont pas des billets de blog). VenC n'a pas exactement de fonction pour faire ça ou alors ce sont des work-around pas tip-top. C'est prévu d'implémenter les pages dans de futur version cependant.

      Pas de blog multi-langage pour le moment

      Ça, c'est un vrai sujet et j'aimerais monter un groupe de travail sur la question pour réfléchir à la meilleur approche. C'est vraiment pas une feature trivial comme je le dit dans la dépêche et ça demande une réflexion approfondie sur les implications d'une telle fonctionnalité en terme de limite d'expérience utilisateur et de contrainte logiciel.

      Voilà voilà, j'espère que ça répond à ta question et que ça t'aide à y voir plus clair :)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.