Clean Code

1) Meaningful Names

Usar nombre relevantes y de intención. No usar una variable llamada «d» y si «fileAgeInDays»

Evitar usar nombres  que no den información.

No usar como nombre el tipo de variable que es. No usar «accoundList pero si accounds».

Evitar la desinformación.

No usar nombres largos que solo se diferencien en una palabra. No usar el mismo nombre para cosas que signifiquen lo mismo.

No usar nombres que sean impronunciables. Ej: genymdhns.

Usar nombres que sean fáciles de buscar.

No usar prefijos.

Si tenemos interfaces e implementaciones, es preferible poner «Impl» a la implementación que no «I» a la interface.

Los nombres de clase tiene que ser nombres. No deben ser un verbo.

Los nombres de los métodos tienen que ser verbos.

No usar nombres graciosos.

Una palabra, un concepto.

Usar nombres por contexto. Ej: «State» de dirección y estado de la variable.

2) Functions

Las funciones tienen que tener un tamaño reducido. Tiene que ser lo suficientemente grande que se pueda entender.

Las funciones solo deben hacer una cosa. Deben hacerlo bien y deben ser lo único que hagan.

Para validar que solo hace una cosa, se puede escribir usando un párrafo con TO.

Las funciones tienen que contener elementos que estén en el mismo grado de abstracción. No mezclar niveles de abstracción.

Poner las funciones de abajo a arriva.

No usar un switch. Usar una factoría de objetos y solo usar el switch para crear estos objetos. Un switch viola el principio de responsabilidad único y el de abierto cerrado.

Invierta tiempo en elegir un nombre y cámbielo las veces que sea necesario. Tienen que ser descriptivos.

Es mejor no usar parámetros para llamar a las funciones. Cuantos más argumentos, más difícil es de testear el código. Hay que disminuir el número de argumentos, por ejemplo, añadiéndolo a un objeto.

Si añadimos contexto a los nombres, podemos mejorar su lectura. Ej: write(name), es mejor writeField(name).

No usar parámetro boolean que signifiquen comportamiento.

Los argumentos de entrada es preferible que no sean de salida.

No usar código de errores, es mejor usar excepciones. Al usar clave de errores, se acopla el código a estos errores ya existentes, no se añaden códigos nuevos, se reutilizan los antiguos… con las excepciones se pueden añadir nuevas sin problema.

Los bloques try y catch es mejor extraer su cuerpo en funciones individuales.

Solo tener un punto de entrada y un punto de salida. Solo tener un return dentro de la función.

Una buena forma de trabajo es:

  • Estructurar las ideas
  • Crear funciones, no importan que sean extensas o complicadas, con sangrados y bucles anidados. Los nombres son arbitrarios, la lista de argumentos son extensas, código duplicado… pero con una batería de pruebas que abarcan todas las líneas
  • Retocar el código, dividirlo en funciones, cambiar nombres, eliminar duplicados.
  • Al final, se consigue que se cumplan las reglas descritas.

Escribir el código es como contar una historia.

Las funciones tienen que ser breves, con nombres correctos y bien organizadas.

Microservicios efectivos: 10 mejores prácticas

1. DDD: diseño impulsado por dominio

2. Un microservicio, un BD o tablas privadas

3. No usar frontales de monolitos

4. CI / CD. Es necesario tener una entrega continua y un despliegue continuo

5. Observabilidad

5.1 ELK: Logs

5.2 Prometheus : Monitorizar

5.3 Zipkin: Tracing

6. Unificar el stack de desarrollo.

7. Comunicación asincrona.

7.1 Message Queue : Kafka

7.2 Rest asincrono: Atom or CQRS

8. Microservicio primero

9. Infraestructura por encima de las librerías

10. Consideraciones organizacionales

 

Control de versiones – Trunk, Branch y Tag

Trunk, branch y tag son tres de los principales conceptos que tenemos que tener claro a la hora de usar un control de versiones. No nos importa el sistema de control de versiones que usemos, ya que son conceptos globales. Estos conceptos existen en CVS, Subversion, Git o Mercurial

  • Trunk (tronco): la línea o rama principal de desarrollo. Sobre esta rama se tiene el código que ya está preparado para una release. Idealmente debería tener un control de pruebas, test,… que permita que este código esté en un estado estable.
  • Branch (rama): copia de código para hacer cambios. Lo ideal es que cada desarrollador trabajara en su rama y luego, una vez validado los cambios, hiciera la integración con trunk.
  • Tag (etiqueta): sirve para identificar un cierto momento en el desarrollo que queremos preservar. Lugar ideal para marcar cambios de versión (alfas, betas, RC, RTM) y puntos de interés como copias de despliegues. Sobre un tag no se puede / no se debe hacer cambios.

SQLServer Eliminar todas las tablas de una base de datos




Vamos a eliminar todos las tablas de una base de datos.
Parece tan sencillo como seleccionar todas las tablas, botón derecho y eliminar… pero no es así, existen reglas de integridad referencial entre las tablas. Puedes intentar borrar una a una e ir borrando las relacionadas según te vaya dando errores… Suerte!!!!

Una forma sencilla de borrar las tablas, es siguiendo estos 3 pasos:

  • Desactivar la integridad referencial
  • Borrar las tablas
  • Volver a activar la integridad referencial

Para hacer esto, solo tenemos que ejecutar este script sobre una consulta de BBDD:

— Primero desabilitar la integridad referencial
EXEC sp_MSForEachTable ‘ALTER TABLE ? NOCHECK CONSTRAINT ALL’
GO

EXEC sp_MSforeachtable @command1 = «DROP TABLE ?»

— Ahora volver a habilitar la integridad referencial
EXEC sp_MSForEachTable ‘ALTER TABLE ? CHECK CONSTRAINT ALL’
GO

Volver a habilitar la integridad referencial puede parecer que no tiene sentido al haber borrado las tablas, es recomendable reactivarla para que su funcionamiento sea normal en adelante.

PD: Si no os ha borrado todas las tablas, es posible que la tengáis que ejecutar varias veces

SQLServer Añadir BBDD desde archivo local




Hola a todos. En este caso, vamos a añadir una BBDD desde archivo local a nuestro SQL Server Management Studio.

Partimos desde esta BBDD de prueba, donde por un lado tenemos los datos y por otro los permisos de usuarios.

BBDD_Pruebas

1) Lo primero que tenemos que hacer es asignarnos permiso a nuestro usuario de control total desde las opciones de windows. Para ello, sobre cada uno de los archivos pulsamos botón derecho -> Propiedades -> Seguridad y añadimos control total sobre nuestro usuario.

2) Ahora vamos a nuestro SQL Server Management Studio y nos autentificamos con la autentificación de windows.

SQLServerLoginWindows

3) Adjuntarla

3.1) A través de una consulta (Recomendado)

CREATE DATABASE prueba
ON (FILENAME = ‘C:\BBDD\prueba.mdf’),
(FILENAME = ‘C:\BBDD\prueba_log.ldf’)
FOR ATTACH;

3.2) A través del programa

3.2.1) Ahora, sobre «Bases de datos», Botón derecho -> Adjuntar

SQLServerAdjuntar1

3.2.2) Ahora pulsamos sobre Agregar -> La buscamos en nuestra carpeta de origen y aceptar

SQLServerAdjuntar2

4) Y ya tenemos añadida la BBDD. Ahora hay que crear un inicio de sesion y configurarlo para que esta BBDD sea suya. Para cualquier duda, consultar este post: instalar-sql-en-local

AOS 2014

El 2014/06/06 y 2014/06/07 se celebró en Valladolid el AOS, el Agile Open Space.

Este era mi primer Open Space al que asistía. Me habían hablado de él como algo muy interesante. Pues como me lo pintaron tan bien, tuve que ir, que remedio XD.

 

VIERNES

 

Nada más llegar, uno se encuentra con viejos amigos:

IMG_4577IMG_4591

 

Después de una presentación por parte del director de la escuela, del representante de los organizadores, propuesta un poco larga de temas y de una gran comida picnic, preparados para aprender.

 

Posibles charlas:

IMG_20140606_132306

 

De este primer día aprendí:

  • Test unitarios no por clase, sino por funcionalidad
  • Hay que hacer un esfuerzo extra si el equipo está deslocalizado
  • Preparar un entorno ágil y la gente aprenderá a ser ágil.

 

Sábado

 

Muchas fuerzas cogidas para este sábado intenso de hasta 6 charlas. Más gente conocida que el viernes no pudo venir y más ganas de aprender.

Posibles charlas para el sábado:

IMG_20140607_114042

 

De este segundo día aprendí:

  • No mutilar SCRUM, añadirle cosas
  • Primero decir NO a algo y luego discutirlo
  • Si quieres colaborar con el software libre, solo tu pones las barreras
  • Cuando un código está mal, siempre hay que dejarlo mejor de lo que estaba. Y tener cuidado cuando parar.
  • Pese a lo que todos creemos, los peores problemas para implantar las metodologías ágiles, son las personas que están en el medio de la jerarquía, o eso dicen XD.

 

 

Posibles mejoras:

  • Cuando se propone los temas de las charlas, los nombres son imposibles de acordarse de ellos y luego los buscamos para poder votarlos por la localización de su cartulina en la pared. Si se tuviera un cuadro de números y letras, sería más fácil de localizar. Por ejemplo, yo quiero votar la B5, la C3, …
  • Que las cartulinas tengan colores según su temática. Divididas en metodologías ágiles, dinámicas, …
  • Que haya una sala reservadas para charlas técnicas. Llega un momento que a uno le apetece una charla así.

 

 

Muchas gracias a los organizadores, lo han hecho genial y eso que la papeleta no era fácil.

Animo a asistir a estos eventos. SIEMPRE se aprende algo.

 

Solo morimos el día que ya no queremos aprender

Instalar BQ Aquaris para hacer debug en eclipse

Para poder utilizar nuestro dispositivo para hacer debug en IDE Eclipse, tenemos que hacer unos sencillos pasos.

  1. Descargar los driver en este enlace
  2. Hacer una copia de los driver que tenemos instalados en el sdk. Por norma general lo solemos tener en la ruta adt\sdk\extras\google\usb_driver
  3. Descomprimir y sobrescribimos en la carpeta usb_driver.
  4. Ir al administrador de dispositivos y configurar el dispositivo que no nos reconoce (por lo general lo reconoce con el nombre de «Android Composite ADB Interface»). Para esto, sobre Equipo->Propiedades->Administrador de dispositivos, seleccionamos el dispositivo USB que no nos reconoce y cambiamos el controlador. Si no nos lo encuentra, decirle que lo busque sobre la carpeta adt\sdk\extras\google\usb_driver donde hemos metido los nuevos controladores.

Espero que os sea de utilidad.

Uso de librería Hamcrest




Hola de nuevo.

Después de mucho tiempo sin escribir, creo que ya era hora que probara cosas nuevas. Tras visualizar las charlas de la CAS2013, me puse a escuchar la de Joaquin Engelmo , Adicto al verde. Esta charla me la recomendaron Soraya Vay y Javier Gamarra, los cuales asistieron a esa conferencia Agile Spain. Os recomiendo encarecidamente que veáis esa charla.

Una de todas las herramientas que expuso me quedé con una de fácil complementación y de fácil uso, como es la librería hamcrest. Esta librería permite hacer los assert con un mayor sentido semántico. Los assertEquals, assertTrue, … de toda la vida, tienes que pensar que poner en cada uno de los parámetros.

Ej: El assertEquals(parametro1, parametro2) se suele poner en parametro1 el valor esperado y en el parametro2 el valor obtenido. Esto es si te acuerdas el orden, ya que cuando estas escribiendo el assert se suele dudar al no ser este orden obligatorio.

Pues con la librería Hamcrest, esto no vuelve a pasar. Pasamos del assertEquals(parametro1, parametro2); a assertThat(NOMBRE_TEST, equalTo(user.getNombre())); Como vemos, no solucionamos lo del orden de valor esperado y lo de valor obtenido, pero nuestro assert mejora en su significado semántico.

Partimos de esta clase sobre la que queremos hacer test:

User.java

Una vez que tenemos esta clase de origen, realizamos los test para cada uno de sus atributos.

UserTest

 

Como vemos, la semántica adquiere mayor valor.

Pasos para implementar esta librería (por si acaso XD):

Descargarse la librería desde el sitio oficial Hamcrest-Descarga y descargarse la «hamcrest-all-1.3.jar» e incorporarla al proyecto del test (tanto en la carpeta de lib y en el buildpath)… y YA TAAAAAAA. Ahora, si se quiere tener la navegación, descargaros «hamcrest-all-1.3-sources.jar». Todo esto lo tenéis por separado o en el archivo «hamcrest-1.3.zip».

Conclusiones rápidas e incluso diría poco ciertas:

  • Con poco esfuerzo podemos dar un mayor valor semántico a nuestros assert de los test
  • Nos permite seguir utilizando los assert anteriores por si no nos sentimos cómodos con esta librería, lo que no nos ata a ella.
  • Si estamos utilizándola significa que estamos haciendo test, aunque sea solo para probarla. Otra razón por si todavía hay indecisos (y es que los hay).
Hacer test, probarla, seguir haciendo test… VERDE es bueno y ROJO solo es el paso anterior al VERDE, que es bueno

 

 

Instalar SQL Server en local




Hola a todos. En este «experimento», voy a mostrar como se instala SQL Server en local.

Lo primero es lo primero, para poder instalar SQL Server en local, necesitamos 2 programas:

El primero es una BBDD de SQL Server para desarrollar y el segundo es una herramienta gráfica para administrar SQL Server.

1) SQL Server 2008 R2

Seleccionamos SQL Server Configuration Manager.

1

Una vez dentro de SQL Server 2008 R2, tenemos que configurar los protocolos de SQLEXPRESS. Para ello, pulsamos sobre «Protocolos de SQLEXPRESS», seleccionamos «TCP/IP» con el botón derecho y vemos sus propiedades:

QL Server 2008 R2 protocolos sql

 

Tenemos que establecer bien el puerto sobre el que se va a ejecutar.  Para ello, sobre la pestaña de «Direcciones IP», tenemos que ir al último apartado e introducir el puerto 1433 en la fila de nombre «Puerto TCP».

QL Server 2008 R2 SQL propiedades

 

Ahora tenemos que habilitar los servicios propios de SQL Server. Para hacer esto, sobre el menú de la izquierda, seleccionamos «Servicios de SQL Server». En el apartado de «SQL Server (SQLEXPRESS)», mostramos sus propiedades con el botón derecho y accedemos a la pestaña «Servicio». En la fila de «Modo de Inicio», lo dejamos en automático.

QL Server 2008 R2 Servicio

 

Con esto hemos terminado con la primera parte y ya tenemos instalado lo necesario con el programa SQL Server 2008 R2

2) SQL Server Management Studio

Ahora ejecutamos el programa SQL Server Management Studio. Nos aparece una pantalla de autenticación. Seleccionamos la «Autenticación de Windows» y nos conectamos. NOTA: si hemos instalado la versión express, en el login hay que poner «\sqlexpress» seguido de localhost.

SQL Server Management Studio Login

 

Una vez logueado, sobre los «Inicios de sesión», creamos un nuevo usuario:

SQL Server Management Studio Crear usuario

Ya tenemos el usuario creado

SQL Server Management Studio Usuario creado

Sobre el apartado de «Bases de datos», creamos una nueva base de datos.

SQL Server Management Studio Crear BBDD

Ya tenemos la BBDD creada:

SQL Server Management Studio BBDD creada

Ahora solo tenemos que asociar el usuario a la base de datos que antes creamos. Para esto, sobre las propiedades del usuario, en el apartado «General», indicamos sobre «Base de datos predeterminada», la base de datos.

SQL Server Management Studio Asociar usuario

Ahora sobre el apartado de «Asignación de usuarios», asignamos la base de datos que creamos en primera instancia.

SQL Server Management Studio Asociar BBDD

Posibles pasos extras que tendremos que hacer para que funcione:

1) Permitir la autentificación por SQL Server y no solo por autentificación de windows. Para esto, solo tenemos que pulsar botón derecho sobre la conexión y acceder a las propiedades:

SQL Server Acceso1

Y dentro del apartado del apartado seguridad, activamos la autentificación «Modo de autentificación Windows y SQL Server»

SQL Server Acceso2

2) Cuando hagamos cambios, tenemos que reiniciar el servicio, para ello, accedemos a administración del servicio de SQL y reiniciamos el servicio

Reiniciar Servicio SQL

Y con estos pequeños pasos ya tenemos configurado SQL Server para poder desarrollar o lo que haga falta.

Agradecimientos: