Forem: Adrian Guillen

What is a typical day like as a developer? 🖥️😵‍💫☕

Adrian Guillen — Wed, 21 Aug 2024 16:33:54 +0000

When someone starts learning programming and searches for information about how a developer lifestyle is, it’s easy to find a lot of contradictory messages and some of them are really unhealthy. One of the most controversial topics is how a programmer spends his time, and that’s why I’m writing this article, to bring some light and clarify how in my experience a developer spends his day.

First of all, I will share a little about myself so you can have some context about my experience as a developer. I’ve been working as a frontend developer in Spain and Ireland for more than 7 years at the time of writing this article (August 2024). I worked in a medium size consultancy company for a year, around 4 years in a small consultancy company making projects for IBM and other companies of different sizes, then I've work for a year at Atrapalo who is an online travel agency and my last two jobs had been in Ireland working on a product company and my current one is an AI startup. As you can see I have experience in consultancy but also in product based companies, and startups and I worked in very different environments, projects and applications.

How developers spend their time

Is pretty common to hear in the IT community about developers who say that they spend hundreds of hours per week developing, or working on side projects, contributing on Open Source projects, drinking coffee and writing thousands of lines of code. But what is the reality of an average developer? I say “average developer” because some of the people who share their content on social media aren’t showing the reality of their life, but the parts they want to share, and usually the reality they show isn’t the one of an average developer as you or myself.

Some people think that a developer is a machine that transforms ideas (and coffee) to code, but programmers do way more things other than programming. For example, if you work in a medium or big company it is usual to follow an agile workflow, that means that the application or product that you are developing would be released to the client in different phases. If you work with agile it is common to have a meeting every day with the developer team to share with your teammates what you did the day before, what are you going to do today and if you had some problems. And also it is common to make demonstration meetings with the client every few weeks to show him the project progress.

Whether developers work in an agile workflow or not, they will spend time in meetings every day because in the real world, the team needs to prioritize tasks, share knowledge between them, or discuss the better way to solve a problem.

Every day when a developer starts working, the first thing is to remember the work done the day before, it may sound dumb, but a lot of time is spend this way, and if the problem is complex, the amount of time needed to start working will increase exponentially. And after every meeting this process starts again, so if a developer has lots of meetings in a day it would be very difficult to be productive.

When developers start working on a problem the first thing they do isn’t write code, the first thing usually is analyze the problem, and figure out the best way to solve it. If a programmer starts writing code without analyzing the problem, the code resulting will be in most cases poor, so the most common scenario is spending some time thinking about different ways to solve it. Also it is common to ask for help or different opinions to another teammate, specially when you're facing challenging problems.

The developers face new problems almost every day, so it is common that they need to learn new things constantly. They spend a lot of time googling, learning from tutorials, forums or documentation. A developer doesn’t need to know everything, only where to find the information needed every time.

Finally, when a developer isn’t in a meeting and knows what needs to be done and how to do it, the programmer will start writing code. As you can see, writing code isn’t the first thing a developer does every day in the morning when starts working.

How much time does a developer spend writing code?

Is difficult to measure how much time a developer spends writing code, but if we are talking about an 8 hours workday, I assume that only 3–5 hours will be spent writing code, but definitely no more than that. This is an approximation, it is impossible to measure the amount of time spent programming, and it depends a lot on the experience of the developer and the company that developer is working for.

Is common to think that the more experienced the developer is the more time spent programming, but this is completely wrong. In fact, the more skilled you are the more the team will need your help. Also you will spend more time helping other teammates and taking part in meetings with clients or the product team instead of programming.

I hope that this article will help to break some myths about how a developer spent his time. What do you think about it? How do you spend your time? Do you think that you spend more than 3–5 hours writing code?

👀Understanding the JavaScript Call Stack: How Your Code Really Runs 🚀

Adrian Guillen — Mon, 19 Aug 2024 19:28:36 +0000

How the JavaScript call stack works is something that every frontend developer has asked at least once in his career, and in my opinion, it's not a question that has been answered in most places, and the answers are not always clear or easy to understand. That's why I've decided to cover the topic in this post.

Let's start from the beginning. The JavaScript engine runs the code line by line synchronously, and every time a function is executed, it creates an execution context (a space in memory to store all the scoped properties that exist only inside that function) and adds the function to the call stack.

JavaScript only executes the code of the function that is on the top of the stack, and when a function finalises and returns its value, the engine removes the function from the call stack and starts working on the next one.

When the call stack is empty, the JavaScript engine continues running the code in the next global context, or what is the same, continues executing the lines that are in the root of the JavaScript file and don't belong to any function.

Let's see some examples, line by line:

const num1 = 2;
const num2 = 5;

function sum(a, b){
return a + b;
}

const result= sum(num1, num2);
console.log(result) // 7

This is a really simple code that defines 2 constants (num1 and num2) and then defines a function sum that sums 2 numbers and returns the result of the sum. Finally, the constant result is created, and the result of executing sum with the arguments num1 and num2 is assigned to it. Then the value of the result is printed on the console.

If you think that the previous explanation is too simple or too complex and does not explain anything, please bear with me, we are getting to the interesting stuff.

Let's see what the JavaScript engine is doing, line by line. In the first line, the engine creates a label num1 and stores in memory the value 2.

const num1 = 2;

The second line does the same for label num2. It creates a label num2 and stores in memory the value 5.

const num2 = 5;

What this means is that whenever someone inside the global scope requires the value of num2 the engine is going to change the label and put the value 5 instead.

Let's continue with the next line. The next line is the function sum. What do you think the engine is going to do? Do you think it is going to execute the function or add it to the call stack? Nope! What the engine is going to do is store a new label named sum and store the code inside the brackets in memory. Or what is the same, It's going to store the function definition and assign it to the sum label.

function sum(a, b){
return a + b;
}

if we could visually see the memory of the code that we've run so far, we would see something like this:

Label name	Value in memory
num1	2
num2	5
sum	function definition

The next line is a really interesting one. When the JavaScript engine reaches the next line, it creates the label result, but at this point, it doesn't yet know what value needs to be assigned to the label because the value is the result of executing a function, so first, it needs to execute the function, do whatever the function needs to do, and get the result from the return value.

const result= sum(num1, num2);

At this point, the engine adds the function to the call stack and also creates a new execution context, which is a new space in memory were JavaScript can store the value of the args and every other property that is inside of the function without colliding with the global context.

Call stack
sum
Global

First of all, the engine creates in memory the labels a and b which are the names given to the parameters, and it assigns the value of the arguments 2 and 5 respectively.

If we could see the memory at this specific moment, we would see something like this:

Label name	Value in memory
a	2
b	5
return	2 + 5 = 7

In this case, the function is really simple and only returns the value of the sum between a and b, so the engine substitutes the parameters with the values of the arguments and returns the value to the global execution context. Finally, the function is removed from the call stack, and only the global context remains.

Call stack
Global

At this point, the result of the function is assigned to the label result and we can print the value on console with the console log.

Let's take a look at how the global memory looks now:

Label name	Value in memory
num1	2
num2	5
sum	function definition
result	7

Did you noticed? the label result has a value of 7? and also sum still has the function definition inside.

Let's take a look at the next code:

const num1 = 2;
const num2 = 5;

function sum(a, b){
return a + b;
}

const result= sum(num1, num2);
console.log(result) // 7

function sumThreeNumbers = (x,y,z) => {
return sum(x, y) + z
}

const result2 = sumThreeNumbers(4,6,2)
console.log(result2) // 12

The main difference is that now we have a new sumThreeNumbers function and we are creating a new result2 constant and assigning the value of running the function sumThreeNumbers with the arguments, 4, 6 and 2.

Let's take a look at how the call stack works when we run nested functions.

If we jump to the line when we define the constant result2 the global memory would look something like this:

Label name	Value in memory
num1	2
num2	5
sum	function definition
result	7
sumThreeNumbers	function definition

Just as on the previous example, the JavaScript engine doesn't know what value to assign to the label result2, to get the value, first needs to execute the function sumThreeNumbers with the arguments. The function is added to the call stack, and a new execution context is created. The execution context would look like this:

Label name	Value in memory
x	4
y	6
z	2

So the first thing that JavaScript does is create the parameter labels and assign the value provided by the arguments.

Now let's take a look at our call stack

Call stack
sumThreeNumbers
Global

As you can see, the call stack only has the sumThreeNumbers item (apart from the global context that is always present).

To be able to get the result value, the function sum needs to be executed first, so the engine will add the function to the call stack and create a new execution context for the sum function.

Call stack
sum
sumThreeNumbers
Global

As the sum function is on top of the call stack, Javascript needs to run sum first to be able to continue running sumThreeNumbers.

This is how it's going to look the execution context for the function sum:

Label name	Value in memory
a	4
b	6
return	4 + 6 = 10

As you know, it will return _10 _and it will be removed from the call stack

Call stack
sumThreeNumbers
Global

The JavaScript is going to continue executing the sumThreeNumbers and the execution context will look like this:

Label name	Value in memory
x	4
y	6
z	2
return	10 + 2 = 12

It will return the value 12 and be removed from the call stack.

Call stack
Global

Then the value 12 will be assigned to the property result2 and the value 12 will be displayed in the console.

I hope this post has help you to understand how the JavaScript call stack works, if so please leave a comment and a like. I see you in the next one!

❌ How to Cancel Fetch Requests in JavaScript 🚀

Adrian Guillen — Sun, 30 Jun 2024 12:47:49 +0000

Ever wanted to cancel a fetch request in JavaScript? Discover how the **AbortController **makes it easy to manage and stop async operations. Check out this quick guide to master it in just a few steps!

First, you might wonder when you would need to cancel a fetch request. Here are an examples:

When filtering a list of elements in JavaScript, the data often comes from an API. It’s common to add filtering, pagination, and other features to display the list correctly. However, JavaScript does not guarantee that fetch requests will be resolved in the order they were made.

For instance, if a user applies filters quickly, you might make requests A, B, and C in that order. Ideally, you want to display the results of the latest request (C) last. However, due to the fact that the browser and server work asynchronously, requests might resolve out of order. Request C could be resolved first, followed by A and B, leading to incorrect data being displayed to the user.

In such situations, AbortController **helps by allowing you to **cancel requests A and B, ensuring only the latest request (C) is active. This way, the user sees the expected results.
I’m going to show you step by step an example about how to use AbortController to handle this kind of situation.

First, create an AbortController instance. Retrieve the signal from the controller, which will be used to control the fetch request.

Then, use the signal in the fetch request options. Handle the response by logging the data. If an error occurs, check if it's an **AbortError **to know if the request was cancelled using the AbortController. If not, you can handle the error as usual.

Finally, when you need to cancel the fetch request, because for example, a user is selecting a new filter you can use controller.abort to cancel the previous request. I’m using a setTimeout in this example for simplicity.

This is the complete code example.

If you’ve found this short tutorial helpful, please like this post and share it with your colleagues and friends. Have you previously used the AbortController? Share your thoughts in the comments below!

✈️ Moving Abroad: My Journey as a Frontend Developer in a New Country 🌎

Adrian Guillen — Mon, 24 Jun 2024 21:10:20 +0000

In the next few lines, I will share my personal experience of moving from Barcelona to Dublin while working as a developer. It has been a very interesting experience with more than a few challenges, and finally, almost 2 years later, I’m ready to share my experience.

Everything started as all big changes do, with a mix of excitement, fear, and a lot of planning. It was a very planned decision, as my wife and I had spent countless hours talking about leaving Spain to try a different country. We knew that our future country needed to be in Europe, as none of us wanted to be too far from our family, and we knew that we wanted to live in a country where their main language was English. That left only two potential options: the UK and Ireland.

Before Brexit, we both liked the idea of moving to Scotland, as we’ve been there on vacation a few times, and we really liked the lifestyle and people, and my wife was especially in love with Edinburgh. However, Brexit changed everything. As you may know, after Brexit, you need to get a visa to stay in the UK. Besides, the COVID situation was pretty recent (it was 2022), so we felt like trying to move to the UK was too risky for us. The only option left was Ireland.

I knew that Ireland had the headquarters of the biggest tech companies in the world, such as Google, Amazon, Apple, Microsoft, and many more, so for me, Ireland was an option that really excited me from a career point of view. There was only one tiny problem. I had never visited the country, and apart from knowing that it could be good for my career, I had no idea about it. My wife, on the contrary, had visited Ireland on one occasion, and she really liked the lifestyle and the culture, as it’s relatively similar to Scotland, with green landmarks, a lot of castles and monuments, and a lot of nature around, which is something that we both value a lot.

After investigating the country from very different points of view (economics, politics, culture, history, cost of living, salaries, work market, etc.), I found it pretty appealing, especially since we were living in Spain, which was facing economic problems, and the work market was pretty slow with a huge unemployment rate (it still has one of the higher unemployment rates in Europe).

Ireland was not perfect, though. After some investigation, I found that Ireland was facing a severe housing crisis, and the cost of living has been skyrocketing since the start of the war in Ukraine. I was not scared, though, as Spain was facing the same issues, and to be fair, I think most of the problems that I found online were the same in most parts of Europe.

So, once the decision about the country was made, there was a tiny, small detail to solve. We only wanted to move to Ireland once I found a job while still living in Spain, as we thought it would be too risky to leave our stable jobs in Spain to live in a different country without having a job or having any contact that could help us in case things didn’t go as planned as they usually do.

Looking for a job in Ireland from Spain

First of all, I would like to share a little bit about my background. In 2022, I had a little more than 5 years of experience, and I was working in Spain for an online travel agency called Atrapalo as a senior frontend developer, working with technologies such as Next.js, React, and Typescript and following clean architectures such as domain-driven design. In summary, I like to think that I have a really good CV, as I’ve always tried to work for companies that make me grow in my career and offer me opportunities to learn the latest technologies.

With that in mind, I started translating all my LinkedIn and CVs from Spanish to English, and I started applying to different job positions.

I also started speaking in English with my wife daily to practice, as I was not 100% fluent, especially when speaking. By then, my English was good enough to read (a few months prior to making the final decision to move, I started reading books only in English), and I was able to understand 80% of a conversation, but when I tried to speak, I felt really awkward, and I got extremely nervous. After a month of speaking daily and exclusively in English with my wife, I improved enough to feel relatively comfortable having phone interviews without choking.

After a month of sending CV’s and having some phone interviews with recruiters, I reached the final stage with 2 companies. I got an offer from one of them, which I decided to accept. The offer was good enough, but in the lower range for someone with my skillset. And there was no relocation package and no fancy perks. However, for me, the most important part was the opportunity that this job offered me. We were moving to Ireland.

Preparing to move to Ireland

When I received the offer, I told the company that I needed six weeks to be ready. Two of these weeks were to finish the relationship with my current employer (as it’s common in Spain), two weeks to make the proper arrangements to move, and 2 weeks to establish ourselves in Ireland.

This seems like enough time, but there was so much that needed to be done. First of all, we tried to sell all the things that were worth selling. We gifted or threw away the rest. We also got our passports in place (it’s not really needed because we were moving inside Europe, but it’s always a good idea to have the passports ready just in case). We also started looking for temporary accommodation in Ireland, as it was impossible to rent anything while living in Spain due to the housing crisis and the fact that we had a Spanish phone number, and for some reason, maybe because of the high demand, no landlord was willing to call us back, so we finally ended up renting for 3 weeks an apartment in the centre of Dublin, as my position was fully remote within Ireland and we wanted to be close to the public transport, and it’s always easy to move around if you’re in a city.

The last few days, apart from doing the usual preparations, we decided to spend as much time as possible with family and friends, and in no time it was the night prior to our flight to Ireland.

The first few weeks in Ireland

As soon as we reached the Dublin airport, my wife and I had one and only one obsession: to find long-term accommodation in Dublin. We did our investigation online, and it was really hard to find any place to rent in the city, and we only had the booking for 3 weeks, so the clock was ticking.

We got some prepaid Irish phone numbers, and we started applying to every accommodation that was published on several online portals. We had notifications active, and every time we got one, we stopped doing whatever we were doing at the moment to send an application.

The only two requisites that were non-negotiable for us were that it needed to have two rooms (one to sleep in and another so I could work), and we didn’t want to share the place with other people. It was one of the most stressful moments of my life.

During these few days, we also tried to open a bank account in Ireland because it’s always easy to do some paperwork if you have a local bank account, and also because my new employer asked me for a bank account with an Irish IBAN. However, for some reason, it was impossible to open a bank account without permanent residency. There was some workaround that we tried with an online bank account (nowadays Revolut offers an Irish IBAN), but in the end it didn’t work for us, and my employer offered me to use Wise instead of a conventional bank.

After a week in Dublin, we had the opportunity to visit a few apartments, but we were not selected by the landlords, or it was not what we were expecting from the place. It’s impressive what some state agents can do with nice lighting and Photoshop.

We were pretty anxious by then, but some evening we received a call from the state agent that managed the first house that we went to see in Dublin (a nice and small 2-bed terrace house from the 70’s) saying that the landlady was offering to rent the house to us. It was quite expensive, in the upper bracket of our budget, but we decided to accept it as it had been hell to find anything that fit our expectations and was in living conditions.

A week later, still living in the temporary apartment, I started my new position as a senior frontend developer, and two weeks later we moved to our new home.

Working as a developer in a different country

As I mentioned before, I worked fully remotely in my new position. This was not new for me because, even before the pandemic, I used to work hybrid, going to the office only 2 days per week, and after the pandemic, I had plenty of time to get used to working from home most of the time.

One of the biggest differences that I discovered about my colleagues is that everyone is really polite with each other. It's not that in Spain people are rude or anything like that, but Spanish as a language is more direct, and it’s common to use commanding sentences. In Ireland, however, people are more polite and use more indirect ways of asking for things. That’s something that I eventually got used to, but in the beginning, it took me some time to start talking this way.

Another difference that I noticed was that people respect the working hours, and except on exceptional occasions, I was never asked to work overtime. On the contrary, in Spain, it is pretty common to work as a developer for nine or even ten hours per day, depending on the company. And no, in case you’re asking yourself about it, nobody pays you for the overtime hours.

Other than that, the kind of job and the project that I worked on were pretty similar to my previous experiences. The main difference was that in Ireland we had less stress in general and the timing was more realistic, but that could perfectly be because I got lucky with the companies that I’ve been working for so far.

Being in emergency tax and getting the PPSN

Something to consider when moving to Ireland is that to be able to pay taxes, you need to have a PPS number. And when you first arrive in the country, you obviously don’t have one. You cannot require one without employment and permanent residency in Ireland.

If you don’t have this number, you will be subject to the emergency tax. This basically means they are going to tax all your salary at 40%, which is the maximum rate. There is no way to prevent this from happening, so in the first few months that it takes to request the PPS number, you will only get a little more than half of your salary. After that, you can request to get your money back, and I must say that the revenue is really fast, giving you back what is yours.

Weather

Some people imagine Ireland as this grey country, always rainy and windy. And they are not wrong; there is some truth in that. It rains a lot, but I must say that we don’t experience heavy rain too frequently; most of the time, it is very light rain. To be honest, I really like the humid days when there is a very subtle rain outside and I’m working, warm, and cosy at home. The summer is mild, and the days are longer and way sunnier, which I really appreciate compared to Spain, where the summer is like living in hell at 35 degrees Celsius.

However, during winter we don’t have much sunlight, and I take vitamin D supplements as I used to be a little bit low on morale, which never happened to me before living in Spain.

In general, I like the weather here, but it’s a very personal thing, and I know that there are a lot of people, especially those living in warm countries, who find it really difficult to live in Ireland because of the weather.

Final Thoughts

Almost two years later, we are still living in the same 2-bed terrace house. I’m working for a different employer for almost double my initial salary in Ireland, and we are about to buy a house in the country. So much has happened since then, but everything started with the desire to improve in life and not be complacent in our comfort zone. I have not regretted it even once.

Cómo es un día en la vida de un programador

Adrian Guillen — Sun, 14 Nov 2021 13:14:48 +0000

Cuando alguien empieza a aprender programación y busca información sobre cómo es la vida de un programador, es fácil encontrar mucha información contradictoria y en algunos casos incluso perjudicial. Uno de los temas más controvertidos es cómo invierte su tiempo un programador y por eso mismo estoy escribiendo este artículo, para tratar de aportar un poco de luz y aclarar, según mi experiencia, como es un día en la vida de un programador.

En primer lugar me gustaría compartir un poco de mi trayectoria profesional para que tengas contexto sobre quien soy y cual es mi experiencia. En el momento de escribir este artículo (Noviembre de 2021) llevo trabajando como desarrollador frontend en España unos 5 años. Trabajé 1 año en una consultora mediana, 3 años en una consultora pequeña que hacía grandes proyectos para IBM entre otras empresas, y actualmente trabajo en Atrápalo, que es una agencia de viajes que tiene presencia en España y parte de latinoamérica. Como puedes ver tengo experiencia en consultoría pero también he trabajado en empresas de producto y a lo largo de los años he trabajado en todo tipo de proyectos, equipos de trabajo, y aplicaciones.

Cómo invierten su tiempo los programadores

En la comunidad IT es muy común escuchar sobre desarrolladores que dicen que invierten cientos de horas a la semana programando, trabajando en side projects, contribuyendo en software libre, bebiendo café y escribiendo miles de horas de código. ¿Pero en qué invierte su tiempo un desarrollador promedio? Fíjate que he dicho "desarrollador promedio" porque en muchas ocasiones las personas que comparten contenido no muestran la realidad de su vida, sino simplemente el trozo que les interesa compartir y lo que muestran no suele ser lo que un desarrollador promedio suele hacer.

Hay quien piensa que un programador es una máquina de transformar ideas (y café) en código, pero los programadores hacen bastantes más cosas aparte de escribir código. Por ejemplo los desarrolladores que trabajan en empresas medianas o grandes acostumbran a utilizar metodologías ágiles, esto significa que la aplicación o producto que están desarrollando se desarrolla en diferentes fases en vez de entregar el proyecto de golpe al final del desarrollo. En este tipo de entornos los desarrolladores acostumbran a hacer reuniones diarias para hablar sobre lo que hicieron el día anterior, que harán durante el día de hoy y si se encontraron con algún bloqueo al realizar su tarea. En este tipo de entornos es muy común hacer reuniones de demostración con el cliente de forma periódica para que pueda ir viendo la evolución del proyecto.
Además tanto si trabajan en un entorno ágil como si no lo hacen, los desarrolladores invierten tiempo en reuniones todos los días. Los motivos más comunes suelen ser priorizar tareas dentro del equipo, decidir cómo se afrontará una tarea especialmente complicada, compartir conocimiento y ayudar a otros miembros de equipo que tienen algún problema.

Por otro lado, cada día cuando un programador empieza a trabajar, una de las primeras cosas que hace es recordar en que estuvo trabajando el día anterior. Esto puede parecer una tontería, pero se invierte bastante tiempo del día en recuperar el contexto de lo que se estaba haciendo, especialmente si la tarea era muy complicada, o es la primera vez que el programador se enfrenta a ella. Tal y como hemos visto en el párrafo anterior, los desarrolladores acostumbran a tener varias reuniones cada día, lo que supone que después de cada reunión también se tiene que invertir algo de tiempo en recordar que se estaba haciendo antes de poder empezar a programar. Por lo tanto, si un programador tiene muchas reuniones en un mismo día, será muy difícil que sea productivo porque deberá invertir tiempo constantemente en recuperar el hilo de lo que estaba haciendo anteriormente.

Cuando un desarrollador empieza a programar lo primero que hace no es escribir código, lo primero que se suele hacer es analizar el problema que se está intentando resolver para encontrar la mejor solución posible. Si un programador empieza a escribir código sin analizar primero el problema, lo más probable es que el código que genere sea de poca calidad, así que la fase de análisis es muy importante. En este punto también es muy común preguntar a compañeros más experimentados para buscar y debatir cual es la mejor solución.

Los desarrolladores se enfrentan cada día a nuevos retos, así que es muy común que durante su jornada sea necesario que busquen información constantemente. La mayoría de desarrolladores invierten tiempo buscando en google, aprendiendo de tutoriales, foros, o en la propia documentación. Un desarrollador no necesita saberlo todo, simplemente necesita saber donde encontrar la información necesaria en cada caso.

Finalmente, cuando un desarrollador no está participando en reuniones, ya sabe como continuar con la tarea que estaba realizando, y ya tiene claro cómo va a resolver el problema, sólo entonces, se pone a escribir código. Así que como puedes ver, escribir líneas de código no es la primera cosa que un programador hace por la mañana cuando empieza a trabajar.

Cuánto tiempo invierte un programador escribiendo código

Es difícil medir cuánto tiempo pasa un desarrollador programando, pero si hablamos de una jornada laboral de 8 horas, calculo que de promedio se pasan unas 3 - 5 horas máximo escribiendo código. Evidentemente esto es una aproximación basada en mi experiencia personal, ya que es imposible calcular con exactitud el tiempo promedio que un programador pasa escribiendo código, además depende mucho del sector, la experiencia del programador y la empresa en la que trabaje.
Es común pensar que contra más experiencia tiene un desarrollador más tiempo pasa programando, pero esto no suele ser cierto. De hecho, contra más experimentado y hábil sea el programador menos líneas de código escribirá porque invertirá más tiempo ayudando a otros miembros del equipo, asistiendo a reuniones con clientes o analizando problemas de gran complejidad.

Espero que este artículo ayude a romper algunos mitos sobre cómo los programadores invertimos nuestro tiempo. ¿Qué opinas al respecto? ¿Pasas más de 3 - 5 horas programando?

Cómo estructurar un proyecto de React

Adrian Guillen — Sun, 07 Nov 2021 15:51:45 +0000

En los anteriores artículos de esta serie de fundamentos de React expliqué las tres mejores formas de crear un proyecto de React y también analicé minuciosamente cada uno de los archivos y carpetas en un proyecto de React generado con Create React App.

Ahora que ya sabemos cómo crear un proyecto y qué elementos contiene, el siguiente paso es empezar a programar nuestra propia app. En este artículo se va a explicar qué estrategias seguir paso a paso para empezar a programar una aplicación sencilla. También dejaré a vuestra disposición el link a un repositorio de github que he creado para la ocasión, donde se puede ver el resultado del proyecto que he usado como referencia en este artículo.

Antes de entrar en detalle sobre la estructura de proyecto que propongo, me gustaría aclarar que me he basado en una estructura simplificada de Domain Driven Design, que sea fácilmente escalable y que permita adaptarse con algunos ajustes a casi cualquier proyecto, sin embargo con el objetivo de simplificar el contenido de este post, no explico en detalle qué es el DDD ni en qué conceptos se basa este tipo de arquitectura. En futuros artículos pretendo cubrir en profundidad sobre DDD entre otros temas.

En este post vamos a trabajar principalmente dentro de la carpeta src, ya que es donde reside el código fuente de nuestra aplicación. En este artículo no se va a explicar qué hace cada uno de los archivos y directorios que existen inicialmente puesto que eso ya se cubrió en el artículo anterior.

Lo primero que me gusta hacer cuando creo un nuevo proyecto de React es crear una estructura básica de carpetas que me permita tener el código organizado para que sea fácil encontrar lo que estoy buscando en cada momento una vez el proyecto va creciendo.

Si no se genera una buena estructura desde un principio, es posible que con el paso del tiempo el proyecto vaya creciendo en tamaño, creándose componentes nuevos, archivos con lógica de negocio y utilidades y poco a poco, de forma casi imperceptible, será más difícil añadir mejoras y corregir bugs, porque el proyecto que inicialmente eran unos pocos componentes, se ha convertido en un monstruo con cientos archivos en los que nunca se encuentra a la primera lo que se busca.

Para evitar que esto ocurra, me gusta hacer una estructura inicial de carpetas muy básica que me permita ir ampliando conforme el proyecto se hace más grande y que se adapte tanto a proyectos pequeños, medianos o (con un poco de trabajo) a proyectos grandes.

Estructura de carpetas básica

La estructura básica de proyecto que propongo es la siguiente:

En primer lugar, he creado la carpeta components que será la encargada de contener los componentes React de nuestra aplicación. En este caso, como el proyecto parte de cero, tan solo tenemos el componente App, pero en el futuro, conforme vayamos ampliando el proyecto y creando más componentes, este será el directorio en el que irán contenidos.

El segundo directorio que he creado es el domain que es el directorio encargado de contener la lógica de negocio de la aplicación. La lógica de negocio es toda aquella que es única del funcionamiento concreto de nuestro proyecto, y que no depende de ningún framework ni librería. Por ejemplo, si estamos creando una aplicación de calculadora, la función "suma", "resta"... forman parte de la lógica de negocio de nuestra aplicación.

Es posible que te estés preguntando si tiene sentido crear este directorio desde un punto tan temprano del desarrollo, si el proyecto ahora mismo no es más que apenas un par de componentes sin lógica ninguna. La respuesta a esta pregunta es un rotundo "sí, es necesario", el motivo es bien simple, si no creas este directorio desde el principio, es fácil ir añadiendo esta lógica dentro de los componentes, lo que provocará que la lógica dependa de la librería de componentes que estés usando, en este caso React. Por lo tanto, la lógica de negocio será más difícil de testear y de reutilizar. Si no tienes claro qué es la lógica de negocio, y porque es importante que no esté relacionada con React, no te preocupes, escribiré futuros artículos hablando sobre el tema.

Por último he creado el directorio pages, que será el encargado de contener las diferentes páginas de nuestra aplicación en caso de que nuestra app tenga routing. Si nuestra aplicación no tiene routing, es posible que no necesitemos este directorio, en ese caso es totalmente válido dejar el index.css y el index.js en la raíz del directorio src.

Como nuestro proyecto no va a tener rutas no vamos a utilizar el directorio pages, sin embargo es recomendable que en caso de tener una aplicación con routing lo utilices.

Refinando la estructura de carpetas

Esta estructura de carpetas que se ha propuesto es muy básica y se puede mejorar un poco más. Para ello lo primero que recomiendo es crear una carpeta por cada componente, de forma que contenga todos los archivos de javascript, css y test de ese componente. Por ejemplo he creado el directorio App que contiene lo siguiente:

De la misma forma, dentro de pages es recomendable crear un directorio por cada página de nuestra aplicación, en los que se incluirán los archivos de javascript, css y test.

El directorio domain es ligeramente diferente, porque al contener archivos con lógica de negocio, no tiene sentido crear una carpeta por cada archivo, puesto que cada archivo ya contendrá las funciones, clases y métodos relacionados con una funcionalidad o grupo de funcionalidades. Por lo tanto la clasificación de archivos y carpetas debe estar relacionado a los diferentes elementos de dominio. Un elemento de dominio es una entidad que puede ser del mundo real o del dominio de la aplicación.

Por ejemplo, si tenemos una aplicación de gestión de usuarios, un elemento de dominio es "usuario", y si en esta aplicación se gestionan roles de usuario, otro elemento de dominio podría ser "roles de usuario". En este caso hipotético crearíamos la carpeta usuario dentro del domain y dentro de esta carpeta crearíamos los diferentes archivos de lógica relacionados con el usuario. De la misma forma crearíamos la carpeta roles-de-usuario y dentro de esta escribiríamos los archivos relacionados con los roles.

Si pese a estos ejemplos no ves claro que son los elementos de dominio en futuros artículos explicaré en profundidad qué son y cómo utilizarlos en tus proyectos.

Siguientes pasos a seguir

La estructura de proyecto que he propuesto es válida para un proyecto muy sencillo, y a la que empieces a crear varios componentes, hacer llamadas al backend, etc deberás crear nuevos archivos y carpetas. Una buena forma de continuar evolucionando tu proyecto es generar los directorios application e infrastructure.

En el directorio application puedes incluir los casos de uso de tu aplicación, por ejemplo llamadas api rest, las actions para actualizar tus reducers, y los selectores que te permiten escuchar los cambios en el estado de tu aplicación.

En el directorio infrastructure puedes incluir clases o funciones que hagan abstracciones de librerías de fetching, de forma que tu proyecto no esté acoplado a librerías de terceros, etc

Si no tienes claro qué es el acoplamiento, ni porqué es necesario trabajar con abstracciones en futuros artículos cubriré con detenimiento estos conceptos.

Otros directorios que se pueden añadir según se vayan necesitando son los directorios static, theme y config.

El directorio static es un directorio opcional, que no está en todos los proyectos ya que hay proyectos en los que no es necesario, pero los proyectos que lo utilizan suele incluir todos los archivos estáticos que necesitan estar dentro del directorio src pero que no contienen código fuente, como por ejemplo imágenes o fuentes. En el caso de nuestra aplicación podríamos crear el directorio static y poner dentro el archivo logo.svg.

En el directorio config es un directorio opcional, en el que incluiremos todos los archivos de configuración de librerías. En nuestra aplicación incluiríamos los archivos reportWebVitals.sj y setupTest.js.

Por último hay aplicaciones grandes que contienen muchos estilos css, y algunos de estos estilos son generales y compartidos a lo largo de toda la aplicación. Para incluir estos archivos es común crear el directorio theme, en el que se incluyen archivos con variables de css, la configuración de las fuentes, variables de media queries etc.

Por último me gustaría animarte a que cometas errores, ya que una de las mejores formas de aprender qué estructura de proyecto funciona mejor para ti es equivocarte y aprender de tus errores.

Foto de la cabecera por Antonio Batinić from Pexels

Qué hay en un proyecto de React creado con Create React App

Adrian Guillen — Mon, 01 Nov 2021 16:11:29 +0000

En mi anterior articulo expliqué las diferentes formas que existen para crear un proyecto de React, siendo Create React App la mejor opción casi para cualquier tipo de aplicación web.

En este articulo se creará un nuevo proyecto con Create React App y se explicará en profundidad, archivo por archivo, que es lo que genera por nosotros esta increíble herramienta.

En primer lugar, necesitamos tener instalado Node y npm en nuestra maquina y abrir un terminal de comandos. Si no tienes Node y npm instalados te recomiendo que sigas los pasos desde la web de Node y continúes cuando lo tengas correctamente instalado.

Para crear un proyecto de React con Create React App tan solo es necesario en la terminal navegar al directorio donde queremos crear nuestro proyecto y escribir uno a uno los siguientes comandos:

npx create-react-app my-app
cd my-app 
npm start

El primer comando es el que crea todo el proyecto, deberías cambiar my-app por el nombre de tu proyecto. Este comando puede tardar unos cuantos minutos en terminar, esto es completamente normal ya que necesita crear todos los archivos y carpetas, así como instalar todas las dependencias iniciales para que el proyecto pueda funcionar correctamente.

El segundo comando sirve para acceder desde la terminal al directorio del proyecto que ha creado Create React App.

El ultimo comando sirve para arrancar el proyecto con un servidor local al que puedes acceder desde cualquier navegador, escribiendo en la ruta la dirección localhost:3000. Una vez tienes arrancado el proyecto con npm start, cualquier cambio que realices dentro del proyecto se verá reflejado en el navegador, prácticamente en tiempo real.

A continuación, para poder trabajar en el proyecto es necesario que utilices algún editor de código, o IDE, como por ejemplo Visual Studio Code, que es una herramienta Open Source, gratuita, de las más utilizada dentro del sector profesional. Si te interesa como configurar y personalizar Visual Studio Code, en futuros artículos explicaré como configurarlo y cuales son las mejores extensiones para desarrolladores React.

Para la ocasión, he creado un proyecto llamado article-cra y este es el resultado de lo que ha generado Create React App:

A continuación voy a explicar para que sirven cada uno de los archivos y carpetas que ha generado por nosotros Create React App.

Directorio node_modules

El primer directorio que vemos en el proyecto es la carpeta node_modules. Esta carpeta incluye todas las dependencias de nuestro proyecto, es decir, que se encuentran todas las librerías, utilidades, frameworks, etc que utiliza nuestro proyecto. Por ejemplo, la librería de React es una dependencia de nuestra app, y por lo tanto, el código fuente de React se encuentra dentro de la carpeta node_modules.

Directorio public

El siguiente directorio que se puede apreciar es el public. Dentro de este directorio se encuentran todos los archivos estáticos, es decir, que no necesitan ser compilados, ni forman parte del código fuente de nuestra aplicación.

En este directorio se encuentra el favicon.ico, que es el archivo de imagen que permite que aparezca el logo de React en la pestaña del navegador. Si cambiamos este icono por un icono diferente y refrescamos el navegador, deberíamos de ver el nuevo icono en el browser.

El index.html es el archivo de html principal de nuestro proyecto, y será el archivo que servirá nuestro servidor web cuando publiquemos en un servidor nuestra aplicación.
Como mención especial, en este archivo se encuentra el div que utiliza react para inyectar el código de toda la aplicación react. Esto lo explicaré mejor en post sucesivos.

Los archivos logo192.png y logo512.png son archivos de imagen que sirven por si queremos convertir nuestra aplicación en una Progressive Web App. Las aplicaciones PWA se pueden instalar en dispositivos Android, IOS, Windows y Mac OS, permitiendo utilizar la aplicación como si la tuviésemos instalada en nuestro dispositivo. La imagen que aparecería en nuestro listado de aplicaciones es uno de estos dos logos. Hay 2 imágenes porque dependiendo del tamaño y resolución de la pantalla del dispositivo utilizará una imagen u otra.

El siguiente archivo es el manifest.json, que es un archivo que aporta información al navegador sobre el nombre de la aplicación, los iconos que debe utilizar en función del tamaño de pantalla y también el color principal y secundario de la app, etc.

Por último tenemos el archivo robots.txt que sirve para que una vez que la aplicación está desplegada en un servidor, los buscadores como Google puedan indexar la aplicación para que aparezca en los resultados de la búsqueda. Sin este archivo nunca aparecería tu aplicación en Google a no ser que escribas toda su URL.

Archivos en la raíz del proyecto

A continuación voy a explicar los archivos que están en la raíz del proyecto.

La mayoría de las aplicaciones profesionales se suben a algún repositorio de git, como por ejemplo Github o Gitlab. Sin embargo hay archivos que no es aconsejable subir a los repositorios porque contienen tokens de seguridad, archivos o directorios autogenerados, como el node_modules o la carpeta build o dist donde se almacena el código del proyecto para producción etc. La forma de incluir excepciones sobre los archivos y carpetas que se van a subir al repositorio de git se realizan en el archivo .gitignore. Es este archivo se pueden incluir carpetas enteras, extensiones de archivos, etc. Todo lo que se incluya en este directorio será ignorado al realizar una subida al repositorio.

El archivo package.json es un archivo muy importante en todos los proyectos hechos en Javascript, ya que define el nombre del proyecto, el numero de versión, define las dependencias y dependencias de desarrollo, y también los scripts disponibles. Por ejemplo el script para arrancar el proyecto npm start, está definido en este archivo, así como también el script para hacer el build de producción.

El archivo package-lock.json sirve para guardar un registro de la ultima versión de todas las dependencias de tu proyecto, de forma que la próxima vez que instales dependencias en un proyecto se utilicen las mismas que anteriormente te funcionaron. Esto evita que la aplicación deje de funcionar porque una dependencia se ha actualizado y entra en conflicto en la nueva versión con alguna otra dependencia de tu proyecto. Si no existiese este archivo no tendríamos forma de instalar siempre las mismas versiones de nuestras dependencias en un proyecto y se producirían muchos conflictos entre dependencias.

Por último tenemos el archivo README.md que sirve para documentar tu proyecto, informar a posibles usuarios como arrancar el proyecto, hacer build de producción y en definitiva exponer cualquier información relevante sobre el proyecto. El archivo README.md es el archivo que se muestra por defecto cuando accedes a un repositorio de git, y también es el archivo que se muestra cuando se publica una librería a npm o cualquier gestor de paquetes de npm personalizado.

Directorio src

El directorio src es donde se encuentra el código fuente de la aplicación, y por tanto es directorio donde se pasa la mayor parte del tiempo programando.
Cuando se crea un proyecto con Create React App se genera un proyecto de muestra con unos archivos que en la mayoría de los casos se borrarán para empezar a construir el proyecto con los archivos y carpetas que necesites. Sin embargo para poder borrar todo su contenido es importante conocer que hace cada archivo para poder sustituirlo por el que te interese en cada caso.
A continuación voy a explicarte uno a uno para que sirven los archivos que hay dentro de la carpeta src.

El primer archivo es el App.css, dentro de este archivo se encuentran los estilos CSS del componente principal App.js . En un proyecto real, lo más recomendable es tener múltiples archivos CSS, posiblemente uno por cada componente.

El archivo App.js es uno de los archivos más importantes de la aplicación, puesto que es el primer componente que cargará React y por lo tanto es el componente que contiene toda tu aplicación de react. Esto implica que cuando vayas creando nuevos componentes en tus proyectos, todos acabaran dentro del componente App.js de una forma u otra.

En todas las aplicaciones profesionales se escriben (o deberían escribir ) test automáticos para validar que la aplicación está libre de errores (bugs) y estar seguro y confiado que no vas a subir código con errores en un entorno de producción. Por este motivo Create React App genera el archivo App.test.js, que es un archivo donde se genera un test de muestra para la aplicación. Al igual que con los archivos CSS, en un proyecto real, habrá más de un archivo de test, posiblemente uno por cada componente.

El archivo index.css recoge los estilos generales de la aplicación. En el App.css solo se encuentran los estilos del componente App.js, pero si se quisieran tener estilos compartidos a lo largo de toda la aplicación, una manera de compartirlos seria mediante el index.css, ya que los estilos que se incluyan aquí dentro se compartirán en toda la aplicación.

El archivo index.js es otro archivo de vital importancia, puesto que es el punto de entrada a la aplicación React, es decir que es el primer archivo que se va a cargar, y a partir de este, se cargarán el resto de los archivos de la carpeta src. Dentro del index.js se carga el componente App.js y se le dice a React en que elemento del html de la aplicación lo tiene que pintar. Este es por lo tanto un archivo que siempre tiene que estar en todas nuestras aplicaciones de react. En futuros artículos explicaré en más profundidad como funciona este archivo.

El archivo logo.svg se utiliza dentro del App.js para pintar el logo de react. Una vez modifiques o elimines el componente App.js puedes eliminar sin miedo este archivo porque no tiene ninguna otra función.

El archivo reportWebVitals.js se llama desde el index.js y sirve para medir el performance de la aplicación. No es imprescindible, pero es recomendable tenerlo.

Por ultimo el archivo setupTest.js sirve para importar la librería de testing por defecto de Javascript.

Como se ha visto en este articulo, Create React App genera muchos archivos y carpetas por nosotros, y nos da un proyecto listo para que podamos empezar a construir nuestra propia aplicación de React. En el próximo articulo explicaré como a partir de un proyecto hecho con Create React App podemos empezar a construir nuestro proyecto de React.

¿Os ha quedado alguna duda respecto a algún archivo? ¿Tenéis alguna duda o sugerencia?
Si es así dejadme un comentario abajo y lo responderé.

Cómo crear tu primer proyecto de React

Adrian Guillen — Mon, 25 Oct 2021 06:31:53 +0000

Una de las primeras dudas que surgen cuando empezamos a trabajar con una librería o framework para el frontend es sin duda cómo empezar un proyecto nuevo.

Lo primero que debemos tener en cuenta es que para poder trabajar con React o cualquier otro framework como Angular, Vue, Svelte, etc primero necesitaremos tener nuestro equipo configurado con Node y npm. Una vez tenemos el entorno listo, ahora sí, ya estamos listos para empezar.

Para crear un nuevo proyecto de React, tenemos 3 alternativas:

1 - Crear un proyecto desde 0.
2 – Utilizar un proyecto existente como plantilla.
3- Utilizar alguna herramienta que genere el proyecto por ti.

1 Crear un proyecto desde 0

La primera opción es quizá la más básica y costosa, ya que si creas un proyecto manualmente desde cero, deberás crear todos los directorios y archivos que necesites, pero también deberás configurar las diferentes herramientas necesarias para compilar el código, realizar test, hacer linting del código y generar el código para producción entre otras cosas.
No te preocupes si alguno de los términos que he utilizado más arriba no te suenan, tengo pensado explicar todos estos conceptos en post sucesivos.

En resumen, crear un proyecto desde cero, te permite personalizar mejor que incluyes y que no incluyes en el proyecto, pero requiere mucho trabajo y conocimientos previos. Yo recomendaría esta primera opción para gente con experiencia y/o que quiera aprender a configurar desde cero un proyecto.

2 Utilizar un proyecto existente como plantilla

La segunda opción es quizá una solución más sencilla que la anterior, ya que en Github existen repositorios de plantillas que explican paso a paso como utilizar la plantilla. Lo más habitual suele ser que debas clonar el repositorio, para lo cual solo necesitas tener una cuenta gratuita de Github. Una vez clonado el repositorio deberás seguir los pasos que aparezcan en el Readme y en apenas 5 minutos ya tendrás un proyecto de React arrancado y funcionando.

Una de las plantillas más utilizadas con este propósito es React-boilerplate ,ya que es una plantilla de React para aplicaciones de uso general. Si buscas una plantilla más especifica existen otros templates de proyectos React para casi cualquier tipo de aplicación.

En conclusión, es una opción mucho más sencilla de crear un proyecto React, ya que en apenas 5 minutos se tiene un proyecto perfectamente configurado y funcionando sobre el que empezar a trabajar, aunque no tienes tanto control sobre el tipo de librerías y herramientas incorpora la plantilla.

3 Utilizar alguna herramienta que genere el proyecto por ti

Las dos opciones mencionadas están muy bien, pero ¿no seria mejor si pudieses utilizar alguna herramienta a la que le digas algo del estilo “genérame un proyecto React, perfectamente configurado, y que tenga X e Y configuraciones” y automáticamente haga todo el trabajo por ti?

Pues exactamente eso es Create React App , es un cliente (CLI a partir de ahora), que te permite crear un proyecto de React customizado, pudiendo elegir entre diferentes opciones de configuración para que elijas la que se adapte mejor al proyecto que deseas empezar. Esta opción es sin duda la favorita de la mayor parte de la comunidad, porque genera de forma sencilla el proyecto, y tiene detrás una gran comunidad que actualiza el CLI constantemente por lo que siempre que quieras crear un proyecto nuevo de React, estará actualizado a la ultima versión de la librería.

¿Y como se utiliza Create React App? Pues es muy sencillo, tan solo necesitas tener Node y npm instalados en tu maquina, abrir una terminal y lanzar los siguientes comandos, uno a uno, en el directorio donde quieres crear el proyecto:

npx create-react-app my-app
cd my-app
npm start

El primer comando crea el proyecto de React con el nombre “my-app” (deberías cambiar el “my-app” por el nombre de tu proyecto), el segundo comando sirve para cambiar del directorio actual al directorio del proyecto, y por ultimo, el tercer comando arranca el proyecto de React para que puedas empezar a trabajar con él y ver los resultados en tu navegador.

Hay que tener en cuenta que los 3 comandos anteriores están pensados para dispositivos MAC OS o Linux, para Windows el segundo comando cambia un poco:

npx create-react-app my-app
dir my-app
npm start

En conclusión, Create React App es sin duda la mejor herramienta para crear tu primer proyecto de React por la simplicidad que tiene y por la posibilidad de customizar la configuración de tu proyecto.

En próximos artículos explicaré en profundidad la estructura de archivos y carpetas que genera Create React App, y como empezar a desarrollar a partir de ellas.

Por último preguntar ¿que utilizáis para crear nuevos proyectos de React? ¿Utilizáis alguna herramienta que no haya mencionado? Dejadme vuestras opiniones en los comentarios.