Code should grow by addition rather than mutation.— Measuring the closure of code, Michael Feathers. Via: Software volatility.
Durante el fin de semana, a ratos libres, he ido completando el wiki con una entrada sobre los principios del desarrollo de software que todavía tienen que evolucionar. Aunque la programación es una tensión continua entre varios heurísticos, tener en mente lo anterior y seguir unas técnicas de trabajo adecuadas me ayuda a tomar decisiones.
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.
¿Usuarios habituales de gvSIG? No os perdáis esta extensión que añade nuevas funcionalidades al TOC estándar que acaba de liberar Cartolab.
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!
«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.
Poco a poco el wiki toma más contenido. En los últimos días he estado añadiendo técnicas, conceptos, personajes y eventos del mundo SIG que almacenaba en local. Está muy en pañales todavía y, debido a la actividad de la última semana, contiene principalmente conceptos e ideas relacionados con el análisis geográfico. Pero crecerá!
«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