Pendant la conférence Agile 2008, notre collègue Dave Nicolette de Valtech US a animé avec Karl Scotland une session présentant TDD à des managers. Cette présentation est maintenant disponible en vidéo.
Leur approche est intéressante: ils utilisent Excel (un outil qui parle bien aux chefs!) pour démontrer comment un développeur fait du code piloté par les tests. Un bon argument à utiliser pour persuader son chef de l’intérêt de notre travail!
Un avantage de cette présentation par rapport à celles faites à XP Day ou ailleurs (je crois qu’il s’agit de la 3e ou 4e fois que cette présentation est faite), c’est que l’audience est composée principalement de managers n’ayant pas de compréhension réelle de ce qu’est TDD.
Cyrille Le Clerc & Nicolas Griso spoke yesterday about OSGi at the ParisJUG. We had a big picture of this specification: where does it came, history, governance, early adopters, future adoptions and expectations (french readers can consult this post).
The OSGi platform is a native competitor to JavaEE. Although, if you are not a middleware vendor, do not switch right now. It lacks productivity tools like annotations (due to old profiles compatibility: J2ME, J2SE1.1), testability is also immature (out-of-the platform testing is not provided, should reminds you old J2EE).
Keep it on your disruptive technology radar because it is really promising. In particular, have a look on the SpringDM (Dynamic Modules) initiative that adds the equivalent to the eclipse extension points. Then, you can declaratively add your business services (Spring beans) as OSGi-level services to contribute to the platform.
La conférence Agile 2008 a lieu dans 3 semaines seulement! Ce sont déjà les tout derniers moments pour s’inscrire (plus de 1200 inscrits il y a une semaine, sur 1600 attendus).
Valtech sera présent à cette conférence. 3 des sujets que nous avons présentés ont été retenus:
Par ailleurs, Eric Lefèvre a co-organisé la track Breaking Acts, une serie de sessions cherchant à faire avancer nos connaissances sur l’agilité.
Nos collègues des autres filiales de Valtech ne sont pas en reste. En particulier, Valtech US assure 8 sessions (!), plus une pour Valtech UK:
Avec un total de 12 sessions, il semblerait que Valtech fournisse le plus gros contingent de présentateurs 
Si vous vous rendez à Agile 2008, certains d’entre nous serons reconnaissables à leurs polos Valtech.
Si vous ne pouvez pas vous joindre à nous à Toronto, n’hésitez pas à assister à la présentation de Gilles sur TDR dans nos locaux, lundi 28.
Certains savent que je ne suis pas amateur de traductions françaises de termes informatiques. Franciser des termes répandus dans le monde anglophones et qui n’ont pas d’équivalents directs en Français me parait contre-productif. En effet, l’amateur francophone qui cherche des informations supplémentaires ne trouvera que les (rares) documents en Français ayant adopté une convention peu utilisée en pratique. Il aura également plus de difficulté à communiquer avec 95% de la communauté informatique, qu’elle soit anglophone de naissance ou simplement non-francophone.
Lire la suite »
Publié le 28/06/2008, par Eric Lefevre-Ardant dans Uncategorized | Comments Off
These days, I have had the opportunity to think more about Behavior-Driven Development (BDD) with tools such as JBehave, RSpec, TestDox, and Test-Driven Requirements (TDR) with tools such as Fit, FitNesse, GreenPepper, Concordion. Here are my conclusions.
There is no doubt that BDD helps write tests with a more functional focus. This is also what TDR tools do and there is some overlap.
BDD and TDR help focus on client needs (write the ‘right code’ as opposed to the ‘right code’, as achieved by TDD). However, tooling is more developer-focused for BDD, and business-analyst-focused for TDR.
Therefore, TDR appears to me as a great tool, when business analysts are well integrated with developers. For example, they are part of the same Scrum team, or at least available regularly during the course of an iteration for the Sprint Planning and for conversations aimed at explaining what’s behind the story. TDR helps in making sure that all parties are clear regarding what should be coded (and what has actually been coded), while having no more than a simple user story to begin with. TDR is then mainly a communication tool between technical people and business people.
See a post by James Shore for more on that aspect of TDR.
However, I feel that BDD is an appropriate tool when developers receive specifications from an external team of business analysts, written maybe several iterations earlier. This is not an ideal situation, but it does still occur. In this case, developers should not waste their time with a tool such as Fit which is not the most efficient from their point of view.
BDD also seems great when the whole team is made of very technical people, able to read source code everyday on their own machine. Committers on an Open Source project would be a good example (how often do you ever hear of business analysts contributing to an OSS project?). Another example would be small and focused teams in start-ups that have an excellent understanding of what should be implemented (especially if this team is the one that created the start-up, as it often happens).
Last thought: just like other techniques (such as Pair Programming), it might be that BDD increases cohesion within the team, while creating protection from an outside world that is not as agile as the team. So it is possible that future improvements on the project such as integrating business people in the team might be harder to achieve.
If you can read French, check out this discussion on the XP France mailing list.
Publié le 27/06/2008, par Eric Lefevre-Ardant dans Uncategorized | Comments Off
After a pointer by Jérôme Piétri, a colleague of mine at Valtech, I have had a look at RichNesse, a WYSIWYG interface for editing pages under Fitnesse. It is based on FCKEditor. All in all, I am impressed.
As it is, RichNesse comes with a number of buttons that helps with the format of your wiki page. The format will eventually be converted into the appropriate Fitnesse markup, which you’ll see if you later visit the usual Edit button.
Those buttons in themselves are very useful. I don’t know about you, but in my case, I often have to go from one wiki engine to another, depending on the client and on the project. And I continually get mixed up for the first few minutes I edit a wiki page. Those WYSIWYG buttons really help.
Here is a look to the RichNesse editor (note the button bar on top)
Compare to the old editor:
There are four features that make the difference:
- Undo/Redo; yep, it seems that everything you do while under the editor can be undone
- Search and Replace! That was not in the basic editor. So when you wanted to change the name of a variable, you had to copy & paste into a text editor, and copy back again. It’s now built in!
- one button to insert a whole column: saves tons of keystrikes
- a button that redirects to the upload section of Fitnesse; that was not in the basic editor.
Unfortunately, I spotted a number of limitations. None of them are very serious, though:
- Some formattings very specific to Fitnesse such as collapsible sections are not available yet.
- The Copy and Cut buttons did not work and Paste behave curiously. The message I got was that my ‘browser security settings don’t permet the editor to automatically execute cutting operations.’ Of course, Ctrl-C, Ctrl-X and Ctrl-V still work perfectly.
- Integration with Fitnesse is not perfect. For example, if you create a table, the wizard will allow to enter a ‘caption’. Unfortunately, this caption will mess up the display and prevent the table from being properly interpreted as a fixture.
- The editor that opens when you first create a page is the basic Fitnesse editor. This is not a big deal: you can always save the empty page and reopen it again.
Another feature that I’d like to see, but will no doubt be tricky to implement, would be some kind of search & insert feature for links to other pages. Fitnesse is rather complex on this, especially since it supports hierarchical pages (a concept not usually found on wikis). It’s be cool to be able to search for a page, and then specify whether you want to link to it as a sub-page, or an absolute URL, or even as a SymbolicLink.
All in all, it is a very useful addon to FitNesse, one that I now systematically install. No doubt that lots remain to be done, but come join the fun now, it is already worth it!
Note the RichNesse button on the left when viewing a page; the Edit button is still available
Publié le 26/06/2008, par Eric Lefevre-Ardant dans Uncategorized | Comments Off
The Conference on Continuous Integration & Testing, Asia edition, is tomorrow! I wish I could be there, but the plane ticket is unhelpfully expensive 
Well, I’ll have to make up by going to CITCON Amsterdam in October! Who’s joining me?
Cobertura and Maven: There are TWO important things to do. Then, we’ll see about integrating Cobertura and Hudson.
First, set Cobertura as one of the reports in pom.xml:
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.2</version> <!-- use last version available -->
</plugin>
</plugins>
</reporting>
Finally, to get the actual report, you must remember to run ‘mvn site’. The reports will *not* be generated when simply running the unit tests.
For configuration, you must add a <plugin> tag in <build><plugins>; this is optional if you are only interested in Maven Site Reports. Remember: this does *not* mean that coverage analysis will be done when testing or running the code, only when running “mvn site”.
If you want the coverage reports directly under Hudson (and are not satisfied with publishing the maven site reports), things gets messy. There is a plugin for this, but I couldn’t get it to work (some people report that the current version, v0.8.4, is broken; it could also be because I’m using a Maven 2-type job under Hudson, which is not the most stable)
First, install the Cobertura-Hudson plugin.
This plugin requires XML reports to be generated by Cobertura. Looks simple enough according to the documentation.
The wiki page for the Cobertura plugin states that the configuration should be done in the <build> tag, but that didn’t work for me. In my case, I had to do it in the <reporting> tag, as follows:
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<formats>
<format>html</format>
<format>xml</format>
</formats>
</configuration>
</plugin>
</plugins>
</reporting>
That’s it from me. I hope you’ll have more luck than me with the Cobertura plugin. Anyway, don’t forget that you can always look for the report on the Maven-generated site. You can even create a Bookmark to it, since the page is stable (except when the build overrides it, of course).
Publié le 17/06/2008, par Eric Lefevre-Ardant dans Uncategorized | Comments Off
Readers to this blog know that I take every opportunity to talk about Hudson, one of the very best Continuous Integration tools. Well, I have another very good reason: you can contribute to it and make money, at least if you let yourself known before the end of June.
Sun has started what they call the GlassFish Awards Program. Under it, contributions to some projects are eligible to cash awards. One of these projects is Hudson, and what’s important is that not too many contributions have been made so far, so it is likely that yours could actually get money!
Many types of contributions are accepted: courseware, user-groups, plugins… as for me, I intend to submit the translation to French, as well as my Fit plugin — that is, if I can get moving before it is too late 
It is not easy to say how much money can be made. It depends on the quality of the submission, but also on the number of submissions that are accepted. I guess it should be rather easy to make a few hundred US$ (of course, as Kirk Pepperdine says, that’s probably only a couple of euros ).
How wrong I was when I said that Sun was not founding Hudson much!
I have originally had a look at Scrum and XP From the Trenches around 2 years ago, I think. It seemed to be good, but too long, so I barely scrape the surface.
Recently, I have had a longer look into it, and there is now no doubt that it is a great document.
The thing is, there is little formalized documentation on practices actually put in place in real Scrum project. In Ken Schwaber’s books (at least in the first two — I haven’t read Entreprise Scrum yet), you’ll find case studies, personal comments and the like, but few simple, practical techniques. On the internet, you will find those practical techniques, but scattered on many blogs, mailing lists, InfoQ reports, etc.
Scrum and XP From the Trenches seems to be the only one to attempt to group many of those practices in a single document, backed by actual experience on the field.
At times, it can be frustrating (”we thought this other technique sounded good, but we didn’t give it a try”), but most of the time, advices are excellent. At the very least, they give you support to talk to your team (”hey, this thing here worked for these guys; why don’t we give it a try?”). And occasionally, you’ll learn that unintuitive pratices worked (for example, they did try colocated teams, as they were fairly happy with teams spread on several sites).
This is now a book I regularly point to at the end of the Scrum courses that I give for Valtech Training.
