DEV Community: Fernando da Silva Sousa

Projeto Planning poker realtime com Laravel

Fernando da Silva Sousa — Fri, 24 Nov 2023 04:02:40 +0000

Como desenvolvi um planning poker com Laravel, Ably, InertiaJS, Tailwind e Vuejs.

naaando / planningpoker

Planning poker

Planning Poker

Overview

This is a Planning Poker project developed using Laravel as the backend framework, Vue.js for the frontend, Inertia.js for the middle layer, and Ably for real-time communication.

Usage

Welcome	Playing

Technologies Used

Requirements

Docker
Docker Compose
Database (e.g., MySQL)

Installation

Clone the repository:

git clone https://github.com/naaando/planningpoker.git

Copy the environment file:

cp .env.example .env

Configure the environment file:

Open the .env file at the root of the project and configure your environment variables, including the database configuration and Ably credentials.

Start the project with Sail:

./vendor/bin/sail up -d

Install PHP dependencies:

./vendor/bin/sail composer install

Generate the application key:

./vendor/bin/sail artisan key:generate

Run database migrations:

./vendor/bin/sail artisan migrate

Install Node.js dependencies:

./vendor/bin/sail npm install

Compile assets:

./vendor/bin/sail npm run dev

Contributing

Contributions are welcome! Please follow the instructions in CONTRIBUTING.md.

License

This project is licensed under the MIT License.

View on GitHub

Meu time de utiliza scrum na gestão dos projetos, uma parte desse fluxo de trabalho envolve estimar o tempo gasto nas atividades, e para isso utilizamos um jogo chamado planning poker para fazer as votações das estimativas.

Já existem diversos produtos prontos para esse propósito na forma de sistemas web então decidi criar mais um.

Login

A utilização de sistema de login foi descartada por se tratar de um sistema simples em que um sistema de login poderia atrapalhar a adesão dos usuários e gerar mais complexidade que o necessário, os nomes dos usuários são passados na hora do voto no payload.

Mecânica

A mecânica de um jogo desses não é complicada, você tem salas, onde ocorrem partidas e nas partidas são feitos os votos.

O trabalho da sala é manter um guardar a partida atual, assim pode ser utilizado o mesmo link em vários jogos e os usuários sempre vão conseguir acessar a partida certa.

A partida tem informações de inicio, fim, e o vínculo com a sala, por regra de negócio só pode ter uma partida aberta na sala.

Os votos possuem nome do usuário e valor (atualmente em fibonacci), como não tem usuário logado, o nome é necessário no voto para se ter o contexto.

Modelagem relacional

A modelagem relacional foi algo feito a contragosto já que não vejo necessidade de armazenar esse tipo de informação e queria simplificar ao máximo, mas dada a integração do eloquent ORM optei por utilizar uma modelagem com Postgres, mas algum sistema de dados em memória como Redis seria melhor aproveitado.

Modelagem

A modelagem pensada de forma relacional para se integrar com uma infra de postgres, mas poderia estar estruturada direto com redis em memória para otimizar performance.

Realtime

Um dos requisitos de um sistema de planning poker é funcionar em tempo real, dada a forma que os runtimes de PHP funcionam, existem poucas alternativas de websockets utilizando, a prática comum é a utilização de um serviço especializado na comunicação via websockets, como pusher, soketi, ably.

Aproveitando as integrações do Laravel eu utilizei o sistema de broadcasts do Laravel e o driver do Ably.

Fluxo

Aqui o fluxo completo do aplicação, o usuário deve inserir o nome ao acessar a aplicação, pode entrar em uma sala através de link ou criar.

Os eventos que ocorrem na API (backend) são enviados para a Ably que encaminha as mensagens por websocket para os usuários que estão escutando os eventos da sala.

Cada um desses eventos de websocket é tratado na interface e a cada alteração no estado da partida e das votações reflete imediatamente na interface.

Layout

A parte de layout foi a mais dificil, eu não tinha pensado sobre a complexidade do layout, acreditei que seria mais simples mas ao me deparar com várias alternativas (flexbox, grid, table, position absolute) de implementação, cada uma com seus problemas (e evitando usar js para não aumentar a complexidade).

Acabei optando depois de alguns testes, pela visualização com uma table e divs nas células posicionando os cartões, não fica muito adequado nas pontas mas foi o que ficou mais semelhante ao formato que eu buscava (formato de mesa de poker oval).

O responsivo ficou para ser implementado posteriormente e foi dada pouca atenção ao design da aplicação, pois o foco era em velocidade de entrega e funcionalidade.

Finalização e deploy

O deploy inicial foi preparado em uma VPS da Digital Ocean com Ubuntu, docker e PostgreSQL.

Preparei as actions do GitHub para validar os testes automatizados e fazer a imagem docker a partir do php oficial com apache.

O deploy continua manual mas é um script simples, então também pode ficar para uma melhoria futura.

Primeiro uso

Invés de lustrar muito eu quis mostrar o projeto conforme o que eu tinha conseguido produzir no período que eu me propus para não virar um projeto imaginário.

Aconteceram alguns problemas durante o test drive:

Durante a primeira votação meu sistema morreu e não levantou mais, tinha esquecido de habilitar o docker restart, outro agravante é que eu não preparei o monitoramento então nem acompanhei o log de crash.
O sistema foi feito usando o Firefox, quando foram executar pelo Chrome o layout ficou quebrado.

Mas já deu pra ter uma dimensão do que eu preciso corrigir e espero que em breve já esteja dando para utilizar como ferramenta principal para nosso planning poker.

O código está publicado no github com licensa MIT
https://github.com/naaando/planningpoker

O elefante na sala (gerenciando produtos de software em PHP)

Fernando da Silva Sousa — Wed, 15 Nov 2023 18:35:01 +0000

Neste texto busco auxiliar lideranças na gestão de produtos de software em PHP, abordando o fenômeno que conhecemos como legado de software, insights sobre estratégias e como podemos implementar processos e ferramentas de qualidade com PHP. Se trata sobre minha experiência empírica e em bases de autores de gestão de projetos e processos ágeis.

O PHP é uma linguagem amplamente usada, muito pela sua simplicidade, com servidor HTTP e camada de view abstraídos, com pouco conhecimento se pode fazer coisas realmente interessantes, é um processo diferente de linguagens fortemente tipadas, com compilação, estrutura, orientação a objetos obrigatória, etc.

Funciona muito bem para hobby e desenvolvimento rápido de produtos simples, conforme a aplicação evolui precisa de uma arquitetura mais adequada, idealmente seguindo ou documentando padrões, aplicações web já foram feitas tantas vezes que emergiram padrões para nos auxiliar.

A origem do legado

Muitos sistemas são construído na mentalidade de projeto, mas sistemas são mais parecidos com serviços, eles interagem com protocolos, com ecossistemas, bibliotecas e serviços, além de melhorias na própria plataforma em que foram desenvolvidos, eventualmente algum desses pontos precisa de atualização.

Os motivos principais para um sistema ser considerado legado são

Dependências descontinuada

É a possibilidade mais remota, a não ser que uma tecnologia exótica com pouquíssimos usuários, se o planejamento foi bem feito durante a construção esse risco já deveria estar previsto.

Trabalhar com sistemas open source também mitiga bem esse risco, usualmente outros provedores desse serviço também costumam emergir para ocupar o lugar e em ultima instância você pode incorporar a rotina de manutenção desse sistema por conta própria.

Descaso com atualizações

Os softwares sempre tem novas versões, e existem razões para se preocupar em atualizá-los. A medida que a atualização de um sistema vai sendo postergada existe um efeito na segurança e outro pouco visível na produtividade, novas versões trazem novas soluções para os problemas, as documentações e tutoriais na internet começam a focar nas novidades.

Qualquer sistema com a versão abaixo da LTS deveria ser tratado como um risco de segurança e impacto de performance.

Aumento na complexidade do projeto

Existe na literatura técnica diversos registros de que ocorre um aumento exponencial da complexidade ao adicionar novos recursos a um sistema existente quando ele não possui uma boa arquitetura e seus débitos são acumulados.

Um projeto pode ter sido concebido de forma mal estruturada ou pode ter ficado assim após os autores originais terem saído. De qualquer forma não houve atenção e habilidade suficientes para acompanhar as agendas de atualizações dos sistemas.

Dividir para fracassar

A maioria dos sistemas não devem e não podem ser reescritos do zero. Qualidade não é um programa que pode ser instalado de maneira simples. Seu projeto chegou nesse estado e pode acontecer de novo até mesmo na fase inicial da instalação de um framework, desenvolvedores ruins costumam se escorar nessa solução e existe o risco de fazer um sistema pior que o primeiro.

É uma ideia comum pensar em abandonar a tecnologia atual e apostar na escrita de um sistema novo, e na teoria é uma tarefa trivial pois é possível fazer alguns CRUDs por dia, então supõem que é possível parar de dar manutenção e funcionalidades ao sistema antigo e começar um sistema novo. Um projeto isolado para substituir no final, a medida que o tempo passa mais demandas vão sendo impostas sobre o sistema antigo, então começa a briga por recursos de desenvolvimento.

Você incorre em dois problemas principais, você precisa entregar funcionalidades com a metade do contingente no sistema antigo, que é lento para implementar as coisas, e o novo sistema ainda não está pronto para produção.

Elevando os padrões

O maior efeito perceptível de incremento de qualidade é quando existe um consenso sobre. Satisfação dos desenvolvedores ao desenvolver, da gerencia sobre a produtividade e dos usuários quanto a confiabilidade, funcionalidade e performance do sistema.

Alguns pontos chave para tratar da qualidade da aplicação

Revisão de código

Os processos de revisão de código são de certo a parte mais importante pois é a partir da entrada de novos códigos que melhoramos ou pioramos o que existe, é preciso bloquear commits diretos para master/main, mesmo os desenvolvedores mais experientes não devem ter esse tipo de permissão. É necessário que outros desenvolvedores experientes na base de código avaliem, também é importante observar que se a nenhuma revisão aponta problemas e melhorias, a revisão não está sendo feita corretamente.

Implementação de pipelines

Pipelines integram nos eventos do repositório e podem executar ações para validar se testes automáticos da qualidade do sistema continuam passando, validam se a forma de escrita está de acordo com a definição da equipe (via linters), executam implantações em servidores de teste e produção.

Monitoramento de defeitos e exceções

Não basta esperar a crítica dos clientes, é necessário fazer um monitoramento proativo de problemas e reportar para os clientes antes que eles precisem comunicar o problema, isso estabelece uma confiança na ferramenta, ferramentas como Sentry, Bugsnag, Datadog, Raygun, etc. conseguem sumarizar os erros tanto do frontend quanto do backend para que o problema possa ser corrigido o mais rápido possível, também é importante tratar dos falso positivos para que não tire a visibilidade dos problemas reais.

Estilização de código

O PHP tem um padrão de estilização de código definido pela PSR-12, é uma boa prática segui-lo, mas também existem os padrões do Laravel, Symfony, e outros. É possível automatizar com o ecs ou phpcs, e no caso do Laravel, com o Laravel Pint.

Análise estática e refatoração automatizada

O PHP é uma linguagem interpretada, isso implica em só saber que um código está com problema (seja sintático ou lógico) durante a execução. IDEs mais recentes introduzem algum tipo de validação sintática através do Language Server Protocol, também existem ferramentas para conseguir fazer essa análise de forma estática como PHPStan e PSalm que podem aprimorar a qualidade do código e evita bugs antes mesmo de entrar em produção.

Para refatoração automatizada de código existem ferramentas como Rector e Phabric, com o Rector é possível migrar automaticamente entre versões do PHP e bases de código legada para os padrões mais recentes usando regras personalizadas, frameworks também costumam criar regras para o Rector facilitando a atualização.

Conclusão

O PHP é uma linguagem acessível mas exige uma atenção com qualidade assim como qualquer outra tecnologia para que seja produtiva e atenda as necessidade dos consumidores, ao atentar para se manter atualizado garantimos entregas, segurança e performance nos mantendo produtivos e competitivos mediante o mercado. Também é importante lembrar que assim como na engenharia tradicional, grandes saltos de produtividade advém de novas ferramentas e é importante incorporar o uso delas para se beneficiar.