Christophe Nowicki

Je reviens des mercredis de la RFID organisé par filrfid, le sujet de la présentation était le protocole ZigBee. Lors de la présentation faite par Véranith Ly de la société oRFIDée, j’ai appris beaucoup de choses sur ce protocole. J’aimerai donc vous en faire profiter et parler des domaines qui m’intéressent à savoir la domotique, la robotique et la topologie des réseaux maillés.

Description rapide du standard

ZigBee, est un standard de communication sans-fils comme le Wifi ou le Bluetooth.
Les principaux avantages du standard sont :

• Autonomie de l’émetteur, il est possible de le faire fonctionner durant plusieurs années à l’aide d’une batterie ;
• La possibilité de mettre en place une topologie de réseaux maillés ;
• 65535 nœuds sont addressable sur le réseau ;
• le standard définie : les méthodes de communication sur le réseau, mais aussi les fonctionnement des applications ;
• l’ensemble des produits sont certifiés par l’Alliance ZigBee et soutenus par de nombreuses entreprises industriels ;

Ce qui est intéressant, c’est que le standard définit un ensemble de caractéristiques pour un équipement.
Regroupé sous forme de famille :

• ZigBee Smart Energy ;
• ZigBee Remote Control ;
• ZigBee Home Automation ;
• ZigBee Health Care, non disponible;
• ZigBee Building Automation, pas encore définie ;
• ZigBee Telecommunication Services, non encore définie.

Domaines d’application du protocole

Les domaines d’applications du protocole sont les suivants :

• la gestion de l’énergie et les réseaux de distribution d’électricité « intelligent » ;
• la médecine, avec le suivi des indicateurs physiologiques sur le long terme pour les maladies chroniques.
• Les réseaux de capteurs en général : WSN ;
• Les télécommandes, le protocole est amené à remplacer les télécommandes infrarouge à moyen terme.
• La domotique, pour le contrôle et la gestion des appareils dans une maison ;
• La localisation en temps réel ;
• Et enfin la robotique, pour le contrôle à distance ;

La promesse du standard

Les équipements qui respectent le standard et sont certifiés par l’Alliance ZigBee sont théoriquement interchangeable et peuvent communiquer ensemble.

Cela signifie, qu’il est possible d’allumer à l’aide d’une télécommande de marque A, une douille d’ampoule de marque B et un lecteur de DVD de marque C.

Cela parait trivial dit comme cela, mais dans l’état actuel de développement de la domotique, cela releve du miracle …

Même, s’il existe des protocoles propriétaires pour faire cela, il est nécessaire de vendre son âme à un constructeur (Vendor lock-in garantie sur facture ;-) ) ou bien mettre en place des protocoles de Middleware comme xPL et une belle galaxie de protocoles hétérogènes. (cf. le schéma de ma petite installation perso ;-) ).

La gestion des binding

La couche applicatif du standard ZigBee, inclut une possibilité très intéressante pour la domotique : le binding.

L’idée est de relier deux équipements du réseau de manière automatique et transparente pour l’utilisateur.

L’un des meilleur exemple pour comprendre est celui d’une ampoule et un d’un interrupteur.

Lorsque l’utilisateur active physiquement le binding, à l’aide d’un bouton par exemple.

Les deux devices se mettent en relation avec le coordinateur du réseau, qui détermine si oui ou non les profils applicatifs sont compatibles et de les lier.

Ce qui permet aux équipements d’être liés automatiquement et il n’est pas nécessaire de configurer les adresses des équipements, etc…

L’état actuel de la certification

Pour l’instant, il y a peu d’équipements qui sont certifiés par l’Alliance :

• ZigBee Smart Energy Certified Products ;
• ZigBee Home Automation Certified Products.

Mais on trouve pas mal de vendeurs d’autres produits que ne sont pas forcement entièrement certifiés mais qui respectent la partie communication du standard.

Problématique du sans-fils

Comme toutes technologies sans-fils, elle présente quelques problématiques particulières :

La source d’énergie

Bien que le module ZigBee nécessite très peu d’énergie pour fonctionner (20mA pour émettre une trame sur le réseau), se pose la question de la source d’énergie.

Lorsque celle-ci est fournie par une pile cela pose de problématique de :

• fiabilité / qualité de la source d’énergie ;
• la nécessité de remplacer régulièrement la source d’énergie ;
• la nécessité de mettre en place un dispositif pour notifier l’utilisateur du statut de la pile.

La sécurité

La sécurité du standard ZigBee repose tout d’abord, sur la sécurité du protocole de communication IEEE 802.15.4. Pour mieux comprendre les méthodes de sécurisation mises en place par le protocole, vous pouvez lire cet article de vulgarisation : Security in 802.15.4 and ZigBee networks ; ou bien cet excellent papier Security Considerations for IEEE 802.15.4 Networks. Mais dans ce domaine, rien de nouveau, ce sont toujours les mêmes principes qui s’appliquent, à savoir :

• Plus la puce dispose de puissance et plus le niveau de chiffrement est fort (au maximum AES128 pour ZigBee) ;
• La qualité des composants et du générateur de nombre aléatoire ( merci de ne pas utiliser le PID du programme ;-) ) ;
• La qualité de l’implémentation du code de chiffrement.

Bref, vous vous doutez bien que les modules ZigBee qui seront vendus au grand publique ne seront pas d’un niveau de sécurité militaire et n’embarqueront sûrement pas pas un compteur Geiger comme source d’entropie ;-)

D’autant plus que le standard n’impose pas forcement un niveau de chiffrement fort à tous les profils applicatifs.

Robotique

Pour la robotique, il n’existe pas de profil dans le standard, mais la plupart des amateurs dans le domaine ont déjà compris les nombreux intérêts de ZigBee et on voit de plus en plus d’interfaces apparaître (Bioloid, WowWee, etc… )

Logiciels libres

Du coté des logiciels libres, nous avons :

• Un projet mort : ZigBuzz ;
• Le projet IEEE802.15.4/ZigBee Stack for Linux, dont l’objectif est l’intégration de la pile ZigBee dans le noyau Linux, commiter dans la version 2.6.30-rc7 ;
• Le projet FreakZ, dont l’objectif est l’implémentation du pile ZigBee libre pour l’embarque ;

Malheureusement, il y a une incompatibilité entre la licence des spécifications du standard ZigBee et la licence GPL. en effet celle-ci ne prend pas en compte un usage non commercial.

Pour plus de détails sur ce point : Zigbee, Linux, and the GPL.

Néanmoins, le code du protocole IEEE 802.15.4 est déjà le noyau et bénéficie d’un niveau de protection ;-)

Matériel

Le matériel ZigBee disponible se découpe en plusieurs familles de la plus simple à la plus complexe :

Émetteur-récepteur

Les principaux constructeurs d’émetteur-récepteur sont Texas instruments et Freescale.

Puce

Les puces prennent en charge la norme IEEE 802.15.4, elles sont produites par : Ember, Jennic, Texas instruments et Freescale.

Modules

Les modules prennent en charge le standard ZigBee et sont produites par : Digi, One-RF, Telegesis, Meshnetrics, Radiocrafts…

Produit fini

• Tritech : dongles USB et routeurs Ethernet/Zigbee ;
• Digi : passerelles RS232/485, USB, Ethernet, GPIO, routeurs autonomes
• Telegesis : dongles USB et CF, routeurs autonomes et Ethernet
• Alektrona : gateway ethernet / zigbee;
• Libelium : capteurs et routeurs multi-protocoles Wifi, Bluetooth, GPRS et GPS ;
• Des shields pour la carte Arduino et ses dérivées.

Offre packagée

Pour les produits packagés, il existe les solutions suivantes :

• Control4 : gamme de produits domotiques ;
• AlerteMe : système de suivi de la consommation électrique et alarme.

Déploiements importants de ces technologies

Il y a pas mal de déploiements de ces technologies aux USA dans le cadre des réseau de distribution d’électricité « intelligent » en Californie et au Texas principalement.

En Europe, le ville de Gothenburg en Suède a déployé un réseau de 90 000 compteurs intelligents.

En France, le déploiement est encore à l’état de recherche avec le projet SensLab, le projet de localisation fait par Orfidée pour la Marine Nationale.

Et d’autres projets couverts par des accords de non divulgation ;-)

Références

Voici quelques références pour approfondir le sujet :

• Le site de la ZigBee Alliance ;
• le site sensor-networks ;
• l’article de Sensor-networks sur les différence entre 802.15.4 vs ZigBee ;
• le site du projet IEEE802.15.4/ZigBee Stack for Linux ;

Conclusion

Voilà, ceci est une petite présentation standard ZigBee, que j’ai voulu la plus succincte possible. Le sujet étant très vaste et passionnant. J’ai forcement fait des erreurs et oublié des références. Merci de m’en faire part par mail ou via les commentaires.

Je viens de finir une analyse de code pour un client. J’aime beaucoup ce type de missions, car elles permettent de remettre en perspective mon travail et de mieux analyser les différentes implications de l’organisation sur le développement.

J’essaye dans ce type de mission d’identifier quels sont les points d’organisation qui transparaissent dans l’analyse de code.

Dans plusieurs cas, j’ai pu retrouver des similitudes. Ces similitudes peuvent être regroupées sous le terme de “dette technique”.

Dans cette article, je vais essayer de définir le concept, vous présenter les symptômes, les origines, les conséquences et les solutions envisageables.

Définition de la dette technique

Lorsque vous ajoutez une fonctionnalité à un logiciel, vous avez deux
possiblités :

• Faire le plus rapide possible, c’est à dire en utilisant la
  technique la plus facile, la plus rapide et négliger la conception
• Prendre le temps de réaliser proprement la fonctionnalité, créer une architecture, spécifier les besoin fonctionnels, techniques, faire des tests, etc.

On peut établir une métaphore financière avec la mise en place d’une solution à court terme telle qu’évoquée dans le premier cas de figure en parlant de dette technique.

Vous empruntez du temps sur l’avenir. Comme dans le cas d’un crédit. Mais le coût de cet emprunt n’est pas nul.
Plus vous développez rapidement et mal et plus la dette grandit, les intérêts se cumulent.
Et le projet peut faire faillite sous le coût de la dette.

Symptômes

Voici des exemples de situations réellement vécues au sein d’entreprises :

• Absence de documentation sur la structure du projet : où se trouve le code source? dans quel répertoire se trouve la documentation du projet, où sont les fichiers CSS, etc.
• Aucun test unitaire ou fonctionnel ;
• “Lorsque je change une ligne dans le module A, cela casse le fonctionnement du module B”
• “Ne touche pas à cette partie du code, nous ne savons pas ce qu’elle fait exactement, mais dieu merci cela fonctionne encore” ;
• Nous venons de perdre un disque dur sur le serveur de production, où sont les sauvegardes?
• J’ai l’impression d’avoir déjà corrigé ce bug plusieurs fois, étrange….
• Code sans aucun commentaire ou avec des commentaire trop anciens ;
• La connaissance du projet dépend d’une seule personne ;
• Je vais mettre un commentaire TODO ou FIXME et je corrigerai le problème plus tard ;
• Nous ne pouvons pas mettre à jour les composants du serveur, cela va casser le code ;
• Nous n’avons pas le temps de faire cela, ce n’est pas une urgence vitale ;
• Nous ne pouvons pas mettre à jour le code, personne ne comprend cette partie du code …
• La personne responsable du module est partie en vacances …

Vous avez aussi entendu ou vécu ce genre de situation ?
Alors appelez le 81212 et dites ‘Thermomètre’ ;-)

Les origines

Qui est responsable de ces problèmes. La réponse est assez simple, car chaque intervenant du projet est responsable :

• le chef de projet qui néglige la conception, planifie mal
  l’exécution des tâches ou ne transmet par correctement les demandes des clients ;
• le client qui s’introduit dans la conception technique du
  logiciel et qui impose brutalement son point de vue ;
• le développeur qui ne sait pas dire “non”, qui surestime ses
  capacité ou bien qui ne joue pas collectivement dans une équipe ;
• les utilisateurs avides de fonctionnalités et volatiles dans leur
  demandes ;

Les conséquences

Les conséquences de la dette technique sont les suivantes :

• Augmentation du temps de développement ;
• Impossibilité de prévoir et d’anticiper les coûts d’entretien ;
• Difficulté pour faire rentrer un nouveau développeur dans l’équipe ;
• Faillite

Solutions

Technique

La solution technique miracle permettant de vous sortir du bourbier n’existe pas.

Ceux qui vous disent qu’il suffit de refaire le logiciel avec une autre
technologie / technique ont sûrement quelque chose à vous vendre ;-)

Infrastructure

Il faut absolument mettre en place une infrastructure pour chaque
développement quelle que soit la taille du projet.

• Un logiciel de suivi de bugs : comme Request Tracker, Trac, Mantis, etc…
• Un système de suivi de version tel que Subversion, Git ou Mercurial ;
• Un système de sauvegarde ;
• L’automatisation des tâches à l’aide d’un système de compilation automatique ;
• Des tests unitaires et fonctionnels automatisés ;

Refactorisation

La refactorisation est une forme de paiement des intérêts de la dette.
En effet, elle permet de faire une pause dans le développement et de “nettoyer” le code.

Méthodes de développements

Je ne vais pas lancer une querelle de clocher, je ne vais pas non plus vous dire que telle ou telle méthode de développement est la meilleure.

Il existe un bon nombre de méthodes de développement.

Chaque méthode présente ses avantages et ses inconvénients.

Par contre, une chose est sûre, les équipes de développement qui appliquent une méthode de développement rencontrent moins souvent ce type de problème.

Un peu de provocation

Je ne résiste pas ;-)
Est-ce que la dette technique est mauvaise dans tous les cas ?
Comme dans le cas d’une patate chaude cela dépend de qui paiera les intérêts.
Il est possible de faire un prêt ninja avec les intérêts de la dette.

Cela fonctionne dans le cas d’un marché ou “the-winner-takes-all”.
Par exemple, dans le cas d’une start-up innovante dont le seul but est de revendre le logiciel.

La dette technique permet de partir plus vite au soleil ;-)

Références

• La conférence d’Andy Lester au YAPC::NA 2006 : Get out of Technical Debt Now! ;
• Un commentaire sur LinuxFR d’un ancien développeur du site voyages-sncf.com ;

Le monde du web et celui de l’impression, ont décidément du mal à se rencontrer.
La prise en charge de l’impression est bien souvent très problématique dans le cas d’un projet web.

Dans la plupart des cas, il est possible de s’en sortir en utilisant les possiblités offertes par les feuilles de style CSS.
Mais le rendu final du document n’est pas garanti, les différents navigateurs interprètent la feuille de style selon leur humeur
et cela ne fonctionne pas dans le cas de documents complexes.

Dans ce cas, l’unique solution est de produire un document au format PDF, unique garantie pour une impression de qualité.
Je vais donc décrire dans cet article, la solution que nous avons mis en place dans le cadre du projet MAVISE.

Historique

La base de données MAVISE fourni les données sur l’ensemble des chaînes de télévision accessibles dans l’Union européenne.

Elle a été développé par la société Easter-eggs en collaboration avec l’Observatoire européen de l’audiovisuel (OEA) pour le compte de la DG Communication de la Commission Européenne.

Dans la 1ère phase du projet nous avons développé un système d’impression avec des feuilles de style.
Ce système ne donnait pas entièrement satisfaction au client.

En effet, les pages du projet étant très complexes, le résultat de l’impression produite par les différents navigateurs était très aléatoire (coupure en plein milieu d’un tableau, impression sur plusieurs pages et saut de pages inexpliqués).

Le résultat n’était pas professionnel et il était difficile pour le client d’alimenter un rapport avec les contenu de la base.
Nous avons donc proposé de mettre en place un export PDF pour l’ensemble des éléments de l’application.

Choix techniques

Au fils du temps, je suis devenu un expert de la production de document PDF,
en effet, j’ai été en charge de l’export PDF dans de nombreux projets.

J’ai eu le plaisir d’utiliser plusieurs API pour produire des documents au format PDF, comme par exemple :

• ReportLab en Python ;
• FPDF en PHP ;
• PDF::API2 en Perl.

Le travail pour produire des documents PDF consiste dans la plupart des cas à dessiner avec l’aide de ces diffèrentes
API, le contenu du document. (texte, tableaux, graphique et mise en page).

Il s’agit d’un travail long et fastidieux, qui consiste à fournir une suite d’instructions pour former le document.
Cette technique montre vite ses limites :

• les demandes de modification de la mise en page du document produit, sont lourdes et nécessitent beaucoup de temps ;
• le code pour produire le document est difficilement rationalisable ;
• elle ne convient pas à des documents de grande taille.

Dans le modèle MVC, qu’utilise la plupart des applications Web, nous utilisons un système de template pour l’affichage (la vue).

Alors pourquoi bon “coder” la présentation des documents PDF?

Pour cette raison, j’ai proposé au client de bâtir le système d’impression des documents PDF sur un système de template.

Ce système repose sur le langage de programmation XSL-FO, les projets Apache FOP et Apache Cocoon.

Architecture du système d’impression

1. Lorsque l’utilisateur clique sur le lien PDF, il est redirigé vers Apache Cocoon ;
2. Cocoon, récupère l’ensemble des informations directement sur le site web, via l’API REST ;
3. Il agrége les informations dans un document XML ;
4. Ce document est transformé en FO à l’aide d’une feuille de style XSLT ;
5. Le document est produit par Apache FOP ;
6. L’utilisateur obtient le document final.

L’interface entre le Site Web et Apache Cocoon

L’architecture du système d’impression repose sur le fait que l’ensemble des variables manipulées par notre application sont accessibles à l’aide d’URL REST.

En effet, il est possible d’afficher le contenu des diffèrentes variables manipulées par l’application à l’aide d’adresses URL spécifiques.
Voici un exemple de sortie :

<?xml version="1.0" encoding="UTF-8"?>
<array>
<is_admin />
<country>
<id>1</id>
<iso3166>FR</iso3166>
<name>France</name>
<enabled>t</enabled>
<minimal_age_of_audience>4+</minimal_age_of_audience>
</country></array>
...


Il est donc possible de récupèrer l’ensemble des informations du site à l’aide du protocol REST.

Nous avons aussi de très nombreux tableaux dans l’application, pour les récupérer, nous utilisons le format XML natif du contrôleur de tableaux dhtmlxGrid.
Voici un exemple de sortie : fichier XML pour dhtmlxGrid.

Agrégation des données dans un seul fichier

Pour récupérer l’ensemble des données du site dans un fichier XML, j’utilise la directive include, offerte par Cocoon :

$ cat /var/lib/tomcat5/webapps/cocoon/mavise/program/program.xml
<?xml version="1.0"?>

<page name='program' xmlns:i="http://apache.org/cocoon/include/1.0">
<i:include src='cocoon:/webui_program'/>
...


Cette directive dit à Cocoon, d’inclure le contenu qui se trouve à l’url cocoon:/webui_program, défini dans le fichier
sitemap.xmap :

<!-- Webui -->
<map:match pattern="webui_*/*">
<map:generate src='http://localhost/{1}?id={2}&presenter=rest&filter=webui'/>
<map:serialize type="exml"/>
</map:match>


Transformation XSLT

Pour transformer les données contenues dans ce fichier, nous avons créé notre propre feuille de style XSLT, pour produire un document FO.
Cette feuille de style prend en compte la mise en forme des diffèrentes données du site.

Grâce à ce système, l’ensemble de la mise en forme est centralisé dans un seul fichier.
Il est aussi possible d’ajouter du contenu statique dans le PDF à l’aide de balises dédiées.
Comme par exemple, une balise copyright, qui sera transformées en un texte statique dans tous les documents PDF.

Le pipeline pour les documents PDF

Voici le pipeline final pour produire des documents PDF :

<!-- PDF -->
<map:match pattern="*/*/*.pdf">
<map:generate src='{1}/{3}.xml'/>
<map:transform src="mk_id.xsl" type="xslt">
<map:parameter name="val" value="{2}" />
</map:transform>
<map:transform type="include">
<map:parameter name="parallel" value="true"/>
<map:parameter name="support-caching" value="true"/>
<map:parameter name="expires" value="600"/>
</map:transform>


Le point intéressant à noter dans ce pipeline est l’encodage des arguments passés via l’URL pour le document PDF.
En effet, les URL pour produire les PDF sont formés de la manière suivante :

http://mavise.obs.coe.int/cocoon/mavise/channel/2157/channel.pdf

L’URL contient, le nom du module et l’identifiant de la chaîne.
De cette manière, il est possible de passer d’autres arguments au système d’impression (comme par exemple, changer l’orientation du document).

Performances

Au niveau des performances du système d’impression, nous n’avons pas une charge très importante sur la génération des documents PDF.
La production des documents est une tâche complexe et nécessite donc de manière génèrale beaucoup de ressources.
Néanmoins, il y a une chose intéressante à noter au niveau de la génération des documents PDF.
Celle-ci est plus rapide que l’affichage dans un navigateur.
En effet cela est lié au fait que les échanges de données se font en local sur le serveur, il y a donc moins de bande passante utilisée que dans le cas de l’affichage de cette même page par le navigateur.

Les petits désagréments du format PDF

Nous avons rencontré un petit problème, avec la gestion des polices UTF-8, en effet, comme la base contient des données sur des chaînes de télévision et des entreprises Turques, nous avons eu besoin d’embarquer une police UTF-8 à l’intérieur du document.
Et visiblement cela pose des problèmes à certains lecteurs.

Quelques liens utiles

Voici quelques liens utiles qui nous ont aidé dans la réalisation de ce système d’impression :

• Le guide d’installation d’Apache Cocoon, FOP sur Debian GNU/Linux ;
• Documentation de la version 2.1 d’Apache Cocoon ;
• XPath Tutorial ;
• XSLT Tutorial ;
• XSL-FO ;

Conclusion

En conclusion, j’aimerais remercié l’Observatoire européen de l’audiovisuel (OEA), pour nous avoir fait confiance pour la mise en place de cette solution.
Au 1er abord, le schéma de l’architecture n’est pas très engageant ;-)

J’espère que cette solution donnera des idées à d’autres personnes, pour leur système d’impression.
L’objectif final est de faire des économies de papier par rapport à une impression faite via Internet Explorer ;-)

La base de données MAVISE fournir les données de base sur l’ensemble des chaînes de télévision accessibles dans l’Union européenne.
Elle à été développer par la société Easter-eggs pour le compte de la DG Communication de la Commission européenne.
Je vais décrire dans cet article les diffèrentes méthodes que nous avons mise en place pour optimiser les performances de cette application.

Problèmatique

La base de données contiens beaucoups d’informations :

• la description du paysage audiovisuele de 30 pays ;
• des fiches sur 5000 chaînes de télévision ;
• des fiches sur 4000 entreprises ;
• des fiches sur 8000 programmes de télévision ;

L’ensemble des ses données ne sont pas accessibles au grand publique.

D’un point de vu technique, la base de données PostgreSQL contient :

• 115 tables ;
• 100 vues ;
• 220Mo de données.

Cela vous donne une petite idées de la taille de l’application.
La complexitées de l’application, la quantité de données disponibles et leur affichage nous as posées de nombreux problèmes :

• Quantité de données très importante à transferer entre le client et le serveur Web ;
• Requêtes complexes au niveau de la base de données ;

Optimisation de la base de données

Pour l’optimisation de la base de données, il faut faire attention aux points suivants :

1. L’ORM (DB_DataObject dans notre cas) ne doit faire aucune opération de jointure . Il utilise toujours une vue dédier pour chaque fonctionnalitées ;
2. Chaque vue ne calcule que les champs qui sont nécessaire à l’affichage ;
3. Le plan d’execution de chaque vue est optimiser à l’aide d’index. Pour trouver quels sont les indexes à créer, il faut utiliser l’instruction EXPLAIN ANALYSE , comme décrit sur le wiki de Postgres : Using EXPLAIN.

Le travail principal consiste donc à éxécuter toutes les vues de l’application pour optimiser les plans d’éxécution à l’aide d’indexes.
Pour mieux comprendre la sortie de l’instruction EXPLAIN ANALYSE, j’utilise l’outil suivant : explain-analyze.info.

Pour savoir quelles sont les optimisations les plus pertinantes, il est intéressant d’analyser les logs du serveur Postgres à l’aide du logiciel Practical Query Analysis.

Il faut aussi “tuner” la configuration du serveur de base de données pour utiliser le maximum de la mémoire disponible sur le serveur.

Javascript

Nous avons utilisé le framework Javascript Mootools, le contrôleur de tableau dhtmlxGrid et l’éditeur de contenu TinyMCE.

Dans chaque page de l’application, il faut faire attention à ne charger que les fichiers nécessaire.
En effet, ces outils, bien que très pratiques sont très volumineux et augementent la taille des pages dans des proportions importantes.

Dans certains cas, nous avons dépasser plus de 640Ko de code Javascript dans une page ;-)

Les solutions que nous avons mis en place pour réduire la taille de ces fichiers :

• La compression Gzip, malheureusement nous avons rencontrer de problèmes très importants avec Internet Explorer ;
• Nous avons ensuite opter pour YUI Compressor qui fonctionne bien mieux ;

Systèmes de Cache

L’application dispose de nombreux systèmes de caches :

• Le système de cache du gestionaire de template Smarty ;
• Notre propre système de cache pour le contenu des tableaux, réalisé à l’aide du module Pear Cache_Lite ;
• L’API de XCache, pour certains calculs et XCache pour les opcodes PHP ;
• Le système de cache d’Apache Cocoon pour le système d’impression ;
• La cache du navigateur des utilisateurs. Il est possible de bien contrôler le contenu du navigateur des clients à l’aide du module mod_expires d’Apache.

Réduction de la taille des pages

Nous avons travailler pour réduire au maximum la taille des échanges entre le navigateur web et le serveur.
Pour cela nous avons utilisé la compression Gzip sur :

• Le contenu des tableaux ;
• Les pages produites par le système de tempate ;

Celle-ci est réalisé par le gestionnaire de tempon de PHP, à l’aide de la fonction ob_gzhandler ;

Outils utilisés

L’optimisation d’une application est toujours empirique, il est nécessaire d’avoir de bon outils pour observer les effets des modifications.
Pour cela nous avons utilisé :

• Le module Firebug pour Firefox ;
• Et son add-ons YSlow.

Les liens utiles pour l’optimisation des performances d’une application Web

Pour finir, voici quelques liens très interessants sur l’optimisation d’une application Web :

• Le blog Performance web ;
• Sermon de l’équipe de Yahoo : Exceptional Performance

Je vais essayer de décrire l’architecture que j’ai mis en place chez moi et que j’utilise tous les jours pour ma gestion des contacts personnels et professionnels.

Problèmatique

Ma problèmatique est extrêment simple et beaucoup de gens doivent avoir la même :
J’ai beaucoup de contacts dans mon carnets d’adresses, je me déplace et j’utilise plusieurs outils.

Je suis tête en l’air et j’ai tendance à oublier les coordonnées d’une personne ;-)

Ma solution

Elle repose sur les composants suivants :

• L’annuaire LDAP : OpenLDAP
• La suite de logiciel de communication pour KDE : Kontact
• Le logiciel de synchronisation : OpenSync et le protocole SyncML
• Le webmail : Horde

Stockage des contacts

Je sais qu’utiliser un annuaire LDAP pour la gestion des contacts donne l’impression d’utiliser un Bazouka pour tuer une mouche.
Mais la technologie LDAP permet de stocker les informations sans être dépendant d’une solution ou d’un système de stockage spécifique.

En effet, de nombreux logiciels sont compatibles avec le protocole LDAP et permettent donc d’accèder à vos contacts.

J’ai donc installé OpenLDAP sur mon réseau.

Les schèmas LDAP inetorgperson et core et une ou=contacts sur laquel vous avez tous les droits sont nécessaires.

Gestion des contacts

Pour la gestion des contacts, j’utilise le carnet d’adresse de Kontact.
En effet, celui-ci permet de saisir les informations directement dans l’Annuaire grâce au système de resource de KDE.
Kontact propose une gestion offline des contacts, permettant de consulter ses contacts sans accès réseau, mais pas de les modifier.

Le schèma LDAP inetorgperson et core ne prend pas en charge tous les attributs de Kontact.
Mais l’essentiel des informations sont disponibles.

L’avantage de stocker les données dans une resource KDE est que l’ensemble des logiciels KDE peuvent utiliser ces données :

• Kmail peut completer les adresses e-mails issues de l’annuaire ;
• Twinkle permet d’appeler les numèros de téléphone ;
• KMobileTools permet d’envoyer des SMS ;

Synchonisation des contacts avec le téléphone portable

Pour la synchronisation des contacts avec mon téléphone portable, un Nokia N95, j’utilise le logiciel MultiSync.
Celui-ci permet de synchroniser les contacts issus du carnet d’adresse KDE vers le téléphone à l’aide du protocole SyncML et à l’aide d’un dongle Bluetooth.

La configuration est la mise en place de ce système est décrite dans ce Thread du forum Ubuntu :
HOWTO: Sync Evolution with Nokia N95 via Bluetooth on Ubuntu Gutsy.
Le plus simple est de configurer le conduit à l’aide de l’interface graphique de kitchensync.

Webmail

Pour mon Webmail, j’ai installé le gestionnaire de contacts sur projet Horde : Trean.
Celui-ci dispose d’un support LDAP assez complet : LDAP Based Address Book

Intégration avec le système de téléphonie

L’intégration avec ma PABX IP se fait à l’aide du module Asterisk
LDAPget, qui permet de recherche le numèro de téléphone de l’appellant dans l’Annuaire.

J’ai aussi essayé d’alimenter le contenu du carnet d’adresse de mon téléphone DECT à l’aide du contenu de l’annuaire LDAP.
Mon téléphone, le Siemens Gigaset SL560, qui dispose du support Bluetooth.
Mais malheureusement, le protocole utilisé entre le téléphone et le PC n’est pas standard.
Il faut donc passer par un logiciel propriétaire sous Windows, pour synchroniser ses contacts ;-(

Problèmatiques et idées d’évolutions

Mon système est fonctionnel, même si c’est parfois artisanal et que certaines problèmatiques sont encore posées :

• certains logiciels sont encore en phase de développement et donc pas toujours très stables ;
• entre l’annuaire LDAP et les diffèrents composants, il y a toujours une perte d’informations, toutes les informations ne sont pas toujours disponibles ;
• Les composants de l’architecture ne disposent pas tous de fonctions de filtrages nécessaire.

Le principal problème avec la gestion des contacts est leur mise à jours.
En effet, il faut mettre soit même les informations à jours ;-)

C’est pour cette raison que je pense qu’une évolution intéressante de mon architecture,
serait la mise à jours des informations par les contacts eux mêmes.

Via une simple page web ou bien par la récupèration des informations sur les nombreux réseaux sociaux.

Malgré tout le mal qu’il est possible de penser ou de dire sur le format de fichier CSV, celui-ci présente beaucoup d’avantages :

• il est facilement manipulable pour les utilisateurs à l’aide d’un tableur comme Calc, Gnumeric ou bien Excel ;
• il permet d’écrire rapidement et facilement des routines d’import / export ;
• il permet d’échanger les données entre des bases et des systèmes hétérogène.

Mais ce format de fichier ne dispose pas d’un système de validation. Dans la plupart des cas ce sont les routines d’import / export qui prennent en charge la validation des données et de leur mise en forme.

Ce travail est pénible, répetitif et ennuyeux mais nécessaire si vous ne voulez pas qu’un fichier mal formaté ne corrompe les données de votre base.

L’objectif de cette article est de proposer une solution simple permettant la validation d’un fichier CSV en utilisant les fonctionnalités offertes par les schémas XML.

Les exemples fournis sont écrit à l’aide du language de programmation PHP5.

Transformation CSV vers XML

Votre fichier doit contenir sur la 1ère ligne, le nom de chaque cologne :

“CHANNEL”;”COMPANY”;”BVD_ID_Groupe_1″;”BVD_ID_Groupe_2″;”GENRE”;”URL”;”OTHER_URL”;”COMPETENT_AUTHORITY”
“Canal+ Film 1″;”C MORE ENTERTAINMENT AB”;”NL33268595″;”DE8330261794″;”CIN”;”http://www.canalplus.se”;”http://www.sbsbroadcasting.com/, http://www.prosiebensat1.de/”;”RTVV”
“Canal+ Film 2″;”C MORE ENTERTAINMENT AB”;”NL33268595″;”DE8330261794″;”CIN”;”http://www.canalplus.se”;”http://www.sbsbroadcasting.com/, http://www.prosiebensat1.de/”;”RTVV”
“Canal+ Film 2 Sport Weekend”;”C MORE ENTERTAINMENT AB”;”NL33268595″;”DE8330261794″;”CIN”;”http://www.canalplus.se”;”http://www.sbsbroadcasting.com/, http://www.prosiebensat1.de/”;”RTVV”
“Canal+ Film 3″;”C MORE ENTERTAINMENT AB”;”NL33268595″;”DE8330261794″;”CIN”;”http://www.canalplus.se”;”http://www.sbsbroadcasting.com/, http://www.prosiebensat1.de/”;”RTVV”
“Canal+ Film HD”;”C MORE ENTERTAINMENT AB”;”NL33268595″;”DE8330261794″;”CIN”;”http://www.canalplus.se”;”http://www.sbsbroadcasting.com/, http://www.prosiebensat1.de/”;”RTVV”

Pour transformer le fichier CSV en XML, il suffit de lire le fichier CSV avec la fonction fgetcsv et mettre les données dans des balisent XML : csv_to_xml.php

Une fichier CSV converti en XML ressemble à cela : channel.xml

Validation du fichier XML

Il ne reste plus qu’à écrire le schéma permettant de valider le fichier XML : channel.xsd

Vous pouvez tester vos schéma en ligne de commande en utilisant la commande xmllint issue du paquet Debian libxml2-utils :


$ xmllint --noout --schema channel.xsd channel.xml
channel.xml validates


Validation en PHP

Une fois que votre schéma est correct et permet de valider le contenu du fichier XML, il faut l’intégrer directement dans votre application : validate.php

Conculsion

Cette méthode apporte les avantages suivants :

• Les règles de validation sont décrites directement via le schéma, et celui-ci dispose de nombreuses fonctionnalités tels les types de bases, les expression rationnelle, les séquences, etc…
• Les messages d’erreur sont compréhensibles pour l’utilisateur même, s’il faut parfois les traduire (en convertissant les numéros de lignes et certaines notions) ;
• La simplicité ;0)

Cette technique a été mise en oeuvre dans le cadre du projet MAVISE pour valider plus d’une vingtaine de formats de fichiers différents.

Il existe des outils tel que SQLSync permettant de synchroniser les données d’une base PostgreSQL. Mais cette outil, ne permet pas de faire une copie partiel des données.
Dans la plus part des cas, il faut programmer la synchronisation soit même, l’objectif de mon article est de vous proposer une solution simple et élégante.

La problèmatique

Des données sensibles se trouvent dans la base principale et il ne faut synchoniser qu’une partie de ces données vers les autres bases. L’architecture dispose des caractèristiques suivantes : Le schèma est identique sur chaque base ; Les opèrations d’écriture se font seulement sur la base principale ; Les bases sont accessibles en réseau.

La solution

Pour résoudre le problème, j’ai testé plusieurs approches avant de retenir l’utilisation d’un fonction de hachage dont voici le principe :

• chaque table doit disposer d’un identifiant unique. (champ id de type SERIAL) ;
• un programme récupère le couple id et la sum de hachage pour chaque table de chaque base qui doit être synchroniseés ;
• il compare le couple et si celui-ci est diffèrent alors les données sont mise à jour.

Implementation au niveau de la base de données

Le calcul de la somme de hachage se fait un niveau de la base de données à l’aide d’un fonction :

SELECT id,md5 FROM get_table_md5('nom_de_la_table');
 id |               md5
----+----------------------------------
  4 | 9f3bcd2fae528244669613ae0466cc3c
  5 | 1f3bcd2fa24528244669613ae66cc3czd
...
(42 row)

Voici le code de la function PL/Perl:

CREATE LANGUAGE plperl;
CREATE TYPE table_md5 AS (id INTEGER, md5 TEXT);
CREATE OR REPLACE FUNCTION get_table_md5(varchar) RETURNS SETOF table_md5 AS $$
    my ($rv, $status, $nrows, $row);
    # Get Table OID
    $rv = spi_exec_query("SELECT c.oid AS oid FROM pg_catalog.pg_class c
        LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
        WHERE c.relname LIKE '$_[0]';");
    $status = $rv->{status};
    $nrows = $rv->{processed};
    return undef if ($nrows != 1);
    my $oid = $rv->{rows}[0]->{oid};
    # Get Table attributs
    $rv = spi_exec_query("SELECT attname,atttypid FROM pg_catalog.pg_attribute a
        WHERE a.attrelid = $oid AND a.attnum > 0 AND NOT a.attisdropped");
    $status = $rv->{status};
    $nrows = $rv->{processed};
    return undef if ($nrows < 1);
    my $atts;
    my $atts_not_null;
    foreach my $rn (0 .. $nrows - 1) {
        if ($rv->{rows}[$rn]->{atttypid} == 16) {
            $atts .= " (CASE WHEN $rv->{rows}[$rn]->{attname} THEN 't' ELSE 'f' END) AS $rv->{rows}[$rn]->{attname}";
        } else { 
            $atts .= " $rv->{rows}[$rn]->{attname}::text";
        }
        $atts_not_null .= " (CASE WHEN $rv->{rows}[$rn]->{attname} IS NULL THEN '' ELSE $rv->{rows}[$rn]->{attname} END)";
        $atts .= ',' if ($rn != $nrows - 1);
        $atts_not_null .= ' || ' if ($rn != $nrows - 1);
    }
    # Calc MD5
    my $sql = "SELECT id, MD5($atts_not_null) AS md5 FROM (SELECT $atts FROM $_[0]) AS $_[0];";
    $rv = spi_exec_query($sql);
    $nrows = $rv->{processed};
    foreach my $rn (0 .. $nrows - 1) {
        return_next({
            id  => $rv->{rows}[$rn]->{id},
            md5 => $rv->{rows}[$rn]->{md5}
        });
    }
    return undef;
$$ LANGUAGE plperl;

Pour utiliser cette fonction vous avez besoin du support du language de programmation PL/Perl dans Postgres, celui-ci se trouve dans le paquet Debian : postgresql-plperl-

La gestion des conditions

Le choix des données à synchroniser se fait individuellement pour chaque table à l’aide de la clause WHERE de la manère suivante :

SELECT id,md5 FROM get_table_md5('nom_de_la_table') WHERE id IN(SELECT id FROM nom_de_la_table WHERE nom_de_la_table.champ LIKE 'sync');
 id |               md5
----+----------------------------------
  1 | fdd56eabd4bb997e453e33f0022d46c1
(1 row)

Implementation du script de synchronisation

La synchronisation des données peut être réalisée à l’aide de n’importe quel language de programmation,
il suffit juste de disposer d’un accèss à la base de données.

Voici un exemple de script écrit par Emmanuel Saracco en PHP5 qui se repose sur les modules PEAR suivants :

• DB : pour l’accès à la base de donnée.
• Console_Getopt : pour la gestion de la ligne de commande.

Ce script nécessite un fichier de configuration, en voici un exemple.
Ce fichier contiens la configuration des diffèrentes base de données et les conditions sous-forme de clauses where.

Conclusion

Cette méthode de synchronisation fonctionne, elle est en production chez un client pour une base de données de plus de 100 tables, elle permet de synchronisé le contenu d’une base vers deux autres.
Les avantages de cette méthode sont les suivants :

• le fait de pouvoir choisir le contenu de la clause where permet de réalisé des régles de synchronisation très complexes ;
• les performances sont très bonnes car les transfert réseau sont limités ;
• il est possible d’écrire le script de synchronisation avec n’importe quel language de programmation.

Au cours de l’année dernière, j’ai mis en place un système de vidéo-surveillance à mon domicile, ce système se base sur un serveur sous Debian GNU/Linux et le logiciel libre Zone Minder. Au cours de cette mise en place, j’ai acquis une expèrience sur les technologies de vidéo surveillance. Suite à de nombreuses demandes de collèges et amis, je tiens à partager cette expèrience : Mise en place d’un système de vidéo surveillance avec ZoneMinder

Tous les documents disponibles dans la partie publication de mon site web, sont écrit à l’aide du langage DocBook,
cette méthode permet de séparer fond du document de sa mise en forme et ainsi publier le document dans plusieurs formats (HTML, PDF, Texte, etc…).

Cette possibilité forte intéressante, est devenus au fils du temps un handicape.

Car la moindre modification d’un document nécessite la régénération des différents formats d’export.

J’ai donc cherché à simplifié et automatisé la procedure de publication. La résultat de ce travail est décrit dans ce document :

Mise en place d’un système de publication de contenu basé sur le projet Apache Cocoon et le langage de balises DocBook

For Work related reasons, I’ve added transaction authentication support for MyDNS version 1.1.0 in tree days for one of our clients.
I’ve used the source code of ISC Bind, OpenSSL and RFC 2847 to write my patch.

MyDNS

MyDNS is a free (as freedom) DNS server for UNIX systems. It is designed to serve DNS records directly from an SQL database (MySQL or PostgreSQL are supported).
It’s a very useful software, used by many dynamic DNS providers.
I’ve used it at work for many projects, because is very easy to manage DNS records with it. But this time we needed to secure dynamic DNS updates.

TSIG

This protocol allows for transaction level authentication using shared secrets and one way hashing (with the HMAC-MD5 algorithm).
It can be used to authenticate dynamic updates as coming from an approved client or to authenticate
responses as coming from an approved recursive name server.
It’s an easy and strong authentication method, simpler than DNSSEC.
If you want more informations about Dynamic DNS Updates with TSIG and Security, please read this document.

Installation

Download and extract the source code of MyDNS version 1.1.0 at http://mydns.bboy.net/download :


$ wget http://mydns.bboy.net/download/mydns-1.1.0.tar.gz
$ tar xzf mydns-1.1.0.tar.gz


Download and apply my patch : /wp-content/contrib/mydns-1.1.0-tsig.patch


$ cd mydns-1.1.0
$ wget https://csquad.org/wp-content/contrib/mydns-1.1.0-tsig.patch
$ patch -p1 < mydns-1.1.0-tsig.patch

Build process

You need to build the program with OpenSSL support :

$ ./configure --with-openssl
$ make
# make install


Database setup

To create database structure use the ‘–create-table’ option :

$ mydns --create-table | mysql

Transaction Keys are stored in the ‘dnskey’ table and the name of the key.
Keyname allowed to update an record are stored in column ‘update_key’ of the ‘soa’ table.

You can generate you own key with dnssec-keygen tool :

$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST client.domain.com


Insert the value of this key in the ‘dnskey’ table :

mydns> INSERT INTO dnskey (name, algorithm, size, type, private) VALUES
('client.domain.com', 'HMAC-MD5', 128, 'HOST', 'IYrqgYuJaTkL2Xs34GZ7+w==');


Add the ‘update_acl’ column in the ‘soa’ table :

mydns> ALTER TABLE `soa` ADD `update_key` VARCHAR( 255 ) ;


Assign the update key to an DNS entry :

mydns> UPDATE soa SET update_key = 'client.domain.com' WHERE origin='domain.com.';

Restart the MyDNS server and check if the optional column ‘update_key’ was found :

# mydns -v
...
mydns: optional 'update_key' column found in 'soa' table
...


Usage

Update an domain entry with the nsupdate client :

$ nsupdate -d -y client.domain.com:IYrqgYuJaTkL2Xs34GZ7+w==
> server ns.domain.com
> zone domain.com
> update add entry.domain.com 60 A 192.168.0.1
> send


Conculsion

The full RFC in not totaly implanted, thoses features are missing :

• TCP support, I’am not an expert of the DNS protocol and I dont fully understand TCP usage and message chunking.
• Authentication of responses from an approved recursive name server.