Diapos des conférences du Web Event Lyon n°4

Bonjour bonjour !
Aujourd’hui a eu lieu le Web Event Lyon n°4 à Lyon. Il y a eu plein de conférences très intéressantes. Je liste ici les présentations que j’ai pu retrouver histoire de cliquer sur tous les liens et tester toutes les démos un de ces quatre matins.
Et le petit bonus qu’il faut voir même si vous n’allez pas au bout de la conférence de Sylvain :

Publié dans Neurone Geek | Laisser un commentaire

La boussole des patates ninja

Ce soir j’ai découvert les opérateurs binaires (ou bit à bit) en programmation, et — surtout – des cas d’utilisation concrète. Comme à chaque fois que je découvre un truc chouette, je suis toute contente.

J’ai expliqué tout ça à un gentil monsieur barbu, et je vais vous réexpliquer.

Noooon ! Partez pas ! J’ai dessiné des patates mignonnes et des patates ninja ! Siouplé ! \o/

Les opérateurs binaires c’est quoi ? Ce sont des opérateurs qui comparent deux trucs bit à bit. Pour ne pas effrayer les gens normaux qui pourraient passer par ici, imaginons que nous stockons nos données dans des patates, comme celle-ci :

Les patates peuvent être noires ou blanches. Elles ne peuvent pas contenir d’information plus consistante que ça, donc si on veut avoir plus d’informations, il faut utiliser plus de patates.

Les opérateurs binaires sont donc des opérateurs qui, à partir de deux groupes de patates, fabriquent un nouveau groupe de patates en comparant une par une les patates des deux premiers groupes (on dit « opérandes » quand on a une barbe et des lunettes).

Par exemple, l’opérateur & (« et bit-à-bit ») ne fait des patates noires que si les deux patates sont noires dans les couples qu’il compare :

L’opérateur | (« ou bit-à-bit ») fait une patate noire si au moins une des deux patates est noire dans la paire de patates qu’il regarde :

Et on a aussi le ^ (« ou exclusif bit-à-bit ») qui renvoie une patate noire si une et une seule des patates de la paire est noire :

Donc voilà, c’est plutôt inutile à première vue, comme ça, mais imaginez. Imaginez que vous avez un jeu — donc un programme informatique – avec une patate ninja. Comme ça :

Et elle se déplace dans un monde où il existe 4 directions : le nord, le sud, l’est et l’ouest. Chacune est représentée dans votre programme par un groupe de patates (de bits) contenant chacun une seule patate noire :

En réalité, vous utiliserez 1, 2, 4 et 8 dans votre programme. Une sombre histoire de compter en binaire, que je ne sais expliquer qu’avec des shadoks.

Quand tout est simple, si vous voulez déplacer votre ninja de coordonnées x et y, vous regardez dans quelle direction il va et vous agissez en conséquence :

si directionDuNinja == NORD alors y_du_ninja = y_du_ninja + 1 ;
sinon si directionDuNinja == SUD alors y_du_ninja = y_du_ninja - 1 ;
sinon si directionDuNinja == EST alors x_du_ninja = x_du_ninja +1 ;
sinon si directionDuNinja == OUEST alors x_du_ninja = x_du_ninja - 1 ;

Sauf que ! Sauf que votre ninja peut très bien aller dans deux directions à la fois. Le Sud-est, vous connaissez ? Lui aussi, manque de bol.

C’est un peu la louze là, parce qu’il va en même temps vers le sud et vers l’est. Qu’est-ce qu’on met dans la variable directionDuNinja ? On fait une direction SUDEST est on ajoute des millions de tests ?

On aurait des trucs du genre si direction == sud ou sud-est ou sud-ouest, alors le y_du_ninja = -1, et des conditions en plus sur toutes les directions.

Regardons ce que ça donne quand on sort nos opérateurs binaires. D’abord, donnons une valeur adéquate à la direction SUDEST

Et ensuite, regardons à tout hasard ce que donne l’opérateur &…

Oh, ça donne quelque chose qui contient une patate noire !

Et si on essaie avec le Nord…

Que des patates blanches ! On tient un truc pour tester des directions doubles avec des constantes simples !

En maths, on appellerait ça un produit scalaire : ça vaut 0 quand les deux bidules qu’on compare n’ont rien à voir l’un avec l’autre, et ça a une grosse valeur (= plein de patates noires) quand les deux bidules comparés sont très semblables.

Ya des gens qui se sont amusés à appeler ces groupes de patates des « vecteurs » et à construire tout un ensemble de théories mathématiques choupi là-dessus, qui s’appelle « l’algèbre linéaire ». Je pensais que j’avais oublié tout ça, mais les concepts me sont vite revenus quand j’ai mis les doigts dedans.

Mon neurone taupin n’est pas mort ! Vive mon neurone taupin !

Publié dans Neurone Geek | 9 commentaires

Le futur proche va devoir être consommé avec modération

L’autre jour (enfin, ce matin), en bonne zCorrectrice, j’ai voulu corriger un tutoriel du Site du Zéro. J’y ai lu deux paragraphes écrits au futur proche, j’ai râlé en mon for intérieur, et j’ai aussi râlé sur twitter, qui est un prolongement assez logique de mon for intérieur sur certains sujets.

Voici le tweet de la discorde, reproduit jusqu’à la dernière faute de frappe :

Message : arrêtez d’écrire des tutoriels au futur proche (« nous allons + infinitif). C’est lourd et ça me change en loup-garou.

À partir de là, tout est parti dans tous les sens. On m’a retweetée un peu, mais surtout on m’a accusée d’être anti-futur proche. Les arguments, en substance, étaient :

  1. Oui mais si c’est du futur et que c’est proche, on va utiliser du futur proche.
  2. Oui mais on va pas supprimer des temps juste parce que ça te plaît pas.

J’ai été très blessée par le second argument. Je prends toujours très personnellement ce genre de remarques. Bien sûr que non, on ne va pas supprimer le futur proche ! La preuve : même moi, je l’utilise.

C’est un temps très choupi, plein de mots, ce qui est particulièrement utile en période de NaNoWriMo. Accessoirement, c’est un temps à part entière, qui porte des nuances sensées par rapport à un futur normal. (Entre nous, je trouve le futur antérieur un peu plus amusant, mais la question n’est pas là.)

Qu’est-ce que le futur proche ?

Comme mentionné dans le tweet de la discorde, il s’agit d’un futur construit sur un verbe « aller » suivi d’un infinitif. Quelques exemples :

Le nouveau site va sortir. Non mais si, bientôt : à la fin de la semaine.
Nous allons partir dans les minutes qui viennent.

Le premier piège du futur proche

Petit message de santé grammaticale : quand on utilise le futur proche, il faut bien se souvenir que le second verbe est à l’infinitif. Par exemple, attention à ce genre de petites phrases…

Vous allez remonter dans le grand Nord ?

… qui se retrouvent, comme par magie, transformées en ceci :

Vous allez remontez dans le grand Nord ?

(Là on dit « Uuuuurgh ». Allez, tous ensemble : « Uuuuurgh ».)

Je ne m’étendrai pas sur l’aspect grammatical du truc. Si vous hésitez, remplacez vos verbes par « cuire » ou « descendre » et regardez si c’est conjugué ou pas.

Le poids du futur proche

Nous allons commencer par un exemple

Là où le futur proche va poser problème, finalement, même conjugué correctement, ça va être quand on va l’utiliser à tout bout de champ, même dans des situations où on ne va avoir ni du futur, ni du futur proche. Par exemple, je vais utiliser seulement le futur proche dans ce paragraphe, et vous allez bien sentir la différence entre celui-ci et les précédents… D’ailleurs je sens que je vais perdre au moins la moitié de mes lecteurs. Vous allez sentir que je pourrais dire les choses plus vite, mais vous allez devoir vous coltiner une quantité excessive de mots, filtrer du contenu à la lecture, pour finalement arriver au même sens à la fin.

En effet, les gens ont une tendance toute naturelle, quand ils veulent expliquer quelque chose, à recourir au futur proche. Exemple :

Les flottants, tu vas voir, c’est vraiment pas si compliqué. Regarde, ce bloc, je vais lui donner une propriété float: left. Comme tu le vois, il va se coller à gauche. Le bloc non positionné en dessous va remonter à la place du flottant, mais son contenu va « envelopper » le flottant. On va donner une margin-right au flottant… Et là tu vois, un petit espace blanc va apparaître entre le contenu non positionné et le flottant.

À l’oral, ça s’entend souvent, je vous laisse tendre l’oreille. Ces habitudes orales se retrouvent donc à l’écrit. Je vous fais la même explication en gardant le futur proche uniquement là où il est pertinent :

Les flottants, tu vas voir, c’est vraiment pas si compliqué. Regarde, ce bloc, je lui donne une propriété float: left. Comme tu le vois, il se colle à gauche. Le bloc non positionné en dessous remonte à la place du flottant, mais son contenu « enveloppe » le flottant. On donne une margin-right au flottant… Et là tu vois, un petit espace blanc apparaît entre le contenu non positionné et le flottant.

Je conçois que vous n’ayez rien compris aux flottants avec ce paragraphe (on pourrait faire plein de dessins à mille mots pièce pour expliquer les flottants CSS, et ça ne suffirait pas. J’ai un projet « expliquons les flottants CSS avec des koalas » dans les cartons, mais j’hésite encore à le sortir. Bref. Ce n’est pas le sujet). Mais vous ne trouvez pas que le second paragraphe est un peu plus clair que le premier ? Juste en passant un discours au présent, on le rend plus « light », plus simple à lire.

Et je vais continuer par les vraies raisons de ma colère

C’est cela que je reproche au futur proche : on l’utilise trop, là où il ne sert pas à exprimer un futur proche. Souvent, on le retrouve dans des paragraphes d’explications ou de description, où le présent serait plus adapté. À ce niveau, le futur proche (et le futur tout court, d’ailleurs) n’est pas un choix éclairé en fonction du sens qu’on veut donner au texte : c’est un simple tic de langage.

Même dans un tutoriel, où vous expliquez un processus étape par étape, ce n’est pas la peine d’utiliser le futur proche. Regardez les cuisinières de Marmiton.org. Elles utilisent le présent pour les indications… et pour les explications :

  1. Mélangez la farine, les œufs, la levure et le vin blanc. Le vin blanc est facultatif, mais il aide la pâte à monter.

(D’ailleurs, c’est en effet assez impressionnant de mélanger de la levure chimique avec du vin blanc. Ça fait une petite mousse qui fait pschiiiiii et il faudra que je regarde pourquoi avec Madame L., mais je crois que je m’écarte du sujet, encore.)

Or, quand on écrit du contenu technique ou quand on veut fournir une explication scientifique, on doit viser l’efficacité du discours, pas un nombre de mots ou de signes minimum. Le fond du discours est souvent déjà suffisamment compliqué pour qu’on n’en alambique pas la forme en plus.

Mais qu’est-ce que je vais faire de ma vie alors ?

Messieurs les techos qui me lisez, je vous conseille d’utiliser le présent pour vos explications, et de réserver le futur (proche ou non) à ce qui parle de sujets présents plus loin dans le document ou dans l’avenir. (Ex. Nous allons voir ici comment blablabla, puis nous verrons au chapitre suivant que bliblibli. Il est/sera possible de faire ceci ou cela dans la version XX du langage qui ne sera pas abordée dans ce bouquin.)

Même chose quand vous rédigez un tutoriel : pensez aux cuisinières de Marmiton.org. Écrivez des choses comme ceci :

Instancions un nouvel objet struct machinchose. Cette structure contient toutes les données concernant notre date.

Plutôt que des choses comme ceci :

Nous allons instancier un nouvel objet struct machinbidule. Cette structure va contenir toutes les données concernant notre date.

Conseil d’ami : si vous êtes en train d’écrire nous allons avoir, vous allez sûrement pouvoir changer votre phrase en présent. :p

Tu es vraiment trop extrême dans ton discours, Tûtie. Je vais pleurer, là, voilà. Au futur très proche.

Comprenons-nous bien : il ne s’agit pas d’une interdiction stricte, mais d’une recommandation de style. Grammaticalement, c’est tout à fait correct. Et vos lecteurs comprendront aussi si vous leur parlez au futur.

Simplement, la répétition du futur proche est lourde, avec le risque que vos lecteurs décrochent (sur un contenu web, c’est un risque particulièrement marqué). Posez-vous juste la question : est-ce que vous choisissez votre temps parce que vous voulez exprimer un futur, ou est-ce que vous transposez un tic de langage ?

Est-ce que le futur est justifié ? Si oui, n’hésitez pas. Si non, passez au présent.

Publié dans Neurone écrivain, Neurone orthographique | 10 commentaires

Cinquante milliers. Le retour.

Bonjour, lecteur égaré qui te souviens de l’adresse de mon blog !

Voici ma déclaration d’intentions pour le NaNoWriMo 2011.

Les intentions du neurone écrivain

Le NaNoWriMo, vous vous souvenez, je l’ai fait l’an dernier : il s’agit d’écrire un roman de 50 000 mots entre le 1er et le 30 novembre. L’an dernier j’ai réussi, notamment grâce au spectre de l’humiliation personnelle qui luisait doucement dans la nuit, lorsque, entre deux phrases, j’avais l’impression que l’inspiration se tarissait.

Cette année, donc, je remets le couvert. Je ne suis toujours pas une écrivain en herbe, ça fait un an que je n’ai pas écrit de texte long, je ne me suis absolument pas exercée depuis novembre dernier, mais ça va, je suis zen. (Je ne dirai sûrement plus la même chose le mois prochain, quand la machine sera lancée et que je commencerai à accumuler du retard, huhu.)

Mon roman sera toujours un texte de science-fiction cette année, mais j’ai visé moins haut : pas de morale à la fin, pas d’univers trop compliqué, pas d’explications physiques… Je vais faire un petit space opéra pas prise de tête, sans me demander trop longtemps si ce qui se passe est plausible ou pas. Dans science-fiction, il y a fiction, après tout. :)

Grande nouveauté 2011, je posterai le texte en public au fur et à mesure que je l’écrirai. Scrivener, mon petit logiciel chéri d’amour, possède une fonction « compiler en HTML » qui fonctionne plutôt bien après quelques de nombreux ajustements. Bon, évidemment, je n’ai pas encore réfléchi à l’endroit exact où j’allais publier le bousin. Sûrement quelque part sur ploque.net… Je vous tiendrai au courant avant le mois prochain, c’est promis.

Le mot du neurone geek

Je versionnerai aussi quotidiennement, sur mon profil github, le fichier Scrivener et les différents fichiers annexes (le HTML lisible, les feuilles de comptage des mots au format tableur, etc.). Dans la mesure où le fichier Scrivener (le dossier .scriv, là) contient tous mes documents préparatoires, c’est un vrai petit nid de spoilers et donc je vous déconseille formellement d’aller le voir.

L’an dernier, je manquais d’un moyen de sauvegarder en lieu sûr les versions successives de mon roman, et je pense que cette sécurité supplémentaire sera un atout non négligeable si je compte un jour exploiter sérieusement le texte que je produirai en novembre.

Publié dans Neurone écrivain | Marqué avec | 4 commentaires

Marketing « ciblé »

Publié dans Neurone Minitel | Marqué avec , | 2 commentaires

Obslescence programmée

Le mois dernier j’ai participé au concours d’images drôles de monsieur Hteumeuleu, un monsieur qui fait un peu le même métier que moi (pas complètement, mais on a des points communs). Mon dessin de 23 H à l’arrache est arrivé quatrième, du coup j’ai gagné un livre qui parle de ce dont parle mon dessin. C’est la première fois que je gagne quelque chose en faisant un dessin. C’est plutôt chouette, je vais recommencer, je crois.

Le dessin gagnant. C'est un peu de l'humour de double geek (humour d'intégrateur croisé à un clin d'œil Minecraft). Si vous ne comprenez pas le gag, c'est que vous êtes quelqu'un de normal.

P.-S. « Obsolescence » c’est déjà dur à écrire, mais c’est encore pire quand on fait exprès d’y ajouter une faute.

Publié dans Neurone Geek, Neurone orthographique, Neurone un peu useless | Marqué avec , , , , | 5 commentaires

Tout doit disparaître

Sans caricaturer aucunement, j’ai très peur des magasins de fringues, surtout en période d’affluence. J’arrive à y poser un orteil en période ultra-creuse, si les circonstances l’exigent absolument. De même, je redoute les grands magasins qui nous assomment de promotions « exceptionnelles », agressives et agrémentées de spots bruyants, qui augmentent significativement mes migraines sans diminuer réellement l’addition…

Cependant, un type de magasin (physique) résiste encore et toujours à mes angoisses, et me transforme en bête assoiffée de l’achat, en esclave aveugle toutes les promotions.

Papeteries et autres graphigro ont encore de beaux jours devant eux avec les timbrés comme moi.
Merci, « Agenda et écriture » de la Part-Dieu, pour la taille du panneau et les dix kilos de stylos à dessin que j’ai acquis sans que je comprenne exactement ce qui se passait…

Publié dans Neurone Fille, Neurone un peu useless | Marqué avec , , | 5 commentaires

Ce blog ne mange pas de chatons.

Bien le bonjour. Aujourd’hui, je vous propose de sauver un chat en évitant de commettre la dernière faute à la mode, qui est en réalité une double faute avec effet combo. En effet, cette mode consiste à combiner une confusion entre « a » et « à » avec une confusion entre les terminaisons « é » et « er ». Il en résulte des erreurs qui changent du tout au tout le sens des phrases…

 

Minou à manger = minou comestible.

 

Publié dans Neurone orthographique | Marqué avec , , | 5 commentaires

Standards métaphoriques

Bonjour. Vous le savez peut-être, mon métier dans la vie, c’est de faire des sites web. En gros. Je ne fais pas tout dans les sites web, mais l’idée est là.

Quand le métier de quelqu’un est de faire des sites web, son devoir est de respecter les standards du web, dans la mesure du possible. En général c’est assez possible, il y a quelques règles à connaître, et il ne faut pas avoir peur de vérifier les autres. Les standards du web sont écrits par un groupe de gens d’origines et de métiers divers, regroupés sous le nom de W3C. Ces gens-là écrivent dans des longues recommandations comment on doit écrire le code HTML qui constitue les pages que vous lisez, donnent des conférences techniques pour informer les gens et recruter des joueurs de loup-garou1, et ont un travail et une vie en dehors du W3C. Si j’ai bien compris.

Bref. Tout ça pour dire qu’il y a des standards, que c’est mieux de les respecter, et que pour les respecter, c’est mieux de les connaître un peu au lieu de passer sa vie sur les sites de référence pour savoir comment emboîter les éléments et avec quoi les habiller. Donc personnellement, j’ai des petits trucs mnémotechniques(2) pour retenir les standards un peu tordus. Par exemple, les tableaux. En HTML, on peut faire des jolis tableaux, comme ça, par exemple :

Mâle Femelle
Canard Cane
Taureau Vache

D’accord. Il n’est pas VRAIMENT joli. Mais il est standard, parce que je lui ai donné une structure standard. Le code derrière ressemble à ça :


<table>
<tbody>
<tr>
<th>Mâle</th>
<th>Femelle</th>
</tr>
<tr>
<td>Canard</td>
<td>Cane</td>
</tr>
<tr>
<td>Taureau</td>
<td>Vache</td>
</tr>
</tbody>
</table>

Ce n’est pas bien méchant. Tous les trucs entre chevrons (<truc>) sont des balises. Les balises qui commencent par un slash (</truc>) sont des balises fermantes. Les autres sont des balises ouvrantes. Quand on ouvre une balise, on peut en ouvrir d’autres dedans, mais il faut respecter l’imbrication : si j’ouvre une balise <truc> à l’intérieur d’une balise <machin>, je dois refermer <truc> avant de refermer <machin>.

Voilà. Mon métier c’est ça : ouvrir et fermer des balises, basiquement. (… très basiquement. Je fais d’autres trucs aussi, quand même.)

Donc ça c’était pour les gens qui ne sont pas bilingues français-HTML. J’en viens au fait. À un tableau, on peut donner une structure comportant un en-tête, un corps et un pied de tableau. Ces trois parties sont marquées par les balises <thead>, <tbody> et <tfoot>. Plutôt logique : <thead> pour table-head, <tbody> pour table-body, et je vous laisse deviner pour la dernière balise.

Or, sur ce point, les standards contredisent ce que penserait la raison, ou du moins l’instinct humain : on voudrait déclarer, dans le code HTML, la tête en premier, puis le corps, puis les pieds, un peu comme pour un accouchement.

Oui, mais ! Déclarer n’est pas accoucher. La structure en trois parties dans un tableau n’est pas là que pour faire joli : il s’agit de reporter dans l’en-tête et le pied les informations importantes, récurrentes, qui devront par exemple apparaître sur toutes les pages d’une très grande table qu’on voudrait imprimer. Ces informations étant importantes, on doit les déclarer en premier. L’ordre de déclaration est donc toujours <thead>, puis <tfoot>, et seulement à la fin l’élément <tbody>.

Pour se souvenir de cette petite blagounette, on peut se rappeler la signification sémantique des éléments <thead> and co. Personnellement, j’oublie toujours, et finalement, je perdais souvent du temps à vérifier sur les sites de référence pour comprendre pourquoi mon sniffeur d’écarts au standard grognait tout le temps.

Finalement, j’ai opté pour l’astuce mnémotechnique : le tableau structuré standard est un bel homme (forcément, il est standard et bien de tous points de vue), charmant, mais… Avec les pieds sur les épaules. Ça refroidit un peu, je vous l’accorde. Voilà ce que ça donne, le <tfoot> avant le <tbody> !

Bonjour. Je suis un tableau standard. On va boire un verre ?

Enfin… je devrais dire « le <tfoot> avant les <tbody> », puisque le rédacteur zélé peut insérer autant de corps qu’il le veut, pour regrouper logiquement son contenu. Sémantiquement c’est très bien, mais mon image métaphorique est encore moins draguable, du coup. Dommage, il était tellement mignon…

T'as pas soif ?

1 Mais grâce à moi, les villageois ont gagné à Lyon. Hin hin hin.

Publié dans Neurone Geek | Marqué avec , , | 4 commentaires

Ceci est un test

Bonjour.

Bonne année 2011. En effet, c’est la première note de l’année !

Mon scanner vient de faire une mauvaise chute. Heureusement, c’est un super scanner et il a survécu !

Voici donc ce que je viens de scanner pour vérifier la bonne marche du bousin :

Il s’agit d’un extrait d’une tentative de vulgarisation scientifique de je-fais-quoi-dans-la-vie au juste. J’ai rigolé en revoyant le dessin après l’avoir oublié dans un tiroir. Hi. :)

Publié dans Neurone non classé | Marqué avec , , | Laisser un commentaire