Agile Open Spain, Octubre 2009, Madrid

En Agile Spain han anunciado el Agile Open Spain un evento que promete ser muy interesante. Me permito copiar de su página web:

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid.

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

España no destaca por la cantidad de eventos independientes relacionados con el agilismo, así que esta se me antoja como una oportunidad muy buena para aprender, compartir y conocer experiencias, hacer networking, y en definitiva empaparse de todo lo que el agilismo puede ofrecer.

Podéis ver la localización aquí e inscribiros en el evento desde este enlace. El evento es gratuito y las plazas son limitadas.

Centros de datos

Me encanta. Siempre genial...



El original aquí.

Sharding, ¿sí o no?

Facebook, Digg y muchos otros utilizan una técnica denominada Sharding para escalar.

El Sharding es una técnica que consiste en particionar los datos de tu base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento más rápido. Una agrupación típica puede ser por id por ejemplo: "los usuarios del 1 al millón están en esta base de datos"; o por nombre "los usuarios cuyo nombre va de la A a la E" están en esta base de datos".

Típicamente estos shards, agrupaciones o segmentos estarán localizados en tablas en diferentes bases de datos y localizaciones físicas. El Sharding no tiene por qué estar basado únicamente en una tabla y una columna, puede ser a nivel de todas las tablas. Por ejemplo podríamos decir "todos los datos de usuarios cuyo perfil está en los Estados Unidos los redirigimos a la base de datos del servidor en Estados Unidos, y todos los de Asia van a la base de datos de Asia".

El Sharding como tal mejora la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas por lo que los accesos serán mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, el basar el Sharding en la localización geográfica permite también disminuir considerablemente la latencia.

¿Cuándo se necesita hacer Sharding? Principalmente cuando el volumen de datos comienza a ser inmanejable. A tablas más grandes, más lentos son los accesos. No es lo mismo acceder a una tabla de diez mil usuarios que a una tabla de diez millones de usuarios. También comentan en el blog del que hablaré en breve que es bueno hacer Sharding cuando el volumen de escrituras es demasiado grande para un único servidor. En bases de datos, escrituras=bloqueos, bloqueos=contención de recursos, contención de recursos=mala experiencia de usuario, a parte del problema con la sincronización con slaves.

Todo esto viene a cuento de que en el blog de rendimiento de MySQL nos advierten de por qué no deberíamos hacer Sharding prematuramente. El problema principal es que Sharding se ha convertido en una palabra de moda. A fin de cuentas, si Facebook lo hace, ¿por qué no lo voy a hacer yo? Pues porque yo no tengo 120 millones de usuarios activos, ¿quizás?

Mi opinión es que en general estoy de acuerdo con el no hacer Sharding desde el principio, pero sólo si este va a impactar en la estructura de la base de datos. Es decir, dividir los usuarios de la A-E, la F-M, ... etc. a bote pronto parece como una mala decisión, al menos sin saber si vamos a tener cien usuarios o cien mil.

Pero planificar para Sharding no siempre tiene por que ser una mala decisión. En Java por ejemplo hay herramientas que nos lo facilitan. En general, el particionar por aplicación o por país además no son decisiones demasiado relevantes y que no tienen porque impactar el desarrollo en sobremanera, al tiempo que en el futuro facilitan enormemente la escalabilidad del servicio. Eso sí, hay que tener claro que a mayor número de shards mayor mantenimiento. No es lo mismo actualizar un índice en una tabla que hacerlo en cinco, especialmente porque al hacerlo en cinco es más fácil el dejarse uno olvidado.

Mi CV

Los que seguís este blog ya sabéis que ando metido en Jobsket, y a ello estoy dedicando mis esfuerzos. Jobsket es la razón por la que quizás no estoy actualizando tan a menudo como debiera.

De hecho, en los dos en los últimos dos meses hemos trabajado tanto que apenas he tenido tiempo para bloggear. Dos meses y dos releases. La última la hemos anunciado hoy y viene con muchos cambios. Uno de ellos, y que a alguien quizás le interese es la posibilidad de incrustar tu CV en la web al más puro estilo scribd, docstoc y demás.

Aquí os dejo mi CV.

También ofrecemos otras formas de promoverlo como el CV en miniatura que se ve en este blog a la derecha, o un par de iconos de promoción nuevos que hemos añadido, además de poner "bookmarkearlo" en facebook, twitter, friendfeed y similares.

Así que nada, si queréis tener vuestro CV en su formato original en vuestra web para promoverlo o lo que sea, ya sabéis, sólo tenéis que registraros en Jobsket :)