Source

Ayant eu l’honneur et l’avantage de participer au BarCamp Summer Lyon, je vous propose un petit retour d’expérience sur cette excellente initiative d’un ensemble d’assoc’ actives de la région lyonnaise :

• Mix-IT
• LyonRB
• Club Agile Rhône-Alpes de Lyon
• Flex/Flasheurs
• MUG Lyon
• Lyon Java User Group
• Développeurs PHP de Lyon

L’objectif : donner l’opportunité à chacun de présenter un sujet qu’il connaît ou sur lequel il souhaite échanger librement. Les choix de sujets étaient proposés sur une base de volontariat, les sujets retenus votés à la gommette comme au bon vieux temps (comme on aime quoi).

Le public était quasi-exclusivement technique (à l’évidence), issus de SSII / éditeurs, et composé d’architectes, développeurs web, coach agile, chefs de projets, entrepreneurs…

En résumé, un bon rythme, des sujets « en vogue » avec échanges constructifs sur les intérêts / risques de chaque techno ou méthodo.

Voici un rapide retour sur les thématiques auxquelles j’ai assisté, pour alimenter la discussion et inviter à poursuivre cette initiative !

DevOps

En tant que newbie du sujet, j’ai cerné DevOps comme consistant en un ensemble de pratiques et principes d’échanges pour une meilleure communication entre équipes infra / support et équipes de développement. Ces principes se déclinant en :

• organisation projet,
• modes de communication,
• outils.

Une forte composante de cette méthodologie réside dans les deux premiers points : comment briser les barrières entre équipes de support, administrateurs système et équipes de développement. Cette cassure visant à impliquer chacun dans le process projet et fluidifier les échanges.

Pour cela, la méthodologie intègre fortement les principes de l’agilité, suggère une fréquence élevée de livraisons etc. … Pour plus d’infos, je vous invite à consulter l’article DevOps sur Wikipedia (anglais).

Niveau outils, nous avons échangé sur les systèmes d’intégration continue et de déploiement automatisé (installation et configuration de machine en un clic).

Un retour a été donné sur les outils suivants :

• Puppet (Ruby) : assez simple à prendre en main, grosse communauté
• CFengine : performant mais peu de retours d’expérience et pas d’interface graphique
• chef (beaucoup plus complexe)

Une limite signalée à propos de ces outils touche principalement les entreprises « désossant » les paquets standards selon leur propre norme, ne laissant donc on ne peut plus utiliser les paquets standards. C’est toujours bon à savoir

Les avantages sont en revanche multiples :

• Le versionnement d’un script puppet rend extrêmement simple toute procédure de retour arrière (rollback) sur le serveur.
• La montée en volume d’un parc de machines hébergées en interne devient un jeu d’enfant
• On peut aller jusqu’à envisager les backups (machine, données, sources)

L’administrateur déporte donc son travail sur l’outil puppet plus que sur le serveur lui-même, transformant son métier plutôt que l’annihilant (et au passage le rendant plus intéressant ? On aime bien ne faire les choses qu’une fois en général ).

D’un point de vue humain, un principe intéressant consiste à intégrer les équipes de support et d’administration le plus tôt possible dans les phases de conception d’un projet pour intégrer au mieux leur contraintes, et simplifier les échanges ultérieurs. En résumé, comprendre les problèmes des autres permet souvent d’y apporter une solution simple à laquelle on n’aurait jamais pensé. Ca paraît évident à dire, moins à faire !

Nous avons enfin échangé sur des problématiques comme :

• Combien ça coûte ? Quelques tuyaux résident dans le chiffrage :
  • A priori : estimer le gain sur la maintenance (très difficile)
  • A posteriori : estimer le gain en comparaison avec un autre projet (techniquement plus simple, mais souvent négligé voire oublié selon la coutume « ce qui est fait est fait »)
• Décloisonner demande un état d’esprit ouvert : lorsque les tensions sont déjà fortes, il y a fort à parier que la mayonnaise ne prenne pas

Et vous, êtes-vous DevOps ?

TDD / BDD

Source

Sans revenir trop longtemps sur le Test Driven Development et sa clique (JUnit, DBUnit, NUnit, FlexUnit, PHPUnit…), nous avons abordé un nouvel acronyme pour moi : BDD (Behavior Driven Development), dont le principe est bien mieux expliqué sur Wikipedia que je ne saurais le faire.

Le retour d’expérience a été donné principalement sur JBehave qui propose de rédiger des exigences sous forme de fichiers au format texte comprenant trois mot-clés principaux : GIVEN (définir une situation) WHEN (définir un événement déclencheur) THEN (définir le résultat attendu). Les phrases pouvant être rédigées comme vous le souhaitez.

L’idée diabolique est donc d’obtenir ce fichier d’un interlocuteur fonctionnel, que vous pouvez utiliser sans transformation pour développer des routines correspondant à chaque exigence et ainsi valider que votre programme y répond.

Même si (à mon humble avis) cette méthodologie demande un interlocuteur métier motivé – pour ne pas dire un « consultant AMOA ultra au point » – et certainement d’éliminer quelques freins, le principe d’alléger vos spécifications et de retrouver (par un heureux effet de bord) vos exigences dans votre code source est clairement intéressant. Je m’interroge également sur le glissement vers « l’algorithmie masquée » que peuvent représenter les fameux fichiers textes… Vaste programme.

Amis flexeurs, quelques early-adopters ont déjà expérimenté le principe basé sur Cucumber (Ruby). Si ça vous dit… En attendant, si vous faites du FlexMock, FlexMonkey et FlexUnit, c’est déjà pas mal !

Un petit regret, la difficulté d’aborder la question du « où s’arrêter » en fonction du projet mené : est-ce toujours rentable d’avoir une couverture de tests à 100% si votre projet a une durée de vie limitée… Même si cette question est particulièrement sujette à l’appréciation de chacun sans réellement connaître de règle.

Des spaghettis, des marshmallows

Source

Le dernier atelier reprenait le concept du marshmallow challenge.

Le principe : 18 minutes pour construire la plus haute tour de spaghettis surmontée d’un marshmallow avec comme accessoires du scotch et un fil de couture.
L’objectif : souligner la façon dont nous travaillons en équipe, dont nous fonctionnons face à un problème… Les résultats sont intéressants, je vous invite à tenter le coup si vous en avez l’occasion.

Je n’ai pas la photo de notre oeuvre éphémère… Mais ne regrettez rien

Merci à tous les organisateurs donc, à quand le prochain ?Autres articles sur le même sujet

• Le 8ème jour ils créerent le Volume
• Vous avez dis Flex3 Beta2 ?
• L’université Lyon1 cherche (aussi) 2 stagiaires
• ORM, Hibernate et contrariétés…

Que vous soyez acteurs dans les nouvelles technologies ou simplement curieux de voir ce que le présent nous réserve, vous êtes conviés à venir participer au 1er BarCamp dédié aux Interfaces Riches, le 23 juin 2010 à partir de 17h, au cyberCafé du campus de la Doua à Villeurbanne.

Au programme : des conférences, des ateliers et des démonstrations de ces technologies naissantes ou déjà matures et de leurs usages dans différents domaines (commerce, enseignement, divertissement…). Aux côtés des principaux innovateurs de ce secteur, vous pourrez même, si vous le souhaitez, proposer votre propre présentation dans les tribunes libres prévues à cet effet.

Quelques présentations au menu :

• Nouvelles expériences utilisateurs multi-canal grâce aux RIA (ipTv, bornes interactives);
• OpenScales: client cartographique basé sur les technologies ActionScript3 / Flex / AIR;
• Comment développer une RIA moderne en Javascript avec RESTHub.

Rendez vous, donc, le 23 juin 2010 pour une rencontre conviviale qui vous donnera l’occasion de découvrir ou de montrer dès aujourd’hui, les interfaces de demain.

• « Flash In The Can » : hymne a l’AS3
• Virtual Cabinet, flash et interfaces riches pour l’apprentissage des langues (3)
• Interfaces tangibles : le futur du multitouch
• Barcamp Lyon : Mix-IT, Flex, Java, PHP, JS, Cloud… (et chips)

Voilà un résumé de la première journée : une énorme keynote, quelques conférences plus ou moins intéressantes…

La Keynote

La volonté d’Adobe d’être présent sur tous les écrans, quelque soit leurs tailles et leurs résolutions. Ça ressemble presque à une déclaration universelle. On se rappelle de l’annonce en mai 2008 de l’open screen project qui, à l’époque, laissait pas mal de place à la spéculation. Aujourd’hui, les choses se mettent en place… Pas moins de 42 partenaires dont Google, RIM, HTC, Docomo… et des annonces qui permettent de mieux comprendre où Adobe veut aller.

Le flash player 10.1.

Quelques nouvelles fonctionnalités comme le support du Multitouch, un meilleur support du P2P mais surtout un énorme travail sur les performances du player afin que ce dernier puisse tourner sur les mobiles et les notebook.

• Réduction de l’empreinte mémoire du player
• Meilleur gestion de la consommation électrique
• Amélioration du rendu et des performance vidéo

Tout porte à croire qu’on assiste à la fin de FlashLite… On va enfin avoir le même player partout et tout le monde pourra avoir la même expérience quelque soit le terminal.

AIR 2.0

Adobe semble avoir écouté un peu la communauté. Pas mal de nouveautés et d’améliorations concernant l’intégration et la communication avec le système. Avec cette version, un développeur AIR va pouvoir facilement développer de l’application native Mac, PC, ou Linux, en fonction de son système.

• Possiblité de lancer et discuter avec des process natifs
• Support des unités de stockages (et de leur branchement)
• Prise en charge du multiTouch
• Accès au données du microphone.

Les outils de la Flash Platform

FlashBuilder se positionne comme un éditeur de code avancé pour ActionScript, y compris quand on développe en flash. Adobe a donc amélioré les liens entre ces IDE pour faciliter les aller-retour. Idem avec Flash Catalyst qui se positionne comme un outils à deux faces.

Faciliter l’intégration d’un design provenant d’un produit Adobe et faire le pont entre designer et développeur (avec un format de projet commun)

Permettre de faire du prototypage rapide d’interactions (l’équivalent de ce qu’offre Fireworks en terme de prototypage de site web)

L’iPhone

Un des grands absents de l’Open Screen Project est en effet Apple. Adobe ouvre enfin la porte du temple de l’iPhone à ses développeur en permettant d’exporter ses application flash au format iPhone. On est encore loin du flash dans l’iPhone mais c’est quand même un premier pas. (Bientôt) fini donc, XCode et Mac pour faire des applications iPhone… En ça aussi, c’est plutôt une bonne nouvelle. Concrètement, Adobe est parti sur LLVM (qu’il utilise déjà pour Alchemy). Pour plus de détails voir cet article.

Et la Creative suite dans tout ça…

Comme l’année dernière à Milan, on nous parle vite fait de la Creative Suite.

Le producteur d’Avatar, le prochain film de James Cameron, présente comment les différents outils de la suite interviennent lors de la création d’un film comme Avatar, de la création des textures 3D sous Photoshop à la post production avec AfterEffects.

Et parce qu’on a été sage, on a droit à quelques scènes d’avatar en 3D… Ca promet !

Conclusion

Un mot-clé : « multi » ;

• multi-écrans (Open Screen),
• multi-cast (P2P),
• multi-touch,
• multi-langues (TLF),
• multi-disciplines (création, développement).

Le tout en se donnant les moyens de faire fonctionner tout ça : AIR 2.0, Flash Player 10.1 et amélioration des outils vers plus de productivité.Autres articles sur le même sujet

• Live from MAX Milan : hands on thermo…
• MAX 09 – Le multitouch
• MAX 09 – Où est passé le Text Layout Framework ?
• MAX 09 – Sneak Peeks !

Ah oui, au fait, juste avant de commencer : un mot sur les Awards. Nous avons eu droit à une présentation des MAX Awards par Mark Hamil juste avant la session Sneak Peeks. On ne reviens pas dessus tellement nous avons trouvé ça pauvre en information. Nous sommes certains que les projets choisis sont effectivement géniaux, mais nous n’avons vraiment pas eu l’occasion d’en voir suffisamment et d’en entendre parler leurs concepteurs pour se faire une quelconque idée de la chose.

Voici plutôt un aperçu de ces Sneak Peeks particulièrement intéressants sur les innovations en cours chez Adobe. Le principe est simple : prenez Mark Hamil (Luke Skywalker pour les intimes) comme présentateur qui ne comprend rien aux technologies montrées, déguisez les ingénieurs Adobe en chevaliers de l’empire, Chewbacca ou princesse Leïa et vous obtenez un show de geek vraiment sympa et impressionnant.

Principe

Chaque équipe passe présenter son projet et doit rivaliser d’idées innovantes pour obtenir les clameurs de la foule en folie. Ca va vite, ils font souvent des blagues et vont parfois jusqu’à scénariser la présentation. C’est vraiment excellent ! Les infos passent très bien, on ne s’ennuie pas… Voyons voir.

Mobile

L’équipe mobile nous a présenté un jeu multi-joueurs utilisable depuis différents terminaux mobiles (Palm, Google Android, Nokia…), une application AIR sur portable et en mode web sur PC. Le principe technique est que ce jeu s’exécute côté serveur et que les images du jeu sont envoyées en streaming sur les terminaux (un peu comme une vidéo YouTube). Chaque commande est également envoyée au serveur pour lui permettre de calculer le comportement attendu pour le joueur.

Même si la technicité est certainement élevée et innovante, la pauvre bande passante du Wi-Fi disponible a montré les lacunes de l’outil. L’intérêt reste à notre sens assez limité, bien que nous ne soyons pas des spécialistes du jeu en ligne. On salue quand même la performance (faut le faire non ?)

Flash

La démo Flash est assurée par Chewbacca en personne. Il nous montre comment la future version de Flash Professionnel permettra de générer des animations de formes à l’aide d’un moteur physique pour leur donner un aspect particulièrement réaliste. L’exemple ci-après est réalisé à partir de dessins de formes vectoriel et d’activation de quelques cases à cocher…

On vous laisse imaginer les possibilités offertes au designer pour réaliser des animations réalistes et relativement complexes en quelques clics, c’est vraiment intéressant pour le monde de la création.

Flex pour mobile

Cette fois, c’est princesse Leia qui procède à la présentation d’un développement en environnement Flex avec le framework mobile. Concrètement, il/elle utilise des composants liste et champ de recherche, compile et lance une application ressemblant plus que fortement à une application iPhone de recherche et affichage d’informations.

Le résultat, affiché sur un iPhone (forcément…), est particulièrement réussi, très réactif. C’est impressionnant, en tant que développeurs Flex de voir la simplicité du développement Flex apportée sur un environnement de ce type !

Photoshop

On ne sait plus à quoi s’attendre sur Photoshop. Le logiciel vit depuis un certain temps, et pourtant cette présentation nous a laissé sur le c… pardon, pantois.

Concrètement, l’équipe a travaillé sur une fonctionnalité de gommage intelligent (mathpatch), interprétant la globalité de l’image pour remplacer le contenu supprimé par un contenu particulièrement réaliste. Le résultat est absolument hallucinant. Vous pouvez supprimer le fameux fil électrique qui rature le beau bâtiment à présent.

Ce fonctionnement a carrément été appliqué à des parties d’images : la démonstration montre le conférencier supprimer une usine de la vue de la photos. 20% de l’image est recomposée automatiquement. On constate déjà un peu plus l’intervention de la machine, mais en faisant attention. Bluffant !

Fireworks

L’équipe Fireworks a présenté une fonctionnalité de retour arrière sur ses actions de manière ciblée. Concrètement, vous travaillez sur une partie de votre image, puis une seconde et ne voulez annuler que les changements effectués sur la première partie, mais pas sur la seconde, vous pouvez sélectionner ladite première partie et annuler uniquement ces changements : particulièrement pratique pour les designers habitués à ce genre d’outils !

Dreamweaver

Nous n’avons pas particulièrement l’utilisation de Dreamweaver habituellement, mais on retient cette démonstration, particulièrement intéressante pour l’utilisation de la nouvelle norme HTML 5.

En l’occurrence, une nouvelle spécification est sortie (HTML 5) intégrant notamment un notion de Canvas, des interactions et animations pouvant être définies pour ce canvas. Adobe montre une forte volonté de tirer partie de cette nouvelle solution en permettant un copier coller depuis Flash dans Dreamweaver d’une animation Flash, Dreamweaver la transformant en animation native Canvas.

L’intérêt ? Pas de Flash Player, des performances excellentes, et une adéquation parfaite aux standards. Une excellente initiative pour tenter de se rapprocher du standard plutôt que chercher à l’évincer.

AIR : Rome

Attention, énorme application. Le conférencier nous présente un outil à l’ergonomie particulièrement réfléchie et léchée regroupant en quelque sorte le principale de chaque outil d’Adobe. Vous pouvez dessiner en vectoriel (Illustrator / Fireworks), ajouter des animations (Flash), importer des calques Photoshop, ajouter des écrans et créer une interaction type navigation entre écrans (Flash Catalyst).

Enfin, vous pouvez exporter votre travail en SWF, AIR, SVG, image, page HTML, PDF… Tout cela étant, également fonctionnel en mode Internet : il y avait de la bave sur les sièges…

Pour nous, c’est le vainqueur. C’est absolument impressionnant à voir ! Ca montre notamment les capacités offertes par AIR et confirme son positionnement sur une application Internet mêlée à une application de bureau.

Autres articles sur le même sujet

• Du HTML dans mon Flex…
• Live from MAX Milan : hands on thermo…
• MAX 09 – Le multitouch
• MAX 09 – Ça annonce !

Un conférence sur le multitouch, un thème qui nous tenait à coeur pour cet événement !

MAX a été l’occasion pour Adobe d’aborder le multitouch de manière plus détaillée. En effet, le matériel commence à devenir disponible pour le grand public et le succès de l’iPhone montre déjà l’intérêt des utilisateurs pour ce type d’interactions et la nécessité d’anticiper cette composante dans la conception des nouvelles Interfaces Homme Machine.

Nous résumerons ici deux conférences auxquelles nous avons pu assister : la première « officielle » assurée par une personne du groupe Cynergy, relativement générale et montrant quelques exemples intéressants. La seconde, appelée « unconference », assurée par une personne d’Adobe, en charge de la prise en compte du multitouch au niveau du Flash Player 10.1, celle-ci plus technique et orientée sur les bonnes pratiques, particulièrement intéressantes.

Essayons de ressortir les principales idées et conclusions de tout cela.

La présentation s’articule autour des axes suivants :

• Matériel et principaux environnements de prise en charge, à disposition du grand public
• Types de mouvements reconnus nativement sur ces matériels
• Implémentation avec AIR 2.0 et bonnes pratiques

Matériel et principaux environnements

Aujourd’hui, le multitouch est accessible au grand public via :

Types de mouvements et informations reconnus

• Natifs
  • Zoom,
  • Swipe (action de faire glisser à deux doigts),
  • Rotation
  • Taille d’appui sur l’écran
• Personnalisés (permet d’implémenter ses propres interprétations de mouvement)

C’est peu mais suffisant pour la plupart des actions connues.

On regrettera le fait que seul un mouvement natif est reconnu par le système à la fois, impliquant qu’on ne peut zoomer et faire pivoter un élément en même temps. Il faut dans ce dernier cas se débrouiller.

On appréciera aussi le fait que le « standard » établi par l’iPhone se retrouve dans les mouvements reconnus et pris en charge pour tous ces systèmes. A savoir que les mouvements natifs ne peuvent être utilisés en concurrence avec les événements personnalisés. Aussi, soit vous faites du natif, soit vous vous démerdez… Why not !

Implémentation avec AIR 2.0 et bonnes pratiques

La nouveauté est que AIR 2.0 écoute les événements envoyés par les systèmes multitouch et offre une API assez simple permettant d’y réagir. nous ne rentrerons pas dans les détails, mais plusieurs choses doivent être prises en compte avec attention pour produire une « bonne » application multitouch :

• Il est important de pouvoir gérer les événement Souris et les événements Touch de manière unifiée pour que l’application reste compatible avec un système standard. N’oublions pas que le multitouch est loin d’être encore accessible à tous
• Il faut penser à la taille des doigts : un bouton sera certainement plus gros dans une application multitouch, l’homme étant moins précis que la souris (désolé pour la blague de geek).
• De ce fait, il faut idéalement être capable d’adapter son application à des résolutions différentes : certaines applications multitouch prennent tout leur sens sur des écrans très grands (table type Microsoft Surface), mais peuvent être amenées sur des écrans plus petits (tablet PC par exemple). Selon la résolution cible, un pixel n’aura absolument pas la même taille et l’application pourra devenir totalement inutilisable
• Utiliser un gestionnaire personnalisé d’interprétation de mouvement en ActionScript (type touchLib) se révèle être une solution généralement plus flexible voire performante que l’usage de la détection native de mouvements simples. D’autant plus quand on repense à la restriction de non parallélisation de mouvement natifs simples (zoom + rotation).

Conclusion

Nous arrivons à un moment où les outils se présentent pour proposer des interface apportant réellement quelque chose en terme d’innovation et d’interactivité. C’est donc naturellement qu’Adobe s’insère dans cette voie et propose de reprendre la main sur les technologies déjà existantes dans ce domaine (type TUIO, touchLib…) et se tient prêt pour le matériel de demain !

A quand les éléments tangibles dans les boutiques Adobe ?

À noter : vous pouvez retrouver  les conférences sur le multitouch, sur Adobe TV :

• Multitouch Development with flex
• Multitouch and the flash plateform

Autres articles sur le même sujet

• MAX 09 – Où est passé le Text Layout Framework ?
• MAX 09 – Sneak Peeks !
• MAX 09 – Ça annonce !
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher

Une seule session concernant TLF ! “Sold out” très rapidement, et j’ai eu la chance d’avoir une place. Première impression à l’arrivée: je suis impressionné par la nombre de personnes en attente d’une place : un tas de gens s’agglutine devant la porte en espérant pouvoir entrer. Ok ! Je me faufile et j’entre… dans une toute petite salle !

Petit rappel

Le Text Layout Framework (TLF pour les intimes) est le nouveau framework proposé par Adobe pour la gestion de texte international. Un soin particulier a été apporté au sens de lecture, et même aux ligatures de texte dynamique, le tout pour obtenir un texte le plus lisible et utilisable possible.

Les liens :

• Trouver TLF :
  • TLF sur le labz d’adobe
  • TLF en open source
• Quelques exemples :
  • PageLayout Project : Une librairie, powered by Me, qui permet la création et le développement d’éditeur riche (On en reparle bientôt ! ).
  • Times Reader : une application AIR que l’on ne présente plus !

En bref

L’ambiance est survoltée : beaucoup de représentants de pays oubliés dans la gestion actuelle de texte de Flash. Les gens sont contents ! Enfin ils vont pouvoir faire du joli Flash en arabe ou en langue asiatique, le tout supporté par un framework Adobe. C’est pas trop tôt !

Je ne reviendrai pas sur ce framework en profondeur, mais plutôt sur les outils mis à disposition dans Flash CS5. Outre toute la gestion de texte que permet TLF (conteneurs liés façon InDesign, texte ligaturé, multi-colonnes, gestion des langues arabe, asiatique, hébreux, … ), la team a développé des outils très pratiques. Je retiens le nouvel outil d’import de polices spécifique à TLF, qui permet une gestion fine des polices, avec à la sortie un joli package SWZ. Que du bon.

En conclusion

Mais pourquoi diable Adobe n’a pas parlé de ce framework aux keynotes ? Peux être que le texte n’est pas vendeur… Il n’empêche que 2 phrases d’annonce n’allaient pas exploser le timing.

En y regardant bien, Adobe a potentiellement créé un système qui d’une part les propulsent bien en avance par rapport à la concurrence. D’autre part, cela leur permet de s’ouvrir un marché immense! Le monde asiatique, arabe… qui vont ENFIN pouvoir utiliser les technos Flash, avec un vrai système porté et validé par Adobe.

Et je ne parle pas du monde de l’entreprise en général, la gestion de texte dans les CMS en particulier, qui est une vrai problématique ; et qui à l’heure actuelle est plus une bidouille qu’autre chose lorsque l’on veut une gestion fine de son texte… TLF ouvre des portes sur le développement d’outils WYSIWYG type Buzzword, et propose une vrai réponse à ces problématiques.

Alors Adobe ? Pourquoi ne rien dire ?

[Update]

Adobe vient de poser la video de la session… Ça rattrape un peu !
Autres articles sur le même sujet

• Live from MAX Milan : hands on thermo…
• MAX 09 – Le multitouch
• MAX 09 – Sneak Peeks !
• MAX 09 – Ça annonce !

Alors le multitouch remplaçant de nos bons vieux claviers / souris ? Pas si sûr ! Pour certains acteurs cela ne fait pas de doute. Pour d’autres en revanche, ces interfaces ne sont que des périphériques supplémentaires, un moyen différent de « consommer ».

Imaginez manipuler un fichier Excel en multitouch… Ça risque d’être assez pénible ! Pour peu que l’on soit un accro des macros ! (bon moi je m’en fou je fais pas d’Excel). Et puis pour l’instant ça fait mal aux doigts ! A force de gesticuler autour de sa table 50 pouces, on prend des crampes…

D’accord mais c’est bien le multitouch ! LA solution ? Les pseudo claviers / souris comme périphériques physiques de la table. Imaginez un clavier souple ou une souris transparente en plexiglas : pas d’électronique dedans, et tout de même repérés par la table. Un peu comme les tables tangibles, reconnaissant des périphériques électroniques (appareils photos…), ou des périphériques de soirée (un verre…) ou n’importe quoi qui possède un tag RFID. RFID ou bien par une forme particulière : on peut imaginer des objets de formes différentes, qu’une analyse d’image peu détecter.

slap widgets demo

Plusieurs groupes travaillent sur ce type d’interfaces tangibles : le MIT avec le groupe Tangible Media Group, le Media Computing Group, un groupement de recherche des universités allemandes, avec le projet SLAP : Silicone Illuminated Active Peripherals.

Et ce n’est qu’un début ! Le monde de la musique dispose déjà d’interfaces tangibles.

[update] Do you want more ?
Pattie Maes, du Fluid Interface Group – MIT, à présenter en février dernier leur dernier jouet : « the SixthSense » : Minority Report en vrai. Pourquoi avoir un périphérique alors que ses doigts c’est si bien ?!

Ils sont aussi à l’origine du projet fou Siftables

Je vous invite vivement à découvrir l’ensemble des projets de ce groupe : il y a là de quoi rêver sur l’avenir des interfaces !
[/update]

Et là oui ! J’imagine mieux Excel en multitouch !
A suivre de près donc… A quand un docteur maboul virtuel tangible ?
Et vous, des idées ?Autres articles sur le même sujet

• Un curseur… des curseurs ???
• MAX 09 – Le multitouch
• Caresse-toi le flex : FlashPlayer 10.1 et Multi-toucher
• BarCamp interfaces riches, Lyon, 23/06

Vous venez de créer votre douzième workspace Eclipse/Flex Builder ??? Et vous en avez marre de recréer vos perspectives, et autres vues… à chaque fois ???

Mais pourquoi diable n’utilisez vous pas les « fameux » ‘working sets’ ?

Et puisque quelques pixels valent pleins de mots…

Les working sets ( prononcez ‘setss’ )… tout simplement la solution moderne aux problèmes de congestion de projets dans Eclipse & Flex Builder !Autres articles sur le même sujet

• WTP – Flex Buider : résoudre les problèmes de mémoire
• L’erreur est humaine… debuguer un projet Flex distant via Flex Builder
• Flex Builder 3 et le PHP ( PDT ) : installation
• Flex et les warnings inutiles…

Autres articles sur le même sujet

• Buzz à Max…
• retour sur Lafabrick @ max
• wiiFlash et 3d à l’université
• wiiFlash à l’université : acte 2

Si ce n’est déjà fait, je vous laisse jeter un œil sur la première partie de cette architecture, et de récupérer le swc avant de lire la suite.

A quoi ça sert l’IOC ?

L’IOC ( Inversion Of Control ) est un patron d’architecture, possédant plusieurs représentations ( inversion de contrôle, injection de dépendance, …). Je ne vais pas faire un cours sur l’Injection de contenu : je vous laisse voir ici pour plus d’informations.

Dans Reflex, le but du package IOC est de décentraliser les objets de configurations de l’application. En gros, mettre les services d’accès aux données dans un fichier de configuration XML au lieu de les coder en dur dans l’application Flex.

Certains spécialistes me diront certainement que l’Injection de contenu n’est pas forcement une représentation de l’IOC, et donc un abus de langage pour Reflex : je répondrais par “traduisez ici IOC par Injection Of Content, et laissons tomber les patrons d’architecture !”.

Au commencement, le ServicesLocator

Nous avons vu dans la première partie comment réaliser simplement un appel à une méthode distante. Avoir un point d’accès global aux différents services est pratique lorsque l’on commence à avoir plusieurs services, ou si des vues différentes utilisent un service identique. Voyons comment procéder avec le premier exemple.

Reprenons l’exemple du tuto #1 : il faut charger les services dans le ServicesLocator. Nous allons donc modifier notre vue :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="absolute"

	creationComplete="init()"

	xmlns:controller="controller.*"
	xmlns:model="model.*">

	<mx:Script>
		<![CDATA[
			import com.lafabrick.reflex.service.ServicesLocator;

			public static const SERVICE_USER:String = "userService";
			public static const SERVICE_OTHER:String = "otherService";

			private function init() : void
			{
				ServicesLocator.addService( SERVICE_USER, remoteUser );
				ServicesLocator.addService( SERVICE_OTHER, remoteOther );

				userControl.service = ServicesLocator.getService( SERVICE_USER );
			}

		]]>
	</mx:Script>

	<mx:RemoteObject id="remoteUser"
		destination="javaFacadeUser" showBusyCursor="true" />

	<mx:RemoteObject id="remoteOther"
		destination="javaFacadeOther" showBusyCursor="true" />

	<controller:UserController id="userControl" />

	<model:UserModel id="userModel" />

	<mx:VBox>
		<mx:TextInput id="login" />
		<mx:TextInput id="password" displayAsPassword="true" />

		<mx:Button label="connect"
			click="{userControl.login(login.text, password.text)}" />

		<mx:Label x="208" y="44"
			text="User Name : {userModel.userLogged.name}"/>
	</mx:VBox>

</mx:Application>

• À la création de l’application ( creationComplete ), nous déclenchons la fonction init();.
• Nous ajoutons les services RemoteObject dans le ServicesLocator. La signature de cette méthode est la suivante :

  ServicesLocator.addService( serviceName:String, serviceObject:AbstractService )
  

   

  • 



serviceName:String est le nom de référence utilisé pour indexer, et plus tard retrouver le bon service.
  • serviceObject:AbstractService est l’identifiant (id) de l’object service (le RemoteObject).

• Nous supprimons la propriété service dans la déclaration mxml de UserController, pour la déclarer en ActionScript dans la fonction init(). 

ServicesLocator.getService( serviceName:String ) renvoie l’instance du service défini par serviceName, référencée dans le locator.

Note : Au niveau de l’appel du service, nous pourrions appeler la méthode getController de ControllerLocator.

userControl.login(login.text, password.text);


devient :

( ControllerLocator.getController( MonApplication.SERVICE_USER )
	as UserController ).login(login.text, password.text);

Dans ce cas, nous devons « caster » le retour de getController(…) en UserController ( sinon erreur ! Flex ne connaîtrait pas la méthode login )

Un composant pour la vue

Histoire de mettre en pratique un peu plus l’utilisation des “locators” de Reflex, nous allons créer un composant MXML étendant Canvas, qui va contenir la représentation visuelle de notre application. Nous allons utiliser ControllerLocator dans ce fichier pour récupérer le UserController.

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas
	xmlns:mx="http://www.adobe.com/2006/mxml"
	width="100%"
	height="100%">

	<mx:Script>
		<![CDATA[
			import model.UserModel;
			import controller.UserController;
			import com.lafabrick.reflex.controller.ControllerLocator;
			import com.lafabrick.reflex.model.ModelLocator;

			[Bindable]
			private var userDataModel:UserModel =
				( ModelLocator.getModel( UserModel ) as UserModel);

		]]>
	</mx:Script>

	<mx:VBox horizontalCenter="0" verticalCenter="0">
		<mx:TextInput id="login" />
		<mx:TextInput id="password" displayAsPassword="true" />

		<mx:Button
			label="connect"
			click="{ ( ControllerLocator.getController( UserController )
				as UserController ).login( login.text, password.text )}" />

		<mx:Label x="208" y="44"
			text="User Name : {userDataModel.userLogged.name}"/>
	</mx:VBox>

</mx:Canvas>

Pour que le “Binding” fonctionne correctement entre la vue et le modèle, nous devons utiliser des pointeurs vers les modèles à utiliser.

Le fichier de configuration XML (IOC)

Nous venons de voir comment utiliser le ServiceLocator. Intégrons maintenant le système IOC pour ne plus avoir à le gérer !

Ce fichier vous permet de décrire des objets, pour ensuite les récupérer et les instancier dans votre application ( via ApplicationContext ). Ce fichier s’inspire fortement des fichiers de configuration de Spring, un framework puissant pour Java.

Ci-dessous le fichier représentant 2 services RemoteObject :

<?xml version="1.0" encoding="UTF-8"?>
<objects>

	<object id="remotingUser" className="mx.rpc.remoting.mxml.RemoteObject">
		<property name="destination" className="String">javaFacadeUser</property>
		<property name="showBusyCursor" className="Boolean">true</property>
	</object>

	<object id="remotingOther" className="mx.rpc.remoting.mxml.RemoteObject">
		<property name="destination" className="String">javaFacadeOther</property>
		<property name="showBusyCursor" className="Boolean">true</property>
	</object>

</objects>

• Le tag <objects> englobe les différents objets définis dans le fichier. Il est défini par :
• Un objet <object> est défini par :
  • un identifiant id. Cet id est celui que nous utiliserons plus tard dans l’application Flex pour retrouver et instancier l’objet.
  • un nom de classe className : la classe de référence.
• Les propriétés des objets sont définies par :
  • leur nom name
  • leur classe className de référence.

Ici, un RemoteObject a besoin de 2 propriétés : la destination du type String, et éventuellement showBusyCursor du type Boolean.

Régler le problème d’inclusion de classe

Le “petit” problème de ce système est que la déclaration externe des objets fait que les classes ne sont pas intégrées dans le projet Flex. Le compilateur Flex ne trouve pas de référence aux classes, et ne les intègre donc pas dans la compilation. Un façon très simple de régler ce problème est de créer un petit fichier actionScript, et d’ajouter des objets bidons du même type que ceux définis dans votre fichier de config.

Exemple avec les services : (fichier includeService.as)

import mx.rpc.http.mxml.HTTPService;
import mx.rpc.remoting.mxml.RemoteObject;
import mx.rpc.soap.mxml.WebService;

private var ser1:RemoteObject;
private var ser2:HTTPService;
private var ser3:WebService;

Ce fichier sera intégré dans votre application.

Chargement et gestion du contexte XML

Vous allez voir : simple comme bonjour !
Nous allons ajouter le chargement du fichier via ApplicationContext. ApplicationContext permet de charger automatiquement le contexte cible, et de retrouver, instancier, et enregistrer automatiquement tous les services qui se trouvent dans votre fichier de configuration XML dans le ServicesLocator.

Votre application finale :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="absolute"

	creationComplete="init()"

	xmlns:model="model.*"
	xmlns:view="view.*"
	xmlns:controller="controller.*"
	xmlns:service="service.*">

	<mx:Script>
		<![CDATA[
			import com.lafabrick.reflex.ioc.event.ContextEvent;
			import com.lafabrick.reflex.ioc.ApplicationContext;
			import com.lafabrick.reflex.controller.ControllerLocator;
			import com.lafabrick.reflex.service.ServicesLocator;

			include "includeService.as"

			private function init() : void
			{
				ApplicationContext.addEventListener(
					ContextEvent.CONTEXT_LOADED, onLoaded );

				ApplicationContext.load( "ioc/application-config.xml" );
			}

			private function onLoaded( event:ContextEvent ) :void
			{
				// Contexte chargé
				// ...
			}

		]]>
	</mx:Script>

	<controller:UserController id="userControl" />

	<model:UserModel id="userModel" />

	<view:LoginView id="view" />

</mx:Application>

• Nous continuons à utiliser le “creationComplete” pour déclencher la fonction init() qui chargera le fichier de configuration.
• Il ne faut pas oublier d’inclure au besoin les classes contenues dans notre fichier de config !

  include "includeService.as"
  

• Dans la fonction init(), nous ajoutons un écouteur sur ApplicationContext (ContextEvent.CONTEXT_LOADED), qui déclenchera la fonction onLoaded quand le fichier de configuration sera chargé. Puis nous lançons le chargement du fichier de config ( ioc/application-config.xml ).
• … Et nous incluons la vue LoginView.

Modification de notre UserController

Dans un soucis de clarté, nous allons créer 2 classes contenants les constantes référençants les noms des services (contenus dans le fichier de configuration), et les noms des méthodes de ces services.

MethodConstant (dans notre exemple uniquement la méthode login)

package service
{
	public class MethodConstant
	{
		public static const LOGIN:String = "login";
	}
}

ServiceConstant (les identifiants des objets contenus dans le fichier de configuration)

package service
{
	public class ServiceConstant
	{
		public static const SERVICE_USER:String = "remotingUser";
		public static const SERVICE_OTHER:String = "remotingOther";
	}
}

Nous venons de charger notre fichier de configuration au niveau de notre Application. Nous devons maintenant modifier notre contrôleur pour qu’il écoute le chargement du fichier (événement ContextEvent.CONTEXT_LOADED), et mette à jour sa propriété service.

package controller
{
	import com.lafabrick.reflex.controller.BaseController;
	import com.lafabrick.reflex.ioc.ApplicationContext;
	import com.lafabrick.reflex.ioc.event.ContextEvent;
	import com.lafabrick.reflex.model.ModelLocator;
	import com.lafabrick.reflex.service.ServicesLocator;

	import dataObject.UserDo;

	import model.UserModel;

	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;

	import service.MethodConstant;
	import service.ServiceConstant;

	public class UserController extends BaseController
	{

		public function UserController() : void
		{
			ApplicationContext.addEventListener(ContextEvent.CONTEXT_LOADED, onLoaded);
		}

		private function onLoaded( event:ContextEvent ) :void
		{
			// Contexte chargé
			this.service = ServicesLocator.getService( ServiceConstant.SERVICE_USER );
		}

		public function login( log:String, pass:String ) : void
		{
			executeMethod(MethodConstant.LOGIN, onLoginResult, onLoginFault, log, pass);
		}

		public function onLoginResult( event:ResultEvent ) : void
		{
			(ModelLocator.getModel( UserModel ) as UserModel).userLogged =
				event.result as UserDo;

			trace((ModelLocator.getModel( UserModel ) as UserModel).userLogged.name);
		}
		public function onLoginFault( event:FaultEvent ) : void
		{
			trace("resultat pourri ..."+event.fault);
		}

	}
}

Les sources de cette exemple

Et voilà ! Je vais préparer d’autres articles, notemment l’intégration de Reflex dans un projet Gumbo/Flex4. N’hésitez pas à poster vos retours, c’est en flexant qu’on devient flexeron.Autres articles sur le même sujet

• Utiliser Cairngorm dans un projet Flex / AMFPHP
• Google AJAX Language API… et ton Flex devient polyglotte !
• Reflex #1: une micro-architecture pour Flex… simple !
• Flex 4 et les layouts – Faire une ViewStack « pure » Spark