GBR: Docs MISC

Neste diretório encontramos documentos e documentações diversas.

• Brainstorm
• Estudos
• Planejamento
• Trabalhos Científicos
• Prospecção de produtos e clientes
• Produto Monitoramento e Telemetria

Organizar

Links p/ analisarmos e organizarmos nos assuntos diversos.

• OSS: https://github.com/github/opensource.guide#readme
• Misc: https://www.theerlangelist.com/

Como conversar com a AI?

*Planejamento* - Pesquisa e Desenvolvimento (P&D) - *Pesquisa:* Usar fluxo do método de pesquisa científica - *Pesquisa:* Usar fluxo de refinamento: - Brainstorm - -> Revisão - -> ADR(s) Proposto - -> [Revisar se retornamos p/ passo 1 ou 2] - -> EARS(s) - -> [Revisar se retornamos p/ passo 1 ou 2] - -> ADR(s) Aceito - -> EARS(s) Finais p/ os ADR(s) Aceito - *Desenvolvimento:* Usar especificações ADR e EARS como base para toda implementação. - *Desenvolvimento:* Usar TDD na implementação e assumir baby-steps p/ atingir o objetivo aos poucos.

Como iniciar um desenv. na AI

*Resumo* Estou precisando da sua ajuda, mestre, por gentileza seja um Especialista e Desenvolvedor Sênior Java, focado no Java v8/11.

*Problema* Estou tendo problemas para manter a Win.dll, que é um projeto C/C++ utilizando os PerformanceCounter do Windows p/ monitor os recursos do sistema operaciona Windows.

Para resolver este problema eu analisei e encontrei a biblioteca oshi-core que disponibiliza formas de monitar os recursos do windows sem a necessidade de eu manter ainda a Win.dll, e o projeto em C/C++.

*Solução* Para criar a nova operação java no código do Collector tive que implementar a classe  @GetDrivers.java utilizando a biblioteca oshi-core. Aproveitando eu vi que ela disponibilizava a função de monitoramento p/ uptime do sistema operacional e atualizei a operação já existente  @GetUpTime.java removendo o código legado utilizando a Win.dll via JNI.

*Próximos passos* Agora eu preciso da sua ajuda mestre, para podermos atualizar as operações relacionadas ao monitoramento da CPU no windows,  @GetTopCPU.java ,  @GetCpuByName.java ,  @GetCPUIdle.java ,  @GetCPUPriv.java ,  @GetCPUUser.java , para que elas utilizem os recursos da biblioteca oshi-core ao invés da chamada ao Win.dll via JNI em Collector_win.perfMon.

Eu criei um singleton para a instância retornada em new SystemInfo() da biblioteca oshi-core, por questão de desempenho. Caso precise utilizar alguma informação desta instância é só utilizar o singleton na classe pai  @OperacaoJAVA.java , systemInfo.

*Resultado esperado* Precisamos que os resultados que o código atual fornece NÃO seja alterado, ou seja, na nova implementação utilizando a biblioteca oshi-core temos que manter o mesmo formato retornado atualmente (a String formatada p/ retornar os dados da métrica coletada).

Como não podemos criar testes unitários neste caso, devido a natureza da implmentação ser totalmente dependênte da biblioteca legada Win.dll e do sistema operacional Windows. Mas temos alguns testes de integração que irão validar o formato de retorno, faça uma varredura nestes testes, se realmente existem, e faça um processo de TDD deixando tudo VERDE e se for necessário crie novos testes para nossa nova implementação utilizando o oshi-core.

Ao final temos que ter as métricas de CPU do Windows sendo coletadas exclusivamente utilizando a biblioteca oshi-core e o código ETL necessário p/ retornarmos os dados da coleta no formato correto.

*Pesquisa & Desenvolvimento* Mestre, esta primeira etapa é a pesquisa, então o objetivo é gerarmos o relatório de como será nosso desenvolvimento, atendendo ao requisito acima mencionado.

A próxima etapa será o desenvolvimento de fato, se e somente se, toda a pesquisa e relatório de desenvolvimento forem aprovados.