
I constantly find myself perplexed, discussing with colleagues how quickly I forget things. It seems my mind randomly selects certain information to retain for a decade, while it throws other details away. It can be something I learned, a special moment, an event, even something bad someone said to me. I'm very guilty of this.

To work around that, I decided to take some action. First, I began taking pictures of nice <s>random</s> things, despite my lack of interest in cameras. Particularly after a year full of life-changing events, there are times when you struggle recall a special moment. I'm happy to share some special pictures [here](https://alison.dev.br/photos).

In a professional setting, I began keeping a daily logbook of all my activities in 2020, and it has since become a routine.

![Monthly Notes](/assets/posts/montly-notes.png)

In these monthly documents, I log all my work, decisions, feedbacks, and plans. Similar to my [brag document](/posts/brag-documents), it helps me stay organized for monthly reviews with my leader or any other activities that require this information.

Here's a list of <s>example</s> activities I maintain in these documents. I can add one or a few of them, but never everything on the same day.

- Daily Tasks
- Meeting notes and preps
- 1-1 notes and feedbacks
- Draft of technical documents
- Technical/Product decisions
- To-to list of the next day
- Interview Feedbacks


I forget things quickly


I acknowledge this title looks like a click bait, but at the end of the day it's true: not everything needs refactoring.

Working in large codebases isn't easy and can become a terrible experience if you don't:

- Keep improving the code as you add new features;
- Work with automated tests;
- Deprecate and remove unused code;

As the code becomes legacy and your production environment starts to experince more incidents due to your code's lack of quality, there are a few steps I like to reproduce in order to revamp the project and establish a good environment for engineers and the end user.

## Work with your leaders

Even in projects that aren't breaking production because of technical bebt, there's always something to be improved. Negotiate a time on your cycles to work on technical debt and   improvements. Ensure that it's a continuous effort rather than a one-time project. A few options to start including these tasks in your cycle.

- [Friday-fix](https://www.elastic.co/blog/solving-the-small-but-important-issues-with-fix-it-fridays);
- Fixing schedule: each developer works on a improvement at time;
- A percentage of your tasks dedicated to tech-debt.

But remember: before you start working on actual improvements, communicate the current scenario to your leaders and try to propose what needs to be done. These problems need visibility.

#### Refactoring may introduce new bugs

Even if you have the perfect test coverage of your application, a dedicated QA team running tests of different kinds, new changes may introduce bugs. Refactoring changes included! In this case, we should avoid blaming specific people and try introducing new ways to avoid such issues from happening again (e.g.: automated tests!).

## Small changes, big wins

To start with ‘big wins’, think of anything that won't require the team to learn something new and that will improve everyone's life. It can be automated solutions, code-mods, automated tests,

#### Automation

In some cases, introducing a better linter, an auto-formatting tool, a few code-mods, a code complexity analytics tools will ensure that new features follow a better standard in comparison to the existing codebase without introducing a new cerimony or specific task to the team.

#### Tests

Foster the automated tests culture. Whenever you change a piece of code, try adding a test. New bug? Try adding a new test to prevent it from happening again.

It can be annoying in most cases, but it's worth doing. Refactoring without tests is a risky approach.

#### Priotization

Priotizing technical debt isn't easy, but you can build your own board to help you determine small improvements that can solve critical issues, especially the ones users care and actually use.

Most of the times it's not as simple, since critical issues usually require a larger initiave, but in these cases, try to break it down in smaller parts and iterate over time.

## Communicate with your peers

As these enhancements start to become the standard for your team, send regular notes about the improvements your team has been acomplishing. It can hard to follow all the changes and some people may start loosing track. Try sending weekly

## Not everything needs refactoring

That's the title of this post, and you propably read everything waiting for this but this idea here is quite simple: If a feature is not being used, is not critical, might be replaced soon, has a complex context, or might introduce conflicts with other branches, you should consider not refactoring it at this stage.

Simply acknowledge it as a tech debt. Additionally document/comment and explan why the team is not prioritizing that change at the moment and move on. In the future, the team may consider it's the right time to improve that part of the codebase based on your own board of priorities.

Not everything needs refactoring


CSS grids are perfect to strcuture complex layouts, but we can also leverage its capabilities do deliver nice animations on the front-end.

As an example, we can animate two columns. Once I hover one of them, it expands and therefore the other column shrinks. See the demo:

![Grid columns animation using CSS](/assets/posts/grid-columns-animation-hover-effect.gif)

## HTML

```html
<div class="grid">
  <div class="item"></div>
  <div class="item"></div>
</div>
```

## CSS
Here's all the CSS you need to make this work. Some of the properties used here are only for styling purposes, so feel free to change them to fit your needs.

```css
.grid {
  height: 300px;
  transition: 300ms;
  display: grid;
  grid-template-columns: 1fr 1fr;
}

.item {
  height: 100%;
}

.item:first-child {
  background: #455d7a;
}

.item:last-child {
  background: #f95959;
}

.grid:has(.item:first-child:hover) {
  grid-template-columns: 1.5fr 0.5fr;
}

.grid:has(.item:last-child:hover) {
  grid-template-columns: 0.5fr 1.5fr;
}
```

Pretty cool, huh?

<small>Source: [1](https://css-tricks.com/animating-css-grid-how-to-examples/).</small>


Grid columns animation using CSS


This is a simple experiment made to explore the usage of Supabase and Shadcn/UI on a NextJS application using the pages router.

Check it out on Github for more details: [https://github.com/alisonmonteiro/dsnapp](https://github.com/alisonmonteiro/dsnapp).

The application is built using NextJS, a React framework that enables server-side rendering and static site generation.

I'm also using [Supabase](https://supabase.com/) as a database and authentication provider. For the UI, I'm using [Shadcn/UI](https://ui.shadcn.com/), a simple and lightweight library for building interfaces.

Simple notes app using NextJS, Supabase, and Shadcn/UI


This week I was working on a personal project and at some point I wanted to covert a PDF file to HTML. After doing some research, I found [Apache Tika](https://github.com/apache/tika), a toolkit that can detect and extract text and metadata from different file types, such as PDF, PPT, XLS.

In my case, I decided to use it on the command line, but you can use it as a dependency in a Gradle project, as Maven dependency and so on. Click [here](https://tika.apache.org/3.0.0-BETA/gettingstarted.html) to check more details on how to get started in their website.

## CLI

To use it in your command line, you have to have Java installed on your server. If you’re running it locally, you’ll also have to install java in your computer or container. Run `java --version` to check your current version.

First, donwload the JAR file. Here we’re using `wget` but you can get it using other package to retrieve files such as `curl`.

```bash
wget https://archive.apache.org/dist/tika/2.6.0/tika-app-2.6.0.jar
```

Then, run the the command with the following structure:

```bash
java -jar /[path_to]/tika-app-2.6.0.jar --[output_format] [source_file]
```

For example:

```bash
java -jar /home/alison/dev/project-x/tika-app-2.6.0.jar --html ./static/report.pdf
```

This command will transform your PDF file in HTML and display the new content in your stdout. Check their documentation for more options and formats.


Converting PDF to HTML from the command line


I like to create software following a simple approach where I first define how clients will interact with it, should it be humans interacting with UIs or other apps interacting with APIs.

Say I want to create an SDK in Go that interacts with a internal service. First, I determine how other apps will interact with that. For example, before starting creating the logic behind the function, I know my function will look like this:

```go
func main() {
  items, err := customSDK.GetItem(id)
  // ...
}
```

Usually, that also makes my life easier to work with automated tests. During the actual development, I'll probably add a new extra parameter or even make a brutal change to the API, but that's how I like to start.

That's not different for user interfaces, I like to see real information when coding front-end stuff as well. In most cases, the front-end will start after the API is already finished, especially when it comes to rebranding the entire UI and starting a fresh version.

Though, sometimes we need to see the front-end in action even when the back-end is planned to be executed after. Also, there are some cases we want to implement a feature as a test or playground to learn something new, but don't want to implement an entire back-end API.

## Serving Mock data

Instead of creating mock objects directly on your front-end, and adding timeouts to ‘fake’ a loading layer that a network request would add, you can simply create a mock server using `json-server`.

Create a `db.json` file and add in some resources:

```bash
{
  "posts": [
    {
      "id": 1,
      "title": "My post title",
      "views": 100
	}
  ],
  "profile": {
    "name": "My Profile"
  }
}
```

Simply run:

```bash
npx json-server db.json
```

Once you start your local server, you can run the following command to get a post with ID = 1:

```bash
curl -X 'GET' 'http://localhost:3000/posts/1' \
  -H 'Accept: application/json'
```

That's it! You now have a REST API up and running. Run `npx json-server --help` for a full list of option or check the [documentation](https://github.com/typicode/json-server).


Mocking data for Front-end developers


As a software engineer, I've worked in a wide range of tasks. These include tasks with a defined scope, containing numerous decisions and well-documented rules, as well as tasks that require more exploration to be completed but still have a certain date to be deployed. For the latter, the scope can be adjusted if we encounter conflicts, overlaps, or other issues along the way.

When a conflict is found during the task execution I would probably ask the reporter what to do and give some suggestions over a call or Slack and continue with the implementation. What happens a month later when someone asks why this addition to the scope is in production, though?

I can decide to simply look directly at the code, which would take a while to understand and refresh my mind on that topic, but with good commit messages and PRs in addition to a clean code base I would find an answer at some point.

That being said, I wanted to suggest a simpler approach that can be implemented during or right after the call. This method ensures that the information remains publicly available, even for non-technical people. Decisions can be added to the ticket as a comment, or to a documentation page if the concept is too complex to fit in a comment.

## What is ADR?

An **Architecture Decision Record** (ADR) is a document that records a significant architectural choice made, including the reasons and results. There are some examples [in this repository](https://github.com/joelparkerhenderson/architecture-decision-record) that you can take as reference.

## Start simple

For now, you can start with a simple approach. If your team doesn't have a culture of creating documentation yet, begin by adding context to the Pull request description, as code comments or as a markdown file.
Explain the issue, the decision and the consequencies and gradually provide more details in the ticket.
Eventually, create a small repository of documentation and share it with your team, that’s really important especialy on larger groups of people.

## Keep improve as you go

That all being said, you can keep this mindset and use the tools you already have to document your decisions. In the example I gave in this post, I mentioned “ticket” but you can use any other tools such as Linear, Notion, Confluence or any other tool.
The goal is to keep the decision and its whys available and transparent to everyone on the team.


ADRs: Not just for Architectural decisions


After finishing the book [The Manager's Path](https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897), I wanted to pick a few options that made me find a good balance between engineering and tech management skills. My goal was to read 10 books, but turns out I've finished 4 and have a couple unfinished:

## Engineering Management for the Rest of Us

This is one of the best books I've read about tech management so far, especially because I came from a non-management background. It's funny and compelling but also useful. I contains lots of practical advices. I had to buy new highlighter just for this read 🤣. I highly recommend it if you're eyeing a role in tech management.
[Find it on Amazon](https://www.amazon.com/Engineering-Management-Rest-Sarah-Drasner/dp/B0BHX8BQ9C).

## Grokking Algorithms

<b>An Illustrated Guide for Programmers and Other Curious People</b>.
This is one of those books you'll read in a couple of weeks. It's really simple and fun to read. If you have a technical background, you can take it as a review of fundamental concepts, including simple patterns and algorithms.
[Find it on Amazon](https://www.amazon.com/Grokking-Algorithms-illustrated-programmers-curious/dp/1617292230).

## On Writing Well

This one is not about writing software well, it's about English. Despite its non-technical nature, I can't recommend it enough, especially for non-native English speakers. It not only introduces new vocabulary but also advise on how to tell good stories. It's so good so impactful that I'm considering a second read at some point.
[Find it on Amazon](https://www.amazon.com/Writing-Well-Classic-Guide-Nonfiction/dp/0060891548).

## 14 habits of highly productive developers

This is another book we can read in a week. It's a simple but great list of 14 habits. It includes tips  and great insights from FAANG+ developers on how to keep up with new techs, discussions about specialist or generalist paths, how to stay productive and not feel overwhelmed, and so on so forth. It's a must read for people starting in the software industry.
[Find it on Amazon](https://www.amazon.com/14-Habits-Highly-Productive-Developers-ebook/dp/B08BF74RRG).

2023 review: 4 Books I read last year


Eu escrevo este post da perspectiva de um desenvolvedor de software que tem aprendido bastante sobre processos e gestão de pessoas nos últimos anos, mas acredito que ele sirva para pessoas que trabalham em outras áreas, fora do mundo da tecnologia também. Afinal, nos últimos anos tudo tem acontecido de forma muito mais acelerada, e mais áreas tem dependência ou contato com alguma ferramenta da tecnologia exatamente pra acelerar processos. Com isso, o trabalho que faríamos em 8 horas, hoje fazemos em 6 ou menos, por exemplo.

No meu caso, utilizar assistentes inteligentes como o Github Copilot me ajuda bastante a “pular” aquela parte mais chata ou repetitiva que uma máquina consegue inferir facilmente, sem a necessidade de um ser humano digitar letra por letra. Também é possível encontrar a melhor palavra, expressão ou frase utilizando o ChatGPT, por exemplo. Tudo isso acelera o processo de desenvolvimento de uma determinada tarefa e nos torna tudo mais ágil.

## Se orgulhe

Com esse passo tão acelerado, acabamos esquecendo de muitas conquistas profissionais que tivemos durante nossa carreira, por simplesmente partir para a próxima demanda, tarefa, projeto ou empresa.

A verdade é que com um certo tempo de carreira, você provavelmente vai ter alguns projetos pra se orgulhar. Por isso, mesmo que sejam conquistas pequenas, vale a pena construir e manter um pequeno histórico pessoal (ou profissional), é quase como uma documentação privada da sua evolução profissional, pra você se orgulhar (ou se gabar 🥁🥁).

Se ainda não ficou claro ao que estou me referindo, deixa eu perguntar: o que aconteceu na ultima vez que seu chefe lhe convidou para uma avaliação semestral ou anual e perguntou quais os projetos ou entregas que você mais gostou de participar? Ou até você mesmo quis reunir as melhores entregas dos últimos 12 meses para tentar pedir uma promoção. Talvez, pra algumas pessoas, isso seja uma pergunta fácil de responder, não sei. Mas pra alguém com a memória fraca como a minha, essa pergunta é matadora. Pra mim, é inimaginável lembrar tudo o que fiz durante 6 meses, 1 ano, e ainda selecionar os itens mais interessantes e que eu gostaria de apresentar.

Tudo melhorou quando vi um [post do Elton Minetto](https://eltonminetto.dev/post/2022-04-14-brag-document/), e também um [artigo da Julia Evans](https://jvns.ca/blog/brag-documents/) (linkado no post do Elton) sobre como ter o seu trabalho reconhecido utilizando um Brag Document. Esses materiais me abriram muito os olhos, pois um documento como esse nos possibilita manter um histórico de fácil manutenção, e que vai nos servir independentemente da necessidade, seja para uma avaliação, para uma entrevista de emprego ou para resgatar um conhecimento específico sobre um determinado assunto.

## Brag document

Brag, em tradução livre, seria algo como “vangloriar-se”, “gabar-se” ou “envaidecer-se”. O intuito dele é manter um histórico de suas conquistas profissionais. Aqui listei alguns exemplos do que eu costumo adicionar ao meu:

- Entregas que me senti orgulhoso em fazer parte;
- Artigos e documentações que você escrevi;
- Sessões de mentoria que participei;
- Resoluções de incidentes que pude contribuir;
- Palestras ou cursos que apresentei;
- Lançamento de funcionalidades importantes;
- Soluções que propus e que geraram resultados positivos;
- O que mais você achar interessante.

Mas lembrando, esse documento é algo seu e não pertence à empresa ou time que você trabalha atualmente. Você pode (e deve) utilizá-lo durante cerimônias do seu dia-a-dia profissional, caso necessário. Mas ao começar em uma nova empresa, o seu Brag document continua o mesmo.

## Existe um modelo?

Como muitas outras práticas relacionadas a carreira, não existe algo escrito na pedra em relação ao brag document, mas vou compartilhar um modelo que eu tenho utilizado desde o começo do ano. Todos os itens abaixo são apenas para exemplo.

![Modelo de Brag Document](/assets/posts/brag-document-notion.png)

Nesse caso, estou utilizando o Notion, mas a ferramenta não deve ser um limitador pra você fazer a utilização do documento em si. Uma simples planilha no Notion ou Google Sheets já é suficiente.

## Quando devo atualizar?

Isso é muito pessoal e pode variar, dependendo do momento da sua carreira. Eu costumo separar **10 minutos a cada duas semanas** no meu calendário pra adicionar os itens que acredito que deveriam estar no meu Brag doc. Não é sempre que tenho atualizações, mas vou adaptando o meu tempo conforme a necessidade. Mas isso fica a seu critério, o importante é atualizar sempre que possível.


Brag Documents


Como desenvolvedores, nós temos algumas responsabilidades. Dentre elas, escrever código, estudar novas tecnologias, nos comunicar bem e etc. Além destas, existe uma característica que considero muito importante para um bom desenvolvedor de software, que é a habilidade de fazer um bom troubleshooting. Este nome pode ter diversos significados, mas aqui me refiro a resolução de problemas, sejam eles: bugs, problemas em versões candidatas ou até mesmo incidentes mais graves em produção.

Não importa o quão bom seu time seja, **incidentes e bugs em produção sempre irão acontecer,** e isso é um fato. Que eles são uma forma de aprendizado muito subestimados, também. Se você nunca teve um problema em produção, parabéns!
Ou talvez eu deva recomendar que você melhore seu monitoramento... 😅👀

A verdade é que ninguém gosta de estar responsável por resolver um incidente grave e que pode ter um impacto enorme para o projeto, mas estar *on-call*, ajuda você ganhar experiência, ao mesmo tempo que te ajuda a conhecer melhor o seu projeto.

Se você é uma pessoa desenvolvedora menos experiente, sem problemas. É importante que alguém mais experiente te auxilie durante os incidentes para resolver tais problemas.

## Cada caso é um caso

Com o desenvolvimento das ferramentas e tecnologias, bugs ficam mais complexos e difíceis de identificar e reproduzir.

Por isso, a sequência de passos neste post serve apenas como referência do que eu costumo fazer quando algo grave acontece em um sistema, de forma que a situação tenha o menor impacto possível.

Mas **nada impede que outras ações sejam tomadas**, dependendo do problema.

## 0. Documentação

Na verdade, este não deveria ser necessariamente um passo, mas pode acontecer durante todo esse processo que vou detalhar a seguir. É importante registrar as atualizações e descobertas durante todo o processo. De preferência, tudo deve adicionado a um documento de pós incidente (*post-mortem*).

Se você utiliza as ferramentas da Atlassian, você pode fazer uso de um template que é [disponibilizado no Confluence](https://www.atlassian.com/software/confluence/templates/incident-postmortem). Se você utiliza outra ferramenta, tudo bem. O importante é que o ocorrido esteja documentado.

Aqui é importante deixar claro:

- O que aconteceu;
- Quando aconteceu;
- E por quê aconteceu.

A ideia aqui não é encontrar culpados para o ocorrido, mas documentar tudo ajuda muito a evitar que o mesmo problema ocorra novamente. Muitas vezes, apontar nomes é interessante para documentar quem participou do processo.

## 1. Stop the bleeding!

O primeiro passo que costumo aplicar em um momento de incidente é tentar fazer com que o problema pare de ocorrer, ou fazer o que chamamos de parar o sangramento. Fazendo uma analogia com o mundo hospitalar, mesmo que o caso seja mais grave, esse é o momento de aplicar o curativo, não fazer uma cirurgia. Calma, que eu explico.

Muitas vezes a solução para conseguir parar o sangramento não vai ser a mais “bonita”. Ela pode incluir dar *rollback*, enviar um *hotfix* para produção, desligar a feature (caso utilize feature flags) ou balancear a carga para redirecionar usuários para outro grupo de servidores. Eu sei, como desenvolvedores queremos pensar na melhor solução logo de cara, a que vai resolver todos os nosso problemas, mas esse não é o momento. Nós teremos tempo pra isso.

Vale lembrar que no momento que a solução paliativa foi aplicada em produção, é importante que os *stakeholders* sejam comunicados.

## 2. Investigue e encontre a causa raiz

Pronto, agora você e seu time estão um pouco mais tranquilos para investigar o que realmente ocorreu, entender e documentar os detalhes do que levou o serviços a chegarem naquele incidente.

No mais, continue analisando logs, traces, e tente **reproduzir** o cenário.

Reproduzir um erro localmente ajuda a detectar a causa raiz do problema e propor uma solução mais rapidamente.

Outra forma de encontrar a causa raiz, é isolando o problema. Aqui cabe remover dependências, testar as credenciais utilizadas em outro servidor ou aplicativo, remover chamadas a APIs de terceiros, chamar métodos diretamente, aplicar a feature em um contexto isolado, e o que mais a sua criatividade sugerir.

Lembre-se de sempre adicionar a solução a documentação ou documento post-moretem.

## 3. Corrija o problema

Realize a correção, seguindo o processo que seu time utiliza (talvez você precise pular alguns passos aqui 😬), e adicione todos os outros itens que não são urgentes ao backlog para priorização.

Após a correção definitiva, faça questão de adicionar os detalhes a documentação criada no passo 0 e comunicar a todos os envolvidos. Com isso, todo mundo aprende e evita que o problema ocorra novamente.

Dessa forma, você não só resolve o problema imediato, mas também contribui para a melhoria contínua do sistema e do processo de troubleshooting.

## 4. Monitore a solução

Após realizar a correção do problema, é importante monitorar a solução implementada para garantir que a solução realmente corrigiu o problema. Isso envolve a análise contínua dos logs e métricas relevantes, além de acompanhar o desempenho do sistema e verificar se não há novos problemas surgindo.

É fundamental estabelecer alertas e notificações para identificar qualquer anomalia ou comportamento inesperado. Assim, será possível agir rapidamente caso ocorra algum incidente ou bug em produção novamente.

## 5. Follow-ups

Após a resolução do problema, é importante realizar follow-ups para garantir que o incidente não ocorra novamente. Follow-ups são aquelas tarefas que podem ser feitas para melhorar o processo como um todo, mas não necessariamente são parte da solução final.

Isso inclui verificar se as medidas corretivas foram eficazes, analisar se há necessidade de melhorias nos processos existentes, analisar se há necessidade de treinamento adicional para a equipe e implementar ações preventivas para evitar problemas semelhantes no futuro.

E aí, existe mais algum passo que você segue ao se deparar com um incidente em produção? Compartilha comigo.

Incidentes em produção -  Como realizar um bom troubleshooting?


Como já mencionei [aqui no blog](https://alison.dev.br/posts/como-fazer-um-e-mail-responsivo-template), criar templates de e-mail é como voltar aos anos 90. É necessário utilizar tabelas e outros recursos bem antigos do HTML, e a maioria dos cliente de e-mail não suportam propriedades CSS mais modernas.

Bom, estamos em 2023 e é hora de repaginar a criação de emails.

## React Email

Uma ferramenta muito interessante que me chamou a atenção e que tenho testado nos últimos meses é a [React Email](https://react.email/). Ela transforma totalmente o ambiente relatado no post que mencionei acima e nos traz para uma época que temos ferramentas poderosas como React e TypeScript.

O React Email nos traz uma série de componentes sem estilo para construir nossos e-mails utilizando React e TypeScript.

Para utilizar o React Email é bem simples:

### 1. Pacotes NPM:

Adicione os pacotes necessários ao seu projeto:

```shell
yarn add react-email @react-email/components -E
```

### 2. Scripts NPM:

Adicione os seguintes scripts ao seu `package.json`:

```json
{
  "scripts": {
    "emails:dev": "email dev",
    "emails:export": "email export",
  }
}
```

### 3. Criando o template:

Crie o seu template `.tsx` em uma pasta chamada `emails` utilizando a [documentação](https://react.email/docs/components/html):

```tsx
// Exemplo: ./emails/exemplo.tsx
import { Button } from '@react-email/button';
import { Html } from '@react-email/html';
import * as React from 'react';

export default function Email() {
  return (
    <Html>
      <Button
        pX={20}
        pY={12}
        href="https://example.com"
        style={{ background: '#000', color: '#fff' }}
      >
        Click me
      </Button>
    </Html>
  );
}
```

Se for necessário, você pode especificar outra pasta utilizando a flag `--dir` no comando `email`: `email dev --dir=another_folder`

### 4. Testando:

Execute o projeto localmente para visualizar as mudanças no seu template:

```shell
yarn emails:dev
```

### 5. Exportando o HTML:

Para exportar o HTML final, você pode executar o comando `export`:

```shell
yarn emails:export
```

Pronto, agora é so continuar enriquecendo o seu e-mail utilizando os componentes da própria documentação do React Email. 🎉

E-mails & React


O JavaScript é uma linguagem de programação bastante flexível e poderosa, permitindo realizar tarefas assíncronas de forma bem eficiente. Duas funcionalidades bem úteis nesse contexto são o `for await...of` e o `Promise.all`. Vamos entender como eles funcionam e como podem ser aplicados.

## for await...of

O `for await...of` é uma estrutura que nos permite iterar de forma assíncrona sobre uma coleção de elementos.
Isso é particularmente interessante quando estamos lidando com operações assíncronas, como requisições a APIs ou leitura de arquivos.

A sintaxe básica do `for await...of` é a seguinte:

```javascript
for await (const item of collection) {
  // `getFullURL`: função que se conecta a uma API para capturar a URL.
  const url = await getFullURL();
  return url;
}
```

Podemos utilizar essa estrutura em conjunto com arrays, para processar cada item de forma assíncrona.

## Promise.all

O `Promise.all` é um método que nos permite lidar com várias [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) ao mesmo tempo.
Ele recebe um array de promises e retorna uma nova promises. Essa promise é **resolvida** quando todas as promises do array forem resolvidas, ou **rejeitada** se ao menos uma delas for rejeitada.

A sintaxe básica do `Promise.all` é a seguinte:

```javascript
async function downloadFiles(urls) {
  // `downloadFileByURL`: função que retorna uma promessa de download de um arquivo
  const filesPromises = urls.map(url => downloadFileByURL(url));

  try {
    const files = await Promise.all(filesPromises);
    return files;
  } catch (erro) {
    // Error handling.
  }
}
```


`for await...of` vs `Promise.all` no JavaScript


Bom, o post de hoje é bem simples: como fechar o aplicativo GlobalProtect no macOS.

## Fechando o aplicativo

Se você já usa o aplicativo GlobalProtect no macOS, deve ter notato que não é possivel fechá-lo facilmente. Mesmo que você tente encerrar o processo pelo Activity Monitor, o aplicativo abre novamente de forma automática.

Por essa limitação, podemos executar o seguinte comando para encerrar o(s) processo(s) referente(s) ao GlobalProtect:

```bash
launchctl unload /Library/LaunchAgents/com.paloaltonetworks.gp.pangp*
```

## Reabrindo quando necessário

Se você precisar executar o aplicativo novamente, execute o comando `load`:

```bash
launchctl load /Library/LaunchAgents/com.paloaltonetworks.gp.pangp*
```

Se você utiliza o ZSH ou algum outro interpretador de linha de comando, você pode configurar esses comandos como alias para facilitar o liga/desliga no dia-a-dia.


Fechando o aplicativo GlobalProtect no macOS


Este post é sobre a utilização da biblioteca Wireit em conjunto com scripts NPM.

## NPM Scripts

NPM é um gerenciador de pacotes bem conhecido no mundo JavaScript. E através dele, conseguimos configurar scripts que nos ajudam durante o processo de desenvolvimento, testes e build das nossas aplicações.

Por exemplo, no arquivo `package.json` podemos definir uma série de comandos para build, execução e verificação de tipos:

```json
{
  "name": "testing-wireit"
  "scripts": {
    "build": "next build",
    "start": "next start",
    "typecheck": "tsc"
  },
  "dependencies": {
    "next": "latest",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
  }
}
```

Com isso, ao executar o comando `npm run build` o NPM irá não somente executar o comando equivalente, mas também irá executá-los utilizando as bibliotecas instaladas localmente no nosso projeto.

## Usando NPM Scripts com Wireit

[Wireit](https://github.com/google/wireit) é uma ferramenta do Google que roda em conjunto com os NPM scripts e torna esses scripts mais eficientes e inteligentes. Algumas features e vantagens do Wireit incluem:

- Utilizar os comandos `npm run` que você já conhece;
- Executa automaticamente as dependências entre os scripts NPM em paralelo;
- Assiste qualquer script e o executa continuamente em caso de alterações;
- Armazena os resultados em cache local e remoto
- Possui um plugin do VSCode que oferece sugestões, documentação e avisos enquanto você desenvolve novos scripts ou mantém scripts pré-existentes

Bom, com isso em mente, vamos para um exemplo prático. Após instalar o Wireit como dependência de desenvolvimento:

```bash
npm run install wireit -D
```

Podemos fazer algumas alterações no nosso `package.json` para utilizar o **Wireit** definitivamente no nosso projeto:

```json
{
  "name": "testing-wireit"
  "scripts": {
    "build": "wireit",
    "start": "wireit",
    "typecheck": "wireit"
  },
  "wireit": {
    "build": {
      "command": "next build",
    },
    "start": {
      "command": "next start",
      "dependencies": ["build"] # exemplo de dependencia entre scripts
    },
    "typecheck": {
      "command": "tsc"
    }
  },
  // ...
}
```

Após essas alterações, é possível utilizando meus scripts normalmente.

Não esqueça de adicionar a pasta gerada pelo wireit no seu arquivo `.gitignore`.

```bash
echo .wireit >> .gitignore
```

## Scripts em paralelo

O Wireit executa scripts em paralelo por padrão. Inicialmente, ele irá executar até 2 scripts por vez para cada core de CPU lógico detectado no seu sistema.
A quantidade desses scripts também irá depender do seu mapa de dependencias.

Se você necessitar configurar um numero diferente, ele disponibiliza a variável de ambiente `WIREIT_PARALLEL` para determinar o numero de scripts a serem executados em paralelo.

```json
export WIREIT_PARALLEL=4
```

Para entender mais sobre como rodar scripts NPM em paralelismo, veja a documentação oficial [aqui](https://github.com/google/wireit#parallelism).


NPM Scripts mais inteligentes


## Antes do Pull Request

Esse é um post sobre como criar Pull Requests melhores. Nele, pontuo algumas estratégias relativamente simples, que ajudam muito o seu time a colaborar de forma mais efetiva. Para esclarecer, Pull Requests também são conhecidos como Merge Requests em algumas ferramentas.

Antes mesmo de inciar a criação do seu Pull request, é importante ter algumas coisas em mente.

### Testes automatizados

Decidi deixar esse item como primeiro topico desta seção, pois acredito que ela é uma das coisas mais importantes e necessárias que compõem um bom PR.

Colaborar em um projeto com mais desenvolvedores pode se tornar algo muito complexo e desafiador, pois cada pessoa pode exergar o projeto de uma forma diferente, principalmente se a pessoa desenvolvedora acabou de chegar no seu time.

Além dos testes manuais, testes automatizados são uma forma de garantir que o seu código faz exatamente o que ele deveria fazer, e que essas funcionalidades permaneçam fazendo isso mesmo depois de diversas mudanças. Em códigos sem cobertura de testes, é comum nós alterarmos X e quebrar Y em produção, mesmo que em teoria, essas features nem se conectem. Se você já trabalhou em projetos sem testes, deve saber do que eu estou falando.

### Commits

Algumas equipes criam diretrizes para mensagens de commit, mas este tópico nem é sobre isso. Eu criei ele neste post para te lembrar de criar bons commits, que mantenham um histórico das suas mudanças e com mensagens que descrevam tais mudanças.
Commits são tão importantes quanto o Pull Request em si. Se você tiver interesse em melhorar suas mensagens de commit, eu recomendo esse [artigo](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/).

### O que deve conter em um PR

Solucione um problema por vez. Se você estiver solucionando uma feature, limite o escopo da mesma, pois isso facilitará a revisão e o histórico de mudanças ficará mais claro.

### Diretrizes

É provavel que sua equipe tenha configurado tarefas automatizadas para verificar testes, lint, tipos estáticos, mensagens de commit e outros parâmetros para garantir a qualidade de código do projeto, e claro, manter o mesmo mais organizado.
Por isso, se possível, tente executar os processos de verificação de qualidade antes de executar `git push`. Mas não se preocupe, se você esquecer, a Pipeline _irá_ avisar.

## Tamanho do Pull Request

Muito se questiona sobre o tamanho ideal para um Pull request, mas a verdade, é que **depente** (como muitos assuntos no desenvolvimento de software).

![Tweet da conta I'm a developer](/assets/posts/iam-a-developer-code-review.png)

Você pode ter estratégias diferentes de acordo com o tamanho e nível de maturidade do seu time, ou até com as tecnologias que vocês utilizam.
Mas gostaria de adicionar um link para esse [artigo](https://smallbusinessprogramming.com/optimal-pull-request-size/), que explica o tamanho ideal para PRs e menciona alguns estudos a respeito desse tema.

![Gráfico mostrando relaçao entre tamanho do PR e tempo de revisão](/assets/posts/pr-size-and-review-time.png)

Em resumo, esse artigo sugere que algo em torno de 250 LOC seria o ideal para um Pull Request. Lembrando que, de forma alguma isso deve ser uma regra super restrita, pois sabemos que cada caso pode necessitar de uma estratégia diferente.

## Revisando seu próprio PR

É comum testarmos diversas possibilidades para solucionar um problema durante o processo de desenvolvimento de uma aplicação.
Adicionamos arquivos, escrevemos testes que, no fim, não fazem mais tanto sentido. Muitas vezes, até criamos soluções que poderiam ser bem mais simples.

Aantes de criar o seu Pull Request, realize um processo de revisão nele, mesmo que seja uma revisão super rápida.
Desta forma, previnimos mudanças indesejadas e arquivos desnecessários. Caso essas mudanças desnecessárias existam, podemos ajustá-las antes de nossos colegas as capturarem.

Após revisar seu PR, se você visualizar algum ponto do código que possa ser confuso para outros desenvolvedores, você pode adicionar comentários que possam facilitar a revisão, por exemplo:

- Este componente está sendo exportado pois precisamos dele nos testes automatizados;
- Este código não foi removido, ele só foi movido para outro componente, veja o Component.tsx.

## Titulo, Descrição e Referências

O seu PR deve conter um título auto-explicativo. Já a descrição deve deixar claro o foi alterado no seu projeto, e deve possibilitar outros desenvolvedores revisarem e testarem suas mudanças.

**Exemplos de títulos:**

- Adiciona casos de teste para o método X;
- Adiciona melhorias no gerenciamento de erro na criação de usuários com avatar.

Além disso, aqui está um ótimo [exemplo](https://github.com/rails/rails/pull/32865) de um excelente titulo e descrição em um projeto real.

Para mais, adicionar links para tarefas, outros PRs e issues é muito útil para facilitar a revisão e referências futuras, além de ajudar seu PR a ser aceito mais rapidamente.


Bons Pull Requests para Code reviews ainda melhores


Recentemente completei 28 anos de idade, e destes muitos foram dedicados a tecnologia e desenvolvimento de software.

Por isso, decidi refazer este site, mas mantendo todos os posts antigos, até para deixar parte do meu aprendizado documentado.

Para dar os devidos créditos, estou usando um [blog starter](https://github.com/zeit/next.js/tree/canary/examples/blog-starter) da Vercel. Além dos ajustes de design, adicionei suporte à [MDX](https://mdxjs.com/) e algumas coisinhas mais.

Se você tem interesse em ver mais detalhes do código, ele continua sendo atualizado no meu [Github](https://github.com/alisonmonteiro/blog).

É isso, nos vemos em breve 👋

Novo blog


Além de falar sobre coisas aleatórias relacionadas a desenvolvimento de software, neste blog eu também vou documentar um pouco da minha tragetória como desenvolvedor.

Uma das coisas que mais gosto de fazer, é compartilhar conhecimento, e uma das formas mais interessantes e desafiadoras de fazer isso é através de palestras. Eu já realizei algumas, mas esta foi a primeira depois da pandemia.

## Github Community Fortaleza

Vou deixar tanto o Twitter quanto o Instagram do Github Community Fortaleza, para quem quiser conhecer mais sobre o projeto:

- [Twitter](https://twitter.com/ghcfortaleza)
- [Instagram](https://www.instagram.com/ghcfortaleza/)

## Palestra

A ideia era falar um pouco de cada tecnologia, começando pelo básico do Typescript, passando pelo TailwindCSS e finalizando com o Next.js.
Caso você não conheça alguma dessas ferramentas, deixarei os links para as documentações oficiais:

- [Typescript](https://www.typescriptlang.org/)
- [TailwindCSS](https://tailwindcss.com/)
- [Next.js](https://nextjs.org/)

Quando falei do Next.js, a principal ideia era mostrar a simplicidade e o quão poderoso ele pode se tornar, além de mostrar as suas abordagens para criar aplicações, usando SSR, SSG, ISR, etc.

![Palestra](/assets/posts/palestra-alison-monteiro-github-fortaleza.jpg)

Por fim, mostrei um projeto real, que consome a API do próprio [Github](https://github.com/), e utiliza as tecnologias que citei acima.
Esse projeto além de ter sido construido, também foi apresentado utilizando o [Github Codespaces](https://github.com/features/codespaces).

Palestra sobre front-end no Github Community Fortaleza, na Digital College


I'm a huge fan of [CSS](https://en.wikipedia.org/wiki/CSS). I've been working with it for a few years, and I'm still learning it every day.

Today I learned that we can use multiple backgrounds on a single element with CSS. It is possible because the `background` property is [specified](https://developer.mozilla.org/en-US/docs/Web/CSS/background#try_it) as one or more background layers, separated by commas.

## Multiple backgrounds

With multiple backgrounds, we can achieve exciting effects using only CSS. See an example in the demo below.

![Background image by Andrea De Santis, on Unsplash.](/assets/posts/til-css-multiple-backgrounds.gif)

Background image by Andrea De Santis, on Unsplash.

Also, here's the CSS code that I used to create the demo above:

```css
.rocket {
    background:
      url('/icon.png') no-repeat center 80%,
      url('/image.png') no-repeat center center;
    transition: background-position 1s;
    background-size: 50px, 100%;
    width: 400px;
    height: 400px;
}

.rocket:hover{
    background-position: center 10%, center;
}
```

And the HTML:

```html
<div class="rocket"></div>
```

Pretty cool, huh?

## A11y:

Sadly, most browsers don't provide information on background images to assistive technology - such as screen readers. If the element you're creating contains any essential information about the page, you should consider describing it semantically in the document. See more [here](https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable#guideline_1.1_%e2%80%94_providing_text_alternatives_for_non-text_content).


TIL: CSS multiple backgrounds


Next.js é um dos frameworks mais utilizados no ecossistema React. E uma das features que acho mais mais interessante é a forma que ele trata requisição de dados - imagino que pelo título do post, deu pra perceber que vamos falar disso, certo?

Em aplicações web modernas, podemos lidar com requisições de dados de algumas formas diferentes, mas hoje vamos focar em duas específicas: **SSR** e **SSG**.

## O que são SSR e SSG?

### SSR

**SSR (*Server Side Rendering*)**, ou Renderização do Lado do Servidor vem para solucionar um pouco dos problemas das aplicações [SPAs](https://en.wikipedia.org/wiki/Single-page_application), mantendo suas principais vantagens. O SSR inverte o processo de renderização das SPAs, trazendo parte do esforço de renderização de aplicações  para o servidor.

Com isso, a abordagem de utilizar SSR pode fornecer aos usuários uma experiência muito melhor e um tempo de carregamento bem mais eficiente, já que parte da renderização de cada requisição é feita no servidor. Com isso, o SSR também nos ajuda a lidar com problemas de SEO.

### SSG

Por outro lado, o **SSG (*Static Site Generation*)**, ou Geração de Site estático, vem para tentar simplificar alguns casos em que o SSR acaba sobrecarregando servidores de forma desnecessária. Ao invés de renderizarmos as requisições no lado do servidor, o conteúdo da aplicação é gerado de forma estática antes de ser enviado para o servidor. Esse processo pode ser feito por ferramentas conhecidas como [Static Site Generators](https://www.cloudflare.com/learning/performance/static-site-generator/).

Então, após as páginas serem geradas, podemos usar qualquer serviço de hospedagem de páginas estáticas e servir nossa aplicação através de [CDN](https://www.fastly.com/blog/why-you-should-use-content-delivery-network) - tornando nossa aplicação mais segura, mais rápida e mais escalável. Além da possibilidade de reduzir os custos com servidores.

## SSR e SSG no Next.js

No [Next.js](https://nextjs.org/), a forma que você faz as requisições dos dados na sua aplicação, define a forma que o conteúdo será servido para os usuários.

### SSR

Se você exportar a função `getServerSideProps` em uma página, o Next.js vai renderizá-la no servidor em cada nova requisição.

```jsx
function Page({ user }) {
  return <div>Username: {user.name}</div>
}

export async function getServerSideProps(context) {
  const user = { /* requested data */ }

  return {
    props: {
      user
    },
  }
}

export default Page
```

### SSG

Por outro lado, se você exportar uma função chamada `getStaticProps`, o Next.js vai pré-renderizar sua página no momento de *build* - normalmente quando você envia alterações para o seu projeto (via Git, por exemplo).

Como os dados serão gerados antes dos usuários acessarem a página, os dados renderizados nesta página serão os mesmos para todos os usuários que acessarem a aplicação. Por isso, esse tipo de estratégia é utilizada para conteúdos que podem ser compartilhados, guardados em cache e pré-renderizados, como posts de blog.

```jsx
function Page({ post }) {
  return <div>Title: {post.name}</div>
}

export async function getStaticProps(context) {
  const post = { /* requested data */ }

  return {
    props: {
      post
    },
  }
}

export default Page
```

Você também pode utilizar o React hook [SWR](https://swr.vercel.app/), criado pelo time do Next.js. Se você precisa requisitar dados no browser (client-side), ele é muito recomendado. Ele vai manter os dados em cache, e vai atualizá-los assim que que esses dados estiverem obsoletos.

```jsx
import useSWR from 'swr'

const fetcher = (...args) => {
  return fetch(...args)
    .then((res) => res.json())
}

function Page() {
  const { user, error } = useSWR('/api/user', fetcher)

  if (error) return <>Error</>
  if (!user) return <>Loading...</>

  return <>Username: {user.name}</>
}
```

Referências: [1](https://nextjs.org/docs/basic-features/data-fetching/overview), [2](https://andrei-calazans.come/posts/2021-05-06/next-js-when-to-use-get-server-side-props), [3](https://swr.vercel.app/).


Data fetching: SSR e SSG no Next.js


Há alguns anos eu comecei a estudar [Go](https://golang.org/), uma linguagem open-source, focada em alto desempenho, desenvolvida pelo Google e que tem uma syntaxe bem próxima da linguagem C.

Meus estudos se limitaram a projetos pessoais (que posso demonstrar aqui em breve) e muitos testes, mas algumas coisas que aprendi enquanto estava estudando, me fizeram mudar um pouco a forma que eu vejo e escrevo software.

Os pontos que irei detalhar nesta série de posts são algumas das features mais comuns da linguagem, e podem parecer bem simples, mas se bem utilizados - até em outras linguagens, podem deixar o seu código muito mais fácil de ler e manter.

## Retornos múltiplos

Esta feature não é nenhuma novidade pra quem já programou em Python, por exemplo. Mas isso nos possibilita ter acesso a várias abordagens e várias formas de implementação de novos recursos.

Um dos mais conhecidos, e até adotado como convenção pela linguagem é o gerenciamento de erros, através do pacote `errors`.

No exemplo a seguir, mostramos como seria o retorno múltiplo de valores em uma função, e a forma de gerenciar erros em Go.

```go
package main

import (
	"errors"
	"fmt"
)

func greaterThanTen(number int) (bool, error) {
	if number > 10 {
		return true, nil
	}

	return false, errors.New("The number is not greater than 10")
}

func main() {
	isntGreaterThanTen, err := greaterThanTen(5)
	isGreaterThanTen, err2 := greaterThanTen(15)

	fmt.Println(isntGreaterThanTen, err) // => false, The number is not greater than 10
	fmt.Println(isGreaterThanTen, err2)  // => true, nil
}
```

Para desconsiderar algum dos múltiplos parâmetros, você pode utilizar o `_`, já que em Go, você não pode declarar um variável e não utilizá-la - isso geraria um erro de compilação.

```go
...

func main() {
	isGreaterThanTen, _ := isGraterThanTen(15)
	fmt.Println(isGreaterThanTen)  // => true
}
```


Go: Múltiplos Valores de Retorno


[Git](https://en.wikipedia.org/wiki/Git), é um sistema de controle de versão moderno criado por [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds), mesmo criador do Linux Kernel. O Git é uma das ferrementas de código aberto mais utilizadas pelos programadores, sendo responsável por manter registradas quaisquer alterações a um determinado projeto. Com isso, permitindo que seja possível, comparar diferentes versões, avançar ou regredir no histórico de versões deste mesmo projeto, e muitas outras tarefas.

Se você ainda não entende muito bem o que é e como funciona o Git, mas gostaria de aprender, recomendo [este artigo](https://www.atlassian.com/br/git/tutorials/what-is-git). Além disso, tenho alguns outros artigos, que escrevi há algum tempo aqui no blog sobre o assunto:

- [[PT] Como listar os autores do seu projeto pela linha de comando](https://alison.dev.br/posts/list-your-projects-git-authors-command-line)
- [[EN] Lembrete: se necessário, utilize --force-with-lease](https://alison.dev.br/posts/reminder-force-with-lease)

<br />

## O que é o Git Cherry Pick, e como mover pequenos pedaços de código entre branches?

O `cherry-pick` é um dos comandos do **git** que nos permite levar partes específicas da nossa árvore de commits para uma branch desejada.

Lembrando que o `cherry-pick` é um comando muito útil, quando bem utilizado. Porém, ele não pode substituir o git merge e o git rebase, por exemplo. Cada um possui uma situação que se encaixa melhor. Use o cherry-pick apenas em último caso, com cuidado para não duplicar commits na sua linha do tempo, de forma desnecessária. **Use com moderação**!

### Então vamos para o exemplo:

O exemplo mais simples que eu posso trazer para representar a ideia do cherry-pick é o de levar alterações que estão em uma branch específica para a branch de produção (`main`, neste caso), sem afetar outras branches pré-prod.

![Grafico 1 - Exemplo prático do comando git cherry-pick.](/assets/posts/git-cherry-pick-o-que-e-como-usar.png)
<small>Grafico 1 - Exemplo prático do comando git cherry-pick.</small>

---

Para melhor entendimento, neste exemplo temos 2 features e 1 hotfix no nosso ambiente de `testing/qa`, onde:

- uma das features contém um bug (linha vermelha), e outra está aprovada (linha verde).
- o hotfix corrige um bug em `staging` antes de tudo ir pra `main` (produção).

Considerando que já temos vários commits em `staging` e mais alguns em `testing/qa`, como podemos fazer para enviar o ajuste para `staging`, e então realizar o merge `staging` -> `main`, sem enviar tudo que temos de divergente na branch `testing/qa`?
Além disso, manter o fluxo de integração, com nossa branch `hotfix-1` sendo enviada para `testing/qa` normalmente e sem conflitos?

Bom, para resolver esse problema, podemos usar o commando `cherry-pick`. Ele vai nos ajudar, seguindo exatamente o que a linha azul do nosso gráfico 1 representa.

Para resolver o passo 2, podemos seguir o fluxo normalmente. Nenhuma alteração é necessária, e com isto vamos manter nossas branches sincronizadas com o contéudo do cherry-pick.

## Como executar o comando git cherry-pick?

O cherry-pick, pode ser feito tanto por command line quanto por interface gráfica.

### Interface Gráfica

A maioria dos gerenciadores de repositórios git (Gitlab, Github, etc) já incluem uma opção de cherry-pick por padrão em cada Pull (ou Merge) Request.

- [Como utilizar cherry-pick no Gitlab](https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html)
- [Como utilizar cherry-pick no Github](https://docs.github.com/pt/desktop/contributing-and-collaborating-using-github-desktop/managing-commits/cherry-picking-a-commit)

### Cherry-pick localmente por linha de comando

Para realizar esta ação por linha de comando, primeiro você deve ir para a branch que você quer levar para a branch alvo e exibir o identificador do ultimo commit que você deseja integrar.

```shell
git checkout hotfix-1
git rev-parse HEAD
//=> Ex.: 851a2508b93007e145b132dae2c69a7165734a8a
```

Com o resultado acima, podemos realizar navegar até a nossa branch alvo e realizar o cherry-pick:

```shell
git checkout stagig
git cherry-pick 851a2508b93007e145b132dae2c69a7165734a8a
```

Pronto! Simples assim.


Git: O que é e como usar o Git Cherry Pick?


<figure>
    <img src="https://images.unsplash.com/photo-1505238680356-667803448bb6?ixlib=rb-1.2.1&q=85&fm=jpg&crop=entropy&w=800" alt="Code" />
</figure>

Um dos recursos que eu mais utilizo no ES6+ hoje em dia é [Desestruturação de objetos](https://javascript.info/destructuring-assignment#object-destructuring).

Existem diversas formas de fazer bom uso dessa feature tão versátil. Porém, é bom tomar um certo cuidado para não abusar das possibilidades e acabar deixando o código mais complexo e difícil de ler do que deveria.

Hoje, vamos falar sobre a atribuição de valores padrão na **desestruturação de objetos**, uma das diversas possibilidades dessa feature do JavaScript.

## Desestruturação de Objetos

```jsx
const person = {
	name: 'Alison',
	age: 25,
	cool: true,
}

// ...

const { name, age } = person
console.log(name) // => Alison
console.log(age)  // => 25
```

O exemplo acima mostra a definição de um objeto `person` e atribuição dos valores das propriedades desse objeto a duas variáveis distintas.

Uma pergunta que pode vir a mente quando vemos um código como esse é: e se, em códigos similares a este ou até mais complexos, a propriedade utilizada na desestruturação não existir?

```jsx
const person = {
	name: 'Alison',
}

// ...

const { name, cool } = person
console.log(cool)  // => ?
```

Bom, nesse caso, o output seria `undefined`, pois estamos criando a variável, mas a desestruturação não conseguiu atribuir nenhum valor a mesma.

Podemos, portanto, atribuir um valor padrão as propriedades que queremos capturar, pro caso de elas não existirem no objeto em questão.

## Valores padrão para propriedades de um objeto

```jsx
const person = {
	name: 'Alison',
}

// ...

const { name, cool = 'Yes' } = person
console.log(cool)  // => Yes
```

E aí, curtiu? Espero que sim. Esse tipo de detalhe pode ajudar bastante na legibilidade do nosso código, além de ser muito flexível, já que aceita até **chamada de funções** como valor padrão.

Definindo valores padrão para propriedades - Desestruturando Objetos Javascript


If you are working on a project and need to release often, you might need some automated scripts/commands to help you with the day-to-day tasks.

This tiny article is about one of these commands: **List your git project contributors.**

## Give credit to people

When working on an open-source project, it's important to give credit to all the people who contribute to it.

To get the list of authors, we can run:

```jsx
git log --all --format="%aN" | sort -u
```

Remember to add `| sort -u` to your log command. If you don't do it, the output will show the same author a bunch of times. Unless you want that, add the sort command to your pipe.

If you want to add the e-mails to the list, you can run:

```jsx
git log --all --format="%aN <%aE>" | sort -u
```


List your git authors via command line


O Parameter Store é um recurso do **AWS Systems Manager**, serviço da AWS que nos oferece armazenamento tanto de texto simples, quanto de dados secretos, como senhas e chaves privadas. Com isso, podemos transformar variáveis de ambiente do seu projeto em dados armazenados em um ambiente mais controlado, que se comunica com outros serviços, com controle de acesso de usuários, e se preferir, [criptografado](https://aws.amazon.com/pt/kms/). Com o **Parameter Store** você consegue organizar suas variáveis de ambientes de forma hierárquica, baseada nos seus stages e tags.

**Nota:** Se você utiliza o [Terraform](https://www.terraform.io/) como ferramenta para gerenciamento da sua infraestrutura, a [documentação](https://www.terraform.io/docs/providers/aws/r/ssm_parameter.html) mostra como criar este recurso.

### Criando seu Parâmetro

![Criando parametro](/assets/posts/criando-parametro-aws-param-store.png)

Ao clicar em "Create Parameter", você deve ser redirecionado para listagem e ver o seu parâmetro criado.

![Lista de parametros](/assets/posts/lista-parametros-aws-param-store.png)

## Capturando parâmetros

Para utilizar variáveis armazenadas dentro do SSM Parameter Store, você pode utilizar o SDK da AWS na linguagem de sua preferência.

```jsx
const ssm = new AWS.SSM()
ssm.getParametersByPath(params, (err, data) => {
  if (!err) {
    return data
  }

  console.error(err)
  return
})
```

Para este exemplo, estamos utilizando NodeJS. Veja a lista de ferramentas e SDKs da AWS [neste link](https://aws.amazon.com/tools/).

## Integrando com o ECS

Além de conectar diretamente com a sua aplicação utilizando o Software Development Kit (SDK), você também pode capturar parâmetros dentro de outros serviços da AWS como o Elastic Container Service ou ECS.

Comumente, você deve utilizar **variáveis de ambiente** de texto simples dentro da sua Task Definition. A única coisa que muda é que no lugar de usar algo como

```jsx
...
"environment": [
  {
    "name": "DATABASE_USERNAME",
    "value": "main_user"
  }
]
...
```

A sua Task Definition vai ser algo mais parecido com isto:

```json
{
  ...
  "executionRoleArn": "",
  "containerDefinitions": [
    {
      "name": "",
      "image": "",
      ...
      "environment": [
        {
          "name": "DATABASE_USERNAME",
          "valueFrom": "/stg/database-user"
        }
      ],
      "secrets": [
        {
          "name": "DATABASE_PASS",
          "valueFrom": "/stg/database-password"
        }
      ],
      ...
    }
  ]
  ...
}
```

Lembre-se de que sua `executionRoleArn` deve ser configurado para permitir a comunicação entre o ECS e o SSM. Veja na [documentação oficial da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html#task-execution-secrets) como criar tal *Role*.

Pronto, agora você poderá capturar suas variáveis do Parameter Store como variáveis de ambiente na sua aplicação, sem necessidade de utilizar o SDK.

**Referências:** [1](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html), [2](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/SSM.html), [3](https://aws.amazon.com/pt/systems-manager/features/?nc1=h_ls).


Utilizando o System Manager para armazenar variáveis de ambiente dos seus Containers na AWS



Este post é sobre um caso de uso bem específico, mas realmente espero que ajude alguém, ou ajude a mim mesmo, em um futuro não tão distante. E, por ser específico, vou entar representar de forma simples o problema e o que me levou a solucionar o mesmo.

## Multiplas aplicações no Elastic Load Balancer?

Bom, em um certo experimento, eu estava tentando compartilhar o mesmo **Elastic Load Balancer** para multiplos domínios que, no fim das contas, levavam para a mesma aplicação. O fluxo era mais ou menos assim:

```md
shoes.com -------|
                 |
cars.com --------|---- Load Balancer ---- EC2 Instances
                 |
clothes.com -----|
```

Todos os domínios já estavam utilizando **certificados SSL,** criados a partir do **Amazon Certificate Manager**. Isso pode parecer um experimento legítimo e tudo funcionou muito bem, até que eu precisei **adicionar um novo domínio** a esta rede que eu havia criado anteriormente.

## Registro de domínio no Route 53

Após solicitar o certificado no **Certificate Manager** e registrar os Record Sets no **Route 53** - tudo que deve ser feito para adicionar um novo domínio com SSL na AWS, algo parecia não estar certo: na lista de domínios, o novo estava sempre como "**In use? No**", como podemos ver na imagem a seguir:

![Certificados no Amazon Certificate Manager](/assets/posts/in-use-no-dominios-aws-acm-com-elastic-load-balancer-certificates.png)

Bom, esse simples detalhe me tomou algumas poucas horas de pesquisa. Passei e repassei todos os detalhes da criação do domínio e requisição do certificado para confirmar que tudo estava certo, mas só no momento em que eu **conferi cada passo** que levava o meu domínio à minha instância EC2, que eu descobri o problema.

## A Solução

Em cada Elastic Load Balancer, você provavelmente terá um ou mais "Listeners", que levará ao seu Target Group. Você também pode redirecionar uma porta específica para outro recurso ou até configurar uma resposta fixa. Mas para este exemplo, vamos considerar que você configurou um apontamento para o seu Target Group.

![Configuração do Listener no Elastic Load Balancer](/assets/posts/in-use-no-dominios-aws-acm-com-elastic-load-balancer-listener.png)

Cada Listener a ser apontado para portas que necessitam de [conexão segura (HTTPS)](https://pt.wikipedia.org/wiki/Lista_de_portas_dos_protocolos_TCP_e_UDP), deverá ter, pelo menos, um certificado SSL configurado como padrão. Caso o seu Load Balancer permita-se receber requisições de multiplos domínios (que é o nosso caso aqui), você precisará habilitar cada novo certificado nas configurações do Listener.

Para habilitar um novo certificado no seu Load Balancer você precisa seguir alguns passos, vamos começar pelo serviço **EC2**:

- Clique em "Load Balancers", no canto inferior esquerdo;
- Selecione o seu ELB e clique na aba **Listeners**;
- Então, caso você tenha uma porta com conexão segura configurada, clique em **View/edit certificates**;
- Clique no ícone **+**, no canto superior esquerdo.

![Configuração do Listener no Elastic Load Balancer](/assets/posts/in-use-no-dominios-aws-acm-com-elastic-load-balancer-listener-certificate.png)

Pronto, em alguns minutos o seu **Certificado SSL** ficará com o status "**In use? Yes**"!


"In use? No" - Domínios não reconhecidos pelo ACM em conjunto com Elastic Load Balancer.


Atualmente, navegadores modernos dispõem de uma API, exposta através do construtor [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams), que nos ajuda a trabalhar com o que chamamos de `search params`. Hoje, vamos utilizar esta ferramenta para entender como **capturar parâmetros da URL** de forma simples utilizando **Vanilla JS**.

Digamos que você está desenvolvendo um **software de distribuição anúncios**. Neste projeto, o usuário irá acessar uma URL, e baseados na mesma, iremos distribuir apenas os anúncios de um cliente específico.

Levando em consideraçao que neste caso, o dado que define um cliente na nossa URL é o parâmetro `client`, como fariamos para capturar o dado identificador na URL abaixo?

```html
https://ad.io/?i=3s7d1&client=ejhe7a61c52nr2f
```

Como mencionei acima, temos um construtor que nos ajuda a transformar os dados do `search` em **objeto nativo do JavaScript**. Vejamos o exemplo abaixo:

```js
const { search } = window.location;
const params = new URLSearchParams(search);
const clientId = params.get('client'); // => ejhe7a61c52nr2f
```

Neste exemplo, o resultado na variável `clientId` seria `ejhe7a61c52nr2f`. O método `get` retorna o primeiro valor associado a chave passada como parâmetro.

Lembrando as chaves do objeto `URLSearchParams` são case sensitive. Ou seja, caso eu tentasse capturar o parâmetro `Client` da URL acima, o resultado seria `null`.

Para mais informações sobre o construtor &&URLSearchParams**, e como capturar parâmetros da URL usando JavaScript, clique [aqui](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams).


Capturando parâmetros da URL com JavaScript


Infelizmente, ainda é muito comum acontecer certos problemas com os ambientes mais importantes de um projeto (leia-se beta, prod), pois mesmo que a equipe tenha boas intenções, de manter o fluxo de desenvolvimento mais dinâmico e otimizado, acaba pecando em alguns detalhes que fazem bastante diferença.

Quem nunca ouviu aquela velha história do(a) estagiário(a) ou da pessoa desenvolvedora menos experiente que acabou fazendo um `UPDATE` sem adicionar uma cláusula `WHERE`? Bom, para quem trabalha com banco de dados relacionais, isso é bem mais comum do que a gente imagina. Nos dias de hoje, com a maioria dos projetos já utilizando um software de controle de versão 🙏, muitas vezes o famoso "**update sem where**" toma novas formas.

<figure>
  <img src="https://images.unsplash.com/photo-1521675333836-36e707ac1d20?ixlib=rb-1.2.1&w=1000&q=85&fm=jpg&crop=entropy&cs=srgb" alt="Git Branches" />
  <figcaption>Photo via Unsplash</figcaption>
</figure>

Se você ainda não utiliza um software de controle de versão no seu projeto, recomendo fortemente você começar por este [link aqui](https://git-scm.com/book/pt-br/v2).

Há uma certa divergência entre **desenvolvedores de software** em relação a forma de integrar as alterações de uma branch em outra. Uma parte acredita que a melhor forma seja o [rebase, mas outros acreditam que seja o merge](https://www.atlassian.com/git/tutorials/merging-vs-rebasing). Os dois, no fim das contas, resolvem o mesmo problema.

Independente de qual abordagem você e sua equipe utilizam - e há algumas que utilizam as duas ao mesmo tempo, é importante temtar manter o ambiente o mais controlado e bem definido possível.

Pessoas desenvolvedoras que estão começando a carreira, tendem a repetir os passos que os seus mentores ou programadores mais experientes fazem ao tentar resolver um problema. Então, se um(a) estagiário(a) pedir ajuda para atualizar a mensagem de um commit, que já está na branch remota, provavelmente você irá atualizar a mensagem e fazer um [`push --force-with-lease`](https://alison.dev.br/posts/reminder-force-with-lease). Nesse momento, é importante que a pessoa desenvolvedora entenda exatamente o que foi feito, para que não tente reescrever o histórico de uma branch importante. Pois isso, pode acarretar a atualização de um ambiente crítico, após ativar uma pipeline de deployment, por exemplo.

Utilizei um exemplo que utiliza o merge como forma de integrar as alterações, mas o mesmo se aplica ao rebase.

Para evitar que esse tipo de problema mais sério aconteça, é importante que suas branches críticas sejam protegidas contra merges de pessoas desenvolvedoras menos experientes, ou contra merge requests que não tenham recebido uma quantidade de aprovações suficientes, por exemplo. Esse tipo de permissão é facilmente customizável na maioria das ferramentas de gerenciamento de código GIT.

A ideia de ter branches com permissões restritivas para pessoas desenvolvedoras menos experientes, é a mesma de ter permissões restritivas para os banco de dados dos ambientes mais críticos, onde mesmo que o update sem where aconteça, que seja em um ambiente controlado, assim como um `push —force-with-lease`.

Este é o "update sem where" dos dias atuais



Anteriormente, aqui no blog, fiz uma postagem sobre como resolver um erro bem comum na integração de um EFS e instâncias EC2 privadas. Se você ainda não viu, vale a pena conferir. 😜 [Clique aqui](/posts/efs-error-failed-to-resolve-server-name-or-service-not-known). Hoje, também iremos falar do EFS, mas sobre como a utilização desse serviço pode se tornar um problema em alguns contextos.

## O que é o EFS?

EFS é um dos serviços que a AWS nos oferece, e se destaca por ser, basicamente, um File System NFS na nuvem de baixíssimo custo. Ele foi criado com o intuito de fornecer acesso compartilhado e paralelo para até milhares de instâncias EC2, permitindo que sua aplicação forneça alto nível em taxa de transferência com **baixa latência**.

Se eu consigo ter um volume de arquivos compartilhados em múltiplas instâncias EC2, isso quer dizer que eu posso ter um bloco específico de código compartilhado entre todas elas? Bom, não é bem isso. O serviço deixa alguns pontos não tão claros na sua landing page de apresentação, mas se olharmos um pouco mais a fundo a [documentação oficial](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), iremos encontrar alguns detalhes bem interessante. Por enquanto, iremos focar em uma bem específica: a latência.

## Latência

Latência, quando falamos em redes de computadores, é o tempo que que leva para os pacotes percorrerem o caminho entre o ponto X e o Y. Quanto mais alta a latência, mas tempo a transmissão demora para ocorrer.

Como sabemos, na internet cada milésimo de segundo conta. E no EFS o modo de entrega, e a limitação dos recursos são um pouco diferentes do que nós já estamos acostumados em outros serviços da AWS, veja a tabela abaixo:

![Comportamento de intermitência para sistemas de arquivos no EFS](/assets/posts/latencia-ao-utilizar-o-aws-elastic-file-system-efs-table.png)

Veja mais detalhes na [documentação sobre perfomance do EFS](https://docs.aws.amazon.com/efs/latest/ug/performance.html).

### Créditos de intermitência acumulada

A AWS usa um sistema de créditos no EFS para determinar quando o File system vai "explodir", que é determinado pelo tamanho dos arquivos, pela quantidade de arquivos, e pelo tempo que esses arquivos ficam "parados" no seu sistema de arquivos.

Quanto maior o tamanho dos seus arquivos e menos você utilizá-los, mais créditos você terá, e mais rápidos seus arquivos serão entregues as instâncias que compartilham o sistema de arquivos.

Ou seja, é muito mais barato, em latência, ter 2 arquivos de 1 GB cada, do que ter 50 arquivos de 1KB cada. Veja mais detalhes [neste post](https://www.jeffgeerling.com/blog/2018/getting-best-performance-out-amazon-efs).


Latência ao utilizar o AWS Elastic File System (EFS)


You open your computer to finish a task and see a red triangle at the top-right of your screen with the following message:

> The update information is outdated. This may be caused by network problems or by a repository that is no longer available. Please update manually by selecting ‘Show updates’ from indicator menu, and watching for any failing repositories.

Since this blog is about the experiences that I get and the problems I solve being a Web Developer, let me help you fix one more problem.

## The problem

Well, the reason for the alert shows is described in the error message: "This may be caused by network problems or by a repository that is no longer available". There are no reasons to be worried, though.

## How to solve

While the reason is self-explanatory, the solution suggested by the error message doesn't work as expected. When you select the Show Updates option, it says that the software is up to date.

To be honest, it does work sometimes. However, you can also do it manually if you want. Just open your terminal and run the command below:

```bash
sudo apt update
```

This command will download and install an updated list of your packages. To understand the difference between the commands `update` and `upgrade`, have a look at this [Ubuntu man page](https://manpages.ubuntu.com/manpages/xenial/man8/apt-get.8.html).

That's it 👋


Ubuntu: How To Solve "The Update Information Is Outdated" error alert?


Caso você esteja construindo uma infraestrutura na AWS e precisou montar um sistema de arquivos nas suas instâncias EC2 privadas, você pode ter se deparado com o seguinte erro:

```bash
Failed to resolve server us-east-1a.fs-xxxxxxxx.efs.us-east-1.amazonaws.com: Name or service not known
```

Para montar um sistema de arquivos, o assistente de montagem `amazon-efs-utils`, tenta fazer uma conexão através da porta 2049, utilizando o DNS atribuído ao seu File System, e que segue o seguinte formato: **fs-12345678.efs.us-east-2.amazonaws.com.**

Caso a sua VPC não esteja apta a resolver endereços de DNS internamente, sua instância EC2 não conseguirá se conectar ao seus sistema de arquivos EFS. Para habilitar a resolução de DNS na sua VPC, abra o Gerenciador de VPCs e selecione a VPC desejada. Então, vá em Actions, habilite os recursos **DNS resolution** e **DNS hostnames**.

Desta forma, os recursos privados pertencentes a sua VPC poderão se conectar internamente e resolver endereços de DNS.

EFS error: Failed to resolve - server  name or service not known


`:focus-within` é uma pseudo-classe do CSS que representa um elemento em que um dos seus elementos filho recebe uma correspondência da pseudo-classe `:focus`. Caso isso tenha soado estranho, não se preocupe que vendo o funcionamento do exemplo, tudo vai ficar mais claro.

## Exemplo:

<iframe src="https://codepen.io/alisonmonteir0/embed/ExxQpBW?height=265&theme-id=0&default-tab=css" width="100%" height="300" name="codepen" frameborder="0"></iframe>

Depois que eu descobri esse seletor, eu acabei deixando de usar algumas soluções bem desnecessárias com Javascript. Como visto no exemplo, com ele, podemos **alterar o estilo do elemento pai, quando um elemento filho está sob foco**.

É importante entender que esse seletor funciona **principalmente nos browsers modernos**. Browsers como IE ou estão fora do suporte. Veja mais detalhes no [Can I use](https://caniuse.com/#search=focus-within).

A pseudo-classe :focus-within do CSS


<figure>
	<img src="https://images.unsplash.com/photo-1542382257-80dedb725088?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1400&q=80" alt="Network" />
	<figcaption>Photo by Anastasia Dulgier, via Unsplash</figcaption>
</figure>

Acessar o seu projeto em diversos dispositivos, muitas vezes pode ser necessário, mesmo que você esteja testando-o em ambiente local. O comando `artisan`, do Laravel, disponibiliza várias funcionalidades, e uma delas é de criar um host na sua rede local para tornar possível acessar o seu projeto de diferentes dispositivos conectados a sua rede.

## IP do host
Para utilizar esta função, primeiro, é necessário ficar atento a sua faixa de endereço IP.
Caso não seja um problema, você pode inclusive utilizar o seu próprio IP como host.

### No Mac ou Linux
No Mac OS ou Linux, para ver o seu endereço IP, digite o seguinte comando no seu terminal:

```sh
ifconfig en0
```

### Windows
No Windows, para ver o seu endereço IP, digite o seguinte comando no seu terminal:

```shell
ipconfig getifaddr en1
```

Isso deve ter lhe retornado algo como `192.168.1.9`. A partir daí, você pode utilizar este mesmo IP ou um outro válido na sua faixa de IP, como por exemplo `192.168.1.37` ou `192.168.1.66`.

## Criando o host

Com isto feito, você já pode criar o seu host utilizando o comando abaixo:

```sh
php artisan serve --host=IP_ADDRESS
```

Não esqueça de substituir `IP_ADDRESS` pelo seu endereço de IP.

Além disso, você pode definir uma porta específica que você quer o seu host rodando, assim como já era comum no comando `serve`, utilizando o parâmetro `--port`.

Caso o endereço de IP escolhido esteja indisponível, você receber uma mensagem como esta: **Failed to listen on 192.168.1.1:8000 (reason: Can't assign requested address)**

Mas não tem problema algum, basta escolher um novo endereço IP e continuar com os seus testes.


Acessando seu projeto Laravel em todos os seus dispositivos


<figure>
	<img src="https://images.unsplash.com/photo-1565843714144-d5a3292ae82d?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=1352&q=80" alt="Coffee and Code" />
	<figcaption>Photo by Marc Mintel, via Unsplash</figcaption>
</figure>

Se você já precisou fazer alguma alteração em um projeto que utiliza Laravel, provavelmente você se deparou com uma serie de componentes utilizando VueJS. Isso por quê, mesmo não definindo qual biblioteca JavaScript ou pré-processador CSS você deve usar em seus projetos, o Laravel deixa uma estrutura pré-definida [utilizando Vue e SASS/SCSS](https://laravel.com/docs/5.8/frontend#introduction).

Para utilizar uma variável definida no seu arquivo `./css/variables.scss` dentro de um componente chamado `./js/File.vue`, por exemplo, você só precisa fazer o seguinte.

File.vue:
```html
...

<style lang="scss" scoped>
	@import '../css/variables';

	p {
		color: $awesome-color-g200;
	}
</style>

...
```

Isso é possível por quê, ao setar o atributo `lang="scss"`, o VueJS considera como SCSS tudo que está dentro da tag `style`, por isso podemos usufruir de todos os recursos do pré-processador dentro do no nosso componente.

Caso você esteja fazendo algum tipo de refatoração, eu recomendo recriar as [variáveis utilizando apenas CSS](https://developer.mozilla.org/pt-BR/docs/Web/CSS/Using_CSS_custom_properties). Desta forma, você terá acesso direto as suas variáveis, sem necessidade de importação de arquivos.


Utilizando variáveis do SASS em um componente VueJS, no Laravel


According to the Git documentation, the `git push` command "update remote refs along with associated objects". It means that it updates your remote repository based on your local information.

This is just a reminder to myself in the future. Try `git push --force-with-lease` Instead of `git push --force`.

The `git push --force` updates the repository with everything you have locally. **Possibly overwriting** any changes that a team member has pushed in the meantime.

Reminder: force with lease


Trabalhando como desenvolvedor(a) Front-end em uma empresa de pequeno porte, em algum momento você vai se deparar com uma task relacionada a criação de um template de e-mail. Essa pode parecer uma tarefa muito básica, mas ela requer atenção em alguns pontos para que o e-mail chegue na caixa de entrada e com o Front-end fiel ao layout.

Primeiramente, é importante identificar qual ferramenta será utilizada para enviar as mensagens, pois em alguns casos temos diversas limitações e em outros não precisamos nos preocupar sequer com a construção do template em si.

Porém, para este post, vamos levar em consideração que você precisa construir o seu template baseado em um layout que um designer fez, exclusivamente para este envio, certo?

## De volta aos anos 90

Mesmo com todas as tecnologias que conseguimos usufruir no front-end atualmente, nossos clientes de e-mails são muito limitados em relação a interpretação de código.
Por isso, para suportar o máximo de clientes possíveis, nossos e-mails devem ser construídos utilizando tabelas como estrutura. Sim, usando a tag `<table>`, nada de **Grid Layout ou FlexBox**. Além disso, devemos utilizar 100% do nosso estilo inline (ou o máximo possível).

Isso pode parecer bem estranho, mas esta é a técnica mais utilizada para que todos os clientes/usuários tenham a melhor experiência possível em seus respectivos clientes de e-mail. Veja um exemplo de como seria a estrutura de um e-mail marketing bem básico:

```html
<table border="0" width="100%" cellpadding="0" cellspacing="0" align="left">
  <tr>
    <td style="text-align: center;">
      <h3 style="color: #000;">Olá,</h3>
      <p style="color: #000; line-height: 1.7em; margin-bottom: 0;">Obrigado por nos visitar ontem. Como foi sua experiência?</p>
      <a style="margin-top: 16px; max-width: 230px; color: #FFF; background: #FF5E00; font-size: 16px; font-weight: bold; padding: 16px 60px; text-decoration: none; border-bottom: 2px solid #D04D01; border-radius: 5px;" href="https://www.meusite.com">
        Avaliar
      </a>
    </td>
  </tr>
</table>
```

Com o estilo sendo 100% inline e a marcação HTML da estrutura precisando ser feita apenas com tabelas, vamos utilizar alguns truques para deixar nosso e-mail mais responsivo.

## Resets, Media queries e Mobile first

Alguns clientes de e-mail aceitam alguns estilos gerais, mas isso não é regra.
É comum termos alguns "resets" de CSS em uma tag `<style>` para tentar deixar a estrutura inicial mais parecida para todos os clientes de e-mail.

Além dos resets, alguns clientes de e-mail também aceitam `@media` queries.
Isso é um pouco recente, se considerarmos a evolução dos clientes de e-mail. Veja um exemplo utilizando uma  media query:

```html
<style type="text/css">
  body {
    font-size: 14px;
  }

  @media only screen and (max-device-width: 480px) {
    table a {
      background: #333 !important;
      border-bottom-color: #CCC !important;
    }
  }
</style>

<table border="0" width="100%" cellpadding="0" cellspacing="0" align="left">
  <tr>
    <td style="text-align: center;">
      <h3 style="color: #000;">Olá,</h3>
      <p style="color: #000; line-height: 1.7em; margin-bottom: 0;">Obrigado por nos visitar ontem. Como foi sua experiência?</p>
      <a style="display: inline-block; margin-bottom: 22px; margin-top: 16px; max-width: 230px; color: #FFF; background: #FF5E00; font-size: 16px; font-weight: bold; padding: 16px 60px; text-decoration: none; border-bottom: 2px solid #D04D01; border-radius: 5px;" href="https://www.google.com">
      	Avaliar
      </a>
    </td>
  </tr>
</table>
```

Como você deve ter notado, para sobrescrever nossos estilos inline, precisamos utilizar o `!important` em todos os atributos que adicionarmos ao nosso CSS, que é bem comum nesse ambiente de **e-mails marketing**.

### Por quê usar estilo inline, então?

Uma coisa muito interessante de se saber sobre esse resets é que, mesmo que o seu cliente de e-mail suporte estes recursos: ao tentar encaminhar ou responder um e-mail que contenha estes estilos "extra", nesse momento todo esse estilo "extra" é descartado e só os estilos inline são utilizados. Sabendo disso, é importante avaliar seu público alvo e qual versão do seu e-mail pode ser compartilhada tanto no formato desktop quanto no mobile, e a partir disso definir a regra da sua media query.

## Boilerplate

Depois de muito pesquisar a respeito, acabei fazendo uma análise mais detalhada dos e-mails enviados pelo [iFood](https://www.ifood.com.br/), e achei que ele tinha um código muito bem estruturado.

Acabei montando um modelo baseado no que eles utilizavam na época (mantendo os créditos, assim como eles o faziam), porém com algumas adaptações.
Decidi publicar ele em um gist e compartilhar.

[Clique aqui](https://gist.github.com/alisonmonteiro/e758e9472d317eb53e7b3054041bb747) para visualizar o Gist com o template.
Agora, nos raros casos que preciso criar um e-mail "do zero", recorro a este template.

Lembrando que o `max-device-width` utilizando com regra da minha media query, pode ser substituído por qualquer outra regra que faça mais sentido pro seu caso.

Como fazer um e-mail responsivo + template de exemplo


Hey!

This is my first blog post!

I'm using a [blog starter](https://github.com/zeit/next.js/tree/master/examples/blog-starter) from ZEIT in the front-end.

I will publish posts in English and Portuguese. It can be simple things that I learn, thoughts, or long texts about web development.

I hope you like it.

Hi, I'm Alison Monteiro!

Latest Posts

I forget things quickly

Not everything needs refactoring

Grid columns animation using CSS

Simple notes app using NextJS, Supabase, and Shadcn/UI

Converting PDF to HTML from the command line

Hi, I'm Alison Monteiro! 👋

Latest Posts

I forget things quickly

Not everything needs refactoring

Grid columns animation using CSS

Simple notes app using NextJS, Supabase, and Shadcn/UI

Converting PDF to HTML from the command line

Hi, I'm Alison Monteiro!