El abismo

Como desarrollador con unos cuantos proyectos a mis espaldas, he llegado a identificar como uno de los problemas más importantes a resolver lo que llamamos "gap" tecnológico del usuario. ¿Qué este gap tecnológico? Pues se trata de la falta de determinados conocimientos tecnológicos (del usuario o cliente), que imposibilitan la comprensión y uso de un sistema.

Esta tierra de nadie, esta zanja en el camino a la solución tecnológica, puede ser de distintos tamaños, yendo desde la simple ignorancia de un pequeño truco o utilidad como puede ser el usar el TeclaControl+F para buscar palabras en un documento, o el TeclaWindows+escribir para encontrar una aplicación en sistemas Windows 7/8, a algo mucho más profundo y peligroso como puede ser la total falta de conocimientos no ya en informática (que al fin y al cabo solo existe masivamente desde hace unos 50 años) sino la más completa ignorancia sobre qué es un automatismo, ordenador o máquina.

Con esto quiero decir que en casos leves es solución suficiente señalar al usuario dónde está un menú, o hacerle una demo de una funcionalidad nueva, pero en demasiadas ocasiones nos encontramos ante la ausencia del marco necesario para entender un carajo.

Este caso sería el del típico empleado que guarda toda su información en su ordenador local, y desconoce lo que es un fallo de hardware, una copia de seguridad, la naturaleza electromagnética de la información de su disco o RAM (volátil), las soluciones gratuitas de backup local y online, el valor de su información, etc…

Este tipo de usuarios puede ser un auténtico problema en entornos informatizados (cualquier oficina de más de 2 personas a día de hoy) por varias razones:

1.      Por un lado su falta de conocimientos hace que use mal las herramientas, en general infrautilizándolas y perdiendo un montón de tiempo al cabo de día por ello.

2.      Por otro lado, todo ese tiempo malgastando es tiempo que alguien tiene que pasar esperando o se transforma en trabajo extra para otros compañeros (por baja productividad o control de daños).

3.      La frustración que produce usar mal las herramientas lleva al usuario a estar descontento con las herramientas y eso genera una carga negativa a día a día que puede sumarse a otras cosas para generar un mal ambiente de trabajo.

4.      La lentitud y complejidad extra añadida al trabajo por un mal uso de la herramienta, suele  pasar factura a la concentración del trabajador, empeorando sus resultados.

5.      La imagen de la tecnología y los cambios, se ve empañada a ojos del usuario por todo lo anterior, generando una animadversión a la tecnología y el cambio. Algo que a la larga puede matar a una empresa o industria al completo.

Por si todo esto no fuera ya bastante malo, resulta que la llamada brecha digital solo se amplía con el tiempo y llega un punto en que se hace tan grande que tratar de superarla uno mismo cuesta mucho más de lo que podemos asumir, en particular en condiciones de estrés y negatividad como las que enumeraba antes. Y en cuanto a confiar en terceros…  reconozcámoslo: la mayoría de los cursos de formación tecnológica tienen mucho de estafa (ofertas de pocas horas concentradas, malos docentes, programas rígidos…) o un desastre por falta de tiempo (RRHH contratando basurilla y presionando para abaratar algo con que llenar el expediente).

Es por todo esto que el gap tecnológico, la brecha no tanto digital como tecnológica, es tan peligrosa: provoca problemas reales, reduce la productividad, aumenta con el tiempo, se contagia a su alrededor y no existe una solución definitiva para ella.

Así que ahora que sabemos qué es y cómo nos afecta, preguntareis “¿cómo arreglamos este gap, este abismo de conocimientos que está cargándose la viabilidad de mi empresa?” La respuesta es, en mi opinión, que no se puede resolver, solo podemos tratar de minimizar el problema. Y para minimizarlo, al margen de reconocerlo en nosotros (sí, todos lo tenemos, no se libra ni Dios) y en los demás, debemos tratar de atacarlo a la mínima oportunidad: si vemos que nuestros compañeros desconocen algo o realizan tareas que debería estar realizando una máquina, debemos acercarnos y ayudar con ello. Se requieren también paciencia, curiosidad y humildad para reconocer nuestra propia ignorancia y ocasional estupidez. Y se requiere una voluntad de equipo para tratarla entre todos en el día a día, a pesar del estrés, los roces y los humos de cada uno de nosotros. Pero sobre todo, creo que se requiere valor y asertividad para cuestionarlo todo (independientemente de la jerarquía) y disentir públicamente.

¿Difícil? Sí. ¿Incómodo y desagradable en muchos casos? Desde luego. Pero la alternativa dada la velocidad de los acontecimientos, es el fracaso a medio y largo plazo. Y si no, que se lo digan a la industria musical (barrida por iTunes y el P2P), la industria del cine (barrida por Megaupload y los torrents) o la industria editorial (barrida por Amazon y los ebooks) entre otras afectadas por no tener un marco de conocimientos adecuado sobre la tecnología y las herramientas.

Lecturas relacionadas MUY recomendables: Philip Zimbardo, Gerd Gigerenzer, Usuarios del siglo XXI, Robert J. Stenberg.

La programación como proceso de diseño (Code as Design)

Hace unos meses que tengo pendiente comentar un poco los ensayos de Jack W. Reeves: Code as Design.

Se trata de unos textos realmente valiosos dada su relevancia a lo largo de dos décadas (el primero fue publicado inicialmente en 1992) y por la peculiaridad de que la idea fue revisada 13 años después. Pero además es decepcionante ver como aun hay muchos profesionales del sector que no tienen claro lo que comentaba Reeves ni nada remotamente parecido.

La idea central que plantea Reeves es simple en su formulación: el desarrollo de software es un proceso de diseño. Pero esa simpleza oculta multitud de ideas interesantes y de prejuicios dentro y fuera del sector que llevan a considerar al programador como un obrero más. Y así nos va.

Esa idea nos lleva a plantear la obligatoriedad de que los cambios de requisitos deberían ser caros. Y que los desarrolladores ni son albañiles, ni son intercambiables como les gusta pensar a las grandes consultoras. O que el presupuesto cerrado a la hora de entregar un software es una estupidez de base. Pero como es un ensayo corto y discutido a lo largo de 20 años, creo que será mejor que cada uno lo lea (es corto) y juzgue por sí mismo.

A continuación para tratar de animar a los mas perezosos a leerse los ensayos, pongo algunas citas interesantes:

The Unpredictability of Requirements
There's a refrain I've heard on every problem project I've run into. The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it. 

One route is to treat changing requirements as the result of poor requirements engineering. The idea behind requirements engineering is to get a fully understood picture of the requirements before you begin building the software, get a customer sign-off to these requirements, and then set up procedures that limit requirements changes after the sign-off. 

One problem with this is that just trying to understand the options for requirements is tough. It's even tougher because the development organization usually doesn't provide cost information on the requirements. You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can't tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof? 

Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify. 

Software's intangible nature also cuts in. It's very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not. 

This leads to the ironic point that people expect that requirements should be changeable. After all software is supposed to be soft. So not just are requirements changeable, they ought to be changeable. It takes a lot of energy to get customers of software to fix requirements. It's even worse if they've ever dabbled in software development themselves, because then they "know" that software is easy to change. 

But even if you could settle all that and really could get an accurate and stable set of requirements you're probably still doomed. In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading. 

Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.

En serio. Si no lo has leído, léelo ya.

Interrupciones y ruido en el desarrollo de software

Al hilo del resumen que encontré sobre Peopleware, y dándole vueltas a como mejorar mi flujo mental, me he puesto a pensar en que a lo largo de mi carrera, he tenido la interesante desgracia de encontrarme trabajando en diversos entornos ruidosos y con una gran cantidad de interrupciones. De todos ellos, creo que ha habido tres que han sido especialmente representativos en cuanto a lo que suponen para el desarrollo de software, tanto el ruido como las interrupciones.
De estos tres casos, una vez enfriados a base de tiempo para un análisis mínimamente objetivo, puedo decir que tenían, en mi opinión, las siguientes características:

1. El primer caso lo experimenté trabajando en un entorno con más ruido de conversaciones y teléfonos del deseable, pero relativamente amortiguado con algunos metros de distancia. Muy pocas interrupciones, y muy informales.
2. En segundo caso, el entorno era muy ruidoso, con montones de conversaciones al lado, y varias decenas de interrupciones diarias tanto in situ como de correo. Un caso bastante extremo, la verdad.
3. En el tercer caso, el entorno no era más ruidoso que cualquier otro en el que haya estado, pero había muchísimas interrupciones in situ. Telefónicas y de correo sin embargo, había muy rara vez.

En todas las ocasiones, tuve que realizar trabajo de análisis, diseño e implementación de las aplicaciones que tocaban en cada momento y en todos los casos hice un análisis de mi estancia, inmediatamente tras cambiar de empleo, como de costumbre, para tratar de aprender de errores propios y ajenos (una pseudo tarea de cierre y evaluación del proyecto que casi nadie lleva a cabo por lo que veo). Así que este artículo se centra exclusivamente en la relación entre ruido, interrupciones y desarrollo de aplicaciones.
Y una vez comentado el contexto creo que puedo pasar a exponer las siguientes opiniones que me he formado a base de estas y otras experiencias:

1. El trabajo de análisis y diseño admite mejor el ruido que la implementación. En mi caso puedo, por ejemplo, realizar documentación o establecer la arquitectura de una solución, con un nivel medio de ruido. Sin embargo para programar necesito muy poco ruido y/o cascos (como manera de aislarme), o la tarea se ve muy mermada en eficacia.

1. El análisis y diseño admiten interrupciones en ventanas de tiempo [x] relativamente pequeñas, quizá de media hora. Estas interrupciones merman estas tareas, pero no hasta un punto excesivo que eche por tierra horas de trabajo. En cambio la programación (la que se haga bien, no parchear algún desastre) muchas veces requiere de un par de horas como poco sin prestar atención a nada más o puedes irte directamente al bar y la productividad habrá sido similar pero con algo más de alegría.

Supongo que otras personas habrán tenido experiencias similares o diferentes, pero estas son las que tengo de primera mano, así que tengo pocas razones para discutirlas. Por otro lado, el por qué el ruido y las interrupciones afectan de determinada manera a mi trabajo, merecen al menos un intento de explicación. Y aquí es donde van mis dos céntimos.

Creo que la razón de esta diferencia entre las necesidades de concentración de una y otra tarea, se debe a que las tareas de análisis y diseño, son tareas de alto nivel, abstracciones (por definición incompletas), a menudo incorrectas y/o, ambiguas (un poco al hilo de las leaky abstractions de Joel Spolsky), tareas además más “naturales” en el sentido de que no requieren de un marcado ciclo de trabajo tan formal (ojo, no digo que no sea formal pero hay un trecho) y dependiente de la tecnología (IDE/compilador, base de datos, flujos de trabajo con sistemas de control de versiones…) como la implementación en código y bases de datos. Por tanto las tareas de diseño y análisis son más flexibles para con los ciclos de abandono y retomado propio de las interrupciones. Yo diría (en un sentido positivo aunque no lo parezca) que el análisis y el diseño de los sistemas informáticos, especialmente en cuanto a software, son tareas incompletas y erróneas por definición, y como otros trabajos de diseño, se sustentan muy bien sobre el papel.
Sin embargo, en la implementación, cuando el programador recoge las especificaciones y diseños del analista (uno mismo en caso de que el analista y el programador sean la misma persona), y se pone a codificar, se acaba encontrando con todas las omisiones, ambigüedades y errores que han pasado por el tamiz de los diferentes roles y hasta sus manos: desde el cliente, pasando por la toma de requisitos, análisis funcional y orgánico y cualquier otra fase que queramos meter en medio. Y es entonces cuando todo ese trabajo que no se ha realizado antes, todo lo que se ha olvidado, omitido conscientemente, tergiversado… cualquier decisión que no se ha tomado, se atasca en la implementación, que necesita convertir toda la documentación, en un producto funcional y mantenible en el tiempo, y debe hacerse sin errores, porque la implementación no perdona, y si no “cae” en el compilador, lo hará en tiempo de ejcución en el entorno de preproducción, o peor aún, en producción.

Parafraseando a Richard Feynman: "Para lograr un éxito tecnológico, la realidad debe estar por encima de las relaciones públicas, de los diseños, análisis y requisitos tomados, porque la problemática que resuelve el sistema, los usuarios que lo van a usar, el compilador, la base de datos y el entorno de producción no pueden ser engañados.".


La necesidad de hacer algo sólido, sin errores, ni omisiones, desde lo que es la documentación incompleta (como decíamos, por definición), obliga al desarrollador a mantener un modelo mental del sistema muy detallado, mucho más que en las etapas anteriores, y esto cuesta mucho más “cerebro” (atención, modelos mentales detallados, datos, simulaciones, peculiaridades del entorno…) que en el caso del análisis (que puede abstraerse del entorno como poco). Supongo que por eso cualquier cosa que robe “cerebro” o lo ralentice, como las interrupciones o el ruido, son tan perjudiciales en esta etapa de implementación. Y quizá por eso también los técnicos tienden (tendemos) a dejar de ver el bosque en muchas ocasiones, de tanto árbol que tiene, con las consiguientes quejas (con razón o sin ella) de usuarios y comerciales.

Y ojo, esto no es una crítica al indispensable trabajo de análisis y diseño (que me parece crítico para poder llevar a cabo el proyecto con éxito), ya que en mi caso hablo de mi propia experiencia en los diversos roles, sino una reflexión sobre la posible necesidad de mantener a los programadores en entornos más tranquilos y relajados que los de los analistas. Es una invitación a incentivar el uso de cascos (quizá proporcionándoles unos con reducción activa de ruido), quizá ropa cómoda, pero sobretodo a dejarlos en paz durante periodos largos del día, aislándolos de interrupciones y distracciones indeseadas. Y también es una invitación a establecer relaciones estrechas y de confianza (laboralmente al menos), entre los miembros de análisis y desarrollo, ya que su productividad como equipo debería mejorar con un lenguaje común, conocimiento de los talentos y limitaciones de cada uno, buenas costumbres y manías. Al fin y al cabo no son dos recursos intercambiables como les gusta pensar a demasiados responsables de proyectos y departamentos de RRHH, sino dos tipos de diseñadores creativos (o deberían serlo) que van a realizar una obra común de carácter muy técnico. Son dos creadores (ahora que está de moda la palabra con la Ley Sinde) que van a colaborar (en el sentido de Pixar), y es por ello que más vale que se entiendan bien y sepan donde ceder ambos el lápiz y el papel o la decisión para obtener algo coherente, porque de no ser así, el resultado puede ser catastrófico.

Vídeo relacionado: Jason Fried 2010 en TED o Youtube.

Foto de Wiki Commons.

NOTA: Este artículo empecé a escribirlo hace 10 meses, pero diversas circunstancias lo han mantenido en un cajón durante largo tiempo.

La informática es...

"La informática es la ciencia de como crear programas, no como crear ordenadores, y como los programas sirven para resolver los problemas de la gente, un informático debe principalmente entender a la gente"

Edsger Wybe Dijkstra

Privacidad, sueldos y pecados

El otro día estuve hojeando el Investigación y Ciencia de noviembre dedicado a la seguridad y la privacidad. En general no dice nada realmente nuevo sobre lo que cualquier interesado o paranoico sepa a día de hoy si se mantiene informado, sin embargo si hace un muy buen repaso al estado actual de la privacidad y señala los frentes que hay abiertos y objetivos interesantes a corto y medio plazo como son las redes sociales tipo Facebook.

Lo que realmente me llamó la atención en uno de los artículos fue un algoritmo sencillo (de los de papel y lápiz) para compartir información común sin desvelar información propia. A pesar de que juraría haber visto algo sobre el tema en libros de criptografía y seguridad en el pasado, no fue hasta ese artículo que se me ocurrió una aplicación práctica en mi entorno para este tipo de técnicas matemáticas: conocer el sueldo medio de un grupo sin que nadie tenga que revelar el propio.

La razón de este interés es que a lo largo de mi carrera como profesional he visto en varias ocasiones como el compartir la información de sueldos concretos despertaba en algunas personas envidia y codicia que a pesar de ser pocas, acababan afectando el funcionamiento del grupo de manera bastante ruin cuando descubrían que alguna persona cobraba por encima de alguien en particular. El problema a mi entender era que en algunos casos, las grandes diferencias de sueldo entre el mayor y el menor sueldo generaban pura y llana codicia sacando lo peor de algunas personas, por lo que mi posición hasta ahora al respecto, por el bien de las relaciones en el grupo, era negar información sobre mi sueldo de la manera más amable posible (aunque mi sueldo suele estar en la media por lo que veo en Infojobs y me salto la regla si conozco bien a la persona como para pensar que no va a afectarle [hola chicos :-)]) a la vez que he procurado no preguntar sobre sueldos particulares a nadie de mi entorno directo sin antes de conocerle lo suficiente (sin embargo si he preguntado un par de veces sobre sueldos medios a compañeros de otras empresas).
En fin, que en un par de ocasiones, a la hora de pedir una revisión salarial me he encontrado con la necesidad de conocer los sueldos medios de mi entorno inmediato, pero sin poder preguntar directamente sobre sueldos en mi grupo de trabajo. Y ahí es donde el algoritmo me ha encendido la bombillita al mostrar una manera de compartir en el grupo la cifra de sueldo medio sin que nadie tenga que decir lo que cobra.

Sobre el algoritmo, la revista dice lo siguiente aplicado a un problema de “conocer el peso medio de 3 personas”.

Cálculos en compañía

La evaluación segura de funciones permite que un grupo de personas calcule cualquier cosa a partir de datos privados de cada uno, sin que nadie revele sus propios datos en el proceso.

Alicia, Juan y Marta quieren calcular su peso total, sin que ninguno revele su propio peso.

Cada persona elige tres números, o "porciones", entre 0 y 1000. Dos porciones se eligen al azar y la tercera hace que el total sea igual al peso de la persona módulo 1000. Por ejemplo, Alicia, para su peso de 54 kilogramos, emplea 300, 550 y 204, que totalizan 1054.

Luego, cada uno entrega dos de sus porciones a los otros por separado.

Seguidamente, cada uno suma la porción que se quedó y las dos recibidas de los otros participantes, otra vez módulo 1000.

Y comunica el resultado a los otros dos.

Cada uno suma los tres números y así obtiene el peso total (módulo 1000), sin que ninguno pueda averiguar el peso de los otros.

Un método más complicado permite a un grupo multiplicar números privados. Sumando y multiplicando bits, podría calcular todo lo que pueda evaluar un ordenador a partir de sus datos privados. El sistema completo protege también contra quienes se apartan de las reglas.

Tras realizar en papel (que poco tecnológico me estoy volviendo) la comprobación de que el algoritmo expuesto funciona también con 4 “jugadores” intentaré probarlo en mi último grupo de trabajo a ver que tal respuesta hay, pero estoy seguro de que este algoritmo le puede ser útil a muchas otras personas. Lo único que me gustaría aclarar es que a mayor número de implicados, más pesado se vuelve el intercambio de porciones, al tener que usar tantas porciones como personas implicadas, pero con números pequeños (5-8) debería ser muy manejable.

Se puede acceder a un interfaz básico que he programado en ASP.NET con VB.NET para realizar los cálculos de porciones individuales para un número de entre 3 y 99 jugadores en mi sitio web Aneode pero como ya he dicho antes, el cálculo se puede hacer a mano. En cualquier caso, recordemos que cada jugador, solo debe conocer una de nuestras porciones, nunca varias, y una de nuestras porciones queda en secreto para el resto de jugadores. Ah y si alguien no sabe de que va lo de módulo 1000, no es más que restar mil a cualquier número que haya resultado superior a mil (1236 pasaría a ser 236). Después solo quedaría realizar la suma final de los totales individuales y dividir entre el número de jugadores para obtener el sueldo medio del grupo.

De todos modos aunque este método debería eliminar envidias y suspicacias, no va a detener a alguien codicioso que vea que está demasiado cerca del salario medio aunque sea por encima y tampoco va a eliminar a alguien envidioso con algún toque de paranoia que podría acabar mirando a todo el mundo como posible sospechosos, pero aun así debería ser de utilidad al mantener en secreto las cifras individuales. Adicionalmente se me ha ocurrido que el sistema podría fallar parcialmente (por el lado humano claro) si se realizan ciertas cosas como por ejemplo:
Si en un grupo de 3 personas dos comparten su cifra salarial, el tercero queda al descubierto al poder usarse el dato medio, más las dos cifras de los chivatos. Esto debería ser también así para grupos más grandes con un mayor número de chivatos.
Si un grupo de N personas realiza el cálculo y más adelante llega un nuevo jugador con el que se repiten los cálculos, se puede obtener la cifra del nuevo jugador de manera muy simple. Es decir que si un equipo de 10 jugadores hace el cálculo y se repite el cálculo con 11, los 10 jugadores iniciales, pueden calcular la cifra individual del nuevo jugador.
De lo anterior supongo que puede deducirse que si dentro de un grupo, con el cálculo realizado, un subgrupo empieza a recalcular las cifras dejando al margen un jugador cada vez, podrá ir obteniendo cifras individuales tranquilamente.
Así que debo aconsejar que si alguien quiere usar el algoritmo, debiera hacerlo solo en grupos de más de 3 personas, y advertir a nuevos jugadores del sueldo medio inicial y el problema de seguridad que supone el recalcular cifras, ya que es fácil dar al traste con la privacidad si no cuidamos esos detalles.

Y en principio no veo más problemas asociados a esta versión del algoritmo. Habrá que ver si la versión completa que menciona el artículo contiene mejoras que permitan privacidad extra incluso en caso de “traición”, pero eso sería motivo de otro post…

Así que eso es todo. Si alguien se anima a usarlo, quiere señalar debilidades adicionales, errores míos o aplicaciones prácticas alternativas, queda invitado a comentar al respecto.

Nota: La imágen ha sido obtenida de Yerusha.

ASP Vs ASP.NET

Por alguna razón, al volver de vacaciones me he encontrado con una nueva aplicación (pequeña) escrita en ASP clásico de la que he tenido que hacerme cargo. Después del susto, de entender lo que quiere el cliente, y en ausencia del responsable de la toma de la decisión, decidí que no había razón alguna para mantener la aplicación como ASP clásico, así que la he migrado a ASP.NET, pero como medida de precaución me he tomado la molestia de escribir una serie de razones por las que no se debería volver a tomar una decisión semejante y por si acaso se piden explicaciones a mi propia decisión.

Además por si alguien lo necesita en algún momento o por si vuelvo a necesitarlo yo, voy a copiarlo aquí mismo:

¿Por qué se debería preferir tecnología .NET frente a ASP clásico?

1. ASP clásico es una tecnología obsoleta, por lo tanto mañana mismo podría dejar de funcionar por un parche (correcto o por error) de Microsoft en cualquier sistema de desarrollo o producción.
2. .NET 1.x mejoró la tecnología de programación con controles de usuario más flexibles y potentes que permitían desarrollos más rápidos al tener que escribir mucho menos código de presentación y funcionamiento para realizar las aplicaciones.
3. .NET 2.x mejoró la tecnología de controles de usuario algo más como por ejemplo los menús de usuario, así como el tratamiento de XML entre otros datos.
4. El equipo de trabajo, como la mayoría de equipos actuales tiene mucha más experiencia (y más cercana) en desarrollo con ASP.NET por lo que la fiabilidad de las estimaciones de tiempo y viabilidad de peticiones solo puede asegurarse realizando el desarrollo con .NET.
5. Los esfuerzos de la comunidad de desarrolladores y de Microsoft para con .NET han sido mucho mayores (por importancia, y en recursos y tiempo) lo que ha producido más documentación para el uso de la tecnología y la resolución de problemas de integración o desarrollo con .NET.
6. El entorno de Visual Studio permite la depuración para proyectos .NET pero no para los ASP clásicos, por lo que la búsqueda y corrección de errores de ejecución será siempre más rápida bajo la plataforma .NET.

Notas a tener en cuenta:

• AJAX.NET no es parte del framework .NET sino un framework que la comunidad de desarrolladores ha escrito usando .NET para facilitar el uso de tecnologías AJAX sobre .NET, es decir, que se puede tomar AJAX.NET como un “pro” si es necesario usarlo, pero nunca como un contra al no formar parte de la tecnología.
• ASP.NET permite programar con estilo spaghetti como en ASP clásico, pero está orientado a hacer fácil una programación orientada a objetos con separación entre capas, así que la manera de programar no debería tenerse en cuenta a la hora de elegir tecnología a no ser que se quiera programar orientado a objetos, en cuyo caso debería considerarse .NET como la opción indicada.
• ASP clásico salió en noviembre de 2000, ASP.NET en Enero de 2002.

Como nota curiosa, me he encontrado en Geeks, en el blog de Gustavo Velez, un divertido artículo sobre sabotaje y desarrollo informático, en cuyo manual viene la siguiente frase, completamente al hilo de este post de ASP clásico en aplicaciones modernas:

"Think out ways to in crease the number of movements
necessary on your job: use a light hammer instead of a heavy one"

Representación de datos GPS en mapas web

Bueno, al fin, con un poco de maña y algunos mini-programas escritos a medida en .NET, he podido generar un fichero único y con el una representación sobre un mapa web de la ruta que seguimos en el viaje por Islandia.

Para acceder tan solo es necesario pinchar en uno de los dos enlaces siguientes:
Islandia 2008 (Microsoft Live Search Maps), Islandia 2008 (Google Maps)


De todo el proceso me gustaría comentar tres cosas, por si alguien está interesado en hacer algo parecido:

1. Para enlazar un mapa de Google Maps generado con tus datos, tienes que realizar dos pasos ("buscar" el archivo y generar la URL), mientras que con Microsoft Local Live tan solo tienes que pasar un parametro (la ruta al archivo) por URL.
2. El tratamiento de archivos KML/KMZ es tedioso. Yo, como programador, no he tenido problemas en procesar a base de .NET los 50 archivos diferentes (unos 2 megas de datos XML) para generarme uno usable por Google y Microsoft, pero cualquier persona que no sepa programar tendrá que buscarse la vida para montar el mapa web (manipulación usando Google Earth por ejemplo pero no voy a extenderme con eso).
   
3. Al usar Google Maps, he notado que representaba mal los datos en un momento determinado, pero debía ser un bug, porque no se ha repetido (mismo archivo, distinta instancia de navegador).

Así que finalmente, mis consejos a los interesados en repetir la experiencia de plasmar la ruta de las vacaciones, es que se hagan con el Google Earth, procuren limitar el número de ficheros con datos y tengan paciencia (o llamen a un amigo programador ;-) a la hora de montar el tinglado web. Eso si, los ficheros offline con información GPS unido a la información de fecha y hora de la cámara siguen siendo de mucha utilidad a la hora de identificar donde se tomo una foto en particular, algo realmente útil cuando viajas rápido por un país desconocido y de nombres impronunciables como es Islandia.

Actualización: En Barrapunto se ha abierto un interesante debate con más información sobre GPS y tratamiento de datos.

Cafeinaaa!!

Red Bull te da alas y evita que rompas el monitor del ordenador con la cabeza cuando tienes mucho sueño.

¡¡Que aburrido es documentar una aplicación que no ha hecho uno mismo!!

PD: Post basado en un Twitteo mio de hace un rato...