Sommaire
- Con tenu
- Marc donne. Oui, mais Marc donne quoi déjà ?
- Couleuvres
- Et maintenant ?
- haml et markdown
- Je pars à maître
- Petit bonus
- Conclusion
Hey !
Ça y est, vous avez bien suivi la première et deuxième [1] partie de "Écrire une page web de nos jours" et vous pensez être devenu un Dieu de l'achetaihèmaille ? Vous auriez tort !
Vous pensiez qu'un peu de haml, sass, ruby, rake, gem, git, bundler, guard, guard-rake ou encore coffeescript suffisait ?
Allez, il est temps de passer aux choses sérieuses et voir comment markdown, haml (oui encore lui) et ruby (toujours lui) peuvent réellement enlarger votre productivité devis et faire de vous un vrai développeur web !
Note : contrairement aux premiers épisodes, celui-ci ne montre pas l'intégralité du boulot, mais détaille les étapes et concepts principaux. Le résultat final n'est pas directement disponible, mais sera l'objet d'un prochain article, plus spécifique au projet dans son ensemble.
Con tenu
C'est bien joli, vous avez une superbe page oueb qui rox des mamans ours. Supaïr ! Mais, maintenant, il serait temps de passer aux choses sérieuses et là, comment dire… le haml say nul !
Ben oui, vous vous voyez, sérieusement, écrire votre prose comme ça :
%p
C'est bien joli, vous avez une superbe page oueb qui rox des mamans ours. Supaïr ! Mais, maintenant, il serait temps de passer aux choses sérieuses et là, comment dire...
%i
le
%a(href="http://haml.info/")
haml
say nul
!
Ou alors, vous préférez écrire comme ceci :
C'est bien joli, vous avez une superbe page oueb qui rox des mamans ours. Supaïr !
Mais, maintenant, il serait temps de passer aux choses sérieuses et là, comment dire...
_le [haml](http://haml.info/) say nul_ !
Ouah !!! Livre-nous ton secret ô maître ! Quelle est cette syntaxe si magnifique !
Comment ça, je rêve ? Pffff, c'était mieux à vent !
Ok, vous l'aurez tous compris, on va parler de markdown parce que c'est hype !
Sachez, pour la forme, qu'il existe d'autres choses plus ou moins équivalentes, comme reStructuredText ou Textile.
Marc donne. Oui, mais Marc donne quoi déjà ?
Markdown, c'est juste la syntaxe de texte enrichi la plus en vogue en ce moment. On la retrouve partout, sur github, sur stack* et même sur da linux french page, c'est dire !
Ha ok, vous connaissez déjà. Bien bien, passons donc aux choses sérieuses : faire du markdown en ruby !
Pour pouvoir transformer du markdown en html, on va évidemment utiliser des gems !
La plupart du temps, Maruku ou rdiscount sont utilisés. Mais comme on ne veut pas faire comme les autres, on va utiliser redcarpet !
Comme d'habitude, ça se fait facilement en ruby. Tout d'abord, ajouter la gem au fichier Gemfile :
gem 'redcarpet'
Puis l'installer :
bundle
À ce moment vous pouvez commiter le fichier Gemfile mais aussi le Gemfile.lock.
Ensuite, si vous avez un fichier markdown plop.md à convertir, rien de plus simple avec ce petit bout de ruby :
require 'redcarpet'
markdown = Redcarpet::Markdown.new
html = markdown.render File.read 'plop.md'
Et voilà !
Évidemment, vous pouvez faire plus de chose, mais pour ça allez lire la doc de redcarpet.
Couleuvres
Avant d'aller plus loin dans l'intégration, arrêtons-nous un instant. Ok, on a du markdown qui se transforme en html. Cool. Mais il manque la fonctionnalité absolument indispensable : la mise en couleurs du code source !
Ben oui, vous vouliez vous servir du markdown pour quoi d'autre que présenter du code source ?
Vous connaissez pygments ? Ben, ça tombe bien, c'est ce qu'on va utiliser ! Enfin, via un wrapper ruby quand même, pas question d'utiliser un truc en python ici !
On va juste faire comme d'habitude. D'abord rajouter la gem qui va bien :
gem 'pygments.rb'
Et l'installer :
bundle
Puis améliorer un peu le script ruby :
require 'redcarpet'
require 'pygments'
class HTMLwithPygments < Redcarpet::Render::HTML
def block_code(code, language)
Pygments.highlight(code, :lexer => language)
end
end
markdown = Redcarpet::Markdown.new(HTMLwithPygments, :fenced_code_blocks => true)
markdown.render File.read 'plop.md'
Et voilà, si vous avez du code entre trois (ou plus) backticks il sera mis en forme. Et, en plus, c'est compatible avec linuxfr ce qui est absolument obligatoire !
Et maintenant ?
Quoi ? Vous avez du haml, du sass, du ruby, du bundler, du rake, du guard, du rake, du markdown, etc. et vous n'êtes pas encore satisfait ? Comment ça, ça sert à rien tout ça si on ne peut pas inclure le markdown dans la page oueb ?
Bon, c'est facile : vous lancez rake ou guard et ensuite, vous exécutez le markdown et enfin copier/coller dans le fichier html généré. Voilà !
Toujours pas content ?
Ok, on va faire un peu mieux alors…
haml et markdown
Lorsqu'on transforme un fichier haml en html, il est possible de lui passer un objet dont les membres vont pouvoir être appelés dans le haml. Si on crée un object qui lui va convertir le markdown en html via une méthode (qu'on va appeler content) alors rien de plus simple pour intégrer votre fichier markdown en haml !
Tout d'abord, on va changer un peu le fichier haml pour qu'il ressemble à ça :
!!! 5
%html(lang="en")
%head
%meta(charset="utf-8")
%link(rel="stylesheet" type="text/css" href="application.css")
%title= "Écrire une page web de nos jours"
%body(class="blue")
= content
On va aussi prendre un fichier markdown, plop.md qui ressemble à ça :
# Yeah !
Supaïr, je suis un fichier markdown !
Et je peux faire plein de trucs cool
* comme
* ceci
Et il convient ensuite de changer notre script ruby.
Initialement on avait un bloc content ceci :
haml = IO.read("index.haml")
hamlengine = Haml::Engine.new(haml)
html = hamlengine.render()
File.open("_site/index.html", "w") { |f| f.write(html) }
On va donc ajouter une classe gérant notre markdown :
class Content
def content
markdown = Redcarpet::Markdown.new(HTMLwithPygments, :fenced_code_blocks => true)
markdown.render File.read 'plop.md'
end
end
Et on va en passer une instance à notre convertisseur haml :
haml = IO.read "index.haml"
hamlengine = Haml::Engine.new haml
html = hamlengine.render Content.new
File.open("_site/index.html", "w") { |f| f.write(html) }
Et c'est tout ! Lorsque le haml sera transformé, il va appeler la méthode content de l'instance de Content qui va transformer le markdown en html et l'ajoutera au document.
Elle est pas belle la vie ?
Je pars à maître
Et oui, c'est bien joli tout ça, mais si on allait plus loin ? Et surtout, si on paramétrait tout ça.
Car là, dans le cas présent, ça permet de déléguer une partie du haml par du markdown. Mais, ce serait beaucoup plus sympa si on se concentrait sur le markdown qui indiquerait de lui-même dans quelle "page" haml il voudrait être rendu.
Dans cette optique et histoire de ne pas réinventer inutilement la roue, on va partir sur ce que fait jekyll. C'est-à-dire que le fichier markdown va comporter un entête qui va en indiquer différents paramètres.
Ces paramètres vont être séparés du reste du markdown par des tirets. Le contenu est simplement sous forme d'un yaml parce que say bien !
Voici un exemple de paramètres :
---
param: valeur du paramètre
param2: autre valeur
---
Suite du fichier...
Par contre, ce paramétrage ne devra pas être inclus dans la génération du html à partir du markdown.
On va donc remplacer le File.read 'plop.md' par quelque chose d'un peu plus évolué :
content = File.read 'plop.md'
datas = Hash.new
begin
if content =~ /^(---\s*\n.*?\n?)^(---\s*$\n?)/m
content = $'
datas = YAML.load $1
end
rescue => e
puts "YAML Exception reading 'plop.md': #{e.message}"
end
Voici ce qui est réalisé :
- on lit tout le fichier
- extraction de l'entête si elle existe
si c'est le cas :
Ok, mais pourquoi on fait tout ça déjà ? Ben on va simplement y placer un paramètre layout qui va avoir comme valeur le nom du fichier haml dans lequel insérer le html généré à partir du markdown. Ainsi, on se concentre sur le contenu réel (le markdown) et non sur la page oueb.
Si on veut refaire l'exemple précédent avec ce principe, on aurait d'abord ceci en tête de notre plop.md :
---
layout: index.haml
---
et le ruby ressemblerait à quelque chose du genre :
class Content
def initialize
@content = File.read 'plop.md'
@datas = Hash.new
begin
if @content =~ /^(---\s*\n.*?\n?)^(---\s*$\n?)/m
@content = $'
@datas = YAML.load $1
end
rescue => e
puts "YAML Exception reading 'plop.md': #{e.message}"
end
end
def content
markdown = Redcarpet::Markdown.new(HTMLwithPygments, :fenced_code_blocks => true)
markdown.render @content
end
def render
haml = IO.read @datas['layout']
hamlengine = Haml::Engine.new haml
html = hamlengine.render self
File.open("_site/index.html", "w") { |f| f.write(html) }
end
end
Et on pourrait alors faire un
content = Content.new
content.render
qui lirait le markdown, irait chercher le haml nécessaire, rendrait le markdown lors de l'appel à content à l'intérieur du code haml.
Alors, elle est pas belle la vie ?
Évidemment, on peut imaginer chaîner l'ensemble. C'est-à-dire que le fichier haml peut aussi n'être qu'une sorte de fichier "partiel" et contenir lui-même un entête yaml.
Pour aller encore plus loin, on peut aussi rendre disponible le contenu de @datas, donc de l'entête. Soit en présentant un accesseur sur @datas, soit en ajoutant des accesseurs spécifiques, soit en utilisant method_missing. Quelle que soit la solution, le but est d'ajouter des méta-données, telles le titre, l'auteur, des liens, catégories, tags, etc. Finalement tout ce qu'on veut, de toute manière la majorité du boulot se fera par l'appel à ces données dans des fichiers haml.
Petit bonus
Et oui, comme c'est nowel, voici un petit bonus.
Dans votre fichier Gemfile (ou manuellement), ajoutez une référence à gollum. Il s'agit d'un éditeur / visualiseur markdown réalisé par github. Il permet donc de voir vos posts, d'en éditer le contenu au format markdown (il prend en charge en réalité d'autres types) et d'en avoir la prévisualisation. C'est tout de suite beaucoup plus sympa.
Donc installez gollum, rendez-vous dans le dossier concerné, par exemple _posts, et exécutez gollum. Enfin, rendez-vous à l'adresse http://localhost:4567/pages (oui le lien est pour pages car ça permet de lister les pages trouvées, étant donné qu'il n'y a pas de Home.
Vous pouvez maintenant éditer et visualiser vos posts, voire même en créer des nouveaux. Attention, lorsque vous enregistrez, cela fait un commit git.
Alors, sympa, non ?
Conclusion
Fin de la petite série de trois articles sur "Écrire une page web de nos jours". Mais non, ne pleurez pas, c'est pas tout à fait terminé ;-)
J'espère que cette série aura pu vous intéresser, au moins vous présenter quelques outils plutôt sympas qui pourraient vous être utiles, même si ça reste assez classique (le combo ruby, haml, coffeescript, sass est plutôt courant côté rails).
Le résultat de tout ceci est une vrai mise en application de tout ce que vous avez pu voir ici.
Les sources / explications seront bientôt disponibles, il ne manque qu'un petit coup de polish pour que ce soit présentable (un peu de doc, explications, etc.).
Bon web à tous !
[1]: "#{part_1}#{part_2}".to_linuxfr http://linuxfr.org/users/crev/journaux/ecrire-une-page-web-de-nos-jours
# webgen
Posté par rewind (Mastodon) . Évalué à 4.
En fait, tu viens pas de réinventer webgen ?
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 4.
Et aussi jekyll, hyde, pelican, mynt, …
Il y en a plein, le mien est obligatoirement mieux, bientôt il dominera le monde !
ou pas
[^] # Re: webgen
Posté par fravashyo . Évalué à 1.
Ça me semble bien compliqué en tout cas. Sortir tout cet arsenal juste pour faire un site, ça fait un peu peur. En général quand j'ai besoin de créer un site web, j'installe pmwiki (qui est facilement extensible pour tout un tas de besoins) et ça roule.
Quant à Markdown, je trouve ça horrible et limité.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 4.
hein ?
Quel arsenal ? Ok, il y a plein de noms partout, par contre, ton wiki il faudra bien que je modifie l'html généré pour qu'il ressemble à ce que je souhaite (probablement via un moteur de template utilisé par pmwiki -> haml), il faudra aussi que je fasse la css (ok moi je vais faire du sass car c'est pour le coup beaucoup plus agréable).
Ensuite, ok, divergence sur la saisie, mais bon y'a quand même dans markdown de quoi faire pas mal de choses, y compris des tableaux par exemple, et pour les cas plus tordus j'ai haml.
Par contre, côté serveur, j'ai … rien de plus qu'un serveur de fichier statique. Pas de php, pas de ruby, pas de python, rien, nada, que dalle. Alors que si je veux mettre un pmwiki ou autre, ben il faut que je gère mon serveur, mes versions de php, ruby, etc.
Au contraire, pour un besoin qui est la fourniture de documents html sans interaction autre que du javascript si j'en ai besoin (donc pas de personnalisation, pas de login, pas de saisie depuis le navigateur, etc) pourquoi vouloir faire autre chose que du … html. La seule chose c'est que je me simplifie la vie pour ne pas avoir à saisir mon html à la main, mais c'est du ressort de l'avant-publication. L'après publication c'est "apache mon petit, t'es gentil, tout le répertoire là tu le fourni et tu ne te poses pas de question".
Ha oui, et justement, tout ceci n'est pas un wiki (je n'aime pas du tout les wiki détournés pour faire autre chose, moi je veux juste faire ce qu'avant on appelait des "pages personnelles")
[^] # Re: webgen
Posté par _jordan_ . Évalué à 2.
C'est vrai que tant qu'à faire, autant partir sur le côté serveur. J'ai vraiment bien aimé cette petite série mais moi je ne veux pas m'arrêter à la page static. D'autant que je voulais m'intéresser à ruby on rails donc j'imagine que tu as encore toute un panoplie d'outils à ajouter.
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
Hum… pourquoi ? C'est une vrai question, pourquoi vouloir forcément partir côté serveur ?
Pas forcément.
Sur la dernière application Rails sur laquelle je bosse voici les techno utilisées :
Le reste c'est essentiellement des composantes métier / ui (underscore, moment, monocle)
Mine de rien, avec les technos présentées ici tu peux te lancer dans du rails sans trop de problème. De toute façon le problème est plus souvent dans l'architecture, l'organisation, etc que dans les libs utilisées.
[^] # Re: webgen
Posté par _jordan_ . Évalué à 1.
Tu fais vraiment des sites sans côté serveur de temps en temps ?(vrai question aussi :) )
Pour moi, c'est complétement inconcevable et comme j'ai bien aimé découvrir certaines technologies que tu as donné, je me demande s'il n'existe pas des choses sympa côté serveur.
Ainsi, à la fin on aura une page web tellement divine qu'elle coutera trop cher pour n'importe qu'elle entreprise.
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 3.
Justement, la question est : "pourquoi ?"
Oui, genre mon site. Je n'ai absolument pas besoin d'avoir du code côté serveur dans ma page.
Et aussi vu les possibilités actuelles des navigateurs c'est parfois inutile, le js pouvant faire pas mal de choses. Une application web en html/js qui discute avec du REST avec quelqu'un d'autre c'est pas mal. Et je fais exprès de dire "quelqu'un d'autre" et non "composante serveur" car les deux peuvent être totalement découplés.
Par exemple, si voulais faire une galerie photo, pourquoi je n'irai pas juste faire un site statique qui choperait des données de flickr via une api ?
Sur mon site je n'ai aucun système de login, pas de commentaires, pas d'interface de saisie. D'ailleurs ce site n'est que le produit d'un autre logiciel.
Ben en fait oui il y a des choses sympa qui existent mais elles sont pour beaucoup ici (ruby entre autre)
Maintenant il y a encore d'autres choses, au risque de choquer certains, on peut faire des choses très sympa également en java par exemple (à condition de bien choisir ses outils, j'avais fait une démo mais bon entre ça et le ruby que j'ai présenté il y a quand même un sacré écart…). Je ferais bien aussi un serveur (ou un générateur comme je viens de le faire) en go.
Après, tout dépend ce qui t'intéresse aussi, si c'est le code "backend" ou plutôt l'interface par exemple.
[^] # Re: webgen
Posté par barmic . Évalué à 4.
Dire qu'avant on disait que Java EE c'est nul parce qu'on empile trop de techno… :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: webgen
Posté par fravashyo . Évalué à 1.
je ne vois pas trop ce que tu reproches à du contenu généré dynamiquement. Tous les hébergeurs mutualisés proposent du php, et si tu as un dédié ou un auto-hébergement tu peux utiliser ce que tu veux (ror, php, python etc).
Le seul intérêt que je vois, c'est juste de s'amuser avec de nouvelles technologies que tu cites (haml, sass, ruby, rake, gem, git, bundler, guard, guard-rake, coffeescript, redcarpet, pygments etc…), par contre, quand tu critiques le fait que par exemple pmwiki nécessite de "gérer" la version de php, ça fait juste un paramètre à prendre en compte (pas de base de données relationnelle, le contenu est stocké en plein texte), en revanche dans la chaîne de production que tu utilises, il y en a plus de 10 !
Que se passe-t-il si un des chaînons casse ? S'il change de comportement, s'il y a un bogue lors d'une mise à jour ? Ça me semble autrement plus périlleux que de vérifier une unique version de PHP, d'autant plus que pmwiki est simple et compact, régulièrement mis à jour, et toutes des versions récentes de PHP fonctionnent sans problème avec.
On pourrait d'ailleurs dire la même chose de Ruby : je n'aime pas les langages de programmation détournés pour faire autre chose, un langage de programmation ce n'est pas fait pour créer des pages html (ou faire office de serveur web, comme ROR)
hélas, le nom de pmwiki, choisi sans doute à l'époque florissante des débuts du concept de wiki, ne s'applique plus à ce que c'est devenu : un système de gestion de contenu comme un autre, qui utilise effectivement le principe de wiki pour éditer les pages, mais qui permet la plupart des choses que l'on trouve dans un CMS comme Drupal par exemple.
Enfin, l'avantage dans mon utilisation de pmwiki, c'est que j'utilise la même syntaxe en txt2tags qu'ailleurs, et il m'est possible à partir d'un site en pmwiki de l'exporter en LaTeX (pdf), ou en html statique, via un petit script qui récupère le contenu en mode texte de pmwiki. De plus, il est possible de recoller le contenu en txt2tags dans les autres CMS existants qui en supportent la syntaxe : entre autres dotclear, dokuwiki, plone, wordpress, drupal.
Et si on préfère le html static, il reste toujours l'export html de txt2tags : txt2tags -t html fichier.t2t
J'ai d'ailleurs créé la plupart de mes sites sur ce principe, mais maintenant je trouve fastidieux de devoir éditer les fichiers en local, les convertir, renvoyer les fichiers générés sur le serveur ftp, alors je migre progressivement tout dans par exemple pmwiki (ou encore il est possible de servir directement les fichiers originaux via le module php)
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
En soit, rien d'autre que le fait que, en général, ça ne sert à rien. Par exemple, j'ai un dotclear. Si je n'en utilise pas les commentaires, la partie dynamique ne me sert absolument à rien. Que le code qui génère le html soit sur un serveur ou sur un client ça ne change juste presque rien.
Ha mais ce n'est pas du tout en lien avec une quelconque disponibilité d'outils côté serveurs. Enfin presque, parce que mine de rien ça me permet de publier du code généré par des outils ruby et autre sur un mutualisé php.
Hum, même pas car comme je l'ai indiqué j'utilise aussi toutes ces techniques dans des applis RoR.
Et si un jour ce n'est plus le cas ? C'est du même genre que la compatibilité ruby ou gem. Sachant que je peux très bien bloquer les versions des gems et dans ce cas il n'y a plus vraiment de problème.
Wat ?
PHP est un langage de programmation, et il est fait pour créer des pages html.
Là franchement je ne vois pas la différence entre PHP et Ruby. Dans les deux cas on va utiliser un langage de programmation pour servir de glue (lorsque c'est bien fait) autour de langages de templates (haml, twig en php, etc) voir de conversion de contenu vers html (markdown, twt2tags, etc)
RoR n'est pas un serveur web…
Et sinon, si je prend la fin de ton message finalement tu as pmwiki et tu rajoutes des scripts, des outils pour en faire ce que tu souhaites. Ben exactement comme ce que j'ai fais alors…
[^] # Re: webgen
Posté par barmic . Évalué à 2.
Il y a la possibilité de créer du contenu online tout de même. Tout le monde ne veux pas d'un écrire son billet en local lancer une tambouille et uploader via (S)FTP(S).
Par contre je suis surpris que tu ne met pas en avant le fait que ça permet d'avoir un serveur simple avec très peu d'attaques possibles et léger. Je crois qu'à la base c'est pour cette raison que son revenu les contenu statique, les problèmes de performance. Aujourd'hui tout les sites à fort trafic utilisent 2 types de serveurs ceux qui crée du contenu dynamique et ceux qui délivrent le contenu statique et leur page web sont un mélange de ces deux contenu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
Oui, et c'est aussi ce qui m'embêtait. Avec les solutions de génération, l'avantage est que tout le contenu de mon site est dans un git. Ça en devient une solution distribuée, facile à accéder.
Je ne l'ai pas mentionné dans ce commentaire, mais je crois que je l'avais déjà mis dans un autre. Il est évident que la composante serveur est vraiment plus simple, n'importe quel serveur capable de fournir des fichiers statiques est suffisant. Moins de ressources, moins d'angles d'attaques, moins de configuration, etc.
[^] # Re: webgen
Posté par barmic . Évalué à 2.
Je n'ai pas regardé tout le détail de la solution, pour la génération tu as besoin de l'ensemble du contenu de ton site (pour par exemple regénérer le sitmap et le flux atom) ? Si c'est le cas c'est dommage (bien que je n'ai pas de solution à t'apporter).
Pour git tu veux dire que tu upload via git ? Si c'est le cas, la simplicité du serveur prend quand même un sacré coup.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: webgen
Posté par Juke (site web personnel) . Évalué à 2.
Pourquoi ?
[^] # Re: webgen
Posté par barmic . Évalué à 2.
Parce qu'il faut monter un serveur git gérer les utilisateurs etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: webgen
Posté par claudex . Évalué à 3.
Tu veux dire installer un serveur avec SSH ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: webgen
Posté par barmic . Évalué à 2.
Je trouve que c'est bien plus simple à installer et configurer et ça laisse très peu d'angle d'attaque et tu en a probablement déjà eu besoin pour installer ton serveur web.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: webgen
Posté par claudex . Évalué à 3.
Non, je voulais dire que pour avoir un serveur git, il te suffit d'un serveur avec SSH.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: webgen
Posté par Juke (site web personnel) . Évalué à 2.
Non ce n'est pas necessaire.
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
Normal je ne l'ai pas encore rendue publique :)
Oui mais je ne vois pas bien en quoi c'est dommage. Entre autre mon atom comportant l'ensemble des posts (mais pas de tous les contenus), il me le faut bien.
Dans le cas présent c'est les sources qui sont dans mon git. L'upload se fait par rsync en général, via une tâche
rake. D'ailleurs ce n'est que la version générée qui est envoyée, les sources ne sont pas envoyées vers le serveur. Je pourrais automatiser certaines choses, par exemple si je merge dans une branche ça déclenche la publication, mais ça voudrait dire que le serveur sur lequel je publie ou le serveur sur lequel je pose mes sources contient les dépendances nécessaires. Et ce n'est pas le cas. Alors que tous les ordis à partir desquels j'écris l'ont…[^] # Re: webgen
Posté par barmic . Évalué à 2.
Intellectuellement en tout cas, je trouve dommage de devoir récupérer tout les articles pour en ajouter 1.
Ou il faudrait mettre à jour le fichier xml en question.
La tâche rake utilise une implémentation en ruby ou elle fait appel à la commande ? (par simple curiosité)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
Lorsque tu veux ajouter une classe à un code source, en général tu récupère le dépôt.
Ben là c'est pareil.
Et je ne récupère pas que les posts puisqu'il y a aussi les layouts, css, etc.
Hum, nope, pas possible. En tout cas pas dans tous les cas.
La version générée n'est pas versionnée. Donc si j'arrive sur un ordi sur lequel je n'ai pas déjà généré je ne l'ai simplement pas (et je ne vais pas m'amuser à récupérer la version distante). Idem si j'ai fais des modifs depuis un autre poste, commité, pushé, publié, lorsque je reviens sur l'un ou je ne suis plus à jour il faut bien que je regénère tout.
J'utilise la commande rsync (je l'appelle dans la tâche). Je n'ai même pas regardé si une implémentation ruby existait, j'ai rsync sur toutes mes machines…
[^] # Re: webgen
Posté par rewind (Mastodon) . Évalué à 2.
Et pour quelqu'un qui voudrait un outil de ce genre, qui n'a pas le temps de faire ce que tu fais, et qui préférerait un outil Ruby à Python, tu conseillerais quoi ?
J'ai trouvé cette liste mais après, il y a beaucoup trop de choix. Actuellement, j'utilise webgen mais le développement était arrêté, je crois voir qu'une version 1.0 va sortir, mais je me demande s'il n'y a pas plus «moderne». Jekyll me semble trop orienté blog, et nanoc m'a l'air pas mal mais je ne sais pas quoi en penser.
Un avis ?
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
Ben heu… le mien ?
Il ne faudrait presque rien pour qu'il gère une arborescence de documents. Mais ça dépend ce que tu souhaites.
Pour le moment (ce sera plus facile lorsqu'il sera réellement publique) il permet d'avoir des pages statiques, des pages de blog (comme jekyll en gros), génère sitemap et atom automatiquement.
Je vais voir d'ailleurs pour rajouter une arborescence de pages plutôt que juste un seul niveau.
Après, décris un peu plus ton besoin, ça sera plus facile.
Mais si en gros tu veux du contenu qu'on peut écrire en markdown et un ou plusieurs templates, ça peut correspondre.
[^] # Re: webgen
Posté par rewind (Mastodon) . Évalué à 2.
Mon besoin est assez simple : un site de taille moyenne (quelques dizaines de pages statiques organisées en arborescence), pas de blog, un seul template (mais peut être amené à évoluer). Pour l'instant, avec webgen, j'écris mon html directement, je ne passe même pas par Markdown, mais ça peut évoluer (j'aimerais notamment afficher du code source pour un langage particulier qui n'est pas pris en charge, ainsi que pour du shell).
[^] # Re: webgen
Posté par CrEv (site web personnel) . Évalué à 2.
OK.
Ben je dirais que si ton html (le contenu, pas le template) peut être généré par markdown (car markdown ne fait pas tout, mais entre pandoc et redcarpet ça devrait pouvoir être pas mal je pense) alors je n'ai presque rien à changer à mes scripts pour que ça fonctionne.
Si je trouve le temps j'essaierai d'en faire une petite démo dans se sens, histoire de voir.
Bon par contre j'ai pas grand chose d'autre à te proposer, surtout qu'en fait je n'ai pas vraiment regardé la liste des existants pour pouvoir faire mon truc comme je l'entendais.
J'aillais dire que finalement un très simple script maison ruby qui te compile du template (haml) par exemple et markdown serait suffisant. Mais forcément il faudrait rajouter du css. Et en gros on retombe sur ce que j'ai fais, avec une orientation différente.
# Pandoc markdown et coloration syntaxique
Posté par ®om (site web personnel) . Évalué à 8. Dernière modification le 02 janvier 2013 à 15:44.
Il est également possible de colorer du code source avec markdown (celui de pandoc) en indiquant le langage utilisé comme ceci :
Puis :
Il suffit donc de rajouter 2 lignes
~~~en indiquant le langage pour activer la coloration. Bien pratique pour générer des pages html (ou autre) à partir de fichiers source !Les langages supportés (listés par
pandoc -v) :L'inconvénient, c'est que ça n'utilise qu'un outil : c'est trop simple, ça ne va pas plaire à l'auteur du journal
^^blog.rom1v.com
[^] # Re: Pandoc markdown et coloration syntaxique
Posté par CrEv (site web personnel) . Évalué à 2.
Exactement !
Mais sinon, ça a aussi l'inconvénient de ne pas être en ruby, c'est probablement un peu plus complexe à intégrer dans ma solution, etc.
Mais surtout, et là c'est juste inconcevable, la syntaxe n'est pas compatible avec linuxfr qui utilise 3 ` !
[^] # Re: Pandoc markdown et coloration syntaxique
Posté par ®om (site web personnel) . Évalué à 2.
Ça marche aussi avec 3
`au lieu de 3~:blog.rom1v.com
[^] # Re: Pandoc markdown et coloration syntaxique
Posté par CrEv (site web personnel) . Évalué à 2.
Ben c'est malin !
Résultat, si certains veulent ils peuvent, peut-être, remplacer redcarpet par https://github.com/alphabetum/pandoc-ruby qui permet de l'utiliser depuis du code ruby.
# C'est lu (mineux) et approuvé, mais…
Posté par muchos (site web personnel) . Évalué à 1.
Bravo pour ces conséquentes descriptions des nouvelles techniques d'intégration web, mais j'ai l'impression que le ton est moqueur alors que ce sont des techniques vraiment intéressantes (selon l'intégrateur).
En outre, Markdown est un super langage, avec la capacité d'être compilé en html, mais ça me semble très limité pour concevoir des pages web.
Debug the Web together.
[^] # Re: C'est lu (mineux) et approuvé, mais…
Posté par CrEv (site web personnel) . Évalué à 3.
En quoi le ton est-il gênant et surtout en quoi c'est mis en opposition avec la fin de la phrase ?
Oui c'est moqueur, à plus d'un titre. Moqueur sur la forme ça c'est sur, c'est une "private joke" sur quelqu'un qui ne peut s'empêcher de placer des liens partout, beaucoup trop. Moqueur sur le ton, assurément. Mais au moins j'ai pris plus de plaisir à l'écrire que si je l'avais fait avec un ton sérieux, et j'espère que s'en est tout de même un peu plus marrant à lire. Il ne faut pas confondre le fond (présentation des technos), la forme (le "ton") ni le but (faire une page web statique).
Oui, et c'est pour cette raison qu'il n'est pas seul dans l'histoire, mais qu'il est couplé, ici, à haml. Je ne me sert de markdown que pour la partie purement texte, article, comme sur linuxfr d'ailleurs. Le reste de la page, la structure de base, header, footer, etc, c'est du haml.
[^] # Re: C'est lu (mineux) et approuvé, mais…
Posté par BAud (site web personnel) . Évalué à 2.
faudra que tu nous le présentes un jour :) bon, ce sera pour mercredi prochain maintenant…
Sinon, moi, ça m'a rappelé https://github.com/nono/linuxfr.org et organisation-code-linuxfr.
[^] # Re: C'est lu (mineux) et approuvé, mais…
Posté par CrEv (site web personnel) . Évalué à 3.
Disons que c'est quelqu'un qui tourne autour de php, en radotant sa pub de manière un peu trop lourde et qui adore noyer ses articles de liens. Bon après il est pas méchant, c'est juste divertissant sur la forme ;)
Si ça se passe bien il y aura peut-être quelque chose mercredi prochain…
Ben il est vrai que j'ai quand même pioché une partie de ses technos dans celles que j'utilise au taff, et il se trouve que c'est aussi une application rails (sur laquelle d'ailleurs Bruno a travaillé)
# Les temps changent...
Posté par Maclag . Évalué à 4.
Il y a seulement 6-7ans, il fallait être un pro pour créer un site dynamique, et n'importe quel crétin pouvait trouver de quoi faire une bête et simple page statique.
Mais grâce au progrès de la technologie, aujourd'hui, n'importe quel abruti peut faire un site dynamique, mais la création d'un site statique requiert un ensemble de compétences que seul un expert peut cumuler.
De toute façon les sites perso c'est fini. Bientôt on dira
"T'as une page Facebook?
-Pfeuh! Mais non, pauvre ringard, j'ai une app pour iPhone qui génère des pops-up chaque fois que je veux te faire partager ma vie privée et la couleur de mes selles!"
[^] # Re: Les temps changent...
Posté par ckyl . Évalué à 3.
Tu confonds faire quelque chose et remplir du contenu. Ce n'est pas la même chose et cette confusion peut expliquer le tas de boue qu'est le web d'un point de vue technique.
Tu peux faire exactement comme avant et tu peux même mettre un GIF animé d'un mec avec une pelle si tu veux. Après c'est juste de l'outilage pour se faciliter la vie comme dans tout domaine. Les outils existent il faut juste les utiliser à bon escient.
Si tu veux écrire des CR au boulot tu peux par exemple:
Niveau productivité j'ai vite choisi.
Cet assemblage d'outils te paraitrait tout à fait normal pour programmer, en quoi est ce différent ?
[^] # Re: Les temps changent...
Posté par CrEv (site web personnel) . Évalué à 3.
Mouai…
L'ajout d'outils pour générer du html ne t'empêche absolument pas d'en faire à la main, comme avant, si ça te chantes. Et sinon tu peux toujours utiliser tous les éditeurs qui te transforment un document en html, ça existe toujours, et il paraît même que word te sors du html plus propre qu'avant (en même temps c'était pas très dur…)
Pas plus ni moins qu'avant.
Je passe ma journée devant du code. J'ai un tas d'outils sous la main. Je trouve beaucoup plus logique (et agréable) d'utiliser tout ceci pour mon besoin plutôt que de mettre quoi ? un mediawiki, un dotclear, un wordpress, un truc du genre, bloaté, ayant des failles, me demandant un serveur configuré, etc alors que je peux juste envoyer du html ?
Pourquoi je voudrais un site "dynamique" d'ailleurs ? J'en ai pas besoin.
Et vu la popularité des solutions du genre (à voir par exemple le nombre de personnes utilisant les pages github) je pense que je suis loin d'être le seul dans ce cas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.