Forem: Giovani Sousa

Cansado de conferir o schema.rb

Giovani Sousa — Mon, 05 Sep 2022 20:00:36 +0000

O Rails nos dá algumas facilidades que parecem mágica. A não-necessidade de importar os módulos que queremos usar, a metaprogramação da linguagem Ruby, os generators presentes no framework... Entre outras. Para mim, o maior contraste com outras linguagens é como fazer muito escrevendo tão pouco quando comparado. E isso tem o seu lado ruim também.

Quando criamos um novo modelo, não precisamos declarar no arquivo ruby (model.rb) todos os campos presentes naquele modelo. Geralmente, só mencionamos os campos que precisam de alguma validação ou que estão presentes em algum método para aquele modelo. E toda vez que queremos saber algum campo que não é mencionado: ctrl + f no schema.rb. O que não é exatamente a forma mais rápida e agradável que gostaríamos, ainda mais quando o campo é mencionado em diferentes tabelas, a tabela é mencionada em outras tabelas, indexes e etc.

Com a gem (Annotate)[https://github.com/ctran/annotate_models], podemos facilmente adicionar um comentário ao fim do código no model.rb com a estrutura da tabela referente aquele model, no mesmo formato que encontramos no schema.rb, algo tipo:

# == Schema Info
#
# Table name: line_items
#
#  id                  :integer(11)    not null, primary key
#  quantity            :integer(11)    not null
#  product_id          :integer(11)    not null
#  unit_price          :float
#  order_id            :integer(11)
#

Maravilha, né?

Falta algo no seu commit

Giovani Sousa — Fri, 13 May 2022 20:47:51 +0000

Falta algo no seu commit. O histórico de commits e pull requests é uma documentação incrível sobre a evolução do seu projeto. Assumindo que você já usa boas mensagens de commit, no histórico do seu projeto (git log), você já tem qual foi a mudança - no título ou vendo a mudança (git diff), quando aconteceu e quem fez essa mudança. Mas tem dois pedaços de informação que normalmente não estão ali.

Um desses pedaços de informação faltando no seu commit é a razão pela qual você fez a mudança. É comum essa informação estar em uma ferramenta de gerenciamento de projetos — como Jira, Trello ou Pivotal Tracker. O melhor caso é essa conexão ser feita numa via de mão dupla, a partir da ferramenta é possível encontrar o commit, e, partindo do commit, é possível encontrar o ticket na ferramenta.

O segundo pedaço é a explicação da solução. Quais as razões que te levaram a resolver aquela demanda (o primeiro pedaço da informação) daquela forma (o que podemos ver no git diff). Essa informação é muito valiosa e, muitas vezes, fica guardada na sua cabeça até não estar mais.

Para muitas pessoas desenvolvedoras, a maioria do trabalho no código é manutenção de que já existe. Passa pelo processo de ler, entender como funciona e aplicar as mudanças de acordo com a demanda, seja para corrigir um bug, adicionar uma nova funcionalidade e quem sabe até remover algo. Antes de tirar a cerca, é importante entender por que ela foi colocada ali, qual era o problema anterior a última mudança, o que ele resolveu, por que resolveu daquela forma.

E temos um lugar perfeito para guardar essa informação. O commit é formado pela descrição curta (também chamada de título) e pela descrição longa, pouquíssimo utilizada. Mas é bem simples de adicionar, direto do terminal, é a string após o segundo -m:

git commit -m "Descrição curta" -m "Descrição longa."

Ou editando o commit posteriormente com git commit --amend:

Descrição curta

Descrição longa

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Author:    YOU! <your-email@email.com>
# Date:      Thu May 13 09:31:52 2022 -0300
#
# On branch main
# Your branch is up to date with 'origin/main'.
#
# Changes to be committed:
#   modified:   file-changed.txt
#

Adicionar a motivação e a razão por trás da solução como descrição longa do commit — conectando a mudança do código com o que temos na ferramenta de gerenciamento de demanda e registrando nosso raciocínio—, é parte da comunicação do time e enriquece muito a tomada de decisão futura.

Tendo uma extensão no seu editor de texto, como a GitLens disponível para VSCode, no momento que você está editando o código, é possível ver quem foi o último a modificar aquela linha, quando, e a mensagem do commit.

Olha que beleza, no momento que você está construindo a nova solução ou entendendo a última, você consegue saber o que a última pessoa que modificou aquilo estava pensando. Sem a necessidade de tomar tempo dela ou tentar fazer ela relembrar — o que pode ser impossível.

Bom, o que a gente está esperando?

Conclusão

O commit é formado pela descrição curta (também chamada de título) e pela descrição longa, pouquíssimo utilizada. Utilizar a descrição longa para:

Conectar o commit e o código que é parte dele com a demanda (o ticket no JIRA, o card do trello, quem pediu, o que pediu, as restrições que pediram para respeitar, e etc)
Explicar as razões por trás da solução. Quais foram as decisões tomadas para solucionar aquilo daquela forma.

São pequenas informações que muitas vezes são perdidas ao longo do tempo. O registro delas pode ajudar seus colegas ou o você do futuro a tomar decisões melhores e escrever soluções melhores!

Controlando a quebra de linha

Giovani Sousa — Mon, 02 May 2022 20:17:39 +0000

Seja para criar um efeito estético ou evitar algum problema, tipo uma palavra viúva, aquela que sobra para outra linha no final de um parágrafo, é legal ter umas cartas na manga para dar aquela ajeita nos textos e nas quebras de linha. Ainda mais quando tratamos de partes chave do projeto, como a primeira coisa que vão ver no site que você está desenvolvendo, como é o caso da Hero Section¹.

Por exemplo, estamos criando um site que o texto da nossa Hero Section é "Vamos Jogar um Basquete". Os designers do nosso time pediram que a frase ocupe apenas uma linha em telas grandes o bastante, mas nas demais, o desejado é que ao quebrar, nunca a palavra "Basquete" fique sozinha na segunda linha.

Obviamente, podemos dar uma olhada como a frase fica disposta em vários tamanhos de tela e forçarmos a quebra de linha entre as palavras "jogar" e "um" com uma tag <br> e, para os tamanhos de tela, que cabem a frase toda, podemos usar media-queries² para esconder a quebra de linha.

<section class="hero">
  <h1> Vamos Jogar<br>um Basquete</h1>
  <button>Jogar</div>
</section>

Mas tem um jeito muito mais fácil e escrevendo muito menos! É utilizando o caracter especial Non-breaking space³, no HTML ele é invocado assim:  . Esse caractere funciona como um espaço, mas, no momento da quebra da linha, ele não vai ser considerado. É como se "Um Basquete" fosse uma palavra só sob a regra padrão de quebra de linha, na qual uma palavra é indivisível.

Codando nosso exemplo:

Geralmente, a primeira dobra (o que aparece no seu navegador assim que abre o site) da página inicial dos sites é chamada de Hero Section. A versão mais comum é uma imagem de fundo, um texto grande com o nome do produto e/ou um slogan e um botão convidando a se cadastrar, comprar o produto ou algo que seja do interesse do site em questão. ↩
https://developer.mozilla.org/pt-BR/docs/Web/CSS/Media_Queries/Using_media_queries ↩
https://en.wikipedia.org/wiki/Non-breaking_space ↩

Um .env para todos workspaces

Giovani Sousa — Sat, 05 Jun 2021 23:24:49 +0000

A feature do Yarn Workspaces é bastante útil quando você quer ter várias aplicações ou bibliotecas
no mesmo repositório. Um famigerado monorepo. O Roberto Achar fez um post sobre como configurar um monorepo utilizando o Yarn Workspaces. A biblioteca do Material-UI para React é um exemplo de repositório que tem múltiplos pacotes juntos e usa Yarn Workspaces.

São várias as organizações que podemos fazer nesse esquema, podemos ter aplicações independentes, uma lib que é usada por todas as outras, várias independentes e uma que usa todas elas e etc. Nesse mundo de aplicações, durante o desenvolvimento, ter um .env para cada uma pode não fazer sentido ou simplesmente ser chato demais por ter que ficar cada hora mudando em um lugar diferente, copiando de um pro outro e etc.

Um comando e uma alteração nos seus scripts pode resolver isso:

Instale a biblioteca dotenv-cli

yarn add --dev dotenv-cli

Adicione dotenv -e .env antes do seu comando que irá iniciar a aplicação/lib, por exemplo:

//package.json
"scripts": {
    "start-frontend": "dotent -e yarn workspace frontend start"
}

Assim, sua aplicação vai poder acessar as váriaveis que você configurou no seu .env da raiz 🎉

Copiando com Javascript - Clipboard API

Giovani Sousa — Sat, 29 May 2021 15:16:05 +0000

TL;DR

let textToCopy = "Eu quero copiar esse texto aqui"

function afterSuccess() {
    console.log('Copiado com sucesso!')
}

function afterFailure(error) {
    console.error('A Cópia falhou!', error)
}

window.navigator.clipboard
    .writeText(textToCopy)
    .then(afterSuccess, afterFailure)

Numa era pré ClipboardAPI, a solução para copiar e colar algum texto que eu mais vi envolvia adicionar à página um input com o texto que você quer copiar, colocar o foco naquele input, selecionar o texto e enviar o comando document.execCommand("copy"). E em muitos casos essa ainda é a melhor solução dependendo de quais browsers a sua aplicação deve-se manter compatível. Você pode comparar o suporte dessa feature utilizando o caniuse.com. Suporte a document.execCommand x Suporte a Clipboard API write text. Em caso de IE, não tem jeito, vai ter que usar document.execCommand.

Para o uso do Clipboard API, além de conhecer a API em si, temos que respeitar algumas regras por questão de segurança. Uma delas, por exemplo, é que o clipboard.writeText vai falhar caso o usuário não esteja com foco na aba. Você pode ver esse erro acontecendo, testando o código no console do seu browser (isso no Chrome). Em alguns outros browsers, esse código só funciona caso esteja num código sendo executado em resposta a uma ação do usuário, como um click por exemplo. Então, tenha isso em mente ao utilizar essa API.

O código é simples, a função window.navigator.clipboard.writeText retorna uma Promise, ou seja, ele é assíncrono, logo após a sua execução pode ser que ele ainda não tenha terminado de copiar. Por isso, nós utilizamos o .then, para que quando essa Promise seja resolvida, ou seja, o comando tenha de fator terminado de copiar ou dado erro, no caso de sucesso execute a nossa função afterSuccess e em caso de erro execute nossa outra função, afterFailure. E é isso, assim que aparecer a mensagem de sucesso, já estamos livres pra sair colando nossa mensagem.

Esse text foi originalmente postado em https://giovanisleite.dev/copiando-com-javascript

Como configurar chaves SSH para duas ou mais contas no Github

Giovani Sousa — Sat, 20 Jun 2020 16:05:09 +0000

Imagino que você já tenha sua primeira conta configurada e está fazendo/já fez o processo de autenticação SSH para a segunda conta, criando uma segunda chave e adicionando ao Github/Bitbucket/Gitlab/Outro da sua escolha e deu merda na hora de fazer o git clone do projeto.

Como resolver

Dentro da pasta que guarda suas chaves, geralmente ~/.ssh você vai criar um arquivo config.

Supondo que você quer deixar a chave que já está funcionando como default e quer que essa segunda chave funcione apenas para casos especiais, como esse repositório ou alguns repositórios que você vai fazer clone em seguida. Você vai adicionar uma regra no arquivo ~/.ssh/config para esses repositórios:

Host caso-especial
  HostName github.com
  IdentityFile ~/.ssh/segundachave_id_rsa

Ao clonar o repositório, ao invés de usar o comando que o Git sugere, você vai usar algo como: git clone git@caso-especial:organizacao-dono-do-repo/repo.git. E tchana nana na.