Que l’on me pardonne de paraphraser ici la déclaration rituelle qui accompagnait l’inhumation du Roy de France et la transmission immédiate de la monarchie à son successeur désigné.

L’analogie me parait en effet appropriée dès lors que « Adobe Flex », roi incontestable des technologies RIA, est mort et « Apache Flex » est né (du moins c’est en cours).

Alors, faut-il s’en réjouir ? Oui, assurément, c’est une excellente nouvelle, et qu’il conviendra de célébrer justement en temps utile.

Et je dirais même plus, remercions Adobe pour ce cadeau qui nous est offert, en toute franchise, mais sans naïveté.

Il ne nous intéresse pas de chercher à analyser les raisons internes à Adobe qui ont motivé ce choix, laissons à César ce qui lui appartient, et regardons l’avenir de Flex, dont il ne tient qu’à nous qu’il soit glorieux.

Pour nous qui sommes développeurs Flex depuis 2004 et la version 1, nous n’avons cessé de pousser le framework dans ses retranchements, et toujours nous avons réussi à produire des applications (d’entreprise) esthétiques et de qualité, sans sacrifier pour autant l’industrialisation logicielle, qui est, hélas, trop souvent négligée.

A l’heure actuelle, nous affirmons que Flex reste le meilleur environnement de développement d’applications riches multi-plateforme, tant en terme de productivité que de richesse graphique ou fonctionnelle.

Les arguments en faveur (ou pas) de cette thèse ont été déjà largement exposés et sont accessibles via les liens ci-dessous :

• After 6 years doing Flex, am I moving to HTML5?
• The Future of the Flex Framework in Enterprise IT
• Adobe Flash Wounded but Death Exaggerated

Notre intention aujourd’hui est de continuer plus que jamais à utiliser Flex, et de renforcer notre présence dans son éco-système, en poursuivant la publication de composants, et en contribuant activement au framework Apache Flex.

Flex reloaded

Avec (et surtout sans) Adobe, Flex va continuer sa vie. Beaucoup de volontaires participent déjà au projet Apache Flex. De manière générale, les entreprises qui ont choisi Flex comme outil de développement de RIA continueront à l’utiliser, d’abord parce qu’il n’y a pas encore d’alternatives sérieuses offrant les mêmes possibilités et la même productivité.

Chez Kap IT nous n’avons pas diminué notre activité sur Flex, au contraire, nous continuons même à recruter de nouveaux clients (et des développeurs aussi…).

Nous restons convaincus que Flex restera encore pendant plusieurs années la plate-forme de choix pour les applications d’entreprise. Nous continuerons donc à investir dans Flex, sans doute plus qu’avant, en nous investissant dans le projet Spoon et la fondation Apache et en continuant à recruter et former ceux qui partagent cette conviction.

A ce propos, nous participons au « Logo Contest », dans lequel nous avons proposé deux déclinaisons différentes du futur logo Flex (et entre nous, ce changement est plutôt bienvenu) que vous pouvez découvrir dans cet article.

Flex n’est qu’un outil

Notre expertise en matière de RIA d’entreprise ne s’arrête évidement pas à la technologie. Les nombreux projets que nous avons réalisés pour nos clients nous ont permis de capitaliser sur les autres domaines qui permettent de réaliser des applications riches de qualité comme la méthodologie, l’ergonomie, le design ou encore l’assurance qualité. Ces domaines sont indépendants des langages et des plate-formes utilisés et nous sommes donc libres de changer s’il le faut. Si d’aventure une solution pour les RIA d’entreprise aussi productive et puissante que Flex devenait disponible, nous serions prêts.

A suivre…

Les prochains mois seront riches en surprises, surtout, restez online !

Il me reste à vous souhaiter une excellente année 2012, ainsi que beaucoup de projets Flex fructueux et passionnants.
Et de concert, souhaitons tous une Longue Vie à Apache Flex !

Vous suivez probablement de près l’évolution du SDK Flex, depuis qu’il a été accepté en incubation par l’Apache Software Fondation en début d’année.

La communauté, très active depuis que le projet est entré en incubation, a décidé d’organiser un concours pour offrir au framework une nouvelle identité; un symbole fort (et obligatoire) afin de marquer le transfert du produit de l’éditeur vers la communauté open-source.

La période de remise des propositions s’est achevée hier et le nombre de propositions est relativement élevé. (Une cinquantaine de propositions). Il s’agit d’un signe encourageant venant de la communauté, laissant présager un futur plus serein pour le framework, en difficulté depuis les annonces d’Adobe.

2 personnes de notre pôle ergonomie-design ont travaillé sur des propositions de logo.
En voici le résultat, accompagné de leur démarche respective.

Proposition 1

Cette première proposition se base sur un symbole fort et puissant, le chef indien, qui nous a donné un liant entre “l’univers” Apache et la marque Flex.

Elle conserve l’identité Flex intacte et l’enrichit des codes graphiques d’Apache. On retrouve ainsi la plume, dans la collerette du chef, les codes couleurs du logo Apache et le “Fx” de Flex, le tout dans une composition qui souhaite récupérer les forces des deux enseignes initiales.

Proposition 2

Avec la deuxième proposition, nous avons décidé de couvrir un autre champ des possibles, celui de la sobriété et de la solidité.

Initialement basée sur la symbolique du tipi indien, forme solide faisant référence à l’univers Apache, nous avons ensuite orienté ce travail autour d’un jeu de typographie.

La forme triangulaire du logo évoque ainsi une tente indienne aux couleurs d’Apache, où l’on peut dans une seconde lecture discerner le A d’Apache et le F de Flex fondus l’un dans l’autre.

Le dessin final représente de manière abstraite l’absorption de Flex au sein de la communauté Apache.

Souhaitons bonne chance à ces logos! Les votes ont commencé ce matin et la décision finale devrait être prise par les membres PPMC du projet.

Toute l’équipe de Kap IT est heureuse de vous présenter ses meilleurs vœux pour l’année 2012 !

Tout d’abord, je me joins à toute l’équipe Kap IT pour vous souhaiter une bonne année 2012 pleine de belles réalisations interactives !

Que se cache-t-il derrière ce sigle ? Déjà 3 ans qu’il dispose de sa définition Wikipedia mais qu’en est-il en ce début 2012 ?

Voici un rapide bilan de son incursion dans notre quotidien.

Contexte

Nous sommes constamment « encerclés » par de nouveaux dispositifs tous plus sophistiqués les uns que les autres (ubiquité technologique). Que ce soit des smartphones, des tablettes, une Wii, une Kinect, tous ont un point commun… Ils nous permettent d’interagir avec eux par ce qui est le plus naturel pour nous ; notre toucher, nos gestes et même notre voix. Rendant presque invisibles les interactions elles-mêmes.

Les techniques d’interaction du NUI

Ainsi en conjuguant ces nouvelles possibilités avec un bon design d’interaction, nous sommes capables de concevoir des produits encore plus efficaces et intuitifs qu’auparavant.
Un nouveau modèle d’interaction a donc émergé et il répond au doux nom de NUI pour Natural User Interface ou Interfaces Utilisateurs Naturelles en français.
Et cette apparition a du bon, principalement pour les utilisateurs, qui disposent d’interfaces encore plus intuitives et sans doute plus rapides à appréhender.

Mais où trouve-t-on le NUI ?
Regardons d’un peu plus près les types d’interactions présents dans notre quotidien.

Une petite astuce rapide qui pourrait vous faire gagner un peu de temps lors de la compilation de votre projet Flex grâce au plugin maven Flexmojos.

On part du principe que toute application non triviale Flex est composée d’un ensemble de modules (au sens maven).
Ces modules sont généralement de type SWC ou SWF.

En tant que bon développeur que vous êtes, vous lancez votre compilation/test maven en local avant chaque commit afin de vous assurer que vous n’allez pas casser le build et ainsi vous attirer des ennuis auprès de l’équipe technique ou encore perdre des points à votre jeu favori.

Dès lors que vous développez une application de taille moyenne/grande, vous vous retrouvez à la merci des performances du compilateur Flex (dont la nouvelle version se fait attendre depuis la nuit des temps), même si vous avez eu la bonne idée de découper votre application en modules Flex.

Lorsque vous lancez la compilation sur tout votre projet, les modules maven vont être compilés les uns après les autres, y compris si vous avez changé les sources que dans un seul projet.

La variable de configuration « quick » que l’on retrouve pour les projets de type SWC ou SWF, pourrait vous aider à accélérer cette compilation.
À propos de cette variable, la doc indique :

« Quick compile mode. When true, Flexmojos will check if the latest artifact available at maven repository for this project is newer then sources. If so, wont recompile. »

Le principe est tout simple : Si la date de l’artifact généré dans le repository maven est plus récente que la date de modification des sources, c’est que les sources n’ont pas été modifiées. Flexmojos va donc éviter de recompiler les SWC/SWF qui ne le nécéssitent pas… Pratique !

Pour utiliser le quick mode, il suffit de l’activer dans la configuration du goal choisi :

<plugin>
        <groupId>org.sonatype.flexmojos</groupId>
        <artifactId>flexmojos-maven-plugin</artifactId>
        <version>${flexmojos.version}</version>
        <configuration>
                <quick>true</quick>
                ...
        </configuration>
</plugin>

Attention !

Il faut noter toutefois, que ce mode peut entraîner des effets de bord gênants :

• Si un module n’est pas compilé, les tests ne sont pas exécutés. Dans vos rapports de tests, vous allez donc voir baisser le nombre de tests exécutés ainsi que leur couverture de code!
• Il semble que le plugin ne gère pas les sources qui ne sont ni des .as ni des .mxml. Par exemple, des .properties ou .css à compiler. Ce qui signifie que vos locales ou feuilles de styles ne seront pas recompilées, même si elles ont changés.

Cette petite astuce sera donc à utiliser avec parcimonie