Blog about chtijs.francejs.org

[0gust1]

1 - c'est juste une possibilité que j'avais testé. On peut aussi créer un dossier avec le nom que l'on veut. Par contre, ce nom sera dans l'URL. Pour le tri "chronologique" des billets, je pense qu'il vaut mieux se baser sur une metadata date, au format ISO à écrire dans les fichiers md, indépendemment du nom du dossier dans lequel l'article se situe.

2 - Je suis plutôt partisan de la première solution. C'est ce qu font plusieurs générateur de sites statique que j'ai essayé. Les fichiers HTML sont générés avec marked, et on se fait une fonction qui scanne les metadata et renvoie un objet trié et itérable pour générer la liste des posts.

3 - C'est mieux de se garder la possibilité de poster d'autres choses que des comptes-rendus de rencontre, je pense. Si motivation il y a, on peut imaginer de petits billets de veille, d'actus (autres confs JS / Web par ex).

Ce serait bien d'avoir du RSS aussi, tiens. ça devrait pas être compliqué si on a géré une liste chrono d'articles.

[neemzy]

C'est une question que je me posais, justement : est-ce qu'on écrira des articles pour le site, ou est-ce qu'on fait ce truc de câbler les catégories JS de nos blogs respectifs pour que les articles ressortent ? Notons que l'un n'empêche pas l'autre, au demeurant.

(Concernant la seconde solution, je suis preneur d'infos d'ailleurs parce que j'ai pas encore implémenté les tags sur mon blog... Je dois câbler une URL qui renvoie du JSON, un truc comme ça ?)

[nfroidure]

Si on veut faire un planète des catégories JavaScript de nos blogs (perso, je suis pour), on peut le faire en statique, mais ça veut dire que ça changera qu'à l'occasion d'un update. Ça peut faire le job dans un premier temps.

Je veux bien me mettre sur la scan, à moins que l'un d'entre vous le souhaite ?

[nfroidure]

@0gust1 pour les billets, si on met la date dans les metas, ça serait peut-être plus simple de virer les dossiers et ce nommer les fichiers en rapport avec le titre (genre rencontre-chtijs-1.md). Vu qu'il y a peu de chances pour que le cas où deux billets de blog soient publiés le même jour, on aura autant de dossiers que de fichiers dans un cas comme dans l'autre. Qu'en penses-tu ?

Par contre, je propose de numéroter les billets (genre 1-rencotnre-chtijs-1.html) pour qu'on puisse facilement savoir l'ordre des billets vu depuis le dossier. Pour simplifier, en revanche, rien n'empêche de faire un watch sur le dossier pour préfixer automatiquement les billets avec un ID incrémenté en cas d'ajout d'un fichier md (un peu comme avec les fontes).

[nfroidure]

Bon, j'ai fait un essai rapido, dîtes moi ce que vous en pensez.

[0gust1]

Bon, je reprends un peu de service :)

@nfroidure : je suis pas sûr de bien comprendre. Tu proposes de virer les dossiers ?
Les dossiers nommés en fonction de la date c'est pas top, on est d'accord. Par contre, avoir 1 dossier = 1 article permet de mieux gérer le contenu et les choses associées (médias dans l'article, CSS, JS spécifiques).

La plupart des générateurs de sites statiques proposent une tâche Grunt ou Yeoman de "création de nouvel article". Une fois lancée, on entre un "titre" pour le nouvel article, un nouveau dossier est alors créé, avec pour nom le "titre" précédemment saisi (et rendu URL "friendly").

[nfroidure]

@0gust1 j'avais pas pensé aux contenus associés. Par contre, est-ce vraiment leur place ? Ou alors, les mettres dans les bons dossier uniquement dans l'arbo générée ? Je manque de recul là-dessus.

[0gust1]

Je manque de recul là-dessus

Moi aussi :). Je m'étais dit "ouais, finalement on en a pas besoin (des dossiers), vu le peu de contenu" et puis quand j'ai vu ton commit : "ah oué, ça fait déjà pas mal d'articles déjà, en fait, peut être que c'est plus justifié (les dossiers)".
Sinon, à titre perso, je trouve la solution des dossiers simple et élégante du point de vue des URLs, mais je n'y suis pas cramponné.

[0gust1]

@neemzy pour syndiquer les contenus externes... RSS ? Mais faut trouver une lib JS qui parse ce genre de trucs. ça me redonne envie de relancer un blog perso/dev, tiens... :)

[neemzy]

J'suis pas fan du RSS personnellement, mais il faut bien reconnaître que c'est un standard pour ce genre de choses ; de plus pas mal d'entre nous l'auront potentiellement déjà implémenté. À aborder à la table ronde :)

Pour le parsing, je vois deux options :

• côté client (via AJAX) mais ça va peut-être être lourdingue, non ?
• à la génération (via Grunt), probablement plus propre mais pas automatique

[nfroidure]

@neemzy côté client c'est impossible (enfin, difficilement possible) car les flux RSS/ATOM sont rarement valides XML et on ne peut donc pas les charger avec responseXML /o.

Il faudrait chercher un module équivalent à SimplePie pour PHP. Sinon, il reste la possibilité d'utiliser le module SAX pour parser les fichiers ATOM/RSS (SAX est vendu comme XMLdemerde-proof) mais gros morceaux quand même. Je serais étonné que rien n'existe dans ce sens.

Par contre, browserify pourrait nous aider à faire un truc client et server (le module SAX est browserifiable). Comme ça quand on génére le site avec Grunt, on met à jour les fichiers statiques avec les derniers posts et côté client, on rafraîchit pour voir si y'a rien eu entre temps. Yeah, encore un use case de Browserify :D.

[neemzy]

Ah oui bonne solution, ça me paraît bien ! Je connais pas du tout SAX par contre.

[nfroidure]

Lo, juste pour info, y'a plusieurs lecteur de flux basés sur Sax déjà existants : https://npmjs.org/browse/depended/sax

Pour le lecteur de flux côté client, la principale difficuté sera de faire des XHR cross-domain.

Soit on utilise les entêtes HTTP dédiées, mais ça me paraît un peu tendu de demander à chaque membre de ChtiJS d'ajouter des entêtes Access-Control-Allow-Origin pour qu'on puisse lire leur flux.

Soit on le fait côté serveur, et du coup, le site statique prend du plomb dans l'aile.

[neemzy]

Au pire, perso je blogue pas tous les deux jours, je sais pas vous... Qui aura la main sur la mise à jour du site en prod ? Je ne sais plus bien ce qu'on s'était dit sur l'hébergement, mais il serait peut-être possible d'avoir un rebuild automatique quotidien (par exemple), même partiel, afin de choper les éventuels nouveaux articles ?

[nfroidure]

Je dois pouvoir trouver une place sur un de mes srv pour refaire le build à intervalle régulier.

[neemzy]

Cool ! Ça peut se faire en appelant une URL donnée, un truc du genre ?

[nfroidure]

Je pensais à une tâche cron toute bête du style :

git clone [email protected]:chtijs/chtijs.francejs.org chijs
cd chtijs
npm install --dev
grunt dist
cp www www-tmp -R
git branch gh-pages
rm -r www
mv www-tmp/* .
rmdir www-tmp
git commit -a -m "Site updated"
git push
cd ..
rm chtijs -r

[neemzy]

D'accord ; j'ai lu un article sur les GitHub Pages entretemps donc je pige mieux la manoeuvre. Bien joué :)

[nfroidure]

On a finalement renoncé au blog.