Why you should read the source if your shop sells custom apps on top of a framework. HN original post. Related: The costs of going it alone & Working with upstream: an interview with Lazslo Peter.

If you only watch a keynote this year, make it this one: Bret Victor – Inventing on Principle.

The serendipity again: I found this video few days after I finished reading Implementation patterns, by Kent Beck. Both two are connected, in the sense that Bret Victor talks about the importance of values and principles in our life and work -with amazing demo examples implementing his particular principle! Beck does the same at the level of programming.

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.