gaaaaaAab a écrit 1401 commentaires

working overtime

je traduirais ça par "heures sup" plutôt que le fait d'être en dehors des plages horaires.

je recommande le livre "Rework" de 37 signals qui est vraiment intéressant à lire.

oui !

Je reformule, j'aurais du dire "zéro doc en tant que tel" plutôt que "zéro doc".

"You should always write your code as if comments didn't exist. This forces you to write your code in the simplest, plainest, most self-documenting way you can humanly come up with."

http://www.codinghorror.com/blog/2008/07/coding-without-comments.html

le commentaire explicite, c'est quand on n'a pas réussi à transmettre tout ce qu'il fallait mettre dans le code. Je trouve l'exemple dans l'article en lien ci dessus très parlant.

ça me rappelle aussi un peu le DOET The_Design_of_Everyday_Things. Je viens de farfouiller sur le net pour me rafraîchir la mémoire. Je pensais au chapitre 3. Knowledge in the Head and in the World". mais vaut mieux le lire in extenso, je trouve le résumé un peu aride.
Appliqué au dev, l'objet qu'en veut concevoir serait le code proprement dit, et le commentaire, le "knowledge in the world". Si on peut s'en passer, c'est mieux.

Le agile manifesto, en essayant de mettre tous les trolls de côté, est une liste de couple de "concepts" opposés. Ensuite, tout est dans la façon dont on équilibre la colonne de gauche et la colonne de droite. Pour certains, le bon équilibre concernant la doc, c'est pas de doc.

voilà j'espère quelques éléments de réflexions. Sur le plan personnel, je commente assez peu, et très très rarement sur des éléments techniques.

Pour finir, la seule documentation vraiment à jour, c'est le code !

gaffe quand même. On va finir par t'appeler CrEv_g ;-)

tout est une question de l'endroit ou tu mets le curseur entre trop de doc et pas de doc. Dans certaines méthodes à Gilles, la règle, c'est zéro commentaire dans le code. (option "Si le code a besoin d'être commenté pour être compris, c'est du mauvais code")

Il faut distinguer la doc interne et la doc d'API à destinations de développeurs tiers. Si getTitle fait partie d'une interface externe, il faut la documenter au moins succinctement (ne serait-ce que pas un lapidaire "self explaining"). Si c'est un bout de doc interne à un module, perso, je ne documenterais pas, parce ce que le développeur qui coincerait déjà à ce niveau là, ce serait pas la peine qu'il regarde plus loin.

En fonction du contexte dans lequel est englobé ce bout de code, les 4 lignes de commentaires seront plus ou moins utiles. J'aurais tendance à dire plutôt moins, mais c'est un exemple un peu caricatural. Les IDEs qui génèrent des getter/setter en profitent parfois pour écrire les 3 lignes de doc qui vont avec.

concernant ton titre, cf mon commentaire plus haut. La doc obsolète, en plus d'être inutile, peut-être nuisible si on ne sait pas qu'elle est obsolète.

un journal bien touffu ma foi.
Concernant la doc, j'ai un peu honte de répondre avec un commentaire bookmark, mais je ne pourrais pas écrire mieux (et même j'en ai compris plus sur le sujet après l'avoir lu qu'avant).

Effets néfastes car quelqu'un de sensé a forcément plus de confiance dans les produits crées par des gens qui savent se tenir, argumenter et s'exprimer sans être grossier ou vulgaire.

mouais … je me considère comme relativement sensé, et à choisir entre l'avis d'un gars qui consacre sa vie à un projet qui le passionne et d'un porte parole d'une multinationale, je ferais plutôt confiance au premier, même s'il est parfois grossier.

Mais je t'accorde que sur ce domaine, je suis un initié. J'ai donc vérifié il y a quelques jours sur les fils de news google (en et fr): l'incident est repris principalement sur des sites de techos. A part un petit article sur 20minutes.fr ou équivalent et un article d'un lecture sur le site du nouvel obs, je n'ai vu aucune reprise dans les media grand public. Dans le Monde, il y a un article qui parle de Torvalds, mais pas de bol, c'est pour le fait qu'il aie remporté le Millenium Prize, qui devrait avoir assez peu d'effets négatifs.

Du coup, l'effet néfaste éventuel, je demande à voir. En tout cas, ça m'étonnerait que la courbe de vente des téléphones sous Android soit beaucoup impactée.

note l'échelle de temps: dans "quelques dizaines d'années", je pense qu'il y aura prescription !

et un journal dans quelques dizaines d'années pour qu'on sache enfin de quel projet il s'agit ? ;-)

paf dans l'actu
un article sur osnews sur le sujet (pour anglophone)

j'ai dépouillé pour la première fois ce we, et c'est vrai que le bulletin pour Chewbacca, c'était assez fendard !

oui. Par chez moi, 66 % d'abstention au second tour, mais quand il ne reste plus qu'un seul candidat parce que le second s'est désisté, ça se comprend. Ça serait plus parlant d'avoir le pourcentage d'abstention en ne prenant en compte que les circonscriptions où il y avait au moins deux candidats au second tour.

petit contresens sur la fin. cf ce commentaire

nan mais faut relativiser un peu aussi.

Si ton employeur insiste lourdement sur cet aspect des choses, tu peux désarmer ça en montrant ta bonne foi: soit en remettant ton e-mail pro à la place du perso, soit en l'attribuant à un alias e-mail de ta boite (ce qu'il aurait en fait été bien de faire dès le début si ton employeur avait vraiment eu envie de continuer sur ce projet).

à te lire, j'ai quand même du mal à comprendre la position de ton employeur qui trouve d'un seul coup que c'est projet super important qui lui appartient alors qu'il en a rien eu à battre pendant longtemps. Qu'aurait-il dit si tu avais abordé le sujet il y a 3 mois, c'est à dire avant qu'on te contacte pour proposer un contrat de support ?

est-ce qu'il est toujours aussi motivé pour investir là dessus si tu lui annonces que tu laisses tomber ?

bref, je vois le mal partout chez les méchants patrons ;-)

ou alors, faudrait vraiment que son poste pro n'était plus du tout sur ce projet par exemple, de manière explicite

c'est ce qu'il ressort de son explication. Une fois la livraison faite au client, hors un peu de support, le projet est tombé dans l'apathie. Même sans que ça soit explicite, il suffirait de montrer que ses tâches professionnelles ultérieures l'occupait à temps plein, ce qui ne laissait que le temps perso pour travailler sur ce projet.

le code et forges appartiennent à l'entreprise

la forge, oui. Pour le code, c'est beaucoup moins clair. Le projet de départ était un projet GPL externe. L'entreprise détient les droits sur tout le code produit par 261f030600e9 dans le cadre professionnel. Mais pour ce qui concerne le code développé sur son temps libre, je suis pas certain que ça soit si clair que ça. Il aurait pu tout aussi bien le diffuser sur un git quelque part.

Tout ça pour dire que techniquement, si ton entreprise veut reprendre le contrôle du code, et même changer la license) elle en a entièrement le droit.

Il s'agissait au départ de la reprise d'un projet en GPL externe à la boite. Du coup, je doute qu'elle puisse changer la licence de l'intégralité du projet. Mais je n'ai pas l'impression que c'est son objectif de toute façon.

c'est malheureux, mais si tu n'es pas prêt à te fâcher avec ton patron, il aura tout ce qu'il voudra. C'est dommage que tu n'aies pas eu conscience plus tôt de rentrer dans une phase de négociation, tu aurais pu mieux te préparer. Mais bon, ce n'est pas trop tard.
- identifie les trucs qui sont absolument non négociables pour toi et ne lâche rien dessus,
- identifie ce qui est vraiment pas négociable pour ton patron,
à noter qu'à ce point là, on peut se rendre compte qu'il n'y a aucun accord possible.
- identifie les trucs sur lesquels tu peux lâcher un peu,
- identifie les moyens que tu peux utiliser pour faire pression (en étant prêt à aller jusqu'à les mettre en oeuvre): fork communautaire, désengagement total du projet, …)
- identifie les arguments et prépare des contre arguments à ceux que peut faire valoir ton patron.

par exemple, sur le site web, tu l'as développé sur ton temps libre. Si ton patron le veut, échange le contre plus de contrôle sur le projet (ou une prime, ou un autre truc qui est important pour toi)

Sur le plan moral, la situation est pas si claire que ça. Le projet était développé pour le compte d'un client, donc pas un investissement de ta boite. Tu as ajouté des nouvelles fonctionnalités sur ton temps libre, pas sur ton temps de travail. Du coup, revendiquer le contrôle complet, je trouve ça gonflé.

sinon, il n'a manifestement pas bien compris le concept de la sponsorisation. Un sponsor file des sous, et à ce titre peut avoir plus d'influence sur le projet que les autres gens, mais s'il prend le contrôle, ça ne s'appelle plus un sponsor. A voir s'il est vraiment persuadé qu'il est dans son bon droit, ou est-ce qu'il tente simplement le coup en se disant que si tu laisses passer, il gagne sur toute la ligne, et que si tu réagis, vous trouverez quand même un accord qui lui ira.

ce que je voulais dire c'était bien ça, faire un tar, ça utiliserais moins d'inode, non ?

alors oui, ça marchera … enfin, à condition de commencer par supprimer un fichier pour pouvoir créer un tar, ou faire du append sur un tar existant ;-)

petit point de vocabulaire, créer des archives avec tar, ça ne peut vraiment pas être assimilé à de la compression, d'où la réponse de jben.
tar propose des options de compression, mais ça reste périphérique au traitement d'archive, qui est la fonction principale de tar. D'ailleurs, la compression/décompression peut tout aussi bien être appliqué a posteriori à coup de gzip/bzip2.

Malheureusement je parle là d'éditeurs de logiciels, donc de boites où la création vient réellement du développement :-(

ha ben … mauvaise boite, changer boite ;-)

Enfin si, tu as toujours le droit de faire plus d'heures que prévus.

ça, à part quelques cadres éclairés qui forcent les gens à rentrer chez eux, c'est clair qu'on t'interdira rarement de faire plus d'heure …

Pour rebondir sur les heures de présence, c'est vrai que je suis dans une structure assez grosse (quelques milliers de personnes) et dans un secteur d'activité technique. Je veux bien croire quand la petite boite pour laquelle l'IT n'est qu'une fonction support, la compréhension des enjeux de dév soit moins bonne.

d'accord aussi pour dire que le dév est une activité créative, et, pour une part, artisanale même. Dans la situation que tu décris, c'est bien de savoir s'exprimer pour arriver à mettre les enjeux à la portée des non techos. A force de patience, c'est possible de les former/éduquer pour qu'ils appréhendent mieux comment formuler leurs besoins, ce qu'il peuvent attendre et dans quel délai.

En parlant de postes, pour vous développeurs (enfin ça peut sûrement s'appliquer à d'autres) comment se passe votre temps de travail ?

je ne rentre plus dans la case développeur, parce que je fais aussi d'autres trucs, mais je ne l'ai pas complètement quitté non plus, alors je réponds.

Etes-vous contraint par des horaires strictes ?

Théoriquement, oui, mais aucun "petit chef" n'a vraiment réussi à m'imposer de les respecter, et les "pas petits chefs", avec sagesse, me laissent tranquille :-)

Horaire libres ?

du coup, assez libre, mais ça reste dans une plage horaire "raisonnable", genre j'arrive avant midi (en gros entre 9h30 et 11h, tendance chaotique) et je pars entre 19h30 et 22 h 30 (hors amplitude exceptionnelle, je suis déjà arrivé avant 8 h, et parti à minuit).

Finalement, dans quel cas êtes vous le plus productif

à partir de 17/18 h, quand tout le monde s'est un peu barré et que je suis un peu tranquille. Comme je commence à être un vieux de la vieille, je passe pas mal de temps en traitement d'interruptions diverses et variées dans la journée. A noter que mon périmètre déborde un peu du côté de l'architecture, du coaching, de la discussion de spec fonctionnelles, voire de discussion sur les process en plus de tâches de dev.

combien d'heures par jour de boulot ?

variable. Certaines journées, ça veut pas. A ce moment là, je force pas, je fais le tour des bureaux, je papote, je m''auto forme ou je fais des trucs chiants mais nécessaires et je me barre tôt. Je n'ai jamais suffisamment observé pour faire de moyennes, mais à la louche, je dirais que je suis plus du côté de 4/5 h de moyenne que de 2/3 h.
A relativiser par le fait que j'ai appris à compter les réunions/discussions ou on a parfois un peu l'impression de "ne pas travailler" comme du travail même si ça rentre pas dans la case "développement" ou si ça ne peut pas se justifier sur un décompte de temps.
A noter aussi que je suis en temps partiel, et que du coup, ça densifie un peu les journées pour rester à peu près en phase avec ce que fait le reste de l'équipe.

Concernant l'illusion d'avoir 8 heures productives en moyenne par jour, et la nécessité d'être comptable de 8 heures par jour, j'ai l'impression que les deux notes que tu cites enfoncent un peu des portes ouvertes. Il y bien que l'encadrement à la feuille excel et les couches hautes du management qui ne sont pas conscients de ça.

il y a plusieurs sortes de manchots.

L'article AFP/Le monde parle de manchots empereur. D'après wikipedia (que ferait-on sans ça), il y a bien des manchots empereur en terre Adélie, mais d'après l'article du Guardian, les observations portaient sur les manchots Adélie.

bon, de toute façon, Tux est un manchot pygmée.

anéfé.

là j'ai aussi du:

flag = 0;
while (condition1) {
        switch(state)
        case 1:
                si (condition2) {
                        state = 3;
                        flag = 1;
                        continue;
                }
                break;
        case 2:
        case 3:
                si (flag != 0) {
                        // des trucs
                }
                sinon {
                       // d'autres trucs
                }                
        case 4:
                si (state == 2 || state == 3) {
                        // des trucs
                }
                // du code commun à 2,3 et 4
                // enfin ... "commun" mais avec quand même des traitements conditionnels
}

j'étais un peu optimise en fait, c'est étalé sur environ 3000 lignes de gloubi boulga :D

en réponse à delio :

Ca ressemble à la façon habituelle de coder une machine à état.

oui, le problème ici c'est qu'il y avait plusieurs états possibles sur laquelle baser ce mécanisme, et ce n'est pas le plus simple qui a été retenu. Le bout de code ci dessus ne rend pas justice à la complexité du machin, qui a jusqu'à 9 niveaux d'indentation, des conditions dont les effets sont distribués entre les différents case et encore, certains bouts des traitements ont effectivement été déportés dans des fonctions.

je n'avais lu que le post original en anglais. Je viens tout juste de lire l'article en français, et ben … pas bravo clubic.

Je cite:

Torvalds (…) en remet une couche en indiquant qu'à son sens, Gnome 3.4 était une « erreur totale en terme d'ergonomie pour l'utilisateur » (total user experience design failure, en anglais dans le texte).

allez, la VO correspondante:

End result: extensions.gnome.org may be a really cool idea, but it seems to have some serious usability problems in practice. And the whole gnome3 approach of "by default we don't give you even the most basic tools to fix things, but you can hack around things with unofficial extensions" seems to be a total UX failure.

traduction vite faite:

Au final: extensions.gnome.org est peut-être une très bonne idée, mais semble avoir en pratique des sérieux problèmes d'utilisabilité. Et toute l'approche de Gnome3 du genre "par défaut, on ne vous donne pas les outils les plus basiques pour régler les trucs, mais vous pouvez les trifouillez à coup d'extension non officiels" semble être un échec total en terme d'expérience utilisateur.

donc quand Linus parle d'un échec pour l'ergonomie, il ne parle pas de Gnome 3 en tant que tel, mais de la gestion de la configuration avec les extensions.

voilà voilà … merci l'auteur de l'article et du titre sensationnaliste à deux ronds, il peut postuler pour écrire les titres des news sur slashdot …

C'est vrai qu'il aurait pu tout aussi bien s'énerver contre X ou Fedora qui ne proposait pas le backport des fix pour le driver intel pour sa version ;)

Pour moi c'est un réel manque d'humilité que de ne pas pouvoir présenter les choses sans vouloir les imposer

à sa décharge, quand on fait du dev et qu'on a un peu de bouteille (et il en a plus que moi), on se sent parfois autorisés à produire des jugements assez tranchés:
Exemple, j'ai lu aujourd'hui un bout de code monstrueux en C qui mélangeait allègrement des while et des switch/case, du genre dans un case, on modifie la valeur de la variable testée dans le switch, qui fait qu'on rentre dans un autre case lors de l'itération suivante de la boucle, le tout sur au moins plusieurs centaines de lignes (je voulais compter le nombre de ligne de la fonction, mais j'ai oublié. Je ferais demain tiens). Ajoute à ça qu'on regroupe parfois plusieurs case, mais que dans le traitement "commun" à ces différents cases, on reteste la valeur qui a servi au switch et on fait des traitements différents (Pas sur que ça soit très clair mais bon, autant que ce bout de code …)
Bon, ben je me sens autorisé à dire que c'est vraiment du code de merde.