Forem: Gustavo Inocencio

Resolvendo problemas de integração entre interfaces com padrões de projeto

Gustavo Inocencio — Mon, 18 Jul 2022 15:02:32 +0000

Contéudo

Introdução
Decorator
Adapter
Facade

Introdução

Sabemos ao lidar com sistemas do mundo real que um problema bastante frequente é a necessidade de integração com sistemas de terceiros. Sejam APIs para integração de um ERP, um CRM ou um sistema auxiliar para uma necessidade que os seus clientes tem.
Com isso, nos vemos com o dilema de como fazer para integrar nossos sistemas para se comunicar com esses outros sistemas. Não há tempo, nem mesmo disposição para sempre fazer uma refatoração do sistema para se comunicar a um parceiro.
Nesse artigo trago 3 padrões de projeto que podem ser um guia para essa necessidade.

Comparativo
Decorator: Acrescenta responsabilidades a uma interface
Adapter: Converte uma interface para outra
Facade: Simplifica uma interface

Decorator

O Decorator é um padrão de projeto estrutural que permite que você acople novos comportamentos para objetos ao colocá-los dentro de invólucros de objetos que contém os comportamentos.
Comportamento típicos que podem utilizar esse padrão são:

Log;
Cache; A estrutura normal do Decorator é atuar como um wrapper para o objeto desejado. Exemplo de implementação:

IWeatherService innerService = new WeatherService(apiKey);
            IWeatherService withLoggingDecorator = new WeatherServiceLoggingDecorator(innerService, _loggerFactory.CreateLogger<WeatherServiceLoggingDecorator>());
            IWeatherService withCachingDecorator = new WeatherServiceCachingDecorator(withLoggingDecorator, _memoryCache);
            _weatherService = withCachingDecorator;

Nesse código é possível ver que o service innerService é envolvido pelo Decorator WeatherServiceLoggingDecorator gerando o service withLoggingDecorator que por sua vez é envolvido pelo Decorator WeatherServiceCachingDecorator gerando o service withCachingDecorator que é o service final.
Uma analogia bastante utilizada é comparar essa implementação com uma cebola e suas camadas.

Adapter

O Adapter é um padrão de projeto estrutural e sua motivação é fazer com que uma interface de uma classe seja convertida para outra interface de acordo com o que o cliente espera.
Existem dois tipos de Adapters que podem ser implementados:

Object adapter - utiliza composição, onde é realizada uma implementação de uma interface
Class adapter - utiliza herança, onde é realizada uma herança da classe externa

A aplicabilidade desse padrão de projeto é ser usado quando a interface de uma biblioteca de terceiros ou algo similar não é compatível com o código atual da aplicação. Também pode ser aplicada para casos de chamadas a APIs, onde é necessária ou desejada a separação da parte do código responsável pela conversão dos dados recebidos da parte em que está a lógica de negócio do sistema. Esse padão é útil quando deseja-se utilizar várias implementações onde a estrutura é similar, mas existem diversas fontes externas (como diferentes APIs). Desse modo, todo o trabalho fica como responsabilidade da classe Adapter, separando essa camada do resto do sistema.

Facade

O Facade é um padrão de projeto estrutural que fornece uma interface simplificada para uma biblioteca, um framework, ou qualquer conjunto complexo de classes.
Exemplos de usos:

Classe muito complexa, onde são necessários apenas alguns dos métodos dela ou que seja apresentado algo mais intuitivo para uso do outro objeto. Uma classe facade faria essa intermediação fornecendo apenas alguns métodos para simplificar a implementação do objeto cliente
Várias classes com métodos necessários para o objeto cliente. Uma classe facade faria a intermediação para simplificar em apenas 1 método a ser chamado.

Banco de dados AWS

Gustavo Inocencio — Tue, 05 Jul 2022 12:12:45 +0000

Este artigo pretende ser mais um da série de resumos para aqueles que pensam em fazer o exame de AWS Certified Cloud Practitioner. Mais informações encontram-se ao fim do artigo. O assunto desse artigo é banco de dados no AWS.

A principio deve ser dito que o uso de banco de dados depende da sua necessidade. Existem diversos serviços que podem ser utilizados. Caso seja apenas um lugar para realizar o deploy do seu database, um serviço EC2 resolveria, para se ter completo controle.
Mas caso queira um PaaS para operar e ter controle de um banco de dados, mas não quer se preocupar com sua infraestrutura, o RDS seria a sua opção.

Uma última opção seriam os SaaS para ter o mínimo de manutenção, como DynamoDB, Elasticache ou Redshift.

RDS

Opere e escale um banco de dados relacional na Nuvem AWS
Automatize tarefas administrativas demoradas
Armazene e transmita dados de forma segura
Suporta deployment entre multiplas zonas disponíveis
Bancos disponíveis:
- MySQL
- PostgresSQL
- MariaDB
- Oracle Database
- SQL Server
- Amazon Aurora

DynamoDB

Não-relacional
Saas, o que quer dizer que está pronto para uso, sem necessidade de nenhuma manutenção ou preparo de infraestrutura ou da camada do banco de dados.
Fornece as opções de chave-valor ou banco de documentos
Baixa latência
Suporta scaling automatizado baseado na configuração

Amazon Aurora

Banco de dados relacional compatível com PostgreSQL e MySQL

Elasticache

Armazena dados de cache
Baixa latência
Suporta Memcached e Redis

Redshift

Serviço escalável de Data warehouse que usa SQL para analisar dados estruturados e semiestruturados em data warehouses, bancos de dados operacionais e data lakes, usando hardware e machine learning projetados pela AWS para oferecer a melhor performance de preço em qualquer escala.

AWS Database Migration Service

Serviço para realizar a migração dos dados locais para a nuvem
Suporta migração contínua ou única de dados

Tipos de armazenamento AWS

Gustavo Inocencio — Mon, 27 Jun 2022 20:40:31 +0000

Existem 3 tipos de armazenamento dentro do AWS.

Armazenamento em blocos
Armazenamento de objetos
Armazenamento de arquivos

Armazenamento em blocos (EBS)

No armazenamento em blocos, os arquivos são separados em partes iguais (blocos) de dados.
O armazenamento em bloco é usado para aplicações executadas em instâncias do EC2.
De acordo com a necessidade pode ser usado um bloco HDD-based ou SSD-based.
Podem ser associados volumes EBS extras ao seu EC2 de acordo com a demanda.
Pode ser criado um snapshot, um "momento", uma "fotografia" para ser armazenado e replicado esse momento do EBS em novos blocos.

Armazenamento de objetos (S3)

Cada objeto consiste em dados, metadados e uma chave
Numa associação com uma biblioteca, o objeto é um livro, onde os dados são os capítulos, os metadados serão as informações do livro como nome e ISBN e a chave é a referência cadastrada desse livro.

Esses objetos são armazenados no Amazon Simple Storage Service (S3). Dentro do S3 o local de armazenamento dos objetos é chamado de bucket, onde o limite de armazenamento é virtualmente ilimitado.

São definidas permissões para o controle de acesso a esses objetos.

Classes de armazenamento do Amazon S3

STANDARD:
- Acessado com grande frequência
- Armazenado em no mínimo três zonas de disponilidade, para replicação de informações
STANDARD - IA (Infrequent Access):
- Acessado com pouca frequência
S3 One Zone - IA
- Apenas em uma zona de disponibilidade
S3 Glacier
- Baixo custo para arquivamento de dados
- Capaz de recuperar em alguns minutos ou horas
S3 Glacier Deep Archive
- Menor custo para arquivamento de dados
- Capaz de recuperar em dentro de 12 horas
S3 Intelligent - Tiering
- Padrão de acesso desconhecidos ou alterados
- Pode armazenar em acesso frequente ou infrequente
- Automação para definição da disponibilidade

Armazenamento de arquivos (EFS)

Armazenamento dados em sistema de arquivos escalável
Aumenta e diminui automaticamente conforme você adiciona e remove arquivos, sem a necessidade de gerenciamento ou provisionamento.

Mais informações:
https://aws.amazon.com/pt/ebs/
https://aws.amazon.com/pt/s3/storage-classes/
https://aws.amazon.com/pt/efs/

Standard Queues vs FIFO Queues no AWS SQS

Gustavo Inocencio — Wed, 22 Jun 2022 14:51:40 +0000

Introdução

Amazon SQS(Simple Queue Service) é um serviço de mensageria oferecido pela AWS com o objetivo de permitir, numa arquitetura de microsserviços, o desenvolvedor a dissociar os componentes do seu aplicativo para que eles possam funcionar e falhar de forma independente.

Vantagens de seu uso:

Libera o desenvolvedor do trabalho de gerenciar seu próprio sistema de fila de mensagens;
Permite o envio, recebimento e armazenamento de mensagens entre componentes
Aumenta a tolerância a falhas do seu aplicativo.
Permite o compartilhamento de dados confidenciais entre componentes usando criptografia
Dimensiona com eficiência à medida que seu aplicativo cresce

Tipos de filas

Standard Queue
FIFO Queue

A Standard Queue é o tipo de fila padrão oferecido pelo AWS SQS. Suas características são:

Número quase ilimitado de transações por segundo por chamada de API
Best-effort ordering, em outras palavras tentativa de sempre entregar as mensagens na ordem em que foram recebidas, porém pode ocasionalmente enviar mais de uma cópia da mensagem enviado fora de ordem
Garantia de que a entrega da mensagem ocorrerá pelo menos uma vez.

Já a FIFO Queue (first in first out) é um tipo mais aprimorado de fila. Suas características são:

Limitadas a 300 transações por segundo por chamada de API sem lote e 3000 mensagens com lote (quando você agrupa 10 mensagens (máximo) por operação)
Garantia de entrega das mensagens na ordem recebida
Garantia de que a entrega da mensagem ocorrerá apenas uma vez e permanecerá disponível até que um consumidor a processe e a exclua. Duplicatas não são introduzidas na fila

Os casos de uso ideais para cada um dos tipos são:

Standard: Casos em seja mais importante a quantidade de transações por chamada de API do que a entrega na ordem e a ausência de duplicatas
FIFO: Casos em que seja extremamente importante a entrega na ordem e a ausência de duplicatas

Mais informações:
https://aws.amazon.com/pt/sqs/

Entendendo SOLID

Gustavo Inocencio — Sat, 11 Sep 2021 10:21:31 +0000

SOLID é o acrônimo para 5 princípios, criado por Uncle Bob e útil para tornar sistemas mais fáceis de manter e estender.

Abaixo estão os 5 princípios que formam o acrônimo em inglês.

Contéudo

Single Responsibility - Responsabilidade única
Open/Closed - Aberto/Fechado
Liskov Substitution - Substituição Liskov
Interface Segregation - Segregação de Interface
Dependency Inversion - Inversão de Dependência

Single Responsibility

Este princípio declara que uma classe deve ter apenas uma responsabilidade. Sendo mais claro e levando para a prática, a classe deve ter apenas um motivo para mudar.

O princípio da responsabilidade única é um dos mais importantes, porque é a base para outros princípios e padrões abordando temas como acoplamento e coesão. Menos responsabilidades numa classe geram menos dependências.

Por exemplo, na classe abaixo. Vê-se que a classe Livro tem responsabilidades ligadas as propriedades do livro, mas também um método para imprimir a página.

class Livro {

    function getTitulo() {
        return "Mundo Sem Fim";
    }

    function getAutor() {
        return "John Doe";
    }

    function virarPagina() {
        // pointer to next page
    }

    function imprimirPaginaAtual() {
        println("Contéudo da Página atual");
    }
}

Para aplicar o princípio nesse exemplo deveria ficar assim:

class Livro {

    function getTitulo() {
        return "Mundo Sem Fim";
    }

    function getAutor() {
        return "John Doe";
    }

    function virarPagina() {
        // pointer to next page
    }

    function getPaginaAtual() {
        return "contéudo pagina atual";
    }
}

interface Impressao {

    function imprimirPagina(pagina);
}

class ImpressaoConsole implements Impressao {

    function imprimirPagina(pagina){
        console.log(pagina);
    }

}

class ImpressaoHtml implements Printer {

    function imprimirPagina(pagina){
        <div style="single-page"> {pagina} </div>;
    }

}

Desse modo, a responsabilidade de impressão fica exclusiva em uma interface e pode-se estender o sistema criando novas implementações dessa interface.

Open/Closed

Esse princípio declara que classes devem ser fechadas para alteração e abertas para extensão, ou seja, não deve-se alterar classes para adicionar novas implementações. É claro que, para correção de bugs, a alteração de classes é permitida, mas para adicionar novas propriedades ou novos métodos não.

Como exemplo veja essa classe:

class Livro {

    function abrirLivro(){
        // abrindo livro
    }

    function realizarAnotacoes(){
        // realizando anotações
    }
}

Para um livro em papel seria normal, mas imagine se o sistema deve começar a considerar também livro digital:

class Livro {

    function abrirLivro(){
        if(livroEmPapel)  
          // abrindo livro em papel
        else if(livroDigital)
          // abrindo livro digital
    }

    function realizarAnotacoes(){
        if(livroEmPapel)  
          // realizando anotações em livro em papel
        else if(livroDigital)
          // realizando anotações em livro digital
    }
}

A chance de esse if quebrar a aplicação é grande.
Para isso, pode-se utilizar uma interface e extende-la para as próximas demandas:

interface Livro {

    function abrirLivro(){
        // abrindo livro
    }

    function realizarAnotacoes(){
        // realizando anotações
    }
}

class LivroEmPapel extends Livro {

    function abrirLivro(){
        // abrindo livro
    }

    function realizarAnotacoes(){
        // realizando anotações
    }
}

class LivroDigital extends Livro {

    function abrirLivro(){
        // abrindo livro
    }

    function realizarAnotacoes(){
        // realizando anotações
    }
}

Desse modo, a cada nova implementação não há o risco de quebrar a aplicação que já estava funcionando.

Liskov Substitution

Esse princípio foi introduzido por Barbara Liskov e diz que havendo uma classe filha B derivada de uma outra classe pai A, deveria ser possível trocar a classe B pela classe A sem prejuízos a aplicação.
Um exemplo de um problema que quebra esse princípio seria o seguinte:

interface Funcionario() {
     private string Nome;
     private string Cargo;

     function remunera() {
     } 
}

class ContratoClt extends Funcionario {
     function remunera() {
        //remunera como CLT
     } 
}

class ContratoPJ extends Funcionario {
     function remunera() {
        //remunera como PJ
     } 
}

class ContratoEstagio extends Funcionario {
     function remunera() {
        //remunera como Estagiario
     } 
}

class Voluntario extends Funcionario {
     function remunera() {
        //não remunera???
     } 
}

No exemplo anterior, a classe Voluntário não implementa a função remunera, o que pode ser um problema de compatibilidade com sua interface. Para resolver esse problema pode-se utilizar o próximo princípio, a Segregação de Interfaces, tornando interfaces menores e mais específicas para serem estendidas.

Interface Segregation

O princípio de segregação de Interface serve para definirmos várias interfaces menores para que as classes que implementam uma das interfaces só tenham que se preocupar com métodos que realmente as interessam.

Voltando ao exemplo anterior:

interface FuncionarioPago() {
     private string Nome;
     private string Cargo;

     function remunera() {
     } 
}

interface FuncionarioNaoPago() {
     private string Nome;
     private string Cargo;
}


class ContratoClt extends Funcionario {
     function remunera() {
        //remunera como CLT
     } 
}

class ContratoPJ extends Funcionario {
     function remunera() {
        //remunera como PJ
     } 
}

class ContratoEstagio extends Funcionario {
     function remunera() {
        //remunera como Estagiario
     } 
}

class Voluntario extends FuncionarioNaoPago {

}

Dependency Inversion

De acordo com Uncle Bob, esse princípio pode ser definido da seguinte forma:
1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.
2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Na prática, o exemplo abaixo mostra o problema:

public class WindowsMachine {

    private final Keyboard keyboard;
    private final Monitor monitor;

    public WindowsMachine() {
        monitor = new Monitor();
        keyboard = new Keyboard();
    }

}

Com a implementação, criando um novo Monitor e um novo teclado estamos deixando o acoplamento entre essas classes alto. Uma mudança em uma delas pode quebrar o sistema.

Para resolver isso, podemos fazer da seguinte maneira, utilizando Injeção de Dependência:

public class WindowsMachine {
    private final Keyboard keyboard;
    private final Monitor monitor;

    public WindowsMachine(Monitor monitor, Keyboard keyboard) 
    {
        this.monitor = monitor;
        this.keyboard = keyboard;
    }

}

Dessa forma desacoplamos o Keyboard e o Monitor do WindowsMachine, criando uma abstração onde qualquer monitor ou teclado passado por parâmetro possa ser acionado. Assim, não é necessário se preocupar em como criar esses dispositivos nessa classe. Preocupa-se apenas em utilizar o que foi recebido.

Utilizando useContext no React

Gustavo Inocencio — Sun, 05 Sep 2021 16:22:22 +0000

Mais um padrão essencial a ser empregado em projetos React, especialmente se você tem propriedades comuns que deseja reutilizar em seus componentes, e acaba escrevendo muitos props duplicados, é usar o React Context.

Por exemplo, se queremos compartilhar dados do usuário entre vários componentes, em vez de utilizar vários props repetidos (props drilling), poderíamos usar o recurso de contexto que está embutido na biblioteca React.

Primeiramente, temos que criar um contexto com React.createContext(). No caso abaixo a referência desse contexto é o UserContext:

const UserContext = React.createContext();

Depois deve-se envolver o App inteiro em um provider (Para esse exemplo foi envolvido o App inteiro, mas se for o caso de apenas um componente consumir o recurso pode ser envolvido apenas o componente):

    const user = {name: 'Gustavo'} 

    <UserContext.Provider value={user}>
        <App />          
    </UserContext.Provider>

No código acima o recurso compartilhado é um objeto user. Para compartilhar um recurso basta que seja atribuído ao atributo value.

Em seguida, podemos consumir esse contexto em nossos componentes individuais utilizando o hook useContext:

  const user = useContext(UserContext);
  return <div>Olá, {user.name} </div>;
 );

Concluindo, essa é uma forma de tornar o seu código mais limpo evitando a necessidade de utilizar várias e várias props.

Referências:
https://pt-br.reactjs.org/docs/hooks-reference.html#usecontext

Pontos sobre orientação a objeto em Delphi

Gustavo Inocencio — Wed, 21 Apr 2021 18:04:32 +0000

Abaixo segue alguns pontos úteis em relação ao Delphi.
Mas como o Delphi, derivado do Pascal é uma boa linguagem para aprender o básico de OOP, os pontos podem ser transportados para outras linguagens:

Interface é o segredo para alta coesão;
Em Delphi, o assigned só enxerga o ponteiro. Por isso quando ocorre Free ele acha que ainda existe o objeto instanciado. Pois o Free só apaga o objeto, mas não o Ponteiro. Nil por sua vez só apaga o ponteiro, mas o objeto permanece, ai tem leak de memória. Usar FreeAndNil.
Sobrecarga (overload): os métodos de uma mesma classe devem ter assinaturas diferentes. (Números diferentes de parâmetros ou parâmetros de tipos diferentes)
Para fazer sobreescrita, deve utilizar palavra reservada virtual no método da classe pai e palavra reservada override nas filhas. Se alguma não tiver override é executada a sua rotina.
Métodos no delphi por padrão são estáticos
Caso não seja definido o escopo de visibilidade é publica por padrão
RTTI lê qualquer escopo de visibilidade a partir do delphi 2010. Antes era apenas escopo PUBLISHED
Classes amigas são duas classes declaradas na mesma unit e que conseguem acessar as propriedades e métodos privados e protegidos uma da outra.
strict private:
só a própria classe acessa seus métodos e propriedades. Nem a classe amiga consegue acessar
strict protected:
só a própria classe ou sua herdada acessa seus métodos e propriedades. Nem a classe amiga consegue acessar
Encapsulamento: a mágica está no que o seu objeto pode ver. Quanto menos melhor, porque o objetivo é baixo acoplamento. Porque caso seja necessário mudança será menos dolorosa. Proteger o que varia. Fugir do Ctrl+C e Ctrl+V. Se vai copiar, encapsula e usa nos vários lugares
Associação é um canal de comunicação entre os objetos.
A herança é um tipo de associação vertical
Existe a possibilidade da associação horizontal

4 tipos de associação:

Simples
Agregação
Composição
Herança
Associação simples é um objeto fazendo uso do outro, mas não necessariamente para criar uma estrutura maior.
Agregação e composição fazem uma relação todo-parte.
Na agregação a parte é um objeto independente. Pode viver fora do todo.
Na composição a parte é um objeto dependente do todo. Não pode viver fora do todo.
No diagrama, o diamante (vazado na agregação e cheio na composição) fica no lado do todo

Ex: Todo-> reunião
Parte -> sala
(Agregação)

pauta = Composição

Composição: no construtor do todo vc constrói as partes. No destrutor vc destrói todas as partes. (Property)
Agregação: nem sempre é necessário criar as partes. Normalmente o objeto já vem pronto. (Listas de objeto)
Construtor de TObject é estático. Nunca sobreescreva (override)
Destrutor de Tobject é dinâmico. Sempre sobreescreva (override)
Coesão: uma classe, uma responsabilidade
Buscar a eficácia e não apenas a eficiência. Não adianta ser bonito se não traz o resultado
Formulário é uma classe e só serve pra apresentação
Camada de apresentação não deve ter regras de negócio
Acoplamento é a dependência entre as classes
Baixo acoplamento significa não ter um problema, um efeito colateral quando é realizada uma mudança

Arquitetura baseada em abstração:

Coesão: Camadas claramente definidas;
Interfaces formais e explicitas entre as camadas
Detalhes ocultos e protegidos dentro de cada camada. (Encapsulamento)
Interface: Declara o quê (cabeçalho)
define o que vai ser feito

Declaração com regras do que vai ser feito

Contrato de uma grande obra

Não tem field em interface, tem que declarar get e set quando declara uma propriedade

Interface que não herda de ninguém está herdando de IInterface

Interface não tem escopo de visibilidade
Todos os métodos e propriedades são públicos

Toda interface tem que ser assinada com um GUID

Classe concreta define o como vai ser feito

Padrões de Projeto:

Criacionais Resolver problemas de criação de objetos * Singleton * Factory * Builder
Comportamentais
Estruturais

Padrão Observer:
1 observado para 1 ou vários observadores
O observado não muda nada do observador. Dá só uma notificação e o observador decide o que faz com aquilo, porque cada observador pode fazer algo diferente.
Observado:
Attach
Detach
Notify

Observador:
Update

MVC não tem persistência. É outra coisa:

Model: tem métodos e propriedades
View: camada de apresentação onde estão as interações com usuário
Controller: fica no meio do caminho fazendo a ligação do view e model

DAO:

Resolver impedância entre objeto e SQL
DAOConnection Camada que gerencia a conexão
DAO Camada que converte o modelo para instrução SQL (ou txt......)
Uma classe de negócio, uma classe de persistência

RTTI é capacidade de extrair informações do objeto em tempo de execução

Criar uma rotina para diversas situações para ser usada de acordo com as informações que são extraídas do objeto

Uma classe para cada informação que se quer extrair. Fields, properties....

Todos são arrays dinâmicos. Uso de for in

Atributos customizados:
Informações adicionais do objeto sem alterar o objeto
declara entre colchetes [] em cima do elemento a ser atribuida a informação

Uso do Styled Components no React

Gustavo Inocencio — Wed, 14 Apr 2021 14:05:03 +0000

Na implementação de estilos para sua página o desenvolvedor tem a mão várias formas de incluir estilos. Desde o velho CSS até o uso de pré-processadores como Sass.

Ultimamente uma forma de inclusão de estilos que vem se destacando é a CSS-in-JS. Considerando a utilização de componentização em JavaScript, visando a reutilização dos mesmos componentes em diversas telas economizando tempo de desenvolvimento e a criação de soluções seguindo um design estabelecido para o sistema inteiro, o uso de CSS dentro de um componente Javascript pode ajudar nessa demanda.

Além disso, já é conhecido dos desenvolvedores que a colisão de estilos é um obstáculo que ocorre bastante nos projetos. Ela acontece quando você estiliza uma tag sem o uso de classes ou cria classes com os mesmos nomes para estilizar seus elementos.

E isso aumenta o uso de !important, uma manobra que pode ser traiçoeira ao realizar a manutenção do sistema depois, já que pode acabar fazendo necessário o uso de outro !important

Utilizando o CSS-in-JS esse problema não ocorre.

Explorando um pouco do universo de CSS-in-JS, existem algumas libs mais conhecidas:

O Styled Components, objeto de análise desse artigo, foi desenvolvido para que o desenvolvedor tenha uma maneira mais fácil de lidar com CSS nos componentes de aplicações React.

As vantagens presentes na lib são:

Critical CSS Automático: Os componentes são renderizados e injetam apenas seus estilos contribuindo para uma menor quantidade de código para o usuário final.

Sem colisão de classes: O styled-components fornece nomes de classes a prova de colisão. Nada mais de quebrar a cabeça só porque precisa mudar a posição ou cor de um objeto. Além disso, tudo que você precisa vai estar no próprio contexto do componente, facilitando o desenvolvimento.

Uso apenas do CSS necessário: Funcionando diretamente nos componentes, ajuda a diminuir o código final, pois o que não é necessário pode ser removido.

Estilo dinâmico simples: Adaptando os estilos baseando nas props recebidas, é possível criar estilos dinâmicos de forma fácil e intuitiva.

Vendor prefixing automático: Você escreve seu CSS no melhor padrão do mercado e pronto, os componentes cuidam para fornecer suporte para browsers antigos.

Exemplo de uso:

Testes de unidade em JavaScript

Gustavo Inocencio — Tue, 06 Apr 2021 13:42:52 +0000

O teste de unidade ou teste unitário em JavaScript é um método de teste no qual é testado um código JavaScript escrito para uma página web ou módulo de aplicativo web. Cada um dos testes de unidade servem para testar uma certa funcionalidade. Esses testes são então organizados em suítes de testes.

Cada suíte contém uma série de testes projetados a serem executados para um módulo separado. Eles não devem entrar em conflito com nenhum outro módulo e não devem ter muitas dependências entre si.

Para evitar desafios no momento de realizar testes de unidade as seguintes diretrizes são úteis:

Não use variáveis globais
Não manipule objetos predefinidos
Escreva funcionalidades core baseadas em bibliotecas
Tente criar pequenas funcionalidades com menos dependências

Melhores frameworks de teste de unidade de JavaScript

Unit.js: é conhecido como uma biblioteca de asserção de código aberto em execução no navegador e Node.js. É extremamente compatível com outra estrutura de teste de unidade de JavaScript como Mocha, Karma, Jasmine, QUnit, Protractor, etc. Fornece a API documentada completa da lista de asserções
QUnit: é usado para testes de unidade de JavaScript do lado do cliente e do lado do servidor. Este framework gratuito de teste JavaScript é usado para projetos jQuery. Ele segue a espeficação de teste de unidade da CommonJS.
Jasmine: Jasmine é o framework de desenvolvimento orientado a comportamento para testar código JavaScript. É usado para testar código tanto síncrono como assíncrono.
Karma: Karma é um ambiente open source de testes. Controle fácil do fluxo de trabalho executando na linha de comando. Oferece a liberdade de escrever testes com Jasmine, Mocha e QUnit. Você pode rodar os testes em dispositivos reais com um debbugging fácil.
Mocha: Mocha é executado em Node.js e no navegador. O Mocha realiza testes assíncronos de uma maneira mais simples. Fornece precisão e flexibilidade nos relatórios. Fornece um bom suporte de features como test-specific timeouts, JavaScript APIs etc.
Jest: Jest é usado pelo Facebook até agora para testar todo o código JavaScript. Ele fornece a experiência de teste de 'configuração zero'. Suporta teste de execução independente e sem interrupção, evitando qualquer conflito. Não requer nenhuma outra configuração de instalação e outras bibliotecas.
AVA: AVA é um framework de teste de unidade JavaScript simples. Os testes são executados em paralelo e em série. Os testes paralelos são executados sem interromper um ao outro. AVA também oferece suporte a testes assíncronos. AVA usa subprocessos para executar o teste de unidade.

Conclusão

Você deve sempre manter três coisas em mente ao realizar o teste:

O recurso que precisa ser testado;
A saída desejada para o teste;
A saída retornada no teste;

Os frameworks mencionados acima ajudam nessa tarefa, mas para facilitar seu trabalho sempre faça a implementação do código de modo a tornar fácil de ser garantido a sua eficácia.

Serialização e Deserialização utilizando ES6

Gustavo Inocencio — Wed, 31 Mar 2021 01:57:10 +0000

Pra começar, explicando o JSON:
JSON é um formato para distribuição de dados “pela rede” e pode ser facilmente compreendido e gerado tanto por humanos quanto por computadores.

Serialização
Serialização é um processo em que um formato de dados é traduzido para um outro formato de dados (JSON) para ser facilmente distribuído.
O reverso da serialização é a deserialização, em que se transforma um formato de dados recebido em sua forma original, para que possa manipulá-lo e usá-lo no aplicativo.

Um exemplo de serialização é o a seguir:

let person = {  
  name: 'Atena',  
  age: 33
}; 
const serialized =   JSON.stringify(person); 
console.log(serialized); // {"name":"Atena","age":33}

Para realizar a deserialização deve-se usar JSON.parse como demonstrado a seguir:

  const storedItem = sessionStorage.getItem(MENUS_DOCS);
  if (storedItem) itemParsed = JSON.parse(storedItem);

O objetivo desse artigo foi ser um resumo rápido para quem precisar realizar a serialização.

Mais informações podem ser consultadas em:
https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify

https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

Lei de Demeter

Gustavo Inocencio — Wed, 24 Mar 2021 19:44:39 +0000

A Lei de Demeter ou principio do conhecimento minimo é uma diretriz de desenvolvimento de software, particularmente de sistemas que utilizam a programação orientada a objetos.
— Wikipedia

Esta lei foi proposta por Ian Holland em 1987. Holland e seus colegas estavam programando um sistema chamado Demeter usando programação orientada a objetos. Durante o desenvolvimento do sistema, eles perceberam que o código que atendia a uma série de regras era menos acoplado.

A Lei de Demeter exige que um método m de um objeto O só pode invocar os métodos dos seguintes tipos de objetos:

O próprio.
parâmetros de m.
Quaisquer objetos criados / instanciados em m.
Objetos componentes diretos de O.
Uma variável global, acessível por O, no escopo de m.

Em resumo, todas as regras acima podem ser resumidas dizendo que você deve evitar invocar métodos de um objeto retornado por outro método. Em linguagens orientadas a objetos modernas, o identificador usado é ponto ou ->. Portanto, a lei de Demeter é violada quando o código tem mais de uma etapa entre as classes.

Um exemplo de código em que a lei de Demeter é violada é apresentado a seguir:

const data = cliente.ultimoPedido.dadosPedido.dataEmissao

Nesse caso é conhecido a estrutura interna do objeto ultimoPedido. O problema nisso é que em uma modificação da classe ultimoPedido, as propriedades podem não existir mais e assim ocorrerá uma quebra no sistema, um chamado a uma propriedade nula.

Nesse caso o ideal é que seja feito na classe ultimoPedido um getDataEmissao para ser usado em outras classes.

const data = ultimoPedido.getDataEmissao()

Assim, mesmo que se modifique a classe ultimoPedido o método ainda existe e vai retornar a informação necessária.

Principais Vantagens

Dependências entre classes e acoplamento são reduzidas.
Classes podem ser reutilizadas com facilidade.
Código é mais fácil de testar.
Código é mais fácil de manter e flexível para mudanças.

Uso de Promises

Gustavo Inocencio — Wed, 17 Mar 2021 19:20:04 +0000

Na programação assíncrona um recurso bastante utilizado é o de Promises, já que sempre queremos que nossas operações e nosso código rodem o mais rápido possível,
assim um recurso que nos permite paralelizar o máximo de ações é extremamente útil.

A estrutura de uma Promise é a seguinte:

// Criando uma promise
const p = new Promise((resolve, reject) => {
  try {
    resolve(funcaoX())
  } catch (e) {
    reject(e)
  }
})

// Executando uma promise
p
  .then((parametros) => /* sucesso */)
  .catch((erro) => /* erro */)

// Tratando erros e sucessos no then
p
  .then(resposta => { /* tratar resposta */ }, erro => { /* tratar erro */ })

Nesse artigo citarei algumas funcionalidades de Promises quando existe a necessidade de executar mais de uma.

Promise.race: executa a mais rápida
Nessa funcionalidade todas as promises iniciam a execução ao mesmo tempo, mas apenas a primeira a ser resolvida tem seu valor retornado.
Essa funcionalidade permite que sejam utilizados mais de uma fonte para a informação buscada e assim ter a mais rápida do momento.

Promise.all: executa todas
Nessa funcionalidade todas as promises iniciam a execução ao mesmo tempo e vão sendo resolvidas.
O problema dessa funcionalidade é que se uma das promises for rejeitada todas são rejeitadas. Essa funcionalidade pode ser usada quando existem várias consultas a APIs diferentes a serem feitas para uma mesma tela e todas as informações precisam ser mostradas.

Promise.allsettled: executa todas, mesmo que falhe e retorna a informação de cada uma se falhou ou não

Assim como Promise.all, nessa funcionalidade todas as promises iniciam a execução ao mesmo tempo e vão sendo resolvidas.
Mas se uma das promises for rejeitada as outras ainda são resolvidas. Essa funcionalidade pode ser usada quando existem várias consultas a APIs diferentes a serem feitas para uma mesma tela, mas para componentes diferentes. Por exemplo, um dashboard. Assim, se uma das informações não for trazida, as outras ainda podem ser apresentadas.

Mais informações sobre Promises podem ser encontradas em:
https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Promise