Planète CS

Tuesday 05/09/2017

Blog des Experts et Architectes CS

FMF8 - 10 Octobre 2017 au LAAS à Toulouse

Prochaine Journée : FMF8 - 10 Octobre 2017 Véhicules autonomes et méthodes formelles (Programme au 21 Juillet 2017)

Ce forum est consacré aux méthodes formelles de développement. Non, ne partez pas tout de suite : les méthodes formelles sont faites pour vous ! Ces méthodes ne sont pas assez connues mais ont un potentiel énorme pour faire progresser la productivité ET la qualité intrinsèque des développements de logiciels embarqués et de leurs outils de développement et de vérification. Et elles ne sont pas si difficiles à mettre en œuvre : certains l’ont déjà fait, avec succès, pourquoi pas vous ? Nous vous proposons donc un cycle de conférence/forum pour vous présenter bien sûr les fondements théoriques de ces méthodes, mais surtout faire un état de l’art et de la pratique, démystifier, échanger, et pourquoi pas monter ensemble des projets pour “passer à l’acte” ? Les intervenants seront à la fois des scientifiques et universitaires les plus compétents dans ces domaines et des utilisateurs “de terrain” qui ont déjà pratiqué ces méthodes et vous livreront leurs retours d’expérience.

La première édition du Forum Méthodes Formelles (FMF) a eu lieu à Toulouse fin 2012 à l'initiative du DAS SE2L du pôle Aerospace Valley et du thème IFSE du RTRA STAE . De nouveaux partenaires ont rejoint l'organisation du forum depuis : pôle Minalogic en 2013, labex Digicosme en 2014, pôle Systematic en 2015, pôle Images & Réseaux en 2017. FMF est devenu un groupe de travail d' Embedded France en 2015.

Deux sessions du forum sont organisées annuellement. Les conférences ont lieu à Toulouse au LAAS-CNRS et sont retransmises en direct à Grenoble au centre INRIA Rhône Alpes, à Rennes au centre INRIA Bretagne Atlantique ainsi que sur le campus de Saclay.

par Agusti Canals le 2017-09-05 09:57

Monday 26/06/2017

Blog des Experts et Architectes CS

Retours de l'EclipseCon France 2017

Du 20 au 22 juin avait lieu à Toulouse l'EclipseCon France 2017. Comme vous vous en doutez, on y parlait d'Eclipse, mais pas que. Les sujets Modeling (et notamment Xtext et Capella), Science étaient également très présents.

Les points clefs de à retenir de ces conférences :

  • Du nouveau du côté des éditeurs textuels dans Oxygen, avec le LSP (Language Server Protocol) utilisé dans un nouvel éditeur générique et par Xtext.
  • Du côté Modelling, des avancées pour la description d'exécution de modèles en lien avec Sirius et de nouvelles briques pour naviguer entre modèle et document word.
  • Des retours intéressants sur la forge Tuleap.

Si cela vous intéresse, voici un petit compte-rendu des sessions que j'ai suivies, ainsi que des pointeurs pour trouver d'autres infos sur l'ensemble de la conférence. Les sessions devraient normalement être toutes rediffusées intégralement sur internet (YouTube) courant juillet.

par vhemery le 2017-06-26 08:48

Friday 10/03/2017

Humeurs d'un libriste

Compte-rendu du Meetup Jenkins Pipeline

J'ai participé aujourd'hui au « meetup » sur Jenkins Pipeline, LE greffon majeur introduit par la version 2.0 de Jenkins.

Arrivé bien en avance (7h30), je m'étais installé à la terrasse d'un café. Toulouse s'animait doucement, le ciel promettait une belle journée et, plongé dans un roman de Pierre Bordage, je sirotais un expresso. Cette rencontre s'annonçait sous de bons présages !

Et force est de reconnaitre que des journées comme celle-ci, j'en voudrais bien une par semaine ! Car tout était parfait : un thème au cœur de mes préoccupations (l'amélioration de nos pratiques d'intégration et de livraison continue), des animateurs passionnés et compétents, un tiers lieu (HarryCow coworking) superbe et accueillant, des moyens techniques confortables (réseau vitaminé, 200 VM mises à la disposition par DigitalOcean), repas et goodies offerts par CloudBees et, avec un soleil de retour et 23°C dans les rues de Toulouse, une ambiance printanière.

Pour en venir au cœur du sujet, si vous n'avez jamais entendu parler du greffon Pipeline, je vous invite à suivre la conférence Jenkins & continuous delivery pipeline donnée par Jean-Philippe Briend (CloudBees) lors du DevFest Nantes 2016. Elle constitue une bonne introduction.

Pipeline est souvent présenté comme le moyen de modéliser des processus d'intégration et de livraison continue complexes, contenant éventuellement des boucles, des étapes conditionnelles, des points de rendez-vous, etc. C'est vrai mais plus qu'un greffon (une famille de greffons en réalité), Pipeline est un paradigme puisqu'il porte en lui le concept « Everything as Code » cher aux adeptes du DevOps. Ainsi, par l'entremise de Groovy et d'un DSL, Pipeline vous permet de scripter votre processus d'intégration continue, ce qui présente plusieurs avantages :

  • Vous n'avez plus à configurer votre processus en cliquant à moult reprises dans l'interface touffue de Jenkins, activité manuelle dont la documentation demandait de nombreuses captures d'écran et moult explications de texte et dont reproduction d'une instance à l'autre de Jenkins était sujette à caution. Désormais, votre processus est décrit dans un script aisé à interpréter et bien plus facile à documenter.
  • Vous pouvez intégrer ce script à vos sources et le faire évoluer de manière synchrone.
  • Comme vos sources, ce script peut évoluer différemment selon les branches, ce qui vous permet d'ajuster le processus aux besoins de chaque branche (et pour encore plus de souplesse et d'automatisme, je vous invite à jeter un œil au greffon Multi branch pipeline).

Rien de bien nouveau pour les adeptes de Travis CI ou d'AppVeyor mais, désormais, « Jenkins le fait aussi ! » À ce sujet, notez que CloudBees vient de publier une nouvelle syntaxe qui reprend la forme déclarative des plateformes mutualisées et est désormais recommandée dans la plupart des cas, la syntaxe « Scripted Pipeline » devant être réservée aux contextes les plus complexes, difficiles à appréhender avec une approche déclarative.

Cette journée a donc été consacrée à la découverte de Pipeline. Le matin, après une courte présentation, nous avons rapidement mis les mains dans le cambouis, profitant de la généreuse infrastructure mise à disposition par DigitalOcean (chaque participant a eu droit à une VM Jenkins, une VM Sonar et autant de VM de build que nécessaire). Les animateurs avaient préparé trois exercices sympas qui m'ont permis de bien me faire la main sur ce greffon que je n'avais jusqu'alors qu'effleuré (cf. mon premier essai sur le projet libre Hipparchus). Après le repas, l'infrastructure de développement et l'architecture de Jenkins nous ont été présentées afin que les participants tentés par une contribution aient toutes les informations nécessaires. Puis, des groupes ont été formés en fonction des centres d'intérêt et des motivations du moment. Pour ma part, ne connaissant pas Java, j'étais mal parti pour écrire mon premier greffon Jenkins. Du coup, je me suis donné le reste de l'après-midi pour déclencher - via le greffon Pipeline - un build dans un conteneur Docker lancé par une instance de Jenkins elle-même « dockerisée » (si vous pensez à du « docker-in-docker », vous avez tout faux). J'ai réussi 10 minutes avant la fin des réjouissances !

Vous l'aurez compris, mon bilan de cette journée est très positif. Ma compréhension de Pipeline est désormais bien plus claire et, si quelques instructions « Groovy DSL » restent à mes yeux de l'ordre de l'incantation magique, j'ai acquis un savoir utilisable dans un futur proche. Je ne m'étais jusqu'alors pas intéressé aux meetup et c'était une belle erreur ! Certes, des ateliers pratiques se déroulant sur une journée entière sont rares ; la plupart des meetup sont des conférences ou des rencontres d'une ou deux heures en soirée. Ceci étant, j'ai expérimenté une de ces conférences vespérales très récemment et elle s'est elle aussi révélée instructive. Je ne peux donc que vous conseiller à tous de vous inscrire sur le site Meetup.com et de surveiller les évènements correspondant à vos centres d'intérêt dans votre région.

Et avant de vous laisser, je me dois de remercier chaleureusement les organisateurs et animateurs de cette journée (Michael Pailloncy et Baptiste Mathus) ainsi que les sponsors (Harrycow, DigitalOcean et CloudBees). Il est épatant de pouvoir assister, sans bourse délier, à des ateliers d'une telle qualité, dans des conditions aussi confortables. Un grand merci à eux tous !

PS : quelques photos ont été prises de cette journée studieuse mais cool !

par sdinot le 2017-03-10 18:51

Thursday 19/01/2017

Blog des Experts et Architectes CS

Nuit de l'info 2016 et le défi CS: les résultats

Cette année, 44 équipes se sont inscrites au Défi CS !!!  23 ont réussi à nous livrer un résultat ... Le Jury a eu lieu vendredi 2/12 et a prononcé le résultat suivant:

1ier:
Oh My Code de l'IUT Haguenau (8 membres)

2ième
HTAG ENSIEE de Strasbourg (8 membres)

3ième(s):
Kilobits de Polytech Lille (9 membres) et  /dev/fsociety de l'INSA Centre Val de Loire (10 membres)

F0.jpg

Pour en savoir plus sur la nuit de l'info connectez vous sur le site officiel et/ou sur l'espace collaboratif  Vous pouvez également consulter les statistique !!! ci-après un aperçu:

Nombre d'équipes : 392
Nombre de membres maximal dans une équipe : 29
Nombre de membres minimal dans une équipe : 2
Nombre de participants : 3068
Moyenne des participants d'une équipe : 8
Nombres de défis : 39
Nombres de défis relevés : 1438

...

F1.jpg

F2.jpg

F4.jpgF5.jpgF7.jpgF6.jpg

par Agusti Canals le 2017-01-19 16:32

FLOAT a été sélectionné pour être présenté au dernier forum "DGA Innovation 2016" qui s'est tenu les 23 et 24 novembre 2016

Le 23 était une journée dédiée au personnel DGA, le 24 a été beaucoup plus animée avec la visite de notre ministre de la défense J.Y Le Drian qui s’est arrêté juste à coté du poster FLOAT: stand4_FLOAT_v3.pdf, projet qui lui a été décrit par le responsable militaire de la thématique Télécom ...

Nous avons été approchés par du personnel militaire mais aussi par des sociétés qui se sont montrées intéressées par le niveau d’innovation du projet. Il faut savoir qu’à long terme les communications optiques semblent être le débouché pour pallier à l’engorgement de la voie RF.

Pour plus d'information contacter Lionel Gardenal

 

par Agusti Canals le 2017-01-19 16:07

Forum Méthodes Formelles: " Méthodes formelles et Cyber-Sécurité " Mardi 31 Janvier 2017 Toulouse

Notre prochain FORUM aura lieu à Toulouse au LAAS et sera retransmis en direct à Grenoble, Saclay et Rennes, n'hésitez pas à vous inscrire sur l'un des 4 sites ...

Programme

Accueil

  • 08h45 -08H55 Accueil des participants
     
  • 08h55-09h00 « Courte introduction à la journée »
    Agusti Canals (CS Communication & Systèmes, Toulouse, France)
     

Exposé Introductif

  • 09h00-10h00 «  Titre à venir  »
    Thomas Jensen (INRIA Rennes - Bretagne Atlantique/IRISA, Rennes, France)
     

Session sur les malwares

  • 10h00-10h30 « Détection des codes malveillants par analyse morphologique »
    Jean Yves Marion (Université de Lorraine, Loria, Nancy, France)
     
  • 10h30-11h00 « Besoins industriels, techniques utiles et problèmes ouverts »
    Sarah Zennou (Airbus, Suresnes, France)

11h00-11h30 : Pause Café

...
 

par Agusti Canals le 2017-01-19 16:06

More Electric Aircraft, Palais des Congrès de Bordeaux: 01 Février 2017 - 02 Février 2017

The aviation industry has seen a trend for greater electrical power requirements for aircraft systems. However, technology has progressed to the point where some light piloted aircraft are already battery powered, and it is envisioned that future larger aircraft will, to various degrees, be electrically powered.

here are many benefits to the more electric aircraft. The move to electric brakes and the electrical "green taxiing" systems allow airlines to reduce operating costs and environmental impact during ground operations.  Wide-body aircraft already benefit from sophisticated electrical power management systems and increased numbers of power-by-wire actuators ....

par Agusti Canals le 2017-01-19 16:06

Rugged pour l’affinage géométrique de prises de vue: Ecole Nationale des Sciences Géographiques à Marne la Vallée, 9 mars 2017

Rugged pour l’affinage géométrique de prises de vue, est à l'ordre du jour du colloque « Photogrammétrie et télédétection : vers la convergence ? »  le 9 mars  dans les locaux de l’Ecole Nationale des Sciences Géographiques à Marne la Vallée.

Utilisation de la bibliothèque open-source Rugged pour l’affinage géométrique de prises de vue (J. Guinet  CS Communication Systèmes, L. Labat-Allee, L. Maisonobe, D. Greslou)

La présentation sera réalisée par J.Guinet Expert CS N3, pour plus d'informations n'hésitez pas à le contacter.

 

 

Jeudi 9 Mars 2017
Programme "préliminaire"

 

9h00-9h40 : Conférence

  • Robotique et vision omnidirectionnelle (El Mustapha Mouaddib, Université de Picardie).

9h40-10h40

  • Interface graphique pour MicMac sous Linux, Windows, Mac OS (D. Jouin, CEREMA) ;
  • Utilisation de la bibliothèque open-source Rugged pour l’affinage géométrique de prises de vue (J. Guinet  CS Communication Systèmes, L. Labat-Allee, L. Maisonobe, D. Greslou) ;
  • Optimisation du calcul de points homologues à partir d'une première modélisation 3D (G. N’Guyen, ENSG).

               Pause-café                               

11h00-12h00

  • Central Italy 2016 earthquakes early impact mapping. Integration of satellite remote sensing data with UAV and terrestrial photogrammetric models (F. Chiabrandoa, Politecnico di Torino, A.M. Linguab, A. Spanòa) ;
  • Monitoring activity with multi-scale photogrammetry at Piton de la Fournaise, La Réunion (A. Derrien) ;
  • Utilisation de l’imagerie THRS Quickbird et aérienne pour la protection du cadre bâti face au risque sismique –Application sur la ville de Boumerdes, Algérie-(M. A. Seddiki, Centre des Techniques Spatiales, R. Nafti, A. Guerroudj).

                          Déjeuner-buffet

13h30-16h30

  • Développement de la méthode PLaS pour quantifier les déplacements 3D des mouvements de terrain (M-A. Chanut, CEREMA, J. Kasperski, L. Dubois, S. Dauphin, J-P. Duranthon) ;
  • Apport de la photogrammétrie et de la télédétection aux suivis des aléas mouvement de terrain (O. Brenguier ADRGT, M. Desrues , P. Lacroix) ;
  • Application photogrammétrique : évaluation de la stabilité d’un bloc rocheux (N. Zergaoui, CEREMA, G. Monnot) ;
  • Caractérisation des températures de surface et des déformations d’une structure du génie civil : application à un quai portuaire (R. Antoine, CEREMA C. Fauchard, J.F. Oehler, P. Joignant) ;
  • Mesures combinées d'imagerie de résistivité électrique et de photogrammétrie : étude des falaises des Vaches Noires (C. Fauchard, CEREMA, R. Antoine, T. Roulland, O. Maquaire, S. Costa, R. Davidson, Y. Fargier) ;
  • Auscultation d’un pilier de carrière souterraine par combinaison de la photogrammétrie et de l’imagerie 3D géo-électrique (Y. Fargier, CEREMA, L. Dore, R. Antoine, S. Palma Lopes, C. Fauchard).

 

16h30–17h30 Conclusions et perspectives par le président de la SFPT

par Agusti Canals le 2017-01-19 16:05

Thursday 24/11/2016

Guilhem Bonnefille

Lenteur des dossiers partagés de VirtualBox avec Windows

Depuis que j'ai converti ma VM Windows de VMPlayer à VirtualBox, je constatais des lenteurs lors de la navigation avec l'explorateur de fichiers dans l'arborescence des Shared Folders. En effet, au changement de dossier, ça prenait régulièrement 10 secondes, voire plus.

En fait, la réponse se trouve dans la documentation de VirtualBox : Long delays when accessing shared folders

par Guilhem Bonnefille le 2016-11-24 13:53

Tuesday 04/10/2016

Guilhem Bonnefille

De VMPlayer à VirtualBox

Depuis quelques années, ma VM Windows est propulsée par VMPlayer. Suite à une montée de version de mon Ubuntu, ce dernier ne fonctionne plus : la commande vmplayer retourne un code 255.

Ayant urgemment besoin de la VM, je désinstalle VMware (vmware-installer -u vmware-player) et je réinstalle une version plus récente. Mais il n'en fallait pas plus pour me donner envie de porter cette VM sous VirtualBox.

Après quelques copies de sauvegarde, la première tentative consiste à créer une nouvelle VM dans VirtualBox, lui associer le disque virtuel vmdk et lancer le tout. Malheureusement, ça ne va pas bien loin : après quelques retaillage de l'écran virtuel, je reste sur un écran noir, sans passer par le logo Windows. Au redémarrage suivant, en mode sans échec, il y a un tas d'indications qui sont données puis... écran noir. Je suspecte donc une influence néfaste des VMware Tools actuellement installés.

En jetant un oeil sur Internet, je découvre un article qui suggère de convertir l'image en OVF avant de l'importer. La conversion avec ovftool se fait parfaitement. Ensuite j'importe la VM et, miracle de technologie, elle fonctionne. Enfin, l'écran est en 800x600 et le réseau hors service. Je prends donc le soin de désinstaller le VMware Tools, puis je redémarre, puis j'installe les add-ons VirtualBox, et je redémarre, pour arriver à un système tout à fait fonctionnel.

Youpi !

par Guilhem Bonnefille le 2016-10-04 21:26

Friday 02/09/2016

Aurélien Tisné

Lancer une VM sans interface graphique

Le but est de lancer une VM sans utiliser de VM manager. C'est particulièrement intéressant quand la VM tourne sur une machine hôte distante. On peut ainsi exécuter une VM sans avoir un lien permanent avec la machine hôte.

Je me place dans le cas d'une machine hôte qui ne possède aucun logiciel VMWare et qui utilisera un simple player pour exécuter une VM.

Il faut avant tout d'abord installer le player et l'API :

  • se connecter sur l'hôte avec un environnement X (les setups d'install sont graphiques)
ssh -X <host>
chmod u+x VMware-Player-6.0.3-1895310.x86_64.bundle
./VMware-Player-6.0.3-1895310.x86_64.bundle
  • installer l'API
chmod u+x VMware-VIX-1.13.0-1295980.x86_64.bundle
./VMware-VIX-1.13.0-1295980.x86_64.bundle

Tester ensuite que la VM s'exécute bien. Il peut y avoir des incompatibilités matérielles. Il faut également ajuster la configuration réseau.

vmplayer /path/to/vm/my.vmx

Une fois que ça tourne bien. On peut enfin lancer la VM sans interface. Cela se fait sur la machine hôte mais plus besoin d'environnement graphique (plus besoin de l'option -X du ssh)

vmrun -T player start /path/to/vm/my.vmx nogui

ou, à distance

ssh <host> vmrun -T player start /path/to/vm/my.vmx nogui

Pour l'arrêter

vmrun -T player stop /path/to/vm/my.vmx

Pour tester si elle tourne

vmrun -T player list /path/to/vm/my.vmx

Ces actions peuvent se faire à distance à condition d'avoir un VMWare Server sur l'hôte (et non plus un simle player)

vmrun -T server -h https://myHost.com:8333/sdk -u hostUser -p hostPassword start

par atisne le 2016-09-02 09:39

Wednesday 06/07/2016

Guilhem Bonnefille

Créer un plugin pour Wireshark, c'est facile

Dans le cadre d'une activité autour du standard CCSDS MAL et de son implémentation sur TCP/IP, j'ai eu besoin de vérifier les informations qui circulent sur le réseau. Du coup, je me suis fait un plugin Wireshark pour décoder nos trames.

Pour développer ce type de plugin, on peut utiliser le C ou lua. J'ai choisi la seconde solution pour sa simplicité de mise en oeuvre. Après quelques recherches, j'ai pu découvrir que ce type de plugin ce nomme dissector. Ensuite, les quelques exemples proposés dans la documentation permettent de rapidement développer ce plugin.

Pour différentes raisons, je n'avais pas le wireshark sur la machine de test. Du coup, pour collecter les données il faut utiliser le bon vieux tcpdump :

tcpdump -i eth0 -w mal.dump tcp port 12345

Ensuite, on peut visualiser le contenu avec :

wireshark -X lua_script:maltcp_dissector.lua mal.dump

Au final, j'ai pu découvrir le framework et développer mon plugin en quelques heures.

Références :

par Guilhem Bonnefille le 2016-07-06 08:03

Tuesday 28/06/2016

Blog des Experts et Architectes CS

Retour de l'EclipseCon France 2016

Du 7 au 10 juin avait lieu à Toulouse l'EclipseCon France 2016. Comme vous vous en doutez, on y parlait d'Eclipse, mais pas que. Les sujets Modeling et Internet of Things étaient également très présents.

Les points clefs à retenir de ces conférences :

  • Pour l'IoT (Internet of Things / Objets Connectés) :

- Le réseau "The Things Network" semble devenir un incontournable. Ce réseau communautaire administré par ses utilisateur est entièrement libre et gratuit, tout en offrant des solutions de modularité et de chiffrage pour des solutions entièrement sécurisées.
- Les solutions Eclipse ne sont pas en reste sur ce domaine, permettant de créer un véritable environnement synergique avec MQTT, The Things Network et le protocole LoRa.

  • Les composants IHMs réutilisables basés sur EMF continuent d'évoluer avec EMF Forms et EMF Parley. Elles se déclinent pour différentes technologies de rendu, comme JavaFX (non implémenté pour EMF Parsley) ou AngularJS. EMF peut également s'utiliser pour des solutions web, avec du JSON et des IHMs en AngularJS par exemple.
  • L'outillage Eclipse pour faire du Docker se répand de plus en plus et évolue rapidement.

Si cela vous intéresse, vous trouverez en annexe un petit compte-rendu des sessions que j'ai suivies, ainsi que des pointeurs pour trouver d'autres infos sur l'ensemble de la conférence. Les sessions devraient normalement bientôt être toutes rediffusées intégralement sur internet (probablement YouTube).

par vhemery le 2016-06-28 11:14

Tuesday 12/04/2016

Blog des Experts et Architectes CS

ICSSEA 2016 and Neptune Days : CALL FOR PARTICIPATION

ICSSEA 2016, 27th International Conference on  SOFTWARE & SYSTEMS ENGINEERING and their APPLICATIONS Telecom ParisTech, Paris, May 25-27, 2016

ASSOCIATED EVENT, NEPTUNE DAYS 2016 ParisTech, Paris, May 26, 2016
 

Sponsored by AFIS (the French Association for Systems Engineering) and INCOSE, co-organized by TELECOM ParisTech, CS Communication & Systems, and the Génie Logiciel quarterly, the 26th edition of the ICSSEA Conference (International Conference on Software & Systems Engineering and their Applications) will be held in Paris on May 27-29, 2015.
 
Sponsors & Partners
AFIS – INCOSE – SEE – CS – Embedded France – Telecom ParisTech – Génie Logiciel – CIGREF – Systematic – NOKIA CNAM – CONNEXION – EDF – Edellweiss & Partners – ANSYS/Esterel Technologies – ÉTS – Fraunhofer Gesellschaft – IRIT – – SysML France – AFTI-ETGL……
 
ICSSEA 2016 PROGRAM
http://icssea.org
    
INTERNATIONAL PROGRAM COMMITTEE
 
Alexandra Bagnato – Softeam (F)
Philippe Baufreton – Hispano Suiza (F)
Erik Boasson – PrismTech (NL)
Agusti Canals – CS Communications & Systèmes (F)
Joseph K. DeRosa – Consultant (USA)
Bernard Dion – Esterel Technologies (F)
Cecilia Haskins – NTNU (N)
Vassilka Kirova – Nokia (USA)
Claude Y. Laporte – École de technologie supérieure (CDN)
François-Marie Lesaffre – SopraSteria (F)
Dominique Luzeaux – DGA (F)
Thierry Millan – Université de Toulouse (F)
Élie Najm – Telecom Paristech (F)
Asmus Pandikow – Syntell (S)
Jean-Claude Rault – Génie Logiciel (F)
Axel Rennoch –  Fraunhofer FOKUS (D)
Christian Winkler – AAU (A)

 

par Agusti Canals le 2016-04-12 08:42

Tuesday 29/03/2016

Aurélien Tisné

Add a custom execution status in TestLink

If you find that default execution status are not enough accurate or unsuitable to your business, feel free to add a new status or redefine existing ones.

We will see the steps to follow to add a new execution status. We want to add the state Partially passed (not fully good but not blocking).

First, declare the new status in the config file. Do not forget to use the custom config file to make upgrades easier. Edit the file <TL_HOME>/custom_config.inc.php. Add the new state partially with code m as new status_code

$tlCfg->results['status_code'] = array (
        'failed'        => 'f',
        'blocked'       => 'b',
        'passed'        => 'p',
        'not_run'       => 'n',
        'partially'     => 'm'
);

Add the translation label (will be defined later in translation files) as new status_label

$tlCfg->results['status_label'] = array(
  'not_run'       => 'test_status_not_run',
  'passed'        => 'test_status_passed',
  'failed'        => 'test_status_failed',
  'blocked'       => 'test_status_blocked',
  'partially'     => 'test_status_partially'
);

Add the new status for the execution user interface. The order is here important: it defined the displayed order (usually gradually sorted).

$tlCfg->results['status_label_for_exec_ui'] = array(
  'not_run'   => 'test_status_not_run',
  'passed'    => 'test_status_passed',
  'partially' => 'test_status_partially',
  'failed'    => 'test_status_failed',
  'blocked'   => 'test_status_blocked'
);

Add the new status color for charts

$tlCfg->results['charts']['status_colour'] = array(
  'not_run'   => '000000',
  'passed'    => '006400',
  'failed'    => 'B22222',
  'blocked'   => '00008B',
  'partially' => 'FF8C00'
);

Then, we must define all translations for the new status label. In <TL_HOME>/locale/en_US/custom_strings.txt and <TL_HOME>/locale/en_GB/custom_strings.txt

$TLS_test_status_partially = "Partially good";

In <TL_HOME>/locale/fr_FR/custom_strings.txt

$TLS_test_status_partially = "Partiellement réussi";

And so on, for all your relevant locales.

Finally, we have to define CSS styles in order to have a colorized display. Once again, use the customization mechanism to add the new styles. In <TL_HOME>/gui/themes/default/css/custom.css

/* ***** Execution & Results ********************************************************* */
div.partially {
  color:      white;
  margin:     8px;
  padding:    6px;
  text-align:   center;
  background:   #FF8C00;
}


/* ***** execution tree coloring ************************* */
span.partially
{
  color:        black;
  padding:      3px;
}


span.light_partially {
  background:     #FDC794;
}


/* ***** render test result status (coloring background) ************************* */
.partially {
  color:      white;
  background:   #FF8C00;
}

/* ***** render test result status (coloring text) ************************* */
.partially_text {
  color:       #FF8C00;
  font-weight: bold;
}

You should now see the new status available in the execution result form: Capture_du_2014-10-08_09_48_27.png

And also in the test case tree: tc-tree.png

You may want to have a report to show all test cases in the new created status. If so, edit <TL_HOME>/cfg/custom_reports.cfg.php to add the new report based on the generic one <TL_HOME>/lib/results/resultsByStatus.php

$tlCfg->reports_list['list_tc_partially'] = array( 
	'title' => 'link_report_partially',
	'url' => 'lib/results/resultsByStatus.php?type=' . $tlCfg->results['status_code']['partially'],
	'enabled' => 'all', 
	'directLink' => '%slnl.php?apikey=%s&tproject_id=%s&tplan_id=%s&type=list_tc_partially',
	'format' => 'format_html,format_pseudo_ods,format_mail_html'
);

and add a label for the new report in all custom_strings <TL_HOME>/locale/*/custom_strings.txt

$TLS_link_report_partially="Partially passed Test Cases";

Unfortunately, it seems not possible to add custom status in the function Test Cases Assigned to Me that proposes shortcuts to set the status of an execution.

par atisne le 2016-03-29 14:04

Tuesday 15/12/2015

Blog des Experts et Architectes CS

Méthodes formelles et sûreté de fonctionnement

Mardi 26 Janvier 2015 Toulouse

Programme

  • 08h45 -08H55 Accueil des participants
  • 08h55-09h00 « Courte introduction à la journée »
    Agusti Canals (CS Communication & Systèmes, Toulouse, France)
     
    • 09h00-10h00 «  Formal methods for safety analysis  »
      Holger Hermanns (Saarland University, Germany)
       
    • 10h00-10h30 « Principes du langage AltaRica et des outils associés d'analyse de sûreté de fonctionnement »
      Pierre Bieber (ONERA, Toulouse, France)
       
    • 10h30-11h00 « La modélisation dysfonctionnelle à la DGA »
      Christophe Frazza (DGA/TA, Toulouse, France)
  • 11h00-11h15 : Pause Café
     
    • 11h15-12h00 « Modélisation et analyses d’architecture IMA à l’aide d’AADL : analyses de sûreté de fonctionnement et génération de code »
      Julien Delange (Software Engineering Institute, Carnegie Mellon University, USA), Jérôme Hugues (ISAE SUPAERO, Toulouse, France),
       
    • 12h00-12h30 « Fiabilité de mission d’un avion — Evaluation stochastique en opération »
      Karama Kanoun (LAAS-CNRS, Toulouse, France)
  • 12h30-14h00 : Pause Repas
     
    • 14h00-15h00 « Safety Architect© : un outil MBSA (Model-Based Safety Analysis) et son application aux études de sûreté des systèmes de combat »
      Frédérique Vallée (All4Tec, Massy, France), Romain Palud (DCNS, Toulon, France)
       
    • 15h00-15h45 « DFTCalc: a Tool for Advanced Reliability, Availability, Maintenance and Safety Analysis »
      Enno Ruijters et Marielle Stoelinga (Twente University, The Netherlands)
  • 15H45-16h00 : Pause Café
     
    • 16h00-16h45 « Safety, Dependability and Performance Analysis of Aerospace Systems using the COMPASS Toolset »
      Thomas Noll (RWTH Aachen University, Germany)
       
  • 16H45-17h30 : Table Ronde animée par Gérard Ladier (Pôle Aerospace Valley & IRT Saint-Exupéry, Toulouse, France)
    « Méthodes formelles et sûreté de fonctionnement, quels débouchés industriels ? »

par Agusti Canals le 2015-12-15 13:29

Oomph : the Eclipse distributions installer

One installer to rule them all.

What is Oomph ?

Oomph is the new Eclipse installer (https://wiki.eclipse.org/Eclipse_Installer). This new project is born in 2014 from Eike Stepper (a well known protagonist in the Eclipse sphere). Oomph claims it "automates the installation and update of Eclipse development environments" and it works well.

It has been quickly adopted by the Eclipse community.
Oomph provides a default public configuration catalog, which is used by Eclipse hosted projects. Those with lot of different committers hence have contributed to it, in order to configure a reproducible development environment for all their committers.

 

What does Oomph features ?

The main Oomph feature is the configurations catalog. After referencing a catalog, you can chose with a simple wizard to install a new Eclipse distribution. You pick in this catalog what you want to install and configure where and how you want to install your new Eclipse distribution.
Then, whenever the catalog is updated, your Eclipse distribution and workspace can be updated with a simple menu-action.
Oomph also brings new extra features, such as:

  • Dynamic working sets, which magically organize your workspace in self-maintaining virtual folders, relieving you from the hassle of sorting your workspace's projects manually.
  • A new centralized bundle pool implementation, which prevents you from downloading the same binaries ever and ever for each new Eclipse distribution.

 

But how can we use it for an industrial project?

  • With the default public catalog: you are limited to standard components' configurations Eclipse has chosen to publish. This is very convenient when you need to install a quick one-shot Eclipse distribution to test a particular Eclipse feature, but not very adapted to your project's particular needs.
  • But you can also build your own catalog: then, you can deploy an Eclipse distribution which match your project's specific needs and experience the full extend of Oomph's power. There are 2 benefits:
    • You can use the same catalog for your whole company and factorize standard configurations per functionality, while still picking only the functionalities you want in each installation.
    • You can define project-specific configurations which automatize all the tedious parts, such as importing projects from GIT or SVN, configuring preferences, and so on.

Yet, constructing and publishing your own catalog is not easy. You will need an advanced Eclipse user to specify this catalog and maintaining it up to date, by merging with the public Eclipse catalog which evolves constantly.

 

With Oomph, only the catalog's maintainer may experience difficulties (and less than before).
Now, whenever an end-user needs a new Eclipse distribution, his hardest job is installing a correct JVM and configuring it (especially if you have an unrecognised certificate authority).

par vhemery le 2015-12-15 10:32

Oomph : l'installeur de distributions Eclipse.

Un installeur pour les gouverner tous.

Oomph, qu'est-ce que c'est ?

Oomph est le nouvel installeur pour Eclipse (https://wiki.eclipse.org/Eclipse_Installer). Ce nouveau projet nous a été servi en 2014 par Eike Stepper (bien connu dans la sphère Eclipse). Oomph vise à automatiser l'installation et la mise à jour de distributions Eclipse et le fait plutôt bien.

Il a très vite été adopté au sein de la communauté Eclipse.
Un catalogue de configurations publiques est disponible par défaut, renseigné par les projets Eclipse. Les projets réunissant des committers variés ont saisi l'occasion pour renseigner leurs propres configurations, offrant à tous un environnement de développement facile à installer et reproductible.

 

Quelles sont les fonctionnalités apportées ?

La première est le catalogue de configurations. En pointant un catalogue, on peut installer une nouvelle distributions Eclipse en déroulant un simple wizard. Il suffit de choisir dans le catalogue les fonctionnalités à installer et configurer où et comment l'installation doit se faire.
Ensuite, à chaque mise à jour du catalogue, il est possible de mettre à jour une distribution Eclipse et son workspace en cliquant sur un simple menu.
Oomph propose aussi d'autres fonctionnalités, telles que :

  • Les "working sets" dynamiques, qui organisent automatiquement votre workspace en dossiers virtuels, vous évitant la fastidieuse tâche de les trier manuellement.
  • Une nouvelle implémentation centralisée du "bundle pool", qui évite de retélécharger sans cesse les mêmes binaires pour chaque nouvelle distribution Eclipse.

 

Mais quel intérêt pour un projet industriel ?

  • Avec le catalogue par défaut : vous êtes limité aux configurations standards publiées par Eclipse. C'est très pratique pour tester une fonctionnalité particulière et installer une distributions Eclipse jetable, mais pas vraiment adapté aux besoins spécifiques de chaque projet.
  • Il est également possible de publier son propre catalogue : le vrai pouvoir de Oomph se révèle alors à vous pour vous permettre d'installer des distributions Eclipse correspondant à vos besoins. Le bénéfice est double :
    • Vous pouvez utiliser le même catalogue pour toute votre entreprise et mutualiser des configurations standards pour chaque fonctionnalité, tout en ne choisissant que celles nécessaire dans chaque installation.
    • Vous pouvez définir des configurations spécifiques à un projet pour automatiser les parties fastidieuses, telles que l'import des projets de GIT ou SVN, la configuration des préférences, etc.

Cependant, construire et publier votre catalogue personnalisé n'est pas une tâche facile. Vous aurez besoin d'un utilisateur Eclipse avancé pour spécifier ce catalogue et le maintenir à jour, en le fusionnant avec le catalogue public qui évolue sans cesse.

 

Avec Oomph, seul le mainteneur du catalogue subit les difficultés (et moins qu'avant).
A présent, dès qu'un utilisateur final a besoin d'une nouvelle distribution Eclipse, le plus difficile n'est plus que d'installer correctement la JVM et de la configurer (en particulier si vous utilisez un certificat d'autorité racine non reconnu).

par vhemery le 2015-12-15 10:31

Friday 04/12/2015

Blog des Experts et Architectes CS

Nuit de l'Info 2015

22 équipes ont relevé le défi CS (), 11 ont livré un rendu ... Le gagnant est :

 

ResultatNDI.jpg

par Agusti Canals le 2015-12-04 14:18

Saturday 07/11/2015

Humeurs d'un libriste

Tests unitaires graphiques sans carte vidéo

Le projet Orfeo Toolbox met en œuvre une batterie de plus de 2800 tests unitaires (nombre en évolution permanente) pour détecter les régressions de code. Ces tests sont joués chaque nuit sur différentes plates-formes et leurs résultats sont publiés sur un tableau de bord que consultent chaque matin les développeurs. Une partie de ces tests produisent des sorties graphiques (2D et OpenGL) et ils échouent s'ils n'ont pas accès à un périphérique d'affichage vidéo. Pour y remédier, nous maintenons une session graphique ouverte sur les machines de test (session ouverte au démarrage de la machine via une connexion automatique de l'utilisateur de test). Cette solution n'est pas satisfaisante pour deux raisons :

  • laisser une session ouverte n'est pas recommandé (faille que l'on peut colmater sur GNU/Linux par le verrouillage de la session à l'ouverture par l'économiseur d'écran) ;
  • qui dit session graphique ouverte dit environnement graphique installé, ce qui n'est pas le cas en général sur un serveur GNU/Linux.

J'ai découvert la semaine dernière le serveur X11 virtuel Xvfb et son wrapper xvfb-run. xvfb-run crée un environnement X tout à fait standard pour le client X qu'il lance hormis que dans les faits, tout se passe en mémoire et aucun affichage n'est produit (il n'est même pas nécessaire que la machine soit équipée d'une carte graphique). Je me suis donc empressé de le tester sur OTB.

Pour limiter la batterie de tests aux tests graphiques, il faut habituellement lancer les commandes suivantes (nous utilisons les outils CMake et CTest) :

$ cd ~/otb/build/OTB
$ ctest -T test -R ^vr
   Site: yoda.isdi0.si.c-s.fr
   Build name: Ubuntu-GNU-Linux-12.10-x86_64-Debug
Test project /home/sdinot/otb/build/OTB
      Start 1845: vrTuImageWidgetNew
 1/52 Test #1845: vrTuImageWidgetNew ........  Passed  0.08 sec
  [...]
      Start 1896: vrTuAmplitudeFunctorTest
52/52 Test #1896: vrTuAmplitudeFunctorTest .  Passed  0.07 sec

100% tests passed, 0 tests failed out of 52

Total Test time (real) =  29.01 sec

Avec le wrapper xvfb-run, la commande devient :

$ cd ~/otb/build/OTB
$ xvfb-run -a -n 1 -s "-screen 0 1024x768x24 -dpi 96" \
    ctest -T test -R ^vr
   Site: yoda.isdi0.si.c-s.fr
   Build name: Ubuntu-GNU-Linux-12.10-x86_64-Debug
Test project /home/sdinot/otb/build/OTB
      Start 1845: vrTuImageWidgetNew
 1/52 Test #1845: vrTuImageWidgetNew ........  Passed  0.07 sec
  [...]
      Start 1896: vrTuAmplitudeFunctorTest
52/52 Test #1896: vrTuAmplitudeFunctorTest .  Passed  0.07 sec

100% tests passed, 0 tests failed out of 52

Total Test time (real) =  24.59 sec

Cerise sur le gâteau, ces tests sont apparemment bouclés plus rapidement lorsque la sortie graphique se fait en mémoire plutôt que sur l'écran. L'écart de 4 à 5 secondes - soit un gain de 15 % - que l'on peut constater dans les rapports ci-dessus est en effet parfaitement reproductible !

par sdinot le 2015-11-07 11:50

Friday 07/08/2015

Aurélien Tisné

Deploy shorewall configurations without using a root user

Shorewall offers the ability to manage several configurations in a convenient way. It allows to centralize the management of your firewall configurations. You work on a single location (your PC for example) and easily deploy the configurations on the targets.

By default, the tool use scp/ssh to act on the remote system and required a user with root privileges to install the configuration on the target. The documentation asks to use a root user.

However, an usual security good practice is to disable the root login by SSH: PermitRootLogin no in the file sshd.conf.

We will see how to use a sudoer user instead of a root user.

You need to install the shorewall package on the administrative system. shorewall-lite is sufficient on the target machines.

You create your configuration with the full sharewall as usual. When ready, you can push the configuration on the target server using shorewall itself. Once the configuration is set on the target, shorewall-lite is started to work with it and thus enable a firewall.

cd $MYCONF
shorewall load -r <root-user> <target-server-name>

Use reload if the firewall is already running on the target.

Now, here is the trick to avoid to use a root user. In the file shorewall.conf alter the variable RSH_COMMAND as follow:

RSH_COMMAND='ssh -t ${root}@${system} "sudo -p \"#[sudo] password for %p: \" ${command}"'
  • we add the option -t to force a pseudo-tty to the ssh command, to be able to type the sudo password
  • we add the sudo command, to use sudoer mechanism
  • we use the -p \“#sudo password for %p: \” option to insert a # (to comment) before the prompt to not interfere with the capabilities retrieval

Warning: You will not see, in standard output, the first sudo prompt, if it's the first time your are loading. Indeed, if it is not already done, the load command start by gathering capabilities of the target machine. This is done using the RSH_COMMAND, we've just altered. But the result of the shorewall-lite show -f capabilities is redirected into the file capabilities and the sudo prompt is also included in this file. That's why we insert a # before the prompt to comment it and not disturb capabilities.

par atisne le 2015-08-07 12:52

Monday 08/06/2015

Humeurs d'un libriste

Premier hackathon OTB

Organisé par le CNES et CS SI, le premier « hackathon OTB » a réuni développeurs et utilisateurs avancés du 3 au 5 juin 2015 à La Serre à Toulouse. Orfeo Toolbox (OTB pour les intimes) est une bibliothèque libre de traitement d'images satellites orientée télédétection, dont le développement est financé par le CNES et réalisé en majeure partie par CS SI depuis 2006. La Serre est un tiers-lieu propice aux conférences et aux rencontres informelles qui partage avec le fablab Artilect une grande friche industrielle (Le Multiple).

img_4287.jpg

Avec la fin du programme Orfeo, le projet OTB est en pleine mutation. Mutation technique - marquée par la sortie de la version 5.0 - mais aussi et surtout mutation dans sa gouvernance. S'inspirant notamment de la gouvernance ouverte mise en place par CS SI pour le projet Orekit, le CNES vient d'ouvrir celle du projet Orfeo Toolbox et un changement de licence est à l'étude. Ce premier hackathon a permis de présenter ces évolutions, d'échanger avec des utilisateurs avancés, de recueillir leurs besoins et de discuter la feuille de route.

Entre mini-conférences, présentation des réalisations de CS SI, du CESBIO, du SERTIT, du CEREMA et d'ONF International (autant de contributions potentielles au projet OTB), ateliers techniques, journée « OTB hacking », tout le monde y a trouvé son compte. Quelques badauds se sont même arrêtés pour écouter qui une présentation, qui un échange technique.

img_4324.jpg

Un grand merci à CS SI d'avoir financé cet événement, volontairement organisé dans un espace ouvert et convivial, plus original et agréable que ne le sont les locaux de CS ou du CNES. Pour beaucoup de participants, c'était leur première visite d'un tiers lieu et d'un fablab ; une découverte du lieu leur a donc été proposée et ils ont pu observer des makers à l'œuvre.

img_4298.jpg

Quelques photographies de l'événement sont déjà en ligne.

par sdinot le 2015-06-08 12:59

Tuesday 07/04/2015

Laurent Cocault

JavaFX et SVG

Les premiers travaux du W3C (World Wide Web Consortium) sur le format SVG (Scalable Vector Graphics) datent de 1999. Malgré son age avancé, le standard continue d'évoluer (le standard a connu plusieurs versions dont une version dérivée avec la spécification Tiny destinée aux terminaux mobiles; une seconde version du standard est actuellement en cours de définition). On ne peut pas dire que la présence du standard dans le domaine spatial soit écrasante, même si son intérêt dans le cadre des applications cartographiques n'est pas à négliger. On voit néanmoins régulièrement ces trois lettres faire leur apparition dans le secteur des centres de contrôle dès qu'il est question de vues synoptiques. Cette approche avait par exemple été adoptée dans le cadre de la rénovation du logiciel SpaceMC de Thales Alenia Space menée fin 2008. Cette approche est également celle retenue sur la ligne de produits ISIS du CNES en cours de développement. Et on peut toujours espérer que la System Engineering Team de l'ESA l'adoptera pour le framework EGS-CC...

Il existe différentes manière d'envisager d'intégrer du SVG dans une application. L'approche la plus classique consiste à s'appuyer sur le support du standard par les navigateurs pour l'intégrer dans des applications Web. Cette approche n'exclut néanmoins pas l'utilisation de ressources SVG sur un client lourd. Batik a ainsi permis de marier SVG et la technologie Swing, solution retenue dans le cadre de SpaceMC. Mais l'abandon progressif de Swing au profit de JavaFX pose à nouveau la question : comment intégrer SVG dans un client lourd aujourd'hui ?

Orientation


Quelques recherches sur le Net permettent d'arriver rapidement à la conclusion que SVG et JavaFX sont solubles. Certains tutoriels suggèrent même plusieurs pistes. Mais la piste la plus régulièrement évoquée consiste à afficher les contenus SVG en s'appuyant sur le moteur de rendu Web intégré à JavaFX. Alors faisons des classes javafx.scene.web.WebView et javafx.scene.web.WebEngine nos meilleures amies pour ces quelques essais.

Chargement d'un SVG disponible en ligne


Commençons simplement par afficher une ressource disponible sur Internet dans une application JavaFX.

    import javafx.application.Application;
    import javafx.scene.Scene;
    import javafx.scene.layout.VBox;
    import javafx.scene.paint.Color;
    import javafx.scene.web.WebView;
    import javafx.stage.Stage;
   
    /**
     * Test SVG displays.
     */
    public class SvgDisplay extends Application {
   
        /**
         * Run the main application.
         *
         * @param args
         *            Arguments of the application
         */
        public static void main(String[] args) {
            // Launch the GUI
            launch(args);
        }
   
        /**
         * {@inheritDoc}
         */
        @Override
        public void start(Stage primaryStage) throws Exception {
   
            // Set the main window title
            primaryStage.setTitle("SVG tests");
   
            // Scene it
            Scene scene = new Scene(new VBox(), 800, 600);
            scene.setFill(Color.OLDLACE);
   
            // Create a Web View
            WebView view = new WebView();
   
            // And add it to the scene
            ((VBox) scene.getRoot()).getChildren().add(view);
   
            // Load the SVG
            view.getEngine()
                    .load("http://upload.wikimedia.org/wikipedia/commons/8/85/Cyclohexane_simple.svg");
   
            // Show the editor
            primaryStage.setScene(scene);
            primaryStage.show();
        }
    }


Les instructions intéressantes ici sont celles qui permettent de créer la WebView et de charger son contenu en faisant référence au WebEngine sur lequel elle s'appuie.

Chargement d'un SVG disponible localement


Dans le contexte d'un centre de contrôle, l'accès à des ressources externes n'est pas un cas de figure représentatif. Les exigences de sécurité des centres restreignent très fortement l'accès aux ressources externes, voire les interdisent, même si l'accès est à l'initiative du centre. Franchissons une étape en adaptant l'appel à la méthode chargement:

    view.getEngine().load("file:///home/laurent/workspace/sandbox/src/main/resources/sample.svg");

Chargement d'un contenu pré-calculé


L'exemple précédent est à peine plus représentatif que le premier dans la mesure où, dans le cadre d'un centre de contrôle, on cherchera avant tout à présenter un contenu dynamique. Dans le cas d'une vue synoptique, on devra en effet calculer le contenu à afficher en fonction de l'état des paramètres de télémesure. L'API de la classe WebEngine, propose un tel mode de chargement illustré ci -dessous:

    // Load the SVG
    StringBuilder builder = new StringBuilder();
    builder.append("<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>");
    builder.append("<svg xmlns=\"http://www.w3.org/2000/svg\" version=\"1.0\" width=\"480\" height=\"543.03003\" viewBox=\"0 0 257.002 297.5\" xml:space=\"preserve\">");
    builder.append("<g transform=\"matrix(0.8526811,0,0,0.8526811,18.930632,21.913299)\">");
    builder.append("<polygon points=\"8.003,218.496 0,222.998 0,74.497 8.003,78.999 8.003,218.496 \"/>");
    builder.append("<polygon points=\"128.501,287.998 128.501,297.5 0,222.998 8.003,218.496 128.501,287.998 \" />");
    builder.append("<polygon points=\"249.004,218.496 257.002,222.998 128.501,297.5 128.501,287.998 249.004,218.496 \" />");
    builder.append("<polygon points=\"249.004,78.999 257.002,74.497 257.002,222.998 249.004,218.496 249.004,78.999 \" />");
    builder.append("<polygon points=\"128.501,9.497 128.501,0 257.002,74.497 249.004,78.999 128.501,9.497 \" />");
    builder.append("<polygon points=\"8.003,78.999 0,74.497 128.501,0 128.501,9.497 8.003,78.999 \" />");
    builder.append("</g>");
    builder.append("</svg>");
    view.getEngine().loadContent(builder.toString());


La différence principale ici est que l'appel à "WebEngine.load" a été remplacé par un appel à "WebEngine.loadContent".

Chargement d'un contenu dynamique


La méthode de chargement proposée est beaucoup plus crédible dans le cas d'utilisation considéré, mais elle présente encore un inconvénient majeur. Le contenu doit être regénéré et appliqué régulièrement pour tenir compte des modifications des paramètres de télémesure reçus en temps-réel. Le rechargement complet du SVG pose non seulement un problème de performance mais également de préservation du contexte d'affichage (par exemple si on souhaite permettre le zoom sur une partie de la vue synoptique).

Pour mettre à jour dynamiquement le contenu du moteur Web de JavaFX, la solution mise en oeuvre consiste à manipuler directement le document chargé via l'API DOM. Pour facilter la manipulation du contenu SVG, il pourrait être tentant d'utiliser la bibliothèque Batik. Une partie de l'API de cette bibliothèque est en effet dédiée à la manipulation du contenu SVG. Il est néanmoins difficile de créer les éléments SVG sans passer par une modélisation Java 2D. L'exemple de code ci-dessous est donc basé sur une utilisation directe du modèle DOM. Il trace un carré rouge dans un document SVG déjà chargé :

    // Get the document of the view and make it a SVG document
    Document doc = null;
    while (doc == null) {
        Thread.sleep(1000); // Ho, so ugly
        doc = view_.getEngine().getDocument();
    }
    String svgNS = SVGDOMImplementation.SVG_NAMESPACE_URI;
    Element svgRoot = doc.getDocumentElement();

    // Set the width and height attributes on the root 'svg' element.
    svgRoot.setAttributeNS(null, "width", "400");
    svgRoot.setAttributeNS(null, "height", "450");

    // Create the rectangle.
    Element rectangle = doc.createElementNS(svgNS, "rect");
    rectangle.setAttributeNS(null, "x", "10");
    rectangle.setAttributeNS(null, "y", "20");
    rectangle.setAttributeNS(null, "width", "100");
    rectangle.setAttributeNS(null, "height", "50");
    rectangle.setAttributeNS(null, "fill", "red");

    // Attach the rectangle to the root 'svg' element.
    svgRoot.appendChild(rectangle);


On notera que la récupération du document en début d'exemple est inscrit dans une boucle. La méthode WebEngine.getDocument renvoie "null" tant que le document n'est pas chargé et affiché.

Make it work, then make it fast


La viabilité de l'approche proposée dans un contexte opérationnel dépend en grande partie des performances de mise à jour d'un contenu SVG de taille raisonnable. Le test mené pour s'assurer que les performances seraient satisfaisantes consiste à charger un document SVG volumineux et à le modifier localement. Dans l'exemple ci-dessous, on charge un SVG représentant le réseau du métro parisien (pesant 1 Mo) et on modifie le nom et la couleur du nom d'une station.

    // Get the document of the view and make it a SVG document
    Document doc = null;
    while (doc == null) {
        Thread.sleep(1000); // Ho, so ugly
        doc = view_.getEngine().getDocument();
    }

    // Update the station "Gabriel Péri"
    Element gp = doc.getElementById("text6614");
    gp.setTextContent("Gabi Pery");
    String style = gp.getAttribute("style");
    style = style + ";fill:#ff0000";
    gp.setAttribute("style", style);


La récupération de l'élément à modifier se fait directement à partir de son identifiant. La modification du nom de la station consiste à mettre à jour le contenu de l'élément "text". La mise à jour de la couleur passe ici par un artifice consistant à suffixer le style avec le couleur à appliquer; le style comporte ainsi deux spécifications de couleur, la seconde l'emportant sur la première. Dans un cas réel, le style pourra être intégralement calculé pour éviter cet artifice.

En termes de temps de réponse:
  • L'affichage de la carte prend environ 3 secondes sur ma brouette,
  • Le renommage et le changement de couleur du nom d'une station semble instantané.
Cette expérience démontre donc qu'il est possible d'ajuster le contenu d'un synoptique volumineux sans le recharger.

Interactions


Si de nombreux systèmes se content de synoptiques passifs, il n'est pas rare de souhaiter interagir avec eux. La représentation visuelle d'un processus industriel, dans notre cas d'un élément de segment sol ou d'équipements bord, invite en effet à l'interaction: soit pour accéder à une information plus détaillée, soit pour modifier l'état du système. Cette dernière étape de maquettage a ainsi consisté à mettre en oeuvre des interactions avec un SVG intégré dans une application Java FX. Pour mon exemple, j'ai pris mon Inkscape préféré pour dessiner une jolie écluse. Objectif de mon essai : piloter mon écluse pour y faire passer des embarcations dans les deux sens... non, je ne suis pas allé jusqu'à modéliser l'embarcation, mais c'est tout à fait envisageable.

Au niveau du diagramme SVG:
  • Une indexation appropriée des éléments rend leur manipulation plus lisible depuis le code source JavaFX.
  • Sur les éléments que l'on souhaite rendre interactif, on déclare un handler d'événement. Dans mon cas, j'ai associé le clic souris à une méthode de l'objet "lock".

    onclick="lock.clickInternalDoor()"

Au niveau du code JavaFX, il est nécessaire d'associer l'objet JavaScript "lock" à un modèle de données Java. L'exemple de code ci-dessous illustre cette association:

    // Link the model and the view
    engine.setJavaScriptEnabled(true);
    JSObject window = (JSObject) engine.executeScript("window");
    window.setMember("lock", lock_);


Enfin, pour gérer les aspects dynamiques de l'écoulement de l'eau d'un bassin à l'autre lorsque les vannes sont ouvertes, un simple Timer suffit. Attention néanmoins à déléguer la prise en charge du rafraichissement du modèle à la boucle d'événements graphiques en appelant la méthode "Platform.runLater(lock_);" (le modèle de données "lock_" à rafraichir étant dans ce cas une implémentation de Runnable).

Pour les curieux qui voudraient voir le résultat final (digne des meilleurs jeux pour CPC 6128 qui ont bercé mon enfance), je peux transmettre le code source sur demande.

par Laurent COCAULT le 2015-04-07 06:35

Monday 30/03/2015

Laurent Cocault

Que ferez vous le 19 janvier 2038 ?

Les yeux de Carl, rougis par l'absence de sommeil, fixaient un écran de contrôle figé deux heures auparavant. L'alerte s'était produite vers 23h30 alors qu'il venait de se coucher. L'urgence était telle qu'il lui avait fallu moins d'une demi-heure pour revenir au centre de contrôle du télescope d'Arécibo. Les chaînes de traitements des messages du programme SETI-NG semblaient rompues au niveau L3 et plus aucun résultat consolidé ne venait alimenter le synoptique général du centre de traitement des données. La rupture s'était produite sur le traitement du résultat d'analyse de l'échantillon #2038-1434586 reçu par le centre à 23:13:59.557 heure locale, soit 03:13:59.557 heure GMT, le 19 janvier 2038.

Les premières analyses de Carl concluaient à un déroulement nominal des traitements de niveau L2 qui ne remontaient pas le moindre avertissement. Mais aucun traitement de niveau L3 ne semblait vouloir démarrer. Les résultats de niveau L2 semblaient tout simplement se volatiliser. Une analyse de l'archive des résultats intermédiaires fournit à Carl un début d'explication sur l'origine de la rupture. A partir de échantillon #2038-1434586, les traitements de niveau L2 demandaient à l'archive de classer les résultats produits dans un mauvais dossier ce qui mettait en défaut le mécanisme de déclenchement des traitements L3. Au lieu de les classer dans le dossier 2038-01-19, le traitement L2 demandait à classer les résultats intermédiaires dans le dossier 1901-12-13.

Le traitement L2 avait cette particularité d'avoir été le seul module intégralement récupéré du programme SETI original lors de sa restauration en 2032, après plusieurs années d'interruption faute de résultat significatif. Cette particularité se traduisait notamment par une procédure de compilation spécifique dont l'option "-m32" soulignait l'archaïsme à l'origine de la mauvaise soirée de Carl.

Pour les systèmes 32 bits, un entier long est représenté sur 4 octets (ou 32 bits): la valeur d'un entier non signé est ainsi limitée à environ 4 milliards (celle d'un entier signé, à environ 2 milliards). De telles valeurs n'ont rien d'astronomique et de nombreuses anomalies logicielles sont liées à ce dépassement de capacité. Le dernier exemple en date est certainement celui du compteur de vues sur YouTube qui a été joyeusement "explosé" par un tube sud-coréen que tout le monde connaît. Dans le cas des systèmes UNIX (et Linux), un tel risque de dépassement plane sur le système de datation. Les "time_t" UNIX représentent en effet une date sous la forme d'un entier signé correspondant au nombre de secondes écoulées depuis le 1er janvier 1970 (une convention certes un peu narcissique, puisque 1970 ouvre la décennie du développement d'UNIX, mais bien plus facilement compréhensible que la référence du 6 janvier 1980 utilisée par le GPS).

Vous l'aurez compris, avec une architecture 32 bits, le système de datation UNIX ne dépasse pas le mardi 19 janvier 2038 3h14m07 GMT. Passé cette date, le dépassement de capacité de l'entier représentant la date passe violemment de LONG_MAX à LONG_MIN; la date passe ainsi de 68 ans après la référence (ou “epoch”) à 68 ans avant la référence. Et nous voici revenus en 1901. Nom de Zeus !

Pour se convaincre de la réalité du problème, voici un court programme qui le met en évidence (pas besoin de DeLorean sur ce coup).

#include <limits.h>

#include <math.h>

#include <stdio.h>

#include <time.h>

int main(int argc, char** argv)

{

/* Current time */

time_t now = time(NULL);

printf("Current time is %s", ctime(&now));

printf("Current timestamp is %ld\n", now);

/* How big is a time_t ? */

printf("The size of a time_t is %d bytes\n", sizeof(now));

/* What about the max time ? */

time_t max = pow(2,31)-1; /* LONG_MAX en 32 bits */

printf("Maximum time is %s", ctime(&max));

printf("Maximum timestamp is %ld\n", max);

/* And after that ? */ time_t after = max+1;

printf("Next time is %s", ctime(&after));

printf("Next timestamp is %ld\n", after);

return 0;

}

Son exécution en 32 bits donne les résultats suivants:

Current time is Tue Mar 24 08:35:08 2015

Current timestamp is 1427186108

The size of a time_t is 4 bytes

Maximum time is Tue Jan 19 03:14:07 2038

Maximum timestamp is 2147483647

Next time is Fri Dec 13 20:45:52 1901

Next timestamp is -2147483648

On voit nettement le basculement de plus 136 ans en arrière. Mais la situation n'est pas désespérée puisqu'il suffit de compiler le code en 64 bits pour retrouver une situation tout à fait normale, illustrée par les résultats suivants:

Current time is Tue Mar 24 08:32:24 2015

Current timestamp is 1427185944

The size of a time_t is 8 bytes

Maximum time is Tue Jan 19 03:14:07 2038

Maximum timestamp is 2147483647

Next time is Tue Jan 19 03:14:08 2038

Next timestamp is 2147483648

Aucun problème donc, me direz vous. Pourtant le problème se pose aujourd'hui. L'illustration romancée de ce billet ne prend pas le contexte spatial par hasard. Dans ce contexte, la durée de vue de vie des logiciels est assez longue. Je pourrais parler de la ligne de produits ISIS ou de l'EGS-CC qui sont actuellement en cours de réalisation et qui doivent supporter des opérations pour les 30 prochaines années, bien au delà de 2038. Heureusement, l'EGS-CC part en Java dont la représentation des dates ne souffre pas du même problème (la référence est toujours le 1er janvier 1970, mais l'unité est la milliseconde et la capacité 64 bits... ce qui me laisse du temps avant d'écrire le même billet concernant Java). Et la ligne de produits ISIS est développée "from scratch" en 64 bits.

Il est bien évident que le problème se pose pour les logiciels qui sont développés à partir d'une réutilisation logicielle. J'ai personnellement pris conscience du problème en 2004 lorsque le CNES avait commandé le développement du gestionnaire de données de la mission CRYOSAT en réutilisant le gestionnaire de données de la mission ENVISAT. La taille des données manipulées dépassant les 2 Go (un peu plus de 2 milliards d'octets), il devenait impossible de les manipuler directement depuis un code compilé en 32 bits (la représentation des tailles de fichiers est également sensible au problème de dépassement de capacité). Une étude a donc été menée sur la faisabilité d'une migration de l'application en 64 bits. Cette étude a conclu à l'impossibilité de migrer, notamment pour des problèmes de support de librairies graphiques. Il n'est pas si aisé de migrer une application d'architecture, même si vous avez respecté la norme POSIX et que vous n'avez pas "casté" vos pointeurs dans des entiers (si si j'ai vu cette abomination... dans du code d'un concurrent, je vous rassure). Le gestionnaire de données de la mission CRYOSAT a ainsi été compilé en 32 bits et la manipulation des gros fichiers externalisée dans des modules compilés en 64 bits. Le logiciel correspondant tourne encore aujourd'hui et tournera pour encore quelques années.

Une pérennité de 20 ans est loin d'être exceptionnelle pour un centre de traitement de données. C'est généralement ce que nous demande le CNES (pour les centres de contrôles, ça peut être plus court dans la mesure où la durée de vie des satellites en orbite basse varie de 5 à 10 ans et que la durée de vie d'un centre de contrôle est liée à celle de la plate-forme). Autrement dit, les centres de traitement de données qui passeront le 19 janvier 2038 seront mis en exploitation en 2018. Si on considère le délai de développement et de qualification du centre, on peut parier que les premiers centres à voir la date fatidique seront développés cette année.

Alors tremblez ! Ou faites surtout attention à vos réutilisations logicielles et ne faites pas passer à Carl une si mauvaise soirée ;-)

par Laurent COCAULT le 2015-03-30 12:04

Monday 16/03/2015

Blog des Experts et Architectes CS

Neptune, Paris, 28 mai 2015 et ICSSEA, Paris 27-29 mai 2015

Cette année la journée NEPTUNE se déroule dans le cadre de la conférence internationale ICSSEA, 3 jours dédiés à l’ingénierie système et logiciel:

NEPTUNE 2015
L'ingénierie dirigée par les modèles ...

ICSSEA 2015
Sponsored by AFIS (the French Association for Systems Engineering and INCOSE ...


N'hésitez pas a diffuser l'information

par Agusti Canals le 2015-03-16 12:22

Thursday 26/02/2015

Blog des Experts et Architectes CS

Embedded France est l’association des représentants Français des logiciels et systèmes embarqués ....

Embedded France est l’association des représentants Français des logiciels et systèmes embarqués. Association loi de 1901, Embedded France est ouverte à tous les industriels fournisseurs et intégrateurs de systèmes et logiciels embarqués, ainsi qu’aux pôles et associations professionnelles représentatives de domaines intégrant des systèmes embarqués.

Embedded France a été créée en 2013 avec pour objectif de développer l’emploi dans la filière française des sytèmes et logiciels embarqués, et de contribuer à la compétitivité de la Nouvelle France Industrielle.

Un travail de fond a d’ores et déjà été entrepris depuis plusieurs années (Comité Embarqué de Syntec Numérique, Rapports Potier 1 & 2, Assises, BGLE, Projets des pôles, Club des Grandes Entreprises de l’Embarqué – CG2E -, etc.), et la filière a commencé à se structurer et à se doter d’outils communs. Les opportunités de développement de la filière sont nombreuses et tangibles, et sa contribution à la compétitivité de la France Industrielle est reconnue par les pouvoirs publics comme l’un des 34 projets de la « Nouvelle France Industrielle ».

....

par Agusti Canals le 2015-02-26 10:01

Monday 23/02/2015

Laurent Cocault

JSR-107

La conjonction d'un tweet de début de semaine dernière et d'une quantité inattendue de temps de cerveau disponible m'ont amené à découvrir la JSR-107 pour laquelle on voit régulièrement passer des tweets depuis un an. La version 1.0 de la spécification de JCache (JSR-107) a été officialisée en milieu d'année dernière et, avec elle, les premières implémentations certifiées conformes.

Justification

L'article tweeté par le twitterstream officiel de Java en début de semaine dernière justifie la JSR-107 en ces termes :

JCache (JSR 107) is a standard caching API for Java. It provides an API for applications to be able to create and work with in-memory cache of objects. Benefits are obvious – one does not need to concentrate on the finer details of implementing the Caching and time is better spent on the core business logic of the application.

La première question qui se pose est donc de savoir si l'adoption de JCache sur nos projets va effectivement nous faire gagner du temps. Autrement dit, gérons nous des mécanismes de cache sur nos applications spatiales ?

On est vite tenté de répondre positivement et pour étayer cette réponse, je suis tenté de revenir sur un système développé en 2010 pour lequel la problématique de gestion de cache avait pris une part significative de mon temps. Le projet IMIS (Instrument Monitoring Interactive Software) a été développé pour le CNES afin de superviser, dans un premier temps, les charges utiles des missions MSL (Curiosity), HY-2A et SARAL (missions d'altimétrie gérées au sein du segment sol SSALTO). L'architecture client-serveur spécifiée par le CNES permettait à un serveur de gestion de données du surveiller la télémesure instrument et de la délivrer aux postes clients sur le réseau CNES ou en dehors. Pour la partie cliente, les choix d'architecture étaient fortement guidés par la technologie retenue (Eclipse RCP), mais pour le serveur, j'avais jugé superflu de m'appuyer sur un serveur d'applications (j'ai toujours cette forte aversion pour la dépendance aux frameworks... ou bien suis-je trop souvent victime du NIH). Il fallait néanmoins adresser quelques problématiques de granularité des services et des fournisseurs de services qui ont abouti à la mise en place d'une architecture distribuée, orientée services et basée composants. Tirant les leçons des difficultés rencontrées sur la réalisation du centre de mission FFIORD en 2008, un effort a été consacré à la définition d'un conteneur de composants assez souple pour être géré sur une ou plusieurs JVM elles-même déployées sur une ou plusieurs machines physiques. Avec une architecture effectivement distribuée se pose vite la question de l'accès aux données générales du système, typiquement les paramètres de configuration généraux. Les accès récurrents à ces données ne peuvent être, pour des raisons de performances, systématiquement faits au niveau du support de persistance (en l'occurrence une base de données relationnelle dans le cas d'IMIS). Il n'en faut pas davantage pour que la notion de cache montre le bout de son nez. Mais les difficultés ne s'arrêtent pas là : puisque les données sont répliquées au sein des différents composants (ou au niveau des conteneurs), il faut en assurer la consistance et la cohérence. Par ailleurs dès que l'on considère des volumes de données conséquents (la base de données satellite SARAL pesant près de 20 Mo), l'empreinte mémoire des données doit être prise en compte et la durée de vie des objets en cache doit être considérée. En définitive, le temps consacré sur IMIS à la mise en place d'un mécanisme de cache distribué et synchronisé via JMX aurait peut-être pu être épargné et ainsi éviter au projet de boire une petite tasse.

Voyons maintenant si JCache aurait constitué une solution acceptable pour le projet IMIS (et pour nos futurs centre de contrôles et de mission).

Principes généraux

L'article mentionné ci-dessus définit JCache de la manière suivante :

The specification itself is very compact and surprisingly intuitive. The API defines high level components (interfaces) some of which are listed below:

  • Caching Provider – used to control Caching Managers and can deal with several of them,
  • Cache Manager – deals with create, read, destroy operations on a Cache
  • Cache – stores entries (the actual data) and exposes CRUD interfaces to deal with the entries
  • Entry – abstraction on top of a key-value pair akin to a java.util.Map}}

Il existe actuellement plusieurs implémentations de l'API JCache. Bien entendu Oracle propose une implémentation dans le cadre de Coherence. Il existe également une implémentation de référence fournie par les contributeurs de la JSR. Enfin les implémentations d'Hazelcast, Infinispan et ehcache ont suivi les dernières spécifications JCache. Pour mener quelques essais, j'ai choisi l'implémentation Infinispan (solution Red Hat) pour l'accessibilité des modules Maven, la documentation exploitable et l'absence, semble-t-il, de prosélytisme (qui est manifeste chez Oracle). Je suis persuadé que le choix d'Hazelcast serait tout aussi pertinent et que ces différents fournisseurs ne pourront véritablement se différencier que sur le long terme (sur des critères de qualité documentaire, de support, de performance et de sûreté de fonctionnement).

Découverte pratique de JCache

Après quelques essais, les points suivants concernant JCache méritent d'être soulignés:

  • Nécessité de sérialiser les données mises en cache. Par défaut, les données sont stockées dans le cache par valeur, ce qui signifie que toute modification sur l'objet après sa mise en cache n'altère pas le contenu du cache. Notons que l'implémentation Infinispan s'appuie sur les mécanismes de sérialisation des objets pour créer ces copies. C'est effectivement l'une des pistes que propose la JSR-107 qui recommande ainsi de généraliser l'adoption du mécanisme de sérialisation standard pour les clés et les valeurs. Si les valeurs ne sont pas sérialisables, une mise en cache par référence est également possible.
  • Dépendance vis-à-vis d’une implémentation. La résolution de l'implémentation JCache à utiliser à l'exécution est automatique lorsqu'un seul fournisseur est présent dans le classpath. Dans le cas contraire, une propriété de la JVM permet de résoudre l'ambiguïté. Il n'y a donc pas de dépendance directe entre le code Java développé et l'implémentation retenue. Il peut néanmoins exister quelques dépendances indirectes : si on reprend l'exemple précédent du stockage par valeur, Infinispan a fait le choix d'imposer que clé et valeur soit sérialisables pour rendre le mécanisme opérant; la documentation de Coherence indique au contraire que seuls les valeurs devant être stockées sur un cache partitionné doivent être rendus sérialisables. On peut donc courir le risque en développant une solution sous Coherence de s'apercevoir qu'elle ne fonctionne pas sous Infinispan à cause de la divergence de politique de sérialisation des valeurs.
  • Cache et Map. Dans une certaine mesure, l'API du cache ressemble à celle des map associatives de "java.util". On pourra néanmoins noter une petite différence au niveau de la méthode "put" qui dans l'API "java.util" retourne la valeur précédemment enregistrée avec la même clé alors que la méthode "put" de JCache est void. On trouvera un équivalent dans JCache avec la méthode getAndPut qui explicite ce mécanisme. Cette différence qui m'a frappé en utilisant l'API JCache n'est pas la seule et surtout pas la plus importante: un chapitre de la JSR-107 identifie les points communs et toutes les différences entre JCache et Map.
  • Cycle de vie des données. Une des fonctionnalités intéressante de l'API JCache concerne la gestion de l'expiration des données. Un exemple simple permet de définir une période d'expiration pour les données du cache en fonction de leur date de dernier accès ce qui, me semble-t-il, correspond à la politique la plus courante pour un cache. En revanche cette fonction n'a d'intérêt que si on peut détecter l'absence d'une valeur et la charger dynamiquement. Créer une surcouche au dessus d'un cache local pour l'alimenter en données lorsqu'elles viennent à manquer est une mauvaise option; il est préférable d'intercaler la source de données derrière le cache de manière à disposer d'un guichet unique d'accès aux données : le cache. JCache a naturellement prévu ce cas de figure et permet de définir des caches “Read-Through” et “Write-Through”. Un exemple simple d'implémentation d'un "CacheLoader" pour un cache en mode “Read-Through” laisse envisager la mise en place de n'importe quelle support de persistance derrière le cache. Notons que l'accès aux données par clé fait fortement penser aux API des bases NoSQL.
  • Manque de maturité des implémentations ? L'exemple de la mise en oeuvre du CacheLoader est assez symptomatique d'un manque de maturité des implémentations actuellement fournies. En effet, l'exemple de mise en oeuvre du CacheLoader ne fonctionne pas avec l'implémentation Infinispan alors qu'il fonctionne tout à fait avec celle de référence. En effet, l'implémentation Infinispan effectue bien un accès au CacheLoader lorsqu'une donnée a expirée ou n'a pas été préchargée, mais elle ne la rend pas accessible dans le cache.
  • Réplication des données. Un des intérêts majeurs d'une solution sur étagère est de disposer d'une solution gérant le cache de manière distribuée. Cette topologie est évoquée par la JSR-107 mais n'est pas imposée aux implémentations. Heureusement, les implémentations, qui ont pour la plupart vu le jour avant que la JSR ne soit finalisée, ont anticipé ce besoin et proposent effectivement une réplication de caches. L'exemple mis en oeuvre s'appuie sur la solution Infinispan et permet de disposer d'un cache distribué via JGroups sans qu'il soit nécessaire d'y introduire de spécificité, à l'exception du fait que le cache ne doit plus être créé par l'utilisateur mais simplement récupéré auprès du CacheManager qui aura au préalable été configuré pour pointer vers une URI de configuration dans laquelle le cache répliqué est mentionné.
  • Modèle événementiel. L'API JSR-107 prévoit également la possibilité d'associer des "listeners" aux caches de manière à réagir aux mises à jour de son contenu : ajout, retrait, modification ou expiration d'un élément. La déclaration du listener comporte quelques indirections programmatiques (définition d'une classe de configuration fournissant la fabrique permettant de créer les listeners) mais offre le degré de souplesse nécessaire permettant de réagir à un type d'événément particulier en spécifiant si on souhaite recevoir les anciennes valeurs et si on souhaite être notifié de manière synchrone ou asynchrone.
  • Performances. Côté performances, les quelques essais menés avec Infinispan ne sont certainement pas représentatifs avec ma brouette (AMD64 2GHz avec 1 GB de RAM) mais donnent un ordre de grandeur de ce qu'on peut attendre d'une solution de mise en cache. Lorsque les éléments sont insérés un par un, le temps moyen d'insertion est de l'ordre de 5 ms. Lorsque les éléments sont ajoutés par groupes de 100, le temps moyen d'insertion (par élément) est de l'ordre de 2 ms. Notons qu'au lancement de JGroups, des messages indiquent qu'une configuration système est souhaitable pour optimiser les performances. Il est donc probable que des essais approfondis devraient être menés sur le thème des performances, en comparant notamment les différentes implémentations disponibles.

Conclusion

Fonctionnellement, l'API JCache et ses implémentations auraient permis, dans le cadre du projet IMIS, d'éviter le développement des catalogues de configuration synchronisés. En l'état actuel des performances observées, il est en revanche plus difficile d'imaginer une utilisation pour un cache de télémesure. Par ailleurs, les doutes sur la conformité des implémentations (qui, rappelons le, ont été développées avant que la JSR soit officialisée) n’invite pas à se lancer tête baissée dans son utilisation. Mais compte tenu de ses apports indéniable, le recours à l’API JCache ne doit pas être exclue pour nos projets à venir.

La spécification de la JSR-107, son API et son implémentation de référence sont accessibles ici : https://github.com/jsr107/jsr107spec

par Laurent COCAULT le 2015-02-23 13:20

Blog des Experts et Architectes CS

Forum Méthodes Formelles: FMF5 16 Juin 2015 - Les méthodes formelles et les tests

Pôle AESE Pôle Minalogic

Forum Méthodes Formelles

Cycle de conférences

RTRA AESE/IFSE





Avant-propos

Les animateurs du DAS Systèmes Embarqués Electronique et Logiciel, avec le soutien du thème IFSE du RTRA AE/SE, ont le plaisir de vous annoncer la programmation d’un cycle de conférences techniques sur les méthodes formelles de développement. Non, ne partez pas tout de suite : les méthodes formelles sont faites pour vous ! Ces méthodes ne sont pas assez connues mais ont un potentiel énorme pour faire progresser la productivité ET la qualité intrinsèque des développements de logiciels embarqués et de leurs outils de développement et de vérification. Et elles ne sont pas si difficiles à mettre en œuvre : certains l’ont déjà fait, avec succès, pourquoi pas vous ? Nous vous proposons donc un cycle de conférence/forum pour vous présenter bien sûr les fondements théoriques de ces méthodes, mais surtout faire un état de l’art et de la pratique, démystifier, échanger, et pourquoi pas monter ensemble des projets pour “passer à l’acte” ? Les intervenants seront à la fois des scientifiques et universitaires les plus compétents dans ces domaines et des utilisateurs “de terrain” qui ont déjà pratiqué ces méthodes et vous livreront leurs retours d’expérience.

Programmation

Prochaine journée : FMF5 16 Juin 2015 - Les méthodes formelles et les tests (Programme à venir)
LAAS-CNRS Retransmis en direct à INRIA Grenoble et Saclay

Dernière journée : FMF4 2014/10/16 - Le model checking en action

Précédentes Journées (Présentations et vidéos)

Comité de programme

2015 : A.Canals (CS), F. Bustany (Systerel), N. Breton(Systerel), S. Duprat (Atos), H. Garavel (INRIA), G. Ladier (AerospaceValley), Y. Moy (Adacore), M. Pantel (IRIT), C. Paulin (LRI), G. Saint-Marcoux (Minalogic), P. Schnoebelen (LSV), J. Souyris (Airbus), F. Vernadat (LAAS-CNRS), V. Wiels (Onera).

Contact

par Agusti Canals le 2015-02-23 10:10

Friday 20/02/2015

Blog des Experts et Architectes CS

ICSSEA 2015: 26th International Conference on SOFTWARE & SYSTEMS ENGINEERING and their APPLICATIONS, Telecom ParisTech, Paris, May 27-29, 2015

Call for Papers

Web site : http://icssea.enst.fr (to be updated soon)

Sponsored by AFIS (the French Association for Systems Engineering) and INCOSE, co-organized by TELECOM ParisTech, and the Génie Logiciel quarterly, the 26th edition of the ICSSEA Conference (International Conference on Software & Systems Engineering and their Applications) will be held in Paris on May 27-29, 2015. By gathering actors from across the enterprise and research worlds, it aims at providing a critical survey of the status of tools, methods, and processes for elaborating software & systems.

TOPICS

As in previous ICSSEA Conferences, any topic in connection with software engineering and systems engineering is eligible.

• Architectures: composition, orchestration, semantically-enabled SOA, ontology-based technologies...

• Complex systems engineering

• Components & reusability

• Development methods: agile, lean, contract-oriented development, interfaces between cognitive sciences, neurosciences, knowledge management and engineering,…

• Distributed computing: service-oriented computing, grid services, Web services, mobile applications...

• Embedded systems

• Evolution: adaptability, maintainability, variability, product lines engineering...

• Information systems

• Management of functional and non-functional properties: analysis & design,representation, modeling, monitoring, composition, configurability, relationship with architecture, resolution of conflicts, aspect orientation, metrics for non-functional properties, semantic issues...

• Man-system interfaces: ergonomics, interaction, cognitive engineering…

• Model-Based Systems Engineering and Model-Based Software Engineering

• Open source issues: architectures for seamless integration/composition, quality assurance,

• Outsourcing issues

• Process engineering with different notations: UML, DoDAF, SysML, the MDA/MDE approaches…

• Project management: conventional methods, agile approaches…

• Quality control & assurance: quality assessment, testing, V&V...

• Quantitative evaluations: architecture, availability, performance, quality, reliability, safety...

• Requirements engineering: elicitation, V&V, modeling, natural language approaches, use of ontologies,…

• Software platforms specific of application domains

• Systems engineering and Systems of systems

• Web engineering: design,composition, control flow, user interface migration, discovery and selection of services, ontology engineering...

Original, unpublished papers are solicited. They may concern industrial implementations or experiments, describe significant results from ongoing projects, research results applicable to industrial applications, or deal with socioeconomic issues associated with software & systems engineering. Offerors may also propose tool demonstrations and posters presentations. All submissions should clearly describe the nature of the work to be presented, explain its contribution, highlight its novel features, and state precisely its current status.

All types of systems are eligible: adaptive, autonomous, context-aware, distributed, embedded, grid computing, mobile, real-time, service-oriented, ubiquitous, Web-based, etc. All end-user domains and economic areas are eligible: information systems, process management, automotive, avionics, banking, defense, energy, health care, insurance, space, telecommunications, transportation, etc.

INSTRUCTIONS TO AUTHORS

Submission and selection of proposed interventions will be conducted as follows:

1- Submit, before March 2, 2015,

- for industrial implementations and experiments, a text of at least 1000 words (about 5,000 characters, figures excluded), in English, including the title of the paper, an abstract of about 200 words, and the address, phone and fax numbers as well as the email address of the authors. If already available, a complete text (about 20,000 characters) would be welcome.

- For applied research results, a text not exceeding the equivalent of 20,000 characters in length (with figures included), in English, including the title of the paper, a 200-500 word summary, and the address, phone and fax numbers as well as the email address of the authors.

- For tools demonstrations and posters presentations, a text not exceeding 2 pages

2- Full papers or extended abstracts will be reviewed by at least three independent reviewers and selected by the International Program Committee.

3- Authors of accepted papers or extended papers will be notified by March 27, 2015 and will receive the recommendations made by the International Program Committee.

4- Authors of accepted abstracts or full papers should provide, before May 1rst, 2015, a text not exceeding the equivalent of 20,000 characters in length (with figures included), in the form of a file, in Word format, attached to an electronic message. Final texts will be submitted, for final checking, to the International Program Committee before publication in the Conference Proceedings, which will be available during the event.

5- At least one author is required to register and attend the conference to present the paper

Submission address: genie-logiciel@orange.fr

GENERAL CHAIRS
Agusti Canals (C-S)
Jean-Claude Rault (Génie Logiciel)

STEERING COMMITTEE
Erik Boasson – Consultant (NL)
Joseph K. DeRosa – Consultant (USA)
Vassilka Kirova – Alcatel-Lucent (USA)
Claude Y. Laporte – École de technologie supérieure (CDN)
Gérard Memmi – Telecom ParisTech (F)

INTERNATIONAL PROGRAM COMMITTEE

See Web site: http://icssea.enst.fr

 

__________________________________________________________________________

 

INFORMATION FORM

 

To be returned to:

Jean-Claude Rault

genie-logiciel@orange.fr

 

Last Name:.............................................................................

First Name:............................................................................

Organization: ........................................................................

E-mail: ……………………………………………………..

Telephone: …………………………………………………

Address:.................................................................................

...............................................................................................

...............................................................................................

 

(   ) is interested in ICSSEA 2015

(   ) wishes to be kept informed

(   ) intends to submit a paper

 

Tentative title:............................................................................................................

...................................................................................................................................

Short abstract (5-10 lines): .......................................................................................

...................................................................................................................................

...................................................................................................................................

Jean-Claude Rault
Génie Logiciel
8, rue du Parc
92190 Meudon, France

par Agusti Canals le 2015-02-20 08:50

Tuesday 16/12/2014

CS SI - E-SPACE & Geo Information

Support analyse de mission et mécanique spatiale pour CERES

Le service DCT/SB/MS du CNES est en charge des activités de mécanique spatiale pour la mission CERES. Les satellites assureront une capacité de renseignement d’origine électromagnétique (ROEM) spatiale : trois satellites volant en essaim localiseront et identifieront les signaux émis par les systèmes des forces ennemies (radars, télécoms …). La mission s’inspire de celle du démonstrateur ELISA.

La prestation de support à l’analyse de mission comprend les tâches suivantes. Support à :

  • l’analyse de l’évolution de l’orbite sous l’effet des perturbations,
  • la définition du maintien à poste,
  • la définition de la stratégie de Mise à poste et de retrait de service
  • l’établissement du bilan d’ergol
  • l’étude de précision de la connaissance de l’orbite extrapolée
  • l’analyse et définition d’orbites de référence
  • maquettage des algorithmes opérationnels éventuellement associés à ces études

Ces études pourront nécessiter des maquettages ou adaptations d’outils spécifiques d’analyse de mission pour les études correspondantes.

Les tâches relatives au support à définition, à la validation système du FDS et aux essais systèmes sont les suivantes. Support à :

  • la contribution à la définition des fonctions de mécanique spatiale et interfaces associées
  • la définition et description de contextes orbitaux pour les essais de qualification du système
  • l’instanciation du FDS avec ces contextes, exécution de ses fonctions, analyse des résultats obtenus, rédaction de rapports de validation

Le CNES a confié à CS cette prestation.

par Nancy Cevallos le 2014-12-16 10:58

Wednesday 10/12/2014

CS SI - E-SPACE & Geo Information

Support technique aux traitements SWIM

Les travaux s’inscrivent dans le cadre de la mission CFOSAT (China France Oceanography SATellite) actuellement en phase C/D au CNES.

CFOSAT est un satellite franco-chinois de mesure des vents de surface de la mer (instrument SCAT) et des vagues (instrument SWIM) dont le lancement est prévu en 2018 au plus tard, pour une durée de mission nominale de 3 ans.

Il s’agit d’une coopération entre les agences spatiales française (CNES) et chinoise (CNSA).

L’instrument SWIM (Surface Wave Investigation and Monitoring) développé par le CNES est un diffusiomètre à vagues, il est dédié à la mesure du spectre directionnel des vagues (hauteur, direction et période des vagues).

Le projet souhaite mettre en place un support technique au développement informatique des maquettes et des outils d’analyse et simulateurs associés.

CS a été retenu par le CNES pour réaliser cette prestation.

par Nancy Cevallos le 2014-12-10 14:40

Wednesday 03/12/2014

CS SI - E-SPACE & Geo Information

Système d’information cartographique « BD-RTM » sur les risques naturels en montagne

Le RTM (Restauration des Terrains en Montagne) est un service de l’Office National des Forêts (ONF) spécialisé dans le domaine des risques naturels, tant en matière de prévention (construction d'ouvrages de protection), que d’appui apporté aux responsables de gestion de crises.

Les services RTM ont, pour le compte de l’Etat et des collectivités locales, un rôle d’expertise et de conseil, réalisent des études, maîtrises d’œuvre et suivis d’ouvrages de protection.

Pour conserver et organiser la connaissance concernant différents volets des "risques naturels en montagne", l’ONF consigne depuis de nombreuses années toutes les informations dans des bases de données (BDRTM).

Les applications s’appuient actuellement sur des systèmes de gestion de BD et des outils de localisation géographique anciens.

Elles doivent être réorganisées et redéveloppées sous un système moderne et performant pour :

  • Faire de la nouvelle base de données un véritable outil de gestion pour les utilisateurs, et permettant d’étendre son périmètre d’utilisation à d’autres départements et d’autres utilisateurs.
  • Faciliter la saisie et l’accès aux données via une interface utilisateur de type web à l’ergonomie adaptée aux activités des utilisateurs.
  • Faciliter l’intégration des outils cartographiques dans la gestion opérationnelle des données.
  • Mettre à disposition des outils de saisie et de consultation des données RTM sur le terrain, facilitant la prise d’information cartographique et attributaire.
  • Adapter les procédures aux activités production, consultation d’information et validation des objets RTM, définies au niveau des services RTM (work flow).
  • Favoriser le développement des réseaux de compétence RTM.
  • Mettre en œuvre un outil plus facilement adaptable aux besoins de l’ONF et des usagers (évolutions des besoins techniques « métier », évolution des partenaires, des commanditaires).
  • Faciliter l’accès aux données et les restitutions aux commanditaires et partenaires des services RTM, acteurs de la gestion du risque.
  • Améliorer la performance de l’accès et du traitement des données.
  • Améliorer l’efficacité de l’administration des données par la mise en place d’une base centralisée, évolutive et ouverte.

CS a été retenu pour la mise en œuvre, maintenance et hébergement du système d’information cartographique web et mobile « BD-RTM ».

par Nancy Cevallos le 2014-12-03 09:48

Tuesday 02/12/2014

Monday 01/12/2014

Humeurs d'un libriste

Compression d'image VirtualBox

On m'a demandé de créer une machine virtuelle GNU/Linux avec un environnement pré-configuré. Cela m'a amené à installer de nombreux logiciels, à faire moult manipulations et, par effet de bord, à faire grossir sensiblement le fichier VDI (virtual disk image). La taille de ce fichier était in fine bien supérieure à l'espace consommé par mon système qui contenait en outre plein de scories que je pouvais supprimer. Voici donc ce que j'ai fait pour faire maigrir l'empreinte du système puis la taille du fichier VDI.

Suppression des logiciels inutiles

J'ai commencé par désinstaller tous les logiciels qui n'avaient aucune utilité dans le cas présent (Thunderbird, Gimp, Transmission, GMusicBrowser, etc.)

J'ai ensuite lancé « deborphan » pour identifier et supprimer les bibliothèques qui ne sont nécessaires à aucun des logiciels installés via les paquets. La suppression de bibliothèques en rendant d'autres inutiles, je préconise une utilisation récursive de deborphan jusqu'à épuisement de la liste.

Puis j'ai supprimé les fichiers de paquets stockés dans le cache d'APT (plus exactement dans « /var/cache/apt/archives/ ») via la commande « sudo aptitude clean » (bien utiliser « clean » et non « autoclean » qui supprime seulement les fichiers obsolètes).

Élimination des scories

J'ai ensuite monté une image ISO de SystemRescueCD dans le lecteur de CD-Rom de la machine virtuelle. Les partitions déclarées dans ma VM sont les suivantes :

  • /dev/sda1 : swap
  • /dev/sda2 : / (système Ext4)

Après avoir fait démarrer ma VM sur l'image SystemRescueCD, avoir choisi un clavier français et un démarrage en mode console, j'ai monté la partition racine de ma VM :

mount -t auto /dev/sda2 /media

J'ai ainsi pu supprimer :

  • les fichiers dans « /var/log » (attention, il est vivement recommandé de préserver l'arborescence) et dans « /tmp »
  • les fichiers et répertoires inutiles ou indésirables (genre historique bash) dans « /root » et « /home/user »

Pour la suite des événements, il faut démonter la partition :

umount /media

Écrasons le vide !

Quand on efface un fichier, les secteurs libérés ne sont pas réinitialisés. Or, pour un outil externe à la VM, rien ne distingue les secteurs libres des secteurs utilisés. Ce faisant, lorsqu'un outil de compression s'attaque au fichier VDI, il traite de manière égale tous les octets du fichier, alourdissant l'archive produite de données inutiles. Pour remédier à ce problème, deux mesures s'imposent :

  • Remplir l'espace inoccupé de « 0 » (rien ne se compresse mieux qu'une plage constante) sans pour autant détruire l'information utile et notamment la structure du système de fichiers.
  • Réduire le fichier VDI à sa portion congrue.

Plusieurs outils et astuces permettent de remplir l'espace libre de zéros. Dans le cas présent, recourir à « zerofree » est sans doute la meilleure stratégie car cet outil est rapide et n'engendre pas l'extension du fichier VDI :

zerofree -v /dev/sda2

Reste ensuite à réduire la taille du fichier VDI à sa portion congrue, ce que sait faire l'outil VBoxManage :

VBoxManage modifyvdi fichier.vdi --compact

Est-ce efficace ?

Ces mesures sont efficaces :

  • Mon fichier VDI originel occupait 6,8 Go et l'archive zip correspondante 4,8 Go.
  • Après l'application de ces différentes mesures, le fichier VDI est tombé à 3,8 Go et l'archive zip à 979 Mo !
  • À lui seul, le remplissage de l'espace vide par des zéros a fait fondre l'archive de 1,3 Go.

Les chiffres parlent d'eux-mêmes.

Mise à jour 2013-10-24

Le besoin s'étant derechef représenté, j'ai procédé de la même manière et voici les gains cette fois-ci :

  • Mon fichier VDI originel occupait 13,4 Go et l'archive zip correspondante 6,3 Go.
  • Après l'application de ces différentes mesures, le fichier VDI est tombé à 7,3 Go et l'archive zip à 3,3 Go !

Autre mise à jour utile, j'ai découvert entre temps un article intitulé « How to shrink a dynamically-expanding guest virtualbox image » dans lequel l'auteur propose une méthode toute simple pour pouvoir lancer zerofree (cet outil n'accepte de fonctionner que si les partitions cibles sont montées en lecture seule) :

  • Redémarrer la VM en tenant la touche Majuscule (Shift) gauche enfoncée lors du boot. Le menu de démarrage apparaît alors.
  • Sélectionner l'option « Recovery mode », puis dans le second menu, l'option « Drop to root shell prompt » puis saisir le mot de passe root. On se retrouve alors en mode « Single ».
  • Arrêter les services éventuellement lancés et susceptibles d'écrire sur les partitions (rsyslog, network-manager, etc.) ; dans mon cas, il n'y en avait aucun.
  • Remonter les partitions en lecture seule :

mount -n -o remount,ro -t ext3 /dev/sda1 /

  • Nettoyer l'espace disque :

zerofree -v /dev/sda1

par sdinot le 2014-12-01 22:32

Wednesday 15/10/2014

CS SI - E-SPACE & Geo Information

Développement et maintenance de l’ORFEO TOOLBOX pour la période 2014-2018

Le CNES a décidé dès 2005 de développer l'Orfeo ToolBox (OTB) pour préparer, accompagner et promouvoir l'utilisation et l'exploitation des images issues des systèmes Pléiades (PHR) et Cosmo-Skymed (CSK).

L’OTB est un ensemble de composants algorithmiques permettant de capitaliser le savoir-faire méthodologique et de tirer profit des résultats de recherche et R&D en analyse d’images d’observation de la Terre.

L’OTB est distribuée comme une bibliothèque Open Source d'algorithmes de traitement d'image écrite en langage C++, ainsi que d’applications et d’utilitaires qui sont construits en s’appuyant sur la bibliothèque.

Depuis maintenant 6 ans, l'OTB est utilisée par un nombre croissant d’utilisateurs, et devient progressivement l’une des références pour le développement de chaînes de traitement d'imagerie spatiale. Elle offre une palette très large d'algorithmes de base, de techniques d'état de l'art et de fonctionnalités avancées pour l'analyse des images, l’extraction d’informations et la production d'informations géographiques.

Parmi les perspectives pour les années à venir, une des transitions majeures est le passage d’un contexte mono-programme préparatoire à un contexte multi-programmes.

Par ailleurs, l’OTB est utilisée comme composant au sein de certains projets du CNES ou de l’ESA.

Enfin, il est important de rappeler que l’OTB est un logiciel libre qui est proche (et a besoin) de la recherche et des laboratoires pour être au plus près de l’émergence de nouvelles idées, voire les susciter.

CS a été retenu pour continuer le développement et la maintenance de l’OTB pour la période 2014 - 2018.

Voici d’autres contributions de CS autour de l’OTB :

par Nancy Cevallos le 2014-10-15 15:01

Tuesday 07/10/2014

CS SI - E-SPACE & Geo Information

DSI CNES : Portage et Optimisation de Codes

La Direction du Système d’Information du CNES offre aux projets et structures métiers du CNES, ainsi qu’aux laboratoires associés et aux industriels intervenant dans le cadre de projets CNES un service de calcul intensif. Ce service est sollicité pour diverses activités de type simulation numérique en phase amont des projets spatiaux et/ou du traitement opérationnel pour la phase d’exploitation.

Ce service s’appuie sur :

  • le « Service Traitement et Calcul », mise à disposition de moyens de calcul à hautes performances
  • le « Service Portage et Optimisation de Codes », assistance au développement, à l’optimisation, à la parallélisation et à l’utilisation de logiciels efficaces sur ces moyens.

L’assistance est basée sur l’expertise en calcul scientifique du service DSI/DV/AR épaulé par une prestation assurée depuis 2008 par CS qui a été renouvelée.

Les principaux objectifs de la prestation sont :

  • Porter les codes de calcul précédemment utilisés sur d’autres moyens et destinés à être utilisés sur le service de calcul intensif.
  • Optimiser et paralléliser les codes de calcul utilisés sur les moyens de calcul intensif.


par Nancy Cevallos le 2014-10-07 09:40

Tuesday 30/09/2014

CS SI - E-SPACE & Geo Information

LETNA : Traitement OCAM-G

La télémesure OCAM-G (Online CAMera-Gnss) est une télémesure générée par la VCTM (Video compression TM) de l’OEU (Ocam Electronic Unit) et transmise au sol via la S-bande. Quatre caméras placées sur la partie haute du lanceur filment les phases critiques du lancement (décollage, séparation d’étages, largages,…). Cette TM achemine les images prises par les caméras, mais aussi des informations appelées « Payload » issues de récepteurs GNSS embarqués. Enfin des mesures sur le fonctionnement du dispositif complètent  les informations transmises au SOL.

Le système OCAM a été conçu pour être mis en place sur toute la gamme des lanceurs exploités par ARIANESPACE (ARIANE5, VEGA et SOYOUZ).

Dans le cadre du projet ARIANE5-ME, l’ESA a confié au CNES (DLA/SDS) l’industrialisation du système SOL OCAM-G afin de pérenniser l’exploitation de la Télémesure, l’archivage et la mise à disposition des données (mesures, données GNSS, images, rush vidéo).

De plus, dans un objectif de qualification des données GNSS OCAM, une station de référence équipée de récepteurs GNSS étalonnées a été mise en place sur le site de Galliot afin de recueillir des données lors de la première partie du lancement. Celles-ci sont acheminées au CTTM afin d’être traitées et ainsi de permettre aux spécialistes de valider les données GNSS issues du lanceur grâce à la confrontation de données de différentes sources.

Cette prestation apporte des évolutions mises en œuvre au CTTM (Centre de traitement de Télémesure au sein du service DCT/ME/NC) et en particulier sur le système LETNA pour traiter l’ensemble de la TM OCAM-G. L’objectif final était de produire les rushes vidéo et les mesures de la PayLoad pour le vol ARIANE5/ATV5 effectué le 29 Juillet 2014.

CS a été retenu pour réaliser cette prestation.

par Nancy Cevallos le 2014-09-30 09:02

Thursday 25/09/2014

CS SI - E-SPACE & Geo Information

Sentinel 2 Toolbox

ESA is developing six new missions called Sentinels. The first three of the Sentinels will be launched in the time frame 2014/2015 and will carry radar and multi-spectral imaging instruments for the monitoring of land and ocean surfaces in response to the operational needs of the Global Monitoring for Environment and Security (GMES)/Copernicus programme.

The objective of this project is to develop an open-source, flexible and re-usable scientific multi-mission Toolbox based on an extension of BEAM, facilitating the handling, post-processing and scientific analysis of the data products from the Multi-Spectral Instrument (MSI) of the Sentinel-2 mission.

The S-2 Toolbox shall further:

  • integrate the Level-2A processor,
  • include a tool for converting Level-1C reflectance into radiance,
  • support a large set of multi-spectral imaging sensors.

CS is leading a consortium composed of CS France and Romania, Brockmann Consult Germany, Telespazio Vega Germany, INRA France and UCL Belgium.

par Frédéric Andraud le 2014-09-25 14:11

Tuesday 23/09/2014

Guilhem Bonnefille

Normaliser les fichiers XMI pour suivre leurs évolutions sous Git

Sur le projet actuel, nous utilisons XMI (format de stockage de la technologie EMF d'Eclipse) pour sérialiser des données. Or, pour gérer les références internes entre les données, XMI utilise naturellement des ID. Et, toujours bien naturellement, ces ID évoluent parfois, sans que cela reflète un changement dans le contenu, simplement EMF a du générer de nouveau ID pour les mêmes données. Et comme de bien entendu, lorsqu'on consulte les diff dans de telles situations, l'information utile est noyée au milieu du bruit.

Heureusement, Git permet d'associer des commandes sur certains types de fichier afin de les pré-traiter avant de calculer un diff pour l'utilisateur. Initialement, cette commande est prévue pour s'appliquer à des fichiers binaires afin d'extraire des informations qui peuvent néanmoins présenter un intérêt pour l'utilisateur. Ici, bien que le format XMI soit textuel, je vais quand même le pré-traiter pour le normaliser c'est à dire retirer tout ce qui est susceptible de changer sans que cela présente un intérêt à mes yeux.

Je crée donc un script normalize-xmi.sh (sans oublier de le rendre exécutable)

#!/bin/sh
sed -e 's/xmi:id="[^"]*"/xmi:id=""/' -e 's/xmi#[^"]*"/xmi/g' -e 's/="_[^"]*"/=""/g' "$@"

Je référence ce script dans un filtre dans .git/config

[diff "xmi"]
	textconv = /chemin/normalize-xmi.sh

J'associe ce filtre aux fichiers XMI dans .git/info/attributes

*.xmi	diff=xmi

A partir de maintenant, chaque commande qui produira un diff de XMI à l'attention de l'utilisateur prendra un poil plus de temps, mais me permettra de me focaliser sur des changements de contenu.

par Guilhem Bonnefille le 2014-09-23 14:58

Wednesday 03/09/2014

CS SI - E-SPACE & Geo Information

Evolution du logiciel TerreImage et classification associée

CS a développé l’outil TerreImage et son plugin QGIS en 2012 pour les besoins de l’Education Nationale.

TerreImage est un logiciel de visualisation d’image et de réalisation de traitement permettant d’afficher et de naviguer simplement dans une image satellitaire, de lancer des algorithmes de traitements, et d’exporter l’image et les résultats de traitement sous forme d’un projet QGIS et d’un fichier KMZ pouvant être ouvert dans Google Earth.
Le plugin QGIS permettant, directement depuis QGIS, de réaliser une classification supervisée d’image.
Ces outils vont être améliorés en conservant une optique d’initiation au traitement d’image par des utilisateurs jeunes et non experts.

Les sciences basées sur l’observation de la terre sont en plein développement et offrent la possibilité de mettre en avant certaines problématiques auprès du corps enseignant. Ces outils vont être améliorés en conservant une optique d’initiation au traitement d’image par des utilisateurs jeunes et non experts.


par Nancy Cevallos le 2014-09-03 15:38

Tuesday 22/07/2014

Aurélien Tisné

Archivage de mails

Comment archiver une arborescence de mails ?

J'ai du mal à jeter.

Au bout de quelques années, il est très probable que je n'aurais plus besoin de revenir sur certains mails. Mais, je me dis qu'une information que j'ai jugée utile de conserver à un moment donné a forcément une certaine pertinence, même émoussée. Et j'ai du mal à jeter.

Donc, il faut archiver.

Mais comment archiver des boites mails ? Au format natif, certe. Mais ce n'est pas pratique. Car, si l'on conserve une information, c'est forcément avec l'objectif de pouvoir la retrouver si l'on en a besoin. Il faut, dans ce cas, être sûr d'avoir un client capable de comprendre ce format et remettre l'information dans le périmètre de l'outil. Un format de type texte serait plus pratique. Car facile a lire pour bon nombre d'outils et facile à rechercher. HTML est un bon candidat :

  • il bénéficie d'une pérennité sans faille,
  • il permet de mettre en forme,
  • il permet une navigation facile.

Voici donc le choix que j'ai fait pour archiver d'anciens répertoires de mails.

J'ai choisi l'outil hypermail [http://www.hypermail-project.org/]. Cet outil permet de convertir des boites mails au format mbox vers des pages HTML, en conservant, notamment, les pièces attachées et les fils de discussion. [http://en.wikipedia.org/wiki/Hyperm...]

Un petit script pour faire de la conversion récursive de répertoires de mails et pour créer des pages d'index. Et le tour est joué.

  • On commence par télécharger la dernière version de l'outil http://www.hypermail-project.org/hy...
  • On compile l'outil : voir hypermail/INSTALL
  • On récupère le script d'encapsulation pour hypermail
  • Récupérer l'arborescence de mails, au format mbox, à convertir. On l'appellera <source folder>. (Avec Thunderbird, ~/.your/mail/profile/Mail/Local Folder.)
  • Lancer le script de conversion mbox2html <source folder> <target folder>. Il génère <target folder>.

Consulter le fichier <target folder>-index.html comme point d'entrée.

On peut s'amuser avec les options d'hypermail.

  • Lancer hypermail -v > ~/.hmrc pour générer le fichier de configuration par défaut
  • Puis modifier les options dans ce fichier

A noter que l'on peut ajouter un moteur de recherche plein-texte à l'archive générée. Voir http://www.hypermail-project.org/hy....

Bon archivage.

par atisne le 2014-07-22 11:10

Wednesday 09/07/2014

Blog des Experts et Architectes CS

Club 27001

Pour info, Jacques SUDRES (Expert CS N3 sur le thème de la sécurité des SI) a été élu comme co-animateur avec Claire Albouy Cossard du Club 27001 de Toulouse.

Pour rappel Jacques a obtenu le 23 mai 2012 une attestation de réussite à l'examen ISMS Risk Manager ISO/CEI 27005, Il est donc “Risk Manager”  et en 2011 une attestation de réussite à l'examen ISMS Lead Auditor ISO 27001, Il est donc également “Provisional Auditor”

Pour en savoir plus n’hésitez pas à le contacter

par Agusti Canals le 2014-07-09 16:07

Tuesday 08/07/2014

Blog des Experts et Architectes CS

Forum Méthodes Formelles Cycle de conférences: "Le Model-Checking en action" : Jeudi 16 Octobre 2014

Les animateurs du DAS Systèmes Embarqués Electronique et Logiciel, avec le soutien du thème IFSE du RTRA AE/SE, ont le plaisir de vous annoncer la programmation d’un cycle de conférences techniques sur les méthodes formelles de développement. Non, ne partez pas tout de suite : les méthodes formelles sont faites pour vous ! Ces méthodes ne sont pas assez connues mais ont un potentiel énorme pour faire progresser la productivité ET la qualité intrinsèque des développements de logiciels embarqués et de leurs outils de développement et de vérification. Et elles ne sont pas si difficiles à mettre en œuvre : certains l’ont déjà fait, avec succès, pourquoi pas vous ? Nous vous proposons donc un cycle de conférence/forum pour vous présenter bien sûr les fondements théoriques de ces méthodes, mais surtout faire un état de l’art et de la pratique, démystifier, échanger, et pourquoi pas monter ensemble des projets pour “passer à l’acte” ? Les intervenants seront à la fois des scientifiques et universitaires les plus compétents dans ces domaines et des utilisateurs “de terrain” qui ont déjà pratiqué ces méthodes et vous livreront leurs retours d’expérience.

Pour en savoir plus: http://projects.laas.fr/IFSE/FMF/ 

par Agusti Canals le 2014-07-08 13:48

Monday 30/06/2014

CS SI - E-SPACE & Geo Information

Tierce Maintenance Applicative des applications VIP, VPDS et outils VIP du segment sol Venµs

L’objet de cette prestation est la maintenance du centre de traitement et de programmation Venµs Image Processing (VIP) et du serveur de distribution Venµs Product Data Server (VPDS) de la mission spatiale franco-israélienne Vegetation and Environment monitoring on a New Micro Satellite (Venµs).

Les objectifs de Venµs sont doubles :

  • La mission scientifique menée par le CNES a pour objectif la réalisation d’acquisitions haute résolution, multi-spectrales et multi-temporelles à haut taux de revisite, sur des sites présélectionnés pour leur intérêt dans divers domaines applicatifs (agriculture, foresterie, études atmosphériques, etc.)
  • La mission technologique, menée par Israël, a pour objectif de démontrer les capacités du propulseur IHET (Israeli Hall Effect Thruster).

Le segment sol de la mission scientifique, dont font partie le VIP et le VPDS, est géré par le CNES. Le développement industriel, démarré en 2007, a marqué une pause du fait de l’incertitude sur le lanceur. Ainsi les composants VIP et VPDS ont été mis en cocon à la fin de leur période de garantie en attendant de connaître le planning du lancement. En décembre 2013, un accord de lancement a finalement été signé avec une date d’échéance entre octobre 2015 et décembre 2016. Le développement du segment sol est donc reparti.

Dans le cadre de ses objectifs scientifiques, la mission Venµs assurera la couverture de près de 100 sites, représentatifs des principaux écosystèmes terrestres et côtiers, observés sur 12 bandes spectrales du visible au proche infrarouge, avec une répétitivité de deux jours.

VENµS est un micro satellite placé en orbite héliosynchrone à une altitude nominale de 720 km dans une première phase dédiée principalement à la mission scientifique. Dans une seconde phase, le satellite sera descendu jusqu’à 410 km pour les objectifs de la mission technologique.

par Nancy Cevallos le 2014-06-30 09:58

Monday 05/05/2014

CS SI - E-SPACE & Geo Information

Preparation and Operations of the Mission Performance Centre (MPC) for the GMES Sentinel-2 Mission

The GMES (Global Monitoring for Environment and Security) programme is an European initiative for the implementation of information services dealing with environment and security, based on observation data received from Earth Observation (EO) satellites and ground based information [http://www.gmes.info].

The GMES Service Component is responsible for the provision of value-added information data and services to the GMES final users while the GMES Space Component (GSC) is in charge for providing the necessary EO data and services to the GMES Service Component.

Within this context, ESA is responsible in particular, for the implementation of the GMES Sentinel missions, feeding the GMES services with operational EO data [http://www.esa.int/gmes].

The GMES Sentinel-2 optical imaging mission will be devoted to the operational monitoring of land and coastal areas. This system will deliver a new generation of optical data products designed to directly feed downstream services related to land monitoring, emergency management and security.

The Mission Performance Centre (MPC) for the GMES Sentinel-2 is a service-based contract covering all activities from the preparation of the site for hosting equipment, to the service and expertise provision during mission commissioning and operational phases.

par Nancy Cevallos le 2014-05-05 14:36

Monday 28/04/2014

CS SI - E-SPACE & Geo Information

Etude du Contenu Informationnel des images Pléiades

L’expérimentation de choix de l’algorithme de fusion P+XS menée par le CNES durant la recette en vol Pleiades 1A, a permis de montrer que de nouvelles mesures et approches pouvaient être utiles pour qualifier le contenu des images et évaluer leur qualité.

Ces mesures et méthodes s’appuient sur la théorie de l’information, la théorie de la complexité, la décomposition des données selon différentes critères, entre autres. A ce titre, elles donnent une importance particulière à l’analyse statistique ou probabiliste des données. Leur intérêt est qu’elles mettent en évidence certaines caractéristiques non facilement perceptibles par l’œil ou même mesurables avec les outils classiques d’analyse d’images.

Le CNES a la volonté de développer cette approche qui offre une nouvelle vision sur un système imageur et sur les produits qu’il délivre, en essayant d’évaluer l’utilisabilité des produits et donc des informations qu’ils contiennent.

Cette approche dénommée "évaluation du contenu informationnel des images" a pour objectifs :

  • Évaluer l’information contenue dans les produits,
  • Déceler d’éventuelles anomalies ou comportements non prévus,
  • Contribuer à la sélection des paramètres optimaux des chaînes de production,
  • Vérifier que les produits présentent des contenus conformes aux objectifs de la mission.

L’objet de cette étude est de développer cette approche en complétant les premiers résultats issus de l’expérimentation de la fusion mentionnée ci-dessus, pour d’autres types de produits, et en s’orientant davantage sur les aspects fonctionnels des produits.

Pour cela, des mesures diverses seront mises en œuvre sur différents produits Pleiades ainsi que pour différentes finalités applicatives.

CS a été choisi pour réaliser cette étude.

par Nancy Cevallos le 2014-04-28 07:57

Tuesday 22/04/2014

CS SI - E-SPACE & Geo Information

Tierce Maintenance de MACCS

CS a été retenu par le CNES pour réaliser la Tierce maintenance applicative de l’outil MACCS (développé par CS).

La chaîne MACCS (Multi-mission Atmospheric Correction and Cloud Screening) est un logiciel multi missions de correction atmosphérique. Il permet la génération des produits de niveau 2 et rassemble plusieurs traitements.

Cette chaîne, initialement développée pour le segment sol VENµS, est aujourd'hui devenue une chaîne multi-capteur capable de traiter des produits de niveau 1 issus de missions différentes telles que VENµS et Formosat mais aussi Sentinel-2 et Landsat (données mises au format Formosat).

Le projet MACCS s’inscrit également dans un contexte multi-projet et sera déployé dans divers centres opérationnels.

C'est dans ce contexte à la fois multi-capteur et multi-utilisateur que le projet MACCS entre dans le cadre d'une "Tierce Maintenance Applicative" permettant de maintenir et faire évoluer des versions différentes en fonction des besoins des utilisateurs.

par Nancy Cevallos le 2014-04-22 14:26

Wednesday 16/04/2014

CS SI - E-SPACE & Geo Information

EARTHLAB : un outil pour l’avenir

Afin de dynamiser le développement des applications spatiales au sein des collectivités locales et régionales, le groupe Telespazio, leader mondial des services spatiaux, a souhaité créer en France un centre pilote de production de services intégrés de Géo-Information appelé EarthLab.

En articulation avec le programme GMES (Global Monitoring for Environment and Security) de l’Union Européenne et de l’Agence Spatiale Européenne, et en application de la directive INSPIRE et de la circulaire PRODIGE, ce centre pilote EarthLab est considéré au sein de la communauté du spatial comme le chaînon manquant des services spatiaux pour la surveillance de l’environnement.

Il a pour vocation de développer et mettre en œuvre les concepts, méthodes et outils permettant la surveillance intégrée et collaborative de l’environnement aux échelles régionales et locales. Leur ambition est ainsi de définir et de garantir le développement de services opérationnels répondant aux réels besoins des utilisateurs finaux.

Il est composé de plusieurs systèmes offrant :

  • Une capacité de réception directe des principaux satellites d’observation de la terre, notamment les dernières générations fournissant de l’imagerie à très haute résolution,
  • Un centre pilote sécurisé de traitement et fusion de l’imagerie spatiale et drones, des données de géo-localisation et de capteurs in-situ d’environnement,
  • Un espace ouvert dédié à l’innovation,
  • Un programme d’accompagnement des activités de recherche appliquée ou fondamentale conduites par les laboratoires publics, en tant que partenaires du projet.

Le centre EarthLab est le premier centre opérationnel intégré de surveillance de l’environnement aux échelles régionales et locales.

CS vient de livrer avec succès début avril sa contribution au programme Earthlab.

par Nancy Cevallos le 2014-04-16 09:25

Tuesday 18/03/2014

Guilhem Bonnefille

Survivre à des remaniements de dossier avec Git

Encore une fois, Git m'a sauvé la vie.

Dans le projet sur lequel je travaille, il y a beaucoup de code généré, ce qui fait que la totalité de ce code peut varier d'un coup pour quelques broutilles. Ce code est échangé entre le client (qui nous génère le code) et nous via un SVN. Récemment, le client a dû rajouter un dossier au premier niveau pour mieux organiser les différents ensembles de code générés.

Entre des micro changements un peu partout dans le code suite à l'évolution du modèle et du code généré et un changement de l'arborescence, autant dire que ça commence à devenir compliqué de demander à un outil de gestion de version de faire une synthèse pour identifier les nouveaux fichiers.

Heureusement, Git est là (oui, je passe par Git pour accéder à SVN).

Avec la commande :

git diff 79ab325..f52477e --name-status --find-copies-harder

Git arrive à trouver quelques similitudes entre les versions de fichiers, mais ce n'est pas suffisant.

Mais la commande :

git diff 79ab325 f52477e:./CPCC --name-status

Permet de demander à Git de faire la comparaison entre deux états différents et en recalant les arborescences comparées tout en réduisant à une synthèse sur chaque fichier (juste Modifié, Ajouté, Supprimé).

Git POWA !!!

par Guilhem Bonnefille le 2014-03-18 18:21

Tuesday 04/03/2014

CS SI - E-SPACE & Geo Information

Etudes de physique de la mesure et d'étalonnage des capteurs en orbite 2013/2014

CS a été retenu par le CNES pour réaliser la suite des travaux de l’étude d’étalonnage des capteurs optiques en orbite 2011/2013 (voir l’article).

Le service « Physique de la Mesure Optique » du CNES développe des méthodes spécifiques d’étalonnage sur cibles terrestres et gère une base de données multi-capteurs.

Le principe de l’étalonnage sur cibles terrestres est de disposer d’une cible au sol suffisamment bien caractérisée afin de prédire la mesure d’un capteur sur cette cible. Il est également nécessaire de connaître les caractéristiques de l’atmosphère qui vont avoir un effet important sur la mesure réalisée.

Le présent marché, pour la période 2013/2014 concerne les lots 4 et 5 décrits ci-dessous. CS participe à la réalisation des activités d’étalonnage.

Le lot 4 rassemble les activités des tâches suivantes, relatives à des études de Physique de la mesure pour la modélisation des observations spatiales :

  • Tâche 9 : Exercice d’inter-comparaison de codes de transfert radiatif,
  • Tâche 10 : Génération opérationnelle des LUT pour l’étalonnage nuage,
  • Tâche 11 : Absorption dans le code de transfert radiatif SOS,
  • Tâche 12 : Choix de la bande red-edge pour la mission CXCI.

Le lot 5 comprend la tâche 13 : Synthèse des étalonnages VEGETATION.

par Nancy Cevallos le 2014-03-04 13:38

Friday 28/02/2014

CS SI - E-SPACE & Geo Information

Maintenance et évolutions du Système d’Information sur l’Eau Rhin-Meuse (SIERM) 2013-2016

CS a été retenu pour réaliser la suite des travaux SIERM 2010/2013 (voir l'article).

La tranche de travaux de maintenance 2010/2013 réalisé par CS avait pour objectif la consolidation des outils mis en place et l’ouverture du système au sein du SIE national via la mise en place de Web Services.

Le présent marché de maintenance, pour la période 2013/2016, a pour objectif de consolider les travaux effectués en 2010/2013, mais également :

  • d’offrir de nouvelles fonctionnalités (ex : fiches de synthèse)
  • de pousser encore plus loin l’intégration du SIERM/SIE national en ouvrant le SIERM aux données d’autres portails thématiques en utilisant leurs Web Services.

Afin de répondre aux enjeux du projet, voici les points forts de CS, tous orientés vers la maintenance d’un portail robuste, efficace et interopérable :

  • Le département Applications de CS s’est structuré ces dernières années en créant une cellule Eau Environnement et Risques. L’équipe CS travaille sur SIERM depuis plus de 6 ans, et en maîtrise toutes les fonctionnalités, tant en termes de connaissances métiers que de compétences techniques.
  • CS a réalisé 3 portails d’accès à l’information sur l’eau pour les Agences Adour-Garonne, Loire-Bretagne et Rhin-Meuse. Par ailleurs, CS travaille régulièrement avec des institutionnels du domaine de l’eau, et notamment l’Office National de l’Eau et des Milieux Aquatiques (ONEMA), un des partenaires de l’Agence de l’Eau Rhin-Meuse (AERM).
  • L’expérience passée par CS sur le projet BERM, puis SIE et enfin SIERM a permis de bien connaître les différents interlocuteurs de l’Agence et garantir ainsi une continuité de service des systèmes BERM et SIE pendant 15 ans, entre 1998 et 2013.

par Nancy Cevallos le 2014-02-28 17:42

Monday 22/07/2013

CS SI - E-SPACE & Geo Information

SUPPORT A LA PREPARATION ET AUX OPERATIONS DU RESEAU DE STATIONS MULTIMISSION DU CNES

Dans la sous-direction Opérations du CNES, le service OP/SR est responsable de la mise en oeuvre du réseau 2 GHz du CNES dans le cadre des projets du CNES mais aussi pour le compte de partenaires externes comme Astrium, Eutelsat, DLR, ESA. Le Service OP/SR a en charge l’ensemble des opérations du réseau 2GHz, à ce titre :

  • Il opère les stations du réseau CNES depuis le COR (Centre d’Opérations Réseau). Les opérations station sont automatisées via le système de télégestion Regates.
  • Dans le cadre des activités de préparation des opérations de mise à poste, l’équipe OP/SR a en charge l’ensemble des essais de niveau réseau et apporte un support aux projets pour les essais système.
  • Il participe aux grands chantiers de rénovation du réseau de stations en tant que futur utilisateur : intégration dans les spécifications des contraintes opérationnelles, suivi du développement, mise en oeuvre des moyens réseau dans le cadre de la qualification technique, formation du personnel opérationnel, définition et mise en oeuvre de la qualification opérationnelle , et enfin mise en exploitation.

CS intervient dans 3 contextes différents :

  • La qualification et la mise en exploitation des composantes de CORMORAN
  • La mise à jour du référentiel documentaire du réseau
  • Le support à la qualification du réseau, puis la participation aux opérations menés par le service.

par Frédéric Andraud le 2013-07-22 15:30

Wednesday 17/07/2013

CS SI - E-SPACE & Geo Information

3MI calibration stydy for Eumetsat

Key elements of the study are to develop consistent level 1 processing steps for 3MI building on POLDER/PARASOL calibration functions. New properties of 3MI have to be taken into account, e.g. the expected spectral range especially to the short-wave infra-red (SWIR), two optical heads, and improved spatial resolution. This will impact the calibration of 3MI and therefore need a review of the pre-launch characterisation parameters, the in-flight calibration integrating the re-sampling issues and furthemore unexpected parameters that could be induced through the new capabilities of the 3MI and synergy with the other instruments flown on the same satellites of the EUMETSAT Polar System Second Generation (EPS-SG).

par Frédéric Andraud le 2013-07-17 15:18

Monday 15/07/2013

CS SI - E-SPACE & Geo Information

Caractérisation de la polarisation instrumentale en vol pour le CNES

L’objectif de cette action R&T est d’étudier l’impact de la polarisation des scènes observées sur les mesures réalisées par les capteurs optiques. Son objectif final est de concourir à l’affinement des spécifications de caractérisation de la polarisation, en phase de conception instrumentale et pour la caractérisation du modèle radiométrique des instruments. L’étude portera aussi largement sur la sensibilité à la polarisation des capteurs non polariseurs à travers le cas des mesures VEGETATION. Avec l’émergence d’une exploitation physique fine des mesures des capteurs géostationnaires (MSG, MTG), l’analyse de l’impact de la polarisation sur ce type d’instrument est également importante. C’est aussi le cas pour l’exploitation des mesures des instruments hyperspectraux, avec la spécificité d’un besoin de bien maitriser la réponse inter-bandes pour permettre une exploitation physique correcte des acquisitions. Cette action portera un intérêt également pour la mission MicroCarb à spectromètre imageur. MicroCarb réalisera des visées du glitter (réflexion spéculaire sur mer, donnant une cible brillante sur une surface marine sombre) pour estimer le contenu de l’atmosphère en gaz carbonique. Cette cible étant fortement polarisante, il est essentiel de bien maitriser l’impact de la polarisation sur les mesures, pour la finesse de l’estimation du contenu en CO2. Enfin, cette action pourra s’avérer utile pour la validation en vol de la caractérisation sol de la polarisation des instruments. Elle débouchera sur des recommandations pour la caractérisation de la polarisation instrumentale par l’exploitation des mesures existantes et sur la définition de configurations d’observation opportunes, généralisée aux systèmes spatiaux émergeant (Spot6, Pleiades, …) ou plus anciens mais toujours en vol (MODIS, …).

par Frédéric Andraud le 2013-07-15 15:09

Wednesday 12/06/2013

CS SI - E-SPACE & Geo Information

Support pour le simulateur CXCI pour le CNES

Le projet CXCI s’inscrit dans la continuité thématique de la filière d’observation optique haute résolution du CNES (SPOT, Hélios, Pléiades, CSO). L’objectif est de préparer le démarrage de projets d’intérêt dual permettant à la fois une certaine continuité programmatique avec Pléiades et la préparation du post-CSO. Ces travaux requièrent la mise en oeuvre d’un simulateur mission qui permet de modéliser les différentes composantes et contraintes du système et d’évaluer les performances mission qui en découlent. Par ailleurs, le service DCT/SB/MP est en charge du développement d’une infrastructure de simulation générique,ISIS, pour les simulateurs de Programmation Mission des 15 prochaines années. Cette infrastructure est réalisée en Java et s’appuie sur les technologies Eclipse RCP, JavaWorldWind et hSQLDB. Le présent support de CS porte sur des tâches de développement et de mise en oeuvre des outils de simulation mission CXCI dans l’environnement de simulation ISIS.

par Frédéric Andraud le 2013-06-12 09:29

Monday 10/06/2013

Aurélien Tisné

Outlook / Thunderbird : pour apprendre à se parler

Suivant son paramétrage, Outlook peut décider d'envoyer ses messages dans le format TNEF (Transport Neutral Encapsulation Format). La plupart des clients mail - dont fait partie Thunderbird - ne connaissent pas ce format.

Cela se traduit par un email vide qui contient un fichier attaché, nommé winmail.dat, impossible à visualiser correctement.

Le plugin LookOut permet à Thunderbird d'être capable de gérer cet encodage.

Pour plus d'information, on pourra consulter cet article sur Mozillazine.

Cependant, il se peut que ce ne soit pas suffisant. Nous avons rencontré un cas où, malgré la présence du plugin, une invitation à une réunion, envoyée depuis Outlook, ne s'affichait pas correctement avec Thunderbird, c'est à dire, sous forme d'un tableau et avec des boutons permettant d'accepter ou de refuser l'invitation (à noter que ceci est possible grâce à l'extention Lightning). Ceci, alors même que d'autres invitations, également envoyées depuis Outlook, étaient correctement reconnues par Thunderbird.

Toutes les tentatives de paramétrage du format du message dans Outlook sont rester veines.

Comme souvent avec Windows, la solution se trouvait dans la (miraculeuse) base des registres de la machine émettrice de l'invitation. Après modification de la clé de registre :

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Calendar
DWord: SendMtgAsICAL
Value: 1

attention, le numéro de version - 12.0 - peut changer

et un petit redémarrage d'Outlook, les invitations envoyées par cette machine étaient alors correctement reconnues par le destinataire.

par atisne le 2013-06-10 08:57

Friday 26/04/2013

CS SI - E-SPACE & Geo Information

SUPPORT A LA MISE EN PLACE DU NOUVEAU SYSTEME MEOSAR

Cospas-Sarsat (C/S) est un système unique d’aide à la recherche et au sauvetage par satellite. C/S apporte des données essentielles aux administrations et entités en charge de mettre en place les secours (détection, localisation). Aujourd'hui, le système COSPAS-SARSAT est utilisé dans les domaines aéronautique, maritime et terrestre, fournissant un lien vital entre les personnes en détresse et les sauveteurs qui risquent leur vie pour en sauver d'autres. En parallèle du déploiement des systèmes GNSS dans le monde, le concept MEOSAR est en phase de développement par la communauté C/S, basé sur les trois systèmes MEO : DASS/GPS, GLONASS et SAR/GALILEO. Le programme C/S s’est fixé deux objectifs concernant le MEOSAR : assurer une bonne transition du système LEO vers le système MEO et mettre en oeuvre les composantes spatiales et sol de ce système. Le système MEOSAR permettra de traiter en quasi temps réel des signaux d’alertes provenant de balises, et d’assurer une couverture globale grâce aux trois constellations de satellites et aux stations terrestres déployées à travers le monde. Ce système fournira aussi un moyen autonome de localisation de balises. La localisation est obtenue en combinant des données TDOA et FDOA (techniques basées sur des différences en temps et en fréquence).

Dans le cadre de la préparation de la transition du système LEOSAR vers le système MEOSAR, le CNES doit préparer les opérations nécessaires pour mettre en oeuvre les moyens mis en place pour le MEOSAR :

  • contribution nationale :

o mise à jour des procédures MCO existantes pour prendre en compte le MEO

o préparation des opérations en relation avec les administrations nationales qui opèrent le FMCC.

  • contribution au service SAR/Galileo (SGDSP) :

o définir les spécifications opérationnelles, l’architecture des opérations

o assurer la qualification opérationnelle du service SAR/Galileo

o conduire les opérations pre-IOC MEOSAR.

CS a été retenu pour cette prestation et apportera un support au Responsable Opérations CNES en charge de la préparation des opérations dans les domaines suivants :

  • définition des opérations,
  • procédures techniques et opérationnelles : création et/ou mise à jour – validation/qualification,
  • conduite des opérations pre-IOC.

par Frédéric Andraud le 2013-04-26 10:25

Friday 29/03/2013

Luc Hermitte

Le "C++ Moderne"

Suite à la grille que j'avais donnée dans mon précédent billet, deux questions fort pertinentes m'ont été posées :

  • Que signifie simple ?
  • De même C++ moderne concerne la syntaxe ?

De la simplicité

Hum ... est-il simple de définir la simplicité ? Voyons voir. Ah! Même la page wiki du principe du KISS n'élabore pas sur le sujet. Bon.

J'estime qu'un code est simple quand il résout, correctement, un problème en peu de lignes, et qu'il demande peu d'énergie pour comprendre ce qu'il fait des mois plus tard quand on a besoin de le relire, voire de le maintenir.

Un exemple facile serait par exemple un code C qui lit depuis un fichier un nombre de lignes inconnu à l'avance et le même code en C++. La version robuste (qui prend en compte les éventuels problèmes) est vite complexe en C. En effet, en C il faut gérer manuellement les réallocations pour chaque ligne lue, mais aussi pour le tableau de lignes. Le C++, mais aussi glibc, fournissent des primitives dédiées qui épargnent au développeur de devoir réinventer la roue. Cf l'article de Bjarne Stroustrup: Learning C++ as a new language.

On touche au paradoxe de la simplicité entre le C et le C++. Le C qui ne dispose uniquement que des briques élémentaires (relativement à la gestion de la mémoire et des chaines -- et encore) est plus simple que le C++. Pourtant le C++ qui offre des encapsulations de ces briques élémentaires permet de produire plus simplement du code robuste.

Quel est le rapport avec les bibliothèques C++ de manipulation de documents XML ? Et bien, je vous invite à comparer la manipulation de chaines de caractères de Xerces-C++ avec les autres bibliothèques plus modernes.

Le C++ Moderne

Pour comprendre ce qu'est le C++ Moderne, il faut d'abord voir ce qu'est le C++ historique.

Le C++ Historique

Un majorité écrasante, et regrettable, de ressources pédagogiques sur le C++ suit ce que l’on appelle aujourd'hui une approche historique. « Le C++ descend du C, il est donc logique d’enseigner le C avant le C++ ». Après tout nous enseignons le latin avant le français à nos enfants, non ? Certes, cette comparaison, comme bien des comparaisons, est fallacieuse, mais posons-nous tout de même la question : où est le mal à enseigner itérativement du C vers le C++ ? Au delà de l’aspect pédagogique qui nous fournit des abstractions plus simples à manipuler sur ce plan pédagogique, le soucis est dans les habitudes qui seront prises.

Le C++ historique est un C++ où la bibliothèque standard ne mérite pas mieux qu’une note en annexe d’un cours, chose qui pousse à réinventer la roue et à verser dans le syndrome du NIH. C’est un C++ dont les idiomes sont maîtrisés approximativement – assez logiquement, les cours modernisés sont plus au fait de l’état de l’art en matière d’idiomes C++. Mais c’est aussi et surtout un C++ où la gestion des erreurs est confiée à des codes de retour, comme en C.

Souvent nous le savons que trop bien, le développeur est vite laxiste et ne teste pas toutes les fonctions qui peuvent échouer pour traiter les cas dégradés. À commencer par les erreurs de type « mémoire saturée ». Un tel code cavalier dans sa gestion des erreurs ressemblerait à ceci :

NotifyIcon* CreateNotifyIcon()
{
....NotifyIcon* icon = new NotifyIcon();
....icon.set_text("Blah blah blah");
....icon.set_icon(new Icon(...), GetInfo());
....icon.set_visible(true);
....return icon;
}

Sauf que … le C++ peut lever des exceptions. C’est le comportement par défaut des allocations de mémoire en C++, des types standards qui nous simplifient grandement la gestion des chaînes de caractères et des tableaux redimensionnables, des listes chaînées, des tables associatives, etc. Des COTS peuvent aussi lever des exceptions à notre insu. Les exceptions doivent donc être prises en compte. De plus, il est envisageable que plusieurs des fonctions invoquées ci-dessus puissent échouer, le code précédent ne le prenait pas en compte. Supposons que les échecs soient notifiés par des exceptions, et tâchons de corriger le code précédent.

Une version corrigée pourrait ressembler à ceci :

NotifyIcon* CreateNotifyIcon()
{
....NotifyIcon* icon = new NotifyIcon();
....try {
........icon.set_text("Blah blah blah");
........icon.set_visible(true);
........Info info = GetInfo();
........icon.set_icon(new Icon(...), info);
....} catch (...) {
........delete icon; throw;
....}
....return icon;
}
Il semblerait que nous ayons fini. Et pourtant ce tout petit code est juste inmaintenable.
Que se passe-t-il si set_icon lève une exception ? Sommes nous certains que l’icône passée sera bien libérée ?
Pouvons-nous changer de place sans risques le set_icon ? Même si un jour la copie du GetInfo lève à son tour une exception ?
Et si nous rajoutions une troisième ressource, comment faire pour nettoyer correctement derrière nous ?
Bienvenu dans l’enfer de la gestion des ressources et du traitement des cas dégradés du C/C++ ! On aurait pu croire que ce code anodin soit simple à corriger avec un petit catch, ce n'est pourtant pas le cas.

NB: Ces codes proviennent de deux articles, un de Raymond Chen, et sa réponse par Aaron Lahman, au sujet de l’audit de codes dont le sujet est de savoir quel style est le plus propice à repérer rapidement des codes incorrects. La traduction de la réponse est disponible à l’adresse suivante : http://alexandre-laurent.developpez.com/cpp/retour-fonctions-ou-exceptions/

Vous trouverez dans l'article une version corrigée du code qui repose sur les codes de retour, avec un if toutes les deux lignes en moyenne pour remonter les erreurs, et restituer les ressources.

Le C++ Moderne

La solution aux problèmes du C++ historique réside dans le C++ moderne. Décryptons cette tautologie.
Oui le C++ est extrêmement complexe, personne ne prétend d'ailleurs le maîtriser dans sa totalité, et l'avènement du C++11 n'est pas fait pour améliorer les choses. Et pourtant, paradoxalement le C++ est plus simple à utiliser que ce que l’on peut croire. Il s'agit d'accepter de revoir notre façon de penser la gestion des cas dégradés. Là où la tradition nous pousse à envisager tous les chemins d'exécution possibles, ce qui a vite fait d'exploser, l'approche moderne nous pousse à surveiller toutes les ressources qui devront être restituées.

Pour cela on a recourt à une spécificité du C++ : tout objet local sera implicitement détruit en sortie de la portée où il vit, et ce quelque soit le chemin (propre -- i.e. suite à un return ou une exception levée) qui conduit à l'extérieur de cette portée. Si l'on veut être pédant, ce comportement déterministe répond à l’appellation Resource Finalization is Destruction idiom (RFID). Mais généralement on se contente de l'appeler Resource Acquisition is Initialization idiom (RAII) car le principe est qu'une ressource à peine est-t-elle allouée, elle doit aussitôt être confiée à une capsule RAII qui assurera sa libération déterministe.

Le standard C++98/03 n'offre qu'une seule capsule RAII généraliste, mais elle est assez limitée et elle vient avec des effets de bord indésirables pour les non-avertis. Il est toutefois facile de trouver des scoped guards prêts à l'emploi, à commencer par chez boost. Toutes les collections standards suivent le principe du RAII ; ce qui explique pourquoi le type std::string est si vite adopté par les développeurs, et pourquoi on cherche à orienter vers des std::vector<> pour gérer des tableaux. Le dernier standard paru en 2011 introduit enfin des scoped guards standards et sains, et des types dans la continuité du RAII : des pointeurs dit intelligents.

Ainsi, si nous reprenons l'exemple de la section précédente, le code devient une fois corrigé :

shared_ptr<NotifyIcon> CreateNotifyIcon()
{
....shared_ptr<NotifyIcon> icon(new NotifyIcon());
....icon->set_text("Blah blah blah");
....shared_ptr<Icon> inner( new Icon(...) );
....icon->set_icon(inner, GetInfo());
....icon->set_visible(true);
....return icon;
}

Peu importe si les fonctions appelées échouent, peu importe si elles viennent à être réordonnées, nous avons la certitude que inner sera libérée (ou confié à icon), et que icon sera libéré en cas de soucis, ou retourné dans le cas nominal.
Il est intéressant de noter que le RAII est applicable non seulement avec un code construit avec des exceptions, mais aussi avec un code continuant à fonctionner avec des codes de retour pour assurer la propagation des erreurs.

À vrai dire bien qu'il s'agisse d'une spécificité du C++, les autres langages pourvus d'exceptions disposent généralement d'un équivalent avec le dispose-pattern (try-catch-finally) qui permet d'obtenir le même comportement mais de façon explicite et non plus implicite. Si en plus ce langage est pourvu d'un garbage collector, la gestion de la mémoire est encore gérée autrement alors que le C++ nous oriente vers une solution unique pour gérer toutes les ressources, sans distinctions. Il est aussi à noter que C# fut le premier des descendants mainstream du C++ à introduire une alternative implicite et déterministe au dispose-pattern via le mot clé using, et Java s'y est également mis avec l'introduction des try-with-resources dans sa version 7.

NB : Pour certains, « C++ moderne » pourrait rimer avec méta-programmation template et autres joyeusetés très puissantes et vite arcaniques qui sont au cœur du projet qui sert de laboratoire aux évolutions de la bibliothèque standard : boost. Certes, c'est une utilisation moderne du langage, d'une certaine façon, mais ce n'est pas la modernité que l'on attend du simple développeur lambda d'applications. Il est attendu de lui qu'il puisse écrire simplement du code qui réponde aux besoins ; la robustesse et la maintenabilité étant deux des besoins implicites. Suivre l'«approche moderne» décrite précédemment est un premier pas dans cette direction.

Le C++ moderne, c'est aussi la bibliothèque standard, qui non seulement est dans la continuité du RAII, mais qui aussi fournit des outils génériques à des besoins récurrents (collections, algorithmes, chaînes de caractères simplifiées) et pas seulement ces flux rigolos avec des << et des >>.
Le C++ moderne, c'est aussi l'application d'idiomes (/patterns) modernisés. Par exemple, exit le test pour prévenir l'auto-affectation qui ne garantit pas l'exception-safety, mais bonjour l'idiome copy-and-swap.
Le C++ moderne c'est une nouvelle façon de penser en C++ qui implique une nouvelle façon d'enseigner le C++.

Malgré cela, le C++ reste complexe sur bien des points très techniques (comment changer son allocateur, comment écrire des méta-programmes template, etc.) en plus des points hérités du C. Il introduit aussi la complexité de la modélisation objet, à commencer par le Principe de Substitution de Liskov (LSP) qui est une pierre angulaire pour savoir quand on peut hériter, ou encore la Loi de Déméter qui cherche à nous enseigner la différence entre faire soit même et déléguer. Il introduit aussi des choses assez spécifiques comme la distinction entre la sémantique de valeur et la sémantique d'entité à cause de sa dualité quant aux accès directs ou indirects aux objets.
Et à aucun moment le C++98/03 n'adresse la question de la programmation concurrente ou parallèle.

Conclusion

Votre serviteur a profité de sa soutenance N3 pour reprendre un chapitre du mémoire qui répondait à la question C'est quoi le C++ moderne ?. J'espère avoir répondu à la question, mais surtout de vous avoir convaincu de la nécessité de cesser de surveiller tous les chemins possibles dans un code pour à la place surveiller toutes les ressources manipulées.

par Luc Hermitte le 2013-03-29 18:08

Détection rapide d'erreurs de manipulation de la mémoire avec clang

Depuis quelques versions clang offre un outil, asan, qui permet de vérifier rapidement à l'exécution les erreurs de manipulation de la mémoire. En somme, il s'agit d'un mini-valgrind intégré à l'exécutable.

Votre serviteur a pu le tester sur OpenJPEG . OpenJPEG étant prévu pour compiler avec CMake et voir ses tests lancés avec CTest, je vais vous partager les quelques opérations que j'ai pu faire pour profiter de cet outil.

Concernant la configuration de CMake, trois variables doivent être positionnées et c'est tout.

CMAKE_BUILD_TYPE:STRING=Debug
CMAKE_C_COMPILER:FILEPATH=/home/lhermitte/local/bin/clang
CMAKE_C_FLAGS_DEBUG:STRING=-O1 -g -fsanitize=address -fno-omit-frame-pointer 

Il suffit ensuite de finir la configuration, de compiler, pour finir d'exécuter les tests avec ctest.

Prenons un test qui pose un soucis qui a été détecté avec cet outil. La version actuelle de asan donne des informations inexploitables directement sans faire un objdump. Heureusement, clang vient avec le script {trunk}/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py (je vous invite à faire un locate pour le trouver sur votre système). En théorie il suffit de de passer le script sur la sortie produite lors de l'exécution des programmes instrumentés avec asan. Sauf que ce script s'attend à un format précis, et que ctest parasite les sorties en rajoutant "{numero-test}:" devant chaque ligne produite -- si vous connaissez une option de ctest pour l'empêcher de mettre le souk, je suis preneur.

Au final, il faut exécuter un:

ctest -R ETS-C0P0-p0_02.j2k-decode -VV 2>&1 | sed "s#^[0-9]*: ##" | asan_symbolize.py 

Ce qui m'a produit:

UpdateCTestConfiguration  from :/home/lhermitte/dev/openjpeg/build-clang-d/DartConfiguration.tcl
Parse Config file:/home/lhermitte/dev/openjpeg/build-clang-d/DartConfiguration.tcl
 Add coverage exclude regular expressions.
 Add coverage exclude: .*/tests/.*
 Add coverage exclude: .*/thirdparty/.*
UpdateCTestConfiguration  from :/home/lhermitte/dev/openjpeg/build-clang-d/DartConfiguration.tcl
Parse Config file:/home/lhermitte/dev/openjpeg/build-clang-d/DartConfiguration.tcl
Test project /home/lhermitte/dev/openjpeg/build-clang-d
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 18
    Start 18: ETS-C0P0-p0_02.j2k-decode

Test command: /home/lhermitte/dev/openjpeg/build-clang-d/bin/opj_decompress "-i" "/home/lhermitte/dev/openjpeg/data/input/conformance/p0_02.j2k" "-o" "/home/lhermitte/dev/openjpeg/build-clang-d/tests/conformance/Temporary/c0p0_02.j2k.pgx" "-r" "0"
Test timeout computed to be: 1500

=================================================================
==12912==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ee94 at pc 0x7f23854d3df4 bp 0x7fff55b16670 sp 0x7fff55b16668
WRITE of size 4 at 0x60200000ee94 thread T0
    #0 0x7f23854d3df3 in opj_mqc_init_dec /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/mqc.c:490
    #1 0x7f23854e5e07 in opj_t1_decode_cblk /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/t1.c:1623
    #2 0x7f23854e5325 in opj_t1_decode_cblks /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/t1.c:1509
    #3 0x7f23854fe1fe in opj_tcd_t1_decode /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/tcd.c:1481
    #4 0x7f23854fdf1e in opj_tcd_decode_tile /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/tcd.c:1216
    #5 0x7f23854b276d in opj_j2k_decode_tile /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:7524
    #6 0x7f23854c529b in opj_j2k_decode_tiles /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:9035
    #7 0x7f23854af49d in opj_j2k_exec /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:6710
    #8 0x7f23854b735e in opj_j2k_decode /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:9223
    #9 0x42c72d in main /home/lhermitte/dev/openjpeg/src_git_cs/src/bin/jp2/opj_decompress.c:818
    #10 0x7f238411376c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
    #11 0x42994c in _start ??:0
0x60200000ee94 is located 0 bytes to the right of 4-byte region [0x60200000ee90,0x60200000ee94)
allocated by thread T0 here:
    #0 0x41c057 in __interceptor_realloc ??:0
    #1 0x7f23854d3b76 in opj_mqc_init_dec /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/mqc.c:450
    #2 0x7f23854e5e07 in opj_t1_decode_cblk /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/t1.c:1623
    #3 0x7f23854e5325 in opj_t1_decode_cblks /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/t1.c:1509
    #4 0x7f23854fe1fe in opj_tcd_t1_decode /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/tcd.c:1481
    #5 0x7f23854fdf1e in opj_tcd_decode_tile /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/tcd.c:1216
    #6 0x7f23854b276d in opj_j2k_decode_tile /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:7524
    #7 0x7f23854c529b in opj_j2k_decode_tiles /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:9035
    #8 0x7f23854af49d in opj_j2k_exec /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:6710
    #9 0x7f23854b735e in opj_j2k_decode /home/lhermitte/dev/openjpeg/src_git_cs/src/lib/openjp2/j2k.c:9223
    #10 0x42c72d in main /home/lhermitte/dev/openjpeg/src_git_cs/src/bin/jp2/opj_decompress.c:818
    #11 0x7f238411376c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
Shadow bytes around the buggy address:
  0x0c047fff9d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c047fff9dd0: fa fa[04]fa fa fa fd fa fa fa fd fd fa fa fd fa
  0x0c047fff9de0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
  0x0c047fff9df0: fa fa 00 fa fa fa 00 fa fa fa 00 00 fa fa 00 00
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==12912==ABORTING
1/1 Test #18: ETS-C0P0-p0_02.j2k-decode ........***Failed    0.02 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.04 sec

Vous noterez que j'ai ainsi pu obtenir la ligne (et son historique) qui pose un soucis d'accès illégal en écriture, ainsi que les informations relatives à l'allocation de la zone mémoire où l'écriture illégale aurait du se faire.

par Luc Hermitte le 2013-03-29 17:44

Saturday 23/03/2013

Humeurs d'un libriste

Prenons-en de la graine !

Comme moi, vous avez du remarquer qu'il est parfois difficile de trouver une information importante sur le site web d'un projet libre. Plus d'une fois, j'ai du chercher la licence d'un projet dans son référentiel de code ou une archive de sources. Certains ne vous indiquent pas où signaler le bogue que vous avez rencontré, d'autres négligent de vous préciser que le code est disponible sur GitHub ou SourceForge. Et je ne parle même pas de ceux qui clament que la documentation, c'est le code ! Bref, les geeks sont rarement de bons communicants et de bons promoteurs de leurs propres projets. Du coup, lorsqu'un projet réalise presqu'un sans faute, cela mérite d'être signalé.

C'est à mon sens le cas du projet Point Cloud Library (PCL pour les intimes), bibliothèque libre de traitement d'images et de nuages de points.

Page d'accueil du site Point Cloud Library - 2013.03.22

Sur la page d'accueil du projet on découvre :

  •  L'objet du projet en quelques mots avec un lien vers une page « About » plus détaillée, page sur laquelle sont listées les entités qui financent le projet et celles qui y contribuent (une once de reconnaissance publique qui ne coûte pas cher et est toujours appréciée).
  •  La licence du projet (BSD 3 clauses, soit une licence permissive comme l'est celle d'Orekit).
  • Un lien vers le blog technique du projet et l'accroche des dernières annonces relatives à la vie du projet (il y a donc deux blogs, l'un pour les développeurs et utilisateurs, l'autre pour les personnes qui suivent le projet de loin).
  • L'annonce des derniers sprints du projet qui portent le nom des entreprises qui les financent, ce que je trouve plutôt astucieux en terme de communication (au passage, on découvre donc que le projet est géré selon une méthode agile, ce qui démontre un bon niveau d'organisation, et qu'il fédère des entreprises de premier plan).
  • Le statut des dernières compilations et un lien vers l'outil d'intégration continue (pratique courante dans les projets agiles mais sa mise en œuvre est ainsi discrètement soulignée et cette information renforce l'impression de professionnalisme).
  •  Un lien vers la page de téléchargement depuis laquelle on accède aux référentiels de code, aux archives de sources et aux archives binaires (paquets pour diverses distributions GNU/Linux, pour MS-Windows et pour MacOSX).
  •  Un lien vers les listes de diffusion et leurs archives mais aussi vers une page « Contact » qui rappelle tous les canaux d'information disponibles et propose un formulaire de contact en ligne.
  •  Un lien « Media » vers les ressources tierces (présentations, données, outils connexes, événements).
  •  En bas de page, la mention de la licence du site web (et donc de la documentation qui s'y trouve) : Creative Commons Paternité (CC By), licence permissive cohérente avec la licence du code et parfaitement adaptée à un site web et à de la documentation.

On frôle la perfection, il manque juste un lien direct vers l'outil de gestion de bogues (ainsi que, diront les plus exigeants d'entre nous, le recours à un système de gestion de version décentralisé et à un outil d'intégration continue libre).

Au final, cette page constitue une belle vitrine et un intelligent condensé d'information. Le visiteur comprend en quelques minutes qu'il est en présence d'un projet sérieux, structuré, bien outillé et soutenu par le monde industriel. Certes, ce projet semble avoir une solide assise financière et les ressources humaines qui vont avec, ce qui n'est pas le cas de tous. Mais si faire une documentation de qualité, des tests poussés et de l'intégration continue a un coût, le problème tient plus souvent dans la diffusion de l'information et la publicité des pratiques que dans la mise en œuvre de ces pratiques ou la production de ces informations (je connais plus d'un projet libre bien documenté, disposant d'une bonne couverture de tests et procédant à de l'intégration continue). Or, il me semble évident qu'une communication efficace et honnête est un facteur clé du succès d'un projet libre.

J'ai en tête quelques projets libres qui n'ont pas à rougir et devraient s'inspirer de PCL ! ;)

par sdinot le 2013-03-23 19:04

Wednesday 05/12/2012

Guilhem Bonnefille

Git, SVN et les méga projets

Un petit billet pour continuer sur mon expérience de travail avec Git et SVN.

Actuellement, je travaille sur un projet conséquent, c'est à dire qu'il est composé d'un très grand nombre d'article de configuration. Chacun de ces articles de configuration dispose de son historique propre et surtout de ses propres versions. Sous SVN cela se traduit par un layout trunk/tags/branches par article de configuration.

Dans mon espace de travail, j'ai donc créé autant de dépôt Git que d'article de configuration avec des commandes du genre : git svn init --stdlayout <URL>

Je me suis donc retrouvé avec une arborescence de dépôts Git. Sauf que pour les gérer, ça devient vite casse pied. Actuellement, je me suis fait un petit script pour lancer une commande sur tous les dépôts :

#!/bin/bash
# Script: git-foreach
for dir in `find . -name ".git" -type d`
do
	pushd `dirname "$dir"`
	git "$@"
	popd
done

Du coup, la mise à jour reviens à lancer la commande : git-foreach svn fetch Une solution plus élégante serait sans doute d'utiliser des submodules.

Puis, arrive le moment où l'on ne sait plus vraiment où on en est : suis-je à jour par rapport au trunk ? ais-je des commit à partager ? Une bonne solution consiste à rappeler à Git qu'il y a un lien entre la branche master et la branche trunk. On le lui rappelle avec : git branch --set-upstream master trunk Ensuite, Git est à même de nous renseigner rapidement avec des commandes git branch -v

~/Workspace/Root/Proj1 ~/Workspace/Root
* master 179e6bf Comment
~/Workspace/Root
~/Workspace/Root/Proj2 ~/Workspace/Root
* master 830ca95 [behind 7] Comment 2
~/Workspace/Root
~/Workspace/Root/Proj3 ~/Workspace/Root
* master 2100828 [ahead 1] Comment 3
~/Workspace/Root

par Guilhem Bonnefille le 2012-12-05 18:58

Wednesday 17/10/2012

Humeurs d'un libriste

Orthophotographie 2011 de Toulouse Métropole

Voici une information qui intéressera plus particulièrement le département Information Géographique et ImageApplications de la division Espace et ravira les mappeurs de Haute-Garonne et autres amateurs de photographies aériennes : sans tambours ni trompettes (alors que je trépignais d'impatience depuis 10 mois), la communauté urbaine Toulouse Métropole a publié le 20 septembre sur son site Open Data une orthophotographie couvrant les 37 communes de la communauté urbaine. Plusieurs éléments la rendent particulièrement attractive :

  • Elle est relativement fraîche (elle résulte d'une campagne de prise de vue aérienne de juillet 2011) ;
  • Elle est précise (images très bien calées d'une résolution de 12 cm) ;
  • Elle est utilisable en ligne et hors ligne (les dalles sont disponibles au téléchargement et un flux WMS a été ouvert) ;
  • Elle est libre (les données publiées sur ce site sont mises à disposition sous licence ODbL).

Le cas échéant, cette orthophotographie peut donc être utilisée par CS pour ses besoins internes et dans le cadre de prestations réalisées au bénéfice de tiers.

Voici les informations à connaître pour utiliser ces données :

  • La projection utilisée est la EPSG 3943, i.e. Lambert 9 zones, zone 2.
  • L'interface de consultation en ligne permet non seulement de naviguer dans l'orthophotographie mais aussi de télécharger les dalles qui la composent (416 images JPEG RGB 8 bits de 14000 x 10000 pixels pour un poids unitaire moyen d'environ 16 Mo).
  • Les url des serveurs WMS mis à disposition sont 1, 2 et 3.

Spéciale dédicace aux mappeurs : j'ai indiqué sur le Wiki d'OpenStreetMap comment configurer cette source de données dans JOSM.

par sdinot le 2012-10-17 06:54

Thursday 20/09/2012

Guilhem Bonnefille

Editeurs XML

Bien que la technologie XML soit ancienne, le problème concernant un bon éditeur XML revient régulièrement sur le tapis. Comme toujours, il n'existe pas d'outil parfait, bien dans tous les domaines, il faudra donc choisir celui qui rempli le plus de critères à vos yeux. Pour ça, rien ne vaut une petite liste de départ :

http://www.cmsreview.com/XML/Editors/

par Guilhem Bonnefille le 2012-09-20 11:47

Friday 20/07/2012

Blog de l'Equipe outil

Mise à jour des certificats de la Forge, problèmes avec Internet Explorer

Les certificats qui permettent de vérifier que vous êtes bien sur les serveurs de la Forge, et permettant de chiffrer la connexion entre votre client et les serveurs ont été mis à jour. Ceci implique de devoir faire accepter de manière permanente les nouveaux certificats aux clients SVN (de type Tortoise). Pour info, les hash correspondants (afin de vérifier que les certificats sont bien envoyés par les serveurs de la Forge) sont :

  • Pour Thor :

SHA1 Fingerprint=5D:38:8C:06:44:24:7A:F1:A6:74:48:CE:71:E2:8D:C7:E2:8C:3E:09 MD5 Fingerprint=38:0F:D8:9A:BB:53:C9:6C:AA:C7:B3:87:AB:2B:52:05

  • Pour Vulcain :

SHA1 Fingerprint=C9:E2:71:CB:D9:B6:44:55:05:7A:BA:D7:7F:F8:7A:54:59:E4:AE:4C MD5 Fingerprint=87:C3:D9:13:E2:62:4D:5D:C8:24:C0:E3:19:37:51:1F

Ces certificats sont signés par l'autorité de certification racine Certinomis. Le certificat racine de Certinomis est en principe dans tous les navigateurs du marché, ce qui devrait assurer une transition transparente (sans aucune manipulation) pour les utilisateurs de ces navigateurs. Cependant, il a été constaté que des versions récentes d'Internet Explorer ne disposaient pas de cette autorité racine dans leur magasin de certificats, ce qui conduit à un message d'erreur et au refus de connexion. Vous pouvez vérifier cela en allant dans Menu Outils/Option Internet/Onglet Contenu/bouton Certificats/Onglet Autorités principales de confiance, et en regardant si le certificat "Certinomis - Autorité racine" est présent.

Dans le cas contraire, vous pouvez installer ces certificats, soit en exécutant le fichier CertiNomis.exe qui va installer automatiquement le certificat au bon endroit, soit manuellement en installant le Certificat de l'Autorité Racine Certinomis ACR_Certinomis.cer

par jsudres le 2012-07-20 11:21

Friday 30/03/2012

Luc Hermitte

C'est parti!

Suite à des pressions de mes petits voisins, je me décide enfin à ouvrir cet espace.

Ne vous attendez pas à des discours dithyrambiques, dans un premier temps je ne ferai que faire retransmettre des informations qui circulent dans les communautés que je fréquente. Autant dire que ce blog parlera essentiellement de C++, voire de vim les jours de commit.

par Luc Hermitte le 2012-03-30 15:50

Bibliothèques C++ pour la manipulation de documents XML

Je vais tracer ici quelques unes des bibliothèques C++ de manipulation de documents XML. Le billet ne se veut pas exhaustif. Et je mets d'emblée les bibliothèques C comme libproxml, libxml, ..., hors périmètre.

Les traditionnelles

Xerces-C++

  • Licence Apache
  • - bas-niveau (SAX/DOM)
  • +SAX, DOM -- probablement la plus exhaustive sur ces deux approches
  • + i18n
  • + terrain connu pour ceux qui font du SAX et/ou du DOM dans les autres langages
  • - Lourde
  • - Ressources à gérer à la main (non RAII) ; nécessite une réencapsulation de certaines choses pour travailler dans un monde où des exceptions sont lancées

-> celle que je préconise en dernier lieu à cause des maladresses relativement au C++.

Rapid XML

  • Licence Boost (BSL), ou MIT
  • - bas-niveau (SAX/DOM)
  • - pas de SAX
  • + DOM
  • + UTF-8 & encodings 8-bits
  • - pas d'UTF-16, UTF-32
  • + simple
  • + rapide (équivalent à exécuter strlen() sur le texte XML)
  • + C++ moderne => gestion des ressources simple
  • + header-only

-> Celle que je tends à recommander si "traditionnel" (au sens SAX/DOM) est une contrainte.

Tiny XML

  • ...

libxml++

  • ...

Les orientées binding

Les bibliothèques de ce type requièrent une phase préalable d'analyse de schémas pour produire un ensemble de classes C++.

Code Synthesis XSD/e

  • licence triple: GPLv2, commercial, free pour petits dictionnaires
  • + haut niveau => plus simple à manipuler
  • + validation de schémas
  • - pas de SAX, DOM
  • + bindings schema <-> classes C++
  • + simple
  • + C++ moderne
  • + typage fort (et donc plus d'erreurs détectées à la compilation)
  • + petite empreinte, adapté à l'embarqué

xmlplus

  • GPLv3+
  • + binding <-> classes C++
  • uniquement survolée par votre serviteur

Les autres

LEESA

  • licence: New BSD
  • Phase de préprocessing pour produire un DSL (Domain Specific Langage) pour l'expression de requêtes à la XPath, et la traversée de documents XML.
  • Inspiré de XPath, mais ce n'est pas du XPath.
  • - pas de validation d'XML ou de parsing d'XML (SAX, DOM)
  • + applicable au delà d'XML.
  • + haut niveau
  • + typage fort
  • Un excellent article de présentation des fonctionnalités

-> Dans la mesure où des XML avec schémas doivent être manipulés, c'est la bibliothèque qui m'inspire le plus.

Elmax

  • Un gars qui s'est amusé:
  • License: Microsoft Public License
  • - pas de SAX/DOM
  • ~Moyen niveau
  • - pas de typage fort
  • Je vous laisse juge quant à si l'approche vous plait.

Et boost dans tout ça?

Boost.PropertyTree

  • Licence: BSL
  • Peut être détourné pour parser du XML
  • Niveau juste au dessus des bibliothèques traditionnelles (en fait, par défaut, B.PT utilise rapidXML pour le parsing XML)

Boost.Serialization

  • Licence: BSL

-> très bien si on veut sérializer des objets métiers et qu'aucun impératif de communication n'est établi avec un système externe.

par Luc Hermitte le 2012-03-30 15:48

Wednesday 26/10/2011

Guilhem Bonnefille

Black Duck : le retour d'expérience SAP

Dans le numéro 98 de septembre 2011, la revue Génie Logiciel propose un article à propos du retour d'expérience de SAP concernant la gestion de sa politique du logiciel libre avec les outils Black Duck.

Relativement court mais tout à fait pertinent, l'article présente les raisons ayant conduit SAP à investir dans les outils Black Duck ainsi que les résultats obtenus. Il est intéressant de lire que SAP considère le logiciel libre comme un moyen pour augmenter sa productivité en aidant à réduire le délai de la mise sur le marché et à répondre aux exigences du client. Les outils Black Duck sont alors présentés comme une solution pour permettre l'identification au plus tôt des obligations liées aux licences et donc de réduire les reprises de logiciels.

http://www.blackduck.com/

par Guilhem Bonnefille le 2011-10-26 08:45

Monday 24/10/2011

Humeurs d'un libriste

Le logiciel libre et l'open data infusent le Grand Toulouse

La culture du libre est très vivace à Toulouse et infuse désormais les services de la ville et de la communauté urbaine. J'en veux pour preuve quelques annonces récentes :

  • L'appel d'offre du 8 septembre 2011 portant sur le développement d'une offre de services basée sur l'outil de gestion électronique de documents Alfresco et la migration des outils bureautiques vers les logiciels libres pour la Mairie de Toulouse et le Grand Toulouse.

Avis aux industriels, le ton de la politique numérique de la ville et de la communauté urbaine est donné.

par sdinot le 2011-10-24 11:36

Monday 03/10/2011

Humeurs d'un libriste

Comptage de lignes de code : cloc et ohcount

L'art de compter les lignes...

Lorsqu'on vous demande d'auditer le code source d'un projet, les deux questions cruciales qui vous viennent immédiatement à l'esprit sont « quels sont les langages utilisés dans ce projet ? » et « combien y a-t-il de lignes de code ? » Pour y répondre efficacement, il vous faut un outil capable :

  • d'identifier les fichiers contenant du code source,
  • d'identifier le langage de programmation utilisé dans chacun de ces fichiers,
  • de distinguer les lignes d'instructions, les commentaires et les lignes blanches,
  • de calculer le nombre total d'instructions, de commentaires et de lignes blanches pour chaque langage.

Les réponses à ces questions sont moins triviales qu'il n'y paraît car :

  • certains langages utilisent les mêmes extensions de fichier (« .h » pour les entêtes C et C++, « .pl » pour le Perl et le Prolog, etc.),
  • il n'existe pas de convention indiquant si une ligne ne contenant qu'un délimiteur de bloc doit compter comme une instruction ou pas, si une ligne contenant plusieurs instructions atomiques doit être comptée comme une seule instruction ou autant qu'il y a d'instructions atomiques sur la ligne, si une instruction atomique mise en page sur plusieurs lignes doit compter comme une seule instruction ou autant qu'il y a de lignes, si les différentes copies d'un même fichier doivent être distinguées ou pas, etc.

Chaque outil apporte ses réponses, fruits des choix arbitraires de ses auteurs et des algorithmes plus ou moins élaborés mis en œuvre. Selon ces réponses et l'efficacité de l'outil, c'est à dire sa capacité à identifier les fichiers contenant du code source et les langages utilisés, l'expérience montre que l'inventaire final du code d'un projet peut sensiblement varier d'un outil à l'autre.

Pour ma part, j'utilise depuis plusieurs années avec une relative satisfaction cloc. Il n'est pas parfait mais je n'ai pas trouvé d'outil libre plus pratique et précis. Or, cette semaine, Guilhem Bonnefille a suggéré sur une liste interne un autre outil, nommé ohcount et développé par Ohloh pour générer les statistiques affichées sur son site. Comme ohcount est disponible dans le référentiel officiel de Debian, je me suis empressé de l'installer, de lancer les deux outils sur les sources copieuses du projet Orfeo Toolbox et de comparer les résultats. Pour les raisons évoquées plus haut, je m'attendais à des différences mais j'étais loin d'en imaginer de telles ! Je vous présente d'abord les tests effectués puis je vous donnerai les informations qui n'apparaissent pas dans ces bilans et mes impressions.

Cloc

Dans un premier temps, j'ai lancé cloc sans paramètre particulier :

Décompte des lignes de code OTB par Cloc

Mais je me suis aperçu assez vite que cloc avait ignoré les fichiers portant des extensions un tantinet « exotiques » telles que « txx » ou « ipp ». J'ai donc relancé l'outil en ajoutant les options l'invitant à prendre en compte ces fichiers :

Décompte des lignes de code OTB par Cloc avec options

Le résultat parle de lui même : il faut être vigilant sur les extensions prises en compte. Ici, cloc décompte désormais 286 005 lignes de code en plus, ce qui constitue un accroissement de +16 % par rapport au premier bilan !

Ohcount

Voici ce que donne Ohcount sur le même code :

Décompte des lignes de code OTB par Ohcount

ohcount annonce donc un cumul de 14 065 fichiers pour les langages C et C++, décompte se situant entre les deux de cloc. ohcount ignore donc des fichiers sources et l'impact n'est ici pas mince : 225 640 lignes de code en moins sur le cumul des langages C et C++.

La commande ohcount -d montre que le problème vient encore des fichiers d'extension « txx ». Assez bizarrement, sur les 1 642 fichiers ayant cette extension, ohcount en associe 2 au langage C et ignore les 1 640 autres alors qu'il s'agit de 1 642 fichiers de code source C++ ! Malheureusement, ohcount ne propose aucune option équivalente à l'option --force-lang de cloc. Son diagnostic est souverain, rien ne permet de l'altérer. :(

Je ne pouvais pas en rester là ! C'était trop bête car, comme nous le verrons plus tard, ohcount a bien des avantages sur cloc. J'ai donc téléchargé et patché les sources d'ohcount (le plus long a été de trouver ce qu'il fallait modifier car mon patch ne se compose au final que d'une seule ligne). Mais l'exécutable généré à partir de ces sources provoquant des erreurs de segmentation systématiques et sans lien avec ma modification, j'ai fini par télécharger les sources du paquet Debian (qui contenait effectivement plusieurs patchs) et à y reporter ma modification. Après génération et installation d'un nouveau paquet binaire, j'ai ainsi obtenu les résultats suivants :

Décompte des lignes de code OTB par Ohcount patché

ohcount retient bien désormais 1 640 fichiers de plus et il comptabilise 255 042 lignes de code de plus (+14 %).

À l'annonce de ce résultat, Guilhem (toujours le même) m'a suggéré de pousser mon modeste patch. Je l'ai fait mais réalisant dans la foulée que le développement était au point mort depuis 14 mois, j'ai aussi soumis mon patch à Sylvestre Ledru, le mainteneur du paquet Debian qui est visiblement plus actif ces derniers temps que les développeurs officiels d'ohcount. Sylvestre a fait preuve d'une réactivité impressionnante et le soir même, j'avais droit à une mise à jour du paquet d'ohcount sur ma Debian unstable ! Vous ai-je déjà dit ma satisfaction d'utiliser Debian et, plus globalement, du logiciel libre ? :)

Conclusion

Je dois reconnaître que, une fois patché, j'ai été séduit par ohcount :

  • Compilé, il est plus performant que cloc (45 secondes contre 79 sur ma machine pour traiter les sources du projet OTB).
  • Il ne se fie pas qu'aux extensions des fichiers pour déterminer leur contenu et sait par exemple reconnaître que sur 12 fichiers d'extension « in », 5 contiennent du Perl, 3 du C, 2 du XML, 1 est un script Autoconf et 1 n'est qu'un modèle de fichier de configuration à ignorer. C'est précieux et l'incapacité de cloc à faire de même est sa principale faiblesse.
  • De fait, ohcount ose aussi se prononcer sur le contenu d'un fichier d'extension « h ». Selon ce qu'il trouve à l'intérieur, il l'associe au C ou au C++. Et même si j'ai constaté quelques erreurs surprenantes (un fichier d'extension « h » contenant les mots « namespace » et « template » associé au C et non au C++), cette prise de décision est bien plus satisfaisante que la prudente distinction de trois catégories (C, C++, C/C++ headers) effectuée par cloc.
  • ohcount reconnaît les scripts Autoconf (configure.in, configure.ac, configure) et Automake (Makefile.am) mais aussi les scripts CMake (CMakeLists.txt, *.cmake). Là encore, c'est une belle supériorité sur cloc.

Par contre, je suis troublé par le fait qu'ohcount distingue deux Fortran (free et fixed) là où cloc ne voit que du Fortran 77 et par la divergence des décomptes finaux - 74 113 lignes d'instruction pour cloc contre 112 149 pour ohcount - alors que les deux outils sont d'accord sur le nombre de fichiers (425) ! Une jolie démonstration de ce que je disais en introduction sur le manque de conventions dans le décompte des lignes.

Plus globalement, je suis surpris par la divergence des diagnostics quant aux langages utilisés et par la faible concordance des décomptes de ligne à tous les niveaux. Sur OTB, ohcount nous annonce au final 2 238 243 lignes de code quand cloc nous en annonce 2 113 778. Un écart de plus de 120 000 lignes de code, soit 6 %, ça me semble beaucoup pour des outils dont la mission est aussi précise.

Quoi qu'il en soit, je vais désormais préférer ohcount à cloc pour les audits réalisés sur GNU/Linux. Quant à mes très rares interventions sur MS-Windows, ohcount ne fonctionnant pas sur ce système, la cause est entendue. De toute façon, l'exécutable autonome à destination de MS-Windows téléchargeable sur le site de cloc rend cet outil pratique pour les audits réalisés sur les machines banalisées mises à disposition par nos clients.

par sdinot le 2011-10-03 07:21

Tuesday 27/09/2011

Humeurs d'un libriste

Portail Open Data de Toulouse : les données seront sous licence ODbL

La rencontre sur l'open data organisée hier soir à La Cantine de Toulouse a été l'occasion pour la communauté urbaine du Grand Toulouse de présenter son projet open data (dont le nom officiel sera Toulouse.data). Voici ce qu'il faut en retenir :

  • Le portail sera présenté et ouvrira le 22 octobre pendant La Novela (festival des savoirs partagés).
  • Les données seront diffusées sous licence ODbL (licence du projet OpenStreetMap). Toulouse a donc fait le même choix que Paris et nous ne pouvons que nous en féliciter !
  • Pour commencer, une trentaine de jeux de données, essentiellement géographiques, seront publiés, les autres arrivant au fur et à mesure de leur « découverte » (un recensement est en cours dans les services).
  • Une orthophotographie du Grand Toulouse fera partie des données publiées. Les prises de vue issues de la campagne de juin 2011 étant encore en cours de traitement, c'est l'orthophotographie de 2007 qui sera dans un premier temps mise en ligne (celle de 2009 ne peut être publiée pour cause de droits insuffisants). L'orthophotographie de 2011 sera mise en ligne dès que possible (je vois bien cela vers décembre/janvier). Le Grand Toulouse de 2007 n'étant pas celui de 2011 (la communauté urbaine est passée de 25 à 37 communes), je ne sais quelle superficie couvre la campagne de 2007. Mais, de mémoire, celle de 2011 devrait couvrir 1600 km2 (je ne connais pas la résolution des images mais elle devrait être assez fine).
  • Les formats ouverts et interopérables seront privilégiés mais l'intervenante n'a pas donné de garantie à ce niveau. Elle nous a juste informé que les services du Grand Toulouse étaient sensibilisés et feraient leur possible.

Le contributeur que je suis se régale par avance de cette avalanche de données !

par sdinot le 2011-09-27 08:14

Thursday 01/09/2011

Luc Hermitte

"Préférez le pattern Active Object aux à la manipulation manuelle des threads"

Dans son blog où il traite de la problématique de la programmation concurrente, Herb Sutter a publié un dernier article relatif au pattern Active Object que les habitués d'ACE ont déjà dû rencontrer.

Ce pattern mérite notre attention. En effet, la programmation concurrente relève de bien des pièges dans lesquels les non avertis ont vite fait de se jeter. On pourrait croire qu'il suffit de saupoudrer notre code de mutex pour que l'on passe en MT, malheureusement c'est bien loin d'être le cas. Non seulement on risque de dégrader inutilement les performances en protégeant des zones pas si sensibles, mais en plus on risque des interblocages si on n'arrive pas à organiser hiérarchiquement nos locks. Le pattern Active Object est une des approches les plus élégantes qui permette de fonctionner de façon concurrente.

Je ne vais pas renter ici dans les détails sur les avantages et inconvénients de chaque approche. À la place je vous invite vivement à consulter les articles d'Herb Sutter.

Petite remarque, les articles sont certes teintés de code C++(0x/11), mais les principes sous-jacents prévalent dans les autres langages que l'on utilise couramment.

par Luc Hermitte le 2011-09-01 11:54

Wednesday 06/07/2011

Sébastien Domergue

Résumé du Paris Jug Cloud

Mardi 5 juillet 2011 s'est tenu le dernier Paris JUG avant les vacances d'été. Son thème : le Cloud. Au départ un seul speaker était prévu en la personne de Patrick Chanezon mais la profusion de talents disponibles à Paris a permis d'avoir de multiples co-speakers en seconde partie (qui a du être menée au pas de course de ce fait mais ils ont plutôt bien géré).
Plus que jamais le Paris Jug est assailli par les participants. Cette fois, les 180 places sont parties en 2h30 (nouveau record) et la liste d'attente comptait une centaine de personnes.

Première partie : La mode Cloud, collection été par Patrick Chanezon

Patrick Chanezon est Developer Advocate, Cloud & Apps chez Google. Comme il passait par la France au moment du JUG il a pu tenir ce talk sur sa vision du cloud avec ses avantages et inconvénients et son évolution.

Petit historique sur le développement logiciel

Avant toute chose, il faut rappeler que la loi de Moore ne s'applique pas au software mais uniquement au hardware. A titre de comparaison, dans le temps où les capacités du hardware ont évoluées 1.000.000 de fois, la productivité à été multipliée uniquement par 10 pour le software.
On constate ensuite qu'il y a eu une transition d'architecture tous les 20 ans en moyenne :

  • Dans les années 60 : les mainframes
  • Dans les années 80 : les architectures clients / serveur avec des mécanismes de synchronisation entre les clients et le serveur. Une partie de l'application est ainsi dévolue au poste client.
  • Dans les années 90 : l'arrivée du Web. En termes d'architecture, c'est plutôt une régression car on peut l'assimiler au retour des mainframes à cause de la pauvreté des browsers.
  • 2010 : arrivée du HTML 5, maturité des technologies mobiles, Cloud : le browser devient un OS à part entière grâce aux capacités des moteurs javascript, au HTML 5 pour le stockage local, la lecture de vidéos, des images, de la 3D... Le cloud permet de scaler de manière relativement transparente, c'est le retour de l'architecture type clients / serveurs.

Historique du cloud

Le cloud a débuté du côté des sites grand public tels que Google, Amazon, Yahoo, Facebook, Twitter. Lors de la création de Google, le constat état que le matériel basique (type PC) était disponible de manière standardisée à un coût très bas et que la vitesse des réseaux était en augmentation. Ainsi, au lieu de devoir faire de la scalabilité verticale en devant acheter un plus gros serveur central pour augmenter la puissance de calcul, distribuer les calculs sur plusieurs petites machines permet de faire de la scalabilité horizontale et de masquer la panne d'une machine qui est remplacée aisément à coût faible et sans indisponibilité globale.
Les technologies de virtualisation et surtout le développement des logiciels libres ont permis au Cloud de se développer grâce à des applications déployables en grand nombre et grâce à la communauté.
Les premiers services de cloud public ont ainsi vu le jour : Hadoop, Eucalyptus ... et récemment Cloud Foundry.

Les facteurs qui pilotent l'adoption du cloud

Les facteurs techniques

L'utilisation du cloud peut permettre de ne pas réinventer la roue systématiquement en s'appuyant sur les nombreuses briques open source disponibles. Comme évoqué précédemment, le cloud permet un passage d'une scalabilité verticale à une scalabilité horizontale.
Pour programmer dans le cloud, il est nécessaire de disposer :

  • d'un file system distribué : Google File System
  • du stockage de grands volumes de données en mémoire : BigTable (BigTable a une utilisation très bas niveau, des surcouches existent qui rajoutent des fonctionnalités : Megastore qui ajoute la notion de transaction et de requêtes sur les propriétés et Datastore qui ajoute encore des possibilités de requêtages complexes).
  • de nouvelles abstractions de programmation : MapReduce qui s'inspire de Lisp pour distribuer les calculs.
  • de DSL : Sawzall

L'algorithme MapReduce

L'algorithme MapReduce énonce qu'un calcul peut être décomposé en deux étapes :

  • L'étape Map où à un ensemble de (clé, valeur) on associe un nouvel ensemble de (clé, valeur)
  • L'étape Reduce où à un ensemble de (clé, valeur)on associe pour toutes les donnés de même clé une paire unique (clé, valeur)

Ces deux étapes permettent de paralléliser nativement les algorithmes puisque l'étape de Map peut être effectuée sur plusieurs noeuds (et même récursivement) afin que la quantité de données à traiter par chaque noeud soit plus faible. Chaque noeud effectue ensuite une étape de Reduce partielle et fournit le résultat au noeud précédent dans la hiérarchie d'appel qui effectue une étape de Reduce partielle sur les résultats jusqu'à remonter au noeud principal qui dispose donc du résultat.

Des modes de conception différents
L'architecture distribuée implique d'adapter les modes de conception classiques utilisés actuellement. L'exemple le plus frappant est ACID.
ACID avant, c'était :

  • Atomic
  • Consistent
  • Isolated
  • Durable

ACID maintenant, c'est :

  • Associative
  • Commutative
  • Idempotent
  • Distributed

Il faut abandonner la normalisation au profit de la réplication de données pour éviter les relations et jointures qui coûtent "chères" en performance. C'est faire de la compensation plutôt que de la transaction. Un exemple en dehors du monde information a été présenté : Starbucks (encore eux). Donc chez eux, la préparation du café est débutée avant l'encaissement. Plusieurs cas d'erreur peuvent alors survenir :

  • La préparation effectuée n'est pas la bonne : préparation de la bonne commande (retry)
  • La préparation ne convient pas au client : remboursement (refund)
  • Le client ne peut pas payer : la boisson est jetée

La vulgarisation de l'informatique distribuée

  • Au travers des langages orientés distribués : Ergland, Scala, Go
  • Au travers du stockage NoSQL : BigTable, HTable, MongoDB, Reddis, Cassandra...
  • Au travers de pattern : Map/Reduce qui donnera Hadoop
  • Le CAP Theorem : entre la consistance des données, le partionning et la disponibilité des données, on ne peut en avoir que deux qu'il faut choisir
  • Les architectures REST, stateless...
Les facteurs économiques

Le constat est là, la proportion du coût de l'électricité augmente dans le coût global du computing. Sur le ton de l'humour, il est ajouté que dans le futur, les compagnies d'électricité pourront offrir le matériel informatique tant la part du matériel en lui-même sera faible. D'où le passage du monde du produit vers le monde du service. Cela permet de faire des économies d'échelle (avec l'allocation dynamique et répartie des ressources) et des économies sur la gestion des datacenters (les mainteneurs système sont, semble-t-il, voués à tous migrer vers les sociétés de cloud...). La loi de Moore qui continue de se vérifier pour le moment table encore sur des augmentations de la puissance de calcul brute pour un coût moindre.
Enfin, le modèle "Pay as you go" où la facturation est au temps effectivement consommé (issue du modèle des supercalculateurs) permet de maitriser ses dépenses.

Les facteurs culturels

Avec le développement des produits personnels, les utilisateurs attendent au sein des entreprises des produits professionnels qui fournissent des performances et une ergonomie au moins équivalente. C'est la consumérisation de l'IT. Du coup, les applications évoluent comme la mode avec un phénomène de lassitude. Les applications deviennent jetables.
Au niveau méthodologique, on passe donc d'un cycle classique (cycle en V, cascade) vers des cycles agiles qui permettent une évolution constante.
D'un point de vue du développeur, il y a également beaucoup de technologies qui émergent actuellement et pour effectuer des tests, il vaut mieux ne pas avoir à monter un environnement à chaque fois. La devise : Essayer beaucoup mais se planter rapidement pour apprendre de ses erreurs. Il faut apprendre de ce chaos qui permet de disposer de beaucoup d'éléments, techno, patterns...
Avec le développement des librairies, particulièrement open source, et du multi-plateforme, il faut aussi développer la culture des API qui deviendra important pour la conception des application dans l'avenir. Pour développer une API, le cheminement devrait être :

  • Identification des fonctionnalités complexes du backend
  • Développement de ces fonctionnalités
  • Création de l'API au dessus de ces fonctionnalités
  • Créer les clients (au pluriel car tous les types de client devraient accéder à la même API).

La dernière barrière est de développer directement dans le cloud. Actuellement il existe des éléments mais ils sont disparates et il faut encore les assembler manuellement.
Les processus changent aussi, même au sein des méthodes agiles, du fait de la fréquence des livraison qui s'accentue : les livraisons peuvent être quotidiennes voire plusieurs fois par jour.

Delivery / Monetization / Marketing

Les plateformes de distribution sont de plus en plus nombreuses : App Stores, SaaS, Social média... Les opportunités s'en trouvent multipliées. Le risque est d'obtenir une fragmentation car les plateformes emprisonnent leurs clients. En effet, il n'existe pas encore de standard et donc de bascules simples entre les plateformes. De plus, il faut être attentif aux conditions générales d'utilisation afin de détecter les stratégies à long terme de ces plateformes (cas des CGU de Dropbox cette semaine). Afin de remédier à cet état, l'open source pourrait être la solution.
Les infrastructures débutent un travail de standardisation mais qui débouche sur une bataille de standards. Les deux qui semblent sortir du lot sont : DeltaCloud et OpenStack. Au final, pour être indépendant, il faut être multi-cloud.

Outils et plateforme

Un petit tour d'horizon d'éléments disponibles pour travailler dans le cloud.

Les plateformes
  • App Engine
  • Joyent (NodeJs)
  • Cloudbees
  • Amazon elastiv beanstalk

Chacun est différent, propose des panoplies de langages différents, le risque est d'être emprisonné par sa plateforme.

Cloud privé

Cloud Foundry, proposé par VmWare, est une solution open source qui permet de monter des clouds privés facilement.

Volumes de données

Pour le traitement des gros volumes de données et pour MapReduce, Hadoop est le leader.

Développements

L'IDE est "the Final Frontier", des projets sont en cours :

  • Cloud9 (NodeJs)
  • Exo IDE
  • Orion (projet de la fondation Eclipse)

Des ateliers de génie logiciel font leur apparition :

  • Wavemaker
  • Orangescape
  • Runmyprocess

Enfin, Cloudbees permet de lier une partie du développement et du run sur le cloud grâce au build automatique effectué par Jenkins et le déploiement automatique.

Conclusion de la présentation

Cette première présentation a permis d'effectuer un état de l'art de ce qu'il était possible de faire avec les outils du cloud actuellement. Les présentations suivantes sont des retours d'expérience ou des présentations plus détaillées d'outils présentés lors de ce talk.

Création de valeur et de compétitivité avec le cloud par Didier Girard

Le cloud n'est pas une histoire de réduction des coûts!

C'est une histoire de réactivité

L'échelle de temps des ressources IT se comprime. On ne peut plus attendre au minimum une semaine pour disposer d'un serveur, à fortiori dans une équipe agile où l'échelle de temps est plus de l'ordre de l'heure. Un cas pratique rencontré : un projet est notifié le 28/08, le démarrage doit impérativement être le 01/09 avec la mise en place du gestionnaire de sources, du système de build... Ce projet a été la première occasion pour Didier de tester le développement sur le cloud grâce à :

  • Assembla pour le gestionnaire de sources et le bugtracker.
  • Cloudbees pour l'automatisation du build et des tests
  • AppEngine pour le run, cette plateforme étant utilisée initialement pour le développement, la cible finale n'étant pas figée au démarrage.

Lors du projet, l'équipe de développement a du migrer des locaux de la SSII vers les locaux du client, aucune manipulation n'a été à effectuer. Une fois branchés sur le réseau du client le développement a pu reprendre immédiatement.

C'est une histoire d'innovation

Pour tester une librairie ou une idée, il faut que quelque chose soit présentable très rapidement. Cas de l'analyse de l'API forPlay de Google : de l'idée à la mise en production en 2 jours. Cela a aboutit à la réécriture de la démo de l'aquarium.
Autre cas, développement d'un player de musique type Winamp entièrement en HTML 5. Cette application est disponible sur le Chrome Web Store.

C'est une histoire d'ambition

Le projet ske7ch qui permet de tagger des produits grâce à leur code barre, de tagger des pages web... de manière anonyme et gratuite.

C'est une histoire d'agressivité

Le projet A Bon Entendeur a pour objectif de déloger l'acteur principal dans le monde de l'avertisseur de radar. Mais pour cela, il faut disposer d'une plateforme de run (AppEngine) mais également de market places pour bien réussir.
En exclusivité, nous avons pu avoir la présentation de la nouvelle interface du projet qui a été réalisée par un graphiste issu de la communauté de sa propre initiative.

C'est une histoire de démocratisation

Il est désormais possible de tester, de manière gratuite, un service, une plateforme sans disposer d'une infrastructure particulière ce qui développe l'autoformation.

C'est une histoire de performances

Sur le cloud, avoir 300 utilisateurs en simultané est peu, de plus, en utilisant quelques patterns spécifiques, la scalabilité est correcte et aisée.

C'est une histoire de mérite

La taille de la SSII n'est plus un critère car l'hébergement et la montée en charge n'est plus un frein.

C'est une histoire de sérénité

Dans le cas du site de la conférence des évêques de France, le trafic est multiplié par 100 pour Noël et Pâques, avec le Cloud, l'allocation des ressources est automatique et évite des périodes de stress lors de ces fêtes.

Conclusion

Aujourd'hui, 10% du CA de SFEIR est lié au cloud, pour didier le cloud est inévitable et va amener une mutation profonde dans l'esprit des gens et leur rapport aux projets informatiques.

Cloud Foundry, Platform-as-a-Service par Guillaume Laforge

Cloud Foundry est un projet de VmWare, il est composé du système Cloud Foundry et de la plateforme gérée par VmWare comme un service. Cloud Foundry intègre une pile complète de services intégrés avec les dernières versions des frameworks supportés au travers d'un moteur d'exécution. Le provisionning de l'infrastructure est automatique. L'unité de travail est l'application car c'est ce qui est déployé. Les limites des plateformes disparaissent :

  • Multi-langages et possibilité d'en ajouter. A titre d'exemple le langage PHP a été intégré 3 jours après la demande sur les forums, sur l'AppEngine, 3 ans après la demande PHP n'est toujours pas intégré.
  • Pas d'API propriétaires.
  • Possibilité de migrer vers d'autres fournisseur et même vers un cloud privé car cloud foundry est open source.

Les services inclus :

  • RabbitMQ
  • Reddis
  • MySQL
  • MongoDB
  • ...

Les frameworks gérés :

  • Rails
  • Grails
  • Sinatra
  • Spring
  • NodeJs

A venir : le microcloud qui permet de tester les développement sur une machine personnelle hors ligne à la manière d'AppEngine.
Nous avons eu une petite démo en 6"30 chrono (dommage pour la faute de saisie qui a couté les 30 secondes de dépassement) de la création et du déploiement d'une application Groovy sur Cloud Foundry

Cloudbees.com par Nicolas Delof

Cloudbees permet de faire du développement mais aussi du run sur le cloud. La plateforme est évolutive car tout partenaire fournissant des services en SaaS peut être intégré, la facturation est alors mise à jour en fonction. Cloudbees propose un hébergement Jenkins intégré, la forge logicielle est ainsi construite à la manière d'un légo avec les briques nécessaires uniquement : Sonar, Selenium... La facturation est effectuée à la minute effective de build. Ce build devient le lien naturel pour le déploiement sur le cloud. Associé au build automatique à chaque push, le déploiement devient continu. Il est possible de disposer de son propre hébergement Maven avec repository privé et même de disposer de Cloudbees en privé.

Runmyprocess par Erwan Arzur

Runmyprocess est un IDE graphique pour déployer ses applications sur le cloud et permettre d'intégrer et d'orchestrer les processus.
L'inconvénient du cloud est qu'il n'est pas encore totalement stable. L'exemple le plus récent est la chute d'une zone au sein du Cloud d'Amazon le 22 avril dernier. Nombre d'applications n'ont pas pu être disponibles pendant 24h (dont runmyprocess). L'avantage est que suite à l'incident, beaucoup d'articles ont expliqué comment s'en sortir et prévenir ces problèmes. Un exemple est une société qui dispose d'un Chaos Monkey qui arrêt des instances au hasard pour vérifier si le service contienu à fonctionner. Les solutions à mettre en oeuvre en priorité sont le déploiement sur plusieurs zones et/ou le déploiement sur plusieurs datacenter (et même sur plusieurs continents si possible). Ces solutions ne sont viables que si reconstruire le cluster est rapide. Les machines qui le composent sont jetables et doivent pouvoir être reconstruites en quelques minutes. Toute l'infrastructure doit être pensée sur ce mode de fonctionnement, il faut utiliser des mécanismes de monitoring interne mais également externe, le provisioning n'est plus abordé de la même manière... mais cela n'empêche pas la redondance ou les backups!

ExoIDE par Jérémi

ExoIDE fait partie des outils qui veulent faire tomber la dernière frontière : le développement sur le cloud. Actuellement, il n'est pas possible d'effectuer tout son développement sur le cloud mais quelques situations sont possibles :

  • Démarrer rapidement un petit projet, par exemple pour une démonstration
  • Corriger une application rapidement (il est même possible de déployer une application depuis un avion maintenant!)
  • Collaborer autour du code

Nous avons conclu sur une rapide démonstration de l'autocomplétion qu'offre ExoIDE pour Groovy : ça marche!

Ma conclusion

Beaucoup de choses vues ce soir, beaucoup de basewords et de buzzwords également. J'ai avant tout l'impression qu'on retourne à une solution d'hébergement mutualisé (à plus grande échelle mais quand même). Je ne doute pas du gain en termes de mise en oeuvre des plateformes, surtout au début des projets. Le problème reste un problème culturel et légal : mes données ne m'appartiennent plus vraiment car elles sont stockées par une société tierce (d'où le rappel de la lecture des CGU qui est primordial) mais ces données peuvent également être stockées sur des noeuds à l'étranger. Dans la grande majorité des cas rencontrés à CS, cela est tout simplement impossible. C'est pourquoi la solution Cloud Foundry est à mon sens, l'élément qui manquait pour enfin pouvoir rationaliser de manière cohérente les SI de nos clients.
A titre personnel, les tests ont déjà débutés avec comme première application un outil de newsletter sur le cloud. Si j'arrive à l'avancer rapidement, ce test fera l'objet d'un prochain post.
Ainsi s'achève cette saison 2010/2011 du Paris JUG, encore merci à toute l'équipe!

par Sébastien Domergue le 2011-07-06 13:45

Monday 23/05/2011

Guilhem Bonnefille

Migration de Debian à Ubuntu

Ben voila, j'ai franchi le pas : las des soucis de stabilité de la Debian testing qui finissaient par nuire à ma productivité, je l'ai remplacée par Ubuntu dernière du nom. L'avenir dira si c'était une bonne ou mauvaise chose.

Mais ce ne fût pas une mince affaire. En effet, mon portable est protégé par une partition chiffrée (LUKS) et partitionnée avec lvm2.

Première étape : un nième backup (on ne rigole pas avec les données). J'ai utilisé fsarchiver via la distribution g4l (ghost for linux).

Deuxième étape : récupérer le CD d'installation. Pour Ubuntu, il faut utiliser le disque "alternate" pour espérer utiliser les partitions chiffrées.

Troisième étape : l'installation. Le problème est que le système d'installation ne gère pas la réutilisation de partition chiffrée (Cf. bug Ubuntu #285890). Pour pouvoir réutiliser les données il faut faire des actions en manuel. Pour cela, avant d'activer l'étape de partionnement, il faut taper les commandes suivantes dans une console.

cryptosetup luksOpen /dev/sdaX crypt
vgscan
lvscan
pvscan
vgchange -a y vg-crypt

Ensuite, on peut activer l'outil de gestion des partitions et poursuivre l'installation comme si de rien n'était.

Quatrième (et dernière) étape : le reboot. Normalement, le reboot échoue dans la recherche du root et conclut par un shell. En effet, la gestion de la partition chiffrée ayant été faite à la main, l'installeur n'a pas correctement configuré le initramfs.

Pour se débloquer, dans le shell ouvert par le système de boot, il suffit de faire le montage à la main :

cryptosetup luksOpen /dev/sdaX crypt
vgchange -a y vg-crypt

Un Ctrl-D et le boot continue correctement.

Il reste à mettre au point le prochain boot. Il faut donc déclarer la partition chiffrée (dans /etc/crypttab), puis mettre à jour l'initramfs :

update-initramfs -u

Références

  • Debian bug #451535
  • http://wiki.debian.org/DebianInstaller/Rescue/Crypto
  • http://ubuntuforums.org/showthread.php?t=1381103

par Guilhem Bonnefille le 2011-05-23 12:00

Monday 14/03/2011

Sébastien Domergue

MDA : une approche en partenariat

Dans les précédents articles traitant du MDA, j'ai abordé le rôle de l'outillage ainsi que celui des architectes MDA qui doivent placer le curseur de la modélisation. Dans cet article, je vais plus m'orienter vers la réalisation d'un projet avec cette méthodologie et ainsi parler de l'organisation du projet et de la communication avec un client et avec les équipes.

L'approche MDA ne peut réussir que si la communication entre les différentes parties existe et est active. En effet, il est nécessaire de beaucoup communiquer, au moins lors de la phase de spécifications. Avant de pouvoir démarrer un projet avec l'approche MDA, il faut disposer de l'outil qui va servir à modéliser ainsi que des profils qui seront utilisés. Les transformations modèle à modèle et modèle vers code peuvent être en cours de réalisation en parallèle (dans ce cas il faut identifier le risque que leur mise au point prenne du retard) mais il faut que les tenants et aboutissant de ces transformations soient définis car ils peuvent influer sur les profils de modélisation.

La phase de spécification

Cette phase est la phase principale et la plus importante du projet, il faut prévoir plus de temps qu'une phase de spécification plus classique. Dès le départ du projet, il faut :

  • Identifier les grands domaines fonctionnels de l'application. Ce découpage est nécessaire pour pouvoir aborder les aspects du logiciel de manière bornée.
  • Planifier des ateliers de spécification avec le client : ces ateliers durent une journée environ et doivent permettre de couvrir un domaine fonctionnel identifié ci-dessus. Le découpage fonctionnel doit donc prendre en compte le volume de cas d'utilisation qu'on peut identifier à la lecture du cahier des charges et des discussions préliminaires (phase d'avant vente). Si un domaine est trop volumineux, il existe surement un axe de découpage (traitement par différents intervenants, découpage de workflow...). Un atelier qui dure plus d'une journée est d'une part difficile à obtenir du fait des disponibilités du client (en général ses activités normales continuent) et d'autre part ne permet pas de laisser reposer les discussions de la veille. Il faut penser que les discussions peuvent être parfois complexes car les personnes présentes vont devoir exposer leur métier et leurs exceptions.
  • Prévoir deux personnes pour mener chaque atelier. En effet, au cours d'une journée l'attention ne peut être maximale en continue et lors d'échanges, l'un peut discuter et l'autre noter.
  • Préparer en avance chaque atelier avec la compréhension initiale du besoin : identifier les cas d'utilisation, proposer les règles de gestion évidente, un enchainement d'écrans avec une première liste des champs présents sur chaque écran.

Pour chaque atelier, il faut avoir généré un premier document qui sera envoyé avant la réunion pour que le client en prenne connaissance. De plus, si l'outil le permet, générer un mini-site HTML qui permet de suivre les enchainements de page par cas d'utilisation est un plus. Pour mener la réunion on peut ainsi suivre les écrans tels qu'ils existeront, les utilisateurs ont ainsi une meilleure vision sur la réalité de leur futur outil. Les règles de gestion sont alors discutées sur les écrans ou entre chaque écran présenté.
Ces ateliers peuvent être doublés si les premières réunions amènent beaucoup de réécriture afin de pouvoir rediscuter sur des bases plus proches de la réalité. Ces nouvelles réunions doivent normalement se dérouler plus rapidement que les premières.
Le format d'une journée n'est pas obligatoire sur tous les sujets. Par exemple l'atelier d'administration d'une application de gestion est en général suivi par des exploitants qui auront un petit nombre de cas d'utilisation très basiques en termes de règles de gestion. Il est généralement beaucoup plus court.
Attention néanmoins, chaque réunion peut faire diverger l'expression du besoin de son axe initial défini par le cahier des charges et l'offre faite. Il est important de noter tout écart, même s'il n'impacte pas les coûts afin de pouvoir tracer les modifications. Pour les écarts impactant les coûts, il s'agit de décisions prises par les responsables du projet.
En sortie de cette phase, le client dispose des informations suivantes :

  • Les cas d'utilisation de l'application
  • Toutes les règles de gestion de chaque cas d'utilisation
  • Les enchainements d'écran
  • Les champs de chaque écran (champs en lecture, en écriture, obligatoires...)
  • Les messages d'erreur et de traces

La phase de conception

Lors de la phase de conception, il faut disposer des transformations de modèles. Cette phase permet de dériver le modèle de spécifications vers des aspects plus techniques. Les documents en sortie, même s'ils seront fournis au client, seront plus utilisés par les développeurs. Lors de cette phase, il n'est pas nécessaire de faire des réunions externes car la cible technique a déjà été définie lors de la réponse. Les raisons qui peuvent conduire à une réunion sont :

  • La définition des règles de codage
  • La maintenance va être réalisée en partie ou complètement par le client, il faut donc l'impliquer au plus tôt dans les aspects techniques afin qu'il puisse lire le code et trouver les artefacts nécessaires

En sortie de cette phase on doit disposer :

  • Du modèle de données (ce point peut être abordé en spécifications) et du modèle physique
  • De la liste des opérations de service avec la liste des règles de gestion qu'elles implémentent (traçabilité)
  • De la liste des objets de transferts avec leurs attributs
  • Des artefacts générés par l'outillage MDA

Pour le dernier point, il s'agit de pouvoir initialiser l'environnement de développement avec les éléments générés qui ne doivent pas être modifiés (cas de la couche d'accès aux données par exemple) et des éléments qui serviront de canevas aux développement (canevas des écrans par exemple).

La phase de développement

Lors de cette phase, en fonction de sa durée, il faut prévoir des points de visibilité avec le client. Ces points lui permettent de voir sa future application. Des maquettes des écrans ayant été réalisées en phase de spécification, il peut constater que l'application reprend ces maquettes à l'identique (ou au placement de certains champs à cause de la taille des écrans). Il n'est pas nécessaire que ces points de visibilités permettent au client de manipuler l'application car elle est encore en cours de développement et peut donc être partielle et contenir des bugs (sauf si les cas d'utilisation sont validés au fur et à mesure). Par contre, il faut montrer des cas d'utilisation différents à chaque point de visibilité pour rendre compte de l'avancement. Ces points rassurent le client et permettent de montrer que nous suivons ce qui a été défini en début de projet.

Les phases post-développement

Il s'agit des phases de tests, validation, installation et mise en production de l'application. Grâce au MDA, le rejet de l'application est un risque minime puisque le client a été dès le début en prise avec son futur logiciel. Certains cas d'utilisation peuvent être pris en main sans aucun formation. Il faut tout de même prévoir des journées de formation qui permettent de former les nouveaux utilisateurs qui n'ont pas assisté aux réunions et qui permettent également aux utilisateurs déjà habitués à l'application de la manipuler.

Conclusion

Cette organisation n'est pas une organisation absolue. Par exemple, il est tout à fait possible de mettre en place des méthodologies Agile et dans ce cas les points de visibilité se déroulent à chaque run et la manipulation de l'application par les utilisateurs finaux est moins risquée.
Pour des clients qui ne sont pas habitués au MDA, il y a une première phase de prise en main des documents. Ici, tout se joue sur la qualité des documents générés qui doivent être lisibles pour des personnes non initiées à l'UML. Les diagrammes sont alors un support pour les autres informations. Il ne faut pas hésiter à profiter d'UMl 2 pour modifier les icônes de certains éléments, on gagne ainsi en lisibilité.

par Sébastien Domergue le 2011-03-14 10:43

Tuesday 22/02/2011

Humeurs d'un libriste

HTTPS et SSH sur le même port : c'est possible !

Une façon très simple de limiter le nombre d'attaques sur le service SSH est de changer le port d'écoute habituel (port 22) et une façon courante de le rendre accessible depuis un réseau d'entreprise est de mettre ce serveur SSH en écoute sur le port 443, habituellement utilisé par le protocole HTTPS, et que les pare-feux et autres serveurs mandataires sont en général configurés pour laisser passer sans plus de formalités. Dès lors, un outil tel que Corkscrew permet d'encapsuler la connexion SSH dans un tunnel HTTPS et de traverser le serveur mandataire. Ça ne fonctionne pas à tous les coups mais l'essai est souvent fructueux. C'est pour cela que pendant plusieurs années, mes machines personnelles ont été configurées ainsi. Mais fin 2009, j'ai décidé d'installer sur mon serveur auto-hébergé un serveur HTTPS et j'ai donc du déporter sur un autre port le serveur SSH. Mais les ports non standard étant bloqués par la plupart des pare-feux, j'ai perdu au change.

J'ai récemment parlé de ce problème à un ami, lui indiquant que j'allais finir par basculer sur l'IPV6 - ce que me permet mon fournisseur d'accès - afin de disposer de plusieurs adresses publiques que je pourrais associer à la même interface réseau. Je configurerais alors le serveur HTTPS pour qu'il écoute sur le port 443 de l'une et le serveur SSH pour qu'il écoute sur le port 443 de l'autre. Cet ami m'a répondu, amusé, « toi, tu ne connais pas sslh ! »

Non, effectivement, je ne onnaissais pas sslh ! Quel est donc cet outil ? Tout simplement un démon auquel on spécifie trois ports : celui sur lequel il doit écouter, celui du serveur HTTPS et celui du serveur SSH. Selon qu'il détecte sur son port d'écoute une demande de connexion SSH ou HTTPS, il renvoie la requête sur le serveur idoine. Sachant cela, la configuration est évidente : on demande par exemple à sslh d'écouter le port 443 de l'interface publique et à OpenSSH et Apache d'écouter respectivement les ports 22 et 443 de l'interface loopback. Après avoir configuré les différents outils en prenant la précaution de spécfier à OpenSSH un second port d'écoute temporaire sur l'interface publique car je suis très doué pour faire des erreurs, j'ai relancé tous les démons. sslh fonctionne à merveille ! Codé en C, son empreinte mémoire est en outre minime et la petite latence qu'il introduit dans l'initialisation des connexions n'a rien d'handicapant pour un site peu sollicité. Simple et efficace, il suffisait d'y penser (et de le coder...) !

M'intéressant alors à l'auteur de cet outil, j'ai eu une surprise : il s'agit d'Yves Rütschlé, un ancien collaborateur toulousain de CS que j'ai eu le plaisir de croiser à mon arrivée dans la société et dont on m'avait dit le plus grand bien. Merci donc Yves !

par sdinot le 2011-02-22 14:56

Monday 21/02/2011

Guilhem Bonnefille

Git et SVN, de bons amis

Depuis plusieurs années maintenant, j'utilise SVN avec Git en frontend, grâce à l'excellent git-svn. Ainsi, je profite du meilleur des deux mondes :

  • un dépot central bien connu de tous et proposé en standard par nos outils de collaboration,
  • un dépot local qui m'offre réactivité (le réseau et Thor c'est pas toujours la panacé), disponibilité (même lorsque je ne suis pas dans les locaux) et liberté (je peux faire des branches à qui mieux mieux pour organiser mes travaux).

Avec le temps, j'ai pu constater que les outils de synchronisation proposés fournissent le travail attendu, mais sont de trop bas niveau pour une utilisation directe. Pour que leur utilisation soit aisée et avec le moins de risque possible pour mon travail, il faut scripter un peu. Là encore, l'environnement proposé par Git permet de solutionner le problème avec élégance :

  • stash : plutôt que de tout commiter avant de synchroniser avec SVN, git stash permet de mettre les modifications courantes en attente, le temps de la synchronisation,
  • alias : plutôt que de faire des scripts shell dans un coin, le mécanisme des alias permet d'intégrer ces scripts directement dans le jeu de commande de Git.

Trève de blabla. Voici la section que j'ai rajoutée dans mon ~/.gitconfig :

[alias]
	svnup = !DIRTY=$(git status --porcelain -uno) && \
		git stash save svn-up-auto && git svn rebase && \
		test -n \"$DIRTY\" && git stash pop

	svncommit = !DIRTY=$(git status --porcelain -uno) && \
		git stash save svn-up-auto && git svn rebase && git svn dcommit && \
		test -n \"$DIRTY\" && git stash pop

Et voilou. Maintenant, quand je veux mettre à jour mon espace ou publier vers SVN, il me suffit d'invoquer git svnup ou git svncommit et ce quel que soit l'état de mon environnement.

Comme il faut toujours rendre à César ce qui lui appartient, j'avoue que le principe du DIRTY a été repris d'un billet trouvé sur Internet.

par Guilhem Bonnefille le 2011-02-21 13:40

Wednesday 19/01/2011

Sébastien Domergue

Hudson change de nom

Le serveur d'intégration continue Hudson change de nom et devient Jenkins. La raison est qu'Oracle a déposé la marque Hudson et que la communauté a eu peur que ce produit ne redevienne commercial. Les négociations entre l'équipe Hudson et Oracle n'ont pas abouties. L'ensemble de la structure d'Hudson est donc en train de migrer (nouveau domaine, nouvelle organisation...) pour se détacher d'Oracle. Le billet intégral est disponible en anglais en suivant ce lien.

par Sébastien Domergue le 2011-01-19 08:50

Monday 03/01/2011

Sébastien Domergue

Résumé du Paris JUG Annotations

Mardi 14 décembre 2010 s'est tenu le dernier Paris JUG de l'année. Intitulé Java avancé, il s'agissait en fait d'un JUG sur les annotations Java. Une seule conférence occupait l'ensemble de la soirée, animée par Olivier Croisier de la société Zenika et auteur du blog The Coder's Breakfast.

Les annotations arrivent dans Java

Les annotations sont un mécanisme qui apparait dans Java 5 sous une forme embryonnaire. Les annotations sont intégrées car peu à peu, les balises Javadoc ont été détournées de leur emploi premier, notamment avec XDoclet.
Peu d'annotations sont proposées nativement dans Java (@Deprecated, @Override, @SuppressWarning) et 4 méta annotations (des annotations qui annotent des annotations). Mais le mécanisme global est présent. Une annotation est une information portant sur un élément du code source (élément au sens large : package, classe, méthode, attribut...). Cette information peut être utilisée au moment de la compilation ou au moment de l'exécution.
Les annotations permettent, par exemple, d'intégrer de informations de configuration dans le code source et c'est pourquoi elles ont été beaucoup utilisées au sein de frameworks. Hibernate/JPA permet de réaliser le mapping avec des annotations, Spring permet de faire de l'IOC ou encore les frameworks de validation.
De plus, chaque développeur peut créer ses propres annotations afin de proposer un outillage au sein de son équipe.
Une annotation peut disposer de paramètres. Lors de l'instanciation d'une annotations, la valeur d'affectation d'un paramètre doit être 'compile-time constants' et non nulle. La première contrainte s'explique par le fait que l'annotation est un élément qui est consommé pendant la compilation (bien que pouvant exister au runtime) et la seconde contrainte existe pour une raison totalement inconnue.
Une annotation ne peut être utilisée 2 fois avec des valeurs de paramètres différents. Pour cela, il est possible de recourir à des wrappers qui regroupent plusieurs annotations.

Créer son annotation

Une annotation se créé dans un fichier .java de la manière suivante :

public @interface MyAnnotation {
    String message();
    int answer() default 42;
}

Expliquons cette déclaration.
L'annotation est déclarée en tant que @interface afin de conserver la compatibilité entre versions, le compilateur remplace @interface par public interface ..... extends java.lang.Annotation. Pourtant, il est interdit d'écrire directement cette ligne.
Cette annotation dispose de deux paramètres qui sont pourtant déclarés comme des méthodes, un paramètre 'message' de type String et un paramètre 'answer' de type int et qui a pour valeur par défaut 42.
Pour l'instancier, on la déclare de la manière suivante :

@MyAnnotation(message = "un message", answer = 2)

Si une annotation ne dispose que d'un paramètre, le nommer 'value' permet de faire une affectation implicite de valeur à l'utilisation.
Une annotation est annotée par 4 méta annotations qui définissent son utilisation :

  • @Target : qui permet de définir sur quels éléments de code l'annotation peut être employée.
  • @Retention : qui permet de définir jusqu'ou l'annotation est conservée lors du cycle de build. Les valeurs possibles sont SOURCE (l'annotation sert alors d'outillage à l'environnement de développement), CLASS (l'annotation est traitée lors de la compilation mais est consommée) et RUNTIME (l'annotation est utilisée à l'exécution, elle est présente dans le byte-code).
  • @Inherited : qui définit si l'annotation est héritée d'un élément à l'autre. L'héritage fonctionne entre classe mère/fille mais non lorsqu'une classe étend une interface annotée car il n'y a pas d'héritage multiple mais il peut y avoir plusieurs implémentations et donc on pourrait aboutir à une situation où 2 annotations identiques avec des paramètres différents sont héritées sur la même classe.
  • @Documented : qui définit si l'annotation apparait ou pas au sein de la Javadoc de l'élément.

Une annotation peut être instanciée sur un package. Pour un package, qui n'est pas un fichier, il faut créer un fichier nommé package-info.java qui contient du texte dont voici un exemple :

/**
* Documentation du package
*/
@MyAnnotation
@Deprecated
package com.test.annotations.monpackage;

Outillage compile-time

Les annotations de type SOURCE et CLASS sont utilisées lors de la compilation ou par l'environnement de développement au travers de processeurs. Les buts de ces annotations sont :

  • générer des ressources : fichiers de configuration, classes annexes, documentation...
  • améliorer le compilateur : vérification de normes de codage, messages d'alertes ou d'erreur spécifiques à une méthodologie de codage...

Attention néanmoins, une annotation ne doit pas modifier les sources explicitement écrites par les développeurs. Par exemple, le projet Lombock qui propose de faire de l'encapsulation d'attributs en remplaçant les attributs publics en attributs privés accédés par des getteur/setter modifie le code à la volée en se branchant sur le compilateur. Son utilisation dépend donc en plus du support des différents compilateurs.
Les processeurs implémentent Processor ou plus communément étendent AbstractProcessor. Les environnements de développement ne supportent pas tous et à différents degrés l'utilisation des processeurs.

Outillage runtime

L'outillage runtime permet de traiter les annotations RUNTIME. Ces annotations présentes dans le byte-code peuvent être lues par introspection pour ajouter des comportements pendant l'exécution, par exemple un intercepteur. Un exemple de mapping objet / CSV a été présenté pour illustrer cette utilisation et on retrouve pratiquement une notation type Hibernate/JPA en quelques lignes et l'objet de sérialisation est très simple d'utilisation.

Ce qui peut être fait avec des annotations (attention, code moche et technique)

Les codes qui suivent montrent des possibilités des annotations et surtout pas des bonnes pratiquent à employer. Cependant, pour pouvoir relire du code annoté il peut être utile de les connaitre.

La perte du @

Le @ préfixant l'annotation peut être éloigné de l'annotation. Le code suivant est syntaxiquement correct :

@
/**
* Un pavé de javadoc
* qui peut contenir beaucoup
* de lignes
*/
Deprecated

L'injection d'annotation

Oui, oui, vous avez bien lu injection d'annotation et au runtime s'il vous plait. Il est donc possible d'injecter autant d'annotations que l'on veut sur les classes. L'injection est réalisée sur la définition de la classe et sera donc valable pour toutes les instances de la classe. En réalité, tout vient de l'introspection qui permet de réaliser les différents outillages afin de récupérer les annotations d'un élément. Sur la classe, il existe deux Map qui contiennent les annotations et qui sont donc accessibles grâce à la méthode getField(). Ces maps sont initialisées la première fois qu'elles sont accédées mais il existe une méthode d'accès pour chacune et elles sont instanciées de manière statique (ce qui permet donc de les manipuler une fois pour toutes les instances). Une fois la Map récupérée, il est possible d'instancier une annotation (je ne remets pas le code, il est disponible sur le site du Paris Jug) moyennant un Override des méthodes hashCode et equals puis de l'ajouter à la Map. Vu en démo, ça marche, par exemple pour redescendre les annotations d'une interface sur une classe d'implémentation (la gestion des conflits est réalisée arbitrairement dans l'outillage).
Pour les autres éléments du langage, il semblerait que la manipulation doive être effectuée sur une instance et donc la manipulation est à effectuer à chaque instanciation.

Les annotations sur les Generics

Dans les prochaines versions de Java, les Generics pourront être annotés également. L'exemple suivant pourra donc exister :

List<@NotNull String> maListe;

Mais également des écritures plus tordues :

String @NotEmpty monTableau @English [] = new String(){"yes"};

Qui signifie un tableau non vide de chaines en anglais. Lorsque plusieurs annotations seront utilisées, la lecture sera bien compliquée.

Conclusion

Cette soirée m'a permis de découvrir les annotations. Il est vrai qu'il s'agit d'un mécanisme que j'utilise très peu. Malgré 6 ans d'existence, l'outillage au sein des environnements de développement reste pauvre et la communauté divisée sur leur utilisation / pertinence. D'un point de vue personnel, ça me gène de mettre de la configuration dans mon code source car cela implique un nouveau build pour la prise en compte de modifications de configuration. C'est assez symptomatique des javaistes je l'avoue. Beaucoup d'entre nous ne veulent écrire que des fichiers .java. Donc pour remplacer XML, on a des annotations. C'est un peu écrire des classes java de description de vue au lieu d'écrire du HTML parce que le HTML/javascript/css c'est dur. Ce n'est pas notre outil de prédilection certes mais son rôle n'est pas de fournir du byte-code pour la jvm non plus. Chacun sa place.
Ce qui est plus grave à mon avis est la capacité d'injecter des annotations au Runtime. Je trouve que ça ressemble à un parfait vecteur d'attaque. Mais puisqu'il s'agit d'introspection et renseignements pris auprès du speaker, un SecurityManager qui interdit l'introspection doit suffire (une bonne pratique à ne pas oublier donc).
Ainsi se termine l'année 2010 du Paris JUG. Rendez-vous est pris pour les prochaines soirée et surtout pour l'anniversaire du JUG qui aura lieu le 28 février. A cette occasion, un Call for Papers est organisé pour de courtes présentations lors de cette soirée.

par Sébastien Domergue le 2011-01-03 16:39

Wednesday 22/12/2010

Guilhem Bonnefille

Sébastien Poncin, Directeur du site toulousain d'Astrium, invité de Toulouse FM

Ce mardi 22 décembre 2010, Sébastien Poncin, Directeur du site toulousain d'Astrium, était l'invité de Toulouse FM. Une interview intéressante pour notre région et notre secteur d'activité que je ne me risquerait pas à transcrire ici.

http://www.toulouse.fm/actualite-ca...

Bonne écoute !

par Guilhem Bonnefille le 2010-12-22 09:33

Tuesday 02/11/2010

Humeurs d'un libriste

Réutilisation du code des RFC

Pour mémoire, une RFC (« Request For Comments ») est la forme sous laquelle l'IETF (« Internet Engineering Task Force ») publie les spécifications des standards de l'Internet.

« Puis-je utiliser le code source inclus dans les RFC ? »

C'est la question qu'un collègue est venu me poser vendredi. Il faisait référence à l'annexe A de la RFC 4493 qui contient le code source d'un outil permettant de vérifier la justesse d'implantation de l'algorithme AES-CMAC. Les conditions d'utilisation de ce code ne sont indiquées ni dans le code source où seul le nom des auteurs apparaît, ni dans la RFC. Le code est juste précédé d'un vague avertissement :

This C source is designed to generate the test vectors that appear in this memo to verify correctness of the algorithm. The source code is not intended for use in commercial products.

La formulation de cet avertissement le rapproche plus d'une mise en garde quant à sa robustesse qu'à une réelle interdiction d'utilisation. Cependant, en l'absence de licence ou de mention particulière, nous devons considérer que le droit d'auteur le plus strict s'applique et que tout usage de ce code - seul ou inclus dans une application tierce - est proscrit.

Ceci est la règle. Mais une RFC étant la spécification d'un standard ouvert, il me semblait improbable qu'il soit interdit d'en réutiliser le contenu, fût-il du code source. Si la RFC n'en disait rien, c'était que l'autorisation devait être exprimée d'une manière plus globale. Je suis donc parti en chasse...

Après une recherche fastidieuse (une RFC n'est ni du Daniel Pennac ni du Tom Sharpe), je suis tombé sur les RFC 5378, intitulée « Rights Contributors Provide to the IETF Trust », et RFC 5377, intitulée « Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents ». Si celles-ci sont sans ambiguïté quant à la réutilisation des standards et des travaux de l'IETF (réservant la forme des RFC à l'IETF mais autorisant la plus large utilisation de leur contenu), elles n'évoquent pas explicitement le statut du code fourni dans les RFC. Mais j'ai finalement trouvé une réponse claire et positive dans la FAQ du document intitulé « Trust Legal Provisions » :

3 Rights Relating to Code

3.1 Can I use code that is included in IETF Documents in my software?

Yes. Code Components (see Question 3.2) that are embedded or included in IETF Documents published on or after November 10, 2008, can be used, copied, distributed and modified by anyone in any manner under the open source Simplified BSD License, as described in Questions 3.2 and 3.3. This is true even if the 6.c.iii Legend described in Question 4.2 s present in the IETF Document where the Code Component originates.

Code Components that are embedded or included in IETF Documents published during the period of RFC 3978 effectiveness, March 2005 to November 10, 2008, can be used, copied, distributed and modified in any manner under the license grant contained in 3.3.a.E. The IETF takes the position that the code license granted under RFC 3978 is compatible with most other open source licenses, thought it has not formally been recognized by the Open Source Foundation.

La RFC 3978 dont il est fait mention dans la réponse est l'ancêtre de la RFC 5378 qui définit les droits que doit accorder une personne à l'IETF pour que celle-ci prenne sa contribution en compte dans une RFC. Le point 3.3.a.E. de la RFC 3978 indiquait que le contributeur autorisait l'IETF à extraire, copier, publier, afficher, distribuer et incorporer à tout autre travail le code qu'il fournissait à l'IETF dans le cadre de sa contribution. Ce sont des termes proches de ceux de la licence BSD révisée mais la référence explicite faite aujourd'hui à cette licence a le mérite d'éliminer toute incertitude.

Pour mémoire, la licence BSD révisée (ou simplifiée) est une licence libre dite permissive (par opposition aux licences diffusives telles que la licence GNU GPL). On entend par là qu'elle autorise peu ou prou tout à l'utilisateur, y compris l'aliénation des libertés accordées par l'auteur originel du code. Inutile de vous dire que cette licence s'attire la plus grande sympathie des SSII et des éditeurs !

La réponse à la question que me posait ce collègue est donc « oui ». Il a bien le droit d'utiliser et d'adapter le code fourni dans l'annexe A de la RFC 4493 et, si nécessaire, de rediffuser le code originel ou modifié.

par sdinot le 2010-11-02 13:39

Thursday 28/10/2010

Sébastien Domergue

Tests de Play! Framework

Suite à la soirée Frameworks web du Paris JUG (un compte rendu ici), j'ai décidé de tester le framework Play!. Voici donc mes premières impressions au travers de la mise en place d'une application de post-it.
Pour rappel, Play! est un framework web full stack qui a pour but de fournir l'ensemble des bibliothèques Java nécessaires sous la forme d'un bloc cohérent.

Le mini-projet

Cet article reflète mon utilisation basique du framework Play! au travers d'un mini projet de post-it. Cette application doit permettre :

  • de créer des objets de type post-it qui ont : un titre, une date de création, un auteur et un contenu.
  • de supprimer un post-it.
  • d'ajouter des commentaires sur un post-it.
  • de n'être accessible qu'aux personnes authentifiées.

L'application comporte 2 écrans :

  • l'écran principal où tous les post-it associés à l'utilisateur sont affichés.
  • l'écran de détail d'un post-it où sont consultables l'ensemble des commentaires.

L'installation de Play!

Pour installer Play!, rien de plus simple. Le pré-requis est d'avoir une JVM en version 1.5 au supérieure. Un téléchargement depuis le site, une extraction dans le dossier de son choix et on crée la variable d'environnement PLAY_HOME qui pointe vers le dossier en question. On ajoute cette variable au path et puis c'est tout.
Pour vérifier l'installation, tapez dans une ligne de commande : play help et la liste des commandes disponibles s'affiche. On se place dans un dossier pour créer notre projet et on tape play new remindMe, le projet est créé. La commande play run remindMe lance le serveur web intégré. On peut alors se rendre via son navigateur à l'url http;//localhost:9000/ et on a une page de démarrage (vérifiez bien qu'aucun programme n'écoute déjà sur le port 9000, mon client VPN déconnecté avait ouvert ce port en écoute et donc le projet ne se lançait pas).
Cette première page diffère des pages que l'on trouve par exemple sur RoR car elle présente plus d'informations et surtout elle permet d'accéder à l'ensemble de l'aide sur le framework en mode déconnecté. Il s'agit de l'ensemble de la documentation disponible sur le site du framework au moment de votre téléchargement. C'est donc très utile car vous trouvez les mêmes informations sauf pour les modules externes bien sur. Un petit bémol néanmoins, l'accès à cette documentation suppose que le serveur est démarré et qu'aucune erreur de compilation ne survient dans les classes java. Sinon une erreur indiquant l'origine du problème est affichée et il faut commencer par la résoudre pour ensuite obtenir la documentation.
Pour coder, il suffit d'avoir un éditeur de texte car tant que le serveur tourne, il compile à la volée et redéploie à chaud. Personnellement je préfère avoir un IDE donc j'ai utilisé la commande play eclipsify qui génère les fichiers comme .project ou des launchers nécessaires à l'importation sous éclipse.
Maintenant que tout est prêt, entrons dans le vif du sujet.

La couche de persistance

La couche de persistance s'appuie sur JPA, du standard Java donc. Pour activer la persistance, le fichier de configuration de l'application doit être modifié, il faut dé-commenter la ligne db=mem afin de disposer d'une base de données volatile en mémoire. Positionné à fs, la base sera stockée dans un fichier. Il est possible de se connecter à de vraies bases et un exemple de paramétrage mySql est fourni en commentaire. Pour créer un objet persistant, pas de ligne de commande, on crée une classe qui étend Model. Cet héritage n'est pas obligatoire mais fournit un certain nombre de méthodes directement au sein de l'objet comme save, find, findById... Donc pourquoi réinventer la roue?
Le projet contient pour le moment 3 classes comme décrit dans le diagramme ci-dessous : Diagramme de classes Les classes disposent d'annotations pour exprimer qu'elles sont persistantes et pour définir les types d'objets. Par exemple, les attributs content ont une annotation @Lob car ils peuvent contenir de longues chaines de caractère.
A ce niveau, il est possible de tester unitairement notre couche de persistance. Pour la structure de la base, c'est Play! qui s'en charge directement. L'outillage pour les tests est fourni également grâce à JUnit pour les tests unitaires. Voici un exemple de test pour la sauvegarde d'un utilisateur :

// Create a new user and save it
new User("bBob", "secret", "Bob", "bob@gmail.com").save();
// Retrieve the user with e-mail address bob@gmail.com
User bob = User.find("byEmail", "bob@gmail.com").first();
// Test
assertNotNull(bob);

Pour effectuer les tests, il faut lancer le serveur Play! non pas avec play run mais avec play test. Cela permet d'accéder à l'url http://localhost:9000/@tests. Cette page permet de lancer les tests de l'application. Il y a trois catégories de tests : unitaires, fonctionnels et les tests selenium (tests d'IHM). Depuis cette page, on peut sélectionner la ou les classes de test à passer et conserver ces choix en bookmarkant la page. Utile pour passer les tests relatifs à un module uniquement. Je n'ai pas encore regardé du côté des tests fonctionnels et selenium, cela va venir.

Le modèle MVC

Play! est un framework MVC. Nous venons de voir l'aspect Model, l'aspect Vue/Contrôleur s'appuie sur deux artefacts : une page HTML pour la vue (dans 98% des cas) et une classe pour le contrôleur. Play! promeut le pattern Light controler, Fat Model. Cela signifie que la logique est stockée directement dans le modèle. Pardon pour les puristes mais pour des opérations de base de moins de 10 lignes, ça allège le nombre de couches (pour les besoins plus complexes, voir le module Spring décrit plus loin).

Le contrôleur

Il s'agit d'une classe dont chaque méthode static est en fait une url. La méthode ne retourne rien en elle-même, elle appelle une méthode render qui prend en paramètre l'ensemble des objets qui sont à placer dans le scope de la page à rendre. Pourquoi ces méthodes sont statiques ? A cause de la volonté de faire du stateless et de ne pas utiliser l'API Servlet. Puisque l'état n'est pas propagé et qu'une requête n'est pas traitée par un seul thread, il n'est pas vraiment nécessaire d'instancier des classes. Pour utiliser les paramètres d'une requête, la méthode statique a comme paramètres les paramètres de la requête. Par exemple, si on a un champ texte de nom content, mettre un paramètre de type String et de nom content suffit à faire le mapping. Il est bien sur possible d'utiliser des objets complexes avec une notation pointée dans les noms de champs.
Pour notre exemple, je choisis d'utiliser un seul contrôleur qui contiendra tous les points d'entrée. Ce choix est motivé par la taille de l'application qui est minime.
A noter qu'il est possible de valider les paramètres de la requête par annotations des paramètres mais aussi en utilisant @Valid qui permet de valider un objet qui dispose d'annotations internes.

La vue

La vue est une page HTML simple avec le système de template de Groovy. La syntaxe est relativement simple et il y a seulement une quinzaine de tags. Par exemple, pour afficher le contenu d'une variable disponible dans le scope, on écrit ${content}. Il est possible d'utiliser un canevas à la manière de sitemesh avec une directive extends. Le mapping entre une page et une méthode du contrôleur est effectuée en recherchant dans le dossier views un dossier du même nom que le contrôleur. Dans ce dossier, il est recherché un fichier html du même nom que la méthode. Comme définit initialement, l'application contient 2 pages donc j'ai 3 fichiers HTML : un fichier pour la page d'index, un fichier pour l'affichage détaillé et un fichier parent qui contient les imports de css, javascript et la mise en page globale.
Bien que mon application dispose de plus d'url, je n'ai pas besoin de plus de pages. Par exemple, l'appel à la création d'un post-it renvoie sur la page qui affiche les post-its donc dans la méthode save du contrôleur, au lieu d'appeler directement la méthode render() qui va chercher une page, j'appelle la méthode index() qui correspond au même besoin et c'est donc la page index qui est chargée.
Il est possible d'utiliser render sous plusieurs formes : Json, Html, Xml, Text ou Email. Cela permet de fournir par exemple des fragments de page qui seront utilisés via Ajax au lieu de charger une page complète.
En ce qui concerne les possibilités HTML, ce n'est pas Play! qui s'en charge. Ici le programmeur est libre de choisir ses composants de rendu. La bibliothèque JQuery est fournie de base mais non incluse dans le head par défaut et aucun composant JQuery UI n'est embarqué. Pour rester cohérent et par habitude, j'ai conservé JQuery auquel j'ai adjoint des composants JQuery UI (boîte de dialogue, capacité de glisser/déposer...).

Les tags

Il existe peu de tags dans le moteur de templates mais il s'agit des plus utiles. Pour créer un tag, il suffit de créer un fichier html dans le dossier views>tags. Le tag sera ensuite utilisable avec pour clé le nom du fichier HTML. Sur les bases du tutorial de Play!, j'ai créé un tag de rendu des post-its. Il est surtout là pour tester la création de tags puisqu'il est appelé une fois en mode court sur la page d'index et une fois en mode long sur la page de détails.

L'internationalisation

L'internationalisation est effectuée grâce à un fichier de properties par langue. L'application gère ensuite la langue par défaut en fonction de données de connexion de l'utilisateur. Pour ma part, cela a reconnu le français comme langue par défaut directement.

Les modules

Play! permet d'utiliser des modules complémentaires, sortes de librairies à la sauce Play!. J'ai utilisé le module secure pour la gestion de l'authentification pour l'application. Ce module permet d'annoter un contrôleur pour protéger l'accès aux urls et permet de fournir l'identifiant de l'utilisateur connecté. En revanche, la méthode pour vérifier l'authentification est à fournir. Cela permet d'être plus souple quant au système de gestion des identités. Pour cela, il faut créer une classe dans le package controllers qui étend Secure.Security et de réimplémenter la méthode static boolean authenticate(String username, String password).
En première intention, j'ai utilisé une authentification basique où le couple login/mot de passe devait correspondre à une entrée de la table User. Si l'authentification réussit, le paramètre username est stocké dans le cookie Play! et peut donc être réutilisé dans le contrôleur grâce à l'appel Security.connected(). En revanche, à ce moment on atteint la limite de l'utilisation de l'IDE. En effet, le module est déclaré dans le fichier de configuration et il est chargé grâce à Play! en tâche de fond. Il s'agit non pas d'une intégration de jar mais d'une intégration d'une sous application et je n'ai pas trouvé de moyen de mettre à jour le buildpath pour importer la classe Secure car le dossier qui contient le module ne supporte pas l'éclipsification (une erreur est retournée) et que je n'ai trouvé aucun jar externe à importer. Bilan, mon contrôleur est indiqué comme non compilable par Eclipse mais fonctionne parfaitement.
Pour aller plus loin, je voulais pouvoir disposer d'un interfaçage LDAP pour ne pas encore ajouter un login/mot de passe aux utilisateurs. La première piste est l'utilisation de SpringLdap grâce à l'utilisation du module Spring dans Play! Ce module permet d'utiliser l'IOC comme on en a l'habitude (utile pour des applications plus lourdes en termes de règles de gestion) mais utiliser Spring pour intégrer son module LDAP devenait trop lourd donc je suis revenu à l'ancienne méthode à savoir coder ma lecture LDAP. Le besoin ici est de pouvoir trouver une entrée de type People dans un ldap à partir de l'uid et du password. En utilisant le package javax.naming, une connexion LDAP s'effectue en une dizaine de lignes puis la recherche en autant. Si la recherche est fructueuse, c'est que le couple login/mot de passe est correct. Une solution complémentaire aurait été de tenter de se connecter directement au LDAP avec le couple fournit et de voir si la connexion réussit ou non. Puisque mon LDAP est accessible en anonyme et que je vais utiliser les informations récupérées pour construire mon objet User, je passe par la recherche. Petite subtilité, vu que le mot de passe est stocké sous forme d'empreinte, la recherche doit se faire avec l'empreinte du paramètre password. Si la recherche fonctionne, et que mon application n'a aucun utilisateur avec le même username, j'utilise le LDAP pour en créer un pour éviter que mes objets n'aient des références à des identifiants du LDAP qui peuvent évoluer indépendamment et pour minimiser le nombre de requêtes.

Les évolutions

Actuellement, les utilisateurs ne peuvent voir que les post-its dont ils sont les auteurs ce qui fait que le mécanisme de commentaires a ses limites. Je réfléchis à la manière d'ajouter d'autres utilisateurs et plusieurs pistes sont possibles :

  • Affecter le post-it à d'autres utilisateurs.
  • Ajouter la notion de projet où tous les membres du projet verraient tous les post-its.

En associant les deux points précédents et en ajoutant des catégories internes au projet, on obtient un tableau de développement agile !
Une interface d'administration pour gérer les utilisateurs et le paramétrage LDAP est prévue également (peut être via l'utilisation du module crud).

Conclusion

Je ne pourrais pas quantifier précisément le temps passé sur cette prise en main car je l'ai faite en pointillée et surtout j'ai pas mal tatonné surtout d'un point de vue rendu graphique. Mais je ne pensais pas obtenir un tel résultat si rapidement de toute manière et surtout pour un développeur Java je ne vois pas de problème technique majeur.
Merci à ceux qui auront lu cet article dans son ensemble. Si vous avez des questions, remarques, n'hésitez pas.

Captures

Voici des captures d'écran de l'application dans son état actuel. Les post-its sur la page d'index sont déplaçables par glisser/déposer.
ConnexionPage d'indexPage de détails

par Sébastien Domergue le 2010-10-28 13:35

Tuesday 26/10/2010

Jean-Christophe Arnu

Le programme du PGDay Europe 2010 est enfin disponible

Le programme du PGDay Europe 2010 se tenant à Stuttgart du 6 au 8 décembre est disponible ici.

Ce programme est riche en conférences, il sera difficile de faire un choix de salle et de conférence tant toutes sont intéressantes. Pour ma part, mon choix se porte sur :

  • Cloud in 30 minutes: Develop and deploy a business application in 30 minutes on top of Postgresql. Hands-on.
  • Managing PostgreSQL Replication
  • PostGIS 1.5 and beyond: a technical perspective
  • Rapid Upgrades With Pg_Upgrade
  • Advanced PostgreSQL Access from Python with Psycopg
  • Developing PostgreSQL Performance
  • How a large organisation moved its critical application toward PostgreSQL ou Why your PostgreSQL 9.0 cluster needs pgpool-II
  • MVCC Unmasked
  • Postgres-XC: Write-scalable Shared-Nothing PostgreSQL Cluster
  • PgFincore and the OS Page Cache (Is my table in memory ?)

Les conférences sont suivies d'une journée de «tutoriels», je choisirais pour ma part :

  • Introduction to PostGIS: an open-source spatial database
  • Streaming replication and Hot Standby

par jca le 2010-10-26 09:05

Wednesday 13/10/2010

Sébastien Domergue

Résumé du Paris JUG Web et Java

Cet article est un résumé des sujets abordés lors du Paris JUG du 12 ocotbre qui a eu lieu dans les locaux de l'ISEP. Cette nouvelle session abordait le couple Web/Java au travers de 3 sessions (2 courtes, une longue). Les deux sessions courtes abordaient les thèmes de Rubis On Rails et HTML5 tandis que la dernière présentait Play! Framework. Comme d'habitude pour ces résumés, d'abord ce qui a été dit puis je donnerais mon avis.

Ruby On Rails : la conversion d'un javaiste

Cette présentation courte était assurée par Christian Blavier (Octo Technology) et n'était pas un énième HelloWorld RoR. Il s'agissait d'un retour d'expérience d'un javaiste qui est passé à RoR et la présentation de certaines fonctionnalités spécifiques de RoR. Ruby On Rails est un framework web pensé pour rendre le développeur "heureux". Il s'agit d'un des (du ?) seuls frameworks qui annonce cet objectif.
Pour Christian, RoR intègre une multitude de petites bonnes idées faites pour simplifier le développement. Les closures, les urls lisibles ou les tests dont tout l'outillage est fourni en sont des exemples. D'ailleurs certaines choses se retrouvent ensuite chez Java après intégration.
L'aspect tests a été abordé car RoR fournit tout l'outillage pour faire des tests unitaires, d'intégration et sur les vues. Des gems (librairies ruby) supplémentaires permettent également d'écrire ses tests sous une forme impérative (j'ouvre mon application, étant donné que '...' existe...) qui associée à une grammaire traduit du texte en test, très impressionnant.
Ont ensuite été présentés d'autres gems supplémentaires améliorant la productivité mais démontrant surtout l'intérêt de la communauté pour Ruby On Rails.

HTML 5

Cette session courte était animée conjointement par Cedric Beurtheret et Alain Duval (Objectif). Etant donné le temps imparti à la présentation, tout HTML5 ne pouvait être abordé.

Un peu d'histoire

HTML dans sa version 4 date déjà de 1998. Suite à la finalisation de la spécification, l'écosystème web s'est focalisé sur le XHTML est la représentation XML de documents. La norme a été laissée à l'abandon jusqu'en 2004 où les travaux sur le HTML5 ont débuté sous l'impulsion de trois organismes majeurs. Malgré cela, HTML5 n'est toujours pas finalisé et surtout on ne connait pas la date de finalisation! Néanmoins, les stades initiaux des simples drafts ont été dépassés et certaines parties sont proches de la finalisation et n'évoluent que peu. C'est notamment le cas des webforms. Après un bref listing de ce qui évolue dans HTML5 (pour une liste complète je vous conseille de faire un tour sur le site du W3C), nos speakers abordent l'utilisation de HTML5 au sein d'un de leur projet (encore en développement) en se focalisant sur 3 technologies HTML5 : les webworkers, le cross window messaging et le local storage.

Le passage à HTML5

Le projet en question est un projet Web devant être exploité en mode déconnecté sur des terminaux mobiles. L'architecture se compose de clients sur TabletPC qui ne disposent pas d'une connexion permanente, même en 3G, d'un serveur intermédiaire "classique" et d'un serveur en backend en AS/400 qui est un pré-existant. Afin de travailler en mode déconnecté, le projet a été initialement développé avec Gears mais Google ayant annoncé la fin du support de Gears et incité à migrer massivement vers HTML5, ce projet a migré.

Les Webworkers

Il s'agit de pouvoir exécuter des taches de fond en javascript sans bloquer la fenêtre principale de l'application à la manière d'un thread parallèle. Cela évite par exemple l'apparition du message "un script ralentit votre navigateur, voulez-vous le suspendre?". Dans le cadre du projet, cette méthode a été utilisée pour synchroniser périodiquement le client déconnecté et le serveur central. La limitation est que le script qui s'exécute n'a pas accès au DOM puisque pour ce script les objets document/window/parent n'existent pas.

Le cross window messaging

Cette technologie permet d'envoyer des messages à une autre fenêtre. Cette fenêtre dispose d'un listener javascript sur l'évènement "message" et peut traiter le contenu du message. L'envoi de message peu se faire vers un autre domaine mais le domaine source est envoyé avec le message ce qui permet de filtrer les messages en provenance uniquement de domaines "connus". Cela permet par exemple de déployer une application centrale en charge de la sécurité, du menu et d'informations transverses puis de déployer une multitude de petites applications auxquelles sont transférées les données de connexion pour fournir de l'information (comme un mashup d'applications interconnectées). C'est ainsi que le projet utilise le cross window messaging.

Le local storage

En mode déconnecté, il faut pouvoir conserver les données. HTML5 propose trois mécanismes pour cela. Un stockage de type session qui est limité à la durée de vie de la fenêtre. Un stockage persistant qui persiste le stockage précédent mais de type Map et limité à la taille d'un cookie. Le dernier enfin est un stockage persistant sans limite de volume de type SQLLite ou MongoDB (HashTable NoSQL). Pour le moment HTML5 n'impose pas l'implémentation de l'une ou l'autre des technologies ce qui laisse donc le choix aux navigateurs. Il semblerait que l'approche NoSQL gagne du terrain. Dans l'exemple que nous avons eu, SQLLite était utilisé. La structure de la table était créée par une instruction SQL contenue dans le javascript. L'appel SQL peut déclencher deux évènements, l'un de succès l'autre d'erreur ce qui correspond à deux fonctions de callback.

Exemple

Un petit exemple d'une page utilisant toutes ces trois technologies a été présenté, les codes sources de la présentation étant tirés de cet exemple. Le temps de la présentation ne permettait pas trop de manipuler l'exemple mais il avait le mérite d'exister.

Conclusion

Faire du HTML5 peut être un avantage aujourd'hui si on a la main sur le navigateur client. En effet, les différents niveaux d'implémentation ainsi que les interprétations de spécifications alors que celles-ci ne sont pas finalisées ne permettent pas réellement d'être interopérable. De plus, il faut pouvoir disposer de versions récentes des navigateurs (ndla : pour travailler dans des environnements fermés, ce n'est pas toujours évident).

Pause et quizz

Comme d'habitude lors du JUG, un petit quizz permettait de gagner des livres et des licences IntelliJ. Merci à l'équipe du JUG. La pause a également été l'occasion d'annoncer des week-ends de type "startup weekend" mais orientés plate forme mobiles. Le prochain est un week-end iOS et celui du mois suivant Android.

Play! Framework : un an après, 100 000 téléchargements plus tard

Pour cette session d'une heure, ce sont Guillaume Bort (Zenexity et initiateur du framework Play!) et Nicolas Martignole (Blog Le Touilleur Express) qui étaient les speakers. Avant toute chose, Nicolas nous expose son point de vue sur la complexité des applications Java. Il pense qu'une partie de la complexité qu'on retrouve est avant tout culturelle et de notre faute en tant qu'architectes/développeurs, notamment pour repousser l'écriture de pages HTML, du CSS et de Javascript. Pourtant, pour des applications Web, ne pas vouloir écrire ces artefacts revient à ne pas vouloir parler anglais. Ce qui explique ce que n'est pas Play! : un framework de présentation. Play! ne fournit pas de mécanisme de présentation avancée, cela est dévolu à du code HTML/CSS/Javascript avec par exemple JQuery (ou HTML5). Le mécanisme de rendu est celui de Groovy pour le template des pages.
En revanche, Play! est un framework Web full stack (ce terme sera détaillé plus loin) et totalement stateless. Son orientation Web se voit surtout au niveau des URLs qui sont de la forme http://www.monapplication.com/action/parametre1/parametre2 qui sont donc des urls lisibles et bookmarquables.

L'abandon de l'API Servlet

Oui oui, vous avez bien lu, l'API Servlet n'est pas utilisée par un framework Web. Cela vient de la volonté de se débarrasser de l'énorme pool de thread qui ne sert qu'à mettre en attente les requêtes tant qu'elles ne sont pas traitées. L'image qui est prise est celle du McDonald's. Quand vous arrivez, vous choisissez tant bien que mal une file (travail du loadBalancer). Une fois dans cette file, vous attendez votre tour. Une fois arrivé, une personne se charge de vous, prend votre commande, la prépare, vous la donne et vous partez pour laisser la place au client suivant. L'intérêt est qu'une seule personne a été en charge de votre commande mais cela a bloqué la suite de la file. L'API Servlet est identique à se fonctionnement et pour chaque requête en attente, il faut un thread!
A l'inverse, il y a le fonctionnement des Starbucks (ndla : les exemples sont bien ceux évoqués, je ne fais pas de pub) où il n'y a qu'une seule file d'attente et où votre commande est prise le plus rapidement possible par une seule personne. Une fois la commande prise (action très rapide), plusieurs personnes sont dévolues à préparer l'ensemble des commandes (ce qui permet de préparer plusieurs commandes en même temps) puis tous les clients obtiennent leur commande au même endroit dès que celle-ci est prête. Play! se veut une implémentation de ce pattern. Toutes les requêtes arrivent sur le même thread qui "prend en compte l'url". Cette url est transmise au contrôleur adéquat qui se charge de préparer les données à rendre. Une fois l'url transmise, le thread traite l'url suivante et ainsi de suite. Dès qu'un contrôleur a terminé, il fournit sa réponse à un thread de sortie qui "push" les sorties vers le bon client. En développement, il est tout à fait possible de n'avoir qu'un seul thread pour l'ensemble de l'application et en production sur un processeur quad-coeurs, d'avoir 4 threads et traiter environ 3000 à 4000 hits par seconde.
En plus de l'abandon de la Servlet, Play! veut réutiliser la session pour ce qu'elle était et non plus comme un cache ultra volumineux. Play! va donc utiliser seulement un cookie (donc limité à 4Kb attention) et l'objectif est que ce cookie contienne les informations de connexion, la langue par défaut, la couleur préférée... Ce cookie est transmis chiffré pour minimiser les modifications côté client. Ce qui implique donc que la communication est totalement stateless et que la montée en charge est linéaire. En effet, puisque seul le cookie est nécessaire, il peut être traité par deux serveurs différents de la même manière. Si le cache est vraiment nécessaire, il peut être utilisé (et éventuellement partagé) mais il est défini comme tel et techniquement différent de données de session au sens du navigateur.

Un framework full stack

L'objectif de Play! est de fournir l'ensemble des librairies nécessaires sous un seul bloc pour disposer d'un ensemble cohérent. Il reste possible d'utiliser des librairies externes en les plaçant dans le répertoire lib. Le framework Play! vient donc avec :

  • un compilateur interne et incrémental (celui d'Eclipse)
  • Un serveur web
  • Une couche de mapping OR et une base de données en mémoire intégrée pour les tests / développements.
  • Les tests avec l'intégration de JUnit mais aussi de Selenium
  • Le support de Scala

Les deux premiers points associés à l'aspect stateless font qu'il est possible de développer avec un bloc note et de bénéficier du déploiement à chaud. Il suffit de lancer "play run" puis de modifier ses fichiers, les enregistrer et la compilation et de déploiement à chaud s'effectuent immédiatement, il suffit de recharger la page pour visualiser la modification (sans perdre les autres informations). Si la compilation échoue, l'erreur est affichée dans le navigateur. Il est néanmoins possible d'utilisateur un IDE (un plugin Eclipse officiel est disponible) mais non nécessaire.
De même, l'exécution des tests et la visualisation du résultat peut être commandée depuis la navigateur. Ici, on voit l'intérêt d'une url bookmarquable ainsi il est possible d'accéder rapidement à certains tests. Couplé à Selenium qui est déjà intégré, il est possible de passer en revue tous les tests unitaires pour synthétiser le résultat. L'intégration continue est donc quasiment offerte.
Le framework Play! semble aussi armé pour la sécurité mais le temps ne permettait pas d'approfondir le sujet (contrôle d'accès, prévention du XSS...).
Le mode déconnecté semble aussi être géré d'après une vidéo vue en toute fin de présentation mais le sujet n'a pas été abordé non plus.

Déploiement

Pour déployer une application Play!, il faut ... une machine avec Java. Deux modes sont disponibles : autonome ou sous forme de War qui s'installe sur tout serveur d'applications. A noter que Glassfish va intégrer un connecteur Play! natif. La plateforme playapps permet de faire un déploiement sur le cloud également.

Cas d'utilisation

Play! peut être utilisé en production mais également pour maquetter rapidement des idées avec une dynamique et de la persistence afin de pouvoir discuter avec le client de manière plus approfondie qu'une maquette statique. Une mini session de live coding a également eu lieu ce qui permet de voir que la documentation est incluse dans les projets Play! donc même dans le train il est possible d'accéder à la documentation. D'un point de vue purement technique, Play! reste du Java avec du Groovy pour les tags (une quinzaine de tags à connaitre) et tout le système de templates.

Conclusion personnelle

Avant toute chose je remercie les speakers des trois conférences que j'ai appréciées. Puisque nous avons eu trois présentations sur des sujets différents sur le plan technique, je vais faire trois conclusions. La prochaine soirée aura lieu le 9 novembre et aura pour thème les moteurs de règles.

Ruby On Rails

Bon, j'avoue, je n'accroche pas trop à RoR. Mais il s'agit là d'un avis purement personnel sans doute motivé par une inexpérience sur le sujet. Malheureusement la présentation a eu un peu de mal à démarrer à cause de slides illisibles ce qui m'a fait un peu décrocher mais il reste que RoR est riche, bien implanté dans l'esprit collectif (pour le startup week-end qui s'est déroulé, beaucoup de projet l'ont utilisé dont 2 dans le top 3) et actif. RoR 3 vient d'être mis à disposition et la communauté reste très vivante.

HTML5

Les nouvelles possibilités du HTML5 étaient nécessaires tant l'usage du Web est devenu primordial. Je trouve dommage qu'il persiste des guerres de clocher (pour le multimédia notamment) et que pour le moment les organismes de spécifications ne tranchent pas. A présent, sur les trois technologies présentées, je trouve que les webworkers et le local storage sont les bienvenus. Je regrette un peu que les webworkers ne puissent accéder au DOM de la page en cours mais je comprends aussi pourquoi ils ne le font pas. Le local storage permet de développer pour du mode déconnecté mais pose le problème de la synchronisation ce que je trouve tout à fait normal car chaque application peut avoir des politiques différentes sur ce point. En revanche, je suis beaucoup plus mitigé à cause de la possibilité d'envoyer des messages entre plusieurs domaines. Alors oui il est possible de traiter la réception du message le domaine émetteur mais l'identification du domaine reste une donnée qui transite sur le réseau, éventuellement en clair ou presque (puisque tous les navigateurs sont censés pouvoir utiliser cette technologie) et est interprétée en javascript du côté de la fenêtre cible ce qui introduit, à mon sens, trop de risques. Libre à chacun ensuite d'utiliser ou pas le listener dans son application et je pense que les navigateurs mettront en place des mécanismes de protection mais il faudrait que je me penche plus sur les spécifications détaillées pour être sur de mon avis.

Play! Framework

L'effet Waouh a bien marché sur moi, je l'avoue. Bon, étant un accro de l'IDE je vais surement le tester au sein d'Eclipse mais la possibilité de coder par exemple sur un netbook avec juste mon bloc note est alléchante car au final on ne perd que l'auto complétion (et encore, maintenant certains éditeurs légers peuvent proposer des choses) et les informations sont disponibles dans le navigateur. Le tout couplé avec du Scala pour obtenir du fonctionnel en Java et les tests qui font partie du voyage. Néanmoins, le full stack a aussi son mauvais côté puisque l'environnement des librairies est plutôt fermé. Il y a bien le répertoire lib mais l'objectif est de mettre tout au plus quelques jars supplémentaires. Toujours est-il que je vais de se pas le tester.

par Sébastien Domergue le 2010-10-13 12:45

Tuesday 28/09/2010

Humeurs d'un libriste

OpenOffice se meurt, vive LibreOffice !

Lassés de la politique indigente d'Oracle envers OpenOffice et de l'avenir incertain que réservait l'éditeur au projet depuis le rachat de Sun, les principaux contributeurs de la célèbre suite bureautique viennent d'annoncer un fork du projet baptisé LibreOffice. Ces contributeurs ont formalisé leur projet en créant une fondation nommée The Document Foundation.

Si le communiqué de presse emprunte un ton tout diplomatique, on se doute que cette sécession ne s'est pas faite sur un coup de tête. Elle confirme les craintes exprimées par nombre d'acteurs du libre lors du rachat de Sun par Oracle. Des craintes similaires planent sur MySQL mais là, le problème est moins critique vu que des alternatives avantageuses à ce SGBDR existent (notamment PostgreSQL pour adresser les besoins complexes et SQLite pour adresser les besoins simples).

En attendant, souhaitons la bienvenue à LibreOffice et saluons cette initiative comme il se doit !

par sdinot le 2010-09-28 09:22

Monday 20/09/2010

Jean-Christophe Arnu

PostgreSQL 9.0 est sorti

Je ne souhaite pas paraphraser le press kit que nous avons traduit chez PostgreSQLFr alors voici un lien qui en dit plus sur la nouvelle mouture de ce moteur de base de données libre.
Juste pour vous mettre l'eau à la bouche, il faut savoir que PostgreSQL n'est pas passé en version 8.5 mais en 9.0 car des fonctionnalités majeures comme, entre autres, la réplication par flux ont été ajoutées! N'attendez plus plus l'installer et la pousser dans les propositions commerciales!

par jca le 2010-09-20 14:51

Friday 10/09/2010

Sébastien Domergue

MDA : transformer les modèles

Voici la suite des articles à propos de la méthodologie MDA. Les précédents sont disponibles ici et . Celui-ci va traiter de la mise en place des transformations de modèle au cours d'un processus MDA.

Dans mon précédent billet, j'ai évoqué les grandes lignes de la mise en place de la modélisation dans un processus MDA. Une fois que le profils UML ont été créés et que les modèles ont été préparés, il faut les utiliser. Je ne traiterai pas ici de la génération de document car elle est proposée pratiquement par défaut sur tous les outils et qu'un commentaire précédent m'a très justement fait remarquer que la documentation n'est qu'une image statique du modèle à un moment précis. Bien que je pense qu'il faille aussi des supports plus conventionnels en fonction de l'interlocuteur, je suis d'accord sur l'aspect statique d'un document généré. Ce billet a pour but, comme le précédent, de proposer une réflexion à avoir avant de se lancer dans l'écriture de transformations de modèles.

Pourquoi transformer un modèle plutôt que de le compléter ?

La réponse est simple : pour conserver la lisibilité et l'indépendance. Initialement, le modèle contient des données de très haut niveau : types d'utilisateurs, cas d'utilisations, place d'une application dans le SI... Il s'agit d'informations issues directement du dialogue avec les fonctionnels du projet et surtout, techniquement indépendantes. Le projet doit s'inscrire dans les processus de travail et non l'inverse. Ce premier modèle est en quelque sorte la transposition de la manière de travailler des utilisateurs finaux. La question qui est posée tout au long de la rédaction de ce modèle est "Quels sont les étapes clés que vous devez effectuer pour réaliser cette action ?".
Ce modèle fini, se pose la question du "Comment ?". Cette question, au final, intéresse peu les utilisateurs. Ce qui les intéresse est la façon dont ils vont utiliser le système mais l'ensemble des opérations techniques réalisées leur est inutile. Intégrer des informations d'ordre technique n'a donc que pour finalité de complexifier la lecture du modèle.
De plus, si le projet évolue et change de technologie, comment extraire les informations techniques qui y ont été ajoutées ? C'est impossible de le faire avec une maitrise totale et surtout cela prend du temps.
Une transformation de modèle peut être décomposée en 3 étapes : copie du modèle initial dans un nouveau modèle, application de méthodes sur le modèle pour modifier/ajouter des composants, nettoyage du modèle final. La transformation la plus basique va donc, au minimum, copier à l'identique le modèle initial vers un autre modèle qui pourra être manipulé sans craindre de perdre des informations dans le modèle initial.
Pour inclure les données techniques, on conserve donc le modèle fonctionnel dans l'état puis on le dérive grâce aux transformations.

Le but d'une transformation

Une transformation de modèle a pour but d'utiliser les informations contenues dans un modèle afin de fournir automatiquement de nouveaux artefacts UML en fonction des cibles techniques. Par exemple, pour implémenter le pattern DAO (Data Access Object), une transformation va générer une classe de type DAO par classe persistente du modèle. Cette classe DAO sera nommée en fonction de l'objet persistent qui lui correspond et contiendra des méthodes de lecture et d'écriture. Cette classe ne sera générée que pour les objets persistents et non pour tous les autres.
Idéalement, une transformation doit contenir un processus qui ne concerne qu'un choix technologique et les méthodes utilisées doivent automatiser les modifications du modèle soit jusqu'à ce que l'intervention humaine soit nécessaire soit jusqu'à l'implication d'un nouveau choix technologique. Dans ce second cas il est préférable d'avoir deux transformations qui se succèdent immédiatement (sans retouche du modèle) que d'avoir une transformation monolithique à réécrire en cas de modification de la technologie.
J'ajouterai que la phase de nettoyage peut devenir rapidement pratique pour ne conserver que les objets UML pertinents mais attention à ne pas trop élaguer pour pouvoir chainer des transformations si besoin.

Identifier un processus de transformations

Chaque usine MDA peut être différente dans son processus de transformations en fonction des habitudes de réalisation que l'on a. Il n'y a pas de bon ou de mauvais processus de transformation, il faut en revanche en identifier un qui sera figé. La question à se poser est : quels sont les besoins en entrée de ma transformation ?
Il ne faut pas se limiter à un processus linéaire de transformations, un processus en forme d'arbre peut également être envisagé. Prenons l'exemple d'une application de gestion qui aura pour cible une plate forme n-tiers. Dans un premier temps, nous disposons d'un modèle fonctionnel contenant les différents cas d'utilisation et scénario de l'application. Pour une architecture n-tiers, ce modèle peut être à l'origine d'un modèle qui génèrera les suites de tests de validation (tests qui sont donc générés sans prise en compte des techniques utilisées), d'un processus de transformations pour la couche de persistence, d'un pour la couche de services et d'un pour la couche de présentation. Éventuellement deux processus peuvent se rejoindre car ils ont besoin l'un de l'autre pour proposer plus d'artefacts.

Impact des modifications

Une modification du modèle est faite au plus haut niveau possible, éventuellement au sein du modèle fonctionnel si besoin (il ne faut pas hésiter à le mettre à jour au cours de la vie du projet). Suite à une modification, il faut relancer les processus de transformation qui ont pour origine le modèle impacté et non recopier la modification dans tous les modèles. Cela permet de disposer d'informations de transformations dont disposent certains outils pour savoir d'où provient un artefact. Par exemple, si une règle de gestion est modifiée, refaire le processus va montrer les impacts qu'ont la modification (méthode de service à modifier, modification de l'ihm...). Cela permet aussi d'éviter les oublis de correction.

Cas de la génération de code

La génération de code est un peu à la marge du processus de transformation mais en est une finalité. Le "code" (ou tout artefact généré) est un produit final du processus MDA puisqu'il "sort" de la modélisation. Certains produits permettent de garder un lien entre le code et le modèle mais le formalisme UML est déjà perdu, ce lien sert au final peu. Il sert principalement à faire du reverse engineering sur les noms de méthodes et d'attributs ce qui est contraire à l'approche descendante MDA. Il est quand même important d'identifier quand un artefact peut être généré, c'est à dire que le modèle contient suffisamment d'informations pour fournir l'artefact sans avoir besoin de modifier les objets existants du modèle. Une génération au plus tôt permet d'éviter de devoir systématiquement refaire toute la chaine de transformation pour disposer du code après 5 ou 6 transformations alors qu'une seule n'est utile. De plus, les transformations successives pourraient rendre la génération de code non conforme si des informations sont modifiées pour générer d'autres artefacts.
On distingue deux types de génération de code : la génération finale qui ne doit pas faire l'objet de modifications de la part des développeurs et la génération partielle qui n'est qu'un guide. Pour ce deuxième type, il est possible de coupler l'usine MDA avec des outils spécialisés dans la génération de code (Acceleo en est un exemple) qui permettront de regénérer le squelette d'un artefact bien qu'un développeur y ait fait des modifications grâce aux notions de portions protégées qui sont gérées dans ces outils mais pas encore dans toutes les usines MDA.

Conclusion

L'étape de mise en place des transformations est la plus longue dans la mise en place d'une approche MDA dès qu'il s'agit d'utiliser des transformations personnalisées. De plus en plus de transformations "standards" existent mais pour une entreprise qui a investit sur un framework interne devra écrire ses transformations spécifiques pour ne pas perdre l'investissement sur le framework. Néanmoins, des transformations personnalisées sont aussi un moyen de maitriser très finement les artefacts générés et l'organisation des modèles qui constituent un projet.
Ces trois articles clôturent la présentation générale des principes du MDA et de la démarche à adopter pour initier une approche MDA. Je ne puis dire encore sur quels aspects les prochains billets MDA porteront, d'ailleurs si des personnes ont des questions à me poser, cela pourra orienter les prochains billets.

par Sébastien Domergue le 2010-09-10 11:28

Friday 03/09/2010

Humeurs d'un libriste

Attribut @font-face de CSS 3

Si vous créez de temps à autres des pages HTML en essayant de leur donner un peu de cachet, vous connaissez sans doute le cruel dilemme du choix des polices : soit vous prenez des polices classiques, couramment installées sur les postes de travail et le rendu sera partout peu ou prou le même mais l'identité de votre site sera faible, soit vous prenez des polices plus exotiques donnant à votre site une identité plus forte mais, les polices choisies n'étant généralement pas installées sur les postes de travail, le rendu ne sera généralement pas celui que vous escomptiez en créant vos pages sur votre machine (qui, elle, dispose bien des polices requises). C'est réellement rageant !

Comme ce problème se pose en général sur des éléments structurants tels que les titres et les menus, son contournement classique consiste à créer dans un éditeur bitmap tel que The Gimp une image du texte, enrichi de moult effets graphiques pour bien montrer qu'à défaut de sens esthétique, nous savons user et abuser des filtres et scripts proposés.

Même réussi, le résultat pose à son tour un certain nombre de problèmes. Une image est pour un logiciel un amas binaire sans la moindre signification et il ne peut donc en extraire le texte utile. L'effet de bord le plus nuisible est que les moteurs de recherche ne peuvent analyser le contenu de vos pages et référencent donc très mal votre site. Le même problème se pose à une personne qui souhaite copier-coller un de ces textes fournis sous forme d'image (par exemple, vos coordonnées) : elle ne peut le faire et doit se coltiner une recopie « à la main », chose extrêmement agaçante pour les gens pressés et fainéants que nous sommes tous. Mais le problème principal - et souvent ignoré - est celui de l'accessibilité : lorsque vous utilisez des images à la place du texte, ce dernier devient inaccessible aux personnes mal ou non voyantes (les premières optant en général pour un grossissement des caractères et les secondes utilisant un lecteur braille).

Une alternative a priori plus riche à la transformation des éléments structurants en images est le recours à la technologie Flash. Non seulement cette option conduit aux mêmes impasses (un contenu Flash reste un amas binaire) mais elle vous contraint en outre à utiliser une technologie propriétaire tout de même regrettable dans le monde par nature ouvert du Web.

À défaut de solution satisfaisante et préférant le référencement et l'accessibilité aux effets graphiques, je m'étais résolu à utiliser des polices standards, me contentant d'indiquer dans la feuille de style CSS si la police était à empattement ou pas.

Mais voilà qu'en début de semaine, en recherchant pour un travail graphique une police particulière (et libre), je suis tombé sur un article présentant l'attribut @font-face de CSS 3. Cet attribut permet d'indiquer dans la feuille de style l'url de téléchargement et les caractéristiques de polices TrueType ou OpenType auxquelles la feuille de style CSS peut ensuite faire référence. Lorsqu'un navigateur moderne rencontre cet attribut, il télécharge le fichier TTF ou OTF correspondant et applique la police aux éléments textuels concernés. Du coup, nous avons le beurre et l'argent du beurre : nous pouvons utiliser les polices exotiques sans craindre leur disponibilité sur les postes de consultation ! Il devient soudain possible de donner rapidement un peu plus de caractères à nos pages Web.

Voici à titre d'exemple l'aspect de la page d'accueil de mon site personnel avant que je ne découvre l'attribut @font-face de CSS 3 :

Extrait de mon site perso sans utilisation de l'atttribut @font-face de CSS 3

Et voici son aspect actuel :

Extrait de mon site perso avec utilisation de l'atttribut @font-face de CSS 3

Je ne vais pas vous refaire ici un tutoriel sur l'utilisation de l'attribut @font-face, vous en trouverez une multitude sur le Web. Voici cependant deux remarques importantes :

  • Par défaut et par souci de sécurité, Firefox refuse de télécharger les ressources CSS fournies par d'autres sites Web que celui en cours de consultation. Plusieurs contournements sont possibles mais le plus simple est de déposer une copie de la ressource sur votre propre site Web (j'ai cherché pendant une bonne heure pourquoi « ça ne marchait pas chez moi » avant de découvrir ce détail).
  • N'oubliez pas que les polices de caractères sont des œuvres de l'esprit soumises au droit d'auteur. Les mettre ainsi en ligne et les utiliser sur votre site Web requiert que vous en ayez le droit. Ce n'est pas parce que vous avez acheté une licence d'utilisation d'une police particulière sur votre poste de travail que vous êtes autorisé à l'utiliser sur votre site Web ou à la diffuser. Vous avez donc le choix entre l'acquisition d'une licence d'utilisation spécifique et le recours à des polices libres telles que celles diffusées sous licence SIL Open Font License. Les polices libres commencent à être assez riches bien que de qualité très variable. Le site Webfonts.info en référence un certain nombre et vous en trouverez d'autres sur le site Open Font Library qui connait quelques soucis techniques à l'heure où je rédige ce billet. Comme souvent, le diable Google se jette dans la mêlée en se distinguant : non content de fournir sa propre liste de polices (pour l'instant, créées par d'autres), il propose en outre un outil permettant de les évaluer en ligne.

par sdinot le 2010-09-03 09:33

Thursday 29/07/2010

Humeurs d'un libriste

Accès libre aux photographies orthorectifiées du CRAIG

Ces derniers mois, les mises à disposition de données au profit d'OpenStreetMap se multiplient. En général, ces décisions font suite à l'effort de sensibilisation et d'accompagnement plus ou moins long d'un contributeur qui a pris l'initiative de contacter l'entité détentrice des données pour lui suggérer cette mise à disposition. Mais l'annonce faite hier par le CRAIG (Centre Régional Auvergnat de l'Information Géographique) semble tout à fait spontanée.

Le CRAIG a commandé en 2009 une campagne de prise de vue aérienne couvrant les départements de l'Allier et du Puy de Dôme avec une résolution de 30 cm et les agglomérations de Vichy, Moulins et Montluçon avec une résolution de 15 cm. Une seconde campagne sera réalisée d'ici la fin de l'année pour couvrir les départements du Cantal et de la Haute-Loire avec une résolution de 30 cm ainsi que l'agglomération du Puy-en-Velay avec une résolution de 15 cm.

Le CRAIG a annoncé hier qu'il autorisait les contributeurs d'OpenStreetMap à utiliser ces photographies orthorectifiées :

Cette donnée étant la propriété du CRAIG, et ayant vocation à être largement diffusée/rendue publique (cf. Directive européenne INSPIRE), nous nous proposons de la mettre à disposition des contributeurs d'OpenStreetMap pour enrichir la base de données (autant sous licence ODBL que CC-BY-SA). En espérant que ça montre la voie pour les autres...

Un flux WMS est donc disponible pour l'utilisation dans les outils d'édition OSM (josm, merkaartor, ...). 4 couches sont disponibles:

* départements Allier et Puy de Dôme à 30cm (~16000 km²)

* agglomération de Montluçon à 15cm (~180 km²)

* agglomération de moulins à 15cm (~760 km²)

* agglomération de Vichy à 15cm (~ 330 km²)

Ce service est même allé jusqu'à effectuer lui-même des essais avec JOSM et Merkaartor et à indiquer la configuration recommandée !

De telles nouvelles mettent du baume au cœur surtout quand l'initiative du service est spontanée ! Le bénéfice indirect pour la région ne va pas se faire attendre : d'ici quelques mois, l'Auvergne sera bien mieux couverte dans OpenStreetMap qu'elle ne l'est aujourd'hui. Ce n'est pas un détail car OpenStreetMap est de plus en plus utilisé dans des contextes professionnels et opérationnels.

Pour conclure je dirais que lorsque le CRAIG ajoute que son système d'information repose largement sur le logiciel libre, c'est presqu'un lieu commun de nos jours. Mais contrairement à beaucoup d'autres entités et services, le CRAIG en a compris la philosophie et je suis ravi de le voir anticiper de manière pro-active et positive la transposition dans le droit français de la directive INSPIRE (la France est en retard à ce sujet et déjà à l'amende à hauteur de 10 millions d'euros).

par sdinot le 2010-07-29 07:23

Monday 26/07/2010

Jean-Christophe Arnu

Piggly et PgFincore

Tester ses procédures stockées est souvent fastidieux, notamment lorsqu'il s'agit de couvrir le code. Piggly est là pour pallier à ce besoin.
Lorsqu'on lance des requêtes lourdes ou longues, il peut être intéressant de pouvoir contrôler le contenu du cache, PgFincore

Améliorez la qualité de procédures stockées avec Piggly

Le développement de procédures stockées peut être fastidieux, surtout lorsqu'on cherche à avoir un développement industriel de ces procédures. Avoir une vision de couverture concrète, Kyle Putnam a écrit un script en Ruby, piggly, dont le but est d'instrumenter le code de la procédure stockée et permettant de :
  • recompiler les procédures stockées en instrumentant les boucles, les conditions et les blocs de code
  • compter les itérations dans les boucles
  • évaluer chaque branche des conditions
  • vérifier l'exécution de chaque bloc de code afin de détecter le code mort ou non testé
Piggly est peu consommateur (faible overhead d'exécution) et peut s'installer sous la forme de Gem Ruby.
Les test unitaires doivent être écrits pour l'instant en ruby.

Gestion du préfetch cache pour les requêtes lourdes

PGFincore permet de manipuler des blocs de la mémoire cache du moteur PostgreSQL. Il permet notamment de sauvegarder sur disque et restaurer en mémoire des configurations de cache ainsi que d'annoter certains blocs mémoire comme étant importants (où à ne pas sortir du cache en priorité). Cela permet donc de contrôler la politique de cache avant, par exemple le lancement de requête nécessitant tel ou tel index et dont le temps de traitement est long. En contrôlant finement le cache on peut améliorer de manière drastique les performances des requêtes.

par jca le 2010-07-26 15:49

Friday 23/07/2010

Jean-Christophe Arnu

PGDay Europe 2010 sera à Stuttgart (Allemagne)

Le PGDay est la conférence PostgreSQL majeure en Europe. Cette année elle aura lieu à Stuttgart du 6 au 8 décembre 2010.

Magnus Hagander vient de poster sur la liste PostgreSQL Europe un « Call for Paper » pour la conférence. Si vous utilisez PostgreSQL et que vous souhaitez présenter votre retour sur expérience, ou que vous avez effectué une contribution interfacée avec PostgreSQL, n'hésitez pas à proposer une présentation (en anglais).

Pour plus d'informations : http://2010.pgday.eu

par jca le 2010-07-23 15:09

Tuesday 20/07/2010

Sébastien Domergue

MDA : de l'art de ne point trop modéliser

Voici mon second article consacré à la méthodologie MDA (le premier est consultable ici). Je vais tenter de traiter ici de la problématique d'équilibre entre la modélisation et le retour sur investissement de cette modélisation.

Lorsque l'approche MDA est mise en place, il faut garder à l'esprit qu'il s'agit d'une méthode décrite de manière très générale et sans implémentation de référence. Donc, il faut interpréter les directives fournies par l'OMG afin de trouver un équilibre entre la modélisation (en termes de composants mais aussi de quantité d'informations à inclure dans les modèles), les ressources (personnes qui vont développer la méthodologie et celles qui vont l'utiliser) et les bénéfices d'utilisations du contenu des modèles. Cet équilibre est, je pense, propre à chaque implémentation mais voici quelques questions à se poser pour esquisser les premières bornes de la modélisation.

Quelle est la nature des produits à fournir ?

Bien qu'une approche MDA ait pour vocation d'être la plus générique possible, la mise en place première d'un atelier est conditionnée par la redondance d'un type de produit afin que cet atelier puisse être utilisé sur tous les projets. Il y a l'informatique de gestion qui est plus orientée vers des logiciels faits sur mesure et communiquant éventuellement avec des briques externes d'un SI; l'intégration qui a pour but d'urbaniser un ensemble d'applications et/ou de matériels et la cartographie des processus et outils déjà existants (afin éventuellement de procéder à des mises à jour une fois la cartographie de l'existant maitrisé).
Chacun de ces trois domaines manipulent des objets de niveaux conceptuels différents bien que l'on reste dans le thème de l'informatique voire du SI. Chacun de ces domaines va utiliser plus ou moins les possibilités offertes par UML pour être représenté formellement. Par exemple, un diagramme de classes ne trouvera sans doute pas sa place dans un modèle représentant une cartographie des processus. Il ne sera donc pas utile de traiter ce type de diagramme dans la mise en place initiale de l'atelier.
Cette approche permet de limiter les diagrammes à traiter initialement dans la mise en place de l'atelier. Pour des applications de gestion, nous utilisons les diagrammes de cas d'utilisation, de séquences, d'états-transitions et de classes principalement.

Qu'est-ce qui me sera fourni par la modélisation ?

La modélisation en tant que telle n'est pas intéressante, il faut que l'investissement supplémentaire requis par la modélisation fournisse des résultats en retour. A présent, la totalité des outils proposent la génération de documents de manière native (HTML et parfois RTF ou DOC) ce qui permet d'obtenir des documents en cohérence par rapport au modèle par construction. Ces documents, pour garder cette cohérence ne doivent pas être retouchés après leur génération. Il faut donc inclure dans le modèle l'ensemble des informations nécessaires pour générer les documents voulus. Par exemple, pour un document de reprise de données, il faut disposer au minimum du modèle cible et des informations indiquant les sources utilisées pour peupler ce modèle de données.
Cela suppose également que les informations sont stockées dans un format compréhensible par le destinataire du document. Une règle de gestion peut très bien être modélisée en OCL mais cette formulation ne sera pas comprise (ou pire, ne sera pas acceptée) par des personnes issues du fonctionnel. Il faut donc disposer d'une modélisation compréhensible pour ce consommateur du modèle. Néanmoins cette information peut être stockée pratiquement n'importe où dans le modèle puisque c'est la construction du document qui ira chercher l'information et non une recherche au sein du modèle effectuée par une personne.
L'autre aspect est la génération de code (pour les cas où du code doit être fourni). Il s'agit de code au sens large puisque cela inclut aussi bien des fichiers sources à compiler que des fichiers de configuration si besoin. Dans un premier temps, la génération du code technique est la plus aisée à mettre en place puisqu'il s'agit essentiellement de reproduire un schéma immuable sur plusieurs objets. Une fois l'ensemble des informations techniques renseignées, la génération ne pose aucun problème. Dans un second temps, il est possible de développer les générations de codes plus orientées métier (certains domaines s'y prêtent plus que d'autres, je pense à l'embarqué par exemple).
Toujours dans une optique de cohérence avec le modèle, les fichiers ne devraient pas avoir à être retouchés suite à leur génération. Néanmoins, dans cette partie, il peut être décidé que certaines générations seront des générations de squelettes qui ne seront effectuées qu'une seule fois en début de projet afin de fournir une structure cohérente à l'équipe de développement qui complètera ces squelettes au fur et à mesure.
Attention, les informations techniques ne doivent pas être présentes dès les premiers modèles. Ces informations doivent être intégrées à postériori afin que les premiers modèles soient indépendants de l'implémentation choisie. Cet aspect de séparation des informations métiers et techniques sera traité dans un billet à suivre.

Qu'est-ce qu'il manque comme informations ?

UML intègre déjà un certain nombre d'informations qui peuvent être utilisées dans les cas cités précédemment. Mais grâce à UML2, il est possible d'étendre UML pour ajouter de l'information plus sémantique grâce aux stéréotypes et aux attributs étendus. Ces profils UML peuvent être très génériques et utilisés pour tous les projets indifféremment ou orientés métier et ainsi disposer de profils différents en fonction du domaine fonctionnel à couvrir. Cela est à choisir en fonction de la façon dont l'atelier sera utilisé. En interne à une entreprise la seconde option me parait la meilleure mais elle parait inconcevable dans un centre de service sauf à suivre un certain nombre d'applications ayant exactement le même cœur de métier car cela impliquerai de maintenir l'atelier pour chaque domaine du centre de services.
Attention, ici on parle toujours de besoin en terme de modélisation métier. Les besoins de modélisation techniques seront traités dans un billet à suivre.

Conclusion

Grâce à ces trois questions préliminaires, il est possible de cerner les grandes lignes de ce que va être l'atelier MDA dans sa première version en tout cas. Suite à cela, vient la phase de personnalisation de l'atelier où les besoins en modélisation sont retranscrits sous forme de profils UML et la documentation de modélisation est rédigée à destination des futurs modeleurs.
Dans le prochain billet traitant du MDA, je discuterais de la mise en place des processus de transformations / génération au sein de l'atelier. Ces processus doivent suivre une certaine hiérarchie afin de passer d'une information fonctionnelle pure à une information technique puis à du code.

par Sébastien Domergue le 2010-07-20 08:39

Friday 02/07/2010

Jean-Christophe Arnu

PostgreSQL tous azimuts

L'activité PostgreSQL est en forte augmentation à CS depuis ce début d'année. Depuis le mois de janvier, je fais face à une demande sans cesse croissante de demandes internes (et de clients) concernant PostgreSQL. J'en suis ravi. Cette demande croissante est liée à deux facteurs importants :
  • D'une part, le moteur PostgreSQL (depuis la version 8.0 notamment) s'est bonifié en terme de fonctionnalités professionnelles, ce qui n'a pas manqué d'intéresser les spécialistes de la base de données qui ont petit à petit évaluer le produit au niveau des DSI et de petits projets. PostgreSQL est considéré de nos jours comme un produit de production plus que comme un outil de base de données «intermédiaire» pour petits projets ou maquettes
  • D'autre part, le rachat de MySQL AB par Sun et de Sun par Oracle ont jeté le doute sur MySQL, les tentatives de «forks» libres de MySQL (pour le sauver) n'ont fait que troubler la lisibilité de ce produit, qui commençait à perdre du terrain vis à vis de PostgreSQL
PostgreSQL s'impose maintenant comme un produit fiable et répondant à une assez grande variété de problématiques de base de données courante, remplaçant MySQL, Microsoft SQL-Server ou Oracle sur des projets en cours ou futurs.
Les problématiques rencontrées dans le cadre de mon travail relèvent de l'utilisation de PostgreSQL dans un environnement de production simple (pas de réplication, pas de reprise à chaud) mais requerrant du moteur une gestion performante de forts volumes de données.  L'environnement de production, je pense, se complexifiera avec le temps, tout comme les exigences de services, ouvrant le champ à l'ensemble de l'écosystème de PostgreSQL (poolers, répartiteurs, proxy, ...).

par jca le 2010-07-02 09:20

Wednesday 16/06/2010

Humeurs d'un libriste

Popularité des licences

J'ai découvert dans la dernière lettre d'information de Debian qu'un contributeur avait effectué un état des lieux des licences utilisées dans les paquets Debian officiels libres (29470). En synthétisant un peu plus ses résultats, j'arrive au décompte suivant :

Fichiers de licences applicables au logiciel (33313 fichiers de licence au total) :

Licences applicables au logiciel
LicencePartCumul
GNU GPL19893 (59,72 %)19893 (59,72 %)
GNU LGPL7183 (21,56 %)27076 (81,28 %)
Artistic2315 ( 6,95 %)29391 (88,23 %)
BSD1556 ( 4,70 %)30947 (92,90 %)
Apache1119 ( 3,36 %)32066 (96,26 %)
MPL654 ( 1,96 %)32720 (98,22 %)
LaTeX PPL297 ( 0,89 %)33017 (99,11 %)
CDDL190 ( 0,57 %)33207 (99,68 %)
SIL OFL67 ( 0,20 %)33274 (99,88 %)
CeCILL-C20 ( 0,06 %)33294 (99,94 %)
CeCILL12 ( 0,04 %)33306 (99,98 %)
CeCILL-B7 ( 0,02 %)33313 (100,00 %)

Fichiers de licences applicables à la documentation (1006 fichiers de licence au total) :

Licences applicables à la documentation
LicencePartCumul
GNU GFDL875 (86,98 %)875 (86,98 %)
CC-BY-SA79 (7,85 %)954 (94,83 %)
CC-BY52 (5,17 %)1006 (100,00 %)

Les esprits chagrins noteront que 33313 est supérieur à 29470 et, à fortiori, (33313 + 1006) aussi. Cela s'explique par le fait qu'un paquet peut contenir des composants diffusés sous des licences différentes, voire qu'un seul binaire peut résulter de la composition de codes sources diffusés sous des licences différentes mais compatibles.

En ce qui me concerne, c'est une nouvelle confirmation que, contrairement au tableau sombre que dessinent les opposants au logiciel libre et ceux qui n'ont pas vraiment étudié la question, la situation n'est pas si inextricable que cela. La GNU GPL est la licence retenue par plus de 60 % des projets et les 6 principales licences couvrent à elles seules plus de 98 % des logiciels libres diffusés par Debian.

par sdinot le 2010-06-16 13:04

Friday 11/06/2010

Jean-Christophe Arnu

Ouverture de l'agrégation des blogs CS vers l'extérieur

C'est aujourd'hui que les billets publics des blogs CS sont publiés via l'agrégateur public de CS. L'ensemble des billets utilisant le tag « public » seront maintenant consultables depuis internet. Cet espace est maintenant public. Vous pourrez consulter les commentaires des internautes sur l'agrégateur. Cet espace d'expression est le votre, profitez-en, exprimez vous!

par jca le 2010-06-11 12:54

Monday 07/06/2010

Humeurs d'un libriste

OpenStreetMap, import du Pays de Romans

C'est fait, les données cadastrales détenues par le Pays de Romans ont été injectées dans OpenStreetMap et le rendu est déjà consultable en ligne.

Même sans être un champion au jeu des sept différences, vous noterez une différence notable entre le Nord et le Sud de l'Isère. Au Nord, c'est Romans-sur-Isère, au Sud, Bourg-de-Péage. Au Nord, nous sommes dans la communauté de communes qui a décidé de fournir sous licence CC-By-SA ses données cadastrales au projet OpenStreetMap, au Sud, non. No comment...

Ce n'est pas encore une pratique courante mais les exemples de collectivités territoriales et d'institutions collaborant avec OpenStreetMap se multiplient. Nul doute que l'exemple donné l'année dernière par Brest Métropole Océane a été le déclencheur de ce mouvement. Les communautés de communes de Plouarzel et de la presqu'île de Crozon lui ont emboîté le pas. C'est maintenant le Pays de Romans qui suit et d'autres discussions sont en cours. Du côté des institutions, la DGFiP a donné l'année dernière son accord pour l'utilisation de ses données cadastrales sous forme d'un calque d'appui (et non pour leur injection automatique) dans les applications de création de données d'OpenStreetMap. Ensuite, l'administration en charge de la base Corine Land Cover a autorisé l'import de sa base. Plus récemment, l'INPN a fait de même avec la base des parcs nationaux.

Espérons que ce mouvement s'accélèrera, le seul risque étant que les contributeurs d'OpenStreetMap aient un jour du mal à suivre... :)

par sdinot le 2010-06-07 09:05

Thursday 27/05/2010

Sébastien Domergue

Gource : un outil de suivi SCM

Ce billet a pour objectif de présenter l'outil Gource. Cet outil permet de visualiser l'évolution d'un projet au travers du suivi de sa gestion de sources (SVN, Git, Mercurial, CVS et Bazaar sont supportés, voir si après). Au jour le jour cette visualisation n'apporte pas un indicateur valable de l'avancement du projet mais sur la vie d'un projet cela permet de visualiser les grandes étapes du projet et la manière dont l'arborescence a évolué. Pour les projets open-source l'intérêt peut être de visualiser comment la communauté a travaillé sur le projet et fournit un support visuel sur l'implication qu'il y a eu autour du projet.

Gource en bref

Gource est un outil de visualisation de système de contrôle de versions. Il a été développé pour les systèmes décentralisés Git, Mercurial et Bazaar. Le support de CVS et SVN est un support tiers qui est assuré par l'emploi de scripts ou de passerelles entre SVN et Git par exemple. Il permet de visualiser sous forme d'arborescence l'évolution du repository. Le rendu est assuré par OpenGL et requiert que l'accélération matérielle soit activée.

Installation de Gource

Il y a deux versions de Gource disponibles, l'une pour systèmes Linux et l'autre pour Windows. Pour la version Windows, il suffit de dézipper et d'ajouter au Path le dossier de destination. Pour Linux je n'ai pas essayé mais j'imagine que cela doit être pareil. Ensuite tout se fait grâce à la commande gource.

Utilisation de Gource

SVN

Je commence par le cas SVN car c'est le cas le plus représentatif chez nous. Les logs SVN ne sont pas fournis directement dans un format compréhensible par Gource, Il y a deux méthodes pour parvenir à obtenir la visualisation : importer le dépôt SVN dans un depôt Git ou transformer le log en log compréhensible.

Cas du dépôt Git

Ce cas est le plus long à mettre en place mais le plus sûr pour l'utilisation de Gource. Il faut commencer par installer Git puis importer le dépôt grâce à git svn. L'ensemble du dépôt est cloné sur la machine et est donc accessible. J'ai voulu essayé et j'ai eu un problème lors de l'import. Je pense que cette solution est à utilisée si un développeur a déjà copié le dépôt pour travailler. Sinon ça n'en vaut pas vraiment la peine. Ensuite, Gource s'utilise de la même manière qu'avec Git.

Cas du log modifié

Ce cas est le plus rapide mais peut encore comporter des erreurs. Un script python est disponible sur le site de Gource qui va se charger de modifier le log. Les commandes sont les suivantes :

svn log --verbose --xml PATH_TO_REPOS > my-project.log
python svn-gource.py --filter-dirs my-project.log > my-project-gource.log

PATH_TO_REPOS peut très bien être une url et amener vers la racine du dépôt ou bien vers un sous répertoire (pour ne suivre qu'un module par exemple). Ensuite Gource se lance grâc e à la commande suivante :

gource --log-format custom my-project-gource.log

Git

Pour Git, il suffit de se placer dans le repository à visualiser et de saisir la commande :

gource

Rien de plus facile.

Les options de Gource

Alors là le choix est vaste. Je ne vais pas reprendre la syntaxe des options, pour cela il suffit de taper

gource --help

je vais plutôt parler des options qui me paraissent les plus utiles.

  • Tout d'abord, désactiver l'effet Bloom qui, à mon sens, floute trop le schéma s'il y a beaucoup de fichiers.
  • Il est possible de suivre un utilisateur. Cet utilisateur est affiché avec un nom en jaune assez visible. Pendant la vidéo, un appui sur la touche 'V' va basculer la caméra en mode suivi de l'utilisateur au lieu d'afficher le suivi de l'arborescence. Pratique pour le suivi d'une personne dans une arborescence étendue.
  • Il est possible de masquer les noms de fichiers. Dès qu'il y en a plus de 10 à un endroit, c'est vite impossible à lire et ça masque le reste également. Je l'ai désactivé systématiquement. Il est possible de masquer le nom de répertoires, là je suis moins enclin à le faire.
  • Des avatars peuvent remplacer les utilisateurs avec un peu de configuration.
  • Gource peut exporter les images qu'il génère en ppm (attention, très volumineux). Ce ppm peut ensuite être converti en vidéo grâce à ffmpeg par exemple. Les commandes pour cette manipulation sont sur le wiki de Gource.

Conclusion

Cette présentation sommaire de Gource se termine. J'espère qu'elle aura été suffisamment claire et concise. Si vous avez des questions ou voulez un exemple, contactez moi directement.

par Sébastien Domergue le 2010-05-27 13:21

Tuesday 25/05/2010

Humeurs d'un libriste

Pascal Brisset est mort

Ce nom ne vous dit certainement rien mais Pascal Brisset était un type bien. Enseignant-chercheur à l'ENAC, créateur du mini-drône libre Paparazzi, il alliait le talent à la modestie comme pourront en témoigner tous ceux qui ont déjà assisté à l'une de ses conférences. À l'occasion de la dernière édition du salon Solutions Linux, je l'avais invité à présenter Paparazzi dans le cadre de la session de conférences dédiée à l'informatique industrielle.

Pas plus tard que lundi dernier, nous croisant par hasard à Altissimo, nous nous étions découvert une passion commune pour l'escalade. Je ne savais pas qu'il était aussi alpiniste et que cette passion allait lui coûter la vie le samedi suivant. Mardi encore, je l'ai croisé à l'OSSIF et nous avons discuté de l'avenir de Paparazzi autour d'un café (j'avais parlé à Pascal des projets que je nourrissais autour de Paparazzi et d'OpenStreetMap).

C'est certainement peu de choses mais pour que tout le monde puisse se souvenir de lui, une page à la mémoire de Pascal Brisset a été ouverte sur le site Paparazzi.

Adieu Pascal, j'ai réellement été heureux de te rencontrer ! :(

par sdinot le 2010-05-25 07:18

Tuesday 18/05/2010

Sébastien Domergue

Déployer une application

Tout le monde a été confronté au déploiement d'applications et aux scripts maison qui accompagnent cette phase. Généralement, dès l'itération suivante d'un déploiement, ou sur un déploiement en cluster hétérogène, ces scripts et procédures sont modifiées. Cela est valable pour toute technologie, pas uniquement pour les applications Java/J2EE que je connais mieux, je l'avoue.
Après quelques recherches j'ai trouvé un premier produit : DeployIt. Cette application permet de déployer des applications Java en pilotant les serveurs d'application pour déployer des WAR/EAR, copier des fichiers, écrire certaines configuration et même exécuter du SQL si besoin. Néanmoins, cette application ne répond pas au problème majeur de sécurité que nous rencontrons la plupart du temps : les serveurs sont dans des réseaux déconnectés des nôtres. J'ai pu discuter avec les concepteurs de cet outil et ils ne sont pas dans la même logique du tout; pour eux avoir une application sur un serveur non exposé au moins à l'environnement de développement paraissait inconcevable mais là n'est pas la question.

Question : de quoi avons-nous besoin ?

La question de l'utilité d'un tel outil dépend des besoins génériques que l'on peut formuler. Voici, un peu en vrac, les besoins identifiés :

  • traçabilité : quelle version a été déployée, sur quelle cible, quand, par qui...
  • multi-plateforme : si mon développement peut être utilisé à l'identique sur plusieurs plates-formes, son déploiement lui ne doit pas l'être et donc il s'agit d'autant de scripts à gérer.
  • installation à distance : si un réseau permet d'accéder à mes serveurs cibles, autant utiliser ce réseau.
  • installation déportée : si aucun réseau ne permet d'accéder à mes serveurs cibles, il faudrait que j'ai un bundle d'installation complet que je n'aurais qu'à exécuter sur site.
  • multi-technologique : un batch Java ou un exécutable peuvent très bien être déployés en faisant une copie dans le serveur cible, ce point peut éventuellement être sujet à caution en fonction des besoins.
  • gestion de la configuration : il existe toujours un certain nombre de fichiers de configuration, qu'ils soient spécifiques à l'application ou plus généraux, avoir un moyen de gérer la configuration ici permet de la modifier en fonction de la cible (production ou pré-production) simplement. Éventuellement cela permet également de se prémunir d'erreurs de configurations qui se télescopent dans le cas d'applications mutualisées.
  • validation de l'installation : tous les fichiers qui doivent exister existent-ils? Les processus ont-ils démarrés? Mon application répond-elle (ce qui est différent de la question précédente)?
  • déploiement en cluster : quelle stratégie adoptée pour un cluster : déploiement itératif noeud par noeud ou déploiement brutal avec interruption de service ?


Ce genre d'outil existe-t-il?

Pour le moment je n'ai pas trouvé grand chose à ce sujet, IBM commence à en avoir un mais il n'est pas encore très aboutit, Oracle n'a encore rien annoncé... Le domaine est ouvert.

L'intérêt de ce genre d'outil

L'intérêt est avant tout de gérer plus simplement la phase de déploiement qui n'est pas une phase réellement prise en compte dans la vie d'un projet. Ensuite un intérêt en terme de coût puisque les scripts ne sont plus à écrire ni à maintenir et les compétences ne sont pas perdues si une personne part du projet.

La discussion est ouverte

Ce billet laisse volontairement beaucoup de portes ouvertes sur le sujet afin de pouvoir échanger avec ceux qui ont des idées, qui ont déjà rencontré ce genre de problèmes ou qui voient d'autres besoins ou même des contre indications à ce genre de démarche. Merci de vos retours.

par Sébastien Domergue le 2010-05-18 15:05

Wednesday 12/05/2010

Sébastien Domergue

Résumé du Paris JUG Share, Build, Deploy

Cet article est un résumé des sujets abordés lors du Paris JUG du 11 mai qui a eu lieu dans les locaux de l'ISEP. Ce JUG abordait une partie des problématiques du cycle de développement en ce qui concerne l'outillage de share, build et deploy. Une première présentation était une présentation des outils de gestion de sources décentralisée puis une présentation de GIT à proprement parlé à eu lieu. Une présentation du nouveau Maven 3 pour la partie build et enfin la présentation du produit DeployIt de la société Xebia pour la partie deploy.

Avant toute chose, ce JUG a été différent des autres car il s'agissait de 4 sessions de 30min au lieu de 2 d'une heure. Cela implique que les sujets ont été traités de manière très superficielle. Comme pour le précédent billet JUG, je vais relater les propos des sessions puis je donnerais mon avis personnel.

Petit rappel

Avant de présenter les deux premières conférences, je voulais rappeler rapidement ce qu'est une gestion de source décentralisée. Ce type de gestion de sources permet d'avoir un repository local qui peut communiquer avec d'autres repositories. Cela implique qu'il n'est plus obligatoire de disposer d'un serveur central de gestion de sources (nous verrons plus loin les possibilités) et de travailler en mode déconnecté puisque chaque repository contient l'ensemble des modifications. Le plus connu est sans doute Git qui est utilisé pour le développement du noyau Linux.

La gestion de sources décentralisée

Cette première session était présentée par Sébastien Douche qui est consultant en méthodologies d'entreprise (Agile, Architecte technique...). Sa présentation s'articule autour de son expérience au sein de son entreprise actuelle qui est passée au DVCS (Distributed Versionning Control System). L'entreprise partait sur un projet feuille blanche, sans aucun existant préalable ce qui implique nécessairement beaucoup de tests, de POC, de retours en arrière... du moins pendant les premières phases du projet. Le projet a été débuté avec SVN mais il est arrivé un moment où, à la fin du run, le projet ne pouvait être présenté.
Le diagnostique à cette situation a été que SVN n'était pas utilisé en tant qu'outil de gestion de sources mais comme une solution d'archivage où les développeurs faisaient beaucoup de micro-commits tout au long de la journée et donc beaucoup de micro-merges également (merge permanent). La raison invoquée pour ces micro-commits était que plus le commit était gros, plus il était difficile à merger.
La question suivante a été "pourquoi ne pas utiliser les branches SVN?" et la réponse fut "parce que c'est trop difficile à réintégrer au trunk".
L'objectif a donc été de trouver un moyen de toujours disposer d'une version stable prête à livrer régulièrement de la valeur ce qui signifiait supprimer le passage du développement à la livraison et toujours connaitre l'état du projet. Le moyen clé était de séparer le travail (isolation) d'où l'étude des DVCS (Git et Mercurial sont les plus connus).
Un DVCS a une autre approche de la gestion des sources, ils sont orientés contenus et non changements ce qui permet le refactoring massif sans passer par un commit qui doit tout supprimer et tout reconstruire. Cela est possible grâce à l'emploi d'empreintes sur le contenu des fichiers plutôt que de suivre l'ensemble des modifications d'un fichier avec un certain nom.
De plus, les DVCS permettent de déconnecter 3 types de workflows :

  • Le workflow organisationnel qui représente la méthode de travail de haut niveau, imposée par l'organisation.
  • Le workflow personnel qui représente la manière dont le développeur travaille.
  • Le workflow inter-personnels qui représente la manière dont deux développeurs collaborent au développement de la même fonctionnalité.

D'après le présentateur, l'apport de l'utilisation d'un DVCS est que les développeurs sont plus focalisés sur leur propre code ce qui induit plus de souplesse et d'adaptation (indépendance vis à vis de l'organisation). Les développeurs font des push par blocs fonctionnels et la revue de code devient systématique (doublée avec une démo avant le push).

Git

Cette session était présentée par David Gageot de la société Algodeal.
Comme précisé au début de ce billet, Git n'a pas besoin d'un serveur central, chaque utilisateur a une copie complète du repository en local. La présentation ne s'axait pas sur l'utilisation basique de Git (commit, update, branches, tag...) mais sur des fonctionnalités complémentaires de Git.

Git bisect

Quand un projet ne fonctionne plus, il peut être difficile de retrouver le commit coupable. De plus, cela peut venir d'un ajout de tests qui détectent une erreur jusque là bien cachée et il faut rechercher le premier commit responsable. Avec SVN, on procèderait pas dichotomie en remontant suffisamment loin dans le temps pour trouver un commit qui fonctionne puis refaire des tests jusqu'à avoir trouver le bon. Git bisect permet d'automatiser cette recherche en lui fournissant les bornes de la recherche ainsi qu'une commande ou un script qui servira de table de vérité. Dans le cas du test, il est possible de dire que la classe de test est incluse dans le build même dans le passé. Puisque tout le repository est disponible en local, la recherche est plus rapide.

L'abandon de l'intégration continue

D'après le présentateur, il est possible de se passer d'un serveur central d'intégration continue. Au sein de son entreprise, ils ont écrit un script qui permet de lancer un build en local et seulement si le build passe les modifications sont pushés vers l'extérieur. Des mécanismes propres à Git permettent de pouvoir continuer à travailler pendant le build sans perturber ce dernier.

Qui détient la vérité ?

La question qui se pose avec un système décentralisé et de savoir qui détient la vérité pour faire une livraison. Il existe plusieurs méthodes :

Le serveur central

Les modifications y sont déposées par tous les développeurs et lorsqu'une livraison est à faire, ce sont ces sources qui sont utilisées. On retrouve une partie de l'aspect SVN.

L'autorité de confiance

Une personne dispose du repository de confiance. Il intègre les sources de ses lieutenants qui eux-mêmes intègrent les sources d'un cercle de confiance plus large et ainsi de suite en fonction de la taille du projet. Personne ne peut modifier le repository de l'autorité de confiance mais tout le monde peut le lire. C'est le système utilisé pour le noyau Linux ou Linus Torvalds est l'autorité de confiance avec une dizaine de lieutenants officiels.

Passer de SVN à Git

Des ponts existent au sein de Git pour récupérer un dépôt SVN et le traduire en Git puis de refaire des commits SVN plus traditionnels. Cela peut être utilisé par les développeurs par exemple qui vont utiliser SVN pour le trunck principal (workflow organisationnel) mais qui vont utiliser Git en local pour créer des branches, les manipuler, cloisonner les développements... (workflow personnel).

Maven 3

Changement de sujet, après le Share, voici le Build de la soirée avec la présentation du futur Maven 3.0.

Un bref historique

Maven 1.x relevait plus du POC qu'autre chose. Il était très difficile à prendre en main, pas stable et donc il n'a pas été adopté. Maven 2.x apprendra des erreurs de Maven 1 sans être rétro compatible (vu la faible adoption ce n'était pas trop grave). Maven 2 a été énormément adopté par les développeurs mais très peu par la communauté qui était en manque de documentation au sein d'un code lourd et très fermé.

Maven 3 arrive

Maven 3 sera rétro-compatible Maven 2. L'adoption de la version 2 ne permet simplement pas de le laisser tomber d'un coup. En revanche, le noyau de maven a été entièrement réécrit pour permettre d'avoir une vraie modularité avec des API simplifiées et documentées.
Le développement de Maven 3 est aussi fortement orienté tests avec plus de 500 tests d'intégration et l'ensemble des projets du dépôt officiel pour supports de tests. La distribution source est même plus lourde que la distribution binaire du fait du code des tests. Aujourd'hui, passer de Maven 2 au 3 implique juste de changer le Path pour pointer vers un dossier Maven 3. Il reste un ou deux plug-ins récalcitrants mais une documentation précise permet de ne pas en souffrir.

Les nouveautés sous le capot

Sous le capot, Maven abandonne Plexus pour l'injection de dépendance au profit de Google Juice (JSR330) mais pas dans la version 3.0 directement.
Maven est écrit en Java 5 avec l'utilisation de Generics et d'annotations.
Contrairement à ce qui avait été annoncé, Mercury ne sera pas inclus dans Maven pour la gestion des artefacts. Le développement a pratiquement été mis à la poubelle.
Le build plan : peut être le plus intéressant pour le développement de plug-in. Dès le départ du build, maven est à présent capable de fournir l'ensemble des opérations qu'il va effectuer. Ainsi, le plug-in peut se trouver être plus intelligent pour éviter de doubler certaines phases comme passer deux fois les tests unitaires pour deux plug-ins différents. Eclipse utilise déjà Maven 3 dans le plug-in m2eclipse avec le moteur embarqué (donc c'est que la rétro compatibilité marche, on s'en n'était pas aperçu). Cela permet de laisser Eclipse faire les builds incrémentaux (ce qu'il sait bien faire) et maven ne s'occupe que de la confection du jar.
Maven rencontre OSGi grâce à Tycho (repositories p2). Donc Maven devient polyglotte pour l'écriture des pom.
Les principaux plug-ins maven seront mis à jour pour utiliser ces fonctionnalités dans les semaines/mois à venir.

Les nouveautés pour les développeurs

Ben pas grand chose pour le moment! C'est bien ça le problème... Dans la version 3.0 rien n'est vraiment prévu (meilleurs perfs, logs plus lisibles) mais pour les versions suivantes on disposera :

  • de la possibilité de retirer les numéros des versions dans l'héritage des descripteurs.
  • de la capacité d'inclure des morceaux de configuration dans les pom (mixins) pour éviter d'avoir des blocs copiés/collés à l'identique dans tous les projets.
  • de la capacité d'effectuer des excludes qui suivent l'héritage.
  • de builds parallèles à condition d'avoir un graph de build qui s'y prête. Un même projet, sur la même machine a été compilé en 11min sous Maven 2, 10min sous Maven 3 et 6min sous Maven 3 avec builds parallèles.
  • de nouveaux outils : une console!!! (si si) qui permettra d'invoquer plusieurs actions sans relancer la JVM à chaque fois (la console est annoncée comme prête), le plug-in m2eclipse qui devrait s'enrichir.


Et ça ne va rien couter!!!
Enfin, la communauté est revenue à Maven et participe activement au développement (le système de build parallèle a été initialisé par une personne qui a ensuite proposé de l'intégrer au trunck).

DeployIt

Je n'ai malheurseument pas pu assister à la présentation de DeployIt mais je vous invite à lire/relire l'article précédent où DeployIt est présenté. J'ai également un livre blanc version papier de la société Xebia sur ces problématiques si des gens veulent en savoir plus. De toute manière, en 30 minutes, je pense que je n'en aurais pas vu beaucoup plus.

Conclusion

Ce JUG, de part son format, m'a laissé un peu sur ma faim. J'ai eu l'impression d'assister à une session de vente de produits sans réellement en voir les apports ou bien en jetant de la poudre aux yeux. Par exemple, Git n'est pas le remède miracle aux micro-commits. Il gère peut être mieux les conflits que son grand frère mais c'est tout. Sur mon projet actuel, on a tous commité par bloc fonctionnels et on a eu très peu de merge à faire au fur et à mesure. En revanche, l'apport de Git est de disposer de l'ensemble du repository en déconnecté (très pratique en déplacement) et de pouvoir réellement utiliser des branches avec des mécanismes de réintégration multiples (et pas seulement un gros merge). Enfin, la mécanique pour se passer de l'intégration continue existe déjà avec le serveur de TeamCity qui permet de faire un build depuis Eclipse sans toucher au dépôt de sources. De plus, lorsque deux développeurs travaillent sur le même module et que chacun a des tests qui passent, comment s'assurer que l'intégration des deux fonctionne également?
Pour Maven 3, je pense qu'il y a 2 infos majeures : la communauté est revenue sur le développement, ce qui fait que les choix techniques ne seront plus tous contrôlés par une seule entreprise/personne et que les builds parallèles seront possibles. Pour cette dernière, l'intérêt sur nos postes de développement risque d'être limité vu que l'on dispose à peine de 2 cœurs (éventuellement hyperthreadés) mais sur des serveurs d'intégration continue cela pourrait faire gagner beaucoup de temps.
Enfin, je tiens à relayer le message des organisateurs du JUG en ce qui concerne l'ISEP. En effet, l'ISEP accueille gracieusement le JUG une fois par mois dans un amphi où 200 personnes viennent. Au cœurde Paris, une telle salle couterait trop cher pour que le mouvement continue. Pour les remercier, une personne du JUG a déjà fait 4 cours à des élèves des l'ISEP et un appel a été lancé aux bonnes âmes qui disposeraient d'un peu de temps et de l'envie de faire partager leur expérience ou leur savoir sur Java (au sens très large, pas seulement purement technique). Ayant déjà fait des présentations MDA à d'autres élèves, ce genre d'échange est également bénéfique à CS car pour une demie journée passée auprès d'eux, CS se fait connaitre et peut trouver des stagiaires/futures recrues.
Le prochain JUG sera animé par Holly Cummins et traitera du tuning d'applications et de l'architecture OSGi. Je ne sais pas si je pourrais y aller mais si d'autres personnes sont disponibles n'hésitez pas à y faire un tour.

par Sébastien Domergue le 2010-05-12 13:10

Tuesday 11/05/2010

Humeurs d'un libriste

Annulation de trois brevets d'IP Innovation

Dans un article récent, je commentais l'annulation d'un brevet détenu par Exalead à l'issue d'un procès intenté par elle contre Sinequa.

Une mésaventure similaire vient d'arriver à la société IP Innovation qui avait intenté un procès contre Red-Hat et Novell pour violation de trois de ses brevets. Non content de débouter IP Innovation, le juge a déclaré ses trois brevets nuls pour défaut d'activité inventive (l'un des trois critères que doit satisfaire une invention pour être brevetable). La décision est d'autant plus savoureuse qu'IP Innovation est l'un de ces parasites de l'économie, dits « patent troll », qui ne produisent strictement rien mais rachètent des brevets inexploités par leurs auteurs originels afin de rançonner les industriels qui, selon eux, violent lesdits brevets. La menace est bien huilée : soit l'industriel paie une licence (dont le montant souvent excessif touche à l'extorsion de fonds) pour utiliser le procédé couvert par ce brevet, soit le parasite lui intente un procès dans le but de récupérer de monumentaux dommages et intérêts.

Pour mémoire, les algorithmes sont exclus du champ de la brevetabilité en Europe mais ce n'est pas le cas aux États-Unis et au Japon où des milliers de demandes sont déposées chaque année et acceptées sans examen approfondi ni recherche d'antériorité. Or, les opposants au brevet sur les algorithmes ne cessent de dénoncer le défaut d'activité inventive, pour le pas dire le caractère trivial, des brevets accordés dans ces pays, qui nuisent de facto à l'innovation qu'ils sont censés encourager.

par sdinot le 2010-05-11 12:32

Thursday 06/05/2010

Jean-Christophe Arnu

La première béta de PostgreSQL 9.0 vient de sortir

La première version béta de PostgreSQL 9.0 vient de sortir! Il s'agit de la première version à proposer la réplication de base de données binaire et temps réel. Cette réplication s'appuie sur deux mécanismes : la réplication par flux (ou Streaming Replication) et la gestion d'instance à chaut (Hot Standby).
On compte également en plus de cette fonctionnalité importante les nouveautés suivantes :
  • Support du 64 bits dans windows
  • L'amélioration du bus de messagerie interne (LISTEN/NOTIFY)
  • Les procédures anonymes utilisant la claude DO
  • Le triggers conditionnels et par colonne
  • Les contraintes d'unicité pour les  données non scalaires (contraintes d'exclusion mutuelle)
  • L'amélioration des données de type clé/valeur
  • La suppression automatique de jointures, optimisant les requêtes générées par les ORM
L'annonce complète est disponible ici

par jca le 2010-05-06 15:41

Blog de l'Equipe outil

Changement d'agrégateur pour nos blogs

Nous venons de changer de plugin d'agrégation pour nos blogs afin de parfaire la publication vers l'extérieur de nos billets publics. Le nouvel agrégateur est maintenant ZoneClearFeed qui permet une bien meilleure configuration du comportement d'agrégation des billets (évitant ainsi de rediriger un billet vers son url originale par exemple).

par jca le 2010-05-06 13:03

Sébastien Domergue

Les bases de données NoSQL

Le mouvement NoSQL commence à être très visible et actif grâce à son adoption par certaines entreprises sur le net. Il existe 4 types de bases de données dans ce mouvement et chacune a des domaines de prédilection. Cet article va tenter de faire un tour d'horizon des différents types de base de données NoSQL avec leurs avantages, inconvénients et buts pendant que la conférence NoSQL Europe bat son plein.

La grande différence entre une base de données relationnelle et une base de données non relationnelle est l'absence de schéma. Ce n'est pas la base de données qui gère la forme des informations, c'est le logiciel qui s'en charge.

La base de données clé-valeur

Pour faire simple, il s'agit d'une grosse table de hashage persistée. On accède à un élément stocké par son identifiant uniquement. Ce genre de stockage peut s'avérer très utile pour stocker des informations rarement modifiées mais beaucoup accédées. Le premier exemple d'utilisation de cette technologie est Amazon. Puisqu'une donnée est uniquement liée à une clé, il est possible de facilement obtenir des systèmes distribués avec des annuaires d'index. Si le système est distribué et répliqué, il est également prévu un relâchement de la consistance des données. C'est à dire qu'à partir d'un certain nombre de nœuds qui ont répondus la même valeur pour une clé, on considère que la valeur retournée est la bonne valeur. Cela peut donc induire un certain temps de latence lors de la mise à jour d'une information si la réplication des valeurs au travers des réplicats est différée (par exemple pour utiliser les périodes où la charge est moindre).
Un exemple de base de données clé-valeur : Riak

La base de données orientée document

Ici, on conserve le système clé-valeur précédent mais la donnée stockée n'est pas une donnée sérialisée mais une donnée structurée à la manière d'un XML ou JSON. La base de données n'a toujours pas de contrainte de schéma mais elle est consciente de la structure de la donnée ce qui permet d'embarquer des opérations supplémentaires par rapport à précédemment : indexation des valeurs par champs, modification d'un champ et non de l'objet complet et requêtes sur les champs. Les relations one-to-one et one-ot-many sont réalisables sans jointure puisque le document stocké peut inclure les documents comme sous sections par exemple. Je trouve que cela pose un problème lors de la modification de la cible de l'association justement et également un soucis d'espace de stockage mais pour la lecture il est indéniable qu'on y gagne.
Un exemple de base de données document : MongoDB

La base de données orientée colonne

Il s'agit peut être du type le plus représentatif du mouvement NoSQL car le plus visible dans l'actualité. Mais il faut également faire une sacrée gymnastique pour comprendre comment il stocke une information (avis personnel car j'ai mis 3h à comprendre). Pour faire au plus simple, là où une table d'une base relationnelle contient 5 colonnes qui peuvent parfois contenir "null" et donc où chaque ligne couvre les 5 colonnes de la table, une base de données orientée colonne va stocker dans une ligne les colonne utilisées et les valeurs pour ces colonnes. Les cases vides sont évacuées du stockage pour gagner en espace. Un niveau supérieur permet d'agréger ces ensembles dans un ensemble qui se comporte comme une ligne. Une ligne qui contient d'autres lignes en fait. J'utilise des termes volontairement incorrects par rapport au vocabulaire NoSQL car c'est à mon sens la manière dont on se représente le mieux ce stockage.
L'exemple le connu est Cassandra

La base de données orientée graph

Le principe de ses bases est de stocker les relations entre les objets. On distingue 2 types d'entités dans ces bases : les objets qui contiennent les informations propres à un élément et les liaisons qui contiennent les informations de relation entre deux objets. Pour ces deux types, il est possible d'ajouter des attributs nommés pour stocker de l'information. Ces bases sont, par exemple, utilisées dans les modélisations de réseau sociaux mais une utilisation pour des données de cartographie d'équipements serait tout aussi pertinente. Le problème qui se pose aujourd'hui est la gestion de bases réparties sur plusieurs nœuds afin d'optimiser le nombre de ponts à franchir pour parcourir un graph. Les fonctionnalités de ces bases sont bien sur la possibilité d'appliquer les algorithmes de théorie des graphs directement (plus court chemin, nombre de relations, centralité, diamètre du réseau...).
L'exemple le plus actif est neo4j

Conclusion

Ces bases n'ont pas pour but de remplacer les bases de données relationnelles mais de les compléter. Leurs performances sont souvent bien meilleurs en lecture (et en écriture pour Cassandra) mais leurs possibilités de requêtes sont plus limitées. L'utilisation de ces bases pourrait être d'avoir un système de persistance hétérogène (une base relationnelle et une orientée graph par exemple) afin de répondre à des problématique différentes (la base relationnelle pour la gestion des données qui alimente la base orientée graph pour fournir des représentations cartographiques de parcs et bénéficier des calculs mathématiques associés comme la conséquence de la défaillance d'un switch sur l'ensemble du réseau).

par Sébastien Domergue le 2010-05-06 11:13

Humeurs d'un libriste

Pas de support MS-Windows pour l'Atom Z6xx !

Serait-ce le début de la fin pour Microsoft ? Je ne pense pas que nous en soyons encore là mais, signe des temps, Intel vient de lancer une nouvelle gamme de processeurs Atom (famille Z6xx) pour laquelle le fondeur a prévu le support de trois systèmes à base de noyau Linux pour l'embarqué (Android, Moblin et MeeGo) mais pas de MS-Windows CE ou autre déclinaison du système de Microsoft.

Je ne me fais pas de souci pour Microsoft, cette société ne tardera pas à réagir et à trouver avec Intel les arrangements techniques et commerciaux qui lui permettront de revenir dans la course.

En marge de cette information, force est de constater qu'après s'être imposée comme intermédiaire incontournable de l'accès à la donnée au point qu'Internet ne puisse plus vraiment être imaginé sans elle, Google (qui édite Android) étend désormais son emprise dans le monde du logiciel afin de toujours mieux contrôler qui accède à quoi et comment. Nul doute que le livre de chevet des patrons de Google est Power Shift (en français, Les Nouveaux Pouvoirs), le livre dans lequel Alvin Toffler annonçait en 1990 un glissement des pouvoirs en direction de la maîtrise de l'information et anticipait, quatre ans avant que Tim Berners-Lee n'imagine le Web, l'émergence d'agents intelligents collectant pour nous une information personnalisée au sein d'un « super réseau ».

par sdinot le 2010-05-06 07:34

Tuesday 04/05/2010

Jean-Christophe Arnu

Résultat des élections PostgreSQLFr

Voici le résultat de l'élection du bureau de l'association PostgreSQLFr et du vote de l'association concernant le PAP de Damien.

Le bureau est composé de : Président : Jean-Christpohe Arnu Secrétaire : Patrick Francelle Trésorier : Stéphane Schildknecht Vice-Président : Cédric Villemain.

L'appel à proposition de projet de Damien Clochard, visant à sponsoriser des développements autour de PostgreSQL par l'association est accepté par l'association.

Pour rappel les objectifs de ce nouveau bureau sont :

Objectifs et Missions pour 2010

Fonctionnement de l'association

Nous proposons de simplifier les statuts, et pour cela de :

  • Définir des règles au niveau de la composition du bureau
  • Redéfinir les rôles du bureau
  • Redéfinir le nombre d'élu au Conseil d'Administration
  • Redéfinir la notion d'Assemblée Générale
  • Définir une procédure de vote à distance simplifiant et accélérant nos décisions

Visibilité de PostgreSQL

Que PostgreSQL soit visible :

  • Représenter la communauté
    • Valoriser les contributeurs francophones
  • Utiliser la trésorerie pour favoriser la communauté
    • Financer des projets étudiants
    • Organiser un PGDay francophone
  • Communiquer mieux et plus
    • Créer le buzz en France pour la sortie de PG 9.0
    • Produire des plaquettes pour les particuliers et les entreprises
    • Informer régulièrement les membres de PostgreSQLFr de nos actions
    • Prendre part à des manifestations locales ou créer des rencontres locales partout en France

par jca le 2010-05-04 15:26

CHAR(10)

Une conférence sur la haute disponibilité et la réplication va se tenir à Oxford (Royaume Uni). Un appel à conférence a été posté par Simon Riggs (le père du warm, puis du hot standby).

Le voici :

PostgreSQL CHAR(10) Conference is in Oxford, UK on 1-3 July 2010, professionally organised in collaboration with Oriel College, Oxford.

CHAR(10) stands for Clustering, High Availability, Replication, though includes all forms of Parallel, Distributed and Grid architectures. Every aspect of very large databases and high performance systems on both PostgreSQL and variant open source and commercial distros will be given air time and covered in detail by users, experts and developers. We have exhibition space for the major vendors as well as meeting space for workgroups and interest groups.

We already have 11 speakers from Europe, US and Japan proposing 15 separate talks - we'd like even more. If you've got an interesting topic then please note that we are extending the deadline for talk proposals until next Monday 26th April. Speakers get free attendance, accommodation and full board at Oriel College, just 1 hour from London.

http://www.char10.org/

We will be publishing full schedule in early May and begin accepting registrations soon afterwards, to be announced again at that time.

Please put the dates in your diary: 1-3 July 2010

We hope to see you there.

All the best,

--

Simon Riggs     

par jca le 2010-05-04 15:25

Thursday 29/04/2010

Jean-Christophe Arnu

Convertir des lignes en chaine concaténée avec PostgreSQL

Il arrive souvent que l'on souhaite transformer des colonnes de résultats en « lignes » ou en chaînes de caractères. Avec PostgreSQL la clause IN est utilisable dans des requêtes de sélection de colonnes dont la valeur est « dans une liste » comme par exemple

SELECT
   *
FROM
   "users"  AS u
WHERE
   u.dpt_id IN ( SELECT
                       dpt_id
                      FROM
                       departement
                     WHERE
                       performance > 1000.0
                   );

L'exemple ci-dessus est un cas démonstratif, une jointure serait plus performante Si l'on souhaite utiliser le résultat d'une requête afin de le transformer en chaine exploitable (par exemple concaténée) nous utiliserons des fonctions PostgreSQL. Par exemple, soit la requête ci-dessous

SELECT
   username
FROM
   "user"
WHERE
   STATUS < 2;

va nous retourner

   username
--------------------
  jacques
  pierre
  paul
  jean
 (4 lignes)

Si l'on souhaite concaténer les résultats en une ligne on utilisera par exemple la fonction array_to_string(array,string) de la manière suivante :

SELECT array_to_string(ARRAY (SELECT * FROM "user"),',');
   array_to_string
--------------------------
pierre,paul,jacques,jean
(1 ligne)

array_to_string prend en premier paramètre un type «tableau» et en second paramètre une chaîne de caractère représentant le séparateur qui devra être utilisé pour séparer les éléments du tableau dans la chaîne de sortie.

par Jean-Christophe Arnu le 2010-04-29 10:44

Wednesday 28/04/2010

Humeurs d'un libriste

Import massif dans OpenStreetMap aux Pays-Bas

Un import massif de données relatives à l'occupation des sols aux Pays-Bas est en cours dans la base OpenStreetMap. La qualité de ces données est remarquable (bien supérieure à celle des données Corine Land Cover utilisées en France). Admirez le résultat intermédiaire sur OpenStreetMap. C'est époustouflant ! Pour preuve, vous pouvez comparer le rendu de la zone avec celui de Google Maps.

Les données ont été fournies par Object Vision BV. Vous trouverez de plus amples informations à ce sujet dans le Wiki d'OpenStreetMap.

Vivement que Spot Image rende ses images réellement accessibles à OpenStreetMap. À défaut d'import automatique, nous pourrons atteindre le même niveau de qualité à la mimine.

par sdinot le 2010-04-28 09:05

Thursday 22/04/2010

Guilhem Bonnefille

Smart HTTP Transport

Sans trompette ni fanfare, une petite révolution s'est produite dans Git 1.6.6 : le transport HTTP a été amélioré très significativement.

Jusqu'alors, le transport HTTP ne permettait qu'un simple accès en read-only au dépot. Les plus optimistes diront que c'était déjà pas mal (surtout que la nature distribuée de Git limite la gène induite). Qui plus est, cette ancienne version du transport HTTP générait beaucoup de traffic et chargeait le serveur. Tout ceci a conduit, tout naturellement, à éviter la mise en place de ce protocole de transport.

Pourtant, dans un environnement professionnel, il est fréquent de rencontrer un proxy-firewall qui n'accepte que le HTTP, et certainement pas un protocole maison tel que le protocole de transport natif de Git.

En 1.6.6, les choses ont bien changé, rendant le protocole de transport HTTP beaucoup plus efficace. Qui plus est, ce nouveau protocole de transport permet les push sans avoir à configurer une interface WebDAV.

Pour en savoir plus : http://progit.org/2010/03/04/smart-...

par Guilhem Bonnefille le 2010-04-22 16:56

Wednesday 14/04/2010

Sébastien Domergue

Résumé du Paris JUG sur Scala

Ce billet résume la soirée Paris JUG du 13 avril 2010 qui concernait le langage Scala, langage fonctionnel s'exécutant sur une JVM standard. Ce langage fournit un certain nombre de clés pour des patterns Java qui ne peuvent malheureusement pas encore être écrits de manière réellement concise.
Quels sont donc les apports de Scala, comment l'intégrer à un projet et un avis personnel sont au programme.

Hier soir avait lieu le Paris JUG consacré à Scala dans les locaux de l'ISEP. Voici un résumé de ce qui en a été dit.

Scala : késako?

Scala est un langage de programmation fonctionnelle s'exécutant sur la JVM Java (à partir de la 1.5 et de la 1.4 sous réserve d'une version spécifique) sans modification de celle-ci. Il a été développé par Martin Odersky qui avait quitté le JCP suite à l'intégration des generics qu'il trouvait trop timide à cause de la rétro-compatibilité imposée par Java. Scala, dans cette optique, n'est pas nécessairement rétro-compatible bien qu'à terme cela devrait le devenir. Il s'exécute sur n'importe quelle JVM mais passer de la version 2.7 à la 2.8 peut ne pas être possible sans réécriture de code (c'est un choix pour faire évoluer le langage, je ne rentre pas dans la polémique) ou au minimum sans recompilation. Scala se veut donc plus concis sur certains patterns qui reviennent régulièrement alourdir le code de nos applications et propose de nouvelles fonctionnalités.

Scala ou quand le chameau se met au café

Ce qui m'a frappé dès le départ, c'est cette impression de déjà vu sur la syntaxe. Pour moi, c'est du OCaml écrit dans un .java (un .scala ici pour que le compilateur s'y retrouve mais c'est l'idée).

Une fonction est un objet comme un autre

En bon langage fonctionnel, Scala fait qu'une fonction est un objet comme un autre. Cela signifie qu'une fonction peut être un paramètre comme un autre. On a donc accès aux fonctions d'ordre supérieur. L'exemple le plus flagrant je pense est les traitements sur les listes. La ligne suivante filtre tous les éléments d'une liste d'entiers suivant le prédicat "nombre pair" :

val listResultat=List[Int](1,2,4,5).filter(i => i%2==0)


Bon, la syntaxe est un peu abstraite, ce qu'il faut retenir c'est que la méthode filter prend en paramètre une méthode qui prend un paramètre et renvoie un booléen. En Java, l'équivalent serait d'utiliser un Predicate avec l'implémentation d'une méthode, soit 4 ou 5 lignes de plus.
Cela permet également de composer des fonctions. L'exemple vu pendant la présentation était de prendre une liste de fonction puis de toutes les appliquer à partir d'un objet de départ : il existe une méthode de réduction pour justement éviter de boucler sur les éléments de la liste. Sinon on peut utiliser compose qui permet de composer des fonctions.
La spécialisation des fonctions permet d'obtenir de nouvelles fonctions en fixant un paramètre, par exemple, voici 2 définitions de la même fonction qui multiplie deux nombres :

val multiply(x:Int, y:Int) = x*y
val multiply(x:Int)(y:Int) = x*y

Dans la deuxième formulation, notre méthode à 2 paramètres peut aussi être vue comme une fonction à un paramètre qui renvoie une fonction à un paramètre qui multiplie deux entiers et donc on peut écrire :

val double = multiply(2)

double est une fonction à un paramètre qui multiplie par 2 un entier. L'exemple ici reste très simple mais permet de s'épargner du code en faisant plus appel à la généricité.

L'inférence de type

Le langage Scala permet l'inférence de type. bon, je vois pas quoi dire de plus qui soit vraiment constructif à part que les fonctions deviennent très génériques.

Le pattern matching

Le switch de Java étendu à tout. Je ne vois pas quoi dire d'autre puisqu'il s'agit de pouvoir faire des match / case sur à peu près tout. Il est possible de matcher sur tout type de base (String incluse), sur les types (d'où peut-être un avantage de l'inférence de type), de faire des match structurels (cas d'une liste vide, cas d'une liste à un élément, cas d'une liste composée d'un premier élément et d'une queue pour faire de la récursivité par exemple). C'est puissant et très concis comme code au lieu de nos éternels if dans tous les sens.

Non nullité

En Scala, le null se fait pousser dehors. Le but est ici de se passer des tests if(myObject == null). Pour cela, on encapsule l'objet dans un objet de type Option qui est étendu par les classes None et Some. En gros, on définit l'objet en tant qu'instance de Option puis on fait monObjet.get() pour obtenir la valeur. Si l'objet est vide, get renvoie None qui est un objet absorbant (tout appel de méthode depuis None ne plante pas, ça ne fait rien en fait). Sinon get renvoie l'objet contenu dans l'option. Alors ça fait faire une certaine gymnastique et ça utilise au maximum l'inférence de type, ça peut permettre de se passer des tests de nullité mais, personnellement, je pense que null est aussi un résultat en soi et qu'il peut être bon de le traiter. Ensuite, on peut utiliser ce mécanisme partiellement pour des objets dont la nullité ne pose de problème que pour les NPE et dans ce cas on gagne en nombre de lignes de codes (en clarté c'est à voir...).

Scala : des possibilités alléchantes

Les acteurs

Clairement, il s'agit d'ESB en puissance. Un acteur est une entité autonome évoluant dans un thread ou un pool de thread (j'y reviens juste après) qui dispose d'une boite de messages qui peuvent lui être envoyés et il peut envoyer des messages aux autres acteurs.
Revenons en détail sur toute cette phrase. En Scala, les acteurs peuvent être créés sous 2 formes différentes :

  • un acteur démarre avec un thread alloué à son utilisation
  • un pool de thread est alloué à l'application pour l'ensemble des acteurs. Cette solution est la plus utilisée bien sur.


Un acteur dispose d'une boite aux lettres qui peut contenir tout type de message : texte, objet... Quand il est en attente de message, dès que la boite se remplit il traite le message puis se remet en attente et ainsi de suite.
Un acteur peut être démarré sur une JVM distante en une ligne. Rien à dire, c'est beau.
La librairie Akka propose une gestion plus poussée des acteurs :

  • gestion de la stratégie lors des pannes
  • meilleurs performances
  • remonting transparents (oui, grâce à ça l'acteur peut être exposé en REST, Comet, ...)
  • ajout de modules de sécurité si besoin pour les accès
  • grosse communauté très active


Un acteur peut dialoguer avec d'autres acteurs.

La programmation par aspect avec les traits

Un trait est ce qui se rapprocherait en Java le plus d'une interface avec des méthodes définies directement en interne. C'est à dire qu'un objet Scala peut disposer de plusieurs traits sans pour autant devoir implémenter des méthodes spécifiques. Par défaut, il existe un certain nombre de traits, par exemple un trait Serializable qui permet de disposer de méthodes de sérialisation d'objets. Un trait peut être ajouté à la définition de la classe à la manière d'un implements/extends ou alors à l'instanciation. C'est sans doute là que cela devient le plus intéressant.
Imaginons un produit dans un magasin en ligne. On crée deux traits, l'un qui se nomme Stock et l'autre qui se nomme Update. Notre objet peut avoir le trait Stock lors de son utilisation par un client qui l'achète pour afficher le stock courant de l'objet et le trait Update lorsque l'administrateur du site décide de le modifier pour afficher par exemple dans quel rayon du magasin il est disponible. On peut ajouter autant de traits que l'on veut mais l'ordre peut être important quand le trait override une méthode tout en appelant la méthode parent via super.
Le développement de traits génériques permet de développer des couches transverses et de les inclure sans trop d'adhérence.

Scala : la compatibilité avec le code Java (et .Net)

Scala peut appeler des classes Java sans aucun soucis. D'ailleurs, si on ne se sent plus suffisamment à l'aise avec une écriture fonctionnelle il est toujours possible d'utiliser du bon vieux Java en utilisant toutes les librairies habituelles). En revanche, l'appel de code Scala depuis Java est un peu plus délicat pour au moins la notion de trait qui serait transformée en héritage multiple et de fait interdit sous Java.
Il parait aussi qu'il est possible de communiquer avec du .Net mais aucun exemple ni commentaire n'a été fait sur le sujet.

Développer en Scala

Soyons clairs, les IDE sont encore très inégaux devant Scala. Bon, avant toute chose, des modules de coloration syntaxiques sont disponibles pour pratiquement tous nos éditeurs textes préférés.
Ensuite, pour les IDE plus lourds, on retrouve Eclipse, IntelliJ et Netbeans. Aujourd'hui, IntelliJ est clairement devant les autres avec un plug-in qui a l'air stable malgré quelques lenteurs (une question s'est posée pour savoir si cela venait réellement du plug-in ou juste d'IntelliJ qui est connu pour ses lenteurs). Les deux autres ne sont pas encore suffisamment stables pour être réellement utilisés en développement sans redémarrer plusieurs fois par jour son IDE pour Eclipse et pour NetBeans, c'est purement impossible.

Scala en production

Scala a commencé son buzz depuis juillet dernier avec un fort taux de croissance (mais un taux qui reste faible quand même). L'exemple le plus médiatisé est le portage de la file de messages de Twitter de Ruby vers Scala. Le code source de cette file de messages est disponible ici. D'autres projets existent, EDF, Foursquare... Des témoignages sont disponibles sur le site de Scala.
Néanmoins, les industriels restent assez craintifs sur sa mise en production pour les mêmes raisons que toute nouvelle technologie sur la maintenance, la pérennité, la fiabilité...

L'avenir de Scala

Scala continue son évolution avec la sortie de la version 2.8 annoncée prochainement. Le langage est dans une phase de consolidation et de nettoyage interne, les gros chantiers initiaux étant passés. La rétro-compatibilité devrait arriver avec les prochaines versions mais à tout moment cela pourrait être cassé si le besoin s'en faisait sentir.
Scala met en avant des pratiques et patterns qui intéressent beaucoup de développeurs Java et certains aspects sont à présents portés de Scala vers Java. Par exemple le pattern Actor avec plusieurs librairies. Je vous conseille le comparatif disponible ici qui résume ce portage. Pour les traits ça parait encore difficile puisque cela ressemble beaucoup à de l'héritage multiple mais l'ajout à l'instanciation pourrait faire bouger les choses. Le pattern matching et les fonctions de degré supérieur, je ne sais pas (faut encore que je me renseigne un peu).

Conclusion (personnelle)

Attention, ce passage n'engage que moi, pas du tout les présentateurs de la soirée.
Je ne pense vraiment pas que Scala soit le remplaçant de Java car il reste trop confidentiel et les ports des bonnes idées font que le besoin de passer à Scala risque d'être flou. Je le vois plutôt comme un laboratoire de tests. Évidemment, l'apport du fonctionnel est non négligeable mais on se retrouve avec des choses assez inutiles comme l'inférence de type qui ne sert au final qu'à mettre à genou l'IDE et le compilateur puisque celui-ci va finir par compiler du bytecode donc le typage va être réintégré. Scala a au moins le mérite de faire découvrir d'autres horizons au langage objet (moi je veux des fonctions d'ordre supérieur) et amène des choses qu'on a tous voulu avoir à un moment ou un autre (des switch sur tout, des Acteurs...).
Clairement, je pense que je vais tester les Acteurs (un des portages Java) car je trouve que ça simplifiera la vie, surtout pour distribuer les applications sans y penser.

par Sébastien Domergue le 2010-04-14 14:55

Tuesday 13/04/2010

Sébastien Domergue

MDA : première approche

Bonjour,

sur ce premier billet, je vais parler de l'approche MDA. MDA pour Model Driven Architecture. C'est une approche de conduite de projet à base de modèles, portée par l'OMG. Cette approche ne se limite pas au domaine du logiciel bien que c'est de cela dont je parlerais ici.

MDA : des modèles pour exprimer des processus

Donc, MDA est orientée par les modèles, ces modèles doivent être décrits dans un formalisme qui suit le MOF (Meta-Object Facility). Il s'agit du métamodèle représentant le langage de description. UML n'en est que le représentant le plus répandu (car lui aussi issu de l'OMG), On peut citer par exemple SysML ou QVT en tant que métamodèles.
Un projet réalisé en utilisant l'approche MDA met au coeur du process la logique métier, donc une forte implication du client est nécessaire, tout du moins dans les phases de définition. Il faut modéliser avant tout les processus métier :

  • qui utilise le système : utilisateurs ou systèmes externes
  • quels sont les fonctionnalités du système
  • qui peut faire quoi : quel acteur peut utiliser quelle fonctionnalités
  • l'enchainement métier des différentes fonctionnalités : par exemple, un module "Livraison" est démarré après qu'un module "Achat" aie créé une commande.
  • au sein d'une fonctionnalité, quelles sont les tâches à effectuer, autant par l'acteur que par le système
  • comment l'acteur interagit avec le système


On voit ici qu'on ne parle pas encore de technologies, de frameworks ou de progiciels. Ici, on est dans la définition du métier cible. C'est le modèle PIM (Plateform Independant Model). Bien qu'utile pour cadrer la suite du projet, ce modèle ne doit pas être la fin du processus MDA. En effet, un investissement plus important doit être consenti sur cette phase, en forte interaction avec le client.

MDA : l'exploitation des modèles

A partir de ce modèle, tous les éditeurs de modèles permettent au moins une génération de documentation au format rtf/doc et/ou html. Cette documentation est générée et non retouchée pour conserver la cohérence avec le modèle. Si une modification est à faire, c'est au sein du modèle qui regénèrera un document.

Une fois cette première étape réalisée, si le logiciel le permet, il est possible de transformer le modèle vers un autre modèle (transformation M2M) ou de générer du code (transformation M2C).

Transformation Model-2-Model

Une transformation M2M permet d'effectuer un certain nombre d'opérations automatiques sur un modèle afin d'obtenir un nouveau modèle de travail. Cela peut aller du changement de métamodèle (passer de SysML à UML) à l'intégration d'informations techniques initiales. Pour cela, il faut avoir pu décrire la transformation, les manipulations effectuées, les objets impactés. UML2 ayant introduit les profils UML, l'ajout d'un stéréotype à un objet permet de filtrer différemment les objets et ainsi d'effectuer des manipulations différentes (sémantique du modèle). Cela permet de commencer à inclure la plate forme cible.
Le modèle résultat peut être modifié à postériori mais uniquement sur les aspects qui découlent de la transformation. Il ne s'agit pas d'inclure ici un nouveau cas d'utilisation mais plutôt de définir des variables relatives à la plate forme cible.

Transformation Model-2-Code

Une transformation M2C fournit du code. Par code, il s'agit de tout élément nécessaire à la réalisation du projet. Cela peut être des classes, des fichiers d'en-tête, des fichiers xml ou de propriétés... Généralement, il s'agit des aspects techniques qui sont générés car ils n'incluent aucune logique mais il s'agit de couches qui, si elles devaient être réalisées manuellement, prendrait beaucoup de temps, pour des développeurs qui n'aimeraient pas faire ça et donc potentiellement plus de bugs (qui sont les plus difficilement détectables car dans les couches les plus basses et techniques de l'application). Aujourd'hui, on peut tabler sur une génération de l'ordre de 30% de l'application, avec quasiment 90% des fichiers techniques générés.

MDA n'est pas encore le Saint-Graal

L'utilisation de la méthode MDA implique nécessairement de nouvelles compétences. Les premières phases de spécification et de conception nécessitent des compétences fonctionnelles et de modélisation. Cela prend plus de temps également et il faut parfois faire comprendre au client que s'il doit participer à plus de groupes de travail c'est pour au final ne pas avoir à refaire des pans entiers de son application. Cela permet aussi d'encadrer les développements grâce au maquettage des écrans et à la définition des services appelés. Chaque service implémentant un certain nombre de règles.
De plus, cette méthode implique de savoir et de pouvoir développer les transformations. Initialement il s'agit d'un investissement, qui a déjà été fait pour les technologies Java/J2EE en tout cas. Par la suite, il s'agit d'ajouts en fonction des besoins. En tout cas, ce n'est pas encore une approche "Out of the box".

Conclusion

Pour conclure cette présentation rapide de MDA, je dirais que le secteur est en pleine effervescence à l'heure actuelle. Les nouvelles spécifications UML3 sont en cours à l'OMG, de plus en plus d'entreprises utilisent cette approche et de nouveaux outils émergent. Dans les posts suivants de cette rubrique, j'essaierai de revenir sur les points survolés très rapidement ici et de parler un peu plus de ce qui est fait à CS dans le cadre de cette approche.

par Sébastien Domergue le 2010-04-13 06:57

Guilhem Bonnefille

Licence "IP" crée au Ministère de la Justice

Le ministère de la justice crée une licence Publique : IP inspiré des CC...

http://www.zdnet.fr/blogs/l-esprit-...

(Lu sur liste OpenStreetMap)

par Guilhem Bonnefille le 2010-04-13 06:46

Thursday 08/04/2010

Jean-Christophe Arnu

Election à l'association PostgreSQLFr

J'ai envoyé hier un mail sur la liste de diffusion des membres de PostgreSQLFr afin de faire procéder au vote. Ce mail décrit la procédure de vote pour les élections du conseil d'administration (le 2010-04-22) et du bureau (uniquement pour les membres du conseil d'administration le 2010-04-29 ) ainsi qu'un vote de principe sur l'appel à proposition de Damien Clochard sur le financement de projets de développement (le 2010-04-29 également).

Pour une version plus lisible du mail, se reporter à la page du wiki de l'association.

par Jean-Christophe Arnu le 2010-04-08 08:30

Monday 22/03/2010

Jean-Christophe Arnu

Assemblée Générale de PostgreSQLFr

Bientôt l'association PostgreSQL va se réunir en Assemblée Générale (à l'occasion de Solutions Linux). Je vous donnerai plus d 'information très bientôt!

par Jean-Christophe Arnu le 2010-03-22 18:46

Assemblée Générale de PostgreSQLFr

L'assemblée générale de l'association PostgreSQLFr a eu lieu ce mercredi 17 mars à 21heure à l'association pour le Progrès de l'Homme (Léopold Meyer) à Paris.

par Jean-Christophe Arnu le 2010-03-22 18:46

Adhérer à PostgreSQL Europe, maintenant c'est possible

PostgreSQL Europe vient de modifier ses statuts afin qu'il soit possible d'en devenir membre. Pour celà il faut suivre la procédure suivante :

  1. Créer un compte «communautaire» en se connectant ici
  2. Se connecter sur le site de PostgreSQL Europe en cliquer sur le lien «Your Membership» et identifiez vous

Le montant de l'adhésion est de 10€ pour deux ans. Il reste deux semaines au mieux pour devenir membre alors sautez le pas!

par Jean-Christophe Arnu le 2010-03-22 18:45