Photos du challenge

Je me suis permis de faire une petite sélection que je vous propose. Dans un ordre arbitraire issu de l’ordre des dernières photos publiées, voici donc les participants et une sélection de photos.

Julien

[flickr] [blog]

Pour sa première participation, contrat rempli avec talent ! Julien a proposé des photos pleines de couleur et souvent très graphiques / géométriques. Il nous présente également parfois des curiosités locales

Y’a juste un truc : c’est pas bien de narguer les gens avec des photos du Yosémite.

François aka franlero

[flickr]

Il a bouclé sa deuxième participation avec autant de brio que la première — voire plus ! J’ai l’impression que François a fourni des photos plus travaillées (en post production mais aussi à la prise de vue) que la fois précédente. Me trompe-je ?

Belle série, avec de la variété de qualité. Beaucoup de couleurs, des photos plus graphiques.

Et puis bon, y’a la bourde : la photo de l’OL !

Tim aka timothep

[flickr] [blog]

Tim est un vieux renard du PADC, et je crois bien qu’au fur et à mesure il a pris goût à se mettre en scène ! Et c’est même devenu contagieux.

Tim en tout cas aime faire sourire avec ses mises en scènes ou ses montages, toujours pleins d’humour. Il aime également partager ses bons moments avec nous.

Et grâce à lui, on connait maintenant la recette (inratable) de la brioche.

Franck aka herisson26

[flickr] [blog]

Franck, également un vieux routard du PADC, avait prémédité une belle série homogène pour cette année. Il avait prévu de se mettre en scène chaque jour, avec un traitement identique à chaque fois. Du noir et blanc très très contrasté, granuleux, à l’ancienne quoi !

Disons qu’il s’est mis à nu devant nous (oui, bon, je sais, elle était facile).

Toujours est-il que — peut-être — l’année prochaine Franck n’oubliera pas sa dernière photo. :p

Hervé

[flickr] [blog]

Hervé, un participant de la première heure qui récidive. Il nous propose des images du quotidien, petites tranches de vie. Il va quand même falloir qu’il nous explique cette attirance pour les immeubles et les antennes télé !

Et sachez-le, les nèfles se dégustent quand elles sont tâchées.

Lisa

[flickr]

Lisa qui honore sa deuxième participation en nous proposant une série ensoleillée (chanceuse !) et gaie. En un sens, ses photos sont à l’extrême opposées à celles de Franck. Amusant.

Je pense que tout le monde s’accorde sur la photo du moineau narcissique !

Céline aka enilec84

[flickr]

Céline a relevé le défi et c’était pas gagné compte tenu des événements. Bravo à elle ! Merci pour les petites fleurs, les couleurs, les photos rigolotes et les photos trop mignonnes !

Par contre, juste un truc, on n’a pas précisé qu’on ne martyrisait pas les animaux pour les besoins du PADC. Donner du chewing-gum à des poissons, c’est quand même pas très sympa.

Mon bilan

Tout d’abord, j’ai particulièrement apprécié — comme à chaque édition — cette relation particulière qui se noue entre les différents participants. Nous formons pendant un mois un petit groupe, on suit à peu près quotidiennement les publications de chacun. On découvre des styles, on pioche des idées. C’est vraiment l’aspect le plus positif de cet exercice, à mon sens.

Concernant mes photos, j’ai trouvé que mes photos étaient moins souvent recherchées que les années précédentes. Est-ce par manque de temps ? Probablement en partie. Toujours est-il que le simple fait de participer au challenge m’a fait prendre plus souvent l’appareil avec moi, et je pense avoir pris plus de photos, même personnelles pendant cette période. Photographiquement parlant, c’est donc un bilan relativement mitigé de mon côté.

J’espère faire mieux la prochaine fois !

Enfin, si je devais retenir quatre photos, ça serait les suivantes.

La première est une que je m’étais promis de ne pas publier pour le PADC. Mais … impossible de résister à cette petite main qui agrippe le doigt de sa maman.

La deuxième illustre est issue des rares fois où je suis sorti du train train quotidien et où j’ai essayé de trouver une photo. En plus avec ce temps de Mars qu’on a eu en Avril, ça donne des couleurs et des contrastes intéressants.

La troisième est la trouvaille dont je suis particulièrement content, en cette période d’élections. L’idée m’est venue d’un coup en parcourant les tracts des candidats. On se rend compte que le portrait pour ce genre d’exercice est très codifié !

Enfin, une discussion m’a fait me remémorer une série de Julian Wolkenstein sur la symétrie des visages. Ça m’a donné envie de faire la même chose sur ma pomme. Évidemment, ça fait ressortir l’asymétrie de mon visage !

Et vous ?

Qu’avez-vous pensé de ce PADC 2012 ? De vos photos, de ce que vous avez découvert, appris, ou changé ?

Enfin, sur le principe du PADC ?

Encore merci d’avoir participé, et bravo à vous !

Les bilans:

• Franck
• Tim
• Julien

Sur le même sujet :

• Photo a day challenge 2012
• Photo a day challenge : J-4
• Photo a day challenge 2

L’objet du délit ? L’écran de connexion à son espace abonné, qui demande d’entrer un numéro client et un mot de passe. Jusque là, rien d’anormal. Sauf que je n’arrive pas à comprendre pourquoi ils ont fait comme suit.

Écran de connexion à l’espace abonné free mobile

Ce qui m’agace

Pour entrer le numéro client, il faut utiliser leur pavé numérique aléatoire. Par contre, pour le mot de passe, un champ HTML standard est utilisé, permettant au navigateur d’enregistrer sa valeur.

Plusieurs remarques me viennent à l’esprit.

Tout d’abord, c’est très gentil de s’assurer que le navigateur ne puisse pas se souvenir de notre numéro client. C’est un numéro très facile à retenir à 8 chiffres aléatoires, d’ailleurs je m’en souviens par cœur… En fait non. Par contre, le mot de passe que j’ai choisi moi même, ça, le navigateur s’en souviendra pour moi.

Parlons ensuite sécurité informatique. Dans ce domaine, on considère qu’un identifiant n’est pas spécialement secret, contrairement à un mot de passe. Or ce genre de pavé numérique est justement utilisé par les banques, en général pour éviter qu’un logiciel espion vous pique votre mot de passe. Pas de bol, Free mobile protège une donnée pas forcément sensible…

Bon évidemment, le dernier point de rabat-joie que je suis : l’accessibilité, et elle est nulle. Ou alors je ne sais pas comment on s’en sert. Mais j’ai été incapable de remplir tout ça sans souris. Et quand bien même vous arrivez à cliquer sur « aide vocale » (sans savoir où le bouton se trouve), vous êtes sensé survoler les boutons à la souris et la voix vous dit sur lequel vous êtes. Super. Est-ce vraiment utilisable quand on ne voit rien ?

Tout ça pour protéger votre compte ? On peut y faire quoi ? Activer une option ? Ouahhhhhh.

La solution (simple)

Il y a pourtant d’autres manières de faire. En voici une, simple, sécurisée, ergonomique.

1. Mettre des champs standard numéro client / mot de passe.
2. En cas d’activation d’option ou autre modification critique, envoyer un code de confirmation par SMS ou par mail.

Mais par pitié, changez ça !

Sur le même sujet :

• Posh : problème de sécurité
• Posh : rustine sur portaneo.com
• Entrevue avec un des casseurs de captcha de Yahoo

Une photo par jour

Les règles du jeu sont enfantines : prendre une photo par jour pendant le mois d’avril. Et pour que tout le monde puisse en profiter, publier cette photo dès que possible sur le groupe flickr. Il n’y a évidemment pas obligation de publier dans la journée !

Le PADC n’est pas un concours : il n’y a pas de gagnant ni de perdant, pas de compétition. C’est juste un rassemblement éphémère de photographes d’horizon et sensibilités différents autour d’une passion commune.

La durée est volontairement à la fois assez longue pour passer le cap des photos faciles et assez courte pour ne pas se lasser (même après trois participations). Le PADC est un exercice très formateur d’abord parce qu’on tente beaucoup de nouvelles choses, et aussi parce qu’on profite des photos des autres participants.

Les éditions précédentes

Tout a commencé en 2008 avec une simple question : «  qui est partant ?  ». Huit participants ont relevé le défi sur flickr (d’autres sur leur blog perso).

PADC 2008 (extrait)

En 2009, 34 membres ont dit chiche en s’inscrivant sur le groupe flickr et en proposant pas moins de 552 photos !

PADC 2009 (extrait)

Lancez-vous !

Cette année, le groupe flickr est créé et vous pouvez déjà le rejoindre.

Je souhaite que le PADC de cette année soit aussi passionnant que celui des années précédentes, et qu’il suscite autant de réactions. Rejoignez-nous et participez à ce petit voyage photographique d’un mois !

Alors chiche ?

Si vous voulez en savoir plus sur les éditions précédentes:

• PADC 2008 (lancement)
• Groupe flickr PADC 2008
• Ma sélection des photos (PADC 2008)
• Mon bilan du PADC 2008
• PADC 2009 (lancement)
• Groupe flickr PADC 2009
• Mon bilan du PADC 2009

Sur le même sujet :

• Photo a day challenge 2012 : the end
• Photo a day challenge : J-4
• Photo a Day Challenge : semaine 2

Clean code: A Handbook of Agile Software Craftsmanship

Clean code est un livre que tous les développeurs devraient lire. Et je pèse mes mots.

Étrangement, il ne m’a pas transcendé pendant la lecture elle-même. En fait, j’avais l’impression que l’auteur ne m’apprenait pas forcément grand chose. En tant que développeur, vous voyez du code toute la journée, vous savez dinstinguer un code source pourri d’un bon code.

Le truc, c’est que cette lecture mûrit. Et une fois devant un fichier source, on ne peut s’empêcher de repenser à ce bouquin. On se rend compte qu’à tel endroit on devrait procéder autrement pour rendre le code plus compréhensible, qu’à tel autre il faudrait renommer une variable etc…

Et surtout, on ne peut plus s’empêcher de mettre son grain de sel.

Un code soigné

Il est assez facile de reconnaitre un code tout pourri, illisible. On repère les paquets de nouilles à des lieues à la ronde. Mais arriver à définir de qui caractérise du code soigné est un exercice plus périlleux.

L’auteur Robert C. Martin propose plusieurs définitions, dont la sienne. Il cite également quelques collègues, et je me permets de reprendre à mon tour une partie de définition qui me semble tomber juste.

Clean code is simple and direct. Clean code reads like well-written prose.

---

Un code soigné est simple et direct. Il se lit comme de la prose bien écrite.

Grady Booch, author of Object Oriented Analysis and Design with Applications

Suivie par une explication de l’auteur.

Reading clean code will never be quite like reading Lord of the Rings. Still, the literary metaphor is not a bad one. Like a good novel, clean code should clearly expose the tensions
in the problem to be solved. It should build those tensions to a climax and then give the reader that “Aha! Of course!” as the issues and tensions are resolved in the revelation of an obvious solution.

---

Lire du code soigné ne s’approchera jamais de la lecture du Seigneur des Anneaux. Cependant, la métaphore littéraire n’est pas mauvaise. Comme un bon roman, un code propre devrait clairement révéler le problème à résoudre. Il devrait révéler des tensions jusqu’à un paroxysme et ensuite donner au lecteur ce « Aha ! Bien sûr ! » lorsque les problèmes et tensions sont résolues dans la révélation d’une solution évidente.

Robert C. Martin, Clean Code

The boy scout rule

Si je devais retenir une chose de ce livre, c’est la boy scout rule (règle du boy scout).

Leave the campground cleaner than you found it.

---

Laisse le campement plus propre que tu l’as trouvé

Chaque fois que vous allez lire du code améliorable (pour ne pas dire pourri), à cause de ce livre et de cette règle vous ne pourrez plus hésiter entre laisser en l’état (si ça marche, on ne touche pas) et changer les choses.

La première solution est la plus facile, mais elle permet à du code pourri de perdurer, elle entretient la dette technique d’un logiciel. C’est la solution conservatrice qui est souvent préférée.

La deuxième solution permet d’améliorer continuellement la compréhensibilité du code source, donc de faciliter sa maintenance et la correction de bugs. Elle est plus risquée, mais se fait sans trop d’arrières pensées si le code est testé. Et s’il ne l’est pas, le fait d’écrire un test entre aussi dans cette catégorie.

Un livre à lire

Je vous passe les détails des différents chapitres abordés par ce livre, chacun couvre un domaine de la propreté du code. On y aborde principalement :

• le nommage des variables, classes et fonctions ;
• le contenu des fonctions, les arguments ;
• les commentaires (dans un sens un peu inattendu mais finalement intéressant) ;
• les objets et structures de données ;
• le formattage du code ;
• les classes, leur taille, organisation et responsabilité ;
• les tests unitaires.

L’auteur nous a tout de même gratifié d’une étude de cas d’un chapitre (chapitre 14) qu’on peut facilement passer. C’est le seul point négatif de ce livre qui se lit quand même globalement très aisément (au final, il y a peu de code).

Malgré cette partie pesante, le livre vaut vraiment le coup. Clean Code est un livre au premier abord anodin mais qui a fait évoluer ma manière de développer. Je ne dis pas que ce que je produits est devenu subitement parfait. Qui peut prétendre à ça ? Mais je pense mieux faire, et j’ai surtout moins de scrupules à intervenir dans du code que je croise au détour d’un débug.

• Clean Code [broché]
• Clean Code [kindle]

J’ai tenté d’utiliser un balisage HTML5 plus sémantique dans le code source de mon blog. J’ai utilisé notamment la balise article pour délimiter le contenu des articles, la balise nav pour le menu supérieur et aside pour la colonne de droite.

La balise article permet de délimiter les différents articles de la page, c’est à dire le vrai contenu, pour le différencier d’éléments de navigations (délimités par nav) ou d’autres éléments se rapportant au site (balise aside). Je pensais que ça suffirait, mais il semble que google se fiche complètement de cette sémantique.

Finalement, j’ai trouvé comment arriver à mes fins avec les microformats documentés sur le site de www.schema.org. Ça donne un code qui ressemble au suivant.

<article itemscope itemtype="http://schema.org/Article">
  <h1 itemprop="name">
    <a itemprop="url" href="article.htm">Titre de l'article</a>
  </h1>
  <div itemprop="description">
    <p>Contenu ou résumé de l'article ici</p>
    <p>...</p>
  </div>
</article>

Ce qu’il faut retenir:

• La balise HTML qui contient un élément complet doit être identifiée par l’attribut itemscope
• Le type de contenu doit être identifié avec l’attribut itemtype dont la valeur est une url décrivant le type. La liste des types peut être trouvée sur le site schema.org.
• Le titre de l’article doit être identifié avec l’attribut itemprop="name"
• Le contenu de l’article doit être identifié avec l’attribut itemprop="description"

Il semble que cet ensemble constitue le minimum vital pour avoir des microdonnées correctes, et interprétées par google plus.

Démonstration en images.

Description détectée par google plus

Puis après avoir ajouté l’image et l’attribut itemprop="image"» (sans cette image, il n’utilisait pas le logo google+ comme description, même avec le bon attribut, je ne sais pas pourquoi).

Description et image détectées dans google plus

Sur le même sujet :

• Le géoportail n’est pas un rival de Google Earth
• Google : Rechercher un visage
• Va-t’on sur Google avant de provoquer un génocide ?

jQuery

Je suis tombé sur un article intéressant il y a quelques temps: Your jQuery now with 67% less suck. J’y ai appris par exemple qu’il y a désormais plus de sites internet qui utilisent l’excellent jQuery que Flash.

Mais on y découvre également des astuces pour permettre à son code jQuery d’être plus performant. Beaucoup de ces astuces sont basées sur la rapidité des sélecteurs utilisés à profusion par jQuery.

On nous dit par exemple que $("#id").find("p"); est deux fois plus rapide que $("#id p");, pour un effet égal.

J’ai voulu aller plus loin dans cette analyse de rapidité des sélecteurs, en faisant un benchmark.

Protocole

Le code source du benchmark est disponible, utilisable et modifiable. Le projet est sur github et je vous invite à y jeter un coup d’œil.

Certains tests ne sont pas directement comparables, comme par exemple celui qui concerne le sélecteur :even qui renvoie les éléments pairs.

Tous les sélecteurs ont été testé en utilisant container.find(selecteur), c’est le moyen que j’ai trouvé pour avoir des résultats comparables entre sélecteurs. On verra que ce choix a pu avoir un impact sur les benchmarks eux-même.

Comparaison des sélecteurs

Ces tests ont été effectués sous Chrome, la hierarchie est globalement la même sous d’autres navigateurs à quelques exceptions près. Mais pour comparer les sélecteurs entre eux, j’ai préférer le faire avec un seul navigateur.

Nous verrons par la suite une comparaison des navigateurs.

Les plus rapides

Sélecteurs les plus rapides (échelle log)

Le palmarès est à peu près le même pour Chrome et Firefox (on note des différences avec Opera et IE, mais nous y reviendrons). Attention, l’échelle est logarithmique !

Sans aucune surprise, le sélecteur #id est le plus rapide. Il profite évidemment de la fonction native document.getElementById() implémentée par les navigateurs.

On remarque également que sélectionner un élément avec son identifiant est à peu près 5 fois plus rapide que de le faire en connaissant sa balise HTML, et que ce sélecteur est le deuxième plus rapide.

Les plus lents

Sélecteurs les plus lents (échelle log)

Pour mettre en relief ces données, il convient de comparer les échelles avec le graphique du dessus. Le sélecteur .class permettait d’effectuer 60000 opérations par seconde. Ici, le sélecteur [attr!=val] a une vitesse de 300 opérations par seconde. Le second est donc 200 fois plus lent !

On note également que d’utiliser la méthode .find() sur un objet jQuery semble très pénalisant, avec une performance parmi les plus mauvaises du benchmark. Cette mesure va à l’encontre du conseil donné par l’article Your jQuery now with 67% less suck. Mais nous y reviendrons.

Sélecteurs classiques

Sélecteurs de base (échelle log)

Les sélecteurs de base, liés aux attributs id, class ou aux balises. L’échelle logarithmique est trompeuse, mais c’était le seul moyen de tout mettre sur le même histogramme : le sélecteur d’identifiant est 4 fois plus rapide que le sélecteur de classe.

On remarque aussi que Internet Explorer 8 est un veau. Ô surprise. Il est 19 fois plus lent que Chrome sur le sélecteur #id, dans ce benchmark.

Parcours du DOM

jQuery permet de sélectionner un élément en fonction de la hierarchie de ses parents. Par exemple, avec le code HTML suivant, on dispose de plusieurs moyens pour sélectionner le paragraphe contenu dans l’élément div.

<div>
  <p>Balise à sélectionner</p>
</div>
<p>Ne pas sélectionner</p>

On peut utiliser une des solutions suivantes.

var withSelector = $("div p");
var withFind = $("div").find("p");
var withArguments = $("div", "p");

Cependant, les benchmarks montrent des performances différentes pour les trois méthodes.

Parcours de DOM (échelle log)

Il semble que la solution préconisée en général soit la plus lente dans la configuration testée ici ! En effet, la méthode .find() a montré les performances les plus faibles en étant 100 fois plus lente que le sélecteur classique a b.

Sélecteurs d’attributs

Sélecteurs d’attributs (échelle log)

Ces sélecteurs ont à peu près les mêmes performances, sauf le sélecteur [attr!=foo] qui permet de sélectionner des valeurs différentes de celle indiquée. On peut également remarquer que Opera semble être particulièrement optimisé pour traiter ces requêtes. En effet, Opera est en général un peu moins de 10 fois plus rapide que Chrome et plus de 50 fois plus rapide que IE8 sur ces sélecteurs.

Sélecteurs liés aux formulaires

Sélecteurs liés aux formulaires (échelle log)

J’ai regroupé au sein d’un test spécifique tous les sélecteurs permettant d’accéder à des champs de formulaires. Ce qui est intéressant, c’est qu’on trouve des performances assez médiocre en comparaison des sélecteurs d’attribut. Pourtant, ces sélecteurs font en théorie le même travail !

// Ces deux sélecteurs sont équivalents
// mais n'ont pas les mêmes performances
var passwordInput = $(":password");  // 10x plus lent
var passwordAttribute = $("[type='password']");

Pour confirmer, j’ai créé un test spécifique permettant de comparer les sélecteurs dans des conditions identiques.

Comparaison des sélecteurs équivalents (échelle log)

Globalement, on gagne énormément en performance en n’utilisant pas ces sélecteurs spécifiques, que sont :input, :password etc… Seuls :enabled et :selected semblent correctement gérés par les navigateurs.

Performances des navigateurs

Ce benchmark n’avait pas à l’origine pour but de comparer les navigateurs. D’ailleurs, je n’ai pas IE9 ! Si certains sont intéressés pour faire leurs propres tests, le code source de ce benchmark est disponible sur github. Vous pouvez l’utiliser, le modifier et soumettre des modifications.

Malgré tout, je ne résiste pas à l’envie de faire un comparatif global.

Performance globale sur les sélecteurs testés (échelle log)

Sur ce benchmark, Opera se démarque en partie grâce aux optimisations liées aux sélecteurs d’attributs. Chrome s’en sort mieux que Firefox. Et enfin Internet Explorer 8 (version obsolète, à leur décharge), est clairement à la ramasse.

Sur le même sujet :

• Chain AJAX calls using jQuery 1.6

Onglets contenant des iframe

En ouvrant et fermant des onglets contenant un iframe, on se rend compte que la mémoire n’est jamais libérée par le navigateur. Les mesures ont été réalisées avec Internet Explorer. J’ai observé le même comportement avec Google Chrome. Firefox semble libérer correctement sa mémoire.

Évolution de la mémoire avec ouverture / fermeture d’onglets contenant un iframe

Il existe un petit truc pour permettre de libérer cette mémoire, et il faut le savoir. Je vous en fait donc profiter:

// Avant de retirer l'iframe du DOM
$("#container iframe").attr("src", "javascript:false");

// Ou au sein du code de l'iframe lui-même
// Dans le cas où vous avez accès à un événement avant la fermeture
window.location = "javascript:false"

Le résultat devient alors:

Utilisation mémoire lors de la création / suppression d’iframe

De même, ces mesures ont été réalisées sous Internet Explorer. La version 15 de Google Chrome ne semble par contre pas libérer la mémoire avec ce petit « truc ».

On observe que la mémoire utilisée ne redescend pas forcément au même niveau qu’avant la création de l’iframe, mais la mesure de mémoire utilisée par un processus n’est pas très précise. Et le comportement dépend beaucoup de la gestion mémoire du navigateur lui-même.

Est-ce du mauvais matériel ? Sincèrement, non.

J’ai (j’avais) un Canon EOS 40D, modèle de 2007. Je continue de penser que malgré son âge, c’est toujours un très bon boitier d’actualité. Mon objectif standard ? Un Canon 17–55 f2.8 IS USM : je l’adore ! Pour accompagner tout ça, un 70–200 f4 série L qui vaut largement sa réputation.

Canon EOS 40D + 17–55

L’arrivée du GF1 dans ma besace a tout changé. J’ai retrouvé une bonne qualité des photos, avec un encombrement et un poids très très très inférieurs. Certes, quelques compromis sont obligatoires, mais ce petit appareil a simplement relégué la grosse artillerie au placard.

Panasonic Lumix GF1

Plus globalement d’ailleurs, sur le marché des appareils photos, l’arrivée des appareils hybrides est en train de tout changer. Moins gros, moins lourds mais offrant une qualité d’image bien meilleure que ce qu’offrent les compacts.

Bref, Adios EOS.

PS: J’ai encore un 40D à vendre, ainsi qu’un objectif 70–200 F4L et un flash sigma 530DG Super.

Sur le même sujet :

• Nouveaux joujoux arrivés
• Panasonic GF1 : après 2 mois d’utilisation

Rework — Jason Fried, David Heinemeier Hansson

Pour la petite histoire, les auteurs Jason Fried et David Heinemeier Hansson sont les fondateurs de 37signals. Cette entreprise propose des outils collaboratifs web à usage professionnel (ils appellent ça des productivity tools, des outils pour être productifs).

Mais on doit surtout à ces deux acolytes la création du framework Ruby on Rails, qui a créé une vraie rupture dans le développement web depuis sa sortie. Après avoir été le framework qui monte, il est devenu celui qu’il faut connaitre.

Jason Fried a également donné une conférence TED sur le thème Pourquoi on ne travaille pas au travail (Why work does not happen at work), thème extrait de Rework.

Rework: le livre

Les auteurs présentent leur recette du succès d’un produit, d’une entreprise, basée sur leur expérience d’entrepreneurs du web. Si leur précédent livre, Getting Real (nous y reviendrons) était clairement axé sur la création d’une application web ; Rework couvre un champ plus large.

It’s time to rework work. Let’s get started.

---

Il est temps de repenser le travail. C’est parti.

Le livre est organisé autours de chapitres contenant un nombre variable d’idées. Chaque idée est présentée par une phrase d’accroche et par une ou deux pages d’explications. Rework est donc très rapide à lire, mais cela ne veut pas dire qu’il ne soit pas dense.

Beaucoup d’idées sont présentées en peu de mots, mais ils font mouche.

Ce que je retiens

Rework est un livre qu’on est amené à feuilleter et re-feuilleter, lire et relire assez souvent au fil du temps. Une situation au travail nous rappelle quelque chose qu’on a lu, et tout d’un coup l’idée expliquée dans ce livre fait mouche alors qu’on l’avait survolé auparavant. Il est probable que ce que je retiens aujourd’hui soit légèrement différent de ce que je retiendrais de ce livre dans quelques années.

Moins, c’est un plus

Les auteurs de Rework prônent la frugalité à plusieurs niveaux : une petite équipe, un temps et des ressources limitées, et en faire peu (le faire bien).

Les trois idées sont étroitement liées : avec une équipe plus petite, et pas d’argent/de temps, il faut en faire moins. Sauf que plutôt que d’accepter cette situation comme une contrainte, Jason et David nous présentent cette approche comme un choix assumé.

Une petite équipe permet de s’adapter, de réagir aux imprévus, de se réorganiser pour faire face aux événements. Bref, une petite équipe est agile, ses membres communiquent plus facilement, et comme chacun doit faire un peu de tout, l’équipe en entier est plus impliquée dans le produit final. Cette idée se décline de plusieurs manières, et par exemple sur les recrutements.

Hire when it hurts

The right time to hire is when there’s more work than you can handle for a sustained period of time. There should be things you can’t do anymore. You should notice the quality level slipping. That’s when you’re hurting. And that’s when it’s time to hire, not earlier.

---

Embauchez quand ça fait mal

Le bon moment pour embaucher est quand il y trop de travail par rapport à ce que vous pouvez gérer pendant une période prolongée. Il devrait y avoir des choses que vous ne pouvez plus faire. Vous devriez remarquer que le niveau de qualité baisse. C’est à ce moment que ça fait mal. Et c’est qu’il est temps d’embaucher, pas avant.

Cette approche m’a assez étonné à la première lecture. Mais en y repensant, et en repensant aux expériences du monde professionnel, ce conseil est précieux.

L’autre point appuyé dans ce thème «  Less is More  », est tout simplement d’en faire moins. Sous entendu: « mais le faire bien ».

Build half a product, not a half-assed product

You can turn a bunch of great ideas into a crappy product real fast by trying to do them all at once. You just can’t do everything you want to do and do it well. You have limited time, resources, ability, and focus. It’s hard enough to do one thing right. Trying to do ten things well at the same time? Forget about it

---

Créez un demi produit, pas un produit foireux

Vous pouvez très rapidement transformer un tas d’idées géniales en un produit merdique en essayant de toutes les réaliser à la fois. Vous ne pouvez pas faire tout ce que vous voulez et le faire correctement. Vous avez un temps, des ressources, des compétences et une concentration limités. Il est suffisamment difficile de faire une seule chose correctement. Essayer d’en faire dix à la fois ? Oubliez.

Et là, c’est du vécu. Même si ça semble tomber sous le sens, dans « la vraie vie » c’est très difficile à faire passer. Toutes ces choses qui semblent indispensables sur le moment ne le sont pas, et on s’en rend compte souvent trop tard.

Réduire l’étendue d’un projet implique de savoir dire non à beaucoup de personnes, et de le dire. Dire non à ses propres idées, dire non aux futurs clients qui ont « absolument » besoin de telle ou telle chose, dire non aux demandes d’améliorations des clients actuels. Même si on peut accepter le principe d’un produit limité, quand vient le temps de dire non l’expérience montre que cette posture est difficilement tenue.

Sortir un produit, maintenant

Là encore, on retrouve dans ces idées abordées par Jason et David des principes du développement agile. Celui-ci est également très appuyé : il faut sortir quelque chose.

Cette idée vaut pour la mise sur le marché du produit, comme pour les phases de recette. Le principe est simple : confronter le plus rapidement possible le produit à ses utilisateurs.

Pourquoi ? Parce qu’il y a toutes les chances qu’en écoutant ceux-ci vos priorités changent, et que votre produit s’améliore plus efficacement.

Launch now

Don’t hold everything else up because of a few leftovers. You can do them later. And doing them later may mean doing them better, too.

Don’t mistake this approach for skimping on quality, either. You still want to make something great. This approach just recognizes that the best way to get there is through iterations. Stop imagining what’s going to work. Find out for real.

---

Lancez-le maintenant

Ne retenez pas tout à cause de quelques points restants. Vous pouvez les faire plus tard. Et les faire plus tard signifie aussi mieux les faire.

Ne confondez pas non plus cette approche avec une reduction de la qualité. Vous voulez toujours quelque chose de grand. Cette approche reconnait seulement que le meilleur moyen d’y arriver est en itérant. Arrêtez d’imaginer ce qui va marcher. Découvrez-le pour de bon.

Autres idées

Je ne vous ai donné qu’un petit aperçu des idées abordées dans Rework. On y parle aussi beaucoup de recrutement, d’organisation du travail, de gestion de crise, et j’en passe. Le livre est très intéressant, et on se plait à parcourir de temps en temps son contenu à la recherche d’un chapitre dont on se souvient.

Par exemple, un petit point qui plaira beaucoup en France (avec cette culture de rester tard au bureau pour montrer qu’on bosse). Je précise que 37signals est une entreprise à Chicago, on ne peut pas dire que ça soit la culture 35 heures.

Send people home at 5

When people have something to do at home, they get down to business. They get their work done at the office because they have somewhere else to be. They find ways to be more efficient because they have to. They need to pick up the kids or get to choir practice. So they use their time wisely.

---

Renvoyez les gens chez eux à 5h

Quand on a quelque chose à faire à la maison, on va droit au but. On finit ce qu’on a à faire au bureau parce qu’on a ailleurs où aller. On trouve des moyens d’être plus efficace, parce qu’on n’a pas le choix. Il faut aller chercher les enfants ou se rendre à la chorale. On utilise donc notre temps judicieusement.

Je pourrai continuer encore longtemps comme ça, mais mon article risque de reprendre l’intégralité du (très court) livre.

C’est le genre de livre qu’on aimerait prêter, et en tout cas qu’on aime conseiller !

Liens

• Rework sur amazon, et le site officiel
• Getting Real sur amazon, et le site officiel
• Conférence TED Pourquoi on ne travaille pas au travail (Why work does not happen at work)
• Ruby on Rails sur wikipédia

Jupiter !

J’avoue, la qualité de la photo n’est pas vraiment à la hauteur de ce qu’a pu nous envoyer la sonde Voyager 2 (voir les photos sur wikipedia), mais j’ai quand même réussi à photographier Jupiter !

À l’origine, j’ai ressorti mon objectif MTO 1000AM, pour photographier la Lune. Ces derniers soirs, elle était particulièrement lumineuse avec un ciel dégagé. J’ai donc pris quelques photos : j’ai testé l’objectif seul, puis j’ai ajouté un doubleur de focale sur ce mastodonte.

MTO 1000AM + 40D

Il semblerait d’ailleurs que le doubleur me fasse gagner en définition, c’est bon à savoir. Il faut prendre plusieurs photos et les assembler par la suite pour obtenir une image complète de la Lune. En comparant le résultat avec une photo sans doubleur, on remarque des détails plus fins sur la photo à 2000mm.

Logique ? Pas forcément, car je pensais que l’objectif était limitant en définition, pas mon boitier. Sur les photos prises à 1000mm, on distingue difficilement des détails de quelques pixels. Or en ajoutant un élément optique (loin d’être parfait), il n’est pas évident d’avoir une meilleure image. Pourtant, c’est bien ce que j’ai observé.

Le résultat peut être visible ci-dessous : une photo de la Lune, plein cadre. On voit bien les reliefs sur la droite, la lune n’étant pas tout à fait pleine. Les cratères deviennent plus visibles.

La lune, 40D + MTO 1000AM + doubleur

Bref, revenons à nos moutons : Jupiter. En photographiant la Lune, j’ai remarqué un point très lumineux en bas à gauche de celle-ci. Un point qui ne scintillait pas : c’est un indice. En orientant l’appareil vers ce point … je distingue Jupiter ! Étant donné mon ignorance en astronomie, c’est un vrai coup de bol.

Après la prise de quelques renseignements sur l’observation des planètes (Jupiter, Saturne). Il semblerait que l’on s’approche de la période la plus favorable pour observer Jupiter : le meilleur moment étant fin octobre 2011.

Distance Terre-Jupiter, magnitude (planetobs.com)

Chose que j’ignorais jusqu’à maintenant : la magnitude est une mesure de luminosité, l’échelle est inversée. Plus la magnitude est faible, plus l’objet est lumineux. Jupiter est observable la nuit quand elle est proche de nous (ce qui est pas mal logique).

Juste par curiosité, j’ai regardé ce qu’il en était pour Saturne : il va falloir être un peu patient.

Distance Terre-Saturne et magnitude (planetobs.com)

J’ai quand même noté dans un coin de ressortir le barda pour mi-avril. C’est à ce moment que Saturne devrait être plus proche de la Terre, et observable. Pourrais-je distinguer les anneaux ?

Source:

• Planetobs
• IMCEE, pour le calcul des éphémérides : distance, magnitude, heure de lever/coucher.

Sur le même sujet :

• Pleine lune
• L’éclipse de lune du 15 juin 2011
• Dites moi si j’me goure mais