All posts in Technologies Web

Retour sur DevoxxFR

Jeudi 19 et vendredi 20 avril avait lieu à Paris la conférence DevoxxFR,  par et pour les développeurs java.

La première chose à souligner est l’immense succès de cette première grande conférence puisque nous étions 1250 personnes réunies à l’hôtel Mariott pour les deux derniers jours.

À l’occasion de la sortie des vidéos sur la plateforme Parleys, petit retour sur quelques conférences que j’ai eu l’occasion de voir.

Keynotes

Les deux keynotes qui m’ont particulièrement marquées sont celles de Neal Ford et de Patrick Chanezon.

Dans Abstraction Distractions, Neil Ford nous parle de l’empilement des couches d’abstractions qui envahissent notre quotidien sans qu’on y prête plus vraiment attention et qui peuvent parfois nous induire en erreur. Il nous conseille de toujours avoir à l’esprit ce qui se passe en dessous de la couche que l’on utilise.  Sa keynote est agrémentée d’anecdotes qui font sourire l’auditoire.  Du gros niveau !

Patrick Chanezon enchaîne ensuite avec le portrait d’un développeur en reprenant la trame de The Artist.  On suit le parcours d’un mec qui pendant plusieurs années est le roi du pétrole à coder du cobol dans des SI bien complexes dont seul lui a le secret (=période où Jean Dujardin est une star du cinéma muet).  Puis à l’arrivée de nouvelles technos sympa type mobile, cloud, html5 (=l’arrivée du cinémas parlant) le dev ne s’y intéresse pas et reste dans sa zone de confort.  Malheureusement pour lui ces nouvelles technos prennent de plus en plus de place et notre ami se retrouve rapidement dépassé et remisé au placard (=dépression de Jean Dujardin).

Mais finalement tout est bien qui finit bien car notre développeur se prend en main, réalise qu’il fait partie d’une communauté de passionnés, participe à des jugs et vient à Devoxx. Et finalement cela donne une keynote plutôt rafraîchissante et pleine d’humour.  Bien joué.

Play Framework 2.0

Un mois après la release de la version 2, Sadek Drobi, CTO de Zenexity et Guillaume Bort, cofondateur de Zenexity et créateur de Play Framework retracent l’histoire du web pour expliquer les fondements du framework.

Au départ, le web était constitué de pages statiques puis nous sommes passés dans une phase de langages dynamiques avec notamment PHP, il a fallu ensuite structurer tout ça et c’est à cette époque que sont apparus les premiers frameworks MVC. Plus proche de nous, on a assisté à la démocratisation d’Ajax qui nous a apporté la mise à jour des pages sans besoin de recharger le navigateur.

Aujourd’hui, une page est bien souvent constituée de fragments autonomes, « bindés » sur des flux de données.  Sadek et Guillaume prennent l’exemple de twitter.  Le besoin est réel de structurer ces flux car nous sommes en plein dans l’ère du web temps réel.

C’est sur ce constat qu’a été bâti Play Framework 2,  apporter un socle pour structurer l’interaction avec des streams de manière efficace.

Et voilà du coup ce qu’il est possible de faire : http://console-demo.typesafe.com l’explication ici : http://typesafe.com/products/console

La présentation continue avec comme leitmotiv « don’t fight the web » :  il ne sert à rien d’abstraire le web mais au contraire il faut bâtir en s’appuyant dessus.  Ce que l’on retiendra c’est que Play Framework est un framework stateless full stack qui embrasse le protocole http.

D’un point de vue personnel, cette présentation m’a donné envie d’explorer plus en détail la version 2 de Play, la version 1 apportait déjà beaucoup de fun dans les développements.  Chez DocDoku, nous l’utilisons d’ailleurs en production sur certains projets.

Behind the Scenes of Day-To-Day Software Development at Google

Petra Cross de Google vient nous parler des méthodes de développement chez Google, elle nous présente d’abord la hiérarchie type d’une équipe de développement puis nous parle des méthodes de travail.  On apprend que les maîtres mots sont ‘pragmatisme’ et ‘efficacité’. Par exemple l’équipe de Petra applique l’agilité dans le sens où ils utilisent un backlog de tâches, par contre ils ont totalement supprimé le standup meeting qui selon elle est une perte de temps  (j’entends les agilistes hurler !).

Un concept intéressant massivement utilisé chez Google est le ‘eating your own food’,  il s’agit d’utiliser soit même les produits que l’on conçoit. Ainsi  les googlers utilisent en interne les nighlty build de leurs produits ce qui permet d’avoir un feedback très rapide et de qualité sur les développements.

Conférences Android

J’ai eu l’occasion d’assister à deux conférences sur Android :  « Optimiser vos applications HTML pour Android » et « Android, Graphisme et Performance ». La première présentée par Romain Guy était un condensé de trucs et astuces afin d’optimiser l’IHM des applications Android.

Parmi les astuces et optimisations vues :

  • ViewStub : permet d’instancier (« inflater ») des vues au runtime uniquement si besoin. Cela limite l’empreinte mémoire des View qui peut être très coûteuse, par exemple une TextView vide prend 800 octets en mémoire.
  • StrictMode : outil de debug qui permet d’être notifié lorsqu’une opération lente est effectuée (écriture et lecture disque, opération réseau) ou lorsque une fuite mémoire est détectée (fuite sur les objets sqlite, objet closable non fermé, fuite des activity)
  • GridLayout : nouveau layout introduit d’ICS, moins gourmand que LinearLayout.  Pour les versions Android précédentes, Romain nous conseille RelativeLayout là où c’est possible plutôt que LinearLayout
  •  hierarchyviewer : outil du sdk qui permet de visualiser les grappes de vues et d’analyser leurs performances.

Romain nous détaille également une spécificité des AsyncTask : à partir de l’API level 12 les AsyncTask sont exécutées de manières sérialisées, les unes après les autres. Attention donc à ne pas ralentir la file d’exécution avec une tâche trop longue. Google justifie ce changement en expliquant que la programmation multithread est compliquée. Ils ont donc décidé de revenir sur le comportement par défaut pour limiter les bugs potentiels. Par contre si l’on est sûr que les tâches sont totalement thread-safe, il est tout a fait possible programmatiquement de revenir au comportement précédent.  Ainsi pour paralléliser les AsyncTask il suffit d’appeler :

task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR);

La deuxième conférence Android est celle du googler Nicolas Roard qui travaille sur la webview Android. Nicolas nous délivre quelques astuces pour optimiser les performances dans une webview.  Il nous recommande de privilégier le CSS3 plutôt que le javascript lorsque l’on souhaite faire une animation.

Il nous explique également comment forcer la création de layers qui seront accélérés de façon hardware à partir de la version 3.  Pour cela il suffit d’appliquer une propriété css de transform 3D sur un élément.  On peut également créer un layer sur un scroll afin d’obtenir un rendu proche du natif grâce à la propriété css overflow scroll.

Attention tout de même, ces layers ont certes un rendu fluide mais ils sont très couteux. Il est donc conseillé de les utiliser avec parcimonie, par exemple uniquement durant une animation.

Nicolas termine par 25 minutes de questions/réponses. Les questions majoritairement posées tournent autour des performances de la webview qui souffre de la comparaison avec l’application Google Chrome pour Android.

Il nous explique que même si les deux s’appuient sur le moteur de rendu webkit, les contraintes ne sont pas les mêmes. La webview fait partie intégrante du framework, l’équipe a donc des contraintes quant à la mémoire et l’espace disque utilisé, la webview doit être compatible avec un maximum de choses et rétro compatible avec les précédentes releases. L’équipe de Nicolas a notamment fourni un effort de travail spécifique pour afficher correctement les widgets jquery mobile.

Toutes ces contraintes ne sont pas applicables à Chrome, Chrome est téléchargé depuis le market, c’est un choix de l’utilisateur, par conséquent ils ont beaucoup plus de liberté. Ils peuvent prendre des décisions, avancer vite et releaser souvent, chose impossible à faire pour la webview qui doit attendre une nouvelle version d’Android pour être mise à jour.

Nicolas conclut en nous assurant que les deux équipes mettent en commun beaucoup de travail et que tout le monde en tire un bénéfice.

Quickies

Entre midi et deux avaient lieu les quickies, un format court de conférences où en 15 minutes un speaker présente un sujet qui lui tient à cœur.

J’ai pu notamment voir Mathilde Lemee nous présenter son projet FluentLenium qui facilite l’écriture des tests Selenium en proposant une API très lisible (d’où le fluent !). Et effectivement quand on regarde l’exemple de base, on comprend tout de suite le test :

public class BingTest extends FluentTest {
    @Test
    public void title_of_bing_should_contain_search_query_name() {
        goTo("http://www.bing.com");
        fill("#sb_form_q").with("FluentLenium");
        submit("#sb_form_go");
        assertThat(title()).contains("FluentLenium");
    }
}

FluentLenium s’appuie sur les selectors CSS (même si les regex sont possibles). Enfin la dernière chose à noter sur le projet est qu’il est agnostique du framework d’assertion, ainsi jUnit Assert, Hamcrest et Fest-assert sont supportés.

Un deuxième quickie assez fun fut celui de Philippe Antoine qui s’est proposé de recoder en live le tetris de Martin Kleppe dont une version est jouable ici : http://jsbin.com/egiqul/49

La spécificité initiale de ce Tétris est d’être codé en 140 caractères, cette performance est possible en utilisant le décalage binaire.

Philippe se lance donc dans la réalisation du Tétris avec l’aide de la salle,  il en profite pour nous montrer comment faire du TDD en javascript avec QUnit. Un quickie original qui a bien plu.

Code Story

Pendant les deux jours de conférences, une équipe de quatre développeurs a codé en live une application from scratch. Chaque slot de conférence a donné lieu à un sprint. Ils ont fonctionné en pair programming avec un binôme codant pour la salle : ordinateur relié au vidéo projecteur en commentant le code.  J’ai eu l’occasion d’assister à un sprint, et par la même occasion j’ai pu découvrir Trello un super outil très souple et très simple de gestion de projet.

Conclusion

En tant que développeur, je me suis régalé durant ce Devoxx, j’ai pu satisfaire ma curiosité sur des sujets totalement nouveaux pour moi, comme me plonger dans des astuces plus techniques sur des sujets comme Android.  Si je devais dégager des keywords de cette grande et belle conférence, je choisirais :  cloud, mobile, html5 & javascript, NoSQL.

GWT est-il toujours pertinent ?

Il y a 3 ans, lorsqu’il s’agissait de définir le socle technique d’une nouvelle application web, en l’absence de contraintes exogènes, GWT (Google Web Toolkit) était pour nous un choix naturel pour le développement de la partie « front web ». Les arguments massue de l’époque étaient le manque de portabilité de JavaScript, son faible niveau d’outillage par rapport à Java et aussi la grande difficulté que l’on peut rencontrer à développer une large application avec un langage aussi dynamique et faiblement typé que JavaScript. Face à ces écueils, GWT représentait le rempart absolu, la solution ultime.

Aujourd’hui toutefois, les choses ont de mon point de vue quelque peu évolué.
Tout d’abord, le support de navigateurs obsolètes, comme Internet Explorer 6 par exemple, n’est plus l’obsession des DSI qui par contre tiennent de plus en plus à ce que leurs applications offrent également un bon rendu sur les dispositifs mobiles et tactiles.

Ensuite, l’écosystème JavaScript a progressé. Si les jQuery et autres Prototype existaient déjà il y a 3-4 ans, des frameworks de plus haut niveau tels que Backbone.js, JavaScriptMVC, s’appuyant d’ailleurs sur jQuery, ont fait leur apparition. Ceux-ci aident à fournir un cadre à la structuration des applications de grandes tailles, point délicat lorsque le volume de JavaScript devient important. Des moteurs de templates côté client comme mustache ou des starter kits, à l’instar de bootstrap twitter, sont également venus enrichir l’offre JavaScript.

Côté GWT aussi les lignes ont bougé, passés les premiers instants d’émerveillement, quelques défauts se sont fait sentir. Le premier d’entre eux est l’absence d’une vraie bibliothèque de widgets solide et pérenne. GWT étant avant tout un socle technique, Google laisse à la communauté ou aux éditeurs tiers le soin de bâtir sur son framework. Ainsi Ex GWT, SmartGWT, Vaadin pour ne citer qu’eux disposent de composants de plus haut niveau, prêt à l’emploi. Malheureusement ces bibliothèques n’ont jamais donné pleinement satisfaction : licence peu « business friendly », adhérence importante, problème de qualité. Au final, la sagesse recommande de se contenter de GWT et de tout développer soi-même…
Par ailleurs, GWT, au fil des versions, a gagné en complexité, le pattern « activities/places » pour être correctement employé exige que les développeurs soient bien formés ; RequestFactory, CellWidget sont des nouveautés qu’il conviendra à nouveau d’assimiler et qui contraindront la migration d’un bon nombre d’applications.
En outre, si GWT parvient à éloigner complètement JavaScript du développeur, il ne le préserve pas de CSS qui tend à prendre de plus en plus d’importance et devient une nouvelle source d’incompatibilité entre les navigateurs. On touche finalement au coeur du problème : GWT est une abstraction imparfaite ; cette encapsulation des technologies web ne dispense pas les développeurs d’en comprendre les arcanes.

Conclusion
Pour répondre très concrètement à la question posée par ce billet : oui GWT est toujours pertinent surtout s’il s’agit d’implémenter une grosse application de gestion avec des développeurs de niveau hétérogène. Par contre, pour une application innovante, faisant un usage prononcé des dernières fonctionnalités HTML5 (3D, communication temps réel) il est avantageux d’être en prise directe avec le browser (bare metal).
Quoi qu’il en soit, ce qui était annoncé à la sortie du framework de Google ne s’est pas produit : JavaScript n’est pas devenu l’assembleur du web. Qu’on le déplore ou non, ce langage est aujourd’hui incontournable, son champ d’application dépasse d’ailleurs largement le cadre du navigateur (CommonJS). Aucun développeur IT ne peut continuer à le bouder.

DocDoku présent au Mobile World Congress du 27/02 au 01/03/2012

Nous serons en effet présents cette année à l’évènement mondial du mobile, le MWC à Barcelone du 27/02 au 01/03/2012.
N’hésitez pas à nous rendre visite sur le Pavillon Français, Hall 2.0 ou à nous contacter pour prendre rendez-vous sur vos stands ou autres points d’échanges :

 
 

DocDoku soutient l’IRIT pour la future Licence Pro Entreprise 2.0

La révolution Web 2.0 a donné naissance aux réseaux sociaux qui redistribuent véritablement les cartes en matière de communication B to C et B to B.

Être présent sur ces nouveaux médias devient indispensable pour les grandes entreprises mais aussi pour des entreprises de plus en plus petites.

Afin de répondre à une demande importante des entreprises, l’IRIT et l’Université de Toulouse vont prochainement proposer au Ministère chargé de l’enseignement supérieur et de la recherche la création d’une licence professionnelle.

Intitulée « Entreprise 2.0 : les réseaux sociaux au service de l’entreprise », cette formation aura pour objectif de former en apprentissage les futurs stratèges des médias sociaux, community manager, média planner ou webmarketeurs de demain.

Une formation qui devrait avoir un franc succès tant du côté des étudiants que des entreprises si elle voit le jour !

Symfony 2 et Play! : Frameworks de productivité

Ces derniers temps nous avons parallèlement travaillé en PHP avec Symfony 2, juste sorti cet été, et en Java Play! Framework. Ces deux outils sont ce que l’on appelle des Frameworks de productivité, dans la lignée de Ruby on Rails ou Grails, sur lequel j’ai un peu d’expérience.

L’enseignement de ces derniers mois est que ces outils sont presque interchangeables, car basés sur des architectures très proches : Vue, templating, routing, Controlleur, Modèle, ORM. Cela faisait 5 ans que je n’avais pas fait de PHP, et je n’ai pas eu de grandes difficultés à prendre Symfony 2 en main.

Mais pourquoi choisir un tel Framework ? Comme le nom l’indique, à être plus productif. J’ai pu réalisé en trois semaines un Back Office basé sur 35 tables SQL en générant automatiquement le code. En général le code généré n’est pas maintenable, mais Symfony va bien au-delà de cette génération. Tous ces outils m’ont permis ensuite de modifier ce Back Office brut en un produit plus adapté, marketé, en Ajax.

back office avec Symfony 2

En avançant dans ce travail, et en reprenant également les composants pour le Front Office j’ai essentiellement eu de bonnes surprises.

Play! a également eu du succès, et effectue la partie Back Office de notre produit Ipad Kumobook. Ce qui est visible sur la vidéo a été fait par une personne en moins d’un mois ! JQuery fait également très bon ménage avec Play! et Symfony. Le système de Play! est assez différent puisque, comme Grails, il ne génère pas du code, mais affiche le rendu à la volée.

Reste donc à choisir le Framework parmi Symfony, Play!, Roo, ou Grails. Pour cela, DocDoku est à votre service pour vous apporter les conseils nécessaires.

Formation HTML5

Une nouvelle formation vient de faire son entrée à notre catalogue : « Développer des applications HTML 5 ». Destinée aux développeurs, elle est la synthèse de notre pratique quotidienne depuis plus d’un an de cette technologie conjuguée à l’étude approfondie des normes et spécifications la constituant.

Cette formation s’étale sur 3 jours, l’ensemble des nouveautés d’HTML5 et de CSS3 sera expliqué, nous prendrons également du recul pour traiter des problématiques de conception technique et échanger sur les perspectives qu’ouvrent la plateforme pour les applications métier ou digitales.

La première session inter-entreprises est planifiée du 24 au 26 octobre 2011 à Toulouse au centre ville dans nos nouveaux locaux entièrement rénovés. Thé, café, jus de fruits, viennoiseries et les déjeuners seront offerts aux stagiaires.

Programme complet de la formation HTML5 :
http://www.docdoku.com/formation/html-5/

Inscription et demande d’information :
http://www.docdoku.com/identite/contact/

DocDoku et Webinage font carton plein à la Mêlée Numérique XV !

Cette année encore, DocDoku était présent à la Mêlée Numérique et accompagné d’un partenaire de grande qualité avec Webinage.

Sur le stand de DocDoku, vous avez pu assisté à la présentation de l’application tactile que nous avons réalisée pour et avec Webinage.

Vous avez été également très nombreux à vouloir une démonstration de notre solution de GED Open Source disponible en SaaS.

Ces deux journées ont donc été plus que satisfaisantes pour l’équipe DocDoku car un public de qualité était au rendez-vous.

La conférence sur « HTML 5 ou l’évolution majeure du web et de l’internet mobile » présentée par Florent Garin notre Directeur Technique et Thomas van de Velde, Directeur Général de Webinage a rencontré un grand succès, avec la participation d’une centaine de personnes dans la salle !

Si vous n’avez pas pu assisté à la conférence, la présentation sera prochainement disponible sur notre blog et sur le site internet de la Mêlée Numérique.

DocDoku vous offre une tablette tactile pour tout contrat signé à la Mêlée Numérique XV

DocDoku aura le plaisir de vous accueillir sur son stand lors de la 15ème édition de la Mêlée Numérique à l’Espace Diagora de Toulouse Labège, les mercredi 20 et jeudi 21 avril 2011. Le Salon des TIC numéro 1 sur le Sud Ouest rassemble tous les acteurs économiques des solutions de l’informatique, des nouvelles technologies, des télécoms et de l’innovation. Au programme : 150 exposants, 45 ateliers et conférences et plus de 3000 visiteurs attendus.

L’actualité de DocDoku
Cet évènement sera l’occasion pour DocDoku de vous présenter sa dernière réalisation tactile entièrement développée au moyen de technologies innovantes Open Source (HTML 5, CSS3, JQuery, SIPCommunicator…). Venez également échanger avec nous sur notre solution de gestion du cycle de vie des produits (Product Lifecycle Management) Open Source, qui est incubée au sein d’OW2 et devrait être lancée au début de l’année prochaine.

Animation sur le stand
Assistez à une démonstration de l’application multiplateforme Webinage, notre dernière réalisation tactile entièrement développée au moyen de technologies innovantes Open Source.

Animation atelier
Notre directeur technique, Florent Garin, animera également un atelier sur « HTML 5 ou l’évolution majeure du web et de l’internet mobile » le mercredi 20 avril de 16h30 à 17h30 . Inscrivez-vous sur le site du salon.

A Propos de DocDoku
DocDoku est un cabinet de conseil et de formation innovant disposant d’une expertise sur les technologies et solutions Open Source (Java, JEE, Android, DocDoku, Liferay…). Cette expertise nous permet d’avoir la confiance de clients majeurs comme Amadeus, Axa, Cegedim, Dassault, LG, Motorola, Météo France, Mia Electric, MSA, NEC ou Pierre & Vacances.
Nativement éditeur de la solution libre éponyme de gestion collaborative de documents (GED ou ECM), notre activité résolument tournée vers la recherche et développement nous permet d’apporter une réelle valeur ajoutée à nos prestations de conseil, d’expertise, de formation et de réalisation de projets dans le domaine IT.
Nos consultants sont très impliqués dans nos projets de recherche et développement essentiellement Open Source et assurent une veille technologique permanente.

Plus d’information sur le salon
Mercredi 20 et jeudi 21 avril 2011 à l’Espace Diagora de Toulouse Labège. Entrée gratuite Le site du salon : http://www.meleenumerique.com

Contact Presse
M. Eric Descargues Téléphone : 05 61 72 24 09

Mentions Légales
DocDoku SARL au capital de 20 000 euros RCS Toulouse : 492 273 800 000 28 Code APE : 5829C Buroplis – Bâtiment B – 150 rue Nicolas Louis Vauquelin 31100 Toulouse
http://www.docdoku.com

HTML 5, the next big thing

HTML 5 est assurément la prochaine révolution en matière de développement de sites internet et d’applications web. Grâce entre autres à WebGL (API 3D), WebSocket (connexions TCP full-duplex) ou encore Web Storage (stockage de données en local côté navigateur) il n’y a plus de frontière entre applications natives et applications web et cela sans plugin.

Pour se convaincre des possibilités, il suffit de voir le portage du jeu Quake 2 sur ces technologies.

DocDoku participe à la 14ème édition de la Mêlée Numérique à Toulouse Labège les 28 et 29 avril 2010

DocDoku aura le plaisir de vous accueillir sur son stand lors de la 14ème édition de la Mêlée Numérique à l’Espace Diagora de Toulouse Labège, les mercredi 28 et jeudi 29 avril 2010.

Le Salon des TIC numéro 1 sur le Sud Ouest rassemble tous les acteurs économiques des solutions de l’informatique, des nouvelles technologies, des télécoms et de l’innovation. Au programme : 160 exposants, 40 ateliers et conférences et plus de 5000 visiteurs attendus.

DocDoku : Conseil, Formation et Solutions innovantes IT

L’actualité de DocDoku

Cet évènement sera l’occasion pour DocDoku de vous présenter ses toutes dernières solutions collaboratives (GED en mode SaaS avec client web Ajax) et mobiles (applications Android et multiplateformes). Venez également découvrir notre savoir-faire dans le domaine du conseil et de la formation en Systèmes d’Information et Technologies de l’Information et de la Communication.

Animation sur le stand

Venez assister à une démonstration de l’application Tableonline pour Google Phone Android, outil pratique et ludique de recherche et de réservation de restaurant depuis votre mobile. Découvrez également la nouvelle version de notre interface web (Ajax-GWT) de notre solution de GED éponyme à l’origine de notre société.

Participation atelier

Notre directeur technique, Florent Garin, animera également un atelier sur les « Stratégies et développements mobiles multiplateformes» le jeudi 29 avril de 9h30 à 10h30 (à suivre sur le programme du salon).

A Propos de DocDoku

DocDoku est un cabinet de conseil et de formation composé d’experts dans le domaine des Technologies de l’Information et de la Communication. Notre savoir-faire se traduit également par l’édition et l’intégration de solutions professionnelles mobiles et collaboratives.

Nativement éditeur de la solution libre éponyme de gestion collaborative de documents (GED ou ECM), notre activité résolument tournée vers la recherche et développement nous permet d’apporter une réelle valeur ajoutée à nos prestations de conseil, d’expertise, de formation et de réalisation de projets dans le domaine IT.

Nos consultants sont très impliqués dans nos projets de recherche et développement essentiellement Open Source et assurent une veille technologique permanente.

Enfin, nous nous efforçons de créer et de proposer des prestations et solutions  adaptées sans jamais oublier que l’expertise n’a de sens que si elle est au service de la couverture de vos  besoins métiers.

Plus d’information sur le salon

Mercredi 28 et jeudi 29 avril 2010 à l’Espace Diagora de Toulouse Labège.

Entrée gratuite

Le site du salon : http://salon.meleenumerique.com/

Contact Presse

M. Eric Descargues

Email : eric.descargues@docdoku.com

Téléphone : 05 61 72 24 09

Mobile : 06 70 00 12 91

Mentions Légales

DocDoku SARL au capital de 20 000 euros

RCS Toulouse : 492 273 800 000 28

Code APE : 5829C

Buroplis – Bâtiment B – 150 rue Nicolas Louis Vauquelin

31100 Toulouse

http://www.docdoku.com

JavaFx vs Flex vs Silverlight

Après une période d’inactivité importante due à un beau projet Pierre et Vacances et l’écriture d’un livre sur Android, je reprends ce blog en main !

Je suis tombé dernièrement sur une comparaison des performances entre JavaFx, Flex et Silverlight. Bien que je ne sois pas tout à fait certain de la validité des résultats, il semblerait à vue de nez que JavaFx s’en sorte très honorablement.
Pourtant, je ne pense pas que dans son état actuel, cette technologie pourra décoller.
Le problème n’est pas qu’il faille réapprendre un nouveau langage de script, après tout même si cela demande un petit effort au départ, l’avantage de bénéficier d’un langage (DSL) spécifique à la définition d’interfaces graphiques devrait au final l’emporter.
Le souci n’est pas non plus l’absence d’outils orientés design car Production Suite devrait convenir à la plupart d’entre nous.
Non, le défaut majeur de JavaFx est son manque de discrétion : le temps de démarrage est beaucoup trop long et sans rapport avec Flash, la petite icône Java qui apparait dans la barre de notification est gênante car elle nous rappelle que « quelque chose » se lance, les fenêtres de sécurité sont invasives (heureusement aujourd’hui crossdomain.xml est en partie supporté) et enfin l’expérience utilisateur de l’installation du runtime et des mises à jour de la JVM, avec sa publicité Open Office et sa toolbar Yahoo, plus que moyenne.

A mon sens, tant que ces inconvénients ne seront pas corrigés, il y a très peu de chance qu’émerge un « youtube » s’appuyant sur JavaFx et cela quelles que soient les autres qualités de la plateforme.

Eclipse RAD

Il y a quelques jours lors d’un déjeuner avec Jean-Marie Damas (un des organisateurs de l’Agile Tour), nous avons évoqué le framework Eclipse RAP (Rich Ajax Platform).
Ce framework n’est pas vraiment tout nouveau et finalement si discret qu’il n’est pas très connu.
L’idée de RAP est d’être le pendant de RCP (Rich Client Platform) dans le monde Web. Il fournit le même environnement « Workbench » et les applications RAP sont implémentées avec les mêmes APIs SWT et JFace que celles tournant sous RCP.
Cette approche universelle peut séduire mais elle me rappelle un peu trop de nombreuses autres tentatives de grand écart qui se sont soldées pour la plupart par des échecs. JDO (Java Data Objects), par exemple, voulait offrir une API unique de persistance et cela quelque soit le système de stockage sous-jacent (BD, XML, fichiers à plat…).

Si l’on souhaite obtenir le meilleur de la plateforme d’exécution il n’est pas souhaitable de concevoir une application web comme une application lourde, une application de bureau comme une application pour mobile…La liste est longue !

architecture-RAP

Upload et download de fichiers avec un web service (suite)

Ce message fait suite à mon précédent billet concernant le download et surtout l’upload de fichiers par Web Services SOAP.

Le bug 29 du projet jax-ws a bien été résolu, avec un petit bémol car la correction ne fonctionne qu’avec les Web Services à base de Servlet et non ceux basés sur les EJB Session. Cependant, pour transférer les données binaires MTOM utilise un transfer-coding de type chunked. Il s’agit d’une fonctionnalité d’HTTP 1.1 permettant d’envoyer ou de recevoir une requête HTTP par morceau.

La version 1.1 du protocole HTTP est vieille de plus de 10 ans. Malheureusement, dans de nombreuses organisations, sévissent encore des proxies web ne supportant que la version 1.0 !
Du coup, il n’est plus possible d’appliquer la propriété JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE sur le proxy du client. On se retrouve alors avec le problème initial ; on risque le « out of memory » côté client en téléchargeant sur le serveur (upload) un fichier volumineux.

Enfin, que les utilisateurs de DocDoku se rassurent, par défaut les échanges de fichiers se font par Web Services MTOM et en cas d’environnement réseau hostile (proxy http 1.0) le client bascule automatiquement dans un mode HTTP basique (multipart/form-data).

Upload et download de fichiers avec un web service

Comment faire pour « uploader » et « downloader » un fichier vers et depuis un web service ?
Très simple me diriez-vous et depuis longtemps. Il suffit d’utiliser SAAJ (SOAP with Attachments API for Java) ou encore mieux MTOM (Message Transmission Optimization Mechanism) pour bénéficier de l’assurance d’une compatibilité .Net/Java optimale.
En théorie cela semble simple mais quand on passe à la pratique, dans le contexte d’une application réelle, les choses se compliquent bigrement, en tout cas en ce qui concerne l’implémentation de JAXWS.
La plus grosse lacune de JAXWS au niveau MTOM est son incapacité à transmettre les données binaires sous forme de flux de bout en bout. Comme expliqué ici il est bien possible d’indiquer au client d’utiliser le mode « streaming » mais côté serveur rien à faire, l’ensemble des octets constituant le fichier est monté en mémoire.
Même côté client, JAXWS mériterait quelques améliorations. En effet il n’est pas possible de superviser la progression du transfert, de plus le mode « streaming » opère en appelant HttpURLConnection.setChunkedStreamingMode sur la connexion sous-jacente ce qui pose des problèmes car de nombreux serveurs web ou proxy ne supportent pas ce mode. Il serait intéressant que JAXWS calcule la taille du contenu à poster et invoque plutôt la méthode HttpURLConnection.setFixedLengthStreamingMode.

Conclusion de tout cela, pour uploader un fichier en http rien ne vaut d’utiliser directement HttpURLConnection et d’implémenter le basique et standard upload multipart/form-data.

Lemmings en Javascript

Il est tout possible de faire en AJAX même le fameux jeu lemmings.
Preuve est faite qu’avec du javascript, du css et beaucoup d’ingéniosité on parvient à implémenter dans un navigateur des applications de bureau.
Il faut toutefois relativiser l’exploit, si le jeu d’origine pouvait tourner sur un 286, la version web requière une configuration musclée !
De plus, la partie son n’est pas portable mais s’appuie sur QuickTime ou Windows Media Player.

Le débat pour ou contre AJAX reste donc entier !

Problème d’accents dans les applications web

La gestion des accents dans les applications web n’est toujours pas, quelque chose de simple qui marche sans qu’on s’en préoccupe !

Quand le navigateur soumet un formulaire, il poste les valeurs des champs en utilisant le même encodage que celui de la page html d’origine.
Dans une jsp, pour spécifier au moteur de servlet l’encodage du flux de la réponse http et donc de la page html générée, nous avons recours à la directive @page comme ceci :

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

Renseigner l’attribut contentType a deux effets ; premièrement d’encoder la réponse dans le format choisi, deuxièmement de l’indiquer au client, par le biais d’une variable dans l’entête http.
Il est cependant intéressant de mentionner cet encodage directement dans la page html. Ainsi, elle pourrait être parsée à nouveau correctement ; par exemple ré-affichée après avoir été sauvegardée sur le disque. Il est donc plus prudent d’ajouter la balise suivante entre les tags head :

<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>

Enfin, nous pouvons remarquer que la directive @page support également un attribut « pageEncoding ». Cet attribut précise simplement l’encodage de la page jsp elle même. Cette information sert au moment de la compilation de la jsp pour produire la servlet correspondante. Cette valeur dépend de l’IDE, NetBeans (dans sa configuration initiale) sauvegarde les fichiers en utilisant l’encodage par défaut de l’OS : CP-1252 pour Windows et UTF-8 pour linux.

Côté serveur, il faut décoder les paramètres de la requête http avec le même encodage que celui qui a servi à la transmission du formulaire.
Mais quel est celui utilisé quand on appelle HttpServletRequest.getParameter(name) ?
En théorie, à l’instar de ce que fait le serveur dans sa réponse, le navigateur est censé communiquer au serveur, dans l’entête http, l’encodage employé.
Malheureusement, dans la pratique ni Internet Explorer ni Firefox ne le fait. Pour s’en convaincre il suffit d’appeller HttpServletRequest.getCharacterEncoding() et constater que la méthode retourne null.
La conséquence de cela est que si l’object HttpServletRequest ne connait pas l’encodage dont s’est servi le client, il en utilisera un par défaut. Ce paramétrage est propre au serveur d’application, Glassfish par exemple, utilise l’ISO-8859-1. Il est évidemment possible de le changer.
Il est aussi possible de modifier le « CharacterEncoding » programmatiquement grâce à la méthode setCharacterEncoding(value). Si l’application est développée à l’aide d’un framework web (JSF, struts…), il faudra définir un HttpServletFilter pour le faire avant que les couches du framework n’accèdent à la requête.

Formalisation de REST

REST (REpresentational State Transfer) apparaît de plus en plus comme une alternative sérieuse à SOAP. A l’instar d’eBay ou d’Amazon de nombreux sites web proposent dorénavant leur API publique également sous forme d’interfaces REST.
Pour l’instant, le frein majeur à l’adoption de ce paradigme demeure le manque d’outil ou de formalisation. REST n’est aujourd’hui qu’un concept d’architecture logicielle.
Néanmoins, cela est peut être en train de changer grâce la spécification WADL (Web Application Description Language).
Grossièrement, WADL a pour objectif de définir un langage de description des interfaces de type REST. L’équivalent du WSDL dans le monde SOAP.
C’est une affaire à suivre, je sens bien qu’on a pas fini d’entendre parler de REST et de WADL.

PHP imagettftext

Dernièrement, je constatai que le captcha (test permettant de distinguer un utilisateur humain d’un ordinateur) que j’avais installé sur la page des commentaires ne marchait subitement plus. En y regardant de plus près, je vis que l’erreur venait de la fonction php imagettftext de la bibliothèque GD. Cette fonction dessine un texte avec une police TrueType. Elle accepte en paramètre (entre autres) le chemin vers le fichier de police.
Le problème est que depuis la version 2.0.18 de la librairie GD la façon d’interpréter le chemin a changé. Dorénavant, le fichier doit être défini sans l’extension ttf et la recherche des fichiers se fait par rapport aux répertoires spécifiés dans la variable d’environnement GDFONTPATH. Ainsi, si le fichier de police se trouve au même emplacement que le script php, il convient d’écrire :


putenv('GDFONTPATH=' . realpath('.'));

 

$font = 'Font';

Je tenais l’explication (et la correction) de mon bug ; mon hébergeur avait mis à jour la lib GD du serveur dédié sur lequel est installé mon blog.

Cette mésaventure montre, en tout cas, que php ne semble pas évoluer de manière aussi conservative que java ; rappellons que la JVM 1.5 est toujours capable de faire tourner du code écrit avec la première monture du jdk. Cela pourrait être un frein à l’adoption de php dans l’entreprise.