CrEv a écrit 4577 commentaires

Même en dehors des SSII ?

Parce que bon ça oui, on en trouve à la pelle. Des SSII qui se disent différentes / mieux que les autres aussi (en fait elles disent toutes ça).
Par contre, des éditeurs de logiciels c'est pas tout à fait la même histoire…

Ha oui, il semble qu'il soit épuisé… Dommage car c'est réellement un livre très intéressant.

Comme je suis un gars sympa, je te fais le mien à 128€ seulement.

La lecture de cet article (qui était pas mal repris sur twitter par exemple, il y a presque 2 mois) m'a fait pensé à un bouquin que j'ai adoré : « L'Éthique hacker et l'esprit de l'ère de l'information » de Pekka Himanen.

Je reprends ce que j'avais écris à l'époque.

---

Je conseil réellement ce livre à tous les développeurs, tous les ingénieurs, toutes les personnes qui sont intéressées de près ou de loin par les hackers (ou qui pensent en être un).

Pour vous parler de ce livre, je vais déjà vous citer un passage de l'article sur les ingénieurs grincheux qui m'a vraiment fait penser à celui-ci :

Revoyons un instant ce qui fait avancer les ingénieurs :

• Être créatif
• Résoudre des problèmes
• Avoir une incidence sur la vie des gens

Notez une absente dans cette liste. L'argent. Donner bêtement de l'argent à un ingénieur ne le satisfera que rarement. Cela fait cliché, mais ça n'a rien à voir avec l'argent. L'argent permet de s'amuser, mais ce qui nous intéresse vraiment c'est le code et la création. Lorsque nous pouvons le faire dans un environnement sain, nous sommes heureux, et pour très longtemps.

Ce livre est en réalité un livre de philosophie. Si vous désirez un livre technique, passez votre chemin. Par contre, mine de rien il a une préface intéressante, par un certain Linus Torvalds…

Ce livre oppose l'éthique hacker à l'éthique protestante du travail. D'ailleurs le titre de l'ouvrage est une sorte de clin d'œil au premier livre dans lequel le terme d'éthique protestante du travail est apparu. Il s'agit d'un livre de Max Weber intitulé « L'éthique protestante et l'esprit du capitalisme ». Et cette opposition cadre parfaitement avec le passage cité.

---

Tant qu'à faire, voici la quatrième de couverture :

« Il y avait la rock'n'roll attitude, il y a désormais la “hacker attitude“, un modèle social pour l'ère post-industrielle », expliquait Libération lors de la parution de ce libre au début de l'année 2001 aux Etats-Unis. On considérait jusqu'à présent le « hacker » comme un voyou d'internet, responsable d'actes de piratage et de vols de numéros de cartes bancaires. L'essor du Net a contribué à cette mauvaise réputation, certes tronquée et trompeuse, des flibustiers de la grande toile.

Le philosophe Pekka Himanen voit au contraire les hackers comme des citoyens modèles de l'ère de l'information. Il les considère comme les véritables moteurs d'une profonde mutation sociale. Leur éthique, leur rapport au travail, au temps ou à l'argent, sont fondés sur la passion, le plaisir ou le partage. Cette éthique est radicalement opposée à l'éthique protestante, telle qu'elle est définie par Max Weber, du travail comme devoir, comme valeur en soi, une morale qui domine encore le monde aujourd'hui.

Cet essai de Himanen - déjà salué par la critique aux Etats-Unis et au Japon - ouvre de nouvelles voies pour penser l'avenir des sociétés post-industrielles et la transformation en cours du capitalisme.

Pekka Himanen, né en 1973, docteur en philosophie, enseigne à l'université d'Helsinki, ainsi qu'à l'université de Berkley en Californie.

Linus Torvalds, illustre hacker, est à l'origine du système d'exploitation Linux.

Manuel Castells, professeur de sociologie à l'université de Berkley, est notamment l'auteur de L'ère de l'information (Fayard).

---

Sinon vous pouvez aussi aller lire cette intéressante interview de Roberto Di Cosmo.

Alors lorsque je vois des personnes proches de mozilla se plaindre, j'ai un peu envie de leur demander ce qu'ils ont fait pour que ce ne soit pas le cas.

Si tu avais entendu une seule personne de Mozilla suggérer qu'ils auraient dû passer à Gecko, ton commentaire aurait été fondé. Mais comme ce n'est pas le cas…

1. proche de mozilla != mozilla
2. je dis que des proches de mozilla se plaignent, pas que mozilla dit qu'ils auraient du passer à gecko (si tu ne vois pas la différence c'est problématique)

À Mozilla on pense et on dit que pour le bien du Web il est dommage de tomber à seulement 3 moteurs.

Oui, c'est certain. Mais quelle aurait été la réaction si opéra passait à gecko ? Les réactions auraient été les mêmes ? Si les réactions auraient été différentes c'est juste triste, car si les gens passent à webkit et non gecko c'est parce que webkit répond mieux aux besoins.

Et je trouve qu'il y a un peu de mauvaise fois dans tout ça, car au final Opéra vient de passer sur un moteur open source (le leur ne le sera peut-être pas mais la base, webkit, l'est). Et c'est très bien.

framework

Mouai, si tu classe ça dans ta grille de business loto say triste

en même temps c'est la saint valentin

oups !

Pourquoi ce serait un mauvais choix ?
Opera est une petite entreprise tout de même. Ils pensent que passer à webkit va les aider bien que par certains côtés ils perdent en indépendance. Mais leur plus value est aussi (surtout ?) sur l'interface (bien que moi je ne l'ai jamais supporté)

Donc ils passent à webkit/v8. Est-ce un bon choix, technologiquement parlant ? Je pense que oui.
Ok, on retombe dans les histoires de "monopole" de webkit. Mais n'est-ce pas faute d'alternative sérieuse ? Je veux dire, quel choix auraient-ils pu faire ? Gecko ? Ca fait bien longtemps que personne n'essai de l'embarquer, alors que tout le monde embarque du webkit. Pire, certains navigateurs sous gecko sont passés sous webkit.
Alors lorsque je vois des personnes proches de mozilla se plaindre, j'ai un peu envie de leur demander ce qu'ils ont fait pour que ce ne soit pas le cas. Personne ne veut de gecko. Ca peut être un bon moteur, il semble tout de même plus complexe à utiliser / inclure, ce qui ne semble pas être le cas de webkit.

Qu'on combatte le code webkit-only pourquoi pas. Maintenant, la seule manière à mon avis est que les autre moteurs aillent aussi vite que webkit pour ajouter des nouveautés. Car c'est bien là le problème. Si les gens intègrent du webkit et code pour webkit c'est surtout que, contrairement aux autres, webkit correspond au besoin.

Pour Opéra c'est à mon avis un bon choix de passer à webkit.

ce n'est pas un énième projet de jeu vidéo mais un CMS

Oué c'est pas comme si c'était finalement un énième projet de CMS… (désolé mais je vois pas bien la différence entre les deux…)

J'ai pu mettre les graphismes à fond, je n'ai pas du tout de lag !

Encore heureux quand même. Lancer un jeu d'il y a dix ans, à l'époque sur un amd 1800 et 512Mo de ram par exemple, et ramer sur un i5 4Go de ram serait pour le moins ridicule.

Y'a que moi que ça choque ce gris sur gris ?
C'est assez peu lisible et, de mon point de vue, fait tout sauf donner envie malheureusement…

Beaucoup de développeurs ont une mauvaise opinion de javascript, souvent justifiée

Y'a moyen d'avoir une explication sur cette phrase ? Car de mon point de vue c'est juste du troll. Ce que j'en vois c'est que "beaucoup de développeurs" n'ont aucune idée de ce qu'est javascript, la seule chose qu'ils en connaissent c'est un plugin jquery pour faire bouger un nyan cat derrière le curseur.

Merci également à CrEv et sa css solarized, qui m'a mis sur la bonne voie avec l'utilisation de sass.

Ben de rien ;)

Franchement, ça fait un moment que je ne fais plus de css. Que du sass, scss, less, google stylesheet. C'est quand même beaucoup plus puissant / intéressant.

D'ailleurs, alors que j'étais plus syntaxe scss, j'utilise de plus en plus sass qui est plus sympa si on part from scratch (pas de css existant) et qui est plus cohérente dans un contexte ruby + coffeescript + haml puisqu'on a 4 syntaxes presque identiques.

Sinon, ça me fait dire que je devrais finir de corriger deux trois petites choses dans solarized, ça ferait du bien…

Bravo pour ta css

Si je prenais plutôt un exemple sur une fonction qui utilise le temps, ou le statut de l'utilisateur pour modifier le contenu.

Ha oui, mais là on est vraiment dans quelque chose de totalement différent. D'ailleurs de mon point de vue je fais de la publication simple, il n'existe même pas d'utilisateur…

une bonne raison de le placer côté serveur est de contrôler les accès.

Heu, justement, je ne contrôle pas les accès, c'est ouvert (les sources sont même publiques)

ta base de données pour les commentaires, serait donc un fichier compilable.

Oui, les commentaires seraient un fichier qui est inclus dans la génération, aucune vrai différence avec un billet.

la compilation générerait plusieurs versions des commentaires
- une version public avec tous les commentaires modérés
- une version privée, avec modération des commentaires

Oula non. Mon idée (pas encore implémentée faute de temps) est juste d'utiliser git comme base de données. Les informations du commentateur (email par exemple) seraient dans les données du commit. Le commentaire serait le contenu du commit. la modération se fait alors en cherry-pickant / fusionnant les commits ou non.
Git est donc l'outil de modération et de "base de donnée".

Par contre, je ferai tout ça dans un autre dépôt, pas question d'avoir cela en publique.

mais cela implique pour l'utilisateur que son post n'est pas instantané.

ce qui est de toute façon le cas avec des commentaires modérés…

des fonctions que l'on sait très bien faire aujourd'hui avec des langages cote serveur.

auquel il faut rajouter un moyen de persistance qui serait en doublon avec mon git

tout l’intérêt de la compilation et de balancer le site on the CDN

hum, non. en tout cas pas directement
L'intérêt premier est que c'est plus cool à gérer qu'un logiciel côté serveur. Ensuite c'est beaucoup plus sympa en terme de gestion serveur car pas de langage. Je peux donc déplacer mon domaine et son contenu très facilement.

Mais le but est au contraire de traiter les commentaires comme du contenu venant enrichir le contenu initial.

C'est bien, tu as justement pointé une grosse différence entre les deux solutions :

au moment de reverser l'évolution

C'est donc deux façon de faire très différentes. Dans le cas d'un rebase interactif comme tu l'entends, on va nettoyer l'historique à la fin, au moment de merger. Dans le cas que j'exposais, on se soucie d'avoir un historique propre et cohérent pendant le développement. Et ça change tout.

Et en plus, côté facilité et confort d'utilisation on est quand même vraiment très loin. Stgit est beaucoup plus agréable à utiliser que rebase -i. Dans les trucs utiles, les piles de patches ça permet aussi d'avoir des patches non appliqués. Par exemple avoir toujours un patch final contenant une conf particulière. Lorsque je développe je l'applique, lorsque je commit/push, il ne l'est pas. Peut-être y a-t-il d'autres moyens, mais celui-ci est vraiment pratique.

stgit et mq permettent de gérer (comme quilt) des piles de patches. C'est un peu plus puissant que des commits car on peut très facilement les modifier, changer leur ordre, fusionner, découper, etc. Le but est de travailler sur des patches qu'on modifie jusqu'à avoir une fonctionnalité propre avec un historique propre.

L'exemple tout bête c'est : j'ai un programme client serveur (par exemple une appli web). Je rajouter une action côté serveur, une ressource rest par exemple. Je la code, je fais un commit. Ensuite je code la partie cliente, je commit. Et là je me rend compte que finalement il manquait une broutille, il y avait une petite erreur, etc dans la partie serveur. En temps presque normal, les gens font un commit qui corrige le premier. Ben là non, on dépile le dernier commit, on met à jour le serveur, on rempile.

Je ne dirais pas que c'est utile tout le temps, mais parfois c'est vraiment vraiment sympa de pouvoir, facilement, travailler sur toutes les couches sans problème. Et une fois qu'on est satisfait, on les transforme en commit et on peut pusher.

Comme indiqué ici le problème venait de mémoire de l'utilisation par défaut des bookmarks (qui n'est franchement pas géniale)

La branche nommée
Je trouve dommage que git ne l'implémente pas

Pourquoi ?

La fonctionnalité de git est implémentée par le bookmark chez mercurial. Ça fonctionne de la même façon

hum, pas tout à fait…

Petit exemple à la con dans les deux systèmes :

• une branche
• on crée deux topic branches / bookmarks
• on commit dans les deux
• on cherche à revenir sur la branche initiale et on merge

hg :

hg init
echo "plop" > plop.txt && hg add plop.txt && hg ci -m "Plop"
hg bookmark book1
hg bookmark book2
hg up book1
echo "book1" >> plop.txt && hg ci -m "book1"
hg up -C book2
echo "book2" >> plop.txt && hg ci -m "book2"

Comment je reviens à la racine commune initiale pour merger ?
Ben je peux pas facilement car tip s'est déplacé.

hg glog -q
@  2:1e6b0920866c
|
| o  1:2916c74c15d8
|/
o  0:1c8a265ec97f

Evidemment là c'est un cas simple, mais dans un cas plus compliqué c'est vraiment galère pour se déplacer.

Maintenant git :

git init
echo "plop" > plop.txt && git add plop.txt && git ci -m "Plop"
git co -b branch1
git co master
git co -b branch2
git co branch1
echo "branch1" >> plop.txt && git ci -am "branch 1"
git ci branch2
echo "branch2" >> plop.txt && git ci -am "branch 2"

A ce moment là, si je veux merger depuis la racine commune c'est très simple puisqu'il me suffit de faire un git co master.

Les bookmarks en hg c'est juste un label sur une branche anonyme. On le voit d'ailleurs très bien dans l'historique.

Et pour ceux qui ont utilisé hg < 1.6 on ne pouvait juste pas push/pull les bookmarks

Ha oui, et ne surtout pas oublier de rajouter cela à votre .hgrc. Sans cela, même pas la peine d'essayer les bookmarks :

[bookmarks]
track.current = True

D'ailleurs la description est très marrante : It is possible to obtain a more Git-like experience

c'est beaucoup plus simple à maîtriser (mais ça on l'a déjà dit)

Oui, on le dit beaucoup mais j'en suis pas vraiment convaincu. Je ne trouve pas que mercurial soit plus facile à utiliser que git. Ok, la différence vient peut-être non du frontend mais plus de la staging area, mais à part ça…

Mq (gestion de pile de patchs) est super puissant et très simple, contrairement à git stash (que je n'arrive toujours pas à aimer…)

ça tombe bien ce n'est pas équivalent. Regarde du côté de stgit. Et ensuite tu n'auras plus de raisons de rester sous hg…

Hum, pas exactement si je ne me trompe pas. J'avais eu pas mal de problèmes avec les bookmarks, j'ai jamais vraiment réussi à retrouver le confort de git sur ce point.
Il faudrait que je refasse des tests, mais c'était pas génial.

Effectivement. Ça mérite pas un journal de 2600 mots par contre.

Oué enfin, ta solution et ce que je propose ne sont juste absolument pas comparable, désolé.

Si je ne voulais faire que du markdown et un template basique en html, pourquoi pas. Alors c'est sur, je comprend que si on veut une css qui fait 3 lignes et un template qui en fait 10 il n'y a pas besoin de cela. Parfais. Maintenant désolé d'avoir besoin d'un poil plus.

Et sinon, j'ai pas bien compris les "bugs". Sur le premier, c'est bien markdown qui gère les backslash de la sorte, non ?
Et le deuxième, il est où le rapport avec markdown ?

Nope. Mon dotclear existe toujours, j'ai choisi de ne rien migrer. De toute façon je n'aurais pas pu garder les mêmes urls par exemple. Et je n'en ai pas vu vraiment l'intérêt.

Mais si je devais le faire, je pense que je m'arrangerais simplement pour récupérer les contenus des articles en html (ça doit être faisable sans trop de problème) et je les transformeraient en pages html statiques à placer dans _pub. En gros. Mais bon, je pense que je ne le ferai jamais.

Alors… dans une précédente boite je m'étais justement occupé de la migration de notre svn. J'ai donc testé git, mercurial et bzr. Avant d'aller plus loin, on est passé à mercurial, je l'ai utilisé pendant en gros deux ans. J'utilisais git avant, pendant, et après, y compris pour des projets pro.

Pour commencer, bzr a des bons côtés je trouve, il est plutôt souple sur sur fonctionnement. Mais il a beaucoup de défauts et rien que sa lenteur fait que je n'ai jamais pu le blairer ! Pourtant j'ai vraiment essayé

Maintenant, git et mercurial. J'ai apprécié mercurial, il fonctionne plutôt bien. C'est déroutant que certaines commandes soient inversées lorsqu'on fait du mercurial et du git, mais bon c'est pas grand chose.
Mercurial fonctionne bien, mais je suis d'accord pour le côté extensions, c'est nul. Idem pour l'absence d'un équivalent correct aux submodules.

Pendant longtemps j'ai taillé mercurial pour sa gestion des branches. Ensuite j'ai compris comment ça fonctionnait et j'ai apprécié. Ensuite j'ai taillé git mercurial pour sa gestion des branches.

Je m'explique : dans mercurial la branche n'est qu'une méta donnée d'un commit. Pour qu'une branche existe il faut au moins un commit. Dans git une branche est un pointeur vers un commit. Pas besoin de commit dans la branche pour qu'elle existe, plus simple pour créer plusieurs branches depuis un même état.

Au final cela induit une vrai différence d'usage (et c'est là où je trouve qu'il y a réellement un point commun, dans l'usage, avec svn, contrairement à ces histoires de frontend qui sont un peu ridicules).
Dans git, on va brancher d'abord (beaucoup de branches nommées juste pour faire quelques commits, topic branches, court terme) pour préparer le boulot. Genre, je vais bosser sur si, sur ça, sur cet autre point, allez hop je crée 3 branches.
Dans mercurial, on va brancher plutôt au besoin (si on ne parle pas de branches long terme). On va toujours bosser dans default. Si j'ai besoin de corriger un commit, je remonte l'historique pour me placer dessus, et je commit directement. Je viens de créer un head, pas besoin de faire une branche. Et hop, je merge. Si j'ai plusieurs choses à faire, pareil. Je me met sur default et je bosse. Lorsque je veux passer sur une autre tâche, je reviens à mon état initial et je bosse. On est plus dans du "branch as needed" et on utilise beaucoup plus les branches anonymes.

Au final, je préfère le fonctionnement de git, mais parfois j'aime bien celui de mercurial tout de même.

Quelques liens (ça vient du même site mais ça c'est pas grave c'est plutôt de qualité) :

• Mercurial Workflows: Branch As Needed
• A Guide to Branching in Mercurial
• A Git User’s Guide to Mercurial Queues
• The Real Difference Between Mercurial and Git

Ha oui, et côté mercurial j'ai très souvent utilisé mq avec pas mal de plaisir. Sous git il m'arrive souvent d'utiliser stgit. Et je vous encourage vraiment à les utiliser, surtout si vous vous souciez de votre historique.

Voilà, ça répond pas totalement à ta question, mais met en évidences quelques différences.

Il existe quelques modèles non tactiles, ça peut aider

Maintenant, ce que je trouve pas mal, est d'avoir une liseuse tactile avec boutons, où on peut configurer un peu le fonctionnement.
Déjà, je préfère tenir de la main gauche. Et dans ce cas, ce que j'aimerais c'est le bouton de gauche pour aller en avant, toucher la partie gauche de l'écran pour aller en arrière. C'est ce que je trouverais plutôt pratique. Mais ce n'est pas tout le temps configurable :(

Mais je n'avais pas ressenti de lourdeur (mais elles n'ont pas toutes le même poids ni la même forme). Il est possible de tenir la cybook par le "coin" bas gauche sans trop de problème ni fatigue.

Adobe Digital Editions

Qui pour info, fonctionne plutôt bien avec wine (enfin je l'ai testé avec crossover, mais ça devrait être un peu pareil)