Clever Garden, Clever Age, Clever Presence - 100% digital

La sécurité au travers de l'OWASP

Mickael Franc — 2012-05-10T08:57:32Z

La qualité d'une application web est intrinsèquement liée à la sécurité de cette dernière, c'est pourquoi nous avons décidé de vous faire une introduction sur l'OWASP et quelques concepts sur la sécurité applicative.

1. Définition

OWASP (Open Web Application Security Project) est un guide de sécurisation des applications web, c'est un "ouvrage" de référence des bonnes/mauvaises pratiques de développement, d'une base sérieuse en termes de statistiques, et d'un ensemble de ressources amenant à une base de réflexion sur la sécurité. Des outils sont aussi proposés pour effectuer un audit de sécurité.

2. Les projets de l'OWASP

De nombreux projets développés en interne sont proposés et disponibles librement sur le site officiel : https://www.owasp.org

Ces projets permettent aussi bien de faire de la veille, comme le TopTen d'OWASP qui liste annuellement les failles les plus couramment utilisées par des utilisateurs malveillants. Mais aussi des logiciels puissants, permettant de faire des audits de sécurité avancés sur n'importe quelle plateforme.

Sur le site d'OWASP est disponible un grand nombre d'articles détaillés sur des failles/vulnérabilités. Ces articles expliquent : le principe d'une faille, son impact, une ou plusieurs méthodes d'attaques, et un mécanisme de protection.

Le guide OWASP propose aussi des documents plus méthodologiques encadrant l'univers d'un RSSI (Responsable de la Sécurité des Systèmes d'Informations). Ces documents offrent une bonne pratique pour définir et qualifier les risques auxquels pourrait être confrontée une société, une application, etc... Afin de couvrir l'ensemble de l'environnement (humain et applicatif) pour ensuite manager les équipes sur les projets.

Voici une liste (non exhaustive) de projets populaires, ainsi qu'une description succincte :

- Top Ten : Liste des failles les plus couramment utilisées par des utilisateurs malintentionnés sur internet. Ce document est accompagné d'une qualification des menaces listées et d'une explication sur l'exploitation.

Cf : https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=2010_Translation_Efforts

Voici le Top Ten de l'année 2010 (vulnérabilités listées de la plus commune à la moins exploitée) :

Injections
Cross-Site Scripting (XSS) => Script corrompu à travers un site
Broken Authentication and Session Management => Violation de Gestion d'Authentification et de Session
Insecure Direct Object References => Références directes non sécurisées à un Objet
Cross-Site Request Forgery (CSRF) => Falsification de requête intersites
Security Misconfiguration => Mauvaise configuration de sécurité
Insecure Cryptographic Storage => Stockage cryptographique non sécurisé
Failure to Restrict URL Access => Manque de Restriction d'accès au niveau des URLs
Insufficient Transport Layer Protection => Protection insuffisante de la couche Transport
Unvalidated Redirects and Forwards => Redirections et Renvois non validés

Ce top 10 évolue dans le temps, certaines failles (comme les problèmes de sécurité dus à une mauvaise configuration) n'étaient plus dans le classement entre 2004 et 2010. Cet exemple montre qu'il y a de nombreux autres points à vérifier, qui ne sont pas listés dans ce classement. Même si vous pensez avoir sécurisé votre application web, vous pouvez déjà être vulnérable face à quelque chose auquel personne n'a jamais pensé auparavant. Certaines vulnérabilités dans les articles d'OWASP sont non-applicables au web, mais peuvent servir de base à une réflexion sur la sécurité et la création d'un référentiel de sécurité.

Il faut voir cette liste comme un référentiel du minimum à sécuriser.

- Webscarab : Un outil d'audit de sécurité. Il s'agit d'un proxy disposant d'une interface graphique qui, une fois relié à un navigateur, intercepte les requêtes/réponses HTTP entre le client et le serveur, ce qui permet de les analyser, de forger des requêtes soi-même, de tenter différentes injections, etc... Le proxy est intercalé entre le client et le serveur à la façon d'une attaque « Man in the middle ». Webscarab dispose de nombreux plugins permettant d'augmenter le nombre de fonctionnalités offert par l'outil (WebServices, Spider, XSS/CRLF, SessionID Analysis, etc...).

Cf : https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Remarque : Par défaut il est livré avec uniquement l'intercepteur de requête, la version "self-contained" est livrée avec tous les plugins. Le gros défaut de cette solution est qu'elle n'est pas régulièrement mise à jour (dernière en date : 04 Mai 2007) et n'intègre pas les dernières vulnérabilités découvertes.

L'intérêt de cette solution : avoir un outil qui facilite un audit applicatif. Ce logiciel ne permettra pas d'avoir une application ayant une sécurité élevée s'il est utilisé seul. D'autres tests seront à faire pour accroitre la sécurité de votre application.

- Webgoat : Il s'agit cette fois d'une application web volontairement non sécurisée. Elle est livrée avec un tutoriel et des exercices pratiques. Une fois de plus, OWASP met en avant l'aspect pédagogique de ces solutions, ayant pour but d'instruire l'intéressé sur les différentes techniques d'exploitation de vulnérabilités. L'intérêt est de former le développeur à produire un code sûr.

Cf : https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

D'autres projets intéressants et utiles pour le milieu de l'entreprise existent, mais ils feront sûrement l'objet d'un prochain article plus détaillé.

3. Orienter les développements vers une démarche défensive

Chaque projet est différent et comporte un seuil de criticité propre à lui. C'est pourquoi il faut qualifier chaque risque associé à ce dernier.

Une méthode consiste à créer un tableau croisé entre les vecteurs d'attaques (XSS, CSRF, etc…) et les risques résultants de ces attaques (défiguration du site, corruption du contenu de la base de données, perte de données confidentielles, interruption totale/partielle de service, etc..).

Chaque projet devrait avoir son propre référentiel de sécurité (Base OWASP + Spécificités du projet + Risque acceptable ou non en fonction du projet).

Une fois les vecteurs d'attaques définis, on est en mesure de prioriser l'implémentation de correctifs de sécurité.

Conclusion

Le guide OWASP regorge d'informations utiles pour tout niveau de compétence. Le développeur non initié au domaine de la sécurité verra cet univers démystifié, l'expert y verra une base de connaissances sur laquelle il pourra se reposer. Les outils proposés sont efficaces même si certains ne sont pas assez maintenus ou accumulent un retard par rapport à d'autres solutions Open-source. L'OWASP reste toutefois un référentiel soutenu par le milieu professionnel et amène à une réflexion intellectuelle sur le domaine de la sécurité, auquel chaque développeur devrait être sensibilisé.

Sud Web 2012 dans un mois : et dire qu'il y en a qui n'ont pas encore pris leur place !

Nicolas Hoizey — 2012-04-25T09:48:22Z

Chez Clever Age, nous sommes toujours excités à l'approche de conférences qui défendent la qualité web telle que nous la défendons aussi !

Du coup, à un mois de la deuxième édition de Sud Web, dont la première nous avait laissé des étoiles dans les yeux, l'excitation monte aussi chez nous de retrouver nos confrères, d'échanger et de construire tous ensemble sur les bonnes pratiques de la qualité Web.

D'autant plus que cette année, en plus de la traditionnelle journée de conférences du vendredi (dont le programme est plus qu'alléchant), les participants se retrouveront le samedi pour un "élaboratoire" où tout le monde pourra proposer des sujets sur lesquels élaborer des solutions, construire ensemble les outils qui améliorent le web de demain. Nulle doute que les Clever Agiens présents prendront une part active dans cette initiative originale et diantrement constructive !

Cette année, nous serons présents au coeur des participants, mais aussi dans le staff comme l'année dernière par l'action bénévole d'un Clever Agien motivé. Mais aussi, fait original : notre Jérémie Patonnier (qui y était orateur l'année dernière) y sera présent pour présenter les couleurs du sponsor Mozilla, dans la communauté duquel il est très actif !

Bref, rejoignez-nous y gaiement les 25 et 26 mai à Toulouse, et comprenez et construisez le Web de demain avec nous et les autres participants de Sud Web 2012 !

Et bien sûr, si par le plus pur des hasards vous n'avez pas encore de ticket, c'est par là ; dépêchez-vous, ça ferme le 13 mai ! —> http://sudweb.fr/2012/inscription/

Le mouvement DevOps

Gwenael Perier — 2012-04-17T11:11:11Z

De manière générale DevOps est un mouvement ayant pour objectif l'alignement du système d'information sur les besoins de l'entreprise (en se concentrant plus essentiellement sur la partie développement / opérations).

"DevOps" est un terme issu de la contraction des mots anglais "development" (développement) et "operations" (exploitation). " [1].

Dans cet article je vais vous présenter ma vision de DevOps. Elle n'est sûrement pas complète mais elle permettra je l'espère de démystifier le terme et d'en comprendre le sens principal.

Définition du mouvement DevOps

En regroupant les différents termes de plusieurs définitions données sur le web, voici ce que l'on obtient :

DevOps est :

un mouvement.
 une culture.
 un processus agile sur l'ensemble de la chaîne (du développement à la mise en production).
 une nouvelle approche technique.
 une autre approche humaine.
 une réponse à de nouvelles problématiques comme le  déploiement massif, le  déploiement régulier.

Pour résumer on peut dire aussi que le mouvement est également pour 30% une affaire d'outils, de code et de processus métiers et pour le reste (70%) une affaire de culture et de communication.

Bon, ok. DevOps est un mouvement, une culture, un état d'esprit, voire même une religion pour certains, mais en pratique, qu'est ce que c'est ? Nous y reviendrons plus loin dans cet article. Pour comprendre DevOps, et découvrir ses méthodes, processus, et les différents outils utilisés, il faut tout d'abord s'intéresser à son origine. Pourquoi ce mouvement est-il apparu ?

Pourquoi DevOps ?

De nombreuses entreprises (essentiellement les plus grandes) divisent le développement (ceux qui pensent et écrivent le code) et l'administration système (ceux qui déploient et exploitent les applications) entre différents départements / services. Dans ce type d'organisation, les développeurs ne sont pas souvent préoccupés par l'impact de leur code sur la production mais plus par la livraison fréquente de nouvelles fonctionnalités. À l'inverse, le service des opérations de production est plutôt concentré sur la stabilisation des services et de l'architecture ainsi que sur la performance des instances actuelles.

La mise en production est pour beaucoup d'entreprises une étape lourde, compliquée à cause des différentes procédures établies. Les équipes en charge refusent souvent le changement rapide du code (nombreuses livraisons / déploiements). Mais plus il y a de nouvelles fonctionnalités présentes, plus le temps pour la mise en production peut devenir important, plus il y a de chance d'avoir des remontées de bugs bloquants, plus il faudra de tests post-production, etc .... Potentiellement cela implique du temps d'indisponibilité pour l'application, du stress pour les équipes et bien entendu de l'argent perdu.

A l'inverse des équipes de production, les développeurs développent leur code sans la contrainte d'un environnement dit 'de production' (plusieurs serveurs, gestion de flux réseaux complexes, configurations différentes, systèmes d'exploitation différents). La plupart du temps, un développeur installe son propre serveur web avec sa configuration habituelle, sa base de donnée habituelle sur son système d'exploitation préféré, etc... Que celui qui n'a jamais eu le problème du 'ça marche sur ma machine' (mais bien entendu pas sur le serveur de recette ou de production) me jette le premier pingouin :).

Même au sein des équipes de développement le problème peut être rencontré. Installation d'Oracle avec une équipe de développeurs sous Mac OSX, Ubuntu, et Windows. Résultat : même code, mais pas un des développeurs n'a réussi à faire fonctionner l'application complète de la même manière !!!

Le mouvement DevOps tend à essayer de fusionner ces deux mondes que sont l'exploitation et le développement. Chaque monde va apprendre de l'autre et surtout essayer de se comprendre :

En facilitant la communication entre les deux mondes (utilisation de méthodes agiles, intercommunication).
En industrialisant les processus de livraison (intégration continue, déploiement continu, etc ...).
En utilisant des outils (Puppet, Chef, Vagrant , fabric, etc ...) pour l'industrialisation de l'infrastructure.

Comment être DevOps ;)

Communication, processus et méthodes agiles

Les équipes de développement ont besoin de communiquer avec les équipes opérationnelles. Elles doivent pouvoir adapter rapidement leur environnement de développement et les changements d'architecture sur leur code. De la même manière, lorsqu'une nouvelle fonctionnalité demande un changement d'architecture ou l'installation d'un nouvel environnement et/ou serveur, les équipes opérationnelles se doivent d'être de bon conseil sur la configuration et l'installation. Elles auront souvent une vision plus juste que les développeurs.

Les équipes opérationnelles ont besoin de communiquer avec les équipes de développement qui ont des connaissances sur des outils, des processus qui peuvent aider à rendre les environnements plus facile à gérer, plus efficace et plus propre. Elles ont également besoin de comprendre le besoin applicatif et fonctionnel des développeurs pour permettre une meilleure optimisation des ressources, un meilleur monitoring et une meilleure remontée d'erreur.

Les méthodes agiles ne sont pas réservées uniquement aux équipes de développement mais peuvent aussi être appliquées sur toute la chaîne IT. Les méthodologies de développement Agile comme Kanban et Scrum peuvent révolutionner les pratiques opérationnelles de la même manière qu'elles ont changé la façon dont les développements s'opèrent.

Prenons l'exemple de l'analyse des problèmes en production qui nécessite une coopération entre les équipes d'exploitation et celles de développement comme la gestion des logs et des exceptions, des outils de concentration et d'analyse de logs. DevOps permet avec les méthodes agiles de gérer sous forme de points les problèmes rencontrés et le partage des informations, des solutions facilitent la résolution des dits problèmes.

L'organisation, bien qu'étant le point le plus complexe à aborder pour l'adoption d'une culture DevOps, n'est pas impossible à mettre en place, même pour de grandes entreprises : Amazon a adopté ce concept, et une devise en est alors ressortie : « You build it, you run it ». Le point essentiel pour la communication est de s'assurer que les objectifs soient communs aux différentes parties et se dirigent vers une amélioration de la disponibilité, de la performance et de l'évolutivité des applications.

Industrialisation des processus de livraison

Beaucoup trop d'organisations restent encore sur le cycle : Développement long -> Recette longue -> Livraison douloureuse -> Bugs -> Recettes correctives -> Redéploiement de patch (ouf..) soit par méconnaissance , soit par peur du changement ou par le coût de celui-ci. Ce type de projet avec un planning de livraison à plusieurs mois regroupe souvent un lots de fonctionnalités pour éviter une multitude de déploiement (souvent dûe à la frilosité de la mise en production). On se retrouve alors avec des allers retours dans tous les sens et des attentes dans chaque équipe, ce qui peut créer des groupes (eux / nous) et certaines frustrations (exemple : ça fait deux mois qu'on a fini de développer cette fonctionnalité mais elle n'est toujours pas testée ni livrée en production).

Prenons le postulat de base : ''une portion de code qui n'est pas livrée n'apporte aucune valeur ajoutée à l'entreprise ou à l'application''. Plus les déploiements sont fréquents, plus le processus est maitrisé. Il y a moins de code à livrer, donc moins de risque d'erreur, moins d'impact lors d'un rollback / retour-arrière. De plus, une application avec laquelle on peut rapidement livrer des nouvelles fonctionnalités ou des correctifs de bugs aura un meilleur retour des utilisateurs (plus de réactivité) et donc une meilleure image. C'est là qu'intervient la méthodologie du déploiement continu permettant le déploiement du code de façon rapide et efficace. Pour arriver à une automatisation complète ou quasi-complète de la chaîne de production, plusieurs étapes sont nécessaires :

« Continuous Integration » est le processus d'intégration (génération de code, compilation, exécution des tests unitaires, fonctionnels, ..) à chaque changement d'environnement (source code, os...)

C'est une très bonne pratique de développement qui consiste à utiliser le « développement piloté par les tests (Test driven Development, TDD) » ou à aller encore plus loin en utilisant le ''développement piloté par les comportements'' (Behavior Driven Development, BDD) pour permettre une couverture améliorée du code et du fonctionnement de l'application. Ces tests sont ensuite exécutés par le serveur d'intégration à chaque évolution de code ou changement de périmètre fonctionnel. Le contrôle et la gestion des résultats (tests, fiabilité, analyse du code) sont à la charge du serveur d'intégration.

« Continuous Delivery » est l'étape suivante et caractérise la possibilité de déployer ses applications à tout moment.

Cette étape est très importante et est dépendante des résultats de l'intégration, si toutes les contraintes sont au vert, le déploiement peut se faire de manière automatisée sur l'environnement cible (recette, pré-production, production).

« Continuous Deployment » est l'ensemble de ces processus et méthodologies permettant le déploiement en continu en production.

Malheureusement, la démarche de déploiement continu est loin d'être simple à mettre en œuvre, car dépendante de tous les acteurs du système d'information de l'entreprise.

Quelques outils DevOps

Les outils jouent un rôle majeur pour industrialiser les processus et la gestion des architectures dans le mouvement DevOps. Voici donc quelques outils (la liste est loin d'être exhaustive) qui vous permettront de vous familiariser avec tous les concepts abordés et qui à mon sens représentent bien le mouvement DevOps :

Capistrano : outil open source pour exécuter des scripts sur plusieurs serveurs, son utilisation principale est le déploiement d'applications web. Il automatise le processus de déploiement d'une nouvelle version d'une application sur un ou plusieurs serveurs web.
Liquibase est une librairie open source (Apache 2.0 Licensed) pour versionner et gérer les changements de schéma de base de données.
Jenkins est une application d'intégration continue qui monitore l'exécution de jobs répétés, comme les builds d'un logiciel ou des tâches automatiques.
VirtualBox est une solution permettant de monter rapidement des 'Virtuals Machine'.
Vagrant est un outil pour construire des VM opérables en VirtualBox via scripting.
Puppet/ chef permet la gestion de configurations systèmes dynamiques.

Conclusion

Définir le mouvement DevOps n'est pas chose facile. Par contre, définir ce que n'est pas DevOps l'est davantage.

Voici ce qu'il n'est pas :

un produit ;
une personne ou une équipe ;
une recette miracle ;
une méthodologie stricte, au sens ou il n'y pas de règle prédéfinie mais plus une philosophie de développement.

Maintenant, à vous de vous faire votre propre opinion sur ce mouvement et ce qu'il représente pour vous.

Pour de plus amples informations sur le mouvement DevOps :

[1] Citation du site http://devops.fr/

Dagon, un nouveau media pour le Web

Boris Schapira — 2012-04-01T07:46:58Z

Nous avons vu, au cours des dernières années, le Web évoluer pour passer d'un simple répertoire documentaire au compagnon social qu'il est devenu aujourd'hui. Cette révolution n'a été possible que par le biais d'évolutions technologiques et d'un effort certain de standardisation qui ont permis d'ajouter de nombreux média (images, sons, vidéos) à ce qui était uniquement textuel. Aujourd'hui, le Web est prêt pour de nouvelles révolutions. Dagon est de celles-ci.

Dagon est un « Grand Ancien », dieu poisson, dans le mythe de Cthulhu de l'écrivain d'horreur américain H. P. Lovecraft.

Wikipedia : Dagon (Mythe de Cthulhu)

Voir aussi :

William Fries -> Free Willy
Wandaleach -> Archi Leach (A Fish Called Wanda)

Bon 1er avril !

On connaissait déjà les enceintes olfactives Odoravision, qui permettent, moyennant d'importants moyens financiers, d'équiper une infrastructure Home Cinéma. Mais pour le Web, il n'existait pas d'équivalent.

Forte de ce constat, la société française Dagon, basée à Sopoins (34), vient de présenter un premier prototype de périphérique olfactif entièrement interfacé au Web. Le dispositif est pour l'instant assez complexe, puisqu'il impose l'installation de pilotes, d'un service local et d'un plugin disponible uniquement pour Firefox. Mais son potentiel est suffisament grand pour qu'il ait été retenu pour une présentation internationale à la MozCon de Seattle le 25-27 juillet prochain.

Son inventeur, l'ingénieur William Fries, a tout d'abord imaginé son périphérique comme un pur produit d'accessibilité destiné à des populations privées d'un ou plusieurs sens. Devant l'intérêt suscité par ce qui n'était alors qu'un concept, il a contacté le W3C en septembre 2009 pour entamer avec eux un processus de normalisation (toujours à l'ébauche).

Dagon se compose pour l'instant de cinq capsules diffusant chacune un parfum particulier sur 16 intensités :

parfum montant, acide, aigu
parfum fruité
parfum boisé
parfum animal (musqué)
parfum terreux

Une odeur émise peut ainsi se décliner sur cinq coordonnées, chacune définie sur un encodage hexadécimal. Fort du million de possibilités offert par son périphérique, Eric Wandaleach imagine déjà des odeurs caractéristiques permettant de déterminer avec précision la présence d'un champ de recherche ou d'un formulaire à saisir.

D'autres débouchés sont évidemment bien moins nobles. On pensera immédiatement aux Marques, qui essaieront chacune de créer chez l'internaute une marque olfactive reconnaissable et patentée, ou aux publicitaires qui useront des parfums les plus chargés pour attirer l'attention sur leurs espaces publicitaires. "Nous avons pensé immédiatement aux dérives d'un tel système, c'est pourquoi nous nous sommes rapidement rapproché du W3C pour encourager une normalisation des plus rapides. Il est inconcevable pour nous qu'une marque puisse acheter un parfum et en interdire l'utilisation à d'autres" a confié le directeur de Dagon Eric Wandaleach à Jérémie Patonnier, notre expert en normalisation.

La spécification W3C

Encore à l'état de pré-draft (et donc seulement consultable au sein du bureau de normalisation), la nouvelle propriété CSS qui fait parler d'elle est donc odor. Elle sera bientôt utilisable dans Firefox 13 (nightly-build, à compiler soit même) sous cette forme :

-moz-odor: #2FA47;

(Il s'agit de la première proposition, il est encore fort probable qu'elle évolue, d'où la présence du préfixe -moz)

Il faut bien sûr être équipé du périphérique de la société Dagon, la bonne nouvelle étant que leur technologie est sous licence MIT et que d'autres constructeurs pourront se lancer dans leur fabrication. Acer s'est déjà manifesté pour équiper ses futurs ordinateurs et tablettes de cette nouvelle interface. Pourtant, Wandaleach ne semble pas inquiet : "Nous ne voyons pas l'intérêt de verrouiller ces brevets, c'est le software permettant les mélanges les plus subtils qui emportera le marché. De ce côté-là, nous avons quelques années d'avance sur nos concurrents".

Nous sommes encore à plusieurs années de la commercialisation au grand public mais en tant que spécialistes du Web, nous ne pouvons que nous féliciter de ce pas en avant vers un nouvel inconnu...

Play Framework 2.0 - Premières impressions

Matthieu Guillermin — 2012-03-23T13:13:21Z

Play 2.0 est une refonte majeure du framework faisant la part belle à Scala. La version Beta sortie en novembre dernier était assez loin d'être finalisée et nous avait laissé quelque peu sur notre faim. La sortie des premières RC et, depuis peu, de la version finale nous permet enfin de plonger réellement dans l'outil et d'analyser plus en détail cette nouvelle mouture.

Rien n'a changé ?

Lorsqu'on commence à tester rapidement Play 2.0, on se dit que finalement rien n'a vraiment changé. On télécharge le framework, on le dézippe, on l'ajoute à son PATH, on lance un "play new" puis un "play run" et on peut accéder à la page d'accueil de notre nouvelle appli dans notre navigateur en quelques secondes.

La structure du projet est sensiblement la même que pour la version précédente. On retrouve rapidement ces packages habituels : controllers, models, views. Les points forts de Play semblent avoir été conservé :

La documentation est intégrée dans notre appli en mode dev et acccessible avec une "route" spécifique
le code est rechargé "à chaud" sans qu'on ait besoin de s'en occuper
on peut écrire notre code en Java ou en Scala comme on pouvait le faire avec le module play-scala de la version précédente

C'est en creusant un peu plus qu'on se rend compte qu'il y a quand même beaucoup de changements.

Tout a changé

Accès aux données

Tout d'abord, l'accès aux données a été revu. Pour Java, c'est la librairie Ebean qui a été retenue en standard. Plus adaptée au mode de fonctionnement stateless de Play qu'Hibernate, elle est bien intégrée au framework. On retrouve globalement les mêmes automatismes que dans Play 1.

Pour Scala par contre, on change de philosophie avec le librairie Anorm. C'est plutôt un retour aux sources qui est opéré via l'utilisation directe de requêtes SQL mappées "à la main" vers des objets. Des outils sont disponibles pour faciliter la tâche, mais on est quand même loin du côté "magique" de la version Java.

Avec ces 2 possibilités offertes, le développeur est libre de travailler avec la solution la plus adaptée à son contexte (rapidité de développement, performance de l'application...).

Voici un exemple de code d'un Model réalisé avec Ebean :

Et voici le code d'un Model Anorm tiré d'une application exemple fournie avec Play :

Routing

Le routing n'a pas beaucoup changé en apparence, on retrouve toujours le même fichier de configuration des routes. Par contre, cette fois, la configuration est vérifiée à la compilation. Impossible donc de déclarer une route sans avoir créé le controller associé. Play nous apporte néanmoins une petite astuce pour créer très rapidement un controller "TODO" qui affichera une page spéciale dans le navigateur.

Controllers

La logique des controllers reste la même. On crée une classe Controller dans laquelle on déclare des méthodes statiques pour chacune de nos Actions. Il est également possible de créer une classe pour chaque Action. Le code en devient plus verbeux mais cela peut rendre les tests plus faciles.

Les Actions, au lieu d'appeler une méthode render(), doivent maintenant retourner un objet Result. Des helpers sont là pour construire des Result avec différents codes HTTP de retour (ok(), forbidden(), notFound(),…) et différents types de données (texte, json, html, xml,…). On donne ainsi la possibilité au développeur de manipuler finement la couche HTTP.

Les paramètres sont passés automatiquement à l'Action grâce au mapping effectué dans le routing.

Voici un exemple de code d'un Controller :

Formulaires

La gestion des formulaires fait son apparition à travers un système qui permet de structurer son code tout en restant simple. Il est conçu pour s'interfacer facilement avec le Model. Les cas d'utilisations classiques seront donc très faciles à implémenter. Les cas plus complexes nécessiteront un travail spécifique du développeur.

Templates

C'est pour moi un des changements les plus importants car il apporte une philosophie très différente du moteur Groovy utilisé dans la version précédente.

Le moteur de template repose entièrement sur Scala, ce qui a permis de le rendre "typé". En clair, chaque template attend des paramètres d'entrée typés (et peut appeler d'autres templates avec également leur définition de paramètres). C'est à la compilation que tout cela va être vérifié, rendant les templates très robustes.

Pour accentuer encore plus cette robustesse, l'appel au routing depuis les templates pour générer des urls (pour les liens, les formulaires,…) est également vérifié à la compilation. Avec ça, Il va devenir très difficile d'avoir un lien mort dans son application.

Il est à noter qu'il existe des solutions pour utiliser le moteur de template Groovy de Play 1 vers Play 2 (voir Groovy templates for Play ! 2 et Faster Groovy Template Engine). Il sera donc envisageable de réutiliser certains éléments lors d'une phase de migration.

Voici par exemple le code d'un template "index" prenant en paramètre un User et une liste de Link et appelant un template "main" :

Assets

Play 2.0 suit la tendance actuelle en matière de CSS et javascript en permettant de gérer nativement la compilation du code Less ou CoffeeScript. La gestion d'autres types de fichiers sources peut être ajoutée via des modules de manière assez simple.

Le framework en profite pour gérer également la minification des assets.

Asynchrone

Play 1 apportait déjà quelques briques pour le développement de traitements asynchrones. Une étape supplémentaire est franchie avec l'intégration d'Akka et son modèle d'Actor. Les traitements pourront désormais être distribués facilement par Akka sur plusieurs instances de l'application.

Les manques

Au delà de toutes ces nouveautés, comme très fréquemment lors d'une refonte, certains détails manquent à l'appel.

Le principal "manque" de cette nouvelle version est l'absence de compatibilité avec les applications développées en utilisant la version précédente. La migration est loin d'être évidente et nombre de projets resteront vraisemblablement en Play 1 pendant un moment.

Il faut noter également l'absence de module CRUD (utilisé pour créer rapidement des interfaces d'administration basiques). Cela est dû à la direction prise avec Anorm de redonner plus la main au développeur sur l'accès aux données en enlevant un peu de "magie".

Même si le code de Play 2.0 repose essentiellement sur Scala, l'utilisation du framework en lui-même ne posera pas de problème à un développeur Java sans réelle connaissance de Scala. En revanche, lorsqu'on veut aller fouiller un peu dans le code source du framework (chose qui arrive forcément à un moment ou à un autre), cela pourra se révéler assez handicapant. D'un autre côté, la simplicité de l'API de Play et la possibilité de pouvoir "mixer" Java et Scala peuvent en faire le framework idéal pour apprendre ce nouveau langage.

Dernier petit détail, le développement en utilisant Scala est gourmand en temps de compilation. Même si celle-ci se fait à la volée en cas de modification, on perd quand même un peu de réactivité lors des rafraîchissements de page.

Conclusion

Les grands principes qui ont fait la réputation de Play 1 sont toujours présents dans cette nouvelle version. L'API reste très simple à utiliser et les nouveautés sont réellement intéressantes. On regrettera l'abscence du module CRUD qui était très pratique dans les premières phases d'un projet à des fins de prototypage ou de test.

De l'importance de gérer les pages d'erreur

Guillaume Marty, Margaux Lespagne — 2012-03-16T09:01:54Z

Parmi les erreurs HTTP, celle ayant le code 404 est la plus fréquente sur le Web. Comment les repérer, les réparer et pourquoi pas faire le buzz autour des pages non existantes ?!

Qu'est-ce que c'est ?

Définition

En HTTP, chaque requête est accompagnée d'un en-tête spécifiant son code. Ces codes du protocole HTTP donnent au client une information relative à la requête. En cas de succès, le serveur envoie un en-tête 200 pour signifier que la ressource sera transmise sans problème au client. Un code commençant par un 4 signifie une erreur survenue du coté du client. Il en existe de plusieurs types, mais les plus courants sont :

Erreur 400 : mauvaise requête/page non trouvée. Cette page apparaît principalement lorsque le nom de domaine demandé n'existe pas.
Erreur 401 : Accès non autorisé. Ce type d'erreur survient lorsque la page demandée se situe dans un répertoire protégé pour des raisons diverses (travaux, sections privées ou autre).
Erreur 403 : répertoire interdit. Ici c'est votre adresse IP qui ne vous permet pas d'accéder à l'adresse.
Erreur 404 : fichier non trouvé. Elle apparaît lorsque la page demandée a été retirée, déplacée ou renommée.

Les erreurs 404

Un exemple de page d'erreur standard sous Apache.

Parmi ces erreurs, celle ayant le code 404 est la plus fréquente sur le Web. Petite explication sur ce chiffre :

Nous avons vu que le premier “4” indique une erreur provenant du client. Le serveur web vous indique que vous avez fait une mauvaise opération.
Le 0 représente une erreur générale de syntaxe (faute de frappe par exemple)
Le dernier chiffre 4 pointe vers l'erreur spécifique du groupe 40x, ici 404 : “fichier non trouvé” (Not Found)

Pour la petite histoire, une légende circule sur le choix du numéro 404. Il semblerait qu'« au CERN, en Suisse, les chercheurs, excédés d'aller sans cesse relancer un serveur défaillant installé dans le bureau n°404, aient attribué ce numéro d'erreur au défaut de connexion, en souvenir de cette pièce maudite. » (via Wikipédia)

Comment des liens vers des pages inexistantes apparaissent-ils ?

Cette erreur peut avoir de multiples causes. Soit le fichier a tout simplement été supprimé, ce qui est fréquent si le site a connu plusieurs refontes, soit l'url est erronée à cause d'une faute de frappe lors de la saisie de l'adresse. Une faute de frappe peut également être introduite par le webmaster en créant des liens vers ses propres pages ou les pages d'un site externe. L'apparition de ce type d'erreur peut désorienter les internautes. Ceux-ci peuvent être tentés de corriger manuellement l'URL, de cliquer sur le bouton "Page précédente", voire de quitter votre site.

Les bonnes pratiques ergonomiques

Bien entendu, il est important d'éviter les pages 404. Mais le long de la vie d'un site, il arrivera probablement qu'un utilisateur se rende sur une page non existante à un moment ou un autre. Il faut donc redoubler d'effort sur cette page pour expliquer à l'internaute ce qui a pu se passer. Il est essentiel de limiter sa frustration. Il existe de bonnes pratiques d'optimisation et de personnalisation d'un point de vue ergonomique, graphique et éditorial à mettre en place, en voici une liste :

Respecter la charte graphique

Rien de plus perturbant pour un utilisateur que de se trouver face à une page d'erreur par défaut. Il est donc important de garder la charte graphique pour rester cohérent avec l'ensemble du site web et ne pas perdre le visiteur. Celui-ci doit identifier clairement et rapidement qu'il est bien resté sur le bon site, et ainsi éviter qu'il ne le quitte.

Expliquer brièvement et clairement le problème

Il faut créer un contenu concis, permettant à l'internaute de se situer rapidement, avec un message simple expliquant que la page n'existe pas ou bien n'est plus disponible. Une formule d'excuse simple est appropriée : "Désolé, la page demandée est introuvable." Il faut considérer cette page comme une page d'accroche. Il est important de ne pas rendre l'internaute responsable de cette erreur, il doit être conscient que le problème provient uniquement du site.

Proposer des solutions

Une fois que l'internaute a identifié l'erreur, il convient de l'inviter à faire une action. Il est possible d'inclure un moteur de recherche interne pour que l'internaute précise sa demande. Dans de nombreux cas, la page recherchée existe toujours, mais a été déplacée ailleurs dans le site web. Cependant, dans la plupart du temps l'internaute déçu ne fera pas de requête de son propre gré (peur d'être déçu une deuxième fois peut-être). Il faut alors lui proposer des solutions intelligentes, comme pré-renseigner le champ de recherche avec des mots-clés tirés de l'URL.

On peut également épargner une étape à l'utilisateur en se servant de ces mots clés pour afficher les liens du site qui correspondent le mieux à la requête.

Proposer des liens utiles vers des pages clés de votre site :

lien vers le plan du site
navigation ou rubrique principale du site
liens vers les pages les plus “populaires” particulièrement avantageux sur un blog, car il n'y a pas de but spécifique à la visite d'un internaute mis à part la lecture d'articles intéressants.
lien vers la page de contact/formulaire, lui donnant la possibilité d'alerter le webmaster de cette erreur ou bien tout simplement, poser une question directement.

Une autre alternative consiste à prévenir l'internaute que la page demandée n'est pas existante puis le rediriger sur une page à forte influence : en général la page d'accueil du site

Ne pas indexer les pages d'erreur

D'un point de vue SEO, il est important que les pages d'erreur ne soient pas indexées par Google et les autres moteurs de recherche. Il faut donc bien vérifier que le serveur Web renvoie un code HTTP 404 lorsqu'une page inexistante est demandée.

Étude de cas

D'après L'étude de cas sur les pages 404 réalisée par Mountain Equipment Co-op de Which Test Won la mise en page semble également importante. Il convient d'adopter une page aérée et d'y ajouter une grande image pour illustrer et capter l'attention du visiteur.

“La meilleure version obtient un taux de conversion de 38.32% et une amélioration du taux de conversion de 3.56%. En parallèle, cette version présente une amélioration de 73.2% du chiffre d'affaires par visite.” “La meilleure version fournit aux lecteurs des excuses pour l'erreur, ainsi que des images plus attrayantes et les couleurs qui conviennent mieux aux attentes des clients (...). Cette version a également fourni un champ de recherche et une liste déroulante qui a simplifié le processus de re-navigation pour les utilisateurs - un moyen efficace de renouer le dialogue.”

Source : http://whichtestwon.com/archives/2254

Les erreurs à ne pas commettre

Il existe des pratiques anti-ergonomiques que l'on rencontre encore trop souvent sur le web. En voici quelques unes :

Certains sites utilisent la “redirection automatique vers la page d'accueil” n'expliquant pas à l'internaute ce qu'il s'est passé et pourquoi il n'a pas atterri sur la page qu'il avait demandé.
Afficher une page de type “Warning” (attention). La discrétion est de rigueur sur ce genre de page, rien ne sert d'apeurer l'internaute.

Les meilleurs moyens d'éviter les erreurs 404

Créer une page d'erreur fonctionnelle sous Apache

Le fichier .htaccess est utilisé pour de nombreuses choses : bloquer l'accès à un répertoire, demander un mot de passe, réécrire les url d'un site, etc. C'est bien entendu à la dernière utilité que nous allons nous intéresser ici. Tout d'abord, créez un fichier .htaccess que vous déposez à la racine de votre site. Puis à l'intérieur même de ce fichier, placez la ligne de commande suivante (exemple pour une page de type erreur 404) :

ErrorDocument 404 http://www.mon-site.com/404.html

Ensuite créez un fichier 404.html à la racine du site et placez-y le message d'erreur personnalisé.

Si vous êtes en manque d'inspiration pour cette page, il existe des scripts déjà prêts pour la personnaliser rapidement.

Créer une page d'erreur fonctionnelle en ajoutant le Widget 404

Google propose un service pour faciliter la création de pages d'erreur personnalisée : http://www.google.com/support/webma...

Le widget 404 remplace automatiquement les messages d'erreur par des suggestions utiles pour l'internaute. Cela permet aux internautes de trouver plus facilement l'information dont ils ont besoin, réduisant ainsi la probabilité qu'ils quittent votre site pour chercher ailleurs.

D'après tout ce que l'on a pu voir précédemment dans cet article, il convient de suivre l'augmentation du nombre de pages 404 présentes sur votre site et mesurer si les changements ont un impact sur votre trafic. Voici une liste de quelques outils pour tracker les pages d'erreurs 404.

Repérer les liens morts grâce à Google Analytics

il est possible de savoir combien de visites il y a eu sur votre page d'erreur 404. Si vous utilisez le code asynchrone, il suffit de placer le code JavaScript suivant dans le modèle de votre page 404 :

pageTracker._trackPageview(“/404.html ?page=” + document.location.pathname + document.location.search + “&from=” + document.referrer) ;

Vous pouvez également recevoir une alerte par email lorsqu'une page d'erreur est visitée trop fréquemment.

source : http://www.smashingmagazine.com/201...

Repérer les liens morts grâce aux outils pour les webmasters de Google

Vous pouvez lister les erreurs rencontrées par le robot d'indexation de Google et surtout les pages d'origine. Dans les outils pour les webmasters de Google, rendez-vous sur la page Diagnostic > Erreurs d'exploration.

Rediriger les anciennes pages

Si vous changez le nom de domaine de votre site, n'oubliez pas d'utiliser l'outil "changement d'adresse" des outils pour les webmasters de Google. Il vous permettra d'informer Google de votre nouveau domaine.

Créer le buzz !

Mettre en place des pages d'erreur personnalisées permet même de faire parler de vous. Certains sites l'ont bien compris !

https://github.com/404

https://github.com/500 (Notez l'interactivité avec la souris sur les deux pages ci-dessus)

Exemples de pages d'erreur qui font parler d'elles :

http://www.bonjour404.fr/
http://iplanwebsites.com/404
http://www.netmagazine.com/404
http://www.fryewiles.com/templates/...
http://www.incan.co.uk/404.html (de quoi vous occuper et oublier l'erreur, à voir si une fois le jeu énervant et terminé, l'internaute quitte le site)
http://www.cubancouncil.com/404
http://www.homestarrunner.com/toons.html
http://proteys.info/404/
http://www.404notfound.fr/
http://www.flickr.com/photos/pioupi...

Le nouveau M de LAMP : MariaDB

Benjamin Clay, Damien Alexandre — 2012-02-29T11:03:26Z

Nous étions jeudi 1er février au meetup MySQL organisé par LeMug.fr et SkySQL. Nous avons pu y approfondir nos connaissances sur MariaDB, le remplaçant libre de MySQL.

MariaDB : Un nouveau SGBD ?

MySQL est un Système de Gestion de Base de Données apparu en 1995 qui est devenu en quelques années un des plus utilisés dans le monde. En 2008, l'entreprise MySQL AB éditrice de MySQL est rachetée par Sun Microsystems, qui se fait racheter un an plus tard par Oracle.
Michael Widenius, aussi connu sous le pseudonyme de Monty, est le principal auteur de la première version de MySQL, et est le fondateur de MySQL AB. Il a quitté Sun Microsystems afin d'assurer la disponibilité d'une version gratuite et stable de son bébé.
C'est ainsi qu'est né MariaDB, un projet sous licence GPLv2 se basant sur MySQL, qui se veut être très stable, plus robuste, plus performant, et surtout 100% compatible avec ce dernier.

MariaDB se place donc dans la continuité de MySQL : nous y retrouvons toutes les fonctionnalités de ce dernier, avec, si possible, des corrections de bugs et des améliorations de performances. La compatibilité reste totale et les binaires de l'un sont échangeables avec ceux de l'autre, à condition de rester sur des versions mineures compatibles :

les données et les définitions de table (.frm) sont identiques ;
toutes les structures et les APIs clientes, ainsi que tous les protocoles sont identiques ;
tous les noms de fichiers, binaires, chemins, ports, sockets... devraient être les mêmes ;
tous les connecteurs (PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C connector...) fonctionnent sans changement ;
le paquet mysql-client fonctionne aussi avec un serveur MariaDB.

Parmi les différences, nous pouvons noter l'apparition de plusieurs moteurs de stockage tels que XtraDB, et Aria, une sorte de MyISAM transactionnel, ou encore FederatedX.

XtraDB est une version améliorée d'InnoDB, le moteur de stockage le plus souvent utilisé actuellement sur les projets PHP/MySQL. En effet, XtraDB est conçu pour être plus performant, notamment en exploitant plus efficacement les processeurs multi-cores et la mémoire.

Retours d'expérience

Le 1er février, Colin Charles, actuellement développeur chez Monty Program AB, le plus gros sponsor de MariaDB, a fait une présentation du projet dans un pub parisien.

Why MariaDB?

View more presentations from Colin Charles

La présentation et les discussions lors de cette soirée nous ont appris que des sites à fort trafic utilisent d'ores et déjà MariaDB en production : pap.fr, Pixmania, Paybox, … et d'autres entreprises tels que Viadeo l'utilisent pour leur BI.
Toutes ces applications qui ont migré de MySQL vers MariaDB ont gagné en performance. Pixmania serait passé de 50 serveurs MySQL à seulement 10 MariaDB, avec très certainement d'autres optimisations, mais nous n'avons pas pu avoir plus d'informations.

Benchmark sur une application existante

Après avoir eu écho de ces informations et de ces chiffres plutôt impressionnants, nous avons décidé de réaliser un benchmark rapide des serveurs MySQL 5.1 et 5.5, et de MariaDB 5.2. Pour cela, nous avons utilisé une page d'un projet existant qui contient de nombreuses requêtes SQL. Nous avons choisi une page ayant des requêtes de complexités différentes, certaines très simple, d'autres avec de nombreuses jointures. Le benchmark a été fait en effectuant 5 000 requêtes sur la page en question, et en utilisant les mêmes configurations pour tous les serveurs, les étapes ont été :

Lancement de MySQL 5.1
Lancement de Apache Benchmark sur la page Web
Arrêt de MySQL 5.1
Lancement de MySQL 5.5
Lancement de Apache Benchmark sur la page Web
Arrêt de MySQL 5.5
Lancement de MariaDB 5.2
Lancement de Apache Benchmark sur la page Web

Voici les résultats obtenus :

Nous remarquons qu'il y a une nette progression des performances entre les 2 versions de MySQL testées, et que MariaDB, bien qu'en version 5.2, est tout de même au-dessus de MySQL 5.5.

MySQL 5.5 est actuellement la version la plus avancée du SGBD et bénéficie de gains très importants sur ses prédécesseurs. La fusion de cette version dans MariaDB est actuellement en cours, MariaDB 5.3 est d'ores et déjà en release candidate, la version 5.5 suivra rapidement. Cette future version du SGBD disposant des dernières améliorations d'Oracle devrait donc surpasser les mesures effectuées avec MariaDB 5.2.

Conclusion

Si vous n'êtes pas encore prêt à passer à MariaDB en production, il est tout de même grand temps de vous y intéresser :

performances accrues ;
licence libre ;
support pour entreprises (via l'entreprise SkySQL par exemple) ;
parfaitement compatible, aucune migration de données nécessaire.

Petite anecdote : "MySQL", tout comme le moteur de stockage MyISAM, vient du prénom de la fille de Monty "My", MariaDB vient bien évidemment du prénom de sa plus jeune fille. Merci à SkySQL et LeMug.fr pour l'accueil, les bières et l'organisation de la conférence !

Utiliser, optimiser et servir des fichiers SVG

Jérémie Patonnier — 2012-02-15T13:53:59Z

SVG est un format d'images vectorielles qui repose sur une syntaxe XML. Il est actuellement supporté par tous les navigateurs du marché, y compris Internet Explorer depuis sa version 9. Le support de ce format s'améliorant rapidement, il devient de plus en plus utilisé. Ceci dit, le fait que ce format repose sur XML nécessite de prendre quelques précautions en termes de performance.

Rappel : Inclure du SVG dans du HTML

Si SVG peut se suffire à lui-même, le Web design moderne en fait une utilisation importante en conjonction avec les autres technologies Web que sont HTML, CSS et Javascript (à titre d'exemple, jetez donc un coup d'œil au site Vlog.it). Ainsi, avant de voir comment on optimise SVG, faisons d'abord un petit rappel sur les différentes façons d'inclure du SVG dans un document HTML.

Avec HTML, vous disposez de 4 techniques pour inclure du SVG dans le document :

la balise iframe,
la balise object,
la balise img
et, avec l'arrivée de HTML5, vous pouvez aussi mettre des balises svg directement dans du HTML.

Historiquement et techniquement, c'est la balise object qui est la plus sûre et la plus appropriée pour inclure du SVG. Elle vous permet d'éviter tous les effets de bord liés aux iframe (performances, accessibilité, etc.) tout en autorisant la propagation des événements DOM (ce que ne permet pas la balise img). Cerise sur le gâteau, elle vous permet de gérer élégamment les solutions de repli pour l'accessibilité ou, plus trivialement, de gérer les vieilles versions d'Internet Explorer. En effet, pour mémoire, si l'objet référencé par la balise object n'est pas compris par le navigateur, il affichera le contenu HTML présent à l'intérieur de la balise.

Du côté de CSS, il est possible d'inclure du SVG via :

la propriété background-image (extrêmement utile en conjonction avec la nouvelle propriété CSS 3 background-size)
la propriété content utilisée avec les pseudo-éléments ::before et ::after.

Il sera également possible à terme de l'utiliser avec la propriété CSS 3 border-image. Malheureusement, à ce jour, aucun navigateur ne supporte cette propriété correctement, en particulier avec SVG.

En résumé, navigateur par navigateur [1], ça va donner ça :

Intégration	IE	Firefox	Chrome	Opera
iframe	ok	ok	ok	ok
object	ok	ok	ok	ok
img	ok	ok	ok	ok
svg	ok	ok	ok	ok
background-image	ok	ok	ok	ok
content	ok	ok	ok	ok
border-image	non	bug	bug	bug

On notera un petit bug dans Firefox qui parfois pixelise les images SVG intégrées via CSS ou la balise img.

SVG et performance, les principaux écueils

En terme de performances, SVG souffre de deux écueils qui sont liés au fait que SVG est un format XML.

Premièrement, qui dit XML dit DOM. En effet, tous les navigateurs qui vont interpréter une image SVG vont d'abord construire un arbre DOM des éléments qui constituent cette image. Or, DOM est une API extrêmement lente qui peut consommer beaucoup de mémoire si l'on n'y prend pas garde. Ainsi, plus vous avez d'éléments dans votre image, plus son interprétation aura un impact sur les performances. Dans la mesure du possible, essayez toujours de réduire le nombre d'éléments nécessaires pour construire votre image.

Vous pouvez bien sûr toujours vous amuser à faire cette optimisation à la main, mais de vous à moi, ce n'est pas vraiment super folichon à faire. De ce point de vue, les logiciels de dessin vectoriel comme Adobe Illustrator ou Inkscape peuvent vous aider de manière assez efficace via les fonctions de « pathfinder » pour fusionner des formes entre elles ou via les fonctions de simplification des courbes qui vont vous permettre de réduire le nombre de vecteurs d'une image. L'aspect délicat étant alors de trouver le bon point d'équilibre entre le respect du dessin original et la version optimisée.

Deuxièmement, le format XML est un format texte assez verbeux. Concrètement, cela signifie qu'une image SVG est facilement plus lourde qu'une image bitmap du seul fait de son format natif.

Pour éviter ce problème, il vous faut compresser vos images. SVG supporte très bien la compression avec des résultats parfois spectaculaires (il n'est pas rare de voir des taux de compression de l'ordre de 70% à 80% avec une simple compression GZip). Pour cela, vous avez deux options :

produire du SVG compressé via GZip (qu'on identifie souvent avec l'extension .svgz au lieu de .svg)
demander à votre serveur Web de compresser le SVG à la volée lorsqu'il le sert.

La première option a l'avantage de réduire la consommation de CPU de votre serveur, tout en permettant de compresser le SVG au maximum, car les calculs de compression sont fait avant même la mise en production de vos fichiers.

De son côté, la deuxième option permet de gérer dynamiquement la compression en se basant sur de la négociation de contenu HTTP, afin de toujours servir aux navigateurs un format de compression qu'ils sont capables de gérer (GZip, Deflate, etc.).

En creux, les avantages de la première méthode sont les inconvénients de la seconde, et vice et versa.

Configurez votre serveur

Point essentiel quand on sert des fichiers SVG, vérifiez toujours que votre serveur Web envoie les en-têtes HTTP qui vont bien. En particulier, vérifiez toujours que le type MIME envoyé est bien image/svg+xml. Sans ça, certains navigateurs refuseront tous simplement d'afficher l'image, et les plus taquins vous afficheront un bel arbre XML lambda !

Si vous servez des fichiers compressés avec GZip, pensez bien à envoyer l'en-tête HTTP qui le signale, sinon, là encore, les navigateurs n'afficheront rien et les plus joueurs vous proposeront de télécharger le fichier.

Si vous utilisez le serveur Apache, il suffit d'ajouter ces deux lignes dans la configuration du VirtualHost (ou dans un fichier .htaccess) :

AddType image/svg+xml svg svgz
 AddEncoding gzip svgz

Optimiser SVG lui-même

Au niveau du document SVG, il est également possible de réaliser un certain nombre d'optimisations qui peuvent en améliorer les performances.

Un petit avertissement avant de rentrer dans les détails : ces optimisations nécessitent du temps et ne sont pas toujours automatisables. Elles sont donc coûteuses en ressources, or, on sait tous ce que cela implique dans un projet. Prenez donc le temps de peser le pour et le contre avant d'entamer une optimisation du code. Dans la mesure du possible, je vous indiquerai le coût de chacune de ces optimisations.

Réduisez les décimales

Les outils de dessins génèrent souvent des fichiers avec une précision trop importante (parfois plus de 6 chiffres après la virgule pour les valeurs chiffrées). Il est assez facile de réduire cette précision sans perte visuelle (2 à 3 chiffres après la virgule).

Coût de l'optimisation : Faible car facilement automatisable

Supprimez les balises inutiles

Les outils qui génèrent du SVG ont vite tendance à abuser des métadonnées (les balises title, desc, metaData). À moins qu'elles ne soient indispensables pour des questions d'accessibilité ou de référencement, vous pouvez les supprimer sans risque. Le cas des balises g ou svg, qui sont des conteneurs génériques, est un peu plus délicat car leur usage est parfois nécessaire. Il faut donc voir au cas par cas.

Coût de l'optimisation : Moyen, car même si c'est facilement automatisable, une part de travail manuel peut être nécessaire.

Préférez la balise path aux formes de base

La syntaxe de l'attribut d de la balise path est très compacte et s'optimise facilement (en particulier en utilisant les notation de coordonnées relatives), il est donc conseillé de préférer cette balise aux balises des formes de base qui sont souvent plus verbeuses.

Coût de l'optimisation : Élevé, car elle dépend fortement de votre outillage, de votre savoir-faire et du degrés d'optimisation que vous souhaitez atteindre.

Externalisez les attributs de présentation dans des feuilles de style

Certains attributs SVG peuvent s'utiliser comme des propriétés CSS. Ainsi, ils peuvent être facilement externalisés dans des feuilles de styles externes qui seront mises en cache par les navigateurs. Les sélecteurs CSS permettent également de mutualiser facilement les propriétés communes à certains éléments, ce qui limitera la verbosité de SVG.

Coût de l'optimisation : Moyen, car il repose sur le même outillage et le même savoir faire que pour les pages HTML. Cependant, il nécessite d'être bien pris en amont, surtout si vos fichiers SVG sont volumineux ou générés par des éditeurs d'images qui ne connaissent pas CSS.

Conclusion

Comme toute technologie Web, SVG nécessite un savoir-faire qui lui est propre. Ceci étant, en vous reposant sur vos connaissances en HTML/CSS et en suivant les quelques conseil de cet article, vous pourrez rapidement utiliser SVG dans un contexte de production sans avoir à vous soucier des performances. Amusez-vous bien !

[1] Notez que je ne cite pas Safari, mais c'est la même chose que Chrome. En ce qui concerne IE, il s'agit bien sûr de IE9 ;)

PostGIS et son utilisation avec un framework moderne

Paul Mallet — 2012-02-02T13:07:29Z

Pour rappel, PostGIS est une extension ajoutant des fonctionnalités géospatiales au systeme de gestion de base de données PostgreSQL, en se basant sur la spécification OpenGIS. Si votre application manipule des repères ou zones géographiques, des objets géométriques ou des distances, c'est donc un outil à ne pas négliger.

Malgré ses 10 ans d'existence (dont 6 en version stable), PostGIS reste très peu utilisé dans les projets Web, souvent à cause de son intégration compliquée au sein des différents frameworks. Nous allons voir ici que ce n'est pourtant pas toujours le cas, en décrivant son installation et son utilisation au sein d'un projet Play ! Framework

Installation & Configuration

Les consignes ci-dessous se basent sur la distribution Ubuntu 10.04 et sur la version 8.4 de PostgreSQL, mais l'installation varie assez peu pour les autres distributions et/ou versions, des paquets étant disponibles soit nativement, soit sur internet (voir http://trac.osgeo.org/postgis/wiki/... pour plus d'informations).

L'installation se fait grâce à deux paquets :

sudo apt-get install postgis

sudo apt-get install postgresql-8.4-postgis

Une fois ces deux paquets téléchargés, l'installation de PostGIS sur votre machine est terminée. Néanmoins, vous ne pouvez pas encore utiliser ses fonctionnalités avec votre base de données : pour cela, quelques manipulations supplémentaires sont encore nécessaires :

1.Connexion en tant qu'administrateur de serveur PostgreSQL

sudo su postgres

2. Activation du langage PL/SQL sur votre base de données :

createlang plpgsql my_geo_database

3. Ajout des fonctions PostGIS dans la base de données :

psql -d my_geo_database -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql

psql -d my_geo_database -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

4. Changer le propriétaire des tables créées (et ainsi les rendre accessibles depuis vos applications)

psql my_geo_database -c "ALTER TABLE geometry_columns OWNER TO my_user"

psql my_geo_database -c "ALTER TABLE spatial_ref_sys OWNER TO my_user"

Ça y est, votre base de donnée est prête ! Voyons maintenant comment l'utiliser dans un projet Play !

Utilisation dans Play ! Framework

Imaginons une application Web répertoriant les célèbres cabines téléphoniques anglaises(lien), et fournissant un certain nombre de services au visiteur, notamment basés sur la géolocalisation.

Une fois le projet Play initialisé, la première étape est de télécharger les quelques librairies (JAR) nécessaires à l'utilisation de PostGIS :

Le JAR PostGIS, fournissant le connecteur JDBC ainsi que les classes utilisables dans l'application.

Hybernate spatial et Hybernate spatial postgis qui fournissent le dialecte JPA permettant d'utiliser PostGIS conjointement à Hibernate.

Une fois les JAR ajoutés au répertoire lib/, réfléchissons à la conception du modèle de l'application. Commençons simplement en créant une classe PhoneBox, avec comme attributs un label, une latitude et une longitude :

public class PhoneBox extends Model {
 
 public String label;
 public double latitude;
 public double longitude
 
 public PhoneBox(String label, double latitude, double longitude) {
 this.label = label;
 this.latitude = latitude;
 this.longitude = longitude;
 }
 }

Une cabine téléphonique est un élément assez petit (sur une carte du moins) pour être considéré comme un point (par opposition aux polygones). Ca tombe bien, PostGIS utilise justement cette notion de Point :

import org.postgis.Point;
 
 public class PhoneBox extends Model {
 
 public String label;
 public Point location;
 
 public PhoneBox(String label, double latitude, double longitude) {
 this.label = label;
 this.location = new Point(longitude, latitude);
 }
 }

Nous avons donc remplacé le couple latitude / longitude par un seul attribut de la classe Point et modifié le constructeur afin d'instancier cet attribut à partir de ces mêmes latitudes et longitudes.

Comme beaucoup d'autres frameworks Java, Play ! se base sur Hibernate pour gérer la persistence des objets en base de données. Malheureusement, Hibernate ne reconnait pas nativement les types utilisés par PostGIS : C'est là que va intervenir la bibliothèque Hibernate Spatial, installée précédemment.

import org.postgis.Point;
 
 @Entity
 @Table(name = "phonebox")
 public class PhoneBox extends Model {
 
 @Column(name = "label", length = 100, nullable = false)
 public String label;
 
 @Column(name = "position", columnDefinition = "GEOMETRY")
 @Type(type = "org.hibernatespatial.GeometryUserType")
 public Point location;
 
 // pas de changement au niveau du constructeur
 }

En plus des annotations usuelles, l'attribut columnDefinition de l'annotation @Column détermine le type du champ en base de données, et l'annotation @Type détermine quand à elle la classe à laquelle Hibernate doit se référer pour gérer la persistance de l'attribut, ainsi que les requêtes HQL le concernant.

Après avoir relancé l'application, on peut voir que la table phonebox a bien été créée dans notre base de données, avec les champs correspondants.

Ajoutons rapidement quelques cabines téléphoniques pour voir leur représentation dans la base de données :

Les objets sont donc correctement enregistrés avec leurs données. On peut remarquer que le champ location est représenté par une chaîne de caractère peu lisible, c'est le cas avec PostGIS pour tous les champs de type geometry.

Une fois nos cabines téléphoniques disponibles, voyons ce que PostGIS nous offre comme possibilités d'utilisations. Une fonctionnalité pourrait par exemple consister à récupérer les n cabines téléphoniques les plus proches d'une position donnée. Pour cela, nous allons utiliser une requête SQL utilisant les fonctions PL/SQL ajoutées plus tôt :

public static List closest(double latitude, double longitude, int nb)
 {
 TypedQuery q = JPA.em().createQuery("SELECT p FROM PhoneBox p ORDER BY ST_DISTANCE(ST_MAKEPOINT(:longitude:latitude,), position)", PhoneBox.class);
 
 List list = q
 .setParameter("latitude", latitude)
 .setParameter("longitude", longitude)
 .setMaxResults(nb)
 .getResultList();
 
 return list;
 }

La fonction ST_MAKEPOINT sert, comme son nom l'indique, à créer un point à partir des latitude et longitude fournies en arguments ;
la fonction ST_DISTANCE, quant à elle, récupère la distance entre deux objets géométriques (quels qu'ils soient).

En ordonnant les résultats de la requête en fonction de cette distance, on obtient bien les cabines attendues. En les affichant sur une carte Google Maps (les latitudes et longitudes sont directement récupérées depuis l'objet Point) :

Mais PostGIS ne se limite pas seulement au calcul de distances ! Le nombre de fonctions à disposition est assez impressionnant, et couvre énormément de cas d'usages. Pour s'en rendre compte, il suffit de regarder quelques projets où PostGIS a été mis à l'ouvrage :

La ville de Boston utilise PostGIS pour stocker ses données "ouvertes" et les rendre disponibles à la consultation :

L'IGN, stocke également une partie de son immense base de données sur PostgreSQL/PostGIS, avec des interfaces Web et natives à destination de ses chercheurs :

Mais attention, malgré toutes ses qualités, PostGIS n'est pas bon à utiliser dans tous vos projets géospatiaux : dans la plupart des cas (et souvent pour les plus basiques), passer par une API tierce (Google, Bing, OSM...) apportera une simplicité et un découplage bienvenus.

Futures perspectives

Actuellement, la version stable de PostGIS est la 1.5. La version 2 est sur les rails, et apportera son lot de nouveautés, notamment au niveau de la topologie et du support de la 3D, ainsi qu'un nettoyage de rigueur des fonctions dépréciées.

Pour plus d'informations sur cette seconde version, je vous renvoie vers les présentations suivantes ayant eu lieu lors lors de la dernière session PostgreSQL en Juin dernier :

Web Storage, le stockage de données côté client

Damien Alexandre — 2012-01-17T13:24:31Z

Les applications Web sont de plus en plus complexes, et utilisent de plus en plus Javascript. Un des points faibles du développement de ces applications est le stockage de données sur le poste du client. Ce problème est résolu avec l'API HTML5 Web Storage.


Logo Web Storage

HTML5 change la donne en terme de stockage de données. Alors qu'à une époque, tout ce qui devait être stocké passait par le serveur Web, il est maintenant possible de s'en passer intégralement.

Nous faisons déjà du stockage côté client avec les cookies, mais ils sont limités à 4Ko et ont quelques défauts (sécurité, difficultés à gérer le multi-tab...). Web Storage est bien plus puissant et facile à manipuler.

Les différentes technologies de stockage

Le Web Storage a déjà fait couler beaucoup d'encre et 3 standards sont apparus :

Web Storage qui nous intéresse aujourd'hui, il permet de stocker des chaînes de caractères sous une clé alphanumérique ;
Web SQL Database qui porte une vraie base de donnée relationnelle dans le navigateur (mais qui a été abandonné par le W3C) ;
Indexed Database qui est un peu entre les deux. Il permet aussi le stockage de clé / valeurs mais est indéxé comme une base de donnée et rend donc possible des recherches sur valeur (sans devoir itérer sur tous les enregistrements comme avec Web Storage).

Web Storage est la seule des trois à être déjà disponible relativement partout :

Vous pouvez faire le test sur cette petit démo.

Web Storage, comment ça marche

Le principe est vraiment très simple : c'est un stockage sous la forme clé / valeur. Il y en a deux différents :

stockage uniquement pour la durée de la session (et uniquement pour cette instance du site, un autre onglet sur la même page n'est pas affecté) ;
stockage permanent.

Pour chacun de ces stockages, on a un objet manipulable, respectivement sessionStorage et localStorage. Les deux objets exposent la même API.

C'est tout ce dont vous avez besoin pour utiliser le stockage côté client.

Les navigateurs les plus récents ont déjà ajouté à leurs outils d'inspection de quoi manipuler les données stockées avec Web Storage :


L'inspecteur de Chrome


Firebug dans Firefox

Nous pouvons l'utiliser alors ?

Comme nous avons pu vous le montrer en introduction, certains navigateurs encore très présents (IE7) ne supportent pas localStorage. Heureusement pour nous un plugin jQuery existe ! Il utilise alors Gears, userData (sous IE) ou en dernier recours, les cookies. C'est une solution complète qui doit encore faire ses preuves mais qui pose déjà une bonne base. Comme toute nouvelle technologie, c'est en fonction de vos besoins et de vos visiteurs que le choix doit se faire - si comme Facebook vous décidez de ne plus supporter IE7 [1], ou si vous développez un site mobile uniquement, vous êtes alors prêt à utiliser Web Storage !

Voici quelques raisons justifiant l'utilisation de Web Storage dans le développement d'applications :

permettre à l'application de fonctionner en mode hors-ligne (stocker les données saisies en local et les synchroniser avec le serveur une fois connecté) ;
améliorer les performances (mettre en cache des données) ;
se passer d'un développement serveur ;
stocker par instance et non par domaine (contrairement aux cookies) ;
ne pas transmettre les données sur le réseau (contrairement aux cookies encore une fois) ;
disposer d'un espace de stockage important (5 Mo).

Certains points négatifs sont aussi à prendre en compte :

les données stockées sont vulnérables (visibles et modifiables par le client) ;
elles sont stockées dans un seul navigateur et il n'est donc pas possible d'y accéder depuis un autre ordinateur ou navigateur.

Quoi qu'il en soit, nous avons un nouveau jouet qui marche déjà un peu partout - il est temps de repenser notre approche du stockage côté client en prenant sérieusement en compte cette nouvelle fonctionnalité des navigateurs.

[1] La Timeline de Facebook n'est pas compatible avec le navigateur de Microsoft.