Evaluating code dynamically in Groovy (differences with Ruby)

2009-10-10

This week I found out that there are important differences between Ruby and Groovy when it comes to evaluate code dynamically. In order to write the testing infrastructure of a DSL we were developing, we wanted to invoke the code contained in isolated files in the context of the caller code. We were using Groovy, and I wrongly assumed that it would be as easy as with Ruby.

Imagine you have a file named say.script with the next contents:

say "Hello"

In this DSL, you can say things that are visualized in the STDOUT. Executing this script with Ruby is very simple: just invoke eval() with the code to evaluate it in a context where the say() method exists.

def say(message)
  puts message
end

eval File.read('say.script')

If you want to evaluate the code in the context of some object (for example, an expression builder), you can write something like:

class Context
  def say(message)
    puts message
  end
end

context = Context.new
code = File.read('say.script')
context.instance_eval code

However, in Groovy, the GroovyShell.evaluate() method is not equivalent to Ruby’s eval() method. While both mechanisms can share state between the caller and the invoked code through the concept of bindings, in Groovy the evaluate() method is always resolved in the context of a Script object. This means that the implicit invocation context is not shared. If you try to execute this code:

def say(message){
  println message
}

def shell = new GroovyShell()
def code = new File("say.script").text

shell.evaluate(code) //WRONG: in the script object the say() method is not defined

You will obtain something like:

Exception in thread "main" groovy.lang.MissingMethodException: No signature of method: Script1.say() is applicable for argument types: (java.lang.String) values: {"Hello"}

A workaround for this situation is to convert the script code into a closure. This way, the DSL code is evaluated but not executed. With the closure object you can make the invocation in the context you prefer. In the last example, code bellow will make it:

def say(message){
  println message
}

def shell = new GroovyShell()
def code = new File("say.script").text

code = "{->${code}}"
def closure = shell.evaluate(code)
closure.delegate=this
closure()

In the example, we wrap the code to execute with a closure syntax. In this way, when we call evaluate we obtain a closure object. With this closure object we can modify its delegate (invocation context) and then call it.

Finally, if we wanted to execute the code using a specific invocation context (something like Ruby’s instance_eval), we just have to modify the delegate object:

class Context{
  def say(message){
    println message
  }
}

def shell = new GroovyShell()
def code = new File("say.script").text
code = "{->${code}}"

def context = new Context()

def closure = shell.evaluate(code)
closure.delegate = context
closure()

I don’t know of a better approach for solving this problem with Groovy. Initially I thought there will be a direct way, like in Ruby. But after hours of searching for it we didn’t find anything (which doesn’t mean it doesn’t exist, of course).

5 Comments

About agile estimating in hours

2009-09-8

In this post I would like to talk about the practice of estimating tasks in hours in the iteration planning. After more than one year applying agile estimating techniques at work, I have changed my mind about this practice, and I would like to share my conclusions.

We started the development with the following SCRUM configuration:

  • Iterations of 4 weeks.
  • The Release Backlog is composed of user stories which are estimated in story points.
  • The Iteration Backlogs are composed of the selected user stories for the iteration, which are decomposed into tasks, that are estimated in hours.

This approach is supported by several books, including the original Scrum book and the superb Mike Cohn’s Agile Estimating and Planning book. The original Scrum proposal recommends 4 weeks as the duration of each sprint (iteration). Regarding to the backlog contents, the original proposal talks about features as the main item for the product backlog, and tasks for the iteration backlog. Features would be estimated in days and tasks in hours.

Mike Cohn elaborated on this proposing to use user stories as the main product backlog artifact, and tasks for the iteration backlog. He proposes to estimate user stories with ideal days or story points, and tasks in hours. It is worth to notice that the user stories technique was popularized by Kent Beck in his seminar Extreme Programming Explained book. In the first edition of the book, Kent Beck proposed to estimate the size of stories with points (1,2 or 3). But in the second edition he advocates for using real time estimates. In the same way, he proposes splitting stories into tasks and says that developers should estimate them, although many XP practitioners prefer not to estimate tasks at all, or even to create stories as small as possible in order to eliminate the need for separate tasks.

After several weeks applying the mentioned approach, I realized that there were some aspects I didn’t like in our planning strategy. The process of splitting stories into tasks and, specially, the estimation of each task was a high time-consuming activity for the project and added little value. I think that this activity was becoming what Lean people call waste:

  • Foreseeing estimations at the task level is, by definition, very inaccurate. It is not worth to think thoroughly about how many hours are you going to spend in implementing some subsystem and its tests. Specially if you do it one, two or three weeks before you do it. You’ll be wrong, because software development is a wicked problem.

  • If you are going to manage inaccurate estimations at the task level, you have added no value to the story point estimations you already have. These can be converted into real time easily using your team speed so, why bother in the extra-effort?.

  • In order to determine the tasks that need to be done for implementing a story, there are two contradictory forces:

    • If you don’t want to get deep in the design (after all, you are in an estimation meeting) you end up with a very similar set of tasks for many stories: design meeting, implementation, testing, documentation…

      Regarding to this, I found very artificial to estimate the hours you spend writing tests and implementing something. Can you separate both activities in a realistic way?

    • If you get deep in the design inside a planning meeting so you can create very specific tasks, then you are mixing two very different activities: design and planning. Each requires a very high amount of energy. I have found far more productive to postpone design discussions for late meetings where people can focus completely in the thing to be designed. When you are in a planning meeting you look at the whole number of stories from a very high point of view.

In my opinion, the main advantage of having tasks estimated in hours is that you can see how many hours are burnt daily in the sprint backlog, so it’s very clear how the team advances each day. However, only with the daily meeting and keeping the stories small you can perceive a good sprint progress information.

While the story-points estimations worked very well for estimating our release planning, I found that splitting and estimation of tasks with hours was very inaccurate and someway artificial.

So we decided to stop splitting stories into tasks (not only stop estimating them in hours, we stopped managing tasks as first-class planning artifacts). We want very small stories so we force ourselves to split them when necessary (while keeping them tracer bullets). And I don’t really miss tasks. Certainly, there are many times where it is useful to write down the high-level tasks that are needed for implementing some story, but we are fine capturing them as informal comments with the story.

In this process of improving our development method, we first used Excel templates for managing our backlogs. After that, we used Agilo: a very nice tool based on trac that can be easily deployed as a VMWare Appliance. It supported perfectly the estimation in story points and hours for the product backlog and the sprint backlog, respectively. When we changed our planning approach we started using Pivotal Tracker. Pivotal Tracker is an amazing tool. Funny enough, I proposed to their creators to have the possibility of dividing stories into tasks and estimating them in hours. Many people liked this feature, which is currently the number 8th in Pivotal Tracker Most popular topics. The first topic was add tasks to a story and they have already implemented it in a very nice and simple way (with no estimations of course).

In sum, in our current process:

  • We have iterations of 2 weeks (we preferred a shorter delivery cycle)
  • We manage user stories as the only planning artifact in our backlogs (release, product and sprint).
  • We use tasks for clarification of some stories, not as a general planning item.
No Comments

Slides of a talk on agile development and estimation for Preparatic

2009-09-8

I would like to share the slides I used in a talk on agile development. I gave the talk on last July, as part of the Preparatic weekly sessions. I really enjoyed it. The people received the lecture very well and many people participated with questions and opinions making the session much more interesting.

NameDescriptionLanguageDate
2009-06-CharlaPreparaticAgil.pdfSlides of a presentation on agile development and estimating techniques. They were presented in a Preparatic session.
spanish
2009-06
No Comments

The Composed Method implementation pattern

2009-06-28

Infoq is one of my favorite sources for reading general-purpose stuff on software development. Some time ago they published an excellent presentation: 10 Ways to Improve Your Code by Neal Ford. I just loved it. The first practice it focused on is the composed method implementation pattern, one of the most fundamental development practices I can think of.

It was formally described a lot of years ago, as a pattern, in Kent Beck’s book Smalltalk Best Practice Patterns. I havent’t read this book yet (it is arriving in my next Amazon’s order). Sincerely I don’t know anything about Smalltalk but people usually say that this book is recommendable for anyone interested in good programming practices. I’m sure I will enjoy it. I expect it to be better than Implementation Patterns, also by Kent Beck. While not a bad book, I thought it was going to be much better. In this book, it is said that you should:

Compose methods out of calls to other methods, each of which is at roughly the same level of abstraction

I don’t know why but I tended to call this implementation pattern as factorized code. I think it has to do with the fact that the first time I realized about its importance was reading Martin Fowler’s Refactoring book. It was a lot of years ago but I remember that in some section (I guess it was in the extract method refactoring pattern) the book said that when you have in your code something like this:

void someMethod(){
  //do some stuff
  line 1
  line 2
  line 3

  //calculate some other stuff
  line 4
  line 5
  line 6

  //do final stuff
  line 7
  line 8
  line 9
}

You should refactor to something like this:

void someMethod(){
  doSomeStuff()
  calculateSomeOtherStuff()
  doFinalStuff()
}

void doSomeStuff(){
  line 1
  line 2
  line 3
}

void calculateSomeOtherStuff(){
  line 4
  line 5
  line 6 
}

void doFinalStuff(){
  line 7
  line 8
  line 9 
}

It said that, instead of having a sequence of comments and lines of code, you should extract lines of code to methods with proper names. This way you could also remove comments, as they were redundant. If I remember something of the Refactoring book, is how impressed I was about Fowler’s coding style (the catalog is full of Java code samples).

In my first year at the University, we were taught about procedural programming. I remember being told that when you designed a program, you had to divide high-level routines into calls to lower-level ones. By doing this recursively, you obtained a tree, where leafs represented primitive routines.

Watching the way many people code it seems that this fundamental principle has simply being lost. It seems like if with objects, you only have to take care of carefully design the public contract of objects and their relations. While this aspect is very important, you have to pay a lot of attention to the design of internal code.

Although this pattern may seem very simple, applying it correctly is not as simple as saying you should divide methods into small steps. I think there are three fundamental properties that should rule methods design:

  • Cohesion
  • Clear interfaces
  • Symmetry

Methods should be highly cohesive. This means that methods should focus in a single responsibility or functionality. This property comes from the software quality field, usually applied to modules or classes. Applying it when designing methods implies that you shouldn’t have methods that do many things from the point of view of the client that is using it. Who is the client depends on the abstraction level where the code is being invoked. Could be another class o just a private method inside in the same one. A method that receives five parameters is usually a bad smell.

Methods should have clear interfaces. In Writing Solid Code Steve Maguire says that the signature of all methods (functions in those days) should be clear enough in order to understand what the method is supposed to do, without any other kind of documentation. Signature means the name of the method as well as of the parameters it receives and returns (and their types). Achieving this involves many things but without cohesion is just impossible.

The book shows a good example of how a method should not being designed: the C realloc() function. It just does many things with a very obscure interface, which you won’t understand without the documentation. The book also contains a very representative example from the physical word, the candy machine interface problem: when the candy machine offers numbers for both selecting products and displaying their prices. Methods should not offer a candy machine interface.

The composition of methods should also be symmetric. The steps a method is divided in should be at the same level of abstraction. Abstraction is a construction that a person does in order to understand something. Jumping from one level of abstraction to another requires mental effort. If you have to keep jumping between different levels of abstraction in order to understand some code, it will be far more difficult to understand.

In conclusion, while this pattern will improve the quality of your software, I use it because for me it is easier to program this way. It is just the principle of divide and conquer working. I usually code methods following a top-down approach. Writing the top level methods calling lower-level methods before they exist. This way I can directly project the structure of steps that I, like a human, have in my head. Other people prefer to write the code without decomposing it first, and then refactorize to extract methods (I think this approach is far less effective).

Anyway I think that if you apply this practice exhaustively, along with using proper names for naming identifiers, your code will be like a 400% better.

No Comments

Slides of Agile Development and Rails Course

2009-04-12

Here it is the last version of the presentation I used in the Agile Development and Rails courses I taught in the University of Oviedo (HCI-RG group). They correspond to a 6 hours-class (the whole course was one week length). It is a very short duration to introduce both the agile development approach and the rails platform so I had to leave out many things. I was very interested in the part of basic good development practices because I think these are easy to learn and very worthy for everyone.

NameDescriptionLanguageDate
2008-04-agile-rails.pdfSlides on Agile development and Introduction to the Rails Platform. They are part of the Agile Development and Rails courses I participated in at the University of Oviedo.
Spanish
2008-04
No Comments

Research Report on Model Driven Software Development (2006)

2009-04-12

In 2006 I got a FICYT Research Grant in Software Engineering. As the results of my research I wrote a document I would like to share. Since it was written three years ago it is quite outdated but perhaps somebody can find it useful.

The report shows very well my evolution during the research period. First, I was very interested in evaluating the possibilities of UML for specifying software formally. As result there is a very long chapter on the foundations of the language. Then I learned the benefits of the multi-DSL proposal (and the inconveniences of the UML-centric one), and the basics on model to model transformations and formal languages definition through their metamodels, and I focused my research on these topics.

NameDescriptionLanguageDate
2006-MDSD-FICYT.pdfReport on Model Driven Software Development. Written during the research period corresponding to a FICYT Research Grant in Software Engineering.
spanish
2006

No Comments

Slides of Web Accesibility Course

2009-04-10

There are some stuff I would like to share online. It may be useful for someone and is totally useless in my hard drive. Perhaps in the future I will create a downloads page or something similar. For now, I will collect these things in a Downloads Category in the blog.

One of the things I would like to share are the slides of the courses I have taught in the past years. This one is the last version of the Accesibility part I have been teaching in several of the HCI-RG courses on Human Computer Interaction.

The slides are mainly focused in the 1.0 version of the WCAG. It also contains an introduction to the 2.0 version and AJAX related issues. They were created using the HTML Slidy System so you can view them in the browser.

NameDescriptionLanguageDate
2008-07-CursoAccesibilidadWeb.zipSlides of a course on Web Accessibility. HCI-RG courses on Human Computer Interaction (University of Oviedo). In HTML Slidy format. View them online.
Spanish
2008-07

No Comments

The role of models in Agile and Model Driven Development approaches

2009-04-5

When I was at the university, I remember being very interested in the suggestion that building software was like building bridges, and that software should have blueprints as sophisticated as those needed to build a bridge. I remember to has been told that you will never find a book on “How to build bridges in 7 days” but you will find the equivalent on “how to learn C++ in 7 days”.

Today, I’m not so convinced that this analogy is a good one. I can’t agree more with this quote from Dave Thomas (the Pragmatic Programmers proposed a new analogy that I’m pretty sure not everyone can digest):

Software development is neither. Nor is it art. It’s just software development. People who look for the “software is like xxx” analogies are missing the point. Software development is like software development. Let’s decide what works for us, and have fun while doing it

If you are interested, Martin Fowler explains the reasons why the building bridges analogy fails. I think, there is a sentence in his article that summarizes the problem very well:

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

This question is, obviously, rhetorical. You won’t. Traditionally, the gap between models and code has been huge. If you ignore this gap, then you may think that you have to make great efforts in creating very rich models, so the low-skilled and no-talented programmer can translate them into working code. And if you can create these models, then nothing stops you from planning the full development process up-front. Since the construction phase is mechanical and predictable, then you only have to calculate how much time you will have to spend in modeling. And since modeling is about drawing (if we use this development approach we are using UML for modeling everything for sure), this estimation should be easy too. After all, drawings, like Word documents or Power Point slides, always compile and work. Of course, this scenery would mean that software projects are delivered on time, that the waterfall approach works, and that no matter wether the developers are talented or not.

In my opinion, the fact that models can’t be converted into code easily is addressed by the two development approaches I am more interested in:

  • Agile development

  • Model Driven Engineering (MDE)

Although both approaches are perfectly compatible, they propose different ways when it comes to use models. Both approaches see models as a communication tool, as a resource that let us, as humans, reason and elaborate solutions that solve complex problems. While agile practitioners warns you against using models for anything more than this, MDE practitioners propose to take the next step and convert models into first-class development artifacts.

The two approaches give different answers to the question of being able to create designs that can turn the coding into a predictable activity:

  • Agile developers’ answer is “no”. In fact, they propose to use many good development practices and exhaustive testing as a shield against problems when coding. Coding is not an ugly phase, neither is cleanly separated from design. There are not designers and programmers, there are developers. They will use models as a way to collaboratively obtain the best designs that solve the problem, not as a way of documenting it. And since they assume they can’t predict how the full process is going to be in earlier stages with detail, they are going to estimate and develop the project iteratively, using an empirical estimating approach.

  • The MDE answer is a little bit more complex to say, since the paradigm is in its earlier stages. But if we manage to have MDE solutions where we can define the best DSLs to describe a problem, and to specify how this input is translated into a working application, then, if these DSLs are defined in a way that are reusable in different instances of the same problem, we would be very close to being able to answer “yes” to that question.

By the way, a confluence of both approaches can be seen in the BDD (Behavioral Driven Development) frameworks: such as RSpec, Concordion or Cucumber, but I think that topic deserves a post on its own.

1 Comment

A nice iPhone tool for agile development

2009-02-16

From time to time I like to check for new applications for my iPhone. It’s pretty amazing how quickly the base of applications is growing, so I usually discover nice surprises.

So today I decided to look for application that was SCRUM-specific. Sincerely I didn’t expect to find anything, nor I had any concrete application in mind. The app store search dialog suggested ScrumTools. It’s a very very simple, but still useful, iPhone app. In its current version it offers two things:

Although books usually recommend it, I had never used a timer to control the daily meeting length. If you don’t take care, these meetings can be easily longer than the 15 minutes recommendation. Since members of the team expose their problems, discussions about how to solve things tend to appear quite often. The solution is as simple as delaying further discussions for specific meetings. The iPhone ScrumTools alerts at 10, 5 and 1 minutes remaining (the normal iPhone timer won’t do this). I thing is a very good way of focusing the meeting in answering the three questions

Screenshot of the timer of the ScrumTools for Iphone

Regarding to the Planning Poker activity, if you don’t know what it is about, you should read Mike Cohn’s book on Agile Estimating and Planning. It’s the best book on agile development I have read. Planning Poker is a technique for estimating size in software development. Basically, for each story:

  1. The story is presented and the team discuss about it.
  2. The members of the team choose a card that represents their estimation. We use story points in the set proposed by Cohn (1,2,3,5,8,13).
  3. Everyone turn their cards over at the same time.
  4. The members with the lowest and highest estimation expose their reasons, and then the estimation process is repeated.

The book tells that teams will find consensus soon. I was a bit skeptical about this after reading the book, but practice has taught me that a consensus is usually reached quickly.

Screenshot of the planning poker deck of the ScrumTools for iPhone

No Comments

Changed to WordPress

2009-02-8

I’ve changed my blogging system from Typo to WordPress. I found several problems with my Typo installation, specially regarding to performance. I was very interested in updating to the latest version of Typo, which addresses many problems (including its performance). Unfortunatelly, I didn’t manage to make it work in Site5, the hosting service that runs this blog. The last version of Typo runs on Rails 2.2. Site5 hasn’t updated to 2.2 yet. I updated my local gems of rails to version 2.2.2, but I didn’t manage to make it work (and it seems that I am not the only one having this problem).

I really love Typo and I don’t discard to use it again in the future. For now, I’m going to enjoy the benefits of using WordPress, the most widely used blogging System. I had some experience configuring a WordPress site, so I knew what to expect:

  • Extremely easy configuration
  • A huge amount of themes and plugins available

My first theme choice was Skittish (the theme I was using with Typo). The problem was that it wasn’t updated to the last version of WordPress and it needed minor fixes to work. I decided to browse the WordPress Theme Directory and this site which offers a selections of themes. Finally I found a very nice one: The Vostok theme. I was looking for something exactly like this:

  • Extremely clean and simple.
  • Maximum legibility with dark tones.

Their creators are experts in interaction design and usability. I think that a simple product like this blog theme is a proof of their philosophy and expertise. I just can thank them for sharing this wonderful theme under a GNU v2 license.

1 Comment