Spring 5 y Spring Boot 2. Controladores Asíncronos
Por fin, tras varias versiones de Spring, con Spring 5 y Spring Boot 2 han añadido la posibilidad de implementar controladores asíncronos y no bloqueantes, desterrando así la programación tradicional síncrona y bloqueante de los Servlets. Además, para la parte asíncrona, han utilizado el framework Netty, lo cual creo que es la elección acertada.
He creado un proyecto muy sencillo en GitHub para mostrar diferentes modos en los que podemos utilizar Spring Boot 2 para crear controladores asíncronos:
https://github.com/rekkeb/springboot2-async-controllers
Cualquier feedback será bienvenido 😉
Referencias:
Estadísticas 2015
En primer lugar quería agradecer a tod@s l@s que visitáis el blog que dediquéis parte de vuestro tiempo a leer lo que escribo. Muchas Gracias!!!!
Nos vemos en 2016.
Ya sabéis, cualquier duda, mejora, sugerencia, etc… será siempre bien recibida.
Estadísticas de visitas mensuales de este año 2015:
Estadísticas de post publicados durante este año 2015:
Estadísticas de visitas durante estos años:
Visitas por países:
Docker, elimina todas las imágenes con un solo comando
Cuando trabajamos con Docker y queremos eliminar todas las imágenes que hayamos descargado, tan sólo tenemos que ejecutar el siguiente comando:
docker rmi $(docker images -q)
NOTA: Si estáis en un sistema Linux, quizás tengáis que utilizar sudo delante del comando.
Recordad que si las imágenes se están utilizando en algún contenedor, Docker os mostrará un error indicando que la imagen se encuentra en uso. Podréis forzar el borrado de la imagen con el parámetro -f o bien, eliminar en primer lugar el contenedor o contenedores.
Empezando con Akka
Estos días me he propuesto empezar a aprender y utilizar Akka para practicar la programación orientada a Actores e incorporar herramientas nuevas a mis proyectos que me permitan obtener el máximo rendimiento en cada uno de ellos.
En mi repositorio de Github tengo un ejemplo muy simple que he hecho con Akka y que os animo a que reviséis y critiquéis todo lo que consideréis oportuno. Cualquier crítica y mejora, será siempre bien recibida.
Estoy documentándome utilizando varias fuentes que quería recomendar, porque me parecen muy buenas y estoy aprendiendo mucho con ellas.
- En primer lugar la documentación oficial de Akka (yo estoy consultando la versión para Java)
- Libro – Akka in Action: Aún no está a la venta, pero ya puede descargarse el primer capítulo desde la web de Manning y además está disponible el acceso al repositorio de GitHub donde están añadiendo el código fuente que utilizan en el propio libro.
- Libro – Effective Akka: Este libro está muy orientado a la práctica con Akka. Evita centrarse en teoría o en explicar qué es Akka y va más al grano con ejercicios, buenas prácticas, patrones…
Os dejo a continuación los enlaces a Amazon de cada uno de estos libros que os comentaba.
|
|
|
|---|
¿Alguna sugerencia para aprender/utilizar Akka? Fuentes, documentación, buenas prácticas, ejemplos de código, ….
Saludos 🙂
Cuando trabajamos con Docker y, sobre todo, cuando estamos haciendo pruebas con imágenes y contenedores, hay ocasiones en las que al ejecutar el comando «docker ps -a» para ver todos los contenedores que tenemos, nos aparece una lista bastante extensa.
Hay una forma muy sencilla de eliminar todos estos contenedores (ojo sólo los contenedores, no las imágenes) y dejar nuestro sistema limpio para volver a empezar, y para ello sólo tenemos que ejecutar el siguiente comando:
docker rm $(docker ps -a -q)
NOTA: Si estáis en un sistema Linux, probablemente tendréis que utilizar sudo delante del comando.
El otro día, haciendo unos tests de integración con Spring para un servicio REST, me encontré con la necesidad de inyectar una dependencia en un servicio que fuera un objeto Mock, al que pudiera modelar el comportamiento. Necesitaba que el test de integración probara todas las llamadas necesarias sobre mi servicio, pero no me interesaba que la dependencia que tenía inyectada mi servicio con @Autowired hiciera llamadas reales, ya que en este caso eran contra APIs terceras con cuota de pago.
Por tanto, como en mis tests unitarios suelo utilizar Mockito, se me ocurrió que podría inyectar la dependencia para llamar a APIs terceras en forma de Mock, de modo que las llamadas reales nunca se hagan en los tests. Por tanto, quería mostraos cómo crear un Bean desde vuestros contextos XML, que fueran mocks con Mockito.
Cuando creamos un Mock con Mockito desde código (sin utilizar sus anotaciones) hacemos algo como lo siguiente:
MyService myService = Mockito.mock(MyService.class)
Por tanto para hacer esto mismo desde nuestro contexto en XML, haríamos:
<!-- Mocked Beans --> <bean id="myService" class="org.mockito.Mockito" factory-method="mock"> <constructor-arg name="classToMock" value="com.service.MyService"/> </bean>
Lo siguiente a tener en cuenta, es que probablemente tengamos una etiqueta de tipo <context:component-scan/> para escanear automáticamente nuestros Beans y como este Bean Mockeado de MyService lo estamos creando manualmente, tenemos que decirle a Spring, que no es necesario que lo escanee él, que ya lo creamos nosotros. Para ello utilizamos los exclude-filter:
<!-- Scans all the Service Beans, except the ones we need to mock--> <context:component-scan base-package="com.service"> <context:exclude-filter type="assignable" expression="com.service.MyService"/> </context:component-scan>
Si tenéis cualquier duda, sugerencia, mejora, … Será siempre bien recibida 😉
Más Info:
The IoC Container | http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html
—
Libros de Referencia:
Spring.Tercera Edición (Anaya Multimedia/Manning)
No soy un recurso
⚠ Atención!! Opinión personal
Desde que empecé a dedicarme al mundo de la informática en la empresa privada, no he dejado de escuchar cómo se refieren a nosotros con el término «Recurso». Es muy común escuchar frases del tipo: «Necesito un recurso Java, para tal proyecto».
¿En serio? ¿Un recurso java? Quizás se refieran a la JVM, no lo sé.
Pero la lástima, es que sí lo sé. En nuestra profesión, se nos considera recursos, no personas. Da igual que seas un máquina en Groovy, que seas un experto en Hadoop; la realidad es que somos un recurso. Como una silla o una mesa.
Cada día, cada vez que escucho esa palabra para referirse a nosotros, no puedo evitar levantar la mano y pedir que se rectifique ese término, no es tan difícil; simplemente hay que cambiar «recurso» por «persona».
Aún así, creo que el problema es más profundo de lo que parece en un principio, ya que compañeros míos que antes programaban codo con codo conmigo y ahora se dedican a tareas de gestión como jefe de proyecto, se refieren a nosotros mismos como recursos. Venga!! De nosotros depende cambiar esto, es súper fácil.
Los equipos los forman personas, no recursos. Personas con cualidades, unos mejores, otros peores, unos más inteligentes, otros menos. «Cosificar» los equipos y referirse a nosotros como recursos no provoca que el rendimiento sea mejor ni que los tiempos de entrega se reduzcan. Lo único que provoca es que cueste menos prescindir de alguien en concreto llegado el momento.
Y esto me huele a alcanfor y a antiguo, de una forma exagerada. Huele a empresa dinosaurio. Huele a que no hemos avanzado nada. Incluso, las personas encargadas de velar por las personas dentro de una empresa se llaman «Recursos Humanos»!!!!!!
Creo firmemente en que podemos cambiar todo esto, es muy sencillo, sólo depende de nosotros. Estoy muy seguro de que un equipo de personas funciona infinitamente mejor que un equipo de recursos.
Así es que, cambiémoslo, seamos mejores, seamos excelentes; yo lo tengo muy claro: No soy un recurso.
Convierte tu bucket de S3 en un Repositorio de Maven
El objetivo de este post es mostrar cómo podemos tener un repositorio Maven al estilo de Artifactory o Nexus, pero en un Bucket de S3.
Y quizás, la pregunta sea: ¿Y para qué quiero hacer eso?
Por mi parte, he encontrado varias respuestas a esa pregunta que me compensan y que me han animado a buscar esta alternativa.
- Me olvido de tener que mantener un servidor físico y que esté operativo el 100% del tiempo
- Tengo mis artefactos en alta disponibilidad y replicados en múltiples zonas de disponibilidad
- Utilizando CloudFront junto con S3 puedo tener una baja latencia de acceso en cualquier parte del mundo
- Puedo controlar la privacidad de mis artefactos de forma granular y controlar el acceso al bucket de forma muy precisa con las políticas IAM de AWS
- No tengo que preocuparme por la cantidad de artefactos que estemos almacenando y el tamaño que ocupen
- Los tiempos de lectura y escritura son difícilmente mejorables por un servidor tradicional
- Puedo acceder a los artefactos desde cualquier lugar
- Los precios de S3 son muy asequibles
- Puedo utilizar la consola de AWS para gestionar mis artefactos, las herramientas AWS-CLI, o los plugins para los navegadores
Vamos a ver cómo configuramos todo para tener nuestro repositorio en S3. Es terriblemente sencillo.
MongoDB. Repara tus bases de datos
Cuando estamos trabajando con MongoDB y estamos realizando operaciones de manera continuada sobre una Base de Datos: crear colecciones, insertar documentos, eliminar documentos, eliminar colecciones… Puede que nuestras Bases de Datos lleguen a ocupar mucho más espacio en disco del que aparentemente deberían ocupar.
Personalmente, me he encontrado situaciones, en las que he estado haciendo pruebas con Bases de datos, en las cuales creaba varias colecciones, insertaba un montón de documentos, creaba índices, eliminaba documentos… y, por último, eliminaba todas las colecciones (y documentos) para dejar mi Base de datos limpia. En este punto observaba cómo la base de datos ocupaba un espacio excesivo en disco en comparación con los datos que tenía. Buscando el por qué de este comportamiento, estuve estudiando el modelo de almacenamiento en disco de MongoDB, para conocer cómo almacena realmente los documentos en el disco y encontré que, cuando una base de datos se «desmadra», podemos ejecutar un comando para repararla.
Tenemos dos modos de hacerlo:
1. Reparar una única base de datos
Para ello, desde la consola de MongoDB y con nuestro mongod ejecutándose, lanzamos el siguiente comando:
> use myDb > db.repairDatabase()
+Info: myDb es el nombre de la base de datos que vamos a querer reparar
2. Reparar todas las bases de datos
En este caso, debemos detener todos los procesos mongod que tengamos ejecutándose, y lanzar el siguiente comando desde nuestro Terminal:
mongod --repair
De este modo, MongoDB comenzará a reparar todas las Bases de Datos y mostrará la evolución del proceso en pantalla.
Espero que estos comandos os sean útiles y ya sabéis: cualquier mejora, sugerencia o crítica será bienvenida 😉
Lecturas Recomendadas
- MongoDB: The Definitive Guide
(Amazon)
Más Info
- MongoLab | How Big is Your MongoDB?
PIG. Filtrado en base al tamaño de cada tupla
Actualmente me estoy adentrando poco a poco en el mundo del BigData, con Hadoop y todo su ecosistema; especialmente mediante AWS y ElasticMapReduce.
El asunto es, que durante estas semanas he estado desarrollando unos scripts de PIG para analizar la gran cantidad de logs que generan las diferentes APIs REST que hemos desarrollado en mi trabajo. Estas APIs generan logs con la actividad que realizan los usuarios sobre ellas y esta información se analiza para obtener estadísticas y saber las invocaciones que realiza cada usuario y el uso general que se hace de cada API. (No hay información sensible 🙂 )
El formato en el que están almacenados los logs, ha ido variando conforme las APIs han ido creciendo y evolucionando, y por tanto, conviven diferentes versiones de entradas de logs.
Las diferentes versiones de las entradas de logs son casi idénticas entre sí; sólo varía la posición de los campos y la longitud de la entrada, es decir, el número de campos que tiene cada una. Un ejemplo de los logs de los que hablo podría ser el siguiente (La primera línea es meramente informativa, para poner nombre a los campos; no se almacena):
Date | Id App | Id Num | User | IP | API Name | Method | ResponseCode | Timestamp 12:23:40,878 12-01-2014| myApp | 95 | developer | 10.0.51.67 | MiApi | POST | 201 | 1380536454505 |
Poco después se añadió a los logs información sobre el servicio que ha sido invocado dentro de cada API, por ejemplo:
Date | Id App | Id Num | User | IP | API Name | Service | Method | ResponseCode | Timestamp 12:23:40,878 12-01-2014| myApp | 95 | developer | 10.0.51.67 | MiApi | /test.json | POST | 201 | 1380536454505 |
Por tanto se hacía necesario poder diferenciar una tupla de otra y mi intención era lograrlo utilizando PIG.
Como sabéis, Apache PIG es una plataforma para analizar y procesar grandes cantidades de datos, que cuenta con su propio lenguaje conocido como PigLatin. Mi objetivo es diferenciar las tuplas directamente con PigLatin, sin recurrir al uso de UDF’s personalizadas.
Filtrar las tuplas en base a su tamaño es muy sencillo, pero me costó mucho lograrlo y buscando en internet no conseguía encontrar nada parecido que me pusiera tras la pista. Por eso lo publico aquí, por si a alguien más le puede servir de ayuda.
Rekkeb's Blog 