Les vidéos de Back From MAX Paris sont en ligne
Le 27 Octobre dernier, avait eu lieu le Back From MAX organisé par Adobe à Paris:
Adobe Back from MAX Paris le 27 Octobre 2011
A la suite des présentations de la journée, ont eu lieu les "Lightning talks", ces mini-présentations de 10 minutes (en théorie
). A cette occasion, 5 participants ont pu donner leur retour d'expérience sur le développement d'application AIR Mobile.
C'est d'ailleurs à cette occasion que j'ai pu découvrir l'application Pocket Agile dont vous avez peut-être entendu parler sur flex-tutorial:
Pocket Agile – Une application AIR multi-plateforme connectée au cloud
J'ai aussi présenté une des applications que j'ai développé chez Business Geografic, avec quelques explications sur le mode déconnecté.
Toutes les vidéos sont sur le site de BAAO, vous n'avez qu'à vous servir
:
Flex given to the Apache Software Foundation – round-up and opportunities
This post is the 1002nd published on flex-tutorial.fr since January 2008, and it is especially important because it addresses the future of the evolution of Flex. The 1000th article was actually this same article but in French. Due to popular demand and Twitter RTs, I decided to translate it into English, adding a few things I missed when writing the original article
Flex Community Summit
Last week, I was invited by Adobe to spend 2 days at their offices in San Francisco for a rather special Flex Community Summit. 2 days of presentations / lectures on the following points:
- Clarify the message given by Adobe
- Explain the consequences of the Flex project being given to Apache
- Explain how the Apache Software Foundation and their hosted projects actually work
- Bring the community together to get its feedback and participate in open discussions
The latest announcements made by Adobe were quite rushed and often clumsy. It must be said that the change of strategy was a surprise to many, given that it was made after Adobe MAX (October). It is too late to change this, and Adobe has even apologised for its poor communication. So, we must now forget about it and think about the future of Flex.
Apache Software Foundation
Although the presentation was not particularly exciting, it was interesting to see how the Apache SF and the projects it hosts actually work. The presentation was provided by a member of the board of the ASF, Roy T. Fielding , who is one of the authors of the specification HTTP / REST, no less.
The ASF is a non-profit association which hosts projects licensed under the Apache licence. The most famous of these projects is the Apache HTTP Server, one of the most popular softwares in the business. There are many others, with 97 other projects, including Apache Maven, Ant, Tomcat, OpenOffice, Lucene, Subversion, … I'm just listing the "official" projects because Apache projects have 2 states: incubation and accepted.
For Flex, it will of course begin with the incubation period. For this to happen, Adobe will send a proposal (a document that we saw earlier in the week) to the Apache mailing list which will be considered by the board. Apache will acknowlege this proposal within 72 hours and decide whether the project is accepted into the incubation process or not. This step should not be a problem, Adobe is one of the largest contributors to the Apache Foundation and recently had PhoneGap accepted by the Apache Foundation.
During this incubation period, the organisation of the project must be proven and shown to be ready. If all goes well, the project can come out of the incubator and become a "real" Apache project. This may take several weeks to one year.
The roles within the ASF – Committers & contributors
The ASF is organised quite differently to how you may expect. The organisation of the board is almost exclusively done through the mailing list, no meetings. Within the projects themselves, it is the same, there is no hierarchy as such, no president, no manager, etc.. You can find more information on the operation of the Apache Software Foundation on this page:
Apache Software Foundation – How it Works
Everything is done on the basis of "meritocracy". Put simply, the more you do for the project, the higher your rank is.
If you are involved in the project, you have the role of "contributor". This means that you are active on the mailing list, you have submitted patches or written documentation, for instance.
Then you have special contributors called "committers". These people have write access to the versioning system of projects (SVN).
Then we can find members of the "PMC" which are "contributors" or "commiters" entitled to vote for decisions taken by the community.
Open governance
The voting system is very important in the projects of the ASF, and work in a very simple manner. Each voter can give a +1, 0 (neutral) or a -1. The decision is then made based on the score of the vote, and the negative votes must be justified.
An important point to note is that the projects of the ASF are composed of individuals, not groups or businesses. Some members of the Apache Flex project will be Adobe employees, but they will not have more importance than the others, everything will be based on the votes of individuals.
Here Adobe loses control of the governance of Flex, and therefore the direction the project takes. The community members of the ASF will decide. And this changes many things, including the fact that strategic decisions from Adobe will no longer influence the project.
Great, then what is the roadmap?
One issue that was raised at the Summit was to know what the roadmap for the next Apache Flex would be. And in fact, there is no roadmap, but it's not a problem. This is the "design" for any Apache project.
In an Apache project, there is no manager who will dictate where the project is moving, everything depends on individuals. The evolution of the Apache project Flex is in fact directly dependent on the contributions made by its members. Basically, if a "contributor" wants to do something in the project, he will submit a patch and start a thread on the mailing list. If the contribution seems interesting, it will be included in the source code of the project.
Nobody is going to tell a member of the project to work on a specific feature. The feature itself may be discussed on the mailing list but governance is open, so there is no instruction.
There is no public roadmap itself. This may seem strange at first, but that is how the ASF works. In the end, I think it's a very good system.
Flex 5 most wanted features – Polls and results
A couple of days ago, I put together an online meeting (using Adobe Connect) with French developers about the future of Flex. This meeting wasn't about Flex being dead or not, or complaining about Adobe decisions. Instead, we tried to think of features that would make Flex even better than it is today.
There were 4 main points of focus:
- Improving the industrialisation of Flex projects (eg. better integration with Maven or with other piece of software which we find in our business, such as Sonar, …)
- Improving the efficiency of Flex developers (eg. missing components, …)
- Improving the integration of Flex applications within their environment (cross-domain restrictions, full screen mode, AutoFill on forms, keyboard shortcuts, embedded WebKit, …)
- Giving Flex exclusive features (file access, SQLite + WebKit within Flash Player, …)
Around 80 developers (exclusively from France) participated in this Connect session. We started with two polls, then everyone could suggest features they wanted to see as part of the future of Flex for about 1 hour. We ended up with about 40 features and then everyone had around 30 minutes to vote for the features they liked the most.
Since this is quite important, I decided to share the results and translate them into English. Maybe it will give some ideas to other community leaders outside of France
.
If you can read French, here are the results. If not, keep reading
.
Poll results
Here are the results for the first 2 polls. The number of votes is given in brackets.
Would the FalconJS compiler (Flex -> HTML5) be suited to your projects?
- (26) – Yes, if it performs well
- (10) – No, I don't like cross-compilers, I prefer writing my own HTML5 content
- (7) – No, I have some features which are impossible to create without Flash Player
- (1) – My customer is not asking for a migration / can't migrate
Are you (or your company) willing to participate in the Spoon project?
- (16) – Yes, depending on the time I can spend on it
- (9) – No, I will wait and see how Spoon works out before I make any decision
- (4) – Yes, active participation
- (4) – No, but I want to use the new features of the framework
- (2) – No, I'm moving away from Flex
Most wanted features
Here are the most wanted features for Flex 5 in general, so this also includes AIR and Flash Player because both are linked to Flex:
- (27) – Improve the language (private constructors, operator overloading, generics, metatags, enums, abstract classes, introspection, …) so that ActionScript becomes the same level as Java
- (26) – Finish the Spark component set (Tree, Charts, …)
- (23) – Improve the AIR Mobile Simulator ADT (resolutions, screen density, …)
- (22) – Advanced debugging tools (follow event propagation, reverse debugging, …)
- (21) – HTML content integration, also on mobile (iFrame component, htmlText properties, …)
- (20) – Reduce tight coupled classes within the SDK using more interfaces
- (20) – Improve the Spark components (selectable Label, Autocomplete, …)
- (20) – Improve debugging on mobile (debug player + errors from ANEs)
- (19) – Native PDF display
- (19) – Ability to embed a web browser (such as WebKit used in AIR) also in Flash Player
- (18) – SQLite access within Flash Player
- (17) – Official Maven integration of flex-mojos (archetype, …)
- (17) – Be more flexible with security rules (x-domain, keyboard in full screen mode, …)
- (15) – Printing
- (15) – Integration with the history / password manager of the browser
- (15) – Render components with the GPU
- (14) – Support ANE development in tooling
- (14) – Enhance StageWebView for better JS / communication
- (14) – Resuscitate code quality tools such as Flex CPD, Flex PMD, and improve Sonar integration
- (14) – Better and asynchronous JPEGEncoder/PNGEncoder within the SDK (using Alchemy)
- (13) – Removing the MX components + changing some packages such as "core"
- (13) – A sharing system similar to the AppStore for components with 3 levels of integration (Unstable / Stable / Official)
- (13) – Code obfuscator
- (12) – Replace the Tween class (too slow)
- (12) – Customisation of the right click contextual menu
- (11) – Facilitate AIR applications update when compiled with Captive Runtime
- (11) – SEO
- (10) – Metatag checking at compile-time
- (10) – Allow users to contribute the framework using Git
- (9) – Remove compiler integrations (ADL and such) from Flash Builder for a better integration within other IDEs
- (9) – A way to make it easier to play sound within RIA applications
- (8) – Stop using the bloated UIComponent class
- (8) – Allow one-click technology stacks such as Spring/Hibernate on Tomcat ; EJB3/Hibernate on JBoss ; Spring/Hibernate on Tomcat or Jetty
- (8) – Solve the rendering issues when embedding fonts in an AIR Desktop application
- (7) – Better integration with GraniteDS
- (7) – Fusion of GraniteDS and BlazeDS + RTMP support
- (7) – BlazeDS enhancements : BigInteger and BigDecimal out of the box
- (6) – Better ASDoc support : compile-time variables, allow ASDoc generation of some parts of the project
- (4) – BlazeDS enhancement : Using non-blocking NIO for messaging scalability
Quick analysis of the results
The results of this session are quite clear. A participant actually summed it up pretty well in one of the comments made on the French article.
There are 2 main topics that stand out:
- A better IDE (= better productivity). Flash Builder isn't good enough for a consistent project (compile time, design view, …). A more complete language to make our life easier.
- Opening Flex to other web technologies. Being able to communicate and integrate HTML5 content with your Flex project will be key. A good example is Google deprecating the AS3 Google Maps API in favor of the JS one. A better HTML integration/communication within Flex projects would allow us to use the JS API without any issue.
If you are interested in the future of Flex development, I suggest you do the same kind of exercise, it's always very informative (and if you need a Connect room, contact me at fnicollet@gmail.com).
Adobe have invited myself and a few others to San Francisco in a few days time to discuss where Flex is headed. If you want Spoon to be a success, the time is now
Concertation Flex 5 – Bilan et résultats
Il y a quelques jours, je vous annonçais l'organisation d'une rencontre entre développeurs FR pour imaginer la roadmap de la prochaine version de Flex:
Concertation Flex 5 – Partagez vos idées sur l'évolution du framework Flex
Chose promise, chose due, cette concertation a bien eu lieu cette après-midi. Ce billet va présenter les résultats des différents sondages réalisés pendant cette session ainsi que la liste des fonctionnalités que les développeurs demandent. Bien sûr, cela ne veut pas dire que ces éléments seront intégrés dans la roadmap, mais cela permet de doser le ressenti des développeurs sur les éléments manquants à Flex.
Avant de dévoiler les résultats, je tiens à remercier tous ceux qui ont participé à cette réunion (en cumulé, on a du atteindre les 80 participants).
Je vais mettre les résultats par ordre décroissant de votes. Le nombre entre parenthèses représente le nombre de votes.
Le compilateur FalconJS (Flex->HTML5) conviendrait-il à vos projets?
- (26) – Oui (sous réserve de bonnes performances)
- (10) – Non, je n'aime pas les cross-compiler, je préfère écrire mon contenu HTML5
- (7) – Non, j'ai des fonctionnalités impossibles à réaliser sans Flash Player
- (1) – Mon client ne me demande pas de migration / ne peut pas migrer
Comptez-vous (ou votre entreprise) participer au projet Spoon?
- (16) – Oui, en fonction du temps disponible
- (9) – Non, je continue flex j'attends de voir le travail de spoon avant de me décider
- (4) – Oui, participation active
- (4) – Non, mais je veux profiter des nouveautés du framework
- (2) – Non, je souhaite m'écarter de Flex.
Viennent ensuite les fonctionnalités attendues par les développeurs. Ces derniers ont d'abord tous donné les fonctionnalités qu'ils souhaitaient voir (en vrac). Celles-ci ont été consignées dans une liste de 40 points différents. Au bout d'une grosse heure de discussions, les participants ont pu voter (sans voir les résultats) pour une ou plusieurs fonctionnalités.
Fonctionnalités les plus demandées
- (27) – Amélioration du langage (constructeurs privés, surcharge d'opérateurs, generics, metatags, enums, classes abstraites, introspection) pour venir au même niveau que Java
- (26) – Terminer la "sparkisation" de tous les composants (Tree, Charts,…)
- (23) – Amélioration du simulateur pour AIR mobile (résolutions, …)
- (22) – Outils de debug avancés (pouvoir suivre les propagations des évènements par ex.)
- (21) – Gestion du contenu HTML (y compris sur mobile)
- (20) – Réduire le couplage fort du code du SDK en utilisant davantage d'interfaces
- (20) – Amélioration des composants Spark (Label selectable, Autocomplete, …)
- (20) – Amélioration du debug sur mobile ( player debug + erreurs ANEs)
- (19) – Affichage natif des PDFs
- (19) – Possibilité d'embarquer un navigateur (type Webkit pour AIR) aussi en web dans Flash Player
- (18) – SQLite en web, pas que dans AIR
- (17) – Intégration officielle de maven (archetypes & co)
- (17) – Réduire la taille des swc du framework
- (17) – Etre plus souple avec des règles de securité incompréhensibles (cross domain, clavier en full screen, etc.)
- (15) – Impression
- (15) – Intégration avec les gestionnaires d'historique / mot de passe navigateur
- (15) – Faire le rendu graphique des composants en passant par le GPU
- (14) – Support du développement des ANEs
- (14) – Améliorer StageWebView pour communication avec JS / DOM + SWV Desktop
- (14) - Réanimation des outils orientés qualité: Flex CPD, FlexPMD, et améliorer l'intégration à Sonar
- (14) – JPEGEncoder et PNGEncoder du SDK plus rapides (Alchemy) et asynchrones
- (13) – Suppression des composants MX + modification des packages trop communs comme core.
- (13) – Un système de création et de partage de composants à la sauce App Store avec 3 niveaux progressifs: 1) Instable: proposé à la communauté et rapidement testé 2) Stable: Validé par plein de développeurs qui l'ont utilisé en prod 3) Officiel: intégré dans le framework Flex
- (13) – Outil d'obfuscation du code
- (12) – Remplacer la classe Tween fournie par Adobe car trop lente)
- (12) – Personnalisation du menu contextuel en click droit (FP 11.x)
- (11) – Faciliter l'updating des applications AIR compilée avec Captive Runtime
- (11) – Référencement
- (10) – Contrôle des metatag à la compilation (par exemple: un Bindable dans une interface peut ne pas être Bindable dans l'implémentation, idem pour les [Event] dont le compilateur ne contrôle pas l'existence d'un dispatch ===> les interfaces gagneraient encore plus en intérêt)
- (10) – Permettre la contribution au Framework via Git
- (9) – Sortir les intégrations des compilateurs (ADL et autres) de FB, dans une appli externe (pour une meilleur intégration du SDK dans d'autre IDE)
- (9) – Gestion du son dans les applications
- (8) – Réduire les dépendances vers UIComponent à 0
- (8) – Permettre des installations automatiques (one click) de technologies stacks en local, genre (Spring/Hibernate on Tomcat ; EJB3/Hibernate on JBoss ; Spring/Hibernate on Tomcat or Jetty )
- (8) – Régler le problème de différence de rendu des polices embedded dans une application AIR Desktop, selon les plate-formes
- (7) – Envisager une meilleure intégration de GraniteDS
- (7) – Fusion des projet GraniteDS et BlazeDS + support du RTMP
- (7) – Améliorations BlazeDS : gestion de types BigInteger et BigDecimal de base.
- (6) – ASDoc: Support des variables de compilations + possibilité de générer seulement une partie (celle qui fonctionne)
- (4) – Améliorations BlazeDS : intégrer d'emblée le non-blocking NIO de manière à permettre la scalabilité du messaging
Analyse rapide des résultats
Il est intéressant de voir que la fonctionnalité la plus votée est une amélioration du langage ActionScript 3 sur lequel repose Flex. La plupart des développeurs Flex ont de l'expérience dans d'autres domaines / langages (Java, le plus souvent) et souhaitent arriver aux mêmes possibilités syntaxiques. Cela peut aussi permettre aux frameworks d'injection de dépendance de devenir plus puissants et de mieux s'intégrer avec le code (metatags compilés, introspection, …).
Pour le reste, je crois que les fonctionnalités parlent d'elles-même. Pour n'importe quel développeur Flex, le Top 10 peut améliorer sa productivité et la qualité de son code.
Encore une fois, merci à tous les participants d'avoir donné un peu de leur temps !
Comme je l'avais annoncé dans mon billet précédent, je serai à San Francisco la semaine prochaine chez Adobe pour discuter de la roadmap de Flex. Votre parole sera donc entendue





