Ir al contenido principal

Entradas

La regla del Boy Scout

  Los Boy Scouts tienen una regla sobre el lugar donde acampan, siempre hay que dejar la zona del campamento en mejor estado de como se encontró al llegar. Si esto lo extrapolamos al mundo de la Calidad del Software, se podría decir que siempre que realicemos cualquier modificación intentemos mejorar el código que nos encontramos. Todos los que llevamos tiempo programando sabemos que con el paso del tiempo, si estamos evolucionando un proyecto el código se va deteriorando. La culpa de esto normalmente es nuestra (de los desarrolladores), que por diversas causas (presión, incidencias bloqueantes,...) empezamos a hacer que el código se degrade. Si conseguimos aplicar esta regla, podremos mejorar un poco la calidad de nuestro software. Por supuesto esto solo es posible si no estamos trabajando bajo presión, y es posible dedicar un poco de tiempo a realizar estas mejoras. Os voy a poner un pequeño ejemplo a mejorar. Supongamos que tenemos la siguiente función: public boolean rest...

Recargando

Cuando llega Agosto normalmente estoy muy sobrecargado y necesito tomarme unas semanas para respirar y descansar del mundo informático. Normalmente aprovecho este mes para “desconectar” e intentar retomar antiguos (y saludables) hábitos. Además este año ha sido “diferente”, mi vida laboral ha pegado un giro de 180 grados, y todavía me estoy acostumbrando. A veces necesito enfocar toda mi atención en otra cosa, sin tener pensamientos en segundo plano, y este verano me propuse resolver el cubo de Rubik. También he conseguido recuperar dos buenas costumbres: La lectura : me gusta mucho leer, pero hace unos años, de repente, dejé de hacerlo. Últimamente al año me leía sólo dos o tres libros. Gracias a “ Good Reads ” y “ EBiblio ”, he conseguido retomar la lectura. Este año llevo más de 20 libros. Jugar al ajedrez : me encanta el ajedrez, y ¿sabéis cuánto tiempo llevaba sin jugar? Más de diez años... Estuve buscando una aplicación con vídeos para que mis peques aprendieran de forma amena lo...

Lectura para el verano

Este verano he decidido cerrar el portátil y aprovechar para leer. Me he decidido por "Código Limpio" que es un repaso a las bases de la programación (la puerta de entrada al mundo de QA). Para ser un libro técnico se lee muy bien, y está escrito con muchos ejemplos. Ideal para leer con este calor. Me está ayudando a corregir algunos pequeños vicios y ya he empezado a programar siguiendo algunos de sus consejos. Ya llevo casi la mitad del libro y estoy muy contento, así que os lo recomiendo sin dudarlo. Y vosotros, ¿me recomendáis algún libro técnico?

Tests dinámicos con JUnit5

  Hoy os quiero hablar de los  test dinámicos . Cuando pensamos en realizar test, normalmente tenemos muy claro las funcionalidades que queremos comprobar, pero a veces esas funcionalidades varían con el paso del tiempo, y nuestras pruebas tienen que adaptarse a estos cambios. Aquí es donde entran en juego los test dinámicos. Os voy a poner un par de ejemplos de este tipo de test: Imaginaros que tenéis que chequear un menú dentro de una pagina web, y ese menú actualmente tiene 4 opciones. Puede pasar que dentro de unos meses las opciones aumenten. Un test dinámico, primero leerá todas las opciones que tiene el menú, y después realizará las pruebas establecidas por cada una de ellas. Pensar en una base de datos que se carga todos los días a las 03:00 AM, y a las 04:00 AM se lanzan una serie de consultas de BBDD para verificar que la información es correcta. Imaginaros que algunas consultas se leen de un directorio que contiene ficheros *.QRY en los cuales están las consult...

Apache Derby vs. SQLite

Hoy os traigo un pequeño análisis para contaros las diferencias entre dos bases de datos que nos pueden venir muy bien para proyectos pequeños o para infraestructuras con un tamaño inicial reducido. La primera se llama SQLite ( https://www.sqlite.org ), y es un sistema de base de datos que se encuentra dentro de muchas aplicaciones que utilizamos normalmente como navegadores o aplicaciones del móvil. Es muy ligera, cada base de datos se gestiona dentro de un solo fichero y es ideal para procesos que no necesitan acceso concurrente. Por ejemplo para una aplicación de consola que se ejecuta periódicamente, y lo único que necesita es actualizar la información a través de un solo hilo en cada ejecución. La otra se llama Apache Derby ( https://db.apache.org/derby/ ), esta base de datos también se ejecuta en memoria, ocupa muy poquito espacio, y la mayor diferencia es que está preparada para procesos concurrentes. Por ejemplo una aplicación web donde varios hilos pueden escribir/consultar a ...

Procesando ficheros grandes en JAVA

Llevamos unas semanas con varias filtraciones de datos, hace unas semanas hubo una de Facebook, y hoy hemos tenido otra con datos de una empresa de telefonía... Cuando nos enteramos de estas cosas, nos gustaría saber si se han filtrado nuestros datos, pero para eso hay que tener los datos (algo que a veces es difícil de encontrar) y después tener las herramientas para abrir esos ficheros. En los dos casos que he comentado, los ficheros eran texto plano, en formato CSV. El primero ocupaba 800 MB y el segundo 5,36 GB Yo no he conseguido abrir ninguno con las herramientas habituales. Así que he escrito un pequeño programa que lee línea a línea cualquier fichero, busca en cada línea la cadena que nos interese, y las coincidencias que encuentra las escribe en otro fichero. Podéis acceder a ese desarrollo desde aquí:  https://github.com/tecnificados/bigFileOpps Espero que os sea útil. Nos vemos pronto. Muchas gracias a  Hugo y a Valandil por su ayuda consiguiendo los datos.

Spring Boot: un CRUD hecho y derecho

  Este es el quinto (y último) artículo de la serie sobre  Spring Boot  que comenzamos el mes de Febrero. Estos son los anteriores: Introducción Página inicial con Bootstrap Spring Boot: Trabajando con bases de datos Spring Boot: Seguridad básica El proyecto con el que estamos trabajando esta en GitHub y esta es su URL:   https://github.com/tecnificados/boot Hoy vamos a coger todo lo que hemos aprendido y transformar nuestras diferentes pruebas en un CRUD de Incidencias.  Antes de nada, ¿qué es eso? CRUD es un acrónimo de CREATE, READ, UPDATE Y DELETE. Cuando alguien nos habla de este término, a lo que se refiere es a un proyecto que permite realizar estas operaciones sobre una o más entidades. En los diferentes commits que he hecho estos dos días he ido añadiendo operación por operación los diversos cambios en un nuevo Controlador ( IncidenciasController ), y añadiendo las diferentes JSPs: Creo que se pueden seguir muy fácilmente, por lo que esta vez no vo...