Le blog sur l’innovation tenu
par Colin Stewart a récemment posté un billet qui me rappelle fort
certains enseignements tirés des cours d’innovation que j’ai suivi à
l’Isep (dont il faudra que je vous parle un jour). Il analyse le succès
de Blizzard et du jeu World of Warcraft, et en tire 11 leçons sur
l’innovation
— qui sont en fait applicables à quasiment tout développement
informatique, voire industriel, voire quoi que ce soit. On trouve par
exemple des leçons comme “servez-vous des critiques”, “utilisez votre
propre produit”, “demandez la perfection”, etc., le tout détaillé et
expliqué. Mérite un coup d’œil, c’est très instructif.
11 innovation lessons from creators of World of
Warcraft
Dans cette chronique, je vais détailler mes expériences de développement
avec Flex, la technologie d’Adobe.
J’ai été promu il y a quelques temps grand
grand-manitou-chef-programmeur d’une association, Antigone, visant à
encourager l’apprentissage du grec ancien — et développant pour se faire
un logiciel d’apprentissage du grec ancien. Je suis donc chargé de
concevoir et développer ce logiciel.
Choix d’une technologie
Je suis parti sans idées arrêtées quand à la technologie à employer. A
vrai dire, je cherchais quelque chose de moderne et sympa : rien de pire
que de s’enferrer dans une technologie trop contraignante qui fait sans
cesse obstacle au développement. J’ai donc un peu tâté du côté de .NET
et WPF, en ayant plutôt de bons résultats.
Quoi qu’il en soit, les prérequis étaient les suivants :
- Portabilité : le logiciel doit fonctionner sous plusieurs OS,
dont un système libre (typiquement Linux).
- Personalisation : l’apparence du logiciel doit pouvoir être
facilement et fortement modifiée - pas de widgets natifs non
personnalisables, quoi.
- Multimédia : le logiciel doit pouvoir rendre des textes en
caractères grecs, enregistrer la voix, restituer du son et
éventuellement de la vidéo.
J’ai donc
commençé par quelques tests en utilisant
WPF : une technologie
moderne, souple, et basée sur .NET que j’aime bien. L’interface et les
widgets sont personalisables à loisir, il y a plein de capacités
multimédias, et des bibliothèques annexes le cas échéant. Bref, la
panacée — mais pas portable. Le .NET pur peut tourner sous Linux et Mac,
grâce à Mono, mais WPF reste pour l’instant du pur Windows. A exclure
pour des raisons de portabilité, donc.
XUL
m’a bien fait de l’œil : c’est la technologie derrière Firefox. J’y
avais un peu touché en écrivant mon extension pour Thunderbird, et, il
faut dire ce qui est, c’est fort sympathique — ainsi que très portable
et hautement customisable par un peu de CSS. Plus la possibilité de
programmer en Javascript, qui est un langage que j’aime bien. Seul
souci : les capacités multimédias. Pour en intégrer, il aurait fallu me
servir d’un plugin du type Flash, ou en recoder en C++. Bref, pour un
projet multimédia, j’avais moyennement confiance : j’ai fini par
l’écarter.
J’ai alors pensé à C++ : en
choisissant un bon système de widgets, cela devait être possible. Et
justement, Trolltech sortait en grande fanfare sont produit phare,
Qt 4.3. J’avais déjà jeté un
coup d’œil à Qt, qui est décidément une très chouette technologie,
vraiment agréable à manipuler ; c’est très portable, il y a quelques
capacités multimédias, et la personnalisation est hautement possible, à
l’aide de pseudo-CSS. Mais bon, le C++ n’est pas vraiment ma tasse de
thé — je préfère les langages d’un peu plus haut niveau, que ce soit du
genre Java/.NET ou plus genre script PHP/Javascript. Enfin pourquoi pas.
D’ailleurs, en y repensant,
il y avait Java. Proche de .NET, j’en avais déjà manipulé ;
portable, et relativement élégant. De plus, il y avait la possibilité
d’utiliser Jambi,
l’interface Java de Qt. Tous les avantages de Qt, plus du Java, donc :
pas mal. Cela dit, je connais plus .NET que Java ; cela donne souvent un
sentiment de plus grande propreté et modernité dans .NET que dans Java,
qui traîne quelques archaïsmes que j’avais moyennement envie de
retrouver. Rien de très concret, en tout cas ; c’était pour le moment
mon meilleur choix.
Flash, Flex et AIR
J’ai enfin regardé rapidement
du côté de Flex. Pour ce que j’en savais,
c’était une technologie similaire à XUL ou WPF, permettant de concevoir
des interfaces en XML et de les contrôler à l’aide d’un langage de
script. Basée sur Flash, je pouvais donc m’attendre à de la portabilité,
à une bonne personnalisation graphique, et à un très bon support
multimédia. En creusant un peu, j’ai confirmé ces impressions — et
surtout j’ai découvert AIR, à l’époque en version bêta.
AIR,
est principalement un enrobage d’intégrer du Flash dans des applications
de Bureau. L’emballage-desktop est très léger, il s’agit d’à peine plus
qu’un fichier de configuration détaillant le nom et la taille de la
fenêtre à employer ; AIR génère ensuite un exécutable, un installeur, et
permet de lancer son projet Flash dans une fenêtre. Du simple et du bon,
donc.
Concernant le développement concret en utilisant AIR, le développeur a
le choix entre trois technologies : XHTML/CSS, Flash ou Flex. Le XHTML
est ce qu’il y a de plus connu et de plus simple ; l’application est
alors rendue dans un navigateur embarqué. Le Flash permet d’héberger un
module Flash classique dans un conteneur AIR. Enfin, Flex permet de
créer une application riche en utilisant des fenêtres natives de l’OS.
La bibliothèque de contrôles utilisateurs disponibles avait l’air
importante, et les quelques exemples que j’ai téléchargé ont achevé de
me convaincre.
Conclusion
Finalement, AIR/Flex remplissait toutes mes contraintes, et me
permettait en plus d’utiliser une technologie moderne, des interfaces en
XML et du Javascript : tout pour plaire. Après beaucoup d’hésitations,
je suis donc parti là dessus.
Dans la prochaine chronique, je raconterai ma quête d’un framework MVC
pour Flex, qui soit à la fois léger et adapté à mes besoins.
En essayant de corriger le mapping de mon clavier sous Parallels, j’ai
dû chercher comment faire fonctionner toutes les touches d’un clavier
Mac sous Windows — que le clavier Mac soit intégré, USB ou virtualisé.
J’ai finalement retrouvé la configuration à installer pour parvenir à un
résultat parfait. Il s’agit d’un mapping créé par Florent
Pillet, qui s’installe facilement, et
s’active en suivant les instructions fournies. Et joie, Windows
reconnaît maintenant correctement toutes les touches du clavier :
l’arobase, les accolades, tout fonctionne. Si vous avez des pépins
d’interaction Mac/Windows, vous savez donc comment vous y prendre :)
La course à la première place
Hier, Opéra annonçait être le premier à passer le test
Acid3 à 100/100, talonné par
Safari à 98/100. Manque de chance, en corrigeant les deux derniers
tests, l’équipe de Safari a trouvé un bogue dans le test
Acid3 lui-même, qu’ils
ont signalé. Il a aussitôt été corrigé, faisant passer Opéra à 99/100…
et Safari à 100/100 ! On peut donc bien considérer que Safari a été le
premier à passer le test Acid3.
De plus, aucun des deux navigateurs n’avait un rendu parfait au pixel
près hier soir, mais Safari a corrigé
cela
dans la nuit. Maintenant, Safari passe donc le test à 100/100, avec un
rendu parfait, et surtout une build publique déjà disponible (Mac et
Windows). Vous pouvez donc télécharger cette nightly de Safari dès
maintenant, et confirmer chez vous que le test Acid3 passe bien — alors
qu’Opéra n’a encore publié que des captures d’écran. De plus, il est
également possible d’avoir la liste des bogues corrigés dans WebKit,
ainsi que le code source complet du moteur, pour vérifier la correcte
implémentation de cette mise en conformité des standards.
Les enjeux
De nombreuses personnes font remarquer que le test Acid3 ne teste que
certains points particuliers et souvent obscurs des normes en question.
C’est exact, et d’ailleurs les mêmes critiques avaient été formulées à
l’égard d’Acid2.
On ne peut cependant que constater l’amélioration du support CSS dans
les navigateurs suite au test Acid2 ; on peut espérer qu’il en sera de
même pour Acid3. D’autre part, comme le soulignait un commentateur de
Surfin’ Safari, le blog des développeurs de
WebKit, les tests Acid obligent les développeurs à se plonger dans les
normes des standards du Web, souvent pour la première fois. Il est donc
probable que de nombreux bogues soient fixés au cours du processus, en
plus de ceux strictement nécessaires au support des tests Acid.
Une bonne chose, donc — et puis cela encourage la compétition entre les
navigateurs, ce qui est toujours bon à prendre.
Je suis finalement passé à CarbonEmacs+Slime+OpenMCL comme
environnement de développement
Lisp,
et c’est tout chouette — bien plus que le petit éditeur de démo
d’OpenMCL. Editeur de code, interpréteur, animations et petites phrases
amusantes dans Emacs… Le pied. Merci à David Steuber pour son
excellent tutoriel sur l’installation d’un environnement Lisp sous Mac
OS X !
