
# JSDay Canarias 2023

<MdxImage src="/assets/blog/canarias-js-2023/head.png" alt="photo" />

# Index

1. [Welcome to JSDay Canarias 2023](#welcome)
2. [Making Felix Felicis](#kent)
3. [Storybook, the best friend we all need](#anna)
4. [Rerenders vs surgical updates, what's the fuss about?](#braulio)
5. [Testing and simple design with TypeScript](#carlos)

## Welcome to JSDay Canarias 2023<a name="welcome"></a>

This year there was an impressive level among both speakers and visitors. I networked with people from different positions than mine, but what I loved most about this edition is being able to meet up with old friends again and celebrate with them this incredible event we have in Tenerife.

<MdxImage src="/assets/blog/canarias-js-2023/friends.jpeg" alt="photo" />

Not forgetting that this year we could also enjoy the presence of Kent C. Dodds. For those who don't know who Kent C. Dodds is, he is a well-known software engineer, educator, and speaker in the JavaScript and React communities. He is known for his contributions to open source projects and his efforts to teach and empower developers through his online courses, workshops, and conference talks. has created popular open source projects like React Testing Library and Downshift and has made significant contributions to various other projects in the JavaScript ecosystem. He is a strong advocate for testing, accessibility, and best practices in software development.

<MdxImage src="/assets/blog/canarias-js-2023/big-boss.jpeg" alt="photo" />

Being able to engage in a conversation with him has been a dream come true, as his knowledge and hands-on approach has allowed me to delve deeper into key React concepts and discover the importance of testing in developing robust and reliable applications. Thanks to his guidance and valuable resources, I have gained a solid foundation and am excited to continue learning and applying his teachings. Kent C. Dodds is a true reference in the development community and his passion for sharing knowledge has left a lasting impression on me.

### Making Felix Felicis<a name="kent"></a>

In this talk, Kent C. Dodds shared the ingredients he has used to create his own luck, and hopes he can help us create our own.

<MdxImage src="/assets/blog/canarias-js-2023/making-felix-felicis/kent.jpeg" alt="photo" />

### Storybook, the best friend we all need<a name="kent"></a>

As frontend developers, we always have problems to manage, reuse and maintain UI components. Anna's proposal for this talk was to show Frontenders the magic and potential of the Storybook library. Anna presented the different approaches we can take when using storybook, as well as the many benefits it can have for our daily work.

<MdxImage
	src="/assets/blog/canarias-js-2023/storybook-the-best-friend-we-all-need/anna-sala.jpeg"
	alt="photo"
/>

### Rerenders vs surgical updates, what's the fuss about?<a name="braulio"></a>

Why are we so obsessed with re-rendering? What are the benefits of surgical updates? In this talk Braulio Diez and Daniel Sanchez compared both approaches and why surgical updates seem to be the future of web development.

<MdxImage
	src="/assets/blog/canarias-js-2023/rerenders-vs-surical-updates/braulio-diez-and-daniel-sanchez.jpeg"
	alt="photo"
/>

### Testing and simple design with TypeScript<a name="carlos"></a>

In this talk Carlos Blé told us about some principles and concrete techniques to prevent the code from degenerating and slowing down the implementation of functionalities.

<MdxImage
	src="/assets/blog/canarias-js-2023/testing-y-diseno-simple-con-typescript/carlos-ble.jpeg"
	alt="photo"
/>

But beyond the talks, I want to thank the organization for creating a warm and welcoming environment. The opportunity to interact with other attendees, share ideas and make meaningful connections was invaluable. The passion and dedication of everyone involved in the organization was evident in every interaction.

JSDay Canarias was not only an educational event, but also a catalyst for personal and professional growth. I felt inspired and motivated by the community of developers gathered there, and I am sure that the connections and knowledge gained will accompany me in my career.

In conclusion, I would like to express my deep gratitude to the JSDay Canarias organization for providing us with a truly memorable event. For making this exceptional event possible, your dedication, effort and passion were reflected in every aspect of the event, and I am excited to see what future editions have in store. JSDay Canarias has left a lasting impression on me, and I am grateful to have had the opportunity to be a part of this unforgettable experience.


JSDay Canarias 2023


# First time in Ract Alicante

In this post I want to talk about my experience at React Alicante, which I attended for the first time.

<MdxImage src="/assets/blog/react-alicante-2022/react-alicante.webp" alt="photo" />

## Thanks to my travel partners.

I want to thank my travel partners who told me about this event and I was able to attend with them and learn many new things.

<MdxImage src="/assets/blog/react-alicante-2022/travel-partners.webp" alt="photo" />

## What is React Alicante?

React Alicante is a international conference about React and React Native in one of the sunniest cities in Europe.

-   33 International Speakers, learn from some of the best front-end developers and speakers out there.
-   10 Workshops, do you want to boost your skills? This year we have 8 workshops covering different topics and levels.
-   600 In-Person + Remote, be one of them and enjoy a few days of learning, networking, sunbathing and fun.

## Event Schedule.

<MdxImage src="/assets/blog/react-alicante-2022/event-schedule.webp" alt="photo" />

## My experience.

It was the first time I had traveled to such a high level event and it was the second event I had attended. When we arrived in Alicante, we were very hungry and went out to eat. We found a place where the food was wonderful.

<MdxImage src="/assets/blog/react-alicante-2022/food-1.webp" alt="photo" />
<MdxImage src="/assets/blog/react-alicante-2022/food-2.webp" alt="photo" />

On the first day of the event I was nervous, as all the talks were going to be in English and I doubted that I would understand everything they said.

<MdxImage src="/assets/blog/react-alicante-2022/first-day.webp" alt="photo" />

But those nerves vanished when I realized that my English is much better than I thought and I could fully understand the speakers in the talks. The next step was to lose the fear of talking to people in English. So I set out during the breaks to walk around the different stands. I was able to meet many interesting companies and people thanks to this event.

I was able to appreciate the leading technologies that are used with React and that are already on my roadmap to take a look at them later, such as State Machines or GraphQL.

In the evening I was able to enjoy a wonderful sunset which I did not hesitate to take a picture.

<MdxImage src="/assets/blog/react-alicante-2022/sunset.webp" alt="photo" />

The last day, after the talks we had dinner at a wonderful place, Marmarela Mediterranean Cocktail Club. Both the atmosphere and the music were very pleasant. If I come back to Alicante one day, I will surely visit it again to have a good time.

<MdxImage src="/assets/blog/react-alicante-2022/marmarela.webp" alt="photo" />

Finally, we have been given many gifts already from the event itself, as the companies themselves in their booths, not to mention the many stickers that I have been offered and now proudly decorate my laptop.

<MdxImage src="/assets/blog/react-alicante-2022/gifts.webp" alt="photo" />

## In conclusion.

If you can afford the trip, the stay and the event, do not hesitate to attend the event. It is a unique and wonderful experience that I recommend to all programming enthusiasts. If there is a React Alicante 2023, I will surely go with great desire.


First time in React Alicante


# Migrate my website to TypeScript

<MdxImage
    src="/assets/blog/migration-to-ts/js-to-ts.png"
    alt="js-to-ts"
></MdxImage>

## What is TypeScript?

TypeScript is a programming language developed by Microsoft in 2012. Its main ambition is to improve the productivity of complex application development. It is an open source language developed as a superset of JavaScript. What this means, in simple terms is that any valid JavaScript code is also valid to TypeScript.

## What advantages offers TypeScript over JavaScript?

In terms of software development, TypeScript offers:

-   **Optional static typing.** JavaScript is a dynamically typed language, which means that types are checked, and data type errors are only detected at runtime. This can be very dangerous and can create errors during production.

-   **TypeScript introduces optional strong static typing:** once declared, a variable does not change its type and can only take specific values.

-   **Readability.** Thanks to the addition of strict types and other elements that make the code more self-expressive, you can see the design intent of the developers who originally wrote the code. This is especially important for distributed teams working on the same project. A code that speaks for itself can compensate for the lack of direct communication between team members.

-   **IDE support.** Type information renders editors and integrated development environments (IDEs) much more useful. They can offer features like code navigation and auto-complete, providing accurate suggestions.

-   **The power of object-orientation.** TypeScript supports Object-Oriented Programming (OOP) concepts such as classes, interfaces, inheritance, etc. The OOP paradigm makes it easier to build well-organized scalable code, and this advantage becomes more apparent as your project grows in size and complexity.

-   **The support of a talented community.** Behind TypeScript is a massive community of very gifted people working day by day to improve the language.

-   **Integrated support for updated versions** of ECMAScript, which is the scripting language that forms the basis of JavaScript.

-   **ECMAScript defines the standards and novelties of JavaScript.** TypeScript takes great care to include all these new features with each update.

## How to migrate the website from JavaScript to TypeScript?

It has been a bit of a dilemma, because at first I wanted to redo the whole site from scratch. Talking to a couple of people who already have a lot of experience with TypeScript, they recommended me to migrate the configurations and then fix the errors that were coming out because of the famous any. So I changed the configuration, the truth following the NextJs documentation was quite simple, in fact even much of the work is done by the framework itself.

Once this was done, the red festival began. In almost all the components I had to add things because it marked me that I had an any. I have also been able to use interfaces and it was not until I migrated the internal project of the cryptocurrency price list where I saw the ease that the TS brings us. I remember that when I was developing the project, I had to resort thousands of times to the official API page to consult what was returned.

Thanks to make the migration I was able to find a bug in my Tic Tac Toe project, which apparently was due to my bad way of developing the project in JS.

## Conclusion

I can say that I have fallen in love with TypeScript and that everything I'm going to do from now on I'm going to try to do with it. I have a few projects in mind that I want to give them a hand, but with TypeScript.

Migrate my website to TS


# Applying the DRY principle

<MdxImage src="/assets/blog/dry-principle/logo.jpg" alt="dry logo"></MdxImage>

I am currently assisting in the Savvily web project that is created with Hugo.

> Hugo is a fast and modern static site generator written in Go, and designed to make website creation fun again.

Each time when we introduced a new feature, I saw that the code was getting more complicated to maintain. So I decided start to apply the DRY principle:

The main objective of DRY (Don’t Repeat Yourself) is to reduce the number of code repetitions. Duplicating data, logic or function in your code not only makes your code long, but also makes you spend a lot of time maintaining, debugging or modifying your code. If you need to make small changes to your code, you will need to do it in several places.

## In project

The first thing I noticed that was repeated several times was the author section. It appears in both the book, where main color is pink, and podcast,where main color is yellow, products:

<MdxImage src="/assets/blog/dry-principle/step-1.png" alt="Step 1"></MdxImage>

Only the color changes, so we can make it a component. We create a new file in the partials folder and name it author.html. Inside we add this:

<MdxImage src="/assets/blog/dry-principle/step-2.png" alt="Step 2"></MdxImage>

Now we fix the section so that it ends like this:

<MdxImage src="/assets/blog/dry-principle/step-3.png" alt="Step 3"></MdxImage>

Now followed the option to subscribe to savviletter that appears on the pages of the podcast and savvi people:

<MdxImage src="/assets/blog/dry-principle/step-4.png" alt="Step 4"></MdxImage>

We create another file in the partials folder, but this time we call it subscribe.html and it will contain:

<MdxImage src="/assets/blog/dry-principle/step-5.png" alt="Step 5"></MdxImage>

And to call the component we need just add this line:

<MdxImage src="/assets/blog/dry-principle/step-6.png" alt="Step 6"></MdxImage>

Thus, we have been creating components of the product reviews section, savvily products, savvily people page header.

The last component added is podcast-episodes.html. Which we use to paint the boxes of all the episodes of each podcast. This component is born by creating a page that hosts all the episodes of the previously selected podcast. The necessity of this component comes to that when we enter in the main page of a podcast. We can only see the last three episodes. To see all the episodes you have to click on the “see all episodes” button. The way we paint these three episodes is identical to how all the other episodes are painted on the page:

<MdxImage src="/assets/blog/dry-principle/step-7.png" alt="Step 7"></MdxImage>

The content of the component is as follows:

<MdxImage src="/assets/blog/dry-principle/step-8.png" alt="Step 8"></MdxImage>

So we invoke it in the templates like this:

<MdxImage src="/assets/blog/dry-principle/step-9.png" alt="Step 9"></MdxImage>

> Call in podcast page.

<MdxImage src="/assets/blog/dry-principle/step-10.png" alt="Step 10"></MdxImage>

> Call in episodes page.

In conclusion, duplication can cause maintenance nightmares, poor factorization and logical contradictions. Therefore, if we write the same logic more than once, we should do DRY in our code. The common way to make DRY in a code is to wrap the duplicated logic with a function and replace it from all places where it appears with function calls.

In my opinion, the DRY principle is key to creating good applications, with unification and reuse improving the quality of the code base and in turn improving maintainability.


Applying the DRY principle


# Refactoring tests

<MdxImage
  src="/assets/blog/refactoring-tests/logo.png"
  alt="logo"
></MdxImage>

Yesterday I finished my Bowling kata in java and I asked my practice tutor to give me feedback on the kata. He suggested doing one more refactor, but this time instead of doing it to the code, do it to the tests using Parameterized Tests.

## What are Parameterized Tests?
Parameterized test is to execute the same test over and over again using different values. It helps developer to save time in executing same test which differs only in their inputs and expected results.

Now that we know what is a parameterized tests, let’s take a look at the test before making a refactor:

<MdxImage
  src="/assets/blog/refactoring-tests/refactor-1.png"
  alt="start code"
></MdxImage>

As we can see, the test bodies are the same. The only thing that changes is the data that we enter in the roll function and the expectation that we expect to obtain.

Let’s start by extracting the data and expect:

<MdxImage
  src="/assets/blog/refactoring-tests/refactor-2.png"
  alt="first refactor"
></MdxImage>

Now let’s create a single test that covers all cases:

<MdxImage
  src="/assets/blog/refactoring-tests/refactor-3.png"
  alt="second refactor"
></MdxImage>

As we can see, the test has been greatly simplified. I also removed the roll function and made a refactor of the saveRolls function. The refactor is instead of saving the rolls one by one, I save all the rolls.

As we can see we have reduced the size of BowlingGameShould quite a lot:

<MdxImage
  src="/assets/blog/refactoring-tests/refactor-4.png"
  alt="third refactor"
></MdxImage>

The use of Parameterized test can’t always be used and sometimes generates more noise than benefit. But in this case the test process is always the same, so it is acceptable.

Refactoring tests


# First time in JSDay Canarias

<MdxImage
    src="/assets/blog/canarias-js-2022/can-js-0.jpg"
    alt="photo"
/>

In this post I want talk about my experience at this event, which I’ve been to for the first time.

## What is JSDay Canarias?

Is a tech event focused on Javascript and its ecosystem. In this edition we have 4 workshops and 48 talks in English and Spanish all of them steered by professionals where the new tools will be explained as well as the current status of the JavaScript language and all its whole ecosystem.

At first I felt afraid to start talking to people, but I gradually lost my fear to talk with others and then I started getting in touch with some really interesting people.

I had the opportunity to see one of my favorite YouTuber.

<MdxImage
    src="/assets/blog/canarias-js-2022/can-js-1.jpg"
    alt="photo"
/>

The talks I have attended have been incredible. I’ve learned things I never thought I’d see and this has really opened my mind, especially the talk about adaptive architecture.

And I would like to thank Kevin for joining me at the event and introducing me to some very interesting people.

<MdxImage
    src="/assets/blog/canarias-js-2022/can-js-2.jpg"
    alt="photo"
/>

In conclusion, it was excellent and very entertaining, next year I will repeat.
The next event, where I am going to attend is React Alicante, which runs from September 29th to October 1st. I’m so excited to be able to go to such a big event.

First time in JSDay Canarias


# Snapshot testing

<MdxImage
    src="/assets/blog/snapshot-testing/snapshot.png"
    alt="Snapshot testing"
></MdxImage>

## What is snapshot testing?

Snapshot testing is a type of “output comparison” or “golden master” testing. These tests prevent regressions by comparing the current characteristics of an application or component with stored “good” values for those characteristics.

## How Snapshot Testing Works

As the name suggests, Snapshot testing records take a snap of the system. In Jest, this would be a render tree. Then it compares the recorded snapshot in future executions.

## Benefits of Snapshot testing

-   It introduces a clear pattern for testing the component render trees.
-   Easier to view code changes.
-   Easier to update when the component changes.
-   Allows conditional rendering tests.
-   Allows checking how components behave once you pass various combinations of props to them

## Difference with functional/unit test

The main difference between snapshot testing and functional/unit tests is, snapshot tests never assert the correct behavior of the application functionality but does an output comparison instead.

## My conclusion

Snapshot tests are easy to create and they are a great way to check that your application’s behavior isn’t changing unexpectedly during development. I’ve tested snapshot tests , but I still prefer functional/unit tests, because they bring me more security.


Snapshot testing


# My experience reading Diseño Ágil con TDD

<MdxImage
    src="/assets/blog/books/diseno-agil-con-tdd.jpg"
    alt="Diseño Ágil con TDD"
></MdxImage>

In the previous post, I mentioned that I had finished reading the book ***Diseño Ágil con TDD*** by Carlos Blé Jurado. Today I wanted to share my experience with the book and the TDD.

When I started reading the book, everything sounded very technical to me, but as I went on reading, everything started to fit like gears. There are times when I had to use Google for certain more technical terms, but I was very attracted to reading the book, which absorbed me every time I continued to read it.

***Diseño Ágil con TDD*** is not one of those books you read once and leave them on the shelf or in the closet to catch the dust. It is these books that I know I will read several times, even if it is a particular chapter to reinforce or recapitulate reading. Such as the chapter of “Mock Objects” or “Styles and Errors”, which in my opinion, were some of the best chapters of the book.

Since I started reading the book, practicing TDD and sharing my code with my fellow learners. I have seen a clear improvement when dealing with a problem, either by better structuring the code, naming tests in a more meaningful way or when performing refactoring of my old code. I still have a long way to go to improve, and I continue with the same motivation and enthusiasm as the first day when I start learning TDD.

In conclusion, I recommend reading this gem book, either because, you want to learn to do TDD or to reinforce your knowledge. I would dare to say the book complements quite well with the new Carlos’s book, ‘Código Sostenible’. I started to read him recently, and I will surely do a post about it like this, because it is another gem of a book, and it is helping me to improve as a professional in this sector.

My experience reading Diseño Ágil con TDD


# Principios SOLID

## ¿Qué son los principios SOLID?

Los principios SOLID son un conjunto de principios aplicados a la programación orientada a objetos, aplicándolos correctamente ayudan a crear un software de calidad en cualquier lenguaje de programación. Robert C Martin formulo los cinco principios de la programación orientada a objetos que posteriormente pasaron a ser los principios SOLID.

## Los cinco principios

-   **S** → Principio de Responsabilidad Única
-   **O** → Principio de Abierto-Cerrado
-   **L** → Principio de Sustitución de Liskov
-   **I** → Principio de Segregación Interfaces
-   **D** → Principio de Inversión de Dependencias

<MdxImage
    src="/assets/blog/solid-principles/solid.png"
    alt="solid principles"
></MdxImage>

## Principio de Responsabilidad Única

Este principio se explica de una manera bastante simple:

> **_Cada componente de nuestro código tiene que tener una única responsabilidad._**

Cuando nos referimos a componente, nos referimos a todo lo que engloba, ya sea una función, una clase o cual estructura concreta. Siguiendo el principio, una función tiene que tener una única responsabilidad, una clase tiene que tener única responsabilidad, etc…

Cuando cada componente de nuestro software tiene una única responsabilidad, entonces decimos que el nivel de cohesión es alto. Y si hablamos de cohesión estamos hablando también de acoplamiento. El acoplamiento es el grado de relación entre un componente y los demás.

El **_Principio de Responsabilidad Única_** nos ayuda enormemente a mejorar los niveles de acoplamiento y cohesión, lo que se traduce en un código más sencillo de diseñar, programar y mantener.

Ejemplo sencillo del Principio de **_Responsabilidad Única:_**

```java
class MyClass
{
	private $counter = 0;
	public function incrementCounter(){
		$this-> counter++;
		return $this-> counter;
	}
}
```

---

## Principio de Abierto-Cerrado

El segundo principio se vio por primera vez en el libro Object-Oriented Software Construction escrito por Bertrand Meyer por el año 1988 y se puede resumir en:

> **_Las entidades de software deben ser abiertas para extender, pero cerradas para modificación._**

Cuando se refiere a abierto para extender, se refiere a extender el comportamiento de ese componente sin necesidad de modificar su código. Los cambios en son malos, todo lo contrario, todo sistema cambia su ciclo de vida a lo largo del tiempo. Esto nos ayuda a añadir a los componentes nuevas funcionalidades, con la certeza de que el código anterior no se vea comprometido y seguirá funcionando.

Este principio se suele resolver usando **_polimorfismo_**, es decir, en vez de usar un componente principal para resolver una operación, este lo delega en los objetos que utiliza, liberándose de esa responsabilidad.

Una forma sencilla de saber que estamos violando el **_Principio de Abierto-Cerrado_**, es identificar cuales son los componentes que estamos modificando más amenudeo.

Un ejemplo sencillo del **_Principio de Abierto-Cerrado:_**

```java
enum Class VehicleType{CAR,MOTORBIKE}
interface Vehicle{
	fun draw()
}
class Car: Vehicle{
	override fun draw(){
		//Draw the car
	}
}
class Motorbike: Vehicle{
	override fun draw(){
		//Draw the motorbike
	}
}
fun draw(vehicle: Vehicles){
	vehicle.draw()
}
```

Como podemos apreciar en el ejemplo estamos usando también el **_Principio de Responsabilidad Única._**

---

## El Principio de Sustitución de Liskov

Este principio viene a hablar sobre cómo usar una de las herramientas que nos da la programación orientada a objetos a la hora de reutilizar código, que es la herencia y fue desarrollado por Barbara Liskov, en una conferencia allá por el año 1987. La herencia es una potente herramienta que nos permite reutilizar código, también es una de las herramientas que nos permite implementar el polimorfismo, que es otro de los grandes puntos fuertes de la programación orientada a objetos.

Este principio viene a decir:

> **_Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas._**

La definición del principio también puede verse de la siguiente manera:

> **_Debe ser posible utilizar cualquier objeto instancia de una subclase en lugar de cualquier objeto instancia de su superclase sin que la semántica del programa escrito en los términos de la superclase se vea afectado._**

Esto lo que nos quiere decir es que si tenemos una clase hija, deberíamos poder sustituir a las clases padre sin que el código se vea comprometido. Esto es lo que nos permite es a extender una clase, sin modificar el comportamiento de la clase padre. Si un método sobrescrito no hace nada o lanza una excepción, seguramente estamos incumpliendo este principio. Otra manera de ver si estamos incumpliendo el principio, es si los test de la clase padre no funcionan para la hija.

En este ejemplo podemos ver que la clase elefante solo puede caminar, mientras que la clase perro puede caminar y saltar.

```java
open class Animal{
	open fun walk(){}
}
open class LightweightAnimal: Animal(){
	open fun jump(){}
}
fun jumpHole(animal: LightweightAnimal){
	animal.walk()
	animal.jump()
}
class Elephant : Animal()
class Dog: LightweightAnimal()
```

---

## El Principio de Segregación de Interfaces

This.simple()

> **_Muchas interfaces específicas son mejores que una interfaz de propósito general._**

Si desarrollamos interfaces muy grandes estamos obligando a que los objetos que implementen esta interface tengan todos los métodos de esta. También podemos enunciar el principio de la siguiente manera:

> **_Las clases que implementan interfaces no tiene que estar obligadas a implementar métodos que no usan._**

Debemos priorizar las interfaces pequeñas sobre las grandes. Si necesitamos una interface muy grande, es mejor que lo dividamos en una serie de interfaces más pequeñas, de manera que si nuestros objetos solo implementen las interfaces que realmente necesiten y no tengamos que crear funciones que no necesitamos solo porque lo dice la interface.

El ejemplo nos muestra un uso correcto de nuestro **_Principio de Segregación de Interfaces:_**

```java
interface ReadableStreamIface{
	open function openIt()
	open function readIt()
}
interface WritableStreamIface{
	open function writeIt()
}
class File: ReadableStreamIface, WritableStreamIface{
	open function openIt(){//...}
	open function readIt(){//...}
	open function writeIt(){//...}
}
class File: ReadableStreamIface{
	open function openIt(){//...}
	open function readIt(){//...}
}
```

---

## El Principio de Inversión de Dependencias

Y para terminar el ultimo principio de SOLID, que nos habla de una manera de desacoplar nuestros objetos. Suele definirse como:

> **_Los módulos de alto nivel no deberían depender de módulos de bajo nivel, ambos deberían depender de abstracciones._**

Que suele venir acompañado por:

> **_Las abstracciones no deberían depender de detalles, sino que los detalles deberían depender de las abstracciones._**

Esto se traduce a que nuestros objetos están acoplados entre si. Hay una dependencia estrecha entre nuestros objetos que deriva en tres efectos colaterales, la rigidez, la fragilidad y la inmovilidad.

Cuando hablamos de **_rigidez_** nos referimos a que nuestro sistema es difícil de modificar. Esto implica que cualquier cambio nos va a obligar a cambiar cosas en muchas partes de nuestros sistemas.

Con el termino **_fragilidad_** queremos decir que, dado que cada cambio puede tener muchos efectos inesperados en diferentes partes de nuestro código, nuestro sistema es frágil. Es decir que se puede romper con facilidad.

Si nuestro código está acoplado es muy difícil que podamos usarlo en otra parte de nuestro programa. Para esto usamos el termino inmovilidad. Esto dificulta en gran medida su reutilización.

En resumen, un mayor acoplamiento se traduce en una mayor rigidez, un sistema más frágil y una **_inmovilidad_** que se traduce en, no solo un menor índice de reutilización sino en un mayor coste de mantenimiento.

Podemos ver la flexibilidad que le otorga esta arquitectura a nuestras clases:

```java
interface Persistence{
	fun save( shopping: Shopping)
}

interface PaymentMethod{
	fun pay( shopping: Shopping)
}

class Shopping

fun main(){
	val shoppingBasket = ShopingBasket( Server(), Paypal())
}

class ShopingBasket(
	private val persistence: Persistence,
	private val paymentMethid: PaymentMethod
){
	fun buy( shopping: Shoping){
		persistence.save( shopping)
		paymentMethid.pay( shopping)
	}
}
```


Principios SOLID


# Colaboración en un proyecto privado

En este post quiero compartir mi experiencia en un proyecto que he realizado en colaboración con una empresa. Me hubiera gustado mostrar algunas cosas del proyecto, pero al ser un proyecto privado no se puede filtrar nada, pero sí puedo comentar como me he sentido a lo largo del proyecto y mi experiencia con el stack tecnológico usado en el proyecto.

## Tecnología usada en el proyecto

El proyecto en primer lugar iba a ser con React en FrontEnd y Symfony en el BackEnd. Mis primeros días peleando con React fueron muy estresantes, todo a raíz de que me faltaba bastante experiencia en React como para poder usarlo en un proyecto real. Gracias a esto, pude ver que aún me faltaba mucho que aprender en React para poder usarlo en un proyecto real. Así que, al final usamos Symfony también para el FrontEnd. La verdad es que fue la primera vez que usaba Symfony, me ha sido bastante satisfactorio el aprendizaje del mismo y su uso. Pasados los algunos días, ya me había adaptado bastante bien y hasta me han ido asignado cosas del BackEnd, que nunca ha sido mi punto fuerte, pero pude ver que tampoco era para tanto, simplemente me faltaba práctica e investigación.

Al ver como iba avanzando el proyecto y que las cosas empezaron a tomar forma, me daba una alegría impresionante. Ya no se trataba de la típica práctica de casa que te montabas para aprender algo y emocionarte porque funcionaba , era algo real. Algo que veía funcionar y sé que en el futuro muchas personas van a usar en su trabajo. Estoy muy agradecido con la empresa que me brindo esta oportunidad de trabajar en un proyecto de esa magnitud y darme la oportunidad de participar en algo tan valioso. En general, con este proyecto he aprendido a no tenerle miedo a nuevos retos, ya sea en el BackEnd o en el FrontEnd .

## El futuro

Dentro de una semana empiezo a realizar una serie de prácticas de formación en otra empresa, donde espero aprender muchas cosas nuevas como TDD, mejorar mi forma de programar, y hacer un código más legible para otras personas que vengan después. Ya iré creando post con las cosas nuevas que me irán llamando la atención.

Espero que vuelva a encontrar la rutina que tenía antes, tanto en aprender cosas nuevas leyendo los libros, como en escribir entradas en el blog y continuar con mi portafolio en mis tiempos libres ya que por falta de tiempo he abandonado.

Colaboración en un proyecto privado


# Mi primera entrevista de trabajo como programador web

Hace días he tenido mi primera experiencia con lo que es mi primera entrevista de trabajo como programador web. He tenido otras entrevistas pero nunca una en este sector.

Todo comenzó postulando para un proyecto que me llamaba bastante la atención ya que sería una oportunidad de aprender Kotlin y Spring, siendo cosas que tenía por aprender en mi lista.

Como cabía de esperar lo primero que me preguntaron fue, “que es lo que te llamo la atención de nuestra empresa”. Les explique que el proyecto que presentaban me llamaba muchísimo la atención ya que era en una tecnología , arriba mencionada, que llevaba tiempo en mi lista “ToLearn”.

Luego seguía una pregunta bastante interesante, “que esperas de nuestra empresa”. A lo que respondí experiencia y ver el funcionamiento de un proyecto real en marcha.

Al final de la entrevista, como era de esperar, hemos hablado en ingles, lo que me ha sorprendido bastante ya que he entiendo toda la conversación ,pero me costo un poco expresarme.

Como conclusión, me llevo un buen sentimiento de esta nueva experiencia, con la que mejoro como profesional, sabiendo lo que tengo que mejorar y como sentirme en las futuras entrevistas.

Mi primera entrevista de trabajo como programador web


# Nuevo amanecer

Esta semana me la he pasado liado y casi no he podido dedicarle nada de tiempo a seguir aprendiendo React. Por otro lado, esta semana me de deprimido un poco al estar parado y no tener un objetivo claro que alcanzar, ya que mi ultima meta fue terminar el ciclo superior, pero y ahora? Estaba como loco por querer empezar a trabajar, pero no se pudo… Así que hay veces que paso horas mirando ofertas de trabajo y viendo a la cual puedo postular con mi perfil actual.

Hace un par de días me arme de valor y me apunte a colaborar en la traducción del libro de TDD a TypeScript, la verdad nunca pensé que hacer test fuera tan entretenido y me lo fuera tomar como un juego. Apenas he terminado el primer capitulo y estoy a la espera de la aprobación del autor para seguir con este pequeño juego.

También me apunte a continuar el proyecto que deje durante el curso, así puedo aplicar mis conocimientos de React en un proyecto real con el fin de pulir mis conocimientos y agilidad.

Así que vuelvo a tener unos objetivos nuevos, tanto el libro como el proyecto, son cosas que me motivan a seguir mejorando y dar el 100% de mi.


Nuevo amanecer


# Primera semana después de la FCT

Esta semana ha empezado con un pequeño sabor agridulce por mi parte, ya que pensé que iba a trabajar, pero no pudo ser. Entonces me he propuesto ser activo y autoformarme para mejorar como programador. Así he empezado terminando el curso de OpenWebinars de Xamarin que había empezado en la FCT para el proyecto que he podido desarrollar gracias a ese curso y un par de videos de YouTube que la verdad me han ayudado a crear mi primera aplicación móvil.

Nunca pensaría que ese proyecto que pensé que no llegaría a nada, se convirtiera en una app que esta apunto de ser probada en tiendas. Esa sensación de haber creado algo que facilita el trabajo a otras personas, es impresionante… La aplicación en sí es muy sencilla, seleccionada la marca de ropa y la tienda, basta con escanear con la cámara del móvil o introducirlo manualmente el código de barras del producto y nos devuelve la información del producto en la tienda seleccionada,(su referencia, descripción, talla, modelo, precio y el stock que hay actualmente en la tienda). También nos da una lista del stock en otras tiendas del mismo producto, por si en nuestra tienda no hubiera stock. Y una lista de las diferentes tallas y modelos que tiene el producto.

Ahora que tengo esta experiencia como he comentado en el anterior blog, mi próximo objetivo es React. Ya he estado viendo cositas básicas y por ahora me parece muy fascinante, se parece en parte a Razo pero sin ser igual. Ahora que visto algo de los componentes y el JSX pues se me vienen montón de cosas a la cabeza que he hecho en el pasado y que reharía usando React, aunque por ahora no sé nada de este framework.

Hoy me han recomendado usar TypeScript en React en vez de JavaScript así que me he pasado toda la mañana investigando y estudiando TypeScript. Me siento un poco estresado por querer aprende varias cosas, pero sé que todo es cuestión de tiempo, dedicación y sobre todo aprender de mis errores.


Primera semana después de la FCT


# Mock Objects in TDD

Recently finished reading “Diseño Ágil con TDD” book from Carlos Blé, where in chapter five talks about mock objects in TDD, that wasn’t the first time I hear about mock objects, but never imagine what great use can have this thing.

## What are Mock Objects?

The term ‘Mock Objects’ has become a popular one to describe special case objects that mimic real objects for testing. If you’re testing a pure function, which only depends on it, there we no need mocks. But if you want to test a function or method that depends on different function or method, then we can use mocks.

<MdxImage
    src="/assets/blog/mock-objects-in-tdd/mock-objects.png"
    alt="brain-things"
></MdxImage>

## How are Mocks Created?

Right now, you might be thinking that creating these mocks would mean a lot of additional work. Most language environments now have frameworks that make it easy to create mock objects. What’s often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing.

## Why Mocks Improve Development?

Mocks play a critical role in the TDD process, making it possible to develop code using a top-down approach. This means that you start at the beginning of the program, the main loop, and work your way down to the lowest-level peripheral drivers.

## Types of Mock Object

From the most basic to the most advanced type we had Dummy, Stub, Spy, Mocks and Fake.

## Dummy

A class that you pass into something when you don’t care how it’s used. e.g. As part of a test, when you must pass an argument, but you know the argument will never be used. In general, if a dummy is used, you will want it to throw an exception to tell you something is wrong.

## Stub

Provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.

## Spy

Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.

## Mocks

They are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

## Fake

This objects actually have working implementations, but usually take some shortcut which makes them not suitable for production.


Mock Objects in TDD


# Aprendiendo React

En este post y los siguientes, quiero ir dejando conocimientos que voy aprendiendo sobre React, así puede ser que sea util para otras personas que buscan aprender React.

<MdxImage
    src="/assets/blog/learning-react/react.png"
    alt="React"
></MdxImage>

## ¿Qué es React?

React es una librería de codigo abierto de JavaScript, que nos permite diseñar interfaces de usuario con el objetivo de facilitar el desarollo de aplicaciones en una sola página. Fue creado por Facebook en el 2013 y desde entonces lo han mantenido junto con una comunidad de desarolladores independientes.

Ahora que tenemos una ligera idea de que es React, vamos a ver algunos conceptos:

-   Create React App
-   JSX
-   Componentes
-   Props vs States
-   Hooks básicos
-   Ciclo de vida de un componente
-   Listas y keys
-   Renderizado condicional
-   Composición vs herencia

## Create React App

Create React App es un CLI oficial de React que nos permite como su nombre indica, crear una nueva aplicación de página única de un modo rápido y con poca complejidad.

El comando para crear una nueva aplicación de React es el siguiente:

`create-react-app hola-mundo`

## Que es el JSX?

El JSX es una extensión de sintaxis para JavaScript. En una primera instancia, puede parecer HTML pero es JavaScript. Sirve de preprocesador (como Sass) y transforma el codigo a JavaScript.

## Componentes

Los componentes son pequeños y reutilizables fragmentos de código que devuelven un elemento de React para ser renderizado en una página. La mayoría de las aplicaciones React tienen muchos componentes pequeños, y todo se carga en el componente principal de la aplicación, permitiendo separar la interfaz de usuario en piezas independientes,reutilizables y pensar en cada pieza de manera aisalada.

Un componente de clase es una clase de JavaScript que extiende de la clase Component de React.

```JavaScript
class HolaMundoextends React.Component {
  render() {
    return <h1>Hola Mundo</h1>;
  }
}
```

Los componentes funcionales son funciones que normalmente reciben un objeto (llamado props) y retorna un ReactNode (ReactNode uede ser un elemento html, un string, un booleano, entre otros tipos de datos).

```JavaScript
function HolaMundo(props) {
  return <h1>Hola Mundo, {props.name} os saluda.</h1>
}
```

## Props vs States

Como menciono antes, las props son objetos que reciben los componentes del componente padre, son sólo de lectura y no deben ser modificados de ninguna forma. De una manera más sencilla, son las propiedades del componente las cuales cumplen un rol importante en el proceso de desarollar una página web.

El estado es un objeto React incorporado que se utiliza para contener datos o información sobre el componente. El estado de un componente puede cambiar con el tiempo; cada vez que cambia, el componente se vuelve a renderizar.

-   Cada vez que cambia el estado de un objeto, React devuelve el componente al navegador.
-   El objeto de estado se inicializa en el constructor.
-   El objeto de estado puede almacenar varios props.
-   this.setState() se utiliza para cambiar el valor del objeto de estado.
-   La función setState() realiza una fusión superficial entre el estado nuevo y el anterior.

## Hooks básicos

Los Hooks fueron incorporados en la version 16.8 de React , que nos permite tener estado, y otras características de React, en los componentes creados con una funcion. Esto antes, no era posible y nos obligaba a crear un componente classe para poder acceder a todas las posibilidades de la librería.

En los hooks básicos podemos encontrar **_useState_** y **_useEffect_**:

**_useState_** nos permite otorgar estados a nuestros componentes, permitiendonos renderizar de nuevo el componente cada vez que cambie el contenido guardado en useState.

**_useEffect_** nos permite ejecutar codigo en el momento que se crea el componente, siendo como un metodo de ciclo de vida, que nos permite acceder en momentos concretos , cuando se crea, cuando se destruye, etc, al componente.

## Ciclo de vida de un componente

El ciclo de vida de un componente son una serie de funciones que se ejecutan en distintos momentos de la vida del componente y nos permiten realizar distintas acciones en estos momentos. El ciclo de vida se puede dividir en 3 etapas, Montaje, Actualización y Desmontaje. A su vez cada ciclo de vida, nos va a proporcionar diferentes métodos de ciclo de vida para el componente, dependiendo en qué fase se encuentre, que vamos a poder utilizar.

<MdxImage
    src="/assets/blog/learning-react/component-live-cicle.png"
    alt="component live cicle"
></MdxImage>

## Listas y keys

Cuando creamos una lista de componentes, a cada uno se le debe asignar una key única, para que react lo pueda identificar y distinguir de los otros componentes en la lista.

Las keys ayudan a React a identificar que ítems han cambiado, son agregados, o son eliminados. Las keys deben ser dadas a los elementos dentro del array para darle a los elementos una identidad estable. La mejor forma de elegir una key es usando un string que identifique únicamente a un elemento de la lista entre sus hermanos. Habitualmente usaremos los IDs de nuestros datos como key.

## Renderizado condicional

En React, puedes crear distintos componentes que encapsulan el comportamiento que necesitas. Entonces, puedes renderizar solamente algunos de ellos, dependiendo del estado de tu aplicación. El renderizado condicional en React funciona de la misma forma que lo hacen las condiciones en JavaScript. Usa operadores de JavaScript, como if o el operador condicional, para crear elementos representando el estado actual, y deja que React actualice la interfaz de usuario para emparejarlos.Veamos un ejemplo:

Teniendo estos dos componentes:

```JavaScript
function UserGreeting(props) {
  return <h1>Welcome back!</h1>;
}
function GuestGreeting(props) {
  return <h1>Please sign up.</h1>;
}
```

Vamos a crear un componente Greeting que muestra cualquiera de estos componentes dependiendo si el usuario ha iniciado sesión:

```JavaScript
function Greeting(props) {
  const isLoggedIn = props.isLoggedIn;
  if (isLoggedIn) {    return <UserGreeting />;  }  return <GuestGreeting />;}
ReactDOM.render(
  // Intentar cambiando isLoggedIn={true}:
  <Greeting isLoggedIn={false} />,  document.getElementById('root'));
```

## Composición vs herencia

La herencia en React es muy similar a la de JS, y no hay mucho que agregar sobre ese tema. Por ejemplo, si vamos con la clase, existe la misma herencia que con las clases de JavaScript. Podemos usar solo una extensión simple para heredar métodos del componente principal.

La composición de componentes es uno de los patrones más esenciales en React relacionado con el modelo de componentes. Nos ayuda a construir incluso funciones muy complejas usando muchas partes pequeñas. Al usar la composición, podemos implementar otros componentes en el componente. Por ejemplo, cuando creamos el perfil de usuario, podemos crear el componente userProfile, poner componentes userPhoto y usar userDescription como accesorios secundarios.

Cuando desarrollamos aplicaciones para React, existen algunas razones principales por las que deberíamos optar por la composición en lugar de la herencia. El primero es la posibilidad de evitar componentes demasiado anidados. Debido a props.children, podemos separar el código en lugares separados. No necesitamos profundizar mucho en los componentes y crear muchos si. La siguiente cosa importante. Con la composición, seguimos el modelo de todo es componente diseñado por React.

Aprendiendo React


# Mi experiencia en la FCT

Cuando me dijeron que voy a ir a la FCT, quería ir a Lean Mind junto con mi compañero de clases que me ha acompañado desde el primer año del DAW, pero en ese momento mi vida personal pasaba por problemas económicos así que tome la decisión de renunciar ir a formarme a LM y pedir a mi tutora que si pudiera darme una empresa donde tenga mayor posibilidad de contratarme.

## Mi empresa en la FCT

Así empezaron 3 meses en Grupo Número 1, donde he aprendido que aunque no sepa nada de programación en móviles, no es tan distinto de programar una web.

## Como afronté el reto propuesto por la empresa

 He estado estudiando por mi cuenta como hacer una aplicación para tiendas de ropa y me he topado con Xamarin Forms, permite a los desarrolladores crear interfaces de usuario en XAML con código subyacente en C#. Estas interfaces se representan como controles nativos con mejor rendimiento en cada plataforma.

 
<MdxImage
  src="/assets/blog/fct-experience/xamarin.jpg"
  alt="Xamarin"
></MdxImage>

 A medida que iba programando y estudiando, veía como la aplicación iba tomando forma y cada vez me motivaba más y más. Ahora que he terminado mi FCT y miro la aplicación, que está lista para empezar a hacer pruebas en tiendas, veo lo mucho que he aprendido y he avanzado en mi camino de ser un buen programador.

## Conclusión

 En general estoy muy contento con mi trabajo y esfuerzo desempeñado en la FCT. Agradezco toda la experiencia que he obtenido de mis superiores, que me han enseñado desde ajustar mi mente a la hora de programar, hasta aprender cosas sobre bases de datos MYSQL que desconocía.

## Agradecimiento

 Siempre voy a estar agradecido a mi compañero, que se ha convertido como un hermano que nunca tuve en estos dos años. Siempre ha estado ahí para animarme y ofreciéndome un apoyo incondicional en mi peor momento de mi vida.


Articles