Você aí, tem medo de usar o git? O máximo que faz é commitar e subir? Os outros comandos te assustam? Não se preocupe, você não está sozinho!

O Git pode parecer intimidante no início, mas uma vez que você entenda o básico, ele se torna uma ferramenta poderosa e indispensável para qualquer dev!

Neste artigo, vou explicar alguns comandos úteis e quando utilizá-los.

git stash​

O comando git stash permite que você salve temporariamente as mudanças que você fez no seu código, sem precisar commitar tudo de uma vez.

É como se você estivesse colocando suas alterações em um esconderijo temporário, para que possa trabalhar em outras coisas sem se preocupar em perder o trabalho que já fez. Quando você estiver pronto para voltar a trabalhar nas alterações, basta abrir o esconderijo e recuperar o que estava dentro dele.

Os comandos git stash pop e git stash apply são usados para aplicar as alterações armazenadas em um stash ao seu diretório de trabalho.

A diferença entre eles é o que acontece com o stash após a aplicação das alterações:

• git stash apply Este comando aplica as alterações do stash mais recente (ou especificado) ao seu diretório de trabalho, mas deixa esse stash na lista de stashes para possível reutilização

• git stash pop Este comando aplica as alterações do stash mais recente (ou especificado) ao seu diretório de trabalho e remove esse stash da lista de stashes. Porém, se houver conflitos após o git stash pop, ele não removerá o stash, fazendo com que se comporte exatamente como o git stash apply

Então basicamente, git stash pop é git stash apply && git stash drop

Mas lembre-se, se houver conflitos durante a aplicação do stash, ambos os comandos irão desencadear o modo de resolução de conflitos de mesclagem e nenhum deles se livrará do stash

Para visualizar todos os stashes, use o comando git stash list

Para dar um nome ao stash, use o comando git stash save nome-do-seu-stash

git mv​

O comando git mv é usado para renomear ou mover arquivos sem perder o histórico do git. Ele tem a seguinte sintaxe:

git mv [origem] [destino]

• origem é o nome do arquivo ou diretório que você deseja renomear ou mover.
• destino é o novo nome ou caminho do arquivo ou diretório.

Por exemplo, para renomear um arquivo chamado index.html para home.html:

git mv index.html home.html

Para mover um arquivo chamado index.html para o diretório public_html:

git mv index.html public_html/

Para renomear um diretório chamado scripts para scripts_new:

git mv scripts scripts_new

Para mover um diretório chamado scripts para o diretório src:

git mv scripts src/

O comando git mv rastreia as alterações nos arquivos e diretórios que você renomeia ou move. Isso significa que você pode reverter essas alterações se precisar.

Se você renomear um arquivo chamado index.html para home.html, e depois decidir que não quer mais a renomeação, você pode reverter a alt: git reset HEAD index.html

Isso restaurará o arquivo index.html para o seu nome original.

git amend​

Com o git amend, você pode fazer alterações em um commit anterior sem precisar criar um novo commit.

• git commit --amend --no-edit: altera o último commit que você fez. Isso é útil quando você percebe que esqueceu de adicionar um arquivo ou precisa corrigir um erro no commit anterior. O parâmetro --no-edit significa que você não precisa editar a mensagem do commit anterior. Se você quiser editar a mensagem, basta remover esse parâmetro.

• git commit -m 'mensagem alterada' --amend: altera a mensagem do último commit que você fez. Isso é útil quando você percebe que a mensagem do commit anterior não está clara o suficiente ou precisa ser mais específica.

git fetch​

O comando git fetch é usado para buscar as atualizações mais recentes de um repositório remoto e atualizar o seu repositório local com essas mudanças.

É como se você estivesse buscando as últimas notícias de um jornal para se atualizar, mas sem necessariamente ler todas as notícias. O git fetch baixa as mudanças do repositório remoto, mas não as integra automaticamente ao seu repositório local. Para isso, você precisará usar outro comando, como o git merge.

Por exemplo, imagine que você tenha um repositório remoto chamado projeto-1-origin e um repositório local chamado projeto-2. Para manter os dois repositórios sincronizados, terá que adicionar o projeto-1-origin como um "remote" no seu repositório local. Isso pode ser feito com o comando:

git remote add repo1 <url-do-repositorio-1>

O nome repo1 é apenas uma referência para o repositório remoto no seu repositório local. Geralmente, é comum usar "origin" como nome para o repositório remoto principal, mas você pode escolher qualquer nome que faça sentido para o seu projeto.

Agora, para sincronizar com o repositório remoto, buscando todas as branches e atualizações,: git fetch repo1

Em seguida, você pode mesclar a branch principal (ou qualquer outra branch que você queira) do repositório 1 para a branch atual do repositório:

# Integra as mudanças baixadas ao seu repositório local
git merge repo1/main

Resolva quaisquer conflitos de mesclagem que possam ocorrer e por fim, faça o commit e o push das alterações para o repositório 2

git rebase​

O comando git rebase é usado para mover ou combinar uma sequência de commits para um novo commit base, reescrevendo o histórico do projeto. É um dos comandos mais poderosos, que te permite alterar a ordem, commits, além de ajudar a manter um histórico de commits mais limpo e organizado.

É como se você podesse pegar um conjunto de cartas de baralho e reoganizá-las da maneira que quiser, criando uma nova sequência de cartaas que mais faz sentido para você.

O rebase é uma alternativa ao comando git merge, que também é usado para integrar as mudanças de um branch para outro. A principal diferença entre o rebase e o merge é que o rebase move os commits de um branch para outro, enquanto o merge cria um novo commit que combina as mudanças de ambas branches.

Isso significa que o rebase pode ser usado para criar um histórico de commits mais linear e fácil de entender, enquanto o merge pode ser usado para manter um histórico de commits mais completo e preciso.

Você pode usar o comando git rebase para:

• Reorganizar commits
• Editar mensagens de commit
• Alterar nome da pessoa do commit
• Dividir um commit em vários commits menores
• Combinas vários commits em um único commit

Para editar a mensagem dos últimos 10 commits de uma branch. Faça da seguinte forma com o comando:

git rebase -i HEAD~10

• Isso abrirá um editor de texto com uma lista dos últimos 10 commits.
• Substitua pick porreword na frente de cada commit que você deseja editar
• Salve e feche o editor
• Isso abrirá outro editor de texto que permitirá que você edite a mensagem de commit do commit selecionado
• Salve e feche o editor novamente e o Git irá reescrever o histórico de commits com as novas mensagens de commit

Se o seu editor de texto não estiver abrindo como esperado, execute o seguinte comando: git config --global core.editor "code --wait"

Em alguns casos, acontece da pessoa não alterar o nome de configuração global do Git e commitar com o nome do outro colega, commitar sem nome, ou algum erro em específico.

e para corrigir isso, podemos alterar o nome da pessoa que fez os últimos 10 commits em uma branch,da seguinte forma:

git rebase -i HEAD~10

• Isso abrirá um editor de texto com uma lista dos últimos 10 commits.
• Substitua pick por edit na frente de cada commit que você deseja alterar
• Salve e feche o editor
• Para cada commit, os seguintes comandos:

git commit --amend --author="Novo Nome <novoemail@email.com>"
git rebase --continue

Depois de alterar todos os commits, você precisará forçar o push para o repositório remoto se já tiver feito o push desses commits:

git push origin +nome-da-sua-branch

O sinal de mais (+) antes do nome da branch no comando git push é o que permite o “push forçado”. Isso significa que o Git substituirá a branch remota mesmo que a sua versão local esteja desatualizada, o que é necessário quando você reescreve o histórico de commits como fez aqui.

Conclusão​

Viu só como não é um bicho de sete cabeças? O Git possui muitos comandos que facilitam o nosso dia a dia para resolver alguns problemas relacionados. Espero que esse artigo tenha te ajudado a entender alguns comandos. Lembre-se que a prática leva à perfeição!

Em breve, irei escrever a parte 2 com mais alguns comandos. O Git possui inúmeros deles e dicas que podem facilitar ainda mais o seu trabalho. Até a próxima!

Migrating to standlone: https://angular.io/guide/standalone-migration

O que é um Standalone Component?​

Um Standalone Component (Componente Independente) é um componente Angular que pode ser utilizado de forma isolada, ou seja, sem depender de um NgModule. Ele é autocontido e não requer a declaração em um módulo para ser utilizado.

Diferentemente dos componentes tradicionais, que são declarados em um NgModule e precisam ser importados nesse módulo para serem utilizados, um Standalone Component pode ser importado e utilizado diretamente em qualquer parte da aplicação, sem a necessidade de configurar um módulo específico.

São especialmente úteis em projetos menores ou quando se deseja migrar gradualmente uma aplicação existente para a nova abordagem.

• Documentação Oficial: https://angular.io/guide/standalone-components

Etapas de migração​

Este schematic está disponível apenas no Angular 15.2.0 ou posterior.

• Execute o schematic com o seguinte comando:

• Execute a migração na ordem listada abaixo, verificando se seu código é compilado e executado entre cada etapa:

Depois da migração​

Parabéns, sua aplicação foi convertida para standalone 🎉. Estas são algumas etapas opcionais de acompanhamento que você pode seguir:

• Encontre e remova quaisquer declarações NgModule restantes: como a etapa “Remove unnecessary NgModules” não pode remover todos os módulos automaticamente, talvez seja necessário remover as declarações restantes manualmente.
• Execute os testes unitários do projeto e corrija quaisquer falhas.
• Execute qualquer formatador de código, se o projeto usar formatação automática.
• Execute todos os linters do seu projeto e corrija novos avisos. Alguns linters suportam a flag--fix que pode resolver alguns avisos automaticamente.

Converter rotas para standalone​

Após a migração, os módulos de funcionalidades criados ainda existirão, pois ainda possuem a configuração de roteamento. Também podemos migrar a configuração de roteamento para Standalone, e esta etapa precisa ser feita manualmente, pois não é suportada pelo schematic.

Cart Routing Module:

Products Routing Module:

App Routing Module:

Remova app-routing.module do main.ts​

Agora podemos excluir com segurança os seguintes arquivos:

• cart-routing.module.ts
• products-routing.module.ts
• app-routing.module.ts

E também excluir:

• cart.module.ts
• products.module.ts

Lazy loading em um componente Standalone​

Qualquer rota pode carregar com lazy o seu componente Standalone e roteado usando loadComponent.

Portanto, em vez de criar um arquivo CART_ROUTES, podemos carregar lentamente o componente diretamente no APP_ROUTES e remover o arquivo cart.routes.ts:

Função Inject​

A função “inject” é uma função utilizada em contextos de injeção de dependência (DI) para recuperar uma instância de um objeto a partir de um token específico. Ela é usada para obter uma dependência do sistema de injeção de dependência ativo. Leia mais na documentação oficial.

Conclusão​

Em resumo, a migração para Standalone Components é uma opção viável para otimizar o desenvolvimento Angular, proporcionando componentes mais independentes e facilitando a reutilização em diferentes partes da aplicação.

Ao seguir as etapas de migração e aproveitar as vantagens oferecidas por essa abordagem, é possível melhorar a organização e a manutenção do código, tornando-o mais eficiente e escalável.

Nos últimos anos, o uso de APIs tem crescido bastante, principalmente devido ao aumento da demanda por aplicativos e serviços baseados em nuvem. As APIs permitem que diferentes sistemas se comuniquem e compartilhem dados de forma eficiente e segura, tornando a integração de sistemas mais fácil e eficaz.

Com o aumento da popularidade das APIs, a documentação dessas APIs tornou-se ainda mais importante.

Você já ouviu falar sobre o Swagger?​

É aqui que entra a ferramenta Swagger, que permite criar uma documentação clara e completa da API, ela fornece uma maneira fácil e padronizada de descrever os endpoints, parâmetros, respostas e modelos de dados que compõem uma API.

Também oferece recursos avançados, como autenticação e autorização, que permitem que os desenvolvedores restrinjam o acesso a certos endpoints da API.

Clean Architecture​

A documentação da API também é essencial para manter uma arquitetura limpa em um aplicativo. Clean Architecture é um padrão de arquitetura de software que ajuda a manter o código bem estruturado, modular e fácil de manter.

Com uma documentação clara e completa, podemos facilmente entender como a API funciona e como integrá-la ao aplicativo de uma maneira que siga as suas melhores práticas.

Configuração do Swagger​

Depois de configurar o Swagger em seu projeto e definir as rotas necessárias para documentar sua API, é hora de trabalhar no código de configuração e começar a gerar o código inicial.

De acordo com a documentação, a estrutura inicial será algo parecido com:

const swaggerUi = require("swagger-ui-express");
const swaggerJsdoc = require("swagger-jsdoc");


const swaggerOptions = {
   definition: {
    openapi: "3.0.0",
    info: {
      title: "Título da sua API",
      description: "Descrição da API",
      version: "1.0.0",
      contact: {
        name: "Contato",
        url: "URL de contato",
      },
    },
    externalDocs: {
      description: "Alguma documentação externa",
      url: "URL para documentação externa",
    },
    servers: [
      {
        url: "/api",
        description: "Servidor Principal",
      },
    ],
    "tags": [
    {
      "name": "Usuários",
      "description": "Descrição da tag"
    }
  ],
    securityDefinitions: {
      apiKeyAuth: {
        type: "apiKey",
        name: "Authorization",
        in: "header",
      },
    },
  "paths": {
    "/api/users": {
      "get": {
        "tags": [
          "Usuários"
        ],
        "description": "Retorna todos os usuários",
        "responses": {
          "200": {
            "description": "Usuários retornados com sucesso"
          },
          "400": {
            "description": "Erro ao retornar usuários"
          }
        }
      }
    }
  }
},
"schemas": {
      "usuarios": {
        "type": "object",
        "properties": {
          "nome": {
            "type": "string"
          },
          "sobrenome": {
            "type": "string"
          },
          "cpf": {
            "type": "string"
          },
          "email": {
            "type": "string"
          }
        }
      required: ["nome", "sobrenome", "cpf"]
  },
  apis: [],
};

const swaggerDocs = swaggerJsdoc(swaggerOptions);

Agora imagine que à medida que o seu projeto cresce em complexidade, você precisa lidar com uma grande variedade de requisições possíveis, schemas, responses e muito mais dentro de “paths”. Se você não organizar bem o código, ele pode ficar enorme e dificultar a localização do que é necessário.

Para garantir que um sistema seja fácil de manter e bem organizado, é fundamental adotar uma estrutura clara e objetiva. É nesse ponto que a arquitetura limpa e os princípios SOLID entram em cena.

Esses princípios separam a responsabilidades e isso torna o código mais fácil de entender, testar e modificar.

Estrutura escalável​

|-- docs
    |-- paths
        |-- [+] features
        |-- index.js
    |-- responses
        |-- badRequest.js
        |-- conflict.js
        |-- forbidden.js
        |-- notFound.js
        |-- serverError.js
        |-- unauthorized.js
        |-- index.js
    |-- schemas
        |-- [+] features
        |-- index.js
    |-- tags
        |-- [+] moduloTal
        |-- index.js
|-- swaggerConfig.js

• Paths: contém os arquivos que definem os endpoints disponíveis na API, divididos por módulos/features específicos.
• Responses: contém os arquivos que definem as respostas possíveis da API em caso de solicitações bem-sucedidas ou com falha. Cada resposta tem um arquivo separado para manter a organização e facilitar a manutenção.
• Schemas: contém os arquivos que definem os modelos de dados usados na API, também divididos por módulos específicos.
• Tags: contém os arquivos que definem as tags usadas para agrupar endpoints relacionados na documentação do Swagger.

No arquivo “index.js” em cada subpasta serve como ponto de entrada para essa seção específica e contém as importações necessárias.

Dessa forma, a a navegação e a manutenção da documentação pode se tornar mais fácil, especialmente à medida que ela cresce em tamanho e complexidade.

Sendo assim, podemos fazer as seguintes melhorias no arquivo de configuração do Swagger:

const swaggerJSDoc = require("swagger-jsdoc");
const paths = require("./paths/index");
const schemas = require("./schemas/index");
const responses = require("./responses/index");
const tags = require('./tags');

const swaggerOptions= {
  definition: {
    openapi: "3.0.0",
    info: {
      title: "Título da sua API",
      description: "Descrição da API",
      version: "1.0.0",
      contact: {
        name: "Contato",
        url: "URL de contato",
      },
    },
    externalDocs: {
      description: "Alguma documentação externa",
      url: "URL para documentação externa",
    },
    servers: [
      {
        url: "/api",
        description: "Servidor Principal",
      },
    ],
    security: [{
      apiKeyAuth: []
    }],
    tags: tags,
    paths: paths,
    schemas: schemas,
    responses: responses,
  },
  apis: [],
};

const swaggerSpec = swaggerJSDoc(swaggerOptions);
module.exports = swaggerSpec;

Dessa forma, ajuda a manter a documentação organizada e fácil de navegar.

Confira com mais detalhes a estrutura e o código, em meu repositório, onde criei uma API Fake para simular as requisições e assim poder documentar com o Swagger.

Link para acesso disponível aqui

Conclusão​

Esse foi um breve artigo, onde destacamos a importância de manter um projeto bem estruturado e documentado para facilitar a manutenção e o trabalho em equipe.

Mostramos como a ferramenta Swagger é uma ótima opção para documentar APIs de forma clara e intuitiva, permitindo que os desenvolvedores possam entender rapidamente a estrutura e a utilização dos endpoints disponíveis.

Espero que tenha gostado e que esse conteúdo tenha te ajudado de alguma forma. Como sempre, estamos em constante aprendizado. Até a próxima! ♥

Os padrões de commits são importantes para garantir a qualidade e clareza da documentação do histórico de desenvolvimento do seu projeto.

Eles orientam a escrita das mensagens de commit no controle de versão, assegurando a consistência nas informações registradas. Em equipes grandes ou em projetos de longa duração, o uso desses padrões de commits se torna ainda mais valioso, pois ajuda a manter a facilidade de compreensão dos commits e a qualidade da documentação ao longo do tempo.

Tipos e Descrição​

feat​

O tipo “feat” é usado para indicar que uma nova funcionalidade foi adicionada ao código.

• Pode incluir novos recursos, novas funcionalidades, novos componentes, etc;
• Deve incluir uma descrição precisa da funcionalidade adicionada.

fix​

O tipo “fix” é usado para indicar que algo que estava quebrado foi corrigido.

• Deve incluir uma descrição precisa do problema que foi corrigido.

style​

O tipo “style” é usado para commitar uma alteração que modifica a formatação ou estilo do código, sem afetar sua funcionalidade.

• Altera a formatação ou estilo do código, sem afetar sua funcionalidade;
• Pode incluir ajustes na indentação, no uso de espaços em branco, no formato de variáveis e funções, etc.

refactor​

O tipo “refactor” é usado para commitar uma alteração que refatora o código existente, sem adicionar novas features ou corrigir bugs.

Refatorar o código significa reestruturá-lo para torná-lo mais eficiente, legível ou fácil de manter, sem mudar sua funcionalidade básica.

perf​

O tipo “perf” é usado para commitar uma alteração que melhora o desempenho do código, sem adicionar novas features ou corrigir bugs.

• Pode incluir ajustes para tornar o código mais rápido, usar menos recursos ou melhorar a escalabilidade.

test​

O tipo “test” é usado para commitar alterações durante a cobertura de testes, ou adicionar novos testes ao código.

• Pode incluir a criação ou modificação de testes unitários, de integração ou de aceitação;
• Deve incluir uma descrição precisa da mudança realizada durante o teste.

docs​

O tipo “docs” é usado para commitar alterações em documentação do código.

• Inclui comentários, arquivos de documentação, tutoriais, manuais etc.

chore​

O tipo “chore” é usado para commitar mudanças que não são diretamente relacionadas ao desenvolvimento de novas funcionalidades ou correções de bugs.

Em vez disso, são mudanças de tarefas rotineiras ou manutenção que são importantes para o projeto, mas que não possui impacto direto na funcionalidade do código. Isso inclui:

• Atualização de dependências;
• Configuração de build ou pipeline de CI/CD;
• Melhorias no processo de desenvolvimento ou na estrutura do projeto;
• Adição ou mudança em script de build, que não afeta o código de produção.

build​

O tipo “build” é usado para commitar alterações que afetam o processo de build do projeto, como configurações de compilação, dependências ou tarefas de automatização. Isso inclui:

• Configurações de compilação: Mudanças nas configurações do compilador, como opções de otimização, flags de compilação ou parâmetros de compilação;
• Atualizações nas dependências externas, frameworks ou módulos utilizados.

revert​

O tipo “revert” é usado para commitar uma operação de revert. Isso significa que você está revertendo uma alteração no código.

Suponha que você tenha feito um commit com a mensagem “feat: adicionar nova funcionalidade x”, mas depois descobre que essa feature não é mais necessária ou causa problemas no código. Você pode fazer um commit de revert para reverter as mudanças feitas na funcionalidade x.

Por que devo utilizar?​

Existem vários porquês de utilizar esse padrão de commits em seu projeto, vamos lá:

1. Padronização: uma forma padronizada de escrever mensagens de commit, o que ajuda a manter a consistência e a clareza ao longo do tempo. Isso também facilita a leitura do histórico de commits do projeto e a compreensão de quais mudanças foram feitas.
2. ** Melhora a colaboração**: quando todos na equipe usam o mesmo padrão para os commits, fica mais fácil para outros devs entenderem o que foi alterado e porquê. Isso ajuda a tornar o processo mais eficiente e menos propenso a erros.
3. Documentação: ajudam a documentar as mudanças feitas no projeto de uma forma clara e estruturada, o que pode ser útil para futuros devs que farão alguma manutenção durante o projeto.

Em resumo, o Conventional Commits ajuda a manter a organização, clareza e transparência do projeto, o que pode ser útil para a equipe e para os usuários finais.

Meu nome é Yasmin e tenho 22 anos. Sou apaixonada por tecnologia e design, e é incrível como posso unir essas duas paixões para criar ideias e desenvolver soluções.

Com minha criatividade e conhecimento, eu sempre busco novas formas de trazer ideias inovadoras para a vida.

A seguir irei compartilhar minha jornada neste mundo fascinante da tecnologia e design, e como essas paixões têm me levado a novas descobertas e realizações ❤

Desde meus 14, 15 anos, sempre tive curiosidade em descobrir como funcionavam os aplicativos e jogos por trás dos panos. Mas apenas conheci a teoria e não tive muito interesse em conhecer como funcionava a programação.

Quando terminei o ensino médio, tive a oportunidade de ingressar na faculdade para estudar Análise e Desenvolvimento de Sistemas com uma bolsa do Prouni que eu consegui! Cheia de expectativas e ansiosa para começar, no meu primeiro dia de aula me senti perdida e um pouco desorientada, pois ainda não possuía algum tipo de conhecimento prévio sobre a área.

Foi então que eu me dediquei a aprender, explorando a lógica da programação, construindo algoritmos e ampliando meus conhecimentos sobre a área a cada dia.

Meu primeiro encontro com a programação foi com a linguagem Java, e foi um momento emocionante quando escrevi meu primeiro “Hello, World!”.

No segundo semestre, tive a oportunidade de explorar o mundo da orientação a objetos, estudei com a série do Curso em Vídeo (devo minha eterna gratidão ao Guanabara!) e foi aí onde me senti encantada com o mundo da programação, me inspirou a continuar aprofundando meus conhecimentos.

Enfrentei algumas dificuldades no caminho e cheguei a pensar em desistir. Foi então que, indo para o quarto semestre, decidi trancar o curso de ADS e focar exclusivamente em Design Gráfico, pois eu já tinha uma certa experiência. Dediquei-me a aprimorar minhas habilidades através de tutoriais e praticando bastante. Isso me permitiu entrar na área e trabalhar com Design, onde tive a oportunidade de aprimorar minhas habilidades e aprender ainda mais, graças à equipe maravilhosa que tive e ao meu constante interesse em descobrir novas técnicas.

Mas a paixão pela programação nunca morreu! E depois de algum tempo, decidi voltar pra faculdade de Análise e Desenvolvimento de Sistemas, agora com mais conhecimento e dedicação.

Foi então que descobri novos aspectos que antes não tinha visto. Me apaixonei e, finalmente, me encontrei! Além disso, meu conhecimento em Design Gráfico me permitiu ver a programação com outros olhos e adquirir novas habilidades complementares.

Recebi minha primeira oportunidade de trabalhar como Desenvolvedora de Software Jr., atuando como full-stack. Atualmente faz 6 meses que estou na área, e meu dia a dia na programação é uma constante jornada de aprendizado e me sinto extremamente realizada ao desenvolver e adquirir novos conhecimentos todos os dias.

Minha jornada na programação foi cheia de altos e baixos, mas eu não me arrependo de ter escolhido esse caminho. Desde o início, eu sempre soube que a tecnologia fosse algo que me atraía.

Aprendi que é importante nunca desistir! E que mesmo com as dificuldades, é preciso persistir e seguir em frente. A programação é uma área em constante evolução e aprendizado, e é por isso que amo o que faço! A cada novo projeto, descubro novos conhecimentos e sinto uma sensação de realização, como se estivesse alcançando um novo patamar em minha jornada na programação.

Sou grata por ter a oportunidade de estar nesse mundo, e por ter tido a coragem de seguir em frente mesmo com as dificuldades. Acredito que a programação é algo que sempre estará presente na minha vida e, por isso, eu estou sempre disposta a aprender mais e a me desenvolver ainda mais como desenvolvedora.

Enfim, minha jornada na programação é uma constante busca pelo conhecimento e pelo desenvolvimento, e eu não poderia estar mais feliz e realizada com a escolha que fiz.