CrEv a écrit 4577 commentaires

J'ai un odyssey de chez bookeen.

Les raisons de cet achat:
- écran sans lumière

Il existe une cybook odyssey hd frontlight qui rajoute :

• un écran hd (1024*668 si je ne me trompe) : c'est un peu mieux, un peu plus propre, mais ne fait pas une énorme différence
• l'écran est éclairé (et non rétro-éclairé !) et c'est plutôt bien ça, vraiment

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 ! ;-)

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.

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.

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…

pas la réimplémentation bancale utilisée par DLFP

c'est à dire ?

Hum, tu génère ton html depuis le markdown, ok. Par contre, il faut bien créer une page html de base, un css, non ?

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 :)

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.

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…

Fire the workaholics

Le chapitre de rework sur le sujet est plutôt intéressant. En gros, beaucoup de personnes qui restent tard sont juste mauvaise et on besoin de beaucoup plus de temps pour faire les choses (et pour bien faire c'est autre chose). Alors que quelqu'un qui veut partir tôt gagnera à être beaucoup plus productif et propre.

Juste comme ça, j'ai par contre l'impression que tu es d'accord avec le commentaire parent…

« Mais nous ne devrions pas en tenir rigueur à Rackspace. »

Mais pas du tout mon bon.

Lorsqu'on veut être affirmatif on utilise "must".

Ce qui serait plutôt "mais ne devons pas en tenir rigueur à Rackspace", non ?

Intellectuellement en tout cas, je trouve dommage de devoir récupérer tout les articles pour en ajouter 1.

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.

Ou il faudrait mettre à jour le fichier xml en question.

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.

La tâche rake utilise une implémentation en ruby ou elle fait appel à la commande ?

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…

Je n'ai pas regardé tout le détail de la solution

Normal je ne l'ai pas encore rendue publique :)

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) ?

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.

Pour git tu veux dire que tu upload via git ?

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…

Il y a la possibilité de créer du contenu online tout de même

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.

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 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.

je ne vois pas trop ce que tu reproches à du contenu généré dynamiquement

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.

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).

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.

Le seul intérêt que je vois, c'est juste de s'amuser avec de nouvelles technologies que tu cites

Hum, même pas car comme je l'ai indiqué j'utilise aussi toutes ces techniques dans des applis RoR.

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

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.

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

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)

ou faire office de serveur web, comme ROR

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…

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.

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.

Pour moi, c'est complétement inconcevable

Justement, la question est : "pourquoi ?"

Tu fais vraiment des sites sans côté serveur de temps en temps ?

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.

je me demande s'il n'existe pas des choses sympa côté serveur.

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.

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…)

la création d'un site statique requiert un ensemble de compétences que seul un expert peut cumuler.

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.

faudra que tu nous le présentes un jour :)

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 ;)

bon, ce sera pour mercredi prochain maintenant…

Si ça se passe bien il y aura peut-être quelque chose mercredi prochain…

Sinon, moi, ça m'a rappelé https://github.com/nono/linuxfr.org et organisation-code-linuxfr.

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é)

tant qu'à faire, autant partir sur le côté serveur

Hum… pourquoi ? C'est une vrai question, pourquoi vouloir forcément partir côté serveur ?

je voulais m'intéresser à ruby on rails donc j'imagine que tu as encore toute un panoplie d'outils à ajouter

Pas forcément.
Sur la dernière application Rails sur laquelle je bosse voici les techno utilisées :

• ruby -> ok
• haml -> ok
• coffeescript -> ok
• guard -> ok
• rake -> ok
• bundler -> ok
• sass -> ok
• mustache -> ko, utilisé pour des templates côté client, je n'ai pas mis d'interactivité dans mes pages donc pas besoin
• backbone.js -> ko, pas utilisé et pas vraiment utile pour mon besoin

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.

mais j'ai l'impression que le ton est moqueur alors que ce sont des techniques vraiment intéressantes

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).

Markdown est un super langage mais ça me semble très limité pour concevoir des pages web.

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.

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.

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")

Et aussi jekyll, hyde, pelican, mynt, …

Il y en a plein, le mien est obligatoirement mieux, bientôt il dominera le monde !

ou pas