samedi 31 décembre 2011

comparaison frameworks #javascript : infographie

Sur ce site une infographie qui compare la popularité des différents framework javascript. Résultat : jQuery vainqueur par KO.

Free Web Resources
Javascript Frameworks and jQuery Infographic is brought to you by WebAppers.com

mercredi 28 décembre 2011

serveur documentaire en #coffeescript pour node.js

Il arrive parfois d'avoir besoin d'un petit serveur de document en complément d'une application métier lourde.

ci dessous un exmple de programme en coffescript (qui sera traduit en javascript) pour un moteur node.js



Le programme commence par récuperer les parametres de lancement
Pour chaque requete le serveur vérifie la présence du fichier dans son cache mémoire (ligne 24-29) . Si le fichier n'est pas en cache, il va le lire, l'envoyer puis le mettre dans son cache mémoire. Le programme est tout simple et il présente une alternative interressante à un serveur Tomcat ou apache.
Il suffit de déployer  un sous-répertoire de document  dans le répertoire d'installation.

Le point fort de ce serveur est sa simplicité (une vingtaine de ligne)  et sa robustesse.  Par sa conception et son moteur d'exécution il est capable d'encaisser une charge supérieure à un tomcat ou a un apache dans les mêmes conditions.
C'est un serveur qui ne coute pas cher à deployer ou à maintenir. Il offre plus de sécurité qu'un serveur apache pour le même usage: pas besoin de mettre des options de droit sur l'affichage de répertoire

Le programme est disponible sur https://github.com/germanlinux/Lemon-labs/tree/master/nodeJS
L'idée originale est de casimir Antunes. J'ai ajouté la gestion du cache inMemory et le controle de l'existence des fichiers.



vendredi 23 décembre 2011

5 tendances pour 2012 #nodejs #html5 #javascript


La fin d'année arrive avec son lot de prédiction, de tendance pour l'année 2012.
Je vais faire ici ma liste des 5 tendances qui vont  dominer ou non l'année qui arrive.
Par honnêteté je réaliserai l'an prochain à la même époque un bilan.

Tendance 1: De plus en plus de chose font se faire en javascript coté client. HTML5 annonce une mutation sur la manière de faire des applications. jQuery, Backbone , batman  seront les valeurs montantes. Les raisons de ce phénomène ?:
a) La fragmentation des postes clients (pc, tablettes, smartphone)
b) les couts de traitement coté serveur vous sont facturés cash (cloud computing, serveur , salle machine)

Tendance 2: amaigrissement des frameworks : c'est le corollaire du point 1. Les serveurs ne sont que des distributeurs  de données , en JSON si possible,  avec une simplification à l’extrême. Une application métier  sera l’agrégation de mini-services hétérogènes.

Tendance 3: Les entreprises vont continuer à investir dans les réseaux sociaux (Facebook pour ne pas le citer). Après les pages de groupe ou de fan, l'étape suivante est la création par les entreprises d'applications intégrées à Facebook. La force de Facebook n'est pas son contenu mais son architecture. C'est  une architecture ouverte qui permet à chacun de développer des applications qui viennent s'intégrer à Facebook (exemple ici avec Rails) .

Tendance 4: Virage de Twitter, l'usage que je préfère est le partage de lien. Il permet de savoir que telle ou telle personne   est en cours de lecture d'un document. Delicious remplissait ce role mais depuis peu , il se tourne vers la curation de contenu, dommage. L'autre usage de twitter est la recherche d'information en continu. 2012 sera une année charnière pour twitter qui doit dégager une logique économique ou etre mangé par un gros (Facebook , microsoft ou google)

Tendance 5: Les bases de données NoSQL. Les volumes de données explosent et les entreprises ne savent plus les analyser (moins de 10 % de données sont exploitées) . Les bases NOSQL ne vont pas résoudre ce problème mais ne font que le repousser.


Les conséquences de tout ca:

Croissance de javascript et HTML5 dans les systèmes d'information. Javascript va prendre pied sur le coté serveur avec la révolution de node.js. Node.js permet à un développeur moyen de programmer des services asynchrones repoussant très loin les limites: en temps de crise , l’intelligence remplace l'argent. Dans le monde JEE scalabilité est synonyme d'achat de serveur, c'est la fin d'une époque.

Seuls les framework qui  anticiperont ce mouvement vont tirer leur épingle du jeu: parmi ceux ci :Rails.

Posez vous cette question: c'est le framework qui est à votre service ou vous qui êtes à son service.


dimanche 18 décembre 2011

Le blues des frameworks MVC #node.js

Le concept du framework MVC  (modele vue controleur)  date du début des années 80 , bien avant le temps d'Internet ou de Java/JEE.
mvc 2

Jusqu’à maintenant les choses étaient simples. Un bon gros serveur MVC générant des vues pour le client.
La carrière de l'informaticien était toute tracée: Le MVC serveur tu maitriseras. Hélas des elements sont venus parasiter ce bel édifice.

  • La montée en puissance du javascript.

Boosté par les gars de google ou de microsoft , le moteur d'exécution javascript est celui qui a gagné le plus en performance.

  • Le javascript est le seul langage supporté par tous les navigateurs.
  • La segmentation du poste client
Le PC est maintenant en concurrence directe avec les smatphones ou les tablettes. Le concepteur se retrouve devant une fragmentation du matériel et il doit gérer tous les cas de figure (clavier / ecran tactile)
ET cela même au niveau des applications métiers

 Il n'est donc  plus réaliste d'avoir tout le traitement de la vue préparé au niveau du serveur. Le framework se trouve réduit à un distributeur de données en ... JSON.  

  • Plusieurs frameworks et non plus un seul framework

Certains traitements sont déportés sur le client mais sans pouvoir êtres terminés.
Prenons l'exemple d'un export CSV pris en charge par du javascript sur le poste client:
A)  Le client recoit de la donnée en JSON
B)  Le client retravaille les données et fabrique un export CSV
C) Le client NE POURRA pas enregistrer son travail sur son poste local (pour des raisons de sécurité, le navigateur refuse de dialoguer avec le système de fichier local) .

La solution est d'envoyer le fichier CSV vers un serveur qui se chargera de retourner le fichier reçu avec la bonne entete. Ce serveur joue le rôle d'un miroir qui se contente de renvoyer ce qu'il reçoit du client. Pour cela une dizaine de lignes suffit, nul besoin d'un framework embarquant plusieurs milliers de ligne de code.

Ainsi l'architecture applicative ne sera pas composée d'un gros serveur MVC mais de plusieurs composants hétérogènes de taille réduite.

On ne peut plus parler de modèle MVC. Sur ce site http://blog.nodejitsu.com/scaling-isomorphic-javascript-code  Charlie Robbins  liste les differents modèles induits par l'utilisation de framework client (backbone.js , batman.js etc ) et introduit la notion de RVP : Resource-View-Presenter




C'est pour ça que les frameworks  'classiques' vont devoir s'adapter ou disparaître. A ce jour seul Rails avec les versions > 3.0 a pris le parti de se mettre en retrait sa partie serveur pour mettre en avant la partie cliente.