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

Justin Sandercoe, de justingguitar.com

Pour résumer, Justin a créé presque 500 cours de guitare en vidéo (en anglais, un grand nombre est traduit), accessibles gratuitement sur Youtube et sur justinguitar.

On trouve, notamment une progression de cours pour les débutants n’ayant jamais touché une guitare de leur vie (D Chord); des chansons décortiquées pour pouvoir jouer au coin du feu (Tears in Heaven, Eric Clapton) ; ou encore des explications pour réaliser des riffs de malades (Neon, John Mayer). Tout ça, accessible gratuitement.

On tombe des fois sur des vidéos de guitare sur Youtube : les gens jouent leur morceau, expliquent parfois leurs accords. Justin va plus loin, d’ailleurs il ne joue pas les morceaux en entier. Par contre il explique en détail toutes les parties de la chanson, la rythmique, ce qu’on peut ajouter, les petits trucs sympas.

Un petit exemple de ses excellents cours, sur la chanson Hurt, de Johnny Cash. Cette chanson fait partie de son songbook pour débutants. Il a prévu cette chanson pour la 6ème étape de son cours pour débutant. Pour résumer : c’est fastoche mais déjà sympa à jouer.

Bon, je vous vois venir avec votre question bassement matérielle : comment fait-il donc pour vivre ce brave homme ? C’est bien beau de piquer le boulot d’honnêtes profs de guitare, mais il faut quand même arriver à payer les pâtes (et les guitares, et les amplis).

C’est simple :

• Les internautes peuvent donner de temps en temps, ou tous les mois. Apparemment ça marche, je ne sais pas à quel point
• Justin vend également des DVD, des recueils de tablatures adaptés pour ses cours, et des cours thématiques. On peut les retrouver sur son magasin en ligne.

J’avais envie de le remercier pour sa générosité, et également le féliciter pour la qualité de son travail. Sincèrement, j’adore. Je m’y suis remis depuis peu mais le fil rouge qu’il a tracé permet de me motiver à jouer plus souvent, et je pense que j’ai déjà progressé plus que je n’aurais pu le faire tout seul !

À tous les autodidactes qui comprennent l’anglais, allez faire un tour sur le site de Justin. Perdez vous, fouillez, vous n’aurez qu’une envie : chopper votre gratte et jouer.

Sur le même sujet :

• Cours web dynamique, session 2

I looked for a way to chain ajax calls in jQuery 1.6 using new Deferred objects. My purpose was to wait for the response a call before sending the next.

Chaining, the old fashionned way

In a old fashionned jQuery way, we have to do something like that :

$.get("example1.php", function(data){
  // Do some stuff here
  // then launch the second call
  $get("example2.php", function(data){
    // Do some stuff here
    // then launch the third call
    $.get("example3.php", function(data){
      // You get the point
    });
  });
});

As you can notice, this code works well for a limited number of chained calls. But if you’d like to chain more calls, you’ll have to handle a lot of imbricated calls rendering the code a real mess. Even worse if you have to handle requests failures.

Chaining with Deferred and pipe()

I did not find an obvious example neither jQuery.com nor anywhere else on the internet. After investigating on how to do that with the new Deferred object in jQuery 1.6, I found a simple solution.

// First ajax call
$.get("example1.php")
  .done(function(data){
    // Do something here
  })
  // Second ajax call that have to wait for
  // the first response before being launched
  // You can use data received from the first call
  .pipe(function(data){
     // Take care of returning the new deferred object
     return $.get("example2.php");
  })
  .done(function(data){ /*Do something else*/ })
  // Third call : waits for the second response
  .pipe(function(data){
     return $.get("example3.php");
  })
  .done(function(data){ /*Do something else*/ });
  // You can repeat this stuff over and over

If you know a shorter version of this example, let me know : I’m interested !

Enchaîner les appels, la vieille école

Dans un style jQuery vieille école, ça donnerait ça :

$.get("example1.php", function(data){
  // Traitement des données
  // Second appel AJAX
  $get("example2.php", function(data){
    // Traitement des données
    // Troisième appel
    $.get("example3.php", function(data){
      // Vous avez compris l'idée
    });
  });
});

Ce code fonctionne bien pour un petit nombre d’appels à enchainer. Mais dès qu’on veut en enchaîner un certain nombre, on se retrouver avec beaucoup trop d’appels imbriqués qui rendent le code illisible. Le constat est encore pire si on doit gérer les erreurs des requêtes AJAX.

Enchainer les appels avec Deferred et pipe()

Je n’ai pas trouvé un exemple concret ni sur jQuery.com ni ailleurs sur internet. Finalement, après quelques investigations j’ai fini par trouver une solution assez simple

// Premier appel ajax
$.get("example1.php")
  .done(function(data){ /* Do something here */ })
  // Deuxième appel ajax, qui doit attendre la réponse
  // du premier pour pouvoir être lancé.
  // On peut réutiliser les données reçues par l'appel précédent.
  .pipe(function(data){
     // Bien retourner le nouvel objet deferred
     return $.get("example2.php");
  })
  .done(function(data){ /*Do something else*/ })
  // Troisième appel : attend la réponse du 2e
  .pipe(function(data){
     return $.get("example3.php");
  })
  .done(function(data){ /*Do something else*/ });
  // On peut répéter à l'envie.

Peut-être existe-t-il une version plus courte que cette dernière, si vous la connaissez, faites-la moi parvenir : ça m’intéresse.

Sur le même sujet :

• Benchmark des sélecteurs jQuery
• Cours web dynamique, session 2

Le Mont Aiguille

J’avais proposé à Cindy et Julien, suite à la sortie à l’Aiguille de la Persévérance, de les emmener faire de l’escalade en grande voie. Promesse tenue : nous sommes partis gravir le Mont Aiguille, avec en prime Franck et Marc qui ne se sont pas trop fait priés pour venir.

Clairon à 5h30 donc, dans un petit coin drômois paumé mignon, pour un décollage à 6h15. Quelques lacets plus tard, nous passons La Richardière puis voilà en bas de la marche d’approche. Note pour plus tard ; il est possible de s’avancer en voiture : la première aire de stationnement n’est pas la seule.

La marche d’approche nous fait gravir 600m de dénivelé pour atteindre le col de l’Aupet, et on a encore droit à 20min de marche pour rejoindre le bas de la voie normale. Il faut prévoir facilement 1h30 de marche en tout. Partis vers 8h du bas, nous sommes en haut vers 9h30 !

Dans la voie normale

Trois étant également la cotation maximum de la voie en question (en cotation d’alpinisme, cela donne du «  Peu Difficile  »), tout le monde a revêtu les grosses et laissé les chaussons dans le sac. L’ascension sera tranquille.

Le beau temps étant au rendez-vous on peut profiter du paysage : on a une vue imprenable sur les sommets du Vercors, avec le Grand Veymont juste en face.

Passage derrière le rocher de la Vierge

La grimpe est ponctuée de traversées, un passage derrière le rocher de la Vierge, on suit parfois même un sentier ! Bref : c’est assez varié, sympa et jamais difficile.

Au niveau des points, c’est jamais vraiment l’abondance, comme souvent en grande voie. Mais dans tous les passages les plus durs moins faciles on trouve un câble arrimé avec des énormes broches scellées. Le câble permet de se sécuriser si besoin, les broches servent de relai ou pour accrocher une dégaine.

Dernières longueurs dans la voie normale

Les dernières longueurs avant la sortie ne sont pas vraiment les plus agréable en termes d’escalade, mais il semble qu’elles aient plu. On franchit des ressauts dans une cheminée : il faut veiller à ne pas s’enfoncer dedans, chercher des prises de chaque côté.

Après 3h de grimpe, nous voici finalement sur le plateau du Mont Aiguille.

Sur le plateau du Mont Aiguille

L’escalade se « transforme » enfin en randonnée pour atteindre le sommet qui se trouve presque à l’opposé du plateau.

Vers le sommet

Assis là haut, on a un peu l’impression d’être sur une île, à 2000m d’altitude quand même. Les chocards viennent nous narguer en jouant avec le vent, en se posant comme des fleurs au sommet. Ça donne vraiment envie de revenir pour bivouaquer en haut, comme l’ont fait des grimpeurs croisés ce matin.

Après un pique-nique bien mérité, on repart vers la descente des Tubulaires. Je n’en ai pas de photos car j’ai souvent fermé la marche, posé ou lové la corde… Mais Franck en a quelques unes.

La descente commence par une suite de désescalades pas toujours très rassurantes, où la pose d’une corde peut s’avérer utile pour sécuriser certains passages ; et de descentes dans des pierriers. Je crois que ma grande hantise — probablement partagée par Franck à ce moment là — était de râter la bifurcation vers le rappel final. Du coup, on a passé en revue tous les passages qui semblaient partir vers la droite…

Note pour plus tard : le rappel final se trouve après un premier rappel d’environ 10m. Jusqu’à cette descente on peut difficilement se tromper de chemin : il faut continuer tout droit en suivant la pente. Le dernier relai est assez facile à trouver : légèrement sur la droite, sous un pin. On voit même la chaîne sans chercher.

Le rappel final de presque 50m est vraiment un moment sympathique après toutes ces descentes dans les pierres : on n’en voit pas le bout quand on s’y engage, il contient un passage en fil d’araignée et il faut se retourner pour la fin. Un joli rappel en résumé :p

Finalement, la descente nous aura pris presque autant de temps que la montée contrairement à ce à quoi on s’attendait…

En bref, ce fut une sortie sympathique : se retrouver entre amis et grimper dans un cadre aussi joli, que demander de plus ?

J’avais pu photographier la dernière éclipse partielle de soleil par chance : cette fois-ci j’avais prévu le coup. Il a suffit d’un petit rappel quelques jours sur mon agenda et assez de temps pour embrigader François pour qu’une sortie photo soit prévue pour le jour J. On se retrouve alors 2 appareils photo chacun (reflex + hybride) trois trépieds, François a même un petit télescope dont on reparlera.

La lune se lève enfin, éclipse de Lune 15 juin 2011

L’éclipse étant prévue pour 22h14, un rendez-vous est fixé aux alentours de 21h30. Sauf qu’à cette heure ci, point de lune à l’horizon. À 22h, changement de tactique et on se rend sur une colline toute proche, histoire de dominer un peu la ville. Rien non plus. Est-ce parce que la lune est trop basse à l’horizon, ou est-ce à cause d’un léger voile nuageux à basse altitude ?

Il a fallu attendre 22h30 pour que François aperçoive la lune, très sombre, déjà relativement haute par rapport à l’horizon. Il faut se rendre à l’évidence : les photos d’éclipse lunaires qu’on peut voir sont en général trompeuses. La lune n’est pas aussi rouge dans le ciel, pour la simple raison qu’elle est très très très très sombre. En exposant une photo comme il faut, on arrive à la voir plus facilement, d’où cette couleur et cette clarté qui ressort. Mais regardez la photographie que j’ai publié : on voit les étoiles à droite. C’est un signe d’une très faible luminosité !

Éclipse de Lune 15 juin 2011

Entre 22h30 et 23h15, on a … mitraillé. En essayant différents réglages, différents points de vue.

Puis, une fois l’éclipse finie et la lune redevenant pleine, François a sorti son télescope. Pour la lune en gros plan, et puis, on a essayé de mettre un appareil photo au bout de l’oculaire, juste pour voir.

Et ça marche ! Il est assez difficile de rester dans l’axe, et la mise au point est hasardeuse. Mais on arrive quand même à en tirer quelque chose.

La lune au GF1 + 20mm derrière un télescope

À refaire donc … en 2014 ! Mais mon petit doigt me dit qu’on reparlera de ce petit télescope, avec — cette fois — une bague d’adaptation qui va bien.

Notes :

1. Une éclipse est prévue le 10 décembre 2011 à 14h UTC, je doute qu’elle soit visible en Europe de l’Ouest. La NASA semble indiquer qu’elle sera visible en Europe sans plus de précisions. [retour].

Sur le même sujet :

• L’éclipse partielle du 4 janvier
• Jupiter (et la Lune)
• Pleine lune