Nas últimas 2 semanas fomos inundados com posts sobre DeepSeek. Não estou escrevendo sobre DS, mas é relacionado, não consigo escapar 🙂
Este artigo é excelente para afiar suas habilidades como engenheiro. Isso é ainda mais importante porque o mundo da IA está se movendo rapidamente em direção a um mundo de código aberto, onde teremos uma infinidade de opções disponíveis.
Eu adoro Dezembro. Natal, Ano-Novo, uma ou 2 semanas de ferias, a retrospectiva das conquistas do ano e … AdventOfCode. O AdventOfCode é um desafio anual de programação que consiste em quebra-cabeças que podem ser resolvidos em qualquer linguagem de programação. O evento é direcionado para pessoas com diferentes níveis de habilidade em programação e oferece uma oportunidade para aprimorarem nossas habilidades e aprender novas técnicas. Os desafios são lançados diariamente durante o mês de dezembro até o dia 25, no natal. Sempre há 2 problemas e para cada um resolvido você ganha uma estrela.
Vou ser honesto e dizer que até 2022 eu resolvia alguns desafios mas nunca fui consistente. Este ano eu decidi levar a sério e até o dia 8 eu coletei todas as 16 estrelas. E como disse acima, estou encarando como uma oportunidade de aprendizado: todo problema tem um exemplo com a solução, então cá estou fazendo TDD, o ciclo clássico red-green-refactor; todo dia você baixa um arquivo texto como input e resolve para cada uma das estrelas, então cá estou com um template automatizado em node que gera uma estrutura comum de arquivos e pastas; os problemas podem ser resolvidos de vários modos, então cá estou calculando o desempenho da minha solução e otimizando; estou publicando as minhas respostas dia-a-dia, então cá estou comentando o meu código para que minhas intenções sejam claras; como há um problema por dia, então cá estou encarando cada dia como uma versão, automatizei a geração de versões no Github usando release-please.
Minha estrategia cada dia tem sido a mais ingênua, tento resolver tudo por força-bruta. Quando demora muito, eu paro e penso em algo melhor. Se está aceitável (bem, aqui é bastante subjetivo, qualquer coisa rodando em menos de 3 minutos, ok), eu envio as respostas e ao fim do dia revisito o problema e reflito se há um modo melhor de fazer. Um exemplo, em um dia era necessario calcular caminhos usando um mapa com instruções. Minha primeira abordagem foi com um loop, depois de resolvido percebi que poderia usar o mínimo múltiplo comum dos diversos caminhos.
Vamos ver se consigo manter-me em dia com os problemas, tem sido muito divertido, eu recomendo fortemente!
Após retornar do API Days em Londres, estou estudando padrões de design para APIs. O último artigo que li foi “Arguments and Results” de James Noble (1), publicado em 1997 e ainda extremamente relevante. Parte do meu trabalho atual, desenvolver um data warehouse, é otimizar o transporte de grandes volumes de dados. E se eu quiser usar APIs, como posso fazer isso de forma eficiente? Há um consenso de que APIs REST não são adequadas em cenários de alto volume e estudando esse tópico cheguei ao Noble.
O artigo discute padrões para protocolos de objetos e para isso existem dois grupos:
De
void Send-FixedIncome(EntityName, IssueDate, MaturityDate, PrincipalAmount, ...) { }Para
void Send-FixedIncome(FixedIncome) { }“adding an eleventh argument to a message with ten arguments is qualitatively quite different to adding a second argument to a unary message”
De
void CalculateHomeLoanAmount(HomeLoan, Collateral) { }
void CalculateHomeLoanAmount(HomeLoan) { }
void CalculateAutoLoanAmount(AutoLoan) { }
void CalculatePersonalLoanAmount(PersonalLoan) { }Para
void CalculateAmount(LoanType, Loan) { } //Loan would be the interface for all loan types“Protocols (APIs) where many messages perform similar functions are often difficult to learn and to use, especially as the similarity is often not obvious from the protocol’s documentation”
De
void SettleDebt(Loan, ParcelsToPay) { } # no. of parcels can be retrieved from the loan Para
int GetOpenParcels(Loan) { }
void SettleDebt(Loan) { () => Settle(Loan) } # in Settle no. of parcels is retrieved“These kinds of arguments increase the complexity of a protocol. The protocol will be difficult to learn, as programmers must work out which arguments must be changed, and which must remain constant.”
“Perhaps the computation returns more than on object”
” Sometimes you need to ask a question, then do something else while waiting for the answer to arrive”
“Some computations can best be performed immediately but the computation’s result may never be needed”
Em suma, estes conceitos já são bastante difundidos. Qualquer linguagem de programação mainstream tem suporte para métodos assíncronos (Lazy object) e avaliação lenta (Lazy object). Além disso, um bom design OO faz com que o ‘Arguments object’ e o ‘Selector object’ apareçam naturalmente. Foi um bom artigo back-to-basics para me lembrar da importância de um bom design em meus métodos de API.
Esta semana estive em Londres atendendo o evento ApiDays. Uma vez ao ano eu participo de um evento externo, em adição a estudar sozinho, é importante encontrar colegas de profissão e conversar sobre o que acontece nas trincheiras. Para a minha surpresa, IA não foi o tema central, assisti por volta de 30 palestras e apenas 4 eram especificamente sobre IA. Dois grandes temas no evento:
Governança de API’s: Ênfase dada ao ciclo de vida das API’s: definição->design->desenvolvimento-> testes->publicação->operação. O que eu vou levar para casa:
Democratização de API’s: Aqui há 2 visōes que estão convergindo, por um lado experts dizem que devemos desenvolver as API’s pensando em devops e gitops. Esta visão coloca uma grande importância nos aspectos de governança mencionados no item anterior; em adição, esta visão ressalta interoperabilidade e composibilidade como atributos essencias para API’s modernas. Por outro lado, se olharmos para a composição mais comuma das empresas, apenas 10% são da área de tecnologia (pesquisa da Gartner exibida em uma das palestras); temos 49% de usuários finais e 41% classificados como analistas de negócio tecnólogos. Estes 41% criam soluções de tecnlogia ou de análise a partir das soluções que a área de TI fornece. Eles cunharam o termo ‘mundo da economia pós-API’ para abraçar este pessoal que tem ter acesso facilitado às API’s. Quanto mais simples for, mais fácil será para produtos inovadores surgirem a partir da informação disponível. Esta segunda visão aposta em API’s abertas e públicas, aposta em ecossistemas e marketplaces.
Vou citar 2 ferramentas que testei no evento e achei fantásticas:
Superface.ai: OK, existem catálogos de API’s, sabemos do conceito de observabilidade, como lidar com API’s que são similares porém com formatos diferentes? Pense no wttr.in e no OpenWeatherMap, ambas permitem que você veja se vai chover hoje em Londres. Mas a similaridade termina aí, é necessário fazer o código para cada uma delas. Mais, se uma delas estiver indisponível você é responsável por rotear o pedido. O Superface lida com isto: (1) você fala qual o seu contrato (2) o Superface tem agentes autônomos que descobrem API’s condizentes com o seu contrato e mapeia o seu contrato para o contrato das API’s que ele localizou. (ok, aqui tem IA 🙂)
Mocking servers do Postman: eu uso Postman frequentemente para testar API’s, e descobri que nele você pode prototipar a sua API. Desenhe seus métodos, especifique os contratos a partir de exemplos e o Postman cria a documentação e um endpoint. Quando eu queria pensar em uma API, usava o httpbin, isto é muuuito mais bacana.
Selenium tem sido minha ferramenta de escolha para automação de testes de UI por um bom tempo, e com razão. Ele foi o pioneiro e eu usei muito, mas recentemente tornei-me um fā do Cypress. Eu fiz um curso sobre Cypress (todos os exercícios podem ser encontrados no meu GH), e me convenci completamente de que ele apresenta uma alternativa mais eficiente e confiável.
Ao analisar as diferenças entre Selenium e Cypress, alguns fatores-chave se destacam. Selenium suporta várias linguagens incluindo Java, Python, C#, e outras enquanto Cypress é puramente JavaScript. Isso pode inicialmente parecer limitante, mas considerando que a maioria das aplicações web são agora baseadas em JavaScript, Cypress se torna uma escolha natural. Testes Selenium são executados fora do navegador enquanto Cypress roda diretamente dentro do navegador. Isso permite ao Cypress controlar todo o processo de automação, incluindo tráfego de rede, temporizadores e até mesmo o carregamento do código JavaScript. É este controle interno que promete estabilidade – uma promessa que o Selenium muitas vezes não consegue manter devido à suas dependências externas. A possibilidade de testar sua automação com opções de debugger no navegador é revolucionária, passo muito tempo entendendo meus scripts usando as abas do console, styles e rede, tenho certeza de que os desenvolvedores FE estão muito familiarizados com elas.
Cypress fornece uma API simples e fluida para interagir diretamente com o DOM, dê uma olhada:
describe('DOM Interactions Test', function() {
it('Fills and submits a form', function() {
cy.visit('https://www.example.com/form') // Cypress loads the webpage
cy.get('input[name="firstName"]').type('John') // Cypress finds the input field firstName and types 'John' into it
cy.get('input[name="lastName"]').type('Doe') // Cypress finds the input field lastName and types 'Doe' into it
cy.get('button[type="submit"]').click() // Cypress clicks the submit button
})
})Compare com Selenium
WebDriver driver = new ChromeDriver();
driver.get("https://www.example.com/form"); // Open URL
WebElement firstName = driver.findElement(By.name("firstName"));
firstName.sendKeys("John"); // Fill the firstName input
WebElement lastName = driver.findElement(By.name("lastName"));
lastName.sendKeys("Doe"); // Fill the lastName input
WebElement submitButton = driver.findElement(By.tagName("button"));
submitButton.submit(); // Submit the formCypress permite que você interaja com seletores CSS!
Outra grande vantagem do Cypress é sua capacidade de lidar com operações assíncronas muito facilmente.
describe('Asynchronous Handling Test', function() {
it('Waits for an element to be visible', function() {
cy.visit('https://www.example.com') // Cypress loads the webpage
cy.get('#asyncButton', { timeout: 10000 }) // Cypress waits for the element with id 'asyncButton' to become visible for up to 10 seconds
.should('be.visible') // Asserts that the element should be visible
.click() // Clicks the button once it's visible
})
})Lidar com API’s também é moleza:
describe("Todo List API Interaction", () => {
// Define the base URL of your API
const apiUrl = "https://example-api.com";
beforeEach(() => {
// Intercept the API call and load a JSON payload for the response
cy.intercept("GET", `${apiUrl}/todos`, { fixture: "todos.json" }).as("getTodos");
// Visit the application or a specific page where the API call is made
cy.visit("/todo-list");
});
it("should fetch todos from the API and display them", () => {
// Perform any actions that trigger the API call (e.g., click a button to fetch todos)
cy.get("#fetch-todos-btn").click();
// Wait for the API call to complete and the response to be displayed
cy.wait("@getTodos");
// Assert that the correct API endpoint was called and the response was handled properly
cy.get(".todo-item").should("have.length", 3); // Assuming the response contains 3 todo items
});
});O que para mim é o grande atrativo é a minha ressalva: ao interagir a partir dos seletores CSS demanda que você seja cuidadoso ao escolher aqueles que têm menos chance de mudar e quebrar seus testes. Ainda assim, eu pretendo apenas usar Cypress para meus testes de UI.
Uma das minhas estruturas de dados favoritas para operações de busca eficientes é o filtro de Bloom, acabei de encontrar esta demonstração, confira lá.
Nomeado em homenagem ao seu criador, Burton Howard Bloom, um filtro de Bloom é uma estrutura de dados probabilística eficiente em termos de espaço, projetada para responder a uma pergunta simples: “Este item está no conjunto?”. Ao contrário de outras estruturas de dados, um filtro de Bloom compensa a precisão pela velocidade e eficiência de espaço, o que significa que às vezes pode retornar falsos positivos, mas nunca falsos negativos.
O filtro de Bloom funciona usando um vetor de bits de tamanho ‘m’ e ‘k’ funções de hash. Quando um elemento é adicionado ao filtro, ele é passado por todas as ‘k’ funções de hash, que retornam ‘k’ índices para definir como ‘1’ no vetor de bits. Para verificar se um elemento está no filtro, as mesmas ‘k’ funções de hash são aplicadas. Se todos os ‘k’ índices no vetor de bits forem ‘1’, o filtro retorna ‘sim’; caso contrário, retorna ‘não’. Uma resposta ‘sim’ pode significar que o elemento definitivamente não está no conjunto (verdadeiro negativo) ou pode estar no conjunto (falso positivo), mas uma resposta ‘não’ sempre significa que o elemento não está no conjunto (verdadeiro negativo). Note que ao implementar você deve pensar cuidadosamente quantas funções de hash utilizar e qual a taxa aceitável de falsos positivos.
Filtros de Bloom são amplamente utilizados em aplicações de software onde o custo de falsos positivos é menos crítico do que os benefícios de velocidade e eficiência de espaço. Algumas dessas aplicações incluem corretores ortográficos, roteadores de rede, bancos de dados e caches. Eu tenho um aplicativo gerador de senhas e uso Filtro de Bloom para verificar se uma senha já foi usada.
Gossip protocol é uma técnica descentralizada de comunicação peer-to-peer para transmitir mensagens em um enorme sistema distribuído (…)
[Em inglês]
Outra perspectiva para um tema polêmico.
https://blog.pragmaticengineer.com/yes-you-should-estimate/
[em inglês]