lundi 30 janvier 2012

Votre age selon #google

En allant sur cette page google : https://www.google.com/settings/ads/onweb/ ,  google affichera vos centres d'interet, votre sexe et votre age. Il déduit ces informations en fonction de vos recherches et de votre navigation.

Résultat :Google ne se trompe jamais.


jeudi 26 janvier 2012

Etes vous pret pour le futur du web : #SPDY ou #websocket ?

Les concepteurs du web étaient loin d'imaginer qu'un simple système de partage de document allait devenir le support des applications métiers.

Le protocole HTTP sur TCP est arrivé en bout de course, il fallait trouver quelque de plus rapide.
Il existe deux techniques : les websockets et le protocole SPDY mis en avant par google.





Le protocole SPDY propose de multiplexer les requetes sur la même connexion TCP, de compresser les entetes , le tout sur le protocole sécurisé SSL.
Autre point important : l'initiative des  requetes est bi-directionnelle: Le serveur peut avertir le client qu'il va lui envoyer des informations sur un canal.

Le site suivant : https://spdy-twitlog.indutny.com/  permet de tester la compatibilité de votre navigateur à ces nouvelles technologies. Il est écrit en javaScript et tourne sur Node.js.


Avec un navigateur compatible :


Avec un navigateur non compatible:


samedi 21 janvier 2012

Nouvelle version 3.2 de #rails

La version 3.2 de ruby on Rails est arrivée.

Les principales  nouveautés sont les suivantes:

  • Nouveau système de cache du code ruby de l'application. Le framework détecte si un fichier source à changé et dans l'affirmative recharge le code.  
  • Une extension pour examiner les requêtes SQL (mode explain)  
  • Un nouveau système de log.
  • La documentation dans le format EPUB, kindle etc

Et encore plein de bonnes choses




L'installation est toujours aussi simple :
rvm gem install rails

(5 minutes après)

rails new myAppl

puis
cd myApp
rails server

Et par magie dans le navigateur : localhost:3000



samedi 14 janvier 2012

Du code bien expliqué avec docco.coffee #javascript

Pour expliquer le contenu d'un programme, il n'y rien de mieux que les annotations en marge du listing.  Cette opération est maintenant automatique avec l'utilitaire docco.coffee. Il fonctionne  avec node.js, il utilise la librairie python 'pygments'.


Il fonctionne très simplement:  docco *js ou docco *coffee ,  va créer un répertoire 'docs' qui contiendra une page HTML.

Tout ca donne vraiment envie d'écrire de la doc.




vendredi 13 janvier 2012

Comment PHP a sauvé le #web de #Free mobile





A l'annonce des offre Free , des centaines de milliers d'internaute se sont rués sur le site web de mobile.free.
Celui-ci s'est très vite trouvé saturé et en rupture de charge. Les petits curieux qui analysent les pages web et qui s'intéressent aux architectures web  avaient remarqué que les pages étaient délivrées par un framework JAVA/J2E  (présence des cookies avec des sessions typiques) . Lorsque le site a été de nouveau opérationnel, les cookies par magie relevaient du architecture PHP.
Un des moyens mis en oeuvre par les équipes Free pour augmenter les capacités d'accueil du site (scalabilité) à donc été de remplacer des parties entières de JAVA/J2E par du PHP.

Relevé sur les forums:


Cependant, nous avons pu remarquer encore quelques dysfonctionnement dans le processus d’inscription, et pour cause… Le site a semble t’il été entièrement réécrit dans la nuit !
Ce tour de force rendu semble t’il indispensable par l’incapacité à relever l’ancienne plateforme tournant sous Java, et qui désormais est en PHP.


 ----------------------------------------------------------------------------------------------------------
 (fin de citation)

Une application PHP sera nativement plus performante qu'une application JAVA/J2E pour les raisons suivantes:


  • Le serveur applicatif Apache (langage C) qui sert les pages PHP est plus fiable et puissant que n'importe quel Tomcat. La 'scalabilité' est plus facile à réaliser avec Apache/PHP qu'avec JAVA/J2E. Il est recommandé de placer un apache devant un ou plusieurs  tomcat pour cela (voir aussi le sujet des ressources non java:js,css) .
  • Une architecture PHP like est plus simple et coute moins cher.
  • Une application PHP utilise aussi la programmation objet mais sans ses dérives : des soit-disant experts on convaincu les crédules : la programmation objet doit forcement se traduire en plusieurs couches.  (voir des articles sur la notion de  principes SOLID)
  •  Les développeurs sont meilleurs en PHP

Avant les programmeurs PHP étaient considérés comme des amateurs. Maintenant la tendance s'inverse: Les meilleurs programmeurs se trouvent dans les communautés PHP, Ruby , Python , javascript et les C like.
 Peut importe le langage , l'essenciel est l'algorithmie.
Les entreprises pragmatiques preferent  utilser l'algorithmie  plutot que des dollars pour augmener les performances de leur site.
 Les plus gros sites WEB (facebook, twitter ) ont bien compris cette démarche.

Alors si au détour d'une réunion vous entendez quelqu'un qui explique doctement "que les applications JAVA/J2E sont plus robustes et plus scalables que les autres." , ne cherchez pas à argumenter, vous risquez de l'instruire.

Au commencement était le verbe ...  mais à la fin il y a toujours un developpeur qui se tape le boulot et qui sait ce qui est bon.


Pour le reste, Le grand architecte divin reconnaitra les siens.













mercredi 11 janvier 2012

Outils pour auditer des pages web #chrome, #firebug

Il existe des outils très pratiques pour savoir si un  site web est optimisé ou non.
Les deux navigateurs chrome et firefox proposent chacun leur extension.
Pour chrome.
Chrome est livré nativement avec l'outil devtools. (lien ici ) qui s'active par la touche de fonction F12


En plus des fonction d'inspection standard , il propose de réaliser des audits de page.
 Cet ensemble peut etre complété par l'extension Page Speed.

 Un exemple ici d'utilisation :



Firefox ne propose rien d'origine, il  cnvient d'ajouter deux extensions

La plus connue 'firebug'  qui correspond à l'outil de chrome (devtools)

et une autre extension 'yslow'  (trousse à outil yahoo)

Un exemple de sortie avec yslow:

Maintenant vous n'avez plus d'excuse pour ne pas faire des sites rapides.


mardi 10 janvier 2012

#node.js + #jQuery : mettre un tigre dans votre #node.js

Il arrive souvent aux admin de faire des programmes qui récupèrent des pages HTML pour différentes bonnes raisons:

  • Vérifier des liens 
  • Extraire des informations d'une page


 Ces traitements de parsing sont toujours un peu délicats et très dépendants de la page à traiter.
 Ces opérations se font à coup d'expression régulière avec des contorsions pour traiter les balises ouvrantes et fermantes.
 Avec jsdom il est maintenant possible d'utiliser la puissance de jquery coté serveur.
La puissante de la meilleure librairie javascript cliente sur un serveur node.js
Ci dessous quelques exemples: jQuery peut etre lu à partir d'un fichier local, ou téléchargé. Pour le premier exemple la page html à traiter est lue en local , dans l'exemple suivant la page est récupérée à distance.

Tous les sélecteurs jQuery sont utilisables.


JSDOM vous permettra aussi de créer des nouveaux documents, enfin   il  peut servir comme modificateur de code HTML au sein d'un reverse_proxy.


Les exemples complets sont sur lemon-labs.

lundi 9 janvier 2012

#Hadoop, les limites des #nosql


Le système complet de la famille de stockage NOSQL , HADOOP vient de sortir en version 1.0
Le phénomène NOSQL commence à diffuser au sein des directions informatiques grandes ou petites.
Le sujet des bases nosql soulève deux questions:
Quels sont les cas d'utilisation à retenir ?
 Sur le site http://www.saama.com  une infographie  propose une réponse à cette question.

Le nombre de cas d'utilisation est reduit et les risques d'erreur important.
Les applications métier de gestion sont à écarter, surtout si elles reposent sur un bon vieux framework MVC J2E.
A mon sens l'utilisation d'une base NoSQL se justifie pour des usages :

  • très simples. 

Exemple: l'application ne sert qu'a afficher ou a manipuler quelques table sans valeur ajoutée. Les tables seront regoupées dans une seule entité d'une base NOSQL avec de la denormalisation et de la redondance assumée.

  • Des architectures d'infrastructure  avec des fortes contraintes de volume  ou de disponibilité : Un serveur de session, un gestionnaire de message par l'exemple  
  • Des applications qui mettent en oeuvre des opérations d'indexation ou de comptage. C'est ici qu'intervient le map/reduce mis en avant  par google. 

En conclusion: Le Nosql est en passe de devenir le nouveau truc à vendre par les SSII. Il y très peu de projets candidats.  

Vous avez envie de vous lancer dans l'aventure. 

La tentation est forte de commencer par hadoop: Ce projet a 6 ans d'age, labélisé par La fondation Apache.
 Hadoop se présente  comme un assemblage de plusieurs sous-projet avec à la base  un système de fichier HDFS et HBASE pour le stockage. Avec hadoop les données et les fichiers sont distribués sur plusieurs serveurs. Les opérations de map-reduce se passent sur chaque fragment eléméntaire de données.

Aussi, je vous conseille de commencer avec des produits NOSQL plus modestes comme Riak ou mongodb.
Leur spectre d'utilisation est plus grand que celui d'hadoop.
Avec les produits NOSQL il faudra souvent passer par du javascript (meme pour hadoop) qui s'impose comme le langage 'utilitaire' de ces nouvelles bases.




Les bases NOSQL vont aussi se retrouver au niveau du client,  cette  adoption est favorisée par l'adoption du HTML5 et de la décentralisation des traitements. Votre poste de travail mobile va extraire les informations geo-localisées depuis une base de données centrale. Puis votre terminal travaille sur les données locales pour une re-synchronisation future.

Mais attention.

Pouvoir stocker plus de données c'est bien, mais pour en faire quoi ? Une entreprise ne sait se servir que de moins de 5% de ses données. La donnée doit etre structurée, indexée et tracée  et non pas déversée en vrac dans un entrepot ou une base de données sinon elle sera perdue.
En 2020 , l'écart entre le volume d'information et la capacité de stockage va se creuser : en clair il faudra compresser la donnée et ne sélectionner que l'information pertinente.
Aussi de la même facon qu'il y a des DSI , il y aura de Data manager assurant la gouvernance des données au sein des SI. Après l'urbanisation des SI , c'est le tour des données.



dimanche 1 janvier 2012

Qui a peur de #node.js , #javascript ?

Le projet node.js est un recent et provoque pas mal de bruit sur le Net.
Le sommet de la polémique a été atteint par cet article: node.js est il un cancer  ?.
La discussion a continué sur reddit.com  avec des échanges vifs. Pourquoi un tel déchaînement de passion.

Pour rappel : qu'est ce que node.js.

Node.js est l'habillage du moteur d'exécution du javascript utilisé par Chrome. Ce moteur s'appelle V8. Il est en C et en javascript. Chrome s'en sert pour exécuter le javascript coté client. Ryan Dahl et ses amis lui ont  ajouté quelques librairies afin d'obtenir un produit autonome node.js. C'est une machine virtuelle comme la JVM sur laquelle vient s’exécuter du javascript. Un des créateurs du V8 était aussi concepteur de la JVM.
Les principes de node.js sont simples :

  • La  gestion dans  boucle sans fin des évènements
  • Une facilité de mise en oeuvre  de  programmation asynchrone
  • Un seul processus , pas de multi-thread 





Est il dangereux d'installer node.js sur un serveur. 
La réponse est NON.

Le coeur de node.js , le moteur V8 est déjà présent coté client. Les failles de sécurités sont rapidement corrigées.
Par comparaison il est plus risqué d'installer sur un serveur les services suivants :
- Un serveur apache
- Un serveur Tomcat (les failles des JVM sont les plus dangereuses)
- Un webmin , un serveur telnet ou FTP

Alors pour pourquoi tant de réticence ? 

En premier lieu, le langage javascript. Tous les admin UNIX (moi le premier) ont au cours de leur carrière utilisé ou côtoyé du javascript pourri, récupéré par copier/coller sur un site de bidouilleur.
Les vrais développeurs javascript sont rares. Ce langage est souvent utilisé comme quelque chose de deuxième zone. Ce phénomène s'inverse et le javascript est maintenant à l'honneur.
L’hégémonie de la partie client.  
Le MVC serveur était jusqu’à présent le composant principal d'une application. Il était rentable d'investir dans l'ingénierie de ces composants. Hélas, les smartphones , les tablettes, le cout du SI  et tout simplement le bon sens sont venues perturber ce bel équilibre. Le MVC passe de l'autre coté.
L'effort du  développement porte sur le coté client. C'est tout simplement  cette partie qui offre le plus de rentabilité (ROI).  Non seulement le javascript est le seul langage universel coté navigateur (client) mais en plus maintenant il cherche à envahir les serveurs. On pourrait avoir un seul langage de bout en bout (serveur _ client).

La puissance que procure node.js

Il est possible en dix lignes de javascript d’écrire un programme qui embarque les couches réseaux d'un serveur web, la gestion de la délivrance du contenu et la configuration du serveur. Node.js reproduit même le système des 'pipes' des commandes unix : on va lire un fichier et brancher sa sortie sur le flux de réponse du client. Tout ceci est possible parce node.js transgresse un 'dogme'  UNIX : l'organisation en couche. Ryan Dahl veut faire de l'informatique simple et bon marché. Idem pour  la programmation objet qui  a été détournée de son objectif. Faire de l'objet revient à faire des couches. Et comme dans la vie courante , chacun essaye de refiler sa m.... à une autre couche. Voila pourquoi des choses comme node.js , jquery ,javascript , coffeescript et Rails font peur: ils sont simples, puissants  et ne coûtent pas cher. Les apparatchiks sont inquiets.. pour leur mur de berlin