Jorge Manrubia

At work we have been experiencing serious performance problems with the Eclipse feature we are developing. We have just solved the problem and I would like to share the chain of events that caused it. I will elaborate on this a little bit, but in a few words:

• If you want to wait for jobs in Eclipse Junit Plugin tests, use this method instead of the proposed in the second edition of the book Eclipse: Building Commercial-Quality Plug-Ins.
• The global buddy class loading policy can affect performance seriously. It is logical and they warn you about it. I can confirm it is true.

Waiting for jobs in Eclipse JUnit Plugin Tests

The Eclipse PDE provides a launcher that let you test your plugins using JUnit. It basically instantiates a new Eclipse workbench and, when it is up, the tests are run inside it. When writing tests, a common need is waiting for jobs to finish. After launching a job for testing its results, the job is run in a separate thread, so the test code will continue running if you don’t stop it.

The book Eclipse: Building Commercial-Quality Plug-Ins is an excellent resource for learning Eclipse plugin development. It proposes some utility methods for using with Eclipse Plugin tests. One of this methods is indeed waitForJobs():

This implementation worked well for us until one day we decided to divide a plugin that had become too big. I started by creating a new plugin extracting some code of the plugin along with its tests. But the tests always failed launching a NoClassDefFoundError exception. I was totally convinced that this problem was related to the way we had configured class dependencies between plugins. We use Groovy and the exception was always launched from the groovy libraries referenced from groovy compiled code. I spend a lot of time trying to figure out what was going on. It was a colleague who pointed out that it seemed that the test code was not waiting for the job under test to finish. And he was right. After searching in google I found a more robust implementation of the waitForJobs() method:

Using this approach solved the problem. This would had nothing to do with performance if I hadn’t messed up with the class loading configuration trying to solve it. Basically I made many of our plugins to use a global buddy class loading policy and, once the problem was solved, I didn’t undo it. And, while we perceived a poor performance in our plugin, it wasn’t until recently that we discovered the cause was precisely that global policy (we thought it was a problem with the development installation of the system our product connects to). And this brings me to the next section.

Eclipse Buddy Class Loading

The Eclipse core platform runs on a sophisticated runtime for Java components (Equinox, an OSGI implementation). This runtime provides a powerful architecture for installing and running Java modules (bundles or plugins). For doing so, it redefines completely the class loading system of the Standard Java Platform. When running inside Eclipse, each bundle has its own class loader. Bundles declare in their manifests how do they relate to other bundles, so their class loaders know how to locate external classes.

When a bundle A depends on a bundle B it can access its exported classes with no problem. The problem comes when it is B who wants to load classes from A dynamically, but it can’t depend on it (because it would create a circular dependence, or just because it doesn’t make sense). For example, the Log4j bundle can’t depend on a bundle that provides a log4.properties configuration file but it still wants to locate it in execution time. We have a number of scenarios like this in our application, where some bundles need to load classes/resources from other bundles they don’t know in execution time.

In these situations Eclipse Buddy Class Loading come to the rescue (another approach, better but more complex, is to use extension points for allowing plugins to be extended in execution time). Buddy policies allow one bundle to declare that it needs to load classes from other bundles (buddies). When a bundle class loader fails to locate some class, it starts searching for it in the declared buddies. The system can configure a number of policies that determine the way classes are searched:

• dependent: search in bundles that directly or indirectly depend on the bundle.
• required: search in bundles that explicitly declare themselves as buddies of the caller bundle.
• global: search in all the bundles.

There are others policies available but I think the first two are the most common. Buddy policies are configured in the MANIFEST.MF file of the bundle that needs to load the classes. For example, in the manifest of the org.apache.log4j plugin you can find this:

Since it uses a registered policy, if you want your bundle to provide a properties file for log4j, you should declare your bundle as a buddy of Log4J.

With a dependent policy this last step is not necessary. As it is obvious, registered is more efficient than dependent, and this one is more efficient than global. In a product like our feature, which is big but not huge, when we changed from global to dependent we observed a huge performance boost, specially the first time the product functions were launched (which is when classes are loaded).

When you try to solve a mysterious bug for long time enough, you are so satisfied when yo do it that you don’t spend too much time blaming yourself for having produced it. And that was my state after this one…

I am involved in a personal project where I am developing a web application with Rails. I am using RSpec and Cucumber, and I am following an outside-in, behavior-driven development approach, as recommended in the excellent RSpec Book. In this post I would like to share a problem I found and how I solved it.

It started when I tried to refactor some duplicated code in my controllers specs. It was related to the authentication system. Specs should test their behavior in both authenticated and insecure contexts, to be sure that anything happens if an anonymous user sends a POST action to your WorldDestroyerController. For example:

The next fragment was recurrent in all my examples.

For every example in the example group, it basically stubs the controller method that validates sessions in order to get a valid one when invoked (I am using authlogic). I wanted to create a macro context_authenticated so I could code the previous example like this:

My first attempt was to write a macro that included the before block and yielded to the block provided in the invocation:

The examples failed because the before(:each) fragment was not being invoked before executing them. To discover the problem I had to investigate a little bit about how the RSpec DSL works. Basically:

• Each context (alias for describe) creates a new ExampleGroup subclass.
• Each it (alias for example) creates a new instance of the current ExampleGroup subclass where it is invoked.

So the problem was related to the very nature of closures. In Ruby, a block of code (proc or lambda) maintains the bindings in effect for that closure. The bindings contains not only variable references, but also the self reference itself.

In my case, what I was doing was to submit a closure with the it examples to the macro. The execution context of this closure was the one where it was defined: the ExampleGroup subclass created by describe UserSessionsController.... However, inside the macro, a new ExampleGroup subclass was created, and the before block was associated with that example group. That was the reason why the the before code was not getting executed before the submitted examples. Once I understood this, the solution was simple:

What the previous code does is to change the evaluation context of the closure, so it get executed inside the ExampleGroup class created by the macro.

I have decided to write my first review on my last reading: The Mythical Man-Month: Essays on Software Engineering.

The title of the book refers to the the unit of effort man-month. It is used by (I want to think ‘old’) metrics to estimate and schedule software development. As Brooks explains in his book, while cost varies on the product of number of people and number of months, progress does not. It would do it if tasks in software development could be partitioned between individuals with no communication among them. When you take into consideration the need of communication between parts, the effort increases as n(n-1)/2. The famous Brook’s Law appeared in this book as an oversimplifying but eloquent way to capture the problem:

Adding manpower to a late software project makes it later

If you are interested in reading about the importance of communication in software development I recommend you to read Agile Software Development: The Cooperative Game. This book contains the most sensible discussion on the nature of software development that I have ever read. Cockburn defends that software development is a cooperative game of invention and communication.

Returning to the The Mythical Man-Month book, Another thing I loved is how it talks about the human factor in software development. In the chapter The surgical team, Fred Brooks says the following:

The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming

When I read this sentence I was totally amazed. Notice that the author was the project manager of the massive software system of IBM System/360 (OS/360). So more than 3 decades ago, a software developer with experience in developing huge programs, didn’t emphasized the need of ceremony and heavyweight recipes for software development. Instead he could clearly see what many people can’t today. He proposed that the most expert programmers should act as surgeons leading a surgical team. The rest of the team should assist them in order to maximize their effectiveness with the core tasks of writing the specs, designing, coding and testing.

Fred Brooks mentions a 1968 study that concludes that the best programmers are 10 times more productive that the worst ones. Robert L. Glass in Facts and Fallacies of Software Engineering talks about numbers ranging from 5 times better to 28 times better. Ignoring this fact is, in my opinion, the source of many deep problems in the spanish software development industry today. Companies don’t see technical talent as an asset to make more money, but simply like something academical.

Although these were the topics I enjoyed most, the book covers many other software development principles which are totally valid today: the importance of prototyping and the wicked nature of the discipline, the dangers of over-designing, the need of cohesive teams with good communication mechanisms… The visionary condition of the author was proved again with his famous article No silver bullet, which stated that nothing in the next 10 years (from 1986) would provide one order of magnitude improvement in software development. The article is included in the book by the way.

In conclusion, it is a book that I totally recommend. The principles it talks about are totally valid today and I really enjoyed reading about them considering the time the book was written. I am simply amazed by the fact that 34 years ago, someone was able to recapitulate so many true and concise ideas on software engineering, even before that software engineering, as a discipline, existed.

I have created an electronic registry of the books I read. To create it I have used the Now Reading Reloaded extension, based in the excellent Wordpress Now Reading extension. This extension makes very easy adding books searching for them in Amazon, and retrieving their data from Amazon’s servers (including their cover image). It also let you manage the life cycle of books (reading now, finished and unread).

So I installed this extension, went to my physical library and added the technical books I own. Then I modified the PHP templates to fit my page theme and show the results in the way I wanted.

My last two Amazon’s orders have been quite big (the current USD/EUR exchange rate has something to do with it), so now I have 16 books waiting to be read in my library (and a few more in my Amazon’s wish list). In recent times I have focused my reading mainly in agile development, ruby on rails, good programming practices and, to a lesser extent, user experience design.

I intend to write reviews of the books I read in the form of blog posts. I’ll link back the reviews from the book backlog, using a Now Reading feature that let you associate a post number to book entries.

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:

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.

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

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:

You will obtain something like:

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:

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:

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).

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.

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.

Name	Description	Language	Date
2009-06-CharlaPreparaticAgil.pdf	Slides of a presentation on agile development and estimating techniques. They were presented in a Preparatic session.		2009-06

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:

You should refactor to something like this:

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.

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.

Name	Description	Language	Date
2008-04-agile-rails.pdf	Slides 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.		2008-04

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.

Name	Description	Language	Date
2006-MDSD-FICYT.pdf	Report on Model Driven Software Development. Written during the research period corresponding to a FICYT Research Grant in Software Engineering.		2006