Sommaire
Bon, à priori faut faire plus court et assumer son côté bookmarks donc voici !
Dev
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 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.
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.
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)
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 BFG . É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 Raoul Volfoni (site web personnel) . É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/
[^] # Re: Paname
Posté par CrEv (site web personnel) . Évalué à 2.
Ha oué, sympa aussi.
J'ai aussi celui-ci qui m'avait bien plus comme lien : http://www.pariszigzag.fr/visite-insolite-paris/dans-les-coulisses-du-metro-parisien (et http://www.pariszigzag.fr/visite-insolite-paris/les-stations-fantomes-du-metro par extension)
Ben déjà que j'arrive pas à avoir le temps de visiter et découvrir la ville dans laquelle je suis (Lyon) alors qu'il y a pas mal de choses, je suis loin de découvrir réellement Paris :-)
[^] # Re: Paname
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Je connais bien ces stations. De même que le Paris souterrain où j'ai organisé quelques fiestas mémorables dans les années 80…
Mais je m'égare (du nord)
[^] # Re: Paname
Posté par chimrod (site web personnel) . Évalué à 2.
Pour repartir sur les vieilles photos et dans l'échange de lien, il y a aussi les photos de l'exposition universelle de 1900 :
http://www.laboiteverte.fr/paris-pendant-lexposition-universelle-de-1900/
Ce site est une mine pour tout ce qui est photo et imagerie…
[^] # Re: Paname
Posté par be_root . Évalué à 1.
waaaah Urban sax !
Ma jeunesse me sauta à la gueule d'un coup, je les avais oublié, il existent encore.
Merci, j'ai bien fait de me connecter ce soir :-)
Il se prend pour Napoléon, son état empire.
# Dépêche
Posté par weeber (site web personnel) . É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 CrEv (site web personnel) . Évalué à 2.
Pour ma part j'en pense que c'est une idée intéressante mais :
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
[^] # Re: Dépêche
Posté par Ago . Évalué à 1.
Pour ceux qui aiment bien ce genre de fils vous avez http://devopsweekly.com/ qui est pas mal dans le genre.
[^] # Re: Dépêche
Posté par BAud (site web personnel) . Évalué à 3.
si tu en retrouves d'autres, tu peux ajouter le tag veille_technologique :)
# Review
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Oui.
Oui.
Review Board.
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 CrEv (site web personnel) . É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.
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 Guillaume Denry (site web personnel) . Évalué à 2. Dernière modification le 06 juin 2012 à 16:33.
C'est encore le mieux oui, si on veut être rigoureux.
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.
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.
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.
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 CrEv (site web personnel) . É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 tippar 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 :
Bon c'est approximatif, fait rapidos, mais je pense que ça respecte en gros l'esprit de ce que je souhaiterais.
Oué, ça c'est avec des gens civilisés ;-)
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 Guillaume Denry (site web personnel) . Évalué à 3. Dernière modification le 06 juin 2012 à 21:17.
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".
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.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.