Zipline Backtesting Engine

Olá, daqui é o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 1 de 7. A maioria dos algoritmos de trading parece brilhante no papel, mas perde dinheiro instantaneamente nos mercados reais. O suspeito do costume é o look-ahead bias. O teu código espreita acidentalmente o preço de fecho de amanhã para fazer a trade de hoje. A Event-Driven Backtesting Engine do Zipline 3.0 impede isto completamente. Num backtester vetorizado standard, tu carregas um dataframe enorme de preços históricos e aplicas operações de pandas em toda a timeline de uma só vez. Isto é rápido, mas tem falhas profundas para simular a realidade. Podes facilmente escrever lógica que dispara uma buy order hoje, com base numa rolling average que inclui acidentalmente dados da próxima semana. O Zipline elimina essa possibilidade, forçando-te a usar uma stream estritamente event-driven. Ele simula uma bolsa de valores real. Quando corres um backtest, a engine age como um timekeeper rigoroso. Ela avança pela história, tick a tick, ou minuto a minuto. A cada passo, dispara um evento. O teu código recebe apenas os dados disponíveis naquele microssegundo preciso. Inspecionas o state atual, colocas as tuas ordens e depois esperas que a engine avance o relógio. Não podes olhar para a frente, porque ainda não foi feito o stream dos dados futuros para a engine. Esta arquitetura garante que o teu backtest reflete as restrições reais do live trading. No entanto, processar uma timeline financeira evento a evento em Python puro cria um bottleneck enorme. Podes estar a processar anos de dados de preços ao minuto para milhares de ações individuais. Para tornar este event loop computacionalmente viável, o Zipline faz offload de grande parte do trabalho para C-extensions. A core engine depende de rotinas pré-compiladas para processar os números rápido o suficiente para ser útil. Esta dependência de C-extensions introduz um grande ponto de atrito. Fazer o setup de um environment quantitativo robusto do zero é notoriamente difícil. O Zipline não é uma tool Python standalone. Requer uma integração profunda com libraries científicas system-level. Por exemplo, usa a TA-Lib, uma standard library para gerar indicadores técnicos de mercado. Também depende de packages que precisam do LAPACK e do BLAS para cálculos pesados de álgebra linear. Estas são codebases legacy e complexas em C e Fortran. Se tentares fazer a build deste environment usando um simples comando pip install, vais quase de certeza bater numa parede de erros de compilação. O pip faz o download do source code para estas dependências e tenta compilá-las localmente. Isto exige que o teu sistema operativo tenha um compiler de C bem configurado, um compiler de Fortran, e os system header files corretos já instalados. A maioria dos sistemas operativos base não tem isto out of the box. É por isso que a documentação do Zipline recomenda explicitamente o uso de conda em vez de pip. O conda não é apenas um package manager de Python. É um binary manager de environment e system-level. Quando crias um environment conda e instalas o Zipline através do channel conda-forge, não estás a compilar nada a partir do source. O conda faz o download de binários pré-compilados para o teu sistema operativo específico. Lida com as C-extensions, a TA-Lib e o LAPACK de forma transparente. A dependency tree é resolvida para ti, gerando um environment estável pronto para desenvolvimento algorítmico. Aqui está o insight principal. O event loop rigoroso que torna o Zipline matematicamente honesto é exatamente o que o força a depender de C-dependencies pesadas e compiladas para correr em scale. Ao entenderes esta arquitetura, percebes por que razão a instalação é complexa, e por que o conda é a única forma sensata de fazer a build do teu environment. Se quiseres ajudar a manter o show a andar, podes apoiar-nos procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e keep building!

Olá, daqui é o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 2 de 7. Configuras um contador simples na tua lógica de trading usando uma variável global em Python e, a meio do backtest, ele faz reset ou lança um erro. No backtesting event-driven, as variáveis globais normais são uma armadilha. Para sobreviveres a milhares de eventos de mercado simulados, precisas de uma forma segura de manter o state, que é exatamente onde o Algorithm Lifecycle e o State Management do Zipline entram em ação. Qualquer algoritmo em Zipline requer pelo menos duas funções fundamentais: initialize e handle data. O Zipline é um sistema event-driven. Ele percorre os dados históricos cronologicamente, disparando um evento para cada time slice. A função initialize corre exatamente uma vez quando o teu backtest começa. Ela recebe um único argumento chamado context. Pensa no context como a memória persistente do teu algoritmo. Por debaixo do capô, é um simples dicionário de Python, mas atua como um namespace dedicado. Em vez de declarares variáveis globais normais, tu associas o teu state diretamente ao context. Se quiseres monitorizar um asset específico, como as ações da Apple, procuras por ele no initialize e atribuis a context dot asset. Isto garante que a referência sobrevive desde o primeiro até ao último dia do backtest. A seguir temos a função handle data. Esta é chamada sempre que há um novo evento de mercado, como uma nova trading bar diária. Ela recebe dois argumentos: context e data. Tu já conheces o context. É aí que lês o state que configuraste antes, ou atualizas variáveis em execução. O segundo argumento, data, representa o ambiente de mercado atual. É a tua lente para a simulação naquele exato momento. Usas o data para verificar se um asset está tradable no momento, para ir buscar o seu preço atual, ou para pedir uma janela histórica de preços. Considera uma estratégia standard de crossover de duas médias móveis. Na tua função initialize, defines o teu asset alvo e associas ao context. Dentro do handle data, pedes ao objeto data os preços dos últimos trinta dias para calcular uma média móvel curta, e os últimos trezentos dias para uma média móvel longa. Comparas as duas médias. Se a média curta cruzar acima da média longa, é um sinal de compra. Executas isto chamando a função order, passando o teu context dot asset e um número alvo de ações. Fazer trading é apenas metade do trabalho. Também precisas de monitorizar a performance dos teus indicadores ao longo do tempo. O Zipline oferece uma função built-in chamada record. No final do teu bloco handle data, chamas o record e passas-lhe a tua média móvel curta, a média móvel longa e o preço atual. O Zipline recolhe estes valores gravados a cada passo e anexa-os ao dataframe de performance final, retornado no fim do backtest. Quando o teu código estiver pronto, tens duas formas de o correr. A primeira é através da command line interface. Passas o teu script Python para o comando run do Zipline, especificando as tuas datas de início e fim, o teu capital inicial, e um ficheiro de output para os resultados de performance. Isto é ideal para pipelines automatizadas ou execução remota. O segundo método é interativo. Se usares Jupyter Notebooks, podes usar o magic command built-in do Zipline. Ao escreveres percent percent zipline no topo de uma célula do notebook, defines e executas o algoritmo inline, passando as tuas datas e capital como argumentos para o magic command. Os resultados são injetados diretamente num dataframe local, prontos para análise imediata. Aqui está o insight principal. O Zipline obriga-te a dividir o teu algoritmo em dois objetos distintos: context para o state interno que tu controlas, e data para o ambiente de mercado externo. Respeita essa fronteira, e o teu state management vai manter-se perfeitamente sincronizado ao longo de milhares de trades. É tudo por este episódio. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 3 de 7. A tua lógica de trading pode ser impecável, mas se carregares ficheiros CSV enormes para a memória sempre que corres uma simulação, a tua velocidade de iteração vai parar completamente. O bottleneck raramente é o teu algoritmo. É o teu data pipeline. O Zipline resolve este problema usando Market Data Bundles e Custom Ingestion. Um data bundle é uma coleção de preços de ativos e metadata que foi pré-compilada num formato de storage altamente otimizado. Em vez de fazer o parsing de ficheiros de texto raw durante uma run, o Zipline lê de storage binário comprimido e de uma base de dados local rápida. Esta separação entre o processamento de dados e a execução da estratégia torna os backtests excecionalmente rápidos. Tu disparas esta compilação a partir da command line usando o comando zipline ingest, seguido do nome do bundle. O Zipline traz um default bundle chamado Quandl, que vai buscar dados históricos diários standard de ações à internet e os escreve diretamente no teu disco local. A maioria dos ambientes profissionais depende de dados proprietários. Para usares os teus próprios dados, tens de construir um custom bundle. Criar um custom bundle requer escrever uma ingest function. Esta função atua como um tradutor dedicado entre a tua source de dados raw e o formato de storage interno do Zipline. Aqui está o ponto crucial. A ingest function não devolve um dataset customizado. Em vez disso, o Zipline passa vários writer objects para a tua função, e o teu código alimenta esses writers com dados raw. A signature da ingest function requer parâmetros específicos para lidar com este routing. Ela recebe uma configuração de environment, o trading calendar, as sessões de start e end, e os writer objects. Os dois objetos críticos com os quais vais interagir são o asset database writer e o daily bar writer. O asset database writer lida com a tua metadata. Tu passas-lhe uma tabela estruturada contendo os teus symbols, as suas datas de start e end, e os nomes das suas exchanges. O writer compila isto numa base de dados local para que o engine saiba exatamente quais os ativos que existem em qualquer trading session. O daily bar writer processa a price action real. Tu forneces-lhe um iterator que faz yield de blocos de pricing data. Cada bloco contém um identificador interno do ativo, emparelhado com uma tabela dos seus dados de open, high, low, close e volume. O writer pega nestes blocos e comprime-os no disco. O Zipline fornece um mecanismo built-in para lidar com flat files standard usando o CSV directory bundle, comumente chamado de csvdir. Tu configuras os teus dados proprietários guardando ficheiros CSV individuais numa única pasta, nomeando cada ficheiro com o seu ticker symbol. A seguir, registas este diretório num script de configuração específico do Zipline chamado extension file. O registo simplesmente liga o nome do teu custom bundle à ingest function subjacente, para que a command line tool saiba que ele existe. Quando corres o zipline ingest com o teu novo nome customizado, o sistema aponta a ingest function para a tua pasta. Ele faz um loop pelos ficheiros CSV, extrai a metadata, alimenta o asset database writer, e injeta as rows de pricing histórico no daily bar writer. O text parsing lento e custoso acontece exatamente uma vez. Após a ingestion, os teus dados proprietários ficam guardados permanentemente no formato otimizado, instantaneamente acessíveis para milhares de iterações de backtest de alta velocidade. O verdadeiro poder da custom ingestion é que ela faz o decouple estrito da tua preparação de dados da execução da tua estratégia, garantindo que a lógica de parsing lenta nunca polua o teu ambiente de testes. É tudo por este episódio. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 4 de 7. Splits de ativos e dividendos podem invalidar instantaneamente o teu histórico de preços. Se uma ação sofre um split de dois para um, um loop de backtesting ingénuo vai achar que o preço acabou de cair cinquenta por cento. Evitas isto usando a Algorithm API e as interações com BarData, que lidam com ajustes point-in-time automaticamente. No Zipline, o núcleo da lógica do teu algoritmo interage com um objeto tipicamente chamado data, que é uma instância de BarData. Ele é passado para os teus event handlers, como o teu data handler principal ou as tuas scheduled functions. A sua principal função é servir dados de preço e volume exatamente como apareceram naquele momento específico da simulação, prevenindo completamente o look-ahead bias. Quando chamas data dot current, passas-lhe um asset e um field, como price ou volume. Ele dá-te o valor mais recente disponível naquele minuto ou dia exato da simulação. Quando precisas de uma lookback window para calcular uma moving average ou volatilidade histórica, chamas data dot history. Dás-lhe o asset, o field, o número de barras e a frequência, como um dia ou um minuto. Aqui está o ponto chave. Tanto o current como o history ajustam automaticamente os dados retornados para corporate actions, mas apenas até ao tempo atual da simulação. As tuas moving averages não vão sofrer distorções enormes numa data ex-dividendo, porque os preços históricos são ajustados para se alinharem perfeitamente com a price frame atual. Obténs uma time series matematicamente contínua sem teres de gerir os multiplicadores de corporate actions tu mesmo. Antes de agires sobre esses dados de preço, precisas de verificar se o asset é realmente tradable naquele exato momento. Passar o teu asset para data dot can trade verifica se a exchange está aberta para esse asset e se ele está ativamente listado. Se uma ação sofreu delist ontem, ou ainda não teve a sua initial public offering, isto retorna false. A seguir, tens o data dot is stale. Se um asset for altamente ilíquido e não tiver sido negociado durante a barra atual, o Zipline vai fazer forward-fill do último preço conhecido para evitar erros de missing data. No entanto, se executares uma estratégia de mean-reversion em preços com forward-fill, estás a fazer trading com dados fantasma. Data dot is stale retorna true se o preço que vês for trazido de um período anterior em vez de uma trade nova. Verificar tanto a tradability como a staleness antes de colocar uma order previne uma classe massiva de erros de simulação. Isso cobre os inputs, passando agora para o execution timing. Por defeito, o Zipline chama o teu data handler principal a cada barra de simulação. Se correres uma estratégia ao nível do minuto, executar lógica complexa de rebalanceamento a cada sessenta segundos vai arrastar o teu backtest e disparar transaction costs irreais. A solução é o método schedule function. Usas isto dentro da fase de inicialização do teu algoritmo para registar uma custom function específica para correr num horário preciso. Recebe três argumentos principais. Primeiro, a função que queres correr. Segundo, uma date rule. Terceiro, uma time rule. Supõe que queres correr um rebalanceamento de portefólio exatamente trinta minutos antes do fecho do mercado. Passas a tua função de rebalanceamento como o primeiro argumento. Para a date rule, usas o helper method date rules dot every day. Para a time rule, usas time rules dot market close, passando trinta minutos como argumento de offset. Agora, em vez de disparar centenas de vezes por dia, a tua lógica de rebalanceamento corre exatamente uma vez, mesmo quando a trading session está a terminar. A separação entre o objeto BarData para acesso seguro a dados e a scheduling API para execution timing garante que a lógica principal do teu algoritmo só corre quando deve, usando preços que realmente existiam naquele exato momento. Gostava de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um ótimo dia!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 5 de 7. O teu algoritmo identifica um sinal de saída perfeito e dispara uma ordem de venda massiva. O problema é que é sábado. Se o teu backtesting engine não souber que a exchange está fechada, essa ordem ou é executada num mercado fantasma ou faz crashar toda a tua simulação. Os Custom Trading Calendars mapeiam a realidade dos horários de mercado globais para evitar exatamente este cenário. Um trading calendar no Zipline é a source of truth absoluta para as sessões de mercado. Ele dita quando os dados podem ser ingeridos e quando as ordens podem ser processadas. Por default, o Zipline assume um horário standard de ações dos Estados Unidos. Se quiseres negociar ações internacionais, futuros ou ativos alternativos, tens de definir as regras específicas dessas exchanges. Fazes isto criando uma custom class que herda da base class Trading Calendar do Zipline. Só precisas de configurar algumas properties específicas para estabelecer os limites do dia de negociação. Primeiro, defines o open time. Isto dita a hora e o minuto exatos em que o mercado começa a aceitar ordens. Segundo, defines o close time, que marca o último minuto da sessão de negociação. Terceiro, defines os regular holidays. Isto é uma collection de datas específicas em que a exchange está completamente fechada, como feriados nacionais. O Zipline não faz todo este cálculo de datas from scratch. Ele utiliza imenso a library pandas, especificamente as classes Holiday Calendar e Custom Business Day do pandas. Quando forneces a tua lista de regular holidays, estás essencialmente a popular um objecto Holiday Calendar do pandas. O Zipline combina esta lógica do pandas com os teus open e close times definidos para gerar um index massivo e pré-calculado de cada minuto de negociação válido para toda a duração do teu backtest. Este cálculo upfront é crucial. Significa que o teu algoritmo não está a avaliar matemática de datas complexa durante cada tick da simulação. Ele simplesmente faz uma query a um array altamente otimizado. Esta é a parte que interessa. Nem todos os mercados dormem. Se estiveres a simular trades de criptomoedas, as assumptions standard sobre os fins de semana vão arruinar o teu data alignment. Tens de construir um calendar contínuo vinte e quatro sete. Vamos ver como construir um, ao qual vamos chamar TFS Exchange Calendar. Defines a tua nova class e herdas da base class standard. Para o open time, especificas meia-noite. Para o close time, especificas onze e cinquenta e nove da noite, dando-te um ciclo diário completo. Como as exchanges de criptomoedas não observam feriados tradicionais, defines a property regular holidays para retornar uma empty list. O passo final é ajustar o schedule semanal. Os trading calendars tradicionais usam um objecto Custom Business Day do pandas configurado estritamente de segunda a sexta-feira. Para o teu calendar TFS, fazes override desta property weekmask para incluir explicitamente sábado e domingo. Assim que a class estiver completa, vais registá-la no environment do Zipline usando um custom string identifier. A partir desse ponto, tanto os teus data ingestion bundles como os teus trading algorithms vão reconhecer o schedule contínuo. As ordens vão ser processadas sequencialmente, sem saltar os fins de semana, e os dados ao nível do minuto vão mapear perfeitamente para os timestamps do mundo real. Se as regras do teu calendar estiverem mal configuradas, os teus price data vão ficar desalinhados e as tuas performance metrics vão ser totalmente fictícias. Os time boundaries ditam todas as ações num event-driven engine, e os trading calendars são exatamente a forma como dás enforce a esses boundaries. É tudo por este episódio. Obrigado por ouvires, e keep building!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 6 de 7. Calcular métricas de risco complexas a cada tick pode tornar o teu backtest extremamente lento. Tu queres que as tuas simulações sejam rápidas, mas também precisas de saber exatamente como a tua estratégia se comporta sob stress. Na verdade, podes desativar o tracking default durante o debugging ou escrever trackers customizados altamente otimizados. Este episódio aborda Risk Performance Metrics e Custom Evaluation. O Zipline agrupa os seus cálculos de risco e performance built-in numa estrutura chamada Metric Set. O set default gera automaticamente estatísticas standard como beta, Sharpe ratio e total returns. Quando a tua simulação termina, o Zipline empacota todos estes cálculos no DataFrame de performance. Cada métrica com tracking torna-se numa coluna, e cada linha representa um time step na tua simulação. Se não precisares de todas estas métricas default, podes passar um Metric Set simplificado ao iniciar o engine, poupando um tempo de processamento significativo. Quando as métricas default não capturam o teu modelo de risco específico, tu defines uma métrica customizada. Fazes isso criando uma subclass do objeto de métrica base do Zipline. Escrever uma métrica customizada significa fazer um hook diretamente ao relógio interno da simulação. Tu controlas exatamente quando a tua lógica é executada implementando três métodos de lifecycle específicos: start of simulation, end of session e end of bar. O start of simulation é onde inicializas variáveis e defines o state inicial. O end of session corre uma vez no fecho do dia de trading. O end of bar é executado após cada atualização de preço, o que é crítico para estratégias ao nível do minuto. Sempre que um destes hooks baseados em tempo é acionado, o Zipline passa-lhe dois argumentos obrigatórios: o ledger e o packet. O ledger guarda o state matemático em tempo real da tua simulação. Contém o valor atual do teu portefólio, saldos de cash e todas as posições abertas. Tu tratas o ledger como dados read-only. O packet, por outro lado, é um dictionary vazio que representa o payload de dados para esse time step específico. Tu escreves no packet. Qualquer key-value pair que atribuas ao dictionary do packet torna-se instantaneamente numa coluna no teu DataFrame de performance final. Vamos ver como fazer o tracking do maximum intraday drawdown usando o hook end of bar. Primeiro, defines a tua class de métrica customizada. No método start of simulation, crias duas variáveis: uma para fazer o tracking do valor mais alto do portefólio visto até agora, e outra para o maximum drawdown atual. Ambas começam a zero. Aqui está o insight principal. Como as quedas intraday são invisíveis se verificares apenas os preços de fecho diários, tens de executar a tua lógica dentro do método end of bar. Dentro deste método, lês o valor atual do portefólio a partir do argumento ledger. Se o valor atual for maior do que o teu valor mais alto registado, atualizas a high water mark. Se for menor, calculas a queda percentual. Se essa queda exceder o teu maximum drawdown registado, atualizas a variável de maximum drawdown. Finalmente, pegas na tua variável de maximum drawdown e atribuis a uma key no argumento packet. Ao escreveres no packet no final de cada bar, o teu DataFrame de performance final vai conter um registo granular, minuto a minuto, da pior queda intraday experienciada. As métricas customizadas são fundamentalmente apenas observers a ler o ledger da simulação e a escrever no packet de output, dando-te controlo total sobre o que é medido e quando. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. Zipline Backtesting Engine, episódio 7 de 7. Passas meses a aperfeiçoar um algoritmo num simulador, mas o mercado real não aceita ordens de trading simuladas. O Zipline foi concebido principalmente para backtesting, mas a sua arquitetura modular significa que podes ignorar completamente a simulação interna e encaminhar diretamente para um execution engine real. Estender a arquitetura do Zipline torna esta transição possível. De origem, o Zipline opera como um circuito fechado. Alimentas o sistema com dados históricos de preços, ele calcula sinais e cruza as tuas ordens internamente com o comportamento passado do mercado. O sistema isola intencionalmente o teu algoritmo de redes externas. Mas um sistema de trading moderno acaba por precisar de comunicar com o mundo exterior. Precisas de uma forma de substituir os componentes da simulação interna por módulos customizados que lidem com live data e capital real. O Zipline lida com este requisito através de um mecanismo de extensão construído à volta de um ficheiro de inicialização específico chamado extension dot py. Este ficheiro atua como um registry local para o teu ambiente. Quando a framework Zipline arranca, procura imediatamente aqui por overrides definidos pelo utilizador. Usas este ficheiro para registar novos data bundles, modelos de comissão customizados e execution engines alternativos. O componente mais crítico que tens de substituir para live trading é o Blotter. O Blotter atua como o sistema interno de gestão de ordens. Ele rastreia ordens em aberto, cancela-as quando instruído e processa os trade fills. O blotter de simulação por defeito finge executar trades com base em volume histórico e algoritmos de slippage. Para fazer live trading, tens de ignorar isto completamente. Consegues isto ao escreveres uma class Blotter customizada. Em vez de simular a execução, os métodos da tua class fazem network calls para a API de um broker real. Quando o algoritmo pede uma trade, o teu blotter customizado formata esse pedido numa live order e transmite-a para a exchange. Aqui está o ponto chave. Não modificas uma única linha do source code original do Zipline para implementar isto. Defines a tua class Blotter customizada no teu próprio workspace. Depois, abres o extension dot py. Importas a função de registo do blotter a partir do módulo de utilities do Zipline. Passas a esta função uma string única com o nome para o teu broker, juntamente com a tua class Blotter customizada. Isso regista o teu execution engine globalmente. Finalmente, quando executas o teu script de trading a partir da command line ou de um notebook, forneces simplesmente a string com o nome do teu blotter customizado como launch parameter. A framework troca a maquinaria interna automaticamente. Exatamente o mesmo algoritmo que correu em simulação está agora a fazer trading com capital real. Suportar este nível de modularidade exige uma core foundation altamente estável. O Zipline depende muito de dataframes numéricos rápidos e armazenamento em base de dados relacional para mover informação entre o algoritmo e o blotter. Com o lançamento do Zipline 3.0, a core architecture recebeu uma atualização estrutural significativa para modernizar esta fundação. Toda a plataforma foi migrada para suportar Pandas 2.0 e SQLAlchemy 2.0. O upgrade para o Pandas 2.0 traz uma gestão de memória substancialmente melhor e tempos de execução mais rápidos para os enormes arrays de time series que o Zipline processa a cada tick. O SQLAlchemy 2.0 moderniza completamente a forma como o engine interage com as bases de dados SQL subjacentes. Ele impõe query execution paths mais rigorosos e explícitos quando o sistema gere metadados de ativos e armazena resultados de trading. Estes upgrades fundamentais garantem que, quer estejas a correr um backtest histórico massivo ou a encaminhar live orders através de uma extensão de broker customizada, o engine opera no standard moderno da infraestrutura de dados de Python. Ao separar a lógica de trading das mecânicas de execução, a arquitetura garante que o teu algoritmo permanece completamente intocado, enquanto a execution layer subjacente se adapta à realidade. Encorajo-te vivamente a explorar a documentação oficial e a tentares escrever as tuas próprias extensões hands-on. Se tiveres ideias sobre o que devemos abordar a seguir, visita dev stories dot eu para sugerires tópicos para as nossas futuras séries. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.