Estimations are part of our everyday life. We estimate how long the bus ride to work will be so that we know what time we should wake up. Drivers estimate how big a spot by the curb is to decide if they can park there or not. Engineers estimate how much time they need to get a building done so that they can charge the clients, pay the builders, and so on.

So, looking at these examples, I’d say that we estimate as a means of predicting something that usually can be measured: time, distance, size, etc, without having to actually measure it. We predict because measuring it may not be worth it, or because if we measure it, once we are done, this knowledge isn’t useful anymore.
With this prediction in hand we are able to make decisions. So I think that we can say that we estimate stuff to plan our actions.

2. Estimating projects

Let’s take the engineer as an example, I am not an engineer, but since my father is a builder, I think I can say some things about it. So the engineer has to estimate a building project, probably the differences between a project and another will eventually boil down to the material, the size, the number of builders that will be working, and a few more variables that are likely to be easily quantified. Once the engineer has all the information he needs, it’s just a matter of calculations. There aren’t many different ways of building a wall or a pillar after all. Of course, it is an estimation, so it may still prove itself invalid, that’s why it’s called estimation and not vision-from-my-crystal-ball.

Now, in software development we also need to estimate how long it will take, how many developers/QAs we will need, and so on, but the tricky thing is: how do we measure software? We don’t have materials, area, size. What units are going to be used as input for our calculations to come up with a reliable estimation?

Well, there aren’t any. Software development, different to classical engineering, isn’t measurable, because it’s an intellectual and creative type of work. Writing software for a bank is not the same thing as writing a mobile phone game. While we work in a development project we learn about the client’s domain, their needs, their specificities. And each client has their own details, even if they belong in the same type of industry. This makes all development projects a learning project. If we are learning something, we don’t really have the knowledge before it is done, so our estimations won’t be very accurate.
Not to mention differences of technology, the knowledge of the team members, how to deal with the client people to gather requirements and approve a completed functionality.
If you ever hear anyone saying that software development is an exact science, tell them: “Lies!”. It’s a lot about learning, finding different solutions for different problems and *a lot* of dealing with people, not so similar to the classical build-my-house project.

3. So what do we do?

Well, that’s a good question, since we can’t really say “we won’t estimate this software project”. We still need to plan it, and as we agreed estimations are needed for planning. So, where I come from we don’t estimate how big a software is, nor how long it’s going to take us to write it. We estimate how complex it seems to be, and the most important thing is: this estimations are relative, not absolute. We split the work into “stories“, an independent and small piece of work and assign “story points” to each story, a completely abstract unit of measurement.

If I tell you that I will need 4 hours to wash your car, this is an absolute estimation, since 4 hours is a fixed amount of something that we all know how to measure and have a common understanding of (hours). Now if we agree that a given piece of functionality for your software is 2 story points, it’s relative because it means that it is twice as complex as it is to write another piece of functionality that is 1 story point. But a “story point’ doesn’t really mean anything.

It’s true that there is a statistical co-relation between story points and time, as we can see on the chart below, but this co-relation of how much time in average a story point is worth varies quite a lot depending on the team, the project, the domain, technology and so on. The relativity between the points is still valid though.

How story points relate with one another when converting them to time units. Taken from Story Points explained.

4. Estimating software

So now that we can measure the effort to write software using its complexity in story points, we can start estimating our work. As we already agreed, development is a lot  about learning, so we can infer that the more we work on a project, with the same team and environment, the more accurate our estimations will be, since we will know more about such project’s details. That’s why we ideally avoid estimating a whole project at once in the beginning, it’s better to estimate it in parts. For instance, estimating a bucket of stories for each planned release or each planned iteration.

After a few iterations we can get a grasp of an average number of story points that team can complete in a given amount of time. It’s important noticing that any change in any of these variables: team, project and environment may and will affect this co-relation. Once we have this average number we can start predicting how much time it will take us to complete a big set of stories.

Now, that sounds very good in theory, but in real life we usually need to tell our clients an estimation before we actually start working, depending on the contract and the relationship with the client, so… what do we do? This has got to be the one billion dollars question of software development lately. And the more I talk to people about it, the more it seems like there’s no satisfying answer.

5. Contracts

When the client is known and there is already a strong relationship between the parts it is easier to get a flexible contract, usually in a time-and-materials fashion, allowing us to adapt the complexity x time co-relation as the project advances and negotiate deadlines x scope x team variables to get whatever the client needs the most as soon as we can deliver. This really requires mutual trust and collaboration, which agile is all about. But the world is not 100% agile, as humans are not 100% trustworthy, so from what I have experienced these contracts are not the most common out there, specially when we are trying to get a new client to partner up with.

On the other side of the rope lies the least flexible type of contracts: fixed-price and scope contracts. The client tells you: here’s what I need, you tell them: I need X months to get that done, and it will cost you Y money units. Needless to say there’s a big risk involved in this type of contract. If the estimation is too low either you may need to work over-hours to get the work done, or the deadline won’t be met. In the worst cases, both may happen. If the estimation is too high, the client may prefer a cheaper potential partner and leave you. In the case they accept your terms, there will probably be a big waste of money from the client’s part, and time from both your sides (see the Parkinson’s Law). Not to mention requirement changes that, regardless of what the clients say, will come up during the development.

Most of the other types of contracts I have seen lie in between these two types or are a mix of them. Some examples I have seen are offering a couple of iterations to develop a prototype for the potential client, for free. After this prototype is ready, if the client likes what they see, the team will have a much better knowledge to work on more reliable estimations for a fixed-price contract. Another option could be a contract with a fixed deadline but variable scope, where the team compromises to deliver at least X story points. Or fixed scope but variable deadline, depending on what’s more important for that client.

6. Managing estimations

That said, I have had many discussions with colleagues about how to manage existing estimations, mostly in regards of whether we should re-estimate stories or not.
This may become a rather hot debate, but my opinion is that: we should try to avoid re-estimating stories, unless we’re really far off.
I really like Mike Cohn’s take on the subject, I don’t think I can explain it as well as him, so just take a look at it!
The basic idea is that we have knowledge-before-the-fact and knowledge-after-the-fact, and we shouldn’t mix them on our backlog, since we will need a normalized set of data to plan our future work on.

The problem arises when we use estimations not only for planning, but also to charge the clients due to the contract type. In this case re-estimating stories or not may not be an option. If the estimations are not tied with the project costs, informing the client that a given story will take longer than planned may suffice, in this case, since the development is in progress, a timed-estimation may even be accurate enough and more useful.

7. Conclusion

In my opinion, software estimation techniques are quite fair nowadays, the problem is not how we estimate software, it’s how we charge our clients.
Estimations are called estimations for a reason, they are not supposed to be the truth written in stone, and contracts based on that are quite risky.
I have the impression that once we all build a common understanding that software development is not as a classical engineering type of project many things will become simpler, and we will stop feeling that we are working in the software-estimation industry instead of in the software-development one (at least I feel like that at times).
The engineering part of our work is done by the compilers and interpreters, not by the developers.

myApp.buttonBinder = {
  bind: function(button) {
    if (myApp.shouldChangeButtonAction()) {
      button.unbind("click").click(function() {
        button.closest("form").submit();
      });
    }
  }
}

So we wanted to test this using Jasmine.
Our main goal was to test that when the button was clicked the form that contains it was being submitted.
It would be cool if we could use Jasmine’s spies:

describe("myApp.buttonBinder", function() {
  it("should bind form submit to button", function() {
    var form = $("<form/>");
    var button = $("<input/>");
    form.append(button);
    spyOn(form, 'submit');

    myApp.buttonBinder.bind(button);
    button.click();

    expect(form.submit).toHaveBeenCalled();
  });
});

But unfortunately this does not work. I didn’t look too much into it, but I suspect it is due to the fact that when the actual code runs, the jQuery ‘closest’ selector creates a new form object that represents the same DOM element. But as it is a different object the spy can’t recognize that the function submit has been called.
One idea is to instead add a listener to the form’s submit event and check if this listener has been called:

describe("myApp.buttonBinder", function() {
  it("should bind form submit to button", function() {
    var form = $("<form/>");
    var button = $("<input/>");
    form.append(button);
    var formHasBeenSubmitted = false;
    form.submit(function() {
      formHasBeenSubmitted = true;
    });

    myApp.buttonBinder.bind(button);
    button.click();

    expect(formHasBeenSubmitted).toBeTruthy();
  });
});

And voilá! This works!
But it looks terrible, doesn’t it?
Good thing Jasmine lets us extend itself, so we can create a new spy function and a new custom matchers:

// SpecHelper.js
var jasmineExtensions = {
  jQuerySpies: {},
  spyOnEvent: function(element, eventName) {
    var control = {
      triggered: false
    };
    element.bind(eventName, function() {
      control.triggered = true;
    });
    jasmineExtensions.jQuerySpies[element[eventName]] = control;
  };
};

var spyOnEvent = jasmineExtensions.spyOnEvent;

beforeEach(function() {
  this.addMatchers({
    toHaveBeenTriggered: function() {
      var control = jasmineExtensions.jQuerySpies[this.actual];
      return control.triggered;
    }
  });
});

And now our test looks like this:

describe("myApp.buttonBinder", function() {
  it("should bind form submit to button", function() {
    var form = $("<form/>");
    var button = $("<input/>");
    form.append(button);
    spyOnEvent(form, 'submit');

    myApp.buttonBinder.bind(button);
    button.click();

    expect(form.submit).toHaveBeenTriggered();
  });
});

Much better \o/

If you work with development of some sort, big chances are you work with web development.
If you work with web development, regardless of the technology stack – be it Java, .NET, Ruby, Python, Perl or Brainfuck – your application runs on a browser, and all browsers run JavaScript, so you can’t escape from it. *

That said, once you have learned JavaScript, you will find out that programming in JavaScript is actually fun!
I have gone through this myself as I have seen colleagues going through this too.
Not only you will find out it is fun, you will see how JavaScript is a powerful language that has lots of good things that you will start to wish other languages also had.

Most important of all: your JavaScript code will start to look good.
And once all developers in your team have learned that learning JavaScript is not only important, but necessary, your project’s JavaScript codebase will stop looking horrendous as it does nowadays. It will look good, modularized and testable. And you won’t ever again go “Oh crap, I have to touch JavaScript in this story…”.

Wait, did I say testable? Yes, I did! You can actually TDD your JavaScript code as well as you can TDD your <favorite language> code.
For that I recommend Jasmine, have been using it in our project, love it.
You can even combine Jasmine with Rhino or WebDriver and add your JavaScript tests to your Continuous Integration pipeline. (Your project has a CI server, right?!)

And you know what? Learning JavaScript is EASY!
I believe most developers familiar with any OO language wouldn’t need more than a couple of days to start writing more than decent JavaScript code.
There’s plenty of good websites and books out there for you to learn it, so go on and have fun!

* Ok, actually, you can escape from writing JavaScript.
You could go with GWT for instance. And I remember there were other frameworks that let you develop the whole fancy UI on Java on the server side, sending only few instructions to the client – I can’t recall any names right now.
The thing is: is it worth it?
I worked with GWT for a considerable time in 2009 and, now that I have had more JavaScript experience, I definitely wouldn’t go back to GWT. It just seems like a lot more work to do, not to mention the messy HTML and CSSs it generates.
If you’d like to have your JavaScript compiled from something else, take a look at CoffeeScript

Not long ago I wrote about functional tests and the page objects pattern in Aqris’ blog. Back then we at Aqris got all very excited about page objects as they were the solution we were looking for to solve our problems on maintaining our functional test code base, which by that time was based on a set of messy helpers that nobody really understood completely.

Before page objects, whenever a developer in our team had to write a test that had to perform an action no other test already performed, he or she would go through that bunch of helpers trying to figure out which one was the helper that should perform such an action. The result of this approach was that the team couldn’t get to a full agreement on what was each helper’s responsibilities. Everybody agreed that the code was not good, but each person had their point of view on why.

We first learned about the pattern here, when reading about WebDriver (now Selenium 2). Page objects came as the solution to separate the different actions our helpers contained in an extremely simple and even obvious way that nobody in our team had previously thought: simply creating a specialized helper for each page of the application.

It is in fact so simple that I still wonder how come we didn’t think of that before… I think that we were too busy trying to figure out how to deal with the helpers we had, and we were too used to have them that way. I guess that’s because the previous project we had worked on (and the first one we had a strong movement towards automated tests with Selenium) was a web app based on only one single page with lots of GWT-based ajax.

Anyway, excuses aside, we started using page objects and it was great! But then other doubts started to come up: how to deal with parts of a page that are common to many pages – for instance a side navigation bar? How to make our tests more readable? Should our page objects use selenium directly? If yes, how to resolve the selenium dependency? Can the page objects just encapsulate the locators for the html elements instead? Should page objects be responsible for the tests assertions too, depending on xUnit’s API, or should they just provide verification methods that would be used by our tests’ code itself?

I think that these are questions that may or may not have a straight correct answer, but here I will write a bit of what worked well for us or for me later on when dealing with that.
To do that I think we can write a test for an imagined scenario.
Let’s try that!

The problem

Let’s say that we have a test case to test the following hypothetical scenario:

We have a hypothetical book store application.
Every page in the application has a navigation bar on the side.
An user goes to our application home page and, by clicking on a link on the navigation bar, she goes to a page to search for books.
On the search books page she fills in a search form, entering “Tolkien” in the author field and “Rings” in the title field, and submits the form.
She is then redirected to a search result page that contains a list of books along with the same search form already filled in with the same search data she had entered – in this case, “Tolkien” in the author field and “Rings” in the title field.

We want to assure that, given our test data, the search result contains the book ‘The Return Of The King’.
We also want to assure that the search form in the result page still has the data she had previously entered.

The code solution after the jump

The code

(I will write the code in Groovy here, because it is similar to Java, which is a widely known language, and because with Groovy we can do some nice things to make the code more readable. But you can use whichever language you prefer.)

Usually we create a Page class which all other page objects classes inherit from.
It keeps a reference to our selenium instance, so that all our pages know how to manipulate their elements and do all the dirty job for us, exposing higher-level actions to our tests. Plus, if the HTML elements on our page changes, we know exactly what part of our test code base has to be updated.

So our Page class may look like this:

class Page {
  Selenium selenium   
  Page(Selenium selenium, String title) {
    this.selenium = selenium

    /*
     * In Groovy, selenium.title is the same as selenium.getTitle()
     */
    if (title != selenium.title) {
      throw new IllegalStateException("Should be on page ${title} but I am actually on page ${selenium.title}")
    }
  }
}

The Page constructor receives the expected page title, which is passed by the subclasses that will inherit from it.
Then we check if the title of the page in which selenium currently is corresponds to the title of the page our test should be. This is a nice way to ensure the test is navigating through the pages following the flow we expect it to.
It is a bit annoying to pass the selenium reference to every page we create, but I think that it is worth it anyway.

I also like to create Button, Link and Form classes, as usually we have to deal with all of them and specially because from the interactions with these elements our test navigates among the pages, so they can create new page objects for us too.

They may look something like this:

class Button {
  Selenium selenium
  String locator

  Button(Selenium selenium, String locator) {
    this.selenium = selenium
    this.locator = locator
  }

  void click() {
    // sometimes Groovy allows us to omit the parenthesis!
    selenium.click locator
  }
}

The locator attribute is used by selenium to find the button in the page’s HTML structure. It might be an ID, an xpath expression, etc.
I made Link an abstract class because each link will bring a different page to the user:

abstract class Link {
  Selenium selenium
  String locator
  
  Link(Selenium selenium, String locator) {
    this.selenium = selenium
    this.locator = locator
  }

  Page click() {
    selenium.click(locator)
    return linkedPage // the same as 'return getLinkedPage()'
  }

  abstract Page getLinkedPage()
}

Similarly, forms are also represented by abstract classes. They know how to fill themselves with data using selenium, and which page to show after they are submitted:

abstract class Form {
  Selenium selenium

  Form(Selenium selenium) {
    this.selenium = selenium
  }

  Page submit() {
    submitButton.click()
    return pageAfterSubmit
  }
  
  abstract void fill()

  abstract Button getSubmitButton()

  abstract Page getPageAfterSubmit()
}

With this we can start to write the classes specific to our scenario.

As all pages in our application contain the navigation menu, we can modify the Page class so that it contains an instance to a NavigationMenu object, which will keep the details of the actions related to the menu:

class Page {
  Selenium selenium
  NavigationMenu navMenu
  
  Page(Selenium selenium, String title) {
    this.selenium = selenium
    if (title != selenium.title) {
      throw new IllegalStateException("Should be on page $title but I am actually on page $selenium.title")
    }
    navMenu = new NavigationMenu(selenium)
  }
}

class NavigationMenu {
  Selenium selenium

  NavigationMenu(Selenium selenium) {
    this.selenium = selenium
  }

  Link getSearchBooksLink() {
    return new Link(selenium, "link=Seach Books") {
      Page getLinkedPage() {
        return new SearchBooksPage(selenium)
      }
    }
  }
}

Notice that the navigation menu has a searchBooksLink, which when clicked returns an object for the search page.
The HomePage class that represents our application’s first page is as simple as it gets:

class HomePage extends Page {

  static final String URL = "http://localhost:8080/my_book_store"

  HomePage(Selenium selenium) {
    super(selenium, "My Book Store")
  }
}

So we can start to write our test code:

def testShouldFindTolkienBooks() {
  selenium.open HomePage.URL
  def homePage = new HomePage(selenium)
  def searchPage = page.navMenu.searchBooksLink.click()
}

The SearchBooksPage class contains our SearchBooksForm which inherits from Form:

class SearchBooksPage extends Page {
  Form searchForm
  SearchBooksPage(Selenium selenium) {
    super(selenium, "My Book Store - Search Books")
    searchForm = new SearchBooksForm(selenium)
  }
}

All fields from our form become properties in our form class, in this case, author and title.
We will use these properties to fill in the form.

class SearchBooksForm extends Form {

  private static final String AUTHOR_LOCATOR = "//form[@name='search_books']/input[@name='author']"
  private static final String TITLE_LOCATOR = "//form[@name='search_books']/input[@name='title']"

  String title
  String author

  SearchBooksForm(Selenium selenium) {
    super(selenium)
  }

  void fill() {
    selenium.typeKeys(AUTHOR_LOCATOR, author)
    selenium.typeKeys(TITLE_LOCATOR, title)
  }

  Button getSubmitButton() {
    return new Button(selenium, "//form[@name='search_books']/input[@type='submit']")
  }

  Page getPageAfterSubmit() {
    return new SearchResultPage(selenium)
  }

  String getAuthorFieldValue() {
    return selenium.getValue(AUTHOR_LOCATOR)
  }

  String getTitleFieldValue() {
    return selenium.getValue(TITLE_LOCATOR)
  }
}

Here is the SearchResultPage class:

class SearchResultPage extends Page {

  Form searchForm
  
  SearchResultPage(Selenium selenium) {
    super(selenium, "My Book Store - Search Result")
    this.searchForm = new SearchBooksForm(selenium)
  }
  
  def getResult() {
    def books = []
    def i = 1
    while (selenium.isElementPresent("//div[@id='books']/div[@class='book'][${i}]/span[@class='title']/text()")) {
      books << selenium.getText("//div[@id='books']/div[@class='book'][${i}]/span[@class='title']/text()")
      i++
    }
    return books
  }
}

so now we can finish our test code:

class MyBookStoreTests extends SeleneseTestCase {
  def testShouldFindTolkienBooks() {
    selenium.open HomePage.URL
    def homePage = new HomePage(selenium)
    def searchPage = page.navMenu.searchBooksLink.click()
    searchPage.searchForm.author = "Tolkien"
    searchPage.searchForm.title = "Rings"
    searchPage.searchForm.fill()
    def resultPage = searchPage.searchForm.submit()
  
    assertTrue resultPage.result.contains("The Lord Of The Rings: The Return Of The King")
    assertEquals "Tolkien" resultPage.searchForm.authorFieldValue
    assertEquals "Rings" resultPage.searchForm.titleFieldValue
  }
}

But this test code is still not very good.. it could be more readable and all these accesses like a.b.c.d() bum me out.
So let’s improve it a bit.

Improvements

First of all, let’s try to get rid of that selenium reference there inside of our test code.
To do that we can create our own extension of SeleneseTestCase with some utility methods and then make our test cases extend from it instead.

As we are using Groovy, we can create a method that creates the first page object our test needs for us, it can do it based on its class name and set its selenium dependency too. Let’s call this method visit, this way we can write on our test visit(HomePage).

class MyBookStoreSeleneseTestCase extends SeleneseTestCase {
  Page visit(Class clazz) {
    assert Page.isAssignableFrom(clazz)
    assert Page.URL
    selenium.open clazz.URL
    return clazz.newInstance(selenium)
  }
}

And our test becomes:

class MyBookStoreTests extends MyBookStoreSeleneseTestCase {
  def testShouldFindTolkienBooks() {
    def homePage = visit(HomePage)
    def searchPage = page.navMenu.searchBooksLink.click()
    searchPage.searchForm.author = "Tolkien"
    searchPage.searchForm.title = "Rings"
    searchPage.searchForm.fill()
    def resutPage = searchPage.searchForm.submit()
  
    assertTrue resultPage.result.contains("The Lord Of The Rings: The Return Of The King")
    assertEquals "Tolkien" resultPage.searchForm.authorFieldValue
    assertEquals "Rings" resultPage.searchForm.titleFieldValue
  }
}

Usually in spoken language the verbs come first, so we can improve our custom SeleneseTestCase class by adding some dummy methods just to make our test more readable, delegating the actions to our objects:

class MyBookStoreSeleneseTestCase extends SeleneseTestCase {
  Page visit(Class clazz) {
    assert Page.isAssignableFrom(clazz)
    assert Page.URL
    selenium.open "http://localhost:8080/my_book_store"
    return clazz.newInstance(selenium)
  }
  Page clickOn(Link link) {
    return link.click()
  }
  Page fillAndSubmit(Form form) {
    form.fill()
    return form.submit()
  }
}

class MyBookStoreTests extends MyBookStoreSeleneseTestCase {
  def testShouldFindTolkienBooks() {
    def homePage = visit(HomePage)
    def searchPage = clickOn(page.navMenu.searchBooksLink)
    searchPage.searchForm.author = "Tolkien"
    searchPage.searchForm.title = "Rings"
    def resutPage = fillAndSubmit(searchPage.searchForm)
  
    assertTrue resultPage.result.contains("The Lord Of The Rings: The Return Of The King")
    assertEquals "Tolkien" resultPage.searchForm.authorFieldValue
    assertEquals "Rings" resultPage.searchForm.titleFieldValue
  }
}

This test, as all other Selenium tests I have seen so far, only interacts with one page at a time. So we don’t need to have different variables for each page. We can have a single ‘page‘ variable and use it everywhere, something like this:

    ...
    def page = visit(HomePage)
    page = clickOn(page.navMenu.searchBookLink)
    ...

Then we can move the page variable to an attribute of MyBookStoreSeleneseTestCase and avoid having all those assignments:

class MyBookStoreSeleneseTestCase extends SeleneseTestCase {
  Page page
  Page visit(Class clazz) {
    assert Page.isAssignableFrom(clazz)
    assert Page.URL
    selenium.open clazz.URL
    page = clazz.newInstance(selenium)
    return page
  }
  Page clickOn(Link link) {
    page = link.click()
    return page
  }
  Page fillAndSubmit(Form form) {
    form.fill()
    page = form.submit()
    return page
  }
}

class MyBookStoreTests extends MyBookStoreSeleneseTestCase {
  def testShouldFindTolkienBooks() {
    visit HomePage
    clickOn page.navMenu.searchBooksLink
    page.searchForm.author = "Tolkien"
    page.searchForm.title = "Rings"
    fillAndSubmit page.searchForm
  
    assertTrue page.result.contains("The Lord Of The Rings: The Return Of The King")
    assertEquals "Tolkien" page.searchForm.authorFieldValue
    assertEquals "Rings" page.searchForm.titleFieldValue
  }
}

Then we can actually get rid of the references to ‘page‘ altogether from our test code. To do it we implement property and method missing in our MyBookStoreSeleneseTestCase, in a way that if we try to access a method or property that it doesn’t have, it looks for them in the page object:

class MyBookStoreSeleneseTestCase extends SeleneseTestCase {
  // all that we already had plus:
  def methodMissing(String method, args) {
    page.invokeMethod method, args
  }
  def propertyMissing(String name) {
    page[name]
  }
}

class MyBookStoreTests extends MyBookStoreSeleneseTestCase {
  def testShouldFindTolkienBooks() {
    visit HomePage
    clickOn navMenu.searchBooksLink
    searchForm.author = "Tolkien"
    searchForm.title = "Rings"
    fillAndSubmit searchForm
  
    assertTrue result.contains("The Lord Of The Rings: The Return Of The King")
    assertEquals "Tolkien" searchForm.authorFieldValue
    assertEquals "Rings" searchForm.titleFieldValue
  }
}

To finish, we can improve the filling out of the form using Groovy’s with method and use Hamcrest to write our assertions.

First we have to overwrite the method with in our Form class.
Groovy’s ‘with‘ method is very handy but it doesn’t return the own object. More about it here.
So we just add the following code to our Form class:

class Form {
  // ....
  def with(Closure c) {
    super.with(c)
    return this
  }
}

And then our test code can be written as:

class MyBookStoreTests extends MyBookStoreSeleneseTestCase {
  def testShouldFindTolkienBooks() {
    visit HomePage
    clickOn navMenu.searchBooksLink
    fillAndSubmit searchForm.with {
      author = "Tolkien"
      title = "Rings"
    }
  
    assertThat result, hasItem("The Lord Of The Rings: The Return Of The King")
    assertThat searchForm.authorFieldValue, is(equalTo("Tolkien"))
    assertThat searchForm.titleFieldValue, is(equalTo("Rings"))
  }
}

Much better uh?!

You can get the full code (with some workarounds to get it working without a real application) here.

The story…

This laptop comes with two video cards and what nvidia calls Hybrid SLI.
The idea is very nice : one video card is integrated to the motherboard and is always switched on.
The other one is a discrete card and is manually switched on by the user when he/she wants more graphical processing power, consuming more power. This sounds interesting for laptop owners, who may want to save the battery as much as possible.
When the discrete card is on, both cards work together combined to provide a more powerful graphical processing device.
Even tough the idea is nice, the implementation is not, and nvidia even gave up moving on with the technology. If I am not mistaken, I read somewhere that they claim the driver implementation to control the devices together is very complicated.
The drivers for Windows Vista and Windows 7 work quite well, and is maintained by the laptop vendors, in this case, Dell.

Now if you use Linux…:
nvidia provides their proprietary driver for Linux, which is very nice, but allows us to use only the integrated card.
At first it was ok for me, as I didn’t have the need to use the power of both cards together on Linux anyway. The problem is: the Linux driver does not switch the discrete card off. Yeap, that’s right, you can’t use the discrete card, but it is always on consuming power. Ironic, uh?! The result is: on Linux my laptop always runs hotter and the battery lasts shorter than on Windows.

I researched for a long time when I bought the laptop, but I couldn’t find a way to get the discrete card off.
One good piece of news is that the project nouveau, an open source driver for nvidia cards, plans to add full support to switching these cards on/off at will. The driver is still under heavy development though… and many features are not yet implemented.

So just a few days I received an update from the sites I have been following related to the subject.
avilella has been running a great blog about switchable graphics on Linux, and quickly updating it on every new details that comes up. The address to his blog is: http://linux-hybrid-graphics.blogspot.com/

There is also a bug report on Launchpad regarding the same problem: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/312756
On this bug report page they are collecting information about all different laptops with switchable cards, so that they can work on a solution for everyone.
But just yesterday a member from Launchpad named drphd found an ACPI method that can be called on the Dell XPS 1340 to disable the graphic card.

I just made a small modification on the module that avilella posted here, making it specific for the Dell XPS 1340, by using the method indicated by drphd. And, thanks to these guys, we can now switch the discrete card off.

The solution

So, to use it, just download these two files:

Makefile
xps_nv.c

Before compiling the module, run: lspci -v
You should see the information for both cards, including the IRQ and the kernel modules related to them.
Now place those two files inside the same folder, cd to this folder and run:

make
sudo cp xps_nv.ko /lib/modules/`uname -r`/kernel/
sudo depmod
sudo modprobe xps_nv

If you run lspci -v again, you should see the detailed information only for the integrated card. On my machine the output after the module is loaded is:

02:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 9200M GS] (rev ff) (prog-if ff)
	!!! Unknown header type 7f

03:00.0 VGA compatible controller: nVidia Corporation C79 [GeForce 9400M G] (rev b1)
	Subsystem: Dell Device 0271
	Flags: bus master, fast devsel, latency 0, IRQ 23
	Memory at aa000000 (32-bit, non-prefetchable) [size=16M]
	Memory at b0000000 (64-bit, prefetchable) [size=256M]
	Memory at cc000000 (64-bit, prefetchable) [size=32M]
	I/O ports at 5000 [size=128]
	[virtual] Expansion ROM at c0000000 [disabled] [size=128K]
	Capabilities:
	Kernel driver in use: nvidia
	Kernel modules: nvidia-current, nvidiafb, nouveau

To make sure that the module is loaded every time you boot your laptop, edit the file /etc/modules and add, in the end, a new line with the text:

xps_nv

As you see, I have the Dell XPS 1340 with a GeForce 9400M G and a GeForce 9200M GS.
But I think that the same solution should also work for people who have the combination GeForce 9400M G + GeForce 210M.

After the module is loaded the laptop runs a bit cooler, it uses around 4W less power and the battery is estimated to last around 30-50 minutes longer.

Remember that every time you install a new kernel you will have to re-compile and re-install the module.

Cheers!

So, my ~/.vimirc looks like this:

set tabstop=2 expandtab autoindent smartindent shiftwidth=2 number

 
Here’s what each of them does

And here are some of the commands I use more often:

Also remember that many of these commands may be used with a different number of lines.
For instance, pressing 1, 0, d, d will delete he next 10 lines.

Any other cool commands for Vim? Let me know on the comments!

One of the things that I like is how using Groovy’s dynamic features the framework injects database access technicalities into our domain classes.
The domain is therefore smart enough to retrieve/update its relationships and even to find/update itself, all without the need to pass around repositories dependencies whatsoever, or to force the domain classes to extend any other classes.

But sometimes we need to write HQL (or criterias) ourselves, and then in our first project we ended up having some domain classes quite bloated with custom queries and a lot of other database related operations mixed with pure domain-specific logic operations.

Something like this:

  class Book {
    // properties, mappings, constraints
    // domain methods

    def findAllBooksFromTheSameAuthor() {
      return findAll("some HQL")
    }

    def findSimilarPurchasedBooks() {
      return findAll("some HQL")
    }
  }

This code is just a silly example to illustrate the problem.
Of course we could have used Grails’ dynamic finders for those queries too, but we would be externalizing the internals of our domain class so we like this approach of adding custom query methods better.
One thing we didn’t like though, is that we had many methods like the ones above, mixed with the domain logic and properties.
So we decided to move these methods somewhere else and inject them into our domain classes, like Grails does with its dynamic generic finders.

A very nice way to do it seemed to be using Groovy’s Delegate annotation, having something similar to:

  class Book {
    @Delegate BookQueries bookQueries = new BookQueries(this)

    // properties
    // mappings, constraints, domain methods
  }

  class BookQueries {
    Book book

    BookQueries(Book book) {
      this.book = book
    }

    def findAllBooksFromTheSameAuthor() {
      return Book.findAll("some HQL")
    }

    def findSimilarPurchasedBooks() {
      return Book.findAll("some HQL")
    }
  }

We have to pass the book object to BookQueries because we are gonna need its properties to build our queries.
For instance, we need its author to find all books from the same author.
And using the delegate we can call methods from BookQueries with a Book object:

  book.findSimilarPurchasedBooks()

The only problem with this is that we also had some static methods to first retrieve our objects.
These are queries that are not related to any relationship or similarities between objects, so they are static methods in the Book class:

  static def findBestSellersInMonth() {
    findAll("some HQL")
  }

The problem is that static methods are not delegated.

In our project we decided to scrap the @Delegate for good, move all custom query methods to BookQueries, including the static ones, transform them into closures and inject them manually, one by one, into the Book class during the application BootStrap, using Groovy’s Expando metaclass.

But I didn’t really like this approach.
I think I’d rather keep the @Delegate, and then move the static methods to a BookRepository class:

  class BookRepository {
    def findBestSellersInMonth() {
      return Book.findAll("some HQL")
    }
  }

It might seem as a step backwards.. “why do you need repositories if you have your rich domain that can retrieve itself?”
But the static modifier already tells that these methods don’t belong to our domain *objects*.
They are there to initialize the objects, retrieve them from somewhere (the database).
And, well, isn’t this part of the definition of repositories? =P

Update — May 10th ———————————

Peter Ledbrook suggested using Grails’ named queries (see comments). It looks indeed very nice, but we really wanted to move our queries out of our domain class, to make it more readable and, well, prettier

With the named queries we could move a static block containing the static queries to the BooksQueries class and assign this static block to a static nameQueries block in the Book class, and this would import the static queries.

Today I was messing with this a bit more and I realized that I could just inject the static methods into my domain class from inside my delegate itself.
It’s so simple I don’t understand how come I didn’t think about that before
So, if you don’t like the repository approach, you can always have something like:

  class Book {
    @Delegate BookQueries bookQueries = new BookQueries(this)
    // all Book properties, constraints, domain methods, etc
  }

  class BookQueries {

    static {
      BookQueries.metaClass.methods.each {
        if (it.static) {
          Book.metaClass.static."$it.name" = owner.&"$it.name"
        }
      }
    }

    Book book

    BookQueries(Book book) {
      this.book = book
    }

    def findAllBooksFromTheSameAuthor() {
      return Book.findAll("some HQL")
    }

    static def findBestSellersInMonth() {
      return Book.findAll("some HQL")
    }
  }

CSS Tab Menu

And it is quite simple.
All that is needed is an image with the looks of the tabs, when unselected and when selected/hovered.
I used this:

tabs background image

You can edit the image to get whatever looks you want.
So, now we only need our html and css:

* Please notice that I used a ‘header’ container for the menu and I set some style attributes for position/etc, but you would probably change it to whatever your container needs.

HTML fragment:

<div class="header">
  <ul class="menu">
   <li>
     <a href=""><span>Option 1</span></a>
   </li>
   <li class="selected">
     <a href=""><span>Option 2</span></a>
   </li>
   <li>
     <a href=""><span>Option 3</span></a>
   </li>
   <li>
     <a href=""><span>Option 4</span></a>
   </li>
 </ul>
</div>

CSS:

.header {
  width: 100%;
  height: 80px;
  background: #003366;
  position: relative;
}

.menu {
  margin: 0px;
  list-style: none;
  position: absolute;
  bottom: 0px;
  right: 20px;
}

.menu li {
  float: left;
  margin-left: -12px;
}

.menu li a {
  float: left;
  height: 24px;
  background: url('img/menu.png') no-repeat;
  position: relative;
  text-decoration: none;
  color: #003366;
  cursor: pointer;
}

.menu li a span {
  float: left;
  padding: 6px 31px 0 35px;
}

.selected a,
.menu li a:hover {
  background: url('img/menu.png') 0px -25px no-repeat !important;
  z-index: 10;
}

.menu li a:hover {
  z-index: 11;
  color: #99cc00;
}

Notice that the image has to be placed in a folder called img with the name menu.png.

And that’s it!

So, today I will write down how to center a floating div with variable width…. A what? Portuguese English please!

Nowadays it is very common to see on websites a small notification on the top of the screen, like those:

Notification

I first saw these things on Google applications like GMail, but they are very nice anyways, because they avoid the use of (grr!) pop-ups (grr!) when there’s the need to notify the user about something. That’s probably why they are becoming each time more popular.

Anyway, this is basically a div or a span, centered on the screen or whatever other container contains it.
Usually to center something it is enough to use

margin: 0 auto;

But in this case we don’t know how wide the div should be, as it depends on the text it will show, which is dynamically provided by some programming language.
So my notification div class does not have a ‘width’ attribute and is displayed as an inline element:

.notification {
  display: inline;
}

In this case setting the margin to auto won’t work, so what to do?
I wanted to center my notification div in relation to the screen, so I created two divs:

<div class="container">
  <div class="notification">
   Here goes my notification message
  </div>
</div>

And my CSS:

.container {
  position: absolute;
  top: 0px;
  width: 100%;
  text-align: center;
}

.notification {
  display: inline;
}

Basically we insert the notification div inside a container that occupies the whole area in which the div is to be centered, and set text-align: center.

I know it is very simple but it is not always obvious

Cowboy Bebop

Pra quem não sabe, Bebop é uma subdivisão do Jazz, e essa é só a primeira das referências musicais presente no anime.

Misturando batalhas espaciais com artes marciais e faroeste, o desenho trás uma trilha sonora de dar inveja a qualquer trilogia famosa de Hollywood, com forte influência de blues, jazz e rock’n roll.

A composicão da trilha sonora foi liderada por Yoko Kanno, uma japonesinha batuta conhecida por suas criacões musicais para games, animes e filmes. Ela reuniu alguns músicos e formaram uma banda para a criação da trilha-sonora. Batizaram a banda de The Seatbelt (Os cintos-de-segurança), pois brincavam que deveriam usar cintos-de-segurança para permanecerem seguros durante as sessões de jam.

A banda não tinha um cantor principal, mas contaram com a participação de vocalistas como Steve Conte, Mai Yamane, Gabriela Robin (há rumores de que esta seja na verdade um pseudônimo da próprio Yoko Kanno) e outros para as músicas não-instrumentais.

A banda se reuniu mais uma vez em 2004 para criar a trilha-sonora do segundo game baseado em Cowboy Bebop.

Clique em ‘Leia o resto deste post’ para poder ouvir algumas músicas da trilha.

Chega de conversa e vamos ao que interessa:

Don’t Bother None, por The Seatbelts e Mai Yamane:

Digging My Potato:

Doggy Dogs III:

Call Me, Call Me, por The Seatbelts e Steve Conte:

The Real Folk Blues, por The Seatbelts e Mai Yamane:

See you in space, Cowboys!