El malo de la película

Así es como me siento. Soy el malo de la película cuando me reuno con mis socios, me cuentan los pormenores del nuevo proyecto y las maravillas que se quieren implementar. Soy el malo de la película cuando los veo tan sonrientes y emosionados, y yo no puedo más que poner cara de circunstancia y decirles: “buff, no creo que todo eso salga en tan poco tiempo” o “buff, para poder hacer eso, tendríamos que retocar el modelo de datos y reestructurarlo todo”.

Ellos saben que adopto esta postura por posicionarme en el lado más realista que puedo, aunque se podría entender que es ya una deformación profesional.

De todas formas, no me siento mal por ello. Tengo asumido que debo trabajar siempre situándome en dos perspectivas diferentes: el lado del usuario y el del programador. Ellos lo hacen sólo desde el lado del usuario y conocen bien esa parcela; lo que es vital para el usuario, cómo y qué se debe permitir personalizar, etc.

Supongo que no soy el único que se siente así en esta situación. Sólo quería expresar mi parecer.

Almacenamiento sin esquema.

Leo en digitta.com la traducción de una entrada del blog de Bret Taylor de FriendFeed. En ella se explica cómo han implementado un sistema de almacenamiento sin esquemas en una base de datos MySQL. La cuestión consiste en tener en una tabla un campo id, en su caso un UUID de 16 bytes, y un campo MediumBlob en el que se almacenen los datos sin esquema, formateados como objetos JSON o diccionarios de Pyhton:

{“Cod”:33423,“Nombre”:”Juan”,”Profesion”:”conductor”,”Nacionalidad”:”española”}

Si se desea indexar por estos campos-propiedades, se usará una tabla por cada campo por el cual se vaya a indexar. De esta forma, si se desea añadir o eliminar índices, basta con crear o eliminar la tabla correspondiente.

No voy a profundizar demasiado. Se pueden ver más detalles acerca de la implementación en el propio post. Lo que me llamó la atención, aparte de la sencillez del sistema tanto para implementarlo como para mantenerlo, fue la razón que les llevó a implementarlo: Hay muchos proyectos diseñados para abordar el problema (alto crecimiento y constantes cambios en el esquema) almacenando los datos con esquemas flexibles y construir nuevos índices al vuelo (por ejemplo. CouchDB). En cualquier caso, ninguno de ellos parece lo suficientemente utilizado por sitios grandes como para inspirar confianza.

Bien, intentaré hacer mi propia implementación de un sistema similar y si puedo, publicaré los resultados al respecto.

Carga y proceso de datos externos. Alternativas al XML.

Interesante el experimento que ha llevado a cabo Andrés Nieto, destinado a evaluar los tiempos de carga y procesamiento de datos externos, por medio de javascript. Las opciones evaluadas para la transferencia de los datos son archivos en formato XML, JSON y texto plano. Curiosamente, fueron estos últimos los que dieron unos tiempos más ajustados, aunque en dura lucha con JSON. Sin duda alguna, con estos resultados, se nos abren nuevas posibilidades a la hora de enviar nuestros datos al navegador de forma asíncrona. Incluso, por lo visto, Flickr lleva algún tiempo considerando esta posibilidad, obteniendo tiempos más que aceptables (10.000 resultados en menos de 20 milisegundos).

Ahora, la duda que me viene a la cabeza es si estos resultados se mantienen cuando la transferencia se establece entre dos servidores, por ejemplo cuando consumimos un webservice y es, desde el lado del servidor desde donde procesamos los datos transferidos. Y si es así, ¿no deberíamos plantearnos la conveniencia del XML para el transporte de datos, aún siendo éste el estándar para la comunicación entre aplicativos?