API first - ótimo com IA

        API first é uma abordagem de desenvolvimento de software onde o contrato de definição da API é feito primeiro que o código.

        Aplicar o "API first" sem IA é um trabalho chato e acho que demora mais do que sentar na reunião e fazer algumas anotações sobre os recursos e suas interações na mão, depois codar a API e disponibilizar para a outra equipe (se for o caso) e fazer alguma correção. Achei realmente muito cansativo, trabalhoso e demorado. Em uma empresa que trabalhei, para APIs externas era usado esse conceito, mas não era o time de dev do projeto (vulgo squad) que fazia, era uma equipe só pra isso, tinha que abrir chamado e passar o JSON do recurso, os endpoints e tal (meio como vou fazer abaixo com o prompt da IA).

        O motivo principal de fazerem isso na empresa para APIs externas ao invés de simplesmente configurar o Swagger no projeto com Spring Boot e ele ir tomando forma acredito era pra disponibilizar o Swagger para clientes externos, uma vez que o Swagger do projeto não ficaria exposto em produção, então eles tinha um endereço de documentação onde expunham o .yaml gerado para clientes externos acessarem. Pra equipes internas não sei se valeria o trabalho. 

        Com a IA é molesa, mas na mão, vi em um vídeo (que vou deixar no final) e achei um inferno! Então vou deixar o prompt aqui de exemplo para usar sempre que for preciso. Claro que no momento de gerar pode (e deve) passar mais informações, como campos obrigatórios, se usa autenticação, qual tipo de autenticação, url de autenticação, tudo isso é importante para a documentação da API!

Cria pra mim o .yaml do swagger para API first seguindo a seguinte especificação:

openapi: 3.1.0

title: pedidos

description: DOC API pedidos

servers: https://localhost:8080/pedidos-api

versione no padrão: /api/v1/recurso

Recurso /pedidos

GET - 200 OK

GET {id} - 200 OK ou 404 Not Found

POST - 201 Created ou 400 Bad Request

PUT {id} - 202 Accepted ou 404 Not Found

DELETE {id} - 202 Accepted ou 404 Not Found

JSON objeto:

 

{

  "idPedido": 160253,

  "idCliente": 123658,

  "produtos": [{

        "idProduto": 6548,

        "descricao": "Livro Java - Como programar",

        "quantidade": 1,

        "valorUnitario": 250.00

  }]

  

}

O link do vídeo que ensina a fazer a documentação na mão é o: https://www.youtube.com/watch?v=cksLbT8nDB4

Metodologia Twelve-Factor

         A metodologia Twelve-Factor App é um conjunto de 12 regras para manter uma aplicação de forma eficaz, sendo elas:

1. Codebase (Código-fonte único): Uma aplicação deve ser armazenada em um único repositório de código, com múltiplas implantações derivadas do mesmo código-base.

2. Dependencies (Dependências explícitas): Todas as dependências da aplicação, incluindo bibliotecas e ferramentas de sistema, devem ser declaradas explicitamente e gerenciadas de forma isolada.

3. Config (Configurações): As configurações da aplicação devem ser armazenadas em variáveis de ambiente, não no código-fonte, para permitir a configuração flexível em diferentes ambientes.

4. Backing Services (Serviços de Back-end): Os serviços de back-end, como bancos de dados e filas, devem ser tratados como recursos externos, acessíveis por meio de interfaces padrão.

5. Build, Release, Run (Construir, entregar, executar): O processo de build, entrega e execução da aplicação deve ser separado em etapas distintas, com cada etapa tendo suas próprias responsabilidades e garantindo a consistência entre ambientes.

6. Processes (Processos): As aplicações devem ser executadas como processos independentes, leves e sem estado (Stateless), para facilitar a escalabilidade e a resiliência.

7. Port Binding (Ligação de porta): As aplicações devem ser autocontidas e expor serviços por meio de portas, para que possam ser facilmente conectados a outras aplicações e serviços.

8. Concurrency (Concorrência): As aplicações devem escalar horizontalmente, adicionando instâncias concorrentes para lidar com cargas de trabalho aumentadas.

9. Disposability (Descartabilidade): As aplicações devem ser fáceis de iniciar e parar rapidamente, sem impacto para outras partes do sistema, para facilitar o deploy e a atualização contínua.

10. Dev/Prod Parity (Paridade dev/prod): Os ambientes de desenvolvimento, testes e produção devem ser o mais semelhantes possível, para minimizar diferenças e evitar problemas de compatibilidade.

11. Logs (Registros): As aplicações devem produzir logs estruturados e acessíveis por meio de interfaces padronizadas, para facilitar a depuração e o monitoramento.

12. Admin Processes (Processos de administração): As tarefas administrativas, como migrações de banco de dados e limpeza de caches, devem ser executadas como processos únicos e rastreáveis.

Fonte: https://12factor.net/pt_br/

Instalando o Docker no Windows usando WSL 2 e Ubuntu

          Nesse artigo vamos configurar o Docker pra rodar no Ubuntu através do WSL 2 de forma nativa (como se a máquina fosse Linux puro). Caso não tenha o WSL 2 configurado veja aqui como fazer: Configuração WSL 2

 

Agora vamos ao Docker! O primeiro passo é atualizar a biblioteca do Ubuntu de gerenciamento de programas:

 Obs: Para versão 22-4 do Ubuntu ver aqui. 

$ sudo apt update && sudo apt upgrade

 

Depois instalar as dependências como Http, certificados, acesso a URLs, etc...

 

$ sudo apt-get install \

    apt-transport-https \

    ca-certificates \

    curl \

    gnupg \

    lsb-release

 

Agora adicionar o repositório Docker na biblioteca do Ubuntu:

 

$ sudo mkdir -p /etc/apt/keyrings

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

 

Agora para configurar o repositório:

 

$ echo \

  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

 

Vamos mais uma vez atualizar a biblioteca:

 

$ sudo apt-get update

 

Agora sim vamos instalar o Docker. Para a instalar a última versão usamos:

 

$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

 

Para instalar uma versão específica primeiro listamos as versões:

 

$ apt-cache madison docker-ce | awk '{ print $3 }'

 

E então instalamos a que desejamos. Ex:

 

$ VERSION_STRING=5:20.10.13~3-0~ubuntu-jammy

$ sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING containerd.io docker-compose-plugin

 

É preciso também dar permissão a pasta criada. A instalação do Docker já espera que haja um grupo chamado "docker". Veja com o comando "groups" se esse grupo "docker" já existe, caso não tenha sido criado, siga as duas linhas abaixo, caso tenha sido criado, apenas adicione seu usuário a ele.

 

$ sudo groupadd docker

$ sudo usermod -aG docker $USER

 

Pronto, agora é só fazer logoff e login ou fechar o app do Ubuntu e abrir novamente para poder usar o docker.

 

Atenção! Em alguns casos ao sair e entrar no App do Ubuntu (e outras distribuições) ele desliga o serviço do Docker. Caso isso aconteça pode ser resolvido da seguinte maneira:

 

$ sudo systemctl enable docker.service

$ sudo systemctl enable containerd.service

 

Isso adiciona o serviço do Docker ao Systemd que gerencia serviços que inicializam automaticamente. Caso queira remover basta usar o "disable" ao invés do "enable".

 

 

Fonte:

https://docs.docker.com/engine/install/ubuntu/

https://docs.docker.com/engine/install/linux-postinstall/

https://github.com/codeedu/wsl2-docker-quickstart#instala%C3%A7%C3%A3o-do-wsl-2

 

Glowroot - Ferramenta grátis para profiling remoto de aplicações Java

       Hoje vou apresentar uma ferramenta de profiling gratuita para aplicações Java, o Glowroot. 

   

    Mas primeiro uma rápida explicação dobre o que é profiling. Profiling é o processo de monitoramento e medição de desempenho das aplicações para manutenção e melhoria de performance e busca de erros que levam a queda do sistema. 

    

    Existe uma vasta variedade de programas que fazem esse tipo de serviço, a maioria deles é pago, e os gratuitos geralmente são bem limitados ou não tem uma interface web para acesso remoto. O Glowroot é uma boa opção porque é gratuito e tem a interface web, facilitando o trabalho. Antes dele eu usava o Jvisualvm que já vem por padrão nas JDKs (até a versão 8 se não me engano) mas é bem limitado e exige que o servidor tenha a parte gráfica habilitada e o acesso direto ao programa. 

    

    O Glowroot permite acompanharmos o uso de memória, mostra as falhas a nível de métodos, permite vermos as consultas mais pesadas da aplicação, etc. Ou seja, uma ferramenta completa e de fácil instalação. 

     A ferramenta pode ser baixada no seguinte endereço: https://glowroot.org/ 

    

    Lá também tem as instruções de instalação. Após instalar o Glowroot, na pasta glowroot vai ser criada uma subpasta de logs e uns arquivos. Para disponibilizar o Glowroot pela web é preciso alterar o endereço de 127.0.0.1 para 0.0.0.0 no arquivo admin.json. 

    A versão disponível nesse endereço é sempre a última, para versões anteriores você pode acessar o repositório do projeto: https://github.com/glowroot/glowroot/releases.

    Você também pode ver uma demo da aplicação rodando como na imagem abaixo:

Debug remoto no Tomcat com o Eclipse

    Nesse post vou mostrar como preparar o Tomcat para Debug remoto com o Eclipse.

    Primeiro precisamos criar um arquivo na pasta raiz do Tomcat, e esse arquivo muda de extensão e de conteúdo de acordo com o S.O..

    Vamos primeiro ao do Windows: pode chamá-lo de startupDebug.bat e o conteúdo básico deve ser o seguinte:

set JPDA_ADDRESS=8000
set JPDA_TRANSPORT=dt_socket
bin/catalina.bat jpda start

    No ambiente linux o arquivo pode ser chamado de startupDebug.sh e deve ter permissão de leitura e execução (+rx). O conteúdo básico é o seguinte:

export JPDA_ADDRESS=8000
export JPDA_TRANSPORT=dt_socket
bin/catalina.sh jpda start

    Feito isso, quando quisermos debugar o Tomcat pelo eclipse, basta executar o Tomcat a partir desse script, ao invés do startup.bat (ou startup.sh em ambientes Linux) que executamos de costume. A porta de acesso ao sistema via browser continua a mesma de antes, a nova porta configurada foi para o debug. Será necessário liberação da porta no firewall em caso de acesso a servidores protegidos.

    Tendo feito isso e com a aplicação já startada, vamos ao eclipse configurar o debug remoto.

    No eclipse, no menu Run vá em Debug Configurations, a seguinte janela abrirá:

    Clique com o botão direito do mouse na opção Remote Java Aplication e escolha a opção New Configuration.  A imagem abaixo mostra em realce cada ponto de configuração, que são bem intuitivos. Após escolher a aplicação e dizer o endereço da aplicação onde está o localhost, no campo Port coloque a porta que configuramos no arquivo e clieque em Debug.

    Pronto, se todas as configurações estiverem corretas, o eclipse vai se conectar com a aplicação e você poderá debugar normalmente o código. Abraços!

Git – Configurando o SSH no Windows e no GitHub

Criar uma chave SSH não é muito complicado. Quando instalamos o Git no Windows, ele já traz uma ferramenta para isso, o OpenSSH.

Então, vamos começar executando o git-bash, um terminal Linux para o Windows que também faz parte da instalação do Git. Após aberto o git-bash, digite:

ssh-keygen -t rsa -b 4096 -C "seu-email@aqui.com"

Você será indagado sobre onde salvar a chave, sendo que o prompt também já mostra um caminho default. Basta pressionar o “Enter” para criar a chave SSH no caminho default. Caso já exista uma chave salva, ele perguntará se deseja sobrescrever. Logo depois, ele pedirá uma senha e a confirmação:

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Caso não queira informar uma senha, pode apenas confirmar sem digitar nada (é recomendado criar uma senha, claro!). Então o prompt lhe informa que a sua chave privada e a sua chave publica estão no caminho indicado previamente, que se for o default é: C:\Users\seu-usuario\.ssh.

Adicione sua chave SSH ao SSH-Agente:

eval $(ssh-agent -s)

ssh-add ~/.ssh/id_rsa

E por fim, adicione sua chave a sua conta no GitHub, o comando abaixo copia sua chave para a memória e deixa pronto para colar no GitHub:

clip < ~/.ssh/id_rsa.pub

Depois, acesse sua conta no GitHub e vá nas configurações:

Clique em “SSH and GPG keys”.

Clique em “New SSH key”:

Adicione um título para identificação da sua chave (pois você pode ter mais de uma, de diferentes dispositivos) e cole a sua chave SSH, depois, confirme sua senha.

Pronto! 

https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
http://guides.beanstalkapp.com/version-control/git-on-windows.html

Tunando sua Linha de Comando Windows

As vezes compramos computadores e pela praticidade dos drivers e outras coisas que já vem instaladas ou pela pouca familiaridade com o Linux não queremos mudar o nosso S.O., porém como desenvolvedores as vezes queremos usar alguns comandos do Linux para auxiliar algumas tarefas.

Passando por isso, encontrei duas ferramentas legais e que trabalham juntas para isso.

A primeira, chamada Scoop.sh, permite pesquisarmos e instalarmos coisas via linha de comando de forma muito fácil, semelhante o Linux.

O endereço para essa ferramenta é:

http://scoop.sh/

Para instalar, abra o PowerShell como administrador e digite os 2 comandos abaixo:

1.     Set-ExecutionPolicy RemoteSigned -scope CurrentUser

2.     iex(new-object net.webclient).downloadstring('https://get.scoop.sh')

Esse vídeo de demonstração também é encontrado no site do scoop:

         

O scoop funciona como um gerenciador de aplicações, ou seja, o que você instala com ele, ele mantém uma lista pra que você possa gerenciar: usar, atualizar, desinstalar, etc.

O comando scoop list  mostra o que você tem instalado. O comando scoop search nomeDeUmPrograma busca um programa no repositório e lista para você escolher o que vai instalar.

Então agora vamos instalar o utilitário que disponibiliza comandos do Linux para a linha de comando do Windows. O nome dessa ferramenta é busybox.

Você pode saber mais sobre esta ferramenta em:

https://www.busybox.net/about.html

Os comandos são:

1.      scoop search busybox

2.      scoop install busybox

3.      scoop list

Outras ferramentas que eu aconselho são openssh, nano, 7zip. Daí em diante basta ir instalando e usando o que precisar, como git, node, etc...

Espero ter ajudado, até a próxima!