Etiquetas

, , ,

La semana que viene tenemos la Menorca Techtalk organizada por Martín Varsavky. La lista de invitados de todo el mundo acojona bastante. Como hay una reunión en plan non-disclosure –no se permitirá ni bloggear, tomar fotos ni grabar lo que se hable allí– para presentar los proyectos individuales y pedir opinión y ayuda a los demás decidí presentar una prueba de concepto de mi vaporcito (comenzará como proyecto interno del Menéame, si no muere antes). Espero poder llegar, al menos con una versión mínima.

Teníamos problemas importantes de temas de “tiempo real” –más estrictamente, lograr bajas latencias–, escalabilidad, base de datos distribuidas y rápidas, etc.. Por eso se nos hacía muy difícil comenzar sin una financiación importante –que no conseguí–, pero Google App Engine de golpe nos soluciona gran parte de los problemas de plataforma. Ahora ya no nos hace falta grandes financiaciones ni resolver los problemas que ya lo tiene muy resuelto Google, además el lenguaje elegido fue Python, así que ya no había excusas para no intentarlo.

Hace unos días decidí que debía preparar una prueba de concepto que tendría múltiples objetivos, probar la plataforma, encontrar sus problemas y limitaciones, y pedir la opinión de los expertos –técnicos y de negocios– que estarían en Menorca.

Le dí muchas vuelta al tema de Django versus Google App Engine, la verdad es que el segundo es muy simple –con una curva de aprendizaje quizás más plana– pero también tiene sus limitaciones importantes, una de ellas, la más costosa y coñazo de implementar, es la gestión de usuario. Con Google es muy fácil, siempre y cuando estén dados de alta en Google😦

De todas formas veía que Django en Google App es bastante complicado y aporta muy pocas ventajas, ya que el módulo de usuario y admin no puede ser usado por la incompatibilidad del modelo de datos, así que decidí hacerlo con Google App Engine pero intentando que por diseño y programación sea fácilmente portable a Django si hiciese falta.

Y allí me encontré con el problema.

Recién estoy aprendiendo y probando Google App, aunque pasé decenas de horas leyendo y casi estudiando todo lo que hay en Internet sobre el tema, debo decir que soy un completo n00b. En cuando a Python, sí, lo conozco, pero no soy un hacker Python y todavía me falta bastante para ser experto en el lenguaje –por ejemplo poder programar un par de horas sin necesidad de recurrir a la documentación–

Aquí viene lo que acabo de re-descubrir por enésima vez, aunque la edad debe también hacer mella. Es  imposible hacer un buen diseño sin conocer perfectamente la plataforma sobre la que se desarrolla.

Puedes saber de qué va un MVC, pero cada uno de elos tiene sus particularidades, Django y Google App tienen además sus “manías” –al igual que Rails– que hay que conocer. Puedes saber muy bien la teoría y arquitectura de bases de datos relacionales, pero cada una de ellas tiene sus manías que afectan a la hora de desnormalizar o crear los múltiples índices necesarios [*] –si es que se puede o no lo empeora aún más– para mejorar el rendimiento en aplicaciones webs –es inevitable–. Pero es que además si programas en Google App Engine (o en Amazon SimpleDB para el caso), olvídate de mucho de lo que preasumes en bases de datos, ni siquiera son relacionales –pero sí son rápidas y distribuidas–.

[*] La base de datos del Menéame tiene –por ahora, espero que dure– 23 tablas y 60 índices diferentes.

A lo que iba, llevo más de una semana en plan diseño, y cada pocas horas –como máximo– tengo que replantearlo y rehacer partes importantes a medida que aprendo algo más de las posibilidades, o de las limitaciones de plaforma+lenguaje.

Hace muchos años que no participo del diseño de  “sistemas tradicionales” y de problemas “bien conocidos” –la última vez que lo hice el estándar era el Gane/Sarson y el waterfall–, pero en sistemas cuya arquitectura es nueva y poco conocida es imposible hacer un buen diseño –más o menos detallado– sin conocerla y haberla experimentado en carne propia: i.e. haber hecho programas que exploren la mayoría de posibilidades. No es sólo que un método iterativo e incremental sea lo recomendable,  no queda remedio.

El que afirme lo contrario miente como un bellaco, no lo ha intentado nunca, es un genio, o yo soy un subnormal😉

Seguramente en tres o cinco años, cuando haya libros de texto –que no pequeños trucos, howtos o apuntes– sobre el tema ya no hará falta la experiencia en primera persona, pero espero que dentro de tres años estemos programando en arquitecturas más flexibles que el Google App o Amazon EC2+SimpleDB.

Además hoy mismo  además experimenté en carne propia la ventaja que los métodos HTTP del REST, sobre todo  GET, sean idempotentes. Lo intuyes, pero hasta que no te das con un martillo en los dientes no estás del todo convencido. Me duele toda la boca😉

Moo

Como no teníamos ni tarjetas para dar –el año pasado hacíamos el ridículo escribiendo teléfonos y direcciones en servilletas– a Benjamí se le ocurrió reunir en una cuenta de Flickr a las fotos que pudimos rescatar de eventos y gentes relacioandos con Menéame y luego encargar las tarjetas a Moo. Quedaron muy chulas, además alegra ver a los amigos en el revés de las tarjetas. Estas son algunas de las que pude poner sobre un folio para sacar la foto:

Tarjetas Moo del Menéame