DEV Community: Lara Carvalho

Como passar no AWS Certified Cloud Practitioner Exam

Lara Carvalho — Wed, 14 Jun 2023 21:28:32 +0000

Existem alguns benefícios em tirar uma certificação da AWS. Dentre se desenvolver credibilidade sobre seus conhecimentos, dar mais confiança a usuários recorrentes, você consegue demonstrar suas qualificações de nuvem de forma comprovada.

Tive o prazer de participar de uma ação da LinuxTips #CHamaAsMina para disseminar o conhecimento sobre AWS, onde eles disponibilizaram seu curso preparatório para o Certified Cloud Practitioner com um voucher 100% para o exame. Aproveitando essa oportunidade, comecei a estudar para tirar minha certificação. Já tinha interesse em realizar o AWS Certified Solutions Architect e pensei em usar essa experiência como aprendizado para a próxima vez.

Sobre o Exame

Segundo a página da certificação:

"O AWS Certified Cloud Practitioner oferece uma compreensão básica dos conceitos, serviços e terminologia da Nuvem AWS. Esse é um bom ponto de partida para indivíduos em funções não técnicas, sem experiência prévia com TI ou em nuvem, ou para aqueles com experiência em TI on-premises que buscam fluência básica na Nuvem AWS. Essa certificação pode dar aos candidatos a confiança necessária para enfrentar as certificações da AWS com base em função."

Essa é a certificação fundamental de nível básico, ela é recomendada para profissionais que tem ou não experiência na nuvem AWS e prevê preparar o candidato para conhecer mais os principais serviços e casos de uso da AWS, modelos de cobrança, conceitos de segurança e precificação de tais serviços. Apesar disso, o guia do exame recomenda que o candidato tenha 6 meses de experiência com a nuvem AWS.

Alguns dados gerais:

A prova dura 90 minutos
Para passar, você precisa acertar 70% da prova (isso dá 56 questões)
Conta com 65 perguntas de múltipla escolha (algumas podendo escolher várias respostas)
Custo de $100 dólares
Você pode optar por fazer a prova online ou em um centro autorizado de treinamento.

Para entender mais do exame, a Amazon disponibiliza um guia do exame com explicações sobre conceitos abordados. Além disso, conta também com um exemplo de perguntas (disponível em português!) para entender melhor como funciona a prova em si.

Preparação

Eu utilizo AWS há alguns anos, porém não foi um uso contínuo. Já trabalhei em empresas que usavam muitos serviços serverless, então o contato como dev era maior, e outra cujo contato era mais concentrado no time de DevOps, então não me considero expert na plataforma. Como ganhei um curso preparatório, resolvi começar por lá. Todos os dias estudava um assunto diferente e ia seguindo por lá.

Muitos serviços eu já utilizei no dia-a-dia, mas outros conhecia apenas por nome, porque não houve necessidade real em brincar com ele. Agora, a própria AWS conta com um curso preparatório oficial que pode ser acessado aqui.

Caso você consiga acompanhar em inglês, o freeCodeCamp liberou este video de 13h para estudar para o exame. Foi ele que usei logo depois do da LinuxTips para me preparar. Nos comentários existem alguns timestamps com a organização de cada tópico, então foi fácil navegar pelo video quando eu tinha dúvida em algum conceito.

Por último, achei melhor treinar com o que eu conseguia de provas então achei no Udemy este curso com 6 simulados de perguntas reais da prova onde eu poderia treinar quantas vezes eu quisesse. Ele sempre entra em promoção, então é possível consegui-lo por um preço acessível. Não ganho nada por recomendá-los, e vou trazer uma alternativa grátis, mas se você quer ter a experiência de prova, esses simulados são bem úteis.

Todas às vezes que eu fazia um simulado, eu lia todas as respostas (as que acertei e errei) porque eles trazem explicações do porquê de cada resposta estar errada/certa. Isso me fez entender melhor meus pontos fracos e buscar os dados corretos. Fui anotando tudo que eu achava confuso; nomes parecidos foram meu maior problema. Às vezes eu conhecia o serviço, mas os nomes me confundiam e acabava errando uma questão. Para quem tem dificuldade em gravar as coisas, repetir os simulados pode ajudar e muito!

Eu estudei por 1 mês de forma interrupta, então não foi todo dia que eu pegava e via um conteúdo novo. Às vezes só consegui estudar um dia na semana porque eu estou também estudando para uma especialização, então eu fazia o que podia.

No fim, fiz os 6 simulados 5 vezes. Aqui está a média das minhas notas cada vez que fiz:

Primeira vez: 66% (não havia terminado o curso);
Segunda vez: 75% (não havia terminado o curso);
Terceira vez: 79% (curso finalizado);
Quarta vez: 88% (curso finalizado);
Quinta vez: 94% (curso finalizado).

Apesar de não ser uma média super alta, meu objetivo era conseguir pelo menos 90% nos testes sabendo que teria uma margem para a prova. É claro, poderia buscar outros recursos, mas preferi jogar a favor dos meus pontos fortes.

Um último recurso que se tornou indispensável foi esse repositório com quase 600 questões do banco de perguntas da AWS. Analisar as perguntas e respostas aqui fez com que eu entendesse um pouco de perguntas que não estavam no grupo do curso do Udemy. Se você não quiser pagar pelo curso, consegue usar essa lista para simular um ambiente de prova, lembrando que são 65 questões em 90 minutos. É só separar algumas questões, colocar um timer e treinar!

Como é a prova de verdade?

Eu escolhi fazer a prova num local aprovado pela AWS e a Pearson por achar algumas das regras de prova online um pouco difíceis de garantir (falta de barulho, conexão constante, preparar a máquina, etc.).

Achei que seria mais complicado, eles são bem rígidos em exigir que você chegue com 15 minutos de antecedência, mas comigo acabei chegando cedo demais e o pessoal do local me permitiu até adiantar meu horário. Você entrará em uma sala com computadores preparados apenas para a prova, irá conectar com as suas credenciais e iniciar a prova. Tem um timer rolando e você pode revisar as perguntas antes de enviá-las para aprovação. Dependendo da sua prova, você recebe uma mensagem no fim dizendo se passou ou não, mas o resultado completo com o certificado só vem em até 5 dias úteis.

Eu achei a prova bem condizente com o material que estudei. Alguns tópicos eu não havia estudado, então provavelmente não fui bem neles, mas as perguntas das matérias e serviços que estudei estavam bem fáceis, então foi bem tranquilo para mim. No fim, minha nota final foi 855 (de 1000), então estou feliz com o resultado. Se você se importa em gabaritar, talvez um tempo extra de treino seja necessário.

Agora, sobre compreender mesmo os assuntos, todo esse esforço valeu a pena? Eu sinto que aprendi, sim, detalhes de vários serviços que havia usado antes, mas que não tinha me aprofundado. Aprendi mais sobre serviços que nunca havia trabalhado e entendi mais a filosofia de arquitetura da AWS.

Achei que a experiência valeu, sim, a pena, e depois que você obtém a certificação, você ganha algumas coisas como: 50% de desconto na próxima prova, acesso a uma comunidade de pessoas certificadas, o badge para mostrar sua certificação.

Conclusão

Espero que tenham curtido o que eu trouxe hoje. O post original pode ser encontrado aqui: https://laracarvalho.net/post/como-passar-aws-certified-cloud-practitioner/

Como usar error cause no Javascript e no Typescript

Lara Carvalho — Wed, 08 Mar 2023 14:11:09 +0000

Tratar erros nunca é uma tarefa divertida, principalmente no ecossistema Javascript onde precisamos tratar vários tipos de erros; HTTP, Node, milhares de bibliotecas...

Uma proposta relativamente recente me chamou bastante à atenção em relação ao tratamento de erros. Se trata da proposal-error-cause, já disponível nas versões mais atualizadas dos navegadores e do Node 16.9.0. De forma resumida, ela traz a razão, a causalidade de um erro específico.

Sabe quando precisamos fazer um fetch em uma API e precisamos tratar diversos erros como a própria falha da rota, bug em nossa implementação ou até mesmo um erro terceiro, que não previmos ainda? É uma loucura tratar isso tudo da forma tradicional, mas usando um exemplo descrito na própria proposta, podemos ver como esse tal error.cause pode nos ajudar:

async function doJob() {
  const rawResource = await fetch('//domain/resource-a')
    .catch(err => {
      throw new Error('Download raw resource failed', { cause: err })
    })

  const jobResult = doComputationalHeavyJob(rawResource)
  await fetch('//domain/upload', { method: 'POST', body: jobResult })
    .catch(err => {
      throw new Error('Upload job result failed', { cause: err })
    })
}

try {
  await doJob()
} catch (e) {
  console.log(e)
  console.log('Caused by', e.cause)
}
// Error: Upload job result failed
// Caused by TypeError: Failed to fetch

Além dos nossos logs tratados, recebemos exatamente a causa daquele erro estar sendo levantado. Isso resolve aquele problema de tentar encapsular erros em mensagens bonitinhas e acabar tirando um pouco da transparência que facilita um bom debugging.

Agora, tudo parece muito fácil, certo? Só começar a aplicar isso ao seu código e ser feliz. Na verdade, ainda não temos uma implementação dessa propriedade no Typescript até o momento (02/2023).

Se você tentar acessar a propriedade, receberá um erro dizendo que tal propriedade não existe na classe Error.

Isso porque o Typescript trabalha em cima de versões novas do ES e Node. Como essa proposta foi aprovada e adicionada à versão 16.9.0 do Node, e o time do Typescript adicionou essa mudança algum tempo depois, precisamos atualizar nosso tsconfig.

Veja o exemplo abaixo:

{
  "compilerOptions": {
    "lib": ["es2022"],
    ...
  },

Atualizando o compilerOptions.lib para ES2022, os erros em relação ao error.cause irão desaparecer e você irá poder usurfruir dessa ferramenta poderosíssima.

Para referência, a compatibilidade da proposta:

Chrome, released on 93,
Firefox, released on 91,
Safari, released on 15,
Node.js, released on v16.9.0.

Entendendo TypeGuards, keyof e Template Literals em Typescript Avançado

Lara Carvalho — Thu, 23 Feb 2023 14:00:00 +0000

Existem 3 features que você deve entender para parar de tratar o Typescript como uma barreira e começar a vê-lo como uma ferramenta. Porque ele é poderosíssimo, e vai muito além de tipar tudo como any pra fazer o console parar de te perturbar.

1. Type Guards

De acordo com a documentação oficial:

Um type guard é uma expressão que performa uma checagem que garante que o tipo está de acordo com o escopo definido.

“A type guard is some expression that performs a runtime check that guarantees the type in some scope.” — typescriptlang.org

O que exatamente isso significa? Com essa ferramenta, podemos afunilar as possíveis tipagens que queremos receber de nossos objetos. Criamos uma forma muito simples de assegurar uma segurança de tipos em nosso código, nada de receber algo que não estávamos esperando.

Então como podemos criar nossas próprias type guards?

Vamos ver um exemplo usando a ferramenta typeof, já nativa do Javascript:

class Human {
    breathe()
}

class Robot {
    calculate()
}

function createEntity(entity: Human | Robot) {
  if (typeof entity.breathe === 'function') {
    entity.breathe()
  }

  if (typeof entity.calculate === 'function') {
    entity.calculate()
  }
}

Ao escrever este código acima, imediatamente recebemos os erros:

Property 'breathe' does not exist on type 'Human | Robot'. Property 'breathe' does not exist on type 'Robot'.(2339)
Property 'calculate' does not exist on type 'Human | Robot'. Property 'calculate' does not exist on type 'Human'.(2339)

Então antes mesmo de rodar nosso código, recebemos um erro importante: Alguns dos métodos descritos não podem existir em cada tipo que a minha função recebe. Isso porque meu argumento recebe um tipo de união entre Human e Robot. Então a minha implementação não satisfaz a definição da minha função.

Vamos criar então nossos type guards para resolver esse problema:

function isHuman(entity: Human | Robot): entity is Human {
  return 'breathe' in entity
}

function isRobot(entity: Human | Robot): entity is Robot {
  return 'calculate' in entity
}

Com essas funções básicas, eu consigo checar se a propriedade especificada pertence ao objeto.

E como type guards tem seu próprio escopo, o que acontece dentro de cada bloco de função terá seu check executado sem interferir no que acontece fora dela. O tipo de entity permanece unknown.

E agora posso reescrever aquela função:

function createEntity(entity: Human | Robot) {
  if (isHuman(entity)) {
    entity.breathe()
  }

  if (isRobot(entity)) {
    entity.calculate()
  }
}

2. Keyof

Utilizando essa keyword nós podemos criar dinanismo à nossas funções de uma maneira muito interessante.

Vamos ver este exemplo:

interface MenuOptions {
  start: boolean
  pause: boolean
  stop: boolean
}

type ChosenOption = keyof MenuOptions

function choose<T extends ChosenOption>(key: T, value: MenuOptions[T]) {
  console.log(`Logger: ${key} is set to ${value}`);
}

Aqui temos uma interface que define algumas opções de menu e um tipo que define que opção nós escolhemos a partir da key (chave) da interface, no caso são start, pause, stop.

E abaixo temos uma função de logs chamada choose que recebe um tipo T genérico, que extende o ChosenOption e um valor que deve se adequar aos valores das keys de MenuOptions. Nesse caso, só temos booleans.

Então fazendo alguns testes, veremos que:

console.log(choose('start', true)) // Logger: start is set to true
console.log(choose('pause', false)) // Logger: pause is set to false
console.log(choose('stop', 100)) // Erro: Argument of type 'number' is not assignable to parameter of type 'boolean'

Agora temos uma função que satisfaz a nossa segurança de tipagem e que é extensível a partir da nossa interface.

3. Template Literal Types

Às vezes nós não precisamos de tipos ultra complexos nem criar um monte de definição específica, às vezes nós precisamos de algumas definições em string para mapear IDs, ações externas ao nosso código, tags que devem ser expostas em texto, etc.

Para isso, podemos usar os template literal types, que são baseados em string literals para expandir nossa forma de trabalhar com strings através de union types.

Vamos ver alguns exemplos:

type Strings = 'greetings' | 'welcome_text' | 'goodbyes'
type Languages = 'pt_br' | 'en_us' | 'en'

const LocaleGreetings = `${Languages}_${Greetings}`

Agora, de forma simples, temos vários novos tipos preparados a serem usados. Alguns exemplos: pt_br_greetings, en_goodbyes, etc.

Outro exemplo é quando queremos receber uma informação já bem descritiva. Imagine que preciso receber um evento que modifica dados no meu banco, mas em três diferentes instâncias: quando inserimos um dado, quando atualizamos um dado ou quando deletamos um dado.

Nosso código usando template literals:

type EventMethods = 'INSERT' | 'UPDATE' | 'DELETE'

interface Event {
    action: string
    method: EventMethods
}

Em vez de aceitar apenas strings genéricas e checar dentro do meu código se elas são válidas ou não, eu defino exatamente o que quero receber e deixo o runtime check fazer o trabalho por mim.

Conclusão

Espero que tenham curtido o que eu trouxe hoje. Caso queiram ver esse conteúdo em vídeo: Video no Youtube.