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 :
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 !
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.
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.
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/
Vous avez été nombreux à nous la réclamer. La présentation effectuée avec notre partenaire Webinage lors de notre atelier du mercredi 20 avril 2011 lors de la Mêlée Numérique 15 est en ligne.
Merci à Laura de l’équipe KeepCore pour cet interview sur le thème du RIA sur leur blog RIA-EXPERTS.
L’article complet est ici.
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 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 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 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.
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
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.
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 !
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).
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.
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 !
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.
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.
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.
Remember The Milk est une application que l’on pourrait classer dans la catégorie Web 2.0. En effet, RTM est massivement AJAX, offre des raccourcis clavier, possède des fonctionnalités de partage et d’échange, dispose d’une API publique et intègre d’autres technologies comme les SMS.
RTM, bien que malgré tout limité dans ses possibilités, est un bon concentré de ce que l’on pourrait trouver sur le net demain.
En personnalisant mon blog, j’ai mis le doigt sur une incompatibilité d’Internet Explorer avec le standard XHTML. En effet, si dans une page html nous insérons la balise :
<script type="text/JavaScript" src="mon_script.js"/> ;
IE ne considérera pas la balise fermée et ne sera donc pas capable d’effectuer le rendu correctement.
Nous devons donc choisir la forme suivante :
<script type="text/JavaScript" src="mon_script.js"></script> ;
elle aussi heureusement conforme au standard XHTML.
IE n’est donc pas full XHTML compliant, Firefox lui, n’a pas ce problème !
