Recently, Containers (Kubernetes and Dockers), have become a buzzword in the IT world. It’s success and tremendous adoption is due to 
how it makes easy to solve one of the biggest DevOps problems today: **The Deployment**.

This problem arises from the fact that you need to accommodate a lot of different technologies (software and hardware) in a lot of different 
environments from the development until the production stages, and the configurations for all these environments are complex and error 
prone leading to situations were the software runs in one environment, but not in the other. With containers, this is not an issue.

> If it works in one container correctly it will run in every container, no matter the hardware or the OS where the containers are running.

In short, containers allow you to package up an application with all the parts needed, such as libraries and dependencies, and deploy it as 
single package which is OS agnostic, like if it was a Mobile App, with its own sandbox, but better because you’d be able to install the exact 
same app in both Android and iOS. Containers gained popularity when Docker was released in 2013, making containers easy to use, not 
only in Linux but also in Windows and OS X.

The biggest advantages of containers when compared with Virtual Machines (VM) are the speed and the lower resource usage. Per host 
machine, you can have more containers than VMs, with a performance increase in both boot speed and container size than you would have 
with VMs. This not only brings down infrastructure costs (both Cloud and on premises) but also the operational costs, since maintenance of 
all environments are pretty much the same.

Although there are clear advantages to work with Containers, as described in the huge number of articles that we can find online (stating 
how awesome containers can be used for software development) there are also some drawbacks: development using containers require 
the setup of a complex container environments and will require a controlled release management (which can be eased up with automation 
development support tools (such as Maven, Jenkins, SonarQube). It also brings a risk of development slowness (as the project grows the 
slowness and complexity would grow with it). This slowness is compensated with the main major advantage of Containers: How easy it is to 
perform a deployment.

> Containers deployment is easy and fast because you no longer need to worry about complex, and error prone, specific configurations for each environment. Now, if it works as it should in one container it will work, for sure, on every container in any environment. No longer we will have the episodes of “It was working on my machine…”!

Besides the obvious advantage of this kind of setup, a quicker onboarding for new team members, there is other like the need to setup a 
single environment either for development and to deployment.


## Conclusion

Bottom line is yes, for most of our client projects it makes sense to setup development environments on top of a container-based 
environments, even considering the price that you have to pay to setup a complex development environment and loose some of the speed 
of developing in a native environment.

[Docker](https://www.docker.com/) is an open source implementation of Linux containers. Containers are based in a Linux feature called cgourps, that limits and 
isolates the use of resources (CPU, RAM, OI, network, …) to a collection of processes. This feature is a part of the Linux kernel since version 
2.6.24, release in January 2008.

[Kubernetes](https://kubernetes.io/) are an open-source container-orchestration system. It works with a range of container tools, including Docker.

Example of a docker file:
```dockerfile
FROM ubuntu:18.04
COPY . /app
RUN make /app
CMD python /app/app.py
```

Are Containers the Next Best Thing for  Development?

Recently, Containers (Kubernetes and Dockers), have become a buzzword in the IT world. It’s success and tremendous adoption is due to 
how it makes easy to solve one of the biggest DevOps problems today: **The Deployment**.

What is clean code? Well, in simple terms, clean is basically code that can be easily understood and modified.

Why clean code? You need clean code because code is meant to be read by humans not by machines, the cleaner it is the easier it will be understood. You’ll be building systems that are not static and will be expanded/changed when new requirements arise, and because the code will have bugs and they need to be fixed. There is also another very important reason, when someone else (or maybe even yourself after a few months) needs to use or change the code it will be easier for them to be productive if they can understand your code quicker.

There are a few tricks you can use, no matter your level of experience, you can use right away to make your code cleaner: **Small functions** and **Good naming** (in variables, functions and classes). Although there are more, my experience has shown me that those two alone will have the bigger impact for lowest effort, because for the most part it’s not a matter of skill/knowledge, is just a matter of caring.

## Small Functions
As you know, the best way to solve a problem is to split it into smaller pieces. This is exactly what this trick is all about. A big function is harder to debug, change and test than a set of smaller ones. An additional benefit of this is the ability to reuse code. So, all you need to do is to make sure a function will only do one thing and do it well.

#### The key benefits are:

- **Improved code readability**: if the functions are small, it will easier to browse through the code, and will take less cognitive effort to understand what it does.
- **Code reuse**: when the functions are small and only one thing there will be a bigger chance for it’s reuse.
- **Easier testing** and debugging: smaller code blocks are obviously easier to test using unit tests. At the same time, they are also easier to debug.
- **Easier refactoring**: when your code is doing only one thing and it easier to move the code around because it will have less dependencies and, using the IDE tools, it is very easy to rename it, for example.
- **Easier to name properly**: having a small concise function will make it much easier to name it accurately!
 
> Tip: if you consider use “and” or “or” in you function name to convey its meaning you are probably doing too much in a single function. Consider breaking it.

## Good Naming
Having things named right is hard! The golden rule is to have the name clearly describe its meaning. However, you should take the additional effort because will pay-off big time throughout the development life cycle. When you see a reference of a variable, function or class, you can infer what it is and/or what it does without having to investigate its details.

#### The key benefits are:

- **Improved code readability**: When a variable, a function or a class are well named the code will become much easier to understand because you can infer they’re meaning or purpose without the need to investigate the details.
- **Improved team performance**: when the team uses the same name conventions, you’ll feel right at home changing another person’s code.
- **Improved maintainability**: When you use names from relatable to the domain, you can count not only on the technical team, but also on the business teams because they will be able to relate and understand questions you might have.

###### There are a few rules of thumb when it comes to naming things:

- **Naming protocol**: you can find names that make sense to you, but you must consider how much sense they will make to others. In most cases it is a safe bet to use names that most programmers can understand (e.g., “iterator”) or domain specific names.
- **Respect language standards**: You must respect language standards like casing. For example, in java all functions and variables names should be in Camel Case, and classes and interfaces in Pascal Case.
- **Searchable names**: it is a good practice to make you names easily searchable. For example, searching for a single or double-letter names will yield much more results than you wish. Another example is using a well named constant instead of number (e.g. `PAGE_SIZE=10` instead of just “10”).
- **Pronounceable names**: it will make it easier to remember and to discuss you team members, when, for example asking questions.
- **Don’t add the type to the name in variables**: That is just noise. Most times, the tooling will warn if you mess up with the types, and if you need to change the type you will also have to rename the variable in every single place to avoid disinformation.
- **Classes should be named using nouns or noun phrases**: A class names should not be a verb because a class is a thing.
- **Functions should be named using verbs or verb phrases**: A function does things, it is not a thing.


# Conclusion
Although this is a very simple set of rules, I keep seeing bad code being written by junior and senior developers alike. Just start using them right away and this for sure will make your future self much happier!

As professional developers we need to be responsible for our code, having it work is not enough! A good professional takes care of its code and must make sure what he/she releases is the best they can do, not only for themselves, but also and foremost to be used by others.

There are quite a few more techniques to make you code clean. Robert C. Martin has two books dedicated to this subject (Clean Code and Clean Architecture), these books are quite complete, and provide an in depth set of techniques to build and design clean code. I urge you to read them!

##### References
Martin, R. C. (n.d.). *Clean Code: A Handbook of Agile Software Craftsmanship*. Prentice Hall. Retrieved 8 13, 2019

```javascript
export const getStaticProps = async () => {
  const strapiData = await apollo
    .query({ 
      query: getArticlesPage,
    })
    .then((res) => res.data || {})
    .catch(err => console.log(err))

  const { pages, articles } = strapiData;
  return {
    props: {
      page: pages[0] || {},
      articles,
    },
  };
};
```
```PAGE_SIZE=10```

Become a Clean Coder Quickly

A couple of tips to allow you to create more readable an extendable code. 

Writing clean code is very hard. However there a couple of tips that will make write cleaner code right away: **Small Functions** and **Good Naming**. 

Become a Cleaner Coder Quickly

# My Articles

A list of articles written by me.