Opera, éditeur norvégien qui développe le navigateur éponyme, vient de sortir en version alpha Dragonfly, un débuggeur JavaScript / DOM fort prometteur. Opera souffrait depuis un moment du manque d’un tel outil, voyons si l’attente en valait la peine…

Bien évidemment, on ne peut s’empêcher de penser à Firebug, une application similaire existant pour Firefox sous forme d’extension. Celui-ci, maintenu par un développeur de chez Facebook, a réellement changé la vie des aficionados du JavaScript tant il simplifie lé débuggage d’applications JavaScript / AJAX complexes. (pendant ce temps, les développeurs Flash attendent toujours un débuggeur décent…)

Notez que Microsoft prépare également un outil dans le style pour Internet Explorer 8.

Ce qu’il y’a d’important à retenir sur Dragonfly :

• l’appli est légère et assez réactive, contrairement à Firebug qui avait tendance à mettre Firefox 2 à genoux assez vite
• Dragonfly se comporte comme un application web et se met donc à jour automatiquement
• possibilité de débugger à distance, utile pour des terminaux mobiles ou des consoles (uniquement avec Opéra Mini pour le moment)
• mise à jour du DOM en live
• pas encore possible d’éditer le CSS à la volée, mais promis-juré c’est pour bientôt, qu’ils disent
• Dragonfly est open source (licence BSD) : un premier pas d’Opera vers le libre ?
• les gens d’Opera ont un accent rigolo.

Dragonfly est plutôt léché, mais n’offre en l’état pas grand chose de plus que Firebug. Ce n’est encore qu’une alpha et les gens d’Opera ont fait un tas de promesses alléchantes, donc wait and see…

“The initial alpha release is just the beginning. Opera Dragonfly has a fully featured road map, including support for editing of CSS, JavaScript and the DOM, a single window mode, improved JavaScript thread handling, XHR AND HTTP MONITORING, improved keyboard navigation, and translation into a number of languages.”

Dragonfly est livré avec Opera 9.5 beta 2. On accède ensuite à l’outil via Outils > Avancé > Outils de développeur, et ensuite il n’y a plus qu’à suivre le petit tutorial.

Le “oui mais t’a pas Firebug” étant généralement de mise lorsque l’on évoque Opera à un Firefox fanboy, voilà qui va peut-être un peu changer la donne et attirer un peu d’attention sur un navigateur qui le mérite largement (et qui passe le test Acid3, contrairement à d’autres…).

Le player Flash de debug en action, sur le site d’Adobe…

Adobe vient de publier un document fort intéressant intitulé « Flex SDK coding conventions and best practices ». Le titre est trompeur puisqu’il n’est point question de Flex mais bien d’AS3, ce qui est révélateur quand à l’obsession maladive d’Adobe sur Flex (au détriment de Flash en tant qu’IDE, oserais-je avancer). Plus généralement, cette louable initiative, parmi d’autres, tend à montrer à quel point la firme californienne cherche à se créer une crédibilité auprès des « vrais » développeurs.

La lecture ou au moins le survol de ce document est recommandé. C’est un condensé de bon sens qui tranche avec le grand n’importe quoi de l’AS1 et de l’AS2 (”monClip1_mc”, David T. style). Et celà peut servir d’arbitrage lors d’un désaccord entre développeurs.

Pour autant, on y relève un certain de nombres de passages un peu surprenants :

Tableaux typés

Do this:
var a:Array /* of String */ = [];
Not this:
var a:Array = [];

Étrange… Cette pratique rapelle la méthode utilisée à l’époque par le compilateur alternatif MTASC. Certes, c’est bien commode pour la complétion dans FlashDevelop par exemple, mais c’est en concurrence avec la méthode officielle Flex (lourdingue) : ArrayElementType metadata tag. La prochaine version de l’EcmaScript, et donc logiquement le futur AS4, integrera en natif les tableaux typés. En attendant, si on est courageux, on peut utiliser des classes de tableaux typés (MovieClipArray, etc) que l’on trouve dans pas mal de frameworks AS.

int plutôt que uint

Use int for integers, even if they can’t be negative. Use uint only for RGB colors, bit masks, and other non-numeric values.

Tout simplement absurde. Adobe préconise cette pratique en oubliant de préciser qu’elle découle d’un bug dans le player Flash : Types in AS3: ints not so fast, uints slow!

imports

Import specific classes, interfaces, and package-level functions rather than using the * wildcard.
Do this:
import mx.controls.Button;
import flash.utils.getTimer;
Not this:
import mx.core.*;

Mouais. Ou comment avoir 30 lignes d’imports au début de chaque classe. Je pense pas que ce soit très utiles pour les classes intrinsèques du player Flash (import flash.display.*; rules !)

À part ça, que du bon. À revisiter quand le document sera terminé.

Flex SDK coding conventions and best practices