Skip to content

Estadísticas 2015

31 diciembre 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:

months

Estadísticas de post publicados durante este año 2015:

posting

Estadísticas de visitas durante estos años:

years

 

Visitas por países:

countries

 

Docker, elimina todas las imágenes con un solo comando

24 octubre 2015
tags:

docker-logo-loggedout

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

29 marzo 2015
tags:

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.

  1. En primer lugar la documentación oficial de Akka (yo estoy consultando la versión para Java)
  2. 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.
  3. 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.



  Akka in Action    



    Effective Akka   

¿Alguna sugerencia para aprender/utilizar Akka? Fuentes, documentación, buenas prácticas, ejemplos de código, ….

Saludos 🙂

Docker, elimina todos los contenedores con un solo comando

19 marzo 2015
tags:

docker-logo-loggedout

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.

Spring: Crear un Mock de un Bean desde los ficheros XML de Contexto

17 enero 2015

SpringSource

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)(Amazon.es)

No soy un recurso

29 noviembre 2014

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

8 noviembre 2014

apache-maven-project

 

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.

  1. Me olvido de tener que mantener un servidor físico y que esté operativo el 100% del tiempo
  2. Tengo mis artefactos en alta disponibilidad y replicados en múltiples zonas de disponibilidad
  3. Utilizando CloudFront junto con S3 puedo tener una baja latencia de acceso en cualquier parte del mundo
  4. 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
  5. No tengo que preocuparme por la cantidad de artefactos que estemos almacenando y el tamaño que ocupen
  6. Los tiempos de lectura y escritura son difícilmente mejorables por un servidor tradicional
  7. Puedo acceder a los artefactos desde cualquier lugar
  8. Los precios de S3 son muy asequibles
  9. 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.

Leer más…