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.

Televisión a la carta. Mini how-to, (pseudo hacking)

La semana pasada estuve viendo en La 2 de RTVE, un reportaje de A pedir de boca, que me gustó mucho sobre las frutas de Canarias. El caso es que me quedé con ganas de que lo viera mi mujer, que es una gran consumidora de fruta, y me puse a ver si era posible ver el reportaje en la web de RTVE, A la carta, donde se supone que están disponibles los programas emitidos por las cadenas del ente, para poder verlos on-line. Y así es, allí colgado estaba el capítulo que me interesaba, pero a la hora de verlo on-line, aquello no se descargaba ni pa dios. Por alguna extraña razón, el reproductor embebido en la web iba tan lento que se podían ver 30 segundos de programa cada 5 minutos (¿WTF?).

Descartados los problemas de sistema operativo, navegador, potencia, red de la casa y caché de streaming puntual, me puse a bucear para encontrar alguna manera de descargar video de esa web. Como parece que no soy el único que tiene problemas con RTVE, encontré rápidamente algunos tutoriales, sin actualizar, claro, pero fáciles de interpretar para realizar la tarea. El video se descargó en formato FLV, reproducible con VLC, y lo hizo realmente rápido, por lo que parece que el problema tampoco es de los servidores de RTVE, sino de algo del front-end que han montado para hacerlo amigable y que convierte el portal en inusable. Una lástima, ya que al fin y al cabo he pagado la web y sus contenidos, a base de mis impuestos. Aunque ahora entiendo que sacasen una oferta para montar un portal web de contenidos (que estuvimos valorando en mi oficina): saben que el suyo no funciona.

En cualquier caso, voy a describir los pasos a seguir para descargar contenidos de RTVE A la carta, por si en algún momento vuelvo a necesitar descargar un video de esa web, tener el método a mano.

Es el siguiente:

• Abrir el video que queramos en http://www.rtve.es/alacarta

• La URL que nos sale será algo tipo:
  http://www.rtve.es/alacarta/la2/abecedario/index.html#681524
  El numerito final, el 681524, es el ID del vídeo, y lo apuntamos.
  
  
• Ponemos ese ID como nombre del archivo XML en la URL:
  http://www.rtve.es/alacarta/player/681524.xml
  
  
• Al abrirlo con el explorador, se nos muestra un archivo XML tipo:

<playlist version="1">
<trackList>
<track>
<title>A pedir de boca</title>
<creator>... ALACARTA ...</creator>
<cdn>akamai </cdn>
<location>
rtmp://stream.rtve.es/stream/resources/alacarta/flv/4/1/1264939929914.flv
</location>
<image>/resources/jpg/6/0/1264939924406.jpg</image>
<info>... INFO ...</info>
</track>
</trackList>
</playlist>

• De la URL rtmp://stream.rtve.es/stream/resources/alacarta/flv/4/1/1264939929914.flv
  cojemos la parte "resources/alacarta/flv/4/1/1264939929914.flv"

• Y lo añadimos a la URL: http://www.rtve.es/
  quedando:http://www.rtve.es/resources/alacarta/flv/4/1/1264939929914.flv

Ahora podemos abrir esa dirección y se nos descargará directamente el archivo de vídeo.
Sazonar con un VLC y a disfrutar de la tele que has pagado con tus impuestos y cuya implementación deficiente a base de concursos amañados te ha dejado sin ver.

Película: Startup.com

Título: Startup.com
Año: 2001
Tipo: Documental
Idioma: Inglés (EEUU) subtitulado al español.

Curiosa película. Narra en forma de documental, la creación de una empresa de Internet en los Estados Unidos antes de la crisis de las puntocom en el 2000 y su caída tras esta.

En los créditos finales (posible spoiler, pero es un documental, así que…) dan alguna información que supongo que dará una mejor idea del “argumento”, cito una parte a modo de epitafio de la empresa:

govWorks
Mayo 1999 – Diciembre 2000

Reunió fondos por valor de 60 millones de dólares.
45 ciudades internacionales contrataron sus servicios.

Ganaron el contrato de las multas de aparcamiento de Nueva York

En resumen se trata de un buen relato de la historia de una puntocom típica, con dos socios fundadores, Kaleil y Tom y se parece en muchos puntos (socios, desarrollo, problemas…), a una empresa en la que trabajé hace unos años y que siempre recordaré con cariño como la empresa en la que más aprendí sobre el trabajo, la tecnología, y el estrés, por qué no decirlo.
Esta película bien podría ser de visionado obligatorio para cualquier interesado en montar una empresa de software o trabajar en una joven startup de terceros, ya que se aprende mucho más de los errores que de los aciertos, pero si los errores son ajenos, mejor.

PD: Para saber más sobre errores en proyectos de software y empresas, recomiendo totalmente leer el artículo de Coding Horror: The only truly failed project.

Los nombres son importantes

“Los nombres son importantes” decía Publio Cornelio Escipión, general romano con imperium en Hispania durante la Segunda Guerra Púnica iniciada por Aníbal Barca, según narraba Santiago Posteguillo en Las Legiones Malditas.
También los egipcios en la antigüedad creían en el poder de los nombres. Pensaban que conocer el poder de una cosa te da poder sobre ella y por tanto es un tema recurrente en la mitología egipcia (el nombre secreto de Ra) o visible en su propia escritura como descubrió Champollion al deducir que rodeaban acotando con líneas los nombres propios en sus jeroglíficos. Y como no podría ser de otra manera teniendo en cuenta el pasado común, los hebreos recurren a la religión y el mito (el Golem y el nombre de Yahvé escrito en su frente) para evidenciar la importancia del nombre.

“Los nombres son importantes”, decía un jefe que tuve en cierta empresa. Y por ello trataba de seleccionar con cuidado el nombre de las partes que componían una aplicación y de la aplicación (codename que dicen en Microsoft) en si misma. Algo poco ortodoxo, pero curioso y útil.

“Hay que ponerle un buen nombre” decimos ahora cuando creamos un detergente con Megaperls o una crema con Hidroactive, pero al final todo se basa en lo mismo:

El nombre que damos a algo, condiciona nuestra percepción de ese algo.

“Programador” y “programación” recuerdan demasiado a la columna de programas de televisión de una cadena local, como para que se tome en serio el trabajo que realiza un informático escribiendo código, y la propia palabra “informático” está completamente desprestigiada debido a su abuso para todo (“fallo informático”, redes informáticas, aplicaciones informáticas, sistemas informáticos de vuelo, informática doméstica, juegos informáticos…).
“Analista” suena mejor, ya que probablemente lo relacionamos con el análisis financiero, el dinero, Wall Street y demás cosas “grandes” y “serias”.
Supongo que de ahí mi preferencia (como consultor, analista y programador) de llamar al analista y programador informático, “desarrollador”, que indica algo más interesante que programar y sugiere que las aplicaciones no se piensan, escriben, prueban e implementan solas de la noche a la mañana y que requieren de cierto rodaje. Aunque me sigue pareciendo una palabra insuficiente.
También parece que este tema de la importancia de los nombres tiene mucho que ver con la aparición de términos cuanto menos curiosos en el mundo del software, tales como "arquitecto de software", "CEO de start up", o similares, aunque en mi opinión se debe más al marketing y las ganas de darse aires que a un intento de comunicación real con el cliente.
En cualquier caso los nombres son importantes y no es lo mismo echar horas y ganas a una actividad con un buen nombre que a una actividad que suena a viejo y aburrido.

PD: Supongo que Shakespeare no estaría de acuerdo con esta entrada, pero el no vivía en la Era de las Comunicaciones.

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.

Pegasus vuelve al servicio

La semana pasada, Pegasus, mi servidor doméstico, dejó de iniciarse. Todo apuntaba a fallo de disco duro, y efectivamente la partición de arranque estaba más corrupta (por causas físicas o lógicas, aun no he intentado determinarlo) que el gobierno de Camerún.

Pegasus había cumplido diariamente y durante años fielmente como servidor de archivos, impresión, escaneo centralizado, servidor web, servidor de FTP y emule centralizado. Todo ello bajo un sistema operativo Windows 2000 completamente parcheado, pero el tiempo no perdona, y la única opción viable (dado que no tenía tiempo ni herramientas para analizar en profundidad el disco… se admiten sugerencias) para volver a poner en marcha el servidor, era reinstalar sobre un disco duro nuevo (que extraje de Galactica), lo que nos lleva al motivo de este post, ya que el sistema operativo, dadas mis experiencias pasadas, necesidades actuales y recursos limitados, era obvia: Ubuntu.

En esta ocasión descargué el ISO del DVD de instalación (y LiveCD) Ubuntu, y el proceso de montar el sistema, al igual que en otras ocasiones, fue rápido comprendiendo alrededor de una hora y media para tener el sistema base completo (ofimática, diversas utilidades, navegador, etc) y otra media hora para descargar e instalar todas las actualizaciones. Todo ello sin apenas intervención humana y con unos asistentes la mar de sencillos. Hasta aquí nada reseñable en esta versión del sistema Open Source, ya que siempre se ha comportado así, sin embargo lo que si se nota al iniciar el sistema y usarlo es un evidente cambio de aspecto (a mejor), una mejora de rendimiento (aunque creo que es solo una percepción mía) y lo que parece una mejor distribución de los elementos del menú. También parece, por lo poco que he instalado (Ddclient, Amule, y todo vía Synaptic claro) que el sistema es estable y rinde bien. El único problema que aun no he solucionado es como aumentar la resolución del escritorio o el tamaño del mismo, que parece estar limitado por el monitor (que no necesito ya que lo uso por VNC).

Así que Pegasus vuelve a servir en la flota, y ya que está con Linux pero yo trabajo con .NET, dejo pendiente la instalación de XSP2 para correr aplicaciones ASP.NET 2.0 que me servirá para jugar un poco y seguramente para escribir otro post.

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.

¡¡Que gran verdad!!

Leido en Microsiervos hace unos momentos...

"¿Que por qué los videojuegos están mucho mejor diseñados que los programas tipo Office? Los videojuegos están diseñados por gente a la que le encanta jugar con ellos. Los programas como Office están diseñados por gente que querría hacer cualquier otra cosa durante el fin de semana."

Estoy totalmente de acuerdo con esa frase. Y añado esta otra:

"El mejor programador no es el que mejor o más rápido programa, sino el que más atajos de teclados del editor de turno conoce, para impresionar a su jefe cuando pasa por su lado."

Estoy saturadísimo de trabajo, siento no actualizar más a menudo. ¡Pronto, espero, volveré! (y de paso os hablaré de mi nuevo ratón Fatal1ty de Creative comprado por 5 euros :-D)

Aladino, genios y deseos

A lo largo de los años, he notado, tanto en mi profesión de informático como en otras tareas (dependiente, blogger profesional, cliente), que existe una clase de persona / cliente bastante particular al que denomino "Aladino", nombre que como muchos ya sabrán proviene del cuento "Aladino" que Scheherezada narra al sultán en Las Mil y Una Noches, una joya de libro aunque pocos se acuerden de él en estos aciagos tiempos para Irak, Siria e Irán.

Mis Aladinos*, se ganan el apelativo cuando de forma reiterada piden cosas vagas, sin pararse a pensar realmente en lo que necesitan o lo que habrá de ponerse en marcha, sin involucrarse en la tarea... y además se quejan.
Al contrario que el Aladino del cuento que solicitaba con sabiduría lo que necesitaba y en base al poder del genio, estos Aladinos se limitan a pedir sin sentido, sin responsabilidad y exigiendo en muchas ocasiones lo imposible, lo que acaba dando lugar a una gran insatisfacción para el genio que se dedica a trabajar en pos de un deseo que nunca es el que concede y a otra gran insatisfacción para el Aladino que pide cosas que llegan a ser contraproducentes para si mismo.

En principio la solución (o buena aproximación) es tan sencilla como que el Aladino se pare 5 minutos a pensar lo que quiere o necesita, sin embargo esto suele ser anti intuitivo para Aladino, que prefiere emplear músculo y ojos donde debería emplearse cerebro, por lo que hay que tratar de encauzarle mediante algún truco de magia :-)

Los únicos trucos que conozco para ayudarnos a Aladino y a nosotros mismos son los siguientes:

Los Tres Deseos: consiste en convencer a Aladino (si no se lo cree, por muy cierto que sea, no servirá de nada) de que una vez que gaste los deseos no va a volver a tener oportunidad de corregir nada, obligándole a sentarse durante al menos unos minutos para evaluar correctamente lo que necesita.

El Genio Malvado: consiste en limitarte a cumplir exactamente lo que pide Aladino sin hacer ningún trabajo adicional ni adivinar o inventarse nada. Si Aladino quiere hacer una web llena de gifs animados y Flash para un periódico, lo haces y esperas a que se arrepienta solicitando otro deseo antes de mover de nuevo un solo dedo. En el caso de que haya que eliminar algo, te aseguras de tener una copia de seguridad SIEMPRE para poder volver de una manera cómoda al estado anterior. Y por supuesto los deseos deben ir por escrito para evitar el desplazamiento de la responsabilidad de Aladino al ifrit.

Los Pecados Capitales: se trata de escuchar atentamente lo que pide Aladino, considerarlo un momento y comentarle alguna manera mejor de hacerlo que sacie su avaricia (sobre beneficios), pereza (soportar tu la responsabilidad del proyecto), ira (venganza contra algún competidor), envidia (de algún colega al que pueda dar en los morros con algo) y/o soberbia (proteger y alimentar el orgullo y su imagen en la empresa).

Cada uno de estos trucos tiene pros, contras, y requisitos. Para los Tres Deseos se necesita una posición firme, de igual a igual, donde plantarte y de la que no te puedan sacar frotando, además de tener las suficientes tablas en la profesión como para poder ayudar Aladino a pensar. Para El Genio Malvado se necesita tener siempre a mano una libreta o grabadora y la seguridad de que Aladino no va a tomarse a mal sus propios errores, lo que implica el evitar los "ya te lo dije". En cuanto a Los Pecados Capitales es necesario conocer bastante al cliente y a su entorno, sus amigos y enemigos, trapos sucios y pecados favoritos pero una vez descubiertos llevarle a donde quieras es pan comido.

Por otro lado el ifrit siempre debe tener en cuenta que los Aladinos son los que frotan la lámpara para sacar al genio a trabajar, y por tanto tienen cierto poder en la vida del ifrit, siendo incluso capaces de cerrar la botella del esclavo si las cosas se le ponen feas, por lo que el genio debe cuidarse de pecar de orgulloso y de cabrear al "amo".

Como epílogo me gustaría recordar al geniecillo de Asimov Azazel, que tan buenos ratos me hizo pasar en su día y cuya lectura recomiendo como ejemplo de lo que puede producirse cuando un Aladino recurre a un genio bienintencionado, y como ejemplo reciente de que los problemas de entendimiento entre amos y genios no son solo atemporales, sino universales.

*Nota: Todos, en ocasiones nos comportamos como Aladinos, yo mismo incluido, aunque creo que los peores Aladinos son familiares cercanos.