DEV Community: Lucien Risso Correia

Property Hooks no PHP 8.4

Lucien Risso Correia — Tue, 08 Oct 2024 19:55:12 +0000

Em novembro teremos o lançamento da versão 8.4 do nosso querido PHP e com ela teremos um novo recurso muito aguardado pela comunidade: o property hooks! Inspirado por outras linguagens como C#, Swift e Kotlin esse novo recurso tira a gambiarra dos métodos mágicos __set() e __get().

Vou mostrar um exemplo de como faz atualmente para termos getter e setters sem precisar criar a propriedade como privativa e criar dois novos métodos com nomes diferentes da propriedades.


class Foo
{
    private String $bar;

    public function __set($name, $value)
    {
        $this->$name = $value . "!!!"; 
    }

    public function __get($name)
    {
         return "!!!" . $this->$name;
    }
}

Usando o __get() e __set() consigo deixar o $bar público quando defino valor e quando busco o valor, porém com implementação diferente e sem ter que criar métodos com nomes distintos da propriedade. Em exemplo visual ficaria assim o uso:


$foo = new Foo();

$foo->bar = "new release";
// aqui o valor que ficará salvo seria "new release!!!"

echo $foo->bar; // aqui retornaria "!!!new release!!!"

Agora imagine como ficaria o __get() e __set() com outras propriedades, uma confusão total. Outra maneira de fazer isso seria criando um método getBar() e um outro setBar(), mas isso considerando apenas uma propriedade e no uso ficaria diferente do anterior:

class Foo
{
    private String $bar;

    public function setBar($value)
    {
        $this->bar = $value . "!!!"; 
    }

    public function getBar()
    {
         return "!!!" . $this->bar;
    }
}

$foo = new Foo();

$foo->setBar('new release');
// aqui o valor que ficará salvo seria "new release!!!"

echo $foo->getBar(); // aqui retornaria "!!!new release!!!"

Eu particularmente acho meio chato criar novos métodos para esse caso de uso, prefiro muito usar a chamada direta da propriedade tanto para pegar quando definir seu valor. Esse novo recurso chega para resolver essa bagunça e permitir definir o get e set individualmente junto com a declaração na classe.


class Foo
{
    public String $bar {
        set (String $value) => $this->bar = $value . "!!!";
        get => "!!! . $this->bar";
    }
}

Esse novo código faz a mesma coisa porém individualmente, sem criar novos métodos ou utilizar __get() e __set() que precisam de tratamento para cada propriedade e a classe tiver.

Agora é só aguardar o lançamento desse novo recurso que deverá sair dia 21 de novembro!

Laravel 11

Lucien Risso Correia — Tue, 12 Mar 2024 12:22:45 +0000

Laravel 11 chegou com algumas mudanças que posso dizer "finalmente" e umas outras "pra que isso?".

Controller simplificado

O controller base foi simplicado, não extendendo o Controller interno do Laravel, sendo assim quando precisar do AuthorizesRequests ou do ValidatesRequests precisará adicionar a cada controller que for utilizar.

Rate limit em segundos

Agora é possível definir rate limits em segundos em vez de minutos, utilizando o Limit::perSecond().

Novos comandos de criação do artisan

Agora temos comando para criação de class, enum, interface e trait:

php artisan make:class
php artisan make:enum
php artisan make:interface
php artisan make:trait

Helper once

Agora você pode cachear um retorno de função e sempre ter o mesmo retorno nas chamadas subsequentes:

function random(): int
{
    return once(function () {
        return random_int(1, 1000);
    });
}

random(); // 123
random(); // 123 (cached result)
random(); // 123 (cached result)

Menos arquivos padrões

Se olhar a pasta app/Http vai ver somente o controller agora, sem o Kernel.php e a pasta Middlewares.

Campo 'password' pode ser com outro nome agora

Finalmente, depois de anos de espera os Devs BRs que cairam num projeto que o banco é em português poderão utilizar o nome da coluna senha na tabela de usuario como 'senha' em vez de 'password'. O método getAuthPasswordName() foi adicionado ao Authenticatable permitindo alterar o nome da propriedade da senha.

Migrations de alterações ficaram mais chatinhas

Agora toda vez que alterar uma coluna pela migration precisará reescrever todas as alterações anteriores novamente para não voltar ao padrão. Digamos que na criação foi adicionado um comentário na coluna, e em uma migration posterior você altera para ter um valor padrão, para não perder o comentário terá que chamar o método novamente ou irá voltar para o padrão que é sem comentário. Particulamente achei isso ruim.

MariaDB

Agora o Laravel possui um driver específico pro MariaDB, em vez de utilizar o driver do MySQL agora pode utilizar o mariadb nas configurações do banco. O que isso muda por enquanto é em relação ao uuid, mas futuramente deverá ter mais coisas específicas pro banco.

Carbon 3

Agora o Laravel suporta tanto o Carbon 2 quanto o Carbon 3, só atulizar nas dependencias do composer e fazer os ajustes conforme a documentação do Carbon no que precisar.

Registro de Providers

Agora o registro de providers foi movido para o arquivo bootstrap/Providers.php e retirado do config/app.php. Para packages que criavam arquivos nessa pasta agora é precisa atualizar o método para o ServiceProvider::addProviderToBootstrapFile().

Essas são as mudanças que achei interresante comentar, pra saber de todas é só ler o release notes e o upgrade guide na documentação do Laravel.

Gerência de Estado no Flutter

Lucien Risso Correia — Mon, 05 Feb 2024 20:09:48 +0000

O ano era 2021 e a comunidade Flutter estava agitada demais com algumas tretas envolvendo o time do Flutter e desenvolvedores da comunidade, nessa mesma época o tal state management estava no hype de assuntos da comunidade. Fiz um texto originalmente no Medium, que também está publicado aqui, tirando sarro dessas polêmicas e satirizando os principais packages de gerenciamento de estado do Flutter.

Em projetos futuros a esse texto ainda continuou a discussão sobre qual package utilizar para isso, e a treta sempre foi grande. Chegamos em 2024 e sinto que isso deixou de ser um richa e finalmente os devs Flutter entenderam que no final tudo é Streams ou Observers, ou talvez não...

Observer

O Observer Pattern, também conhecido como Publish/Subscribe, é um padrão de design que define um mecanismo de comunicação entre objetos. Nesse padrão, um objeto, chamado Subject, mantém uma lista de objetos Observers que dependem dele. Quando o estado do Subject muda, ele notifica todos os Observers, que podem então atualizar suas próprias interfaces.

No Flutter esse designer é implementado no ChangeNotifier, onde se pode criar uma classe com as propriedades desejadas pro estado que quer gerenciar e métodos que manipulam e notificam a mudança de estado pros Observers. Veja um exemplo de uso básico de gerenciamento de estado com Observer em Flutter:

class MyState extends ChangeNotifier {
  int count = 0;

  void incrementCount() {
    count++;
    notifyListeners();
  }
}

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  MyState state = MyState();

  @override
  void initState() {
    super.initState();
    state.addListener(() {
      setState(() {});
    });
  }

  @override
  Widget build(BuildContext context) {
    return Text('Count: ${state.count}');
  }
}

Nesse exemplo, a classe MyState é um Subject. Ela define uma interface para registrar e remover Observers (o método addListener()) e notifica os Observers quando seu estado muda (o método notifyListeners()).

A classe MyWidget é um Observer. Ela se registra como um Observer da classe MyState no método initState(). Quando o estado da classe MyState muda, o método update() da classe MyWidget é chamado, o que faz com que o widget seja reconstruído.

Com o Provider podemos simplificar a parte de widget e retirar a parte de implementação do trecho do initState, já que o próprio widget dele já faz essa reconstrução quando recebe notificação que o estado mudou. Com isso temos pequenas mudanças no código de widget e ele ficaria assim:

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => MyState(),
      child: Consumer<MyState>(
        builder: (context, state, child) {
          return Column(
            children: [
              Text('Count: ${state.count}'),
              ElevatedButton(
                onPressed: state.incrementCount,
                child: Text('Incrementar'),
              ),
            ],
          );
        },
      ),
    );
  }
}

Lembre-se: o Provider tem como foco ser uma biblioteca para injeção de dependência utilizando a arvore de widgets, a classe Consumer auxilia no uso das dependências injetadas no contexto de Widget, o foco do Provider não é gerenciar estado.

Stream

Stream é uma sequência assíncrona de eventos. Ela pode ser usada para representar dados que mudam ao longo do tempo, como a localização do usuário, a entrada do teclado ou a saída de um sensor.

Um exemplo de uso se Stream para gerenciar estado no Flutter com um contador progressivo que incrementa o valor a cada segundo:

class MyState {
  int count = 0;

  Stream<int> get countStream =>
      Stream.periodic(const Duration(seconds: 1), (_) => count++);
}

class MyWidget extends StatelessWidget {
  final MyState state = MyState();

  @override
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: state.countStream,
      builder: (context, snapshot) {
        if (snapshot.hasData) {
          return Text('Count: ${snapshot.data}');
        } else {
          return Text('Aguardando...');
        }
      },
    );
  }
}

Nesse exemplo usamos o StremBuilder para poder atualizar o widget a cada troca de valor, mas também podemos fazer sem ele com o famoso setState escutando os eventos da Stream com o listen:

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  final MyState state = MyState();

  @override
  void initState() {
    super.initState();
    state.countStream.listen((count) {
      setState(() {});
    });
  }

  @override
  Widget build(BuildContext context) {
    return Text('Count: ${state.count}');
  }
}

E é sobre isso que venho lembrar e ajudar a fixar na cabecinha dos devs iniciantes em Flutter: quem gerencia o estado é você e não o package. O que quero lembrar é que independente de está usando BLoC ou MobX, Riverpod ou Solidart, GetX ou setState, o resultado final dependerá de como você escreveu a solução. E se não gostou de nenhuma implementação de Observer dos packages, crie sua própria, no final ou é feito em cima de Stream ou em cima de Observer.

Vou listar qual usa o quê pra exemplificar:

Packages que utilizam Stream:

BLoC
RxDart
GetX

Packages que utilizam Observer:

MobX
ChangeNotifier
Flutter Hooks

Por trás dos panos eles utilizam basicamente a mesma lógica, porém com implementações diferentes que mudam como será escrito o código. Mas igualmente, quem faz o gerenciamento é quem escreve a aplicação em si. Além disso o que ocorre muito é confundirem state managment com dependencie injection, no caso de GetX ou Provider por exemplo, que possuem essa implementação a mais para compor o package e tornar mais completo. São coisas que costumam serem necessitas juntamente porém já não são mais em si state managment.

Bom códigos e best reguards!

Kubernetes: criando seu primeiro Pod

Lucien Risso Correia — Wed, 10 Jan 2024 19:21:21 +0000

Segundo a documentação do Kubernetes um Pod é a menor unidade computacional que você pode criar e gerenciar no Kubernetes. É um encapsulamento de um ou mais containers que utilizam recursos de hardware e rede compartilhados entre si, como se essas aplicações estivessem rodando em uma mesma máquina em servidores VPS por exemplo.

Vamos subir um Pod simples com o nginx primeiramente:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Para aplicar as alterações vamos salvar esse código em um arquivo pod.yaml e rodar o comando do kubeclt: kubectl apply -f pod.yaml

Para verificar se terminou certinho podemos rodar kubectl get pods e o resultado deve ser algo parecido com:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          20s

Agora temos um Pod rodando um container que utiliza a imagem do nginx, ou seja, se entrar dentro dele e fizermos uma requisição pro localhost deve retornar a página default do nginx. Para facilitar a visualização vamos permitir o acesso do pod externamente pela porta 8080 com o comando kubectl port-forward pod/nginx 8080:80. Se você estiver utilizando o minikube irá precisar rodar o comando minikube tunnel. Com isso podemos ver a página default do nginx acessando localhost:8080

Laravel - Parte 2

Lucien Risso Correia — Thu, 27 Jul 2023 00:25:15 +0000

Chegamos aos controladores da aplicação, que no artigo anterior seriam os próximos logo após da rota. Recapitulando: a aplicação recebe a chamada HTTP, leva pra rotas pra verificar para onde vai esse requisição e no caso atual ele vai ir para algum controller. Os controllers podem chamar classes e métodos de muitos lugares dependendo do tamanho e do design da aplicação, como por exemplo QueryBuilders, UseCases, Services, Repositories entre outros.

Mas ainda não chegamos ao ponto de utilizar esses designs, vamos somente seguir o fluxo simples da requisição. Dentro do método do controller podemos literalmente colocar qualquer coisa e até mesmo nem dar retorno :), mas vou dar um exemplo mais decente:

    public function metodoDoController()
    {
        // coloca o que quiser aqui mas vou dar um retorno do famoso hello world

        return "Hello World";
    }

Antes de continuar esqueci de dizer onde ficam os arquivos de controllers e como cria eles. Os arquivos ficam em app/Http/Controllers e é possivel criar um novo com o comando php artisan make:controller NomeDoController

Isso é extremamente básico, vamos fazer algo útil mesmo, vamos pegar dados que vieram na requisição:

    public function metodoDoController(Request $request)
    {
        $dadosDoRequest = $request->all();
    }

Agora eu pedi a injeção do Request como parâmetro do método, o Laravel injeta automaticamente o objeto do Request, com essa injeção podemos fazer outras coisas mas mais adiante veremos mais afundo a injeção de dependência nos métodos de Controller. O método 'all' retorna um array com tudo de dado que veio no request. Vamos supor que esse é o método de login e deve receber email e senha na requisição:

    public function login(Request $request)
    {
        $email = $request->email;
        $senha = $request->senha;

        return response()->json([
            'email' => $email,
            'senha' => $senha
        ]);
    }

Agora obtive o email e senha utilizando o request de uma maneira diferente, chamando diretamente a chave do dado como se fosse uma propriedade do objeto. No PHP temos os métodos mágicos, e o __get() é um deles utilizado amplamente dentro do Laravel, em outros casos veremos esse mesmo esquema de chamar propriedades que não foram definidas na classe. E pra finalizar o método utilizei o response()->json() que retorna a resposta com o header 'application/json' para o cliente.

Somente com isso já podemos fazer coisas legais, como a famosa calculadora :)

    public function somar(Request $request)
    {
        $numero1 = $request->numero1;
        $numero2 = $request->numero2;

        return response()->json([
            'resultado' => $numero1 + $numero2
        ]);
    }

Somente com isso já podemos realmente criar uma API que não precise de base de dados e ir explorando o Request e Response do Laravel. Use o wget, postman, insomnia, o navegador ou qualquer outra ferramenta para enviar requisições HTTP e teste sua API.

Na próxima veremos o início de banco de dados, já montando uma API mais dinâmica e legal :)

As tais gerências de estado do Flutter

Lucien Risso Correia — Wed, 31 May 2023 00:53:02 +0000

Pra começar esse texto é uma sátira sobre as brigas que ocorrem na comunidade Flutter sobre gerência de estado, se levar isso a sério recomendo um psiquiatra.

Quem não é do front provavelmente não tá ligado sobre gerência de estado, volte duas páginas por favor (procure no google, estou com preguiça de explicar nesse texto). Mas enfim, se já codou com Flutter provavelmente já mandou o setState para aquele lugar e se não mandou tá codando errado. Chegando no ponto principal, a partir disso você vai conhecer os famosos competidores do ringue: BLoC, MobX, Provider/Riverpod, Cubit, Getx, ValueNotifier/ChangeNotifier, Triple Pattern entre outros que você pode encontrar aqui mas que tá errado, onde que o GetIt é state management deus?? Absurdo, vou abrir PR no repositório do site…

Vamos começar pelo mais polêmico, que rufem os tambores (som do tambor)… ELE, O GetX. Esse tal de GetX na verdade é um framework (ruim) dentro do flutter, que seria outro framework (talvez não, mas isso é assunto pra outro texto), o que pra mim não faz sentido nenhum. Esse package propõe tanta coisa que cansa só de ler a intro da documentação dele. Esse monstrinho feio tem coisas pra mostrar alertas, pra injetar dependências, pra traduzir texto, pra gerenciar as rotas e até pra SALVAR DADOS NO LOCAL STORAGE DO DISPOSITIVO, SÓ FALTA FAZER CAFÉ E CÓDIGO SOZINHO. Vou abrir uma issue pra isso, to sentindo falta do café.

Seguindo, com o talvez segundo mais popular segundos pesquisas que não fiz temos o MobX. Esse é simples, o único problema é depender de geração de código que deixa o desenvolvimento mais lento que o Chrome com 2 abas abertas em um pc com 4GB de RAM e um Celeron. Até tem como utilizar sem geração de código, mas ai perde a graça e fica muito verboso.

Na real, fui ver quantos tem pra falar e fiquei cansado, vou encerrar com o BLoC então. Esse lindão ai te faz ter que entender sobre orientação a objetos, quem quer entender isso em pleno 2021? Ainda mais a galera que vem do javascript, nem sabem o que é isso. Bom, só pra resumir, tu precisa criar classes pros eventos e pros estados, CADA EVENTO QUE TIVER É UMA CLASSE, E CADA ESTADO TAMBÉM É UMA CLASSE, isso é muito verboso, cansei só de pensar.

Enfim, programar é chato mesmo, só aceite e pegue uma breja geladinha pra aguentar tanta coisa que rola no Flutter e na bolha dev.

Laravel - Parte 1

Lucien Risso Correia — Mon, 29 May 2023 22:13:40 +0000

Ciclo de requisição básico

Partindo do básico é necessário conhecer o básico de dois conceitos: route e controller.

Route

Route, ou se preferir chamar de rota mesmo é onde se cria as rotas HTTP, definindo sua assinatura, método HTTP e a resposta. Na pasta 'routes' existem quatro arquivos php: 'api.php', 'channels.php', 'console.php', 'web.php'. Numa aplicação poderá ter vários desses para organizar as rotas, mas como por enquanto é somente o básico vamos ficar somente no 'api.php'.

Na versão 10 esse arquivo vem como o seguinte código:

<?php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;

/*
|--------------------------------------------------------------------------
| API Routes
|--------------------------------------------------------------------------
|
| Here is where you can register API routes for your application. These
| routes are loaded by the RouteServiceProvider and all of them will
| be assigned to the "api" middleware group. Make something great!
|
*/

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
    return $request->user();
});

Em resumo essa rota possui um middleware do sanctum (package de autenticação) que retorna o usuário autenticado. Por enquanto deixaremos de lado e pra não confundir apagaremos esse trecho.

Para definir rotas simples o Laravel possui a classe 'Route' juntamente com os métodos que definem o método HTTP da rota, seguindo os mesmos nomes 'get', 'post', 'put', 'patch', 'delete'.
Cada um desses métodos recebe como primeiro parâmetro a assinatura da rota e como segundo parâmetro um callback.

Assim podemos criar um endpoint '/hello-world' GET:

Route::get('/hello-world', fn () => 'Hello World');

Com isso teremos um retorno de um texto 'Hello World' ao chamar a rota.

Response

Até a parte anterior foi possível retornar algo simples como um texto com status code 200. Já adiantando um próximo assunto vou deixar como retornar qualquer coisa definindo o status code HTTP:

Route::get('/error-500', fn () => response('ERRO!!!', 500));

O código acima utilizou a função 'response', um helper do Laravel para facilitar o retorno da classe de Response do framework. Com esse helper podemos definir o retorno e em seguida como segundo parâmetro o status code HTTP desse retorno, que no exemplo foi 500 de erro no servidor.

Para finalizar a parte básica de rotas vou deixar um link da documentação da Mozilla de Status Code HTTP que utilizaremos adiante.

Padrões de Desenvolvimento de Software NÃO são meras frescuras

Lucien Risso Correia — Tue, 21 Mar 2023 23:47:08 +0000

Conhece aqueles desenhos que os músicos de uma orquestra leem enquanto tocam a música? A partitura, cheia de linhas e símbolos. Na música ela é utilizada de forma universal, para qualquer músico, de qualquer lugar do mundo, que fale qualquer idioma, conseguir tocar qualquer música escrita ali. Isso só é possível porque a partitura foi padronizada como uma forma de escrever uma música, uma linguagem universal.

Mas o que partitura tem a ver com desenvolvimento de software?

Numa conversa aleatória, na base da cerveja é claro, foi comentado sobre o tempo em que um desenvolvedor demora para se entender com o código. Nisso, foi relacionado a partitura com os padrões de desenvolvimento, assim como qualquer músico que saiba ler uma partitura consegue tocar qualquer música feita por outro músico sem sequer o conhecer, qualquer desenvolvedor que saiba os padrões da *stack *do projeto, consegue se entender rapidamente a ponto de em pouco tempo conseguir adicionar uma feature nova ou corrigir um bug.

Os grandes projetos de software livre definem padrões

Muito provável que o repositório daquele seu framework favorito tenha um arquivo chamado *CONTRUIBUTING.md *com todas as instruções e padrões para aquela sua PR **linda **ser aceita e ir pra *branch *principal. Vou deixar o exemplo do *flutter *para dar uma olhadinha. Procure pelo repositório de seus frameworks favoritos, eles provavelmente devem seguir padrões.

Ser escalável não é hospedar na Amazon

Sabe aquele tio ou primo, um gênio incompreendido, que viu alguma palestra sobre *startups *e brotou com uma ideia estranha? E que quer alguém que saiba mexer com *AWS *pro produto genial dele ser escalável? Então, eu ainda não entendi o que faz pensar que é só tacar lá que vira um *puta software escalável. *Ser escalável não se limita ao custo de servidores, abrange também o custo humano, nisso existem duas frentes, a galera que cria as novidades e a galera que corrige o que já está rodando. Nessa segunda frente, um software mal feito, pode acabar pesando no custo, e com isso nessa tal de escalabilidade.

Querendo ou não, é impossível pegar todos os bugs e erros de um sistema grande antes de enviar pra produção. Pode ter 100% de cobertura de testes automatizados e mais os testes manuais que sempre terá alguma coisa que não foi prevista. E para conseguir diminuir ao máximo os erros e bugs em produção, o processo de desenvolvimento deve ser muito cuidadoso e rigoroso, obrigando os desenvolvedores a testarem e escreverem testes, seguir o design do código e os padrões de desenvolvimento estabelecidos. Tudo isso colabora para evitar problemas em produção e não criar a bola de neve que código ruim causa e evitando custos adicionais como horas extras da galera que trampa no feriado pra corrigir um erro 500 naquele módulo indispensável pros clientes.

O ciclo de vida não pode terminar em um “software novo”

Não são poucos casos que escutei de software que precisaram serem reescritos pra poderem receber novas features. E todos esses casos foram por ir criando a base de “duas coxadas e uma barrigada”, cuspindo código adoidado pra entregar logo porque tem que ter tal coisa pro próximo pitch *com investidores ou com uma apresentação pra um possível grande cliente. Esse famoso atrito do pessoal de vendas/gestão com o pessoal técnico pode custar muito ao longo do tempo. Mas ainda existe a outra ponta, a ponta dos software que nunca termina as correções de erros e bugs, que cada vez mais se contrata desenvolvedor para ir corrigindo, e a cada correção se cria um novo bug ou erro. Repita comigo: “*Encher a empresa de devs não faz as coisas serem mais rápidas”. Um código fonte ruim gera desanimo, e desanimo pode gerar alta rotatividade, e trocar de funcionário custa muito mais que manter. Até esse novo chegar ao nível de desempenho do anterior demora. É claro que é impossível ter um código totalmente limpo, simples e fácil de entender em um sistema grande, mas é aquele ditado: faça o seu melhor nas condições que você tem, até ter melhores condições para fazer melhor ainda.

Aquele velho blá blá blá de sempre

Sim, vou terminar esse texto repetindo o que provavelmente o sênior do teu trampo já repetiu várias vezes, padrões de desenvolvimento não são frescuras e se vocês acha que é frescura, releia esse texto.

tl;dr:

Esse texto foi escrito baseado em experiência própria e em conversas com outros devs e galera da área. Não leve nada ao pé da letra, ou leve, particularmente eu to nem ai :)