¿Funciona el soporte de la comunidad?

Bueno, pues según mi experiencia si, y muy bien además. Ayer estuve probando la última versión de uDIG, con la que estamos empezando a trabajar para incoroporarlo como cliente de escritorio en algunos proyectos. Quise conectarme a un repositorio de ArcSDE, pero no funcionaba. Así que puse un mensaje a la lista de desarrolladores. ¿Cómo acabó todo?. Pues que efectivamente se descubrió un "bug" en el proceso de generación del plugin necesario, que se identificó y que se corregirá en la siguiente versión disponible. Pero además, el desarrollador encargado de esta tarea envió a toda la lista de correo el plugin corregido, que efectivamente funciona sin ningún problema. Hasta aquí, todo bastante normal, pero lo que no he dicho es CUANTO TIEMPO transcurrió en todo el proceso. En España eran las 7 de la tarde más o menos, con lo que en Norteamérica ya están levantados y al tajo. Vamos, resumiendo, que tenía en mi poder la solución en CINCUENTA MINUTOS.

Con Geoserver he tenido experiencias similares, incluso me han llegado a enviar un WAR a mi correo que solucionaba algún problemilla que tuve, y que me compilaron especialmente a mi (y que suelen hacer a todo aquel que lo necesite, siempre que esté justificado claro).

Y ahora una reflexión. Evidentemente, este tipo de soporte no es posible encontrarlo en casi ningún fabricante de software SIG en la actualidad. Aunque parezca una afirmación un poco fuerte, la reflexión viene más bien por otro lado. Creo que todo el mundo ve las ventajas que tiene un proceso abierto, en el que se tiene acceso directo a los creadores de la herramienta, a las mejoras en las que están trabajando en este preciso instante, y a la corrección de errores que pueden estar afectando nuestro trabajo diario.

Evidentemente, la respuesta de los fabricantes puede seguir siendo crear call centers con becarios poco formados (nada contra ellos, muchos han empezado así) y poco preparados para dar respuestas de calidad, con unos sueldos ínfimos que les invitan a volar en cuanto se han formado y tienen una oportunidad mejor, lo que obliga a reconstruir y volver a formar al equipo de trabajo. Pero está demostrado que el usuario exigente de hoy en día (cada vez hay más) no acepta esto. La prueba está en que la mayoría de las veces funciona mejor lo que uno encuentra en los foros. Aquí, también es la comunidad de usuarios la que aporta y soluciona problemas.

Esto, que puede parecer un ahorro de costes estupendo, puede ser una trampa en mi opinión. En un modelo de negocio que evoluciona hacia los servicios más que a la venta de licencias (y esto no hay quien lo pare ya), más vale que el soporte sea bueno. Siempre podemos pensar si es mejor atender volumen con poca calidad o atender adecuadamente cada nicho de mercado, el equilibrio evidentemente es difícil, pero cuando el software falla el estropicio se nota mucho, esto en Sistemas de Información Geográfica dedicados a la gestión o publicación de información es especialmente relevante y visible.

Además, hay que tener en cuenta otra cosa. Hay toda una generación que se está incorporando ahora al mercado de trabajo, y que tiene como característica principal el dominio de este entorno colaborativo y participativo, lo han incorporado como forma natural de interacción en todos los ámbitos, y no van a entender las viejas formas de interacción con un departamento de soporte técnico ("estimado cliente, se ha recibido su incidencia blah, blah,blah....."). Cuando esta generación lleve la batuta de los negocios, muchas cosas cambiarán, de hecho ya lo están haciendo, o al menos deberían estar cambiando si el software en cuestión y los servicios asociados pretenden mantener su cuota de competitividad.

Y esto es válido para software gratuito, de pago, con código abierto o cerrado.

Bueno al menos es así como yo lo veo.

ArcGIS Server code challenge

Ya se han fallado los premios para el ArcGIS Server Code Challenge, que ha tenido lugar en la Conferencia de Desarrolladores de ESRI (ESRI Developer Summit).

Se pueden ver los scripts / programas que han sido enviados, así como los ganadores, en la siguiente URL:

http://esricodechallenge.wordpress.com/

Viendo lo que ha enviado la gente, me asalta una duda.

¿Nadie desarrolla en Java por allí?. Sabía que .NET era mayoritario, pero no me imaginaba que no iba a encontrar ninguna entrada desarrollada en la plataforma de desarrollo empresarial más extendida.

Desde luego, desarrollar con ArcGIS Server en Java es una aventura no apta para cobardes. Por fin está empezando a aparecer documentación en la web, después de llevar el producto varios meses en el mercado. Y ahora resulta que se hace todo con AJAX, como no podía ser de otra forma, está bastante bien a nivel técnico, la verdad.

Aún así, faltan por pulir muchos aspectos, hay zonas de la API que no están documentadas, por ejemplo el tema del manejo de Geodatos, imposible encontrar un ejemplito en Java (si en .NET), y hasta que han empezado a aparecer los ejemplos en la web (http://edn.esri.com/index.cfm?fa=java.gateway), es difícil imaginarse que alguien "adivine" todo el tinglado de los PhaseListener de JSF y su integración con AJAX así como por arte de magia. Escribiré otro post sobre este tipo de desarrollos más adelante, pues tienen su miga.

En el caso de ArcGIS Server, y en igualdad de circunstancias, es mejor optar por .NET pues es un producto mucho más acabado y completo a todos los niveles, y se nota que ESRI va de la mano de Microsoft.

Sin entran a valorar esto, pues daría para un largo y encendido post, lo que tengo claro es que cada día me gusta menos la arquitectura de bajo nivel de este producto precisamente por este motivo, demasiado objeto COM por ahí debajo haciendo la puñeta. Llamar a estos señores desde Java se hace a través de una librería intermedia que actúa como pasarela o "bridge", y aunque ha mejorado mucho en la versión 9.2, nos sigue obsequiando con unas magníficas excepciones nativas (AutomationException) que me recuerdan a los mejores tiempos del "Segmentation Violation" de ArcView 3.x.

La recomendación que he escuchado alguna vez, "pues hazlo en .NET", desgraciadamente no me sirve. En España y gran parte de Europa se utiliza la plataforma JEE de forma exclusiva, y por unos buenos motivos, en mi opinión. Que te cambias a .NET y descubres que funciona fenomenal, pero que te tienes que apoyar en un servidor Windows con IIS, si o si.

Bufff.