Archive

Articles taggués ‘Google Web Toolkit’

On aime, on partage #47

Bienvenue dans la série « On aime, on partage » de Viseo Technologies ! Chaque semaine retrouvez les meilleurs articles du web issus de notre veille technologique.

Java

JSR 375 : Java EE Security API

Une JSR qui vise à reconsidérer l’API de sécurité pour qu’elle embrasse le paradigme du Cloud et des PaaS. Au programme notamment : une normalisation des mappings de rôles, et un enrichissement des conditions d’autorisations annotant les méthodes. Quand on voit ce qu’il est possible de faire avec Spring Security, il était temps d’y penser.

James Gosling et Bruno Souza rejoignent Jelastic

Le fournisseur de PaaS et IaaS Java et PHP (mais aussi Ruby, Nodes.js, Python, et bientôt .NET) voit arriver le père de Java et un membre très actif et reconnu de la communauté Java rejoindre ses effectifs. Jelastic poursuit donc son développement et illustre par là la volonté d’accroitre son offre sur le périmètre Java (53% des utilisateurs). L’ambition est même plus large puisque Jelastic a candidaté récemment pour rejoindre le JCP afin de faire évoluer la plateforme Java de façon favorable pour son usage dans le Cloud.

Top Java IDE keyboard

ZeroTurnaround rend disponible un document reprenant, par catégories d’actions, les raccourcis clavier des trois principaux environnement de développement du monde Java. Ce document de 37 pages comprend également une analyse du marché des IDEs pour le monde Java, ainsi que des plugins les plus uilisés.

Lire la suite…

On aime, on partage #35

 

Bienvenue dans la série « On aime, on partage » d’Objet Direct !
Chaque semaine retrouvez les meilleurs articles du web issus de notre veille technologique.

 

 

Evénement

Retour sur le “Hackathon” VSC

Les 9 et 10 avril dernier, Voyages-sncf.com organisait son premier hackathon interne. Pendant 24h, 76 salariés et partenaires ont conçu et fait aboutir en équipes des projets créatifs et innovants. Retour sur les coulisses d’un hackathon pas comme les autres.

https://storify.com/Voyagessncf_com/retour-sur-le-hackathon-vsc-sprint

Développement

Le futur de GWT avec la version 3.

Un résumé de la keynote donnée lors de la dernière conférence GWT.create : les nouveautés à venir, avec notamment les très attendus supports des Lamdbas et de CSS 3, et les défis à relever pour GWT dans un écosystème web complètement différent de celui existant à la création du Toolkit.

https://docs.google.com/file/d/0BybCmA8qlS-PMEJMU3BLSFBLVmxiRjNtaWhOUmY0WlZhdlVB/edit?hl=fr&forcehl=1

Cloud

Comparatif des clouds : Google devance tous ses concurrents

Retrouvez le classement CloudScreener / Cedexis  des clouds en fonction de leur rapport performance/prix.

http://www.journaldunet.com/solutions/cloud-computing/comparatif-cloud.shtml

 

Merci aux contributeurs de la semaine : Jean-Philippe LETARD, Claude PETOT et Murielle RENAULT.

On aime, on partage #7

Bienvenue dans la série « On aime, on partage » d’Objet Direct !
Chaque semaine retrouvez les meilleurs articles du web issus de notre veille technologique.
 
 
 
 

Java :

GWT de Google est mort, vive le GWT de la communauté !

L’avenir du framework GWT a été abordé lors de la dernière conférence Google I/O. Pour rappel, ce framework permet de concevoir des interfaces web en Java (concrètement, le code Java de la partie client d’une application GWT est compilé vers du Javascript). Pour les futurs développements, l’équipe souhaite mettre l’accent sur le performances (compilation, exécution), les problèmes de mobilité (conso batterie, réseau), et un meilleur suivi des version de Java (7, et bientôt 8). Il a aussi été question de nouveautés dans l’organisation du développement de GWT : le projet était déjà open-source, mais Google a décidé de passer sur un mode plus « communautaire » en le plaçant sous la gestion d’un comité de pilotage géré par plusieurs acteurs… une manière élégante de s’en débarrasser ?

http://javaweb.developpez.com/actu/55878/GWT-de-Google-est-mort-vive-GWT-de-la-communaute-la-feuille-de-route-de-la-boite-a-outils-de-developpement-Web-devoilee/


Retour d’expérience sur la création d’une application “desktop” à base d’HTML5

Nos confrère d’Ippon nous partagent leur récente expérience mettant en oeuvre HTML5 dans la réalisation d’une application multi-plateforme / multi-devices ayant la particularité de proposer un mode offline. La problématique de gestion du cache est bien détaillée ce qui permettra à quiconque se lançant dans un développement similaire de gagner un temps précieux en évitant quelques pièges.

http://blog.ippon.fr/2013/05/23/une-application-html5-desktop-en-mode-offline




Agilité :

Sprint Reviews in practice

La revue de Sprint est un élément essentiel de Scrum.

Dans l’article qui suit, Ian Mitchell nous en fait une présentation complète (et plus !) : quezaco ?, les différentes étapes, la différence avec la rétrospective, le backlog grooming, les anti-patterns et quelques conseils avisés pour que ce soit une réussite !

Vos revues de sprint ne se passent pas de la manière dont vous souhaitez ? Lisez cet excellent article, un must read pour tout Scrumiste !!!

http://agile.dzone.com/articles/sprint-reviews-practice




Design et conception :

DIP in the wild

Le principe d’inversion de dépendences, ça vous parle ? Voila un article très complet sur le blog de Martin Fowler. Prenez le temps de le lire. Après une longue introduction à ce qu’est le principe d’inversion de dépendances (le DIP du titre) par rapport à l’injection de dépendance ou l’inversion de contrôle, l’auteur illustre ses propos à travers différents exemples. En conclusion, Brett Schuchert rappelle que le code est le moyen d’arriver à ses fins et non la finalité en elle même. Il rappelle aussi que ce qui marche dans un contexte peut ne pas marcher pour un autre. Bonne lecture …

http://martinfowler.com/articles/dipInTheWild.html




Tribune libre :

HOW-TO : Piloter un drone à la Minority Report

Nous avons la chance en tant que développeur d’avoir la possibilité d’assister a un grand nombre d’évènements (DOJO, Barcamp, etc.). Il faut bien avouer que les occasions ne manquent pas et que nous avons l’embarras du choix ! Parmi ces évènements voici le retour d’un “Coding Marathon” organisé par la société Palo-IT qui, par son choix de sujet original, mérite toute votre attention ! En effet, nos confrères ont mixé 2 dispositifs High-tech du moment :

  • le capteur Leap Motion (dispositif prometteur permettant de communiquer avec un ordinateur avec une gestuelle qui n’est pas sans rappeler celle que nous avons découvert il y a quelques années dans le film Minority Report) .

  • l’AR.Drone de la société Parrot (un drone quadrirotor)

L’aventure nous est relatée itération par itération présentant ainsi les différentes embûches rencontrées et les premiers pas avec ces technos originales. Même si il reste encore un peu de travail pour arriver à maîtriser parfaitement les deux appareils, gageons que les participants ont passés un bon moment !

http://palo-it.com/blog/piloter-lar-drone-2-0-avec-le-capteur-leap-motion


Comment déterminer qu’un grand nombre est divisible par 7 ?

Tout ça de manière graphique applicable par un enfant … Le pire, c’est que ça marche !!!

http://blog.tanyakhovanova.com/?p=159


Merci à nos contributeurs de la semaine : Clément Plantier, Jean-Philippe Letard, Mathieu Laurent et Benjamin Marron.

JUG Summer Camp – première édition !

Le 10 septembre dernier a eu lieu le JUG Summer Camp, organisé à La Rochelle par le JUG Poitou-Charentes, cette première édition (qui, nous l’espérons ne sera pas la dernière) fut riche en contenu. Les conférences au nombre de 10 furent rondement menées et la place était laissée pour rencontrer des confrères, des speakers ou encore passer de bons moment autour d’un verre (… bon ok en fait il y en a eu deux). Lire la suite…

Framework GWT : GXT vs SmartGWT

Si Google Web Toolkit est un excellent framework Web, il souffre d’un manque flagrant d’éléments graphiques et, bien qu’il existe des bibliothèques comme gwt-incubator, il est parfois très intéressant d’utiliser des frameworks bien plus complets se basant sur GWT. Suite au changement de licence de ExtJS et la fin de GWT Ext, on retrouve maintenant deux frameworks au dessus de GWT 2.0 : SmartGWT et GXT. SmartGWT est un wrapper de la librairie Javascript SmartClient vers GWT alors que GXT est une réelle surcouche à GWT.

La démo de GXT

La démo de GXT

La démo de SmartGWT

La démo de SmartGWT

J’ai l’occasion en ce moment de travailler sur GXT qui a été choisi par le client pour la migration de son application de GWT 1.5 + GWT Ext (devenu donc obsolète et non maintenu) vers GWT 2.0 et GXT. J’ai donc pu découvrir le code et l’architecture de GXT. A coté de ça, je suis allé comment fonctionnait SmartGWT et parcouru les différentes discussions sur internet.

Le choix entre ces deux frameworks est une étape cruciale et assez difficile. Les deux ont leurs détracteurs et leurs défenseurs.

Certaines personnes défendent même l’utilisation seule de GWT 2. Ces deux frameworks se marient d’ailleurs très mal avec le nouveau UIBinder. Cependant, comme le fait remarquer très justement un des contributeurs de SmartGWT, il faudrait plusieurs mois pour recréer les widgets qu’ils offrent.

La principale différence entre ces deux framework GWT est que GXT est purement Java et donc rentre dans la logique complète de compilation java en javascript de GWT alors que SmartGWT est un wrapper. C’est d’ailleurs cet élément qui amène le plus de détracteurs à celui-ci : lenteur, lourdeur du chargement initial, quid d’un changement de licence chez SmartClient – la librairie Javascript encapsulée, difficulté à étendre les classes pour répondre à des besoins particuliers… Google Web Toolkit ne peut pas optimiser le code javascript. Les contributeurs de SmartGWT plutôt actifs se défendent avec vigueur sur ces points 🙂

GXT serait lui moins complet et moins configurable sur l’apparence. D’après ce que j’ai pu voir en parcourant leurs exemples, je pense que c’est configurable avec l’utilisation de Template ()voir un très bon exemple ici)qui est un mécanisme très intéressant. En parcourant les exemples j’ai vu qu’il était possible de « templater » le rendu par exemple une liste pour créer un browser d’image. Je trouve le principe simple et bien flexible ! GXT est écrit en Java/GWT contrairement aux nombreux wrapper Javascript (SmartGWT en tête). Ainsi la compilation n’inoculera que les ressources nécessaires, le débogage se fait en java y compris dans les composants, l’extension de composant est beaucoup plus naturelle et se fait en java.
Cependant tout n’est pas rose sur GXT. D’abord le framework souffre d’un énorme problème au niveau de sa documentation. Si rentrer dans la logique de l’architecture n’est pas d’une complexité insurmontable, il va falloir se débrouiller avec la Javadoc et les exemples finalement pas si nombreux et complets. Pour moi, c’est clairement le point noir de GXT. Ensuite il existe des bugs (JSONLoader dont le templating ne sert à rien) et petites choses à savoir (mettre une taille dans une ColumnConfig pour la voir réellement apparaître !) qui font parfois perdre beaucoup de temps.
Ensuite de façon plus idéologique, GXT ne suit pas entièrement la logique de GWT. GXT utilise une logique MVC et non MVP préconisé par les ingénieurs de Google ainsi que des listener et non des handlers qui sont la norme depuis GWT 1.6.
GXT propose comme GWT Ext un manager central des composants graphiques lorsqu’ils sont référencés par un ID. Cependant c’est parfois difficile à utiliser car ils ne sont réellement référencés dans le manager que lorsqu’ils ont été rendu graphiquement (et pas simplement ajouté dans le constructeur). Par exemple les tabs items ne sont rendus que lorsque l’utilisateur clique sur les onglets correspondant.

Il faut aussi évoquer les problèmes de licences. Si SmartGWT se base sur SmartClient est donc hérite d’une licence LGPL. GXT est lui sous licence GNU GPL V3. Il faudra payer une licence si vous voulez utilisez GXT pour vendre un produit propriétaire ou si vous voulez un support actif de Sencha (l’entreprise derrière GXT).

Dans tous les cas, ces deux frameworks sont impressionnants et confirme l’intérêt porté à GWT ainsi que ces possibilités. La logique programmation en fait des frameworks relativement facile à appréhender (widget, layout, event) et le full Java permet d’être très productif. C’est encore plus vrai pour une personne ayant déjà une bonne expérience des clients lourds type Swing.

N’ayant pu creuser SmartGWT, je ne ferais pas de conseils définitifs. Cependant GXT est sûrement le meilleur choix pour des projets étant toujours sur GWT Ext.

Remarques additionnelle :
– SmartGWT est développé par le développeur de feu GWT Ext
– Il existe une autre librairie très intéressante : gwt-mosaic. Elle aussi en full Gwt.
– Il existe aussi la librairie Vaadin, qui prend aussi en charge la partie serveur.

Categories: RIA Tags: ,

Google Wave, révolution ?

Logo Google Wave Je me suis avalé l’intégralité de la vidéo de présentation de Google Waves (1h20 !) mais ça valait le coup. Depuis l’annonce faite en mai à la conférence Google I/O à quelques (600) happy few, le buzz a considérablement enflé. Jusqu’il y a quelques jours où Google a annoncé qu’il élargissait le nombre d’invitations à 100 000 et où le sport à la mode est devenu d’avoir SON accès (voire, encore plus fort, l’accès à la sandbox développeur). Il parait même que certains les achètent aux enchères sur e-bay !

Mais qu’est-ce donc que cet OVNI. L’ambition de Google est tout simplement de succéder à l’e-mail (et donc à SMTP) en terme d’usage et de popularité !

La solution ? Fournir un client unique pour toutes les usages collaboratifs d’Internet : le courriel donc, mais aussi le chat, le twitt, le blogging, la publication dans un Wiki, dans Facebook ou tout autre réseau social, jusqu’à l’écriture de compte-rendus de réunion, la planification d’un voyage ou même le jeu, ou toute autre activité qui induit un échange, une collaboration, une publication. Rien que ça !

Comment Google présente-t-il son nouveau bébé ? Qu’est ce qu’une Vague ?

  • Une Vague, c’est moitié conversation, moitié document
  • Une Vague c’est partagé
  • Une Vague c’est vivant

Mais encore? Quoi de neuf par rapport à un courriel traditionnel ?

  • On est plus proche d’une conversation que d’un courrier : tous les participants peuvent intervenir à tout moment (voire se couper la parole !). En ce sens ça ressemble plus à du chat.
  • Les échanges se font instantanément. Toute modification (frappe d’un caractère, mais aussi ajout de pièce jointe, ou d’image) est propagée instantanément à tous les participants ce qui rend effectivement l’échange extrêmement vivant (fini le temps d’attente pendant lequel apparaît le message “votre correspondant rédige un message”) mais aussi très intrusif (quand on chat on peut faire autre chose en même temps, c’est beaucoup plus difficile quand on est sur une Vague).
  • Une nouvelle dimension intervient, le temps : l’historique des échanges qui ont amené la Vague dans l’état courant est conservé et peut être restitué.
  • On peut intervenir à tout endroit de la conversation sans la dupliquer : on rassemble en un seul document un thread complet (i.e. le mail initial et toutes ses réponses ou mises à jour)
  • C’est réellement et nativement multi-media (même si le support initial est aujourd’hui majoritairement le texte).
  • On peut gérer des habilitations : l’accès à une Vague ou à certaines de ses parties peut être finement contrôlé.

L’équipe de Lars Rasmussen et Stephanie Hannon (les créateurs de Google Maps) est partie de la question suivante : à quoi ressemblerait l’e-mail s’il était inventé aujourd’hui ? La présentation du résultat est bluffante et, sans faire du “Googlisme” primaire, le concept me semble effectivement révolutionnaire.

Google Wave, c’est trois composants :

  • Un produit : un client écrit en GWT accédant à un serveur hébergé sur Google AppEngine
  • Une plateforme : des APIs pour développer
  • Un protocole : basé sur XMPP

Le tout est intégralement open source, l’objectif étant de développer des APIs et des usages nouveaux (j’ai admiré l’initiative de la R&D SAP pour proposer un outil collaboratif de modélisation de Business Process s’appuyant sur Google Wave).

J’attends avec impatience mon accès pour vous donner un retour concret (incluant aussi les points négatifs 😉

Cloud computing : le Google App Engine intègre Java

Le cloud computing en Java : c’est parti ! Google App Engine, c’est à dire la mise à disposition de l’infrastructure Google pour supporter les applications d’entreprise, peut désormais héberger des applications écrites en Java.

Les API gérées en standard sont : GWT, Servlet, JDO et JPA. Le mécanisme d’identification/authentification de Google (basé sur les adresses mail Google) s’intègre aussi très facilement. Tout cela utilise le JDK 1.6 de SUN.

Déclarer une nouvelle application à partir du site de Google est un jeu d’enfant. Il faut ensuite télécharger un plug-in  et l’installer sur Eclipse. Vous pouvez ensuite définir vos propres applications App Engine (qui sont en fait des applications GWT un peu customisées), les tester sur votre machine. Quand tout fonctionne, vous pouvez la déployer chez Google en 2 clics et un mot de passe. Encore plus simple que de déployer une application sur un Tomcat ou un JBoss local.

Évidemment, Google ne vous affecte qu’un ensemble limité de ressources (1Go de disque cependant). On peut ensuite « louer » de nouvelles ressources (CPU, mémoire, bande passante, disque) directement à partir du site d’administration de votre application. Et ajuster cette dépense au jour le jour. C’est le principe : vous payez ce que vous utilisez.

Tout n’est pas tout rose cependant : GWT demande du savoir faire. La base de données est DataStore, c’est à dire la BDD Google qui n’est pas précisément relationnelle. Ce qui signifie que les interfaces JDO/JPA proposées par Google imposent un certains nombre de contraintes, dont certaines ne sont pas précisément mineures …

Ne nous y trompons pas : cette offre est un événement majeur dans le monde de l’informatique,  si ce n’est pour le monde tout court. La facilité sidérante de déploiement d’une application sur App Engine, le coût très raisonnable et adaptatif, l’immense scalabilité garantie par Google, risquent de secouer très largement notre métier. On peut déjà imaginer que la livraison d’une application « clé en main »  sous la forme d’un déploiement Google App engine,  sera une prestation que nous aurons prochainement à faire. Il faut nous y préparer.

Je ne saurais trop vous conseiller de vous intéresser très très vite à cette technologie/proposition. C’est une opportunité majeure qui s’ouvre devant nous. Le cloud computing, c’est aujourd’hui. Demain il sera déjà trop tard pour se distinguer.