DEV Community: Victor de Oliveira Marinho

[dependêncIA] como (não) usar ferramentas de inteligência artificial de modo (in)produtivo para dev

Victor de Oliveira Marinho — Mon, 21 Jul 2025 14:53:24 +0000

Fala minha tropa, hoje venho trazer um tema aqui que tenho já matutado a um bom tempo, e acredito que agora eu tenho o mínimo de maturidade para poder falar sobre (embora ache que isso é só o começo de uma série, já que a IA veio pra ficar).

O gatilho desse texto foi um post do Leandro Proença (que também lançou um post no Bluesky), e a partir dos breve comentários, achei que seria massa trazer isso de uma forma mais corrida (acredito que em breve saia o artigo dele também sobre isso).

Para começar, antes que os defensores de vibe coding venham tacar preda, eu trago nesse texto a minha experiência com inteligência artificial, e também de como eu acredito que ela pode ser benéfica. Já fui um cara mais contra ela, mas na engrenagem do capitalismo, eu não faço as regras, eu só aceito. Pois bem, vamos lá.

Eu, Robô

Bom, eu estive envolvido em dois momentos com projetos de IA de forma profissional, e acredito que isso me possibilitou ver dois momentos distintos o quanto ela avançou para o usuário final. Em 2023 a 2024 (se não me falha a memória), eu estive em um projeto pensando Chatbots com IA para auxiliar uma área que era muito onerada pelos contatos via aplicativo de comunicação interna. A ideia era utilizar alguma ferramenta que ajudasse a fazer uma triagem e resolver pequenas dúvidas. Tive contato nesse período com as ferramentas do Chatbase (que usa o GPT por baixo dos panos), e também do Gemini e Amazon Q (esses tive só apresentação de consultorias, sem ter um uso efetivo).

No segundo momento, foi quando passaram a avaliar ferramentas de código com IA embutida. Por conta de me envolver em bastante projeto, acabei tendo a oportunidade de participar desse piloto junto com outros devs, e aqui foi onde eu acho que começou a ter coisas com as quais eu não concordava, não via que agregava valor e que não entregava resultado, segundo meu ponto de vista.

Minority Report

Pois bem, esse segundo momento foi um processo mais impositivo, mas acredito que era para justamente testar os limites da ferramenta e saber onde ela atenderia ou não. A ferramenta escolhida foi o Cursor, e a primeira vista não dei muita bola, até começar a perceber que havia uma pressão maior para usar a ferramenta diariamente (e era válido, aliás, quem estava encabeçando o projeto precisava de dados para tomar uma descisão). Decidi me abrir para a ferramenta, e comecei de forma tímida a utilizar o Chat, muito para geração de ARDs e PRDs das aplicações legadas, e me pareceu muito interessante nesse sentido.

Depois avancei para uso do autocomplete e, enfim, comecei a ter uma fluidez maior. Contudo, sempre com um pé atrás - aliás, sou de humanas, essa criticidade de tudo faz parte de mim. Passado um tempo, a ferramenta se afirmou como útil, mas ao meu ver de forma muito prematura. Acredito que um tempo maior de benchmark faria mais sentido, além de qualificar os dados: quem estava usando a ferramenta (por níveis de Jr, Pl, Sr…), como estava usando, quando estava usando, para quê estava usando, qual a qualidade de prompt utilizada e, sobretudo, quantos prompts foram utilizados. Digo isso, pois um dos vídeos que vi na época foi do Augusto Galego sobre esse medo dos devs, e ele trazia esse ponto da relação entre quantidade de prompts e o quanto gastaria pra fazer na unha.

Nesse processo, foi solicitado alguns feedbacks, e acredito que muitos mascaravam um limite, que é claro, dessas IAs que auxiliam na codificação, fora a elaboração de estatística sem ter um cuidado com o que se diz. Ninguém é bobo, todos nós somos adultos e vivemos em um mundo capitalista; no mundo do trabalho, somos divididos por níveis, e cada um toca a banda como deve tocar. Digo isso pois, você fornecer dados como: reduziu X%, aumentou X%, etc, etc, etc, é o que faz brilhar os olhos dos cabeça branca (quem tem dim dim de verdade). Essas métricas, segundo o breve curso que fiz de UX, condiziam mais com as famosas “métricas da vaidade”.

Projeto Gemini

Bão, chegamos ao ponto que eu queria chegar. Antes de qualquer coisa, acima eu só expûs o que eu senti e acreditava para aquele momento, inclusive em conversas que tive no privado com colegas e em reuniões conjuntas. Não se trata de nada além de perceber o óbvio em nossas relações de trabalho, como empregador e empregado.

Indo pro que interessa. Estive em um projeto posterior para servir de case para a área, onde deveria utilizar IA de ponta-a-ponta - a ideia é interessante, se você agora pretende fazer um benchmark agressivo para saber os limites internos de onde a IA pode ir de fato. A princípio, era um sistema legado, que tínhamos já alguns problemas, e miramos nele por conta de uma simplicidade de lógica de negócio.

Não vou trazer aqui o passo-a-passo desse projeto, pois trata-se de algo mais interno, e inclusive foi gerado apresentação para contar um pouco de como foi o processo (mas, claro, seguindo o rito corporativo). O que eu queria trazer aqui são os efeitos de como conduzi esse processo (claro, influenciado por uma necessidade de que eu não intervisse no código).

Já havia cerca de 1 mês que estava usando o Cursor para pequenas coisas, e seguia o rito normal de trabalho (como os Incas e os Astecas). Até que chegou esse projeto, e a lei era: não deve haver intervenção do DEV. Ou seja, eu iria apenas guiar a IA a construir tudo de ponta-a-ponta, testar, enviar bugs do terminal para a IA, e ela se resolver.

Ex_Machina

Esse período de duas semanas, eu tive um uso intenso de IA no dia-a-dia, basicamente o dia inteiro eu estava ali conversando com o Chat, usando o Claude Sonnet 4, e refazendo do zero o sistema legado escolhido. Quando foi gerado a primeira versão okayzinha, eu achei animal. E com isso fui ajustando layouts, resolvendos bugs, montando as funcionalidades - parecia coisa de outro mundo. Entretanto, cada vez mais notava um distanciamento meu em relação ao código. Em empresas de tecnologia se discute muito o ownership do produto que você trabalha, mas com essas IAs agora, como fica a questão?

Nesse período, também me aperfeiçoei um pouco em prompts, usava Gemini como auxiliar para gerar prompts para o Cursor, mas não programei uma linha de código sequer, absolutamente nada. Apenas validava as construções, se elas faziam sentido, pedia para refatorar de maneira X, mas sem programar.

Teve alguns momentos que me assustei pela facilidade: implementar em 15 minutos a tokenização de URLs para mascaramento de IDs, com testes já incluídos nos specs. Agora você me pergunta se eu sabia fazer isso na unha, vou ter que te falar que não.

É onde percebi o quanto de produtividade que ela trazia, era o quanto de burrice ía crescendo em mim. Sem perceber no avanço, de mais duas semanas, em 1 mês eu posso atestar que tenho uma queda relativa cognitiva no que diz respeito ao uso de IA (servi de experimento pelo menos). Incomodado com isso, calhou que uma Newsletter do Tem vaga pra Jr! enviou esse texto aqui:

O preço invisível do ChatGPT: estudo revela que uso constante pode reduzir sua criatividade

Esse artigo fala um pouco de como o uso intensivo das IAs podem afetar as nossas ativações neurais, e de como a longo prazo isso representa um perigo. Chegou ao ponto, de eu começar a internalizar que não sabia mais programar, que eu era uma farsa. E, de fato, todo aquele monte de código não era meu, não fui eu que pensei, encadeei, nada disso. E se der problema em produção? Entraremos na Engenharia Reversa para descobrir o problema e no que vai dar. Ou capaz, que entraremos na era do “vibe fix”, reúne um monte de log, dados, joga pra IA e deixa ela resolver (será que dará certo para contextos que tem inúmeras integrações e complexidade lógica?).

Fora isso, um tema pouco falado, todo mundo fala que você tem que aprender prompt, xyz, mas pouca gente fala do impacto em saúde mental que uso intensivo pode e deve estar gerando em desenvolvedores pelo mundo a fora. Essa pressão, cada vez maior, por resultados a todo custo, faz com que os devs abram mão de sua persona envolvida, para delegar para a IA, porque de fato ela entrega mais rápido, a questão é: entrega com qualidade?

Com o Cursor, e outras ferramentas de código, criou-se um frenesi da entrega a qualquer custo, lideranças levando que o time aumentou em mais de 150%, é um novo ápice do capitalismo no ramo da tecnologia. E juntamente disso, vemos o ápice da alienação do trabalhador - é, a gente só sente quando a água bate na bunda. Quando os maquinários chegaram nas linhas de produção, quem estava no âmbito administrativo não sentiu que seria substituído, até que surgiu o computador, planilhas, sistemas (e todo esse mercado criou o mercado de devs). Mas agora, a conta tá chegando pra gente que somos peões premium. Como lidar com tudo isso?

Matrix

Parabéns guerreiros e guerreiras, se tu chegou até aqui, depois de eu falar para um caralho, você só precisa clicar no link abaixo e mandar “EU QUERO” no comentário, que irei mandar os melhores prompts para salvar a sua vida, além de assinar minha newsletter semanal, e minha mentoria pela bagatela de 15 mil dól…..brinks.

Bom, diante disso, “o que eu faço Victor? não uso IA? uso IA?”. Bão, aqui é aquele momento do Morpheus com o Neo, você tem duas escolhas:

1 - Usar a IA como ferramenta

2 - Tornar-se gerente de IA

A escolha é sua. Eu estou falando de um lugar como desenvolvedor pleno, outros textos de devs mais novos e mais experientes pode ajudar dependendo de você que tá lendo. Eu, já tomei a segunda pílula, e eu trouxe no texto (acredito ter deixado bem claro) o quanto me fez mal.

Acredito que a gente precisa usar a IA como ferramenta, ela veio pra ajudar de fato, otimiza muita coisa, e tá bom. Como você pode usar? Acredito que já evitando prompts do tipo:

Preciso que você ajuste a view X, está vermelha, não branca
Preciso que você me ajude com esse bug aqui (aí vem um rajadão de trace do terminal)
Preciso que você crie uma rota que irá devolver o payload tal

Evitar esses prompts bobos (mas muito danosos) é importante, porque quando você menos ver, você já nem tá mais pensando direito, você só vai dando rajadão de linguagem natural e a IA vai se virando nos 30.

Outra coisa, evitar terceirizar trabalho. “Ai, mas o meu chefe tá cobrando de usar IA”. Irmão, tu vai usar a porra da IA, mas não terceirizando. No dashboard ele não vai ter o que tu inputou (se tiver também, qual o problema?). Então evita prompts que a IA gera troucentos códigos que tu não faz nem ideia do porque ele criou a disgrasa de um concern na aplicação, imbutido num service, pra chamar no controller.

Procure, em vez disso (e aqui não vou discutir prompt, então calma lá pedreiro de prompt), traga prompts que estimulem seu pensamento lógico cognitivo. Não recorra a IA primeiro, saia dessa porra de IA First. Primeiro tente pensar por você o problema, quais seriam as hipóteses, investigue. Isso não leva tanto tempo quanto a gente diz (nós devs adoramos aumentar como se as coisas fossem muito maiores do que são). Beleza, pensou? Agora, chegou num limite do que você raciocionou, aí é interessante com o apanhado de informações, perguntar para a IA se faz sentido, que caminhos e alternativas ela poderia te dar.

E com isso, evite que ela construa todo o código para ti de cabo a rabo (claro, há pedaços que são chatos de se fazer, que você pode pedir pra ela dar aquela forcinha). Mas você, jovem gafanhoto, dev jr, não faça isso, você mais do que ninguém nessa terra, tem que escrever cada linha, inclusive coisas repetitivas, para fixar o conhecimento da linguagem.

Em contextos que os códigos precisam de um pensamento mais complexo, em vez de pedir para a IA solucionar, opte por solicitar que ela te indique o caminho, qual seria o passo-a-passo, sem lhe fornecer código. Até para você considerar se aquilo faz sentido ou não.

Último ponto que queria trazer de como usar, é a etapa final do seu trabalho: a revisão. Após você pensar, seguir o passo-a-passo, etc, peça para ela revisar, se faz sentido com requisitos, histórias de usuários ou seja lá o que for que tenham te passado de especificação. Com isso, você usa ela para dar um carimbasso no seu trampo sem te emburrecer.

Dessa forma, nós enquanto devs, trabalhamos de maneira mais orgância e colaborativa com IA, conseguindo trazer satisfação pessoal no nosso dia-a-dia, tendo o famoso ownership do código (muito útil em WarRooms) e deixando nosso cérebro mais forte (porque aliás, ele é um músculo que requer treino constante para não perder o shape).

The Terminator

Bom, essa foi minha visão que eu queria passar, se você não concorda, deixa nos comentários, se concorda, também deixa a sua visão aí. Não quero bancar o paladino da IA, e falar o que tá certo e errado, é apenas minha experiência e minha visão, vai de você escolher e definir como quer usar as IAs, só tome cuidado para não cair na dependêncIA. Fé!

PS.: Esse texto não foi escrito e nem revisado por IA, conforme selo de qualidade abaixo.

Em tempo, vi ontem um vídeo sobre o outro lado da moeda do GPT, vale muito a pena ver esse vídeo da BBC: ChatGPT: o que você não vê.

[Resenha] Entendendo Algoritmos: Um guia ilustrado para programadores e outros curiosos - Aditya Y. Bhargava

Victor de Oliveira Marinho — Fri, 04 Jul 2025 01:05:32 +0000

Fala minha tropa, fazer uma resenha rápida aqui de uma leitura que tive recentemente, e também pra movimento esse blog que já tá enchendo de teia de aranha. Seguinte, desde alguns meses comecei a me aventurar na leitura técnica, qual gerou um primeiro artigo já publicado aqui no dev.to ([Resenha] Programando em Go - Caio Filipini), e terminando essa leitura decidi embarcar no livro Entendendo Algoritmos: Um guia ilustrado para programadores e outros curiosos do Aditya Y. Bhargava, apelidado por mim carinhosamente (e acho que por muita gente), livro dos ratinhos.

Esse livro é um tapa na cara de muito professor (inclusive na minha na época que dei aula) por conta da sua didática. Passei uma vida na escola sem entender logaritmo, e o cara em meia dúzia de frases conseguiu me explicar a parada. É algo surreal. O grande acerto do livro é uma linguagem muito simples (acerto forte da equipe de tradução também da Novatec), além dos desenhos do autor que vão criando imagens da sua explicação.

Inclusive, estava comentando com uma colega que cursa história sobre essa leitura, e até ela ficou interessada de tão bem que estava falando do livro.

Mas voltando ao livro do ratinhos, o autor traz alguns assuntos que julgo muito importante para programadores (independente de nível), e que muitas vezes esquecemos os conceitos ou talvez não conseguimos aprender mesmo com a faculdade.

Os 5 primeiros capítulos (que foram os que consegui compreender melhor e refiz os exemplos utilizando a linguagem Go), abordam assuntos essenciais, e versam até de nível básico a médio (não julgo tão difíceis assim). Os outros 5 são tópicos um pouco mais avançados (que inclusive terei de relê-los, pois não consegui ter tempo para aplicá-los em Go ou Ruby).

O grande acerto pra mim no primeiro capítulo foi ele explicar de forma muito simples sobre Notação Big O, é nesse capítulo que ele explica em poucas linhas logaritmo de um maneira magistral. Os 4 capítulos seguintes a esse abordam Ordenação e seleção, recursão, quicksort e tabelas hash - e o acerto grande é sempre trazer quando usar, como usar, para quê usar, e as notações Big O dos algoritmos.

Os outros 5 capítulos já abordam temas de uma complexidade maior, acredito inclusive que para você que deseja se aventurar, utilize materiais de apoio e leia sem muita pressa, até pegar a ideia do que é abordado (acho que assim teria aproveitado melhor, mas tá valendo para uma primeira leitura). Os assuntos versam sobre Pesquisa em largura, Algoritmo de Dijkstra, Algoritmos gulosos, Programação Dinâmica, K-vizinhos e mais uns 10 algoritmos mais complexos que não foram destrinchados. Dessa segunda parte, para mim o acerto foi ele trazer exemplos de aplicação dos algoritmos no mundo real, ou problemas conhecidos.

O livro como um todo é divertido, ainda mais pelas anedotas que ele usa para criar metáforas dos algoritmos, bem como o cuidado em sempre oferecer termos que sejam acessíveis a qualquer leitor. É um baita livro também de preparação para entrevistas técnicas onde a régua é um pouco mais crítica com relação a algoritmos (acredito que a primeira metade já cubra boa parte), sendo a segunda parte mais para cadeiras e empresas que atuam com sistemas de alta complexidade.

Sem me alongar mais que o necessário, acho que essa é a ideia geral. Um adendo da minha experiência com a leitura, é que para me apoiar em algumas dúvidas que tive, usei o novo pai dos burros, mais conhecido como Gemini, e com a gem de “Parceiro de programação” foi interessante ampliar um pouco o conteúdo devido a ele tentar explicar alguns trechos de código que ele mesmo gerava para exemplificar, bem como alguns exemplos de aplicação que eu solicitava. Tirando isso, essa resenha aqui é totalmente feita por uma Inteligência Humana, conforme selo abaixo.

[Resenha] Programando em Go - Caio Filipini

Victor de Oliveira Marinho — Thu, 08 May 2025 14:54:35 +0000

Terminei recentemente o livro “Programando em Go” do Caio Filipini, e gostaria de comentar sobre algumas coisas muito bacaninhas que pude aprender.

Eu já havia feito antes um curso da Udemy sobre Go, e foi até positiva a experiência, embora eu tenha achado algumas partes um pouco rasas, mas acredito que era premissa do curso, uma vez que a ideia era de ser um curso introdutório. Fora isso, tenho percebido que meu foco para cursos em vídeo online está quase zero, então pode ter sido mais culpa minha mesmo.

Pois bem, pesquisando por livros da linguagem encontrei esse do Caio e decidi me aventurar, depois de anos sem ler um livro técnico era um grande desafio em que eu me colacava. Claro que durante esses anos eu li inúmeros capítulos de livros técnicos, mas até então não tinha me proposto a ler de cabo a rabo - que é algo que tenho buscado mais recentemente para me aprofundar em alguns temas.

O livro se inicia com uma breve introdução, mas que já vai introduzindo elementos centrais da linguagem. Logo no segundo capítulo foi onde eu comecei a ficar envolvido com a leitura do livro, quando como se não fosse nada, após apresentar elementos de sintaxe básica, ele mostra a facilidade de implementação do quicksort em Go. Foi um dos capítulos que mais gostei.

Longe de ficar descrevendo cada capítulo, acho que o sucesso do livro se dá em trazer exemplos despretensiosos, para posteriormente ir destrinchando e explicando os novos elementos que vão surgindo nos códigos - como o que é feito entre o capítulo 3 (com exemplos de pilha inclusive) e 4/5 (onde se explica os elementos de maps, slices, arrays e tipos customizáveis que aparecem no capítulo anterior).

Gostei muito do capítulo sobre funções, onde pude aprofundar meus conhecimentos sobre funções de primeira classe, funções anônimas, closures e high-order functions. Junto disso, o capítulo sobre Goroutines foi importante para expandir o que aprendi no curso da Udemy, quando ele aborda a questão de channels, buffer, select, além de sincronização - coisas que até então não tinha visto, e isso ampliou muito a minha visão de como tirar proveito disso em projetos que já atuei.

Por fim, os capítulos finais trabalha em cima de um exemplo que cai muito em entrevista de devs, que é um encurtador de URLs, e foi muito bacana como a cada capítulo o projeto vai se desenvolvendo, de como o autor apresenta os problemas que vão surgindo em termos de código, explicando as bibliotecas envolvidas, e fornecendo alternativas que podemos tomar para solucionar esses problemas. O ponto alto disso é o capítulo sobre a refatoração, que foi muito interessante ter esse acompanhamento com o autor de como pensar refatoração usando o que Go tem para nos oferecer - claro que só com a experiência em projetos reais para ir pegando a malícia da refatoração.

Enfim, um artigo curtinho, só pra tá vivo nessa plataforma, e de uma leitura muito interessante (e importante) para minha carreira, vale muito a leitura para quem tem interesse em embarcar nesse universo de Go. Agora a ideia é desenvolver um CLI para botar em prática, sem ajuda de livro e do autor, os conhecimentos aprendidos e quem sabe logo menos volto com um artigo sobre como desenvolver esse CLI básico em Go. Até a próxima!

Minha experiência na 2ª rinha de backend com Ruby + Sinatra

Victor de Oliveira Marinho — Tue, 27 Feb 2024 15:08:09 +0000

Introdução

Fala minha tropa, hoje venho aqui contar um pouco da minha experência na 2ª edição da rinha de backend. Ano passado acabei não conseguindo participar, devido ao prazo ter ficado um pouco apertado. Esse ano com o prazo mais largo, consegui fazer com folga minha versãozinha. Para conseguir submeter uma versão, pensei em utilizar o ruby com sinatra, para ver algo um pouco mais diferente - no trabalho acabo usando muito rails, dessa vez queria ver que outras possibilidades conseguiria fazer com ruby, só que de forma mais enxuta.

Inspirado em algumas lives do Leandro Proença, até pensei na alternativa de fazer com ruby puro, mas preferi ficar no seguro e fazer com sinatrinha que já tinha tido oportunidade de mexer num módulo extra do treinamento da Campus Code - tendo sido também com o Leandro.

Pois bem, decidido a stack, eu fiquei pensando no nome do projeto. Infelizmente é meu modus operandi (desde a época de escrever ensaios na faculdade de Letras). Peguei umas músicas do Frank Sinatra e escolhi My Way, sobretudo pelo trecho que mais parecia um meme do resultado final após rodar o Gatling:

O Processo

A partir disso, fiz um README boladão, e diferente do ano passado, esse ano decidi ir por baby steps. Ano passado, além de prazo apertado, eu fiquei muito ansioso com a infinidade de coisas que eu não tinha tanto conhecimento e que precisava - como o Nginx e Gatling. Isso acabou me travando. Dessa vez, me preocupei primeiro em construir as rotas, depois fui construir os serviços no docker, depois a partir do repositório agostinho do Leandro, pensei num adaptador de conexão com o banco junto com um pool de conexões. Trabalhei em cima das validações, em grande parte me ajudou a ler os testes do Gatling, para atender aos requisitos.

Terminado a parte de desenvolvimento em si, fui criar o docker-compose baseado no repositório da rinha e fui alinhando conforme zapeava entre os repositórios. Conseguindo rodar o docker-compose, parti para instalar o JDK e baixar o Gatling para rodar os testes. Feito isso, rodei os testes do Gatling e aí começa a saga.

Bugs e mais bugs…

Ao rodar o Gatling as primeiras vezes, já estourava uns 70% as validações, tive que rever a lógica. Mas o que eu ainda não tinha percebido é que era no fluxo de requisições concorrentes que estourava os erros. Visto isso, foi quando entre inúmeros tweets da rinha, vi a importância do uso das transactions. Esse foi o primeiro item que aprendi algo, e que me ajudou a sanar grande parte dos erros.

Acompanhando via Portainer, eu comecei a observar alguns erros do Nginx, então para entender o que eu estava configurando de errado, fui entender o que cada linha do Nginx significava, e com isso consegui ter maior consciência do que estava fazendo de fato. Uma abordagem que eu insistentemente tinha era de aumentar no talo as worker_connections, cheguei a colocar 60000. Não percebia que esse aumento em si não adiantava, já que minhas APIs não conseguiam atender esse volume.

Após entender isso, comecei a rever as threads da aplicação e trabalhei um bom tempo em entender como orquestrar isso. Comecei a subir o puma com workers + threads, e comecei a ter alguns resultados positivos - estava usando 3 workers + 5 threads e com isso conseguia atender um pouco mais da enxurrada de requisições. Mas ainda assim após algum tempo começava a derrubar as connections do Nginx, e estourava inúmeros erros 502 e 500.

Foi então que o Leandro, outra vez, me mandou uma thread do twitter em que explicou os aprendizados dele com a rinha anterior, thread essa que deixo abaixo:

Alguns ajustes no NGINX e PostgreSQL e minha versão Ruby ganha um aumento de tput que garante 46k inserts.

"Ajuste pra cima", eles dizem.

Não. É pra baixo.
As queries são rápidas, ñ preciso floodar a stack toda com mtos requests à espera: latência gera custo.

Detalhes na 🧵 pic.twitter.com/cAj8Ew3XWu
— leandro • nsp (@leandronsp) September 6, 2023

O que me ajudou foi entender que para conseguir atender de forma efetiva eu deveria fechar a torneira no Nginx e nas threads e workers das APIs, e focar em tunar as respostas do BD. Retornei a aplicação para apenas 5 threads, no Nginx limitei à 256 worker_connections e fui entender como funcionava a pool de conexões. Foi ali que demorei grande parte. Quando retornava à essas configurações mais sóbrias, acontecia de muito cedo dropar as conexões do Nginx e das APIs, não entendia porque havia um gargalo no banco de dados. Depois de muito conversar e estudar documentações, não chegava a nenhuma conclusão. No desespero, fui ver como trabalhar com I/O assíncrono, vi alguns web servers (como o falcon, thin etc), mas nada funcionava direito. Entre bugs e mais bugs desfiz tudo e fui ler a documentação da gem Connection Pool.

Bug com a gem Connection Pool

Não sei por qual motivo, estava tendo problemas com o método checkout do pool de conexões. Aparentemente, ele após o uso não estava realizando a devolução da conexão pro pool, fazendo com que a cada transaction fosse criada uma nova conexão com o banco. Isso explicava o gargalo, mas como contornar? Bom, havia o método checkin, com isso, criei um método de abertura e de fechamento da conexão e isso começou a surtir efeito.

Porém, o melhor foi utilizar o método with - por indicação do Leandro. Indo na documentação, inclusive, eles falam que é melhor o método with em vez do checkout devido a instabilidades que poderiam ocorrer (às vezes é só ler a documentação né? kkkk).

Enfim, com o método ajustado, consegui atender a maioria das requests, mas ainda sim tinha erros. Os últimos ajustes foi configurar no PostgreSQL 30 max_connections e 30 io_concurrency para atender o pool de 15 conexões das duas APIs. Cada API tinha 5 threadzinhas e com folga conseguiu atender as conexões repassadas pelo Nginx. Os resultados estão abaixo de uma das execuções:

Considerações finais

Lição aprendida é que nem sempre escalar recursos, colocar mais power de máquina, pods, réplicas etc é um caminho indicado. Às vezes é mais produtivo identificar onde é o gargalo e como otimizar e, sobretudo, fechar a torneira pode ser mais eficaz em termos de performance (e também de grana em cenários reais de empresas).

Bom, dos vários temas que pude aprender nessa rinha - seja do uso de transactions, pool de conexões, threads, concorrência - foi muito importante também esse compartilhamento dos problemas e das ajudas dos colegas (seja pessoalmente, seja via tweets compartilhando as soluções). A possibilidade de ver várias das submissões e as soluções que cada um fazia me ajudou muito no processo também.

Só tenho a agradecer ao Francisco Zanfranceschi por ter criado a rinha e ter fornecido essa oportunidade de tanto aprendizado. Agradecer também ao Leandro Proença pela ajuda e por todos os conteúdos que ele tem produzido. Agora vamos aguardar a live do dia 14/03 para ver em que posição fiquei, e já aguardo ansiosamente a próxima edição da rinha.

Pra você que se interessou, ainda tem tempo pra fazer a sua submissão, até o dia 10/03, o link do repo é esse aqui: https://github.com/zanfranceschi/rinha-de-backend-2024-q1

Link da minha versão Ruby + Sinatra pra Ruby: https://github.com/v1t4o/my_way

Usando a gem Foreman

Victor de Oliveira Marinho — Sun, 23 Jul 2023 15:02:45 +0000

Fala minha tropa, suavidade? No último artiguinho, no fim dele eu comentei sobre a gem Foreman, pra não ficar no ar, resolvi escrever esse artiguinho curto sobre como utilizar essa gem que pode ser um adianto em muitos projetos para desenvolvimento local.

Sobre o Foreman

O Foreman é uma gem que facilita a nossa vida quando se trata de vários processos de uma aplicação que necessitam ser executados. Um exemplo, aqui na firma tem um legadão que ele tem uma série de processos para além do rails s. Quando tentei executar a aplicação pela primeira vez, era meio cabaço, aí abri um três terminais só pra fazer funcionar. Só que aí, ela integrava com outro legadão que tinha outros 2 processos, e aí lá vai eu abrir mais dois terminais.

Bom, se eu tivesse usado o Foreman, teria usado apenas um terminal pra primeira app, e outro terminal pra segunda app, uma vez que eu consigo colocar dentro do arquivo de config do Foreman os vários serviços que necessito que estejam em execução apenas uma vez, sem precisar abrir vários terminais.

Usando a gem

Primeiro passo, é você adicionar no seu projeto a gem do foreman

gem 'foreman'

Depois disso, rode o comandinho mais famoso dos rubistas:

bundle install

Aí na raiz do seu projeto, você precisará criar um arquivinho chamado Procfile, onde você pode botar os processos que necessite, por exemplo:

web:    rails s -p 3001
worker: bundle exec sidekiq
service: bin/./bunny_consumer.rb

Veja que sem o Foreman, eu teria que abrir três sessões do terminal para conseguir subir por completo minha app e seus serviços; já com a gem, para executar esses três carinhas basta no terminal eu rodar o seguinte comando pra mágica acontecer:

foreman start

A carinha dele quando está em execução:

Conclusões

O Foreman ajuda muito a gente no ambiente de desenvolvimento, e acredito que seja uma mão na roda para quando chega devs novos no time, sobretudo os de nível júnior. Além disso, acho massa a questão do Procfile por funcionar meio como uma documentação do que é necessário pra app funcionar. Já peguei legados que tinha que ser meio Mãe Diná pra descobrir o que precisava rodar para aplicação funcionar. O Foreman também tem algumas paradas maneiras de exportação em produção, que ele cria uns serviços no /etc/init que pode ser uma mão na roda para gerenciar os serviços das aplicações no servidor. Ele também tem uma breve explicação sobre a questão de concorrência que pode ocorrer. Além dele, tem outros carinhas também, eu cheguei a mexer um cadinho com o Overmind, que é em Golang, e achei bem massa também. Mas me conta aí, que outro gerenciador de processos você conhece?

Fontes

https://github.com/ddollar/foreman

http://blog.daviddollar.org/2011/05/06/introducing-foreman.html

Aplicações Ruby On Rails com RabbitMQ: uma breve discussão sobre monolitos, microsserviços e mensageria

Victor de Oliveira Marinho — Sat, 22 Jul 2023 00:01:59 +0000

Fala tropinha, tudo certo? Bom, mês passado fiz uma palestrinha técnica na firma, e me propus a falar um cadinho sobre RabbitMQ e a arquitetura de microsserviços, envolvendo nesse caso aplicações Ruby On Rails. Meu intuito aqui não é fazer uma super indagação sobre o tema, nem me aprofundar muito na implementação, mas talvez tentar fornecer um feijão com arroz sobre o tema, sobretudo pra quem nunca viu nada sobre.

O que é RabbitMQ? O que é mensageria?

Tomo como ponto de partida a tentativa de explicar o que é o RabbitMQ, bom, ele é um software escrito em Erlang e foi lançado pela Rabbit Technologies em 2007. Ele é um software de mensageria e implementa o protocolo AMQP (Advanced Message Queuing Protocol). Guarda essa sigla pois ela será importante quando formos implementar nas apps em rubyzin. Um outro conceito importante é que o RabbitMQ é um Message Broker, o que isso quer dizer? Que ele é um servidor que apenas recebe as mensagens e alguém consome dele, não há um processamento via RabbitMQ. Isso é importante frizar pois no início podemos acabar confundindo o RabbitMQ com um Resque/Sidekiq da vida.

Sabendo disso, agora o interessante é pensarmos em que tipo de arquitetura se encaixa a aplicação do RabbitMQ, dito isto, vou entrar em uma discussão breve sobre o que seria a arquitetura monolítica e a de microsserviços.

Arquitetura Monolítica

A arquitetura monolítica trata-se de um sistema que contempla vários módulos e funcionalidades. Se pensarmos em uma API monolítica, se trataria de uma API com várias rotas, que podem englobar pedidos, compras, produtos, clientes etc, tudo em um mesmo carinha. Isso acaba evidenciando que sistemas monolíticos envolvem processos altamente acoplados, executando como um único serviço. Além disso, em caso de pico de demanda, toda arquitetura que envolve a aplicação em si deverá ser escalada.

Seguindo alguns artigos que li, que deixo no final, apresento aqui os benefícios e desafios que a arquitetura monolítica apresenta

Benefícios

Implantação através da cópia do pacote
Compartilhamento de memória, espaço e recursos
Desempenho em alguns casos, por conter em si todos os módulos

Desafios

Alta complexidade ao longo do tempo
Alto acoplamento
Processo demorado de desenvolvimento e deploy
Dificuldades na integração CI/CD
Difícil escalonamento
Uma falha derruba o sistema

Arquitetura de Microsserviços

Nesse tipo de arquitetura, lembra aquela APIzona que a gente conversou mais a cima, então, imagina que vamos quebrar cada setorzinho em um serviço, ou seja, em vez de uma API que contempla todos aqueles módulos, teremos um carinha pra processar pedido, outro pra processar produto, outro para processar cliente etc, é como se cada microsserviço fosse um miniaplicativo que tem a própria arquitetura e lógica de negócios, com seu próprio banco de dados - o que garante um acoplamento flexível.

Novamente, a partir de alguns artigos que li, trago aqui um resumo dos benefícios e desafios da arquitetura de microsserviços.

Benefícios

Mais rápido desenvolver, entender e manter
Autonomia através do isolamento dos ciclos de vida
Aplicativo poliglota
Ciclos de lançamento independentes
Escalonamento individual

Desafios

Complexidade devido a ser distribuído
Problema com transações distribuídas
Teste abrangente torna-se mais complexo
Implantação mais complexa
Sobrecarga de operações
Latência introduzida no tempo de resposta
Banco de dados por serviço
Instrumentar e monitorar ambiente
Cada serviço tem sua regra de acesso
Comunicação assíncrona

Exemplo de Uso

Tendo isso em mente, vamos focar em um case de exemplo que eu bolei para a minha apresentação. Tentei idealizar uma aplicação legada em que utilizasse processos síncronos com jobs via Sidekiq/Resque, a ideia era mais ou menos essa aqui:

Veja que ali temos uma aplicação, que embora seja focada em distribuir as Notificações, ela acaba por ficar responsável por vários tipos de notificações: email, sms, push. Nesse caso, minha ideia, era pegar um desses tipos e quebrar em um serviço separado, suponhamos que a gama de emails disparados fosse muito alta. Na arquitetura em monolito, para escalar eu teria que aumentar o hardware de servidor ou de rede, ou até pensar na questão do banco de dados. Agora em microsserviço, veja como ficaria o exemplo:

Nesse caso, veja que eu tenho um Service Notifications responsável apenas pelo disparo dos e-mails e mesmo que eu tivesse um aumento na demanda por disparo de e-mails, não necessitaria escalar meu monolito por inteiro, agora eu escalo somente o meu microsserviço. Eu acho essa forma de pensar e partir pros microsserviços interessante. Geralmente, por hype, as pessoas tem vendido microsserviços como bala de prata para problemas de performance dentro das empresas, mas acredito que seja mais adequado pensar a arquitetura como uma solução se o contexto apresentar as condições necessárias.

Essa forma mais cautelosa, fará que você apenas escale o que de fato necessitar de um legado, e ainda o mantiver ativo enquanto seu ciclo de vida permitir. Sair de um legado para uma arquitetura de microsserviços por inteiro, pode representar um desperdício de dinheiro em infraestrutura, uma vez que você pode ter segmentado vários módulos em microsserviços que não demandam tanto, representando máquinas ociosas, espaço em banco de dados alocado sem uso, entre outros impactos desnecessários. Enfim, o papo tá bom, mas como funciona o processo? Vamos lá, dividi em dois momentos a implementação em aplicações Ruby On Rails. Primeiro ponto é o Publisher e o segundo o Consumer.

Implementação

Publisher

Primeira coisa que fiz nesse exemplo acima, foi na aplicação Notifications incluir a gem do Bunny no Gemfile.

gem 'bunny'

Após isso, rode o comando:

bundle install

O segundo passo, é criarmos na pasta lib o arquivo bunny_client.rb com o seguinte conteúdo:

# frozen_string_literal: true

class BunnyClient
    class << self

        # Cria a conexão com o RabbitMQ
        def connect!
            # Utiliza a variável CLOUDAMQP_URL para conectar no host indicado
            @connection = Bunny.new(ENV['CLOUDAMQP_URL'])
            @connection.start
            # Cria o canal
            @channel = @connection.create_channel
            # Cria nossa fila para onde vamos publicar as mensagens
            @fan_out = @channel.fanout('notifications_email.out')
            @connected = true
        end

        # Publica as mensagens na fila, informando a origem da app
        def push(payload)
            connect! unless @connected
            @fan_out.publish(payload, { app_id: 'notifications_email' })

            true
        end
    end
end

Crie um arquivo em config/initializers chamado bunny.rb com o seguinte conteúdo:

require 'bunny'
require 'bunny_client'

No seu arquivo .env, não esqueça de adicionar a seguinte variável de ambiente:

CLOUDAMQP_URL: amqp://localhost:5672

Dessa forma, dentro do fluxo da sua app, vamos supor que você tenha um model que após salvar localmente numa base de dados, você queira encaminhar para uma fila onde o microsserviço irá processar, você pode fazer algo como:

class Notification < ApplicationRecord
    after_save :publish!

    def publish!
        message = {
            email: email,
            subject: subject,
            content: content    
        }

        # Aqui um exemplo, estamos utilizando o método do client que criamos acima
        BunnyClient.push(message.to_json)
    end
end

Para fazer funcionar na sua app, basta rodar o bom e velho rails s e bater na rota de criação por exemplo, para ver o funcionamento da publicação na fila.

Consumer

No microsserviço, seguimos o mesmos passos iniciais que é incluir a gem do Bunny no Gemfile.

gem 'bunny'

Após isso, rode o comando:

bundle install

No seu arquivo .env, não esqueça de adicionar a seguinte variável de ambiente:

CLOUDAMQP_URL: amqp://localhost:5672

Após isso, precisamos criar um arquivo na pasta bin chamado bunny_consumer.rb com o seguinte conteúdo:

#!/usr/bin/env ruby

require File.expand_path('../config/environment', __dir__)

# Cria a conexão com o RabbitMQ
connection = Bunny.new(ENV['CLOUDAMQP_URL'])
connection.start
channel = connection.create_channel

# Cria a fila para processamento
queue = channel.queue('notifications_email.in', durable: true, auto_delete: false)

puts "\nStarting consumer!"

# Captura da fila out (que usamos na outra app) as mensagens existentes
fanout_name = 'notifications_email.out'
queue.bind(channel.exchange(fanout_name, type: 'fanout'))
puts "[consumer] #{queue.name} binds to #{fanout_name}"

# Inicia o processamento da mensagem
# Nesse nosso exemplo aqui, vamos utilizar o Modelo de Email, para o qual
# Vamos salvar local para ter um histórico do envio
# Mas poderia se tratar também de usar diretamente o mailer
queue.subscribe do |d_info, properties, payload|
    Email.create_and_send(JSON.parse(payload))
    puts "[consumer] #{queue.name} received #{properties[:type]}, from #{properties[:app_id]}: #{payload}\n"
end

begin
    while true
        sleep(3)
    end
rescue Interrupt
    connection.close
    puts "\nShutting down gracefully."
    exit
end

Rode o seguinte comando no terminal, para tornar esse arquivo executável:

sudo chmod 755 bin/bunny_consumer.rb

Lá no nosso model de Email, a implementação da chamada a partir do BunnyConsumer ficaria dessa forma:

class Email < ApplicationRecord
  def self.create_and_send(payload)
    message = new(
      email: payload['email'],
      subject: payload['subject'],
      content: payload['content']
    )
    message.save!
    send_message(message) 
  end

  def self.send_message(message)
    MessageMailer.with(message: message).send_email.deliver_now
  end
end

Veja que aqui eu consigo criar localmente o e-mail e logo após faço o envio do e-mail. Observe que esse microsserviço ele fica responsável apenas por processar isto, não há requisição ou qualquer outra coisa.

Por fim, para fazer funcionar esse carinha, basta rodar o comandinho:

bin/./bunny_consumer.rb

Claro, você pode criar rotas para consultar esses dados no microsserviço se quiser, em vez da aplicação legada, basta criar um Procfile com ambos os comandos abaixo, e utilizar a gem do Foreman:

web: bin/rails s -p 5002
service: bin/./bunny_consumer.rb

Conclusões

Bom, espero que esse artiguinho ajude a introduzir a vocês um pouquinho dos conceitos de monolitos, microsserviços e mensageria com RabbitMQ. Volto a bater na tecla de que microsserviços não é bala de prata, é preciso considerar os contextos e necessidades. Entretanto, pode ser uma arquitetura que seja um trunfo em contextos de serviços que tenham uma demanda crescente e que vira e mexe necessitam de algum tipo de escalabilidade.

Fontes:

https://aws.amazon.com/pt/microservices/

https://cloud.google.com/learn/what-is-microservices-architecture?hl=pt-br

https://medium.com/@marcelomg21/arquitetura-de-microsserviços-bc38d03fbf64

https://github.com/ruby-amqp/bunny

https://world.hey.com/dhh/how-to-recover-from-microservices-ce3803cc

Implementação do Flipper para controle de features

Victor de Oliveira Marinho — Fri, 02 Jun 2023 15:19:42 +0000

Fala tropinha, hoje venho trazer uma gemzinha braba também, que pode ajudar no dia-a-dia. A gem em questão é a Flipper, e ela é uma gem que fornece features flags que pode auxiliar você à controlar o acesso à determinadas features ainda em desenvolvimento.

Instalação e Configuração

Para instalação, basta adicionar no seu Gemfile a gem flipper e a flipper-ui

gem 'flipper'
gem 'flipper-ui'

Além dessas duas, ainda devemos adicionar uma outra gem adapter, para termos onde guardar nossas flags. Vou utilizar aqui a do Redis, que tenho visto ser mais comum, mas pode ser que na sua empresa eles acabem optando por salvar no BD. Na documentação oficial, tem os adaptadores que conectam no banco e cada um tem sua doczinha bonitinha.

gem 'flipper-redis'

Depois disso, basta rodar o bundle. Na pasta config/initializers crie o arquivo flipper.rb com o seguinte conteúdo para configurarmos o Redis como o local onde será guardado as features flags:

require 'flipper/adapters/redis'

Flipper.configure do |config|
  config.adapter { Flipper::Adapters::Redis.new(Redis.new) }
end

Para configurar o acesso à UI do Flipper, você precisa fazer o processo de montagem da rota. Entre no arquivo routes.rb, e adicione a seguinte linha:

mount Flipper::UI.app(Flipper) => '/flipper'

Essa rota, se for necessário (e quase sempre é kkkk), tem como você protegê-la, na documentação tem algumas dicas. Não vou avançar muito aqui, pois depende um pouco de como cada empresa em que a gente trampa lida com isso.

Interface para criação das features flags

Após subir sua aplicação, tente bater na rota /flipper e irá aparecer essa telinha:

Para adicionar alguma feature, basta clicar em Add Feature, e aparecerá a seguinte telinha:

Escolha um nome para a sua feature flag, em breve mostrarei como implementar isso no código. Ao prosseguir, aparece uma tela com algumas opções que temos em cada feature flag criada:

O Flipper é uma mão na roda pra algumas coisas do dia-a-dia. Por exemplo, temos ali a opção de actors. Digamos que há um determinado fluxo da sua aplicação que tem gerado alguns erros para alguns clientes. Podemos usar essa opção para indicar os IDs desses clientes, e aplicar apenas para eles a solução de contorno. Podemos fazer isso também habilitando por grupos, como mostrado na tela acima.

Um outro cenário interessante de aplicação. Digamos que foi criado algum novo serviço para solucionar uma consulta, mas antes de fazer a troca em produção, você pensa em ir testando aos poucos. Tem como você habilitar uma certa porcentagem de usuários ou por tempo, e isso faz com que você consiga ir escalando essa quantidade, até perceber que pode mudar o fluxo na aplicação sem trazer grandes impactos aos clientes.

Tá, mas até agora só falei do Flipper, como isso se aplica no código? Bom, é bem tranquilo. Criei uma aplicação rails e gerei um scaffold para Car. Vou mostrar como isso poderia ser utilizado no controller, na parte de edit, e na view com o botão de deletar.

Uso dentro do código e testes

Bom, estamos aqui no cars_controller.rb, e veja que é bem tranquilo para utilizar o Flipper.

def edit
    render :show unless Flipper.enabled?(:edit)
end

No método de edit, eu coloquei uma verificação para que caso a feature flag :edit não esteja habilitada, eu renderize o show do car. Caso esteja habilitada, ela prosseguirá o fluxo normal e com isso conseguirei editar o item.

Na view não é muito diferente esse processo, no arquivo show.html.erb, fiz algo bem parecido, envolvendo o botão de destroy em um if que só vai exibir se a feature flag estiver habilitada:

<% if Flipper.enabled?(:destroy)%>
    <%= button_to "Destroy this car", @car, method: :delete %>
<% end %>

Um cuidado importante que se deve ter ao utilizar features flags do Flipper, é que ao deletar, ela deixa de existir em todo o sistema. Com isso, lembre-se de tirar a verificação da feature flag dos trechos de códigos onde você acabou usando por algum momento as flags.

E como ficaria ao criarmos testes? Bom, o processo é bem semelhante. Eu consigo, dentro dos testes, desabilitar ou habilitar alguma flag usando os métodos enable ou disable, e com isso simular os fluxos, veja abaixo um exemplo de teste:

require 'rails_helper'

RSpec.describe "Feature Flags" do
 context "destroy a car" do
  it 'when feature flag is disabled' do
    Flipper.disable(:destroy)
    Car.create!(make: "Ford", model: "Ká", color: "Red", year: "2023", price: "R$ 30.000,00")
    visit cars_path
    click_on "Show this car"
    expect(page).not_to have_button("Destroy this car")
  end

  it 'when feature flag is enabled' do
    Flipper.enable(:destroy)
    Car.create!(make: "Ford", model: "Ká", color: "Red", year: "2023", price: "R$ 30.000,00")
    visit cars_path
    click_on "Show this car"
    expect(page).to have_button("Destroy this car")
  end
 end
end

Considerações Finais

Bom, meu intuito era apresentar essa ferramenta, que pode ser muito útil no nosso dia-a-dia. Um uso interessante que notamos aqui na minha empresa atual, é de que em soluções críticas, que podem gerar impactos ao cliente, talvez testar a solução colocando uma feature flag seja mais interessante no ambiente de produção, uma vez que evita o processo de rollback.

Além disso, com alguns controles do Flipper, é possível ir escalando a quantidade de clientes que podem ter acesso ou não à determinada feature, isso evita um impacto negativo no lançamento de uma nova feature. Observamos uma oportunidade interessante de usá-la também para reduzir quantidade de rollbacks e até como solução de contorno rápida para alguns problemas com prioridade alta.

Fontes

https://github.com/jnunemaker/flipper

Flipper Documentation

Usando a gem httplog para uma melhor análise dos logs

Victor de Oliveira Marinho — Wed, 19 Apr 2023 12:01:16 +0000

Fala tropinha, tudo bom? Venho trazer nesse artiguinho minúsculo, um pouquinho sobre uma gem que tenho usado no dia-a-dia do trabalho para fazer alguns mapeamentos e documentação de aplicações legadas. A gem em questão é a httplog, e achei ela bem interessante por conseguir me exibir em detalhes os dados das requisições que são feitas para as mais diversas aplicações.

Para configurar ela, o primeiro passo é adicionar a gem no Gemfile:

gem 'httplog'

Depois disso basta rodar o seguinte comando no terminal, dentro da sua pasta do projeto rails:

bundle install

O último passo é você criar dentro da pasta config/initializers o arquivo httplog.rb:

HttpLog.configure do |config|

  # Enable or disable all logging
  config.enabled = true

  # You can assign a different logger or method to call on that logger
  config.logger = Logger.new($stdout)
  config.logger_method = :log

  # I really wouldn't change this...
  config.severity = Logger::Severity::DEBUG

  # Tweak which parts of the HTTP cycle to log...
  config.log_connect   = true
  config.log_request   = true
  config.log_headers   = false
  config.log_data      = true
  config.log_status    = true
  config.log_response  = true
  config.log_benchmark = true

  # ...or log all request as a single line by setting this to `true`
  config.compact_log = false

  # You can also log in JSON format
  config.json_log = false

  # Prettify the output - see below
  config.color = false

  # Limit logging based on URL patterns
  config.url_whitelist_pattern = nil
  config.url_blacklist_pattern = nil

  # Mask sensitive information in request and response JSON data.
  # Enable global JSON masking by setting the parameter to `/.*/`
  config.url_masked_body_pattern = nil

  # You can specify any custom JSON serializer that implements `load` and `dump` class methods
  # to parse JSON responses
  config.json_parser = JSON

  # When using graylog, you can supply a formatter here - see below for details
  config.graylog_formatter = nil

  # Mask the values of sensitive request parameters
  config.filter_parameters = %w[password]

  # Customize the prefix with a proc or lambda
  config.prefix = ->{ "[httplog] #{Time.now} " }
end

Prontinho, assim quando você subir a aplicação, ele carrega o httplog e você consegue ter uma visão um pouquinho melhor de cada request feita para outras aplicações. Tem como ainda naquele arquivinho que criamos nos initializers ajustar o texto exibido, cor, filtrar parâmetros, entre outros itens que estão disponíveis no arquivo de configuração.

Caso você prefira não ficar vendo os logs pelo terminal, tem como ajustar para ele salvar em um arquivo de log, basta alterar a linha 7 do arquivo httplog.rb para:

config.logger = Logger.new('log/development.log')

Bom, por hoje é só, espero ter ajudado. Se você conhecer alguma outra gem que ajuda a ter uma melhor visão dos logs, comenta aí abaixo. Tmj!

Link da gem: https://github.com/trusche/httplog

Uso do Portainer para administração de contêineres do Docker

Victor de Oliveira Marinho — Fri, 17 Mar 2023 14:07:51 +0000

Fala minha tropa, tranquilidade? Nesse primeiro artigo aqui na dev.to eu quero falar um pouquinho sobre o uso do Portainer para gerenciamento de contêineres do Docker. Essa dica foi um parceiro do meu trampo que me passou, vou compartilhar com geral pra ajudar no dia-a-dia.

Usar o Docker só via terminal é massa, mas devido à correria do dia-a-dia às vezes vale a pena ter disponível algo pra gerenciar de forma mais fácil. Dessa forma, o Portainer é uma boa solução.

Se você ainda não tem o dockerzão instalado na sua máquina, tem esse tutorial brabo de Docker na Digital Ocean.

Pois bem, para tê-lo na sua máquina, o primeiro passo é você rodar esse comando para criar um volume para os dados do Portainer:

docker volume create portainer_data

Depois disso, tu precisa rodar o seguinte comando para baixar a imagem do Portainer e mapear os volumes para gerenciar o Docker:

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Para saber o que cada coisa significa, segue abaixo uma listinha com a descrição das paradas:

-d - essa opção faz com que o container funcione em background
-p - essa opção faz com que seja mapeada a porta 9443 para acesso via navegador na porta default do Portainer (9443) [segundo documentação]. Vale lembrar que você pode alterar essa porta, poderíamos ter utilizado 9000:9000, por exemplo.
--name - é o nome do container a ser criado
--restart=always - isso faz com que o container reinicie automaticamente
-v /var/run/docker.sock:/var/run/docker.sock - mapeia o volume do container para gerenciamento dos outros contêineres do ambiente Docker
-v portainer_data:/data - mapeia o volume referente aos dados do Portainer que criamos antes
portainer/portainer-ce:latest - indica qual imagem do Portainer será utilizada

Bom, depois dos comandos terem rodados, é só você acessar via navegador na URL: https://localhost:9443

No primeiro acesso, ele pedirá para você cadastrar uma senha pro admin. Basta preencher bonitinho e concluir pra ter acesso ao painelzinho do Portainer.

No Portainer há várias funcionalidades, você tem uma dashboard informando os ambientes disponíveis:

Você também tem uma dashboard por ambiente dos contêineres, volumes, imagens, redes criadas:

Na listagem dos contêineres, você tem a opção também de visualizar os status, parar ou iniciar um container específico. Há também como adicionar novos contêineres por aqui.

Clicando em um deles, você consegue visualizar mais informações, como operações dos contêineres, status, acesso à logs e terminal.

Bom, basicamente é isso, o intuito aqui era mais apresentar a ferramenta, que tem salvado muito no dia-a-dia do meu trampo.

Fontes

https://docs.portainer.io/start/install-ce/server/docker/linux