Livres informatiques gratuits pour noel

Sur github , victor felder a eu la bonne idée de référencer  les livres informatiques gratuits.
Le lien est ici. La partie française est là.

J'ai cherché aussi des livres gratuits sur spring-batch:

Lien ici

Et sur jenkins (lien ressource en francais ici)

Immortel COBOL : un framework MVC en COBOL

Avec le projet COBOL on Wheelchair donnez une seconde jeunesse à vos développements COBOL.

Ce projet est ici   il permet d’écrire des applications WEB en COBOL selon le modèle MVC .

Le prérequis : un serveur HTTP, un compilateur COBOL (ex: openCobol sur Linux)  ET des développeurs COBOL.
  Les parties Controleur et dispatching semblent marcher  mais la partie modèle (accès aux données) n'est pas abordée.
Il n'y pas de doute, les développeurs COBOL sont de la tribu des immortels.

Pourquoi Paypal migre ses applications de Java/J2E vers Node.js

Paypal a fait une annonce qui fait le tour du web: cet acteur majeur dans le moyen de paiement a annoncé l'abandon de Java/J2E en faveur de Node.js pour tous ses services.
Lire l'article ici.  ou ici en francais.
Cette décision est motivée par:

• La durée raccourcie du cycle de mise en production
• La durée raccourcie d'apprentissage de la filière Javascript
• Et surtout pour des raisons de coût et  de performance. 

Site Payal:(lien ici)

Sur la performance:

• Double the requests per second vs. the Java application. This is even more interesting because our initial performance results were using a single core for the node.js application compared to five cores in Java. We expect to increase this divide further.
• 35% decrease in the average response time for the same page. This resulted in the pages being served 200ms faster— something users will definitely notice.

Sur les couts:

• Built almost twice as fast with fewer people
• Written in 33% fewer lines of code
• Constructed with 40% fewer file

Les gains  d'apprentissage constaté dans la nouvelle filière est  de 1 pour 10  (1 jour pour javascript vs 10 jours pour J2E) . La pile J2E utilisée était le  framework Spring.

Paypal a mis en place une pile logicielle à base du framework Express. Et a reversé des librairies javascript servant à prendre en charge la sécurité dont

Lusca

Out-of-the-box application security. Lusca is middleware that can be deployed over Express, and configured to plug common attack vectors. When used, it will:

• Enable Cross Site Request Forgery (CSRF) headers.

• Enable Content Security Policy (CSP) headers.

• Enable X-FRAME-OPTIONS headers to help prevent Clickjacking.

• Enable Platform for Privacy Preferences Project (P3P) headers.

Lusca (lien ici) implemente la couche sécurité pour Express.

Donc: moins de ligne, moins de personnel , plus rapide et plus simple.

Installation de Jenkins; continuous integration system

Le projet phare pour faire de l’intégration continue était jusqu’à présent Hudson . Oracle par le rachat de SUN s'est retrouvé à la tête de projet opensource. Avec les conséquences suivantes: fork de Mysql , openoffice et Hudson.
Jenkins est la suite de Hudson en dehors de la sphère d'Oracle.

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produitpas de régression dans l'application développée. Bien que le concept existât auparavant^{[réf. nécessaire]}, l'intégration continue se réfère généralement à la pratique de l'extreme programming. (source wikipedia) 

L'installation de jenkins est simple: soit par le gestionnaire de paquet, soit par téléchargement de l'archive et son lancement par la commande java.
Jenkins embarque sont propre serveur web.
Aussi après son lancement par:

java -jar jenkins.war

donnera dans son navigateur : (http://locahost:8080)

http://localhost:8080

Pour un démarrage automatique par le systemV  d'unix:

 Ubuntu propose un utilitaire graphique Bootup-Manager pour gérer le démarrage des services.

Jenkins permet de lancer n’importe quel batch  en plus de sa fonction principale de construire et de tester des projets.

Jenkins est utilisable pour des projets en Java mais aussi PHP, Ruby et javascript (node.js)

Applications COBOL: Les belles anciennes

L'informatique connait actuellement un certain nombre de mutation. Les smartphones,les tablettes  le cloud, les réseaux sociaux , le NoSQL et le bigdata: des mots qui rythment les avancées technologiques. Mais on oublie vite qu'il reste des milliers de programmes COBOL comportant des millions de ligne . Sur ces programmes reposent l'ossature des traitements réalisés par les Administrations, les Banques ou les assurances. Ces applications sont un peu les oubliées de l'informatique. Elles sont portant  des belles anciennes.

3 choses à savoir au sujet de ces applications:

1 ) Il ne reste que le meilleur.... et le pire

Dans la plupart des cas  les applications restantes sont bien écrites , seuls les meilleurs programmes ont survécus , un peu comme une sélection naturelle. Un mauvais programme , mal écrit , sans évolution possible parce que trop complexe a déjà fait l'objet d'un portage vers des technologies plus modernes. Il reste le haut du panier des programmes COBOL. Hélas à coté de ces bons élèves se trouvent des programmes 'stratifiés'. Chaque évolution faisant l'objet d'un empilement supplémentaire.

2) Coût de maintenance.

Elles ont un coût d'entretien  faible car elles sont sûres  Elles ont tourné  des millions de fois avec des cas de figure inimaginables. Chaque recoin de l’application a été testé en réel. Le coût de correction d'une application COBOL est moins élevé que pour une application J2E

( 5,42 $ par ligne de code Java , tandis qu'une erreur sur Cobol ne coûte que 1,26 $)  

source: http://www.lemondeinformatique.fr/actualites/lire-erreurs-de-programmation-java-coute-plus-cher-que-cobol-46976.html

3) Lecture simplifiée de l'algorithmie des programmes COBOL 

La composition d'un programme COBOL facilite sa prise en main.

Sur 100 lignes de programmes COBOL seules 20 implémentent directement la partie métier. Les autres servent à mettre le programme en relation avec son environnent (ENVIRONMENT division ) 

ou à définir les données à traiter (DATA division). L’algorithmie est regroupée dans très peu de ligne dans la PROCEDURE division. Ce phénomène  de concentration ne se retrouve pas dans des programmes issus d'une approche objet hébergés au sein d'un framework: on assiste dans ce cas un éparpillement façon puzzle de algorithmie générale du programme.

Façon puzzle : RIP

Les coûts.  

Aussi, les coûts / risques  des anciens programmes  (legacy) viennent d'un part de l'infrastructure MAINFRAME à entretenir  (licence et matériel) et d'autre part de la perte de compétence sur la partie métier (absence de documentation générale) . 

La  génération des programmeurs COBOL va arriver à l'age de la retraite. 

Je recommande aux jeunes ingénieurs de passer par la case 'COBOL' pour booster leur carrière 

Le retour des disques vinyles

Alors que faire ?

Cette question revient souvent dans les forum comme quora.com

A la question: pourquoi les banques continuent à utiliser leurs programmes  COBOL ?

Voici une des réponses qui résume bien: 

J'ai travaillé dans l'autorité de conception technique pour Natwest Bank et Royal Bank of Scotland. Ceci est un résumé de ce que le chef de la stratégie technique m'a dit une fois:

Le montant d'argent que la banque a investi en COBOL et d'autres technologies plus anciennes est massive.

Cet immense investissement au cours des décennies a abouti à un système bancaire de base qui a des capacités qui ne sont pas reproduits par les éditeurs de progiciels. 

Personne ne sait vraiment comment l'énorme monticule de code spaghetti fonctionne réellement. Le projet de reverse engineering   serait un projet gargantuesque.

Les projets gargantuesques ne sortent jamais

Et quel serait l'avantage - le système fonctionne comme il est.

Architectures orthogonales

J'ai entendu une fois l'expression 'architectures orthogonales'  sans avoir plus de détail.
En piochant à droite et à gauche, on imagine que cette notion fait référence aux des
 architectures verticales et horizontales.

Le modèle 3tiers

On a d'un coté des modèles d'infrastructure en 'tiers' avec généralement 3 tiers:
Le serveur web , le serveur de traitement (applicatif) et le serveur de données (SGBD) .

La conception MVC

A cette spécialisation  des rôles  s'ajoute un découpage fonctionnel en couche MVC 

Le serveur applicatif met en oeuvre un ensemble de design pattern: Model Vue Contrôleur (inventé bien avant le WEB) 

Et le reste: OOP , OS

A ce mille-feuille vient s'ajouter les couches liées au développement en approche objet puis celles du système d'exploitation.

Et donc..

On se retrouve avec un empilement de module , de composant de nature et de taille hétérogène.

Or quel est l'objectif:  Offrir un service de qualité à nos utilisateurs. Ici intervient la notion de scalabilité. Comment supporter un nombre d'utilisateur plus important avec des volumes de données en hausse ?.

A chaque fois le problème est botté en touche en direction des  responsables d'infrastructure. 

Leur  seule  réponse possible est  d'augmenter le nombre de serveur pour doubler, tripler les composants. 

Mais empiler des briques hétérogènes fragilise la stabilité de l'ensemble. C'est coûteux pour un rendement marginal décroissant.  Car cet empilement ne donne pas un rendement d’échelle linéaire. 

Il faut trouver des systèmes pour partager des sessions serveurs , gérer des caches à tous les niveaux, des répartiteurs etc.  bref le prix à payer est élevé. 

La scalabilité horizontale consiste à augmenter le nombre de machine. La scalabilité verticale vise à augmenter la puissance unitaire des machines.  L'orthogonalité cherche à combiner les deux approches en par une simplification des architectures.

Vers des architectures pus simples et ... moins coûteuses.

La première règle à mettre à oeuvre est de réaliser des applications avec des architectures simples avec moins de couche.

Règle 1: simplifier les couches d'abstraction: chaque abstraction coûte et ajoute de la  complexité  

  

Avez vous besoin de faire une application métier de gestion ou un site de publication ?

Si la réponse est 'une application métier' , vous n'avez pas besoin d'un serveur web complet pour votre application.  

Votre choix doit se tourner vers des serveurs applicatifs à gestion d’événement non bloquants et asynchrone  (Non-bloking I/O event loops) comme Node.js pour javascript , VertX pour Java ou eventmachine pour ruby.

Et des mico-frameworks comme Express ou Sinatra. 

Dans ces technologies , le développeur  travaille directement son cœur de métier: la mise à disposition de ressources. Il n'est plus tributaire de la configuration lourde d'un serveur HTTP.

Un process en attente sur un serveur =  gaspillage de ressource = les serveurs vous font les poches.  

Règle 2: Réfléchir en terme de conteneur autonome. 

Votre application doit être l'assemblage de briques identiques autonomes. Ces briques ne doivent pas gérer ou partager des sessions. Celles ci sont prises en charge par le client (REST: les requêtes sont autonomes

Ce qui implique aussi que chaque conteneur accèdes à des données dans son contexte. 

Aussi un conteneur embarque : une couche HTTP, l'application métier et le backend de stockage.

Comment passer d'une architecture 'classique' à une architecture moderne. 

• Tout d'abord la partie applicative:

• Puis la partie frontale :

Pour accéder aux conteneur, il est possible de placer en frontend le serveur NGINX. Ici ,il n'est pas utilisé comme un serveur web mais comme un reverse-proxy avec des fonctionnalités de répartition de charge.

• La partie backend ou stockage:

L'usage d'une base NoSQL viendra compléter le dispositif et rendra chaque 'nœud' autonome les uns par rapport aux autres.

•  La partie SSO  peut elle aussi être implémentée sur chaque nœud: 

  

Ici , il n'est plus question de SSO préemptif ou coopératif: on est dans un mode de micro-SSO 

Pour aller plus loin.

L'idée générale est d'obtenir des boites identiques autonomes un peu comme ceci :

Permettant empilements à la fois verticaux et horizontaux = Orthogonaux  = des constructions solides.

Le site Colbert 2.0

Le ministère du Redressement productif a mis en ligne sont outil Colbert 2.0 destiné à calculer les gains de relocalisation. Quel est l'architecture du site ?:

- Le moteur est en PHP sur un serveur Apache.
- Utilisation de jquery pour faciliter les échanges avec  l'utilisateur
- Utilisation du framework 'Bootstrap' pour la mise en page et le design.

Bootstrap est une collection de javascript , de feuille de style (CSS) qui permet de réaliser des sites web bénéficiant des dernières avancées ergonomiques. Bootstrap permet de gèrer des affichages sur mobiles ou tablette : (responsive design) , le projet est porté par les équipes de twitter. 

mongodb : premiers pas avec cette base nosql

Et une vidéo de plus consacrée à mongodb: Les premières manipulations

Le support est en ligne ici :

Mongodb101 support de la video pour débuter from eric german

La partie vidéo seule est ici:



Les sujets abordés sont les suivants:

j'evoque l'injection massive par la commande mongoimport
La syntaxe est la suivante:

./mongoimport --file ../../stations.json --collection stations --db velibdb --jsonArray

Le dernier paramètre (jsonArray) sert à indiquer que les documents JSON sont  les uns à la suite des autres dans un tableau.

J'utilise un fichier opendata sur l'état des stations  Velib issu du site: http://eaupen.madebymonsieur.com/velib

Le programme ruby  servant à mettre à jour  les informations des stations est donné ci-dessous:



Les prochaines vidéos porteront sur les recherches dans une base mongoDB.

Une première introduction à la base NOSQL mongodb

J'ai mis en ligne une nouvelle vidéo consacrée à  mongodb.
Le site de mongodb est ici.



 Le support complet slides et vidéo est sur le site de partage slideshare

Mongodb introduction from eric german


MongoDB et Haddop sont deux compagnons.  Hadoop permet de stocker des volumes importants  et mongoDG s'occupe de la restitutions d'extraction de données venant d'hadoop.
Dans le sens inverse, mongodb peut utiliser la puissance des JVM pilotée par Hadoop pour réaliser des traitements par lots (ex Map-reduce).

MongoDB est une base NOSQL  de type document un peu comme couchDB. Son langage de commande est le Javascript.  Le projet se compose d'une série de programme dont 'mongod' : le serveur de la base et 'mongo' : un client sous la forme d'une console shell.

J'ai mis ici un exemple de script de lancement du service mongod pour ubuntu
 

Et ici le fichier de configuration:

Bientôt des vidéos et des articles sur la base NoSQL MongoDB

Voila plusieurs semaines que je bricole avec MongoDB l'étoile montante des bases NoSQL  (Not Only  SQL).

 Après avoir essayé: CouchDB , Redis , Riak , étudié Cassandra et Hadoop (voir les posts ou les vidéos)

(source : http://germanlinux.blogspot.fr/2012/12/la-carte-hadoop-pour-ne-pas-se-perdre.html )

Posts :

• Hadoop , mongoDB : http://germanlinux.blogspot.fr/2012/12/la-carte-hadoop-pour-ne-pas-se-perdre.html  (8/12/12)
• NoSQL : théorème de CAP :http://germanlinux.blogspot.fr/2012/01/hadoop-les-limites-des-nosql.html (9/01/12) 

C'est lors de la journée des utilisateurs Hadoop France en decembre 2012 que j'ai compris l'importance du rôle de MongoDB.

Il y a d'un coté le BigDATA:
Il   répond à un besoin de stocker un nombre vertigineux de données et surtout à offrir un cadre pour réaliser des traitements parallèles (map-reduce)

De l'autre  coté le mouvement NoSQL qui cherche à assouplir  l'architecture applicative et à simplifier les modèles de données. Le NoSQL souhaite aussi répondre au besoin de stockage de masse engendré par les réseaux sociaux. Ces informations ne sont pas toujours structurées . La disponibilité, le partage des données sont les objectifs principaux, le traitement parallèle est secondaire.

MongoDB fait le lien entre ces deux mondes.
 

Prochaine vidéo

A bientôt.

Le cloud: le juge de paix des architectures applicatives

Le cloud se veut une réponse  agile et souple à nos besoins en services informatiques.  Mais il se révèle aussi comme un élément structurant qui influence l'architecture des applications informatiques.

Prenons trois exemples:

Deux applications identiques

 Les applications A et B sont identiques en terme de fonctionnalité, du nombre d’utilisateur etc.
Pourtant chaque mois la facture du fournisseur du cloud sera pour l'application 'B' trois ou quatre fois plus chère que pour l'application 'A' : pourquoi ?.
L'utilisation du cloud n'est pas gratuite, le coût dépend de l'usage.  La réponse est simple: dans l'application 'A' la grande partie des traitements  est réalisée sur le poste client. La partie cloud ne sert qu'a délivrer une application complète qui ne fera appel au cloud que pour la récupération des données.
C'est l'utilisateur qui supporte une plus grande partie des coûts en utilisant la puissance de calcul de son poste.

Ce raisonnement est amplifié dans le cadre d'une entreprise qui utilise un cloud privé ou public: elle supporte un double coût: La partie cloud et la partie poste de travail. Cette dernière étant obligatoire: chaque employé est doté d'un poste de travail.

2eme exemple la scalabilité.

Le cloud est avant tout élastique. La puissance mise à la disposition doit pouvoir s'adapter (dans les deux sens) en fonction de la demande. Vous n’êtes pas face à un cloud s'il faut deux jours de délais pour obtenir une machine virtuelle supplémentaire. Au contraire , ces ajustements doivent pouvoir être administrés par des commandes à votre disposition.
Mais toutes les applications ne sont pas 'scalable' de la même manière. Si votre application utilise un serveur de session  (en base par exemple) l'ajout de serveur applicatif va se heurter à des problèmes de disponibilité des informations de session. Aussi, il est préférable que la session soit portée par le client afin de libérer la partie serveur d'une tache complexe et coûteuse.  Ce déport concerne   les traitements , le stockage coté client. Il est favorisé par l'utilisation d'architecture de type REST.
Sans état: Chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le client et le serveur.
https://fr.wikipedia.org/wiki/Representational_State_Transfer

3eme exemple: Les nouveaux terminaux: smartphone-tablette

Un des critères de qualité important pour une application pour les terminaux mobiles est la consommation électrique. Aussi , une application qui est obligée d'échanger en continu avec le serveur va  vider les batteries du terminal. Les applications voraces sont vite abandonnées par les utilisateurs. D'où l’émergence d'un type d'application qui embarque les traitements et une partie des données. L'application travaille de manière autonome et se synchronise de temps en temps avec votre cloud.
Ces application sont de type single-page application alias SPA en anglais
http://fr.wikipedia.org/wiki/Application_Web_Monopage

source :http://net.tutsplus.com/tutorials/javascript-ajax/important-considerations-when-building-single-page-web-apps/

En conclusion: toutes les applications ne sont pas taillées pour aller sur un cloud. Le choix d'une architecture applicative doit se conformer aux contraintes du cloud y compris dans sa logique de tarification: partager les coûts avec l'utilisateur en mutualisant la CPU et la mémoire.

Prochain épisode: dessine moi un cloud.

lazy evaluation avec ruby 2.0

Dans les nouveautés de Ruby 2.0 , une se distingue des autres : la lazy evaluation.
Cette fonctionnalité rapproche de plus en plus ruby du domaine des langages fonctionnels.

La présentation est disponible sur slideshare :

ruby 2.0 et lazy evaluation from eric german

Le code des exemples est le suivant:
La programmation fonctionnelle  favorise l'usage des générateurs ou des suites pour résoudre un certain type de probleme  (List comprehension - map/reduce) .

Avec le mode lazy , ruby est capable de retarder l'évaluation d'expression et mieux encore de le faire à la demande.

Le principal cas d'usage reste l'utilisation des streams (flux) appliquée à des besoins de diffusions de video ou de fichier sous la forme de chunk (tronçons). Ainsi Node.js dispose d'une api permettant de brancher des flux entres eux un peu à la façon de la commande 'pipe' sous unix.

Sortie dans les délais de Ruby version 2.0

Pour les 20 ans de la première version de Ruby, voici la version 2.0

Disponible ici.


Parmi les  nouveautés:

• Utilisation de paramètre nommé (clé - valeur) dans l'appel des méthodes.
• Prise en charge d'un vrai  mode 'lazy' dans les générateurs de séquence (enumerator) 
• Meilleur support de l'asynchronisme

Très bon travail de l'équipe de développement.

Retour vers le futur : les AGL

Je ne donne  plus qu'un seul cours aux futurs analystes: Les AGL.  Le déclin des  AGL restent pour moi un mystère comparable à la disparition 'brutale'  des dinosaures.
La présentation est ici :

Agl2012 from eric german

Les  années 80 - 90 : l'age d'or des AGL. 

Ils sont incontournables. Leur règne  repose sur l’omniprésence du COBOL dans l'informatique et de l'industrialisation basée sur la programmation structurée.  Sur 100 lignes de code COBOL , 20 lignes seulement contenaient la partie 'métier'  le reste étant des instructions destinées à insérer le programme dans son environnement.
Toute l'algorithmie  était exposée au sein du programme  sur un même listing.

La  programmation objet, l'avènement du langage JAVA, la généralisation des bases de données ont précipité le retrait des AGL.
L'utilisation du WEB comme support des applications métiers a achevé la mise au placard des AGL de cette génération. Ces architectures sont basées sur le design  MVC  : modèle-vue-controleur. Ce modèle impacte le traitement algorithmique des problèmes. L' intelligence des traitements est éparpillée dans les 4 coins de l'application et du framework. La devise  'diviser pour résoudre' de l'approche objet appliquée aux projets MVC aggrave encore plus cette dispersion.
Aussi les AGL classiques ont été mis au rebut en attendant la prochaine génération.

Le modèle économique.

Mais un des facteurs  moins connu, de la difficile percée des AGL,  est lié au modèle économique des sociétés de services  informatiques.Quand on veut augmenter la productivité d'un secteur, le choix peut se résumer à ceci :
Soit acheter des robot à des  fabriques  de robot pour augmenter la productivité: comme ceci:

Soit ajouter de la main d'oeuvre  sur des postes banalisés comme ceci:

Pour une société de service qu'est ce qui est le plus rentable, facile et  sûr  ? :  louer des prestataires.
Si le coût moyen d'un prestataire est de 1000 euro par jour, la SSII facturera 1000 X 20 jours = 20.000 euro par mois aux clients. Quel est le salaire du prestataire: prenons un jeune ingénieur à 3000 Euros par mois : la SSI va dépenser 3000 X 2 (les charges sociales) = 6000 euros.

Ce calcul est a rapprocher avec le coût d'un secteur recherche et développement capable de fabriquer un AGL qui s'adapte aux nouvelles technologies. Avec en plus un retour sur investissement très aléatoire.


Mais, on assiste actuellement au reveil des AGL avec deux approchent différentes.

Les AGL  basée sur la modélisation UML (exemple Blu age) .

 L'UML est maintenant mature, universel et maîtrisé. La toutefois la complexité demeure dans la maîtrise des design Pattern (modèle de conception) .
Dans les écoles d'ingénieur l'enseignement  de l'UML se fait en 10 jours: mais  l'UML ne remplace pas   la maîtrise des bases de l'algorithmie.

Ces AGL -UML  sont capablent de générer du code pour des cibles différentes (PC , tablette)etc .

Les AGL sous forme de DSL.

Les spécifications fonctionnelles.
Le facteur de réussite d'un projet repose en grande partie sur la qualité des spécifications fonctionnelles détaillées. Des DSL (langage de domaine métier ??)  permettent  à la Maîtrise d'ouvrage d'exprimer leurs règles de gestion avec les termes de leur métier. Des traducteurs automatiques vont transformer ces règles de gestion en langage informatique. Un exemple de cette méthode est le projet cucumber

La maîtrise d'ouvrage rédige ceci:

Le résultat sera sous la forme d'un test fonctionnel que le développeur devra résoudre.

Conclusion: les AGL sont de retour. Attention , ils ne sont pas des produits miracles. Le coût d'entrée est lourd avec le risque de se tromper de produit. Les AGL sont à utiliser avec des méthodes Agiles pour en tirer les meilleurs résultats et pour minimiser les risques.
C'est bon d’être vieux , le passé devient le futur .

Une astuce à connaitre pour utiliser le module d'upload formidable dans Express

Dans un post précédent, je présentai le module de téléchargement 'formidable' pour Node.js.
J'ai essayé d'utiliser ce module dans le framework Express.  Après quelques essais infructueux et des recherches sur le site stackoverflow, j'ai compris les raisons du dysfonctionnement: la juxtaposition de deux couches de traitement du formulaire d'upload.

La couche web d'express se présente comme ceci:

La ligne : express.bodyParser()  prend en charge la gestion des données du formulaire.

Aussi la syntaxe    form = new formidable.IncomingForm()  est redondante avec bodyParser.

Deux solutions  possibles:
Commenter la ligne express.bodyParser()  et utiliser new formidable.IncomingForm()   pour traiter le formulaire ou inversement , ne pas utiliser new formidable.IncomingForm() et traiter le formulaire avec les primitives d'Express.

Pour ma part je préfère utiliser les méthodes de Formidable car elles sont plus adaptées à la gestion d'un upload.

5 tendances pour 2013 #html5 #javascript

L"an dernier à la même époque , j'avais publié un post sur les 5 tendances à suivre pour l'année 2012.
Le post est ici 5 tendances pour 2012 #nodejs #html5 #javascript

Pour etre honnête dans ce type d’exercice , il convient avant tout de dresser un bilan.

Bilan 2012

En 2012 j’annonçais:

Tendance 1: De plus en plus de choses vont se faire en javascript coté client. HTML5 

je me mettrais la note de 18/20 sur ce premier item.

Tendance 2: amaigrissement des frameworks : 
Rails 4 n'est pas encore sorti. Django est sorti mais au cinema seulement.

note : 5/20

Tendance 3: Les entreprises vont continuer à investir dans les réseaux sociaux (Facebook pour ne pas le citer).

Note incontestable de 20/20

Tendance 4: Virage de Twitter

J'ai failli ne pas être bon sur ce coup là , mais en 2012 twitter a ajouter des tweet publicitaires et des nouvelles utilisations viennent compléter l'écosystème: exemple le jeu tweeria.com (lien vers mon personnage ici)

Note 12/20

Tendance 5: Les bases de données NoSQL

Là , il n'y a pas photo : note 15/20

Pour 2013 ....  

les 5 tendances à suivre sont ...........

Tendance 1 : encore plus de javascript, node.js . Avec une librairie qui commence a se détacher du lot
Backbone.js. Ce module permet d'ordonner son code javascript.

Tendance 2 : La valorisation des données (restitutions graphiques). Elles se font naturellement sur le client. La librairie qui revient le plus souvent dans les conversations: d3.js . Mais il ne faut pas oublier raphaeljs. Et pourquoi pas nvd3.js pour faire la synthèse des deux ?

Tendance 3: Les DSL creusent leur lit dans le sillon de javascript et CSS avec Coffeescript, LESS etc.
Un autre langage à suivre : LUA.  Ainsi le développeur doit devenir polyglotte.

Tendance 4: Le bigData avec le Nosql et l'opendata.   Dans ce domaine, un trio se distingue: Hadoop , mongoDB et D3.js pour la restitution.

Tendance 5:  des versions majeures pour Ruby (version 2.0) , Rails (version 4) et .. java 1.8 avec un gros défi pour java : démontrer qu'il est capable de s'adapter à l'elastic  cloud.

Car 2013 sera surtout  l'année du cloud facile....  (post à suivre)

A suivre cette année et RDV pour un bilan en 2014.



 

Un jeu de carte original

Un nouveau jeu de carte commence à connaitre un certain succès : Cards against Humanity.

Le principe du jeu est très simple: Les cartes noires sont les questions, les blanches les réponses.
Le but du jeu est de proposer les réponses les plus drôles  C'est le principe des 'cadavres exquis' adapté pour des cartes.

Exemples de questions: (cartes noires)

Il faut compléter les 'blancs' par les réponses tirées des cartes blanches.

Un kit du jeu  en francais est disponible ici.

A vous d'imprimer les cartes et de commencer une partie 'caustique'