Sur la route d’Oxiane disgressions diverses

L’événement annuel du monde Smalltalk européen, à savoir l’ESUG 2009, vient de se dérouler à Brest. OXiane y était représenté de deux manières : cité comme collaborateur du projet de Geomer avec Océanopolis et représenté par mon humble personne.

La plupart des gens s’attendraient à une réunion de vieux croulants ressassant les heures de gloire de Smalltalk. Il n’en est rien (j’étais le seul). Je reviens gonflé à bloc et convaincu, après avoir côtoyé près de 140 autres passionnés venus du monde entier, qu’une renaissance de Smalltalk est en cours. Smalltalk a toujours été un marché de niche mais la niche subsiste, prospère et la communauté se prend à rêver d’expansion sur des airs de « Yes we can ».

Un des grands intérêts de cette conférence internationale est qu’elle réunit industriels et universitaires. Nul doute que l’utilisation de Smalltalk dans les universités augmente et les deux projets phares que sont Pharo et Seaside constituent un réel espoir de changer l’image du langage et de lui donner un nouvel essor. Certains en profiteront ici pour conforter leur certitude que Smalltalk est un langage d’universitaires. Plusieurs faits leur donnent tort. Par exemple, j’ai appris que la branche Smalltalk de Cincom, distributeur des produits VisualWorks et ObjectStudio réunis dans une même offre appelée Cincom Smalltalk, voit son chiffre d’affaire augmenter régulièrement d’environ 20% tous les ans. Elle acquiert de nouveaux clients, augmente l’effectif de ses équipes et investit dans des développements comme son nouveau produit appelé WebVelocity, basé sur VisualWorks et Seaside.

Un autre fait marquant vient de la société Instantiations, qui nous a présenté les nouveautés actuelles et futures de VASmalltalk, le successeur du VisualAge/Smalltalk d’IBM.

Un troisième acteur industriel, GemStone, a aussi montré l’intégration du langage Ruby dans son système Smalltalk, ce qui devrait sans aucun doute augmenter encore l’intérêt et la coopération entre les deux communautés.

Lire la suite du bllet »

VMWare vient donc de racheter Spring, pour une somme assez conséquente, de quelques 420 millions de dollars (soit le prix de quatre Ronaldo et un Benzema).
Pour le coup tout le monde a été surpris. Autant le rachat de JBoss par Red Hat (pour à peu près la même somme) était stratégique, marketing, autant le rachat de Sun par Oracle était industriel, autant le rachat de VMWare pourrait bien être un investissement qui augurerait de beaucoup d’autres choses.

Spring a rarement fait n’importe quoi. Ils ont été très agressifs du point de vue marketing mais ils ne sont jamais sortis de leur positionnemment technologique et novateur. On peut le voir dans le communiqué de Rod Johnson : il y parle autant des perspectives technologiques que du mot “Simplicité” qui est - plus qu’un mantra - leur slogan.

Du côté de VMWare, on a une politique ambitieuse. Le recrutement se fait d’abord à très haut niveau. Les deux entreprises au recrutement le plus ambitieux sont Google et eux. Ils ont ainsi récemment engagé un core développeur du noyau de Windows NT. Certainement pas pour développer un pacman.
Alors, que nous réserve cette alliance inattendue? Quelle perspective technologique là dessous? Rod Johnson le pense, l’avenir est le cloud. Spring et VMWare souhaitent se positionner sur ce nouveau marché, comme PAAS (Plateform as a Service), alliant le meilleur et le plus simple des deux entreprises (pour reprendre un gimmick à la Spring).

Du moins ce que vient de dire SpringSource est clair. A la conquête d’un nouvel eldorado. Après la crise de 2008-2009, le renouveau. Les nouveaux farwests s’ouvrent à nous.
Mais qui sait ce que l’on va trouver au bout de cette nouvelle frontière? Dans cette course aux nuages…

Depuis quelques jours, Google a annoncé le support de Java 6 sur son infrastructure de Cloud Computing, Google App Engine  (autrement dénommée GAE).
Cette nouvelle est tempérée par le fait que toutes les API de java ne sont pas supportées. Ainsi, interdiction par exemple de créer un Thread, d’écrire un fichier…
La plupart des limitations sont structurelles et dues au fait que l’on est “on the cloud” - où la notion de Fichier, de Thread… est largement abolie, puisque l’on ne sait pas sur quelle machine sera déployée l’application.

Mais il existe d’autres limitations. Certaines sont des choix - comme l’impossibilité d’utiliser le package java.awt.* D’autres sont des erreurs due à la jeunesse - et au caractère novateur du produit - comme l’impossibilité d’utiliser l’annotation @MappedSuperClass de JPA (mais on peut utiliser JPA) ou l’obligation de créer un serialVersionUID pour les classes sérialisables. Ou cette erreur carrément mystérieuse, un  ClassNotFoundException sur java.util.Collections.unmodifiableList(<ma liste>)… Erreur que j’ai repéré lors d’un déploiement sur la plate-forme cible, alors que tout se passait bien sur la plate-forme de test en local…. Erreur de jeunesse là encore.
Google a écrit une White List qui liste les packages de la JRE autorisés sur son infrastructure. ( http://code.google.com/intl/fr/appengine/docs/java/jrewhitelist.html ) (et on trouve pourtant bien le support de la classe Collections).

Depuis cette annonce du support de java6 par la plate-forme GAE, tous leurs mainteneurs de frameworks Java se demandent si le fruit de leur travail fonctionneront sur GAE. Le test a été positif pour Groovy, Scala, Restlet, moins pour Jersey, pas bon les WebServices (JAX-RPC or JAX-WS) , OK pour Spring mais on ne peut pas utiliser la gestion de la transaction pour JPA, etc…
Le tableau de la compatibilité avec GAE est complexe, et n’a pas fini d’être rempli. Vous trouverez ici une liste des tests actuellement en cours sur chacun des frameworks.

Aujourd’hui nous allons voir qu’il est possible de déployer une application Wicket sur GAE - nous le verrons sur une application simple de type Hello World, partant de la création de l’application jusqu’à son déploiement.

Lire la suite du bllet »

Nous publions sur le site www.oxiane.com un dossier décrivant une manière d’intégrer des composants riches de type Ajax dans une application web (classique ou de type RIA), grâce à la bibliothèque Ajax JQuery et à JAX-RS, l’API Java pour les services Restfull.

Depuis plusieurs années maintenant, la plupart des applications sont développées pour être accessibles par un simple navigateur. Ainsi par exemple un gestionnaire de contrats d’assurance peut-il récupérer les données concernant son client en ayant une simple connexion internet. Ces solutions dites “client léger” sont faciles à déployer et à maintenir, mais souvent elles ne sont pas ergonomiquement satisfaisantes. Le besoin est grand d’avoir des applications qui s’exécutent toujours depuis un navigateur, mais avec des caractéristiques similaires aux logiciels de bureau : un arbre de sélection, un menu en accordéon, des changements dynamiques dans la page affichée…  Les frameworks RIA se sont développés notamment pour répondre à ce besoin. Grâce à  Flex, Silverlight, JavaFX ou GWT, on peut envisager de créer des applications multi-plateformes, aisément déployables, et “engageantes”.

Cependant, il est de nombreux cas où l’on aimerait avoir une application riche, mais sans forcément s’embarquer dans un développement spécifique avec un framework complet, qui ajouterait un langage (et donc une complexité) à l’application - mais en utilisant simplement html et javascript, si possible au travers d’une bibliothèque ajax toute faite. On peut imaginer cela dans au moins trois cas.

Il peut arriver par exemple, que l’on veuille, dans une application classique - par exemple écrite en Struts -  ajouter  quelques éléments ajax dynamiques, sans toutefois casser l’architecture générale. Pour cela, il convient d’avoir une méthode générale pour intégrer aisément des composants ajax dans une page jsp.

Autre possibilité : on aimerait s’appuyer sur le travail des graphistes et des spécialistes du web. Ceux-ci, depuis quelques années, sont devenus de grands connaisseurs des pages html dynamiques. Les bibliothèques Ajax - JQuery, Proptotype en particlulier - ont supplanté Dreamweaver dans les études qui montrent les outils préférés des développeurs web.  Nombreux sont ceux qui savent maintenant créer des interfaces graphiques dynamiques d’une ergonomie et d’une efficacité redoutable.

Troisième cas, on aimerait créer une architecture logicielle fondée sur une série de composants html/javascript réutilisables aisément, réembarquables tels quels dans des applications. Le but de cet architecture serait de venir faire une véritable application RIA - une Rich Internet Application - mais tout cela en client léger, sans se lier à un framework “maison” (Flex, Silverlight…). Plus loin, dans cette démarche, on peut envisager de créer des composants qui sachent eux même comment se présenter, comment s’afficher, et comment récupérer les informations côté côté serveur.

Pour réaliser cela, nous utiliserons dans notre exemple la bibliothèque JQuery, avec un de ses plugins (JQGrid) qui permet d’afficher de manière “sexy” un tableau dynamique. C’est ce composant qui se chargera du tri, de la pagination etc.

Pour intégrer les composants Ajax à notre back-end, nous utiliserons la JSR dédiée aux services REST (JAX-RS : “JAX-RS: The JavaTM API for RESTful Web Services”). Grâce à cette nouvelle API, nous irons récupérer des données  grâce à une simple requête HTTP (qui sera une requête Ajax). Il faut savoir que la JSR311 est bien plus vaste que cela puisqu’elle permet de construire des applications suivant  les principes Rest. Nous ne l’utiliserons ici qu’en partie, mais ce Proof of Concept ne demande qu’à être étendu.

Faire du RIA avec des composants ajax et des services REST.

Auteur : Gabriel Kastenbaum

Android est un système d’exploitation développé par un consortium autour de Google. Son usage est dédié aux Smart phones et autres téléphones mobiles mais on commence à le trouver également sur quelques Netbooks. Ce système d’exploitation est basé sur Linux et embarque en son coeur une JVM spécialement écrite pour lui.

10. Android s’insère particulièrement bien dans la stratégie de Google de faire passer l’information. A bien y regarder, que l’on utilise internet ou que l’on utilise demain son téléphone mobile, nous sommes entrés dans une ère où l’information circule, tout le temps, passe de main en main, le plus vite possible, sans s’arrêter. C’est vrai pour l’information “classique” - un soulèvement au Tibet ou le renversement du gouvernement Tchèque. C’est vrai aussi pour l’information dans les entreprises. Chez Dell, en quelques minutes, une commande prise par téléphone par une Irlandaise pour le compte d’un homme d’affaire en Hongrie sera mise en production dans une usine Dieu sait où.

L’information se balade sur une toile mondiale. Elle est accessible de n’importe où. C’est particulièrement frappant si vous prenez par exemple le RER pour rentrer de la Défense à Paris. De jeunes gens consultent sur leur téléphone les horaires de cinéma et les critiques des films pour organiser leur soirée, ou qui répondent à des mails professionnels de leurs clients. Une antenne et vous êtes connectés à toute l’information du  monde, que cette information soit très professionnelle ou très personnelle, elle viendra se livrer à vous, elle ne peut pas faire autrement.

Et dans ce monde de circulation, dans ce monde de foisonnement, Google se veut le Windows de l’information, le système d’exploitation de la circulation d’information. Main invisible ? Grand ordonnateur ? Ultime artisan de l’Ether [1] ? Il fait passer l’information. En délivrant un OS pour les téléphones mobiles, il apporte l’information au plus près de chaque individu. Cette démarche bien sûr doit amener à se poser des questions sur le monde avenir où un acteur a ici le quasi monopole des moyens de rechercher et de restituer l’information. Mais en même temps qu’une interrogation,  c’est aussi la réalité d’un monde qui change, d’une technique qui propose de nouvelles possibilités. A chacun de s’approprier ce nouveau monde fluide.

9 Timing : la technologie embarquée, les réseaux et les serveurs sont là. Le nombre de téléphones qui peuvent se connecter à internet ne cessent d’augmenter. Actuellement , 3 millions de Français surfent sur internet à partir de leur téléphone mobile, sur 55 millions d’abonnés, soit 8.3% des abonnés. Chiffre de février 2008. Or le nombre de  téléphones pouvant se connecter à internet va continuer à croître et le nombre de services augmentera lui aussi. On dirait une réplique de la vague internet des années 2000…

8. Une architecture ouverte au développement. La base de ce nouvel OS est un Linux (noyau 2.6) . Au dessus, vous trouvez une série de bibliothèques en C/C++ pour augmenter les capacités de ce système : bibliothèque Media, bibliothèques pour la 2D et la 3D, SQLite pour stocker les données…

Lire la suite du bllet »

A la surprise générale, Google sort son navigateur maison, chrome…

…mais vous le savez probablement déjà.

Pour une fois, je ne vais absolument pas parler technique. Il y a un autre aspect de google-chrome qui est d’ores et déjà surprenant, c’est le budget communication qui a accompagné le lancement du produit…

Résumons : l’envoi d’une bande-dessinée (très bien faite, soit dit en passant) à des blogueurs “influents”. Ah oui, et un billet sur le blog officiel de l’entreprise. C’est tout. Avouez que c’est pas cher, c’est un budget de PME.

Laissez agir, même pas besoin de secouer.

• Lundi vers midi, un blogueur annonce la bande-dessinée, reçue dans sa boîte aux lettres le matin même. Le site web http://www.google.com/chrome affiche encore 404.
• Google confirme dans la précipitation vers 14h et publie la BD en ligne vers 15h30.
• L’article wikipedia voit le jour à 16h17
• Mardi matin, tous les flux RSS ayant un rapport avec l’informatique parlent de chrome
• Téléchargeable mardi dans l’après-midi
• Jusqu’à l’article dans le monde le lendemain

…

• Et maintenant, vous qui me lisez vous vous dîtes “encore un billet sur chrome ; y’en a marre !”

Pas besoin de louer le CNIT, de faire une campagne d’affichage 4×3, de faire un lancement sur les champs-élysées, un feu d’artifice, ni de spots télé …

Je connais rien à la publicité mais je me plais à penser que la sortie de chrome devrait faire partie du programme de toute école de publicité/communication/marketing. Je pense même que pour le lancement de produit high-tech il y aura un avant-google-chrome et un après.

Décidément, ’sont forts chez google, non ?

Auteur :  Guillaume Rams

La très attendue version 1.5 de GWT vient d’arriver. Il s’agit d’un important pas en avant pour le framework de google et pour les développeurs java.

Pour rappel, GWT est une bibliothèque qui permet de créer des applications avec des IHM complexes, qui tournent sur client léger, et tout cela sans connaître javascript, car écrites complètement en java. Il est livré avec des outils de développement et de debug, et il est soutenu par une toute petite boîte américaine qui s’appelle Google.

Au menu:

Support de java 5. On pourra enfin utiliser les listes typées et les generics de Java 5, ils seront traduits en javascript. On pourra utiliser des classes du type StringBuilder, TreeMap qui seront émulés en javascript côté client. Grand pas en avant car il va permettre d’utiliser ce framework avec du code bien plus propre.

Amélioration des performances. A chaque version, Google améliore encore les performances de son framework. Selon les dires de Bruce Johnson, leader du projet, les développeurs qui ont utilisé GWT 1.5 ont senti une amélioration de x2. Quand on sait que le moteur Javascript de Firefox est lui aussi en grande amélioration de performance (voir http://xulfr.org/news/2008/08/28/259-tracemonkey-dans-firefox-31-le-javascript-qui-boost) et que HTML 5 pourrait bien être un bon cru, on voit que l’approche “classique” (html/javascript) se remobilise face à la concurrence des approches RIA (Flex, Silverlight…).

Amélioration des widgets : plus beaux, plus faciles à customiser accès à la CSS par défaut), plus accessibles (qui supportent la norme ARIA), plus fonctionnels, voire qui supportent les langues écrites de droite à gauche. DOM : Accès par une nouvelle classe qui mappe entièrement les recommandations du W3C.

Une meilleure doc (c’était pas bien difficile), mise à jour. Avec notamment une belle page bien parlante qui montre l’ensemble des widgets : http://gwt.google.com/samples/Showcase/Showcase.html

En parallèle, Microsoft crée son GWT pour la plateforme .Net. avec Volta. Mais ils se basent sur le bytecode plutôt que sur le code source pour générer le javascript.
(http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/9af068124dae8e04)

On peut distinguer quatre tendances dans la percée de GWT:

• Percée des frameworks webs à composants - au détriment des frameworks webs sur le mode request/réponse. Ils correspondent mieux aux mécaniques ajax, et à une réutilisation intelligentes des composants.
• Les frameworks webs peuvent se distinguer entre ceux qui permettent de créer des sites internet, avec de belles URL, une grande proximité avec le HTML (Struts, Tapestry, Wicket), et les frameworks qui permettent surtout de créer des applications web complexes, avec un moins grand respect pour les questions de présentation, mais une plus grande possibilité de faire des IHM très dynamiques (GWT et d’une certaine manière JSF). Wicket peut se placer dans les deux catégories: manipulation aisée du HTML dans le code java ; en revanche la capacité à créer des widgets n’est pas son plus grand atout.
• Il y a deux approches : L’une embarque la mécanique, les aspects dynamiques des pages, dans du (X)HTML. C’est l’approche traditionnelle (JSP, php, Struts, Tapestry, JSF…) qui correspond à l’architecture du HTML et qui embarque les données dans des tags. Et l’approche qui consiste à être le moins intrusif possible dans les pages HTML et décorer ces pages (Wicket, GWT) avec du code dynamique. (Tapestry est un peu entre les deux approches, avec à la fois la présence d’une taglib, et une décoration systématique et un grand respect pour les maquettes HTML).

Les frameworks HTML/Ajax ne sont pas démunis face aux solutions RIA.

Il faudra cependant que les normes (html, javascript), continuent à évoluer pour permettre la création d’interfaces graphiques nativement plus fonctionnelles, gérant par exemple : le Drag’n'Drop, la mise à jour dynamique de données (Comet), l’intégration des données et de la présentation (JSon).

Auteur :  Gabriel Kastenbaum

Je viens de regarder la démo de google sur leur nouvelle offre.
http://code.google.com/appengine/

Démo:
http://www.youtube.com/watch?v=bfgO-LXGpTM

La démo est simple:

• On démarre un petit serveur de test;
• Puis on développe une appli web qui tourne sur ce serveur démarré;
• Tout est développé en Python;
• On teste au fur et à mesure, pas de serveur à arrêter/redémarrer
• Lorsqu’on est satisfait on fait “appengine update” (une sorte de cvs commit + publish) et cela installe l’application sur le serveur distant !
• Et tout le monde peut accéder à cette application.

Le truc, par rapport à -par exemple- un serveur chez free, ovh ou autre, c’est qu’on est sur une infrastructure full Google. Avec ses choix, ses forces et faiblesses, etc.

Au lieu d’avoir une base de données + un serveur apache + un interpréteur PHP ou une JVM + un tomcat ou un autre package similaire, on a un environnement complet de développement complètement dédié à la plateforme.
Avec notamment -et surtout- une base de données google, accessible dans le code.

L’impression générale est très étrange. En fait cela me donne l’impression de donner accès à un énôôrrme AS400 en ligne. On fait du RPG 2.0 si j’ose dire : on a “les dents sur le serveur”. Les données sont juste là, toutes prêtes, dans le code …

En ce sens, c’est le même mouvement d’intégration que Seam -avec d’autres aprioris bien sûr- mais l’idée reste de re-rassembler des bouts éparpillés.

Avec un implicite de taille tout de même : faire des applis qui ne ne peuvent tourner que sur du Google. D’où peut-être cette impression de RPG ?

Qui cela peut-il intéresser ?

Les petite boîtes qui font leur développements en interne ? Il faudrait que le Python -langage de la plateforme- soit mieux connu. Et est-ce que la plateforme apporte les outils -en terme d’idées directrices de dev, de structures- pour faire du travail en commun par exemple, pour vraiment développer avec des gens “normaux” une application exploitable ? Je ne sais pas ! Par exemple quel est le lien avec la suite logicielle de Google ? Si lien il y a cela voudrait dire qu’en fait ce n’est pas son RPG mais plutôt son VB 6 ! Hélas, cela manque encore d’environnement de développement réel, pas d’IDE, pas encore. (next move ?)

Des éditeurs “googlelisés” qui développent des petites applis sympas pour cette plateforme ? Plutôt, oui.

Et des geeks bien sûr.

bref, à suivre …
Auteur :  Gabriel Kastenbaum