DEV Community: Vitor Freitas

Formatting currencies with Intl.NumberFormat

Vitor Freitas — Thu, 02 Jul 2020 23:23:11 +0000

Do you know the Intl object in Javascript?

This namespace stands for the ECMAScript's internationalization API, and provides some nice features such as string comparison, and number, date and time formatting. With this post I'll show about currency formatting using the NumberFormat constructor.

Recently I had to format integers to a currency format and I had 2 options:

Do it myself (which I'm a huge fan of)
Use some external library

But this time was different, and I took some time to search about the topic and then I found Intl.NumberFormat. It's usage is simple, here's an example:

const reaisFormatter = new Intl.NumberFormat('pt-BR', {
  style: 'currency',
  currency: 'BRL'
})

reaisFormatter.format(123.50) // R$ 123,50

And that was it. Simple, huh? And within the NumberFormat constructor you have an infinity of possibilities, such as unit formatting (liters, centimeters, foot...), percentage, decimal formatting and so on.

Perheps you don't need to npm install something to do that anymore. Hope you enjoyed it!

Removendo propriedades de um objeto JavaScript usando destructuring e spread operator.

Vitor Freitas — Sun, 23 Feb 2020 15:10:34 +0000

O problema

Estou escrevendo testes unitários para um microserviço feito com TypeScript, testando funções que buscam dados no banco de dados, removem determinadas propriedades do objeto e o retorna para o cliente. Preciso ter certeza de que os dados estão sendo removidos, e para não reescrever todo o payload no meu arquivo de testes exceto pelas propriedades removidas, busquei uma solução mais simples.

Exemplo

// Função a ser testada

function fetchFromDatabase() {
  const payload = {
    id: 1,
    name: 'Vitor',
    secret: 'My secret'
  }

  delete payload.secret

  return payload
}

...

// Arquivo de teste (usando o chai, mas poderia ser qualquer lib de testes)

function testMyFunction() {
  const mock = {
    id: 1,
    name: 'Vitor',
    secret: 'My secret'
  }
  insertIntoDatabase(mock) // Exemplo adicionando um mock no banco de dados

  const result = fetchFromDatabase()

  const { secret, ...allowedProperties } = mock // Onde a mágica acontece.

  expect(result).to.be.eql(allowedProperties) // returns: true
}

O que aconteceu?

Usamos o destructuring para selecionar as propriedades que não queremos, e com o spread operator (...) salvamos todo o resto (propriedades que queremos) dentro de allowedProperties.

E o `delete`?

Na função que é testada é usada a keyword delete, mas poderia ser facilmente substituída pela nossa "técnica" de destructuring + spread operator.

No JavaScript temos a keyword delete, que remove uma propriedade de um objeto.

const obj = { name: 'Vitor', role: 'Developer' }

delete obj.role

console.log(obj) // { name: 'Vitor' }

Entretanto, como podemos ver, ao usarmos o delete o nosso objeto é mutado. Particularmente, não é um comportamento que gosto de manter na minha base de código, pois pode dificultar os meus testes e criar side effects difíceis de debugar.

Debugando como um profissional

Vitor Freitas — Tue, 21 Jan 2020 14:35:53 +0000

O que é "debugar"?

Debugar é a arte de achar a causa de um bug. Nem sempre debugar é algo trivial e pode tomar horas, dias ou até semanas para que você consiga resolver o bug.

O mindset correto

Debugar é uma atividade que requer que o programador pense de uma forma clara e não enviezada sobre um problema. É muito fácil culpar o outro quando um bug surge, e saber que independente de quem for a culpa a responsabilidade de corrigir este bug é da equipe requer tempo e, claro, o mindset correto.

Nada é impossível

É comum querermos pensar "mas isto é impossível!" ou "no meu código não acontece esse tipo de coisa." quando um bug ou um erro surge. Sinto lhe informar mas isto é tão possível que já aconteceu! Então ao invés de lamentar ou discordar que este bug acabou de acontecer, use o seu tempo para corrigi-lo! Fix the problem, not the blame.

Não entre em pânico

Somos pagos para resolver problemas. A partir do momento que somos contratados por alguém ou por alguma empresa, nossa função é resolver os problemas dessa pessoa, agregando valor para a sua marca ou produto. Não entrar em pânico é imprescindível, e ao debugar um código não será diferente. Dê um passo para trás e veja o contexto como um todo. Por que isso aconteceu? Dada as circunstâncias, isto acontecerá novamente? Lembre-se, computadores fazem o que o instruímos a fazer, e não o que queremos que ele faça.

Corrija o bug, e não os seus sintomas

Sintomas são comportamentos que existem por conta de um determinado bug, e é fácil pensarmos que estes sintomas são o bug. Corrigir sintomas significam que o bug ainda está lá, e sinto lhe informar, mas ele vai voltar! Busque a raiz do problema e não os sintomas que o cercam.

Técnicas para debugar como um profissional

Reproduza o bug

Reproduzir um bug é uma frase conhecida no nosso meio, ela significa que você foi capaz de alcançar o mesmo comportamento reportado pelo seu usuário ou QA (controle de qualidade). Esta etapa é super importante, pois se você não consegue reproduzir um bug, como saberá que o mesmo foi corrigido? Se possível, isole este comportamento por meio de testes unitários/integração ou em um ambiente controlado, principalmente em casos onde você precisa passar por vários passos até chegar no bug. Você ganhará tempo e consequentemente resolverá este problema mais rápido.

Tenha controle dos dados

Como um bom programador JavaScript, uma das técnicas que mais uso para debugar minhas aplicações é por meio do console.log. Essa função escreve no console do browser (ou terminal) o que receber como parâmetro. Ou seja, posso escrever um payload de um requisição, o estado de uma variável em determinado bloco ou até um simples "cheguei aqui!" para saber se uma função foi chamada, por exemplo. É muito mais fácil descobrir um erro quando você pode visualiza-lo com clareza. Use funções de print ao seu favor!

Diga em voz alta

O ato de explicar o erro para outra pessoa é esclarecedor. O simples fato de você expressar o que está acontecendo para um colega de equipe muitas vezes é o necessário para que a solução apareça. Comunique-se!

Refatore seus testes

Sempre que possível cheque a integridade dos seus testes. Testes não podem ser enviezados e devem funcionar com as mais diversas entradas! Refatore quando for conveniente.

Use um debugger!

Temos várias ferramentas para auxiliar o processo de debugging do seu código. Use-as! IDEs geralmente contam com debuggers, como por exemplo Netbeans, Visual Studio Code e as IDEs da JetBrains. Use aquela que você se sentir mais a vontade e que te ajude a resolver os seus problemas.

Posteriormente pretendo escrever um artigo ensinando a usar o debugger do VS Code para debugar aplicações front-end e Node.js. Fique de olho!

Conclusão

Estas são dicas valiosas e que uso no meu dia-a-dia. A maioria vieram de notas que fiz enquanto lia o capitulo 3 do livro O programador pragmático e ver que eu estava no caminho certo foi uma sensação muito boa 😆. Recomendo a leitura do livro, lá ele aborda vários outros tópicos além de debugging.

Dúvidas ou sugestões estou sempre a disposição!

O programador pragmático: consertando vidros quebrados.

Vitor Freitas — Mon, 13 Jan 2020 19:16:06 +0000

Estou lendo este livro sensacional chamado "The Pragmatic Programmer" (aka O programador pragmático). So far, so good. Esta é uma tentativa de sumarizar alguns aprendizados do livro conforme eu vou lendo e aplicando no meu contexto real.

Sobre vidros quebrados

Sabe aquele prédio que até um mês atrás havia apenas um vidro quebrado e conforme o tempo passou, ele veio se deteriorando dia após dia? Acredite ou não, poderia ser o seu código.

O que quero dizer é que um erro besta de arquitetura, design pattern e decisões de negócio podem afetar o seu código no futuro se você não tratar o quanto antes. É como um virus que se estabelece e há de ser tratado o quanto antes.

Meu contexto

Recentemente refatorei toda uma aplicação front-end na empresa em que trabalho pois a codebase anterior estava atrofiada a tal ponto que era complicado adicionar novas features. Como se tratava de um MVP, tento entender a pressa e as decisões escolhidas no momento. E, também por ser um MVP, refatorar não foi muito custoso. O resultado vem sendo um produto bom pro desenvolvedor e bom pro usuário.

Mas recentemente me peguei tomando decisões ruins na organização de pastas e arquivos, e na arquitetura no geral. Fui capaz de perceber que aquilo não escala, mas fui empurrando com a barriga até o momento atual.

Conclusão

Esta parte do primeiro capitulo de O programador pragmático serviu para deixar claro algo que eu já sabia, e foi o empurrão necessário para eu voltar e melhorar o meu código e não cometer o mesmo erro que cometeram no passado.

Com o objetivo de me tornar um melhor desenvolvedor, este capitulo deixou bem claro pra mim o primeiro passo que devo tomar. Deixar sua codebase atrofiar sabendo que poderia melhorar te faz irresponsável, e não é o que queremos, correto?

Ionic + OneSignal: Utilizando na web e no mobile.

Vitor Freitas — Fri, 13 Dec 2019 00:44:58 +0000

Contexto

Estou trabalhando em uma aplicação mobile feita em Ionic, que precisou ser portada também para web. A versão antiga dessa aplicação (web) era feita em Angular 1 e, com o objetivo de melhorar a experiência e reduzir o custo da manutenção, resolvemos utilizar a base de código do nosso app também para web.

O problema

Para notificar no mobile usamos o @ionic-native/onesignal e na web o OneSignalWebSDK. Tudo funcionava bem com um simples ionic serve. Entretanto, após fazer um build com ionic cordova build browser, o OneSignal que era injetado no objeto window não era aquele provido pelo OneSignalWebSDK, e sim o do cordova. Cheguei nessa conclusão após analisar vários console.logs e ver diferenças marcantes entre o output dos logs de desenvolvimento e de produção.

A solução

Para solucionar precisei importar o OneSignalWebSDK programaticamente. Isto é, usando JavaScript ao invés de uma tag <script> no arquivo index.html. Este chunk de código é executado após o cordova carregar todos os seus plugins, ou seja, após a Promise platform.ready() ser resolvida.

O código

app/app.component.ts

providers/notification/notification.ts

Problem Solved

Resolvi omitir a implementação do OneSignal do cordova pois na documentação contém o necessário para sair usando. Espero que isto resolva o seu problema assim como resolveu o meu. Obrigado!

Removendo switch/case de um reducer

Vitor Freitas — Sun, 20 Oct 2019 19:34:39 +0000

Por quê fazer isso, afinal?

Não sou um grande fã de blocos switch/case. Fazendo alguns testes de performance comparando à mapear objetos literais no Javascript ele se mostrou mais lento. Minha opinião é um pouquinho sem fundamentos lógicos, mas vamos explorar um pouco mais dos por que's logo a frente.

Nota: testes de perf. são legais, sim. Mas por vezes, milisegundos pra mais ou pra menos não fazem diferença pro seu usuário. UX é importante, assim como DX! (Developer experience)

Problemas com switch/case

Como mencionei acima, "object lookup" performam melhor que switch/case's. Outro problema está em sua sintaxe, todo o resto da linguagem usa {} para delimitar escopo, enquanto cada case usa :. Usando objetos, não precisamos utilizar break ou return em cada caso. No nosso caso precisamos de return's pois estamos lidando com reducers e eles precisam retornar uma nova versão do state. Objetos são mais fáceis de testar, pois são apenas objetos! Não entende nada de testes com Javascript? Dê uma olhada aqui.

Resultado

O bloco acima foi retirado de um código que estou trabalhando agora mesmo, o qual contém um reducer de carrinho de compras bem simples. Enquanto olhava aquele switch/case que todo mundo ensina me questionei "e se eu fizesse diferente?". Cheguei nesse resultado e, sinceramente, não está de todo mal :P

Conclusão

Mostrar a si mesmo que você tem algum domínio em cima da ferramenta o qual você trabalha é um sentimento bacana. Você vê que seu código vai além de fórmulas máginas que você copia do Stack Overflow e etc, e consequentemente você fica mais confiante. Trabalho com Javascript há quase 2 anos (não é muito) e sempre que essas situações me ocorrem, gosto pra caramba.

Legibilidade na sua base de código é importante. Talvez hoje eu ache dessa forma melhor, talvez amanhã eu ache switch/case melhor. Tudo vai depender do quão fácil é para entender o objetivo do código. Afinal de contas, não posso me dar o luxo de abrir mão da legibilidade baseado em opiniões totalmente arbitrárias.

Alguma sugestão ou opinião? Fale comigo!

“Code that communicates its purpose is very important. I often refactor just when I'm reading some code. That way as I gain understanding about the program, I embed that understanding into the code for later so I don't forget what I learned.”

Martin Fowler, Refactoring: Improving the design of existing code.

Meus aprendizados na Campus Party Goiás

Vitor Freitas — Sun, 15 Sep 2019 20:05:00 +0000

Entre os dias 04 e 08 de setembro ocorreu lá em Goiania mais uma das edições da Campus Party, a qual tive o prazer de poder ir.

A primeira dica que posso dar pra você que está lendo é: se tiver oportunidade, vá a uma campus party, especialmente se sua jornada está começando. Lá você encontra muita gente disposta a ensinar e passar conteúdo e diversas comunidades ensinando os mais diversos assuntos que você possa imaginar.

O que você aprendeu lá, afinal?

Quanto a tecnologias, vi muito conteúdo sobre Docker e Kubernetes, Infra as Code, Serverless, GraphQL e Gatsby, Algolia e diversas outras coisas. Irei discorrer um pouco sobre os que mais me chamou atenção e que tive a oportunidade de por a mão na massa enquanto aprendia.

Docker

É um nome que costuma aparecer nas conversas, e pra mim era um conceito muito abstrato até então. Ainda tenho algumas dúvidas, mas lá eu pude aprender como começar com containers e uma breve introdução do que eles são. Fiz uma brincadeirinha e pushei no GitHub aqui.

GraphQL

Este era, e ainda é, o que mais tenho curiosidade de aprender nos últimos dias. Uma alternativa para a forma que escrevo minhas APIs hoje é algo que muda o jogo da água pro vinho. Lá pude escrever algum código server-side (que publiquei aqui), e posteriormente integrei em uma aplicação React de teste para ver como funciona (que publiquei aqui). Não tenho muito a dizer se não "Aprenda GraphQL!". O esforço inicial é mínimo, achei a curva de aprendizado bem interessante, pelo menos para mim que já tenho algum background. Ferramentas como o graphql-yoga podem ser um ótimo entry point para você que está curioso, assim como eu estava.

Algolia

Este é uma ferramenta do tipo "search engine" muitíssimo poderosa. Na hackathon que eu e dois amigos participamos descobrimos o Algolia e foi o canal para desenvolvermos algo muito robusto com pouco esforço. Infelizmente não ganhamos, mas o conhecimento valeu a pena.

Mas, o mais importante...

Pude ter ainda mais certeza de que eventos desse tipo são ótimos para criar um networking, que é fundamental para nós de tecnologia. Social skills são necessárias e precisam ser desenvolvidas.

Outro aprendizado importante é APRENDA OS FUNDAMENTOS. Frameworks, ferramentas e até linguagens de programação vem e vão, mas os fundamentos sempre se mantêm.

Aos que me acompanharam nessa aventura, obrigado! (@KelvinCS, @caique39)

DEV Community: Vitor Freitas

Formatting currencies with Intl.NumberFormat

Removendo propriedades de um objeto JavaScript usando destructuring e spread operator.

O problema

Exemplo

O que aconteceu?

E o delete?

Debugando como um profissional

O que é "debugar"?

O mindset correto

Nada é impossível

Não entre em pânico

Corrija o bug, e não os seus sintomas

Técnicas para debugar como um profissional

Reproduza o bug

Tenha controle dos dados

Diga em voz alta

Refatore seus testes

Use um debugger!

Conclusão

O programador pragmático: consertando vidros quebrados.

Sobre vidros quebrados

Meu contexto

Conclusão

Ionic + OneSignal: Utilizando na web e no mobile.

Contexto

O problema

A solução

O código

Problem Solved

Removendo switch/case de um reducer

Por quê fazer isso, afinal?

Problemas com switch/case

Resultado

Conclusão

Meus aprendizados na Campus Party Goiás

O que você aprendeu lá, afinal?

Docker

GraphQL

Algolia

Mas, o mais importante...

E o `delete`?