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”

Retrospectiva y Objetivos 2018

Es hora de reflexionar sobre todo este año y si tuviese que escribir una frase sería “cambios, vida y felicidad”. Porque empecé el año siendo padre de la pequeña Aitana, me certifiqué como “Profesional Scrum Master”, di un par de charlas en Meetups, fui a la TarugoConf y a Codemotion. Justo antes de asistir a la TarugoConf mi familia y yo Madrid y yo me despedía del gran equipo de coches.com. Volvimos a Sevilla, y junto al gran equipo de QAShops sigo aprendiendo, mejorando y disfrutando de cada día. Aún así incluso este año me dio tiempo a visitar Budapest, a perderme por Sevilla una vez más y sobre todo a disfrutar cada momento junto a mi familia.

16255888356_f278413370_z

Sigue leyendo “Retrospectiva y Objetivos 2018”

De vuelta al mundo real

Llevo varias semanas sin actualizar el blog y no por falta de ganas, sino porque he estado disfrutando de experiencias increíbles que me gustaría contaros hoy.

Desde que llegué a Sevilla ha sido un no parar de hacer cosas, en estas ultimas 2 semanas facilité una kata en PHPSevilla, estuve echando una mano de mentor en el Sevilla Startup Weekend y para terminar la semana cogí un AVE a Madrid para ir a la Codemotion.

32007811964_d46496180e_z.jpg

Pero es que antes de eso estuve en la TarugoConf (espectacular), es un eventazo que te llena de energía y te da pie para hablar con la flor y nata del mundo startupil. Entre tanto me dio tiempo a establecerme en Sevilla, encontrar piso, mudarme y todo ese rollo. Y lo más importante: sigo teniendo una hija que crece cada día más rápido y con la que disfruto.

TarugoConf

Ya lo he dicho antes, es un eventazo donde pude conocer a un montón de gente que sigo en twitter, la verdad es que me encantó en todos los sentidos. Candela, David Bonilla & Co. hacen un trabajo espectacular. Aquí os dejo el post del postmortem http://www.bonillaware.com/postmortem-tarugo17

Kata en PHPSevilla

Cuando estuve en Junio con los chicos de PHPSevilla hablando sobre refactoring, me sentí como en casa. Así que a mi vuelta a Sevilla me propusieron hacer una pequeña kata para haciendo pair programing, aprender TDD.

El meetup comenzó con una pequeña introducción a el ciclo de TDD: Red – Green – Refactoring. Haciendo hincapié en que es muy complicado cambiar la mentalidad de escribir primero los tests y por ello hay que ir pasito a pasito (baby steps). En la charla comenté que bajo mi punto de vista, la mejor manera de empezar con TDD es que tenemos que ser, sobre todo al principio, muy estrictos siguiendo las reglas:

  • Hacer un test
  • Comprobar que falla
  • Hacer el código mínimo para que funcione
  • Refactorizar si es necesario
  • Volver al principio

Después de la pequeña charla el reto consistió en ponernos por parejas y resolver un pequeño problema, en este caso FizzBuzz. Estuve echando una mano a los compañeros que andaban por allí, intentando resolver dudas y haciendo que todos pasaramos un buen rato La verdad que a mi como facilitador me gustó mucho la experiencia, espero que los asistentes también. Con el pequeño ejercicio de FizzBuzz, pudimos demostrar de primera mano que seguir las reglas de arriba no es tan sencillo como parece.

Desde aquí dar las gracias a los organizadores de PHPSevilla por fomentar eventos tan molones, a los sponsors por cedernos el local y sobre todo a todas las personas que participaron.

Sevilla Startup Weekend

Se trata de un evento emprendedor que se celebró desde el viernes 17 de Noviembre hasta el domingo, en el que los participantes trabajan durante más de 54 horas para convertir sus ideas de negocio en una ‘startup’.

A decir verdad, cuando me propusieron ser mentor me pilló un poco de sorpresa. Además no conocía a nadie de SevillaUP (las maravillosas personas detrás del evento), pero eso no me quitó las ganas de echar una mano en lo que pudiese durante el fin de semana.

El evento tuvo lugar en el “Club Antares” un sitio muy chulo donde había muchísima gente con ganas de pasar un finde aprendiendo y disfrutando. Como comenté al principio no conocía a nadie, pero el buen rollo entre mentores, organización y participantes hizo que nos hiciésemos piña y que todo saliese genial.

Me sorprendió mucho la cantidad de personas de todas las edades, había chavalada de 16-20 años hasta gente con mucha experiencia que tenía el gusanillo de pasar el finde validando ideas de negocio. Es impresionante lo mucho que me aportó el evento, la cantidad de cosas que aprendí y la gente tan interesante con la que charle. Impresionante tambien el cariño que le ponen las chicas y chicos de SevillaUp a todo lo que hacen es tremendo. Las ganas que le ponen los participantes para estar todo el finde trabajando. Y qué decir del resto de mentores, es genial que gente tan grande saque un hueco para venir el finde y poder aprender mucho de ellos. Me he sentido super pequeñito al lado de personas tan grandes y con tanto que aportar.

Codemotion

Coger el primer AVE de la mañana no es nada fácil, hay que luchar contra las ganas de quedarse calentito en la cama. Pero la ocasión lo merece: Codemotion. Para el que no lo conozca, es un evento con más de 140 charlas y talleres donde van (o vamos) más de 2000 asistentes con ganas de aprender y sobre Machine Learning, Deep Learning, Microservicios, Cloud Computing, Contenedores, Desarrollo software,…

Me encantó el evento, no solo porque las charlas a las que fuí estuvieron geniales, sino porque pude reencontrarme con antiguos compañeros, antiguos jefes, colegas de profesión y encima me dió tiempo a desvirtualizar a unas cuantas personas solo conocía por Twitter o por los cursos online de Refactoring. Una pena no haber podido desvirtualizar a más gente.

Las charlas que más me gustaron:

  • How to create a healthy and productive environment. Felix contó unos cuantos tips sobre como tener una cultura de equipo sana, competitiva y que haga crecer al equipo.

  • ¿Tienes un #bug? Tus tests unitarios no están bien planteadosAunque el ponente dijo que que era para beginners fue una charla muy bien contada y con las ideas muy claras de como afrontar el testing, mocking.

  • Las reglas que hay que romper para que tu equipo de desarrollo sea el más rápido, de Javier Abadía. Me pareció una charla muy divertida, muy bien contada y con muchos buenos consejos. Donde el mensaje estaba en que lo importante es dar soluciones que aporten valor al negocio y a los usuarios no en disputas de primer mundo (espacios vs. tabuladores, codigo acoplado, command buses/event sourcing,…)

  • El informático de David Bonilla. Fue un cierre de Codemotion brutal en mi opinión. La charla (aunque con un ritmo un lento) dejó un monton de preguntas en el aire y sirvió para irnos a casa con la conciencia removida. La verdad es que quiero volver a escuchar esta charla. Menos mal que el equipo de Autentia estuvo a tope grabando las charlas.

Conclusiones

Me gustaría escribir más, pero hasta ahora mi manera de escribir era abrir un monton de pestañas en Chrome, ponerme a picar código e ir escribiendo en sublime lo que iba haciendo. Creo que para seguir escribiendo de manera regular tengo que darle una al proceso, sobre todo porque ahora con la pequeña no tengo tanto tiempo de seguido.

Así que he empezado a utilizar google keep para apuntar las ideas, posts, referencias. Una vez a la semana (más o menos) les pongo un poco de orden y las categorizo en Trello. Cuando creo que tengo material suficiente creo un doc en Google Drive y empiezo a darle forma. Espero que con esta forma me de tiempo porque material tengo un bastante.

Screen Shot 2017-12-12 at 19.00.45.png

Por eso nos vemos en el próximo post. ¡Espero que sea pronto!

Por cierto, ahora que veis las temáticas, ¿os atraen? ¿os gustaría que profundizase sobre algo que no he tocado? ¿alguna idea?