DEV Community: Guillermo Verón

Are you a professional developer?

Guillermo Verón — Tue, 25 May 2021 12:40:34 +0000

According to Robert C. Martin, author of Clean Code: A Handbook of Agile Software Craftsmanship:

Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.

But what does "clean code" mean?

As Robert C. Martin mentions in his book, many authors have their own definitions of clean code. However, most of them mention at least one of these characteristics:

Easy to read
Easy to understand
Easy to change

To this end, the code must be simple, tidy, and have the right abstractions. It is necessary to spend time reviewing the code to find ways to improve it and achieve a clean code.

The code review

In the code review, we can find many improvements such as more meaningful variable names, splitting long methods into smaller ones, reorganizing code into more specific classes, and so on. Of course, this can take time. But that investment of time will pay off every time you or your co-workers refer back to the code. It will be easy to read, understand and change.

As a result of the code review, we would deliver a polished and refined code. Our co-workers would appreciate it and we would convey the culture of clean code also. When others see that elegant and tidy code, no one will want to be the first to screw it up.

Reasons why we don't write clean code

Let's be honest. Sometimes, we forget to review the code or just leave it for later refactoring. That code can even stay there forever, though. There is a famous saying:

Later equals never

As developers, we commit to complete a certain amount of work. We have deadlines, that unconsciously lead us to code as quickly as possible, leaving aside the code review and consecutively the code quality.

Follow @gitlost on Twitter for more funny git commit messages.

We could go on citing reasons why we don't write clean code, such as the code was already a mess before it passed through our hands, as mentioned by Andy Hunt and Dave Thomas in The Pragmatic Programmer, making an analogy with the broken windows theory. You can find more information about this theory in this article.

Photo by Joe Dudeck on Unsplash

It turns out that, as professionals, we should not look for excuses but solutions. If something is not right, we must be able to communicate it and provide solutions. Otherwise, we would be part of the mess. So, the main reason we don't write clean code is that we are not professionals.

Conclusion

Spending time on code review is the key to clean code and can make the difference between being a professional developer or not. A professional not only cares about the code does what it is expected to do but also cares about the quality of the code.

So the next time you are about to push your changes, I invite you to take a look at your code and ask yourself the following questions:

Am I satisfied with this code?
Does this code represent me as a programmer?

If the answer is no, I invite you to spend some time reviewing your code and finding ways to improve it.

So, are you a professional developer?

Thanks for reading!

Build a Generic CRUD API with ASP.NET Core

Guillermo Verón — Mon, 10 May 2021 18:11:45 +0000

In the process of creating CRUD controllers, we can repeat a lot of code and go against the DRY principle. To avoid that, I'm going to show you how to build a generic base controller, then you will only have to create controllers that inherit from the base controller, and that's it. The controllers will already have the basic CRUD methods.

I saw a lot of articles about the Generic Repository Pattern. What I'm going to show you is not a Repository Pattern. EF Core is already based on the Unit of Work and Repository Pattern. Thus, we can use the DbContext class directly from our controllers, and that's what we're going to do. Anyway, you can find more information about using a custom repository vs using EF DbContext directly here. With that said, let's start to build our Generic CRUD API.

Base Model

At first, let's define the base model for our entities. For operations like edit and delete we need an Id property, and we can have some timestamp properties for audit as well. So EntityBase looks like this:


 c#
using System;

namespace GenericCrudApi.Models
{
    public class EntityBase
    {
        public long Id { get; set; }
        public DateTime CreationDate { get; set; }
        public DateTime? ModificationDate { get; set; }
    }
}

Generic Base Controller

Now, we are ready to implement our generic controller. It will be an abstract class because it will be the base class for our controllers, and we'll mark the CRUD methods as virtual since we need to be able to override them in our inherited controllers if necessary. So CrudControllerBase looks like this:



using System;
using System.Threading.Tasks;
using GenericCrudApi.Models;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;

namespace GenericCrudApi.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class CrudControllerBase<T>: ControllerBase where T: EntityBase
    {
        protected readonly DataContext _context;

        public CrudControllerBase(DataContext context)
        {
            _context = context;
        }

        [HttpGet]
        public virtual async Task<IActionResult> List()
        {
            var entities = await _context.Set<T>().ToListAsync();

            return Ok(entities);
        }

        [HttpGet("{id}")]
        public virtual async Task<IActionResult> Detail(long id)
        {
            var entity = await _context.Set<T>().FindAsync(id);

            if (entity == null)
                return NotFound();

            return Ok(entity);
        }

        [HttpPost]
        public virtual async Task<IActionResult> Create(T entity)
        {
            entity.CreationDate = DateTime.Now;
            await _context.Set<T>().AddAsync(entity);
            await _context.SaveChangesAsync();

            return CreatedAtAction("Detail", new { id = entity.Id }, entity);
        }

        [HttpPut("{id}")]
        public virtual async Task<IActionResult> Update(long id, T entity)
        {
            if (id != entity.Id)
                return BadRequest();

            if (!await EntityExists(id))
                return NotFound();

            entity.ModificationDate = DateTime.Now;
            _context.Entry(entity).State = EntityState.Modified;
            await _context.SaveChangesAsync();

            return NoContent();
        }

        [HttpDelete("{id}")]
        public async Task<IActionResult> Delete(long id)
        {
            var entity = await _context.Set<T>().FindAsync(id);

            if (entity == null)
                return NotFound();

            _context.Set<T>().Remove(entity);
            await _context.SaveChangesAsync();

            return NoContent();
        }

        private Task<bool> EntityExists(long id)
        {
            return _context.Set<T>().AnyAsync(e => e.Id == id);
        }
    }
}

Note: _context.Set<T>()

Returns a DbSet instance for access to entities of the given type in the context and the underlying store.

Inheriting from the Generic Base Controller

It's time to see our base controller in action, for this we're going to create a TodoItem controller by extending the CrudControllerBase.



namespace GenericCrudApi.Models
{
    public class TodoItem: EntityBase
    {
        public string Name { get; set; }
        public bool IsComplete { get; set; }
    }
}



using GenericCrudApi.Models;
using Microsoft.AspNetCore.Mvc;

namespace GenericCrudApi.Controllers
{
    public class TodoItemsController: CrudControllerBase<TodoItem>
    {
        public TodoItemsController(DataContext context) 
        : base(context){}
    }
}

And that’s it. Now we can test the HTTP methods with Postman:

Alright, the API is working but we still have some work to do. For real-world applications, we should be careful with data access. For instance, for a User entity we should not return the password hash in the GET method, as well as we might need some validations in the POST and PUT methods. For this, we can add Automapper and inject it in the CrudControllerBase. Also, we might add soft delete support to the DELETE method. And finally, to make our code completely reusable, we need to add filtering, sorting and pagination features.

In short, the to-do list:

Add Automapper and inject it in the CrudControllerBase.
Add filtering, sorting and pagination features.
Add soft delete support

I'd like to write about it in futures articles. So, if you liked this article, please let me know in the comments and stay around. If you are interested in contributing, feel free to fork the project and send me a Pull Request.

View or download the sample code on GitHub.

Thanks for reading!

Git - How to fix a bad commit

Guillermo Verón — Sat, 24 Apr 2021 14:01:35 +0000

Oh no, this commit is a mess! 🤦‍♂️

We all have a bad day sometimes. We can forget to include a file, leave some comments, or a merge didn't go as expected. Fortunately, Git has some commands to deal with these common situations and I want to show you some of them.

Modify commit message

Oops... You found a spelling mistake in the commit message. No worries, you can modify it:


 bash
git commit --amend -m "new message"

Add files to last commit

You already have committed the changes but forgot to add some files. No problem, you can still add them to the commit:


 bash
git add <file_name>
git commit --amend HEAD~1

Undo commits

If you want to undo the last commit but keep the changes:


 bash
git reset --soft HEAD~1

If you want to undo both commit and changes: ⚠️ Be sure that you want to lose the changes:


 bash
git reset --hard HEAD~1

Alternatively, if you want to undo all your local changes, you can reset to the origin version of the branch:


 bash
git reset --hard origin/<branch_name>

If you want to undo the commit without altering the existing history. You can use git revert, this command undoes a commit by creating a new commit:


 bash
git revert HEAD

If you have just resolved some conflicts, finished the merge, and push to origin. But wait, something went wrong...

The safe way to undo a merge commit that has already pushed to the remote branch is using the git revert command:


 bash
git revert -m 1 <commit_id>

commit_id is the merge commit id that you want to revert.

Notes:

You can also undo any number of commits. E.g:
- git reset HEAD~3 (going back three commits before HEAD).
- git reset --hard <commit_id> (going back to a specific commit).
Use git reset if the commit is not pushed yet and you don't want to introduce a bad commit to the remote branch.
Use git revert to revert a merge commit that has already pushed to the remote branch.
Use git log to review the commit history.
If you prefer, you can also create a new commit with the fix.

I hope you find these commands as useful as I do and can use them. If you already knew these or think one is missing, please let me know in the comments. Thanks for reading!

Vue JS - Differences between Computed and Watch

Guillermo Verón — Thu, 01 Apr 2021 16:24:11 +0000

When I started to code in Vue and had to react to changes, I always asked myself the same question: computed or watch? 🤔️. The both seem to do the same, right? However, a computed property may be better than a watcher in some cases or vice versa.

Computed

We can think of a computed property as a normal property, but with the difference that Vue automatically evaluates its value every time one of its dependencies is changed. For instance:

computed: {
  total() {
    return this.price * this.quantity;
  }
}

The total property will be calculated every time the price or the quantity changes.

Watch

A watcher is basically a function that Vue automatically executes when the watched property changes. If we take the above example, we could do it as follows:

watch: {
  quantity(val) {
    this.total = this.price * val;
  },
  price(val) {
    this.total = this.quantity * val;
  }
}

This works, but it's a lot of code. We would have to add a third watcher if the total property also depended on the tax. This is the main reason why it's a better idea to use a computed property instead.

While computed properties are more appropriate in most cases, watchers are more powerful and allow us to perform complex operations such as HTTP calls or execute some asynchronous logic that wouldn't be possible with a computed property.

Suppose we want to get the movies in which an actor appears. We could do it in the following way:

export default {
  data() {
    return {
      actorId: null,
      movies: [],
    };
  },
  methods: {
    getMovies() {
      // http request
      axios.get(`movies/actor/${this.actorId}`)
      .then(resp => {
        this.movies = resp.data;
      });
    }
  },
  watch: {
    actorId(val) {
      if(val) this.getMovies();
    }
  }
}

Another use case for a watcher is when we need to watch a data property until it reaches a specific value, and only then do something. For instance:

watch: {
  quantity(val) {
    if (val > this.stock) {
      this.error = true;
      this.errorMessage = `We only have ${this.stock} units`;
    }
  },
}

Conclusion

Computed properties and watchers have different use cases. It would be a better idea to use a computed property whenever we need to calculate a value based on other properties, considering that Vue will reevaluate the property every time any of its dependencies is changed and we will not need a custom watcher for each dependency. But a watcher would be better if we need to do something more generic than just get a value, such as HTTP calls, store data in local storage, set a timer, or whatever we couldn't do with computed properties.

Vue JS - Diferencias entre Computed y Watch

Guillermo Verón — Tue, 30 Mar 2021 12:50:43 +0000

Cuando empezaba a programar con Vue y tenía que reaccionar a cambios, siempre me hacía la misma pregunta: ¿computed o watch? 🤔️. Ambos parecen hacer lo mismo, ¿cierto?. Sin embargo, una propiedad computada puede ser mejor que un watch en algunos casos o viceversa.

Computed

Podemos pensar en una propiedad computada como una propiedad (como las que retornamos en el data), pero con la diferencia de que Vue puede evaluar automáticamente su valor cada vez que una de sus dependencias cambia. Ej.:

computed: {
  total() {
    return this.precio * this.cantidad;
  }
}

El valor de la propiedad total será calculado cada vez que cambie el precio o la cantidad.

Watch

Un watcher es básicamente una función que se ejecuta automáticamente cuando la propiedad observada cambia. Si tomamos el ejemplo anterior, podríamos hacerlo de la siguiente forma con watchers:

watch: {
  cantidad(val) {
    this.total = this.precio * val;
  },
  precio(val) {
    this.total = this.cantidad * val;
  }
}

El resultado final es el mismo, pero la solución con watchers es repetitiva. Si el valor de la propiedad total también dependiera del impuesto, tendríamos que observar una tercera propiedad. Esta es la principal razón por la que es mejor idea utilizar una propiedad computada.

Si bien las propiedades computadas son más apropiadas en la mayoría de los casos, los watchers son más poderosos y nos permiten realizar operaciones complejas como llamadas http o ejecutar alguna lógica asíncrona que no sería posible con una propiedad computada.

Supongamos que queremos obtener las películas en donde actuó un determinado actor. Podríamos hacerlo de la siguiente forma:

export default {
  data() {
    return {
      actorId: null,
      movies: [],
    };
  },
  methods: {
    getMovies() {
      // http request
      axios.get(`movies/actor/${this.actorId}`)
      .then(resp => {
        this.movies = resp.data;
      });
    }
  },
  watch: {
    actorId(val) {
      if(val) this.getMovies();
    }
  }
}

Observamos la propiedad actorId para que siempre que cambie de valor, llamemos una API que nos devolverá las películas relacionadas al actor.

Conclusión

Es mejor idea pensar en una propiedad computada siempre que necesitemos calcular un valor en función a otras propiedades, teniendo en cuenta que Vue volverá a evaluar la propiedad cada vez que alguna de sus dependencias cambie y no necesitaremos un watch personalizado por cada dependencia. Pero un watch sería mejor si en cambio necesitamos realizar algo más complejo como llamadas http, configurar un timer o guardar datos en el local storage.