Posts Tagged ‘Web’

Prochaine réunion du ParisJS

Wednesday, June 15th, 2011


Vous ne le savez peut-être pas mais, depuis octobre 2010, un Groupe d’Utilisateurs du langage JavaScript se réunit à Paris tous les derniers mercredi du mois.

Ce groupe très dynamique s’intitule ParisJS et rejoint les groupes d’utilisateurs existants, qu’il soit Européens (Berlin, London, Vienne, Cologne, Amsterdam), Canadiens (Montréal, Toronto, Vancouver), Australiens (Sydney, Brisbane) ou, bien sûr, Américains (Boston, Baltimore, Colombus, Portland, Atlanta, Los Angeles, New York, Brooklyn, Austin, Dallas, Las Vegas).

On présente au ParisJS généralement 4 ou 5 sujets de 15 à 30 minutes par soirée, comme par exemple des frameworks et librairies (node.js, backbone, Raphael), des frameworks de tests (QUnit), des bases NoSQL (CouchDB), on traite de l’amélioration des performances (chargement asynchrone, how to be faster than JQuery) et on présente des démos technologiques (Kinect dans le browser, Inside Globe Tweeter, Pacmaze : un Pacman en WebGL).

Cette liste n’est pas exhaustive, vous la trouverez plus complète sur le site officiel du ParisJS.

Ce mois-ci, Valtech offre son auditorium pour la session du mercredi 29 juin. Nous vous y attendrons à partir de 19h30 à l’adresse suivante : 103 rue de Grenelle 75007 Paris.

Seule formalité pour participer, s’inscrire sur eventbrite.

Gae : Leçons pour celui qui passera après moi ou si vous vous intéressez à GAE, Maven, Jersey, Rest …

Monday, January 24th, 2011

Je vais vous faire part dans ce nouveau billet de mon incommensurable expérience sur GAE et d’un écosystème particulier, le mien. Pour reformuler, ce que je vous propose ici est un REX. J’ai toujours adoré cet acronyme, très parlant, d’une phonétique explosive. C’est le genre de document qui revient vous mordre même une fois que vous l’avez mis à la niche. Pour ceux qui ne connaissent pas, c’est un document que l’on vous demande de rédiger quand vous vous êtes planté pour ne pas vous planter une deuxième fois. De manière plus positive, on a toujours dit que c’est en tombant que l’on apprends à marcher.
(more…)

Ne cassez pas l’historique dans vos applications Ajax !

Monday, December 20th, 2010

Il est aujourd’hui inconcevable de ne pas utiliser Ajax et autres comportements dynamiques à base de JavaScript dans vos applications.
Cependant, souvent, cela se fait au détriment de la gestion du bouton précédent / suivant, et plus globalement de l’historique du navigateur.
Par ailleurs, cela pose également problème si l’utilisateur clique sur un lien JavaScript via l’action “ouvrir dans un nouvel onglet” ou “ouvrir dans une nouvelle fenêtre”.

J’ai voulu adresser ce problème dans un projet personnel de type carnet d’adresse et je vous propose une solution dans la suite de cet article.
(more…)

Cours du soir Selenium: les slides

Friday, July 11th, 2008

Suite au cours Selenium donnée par Philippe lundi dernier, voici les slides pour vous!

Atelier clients riches Web : GWT, Silverlight et Flex, le 19 juin

Wednesday, May 21st, 2008

Le 19 juin, Valtech Training organise un atelier clients riches Web : GWT, Silverlight et Flex.

A l’heure où Web 2 devient l’expression la plus utilisée de la presse informatique et où les éditeurs se livrent à une escalade d’annonces, nous vous proposons de vous forger votre opinion sur les technologies les plus en vue du monde Rich Internet Application : Flex, GWT et Silverlight.

Après une introduction rapide aux problématiques et solutions du client riche, vous pratiquerez lors de trois ateliers techniques successifs de 2 heures. Vous écrirez donc votre première application dans chacune de ces technologies et serez ainsi amené à juger de leur facilité de mise en œuvre : essayez-les, choisissez !

Je veux m’inscrire !

Le retour des Network Computer

Wednesday, April 30th, 2008

A l’heure où je vous parle, je suis devant un banal ordinateur.
Rien de plus commun que cet engin doté encore d’un disque dur, d’une mémoire et même d’un lecteur de disquette (je sais, je suis vieux). Mais est-ce moi, ou ma machine qui est vielle.
Il y a presque 20 ans j’ai démarré avec un « 3270 », quel engin barbare (merci IBM) pour faire de l’informatique. Terminal passif, juste un écran et un cable réseau connecté à Big Blue.
Mais en finalement, pas si désuet que ça.
Pour gérer ces mails, il y a Google (Gmail)
Pour faire ces spécifications et autres plans chers à nos Ingénieurs Qualité, il y a Google (Google Docs)
Pour faire nos suivis de projets, statistiques en tout genre, il y a Google (Google Docs)
Pour voir nos photos de vacances, il y a Google (Picassa)
Pour suivre la presse, il y a Google (Google Reader)
Pour voir les films, il y a Google (bon là, c’est YouTube, pas encore racheté par Google?)
Et maintenant, même pour développer nos applications, il y a Google (Google App Engine)
Et pour ranger tout ça sur mon bureau, il y a encore Google (IGoogle)

Donc, pourquoi s’embarrasser d’un vieil ordinateur, avec disque dur de 180Go et mémoire de 2Mo, pour finalement accéder à Internet.
Même Windows, à quoi sert-il, si ce n’est lancer le navigateur.
Même le système d’exploitation est remplacé par le navigateur, YouOS (www.YouOS.com)
Reste à avoir un bon fournisseur d’accès, et voilà !

PS : Google = Google, Yahoo, et Cies

Faire revivre les liens morts

Sunday, October 14th, 2007

Pour pérenniser son blog ou son site en général, il faut se battre contre plusieurs ennemis. La motivation pour écrire de nouveaux articles en est un. C’est un facteur facilement maîtrisable car cela dépend de soi-même. Il n’en est rien pour les liens morts. Aucun faire-part de décès ne vous prévient de leur disparition.

Heureusement, il y a des outils pour automatiser la détection de ces petites choses qui peuvent rendre inconsistant votre superbe article de 2002 prédisant la crise financière mondiale liée à l’utilisation abusive de la titrisation sur le marché du crédit immobilier américain.

Dans le cadre de la migration de ce blog, j’ai utilisé: www.dead-links.com.

Il prend en paramètre une URL et affiche un rapport complet après vérification de tous les liens de la page. L’affichage du rapport suit la progression de la vérification par le serveur des liens.

Voici les étapes:

  1. Crawling Internal Links (exploration des liens internes au nom de domaine)
  2. Checking External Links (vérification des liens externes)
  3. Report (liens morts avec codes d’erreur)

Ensuite, il ne reste plus qu’à réparer, c’est-à-dire faire revivre les liens en repointant vers des ressources existantes.

Comme toute opération de maintenance, il y a des inconvénients:

  • Réitérer l’opération à chaque fois qu’on veut refaire la vérification
  • La réparation n’est pas automatisable et peut être fastidieuse

Il y a d’autres outils disponibles en ligne, saluons notamment l’inébranlable W3C avec son outil maison: validator.w3.org/checklink

Screen Recorder

Friday, October 12th, 2007

La version 9.2 de Quicktest Professional est dotée d’une nouvelle fonctionnalité fort intéressante appelée Screen Recorder. Cette fonctionnalité permet d’enregistrer la vidéo de l’application testée pendant le déroulement d’une session de test. Cette vidéo sera ajoutée au résultat du test.

(more…)

Les standards du web sont-ils suffisants pour développer des applications web ?

Thursday, September 13th, 2007

Ext-logoJ’ai connu le framework Ext-js après avoir eu la charge d’évolutions sur une mini-application web.

Ce qui est frappant c’est que les gens qui éditent ce framework ont rétablit pour les applis web un équilibrage qui existe toujours dans les applications lourdes (Desktop). Ils ont replacé la gestion de l’interface homme machine du côté du client. Cette librairie en langage Javascript offre des services d’interaction avec le javascript (JSON, extension des API natives, etc.), avec le serveur (Ajax) et une gamme de composants graphiques d’interaction. L’interface d’une application web construite sur ce modèle est donc la composition de:

  • vues (pages HTML) qui initialisent le squelette de la page,
  • contrôleurs (scripts Javascript) qui intègrent les composants graphiques et qui dynamisent ce squelette,
  • modèles (scripts Javascript) qui récupèrent les données du serveur.

Pour le développeur

Du point de vue du développeur, c’est une librairie agréable à utiliser pour peu qu’on se familiarise avec le javascript du XXI ème siècle (qui n’a plus rien de commun avec le scripting verbeux et inmaintenable qu’on vous demandait de faire marcher sous IE et Netscape en l’an 2000). Mécanismes de listener, panels, layout, on se croirait presque en train de faire du Swing ! Ce qui m’a posé le plus de problèmes est le typage faible ainsi que le passage de pointeurs de fonctions qui ne ressemble pas à ce qu’on fait habituellement en objet mais qui est très pratique pour passer un callback. Du côté des outils, c’est firefox+firebug associé à Eclipse WTP avec lien des sources directement dans Tomcat.

Le marché

Le besoin d’applications riches tournant dans le conteneur d’application qu’on appelle navigateur web, avec déploiement instantané et accès concurrent est très fort. Les solutions pour augmenter l’expérience utilisateur et la productivité des développeurs existent; j’ai parlé de Ext-js mais il y a aussi Flex d’Adobe ou Silverlight de Microsoft. Ext-js repose sur les standards et arrive à faire tourner ses applications dans le navigateur, mais ce n’est pas le cas de Flex ou Silverlight qui requierent tous deux un plug-in container d’application.

Les standards du web ont été conçus sur un modèle documentaire. Sauront-il inventer un standard de l’application web ? Si on regarde côté applications ‘Desktop’, il n’existe aucun standard de ce type car pour moi, un standard est plutôt lourd et peu évolutif. Je pense que la concurrence dans ce domaine permet de développer l’innovation et les bénéfices pour les utilisateurs. Le risque majeur est qu’un acteur du marché développe un monopole avec l’emprise sur le web que cela induit.

Conclusion

Pour finir, je pense que pour un développeur de vraies applications web (i.e. pas de sites web), il est plus agréable de travailler avec un Framework de qualité comme Ext-js que de redévelopper sans cesse l’interface utilisateur sur chaque page.

Pour le responsable technique/décideur, la question de la pérennité du framework dans un marché aussi versatile que celui des interfaces web est cruciale (je me demande toujours pourquoi JSF n’est pas adopté en masse – l’objet d’un autre article peut-être).

Pour les utilisateurs, le seul désagrément est la quasi-disparition du rafraîchissement des pages dont ils avaient fini par s’accommoder !

Les limites du “miracle GWT”

Sunday, July 8th, 2007

GWT au pays des Bisounours
Sentez-vous ce parfum d’euphorie un brin béat qui traverse le web à la seule évocation de GWT, cette propension à parer de qualités la librairie de Google parfois au mépris de toute objectivité ? Ressentez-vous à la lecture des différents articles de présentation l’ombre de ce doute face à cette librairie, dont on vous promet monts et merveille sans contrepartie ? Parfaite intégration avec l’existant, productivité multipliée par 5, la fin des migraines Javascript ? Se peut-il vraiment que tout soit aussi parfait ?
Non, bien sûr que non…
J’avoue ne pas être d’un nature très « groupie », et donc que les superlatifs provoque en moi au mieux un haussement de sourcil interrogateur, et bien plus souvent un réaction de méfiance face au merveilleux que l’on me promet.
Soyons clairs : je pense, je suis persuadé que GWT est une bonne librairie, un très bon outil. Pas moins. Pas plus non plus. En effet, elle résout nombre de problématiques liées aux développements Ajax et Web 2.0.
De là à dire qu’elle ne souffre d’aucun défaut, il y a un pas que je me refuse à franchir. Explication en détail…

Le syndrome de la librairie magique
Comme toute nouvelle librairie, les avantages de GWT ont tendance à en cacher les limites. Souvenez-vous du précédent « Hibernate » : l’accès aux bases de données devenait tellement plus simple que l’on a cru, à tort, que la gestion de la persistance se ferait sans mal, et mieux, sans avoir besoin de comprendre les mécanismes sous-jacents tels que transactions, jointures et accès concurrents.
On assiste ici au même phénomène : la création d’application Ajax est rendu tellement plus abordable avec GWT que l’analyse s’en arrête aux bienfaits sans en mesurer les coûts et les pièges. Ne vous faites pas d’illusion : une connaissance, même partielle, de Javascript et des mécanismes associés reste nécessaire pour éviter toute déconvenue.
A mon avis, GWT, tout comme Hibernate ou Java en son temps, résout 80% des problèmes, mais crée 20% de problématiques nouvelles et complètement inédites qu’il serait malhonnête d’ignorer ou de passer sous silence.

Le mythe de l’intégration avec l’existant
L’un des arguments les moins recevable pour le modeste auteur d’hibernate4gwt que je suis est de dire que GWT fonctionne sans peine avec les applications existantes.
C’est bien entendu parfaitement faux avec toute application Spring-Hibernate (pour rester sur des technos éprouvées).
Le simple fait que GWT ne supporte que la syntaxe Java 1.4 pour la partie JavaScript de l’application interdit d’utiliser annotations et collections typées, pourtant largement répandues dans nos applications. Il en découle l’impossibilité pure et simple d’utiliser les entités du Domaine dans la partie cliente d’une application GWT.
Face à ce problème, la communauté se contente pour l’instant de pis-aller. La plus répandue consiste à convertir les entités du modèle en DTO (data transfer objects) par l’entremise de Dozer, ce qui implique l’apprentissage d’une nouvelle librairie et l’écriture des fichiers de mapping idoines. Avouez que pour une intégration naturelle, on peut repasser…

Et encore, je vous fais grâce des problématiques propres à la coexistence des entités Hibernate avec GWT -/. Pour plus d’info sur ce sujet, je vous renvoie au site web d’hibernate4gwt, où j’ai posté un article sur le sujet…

Une documentation anémique
A la différence d’Hibernate ou de Spring, deux poids lourds de l’Open-Source cités plus haut, GWT ne bénéficie que d’une documentation, disons, sommaire. Quelques pages web couvrant les cas standard, mais rien concernant de manière exhaustive le fonctionnement de la librairie.
C’est d’autant plus gênant que cette librairie contient de nombreux concepts innovants qu’il conviendrait de mieux documenter (je pense notamment aux Serializer et aux Generators) afin d’en encourager l’adoption, l’usage et l’enrichissement.
Heureusement, quelques passionnés, tel Robert Hanson, ont pris le taureau par les cornes et entrepris un large travail de vulgarisation que ce soit sur leur site web (dont Timepedia est sans doute l’un des meilleurs exemples) ou par le biais de livres (le célèbre et pour l’instant relativement unique « GWT in action »), mais cela peut difficilement avoir la valeur d’un manuel de référence estampillé « officiel », nécessaire à l’adoption par le plus grand nombre.

Dans la jungle des widgets
Les composants graphiques GWT affichent une situation paradoxale : le framework en lui-même en propose relativement peu (cf. Kitchen Sink, la démo “officielle” GWT), et les librairies de composants tierces (Open-Source ou non) sont pléthores.
Pourtant, autant on peut faire confiance au caractère professionnel des widgets natifs GWT, autant on est en droit de s’interroger concernant les autres composants : quelle est leur fiabilité ? Leur pérennité ? Gèrent-ils convenablement l’arbre DOM ?
Bref, des interrogations que l’on ne peut évacuer d’un simple haussement d’épaule et qui demanderait une évaluation minutieuse, ou l’émergence d’un standard de fait, ce qui ne semble pas encore le cas.

Programmation graphique : un pas en avant, un pas en arrière ?
Avec sa programmation entièrement en Java et événementielle, GWT nous renvoie un peu à l’ère de Swing, avec ses avantages et ses inconvénients.
Au rayon des premiers, la programmation graphique retrouve enfin son unité, face aux innombrables lnagages nécessaires à une page JSF-Ajax (HTML, JSP, JSTL, Javascript,…)
Concernant les défauts, on notera la fin de la séparation entre design et programmation, tel qu’il avait été introduit justement avec les JSP/JSF.
Plus important, GWT n’est pas structurant en terme de programmation. Il n’existe pas à ce jour de framework standardisant la programmation d’une action, ou les règles de navigation, à la manière d’un Struts en son temps…
Du coup, chaque développeur a l’embarras du choix pour coder le comportement de son application, et au vue du forum officiel, nombreux sont ceux qui sont embarrassés par ce choix p. De plus, les projets y perdent en homogénéité, et donc le retour d’expérience sur telle ou telle pratique sont plus lents.

Conclusion
Ces manques, ces défauts, ne doivent pas vous faire perdre de vue mon propos premier : GWT est un très bon outil, sans doute le meilleur disponible concernant le développement d’application Ajax.
Mais au milieu de toute cette vague d’enthousiasme parfois sans recul, il me semblait important de ramener GWT à un juste statut : celui d’une librairie, utile et productive certes, mais dont l’adoption ne se fera pas sans impact…