Fichiers Markdown et metadata about chtijs.francejs.org

[nfroidure]

Ne serait-ce pas plus simple de faire un fichier meta-data à part ?

[0gust1]

Oui, pour le développement (et encore, car il faudra bien résoudre l'association fichier md <=> fichier metadata).
Mais pas pour l'édition de contenu. Comme les metadata concernent le contenu, ça me semble plus propre et plus simple (coté utilisation quotidienne et maintenance) de les avoir dans le fichier markdown.

Je vais refaire un tour des solutions existantes ce soir, le sujet m'intéresse.

[nfroidure]

En markdown, y'a moyen de "commenter'" une partie du document ?

[victordarras]

Si je me souviens bien on peut le faire de la même manière qu'avec html :

<!-- plop -->

En fait les parseurs de Markdown devraient accepter du html valide au sein de Markdown normalement, les commentaires aussi :)

[nfroidure]

Par contre, le commentaire apparaît dans le HTML généré j'imagine ? Sinon si y'a une option pour le virer, j'ai peut-être une solution homemade en utilisant le format vartstream.

<!--
meta.title=Bienvenue sur ChtiJS !
meta.description=ChtiJS, le groupe des devs JS !
meta.keywords.+=JavaScript
meta.keywords.+=Nord
meta.keywords.+=Lille
-->

# Hello world !
Kikooolol !

VarStream ignorera toutes les lignes sauf celles qui sont OK. Petit PoC http://jsfiddle.net/dnWLv/

Avec node, ça donnerait :

var VarStream = require('varstream')
  , Fs = require('fs');
var obj = {};
Fs.createReadStream('mon/fichier/markdown.md').pipe(new VarStream(obj, 'meta'));
console.log(obj.meta);

Edit: Au pire, on peut faire un stream.Transform qui filtre et ne renvoie que les commentaires avec un certain préfixe à VarStream.

[0gust1]

En markdown, y'a moyen de "commenter'" une partie du document ?

En markdown (et c'est la classe), tu peux directement écrire du HTML; donc les commentaires html, c'est ok (et toutes les autres balises aussi).

Vite fait, des package intéressants, à utiliser ou pour s'inspirer :

https://npmjs.org/package/markdown-meta

https://npmjs.org/package/meta-marked

https://npmjs.org/package/markdown-to-json (paquet très mal nommé : il extrait des metadatas formattées en YAML au début d'un fichier markdown et renvoie du JSON).

Ce packet a des options sympa dans l'optique site web / gestion de billets d'actu :

*Markdown YAML front-matter to JSON*

m2j.js is used to read a folder of Markdown files, pulling out the YAML front matter from each, and saving it all as a JSON object.

This is especially useful if you have a folder full of Markdown files that you want scanned and processed into a singl JSON file, which can then be consumed by Angular on the client, cached in a Node server, or saved in a nosql database.

In addition to moving the YAML to JSON, a few extra elements are created:

*iso8601 formatted from date using Moment.js
preview is first 70 or so characters of the actual raw markdown content, with ellipses at the end
basename is the filename without the path or extension*

[neemzy]

Petit HS pour conseiller de proscrire la meta keywords, elle a carrément un impact négatif sur le SEO x)

[nfroidure]

J'avais ajouté les keywords plutôt dans l'idée de générer un "tag cloud" au besoin. Par contre, j'aurai mis les méta keywords vu que ça coûte rien et que certains outils les utilisents (partage de liens etc..). Tu as des ressources qui indiquent un effet négatif ? Jusque ici, je pensais que cela n'avait aucun effet positif uniquement.

[neemzy]

À vrai dire oui (attention) : http://fr.wikipedia.org/wiki/%C3%89l%C3%A9ment_meta#L.27attribut_keywords_.28mot-cl.C3.A9.29

Par contre en le relisant, je ne le comprends pas pareil que la première fois, et en cherchant un peu à côté j'ai des infos contradictoires, donc je suis pas si sûr de ce que j'avance en fait (ne serait-ce que sur le fait qu'ils sont pris en compte ou non).

Bref, désolé pour le HS 👯

[flexbox]

@neemzy Pas si hors sujet
La meta keywords est totalement ignorée
Perso dans mes sites je ne la met JAMAIS. 😄

@nfroidure Bonne idée mais multiplier les sources de navigation donne une dilution du page rank de tes pages vers tes autres page.
ex : faire un menu de navigation avec des catégories + une navigation par keyword c'est mauvais. Il vaut mieux choisir soit l'un soit l'autre.

[neemzy]

@flexbox Pour le coup c'est moi qui ai un doute ; en termes de maillage interne, c'est pas mieux justement de privilégier la quantité (intelligemment bien sûr) ?

[nfroidure]

Je pense qu'il faut voir les choses en terme de navigation plutôt qu'en terme de SEO. Pour moi, le SEO vaut pas la peine d'être pris en compte vu qu'on peut même plus le mesurer (Not provided) et que quand bien même tu es premier, tu ne l'es pas vraiment (Adwords).

Dans tous les cas, ça m'étonnerait qu'on soit pas premiers sur ChtiJS, ce qui est je pense la seule chose qu'on vise ;).

Je pense qu'il vaut mieux miser sur l'expérience utilisateur, la clarté etc... Et de ce point de vue, un petit nuage de mot-clé apporte un type de navigation différent par centre d'intérêt, donc, pourquoi pas.

Je vais regarder le commit de @0gust1 aujourd'hui.

[neemzy]

👍 ça clôture bien cette discussion sur le SEO (désolé encore une fois pour le HS engendré) :)

[0gust1]

Holà, la compagnie,

Je vous invite à checkouter (ou mettre à jour) votre copie locale du master. La génération statique est mise en place. Tout est prêt pour commencer à attaquer la forme et le contenu du site, sur du concret.

PS : le gruntfile est loin d'être propre ou DRY, je suis vraiment allé au plus vite. Si vous vous sentez l'âme de nettoyer un peu, aucun souci.
PPS : l'inclusion des métadata liées au fichiers markdown n'est pas encore en place. J'ai fait une rapide tentative avec Varstream, mais je n'ai pas réussi à le faire proprement (sans ouvrir 2 fois les fichiers markdown).

[nfroidure]

@0gust1 je vais m'y coller.

[neemzy]

Si ça peut aider pour le Gruntfile : cowboy/wesbos@5a2980a

[nfroidure]

6bb4490

Dîtes moi si ça marche pour vous (hésitez pas à faire un npm update/install).

[0gust1]

Bon, je peux pas vérifier là (chui au taf), mais merci @nfroidure !

@neemzy : Oui, j'ai vu passer hier chez Ben Alman. Je suis pas très fan de ce genre de découpage "tasks based" (sauf peut-être pour des projets très techniques du type bibliothèque JS), je préfère faire un découpage par fonctionnalité, via le .merge() de lodash ( du genre : https://gist.github.com/0gust1/7683132 :) ).
Au niveau du gruntfile, ce qui me chiffonne, ce n'est pas tant la longueur mais plutôt la répétition à outrance des mêmes paths au sein des tasks.

Mais bref, pour l'instant c'est pas super important, l'essentiel est d'avoir un process de build et un process de dev qui marche, pour avoir un site très vite ;)

[nfroidure]

Le sujet du thread est traîté, je ferme le ticket ;)