Treinta y cuatro

Hace unas semanas he cumplido mi vuelta al Sol número 34. ¿Qué ha pasado en todo este tiempo? Lo resumo con este post, para mi yo futuro y porque recordar todo lo que uno ha hecho ayuda a no perder la perspectiva.

iCarto

Este año ha sido el 5º aniversario de iCarto y lo hemos celebrado con familia/amigos. Los primeros años fueron duros, probablemente cometimos todos y cada uno de los errores que una nueva empresa puede cometer, esas cosas que no salen en los manuales de MBA y que suponen una verdadera prueba de resistencia. El futuro de la empresa ahora es muy prometedor. Las heridas se han convertido en marcas que uno enseña con orgullo y guarda como recordatorio. Haber contribuido a construir una dinámica de sostenibilidad en el medio de una profunda crisis económica como no se recordaba es algo que quedará para siempre grabado en mi memoria.

icarto

A nivel proyectos, lo más significativo del último año ha sido:

  • Bantegal: la aplicación del banco de tierras de Galicia. He colaborado con un grupo de otros 10 desarrolladores con un background muy diferente al mío, lo que me ha exigido mucho a nivel personal. A nivel funcional, lo más reseñable quizás sea que he desarrollado el componente de cobros y pagos para interactuar con los bancos, implementando el estándar SEPA. Tecnologías: Java, Spring, Wicket, Struts, JSP.

Captura de pantalla de 2016-06-08 20:46:02

ccsi

  • En los últimos meses, he estado centrado en idear y desarrollar una aplicación para la gestión de explotaciones y usuarios del agua que se usará en Mozambique. Fran me ha ayudado a programar lo que teníamos entre manos, que era bastante ambicioso. Es un producto empaquetado con Electron que se divide en 3 componentes principales: una interfaz web, un API REST y una base de datos. Ésta es una arquitectura que ya he usado en otros proyectos y que poco a poco se está convirtiendo en mi default. Continuando con mi evolución hacia la  creación de librerías reutilizables siguiendo la filosofía UNIX, en este proyecto he publicado backbone-uilib, backbone-geojson y leaflet-table. Tecnologías: JavaScript, HTML/CSS, Backbone, Bootstrap, Python, Pyramid, SQLAlchemy y PostgreSQL/PostGIS.

utentes-show

El mundo maker

El último año he estado especialmente activo en el mundo maker. En Mayo del 2015 me convertí en el nuevo presidente de Makers.Lugo, lo que significó poner al día la asociación a nivel burocrático y consolidar un creciente grupo de gente alrededor nuestra. Por tercer año consecutivo, hemos realizado el GenuinoDay en Lugo. Este año la organización la ha liderado Sancos, que ha conseguido organizar el mejor evento hasta la fecha y al que agradeceré eternamente el esfuerzo inmenso que ha hecho durante todos estos meses.

OLYMPUS DIGITAL CAMERA

En Otoño me he pegado un buen recorrido por ferias y conferencias, con un enfoque muy maker: en Santiago la mini maker faire, la OSHDEM en Coruña, el Somero en Gijón; he vistado a la gente del Fablab León y he participado en mi primera conferencia de diseño.

Azuzado en parte por experimentos que hice años atrás, me decidí a proponer una actividad para los miembros del Club de Las Indias: recuperar los valores de la abundancia en la navidad mediante los objetos con los que la celebramos. Un arrebato a lo William Morris. La propuesta fue acogida con entusiasmo y en estos meses de principio de 2016 hemos acabado la fase de investigación, cuyo resultado se puede leer en este epub. Hemos también ideado ya algún producto y estamos ahora con las manos en la masa.

A nivel personal

En este blog he estado bastante activo y casi sin darme cuenta he escrito un ensayo sobre desarrollo de software en una PYME, ordenando las notas que había interiorizado en mi cabeza a partir de la experiencia de los últimos años. He arrancado también un blog musical y otro donde recopilo notas de diseño de interacción.

He visitado Nueva York, Madrid, Berlín, San Petersburgo y París.

He leído más libros de diseño que de cualquier otra cosa y algunos han pasado a mi lista de recomendados. La scifi se ha hecho un hueco también: Oveja mansa de Connie Willis y La mano izquierda de la oscuridad de Ursula K. Le Guin. Me he puesto al día en novela negra leyendo la serie creada por Domingo Villar que tiene como personaje principal al inspector Leo Caldas: Ollos de auga y A praia dos afogados. Siguiendo con el consumo cultural, esta temporada me han cautivado Halt and Catch Fire y El Ministerio del Tiempo.

A principios de 2016, he recuperado la trompeta para tocar en un concierto con amigos. He aprendido las reglas del go. Estoy preparando el certificado Advance de inglés. Esta temporada de la competición de trivial nos ha ido mal, pero nos seguimos divirtiendo. Además de un nuevo portátil, me he comprado mi primer coche.

La lección vital más importante que he aprendido es ésta: uno es lo que hace, no lo que representa. La vida merece la pena sólo si la compartimos con otros que nos ayuden a ser una versión mejor de nosotros mismos.

Lo que me lleva directamente a la banda sonora de este año:

La vuelta 34 ha sido muy intensa. Estoy listo para la siguiente!

Me acabo de comprar un portátil

Luego de casi 5 años con el portátil de empresa, me he visto obligado a comprar uno nuevo. Lo cierto es que, personalmente, me daba una pereza increíble actualizarme y ponerme a comparar características para saber cual me convenía. No me llama conocer el último componente de cada aparato ni soy nada coqueto en lo que se refiere a estar a la última. Me rebelo contra las modas de hoy en día en forma consumo minimalista. Uso mis superpoderes de comprador con cabeza.

Mi problema

La situación actual era tan sangrante y antiproductiva que no tuve remedio: mi equipo actual tarda 6 minutos en realizar un proceso que mis compañeros de proyecto realizan en 40 segundos.

Por otra parte, ese proceso es central a la actividad y lo tengo que realizar varias veces por hora: consiste en hacer un cambio en el código de una web y verlo, es decir, la actividad básica de cualquier programador. Sí, 6 minutos: desde que modifico el código hasta que el paquete war es generado y desplegado en un entorno Java para ser visto en una web. En ese tiempo sólo me queda esperar, pensar en el siguiente problema o resolver microtareas que me despistan del objetivo que tengo entre manos. Es decir, en 1h puedo hacer 8 cambios. Si estás leyendo esto y eres programador valora cuántos cambios necesitas para ajustar y resolver un problema habitual. Aunque moví todo lo que pude a ciclos de feedback cortos (del orden de segundos) gracias a una política de tests agresiva, hay cambios que necesito verlos en la web con otros objetos cargados (es decir, tampoco pude montar un entorno mínimo de prueba que fuese más rápido de desplegar).

Por lo demás, el portátil actual funciona para tareas ofimáticas y cualquier otro proyecto de desarrrollo en los que participo. Evidentemente, uno nuevo siempre será mejor, pero no tenía la necesidad de cambio. Sólo por este proyecto.

El análisis: ¿necesito más micro o más memoria? ¿un disco SSD?

Lo primero que hice fue preguntarle a mis compañeros de proyecto cuáles tenían ellos. Quizás con algo modesto podría arreglar. Pero nada más lejos de la realidad, me quedé asombrado de las máquinas que me decían: entre 12 y 20 Gb de RAM, procesadores quad-core y discos SSD. Como mínimo. Miré los precios de mercado para algo similar … y me entró una depresión. ¿En serio tengo que gastarme esto por 1 proyecto?, pensé. No es que sea agarrado en las cosas que realmente tienen un impacto en mi vida ni mucho menos, pero hay cifras que verlas juntas generan un estado mental de desequilibrio.

Por suerte, Fran y Pablo se habían comprado 2 ordenadores con características distintas entre sí pero en un rango de precios aceptable para mí. Abusé de su hospitalidad y les pedí que montasen un mini-entorno de desarrollo con mi proyecto en sus equipos para hacer unas pruebas. Salieron bien y recuperé un poco el color en la cara. ¡Había solución a mi dilema sin empeñarme!

Como dije, los portátiles que usé de conejillo de indias eran diferentes (dual core VS quad core, disco SSD VS de aguja, 1.5Kg VS 2.5 KG, …) así que tampoco tenía una idea clara sobre qué estilo de portátil escoger. Durante unos días me puse a analizar cómo uso yo el equipo, si las actividades que hago son más intensivas en CPU o en RAM y si la mejora del acceso a disco que promete el SSD es en mi caso relevante. Lo cierto es que esto resultó más fácil de lo que creía inicialmente; total, tenía 6 minutos que rellenar entre cambio y cambio. Me encontré con que en mi día a día es fundamental el acceso a disco: tanto porque en los proyectos siempre uso bases de datos como por la compilación de archivos (que genera nuevos archivos en disco). El micro, en momentos puntuales llega a su límite por alguna actividad como la compilación de código pero en general está muy liberado. Los 4Gb de RAM actuales se quedaban cortos a la mínima que abría un navegador, un editor de código y alguna otra actividad. Esto encajaba con mis sensaciones en los últimos años, así que me decidí por una configuración mínima: disco SSD, un micro dual-core i7 y 12Gb de RAM, más de los que nunca creí poder llegar a usar. Con eso de mínimo, tenía garantizado que me servía para el proyecto y el gasto no era inútil.

Me fui de nuevo a las tiendas. Casi me entra la segunda depresión. Uf, vaya precios. Por otro lado, las configuraciones mainstream no pasan de 8Gb de RAM y salirte de ahí sube un montón. Por suerte para mi bolsillo, no era prudente ponerse a cambiar de portátil en medio de un proyecto así que tenía 4 meses hasta que fuese crítico hacerlo. Podía esperar. A una oferta, a que bajasen los precios de la configuración que yo necesitaba o que los portátiles mainstream subiesen la RAM disponible. Y así me puse, a la espera, con un ojo en la marca que empaqueta los teclados que tan bien le sientan a mis manos y que construyen portátiles con certificación militar de durabilidad, por si sonaba la flauta. Por desgracia para mí, en esta iteración se habían pasado de rosca y, por los mismos componentes, salía en unos 200€ más cara que la competencia. Voy a tener que comprarme un porta de hipsters, pensé. Definitivamente no era mi mejor momento. Con todo, me dije que tenía 4 meses y que la situación podía cambiar, así que esperé.

Durante varias semanas estuve revisando varias opciones de portátiles que me valían. El tiempo pasaba. De 6 en 6 minutos. Hasta el 27 de Agosto. Entonces, Thinkpad decidió hacer un 10% de descuento en sus portátiles por la vuelta al cole. Un 10%. Con la configuración que yo quería. Thinkpad, mi primera opción si bajaba de precio. Actué como un felino. Rápido, sin dudas. Compré.

En un par de semanas recibiré mi nueva máquina que, además de ser preciosa, es tan potente como para enviar un satélite a la luna. Ah. Y desplegar un war a Tomcat en menos de 1 minuto. Y, no sé por qué, me da por pensar en el estado de la tecnología en el Siglo XXI. Me deprimo. ¿En serio? Nuestra profesión necesita nuevas herramientas. Esto tiene que estar mal organizado. Un war en Tomcat. Un cohete en la luna.

 

 

Inversión y amortización en la selección tecnológica

Dependiendo del día y la hora, actúo como programador, dueño, o CTO en una PYME. A lo largo de estos años, me he encontrado en varias ocasiones ante la situación de tener que seleccionar tecnología para un proyecto, compaginando los diferentes roles y perspectivas.

Poco a poco, he ido desarrollando «una intuición», una personalidad propia sobre la dirección que nos interesa a la hora de valorar las opciones tecnológicas. La selección tecnológica en una PYME es un proceso que va más allá de lo técnico, tiene componentes sociales, y también económicos. Estos últimos son los que quiero explorar con esta nueva serie con unos cuantos amigos. Se habla demasiado de los beneficios intrínsecos y universales a cada tecnología particular y muy poco de todo lo demás, que posiblemente tenga más influencia en el tipo de relaciones que una PYME puede generar con su entorno.

Inversión y amortización, lo nuevo y lo viejo

Durante la ejecución de un proyecto, van emergiendo ideas que permitirían reducir tiempos o abrir nuevas oportunidades de negocio a medida que el aprendizaje se consolida. Algunas de ellas tienen sentido y unos costes que te permiten ponerlas en marcha de inmediato; otras, requieren más tiempo o maduración. Aunque suelo ser muy comunicativo con estos aspectos (la comunicación es el oxígeno de una compañía con responsabilidades distribuidas como la nuestra) no es hasta que toca pensar un proyecto nuevo en que bajo esas ideas a la práctica y me pregunto: ¿qué es lo más efectivo que podemos hacer en este proyecto para mejorar nuestros procesos y productos? ¿hacia dónde se están moviendo las necesidades de nuestro mercado? ¿necesitamos cambiar algo drásticamente? Este proceso de evaluación continua requiere mantenerse actualizado y es muy necesario para que el cambio no te pille desprevenido, para evitar ahogarse si el mercado en que navegas naufraga:

When heavily invested in a technology, you live in a memetic bubble, which also serves as an echo chamber. Bubbles created by vendors are particularly dangerous because you never hear honest appraisals from within the bubble. But the biggest danger of Bubble Living comes when it starts collapsing, which you never notice from the inside until it’s too late.

― Neal Ford, Build your own technology radar.

En ese proceso de re-evaluación, hay ocasiones en que toca apostar por algo nuevo y soy consciente de lo que eso supone: estamos ante una inversión. Decidimos invertir porque la posibilidad de beneficios pesa más que los costes y riesgos. La promesa puede ser que nos ayudará a acceder a nuevos mercados, fortalecerá nuestra posición frente a la competencia o reducirá nuestros tiempos y costes de producción, entre otras (aunque éstas son las más habituales que me encontrado por el momento). No puedo negar que, como humano y programador, mi pasión por aprender cosas nuevas y «hacer las cosas bien» influye también en mis decisiones.

Sin embargo, noto que, con los años, mi impulso por asignarle a lo nuevo características positivas por defecto, es menor: soy más juicioso. Quiero pensar que he aprendido a valorar el esfuerzo que supone aprender algo nuevo hasta el punto de, no sólo ser productivo, sino poder ofrecer una alta calidad en mi trabajo. Por muy necesaria que sea la prospectiva y mantenerse actualizado, nuestra industria peca con asiduidad de confundirla con dejarse llevar de forma baladí por la novedad, aporte o no. En economía existe un concepto llamado amortización, que viene a decirnos que el valor de algo se extiende en el tiempo y, por lo tanto, va contra el beneficio sustituirlo mientras su valor no está agotado (no está amortizado), a no ser que lo nuevo aporte un valor netamente superior.

Hablar en estos términos de la selección tecnológica (inversión VS amortización) nos ayuda a enfocar los problema y buscar soluciones.

¿Es posible encontrar el equilibro entre las fuerzas?

Las decisiones tecnológicas no se toman en el vacío, hay un contexto previo, procesos y personas implicados. Necesitamos aprender a reflexionar sobre tecnología no por las cualidades intrínsecas y universales de la misma, sino por las interacciones entre el conjunto de fuerzas en juego. Necesitamos una microeconomía del software, una herramienta que nos ayude a evaluar el equilibro y nos oriente en la toma de decisiones.

En mi experiencia, el equilibro es frágil y complicado de predecir, pues incluye preguntas de difícil respuesta como: ¿cuándo un framework que hemos usado se puede considerar amortizado? ¿cuánto va a retrasar la entrega/proyecto el uso de esta nueva librería? ¿cuándo voy a percibir los beneficios de su implantación? ¿es sensato introducir Node en un equipo de 4 personas donde 3 de ellas no tienen conocimiento web ni javascript previo y el 80% de los proyectos que vas a realizar en los siguientes 2 años son aplicaciones de escritorio?

Pero aunque sea difícil la tarea, una vez sabes que estas fuerzas existen, son fácilmente reconocibles y pensar en clave de oposición entre ellas aporta un inmenso valor en la toma de decisiones. A partir de ese momento, has pasado de ser programador a convertirte en CTO: piensas la PYME como una unidad de producción y estás teniendo en cuenta no sólo tu proyecto o intereses personales sino la evolución de la empresa. Incluyes en tus análisis que, a las finales, esto va de ser rentable para dar de comer a los que la componen.

En esta encrucijada por encontrar el equilibrio, a lo largo de los años, he ido detectando ciertas variables que modulan la intensidad relativa de la inversión y amortización:

Experiencia del equipo

La historia de por qué Disqus usaba Backbone y Django como opción por defecto refleja el tipo de cosas que tienes que preguntarte. La cuestión clave es saber si, además de ti, hay alguien (en tu equipo directo o a salto de subcontratación) que pueda echarte una mano ahora o pueda recoger tu testigo a medio plazo. Si trabajas en una PYME seguramente vas a necesitarla más pronto que tarde ya que esto es como una comunidad donde, si bien hay distribución del trabajo, hay también mucho de pluriespecialismo y colaborar un poco en todo – bien por tamaño del equipo, bien por apurones.

Capacidad de adaptación del equipo

Relacionado con lo anterior, es esperable que la experiencia y capacidades de tu equipo estén alineadas con lo que vendes y produces. Un cambio supone un impacto, un tiempo de aprendizaje de otras capacidades, moverse hacia otras direcciones. El tiempo que le lleva a alguien llegar al punto de ser productivo ante un cambio es muy variable de persona a persona y tiene mucho que ver con su experiencia previa y su pasión por aprender. Algunas empresas lo pueden solucionar cambiando de equipo a golpe de talonario; las que nos definimos como democráticas y aspiramos a crecer horizontalmente, de manera orgánica, debemos tener en cuenta que el impacto del cambio en nuestros tiempos de producción y calidad del producto final no va a ser despreciable.

Acceso e integración de talento

Hoy en día, en España,  si te sales de Java y sus frameworks (Spring, Struts, Wicket) es probable que te encuentres con que los recién licenciados no conocen de qué estás hablando. En las escuelas de informática se está abusando de la concentración en torno a Java, probablemente por la promesa de oportunidades laborales en las «fábricas de software» (que por otra parte se ahorran tiempo de formación porque los nuevos ya vienen de casa aprendidos). En cuanto a gente con experiencia en una tecnología reciente (pongamos por caso Scala, Node), el coste de acceso a ese talento y el riesgo de que se vaya al poco tiempo puede ser prohibitivo para una PYME. Sin duda hay espacio entre tecnologías ampliamente conocidas y otras todavía minoritarias, la cuestión es saber que la decisión tiene impacto en tu capacidad de contratar talento y valorar en qué parte del espacio te conviene estar.

Mercado: oligopolios y efectos red

En ciertos mercados, las opciones tecnológicas tienden a la concentración. En mi caso -sistemas de información geográfica y web- en el stack tecnológico pesan mucho lenguajes como javascript, python y java, con esos lenguajes puedes hacer casi cualquier cosa: desde un plugin para una aplicación de escritorio a una web con servicios de geolocalización. Si buscas sinergias con otras empresas, necesitas integración con otros proyectos, quieres usar librerías existentes o simplemente reaprovechar conocimiento en este sector, conocer Ruby es menos valioso y te abrirá menos puertas que los 3 anteriores. Un economista puede reconocer fácilmente esta situación como efectos red del ecosistema (número de empresas participando, librerías existentes, disponibilidad de foros de consulta, etc). Los efectos red tienen más impacto en el éxito de una tecnología que su belleza o calidad técnica superior. Es la razón por la que PHP y Javascript ganaron la web a principio de siglo, a costa de Perl que tenía el dominio en los 90.

Nivel de indirección y reaprendizaje de la tecnología

Uno de los mayores costes del desarrollo de software es el re-aprendizaje. Al cambiar de tecnología no sólo se pierde código, sino también conocimiento. Apostar por una solución más cercana a los estándares -o con menos conocimiento específico, llamémosle magia- facilita que pierdas menos cada vez que te cambies, aunque puede ser más costoso al inicio ofrecer lo mismo que con otras soluciones con más magia. Por ejemplo, una tecnología como Backbone te habilita a usar los estándares (al final casi sólo te ofrece una manera de organizar tu código Javascript), sin embargo Angular o React te proponen el aprendizaje de una serie de idioms propios a cambio de la promesa de la rapidez de desarrollo.

Volatilidad y adaptación al cambio de la tecnología

Ligado a lo anterior, se puede decir que una opción tecnológica puede estar más preparada que otra para adaptarse al cambio. Una base de código que, por ejemplo, esté basada en Backbone es potencialmente más flexible a la hora de integrar novedades tecnológicas que otra que siga los idioms de React. Esta última tendrá que esperar a que en React se integren los cambios de los estándares o aparerezcan plugins que lo hagan – dependiendo del tamaño del ecosistema alrededor de React esto puede ser más rápido o más lento. Una situación de volatibilidad hace que el período de amortización de una tecnología pueda ser anormalmente corto, lo que afecta a tu capacidad de generar beneficio si tienes que cambiarla al poco tiempo de empezar a usarla. Pueden existir zonas del código y el proyecto con alta estabilidad (no hay ni se esperan novedades tecnológicas) mientras que otras tienen una alta inestabilidad. Lo importante es detectar dónde te interesa no casarte con nadie porque todo está en ebullición y  dónde es seguro además de recomendable hacerlo porque el período de amortización es estable y la reducción de costes es real, no sólo una promesa.

Amortización esperada de la tecnología

Esto tiene que ver con el cálculo de los beneficios esperados. Influyen cosas como lo que estimes que vas a trabajar con esa tecnología en el futuro (no es lo mismo que, durante los siguientes años, estimes un reparto de trabajo de 90% en productos web y 10% en proyectos móviles que un ratio de 60% para aplicaciones de escritorio y 40% en web). Si lo que esperas es crecer mucho en un área determinada, tendrás más espacio para amortizar la inversión porque tendrás más oportunidades de reutilizar el conocimiento y código que has hecho. El alcance de las inversiones tecnológicas deben ir acordes también con tus expectativas de negocio y evoluciones estratégicas.

Margen de inversión

En una PYME no es muy habitual poder dedicar 3 meses a realizar prototipos un poco complejos con varias tecnologías. Habitualmente los tiempos son muchos más reducidos y necesitas sacar trabajo adelante. Es importante que sepas el tiempo que tienes para equivocarte y salir del apuro cumpliendo con las entregas de un proyecto, porque eso va a ser principalmente tu margen de inversión. Aquí importa no sólo el tiempo de duración del proyecto, sino también la incertidumbre que lo rodea: estabilidad de los requisitos, conocimiento previo del dominio, confianza con el cliente para negociar reducciones de alcance o retrasos, etc. También influirá tu compromiso a la hora de solucionar los marrones donde te has metido. Por ejemplo, parece claro que el margen de inversión que tiene un proyecto de 1 mes con alta incertidumbre en cuanto a requisitos, es mucho menor que otro de 12 meses donde conoces perfectamente el dominio y los riesgos que existen.

En mi experiencia, estas variables modulan la intensidad de la inversión o amortización y, dependiendo de la elección en que te encuentres, unas pesan más que otras. Por ejemplo, a la hora de seleccionar un lenguaje y ecosistema para un nuevo proyecto, el mercado de referencia (y sus efectos red) así como la composición de tu equipo son 2 de las variables que me parecen más importantes. Sin embargo, a la hora de seleccionar una librería concreta, el nivel de indirección y volatilidad del ecosistema suele tener más peso en mis decisiones.

A medida que uno avanza y toma experiencia se van haciendo más claras éstas y otras variables, aparecen nuevas, otras se reinterpretan. Lo importante es reconocer las fuerzas, no dejarse llevar por los análisis universalistas y pensar el impacto de las decisiones desde un contexto determinado: el tuyo.

An outsider overview of #sotm13

sotm_2013

Last weekend I was in Birmingham for the StateOfTheMap, to learn how we could be more involved in OSM in a number of projects we have down the line.

Although I’m a casual mapper and I did know some things about OSM and its core technologies, this was my first in-depth immersion into that world. Note also that during the conference I followed a specific path into the multiple choices we had so, do not expect me to write a complete summary of the conference neither a hands-on guide on “How Mapnick stylesheets were ported to CartoCSS” (enjoyed a lot that talk by the way!). I’ll focus on the community side of the conference.

Other that that, OSM is strugging with growth. For me, there is a subtle line which connects Alyssa Wright’s “Changing the Ratio of OSM communities“, Richard FairHurt’s “You are not the crowd“, the tools built by the Mapbox guys for the next generation of contributors, the world-class documentation the HOT team is creating and the multiple talks on gamification during the conference: they’re all talking about how should OSM growth. Being it the social side of it (how could we engage new contributors?) or the technical one (what tools do we need for people to find easy work with OSM?). That is a challenge, but a challenge that most of the communities I know would like to have.

As an outsider, I got the impression that OSM is like a teenager that still has to define itself in some aspects. And my belief is that it it manages to do it in a smoothly fashion, it will have an even brighter future ahead.

JIDEE 2011

Mañana estaré volando a Barcelona para asistir a las JIDEE 2011. El jueves 10 tendré el honor de presentar IDEPo, el nodo IDE de la Diputación de Pontevedra con datos EIEL, un proyecto financiado por la Diputación de Pontevedra y la Xunta de Galicia. Un proyecto que hemos liderado desde iCarto con la colaboración de Cartolab.

No se me ocurre mejor acompañamiento para un proyecto como éste donde el conocimiento de los datos es crucial. Poca gente en España conoce los datos y procesos EIEL tan bien como ellos, una pequeña muestra es el gran trabajo que han liderado con gvSIG-EIEL. Si queréis saber más de IDEPo o simplemente hablar de iCarto, estaré disponible en el WTC al menos todo el día del jueves.

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:


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

Links to code:

Untitled

I’m not such a fan of comparatives to rank things. But I find them useful to know your pros and cons, or at least to know how the surrounding community perceive your product. While having a coffee today I found this article on gis @ stackexchange: QGIS and gvSIG comparison. Made me happy than 2 out of 6 gvSIG pros are tools where I’m engaged: NavTable and OpenCADTools. Keep rocking cartolab and iCarto!

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 =
    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 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!

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:

NavTable

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

NavTableForms

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