<![CDATA[ Tecnologia - freeCodeCamp.org ]]> https://www.freecodecamp.org/portuguese/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ Tecnologia - freeCodeCamp.org ]]> https://www.freecodecamp.org/portuguese/news/ Eleventy Wed, 06 May 2026 14:33:13 +0000 60 <![CDATA[ Consegui uma vaga como programador no Facebook – saiba como me preparei para as entrevistas ]]> https://www.freecodecamp.org/portuguese/news/consegui-uma-vaga-como-programador-no-facebook-saiba-como-me-preparei-para-as-entrevistas/ 665398d7aeb89e03d1651802 Tue, 02 Jul 2024 21:00:00 +0000 Artigo original: I just got a developer job at Facebook. Here’s how I prepped for my interviews.

Escrito por: Andyy Hope

Fiz sete entrevistas presenciais em empresas de tecnologia do Vale do Silício. Por fim, aceitei uma oferta de emprego em engenharia de software no Facebook.

Confira a seguir como me preparei para essas entrevistas e o que aprendi ao longo do caminho.

Minha jornada de anos rumo ao Vale do Silício

Quando eu fazia faculdade de Ciência da Computação na Austrália, sempre vislumbrava meu futuro como engenheiro de software no Vale do Silício.

Eu adorava a ideia de estar no centro das inovações tecnológicas, bem como de seus tropeços. Esse objetivo me manteve focado e motivado.

Larguei meu cargo de engenheiro líder de iOS em uma empresa incrível em Melbourne e voltei para minha cidade natal, Perth, para estudar. Lá, eu me preparei para o processo de entrevistas que me aguardava no Vale do Silício. Eu sabia que seria muito difícil.

Se você falar sobre o processo de entrevista técnica com engenheiros de software reunidos em uma sala, muitos serão contrários a suas práticas comuns. O maior argumento é que a resolução de algoritmos em um quadro branco não representa as tarefas diárias de um engenheiro de software.

Neste artigo, não vou entrar nesse mérito. Em vez disso, vou explorar essas diferentes práticas de entrevista da perspectiva do candidato, além de focar no que aprendi ao longo do processo.

Fazer entrevistas é uma habilidade

Durante minha preparação, eu já sabia que a entrevista seria um desafio, mas, sinceramente, não fazia ideia do nível de dificuldade até fazer a primeira.

Antes disso, usei serviços pagos e gratuitos que simulavam entrevistas de programação e whiteboarding (onde você faz os testes de programação com o auxílio de um quadro branco – em inglês, white board) por telefone com pessoas experientes em seleção. Aquelas provas práticas foram essenciais para eu me preparar para a pressão. Percebi mais tarde, no entanto, que elas representavam apenas uma fração do que era a realidade.

Não aconselho fazer entrevista para seu emprego dos sonhos sem já ter feito algumas antes — simuladas ou reais. O nervosismo pode ser avassalador e só pode ser dominado com a prática.

Assim como em muitas outras situações na vida, a prática eleva a confiança.

Os diferentes tipos de entrevista que encontrei

Se você se preparar e se sair bem nas entrevistas preliminares por telefone, vai ter a oportunidade de comparecer presencialmente para passar o dia fazendo entrevistas. Em geral, elas duram de quatro a seis horas, dependendo da empresa.

Em minha jornada até o Vale do Silício, consegui fazer sete entrevistas presenciais no total, o que me deu uma perspectiva única do panorama atual.

Normalmente, uma entrevista presencial tem três temas principais: algoritmos, design de arquitetura e comportamental (algo que estudei ao me preparar). Porém, algumas empresas parecem contrariar essa tendência ao abranger competências mais práticas.

Vou resumir cada um dos tipos que encontrei.

Entrevista sobre algoritmos

É o tipo mais comum. O entrevistador pede para que você resolva um problema em um quadro branco e avalia seus conhecimentos sobre estruturas de dados, algoritmos de ordenação, recursão e análise da complexidade de tempo/espaço, bem como reconhecimento de padrões e de casos extremos. O mais frequente é, primeiro, apresentar uma solução de força bruta e, em seguida, tentar refinar essa solução e discutir as eventuais vantagens de suas sugestões.

Durante seis semanas, todos os dias, o feijão-com-arroz da minha preparação foi resolver algoritmos em um quadro branco barato, analisar a sua complexidade temporal/espacial e tentar realmente compreender o que fazia cada linha de código.

Pessoalmente, eu adoro fazer algoritmos no quadro branco porque (em geral) não sou obrigado a me preocupar com uma sintaxe compilável, o que me permite focar só no problema em questão. Tem gente que não curte fazer algoritmo na lousa. A essas pessoas, eu diria: pratiquem consistentemente e talvez acabarão mudando de ideia.

Entrevista de design de arquitetura

É uma entrevista interessante e que subestimei demais. O entrevistador pede para desenhar (em um quadro branco, é claro) algo como um sistema de estacionamento, um chat ou um feed como o do Twitter.

O que é avaliado é como se pega um conceito geral para conceber um sistema que satisfaça todos os requisitos e restrições. Cabe ao candidato, no entanto, fazer as perguntas certas para definir os requisitos e as restrições. Essa entrevista está mais para um bate-papo com diagramas sendo desenhados e talvez até estruturação de classes. Tudo é feito em alto nível. Então, você não escreve um código realmente implementável.

Naturalmente, você deve conduzir a conversa de modo a cobrir seu conhecimento sobre como os sistemas funcionam. Se você for um engenheiro de back-end, não entrará em detalhes sobre a aplicação no client (a menos que tenha algum conhecimento prévio nessa área). Como sou engenheiro de iOS, falei sobre padrões de arquitetura, modularização de funcionalidade e padrões de design em vez de como dimensionar as extremidades da API, adicionar workers, AWS e essas coisas.

Entrevista comportamental

O entrevistador faz perguntas sobre você e sobre como lida com determinadas situações. A preparação para essa entrevista não é tão difícil quanto as outras, mas requer muita reflexão da sua parte.

As perguntas geralmente seguem essa linha:
・Como você lida com o fracasso?
・Qual é seu maior ponto fraco?
・Como você resolve um conflito?
・O que você teria feito de diferente?

Creio que seria muito difícil fazer besteira nessa parte, mas ouvi que muita gente faz. Muitos tentam disfarçar os seus defeitos como se fossem qualidades e elaboram a sua resposta conforme o que acham que o entrevistador gostaria de ouvir. Isso quando não transferem a culpa de projetos que não deram certo para outras pessoas:
・"Meu ponto fraco é que sou focado demais"
・"A culpa foi de Jerry, que passou a maior parte do projeto doente"

Entrevistadores são treinados e especializados para identificar gente problemática, sem contar que eles têm um faro apurado para conversa fiada. Então, essa etapa pode fazer sua candidatura ir por água abaixo. Basta ser sincero, mostrar paixão pelo que faz, assumir suas falhas e mostrar interesse em melhorar que tudo vai dar certo.

Adequação cultural

Normalmente, essa entrevista é feita junto com a comportamental, e visa determinar se você está de acordo com os valores da empresa. Por exemplo, o Facebook segue a cultura hacker de ser ousado e lançar novas ideias, experimentar e não ter medo de quebrar algo. Já a Airbnb quer criar um mundo onde as pessoas se sintam acolhidas em todo lugar. Por isso, buscam por gente mais hospitaleira.

Muitas big techs dão ênfase na cultura e contratam com base no alinhamento do candidato com os seus valores. Se você fizer entrevista em uma dessas empresas, é importante pesquisar antes os valores dela para encontrar experiências prévias suas que tenham a ver com ela para informar a seu entrevistador.

Programação em dupla

É uma categoria interessante, em que o candidato é colocado com outro engenheiro em frente a um computador com um ambiente de desenvolvimento semelhante ao que utilizaria no mundo real. Você recebe uma tarefa básica e uma lista de requisitos que deve completar. Conforme você termina cada tarefa, o entrevistador pede que você implemente mais funcionalidades, até o tempo acabar. É liberado usar o recurso que você quiser, como o Stack Overflow ou a documentação on-line.

Creio que muito do sucesso de um candidato nessa entrevista será determinado pela exposição dele a experiências práticas no mundo real. Ao contrário do que acontece no quadro branco, é necessário escrever código sintaticamente correto. Portanto, você deve dominar a sua linguagem e o seu ambiente para não perder muito tempo buscando resposta na internet ou na documentação.

Em meu trabalho anterior, eu escrevia código limpo enquanto trabalhava em uma tarefa, depois otimizava o código quando sentia que já estava pronto. Essa maneira de trabalhar não deu certo nesse tipo de entrevista. Acabei me encurralando por ter escrito um código limpo e o otimizado antes da hora, o que dificultou seu manuseio. Descobri que bastava ter feito um esboço de código e mencionado o que faria de diferente durante a produção, em vez de escrever o código de maneira limpa e otimizada.

Busca e correção de bugs

Muito do que fazemos como engenheiro de software gira em torno de encontrar e corrigir erros que nos são reportados por várias fontes. Nesse tipo de entrevista, você recebe uma lista de bugs para encontrar e corrigir, bem como identificar qualquer outro código potencialmente problemático ao longo do caminho.

Só me deparei com um caso desse tipo de entrevista. Creio que deve ser bem difícil para alguém se preparar para ela, especialmente se for para uma vaga de júnior. Cada ambiente de programação tem as suas próprias particularidades e nuances. Muito do trabalho de correção que fiz veio de experiências prévias com IDE (ambiente de desenvolvimento integrado) e frameworks que acumulei ao longo dos anos.

Teste de domínio do conhecimento

Programação é basicamente a mesma coisa na maioria das linguagens que temos atualmente. Se você sabe programação orientada a objetos em uma linguagem, é provável que esse conhecimento também valha para as outras.

No entanto, essa entrevista foca no conhecimento que não pode ser transferido entre linguagens ou frameworks. As perguntas são sobre especificidades do ambiente relacionadas a API, gestão de memória, capacidade, restrições etc.

Praticar pode ser um desafio aqui. Assim como na entrevista de localização e correção de erros, creio que muitas das respostas resultam de experiências prévias. Dependendo do nível do cargo que você se candidatar, suas respostas podem ter um peso diferente. Por exemplo, se um candidato a uma função júnior não sabe por que uma API é estruturada de certa maneira, dá para relevar. Se, contudo, um candidato a um cargo sênior não souber, aí a avaliação pode ser mais rigorosa.

Compreensão de sistemas operacionais

Dependendo da função ou da equipe para a qual você esteja sendo entrevistado, é possível que as perguntas se concentrem exclusivamente em sistemas operacionais. Nesse tipo de entrevista, o que será avaliado é sua compreensão do funcionamento interno do sistema operacional de um computador.

Confesso que, nessa, fui pego desprevenido. Até aprendi sistemas operacionais nos primeiros anos de faculdade, mas meu conhecimento sobre o assunto foi se perdendo com o passar do tempo, o que refletiu em meu desempenho.

Como você deve se preparar

Como escrevi anteriormente, fazer entrevista é uma habilidade por si só. Mesmo que você já seja um excelente programador em seu trabalho diário ou tire ótimas notas em suas provas, essas habilidades não necessariamente vão servir quando você estiver em uma salinha de entrevista. A persistência, a repetição e a consistência tanto na preparação quanto na prática da entrevista determinarão seu resultado.

Conhecimento mínimo

Se alguém me perguntasse em que área focar, eu sugeriria o seguinte:

  • Aprenda a escrever o código à mão primeiro: em papel e no quadro branco, só depois jogue o código em uma IDE para realçar a sintaxe. Isso deve se tornar um hábito para você.
  • Desenvolva um conhecimento profundo das estruturas de dados: os pontos fortes e fracos de uma em relação às outras. Descobri que implementar estruturas de dados e seus comportamentos do zero me ensinou muito mais do que aprendi com seus conceitos abstratos.
  • Entenda totalmente a notação Big O: tanto a complexidade de tempo quanto a de espaço, o que vai ser importante em perguntas sobre algoritmos e organização de dados.
  • Entenda todos os principais algoritmos de ordenação: diferenças nas complexidades de tempo/espaço podem atrapalhar sua solução ideal para o problema que busca resolver.

Quando começar?

Dependendo do seu cronograma, pode ser que você prefira começar mais cedo ou mais tarde. Muitas das empresas onde fiz entrevistas tinham um período de espera de 12 meses antes que um candidato reprovado pudesse tentar novamente. No entanto, se você já sabe que não vai estar pronto em um ano, é melhor fazer o processo logo agora e ter uma amostra de como ele é para que, quando estiver pronto, ele não seja tão assustador.

Não se preocupe! Você vai conseguir.

Recursos (em inglês)

Entrevistas simuladas

Algoritmos

Sistemas operacionais

Design de arquitetura

Comportamental

95r0mH93-K8IGlgN9pNRPj5YekDfvdLiRkhb

Se você gostou do que leu, dê uma olhada em meus outros artigos sobre desenvolvimento em iOS e Swift. Se quiser entrar em contato, me mande um tweet ou me siga no Twitter, o que vai valer meu dia.

Andyy Hope (@AndyyHope) | Twitter
Engenheiro iOS. Blogger/Palestrante de Swift & iOS

]]> <![CDATA[ MBR x GPT: qual a diferença entre uma partição MBR e uma partição GPT? [Resolvido] ]]> https://www.freecodecamp.org/portuguese/news/mbr-x-gpt-qual-a-diferenca-entre-uma-particao-mbr-e-uma-particao-gpt-resolvido/ 63f6213dc24870050d79dbff Wed, 07 Jun 2023 21:00:00 +0000 Artigo original: MBR vs GPT: What's the Difference Between an MBR Partition and a GPT Partition? [Solved]

Se você está montando um PC, podem ter perguntado a você como desejava instalar seu sistema operacional – MBR ou GPT?

As diferenças entre uma partição MBR e GPT são bastante diretas. Porém, há muitas informações básicas que o ajudarão a ter uma ideia mais clara sobre cada tipo de tabela de partição e quando você deve escolher uma em detrimento da outra.

Neste artigo, abordaremos o que é uma partição, a diferença entre uma partição MBR e GPT, se você deve atualizar de um tipo de partição para outro e muito mais.

O que é uma partição?

Uma partição é uma divisão virtual de uma unidade de disco rígido (em inglês, hard disk drive ou HDD) ou unidade de estado sólido (em inglês, solid state drive ou SSD). Cada partição pode variar em tamanho e, normalmente, cumpre uma função diferente.

Por exemplo, no Windows geralmente há uma pequena partição de recuperação e uma grande partição de sistema de arquivos denominada C:. A partição C: é o que a maioria das pessoas conhece, pois é onde você geralmente instala seus programas e armazena seus vários arquivos.

disk-management
Gerenciador de discos do Windows - Fonte

No Linux, normalmente há uma partição raiz (/), uma para swap – que ajuda no gerenciamento de memória – e uma grande partição /home. A partição /home é semelhante à partição C: no Windows, pois é onde você instala a maioria dos seus programas e armazena arquivos.

yCyXA
GParted no Linux – Fonte

Se você comprou seu computador em uma loja e o sistema operacional já está instalado, o fabricante já cuidou das partições. Você não precisa se preocupar com elas, a menos que queira fazer algo como dual-boot de Windows e Linux a partir do mesmo HDD ou SDD.

Mesmo que você mesmo esteja instalando o sistema operacional, na maioria das vezes, o instalador vai sugerir partições e tamanhos de partição padrão.

Novamente, você geralmente não precisa fazer nenhum ajuste.

Agora que você tem uma visão geral de alto nível do que é uma partição, podemos nos aprofundar nas diferenças entre as partições MBR e GPT.

Observação: usarei o termo "unidade" para me referir a HDDs e SSDs de agora em diante.

Uma visão geral de partições MBR e GPT

Antes que uma unidade possa ser dividida em partições individuais, ela precisa ser configurada para usar um esquema ou tabela de partição específica.

Uma tabela de partições informa ao sistema operacional como as partições e os dados na unidade são organizados. Por exemplo, as capturas de tela acima mostram as tabelas de partição na unidade e cada partição individual é mostrada como um bloco retangular.

Existem dois tipos principais de tabelas de partição: MBR e GPT.

MBR significa Master Boot Record (em português, registro mestre de inicialização) e é um pouco de espaço reservado no início da unidade que contém as informações sobre como as partições são organizadas. O MBR também contém o código para iniciar o sistema operacional e, às vezes, é chamado de Boot Loader (em português, carregador de inicialização).

GPT é uma abreviação de GUID Partition Table (em português, tabela de partição GUID) e é um padrão mais recente que está substituindo lentamente o MBR.

Ao contrário de uma tabela de partição MBR, o GPT armazena os dados sobre como todas as partições são organizadas e como inicializar o sistema operacional em toda a unidade. Desse modo, se uma partição for apagada ou corrompida, ainda será possível inicializar e recuperar alguns dos dados.

Se você comprou seu computador nos últimos cinco anos, é muito provável que ele esteja usando tabelas de partição GPT em vez das tabelas MBR mais antigas.

Diferenças entre as partições MBR e GPT

Existem várias diferenças entre as partições MBR e GPT, mas abordaremos algumas das principais aqui.

Primeiro, a capacidade máxima das tabelas de partição MBR é de apenas 2 terabytes. Você pode usar uma unidade com mais de 2 terabytes com MBR, mas apenas os primeiros 2 terabytes da unidade serão usados. O restante do armazenamento na unidade será desperdiçado.

Por outro lado, as tabelas de partição GPT oferecem uma capacidade máxima de 9,7 zetabytes. 1 zetabyte é cerca de 1 bilhão de terabytes. Então, é improvável que você fique sem espaço tão cedo.

Em seguida, as tabelas de partição MBR podem ter no máximo 4 partições separadas. No entanto, uma dessas partições pode ser configurada para ser uma partição estendida, que é uma partição que pode ser dividida em 23 partições adicionais. Portanto, o número máximo absoluto de partições que uma tabela de partições MBR pode ter é de 26 partições.

As tabelas de partição GPT permitem até 128 partições separadas, o que é mais do que suficiente para a maioria das aplicações do mundo real.

Como o MBR é mais antigo, geralmente vem junto com sistemas BIOS legados mais antigos, enquanto o GPT é encontrado em sistemas UEFI mais recentes. Isso significa que as partições MBR têm melhor compatibilidade de software e hardware, embora o GPT esteja começando a alcançá-lo.

Daremos uma breve olhada no BIOS legado e no UEFI um pouco mais adiante neste artigo.

Você deve atualizar de MBR para GPT?

Se uma de suas unidades estiver usando uma tabela de partição MBR, você pode estar se perguntando se deve atualizar para o padrão GPT mais recente.

Resumindo, provavelmente, não. Como diz o ditado, se não está quebrado, não conserte.

É muito fácil arruinar o setor MBR da unidade, impossibilitando a inicialização novamente. Você precisará criar uma unidade USB de recuperação com Windows ou Linux e tentar reparar o MBR ou limpar completamente a unidade e reinstalar o sistema operacional.

Falo isso por experiência própria: não vale a dor de cabeça.

Dito isso, há alguns casos em que você pode considerar atualizar de MBR para GPT.

Por exemplo, talvez você queira atualizar sua unidade para uma com mais de 2 terabytes ou precise de mais de 26 partições. Mesmo nesses casos, você precisará certificar-se de que seu hardware pode suportar uma tabela de partições GPT e um BIOS UEFI.

Se você fez a pesquisa e tem certeza de que deseja passar a usar o GPT, certifique-se de ter um backup de sua unidade e de todos os dados importantes. Na pior das hipóteses, você poderá reverter sem precisar reinstalar tudo e começar do zero.

Uma visão geral do BIOS

Eu mencionei o BIOS algumas vezes antes. Embora esteja um pouco fora do escopo deste artigo, é necessário um entendimento básico do BIOS para entender uma das diferenças principais entre as partições MBR e GPT.

BIOS significa Basic Input/Output System (em português, Sistema Básico de Entrada/Saída) e é o software armazenado em um chip na placa-mãe de um computador que é executado quando você o liga pela primeira vez.

xThDu5d
Um chip de BIOS em uma placa-mãe da Gigabyte – Fonte

O BIOS faz coisas como configurar o teclado, mouse e outros hardwares, definir o relógio do sistema, testar a memória e assim por diante. Em seguida, ele procura uma unidade e inicia o boot loader (carregador de inicialização) na unidade, que é uma tabela de partição MBR ou GPT.

Normalmente, quando você liga o computador pela primeira vez, verá um logotipo do fabricante do computador ou da placa-mãe.

Muitas vezes, há uma mensagem abaixo do logotipo dizendo qual tecla pressionar para configurar o BIOS do computador. Essa tecla geralmente é Delete (ou Del), Escape (ou ESC) ou F2, embora varie de acordo com o fabricante.

Conforme mencionado anteriormente, existem dois tipos principais de BIOS – BIOS legado e BIOS UEFI:

windows-boot-screen-bios
Uma tela de configuração de BIOS legado – Fonte
29143-uefiasus
Uma tela de configuração de BIOS UEFI – Fonte

BIOS legados são mais antigos e são totalmente controlados por teclado. Eles geralmente são simples em termos de interface do usuário e têm uma cor de fundo preta ou azul semelhante à tela preta/azul da morte do Windows.

UEFI significa Unified Extensible Firmware Interface (em português, Interface Unificada de Firmware Extensível) e pode ser considerado um tipo mais recente de BIOS. O UEFI geralmente inclui gráficos para mostrar a velocidade da ventoinha, temperatura e velocidades de clock da CPU e, às vezes, pode ser controlado com um mouse ou trackpad.

BIOS de MBR e GPT

Como o MBR é um padrão mais antigo, ele é emparelhado com os sistemas BIOS legados (e o BIOS legado só pode acessar unidades com uma partição MBR). Isso não é necessariamente ruim, pois o suporte para BIOS legado é melhor.

Novamente, contudo, uma das limitações mais óbvias das partições MBR é que ela só pode lidar com unidades de até 2 terabytes.

O padrão GPT mais recente é emparelhado com sistemas BIOS UEFI. Embora o suporte para GPT e BIOS UEFI não seja tão bom quanto MBR/BIOS legado, ele está ganhando terreno.

Mais fabricantes estão migrando para BIOS UEFI, que, por sua vez, exige que as unidades usem o formato GPT mais recente. No entanto, o requisito para unidades formatadas em GPT vem com a vantagem de uma capacidade muito maior e até 128 partições.

Para encerrar

Embora entender a diferença entre as partições MBR e GPT seja um pouco como descascar uma cebola, espero que você tenha passado por isso sem chorar.

Se tudo o que você deseja é uma referência rápida para as diferenças entre as partições MBR e GPT, aqui está uma tabela útil:

MBRGPT
Capacidade máxima2TB9,7ZB (~9,7 bilhões de terabytes)
Máximo de partições26128
Local dos dados de inicial./partiçãoNo início da unidadePor toda a unidade
Tipo de BIOSBIOS legadoUEFI

Não se esqueça de não ser como o meu eu mais jovem – certifique-se de ter um backup antes de mexer nas partições. Na verdade, faça dois backups. 🙂

]]> <![CDATA[ Aqui estão mais de 850 cursos da Ivy League que podes fazer agora gratuitamente ]]> Tradução para o português europeu. As oito universidades da Ivy League [https://pt.wikipedia.org/wiki/Ivy_League] estão entre as mais prestigiadas do mundo. Estas são Harvard, Yale, Princeton, Columbia, Cornell, Dartmouth, Brown e a Universidade da Pennsylvania. Em 2023, as oito escolas da Ivy League ficaram no top 20 da classificação de ]]> https://www.freecodecamp.org/portuguese/news/aqui-estao-mais-de-850-cursos-da-ivy-league-que-podes-fazer-agora-gratuitamente/ 63e60dec1c2d3d0521410b19 Wed, 26 Apr 2023 21:00:00 +0000 Artigo original: Here Are 850+ Ivy League Courses You Can Take Right Now for Free

Tradução para o português europeu.

As oito universidades da Ivy League estão entre as mais prestigiadas do mundo. Estas são Harvard, Yale, Princeton, Columbia, Cornell, Dartmouth, Brown e a Universidade da Pennsylvania.

Em 2023, as oito escolas da Ivy League ficaram no top 20 da classificação de universidades nacionais do U.S. News & World Report (link em inglês). Como podes imaginar, estas instituições são altamente seletivas e é muito difícil de ingressar nelas.

A boa notícia é que estas oferecem cursos online gratuitos. Neste artigo, utilizei a base de dados do Class Central para compilar estes cursos para ti. No total, as escolas da Ivy League oferecem atualmente mais de 850 cursos, que, combinados, contam com 40 milhões de inscrições.

cc-homepage-new-year-2022-2023-final-2-1
A base de dados do Class Central tem mais de 100 mil cursos online.

Na semana passada, partilhei uma lista de certificados gratuitos de programação (link em inglês). Acontece que uma das universidades da Ivy League também criou essa lista – a universidade de Harvard, que oferece certificados gratuitos em Ciências da Computação, Python, Inteligência Artificial... podes encontrar todos os detalhes aqui: 1000+ Free Developer Certifications (link em inglês).

Para tornar a compilação abaixo um pouco mais fácil de navegar, dividi-a de acordo com o tema do curso. Podes clicar num tema e saltar diretamente para os cursos correspondentes:

Também configurei uma coleção no Class Central para cursos online da Ivy League (link em inglês). Essa coleção é atualizada automaticamente à medida que são lançados novos cursos. Se gostarias de receber notificações sobre novos cursos da Ivy League, podes "seguir" a coleção.

Observa que compreender como examinar gratuitamente um curso em plataformas como o Coursera pode ser um pouco confuso. Por isso, eu e meu colega Pat escrevemos um guia dedicado ao assunto: Como fazer a inscrição em cursos do Coursera de modo gratuito (link em inglês).

Sem mais demoras, aqui estão todos os cursos online gratuitos oferecidos pelas instituições da Ivy League.

Ciências da Computação (50)

Programação (22)

Ciências da Informação (23)

Matemática (17)

Engenharia (20)

Humanidades (97)

Negócios (90)

Ciência (49)

Arte e Design (18)

Ciências Sociais (86)

Saúde e Medicina (353)

Educação e Ensino (23)

Desenvolvimento Pessoal (16)

]]> <![CDATA[ Os 8 melhores sites de desafios de código para ajudar a aperfeiçoar suas habilidades ]]> https://www.freecodecamp.org/portuguese/news/os-8-melhores-sites-de-desafios-de-codigo-para-ajudar-a-aperfeicoar-suas-habilidades/ 63679e0d7e77d305f28da261 Sun, 09 Apr 2023 21:00:00 +0000 Artigo original: The 8 Best Coding Challenge Websites to Help You Level Up Your Skills in 2020

Apesar da menor taxa de desemprego em décadas, analistas estimaram que contratações no setor de tecnologia continuem crescendo de maneira estável durante a década de 2020 a 2030.

Essa é uma ótima notícia para recém-formados em ciência da computação e desenvolvedores que atualmente trabalham na área, mas não significa que engenheiros ambiciosos podem ser complacentes.

Embora haja, provavelmente, oportunidades de crescimento no mercado em geral, ainda há mudanças significativas acontecendo o tempo todo e um senso de urgência para acompanhar as últimas tendências.

Hoje, existem mais tipos de funções técnicas do que nunca e uma contínua proliferação de novas linguagens,  frameworks e tecnologias. Colaboradores de áreas técnicas que desejam estar à frente devem testar e refinar constantemente suas habilidades.

Para isso, reuni a lista de plataformas abaixo nas quais você pode aprimorar suas habilidades para várias funções, da ciência de dados ao devops.

1. freeCodeCamp

Links úteis: Site | Fórum

freecodecamp-hero

Vamos começar com o freeCodeCamp, que é um ótimo site para quem está iniciando em programação. Ele oferece diversos recursos para aprender sintaxe, praticar código, criar projetos e se preparar para entrevistas.

Eles não têm tantos desafios interativos de código quanto outros sites, mas oferecem alguns desafios divertidos e preparação para entrevistas para os iniciantes em JavaScript.

Ótimo para

Iniciantes que estão aprendendo a programar pela primeira vez. É um ótimo lugar para se aprender HTML, CSS e JavaScript de uma modo divertido e interativo.

Preço/Conteúdo premium

O freeCodeCamp é totalmente gratuito.

2. Coderbyte

Links úteis: Website| Blog | Dev.to | Desafios gratuitos | Premium

coderbyte-hero

Minha plataforma, a Coderbyte, oferece mais de 300 desafios de código para você resolver em um editor on-line, utilizando 10 linguagens de programação diferentes. Você pode acessar soluções oficiais, mais de 1,5 milhões de soluções de usuários e ler artigos sobre como resolver os desafios de maneira eficiente.

A Coderbyte é recomendada pelos principais bootcamps de código (em inglês) e empresas, por ter uma coleção de desafios preparatórios para entrevistas.

Ótimo para

A Coderbyte é perfeita para pessoas que estão entre as fases iniciais e intermediárias de suas carreiras e se preparando para entrevistas. Contém, também, uma biblioteca de desafios mais difíceis para aqueles que gostam de resolver desafios de código por diversão, mas esse não é um site voltado para programadores competitivos.

Preço/Conteúdo premium

Há diversos de desafios gratuitos na Coderbyte, centenas de desafios premium e mais de 1 milhão de soluções de usuário disponíveis para membros.

3. LeetCode

Links úteis: Site | Discussão | Desafios gratuitos | Premium

leetcode-hero

A LeetCode tem, atualmente, uma das melhores coleções de desafios de código on-line. Os tópicos que abordam exigem conhecimento de estrutura de dados como árvores binárias, heaps,  listas encadeadas, entre outros. Por isso, seus desafios são um pouco mais avançados do que os de outros sites. Eles, porém, são ótimos desafios, se usados como preparação para entrevistas de engenharia de software.

Eles também têm uma seção de entrevista simulada que é especifica para preparação para entrevistas de emprego. Eles também organizam seu próprio concurso de código e possuem um ótimo fórum de discussão onde as pessoas falam sobre perguntas feitas em entrevistas, empregos, remuneração e outros tópicos relacionados à engenharia.

Ótimo para

A LeetCode é ótima para programadores intermediários a avançados. Talvez não seja adequada para iniciantes que ainda não sabem como escrever loops básicos, mas, após aprender os fundamentos, é um ótimo site para se praticar programação.

Preço/Conteúdo premium

Existem desafios gratuitos disponíveis na LeetCode e, também, uma assinatura premium, que dá acesso a mais desafios e outros recursos da plataforma.

4. Edabit

Links úteis: Site | Blog | Desafios

edabit-hero

Essa é a primeira vez que o Edabit aparece na nossa lista! Ele cresceu em popularidade em anos passados e os desenvolvedores parecem realmente gostar dos desafios. Oferece uma grande coleção, com mais de 4 mil desafios, que podem ser solucionados on-line em diversas linguagens.

Atualmente, o site oferece apenas desafios com interação de código on-line — não há fóruns de discussão, artigos, soluções de usuários ou entrevistas simuladas como em outros sites — mas, com o tempo, eles podem adicionar algumas dessas opções.

Ótimo para

O Edabit é ótimo para iniciantes que buscam praticar suas habilidades diariamente resolvendo pequenos desafios. Depois de atingir o nível intermediário, outros sites oferecem desafios mais difíceis e mais conteúdos voltados para programação competitiva e entrevistas de emprego.

Preço/Conteúdo premium

Todos os desafios no Edabit são gratuitos e não há opção premium.

5. Codewars

Links úteis: Site | Blog | Desafios gratuitos | Premium

codewars-hero

O Codewars oferece uma grande coleção de desafios de código enviados e editados por sua própria comunidade. Você pode solucionar os desafios on-line no editor do site usando mais de 20 linguagens de programação. Pode, também, visualizar a discussão de cada desafio, assim como as soluções dos usuários. Além disso, você pode ganhar pontos e subir no ranking resolvendo os desafios.

Ótimo para

O Codewars é ótimo para pessoas nas fases iniciante e intermediária. Os desafios são criados pela comunidade então você verá diferentes tipos de desafios de código.

Preço/Conteúdo premium

Eles oferecem todos os desafios criados pela comunidade de maneira gratuita e a assinatura premium dá acesso a alguns recursos interessantes da plataforma.

6. HackerRank

Links úteis: Site | Blog | Desafios

hackerrank-hero

O HackerRank tem uma vasta coleção de desafios de código orientados para algoritmos e estrutura de dados, junto com material de preparação para entrevistas, um fórum de discussão para cada desafio e uma lista das principais soluções de usuário. Eles têm desafios para outros tópicos, como programação funcional, IA, Shell, SQL e muito mais.

Ótimo para

O HackerRank é ótimo para programadores intermediários a avançados que já aprenderam o básico de uma linguagem e estão prontos para solucionar problemas mais complicados. Os desafios são escritos com notação matemática e, às vezes, podem ser um pouco confusos. Por essa razão, pode não ser bom para desenvolvedores iniciantes.

Preço/Conteúdo premium

Todos os desafios no HackerRank são gratuitos e não há opção premium.

7. TopCoder

Links úteis: Site | Blog | Desafios

topcoder-hero

A TopCoder é uma das plataformas originais de programação competitiva on-line. Fornece uma lista de desafios de algoritmos de competições passadas, que você pode completar on-line por conta própria usando o editor de código do site.

Suas Single Round Matches (ou em português, "partidas de rodada única") são oferecidas algumas vezes por mês em um horário específico, onde você compete contra outras pessoas para solucionar os desafios. Aqui estão alguns tópicos que seus desafios podem abordar.

Além de resolver desafios on-line por diversão, eles oferecem competições patrocinadas, onde você pode ganhar prêmios por escrever a melhor solução.

Ótimo para

A TopCoder é mais indicada para programadores avançados, que estão confortáveis com a resolução de desafios algorítmicos que lidam com tópicos avançados, como busca de grafos e a teoria dos números.

Preço/Conteúdo premium

Todos os desafios na TopCoder são gratuitos e não há opção premium.

8. Codeforces

Links úteis: Site | Grupos de discussão | Desafios

codeforces-hero

A Codeforces é, hoje, um dos principais sites de programação competitiva (há alguns anos, a TopCoder era onde a maioria dos programadores competitivos passavam o tempo).

Existem alguns problemas que você pode solucionar como prática, mas não há um editor on-line. Em vez disso, você escreve sua solução em seu próprio editor e, depois, faz o upload para o sistema deles, onde eles testarão o seu código em um conjunto de casos de testes.

Eles também costumam realizar concursos, nos quais participam os melhores programadores competitivos.

Ótimo para

Programadores avançados e competitivos que realmente gostam de resolver desafios difíceis de algoritmos.

Preço / Conteúdo premium

Todos os desafios na Codeforces são gratuitos e não há opção premium.

]]> <![CDATA[ Por que a raiz de um domínio não pode ser um CNAME — e outras definições sobre o DNS ]]> https://www.freecodecamp.org/portuguese/news/por-que-a-raiz-de-um-dominio-nao-pode-ser-um-cname-e-outras-definicoes-sobre-o-dns/ 63874c69d7295905e93497e5 Tue, 03 Jan 2023 21:00:00 +0000 Artigo original: Why a domain’s root can’t be a CNAME — and other tidbits about the DNS

Este artigo usará a pergunta acima para explorar DNS, dig, registros A, registros CNAME e registros ALIAS/ANAME da perspectiva de um iniciante. Vamos começar.

Primeiro, alguns conceitos

  • Domain Name System (DNS): o sistema geral para converter um nome de domínio inteligível para humanos (como "example.com") em um endereço IP (93.184.216.34). O endereço IP é de um servidor (geralmente, um servidor da web) onde são armazenados os arquivos necessários para exibir uma página da web.
  • Servidor DNS (também conhecido como servidor de nomes): usa o software do DNS para armazenar informações sobre endereços de domínio. Existem vários níveis — aqueles pertencentes a cada provedor de serviços de internet, root (13 no total em todo o mundo), domínios de primeiro nível (em inglês, "TLD" – por exemplo, ".com") e servidores DNS de nível de domínio.
  • Nome de domínio: o domínio (example) combinado com o TLD (.com). O termo 'domínio' é frequentemente usado como sinônimo do nome de domínio, embora sejam diferentes. Quando você compra um "domínio" de uma empresa de registro ou revendedor, você compra os direitos de um nome de domínio específico (como "example.com") e quaisquer subdomínios que desejar criar (meu-site.example.com, mail.example.com etc.).

Fluxo de consulta de alto nível

O fluxo de alto nível do que acontece quando você digita "example.com" em seu navegador pode ser simplificado para remover os saltos para os servidores ISP, root e DNS de TLDs, conforme vemos abaixo:

-Yu9MR65z19xx2TDl-6phT7soy3g3KNgjArX
Simplificação do fluxo de uma requisição DNS. Mais detalhes podem ser consultados aqui (texto em inglês).

Um domínio normalmente tem dois ou mais servidores de nome, contendo registros relacionados ao nome de domínio (como "example.com").

Muitos tipos de registros podem ser armazenados, a maioria dos quais pode ter várias entradas por tipo:

  • A: Registros de endereço que mapeiam o nome de domínio para um endereço IP
  • CNAME: Registro de Nome Canônico. Usado para apelidar um nome de domínio (ou nome de subdomínio) para outro. Veremos isso em mais detalhes posteriormente.
  • MX: registros do Mail eXchange que informam aos agentes de entrega de e-mail onde eles devem entregar seu e-mail
  • TXT: registros de texto flexíveis, para armazenar strings para uma variedade de usos
  • SOA: Registro Singular de Início de Autoridade mantido no nível superior do domínio. Contém informações específicas necessárias sobre o domínio, como por exemplo, seu servidor de nomes principal

Quando seu dispositivo envia uma consulta que chega a um servidor de nomes, o servidor procura no nó de registro do domínio um registro A e o endereço IP armazenado associado (example.com: 93.184.216.34). Esse endereço é, então, retornado ao dispositivo para ser usado para enviar uma solicitação ao servidor da web correto para recuperar a página da web ou o recurso solicitado.

Usando o 'dig'

dig (explorador de informações de domínio – do inglês Domain Information Groper) é uma ferramenta de linha de comando para consultar servidores DNS. Esse comando geralmente é usado para solução de problemas ou, como agora, para entender mais sobre a configuração de um sistema.

$ dig example.com resulta em uma resposta longa impressa no terminal, cuja saída padrão é detalhada aqui (texto em inglês). Dela, temos interesse apenas em ver a SEÇÃO DE RESPOSTAS(do inglês, ANSWER SECTION).

;; ANSWER SECTION:
example.com.       72703      IN     A       93.184.216.34

Podemos ver que example.com retorna um registro A de 93.184.216.34. Às vezes, os domínios terão mais de um registro A, se mais de um servidor da web puder fornecer as informações necessárias.

Tem mais! Se tentarmos alguns outros exemplos, logo veremos que outro registro comum aparece: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION:
www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net.
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Usar o sinalizador +short nos permite ver claramente o caminho formado:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net.
e11316.a.akamaiedge.net.
23.217.6.192

CNAME

Um registro CNAME permite que um nome de domínio seja usado como um apelido para outro domínio canônico (verdadeiro).

Quando o servidor DNS retorna um registro CNAME, ele não o retorna ao client. Em vez disso, ele procurará novamente o nome de domínio retornado e, por sua vez, retornará o endereço IP do registro A. Essa cadeia pode continuar com muitos níveis de CNAME profundos, mas sofre pequenos impactos de desempenho de várias pesquisas antes do armazenamento em cache.

Um exemplo simples disso pode ser se você tiver um servidor onde guarda todas as suas fotos. Você pode acessá-lo normalmente através de photos.example.com. No entanto, você também pode querer permitir o acesso via photographs.example.com. Uma maneira de tornar isso possível é adicionar um registro CNAME que aponte photographs para photos. Isso significa que, quando alguém visitar photographs.example.com, receberá o mesmo conteúdo que photos.example.com.

Usando a consulta $ dig photography.example.com, veríamos:

photographs.example.com    IN   CNAME photos.example.com
photos.example.com         IN   A     xx.xxx.x.xxx

É importante observar que o CNAME é aquela parte do lado direito. O lado esquerdo é o nome do apelido ou rótulo.

Outro uso comum é para o subdomínio www. Depois de comprar example.com, você provavelmente também desejará que os usuários que digitem www.example.com vejam o mesmo conteúdo.

Vale a pena notar aqui que example.com pode ser chamado de ápice, raiz ou nome de domínio puro.

Uma opção seria configurar outro registro A, apontando para o mesmo endereço IP de example.com. Isso é totalmente válido e é o que o site real example.com faz, mas não escala bem. O que acontece se você precisar atualizar o endereço IP para o qual example.com aponta? Você também precisaria atualizá-lo para o subdomínio www e qualquer outro que possa usar.

Se um registro CNAME foi usado como apelido para www.example.com para apontar para example.com, apenas o domínio raiz teria que ser atualizado, já que todos os outros nós apontam para ele.

Limitações do CNAME

Na época em que os padrões de DNS foram escritos, algumas regras foram estabelecidas para reger seu uso. RFC 1912 e RFC 2181 estabelecem que:

  • Os registros SOA e NS são obrigatórios no domínio raiz
  • Os registros CNAME só podem existir como registros únicos e não podem ser combinados com nenhum outro registro de recurso (com exceção dos registros DNSSEC SIG, NXT e KEY RR)

Isso exclui um CNAME de ser usado no domínio raiz, pois isso faria com que as duas regras se contradissessem.

O importante aqui é que se trata de uma limitação contratual, não técnica. É possível usar um CNAME na raiz, mas pode resultar em erros inesperados, pois está quebrando o contrato de comportamento esperado.

Um exemplo disso é relatado pela Cloudflare, descrevendo problemas que eles encontraram com os servidores de e-mail do Microsoft Exchange depois de usar um CNAME em seu domínio raiz:

Os domínios geralmente designam os servidores que lidam com seus e-mails por meio do que é conhecido como registro MX. O problema era que os servidores Exchange… podiam pegar o CNAME no registro raiz e não respeitar adequadamente o CNAME definido no registro MX. Você não pode realmente culpar o Exchange. Eles estavam operando sob as suposições estabelecidas pela especificação do DNS.

Aqui, você vê a desvantagem que pode aparecer em vários softwares de servidor ou bibliotecas. Como existe um padrão para que um CNAME seja o único registro em um nó, nenhum outro registro é procurado. Todos os outros registros serão ignorados silenciosamente, sem aviso ou mensagens de erro. Mesmo que um registro MX tenha sido definido para receber e-mail, o MX será ignorado como se não existisse porque o CNAME é avaliado primeiro. O mesmo é verdadeiro se houvesse um registro A: o CNAME teria precedência e o registro A não seria lido.

A internet moderna

Então, por que isso é um problema? Por que você desejaria usar um CNAME para seu domínio raiz? Certamente, esse é o fim do caminho ao procurar o endereço IP do servidor da web que hospeda seu conteúdo?

No cenário moderno da internet, esse não é mais o caso. O mundo é muito diferente de quando os padrões de DNS foram escritos.

Você pode optar por usar um provedor de plataforma como serviço (do inglês, PaaS), como o Heroku, e armazenar conteúdo em seus servidores da web. Você controla o conteúdo, mas não a infraestrutura. O provedor de PaaS faz o trabalho pesado da manutenção da rede. Eles normalmente fornecem um URL (`my-app.herokuapp.com`) que é um subdomínio de seu domínio raiz. Você pode visualizar os endereços IP dos servidores da web em que seu conteúdo está. Eles, no entanto, estão totalmente sob o controle do provedor de PaaS e serão alterados sem aviso prévio.

A escala e a frequência das alterações de back-end feitas pelo provedor de PaaS podem dificultar a manutenção do registro A do domínio raiz apontando para um único endereço IP. Idealmente, você gostaria de fazer isso:

example.com      IN   CNAME    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.example.com      IN   CNAME    my-app.herokuapp.com.
www.example.com  IN   CNAME    my-app.herokuapp.com.

para permitir que o Heroku (ou seu provedor de host escolhido) gerencie a atualização do registro A para a qual o CNAME aponta sem nenhuma alteração feita por você. No entanto, como sabemos agora, isso quebra a especificação do DNS e, portanto, é uma péssima ideia.

É possível simplesmente implementar um redirecionamento 301/302 de example.com para www.example.com. Porém, essa instrução ocorre no servidor da web (portanto, ainda tem o problema de precisar usar um registro A fixo no DNS para apontar para esse servidor da web) ou um redirecionamento de provedor de DNS personalizado (que sofre complicações com HTTPS).

Isso também tem o efeito colateral de alterar o domínio que você vê na barra de URL, o que você pode não querer. Este método destina-se a quando seu site foi movido permanentemente ou quando você está tentando preservar as classificações de SEO, em vez de resolver o problema de apontar para um back-end de mudança complexo de maneira escalável.

A solução

Vários provedores de DNS já desenvolveram soluções personalizadas para contornar esse problema, incluindo:

  • ALIAS em DNSimple
  • ANAME em DNS Made Easy
  • ANAME em easyDNS
  • CNAME (virtual) em CloudFlare

Esses são todos os tipos de registro virtual que fornecem comportamento semelhante ao CNAME, sem nenhuma das desvantagens. A implementação exata pode diferir, mas, em um alto nível, quando o servidor DNS vê um desses tipos de registro virtual, ele age como um resolvedor de DNS. Ele segue a cadeia criada pelo apelido até resolver em um registro (ou registros) A e retornar esses registros A ao servidor DNS. Isso "achata" a cadeia CNAME nos registros A retornados e é indistinguível da consulta enviada. A consulta vê apenas um registro A puro, que não quebra a especificação do DNS e não apresenta nenhuma das desvantagens de um CNAME.

Esses registros virtuais podem ficar ao lado de outros registros na raiz, sem medo de comportamentos não intencionais. Dependendo do método de resolução de DNS do provedor ao seguir a cadeia CNAME, eles também podem ter benefícios de desempenho ao armazenar em cache pesquisas anteriores.

Para uma configuração simples de DNS, configuraríamos conforme abaixo. Essa solução tem todas as vantagens da técnica de apelidar ou rotular um nome de domínio e nenhum dos riscos de usá-lo no nível raiz.

example.com      IN   ALIAS    my-app.herokuapp.com.www.example.com  IN   CNAME    my-app.herokuapp.com.

Obrigado por ler este artigo!

Como sempre, estou aberto a quaisquer correções ou tópicos adicionais.

Referências (todas em inglês)

]]> <![CDATA[ Como atualizar objetos dentro de um array JSONB com PostgreSQL ]]> https://www.freecodecamp.org/portuguese/news/como-atualizar-objetos-dentro-de-um-array-jsonb-com-postgresql/ 6351e66f191d0905ea418a97 Mon, 26 Dec 2022 21:00:00 +0000 Artigo original: How to update objects inside JSONB arrays with PostgreSQL

Escrito por: Leandro Cesquini Pereira

Como atualizar um valor específico em um array JSONB

Digamos que você decidiu armazenar dados em um banco de dados como json ou jsonb e descobriu que acaba de criar novos problemas para si mesmo que antes não existiam. Você não está sozinho.

O JSONB é uma ferramenta poderosa, mas tem um custo, pois você precisa adaptar a maneira como faz consultas (em inglês, queries) e manipula os dados.

Não é raro carregar todo o objeto JSONB na memória, transformá-lo usando sua linguagem de programação preferida e salvar o objeto novamente no banco de dados. Você, no entanto, acaba de criar um problema de gargalos de desempenho e desperdício de recursos.

Neste artigo, vamos ver como atualizar um valor específico de um objeto dentro de um array com uma consulta.

Versão resumida: a query final está no fim do artigo. Você pode conferir um exemplo no DB Fiddle para copiar, colar e testar por sua conta.

Suponha que você esteja implementando tela de clientes o armazenamento de contatos dinâmicos para cada cliente. Então, você tem a ideia de armazenar os contatos em uma coluna em JSONB, pois eles são dinâmicos. Assim, usar uma estrutura de dados não relacional faz sentido.

Em seguida, você cria uma tabela de clientes com uma coluna de contatos em JSONB e insere alguns dados nela:

gfE87Cd6J1Jg8NG-SoiqfVGz1J8JN8rC6Fnj

Bem fácil, não é? Como, no entanto, podemos atualizar um contato específico para um cliente específico? Como mudar o e-mail de Jimi ou o telefone de Janis, por exemplo?

Felizmente, o PostgreSQL é seu amigo e fornece a função jsonb_set:

jsonb_set(target jsonb, path text[], new_value jsonb[, create_missing boolean])

Dada uma coluna de jsonb, você pode definir um novo valor no caminho especificado:

NsMb3UL3fPutaYFB4ebdOGq7rFVCqjJmiJPd
Referência: funções de JSON do PostgreSQL

Os selects (seleções) acima retornarão:

[{"type": "phone", "value": "+1–202–555–0105"}, {"type": "email", "value": "jimi.hendrix@gmail.com"}]

[{"type": "email", "value": "janis.joplin@gmail.com"}]

Para alterar o e-mail de Jimi na lista de contatos, informe o caminho "1, value", que significa o segundo objeto do array (começando em 0) e a chave value (valor). Esse é o path (caminho). O mesmo se aplica para alterar o e-mail de Janis, mas seu objeto de e-mail está no índice 0.

Você deve estar pensando: eu só preciso usar jsonb_set em um statement (instrução) de atualização e pronto? Essa é a ideia, mas ainda não é o suficiente.

O problema com dados não relacionais é que eles são dinâmicos. Bem, esse é um dos motivos para se usar JSONB, mas gera um problema: veja que o objeto de e-mail de Jimi está no índice 1 e o objeto de e-mail de Janis está no índice 0 do array. Outro cliente poderia ter um array muito diferente com índices diferentes. Então, como descobrir o índice de cada tipo de contato?

A resposta é ordenar os elementos do array e obter seu índice:

KoTlVXRd73a57XhyrIfVj0QnZfqRK8KguWoZ

A query retorna 1, que é o índice do objeto email (de tipo email) dentro do array de contatos do cliente Jimi.

Agora, temos todas as peças do quebra-cabeça: sabemos como atualizar um valor em jsonb e como descobrir o índice de um objeto a ser atualizado.

O único passo que resta é a própria atualização. Juntando tudo, temos:

ysGG240RTX8t9rLeuMv4KdubaDVpzVMfjnEb

A parte mais importante dessa query é o bloco with. É um recurso poderoso, mas, para este exemplo, você pode pensar nele como um "modo de armazenar uma variável", que é o path(caminho) do contato que é necessário atualizar, o qual será dinâmico, dependendo do registro.

Deixe-me explicar um pouco sobre esta parte:

(‘{‘||index-1||’,value}’)::text[] as path

Essa parte apenas constrói path como '{1, value}', mas precisamos converter para text[], pois esse é o tipo esperado em uma função jsonb_path.

Resumindo

O JSONB é uma ferramenta excelente e valiosa para resolver muitos problemas. Tenha em mente, porém, que você também precisa consultar e atualizar esse tipo de dado. Isso traz um custo que você deve considerar ao decidir quais ferramentas escolher para usar.

Observação: essa solução surgiu de uma sessão de programação com Lucas Cegatti.

Está procurando por uma empresa criativa para implementar sua próxima ideia? Confira a LNA Systems.

]]> <![CDATA[ Um ótimo guia sobre como construir APIs RESTful com ASP.NET Core ]]> https://www.freecodecamp.org/portuguese/news/um-otimo-guia-sobre-como-construir-apis-rest-com-asp-net-core/ 62c9d1c88e388806e97fbcc5 Sun, 07 Aug 2022 18:00:00 +0000 Artigo original: An awesome guide on how to build RESTful APIs with ASP.NET Core

Este artigo vai servir como um guia passo a passo sobre como implementar APIs RESTful limpas e de fácil manutenção.

Visão geral

RESTful não é um termo novo. Refere-se a um estilo de arquitetura em que os serviços da web recebem e enviam dados de e para aplicações de client. O objetivo dessas aplicações é centralizar os dados que as diversas aplicações de client usarão.

Escolher as ferramentas certas para escrever serviços RESTful é crucial, pois precisamos nos preocupar com escalabilidade, manutenção, documentação e todos os outros aspectos relevantes. O ASP.NET Core nos oferece uma API poderosa e fácil de usar, que é ótima para atingir esses objetivos.

Neste artigo, mostrarei como escrever uma API RESTful bem estruturada para um cenário "quase" igual ao do mundo real, usando o framework ASP.NET Core. Vou detalhar padrões e estratégias comuns para simplificar o processo de desenvolvimento.

Também mostrarei como integrar estruturas e bibliotecas comuns, como Entity Framework Core e AutoMapper, para fornecer as funcionalidades necessárias.

Pré-requisitos

Espero que você tenha conhecimento dos conceitos de programação orientada a objetos.

Mesmo abordando muitos detalhes da linguagem de programação C#, recomendo que você tenha conhecimentos básicos sobre esse assunto.

Também suponho que você saiba o que é REST, como funciona o protocolo HTTP, o que são endpoints de API e o que é JSON. Aqui está um ótimo tutorial introdutório sobre o assunto (texto em inglês). O requisito final é que você entenda como funcionam os bancos de dados relacionais.

Para codificar comigo, você terá que instalar o .NET Core 2.2, assim como o Postman, a ferramenta que vou usar para testar a API. Eu recomendo que você use um editor de código como o Visual Studio Code para desenvolver a API. Escolha o editor de código de sua preferência. Se você escolher este editor de código, recomendo que instale a extensão de C# para ter um melhor realce de código.

Nota do tradutor: a versão do .NET Core 2.2 mencionada neste texto, de acordo com a Microsoft, já atingiu seu final de ciclo no momento desta tradução. A empresa recomenda utilizar o .NET 6.0 – que, acreditamos, não gerará alterações sensíveis ao resultado.

Você pode encontrar um link para o repositório da API no GitHub ao final deste artigo, para conferir o resultado final.

O escopo

Vamos escrever uma API web fictícia para um supermercado. Vamos imaginar que temos que implementar o seguinte escopo:

  • Criar um serviço RESTful que permita que aplicações de client gerenciem o catálogo de produtos do supermercado. Ele precisa expor endpoints para criar, ler, editar e excluir categorias de produtos, como laticínios e cosméticos, além de gerenciar produtos dessas categorias.
  • Para as categorias, precisamos armazenar seus nomes. Para os produtos, precisamos armazenar seus nomes, unidade de medida (por exemplo, kg para produtos medidos por peso), quantidade na embalagem (por exemplo, 10 se o produto for um pacote de biscoitos) e suas respectivas categorias.

Para simplificar o exemplo, não tratarei de produtos em estoque, envio de produtos, segurança e qualquer outra funcionalidade. O escopo fornecido é suficiente para mostrar como o ASP.NET Core funciona.

Para desenvolver esse serviço, precisamos basicamente de dois endpoints de API: um para gerenciar categorias e outro para gerenciar produtos. Em termos de comunicação por meio de JSON, podemos pensar nas respostas da seguinte forma:

Endpoint da API: /api/categories

Resposta em JSON (para solicitações GET):

{
  [
    { "id": 1, "name": "Fruits and Vegetables" },
    { "id": 2, "name": "Breads" },
    … // Outras categorias
  ]
}

Endpoint da API: /api/products

Resposta em JSON (para solicitações GET):

{
  [
    {
      "id": 1,
      "name": "Sugar",
      "quantityInPackage": 1,
      "unitOfMeasurement": "KG"
      "category": {
        "id": 3,
        "name": "Sugar"
      }
    },
    … // Outros produtos
  ]
}

Vamos começar a escrever a aplicação.

Etapa 1 — Criando a API

Em primeiro lugar, temos que criar a estrutura de pastas para o serviço da web e, em seguida, usar as ferramentas de CLI do .NET para estruturar uma API web básica. Abra o terminal ou prompt de comando (dependendo do sistema operacional que você estiver usando) e digite os seguintes comandos, em sequência:

mkdir src/Supermarket.API

cd src/Supermarket.API

dotnet new webapi

Os dois primeiros comandos simplesmente criam um novo diretório para a API e alteram o local atual para a nova pasta. O último gera um novo projeto seguindo o modelo da API web, que é o tipo de aplicação que estamos desenvolvendo. Você pode ler mais sobre esses comandos e outros modelos de projeto que você pode gerar conferindo este link.

O novo diretório agora terá a seguinte estrutura:

Visão geral da estrutura

Uma aplicação ASP.NET Core consiste em um grupo de middlewares (pequenos pedaços da aplicação anexados ao pipeline da aplicação, que manipulam solicitações e respostas) configurados na classe Startup. Se você já trabalhou com frameworks como Express.js antes, esse conceito não é novo para você.

Quando a aplicação é iniciada, o método Main, da classe Program, é chamado. Ele cria um host padrão usando a configuração de inicialização, expondo a aplicação via HTTP através de uma porta específica (por padrão, a porta 5000 para HTTP e a porta 5001 para HTTPS).

Dê uma olhada na classe ValuesController, dentro da pasta Controllers. Ela expõe métodos que serão chamados quando a API receber requisições através da rota /api/values.

Não se preocupe se você não entender alguma parte desse código. Vou detalhar cada um ao desenvolver os endpoints de API necessários. Por enquanto, basta excluir esta classe, pois não vamos usá-la.

Etapa 2 — Criando os modelos de domínio

Vou aplicar alguns conceitos de design que manterão a aplicação simples e fácil de manter.

Escrever código que possa ser entendido e mantido por você mesmo não é tão difícil, mas você deve ter em mente que trabalhará em equipe. Se você não tomar cuidado com a forma como escreve seu código, o resultado será um monstro que dará a você e seus colegas de equipe constantes dores de cabeça. Parece extremo, certo? Mas acredite, essa é a verdade.

0_Obq8C7c3EuzmJBZb
wtf — code quality measurement, criado por smitty42 e sob a licença CC-BY-ND 2.0

Vamos começar escrevendo a camada de domínio. Essa camada terá nossas classes de modelos, as classes que representarão nossos produtos e categorias, além de repositórios e interfaces de serviços. Vou explicar esses dois últimos conceitos daqui a pouco.

Dentro do diretório Supermarket.API, crie uma nova pasta chamada Domain. Dentro da nova pasta de domínio, crie outra chamada Models. O primeiro modelo que temos que adicionar a essa pasta é o Category. Inicialmente, será uma classe simples de Plain Old CLR Object (POCO) – (que pode ser traduzido como "Objeto de CLR puro e simples"). Isso significa que a classe terá apenas propriedades para descrever suas informações básicas.

A classe tem uma propriedade Id, para identificar a categoria, e uma propriedade Name. Também temos uma propriedade Products. Essa última será usada pelo Entity Framework Core, o ORM que a maioria das aplicações ASP.NET Core usa para persistir dados em um banco de dados, para mapear o relacionamento entre categorias e produtos. Também faz sentido pensar em termos de programação orientada a objetos, já que uma categoria tem muitos produtos relacionados.

Também temos que criar o modelo do produto. Na mesma pasta, adicione uma nova classe Product.

O produto também possui propriedades para o Id e o Name. Há também uma propriedade QuantityInPackage, que informa quantas unidades do produto temos em um pacote (lembre-se do exemplo dos biscoitos, do escopo da aplicação) e uma propriedade UnitOfMeasurement. Esta é representada por um tipo enum, que representa uma enumeração de possíveis unidades de medida. As duas últimas propriedades, CategoryId e Category, serão usadas pelo ORM para mapear o relacionamento entre produtos e categorias. Isso indica que um produto tem uma, e apenas uma, categoria.

Vamos definir a última parte de nossos modelos de domínio, o enum EUnitOfMeasurement.

Por convenção, enums não precisam começar com um "E" na frente de seus nomes, mas em algumas bibliotecas e frameworks você encontrará esse prefixo como uma forma de distinguir enums de interfaces e classes.

O código é realmente simples. Aqui, definimos apenas um punhado de possibilidades de unidades de medida. No entanto, em um sistema real de supermercado, você pode ter muitas outras unidades de medida e talvez um modelo separado para isso.

Observe o atributo Description aplicado a todas as possibilidades de enumeração. Um atributo é uma maneira de definir metadados sobre classes, interfaces, propriedades e outros componentes da linguagem C#. Nesse caso, vamos usá-lo para simplificar as respostas do endpoint da API do produto, mas você não precisa se preocupar com isso por enquanto. Voltaremos aqui mais tarde.

Nossos modelos básicos estão prontos para serem usados. Agora podemos começar a escrever o endpoint da API que vai gerenciar todas as categorias.

Etapa 3 — A API de categorias

Na pasta Controllers, adicione uma nova classe chamada CategoriesController.

Por convenção, todas as classes nessa pasta que terminam com o sufixo "Controller" se tornarão controllers (controladores) da nossa aplicação. Isso significa que eles vão lidar com solicitações e respostas. Você precisa herdar essa classe da classe Controller, definida no namespace Microsoft.AspNetCore.Mvc.

Um namespace consiste em um grupo de classes, interfaces, enumerações e estruturas relacionadas. Você pode pensar nisso como algo semelhante a módulos da linguagem Javascript, ou pacotes de Java (links em inglês).

O novo controlador deve responder através da rota /api/categories. Conseguimos isso adicionando o atributo Route acima do nome da classe, especificando um espaço reservado que indica que a rota deve usar o nome da classe sem o sufixo do controlador, por convenção.

Vamos começar a lidar com solicitações GET. Em primeiro lugar, quando alguém solicita dados de /api/categories via verbo GET, a API precisa retornar todas as categorias. Podemos criar um serviço de categoria para este fim.

Conceitualmente, um serviço é basicamente uma classe ou interface que define métodos para lidar com alguma lógica de negócios. É uma prática comum em muitas linguagens de programação diferentes criar serviços para lidar com a lógica de negócios, como autenticação e autorização (texto em inglês), pagamentos, fluxos de dados complexos, cache e tarefas que exigem alguma interação entre outros serviços ou modelos.

Usando serviços, podemos isolar o tratamento de solicitações e respostas da lógica real necessária para concluir as tarefas.

O serviço que vamos criar inicialmente definirá um único comportamento, ou método: um método de listagem. Esperamos que este método retorne todas as categorias existentes no banco de dados.

Para simplificar, não lidaremos com paginação ou filtragem de dados nesse caso. Escreverei um artigo no futuro mostrando como lidar facilmente com esses recursos.

Para definir um comportamento esperado para algo em C# (e em outras linguagens orientadas a objetos, como Java, por exemplo), definimos uma interface. Uma interface diz como algo deve funcionar, mas não implementa a lógica real para o comportamento. A lógica é implementada em classes que implementam a interface. Se esse conceito não estiver claro para você, não se preocupe. Você vai entender daqui a pouco.

Dentro da pasta Domain, crie um novo diretório chamado Services. Lá, adicione uma interface chamada ICategoryService. Por convenção, todas as interfaces devem começar com a letra maiúscula “I” em C#. Defina o código da interface da seguinte forma:

As implementações do método ListAsync devem retornar de forma assíncrona uma enumeração de categorias.

A classe Task, encapsulando o retorno, indica assincronia. Precisamos pensar em um método assíncrono devido ao fato de termos que esperar o banco de dados concluir alguma operação para retornar os dados. Esse processo pode demorar um pouco. Observe também o sufixo "async". É uma convenção que indica que nosso método deve ser executado de forma assíncrona.

Temos muitas convenções, certo? Eu pessoalmente gosto, porque mantém as aplicações fáceis de ler, mesmo se você for novo em uma empresa que usa a tecnologia .NET.


"- Tudo bem. Definimos essa interface, mas ela vem com nada. Como ela pode ser útil?"

Se você vem de uma linguagem como Javascript ou outra linguagem não fortemente tipada, esse conceito pode parecer estranho.

As interfaces nos permitem abstrair o comportamento desejado da implementação real. Usando um mecanismo conhecido como injeção de dependência (texto em inglês), podemos implementar essas interfaces e isolá-las de outros componentes.

Basicamente, quando você usa injeção de dependência, você define alguns comportamentos usando uma interface. Em seguida, você cria uma classe que implementa a interface. Por fim, você vincula as referências da interface à classe que criou.

" - Parece realmente confuso. Não podemos simplesmente criar uma classe que faça essas coisas para nós?"

Vamos continuar implementando nossa API e você entenderá por que usar essa abordagem.

Altere o código de CategoriesController da seguinte forma:

Eu defini uma função construtora para nosso controlador (um construtor é chamado quando uma nova instância de uma classe é criada) e ela recebe uma instância de ICategoryService. Isso significa que a instância pode ser qualquer coisa que implemente a interface de serviço. Eu armazeno esta instância em um campo privado e somente leitura _categoryService. Usaremos este campo para acessar os métodos de implementação de nosso serviço de categoria.

A propósito, o prefixo de sublinhado é outra convenção comum para denotar um campo. Esta convenção, em especial, não é recomendada pela diretriz oficial de convenção de nomenclatura do .NET, mas é uma prática muito comum como forma de evitar ter que usar a palavra-chave "this" para distinguir campos de classe de variáveis ​​locais. Eu pessoalmente acho que é muito mais fácil de ler, e muitos frameworks e bibliotecas usam essa convenção.

Abaixo do construtor, defini o método que vai tratar as requisições de /api/categories. O atributo HttpGet informa ao pipeline do ASP.NET Core para usá-lo para lidar com solicitações GET (esse atributo pode ser omitido, mas é melhor escrevê-lo para facilitar a legibilidade).

O método usa nossa instância de serviço de categoria para listar todas as categorias e, em seguida, retorna as categorias para o client. O pipeline de estrutura lida com a serialização de dados para um objeto JSON. O tipo IEnumerable<Category> informa à estrutura que queremos retornar uma enumeração de categorias, e o tipo Task, precedido pela palavra-chave async, informa ao pipeline que esse método deve ser executado de maneira assíncrona. Finalmente, quando definimos um método assíncrono, temos que usar a palavra-chave await para tarefas que podem demorar um pouco.

Ok, definimos a estrutura inicial da nossa API. Agora, é preciso realmente implementar o serviço de categorias.

Etapa 4 — Implementando o serviço das categorias

Na pasta raiz da API (a pasta Supermarket.API), crie uma pasta chamada Services. Aqui colocaremos todas as implementações de serviços. Dentro da nova pasta, adicione uma nova classe chamada CategoryService. Altere o código da seguinte forma:

É simplesmente o código básico para a implementação da interface, mas ainda não lidamos com nenhuma lógica. Vamos pensar em como o método de listagem deve funcionar.

Precisamos acessar o banco de dados e retornar todas as categorias, então precisamos retornar esses dados para o client.

Uma classe de serviço não é uma classe que deve manipular o acesso a dados. Existe um padrão chamado Padrão de Repositório (Repository Pattern), que é usado para gerenciar dados de bancos de dados.

Ao usar o Padrão de Repositório, definimos classes de repositório, que basicamente encapsulam toda a lógica para lidar com o acesso aos dados. Esses repositórios expõem métodos para listar, criar, editar e excluir objetos de um determinado modelo, da mesma forma que você pode manipular coleções. Internamente, esses métodos conversam com o banco de dados para realizar operações CRUD, isolando o acesso ao banco de dados do restante da aplicação.

Nosso serviço precisa conversar com um repositório de categorias, para obter a lista de objetos.

Conceitualmente, um serviço pode "conversar" com um ou mais repositórios ou outros serviços para realizar operações.

Pode parecer redundante criar uma outra definição para lidar com a lógica de acesso aos dados, mas você verá daqui a pouco que isolar essa lógica da classe de serviço é realmente vantajoso.

Vamos criar um repositório que será responsável por intermediar a comunicação do banco de dados como forma de persistir as categorias.

Etapa 5 — O repositório de categorias e a camada de persistência

Dentro da pasta Domain, crie um novo diretório chamado Repositories. Em seguida, adicione uma nova interface chamada ICategoryRespository. Defina a interface da seguinte forma:

O código inicial é basicamente idêntico ao código da interface de serviço.

Tendo definida a interface, podemos voltar para a classe de serviço e finalizar a implementação do método de listagem, usando uma instância de ICategoryRepository para retornar os dados.

Agora temos que implementar a lógica real do repositório de categorias. Antes de fazer isso, temos que pensar em como vamos acessar o banco de dados.

A propósito, ainda não temos um banco de dados!

Usaremos o Entity Framework Core (vou chamá-lo de EF Core para simplificar) como nosso ORM de banco de dados. Essa estrutura vem com o ASP.NET Core como seu ORM padrão e expõe uma API amigável que nos permite mapear classes de nossas aplicações para tabelas de banco de dados.

O EF Core também nos permite projetar nossa aplicação primeiro e depois gerar um banco de dados de acordo com o que definimos em nosso código. Essa técnica é chamada de código primeiro (code first). Usaremos a abordagem de código primeiro para gerar um banco de dados (neste exemplo, na verdade, usarei um banco de dados na memória, mas você poderá alterá-lo facilmente para uma instância de servidor SQL Server ou MySQL, por exemplo).

Na pasta raiz da API, crie outro diretório chamado Persistence. Este diretório terá tudo o que precisamos para acessar o banco de dados, como implementações de repositórios.

Dentro da nova pasta, crie outro diretório chamado Contexts e adicione uma nova classe chamada AppDbContext. Essa classe deve herdar DbContext, uma classe que o EF Core usa para mapear seus modelos para tabelas de banco de dados. Altere o código da seguinte maneira:

O construtor que adicionamos a essa classe é responsável por passar a configuração do banco de dados para a classe base por meio de injeção de dependência. Você verá em um momento como isso funciona.

Agora, temos que criar duas propriedades DbSet. Essas propriedades são conjuntos (coleções de objetos exclusivos) que mapeiam modelos para tabelas de banco de dados.

Além disso, temos que mapear as propriedades dos modelos para as respectivas colunas da tabela, especificando quais propriedades são chaves primárias, quais são chaves estrangeiras, os tipos de coluna etc. Podemos fazer isso substituindo o método OnModelCreating, usando um recurso chamado Fluent API (texto em inglês) para especificar o mapeamento do banco de dados. Altere a classe AppDbContext da seguinte maneira:

O código é intuitivo.

Especificamos para quais tabelas nossos modelos devem ser mapeados. Além disso, definimos as chaves primárias, usando o método HasKey, as colunas da tabela, usando o método Property, e algumas restrições como IsRequired, HasMaxLength e ValueGeneratedOnAdd, tudo com expressões lambda de um "modo fluido" (métodos de encadeamento).

Dê uma olhada no seguinte trecho de código:

builder.Entity<Category>()
       .HasMany(p => p.Products)
       .WithOne(p => p.Category)
       .HasForeignKey(p => p.CategoryId);

Aqui estamos especificando um relacionamento entre tabelas. Dizemos que uma categoria tem muitos produtos e definimos as propriedades que vão mapear esse relacionamento (Products, da classe Category, e Category, da classe Product). Também definimos a chave estrangeira (CategoryId).

Dê uma olhada neste tutorial (texto em inglês) se quiser saber como configurar relacionamentos um para um e muitos para muitos usando o EF Core, bem como usá-lo como um todo.

Há também uma configuração para propagação de dados, através do método HasData:

builder.Entity<Category>().HasData

(
  new Category { Id = 100, Name = "Fruits and Vegetables" },
  new Category { Id = 101, Name = "Dairy" }
);

Aqui, nós simplesmente adicionamos duas categorias exemplo por padrão. Isso é necessário para testar nosso endpoint API após finalizá-lo.

Aviso: estamos definindo manualmente as propriedades de Id aqui porque o provedor na memória o exige para que funcione. Estou configurando os identificadores como números grandes para evitar a colisão entre os identificadores gerados automaticamente e os dados iniciais.

Essa limitação não existe em provedores de banco de dados relacionais verdadeiros. Portanto, se você quiser usar um banco de dados como o SQL Server, por exemplo, não precisará especificar esses identificadores. Verifique este relatório de problemas no GitHub se quiser entender esse comportamento.

Tendo implementado a classe de contexto de banco de dados, podemos implementar o repositório de categorias. Adicione uma nova pasta chamada Repositories dentro da pasta Persistence e, então, adicione uma nova classe chamada BaseRepository.

Esta classe é apenas uma classe abstrata que todos os nossos repositórios herdarão. Uma classe abstrata é uma classe que não possui instâncias diretas. Você precisa criar classes diretas para criar as instâncias.

O BaseRepository recebe uma instância do nosso AppDbContext através de injeção de dependência e expõe uma propriedade protegida (uma propriedade que só pode ser acessada pelas classes filhas) chamada _context, que dá acesso a todos os métodos que precisamos para lidar com as operações do banco de dados.

Adicione uma nova classe na mesma pasta chamada CategoryRepository. Agora, vamos realmente implementar a lógica do repositório:

O repositório herda o BaseRepository e implementa o ICategoryRepository.

Observe como é simples implementar o método de listagem. Usamos o conjunto de banco de dados Categories para acessar a tabela de categorias e, então, chamamos o método de extensão ToListAsync, que é responsável por transformar o resultado de uma consulta em uma coleção de categorias.

O EF Core converte nossa chamada de método em uma consulta SQL, da maneira mais eficiente possível. A consulta só é executada quando você chama um método que transformará seus dados em uma coleção, ou quando você usa um método para obter dados específicos.

Agora temos uma implementação limpa do controlador de categorias, do serviço e do repositório.

Separamos os interesses, criando classes que só fazem o que devem fazer.

A última etapa antes de testar a aplicação é vincular nossas interfaces às respectivas classes usando o mecanismo de injeção de dependência do ASP.NET Core.

Etapa 6 — Configurando a injeção de dependência

É hora de você finalmente entender como esse conceito funciona.

Na pasta raiz da aplicação, abra a classe Startup. Esta classe é responsável por configurar todos os tipos de configurações quando a aplicação é iniciada.

Os métodos ConfigureServices e Configure são chamados em tempo de execução pelo pipeline da estrutura para configurar como a aplicação deve funcionar e quais componentes ele deve usar.

Dê uma olhada no método ConfigureServices. Aqui, temos apenas uma linha, que configura a aplicação para que use o pipeline MVC, o que, basicamente, significa que a aplicação vai lidar com requisições e respostas usando classes controller (há mais coisas acontecendo aqui internamente, mas é isso que você precisa saber por enquanto).

Podemos usar o método ConfigureServices, acessando o parâmetro services, para configurar nossas ligações de dependência. Limpe o código da classe removendo todos os comentários e altere o código da seguinte forma:

Veja este trecho de código:

services.AddDbContext<AppDbContext>(options => {

  options.UseInMemoryDatabase("supermarket-api-in-memory");
  
});

Aqui, configuramos o contexto do banco de dados. Dizemos ao ASP.NET Core para usar nosso AppDbContext com uma implementação de banco de dados na memória, que é identificada pela string passada como um argumento para nosso método. Normalmente, o provedor em memória é usado quando escrevemos testes de integração, mas estou usando aqui para simplificar. Dessa forma, não precisamos nos conectar a um banco de dados real para testar a aplicação.

A configuração dessas linhas define internamente nosso contexto de banco de dados para a injeção de dependência usando um tempo de vida com escopo definido.

O tempo de vida com escopo definido informa ao pipeline do ASP.NET Core que sempre que ele precisar resolver uma classe que recebe uma instância de AppDbContext como um argumento de construtor, ele deve usar a mesma instância da classe. Se não houver instância na memória, o pipeline criará uma nova instância e a reutilizará em todas as classes que precisarem dela, durante uma determinada solicitação. Desse modo, você não precisa criar manualmente a instância da classe quando precisar usá-la.

Existem outros escopos vitalícios que você pode conferir lendo a documentação oficial.

A técnica de injeção de dependência nos oferece muitas vantagens, como:

  • Reutilização de código;
  • Melhor produtividade, pois quando temos que mudar a implementação, não precisamos nos preocupar em mudar uma centena de lugares onde você usa esse recurso;
  • Você pode facilmente testar a aplicação, pois podemos isolar o que temos para testar usando mocks (implementação falsa de classes) onde temos que passar interfaces como argumentos do construtor;
  • Quando uma classe precisa receber mais dependências por meio de um construtor, você não precisa alterar manualmente todos os locais onde as instâncias estão sendo criadas (isso é incrível!).

Após configurar o contexto do banco de dados, também vinculamos nosso serviço e repositório às respectivas classes.

services.AddScoped<ICategoryRepository, CategoryRepository>();

services.AddScoped<ICategoryService, CategoryService>();

Aqui, também usamos um tempo de vida com escopo porque essas classes internamente precisam usar a classe de contexto do banco de dados. Faz sentido especificar o mesmo escopo, neste caso.

Agora que configuramos nossas ligações de dependência, temos que fazer uma pequena alteração na classe Program, para que o banco de dados semeie corretamente nossos dados iniciais. Esta etapa só é necessária ao usar o provedor de banco de dados na memória (consulte este relatório de problemas no GitHub para entender o motivo).

Foi necessário alterar o método Main para garantir que nosso banco de dados será "criado" quando a aplicação for iniciada, pois estamos usando um provedor na memória. Sem essa alteração, as categorias que queremos semear não serão criadas.

Com todos os recursos básicos implementados, é hora de testar nosso endpoint de API.

Etapa 7 — Testando a API de categorias

Abra o terminal ou prompt de comando na pasta raiz da API e digite o seguinte comando:

dotnet run

O comando acima inicia a aplicação. O console vai mostrar uma saída similar a esta:

info: Microsoft.EntityFrameworkCore.Infrastructure[10403]

Entity Framework Core 2.2.0-rtm-35687 initialized ‘AppDbContext’ using provider ‘Microsoft.EntityFrameworkCore.InMemory’ with options: StoreName=supermarket-api-in-memory

info: Microsoft.EntityFrameworkCore.Update[30100]

Saved 2 entities to in-memory store.

info: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]

User profile is available. Using ‘C:\Users\evgomes\AppData\Local\ASP.NET\DataProtection-Keys’ as key repository and Windows DPAPI to encrypt keys at rest.

Hosting environment: Development

Content root path: C:\Users\evgomes\Desktop\Tutorials\src\Supermarket.API

Now listening on: https://localhost:5001

Now listening on: http://localhost:5000

Application started. Press Ctrl+C to shut down.

Você pode ver que o EF Core foi chamado para inicializar o banco de dados. As últimas linhas mostram em quais portas a aplicação está sendo executada.

Abra um navegador e navegue até http://localhost:5000/api/categories (ou para o URL exibido na saída do console). Se você vir um erro de segurança devido ao HTTPS, basta adicionar uma exceção para a aplicação.

O navegador mostrará os seguintes dados JSON como saída:

[
  {
     "id": 100,
     "name": "Fruits and Vegetables",
     "products": []
  },
  {
     "id": 101,
     "name": "Dairy",
     "products": []
  }
]

Aqui vemos os dados que adicionamos ao banco de dados quando configuramos o contexto do banco de dados. Essa saída confirma que nosso código está funcionando.

Você criou um endpoint de GET de API com poucas linhas de código e tem uma estrutura de código que é muito fácil de alterar devido à arquitetura da API.

Agora, é hora de mostrar como é fácil alterar esse código quando você precisa ajustá-lo devido às necessidades do negócio.

Etapa 8 — Criando um recurso de categoria

Se você se lembra da especificação do endpoint da API, notou que nossa resposta JSON real tem uma propriedade extra: um array de produtos. Dê uma olhada no exemplo da resposta desejada:

{
  [
    { "id": 1, "name": "Fruits and Vegetables" },
    { "id": 2, "name": "Breads" },
    … // Outras categorias
  ]
}

O array de produtos está presente em nossa resposta JSON atual porque nosso modelo Category tem uma propriedade Products, necessária ao EF Core para mapear corretamente os produtos de uma determinada categoria.

Não queremos essa propriedade em nossa resposta, mas não podemos alterar nossa classe de modelo para excluir essa propriedade. Isso faria com que o EF Core gerasse erros quando tentamos gerenciar dados de categorias e também interromperia nosso design de modelo de domínio, pois não faz sentido ter uma categoria de produto que não tenha produtos.

Para retornar dados JSON contendo apenas os identificadores e nomes das categorias do supermercado, temos que criar uma classe de recurso.

Uma classe de recurso (texto em inglês) é uma classe que contém apenas informações básicas que serão trocadas entre aplicações de client e terminais de API, geralmente na forma de dados JSON, para representar algumas informações específicas.

Todas as respostas dos endpoints da API devem retornar um recurso.

É uma má prática devolver a representação do modelo real como resposta uma vez que pode conter informações que a aplicação de client não necessita ou que não tem permissão para ter (por exemplo, um modelo de usuário poderia devolver informações da senha do usuário, o que seria um grande problema de segurança).

Precisamos de um recurso para representar apenas nossas categorias, sem os produtos.

Agora que você sabe o que é um recurso, vamos implementá-lo. Antes de tudo, pare a aplicação em execução pressionando Ctrl + C na linha de comando. Na pasta raiz da aplicação, crie uma nova pasta chamada Resources. Lá, adicione uma nova classe chamada CategoryResource.

Temos que mapear nossa coleção de modelos de categoria, que é fornecida pelo nosso serviço de categoria, para uma coleção de recursos de categoria.

Usaremos uma biblioteca chamada AutoMapper para manipular o mapeamento entre objetos. O AutoMapper é uma biblioteca muito popular no mundo .NET e é usada em muitos projetos comerciais e de código aberto.

Digite as seguintes linhas na linha de comando para adicionar o AutoMapper à nossa aplicação:

dotnet add package AutoMapper

dotnet add package AutoMapper.Extensions.Microsoft.DependencyInjection

Para usar o AutoMapper, temos que fazer duas coisas:

  • Registrá-lo para injeção de dependência;
  • Criar uma classe que vai dizer ao AutoMapper como manipular o mapeamento de classes.

Primeiramente, abra a classe Startup. No método ConfigureServices, após a última linha, adicione o código a seguir:

services.AddAutoMapper();

Esta linha manipula todas as configurações necessárias do AutoMapper, tal como registrá-la para injeção de dependência e procurar na aplicação durante a inicialização para configurar perfis de mapeamento.

Agora, no diretório raiz, adicione uma nova pasta chamada Mapping e, em seguida, adicione uma classe chamada ModelToResourceProfile. Altere o código desta forma:

A classe herda Profile, um tipo de classe que o AutoMapper usa para verificar como nossos mapeamentos funcionarão. No construtor, criamos um mapa entre a classe de modelo Category e a classe CategoryResource. Como as propriedades das classes têm os mesmos nomes e tipos, não precisamos usar nenhuma configuração especial para elas.

A etapa final consiste em alterar o controlador de categorias para usar AutoMapper para lidar com o mapeamento de nossos objetos.

Alterei o construtor para receber uma instância de implementação de IMapper. Você pode usar esses métodos de interface para usar os métodos de mapeamento do AutoMapper.

Também alterei o método GetAllAsync para mapear nossa enumeração de categorias para uma enumeração de recursos usando o método Map. Este método recebe uma instância da classe ou coleção que queremos mapear e, por meio de definições genéricas de tipos, define para qual tipo de classe ou coleção deve ser mapeada.

Observe que alteramos facilmente a implementação sem precisar adaptar a classe de serviço ou repositório, simplesmente injetando uma nova dependência (IMapper) no construtor.

A injeção de dependência facilita a manutenção e alteração de sua aplicação, pois você não precisa interromper toda a implementação de seu código para adicionar ou remover recursos.

Você provavelmente percebeu que não apenas a classe do controlador, mas todas as classes que recebem dependências (incluindo as próprias dependências) foram resolvidas automaticamente para receber as classes corretas de acordo com as configurações de vinculação.

A injeção de dependência é incrível, não é?


Agora, inicie a API novamente usando o comando dotnet run e acesse http://localhost:5000/api/categories para ver a nova resposta JSON.

0_QhjRK7dOyxX8FXL2
Estes são os dados de resposta que você deveria ver

Nós já temos nosso endpoint GET. Agora, vamos criar outro endpoint para fazer o POST (criação) de categorias.

Etapa 9 — Criando outras categorias

Ao lidar com a criação de recursos, temos que ter cuidado com muitas coisas, tais como:

  • Validação de dados e integração de dados;
  • Autorização para criar recursos;
  • Manipulação de erros;
  • Registro.

Não mostrarei como lidar com autenticação e autorização neste tutorial, mas você pode ver como implementar facilmente esses recursos lendo meu tutorial sobre autenticação de token da Web JSON (texto em inglês).

Além disso, existe um framework muito popular chamada ASP.NET Identity, que fornece soluções internas de segurança e registro de usuários que você pode usar em suas aplicações. Ele inclui provedores para trabalhar com o EF Core, como um IdentityDbContext interno que você pode usar. Você pode aprender mais sobre isso aqui.

Vamos escrever um endpoint HTTP POST que cobrirá os outros cenários (exceto o de registro ou logging, que pode mudar de acordo com diferentes escopos e ferramentas).

Antes de criar outro endpoint, precisamos de um novo recurso. Este recurso vai mapear os dados que as aplicações de client enviam para este endpoint (neste caso, o nome da categoria) para uma classe da nossa aplicação.

Como estamos criando outra categoria, ainda não temos um ID. Isso significa que precisamos de um recurso que represente uma categoria contendo apenas seu nome.

Na pasta Resources, adicione uma nova classe chamada SaveCategoryResource:

Observe os atributos Required e MaxLength aplicados sobre a propriedade Name. Esses atributos são chamados de anotações de dados. O pipeline do ASP.NET Core usa esses metadados para validar solicitações e respostas. Como os nomes sugerem, o nome da categoria é obrigatório e tem um comprimento máximo de 30 caracteres.

Agora vamos definir a forma do novo endpoint de API. Adicione o seguinte código ao controlador de categorias:

Dizemos ao framework que este é um endpoint HTTP POST usando o atributo HttpPost.

Observe o tipo de resposta desse método, Task<IActionResult>. Os métodos presentes nas classes do controlador são chamados de ações e possuem essa assinatura porque podemos retornar mais de um resultado possível após a aplicação executar a ação.

Nesse caso, se o nome da categoria for inválido, ou se algo der errado, teremos que retornar uma resposta de código 400 (solicitação inválida), contendo geralmente uma mensagem de erro que as aplicações de client podem usar para tratar o problema, ou podemos ter um 200 resposta (sucesso) com dados se tudo der certo.

Existem muitos tipos de ação que você pode usar como resposta, mas geralmente podemos usar essa interface, e o ASP.NET Core usará uma classe padrão para isso.

O atributo FromBody informa ao ASP.NET Core para analisar os dados do corpo da solicitação em nossa nova classe de recurso. Isso significa que quando um JSON contendo o nome da categoria é enviado para nossa aplicação, o framework irá analisá-lo automaticamente para nossa nova classe.

Agora, vamos implementar nossa lógica de rota. Temos que seguir alguns passos para criar com sucesso uma nova categoria:

  • Primeiro, temos que validar a solicitação recebida. Se a solicitação for inválida, temos que retornar uma resposta de solicitação inválida contendo as mensagens de erro;
  • Então, se a solicitação for válida, temos que mapear nosso novo recurso para nossa classe de modelo de categoria usando AutoMapper;
  • Agora, precisamos chamar nosso serviço, dizendo para salvar nossa nova categoria. Se a lógica de salvamento for executada sem problemas, ela deverá retornar uma resposta contendo nossos novos dados de categoria. Caso contrário, deve nos dar uma indicação de que o processo falhou e uma possível mensagem de erro;
  • Por fim, se houver um erro, retornamos uma solicitação inválida. Caso contrário, mapeamos nosso novo modelo de categoria para um recurso de categoria e retornamos uma resposta de sucesso ao client, contendo os novos dados de categoria.

Parece ser complicado, mas é realmente fácil implementar essa lógica usando a arquitetura de serviço que estruturamos para nossa API.

Vamos começar validando a solicitação recebida.

Etapa 10 — Validando o corpo da solicitação usando o estado do modelo

Os controladores do ASP.NET Core têm uma propriedade chamada ModelState. Esta propriedade é preenchida durante a execução da requisição antes de chegarmos à execução da nossa ação. É uma instância de ModelStateDictionary, uma classe que contém informações como se a solicitação é válida e possíveis mensagens de erro de validação.

Altere o código do endpoint da seguinte maneira:

O código verifica se o estado do modelo (neste caso, os dados enviados no corpo da solicitação) é válido, verificando nossas anotações de dados. Se não for, a API retornará uma solicitação inválida (com código de status 400) e as mensagens de erro padrão que nossos metadados de anotações forneceram.

O método ModelState.GetErrorMessages() ainda não foi implementado. É um método de extensão (um método que estende a funcionalidade de uma classe ou interface já existente) que vou implementar para converter os erros de validação em strings simples para retornar ao client.

Adicione uma nova pasta Extensions na raiz da nossa API e adicione uma nova classe ModelStateExtensions.

Todos os métodos de extensão devem ser estáticos, assim como as classes onde são declarados. Isso significa que eles não lidam com dados de instância específicos e que são carregados apenas uma vez quando a aplicação é iniciada.

A palavra-chave this na frente da declaração do parâmetro diz ao compilador do C# para tratá-la como um método de extensão. O resultado é que podemos chamá-lo como um método normal desta classe desde que incluamos a respectiva diretiva using onde queremos usar a extensão.

A extensão usa consultas LINQ, um recurso muito útil do .NET que nos permite consultar e transformar dados usando expressões encadeadas. As expressões aqui transformam os métodos de erro de validação em uma lista de strings contendo as mensagens de erro.

Importe o namespace Supermarket.API.Extensions para o controlador de categorias antes de ir para a próxima etapa.

using Supermarket.API.Extensions;

Vamos continuar implementando a lógica do nosso endpoint mapeando nosso recurso para uma classe de modelo de categoria.

Etapa 11 — Mapeando o novo recurso

Nós já definimos um perfil de mapeamento para transformar modelos em recursos. Agora, precisamos de um novo perfil que faz o inverso.

Adicione uma nova classe ResourceToModelProfile na pasta Mapping:

Nada de novo aqui. Graças à mágica da injeção de dependência, o AutoMapper registrará automaticamente esse perfil quando a aplicação for iniciada, e não precisamos alterar nenhum outro local para usá-lo.

Agora podemos mapear nosso novo recurso para a respectiva classe de modelo:

Etapa 12 — Aplicando o padrão solicitação-resposta para manipular a lógica de salvamento

Agora, temos que implementar a lógica mais interessante: salvar uma nova categoria. Esperamos que o nosso serviço faça isso.

A lógica de salvamento pode falhar devido a problemas na conexão com o banco de dados, ou talvez porque alguma regra de negócio interna invalide nossos dados.

Se algo der errado, não podemos simplesmente lançar um erro, porque isso poderia parar a API e a aplicação de client não saberia como lidar com o problema. Além disso, potencialmente teríamos algum mecanismo de log que registraria o erro.

O contrato do método de salvamento, ou seja, a assinatura do método e tipo de resposta, precisa nos indicar se o processo foi executado corretamente. Se o processo der certo, receberemos os dados da categoria. Caso contrário, temos que receber, pelo menos, uma mensagem de erro informando por que o processo falhou.

Podemos implementar esse recurso aplicando o padrão solicitação-resposta. Esse padrão de design corporativo encapsula nossos parâmetros de solicitação e resposta em classes como uma forma de encapsular informações que nossos serviços usarão para processar alguma tarefa e retornar informações para a classe que está usando o serviço.

Esse padrão nos dá algumas vantagens, como:

  • Se precisarmos alterar nosso serviço para receber mais parâmetros, não precisamos quebrar sua assinatura;
  • Podemos definir um contrato padrão para nossa solicitação e/ou respostas;
  • Podemos lidar com a lógica de negócios e possíveis falhas sem interromper o processo da aplicação e não precisaremos usar muitos blocos try-catch.

Vamos criar um tipo de resposta padrão para nossos métodos de serviços que lidam com alterações de dados. Para cada solicitação desse tipo, queremos saber se a solicitação é executada sem problemas. Se falhar, queremos retornar uma mensagem de erro ao client.

Na pasta Domain, dentro de Services, adicione um novo diretório chamado Communication. Adicione uma nova classe chamada BaseResponse.

Essa é uma classe abstrata que nossos tipos de resposta herdarão.

A abstração define uma propriedade Success, que informará se as solicitações foram concluídas com sucesso, e uma propriedade Message, que terá a mensagem de erro se algo falhar.

Observe que essas propriedades são necessárias e somente as classes herdadas podem definir esses dados porque as classes filhas precisam passar essas informações pela função construtora.

Dica: não é uma boa prática definir classes base para tudo, porque as classes base acoplam seu código (texto em inglês) e impedem que você o modifique facilmente. Prefira usar composição sobre herança (texto em inglês).

Para o escopo desta API, não é realmente um problema usar classes base, pois nossos serviços não crescerão muito. Se você perceber que um serviço ou uma aplicação crescerá e mudará com frequência, evite usar uma classe base.

Agora, na mesma pasta, adicione uma nova classe chamada SaveCategoryResponse.

O tipo de respostas também define uma propriedade Category, a qual conterá os dados de nossa categoria se a solicitação for concluída com sucesso.

Note como eu defini três construtores diferentes para esta classe:

  • Um privado, que vai passar os parâmetros de sucesso e mensagem para a classe base, e também define a propriedade Category;
  • Um construtor que recebe apenas a categoria como parâmetro. Este criará uma resposta bem-sucedida, chamando o construtor privado para definir as respectivas propriedades;
  • Um terceiro construtor que especifica apenas a mensagem. Este será usado para criar uma resposta de falha.

Como o C# oferece suporte a vários construtores, simplificamos a criação da resposta sem definir métodos diferentes para lidar com isso, apenas usando construtores diferentes.

Agora podemos alterar nossa interface de serviço para adicionar o novo contrato do método de salvamento.

Altere a interface ICategoryService da seguinte forma:

Simplesmente passaremos uma categoria para este método e ele tratará de toda a lógica necessária para salvar os dados do modelo, orquestrando repositórios e outros serviços necessários para isso.

Observe que não estou criando uma classe de solicitação específica aqui, pois não precisamos de outros parâmetros para realizar essa tarefa. Existe um conceito em programação de computadores chamado KISS (texto em inglês)– abreviação de Keep it Simple, Stupid. Basicamente, ele diz que você deve manter sua aplicação mais simples possível.

Lembre-se disso ao projetar suas aplicações: aplique apenas o que você precisa para resolver um problema. Não exagere na engenharia de sua aplicação.

Agora podemos finalizar a lógica de nosso endpoint:

Após validar os dados da solicitação e mapear o recurso para nosso modelo, passamos para o nosso serviço para persistir os dados.

Se algo falhar, a API retornará uma solicitação incorreta. Caso contrário, a API mapeia a nova categoria (agora incluindo dados como o novo Id) para nosso CategoryResource criado anteriormente e o envia para o client.

Agora, vamos implementar a lógica real para o serviço.

Etapa 13 — A lógica do banco de dados e o padrão unidade de trabalho

Já que faremos a persistência dos dados em um banco de dados, precisamos de um novo método em nosso repositório.

Adicione um novo método AddAsync para a interface ICategoryRepository:

Agora vamos implementar este método em nossa classe de repositório:

Aqui, estamos simplesmente adicionando uma nova categoria ao nosso conjunto.

Quando adicionamos uma classe a um DBSet<>, o EF Core começa a rastrear todas as alterações que acontecem em nosso modelo e usa esses dados no estado atual para gerar consultas que inserirão, atualizarão ou excluirão modelos.

A implementação atual simplesmente adiciona o modelo ao nosso conjunto, mas nossos dados ainda não serão salvos.

Existe um método chamado SaveChanges presente na classe de contexto que temos que chamar para realmente executar as consultas no banco de dados. Eu não chamei aqui porque um repositório não deve fazer a persistência de dados, é apenas uma coleção de objetos na memória (texto em inglês).

Esse assunto é muito controverso até mesmo entre desenvolvedores .NET experientes, mas deixe-me explicar por que você não deve chamar SaveChanges em classes de repositório.

Podemos pensar em um repositório conceitualmente como qualquer outra coleção presente no framework .NET. Ao lidar com uma coleção em .NET (e muitas outras linguagens de programação, como Javascript e Java), você geralmente pode:

  • Adicionar novos itens a ela (como quando você insere dados em listas, vetores e dicionários);
  • Encontrar ou filtrar itens;
  • Remover um item da coleção;
  • Substituir um dado item ou atualizá-lo.

Pense em uma lista do mundo real. Imagine que você está escrevendo uma lista de compras para comprar coisas em um supermercado (que coincidência, não?).

Na lista, você escreve todas as frutas que precisa comprar. Você pode adicionar frutas a esta lista, remover uma fruta se desistir de comprá-la ou substituir o nome de uma fruta. Mas você não pode salvar frutas na lista. Não faz sentido dizer uma coisa dessas naturalmente em português.

Dica: ao projetar classes e interfaces em linguagens de programação orientadas a objetos, tente usar linguagem natural para verificar se o que você está fazendo parece estar correto.

Faz sentido, por exemplo, dizer que um homem implementa uma interface de pessoa, mas não faz sentido dizer que um homem implementa uma conta.

Se você quiser "salvar" as listas de frutas (neste caso, comprar todas as frutas), você paga e o supermercado processa os dados do estoque para verificar se eles têm que comprar mais frutas de um fornecedor ou não.

A mesma lógica pode ser aplicada na programação. Os repositórios não devem salvar, atualizar ou excluir dados. Em vez disso, eles devem delegá-lo a uma classe diferente para lidar com essa lógica.

Há outro problema ao salvar dados diretamente em um repositório: você não pode usar transações.

Imagine que nossa aplicação possui um mecanismo de log que armazena algum nome de usuário e a ação realizada toda vez que é feita uma alteração nos dados da API.

Agora, imagine que, por algum motivo, você tem uma chamada para um serviço que atualiza o nome de usuário (não é um cenário comum, mas vamos considerar).

Você concorda que para alterar o nome de usuário em uma tabela de usuários fictícia, primeiro você precisa atualizar todos os logs para informar corretamente quem executou essa operação, certo?

Imagine, então, que implementamos o método de atualização para usuários e logs em diferentes repositórios, e ambos chamam SaveChanges. O que acontece se um desses métodos falhar no meio do processo de atualização? Você vai acabar com inconsistência de dados.

Devemos salvar nossas alterações no banco de dados somente depois que tudo terminar. Para fazer isso, temos que usar uma transação, que é basicamente um recurso que a maioria dos bancos de dados implementa para salvar dados somente após a conclusão de uma operação complexa.

"- Tudo bem. Então, se não podemos salvar coisas aqui, onde devemos salvá-las?"

Um padrão comum para lidar com esse problema é o Padrão Unidade de Trabalho (Unit of Work Pattern). Esse padrão consiste em uma classe que recebe nossa instância AppDbContext como dependência e expõe métodos para iniciar, concluir ou abortar transações.

Usaremos uma implementação simples de uma unidade de trabalho para abordar nosso problema aqui.

Adicione uma nova interface dentro da pasta Repositories da camada Domain chamada IUnitOfWork:

Como você pode ver, ela só expõe um método que vai concluir de forma assíncrona as operações de gerenciamento de dados.

Agora, vamos adicionar a implementação real.

Adicione uma nova classe chamada UnitOfWork na pasta RepositoriesRepositories da camada Persistence:

Essa é uma implementação simples e limpa que só salvará todas as alterações no banco de dados depois que você terminar de modificá-lo usando seus repositórios.


Se você pesquisar implementações do padrão Unidade de Trabalho, encontrará outras mais complexas implementando operações de reversão (rollback).

Como o EF Core já implementa os padrões repositório e unidade de trabalho nos bastidores, não precisamos nos preocupar com um método de reversão.

"- O que? Então por que nós temos que criar todas essas interfaces e classes?"

Separar a lógica de persistência das regras de negócios oferece muitas vantagens em termos de reutilização e manutenção de código. Se usarmos o EF Core diretamente, acabaremos tendo classes mais complexas que não serão tão fáceis de mudar.

Imagine que no futuro você decida mudar o framework ORM para um diferente, como o Dapper (texto em inglês), por exemplo, ou se tiver que implementar consultas SQL simples por causa do desempenho. Se você acoplar sua lógica de consultas aos seus serviços, será difícil mudar a lógica, pois você terá que fazer isso em muitas classes.

Usando o padrão de repositório, você pode simplesmente implementar uma nova classe de repositório e vinculá-la usando injeção de dependência.

Então, basicamente, se você usar o EF Core diretamente em seus serviços e precisar alterar alguma coisa, é isso que você obterá:

Como eu disse, o EF Core implementa os padrões Repositório e Unidade de Trabalho nos bastidores. Podemos considerar nossas propriedades DbSet<> como repositórios. Além disso, SaveChanges apenas persiste os dados em caso de sucesso para todas as operações do banco de dados.

Agora que você sabe o que é uma unidade de trabalho e por que usá-la com repositórios, vamos implementar a lógica do serviço real.

Graças à nossa arquitetura desacoplada, podemos simplesmente passar uma instância de UnitOfWork como uma dependência para esta classe.

Nossa lógica de negócios é bastante simples.

Primeiro, tentamos adicionar a nova categoria ao banco de dados e depois a API tenta salvá-la, envolvendo tudo dentro de um bloco try-catch.

Se algo falhar, a API chama algum serviço de log fictício e retorna uma resposta indicando falha.

Se o processo terminar sem problemas, a aplicação retornará uma resposta de sucesso, enviando nossos dados de categoria. Simples, certo?

Dica: Em aplicações do mundo real, você não deve envolver tudo dentro de um bloco try-catch genérico, mas sim lidar com todos os erros possíveis separadamente.

Simplesmente adicionar um bloco try-catch não cobrirá a maioria dos possíveis cenários de falha. Certifique-se de corrigir o tratamento de erros do implemento.

A última etapa antes de testar nossa API é vincular a interface de unidade de trabalho à sua respectiva classe.

Adicione esta nova linha ao método ConfigureServices da classe Startup:

services.AddScoped<IUnitOfWork, UnitOfWork>();

Agora vamos testá-la!

Etapa 14 — Testando nosso endpoint de POST usando o Postman

Inicie nossa aplicação novamente usando dotnet run.

Não podemos usar o navegador para testar um endpoint de POST. Vamos usar o Postman para testar nossos endpoints. É uma ferramenta muito útil para testar APIs RESTful.

Abra o Postman e feche as mensagens introdutórias. Você verá uma tela como esta aqui:

0_ZZo6TwEXLK8ngpTV
Tela mostrando as opções para testar endpoints

Altere o GET selecionado por padrão na caixa de seleção por POST.

Digite o endereço da API no campo Enter request URL.

Temos que fornecer os dados do corpo da solicitação a ser enviada à nossa API. Clique no item de menu Body e altere a opção exibida abaixo dela por raw.

O Postman vai mostrar uma opção Text à direita. Altere-a para JSON (application/json) e cole o seguinte dado JSON abaixo:

{
  "name": ""
}
0_8hhlYg26sNJRWmbe
Tela antes de enviar uma solicitação

Como você pode ver, vamos enviar uma string de nome vazio para nosso novo endpoint.

Clique no botão Send. Você vai receber uma saída como esta:

0_eqRGjAtndTIgTyqw
Nossa lógica de validação funciona!

Se lembra da lógica de validação que criamos para o endpoint? Esta saída é a prova de que ela funciona!

Note também o código de status 400 exibido à direita. O resultado BadRequest adiciona automaticamente esse código de status à resposta.

Agora vamos alterar o dado JSON para um válido para ver a nova resposta:

0_z0_hmEcSzvkvbQQX
Finalmente, o resultado que nós esperávamos ter

A API criou corretamente nosso novo recurso.

Até agora, nossa API pode listar e criar categorias. Você aprendeu muitas coisas sobre a linguagem C#, o framework ASP.NET Core e também algumas abordagens comuns de design para estruturar suas APIs.

Vamos continuar nossa API de categorias criando o endpoint para atualizar categorias.

Daqui para frente, já que eu expliquei a maioria dos conceitos, vou acelerar as explicações e me concentrar nos novos assuntos para não gastar seu tempo. Vamos lá!

Etapa 15 — Atualizando categorias

Para atualizar as categorias, precisamos de um endpoint HTTP de PUT.

A lógica que temos que colocar no código é muito similar à do POST:

  • Primeiro, temos que validar a solicitação recebida usando o ModelState;
  • Se a solicitação for válida, a API deve mapear o recurso de entrada para uma classe de modelo usando o AutoMapper;
  • Em seguida, precisamos ligar para o nosso serviço, informando para atualizar a categoria, fornecendo o respectivo Id da categoria e os dados atualizados;
  • Se não houver nenhuma categoria com o Id fornecido no banco de dados, retornaremos uma solicitação inválida. Poderíamos usar um resultado NotFound, mas isso não importa muito para esse escopo, pois fornecemos uma mensagem de erro para as aplicações de client;
  • Se a lógica de salvamento for executada corretamente, o serviço deverá retornar uma resposta contendo os dados da categoria atualizados. Caso contrário, deve nos dar uma indicação de que o processo falhou e uma mensagem indicando o motivo;
  • Por fim, se houver um erro, a API retornará uma solicitação incorreta. Caso contrário, ela mapeia o modelo de categoria atualizado para um recurso de categoria e retorna uma resposta de sucesso à aplicação de client.

Vamos adicionar o novo método PutAsync à classe controladora:

Se você comparar com a lógica do POST, você notará que temos apenas uma diferença aqui: o atributo HttpPut especifica um parâmetro que a rota dada deve receber.

Chamaremos esse endpoint especificando o Id da categoria como o último fragmento de URL, como /api/categories/1. O pipeline do ASP.NET Core analisa esse fragmento para o parâmetro de mesmo nome.

Agora, temos que definir a assinatura do método UpdateAsync na interface ICategoryService:

Passemos para a lógica real.

Etapa 16 — A lógica da atualização

Para atualizar nossa categoria, primeiro precisamos retornar os dados atuais do banco de dados, caso existam. Também precisamos atualizá-los em nosso DBSet<>.

Vamos adicionar dois novos contratos de método à nossa interface ICategoryService:

Definimos o método FindByIdAsync, que retornará de forma assíncrona uma categoria do banco de dados, e o método Update. Preste atenção no fato de que o método Update não é assíncrono, pois a API do EF Core não requer um método assíncrono para atualizar os modelos.

Agora vamos implementar a lógica real na classe CategoryRepository:

Finalmente, podemos adicionar o código para a lógica do serviço:

A API tenta obter a categoria do banco de dados. Se o resultado for null, retornamos uma resposta informando que a categoria não existe. Se a categoria existir, precisamos definir seu novo nome.

A API, então, tenta salvar as alterações, como quando criamos uma nova categoria. Se o processo for concluído, o serviço retornará uma resposta de sucesso. Caso contrário, a lógica de log é executada e o endpoint recebe uma resposta contendo uma mensagem de erro.

Agora vamos ao teste. Primeiro, vamos adicionar uma nova categoria para ter um Id válido para usar. Poderíamos usar os identificadores das categorias que propagamos em nosso banco de dados, mas quero fazer dessa maneira para mostrar que nossa API atualizará o recurso correto.

Execute a aplicação novamente e, usando o Postman, envie um POST de uma nova categoria para o banco de dados:

0_UIjyDcw4lnRqY072
Adicionando uma nova categoria para atualizá-la posteriormente

Com um Id válido em mãos, altere a opção POST para PUT na caixa de seleção e adicione o valor do ID no final da URL. Altere a propriedade name para um nome diferente e envie a solicitação para verificar o resultado:

0_i2cpHjrW-422v7jt
Os dados da categoria foram atualizados com sucesso

Você pode enviar uma solicitação GET para o endpoint da API para garantir que você editor corretamente o nome da categoria:

0_3b8rR_shOGcI6P8y
Este é agora o resultado de uma solicitação GET

A última operação que nós temos que implementar para as categorias é a exclusão de categorias. Vamos fazer isso criando um endpoint de HTTP Delete.

Etapa 17 — Excluindo categorias

A lógica para excluir categorias é realmente fácil de implementar já que a maioria dos métodos que precisamos foi construída anteriormente.

Estas são as etapas necessárias para nossa rota funcionar:

  • A API precisa chamar nosso serviço, informando para excluir nossa categoria, fornecendo o respectivo Id;
  • Se não houver nenhuma categoria com o ID informado no banco de dados, o serviço deverá retornar uma mensagem indicando isso;
  • Se a lógica de exclusão for executada sem problemas, o serviço deve retornar uma resposta contendo nossos dados de categoria excluídos. Caso contrário, deve nos dar uma indicação de que o processo falhou e uma possível mensagem de erro;
  • Por fim, se houver um erro, a API retornará uma solicitação inválida. Caso contrário, a API mapeia a categoria atualizada para um recurso e retorna uma resposta de sucesso ao client.

Vamos começar adicionando a lógica do novo endpoint:

O atributo HttpDelete também define um modelo de id.

Antes de adicionar a assinatura DeleteAsync à nossa interface ICategoryService, precisamos fazer uma pequena refatoração.

O novo método de serviço deve retornar uma resposta contendo os dados da categoria, da mesma forma que fizemos para os métodos PostAsync e UpdateAsync. Poderíamos reutilizar o SaveCategoryResponse para essa finalidade, mas não estamos salvando dados neste caso.

Para evitar a criação de uma nova classe com a mesma forma para atender a esse requisito, podemos simplesmente renomear nosso SaveCategoryResponse para CategoryResponse.

Se estiver usando o Visual Studio Code, você pode abrir a classe SaveCategoryResponse, colocar o cursor do mouse acima do nome da classe e usar a opção Change All Occurrences para renomear a classe:

0*0vbRNdSBgQqsf-TO
Forma fácil de alterar o nome em todos os arquivos

Certifique-se de renomear o nome de arquivo também.

Vamos adicionar a assinatura do método DeleteAsync à interface ICategoryService:

Antes de implementar a lógica de exclusão, precisamos de um novo método em nosso repositório.

Adicione a assinatura do método Remove à interface ICategoryRepository:

void Remove(Category category);

E agora adicione a implementação real na classe do repositório:

O EF Core requer que a instância do nosso modelo seja passada para o método Remove para entender corretamente qual modelo estamos excluindo, em vez de simplesmente passar um Id.

Finalmente, vamos implementar a lógica na classe CategoryService:

Não há nada de novo aqui. O serviço tenta encontrar a categoria por ID e então chama nosso repositório para excluir a categoria. Finalmente, a unidade de trabalho completa a transação executando a operação real no banco de dados.

"- Ei, mas e os produtos de cada categoria? Você não precisa criar um repositório e excluir os produtos primeiro, para evitar erros?"

A resposta é não. Graças ao mecanismo de acompanhamento do EF Core, quando carregamos um modelo do banco de dados, a estrutura sabe quais relacionamentos o modelo possui. Se o excluirmos, o EF Core saberá que deve excluir todos os modelos relacionados primeiro, recursivamente.

Podemos desabilitar esse recurso ao mapear nossas classes para tabelas de banco de dados, mas está fora do escopo deste tutorial. Dê uma olhada aqui (texto em inglês) se você quiser aprender sobre esse recurso.

Agora é hora de testar nosso novo endpoint. Execute a aplicação novamente e envie uma solicitação DELETE usando o Postman da seguinte maneira:

0_Ju431skSI6l5IOvV
Como você pode ver, a API excluiu a categoria existente sem problemas

Podemos conferir se nossa API está funcionando corretamente enviando uma solicitação GET:

0_v8PzsTC57h3uIlN1
Agora, recebemos apenas uma categoria como resultado

Finalizamos a API de categorias. Agora é hora de passar para a API de produtos.

Etapa 18 — A API de produtos

Até agora, você aprendeu como implementar todos os verbos HTTP básicos para lidar com operações CRUD com ASP.NET Core. Vamos para o próximo nível implementando nossa API de produtos.

Não detalharei todos os verbos HTTP novamente porque seria exaustivo. Para a parte final deste tutorial, abordarei apenas a solicitação GET, para mostrar como incluir entidades relacionadas ao consultar dados do banco de dados e como usar os atributos Description que definimos para os valores de enumeração EUnitOfMeasurement.

Adicione um novo controlador na pasta Controllers chamada ProductsController.

Antes de codificar qualquer coisa aqui, temos que criar o recurso do produto.

Deixe-me refrescar sua memória mostrando novamente como nosso recurso deve ficar:

{
 [
  {
   "id": 1,
   "name": "Sugar",
   "quantityInPackage": 1,
   "unitOfMeasurement": "KG"
   "category": {
   "id": 3,
   "name": "Sugar"
   }
  },
  … // Outros produtos
 ]
}

Queremos um array em JSON contendo todos os produtos do banco de dados.

Os dados em JSON diferem do modelo do produto por duas coisas:

  • A unidade de medida é exibida em uma forma mais curta, mostrando apenas sua abreviação;
  • Emitimos os dados da categoria sem incluir a propriedade CategoryId.

Para representar a unidade de medida, podemos usar uma propriedade de string simples em vez de um tipo enum (a propósito, não temos um tipo enum padrão para dados JSON. Então, temos que transformá-lo em um tipo diferente).

Agora que sabemos como moldar o novo recurso, vamos criá-lo. Adicione uma nova classe ProductResource na pasta Resources:

Agora temos que configurar o mapeamento entre a classe de modelo e nossa nova classe de recurso.

A configuração de mapeamento será quase a mesma usada para outros mapeamentos, mas aqui temos que lidar com a transformação de nosso enum EUnitOfMeasurement em uma string.

Você se lembra do atributo StringValue aplicado sobre os tipos de enumeração? Agora, vou mostrar como extrair essas informações usando um recurso poderoso do framework .NET: a API Reflection (texto em inglês).

A API Reflection é um poderoso conjunto de recursos que nos permite extrair e manipular metadados. Muitas estruturas e bibliotecas (incluindo o próprio ASP.NET Core) usam esses recursos para lidar com muitas coisas nos bastidores.

Agora, vamos ver como isso funciona na prática. Adicione uma nova classe na pasta Extensions chamada EnumExtensions.

Pode parecer assustador na primeira vez que você olhar para o código, mas não é tão complexo. Vamos detalhar a definição de código para entender como ele funciona.

Primeiramente, definimos um método genérico (um método que pode receber mais de um tipo de argumento, neste caso, representado pela declaração TEnum) que recebe um determinado enum como argumento.

Como enum é uma palavra-chave reservada em C#, adicionamos um @ na frente do nome do parâmetro para torná-lo um nome válido.

A primeira etapa de execução desse método é obter as informações de tipo (classe, interface, enum ou definição de estrutura) do parâmetro usando o método GetType.

Em seguida, o método obtém o valor de enumeração específico (por exemplo, Kilogram) usando GetField(@enum.ToString()).

A próxima linha encontra todos os atributos de Description aplicados sobre o valor de enumeração e armazena seus dados em uma matriz (podemos especificar vários atributos para uma mesma propriedade em alguns casos).

A última linha usa uma sintaxe mais curta para verificar se temos pelo menos um atributo de descrição para o tipo de enumeração. Se tivermos, retornaremos o valor Description fornecido por este atributo. Caso contrário, retornamos a enumeração como uma string, usando a conversão padrão.

O operador ?. (um operador condicional nulo) verifica se o valor é null antes de acessar sua propriedade.

O operador ?? (um operador de coalescência nula) informa à aplicação para retornar o valor à esquerda se não estiver vazio ou o valor à direita caso contrário.

Como temos um método de extensão para extrair descrições, vamos configurar nosso mapeamento entre modelo e recurso. Graças ao AutoMapper, podemos fazê-lo com apenas uma linha extra.

Abra a classe ModelToResourceProfile e altere o código desta forma:

Essa sintaxe diz ao AutoMapper para usar o novo método de extensão para converter nosso valor EUnitOfMeasurement em uma string contendo sua descrição. Simples, certo? Você pode ler a documentação oficial (em inglês) para entender a sintaxe completa.

Observe que não definimos nenhuma configuração de mapeamento para a propriedade da categoria. Como configuramos anteriormente o mapeamento para categorias e porque o modelo de produto possui uma propriedade de categoria do mesmo tipo e nome, o AutoMapper sabe implicitamente que deve mapeá-lo usando a respectiva configuração.

Agora, vamos adicionar o código do endpoint. Altere o código ProductsController:

Basicamente, a mesma estrutura definida para o controlador de categorias.

Vamos para a parte do serviço. Adicione uma nova interface IProductService à pasta Services presente na camada Domain:

Você deve ter percebido que precisamos de um repositório antes de realmente implementar o novo serviço.

Adicione uma nova interface chamada IProductRepository à respectiva pasta:

Agora vamos implementar o repositório. Temos que implementá-lo quase da mesma forma que fizemos para o repositório de categorias, exceto que precisamos retornar os respectivos dados de categoria de cada produto ao consultar os dados.

O EF Core, por padrão, não inclui entidades relacionadas aos seus modelos ao consultar dados porque pode ser muito lento (imagine um modelo com dez entidades relacionadas, todas as entidades relacionadas com seus próprios relacionamentos).

Para incluir os dados das categorias, precisamos apenas de uma linha extra:

Observe a chamada para Include(p => p.Category). Podemos encadear essa sintaxe para incluir quantas entidades forem necessárias ao consultar dados. O EF Core vai convertê-lo em uma junção ao realizar a seleção.

Agora podemos implementar a classe ProductService da mesma forma que fizemos para as categorias:

Vamos vincular as dependências alterando a classe Startup:

Finalmente, antes de testar a API, vamos alterar a classe AppDbContext para incluir alguns produtos quando inicializar a aplicação de modo que podemos ver os resultados:

Adicionei dois produtos fictícios associando-os às categorias que criamos quando da inicialização da aplicação.

É hora de testar! Execute a API novamente e envie uma solicitação GET para /api/products usando Postman:

1_ztoCnav4f95YwGJnQkiuxQ
Conseguimos! Aqui estão nossos produtos

É isso! Parabéns!

Agora, você tem uma base sobre como construir uma API RESTful usando ASP.NET Core usando uma arquitetura desacoplada. Você aprendeu muitas coisas sobre a estrutura do .NET Core, como trabalhar com C#, os conceitos básicos do EF Core e AutoMapper e muitos padrões úteis para usar ao projetar suas aplicações.

Você pode verificar a implementação completa da API, contendo os demais verbos HTTP para produtos, verificando o repositório do GitHub (em inglês):

evgomes/supermarket-api
API RESTful simples criada com ASP.NET Core 2.2 para mostrar como criar serviços RESTful usando uma arquitetura desacoplada e de fácil manutenção.

Conclusão

O ASP.NET Core é um ótimo framework para usar ao criar aplicações da web. Ele vem com muitas APIs úteis que você pode usar para criar aplicações limpas e de fácil manutenção. Considere-o como uma opção ao criar aplicações profissionais.

Este artigo não abordou todos os aspectos de uma API profissional, mas você aprendeu todos os conceitos básicos. Você também aprendeu muitos padrões úteis para resolver padrões que enfrentamos diariamente.

Espero que tenha gostado deste artigo e espero que tenha sido útil para você. Agradeço seu feedback para entender como posso melhorar isso.

Referências para continuar aprendendo

Tutoriais de .NET — Microsoft Docs

Documentação do ASP.NET Core — Microsoft Docs

]]> <![CDATA[ Tudo o que você precisa saber sobre ng-template, ng-content, ng-container e *ngTemplateOutlet em Angular ]]> https://www.freecodecamp.org/portuguese/news/tudo-o-que-voce-precisa-saber-sobre-ng-template-ng-content-ng-container-e-ngtemplateoutlet-em-angular/ 62bb92aea3520206e79ceeda Wed, 29 Jun 2022 17:41:53 +0000 Artigo original: Angular Views, Routing, and NgModules Explained

Era um dia daqueles em que eu me encontrava ocupado trabalhando em novos recursos de um projeto para o meu escritório. Foi aí que, de repente, algo chamou minha atenção:

1_mIQLobNDf0JSUgL7jfq9aQ
DOM final renderizado no Angular

Ao inspecionar o DOM, eu vi que ngcontent estava sendo aplicado nos elementos pelo Angular. Hmm… se eles contêm os elementos no DOM final, qual é a função do <ng-container>? Naquele momento, me senti confuso sobre a diferença entre <ng-container> e <ng-content>.

Ao tentar buscar respostas para minhas perguntas, descobri o conceito de <ng-template>. Para minha surpresa, também havia um *ngTemplateOutlet. Comecei minha jornada à iluminação sobre os dois conceitos e, agora, tinha quatro conceitos que pareciam a mesma coisa!

Você já esteve na mesma situação? Caso isso tenha acontecido com você, está no lugar certo. Sem mais delongas, vamos examinar um por um.

1. <ng-template>

Como o nome sugere, <ng-template> é um elemento de template (em português, modelo) que o Angular usa com as diretivas estruturais (*ngIf, *ngFor, [ngSwitch] e as diretivas personalizadas).

Esses elementos de modelo, ou template, funcionam apenas na presença de diretivas estruturais. O Angular envolve o elemento host (ao qual a diretiva é aplicada) dentro de <ng-template> e consome <ng-template> no DOM final substituindo-o por comentários de diagnóstico.

Considere um exemplo simples de *ngIf:

1_5QM2oe5GQVf7HATJxrX8Cw
Exemplo 1- processo do Angular de interpretação das diretivas estruturais

Acima, vemos a interpretação do Angular para *ngIf. O Angular coloca o elemento host, ao qual a diretiva é aplicada, dentro de <ng-template> e mantém o host como está. O DOM final é semelhante ao que vimos no começo deste artigo:

1_y2SVXFRl57rxi5wr-FzKvA
Exemplo 1- DOM final renderizado

Uso:

Vimos como o Angular usa <ng-template>, mas e se quiséssemos usá-lo? Como esses elementos funcionam apenas com uma diretiva estrutural, podemos escrever:

1_FLw4KCyW4vU1NupwP1z1uQ
Exemplo 2- usando <ng-template>

Aqui, home é uma propriedade boolean do componente definida com o valor true. O resultado do código acima no DOM é:

1_Iki7GXryxU_o9gCuGte0YA
Exemplo 2- DOM final renderizado

Nada foi renderizado! :(

Por que não conseguimos ver nossa mensagem mesmo depois de usar <ng-template> corretamente com uma diretiva estrutural?

Esse era o resultado esperado. Como já havíamos discutido, o Angular substitui <ng-template> por comentários de diagnóstico. Sem dúvidas, o código acima não geraria erros, pois o Angular está confortável com o caso de uso. Você jamais saberia o que aconteceu de fato internamente.

Vamos comparar os dois DOMs acima que foram renderizados pelo Angular:

1_y2SVXFRl57rxi5wr-FzKvA-1
1_Iki7GXryxU_o9gCuGte0YA-1
Exemplo 1 x Exemplo 2

Se olhar mais de perto, verá que existe uma tag de comentário extra no DOM final do Exemplo 2. O código que o Angular interpretou foi:

1_Nrmv3ivT8fB-h3qMS8gzkw
Processo de interpretação do Angular para o Exemplo 2

O Angular envolveu o <ng-template> de host dentro de outro <ng-template> e converteu não apenas o <ng-template> externo em comentários de diagnóstico, mas o interno também! É por isso que não foi possível ver sua mensagem.

Para se livrar disso, há duas maneiras de obter seu resultado desejado:

1_WSp1Iep84HFY9iOM1TLPDw
Uso correto do <ng-template>

Método 1:

Neste método, você fornece ao Angular um formato "sem rodeios", que não necessita de mais processamento. Neste caso, o Angular somente converteria <ng-template> em comentários, mas deixaria o conteúdo dentro dele intocado (O conteúdo já não está dentro de <ng-template> como estaria no caso anterior). Assim, ele será renderizado corretamente.

Para saber mais sobre como usar esse formato com outras diretivas estruturais, consulte este artigo (em inglês).

Método 2:

Este é um formado visto muito pouco e raramente usado (com dois <ng-template> irmãos). Aqui, damos uma referência de template a *ngIf em seu then para informar a ele qual template deve ser usado se a condição for verdadeira.

Usar vários <ng-template> assim não é recomendado (você pode usar <ng-container> em vez disso), já que não é para isso que ele serve. Ele é usado como um contêiner para templates que podem ser reutilizados em diversos locais. Trataremos mais sobre isso em uma seção posterior deste artigo.

2. <ng-container>

Você já escreveu ou viu algum código que se pareça com isso:

1_xSzfSSecltMEvHbwKoTlhQ
Exemplo 1

O motivo pelo qual muitos de nós escrevemos código assim é a incapacidade de usar diversas diretivas estruturais em um único elemento host no Angular. Agora, esse código funciona bem, mas introduz várias <div> adicionais vazias ao DOM se item.id for um valor falso que pode não ser obrigatório.

1_EZDOC5gDjhx0y-2pMGgP1A
Exemplo 1- DOM final renderizado

Pode ser que você não se preocupe com um exemplo simples como esse, mas, para uma aplicação maior, com um DOM mais complexo (exibindo dezenas de milhares de dados), isso pode passar a ser um problema, já que os elementos podem ter listeners associados a eles que ainda estarão lá, no DOM, escutando os eventos.

O que é pior: imagine o nível de aninhamento necessário para aplicar a estilização (CSS)!

1_sTllfe9eYy24VzWXEVZMew
Imagem extraída de: Inside Unbounce

Sem problemas. É quando <ng-container> aparece para salvar o dia!

O <ng-container> do Angular é um elemento de agrupamento que não interfere nos estilos ou no layout, pois o Angular não o coloca no DOM.

Assim, se escrevermos o Exemplo 1 com <ng-container>, teremos:

1_j-TJRTA11OrLKdLrmrjQjA
Exemplo 1 com <ng-container>

O DOM final seria:

1_7D-if7f35ct3vkY3AnozUQ
DOM final renderizado com <ng-container>

Percebeu que nos livramos das <div> vazias? Devemos usar o <ng-container> quando queremos apenas aplicar várias diretivas estruturais sem introduzir elementos extras ao DOM.

Para mais informações, consulte a documentação (em inglês). Existe um outro caso de uso, em que ele é usado para injetar um template dinamicamente em uma página. Trataremos desse caso de uso na última seção do artigo.

3. <ng-content>

<ng-content> é usado para criar componentes configuráveis. Isso significa que os componentes podem ser configurados, dependendo das necessidades do usuário. Essa situação é bem conhecida como projeção de conteúdo. Os componentes que são usados em bibliotecas publicadas fazem uso de <ng-content> para se tornar configuráveis.

Considere um componente <project-content> simples:

1_gzHVRbeW6JYv3XUxX5tQRA
Exemplo 1- definição de <project-content>
1_HIp3l46s5LRIPS8Cs3ZPlg
Projeção de conteúdo com o componente <project-content>

O conteúdo em HTML passado dentro das tags de abertura e de fechamento do componente <project-content> é o conteúdo a ser projetado. É a isso que chamamos de projeção de conteúdo. O conteúdo será renderizado dentro de <ng-content>, dentro do componente. Isso permite que o consumidor do componente <project-content> passe um footer personalizado dentro do componente e controle exatamente a maneira como ele quer que o footer seja renderizado.

Projeções múltiplas:

E se você pudesse decidir qual conteúdo deve ser colocado em qual posição? Em vez de todo conteúdo ser projetado dentro de um único <ng-content>, você também pode controlar a maneira como o conteúdo será projetado com o atributo select de <ng-content>. Ele recebe um seletor de elementos para decidir qual conteúdo deve projetar em um <ng-content> específico.

Aqui vemos como:

1_G6Ruc21MJctpiYqkdD5DjQ
Exemplo 2- diversas projeções de conteúdo com o <project-content> atualizado

Modificamos a definição de <project-content> para que realize diversas projeções de conteúdo. O atributo select decide o tipo de conteúdo que será renderizado dentro de um <ng-content> específico. Aqui, temos o primeiro select renderizando o elemento de título h1. Se o conteúdo projetado não tiver um elemento h1, nada será renderizado ali. Da mesma forma, o segundo select procura por uma div. O resto do conteúdo é renderizado dentro do último <ng-content> que não tem um select.

A chamado ao componente teria essa aparência:

1_rZar8_BvO5g53BQVJS36aQ
Exemplo 2- chamada ao componente <project-content> em um componente pai

4. *ngTemplateOutlet

…Ele é usado como um contêiner para templates que podem ser reutilizados em diversos locais. Trataremos mais sobre isso em uma seção posterior deste artigo.

…Existe um outro caso de uso, em que ele é usado para injetar um template dinamicamente em uma página. Trataremos desse caso de uso na última seção do artigo.

Esta é a seção onde discutiremos os dois pontos acima, mencionados anteriormente. *ngTemplateOutlet é usado para dois cenários — inserir um template comum em diversas seções de uma view, não importando os laços ou condições, e criar um componente altamente configurável.

Reutilização de um template:

Considere uma view em que você precise inserir um template em diversos lugares. Por exemplo, o logotipo de uma empresa em um site da web. Podemos conseguir isso escrevendo o template para o logotipo uma vez e reutilizando-o em todos os locais da view.

A seguir, vemos o trecho de código para isso:

1_M2mxgv1g3VcftdHOFFmTdw
Exemplo 1- reutilização do template

Como você pode ver, simplesmente escrevemos o template do logotipo uma vez e o utilizamos três vezes na mesma página com uma única linha de código!

*ngTemplateOutlet também aceita um objeto de contexto, que pode ser passado para personalizar o que é exibido por um template comum. Para obter mais informações sobre o objeto de contexto, consulte a documentação oficial (em inglês).

Componentes personalizáveis:

O segundo caso de uso para *ngTemplateOutlet é o dos componentes altamente personalizáveis. Considere nosso exemplo anterior do componente <project-content> com algumas modificações:

1_AwPv-pFH7e-Abhr-odvPyQ
Exemplo 2- tornando o componente project-content.html personalizável

Acima, vemos a versão modificada do componente <project-content>, que aceita três propriedades de entrada — headerTemplate, bodyTemplate e footerTemplate. A seguir, vemos o trecho para project-content.ts:

1_KHFWhtDmaysZMxGDTT_61Q
Exemplo 2- tornando o componente project-content.ts personalizável

O que estamos tentando conseguir aqui é mostrar os elementos header, body e footer do modo como são recebidos do componente pai de <project-content>. Se qualquer um deles não for fornecido, o componente exibirá o template padrão em seu lugar. Assim, criamos um componente altamente personalizável.

Para usarmos o componente que acabamos de modificar:

1_13rIyei1HqPdOsQ44l9tug
Exemplo 2- usando o componente que acaba de ser modificado, <project-content>

É assim que passaremos as referências do template para nosso componente. Se alguma delas não for passada, o componente renderizará o template padrão.

ng-content x *ngTemplateOutlet

Ambos nos ajudarão a obter componentes altamente personalizáveis, mas qual deles escolheremos e quando faremos isso?

Pode-se ver, claramente, que *ngTemplateOutlet nos dá uma capacidade maior de mostrar o template padrão se nenhum componente for fornecido.

Não é o que ocorre com ng-content. Ele renderiza o conteúdo como ele está. No máximo, é possível dividir o conteúdo e renderizá-lo em locais diferentes da view com a ajuda do atributo select. Não é possível renderizar condicionalmente o conteúdo dentro de ng-content. Você precisa mostrar o conteúdo que é recebido do elemento pai sem poder decidir com base no conteúdo.

Porém, a escolha de um ou de outro depende totalmente de seu caso de uso. Pelo menos, agora, você tem uma nova ferramenta, *ngTemplateOutlet, que poderá usar para ter mais controle sobre o conteúdo, juntamente com os recursos de ng-content!

]]> <![CDATA[ Como configurar o VS Code para melhorar sua produtividade ]]> https://www.freecodecamp.org/portuguese/news/como-configurar-o-vscode-para-melhorar-sua-produtividade/ 624b689a6daab205304b00aa Tue, 05 Apr 2022 00:12:16 +0000 Artigo original: How to set up VSCode to improve your productivity

Escrito por: Chiamaka Ikeanyi

Os editores de código evoluíram com o passar dos anos. Há alguns anos, não havia o Visual Studio Code (VS Code). Na época, provavelmente, você usava o Sublime Text, o Atom, o Brackets etc. Porém, com o lançamento do VS Code, ele se tornou o editor de código favorito da maioria dos desenvolvedores.

Por que usar o VS Code?

Os desenvolvedores preferem o VS Code porque:

  • É personalizável
  • Torna fácil a depuração
  • Emmet
  • Extensões
  • Integração com o Git
  • Terminal integrado
  • Intellisense
  • Temas e mais…

Agora que você viu as vantagens de usar o VS Code, este artigo tratará da configuração do VS Code e das extensões necessárias ao usar o VS Code para se ter o máximo de produtividade.

Terminal

No Mac, você pode configurar seu terminal para que use o iTerm2 e o ZSh e fazer com que o VS Code o utilize também.

Após configurar o Zsh, abra o terminal integrado do VS Code Terminal > New Terminal e execute o comando

source ~/.zshrc

ou

. ~/.zshrc

para rodar o conteúdo do arquivo de configuração .zshrc no shell.

Fonte

FiraCode parece interessante por causa do suporte a ligaduras de texto. Baixe e instale a fonte FiraCode, e adicione-a ao seu arquivo settings.json.

vqdv5dokMCcD5yivbaPUBTtYsWBiUIMo6gZ6
"editor.fontFamily": "Fira Code","editor.fontLigatures": true,

Abrindo pela linha de comando

Abrir o VS Code a partir do terminal parece interessante. Para fazer isso, pressione CMD + SHIFT + P (no Mac), digite shell command e selecione Install code command in path (Instalar o comando do VS Code no path). Depois disso, navegue até qualquer projeto a partir do terminal e digite code . no diretório para abrir o projeto usando o VS Code.

Configuração

As configurações do VS Code que não são específicas de um espaço de trabalho estão no arquivo settings.json. Você pode configurar o VS Code para se ajustar às suas preferências.

Para abrir o arquivo settings.json, pressione

CMD ou Ctrl + ,

Copie e cole o código abaixo no arquivo settings.json:

{    "editor.multiCursorModifier": "ctrlCmd",    "editor.formatOnPaste": true,    "editor.wordWrap": "bounded",    "editor.trimAutoWhitespace": true,    "editor.fontFamily": "Fira Code",    "editor.fontLigatures": true,    "editor.fontSize": 14,    "editor.formatOnSave": true,    "files.autoSave": "onFocusChange",    "emmet.syntaxProfiles": {        "javascript": "jsx"    },    "eslint.autoFixOnSave": true,    "eslint.validate": [        "javascript",        "javascriptreact"    ],    "javascript.validate.enable": true,    "git.enableSmartCommit": true,    "files.trimTrailingWhitespace": true,    "editor.tabSize": 2,    "gitlens.historyExplorer.enabled": true,    "diffEditor.ignoreTrimWhitespace": false,    "workbench.sideBar.location": "right",    "explorer.confirmDelete": false,    "javascript.updateImportsOnFileMove.enabled": "always",}

Extensões

Abaixo temos algumas extensões úteis que podem melhorar sua experiência de desenvolvimento ao trabalhar com uma base de código.

Para acessar essas extensões,

  • Vá para View -> Extensions
  • Procure por extensões no Marketplace
  • Clique em Install

1. Auto Import

Com essa extensão, você não precisará importar arquivos manualmente. Se estiver trabalhando com um projeto baseado em componentes, basta digitar o nome do componente e ele será importado automaticamente.

d88RTDvyIzGWYC5BuLcnIaFOjHiyDMaqE5Bh

2. Add jsdoc comments

Essa extensão adiciona blocos de comentário ao código. Para usá-la, realce a primeira linha da função, pressione CMD/Ctrl + SHIFT + P e selecione Add Doc Comments (Adicionar comentários aos documentos).

jlJk05MHt3HknnqZyKQB-8d1Oj7qgh7ZOBGL

3. ESDoc MDN

Em alguns cenários, podemos esquecer como algumas coisas funcionam. É nesse caso que a extensão a seguir se torna útil. Não é preciso abrir seu navegador para encontrar a sintaxe. Basta digitar

//mdn [objeto].[método];
r8pUHOgNQwAyNq0DU9VPcL5xb8zGgT1ybCZV

4. CSS Peek

Como o próprio nome sugere, essa extensão ajuda você a conferir as regras aplicadas ao estilo definido na base de código e sua especificidade. Ela é útil quando trabalhamos com bases de código legadas.

7orGFqwr8mdQPOVPuQVMTlRO8XtPgnR0Ggmj

5. GitLens

A extensão GitLens aumenta o que você pode conseguir com o Git. Ela ajuda você a fazer muito mais, como explorar os repositórios do Git sem interrupções, dar uma olhada nas revisões de código, autoria e muito mais.

Sf2hWdpXSF7CPBhmQ9sTf9zGPD-OiXQsf2aM

6. ESLint

Essa extensão integra o ESLint no VS Code para usar o lint em seus códigos. O projeto no qual você está trabalhando precisa ter o ESLint instalado localmente o globalmente para aproveitar os recursos que essa extensão oferece.

Para instalar o ESLint localmente, execute

npm install eslint

ou instale-o globalmente usando

npm install -g eslint

Você também precisa criar o arquivo de configuração .eslintrc. Se você instalou o ESLint localmente, execute

./node_modules/.bin/eslint --init

ou

eslint --init

para a instalação global.

7. Debugger for Chrome

Essa extensão permite que você faça a depuração de seu código em JavaScript diretamente no navegador do Google Chrome.

O4SSLTXtEEdU3AjZODIdUKG7AYao27y6O7jq

8. Google Fonts

Adicionar as fontes do Google é mais fácil com essa extensão. Você não precisa mais procurar pelas fontes com o navegador. Para acessar uma lista de fontes, pressione CMD/Ctrl + SHIFT + P e procure por Google fonts para continuar.

sqVCRBo5mlEUjIFcSsp28oEo4ugo3LMXjKoS

9. TODO Highlight

Com tanto trabalho naquilo que precisa ser priorizado, às vezes, tendemos a esquecer tarefas que ainda precisam se concluídas. A extensão TODO Highlight torna mais fácil vê-las ao destacá-las.

10. Docker

Você pode criar Dockerfiles na hora com essa extensão. Ela também fornece realce de sintaxe, intellisense e muito mais.

Pressione CMD/Ctrl + SHIFT + P e procure por Add Docker files to workspace (Adicionar arquivos do Docker ao espaço de trabalho).

Yv09L4W8lraVLXLr-aYpCHz8hfLC-tuORELa-1

11. Code Spellchecker

Essa extensão é útil na identificação de erros tipográficos dentro da base de código.

12. Import Cost

Import Cost mostra o impacto de pacotes importados dentro do código. Ela ajuda a medir gargalos de desempenho.

4Xl2OdUzPmPFW54eqzrHz59Kg9qSFbCDxUWf

13. HTMLHint

Essa extensão valida seu HTML ajudando você a escrever código em conformidade com os padrões.

ZJN4LadCSa6e1EVHlEMs7gB1f4AVINChBxaY

14. Peacock

Essa extensão dá a você a capacidade de alterar a cor de seu espaço de trabalho. Ela é ideal para quando você têm diversas instâncias do VS Code e quer identificar rapidamente uma instância específica.

BRiUh7NQh1PdVW7aP5mZJcnbzZFaCQcblYpq

Após instalar o Peacock, clique no ícone das configurações, vá para elas, selecione a guia das configurações do espaço de trabalho, clique em {} e cole o código abaixo.

{    "workbench.colorCustomizations": {        "activityBar.background": "#e90b8d",        "activityBar.foreground": "#fff",        "activityBar.inactiveForeground": "#b5b5b5",    },    "peacock.affectedElements": [        "activityBar",    ]}

Você também pode adicionar titleBar e statusBar aos affectedElements e adicionar personalizações de cor para as barras de títulos e de status dentro da seção colorCustomizations.

Para usar uma das cores padrão, pressione CMD/Ctrl + SHIFT + P, digite peacock e selecione seu tema favorita. Isso sobrescreve as configurações de cor dentro do arquivo settings.json definidas para aquele espaço de trabalho.

15. Prettier

Você sempre pressiona a barra de espaço ou a tecla Tab ao programar? O Prettier pode ajudar você. Ele formata as linhas de código e as torna mais legíveis.

Confira as coisas incríveis que você pode fazer com o Visual Studio Code aqui (em inglês).

Fique à vontade para deixar um comentário sobre o que dá certo para você e compartilhe este artigo.

Você também pode conferir o blog do autor para ver mais de seus artigos.

]]> <![CDATA[ Passei 3 meses buscando emprego após um bootcamp de programação. Foi isso que eu aprendi. ]]> https://www.freecodecamp.org/portuguese/news/passei-3-meses-buscando-emprego-apos-um-bootcamp-de-programacao-foi-isso-que-eu-aprendi/ 61b78886f15c8104f2fda0d1 Mon, 13 Dec 2021 22:10:21 +0000 Artigo original: I spent 3 months applying to jobs after a coding bootcamp. Here’s what I learned.

Uma parte menos discutida sobre a jornada de quem faz um bootcamp é o que acontece depois de você concluir o programa — quando começa a procurar um emprego como desenvolvedor que o deixe bem financeiramente.

85L921BMzXxKhVySPo9gxWamr5J4QLFJaVEn
Menos de 3% das procuras por emprego se tornam ofertas de emprego de fato

Concluí o Hack Reactor em julho de 2016 e levou quase 3 meses antes de eu aceitar uma oferta da Radius Intelligence. Me inscrevi para uma vaga em 291 empresas, fiz 32 entrevistas por telefone, 16 entrevistas técnicas, 13 desafios de programação, 11 entrevistas no local e recebi 8 ofertas de emprego. As ofertas iam de US$60 a 125 mil em termos de salário anual de empresas de todos os EUA, tanto para funções em front-end como em full-stack. No total, 2,8% das minhas tentativas viraram ofertas.

Aqui vão 5 coisas que eu gostaria de saber antes de começar a procurar um emprego.

Insight nº 1: converse com pessoas reais

Primeiro, eu me inscrevi em empresas usando a abordagem de "atirar para todo o lado". Me inscrevi usando o Indeed.com, o AngelList, o LinkedIn, o StackOverflow, o Hacker News, sites de empresas e, até mesmo, o Craigslist.

Eu costumava enviar meu currículo para qualquer função que quisesse experiência com React, Node ou JavaScript. Na primeira semana, eu me inscrevia em 15 a 20 empresas por dia.

Dica profissional: encontre empresas usando este repositório que auxilia com a inscrição.

Meu retorno foi baixo. Menos de 5 por cento das empresas me responderam. Eu estava enviando currículos para um buraco negro.

Tudo mudou quando um conhecido meu, que já havia sido um recrutador no passado, compartilhou um guia para a busca de empregos. Ele disse que o ideal é enviar e-mails para pessoas reais diretamente a cada vez que nos inscrevêssemos para um emprego. Não importa para quem fosse, contanto que alguém do outro lado lesse a mensagem.

Desse momento em diante, sempre que enviei meu currículo, procurei a empresa no LinkedIn e mandei um e-mail para alguém da equipe de engenharia ou do RH.

Para a maioria das empresas menores ou para executivos do nível de chefia, o formato do endereço de e-mail costuma ser nome@empresaDosSonhos.com. Para grandes empresas, nome.sobrenome@empresaDosSonhos.com.

Para verificar os endereços de e-mail, eu usava o Rapportive e fazia a checagem dos e-mails com as contas das mídias sociais.

Os resultados foram incríveis. Como mais de 150 e-mails enviados, minha taxa de resposta foi de impressionantes 22%.

Foi uma sensação muito boa ter o retorno de pessoas reais. Para minha surpresa, CEOs e CTOs responderam os e-mails. Algumas vezes, até eram eles mesmos que me entrevistavam.

Moral da história: se quiser se inscrever para vagas entrando pela porta da frente, certifique-se de entrar em contato direto com os "seres humanos" da empresa.

Insight nº 2: comece de baixo e vá subindo

Você enfrentará entrevistas de nível 1 (uma empresa fora da área de tecnologia que precisa de um desenvolvedor qualquer), onde os entrevistadores não pedirão nada além de perguntas triviais sobre JavaScript.

Você enfrentará entrevistas de nível 9 (nível Google/Facebook), onde os entrevistadores fazem perguntas difíceis sobre algoritmos e estruturas de dados.

Defini meu processo estrategicamente de modo a fazer as entrevistas de nível mais baixo antes e deixar para depois as de mais alto nível.

Assim, cedo, eu ganhei experiência, aprendi a ter confiança e garanti ofertas de empresas que tinham entrevistas menos intensas.

Ao ganhar mais experiência, eu fui efetivamente "subindo de nível". Me tornei capacitado a completar entrevistas em empresas onde a expectativa era mais alta. Isso é ilustrado abaixo como uma correlação linear entre o número de semanas que passei no processo de busca e o salário base que me foi oferecido.

bDp3eVv6VQS3Og3ulVpwp6dDylIybdpRczsD
Há uma correlação direta entre o tempo que eu passei em entrevistas e a oferta de salário.

Eu "desbloqueei" perguntas mais difíceis. Desbloqueei salários mais altos e, no fim, desbloqueei o emprego que eu aceitei.

Moral da história: lide com as entrevistas mais fáceis primeiro e com as mais difíceis depois.

Insight nº 3: estude como se seu futuro dependesse disso (porque, de fato, depende)

Detesto ter de ser eu a informar você a respeito disso, mas a coisa mais importante que você pode fazer a qualquer momento do processo é estudar e se preparar.

Por quê? Porque você não vai receber nenhuma oferta se não tiver boas respostas às perguntas que farão a você.

As pessoas não voltarão a procurar você se não acharem que está preparado para as entrevistas.

Ao sair do Hack Reactor, meu ponto fraco eram os algoritmos e estruturas de dados. Um estudo da Triplebyte descobriu que aqueles que se formam em bootcamps tinham menos facilidade nessas áreas que os que se formam em Ciência da Computação.

Então, eu fui aprender e praticar. Todos os dias.

Dediquei dias inteiros a aprender algoritmos de ordenação. Em outros dias, busquei entender como funcionava a internet.

Se eu não entendia um conceito por completo, passava o dia assistindo vídeos no YouTube ou pesquisando no StackOverflow até entender.

Achei os materiais de estudo a seguir muito úteis:

  • InterviewCake: meu recurso favorito para algoritmos e estruturas de dados. Eles dividem a solução em partes, passo a passo — uma ótima alternativa ao Cracking the Code Interview (CTCI). Minha única queixa estava no fato de eles não terem mais problemas para resolver!
  • Seção de Design de sistemas da HiredInTech: um ótimo guia para perguntas de entrevistas sobre design de sistemas.
  • Coderust: se você está evitando o CTCI com todas as suas forças, o Coderust 2.0 pode ser a saída perfeita para você. Por US$49, você obtém soluções em quase todas as linguagens de programação, com diagramas interativos.
  • Como se preparar para entrevistas em tecnologia do Reddit: usei constantemente esse site como régua de medição para meu nível de preparação.
  • Front End Interview Questions: Uma lista extensa de perguntas sobre front-end.
  • Leetcode: o recurso ideal para perguntas sobre algoritmos e estruturas de dados. Você pode filtrar por empresa. Desse modo, por exemplo, você pode ver todas as perguntas que a Uber ou o Google geralmente fazem.
Moral da história: não existe algo do tipo "preparação em excesso".

Insight nº 4: mostre o seu melhor ângulo

Entrar no setor é difícil. Você precisa ter um bom desempenho, mesmo quando não está totalmente preparado. Para ter sucesso, você precisa ser seu próprio advogado.

Venda seu peixe

No Hack Reactor, fomos treinados a mascarar nossa inexperiência. Em nossas narrativas pessoais, omitíamos de propósito nossa educação em um bootcamp.

Por quê? Porque se fizéssemos o contrário, as empresas nos classificariam automaticamente como desenvolvedor júnior ou nos rotulariam como "sem experiência suficiente".

Em uma entrevista com uma startup, a entrevista já deu errado no momento em que perceberam que eu havia feito um bootcamp. Uma empresa usou isso contra mim e me fez uma oferta de US$60 mil, contrastando com outros desenvolvedores júnior.

No fim, você precisa convencer as empresas de que você consegue realizar as tarefas.

Ao mesmo tempo, é preciso convencer a si mesmo de que consegue realizar as tarefas.

Você consegue. Concentre-se no seu amor pela programação. COncentre-se no que você já criou com React e Node. Concentre-se em demonstrar seu grande conhecimento em JavaScript e em qualquer outra linguagem que tenha aprendido.

É somente nesse momento que eles podem justificar dar a você a vaga.

Entrevistas são uma investigação mútua de acerto entre um empregador e um empregado. Embora seja sua tarefa convencer os empregadores a contratar você, também é a tarefa deles fazer você ter vontade de trabalhar com eles.

Não tenha vergonha de usar a entrevista como uma chance de avaliar a oportunidade de emprego.

Eu fazia perguntas sobre qualquer uma das empresas, mesmo aquelas nas quais eu tinha pouco interesse.

Eu fiz entrevistas presenciais em quase todo o país e com qualquer empresa que me convidasse. Eu fazia perguntas e absorvia o conhecimento sobre a organização da equipe de engenharia, sobre as tecnologias e as ferramentas utilizadas, sobre os desafios da empresa e sobre a arquitetura do sistema.

Dica profissional: Durante as entrevistas, faça as seguintes perguntas:
Quais são alguns dos desafios técnicos que vocês vêm enfrentando ultimamente?
De que você gosta mais ao trabalhar na empresa X?
Como são estruturadas as equipes e como as tarefas são divididas em geral?

Tratei cada interação como uma oportunidade de aprendizado. Cada interação me ajudou a melhorar minha apresentação, capacidade de lidar com entrevistas e habilidades técnicas. Cada insucesso me ajudou a encontrar meus pontos fracos.

Moral da história: não se menospreze! E lembre-se, é uma investigação mútua.

Insight nº 5: é uma corrida de resistência, não de velocidade

O caminho não é, de jeito algum, fácil. Por 3 meses, eu estudei sem descanso 6 dias por semana. Mas eu me esforcei para cuidar de mim.

JCemFdVueUTGuA294JVs-b0pc5iPf3INw3ve
Um dia como qualquer outro, só que em JavaScript

Havia dias em que eu estudava com os amigos. Em outros, eu ia a um café estudava por minha conta, ou ia para a sala dos ex-alunos do Hack Reactor para me juntar aos outros. A cada semana, eu visitava nosso consultor de carreiras para falar sobre o andamento do processo.

É fácil chegar à exaustão nesse processo. Por isso, coma bem, durma o suficiente e faça exercícios.

Pode ser bastante solitário. Passe um tempo com amigos que estejam passando pela mesma experiência.

Moral da história: prepare-se para uma competição longa e não se esqueça de cuidar de você mesmo.

Em resumo, as lições mais importantes são:

  1. Converse com pessoas reais
  2. Comece de baixo e vá subindo
  3. Estude como se seu futuro dependesse disso
  4. Mostre seu melhor ângulo
  5. É uma corrida de resistência, não de velocidade

O processo pode parecer interminável, mas você terá sucesso. Comece dedicando horas a isso. Siga enviando currículos. Continue cuidando de si mesmo. Tudo isso vale a pena no final.

Um agradecimento especial a Dylan Tran, Karen Zhao, Rohit 'Sunny' Rekhi, Jake Pace, Anamita Guha, Stephanie Liu e a tantas outras pessoas.

Compartilhe com seus amigos que estiverem procurando emprego no momento.

]]> <![CDATA[ Os 10 sites da web mais populares com desafios de programação [Atualizado para 2021] ]]> https://www.freecodecamp.org/portuguese/news/os-10-sites-da-web-mais-populares-com-desafios-de-programacao/ 61586b0a93a1630527b88eb0 Thu, 07 Oct 2021 10:00:00 +0000 Artigo original: The 10 Most Popular Coding Challenge Websites

Uma ótima maneira de desenvolver suas habilidades ao aprender a programar é resolvendo desafios. Resolver tipos diferentes de desafios e enigmas pode ajudar você a melhorar suas habilidades na solução de problemas, aprender as especificidades de uma linguagem de programação, se preparar para entrevistas de emprego, aprender algoritmos novos e mais.

Abaixo, vemos uma lista de sites de desafios de programação conhecidos com uma breve descrição do que é oferecido por cada um.

1. TopCoder

MTryRL4uVza1V87ERWY26L4cFeqD2rgAnW1f

O TopCoder é uma das plataformas on-line originais de programação competitiva. Lá, você encontra uma lista de desafios com algoritmos do passado que você pode resolver por conta própria, on-line e diretamente, usando seu editor de código. As Single Round Matches do site são populares e oferecidas algumas vezes ao mês em horas específicas. Nelas, você pode competir contra os outros resolvendo desafios o mais rápido possível para ter as melhores pontuações.

Os usuários com a melhor classificação no TopCoder são programadores e competidores muito bons que participam regularmente de competições de programação. O usuário com a melhor classificação tem seu próprio blog, chamado Algorithms weekly by Petr Mitrichev, onde ele escreve sobre as competições de programações, algoritmos, matemática e mais.

2. Coderbyte

sP6ow4n2alliqp5L-p5fVRQC9W0GTws1B9Ig

O Coderbyte oferece mais de 200 desafios de programação, que você pode resolver diretamente on-line em uma entre 10 linguagens de programação (confira este exemplo). Os desafios vão de fáceis (encontrar a maior palavra em uma string) a difíceis (imprimir a correspondência de maior cardinalidade em um grafo).

Eles também oferecem uma coleção de tutoriais de algoritmos, vídeos introdutórios e cursos de preparação para entrevistas. Diferente do HackerRank e de outros sites da web semelhantes, você pode ver soluções de outros usuários para qualquer um dos desafios, além das soluções oficiais publicadas pelo Coderbyte.

3. Project Euler

plhA-E3btLLYRvc4hi3WxmUpAhu3aoef1o0V

O Project Euler fornece uma grande coleção de desafios relacionados à ciência da computação e da matemática. Os desafios tipicamente envolvem escrever um pequeno programa para descobrir a solução para uma fórmula matemática ou equação interessante, como encontrar a soma dos dígitos de todos os números que precedem cada número em uma série.

Você não pode programar a solução diretamente no site em um editor de código, mas precisa escrever uma solução em seu próprio computador e enviar a solução para o site.

4. HackerRank

dOpMtufto0gLZiyDOHZ4BVF58S-z393wRlcu

O HackerRank fornece desafios para vários domínios diferentes, como Algoritmos, Matemática, SQL, Programação Funcional, AI e mais. Você pode resolver todos os desafios diretamente on-line (confira este exemplo). Eles fornecem uma discussão e um quadro de melhores pontuações para cada desafio. A maioria dos desafios tem um editorial que explica mais sobre o desafio e sobre como abordá-lo para chegar a uma solução. Apesar do editorial, não é possível ver, no momento, as soluções dos outros usuários no HackerRank.

O HackerRank também dá a possibilidade de os usuários enviarem inscrições e se inscreverem para empregos por meio da solução de desafios de programação patrocinados por algumas empresas.

5. CodeChef

81eunsDYPAqBSC8KwPpBxhPFTHiqGXp70kMa

O CodeChef é um site indiano de programação competitiva que fornece centenas de desafios. Você consegue escrever o código em um editor on-line e ver uma coleção de desafios separados em categorias diversas, dependendo do seu nível de habilidade (veja este exemplo). Eles têm uma grande comunidade de programadores que contribuem nos fóruns, escrevem tutoriais e participam das competições de programação do CodeChef.

6. Exercism.io

Screen-Shot-2019-12-11-at-8.14.45-AM

O Exercism é um site de desafios de programação que oferece mais de 3100 desafios em 52 linguagens de programação diversas. Depois de escolher a linguagem que você quer dominar, você faz os desafios de programação diretamente de sua máquina (o Exercism tem sua própria interface de linha de comando que você pode baixar do GitHub).

Ele é um pouco diferente dos outros sites de desafios de programação, pois você pode trabalhar com um mentor após concluir cada desafio. O mentor revisa suas resposta on-line e ajuda você a melhorá-la, se necessário. Depois que suas respostas foram aprovadas e enviadas, você desbloqueia mais desafios.

7. Codewars

QR7cVhZ7FGb6HjaEDu4N5Co1eTMNTbo1JFzq

O Codewars tem uma grande coleção de desafios de programação enviados e editados por sua própria comunidade. Você pode resolver os desafios on-line diretamente no editor do site em várias linguagens. Você pode ver as discussões de cada um dos desafios, bem como as soluções dos outros usuários.

8. LeetCode

RzWKVwPaLY2SRsWFWk93ZNlzcg8V0Yeav5t7

O LeetCode é um juiz on-line conhecido, que fornece uma lista de mais de 190 desafios que podem ajudar você a se preparar para entrevistas técnicas de emprego. Você pode resolver os desafios diretamente on-line em uma das 9 linguagens de programação. Você não pode ver as soluções dos outros usuários, mas recebe estatísticas para suas soluções, como a velocidade de execução do seu código em comparação com os códigos de outros usuários.

Eles também têm uma seção de simulação de entrevista, as Mock Interviews, especificamente para a preparação para entrevistas de emprego. O site hospeda suas próprias competições de programação, além de ter uma seção para os artigos que vão ajudar você a entender melhor determinados problemas.

9. SPOJ

MF3wP06V24C7jal2f8NRvAVhS-tAA2vbNDTL

O Sphere Online Judge (SPOJ) é um juiz on-line que fornece mais de 20 mil desafios de programação. Você pode enviar seu código por meio de um editor on-line. O SPOJ também hospeda suas próprias competições e tem uma área para os usuários discutirem os desafios de programação. No entanto, eles não fornecem soluções ou editoriais oficiais como outros sites similares.

10. CodinGame

6l08ZCKDOaoY1TH-PHHHac26McA-c1tIDOPU

O CodinGame é um pouco diferente dos outros sites, pois, em vez de simplesmente resolver desafios de programação em um editor, você participa, de fato, na criação de códigos para jogos que você joga on-line diretamente. Você pode ver uma lista dos jogos que são oferecidos no momento aqui e um exemplo de um deles aqui. O jogo vem com uma descrição do problema, casos de teste e um editor, onde você pode escrever seu código em uma das mais de 20 linguagens de programação.

Embora esse site seja diferente dos sites de programação competitiva típicos, como os mencionados anteriormente neste artigo, ele ainda é bem popular entre os programadores que gostam de resolver desafios e de participar de competições.

Esta lista foi baseada em algumas questões: as próprias experiências do autor no uso dos sites, algumas pesquisas no Google, publicações no Quora e artigos como este e este. O autor também frequentou alguns fóruns e subreddits, como o r/learnprogramming, para saber quais sites geralmente eram recomendados pelos usuários de lá. Aviso: o autor trabalha no Coderbyte, que é um dos sites mencionados acima.

]]>