mardi 29 juin 2010

Ecriture d'un module pour le serveur #http #nginx

redstar2
J'ai développé un petit module de test pour le fameux serveur HTTP NGINX.

Ce module ne sert qu'a jouer avec la configuration et les librairies du serveur,
d'où son nom : nginxsandbox.

Le code C du module est disponible dans lemon-labs de github.

J'ai aussi écrit un shell permettant d'automatiser la compilation et le test d'un module Nginx : monmake.sh

make clean
./configure --with-debug --with-http_stub_status_module --add-module=/usr/local/nginxsandbox/
make
make install
cp /root/nginx.conf /usr/local/nginx/conf/
kill `cat /usr/local/nginx/logs/nginx.pid`
sleep 3
/usr/local/nginx/sbin/nginx > /usr/local/nginx/logs/error.log




Ce script est à installé dans le répertoire des sources du serveur.

Il suffit ensuite de créer un répertoire abritant votre module en dehors de cette arborescence.

Le script commence par faire le ménage dans le répertoire de compilation, puis lance le programme de configuration avec les bonnes options. Pour ma part,j'ai donc ajouté le module nginx status et le mien.
Après le make install, je recopie une sauvegarde de mon fichier de conf dans le répertoire de conf du daemon nginx.

Enfin, je coupe le serveur et je le relance.

Faire pointe pointer le browser sur localhost/sandbox doit donner :
(clic pour agrandir)



Le fichier de conf est modifié de la sorte :


location /nginx_sandbox {
sandbox on;
}





La lecture du "guide d'emiller" est le point de départ à l'écriture d'un module.
Ainsi paré de la ceinture de Batman, l'aventure peut commencer.

lundi 28 juin 2010

Mieux qu'un chien : un AT-AT

C'est la grosse agitation chez les geeks , encore un jeu pour les grands : une nouvelle réplique des machines de guerre AT-AT entièrement articulée.
AT-AT = All Terrain Armored Transport





Il tire des missiles, la cabine peut accueillir deux conducteurs. Les flancs s'ouvrent




source des photos : http://www.toplessrobot.com


Ici un film réalisé avec un de ces robots:






Cliquez sur l'image et préparez 110 $.

samedi 26 juin 2010

Vidéo humoristique sur Java avec "scala" Johanson

Une petite vidéo sympathique sur java, l'opensource et .NET

Pour certains la morale de cette vidéo se résume en :
beware of girls who talk about programming stuff like C++, Lisp, and Java. they take away your virginity.


Lien complet sur reddit.com


mercredi 16 juin 2010

RDBMS vs noSQL , CAP théorème


Linux journal du mois de juillet (195) propose un article sur le mouvement NoSQL. Cet article est un peu partial en faveur des RDBMS (Relational Database Management System) .

En revanche il reprend les notions de base:

Norme ACID :
  • Atomicity : la transaction se termine complètement avec succès ou on revient à l'état initial
  • Consistency: La base est un dans état stable avant et après la transaction
  • Isolation: Une transaction est indépendante d'une autre. Une file d'attente doit gérer les conflits.
  • Durability: Une fois que la transaction est terminée avec succès, les changements dans la base seront acquis un fois pour toute.


Cette norme est un principe fort de fonctionnement des bases de données.


Théorème de CAP ou de Brewer (eric)

  • Consistency : (diffère du la notion éponyme dans ACID) , Quel que soit le moment de l'écriture d'une donnée, la lecture de cette donnée retournera la dernière version.
Une 'éventuelle consistance' signifie que l'on accepte une différence de version de la donnée.
  • Availability: On peut toujours attendre qu'une base de données réponde à une requête . cette disponibilité peut être réalisée par plusieurs serveurs émulant une seule instance.

  • Partition :(partition tolerance) La base de donnée est accessible en lecture ou en écriture même un des noeuds est inaccessible. Lorsque le service reviens à la normale le noeud est mis à niveau.


Ce théorème démontré par Gilbert et Lynch du MIT en 2002 , montre qu'il est impossible pour un système de données partagées de garantir les trois propriétés simultanément.

Un RDBMS privilégie une consistance forte et une disponibilité assurée par une instance miroir.
Un système NoSQL se contentera d'une 'éventuelle consistance' au regard du flux important d'information (exemple :twitter)

Les systèmes NoSQL sont souvent basés sur des magasins de clés-valeurs. Le langage associé est de plus en plus, le Javascript . On peut noter l'existence d'un projet original 'Friendly' qui permet de faire du NoSQL sur MySQL. Une table est créée par champs : si une table normale possède 5 champs, elle sera éclatée en 5 tables (je simplifie) . Cela permet d'avoir une base de données sans contrainte de schémas.
Les NoSQL sont qualifiés de 'post-moderne' : au lieu de vous donner une réponse 'juste' ils vous donnent la meilleure réponse possible.






mardi 15 juin 2010

Le chaos sur twitter


Aujourd'hui , twitter est dans le chaos le plus complet. Une maintenance hier sur leur site à provoqué la panique dans leur application. Les compteurs de tweet sont à zéro , mes tweets se sont évaporés.
L'envoi d'un tweet ne fonctionne plus et le client chrome-twitter m'a généré 120 tweets identiques.

La résolution du problème est à suivre ici : http://status.twitter.com/

Les explications des techniciens sont ici : http://engineering.twitter.com/

Ils appellent ca : une tempête de baleines !

L'augmentation du trafic en raison de la coupe du monde de football serait à l'origine du problème. Pour ma part , je crois que Twitter a voulu faire le ménage parmi les robots et les compteurs vont réellement être remis à zéro.

jeudi 3 juin 2010

Architecture java contre framework légers

Quand on voit la pile complète d'une application Java standard hébergée par un framework MVC, on peut à juste titre être tenté de qualifier ce montage d'usine à gaz ou encore mieux de Rube Goldberg machine.


(Détails )




Or il n'en est rien de tout ca. Chaque couche a sa justification. Un spécialiste JEE arriverait facilement à faire la démonstration du bien fondé de cet échafaudage : ET IL AURAIT RAISON. Le langage JAVA n'est pas pire qu'un autre : il reprend les lignes directrices du C++ à son compte.
Java et JEE mettent en pratique chacun à leur façon cette formule: diviser pour résoudre.
En java: diviser en objet pour résoudre le problème.
En JEE: diviser en couche pour assurer l'indépendance des parties clientes, web métier et données.
Avec un système comme ca, tout le monde trouve son compte:

Les vendeurs de serveur : ce n'est pas pour rien si c'est un fabriquant de serveur qui à eu l'idée de promouvoir ce modèle.

Les sociétés de service : une tel architecture justifie des ressources en nombre, des experts par couche. Cest aussi la certitude de trouver des developpeurs et de banaliser les ressources.

Les informaticiens: une filière reconnue, normée favorise la fluidité du marché du travail dans ce domaine. C'est un confort , une assurance pour un bon déroulement de carrière.

Les DSI: ils ont le sentiment de faire des choix 'raisonnables' , d'investir dans des techniques sures,pérennes et évolutives. Une filière technologique unique , étoffée par un ecosystème fort et couvrant tout le cycle de vie du logiciel.

Avec une telle armada, java aurait du être hégémonique vis à vis des autres langages.
Il n'y a rien de mieux que JEE pour réaliser de manière industrielle des applications métiers traditionnelles.

Alors pourquoi aller contre cette évidence ?.

Le principal reproche à l'ensemble Java/JEE est le coût global d'un projet. Une application est forcement 'lourde' en terme de ressources machines et humaines.

Les développeurs JAVA.

Dans la réalité les développeurs Java ne sont pas aussi interchangeables et banalisés que çà. Le cycle de formation d'un développeur Java est au moins deux fois plus long que celui d'une autre filière (6 mois PHP , 1 an pour le Cobol 2 ans pour le Java/JEE). Avec une remise à niveau tous les 3 ans. La tentation est alors grande de rogner sur le cursus de formation.
Un poste d'architecte applicatif est nécessaire avec un découpage en couche complexifié par le morcellement de l'approche objet. Or les personnes capables de maitriser toute la pile du système et l'architecture globale d'un projet sont très rares et donc chères .
Un investissement dans une équipe complète de développement Java/JEE ne se justifie vraiment que pour des industriels du logiciel. Quel est votre métier: fabriquer du logiciel ou fabriquer des voitures , vendre des aspirateurs ? .

Les applicatifs à produire.

Les applicatifs issus de cette filière se prête mal aux nouvelles contraintes :
Temps de réalisation court pour éviter l'effet tunnel.
Dans l'industrie automobile le temps entre la prise de décision de lancer un nouveau modèle et la sortie du véhicule des chaines doit être le plus court possible. Dans un projet informatique, cette contrainte est identique.
Les 'clients' élaborent des spécifications qui vont fixer les besoins à un instant donné. Hélas, ces besoins évoluent, les donneurs d'ordre vont avoir tendance à anticiper cette évolutions dans l'expression de leurs besoins . Seule une approche itérative avec un cycle court et une mise ne production rapide par 'morceaux' est capable de répondre correctement à ces besoins.

Explosion du volume de données.

L'idée de traiter massivement ses données par un seul serveur est obsolète. La parallélisation est devenue une nécessité. Dans ce mode de traitement, la communication inter-processus , le style de programmation et le traitement des erreurs sont stratégiques. Or Java n'est le langage le mieux adapté pour cela. Plutôt que de faire évoluer Java, les experts préfèrent redessiner un langage à partir de java et de sa très bonne JVM : le SCALA (utilisé par twitter) .

Passage au web 2.0


Pour l'avenir, les développeurs Java......script seront des ressources demandées. Avec javascript, les applications métiers en web surclassent les applications lourdes. Jquery, prototype ou script.aculo.us sont des librairies qu'il faut connaitre. Javascript, et un framework léger (Rails , symphony etc ) sont largement suffisants pour répondre aux besoins de nos utilisateurs.

Un jeune doit il se former à java ou basculer directement vers d'autres technologies ? . La bonne stratégie est de sortir des sentiers battus et de ne pas faire comme tout le monde. Pour une raison bien simple , il sera confronté un jour ou l'autre au java et sa culture alternative sera un plus. d'autant que l'approche MVC par un framework léger permet par la suite d'appréhender plus facilement des architectures complexes.

Demain il y aura trop de developpeurs Java, dans des pays divers et à des prix cassés. en revanche , les architecte-maquetteurs ( développement Agile) seront les rois du marché.

mardi 1 juin 2010

CSS et ascii art

Le WEB et ses technologies sont non seulement des vecteurs pour promouvoir l'art mais ils sont aussi de la matière première pour confectionner des créations artistiques.

On connaissait l'ascii ART:



Il existe maintenant le CSS ART :

Si on clique sur ce lien, le texte suivant va apparaitre:



Si on tape la combinaison 'ctrl A' qui correspont à la selection de tout le document , l'image suivante va s'afficher:




Les caractères originaux sont visibles dans les zones sombres (trait rouge)

Cliquez sur l'image pour revenir au texte.


Une selection partielle donne :


Un examen du source de la page dévoile la technique utilisée:
La feuille de style fixe les couleurs de fond à utiliser dans le cadre d'une sélection.