DEV Community: André Santos Meireles

A importancia de fazer testes

André Santos Meireles — Tue, 12 Mar 2024 00:57:55 +0000

Em um sistema que estava desenvolvendo me deparei com a seguinte demanda, ler um arquivo csv e devolver seu primeiro resultado para analise, um arquivo csv podem vir com a primeira linha sendo um cabeçalho, logo essa linha deve ser ignorada e a segunda linha deve ser retornada ao invés da primeira.

O codigo para essa tarefa é simples.

public function getFirstContent(string $filename, UploadedFile $file, bool $hasHeader = false): array
    {
        $openFile = $file->openFile();
        $csv = [];
        while (($row = $openFile->fgets()) !== false) {
            if ($hasHeader) {
                continue;
            }
            $csv = str_getcsv($row);
            break;
        }
        $openFile = null;
        $file->storeAs(self::SAVE_DIR, $filename);

        return $csv;
    }

Você pode ter notado o erro desta implementação, eu não. Após terminar de fazer esse código fui fazer os testes desta função. Escrevi testes com um caso onde o csv não teria um cabeçalho e o outro teria um cabeçalho, um teste deveria chamar a função fgets uma vez e outro duas, eis o codigo do teste

/**
     * @dataProvider cases
     */
    public function testGetFistContent(bool $hasHeader, array $fgets, string $expected): void
    {
        // arrange
        $splFileMock = $this->getMockBuilder(SplFileObject::class)
                            ->setConstructorArgs(['php://memory'])
                        ->getMock();
        $splFileMock->expects($this->exactly(count($fgets)))->method('fgets')->willReturnOnConsecutiveCalls(...$fgets);

        $file = $this->createMock(UploadedFile::class);
        $file->expects($this->once())->method('openFile')->willReturn($splFileMock);
        $file->expects($this->once())->method('storeAs')->with('/tmp', 'file.csv');

        // act
        $result = $this->service->getFirstContent('file.csv', $file, $hasHeader);

        // assert
        $this->assertIsArray($result);
        $this->assertSame($expected, $result[0]);
    }

public function cases(): array
    {
        return [
            [false, ['a,b,c'], 'a'],
            [true, ['a,b,c', 'c,b,a'], 'c']
        ];
    }

O primeiro teste rodou de forma correta e passou, o segundo caso, onde o cabeçalho existe e deve ser pulada não estava passando, justamente porque $hasHeader nunca muda seu estado, logo quando for true, sempre irá pular a linha e nunca lerá o csv, um erro simples, fácil de ser corrigido, porém com um alto potencial de quebrar sistemas, imagine o quando de processamento desnecessário um loop infinito irá gerar?

Ao notar isso adicionei a uma linha de correção, um simples $hasHeader = false e pronto, o teste passou.

while (($row = $openFile->fgets()) !== false) {
            if ($hasHeader) {
                $hasHeader = false;
                continue;
            }
            $csv = str_getcsv($row);
            break;
}

Testes são importantes para prevenir erros de falta de atenção, que podem ocorrer quando estamos com um prazo apertado ou no dia em que não estamos muito inspirados.

Sempre teste seu código, até mais!

Aprendizados após um projeto pessoal

André Santos Meireles — Fri, 09 Feb 2024 09:34:34 +0000

Recentemente, fiz como projeto pessoal, um clone do chatgpt, o dgpt, foi um projeto bem divertido onde testei várias tecnologias emergentes e tive diversos tipos de satisfação usando essas tecnologias. Quero compartilhar alguns aprendizados e duvidas que tive.

IA

Após mexer um pouco com IA entendi o buzz ao redor, é muito divertido testar modelos, treina-los, ve-los delirando entre outros. O ferramental delas é bom, dependendo da linguagem de programação escolhida haverá mais ou menos recursos, por exemplo javascript e go tem a biblioteca langchain, em PHP, que foi a linguagem que escolhi existe um porte do langchain, que voce pode conferir aqui, porém ele ainda é muito embrionário, quando comecei a brincar com ia com go usei bastante o langchain em conjunto com llama.cpp, mas como não consegui fazer funcionar no php busquei alternativas e encontrei o ollama, um serviço web onde vários tipos de modelos podem ser adicionados, esse serviço é escrito em go e é muito util para testar modelos, como no caso do meu projeto.

Ao usa-lo vi a grande barreira para usar IA de modo "caseiro", elas necessitam de muitos recursos da maquina, os modelos tem cada vez mais parâmetros, logo são muito maiores, necessitam de bastante processamento e memória. Existem modelos menores, mas eles tendem a ser menos eficazes e mesmo modelos pequenos exigem bastante da maquina.

HTMX

Num primeiro momento pensei em usar uma lib ou framework js como solid ou svelte ao outro para aprender, mas resolvi experimentar o "hyper" do htmx. O htmx é uma lib muito competente, pequena, performática, com conceitos muito interessantes, com ele fiz algumas tarefas que exigiram algumas linhas de JS em uma linha com alguns atributos em tags html, parecido em como fazia quando estava aprendendo e tudo que sabia usar era o GRANDIOSO jqeury.

Contudo no decorrer da experiencia percebi alguns engasgos que nao teria usando um lib ou framework js, como na parte do chat onde precisava adicionar vários dinamicamente alguns campos e me vi lutando contra o htmx ao invés de ser ajudado, coisa que quando lembro de ter aprendido svelte, react ou outro framework não lembro de ter acontecido, claro que com mais estudo e pratica esses pontos podem ser mitigados e eu perceba que o htmx é a panacea para o frontend, porem minha impressão atual é: ele é bom para coisas que exigem pouca interação, mas da feita que sua pagina precisa de mais interações ele começa a mostrar sua limitações.

Mercure

Quando fiz o projeto queria usar websockets para quando a mensagem fosse escrita, ele mandar a resposta de acordo com o que fosse recebendo ao invés de esperar a resposta ficar pronta e mandar tudo, ate porque por causa da limitação da minha maquina o processo terminava em timeout. Não queria usar nenhum serviço externo, então busquei alternativas em php, não achei nenhuma boa para rodar localmente, neste projeto usei o frankenphp e em sua documentação comenta que ele ja vem com um servidor Mercure embutido então fui ver do que se tratava.

Mercure é um protocolo pensando em comunicação em tempo real, de alto nível, funciona por padrão nos browsers modernos. É fácil e simples de usar, tem uma performance incrível, com certeza é algo que utilizarei sempre que uma solução exija comunicação em tempo real. A única ressalva e que estudarei melhor como levantar um servidor mercure em um ambiente onde ele não é embutido pro padrão.

Frankenphp

Em novembro foi lançado para produção um novo runtime php, o frankenphp, ele vem com um conceito muito legal que é o worker mode, onde após a inicialização o projeto php todo fica em memória, fazendo com que as requisições subsequentes nao tenham o overhead de carregar todas as libs e subir todos os processos, como aplicativos usando o php-fpm fazem, como 25 a 50% do response time do php é composto apenas do boot da aplicação isso de cara ja faz o php ficar bem mais rápido. Neste video do Dias de dev a um benchmark que mostra bem o potencial do frankenphp em comparação com libs estabelecidas como o Swoole, no video fica claro que o benchmark não foi feito para comprar ambas, porem os números são bastante reveladores.

Integrar o slim framework com o frankenphp foi simples, durante todo o desenvolvimento não usei o woker mode, pois quando em memória a aplicação so é alterada quando ela é terminada e levantada novamente. Mesmo sem usar o worker mode a aplicação ja é bastante responsivo por usar o caddy server, em worker mode ela também fica mais rápida, porem como a minha aplicação não exige muito processamento, por delegar o processamento para o olham, não da para notar aumentos dramáticos de performance, mas ha um perceptível aumento de performance.

O PHP é sempre ótimo de trabalhar, é uma linguagem que sou apaixonado e ver seu progresso ano após ano é fantástico.

Conclusão

Estudar novas tecnologias sempre é bom, mas as vezes pode ser algo tao distante da realidade do trabalho ou do que as vagas pedem que desanima as pessoas de fazerem. Tendo essa experiência aprimorei algumas habilidades e descobri coisas que podem se aplicar em projetos atuais como o ollama e o mercure. Recomendo a todos que tenham seus projetos de duas ou tres semanas para testar tecnologias novas e aprender novos conceitos.

Um modo facil de usar code standards no php

André Santos Meireles — Sat, 08 Jan 2022 20:19:42 +0000

O php é uma linguagem maravilhosa e muito popular, ela possui padrões que ajudam a escrever códigos de fácil manutenção e legíveis, exemplos desses padrões são as PSR's 1 e 12, que indicam padrões de estilo de código ou coding standards.

Um modo de aplicar esses padrões é com o pacote PHP_CodeSniffer que, de forma simplificada, lê nosso código e analisa se segue os padrões indicados nas PSR's ou nos padrões que definimos, essa ferramenta pode ser instalada de forma global ou por projeto com o composer. Assim que instalado podemos utilizar o comando phpcs caminho/para/arquivo se instalado globalmente ou vendor/bin/phpcs caminho/para/arquivo quando instalado por projeto, isso irá listar que pontos do nosso código podem ser ajustados para seguir os padrões. Por mais que esse método exista ele não é prático, normalmente usamos esse pacote em conjunto com o linter da nossa IDE ou editor de texto, o phpstorm já vem com um linter de code standards embutido que precisa ser apenas configurado, o visual studio code tem plugins para implementar essa função de linter e outras ferramentas também tem plugins ou extensões que integram essa função. Isso pode ser aliado com outras ferramentas como PHP-cs-fixer que irão ajustar o código automaticamente com um comando no terminal, atalho nos editores ou quando o arquivo for salvo, as possibilidades e integrações são inúmeras.

Desde que aprendi sobre isso usei os plugins do visual studio code (vscode), até ler post do blog do Tomas Votruba onde ele dizia que olhar as sugestões de padrões de código e concertar manualmente, por mais que fosse algo rápido, quando somando todas as vezes que repetimos essa ação, consumia um tempo razoável, mesmo quando eram concertadas de forma automática por atalhos ainda consumiam um tempo que não seria necessário, então sugeriu o uso de um pacote do composer chamado easy coding standard que automatiza a correção de "erros" padrões de estilo de código. Esse pacote usa os pacotes php_codesniffer e o php-cs-fixer para executar suas ações.

O processo é simples, após instalar o pacote com o comando composer require symplify/easy-coding-standard --dev, você cria um arquivo chamado ecs.php na raiz do projeto, adicionando nele os padrões que deseja irá seguir, após isso execute o comando vendor/bin/ecs check caminho/do/arquivo/ou/diretório para checar os "erros" (não são erros de fato, apenas pontos a melhorar) de padrões e vendor/bin/ecs check caminho/do/arquivo/ou/diretório --fix para concertar os "erros".

Ao aplicar o fluxo que ele sugeriu, achei bem interessante e prático, principalmente para dev's que ainda estão aprendendo sobre essa padrões de estilo de código e ainda não entendem o uso das ferramentas. Até porque todo o processo fica resumido a um comando, mas nem tudo são flores.

Além do setup que pode ser trabalhoso a princípio, rodar um comando é mais um processo durante o desenvolvimento que pode ser facilmente esquecido quando queremos terminar algo ou apenas subir as alterações do código para o github, então pensei, como poderia automatizar a já automatizada verificação e correção de padrões de estilo de código? Após um pouco de pesquisa encontrei a resposta da minha dúvida, git hooks!

Hooks são ações que podem ser configuradas entre as ações do git, por exemplo, um hook pre-commit vai executar algo antes da ação git commit ser executada, assim podemos adicionar um hook para verificar nosso código e ajustar os padrões. Para fazer isso dentro da pasta .git do seu repositório adicione o arquivo um arquivo chamado pre-commit com o conteúdo.

# hook to fix style errors using ecs (easy coding standard)
# this hook is a pre-commit
# when using this script copy as pre-commit on folder .git/hook
# after copy give execution permission with "chmod +x pre-commit"

echo "start scan to find cs errors with ecs"    

ECS_BIN="./vendor/bin/ecs"    
HAS_ECS=false    

if [ -x $ECS_BIN ]; then    
 HAS_ECS=true    
fi    

if $HAS_ECS; then    
 echo "fix cs errors"    
 git status --porcelain | grep -e '^[AM]\(.*\).php$' | cut -c 3- | while read line; do    
   $ECS_BIN check "$line" --fix --quiet;    
   git add "$line";    
 done    
 echo "finish fixers"    
else    
 echo ""    
 echo "cannot run ecs please install in project"    
 echo ""    
 echo "   composer require symplify/easy-coding-standard --dev    "    
 echo ""    
fi

Como isso feito toda vez que o comando git commit for executado ajustes nos arquivos editados serão feitos. Essa é uma ótima abordagem, porém contem um problema, o arquivo pre-commit estará salvo apenas no repositório local e não será compartilhado com todos os outros que usam ou clonarem seu repositório. Isso pode ser contornado usando um pacote do composer chamado composer-git-hooks que facilita do gerenciamento de git hooks.

Instruções da instalação do pacote estão no repositório do pacote, após a sua instalação em extra do arquivo composer.json o seguinte:

"hooks": { 
            "pre-commit": [
                "echo committing as $(git config user.name)",
                "git status --porcelain | grep -e '^[AM]\\(.*\\).php$' | cut -c 3- | while read line; do vendor/bin/ecs check \"$line\" --fix --quiet; git add \"$line\"; done"
            ]
        }

Após isso esse hook será adicionado automaticamente no repositório, mesmo quando for clonado por outro desenvolvedor(a).

Acho que é algo conveniente a ser feito, porque todos que forem interagir com o projeto, versados ou não com estilos de código, no final obedecerão o estilo de código que foi definido e se forem necessárias alterações no estilo de código do projeto elas serão feitas em um ponto central e serão refletidas para todos que trabalham no projeto.

Obrigado por ter chegado até aqui, compartilhe como você lida com padrões de estilo de código. Se quiser, deixe as dúvidas nos comentários que farei meu melhor para responder, bem como sugestões ou criticas, estou linkedin como andresmeireles.