Journal De tout, de rien, des liens, du vrac (des bookmarks quoi)

Posté par (page perso) .
12
5
juin
2012

Sommaire

Bon, à priori faut faire plus court et assumer son côté bookmarks donc voici !


Dev

The Design of LLVM

Si vous souhaitez savoir comment fonctionne LLVM cet article est fait pour vous. Bon, j'ai pas encore eu le temps de le lire, mais dès que j'en ai le temps… (oui c'est facile)

Gerrit Code Review

Gerrit est un système de revue de code destiné à être utilisé à partir de Git.
Je suis personnellement de plus en plus intéressé par les revues de code, mais le problème est souvent la facilité ou non de le gérer et de l'intégrer aux processus existants.
L'avoir au plus près du gestionnaire de source peut être intéressant. A tester rapidement sur mes projets sous Git.
D'ailleurs j'en profite :

  • Vous faites des revues de codes vous ?
  • Et dans votre taff ?
  • Si oui, vous utilisez quoi ?
  • Pas trop chiant comme contrainte dans les processus de dev ?

Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work - part 1

Depuis quelques année, une liste de 14 bonne pratiques pour les perfs web est utilisée. L'article présent (première partie) revient sur ses règles mais en utilisant un navigateur récent (chrome 19) et en le comparant avec un ancien (IE6) afin de voir si ces règles sont toujours d'actualité ou non.
Un très bon article, il est je pense intéressant de faire régulièrement se travail afin de ne pas appliquer des règles idiotes, surtout vu l'énorme évolution des navigateurs ces derniers temps.

Fire & Ice

Vous voulez des checkbox et range qui aient de la gueule ? En voici plutôt bien sympa (et pas qu'un peu).

Misc

Paris avant : endroits de Paris disparu !

Je connais peu Paris. Mais j'aime bien les articles du genre. Il montre l'évolution de certains coins de Paris qui ont (ou non d'ailleurs) changé durant les derniers siècles.

Quel sorte de manager est donc Mark Zuckerberg ?

Question intéressante. On le présente souvent comme un jeune geek. Est-ce vraiment le cas ou est-ce une façade ?

How to stop sucking and be awesome instead

Heu, comment dire…
En fait je crois que le titre suffit. Pour info c'est une présentation faite par Jeff Atwood (derrière Coding Horror, Stack Exchange, Stack Overflow) durant le Atlassian Summit 2012.

Le comment et le pourquoi du principe « KISS »

Petit article imagé sur KISS. Ca tombe bien, on en parle aussi icitte du KISS

MacBook Unibody Model A1342 Teardown - iFixit

Petit guide pour démonter un macbook unibody blanc (pas pro).

Apple répare les MacBook blancs qui se décollent

Vous avez un macbook 13 unibody blanc ? Le fond se décolle ? Il n'est plus sous garantie ? Qu'importe, il suffit de demander à Apple et ils le change ou fournissent un nouveau fond. Pour ma part, je viens de le recevoir ce matin, reste plus qu'à le monter et renvoyer l'ancienne pièce (UPS fourni et prepayé)

Google Apps obtient la certification de sécurité ISO 27001

Une bonne nouvelle pour Google, et une corde de plus à leur arc pour convaincre les réticents à passer sur une solution bureautique dans le cloud.

Microsoft Translator - and Bing Translator - Official Team Blog

Un pas de plus dans la décadence de Yahoo!. Yahoo! Babel fish, le service de traduction de Yahoo! devient Bing Translator.

Effet Casimir

Oué, le nom peut prêter à sourire. Par contre ils ont l'air bien sérieux quand même. En gros, le vide n'est pas vide, et donc il peut y avoir des forces. Et qui dit force dit possibilité de mouvement. Autrement dit (bon c'est pas forcément dans cet article) une possibilité de déplacer des objets dans l'espace (qui n'est pas si vide que ça finalement) sans carburant.

Introduction à la stratégie et la tactique du Product Owner

Très bon parallèle entre jeux et agile. Et surtout l'explication de la différence entre stratégie (product owner) et tactique (équipe).
Plutôt court et bien écrit, allez le lire, c'est vraiment intéressant.

Un redesign en « no-design » | Openweb.eu.org

Mise à jour du design de Openweb et ajout de nouvelles rubriques "blog" et "voir ailleurs".
Openweb reste un site important dans le paysage web francophone de part ses nombreuses traductions. Content de voir un peu de fraicheur dans leur design et une activité. (et j'aime bien le nouveau style)

Post Mortem: Today's Attack; Apparent Google Apps/Gmail Vulnerability; and How to Protect Yourself - CloudFlare blog

Ha ha, cloudflare !
Bon, déjà j'aime pas spécialement cloudflare, mais là. En gros, si j'ai bien compris, un admin c'est fait piraté son compte google. Ok, mais le rapport avec Cloudflare ? Ben la fonctionnalité de récupération de mot de passe. Et oui, aussi bête que cela, une fois le compte mail en poche il suffisait de lancer la procédure suite à une perte de mot de passe et hop, gagné !
Au final intéressant comme article, dans les conseils pas bête, utiliser un compte autre que le compte courant pour récupérer les comptes. Disons que ça évite les problèmes si quelqu'un vous pirate votre compte.

  • # Gerrit

    Posté par . Évalué à 3.

    À noter que le projet Qt utilise Gerrit pour le développement de Qt5, et qu'il est très simple d'y faire accepter des patches si vous en avez.

  • # Paname

    Posté par (page perso) . Évalué à 4.

    Notre capitale regorge de curiosités. Il ne se passe quasiment pas une semaine sans que j'en découvre une nouvelle. Le w-e dernier c'était les journées portes ouvertes aux frigos:
    http://les-frigos.com/ On a pu y écouter et y voir Urban Sax et Big Band Sortie de Secours 'tention ç'est du myspace… :-(

    La semaine d'avant on a découvert un atelier d'artistes insoupçonné:
    http://www.lecent.fr/

    Sinon un site que j'avais découvert il y a qq temps et qui malgré qq bizarreries dans sa conception vaut vraiment le détour c'est paris-unplugged:
    http://www.paris-unplugged.com/

  • # Dépêche

    Posté par (page perso) . Évalué à 3.

    Faire une dépêche par semaine avec des liens intéressants et commentés pourrait être une bonne idée a mon avis.
    Utilisant aussi un outil (shaarli) pour sauvegarder mes liens intéressants je pourrais y contribuer, peut être que d'autres personnes aussi?
    Après il ne faudrait pas que ça devienne une usine à liens xD.

    Qu'en penses-tu journal?

    • [^] # Re: Dépêche

      Posté par (page perso) . Évalué à 2.

      Pour ma part j'en pense que c'est une idée intéressante mais :

      • Pour le moment j'ai pas un vrai bon rythme et je pense que c'est par contre intéressant / important. J'ai réussi à tenir le rythme pendant un temps, env 1.5 ans (enfin pas en publiant ici) mais je suis pas sur de pouvoir/vouloir le tenir
      • J'envisagerais plutôt avec une certaine ligne "éditoriale" et c'est pas encore ça.
      • Il faudrait un peu plus de détail pour passer en dépêche je pense, comme tu dis pour que ce ne soit pas qu'une usine à liens

      Bon, maintenant voilà c'est que mon avis.
      Je crois que pour certains liens les petites brèves qui fleurissent sont pas mal, à condition de détailler un poil. Certains (nono ?) c'étaient essayés aux dépêches de liens de dev, mais je crois que ça avait pas forcément fait mouche, bien que je pense que c'était intéressant.
      Ca y est, j'ai retrouvé : https://linuxfr.org/news/veille-technologique-sur-le-web et https://linuxfr.org/news/les-technos-web-cools-du-moment par exemple

  • # Review

    Posté par (page perso) . Évalué à 4.

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

    • [^] # Re: Review

      Posté par (page perso) . Évalué à 2.

      OK, merci du retour.

      J'ai aussi installé un ReviewBoard, mais je l'ai pas encore vraiment mis en place, entre autre car j'ai pas trouvé ça hyper simple.
      L'un des problèmes pour le coup est que le code sur lequel je bosse est vraiment très modulaire (> 40 projets, tous dans un hg différent donc pas de racine commune) et de ce que j'avais vu il fallait créer tous les projets à la main dessus. Et c'est quand même un peu long.

      Après, une question conne sur le principe : vous faites la review avant de commiter ? Donc pas moyen d'avoir un ensemble de commit ? Ou alors le commit à reviewer est un commit de merge entre une feature branch et la principale ?

      Bon sinon, ça me semble intéressant.

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

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

      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 ?

      • [^] # Re: Review

        Posté par (page perso) . Évalué à 2. Dernière modification le 06/06/12 à 16:33.

        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…

        • [^] # Re: Review

          Posté par (page perso) . Évalué à 3.

          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 ?

          Je viens de regarder un peu plus reviewboard (ça faisait 6 mois que j'en avais un dans un coin…) et en fait c'est plutôt sympa.
          Je ne sais pas trop comment ça marche avec git donc je ne vais parler que de ce que ça donne avec mercurial.
          Déjà, il faut prendre cette extension : https://bitbucket.org/haard/mercurial-reviewboard/overview Il y en a peut-être d'autres mais avec https://bitbucket.org/mdelagra/mercurial-reviewboard/overview j'ai eu des problèmes, et je n'ai pas essayé l'extension initiale http://code.google.com/p/mercurial-reviewboard mais ça vaudrait le coût de voir les différences.

          Bon, quoi qu'il en soit cette extension fonctionne sans problème en ligne de commande (hg postreview tip par exemple) et ça fonctionne aussi dans tortoisehg (avec une interface correcte) donc c'est bien.

          Là où ça m'intéresse beaucoup plus c'est qu'il est possible d'envoyer une review sur toute une branche. Et ça c'est bien.
          Avec un fonctionnement du genre, je peux imaginer un workflow qui serait :

          • création d'une feature branch
          • code / commit / push
          • code / commit / push
          • code / commit / push
          • fonctionnalité / story / … finie
          • demande de review sur la branche
          • review
          • fix / commit (/ push ?)
          • mise à jour de la review avec soit les commits non pushés, soit en resélectionnant les bons
          • OK
          • merge avec le tronc principal
          • close de la feature branch

          Bon c'est approximatif, fait rapidos, mais je pense que ça respecte en gros l'esprit de ce que je souhaiterais.

          Dans un contexte d'entreprise, quand le chef dit, on râle un peu et on fait ;)

          Oué, ça c'est avec des gens civilisés ;-)

          On a un peu rechigné au départ, c'est normal

          Et au final, après un moment, ça donne quoi ? Est-ce que vous reviendriez en arrière ? Est-ce que c'est vu comme un mal obligatoire, comme une perte de temps, ou comme un vrai mieux et une amélioration de la qualité ?
          Et pour finir, le temps "perdu" en code review, est-il vraiment regagné en réduction / suppression de problèmes, bugs, etc ?

          • [^] # Re: Review

            Posté par (page perso) . Évalué à 3. Dernière modification le 06/06/12 à 21:17.

            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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.