DEV Community: Lucas Cavalcante

Mas afinal, o que significa escalar a aplicação?

Lucas Cavalcante — Wed, 19 May 2021 22:49:27 +0000

Resolvi criar este post com o objetivo de destrinchar em pequenas partes o macro-conceito de "escalar a aplicação".

Hoje em dia, ouvimos muito falar sobre criação de aplicações estáveis e escaláveis, que sejam tolerante à falhas, que façam balanceamento de carga, etc. Para quem já se perdeu na parte de "aplicações estáveis..." o resto já começa a não fazer nenhum sentido.

Então, vamos lá começar a destrinchar essa sopa de palavras e tentar deixar os conceitos mais claros e acessíveis para todas as pessoas.

Arquitetura Tradicional

Antes de começarmos a falar de uma arquitetura escalável, vamos entender como que funciona uma arquitetura tradicional, que não leva em conta variáveis de escala.

Na imagem, temos o clássico exemplo de arquitetura cliente-servidor. Onde tudo fica hospedado em um servidor, com uma estrutura básica contendo um servidor web (como o Apache, IIS, etc) e um banco de dados (como o MySQL, MongoDB, etc).

Esse servidor fica aguardando alguma requisição vinda de algum cliente para processar e devolver a este mesmo cliente o resultado esperado.

Arquitetura Escalável

A arquitetura escalável é focada em resolver problemas de sobrecarga de acessos e, a partir daí, gerenciar melhor os recursos para evitar um custo altíssimo com toda essa estrutura que podemos configurar.

Quanto mais a sua aplicação ganha usuários, maior será a quantidade de requisições que ela irá receber simultaneamente. E quanto maior for esse número, maior terá que ser sua preocupação com a infraestrutura em termos de dimensionamento (escala).

E quando falamos de dimensionamento, temos 2 tipos conhecidos: vertical e horizontal.

Dimensionamento Vertical (Vertical Scaling)

Em linhas gerais, quando falamos em "escalar verticalmente", significa que vamos aumentar os recursos do servidor para aguentar mais requisições. Mas é praticamente a mesma arquitetura que vimos no modelo tradicional.

Está estourando a memória? Aumenta a memória!

Está travando os processos? Aumenta os núcleos do processador!

Não preciso nem dizer que esse tipo de solução não vai resolver todos os nossos problemas, né? Já pensou se seu servidor já está com 32 núcleos e 128 GB de memória e ainda continua estourando memória e travando os processos? Se a gente continuar escalando verticalmente, a conta vai sair muito cara e só resolverá temporariamente até precisar escalar novamente, e por aí vai!

Além disso, o dimensionamento vertical nos traz outro problema: não é tolerante à falhas! Se o servidor cair, a aplicação irá fora do ar até que alguém resolva o problema.

Com esse problemas, vamos ao outro tipo de dimensionamento: o horizontal.

Dimensionamento Horizontal (Horizontal Scaling)

Os problemas citados anteriormente podem ser resolvidos agora. Afinal, como poderemos aceitar milhares/milhões de requsições sem afetar nossa infra?

Resposta curta: instâncias!

Tanto para o servidor, como para o banco de dados, podemos criar instâncias que irão receber o tráfego de acordo com a demanda.

No banco de dados, quando temos excesso de tráfego corremos o risco de derrubar o banco e ficar com a aplicação dando erro de conexão. Afinal, o banco não está mais lá, né?

Para isso, usamos a estratégia do source/replica (termo usado pela MySQL para substituir o obsoleto termo master/slave. Se você quer entender melhor essa mudança, pode conferir nessa página do Wikipedia).

Essa estratégia consiste, basicamente, em replicar o banco de dados e quando o original (source) cair, promovemos a cópia (replica) para ser utilizada.

No servidor, quando começamos a ter os problemas de memória e quedas que mencionei anteriormente, ao invés de aumentar os recursos, criamos uma nova "cópia". Sendo assim, conforme o tráfego vai aumentando, as novas requisições vão sendo direcionadas para as outras instâncias.

Podemos fazer esse direcionamento de duas formas: utilizando a estratégia round robin onde cada nova requisição vai sendo direcionada para uma nova instância, e quando chegar na última volta para a primeira e assim sucessivamente. Ou podemos criar filtros no serviço de cloud utilizado para só direcionar para a próxima instância quando a capacidade estiver acima de 80% por exemplo.

Mas quem é o responsável por direcionar as requisições para as instâncias? O famoso balanceador de carga!

Balanceador de Carga (Load Balancer)

O balanceador é quem direciona as requisições para as instâncias de acordo com as regras definidas (round robin ou de acordo com a sobrecarga). Ele funciona como uma camada intermediária entre o cliente e o servidor. E ele usa os IP's das instâcias para fazer esse processo de roteamento.

Usando o balanceador de carga nós podemos ter o mesmo problema de não ser tolerante à falhas, e caso ele caia, nossa aplicação não conseguirá ser acessada, mesmo que os servidores e o banco de dados estejam funcionando perfeitamente. Em casos como esse, podemos ter um balanceador como backup.

Bom, os problemas de sobrecarga de requisições e tolerância à falhas foram resolvidos até aqui. Mas, como essas instâncias são criadas?

Uma estratégia é criar alertas. Posso criar um que, toda vez que a minha instância estiver usando mais de 80%, recebo uma notificação no meu celular. Aí vou lá e, manualmente, crio mais uma instância.

Resolve? Sim! Mas aí temos mais dois problemas: dependência da intervenção humana, e desperdício de recursos.

Intervenção humana: nem sempre a pessoa responsável pode estar disponível.

Desperdício de recursos: você vai lá e cria uma nova instância por causa da sobrecarga de requisições, mas e quando o tráfego baixar? Você vai ficar com duas instâncias, sendo que naquele momento bastava apenas uma. E isso custa muito dinheiro! 😅

A solução aqui é o dimensionamento automatizado.

Dimensionamento Automatizado (Auto Scaling)

O nome é bem auto-explicativo. Podemos criar alguns filtros para provisionar e destruir as instâncias de acordo com a necessidade.

Na imagem podemos ver que existem grupos de auto scaling. Esses grupos devem conter um nome e uma capacidade mínima e máxima de instâncias que devem ser provisionadas. Você também pode especificar a capacidade desejada, que é o número de instâncias que o grupo deve ter por padrão.

Se você não especificar uma capacidade desejada, a capacidade mínima será o padrão.

Bom, um problema a menos agora que temos tudo automatizado.

Quando uma pessoa usuária acessa nossa aplicação ela é direcionada para a instância X. Nessa instância, ela se autentica e acessa a área para usuários autenticados. Quando clicar para ir à outra página, esse pessoa recebe o erro que essa é uma área para pessoas autenticadas, e direciona para o login.

Ué? O que aconteceu aqui? Ela não acabou de se autenticar? Por que está pedindo para se autenticar novamente?

Quando trabalhamos com mais de uma instância temos o problema de perda de sessão entre uma instância e outra. Porque sessões são armazenadas na própria instância e não tem como compartilhá-las entre instâncias.

A pessoa do exemplo acima, se logou na instância X. Quando ela clicou para ir à outra página, ela foi direcionada para a instância Y, mas a sessão de autenticação dela estava apenas na instância X.

E aí? Como resolver isso?

A solução para esse problema tem nome: camada de cache.

Camada de Cache (Cache Layer)

A camada de cache é responsável por armazenar as sessões e compartilhá-las entre as instâncias, evitando o problema que vimos acima.

Existem algumas ferramentas que fazem esse papel. Na imagem acima eu usei o logo do Redis que é uma das mais mais conhecidas (na realidade o Redis é um banco de dados do tipo key-value que armazena os dados na memória RAM do servidor, e que acaba sendo usado como ferramenta de cache por conta dessa principal característica).

Além de armazenar e compartilhar sessões, a camada de cache também ajuda bastante em outro problema muito recorrente quando estamos escalando a aplicação: fazer consultas no banco de dados custa dinheiro, e se você ficar fazendo consultas constantes que poderiam ser evitadas, sua conta no final do mês vai sair bem carinha! 😱

Então, na camada de cache, podemos armazenar informações que não irão se alterar com muita frequência. Por exemplo, podemos armazenar os artigos recomendados para aquela pessoa de acordo com os que ela leu. Se em todas as páginas que essa pessoa visitar fossemos fazer uma consulta no banco... já sabe né? 💸

Então, podemos criar um script para quando essa pessoa acessar nossa aplicação pela primeira vez no dia, vamos buscar no banco (para pegar dados atualizados), senão, vamos buscar na camada de cache.

Princípios SOLID: o que são e como aplicá-los no PHP/Laravel (Parte 05 - Inversão de Dependência)

Lucas Cavalcante — Wed, 17 Mar 2021 22:17:07 +0000

Dando continuidade à série de artigos sobre princípios SOLID, trago hoje o quinto e último dos princípios.

Dependency Inversion Principle

(Princípio da Inversão de Dependência)

Entidades devem depender de abstrações e não de algo concreto. Isso significa que módulos de alto nível não podem depender de módulos de baixo nível, e sim de abstrações.

Como eu citei na parte 04 "abstração é o coração da orientação a objetos. Em PHP, nós conseguimos alcançar um nível de abstração utilizando interfaces e classes abstratas". Ou seja, assim como na parte 04 nós vamos aplicar o nosso exemplo de Employees e Contractor usando interfaces.

Quando trabalhamos com arquitetura em camadas (que no nosso caso é as camadas Controller, Service, Repository e Model) o ideal é que possamos seguir o fluxo da requisição a partir do Controller, e que as camadas mais externas não saibam nada do que acontece nas camadas mais internas.

Por exemplo:

O Controller não pode depender diretamente do Service, assim como o Service não pode depender da camada de Repository.

Mas por quê?

Pois dessa forma essas camadas estariam dependendo de implementações concretas. Ou seja, se eu mudar alguma coisa no meu Service, pode impactar diretamente no Controller e acabar "quebrando" a aplicação. Isso aumenta o acoplamento entre as classes, o que é uma má prática.

E como resolver isso?

Com a inversão de dependência!

Na parte 04, criei 2 interfaces com o objetivo de deixá-las segregadas, cada uma com suas particularidades.

interface UserInterface
{
  public function register(array $attributes, UserRepository $userRepository);
}

interface ContractorInterface
{
  public function calcWorkedHours(array $hours);
}

Para poder fazer a inversão de dependência, eu preciso injetar a interface do Service no Controller. Mas como fazer isso se temos duas interfaces?

A resposta é simples: herança!

Eu vou criar uma interface, e as duas interfaces criadas anteriormente (UserInterface e ContractorInterface) irão estendê-la.

interface ServiceInterface
{
}

interface UserInterface extends ServiceInterface
{
  public function register(array $attributes, UserRepository $userRepository);
}

interface ContractorInterface extends ServiceInterface
{
  public function calcWorkedHours(array $hours);
}

Dessa forma, conseguimos concentrar toda essa camada de abstração em um único ponto.

Agora, vamos ao Controller e vamos injetar essa interface.

class UserRegistrationController extends Controller
{
    protected $userService;

    public function __construct(ServiceInterface $userService)
    {
        $this->userService = $userService;
    }

    // implementação do código
}

Percebam que mesmo o nosso atributo seja nomeado como $userService, ele é do tipo ServiceInterface. E dessa forma evitamos um forte acoplamento entre as camadas concretas, deixando todo serviço a cargo da abstração, que no nosso caso é a ServiceInterface.

Fica aqui o desafio: tente fazer o mesmo processo entre as camadas de Service e Repository. :)

Espero que tenham gostado dessa série de artigos sobre SOLID, e em breve trarei novos conteúdos.

Fui!

Princípios SOLID: o que são e como aplicá-los no PHP/Laravel (Parte 04 - Segregação de Interface)

Lucas Cavalcante — Thu, 12 Nov 2020 19:22:29 +0000

Depois de um longo hiato, estou retomando a série dos príncipios SOLID, trazendo o quarto dos princípios.

Interface Segregation Principle

(Princípio da Segregação de Interface)

Uma classe não deve ser forçada a implementar interfaces que não irá utilizar.

Abstração é o coração da orientação a objetos. Em PHP, nós conseguimos alcançar um nível de abstração utilizando interfaces e classes abstratas.

Mas, antes, vamos dar um passo atrás: o que é interface?

Interface é um conjuntos de abstrações que todas as classes que a implementam deve seguir. Cada método adicionado na interface é uma assinatura, e a partir do momento que uma classe a implementa, esta fica obrigada a adicionar todas as assinaturas previamente criadas na interface.

Partindo deste princípio, parece óbvio que uma classe não deva ser forçada a implementar algo que não irá usar. Mas nesse artigo, você verá que este princípio é muito fácil de violar.

Seguindo o nosso exemplo de Employees e Contractors, até o terceiro post da série eu criei uma classe chamada UserService que injeta os repositories para os dois tipos de usuário.

Vamos fazer uma pequena alteração, a partir de agora será um service para cada tipo de usuário.

class EmployeeService
{
  protected $employeeRepository;

  public function __construct(EmployeeRepository $employeeRepository)
  {
    $this->userRepository = $userRepository;
  }
}

class ContractorService
{
  protected $contractorRepository;

  public function __construct(ContractorRepository $contractorRepository)
  {
    $this->contractorRepository = $contractorRepository;
  }
}

Dessa maneira eu terei duas classes que irão implementar a mesma interface UserInterface.

interface UserInterface
{
  public function register(array $attributes, UserRepository $userRepository);
  public function calcWorkedHours(array $hours);
}

Interface criada com a assinatura do método register (que foi criado nos posts anteriores), e agora adicionei o método calcWorkedHours que será um método útil para o usuário do tipo Contractor onde as horas dele serão calculadas para gerar o pagamento no fim do mês.

Vamos implementar a interface nos dois services.

class EmployeeService implements UserInterface
{
  public function register(array $attributes, UserRepository $userRepository)
  {
    // implementação do código
  }
}

class ContractorService implements UserInterface
{
  public function register(array $attributes, UserRepository $userRepository)
  {
    // implementação do código
  }

  public function calcWorkedHours(array $hours)
  {
    // implementação do código
  }
}

Dessa maneira nós vamos ter um erro na classe EmployeeService pois ela implementa a UserInterface mas não usa o método calcWorkedHours.

Uma maneira errada de resolver isso seria implementar o método, mas sem nenhuma implementação dentro do escopo.

A maneira correta seria criar duas interfaces e implementá-las onde for necessário.

interface UserInterface
{
  public function register(array $attributes, UserRepository $userRepository);
}

interface ContractorInterface
{
  public function calcWorkedHours(array $hours);
}

E após criar as duas interfaces, as classes já poderiam escolher quem implementar.

class EmployeeService implements UserInterface
{
  public function register(array $attributes, UserRepository $userRepository)
  {
    // implementação do código
  }
}

class ContractorService implements UserInterface, ContractorInterface
{
  public function register(array $attributes, UserRepository $userRepository)
  {
    // implementação do código
  }

  public function calcWorkedHours(array $hours)
  {
    // implementação do código
  }
}

Dessa maneira, não obrigamos nenhuma classe a implementar algo que não irá utilizar. Sendo assim, não violamos o princípio da segregação de interface. :)

Quando tentamos entender apenas a teoria dos princípios, parecem bem mais complicados do que realmente são.

No próximo, e último, artigo da série vou falar sobre o Dependency Inversion Principle (Princípio da Inversão de Dependência).

Dúvidas e feedbacks são sempre bem-vindos.

Retomando os posts e geração de conteúdo

Lucas Cavalcante — Thu, 12 Nov 2020 18:20:32 +0000

Olá, pessoal!

Passei um tempo sem postar nada, mas nas últimas semanas retomei o engajamento e criei:

Um canal no youtube: https://www.youtube.com/lucascavalcante81
Um site: http://lucascavalcante.com

Além disso, aumentei minha frequência de postagens:

Linkedin: https://www.linkedin.com/in/lucascavalcante
Twitter: https://twitter.com/lucascgomes

E agora vou retomar meus posts aqui no dev.to!

Podem me adicionar nas redes e se inscrevam no meu canal pois os conteúdos nem sempre serão os mesmos.

Grande abraço! 🤙

4 maneiras de criar componentes no React

Lucas Cavalcante — Wed, 17 Jun 2020 22:59:13 +0000

Durante a quarentena eu fiz um post no meu Linkedin divulgando o "April Free Month" da Pluralsight. Eles ofereceram todos os cursos das plataforma de forma gratuita durante o mês de Abril.

Eu aproveitei a oportunidade para fazer a trilha de React. Sempre tive contatos básicos com React, fazendo pequenas alterações, mas nunca me aprofundei na arquitetura.

E digo com todas as letras que valeu muito a pena. Fiz 5 cursos de React do básico ao avançado, e todos muitos bons. (principalmente os do Cory House)

Desde então o que tenho feito para fixar o aprendizado: estou criando uma aplicação usando React no front (logo mais vou divulgar), e decidi criar conteúdo.

Portanto esse é o primeiro artigo sobre React que estou escrevendo.

Vamos lá!

Como dito, podemos criar os componentes de 4 diferente formas.

Para todos os exemplos, vamos fazer um botão que incremente o contador.

ES6 Class Component

Esse era o modo mais usado antes da versão 16.8 do React. Pois era o que melhor trabalhava com ciclos de vida do componente.

class Counter extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      counter: 0
    };

    this.handleClick = this.handleClick.bind(this);
  }

  handleClick() {
    this.setState({
      counter: this.state.counter + 1
    });
  }

  render() {
    return (
      <>
        <h1>{this.state.counter}</h1>
        <button onClick={this.handleClick}>+1</button>
      </>
    );
  }
}

ReactDOM.render(
  <Counter />,
  document.getElementById('app')
);

Um dos problemas deste formato era o problema de escopo, sempre que criamos uma função, temos que criar um bind para esta função como ajuste de escopo. E além disso, tinha o uso constante da palavra-chave this.

Você pode ver o exemplo neste link.

CreateReactClass Component

Este maneira está em desuso nos dias de hoje por conta da complexidade e quantidade de código que temos que escrever. Ela se assemelha à forma como criávamos objetos no ES5.

const Counter = createReactClass({
  getDefaultProps: function() {
    return { initialCount: 0 };
  },
  getInitialState: function() {
    return { counter: this.props.initialCount };
  },
  handleClick: function() {
    this.setState({
      counter: this.state.counter + 1
    });
  },
  render: function() {
    return (
      <>
        <h1>{this.state.counter}</h1>
        <button onClick={this.handleClick}>+1</button>
      </>
    );
  }
});

ReactDOM.render(
  <Counter />,
  document.getElementById('app')
);

Neste formato também usamos a palavra-chave this.

Você pode ver o exemplo neste link.

Functional Component

Este é o formato mais usado atualmente (após o lançamento da versão 16.8), pois é o que melhor trabalha com os Hooks, evitando o uso do ciclo de vida do componente, além de evitar a palavra-chave this.

Além disso, existe a proposta que as classes do React deixem de existir em um futuro próximo.

function Counter() {
  const [counter, setCounter] = React.useState(0);

  function handleClick() {
    setCounter(counter + 1);
  }

  return (
    <>
      <h1>{counter}</h1>
      <button onClick={handleClick}>+1</button>
    </>
  );
}

ReactDOM.render(
  <Counter />,
  document.getElementById('app')
);

Neste exemplo é perceptível como tivemos que escrever menos código. Aqui, usamos o hook useState que trabalha o controle de estado dos objetos.

Você pode ver o exemplo neste link.

Arrow Function Component

Este formato é bastante parecido com o anterior, e é bastante usado para criar componentes apenas com JSX. Por conta disso, alterei um pouco o exemplo, adicionando 2 componentes que renderizam os elementos HTML.

const Counter = () => {
  const [counter, setCounter] = React.useState(0);

  function handleClick() {
    setCounter(counter + 1);
  }

  return (
    <>
      <Header label={counter} />
      <Button
        whenClicked={handleClick}
        label="+1"
      />
    </>
  );
}

const Header = (props) => <h1>{props.label}</h1>;
const Button = (props) => (
  <button onClick={props.whenClicked}>
    {props.label}
  </button>
);

ReactDOM.render(
  <Counter />,
  document.getElementById('app')
);

Você pode ver o exemplo neste link.

E aí, o que achou?

Qualquer sugestão e/ou feedback sempre serão muito bem-vindos.

Até o próximo artigo! ✋

Princípios SOLID: o que são e como aplicá-los no PHP/Laravel (Parte 03 - Substituição de Liskov)

Lucas Cavalcante — Mon, 15 Jun 2020 22:56:37 +0000

Dando continuidade à série de artigos sobre princípios SOLID, hoje vou falar sobre o terceiro dos princípios.

Liskov Substitution Principle

(Princípio da Substituição de Liskov)

Uma classe derivada deve ser substituída por sua classe base.

Este princípio tem este nome porque foi introduzido por Barbara Liskov em sua apresentação "Data Abstraction" em 1987. Alguns anos mais tarde, ela publicou um artigo, junto com Jeanette Wing, onde elas definiram o princípio como:

Seja Φ(x) uma provável propriedade sobre objetos x do tipo T. Então Φ(y) deve ser verdadeira para objetos y do tipo S, em que S é um subtipo de T.

Uma definição um tanto quanto complexa, não é mesmo? Normal, quando se trata de um artigo científico. Vamos simplificar e ver como isso se aplica na prática.

Continuando o nosso exemplo de Employees e Contractors, no primeiro artigo dessa série eu criei 2 repositories para ambos os perfis de usuário, e os injetei como dependência no UserService.

class UserService
{
    protected $employeeRepository;
    protected $contractorRepository;

    public function __construct(
        EmployeeRepository $employeeRepository,
        ContractorRepository $contractorRepository
    )
    {
        $this->userRepository = $userRepository;
        $this->contractorRepository = $contractorRepository;
    }

    public function register(Request $request)
    {
        $attributes = $request->all();
        if($attributes['type'] === 'employee') {
            $this->employeeRepository->save($attributes);
        }

        if($attributes['type'] === 'contractor') {
            $this->contractorRepository->save($attributes);
        }
    }
}

No segundo artigo da série, eu criei um arquivo BaseRepository que seria a classe pai de EmployeeRepository e ContractorRepository.

É muito simples aplicar a substituição de Liskov.

Primeiro vamos criar um repository intermediário entre a classe pai e as classes filhas.

class BaseRepository
{
    // seu código
}

class UserRepository extends BaseRepository
{
    // seu código
}

class EmployeeRepository extends UserRepository
{
    // seu código
}

class ContractorRepository extends UserRepository
{
    // seu código
}

Dessa forma, a BaseRepository continua sendo "base" para outros repositories também, e a UserRepository vira a classe pai das outras duas.

Agora vamos fazer uma pequena alteração no classe UserService.

class UserService
{
    protected $employeeRepository;
    protected $contractorRepository;

    public function __construct(
        EmployeeRepository $employeeRepository,
        ContractorRepository $contractorRepository
    )
    {
        $this->userRepository = $userRepository;
        $this->contractorRepository = $contractorRepository;
    }

    public function checkUserType(Request $request)
    {
        $attributes = $request->all();
        if($attributes['type'] === 'employee') {
            $this->register($attributes, $this->employeeRepository);
        }

        if($attributes['type'] === 'contractor') {
            $this->register($attributes, $this->contractorRepository);
        }
    }

    public function register(array $attributes, UserRepository $userRepository)
    {
        $userRepository->save($attributes);
    }
}

Renomeei o método register() para checkUserType() onde continua sendo feita a validação do tipo de usuário. Mas, ao invés de chamar diretamente o repository, agora chama outro método dentro desta mesma classe, que por sua vez, agora se chama register() e recebe como parâmetro o array $attributes e uma instância de UserRepository.

Independentemente de qual dos repositories for passado como parâmetro, ambos são do tipo UserRepository e quando for chamado o método save(), irá chamar de acordo com o que foi passado.

Dessa forma, nós temos a chamada para o repository de uma forma mais centralizada, e mantendo o mesmo tipo de objeto na passagem do parâmetro.

Espero que tenha ficado claro para você. Caso contrário, comente aí sua dúvida.

E aí, gostou? No próximo artigo da série vou falar sobre o Interface Segregation Principle (Princípio da Segregação de Interface)

Dúvidas e feedbacks são sempre bem-vindos.

Princípios SOLID: o que são e como aplicá-los no PHP/Laravel (Parte 02 - Aberto-fechado)

Lucas Cavalcante — Wed, 27 May 2020 23:19:38 +0000

Dando continuidade à série de artigos sobre princípios SOLID, hoje vou falar sobre o segundo dos princípios.

Open-closed Principle

(Princípio Aberto-fechado)

Objetos ou entidades devem ser abertas para extensão, mas fechadas para modificação.

Em outras palavras, se eu tenho uma classe genérica que atende a diversos tipos de perfis, ao invés de sair fazer condicionais para cada caso, podemos criar especializações dessa classe, e em cada uma delas eu coloco o que atende aquele perfil.

Vamos continuar o exemplo que eu usei no artigo anterior, onde nós temos 2 tipos de User, o Employee e o Contractor.

Você pode ver aqui que eu criei 2 Repositories, um para cada tipo de usuário, e em ambas eu criei o método save() executando exatamente a mesma coisa. (no final do artigo eu expliquei que usei dessa maneira para facilitar o entendimento da separação de responsabilidades)

Então, vamos melhorar esse código.

class BaseRepository
{
    protected $obj;

    protected function __construct(object $obj)
    {
        $this->obj = $obj;
    }

    public function all(): object
    {
        return $this->obj->all();
    }

    public function find(int $id): object
    {
        return $this->obj->find($id);
    }

    public function findByColumn(string $column, $value): object
    {
        return $this->obj->where($column, $value)->get();
    }

    public function save(array $attributes): bool
    {
        return $this->obj->insert($attributes);
    }

    public function update(int $id, array $attributes): bool
    {
        return $this->obj->find($id)->update($attributes);
    }
}

Criei uma classe BaseRepository que como o próprio nome diz, serve como base para classes especialistas, contendo os métodos que são genéricos a todas as classes que irão estendê-la.

Vamos criar as classes filhas (ou especialistas).

class EmployeeRepository extends BaseRepository
{
    protected $employee;

    public function __construct(Employee $employee)
    {
        parent::__construct($employee);
    }
}

class ContractorRepository extends BaseRepository
{
    protected $contractor;

    public function __construct(Contractor $contractor)
    {
        parent::__construct($contractor);
    }
}

Se as classes EmployeeRepository e ContractorRepository não tiverem nenhuma especificidade, basta criá-las apenas com o construtor chamando a classe pai que todos os métodos irão funcionar. Na camada de Service quando formos fazer a injeção de dependência, injetamos a classe especialista.

Mas utilizando alguns princípios da orientação a objetos, vamos fazer algo específico para cada uma delas.

class EmployeeRepository extends BaseRepository
{
    protected $employee;

    public function __construct(Employee $employee)
    {
        parent::__construct($employee);
    }

    public function all(): object
    {
        $except = [3,17,22];
        return $this->employee->whereNotIn('id', $except)->get();
    }
}

class ContractorRepository extends BaseRepository
{
    protected $contractor;

    public function __construct(Contractor $contractor)
    {
        parent::__construct($contractor);
    }

    public function save(array $attributes, int $hoursPerWeek): bool
    {
        $attributes['hours_per_week'] = $hoursPerWeek;
        return $this->contractor->insert($attributes);
    }
}

Na classe EmployeeRepository eu fiz uma sobreposição do método all() onde quase tudo é igual à classe pai (nome, parâmetros, retorno) exceto a implementação.

Na classe ContractorRepository eu fiz uma sobrecarga do método save() onde o nome do método é o mesmo da classe pai, mas a quantidade e/ou tipo dos parâmetros é diferente.

Dessa forma consegui deixar ambas as classes mais especializadas sem interferir na classe pai, ou perder suas características.

Espero que tenha gostado. No próximo artigo da série vou falar sobre o Liskov Substitution Principle (Princípio da Substituição de Liskov)

Dúvidas e feedbacks são sempre bem-vindos.

Princípios SOLID: o que são e como aplicá-los no PHP/Laravel (Parte 01 - Responsabilidade Única)

Lucas Cavalcante — Thu, 21 May 2020 23:00:01 +0000

Hoje vou abordar um dos temas que mais me interessa dentro do mundo do desenvolvimento de software: escrever códigos melhores.

Dentro deste tema costuma-se falar de arquitetura de software, padrões de projeto, design de software, etc.

Nesta série de artigos vou abordar o SOLID que é um princípio de design de software orientado a objeto (OOD). Basicamente, SOLID é um acrônimo para:

S - Single Responsibility Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Vamos entender como funciona cada um deles e exemplicar usando o PHP. Mais especificamente o Laravel, por ser um framework que adota o MVC por padrão e, com o crescimento da aplicação, tende a ficar com o código/estrutura bem bagunçados se não organizar desde o começo.

Então, neste primeiro artigo vamos abordar o primeiro dos princípios de forma detalhada.

Single Responsibility Principle

(Princípio da Responsabilidade Única)

Uma classe deve ter uma e apenas uma razão para mudança, significando que uma classe deve ter apenas uma responsabilidade.

Este é o primeiro, mais simples, e mais importante princípio, pois parte da premissa que toda classe deve ter apenas 1 objetivo quando se trata do fluxo de uma requisição do software.

Vamos dar uma olhada no exemplo abaixo:

class UserRegistrationController extends Controller
{
    public function register(Request $request)
    {
        $attributes = $request->all();
        if($attributes['type'] === 'employee') {
            $this->saveEmployee($attributes);
        }

        if($attributes['type'] === 'contractor') {
            $this->saveContractor($attributes);
        }

        return view('user.register');
    }

    public function saveEmployee($request)
    {
        DB::table('employees')->insert([
            /* Dados do funcionário aqui... */
        ]);
    }

    public function saveContractor($request)
    {
        DB::table('employees')->insert([
            /* Dados do terceirizado aqui... */
        ]);
    }
}

Esta classe acima viola o princípio da responsabilidade única pelos motivos a seguir:

Mistura responsabilidades. Um Controller deve ser responsável por apenas gerenciar requests e responses.
Regra de negócio de ser aplicada em uma camada separada, como a camada de Service, por exemplo. (que não tem como padrão no Laravel, mas podemos criá-la manualmente)
Operações com o banco de dados também devem estar em outra camada. No Laravel, por padrão, usamos o Model. Mas no neste artigo vou usar a camada de Repository. (mesmo caso do Service)

Vamos corrigir a classe:

class UserRegistrationController extends Controller
{
    protected $userService;

    public function __construct(UserService $userService)
    {
        $this->userService = $userService;
    }

    public function register(Request $request)
    {
        $userService->register($request);

        return view('user.register');

    }
}

Aqui deixamos o Controller isolado com a sua única responsabilidade: gerenciar a request e a response.

No Laravel, para podermos adicionar uma camada de comunicação com a classe atual, nós usamos a injeção de dependência nativa do framework. Basta adicionar a classe desejada como parâmetro no construtor e atribuí-la em uma propriedade da classe. E eu fiz isso adicionando a classe UserService.

Vamos entender agora a classe UserService:

class UserService
{
    protected $employeeRepository;
    protected $contractorRepository;

    public function __construct(
        EmployeeRepository $employeeRepository,
        ContractorRepository $contractorRepository
    )
    {
        $this->userRepository = $userRepository;
        $this->contractorRepository = $contractorRepository;
    }

    public function register(Request $request)
    {
        $attributes = $request->all();
        if($attributes['type'] === 'employee') {
            $this->employeeRepository->save($attributes);
        }

        if($attributes['type'] === 'contractor') {
            $this->contractorRepository->save($attributes);
        }
    }
}

O Service é o local onde colocamos toda a regra de negócio, como é o caso do condicional que usamos para identificar o tipo de usuário.

Aqui também usamos a injeção de dependência, mas importamos 2 classes. Exatamente os Repositories dos tipos de usuário. Como o Model é a representação da tabela do banco dentro da aplicação, e o Repository é reponsável pela operação de banco de cada Model, nada mais coerente mantê-los separados.

Vamos entender agora os Repositories:

class EmployeeRespository
{
    protected $employee;

    public function __construct(Employee $employee)
    {
        $this->employee = $employee;
    }

    public function save(array $attributes)
    {
        $this->employee->insert($attributes);
    }
}

class ContractorRespository
{
    protected $contractor;

    public function __construct(Employee $contractor)
    {
        $this->contractor = $contractor;
    }

    public function save(array $attributes)
    {
        $this->contractor->insert($attributes);
    }
}

Em ambos os Repositories utilizamos a mesma estrutura: injeção de dependência com o respectivos Models, e um método save().

Dessa maneira, separamos as responsabilidades em camadas, deixando o código mais legível e com uma arquitetura mais correta.

No próximo artigo vou abordar o segundo princípio: Open-closed Principle (Princípio Aberto-fechado).

Espero que você tenha gostado. Dúvidas e feedbacks são sempre muito bem vindos.

PS: Se você quiser adicionar Services e Repositories na sua aplicação Laravel, é só criar as pastas app/Services e app/Repositories e adicionar suas classes manualmente.

PPS: Neste exemplo abordei apenas o essencial para explicá-lo, deixando de fora imports, returns, validators, etc.

PPPS: Eu sei que o ideal seria ter um Model User e estender para Employee e Contractor. Mas para o exemplo ficar mais claro, deixei-os separados mesmo.

Como usar map, filter e reduce no PHP

Lucas Cavalcante — Wed, 13 May 2020 04:55:43 +0000

No artigo anterior, eu falei sobre o uso de arrow functions dentro do PHP. Você pode lê-lo neste link.

Hoje, seguindo com a aplicação de conceitos funcionais no PHP, vamos falar sobre 3 funções amplamente utlizadas quando precisamos percorrer um array e, se fossemos usar um loop tradicional, teríamos um pouco mais de trabalho. Estou falando do array_map, array_filter e o array_reduce.

Para começar, vamos usar um array que será aplicado em todos os exemplos deste artigo. Um array com os Top 3 filmes que mais arrecadaram na história do cinema. Vamos ter o título do filme, nota no IMDB, faturamento nos Estados Unidos, e faturamento no Brasil.

    $filmes = [
        [
            'titulo' => 'Vingadores: Ultimato',
            'imdb' => 8.4,
            'faturamento_us' => 858300000,
            'faturamento_br' => 85660000
        ],
        [
            'titulo' => 'Avatar',
            'imdb' => 7.8,
            'faturamento_us' => 760500000,
            'faturamento_br' => 58210000
        ],
        [
            'titulo' => 'Titanic',
            'imdb' => 7.8,
            'faturamento_us' => 659360000,
            'faturamento_br' => 70460000
        ],
    ];

array_map

A função array_map tem como objetivo percorrer todo o array e mapear cada um dos itens processando-os com o que é pedido, e gerando um novo array com os novos valores.

No nosso exemplo, vamos supor que o valor total das arrecadações são valores brutos, e que nós vamos descontar os impostos para mostrar o valor líquido. Vamos usar os valores fictícios de 16% para o Brasil e 6% para os Estados Unidos.

    $filmesDepoisDosImpostos = array_map(function ($filme) {
        $filme['faturamento_us'] -= $filme['faturamento_us'] * 0.06;
        $filme['faturamento_br'] -= $filme['faturamento_br'] * 0.16;
        return $filme;
    }, $filmes);

    var_dump($filmesDepoisDosImpostos);

Você pode perceber que a função array_map recebe 2 parâmetros: o primeiro é a função onde o mapeamento é feito, e o segundo é o array que irá fornecer os dados para serem mapeados.

array_filter

A função array_filter tem como objetivo filtrar os itens do array que atendam a uma condição estipulada dentro da função, e gerando um novo array apenas com os itens filtrados.

Por exemplo, eu quero filtrar pelos filmes que tenham a nota no IMDB abaixo de 8.

    $filmesNotaMenorQueOito = array_filter($filmes, function ($filme) {
        return $filme['imdb'] < 8;
    });

    var_dump($filmesNotaMenorQueOito);

Nesse caso aqui, os parâmetros se invertem em relação ao array_map. O primeiro parâmetro é o array que servirá como base para a filtragem, e o segundo é a função que irá estipular a condição para o filtro.

Se você reparar na saída do código, o novo array manteve a chave original dos itens do array original. Isso pode facilitar se você quiser chamar o array original usando as mesmas chaves.

array_reduce

A função array_reduce tem como objetivo reduzir o array a um único valor utilizando alguma operação aritmética para tal.

Neste exemplo, eu quero somar o faturamento no Brasil dos 3 filmes.

    $totalFaturamentoBR = array_reduce($filmes, function ($total, $filme) {
        $total += $filme['faturamento_br'];
        return $total;
    }, 0);

    var_dump($totalFaturamentoBR);

Aqui, temos 3 parâmetros. O primeiro é o array original que servirá como base para a operação aritmética, o segundo é a função que irá processar o cálculo, e o terceiro (opcional) servirá como valor inicial da operação. No nosso caso, como ele está 0(zero) não faria diferença se nós o removessemos. Mas vamos supor que além desse faturamento, fossemos adicionar o valor arrecadado desses mesmos filmes com streaming. Colocariamos esse valor no terceiro parâmetro.

Achou fácil? Espero que eu tenha ajudado a elucidar suas dúvidas.

Para finalizar, gostaria de refazer 2 dos exemplos acima utilizando maneiras de deixar o código mais legível e clean.

Função externa

O primeiro exemplo será com o array_map e será usando uma função que foi declarada fora do seu escopo.

    function aplicarImposto($filme) {
        $filme['faturamento_us'] -= $filme['faturamento_us'] * 0.06;
        $filme['faturamento_br'] -= $filme['faturamento_br'] * 0.16;
        return $filme;
    }

    $filmesDepoisDosImpostos = array_map("aplicarImposto", $filmes);

    var_dump($filmesDepoisDosImpostos);

Criamos a função aplicarImposto com o mesmo formato e conteúdo da versão anterior. Dentro do array_map, chamamos a função como uma string, e o parâmetro é passado de forma implícita. Visualmente, fica mais fácil de entender o código, mas tudo é questão de costume.

Arrow function

No artigo anterior falei sobre arrow function. A boa notícia é que podemos usá-la em conjunto com essas funções (quando o contexto permite, é claro). Lembrando que arrow function só irá funcionar a partir da versão 7.4 da linguagem.

    $filmesNotaMenorQueOito = array_filter($filmes, fn($filme) => $filme['imdb'] < 8);

    var_dump($filmesNotaMenorQueOito);

Conseguimos reduzir a 1 linha o exemplo anterior do array_filter.

E aí, o que achou? Espero que tenha gostado.

É sempre bom lembrar, dúvidas e feedbacks são sempre muito bem vindos.

Facilitando o entendimento da arrow function no PHP

Lucas Cavalcante — Tue, 12 May 2020 03:01:54 +0000

Se você já estudou um pouco sobre programação funcional, provavelmente já ouviu falar sobre a função que nomeia este artigo. E além disso, se estudou Javascript, possivelmente já estudou muito sobre esse conceito.

Trago neste artigo uma dica rápida de como aplicar este conceito tão popular na programação funcional (amplamente popularizado pelo Javascript) dentro do PHP.

Arrow function

As arrow functions foram introduzidas no PHP a partir da versão 7.4 da linguagem, e tem como principais missões dar produtividade ao desenvolvedor e facilitar o trabalho com escopo.

Vamos ver um exemplo de código sem usar arrow function:

    $valorDoEmprestimo = 30000;
    $taxaDeJuros = 18.63;

    function calcularJuros($emprestimo, $taxa) {
        return $emprestimo * ($taxa/100);
    }

    var_dump(calcularJuros($valorDoEmprestimo, $taxaDeJuros));

Vamos supor que essa taxa é fixa e não precisa ser passada como parâmetro:

    $valorDoEmprestimo = 30000;
    $taxaDeJuros = 18.63;

    function calcularJuros($emprestimo) {
        return $emprestimo * ($taxaDeJuros/100);
    }

    var_dump(calcularJuros($valorDoEmprestimo));

Nesse caso, vamos receber um erro:

Undefined variable: taxaDeJuros

Porque a variável $taxaDeJuros foi declarada fora da função calcularJuros e por conta do escopo, ela não é enxergada dentro da função. Aí que entra a arrow function.

Antes, vamos ver o mesmo exemplo de código com uma função anônima:

    $valorDoEmprestimo = 30000;
    $taxaDeJuros = 18.63;

    $jurosCalculados = function ($emprestimo) use ($taxaDeJuros) {
        return $emprestimo * ($taxaDeJuros/100);
    };

    var_dump($jurosCalculados($valorDoEmprestimo));

Bom, resolvemos em parte o nosso problema. O use nos permite "herdar" variáveis do escopo pai. Não precisamos passar como parâmetro na função, mas ainda assim precisamos referenciar.

Agora, o mesmo exemplo de código usando arrow function:

    $valorDoEmprestimo = 30000;
    $taxaDeJuros = 18.63;

    $jurosCalculados = fn ($emprestimo) => $emprestimo * ($taxaDeJuros/100);

    var_dump($jurosCalculados($valorDoEmprestimo));

Muito mais conciso, não é? Mas o que mudou? Vamos enumerar:

Redução da palavra function para apenas fn
Substituição do par de chaves { } pela arrow =>
Supressão do return
E, finalmente, não foi preciso referenciar a variável $taxaDeJuros em lugar nenhum. Ela simplesmente foi reconhecida por ser do escopo pai.

Fácil, né?

Se ficou alguma dúvida ou gostaria de dar um feedback, deixa um comentário. :)

No próximo artigo vou trazer outros conceitos da programação funcional usando as funções map, filter e reduce no PHP.

Trabalho remoto no exterior #3 - Speaking English

Lucas Cavalcante — Wed, 07 Aug 2019 13:56:59 +0000

Olá, esse é o terceiro post da série "Trabalho Remoto" (leia o primeiro e o segundo aqui e aqui respectivamente), e hoje vou compartilhar minha experiência com o aprendizado do inglês.

Como 95% dos brasileiros da minha geração, eu não aprendi inglês na minha infância/adolescência. O ensino de idiomas no currículo escolar obrigatório sempre foi precário (verbo to be ad eternum), e as escolas de idiomas sempre foram caríssimas.

Na vida adulta ainda demorei para "acordar" e começar a estudar inglês. Só comecei a fazê-lo depois dos 30.

No desespero de aprender, ainda cheguei a fazer UMA ÚNICA aula em uma escola de idiomas. Quando a professora começou a aula pedindo para todo mundo repetir em voz alta "How are you?" e "I'm fine, thanks" umas 200 vezes, já percebi imediatamente que estava no lugar errado. Terminei a aula e já fui pedindo o cancelamento na recepção.

Então, vou listar abaixo o caminho que eu trilhei e que PARA MIM deu certo. Imagino que cada um vá se adaptar melhor a um determinado formato para seu estilo de aprendizado.

Aulas Particulares: quando eu era bem newbie ainda, procurei um professor particular pois ele poderia adaptar o formato da aula à minha necessidade. Peguei a indicação com um amigo que passou um tempo no Canadá, e antes de ir fez aulas com esse professor. Indico bastante, pois nas primeiras aulas além de entender sua motivação, ele vai vendo o seu nível, e sempre tenta arrancar mais do que você pode dar. Às vezes desmotiva, parece que você não está evoluindo, mas é exatamente o contrário. Caso você tenha interesse, manda mensagem que eu indico com o maior prazer. (ele é de Fortaleza, mas dá aulas por Skype também)
Duolingo: como a maioria das pessoas, depois de um tempo fazendo as aulas, e achando que já tinha um nível bom o suficiente, parei com as mesmas. E nisso fiquei alguns anos estudando por conta própria (Youtube, livros, música, comunidades, etc), mas como não havia uma metodologia envolvida, era sempre muito desordenado meu aprendizado. O que me ajudou a manter um contato diário com o idioma e não esquecer coisas importante foi o aplicativo Duolingo. Ele é totalmente gratuito e tem uma estratégia de gamificação que realmente te vicia. Com ele, você treina reading, writing, listening e speaking. Além de ter um fórum para perguntar e responder a outros usuários.
Cambly: é uma plataforma para aprendizado do inglês com falantes nativos do idioma. Foi aqui onde realmente consegui "desbloquear" meu inglês. No começo é difícil, admito. Você pensa em desistir algumas vezes. A minha estratégia inicial foi agendar professores que também falassem português, pois se eu travasse, teria uma válvula de escape. Depois que peguei um pouco mais de confiança fui conversando com outros professores e, aos poucos, fui agendando com professores que só falavam inglês. Eu havia assinado o pacote de 1 ano, mas só fiz regularmente aulas durante 6 meses. Depois desse período fazia apenas aulas esporádicas.

Existem outras plataformas similares ao Cambly (iTalki, Verbling), mas na época peguei um cupom de 50% de desconto e ficou fácil decidir. :)

Depois disso, já fiz diversas entrevistas em inglês. Não sou fluente, e acho que só é fluente quem mora fora um tempo, mas falo o suficiente para manter uma conversação. E até hoje me engancho no phrasal verbs, mas isso não evita que eu consiga me comunicar.

Hoje trabalho alocado em uma empresa em Austin (ô sotaque carregado desse povo do Texas), e isso me ajuda ainda mais a ir corrigindo meu erros.

Trabalho remoto no exterior #2 - Code challenges

Lucas Cavalcante — Wed, 03 Jul 2019 14:13:38 +0000

Olá, esse é o segundo post da série "Trabalho Remoto" (leia o primeiro aqui), e dessa vez vou trazer algumas dicas relacionadas aos sites de code challenge.

Como falei no post anterior, em 2017 comecei a fazer entrevistas em inglês para tentar trabalhos no exterior, fossem eles remotos ou presenciais. E na maioria dessas entrevistas, quando eu conseguia passar para o teste técnico, recebia um e-mail com um link para um site onde o teste seria validado de forma automática e com um tempo pré-determinado para finalização. Também conhecidos como code challenges.

Esse tipo de teste se diferencia um pouco dos demais pela automação que mencionei acima, e também por exigir um pouco mais de conhecimento na parte de conceitos, como por exemplo: estrutura de dados, resolução de problemas, sistemas distribuídos, algoritmos, matemática, etc.

Para quem é acostumado apenas com o dia a dia de um software mexendo com requests, responses, ORM e afins, vai penar bastante como eu penei. Apesar de ter estudado muitos desses temas na faculdade, não aplico com frequência no dia a dia e o conhecimento acaba escapando com o tempo.

Alguns destes testes são bem pragmáticos, do tipo "faça isso" e se compilar, passou. Já outros mandam um breafing, vocẽ tem que criar uma feature, criar testes unitários, e no final a plataforma ainda rodar os próprios testes para verificar a assertividade do código. (e depois de passar em todos esses testes, a empresa ainda te retorna dizendo que você não foi aprovado para a próxima fase, vai entender)

Bom, com o tempo a gente vai pegando o jeito e melhorando nosso rendimento nesses challenges. Mas, claro, precisamos estudar e pegar dicas que irão nos ajudar nesse processo. Então, vou listar abaixo o meu processo de aprendizado para essa finalidade:

30 Days of Code - Hackerrank: o Hackerrank é uma dessas plataformas utilizadas pelas empresas para avaliar seu conhecimento através dos code challenges. Mas, um dos grandes diferenciais dela é que você tem à disposição uma lista de challenges para fazer na hora que você quiser. São organizados por linguagem, conceito, nível de dificuldade, etc. E para começar do zero, recomendo demais o 30 Days of Code que vai explicando desde um simples "Hello World" até temas mais complexos como filas, pilhas, árvores binárias, etc.
Codility: o Codility tem o mesmo propósito do anterior, mas sua parte de aprendizado é um pouco menor, além de ter um foco bem forte em algoritmos. Nos exercícios a gente encontra o algoritmo de Euclides, Fibonacci, Crivo de Eratóstenes, etc.
Livro Estrutura de Dados e Algoritmos em Javascript: esse livro é, de longe, a melhor referência do assunto em língua portuguesa. Apesar de ser focado em uma linguagem (Javascript), a autora aborda o tema de uma forma tão ditática e simples, que mesmo quem não conhece Javascript, terá facilidade com o conteúdo aqui apresentado.

Essas foram as dicas de hoje. Se você conhecer mais alguma plataforma e/ou livro que possa ajudar nessa jornada, compartilhe conosco. :)