28fév

Filed in Non classé Leave a comment

Ça fait un bail que je n’ai pas posté, je profite de l’écriture d’un mémo interne pour me permettre de le copier-coller ici ;)

Comme ces derniers temps j’ai écrit pas mal de scripts de maintenance Bash, je souhaite partager avec vous mes connaissances sur la gestion des process avec le shell (ce qui est quand-même la principale raison pour laquelle on écrirait du shell, outre la portabilité):

Exécution

$command lance la commande et attend son retour
$command & lance la commande en arrière plan
wait attend la fin de tous les process en arrière plan du process courant (code de retour = 0)
wait $PID attend la fin du process caractérisé par ce PID (code de retour = code de retour du process attendu, s’il y en a plusieurs c’est le dernier)

Signaux

kill -0 $PID échoue si aucun process avec ce PID n’existe
trap $command $signal intercepter le signal et exécuter la command indiquée (idéal pour affecter des commandes de nettoyage en post-execute),
exemple: trap 'echo fin' EXIT INT TERM

Variables spéciales

$$ le PID du process courant
$! le PID du dernier process lancé en arrière plan
$? le code de retour de la dernière commande terminée (dans un trap ça peut être le code de retour du process en cours, très utile)

Redirections

$command 1> $file redirige l’output standard vers un fichier
$command 2> $file redirige l’output erreur vers un fichier
$command 1>&2 tout rediriger vers l’output erreur
$command 2>&1 tout rediriger vers l’output standard
$command &> $file tout rediriger vers un fichier
exec &> $file toutes les commandes exécutées après cet appel verront leurs sorties redirigées vers un fichier (exec est en fait bien plus puissant que ça)

Exemple bidon

#!/bin/bash
(sleep 2 && echo 1 && exit 1) &
PID1=$!
(sleep 4 && echo 2 && exit 2) &
PID2=$!
trap "echo Nettoyage... && kill -9 $PID1 $PID2" INT TERM
trap "echo Terminé (code $?)!" EXIT INT TERM
wait $PID1 $PID2
echo code de retour du sleep: $?

N’hésitez pas à partager vos protips de gros barbu en commentaire \o/

13oct

Filed in formation | Git | Javascript 8 Comments

Je vais vous parler aujourd’hui des formations données par Christophe Porteneuve: Git Attitude et JS Attitude.

Avant d’aller plus loin, je tiens à préciser que ce n’est pas un article sponsorisé. Je sais que quand les bloggeurs publient un article sur un sujet potentiellement mercantile, le doute subsiste toujours. Promis, ce n’est pas le cas. Par contre j’ai un intérêt dans l’affaire: Ma société (Clever Age) héberge l’évènemet et a droit à des places gratuites, dont j’ai pu bénéficier cette année. Or il n’y a actuellement pas assez d’inscrits à cette formation que je souhaite (vraiment, mais genre vraiment hein) suivre, et elle risque d’être annulée faute d’inscrits :( donc je vous encourage fortement à vous inscrire :)

JS Attitude & Git Attitude

Concrètement, le monsieur va vous parler – à grands coups de discours très animés, de démos qui font briller les yeux, et de TP qui font saigner les doigts – de JavaScript ou de Git. À chaque fois sous deux déclinaisons: vachement balaise (Git au quotidien, et JS puissant), ou encore plus balaise pour roxer à mort (Git avancé, et JS Guru).

Les prochaines formations pour 2011 sont les suivantes:

Le truc pas cool c’est que c’est toujours un samedi. C’est une nécessité pour l’animateur. En revanche, ça veut aussi dire que quand vous allez négocier avec votre boss pour votre DIF, quand vous allez lui dire « hé, je voudrais écouler mon DIF pour devenir meilleur dans mon travail, et en plus sans rater un jour de boulot » je pense que vous allez vraiment marquer des points :)

Les trucs cool en revanche, c’est que l’atelier est vraiment intéressant, que c’est l’une des formations avancées les moins chères du marché (300€ pour Git au quotidien, 450€ pour JS Guru). Christophe est très transparent sur les tarifs et si ça reste évidemment très cher pour une bourse moyenne personnelle, n’hésitez pas à vous renseigner auprès de votre boite pour le DIF ou le crédit d’impôt au titre de la formation, contrairement à ce que disent certains il est de la responsabilité de votre société de vous aider à monter en compétences !

Focus sur JS Guru

Le programme est ici : JS Guru sur le site JS Attitude.

On va y parler d’amélioration progressive, d’HTML5, de JSON & JSON-P, de MVC côté client avec Backbone et Mustache, des nouvelles API comme le local storage, le local db, l’history, l’appcache, etc… Avec des ateliers vraiment pratiques, vraiment funs (là je ne fais que retranscrire les retours de mes collègues ayant eu la chance d’y participer).

 

Bref, aidez-moi à avoir droit à ma formation, rejoignez les rangs des vrais roxors du JS → Go go go inscription pour le 10 décembre à Lyon !

27août

Filed in Express | NodeJS | Redis | REST 4 Comments

Dans la première partie, nous avions écrit (en mode TDD un peu raccourci) un service REST. On est quand-même allés au bout, mais ça restait améliorable.

Dans cette seconde partie nous allons jouer avec les middlewares Express pour factoriser, ajouter diverses vérifications sur les données, etc… Afin de ne pas imposer de pavés trop lourd, je garderai finalement pour un 3e article l’intégration du support de nouveaux formats, et l’écriture d’une doc agréable à utiliser.

Sommaire

Continue Reading

, , , , , , , ,

25août

Filed in Express | NodeJS | Redis | REST 6 Comments

Une fois n’est pas coutume, je découperai ce tutorial en plusieurs articles distincts, histoire de voir si j’arrive à écrire des articles plus courts ;)

Nous allons voir en détail comment mettre en place un webservice RESTful avec NodeJS et le framework Express. L’objet de ce webservice sera la gestion d’une base de favoris.

Sommaire

MÀJ Oups, j’avais oublié la partie pour réellement jouer avec notre service ^^

Continue Reading

, , , , , , ,

28juil

Filed in Javascript | NodeJS | websocket 14 Comments

La première fois qu’on utilise les websockets, on se dit que c’est compliqué (pas tant que ça en fait). Puis on utilise socket.io, et on se dit que c’est vraiment super simple :) Et puis un jour on aimerait bien sécuriser la connexion au socket, parce que la partie « temps réel » nécessite d’être authentifié, ou simplement parce qu’il faut un pré-requis (comme avoir donné son nom avant de pouvoir chatter) avant que l’écoute ne démarre réellement.

La première idée qu’on a est de se trimballer des flags et d’activer/désactiver l’écoute de certains messages en fonction de ces flags (par exemple: tant que l’utilisateur n’a pas donné son nom, les évènements « message envoyé » sont ignorés). Le problème est que la connexion est pourtant déjà ouverte, des données y transitent déjà, et c’est donc vraiment très loin d’être idéal. De manière plus générale, il semble très complexe de communiquer avec la session utilisateur au sein du websocket. En effet on a un code de ce genre, où l’on voit bien qu’il semble impossible de manipuler la session utilisateur dans le cadre d’un websocket vu qu’il n’y a aucune notion de « request »:

sockets.on('connection', function (socket) {
  // But...
  socket.on('msg', function (data) {
    // ... where the fuck is my session?
  });
});

On va voir que le protocole est bien fait et que la connexion se fait au sein d’une enveloppe HTTP standard, et qu’on a donc accès à tous les headers d’une requête HTTP, notamment les cookies, permettant de récupérer par exemple un ID de session, et donc de lire/modifier la session utilisateur depuis le websocket!

Sommaire:

  1. Gestion des sessions avec Express
  2. Sécuriser une page
  3. Utilisation de Socket.IO
  4. Manipulation de la session utilisateur depuis un WebSocket, et sécurisation de la connexion
  5. Gestion des connexions mutiples
  6. Aller plus loin…

Note: si vous connaissez déjà bien Express et Socket.IO, vous êtes encouragé à sauter directement au chapitre 4 (éventuellement, le chapitre 2 peut rester intéressant). Le reste ne vous apprendra rien.

Retrouvez le code complet des exemples sur GitHub.

03juin

Filed in Javascript | NodeJS 6 Comments

On dit souvent que les méthodes asynchrones apportent à Node.JS un avantage dans sa gestion des accès concurrents. On dit que pour une opération aussi coûteuse que de la lecture sur le disque par exemple, il saura gérer plus de connexions, et dans l’ensemble répondre plus vite si cette opération est faite en utilisant l’API asynchrone plutôt que l’API synchrone.

OK. Soit. En ce qui me concerne je n’ai pas le niveau technique pour comprendre les tenants et les aboutissants de tout ça, donc comment m’en convaincre? Et bien, benchmarkons :)

Partons d’un serveur HTTP très simple: il n’a qu’une page, qui affiche « coucou gamin » dès que le serveur a fini de lire un fichier local de quelques méga-octets.

Dans la suite de l’article je vais vous proposer 3 implémentations de ce serveur, et les résultats d’un test par Apache Bench.

Continue Reading

, , , ,

03juin

Filed in Javascript | NodeJS 10 Comments

Comme on l’a déjà vu, en Javascript, et principalement avec Node.JS, les appels à des méthodes non bloquantes exécutant leur traitement de manière asynchrone permet de faire du multi-tâche de manière très simple et performante. Néanmoins, un piège dans lequel on tombe rapidement est la cascade d’appels asynchrones.

On va prendre deux exemples, et voir comment les rendres plus lisibles dans la suite de cet article :)

Continue Reading

, , ,

01juin

Filed in Express | Javascript | NodeJS 6 Comments

Je me rends compte que dans ce blog je vous parle de Node.JS et d’Express, sans vous avoir jamais présenté ces technologies. Allez, revenons vite fait aux bases :)

Installation

Pour l’installation, je vous renvoie au site officiel, ou à un article en français par Atinux, mais globalement l’installation se résume à ces 3 lignes:

git clone https://github.com/ry/node.git
cd node
./configure && make && sudo make install

Présentation de Node.JS

Node.JS est un projet open-source se basant sur le moteur « V8″ de Chrome (il existe un fork « SpiderNode » par Mozilla, basé sur leur moteur SpiderMonkey).

Il s’agit donc finalement d’un simple interpréteur Javascript, exécutable, et enrichissant le langage avec sa propre API (accès au système de fichier, à la couche réseau, etc.). Ça permet, en résumé, d’exécuter des fichiers « .js » comme des scripts PHP, Python, Ruby, etc…

La spécificité n’est pas vraiment là (après tout, exécuter du JS en ligne de commande, ça se fait déjà), mais évidemment sur son API, toute entière orientée vers le non bloquant, c’est-à-dire que la plupart des commandes, notamment d’accès au système de fichier, rendront la main directement sans attendre la réponse du système, ceci étant largement simplifié par l’orientation évènementielle de Javascript. C’est ce choix de conception, ainsi que le choix du moteur V8 qui offre d’excellentes performances, qui permet d’écrire des applications avec d’excellents temps de réponse, et notamment des serveurs (web ou autres). Son API d’accès à la couche réseau (le protocole HTTP y est implémenté) couplé à cette capacité de gestion des accès concurrents en font évidemment un excellent candidat pour écrire des applications web.

Continue Reading

, , , ,

27mai

Filed in Javascript | NodeJS 5 Comments

S’il y a bien une chose qui craint avec les technologies « cool » et récentes, c’est la doc. Et Node.JS (ou plutôt la grande majorité de ses modules, car l’API de Node elle-même est plutôt bien documentée) n’échappe pas à la règle, et les contributions de @visionmedia quoi que d’excellentes facture et très populaires, en sont hélas une illustration ;) Du coup, il y a des fonctionnalités qu’on ne découvre qu’en farfouillant dans le code…

Je refléchissais en ce moment à un moyen de « packager » les applications Express dans Node.JS, de manière à les réutiliser. Naïvement, j’étais persuadé que ça n’était pas possible, et je suis parti dans le développement d’un framework permettant de simplifier ce packaging, avec des vues embarquées, etc… Naïf, oui, car évidemment cette fonctionnalité existe déjà dans Connect (la couche sous Express): quand on appelle app.use(une_autre_app), c’est comme si on « fusionnait » les deux applications. Ce comportement, ainsi que les valeurs de configuration disponibles, étant très mal documentées, je vais vous en parler ici :)

Continue Reading

28mar

Filed in Non classé 6 Comments

ESI - ou Edge Side Includes - est une solution de mise en cache partiel de page. L’idée générale est d’avoir des « portions » de la page qui sont servis avec différentes règles de mise en cache que le reste de la page.

On peut imaginer une page qui sera mise en cache dans sa globalité, sauf le petit widget « panier » qui lui ne sera pas mis en cache. Une problématique extrêmement fréquente et qui empêche généralement toute mise en cache, alors qu’on n’a qu’un tout petit morceau de la page qui est réellement dynamique :(
L’idéal serait alors que la page soit mise en cache complètement, et que sa partie dynamique soit simplement identifiée par un « marqueur », et que la navigateur aille chercher le contenu de ce « marqueur » à une autre adresse, qui elle a une politique de mise en cache différente.

Et bien c’est ce que propose ESI :) Le marqueur en question est un tag XML <esi src="adresse du morceau de page à rendre" />. Par contre les navigateurs ne comprennent pas ce langage directement, il faut donc ajouter entre les deux un « proxy cache » qui lui saura interpréter ces portions, et rendre au navigateur le résultat final.

Continue Reading

, ,

TOP

Switch to our mobile site