Jul

2

Testatoo: TDD for the GUI

By Olivier Gérardin

Test-driven development is a good thing. We all agree on that, right?

But TDD assumes you can write tests before actually implementing the functionality. How do you do for the GUI when most GUI test tools are based on a scenario-recording appraoch? This requires that the GUI already exists; in other words, another instance of the “chicken or the egg” dilemma…

My friend David Avenante (and host in Montréal for the confoo.ca 2010 conference), has been working on a solution to this problem called Testatoo.

From the web site: “Testatoo provides on one hand an abstraction of the UI business domain through an expressive API and on the other hand a way to express this domain via a DSL (a button semantically stays a buttons whatever the technology). With Testatoo you can therefore write tests with a seldom achieved level of expressiveness and make these tests INDEPENDENT of the underlying technology.”

Interested? The testatoo web site is now up, with tutorials, demos, samples, FAQ, and a forum ! Give it a try, and post your feedback…

May

6

DSLs and non-programmatic ways of expressing requirements

By Olivier Gérardin

I’ve known about DSLs for a while, but a very interesting presentation by Neal Ford at the TSSJS in Prague last year made me reconsider the subject. Before, I considered DSLs were applicable only in very specific situations, like where there existed a huge number of requirements that were expressed very formally. Think rocket launching for example.

But now I tend to think that in most situations, there exist requirements or business rules that could be captured more easily than by writing sentences in a requirements document, then writing more detailed sentences in a specifications document, then writing test cases to make sure the requirements are fulfilled, then implementing the logic in code. And then of course doing it all over again when the business rules change.

If we could express these business rules in a way that could either be interpreted at run-time, or be compiled into the software, we could skip all the chain. We wouldn’t need to validate the software’s behaviour (regarding these requirements) against specifically written test cases, because the integration mechanism  of those business rules would have been validated. In other words, if the software doesn’t behave as expected, it’s not because of a bad implementation, it’s because of a bad business rule.

I once worked with a company named ItemField (which is now part of Informatica) that had a technology (ContentMaster) to transform almost any kind of document (mostly Office documents, PDF and such) into XML, and vice versa. They had thought of extraordinary ways to use their technology; for example, by building an appropriate transformer, they could turn a formal specifications document into a parser for the format described by the spec. If that sounds esoteric, consider the specifications for SWIFT messages, also known as ISO-15022: it’s a huge collection of rules that define different kinds of messages, and how they can be constructed. Now imagine having to write a parser for all the message types… it would be a nightmare to code by hand and test because there are so many rules to implement! (Some have tried: see project WIFE – still a work in progress). Well, ItemField had written a transformation that generated XML parsers and serializers for SWIFT messages right from the specification! So if anything changed in the spec, they just had to run their transformation on the new spec, and that would generate new parsers and serializers. They called it specification-driven transformation.

Apparently ContentMaster was included into Informatica’s portfolio as part of their B2B Data Exchange product family, but I don’t know what survived of the specification-driven transformation.

Anyway, the idea behind this approach is dazzingly powerful: use business rules exactly as they are formalized . Don’t rewrite them N times using a different formalism, creating N possibilities for things to be misinterpreted by a human. For example, we know many domain specialists would write rules in Excel; given a technology such as ItemField’s, it is usually possible to parse these rules directly from the Excel sheet (provided they are reasonably consistently written), and generate whatever is necessary to incorporate them into the software. If rules change, the domain specialists update the Excel sheet, we run the transformation again, and that’s it. Once we are confident that the transformation works (and this means that it has been thoroughly tested!), we know that anything wrong with the business rules comes from the rules themselves, not from the code.

I think this is where we’re heading, generally speaking: giving more control to non-IT people over software, by shortening the way between their expectations and the software they use. MDD is part of this trend, because models are more likely to be understood and driven by users than programming concepts. If we take abstract models as a kind of formal specifications (which they are), then what applies to Excel sheets could also apply here, provided that we can automate and shorten the path from model to final software. This is not the easy part, I admit.

Agile methods of course are also part of this trend, in a different way, because they involve stakeholders very closely and often in the process, and also aim at shortening the path from specifcation to software. For example, in Scrum the product backlog plays the role of master requirements, and while it still has to be written by hand, it is the only artefact between users and the development team.

I think we’ll see this trend amplify over the next years. It might feel like this will ultimatley mean less work for IT people, I don’t believe it. But that might just be wishful thinking.

Jun

19

TheServerSide Java Symposium – Jour 2

By Olivier Gérardin

La journée d’aujourd’hui a commencé fort, avec un keynote de Neal Ford Language Oriented Programming: Shifting Paradigms. Une présentation impressionnante, avec des slides à faire pâlir d’envie Al Gore, et une parfaite maîtrise…

S’appuyant sur un cas concret, Neal montre que la façon de résoudre un problème dans le monde informatique d’aujourd’hui est souvent de créer un framework (aussi petit soit-il) qui généralise le problème, puis de le configurer pour résoudre le cas particulier qui nous préoccupe. Or cela conduit à du code qui est rempli de “bruit” (comprendre: redondance et constructions syntaxiques), illisible par les personnes du domaine métier, et donc ne peut être validé. Que fait-on alors? On externalise le code dans un fichier de paramétrage, XML forcément, mais ça ne le rend pas plus lisible par le métier…

La solution ce sont les DSL, Domain-Specific Languages, qui permettent d’exprimer des notions propres au métier d’une façon accessible aux hommes du métier. On peut les diviser en:

  • DSL internes: utilisant les constructions du langage hôte
  • DSL externes: indépendants d’un langage

Un exemple de DSL interne en Java est JMock, qui permet d’écrire des choses du genre:

one(gt).getGreeting(); will(returnValue(”Good afternoon”));

C’est ce quon appelle “fluent interface”, car on cherche à imiter le langage naturel, quitte à introduire des artefacts sans utilité (“bubble words”). En Java ça reste fortement contraint par la rigidité du langage, mais dans les langages dynamiques on peut faire des choses beaucoup plus avancées.

XML est une forme de DSL externe, a fortiori.. Mais selon Neal XML est obsolète ! (Pas de polémique…). Le futur c’est de modéliser le métier à un niveau d’abstraction supérieur, que ce soit via un langage ou en manipulant un arbre abstrait (ce que certains IDEs tendent déjà à faire), et ensuite d’exécuter le résultat dans un contexte qui, selon le cas, donnera un schéma de DB, un exécutable, etc.

Ce fut de loin la meilleure conf des 2 premiers jours, prenante et stimulante…

Ensuite je choisis d’assister à la conf Son of SOA: Event-Driven Architecture and the Real World, par Eugene Ciurana (LeapFrog). Ca commence par des challenges (calendrier serré, équipe à construire, politique IT rigide, existant à intégrer, …) qui sont autant de challenges si on les voit d’un autre angle. Le choix a été de mettre en place un architecture Resource-Oriented, où tout est considéré comme une ressource, services comme données, et acccessible par une URI. Même si ça ressemble furieusement à du REST, Eugene s’en défend; en effet il y a quelques différences, notamment le mélange entre verbe et nom dans l’URI, mais globalement la différence est si fine qu’elle est invisible.

Eugene a mis en place des outils “best of breed”, avec MuleESB à la place d’honneur, en tant que backbone et resource container. Aussi choisis: Crowd pour le SSO, GWT (tiens…), Wicket, Communiqué (CMS). Au final une success story bien ficelée.

Ensuite je vais découvrir Comet: Building a richer, more interactive web application, avec Ric Smith de kaazing.com. Il s’agit d’expliquer les mécanismes qui permettent de faire du reverse push, ou reverse AJAX, c’est à dire de permettre à une application AJAX d’être notifiée par le serveur de nouveaux événements, par opposition au polling où c’est le client qui interroge périodiquement le serveur. Les avantages sont clairs dans des applications type finances, jeux ou paris, ou tous domaines où le 1/10 de seconde peut faire la différence.

Historiquement, la première façon d’implémenter le push est un iframe invisible, dans lequel le serveur reçoit en continu des balises <script> qui déclenchent l’exécution de callbacks côté browser. Ca marche, mais avec des effets de bord parfois très gênants (clignotement du curseur, fuites mémoire, …).

Deuxième technique, le XHT long-polling: le client lance une requête qui ne revient que lorsque des données sont dispo. La connexion est fermée, et ré-établie immédiatement. Problèmes: léger overhead dû à la reconnexion, et latence possible.

Autre option, XHR streaming. Pour cela, on a besoin que le browser implémente “onreadystate”. La réponse à la requête XHR ne se termine jamais, et lorsque des données sont dispo un callback est appelé. Principal souci, le support limité de cette fonctionnalité dans le parc de browers.

Dernière option, la connexion socket, qui nécessite un plugin (Flash, SIlverlight, Java). Ici on s’appuie sur des fonctionnalités du plugin pour établir une connexion serveur rémanente et notifier le browser.

Enfin, à l’avenir HTML5 intégrera la notion de server-side events, et le serveur pourra alors envoyer un type MIME application/x-dom-server-event qui activera un callback. Mais ce n’est pas pour demain.

Un point important à considérer est le couplage connexion-thread qui existe dans les serveurs classiques; en effet si 100 000 clients sont en attente d’évenements, on ne peut pas admettre de créer autant de threads. Jetty et d’autres résolvent ce problème avec la notion de “Continutation” qui permet de rendre les threads indépendants des connexions.

Un tour d’horizon super intéressant du problème !

Avant de manger, un Expert Panel: Languages: The Next Generation, composé de Ted Neward, Ola Bini et Guilaume Laforge, discute de la prochaine génération de languages. C’est très divertissant, et il en ressort surtout qu’il n’y aura pas de “next big language”, mais que comme Neal Ford l’a prédit, les DSL vont prendre le devant de la scène, avec les langages dynamiques…

Midi, cette fois j’ai compris le truc pour ne pas faire la queue aux plats chauds: d’abord le buffet froid où il n’y a personne, ensuite les plats chauds!

Je saute le Vendor Tech Brief, encore GigaSpaces (eh oui ils sont le principal sponsor). Je vais récupérer mon T-shirt JavaBlackBelt gagné au concours hier, et une petite démo de JavaRebel s’avère assez impressionnante: rechargement à chaud des classes sans arrêt redémarrage! Un confort et une productivité qu’on a oublié sous Java, à force d’appeler des scripts ant et de redéployer à tout bout de champ.

The Enterprise Without a DB, par John Davies: ça fait longtemps que je traîne l’obligation de travailler avec des bases relationnelles comme un boulet, d’où mon intérêt pour ce sujet. John montre l’absurdité de la situation: le schéma FpML compte plus de 4000 éléments, et peut aller jusqu’à 12 niveaux de profondeur. Il est quasiment impossible de mapper un tel schéma avec un ORM. Les DB XML de leur côté n’ont pas d’API standard, et ont des performances sous optimales. Ce que propose John: utiliser le caching, la mémoire quoi, et travailler avec un data grid. Il cite plusieurs outils qui tendent vers ce but: GemStone, TangoSol (acheté par Oracle), GigaSpaces, Terracotta.

Malheureusement, de trop nombreux outils (reporting, etc) et un poids historique des tenants du camp “DB” rend cette approche exotique, et pour encore longtemps.

What’s new in EJB 3.1, par Anotnio Goncalves: Non EJB n’est pas mort! Même si la spec 2.1 l’a presque tué… Aujourd’hui les EJB 3 (JSR 220) sont un soulagement pour qui fait des EJB: POJOs, interfaces simples, injection, annotations, peu de XML à écrire… Les EJB 3.1 (JSR 318) ont pour objectif de les rendre encore plus simple à utiliser, et d’amener de nouvelles foinctionnalités. On note déjà que JPA a son propre JSR (317), ce qui aidera peut-être à redorer son blason. Ensuite l’interface locale devient facultative! l’injection reste obligatoire. Il sera aussi possible de packager des EJB dans un WAR tout simplement, en gardant la fonctionnalité EJB. Enfin différents profils seront définis: A (minimal, pas d’EJB), B (EJB lite), full (EJB complet plus une trentaine d’autres specs). Nouveau encore: la notion de singleton, les appels asynchrones, et le timer service.

Java EE 6 (sortie Q1 2009) embarquera EJB 3.1.

On finit par un Fireside Chat: Zero Turneround in Java Development, où je revois les démos JavaRebel et Grails, plus Geert Bevin (Uwyn) qui présente RIFE.

Rendez-vous demain pour la clôture!