| package br.com.zup.hackton.palindromo; | |
| import org.apache.commons.lang3.StringUtils; | |
| /** | |
| * Algumas palavras e frases: | |
| * | |
| * ana, arara, mussum, mirim, ovo, reviver, socos, salas, ralar, e2e, 1-a-1 | |
| * anotaram a data da maratona | |
| * socorram-me subi no onibus em marrocos |
A ideia é implementar um Quick Command que converte uma schema DDL para entidades e em seguida para uma API REST em Java com Spring Boot. Este Quick Command terá 3 passos:
O objetivo deste Quick Command é gerar templates Terraform para provisionar infraestrutura a partir de diagramas Mermaid seguindo um conjunto de regras do time ou empresa. Este conjunto de regras é configurado como Knowledge Source em alguns passos do Quick Command.
Para criar o Quick Command, basta configurá-lo com o passos abaixo:
Name: generate-terraform-from-mermaid
| @RestController | |
| class CustomerController { | |
| @Autowired | |
| private CustomerService service; | |
| @PostMapping("/api/customers") | |
| public void create(@Valid @RequestBody CustomerRequest request) { | |
| service.save(request); | |
| } |
| # Submitting a request to invoke a specific Remote Quick-Command | |
| curl --request POST \ | |
| --url https://genai-code-buddy-api.stackspot.com/v1/quick-commands/create-execution/{slug-qc} \ | |
| --header 'Authorization: Bearer <TOKEN>' \ | |
| --header 'Content-Type: application/json' \ | |
| --data '{ | |
| "input_data": "qual tecnologia a microsft usa, responda em portugues" | |
| }' | |
| # Checking the result of the previous Quick-Command |
| stk apply plugin ../coffee-studio/java-springboot-restapi-base-plugin \ | |
| --inputs-json '{"project_name": "iFood Web", "project_description": "iFood Web Super Application", "project_springboot_version":"2.7.2", "project_group_id": "br.com.zup.edu", "project_artifact_id":"iFood Web App", "project_version":"0.0.1-SNAPSHOT"}' |
| # we can generate the report as "json" or "md" (markdown) | |
| stk deploy status <execution_id> --report json |
Perf
Teste carga signigica verificar como uma aplicação ou sistema se comporta sob uma determinada carga de trabalho (workload) esperada, que pode ser uma carga pequena, moderada ou grande. Além disso, essa carga é aplicada durante algum intervalo de tempo, como minutos ou horas, para validar a estabilidade do sistema e detectar possíveis problemas no uso de recursos, como memória, CPU, disco ou conexões com um banco de dados por exemplo. É importante entender que um teste de carga não ultrapassa a capacidade esperada ou projetada para uma aplicação ou sistema.
Enquanto teste de estresse está relacionado a verificar como uma aplicação ou sistema se comporta quando aplicamos uma carga de trabalho (workload) muito alta e intensa, geralmente uma carga superior a esperada ou especificada nos requisitos. A ideia aqui é submeter a aplicação além da sua capacidade projetada a fim de detectar problemas ou gargalos no uso de recursos ou componentes internos. O
Pretendo apresentar um código com uma lógica de negócio simples que funciona bem na perspectiva do negócio mas que quebra miseravelmente em ambientes minimamente concorrentes. Para isso, vou demonstrar através de testes de integração como identificar o Race Condition no código e principalmente como resolvê-lo através de mecanismos de locking e Isolation Level do seu banco de dados;