leonardoborges.com

the not so usual geek stuff…

When testing it’s pretty common to see the need for mocking a certain object, say, a Data Access Ojbect. This way you don’t need to depend on a database and you can focus on the actual logic implemented by the method being tested.

For that you have several alternatives like creating the Mock class by hand or - and this is the more common - use one of the various mocking libraries out there.

They all look the same but the past couple of days I’ve come accross to a new - at least for me - mocking library for Java. It’s called Mockito. As the creators state, technically, Mockito is a fork of EasyMock.

I have used EasyMock already but I do think Mockito has its advantages. I find it clear and a bit less verbose to write.

From one of the stubbing examples on their website:

//You can mock concrete classes, not only interfaces
LinkedList mockedList = mock(LinkedList.class);
 
//stubbing - before execution
stub(mockedList.get(0)).toReturn("first");
 
//following prints "first"
System.out.println(mockedList.get(0));
 
//following prints "null" because get(999) was not stubbed
System.out.println(mockedList.get(999));

Looking forward to using it in production!

This is quite funny. A friend, Perl addicted, is now learning Ruby. He really enjoys the language but made a interesting observation: Ruby is a language for lazy programmers!

Well, I have to agree… You know, I love saving keystrokes and achieving more by writing less. And this is so true with Ruby.

Let me give a really simple example, comparing with java - don’t get me wrong… I love java, specially the platform, but it fits well here since I’ve always been a Java guy.

Imagine you have a Phone class with the attributes number and type, which can indicate whether the phone is a land line or a mobile phone. Then you got an array filled with phone classes and you want to narrow it by creating a new array only with mobile phones.

In Java, such a class could look very much like this:

public class Phone {
  private String number;
  private String type;

  public String getNumber() {
    return number;
  }
  public void setNumber(String number) {
    this.number = number;
  }
  public String getType() {
    return type;
  }
  public void setType(String type) {
    this.type = type;
  }
}

Quite simple, isn’t it? But we are telling the compiler many things we actually shouldn’t need to. This class is a java bean and as such, among other things, it needs a pair of getters and setters for each of its attributes.

Now, on with our example, the same class, in ruby, looks like this:

class Phone
  attr_accessor :number, :type
end

Yeah, I know the feeling. This class has exactly what we need: the two attributes with its own pairs of getters and setters each. But we didn’t need to inform it in the verbose way Java has teached us. Cleaner, period.

Now to the code that actually returns the new array containing only mobile numbers. In java, we can do it in two different ways.
Using an ArrayList:

//Create two phone objects, one land line and one mobile
...
// Add them to an array
ArrayList
 phones = new ArrayList
();
phones.add(land);
phones.add(mobile);

//Return an array only with mobile numbers:
private static ArrayList
 selectMobilePhones(ArrayList
 phones) {

  ArrayList<Phone> mobiles = new ArrayList<Phone>();

  for (Phone phone : phones) {
    if (phone.getType().equals("mobile")) {
      mobiles.add(phone);
    }
  }
  return mobiles;
}

Or using ordinary arrays:

// Assume the same phone objects here
...
//Add them to the array
Phone[] phones = new Phone[]{land, mobile};

//Return an array only with mobile numbers:
Phone[] mobiles = new Phone[a.length];

for (int i = 0; i < a.length; i++) {

  if (a[i].getType().equals("mobile")) {
    mobiles[i] = a[i];
  }
}

And you’re good to go. Actually this code with an ArrayList here only looks good thanks to generics. But this is another matter. Let’s take a look at the ruby code that accomplishes de same task:

//Create two phone objects, one land line and one mobile
...
//Add them to an array
phones = [land, mobile]

//Return an array only with mobile numbers:
mobiles = phones.select { |phone|
   phone.type == "mobile"
}

See the difference? Java is a great language but too verbose at times. This is a really simple example but if you take the same principle to a bigger app… yeah, you see where I’m going.

The bottom line… Ruby may be the language of the lazy programmer, as my friend pointed out. But I don’t mind being called lazy as long as I can type less and be more productive. Do you?

Today was the first day of the conference and it started with a tutorial about DSL’s with Martin Fowler, Neal Ford and Rebecca Parsons. We also had as attendants Ola Bini, core developer of JRuby, and others. My expectations were pretty high and the presentation didn’t let me down. I’ll try to put here toghether my impressions and some notes I took while I was there.

Marting Fowler started discussing what DSL’s are and giving some examples that many of us use in our day to day Job. Like the XML configuration files in the Java world. It is a kind of DSL, it has it’s own keywords and syntax in order to express some information that will be used , for instance, to configure an underlying framework.

The problem with XML is that it becomes hard to see the overall behavior behind it. It’s not very fluent to understand the purpose of an XML file just by looking at it for the first time. There is too much “noise”. Things that get into the way of the readability. - YAML files are an much more readable alternatives to XML.

The same happens with a standard framework api code. Let’s take for instance a sample API configuration code written in Java to tackle the domain of hotel reservations. A framework like this could have the following implementation:


HotelService hotelService = new HotelService();
PersonService personService = new HotelService();

Hotel hotel = hotelService.findById(1);
Person guest = personService.findById(10) ;

Reservation reservation = new Reservation() ;
reservation.setFrom(”2008-03-10″) ;
reservation.setTo(”2008-03-14″);
reservation.setGuests(new Person[]{guest});

hotelService.book(hotel, reservation);
Of course implementations of this simple example may vary but we can see here some of the readability problems. One approach we could use for that is to develop a Fluent Interface to wrap this API. This was one of the techniques explored during the tutorial and the actual fluent interface could now look somewhat similar with this:


new Hotel(1)
.book()
.forGuests({
person.find(10)
})
.rooms(1)
.from("2008-03-10")
.to("2008-03-10");


Much more readable, huh? One of the main benefits of using DSL’s they highlighted in the tutorial is the simplicity of code you can achieve. You can actually show this code to a business person and he can understand it. This is a kind of internal DSL.

But there is still a bit of noise in this code. The the parenthesis which are not always desirable, and the use of double quotes for dates. But, this is Java code, and Java doesn’t give too much room for you on the DSL subject. Here was when the speakers changed their focus a bit to Ruby. It’s dynamic nature and metaprogramming techniques provides a powerful flexibility that allows for a looser syntax.

So in ruby the previous interface could look like this now:


Hotel.find(1) .book(1.room).forGuests {
Person.find(10)
}.from(march.10.2008).to(march.10.2008)


We got rid of the double quotes and the code looks more fluent, like a normal english sentence. I doubt a business guy woudn’t understand what this code is doing. With this, we can get closer to the business guys, with a common vocabulary, and fill the gap between us.

This is just one of the ways we could have written this code and is not the actual example used in the tutorial. The syntax also really depends on how readable you wanna make your code. I’ll provide those later when they release the digital format of the presentation.

So one of the flows that the development of an internal DSL can get is to build a framework and define the DSL on top of it. But we should also keep in mind that DSL’s shouldn’t be general purpose programming languages. They should be created to tackle a specific kind of domain problem, so we would have a whole system made of small DSL’s.

Another interesting subject that was touched is testing. How do you test DSL’s?
The suggested approach, and that I think is quite reasonable, is to have separate tests for the underlying framework and another to test the DSL and its parser you can assure you have the expected behaviour of both parts.

This is really just a summary of my thoughts and of what happened there. I’m not going into too much details right now but if you found something too abstract - and it is! - feel free to ask details. I’ll be more than happy to help.

This is definetly an interesting subject and now I’ll head to play more with all that.
PS; This is not the whole presentation, just the best of it from my stand point. Other subjects include External DSL’s which can actually involve you coding Lexers, Parsers and Compilers. It’s usually not worth the hassle. And it’s too complicated anyway, that’s why I left it out from this post.

I never paid too much attention on testing database stuff. While working with java, the closest I got to something workable was using the test case abstractions provided by the Spring framework. It ensures that each test method runs in its own transaction that is rolled back after the test’s execution.

Fair enough. I used the setUp() method on my TestCase to configure some records so I could work with them, removing all of them in the tearDown() method. It was quite simple and worked.

But I always felt something strange with this solution. First of all, I had to add another framework just for that. - Actually I was using spring for dependency injection, but if I wasn’t, it wouldn’t be a nice option. And another thing that bothered me, is that you cannot guarantee that your database is in a known state.

After I started to work with Ruby - and Rails - I discovered the testing fixtures. It is a really nice way to set up your testing data without having to worry about your database state. - If you don’t know what I’m talking about, follow the above link first.

Then I received a message from a co-worker saying he was having some trouble in using DBUnit with Hibernate, and asked for some help. I’ve heard of DBUnit before but never tried it myself. It was a very good opportunity to take a better look into it.

The basic idea after all is very similar to that of the Rails Fixtures: You have some sort of external file - XML in this case - where you set up the testing data. So the framework takes care of erasing the database, inserting your test data and returning it to its original state.

So far so good, DBUnit’s default Classes works with JDBC, DataSources and JNDIDatasources, but not with Hibernate. The effort to put them working together is minimal and is documented in their web site.

I decided to share how this can be done with hibernate and in the end, you would have a test case similar to this one:

Read the rest of this entry »

Dependency injection - DI -  is a great thing. Really. The hability to tweak implementations without touching your code is awesome and the DI frameworks, like spring, saves you a lot of coding. No more service locators stuff.

But, and there is always a but, you’re left with a bunch of XML configuration. And I hate it. Not that XML files are bad… the thing is that everything nowadays has its own set of XML configurarion files. And Spring is not different.

Read the rest of this entry »

Isso é um fato. Cada linha de XML que eu escrevo me faz pensar em formas de evita-las. E isso não é simples.

Ultimamente, desde o Java 5, tem se trocado o XML pelas annotations. Tá bom, fica bonitinho né? Até que fica. Em alguns casos, até mais organizado. O Hibernate desde a versão 3 faz uso das annotaions da JPA como alernativa ao seu XML de configuração. E esse sim é um belo caso de sucesso!

São apenas algumas anotações na classe para mapea-la e pronto, adeus xml! Mas como sempre, as anotações já estão sendo exageradas por aí. Basta decidir configurar uns 3 frameworks - e provavelmente dois deles são descenessários no seu projeto - usando anotações e as suas classes ficarão uma zona! E muito mais ilegíveis que um arquivo XML!

As anotações são recursos muito poderosos e devem ser usadas de forma consciente. Use as que realmente valem a pena, como as que vou falar agora, que fazem parte da nova release do Spring framework, a 2.5 RC1. Read the rest of this entry »

Hoje fiz a versão beta da nova prova de arquiteto da Sun e eis algumas impressões:

- É longa e cansativa… fato justificável se levar-mos em consideração o fato de ser uma prova em estado beta. Ela possui mais questões que a versão final. São 153 questões no total, em 4h e 30min. Read the rest of this entry »

Nesse primeiro post vou falar um pouco sobre meu novo trabalho. Na verdade, sobre um problema que encontramos lá.

Dentre diversas coisas que estamos fazendo, como migrações por exemplo, estou ajudando na elaboração da arquitetura que irá abrigar as novas aplicações desenvolvidas na empresa. Read the rest of this entry »