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 :

• Topology with PostGIS 2.0
• Support 3D de PostGIS 2.0

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.

CQRS (Command and Query Responsibility Segregation) est un modèle d'architecture plutôt récent et que l'on croise donc assez rarement dans les phases de conception. Pourtant, ce type d'architecture innovant peut rendre bien des services, surtout si vous pensez déployer votre application sur une infrastructure distribuée.

CQRS, définition

CQRS est un modèle d'architecture système qui sépare la partie lecture de données (query) de celle qui les modifie (command) de manière à produire un système extensible, distribuable, et fournir quelques avancées utiles qui rendent la maintenance du système moins pesante.

Comparaison entre une architecture 3 tiers et une architecture CQRS

Pour mieux comprendre l'organisation d'une application basée sur une architecture CQRS, essayons de monter un rapide comparatif entre une architecture 3 tiers classique et une architecture CQRS.

Du côté de l'architecture 3 tiers, les services qui permettant d'accéder aux données se confondent avec ceux qui vont agir sur ces mêmes données. Que vous vouliez lire ou écrire des données, vous traversez les mêmes couches, utilisant parfois les mêmes composants pour ces différents types d'action.

Avec CQRS c'est différent. On sépare volontairement les composants qui vont permettre de requêter les données de ceux qui vont les modifier. Cette séparation, au delà de faciliter l'organisation de l'application, permet de répartir plus facilement les charges si l'on dispose d'une infrastructure distribuée.

CQRS en détails

Au premier abord, l'architecture peut paraître un peu complexe. Pourtant une fois les concepts de base assimilés, le fonctionnement devient beaucoup plus limpide.

Il serait ambitieux de prétendre couvrir tous les aspects de CQRS en un article tellement ce modèle est riche. Je vais cependant m'attacher à vous présenter les quatre points cruciaux de ce modèle d'architecture.

La couche de lecture des données (Query)

Il s'agit d'une couche qui fonctionne uniquement en lecture seule. Aucune modification n'est apportée aux données. On utilise généralement des objets et tables spécifiques à l'interface utilisateur. Ici un seul objectif : aller le plus vite possible. Les contrôles sont donc réduits au minimum (on ne passe pas par la couche domaine dont on parlera plus tard) et en base de données, les données sont dénormalisées au maximum, quitte à avoir de la redondance. Cette méthode permet de récupérer seulement les données dont on a besoin, sans avoir à parcourir de nombreuses tables au travers desquelles les données seraient éparpillées.

Cette couche est généralement composée de services qui exposent les données et d'interfaces légères qui requêtent les données.

La couche modification des données (Command)

Dans cette couche, on observe davantage d'intermédiaires. Toute modification des données (mise à jour, création, suppression...) passe par cette couche. Ici, chaque action est contextualisée. On ne se contente pas de demander la modification de telle ou telle donnée, la commande porte en elle la notion d'intention : pour quelle raison je souhaite modifier les données. Par exemple, on pourrait avoir une commande ClientDéménage qui impacterait les informations adresse, ville et code postal de l'utilisateur. Dans cet exemple, on sait pourquoi on a modifié ces informations : parce que l'utilisateur a déménagé.

Pour cette partie, on envoie généralement chacune de ces commandes sur un bus, commandes qui seront traitées par des command handlers associées. Ces command handlers vont transmettre les informations de chaque commande au domaine.

Le domaine

Cette zone concentre toute la connaissance métier de l'application. C'est ici que l'on va analyser chaque commande et décider de la suite à donner pour chacune d'entre elles. Ici on trouvera donc les différents objets qui permettront de faire appliquer les règles métiers, de pratiquer les contrôles nécessaires à chaque action etc... Suite à l'analyse de chaque commande, le domaine peut décider de modifier l'état actuel des données. Pour cela, il va générer un ordre de modification : un event.

Les évènements (Events et Event Store)

Ces events sont tous persistés dans ce que l'on appelera l'Event Store que l'on pourrait comparer à un gestionnaire de versions comme SVN par exemple. Chaque event est enregistré et on peut ainsi facilement revenir dans un état antérieur des données ou rejouer par exemple un enchaînement d'events particuliers.

Un système de snapshots permet également de sauvegarder régulièrement l'état du système. On comprend alors facilement l'intérêt d'un tel système en terme d'audit ou de debogage de l'application : on part d'un snapshot sain et on exécute pas à pas chacun des évènements ayant modifié le système jusqu'à trouver l'origine du problème.

A mesure que ces events sont stockés dans l'Event Store, ils sont également publiés sur un bus pour être traités, plus tard, par des Event Handlers. Ce sont eux qui viendront attaquer les données pour répercuter les changements demandés dans chaque event. Ce n'est qu'au terme du traitement de chaque event que les données seront modifiées et persistées.

Avantages et inconvénients

Les avantages

• Architecture adaptée à une infrastructure distribuée
• Chaque action a un impact limité et maîtrisé
• Facilement extensible
• Très pratique pour conserver un historique et ne pas perdre d'informations

Les inconvénients

• Peu utilisé
• Nécessite une plus grande période d'apprentissage
• Peut nécessiter un grand nombre de classes/fichiers, même pour de simples actions

Intégrer CQRS dans votre prochain projet

Bien que récent, ce modèle d'architecture a trouvé de fervents défenseurs qui ont rapidement proposé des frameworks applicatifs pour permettre aux développeurs de toutes technologies d'utiliser CQRS au sein de leurs applications. Voici donc quelques exemples de frameworks pour les environnements les plus connus :

• Axon Framework (Java) : http://code.google.com/p/axonframework/
• NCQRS (.Net) : http://ncqrs.org/
• OxyBase (PHP) : http://code.google.com/p/oxybase/

L'AFUP organisait cette année la première édition du PHP Tour, un nouvel évènement similaire au Forum PHP, et qui aura lieu chaque année dans une ville différente, en province.

L'équipe Lilloise nous accueillait sur le site d'Euratechnologies pour deux jours de conférences bien remplies, orientées sur le e-commerce et les performances, et comportant une part importante de retour d'expériences. Clever Age était évidemment présent sur place - à la fois dans le public, en tant que conférencier et dans l'équipe d'organisation - et nous avons pu assister à de nombreuses sessions, sur des sujets tous très intéressants.

Plutôt que de paraphraser chacune de ces conférences, nous allons juste faire un retour sur celles que nous avons préférées. Pour les autres, vous pourrez toujours allez voir les slides car, pour ce premier opus dans le nord, le programme était alléchant !

Avec une présentation des nouveautés de la prochaine version majeure du langage, PHP5.4, Zend Framework 2, Symfony2, les tests unitaires avec Atoum, la tenue en charge d'un site média ou les tests A/B avec PHP, la présentation de phpcloud.com ou encore le profiling, la sécurité, et nos coups de coeur, présentés ci-dessous !

Plusieurs sessions de conférences étaient proposées simultanément, offrant aux visiteurs un programme riche et varié

L'éditeur en ligne de la documentation PHP

Yannick Torrès présentait l'éditeur en ligne de la documentation PHP, un outil méconnu mais qui permet d'éditer simplement la documentation dans un navigateur. Désormais, sur chaque page de la documentation officielle, un lien d'édition est présent en haut à droite de la page, et permet d'éditer la page anonymement ou en se connectant avec un compte google, facebook ou php.

Plus d'excuse pour ne pas participer, ne serait-ce que pour corriger une coquille. L'effort est considérable, puisque déjà plus de 98% de la version française est à jour par rapport à la documentation originale, en anglais : cela fait de la version française de très loin la traduction la plus aboutie. Merci au traducteurs pour leur travail et pour cet outil, qui va désormais nous permettre de les aider !

Atoum, un framework de tests unitaires simple, intuitif et moderne pour PHP

Frédéric Hardy présentait à l'occasion du PHP Tour un projet sur lequel il travaille depuis pas mal de temps : le framework de tests unitaires Atoum. Conçu pour tirer partie des fonctionnalités de PHP 5.3, l'objectif (avoué ?) d'Atoum est de remiser PHPUnit au placard, en proposant une alternative intuitive. Les exemples fournis par le documentation du projet sont convaincants :

<?php

namespace vendor\project\tests\units;
require_once 'path/to/mageekguy.atoum.phar';
include_once 'path/to/project/classes/helloWorld.php';

use mageekguy\atoum;
use vendor\project;

class helloWorld extends atoum\test
{
public function test__construct()
{
$helloWorld = new project\helloWorld();

$this->assert
->string($helloWorld->say())->isEqualTo('Hello!')
->string($helloWorld->say($name = 'Frédéric Hardy'))->isEqualTo('Hello ' . $name . '!')
;
}
}

Disponible sous la forme d'une simple archive Phar, le projet Atoum est très prometteur... Frédéric a même pu improviser une deuxième session, non prévue initialement, afin de montrer plus de subtilités d'Atoum. Une découverte très enthousiasmante !

Annonce du lancement de PHPCloud

Zeev Suraski, en vidéo conférence depuis Israël, nous a fait en avant-première une démo du tout nouveau PHPCloud proposé par Zend Technologies. Le principe est simple : il s'agit d'héberger des applications PHP dans le cloud de notre choix. Certes, la solution est encore en version beta, mais elle reste très prometteuse. Outre les aspects commerciaux abordés en début de conférence et qui ne passionnent pas les développeurs que nous sommes, PHPCloud s'annonce comme une solution d'hébergement d'applications PHP fiable et crédible. Zeev nous a entre autres montré comment créer un container d'applications, comment déployer en quelques clics une application PHP telle que Magento, Drupal, phpBB ou bien encore Wordpress.

Puisque c'est Zend qui se cache derrière tout ça, ils ont bien pensé les choses et on a vu comment intégrer nos applications PHPCloud dans l'IDE Zend Studio (une vidéo explique le fonctionnement). C'est assez bluffant, et je passe tous les autres “petits trucs” bien pratiques comme le versionning Git, le remote debug dans Zend Studio, les snapshots, Zend Server.

Pour le moment il faut soit être parrainé, soit faire une “invite request” pour tester la bête. Mais cela vaut le détour puisque c'est totalement gratuit - pour l'instant en tout cas ;)

L'avenir du PHP Tour...

Les ÉléPHPants, les mascottes de PHP...

Avec plus de 250 participants et un évènement à guichets fermés, cette première est clairement une réussite. Les rumeurs courent pour une prochaine édition à Lyon ou Nantes, et si il y a une communauté PHP active dans votre ville, il n'est pas trop tard pour déposer un dossier de candidature. L'AFUP a d'ailleurs lancé un appel à candidature il y a quelques jours... D'ici là, on se retrouve début Juin pour le Forum PHP 2012, à Paris ?

.reaction-page #blog .reaction-style dd, #blog-page #blog .reaction-style dd { margin-bottom: 1em; }