Martius Web

Zsh for the shell nerds

Martin Richard — Wed, 02 Mar 2011 00:37:00 +0100

Il y a quelques semaines mes amis Paul et Nicolas m’ont encouragé a essayé une alternative à Bash, le shell que nous utilisons généralement tous par défaut. Le changement s’est pratiquement fait directement (je suis un gros utilisateur de la console).

Changer de shell dans la console, c’est comme changer d’environnement de bureau (GNOME, Kde, etc) : globalement c’est la même chose, mais la manière dont ils sont présentés va varier. Alors Zsh, ça apporte quoi par rapport à Bash ?

Concrètement, on peut le voir comme une surcouche : la syntaxe des commandes ne change pas énormément. Les principales fonctionnalités qui vous feront basculer sont celles qui apparaissent en mode interactif :

l’auto-complétion/complétement (faites votre choix sur la terminologie) est vraiment puissant et paramétrable,
la correction des commandes est magique, et évite de retaper de longues commandes pour une faute de frappe,
une meilleure gestion de l’historique des commandes.

En plus, zsh supporte de nombreux plugins et supporte un mécanisme de thèmes, dont une impressionnante collection est maintenue sur un dépôt github dans un projet appelé Oh-My-Zsh. Il suffit de cloner le dépôt en local, de suivre le Readme, et de choisir son thème pour qu’en quelques minutes, Zsh soit adopté !

En plus, de nombreux thèmes supportent nativement le plug-in git qui offre la complétion/le complétement et affiche la branche de travail et si des données n’ont pas été archivées dans un commit.

En ce qui me concerne, j’ai choisi le thème “jreese”. Si vous avez le loisir de commenter et de me recommander des plug-ins ou docs pour encore améliorer ma productivité, je suis preneur !

Annuler un rm (retrouver des fichiers supprimés) sur une partition ext3 ou ext4

Martin Richard — Tue, 18 Jan 2011 15:40:00 +0100

Le billet court du jour devrait vous permettre d’éviter de paniquer bêtement parce que votre doigt à glissé et que vous avez lancé la commande

rm -rf *

plutôt que :

rsync -rf *

Si si, ça arrive. L’outil qui va vous sauver la vie s’appelle extundelete. Il fonctionne très bien sur une partition ext3 ou ext4, cependant, pour l’utiliser la partition ne doit pas être montée. Pour démonter /home, il vaut mieux soit passer par un live-usb (comme ça /home n’est jamais monté) ou quitter votre session, lancer un terminal non graphique (Ctrl+Alt+F2 par exemple), vous logguer en root (c’est plus génant sur ubuntu…) et hop :

# extundelete --restore-all /dev/sda3

D’autres options comme --restore-file et --restore-files sont également bien pratiques.

Set up a Teeworlds server on Debian Lenny (or any other Gnu/Linux)

Martin Richard — Tue, 30 Nov 2010 08:53:00 +0100

If you are reading this, I’m pretty sure you already know Teeworlds, an Open source 2D game between Worms (I mean Wormux) and Doom with graphics from Kirby. Today I’m trying to set up a server to host some sessions of this game.

As you will see, this is quite straightforward, and does not require tremendous skills in GNU/Linux systems administration.

Notice : This content is available in English and I’ll try to provide it in French as soon as possible. I decided to write it in English since I did not found a complete how-to on this -very important- topic.

The very first step I recommend you to follow is : Play the game with friends. Done ? Okay, let’s go !

Packages for the game and the server are already provided, but they are too old for the current version of the game that you may have downloaded just now. So, forget the installation through aptitude (or apt-get if you like oldies). Thanks to the project maintainers, the whole project is available in a binary version. We grab this archive, extract it and rename the new folder :

$ wget http://www.teeworlds.com/files/teeworlds-0.5.2-linux_x86.tar.gz
$ tar -xzvf teeworlds-0.5.2-linux_x86.tar.gz
$ mv teeworlds-0.5.2-linux_x86 teeworlds_bin

You may need to find the latest version URL (available on the website).

The very only requirement is to run teeworlds_srv (you may start the server as a normal user), but you haven’t yet configured the type of game experience you want to offer to players, and, if you close ssh connection or your terminal, the task will be killed and your server will be gone (too bad).

Let’s create configuration files teeworlds server is looking for, the software will look for them in ~/.teeworlds :

cd ~
mkdir .teeworlds && cd .teeworlds
touch settings.cfg
touch autoexec.cfg

Configuration options are described in the wiki of the project (Setting up a Teeworlds server), we will just focus on some of them. I put all the following lines in autoexec.cfg, but I don’t really know if this is the right place to put that. Here is my configuration file :

sv_name Bazinga! teh Server
sv_bindaddr bazinga.martiusweb.net
sv_motd Teh Bazinga Server with lolcatz n cheezburgerz
sv_rcon_password my_admin_passwd
password my_user_passwd
sv_register 1

sv_gametype dm
sv_max_clients 12
sv_spectator_slots 0
sv_scorelimit 30
sv_timelimit 10
sv_maprotation dm1 dm2 dm3 dm4 dm5 dm6 dm7 dm8
sv_map dm1
sv_rounds_per_map 5
sv_spamprotection 0
sv_teamdamage 1
sv_vote_kick 1
sv_warmup 3

What does mean all these options ? Explanations :

sv_name is my server name,
sv_bindaddr is used if you want to use a domain name instead of an IP to reach your server,
sv_motd is the message displayed when the user connects (and as a description of your server),
sv_rcon_password is the admin password you have to enter when you type F2 in game (to access the remote control console),
password is the password users must provide to connect on your server (remove this line to create a public server),
sv_register means that my server will be displayed on the servers list of the game.

We configured the engine, now, have a look to game options :

sv_gametype is the type of game, values are dm for death match, ctf (capture the flag), tdm (team death match),
sv_max_clients is the number of clients you want on your server,
sv_spectator_slots is the number of spectators allowed (a spectator is a client too),
when sv_scorelimit score is reached, the round is over,
sv_timelimit is the maximum duration of a round,
sv_map is the first map served,
sv_maprotation is a list of maps that your server allow to play on (space separated),
sv_rounds_per_map is… well, number of rounds played on each map before to switch on new map,
sv_spamprotection don’t disable it if your server is public,
sv_teamdamage means that during tdm, players from the same team can hit each others,
sv_vote_kick allows players to vote the kick of another player,
sv_warmup is the time (in seconds) at the beginning of a round when players have free time to prepare themselves,

That’s all for configuration. If you want to add a map, add it to sv_maprotation and copy the map file in teewords/data/maps (you can find new ones on the forum). Most of these settings can be updated in live via the rcon console (F2 during game).

Now, we will set up the server to last long. This can be done easily with nohup, which allows a process to live after the user is disconnected. nohup will save the standard output in nohup.log, in order to save our perfs and disk space, we will so deactivate output from the teeworlds server (in fact, redirect standard output to the /dev/null black hole). The command will be :

$ nohup teeworlds_srv > /dev/null

That’s all for today !

Flash AS3 : Détecter les clics sur un élément caché par un autre

Martin Richard — Wed, 10 Nov 2010 21:02:00 +0100

Ceci est donc le petit billet du jour, fruit d’un paquet d’heures de recherche pour un résultat fort simple !

Dans le cadre d’une application réalisée en Flash (Action Script 3) - oui, je sais - j’ai une série d’éléments qui sont masqués par une image transparente, faisant office de masque : le calque supérieur prend tout l’espace et capte donc les événements de la souris (notamment le clic).

J’ai cherché plusieurs solutions, j’ai réfléchi à déterminer l’objet cliqué d’après les coordonnées du pointeur, ce qui me semblait complexe étant donné que la forme d’un élément d’un calque en dessous n’est pas vraiment prévisible. Après avoir googlé le problème pendant un moment donc, je suis tombé sur une propriété de la classe (abstraite) InteractiveObject fort utile : mouseEnabled.

Cette propriété permet de désactiver toute interaction de la souris sur l’objet concerné, et la bonne surprise fût que, tout naturellement, le clic souris prenait pour cible l’élément du dessous.

On récapitule donc rapidement :

var gfxElt:MyGraphicElement = new MyGraphicElement();
var mask:MyMask = new MyMask();
 
addChild(gfxElement);
addChild(mask);

l’objet graphique mask recouvre l’objet élément, il n’est plus cliquable.

mask.mouseEnabled = false;

Maintenant si !

Je suis bien conscient que cette découverte n’est pas génialissime en soi, mais peut-être que ce billet épargnera à l’un d’entre vous de perdre du temps et d’imaginer une solution complétement farfelue proche d’une ré-invention de la roue.

Paris Web : Conclusion !

Martin Richard — Wed, 20 Oct 2010 18:44:00 +0200

Voilà, j’ai publié tous mes comptes rendus sur Paris Web, il est temps d’en faire un petit pour tout résumer. Je remercie à nouveau Pascale et Stéphane, grâce à qui j’ai pu accéder à cet événement malgré ma situation d’étudiant.

Paris Web, c’était deux jours de conférences à l’IBM Forum à Bois-Colombes (au nord de Paris), suivie par 450 personnes (et une centaine d’autres en direct via le net) et une journée d’ateliers à Telecom-Paristech (Paris XIIIe) qui a réunit 250 personnes.

Je remercie également mon amie Mélanie pour m’avoir hébergé pendant ces quelques jours.

Petit contexte

Je suis arrivé à Paris le mercredi soir : je suis sorti de cours et j’ai sauté dans mon TGV. Malgré les grèves, je n’ai eu aucun problème dans les transports (ce qui n’a pas été le cas de tout le monde). Je suis arrivé à Bois-Colombes le jeudi matin, le campus IBM est vraiment impressionnant, très chic et constituait un excellent cadre pour l’événement. L’accueil était très bon, j’ai mis un peu de temps à retrouver fetard, et nous nous sommes dirigés vers les amphithéâtres.

Je ne vais pas (re)commenter les conférences, d’ailleurs Ryan l’a très bien fait ! Encore une fois, j’ai été bluffé par le cadre (le grand amphi de l’IBM Forum donne l’impression de rentrer dans une sorte de vaisseau spatial du futur Wahou !) et les facilités d’accès au contenu mises en place (traduction en langage des signes des conférences, sous-titrage et traduction en français pour ceux qui le souhaitaient) étaient parfaites.

Ce que j’ai adoré

Ce que j’ai adoré dans Paris Web, c’est que tout le monde est accessible : les orateurs, les organisateurs comme les participants sont tous dans cette ambiance propre au web. un peu comme si on se retrouvait sur un réseau social IRL. D’ailleurs, le premier réflexe de chacun d’entre nous à été de noter sur nos badges notre pseudonyme sur Twitter, histoire de mettre un visage sur un “following”.

J’ai (presque) toujours aimé le contenu : les sujets étaient intéressants et variés pour la plupart, et présentés par des orateurs qui étaient de très bons à excellents ! J’ai un peu de mal à décrire ce que j’ai vécu là bas. C’est un peu comme emmener un enfant à Disneyland, et la conférence de Paul Rouget prenait la place du StarTour(c) !

Les ateliers était beaucoup plus intimistes, ce qui permettait d’être actif (comme dans l’atelier de Pascal et Raphaël, qui proposaient des phases de mise en pratique), d’échanger des points de vue ou des stratégies adoptés (atelier “comment convaincre un client de la qualité de sa prestation”), ou même de troller de bon matin (oui je regrette un peu de m’être “enflammé” pendant l’atelier sur le web temps-réel - la fatigue et toussa).

En bref, c’était un moment presque magique, où je me retenais de faire ma groupie devant un paquet de gens que je lis depuis quelques années.

Encore merci Pascale et Stéphane !

Ce que j’ai un peu moins aimé

J’ai été un peu surpris parfois par l’attitude prise par certains quand ils apprenaient que je suis étudiant. J’imagine qu’il y a un certain décalage entre mon vécu, mon attitude ou même mon expression par rapport à d’autres ; mais c’était parfois un peu vexant. Tant pis pour eux !

Au sujet d’HTML5 : je n’ai pris des notes que sur deux conférences, mais il y en avait un peu plus. En fait, il y avait quand même un peu de redite d’une conférence à l’autre, ou même, des informations de bases déjà lues par la plupart d’entre nous.

Pour finir, je crois que nous étions tous vraiment affamés, et il n’était pas toujours facile d’atteindre le buffet avant qu’il soit vide !

Que des histoires terribles en somme.

“Finish him”

Titre en référence à la fin de la conférence de Chris Heilmann (qui m’a aussi vraiment bluffée). J’ai adoré Paris Web, c’est peut-être un peu l’effet jeunesse (et ma première fois dans un événement de cette envergure) qui maintient les étoiles que j’ai dans les yeux depuis presque une semaine.

Les points utra-positifs (et personnels) :

les nombreuses rencontres
la confirmation de mon projet professionnel, de mon enthousiasme et de ma motivation pour le web !
les étoiles (toujours) dans mes yeux et la double page de dessins et dédicaces sur le livre Html 5 pour les Webdesigners que j’ai gagné à la fin de la conférence de Chris.

Il ne me reste plus qu’à prendre confiance en mon expression en anglais pour l’année prochaine !

(Paris Web !) #8 Upgrading the frontend, encore un peu d'HTML5

Martin Richard — Wed, 20 Oct 2010 16:36:00 +0200

Cette conférence était dirigée par Dave Shea,que l’on connait tous pour être le créateur de Css Zen Garden (même si il nous rappelle tous qu’il n’a pas fait que ça !). La conférence était en anglais.

C’est la dernière conférence pour laquelle j’ai pris des notes suffisamment complètes pour les résumer sur le blog. Je n’ai pas trop pris de notes sur les conférences orientées graphisme, car beaucoup en parleront mieux que moi.

Le changement

Il y a plein de nouveautés cools en HTML5 et CSS3, Dave en a encore découvert hier. Le problème c’est de toujours de trouver le temps pour apprendre et expérimenter. La solution de Dave c’est de développer des projets personnels, de participer à des Hacks nights ou autres compétition. Un autre moyen intéressant, c’est de bidouiller les pages secondaires de certains sites, comme la page 404 que Dailymotion.

Dave présente quelques exemples sympathiques qu’on voit passer en ce moment sur le web. Bon, ces démos sont sympathiques, mais on est loin des contraintes du “monde réel”. On peut se poser la question des limites actuelles à utiliser ces technologies : comme d’habitude, les navigateurs anciens posent problème, mais on compte aussi sur les outils avec moins de puissance (netbooks) ou moins de bande passante (mobiles).

L’une des questions les plus pertinentes, c’est probablement : “Est-ce que ça marchera encore plus tard ?”. En ce moment ça bouge vraiment vite, et c’est pour ça qu’on essaie de faire du Progressive Enhencement, qui consiste à faire une base qui fonctionne sur des outils limités, et on ajoute des fonctionnalités pour les navigateurs plus récents et appareils plus puissants sans tout casser.

Bon, à côté, le W3C dit que HTML5 n’est pas prêt pour la production, mais les navigateurs poussent à l’utilisation de ces nouvelles technos, donc selon l’orateur, on peut rester en désaccord avec le W3C sur ce point. Il faut quand même fixer quelques règles.

Quelques règles ?

Analysons le site de la FIFA pour la dernière coupe du monde. On regarde quelques éléments dans la page. Ils auraient pu les faire avec CSS3, mais on aurait remarqué rapidement le problème sur les vieux navigateurs. Sur le site de Vélib, au contraire, les coins arrondis qui ne passent pas choquent beaucoup moins : ils auraient pu utiliser CSS3 (border-radius).

L’audience

Il faut regarder qui visite votre site. C’est ce qui doit guider la stratégie technologique. On peut trouver de nombreuses ressources sur le web qui listent très bien les différences d’implémentation. On peut donc regarder les fallbacks pour les autres.

Intéressons nous un peu au propriétés CSS3 et aux vendor prefixes. Ils permettent facilement de faire du progressive enhencement. Il faut par contre faire attention, puisque ça signifie que la spécification risque encore de poser problème.

Voici Modernizr, c’est un script Javascript qui facilite le support des vieux navigateurs et propose des outils de détection des fonctionnalités supportées par les navigateurs.

Attention !

Soyons quand même vigilent : n’en faisons pas trop comme mettre des ombres sur tout le texte d’une page, dessiner des icônes en pur CSS (à quoi ça sert ?). Les performances doivent être considérées car les ressources des systèmes varient beaucoup. L’utilisation de CSS3 peut toujours poser problème quand on utiliser plein de fonctionnalités cool mais qui vont consommer beaucoup de CPU.

Le threading a été poussé par Chrome. Aujourd’hui les web workers (dans la spécifications) sont ici pour normaliser ça, et ça bouge encore beaucoup.

Que peut-on utiliser maintenant ?

Les PNG transparents : mais tout le monde le fait déjà !
Dieu merci, l’inclusion de fontes est aussi arrivé et fonctionne.
Le Doctype HTML5 : c’est facile à retenir et utiliser, en plus, ça ne change presque rien aux navigateurs, même IE6.
Les balises sémantiques (header, footer, etc) : on peut les utiliser, mais IE ne les gère pas, il faut ajouter un petit script. Et la version actuelle de firefox (3.7) n’applique pas encore la règle display:block;.
On peut aussi utiliser l’ajout de nouveaux attributs. Les navigateurs sont habitués à des horreurs, donc ceux qui ne le supportent pas dans l’optique de respecter HTML5 les géreront quand même.
Les nouveaux champs de formulaires : vous pouvez les utilisez, mais le fallback peut faire mal car l’expérience utilisateur s’en retrouve franchement réduite.
les ombres ou les border-radius en CSS ne posent jamais trop de problèmes, puisque ça ne change pas grand chose pour l’utilisateur. Ça sera juste un peu moins beau.
RGBA est un nouveau schéma de couleur CSS3 qui supporte le canal alpha. Le paramètre alpha, placé en dernier, sera généralement ignoré.

Les suivants posent un peu plus de problèmes :

Manipuler l’opacité marche aussi souvent bien et ne pose pas trop de problèmes.
Canvas est là pour bidouiller des images à pixels, SVG est prévu pour les images vectorielles. C’est quand même tôt pour les utiliser, accessoirement Google propose un outil pour implémenter leur support dans IE.
Les transitions et transformations risque quand même de poser des soucis puisqu’on ne peut pas trop faire de fallback.

Il est encore vraiment trop tôt pour utiliser des outils comme les Webworkers, WebGL, etc.

Un petit troll ? On en est où avec les graphistes ?

Hier, il y a eu un débat passionné sur “Photoshop ? Fireworks ? Css ?”. Les graphistes n’étaient pas trop branché CSS. L’orateur pense qu’il est important d’utiliser les outils de design actuels pour se faire une bonne idée. Mais c’est probablement intéressant d’essayer aussi un peu avec les CSS. Le souci principal, c’est qu’il est difficile de se représenter ce qui se passe une fois qu’on passe dans le navigateur. À commencer par les possibilités offertes par Photoshop sur les fontes, qui ne peuvent être reproduites en intégralité avec CSS.

Quoi d’autre ?

L’orateur voulait faire une animation pour un client, et plutôt que le faire en Flash, il s’est orienté vers Javascript (c’est trop tôt pour CSS3 et Canvas étant donné le public visé). Par contre, il a découvert que les PNGs transparents étaient assez mal supportés sur IE7 et 8 quand ils étaient animés. Il a fallu trouver un hack de hack… Aïe.

L’orateur a fait un petit projet (PaintbrushJS), qui utilise de nombreuses nouveautés de HTML5 et CSS3. Il a essayé d’implémenter quelques effets sur des photos pour voir ce qui était fonctionnel ou pas. Il a appris beaucoup de détails grâce à ce projet. En bref, faire un projet personnel qui pousse un peu à faire de la veille technologique.

Questions et réponses

On fait quoi avec les utilisateurs sans JS ?

R: Ah ah, en fait je ne m’en occupe pas trop. Je sais qu’il y a controverse, mais je trouve aujourd’hui que le web est inutilisable pour quelqu’un qui désactive JS.

Un intervenant précise que les chiffres de Yahoo! annoncent entre 1 et 2% d’utilisateurs sans Javascript.

Je vais poser un gros troll : je ne comprends pas trop pourquoi les orateurs anglophones sont si fascinés par webkit. Êtes vous tous fan de Webkit parce que vous utilisez tous des Macs ?

R: Euh, non, enfin, peut-être un peu. Bon, si. Mais Webkit est quand même innovant (même si ils perdent leur avance) et on se bouge toujours vers les fonctionnalités qui permettent de faire des trucs sexys.

Progressive Enhencement ou Graceful Degradation ?

R: Pour moi il n’y a pas vraiment de débat : ce sont des deux faces d’une même pièce. Au final, vous obtenez les mêmes résultats.

Le trolleur sur webkit gagne le bouquin.

(Paris Web !) #7 HTML5 maintenant... et même avec IE 6

Martin Richard — Wed, 20 Oct 2010 16:30:00 +0200

Conférence dirigée par Jean Pierre Vincent, que je lis avec assiduité dans les transports en commun ou pendant les pauses déjeuner.

Cette conférence parle comme beaucoup d’HTML5 et des nouvelles fonctionnalités qui arrivent avec. Jean-Pierre Vincent en utilise quelques unes, et cherche (ou réalise) des fallbacks utilisés en production.

Les slides de la présentation sont disponibles sur le site de l’orateur.

Pour maintenant ou pour plus tard ?

HTML 5 est prévu pour 2022… CSS 2.1 est toujours en RC, la selector API 2 est toujours en “Draft”, mais d’un autre côté, HTML4 et CSS qui sont finalisés depuis (respectivement) 1999 et 1996 et ne sont toujours pas intégralement implémentés.

Les développeurs s’intéressent à la facilité d’accès, la stabilité et à leurs besoins. Les recommandations sont secondaires.

Prenons l’exemple du web storage. Il existe 7 implémentations différentes et qui existent depuis IE6-7 :

UserData (IE)
GlobalStorage (Firefox 2)
Flash Shared Objects (Flash)
Hack window.name
Web storage (3 implémentations)

Heureusement que les bibliothèques sont là ! jQuery jStorage (jstorage.info), YUI3 (bit.ly/lib_store1), etc : Web Storage, avec une bibliothèque, devient OK pour la production.

Quel HTML5 ?

Il y a de nombreuses nouveautés officielles et d’autres technologies périphériques (comme svg) qu’on place sous ce terme. Il existe de nombreuses implémentations pour ces outils. On retient : Spécification + Hacks = Production !

Rappelons les bases : nouveau doctype plus light, nouvelles balises plus sémantiques (header, article). D’autres plus originales : <meter value="25" max="100" />, <progress>. Ces nouvelles balises sont standard, plus faciles à utiliser et comprendre, et donc, la page est plus maintenable et plus accessible (y compris pour les autres outils), et le bénéfice pour la SEO devrait se faire sentir dans les temps à venir.

Ces nouvelles balises sont utilisables en production. Cependant, il est nécessaire d’utiliser des bibliothèques pour IE6-8 (par exemple bit.ly/HTML5_shiv). On perd les utilisateurs d’IE sans javascript.

Les microdonnées (Microdata)

Il est possible de décrire des balises sémantiques avec un vocabulaire personnalisé. Les microdonnées sont en concurrence avec les microformats et RDFa qu’on connait depuis plusieurs années. Cette sémantique standardisée permet d’ajouter des données qui seront facilement exploitables.

Les robots d’indexation sont amateurs de microdatas (Google les exploite déjà).

Les formulaires

La spécification prévoit de nouveaux types de formulaires (<input type="email, color, url ..." />), c’est particulièrement utile pour les navigateurs mobiles qui peuvent adapter la saisie. Quand un nouveau champ de formulaire n’est pas supporté, les navigateurs utiliseront un champ textuel classique. Le grand débat sur ces fonctionalités concernent plus les limites du stylage visuel.

On passe aux API

En fait, les spécifications ne présentent pas toujours des API qui n’ont jamais étaient vues, c’est plus une harmonisation de ce qui est déjà utilisé d’une autre manière.

Comment on faisait ?

Géolocalisation : Adresse IP,
Drag&Drop : Applet Java (les specs reprennent l’implémentation proposée par IE6)
Forms 2 : Js
video : Flash
etc

J.-P. Vincent présente un exemple de page, présentée sous IE6 en HTML5, et dont les fonctionnalités sont supportées par du Javascript. Le formulaire est sensiblement identique sous Chrome, mais qui ne fait pas appel à Javascript. On gagne franchement du temps en décrivant en HTML5 les comportements qu’on devait produire en Javascript. Les formulaires avec Forms 2 peuvent êtres utilisés sur des nouveaux formulaires ou pour compléter des formulaires existants. Le comportement par défaut des vieux navigateurs est d’afficher un champ texte classique.

Géolocalisation

La nouvelle géolocalisation n’utilise plus tout le temps l’IP : par exemple, les google cars on enregistré les SSID des réseaux Wifi accessibles et les ont géolocalisés. On gagne en précision (mais ça fait un peu peur…).

Chris Heilmann nous propose aussi bit.ly/lib_geo.

Fallbacks, fallbacks, fallbacks !

De nombreuses bibliothèques couvrent le fossé entre vieux navigateurs et nouveaux standards : Raphaël JS. La plupart des liens présentés dans cette conférence peuvent être retrouvés sur le site internet de l’auteur. Pour le Drag&Drop, malgré le fallback un peu bancal en Java, il a été franchement utilisé (c’est donc une fonctionnalité qu’apprécient les utilisateurs).

Conclusion

Les nouveaux standards apportent des outils pratiques pour les utilisateurs, et sont utilisables en production grâce aux bibliothèques. On peut peut-être faire une exception pour la vidéo quand les besoins de personnalisation sont un peu avancés.

(Paris Web !) #6 Innover de 9 à 5 (sur les heures de bureau)

Martin Richard — Tue, 19 Oct 2010 13:46:00 +0200

La conférence est dirigée par Olivier Thereaux. Il présente ses observations sur le concept d’innovation dans l’entreprise. Cette conférence changeait des autres puisqu’on a pas vraiment parlé de web. Par contre, c’était en fin de journée, je commençais à avoir du mal à prendre des notes.

L’innovation, c’est quoi ?

On va donner un cadre à la notion d’innovation. Définition basique : “créer de nouvelles solutions au problèmes”. Si on ne cherche pas une solution, ici, on ne parle pas d’innovation. Une innovation peut être radicale (elle change nos vies) ou incrémentale (par exemple, amélioration de processus).

L’innovation plus radicale change “tout”. Prenons un produit : la bougie. On analyse pour trouver le besoin. On créé un nouveau système. L’ampoule a conduit au développement du réseau électrique. L’innovation devient radicale. C’est l’histoire qui le montre.

Le cadre de l’innovation

Aujourd’hui on voit typiquement la R&D comme centre d’innovation. La R&D c’est souvent un petite partie des cerveaux de l’entreprise. Il faut donc impliquer tout le monde, la R&D peut tester les idées de tout le monde. Typiquement, ce modèle d’innovation partagée est employé par 3M et Google. Ces entreprises on laissé respectivement 15 et 20% du temps des employés à faire leurs propres expérimentations. Google impose que 10% de ce temps soit utilisé en dehors du cadre de l’entreprise pour élargir l’esprit et ne pas rester limité à la culture d’entreprise.

L’entreprise dans laquelle l’orateur travaille a développé les jardins de l’innovation. Résultat : plein d’idées, aucune réalisation. Il faut se méfier du mythe de la grande idée. Il faut arrêter de penser qu’on veut garder secrète notre “très bonne idée qu’on risque de se faire voler si on en parle”. Quelqu’un aura peut-être l’idée en même temps et lui, il va la réaliser.

Culture : la culture du hacker

Cette culture, qu’on un peu tous puisqu’on fait de l’informatique, peut servir à hacker l’entreprise.

Hacker l’espace de l’entreprise : l’open-space, les tableaux (partout !) et la machine à café sont d’excellents moyens d’hacker l’espace. Mais c’est rarement une difficulté.

Par contre, hacker un processus est plus compliqué : il faut du temps et de l’argent. Le retour court-terme d’une innovation dans le processus est difficile à estimer, donc le gestionnaire est souvent frileux à son implémentation. On peut quand même trouver des petits moments pour étudier et bidouiller : on avance par petits pas. Mais le projet reste petit, le risque reste gérable, et on est en mesure de gérer les attentes (annoncer que le projet risque de ne pas marcher).

Le vrai avantage compétitif qu’on peut apporter, c’est l’apprentissage. Il faut apprendre à apprendre. On fait bouger le cadre de travail grâce à des moments qui permettent d’échanger et d’apprendre. Il faut aussi apprendre à échouer, car innover entraine souvent des échecs : Mistakes will be made (chairman de 3M).

Une bonne façon d’apprendre à échouer et à persévérer, c’est de jouer : il faut rendre le travail fun. Ceci amène au dernier point qui peut être hacké : l’aspect humain. Entre les années 50 et 90, on voulait de la “qualité totale”, c’est le rôle du champion dans la qualité. Le champion c’est la R&D, il est plus que probable que cette isolation casse les performances du champion.

Pour éviter ça, on mélange les gens avec d’autres qui veulent jouer. Des idées sont produites, “comme ça”. Une idée qui pousse “comme ça”, peut devenir une réponse à un besoin dans un cas encore inconnu au moment ou l’idée pousse.

Avec une série d’expérimentations, on peut obtenir des métriques de succès et créer un cadre d’innovation.

Conclusion

Mince, la conclusion c’est une image… et “Petits pas + Culture de bidouille = Hacker l’entreprise”.

Bibliographie : Scott Berkun “The Myths of Innovation”

Questions et réponses

Est-on dans un bon cadre -en France- pour innover ?

R: euh… j’en sais rien (ndlr: l’orateur est un français expatrié au Canada). Probablement, car le français est plutôt “frondeur”, à condition d’avoir des chefs pas trop…

Métrique du succès de l’innovation ?

R: Disons qu’en moyenne c’est le “110-1”: 90 idées sur 110 sont à jeter, mais c’est toujours un peu difficile de présenter une métrique comme ça.

Tu penses quoi de 37signal ?

R: Cette entreprise américaine est assez innovante, ils ne se définissent pas comme l’entreprise qui va battre l’autre mais celle qui sera “l’anti” (de Microsoft project). Je trouve que 37signal est quand même un peu trop dogmatique : une grosse recette, ça ne marche pas avec tout le monde : pas de meetings, pas de ça, toujours comme ça. Je suis partagé.

Le modèle français c’est souvent à coup de subventions publiques, et là, on apprend que le statut jeune entreprise innovante. Qu’en penses-tu ?

R: Pour des projets de recherche, l’institution est importante et doit maintenir ses efforts. Mais bien souvent, c’est à celui qui est “titillé” de tenter quelque chose.

(Paris Web !) #5 Reusable Code : For Good or For Awesome

Martin Richard — Fri, 15 Oct 2010 10:50:00 +0200

Une conférence qui s’appelle “reusable code”, je sais d’avance que ça va me plaire. En plus, Jake utilisait une wiimote pour contrôler sa présentation, c’était forcément génial.

Une excellente conférence, mais qui s’adresse essentiellement aux développeurs. L’orateur présente des bonnes pratiques pour réaliser des API réutilisables en Javascript. Bien sûr, bon nombre de conseils s’appliquent dans d’autres cas. C’est la deuxième conférence que j’ai suivi en anglais.

Conférence dirigée par Jake Archibald, qui fait de belles APIs Javascript pour la BBC.

L’une de ses grosses missions, c’est de produire du Javascript réutilisable.

Les slides de la présentation sont disponibles sur slideshare.

Il y a cinq éléments pour faire une bonne API :

consistency
flexibility
readability
writability
Kinda useful-ability
= Captain “I build Reusable code” !

On va prendre l’exemple des Carrousel en JS, ils ont poussé comme des champignons ! Il y a des carousels partout sur le site de la BBC.

Bruce Wayne a dévoué sa vie à se battre contre le crime et c’est pour ça qu’il est devenu Batman. Jake a une histoire aussi : quand il était enfant, il voulait regarder un film documentaire avec sa mère. Il pensait que le documentaire en question était “Historical Fallacies”. Il avait mal compris, le documentaire était en fait “Historical Phalluses”, et il a subit le visionnage de ce documentaire avec sa mère. Voilà, une démonstration qui montre que mal nommer quelque chose peut avoir des conséquences désastreuses : c’est difficile à lire, difficile à comprendre, et tout ça peut être source de confusions. Tous les jours, avec les API, les risques de confusion sont nombreux. Une API est difficile à faire et difficile à changer. Si elle est mal conçue, les gens ne vont pas savoir l’utiliser. Fort de cette expérience télévisuelle avec sa maman, Jake se devait de lutter contre les confusions, surtout dans son boulot. Mais passons à la pratique.

A function : where do we put it ?

Global scope, custom “namespace”, existing object, plugin ? Oublions déjà le scope global. Regardons les namespaces. Les namespaces servent à regrouper des choses qui collent ensemble. Soyons un peu vigilant à ne pas non plus trop découper !

[javascript]
jToys.carousel();
jToys.accordion();

Pensons aussi aux alias pour la compatibilité :

[javascript]
jToys.same();
jToys.deepEquals();
jToys.same = jToys.deepEquals;

Ajouter à des objets existants est aussi une bonne idée : en javascript on peut bidouiller un objet à volonté. On peut produire du code super facile à lire. C’est cool. Bien sûr, il y a des pièges.

Par exemple, en surchargeant un objet standard, on risque d’entrer en collision avec une nouveauté du langage (getElementsByClassName()). C’est un problème car la définition du W3C n’est pas la même que celle définie dans le framework prototype pour cette méthode. Ils vont devoir rompre la compatibilité.

Conclusion, c’est peut-être pas une excellente solution.

Écrire un plugin, ça a l’air cool aussi. C’est un peu comme étendre les types par défaut, mais avec moins de risques. Bien sûr un risque de collisions subsiste.

Choisissons donc entre namespaces et plugins. Si les utilisateurs ne connaissent pas javascript mais JQuery, utilisez les plugins. Dans un environnement ou le noyau est presque réduit à zéro. Les namespaces peuvent être cool.

N’oubliez pas d’être cohérent ! Regardez Patrick Stewart il n’a pas changé en 20 ans !

Fonctions et paramètres

Commencez par la documentation. Comment appelle-t-on les paramètres ? Avec la documentation on peut donner des noms cohérents (et ça évite les confusions et les enfants qui regardent des émissions sur des sexes masculins, entre autres).

JS Doc, P Doc sont d’excellents outils pour décrire la documentation. La documentation du code avant de coder permet de tester l’API avant même de commencer à écrire le code. On peut facilement vérifier si elle est intuitive grâce à ça.

Soyons vigilent aux termes que nous utilisons : restons cohérents. Sur wikipédia (enfin, celui que seul Jake utilise), “consistency” est décrit par “pas PHP !”. C’est un tel bordel dans les fonctions PHP, aucune convention, c’est tordu ! Mais bon, au moins, il y a une bonne documentation.

Patrick Stewart n’aime pas PHP.

Donc, pour revenir au Carousel, on a essayé un truc comme :

[javascript]
jToys.carousel('#c', 500, true);

Mais qui fait quoi ? On ne voit pas tout à quoi correspond le second paramètre. Pire elt.cloneNode(true) : mais c’est quoi ce “true” ?

Essayons de faire en sorte que les arguments se lisent bien.

Utilisons des objets optionnels pour les arguments :

[javascript]
jToys.carousel('#whatever', {loop: true, speed: 500});

Dans ce cas, ne soyons pas stupides, décrivons et documentons ces paramètres (les générateurs de docs proposent des manières de décrire ça proprement).

C’est d’autant plus avantageux qu’il est possible de de rajouter des options comme on veut. Utiliser des métaphores c’est une bonne idée quand on a pas trop le choix, mais il faut faire attention à ne pas être mal compris. Pensez à Desktop Wallpaper, le sens fondamental est plutôt débile (Papier peint de bureau…).

Pensons également à l’usage le plus courant en donnant des comportements et des valeurs par défaut à notre objet.

Regardez CSS3, on a overflow-x et overflow-y. Certaines combinaisons de ces propriétés et de leurs valeurs sont incompatibles. Et tout ça devient illisible ! Évitons d’avoir des dépendances entre les paramètres. Pensez aux enfants !

Est-on sur la bonne voie ?

C’est difficile de prouver la qualité de notre propre API. Avec les illusions d’optiques, on ne voit pas le “truc” tant qu’on a pas eu la solution. Si on y revient, il saute aux yeux ! C’est pareil avec les API. Quand on fait l’API, on voit tout de suite ce qui va se passer, après tout, c’est notre bébé ! L’idée c’est de faire lire un code utilisant l’API a quelqu’un. Il faut voir si il arrive à avoir une idée de ce que ce code fait.

Flexible ?

Être flexible c’est important, parce qu’il faut penser aux usages futurs. La solution : l’abstraction. Par exemple Carousel peut hériter de CarouselPane qui ne contient pas de logique visuelle. Un autre aspect important, c’est de faire en sorte de rendre les erreurs faciles à détecter. Quand l’erreur est dans un paramètre (par exemple une faute de frappe), elle devient silencieuse. C’est frustrant pour l’utilisateur.

Note : les slides et la conf seront bientôt dispos en ligne. On a été un peu pressé par le temps.

(Paris Web !) #4 L'accessibilité dans la chaine de production

Martin Richard — Fri, 15 Oct 2010 10:19:00 +0200

Conférence dirigée par Denis Boudreau (co-fondateur de la Coopérative Accessibilité Web expert invité au W3C HTML-WG) et
Vincent François (co-fondateur de cette fameuse coop).

Exemple type du mauvais élève : hé ! Tu peux ajouter les “alt” ? Le développeur n’a pas que ça à faire, en plus il ne sait pas bien ce qu’il faut faire. Le rédacteur ne travaille plus sur le projet depuis un moment. Aïe. C’est un cas courant : l’accessibilité est souvent traité en fin de chaine, comprendre : bien trop tard.

Un autre exemple classique : les contrastes sont trop faibles et le site est presque livré !

Les pièges classiques de l’accessibilité

Souvent, on place assez bien les nouveaux métiers dans la chaîne de production (le designer arrive au début, le contrôleur qualité à la fin d’une itération). On oublie souvent le caractère transversal de l’accessibilité. On risque souvent de négliger des aspects importants, et risquer de prendre des décisions qui auront des conséquences lourdes.

La pire situation étant bien souvent de planifier l’accessibilité en fin de parcours. L’accessibilité est importante lors de la définition des besoins par exemple, ou les premières étapes de conception. L’intégrateur est alors un peu obligé de faire le travail des autres, alors qu’il n’en a généralement pas les compétences. En plus, on ne pose pas toutes les bonnes questions sur les choix technologiques.

Autre coup classique : désigner un champion de l’accessibilité : ce sont des décisions qui se prennent tout au long du projet, donc qu’une personne seule ne peut pas prendre (sa légitimité sera rapidement remise en question).

Les exigences seules sont insuffisantes : ne validez pas que les critères techniques. Souvent, une personne développe les compétences et va tester. Mais la validation de l’expérience utilisateur doit se faire avec un véritable utilisateur (simuler au mieux une situation réelle).

Il ne faut pas non plus confondre accessibilité et conformité. Ces notions ne sont pas interchangeables. L’accessibilité est une démarche subjective alors que la conformité est objective (elle répond à des critères).

La notion de qualité ne relève pas de machines ! Alors évitons de présumer que les outils feront le travail. L’accessibilité fait appel au bon jugement, et implique une évaluation humaine. Il faut donc évaluer soi-même les assertions publicitaires sur l’accessibilité de certains CMS. Ceci mène au piège suivant : on sous-estime l’impact des plateformes. Les licences coûteuses ne sont pas synonymes d’accessibilité. Les solutions libres sont souvent plus faciles à modifier, il est donc plus facile d’adapter le produit pour mieux tenir compte des contraintes d’accessibilité.

Que gagne-t-on à être accessible “dans la chaine de production” ?

On gagne souvent beaucoup de temps. Par exemple, quand le rédacteur choisit les images, il peut préciser un texte alternatif dans la foulée. Alors qu’en fin de chaine, il faudra relancer le processus. Le temps c’est de l’argent : gagner du temps de travail, c’est donc gagner de l’argent.

On gagne aussi dans la relation avec le client : poser les questions liées à l’accessibilité en fin de chaine, c’est gérer ce genre de choses en période de stress, de pic de travail, etc.

Enfin, on gagne en relations internes : on évite de pousser la charge sur le dernier maillon de la chaine, tous découvriront comment améliorer la démarche de qualité et d’accessibilité.

Au bon moment pour les bonnes personnes :

Plus d’informations sur le site d’accessibilité web.

Je n’ai pas pris de notes pour la session Questions/Réponses. Désolé ! On retiendra que beaucoup de monde proteste à l’idée de ne pas élire un responsable accessibilité. La réponse à ce sujet est : “un responsable OK, pas un gendarme, car tout le monde va tenter de l’éviter”. D’autre part, beaucoup s’inquiètent de l’absence d’intérêt pour l’accessibilité dans de nombreuses situations.

(Paris Web !) #3 Let's interface !

Martin Richard — Thu, 14 Oct 2010 16:12:00 +0200

Cette conférence est la première en anglais, j’ai essayé de la suivre sans traduction pour pouvoir prendre des notes. Je pense que ces notes ne seront pas très utiles car la conférence est très visuelle et interactive. La vidéo sera certainement disponible d’ici quelques semaines.

Conférence dirigée par Chris Heilmann (Tech evangelist chez Yahoo !). Vous pouvez retrouver les slides de la présentation.

“Je suis Chris et j’aime cette conférence, j’aime les organisateurs, j’adore les autres orateurs, mais j’ai un problème : la langue. Moi, je suis allemand, j’habite en Angleterre et je parle un petit peu le français.”

“Paris web est une conférence plein de bon contenu, mais le monde ne le saura jamais car le monde ne parle pas français. Et c’est pourquoi nous continuons en anglais.”

C’est assez facile de comprendre car il est allemand. Un petit troll pour Daniel Glazman pour le plaisir.

Problème de représentation

“J’ai du mal à me faire comprendre, l’accent, la langue, alors j’ai commencé à programmer des interfaces. Les interfaces doivent être faciles pour les utilisateurs, qui ont des profils variés : les utilisateurs finaux, ou… notre entreprise.”

“L’utilisateur se demande toujours comment l’ordinateur peut nous aider, souvent on lui répond : laisse, l’informatique c’est pour nous, les informaticiens. L’idée c’est de produire une interface qui laisse l’utilisateur en faire ce qu’il veut.”

L’interface pour communiquer

“Avec la doc de Y!ui, on a tout, du monde l’aime pour ça. Au contraire, W3schools est très light, mais ne présente aucun contexte et toute l’info n’y est pas.”

“N’hésitez pas à produire une petite interface pour la présenter à votre boîte, c’est votre chance !!”

“Prenons l’exemple de Yahoo Placemaker, personne ne l’utilise, alors que c’est cool ! Voilà la doc, comment comprendre l’outil avec une doc très… doc. J’ai donc créé une interface qui montre ce que ça fait. Faire une petite interface montre ce que ça fait de bien et on a commencer à voir l’intérêt.”

“Voici un petit bout de code qui place sur une carte (google map) du contenu detecté dans la page.”

Présentation de jolis outils qui utilisent ces APIs. Les sources sont sur github. “Github is a paradox, it’s a social network for developpers !”

You can do that

“Focus sur les objectifs, mettez vous à plusieurs, utilisez github, c’est super cool !”

“Il ne faut pas hésiter à faire ça pour ses produits mais aussi les produits des autres, pendant une conférence, j’ai pris quelques extensions de firefox pour bidouiller l’interface de stack overflow. Quand on tape une question, j’utilise une API qui permet de retrouver les tags pour cette question. Je présentait mes trucs en me mettant à leur niveau : j’ai fait un truc utile pour eux, ils m’ont écouté.”

Screenr

Screenr est un outil qui permet de faire des screencasts prêt à être twittés, l’idée c’est : montrez avec une vidéo plutôt qu’un long blabla (on connait tous le “ce bouton à gauche, non l’autre… le troisième à gauche).

“La doc est souvent bordélique. Montrez des exemples et la technologie en action.”

Et les données

“TED Talks : David McCandless. Le branding c’est bien, mais l’info est utile aussi ! Montrez aussi les données, racontez leur histoire. Transmettez l’info avec une histoire et des illustrations, des graphiques. C’est facile de trouver et transformer l’info, regardez un peu YQL…”

YQL est une sorte de langage de requête facilitant la récupération et la transformation de données stockées un peu partout.

Chris montre beaucoup d’exemples difficiles à décrire, la conférence sera en vidéo de toute façon.

Il montre comment il peut faire des interfaces intéressantes avec les données du Gardian balancées sur un Google spreadsheet et transformées avec YQL.

“Vous n’avez pas besoin de faire plein de trucs tordus, prenez Google charts par exemple, c’est super simple à utiliser, et en plus là, la doc est accessible.”

“Regardez un peu les sites programmableweb et heroku.com.”

Pas besoin d’être un super dév !

“Yahoo Firehose Search” permet d’utiliser tout Yahoo et d’autres sites comme vimeo, twitter, etc pour chercher un tag dans ces réseaux sociaux.”

“You are never too small to metter.” (Sarkozy + Carla en photo)

Du bel évangélisme qui se vit plus que se raconte, surtout en live ! Allez voir sur http://developer-evangelism.com (par l’orateur).

Questions

Si je met mes vidéos sur youtube et tout ces jolis services, mon client va raller !

R: Il faut lui dire “vous gardez le meilleur caché, et le pire visible, oups !”.

Vous allez directement au code, quels sont pour vous les liens entre développeur et le designer ?

Chez Yahoo, ils commencent par des prototypes papier pour “tout dire”. Ensuite, les développeurs commencent à prototyper, les designers pondent leurs mockups. Les gens ne s’attendent pas mutuellement.

C’est cool d’être tech-evangelist chez Yahoo ?

J’ai posé cette question !

R: “It’s fucking cool ! Avant d’être tech-evangelist, il faut commencer par bosser dans une agence ou tu souffres un peu et voit l’environnement dans lequel les gens évoluent. Sinon, le pied c’est que tu peux passer d’une techno à l’autre, toucher un peu à tout et c’est super cool.”

BTW, il m’a offert le joli bouquin à gagner

(Paris Web !) #2 Javascript Server Side (ssJS), par où commencer ?

Martin Richard — Thu, 14 Oct 2010 14:20:00 +0200

OK, là je m’y retrouve un peu mieux, et je me sens en terrain familier, ou presque : on parle d’exécuter du javascript côté serveur. Ma dernière tentative… ah oui ! Un module PHP expérimental qui embarquait Tracemonkey !

On va faire un point sur l’état de l’utilisation de JS côté serveur. Javascript est-il destiné au client-side ?

Conférence dirigée par Quentin Adam.

Pourquoi mettre du JS server side ?!

JS server-side est en fait déjà bien présent, et très lié aux technos no-SQL (bases de données sans SQL). À l’origine, Javascript a été créé pour le serveur-side, pour le serveur HTTP de netscape.

Le plus gros intérêt de JS server-side, c’est de limiter le nombre de langages dans une application web, On jongle déjà avec trois langages côté client, et côté serveur, n’en parlons pas.

C’est pas toujours évident pour un développeur Java (par exemple) de s’adapter au front ! Introduire Javascript un peu partout dans les projets web va permettre d’unifier les compétences, les outils de développement et de débug. L’auteur suggère qu’on gagnera(it) beaucoup en productivité.

À priori, je ne suis pas franchement d’accord avec tout ce qui se raconte pour le moment. Soit.

Par exemple, on code deux fois les objets métiers : un pour le serveur, un pour le client. Avec ssJS, on devrait pouvoir partager le code.

A terme, on pourrait voir le web comme une plateforme de développement globale : les nouvelles API sont assez excitantes et vont en ce sens : local storage, XUL (Application lourde avec front JS).

Javascript : un langage, des moteurs.

On voulait faire ECMAscript un standard global, mais tout le monde n’a pas suivi.

Regardons un peu le moteur Rhino : codé en Java à la suite d’un accord avec Sun. Le projet n’a pas franchement rencontré beaucoup de succès. La fondation Mozilla a récupéré Rhino quand Netscape a disparu.

Rhino est inclus dans les SDK java aujourd’hui. C’est un peu le moteur à la base de la tendance ssJS.

Moteur JS n’est pas Navigateur !

Le moteur Javascript n’est pas le navigateur : on commence à voir les limites (actuelles) de la solution. La plupart des API (comme DOM) ne sont pas accessibles server-side. Les frameworks Javascript actuels utilisent beaucoup le DOM, et doivent s’adapter.

Sous le capôt

Les requêtes HTTP vont être transformées en événements Javascript : on peut les voir comme des web-sockets.

Un aspect intéressant de cette vision, c’est qu’on peut abonner plusieurs utilisateurs à un même fil d’exécution, c’est à dire, calculer une réponse un fois, et lier tous les événements à ce même calcul. On optimise clairement la sollicitation des ressources.

APE : Ajax Push Engine

Ape est basé sur le/les moteurs Javascript de Mozilla, qui ont été intégrés dans un module Apache. C’est un outil permettant de faire du web temps réel sans les sockets (par exemple). Ils ont poussé les développeurs de Mootools à créer Mootols Server-side, qu’ils utilisent comme base pour le framework.

APE est un excellent moyen de commencer à travailler sur les événements serveur (ce qui ne se fait pas, par exemple, en PHP et en Java).

Node.js

Google a présenté V8. Node.js fait partie des expérimentations de portage de V8 côté serveur. Node.js est porté par la communauté Ruby. Node.js s’inspire des packages Ruby dans son architecture : de nombreux développeurs on créé des bibliothèques qui couvrent de nombreux besoins. Par contre, on ne peut pas dire que Node.js soit franchement stable (API comme projets basés sur Node.js).

Par contre, Node.js permet de faire “ce qu’on veut”, pas seulement du HTTP. Node.js utilise beaucoup Git (NDLR: troll sur git, bien sûr) et github comme forge pour récupérer les différents packages.

On retient deux défauts majeurs : l’écosystème est difficile à qualifier, et Node.js est mono-thread.

On cite le framework Node.js : Express (semblable à Sinatra en Ruby).

Normaliser le ssJS ?

CommonJs est un consortium qui cherche à standardiser un peu tout ça. Oh et la production pour des grands comptes… c’est quand même pas pour tout de suite.

Questions/réponses

J’ai plutôt l’impression qu’on va vers le polyglotte : un langage par besoin.

R: C’est vrai pour beaucoup de cas. Mais quand on est dans un processus qui n’est pas métier, c’est à dire sur l’aspect clairement “application”, on arrête de “doubler” le développement.

NDLR : il n’est clairement pas fan des outils de génération de code, qui ne produisent pas un code “très propre”. Mais je trouve son jugement un peu sévère au sujet de Google Web Toolkit.

Vous ne pensez pas que l’intégrateur front et le développeur back sont deux métiers différents ? Les problématiques ne sont clairement pas les mêmes !

Question posée par votre serviteur. Je pense que je n’aurai pas dû préciser que je suis étudiant, il a répondu “ouais enfin, pour un blog, on s’en tamponne”. Oups, merci et au suivant.

R: la question ne doit pas se poser comme ça, unification ! Un seul langage !

Un thread pour plusieurs requêtes, c’est cool mais… personne ne fait la même requête, si ?

R: Si on prend l’exemple de twitter, je ne suis pas d’accord : un twitt bien suivi contient un lien, et bim ! Tout le monde fait la même requête.

Moi je voudrais parler de “JSS”, Javascript Starsheet qu’on a un peu tous oublié !

JSS permet de faire de la génération de feuilles de styles avec Javascript. Va-t-on TOUT faire en JS et faire disparaître les autres langages ?

R (du public) : NON !

R: On va commencer à faire de javascript un peu partout, par contre, on en a de moins en moins besoin puisque certains langages sont de mieux en mieux

R (de Daniel Galzman, Chairman au W3C \o/ ça la FOUT MAL :p): juste pour dire, euh, écrire des styles en javascript, on a abandonné parce que, euh, facteur 40 côté performances ! On en est tous revenu, même au W3C !

Comment ça se passe quand on “met des requêtes en attente” ? Comment on gère la mémoire, tout ça ?

R: la mémoire ça coute rien, je bosse dans le cloud et on s’en carre un peu de la mémoire. Par contre, c’est vrai qu’on va commencer à manipuler les processus idle, c’est un peu plus complexe (mais on est pas en attente active).

Des APIs pour le web-offline ? Je pense aussi à Gears.

R: Gears est mort, google le dit : ils veulent aller vers les standards. Le web-offline c’est bien, pour plein de raisons, mais niveau API, il manque encore beaucoup.

Conclusion

Il y a des tonnes de projets de ssJS, et beaucoup de trolls, mais vous pouvez beaucoup vous amuser dès maintenant !

(Paris Web !) #1 La conception universelle : ou votre site web s'adaptera à tous les besoins.

Martin Richard — Thu, 14 Oct 2010 14:13:00 +0200

Je suis à Paris Web pour trois jours, je vais essayer de raconter ce que je vois au mieux. Tout est posé brut en fonction de ce que j’entends (j’essaierais de faire une relecture clean quand je serais un peu plus reposé). Soyez indulgent, il est possible (voir probable) que je n’ai pas tout suivi !

Retrouvez tous les billets sous le tag ParisWeb.

Cette première conférence est dirigée par Matt May, Responsable accessibilité chez Adobe (rien que ça). Sa conférence est en français bien qu’il soit anglophone, ce qui rendait le tout parfois un peu difficile à suivre.

Matt May commence par quelques points de repère de l’histoire de la problématique d’accessibilité en guise d’introduction, il nous parle des années 90, d’HTML2 et des attributs alt (<img alt>) et summary (<table summary>).

alt est devenu un attribut d’accessibilité grâce à l’amélioration des technos périphériques. En fait, alt n’était pas tout à fait prévu pour être “accessible”, mais plus pour suivre le trait sémantique prévu.

En 1999, WCAG 1.0, norme d’accessibilité est arrivée : très dure et limitée à HTML.

En puis en 2000 les mobiles qui peuvent être connectés à internet commencent à arriver. Exit HTML, bonjour WML ! On devait créer deux sites : un “classique” et un pour le mobile. Alors est arrivé XHTML. Le web mobile a vraiment explosé avec l’iPhone, car le navigateur approchait efficacement la navigation sur un PC. Maintenant, les tablettes arrivent ! Bientôt, on aura Google TV, les “expériences utilisateur” varient de plus en plus !

Aujourd’hui les outils permettant d’accéder au web se multiplient : comment se débrouiller pour concevoir un front qui passe sur tout ces outils ?

La conception universelle, c’est quoi ?

Concevoir des produits et des environnements pour qu’ils soient utilisables par toutes les personnes, dans la mesure du possible, sans recourir à des adaptations ou à la conception spécialisée.

On s’est inspiré du monde de l’architecture pour en définir les principes :

Une utilisation égalitaire : tout le monde doit pouvoir accéder au web de la même manière.
la flexibilité d’utilisation : par exemple, lire un site web sur son mobile avec le soleil dans le dos… on ne voit rien !
Une utilisation simple et intuitive : besoin d’exemples ? Mais si : le clavier virtuel, la loupe, etc… Tout le monde découvre des outils présents sur PC depuis longtemps, pour les handicaps !
La tolérance de l’erreur : il faut prévoir les erreurs simples, on a souvent un peut de mal à s’y retrouver.
Peu d’effort physique : par exemple, prèsque 10% des personnes (aux USA) ont du mal à utiliser une souris. On arrive à 25-30% chez les personnes agées. Avec les mobiles, les boutons sont très petits…

Il faut imaginer qu’on s’attend à un nouveau type de nouveauté dans peu de temps (1, 2 ans) : on supporte déjà trois types d’ecrans, à quand un quatrième ?

Les outils

Dans le bâtiment, on pense à choisir les matériaux qu’on utilise, ils ont tous leurs propriétés, et construire un bâtiment en verre, seulement du verre, c’est plutôt… fragile.

Dans le web, c’est pareil, on a HTML, CSS, Javascript, Canvas, etc il faut choisir l’outil qui colle au besoin. On utilise encore trop souvent HTML pour faire de la mise en page (quelle idée !)

Matt compare les navigateurs avec les bases des bâtiments : les bâtiments sont bâtis sur… et les sites marchent sur… (Un petit trololo au passage)

du béton … Mozilla (Gecko),
des roues … Webkit
de la boue … IE !

La comparaison continue avec les utilisateurs : il faut penser aux différents handicaps et les assistances qu’ils utilisent.

Évoluer !

N’oublions pas qu’il faut faire évoluer notre métier : les outils changent, il faut penser à créer des solutions ! Et surtout, nous ne sommes pas seuls pour le faire ! En tant qu’utilisateurs des normes du W3C, par exemple, nous sommes tout à fait légitimes pour apporter notre retour aux auteurs des spécifications !

Questions-réponses

Que vouliez vous dire par “prévoir l’entropie” ?

R: L’idée c’est qu’il faut savoir s’adapter : on s’adapte souvent en fonction de nos statistiques d’utilisateurs par exemple… c’est un peu limitatif ! On ne prévoit pas les utilisateurs, que l’on ne connait pas encore, et qui vont commencer à utiliser des nouveaux outils (lecteurs d’écrans, nouveaux mobiles, IE9 pour Windows Phone 7 !)

C’est pas vraiment une question mais plus un remerciement…

…l’accessibilité touche tout le monde à un moment ou à un autre : parfois on est simplement fatigué, etc.. ça marche aussi !

R: c’est pour cela que je suis ici !

Pensez vous que le “design universel” va remplacer tout ce qu’on subit comme contraintes sur l’accessibilité, l’adaptation du design, etc ?

R: J’espère que oui, la “conception universelle” progresse. Par exemple, maintenant, même si ce n’est pas très “politiquement correct”, on voit bien que l’accessibilité et ce genre de problématiques sont au centre de toutes les attentions, car aujourd’hui l’utilisateur “handicapé” est celui qui a des moyens : il achète un mobile ! Les personnes souffrant d’un handicap réél étaient malheureusement un peu sous considérées…

“Open trololo” : vous parlez d’accessibilité, je répond norme. Pourquoi avez vous parlé de Flash ?

R: Je suis “Monsieur Adobe Accessibility” ! Je ne veux pas faire de la pub pour flash, j’ai aussi travaillé pour le W3C. Ce qui est important, c’est de connaître les propriétés de chacune de ces technologies, par exemple, il y a la balise video (40% des navigateurs) et flash (>98% de pénétration, Apple i* inclus). Aujourd’hui, pour faire des sous-titres standardisés et fonctionnels, aujourd’hui il faut utiliser flash. Il faut savoir que si on en a besoin, ça existe.

On sait que plus tard, on va passer au standard. Mais aujourd’hui flash est à considérer.

Il y a-t-il des outils qui permettent de mesurer l’accessibilité ?

Mmmh, oui et non : on regarde les stats pour voir ce qui existe, on regarde les outils des utilisateurs, les outils des développeurs, et on va tenter de s’adapter avec des fallbacks. Il n’y a PAS de réponse absolue.

Pensez vous que pour cette conception, il faut adapter les outils existant ou pousser les nouveaux outils ?

Je pense avoir compris la question. C’est important de savoir que les systèmes de fallback ne sont pas basés sur les standards eux-même mais sur l’observation (comprendre: les limites des navigateurs). Il faut aujourd’hui tenir compte des capacités de chaque navigateur. À ce niveau, il faut s’adapter d’un navigateur à l’autre. Le plus important c’est qu’on créé des sites avec une structure qui suive les normes.

Peut-on commencer un projet avec Zend Framework ou Symfony en ce moment ?

Martin Richard — Sat, 02 Oct 2010 18:08:00 +0200

Zend vient d’annoncer la disponibilité de leur certification pour PHP 5.3. On peut en comprendre que l’adoption à grande échelle de la dernière version du langage par les entreprises est proche. Parallèlement, les secondes versions des frameworks Zend et Symfony sont en phase active de développement et annoncent qu’ils sont conçus pour cette version de PHP et les suivantes : ils utiliseront abondamment des fonctionnalités qui n’existent qu’à partir de PHP 5.3.

Ces frameworks passent en nouvelles versions majeures et on annonce déjà quelques migraines pour ceux qui envisagent de migrer. On est donc en pleine période de flottement, et je me suis posé quelques questions sur les choix à notre disposition pour commencer un projet.

Le contexte

Au bureau des étudiants de l’Insa, l’équipe des “Orgas IF” (informaticiens) est en pleine ébullition : des développements d’applications spécifiques sont à l’ordre du jour, et dans l’idéal, si ces applications pouvaient tenir un paquet d’années, ça serait bien. Il faut dire que l’infrastructure informatique du BDE à de quoi faire pâlir la “DSI” de quelques PME (j’espère que certains se feront un plaisir de confirmer dans les commentaires, sait-on jamais !) et que tout le monde a à cœur d’être efficace. En bref, au BDE, on veut mettre à profit le talent des futurs ingénieurs en informatique pour proposer des outils de gestion aux principales manifestations que l’association encadre.

On en arrive à un point où nos applications (de gestion) seront développées en client léger, et PHP est la technologie retenue : open-source (comprendre, les libristes sont contents et le budget n’explose pas), les compétences sont là et la mise en place se fait rapidement. On veut faire les choses bien, développer des applications stables et qui tiendront la route, on pense donc à utiliser un framework : CakePHP semble avoir été abandonné, personne ne connait Code Igniter, on en est donc à Zend ou Symfony ?

PHP 5.3 pose-t-il problème ?

PHP 5.3 est arrivé le 30 juin 2009, avec le support du concept de namespaces et des fonctions anonymes comme premières grandes nouveautés. Zend Framework 2, tout comme Symfony 2 sont conçus pour PHP 5.3 : l’organisation des classes des deux projets reposera sur l’utilisation des namespaces, et l’architecture de Symfony 2 place le pattern Dependency Injection (cher à Fabien Potencier) comme concept central, celui-ci repose sur les fonctions anonymes (Edit 16/10 : la Dependency Injection ne repose pas sur les fonctions lambda, il peut éventuellement les utiliser).

Devoir maintenir nos serveurs vers une version à jour de PHP n’est pas un souci. Au contraire, on en est à la troisième mineure de PHP 5.3 et le tout est suffisamment stable pour sauter le pas. D’autant plus que d’après Pascal Martin, on appréciera un gain sensible en terme de performances. La question de PHP 5.3 est réglée.

Zend, Symfony ? Symfony, Zend ?

Le problème, c’est que Symfony 2 est prévu pour Mars 2011, Zend Framework pour (il me semble) un vague “fin 2010”, et que le choix d’un framework, tout comme le début de nos développements, doit se faire à peu près maintenant.

Symfony 2 est une réécriture intégrale, je pense qu’une migration de Symfony 1 vers 2 est presque impossible : même Doctrine passe en version 2 et d’après ce que j’en ai vu (notamment dans le billet teaser) on peut considérer que la rupture de compatibilité est effectivement au rendez-vous. J’avais un peu plus d’espoir avec Zend Framework 2 : une rupture de compatibilité s’impose par l’apparition des namespaces, mais l’outil de Ralph Schindler (PHP Tools) semblait faciliter le pas. Mais ça ne suffira pas : des packages risquent d’être renommés, et ceux-ci vont effectivement évoluer. A en voir l’introduction du Zend Framework 2 requirements, les choses vont bouger.

Symfony 1.4 sera supporté jusque novembre 2012. et je n’ai pas réussi à trouver des informations claires au sujet de ZF 1.10. J’ai l’impression que deux ans de support pour symfony 1.4 ne seront clairement pas suffisants : si on veut faire les choses proprement, ça n’est pas pour recommencer de zéro dans deux ans. Et à vrai dire, j’aimerai bien qu’un expert me parle un peu de la migration d’une mineure à l’autre avec Symfony 1 : j’ai vu de gros changements (Forms framework, changement de l’ORM par défaut) et des docs qui avaient du mal à suivre (nous n’avons ni les moyens ni le temps de suivre de véritables formations).

Là, je suis coincé et j’en arrive au titre du billet : peut-on commencer un projet avec Symfony 1.4 ou ZendFramework 1.10 dans l’état actuel des choses, au risque de devoir reprendre une grosse part de nos développements d’ici quelques mois ou années pour pouvoir ensuite apporter des évolutions fonctionnelles à nos productions ?

Peut-on commencer à travailler avec les futures versions ?

Un petit avant-propos : je n’ai pas eu le temps de suivre les mailing-lists, wiki et autres lieux de discussion de la communauté. Je risque donc de dire quelques bêtises sur certains aspects (notamment sur les points précis des changements à attendre). N’hésitez pas à me corriger dans les commentaires.

On est à peu près à un semestre d’une version stable de chacun des deux frameworks (j’ai du mal à croire à un ZF2 stable avant 2011). La roadmap du ZendFramework me semble être une bonne source d’informations pour faire un état des lieux. De nombreuses tâches impliquant des renommages de méthodes ou de classes (y compris dans le Bootstrap, aïe) semblent prévues, c’est plutôt mauvais signe.

Côté Symfony, il me semble que les fondations sont plutôt stables et que les grandes lignes ne bougeront plus (il y a déjà pas mal de doc à ce sujet sur Symfony-Reloaded). Mais les récents mouvements sur le dépôt du projet semblent indiquer que de nombreux composants ne sont pas encore développés : c’est clairement en plein travaux et j’ai du mal à croire qu’on puisse commencer à construire un projet sans manquer de matière.

Autant dire tout de suite qu’on risque d’avoir pas mal de boulot pour migrer d’une version non stable à une finale en plein pic de travail sur le fonctionnel. Il est bien trop tôt pour envisager de travailler avec ces versions.

Comment envisager l’avenir avec les versions actuelles ?

Il me semble avoir compris que symfony 1.4 sera la dernière mineure de la branche 1.x, il ne faudrait donc pas s’attendre à plus que des corrections de bugs et de failles. Zend Framework 1.11 semble lui avoir un avenir : la roadmap prévoit une mineure suivant la 1.10 (ou peut-être ai-je mal compris). Mais peut-être repousse-t-on le problème ?

Le problème est-il pris par le bon bout ? Finalement, peut-être qu’on a complétement loupé les critères sur lesquels faire notre choix. Pour l’instant, je pense qu’il faudra, selon le contexte et les besoins de l’application, choisir l’un des frameworks dans une version stable et faire l’impasse sur les questions relatives au long terme.

Il me reste deux questions pour lesquelles je pense manquer de recul pour répondre : Les migrations vers de nouvelles versions sont-elles nécessaires ? Quel est l’apport d’une migration sur un projet ?

MySQL : activer/désactiver une contrainte d'unicité sur certains tuples

Martin Richard — Sat, 21 Aug 2010 12:52:00 +0200

La situation n’est pas courante, mais elle peut arriver : dans une table de votre base de données, vous souhaitez vérifier qu’une valeur est unique, mais seulement dans certains cas. Il existe un moyen plus simple que de tordre son modèle pour obtenir ce résultat. La solution n’est pas miraculeuse mais a le mérite d’être assez simple à mettre en œuvre.

Imaginons un modèle un peu bateau :

une table de véhicules, dont certains n’acceptent qu’un occupant, d’autres plusieurs,
une table d’usagers, tous présents dans un et un seul véhicule.

On obtient un schéma semblable à celui-ci :

(table) véhicule :
- id_véhicule (clé primaire)
- nom_véhicule
- …
(table) usager :
- id_usager (clé primaire)
- id_véhicule (clé étrangère)
- nom_usager
- …

Il est impossible, avec ce schéma, de vérifier si un véhicule ne devant accueillir qu’un seul usager ne dépasse pas sa capacité : il faut vérifier que l’identifiant de ce véhicule (id_véhicule) ne soit présent qu’une fois dans la table. Ajouter une contrainte d’unicité sur notre table usager interdirait de fait d’avoir des véhicules accueillant plusieurs usagers.

On peut aussi ajouter un champ id_usager, qui serait une clé étrangère dans notre table véhicule, qui ne serait renseignée que pour les véhicules monoplaces. Mais on se retrouve à devoir vérifier dans les deux tables (véhicule et usager) pour obtenir notre ou nos usager(s).

L’autre solution que j’ai rencontrée avec Magento (et plus précisément dans la gestion des règles de promotion associées à un ou plusieurs coupons de réduction) consiste à conditionner l’activation de la contrainte d’unicité à la valeur d’un champ. La méthode est simple : dans notre cas, on placera la contrainte d’unicité sur le champ id_vehicule et un nouveau champ qu’on appellera exclusif. Si la valeur de ce champ exclusif est NULL, alors l’absence de valeur rend impossible de tester la l’unicité des valeurs de se couple. Si la valeur de ce champ est donnée (il faut qu’elle soit unique, j’y reviens plus bas) alors la contrainte d’unicité est activée et l’identifiant du véhicule est contrôlé.

Cette méthode permet d’obtenir la liste des utilisateurs en effectuant la requête sur la seule table usager, et c’est là sont principal intérêt : on obtient des meilleurs performances à la lecture. En contrepartie, le schéma de la base conserve une valeur de plus.

J’ai quelques doutes sur l’intérêt de cette méthode : pour moi il s’agit essentiellement d’une manière de modifier les contraintes métier d’un système associé à un schéma de base de données existant. D’ailleurs, dans la mesure ou notre champ exclusif pourra souvent accueillir plusieurs valeurs, la contrainte d’unicité n’est que partielle. Dans Magento, le champ est de type tinyint(1), il est donc possible d’associer 10 “usagers” à un véhicule supposément réservé à un seul.

Utiliser Bayes pour développer un filtre anti-spam

Martin Richard — Thu, 29 Jul 2010 14:00:00 +0200

En révisant mes cours de probabilités, je me suis dit qu’un bon petit exercice pour une application concrète à l’informatique pourrait être de réaliser un filtre anti-spam utilisant une méthode désormais courante : le filtre de Bayes (dans une version naïve). Je vais essayer d’expliquer la théorie, et qui sait, peut-être proposer une implémentation… un peu plus tard !

La formule de Bayes

La formule de Bayes (de Thomas Bayes, qui l’a trouvée) se base sur la notion de probabilité conditionnelle, c’est à dire, la probabilité qu’un évènement se produise sachant qu’un autre s’est produit. Nous allons nous intéresser à un cas particulier de cette formule, vous pouvez vous intéresser aux détails sur l’article Théorème de Bayes de Wikipedia. Par ailleurs, je me suis inspiré de l’article Bayesian spam filtering sur de wikipedia également.

Considérons l’ensemble des messages que l’on peut les répartir en deux catégories : les spams et les hams (non-spams). L’un est le complément de l’autre, c’est à dire que tout message est dans l’une et une seule des deux catégories.

Considérons ensuite l’évènement “le message contient le mot foo”.

Nous cherchons à déterminer la probabilité que le message soit un spam, sachant qu’il contient le mot foo (on notera cette probabilité Ps). Pour pouvoir écrire la formule facilement on notera ainsi :

p(foo/spam), la probabilité que dans un message on trouve le mot “foo” sachant que c’est un spam,
p(spam), la probabilité qu’un message soit un spam,
p(foo/ham), la probabilité que l’on trouve le mot “foo” dans un ham,
p(ham), la probabilité qu’un message ne soit pas un spam.

On a alors :

Nous obtenons donc une sorte de “valeur potentielle d’un mot comme spam”, mais notre filtre ne peut pas se baser sur l’analyse d’un seul mot. Il faut donc effectuer ce calcul sur chaque mot d’un message et évaluer le “potentiel de spam” de ce message.

En réalité, on va exclure les mots “neutres” dont la probabilité calculée avoisine les 0.5, c’est à dire qu’il y a presque autant de chance que ce mot soit contenu dans un spam que dans un ham. On s’intéressera en fait à une liste restreinte de mots, ceux dont la probabilité est proche de 0 (n’est presque jamais dans un spam) ou de 1(presque toujours dans un spam).

Pour calculer le potentiel de spam, nous allons considérer (naïvement) que les mots sont indépendants dans un message, ce qui est naturellement faux, puisque les mots constituent des phrases et sont liés les uns aux autres. On utilisera la formule suivante

On a au numérateur le produit des probabilités qu’un mot du message soit dans un spam (d’après les calculs précédents).

Au dénominateur on a ce même produit additionné au produit des probabilités contraires (la probabilité que le mot ne soit pas dans un spam).

Si un mot est présent plusieurs fois dans le message analysé, on peut inclure sa valeur plusieurs fois dans la formule, pour la rendre plus juste.

Cette méthode est naïve !

Cette méthode est assez naïve puisqu’elle se base sur un certain nombre de suggestions fausses. Il est alors possible de tromper le filtre en insérant de nombreux mots dont la valeur de spam est très faible afin de fausser le calcul. Afin d’améliorer encore un peu plus notre algorithme, nous pourrions considérer des chaînes de mots plutôt que des mots, permettant de mieux considérer le contexte.

Par exemple, si le mot “viagra” est très souvent contenu dans un spam, le mot “amour” sera (idéalement !) dans un ham. Pourtant “amour avec viagra” ne fait pas de doute sur sa qualité de “mot à spam”.

Feed the filter

Il est impossible de connaître par avance les valeurs potentielles de spam de tous les mots que l’on trouvera dans une boîte mail, il va donc falloir éduquer le filtre.

Le principe est donc de constituer une base de données contenant les mots considérés et leur fréquence dans des messages que l’utilisateur aura enregistré comme spams et non spams.

On doit donc enregistrer :

le mot,
le nombre de fois ou le mot a été trouvé dans un spam,
le nombre de fois ou le mot a été trouvé dans un ham,
le nombre total de spams analysés,
le nombre total de hams analysés.

On obtient p(foo/spam) (la probabilité que le mot foo soit dans un spam) en divisant le nombre de fois où le mot a été trouvé dans un spam par le nombre de spams analysés. p(foo/ham) s’obtient de la même manière.

Le problème des mots inconnus

Bien souvent, un e-mail contiendra un mot inconnu : soit parce que la base de données n’est pas encore suffisamment complète, soit parce que le mot est mal orthographié. Nous ne connaissons alors pas la probabilité qu’un tel mot soit contenu dans un spam, et pire, notre potentiel de spam Ps devient incalculable et n’a pas de sens (la probabilité que le mot soit dans un spam est nulle… tout comme la probabilité qu’il soit dans un ham !).

La seule solution qui s’offre à nous et d’exclure ce mot de nos calculs et de le compter une fois que le statut du message qui le contient est connu.

Passer à l’implémentation

Nous avons maintenant une bonne base théorique, et c’est suffisant pour proposer un filtre naïf capable de nous donner des valeurs qualifiant le potentiel de spam d’un message. Il nous reste maintenant à choisir des valeurs initiales, et à regarder les limites de ce filtre.

Nous devons réfléchir aux valeurs p(spam) et p(ham), respectivement probabilités qu’un message soit un spam ou non. On peut utiliser les valeurs enregistrées dans notre base : p(spam) correspond aux nombre de messages collectés comme spam sur le nombre total de messages analysés. Cependant, ces valeurs seront très certainement incohérentes dans un premier temps (le filtre n’a pas suffisamment appris). Je suggère de considérer qu’en dessous d’un certain nombre de messages analysés, le filtre sera neutre et considérera que “globalement”, la proportions de spams et de ham est identique : p(spam)=p(ham)=0,5.

Nous devrons également choisir la valeur P (entre 0 et 1) à partir de laquelle on considérera que le message analysé est un spam. Plus la valeur sera proche de 0, plus le filtre sera sévère. Un environnement peu spammé peut se contenter d’un seuil à 0,5, sur un formulaire en ligne ou une adresse e-mail de contact, prendre un seuil plus bas (0,3 ou 0,4) sera plus efficace.

Il faut bien comprendre que notre filtre sera parfaitement inutile sans une phase d’apprentissage consistante : nous devons déterminer une base conséquente de mots dont la probabilité de présence dans un spam sera vraiment élevée. Il est toujours possible de commencer avec une liste noire de mots dont la probabilité p(mot/spam) sera fixée à une valeur élevée (0,8-0,9).

Conclusion

De nombreux systèmes anti-spam reposent sur cette technique, même si les formules sont souvent adaptées et pondérées pour être ajustés à la réalité. On pourra, je pense, utiliser la version présentée dans cette article dans un environnement moyennement spammé comme un blog.

Soyons tout de même attentif, lors de l’implémentation, aux performances : notre base de données risque de gonfler très rapidement !

Ne sacrifiez pas votre code !

Martin Richard — Sun, 11 Apr 2010 16:20:00 +0200

Google vient d’exciter les fous-furieux de la SEO (ces gens qui veulent toujours optimiser une page web pour la faire grimper dans les résultats de recherches). Les ingénieurs de la firme ont annoncé qu’à partir de maintenant, l’algorithme de calcul de pertinence, choisissant l’ordre dans lequel les résultats sont affichés, allait tenir compte de la “vitesse de la page”. Tout de suite, tout le monde s’emballe, on annonce tout et surtout n’importe quoi. Faisons un peu de tri…

Analysons un peu l’annonce

Je disais donc que Google venait d’annoncer que la vitesse de la page allait être prise en compte dans les calculs de pertinence de résultats. C’est ce qu’on entend et lit à répétition sur divers blogs et sites internet d’information. Pour autant, l’annonce, sous cette forme, manque cruellement de précision.

La vitesse d’une page est une notion qui n’a presque aucun sens si on ne lui apporte pas un peu de nuance : une première distinction que l’on peut faire concerne la différence entre la vitesse côté serveur et côté client. Pour le serveur, la vitesse de la page correspond à la vitesse à laquelle la requête HTTP va être analysée, la page générée, renvoyée et le temps que le volume de données soit reçu par le client. Si on s’intéresse maintenant au “côté client”, on aura le délai nécessaire pour que la page soit reçue (l’aspect réseau est donc à cheval entre les deux côtés) et le temps qu’il faudra pour que la page soit interprétée et affichée par le navigateur. Pour le client, une page affichée ne correspond que très rarement à un seul aller-retour entre son poste et le serveur : les feuilles de styles, fichiers sources javascript et images sont autant de requêtes qui devront être traitées.

Il serait bon de savoir ce que les crawlers de Google seront effectivement en mesure d’analyser : les mesures de vitesse seront-elles empiriques ou théoriques ? Quels facteurs parmi ceux que je viens de citer seront concernés ? La vitesse pour google est-elle la même que pour le visiteur, le vrai, humain ?

Ce qui va changer

D’après les chiffres que j’ai pu lire dans l’annonce officielle, le paramètre vitesse affecte environ 1% des résultats de recherche (sur l’index actuel, c’est à dire, avec les pages telles qu’elles sont aujourd’hui). La pondération de ce paramètre sera d’ailleurs particulièrement faible en comparaison des critères de pertinence du contenu.

Le bon côté, c’est qu’il est probable que les pages immondes au possible des gros sites corporate (allez, au hasard, orange.fr, voyages-sncf.com, …) subissent à un moment ou à un autre un remaniement vers le mieux, grâce à l’orgueil blessé de leurs concepteurs ; autant dire que pour l’instant, malgré les nombreux reproches des utilisateurs, rien n’a bougé, je n’ai donc pas beaucoup d’espoir sur ce point.

Ce que j’aime beaucoup moins, ce sont les nombreux risques de dérives portées par les bouchers de l’optimisation : on coupe dans la conception, le code et on nettoie par le vide, autant que possible, pour ne garder que des bouts. C’est le point essentiel de mon article, et j’y reviens dans un instant.

Enfin, l’utilisateur sera peut-être gagnant si les développeurs s’emploient effectivement à améliorer les performances de leurs pages, mais le grand gagnant est -comme toujours- Google. Je pense vraiment que ce nouveau choix technique a pour but d’inciter les développeurs à effectivement améliorer “la vitesse des pages”, et ces petites améliorations qui s’accumulent, représenteront un gain de ressources et d’immobilisation de leurs serveurs qui ne se néglige pas.

Le code sacrifié sur l’autel du grand G.

On est maintenant au fond de mon propos : pour de multiples raisons j’ai peur que cette annonce entraîne des pratiques contre-productives pour la majorité d’entre nous (je veux dire, nous utilisateurs d’internet, pas seulement nous les développeurs web).

Pour aider les développeurs à optimiser leurs pages pour gagner des micropoints auprès des robots, de nombreux outils d’analyse et de benchmarking sont à notre disposition. Ceux-ci apportent de nombreux conseils, mais qui, définitivement, ne nous concernent pas tous. C’est au concepteur de connaître le véritable intérêt des différents critères d’analyse proposés par ces outils. Pour donner un petit exemple : Yahoo! Slow suggère d’utiliser des Content Delivery Network (côté Google Page Speed on est un peu plus sobre est on suggère de “paralléliser les téléchargements grâce à l’utilisation de plusieurs domaines”). Je devrais faire quelques tests pour compléter ma connaissance du sujet, mais ma première réaction est “Mes problèmes ne sont pas ceux de G. et/ou Y!” : à l’échelle de ce modeste site, par exemple, ai-je un intérêt à doubler mon parc de serveurs (j’en ai un seul), simplement pour transférer plus rapidement les quelques images et feuilles de styles qui composent la page ?

Par ailleurs, cette règle (màj : paralléliser les téléchargements grâce à plusieurs domaines) contredit celle qui me suggère de minimiser le nombre de domaines utilisés pour réduire le nombre de requêtes DNS…

Le pire n’est pas proposé par ces outils : il y a le concept du tuning de code, prôné par exemple par HTMLminify. Le principe est assez simple : minimiser au possible le poids de la page, d’une part en supprimant les caractères inutiles (espaces, commentaires, etc), et d’autre part en s’affranchissant des règles syntaxiques et des standards, en supprimant par exemple les balises les plus élémentaires et qui n’ont pas d’impact direct sur l’affichage : ~~DocType~~, balises de fermantes et même la balise <html> !

D’une part, on sacrifie la qualité du code : lisibilité, facilité de maintenance, debbugage, etc. Ces problèmes n’existent plus si on adopte une stratégie de mise en production avec pré-compilation, ces optimisations extrêmes n’apparaissent plus sur le code manipulé en développement.

Par contre, d’autres soucis bien plus dangereux ne disparaissent pas. On casse le caractère standard du code, au risque de rendre la page illisible par de nombreux navigateurs. On se dira qu’à priori on peut se débrouiller pour obtenir la même interprétation de la part des différents navigateurs. C’est sans compter sur la multiplication des nouveaux terminaux mobiles ; et il est fort possible que les prochains navigateurs adoptent des stratégies d’analyse plus proches des standards, et que les résultats deviennent très surprenant à l’avenir. Je vous laisse imaginer les coûts de maintenance. On peut ajouter les navigateurs accessibles qui utilisent de nombreuses informations contenues dans la page pour permettre à une personne souffrant d’un handicap de consulter un site internet, ces informations ne sont souvent pas utilisées sur d’autres navigateurs.

Pour les autres outils d’analyse, comme les parsers XML, on peut directement abandonner toute chance de s’en sortir.

Enfin, ces optimisations permettent de minimiser le poids de la page, et donc le temps de transit sur le réseau. Par contre, une fois la page arrivée chez le client, le résultat devient clairement contre-productif : le navigateur devra interpréter la page en Quirks mode, et utilisera nettement plus de ressource pour essayer de nettoyer, corriger et transformer le code de manière à le rendre conforme aux règles syntaxiques : c’est du temps perdu pour que la page soit affichée.

La discussion à se sujet est déjà en cours sur Sitxpress, où le commentaire de mon ami Adrian reformule mon propos.

Nous avons donc réfléchi au point de vue des développeurs, des moteurs de recherche, des utilisateurs. Il reste encore deux catégories d’acteurs qui ne doivent pas être oubliées. D’une part, les chercheurs du W3C : ceux-ci utilisent toute leur énergie pour standardiser le web, le rendre accessible et le faire évoluer. Sacrifier les standards, c’est aussi un peu sacrifier leur travail. D’autre part, pensons aussi aux concepteurs des moteurs utilisés par nos navigateurs. L’analyse, l’interprétation et l’harmonisation du code HTML non standard (et pire, ne respectant pas les règles syntaxiques) représente une montagne de travail de conception et de développement, c’est à dire : un gaspillage d’argent et de ressources qui ne seront pas destinées à l’implémentation de nouvelles fonctionnalités comme les très attendues nouveautés de standard HTML 5.

Ma conclusion sera aussi simple que brève : optimiser, c’est important, mais pas au point de faire n’importe quoi. J’en profite pour faire un peu d’auto-promo, car c’est le discours que je tiens dans mon article sur l’optimisation d’une application en PHP 5 dans le magazine PHP Solutions de ce moi-ci.

Màj : Merci à Agathe, d’Open21 pour le relai de l’information !

Nouveaux brouillons pour HTML 5 publiés par le W3C

Martin Richard — Fri, 05 Mar 2010 20:43:00 +0100

Le W3C, organisme de définition et de normalisation des langages qui font le web, a publié aujourd’hui sept documents sur HTML 5.

Ceux-ci sont toujours à l’état de “brouillons” (drafts), qui ont pour objectif, notamment, de permettre aux navigateurs de se préparer à implémenter les nouvelles fonctionnalités et de recueillir des commentaires de la part des contributeurs/utilisateurs.

Les principaux documents sont le brouillon de la spécification HTML 5, les différences entre HTML 4 et HTML 5, ou encore le document de spécification du langage HTML, se voulant être la référence du langage pour les intégrateurs souhaitant se conformer aux standards HTML. Contrairement à la spécification HTML 5, celui-ci ne vise pas a détailler le comportement prévu des navigateurs vis à vis des balises.

On apprend également que les canevas 2D et micro-données, jusqu’alors intégrés à HTML 5 ont maintenant leurs propres spécifications :

Enfin, les deux derniers documents concernent l’intégration du framework RDF en HTML 5 et la réalisation de pages bi-directionnelles (dont le texte va de gauche à droite et droite à gauche).

L’information vient bien sûr du W3C.

PHP et les sessions : durée de vie, utilisation avancée et quelques subtilités

Martin Richard — Thu, 18 Feb 2010 16:21:00 +0100

PHP met à disposition un ensemble de fonctions permettant de manipuler un mécanisme de sessions : un moyen efficace de conserver des données entre deux requêtes avec lequel vous êtes probablement familier. On s’en passe difficilement sur un site internet interactif !

Bien que ce mécanisme soit assez simple à manipuler, il reste néanmoins quelques subtilités qu’il faut connaître pour en profiter pleinement et éviter des erreurs regrettables. On s’intéressera tout particulièrement à la durée de vie des sessions.

Le mécanisme des sessions de PHP peut se comprendre assez simplement. Le serveur attribue un identifiant unique à l’utilisateur, qui sera retransmis à chaque requête (par le biais d’un cookie ou d’une variable dans l’URL). PHP utilisera cet identifiant pour retrouver les données de l’utilisateur qu’il stocke sur le serveur.

Dans un script php, une session démarre lors d’un appel à la fonction session_start(), cet appel est implicite si la directive session.auto_start du php.ini vaut on. Si aucun identifiant de session n’a été transmis dans la requête, alors PHP générera une valeur aléatoire renvoyée à l’utilisateur. Si un identifiant existe, PHP remplira la variable globale $_SESSION des données enregistrées.

<?php
// Initialisation des sessions
session_start();
 
// On accède à une variable de session, et
// on l'écrit si elle n'existe pas encore
if(!isset($_SESSION['foo']))
  $_SESSION['foo'] = 'bar';
 
echo $_SESSION['foo']; // La variable est utilisable dans le script courant

Les fonctions session_register() et session_unset() ne doivent plus être utilisées (elles sont considérées comme obsolètes).

Gestion des accès concurrents

Les données de sessions sont protégées en écritures : cela signifie qu’un seul script à la fois sera en mesure de les modifier. Ce comportement peut ralentir l’exécution de requêtes simultanées (avec les frames ou Ajax par exemple), l’enregistrement de la session sera retardé en attendant le (ou les) autre(s) script(s) soi(en)t terminé(s). Pour limiter cette attente, vous pouvez appeler explicitement la fonction session_write_close() (ou son alias session_commit()).

Sécurité

Fondamentalement, l’implémentation des sessions en PHP ne souffre pas de problèmes de sécurité, mais vous devrez néanmoins veiller à la manière dont vous les utiliserez. En effet, dans la mesure où une session est basée sur un identifiant transmis sur internet entre l’utilisateur et le serveur, cette donnée est très sensible. Si une personne mal intentionnée obtient l’identifiant de session d’un autre utilisateur, il devient assez facile d’usurper son identité.

Il existe plusieurs techniques (simples ou plus compliquées) permettant d’obtenir l’identifiant de session d’un utilisateur :

la capture : c’est simplement le vol de l’identifiant en le lisant chez l’utilisateur (risque qui doit être contrôlé par l’utilisateur),
la divination : l’identifiant est deviné par la personne mal intentionnée (pratiquement impossible),
la fixation : le pirate choisit et force l’identifiant de la session (que l’on peut éviter simplement).

D’une manière générale, on évitera de transmettre l’identifiant de session dans l’URL par sécurité (pour prévenir de la fixation). D’ailleurs, c’est assez mauvais pour le référencement. Ce comportement peut être désactivé avec la directive session.use_only_cookies à vrai. Bien entendu, un utilisateur interdisant l’utilisation des cookies ne pourra pas utiliser les sessions.

Dans tous les cas, quand le niveau de sensibilité d’une session est modifié (par exemple, quand l’utilisateur s’authentifie ou qu’il obtient de nouveaux droits d’accès), une bonne pratique consiste à générer de nouveau cet identifiant de session avec la fonction session_regenerate_id().

Par défaut, les données de sessions de PHP sont stockées dans un simple fichier de texte (dans le répertoire /tmp sous linux). Tous les scripts PHP peuvent lire ces fichiers car toute exécution de PHP est réalisée par un même utilisateur (à moins que le safe_mode soit activé). Sur un hébergeur mutualisé, il est peut-être plus prudent de stocker les données de sessions dans une base de données. Consultez la documentation de la fonction session_set_save_handler() pour en savoir plus sur la personnalisation de la gestion du stockage des données de sessions.

Durée de vie

L’un des points les plus délicats à appréhender dans le mécanisme des sessions concerne la durée de vie. Dans cette section, nous allons voir qu’il y a plusieurs facteurs qui permettent de déterminer la durée de vie d’une session.

On doit, dans un premier temps, distinguer le cas pour lequel l’identifiant de session est transmis par l’URL de celui où un cookie est utilisé.

Dans le premier cas, la session existera tant que l’identifiant sera transmis par l’URL. En fait, même recopiant la même adresse dans un autre navigateur, la session sera retrouvée.

Si on utilise un cookie, la durée de vie d’une session dépendra de la durée de vie d’un cookie. Cette durée est définie à l’aide de la directive session.cookie_lifetime. Si cette valeur vaut 0, alors le cookie sera maintenu par le navigateur tant que ce dernier ne sera pas quitté par l’utilisateur.

La plupart des directives de manipulation des sessions définies dans la configuration de PHP peuvent être modifiées dynamiquement pour un script, à condition que ces modifications interviennent avant le démarrage d’une session avec session_start(). Si le démarrage automatique est actif, vous ne pourrez pas manipuler ces valeurs. Pour pouvoir faire quelques tests, j’ai utilisé la fonction session_set_cookie_params().

Le script qui suit affiche la durée de vie restante du cookie de session et une chaine de caractère définie à la création de la session. Tant que cette valeur ne change pas, cela signifie que la session utilisée est toujours la même.

<?php
// Durée de vie de la session (Time To Live)
$ttl = 10;
session_set_cookie_params($ttl);
 
session_start();
 
if(!isset($_SESSION['foo']) || !isset($_SESSION['bar'])) {
  $_SESSION['bar'] = uniqid();
  $_SESSION['foo'] = time()+$ttl;
}
 
echo 'TTL de la session ('.$_SESSION['bar'].') : '.(($_SESSION['foo'])-time());

Voici quelques tests que j’ai effectué :

En choisissant la valeur 10 pour la variable $ttl et en actualisant régulièrement la page, on voit la valeur TTL diminuer puis la session se renouveler (nouvelle chaine de caractère affichée);
En choisissant la valeur 60, j’ai eu le temps de relancer mon navigateur avant la suppression du cookie, et de constater que la session était toujours active;
En choisissant la valeur 0, la session était toujours active plus d’une heure après sa création, mais elle n’a pas résisté à la fermeture d’un navigateur.

Ramasse-miettes

Nous avons vu ce qui causait la mort d’une session du côté du client, mais lorsque le cookie est supprimé, ou que l’identifiant n’est plus transmis, les données stockées sur le serveur ne sont pas supprimées pour autant.

PHP a donc mis en place un système de ramasse-miettes (ou garbage collector en anglais) chargé de supprimer ces données persistantes au bout d’un certain temps. Cependant, ce temps n’est pas nécessairement le même que celui de la durée de vie du cookie.

La durée de vie des données sur le serveur est définie par la directive session.gc_maxlifetime. Si les données ont été supprimées du serveur avant que la session ait expirée chez le client, cette dernière est tout de même réinitialisée. Il faut donc considérer (et c’est bien théorique, voir ci-dessous) que la durée de vie réelle d’une session est la plus petite des valeurs entre la durée de vie du cookie et la durée de vie des données sur le serveur.

La donnée ne sera effectivement supprimée que lorsque le ramasse-miette sera appelé. Cette action est effectuée aléatoirement lors du démarrage de la session, la probabilité de son déclenchement est défini par deux directives : session.gc_probability et session.gc_divisor. On a donc :

probabilité d'appel = gc_probability/gc_divisor

Les valeurs par défaut sont respectivement 1 et 100, la probabilité est donc 1/100.

Assurer la durée de vie de la session

Si vous choisissez de modifier la durée de vie de la session du côté du client (avec session_set_cookie_params()), il faudra appliquer les mêmes règles au ramasse-miettes. Cette opération ne peut être effectuée qu’en modifiant la directive session.gc_maxlifetime de php.ini.

Il est tout à fait possible de faire cette modification avec la fonction ini_set(), mais il faudra prendre certaines précautions. En effet : l’appel à ini_set() modifie dynamiquement la configuration, ainsi, lors d’une autre exécution, PHP considérera la valeur écrite statiquement dans les fichiers de configuration. Au passage, ce raisonnement est également valable lorsque la valeur de la directive est modifiée dans un fichier htaccess. Afin de garantir la durée de vie souhaitée à nos données de sessions, la méthode la plus simple consiste à les rendre inconnues pour un autre script ; autrement dit, s’affranchir plus profondément de la configuration statique de PHP.

La solution la plus simple consiste à choisir un autre répertoire de stockage des données de session, un sous-répertoire par exemple :

<?php
$ttl = 3600; // Une heure, en secondes
$local_sessions_save_path = ini_get('session.save_path').'/monsiteweb';
 
session_set_cookie_params($ttl);
ini_set('session.gc_maxlifetime', $ttl);
ini_set('session.save_path', $local_sessions_save_path);
 
session_start();

Avec cette solution, le garbage collector appelé dans le contexte d’un autre script supprimera les sessions périmées dans le répertoire défini par session.save_path, et non le sous répertoire que nous avons choisi. Pensez quand même à créer ce sous-répertoire !

Liaison d’autres données à la session

Dans certains cas, on peut souhaiter sauvegarder des donnés liées à une session sans utiliser la variable $_SESSION : un fichier envoyé par l’utilisateur, des données temporaires dans une base de données, etc.

Ces données ne seront pas supprimées par l’implémentation par défaut du ramasse-miettes. Nous allons donc devoir surcharger le gestionnaire de sessions par défaut, composé de six fonctions, qui se chargeront de :

l’ouverture de la session,
la fermeture,
la lecture des données de session,
l’écriture,
la suppression de la session,
le ramasse-miettes/garbage collector.

Une fois ces fonctions créés, il faudra les déclarer au moteur PHP avec session_set_save_handler().

Dans la suite de cet article, je vais surcharger le gestionnaire de sessions en reprenant le fonctionnement de celui apr défaut de PHP. Il est d’ailleurs très largement issu de l’exemple donné dans la documentation officielle. Dans certains cas, il aurait été utile de sauvegarder les données dans la base de données.

J’ai choisi d’utiliser une classe statique (MySessionHandler) pour centraliser ces fonctions, mais ce n’est pas une obligation.

<?php
class MySessionHandler
{
  protected $save_path = '';
 
 /**
  * On interdit la construction, puisque ce n'est pas nécessaire.
  */
  private function __construct() {}
 
 // Nous placerons ici les méthodes développées à la suite
}

Ouverture de la session

La fonction d’ouverture sera appelée avec deux paramètres : le chemin de sauvegarde et le nom de la session. Ces données seront transmises par le moteur de PHP. Cette fonction se chargera de conserver, pour le script courant, le répertoire de sauvegarde des sessions. Dans la mesure où cette donnée est transmise par le moteur de PHP lui-même, les autres fonctions de manipulation des sessions que nous avons vu avant sont toujours fonctionnelles.

Nous n’avons pas besoin de l’identifiant de session pour cette implémentation.

/**
  * Méthode d'ouverture de la session, c'est
  * @param string $save_path
  * @param string $session_name
  * @return bool
  */
  public static function open($save_path, $session_name)
  {
    self::$save_path = $save_path;
    return true;
  }

Fermeture de la session

Cette méthode est la plus simple : puisque rien de particulier n’est effectué à l’ouverture de la session, on ne fait rien à la fermeture :

/**
  * Fermeture de la session, exécutée à la fin du script
  * @return bool
  */
  public static function close() {
    return true;
  }

Lecture des données

La lecture des données consiste à récupérer les données écrites dans un fichier avant une précédente fermeture. Il faut donc vérifier que la session existait déjà, et n’a pas été supprimée.

Cette fonction doit impérativement retourner une chaine de caractères (string). Le moteur de PHP se charge lui-même de la sérialisation/désérialisation des données avant et après la lecture/écriture. Nous retournons donc directement le bloc de données lu, sans modifications :

/**
  * Lecture des données de session sérialisées.
  * @param string $id identifiant de la session
  * @return string
  */
  public static function read($id)
  {
    $return = '';
    $sess_file = self::$save_path.'/sess_'.$id;
    if(is_readable($sess_file))
    {
       $return = file_get_contents($sess_file);
    }
    return $return;
  }

Écriture des données

De la même manière, on écrira le bloc de données transmis par PHP directement dans le fichier de session. La méthode prendra deux paramètres : l’identifiant de session, et le bloc de données.

/**
  * Écriture des données de la session.
  * @param string $id
  * @param string $data
  * @return bool
  */
  public static function write($id, $data)
  {
    $res = false;
    $sess_file = self::$save_path.'/sess_'.$id;
    if(is_writable($sess_file))
    {
      $res = file_put_contents($sess_file, $data);
    }
    return $res;
  }

Destruction de la session et garbage collector

La suppression des données de session peut être effectuée à deux moments : lors de sa destruction explicite (avec session_destroy()) ou au passage du garbage collector. Nous allons donc implémenter une méthode delete() qui supprimera une session, et qui sera appelée par destroy() et gc().

Dans cet exemple, on supposera que certaines données, stockées dans un répertoire data/sessions/[identifiant de session] sont d’autres données liées aux session que nous souhaitons supprimer. On peut également imaginer devoir supprimer des données dans une base de données.

/**
  * Suppression des données d'une session.
  * @param string $id
  * @return void
  */
  protected function delete($id)
  {
    unlink(self::$save_path.'/sess_'.$id);
    // on suppose ici que le répertoire de session n'a pas de sous-répertoire.
    $sess_dir = 'data/sessions/'.$id;
    $to_delete = scandir($sess_dir);
    foreach($to_delete as &$file)
    {
      if($file == '.' || $file == '..') continue;
      unlink($sess_dir.'/'.$file);
    }
    rmdir($sess_dir);
  }
 
 /**
  * Destruction de la session.
  * @param string $id
  * @return bool
  */
  public static function destroy($id) {
    self::delete($id);
  }
 
 /**
  * Ramasse-miettes
  * @param int $maxlifetime
  */
  public static function gc($maxlifetime)
  {
    $toDelete = glob(self::$save_path.'/sess_*');
    foreach($toDelete as &$id)
    {
      self::delete($id);
    }
  }

Attention à l’identifiant de session !

Dans notre exemple ci-dessus, on se base sur l’identifiant de session pour connaître les fichiers associés à une session. N’oubliez pas que cette pratique n’est pas nécessairement idéale, puisque par sécurité, cet identifiant risque d’être modifié !

Conclusions

Attention, cet article permet de comprendre quelques points importants, mais ne prétend naturellement être complet (on en est même loin !). N’oubliez pas de faire vos propres tests et de lire d’autres articles pour en savoir plus, et plus particulièrement sur la sécurité, car je ne l’ai développé que pour mettre en garde quand à l’existence de risques liés aux sessions.

Facebook distribue sous licence open-source un traducteur PHP vers C++

Martin Richard — Tue, 02 Feb 2010 23:41:00 +0100

L’équipe des développeurs de Facebook a annoncé aujourd’hui la distribution (dans un futur proche) d’un outil permettant de traduire en C++ et compiler du code PHP : HipHop for PHP. D’après l’annonce officielle, cet outil permettrait à Facebook de réduire de près de 50% en moyenne la sollicitation du processeur sur la plupart des pages du service, dont le front-end a été essentiellement développé avec PHP.

PHP est un langage de programmation qui offre de nombreux avantages : une syntaxe souple, facile à apprendre et comprendre, une grande variété d’outils simplifiant le développement, une bibliothèque de fonction couvrant la plupart des besoins des développeurs d’applications web et c’est un produit libre. Ces avantages se traduisent facilement en excellents rapports coûts/temps de développement, ce qui rend le choix de PHP dans un processus de développement agile encore plus pertinent.

D’un autre côté, PHP est un langage interprété : le fichier source sera de nouveau lu et traduit en langage machine avant chaque exécution. Des outils permettent de mettre en cache une partie de ce traitement (les optimiseurs d’opcode) améliorent sensiblement les performances d’une exécution.

Pour les équipes d’ingénieurs de Facebook, ce n’était probablement pas suffisant, car ils ont développé en interne HipHop for PHP, afin de permettre à un script PHP d’approcher les performances d’un programme compilé en C++.

Des compilateurs PHP existent déjà, quelle est donc la valeur ajoutée de HipHop ?

Contrairement à Roadsend ou phpcompiler, HipHop n’est pas à proprement parler un compilateur. L’outil est en fait une chaine de traitement qui mènent à une version compilée, mais passant par une phase de traduction du langage en C++ optimisé pour les besoins. On supposera déjà qu’il est pratiquement inutile d’essayer d’analyser et modifier directement ce code C++ généré. Ce dernier sera compilé par le compilateur Gnu, g++.

La traduction s’effectue en trois étapes majeures :

Une analyse statique permet de collecter les informations sur les déclarations et les dépendances entre les fichiers composant le script : à priori, une table des symboles (classes/méthodes/fonctions) est dressée.
Une seconde analyse permet de choisir le type C++ optimal utilisé pour les symboles et variables (j’en reparle un peu plus bas).
Enfin, les instructions en PHP sont traduites en C++. Cette opération est essentiellement une conversion syntaxique (les deux langages sont assez proches du point de vue de la syntaxe).

Quelles sont les limites ?

A priori, la quasi-totalité de la grammaire du langage a été retranscrite, il est même probable que la plupart des librairies soient utilisables, dans la mesure où celles-ci, tout comme le moteur Zend de PHP, sont écrites en C.

La plupart des gains réalisés proviennent de l’optimisation de la “magie” de PHP, c’est à dire, l’ensemble des instructions qui nécessitent une évaluation dynamique. L’exemple le plus évident est probablement le transtypage à la volée. En effet, dans la mesure où PHP est un langage faiblement typé, il est possible de manipuler une variable sans restreindre son type : on peut facilement passer d’un entier à une chaine de caractères, par exemple. Cette souplesse à un coût, puisque le moteur PHP doit évaluer et déterminer le type de l’information manipulée (coût CPU), et en stocker une copie dans les principaux types (coût mémoire).

HipHop ne remplacera naturellement pas le travail d’optimisation du développeur, il est même possible de s’imposer quelques nouvelles contraintes, comme limiter les transtypages implicites.

Par ailleurs quelques fonctionnalités propres à un langage interprétés n’ont pas été portées en raison de la complexité de l’opération et du faible gain, comme la fonction eval(). On peut tout de même supposer que les noms de symbôles obtenus dynamiquement (voir ci-dessous) fonctionneront, puisque je suppose qu’on peut relativement facilement remplacer le mécanisme par des pointeurs sur fonctions en C++.

<?php
// Manipulation dynamique de symbole : on instancie une
// classe dont le nom est stocjé dans une variable
$classe = 'PDO';
$monObjet = new $classe(); // on vient d'appeler le constructeur de la classe PDO

En savoir plus

Pour ce soir (heure française), on doit se contenter de cette annonce : on ne sait pas encore exactement quelle licence sera choisie (on sait néanmoins que l’outil sera opensource), le code n’est pas encore disponible et le wiki mis en place n’est pas encore public. J’espère donc avoir rapidement l’occasion et le temps de faire des tests et des comparatifs de performance (avec un framework comme symfony par exemple).

Mise à jour : La licence retenue est la licence de PHP, le projet sera bientôt disponible publiquement sur le github de facebook.

HipHop for PHP serait déjà utilisé en production sur Facebook, on peut donc supposer que la première version mis à disposition sera déjà stable et bien avancée.

Annonce officielle sur le blog des développeurs de Facebook