Forem: José Clovis Ramírez de la Rosa

Does your team use React Hooks? Mine doesn't

José Clovis Ramírez de la Rosa — Thu, 06 Jun 2019 11:24:41 +0000

So there it goes. React v16.8 introduced hooks, a way to use state and other React features without writing classes. Folks who started a new project or managed to migrate their existing project already have access to use hooks!

We've recently managed to migrate to React 16.8, but still, haven't made it to Hooks yet.

I didn't think it would be a big deal

Some weeks after the migration, I had to implement a feature that shows a modal to the users and allows them to withdraw from all the jobs that they applied to. I had already used hooks in a project before and was anxious to start creating some awesome hooks! Using this article, I made a custom useCurrentUser hook which looks neat, and when I needed state, I got my hands on useState instead of converting the component to a class.

When I first made the PR, to my surprise, none of my Senior coworkers understood what I was doing!

The offender

Due to the way the project was made, we do data fetching inside the component. How do we do it with Hooks? Checking on the docs, I used the following workaround:

  useEffect(() => {
    let ignore = false;

    getSubscriptions({userId}).then(({isSeeking, sendNewsTips}) => {
      if (ignore) {
        return;
      }
      setIsSeeking(isSeeking);
      setNewsTips(sendNewsTips);
      setOriginalIsSeeking(sendNewsTips);
    });

    return () => {
      ignore = true;
    };
  }, [userId]);

Overall they didn't like the idea, but this piece of code threw them off. The code just seemed too cryptical to anyone reading it, particularly the ignore variable and how it is being used. Seems like using a class would make it look a lot cleaner.

The reasons against Hooks

I took notes of their main concerns and made the following list:

Introducing hooks is a big change to the project that requires team discussion to check if we should start writing all the new components using hooks.
Hooks are still new, incomplete, and encourages code like the above which is too cryptical in comparison with the class-based way to do it.
Hooks might be the future, but they're not the present. There're a lot of components written using classes and switching between them makes it hard to be productive (NOTE: they don't agree with this tweet).
Sometimes it might be faster to deliver the feature using a class-based approach rather than writing hooks.

Thoughts?

It makes sense to me that if the team is not onboard with hooks yet, it might be better to hold it off. Eventually, hopefully, it might be reconsidered later on.

Do you/your team use Hooks? Why or Why not?

YOU and YOUR TEAM should start taking technical decisions!

José Clovis Ramírez de la Rosa — Sun, 02 Jun 2019 02:41:19 +0000

Photo by Lubo Minar on Unsplash

Uh, oh, that dead code again.

Much of the time we let the managers know that there's a lot of technical debt in the code: untested code, leaky abstractions, sometimes even variables named a, b and c. We need to set up a CI and a linter. But when?

In this post, you'll see why you should care about taking technical decisions, and why you need to start participating, proposing, and/or proactively make them along with your team.

I always thought that these depended on management!

Software is meant to help people accomplish their goal. Also turns out, Managers are the ones that know what needs to be done from a business perspective to accomplish the goals. Therefore, it makes sense that they should decide when it would be a good time to tackle the technical debt?

When I initially reached this conclusion, I abandoned refactor. I abandoned tests and radicalized my point of view about business having the final say on every technical decision. Blogs like these became my mantra: Your code may be elegant, but mine f***ing works.

Turns out, you also know what needs to be done

A year ago, I stumbled across this passage from Clean Architecture, by Uncle Bob:

Fight for the Architecture.

“Fulfilling this responsibility means wading into a fight—or perhaps a better word is “struggle.” Frankly, that’s always the way these things are done. The development team has to struggle for what they believe to be best for the company, and so do the management team, and the marketing team, and the sales team, and the operations team. It’s always a struggle.”

The passage opened a crack on my beliefs. Why should we fight with the people that know what needs to be done? Shouldn't the managers be the one factoring out all the constraints, including technical debt? Turns out most of the times these constraints are overlooked - indeed, only the people experiencing the problem knows that the problem exists.

Most of the bigger goals depends on smaller goals to be achieved. It's the work of the doers - people like you, who make things happen. Who else knows best what you need to do in order to accomplish your tasks?

You are responsible for the success of the product -- and your work

When unexpected things happen - be it breaking a fragile piece of code, or failing to meet a previously agreed deadline - who's to be blamed? Turns out you're the one responsible for estimating your tasks and working on it within the constraints. Unexpected things often occur of a lack of quality in the work that you're expected to flawlessly do.

If you estimate a task to be completed in 3 hours, but it ends up taking 8 hours - because by doing it you broke something else and had to spent 5 hours tracing and fixing the issues - YOU will be responsible of it!

To ensure quality in your work - that is, to meet the requirements within the given constraints while avoiding unexpected issues, you need to impose certain quality requirements to the work that you do. Does it require tests? Does it require to pass a linter? These tasks don't necessarily deliver a feature to your customers, but helps you to do so!

Wrapping up

You, who work on the code on a daily basis, know best what kind of problems you're dealing with. To solve these problems, you must take actions. If you don't and instead rely on your product owner or another authoritative person to, they might not see the problem until it becomes too late. When things start to crumble and you're unable to meet your estimations - the fault with be on you.

Because you want to do the best out of your work and hold it to high-quality standards, you need to proactively take actions to combat the technical debt. Doing this is part of your work.

Fix like no one's watching.

References

Apart from the linked content, this article helped me a lot to articulate my ideas around the topic: The programmer as decision maker.

I got my first returned ticket on a project. TWICE.

José Clovis Ramírez de la Rosa — Tue, 16 Apr 2019 12:45:47 +0000

It's the same mistake from all the times. A seemly easy ticket is assigned to you. You quickly go through the code and recognize that one line that's causing the issue...

The Scenario

I was assigned a task: "The company's URL is not working properly". I first managed to reproduce the issue and saw that the current URL was being appended with some kind-of dot-notation inside square brackets.

This code caught my attention:

<div class="company-details">
    {% if company.logo %}
          <img src="{{ company.logo.url }}">
      {% endif %}
  <h3>Company Details</h3>
  <p>{{ company.description }}</p>
  <ul class="social">

    {% if company.homepage %}
      <!-- NOTICE THE NEXT LINE -->
      <li><a href="[[ company.homepage.url ]]" class="icon" target="_blank"></a></li>
    {% endif %}

    {% for link in company.links.all %}
        {% if link.share_platform %}
            <li><a href="{{ link.url }}" class="icon" target="_blank">
                <img src="{% static images/app/company/background.jpg %}">
            </a></li>
        {% endif %}
    {% endfor %}
  </ul>
</div>

I quickly noticed the square brackets that were out of context here. I quickly changed the brackets, commit and pushed the code to QA.

QA returned the ticket.

Fixing audacity with more audacity

When I saw the evidence, it seemed like the square brackets were still there. I checked GitHub to see if I pushed the right code, then made a search for all the places where we were using the company's homepage.

Turns out there was a second template where the same error was made. "Okay, this is definitively the issue!" - I said to myself, and yet once again - quickly fixed, committed, and pushed yet more untested code. I was completely confident that this was the issue.

Nevermind me. QA returned the ticket, again.

Doing things right

Turns out this time the company's URL was sending the user back to... the same page. Seeing the ticket being returned for the second time sent me back to the Earth. This evidently wasn't something I could do with eyes closed, so I decided that I would do it the right way this time.

After reviewing the case I found out that company.homepage was a string! There was no url property, so nothing was being rendered. I fixed the issue but this time I entered to the application as a normal user to make sure that it was fixed. Confirming this, I pushed the code to QA again, keeping an eye on it until it passed QA successfully.

TL;DR, always test what you're doing

Sometimes, we might fall under the temptation of making changes and assuring that it will work. You may do it because you don't want to spend time compiling the project, turning up&down those docker-compose services, redeploying your code to Dokku or, like me, simply didn't want to go to your project's company page to click on an URL.

As tedious as the validation process may be, in the long run, you'll waste much less time testing your changes before passing them to QA. They will also keep your QA metrics healthy :)

Top docker images that I tend to use ad-hoc

José Clovis Ramírez de la Rosa — Thu, 31 Jan 2019 02:42:41 +0000

Docker is a great tool for building and shipping Software. Many teams around the world are taking advantages of its features. For Development, it is particularly useful to be able to declare your whole stack in a docker-compose.yml file and bringing it up and down with all the dependencies and packages that it needs to run.

I tend to use Docker a lot, not only as part of a project but also to perform several ad-hoc tasks. The primary benefit for me is that I don't have to bother installing and then removing the required software - a Docker image is all that's needed to spin-up a container! Here's the top list of Docker images that I tend to use ad-hoc.

1.Adminer

Adminer (formerly phpMinAdmin) is a full-featured database management tool written in PHP. It comes very handily when you need to access an external Database and having a UI will be of help.

Docker command:

docker run -d -p 8080:8080 adminer

Explanation:

-p 8080:8080 = link the host port 8080 with the container port 8080.
-d = run on detached mode.

2.Nginx

Nginx is a high-performance Web server and the go-to solution for multiple companies around the world. If you've ever had to configure it then you may appreciate being able to do it in your machine, rather than having to connect to the host where it is running.

Docker command:

docker run -it -p 80:80 -v $(pwd):/usr/share/nginx/html nginx bash

Explanation:

-p 80:80 = link the host port 80 with the container port 80.
-it = It is actually combining two flags, -i (interactive) and -t (allocate a tty).
-v = mount in volumen. $(pwd) is the current working directory and /usr/share/nginx/html is the place inside the container where it will be mounted.
nginx bash = run bash inside nginx (Inside the container you can run nginx commands as much as you want).

3.Ansible

Ansible is an automation tool for apps and IT infrastructure. It is like Chef and Puppet. You tell Ansible how to connect to the host and define how the host should be configured, and it will go to configure the host for you.

Docker command:

docker run -it -v $(pwd):/app ansible bash

Explanation:

-it = It is actually combining two flags, -i (interactive) and -t (allocate a tty).
-v = mount in volumen. $(pwd) is the current working directory and /app is the place inside the container where it will be mounted.
ansible bash = run bash inside ansible (Inside the container you can run ansible commands as much as you want).

4.Sqlite3

SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. The data can be stored either on a single file in the disk or in-memory.

I've been using sqlite3 a lot lately to interact with a Python webscrapper that have the data in an SQLite file. The CLI and the instructions could get better, but definitively does the job!

Docker command:

docker run -it -v $(pwd):/root/db --entrypoint bash nouchka/sqlite3

Explanation:

-it = It is actually combining two flags, -i (interactive) and -t (allocate a tty).
-v = mount in volumen. $(pwd) is the current working directory and /root/db is the place inside the container where it will be mounted.
--entrypoint = sets the entrypoint command of the container. In this case, the entrypoint will be Bash.

Notes about the docker run commands:

You can add --rm and it will remove the container as soon as it stops.

These are the ones that I tend to use nowadays. Of course, I also use ad-hoc images when I'm learning something (latest were Python3 and Elixir/Phoenix) or under other circumstances (checking if I'm ready for Node V10 or giving maintenance to an old PHP5.4 app).

Of course, if you're running an ad-hoc container a lot for one specific project, you may want to consider using docker-compose instead.

Do you usead-hoc images in your day-to-day? Which ones?

I love to document my code. Am I doing it wrong?

José Clovis Ramírez de la Rosa — Sat, 08 Sep 2018 11:17:51 +0000

I've been saved countless of times by people who document their code, and also doomed by people who doesn't. At some point I just started to love comments, even the most redundant ones. I strongly believe that a comment is never wrong, unless outdated or misleading.

Sadly not much people seems to like this stance. Instead of documenting our functions, we rely on the naming convention and writing expressive code to figure out the what and the why of any code. Sometimes we even have aesthetic troubles with it, as if the comments were distracting us from the code itself.

I like to write expressive code, but I don't see it as a replacement of proper documentation.

Am I doing it wrong?

Don't make that function async.

José Clovis Ramírez de la Rosa — Thu, 19 Jul 2018 01:00:36 +0000

Today's a good day to write Javascript code. ES2015 and the newest features that are coming to the language every year makes it a joy to use. With ES2017, Javascript gained Async/Await, which gives a more concise, expressive syntax to handle asynchronous code. It is available in the latest releases of Node and it can be transpiled using Babel to target the browser.

However, as awesome as it may be, marking a function as async won't magically make your code more performant. More often than not, I stumble against this type of code:

async function saveUser(userData) {
  const user = await this.userRepository.saveUserInDatabase(userData);
  return user;
}

Oh, is that type of async function again.

What happens when you await a function.

When using the keyword await, Javascript will pause the function's execution and return the control to it's caller until the asynchronous operation is completed. In the previous example, our saveUser function will stay standby, waiting for the promise returned by the call to the method saveUserInDatabase(userData) to regain the control and return the results.

Now imagine that we make every single function async. Every function would have to wait for every individual function to be resolved, then that function will get back the control, just to give it back to that function's caller. Under this circumstance the Node process will have to start/stop and save/recover every function's execution state. This actually makes the code less performant!

Imagine if we have several layers in our system, each waiting for the other one to complete to temporally gain the control and give it back again. Your callstack might end up looking like this:

Advices for making a function async.

Generally speaking, async functions are just a promise. They represent a future value that has not been computed yet (can also be seen as an ongoing event). It is a good practice to delay the Promise's computation as much as possible until the value is needed. I think that an async function is a good idea if:

You need the value of another async function: For example, you may want to wait at the database layer for a query to complete so that you can wrap the result and transform it into an entity of your domain.
You need to perform extra steps after the completion of an async function: For example, it would be okay to wait for the user to save in the database if we wanted to send him an email right after. We can return a promise that symbolizes the user email instead.

async function saveUser(userData) {
  const user = await this.userRepository.saveUserInDatabase(userData); // We need the user.
  return this.sendUserEmail(user); // this.sendUserEmail is another async function.
}

You need to handle the exception: Sometimes you want to run an async operation but you need to respond to an eventual failure at that layer's level. For example, we could await the database layer execution when creating an user if we have to delete the user profile picture on failure.
It makes the code more expressive: There may be a time where we need to make a tradeoff between performance and cleaner code :).

Wrapping up.

Async/Await is one of the best things ever reaching the Javascript world. It is a powerful and expressive way to express asynchronous operations. With all this greatness, overusing it can hurt performance, readability and creates complexity - a complexity that it's just not worth the effort sometimes. When creating functions, it is a good idea to give back the control to the function's caller as fast as possible.

Happy Coding!