Opera Unite: involucionando la web

Hoy Opera ha puesto fin al hype que ellos mismos comenzaron hace un par de días, desvelando su proyecto secreto: Opera Unite. Aunque comercialmente se pueden decir muchas más cosas, lo resumiré en un servidor web dentro del navegador. Mediante esto y un API se desarrollan servicios que se ejecutarán en tu ordenador. Por ejemplo, reproductor multimedia, gestor para compartir ficheros, páginas web, chat...

Actualización 0906161825: Ender Wiggins, un tío mucho más responsable que yo, lo está probando antes de juzgarlo (ver comentarios), por lo que tacho un par de cosas de las que me quejo sin deberlo (no lo borro para que quede constancia ;) ).

Vaya por delante que (todavía) no lo he probado, pero el concepto en sí no me gusta, por muchas razones:

  • La fundamental es que obviamente tienes que tener el ordenador encendido constantemente para que esto sea útil. Somos muchos los hace años (incluso hoy, seguro) nos montamos un servidor ftp, web o similar para poder acceder a nuestros ficheros o colgar nuestras páginas web, pero se debía a que no había demasiadas alternativas posibles. Hoy en día, con servicios de almacenamiento baratos (o muy asequibles, más que el consumo energético de nuestro sobremesa) podemos cubrir esto fácilmente. Algunas de los siguientes motivos por lo que no me gusta no dejan de ser derivados de esto.
  • No quiero poder acceder a mi ordenador desde cualquier parte. Lo que quiero es poder colgar mi contenido en la red y poder acceder a él donde sea.
  • Aún en el caso de querer acceder a mi ordenador, las alternativas son incontables: servidores web, ftp, ssh... Servidores multimedia que además convierten el formato del contenido (hay varios que se orientan a ser servidores para la Wii, por ejemplo). Hasta WinAmp ofrece desde hace tiempo un servidor propio.
  • El modelo p2p de distribución de contenido se popularizó entre otras cosas por las implicaciones legales de que un proveedor se convirtiese en distribuidor de contenido. La SGAE y similares se estarán frotando las manos al ver la cantidad de incautos que van a compartir sus colecciones de mp3.
  • Hay alternativas para todas las funcionalidades que ofrece que seguro que son mejores. No creo que su servidor web pueda competir con Apache, por ejemplo.
  • Siempre se ha podido compartir ficheros (email, directamente a través de cualquier messenger, servidores propios...). No hay nada novedoso en esto.
  • Normalmente si quiero compartir ficheros lo hago con Dropbox, que me da 2GB gratis. Y si mis necesidades son mayores, por 10$ al mes tengo 50GB. Sólo el consumo energético de tener el ordenador encendido a todas horas seguro que es mayor. Es un cliente muy ligero, que ni se nota que está corriendo, y me permite tener sincronizados directorios entre varios ordenadores, y también compartir mediante enlaces públicos. Y mi contenido siempre está accesible en su web.
  • Si quiero compartir de verdad, lo hago mediante p2p.
  • ¿Realmente queremos comprometer aún más la seguridad de nuestro ordenador personal?
  • ¿Qué valor van a tener los enlaces a páginas alojadas en PCs, que dependen de tener el ordenador encendido? Además, obviamente la fiabilidad de un PC y una red casera no tiene nada que ver con un servidor "de verdad".
  • Se necesita, sí o sí, usar DNS dinámicas.
  • Nuestras conexiones a internet suelen ser asimétricas, con una velocidad de subida irrisoria. Poner contenido online es lento una vez, pero todos los accesos a ellos son bastante rápidos. Sin embargo, con Opera Unite serán lentos siempre (hasta que Telefónica quiera, al menos).
  • En la época en la que las prácticas se entregaban en disquetes sí era muy útil montarnos un servidor ftp. Hoy en día, con una memoria USB de 16GB en el bolsillo, no lo es tanto. Y con almacenamiento en red gratuíto, menos.
  • ¿Qué pinta toda esta funcionalidad en el navegador?
  • A la gente ya le costaba configurar el router para redirigir puertos del eMule, esto será lo mismo.
  • ...
El título del artículo, "involucionando la web", es, sin duda, exagerado e injusto. El producto en sí mismo puede estar bien y en algún caso puede que incluso sea útil, especialmente para usuarios sin conocimientos técnicos que quieran montar un servidor casero fácilmente. Sin embargo, necesitaba poner el contrapunto a lo que ellos dijeron que significaría, "reinventaremos la Web", y a lo que veo en la blogosfera (revolución, y 2...). Desde hace años la tendencia que parece claro que funciona es aligerar los equipos personales y utilizar tanto contenidos como aplicaciones disponibles en la red. Esto es un paso al contrario.
Ójala GDrive, si finalmente se materializa, cumpla las expectativas creadas: gran(-dísimo) espacio de almacenamiento, API para acceder al contenido, búsqueda completa... Eso sí sería un paso adelante.

Posted by Juan Ignacio Sánchez Lara 15:29 Enlaces a esta entrada  



Redes sociales (II): Firefox Collections

Aunque en estos meses de humo nubes hablar de redes sociales suena demodé, tenemos novedades para Firefox que nos pueden hacer reflexionar sobre ello.
Las Firefox Collections son conjuntos de extensiones, listados, que puedes compartir y a las que te puedes suscribir. Por ejemplo, la primera colección que iba a figurar en el editor's pics no podía ser otra: Web Developer's Toolbox. Hecha por el usuario Mozilla (pero podría ser cualquiera), recopila las extensiones que ellos consideran fundamentales para el desarrollo web. Yo, una vez me instale la extensión 'Add-on Collector', puedo suscribirme a esta lista. Al hacerlo podré instalar las extensiones que la componen, recibiré actualizaciones si añade alguna al listado... Es una funcionalidad social pero muy potente. Cada sector puede colaborar generando un lote de extensiones interesantes: brokers de bolsa, bloggers, desarrolladores...
Esto genera una funcionalidad colateral muy interesante: sincronización de extensiones entre navegadores. Es algo que llevo necesitando desde que comencé a usar Firefox, y, aunque había formas de hacer algo similar, nada que me satisficiese.
No sé cómo se lo plantearon en Mozilla: ¿Cubrir la necesidad de sincronizar extensiones y de ahí salió la idea de compartirlo? ¿Al revés? ¿Ambas a la vez? El hecho es que la funcionalidad social (compartir colecciones) es la generalización de un caso particular (sincronizar mis extensiones) de interés para el usuario. Este es un ejemplo perfecto de solución del problema del arranque en frío en redes sociales comentado con anterioridad:

  • Cubre una necesidad personal existente...
  • ... y a la vez aporta un gran valor añadido.
Dos nuevas notas mentales que siempre denería tener presente:
  • Cuando vayas a implementar algo, piensa si en vez de resolver el caso específico puedes encontrar una solución más general...
  • ... y piensa si esa solución general tiene potencial con un botón "compartir con más gente".

Posted by Juan Ignacio Sánchez Lara 17:34 Enlaces a esta entrada  



CexC, Teiid y el estado del blog

Llevo mucho sin actualizar el blog (dos meses), y antes de la última entrada el ritmo ya había bajado. Alguna razón tenía que haber, además del habitual cansancio. Esta página siempre ha sido una vía de escape de mis inquietudes tecnológicas, pero últimamente me parecía estar totalmente desinteresado de las novedades del sector. El escaso tiempo libre y el que me ocupa la fotografía hacían el resto.
Dándole un poco de vueltas este desinterés realmente no existe, lo que ocurre símplemente es que lo cubro en horas de trabajo. Hasta ahora mi trabajo había sido de desarrollo o de gestión de proyectos, lo que apenas dejaba margen al cacharreo con nuevas tecnologías, por lo que esa necesidad que realmente tengo de estar al día, de probar cosas nuevas, se cubría en casa.
Desde finales del año pasado estoy trabajando en el Centro Experimental del Conocimiento (CexC para los amigos), y mi papel es, en gran medida, realizar un esfuerzo de investigación e innovación. Para nosotros es fundamental evolucionar nuestra forma de trabajo y mejorar constantemente las herramientas a utilizar, y una buena parte de mi tiempo se va en leer artículos, noticias, descargar nuevas aplicaciones o componentes, y probarlos y pegarme con ellos. La verdad es que da gusto cuando, en este sector tan condicionado por los plazos y clientes, se tiene oportunidad de invertir una buena parte de tu tiempo en tareas de innovación, y se confía en la adopción de nuevas tecnologías en vez de atarse a la tradición.
Como medio para dar algo más de visibilidad a esto, y como medio de comunicación, en el CexC acabamos de abrir un blog de nuevas tecnologías en el que ir mostrando al menos una parte de esta inversión. Todavía está en pañales, pero os agradecería que figurase en vuestros marcadores o lectores RSS.
La primera entrada habla de Teiid, una fantástica herramienta para virtualización de datos que acaban de liberar en jboss.org. Cualquiera que haya realizado una aplicación empresarial con varias fuentes de datos diferentes sabrá valorarla como corresponde, en mi opinión. El primer artículo es introductorio, pero iremos ampliando con ejemplos prácticos de esta y otras tecnologías de JBoss con las que trabajamos desde hace tiempo.
Todavía no dispone de comentarios (espero activarlo en breve), así que quien quiera abrir el diálogo que lo haga por aquí mismo.
Nos vemos por el CexC :).

Posted by Juan Ignacio Sánchez Lara 16:50 Enlaces a esta entrada  



Postmortem: estimaciones y creación del sprint backlog

Estamos cerrando el último proyecto, una aplicación de gestión de datos con múltiples perfiles que controlan el trabajo y la información introducida por los demás. Acaba de entrar en explotación con bastante éxito: ni un error en los cuatro primeros días de uso, fundamentales porque corresponden con una primera fase que tiene un plazo límite. A partir de ahora, mantenimiento correctivo y algo de evolutivo.
Es un buen momento para comenzar el postmortem y analizar los errores cometidos.

Hemos usado Scrum como metodología, y la conclusión es que nos ha aportado tan poco como cualquier otra metodología que hubiésemos usado, pero al menos no ha molestado. No creo que nos haya aportado un auténtico valor, pero creo que estamos en el buen camino. El gran reto que teníamos para el desarrollo del proyecto era el uso de una pila de desarrollo nueva para casi todos, y contra eso no hay metodología que valga.

El product backlog se hizo a partir de las reuniones de contacto con los usuarios y de los primeros documentos de prototipado y requisitos que nos pasaron. Hasta ahí, bien, no es un artefacto que tenga mayor complicación.

Para estimar el product backlog hicimos planning poker con el equipo, tras haber contado de qué iba el proyecto. A todas luces la estimación era muy optimista, y se cumplió aquello de que los técnicos son positivos y que los gestores son pesimistas. Sin que sirva de precedente, los gestores tenían razón. Sin embargo, creo que si el mismo equipo volviese a comenzar el proyecto sí cumpliría las estimaciones que salieron de esa reunión. La experiencia en la tecnología y una mejor gestión de los requisitos habrían hecho que se hubiese podido implementar en los tiempos dichos.

Creo que nuestro gran error desde el punto de vista de la metodología fue la creación del sprint backlog. Lo hizo una persona (yo, como Scrum Master). Gran equivocación. Lo debe hacer el equipo en conjunto. El equipo careció de una visión global del proyecto, lo cual no trajo más que problemas:

  • Se adquirieron tareas en el orden incorrecto.
  • No se sabía qué era común y qué no, así que era más difícil organizarse para la reutilización.
  • "Marchas atras" por mala comprensión de las tareas.
  • Funcionalmente se depende del criterio de una única persona.
  • La estimación de las tareas habría sido más acertada con un mejor conocimiento del problema.
  • ...
Ya en un plano más técnico, otra fuente de problemas iniciales fue la ausencia de un modelo de entidades del que partir. Se pretendió hacer de forma totalmente incremental, exprimiendo al máximo la generación del modelo de datos de Hibernate a partir de las clases. En los anteriores proyectos, como ya he comentado, se nos imponía que un analista crease el modelo de datos, y que eso se tomase como base para comenzar el desarrollo. El extremo contrario tampoco es útil:
  • No es una tarea trivial, y es poco tolerante a errores. No pasa nada si haces mal un campo en una pagina, pero un error en el modelo de entidades puede tener consecuencias bastante dramáticas. Hacerlo exige un conocimiento profundo de los requisitos.
  • Una equivocación de una persona puede tener un desagradable efecto de malentendidos de los requisitos en cadena.
  • No es fácil compartimentar inicialmente para que la gente pueda trabajar independientemente.
Para la próxima...
  • El product backlog lo hará el Scrum Master como esta vez, antes de la primera reunión (tampoco tiene sentido movilizar a más personas para él).
  • En el sprint meeting el sprint backlog se hará entre todos los miembros del equipo. En vez de llevar a la reunión el sprint backlog prefabricado, leerlo, y estimar a partir de esa lectura, se generará durante ella, y tras la creación de cada tarea se hará la estimación de la misma. Sí, nos llevará mucho más tiempo, pero no será perdido, sino invertido.
  • En caso de tratarse de una aplicación de gestión, probablemente durante el propio sprint planning se hará un modelo de entidades (entidades del sistema y su relación entre ellas, sin necesidad de entrar a nivel de propiedad). Algo muy básico, pero que permita tener un punto de arranque común y afianzar los requisitos. Eso sí, me mantengo en la opinión de que con Hibernate ya debemos trabajar en términos de entidades y no de tablas.

Posted by Juan Ignacio Sánchez Lara 10:10 Enlaces a esta entrada  



Java en Google App Engine

Hasta ahora el hosting accesible (gratuito o de precios ajustados) era territorio dominante de la plataforma LAMP (Linux + Apache + MySQL + PHP) o derivados. Este ha sido uno de los factores determinantes de la proliferación de herramientas open source para foros, blogging, etc.
Por el contrario el mundo empresarial está copado, también en gran parte, por Java (aunque sitios como Flickr o Yahoo! demuestran que PHP es un sistema que no tiene que limitarse a eso, pero este es otro tema).
Hoy Google ha anunciado la disponibilidad de Java en Google App Engine. Además, con soporte para JPA. Por fin hay una alternativa real al LAMP (¡ojo, que no tiene nada de malo, pero las alternativas siempre son buenas!).

Posted by Juan Ignacio Sánchez Lara 15:11 Enlaces a esta entrada  



Los ordenadores son, esencialmente, deterministas

Los ordenadores, fallos hardware aparte, son autómatas deterministas: dado un estado inicial, una serie de operaciones llevan siempre al mismo resultado.
Una conclusión de esto es que no hacen "cosas raras". Puede haber cosas mal hechas, claro está, pero sus efectos son predecibles.
Un caso paradigmático de esto son las librerías. En todas hay bugs, claro, pero pocos. Si algo "no funciona" revisa antes tu código. Las librerías de código abierto son usadas por millones de desarrolladores, y revisadas por gran parte de ellos (¿aún no has asociado las fuentes a los binarios en Eclipse? ¿A qué esperas?). Sin embargo, tu código es nuevo y sólo tuyo, probablemente el problema esté ahí.
Cuando llamamos a un SAT lo primero que nos preguntan es ¿está enchufado? Sí, es irritante, pero, ¿compruebas que tu código lo está? El determinismo hace que para solucionar la mayor parte de los errores en el código no sea necesario ni pensar. Símplemente un análisis metódico desde el error nos conduce al error: vete a la línea que falla y vete "tirando del hilo". El problema aparecerá solo.

PS: ¿Ah, que estás utilizando librerías propietarias, sin el código? Mmm... ¡Buena suerte!

Posted by Juan Ignacio Sánchez Lara 14:40 Enlaces a esta entrada  



IPhone 3.0 y ubiquidad

No es mi costumbre usar este blog para hacer reseñas de productos, pero sí me gustaría hablar un poco del IPhone, a cuento del reciente anuncio de la versión 3.0 de su sistema operativo.
Se habla mucho de cloud computing, Web 3.0 y demás milongas últimamente, que, en mi opinión, sólo sirven para alimentar los blogs, las columnas en las revistas, y con ello, las nóminas, de supuestos visionarios. Nuevas etiquetas para productos que ya existen.
Sin embargo, la auténtica evolución (no creo que haya revoluciones a la vista) de Internet es la presencia ubíqua de la misma. Hace aproximadamente cinco años trabajé en proyectos de I+D sobre este tema, y se veía claro que el futuro pasaba por ahí. Sin embargo, el precio de los dispositivos y la cara y escasa cobertura de Internet de calidad lo hacían imposible.
A día de hoy los dispositivos están al alcance de cualquiera, y la conexión es más que aceptable, así que esto está a punto de estallar. Google lo sabe y se ha posicionado con Android. Apple, con su iPhone, ya lo está experimentando.
La versión 3.0 contiene dos bombas potenciales en este aspecto: las compras in-app y la conexión de dispositivos.
Sí, todos gritábamos por tener, por favor, cortapega ("ortodoxo", ya que con jailbreaking ya se podía), tethering y A2DP (Bluetooth Estéreo). Pero lo que puede ser una revolución ubíqua es lo otro.
Las compras in-app permiten un modelo de negocio basado en micropagos, para ofrecer contenido de calidad (de pago). Off-topic: ¿tendrá el siguiente iPhone una pantalla de lector de ebooks a color y reventará el mercado?
La conexión a dispositivos permitirá conectar cualquier aparato a Internet, sin requerir una dedicada. Ya estoy empezando a pensar aplicaciones online a aparatos que ahora son offline...

Quien quiera innovar y forrarse, que piense en ubiquidad y se deje de modas pasajeras.

Posted by Juan Ignacio Sánchez Lara 18:53 Enlaces a esta entrada  



Artesanía

El desarrollo de software tiene más de artesanía que de ingeniería. Sí, hay métricas, calidad, automatizaciones... Pero lo que requiere de la persona que lo realiza es que sea un buen artesano, que haga las cosas con esmero, meticulosidad...

Posted by Juan Ignacio Sánchez Lara 9:56 Enlaces a esta entrada  



Cuándo hacer el modelo de datos

Si me preguntasen por el mínimo común denominador de la aplicación de las metodologías tradicionales que he visto en los últimos años, respondería sin dudar el modelo de datos. La gestión de los requisitos es muy variable, el diseño y la construcción varían enormemente... Sin embargo, el momento y la forma en que se hace el modelo de datos siempre era la misma. Una vez recogidos los requisitos, durante el análisis, el paso clave que marcaba, en cierto modo, el fin del trabajo del analista y el comienzo del resto, era la validación del modelo de datos.

En las metodologías tradicionales se hace en dos partes: en la fase de análisis se hace el modelo lógico, y en diseño se hace el físico. En la práctica siempre he visto que esto se fusionaba. Quizá por las herramientas, quizá por lo innecesario de la división, siempre se hace directamente el segundo.

Desde que uso Hibernate había querido aprovechar al máximo la potencia de su mapeo relacional, relegando el modelo de datos a un segundo plano en favor del modelo de clases. Esto, que parece un detalle menor, en mi opinión tiene una gran importancia práctica. Hacerlo implicaría que el analista/diseñador haría, en vez del modelo, directamente las clases, las cuales generarían el primero automáticamente. Expuse esta idea esgrimiendo una serie de ventajas:

  • El trabajo de modelado aportaría más información, ya que los modelos Java más las anotaciones de persistencia aportan más información y valor que las tablas (se introducen validaciones de datos, propiedades calculadas, documentación...).
  • Eliminaríamos el problemático trabajo de mapear tablas existentes.
  • Adelantaríamos el trabajo de la programación de las entidades.
  • Podríamos anticipar cosas como pruebas automáticas para verificar la corrección del modelo.
  • Personalmente trabajo mejor con una herramienta de desarrollo que con una de modelado. Andar con el ratón, dobles clicks y diálogos me parece engorroso y lento, aunque esto ya son preferencias de cada uno.
  • No renunciamos a la información gráfica, ya que podemos generar diagramas tanto de clases como de objetos mediante ingeniería inversa (NetBeans es realmente útil para esto).
La idea no prosperó, y los siguientes proyectos se hicieron como anteriormente.

Al pasar a metodologías ágiles, al desaparecer estas fases, toca decidir cuándo realizar este trabajo. Scrum obviamente no entra en esta decisión, así que, ya con la capacidad de decisión, me adherí al principio de diseño contínuo y además adopté las ideas anteriores. De esta forma, no se haría el trabajo explícito de modelado de los datos, sino que, a medida que se avanzase en la aplicación, se iría mejorando a través del propio diseño de las clases.

Ya con el proyecto en desarrollo, saco las siguientes conclusiones:
  • No realizar análisis del modelo de datos, sino trabajar directamente en el diseño de las clases, es muy práctico: es mucho más tolerante a los cambios (hemos pasado de claves deferred a compuestas de forma trivial, por ejemplo), facilita el trabajo en equipo (no más "lanza de nuevo el script de base de datos, que he cambiado el esquema")... Me reafirmo, por tanto, en los puntos expuestos antes.
  • Desaparece la mentalidad de "tenemos que ceñirnos al modelo de datos a cualquier coste". He visto auténticos malabarismos por parte de desarrolladores por querer respetar el modelo del analista por todos los medios. El hecho de no tenerlo tira esa barrera.
  • Pese a esto, sigue siendo necesario hacer un trabajo previo de análisis. Comprender las clases y las relaciones entre ellas es fundamental para el desarrollo del proyecto. No es necesario especificar desde un principio cada propiedad de cada clase, sus longitudes máximas y sus validaciones, pero sí es importante tener claro lo antes posible el esquema general. Los desarrolladores tendemos a centrarnos en "pantallas", y en una no está la auténtica lógica de las relaciones entre los datos.
Para el siguiente proyecto estoy pensando incluso en hacer una primera versión del modelo de clases en el primer Sprint Meeting. En este creamos una tarea específica para ello, pero esto hace que el conocimiento quede en una sola persona. Creo que el trabajo de hacer una primera aproximación, incluso antes de la estimación de las tareas, ayudaría a todo el equipo a comprender el problema a resolver y la complejidad del desarrollo.

Posted by Juan Ignacio Sánchez Lara 15:15 Enlaces a esta entrada  



¿Qué hacer cuando los usuarios/clientes se ponen nerviosos?

Como dirían en El Hormiguero... "¡Los usuarios, ese gran desconocío''!"

Hoy se nos han puesto nerviosos los usuarios/clientes. Hacemos aplicaciones a medida, y hace un par de semanas tuvimos la última reunión (aún hay requisitos sin cerrar, pero bueno, tenemos claro que tenemos que aprender a convivir con eso). Nos han perido que quieren ver algo cuanto antes (obviamente cambiando la planificación acordada).

Ante una situación así se me ocurren tres alternativas:
a) Como no es lo pactado, nos ceñimos a lo hablado, así que dentro de mes y algo nos vemos. Hasta entonces, dejadnos tranquilos.
b) Ok, el cliente siempre tiene la razón, así que nos adaptamos. Cambiamos la duración del sprint, adelantando la demo, aunque reduciendo el número de historias de usuario que presentamos.
c) Nos mantenemos como estamos, pero, como el cliente siempre tiene la razón, os daremos versiones previas de prueba (abriendo acceso a alguno de nuestros servidores).

La a) es la típica en la programación por contrato, la ortodoxa, la que te enseñan en clase. Tiene sus ventajas y sus inconvenientes. Por un lado, sí, estás en tu derecho de "plantarte", ya que así está acordado. Pero por otro, no satisfaces la solicitud del cliente. Personalmente no me gusta. Predispones al usuario a tirar a la basura lo que le enseñes en la fecha acordada. Y, no lo olvidemos, en ese momento pueden tener razón (sí, señores, los desarrolladores también nos equivocamos).

La b) es la que inicialmente pensamos. No es demasiado mala, ya que no aumenta la "densidad de trabajo", y contenta a los usuarios. Pero presenta varios problemas. La duración del sprint no se debe cambiar, y mucho menos por gente no comprometida. Además, es tarea específica del Scrum Master evitar este tipo de situaciones. Y, dejando ya de lado Scrum, te permite menos margen de error. Aunque la "densidad de trabajo" no cambie, es más difícil cumplir el plazo.

La c) es la que finalmente se va a tomar. No sólo no rompe reglas de la metodología, sino que va a potenciar que el trabajo se haga como se debe. Ya habíamos quedado clara la "definición de hecho" y la integración contínua, así que en cualquier momento se podría desplegar el código del repositorio para probar. Y, además, permite satisfacer la necesidad del usuario (¡incluso mejor que con la opción b), ya que podrá ver más antes) e implicarle más. Tendremos feedback antes, minimizando el impacto del cambio de requisitos. Queda claro (tanto para el equipo como para el usuario) que la fecha de la demo es cuando debe estar el producto estable, que hasta entonces sólo estará viendo una versión en desarrollo.

En teoría todo pinta bien, ya veremos en la práctica :)

Posted by Juan Ignacio Sánchez Lara 15:52 Enlaces a esta entrada  



Redes Sociales (I): el arranque en frío

Las redes sociales basan su funcionamiento en el comportamiento de las personas que las conforman, y, como sistema humano que son, presentan ciertos fenómenos más o menos indeseables.
Uno de ellos es el fenómeno del arranque en frío. En general se refiere a que, dada una situación inicial de un sistema o un elemento (en función del contexto el significado de inicial varía), su estado posee una gran inercia, por lo que es difícil que comience a funcionar.
Esta propiedad, como otras tantas cosas en informática, puede verse a muchos niveles. La aplicación más amplia puede ser el arranque en frío de la red en sí misma: por lo que sea planificas la creación de una nueva red social -justo lo que el mundo necesita-, pero al no tener usuarios los usuarios no se registran, en forma de problema recursivo. El éxito de una red social es el uso que de ella den los usuarios y sus interacciones, por lo que, al estar vacía, tiene poco valor.
Se proponen varias soluciones:

  • Por supuesto, haz algo que tenga interés.
  • Establece mecanismos que recompensen la creación de contenidos.
  • Proporciona APIs de forma que los usuarios puedan extender y conectar el sistema.
  • Alimenta tu sitio a través de APIs y enlaces de otros sitios. Una utilidad muy importante es la de importar contactos. Nadie a estas alturas de la vida se planteará introducir de nuevo las direcciones de sus amigos a mano.
  • Maximiza la visibilidad social del contenido creado por los usuarios.
  • No generes spam.
  • Permanece atento a los usuarios y añade nueva funcionalidad con frecuencia.
Yo añadiría otras:
  • Ofrece contenido desde el principio de su apertura "pública". Mediante un conjunto de "usuarios expertos" puedes crear contenido de forma que cuando el sitio "abra" ya esté funcionando.
  • Haz que los usuarios quieran registrarse. Uno de los aciertos que han llevado al éxito a Tuenti ha sido el sistema de invitaciones, creando una sensación de exclusividad que hace que la gente quiera estar. Es otra de las motivaciones del "beta" ya generalizado en los "servicios 2.0".
Si nos "acercamos", encontramos un nuevo caso de problema de "arranque en frío": el de el contenido nuevo. La primera vez que leí al respecto fue referido a last.fm, el servicio en el que los usuarios envían sus preferencias musicales. El problema es, esencialmente, que hay contenido que parte con tanta ventaja (Los Beatles, Rolling, Radiohead, Coldplay...) que es difícil que el nuevo cobre relevancia. Yo lo notaba con la característica de "reproducir artistas similares" del magno reproductor Amarok. Pusiese lo que pusiese, a eso de una o dos horas los Beatles o los Rolling hacían de agujero negro: al final el contenido que suena acaba estando relacionado con ellos, y se convierten en lo único que reproduce el sistema.
Este problema es difícil de combatir por su propia esencia. De hecho, alguno podría discutir que no se debe combatir, y que el éxito del contenido de una red no debe estar manipulado. Si las fotos de rosiehardy son tan buenas, ¿por qué no debe estar abonada a la portada del explore?
Como para todo, hay soluciones, al menos parciales:
  • Introducir aleatoriedad para evitar los "agujeros negros". Esta es la estrategia del nuevo Amarok. Han complicado la lista dinámica de forma que sea posible "escapar" de esos artistas destacados.
  • Creación de listas específicas que favorezcan las novedades: listas de "lo más nuevo", "lo más escuchado en los últimos días", etc.
  • No crear elementos que penalicen aún más el arranque en frío. Por ejemplo, en el concurso de fotografía de Público han creado una página de 'las más votadas'. Esto es muy negativo, porque los usuarios casuales entrarán a ver lo que hay e irán a esa página en vez de recorrer la galería entera, lógicamente, favoreciendo el voto de las más votadas. Existiendo algo así se premia rapidez en la carga y en el posicionamiento inicial en vez de la calidad en sí. Yo lo sufrí la semana pasada, esta estoy intentando hacer lo contrario :).

Posted by Juan Ignacio Sánchez Lara 13:27 Enlaces a esta entrada  



Estrategias motivadoras 'alternativas'

Mi pareja lleva una agencia de viajes Ecuador en Valladolid (enlace patrocinado ;) ) y hoy me contaba que en uno de los cursos a los que va a ir son muy dados a hacer que la gente participe a base de premios. Cuando alguien responde una pregunta, le dan un detalle (un imán o similar). Obviamente el "premio" no es la finalidad, ni del curso ni de los asistentes, pero convierten algo que normalmente es aburrido y unidireccional en algo más divertido y, sobre todo, más participativo.
Siempre habrá alguno que diga que esto es algo estúpido e incluso una falta de respeto, poco profesional, que es como las sardinas de las focas o los plátanos de los monos... ¿Vosotros lo veis así? Yo no. Ojo, sólo hablo de premios "alternativos", no incentivos "de verdad" (económicos o, en general, caros, eso es tema para otro post).
En mi opinión, estos premios alternativos son más que un juego, que permite establecer una relación de confianza mayor. Los resultados son claros: más gente va al curso, la que va se lo pasa mejor, y además, participa.

¿Incentivos como estos son aplicables a la gestión de proyectos o, en general, a una empresa de desarrollo de software? No hablo de algo que vaya a aumentar la productividad de forma generalizada o una nueva bala de plata, sólo algo positivo, de escasa importancia. Últimamente estoy teniendo que dar más charlas de las que me gustaría, y noto que son bastante pesadas. Hago lo posible por mejorar la participación, pero no es fácil. Incluso el trabajo diario se podría intentar hacer algo más ameno (sí, ya sé que es trabajo, y sí, sé que no somos niños y no hay por qué convertir todo en un juego, pero a nadie le amarga un dulce).
Alguno hay ya en marcha: para Hudson, el sistema de integración contínua, hay un plugin que se llama "El Juego de la Integración Contínua". En resumidas cuentas, se dan puntos por "hacer las cosas bien": añadir pruebas, participar en compilaciones correctas, mejorar las métricas de calidad... Yo lo he instalado en nuestro servidor, en unas semanas os diré cuál es el balance.
Obviaremos el sistema de logros para Eclipse ;)
No se necesita nada tecnológicamente elevado, con una caja de cartón puede valer. Un par de personas en el anterior despacho hicimos una hucha de fails, cada vez que cometíamos una burrada poníamos 10 céntimos.

¿Qué opináis? ¿Tenéis trucos para hacer vuestras exposiciones más llevaderas? ¿Y en el trabajo?

Posted by Juan Ignacio Sánchez Lara 16:23 Enlaces a esta entrada  



Resolución de problemas

Uno de los indicadores más claros, en mi opinión, de la validez (aptitud y actitud, principalmente) de alguien en un trabajo es la forma en la que afronta un problema. Por ejemplo, plantear un problema en una aplicación web en una entrevista de trabajo, puede permitir conocer muchas cosas del entrevistado:

  • ¿Comprende el modelo cliente/servidor? No sería la primera vez que escucho a gente que no comprende dónde se ejecuta el PHP y dónde el Javascript.
  • ¿Es capaz de leer los errores? Lejos quedan aquellos volcados típicos de ensamblador o C. Los lenguajes y los entornos de hoy suelen dar información significativa de lo que ocurre cuando hay un problema. Sin embargo, no todo el mundo realmente se para a interpretarlo.
  • ¿Está acostumbrado a programar tests? Hoy en día se puede probar casi todo, desde el acceso a datos hasta problemas de interfaz. Sugerir programar una prueba cuando aparece un problema sería un muy buen síntoma.
  • ¿Tiene recursos? Pensar en problemas frecuentes o ofrecer alternativas de solución suelen ir relacionado con experiencia real.
Cuando alguien me pide ayuda y su discurso está plagado de "no sé", "esto debería funcionar", "antes iba bien", tiemblo, y si encima se remata con un "no, no he probado eso" o "espera que miro qué pone el error", directamente se me cae el alma a los pies. Es habitual decir que un ingeniero se dedica a resolver problemas. Viendo la ineptitud que a veces presentamos para hacerlo, no me extraña que nadie considere la Informática una Ingeniería.

Me encantan 'C.S.I.' y 'House'. Ambas tienen en común que el leitmotiv es la resolución de un problema. La primera se centra en la recopilación de pruebas, mientras que la segunda es sobre investigación del problema en sí y prueba y error. De hecho, ofrecen dos perspectivas diferentes de cómo afrontar un problema:
  • En C.S.I. es necesario ser muy meticuloso y seguir unos protocolos establecidos (por temas legales) y se dispone de una cantidad razonablemente alta de recursos (un departamento, helicópteros, alta tecnología...). No se presupone nada. Se recopilan y analizan pruebas, y cuando surge una hipótesis se deben conseguir hechos que lo contrasten. Si no se hace así, el señor juez dejará libre al malo por no validez del proceso. La ventaja de esta aproximación es que, con tiempo, la verdad suele salir a la luz por sí misma: el mismo proceso de recopilación de pruebas te lleva al asesino, no hay crimen perfécto (¿o sí?). Ellos tienen el agravante de que su problema (el malo) sigue corriendo mientras ellos avanzan.
  • En House se suele trabajar con prisas (el paciente se muere cada vez más rápido) una cantidad limitada de recursos (no puedes dedicar todo el hospital para un paciente) pero muy buenos (tiene un equipo de los mejores profesionales). Hay procedimientos, sí, pero los protagonistas suelen estar por encima de ellos, considerando como único protocolo el conseguir que el paciente no muera. Mediante diagnóstico diferencial, similar al método socrático, y un (exagerado) proceso de prueba y error se genera el conocimiento que permite localizar el problema.
En mi opinión en informática la resolución de errores se asemeja a House. Cuando encuentras un fallo (aparece un síntoma), hay que...
  1. Pensar posibles lugares problemáticos (posibles enfermedades): ¿problema de configuración del servidor? ¿Fallo en la lógica de negocio? ¿Problema con el acceso a datos?
  2. Hacer los análisis no costosos ni intrusivos: "¿está enchufado?" "¿El usuario y password son correctos?" "¿La base de datos está levantada?".
  3. Priorizar (por probabilidad y coste) los problemas posibles, y comenzar la prueba y error. Nota: quita el tratamiento después de cada prueba (deja el código como estaba).
A éstos añadiría un punto 0 que no encaja en la analogía: prepara una prueba que primero demuestre que hay un problema, y que después te sirva para demostrar que lo has resuelto.

Posted by Juan Ignacio Sánchez Lara 19:06 Enlaces a esta entrada  



¿Los usuarios a la tecnología o la tecnología a los usuarios?

Hace un mes abría una incidencia con Orange porque la velocidad de sincronización me había bajado aproximadamente a la mitad. El otro día me llamaban para cerrar la incidencia, indicándome que la culpa sería de Telefónica, que habría venido más ADSLs en la zona, por lo que la velocidad se reduce. Intenté no pagar mi indignación con la pobre señorita del teléfono, pero hay varias cosas que claman al cielo...

  • ¿A mí que me cuentas de Telefónica? Yo tengo contrato con Orange (incluso la línea), y una de las razones para cambiar a vuestro ADSL fue tener "un único pagador" (cuando tenía problemas antes se pasaban la patata caliente).
  • ¿Cómo que porque haya más clientes se baja la velocidad? ¿Si mi vecino abre el grifo yo no me puedo duchar? ¡Estáis vendiendo por encima de la capacidad!
Dejemos al margen mis problemas con Orange. En Nubeblog enlazaron, casi coincidiendo con lo anterior, unos datos sobre que las PYMES pasan (sic) del Cloud Computing.
Estos dos hechos me llevaron a una discusión filosófica (soy mucho de filosofar contra mí mismo). ¿Cuántos detalles técnicos debe conocer un usuario?

¿Para qué quiere una PYME saber qué es el Cloud Computing? ¿Para qué quiero yo saber que mi problema es porque tienes malas condiciones respecto a la reventa de la línea? Dime que me vas a hacer un backup a través de Internet a un 10% de mi coste actual. Dime que no se puede ofrecer un servicio de más calidad en mis condiciones y ofréceme otra oferta... Ahorrate lo demás, ¡no me importa!

Haz buenos productos sin entrar en tecnicismos y detalles que no le aportan nada al usuario. Lo demás es autobombo (o excusas).

Posted by Juan Ignacio Sánchez Lara 13:15 Enlaces a esta entrada  



X enlaces de los X últimos días

Unas cuantas cosas de las que he compartido en Google Reader en los últimos días.

¿Tu informático está trabajando?
Estados mentales de un informático, desde el 100% improductivo hasta el flow.

Seven Principles of Lean Software Developement
La semillita que papá puso en mamá para dejar de parchear el desarrollo en cascada mediante desarrollo por contratos, de la cual salieron las metodologías ágiles.

Salesforce.com Agile Transformation
Soy un adicto de los casos reales. Aquí vemos cómo Salesforce.com adoptó metodologías ágiles.

Can You Cure the Copy/Paste Disease?
Sí, sé que sufro micromanagementitis, pero nunca dejaré de amenazar con cortar dedos a quien cortapegue, y me gustan los artículos que me dan la razón (soy así :) ).

Agile in the Trenches
Más casos reales. Creo que un caso así demuestra la utilidad, a veces puesta en duda, de un Scrum Master.

OFFTOPIC: Que llueva, que llueva
La convivencia en pareja trajo consigo una negociación en la que intercambiamos los gorgoritos de los triunfitos por las carreras de Alonso, los Nadal - Federer, y unos cuantos tuercebotas. Dicho sin prosa, a cambio de ver deporte sin discutir, durante unos meses al año tengo que soportar Operación Triunfo.
El programa en sí no es tan terrible. El esfuerzo de la música en directo no es habitual en televisión estos días, y que todos, participantes e invitados, interpreten en directo, es bueno. Y siempre hay alguno que canta bien, eso es así. Además la música de fondo siempre es muy buena (en el último año escuché Muse, Coldplay, Los Planetas, Arcade Fire...), ya sólo queda que promocionen esa en vez del último hit de Vale Music. No me gusta el lado reality, pero, por encima de todo, me disgusta la idiotización musical que este programa ha producido. En los últimos castings se hacía patente: la mayor parte de los adolescentes que engordaban las infinitas colas de candidatos habían vivido sólo con Operación Triunfo. Cuando se les ponía a prueba con una canción no conocían la versión original, sino la del anterior triunfito. Se piensan que triunfar es salir de ese programa. Dadme a un currante de garitos madrileños como Luis Ramiro, Marwan o Andrés Lewin, y retirad del mercado los clones prefabricados.
Al grano, que me voy por las ramas.
En las últimas ediciones el principal interés pasó del escenario al jurado, a Risto Mejide. Tengo que admitir que, como el 90% de la audiencia, disfruto sus minutos como un niño. Su personaje de publicista hiriente y odioso me encanta, pero lo que se puede ver más allá me parece también del máximo interés. Más allá de su fachada, nos ha dejado estos días un artículo directo, sincero y, en mi opinión, terriblemente acertado. Quien quiera estancarse en la mediocridad y dejarse llevar por el torrente de la crisis, que lo haga. Pero que no venga luego lloriqueando.

Programación Basada en Google
Desconozco si Julio César Pérez figura en esas listas de gurús, pero su blog me encanta. Pocas entradas, pero admirablemente escritas, y siempre de valor. En general es un tipo práctico (atajos de Eclipse, ejemplos de código...) pero esta vez hace una reflexión muy acertada sobre un antipatrón de desarrollo que todos reconocemos.

Posted by Juan Ignacio Sánchez Lara 17:54 Enlaces a esta entrada  



Micromanagement

Hoy he caído por casualidad en una tira sobre micromanagement en Geek Hero Comic:

Está claro que esta tira no es Sinergia Sin Control, pero me ha hecho pararme a pensar si tengo un problema: me he visto reflejado con el tipo del peinado de el de Simply Red (o el Actor Secundario Bob, o Bisbal, o mi amigo Valle ^_^).
Tengo que admitir que soy muy maniático con muchos detalles que considero importantes, y, más que importantes, malos síntomas. Hoy mismo, en una presentación sobre metodología de desarrollo que he hecho para los compañeros, me he declarado un entrometido maniático, y les he pedido disculpas por anticipado al respecto.
Concretamente, soy MUY maniático con estos detalles (entre otros), que si seguís el blog ya habréis visto comentados:

  • Programar usando el ratón en vez de dominar (progresivamente) los atajos de teclado.
  • No aprovechar las vistas de Eclipse, en sus diferentes variantes: ordenar el código mediante algún criterio en vez de utilizar la vista 'outline'; no utilizar //TODOs y //FIXME para que aparezcan en Tasks; no explotar las posibilidades de la depuración...
  • ¡Cortapegar!
  • Nomenclatura de variables.
  • ...
Buscando al respecto del micromanagement he encontrado diversas opiniones y descripciones. En general se puede definir como gestionar intentando controlar todos los detalles, hasta el más pequeño, sin capacidad de delegación o de confianza.
Tengo que admitir que me siento bastante representado en unos cuantos puntos (la Wikipedia lo asocia a desórdenes obsesivos compulsivos, no sé si diría que tanto, pero casi), así que debo reconocer mi errores al respecto (alguno ciertamente grave). En mi defensa, diré que mi intención siempre fue intentar ayudar, pero está claro que no siempre fue de forma correcta.
Prometo esforzarme en mejorar :).
Una vez hecho este ejercicio de autocrítica...

¿Dónde está la barrera que separa el micromanagement del management y del mentoring? Parece claro que los tres son prácticas relacionadas. Diría incluso que el micromanagement es la perversión de la unión de los otros dos, es llevarlos al extremo. Pero ¿dónde comienza uno y empieza el otro? Creo que es algo subjetivo, que depende de los implicados. Lo que a una persona le puede parecer una ayuda, una sugerencia, a otro le puede parecer un entrometimiento. Seguramente llegar al punto de la confrontación es un síntoma, pero hay otros, como la falta de percepción de confianza, que no son tan fáciles de ver.

Sin embargo, ¿no son herramientas como Checkstyle una forma de micromanagement? ¿No lo es el Daily Scrum? Yo los veo como herramientas para mejorar la calidad del producto y uno mismo, pero esa es mi percepción...

¿Qué opináis? ¿Microgestionais? ¿Lo habéis sufrido alguna vez? ¿Creéis que con ciertas personas o en ciertos momentos puede ser necesario adoptar posturas así? ¿Cómo lo evitaríais?

Supongo que, como siempre, in medio stat virtus.

P.D.: a los compañeros que leáis esto, no dudéis en atarme en corto en este aspecto ;)

Posted by Juan Ignacio Sánchez Lara 19:29 Enlaces a esta entrada  



Trazabilidad

Podríamos explicar la trazabilidad (bidireccional) en el contexto del desarrollo de software como "dado un requisito llegar a la línea de código que lo implementa, y al contrario, dada una línea, saber con qué requisitos corresponde"(a grandes rasgos, no cortapegéis esto para nada importante ;) ).
Esto tiene muchos matices y complicaciones, tanto teóricas como prácticas. ¿Realmente es importante? ¿Necesitamos bidireccionalidad? La trazabilidad es claramente una función no biyectiva: una misma línea probablemente corresponde con varios requisitos, y un requisito corresponde con muchos fragmentos de código dispersos.
Hasta hace poco siempre había visto esto como algo imposible de conseguir -a un coste razonable-. Los requisitos se registraban en un procesador de textos, las tareas en un diagrama de Gantt, y el código en un repositorio, todo desconectado. Los intentos que ví para solucionar esto eran añadir funcionalidad a estas herramientas para lograr lo que se necesitaba. Por ejemplo, hay (caros) plugins para Word que añaden "orientación a requisitos", permitiendo, por ejemplo, versionarlos. En las tareas del Project habría que meter los códigos de los requisitos. En los commits de código, los códigos de las tareas... Trabajo, trabajo, trabajo. Al final, se abandonaba.
El problema era de planteamiento. Es inutil forzar el uso de herramientas para un fin ajeno a los objetivos del implicado: al programador no le da ningún beneficio el esfuerzo extra de añadir el código de la tarea. Al analista, el uso de herramientas más complejas que el word le supone también más trabajo. El gestor del proyecto probablemente no tiene ni tiempo ni ganas de actualizar o comprobar el diagrama de gantt...
La solución ha venido de forma conjunta a la adopción de técnicas ágiles y el cambio de herramientas integradas. Las tareas se añaden en el gestor de incidencias (Trac en nuestro caso). Esto, de paso, soluciona el problema del versionado. Además, al ser información estructurada, al estar en una base de datos, se pueden generar informes y vistas en función de las necesidades. Al programador se le da el Eclipse con Mylyn, que le da valor añadido. Indicar la tarea en la que está trabajando no sólo no es trabajo (hacer un click en ella), sino que le aporta valor añadido, ya que el entorno recuerda el contexto (la perspectiva, las vistas, los ficheros abiertos...), haciéndole más fácil alternar entre tareas. Al final, en el gestor tenemos los requisitos (con su histórico) y podemos ver el código relacionado.

¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.

Posted by Juan Ignacio Sánchez Lara 20:11 Enlaces a esta entrada  



Calidad de Código

Practiques Integración Contínua o no, creo que tus scripts de compilación deberían ejecutar también unas cuantas herramientas de calidad de código. En mi opinión este tipo de herramientas es útil tanto para controlar (y mejorar) la calidad del código en sí como para formar al equipo en una mentalidad de mejora contínua.
Yo acabo de integrar las siguientes (y la lista probablemente siga aumentando):

A esto hay que añadir que Hudson integra también el seguimiento de las tareas abiertas (TODOSs, FIXMEs, etc) que también es fundamental.

¿Qué otras herramientas utilizáis?

Posted by Juan Ignacio Sánchez Lara 11:55 Enlaces a esta entrada  



Informática Corporativa

En muchas organizaciones, y muy notablemente en la Administración, se viene creando un departamento (o movimiento, o tendencia, o normativa...) de "Informática Corporativa". Procede de que la organización crece horizontalmente y la informática, que es transversal (ya que afecta y se desarrolla en todos los departamentos), se vuelve heterogénea en la organización. Esta heterogeneidad es vista como algo negativo, ya que en apariencia aumenta los costes:

  • El personal es menos flexible, ya que un especialista en la tecnología de un departamento puede no serlo para otro.
  • Los recursos hardware son menos versátiles, ya que las aplicaciones desarrolladas en un departamento no son desplegables en otro.
Para dar forma a esta informática corporativa se establecen unos procedimientos (casi siempre a medida, síndrome NIH) que dan lugar a una arquitectura común para los desarrollos.
Esto, visto desde el punto de vista funcional, desde la organización se pretende interpretar como algo fantástico: durante uno o dos (o más) años estudiamos las tecnologías disponibles, para seleccionar la más mejor, especializarnos en ella, y utilizarla para todo.
En la práctica, lo que sucede es que las organizaciones tardan dos años en seleccionar una tecnología que ya está obsoleta para cuando se implanta por primera vez, y se pelea contra ella durante años. Los errores cometidos durante el estudio (todos nos equivocamos) en vez de solventarse se parchean, para mantenerse de forma supuestamente ortodoxa en la normativa. El personal de toda la organización se especializa (en el mejor de los casos) en herramientas que carecen de interés en muy poco tiempo, y se estancan en ellas. Por tanto, todo intento de cambio se percibe como una amenaza, una intromisión en su trabajo. Además, como la arquitectura se convierte en normativa, se prohíbe la instalación en la red interna de todo aquello que se salga de ella.
La informática cambia con mucha frecuencia. Y, aunque no cambiase, no hay balas de plata. Intentar hacer norma de una tecnología es una locura: no hay nada que sirva para todo (ni en metodologías ni en herramientas) y lo menos malo para todo lo es hoy pero no mañana.

No me gusta señalar problemas sin proponer alternativas. ¿Solución? Normaliza el cambio:
  • Establece una política de formación que permita que la gente no sólo se recicle periódicamente, sino que también evolucione constantemente.
  • Haz una revisión tras cada proyecto para analizar los puntos positivos y negativos.
  • Haz un estudio de viabilidad real, en el que de verdad se estudien alternativas de implementación.
El cambio es bueno. ¡Esto no significa que cada mes tengas que hacer las cosas de forma diferente! Si tienes gente formada, y haces un estudio de viabilidad real, el cambio surgirá de forma progresiva y natural: se irán incorporando cosas nuevas, se sustituirán componentes mejorables... Incluso los "cambios radicales" (piensa en un primer proyecto con Python en vez de J2EE) parecerán normales, ya que, en el fondo, los conceptos son los mismos.

PD: mañana tengo que trabajar en mostrar que un cambio es positivo, ¡deseadme suerte! ;)

Posted by Juan Ignacio Sánchez Lara 21:56 Enlaces a esta entrada  



X enlaces de esta semana

Unas cuantas cosas que me han llamado la atención esta semana:

La LOPD y el Cloud Computing

Interesante artículo sobre las implicaciones legales de externalizar los datos.

100 Interview Questions for Software Developers

Preguntas que debes hacer (o para las que te debes preparar) en una entrevista de trabajo.

Getting ready for the cloud

Desplegar una aplicación Java existente en Amazon EC2.

Posted by Juan Ignacio Sánchez Lara 11:49 Enlaces a esta entrada  



Buenas prácticas: Tratamiento de Excepciones

Entrada rápida que resume algo que ya he escrito en otros sitios, y que me gustaría tener público (¡y recibir comentarios!).

Criterios a tener en cuenta al tratar excepciones en Java:

  • Es mejor que la aplicación falle a no saber que ha fallado (y qué ha fallado). Corolario: si no vas a tratar una excepción correctamente, mejor no hagas nada y que la aplicación falle.
  • Siempre que se produzca un error en la aplicación tiene que haber información sobre el error en pantalla, al menos indicando que se ha producido un error. Corolario: no te limites a trazar el error en el log, ¡no siempre habrá alguien mirando!
  • No traces mediante System.out o System.err, utiliza un sistema de logging.
  • Si sólo vas a relanzar la excepción, no la relances, haz que el método lance ese tipo de excepción.
  • No loguees y relances constantemente, no es necesario. Los únicos puntos que no deben lanzar excepciones son los métodos invocados directamente por la aplicación, para que no le llegue al navegador la traza del error. Y si utilizas un framework que gestione bien las excepciones (como Seam), incluso puedes saltarte esta norma.
  • Cuando escribas en el log, escribe información significativa, como los parámetros recibidos por el método. Lo trivial (el nombre del método, por ejemplo) ya se verá en la traza.
  • Al trazar, no concatenes el mensaje de la excepción, vuelca la excepción en sí (toda la traza).
  • Un método no debería declararse como throws Exception, ya que enmascara todas las excepciones, sin permitir gestionar el error concreto. No pasa nada, por ejemplo, por que lance varias: throws IOException, MiOtraException. De esta forma, el que la invoque sabrá a qué tipos de error se debe enfrentar.
Contraejemplos (ejemplos de cómo no se deben hacer las cosas):
  • } catch(Exception e) { }; : se ocultan los errores, es imposible saber qué ocurre.
  • } catch(Exception e) { System.err.println(e) }; : estamos trazando en err, ni se ve nada en pantalla ni en el log, así que en explotación no sabremos qué ocurre.
  • } catch(Exception e) { log.debug("Ha ocurrido algo malo: "+e); }; : el nivel de log es incorrecto (debería ser error), no se dan datos sobre el error, estamos concatenando la excepción, no estamos relanzando...
  • } catch(Exception e) { log.error(e) }; : no se dan datos sobre el error, y no estamos lanzando nada, así que en pantalla no se verán los errores.
Ejemplos válidos en otras circunstancias:
  • } catch(Exception e) { log.error("Identificador: "+id, e); throw new MiExcepcion(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, lanzamos una excepción (que contiene la provocada, para no perder traza) para que el nivel superior pueda seguir tratando el error. Esto sería incorrecto, de todas formas, si en nuestro sistema esto vuelca la traza en el interfaz de usuario. Aparte, probablemente incluso sea innecesario hacer esto (ver último ejemplo correcto).
  • } catch(Exception e) { log.error("Identificador: "+id, e); anhadirMensajeDeErrorAlUsuario(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, mostramos un mensaje de error en pantalla. Esto sería incorrecto, de todas formas, si este método es invocado por un nivel que necesita procesar el error específicamente.
  • ...) throws IOException : si el método no va a hacer nada interesante con la excepción, ¿para qué capturarla?
Actualización 0901131738: este es un tema del que se pueden encontrar infinidad de fuentes, como en java.net, con más detalle, en inglés.

Posted by Juan Ignacio Sánchez Lara 16:04 Enlaces a esta entrada  



Dos enlaces de esta semana

Uno de morralla comercial y otro de programación:

SOA ha muerto. Larga vida a los servicios

¿Qué significa "SOA ha muerto"? ¡Nada! Lo único que consiguen grupos como Burton con declaraciones como estas es cambiar las conversaciones de enteradillos que los directivos que no saben de qué están hablando mantienen entre reuniones. Igual, siendo malpensado, consiguen también redirigir inversiones: ya han conseguido vender su consultoría acerca de SOA, ahora tienen que conseguir vender otra, y ya sabemos que este es el año del Cloud Computing...

Lead developer, Are Yoy Mentoring?

Un buen artículo sobre cómo reintegrar a un programador negativo. En vez de quejarse, tener iniciativa, preguntarle, utilizar herramientas de análisis estático...

Posted by Juan Ignacio Sánchez Lara 9:40 Enlaces a esta entrada  



Introducción a Seam

Como apoyo para una próxima sesión de formación he preparado una modesta presentación/resumen de lo que es Seam, muy por encima. Las principales fuentes son el manual de referencia y "Seam in Action", así que si quieres conocerlo en profundidad, nada como las fuentes originales, mucho más detalladas y sin mis gazapos (ni tonterías de mi cosecha ni relación con trabajo previo mío).

Posted by Juan Ignacio Sánchez Lara 22:19 Enlaces a esta entrada  



Reseña: Peopleware

Peopleware es otro de esos clásicos que todos los informáticos deberíamos leer. Es un libro atípico, porque habla de la Ingeniería del Software en términos de personas, sentimientos, emociones...

A continuación, la tabla de contenidos con el argumento de cada capítulo.

Contenido del libro
Parte I: La gestión del recurso humano
El software lo desarrollan personas, no máquinas, adecuemonos a eso.
Capítulo 1: En algún lugar, en este momento, un proyecto va a fracasar
Los proyectos software fracasan, principalmente, por cuestiones sociológicas, no técnicas.
Capítulo 2: Haz una hamburguesa de queso, vende una hamburguesa de queso
El desarrollo de software es inherentemente diferente de la producción (industrial). Es un error aplicar técnicas de producción (pensar en las personas como máquinas) al desarrollo.
Capítulo 3: Vienna waits for you
(Dejo el nombre del capítulo en inglés por ser un extracto de una canción de Billy Joel, 'Stranger'.)
Más horas de trabajo no implica ni más ni mejor trabajo, para las personas el trabajo no es lo más importante. La adicción al trabajo es un problema.

Capítulo 4: Calidad - si el tiempo lo permite
Comprometer la calidad no es una buena estrategia: mina la auto
estima
de la gente.
De hecho, a la larga una mayor calidad redunda también en una mayor productividad.
Capítulo 5: Revisión a la Ley de Párkinson
No es cierto que el trabajo de desarrollo se expanda hasta abarcar todo el tiempo disponible para él.
Capítulo 6: Laetril
No existen los remedios mágicos ni las soluciones que multiplican la productividad.

Parte II: El entorno de la oficina
Factores externos a las personas que afectan a la productividad.
Capítulo 7: La política de mobiliario
Las políticas de mobiliario no parecen estar pensadas en pro de las personas (y, por tanto, tampoco de su productividad).
Capítulo 8: "Es imposible hacer nada aquí de 9 a 5"
Factores como el ruido o el espacio están más correlacionados con la productividad que la experiencia o el lenguaje de programación.

El capítulo 8 expone datos muy interesantes sobre un estudio que los autores han realizado durante años. Dan un ejercicio a dos candidatos de cientos de empresas, y relacionan los resultados con factores ambientales.

Capítulo 9: Ahorrar dinero con el espacio
La cantidad y calidad del espacio para el trabajador es fundamental.
Interludio
: Medición de la productividad y OVNIs
Medir la productividad es difícil, pero puedes medir algo que al menos te permita saber tu posición respecto a la competencia.
Capítulo 10: Tiempo mental contra tiempo de cuerpo presente
Para que el tiempo se aproveche al máximo el cerebro debe entrar en un estado llamado "de flujo", al que cuesta llegar pero del que es muy fácil salir por culpa de interrupciones. Para maximizar la productividad hay que maximizar la proporción de "tiempo de flujo" respecto al "tiempo de cuerpo presente".
Capítulo 11: El teléfono
Un mundo sin teléfono sería algo fantástico, pero como no parece posible, hay que conseguir minimizar el impacto de las llamadas: silenciar el timbre (o al menos bajar el volumen), utilizar sistemas alternativos, etc.
Capítulo 12: El retorno de la puerta
El entorno de oficina tradicional, de dos, tres o cuatro personas, con paredes y puertas, se ha perdido, equivocadamente, en favor de entornos diáfanos, con mucho ruido y sin privacidad.

En este capítulo se expone un interesante estudio sobre la música y el trabajo. Si bien la parte lógica/matemática del trabajo no se ve afectada, la parte creativa se ve anulada si estas escuchando música.

Capítulo 13: Realizando pasos de paraguas
Nota: para los curiosos, podéis consultar el significado de 'paso de paraguas' ('umbrella step'), que no tiene traducción directa.
En este capítulo se exponen varios conceptos de arquitectura y decoración de interiores para hacer un mejor entorno de trabajo: situación de las ventanas, de los muros, de los espacios compartidos... El resumen más correcto, aunque impreciso, sería decir que "hay que construir como se lleva haciendo desde hace miles de años".


Parte III: La gente correcta
Cómo (y por qué) conseguir a los mejores, mantenerlos, y aprovecharlos al máximo.
Capítulo 14: El factor Hornblower
Nota: 'Hornblower' aquí se refiere a Horatio Hornblower, protagonista de una serie de novelas de C.S.Forrester sobre las guerras napoleónicas.
La gente es diferente, y eso es bueno. No hay que potenciar la similitud y la entropía, sino todo lo contrario. A menor entropía (entendida como igualdad), más trabajo hecho.
Capítulo 15: Contratar un malabarista
En las entrevistas de trabajo no basta con preguntar a los candidatos, hay que ver sus habilidades en la práctica.
Capítulo 16: Feliz de estar aquí
El coste de la rotación es muy elevado (más de 5 meses de trabajo), hay que conseguir mantener a la gente que la gente quiera quedarse.
Capítulo 17: Sistema autoreparable
Cuando se automatiza un sistema humano, por ejemplo al aplicar una Metodología, se pierde gran parte del valor humano. Concretamente, cuando el valor de una Metodología es hacer algo uniforme, mejor sería conseguirlo mediante formación, herramientas, y revisión por parejas.

Parte IV: Crecer equipos productivos
Nota: he traducido 'growing' como 'crecer', aunque no suene demasiado bien, para mantener la metáfora agrícola.
Ya tienes la gente, ahora tienes que hacerla trabajar en equipo.

Capítulo 18: El todo es más que la suma de las partes
Tienes que conseguir hacer que el equipo esté totalmente cohesionado en pos de un fin común.
Capítulo 19: El Black Team
El Black Team es el paradigma de equipo cohesionado. Fue un equipo de testers de IBM, temido por los desarrolladores por su eficacia, aún cuando todo el equipo inicial había cambiado.
Capítulo 20: "Equipocidio"
No es fácil determinar qué debes hacer para conseguir un gran equipo, pero sí hay varias cosas que no debes hacer: gestión defensiva, burocracia, separación física, fragmentar el tiempo de la gente, reducir la calidad del producto, establecer hitos imposibles y control de camarilla.
Capítulo 21: Cena de espagueti
El mejor jefe es aquel que consigue gestionar sin que parezca que hace nada.
Capítulo 22: Open Kimono
La mejor gestión es aquella en la que se confía plenamente en los miembros del equipo y en la que la autoridad se ejerce de forma natural, no mediante imposiciones.
Capítulo 23: Química para la formación de equipos
Para que una organización siga una estrategia correcta de formación de equipos, debe cuidar lo siguiente: culto a la calidad; proporcionar realimentación positiva; sentimiento de élite; alentar la heterogeneidad; preservar los equipos exitosos; proporcionar dirección estratégica, no táctica.

Parte V: Debería ser divertido trabajar aquí
El trabajo no debería ser algo aburrido, una carga, algo negativo... Debería ser divertido, interesante, enriquecedor...
Capítulo 24: Caos y orden
La tendencia natural en el trabajo es ir hacia el orden, pero introducir deliberadamente elementos novedosos, aumentando el caos, disminuyendo así la entropía, es positivo.
Capítulo 25: Electrones libres
Hay gente que no encaja en puestos específicos, pero que aportan gran valor a la empresa. No siempre es necesario regirse por estrictas jerarquías.
Capítulo 26: Holgar Dansk
Introducir los cambios parte de la iniciativa individual. Si algo es sensato, hazlo, que será más fácil de lo esperado, encontrarás ayuda.

Valoración personal
Peopleware es un libro excepcional. No se limita a obviedades, y no se limita a exponer problemas. Entra en muchos temas en profundidad, incluso aportando datos concretos, y aporta soluciones (por ejemplo, enumerando alternativas al uso de Metodologías). Es un libro imprescindible, que nunca envejecerá, y útil no sólo para jefes. Provocador y agitador a todos los niveles. Hay muchísimas cosas aplicables constantemente. Yo ya me estoy haciendo una lista...

Posted by Juan Ignacio Sánchez Lara 17:40 Enlaces a esta entrada  



WTF como ejercicios en entrevistas y en formación

A estas alturas del año ya habréis visto el código responsable del cuelgue masivo de los Zune:

    while (days > 365) {
if (IsLeapYear(year)) {
if (days > 366) {
days -= 366;

year += 1;
}
} else {
days -= 365;
year += 1;
}
}
Este código no creo que entre en la categoría de WTFs, a todo el mundo se le puede patinar un igual. Sin embargo, me viene de perlas para uno de los trabajos que voy a tener en los próximos días: preparar ejercicios de programación para formación y contratación (¿por qué será que recruiting me parece más preciso?). En un post anterior en el que hablaba de mi opinión sobre la aptitud y actitud profesional, Julio César Pérez comentaba lo siguiente
La pregunta estrella era implementar una funcion recursiva que calculara el factorial de un numero entero en cualquier lenguaje. Sólo el 10% la hicieron bien y todos los candidatos eran como mínimo ingenieros.
Ya me habían mirado raro a veces por opinar que las entrevistas hay que orientarlas en ese sentido, pero desde que supe que Google pide programar en una pizarra me he sentido reafirmado: las entrevistas deben ser prácticas.


Contexto
Trabajo en un entorno parcialmente universitario, por lo que una de nuestras razones de ser es la ocupación de estudiantes, con las ventajas e inconvenientes que esto conlleva.

Requisitos
Necesito una forma de...
  • poder evaluar en una entrevista de trabajo los conocimientos (si hablamos de gente con experiencia) o la aptitud (si hablamos de becas) de una persona.
  • facilitar la autoformación del personal, nuevo o no, que se va a incorporar a proyectos con nuevas tecnologías.
Alternativas de implementación
  • Para las entrevistas, recopilar una serie de WTFs y trozos de código, tanto correctos como no, y preguntar al entrevistado por ellos.
  • Para la formación, plantear ejercicios cortos con tareas de no más de una o dos horas, en el que se busque escribir código lo más impecablemente posible. Una vez completado el ejercicio, alguien revisaría el código escrito para pulir entre los dos todo lo mejorable.
Esto último de la revisión, aunque algo exigente (ocupa a dos personas en código de prueba) me parece fundamental. En mi opinión, pensar que una persona aprende a programar símplemente programando es falso. Conozco gente que programa mal y lo seguirá haciendo toda su vida, porque ni lee código de otros, ni libros, y nadie le corrige sus errores. Especialmente en entornos de formación, la figura del revisor me parece fundamental.
  • Calidad de código en el motor de integración contínua como formación: tanto instalar plugins de Eclipse como generar informes de calidad de código pueden ser positivos para aprender. Si se presta atención a los warnings de FindBugs, PMD o Metrics se puede aprender mucho (¡a la vez que mejoras la calidad!).
PD: aquí, al hablar de "código WTF" me refiero a código con una elevada medida de "WTF" como en la siguiente viñeta:

Posted by Juan Ignacio Sánchez Lara 8:28 Enlaces a esta entrada