Javascript

Javascript

Logger le contenu de vos objets avec Node.js

Logger le contenu de vos objets avec Node.js

Le contenu des logs est un élément essentiel de votre programme, bien souvent laissé de côté, il peut s’avérer précieux en cas problème.

En particulier, il arrive de vouloir logger le contenu d’un objet ou bien une de ses propriétés. Bien souvent, le premier réflexe sera d’en afficher le contenu en concaténant son contenu dans une chaine de caractère comme suit:

foobar = foo: "bar"
console.log "Contenu de la variable foobar: '#{foobar}'"

Malheureusement, le résultat ne correspond pas toujours à ce qu’on imagine:

Contenu de la variable foobar: '[object Object]'

Vu comme ça, on n’en fera pas grand chose si on met le nez dans les logs. Bien sûr, il est possible d’afficher la valeur de la propriété ‘foobar’ de l’objet:

console.log "Contenu de la variable foobar: '#{foobar.foo}'"

Le résultat sera un peu meilleur car on sera en mesure de logger la valeur de foo:

Contenu de la variable foobar: 'bar'

Dans notre cas, nous avons de la chance, car la variable ‘foo’ est de type String. Mais si la variable en question est un objet ou bien un tableau, nous tomberons sur le même problème.

JavaScript et Node.js nous proposent au moins deux solutions pour nous aider à produire un log convenable: La fonction ‘JSON.stringify’, et la fonction ‘inspect’ du module ‘util’.

JSON.stringify()

Bien connu dans le mode du JavaScript côté browser pour sérialiser le contenu d’une requête AJAX par exemple, on ne pense pas toujours à utiliser cette méthode pour sérialiser un objet ou bien un tableau JavaScript dans le but d’en logger son contenu:

console.log "Contenu de la variable foobar: '#{JSON.stringify(foobar})'"

On obtient déjà quelque chose de bien plus intéressant, c’est à dire un log avec un descriptif complet de l’objet au format JSON:

Contenu de la variable foobar: '{"foo":"bar"}'

Des objets plus complexes peuvent néanmoins devenir difficile à relire dans les logs, il ne faut donc pas hésiter à renseigner les informations de formatage du JSON lors de l’appel de la méthode ‘stringify’, qui permettent d’obtenir un log plus lisible avec un contenu bien indenté:

console.log "Contenu de la variable foobar: '#{JSON.stringify(foobar, undefined, 2})'"

ce qui donne:

Contenu de la variable foobar: '{
  "foo": "bar"
}'

Le dernier paramètre permet de spécifier l’indentation souhaitée.

La documentation complète de la méthode stringify peut être consulté sur le site de Mozilla: https://developer.mozilla.org/fr/docs/JavaScript/Reference/Objets_globaux/JSON/stringify

La méthode JSON.stringify peut être utilisée également avec des tableaux:

foo = [ "foo", "bar" ]
console.log "Contenu de la variable foobar: '#{JSON.stringify(foo, undefined, 2)}'"

ce qui donne:

Contenu de la variable foobar: '[
  "foo",
  "bar"
]'

Malheureusement, cela ne fonctionne pas avec les fonctions qui ne font pas partie du standard JSON:

bar = (foo, bar) -> "#{foo}-#{bar}"
console.log "Contenu de la variable foobar: '#{JSON.stringify(bar, undefined, 2)}'"

ce qui donne:

Contenu de la variable foobar: 'undefined'

Il ne faut pas oublier que nous détournons une fonctionnalité qui n’est pas spécialement faite pour le log au départ… Heureusement notre bonne vieille méthode toString() appelée sur la fonction nous sortira d’affaire:

console.log "Contenu de la variable foobar: '#{bar.toString()}'"

ou tout simplement:

console.log "Contenu de la variable foobar: '#{bar}'"

donne:

Contenu de la variable foobar: 'function (foo, bar) {
    return "" + foo + "-" + bar;
  }

util.inspect()

Le module util de Node.js fournit quelques fonctions intéressantes, dont la fonction: inspect. Elle permet de formatter un contenu de la façon que le réalise la fonction JSON.stringify que ce soit un objet ou bien un tableau. Elle a l’avantage d’être plus souple en proposant différentes options de sérialisation telles qu’une profondeur limite d’inspection ou bien encore la capacité d’appeler la méthode inspect() sur les sous-objets de l’arbre, lorsqu’ils la propose, afin de produire un contenu sérialisé spécifique.

Par exemple, les appels suivants:

util = require 'util'

console.log "Contenu de la variable foobar: '#{util.inspect(foobar)}'"
console.log "Contenu de la variable foobar: '#{util.inspect(foo)}'"
console.log "Contenu de la variable foobar: '#{util.inspect(bar)}'"

donneront:

Contenu de la variable foobar: '{ foo: 'bar' }'
Contenu de la variable foobar: '[ 'foo', 'bar' ]'
Contenu de la variable foobar: '[Function]'

Et la customisation de la sérialisation comme suit:

qix = { foo:"bar", foobar: { inspect: () -> "Some custom representation of foobar" } }
console.log "Contenu de la variable foobar: '#{util.inspect(qix)}'"

donnera:

Contenu de la variable foobar: '{ foo: 'bar', foobar: Some custom representation of foobar }'

On notera avec ce dernier exemple que la fonction util.inspect() n’a pas vocation à produire un JSON valide, mais elle produira par défaut une notation proche du JSON.

Il est possible entre autre d’afficher les propriétés non-enumerables d’un objet, de coloriser le résultat de l’appel ou bien encore de désactiver l’appel des inspections customisées sur les objets.

Pour approfondir: http://nodejs.org/api/util.html#util_util_inspect_object_options

Pour aller plus loin …

Sachez qu’il existe des modules Node.js dédiés à la sérialisation d’objets à des fins d’analyse. Par exemple, le module nodedump permet de logger dans une sortie HTML un tableau qui détaille le contenu de l’objet:

nodedump

Bien entendu, vous pourrez toujours préférer le debugger de votre IDE favori, son côté interactif apporte de nombreux bénéfices, et l’évaluation d’expressions se révèle être d’une grande aide:

debugger

QCon London – Développement Web mobile, Javascript et HTML5

QCon London – Développement Web mobile, Javascript et HTML5

Avec l’émergence de la mobilité dans notre quotidien, ce sont également de nouveaux besoins informatiques qui sont apparus dans nos SI. Au début, la problématique était simple puisque la plateforme iOS était sans concurrence. L’arrivée de nouveaux challengers a multiplié les nouveaux développements, et la fragmentation des développements est rapidement devenue un problème sérieux à adresser, voire même un véritable enjeu budgétaire: la fragmentation coûte cher et de prime abord ne semble pas toujours rentable à traiter. Certaines entreprises font ainsi le choix de supporter de nombreuses plateformes, tandis que d’autres ne supportent que le strict minimum, c’est à dire iOS et Android, voire même des fois uniquement iOS.

Avec l’avènement d’HTML5 et le bouillonnement actuel du web, des solutions innovantes ont commencé à pointer le bout de leur nez. Sont apparus tout d’abord des toolkits mimiquant l’interface utilisateur d’iOS, puis sont arrivés progressivement des frameworks plus ambitieux ayant pour objectif d’adresser ce problème de fragmentation. Le champion en la matière s’appelle jQueryMobile, il supporte la quasi totalité des plateformes mobiles à ce jour, et ses principaux concurrents sont Sencha Touch et Titanium d’Appcelerator. Même si ces outils sont relativement récents, ils permettent d’ores et déjà de développer des solutions sérieuses basées sur des technos web, et des nouveaux outils innovants fleurissent cette année à un rythme effréné (Rhodes, Jo, Wink, Dojo Mobile, Kendo, M Projecttrigger.io), ce qui montre une furieuse tendance à vouloir trouver des solutions à cette fragmentation via des standards déjà maîtrisés.

Il faut cependant reconnaître que ces idées sont nouvelles, et de nombreux gaps viennent compliquer légèrement les choses. A commencer par le fait que le parc mobile actuel propose des navigateurs plus ou moins matures, dont le support d’HTML5 varie de façon non négligeable selon la version de l’OS et le type de plateforme. Bien que les moteurs de rendu et de JavaScript des navigateurs mobiles évoluent de manière incroyable, tout comme leur matériel d’ailleurs, on est loin des performances natives de ces combinés. Il suffit pour cela de regarder la fluidité d’iOS pour s’en convaincre. Cela est toutefois à mettre dans la balance avec un univers web qui évolue (très) rapidement et qui chaque jour abat des barrières.

(suite…)

Annonce de jQuery Mobile

Annonce de jQuery Mobile

C’est une nouvelle qui va à coup sûr faire du bruit dans un monde du développement mobile déjà bouillonnant, puisque vient d’être annoncé la sortie pour la fin d’année de la version mobile du framework jQuery. Et ce n’est pas par la petite porte que le célèbre framework web souhaite faire son entrée, puisque contrairement à ses concurrents déclarés, tels que jQTouch ou bien Sensha Touch, jQuery Mobile se veut être un framework JavaScript ciblant la quasi totalité des plateformes mobiles web actuelles (Blackberry, Windows Mobile, iOS pour l’iPhone et l’iPad, Android, Symbian, Bada, …), et permettant de développer des interfaces riches capable de faire rougir bon nombre d’interfaces graphiques natives.

Avec l’avènement d’HTML5 (WebStorage, WebSockets, Vidéo, Géolocalisation, …), du CSS3, et des navigateurs mobiles dernière génération proposant des moteurs JavaScripts performants, la guerre du web semble se trouver un nouveau terrain de bataille, et le web mobile aura sous peu toutes les armes nécessaires pour déstabiliser le business modèle à peine naissant des Markets, tel que l’iTunes App Store ou bien l’Android Market. Le marché des applications mobiles semble donc suivre la voie de son grand frère, celui des applications PC, et proposera à terme de nombreuses applications riches directement par le web.

L’annonce parue sur le site de jQuery Mobile indique que l’un des objectifs du framework est de pouvoir développer une application unique pour toutes les plateformes mobiles. Ce concept, ne semble pas nouveau puisque l’objectif de J2ME sorti il y a 10 ans déjà était bien de développer une solution unique, rappelez-vous: « Write Once, Run everywhere ». Le slogan semble être ici: « Write Less, Do More », mais l’objectif de fond est bien le même.

Palm avec sa plateforme WebOS et Firefox sont déjà sponsors du projet. Bien qu’encore en développement intense, la sortie première sortie du framework est prévue pour fin 2010. Ce framework pourrait bien être une des grandes surprises mobile de 2010, et pourrait devenir très rapidement un framework incontournable pour le développement web d’applications riches pour mobile.

Pour en apprendre plus sur cette déclinaison de jQuery, vous pouvez suivre les liens suivants et apprécier les designs présentés :

ExtJS, une API de RIA sérieuse?

ExtJS, une API de RIA sérieuse?

Le framework ExtJS, est une librairie JavaScript destinée à la création d’interfaces utilisateur dont le résultat visuel est assez proche de celui d’Apollo. Ce framework présente l’avantage de ne reposer que sur des technologies standard W3C, donc nul besoin de runtime flash ou java. Cette librairie est sortie récemment en version 2 et semble très bien finie.

Un petit tour sur le site de l’éditeur vaut bien mieux qu’un long discours, je vous invite donc à aller y faire un tour :

Cette librairie est d’autant plus intéressante qu’elle propose une licence LGPL v3, ce qui facilite son inclusion dans de nombreux projets.

Je ne connais pas assez ce type de librairies, mais il se pose à mon avis le problème du référencement du contenu d’applications exploitant ce type de technologies, attention donc à l’utilisation que vous souhaitez en faire.

A mon avis cette librairiea un grand avenir, c’est à mon avis la meilleur librairie de RIA JavaScript à l’heure actuelle.

extjs.JPG

Parmis les autres librairies JavaScript incontournables du momenton notera également JQuery, Prototype ou bien encore Scriptaculous.