Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

And only now we all are understanding what they mean. Even them.

• In Software G Forces: the effects of acceleration, Kent Beck discusses the technological and business challenges of making your releases shorter. And why that matters (see also a good summary of Beck ideas by Mary Poppendieck).

• On the other hand, Jeff Humble and David Farley have published a (jolt-award wining) book called Continuous delivery, which goes (technological) deeper on the value proposal done by Beck. I highly recommend this talk by Jeff at DevOps Hamburg and the introductory article.

Seems that it takes 10 years for the new ideas to mature and emerge in other shapes and wrappings. Nice to see that we, (“software deliverers”) as a profesion, are continuously improving.

He empezado por aquellas que más me sugerían, por ejemplo, la de Jamie Zawinski, uno de los líderes detrás de la liberación del código de Netscape y cofundador de la fundación Mozilla; seguida por la de Brendan Eich, también cofundador de Mozilla y creador de javascript. Me ha gustado descubrir no sólo su trayectoria personal, si no el ambiente que se respiraba en Netscape en aquella época. Totalmente imprescindible como complemento el documental Code Rush:

Al acabar la de Eich, he empezado con la de Douglas Crockford, creador de JSON y uno de los principales gurús del lenguaje. Mundialmene conocido por Javascript: the good parts y sus talleres de introducción a Javascript. El libro y la serie completa son una deliciosa joya para todos los que aspiren a saber algo del lenguaje. De entre todos los videos, por contexto, recomendaría ahora el primero, que versa sobre la historia del javascript (según sus propia interpretación):

Estoy disfrutando enormemente del libro. No sólo me sirve para conocer más ciertos aspectos de nuestra reciente historia (la de la informática y sus empresas) si no también para de algún modo entrar en el proceso creativo de grandes programadores, cómo se enfrentan ellos a la tarea de programar. Conocer, de cara a mejorar el mío propio.

Havoc Pennington, on creating a successful product… and companies I would add.

Dhanji R. Prasanna (one of the engineers behind Google Wave), on how even the smartests fail to stick to the essential. Jointly with this other post, they both draw a good story for any startup to hear.

• Code coupling, or Reducing dependency in your code.
• Cohesive software design, or Cohesion makes code easier to understand, debug, and test.
• Abstraction, or How to tell a cat from a dog.
• Software volatility, or Do most changes to your code base occur in just a few files?

• Route the user actions to the proper tool which will execute it.
• Manage the drawing of the layers.

This post covers the first of above tasks in an introductory way.

Flow of control

MapControl is a java component, which uses the idea of Chain of Responsibility to delegate work on others. Let’s see how it works in this case with a good old graphic:

1. MapControl listen MouseEvents through the MapToolListener. In response to an event, the MapToolListener will call the active tool (let’s say this class is named Behaviour).
2. The active Behaviour processes the info from the mouse, put together the contextual information needed (let’s call that an Event) and calls the next step in the chain (let’s call it the ToolListener).
3. Finally, the ToolListener will execute the actions needed to carry on the task an user have asked for.

public void mouseReleased(MouseEvent e) {

    try {

        if (currentMapTool != null)

        currentMapTool.mouseReleased(e);

    } catch (BehaviorException t) {

        throwException(t);

    }

}

public void mouseReleased(MouseEvent e) throws BehaviorException {

    if (e.getButton() == MouseEvent.BUTTON1 && m_FirstPoint!=null) {

        MoveEvent event = new MoveEvent(m_FirstPoint, e.getPoint(), e);

        listener.move(event);

    }

    m_FirstPoint = null;

}

public void move(MoveEvent event) {



    ViewPort vp = mapControl.getMapContext().getViewPort();

    Point2D from = vp.toMapPoint(event.getFrom());

    Point2D to = vp.toMapPoint(event.getTo());



    //build the new extent

    Rectangle2D.Double r = new Rectangle2D.Double();

    Rectangle2D extent = vp.getExtent();

    r.x = extent.getX() - (to.getX() - from.getX());

    r.y = extent.getY() - (to.getY() - from.getY());

    r.width = extent.getWidth();

    r.height = extent.getHeight();



    //update the ViewPort

    vp.setExtent(r);

}

Some useful resources about MapControl in gvSIG wiki:

• MapControl (spanish)
• Behaviour (spanish)
• ToolListeners (spanish)
• Events related to toollisteners (spanish)

• Mapcontrol
• Canonical events of MapControl:
• MeasureEvent
• MoveEvent
• PointEvent
• RectangleEvent

• History of software development: remember to build your products on top of giant’s shoulders.
• A programmer toolbox: common knowledge a developer should know. Items focus on programming and code.
• Project management: issues to take into account when managing a software development project: from concept to cash. Mainly not related to code.

Si ése es tu caso, te recomiendo que leas estos 2 artículos. El primero se centra en los aspectos económicos y sociales, el segundo en los técnicos y sociales:

• The cost of going it alone, de Dave Neary. Un buen repaso histórico con casos como el de  Softway con GCC (cambios relacionados con Windows NT), Nokia con GNOME (cambios relacionados con Maemo) o Google e IBM con el kernel (el primero por cambios en Android, el segundo por cambios relacionados con drivers para manejar discos virtuales).
• Working with upstream: an interview with Laszlo Peter, by Stormy Peters. Laszlo Peter era release engineer en Sun, es decir, quien se tenía que preocupar de que en cada nueva release de Solaris todo fuese bien.

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 =

    CADExtension.getEditionManager().getActiveLayerEdited();

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<snappers.size(); i++){

            Point2D pointToSnap = snappers[i].getSnapPoint(queryPoint,

                                                geomToSnap,

                                                tolerance,

                                                lastPointEntered);

        }

        double distance = pointToSnap.distance(queryPoint);

        if(minimunDistance > 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!

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