jeudi 26 juin 2014

Retour sur Hackathon impots.gouv.fr

Il y avait du monde pour répondre à l'appel de la DGFiP pour imaginer le futur portail des impôts.


La team en pleine action. Les idées ne manquaient pas:


Notre proposition: une plate-forme de distribution:

Coté architecture , il ne faut pas hésiter à se faire plaisir quand c'est openbar:



Nous nous sommes amusé avec: 
parse.com : un frontal REST à une base NoSQL (pour stocker les informations de la timeline)



Et kafka 



Un petit tour sur bitbucket

Avec bien sur une dose d'angularJS



Un peu de D3 JS  (a essayer dimple.js plus tard )





Je me suis fait des nouveaux amis:






































j'ai visité un atelier d'impression 3D:





Et le codage pendant ce temps ? 


Heureusement les gars d'altic ont assurés.


Le graphiste de wcie  etait le top du top:


Peut-être bientôt sur vos tablettes:
image wcie
Ce que reste à faire: passer du prototype mode puzzle à un vrai projet qui fonctionne.





samedi 21 juin 2014

Opérations avancées avec MongoDB

Dans une video, j'avais présenté une introduction à MongoDB.

Pour faire une suite voici quelques manipulations avec le client mongo ou  l'API Ruby.



Pour commencer: 

Avec le client mongo :
voir toutes les bases : shows dbs 
voir toutes les collections d'une base: show collections

Pour les recherches :


Rechercher à l'aide d'une expression régulière :ATTENTION à réserver que pour les champs 'string'
Toutes les stations de velib dont l'adresse contient le mot 'filles' (ex filles du calvaire )
db.stations.find({address :/.+filles.+/i}).count()

ou en version moins compacte :
db.stations.find({address : $regex :{/.+filles.+/i}}).count()

Pour inverser la sélection : $regex :{/(?!.+filles.+)/i}

Avec l'API Ruby:
rech = @stations.find({:address => /#{Regexp.quote(arr)}/}).each { |p| ...


Rechercher les entrées avec qui n'ont pas un champs précis:
db.stations.find({rem: {$exists : false}})

ou 

db.stations.find({rem: null})  # cette forme ne fonctionne pas si un champs contient la valeur null

Avec l'API Ruby:

rech = @stations.find({:arrondissement => nil})....

Afficher que certain champs en sortie:

db.stations.find({arrondissement: 75001},{'state.total_slots' : 1})

Avec Ruby : utiliser le symbole :fields :


@pgm = @db['jcl'].find({'source' => {'$exists' => true}},{:fields => {'jcl' => 1 , 'source' => 1, '_id' => 0}} ).to_a

(le champs id ou _id est special ,c'est l'identifiant des entrées.  il est toujours retourné sauf si , la valeur de sa clé est mise  à zero.)

Une recherche avec une  condition qui porte sur  deux champs de l'entrée (utilisation de $where et this.
(API Ruby)

@alerte = @coll.find('$where'  => "this.reel['total moe'] >= this.valide['total moe']" , 'semaine' => semaine )

Enfin: un tri
db.stations.find({},{address:1}).sort({'state.total_slots' :-1 }).limit(1)
Ici , le tri combiné à   limit(1) permet de récupérer la valeur la plus grande.

Regroupement d'entrée: 


  • Le plus simple est l'opérateur distinct:

db.stations.distinct('arrondissement')

distinct retourne un array (tableau) , aussi pour connaitre le nombre d élément:
db.stations.distinct('arrondissement').length  



  • L'operateur group:


Un autre manière de déterminer le maxima d'une série

@arr = @coll.group( :initial => {cmax:0} ,:reduce =>  "function(obj,prev) { if(prev.cmax < obj.semaine) prev.cmax = obj.semaine; }" )

un autre exemple avec le client mongo
db.stations.group({initial : {cmax : 0 } ,reduce : function(obj,prev) { if (obj.state.total_slots > prev.cmax) prev.cmax = obj.state.total_slots }})

[ { "cmax" : 72 } ]

Enfin un exemple de regroupement avec cumul intermédiaire et condition :

esi  =@coll.group(:key => :esi ,
                       :reduce => "function(obj,res) {res.pr.push({projet :obj['projet'],v: obj['valide']          ['moed'], r:obj['reel']['moed']  });
                                    res.valideESI += obj['valide']['moed'] ;  
                                    res.reelESI += obj['reel']['moed'] ; }",
                        :initial => {  :pr =>  [],
                                       :valideESI => 0,
                                       :reelESI   => 0 
                         },
                       :cond => {:semaine => max})


vendredi 20 juin 2014

Les vues avec angularjs

Dans cette video et dans les slides , une présentation de la gestion des vues dans angularjs.
C'est la technique de base pour réaliser des SPA (application d'une seule page)


Pour cela , il faut récupérer l'extension  angular-route sur le site d'angularJS.

Le code est simple:

Une video est associée à la présentation (disponible ici)


Le serveur web est porté par Sinatra:


Quelques lectures:



samedi 14 juin 2014

Suite et fin de la vidéo de présentation d'angularJS

Je termine ma présentation d'AngularJS par une application minimaliste.


Au passage je fais une petite démonstration de l'IDE  Brackets.

Pour bien commencer : 2 livres gratuits consacrés à AngularJS


Les slides de support de la video sont :




La video est sur youtube: lien ici



lundi 9 juin 2014

Une introduction à angularJS et aux Single Page Application

J'étais parti pour faire une video sur AngularJS mais j'ai éprouvé la nécessité de remettre cette technologie dans un cadre plus général de développement des applications.

J'expose le système courant du templating coté serveur et coté client.
Templates coté client 

Avec ici la synthèse:


Mais le plus important est de replacer le phénomene des SPA: Single Page Application dans le contexte. REST , MVVM (angularJS ) , SPA et NoSQL sont autant des pièces d'un même puzzle.

Pourquoi des applications de ce type:

  • Pour des raisons Economiques: les coûts sont partagés , elles sont scalables, elles sont simples.
  • Pour la simplicité des solutions misent en oeuvre.

 Au premier abord toutes ces notions semblent très compliquées, mais en commençant doucement par des exemples simples, tout devient possible.

En conclusion: ce n'est pas un simple mouvement de mode. Ces évolutions touchent la manière de faire des applications, de conduire des projets.

Le support des slides de la video est ici:lien



Sur youtube : la video est diffusée a cette adresse.

jeudi 1 mai 2014

Pour bien commencer avec les Architectures REST ou RESTFUL

La vague  REST va déferler sur nous. Hélas, la encore des marchands de rêve vont chercher à vous vendre du REST au kilo.

Ce qu'il faut bien  comprendre: Les architectures REST devront être une CONSÉQUENCE de l'évolution de vos applications  et non pas une CAUSE d'évolution de celles-ci.
En clair: commencer par mette du REST sans avoir ce qui va avec, mettra en difficulté votre système informatique, vos équipes etc.

Pour commencer le REST (ou RESTFUl ) c'est quoi ?


«Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.»

Un chapitre ici traduit en français. (Le 5eme : un des plus important)
  • C'est un livre de chevet (publié en 2007) :lien ici 

Couverture ( observez qui à donné son avis sur le livre)


(selfie truqué : pourquoi ? : à vous de trouver l'erreur)



  • C'est une série de principe : 


1) Utilisation des verbes (Méthodes) du HTTP.
GET : lire une ressource
DELETE : supprimer une ressource
POST et PUT: pour creer ou modifier une ressource
(ou inversement : l'idée est d avoir un verbe pour créer différent de celui utiliser pour modifier)

source stackoverflow: http://stackoverflow.com/questions/630453/put-vs-post-in-rest

2) Chaque ressource a son URL. On interagit avec les ressources en combinant les  url avec les methodes HTTP.

  • GET http://www.example.com/customers/12345
  • GET http://www.example.com/customers/12345/orders
  • GET http://www.example.com/buckets/sample
  • PUT http://www.example.com/customers/12345
  • PUT http://www.example.com/customers/12345/orders/98765
3) Pas de session gérée  coté serveur : Toute l'information de session est stockée sur le client ET donc chaque requête est autonome et complète.

4) Le serveur applicatif ne sert qu'a délivrer de la donnée (le plus souvent au format JSON et non plus XML)

Voila le rapidement présenté le  REST.

Pourquoi le REST a-t-il le vent en poupe ?

  • Il permet de répartir les coûts d'infrastructure entre le fournisseur de ressource (service) et l'utilisateur (poste client). Il est donc pleinement compatible avec le modèle économique des clouds. Les traitements coûteux en CPU  (assemblages des pages WEB, manipulation des donnée)  sont réalisés sur la machine du client. 
  • Les infrastructures et les applications sont plus simples: pas besoin d'avoir des serveurs de session, des bus d'entreprise etc. 
  • La scalabilité est linéaire: sans partage de session à prévoir, avec des serveurs à gestion d 'événement (Node.js , nginx) , l'ajout d'un serveur augmente surement le nombre de connexion possible.
  • Il met fin au débat entre les langages et les framework : PHP ,Java, Spring, Express, Rails  :La partie serveur ne sert qu'a délivrer de la donnée JSON. Le seul langage à maîtriser vraiment est le Javascript (le seul langage universel pour le navigateurs). Aussi, si vous n'avez pas les ressources de développement aguerries au Javascript l'adoption du  REST sera difficile.

Aussi mettre en place du REST sans avoir un idée de la stratégie à mettre en place coté client (Angular, Backbone , Ember ?...) c'est prendre le sujet à l'envers.

Comment reconnaître le vrai du faux REST.


Le critère de la session gérée coté client est important, sinon le simple test suivant est suffisant :

Est ce que votre application fonctionne avec le simple client HTTP en ligne de  commande CURL ?

Ex :  curl -X DELETE http://localhost:4567/pgm/5352d84751514034cc000048

(la partie serveur qui répond à la requete)
## Restful uri

##
delete '/pgm/:id'  do
@id_pgm =  params[:id]
@pgm =  @db['pgm'].remove('_id'  => BSON::ObjectId(@id_pgm) )
response.write ("{ok}")
end




















samedi 29 mars 2014

Les bases NoSQL pour stocker du XML

Pendant de nombreuses années le XML tenait le haut du pavé dans le domaine de format de fichier: pour les données , les configurations etc. Le XML était partout:

Source : https://delta-xi.net/gfx/xml-landscape.gif

Depuis, on revient à un usage plus raisonnable du XML. Et des formats comme le JSON, le YAML ont  maintenant trouvés leur place.

Comment stocker efficacement des fichiers XML ?.

La solution habituelle.

La solution basique consiste à extraire les informations pertinentes du XML pour les sérialiser dans une base de données. Le format XML se prête mal a des opérations de recherche.
Cette solution à ses limites surtout pour des enregistrements XML de taille variable. L'exemple qui vient à l'esprit est celui de la récente réforme des échanges bancaires: le SEPA.
D'un format fixe de 240 caractères , les nouvelles normes ont évoluées sur des articles XML de taille variable. Le volume est plus important en raison de l'utilisation du XML, du détails des opérations mais d'une taille non prédictible.

 Des solutions à base de NoSQL.


Le principe de ces solutions est de stocker les fichiers XML échangés dans  une base de donnée Nosql. Le choix de cette base se portera sur un dispositif orienté document comme MongoDB.
source:
http://blogs.the451group.com/information_management/2011/04/15/nosql-newsql-and-beyond/

Les informations seront stockées sous deux formes:
Sous la forme d'origine en XML et sous un format JSON avec une succession de  clé / valeur. Les opérations de recherche se feront sur la partie JSON.

Ci-dessous un exemple de programme en Ruby utilisant la librairie nokogiri pour parser le XML:

Le fichier XML est exploré récursivement  puis injecté dans une base NoSQL mongoDB par ce script:


Le fichier XML sera injecté par ailleurs.

Ainsi l'information sera disponible sous deux formes avec une des formes autorisant des recherches multicriteres. Le stockage dans un système sans schéma est particulièrement adapté à des informations hétérogènes.