Proyecto de ejemplo: https://github.com/spring-projects/spring-security/tree/5.0.0.RELEASE/samples/boot/oauth2login Pasos: Crear nueva aplicación en la consola de google (https://developers.google.com/identity/protocols/OpenIDConnect): https://console.developers.google.com/cloud-resource-manager?previousPage=%2F Crear credenciales OAuth para la aplicación: https://console.developers.google.com/apis/credentials?project=… Asegurarse de que en redirect URI se pone http://localhost:8080/login/oauth2/code/google en application.properties establecer las propiedades spring.security.oauth2.client.registration.google.client-id y spring.security.oauth2.client.registration.google.client-secret

Ayer tuvimos la segunda sesión de DDD en las oficinas de Comalis. Personalmente se me hizo bastante corto ya que tuvimos bastante debate y muy interesante. Yo aprendí muchísimo… pero por otra parte salí con nuevas lagunas. Empezamos con una pequeña introducción por parte de Tamara de Comalis sobre la empresa. Se dedican fundamentalmente al hosting, cloud, antispam, ssl, etc. Son franceses (el CPD esta en Lyon) pero tienen las oficinas aquí, en Sevilla. Tienen programa de afiliados, así que si os interesa os podéis poner en contacto con ellos que son muy agradables, nos tenían preparado hasta café y pastitas. En lo técnico, repasamos el origen de DDD, la importancia de la reducción de la carga cognitiva al dividir el problema en varios contextos y no tener que mantenerlos todos a la vez en la cabeza. Esto puede implicar que tengamos datos duplicados entre contextos, pero de lo que se trata no es de optimizar en lo técnico, sino de desarrollar un software de calidad, flexible y adaptable. También pasamos por encima del lenguaje ubicuo, que es el lenguaje que utilizamos para definir y describir el sistema. Debe estar lo más próximo posible al lenguaje del negocio para malentendidos o directamente definir mal el sistema. Una vez expuesta la parte más abstracta, pasamos al caso concreto: la gestión de un gimnasio. Dentro de un gimnasio podemos tener distintos contextos: facturación, mantenimiento, gestión de personal o el técnico como tal. Este técnico puedo incluir definir rutinas para los clientes y que estos puedan ir apuntando las actividades que van realizando en el gimnasio. El caso de estudio se centraba en esta última parte, en concreto propuse dos historias de usuario:

Docker es una tecnología de contenedores relativamente reciente (de 2013) que si bien ha puesto sobre el terreno de juego el concepto de contenedores (aunque estos son tan antiguos como del 2005 que fue cuando salieron con Solaris…). Un contenedor viene a ser una máquina virtual ligera, en realidad es una aplicación (se ejecuta en espacio de usuario, usa el kernel del sistema operativo, etc…) en la que se puede instalar un sistema operativo y unas aplicaciones (una imagen) y por tanto se comportará como una máquina virtual a efectos prácticos. La ventaja de esta aproximación es que mientras una máquina virtual tiene unos recursos fijos que toma del sistema anfitrión, Docker no, con lo que es más eficiente y ligero. La verdad es que todo el mundo habla de Docker, pero todavía no me he encontrado a nadie que lo use en producción. No obstante, este sistema es muy cómodo para montar entornos de desarrollo. Lo primero, como siempre, es instalar Docker. La página de [instalación] (https://docs.docker.com/engine/installation/linux/ubuntu/) no refiere aún información para Ubuntu 17.04, a ver que me voy encontrando. El primer paso de la instalación es instalar una serie de paquetes que para mi sorpresa (no) ya tengo instalados. A continuación, y resumiendo las detalladísimas instrucciones de instalación (esto es buena documentación y lo demás son tonterías), los pasos para la instalación son los siguientes:

Con Spring Boot es relativamente sencillo generar un backend para una aplicación por complejo que sea su dominio, precisamente lo bueno de Spring Boot es que permite realizar rápidamente todo el trabajo de infraestructura para centrarse por una parte en el código del dominio y por otra… en la UI. En los últimos años hemos pasado de un paradigma de desarrollo en servidor a uno nuevo cliente/servidor (otra vez). El servidor suele ser una API [REST ] (https://en.wikipedia.org/wiki/Representational_state_transfer) mientras que los clientes son típicamente aplicaciones Android, iOS y Web (lo cual incluye otros servicios REST y con eso emergen los microservicios…). En materia de clientes web, el ganador en toda la historia ha sido JavaScript y básicamente, dentro de JavaScript hay dos grandes frameworks:

Una de las funcionalidades básicas de Hibernate es abstraer la base de datos, pero sin embargo en tiempo de desarrollo resulta bastante útil controlar las consultas que va generando el motor así como sus parámetros. Desde las primeras versiones Hibernate tiene una propiedad, show_sql que muestra estas consultas por consola. Esto tiene dos desventajas, la primera que usa la consola y la segunda que para habilitarlo y deshabilitarlo se depende de un archivo de configuración específico (normalmente el propio de Hibernate o incluso una clase Java si se esta utilizando la configuración Java de Spring). Además este parámetro tan sólo muestra las consultas y no los parámetros de las mismas. La solución idónea pasa por utilizar el sistema de logging estándar que se utilice en la aplicación, así se puede mostrar en consola o registrar en un archivo o cualquier otro tipo de solución y además su activación y desactivación se hace en el sitio lógico, el archivo de configuración de logs de la aplicación. Otra ventaja es que, además, con su configuración oportuna se pueden logar también los parámetros de las consultas (algo muy útil para contrastar con nuestro cliente SQL favorito). Para poder mostrar estos logs hay dos loggers propios de Hibernate que configurar: