Pfiou… Déjà presque trois mois depuis la première partie… Bon, j’ai des excuses hein, vous vous en doutez bien ! Entre temps j’ai déménagé, terminé mon master (et en plus je l’ai eu !), fêté Noël, euh… dormi, mangé, enfin bref. J’ai eu beaucoup de mal à écrire cette partie, mais elle est finie depuis un mois. Comme je trainasse à écrire le compte rendu des deux dernières conférences, je me suis dit que ça vous plairait de lire celle de Karl.

Pour 2010 je veux :

• Qu’on arrête de nous parler de Johnny ;
• Qu’on arrête de nous prendre pour des cons à nous vendre des éco-trucs, des machins-verts ou des bio-bidules ;
• Que les gens comprennent qu’il faut moins consommer (c’est lié au point du dessus) ;
• Le Smashing Book, bon je triche parce que je l’ai déjà reçu, il faut juste que j’aille le chercher ;
• Lire le Smashing Book ;
• Finir de lire les X livres que j’ai commencé à lire ;
• Passer moins de temps dans le métro ;
• Que les gens soient moins cons dans le métro (mais je sais que c’est impossible) ;
• Me remettre à écrire ;
• Avoir du temps pour moi ;
• Changer de serveur ;
• Avoir des sous, et plein même ;
• Apprendre à faire du web-design ;
• Apprendre Rails et Django, parce que c’est cool ;
• Terminer ce que j’ai commencé (plus vague tu meurs, hein ?) ;
• Faire des travaux dans mon notre appartement ;
• Faire un atelier à Paris-Web 2010 (j’ai failli écrire « conférence », mais faut pas abuser) ;
• Voyager ;
• Faire du sport, parce que j’ai le corps d’un pépé de 70 ans ;
• Ranger mes mails, rraahhhh ;
• Aller à un concert, pour voir, on m’a dit que c’était bien ;
• Faire des screencasts ;
• Être moins fatigué ;
• Cuisiner !
• Devenir le maître du monde Nan en fait ça me servirai à rien, et puis je suis sûr que c’est contraignant.

Voilà, merci Père Noël ! (oui, j’ai été très sage)

On m’a fait comprendre que je mets trop de temps à publier mon compte rendu de Paris-Web (quelqu’un attend encore celui de 2007 ?). Pour la peine, je vais le publier en plusieurs parties et les rassembler ensuite (je sais, c'est mal, Cool URIs don‘t change tout ça…).

Je sais, je suis nul et j’ai honte. Je n’ai rien écrit pendant un an et même pas fini le compte rendu de l’année dernière. Je n’ai aucune excuse (enfin si, mais je vous les donnerai dans un autre billet :-)). Pour me faire pardonner, vous trouverez un compte rendu que j’espère le plus complet possible.

La suite bientôt… (enfin faut pas trop rêver non plus)

Je sais, je suis en retard. Comme vous l'aurez compris, j'ai assisté à Paris Web 2008. L'année dernière je n'avais pas eu le temps de faire un compte rendu (honte à moi), cette année je vous ai concocté un vrai compte rendu de brute comme j'aime bien les faire (de la même trempe que celui de 2006).

Sommaire

• Accueil et introduction
• Ergonomie des interfaces riches
• Qualité et accessibilité Web : vers l’amélioration continue
  • Quelques principes à respecter
  • Contraintes et pièges actuels
  • Vers l’amélioration continue
  • Pilotage de parc
  • Communiquer et agir
• Travailler dans le présent
• Accessibilité : des volontaires ?
  • Cécité
  • Malvoyance
  • Déficiences motrices
  • Déficiences auditives
  • Déficiences intellectuelles
  • Déficiences techniques
• Internautes et robots des moteurs de recherche, mais comment font-ils pour s’y retrouver ?
• Table ronde
• Conclusion du jeudi

Accueil et introduction

Christophe Porteneuve, par lejoe

Le nouveau président de Paris Web (l’ancien a lâchement abandonné son poste) nous a accueilli, présenté les conférences et donné le ton. Le web c’est cool, Paris Web aussi. Ça paraît anodin, mais je doute que l’ambiance soit la même au LeWeb‘08… (Puis tiens, pas envie de mettre de lien)

Vous pouvez consulter le support de cette présentation sur slideshare.

Ergonomie des interfaces riches

Amélie Boucher, par lejoe

Dans cette conférence, Amélie Boucher a répondue à une question simple : Les interfaces riches sont-elles une révolution pour l’ergonomie ?

Elle répond simplement : Technology changes, humans don't (Les technologies changent, pas les humains), les règles ergonomiques qui sont valables actuellement sur le Web sont valables pour les interfaces riches.

D’après Amélie il existe trois types d’interfaces :

• Le web non riche (le Web 1), on consomme de l’information ;
• Le web avec des bouts de riche (le Web 2.0 en gros), on consomme, participe, agit. L’interface se contextualise en fonction de la demande de l’utilisateur ;
• L’interface entièrement riche (applicatif, logiciels, etc.), on manipule des objets.

Bien sûr, une interface riche est différente et nécessite quelques attentions :

• Limiter l’attente de l’utilisateur : charger un Flash de 500 Ko ça peut être long, il faut l’informer. Il faut également éviter les chargements lors de l’utilisation, c’est très pénible d’avoir à attendre dès que l’on fait une action ;
• Prendre en compte les antécédents des internautes comme la persistance du réflexe « molette » (les gens sont habitués à utiliser la molette pour parcourir une page, ils l’utiliseront forcément et il faut donc que le résultat soit celui attendu), le fonctionnement du bouton précédent, la persistance du réflexe du bouton d’action (on est tenté de cliquer sur un bouton pour accomplir une action, sans faire attention à ce qui est écrit dedans, sans faire attention au contexte) ;
• Penser à l’effet « temps réel » : sur une interface riche tout va très vite et il faut le prendre en considération. En temporisant certains feedbacks, par exemple avec une notion de latence simulée (clairement : faire croire à l’utilisateur que l’application travaille pour qu’il reste informé que son action a bien été prise en compte et que le résultat va bientôt arriver et ce même si l’application peut faire le traitement très rapidement) ;
• Faire attention aux nouveaux modes d’interaction : Guider l’internaute, compenser un défaut d’affordance (avec des mots, des curseurs, etc.).

Au final, l’interface doit s’effacer pour laisser place au service (ce qui forcément ne plaît pas beaucoup aux graphistes). C’était une conférence très intéressante, Amélie maîtrise vraiment son sujet, on l’écoute et on oublie sa timidité latente.

Vous pouvez consulter le support de cette présentation sur slideshare.

Qualité et accessibilité Web : vers l’amélioration continue

Élie Sloïm, par PascaleLC

C’est la deuxième fois que j’assiste à une conférence d’Élie Sloïm (qui est plus beau en vrai, comme l’a fait remarquer quelqu’un ; je crois que ça va le suivre), une fois de plus je n’ai pas été déçu.

La qualité est quelque chose qui me tient à cœur et il faut dire que dans le Web il y a beaucoup de travail à faire. Toutefois, Élie a décidé de temporiser un peu. Chaque projet est différent et doit avoir des obligations de qualité différentes. Il nous a proposé 5 grands axes pour évaluer le besoin de qualité :

• Quelques principes à respecter

  (Avant de commencer à songer à améliorer la qualité de son site)
  • Séparer le fond de la forme (ça choque quelqu’un ?) ;
  • Structurer le contenu sémantiquement, tôt ou tard le contenu sera utilisé par des machines ;
  • Développement pluri-média puis spécifique (mobile, puis iPhone par exemple) ;
  • Des interfaces appauvrissables (j’ai oublié de noter ce qu’il voulait entendre par là) ;
  • Délégation et mutualisation technique (idem que précédemment)

• Contraintes et pièges actuels

  • Séparation des métiers ;
  • Méthodes agiles, itérations rapides ;
  • Écoute des utilisateurs ;
  • Modèles qualité et référentiels ;
  • Valeur ajoutée sur les contenus et services ;
  • Faire attention aux contraintes techniques (utilisabilité, finance, juridique, innovation, éthique) ;
  • Rejet global : qualité, conformité, accessibilité (je pense que beaucoup de mes lecteurs savent ce que c’est)
  • Surqualité : Trop en vouloir fait perdre du temps
  • Rejets technologiques : Abandon d’AJAX ou de la vidéo (euh, je ne sais plus ce qu’il voulait dire)
  • Exclusion : Déplacer le contenu ne permet pas de s’affranchir des impératifs de qualité (mettre de la vidéo sur Dailymotion par exemple).

• Vers l’amélioration continue

  • Inventaire : Combien de sites je dois gérer ? Qui est responsable de chaque site ? Qui est responsable du parc ?
  • Référentiels : Quelles sont les règles que je m’applique ? Quelles sont les contraintes qui me sont imposées ? Quels référentiels appliquer à mon parc ?
  • Audit : Quel est le degré de conformité de mon parc, de chaque site, de chaque règle ?
  • Planification : Quels sont les objectifs pour le parc, pour chaque site ? Quels sont les priorités ?
  • Déploiement : Somme d’améliorations ponctuelles, suivi des indicateurs, évaluation périodique et/ou continue.

• Pilotage de parc

  C’est plus simple ici : utilisez Mon-Opquast :-).

• Communiquer et agir

  • Approche statique : communication sur l’excellence ou la conformité, annonces ponctuelles, communication institutionnelle ;
  • Approche dynamique : communication sur la démarche, les objectifs, états des lieux permanents, transparence ;
  • Ne pas communiquer uniquement lorsque la conformité est bonne.

Vous pouvez consulter le support de cette présentation sur slideshare.

Travailler dans le présent

Christian Heilmann, par Oncle Tom

J’ai découvert Christian Heilmann l’année dernière. Et quelle découverte ! En plus d’être un excellent orateur, quelqu’un de sympathique, il est extrêmement talentueux. (Ça se voit que je suis fan de lui ?)

Après une introduction poilante sur le métro parisien (littéralement : le fait de se retrouver coincé dans le métro pendant la grève de l’année dernière lui a permis de perdre du poids), il nous a convaincu d’utiliser ce qu’on a.

En vrac voici ce que j’ai pris en note :

• Un CMS c’est beaucoup d’argent, il faut former tous ceux qui vont l’utiliser. Choisir le mauvais c’est perdre beaucoup d’argent ;
• Le site ESPN.com a économisé 2 To de trafic par journée en passant au CSS (et au HTML sémantique) ;
• Pour des décideurs, il vaut mieux présenter ces chiffres en faisant une analogie. Représentez 2 To en nombre de CD par exemple ;
• L’open source ne mourra jamais. Choisir du propriétaire c’est s’exposer à des risques (fermeture de l’éditeur, coût des maintenances, etc.) ;
• Les clients surveillent les concurrents. Il peut arriver qu’ils disent « machin a un super truc appelé Django, on veut la même chose » (c’est juste un exemple) ;
• Si vous vous posez encore la question : www.shouldiusetablesforlayout.com (et regardez le source) ;
• Il faut réutiliser ce qu’on a déjà fait, recycler.

Vous pouvez consulter le support de cette présentation sur slideshare.

Accessibilité : des volontaires ?

Stéphane Deschamps et Aurélien Levy sur le point de torturer deux volontaires, par PascaleLC

Stéphane Deschamps et Aurélien Levy se sont associés pour nous immerger dans les différentes déficiences qui peuvent toucher un internaute. Ces mises en situation ont fait beaucoup rire, mais j’espère que l’audience a pris conscience que quelqu’un d’handicapé (dois-je le rappeler ? Un handicap est lié au contexte) subit ça tous les jours.

Au menu :

• Cécité

  Plus de lumière, plus d’écran, l’introduction lue par une synthèse vocale (bien sûr paramétrée comme pour un aveugle : avec un débit extrêmement rapide).

  Ce qu’il faut en retenir :

  • Il faut faire des textes alternatifs et qui plus est pertinents (je l’écris, même si ça coule de source) ;
  • Il faut structurer sa page avec les balises appropriées, les synthèses vocales fournissent un mode qui permet aux déficients de parcourir la page suivant son plan. Dans ce cas les balises <h1>, <h2>, <h3>, etc. ont un énorme intérêt ;
  • Il faut faire des liens pertinents. Arrêtez les « cliquez ici », « en savoir plus », etc. ;
  • Il faut utiliser les balises <label> pour les formulaires, sans ça les champs ne sont pas associés à leurs intitulés et il est très difficile de faire l’association de tête (la synthèse va lire les x intitulés, puis les x champs) ;
  • Rendez accessibles vos vidéos ! Avec par exemple de l’audio-description ;
  • Spécifiez la langue de votre document et marquez les mots qui sont dans une autre langue (sinon la synthèse vocale lira le mot avec la phonétique d’une autre langue ; imaginez de l’anglais lu par un allemand alors que vous êtes français…)

• Malvoyance

  Des exemples de choses que nous faisons tout le temps : mettre un texte avec une couleur pas assez contrastée par rapport à la couleur de fond, donner du sens à du texte en fonction de sa couleur (« Les champs en rouge sont obligatoires »), ne pas prendre en compte les daltoniens (pourtant 10% de la population française est daltonienne).

  Ce qu’il faut en retenir :

  • Contrastez votre texte, utilisez l’extension Color Contrast Analyser de Firefox pour avoir des informations sur les contrastes de vos pages ;
  • Évitez de vous baser sur une couleur pour véhiculer du sens ;
  • Et en règle générale : arrêtez de penser comme un voyant ou comme quelqu’un de normal, si vous voyez du vert, dites vous que certains n’en voit pas.

• Déficiences motrices

  Un volontaire désigné se faisait ligoter le bras droit (puisqu’il était droitier) et devait remplir un formulaire. Lors de la soumission un joyeux message « session expirée » a bien fait rire tout le monde.

  Ce qu’il faut en retenir :

  • Il faut prévoir une session d’une durée suffisante, et pas seulement pour quelqu’un de valide (ne passez pas vos sessions à 10 minutes pour un formulaire de 3 champs non plus).

• Déficiences auditives

  Nos joyeux orateurs ont coupé leur micro et raconté une histoire différente en même temps. Personne n’a rien compris (j’ai retenu une histoire de grenouille).

  Ce qu’il faut en retenir :

  • Il faut faire du sous-titrage, systématiquement. Forcément on se dit que c’est impossible à faire, que ça coûte trop cher. Mais non, il existe des solutions simples, souvent automatisées et peu chères.

• Déficiences intellectuelles

  Ils nous ont projeté du texte en mouvement, clignotant (difficulté à se concentrer), un exemple de <marquee> moderne et demandé à quelqu’un de lire le texte (bien évidemment il n’avait pas le temps), un proverbe japonais écrit en kanji (que presque personne n’était capable de décrypter), et mon exemple préféré, que je vous retranscris tel quel :

  « Potentiellement il est possible de dire qu’avec un effort non négligeable et une attention toute particulière il est envisageable qu’un élément aussi insignifiant que la quantité d’informations dans une phrase et sa simplicité permettent de la comprendre plus facilement »

  Ce qu’il faut en retenir :

  • Évitez les textes en mouvement, clignotant et les <marquee>. Sinon, fournissez un moyen de contrôle dessus (des boutons pause et stop par exemple) ;
  • Dans le cas de texte dans une autre langue, fournissez une traduction, une définition, quoi que ce soit qui permettrait à l’utilisateur de comprendre ;
  • Dans le dernier cas je pense que c’est assez clair non ? Il faut faire des phrases simples (d’ailleurs, c’est encore plus difficile de faire simple) et placer l’information principale au début.

• Déficiences techniques

  Quelques exemples de sites avec le javascript (chaotique avec une synthèse vocale) ou les images désactivées.

  Ce qu’il faut en retenir :

  • Il ne faut pas faire de javascript intrusif, c’est le mal (entendez par là que vous ne devez utiliser javascript qu’en surcouche, qu’en bonus) ;
  • Vérifiez le contraste de vos textes avec les images désactivées (il peut être utile de rajouter des couleurs de fond) ;
  • Il ne faut pas utiliser de display:none ou de text-indent:-1000em, une synthèse vocale ne pourra pas « voir » le texte dans le premier cas, le texte sera invisible si vous désactivez les images dans le deuxième cas. Préférez les balises <img> avec un texte alternatif ;
  • Optimisez le poids des éléments d’une page. Il ne faut pas croire que tout le monde a une connexion ADSL (de toute façon personne n’est à l’abri d’une défaillance), il ne faut pas oublier les RTC, les mobiles, les…

Ils ont fait vraiment très forts, c’était une conférence à la fois très enrichissante et très drôle.

Vous pouvez consulter le support de cette présentation sur slideshare.

Internautes et robots des moteurs de recherche, mais comment font-ils pour s’y retrouver ?

Alix Lassaigne et Christophe Cotin-Valois, par Édas

Il me semble que c’est la conférence que j’ai le moins aimé. Les orateurs (Alix Lassaigne et Christophe Cotin-Valois) n’avaient pas l’air très habitués à ce genre de représentation et le sujet choisi, l’intérêt de faire un code sémantique (en gros), n’était pas trop adapté à l’auditoire. Dommage.

Vous pouvez consulter le support de cette présentation sur slideshare.

Table ronde

Une partie de la table ronde, par PascaleLC

Les intervenants de la journée se sont retrouvés autour de non pas une mais deux tables rondes ! Ils ont répondu aux questions posées par la salle et… euh… Ben voilà.

Conclusion du jeudi

C'était vraiment très intense, épuisant même. À part la conférence Internautes et robots… c'était vraiment du haut niveau, ça fait vraiment plaisir de voir ça en France. Bientôt le compte rendu de la journée du vendredi (peut-être un peu moins complet que celui là).

Sinon, ça fait toujours plaisir de rencontrer des personnes qu'on « croise » tous les jours sur internet, de discuter, de rire et de manger (je sais, mes centres d'intérêts sont limités).

Tout n'est pas encore terminé, mais une bonne partie est faite. Je vous invite très fortement à me laisser vôtre avis (tant que vous ne dites pas « bouuhh, c'est nul »).

Vous pouvez revoir l'ancien design (mais pas trop longtemps) — PNG 1 Mo

Pourquoi un nouveau design ?

Je voulais changer il y a plus d'un an. Malheureusement, par manque de temps et surtout de talent artistique, ça a traîné. J'en avais marre de l'ancien template qu'on retrouve un peu partout, qui était mal contrasté, qui avait des éléments inutiles, qui était trop corporate, bref qui était vraiment naze.

C'est trop magnifique, c'est de qui ?

Comme vous avez compris que je suis une buse en graphisme, j'ai demandé à quelqu'un de m'aider pour me faire quelque chose de joli. C'est Julie qui a réussi à me convaincre (à me satisfaire ?).

Pourquoi il ressemble à ça ?

Je voulais quelque chose de simple, le plus simple possible. Comme vous le savez (ou pas, mais vous allez le savoir) faire simple c'est difficile. Je voulais un design relativement fluide, lisible et contrasté.

Pourquoi supprimer des trucs qu'on trouve sur d'autres blogs, comme le calendrier ?

En pensant à ce que devait être le futur design, je me suis beaucoup questionné sur l'intérêt de certains éléments. Pour prendre l'exemple du calendrier, ou de la dimension temporelle en général : Ça n'apporte rien à l'utilisateur de savoir qu'il y a un ou des billets qui ont été postés tel jour (sauf une indication sur la fréquence de publication). Ensuite, je me suis dit que cliquer sur tel jour est inutile. On ne sait pas quel(s) billet(s) se cache(nt) derrière tel journée. Au final ça sert peut-être à la sérendipité, mais ce n'est pas vraiment ce que je voulais.

Dans le même genre il y a les archives. Qui va cliquer sur « mai 2006 » ?

Quel est l'intérêt de mettre la blogroll sur toutes les pages ? De mettre un MyBlogLog ? De cacher la syndication trop profondément dans la page ? Bref, une tonne de question…

Il reste quoi à faire ?

Au niveau de l'intégration il reste énormément à faire ! Voici une liste (non exhaustive) :

• Activer une fonctionnalité (super cachée) du formulaire de recherche ;
• Arranger le bloc des métadonnées du billet (normalement il y a plus d'infos) ;
• Remettre le bloc de twitter, que j'ai désactivé pour l'instant puisque le script que j'ai fait est trop nul
• Mettre les droits du billet ailleurs, puisqu'à priori là où il est il ne plaît pas ;
• Finir certains blocs que vous verrez dans certains billets (ça vous avance hein ?) ;
• Finir l'intégration des billets (il y a quelques balises que je n'ai pas encore stylisé) ;
• Faire encore des optimisations ;
• Ajouter une fonctionnalité aux commentaires (j'aime bien être vague) ;
• Refaire le formulaire pour poster des commentaires (en fait celui là est temporaire, ça sera la version dégradée) ;
• Coloriser les codes qu'on peut trouver dans les billets ;
• Et encore !

Et sinon ?

Sinon il y a des billets qui vont disparaître. Certains sont vraiment nuls et n'ont pas leur place ici. Certains vont être réécrits (en partie) parce qu'ils doivent être mis à jour, reformulé, etc. Grande nouveauté : L'intégralité du blog sera bientôt disponible en anglais !

Vous l'aurez compris, il me demande beaucoup de boulot et c'est pour ça que je n'ai pas trop blogué ces temps ci. Je vais essayer de m'y remettre, d'être aussi intéressant qu'avant (un brin d'humour ne fait jamais de mal) et surtout d'avoir un blog de qualité.

P.-S. : Je vous conseille d'analyser la page sous YSlow ;-).

Le 5 avril dernier se déroulait le dernier CSS Off, concours où le but est de réaliser une intégration à partir d'un PSD. À chaque concours la même contrainte : seulement 24h pour participer. En plus de la contrainte temporelle il y a une contrainte spécifique, cette fois ci il s'agissait d'utiliser des microformats.

L'évaluation a pris 2 mois, pour enfin me désigner comme vainqueur (W00T !!). J'ai eu le choix entre $30 pour moi (transcendant lorsque l'on voit le taux de change dollar USD - Euro actuel) ou $50 $100 $125 pour une oeuvre de charité. J'ai donc choisi de reverser les $125 (78€) du concours + 22€ de ma poche à la fondation Abbé Pierre (ce qui fait 100€, pour ceux qui sont vraiment de gros nazes en maths).

Cette décision m'appartient et certains comprendront pourquoi j'ai choisi cette organisation plutôt qu'une autre. Pas la peine de me questionner là dessus, vous ne saurez rien. Pas la peine de critiquer non plus.

Cliquez pour voir ma participation !

Que dire d'autre... Je l'ai trouvé plutôt facile cette fois, il m'a fallu seulement 4h pour tout faire. J'avais enregistré toute la réalisation, mais Camtasia a lamentablement planté à la fin.

P.-S. : Pour la peine je vous prépare 2 surprises qui vont débarquer sur ce blog ;-) !

Une clé composite est une clé composée de plusieurs champs. (Tout simplement)

Une clé primaire composite est une clé primaire composée de plusieurs champs. (Une clé primaire n’a jamais été cantonnée à un seul champ, tout comme les clés uniques et les index)

Pour que ça soit plus parlant prenons un exemple :

On souhaite stocker des documents disponibles en plusieurs langues. Simplement on pourrait faire :

CREATE TABLE documents (
  id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  lang CHAR(2) NOT NULL,
  title VARCHAR(255) NOT NULL,
  author VARCHAR(255) NOT NULL
)

Ainsi, pour insérer des documents :

INSERT INTO documents (lang, title, author) VALUES ("fr", "Rapport", "Nicolas Le Gall");
INSERT INTO documents (lang, title, author) VALUES ("en", "Report", "Jens Meiert");

L’inconvénient c’est que l’on obtient 2 id différents, et qu’il est donc quasiment impossible d’identifier un lien entre ces deux documents. Pourtant il s’agit du même document, mis à part qu’ils ne sont pas dans la même langue.

Une solution est de gérer l’id manuellement (en enlevant l’option AUTO_INCREMENT), mais il est impossible d’avoir 2 id identiques (puisqu’il s’agit d’une clé primaire, ce champ est par définition unique).

Passer le champ en unique ne changera rien, et le passer en index résultera à une perte de cardinalité (ce qui n’est pas bon, ou très déconseillé, pour un id).

Créer une table pour chaque langue n’est pas non plus la bonne solution, ça surchargerai le nombre de tables, rajouterai des jointures et ce n’est pas très maintenable (imaginez que vous trouvez un contributeur japonais, vous n’avez plus qu’à créer une nouvelle table…)

La solution réside dans une clé composite (vous ne vous y attendiez pas, hein ;-) ?).

Si nous créons notre table comme cela :

CREATE TABLE documents (
  id TINYINT UNSIGNED NOT NULL,
  lang CHAR(2) NOT NULL,
  title VARCHAR(255) NOT NULL,
  author VARCHAR(255) NOT NULL,
  PRIMARY KEY (id, lang)
)

Cette fois pour insérer les données on doit préciser l’id :

INSERT INTO documents (id, lang, title, author) VALUES ("1", "fr", "Rapport", "Nicolas Le Gall");
INSERT INTO documents (id, lang, title, author) VALUES ("1", "en", "Report", "Jens Meiert");
INSERT INTO documents (id, lang, title, author) VALUES ("1", "de", "Bericht", "Jens Meiert");
INSERT INTO documents (id, lang, title, author) VALUES ("2", "fr", "Tutoriel", "Eric Daspet");
INSERT INTO documents (id, lang, title, author) VALUES ("2", "en", "Tutorial", "Christian Heilman");
INSERT INTO documents (id, lang, title, author) VALUES ("3", "fr", "La pierre et le sabre", "Karl Dubost");
INSERT INTO documents (id, lang, title, author) VALUES ("3", "jp", "宮本武蔵", "Yoshikawa Eiji");

(oui, je me suis lâché)

Maintenant on peut parfaitement sélectionner un document :

SELECT * FROM documents WHERE id = 1

Et on obtient le document et toutes ses traductions. En examinant d’un peu plus près (avec un EXPLAIN) on peut voir que le SGBD (MySQL dans mon cas) utilise l’index de la table, donc ne la parcourt pas (ainsi sur une très grande table vous avez de très très bonne performances).

Vous me direz que ça ne change pas d’avant, mis à part le fait que l’on peut avoir des id identiques ? Et bien essayons d’insérer une langue qui existe pour le document 1 :

INSERT INTO documents (id, lang, title, author) VALUES ("1", "de", "Bericht", "Jens Meiert");

Le SGBD va vous spécifier que la clé « 1-de » existe déjà. Nous venons donc de modifier le comportement de notre clé primaire (qui était « id » auparavant, maintenant la clé est le couple « id-lang ») pour y ajouter une contrainte supplémentaire.

Il y a une étrangeté tout de même ; si vous sélectionnez une langue :

SELECT * FROM documents WHERE lang = "fr"

Vous obtenez bien vos documents, mais EXPLAIN nous indique que le SGBD n’utilise pas l’index. Si vous savez pourquoi merci de m’éclairer ;-) .

Si vous avez une table vraiment conséquente vous pouvez quand même rajouter le champ lang en index :

ALTER TABLE documents ADD INDEX (lang)

Si vous sélectionnez l’id ET la langue vous n’aurez pas ce « problème ».

SELECT id AS last FROM documents ORDER BY id DESC LIMIT 1

SELECT MAX(id)+1 AS next FROM documents

J'ai eu la chance de réussir à m'incruster m'inscrire à l'atelier sur les microformats animé par Frédéric de Villamil et David Larlet (mais si, le Biologeek !). D'autre n'ont pas eu cette chance, j'ai entendu dire que les inscriptions étaient closes en moins d'une journée ! (désolé pour ceux qui n'ont pas pu y assister)

Deux orateurs pour un atelier d'une heure ? Oui. Et c'était vraiment une excellente idée. Frédéric de Villamil est un défenseur des microformats alors que David Larlet préfère RDF. Ce qui a donné lieu à des combats de "qui-a-la-plus-grosse ahah, tu peux pas faire ça toi hein ?"; outre le côté amusant ça nous a permis de positionner les deux approches.

Les microformats (ou µF, c'est plus rapide à taper) et RDF ont le même but : Sémantiser le web (enfin, ajouter une couche de sémantique à ce qui peut déjà exister). Normalement si vous suivez vous devez vous demander "mais pourquoi 2 choses pour un même but ?", et vous auriez raison de vous le demander.

En fait l'approche de ces langages est complètement différente :

• µF : Répondre à un besoin ponctuel, grâce à des attributs xHTML (donc youpi, rien à apprendre, juste à connaître les paires attributs/valeurs) pour sémantiser quelque chose (comme une vcard par exemple).
• RDF : Offrir un mécanisme générique pour sémantiser, en utilisant du XML et des DTD (donc c'est plus rébarbatif à apprendre/taper/maitriser, mais permet de faire [normalement] tout ce qu'on veut; vous pouvez en rajouter dans des documents xHTML, mais c'est un peu complexe)

A l'issue de cet atelier je suis plutôt dubitatif. J'ai pu essayer les µF, c'est simple, rapide à comprendre et à mettre en oeuvre, mais très spécifique. Et qui dit spécifique dit limité (en capacité ou dans le temps).
Par contre j'ai pu découvrir RDF, qui semble prometteur, mais imbitable. Ecrire une tonne de XML pour décrire des choses simple ce n'est pas ma tasse de thé (et ça ne devrait être celle de personne). Le principal avantage de RDF est sa généricité, sa capacité à s'enrichir. Si vous voulez sémantiser quelque chose, mais que le vocabulaire n'existe pas (entendez par là "que la DTD n'existe pas") et bien vous pouvez l'écrire. Génial hein ? Et bien je ne trouve pas, une DTD c'est chiant à écrire. Et puis créer un vocabulaire ça pose d'autre problèmes : un robot c'est bête, ça va réussir à parser des documents, mais ça ne va pas l'aider à en comprendre le sens donc il faut tout de même apprendre au robot (ou à ce qui exploite les données) à nous sortir les bonnes données. C'est pourquoi RDF est (ou sera) fortement associé à SPARQL, langage de requêtes permettant de récupérer des données d’une base de données RDF. Bon, si vous êtes arrivé à cette ligne vous pouvez vous rendre compte que le paragraphe commence à être grand. Et c'est ce qui me gène dans RDF, c'est du lourd, il faut en faire une sacré couche pour pas grand chose. Et, à mon avis, on n’est pas près d'en faire sans outils appropriés. Un autre point que j'aborderai plus tard : La documentation des vocabulaires qui, il me semble, sera un point très sensible dans le succès réussite l'adoption [mettez le mot que vous voulez] de RDF.

Je compte faire des billets décrivant plus en détail chaque approche, pour que vous puissiez juger (de quoi ? à vous de le savoir ;) ). Donc wait & see :) !

Je suis allé un peu vite, le WaSP Café n'aurait pas ce nom sans le petit apéro ;) . En arrivant je me suis rué sur le buffet, résultat : je n'ai presque pas parlé au gratin présent (mmm, un gratin). Et j'en viens au point faible des WaSP Café (je suis trop fort en transitions) : c'est beaucoup trop court !

• 15-20 minutes d'apéro (bon, je suis arrivé un peu en retard)
• un atelier trop court (mais le sujet est trop vaste)
• pas le temps pour discuter avec les orateurs :(
• et une table ronde (d'ailleurs je n'ai pas vu de table)

Cette dernière partie était une nouveauté, et ça fait ressembler les WaSP Café en mini-Paris Web ! Ne me demandez pas ce qui a été dit pendant cette table ronde, j'étais occupé à organiser le reste de ma soirée... (oui je sais, c'est mal).

Pour conclure : C'est vraiment très bien, mais trop court, et les WaSP Café sont trop espacés dans le temps (ce qui fait qu'on attend beaucoup de chacun). Le petit comité permet d'échanger, quand on a le temps, et au delà je pense que les ateliers seraient trop compliqué à animer.

P.-S.: Merci à l'IESA pour leur accueil et leur locaux sympathiques :)

Si vous avez des yeux qui fonctionnent correctement, vous devez vous rendre compte que le design de ce blog est tout pété absent. En fait aujourd'hui c'est le CSS Naked Day, donc je me suis mis à poil (Rah.. Avec cette phrase je vais attirer encore plein de visiteurs perdus).

P.-S. : J'ai fait ce billet à l'arrache, mais je n'ai vraiment pas le temps en ce moment...

J'ai eu la chance d'assister au Adobe onAIR Tour qui se déroulait mercredi dernier (2 avril 2008) au Palais Brongniart (à la bourse quoi, rien que ça...). Voici un rapide compte rendu :

L'événement a commencé par une keynote de Ryan Stewart, présentant AIR et la gamme Adobe. Pas grand chose à retenir si vous savez déjà ce qu'est AIR, mais quelques petites "révélations" :

• Cocomo : Un framework Flex permettant de faire des visioconférences et tout ce qui peut être cool et utile pendant des e-meeting (vous avez compris que j'ai rien à dire là dessus, en fait pas grand chose n'a été dit là dessus)
• Pacifica : La possibilité de faire de la VOIP via le flashplayer (donc via Flex et AIR, je pense que ça va cartonner)
• AIR disponible pour Linux (en alpha)
• AIR 1.1 pour fin 2008, avec une synchronisation entre les plateformes, c'est à dire qu'elle sortira en même temps sur Windows, sur MacOSX et sur Linux.
• Adobe veut de l'AIR partout (sur le web, sur votre bureau, sur votre portable, sur la Wii, etc.) (oui, je me suis bien creusé la tête pour trouver ma phrase)
• AIR supporte la HD, mais ça pas besoin de le rappeler (ah si ?), et ce via le codec H.264 (le même que Quicktime, donc pas dégueux)

Ci-dessus deux exemples débiles : une infinité de menu donnant une réponse différente à la question "Flash on the iPhone ?" et une application d'une forme bizarre (et avec une musique insupportable)

On a également eu le droit à une pléthore de démos, uvLayer (du partage de vidéos, très impressionnant), Google Analytics AIR (à noter que ce n'est pas Google qui l'a réalisé), et plusieurs applications déjà développées (toutes aussi impressionnantes).

Les autres conférences présentaient les capacités de la bête, via des démonstrations techniques (parfois des exemples totalement débiles). C'était très intéressant de voir que l'on peut créer de joli applications en très peu de temps et surtout très simplement. Certaines conférences étaient un peu plus poussées et il y a eu un peu de redite (je pense que tout le monde à compris que l'on peut avoir de vrai fenêtres transparentes).

Ci-dessus un exemple débile : Une application qui affiche une image différente si l'extension du fichier qu'on lui "drag&drop" n'est pas la bonne.
Mais également un exemple époustouflant : Un lecteur vidéo possédant un bouton pour faire des captures qui s'affichent à la volée derrière le lecteur.

Globalement c'était très bien, et j'irai volontiers à plein de journées comme celle ci. En dehors des conférences il y avait tout ce qu'il faut pour satisfaire un geek : des chips, du Guitar Hero III, de la Wii, des Pop Rocks (!), des boissons énergisantes (dont j'ai abusé), et plein de bouffe. En fait il ne manquait que des filles à moitié nues (avec des gros seins). Ah ! Et il faut acheter le développeur aussi, avec plein de cadeaux :

En plus de ces modestes présents ils tiraient au sort des participants pour recevoir : des posters d'eBoy (mon voisin en a gagné un, je vais devoir le tuer pour le récupérer), des teeshirts d'eBoy, des sacs avec plein de bouquins, des Flex Builder 3 Professional, et 2 Adobe CS3 Master Collection (!!).

Ci-dessus : des cadeaux et les guitares personnalisées à la sauce Adobe Flex/Apollo

Bon, maintenant il ne reste plus qu'à trouver quoi développer en AIR...

P.-S. : Plus de photos dans mon album Flickr.