helyx.org rapport :   Visitez le site

Données techniques du helyx.org

Geo IP vous fournit comme la latitude, la longitude et l'ISP (Internet Service Provider) etc. informations. Notre service GeoIP a trouvé l'hôte helyx.org.Actuellement, hébergé dans France et son fournisseur de services est OVH SAS .

the related websites

domaine	Titre
helyx.org	helyx weblog
concurrent.free.fr	weblog
credit-emprunt-pret.com	weblog title: welcome!
climantica.org	climántica : weblog
mwyann.fr	weblog de mwyann
lalettredemotivation.free.fr	le weblog des lettres de motivation
godlike.fr	godlike's weblog on sap abap
libertecycles.fr	weblog - liberte cycles
viajeanoruega.com	Viaje a Noruega Just another WordPress weblog
dcurbanmom.com	DCUM Weblog DC Urban Moms and Dads
gilamfredaur.free.fr	weblog modelisme : please install firefox navigator
medef-franche-comte.com	medef territoriaux | just another adverbia.typhon.net weblog
iran.sc	iran.sc :: free persian weblog service ::
medef-languedocroussillon.com	medef territoriaux | just another adverbia.typhon.net weblog
blogigo.de	Blogigo - Kostenloses Weblog Blog in 5 Minuten

pagesjaunes.fr actisante-shop.com abimelec.com bilboquet.com speaking-agency.com studioecoledefrance.com liberation.fr cascadevents.fr benita-loca.com dailymotion.com 

Analyse d'en-tête HTTP

Les informations d'en-tête HTTP font partie du protocole HTTP que le navigateur d'un utilisateur envoie à appelé Apache contenant les détails de ce que le navigateur veut et acceptera de nouveau du serveur Web.

DNS

HtmlToText

skip to main content you are using an outdated browser. please upgrade your browser to improve your experience. toggle navigation search for: latest posts latest posts le 17 mai 2016 le langage rust a 1 an le langage rust a 1 an alexis kinsella le langage rust a comme objectif de proposer: une performance et un contrôle sans compromis, la prévention de nombreuses catégories de bug tels que les problèmes de concurrence une ergonomie à la hauteur de langages comme python et ruby. une année sépare la version 1.8.0 et la version sortie de la version1.0.0. pour être plus parlant cela représente près de 12.000 commit, et pas moins de 700 contributeurs. de façon remarquable, le langage est devenu sur stackoverflow, le langage le plus apprécié par les développeurs . l’ article anniversaire de rust propose en autre des cas concrets d’adoption du langage: le cas d’utilisation de dropbox est particulièrement intéressant car il met en lumière comment la société s’est de rust servi pour développer le logiciel qui permet de contrôler le matériel qu’ils ont développé dans le but de prendre leur autonomie vis-à-vis d’ amazon web services . inutile de souligner la criticité de la tâche pour une société qui décide de fonctionner sur son propre matériel à une telle échelle. alors que l’infrastructure back-end de dropbox a été écrite historiquement en go, des éléments clés comme l’empreinte mémoire ou encore le manque de contrôle sur l’utilisation serveur, ont poussé la ré-écriture de composants en rust. selon jamie turner , les avantages de rust sont nombreux: des capacités d’abstraction poussées, pas de null, pas de segfault, pas de leaks, mais des performances proches du c et un contrôle de la mémoire adéquat. dans un second feedback, l’article nous parle de servo , et des développements périphériques qui commencent doucement à atterrir dans la base de code de firefox, entre autre, la tâche de parsing des metadata mp4 sur osx et linux depuis la version 45 de firefox. bien que le code fonctionne encore en test mode , ce ne sont pas moins de 1 milliard de reports d’exécution qui ont pu être comparés avec la version c++ avec une justesse de 100%. cet exemple, reste néanmoins la partie visible de l’iceberg, puisque d’autres morceaux de code devraient être intégrés à terme. au cours de cette première année, le focus a été donné particulièrement à l’amélioration de rust, aussi bien sur la partie écosystème, qu’envers les plateformes supportées, les outils, le compilateur, ou bien encore le langage en lui-même. l’ article détaille chacune de ces catégories. la première conférence sur le langage rust, la rustconf , est prévue les 9 et 10 septembre 2016 à portland. si le langage rust est un sujet d’intérêt pour vous, et que vous habitez en europe, pas d’inquiétude, la rustfest est également prévue à berlin le 17 septembre 2016. enfin, si vous voulez suivre l’actualité rust, vous pouvez vous enregistrer à la newsletter this week in rust pour vous tenir au courant des nouveautés de l’écosystème. le 21 juillet 2014 zero downtime deployment avec node.js et express, une première étape … zero downtime deployment avec node.js et express, une première étape … alexis kinsella lorsqu’on souhaite stopper ou redémarrer un serveur, différentes solutions s’offrent à nous. parmi elles, la possibilité d’envoyer un signal de type sigterm au processus. cette solution est couramment utilisée, malheureusement cela entraîne la coupure des connexions en cours sans permettre au serveur d’honorer les requêtes en cours de traitement. dans l’objectif de fournir une meilleure qualité de service, il est important d’honorer toute requête entrante. comment faire, donc, pour permettre le redémarrage d’un serveur en douceur, sans couper brutalement les connexions en cours ? le protocole http permet au serveur de répondre aux requêtes entrantes par un status code 503 qui signifie que le service n’est pas disponible (service unavailable). l’idée est donc de renvoyer ce status code dès lors que le process a reçu un signal sigterm, tout en laissant le temps au serveur de terminer le traitement des requêtes http en cours, puis de stopper le serveur une fois que les requêtes en cours sont traitées. il est toujours possible de killer le process du serveur si cela met trop longtemps. node.js avec node.js, il est possible d’écouter les signaux reçus par le système et d’y réagir. il est donc possible de mettre en place une mécanique qui instruit le serveur de répondre aux nouvelles requêtes entrantes par un status code 503, puis de couper le serveur une fois les requêtes en cours traitées. cela donne le code suivant: start = new date ( ) # express app = express ( ) gracefullyclosing = false app. configure -> app. set 'port' , process. env . port or 8000 app. use ( req , res , next ) -> return next ( ) unless gracefullyclosing res. setheader "connection" , "close" res. send 503 , "server is in the process of restarting" app. use app. router app. get '/' , ( req , res ) -> res. send 200 , 'ok' httpserver = app. listen app. get ( 'port' ) process. on 'sigterm' , -> logger. info "received kill signal (sigterm), shutting down gracefully." gracefullyclosing = true httpserver. close -> logger. info "closed out remaining connections." process. exit ( ) settimeout -> console. error "could not close connections in time, forcefully shutting down" process. exit ( 1 ) , 30 * 1000 l’appel de la fonction close sur l’instance de serveur http renvoyée express , permet au serveur de terminer le traitement des requête en cours avant de s’arrêter. si votre application node.js est correctement redondée avec un reverse proxy (nginx, haproxy) devant les différentes instances, les requêtes entrantes seront redirigées vers d’autres instances en état de traiter les requêtes. cela sera le cas dès lors que votre application répondra aux requêtes entrantes avec des status code 502 ou 503 par exemple. nginx si votre application est déployée derrière un reverse proxy tel que nginx, il suffit de configurer celui-ci avec plusieurs flux upstream vers différentes instances de votre application pour qu’il soit capable de passer la main à une autre instance lorsqu’il reçoit un code erreur 502 ou 503 en réponse à une requête transmise à une des instances. upstream my_app_upstream { server 127.0.0.1: 7000 ; server 127.0.0.1: 8000 ; server 127.0.0.1: 9000 ; } ensuite, il faut déclarer ce que nginx doit faire lorsqu’il reçoit une réponse 502 ou 503 et le tour est joué. ici, nous indiquons à nginx via la directive proxy_next_upstream de faire suivre la requête au prochain flux upstream lorsqu’il reçoit en réponse une erreur, un timeout ou bien un code http 502 ou 503: location /app { ... proxy_next_upstream error timeout http_502 http_503; ... proxy_pass http://my_app_upstream; } limitations ce fonctionnement décrit dans cet article répond bien aux besoins d’applications traitant des requêtes http simples, néanmoins il ne répond pas au problème des configurations ayant activé l’option de keepalive pour les connexions http, ni aux applications utilisant les websockets. il faudra dès lors trouver une solutions adaptée. conclusion la mise en oeuvre de la notion de gracefully closing lors d’un redémarrage pour raison de déploiement d’une nouvelle version, est une première étape importante pour arriver à faire du zero downtime deployment . cela permet, non seulement d’honorer les requêtes en cours de traitement, mais également à vos reverse proxy de prendre connaissance de l’absence de service et redispatcher les requêtes sur d’autres serveurs avant que le flux upstream soit coupé. le 17 juillet 2014 clusteriser votre application node.js clusteriser votre application node.js alexis kinsella les application node.js sont par nature mono-threadées, or les serveurs, de nos jours, sont presque * toujours multi-core. pour exploiter l’ensemble des capacités de ces serveurs, il est nécessaire de pouvoir exploiter tous les cores. pour cela, il existe principalement 2 techniques: lancer plusieurs instances d’une application node.js sur différents avec un reverse proxy pour load balancer les requêtes entrantes lancer une application node.js en mode cluster dans l’idéal, il faut lancer autant d’instances qu’il y a de cores sur la machine. cela permet de partager au mieux la puissance de la machine entre les différentes instances sans pour autant dégrader les performances en partager les cores entre plusieurs instances. nous allons dans cet article nous intéresser au second cas de figure, c’est à dire le lancement d’application node.js en mode cluster. * le terme “presque” est utilisé ici car de nombreux serveurs cloud d’entrée de gamme restent mono-threadés (vps et instances ec2 1er prix, …). le module cluster le module cluster , bien que marqué comme ayant une api expérimental dans la documentation de node.js, est aujourd’hui largement utilisé. son principe est simple, lorsqu’une application est lancée en mode cluster, un premier process est démarré en mode master . le process master n’a pas pour rôle de traiter les requêtes entrantes à proprement parler, mais plutôt à les dispatcher aux aux process forkés qui eux sont dédiés au traitement des requêtes. il sont lancés dans le mode worker . la responsabilité de l’instanciation de forks en mode worker est du ressort du process master, et les règles sont de fork sont laissées à la responsabilité du développeur. tout au long de la vie du cluster, des événements sont générés aussi bien par le master que par les workers. il est important de s’y abonner pour être capable de réagir à des changements dans le cluster (crash d’un worker, par exemple). un exemple simple de cluster est proposé par la documentation: cluster = require ( "cluster" ) http = require ( "http" ) numcpus = require ( "os" ) . cpus ( ) . length if cluster. ismaster # fork workers. i = 0 while i < numcpus cluster. fork ( ) i ++ cluster. on "exit" , ( worker , code , signal ) -> console. log "worker " + worker. process . pid + " died" else # workers can share any tcp connection # in this case its a http server http. createserver ( ( req , res ) -> res. writehead 200 res. end "hello world \n " ) . listen 8000 bien que les api de clusterisation proposent une api assez simple à gérer, il faut néanmoins s’occuper de plusieurs points de détail, et le risque de mal faire est rapidement arrivé. il est donc conseillé de s’appuyer sur un module tiers pour traiter ce sujet. le module recluster , très intéressant de part sa simplicité et sa maturité, permet de s’affranchir de toute cette complexité de mise en oeuvre. recluster pour l’installer, il suffit de taper la commande suivante: npm install recluster --save pour instancer une application en mode cluster, il suffit d’ajouter le script suivant (cluster.coffee, par exemple) à votre application: recluster = require ( "recluster" ) path = require ( "path" ) cluster = recluster ( path. join ( __dirname , "server.js" ) , { ### options ### } ) cluster. run ( ) process. on "sigusr2" , -> console. log "got sigusr2, reloading cluster..." cluster. reload ( ) console. log "spawned cluster, kill -s sigusr2" , process. pid , "to reload" le module recluster attend en paramètre le chemin du script. il suffit ensuite de lancer le fichier cluster.js au lieu du fichier server.js, et le tour est joué ! (les exemples étant en coffeescript, il est nécessaire d’avoir au préalable compilé les fichiers coffeescript). zero downtime reloading le modules recluster permet de mettre à jour une application sans coupure de service, il faut pour cela appeler la fonction reload sur la variable cluster. dans l’exemple ci-dessus, le signal sigusr2, permet d’indiquer au programme que le cluster doit être rechargé. celui-ci rechargera les différents workers en se basant sur les options passées en paramètre (timeout de rechargement, etc). les requêtes en cours de traitement seront honorés sans coupure brutale, dans la limite d’un timeout défini par les options de configuration du module. cette fonctionnalité est particulièrement intéressantes lors que l’application doit être mise à jour sans coupure de service. ainsi, la base de code peut-être mise à jour, puis les workers redémarrés un par un une fois les requêtes en cours traitées. il est possible de s’appuyer sur d’autres conditions pour recharger les workers d’un cluster, par exemple, il est possible de s’appuyer sur la modification du fichier package.json pour déclencher un rechargement avec le code suivant: fs = require 'fs' fs. watchfile "package.json" , ( curr , prev ) -> console. log "package.json changed, reloading cluster..." cluster. reload ( ) conclusion ne vous laissez pas impressionner par la notion de clusterisation. elle est très simple à mettre en oeuvre dans le monde node.js grâce à une api de base faisant parti des core modules , et de nombreux modules s’appuyant dessus. le 15 juillet 2014 gérer les erreurs avec node.js gérer les erreurs avec node.js alexis kinsella lorsqu’une exception n’est pas gérée dans un programme node.js, cela se termine en général par un crash du process de l’application. il n’y a d’ailleurs pas grand chose à faire pour tenter de rattraper le coup si l’erreur remonte jusqu’à la boucle d’événement. c’est pourquoi, il est nécessaire de traiter les erreurs avec attention. si votre programme génère une erreur qui remonte jusqu’à la boucle d’événement comme suit: process. nexttick ( ) -> throw new error ( "some bad error" ) vous aurez le droit au message d’erreur qui suit: express listening on port: 9000 started in 0.073 seconds / users / akinsella / workspace / projects / gtfs-playground / build / app-test.js: 30 throw new error ( "some bad error" ) ; ^ error: some bad error at / users / akinsella / workspace / projects / gtfs-playground / build / app-test.js: 30 : 11 at process._tickcallback ( node.js: 415 : 13 ) at function.module.runmain ( module.js: 499 : 11 ) at startup ( node.js: 119 : 16 ) at node.js: 901 : 3 process finished with exit code 8 l’événement ‘uncaughtexception’ node.js vous donne une chance d’intercepter les erreurs qui remontent jusqu’à la boucle d’événement grace au dispatch l’événement de type uncaughtexcpetion . contrairement à ce qu’on pourrait penser, l’événement n’est pas dispatché par le process node.js pour catcher l’erreur et permettre de continuer au programme son exécution. c’est principalement pour gérer correctement la libération de resources qui auraient été ouvertes par le programmes, et éventuellement logger de façon plus précise le contexte de l’erreur (etat de la mémoire, etc…). lorsqu’une erreur remonte jusqu’à la boucle d’événement, il ne faut plus considérer l’état du programme comme étant consistant. c’est pour cette raison qu’il ne faut pas tenter de catcher l’exception dans l’idée de permettre au programme de continuer à fonctionner. si vous souhaitez logger un message d’erreur dans le cas d’une exception remontée jusqu’à la boucle d’événement, vous pouvevz ajouter le code suivant à votre programme: process. on 'uncaughtexception' , ( err ) -> console. log json. stringify ( process. memoryusage ( ) ) console. error "an uncaughtexception was found, the program will end. #{err}, stacktrace: #{err.stack}" process. exit 1 process. nexttick ( ) -> throw new error ( "some bad error" ) ce qui donne le résultat suivant: / users / akinsella / .nvm / v0.10.22 / bin / node app-test.js { "rss" : 12312576 , "heaptotal" : 4083456 , "heapused" : 2153648 } an uncaughtexception was found, the program will end. error: some bad error, stacktrace: error: some bad error at / users / akinsella / workspace / projects / gtfs-playground / build / app-test.js: 13 : 11 at process._tickcallback ( node.js: 415 : 13 ) at function.module.runmain ( module.js: 499 : 11 ) at startup ( node.js: 119 : 16 ) at node.js: 901 : 3 process finished with exit code 1 contrairement à la gestion par défaut, nous avons pu retourner un exit code spécifique. ici le code retour: 1 le message de log est également différent. nous sommes donc en mesure de maitriser le log d’erreur en cas de crash. par ailleurs, les informations de mémoire rendues disponibles dans les logs participeront à faciliter l’analyse du crash. express si vous utilisez un framework type express , vous serez déchargé d’une partie du travail car les erreurs qui interviennent pendant le traitement d’une requête htttp sont catchées par le framework qui gérera pour vous l’erreur. par défaut express se contente de logger un crash qui intervient dans le traitement d’une requête http via un simple log retourné dans la réponse http. par exemple, en exécutant le programme suivant: express = require 'express' app = express ( ) app. configure -> app. set 'port' , process. env . port or 9000 app. use app. router app. get "/" , ( req , res ) -> throw new error ( "some bad error" ) httpserver = app. listen app. get ( 'port' ) process. on 'uncaughtexception' , ( err ) -> console. error "an uncaughtexception was found, the program will end. #{err}, stacktrace: #{err.stack}" process. exit 1 console. error "express listening on port: #{app.get('port')}" puis en se rendant sur l’url http://localhost:9000 , express renverra dans la réponse http le log suivant: error: some bad error at / users / akinsella / workspace / projects / gtfs-playground / build / app-test.js: 16 : 11 at callbacks ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / lib / router / index.js: 164 : 37 ) at param ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / lib / router / index.js: 138 : 11 ) at pass ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / lib / router / index.js: 145 : 5 ) at router._dispatch ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / lib / router / index.js: 173 : 5 ) at object.router ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / lib / router / index.js: 33 : 10 ) at next ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / node_modules / connect / lib / proto.js: 193 : 15 ) at object.expressinit [ as handle ] ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / lib / middleware.js: 30 : 5 ) at next ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / node_modules / connect / lib / proto.js: 193 : 15 ) at object.query [ as handle ] ( / users / akinsella / workspace / projects / gtfs-playground / node_modules / express / node_modules / connect / lib / middleware / query.js: 45 : 5 ) il est également possible d’activer un log plus détaillé, avec une mise en forme html, particulièrement utile en mode développement en ajoutant les lignes suivantes: app. configure 'development' , ( ) -> app. use express. errorhandler dumpexceptions : true , showstack : true le résultat sera le suivant: express vous permet également de renseigner un middleware qui aura la possibilité d’interagir les erreurs rencontrées dans le traitement des requêtes http. ce middleware peut être utile pour logger l’erreur rencontrée ou bien encore libérer des resources associées à la requête en cours de traitement. il permettra également de renvoyer une réponse adaptée à l’utilisateur en cas d’erreur non gérée. ce point particulièrement intéressant dans le cas de l’implémentation d’api rest. le serveur devient capable de renvoyer une erreur interprétable par le client même en cas d’erreur non gérée. le middleware prendra la format suivant: app. use ( err , req , res , next ) -> console. error "error: #{err}, stacktrace: #{err.stack}" res. send 500 , "something broke! error: #{err}, stacktrace: #{err.stack}" les promises les promises peuvent vous aider à gérer les erreurs plus efficacement grâce à leur mécanisme de gestion des erreurs. un traitement encapsulé dans une promise ne permettra jamais à une erreur de remonter jusqu’à l’ event loop , l’erreur sera catchée par la promise qui sera remontée dans la fonction fail ou catch selon la librairie ou bien encore dans le callback d’erreur de la fonction then . il est donc intéressant d’encapsuler vos traitement avec des promises, non seulement pour améliorer la lisibilité du code, mais également pour sa capacité à résister aux crashs. les domaines la notion de domain ne sera pas traitée dans cet article, sachez néanmoins que cette notion a été ajoutée à node.js en version 0.10. en bref et pour faire simple, l’idée est plus ou moins de containeriser des event emitters en les associant à un domain . en cas d’erreur dans le traitement d’un événement géré par un domain , l’exception ne fera pas crasher le programme directement, c’est le domain qui sera en charge de traiter l’erreur, mais cela ne vous sauvera pas en général d’un redémarrage du process … commen en témoigne la documentation: domain error handlers are not a substitute for closing down your process when an error occurs. by the very nature of how throw works in javascript, there is almost never any way to safely « pick up where you left off », without leaking references, or creating some other sort of undefined brittle state. the safest way to respond to a thrown error is to shut down the process. of course, in a normal web server, you might have many connections open, and it is not reasonable to abruptly shut those down because an error was triggered by someone else. the better approach is send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker. in this way, domain usage goes hand-in-hand with the cluster module, since the master process can fork a new worker when a worker encounters an error. for node programs that scale to multiple machines, the terminating proxy or service registry can take note of the failure, and react accordingly. la documentation de node.js relative aux domains est disponibles à l’url suivante: http://nodejs.org/api/domain.html le 9 juillet 2014 détecter les versions dépassées de vos dépendances node.js détecter les versions dépassées de vos dépendances node.js alexis kinsella l’écosystème node.js est non seulement très jeune, mais également très dynamique. les versions des librairies que vous utilisez ont tendance à changer très vite. pour vous économiser la recherche permanente des versions de librairies les plus récentes pour mettre à jour votre fichier package.json , npm met à disposition l’outil npm-outdated qui se charge d’analyser vos dépendances et de vous indiquer celles qui ne sont plus à jour. npm-outdated l’outil npm-outdated s’utilise très simplement en l’appelant de la façon suivante: npm outdated --depth = 0 et produira la sortie ci-dessous: les versions plus anciennes de l’outil ne produiront pas de sortie colorisée, il est donc intéressant de monter de version. la version de npm utilsée ici est la 1.4.9 . npm-outdated analysera aussi bien vos dépendances standards que les dépendances de développement sans faire de distinction. la sortie retournée par l’outil ne montre que les dépendances ayant une version dépassée. vous ne verrez donc pas les dépendances ayant une version à jour. 3 versions différentes sont renseignées: current , wanted et latest . ces versions représentent respectivement la version courante, puis la dernière version à jour correspondant au pattern de version déclaré pour votre dépendance dans le fichier package.json , et enfin la dernière version disponible de la librairie. option depth le paramètre –depth=0 permet de se limiter aux dépendances directes sans se soucier des dépendances tirées par les librairies elles-même tirées par vos dépendances directes. si nous utilisons le paramètre –depth=2 , les dépendances indirectes commenceront alors à être matérialisées dans la sortie de l’outil: option json le paramètre –json permet quant à lui d’obtenir une sortie json. cette option est particulièrement pratique pour exploiter l’information produite dans des rapports de build par exemple, ou bien pour être exploiter par d’autres outils. en exécutant la ligne de commande suivante: npm outdated --depth = 0 --json vous obtiendrez la sortie suivante: { "coffee-script" : { "current" : "1.6.3" , "wanted" : "1.6.3" , "latest" : "1.7.1" , "location" : "node_modules/coffee-script" } , "passport-local" : { "current" : "0.1.6" , "wanted" : "0.1.6" , "latest" : "1.0.0" , "location" : "node_modules/passport-local" } , "uglify-js" : { "current" : "2.4.13" , "wanted" : "2.4.14" , "latest" : "2.4.14" , "location" : "node_modules/uglify-js" } , ... } npm-update maintenant que vous connaissez les dernières versions disponibles, vous souhaitez peut-être en mettre certaines à jour. pour cela, vous pouvez utiliser l’outil npm update . pour mettre à jour la librairie request , il faudrait exécuter la commande suivante: npm update request badges pour votre repository github le projet david vous permet de générer des badges indiquant si les versions de vos librairies sont à jour ou bien dépassées. ce projet est particulièrement intéressant car, non seulement, il génère des rapports pour votre projet sans que vous ayez à lever le petit doigt, mais il génère également des badges que vous pouvez exposer les pages de votre projet permettant d’indiquer l’état des versions de vos dépendances. pour exemple, pour savoir si le projet gtfs-playground a les versions de ses dépendances à jour, vous pouvez vous rendre sur la page suivante: https://david-dm.org/akinsella/gtfs-playground l’outil fonctionne exclusivement avec les repositories github. pour construire un rapport pour votre projet, il suffit de renseigner votre organization et du nom de votre repository dans l’url suivante avant de l’appeler: https: // david-dm.org /< organization >/< repository > de même, pour obtenir le badge correspondant à votre projet, il suffit de construire la balise img comme suit: https: // david-dm.org /< organization >/< repository > . < extension > ce qui donne le résultat suivant pour le format png: et pour le format svg: conclusion l’écosystème node.js évolue rapidement. les librairies proposent donc régulièrement de nouvelles fonctionnalités ou bien encore des corrections de bug. il ne faut donc pas hésiter à mettre à jour ses librairies. attention cependant à ne pas non plus se précipiter et installer une version de librairie qui ne serait plus compatible avec votre code ou bien encore d’installer une version buggée. il faut donc penser à faire tourner ses tests pour s’assurer qu’aucune regression n’impacte votre base de code. le 4 juillet 2014 transformez votre code node.js grâce au module de promises bluebird transformez votre code node.js grâce au module de promises bluebird alexis kinsella lorsqu’on parle de promises dans l’écosystème node.js, on pense immédiatement à la librairie q . toutefois, il existe de nombreux modules de promises proposant chacun des choses différentes. en particulier, le module bluebird se démarque grâce à des fonctionnalités tout à fait intéressantes telles que la “promisification” . promisification les core modules de node.js fonctionnent à base de callback. ainsi pour lire un fichier de façon asynchrone, il faut appeler la fonction readfile du module fs et traiter la réponse depuis le callback passé en dernier paramètre de la fonction lors de son appel: fs. readfile "file.json" , ( err , val ) -> if err console. error "unable to read file" try val = json. parse ( val ) ; console. log val. success catch e console. error "invalid json in file" bluebird permet de transformer le code précédent dans le code suivant: fs. readfileasync ( "file.json" ) . then ( json. parse ) . then ( val ) -> console. log val. success . catch syntaxerror , ( e ) -> console. error "invalid json in file" . catch ( e ) -> console. error "unable to read file" promisifyall cette transformation est rendue possible grâce à la promisification du module fs , via l’appel de la fonction promisifyall qui permet de transformer toutes les fonctions exposées en fonctions renvoyant des promises: fs = require "fs" promise. promisifyall fs fs. readfileasync ( "file.js" , "utf8" ) . then ( ... ) selon toute vraisemblance, les fonctions du modules sont proxifiées via un wrapping changeant la signature. on pourra noter que le chaînage de fonctions catch sur la promise permet de différencier le traitement des erreurs en fonction de leur type. ici, l’erreur de type syntaxerror est traitée différemment des erreurs typées autrement. promisify il est également possible de ne promisifier qu’une seule fonction grâce à la fonction promisify : redisget = promise. promisify ( redisclient. get , redisclient ) redisget ( 'foo' ) . then ( ) -> #... il y a tout de même un piège puisque la fonction attend 2 paramètres. le premier étant la référence de la fonction à promisifier, et le second étant l’objet auquel la fonction est rattachée. nodeify la fonction nodeify est également très intéressante car elle permet d’enregistrer un callback sur une promise bluebird et d’appeler celui-ci à la résolution de cette dernière: getdatafor ( input , callback ) -> datafromdatabase ( input ) . nodeify ( callback ) cette possibilité est particulièrement intéressante, car elle permet de construire des api qui deviennent utilisables aussi bien par du code qui fonctionne à base de callback, qu’avec du code à base de promise. ainsi, si le callback est renseigné, il sera appelé. sinon, il suffira d’exploiter la promise retournée par la fonction pour obtenir et traiter le résultat de l’appel. exemple exploitant le mécanisme de promise: getdatafor ( "me" ) . then ( dataforme ) -> console. log dataforme le même exemple exploitant le mécanisme de callback: getdatafor "me" , ( err , dataforme ) -> if err console. error err console. log dataforme spread en temps normal, le code suivant donnera en résultat la tableau : [1, 2, 3]. promise. resolve ( [ 1 , 2 , 3 ] ) . nodeify ( err , result ) -> # err == null # result: [1,2,3] toutefois, l’option {spread: true} passée à l’appel de la fonction nodeify , permet de dispatcher les valeurs de résultat sur l’ensemble des arguments de la fonction de callback renseignée: promise. resolve ( [ 1 , 2 , 3 ] ) . nodeify ( err , a , b , c ) -> # err == null # a == 1 # b == 2 # c == 3 , { spread : true } conclusion la librairie bluebird est riche en fonctions pour le moins intéressantes, vous pouvez les retrouver sur la page de documentation du projet github: lien: https://github.com/petkaantonov/bluebird/blob/master/api.md le 30 juin 2014 locker les versions de vos dépendances node.js locker les versions de vos dépendances node.js alexis kinsella node.js dispose d’un gestionnaire de dépendances très efficace et incontournable: npm . reposant sur les informations de dépendances déclarées dans le fichier package.json , il s’occupera de récupérer les dépendances déclarées et de les installées le dossier node_modules de votre projet, via l’exécution de la commande: npm install pourquoi ? contrairement à la mécanique proposée par maven dans le monde java, node.js repose sur une mécanique de dépendances hiérarchiques. c’est à dire que npm va récupérer et installer pour chaque niveau – application, et dépendances elles-mêmes – les librairies associées. par exemple, si votre projet, ainsi que les librairies dont il dépend, utilisent la librairie mkdirp , alors npm va charger et installer la dépendance mkdirp à la fois dans le dossier node_modules de votre projet, mais également dans le dossier node_modules de la librairie de votre projet. pour chaque librairie, dont vous dépendez, vous devez déclarer un pattern de sélection de version qui indiquera à npm quelle version de dépendance télécharger. les patterns disponibles sont variés, allant du wildcard, à la version exacte. quels risques ? très rapidement, vous serez confronté à des problématiques de versions de dépendances qui évoluent. cela empêchera, au mieux, vos applications de tourner correctement. au pire engendrera des bugs subtiles et très difficiles à détecter ou corriger, avec le risque de mettre en péril votre business, ou bien la qualité perçue de vos logiciels. quelles solutions ? quels outils ? une technique possible pour se prémunir de ce problème, est de locker les versions de vos dépendances en indiquant des patterns de version plus restrictifs, voir complètement fixés. vous ne serez pas sorti d’affaire pour autant. vous aurez beau fixer les versions de vos dépendances, celles-ci reposent également sur d’autres dépendances, pour lesquelles, leur auteurs respectifs n’appliquent peut-être pas les règles de gestion de versions qui vous arrange. ainsi, il est possible qu’une librairie donnée déclare une version de dépendance avec un wildcard. de fait, vous serez amené, à terme, à récupérer une version qui sera, soit incompatible avec votre code, soit tout simplement buggée. il faudrait, dans l’idéal, pouvoir locker toute la hiérarchie des versions de dépendances et pouvoir réinstaller ces dépendances de façon répétée dans les versions sélectionnées. la bonne nouvelle, c’est qu’il existe des solutions pour répondre à ce besoin, dont les outils lockdown et npm-shrinkwrap . lockdown le module lockdown propose de locker les versions des dépendances de votre projet dans le but de vous assurer que le code que vous développez reposera sur les même version de dépendances que ce soit dans votre ide ou bien pendant vos phases de tests ou bien en production. l’usage de lockdown vous permettra de continuer à utiliser la commande npm install , tout en vous assurant d’obtenir le même code à chaque fois que la commande sera exécutée, ainsi qu’en vous évitant d’avoir à copier le code de vos dépendances dans votre gestionnaire de code source ou d’avoir à maintenir un repository privé npm. comme expliqué précédemment, même si vous exprimez la version exacte de vos dépendances dans votre fichier projet package.json , vous êtes toujours vulnérable à l’apparition soudaine d’une incompatibilité avec l’une de vos dépendances. par exemple, si votre projet dépend d’un package avec une version spécifique, qui, elle même dépend d’un autre package déclaré avec un version range, vous risquez de voir la version de votre dépendance changer lors d’une future exécution de la commande npm install . cet exemple n’est hélas pas la seule cause de problème. d’autre actions peuvent accidentellement casser le code de votre application: en poussant une nouvelle version de librairie qui ne supporte plus la version de node.js que vous utilisez en introduisant un bug dans du code qui fonctionnait bien au préalable … utilisation 1. installez une dépendance dans votre projet. par exemple, en ligne de commande: npm install < module >@< version > --save 2. générez le fichier lockdown.json en exécutant la commande lockdown-relock : node_modules / .bin / lockdown-relock 3. puis, ajoutez le fichier nouvellement créé à votre gestionnaire de code source. installer vos dépendances grâce au fichier lockdown.json une fois le fichier lockdown.json généré, il vous suffit d’appeler, de façon tout à fait classique, la commande npm install qui installera l’ensemble des dépendances dans les versions attendues. points forts lockdown se veut être un outil vous garantissant d’utiliser un code source identique, aussi bien en développement qu’en production. c’est pour cela, qu’en plus de stocker les versions des dépendances utilisées, il stocke également des checksums du code utilisé. il permet donc de savoir qu’un code source dans une version donnée a été modifié, et vous alerte du problème. autre point intéressant: le projet est maintenu par mozilla, ce qui a tendance à rassurer quant au sérieux et la pérennité de l’outil. npm-shrinkwrap tout comme l’outil lockdown , la commande npm-shrinkwrap propose de figer les versions de dépendances de votre application. pas de souci d’installation néanmoins, puisque la commande est directement disponible dans la distribution de npm . npm venant avec l’installation de node.js , pas besoin de bouger le petit doigt pour avoir l’outil à disposition. le fichier de stockage des informations de version s’appelle quant à lui npm-shrinkwrap.json . utilisation l’utilisation de npm-shrinkwrap est tout à fait similaire à celle de lockdown , il suffit d’utiliser la commande npm install pour installer vos dépendances, puis exécuter la commande npm shrinkwrap pour générer le fichier de version. gestion des checksums contrairement à lockdown , la commande npm-shrinkwrap ne gère pas de checksum. néanmoins, il existe des solutions de remplacement, telles que le package npm-seal qui se propose de venir compléter la commande npm-shrinkwrap en proposant la fonctionnalité manquante. contrairement à l’utilitaire npm-shrinkwrap , le package npm-seal est un utilitaire 3rd party qui doit être installé en complément avec la commande suivante: npm install seal -g points forts nous l’avons déjà vu, la commande est intégrée à la distribution de l’outil npm . par ailleurs, l’outil est également maintenu par une entreprise gage de sérieux: uber . bon à savoir même si les outils lockdown et npm-shrinkwrap vous proposent des solutions différentes, il est tout à fait possible de combiner l’usage de ces deux outils sans que cela pose de problème. le 27 juin 2014 activer le support jsonp avec express activer le support jsonp avec express alexis kinsella si vos services webs sont destinés à être appelés depuis d’autres domaines dans un browser web, il sera nécessaire d’activer le support du json padding pour vos services rest json. le support du json padding selon le serveur utilisé est très variable. côté node.js avec express, la fonctionnalité est très bien supportée, mais n’est pas activée par défaut. il faut donc l’activer dans la configuration de votre serveur. malheureusement, il faut chercher un peu pour trouver comment faire. voici donc pour vous faire gagner un peu de temps comment configurer votre serveur: app. set 'jsonp callback name' , 'callback' la configuration de la clé: ‘jsonp callback name’ permet de spécifier le nom du paramètre de querystring qui correspondra au callback encapsulant le json de retour. dans notre cas, ici, la variable s’appellera: ‘callback’ . un appel sans callback donnera le résultat suivant: akinsella @ ~$ curl http: // localhost: 8000 / api / v1 / conferences [ { "id" : 12 , "backgroundurl" : "http://blog.xebia.fr/images/devoxxuk-2014-background.png" , "logourl" : "http://blog.xebia.fr/images/devoxxuk-2014-logo.png" , "iconurl" : "http://blog.xebia.fr/images/devoxxuk-2014-icon.png" , "from" : "2014-06-12" , "name" : "devoxxuk 2014" , "description" : "the devoxx uk annual event." , "location" : "business design center" , "enabled" : true , "to" : "2014-06-13" } , ... ] les en-têtes spécifieront un content-type de type ‘application/json’ : akinsella @ ~$ curl -i http: // localhost: 8000 / api / v1 / conferences http / 1.1 200 ok content-type: application / json; charset =utf- 8 content-length: 4397 date: sat, 14 jun 2014 14 : 11 : 36 gmt connection: keep-alive alors qu’en appellant des resources avec le paramètre de querystring : ‘callback’ , le serveur générera des réponses avec un content-type de type ‘text/javascript’ : akinsella @ ~$ curl -i http: // localhost: 8000 / api / v1 / conferences\?callback\=cb http / 1.1 200 ok content-type: text / javascript; charset =utf- 8 content-length: 4430 date: sat, 14 jun 2014 13 : 56 :03 gmt connection: keep-alive le contenu de la réponse sera le suivant: akinsella @ ~$ curl http: // localhost: 8000 / api / v1 / conferences\?callback\=cb typeof cb === 'function' && cb ( [ { "id" : 12 , "backgroundurl" : "http://blog.xebia.fr/images/devoxxuk-2014-background.png" , "logourl" : "http://blog.xebia.fr/images/devoxxuk-2014-logo.png" , "iconurl" : "http://blog.xebia.fr/images/devoxxuk-2014-icon.png" , "from" : "2014-06-12" , "name" : "devoxxuk 2014" , "description" : "the devoxx uk annual event." , "location" : "business design center" , "enabled" : true , "to" : "2014-06-13" } , ... ] ) ; cerise sur le gâteau, la génération du résultat est parfaitement gérée: la sortie obtenue intègre les best pratices de codage permettant d’éviter d’être vulnérable à certaines attaques xss associées à l’utilisation du json padding. le 25 juin 2014 désactiver l’en-tête de réponse ‘x-powered-by’ avec express désactiver l’en-tête de réponse ‘x-powered-by’ avec express alexis kinsella il peut-être jugé embêtant niveau sécurité de dévoiler le type de serveur qui fait tourner vos services web. il est donc préférable de ne pas envoyer cette information dans les en-tête de réponses http avec express. exemple de réponse http avec l’en-tête ‘x-powered-by’ activé: akinsella @ ~$ curl -i http: // localhost: 8000 / api / v1 / conferences http / 1.1 200 ok x-powered-by: express content-type: application / json; charset =utf- 8 content-length: 4397 date: sat, 14 jun 2014 22 : 43 : 15 gmt connection: keep-alive pour ce faire, il vous suffit de déclarer l’option suivante dans le code de configuration de votre application: app. disable "x-powered-by" les clients http connectés à vos services ne recevrons ainsi plus cette information: akinsella @ ~$ curl -i http: // localhost: 8000 / api / v1 / conferences http / 1.1 200 ok content-type: application / json; charset =utf- 8 content-length: 4397 date: sat, 14 jun 2014 22 : 43 : 15 gmt connection: keep-alive le 23 juin 2014 créer un middleware de log des requêtes http entrantes pour express créer un middleware de log des requêtes http entrantes pour express alexis kinsella vous souhaitez pouvoir logger les connections http rentrantes avec node.js et express ? rien de plus simple! il suffit de déclarer un middleware de la façon suivante: util = require 'util' module. exports = ( req , res , next ) -> console. log """--------------------------------------------------------- http request - pid process: [#{process.pid}] http request - url: #{req.url} http request - query: #{util.inspect(req.query)} http request - method: #{req.method} http request - headers: #{util.inspect(req.headers)} http request - body: #{util.inspect(req.body)} ---------------------------------------------------------""" next ( ) comme vous pouvez le voir, aucun module externe n’est nécessaire. il suffit ensuite d’intégrer votre nouveau middleware dans le code de configuration de votre serveur express , comme suit: express = require 'express' requestlogger = require './lib/requestlogger' app = express ( ) app. configure -> console. log "environment: #{app.get('env')}" app. set 'port' , 8000 ... app . use requestlogger ... app . use app. router app. listen app. get ( 'port' ) le log résultant d’une requête http prendra la forme suivante: --------------------------------------------------------- http request - pid process: [ 26074 ] http request - url: / http request - query: { } http request - method: get http request - headers: { host: 'localhost:9000' , connection: 'keep-alive' , accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' , 'user-agent' : 'mozilla/5.0 (macintosh; intel mac os x 10_9_3) applewebkit/537.36 (khtml, like gecko) chrome/35.0.1916.153 safari/537.36' , 'accept-encoding' : 'gzip,deflate,sdch' , 'accept-language' : 'fr-fr,fr;q=0.8,en-us;q=0.6,en;q=0.4' , cookie: '...' } http request - body: undefined --------------------------------------------------------- 1 2 3 4 … 9 10 11 alexis kinsella golang, ios, node.js, java, nosql, cloud software craftsman (tries at least...) xebia france application mobile de xebia pour iphone et ipad © 2018

Analyse PopURL pour helyx.org

http://blog.helyx.org/wp-content/uploads/npm-outdated-depth-1.jpg
http://blog.helyx.org/2014/06/desactiver-len-tete-de-reponse-x-powered-by-avec-express/
http://blog.helyx.org/2014/07/transformez-votre-code-node-js-grace-au-module-de-promises-bluebird/
http://blog.helyx.org/2014/07/clusteriser-votre-application-node-js/
http://blog.helyx.org/2014/06/creer-un-middleware-de-log-des-requetes-http-entrantes-pour-express/
http://blog.helyx.org/wp-content/uploads/npm-outdated.jpg
http://blog.helyx.org/page/10/
http://blog.helyx.org/2014/06/locker-les-versions-de-vos-dependances-node-js/
http://blog.helyx.org/page/4/
http://blog.helyx.org/2014/07/zero-downtime-deployment-avec-node-js-et-express-une-premiere-etape/
http://blog.helyx.org/#content
http://blog.helyx.org/page/3/
http://blog.helyx.org/2014/07/detecter-les-versions-depassees-de-vos-dependances-node-js/
http://blog.helyx.org/author/alexis-kinsella/
http://blog.helyx.org/page/9/
blog.xebia.fr

Informations Whois

Whois est un protocole qui permet d'accéder aux informations d'enregistrement.Vous pouvez atteindre quand le site Web a été enregistré, quand il va expirer, quelles sont les coordonnées du site avec les informations suivantes. En un mot, il comprend ces informations;

Domain Name: HELYX.ORG
Registry Domain ID: D91691035-LROR
Registrar WHOIS Server:
Registrar URL: http://www.ovh.com
Updated Date: 2017-02-21T16:08:10Z
Creation Date: 2002-10-29T20:37:19Z
Registry Expiry Date: 2017-10-30T19:37:19Z
Registrar Registration Expiration Date:
Registrar: OVH
Registrar IANA ID: 433
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Reseller:
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID: C189565106-LROR
Registrant Name: Alexis Kinsella
Registrant Organization: Alexis Kinsella
Registrant Street: 22, rue Mousset Robert
Registrant City: Paris
Registrant State/Province:
Registrant Postal Code: 75012
Registrant Country: FR
Registrant Phone: +33.177101001
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: gqemzhlqa46jt2bav487@j.o-w-o.info
Registry Admin ID: C189565108-LROR
Admin Name: Alexis Kinsella
Admin Organization:
Admin Street: office #87166
Admin Street: c/o OwO, BP80157
Admin City: Roubaix Cedex 1
Admin State/Province:
Admin Postal Code: 59053
Admin Country: FR
Admin Phone: +33.972101007
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: gtcvf97ba2qws0befh1a@u.o-w-o.info
Registry Tech ID: C189565108-LROR
Tech Name: Alexis Kinsella
Tech Organization:
Tech Street: office #87166
Tech Street: c/o OwO, BP80157
Tech City: Roubaix Cedex 1
Tech State/Province:
Tech Postal Code: 59053
Tech Country: FR
Tech Phone: +33.972101007
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: gtcvf97ba2qws0befh1a@u.o-w-o.info
Name Server: NS.OVH.NET
Name Server: DNS.OVH.NET
DNSSEC: signedDelegation
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2017-07-15T18:02:48Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

Access to Public Interest Registry WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to: (a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator, a Registrar, or Afilias except as reasonably necessary to register domain names or modify existing registrations. All rights reserved. Public Interest Registry reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy.

  REFERRER http://www.pir.org/

  REGISTRAR Public Interest Registry

SERVERS

  SERVER org.whois-servers.net

  ARGS helyx.org

  PORT 43

  TYPE domain
RegrInfo
DOMAIN

  NAME helyx.org

  HANDLE D91691035-LROR

  CREATED 2002-10-29

STATUS
clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
clientTransferProhibited https://icann.org/epp#clientTransferProhibited

NSERVER

  NS.OVH.NET 213.251.128.136

  DNS.OVH.NET 213.186.33.102

OWNER

  HANDLE C189565106-LROR

  NAME Alexis Kinsella

  ORGANIZATION Alexis Kinsella

ADDRESS

STREET
22, rue Mousset Robert

  CITY Paris

  PCODE 75012

  COUNTRY FR

  PHONE +33.177101001

  EMAIL gqemzhlqa46jt2bav487@j.o-w-o.info

ADMIN

  HANDLE C189565108-LROR

  NAME Alexis Kinsella

ADDRESS

STREET
office #87166
c/o OwO, BP80157

  CITY Roubaix Cedex 1

  PCODE 59053

  COUNTRY FR

  PHONE +33.972101007

  EMAIL gtcvf97ba2qws0befh1a@u.o-w-o.info

TECH

  HANDLE C189565108-LROR

  NAME Alexis Kinsella

ADDRESS

STREET
office #87166
c/o OwO, BP80157

  CITY Roubaix Cedex 1

  PCODE 59053

  COUNTRY FR

  PHONE +33.972101007

  EMAIL gtcvf97ba2qws0befh1a@u.o-w-o.info

  REGISTERED yes

Erreurs

La liste suivante vous montre les fautes d'orthographe possibles des internautes pour le site Web recherché.