Guillaume Denry a écrit 2954 commentaires

Allez, je caricature, mais pourquoi est-ce que les réflexions d'une église n'auraient pas le droit d'éclairer un débat ?

Considères-tu que les réflexions de l'église de la licorne rose invisible (loué soit son nom, ainsi que le poulet d'appellation d'origine contrôlée) aurait le droit d'éclairer un débat ?

Autrement dit, le choix d'un OS doit etre un opt-in (ie je veux specifiquement qu'on me rajoute ca) plutot qu'un opt-out (ie je veux specifiquement qu'on m'enleve ca). Si quelqu'un veut l'acheter avec un OS, il peut tres bien demander a son magasin qu'il lui installe. Bon sang, ca creerait meme des emplois locaux !

Ça pourrait même être encore plus simple en matière de gestion de sortie d'usine ; l'OS est pré-installé, mais la clef d'activation n'est donnée à l'utilisateur que si celui-ci à coché la case "Avec OS". Dans le cas contraire, le client se débrouille pour installer ce qu'il veut.

Il limite les possibilités techniques, mais il augmente l'ergonomie.
Enfin, c'est comme ça qu'il doit être justifié par les gens de chez Microsoft.

Oui mais les icônes sont différentes :)

J'ai pas l'impression qu'on résoudra quoique ce soit aujourd'hui : il y a des partisans des deux solutions (prise en compte ou pas de la casse), c'est une question éminemment complexe et qui fait appel à des études ergonomiques et même si chacun a son avis sur la question, je n'ai encore vu personne prouver par A+B que l'une des deux solutions est la plus pertinente.

Sans vouloir chercher la petite bête, c'est pas qu'une question de recherche : sous linux, dans ton dolphin/nautilus tu peux avoir "classeur" et "Classeur", sous windows, c'est impossible.

J'aime comme tu mets tout le monde dans le même panier du côté du libre, des gens qui s'expriment sur un forum public, des gens qui conçoivent des interfaces, etc etc
Comme si y'avait UNE grosse entité des linuxiens-qui-refusent-le-progrès-ergonomique-et-fonctionnel.
C'est surprenant de manquer à ce point de nuance.

C'est marrant, j'ai souvent tendance a me méfier…

[captain obvious]
Intuitivement, il semble simplement que l'apparition d'une technologie nouvelle telle que pouvait l'être le noyau linux dans les années 90 -a fortiori à une époque où les systèmes d'exploitation répandus étaient encore peu fiables, ou bien à défricher- provoque un engouement particulier et "embarque" avec elle une bonne partie de passionnés qui ensuite vieillissent avec la technologie.
Par la suite, je dirais en "vitesse de croisière", les jeunes passionnés deviennent moins jeunes, ce qui n'empêche pas qu'un peu de sang neuf entre de temps en temps dans la communauté, mais on a effectivement l'impression que l'"âge d'or" est plus ou moins achevé. (ce qui est probablement une impression de vieux con incapable de voir au delà d'un voile nostalgique :))
Ca a fait pareil avec le demomaking, le côté bricolage et découverte des premières années avait quelque chose de magique, et puis l'informatique était nouveau pour le grand public, on avait l'impression de faire partie d'une poignée d'initiés, des gens s'amusaient à taper du basic sur les CPC dans les rayons des grandes surfaces ou bien à regarder les démos qui tournaient sur des amigas (ou bien les autres machines dont le nom terminait par ST, mince, impossible de me souvenir :)).
Et je ne veux pas dire de conneries, mais j'ai lu un jour que ce fût à peu près la même chose à la découverte de l'automobile, beaucoup de bidouilleurs, de bricoleurs au début (par rapport à la proportion d'utilisateurs, s'entend).
[/captain obvious]

En ce qui concerne la pérennité de Linux, c'est une bonne question mais qui à mon sens fait appel à d'autres réflexions en englobant la question du devenir du matériel et de ses limitations, des usages, etc

Oui, vraiment bien trouvé cette histoire de eingousef.
Comme quoi, il suffit parfois d'un seul mot pour sublimer une histoire drôle.

Que vous le vouliez ou non, cela aura des effets néfastes.

En tout cas, du point de vue des utilisateurs eux-même, et d'après ce que j'ai pu lire à droite à gauche sur les forums, la réception du geste de Linus Torvalds a plutôt été "bonne". C'est pas une personne à qui il adresse un "fuck you" mais une multinationale. C'est un peu comme David contre Goliath, et à ce jeu là, c'est rarement Goliath qui est populaire.

Y'a que moi qui trouve que ce fuck est une très bonne nouvelle sur la façon dont Linus Torvalds mène sa barque ? Ce mec là n'est pas un chef d'entreprise, il a une parole complètement libre, et s'il veut dire publiquement à nvidia que ce sont des enfoirés (et en argumentant), il le dit. Franchement, quoi de plus sain ? Vous voudriez qu'il fasse des courbettes et utilise un langage châtié ? fuck it!

Faut pas déconner, Linus Torvalds, c'est quand même pas Lennart Poettering !

Les "reviewers" sont-ils des personnes dédiées ou ça fait partie des dev ? En gros les devs font la revue des autres dev ?

Chez nous ça ne reste qu'entre codeurs et la règle, c'est de fonctionner par trinôme. Les trinômes se forment pour une période plus ou moins longue ou de façon très temporaire pour une intervention "extra-ordinaire" dans un module spécifique que le développeur ne maîtrise pas forcément.
Chez nous également, un commit = une review, mais c'est parce qu'on fonctionne avec subversion, avec Git ou Mercurial, le plus naturel serait probablement "un push = une review".

Et au final, après un moment, ça donne quoi ? Est-ce que vous reviendriez en arrière ?

J'espère ne pas me tromper en affirmant que la majorité des équipes sont convaincues comme moi par l'utilité du review board (et je ne suis pas chef) car en plus d'être un outil qui va accroître la qualité et diminuer l'entropie des connaissances au sein de l'équipe, il permet d'initier des débats techniques intéressants.
En tout cas, il n'est plus remis en question par qui que ce soit, ça a vraiment bien pris.
En revanche je suis convaincu que c'est le genre d'outil qui, pour ne pas être perçu comme pénible doit vraiment être instantané à utiliser, ça ne doit pas casser le rythme et proposer une interface simple et directe. Une commande à taper et/ou un clic, point barre.
C'est pareil du point de vue du reviewer : on reçoit les demandes de review par mail, en un clic on arrive sur le diff de code, et on peut immédiatement commenter les portions de code et hop, on envoie la review.

Et pour finir, le temps "perdu" en code review, est-il vraiment regagné en réduction / suppression de problèmes, bugs, etc ?

Ouch, faudrait une petite étude pour savoir ça, mesurer la progression qualitative d'un gros projet, c'est déjà pas trivial…
Pour être honnête, les codeurs qui composent le trinôme ont déjà leur propre travail à effectuer et ne passeront pas la journée sur une review, et AMHA les bugs les plus perfides passeront vraisemblablement à travers les mailles du filet, mais ça peut déjà servir à repérer les trucs bien dégueulasses, et à se resynchroniser sur la syntaxe, l'indentation, etc.

Après, une question conne sur le principe : vous faites la review avant de commiter ?

C'est encore le mieux oui, si on veut être rigoureux.

Donc pas moyen d'avoir un ensemble de commit ?

Je ne suis pas le mieux placé pour en parler, j'en ai une utilisation très basique (via un script maison que je n'ai pas écrit) et en plus avec subversion. Je me contente de soumettre une review à chacun de mes commits atomiques.
Ça ne m'étonnerait pas que Review Board fonctionne avec juste des diff/patch, après tout, le but est principalement de pouvoir donner son avis sur un changeset de sources.
Je ne sais donc pas à quel point c'est laborieux de gérer 40 dépôts différents avec.

Ou alors le commit à reviewer est un commit de merge entre une feature branch et la principale ?

Je ne sais même pas si Review Board s’embarrasse de notions de branches. Peut-être bien s'il veut offrir une intégration poussée aux CSV.

Aucun problème pour convaincre les devs ? Pas de réticences (à l'outil ou même au principe de review et de propriété de code ?)

Dans un contexte d'entreprise, quand le chef dit, on râle un peu et on fait ;)
On a un peu rechigné au départ, c'est normal ; tu ajoutes dans la routine des gars un truc en plus qui a priori leur feront perdre un peu de temps.
Ensuite, ça dépend aussi du mode d'utilisation comme je le disais au dessus :
a) Tu interdis le commit avant review obligatoire par tes pairs
b) Tu autorises le commit avant review pour fluidifier un peu le développement au détriment de la qualité du commit dans l'instant et les commentaires a posteriori de tes pairs permettront de corriger le tir dans les commits suivants

A la longue, on se rend compte que c'est une sorte de filet de sécurité et aussi un moyen de faire circuler la connaissance et c'est même parfois assez ludique.

Après, t'as de tout dans les reviewers : ceux qui vont être obsédés par la syntaxe utilisée, ceux qui font une analyse plus profonde du code et qui arrivent à te débusquer un bug de ouf dans ton algo, etc.

Et question bonus (enfin probablement avant les suivantes) : est-il possible avec ce type d'outil de faire de la review d'un code existant (déjà commité) pour analyser et commenter un code réalisé avant de mettre en place des reviews ?

Sûrement.
En fait, (toujours avec Review Board puisque je ne connais pas les autres outils similaires) quand tu soumets un commit, il n'y a pas que le diff qui est affiché, on peut également aller commenter le code inchangé autour du diff si on veut…

• Vous faites des revues de codes vous ?

Oui.

• Et dans votre taff ?

Oui.

• Si oui, vous utilisez quoi ?

Review Board.

• Pas trop chiant comme contrainte dans les processus de dev ?

On a des scripts maisons pour pusher le diff sur le board avant le commit et on peut décider d'une politique "permissive" (reviewer et commiter quand même et attendre les remarques des copains pour s'améliorer) ou bien bloquante (ne commiter que lorsqu'on a eu les autorisations de N collègues).
Le bloquage peut être automatique ou bien on peut aussi s'auto-discipliner, ce qui fonctionne assez bien dans une équipe de taille modeste. De toute façon si tu commits sans attendre les autorisations, ça se voit et tu te fais vite taper sur les doigts.

Je l'utilise de manière "permissive" au sein d'une équipe et les review se font en opportuniste (quand les gens ont le temps) et même dans ce cas là, ça permet de diffuser un peu la connaissance, les gens sont en général assez contents de pouvoir donner leur avis sur le code des autres.

Il est important que l'outil de review soit assez complet pour pouvoir commenter facilement n'importe quelle portion de code soumise, d'offrir un système de "ping-pong" de commentaires, Review Board le fait et permet également de pouvoir engager un thread de discussion de façon hiérarchisée. Mais je pense que les autres outils doivent également le proposer.

Perso j'adore et c'est venu s'insérer assez naturellement dans notre processus de développement.

Oui, ça donne envie de connaître la langue. :)

Dans quels cas l'utilisation d'un objet js comme table de hash commence à poser problème ? je veux dire, je me sers de JavaScript pour faire des IHM web et j'utilise au grand max quelques centaines d'éléments de cette façon, si j'avais à gérer une grosse table de hachage pour une application qui doit gérer des dizaines de milliers, des millions d'éléments, effectivement, je commencerais à m'intéresser à l'implémentation en interne des propriétés des objets (qui doit dépendre des moteurs JavaScript) pour me tourner vers un outil plus approprié…

Je sous-entendais "lorsqu'on utilise les objets comme des tableaux associatifs", c'est-à-dire qu'on part de var o = {}; et qu'on peuple cet objet avec des clefs/valeurs, comme on le ferait avec un map, un QMap etc.
Je suis d'accord pour dire qu'il faut se prémunir de certains pièges, mais pour le gros du besoin, l'objet JavaScript répond assez bien, il me semble.

Mouais, tu joues sur les mots non ?
A part les histoires de mauvaises performances pour les parcours d'éléments (si tu as des liens, ça m'intéresse), je ne vois pas pourquoi on ne pourrait pas considérer que JavaScript offre une structure de donnée de type tableau associatif (certes limité à un système de clefs sous forme de chaîne) par le biais des objets !

Et si je veux un petit verre de Suze immédiatement, ils font aussi ?

L'effet perverse du vote électronique est qu'il met en oeuvre des ordinateurs pour fonctionner et qu'à partir de là, 75% des gens démissionnent en matière de réflexion car "si y'a un ordinateur, c'est que c'est compliqué et que des gens ont bien dû penser à tout pour que ça fonctionne".
Je suis bien sûr comme la plupart d'entre vous (et d'ailleurs de la plupart des gens un peu "éclairés" technologiquement, ce qui devrait constituer un indice tout de même !) viscéralement opposé à ce système car il insère, de manière inédite dans l'histoire électorale, une boîte noire entre le vote et le dépouillement, et que cette boîte noire, personne ne peut garantir qu'elle n'ait pas été altérée.
Mais pour qu'un message ne soit pas interprété comme partisan, il faut absolument éviter tout effet de manche, toute musique, etc, il faut rester le plus neutre possible et se concentrer sur la simplicité de la démonstration et sur les avantages du vote papier car après tout, il s'agit de montrer ce qu'on perd avec le vote électronique. Dans un bureau de vote, une fois que le bulletin a été placé (volontairement par le votant, ce qui est également crucial) dans l'urne transparente, plusieurs témoins peuvent attester visuellement de la manière la plus simple qui soit que celle-ci est restée fermée jusqu'au dépouillement.

Rassure-toi, je suis certain qu'au moment du vote, ils vont te demander en plus du mot de passe une information ultra-confidentielle que seul toi connais, comme ta date de naissance.

Déjà ça part mal avec le début :

N’en déplaise aux aficionados de Linux, son interface et sa simplicité d’utilisation la rendent désormais accessible à n’importe quel débutant en informatique.

Ca sous-entend que les "aficionados" de Linux désirent que ce système échappe au commun des mortel ? Sympa comme a priori sur la communauté !

C'est une contrepèterie ?