Générateur de site statique

0gust1 commented 10 years ago

Quel système de générateur de site statique ?

De mon coté, j'ai un peu joué avec wintersmith, mais plusieurs trucs m'y dérange pour chtiJS :

C'est écrit en Coffeescript
ça s'installe bizarrement, je trouve (ça s'installe au global)

Du coup, je comptais regarder du coté de grunt-assemble, voir s'y on y retrouve les mêmes possibilités.

nfroidure commented 10 years ago

Je ne comprend pas le besoin de générateur de site statique puisque nous avons Grunt ? N'est-il pas possible simplement de faire une tâche de ce genre ?

{ tpl:
  main: {
    src: "/documents/pages/**/*.tpl",
    dest: "/www/",
    ext: '.html"
  }
}

0gust1 commented 10 years ago

Yep.

neemzy commented 10 years ago

Testé et approuvé par @victordarras ce week-end pour son site perso ;) Je plussoie !

0gust1 commented 10 years ago

Je ne comprend pas le besoin de générateur de site statique puisque nous avons Grunt

Un générateur de site statique c'est juste ça, un plugin grunt en général, où une tâche perso. Au départ je posais juste la question d'utiliser un plugin grunt dédié.

J'ai une branche qui lit les fichiers markdown, les convertit en HTML et emballe le tout (via nunjucks, mais tout autre système est possible). Je la commite ce soir ?

nfroidure commented 10 years ago

Ça sera une base de départ, je suis pour.

flexbox commented 10 years ago

+1 pour moi aussi (perso j'utilise middleman pour faire la même chose mais c'est du ruby on rails)

neemzy commented 10 years ago

:+1:

0gust1 commented 10 years ago

Hop, j'ai commité une branche hier soir ( feature/build ).

J'ai travaillé la génération html de fichiers markdown, le système de build et l'environnement de dev (avec livereload). C'est assez brut de décoffrage (certaines parties devraient être plus "propres"), mais ça marche.

Testez de votre coté, et si c'est OK, je resynchroniserais et commiterais ce soir sur le master.

git checkout --track origin/feature/build pour rapatrier la branche et la déplier dans votre espace de travail.

grunt dev et grunt dist pour tester.

Pour la suite, j'aimerais gérer la partie "syntax highlighting " et une partie "metadata" dans les fichiers Markdown. ça nous permettra d'injecter différentes données au niveau de la page générée (auteur(s), titre, mots-clefs, feuille de style, fichier js, etc...), directement depuis le contenu. Il y a des plugins qui font celà (https://npmjs.org/package/markdown-extra ou https://npmjs.org/package/meta-marked par exemple), C'est aussi faisable à la mano (exemple en Coffeescript : https://github.com/jnordberg/wintersmith/blob/89d74509edaf8893a5de4a41bbfb8d29c7e93b49/src/plugins/markdown.coffee).

---
title: titre de l'article
author: Nicolas Froidure
date: 2012-12-12 12:12
---

# Exemple d'article

## Blah blah

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua.

flexbox commented 10 years ago

Si tu veux test avec du vrai contenu je me permet de mettre mon article ci dessous :

---
title: Revue de livre javascript
author: David Leuliette
date: 2013-11-02 13:46
---

# Javascript par nicolas froidure

Si vous suivez mon activité sur [twitter](http://twitter.com/_flexbox) vous avez surement remarqué que je lis énormément de livres sur l'industrie du développement web. Mon dernier livre ? Javascript™ rédigé intégralement en français par monsieur Nicolas Froidure himself.
Cet article présente ma revue de la version poche, ainsi que le contenu que j'ai retenu de ces 400 pages de code.

## Le format poche

Pour commencer, j'ai trouvé le format poche (ou tablette 9') génial. Il se glisse partout et vous pourrez facilement le sortir pour passer le temps.

Il m'a fallu un peu plus d'un mois pour parcourir l'intégralité des 12 chapitres consacré au langage Javascript : rappel des fondamentaux, travailler avec des objets, utiliser des tableaux, les API HTML5, nodeJS ...

Le fil rouge de l'ouvrage est la création d'un jeu de memory. Ce concept permet de présenter une utilisation concrète dans un environnement de développement contrairement à une présentation aléatoire de [snippet]() divers et variés. L'intégralité du code source est disponible sur [github](http://github.com/nfroidure). Vous pouvez aussi [tester directement](http://memory.insertafter.com) le rendu final du jeu.

## Contenu

L'objectif du livre est de guider pas à pas les lecteurs en expliquant chaque notion simplement.

- Structure d'un fichier Javascript : variables, instructions et expressions.
- L'appel aux fonction et leur effet de retour (callback).
- La gestion des erreurs.
- La notion d'objet avec une explication des concepts de constructeur, d'instance, de prototype, d'héritage ...
- La manipulation de chaîne de caractères et les [expressions régulières](regexp).
- Les calculs à l'aide de l'objet Math.
- Utilisation des tableaux.
- Les méthodes dates & les fonctions natives de Javascript.
- Coder dans le navigateur et comprendre le DOM.
- Le chargement de contenu distant avec XMLHttpRequest, et leur transport via JSON.
- Les API HTML5 (TouchEvent, Camera, appcache, ...)
- Créer des applications interactives et participatives avec NodeJS. 

## Ce que le front-end dev a retenu

Le Web évolue rapidement. Les intégrateurs ont été majoritairement touchés par les changements récents dans les techniques et les approches de codage. En 2003, un intégrateur compétent maîtrisait HTML et CSS, avec un peu de copier-collé JavaScript. Nous avons construit des sites web qui étaient consultés sur des ordinateurs de bureau.

Mais nous sommes en 2013 ! Maintenant, un développeur Web front-end compétent baigne dans HTML et CSS, JavaScript et jQuery, les preprocessors CSS ..., la complexification des interfaces demande une certaine maîtrise de Javascript.

Comme expliqué dans l'introduction de ce livre j'ai appris Javascript plutôt par obligation, mais aussi par curiosité, sur le tas. Mon niveau est toujours proche du néant mais je me [débrouille mieux](http://pokemonbreakpoint.fr) Je me considère plus comme un utilisateur de Framework que développeur JS. Les 200 premières pages sont et resteront toujours obscures à mes yeux mais cela permet de connaître l'origine de certaines librairies qui sont -trop souvent- incluses sans forcément en avoir besoin (Les 250 Ko de jQuery par exemple)

J'ai découvert grâce à ce livre pas mal de notions :

- `console.trace()` pour dépiler toute votre stack JS
- `document.getElementByTagNames()` pour récupérer une liste d'élément ayant un nom de balisage précis. `.is()` en jQuery c'est tout de suite plus simple.
- Créer des applications web hors-ligne à l'aide d'un fichier .manifest
- Les Touch event mdn API HTML5 et son équivalent `pointerEvent` pour les technologies Microsoft.
- NodeJS : Créer un serveur et utiliser `npm`

## Pour le prochain Tome

> Javascript c'est un peu comme les échecs. Dès que l'on maîtrise les règles, on se rend compte qu'on ne sait pas jouer
>
> David Leuliette

Ce livre permet de vous enseigner/de revoir les bases de ce langage mais je trouve qu'il manque certains chapitre entièrement dédiés concernant :

- Les conventions de codes
- La performance qui devient vite critique sur les grosses applications

Mais ces 2 sujets méritent des livres entiers rien que pour eux. Il existe aussi une version normale du livre avec des bonus comme 

- La performance
- Les design patterns
- Les frameworks
- La boite à outils du développer Javascript

J'attends avec impatience la version 2 !

Si Javascript vous interesse rapprochez vous de l'initiative FranceJS qui regroupe de nombreux développeurs talentueux à travers toute la France.

Dans ch'nord nous avons [@chtijs](http://twitter.com/chtijs) qui organise régulièrement des rencontres. N'hésitez pas à venir rencontrer les fondateurs [@nfroidure](http://twitter.com/nfroidure) et moi même.

0gust1 commented 10 years ago

Cool ! Je t'invite à commiter le fichier sur la branche (dans documents/contenu/) et à tester un petit peu (notamment l'ajout d'image via le markdown)

Pour définir des metadatas dans le markdown, il y a pas mal de solutions. Je n'ai pas eu le temps de regarder et d'analyser. J'ai ouvrir une "issue" sur le sujet.

neemzy commented 10 years ago

Au fait, question con : HappyPlan (ce que les gars de putaindecode ont écrit et utilisé pour leur site) n'était pas une option envisageable ? Pourquoi ?

nfroidure commented 10 years ago

Toutes les options étaient envisageables :). Moi j'aime bien l'idée de se faire un truc custom pour pouvoir justement creuser le sujet. Un truc complètement packagé nous aurait rien appris finalement.

neemzy commented 10 years ago

OK, c'est une excellente raison :) Ils ont probablement eu la même réflexion d'ailleurs !

nfroidure commented 10 years ago

Par contre, si on résume, la solution de @0gust1 semble bien. Il nous reste quoi à faire à part les textes et le design pour avoir un truc potable ?

flexbox commented 10 years ago

Du contenu incroyable :)

J'ai 2 questions con :

Ca fonctionne les fichiers de settings en .yml ? du genre https://github.com/flexbox/webcitation/blob/master/data/settings.yml Ce serait beaucoup plus simple pour gérer le contenu dans des fichiers team.yml, social.yml une simple boucle et hop notre contenu est généré :)

.less c'est obligé ? J'ai essayé de refactor un peu ... mais compliqué j'ai plus l'habitude du sass / scss ça vous dis pas de changer de crèmerie ?

Le 6 décembre 2013 15:21, Nicolas Froidure notifications@github.com a écrit :

Par contre, si on résume, la solution de @0gust1https://github.com/0gust1semble bien. Il nous reste quoi à faire à part les textes et le design pour avoir un truc potable ?

— Reply to this email directly or view it on GitHubhttps://github.com/ChtiJS/chtijs.francejs.org/issues/4#issuecomment-29997394 .

David Leuliette Front end Developer

http://davidleuliette.com

neemzy commented 10 years ago

Perso je préfère le LESS (et oui, je compte participer !) ; si vraiment c'est gênant pour certains, Stylus peut être un bon compromis avec sa syntaxe souple :)

0gust1 commented 10 years ago

@flexbox : pour les fichiers yaml, c'est carrément possible je pense ;) => http://gruntjs.com/api/grunt.file#grunt.file.readyaml

Je suis plutôt pour, c'est moins lourd à éditer, plus sympa pour les yeux que du pur objet JS ou du JSON. On pourrait facilement gérer l'annuaire des membres comme ça.

@flexbox, @neemzy : Héhé, de mon coté, je ne souhaiterais pas trop partir direct sur du LESS ou du SASS. J'aimerai garder un fichier CSS "classique" aussi.

On pourrait concatèner la sortie du compilateur LESS ou SASS à ce fichier CSS classique et on passer le tout à la moulinette de la minification.

Et une fois ce fichier CSS un peu étoffé, vous pourriez nous faire une micro présentation / atelier sur "comment factoriser / migrer du CSS avec LESS/SASS" ;-) héhé. Et @flexbox pourrait nous SASSiser la génération des icônes SVG de Nico \o/

Enfin, en tout cas ça m’intéresserait.

neemzy commented 10 years ago

En fait il y a déjà LESS dans le projet :) Mais après du pur CSS me va aussi très bien, personnellement ; pour le peu de styles qu'il y aura, ça n'empêchera pas d'avoir quelque chose de facilement maintenable. Si de plus on peut mêler fichiers "natifs" et fichiers "à préprocesser" (c'est le matin), tout le monde devrait y trouver à peu près son compte !

nfroidure commented 10 years ago

Je suis pour les préprocesseurs car ça permet de voir l'essence des CSS plus facilement. Si je prend l'exemple du rythme vertical, une fois qu'on sait qu'il faut être multiple de @vrythm pour toutes les hauteurs, on ne risque plus d'e faire des erreurs. Par contre, cela manque de commentaires pour diminuer le gap avec les newcomers et éventuellement, on pourrait peut-être aussi indiquer un ordre dans lequel consulter les fichiers pour mieux les comprendre.

Après entre less et sass, le souci de sass est qu'il crée une dépendance à Ruby et j'aurai vraiment aimé avoir un repo pur JS. J'avais essayé libsass au travers de grunt-sass qui est en pur C&JS, mais là c'est au niveau des options que ça pêche (notamment au niveau des arrondis).

Je pense que c'est ceux qui contribueront aux CSS qui doivent choisir les outils vu que c'est le principal intéressé. Pour ma part, le seul truc qui me tient à coeur est de rester sur full JS.

flexbox commented 10 years ago

Humm je ne savais pas que sass était obligatoirement marié à ruby. Tu as raison nicolas full stack JS sinon rien :)

/***/

David Leuliette
Front-end Developer
blog.davidleuliette.com /***/

Le 7 déc. 2013 à 10:37, Nicolas Froidure notifications@github.com a écrit :

Je suis pour les préprocesseurs car ça permet de voir l'essence des CSS plus facilement. Si je prend l'exemple du rythme vertical, une fois qu'on sait qu'il faut être multiple de @vrythm pour toutes les hauteurs, on ne risque plus d'e faire des erreurs. Par contre, cela manque de commentaires pour diminuer le gap avec les newcomers et éventuellement, on pourrait peut-être aussi indiquer un ordre dans lequel consulter les fichiers pour mieux les comprendre.

Après entre less et sass, le souci de sass est qu'il crée une dépendance à Ruby et j'aurai vraiment aimé avoir un repo pur JS. J'avais essayé libsass au travers de grunt-sass qui est en pur C&JS, mais là c'est au niveau des options que ça pêche (notamment au niveau des arrondis).

Je pense que c'est ceux qui contribueront aux CSS qui doivent choisir les outils vu que c'est le principal intéressé. Pour ma part, le seul truc qui me tient à coeur est de rester sur full JS.

— Reply to this email directly or view it on GitHub.

nfroidure commented 10 years ago

On reste sur cette config au moins pour la V1 et on voit après que le site est op pour la prod ?

neemzy commented 10 years ago

:+1:

nfroidure commented 10 years ago

Cool. Juste pour info, je suis parti sur l'unité rem car c'est le plus simple à utiliser que em et je transforme la feuille de style en px pour ie<8.

0gust1 commented 10 years ago

on ferme l'issue ?

nfroidure commented 10 years ago

:+1:

0gust1 commented 10 years ago

hopla

ChtiJS / chtijs.francejs.org

Générateur de site statique #4