Feeds:
Entradas
Comentarios

IronHack


Hace unos tres meses, en la fiesta final de la SpainJS conocí a Mauricio. Una persona muy entusiasta y con ganas de llevar a la realidad su último proyecto. Estuvimos hablando un rato y nos despedimos. Hace un par de semanas, ya desde Berlín, me sorprendió ver que este proyecto había pasado de sueño a realidad. Sí, me sorprendí, porque no es usual que los proyectos se transformen en realidades, y eso habla bien de Mauricio, y de su tesón trabajando.

Así que en este post voy a hablar de IronHack, ¿por qué? Ellos no me pagan un duro por este post, pero pienso que es una iniciativa muy interesante, en especial para la comunidad de jóvenes desarrolladores. De hecho yo mismo estuve a punto de involucrarme en un par de iniciativas similares que desgraciadamente no consiguieron despegar.

(Enrique, déjate de rollos y ve al grano, que luego la gente mira el scroll y huyen espantados)

¿Qué es IronHack? Es sencillo, es una escuela para nuevos programadores donde se enseña como hacer software en el mundo real. Imagínate, hace poco que has terminado la universidad o estas terminando. Ha sido duro, pero lo peor es que la mayoría de los conocimientos que te han enseñado son obsoletos. Tal vez sepa algo de JAVA y SQL, quizás teoría de compiladores e incluso C. Con suerte entenderás el modelo waterfall de desarrollo de software y si os han hablado de Scrum ya tendréis más suerte que yo. En mis tiempos me enseñaron el modelo COCOMO, y ¿quién se acuerda de eso? No se vosotros, pero a mi cuando me enseñaron OO me decían que era como un modelo entidad relación pero con herencia.

Sí, tal vez encontraras trabajo en una consultora “cárnica” con todo eso, pero no en una startup o en una empresa importante que se dedique a hacer software de verdad. Hay cosas realmente importante que desgraciadamente no se están enseñando en la universidad: como Ruby o JS, como TDD y BDD, los principios de “clean code” y SOLID, HTML y CSS, Git y GitHub y como poner una aplicación en producción en la nube. Si piensas que todo esto son “moderneces”, os recuerdo que a mi me preguntaron sobre todo esto de forma exhaustiva cuando me entrevistaron para eBay.

No sólo es el temario, sino el método didáctico y los profesores. No es lo mismo que te enseñen todo esto un teórico que no ha sacado a producción software en su vida, a que te lo enseñe un aguerrido veterano del mundo real.  Echad un vistazo al listado de personas involucradas en el proyecto. Y por supuesto, aprender haciendo. Se trata de aplicar los conceptos a un pequeño proyecto y ponerlo en producción.

Finalmente está la guinda, tal vez alguna de las empresas patrocinadores contrate a los mejores de la promoción. Las empresas no son tontas y saben que los medios tradicionales de reclutamiento sólo consiguen gastar dinero y reclutar no-talento.

Si alguno está buscando diferenciarse del resto de sus compañeros de promoción, o simplemente aprender cosas nuevas. Echadle un vistazo a IronHack, tal vez os interese.


Hola a todos, en este post no voy a explicar nada técnico, sino que voy a hacer publicidad de una iniciativa privada y capitalista: mis cursos de formación.  A partir de ahora, si veis un post de “Ganarse el pan” que sepáis que es un anuncio comercial.

Hasta ahora he estado haciendo formación, consultoría y mentoring para empresas. La verdad es que no me ha ido mal, pero siempre me quedó el gusanillo de abrir la formación a individuos particulares. Así que decidí organizar una serie de cursos  sobre JS. Tras unos iniciales intentos fallidos, ya por fin tenemos el primero: “JS Profesional”. El titulo, lo confieso, es un poco serio, y barajé algún título más escandaloso, pero al final lo he dejado en una cosa más neutral. Se trata de un curso orientado al típico desarrollador  que nunca ha trabajado en serio con JS, sino que sólo ha tenido un contacto superficial del lenguaje, como validación de formularios, efectitos con jQuery y un poquito de AJAX. La mayoría de los desarrolladores de “server side” están en esta tesitura. El objetivo del curso es dar un empujón a estos profesionales, para que JS deje de ser un lenguaje misterioso que falla incomprensiblemente. Son 10h de curso, pero van a ser muy intensas, y te van a dar la base para empezar a practicar JS a otro nivel. Eso sí, después hay que practicar en la vida diaria lo que se ha aprendido en el curso. Para más información sobre el curso visita aquí: https://eiar.stagehq.com/events/1683

Pero mis planes no pasan sólo por este curso, quiero crear una serie de cursos sobre temas avanzados: Node.js, REST con JS, integración continua con JS, etc.

Todos los cursos van a seguir el mismo formato: dos clases de 5h cada una. En principio vamos a hacerlo los viernes por la tarde y los sábados por la mañana. La idea es que sea un horario compatible con la gente que trabaja. Sin embargo, he recibido peticiones de poner cursos en otro horario, así que aquí os dejo una encuesta sobre el tema:

Si estas desempleado, no creo que te importe mucho el horario, pero en cada curso reservamos una plaza gratuita para desempleados. Con esto queremos unirnos a la iniciativa #DecisionesQueAyudan. Simplemente tienes que mandarnos tu CV, y justificante de estar desempleado, a nuestra cuenta de correo: info.eiar@gmail.com

Y finalmente os quiero comentar que no voy a estar dando estos cursos yo sólo: me he asociado con el amigo Israel Alcázar El mismo lo explica en su blog En principio Israel va a hacer un curso sobre Git (sistema de control de versiones que todo el mundo debería estar usando ya, excepto si está usando Mercurial o el magnífico PlasticSCM). Más información sobre este curso aquí. Lo interesante es que como estamos juntos en esto proponemos un descuento de 10 euros por curso si te apuntas a ambos cursos. Si te apuntas a un curso mío, recibirás por correo un cupón de 20 euros de descuento para el curso de Israel, y viceversa.

Para finalizar otra encuesta, esta vez sobre el tema precio:

Y por último agradecer a toda la gente que ha hecho retuits y ha recomendado el curso, con gente como vosotros todo es más sencillo.

Bueno, espero que esta iniciativa tenga éxito y podamos seguir dando muchos cursos!


¡ Bienvenidos de nuevo al mundo de CQRS ! Hoy nos vamos a centrar en ver como podemos implementar la persistencia del subsistema de comandos. La opción más tradicional es persistir una instantánea del modelo de datos directamente en una base de datos relacional mediante un ORM o similar. Los amantes de noSQL querrán grabar dicha instantánea usando sus sistema noSQL favorito. Pero ambas opciones se basan en grabar una instantánea del estado del modelo de datos. Sin embargo existe un sistema más simple y que aprovecha el ya existente mecanismo de eventos. Me estoy refiriendo a Event Sourcing.

Concepto y motivación

Ya hemos decidido que el subsistema de comandos va a emitir eventos de negocio, lo cuales serán procesados por el subsistema de consultas para actualizar su esquema de datos interno. Esto tiene algunas consecuencias cruciales:

  1. El subsistema de comandos no va a ser nunca leído por los clientes del sistema, ya que ellos usan siempre el subsistema de consulta.
  2. El subsistema de consultas es el único cliente que realiza operaciones de lectura sobre el subsistema de comandos.
  3. Lo único que va a pedir el subsistema de consultas al de comandos es la lista de eventos de negocio ocurridos desde la última vez que se produjo una sincronización.
  4. Si ocurre un desastre y perdemos todos los datos del subsistema de consultas, basta con levantarlo sin datos, y hacer que le pida al subsistema de comandos todos los eventos ocurridos desde el principio. Por lo tanto el estado del sistema puede residir por entero en el subsistema de comandos. Más sobre esto en futuros posts.

Visto esto, ¿para qué vamos a molestarnos en persistir un esquema de datos basado en entidades y relaciones? Al fin y al cabo ni los clientes ni el subsistema de consulta están interesados en estas entidades. Además lo único que necesitamos para recuperar el sistema en caso de desastre es la lista de eventos de negocio. Por lo tanto lo único que debería ser persistente es la lista de dichos eventos y no un hipotético modelo entidad/relación o un modelo de objetos.

Y este es precisamente el famoso Event Sourcing: almacenar todo el estado del sistema únicamente como una secuencia ordenada de eventos. Por lo tanto si nos decidimos por un mecanismo de sincronización basado en eventos de negocio, el enfoque de Event Sourcing a la persistencia es muy natural. No necesitamos almacenar entidades, ni las relaciones entre ellas, sino serializar una lista de eventos. Cada evento puede poseer campos, pero nunca vamos a necesitar buscar eventos por dichos campos, sino sólo por orden temporal, o como mucho por tipo de evento. El subsistema de consultas sólo va a realizar accesos como el que sigue: «dame todos los eventos sobre pedidos desde el momento X hasta la actualidad por orden cronológico», o «todos los eventos desde el principio».

Otra ventaja de event sourcing es que tenemos todo el historial de operaciones del sistema, lo que lo hace ideal para auditorias, depuración e informática forense.

No digo que debamos usar siempre event sourcing, pero siempre y cuando usemos eventos de negocio como mecanismo de sincronización, me cuesta trabajo pensar en escenarios donde event sourcing no tenga ventajas sobre grabar el modelo tal cual.

Transaccionalidad y consistencia

A nivel transaccional es bastante sencillo: cada comando es una transacción, cada transacción termina con la generación de un evento. A nivel de consistencia podemos tener varios niveles, en función de cuando el comando (la transacción) se da por terminado:

  • Fin de transacción cuando el evento se genera en memoria. Tanto la persistencia del evento como su transmisión al subsistema de consultas se produce de forma asíncrona, en segundo plano. Esto nos da el máximo de escalabilidad y rendimiento. Pero la consistencia es eventual y  podemos perder eventos (durabilidad baja).
  • Fin de transacción cuando el evento se persiste. La sincronización se produce de forma asíncrona, en segundo plano. De esta forma no perdemos eventos, a costa de tener una consistencia eventual entre las consultas y los comandos. Sin embargo la escalabilidad es bastante buena, a condición de que las escrituras sean rápidas. Es un buen compromiso como norma general.
  • Fin de transacción cuando el evento se persiste, y además el subsistema de consultas ha sido actualizado. Aquí tenemos consistencia estricta y durabilidad, pero penalizamos el rendimiento de las escrituras. Si por cualquier caso el subsistema de consulta está muy estresado, podemos perder disponibilidad en la escritura. Si realmente te encuentras en un escenario que requiere una consistencia tan estricta como esta, tal vez no deberías estar usando ni event sourcing ni CQRS.

Como vemos debemos usar un mecanismo de persistencia que escale muy bien a nivel de escritura (excepto en el primer caso) para que nuestro subsistema de comandos escale. No es tan importante en este caso la escalabilidad a nivel de lectura, ya que de ello se encarga el subsistema de consultas, que puede tener otro mecanismo de persistencia totalmente distinto. Además nos basta con un mecanismo que permita escribir en modo “append only” y soporte consultas cronológicas y por tipo. ¿Cómo implementamos pues la persistencia?

Alternativas de implementación

Podemos, como siempre, usar una BBDD relacional como soporte sobre el que almacenar la secuencia de eventos. Pero aunque factible, no es muy ventajoso. Al fin y al cabo nunca vamos a consultar por columnas, o por clave primaria. Tampoco vamos a tener que hacer joins. Ojo, no digo que no podamos usar SQL, lo que quiero hacer notar es que en este escenario el paradigma relacional no nos ofrece muchas ventajas.

Parece mejor usar un paradigma más sencillo. Por ejemplo, en un clave/valor podríamos usar como clave el número de orden del evento y como valor el propio evento serializado directamente. Una simple consulta por rango de clave nos valdría. Otra opción es usar algo como REDIS, que tiene soporte directo para listas y operaciones atómicas de incremento. Por otro lado, algunos sistemas noSQL, como Cassandra optimizan la escritura sobre la lectura, lo que viene bien en el caso de event sourcing.

Podemos simplificar aun más, y usar directamente el sistema de ficheros. Si lo pensáis bien en Event Sourcing no hay ni modificación ni borrado. Toda modificación en el sistema ocurre a través de un comando, que como resultado cambia el estado de este. Como consecuencia del cambio de estado siempre se produce un nuevo evento, que habremos de añadir a la secuencia de eventos ya existente. Lo mismo ocurre con las operaciones de borrado. A nivel de negocio raramente ocurre un borrado como tal. Podemos cancelar un pedido, o anularlo, o sea ejecutar otro comando que termina produciendo otro evento. Como se ve no se necesita ni modificar ni borrar ningún evento. Esto es importante porque tanto los discos magnéticos como los SSD se comportan bastante bien con sistemas que sólo añaden información por el final. En teoría no debería ser muy complicado hacer un sistema que abra un fichero en modo append only… qué curioso acabo de resucitar el concepto de log transaccional o log de operaciones, que se ha usado durante décadas en sistemas transaccionales robustos. Pero meterse a niveles tan bajos sólo compensa si realmente necesitas mucho rendimiento.

Ya existen sistema de persistencia especializados para event sourcing. Son los llamados Event Storages. Sin embargo todos los que conozco no acceden directamente al sistema de ficheros, sino que mapean el concepto de event sourcing sobre otros motores de persistencia como mySQL, Redis o Cassandra.

Snapshoting

Sin embargo la técnica de event sourcing tiene dos debilidades: ficheros que siempre crecen y arranques de sistema lentos.

Como vimos, no es común hacer borrados de los eventos ya que casi todas las operaciones terminan en un evento nuevo que hay que añadir al sistema de ficheros. Esto hace que el espacio de almacenamiento requerido crezca sin parar. Podemos definir eventos de negocio que ocupen muy poco espacio, y usar técnicas de compresión, pero eso sólo hace que el espacio ocupado crezca más lentamente.

Por otro lado, cada vez que el sistema se para y tiene que ser reiniciado, debe leer todo el log de eventos y reprocesarlos para obtener una instancia del modelo de negocio en memoria. Esto hace que el tiempo de arranque sea largo. Este problema afecta al subsistema de comandos principalmente. El subsistema de consultas suele almacenar directamente el estado del modelo de consultas, y sólo necesita procesar los eventos desde la última vez que se paró. Por lo tanto este problema no es importante en el caso del subsistema de consultas.

En los casos en que estos dos problemas son importantes, no se usa event sourcing puro, sino una técnica híbrida llamada snapshoting. La idea es usar event sourcing, pero en segundo plano, y cada cierto tiempo, ir procesando los eventos para generar una instantánea del estado del sistema que será persistida. Esta instantánea estará desfasada con respecto a la secuencia de comandos. La idea es almacenar tanto el log de eventos como la instantánea, por lo que se puede considerar event sourcing puro. Las ventajas son las siguientes:

  • Evitamos volver a procesar el log de eventos completo en caso de arranque. Cuando el sistema arranca lee la instantánea, y procesa sólo los eventos que ocurrieron posteriormente a la creación de dicha instantánea.
  • Se pueden borrar los eventos anteriores a la creación de la instantánea, a condición de que se pueda generar una secuencia de eventos equivalente a ella a partir de la instantánea.

Conclusión

Aprovechando que estamos usando eventos de negocio para sincronizar ambos subsistemas, y usar Event Sourcing como paradigma de persistencia en sistemas CQRS. Este enfoque se integra de forma natural con CQRS, es sencillo de mantener y evolucionar, y en general es una buena base para conseguir sistemas escalables. A nivel de rendimiento es importante que nuestro mecanismo de persistencia sea capaz de escalar bien en escritura.

En el próximo post nos adentraremos en el mundo del subsistema de consultas.


En el anterior post sobre CQRS vimos que existían muchas formas de implementar este estilo arquitectónico, ya que había que tomar varias decisiones de diseño, principalmente que paradigma de persistencia íbamos a usar en el subsistema de comandos y en el de consultas, el método de sincronización entre éstos y el nivel de consistencia que nos interesa. En este post nos centraremos en la sincronización.

¿Qué sincronizamos?

Dejando de lado la tecnología concreta que pudiéramos usar para sincronizar ambos subsistemas, nos surge una pregunta interesante: cuando decimos que ambos subsistemas se sincronizan, ¿cual es exactamente la información que se intercambia entre ambos? ¿Qué es lo que enviamos y recibimos a través de ese mecanismo de sincronización? Si no queremos darle muchas vueltas, podemos simplemente hacer que el nuevo estado, resultante de una operación de negocio, sea recibido por el subsistema de consulta. Es una solución sencilla y directa, pero tiene sus problemas:

  • Transmitir el estado completo una y otra vez puede ser ineficiente.
  • Una de las ventajas de CQRS es precisamente que ambos susbsistemas pueden tener modelos de información diferentes, uno optimizado para operaciones y otro para consultas. Si transmitimos el estado del modelo del subsistema de comandos, la transformación de este en el modelo de información de consulta puede ser costosa e implicar una lógica compleja.

Otro enfoque al problema de la sincronización es transmitir sólo los cambios en el estado del sistema, y no el nuevo estado al completo. De esta forma nos evitamos enviar bastante información, con lo que solucionamos el primer problema. Ummm, dos subsistemas que se sincronizan enviando únicamente los cambios de estado, esto suena sospechosamente a eventos. Técnicamente sólo serían eventos si decidimos que nuestra sincronización siga un paradigma “push” (publish/subscribe). Pero alternativamente podríamos usar un paradigma “pull”, donde el subsistema de consulta pregunta al de comandos qué cambios se produjeron desde un determinado momento. En este caso alguno podría argumentar que no son estrictamente “eventos” sino “cambios”. Yo, por simplicidad, hablaré siempre de eventos, tanto en el caso de “pull” como de “push”.

Ya estoy viendo que a más de uno le ha hecho “click” en la cabeza, y ha visto la luz: «claro, ahora si cambio la propiedad en una entidad, emito un evento “property change”, y si creo una instancia emito un evento de “create”, con lo cual usando el “framework X” lo tengo resuelto y …» Yo mismo he pensado esto en su momento, pero claramente este enfoque nos lleva al lado oscuro del CRUD, que siempre está ahí para tentarnos. A este enfoque lo llamo usar eventos CRUD, y no lo recomiendo en general para CQRS. El problema es que el subsistema de consulta debe ser capaz de interpretar los eventos de la forma más desacoplada posible del subsistema de comandos, pero los eventos CRUD están definidos en función del esquema de datos del subsistema del comandos. Si al subsistema de consultas le llega un evento “property change de la propiedad P sobre la entidad E”, éste debe conocer el esquema de datos del subsistema de comandos para poder interpretarlo. Si hiciéramos un cambio en dicho esquema, tendríamos seguramente que modificar el código en el subsistema de consulta, aunque no se haya producido ninguna modificación en la lógica de negocio. Es más, es probable que haya eventos que ya no tengan sentido, al desaparecer alguna entidad o propiedad. Lo que se intenta con CQRS es que ambos subsistemas puedan evolucionar por separado, y para ello necesitamos que el acoplamiento entre ambos sea bajo. Por lo tanto evitad los eventos CRUD, excepto en el caso que tengáis una necesidad real del mismo esquema de datos en ambos subsistemas (con lo que CQRS no sería una solución tan ventajosa).

Lo que necesitamos son eventos de negocio, que representen cambios en el estado del modelo de negocio, no en el esquema de datos. Para averiguar que eventos de negocio tenemos, debemos hacer antes un buen análisis de la funcionalidad de negocio. Esto es consistente con CQRS, ya que de todas maneras debemos averiguar que operaciones de negocio (comandos) tenemos, por que estados pasa el sistema, etc. Por ejemplo, en una tienda electrónica debemos modelar el ciclo de vida de un pedido. Podemos llegar a algo como esto:

A simplified order lifecycle

A simplified order lifecycle

Existiría un comando “Checkout” que una vez ejecutado por el subsistema de comandos, podría hacer evolucionar el estado del pedido desde “Open” a “Accepted“, o en el caso de un problema, tal vez de pago, al estado “Rejected“. Estas transiciones de estado generarían respectivamente los eventos de negocio “OrderAccepted” y “OrderError“. Ambos eventos transportarían el identificador de pedido y quizás algún campo auxiliar, como por ejemplo, una razón para el rechazo del pedido. Obviamente hay bastantes comandos, estados y eventos, y seguramente falten cosas, pero el hacer un pedido implica un proceso de negocio no trivial.

De esta forma, el acoplamiento entre ambos subsistemas se basa sólo en el formato de los eventos, y en compartir un modelo de negocio común, pero el subsistema de consultas no tiene porque saber como se han estructurado las tablas o los objetos en el subsistema de comandos. El ciclo de vida de un pedido va a cambiar sólo cuando cambie el negocio, no por cualquier detalle técnico, por lo tanto constituye un contrato más estable que un esquema de datos.

El lector avezado habrá notado que esto está muy alineado con el enfoque Domain Driven Design (DDD). Operaciones de negocio, eventos de negocio, estados por los que evoluciona un pedido, etc. Todo esto está muy relacionado con el concepto de lenguaje ubicuo de DDD, no es de extrañar que CQRS sea una arquitectura a la que se suele llegar aplicando la metodología DDD, y viceversa, forzándote a hacer CQRS es fácil que termines haciendo DDD.

Conclusión: una forma muy apropiada de sincronizar ambos subsistemas es mediante eventos de negocio.

¿Cómo sincronizamos?

Desde el punto de vista tecnológico, lo primero a decidir es si queremos un mecanismo de notificación “pull” o “push”.

El paradigma “pull” se basa en que el cliente pregunta al servidor para obtener los datos. Como estamos hablando de pedir cambios, el cliente debe hacer “polling”, es decir repetir la consulta cada cierto tiempo. Esto en algunos casos es ineficiente, ya que muchas veces el cliente va a preguntar en vano, ya que no hay cambios que notificar. De esta manera vamos a estar preguntando y consumiendo recursos para no conseguir nada. Sin embargo en algunos casos es ventajosos usar este paradigma:

  • Es muy simple, no se necesita ningún producto ni protocolo sofisticado para llevarlo a cabo.
  • Internet y la web están diseñados para el paradigma “pull”. Por lo tanto están optimizados para este tipo de interacción, en concreto el uso correcto de las caches, las peticiones HTTP condicionales y el protocolo ATOM/RSS, nos permiten implementar este enfoque de forma eficiente.
  • Es muy interoperable.
  • El servidor (en este caso el subsistema de comandos) está totalmente desacoplado de los clientes. No necesita saber cuantos clientes tiene, ni que eventos recibió cada cliente, ni nada. Simplemente responder a las consultas. Es decir podemos implementar un servidor stateless, que es más sencillo y escalable.

Por lo tanto en algunos escenarios es bastante interesante usar este enfoque, por ejemplo:

  • El subsistema de consulta y el de comandos se comunican a través de la web. Tal vez ambos están en diferentes máquinas en la nube (ideal para alta disponibilidad). En este caso se puede usar HTTP con ATOM/RSS para distribuir los eventos mediante una interfaz REST.
  • Una tercera parte ha implementado una aplicación de agregación de información que usa nuestros eventos. Tal vez sea un business partner, otra empresa de nuestro grupo, el departamento del edificio de al lado, o quizás la nuestra sea una startup que quiere ofrecer una API. De nuevo lo lógico es publicarlo mediante una API REST, que es inherentemente “pull”.

En general todos estos escenarios implican una alta latencia, lo que provoca que las consultas puedan estar segundos o minutos atrasadas con respecto al estado real del sistema.

El paradigma “push”, donde el cliente se subscribe al servidor y recibe los eventos sólo cuando ocurren. El cliente no necesita preguntar al servidor periódicamente, es notificado cuando es necesario. La principal desventaja de este sistema es el acoplamiento entre el servidor y el cliente. El servidor debe mantener una lista de subscripción de forma persistente, y almacenar que eventos fueron enviados a que clientes. Esto puede producir un problema de escalabilidad si tenemos un número ilimitado de clientes. También complica el diseño del subsistema de comandos. En general esto se solventa usando mecanismos de mensajería como JMS o AMQP. También se pueden usar productos de middleware, por ejemplo un producto de Enterprise Service Bus.

Algunos escenarios:

  • El subsistema de consulta y el de comandos están en el mismo proceso. Nos basta con implementar un patrón “Observer”.
  • Ambos subsistemas están en la misma máquina o en el mismo CPD. Usaríamos un sistema de mensajería o un Enterprise Service Bus

En resumen, existen a nivel tecnológico muchas variantes y soluciones para implementar el mecanismo de sincronización. Lo importante es que transmitamos eventos de negocio mediante este.

En el próximo post nos adentraremos en el mundo del subsistema de comandos.


A la vuelta de las vacaciones me han entrado ganas de escribir algo. Sin ganas de hacer el típico post retrospectivo del SpainJS, y por petición popular, he decidido escribir sobre ese gran desconocido que es CQRS. Como no quiero que vuestros ojos se fatiguen mi plan es hacer varios posts cortos en vez de uno con la longitud acostumbrada. En éste me centraré en hacer una introducción al tema. Ya nos meteremos un poco más en detalle en los siguientes.

En una arquitectura tradicional, tenemos un único sistema que se encarga de realizar operaciones de negocio y nos permite consultar la información en la que se encuentra nuestro sistema. Sin embargo, esto viola el principio de única responsabilidad (SRP), ya que el mismo sistema se encarga de hacer dos cosas que en principio son muy distintas: exponer operaciones que evolucionen el estado del sistema de forma consistente, y leer el estado del sistema. Estas dos responsabilidades tienen requisitos muy diferentes desde distintos puntos de vista: funcional, escalabilidad, tiempo de respuesta, seguridad, criticidad, etc. Si nos tomamos en serio el principio de separación de responsabilidades, y somos partidarios de arquitecturas modulares en vez de sistemas monolíticos y centralizados, debemos buscar  una arquitectura alternativa.

Command Query Responsability Segregation (CQRS), es un estilo arquitectónico en el que tenemos dos subsistemas diferenciados, uno responsable de los comandos, y otro responsable de las consultas. Por comando entendemos un petición por parte del usuario u otro sistema, para realizar una operación de negocio, que evolucione el sistema de un estado a otro. Cada uno de estos subsistemas tiene un diseño, modelo de información y mecanismo de persistencia diferente, optimizado para las tareas que deba afrontar. Normalmente el subsistema de consulta suele ser mucho más simple que el otro. Veamos la siguiente figura para explicar un poco como funciona esto (se nota que soy un artista):

CQRS Architecture Overview

CQRS Architecture Overview

El subsistema de comandos, simplemente recibe peticiones de comandos, valida que éstos son consistentes con el estado actual del sistema, y si es así los ejecuta. Como resultado de la ejecución de un comando, el estado del sistema cambia, y ese cambio se comunica al subsistema de consultas mediante algún mecanismo de sincronización.

El subsistema de consulta recibe los cambios en el estado del sistema mediante el mecanismo de sincronización. Durante la etapa de filtrado ignora los cambios en los que no está interesado. En algunos mecanismo de sincronización esta etapa puede formar parte de la configuración del mismo, y no del código de aplicación. Después los cambios se pueden pasar por una etapa opcional donde se pueden transformar, añadirle información calculada y agregar información varios cambios. De nuevo en algunos casos el mismo mecanismo de sincronización podría proporcionarnos herramientas para definir esta etapa de forma declarativa. Finalmente se actualiza de forma adecuada la base de datos. La ejecución de la consulta simplemente consiste en exportar los datos de la BBDD como DTOs y serializarlos en un formato adecuado.

Si en el subsistema de consulta usamos una BBDD relacional, podríamos definir un esquema optimizado para las consultas, de forma que estas no necesiten joins, y las sentencias SELECT sean muy simples y sencillas de optimizar. Tal vez una tabla por consulta, con una columna por parámetro de consulta, y una columna adicional con el resultado en formato ya directamente serializado. Evidentemente otras opciones son posibles.

Y ya está, cualquier sistema que cumpla lo descrito se puede considerar CQRS. Ahora bien, como el demonio está en los detalles, existen muchos puntos importantes a decidir:

  • La naturaleza exacta del mecanismo de sincronización entre el subsistema de comandos y el de consultas. Se puede usar algo tan simple como una llamada local intraproceso, o algo más sofisticado como un sistema de colas, o un servicio web (REST o SOAP). También hay que decidir si la sincronización será pull o push, es decir, ¿el subsistema de comandos notificará al de consulta los cambios? ¿O tal vez el subsistema de consultas preguntará de forma periódica que cambios se produjeron desde la última vez?
  • El paradigma de persistencia de cada subsistema. Puede ser SQL tradicional, o noSQL. Lo interesante es que cada subsistema puede usar el paradigma que más le interese. En concreto si usamos relacional para las consultas, se nos plantea la disyuntiva de usar un esquema desnormalizado totalmente optimizado para las consultas (una tabla por consulta con las columnas específicas a recuperar por ésta) o bien un esquema en tercera forma normal que nos de más flexibilidad.
  • Si el subsistema de comandos tiene persistencia o no. En realidad el subsistema de comandos sólo necesita consultar el estado para saber si puede ejecutar un comando o no. Esta consulta podría proceder del subsistema de consulta, en vez de una BBDD propia. Esto puede ser una opción según que modelo de consistencia sea admisible.
  • Transaccionalidad en el subsistema de comandos. ¿Cuándo se da por terminada la transacción representada por el comando? ¿Cuándo el nuevo estado del sistema se ha modificado en memoria? ¿O tal vez, cuando este estado se ha persistido en la BBDD específica del subsistema de comandos? ¿Quizás sería mejor esperar a que el subsistema de consulta haya recibido el cambio y actualizado el modelo de consulta? Esta decisión es crítica a la hora de definir el modelo de consistencia de datos que queremos (ACID o BASE).
  • ¿Un sólo subsistema de consulta o varios? La arquitectura CQRS nos permite definir varios subsistemas de consultas, especializados en cosas diferentes. Cada uno puede tener un enfoque diferente en cuanto a la persistencia y consistencia. Por ejemplo uno podría usar un sistema noSQL para consultas específicas, y otro podría ser un sistema OLAP para hacer minería de datos.
  • ¿Un sólo subsistema de comandos o varios? De nuevo CQRS nos da la libertad de tener distintos subsistemas especializados en distintas familias de comandos. Uno para procesar comandos relacionados con los pedidos, otros para el control del stock, otro para pagos.

Muchas decisiones, muchas combinaciones, cada una de ellas con su correspondientes ventajas e inconvenientes. Los siguientes posts de la serie tratarán de explorar un poco estos aspectos.

El usar CQRS nos da los siguientes beneficios:

  • Ambos subsistemas pueden evolucionar por separado; el mantenimiento y despliegue puede estar diferenciado. Esto es una ventaja porque normalmente el ritmo de cambios en la funcionalidad es muy diferente en las consultas y los comandos. En mi experiencia es más frecuente añadir una nueva consulta que un nuevo comando.
  • Ambos sistemas pueden escalar por separado. Si nuestro negocio es muy intensivo en lecturas, podemos dedicar más máquinas al subsistema de consultas de forma sencilla. Simplemente levanta otra instancia y conéctala de forma que pueda recibir los cambios transmitidos por el subsistema de comandos.
  • El estilo CQRS es modular de forma inherente. Podemos escoger ir a una arquitectura modular, donde haya varios subsistemas de consulta y varios subsistemas de comandos. Cada uno de ellos de nuevo puede ser diseñado, mantenido, escalado y desplegado por separado. Es muy interesante la posibilidad de añadir nueva funcionalidad (nuevos subsistemas de comandos o consultas) sin tener que parar el resto del sistema.

Sin embargo todo esto no es gratis:

  • Es más complejo, sobre todo debido a que debemos diseñar con cuidado el mecanismo de sincronización en los comandos y las consultas.
  • El tener sistemas de persistencia separados para los comandos y las consultas, o el tener múltiples subsistemas de cada uno, puede provocar que tengamos cierta duplicación de información. Esto puede ser negativos si estamos preocupados por ahorrar espacio en disco.
  • Para construir el subsistema de comandos necesitamos saber que comandos existen, como evolucionan el estado del sistema y cuando la ejecución de un comando es consistente con el estado del sistema. Todo esto exige modelar bien el negocio, olvidarse de las tablas y centrarse bien en las acciones del usuario y modelar bien los casos de uso como máquinas de estado o similar. O sea, no sirve para hacer aplicaciones de mantenimientos de tablas o CRUD. El problema es que muchos frameworks de moda (ROO, GRAILS, RAILS…) están optimizados para ser productivos haciendo CRUD, no para CQRS. No digo que sea imposible usar, por ejemplo RAILS, pero sí es verdad que no va a ser tan productivo.

Los dos últimos puntos son dificultades relativas. El tener duplicación de información y distintos subsistemas es bueno desde el punto de vista de la redundancia y la disponibilidad de la información. Si un subsistema de consultas se corrompe, se puede reconstruir a partir del subsistema de comandos. Por otro lado el no poder usar un enfoque CRUD, o que los frameworks de moda no nos faciliten tanto la tarea, lo veo más un problema social que de ingeniería.

¡ Anda, creo que me ha quedado un post corto !


Este post no es para tratar de convenceros de que os unais a las legiones de Javascript, sino para explicar mis razones para tomar ese camino de perdición. Antes que en javascript programé en tres o cuatro lenguajes, principalmente C y Java. Por supuesto en la universidad aprendí LISP, PROLOG, ADA, varios dialectos de ensamblador y alguna cosa más, pero como nos lo he vuelto a tocar desde entonces no los considero parte de mi “toolkit”.

Yo empecé en esto de Javascript como la mayoría de vosotros, haciendo unos scripts güarrotes para validaciones y efectillos, en los tiempos del año 2000. Era un mal necesario con el que tenía que convivir al desarrollar mis preciosas aplicaciones thin-client en Java. Sin embargo sobre 2005, empecé a querer usar servicios REST sin sesión por temas de rendimiento, lo que me hizo repensar la arquitectura de mis sistemas.  Fue entonces cuando descubrí AJAX, y me quede fascinado por las posibilidades. Desde entonces fue un camino sin retorno; cada vez que aprendía más, descubría nuevas tecnologías, y reflexionaba más sobre como diseñar mejor mis aplicaciones, más enganchado me quedaba con Javascript, y desde entonces hasta ahora.

Así que, ¿por qué Javascript?

Es ubíquo

Que yo sepa, es el lenguaje que en la actualidad está más extendido del mundo. Virtualmente en cada ordenador de cada casa se puede ejecutar una versión u otra de Javascript. ¿Qué ordenador no tiene un browser? ¿Al menos un IE6? Sí, algunas personas por motivos de accesibilidad o seguridad no lo tienen disponible, pero son una exigua minoría.

¿Y en servidor? Pues ya sabeis que tenéis el node.js, tenéis Rhino, etc. En concreto en node.js se está invirtiendo cantidades ingentes de dinero. Ya está soportado en algunas plataformas cloud, como Heroku/Cedar y Windows Azure.

¿Y en desktop? Pues desde hace tiempo existe la plataforma Mozilla, ¿en que creéis que se programa la mayor parte de Firefox y Thunderbird? En una mezcla de Javascript (y C para el bajo nivel). Además Windows 8 plantea usar a JavaScript como uno de los lenguajes de preferencia para hacer aplicaciones de escritorio (otorgándole el mismo rango que a C#).

El mismo lenguaje para cliente y servidor

A día de hoy Javascript es el único lenguaje en el que puedes desarrollar por completo una aplicación web de punta a punta, desde la UI hasta el acceso a BBDD. ¿Qué tiene esto de interesante?

  • No necesitas dominar más de un lenguaje para hacer la aplicación web. Esto te permite no estar cambiando de contexto entre un lenguaje y otro, o simplemente no necesitar dos equipos de desarrollo especializado (uno de front-end y otro de server-side). Además de aumentar tu productividad, puede facilitar tener un equipo de proyecto más cohesionado.
  • No necesitas recodificar la misma lógica tanto en Javascript como en el lenguaje que estés usando en tu server-side. ¿Modelos de negocio? ¿Validaciones? Todo eso es único y debería ser reutilizable tanto en tu front-end como en tu server-side. Si lo haces todo en Javascript, terminas teniendo un montón de código común en ambos lados, que antes tendrías que haber duplicado y mantenido en dos lenguajes diferentes. Eso sí, hay que diseñar tu arquitectura de la forma adecuada para que esto se pueda cumplir.
  • Estándares de codificación y criterios de calidad unificados para todas las capas de tu sistema.
¿No veis todo esto como una “killer feature” de Javascript? Yo personalmente el día que descubrí node.js, vi el cielo abierto, y me dije “esto es la caña”.

Tipado dinámico

Confieso que este punto es muy subjetivo. Ya sabeis que soy un fanático del TDD. Y si haces TDD como es debido, al final el compilador deja de ser tan valioso. Los errores de sintaxis o de tipos son muy sencillos de detectar y arreglar usando TDD, no necesitas un compilador para ello. En los lenguajes de tipado estático, el compilador detecta este tipo de errores, pero a cambio tienes que esperar a que éste se termine de ejecutar. Además normalmente tendrás que escribir más código, para añadir toda la información de tipado que el compilador necesita. Esto hace que el ciclo de TDD sea algo más lento que en un lenguaje de tipado dinámico. Ya que TDD me va a detectar esos errores de todas formas, no me resulta rentable el “trade-off” propuesto por el compilador.

Dicho esto, si no hacéis TDD, mucho cuidado con Javascript, puede ser un buen dolor de muelas de depurar, e incluso pequeños fallos de sintaxis te pueden llevar por el camino de la amargura. Para mi lo ideal del TDD es no tener que depurar, o si lo tengo que hacer, que sea sobre 4 o 5 líneas de código bien identificadas, y que están siendo ejercitadas por un test predecible. Desde este punto de vista Javascript no plantea ningún problema.

Paradigma mixto

Es un lenguaje que te permite hacer OO hasta de dos formas diferentes, con “extends” y sin “extends”. Pero es que además también puedes hacer programación funcional con él. Esto te permite elegir el paradigma de programación que mejor se adapte al problema a resolver.

¿Tratamiento de colecciones? ¿Cálculos puros (validaciones, reglas de negocio)? ¿Programación asíncrona? Mejor el paradigma funcional

¿Modelado de negocio? ¿DDD? Mejor OO

Y por supuesto en una aplicación de verdad vas a tener que usar ambos paradigmas, y mezclarlos armoniosamente. Incluso a veces los puedes mezclar de tal forma que llegan a ser difícil de distinguir uno de otro.

Flexible

Es un lenguaje ideal para hacer DSLs internos, gracias a su gran flexibilidad. Puedes añadir y eliminar funciones al vuelo tanto en una instancia como un constructor. Esto no sólo te permite crear DSLs sino añadir nuevas capacidades al lenguaje, y realizar metaprogramación (aunque en Ruby y Groovy se puede llegar incluso más lejos).

Reconozco que esto puede ser una fuente de problemas, y es mejor evitar este tipo de funcionalidades. Por ello las últimas versiones de Javascript te permiten cerrar total o parcialmente un objeto, para evitar que se puede modificar en tiempo de ejecución. Sin embargo en algunos casos está justificado hacer este tipo de cosas. Aparte de los DSLs y quizás algunos ejemplos de metaprogración, el caso más importante es el de retrocompatibilidad. ¿Qué ocurre si estoy ejecutándome en una máquina virtual de Javascript que no soporta la API de colecciones de la última versión de Javascript? ¿Y si estoy en un navegador que no soporta alguna API de HTML5? ¡No hay problema! Con Javascript puedo detectar tal eventualidad y añadir la API que me falta de forma dinámica. Este tipo de capacidad ha permitido a Javascript sobrevivir en el infierno de incompatibilidades de los distintos browser por más de 10 años.

¿Y los WTF?

Sí, Javascript tiene algunos WTF. Sólo es cuestión de comprenderlos y saber que están ahí. Por ejemplo, los ámbitos de visibilidad no se señalan con ‘{‘ y ‘}’. En Javascript las llaves son prácticamente cosméticas y sólo sirven para agrupar el cuerpo de bucles y condicionales. Otra tema es el hoisting de variables, o el hecho de que en Javascript no existan los números enteros sino que sean todos en coma flotante. Personalmente el WTF que más me molesta es que Javascript tiende a ser “listillo”. Esto significa que intenta no fallar nunca con excepción. De ahí el horroroso e infernal sistema de coerción de tipos o el abuso de null y NaN en mucha de las librerías del lenguaje. En esto sí es verdad que se sufre.

Sin embargo los WTF de Javascript no son tantos ni tan difíciles de aprender como la gente piensa. La mala fama de Javascript viene por causas totalmente ajenas al lenguaje, los WTF de los navegadores. Tradicionalmente la implementación de los navegadores de los estándares de manipulación de HTML y de los servicios estandarizados por W3C ha sido defectuosa. Eso ha causado multitud de quebraderos de cabeza a los desarrolladores. Realmente, en la mayor parte de los casos, cuando un desarrollador piensa en las heridas recibidas en acto de servicio por parte de Javascript, normalmente debería achacarle la culpa al navegador. Desgraciadamente hasta hace poco navegador y lenguaje han estado mezclados en las mentes de los desarrolladores.

El pero

No todo es bonito en el lenguaje. Hay varios problemas con Javascript. El primero, y más importante, son los WTF arriba mencionados. El segundo es la sintaxis tan fea que tiene. La verdad de que con esto de querer simular ser C o Java la pifiaron bien. Espero que en siguientes versiones del lenguaje arreglen todo esto. Si no de momento podemos usar “strict mode”; para desactivar la mayor parte de los WTF, o usar CoffeeScript. El caso de CoffeeScript es curioso, si sabes Javascript entonces CoffeeScript te parece un simple dialecto de Javascript. Si no conoces Javascript, te parecerá un lenguaje totalmente diferente. El caso es que CoffeeScript soluciona la mayor parte de los WTF de Javascript, y tiene una sintaxis mucho más elegante. Lo tengo en el punto de mira a ver como se desarrolla.

Estos son los problemas que reconozco con el lenguaje. Después hay problemas humanos. Ese programador de Java que intenta programar en Javascript como si fuera un hermano retardado de Java (me incluyo en los culpables). Claro, intentas que una manzana se parezca a un plátano, y después vas echando pestes de lo feas que son las manzanas. No critiquemos el lenguaje sólo porque tengamos un conocimiento superficial de este, y al intentar programar como lo hacemos en nuestro lenguaje server-side, las cosas no nos salgan bien. ¡Es como si yo ahora digo que Clojure es una mierda porque no me termino de acostumbrar a su sintaxis y no puedo hacer una asignación de variable de forma sencilla! (no sería mal post :-D )

También hay que reconocer que no es un lenguaje sencillo de aprender. Primero tienes que aprender los WTF, para desarrollar instintivamente buenas prácticas que los eviten. Después tienes que ser capaz de dominar dos paradigmas de programación distintos, OO y funcional. Sólo así conseguirás sacarle toda la potencia a Javascript.

Conclusión

Desde mi punto de vista a día de hoy Javascript es el lenguaje más adecuado para desarrollar aplicaciones web. El problema es que no tiene competencia, ¿qué otro lenguaje tiene unas características similares a las anteriormente mencionadas? Yo no conozco ninguno. Ciertamente Ruby es bastante elegante, y me gusta bastante, ¡ pero sólo se ejecuta en servidor ! Java no está envejeciendo nada bien, y aunque C# es más avanzado está mucho menos extendido y tampoco se ejecute en servidor. Lo mismo puede decirse de Clojure, Scala o Groovy. Sí, podemos hacer como GWT o ClojureScript y compilar estos lenguajes en Javascript, pero, ¿con qué fin? La experiencia GWT ha resultado fallida.

En cualquier caso, a día de hoy, programes en el lenguaje que programes, si quieres hacer aplicaciones web modernas, te toparás con Javascript. Así que es mejor aprenderlo y dominarlo.

Tal vez en el futuro salga un nuevo lenguaje, con más ventajas que Javascript para hacer aplicaciones web. En ese momento tiraré Javascript a la basura y me pondré con el nuevo lenguaje, pero me temo que aun quedan 10 años para eso.

¡Espero que os hayan sentado bien las torrijas de Semana Santa!


Este es un pequeño post que tiene doble objetivo, por un lado quiero contar un poco como fue mi día de codemotion y las charlas a las que fui, por otro lado quiero aclarar algunos aspectos de la charla que di. Empecemos por lo primero.

Las charlas a las que yo asistí

La primera charla que vi fue sobre crear aplicaciones nativas en Widows 8 con Javascript, de Boris Armenta (@borisarm). La verdad es que la charla estuvo interesante, y Boris habló justo sobre lo que decía el título de su charla. Empezó con una pequeña introducción sobre la nueva plataforma de desarrollo de Windows 8, y después hizo una demo. La verdad es que tenía mucha curiosidad por ver como lo habían montado los señores de Microsoft para poder desarrollar aplicaciones nativas con JavaScript. Por lo que Boris contó no se lo han montado mal. Por un lado han orientado las APIs de desarrollo al paradigma de aplicaciones táctiles y no de ratón. En el caso de que el dispositivo no sea táctil, Windows 8 adaptará nuestra aplicación al ratón y teclado de forma transparente al programador. Por otro lado han cogido la máquina virtual de JavaScript de IE9, llamada “Chakra”, y la han extraído del browser para que podamos ejecutar aplicaciones javascript de escritorio en modo nativo, totalmente separado del browser. Ahora con JavaScript puedes acceder a la API del sistema operativo de forma directa y no estás restringido por el sandbox del browser. ¿Y como pintas las UI? ¡Pués con HTML5 y CSS! Windows 8 te proporciona una sintaxis de microdata para marcar el HTML y hacer bindings de este con tu librería de widgets en javascript. Eso sí, Boris se cuidó mucho de decir que esos bindings sólo funcionan para aplicaciones nativas, que nos olvidáramos de usarlos en IE. Sabia decisión para evitar problemas con los estándares. Parece que Microsoft está aprendiendo. Una apreciación personal (Boris nunca dijo nada parecido), me da la impresión que el tema silverlight y XAML ha quedado en segundo plano, como si Microsoft se estuviera preparando para marcarlo como obsoleto. Inquietante y esperanzador a la vez.

Curiosamente, por la tarde me metí en otra charla de .NET, se trataba de las extensiones reactivas de .NET, presentado por Fernando Escolar (@fernandoescolar) y Quique Martínez (@quiqu3). La verdad es que se lo montaron bien, con una dinámica de presentador “gerente” vs. “técnico” divertida. El tema fue las nueva extensión de .NET para programación reactiva, que no es más que un DSL para manejar relaciones observador/observer y bindings de forma  sencilla y elegante, mediante una fluent API. Me resultó también curioso que la misma extensión estuviera portada a Javascript. ¿Será Javascript el próximo lenguaje de referencia para .NET? No lo se, pero apunta maneras. En cualquier caso técnicamente no me pareció nada nuevo, ya que se parece mucho a las cosas que se pueden hacer con ember.js o con knockout.js.

Antes del café de la mañana me fui a ver a Arun Gupta hablar sobre el futuro de JEE 7. Me salió la vena nostálgica de “javero empresarial” que tengo, y se me antojó ver si la JEE evolucionaba por buen camino. Me alegré ver que están pensando orientar JEE al mundo del cloud. No sólo eso sino que percibí un esfuerzo serio por facilitar la vida tanto al desarrollador como al personal de sistemas. Creo que están intentando reaccionar para eliminar esa fama que tiene JEE como plataforma excesivamente compleja. También me gustó la idea de integrar OSGi dentro de JEE mediante el proyecto Jigsaw.

Después de la comida me divertí mucho con la charla de Berto Yáñez (@bertez) sobre Popcorn.js, un framework de la comunidad Mozilla para mejorar y ampliar la interacción de Javascript con las etiquetas <video> y <audio> de HTML5. Ambiente distendido, risas y código en directo. Sin duda de lo mejor del día.

Finalmente, como no, saqué el machete y conseguí abrirme paso para conseguir un asiento en la charla de David Bonilla (@david_bonilla). Hizo publicidad de Atlassian de forma muy elegante y para nada encubierta, e hizo alguna que otra crítica constructiva a varias empresas y a algunas actitudes que tenemos los desarrolladores. Por supuesto el tema era interesante de por si, y algo que a mi personalmente me interesa bastante: como atraer a los desarrolladores a tu plataforma/producto para crear un ecosistemas de desarrollo. Conseguir esto es el santo grial, ya que te proporciona una base de desarrolladores enorme que va a extender y enriquecer tu producto de forma totalmente gratuita. En contrapartida los desarrolladores tienen la oportunidad de ganar dinero y/o hacerse una reputación o simplemente divertirse. Quizás el único fallo de la charla de David fue su excesiva duración, ¡ que ya era última hora y estábamos todo deseando ir a unas cañas :-) !

Me gustó

Un acierto desde mi punto de vista el reunir a comunidades de distintas plataformas de desarrollo, PHP, Ruby, Python, JavaScript, Java y .NET, y también alguna charla de DevOps y de Agile. La variedad es lo que ha distinguido a esta conferencia de otras. ¡Espero que se rompan las barreras endogámicas que separan a cada comunidad de desarrollo!

Por supuesto me gustó bastante el ambiente, el ver estudiantes siempre es bueno desde mi punto de vista. Es importante que las nuevas generaciones vayan viendo lo que se cuece en el mundo real, ya que desgraciadamente la carrera universitaria suele estar muy alejada de la realidad y anticuada en la mayor parte de los casos (con honrosas excepciones). También es interesante que vean que existen conferencias sobre informática en España, y que no tienen porque irse al extranjero para asistir a una conferencia interesante.

También me pareció un buen detalle el cocktail que los organizadores ofrecieron a los ponentes.

Y como no, lo mejor, que como en todas las conferencias, fue la oportunidad de hacer networking con gente nueva por un lado, y reencontrarse con viejos compañeros de viaje.

Cosas a mejorar

Tal vez el próximo año sería mejor que todos los ponentes comieran junto a los asistentes. Con el cocktail es más que suficiente.

Otro detalle fue que hubo demasiada gente. Esto hizo que todas las salas estuvieran muy llenas y que en algunos casos se estuviera bastante incómodo.

UPDATE: Se me olvidaba, hubiera sido muy interesante tener “stands” para las distintas comunidades de desarrolladores que han participado en el evento. Los asistentes podrían haber trabado mejor contacto con otras comunidades de esta manera. Como co-organizador de MadridJS, creo que para el año que viene sería muy interesante tener esto.

Sobre mi charla

Tengo que comentar un par de cosas sobre mi charla. Tal vez algunos asistentes se pensaron que iba a hablar más de CSS orientado a objetos. En realidad esta charla es la hermana de otra que di en la XPWeek el año pasado. Para mi las dos charlas constituyen dos caras de la misma moneda, en una me centro más en CSS y en otra exploro más el diseño javascript. Lamento la posible confusión que pueda haber causado el título y la descripción de mi charla (que es responsabilidad mía no de la organización).

En mi charla sobre CSS orientado a objetos que di el año pasado me centré sobre todo en la parte de CSS, y solo hablé de pasada sobre la arquitectura javascript, y está más orientada a diseñadores. Para los realmente interesados, y la gente que se quedó con ganas de saber más de OO CSS, pueden encontrarla aquí.

Sin embargo en la charla que di en codemotion me quise centrar en los valores “ágiles” y en la arquitectura de software para aplicaciones javascript, como medio para facilitar la colaboración eficaz entre desarrolladores y diseñadores. Obviamente está más orientada a desarrolladores. Esta última está colgada aquí. La he hecho con impress.js así que necesitaréis un navegador “moderno” que soporte HTML5 para verla. Por cierto, mi idea era ver bastante código, pero no me fijé en que las charlas eran de 45min y la cosa quedó bastante corta en ese aspecto. Afortunadamente todo el código está disponible para que lo miréis en Github aquí.

En cualquier caso creo que ambas charlas pueden ser interesantes para ambos roles, y quizás ayuden a entender un poco más lo que implica el trabajo de uno y otro.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 42 seguidores