Liguoblog

jeudi 28 avril 2005

8ball preview

Voici une série de photos du prochain IDE de flash (8ball) avec quelques commentaires.

http://www.flashant.org/index.php?p=332&c=1

Ça va déchirer ! 8)

Java 5.0 update 3

Sun vient d'annoncer l'update 3 de J2SE 5.0.

Release Notes
Téléchargement

PS : Ceux qui ne font pas de Java, profitez en quand même pour faire l'update du JRE (machine virtuelle)

L

J'avais déjà lu quelque part sur le net que la longeur de nom de variable en ActionScript avait un impact direct sur la performance de l'exécution du code.  J'ai donc essayé de me défaire de mon habitude de nommé mes variable de façon explique, peut importe la longueur.

J'ai réussi à le faire sans trop de difficulté car c'était moins long à coder par la suite :P mais beaucoup plus difficile à relire. :S

Je commencais à m'ennuyer de mon ancienne habitude, c'est pourquoi j'ai fait un petit test maison pour connaitre la vérité :

Lire la suite

Informatif.org - wiki

Nicolas Coevoet de informatif.org à récemment installer un wiki à la base de son site. Les sujets principaux sont Flash - XHTML/CSS - PHP.  Il y des tutoriaux, code sources et liens utiles. De quoi pour plaire à tout le monde ! :)

Ça se passe ici.

Java PathFinder

La NASA vient d'annoncer la sortie du Java PathFinder. Il s'agit d'une machine virtuelle qui analyse le bytecode d'une application et trouve tout les chemins possible d'exécution afin de détecter les défaillances qui devrait s'y trouver. Disons que c'est encore assez limité pour l'instant, mais c'est extensible, donc ça devrait prendre de la maturité avec le temps.

Ça se passe ici.

jeudi 21 avril 2005

LineKiller

Voici une petite extension que j'ai faite pour Flash MX 2004. Il s'agit d'un outil qui supprime uniquement que les lignes de la sélection courante.

http://www.liguorien.com/download/LineKiller.mxp

J'espère que ça vous sera utile ! :)

JDK 6.0 build 32 ! :D

Je l'avais annoncé brièvement ici.  Je n'en ai pas reparlé depuis mais je suis tout de même le développement de près étant donné que le développement du JDK est maintenant plus ouvert que les versions précédentes.

J'ai enfin décidé d'essayé le build 32. Pourquoi le build 32 ?  Parce qu'il vient d'y avoir un changement majeur qui risque de changer l'opinion de beaucoup de gens sur la performance de Java pour les applications desktop. Le JDK utilisera dorénavant le DoubleBuffering pour la gestion de Swing. Donc il n'y aura plus de délai d'affichage lorsque une autre fenêtre sera par dessus celle écrite en Java.

J'ai essayé Netbeans avec le build 32 et je ne peux dire qu'une seule chose : ça déchire !!! 8) On a presque l'impression d'utilisé une application native. :)

Cependant ce changement entraine la modification d'environ 60 classes dont l'API publique est différente du JDK 5. Donc pas question d'avoir cette fonctionnalité dans le prochain update du JDK 5.

Source : java.net

mardi 19 avril 2005

JSFL : !Export in 1st frame

Le FLA sur lequel je travail présentement contient des centaines de symboles qui sont exporté pour l'ActionScript sur le premier frame. Afin de faire un preload potable, je ne dois pas les exporter sur le premier frame. L'idée de modifier tout les symboles un par un ne me plaisait pas trop... C'est alors que le JSFL est venu à ma rescousse ! 8)

Lire la suite

lundi 18 avril 2005

Array.push()

Flash me surprendra toujours ! Moi qui croyait que la méthode push() de la classe Array était plus performante que d'utiliser un index. Et bien mes tests prouvent le contraire ! :o

Lire la suite

mercredi 13 avril 2005

Maelstrom

Je n'en ai pas encore parlé sur ce blog. Hier soir j'ai reçu le dernier exemplaire du MX Developer's Journal dans lequel se trouvait un article sur le prochain Flash Player (Maelstrom). Certain sujets m'étaient déjà connu tandis que d'autres sont carrément nouveaux pour moi. C'est pourquoi je vous fait un petit résumé des points important de l'article.

Les efforts de l'équipe de développement sont concentrées sur trois thèmes :  performance, expressivité et standardisation.

Lire la suite

vendredi 1 avril 2005

StringBuilder

J'ai déjà mentionné dans ce billet que les performances de la classe String étaient vraiment mauvaise pour la construction d'une chaine de caractère avec l'opérateur +=. Je vous avais recommendé d'utiliser plutôt la classe StringBuffer pour ce type d'opération. Ce qui est (et reste encore) une bonne pratique.

Je viens tout juste de découvrir l'existance de la classe StringBuilder qui est livré avec le JDK 5.0.  

Encore une nouvelle classe ? Et pourquoi donc ?

C'est à cause que les méthodes de la classe StringBuffer sont synchronisées. Ce qui entraine forcément une baisse de performances...

Dans la majorité des cas, la construction d'une chaine de caractère se fait dans le corp d'une méthode, donc accessible seulement que pour un Thread singulier. Sun à donc décider de créer la même classe, sans la synchronisation.

Lire la suite