Poco a poco con Go y TDD: package, funciones, bucles, arrays y cobertura de test

Todo funcionando, $GOPATH, HelloWorld,… ahora vamos a hincar el diente de verdad a Go con TDD.
Crearemos una pequeña calculadora con la que aprenderemos a hacer un package, funciones, tocaremos un poco los arrays y además nos servirá para mejorar nuestras skills de TDD.

Empezando por los test

Para empezar con la calculadora, vamos a crear un package llamado calculator, así que creamos un directorio con ese mismo nombre (calculator) y nuestro primer fichero será calculator_test.go (TDD a tope).

*nota: solo puede existir un package por directorio

El código de ese primer test será algo así:

package calculator

import "testing"

func TestAdder(t *testing.T) {
    sum := Add(2, 2)
    expected := 4

    if sum != expected {
        t.Errorf("expected '%d' but got '%d'", expected, sum)
    }
}

Si nos hemos fijado un poco en el mensaje de error, vemos que ahora utilizamos %d en lugar de %s porque lo que queremos es imprimir por consola un número.

Si ejecutamos go test nos aparecerá que no esta definida la función Add

$ go test
# github.com/jeslopcru/golang-examples/02-calculator
./calculator_test.go:8:9: undefined: Add

Compilation finished with exit code 2
7997258366_7e77afa99d_z
Atardecer – Paula Gonzalez Perez

Sigue leyendo “Poco a poco con Go y TDD: package, funciones, bucles, arrays y cobertura de test”

Aprendiendo Go con TDD

Hace tiempo que quiero hincar el diente a Go, el lenguaje de Google. Empecé jugando un poco con exercism.io y creo que es hora de empezar Go con test. Vamos a intentar explicar como testear un ejemplo sencillo con Go, para más adelante evolucionar ese ejemplo con usando un enfoque de TDD. La idea es conocer como funciona el lenguaje: declarar variables, crear funciones, hacer test, usar constantes…

5803193649_18e29b5b0e_z
Micah Camara – Go

Sigue leyendo “Aprendiendo Go con TDD”

Cómo saber qué preguntas hacer en una entrevista

Pasar por un proceso de selección es algo complicado, inviertes tiempo, esfuerzo en hacer las entrevistas, las pruebas técnicas… ya hemos hablado antes de Preguntas sobre… en una entrevista a un “desarrollador” y Como preparar una entrevista de trabajo. Esta vez es diferente, estoy al otro lado y créeme cuando te digo que saber que preguntas hacer es más complicado de lo que parece.

Exif_JPEG_PICTURE

Sigue leyendo “Cómo saber qué preguntas hacer en una entrevista”

¿Cuánto vas a tardar? Técnicas para estimar

 

Estimar, ¿cuanto cuesta hacer esto?¿como lo estimamos? No tengo ni idea de como cuanto voy a tardar y predecir el futuro nunca ha sido lo mío.

Las técnicas de estimación “ágiles” son colaborativas, todas las personas involucradas en el proceso deberían colaborar. Del mismo modo, estas técnicas están pensadas para ser rápidas y que puedan repetirse en cada sprint. Y una de las cosas más complicadas es que deberíamos estimas en unidades relativas.  Esto significa que no intentamos estimar euros o en horas directamente. Así aprovechamos la capacidad humana para comparar cosas entre sí y evitamos la dificultad para comparar algo con un concepto abstracto (como euros u horas).

4806295665_8ee75ebb38_z

Planning poker

Cada miembro del equipo tiene una serie de tarjetas con los números de fibonacci (incluso hay apps https://play.google.com/store/apps/details?id=artarmin.android.scrum.poker&hl=es_419). Cada numero significa un peso/esfuerzo/complejidad. Lo que hacemos es exponer una de las historias de usuario para poder “estimarla”.
Sacamos cada uno una carta y esto nos sirve para dialogar y refinar esa historia. Es decir, si un miembro saca un 1 y otro miembro saca un 8 ,hay que analizar porqué esa diferencia y detallar más la historia de usuario, o incluso partirla.

Estimación por afinidad

La idea es construir un tablero con puntos de esfuerzo/peso/valor como columnas, e ir colocando las tareas en cada columna. Esta técnica se basa en que podemos estimar historias en base a sus semejanzas/diferencias con otras.

En realidad ni siquiera es necesario poner la puntuación en las columnas. Sino solo poner las tareas más pequeñas a la izquierda y las más grandes a la derecha. En base a esta ordenación podemos analizar si es necesario “cortar” las tareas más grandes.

Estimación por talla de camisetas

Para evitar la confusión de los puntos, o peor aún estimar en horas una técnica es estimar basándonos en tallas de camisetas. En este caso cada miembro del equipo ha de indicar si cree que la tarea a estimar es: XS (Extra Small), S (Small), M (Medium), L (Large), XL (extra-large) o XXL (Double Extra-Large).

Program Evaluation and Review Technique (PERT)

La idea es que todos los miembros del equipo estimen de manera numérica, por ejemplo usando “planning poker”. Usando esos puntos proporcionados por el equipo se aplica esta formula  (O+P+4M)/6  donde O es la más optimista, P es la estimación más pesimista y M es la media.

Magic Estimation

Creamos una tabla donde las columnas son los puntos de plannig poker. El equipo seleccionará una tarea que se usará como como referencias, lo que se hace con esta tarea es estimarla por lo que es crucial que todos conozcan dicha tarea así como sus implicaciones.

La mecánica es que por turnos en silencio, cada miembro del equipo tome una tarea y la coloque en una columna, si la tarea se va moviendo por distintas columnas se anotan los cambios. Al cabo de un tiempo las tareas con más movimientos son las que habrá que refinar.

Os dejo una pequeña app https://github.com/janpetzold/magic-estimation para implementar esta técnica.

Big/Uncertain/Small

Para hacer planificaciones rápidas, la idea es hacer 3 “montones de historias”: grandes, pequeñas y las que no tengo ni idea de como son. Esto puede servir en un primer momento tener una idea rápida del product backlog.

Dot Voting

No es una técnica de estimación en sí, pero puede servir. Cada miembro del equipo tiene un limite de puntos 10 y lo reparte entre las distintas tareas a estimar.

No estimar

El desarrollo software es, por su propia naturaleza, impredecible y no repetitivo. La idea es construir pequeñas piezas de software de manera iterativa e incremental que nos lleven lo más pronto posible a entregar valor sin dedicar horas a predecir el futuro.

Algunas consideraciones

Si estimamos en puntos de historia, ¿qué significa un 5? ¿y que un 13? Una manera por ejemplo es tener una historia común, conocida por todos los miembros del equipo y en base a esa tarea estimar. Por ejemplo, ¿cuánto pesa un pato?, No tengo ni idea, pero por ejemplo sé cuanto pesa un conejo, y podría “estimar” que un pato pesa los mismo que un conejo, en cambio si me preguntan cuanto pesa un cerdo… podría estimar que es 85 veces más pesado que un conejo.

Requisitos, tareas, historias, prioridades, objetivos,… distintas técnicas para priorizar un product backlog

Requisitos, tareas, historias, prioridades objetivos,… una de las cosas más difíciles a la hora de desarrollar un producto software no es la arquitectura, ni los test, ni siquiera el lenguaje de programación, los más complicado es saber que hacer en el momento adecuado. Qué tenemos que construir, por qué vamos a hacerlo, como lo haremos y que es lo que va primero.

Sí, estoy hablando de priorizar, de objetivos. Así que aquí voy a intentar descubrir algunas técnicas para priorizar un product backlog o al menos intentarlo. No vamos a entrar en detalle de como hacerlo, hay miles de recursos que seguro lo explican mucho mejor que yo, solo quiero tener una pequeña lista de técnicas y un par de pinceladas de cómo funcionan.

6350781099_18e39fc20e_z

Sigue leyendo “Requisitos, tareas, historias, prioridades, objetivos,… distintas técnicas para priorizar un product backlog”

Makefiles como dejar de memorizar comandos en docker – Developer Vago

Si has trabajado con docker, o si lo has probado, seguro que te has dado cuenta de la cantidad de comandos que tiene y la cantidad de opciones posibles. Para simplificarme un poco la vida he estado buscando información y lo que más util me resulta es crear un pequeño Makefile con los comandos que más utilizo.

making waves
Elizabeth Donoghue – making waves

Así que hoy voy a contar algunos trucos y consejos sobre Makefiles y para que veáis la cantidad de comandos que hay aquí os dejo la lista:

Sigue leyendo “Makefiles como dejar de memorizar comandos en docker – Developer Vago”

Aprendiendo VueJS sin hacer un TODO-List

El frontend cambia muchísimo, cada día salen frameworks nuevos, herramientas,… y por ello estar al día de todo es imposible. Pero eso no deja de lado que me apetezca mejorar mis habilidades de frontend y aprender un un poco como se trabaja con javascript más hallá de JQuery y de hacer Stackoverflow Driven Development.

37036473724_28163a121c_z
Matías Garrido – Flickr

Así que me he propuesto ir aprendiendo VueJS, porque creo que tiene una curva de aprendizaje bastante asequible y voy a ver resultados pronto sin demasiada frustración. Además hace tiempo que me encontré con este magnifico libro “Desarrolla aplicaciones con VueJS“, con el curso de CodelyTV sobre hacer TDD con VueJS y Jest y tuve la suerte de cruzarme con Dani Latorre de coding stones en la conferencia “Madrid Software Crafters” y charlar sobre VueJS, frontend actual y las charla que dieron en Codemotion.

Sigue leyendo “Aprendiendo VueJS sin hacer un TODO-List”

Code reviews: comunicación, comentarios y asertividad

Revisar el código de otros compañeros antes de una pull request o antes de pushear es una práctica bastante extendida. Pero ¿cómo hacerlo de manera efectiva? Hace tiempo escribí un post sobre “Cómo llevar a cabo una code review y qué puntos tener en cuenta “ pero después de la “Software Crafter Madrid” me puse a buscar información sobre como mejorar la comunicacióne como intentar disminuir la fricción en las code reviews.

La idea de este post no es escribir en piedra una serie de normas, sino comentar una serie de trucos que a mi han funcionado y por eso me gustaría que tú te animaras a contarme los tuyos. Abajo dejo una serie de referencias

4026722749_18a80f2690_z
Jaguar E-Type 4-2 – Chris Devers

Sigue leyendo “Code reviews: comunicación, comentarios y asertividad”

Algunos trucos para escribir código

Muchas veces se nos llena la boca hablando de los principios SOLID y de que tenemos que escribir mejor código, pero ¿qué significa eso de escribir mejor código? En realidad yo no lo sé, pero en este post voy a contar como intento acercarme a los principios SOLID y al Clean Code en mi día a día como desarrollador PHP.

 

crowd music musician street performer
Photo by Negative Space on Pexels.com

A rasgos generales intento usar Object Calisthenic unido a trabajar la legibilidad del código y que este se lea como prosa. Y algo muy importante, estas indicaciones no debes seguirlas estrictamente, son solo una serie de normas que sigo a veces (repito a veces). Son unas pequeñas pautas, nada más así que si las aplicas no seas demasiado rígido.

Utiliza variables que puedas pronunciar

La idea es que puedas pronunciar el nombre de las variables, funciones y clases. No importa que el nombre quede un poco largo, es mejor saber de qué trata una variable con solo leerla, que tener que intuir el acrónimo.

Mal

$ymdstr = (new \DateTime())->format('y-m-d');

Bien

$currentDate = (new \DateTime())->format('y-m-d');

 

Utiliza constantes para minimizar los números mágicos

La idea es que todo se lea como prosa, así que encontrarse con un 5 o un 23 no mola.

$result = $serializer->serialize($data, 448);

¿Qué significa el 448? Creo que queda mejor algo así:

$json = $serializer->serialize($data, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE);

Esto mismo puede aplicarse dentro de una clase a por ejemplo los estados de un usuario.

class User
{
   const ACCESS_READ = 1;
   const ACCESS_UPDATE = 4;
   const ACCESS_DELETE = 8;
}

if ($user->access && User::ACCESS_UPDATE) {

   // do edit ...
}

Utiliza variables explicativas

¿Qué hace este trozo de código?

$str = 'One Infinite Loop, Cupertino 95014';

preg_match('/^[^,]+,\s*(.+?)\s*(\d{5})$/', $str, $matches);

save($matches[1], $matches[2]);

Seguramente en 1 minuto seas capaz de decirmelo, pero imagina que estas debugeando porque quieres resolver un bug y te encuentras con esto. Tardarás un minuto en saber que hace y lo peor de todo es que quizás pierdas el foco de lo que estabas haciendo.

Por ello creo que lo mejor es utilizar variables que expliquen que es lo que estás haciendo, algo así:

$address = 'One Infinite Loop, Cupertino 95014';
$cityZipCodeRegex = '/^[^,]+,\s*(?<city>.+?)\s*(?<zipCode>\d{5})$/';
preg_match($cityZipCodeRegex, $address, $matches);

saveCityZipCode($matches['city'], $matches['zipCode']);

¿Se entiende algo mejor?

Encapsula condicionales

Cuando estamos leyendo código, llevamos encima una mochila de carga cognitiva sobre que es lo que hace el código, el contexto de la aplicación, las variables… por eso lo que siempre intento es minimizar esa carga y hacer que con solo leer una variable o una condición sepa que es lo que hace. Por ejemplo, normalmente evito hacer cosas como esta:

if ($article->state === 'published') {
   // ...
}

Lo que hago es intentar dar contexto y sobre todo en los if crear funciones booleanas que para que sea mucho más fácil responder a la pregunta del if que evaluar la condición. Me explico:

if ($article->isPublished()) {
   // ...
}

La función isPublished siempre devolverá un booleano, así es más facil seguir la traza del código.

Evita los else y apuesta por los “early returns”

La idea es que no haya demasiados else y que los casos base se resuelvan los más pronto posible.

Vamos a poner el ejemplo del cálculo de fibonacci:

function fibonacci(int $n)
{
   if ($n < 50) {
       if ($n !== 0) {
           if ($n !== 1) {
               return fibonacci($n - 1) + fibonacci($n - 2);
           } else {
               return 1;
           }
       } else {
           return 0;
       }
   } else {
       return 'Not supported';
   }
}

Pero ¿y si intentamos primero los casos base/excepciones y luego el flujo normal):

function fibonacci(int $n): int
{
   if ($n === 0 || $n === 1) {
       return $n;
   }

   if ($n > 50) {
       throw new \Exception('Not supported');
   }

   return fibonacci($n - 1) + fibonacci($n - 2);

}

Demasiado contexto

Esto es algo que me pasa siempre, intento dar buenos nombre y al final lo que acaba pasando es que me paso de frenada y las variables tienen demasiado contexto. Algo así tampoco es bueno.

class Car
{
   public $carMake;
   public $carModel;
   public $carColor;
 
  //...
}

Hay que mantener el equilibrio entre el gym y el ñam

Evita los nombres genéricos

En la búsqueda del equilibrio, también tenemos que tener en cuenta lo malos amigos que son los nombres genéricos. Nombres como Manager, Pool, Handle… funcionan en cualquier contexto, da igual que sea un ERP que una central nuclear en los dos habrá un Manager o un Handler. Así que lo mejor es que tengas cuidado con su uso. Estamos en lo de siempre el equilibrio entre el gym y el ñam.

class Email
{
   public function handle(): void
   {
       mail($this->to, $this->subject, $this->body);
   }
}

$message = new Email(...);

$message->handle();

¿Qué hace handle en este contexto?, queda un poco rato. Lo ideal sería cambiarlo por send, así le damos contexto a la clase Email. Ese contexto surge porque la clase Email realiza acciones “send”.

No utilizar flags

Las funciones no cuestan dinero, así que no te agobies cuando tengas que crear una nueva. Es cierto que reutilizar está bien, seguir el principio de única responsabilidad y todo eso. Pero no debemos perder la cabeza con estas cosas, así que una de las alertas para saber que has perdido un poco el foco es ver funciones con flags como esta:

function createFile(string $name, bool $temp = false): void
{
   if ($temp) {
       touch('./temp/'.$name);
   } else {
       touch($name);
   }
}

Creo que se podrían crear 2 funciones:

function createFile(string $name): void
{
   touch($name);
}

function createTempFile(string $name): void
{
   touch('./temp/'.$name);
}

Proximidad

Declaro las variables tan cerca de su uso como sea posible. Algo así queda un poco raro, sobre todo a la hora de refactorizar y mover cosas de sitio se hace complicado con una estructura como esta:

function hi() 
{
    $a = $this->getA(),
    $b = $this->getB(),
    $c = $this->getC(),
    $d = $this->getD();

    $this->doSomething($b);
    $this->doAnotherThing($a);
    $this->doOtherStuff($c);
    $this->finishUp($d);
}

Mi idea es intentar escribir algo así:

function hi() {
  $b = $this->getB();
  $this->doSomething($b);

  $a = $this->getA();
  $this->doAnotherThing($a);

  $c = $this->getC();
  $this->doOtherStuff($c);

  $d = $this->getD();
  $this->finishUp($d);
}

Ahora queda mucho más claro por lo que lo ideal es usar una variable justo después de su declaración.

Normalmente no es tan simple como este ejemplo, ya que hay dependencias y tal, pero la idea general es esta.

Resumen

Si tuviese resumir que es lo que intento o hacia donde empujo mis soluciones cuando estoy escribiendo código es hacia:

  • Usar poca indentacion: eso hace que el código sea más entendible,
  • Evito utilizar else para conseguir un flujo lineal del programa.
  • Early return siempre que puedo: hacer todas las comprobaciones al principio para intentar ejecutar más código del necesario.
  • Que el código se lea bien: variables con buenos nombres, sin abreviaturas excesivas y con el contexto adecuado.
  • Explaining variables: En las guardas de los if intento que siempre haya una función o variable que empiece por “is” así sé si es true o false.
  • Paciencia: poner un buen nombre no se consigue fácilmente, muchas veces hay que cambiarlo más de 1 o 2 veces.
  • Equilibrio: nos pagan por solucionar problemas y por hacer buen código. Así que no hay que agobiarse, quizás en una primera pasada tomemos algún que otro atajo. No es malo, solo hay que llegar a ese punto en el que escribimos buen código sin perder la cabeza por el código bien escrito.

Este artículo se basa en este repositorio donde encontrarás muchos más ejemplos.

consejos y trucos de composer PHP

¿Conoces composer? Seguro que ya lo utilizas desde hace tiempo en tus proyectos de PHP. Composer es un manejador de dependencias y paquetes en PHP, si quieres empezar, hace ya bastante tiempo que hablé de como sacarle partido a composer y de cómo hacer una libreria utilizando composer. Hoy voy a dar una lista de consejos y trucos.

Partimos de que ya utilizas composer, sabes sus comandos básicos y quieres subir al siguiente nivel. Quieres saber qué más puedes hacer, quieres conocer la diferencia entre ~ y ^, quieres saber qué hacer con el composer.lock,…

Lo primero, lee la documentación. Es el mejor consejo que puedo darte, en la documentación de composer está todo y seguro que hay otras muchas funcionalidades que pueden serte útiles en tu proyecto.Sigue leyendo “consejos y trucos de composer PHP”