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 !
Ca fait un certain temps que je fantasme sur
le
Lisp. Mais
cette fois ci c’est décidé, je m’y met : j’ai commencé à apprendre le
Lisp depuis quelques jours. Expériences jusqu’ici :
Le langage Lisp
A première vue, le Lisp est effectivement un chouette langage. C’est
encore très vivant, il y a plein d’implémentations et de bibliothèques
différentes, des bindings avec des tas d’autres langages — j’ai même
découvert des sites web dynamiques écrits en Lisp !
C’est un style de programmation assez différent (déclaratif au lieu
d’être fonctionnel), que l’on découvre assez agréable, élégant, et tout.
Il n’y a que quelques principes fondateurs, desquels tout découle, ce
qui rend le langage finalement assez facile à apprendre : rapidement, on
se retrouve à penser en Lisp plutôt qu’en fonctionnel.
D’autre part, tout le monde insiste beaucoup sur la grande flexibilité
de Lisp, et c’est vrai : on peut programmer autant en style fonctionnel
(boucles, déclarations de variables, etc.) qu’en style déclaratif — il
est également possible de faire de l’orienté objet ou aspect.
Les tutoriels sur le Lisp sont légion — mais un peu trop légion,
justement : on ne sait pas par quoi commencer. Voici une rapide
sélection de bons documents, pour débuter ou approfondir :
- Casting Spell in Lisp :
celui qui m’a fait démarrer. Un rapide tutoriel de quelques pages
sous forme de Comic book, qui présente le Lisp à travers la création
d’un petit jeu de rôle en mode texte, à base de magiciens, de
grenouilles et de bouteilles de whisky. Amusant et bien fait, il
présenter les concepts fondamentaux du Lisp par la pratique.
Vivement recommandé :)
- Learning Lisp
fast : une
bonne référence pour apprendre un peu plus en profondeur les
structures du Lisp, à l’aide de nombreux petits exemples.
Intéressant, quoique un peu plus proche de la collection d’exemples
que du cours organisé.
- Welcome to
Lisp : un livre
dont le premier chapitre, déjà très complet, est disponible en
ligne. Que le texte brut ne vous déroute pas, ce cours explique
vraiment bien les concepts fondamentaux du Lisp, et est une
excellente lecture une fois que l’on a tapé quelques exemples.
Quand au choix d’un interpréteur Lisp, j’utilise pour l’instant Clozure
CL, qui fonctionne sur tous les bons
Macs — mais il y a certainement plein d’autres bonnes choses.
Conclusion
Le Lisp mérite vraiment qu’on y jette un œil, même sans l’apprendre à
fond. C’est souple, puissant, et surtout sa réputation légendaire
d’élégance n’est pas usurpée. Et puis apprendre de nouveaux langages,
saybien :)
