Link del día: Plataformas de Cloud presentes y por venir
Este link de hoy no es tan sustancial como el resto de los que estamos acostumbrados, pero no por eso deja de ser útil. En este caso, es un listado que productos Platform as a Service (PaaS). No todos son pagos, y algunos pagos tienen free trials, si a alguno le interesa probar alguna aproximación de computación distribuída, esta es su oportunidad.
El listado está aquí: List of Current and Upcoming Cloud Platforms. Dicho sea de paso, me encanta el diseño de ese blog. Minimalista en serio.
El listado de la categoría Cloud Platforms de Wikipedia provee algunos nombres más. Y por si no les alcanza todavía, acá tienen el List of Cloud Platfrms de CloudTweaks (2010).
Tampoco se olviden de checkear Cloud Computing Ecosystem, que lo mantienen actualizado desde aquél post en diciembre del 2009.
Soy un zorrinito en las nubes.
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: Social por defecto
Este es uno de esos ejemplos que van guíando a los programas de la forma que tienen que ser. Hace un tiempo ya César DOnofrio me estuvo comentando sobre una aplicación llamada Color. Con un nombre tan simple, es una herramienta para dispositivos móviles que nos permite formar parte de un “enjambre” de gente que participa de un evento.
Basándose en la localización y el tiempo actual en donde el multimedia es capturado (fotos, videos, etc.), se puede considerar que varias fotos de distintas personas son en realidad pertenecientes a un mismo eventos. Así es como Color nos permite compartir lo que hemos visto con la gente que estuvo en ese evento y con otros. Lo curioso es que entonces todos los detalles que nos perdimos del evento fueron entonces capturados por otros presentes y están disponibles para nosotros también.
La idea es maravillosa, es hacer social en el mundo virtual lo que ya es social en el mundo real. Yo personalmente creo que si esta herramienta no es de alguna forma un ejemplo de cómo deben seguir siendo las aplicaciones (directas en su propósito), al menos tiene un concepto más que interesante.
Soy un zorrinito social.
Link del día: Los fines de semana son para JavaScript
Aunque el título original del post es Weekends are for hacking, yo creo que este título se le ajusta un poco mejor y se presta menos a confusión, ya que el hacking al que se refiere es hacking de archivos JavaScript para crear nuevas funcionalidades o sobreescribir funcionalidades que ya existen en determinados navegadores. Los ejemplos son muy buenos, y las aplicaciones son múltiples. Pasamos desde la posibilidad de crear gráficos hasta la posibilidad de reproducir MIDI desde el navegador. Por supuesto, todo esto es una gran fuente de conocimiento que podemos utilizar para aprender.
Quizá hacer nuestros propios hacks no sean tan difíciles (y de hecho, nos invitan a que lo hagamos), pero personalmente no creo ser tan conocedor de JavaScript como para ser capaz de algo así. ¿Ustedes sí?
Soy un zorrinito JavaScript.
Dicho sea de paso, ¡Felices Pascuas!
Link del día: El algoritmo del Kinect
Si es que han visto demos, publicidades, o han jugado personalmente con el Kinect, probablemente se habrán dado cuenta que tiene mucho trabajo volcado en ese producto, y mucha tecnología novedosa sobre la forma en la que se pueden reconocer los cuerpos, las caras y los movimientos. Simplemente, una forma que resultó ser viable de utilizar el reconocimiento de gestos de una forma muy amplia.
Hace no mucho tiempo Microsoft reveló públicamente el algoritmo que utiliza Kinect para hacer estos reconocimientos. Toda esa información está presente en un paper publicado bajo el nombre de Real-Time Human Pose Recognition in Parts from Single Depth Images. El paper es bastante conciso y no muy largo, pero claro, hay que tener ciertos conocimientos de probabilidad, grafos y procesamiento de imágenes para poder apreciarlo en su totalidad.
Siendo esto público ahora, ¿quién de nosotros será el próximo en armar su aplicación Kinect-like?
Soy un zorrinito en movimiento.
Link del día: Patrones CSS3
La magia de CSS3 nos da la posibilidad de crear una enorme cantidad de figuras complejas, y lo bueno es que son características propias del lenguaje, no se tratan de hacks o de implementaciones propias de navegadores.
Han habido quienes lo llevaron un poco más allá para crear fondos con patrones hechos exclusivamente de código CSS3, y su galería puede observarse en CSS3 Pattern Gallery. La galería es totalmente interesante e interactiva, podemos cambiar los valores que forman los patrones en las cajas de texto y crear nuevos o modificar los existentes a nuestro gusto. Como extra, también es una buena forma de practicar CSS3 de una forma muy gráfica, ¿no lo creen?
Esta galería forma parte del blog de Lea Verou, un blog sobre estándares webs y técnicas CSS, que vale la pena revisar (y cuyo diseño es envidiable).
Soy un zorrinito CSS3.
Link del día: Adapt.js
Siguiendo con la seguidilla de implementos JavaScript, hoy tenemos a Adapt.js, un archivo javascript que nos permite condicionalmente cargar uno u otro CSS de acuerdo a valores del navegador. No se trata solamente de variar las versiones del navegador como podemos hacer con HTML condicional, sino a condiciones como el tamaño de la pantalla, y de hecho, ese es el uso principal que se le da a esta herramienta.
La capacidad de elegir un CSS según el tamaño de la pantalla nos permite fácilmente apuntar a determinados dispositivos móviles de forma distinta que los navegadores de escritorio, e incluso a pantallas que ya quedaron atrás en el avance de los monitores grandes. Tener esa posibilidad nos asegurará que nuestra página siempre se verá bien en cualquier tipo de monitor en el que se la visualice.
Soy un zorrinito adaptativo.
Link del día: Live.js
Para diseñar y trabajar sobre HTML, mientras más atajos tomemos, mejor. Mucho del trabajo es repetitivo, y cuando queremos aplicar estilos, la cantidad de idas y vueltas de una ventana a otra es innumerable, por lo menos, hasta que logramos la perfección del diseño original.
Ya alguien tuvo la idea de circunvalar ese problema y surgió Live.js, un script más cerca a diseñar en el navegador, que automáticamente detecta cambios en el HTML, el JavaScript, o el CSS y los aplica a la página actual.
El proyecto surgió como una desviación desde BackFire, un sistema un poco más complejo (cliente-servidor) que nos permitía guardar los cambios en CSS que hacíamos con cualquier navegador inline (como FireBug, WebKit developer toolbar, etc.).
El punto es que Live.js automatiza todo eso y nos permite trabajar en los archivos de forma directa y ver los resultados en el navegador de forma transparente. Imaginen utilizarlo en conjunto con dos monitores. La productividad se eleva una muy buena cantidad.
Soy un zorrinito en vivo.
Link del día: El juego del test-driven-design
Recuerdo haber hablado más de una vez sobre distracciones y productividad. Varias de esas veces he mencionado que si podemos darle un toque interesante a lo que estamos haciendo, casi a modo de juego o de desafío, la actividad se vuelve mucho más divertida, y por supuesto, nosotros nos volvemos más concentrados hacia ella.
Un muy buen ejemplo de este caso es TDGotchi, autodefinido como una mascota virtual que nos permite mejorar nuestra práctica de Test Driven Design (TDD).
Se trata de una mascotita, una especie de ninja pixelado que tendremos en nuestro entorno de Eclipse, y que mientras vamos avanzando con ciertas reglas en el proceso de TDD (rojo a verde, verde a verde con refactor, verde a rojo con cambios?) este gana puntos y va evolucionando.
¡Velemos por la seguridad de nuestra mascotita y mejoremos nuestros procesos!
…y más allá de eso, tengamos en cuenta una buena forma en la que se da ese _toque especial _a los procesos tediosos.
Soy un zorrinito tedioso.
Link del día: Blueprint visual
Estaba leyendo un artículo sobre herramientas gratuitas para desarrolladores (27 Free Online & Offline Applications for Designers & Developers) cuando una de ellas realmente llamó mi atención. Se llama Boks, y es una aplicación de Adobe Air (eso significa, funciona en Mac, Windows y Linux) que nos permite trabajar sobre Blueprint.
Para quién no recuerda de qué se trata Blueprint, es un framework CSS basado en grillas, ampliamente utilizado para la rápida construcción de diseños, que nos permite crearlos armoniosos y esquematizados.
Boks nos da la posibilidad de hacer esto de una forma visual, una gran ayuda para aquellos que no hemos aprendido a utilizar el framework CSS más famoso de una forma totalmente profunda, y que queremos comenzar a utilizarlo.
Soy un zorrinito CSS.