Before talking more about the conference, I have to thank Globalcode (in special Vinicius and Yara). They did a great job =)

Since last year, the premise of the conference is to have people from all kinds of backgrounds, from a lot of different communities, like Java, Ruby, Python, Agile, Javascript, .NET and lots more. Each day featured five different tracks, with different topics, to fit all those communities and tools. The result is that we had a lot of different people and lots of opportunities to talk to people you usually would not encounter. This was a really enriching experience.

In a personal level, this conference was special to me: I made two ‘speaking’ participations. In one of them I talked about Scala, an introductory talk (you can find the sample code used in the talk in my github). The other one was a panel consisting of people from different languages on the jvm – lots of fun =)

In the event, I had one personal fail moment, that should remain as a tip for everyone out there. In a given moment, when talking to someone, I was asked for my business card… and didn’t have any on me. So the obvious tip: always have business cards with you. Always.

Now, if you follow my posts about events you may have noticed that this one is a little different. It contains no pictures. This is due to a second fail, that happened on this last Monday. I lost (or it got stolen…) my mobile. And with it, all the pictures from the entire event. Sorry =(

Thank you all =)

Well, actually, it wasn’t. Comparing two sets of XML can be really tough. Initially, I considered doing so by hand. Bad, bad idea, because:

• You can’t simply say xmlString.equals(xmlString2) – any white space, including those indentation of yours will make the test fail;
• The same equals call mentioned above will never say that <mytag></mytag> is the same as <mytag/> – and it almost always is;
• How would you consider namespaces at all in those circumstances?
• To solve all of the problems above, you could parse the XML data and verify each node… manually. A whole lot of work.

equals is totally out of the game for the reasons mentioned above. And I’m too lazy to check manually each node of the XML data. Also, such verification would be very error prone.

A better solution is needed, and after some ‘googling’ around, I found XMLUnit. In summary, what it does is that manual verification… But well tested and guaranteed to work – it is a framework developed specifically with that purpose in mind.

This is how a JUnit test using XMLUnit looks like:

import org.junit.Test;
import static org.custommonkey.xmlunit.XMLAssert.*;

public class SampleJCrankyTest {
    @Test
    public void testXml() {
        // this test will pass =)
        asssertXMLEqual("<myxml></myxml>", "</myxml>");
    }
}

This code is using JUnit and, obviously, java – but they seem to be developing a .Net version as well, if you prefer that – its just not as complete as the Java version.

There is a lot of additional xml related features supported, so a look in the documentation is recommended. But concluding, if you need to make xml comparisons, please do yourself a favour and don’t even consider doing any kind of manual testing – go for XMLUnit.

Have you ever faced this kind of problem before? How did you solve it? Please leave a comment! =)

People who read my blog for sometime now probably know I like agile software development. One of the strategies it uses (from eXtreme Programming) is pair programming, and I talked about it a long while ago here.

Now, to the point. What I found out is that, at least for me, pair programming has one more advantage that I was not used to pay attention to: it can help you get motivated. Just having to explain my ideas and having to listen to my pair’s ideas goes a long way in terms of motivation. As I love what I do, this conversation “thing” helps me get back to reality and be productive.

If you cannot do pair programming constantly, what I would suggest you should do is, as soon as you’re feeling you’re not doing as well as you could, do some short pairing. Even if at least for an hour or so, it should help renovate your thoughts.

Now get your hands dirt, try it out and post a comment with your opinion! =)

Two weeks ago, we had the OpenTDC 2009. And this last Sunday, we had the Falando em Java (Speaking Java) 2009. Those two were very busy weeks!

As OpenTDC, Falando em Java was a very nice event. Interesting presentations, and a lot of nice people. A lot of them were, actually, present at both conferences.

Again, we had a handful of people from the office present:

The Team at Falando em Java

The event started with some guys (sorry, I forgot their names!) talking about the history of the event, and of Caelum (the event organizer), and about how they both have been growing these last few years. Nice but could feature less marketing.

Opening

Next, we had Jim Webber talking about SOA. Very good! This was the first time I saw him talking, and he really knows what he is doing! This, and the latter one, were the best presentantions of the event, no question.

Jim Webber

During OpenTDC 2009, Bruno Sousa introduced us to Juggy, and talked a little bit about the next big java event in Brazil: Just Java (and I’ll be there!). This time though, I managed to get a better picture:

Bruno & Juggy

Ok, not that much better, but anyway…

A couple of other presentations followed and then it was lunch time! Nice:

Lunch

After lunch, two more presentations, a break, and then the second international one. This one was supposed to be given by Bill Burke, but he couldn’t attend due to Visa problems. So Jim Webber did it, and very nicely so. The topic: Restful Web Services.

From here on, I don’t have more pictures, my battery run out! But there were only a few things left: some gifts and the closing, plus some beer to end the day.

The event started with Bruno Sousa talking about Open Source development and the Community. In the end, he introduced Juggy to the audience – don’t ask, see the picture bellow.

Bruno & Juggy!

Shortly after that, we had a very, VERY interesting presentation on robotics. Made me want to learn electronics – really! I want to play with those things!! And you can somehow control it with Java! What?!

Robo-Java

Then there was a short break for coffee and networking – I used a little bit more time than planned, and lost the beginning of the next presentation: J2EE architectures with JBoss Seam, JSF and/or Spring. No problem, I didn’t lost the most interesting part which probably was the second half of the presentation – great job, by Vinicius Senger and Alberto “Spock”!

Archictectures

Finally, time to lunch! We (and a huge number of people from the event) went to the local Burger King. Big queue and healthy-less food – but we do this kind of thing sometimes, right? The only drawback: I forgot to take pictures there…

The afternoon featured nice talks on Agile, Java and Digital TV, and a panel on Java FX, GWT and Flex. This last one was specially interesting, although I find strange to have GWT here, since it is totally different from the other two. JavaFX and Flex are clearly competitors, but not GWT.

JavaFX, Flex and GWT

Want to see more pictures? See these links to official ones:

• Picasa
• The Developers Conference

In summary, the day was very good. I learned new things, and met some nice people again. I look forward to the next one!

Wait! Before signing off, here is a picture of some people from the office:

Fábio, Danielle and Diego

Bye for now!

For me, its every one those and than some more. I recently translated this InfoQ article about such topic, and it really made me think about the idea. Maybe I’ll try something like that at some point in the future.

You can find the portuguese translation here. Please feel free to post any comments you have, as I’m very interested in the subject!

My contributions consist basically of translations of some of the articles published in the english version. If you are interested, I created a page listing my contributions, with links for both the portuguese and english versions (when still available) here.

When I first started using agile (eXtreme Programming in my case), one of the things that called for my attention the most was its focus on Accuracy and in avoiding Waste. This means that when developing software using an agile methodology, we always try to build exactly what the client/user want. Nothing less, nothing more. Having developed some things before using methodologies closer to traditional ones, I was urging for someway to stop doing useless work and wasting time (diagrams that would never be touched again anyone?). Agile seemed to be a good bet.

But this all is a little bit abstract. Like I said here, this is just saying that we will try to bring the most value to the client. Now looking into something more practical, there are some interesting things that we can use in a daily basis that also help us improve software quality, among them:

• Pair Programming: two developers, instead of one, work together to solve problems. I talked previously about this here.
• Pair Rotation: to avoid that the pairs get “accustomed” to its pair, we can constantly change the pairs that works together. This also helps leveling up the team knowledge and experience.
• Tests: this is another invaluable practice that should be done in a daily basis. There is too much to sum up in a few lines. I’ll just mention two types of tests: unit and acceptance. We use unit tests to make sure the each individual feature of a system is working, and acceptance tests to guarantee that the whole system is ok, from a perspective similar to what the actual users have.

That’s it for now. I have a few other topics to write about in the pipeline, but if you have any ideas / suggestions for things you would like to see here, please don’t exitate to post a comment!

Bye!

A few days ago, while I was searching for ways to improve the tests in our projects, I found an interesting article with some ideas. The main concept was to make the tests behavior, data and actual implementation separated. The original article can be found here. In this post, I’ll talk about the first of those things we decided to implement here: getting the data separated from the tests implementations.

First, if the data is not to be inside the test implementation, it ought to be somewhere. Where should it be? The answer is anywhere you decide it is easy to change. Better yet if it can be changed by non-programmers as well. In our case (and in the mentioned article’s example) we are using Excel spreadsheets.

Here is an example of how this looks like:

Data in an excel spreadsheet

It is most likely that almost anyone can edit this file. So if you have someone that is not involved in programming (like a client), this person should be able to edit this spreadsheet pretty easily.

After having the data ready, you need to access it somehow. To do this, we are using the Apache POI project, which makes accessing and reading this file (and any other MS Office files) pretty easy. The code bellow would read all cells in the spreadsheet and print them out.

HSSFWorkbook wb = new HSSFWorkbook(new FileInputStream(fileName));
HSSFSheet sheet = wb.getSheet(sheetName);

for (Iterator<HSSFRow> rit = sheet.rowIterator(); rit.hasNext(); ) {
  HSSFRow row = rit.next();
  for (Iterator<HSSFCell> cit = row.cellIterator(); cit.hasNext(); ) {
    HSSFCell cell = cit.next();
    System.out.println(cell.toString() + " ");
  }
  System.out.println();
}

Now, if you want to know if the correct user listing is being returned from some business logic implementation, you would only need to change that code to compare the results read from the files with the ones returned from your business class. The business rules changed? Change the file and the new expectation will be in place, without even having to touch the test code, unless of course it is a change in the structure of the information.

The next problem that my arise is that you probably have a LOT of tests. Or at least you should have… Anyway, having a spreadsheet for each one would be suicide. Tons of files to handle! So what we can do is to create one spreadsheet per test class. Inside the file, we create one sheet per test. The footer of the spreadsheet then looks like this:

Multiple sheets in a spreadsheet

And that’s it! What do you think? Any ideas on how to improve this even more? Don’t be shy and post a comment!