Journal Web Log Today est juillet - écrire un blog de nos jours

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
21
30
jan.
2013

Sommaire

Après la superbe trilogie « écrire une page web de nos jours », voici enfin la suite tant attendue.

Pour rappel :

  1. Ecrire une page web de nos jours et la suite des aventures
  2. Ecrire une page web de nos jours, troisième partie

Mais quelle suite pouvait-on donner alors ? Avec ces trois épisodes nous avons touché du bout des doigts la création d'une page web aujourd'hui. Bon, on en est resté au strict minimum avec haml, git, markdown, ruby, gem, guard, rake, sass, coffeescript, bundler, redcarpet, gollum, etc. Evidement pas question d'en rester là !

Voici un petit résumé tout de même :

  • le html c'est surfait
  • le css c'est tellement 2012
  • ruby c'est indispensable
  • gem say bien
  • markdown ça enlarge ta capacité à écrire
  • javascript c'est pour les boutonneux, coffeescript c'est pour les vrais

Pfiou, on en avait vu des choses tout de même !

L'ensemble était orienté "simple page web". Mais les simples pages, say trop nul, il en faut deux ! (ou plus…) Et c'est ainsi qu'est né Web Log Today ! Voyons donc désormais comment écrire un blog de nos jours !

Présentation

Web Log Today (wlt) est né d'un besoin très simple : remplacer mon vieux blog dotclear par un ensemble beaucoup plus sympa :

  • site / blog statique (pas besoin d'un langage côté serveur)
  • markdown comme langage principal de contenu
  • génération simple de flux atom, sitemap, etc
  • gestion (bien qu'un peu sommaire pour le moment) de tags
  • gestion de billets mais aussi de pages statiques
  • utilisation de templates pour ne pas se répéter tout le temps
  • que des technos cool (mais pour le coup elles sont presque toutes dans la version "écrire une page web de nos jours")

Au final, ça donne quelque chose dans le même genre que jekyll avec quelques différences :

  • haml est utilisé aussi bien comme langage de template que comme générateur de html
  • sass est utilisé par défaut pour les css
  • coffeescript est utilisé par défaut pour le javascript
  • uniquement markdown est supporté côté contenu, et on ne peux pas utiliser de template dans les contenus

Sinon c'est un peu le même principe, il y a pas mal de ressemblances entre autre sur les headers des fichiers (pour indiquer le layout à utiliser, le titre, les tags, etc).

Installation

La majeur partie de Web Log Today est la commande wlt. Cette commande est basée sur sub et ça c'est juste très pratiques. Pour la suite, je pars du principe que vous allez l'installer dans ~/.wlt.

  1. Dépendances

    git, ruby 1.9.3, bundler

  2. Récupération des sources

    git clone https://github.com/CrEv/wlt.git ~/.wlt
cd ~/.wlt

  3. Récupération des dépendances

    bundle

  4. Mise à disposition

    Pour bash :

    echo 'eval "$(<wltpath>/bin/wlt init -)"' >> ~/.bash_profile
exec bash

    Pour zsh :

    echo 'eval "$(<wltpath>/bin/wlt init -)"' >> ~/.zshenv
source ~/.zshenv

Et voilà, wlt est dispo !

Mise à jour

Evidemment, c'est juste trop facile !

cd ~/.wlt && git pull && bundle

Un petit apparté sur le côté git : le but est de garder la branche master toujours installable. Il devrait donc être possible en permanence de faire un pull depuis le master sans craindre le moindre problème. Les développements futurs seront +

Usage

Le principe global est plutôt simple. wlt va lire des informations dans des dossiers spécifiques, va les compiler en css, js et html afin d'en générer un site statique. De manière globale le principe est :

convention over configuration

La majorité des choses repose donc sur certaines conventions, en premier lieu les fichiers et répertoires.

_site

Ce répertoire contient l'ensemble des fichiers générés. Il s'agit réellement de votre site web, il suffit de le copier sur votre serveur pour le rendre disponible.

_posts

Le répertoire _posts contient logiquement les billets de votre blog. Il s'agit de fichiers markdown dont le titre a la structure suivante :

yyy-mm-dd-title-of-the-blog-post.md
  • yyyy : année de publication
  • mm : mois de publication
  • dd : jour de publication
  • title-of-the-blog-post : nom du fichier, en général le titre du billet sans accent ni espace ni caractère spéciaux

Le fichier html généré sera :

yyyy/mm/dd/title-of-the-blog-post.html

_pages

Vous pouvez définir des fichiers statiques qui ne sont pas des billets de blog. Ces fichiers se trouvent dans le répertoire _pages et sont des fichiers markdown. Le nom du fichier markdown sera le nom du fichier html généré. Par exemple index.md deviendra index.html.

Certaines fichiers un peu plus spéciaux peuvent être présents, voir la partie spécifique.

_css

Contient l'ensemble des fichiers sass destinés à être compilés en css. Les fichiers "racines" sont spécifiés dans la configuration (voir plus loin). Le fichier généré est le nom du fichier sass avec l'extension css. Par exemple application.sass donnera application.css

Vous pouvez utiliser toutes les fonctionnalités de sass, entre autre les @import vous permettant de factoriser vos css.

Si vous avez des fichiers css à inclure, et donc ne nécessitant pas une compilation, se référer à la partie publique.

Note : il est bien sur possible d'avoir plusieurs fichiers css de sortie.

_js

Contient l'ensemble des fichiers coffeescript destinés à être compilés en javascript. Les fichiers à compilés sont à spécifier dans la configuration.

Le fichier généré est le nom du fichier coffeescript avec l'extension js. Par exemple application.coffee donnera application.js.

Pour le moment il n'y a pas de mécanismes permettant de concaténer plusieurs fichiers coffeescript en un. Dans un premier temps ce n'est pas réellement nécessaire car le but était de faire un site/blog simple et non une application web. Néanmoins un système type sprockets pourra être envisagé par la suite.

Si vous avez des fichiers js à inclure, et donc ne nécessitant pas une compilation, se référer à la partie publique.

Note : il est bien sur possible d'avoir plusieurs fichiers javascript de sortie.

_layouts

Contient l'ensemble des fichiers haml de templates. Il peut s'agir aussi bien de fichiers "racines" fournissant l'html de base que de fichiers partiels (à charger avec render :partial => "...") ou des fichiers "intermédiaires".

Les contenus (pages, posts) déclarent dans leur entête le template à utiliser. Un template peut également faire appel à un template parent. Ceci permet par exemple d'avoir un premier template correspondant à tout ce qui tourne autour du contenu généré par le markdown, et un autre dédié à la page en elle-même. Pour plus d'explications, je vous suggère juste d'aller voir les exemples.

_pub

Ce répertoire est probablement le plus simple. Tout ce qui est contenu dedans sera copié à la racine du site. Il permet donc d'inclure des fichiers css, des javascript, des images, des ressources diverses, des fichiers html générés par d'autres moyens, etc.

config.yaml

Le fichier config.yaml contient les paramètres nécessaire à la génération du site. Il s'agit de paramètres "systèmes" (par exemple l'url, le chemin de déploiement) ou simplement des paramètres destinés à être factorisés (comptes, infos twitter, etc).

Voici un exemple de fichier, commenté :

# URL du site généré (les liens sont tous absolus)
site_url: http://log.winsos.net
# URL de déploiement, via rsync
deploy_to: ...@www.....lan:/var/www/log/
# Titre des pages
title: CrEv's log

# Informations twitter cards, opengraph, etc
# Nom de l'auteur
name: Plop Plop
# Twitter site / creator -> twitter cards
twitter_site: _crev_
twitter_creator: _crev_
# Description par défaut si non fournie
default_description: My personal weblog

# Divers comptes, permettant d'être affichés dans une page about dans les templates par défaut
accounts:
    twitter: https://twitter.com/_crev_
    gplus: https://plus.google.com/112813954986166280487
    github: http://github.com/CrEv
    coderwall: https://coderwall.com/crev
    linkedin: http://fr.linkedin.com/in/yvesbrissaud

# Assets, description des css/js à générer (nom des fichiers sans extension)
assets:
    css: [application, cv]
    js: [application]

A part le premier (site_url) qui est réellement conseillé, le reste est toujours optionnel et dépend de vos templates. Ceci n'est donc qu'un exemple et vous pouvez en rajouter autant que vous voulez. Ils seront donc accessible de partout via les objets ruby.

Headers

Chaque fichier markdown et haml peut débuter par un entête ajouter quelques méta données. Selon les cas (pages, billet, template) les paramètres ne sont pas forcément tous obligatoire. Voici les paramètres dans le cas d'un billet de blog.

Tout d'abord l'entête doit toujours débuter à la première ligne du fichier, par --- et termine par une ligne contenant uniquement ---.
Ce qui est entre ces lignes est du yaml.

Voici donc les données les plus courantes :

  • layout : nom du fichier haml qui va recueillir la sortie de markdown
  • tags : tableau contenant les tags relatif au billet
  • title : Titre clair, avec accents et autres
  • author : Nom de l'auteur
  • email : email de l'auteur. L'email n'est pas affiché, il est utilisé pour afficher le gravatar correspondant
  • twitter : compte twitter de l'auteur. Optionnel, il peut être défini dans la configuration
  • published : si false permet de ne pas généré la sortie. Cela permet de versionner certains contenus avant qu'ils soit publiés

Par exemple :

---
layout: post
tags: [web_log_today]
title: Web Log Today est juillet
author: Yves
email: plopplop@....com
twitter: _crev_
published: false
---

Note : vous pouvez rajouter sans aucun problème des métadonnées propres. Elles seront accessibles via les objets ruby comme détaillé plus bas. Cela peut vous permettre d'améliorer vos templates, votre site, en posant le maximum de données dans les fichiers markdown ce qui permet de rendre la saisie plus agréable.

Fichiers spéciaux

Deux fichiers un peu plus spéciaux peuvent être présent dans le répertoire _pages et un dans le répertoire _layouts.

Le premier est simplement le fichier atom.xml.haml. Comme son nom l'indique il permet de générer un fichier atom.xml et donc permet d'offrir à vos lecteurs un flux à placer dans un quelconque lecteur. Par défaut il permet de générer un flux basé sur les articles de blogs uniquement.

Le deuxième, un peu dans le même veine, est le fichier sitemap.xml.haml. Il permet de générer un fichier sitemap.xml listant l'ensemble des ressources html de votre site.

Enfin le fichier tags.haml peut être présent dans le répertoire _layouts afin d'afficher tous les billets d'un tag commun. Contrairement à tous les autres cas, ce fichier aura de multiples sorties, un fichier par tag, présent dans le répertoire tags.

Objets ruby

Les fichiers haml peuvent accéder à un certain nombre de propriétés et méthodes. L'ensemble n'est pas parfaitement unifié mais cela fonctionne plutôt bien. C'est un point qui sera amélioré par la suite.

Voici les propriétés les plus importantes accessibles dans les fichiers haml :

  • name : nom du fichier

  • @contents : propriétés globales du contenu

    • config : yaml du fichier du configuration
    • list : ensemble des posts
    • list_lasts(number) : ensemble des posts, au plus number
    • list_by_date : ensemble des posts organisés par année, mois, jour
    • account?(name) : vérifie la présence d'un compte name dans la configuration
    • account(name) : valeur du compte name dans la configuration
    • tag : tag courant, dans le cadre de tags.haml
    • urls : l'ensemble des urls des billets et pages

  • link_to(url) : transforme une url relative en url absolue en utilisant la configuration

  • gravatar? : teste la présence d'un email pour afficher un gravatar

  • gravatar : url de l'image gravatar

  • published? : présence du paramètre published dans l'entête

  • published : valeur du paramètre published de l'entête ou true

  • date : date, dans le cas d'un billet

  • <...>? : teste la présence de <...> dans l'entête

  • <...> : valeur de <...> dans l'entête

  • @scope : En gros idem que tout cela, mais spécifiquement au contenu markdown. Cela permet d'avoir accès aux valeurs de l'entête du contenu ainsi que celles de l'entête du haml

  • content : contenu html à insérer (généré à partir du markdown ou à partir du haml)

D'autres propriétés existent, mais entre ça et les exemples ça devrait permettre de commencer ;-)

Et donc, comment que ça marche en pratique ?

Quelques petites commandes au niveau de wlt :

wlt assets

Compilation des css et javascript.

wlt build

Vide le répertoire de sortie et génère l'intégralité des données.

wlt clean

Vide le répertoire de sortie

wlt gollum

Lance gollum afin de visualiser et éditer les fichiers markdown du projet. Attention, seuls les fichiers ajoutés à git sont gérés.

wlt serve

Compile l'ensemble des données en changeant l'url de destination et le rend disponible sur http://localhost:4000

wlt scaffold

Permet de générer une version de base, simple ou déjà relativement complexe, facilitant le démarrage avec wlt.

Les deux commandes sont wlt scaffold basic et wlt scaffold full.

La version basique contient le strict minimum pour bien commencer :

  • fichier css de base
  • fichier js de base
  • une page d'index listant tous les billets
  • un template pour les billets
  • un header contenant les infos twitter, opengraph, etc
  • un atom, un sitemap
  • un fichier rake et un fichier guard

La version complète rajoute :

  • un css déjà correct (couleurs, mise en page, etc)
  • tags, pages
  • quelques partiels

Getting started

Pour finir, voici un mini tuto pour prendre en main wlt.

  1. Créer un répertoire destiné à recevoir vos sources, dans notre cas mon_supair_blog

    mkdir mon_supair_blog
cd mon_supair_blog

  2. On échafaude en version basique (pour la version full je vous laisse regarder)

    Attention, wlt scaffold nécessite un répertoire vide.

    wlt scaffold basic

    Vous vous retrouvez donc avec tout ce qu'il faut pour commencer.

  3. Vous pouvez déjà voir le rendu tout de suite :

    wlt serve

    Puis rendez-vous sur http://localhost:4000

    Et voilà, votre blog est en route !

  4. Créer un dépôt git (utile pour plein de raisons, entre autre pour l'édition)

    git init
git add .
git ci -m "Initial scaffold"

  5. Un peu de configuration

    Editez le fichier config.yaml. La configuration est plutôt simple et claire.

    Editez le fichier _pub/robots.txt pour changer l'adresse du fichier sitemap.

    Si vous voulez utiliser le déploiement via rake ajoutez une clé deploy_to. Vous pouvez voir l'usage dans le fichier Rakefile.

  6. Editez le contenu, ajoutez un post, etc.

    Si vous voulez éditer un contenu existant (et versionné dans git) le plus simple est d'utiliser gollum :

    wlt gollum

    Puis rendez-vous sur http://localhost:4567/pages

    Vous pouvez aussi éditer le fichier markdown à la main.

    Si vous voulez créer un nouveau post, facile :

    touch _posts/2013-01-29-web-log-today-say-cool.md
git add _posts/2013-01-29-web-log-today-say-cool.md
git ci -m "Add new post"
wlt gollum

    Ha oui, faites attention à un point : gollum commit dans git lorsque vous enregistrez.

  7. Un peu plus loin ?

    wlt serve &
guard

    Comme ça, vous pouvez éditez vos fichiers, et voir le rendu en même temps sans relancer les commandes à la main.

  8. Publication

    Si votre serveur permet de faire du rsync, facile :

    rake deploy

    Et voilà, c'est dispo !

Alors, trop facile, non ?

Mot de la fin

Et voilà, c'est la fin de la prez. Alors, vous voyez bien que le html c'est surfait !

Comme quoi, on part d'un besoin tout bête, faire une page web tout simple, et on arrive à un générateur de site et blog statique top moumoute à base de ruby, markdown et plein de trucs trop cool.

Ha oui, le tout est sous licence BSD, donc faites vous plaisir.

Il reste pas mal de taff, par exemple améliorer vraiment la partie ruby, enfin les objets utilisés côté haml surtout. Et rajouter des tests aussi, j'aimerais bien le blinder de rspec.

Donc voilà, je ne sais pas comment ce petit soft évoluera, la principal étant qu'il répond à mon propre besoin.

Il ne manquerait pas un truc ?

Ha oui, l'url à laquelle trouver tout cela : https://github.com/CrEv/wlt

  • # Pour être cool

    Posté par  (site web personnel) . Évalué à 3.

    Moi j'ai remplacé mon blog dotclear, par Drupal. Ca c'est moderne!

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Pour être cool

      Posté par  (site web personnel) . Évalué à 1.

      C'est pratique mais quand même un poil lourd par moment.

      Je connais aussi, je fréquente depuis un certain temps.

      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # les gens, j'aime les gems

    Posté par  . Évalué à 4.

    Mais pourquoi donc ne pas distribuer la chose sous la forme d'une gem ?
    Cela permettrait une plus grande facilité d'installation (juste gem install wlt) et d'installer la chose dans un endroit standard.

    Sinon c'est de la belle ouvrage.

    • [^] # Re: les gens, j'aime les gems

      Posté par  . Évalué à 10.

      Où y'a de la gem, y'a pas de plaisir.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: les gens, j'aime les gems

      Posté par  (site web personnel) . Évalué à 2.

      Hum, je sais plus trop pourquoi mais j'ai préféré ne pas faire une gem. Pour la facilité, je pense que je vais simplement faire un "oneliner".
      Et aussi j'avais envie d'utiliser sub (oui je sais c'est pas forcément une superbe raison, mais elle me plait quand même)

      Bon après, pourquoi pas une gem un jour…

  • # usine à gaz

    Posté par  (site web personnel) . Évalué à 7.

    C'est un peu compliqué je trouve…

    Pour moi, 2 fichiers php qui servent de moteur, des fichiers textes en txt2tags qu'on envoit sur le serveur, et ça suffit pour monter un blog :

    http://cyoa.hostzi.com/blog/index.php?article=2012-12-07-NewBlog

    la source : http://cyoa.hostzi.com/blog/2012-12-07-NewBlog.blog.t2t

    « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: usineàgaz

      Posté par  (site web personnel) . Évalué à 2.

      On Wed, Jan 30, 2013 at 06:03:17PM +0100, fravashyo wrote:

      C'est un peu compliqué je trouve…

      je suis curieux de voire comment tu genere le rss et le lien vers le zip est mort, peux tu publier ton projet quelque part ?

      • [^] # Re: usineàgaz

        Posté par  (site web personnel) . Évalué à 3.

        si j'étais de mauvaise foi je dirais que c'était l'effet slashdot linuxfr mais en fait j'avais simplement oublié de publier le zip on dirait (ou je l'ai effacé par erreur, ou un vilain pirate a exploité une faille php parce que j'ai eu la mauvaise idée de ne pas avoir un site statique)

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: usine à gaz

      Posté par  . Évalué à 5.

      C'est un peu compliqué je trouve…

      Générer des fichier statiques compliqué ?

      Pour moi, 2 fichiers php qui servent de moteur, des fichiers textes en txt2tags qu'on envoit sur le serveur, et ça suffit pour monter un blog :

      Ca n'a rien de statique ton truc .

      Tu paies l'overhead du PHP pour servir des choses qui n'en ont pas besoin.
      Tu paies le cout de maintenance (c'est dégueulasse les variables dans les .php)
      Tu paies la sécurité d'un truc dynamique. Oh un joli XSS sur ton blog statique…
      Et on peut continuer.

      Non la solution de crEv est très élégante. D'ailleurs je recommande le même genre d'approche pour écrire la documentation dans vos équipe de dev. Dégagez les wiki dont l'UX est assez moisie et remplacez les par ce genre de système. On peut facilement réutiliser tout les outils de dev, de l'éditeur au VCS en passant par l'intégration continue ou grep pour trouver les infos. C'est du coup vachement plus productif. Pour ceux qui aiment pas le Ruby y'a Markdoc en Python qui fait le job.

      • [^] # Re: usine à gaz

        Posté par  (site web personnel) . Évalué à 3.

        Ca n'a rien de statique ton truc .

        je n'ai jamais dit que je recherchais à faire un site statique.

        D'ailleurs si ce n'est que ça, txt2tags est prévu à la base justement pour générer du contenu statique, avec la même source et la commande
        txt2tags -t html --style style.css 2012-1204-NewBlog.blog.t2t

        ça me génère le fichier 2012-1204-NewBlog.blog.html que je peux poser chez n'importe quel hébergeur.

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: usine à gaz

      Posté par  (site web personnel) . Évalué à 2.

      En quoi est-ce compliqué ?
      La version courte de l'usage c'est :

      vi _posts/newpost.md
rake deploy

      Pas très compliqué quand même.

      Et surtout c'est en rien comparable car je parle d'un blog statique ne dépendant que d'un serveur web et non d'un langage côté serveur.

    • [^] # Re: usine à gaz

      Posté par  (site web personnel) . Évalué à 3.

      Markdown (préférablement le vrai, pas la réimplémentation bancale utilisée par DLFP) et mod_autoindex. Tout le reste c'est de la branlette.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Et en Python...

    Posté par  . Évalué à 3.

    …pour ceux qui l’affectionnent particulièrement, il y a Poole qui est du même genre, avec probablement moins de fonctionnalités, mais qui fait l'essentiel et a un système de macros qui rend aisé l'ajout de petits hacks sympathiques.

    • [^] # Re: Et en Python...

      Posté par  . Évalué à 3.

      Il existe énormément de générateurs de site web static, que ce soit en Python, ruby ou [votre langage préféré]. Ils font tous plus ou moins la même chose, certains sont orientés blog, d'autres sont fait pour la doc, mais au final aucun ne convient à 100% (en tout cas pour moi). J'en avais essayé une bonne dizaine avant de me rendre compte que trouver LA solution qui me convienne c'était mission impossible…

      Perso, j'utilise Flask avec deux extensions (Frozen-Flask et Flask-FlatPages), c'est très très fortement inspiré d'un article de Nicolas Perriault. Du coup, aucune contrainte, je choisis mon langage de markup, la structure du site, et tout et tout. C'est-y pas merveilleux :)

      • [^] # Re: Et en Python...

        Posté par  (site web personnel) . Évalué à 3.

        Oui, c'est un peu ça. Il y a plein de générateurs existant. Le truc c'est que c'est qu'ils ne font jamais tout, c'est toujours assez limité pour répondre aux besoins de l'auteur essentiellement et pas pour tous les cas.

        C'est d'ailleurs une raison pour laquelle j'ai développé le mien, ce que j'ai essayé ne faisait pas ce que je voulais (en fait sass et coffee) donc j'ai tout recommencé ;) Faut dire que faire un générateur du genre c'est pas un trop gros boulot.

        Et au final, c'est plutôt cool :)

        • [^] # Ikiwiki

          Posté par  (Mastodon) . Évalué à 3.

          Ikiwiki

          Sur FusionInventory, on a migré sur Ikiwiki. En gros, on a un dépôt git avec des fichiers Markdown qu'on pousse sur le serveur. Le serveur se charge de générer les pages.

          Ikiwiki a trois gros intéret à mes yeux :
          - Il est toujours possible d'éditer les pages et poster des commentaires avec un navigateur Internet
          - branchable.com permet d'être hébergé sans s'embêter
          - et surtout, on peut activer un mode “traduction”, dans ce cas, des fichiers de langue sont générés et ici aussi on peut soit les traduits avec l'interface web, soit avec un client git.

          Au final, on a enfin un site facile a maintenir et surtout simple a traduire !

      • [^] # Re: Et en Python...

        Posté par  . Évalué à 2.

        Je suis d'accord.
        L'idée est donc d'en trouver un qui soit le plus proche de ce que tu veux faire et dans les technos que tu maîtrises ou qui t'intéressent.

        Perso j'aime bien l'approche de qui consiste à utiliser la génération de site statique. Quand l'usage principale est la lecture, c'est très efficace. Cela permet (implique) de dissocier le frontend (lecture) du backend (post, commentaires, etc.). Donc d'avoir une architecture mieux adaptée à l'usage. Par exemple frontend synchrone chez un hébergeur avec une bonne bande passante et une bonne disponibilité et backend asynchrone en auto-hébergement, plus souple.

        Pour ma part, j'ai joué avec jinja2, un peu de sqlite, le tout enrobé de python et j'en ai été très content :)

  • # Commentaires

    Posté par  (site web personnel) . Évalué à 6.

    Super article. Merci.

    J'avoue que les générateurs statiques m'intéresse et m'attire particulièrement. Mais une seule chose freine encore mon envie de sauter le pas : les commentaires…
    Je n'ai pas envie de me priver de commentaires et les sites statiques en sont clairement dépourvus.

    Je comprends bien la problématique de ne pouvoir avoir de commentaire dynamique sur un site statique. Mais les solutions actuelles comme disqus (la plus connu) sont loin d'être digne de confiance…

    J'ai entendu parler de Juvia, mais je n'ai pas encore réussi à tester ça. En plus, ça ne fait pas les commentaires en thread…

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

    • [^] # Re: Commentaires

      Posté par  . Évalué à 2.

      J'avoue que les générateurs statiques m'intéresse et m'attire particulièrement. Mais une seule chose freine encore mon envie de sauter le pas : les commentaires…
      Je n'ai pas envie de me priver de commentaires et les sites statiques en sont clairement dépourvus.

      Pour les commentaires, David Larlet utilise une solution à base de mailing list. C'est expérimental et je ne sais pas trop si ça fonctionne bien (comprendre : est-ce qu'il y aurait plus de commentaires avec un système classique ?). En tout cas, ça sort de l'ordinaire et c'est une idée originale.

      • [^] # Re: Commentaires

        Posté par  (site web personnel) . Évalué à 2.

        J'avais vu ça, mais je trouve ça plutôt étrange. Entre autre le fait que les commentaires sont externalisés même pour leur consultation. C'est plutôt étrange, déroutant, et j'en vois pas bien l'intérêt.
        Mais c'est vrai que ça a le mérite d'être original.

    • [^] # Re: Commentaires

      Posté par  (site web personnel) . Évalué à 5.

      Ha, les commentaires…
      Pour ma part je ne veux pas de disqus (pour tout un tas de raisons, en premier lieu la possibilité de recoupement et les infos que disqus peut avoir)

      Ensuite, je ne veux pas non plus de solution équivalente pour d'autres raisons, par exemple le fait que les commentaires ne font pas partie de la page mais sont en général chargés par iframe. Résultat, pas d'indexation par exemple.

      Je suis en train de chercher quelques solutions, l'objectif étant que les commentaires soient aussi générés par wlt, donc dans l'html généré. Evidemment cela demande des opérations manuelles (la génération est commandée manuellement pour moi) et donc une modération des commentaires. Mais en général, c'est préférable (pas de spam, pas tant de commentaire que ça donc pas trop de taff).

      Le problème est que tout cela nécessite une composante serveur. Par contre, le but est de l'externaliser, que ce soit un composant indépendant du site et de l'affichage, que ce soit mutualisable.
      Donc au final, l'idée (non implémentée pour le moment, j'ai pas eu le temps) est de jouer beaucoup avec git : un formulaire qui pointe sur une partie serveur externe. Le commentaire écrit est transformé… en commit dans une branche dédiée à la page (le commentaire devient une portion de markdown dans un fichier lié à la page, tous les commentaires d'une même page dans une même branche)
      Il faut juste rajouter un petit outil dans wlt pour pouvoir choisir les commentaires (commits) à publier. Les infos genre adresse mail est dans le message de commit.
      Il ne reste donc qu'à merger les contenus (les commentaires) et deployer la version générée.
      En gros, le principe est un peu le même qu'une pull request, le commentaire étant vu comme un ajout au post.

      Bon, je sais pas si c'est clair, ni si ça peut vraiment fonctionner, mais ce sera à tester lorsque j'aurai le temps…

      • [^] # Re: Commentaires

        Posté par  (site web personnel) . Évalué à 2.

        Bon, je sais pas si c'est clair, ni si ça peut vraiment fonctionner

        Bien sûr! Il y a même des tordus qui, de la même façon, détournent un gestionnaire de version pour en faire une messagerie distribuée: http://devnewton.bci.im/home/?q=node/25

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Commentaires

          Posté par  (site web personnel) . Évalué à 3.

          Ha oui, c'est vrai que ce qui est bien dans l'informatique c'est que quand tu penses avoir une idée un peu tordue, tu peux être certain que quelqu'un a déjà eu une idée… beaucoup plus tordue ! ;-)

      • [^] # Re: Commentaires

        Posté par  . Évalué à 3.

        Je sais pas si ça peut t'intéresser, mais le coup du site statique avec des pages « dérivées » (y compris pour commentaires, si on veut) qui seraient enregistrées dans des branches à part en git, et donc sur une autre partie « dynamiques », je l'expérimente dans un projet à moi qui est un peu inactif en ce moment : http://dolka.fr/code/gitollion.git

        C'est aussi basé sur des technos « modernes » mais je voulais faire beaucoup plus simple : utiliser Sphinx pour ne pas avoir à réinventer un système de publication (même s'il est un peu trop orienté documentation parfois), git pour le versionning, et Pyramid pour la partie dynamique. Bon en fait, je triche, je ne sers pas vraiment de fichiers « statiques » directement, mais des blob git qui peuvent leur correspondre, mais ça revient quasiment au même. Ah, et c'est plutôt orienté wiki, moins blog.

        Et pour l'instant, c'est pas documenté ni décrit nulle part, donc bon courage ;-)

        • [^] # Re: Commentaires

          Posté par  (site web personnel) . Évalué à 2.

          L'utilises tu publiquement quelque part ?

          • [^] # Re: Commentaires

            Posté par  . Évalué à 2.

            C'est en « prod » sur http://grifon.fr/ mais ça n'est pas encore du tout adapté à la contribution dynamique, car beaucoup trop buggé (c'est surtout un premier jet). On l'utilise là-bas surtout comme dépôt git multi-version avec génération automatique du HTML.

            J'ai fait assez attention à séparer les différentes parties du projet : il y a le script qui sert à garder un dépôt git « parallèle » à un autre pour du contenu généré (le HTML sorti par Sphinx), et le « reste » qui peut être divisé entre la partie (très simple, en gros un git cat-file amélioré) qui sort les blobs en fonction des requêtes HTTP, et la partie « dynamique » qui stocke les modifications du wiki par commit en git.

      • [^] # Re: Commentaires

        Posté par  . Évalué à 0. Dernière modification le 02 février 2013 à 01:21.

        Il me semble que ce sont deux choses tout à faits distinct.

        L'un c'est du contenu statique, que tu peux te permettre si ça te plait, de compiler.
        L'autre, les commentaires, sont tout à fait dynamique, et ce serait assez ouf de re compiler le site, re déployer, a chaque nouveau commentaire.
        Ou alors, il faut partir sur des système à wake up régulier, mais cela implique pour l'utilisateur que son post n'est pas instantané.
        Sachant qu'en plus tout l’intérêt de la compilation et de balancer le site on the CDN, cela commence à faire beaucoup de latence pour des fonctions que l'on sait très bien faire aujourd'hui avec des langages cote serveur.

        Bref, j'ai pris partit de ne pas mélanger ces deux choses. Elles ne sont liés que par l'ui, et l'ui m'offre pléthore de solution pour mixer le compiler et le JIT selon les besoins de la fonctionnalité.

        désolé pour les fautes toousa.

        • [^] # Re: Commentaires

          Posté par  (site web personnel) . Évalué à 3.

          mais cela implique pour l'utilisateur que son post n'est pas instantané.

          ce qui est de toute façon le cas avec des commentaires modérés…

          des fonctions que l'on sait très bien faire aujourd'hui avec des langages cote serveur.

          auquel il faut rajouter un moyen de persistance qui serait en doublon avec mon git

          tout l’intérêt de la compilation et de balancer le site on the CDN

          hum, non. en tout cas pas directement
          L'intérêt premier est que c'est plus cool à gérer qu'un logiciel côté serveur. Ensuite c'est beaucoup plus sympa en terme de gestion serveur car pas de langage. Je peux donc déplacer mon domaine et son contenu très facilement.

          Mais le but est au contraire de traiter les commentaires comme du contenu venant enrichir le contenu initial.

          • [^] # Re: Commentaires

            Posté par  . Évalué à -1.

            Oui effectivement cet exemple de commentaire est un peu tendancieux en ta faveur.

            Si je prenais plutôt un exemple sur une fonction qui utilise le temps, ou le statut de l'utilisateur pour modifier le contenu.
            Cela impliquerait que tout une logique soit déplacé,
            - ou dans la vue, cf ta problématique
            - ou côté serveur, ma position

            At least une bonne raison de le placer côté serveur est de contrôler les accès.
            Car placé dans la vue c'est permettre à tout a chacun d'accéder ce contenu.
            Hors il est des cas où ce comportement n'est pas désiré.

            auquel il faut rajouter un moyen de persistance qui serait en doublon avec mon git

            Effectivement une base de donnée, serait un doublon.
            Mais si tu voulais garder uniquement une base de fichier, ta base de données pour les commentaires, serait donc un fichier compilable.
            Genre une liste ul > li, je sais pas.

            Dans ce cas là, la compilation générerait plusieurs versions des commentaires
            - une version public avec tous les commentaires modérés
            - une version privée, avec modération des commentaires

            Après avec e-tag facile à générer pour le coup, c'est très agréable à hoster.

            En tout cas, cette idée de prendre le fichier comme base de stockage, et de développement me semble forte intéressante à moi aussi.

            • [^] # Re: Commentaires

              Posté par  (site web personnel) . Évalué à 2.

              Si je prenais plutôt un exemple sur une fonction qui utilise le temps, ou le statut de l'utilisateur pour modifier le contenu.

              Ha oui, mais là on est vraiment dans quelque chose de totalement différent. D'ailleurs de mon point de vue je fais de la publication simple, il n'existe même pas d'utilisateur…

              une bonne raison de le placer côté serveur est de contrôler les accès.

              Heu, justement, je ne contrôle pas les accès, c'est ouvert (les sources sont même publiques)

              ta base de données pour les commentaires, serait donc un fichier compilable.

              Oui, les commentaires seraient un fichier qui est inclus dans la génération, aucune vrai différence avec un billet.

              la compilation générerait plusieurs versions des commentaires
              - une version public avec tous les commentaires modérés
              - une version privée, avec modération des commentaires

              Oula non. Mon idée (pas encore implémentée faute de temps) est juste d'utiliser git comme base de données. Les informations du commentateur (email par exemple) seraient dans les données du commit. Le commentaire serait le contenu du commit. la modération se fait alors en cherry-pickant / fusionnant les commits ou non.
              Git est donc l'outil de modération et de "base de donnée".

              Par contre, je ferai tout ça dans un autre dépôt, pas question d'avoir cela en publique.

  • # Recherche

    Posté par  . Évalué à 2.

    Je n'ai pas vu de fonction recherche.

    C'est assez simple à rajouter même pour un site statique tant qu'il n'y a pas trop de contenu.
    Par exemple, Sphinx construit un index de recherche lors de la compilation. Pour effectuer une recherche, il y a un script qui charge l'index, construit la requête et charge les résultats. J'ignore s'il y a des équivalents écrits en ruby (pour l'indexation) mais l'approche et le code javascript doit être réutilisable.

    • [^] # Re: Recherche

      Posté par  (site web personnel) . Évalué à 3.

      En effet, il n'y a pas de fonctionnalité de recherche. Franchement j'en ai pas du tout vu l'intérêt. Il m'arrive assez peu d'utiliser les recherches sur les blogs (et google est plutôt bon en général…)

      Mais ça reste une piste d'amélioration, faudrait que je regarde plus en détail ce que fait sphinx.

  • # Merci

    Posté par  . Évalué à 2.

    Encore une fois un journal de qualité.
    Merci à toi pour le partage, c'est un plaisir de te lire et de découvrir tout ce petit monde.

  • # Migration contenu dotclear wiki2xhtml vers markdown

    Posté par  . Évalué à 0.

    Petite question : Si tu es parti d'un blog dotclear vers un contenu au format Markdown, tu as sûrement dû être confronté à un problème de migration du contenu dotclear (au format wiki2xhtml) vers Markdown. Si oui, comment l'as-tu résolu ? Je suis à la recherche d'un script de migration. Je n'ai encore rien trouvé de pertinent et n'ai pas encore pris le temps de le faire. J'ai testé rapidement le script présent dans Pelican mais il n'est pas parfait (chez moi, il n'arrive pas à migrer les liens, ne récupère pas les tags, …).

    Merci,

    • [^] # Re: Migration contenu dotclear wiki2xhtml vers markdown

      Posté par  (site web personnel) . Évalué à 2.

      Nope. Mon dotclear existe toujours, j'ai choisi de ne rien migrer. De toute façon je n'aurais pas pu garder les mêmes urls par exemple. Et je n'en ai pas vu vraiment l'intérêt.

      Mais si je devais le faire, je pense que je m'arrangerais simplement pour récupérer les contenus des articles en html (ça doit être faisable sans trop de problème) et je les transformeraient en pages html statiques à placer dans _pub. En gros. Mais bon, je pense que je ne le ferai jamais.

    • [^] # Re: Migration contenu dotclear wiki2xhtml vers markdown

      Posté par  . Évalué à 1.

      J'ai testé rapidement le script présent dans Pelican mais il n'est pas parfait (chez moi, il n'arrive pas à migrer les liens, ne récupère pas les tags, …).

      Pour Pelican (et pour avoir écris une partie du script en question pour le support de dotclear ;-)):

      • c'est basé sur pandoc pour la conversion html → rst/md, ca marche normalement pas trop mal même si c'est pas parfait, mais ça m'étonne que tu ai des problèmes avec les liens ? Je suis pas sur qu'il y ai moyen de faire mieux, à part écrire un convertisseur pour la syntaxe wiki de dotclear.
      • les tags sont gérés (ca a été ajouté il y a 1 an 1/2) donc il y a peut-être un problème, si tu veux un coup de main pour débogger …

  • # une question comme ca

    Posté par  . Évalué à 1.

    Tu ne trouves pas que c'est un peu dommage de rajouter cette étape de compilation autour de ces langages de bases qui depuis toujours ont fais la part belle à l’exécution JIT ?

    Les outils choisit sont probablement très bien, mais je ne peux m’empêcher de penser qu'il y à perte d'un acquis.

Suivre le flux des commentaires

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