Alpha's Manifesto

A black and white figure's thought-hive

¿Por qué HTML5?

Hace no mucho se me presentó en una conversación, en donde me encararon con la siguiente pregunta: “Si el estándar de HTML5 no está aprobado aún, por qué usarlo?”. Me abalancé con una respuesta salvaje del estilo “Por qué no?” (aunque con otras palabras) y no dije mucho más. ¿Por qué alguien querría no usarlo? Pasaron 30 segundos desde mi respuesta y me puse del otro lado, pensando en que me estaban hablando de una nueva versión de Windows y ahí creí comprender el punto de vista. Creo que no aplica a HTML5 pero… por qué habría una diferencia?

Fue entonces en donde me puse a dar una respuesta más elaborada, la cual reproduzco a continuación.


HTML5 es algo muy nuevo todavía, y eso tiene sus pros y sus contras.
El contra que todos obviamente vemos ahora es que puede cambiar hasta terminar de definirse, sumado a que tiene poca adopción y (va a tener) bugs en implementaciones en distintos browsers. Sumenlé problemas de seguridad que sin duda se van a venir, backward compatibility no-tan-suave y más temas.

Ahora, qué tiene de bueno? No voy a enumerar lo nuevo {en cuanto a capacidades} porque eso lo pueden leer en cualquier lado.
HTML5 va un poquito más allá de la tecnología que implementa. Se trata de, por un lado, una forma nueva de aproximarse a la tecnología de la web. Por otro lado, de un plan mucho mayor de lograr una mejor estandarización (que comenzó con XHTML 1.0 y siguió con Transitional HTML). Por otro lado más, el efecto que ha tenido sobre la comunidad online demuestra que estamos capaces de acelerar el proceso de estándares (que hoy por hoy, no baja de los 5 o 6 años, cuando las tecnologías nuevas aparecen cada 6 meses).

Déjenme explayarme sobre lo anterior:
– Una forma nueva de aproximarse a la tecnología de la web
HTML5 fue un poco más “democrática” que el resto de los HTMLs pasados, en donde ya la dirección no se lleva adelante por los que están experimentando en el área, sino los que además de tenerlo asimilado, ya aprendieron de los errores pasados y tienen visión del futuro. Cosas como webSockets, canvas, CSS3 3D acceleration (sé que no es HTML5 pero lo meto en el mismo paquete) no hablan tanto de algo que deba ser más fácil de programar, sino de una dirección distinta que va a empezar a tomar la web. Va a tratarse más de contenido multimedia e interacción, no más texto, imágenes y links. Abre otra forma completa en que las aplicaciones van a poder trabajar, y es un campo perfecto para la creatividad, la innovación y el avance. Cuando se asiente un poco el polvo va a venir la nueva revelación basada en esta tecnología. No estoy seguro de qué y no me las doy de visionario, pero es lo que siempre pasa, y a la velocidad que vamos, estoy seguro de que cada vez la revolución va a ser mayor.

– Forma parte de un plan mayor
Hace tiempo que la web viene “rota”, por su cualidad de “forgiving”. Cuando la web empezó había uno y luego dos navegadores. Tan poca variedad hizo que los programadores se educaran de forma terrible, y ambas partes luchaban por definir su estándar. El resultado: que cada empresa de IT tenga que tener un departamento de HTML+CSS porque algo que se suponía iba a poder hacer cualquiera se convirtió en toda una ciencia. Para sumar, el avance exponencial lo hace cada vez más difícil, con lo cual hoy hay activas 5 versiones de Internet Explorer, 4 de Firefox, 3 de Opera, 9 de Chrome, 2 de Safari y no sé cuántas más me estoy olvidando. Los renderizados y capacidades varían de SO a SO (multipliquen por todo lo que dije), y ni hablemos del mundo móvil. Cada navegador se tiene que acomodar a las 5 versiones de HTML que andan dando vueltas, más sus distintos modos. Cada navegador también implementa sus propios “extras”, que se idearon al principio para que los programadores lo eligieran y dijeran “este sitio funciona con Internet Explorer 6” (¿ActiveX alguien?). Eso era marketing: luego la web iba a ser basada en IE. {Eso hoy es inconsistencia cross-browsing.}

Por supuesto, esto es un quilombo {lío}. Todos usaban IE hasta que FireFox y la moda open source comenzaron a tomar popularidad, luego Google Chrome y la promesa de hacer todo más liviano, más rápido y ellos “apoyando y promoviendo” los estándares, hizo que el mercado se distribuyera mucho.

Programar en HTML y hacerlo “aceptable” en todos lados es complejo también, porque los navegadores se bancan {soportan} todas las formas de hacer cosas, y nosotros tenemos que ajustarnos a ellas para que nuestra nueva página haga lo que queremos. Hoy esto es una traba a la innovación y a la mejora, porque lo que tiene que ser simple es un infierno.

El fallback de HTML5 es HTML4 y se planea en un futuro (lejano) volverlo {al HTML} tan estricto como el XML (de hecho, un schema definido por el mismo), lo cual va a significar: menor cantidad de estándares, mejor performance de los navegadores, menos ambigüedad de implementaciones, más soporte y más acogimiento de distintas plataformas y usuarios. Si piensan que HTML es una regla definida en texto, está realmente muy difícil entender por qué esto no fue así antes. (Excepto que se lean la historia de los párrafos anteriores.)

Por supuesto, proponer algo así hoy está condenado al fracaso, por algo simple: nadie lo va a hacer, y nadie va a tirar a la basura la internet que tenemos hoy. Esos pasos graduales (que cada vez van más rápido) lo van a lograr. Lo mismo se hizo con IPv4 vs IPv6, que casi llega al final de sus días (y hablamos de algo que tuvo unas buenas décadas para llevarse a cabo).

– Acelera el proceso de estándares
Ahora que el UX está en su auge, el entrepeneurship es una palabra (sí, también me sorprende), Microsoft se quiere redimir, Google está en la lucha, y la comunidad misma es la que presiona por todo esto, todo se aceleró. Cuando propusieron HTML5, Google Chrome ya soportaba cosas a la semana. {Nota: Esto no es históricamente correcto. La expresión denota la velocidad con que se adoptaron los cambios.} Si algo cambiara, ellos lo cambian al toque. Se ganaron el corazón de los desarrolladores y de a poco mercado con eso. Es la misma historia, pero ahora sin la burocracia de ir contra un estándar, sino al contrario, presionar para que el estándar se consolide.

Y esto es bueno porque todo lo que conté antes va a ocurrir más rápido. En definitiva, nuestras capacidades en la web no van a ser imposibles por la arquitectura cliente-servidor a la que estamos acostumbrados, sino que pronto van a venir cosas que nos van a permitir esa revolución.

Y si yo estoy desarrollando un producto, ¿por qué me importa todo esto?
Si sos alguien a quien le importa la tecnología y tenés tu pasión en ella, ya tuviste tu respuesta.
Si sos alguien que solo quiere vender un producto, o un cliente al que le tengo que convencer de usar tecnología nueva, la razones son las siguientes:

  1. Si tenés un target determinado, podés forzar a que usen el navegador que mejor soporten lo que quieras, y hacer uso de las nuevas capacidades. Sistemas más limpios, más seguros, y que luego solitos van a funcionar con el resto de los navegadores.
  2. Si tu target es público en general, también te genera buena reputación estar sobre la cresta de la ola. Hay un mundo de apasionados y programadores que te van a mirar por cómo hiciste las cosas y no por lo que hiciste en sí (aunque claro, son la minoría). Si tu target es técnico, más interesante aún.
  3. Si te importa la experiencia del usuario, hay cosas nuevas que podés lograr que de otra forma no podés. No todos van a poder experimentarlo hoy (por la compatibilidad), pero los que sí son visitantes ganados.
  4. Cuando esta nueva tecnología se abra paso a más caminos, la ola te lleva sola sin ningún esfuerzo extra. Ejemplo: video HTML5 hizo que quienes adoptaron HTML5 llegaran al mundo móvil con multimedia. Los que se hicieron los cancheros diciendo “ya lo hicimos en Flash” se habrán enterado que esta semana Adobe anunció que abandona Flash para los móviles. Cuántos proyectos habrá que volver a tocar. Dicho sea de paso, yo pienso que Java (en web) va por el mismo camino.
  5. Last, but not least, si alguien se va a comprar un teléfono hoy, se compra un teléfono de los nuevos. Es lo que le vende y lo que mejor le va a andar hoy y mañana. Hacer un proyecto no es tan distinto, hay que usar lo nuevo para que dure más y funcione mejor hoy y mañana. Mejor aún: no hay diferencia de costos entre HTML4 y HTML5. ¿Por qué no elegir el mejor?

Link del día: Arquitectura CSS

La idea me parece fantástica, pero la forma en la que se desarrolló, no tanto. La idea era, Scalable and Modular Architecture for CSS, una organización del código CSS de una aplicación para que fuera dividido en forma modular. De esta forma, habría determinados estilos base, y otros estilos pertenecientes a módulos que especificarían cosas extra, o modificarían detalles (aunque no deberían) de los estilos base.

Ahora, los estilos base se subdividen, a su vez, en estilos que tienen que ver con el layout, y los que no se llaman “base”. Por último, hay una cuarta clasificación que tiene que ver con estilos de estados, es decir, cuando algo está activado, cuando se encuentra deshabilitado, etc.

Si bien la idea está muy interesante, veo algunos puntos grises en cuanto se debe determinar qué estilo pertenece a qué. Hay reglas CSS particulares que van a ser seguramente pertenecientes a una de las anteriores categorías mientras otras no, pero podemos estar hablando de los mismos elementos en pantalla. Para poder lograrlo de forma precisa, debería tenerse demasiado cuidado y una gran cantidad de reglas que aplicarían a un determinado elemento. En ese sentido no se me hace demasiado natural, aparte de la necesidad de marcar de múltiples formas un mismo elemento (un id, varias clases).

Sin embargo, me parece un muy buen comienzo, y quisiera escuchar ideas, porque creo que esta arquitectura es una base muy poderosa para hacer de CSS complejo algo muy ordenado.

Soy un zorrinito estilizado.

CQRS

Estuve leyendo un poquito últimamente sobre CQRS, que significa Command-Query Responsibility Segregation en inglés (sería “Segregación de responsabilidades de commands-queries” en español, ahora explicaré). No he encontrado una buena y corta explicación al respecto así que aquí va mi intento:

¿Qué significa?

Llamaremos Command (comando) a cada operación en nuestro sistema que impactará el estado de la aplicación. Esto significa, cualquier acción que vaya a llevar un cambio en nuestros datos. (Recuerden, el comportamiento puede ser modelado como datos también, pero podemos considerar estos casos como un subconjunto de las situaciones de las que estamos hablando.) Por ejemplo, agregar un usuario, eliminar una tarea, cambiar un registro o actualizar los permisos pueden ser vistos como commands. Si están familiarizados con el patrón de diseño Command, pueden pensar que esta es la forma correcta de representar estas acciones. La idea encaja correctamente, pero estamos hablando de un modelo arquitectural aquí, así que aunque parezca natural usar este patrón, no es realmente necesario.

Llamaremos Query a cada operación que lea de nuestros datos para devolver un resultado. Por ejemplo, verificar si un cierto nombre de usuario existe, o traer una lista de tareas, verificar si un usuario tiene permisos, etc. Recuerden que las queries no alteran los datos. Como pueden ver, estos pueden ser modelados como un tipo de patrón de diseño command nuevamente, pero no es el punto de este artículo.

Finalmente Segregación de la Responsabilidad (otros usan Separación en su lugar) significa que nuestra aplicación usará comnands y queries de forma separada, y que no pueden ser mezclados. Esto significa que nuestro sistema realizará operaciones de escritura y de lectura en tiempos o en espacios lógicos separados.

¿Para qué sirve?

La mejor aproximación para este patrón arquitectural es tener dos conjuntos de datos distintos, uno para lectura y otro para escritura. El de escritura (view data source) está basado en el otro, que podría ser la persistencia actual para nuestros datos. Podemos entonces mejorar nuestro conjunto de datos para la lectura (que no tiene por qué ser relacional, ni normalizado, ni siquiera persistente mientras esté disponible, como un tipo de caché) para tener una aplicación muy veloz, mientras que el trabajo serio se hace con los commands en el otro conjunto de datos.

Las aplicaciones orientadas a tareas pueden entonces delegar las acciones de forma asíncrona para que las tareas-commands (escritura) no ocurran en tiempo real, así permitiéndonos tratar la concurrencia fácilmente, o dando una experiencia increíble en la sensación de velocidad en la aplicación de usuario. Han visto el mensaje de “Enviando email” de GMail y cómo a veces es instantáneo y otras veces puede tardar hasta 30 segundos? Ese es el tipo de experiencia que podrían dar.

El artículo en donde leí esto (MSDN: CQRS on Windows Azure) explica cómo los comandos pueden ser encolados para ser procesados por un thread en segundo plano, de forma que las tareas no tienen que mantener al usuario esperando, y un segundo thread en segundo plano puede estar actualizando los datos para la vista (los que usan las queries para leer), también de forma asíncrona. Nuestra aplicación podría ser la más rápida para la experiencia del usuario, o podríamos tener al usuario esperando y er notificado cuando su tarea se ejecuta (algo como un panel de notificaciones en la aplicación, algo al estilo Facebook que diga “Su reservación ha sido procesada” mientras el usuario sigue navegando por el sitio, quizás?).

Suena demasiado bueno para ser verdad…

Bueno, esta aproximación tiene sus problemillas. Número uno, definitivamente no lo recomendaría para sistemas de misión crítica o de tiempo real. Para nada. De ninguna manera.

Número dos, y tres, cuatro, cinco, etc., es que nos encontramos forzados a proveer un tipo especial de experiencia de usuario en donde las cosas no ocurren en tiempo real. ¿Cómo manejar esto?

Manejando operaciones de forma asíncrona

Al mismo tiempo, hay un problemita cuando necesitamos que nuestras queries funcionan contra datos reales, en tiempo real. Y a veces, no podemos evitar esto. Por ejemplo, ¿qué si necesitáramos hacer validaciones en un nombre de usuario que el usuario nos provee para verificar que no está duplicado? (Por supuesto, podemos diseñar las estrategias de caché para eso, pero aún así, es un problema.) Este tipo de situaciones puede llevar a algunas impurezas en el diseño, ya que deberíamos trabajar contra nuestro conjunto de datos de persistencia, y no el de lectura, pero las aplicaciones pueden ser modeladas en una forma diferente bajo la premisa de nada es urgente. Miremos algunos ejemplos:

  • ¿Es el nombre de usuario único?
    ¿Por qué necesitaríamos nombres de usuario? Usemos email, autenticación externa como Facebook, Twitter, Google, Windows Live, OpenID, etc. No hagamos que el flujo de usuario dependa de un dato.
  • ¿Están los lugares disponibles para reservación?
    Hagamos un query sobre los datos de lectura, digámosle al usuario que puede haber cambios basado en su pedido, que está viendo y que se le enviará una notificación en el futuro avisando si la reservación fue exitosa o no. Hagamos una reservación lo más cercana a lo que el usuario prefería y permitámosle cambiarla luego, etc.
  • Verificar información de pago
    El pago es nunca instantáneo. Permitámosle al usuario proveer algún tipo de información de contacto, y si el pago no ocurre, contactémoslo luego. Avisémosle más tarde si el pago se efectuó o no. Podríamos en el tiempo intermedio darle una membresía temporal o limitada, etc.
  • Mensajería
    A menos que nuestro sistema de mensajería debiera trabajar como un chat en tiempo real, siempre puede ser procesado con determinada espera. En un chat, la gente espera que los mensajes lleguen de forma instantánea, pero con mensajes siempre saben que las esperas son posibles.

Hay muchos otros ejemplos. A menos que estemos trabajando en un sistema de tiempo real, muchas de las tareas pueden ser trabajadas en otro punto del tiempo. Nuevamente, si no estamos trabajando sobre un sistema de RADAR para el ejército.

Resumen

CQRS (Command-Query Responsibility Segregation/Separation) nos permitirá trabajar de forma asíncrona con operaciones de datos, que a veces pueden tomar más de lo esperado. El impacto más importante en esta aproximación son las expectativas que debemos darle al usuario sobre cuándo se ejecutarán las operaciones, pero la parte buena es la estabilidad, velocidad y disponibilidad de nuestra aplicación. Esto nos provee de habilidades especiales para escalar y crecer en las características de la misma.

Más referencias

  • Domain queries in CQRS, Stack Overflow
    Situaciones de tiempo real, aproximaciones a ellas en una aplicación CQRS.
  • CQRS,  Task Based UIs, Event Sourcing, agh!, CodeBetter.com
    Este artículo habla de CQRS como patrón de diseño, no como patrón arquitectural. Personalmente no me encuentro en deacuerdo con eso, pero es un muy buen artículo.
  • Clarified CQRS, Udi Dahan
    Un buen artículo explicando CQRS y qué hacer en situaciones específicas.
  • CQRS on Windows Azure, MSDN Magazine
    La versión cloud de CQRS.

Link del día: Arquitectura Modular JavaScript

Gracias a JH me llega esta interesantísima presentación sobre un ámbito algo descuidado por lo general del desarrollo web: la parte programática de la interfaz. En esta presentación llamada Scalable JavaScript Application Architecture, Nicholas Zakas nos presenta una arquitectura modular extensible, en donde cada módulo independiente solamente conoce el sandbox en el cual interactúa, aislado de todos los demás módulos, y sin  siquiera conocer cómo es la aplicación web en la que está funcionando.

Parecería que esto no aplica en entornos en donde los distintos módulos tienen que reaccionar frente a acciones realizadas en otros módulos, pero bajo el ejemplo de Twitter, se nos explica cómo es que los módulos pueden registrarse para afrontar cambios cuando sea necesario, de una forma bastante desacoplada.

Tengan en cuenta que el señor Zakas es ingenierio de frontend de Yahoo!, con lo cual, estamos hablando de alguien que tiene a su cargo una página con mucha funcionalidad y mucho trabajo de performance y desarrollo. Por supuesto, tampoco dejen de ver el resto de sus presentaciones, igual de interesantes.

Soy un zorrinito javascript.

Doppler Reports (Español)

Hola a todos

Me enorgullece poder anunciar que desde hace un tiempo he tenido la oportunidad de trabajar junto con el equipo Doppler para un nuevo proyecto, algo que desde entonces se estaba formando llamado Doppler Reports (link). Este proyecto finalmente vio la luz y está activo públicamente desde el 27 de Julio. Permítanme contarles un poco más sobre eso.

Momento… ¿qué es Doppler?

Doppler Email MarketingPara aquellos que no lo conocen, Doppler es una herramienta de email-marketing. Es realmente compleja, pero explicándola en un vistazo rápido, es posible usarla para crear contenido de email online (basado en plantillas o editandolo manualmente), y enviarlo masivamente a una o más listas pre-cargadas. Sim embargo, hay mucho más para lo que puede utilizarse, y una de las grandes posibilidades que nos ofrece está en la capacidad de analizar la reacción del cliente a nuestras campañas de emails. Cuando uno tiene diez, quizá veinte, cincuenta o cien contactos, esto es algo que se puede hacer fácilmente con un listado de ellos. Uno verifica sus contactos, analiza quién abrió los emails enviados, quién hizo click en cuál link, y esa es toda la información que uno necesita.

¿Reportes?

Las cosas cambiaron mucho desde esa mañana del 2005. ¿Qué pasa cuando tienes mil contactos? ¿Y un millón? No, no estoy exagerando. Eso es parte de nuestro trabajo *diario*: mantener una herramienta que envía millones de emails. ¿Cómo obtenemos los resultados y los mostramos al usuario? La respuesta obvia es: Reportes.

Los reportes  te darán toda la información resumida que necesitas sin tener que revisar cada uno de los contactos (porque, por supuesto, el sistema lo hace por tí). A medida que la tecnología evoluciona y que el comportamiento del cliente evoluciona a medida que el marketing evoluciona, nuestras herramientas deben evolucionar también.

Aquí es donde el Equipo de Doppler vio la necesidad de una aplicación de reportes totalmente nueva, para poder satisfacer muchos pedidos que nuestros clientes tenían para la versión anterior de la misma. Pero esta herramienta debía estar pensada para millones de emails, miles de usuarios, información en tiempo real y al mismo tiempo, reportes informativos y elegantes.

Y entramos en la escena. Tuve la oportunidad de trabajar junto con Juan Fazzini para diseñar una arquitectura que escalaría a medida que Doppler siguiera creciendo con todas las futuras características que obtendrá. Entonces, en una tarde de viernes, un pizarrón en blanco, una notebook como grabadora para todo lo que decíamos (ya saben, la documentación es importante), comenzamos a idear y pensar sobre cómo Doppler Reports trabajaría.

¿Cómo está diseñada la arquitectura?

1. Arquitectura distribuida

Distributed architectureCada parte de Doppler funcionará como un módulo independiente, que puede tener varias instancias funcionando al mismo tiempo. Hay un módulo en especial que se encargará de interconectar a los demás entre ellos, pero estos módulos de interconexión pueden trabajar de forma independiente también.

Esto significa que ahora tenemos mayor tolerancia a errores catastróficos. Si un servidor deja de funcionar, las otras instancias de los módulos seguirán trabajando, manteniendo al sistema con funcionamiento normal. Los usuarios no se darán cuenta, apenas puede que noten una demora pequeña en la aplicación.

También significa que si tenemos mucha carga por uso intensivo, podemos crear nuevas instancias de un módulo y los módulos de interconexión automáticamente balancearán la carga.

2. Seguridad en cada llamada

Keys and lock

Tener estos módulos ahí afuera no es poca cosa para la seguridad. La seguridad tiene que ser tan estricta como es posible. Por eso, desarrollamos un protocolo de comunicación que le permitiría a cada módulo verificar si el que llama al mismo es una aplicación autorizada y si está bien devolver datos a la misma. Si todo funciona bien, la llamada se realiza y los datos se devuelven. Si algo no sale bien, como si se provee un token de autorización incorrecto, nunca se sabrá qué pasó. Sabemos que esto no es particularmente transparente para los programadores, pero es lo más seguro que podemos realizar para prevenir intentos de hacking.

El resultado de esta característica es que, incluso cuando los módulos estén disponibles en Internet (no todavía, pero quizás en algún momento lo estén), no cualquiera puede acceder a ellos. Incluso si saben en dónde están o cómo llamarlos, ellos no harían nada hasta que los clientes le provean un token de seguridad auténtico.

También significa que las claves de seguridad para acceder a este módulo se pueden generar y, en el futuro, podría resultar en una API para ciertos módulos de Doppler que cualquiera (o algunos usuarios) podrían utilizar. ¿Imaginas crear una aplicación para tu propia empresa que automáticamente trabaje con los datos que Doppler generó para tí?

3. Reportes en tiempo real

Más que una decisión arquitectural, esto fue un desafío. Ya se sabe que estamos manejando toneladas de datos. ¿Cómo cargarlos rápidamente? ¿Cómo obtener una buena performance? Para eso, decidimos que algunos objetos trabajarían internamente como proxies, de forma que sólo se obtendría la información que se ve.

Esto significa que ahora al entrar a la pantalla de Resumen de Métricas para una de tus campañas, podrías ver (cuidado… se viene un listado grande):

Quick clock

  • Nombre de la campaña
  • Asunto del email de la campaña
  • Tipo de campaña
  • Cantidad de listados de emails que recibieron la campaña
  • Cuántos suscriptores recibieron la campaña
  • Cuándo se envió la campaña
  • Aperturas por cada hora
  • Clicks por cada hora
  • Cuántos emails fueron abiertos (total)
  • Cuántos emails todavía no han sido abiertos
  • Cuántos emails resultaron en soft-bounce
  • Cuántos emails resultaron en hard-bounce
  • Última fecha de apertura
  • Clicks únicos
  • Aperturas únicas
  • Cada uno de los links
  • Para cada link, cuántos suscriptores hicieron click en ellos
  • Para cada país del mundo, cuántas aperturas ocurrieron en ese país

*toma aire* ¿Saben cuánto tiempo le toma a Doppler Reports obtener y mostrar toda esa información? Menos de 5 segundos. Pongo énfasis en ello: Menos. De. Cinco. Segundos. Ese es el tiempo que me toma leer las primeras tres líneas de la página. Quizá cuatro, quizá cinco. Pero antes de que haya terminado de hacerlo, la página está completamente cargada y funcionando. Y debo aclarar, mi conexión a internet no se destaca por su velocidad.

Por supuesto, también usamos caching. Esto agrega una capa más de interacción hasta los datos, pero nuestro sistema de caching nos asegura que tengamos los datos listos para el usuario en el momento que los pida. Los datos de una campaña no cambian mucho, a menos que se acabara de enviar, por lo que, para la gran mayoría de los casos, podrías ver los datos de tu campaña tan rápido como cualquier otra página web.

4. Diseño modular

Puzzle

Mencioné antes que Doppler ha comenzado a ser más y más complejo, y ahora está siendo diseñado de una forma modular. De esta forma, los módulos trabajan independientemente y a la vez, delegan responsabilidad en el módulo que sabe cómo resolver un cierto problema o cómo tratar cierto conjunto de datos. Tener un diseño modular es un aspecto terriblemente importante para cambios futuros. Le permite a nuestro equipo paralelizar el trabajo, y le permite a nuestro equipo (y a nuestra aplicación) crecer.

Esto tiene importantes consecuencias. Para el lado que el usuario logra ver, esto significa que muchas características estarán disponibles más rápidamente. Nuevas características, más mejoras, más robusto, más rápido, mejor. “Harder, faster, better, stronger.”, como Daft Punk recomienda construir el software.

Eso es increíble, ¿puedo usarlo?

Por supuesto. Estas nuevas características ya están disponibles para todos los usuarios que tengan una cuenta de Doppler. Si no tienes una, puedes crearte una de forma gratuita y probar el producto por tí mismo: http://www.FromDoppler.com/.

Antes de que se vayan…

…Quería decir que considero un logro personal haber podido formar parte de todo esto. Intentamos lograr algo radical y hoy tenemos un producto radical. Creo que el Equipo Doppler está muy orgulloso de lo que han logrado. Yo ciertamente lo estoy.

Ah, y este post ha llegado hasta el blog de GetCS. Visitenló, puede que les interese.

Doppler Reports

Hello to you all

I’m really glad to announce that since some time ago, I had the opportunity to work along with the Doppler team for a new project, something that since that time was evolving, called Doppler Reports. This project finally became active and working publicly on July 27th. Let me tell you a little more about it.

What is Doppler anyway?

Doppler Email MarketingFor those that are not aware of it, Doppler is a online email-marketing tool. It’s really complex, but explaining it just at a glance, you can use it to create email content online (template-based or editing it yourself online), and sending it massively to one or many of your pre-entered mailing lists. However, there is much more to it, and one of the big powers enclosed in such a tool is the ability to analyze the customer’s reaction to your mail campaigns. When you have ten, maybe twenty, fifty, or even a hundred customers, this is something you could easily do with lists. You check for your contacts, you see who opened the email you sent, you see who click on which link, and that’s all the information you need to go on.

Reports?

Things have changed a lot in the business since that morning in 2005. What happens when you’ve got a thousand contacts. A million? No, I’m not exagerating. That’s part of our everyday work, maintaining a tool that daily sends millions of emails. How do we get results and present them to the users? The obvious answer is: reports.

Summarizing reports will give you the information youneed without having to scan for each of your contacts (because, of course, the system does it for you). And as technologies evolve, and as customer behavior evolves, and as marketing evolves, our tools needs to evolve too.

That’s where the Doppler Team saw the necessity of creating a new brand report application, in order to fulfill a lot of requests that our customers had from the previous version of our reporting tool. But this one would have to be thought for millions of emails, thousands of users, real time information and at the same time elegant and data-rich reports.

Then we entered the scene. I had the chance to work closely along with Juan Fazzini to design an architecture that would scale as Doppler would get bigger with all future features that it will get. So, in a Friday afternoon, a big white board, a notebook as recorder to keep track of everything we said (you know, documentation is important), we started brainstorming and dreaming about what Doppler reports would work like.

How is the architecture designed?

1. Distributed architecture

Distributed architectureEvery part of Doppler will work as a separated module, that can have many instances working at the same time. There is a special module which will take care of connecting all of the others between them, but these interconnection modules may work independently as well.

This means that we now have more catastrophic-error tolerance. If one server fails down, the other instance of the module will keep on working, and users will notice nothing, but maybe some little delay on the application.

This also means that if we have too much load, because of intensive use, we can just create new module instances and the interconnection modules load balancing will automatically take care of the load.

2. Security on each call

Keys and lockHaving this modules out on the wild is no little thing for security. So, security had to be strong as possible, and we developed a communication protocol that would allow each module to check if the caller is in fact an authorized application and that it is ok to return data to it. If everything goes right, then the call is made and the results are returned. If something goes wrong, as like if you provided an incorrect token, you would never know what happened. This is not transparent at all for the end developer (and we know that), but it is as secure as it gets to prevent hackers.

This means that even when modules are out in the internet (not right now, but maybe someday), not anyone can access them. Even if they knew where they are and how to call it, it would just do nothing until clients provide an authorized token.

This also means that the keys that allow access to this module can be generated and in the future, the API for certain Doppler modules would be available for everyone (or just some users) to use. Do you imagine creating an application for your business that would automatically work with the data Doppler generated for you?

3. Real time reports

More than an architectural decision, this was a challenge. You already know that we are handling tones of data. How to load it quickly, how to achieve a high performance? For that, we decided to make some internal objects proxy-like, so that you would only get the information you request.

This means that you can now enter the dashboard screen summary report for one of your campaigns, and you would see (beware… long list coming):

  • Quick clockName of the campaign
  • Subject for the campaign
  • Campaign type
  • Amount of mailing lists that received that campaign
  • How many unique subscribers received
  • When was the campaign sent
  • Total openings by hour
  • Total clicks by hour
  • How many mails where opened (total)
  • How many mails haven’t been opened yet
  • How many mails have soft-bounced
  • How many mails have hard-bounced
  • Last open date
  • Unique clicks
  • Unique opens
  • Last click date
  • Each of the links
  • For each of the links, how many subscribers clicked on them
  • For each country in the world, how many openings happened in that country

*breathes for air* Do you know how much time takes to Doppler Reports gather and show all that information? Less than 5 seconds. Let me emphasize that: Less. Than. Five. Seconds. That’s what takes me to read the first three lines of the page. Maybe four, maybe five. But before I finished doing that, all the page is completely loaded and working. And I have to say, mine is not a premium connection.

Of course, we also use caching. This adds another layer of interaction until we get to the data, but our caching framework provides us with the ability of habing the data ready for the user right away. Campaign data does not change very often unless you have just sent it, so for most of the cases, you will be able to check your campaign data as quick as any webpage would load up.

4. Modular design

PuzzleI mentioned before that Doppler had started to become more complex, and is now being designed with a modular approach. In this way, modules work independently and at the same time, they rely responsibilities on the module that really knows how to solve a certain problem, or to treat certain data. Having a modular design is terribly important for future changes. It allows our team to parallelize work, it allows our team (and application) to grow.

This has great consequences. On the users side, new features will be available sooner. New features, new improvements. Harder, faster, better, stronger. (As Daft Punk suggests we build our software.)

That impresses me, may I use it?

Of course, this new features are available to all users that have a Doppler account. If you don’t have one, you can even create one free and try the product for yourself: http://www.FromDoppler.com/

Before you go…

…I just want to say that I consider a personal achievement having been part of all of this.  We tried to do something radical, and we have a radical product today. I think that all of the Doppler Team is very proud of what they have today, and I sure am too.

Oh, and this post has made its way into the GetCS blog. Make sure to check it out.

Link del día: Entendiendo REST

Un tiempo atrás tuvimos una lectura que trataba de una visión simple de la arquitectura REST. Sin embargo, hay mucho más por comprender en esta arquitectura.

En este caso me dediqué a leer el artículo de Ivan Zuzak, llamado Why understanding REST is hard and what we should do about it (Por qué comprender REST es difícil y qué deberíamos hacer sobre eso). El artículo es extenso en demasía, pero quisiera dejar alguna suerte de resumen para que no tengan que lidiar completamente con él sin conocimientos previos:

El artículo explica cómo bajo una interfaz simple como REST se esconde una arquitectura muy difícil de modelar. Un sistema que tiene sus puntas desconectadas de a momentos y todavía debe mantener estados puede ser representado con distintos modelos matemáticos, pero ninguno se ajusta a la exactitud. Una vez que se logre modelar y generar una representación formal de esta arquitectura, pueden establecerse estándares que facilitarán el avance. Más que esto, la existencia de un modelo matemático preciso permitirá predecir sus limitaciones y sus capacidades.

Como extra, la especificación de una arquitectura correcta permitirá también concebir buenas prácticas y conceptos de seguridad para la utilización de este tipo de comunicación que de a poco logrará volver a la web semántica.

Soy un zorrinito semántico.

Sistemas Jenga

Suelo decir muchas tonterías a modo de chiste, pero de tanto en tanto, alguna de ellas tiene un poco de verdad. Hoy, hablando de un sistema del que estoy encargado (entre otras personas) de mantener, pensé que estaba muy difícil su actualización, y lo llamé un Sistema Jenga. ¿Qué es un sistema Jenga? Es un sistema para el cual agregar una pieza hace que peligre toda la estructura de su programación.

Jenga

Aquí participan varios conceptos que alguna vez he mencionado. Uno de ellos es, por supuesto, la arquitectura o la estructura con la cual se ha programado, diseñado y modelado el sistema en cuestión. Es obvio que una buena arquitectura, o una pensada en torno a futuros cambios, pueda ser lo suficientemente flexible como para aceptar futuros nuevos requerimientos sin necesidad de rediseños mayores o cambios drásticos en la programación anterior. Pero ese no es el concepto que más me interesa discutir hoy.

Otro de los conceptos es el hecho de cuál es el propósito de una pieza de software. Lo considero un punto incluso filosófico, porque está claro que no hay un sistema multipropósito, que realice todas las funciones que podamos llegar a necesitar, y creo que no debería haberlo tampoco, porque sería infactible que dicho sistema se adapte a todas las situaciones particulares que puedan surgir. Por tanto, el riesgo que tal hipotético sistema introduciría en nuestros procesos, sería catastrófico. No haría falta mencionar tampoco, que la programación/diseño/análisis de ese sistema se aproximaría a lo altamente infactible. Muchos sistemas operativos ya proveen de estas posibilidades gracias a la integración de muchas pequeñas herramientas, pero no es técnicamente parte del mismo sistema, a pesar de que pueden llegar a interactuar de forma muy íntima.

Entonces, a medida que pasa el tiempo, es muy factible que los requerimientos para un sistema se vayan modificando. Muchas veces los cambios son pequeños, pueden ser cuestiones de usabilidad o cuestiones de performance. Incluso puede que haya una modificación grande en el sistema, agregando nuevas funcionalidades y hasta quitando funcionalidades obsoletas, pero el objetivo o el propósito del sistema se mantiene, hace lo que siempre debió hacer.

¿Qué pasa, entonces, cuando cambia el enfoque de negocios y los requerimientos del sistema pasan a tener un propósito distinto del original?

Yo creo (aunque es mi opinión personal) que en ese caso el sistema se vuelve obsoleto, y pierde su razón de ser. Es entonces en donde el mantenimiento de esos sistemas para acomodarse a los nuevos requerimientos puede ser algo dramático, porque se está intentando usar algo que ni siquiera estaba pensado de la forma que se necesita para algo que ni siquiera estaba pensado que se iba a necesitar. Casos tan drásticos son raros, pero son factibles de ocurrir. Y creánme, ocurren.

Bathtub curve

Esto no es nada nuevo tampoco. Se sabe, y es algo conocido como “la curva de la tina de baño” (o su nombre en inglés “Bathtub curve”) que el ciclo de vida de un sofware, o la utilidad que el mismo proporciona a sus propósitos es poco al principio, hasta que los usuarios logran sacar el máximo provecho de los sistemas, hasta que los demás sistemas lograron integrarse de forma correcta al mismo y hasta que los bugs iniciales hayan sido corregidos. En la etapa media es el ápice de la utilización de esos sistemas, pero pasado el tiempo, es cuando el sistema ya deja de satisfacer las necesidades del usuario.

Aquí surge la discusión de qué sucede con la curva en el final. Para productos comunes (por ejemplo, elementos mecánicos) el desgaste producido comienza a introducir nuevas fallas que de a poco vuelven al producto inusable. En el software, es fácil reacomodar la lógica del mismo y entonces, adaptándose a las nuevas necesidades, cabe la posibilidad de que se mantenga en su estado de mejor uso. Así, la curva finalizaría con una forma de sierra, en donde se observarían pequeños picos (dado que al usuario le deja de resultar útil el sistema) y tras dicho re-acomodamiento, una planicie.

Sin embargo, la manutención de un producto a través de la eternidad no es algo factible, y quizá no es deseable tampoco. Aquí es en donde la otra opinión se asoma al respecto, diciendo que la vida de un software también se desgasta proporcionalmente al tiempo que estuvo activo, y, personalmente, creo que tiene sentido.  Las necesidades a través del tiempo suelen cambiar muy drásticamente y, aunque una suma siempre haya sido una suma, las cosas tienden a simplificarse para el usuario y cuando un click antes hacía una suma, ahora debe realizar una estimación a futuro.

Y finalmente, otra cosa que quería mencionar al respecto, es la terrible necesidad del backward compatibility. Esto significa que a medida que vamos mejorando y agregando funcionalidades a nuestro sistema, necesitamos algunas veces tener compatibilidad con las versiones viejas de nuestro sistema. A veces es fácil, porque nuestro sistema puede ser una web application que no requiera de muchas entradas, y por tanto podemos cambiarlo todo sin necesidad de tener esa precaución. ¿Qué pasa si en cambio Microsoft, al implementar su nuevo formato de archivos de Office 2007 hubiera hecho inútiles los archivos de Office 2003 hacia atrás? ¿Qué pasa si en cambio cuando decidieron implementar IPv6 no hubieran tenido en cuenta que somos millones los que estamos actualmente usando IPv4 y que no podemos (o queremos) comprar nuevas placas de red en este momento?

Por eso, siempre es una cuestión a considerar, no hay ni blancos ni negros, pero siempre que un sistema debe mantener compatibilidad con sus versiones anteriores, se agrega complejidad, y de alguna forma es un requerimiento extra que nos impide avanzar con las modificaciones que quisiéramos hacer para avanzar con las nuevas funcionalidades del sistema.

Es entonces, en conclusión, en donde el mantenimiento de un sistema se vuelve algo tan pesado que quizá sería mucho más provechoso realizarlo de cero con las nuevas necesidades, y en donde la modificación del mismo lo hace peligrar cada vez más en su integridad, algo que a mí me gusta llamar Sistemas Jenga.

Soy un zorrinito jenga.