All English

«My friends and I have been coddled long enough by a billionaire-friendly Congress. It’s time for our government to get serious about shared sacrifice.»

— Warren Buffer, NYT 15/08/11

On the the differences between the taxes to labour and the taxes to capital in USA.

All English iCarto Programming pills

How gvsig manages the snappers

Last week I paired together with Francisco Puga to review the status of opencadtools. As Fran is doing a great work in preparing the integration of opencadtools as default CAD tools in gvSIG, I wanted to know first hand how it was going. iCarto and Cartolab were kind enough to sponsor this pairing session. One of the results, apart from working with Fran -which is always motivating and enjoyable, per se-, was a deeper understanding on how snappers work in gvSIG, which is something I had asked myself sometimes. And, as one of the improvements of opencadtools is a followgeometry snapper, it seems a good goal to review that part of the project. Find below the summary:

CADToolAdapter class in extCAD extension maintains a list of snappers and layers to snap to from the editing layer. When the mouse is moved, the snappers are recalculated following this algorithm (note that the code below is the core of the method, some other parts/casts and boilerplate code is missing):

ArrayList snappers = SnapConfigPage.getActivesSnappers();
ILayerEdited layerInEdition =
ArrayList layersToSnap = layerInEdition.getLayersToSnap();

for (FLyrVect layer : layersToSnap) {

    // Getting the set of geometries within the envelope
    // The envelope is calculated based on the tolerance the user wants
    SpatialCache cache = layer.getSpatialCache();
    List geometries = cache.query(envelope);

    // Updating the nearest point
    for (Feature geomToSnap : geometries){
        for (int i=0; i distance){
                minimunDistance = distance;

This algorithm is executed every time the user move the mouse and is very quick if you have few layers to snap to. But, as the number of layer to check increases, the editing process becomes very slow. Besides, as a comment of software design, after reviewing this part of code, I like the way the snappers fit in gvsig cad tools. If you want to add a new snapper, just need to implement ISnapperVectorial interface and make getSnapToPoint method to return the nearest point to the position of the mouse. So, designing your own snappers is very easy!

By the way, if you feel like replying how other GIS applications (QGIS, uDig, …) manage the snappers, I’d be more than happy to hear and learn that!

All English Radar
Two stories on developing software applications. In both cases the client is the public administration, but the way every one was managed and build was quite different:
  • Lean from the trenches, de Henrik Kniberg. Tell the history of how the PUST was built: PUST is an acronym of “Polisens mobila Utrednings Stöd”, a national-wide application for Swedish policemen.
  • Who killed the virtual case file, a very instructive showcase on the famous failure of VCF, an application to manage cases developed by the FBI.
All English Radar

One of those good old texts to revisit from time to time: Who needs an architect? by Martin Fowler. If you are in the software industry, please, make yourself a tea and get 10 minutes of good reading. Will help you to understand what technical leadership means.

All English Fortunes Radar

Code should grow by addition rather than mutation.

Measuring the closure of code, Michael Feathers. Via: Software volatility.

All English Fortunes Radar Software Libre

If we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”.

— Edsger Dijkstra. Quoted on Are all patches create equal? by Jonathan Corbet.

All CartoLab English Events iCarto

gvSIG codesprint in A Coruña: a personal summary

As you may know, iCarto and Cartolab have hosted a gvSIG codesprint at the nice city of A Coruña. iCarto was kind enough to support my attendance to the event to work on gvsig, navtable & navtableforms. Find below some comments on my personal experience.

Some general impressions on the event

  • It’s great to see codesprints are becoming usual in gvsig project. It’s still a new practice to be fully embraced for most members of the community but taking into account that the the first codesprint I proposed was almost 1 year ago, we have good rithm (this was the 4th codesprint!). It feels good to see such an amount of people and energy during the codesprint. It is encouraging and talks about their commitment to the project.
  • This codesprint was the 2nd in number of participants after the one in Valencia! That confirms that Galicia matters 🙂 That was the good news. The bad ones: I’ve missed developers from England (do you know London is directly connected to A Coruña by flight?), Portugal (don’t you know that we speak the same language?!) and more people, shops and gvSIG members & collaborators from Spain, though. We should try harder to bring people to codesprints.
  • That kind of events are great to grow relationships and trust. Also they are great to communicate diffuse information and transfer knowledge: we had some good conversations with Joaquín del Cierro (gvSIG development manager) about the technological background of the project, how some decissions are made and the direction of the development theses days.

NavTable and NavTableForms: what we have done

In the hacking side, I’m pretty happy with the results. Most of the time, Jorge López and me paired together to resolve the priority things on NavTable and NavTableForms. Here the results:


  • Flavio Pompermaier had talked us about the differences between layer.getSource().getRecordset() and layer.getRecordset() methods. Roughly: the second returns the features directly from the source, which seems to reflect changes (schema modifications, add new registers, etc) in real time. I spent a time to reproduce the bugs he showed us but I couldn’t. The last work on listeners done by Javier Estévez and to be integrated in gvSIG 1.12 had solved it.
  • Having some good conversations with Nacho regarding past conversations and improvements on NavTable UI. Some of the proposals will appear soon on your favorite mailinglist!
  • Having some good conversations with Joaquín on metadata and filtering in gvSIG, which resulted on:
    • metadata: the better way to integrate metadata into gvSIG sources is by doing your own custom mechanism, as we already have (for example: to associate to the data domain-values or validation). There is no such a thing of a broad standard on the matter (although there are some attempts).
    • pre-filtering from datasource (definitionExpression in other GIS applications): I had asked that in the mailinglist (and even got a only-read solution). Lately, it appeared again in gvsig-international a thread talking about that. The short answer: it’s not possible to do it now.
  • Refactoring to actions. I work on this during Friday morning. It was more difficult that I thought as our codebase is very coupled at some key part, which required an aditional work to do this. What I got is an initial prototype working (uploaded to a temporal branch on our repo) only with the moving actions (go-next, go-last, go-previous, go-first). Although still a prototype I think is very promising as a base to work on.


  • Landing into trunk, the big rewriting done in NavTableForms. Jorge and I spent thursday morning reading code, updating the example for it to work with the new code and with integrating issues. It was easier that I thought, and we had the example working in less than 3 hours. I even write down our mini-guide to migrate the example, as it could be interesting for other people.
  • Add support for reading domain values from a text file. One of the news on NavTableForms is that it’s able to read domain values from a database (say postgress). Jorge worked to add support for textfiles in a similar way than we do for alias.
  • Adding support for multiple validation rules. Jorge worked and integrated this very nice feature.
  • A new validation rule: mandatory field. I commited this to repo. By the way, It’s nice to see how easy is to add a new rule.

Summing up: as you may see, they were two intense days! A lot of work done and the hacktivation energy at full again. Looking forward to next one!

All English Radar

«No architects. Engineers works across the entire stack»

— TripAdvisor engineering team

TripAdvisor is one of the largest travel sites: 40M Visitors/Month, 200M Dynamic Page views/Day, … how do they make this possible? Here the answer. As I’m a culture/development process junkie, I’ve search how they work. Their approach: an extremely agile culture (as they put it: ) with a lot of code/design review and co-responsibility on your own work.

All English

«Social networks are the modern Romeo and Juliet story. If Romeo is on Facebook and Juliet is on MySpace, there’s no way that they can ever be together»

— Evan Prodromou at OSCON 2009

All English Radar

Software: an utility or a strategic asset?

«One of the most important ways in which these efforts differ is where the risks lie.

For utility projects the biggest risk is some kind of catastrophic error – you don’t want the sewage pipe to break, or to miss payroll. So you need enough attention to make sure that doesn’t happen, but other than that you want costs to be as low as possible.

However with strategic projects, the biggest risk is not doing something before your competitors do. So you need to be able to react quickly. Cost is much less of an issue because the opportunity cost of not doing something is far greater than costs of software development itself.»

— Martin Fowler, on software as utility or as strategic assET