«When you run a business, if your software has a bug, your customers don’t care if it is your fault or Linus’ or some random Rails developer’s. They care that your software is bugged. Everyone’s software becomes my software because all of their bugs are my bugs. When something goes wrong, you need to seek out what is broken, and you need to fix it.»
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.
Etiquetado: Desarrollo de software RSS Mostrar/ocultar comentarios | Atajos de teclado
-
Andrés
-
Andrés
Programming on principle
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.
-
Andrés
On delivering software
More than ten years ago, some visionaries got together in the mountains of Utah to relax, ski and discuss on the challenges of their profession. That was the very moment when the Agile movement cristallized. They wrote a manifest and 12 principles. The first gem goes like:
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.
-
Andrés
Coders at work: netscape y javascript
Estoy leyendo a ratos Coders at work, un libro de entrevistas a programadores inspirado en lo que hizo The Paris Review con su serie Writers at work, por la que pasaron Hemingway, Capote, Borges, …
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.
-
Andrés
If you’re trying to make a successful tech product, 90% of the battle is that it works at all.
Havoc Pennington, on creating a successful product… and companies I would add. -
Andrés
«And this is the essential broader point–as a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria.»
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. -
Andrés
I found interesting this serie of posts titled “4 big ideas in software development” according to Tim Ottinger and Jeff Langr. The serie was published monthly in Pragmatic programmers magazine:
- 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?
-
Andrés
How gvSIG MapControl works: flow of control
Within gvSIG design, MapControl is one of the core components. Its main responsibility is to allow users to interact with a map of layers (zoom in/out, edit geometries, …). That goal is achieved through two concrete tasks:
- 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:
- 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).
- 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).
- Finally, the ToolListener will execute the actions needed to carry on the task an user have asked for.
Some notes before digging into code:- MapControl can have only 1 tool (Behaviour) active at any time. It holds the current selection in a private variable: Behaviour currentMapTool
- MapControl wraps MouseEvents in 4 basic canonical events (see com.iver.cit.gvsig.fmap.tools.Events within libFMap project): MeasureEvent, PointEvent, MoveEvent and RectangleEvent. Any other event will inherit from and extend one of these canonical forms.
A concrete example: how a move event is processed
1 – MapToolListener: listen the mouse event and proxy it to the current selected behaviour (currentMapTool variable).
public void mouseReleased(MouseEvent e) {
try {
if (currentMapTool != null)
currentMapTool.mouseReleased(e);
} catch (BehaviorException t) {
throwException(t);
}
}2 – Behaviour (MoveBehaviour in this case): takes the event, put together the context (MoveEvent) and redirects the petition to the proper ToolListener (listener variable).
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;
}3 – ToolListener: carry on the task. In this case, the listener (a PanListener) make the viewport to update the extent with the new contents.
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);
}Coda
Some useful resources about MapControl in gvSIG wiki:
- MapControl (spanish)
- Behaviour (spanish)
- ToolListeners (spanish)
- Events related to toollisteners (spanish)
Links to code:- Mapcontrol
- Canonical events of MapControl:
Andrés
Done some reorganization on wiki contents and wrote a bit on refactoring and code smells. I’m proud on the pace and themes the wiki is evolving: I have grown quite a bit of software development topics, which is a reflection on my readings and focus last years. Although could evolve later, the topics on software development are organized in 3 subcategories:
- 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.
Andrés
Los costes de no trabajar upstream
Imagina el siguiente caso: deseas usar una aplicación que es software libre para construir tu propia solución ad-hoc sobre ella. Y lo harás muchas veces para diferentes clientes/productos. ¿Cómo enfocarlo? ¿Construyes tu solución con tus mejoras para ti modificando lo necesario o integras tus mejoras en la versión upstream, en el proyecto original?
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.
Luego de leerlos, tendrás una visión más clara de si te compensa o no trabajar con upstream. Si lo que deseas es construir una aplicación vertical con una buena integración (y menos costes de mantenimiento) para sucesivas versiones del software base, la respuesta será sí.
Nacho V han comentado. -
Nacho V
Jim Zemlin (Linux Foundation chief) talking about the issue of contributing back, “[It's] not the right thing to do because of some moral issue or because we say you should do it. It’s because you are an idiot if you don’t. You’re an idiot because the whole reason you’re using open source is to collectively share in development and collectively maintain the software. Let me tell you, maintaining your own version of Linux ain’t cheap, and it ain’t easy.”
http://www.networkworld.com/news/2011/083011-zemlin-250234.html