edukia: biko2egunak

.astro/content-assets.mjs

@@ -1,4 +1,7 @@
 
 import __ASTRO_IMAGE_IMPORT_17cH5r from "../assets/dyndns-kaxeroa/dyndns-kaxeroa.svg?astroContentImageFlag=&importer=posts%2Fdyndns-kaxeroa.md";
-export default new Map([["../assets/dyndns-kaxeroa/dyndns-kaxeroa.svg?astroContentImageFlag=&importer=posts%2Fdyndns-kaxeroa.md", __ASTRO_IMAGE_IMPORT_17cH5r]]);
+import __ASTRO_IMAGE_IMPORT_Z20yt5C from "../assets/hay-algo-de-negocio-en-tu-codigo/arrival.jpg?astroContentImageFlag=&importer=posts%2Fun-enfoque-pragmatico-de-nuestros-tests-del-frontend.md";
+import __ASTRO_IMAGE_IMPORT_28bbst from "../assets/hay-algo-de-negocio-en-tu-codigo/arrival.jpg?astroContentImageFlag=&importer=posts%2Fhay-algo-de-negocio-en-tu-codigo.md";
+import __ASTRO_IMAGE_IMPORT_Z84Mlf from "../assets/enfoque-pragmatico-test/marrazkia.jpg?astroContentImageFlag=&importer=posts%2Fun-enfoque-pragmatico-de-nuestros-tests-del-frontend.md";
+export default new Map([["../assets/dyndns-kaxeroa/dyndns-kaxeroa.svg?astroContentImageFlag=&importer=posts%2Fdyndns-kaxeroa.md", __ASTRO_IMAGE_IMPORT_17cH5r], ["../assets/hay-algo-de-negocio-en-tu-codigo/arrival.jpg?astroContentImageFlag=&importer=posts%2Fun-enfoque-pragmatico-de-nuestros-tests-del-frontend.md", __ASTRO_IMAGE_IMPORT_Z20yt5C], ["../assets/hay-algo-de-negocio-en-tu-codigo/arrival.jpg?astroContentImageFlag=&importer=posts%2Fhay-algo-de-negocio-en-tu-codigo.md", __ASTRO_IMAGE_IMPORT_28bbst], ["../assets/enfoque-pragmatico-test/marrazkia.jpg?astroContentImageFlag=&importer=posts%2Fun-enfoque-pragmatico-de-nuestros-tests-del-frontend.md", __ASTRO_IMAGE_IMPORT_Z84Mlf]]);
 		

posts/hay-algo-de-negocio-en-tu-codigo.md

@@ -0,0 +1,39 @@
+---
+title: "Hay algo de negocio en tu código: (algunas) ideas para la entrega de valor"
+slug: hay-algo-de-negocio-en-tu-codigo
+description: >-
+  Biko2 enpresako blogean idatzitako artikulu bat.
+tags:
+  - biko2egunak
+added: "2019-11-19"
+---
+
+*_Oharra: Honako hau, Biko2 enpresan lan egiten nuenean haien blogean idatzitako artikulu bat da. [Iturria (funtzionatzen duen arte)](https://blog.biko2.com/actualidad-biko/hay-algo-de-negocio-en-tu-codigo-algunas-ideas-para-la-entrega-de-valor/)._*
+
+---
+
+![Shaun Tan ilustratzailearen "The Arrival" liburuan oinarritutako nik egindako marrazki bat. Eraikin handi batzuk ikusten dira eta, behean, familia bat (aita, ama eta alaba) kale erdian. Eraikinen artean, olagarroen tentakulo batzuk daude.](../assets/hay-algo-de-negocio-en-tu-codigo/arrival.jpg)
+
+Es sábado por la mañana y Miren, frontend developer, entra a clase en nuestro Curso de Desarrollo de Software. El plan del día no es el esperado en un curso que promete ser técnico: Rubén y yo dinamizaremos una sesión sobre definición de historias de usuario. Como es habitual en la Biko School, abrimos boca con una introducción teórica para, acto seguido, poner en práctica lo aprendido.
+
+Empezamos explicando que, para hacer bien nuestro trabajo, es fundamental un profundo conocimiento del negocio. En vez de limitarnos a ejecutar una solución, debemos participar en la definición de esta. Para ello, es necesaria una conversación entre las personas implicadas en el proyecto, desde perfiles de negocio hasta perfiles de desarrollo. Una conversación que se da en el dominio del problema, ahí donde solo se habla de las necesidades de la persona que utiliza nuestro software. Una vez entendidas estas necesidades es cuando pasamos al dominio de la solución, donde se definen y dibujan formularios, tablas y llamadas al API.
+
+Esta conversación sobre las necesidades debe estar exenta de ambigüedades. Tenemos que huir de sinónimos, jergas y motes. El «bueno, ya me has entendido» no nos vale. Si surge un concepto de negocio, consensuamos una definición para este. Si surge una nueva palabra para referirnos a ese concepto de negocio, la descartamos o sustituimos la que teníamos. Nunca utilizamos la misma palabra para dos conceptos, ni dos palabras para un mismo concepto. De esta manera propiciamos el lenguaje ubicuo, pilar en el desarrollo de software.
+
+¿Cuántas veces has visto parar un desarrollo por no tener claro qué ocurre en un escenario concreto? ¿Cuántas mañanas has perdido entre emails, llamadas y chats para aclarar una duda? ¿Te ha tocado ejercer de aguafiestas al tener que decir que un diseño es demasiado costoso (si no imposible) de implementar? ¿Has ejecutado una solución creyendo que podía haber sido mejor, sin tener posibilidad de cambiarla? Miren hace un gesto de complicidad. Lo ha vivido, ha estado ahí. Lo ha sufrido.
+
+Aquello que Miren ha sufrido tiene nombre: aprendizaje accidental. El aprendizaje accidental es aquel que ocurre sin esperarlo, cuando todo debería estar claro. Nos frena, nos hace ser ineficientes y genera frustración en el equipo. Contra el aprendizaje accidental tenemos el aprendizaje deliberado, aquel que ocurre cuando todas las personas implicadas en el proyecto se alinean para entender cuál es la necesidad que se quiere cubrir. Solo así podemos sacar partido al verdadero potencial del equipo. Solo así podremos centrarnos en la entrega de valor.
+
+El tiempo avanza, las transparencias se terminan y toca ponerse manos a la obra. Antes de eso, queda ver cómo llevar a la práctica estos principios de los que hemos hablado. Explicamos que, en uno de nuestros proyectos en Biko, nos está funcionando el enfoque [Specification by Example](https://en.wikipedia.org/wiki/Specification_by_example#:~:text=Specification%20by%20example%20(SBE)%20is,examples%20instead%20of%20abstract%20statements.) que llevamos a cabo en talleres de Example Mapping. Explicamos en qué consisten (nota del autor: daría para otro post).
+
+Arrancamos la práctica: Miren y su equipo harán un taller de Example Mapping para una aplicación en la que Rubén y yo asumimos el rol de negocio. No olvidemos los principios de los que hemos hablado: dominio del problema, evitar las ambigüedades y aprendizaje deliberado. Miren los tiene apuntados en su cuaderno, empiezan las conversaciones.
+
+Durante el ejercicio, ocurre algo que Rubén y yo no esperamos. En el taller, el equipo de Miren descubre que nuestro planteamiento permite a algunas personas generar gastos de miles de euros. La idea con la que veníamos no solo no es la mejor posible, sino que puede hundirnos. Menos mal que Miren ha sabido evitarlo, proponiendo una nueva regla que hará que esto no ocurra. Como negocio nos parece bien, muchas gracias y adelante, buen trabajo.
+
+Miren todavía no ha encendido su portátil. En ese momento entiende que, con un bolígrafo y un papel, ha aportado más valor del que hubiera aportado en mil líneas de código. Descubre que, su perfil de frontend developer, va mucho más allá de ejecutar una solución, de implementar un diseño. Su trabajo no es el código, el código es un resultado de su trabajo. Su responsabilidad es entender el negocio y hacerlo suyo.
+
+Nosotros también nos llevamos una lección. Han pillado a Rubén y Aitor, ¿cómo puede ser? Bueno, no pasa nada, siempre podemos darle una vuelta para futuras ediciones del curso. Aunque, pensándolo mejor, creo que está bien así.
+
+## Si quieres profundizar en el tema
+
+Puedes [buscarme en Twitter](https://twitter.com/aitorcurrutia) o [buscar a Rubén](https://twitter.com/rubenbpv), gran conocedor de este enfoque. También te recomiendo [el libro «The BDD Books - Discovery» escrito por Gáspár Nagy y Seb Rose](https://leanpub.com/bddbooks-discovery). Lectura interesante, llena de ejemplos prácticos y anécdotas vividas por los autores.

posts/sobre-developers-y-buenas-personas.md

@@ -0,0 +1,27 @@
+---
+title: Sobre developers y (buenas) personas
+slug: sobre-developers-y-buenas-personas
+description: >-
+  Biko2 enpresako blogean idatzitako artikulu bat.
+tags:
+  - biko2egunak
+added: "2020-2-18"
+---
+
+*_Oharra: Honako hau, Biko2 enpresan lan egiten nuenean haien blogean idatzitako artikulu bat da. [Iturria (funtzionatzen duen arte)](https://blog.biko2.com/actualidad-biko/sobre-developers-y-buenas-personas/)._*
+
+---
+
+Durante el proceso de selección de Biko, entre los nervios e incertidumbre que caracterizan una entrevista de trabajo, alguien me preguntó: «¿Cuál es el mayor reto al que te has enfrentado en tu carrera?» Buena pregunta, aunque me pilló por sorpresa. No recuerdo bien qué contesté, además de balbucear una lista de funcionalidades, tecnologías e infraestructuras con las que había trabajado hasta esa fecha.
+
+Pese a todo, pasé el proceso de selección. Entré en un proyecto interesante, ilusionado por las aventuras que me esperaban. Iba aterrizando, conociendo al equipo, familiarizándome con el negocio y la tecnología. Poco a poco cogía soltura y llegó el momento de asumir el que para mí prometía ser el mayor reto: buscar la manera de hacer testing en el proyecto.
+
+Algunas personas del equipo acordamos que dedicaría un tiempo a analizar cómo lo haríamos. Empecé a entender la teoría: preguntaba a gente, leía libros, buscaba vídeos… Me iba empapando. Compartía con el equipo, pero había gente que no me seguía, sentía que no mostraba interés. ¿Acaso no entendían la importancia del testing? Mi frustración crecía y empecé a bombardear al equipo con recursos sobre el tema. No importaba si los leían, tampoco preguntaba, había que «motivar a la gente». Creía que ayudaba cuando, en realidad, solo presionaba a personas que tenían otras inquietudes en ese momento.
+
+Llegó el momento de saltar del plano teórico al práctico. Entendí la tecnología y herramientas necesarias, buscando la configuración para aplicarlas a nuestro proyecto. Con ayuda, conseguimos montar la infraestructura adecuada. Ahí estaba, era una realidad, podíamos hacer tests en el proyecto. Pero había gente que no los hacía y seguía sin entender qué pasaba. ¿No veían el esfuerzo que había hecho? Lo tenían todo a favor y había gente que no metía un test. En mi afán por aplicar las buenas prácticas que leía en los libros (y buscando un reconocimiento) aumentaba la crispación dentro del equipo y me distanciaba de él.
+
+Algunas personas del equipo estaban motivadas y, poco a poco, iba subiendo el número de tests. Había gente que sentía que se quedaba atrás, pero con ver crecer ese número me bastaba. Cada nuevo test era un logro, me jactaba de tirar del carro y ser un líder. Yo seguía sin escuchar, empujando, mejorando el proyecto a toda costa, presionando al equipo. No entendía que mi tarea era estar al servicio de las necesidades del resto, respetando la diversidad dentro del equipo.
+
+Tengo suerte de formar parte de un gran equipo que, gracias a la atención a la mejora continua, supo pararme los pies. Una persona me dijo algo que me apunté: «En desarrollo de software el reto no es la tecnología, sino las personas». Cientos de tests más tarde lo veo claro: el código lo aguanta todo, basta con meterle horas, probar, fallar y volver a empezar. Las personas no, las personas merecen atención, respeto y cariño.
+
+Si hoy me peguntaran: «¿Cuál es el mayor reto al que te has enfrentado en tu trabajo?» No dudaría, aunque igual sorprendería con una respuesta nada técnica. No hablaría de proyectos, funcionalidades o infraestructuras. Hablaría de la vez que descubrí que esto va de personas y, para mejorar como developer, se empieza por mejorar como compañero. De nada valen las buenas prácticas si no hay empatía, entendimiento y respeto a la diversidad. Contaría ese momento en el que vi que, el equipo que trabaja bien, es el que trabaja feliz. Diría que mi mayor reto fue descubrir todo esto, aunque tenga toda la vida para resolverlo.

posts/un-enfoque-pragmatico-de-nuestros-tests-del-frontend.md

@@ -0,0 +1,44 @@
+---
+title: Un enfoque pragmático de nuestros test del frontend
+slug: un-enfoque-pragmatico-de-nuestros-tests-del-frontend
+description: >-
+  Biko2 enpresako blogean idatzitako artikulu bat.
+tags:
+  - biko2egunak
+added: "2020-6-10"
+---
+
+*_Oharra: Honako hau, Biko2 enpresan lan egiten nuenean haien blogean idatzitako artikulu bat da. [Iturria (funtzionatzen duen arte)](https://blog.biko2.com/actualidad-biko/un-enfoque-pragmatico-de-nuestros-tests-del-frontend/)._*
+
+---
+
+![Nik egindako marrazki bat. Eraikin bat atzean ikusten dela, bambuzko andamio batzuen detallea dago.](../assets/enfoque-pragmatico-test/marrazkia.jpg)
+
+Resulta difícil decir nada que no se haya dicho ya en torno a los beneficios del testing. En Biko, tenemos un compromiso con las buenas prácticas y tenemos clara la responsabilidad de testar nuestras aplicaciones. En este post no vengo a decirte [por qué debes hacer test](https://www.youtube.com/watch?v=vlorWIlPgY0&t), vengo a hablar del enfoque que estamos dando a nuestros test en los desarrollos frontend.
+
+Como software crafters, nuestro oficio es solucionar problemas. No nos limitamos a ejecutar soluciones, entendemos y hacemos nuestro el dominio del problema de negocio que se quiere afrontar. Participamos de forma proactiva en el análisis y diseño de funcionalidades, siempre con un compromiso claro por la entrega de valor.
+
+Como software crafters, en nuestro afán por crear código mantenible, tenemos la responsabilidad de volcar en nuestra base de código todo ese conocimiento que hemos adquirido. No nos limitamos a implementar interfaces, ni nos limitamos a implementar llamadas a un API. Buscamos expresar la intención y motivación que subyace a aquellas soluciones de interfaz que estamos implementando. Aquí es donde iniciamos ese proceso creativo en el que, utilizando el código como materia, vamos moldeando todo aquel conocimiento que tenemos sobre el negocio.
+
+El testing no está exento de este principio: debe estar basado en nuestro conocimiento del negocio. Cuando hacemos un test del frontend, debemos ser capaces de simular la interacción de la persona al otro lado de la aplicación, expresando su intención y motivación. Debemos hablar el lenguaje de nuestro negocio. No nos limitamos a comprobar que ese input recibe ocho dígitos y una letra, comprobamos que una usuaria introduce su DNI para emitir facturas. No comprobamos que recibimos un dato del API, comprobamos que un usuario consulta los siniestros de su póliza.
+
+Para alcanzar este objetivo, es fundamental que nuestros test cubran la interacción con la interfaz de usuario. De nada sirve hacer test unitarios de las capas de nuestra aplicación si no somos capaces de hacer click en el mismo botón que verá la persona que la utilice. A esta persona no le importan nuestros repositorios, servicios de dominio o servicios de aplicación. Esta persona lo único que verá serán botones, campos de formularios o tablas. Si no somos capaces de cubrir esto, estaremos perdiendo una parte importante del potencial de nuestros test.
+
+## Entendido, pero... ¿Cómo lo conseguimos?
+
+En Biko desarrollamos nuestros proyectos frontend (principalmente) en TypeScript y React, utilizando Jest como framework de test. Este framework nos facilita testar todo nuestro core, pero está limitado a la hora de hacer test de nuestras vistas (algo que, como se ha dicho antes, resulta fundamental en un proyecto front). Aquí es donde entra en juego la herramienta React Testing Library.
+
+React Testing Library es una librería de utilidades que extiende de DOM Testing Library y nos permite renderizar una interfaz de usuario para interactuar con el DOM. Se basa en un principio: «cuanto más se parezcan tus test a cómo se usa tu software, más confianza te darán». Cuando lo lees parece obvio, pero es un salto cualitativo en el enfoque que damos a los test de nuestra interfaz. No testamos detalles de implementación de nuestros componentes, sino que actuamos directamente sobre el DOM, del mismo modo que lo hará quien use nuestro software.
+
+Utilizando esta librería junto a Jest, tenemos la capacidad de hacer test de nuestras vistas de forma agnóstica a la implementación. Mockeando los colaboradores como en cualquier pieza de nuestra aplicación, buscamos elementos del DOM (por texto o label, igual que lo haría cualquiera que navegue la web) e interactuamos con ellos comprobando que la respuesta obtenida es la adecuada. Esto nos permite cubrir con test las reglas de negocio en la capa de entrega e incluso, por qué no, desarrollar interfaces de usuario mediante TDD.
+
+## En conclusión
+
+React Testing Library aumenta de forma considerable la fiabilidad de nuestros test del frontend. Nos permite abstraernos de los detalles de implementación y tener unos test lo más parecido posibles a la manera en la que se utilizará nuestro software. Gracias a este principio, obtenemos una batería de test más robusta y que expresa más intención. Esto último nos lleva a un código más mantenible y, como software crafters, pocas cosas nos hacen más felices que una base de código mantenible.
+
+## Si quieres saber más
+
+Si quieres seguir investigando, añado un vídeo y un artículo que pueden resultarte interesantes. Además, si tienes inquietudes sobre testing, buenas prácticas y entrega de valor, siempre puedes buscarnos en redes sociales (a Biko o a mí mismo), nos encantará conocerte.
+
+- Un vídeo: [The Pragmatic Frontend Tester](https://www.youtube.com/watch?v=XjFeUUZm50g) ([Adriá Fontcuberta](https://twitter.com/afontq))
+- Un artículo: [No pierdas el tiempo escribiendo tests](https://blog.koalite.com/2017/11/no-pierdas-el-tiempo-escribiendo-tests/) ([Juan María Hernández](https://twitter.com/gulnor))