DEV Community: Fabrícia Diniz

O que aprendi ministrando meu primeiro workshop

Fabrícia Diniz — Wed, 15 Sep 2021 16:07:07 +0000

Em julho de 2021 eu fui convidada para dar um workshop de Django REST Framework na Python Nordeste. Eu já havia atuado como monitora em um Django Girls local, mas nunca havia ministrado o meu próprio workshop. Eu sabia o tamanho da responsabilidade, mas o que eu não esperava era que aceitar esse desafio mudaria uma chavinha na minha cabeça em termos de criar e desenvolver projetos.

Um workshop é um seminário ou curso intensivo de curta duração em que técnicas são demonstradas e aplicadas. Ou seja, eu precisava de um projeto relativamente simples, que pudesse ser concluído em 3 horas ou menos, mas que ao mesmo tempo "vendesse o peixe" do DRF, demonstrando o quão fácil de usar e customizável ele é.

1º aprendizado: uso da documentação

Todas as vezes que eu cheguei a ler avidamente documentações foi porque eu tinha um problema em um grande projeto e precisava de uma resposta rápida e pontual. Isso fazia com que eu não testasse os exemplos de código em um projeto de baixa complexidade, os aplicando direto no meu grande projeto, e isso normalmente acabava resultando em um comportamento inesperado ou uma mensagem de erro que eu não entendia a procedência.

Aplicar os diferentes conceitos em um projeto contendo o mínimo de código necessário para seu funcionamento reduz as chances de algum fator desconhecido quebrar o código. Além disso, torna mais fácil identificar causas de erros, já que existem menos fatores influenciando o resultado.

2º aprendizado: reduzir escopo dos projetos

No começo de 2020 eu fazia live coding de um site de receitas que eu estava criando como side project. Como eu tinha uma audiência, eu tentei delimitar quais funcionalidades seriam desenvolvidas em qual ordem, mas eu acabei adicionando mais complexidade do que eu conseguia lidar naquele momento. O resultado é que o projeto está abandonado até hoje.

Ser forçada a criar um projeto que pudesse ser completado em poucas horas mudou a forma que eu olho para o escopo dos meus projetos. É melhor criar um projeto com um escopo pequeno mas que você consiga desenvolver do começo ao fim do que tentar fazer um projeto extraordinário que vai ser abandonado na metade.
Um outro ponto a favor dos projetos de escopo pequeno é que você pode sempre adicionar mais funcionalidades, e ter terminado alguma coisa é um gatilho positivo para o seu cérebro.

3º aprendizado: ensinar é realmente uma ótima forma de aprender

Como eu iria ter que explicar todos os passos do projeto para outras pessoas e precisaria saber responder a dúvidas, me debrucei com afinco na documentação e busquei realmente entender o comportamento do código e o que estava acontecendo por baixo dos panos. Testei alguns cenários diferentes (dentro do meu escopo pequeno) para ver como a API se comportava em diferentes situações, com diferentes inputs. Fazendo isso eu consegui um entendimento bem mais profundo do funcionamento do meu sistema e do framework como um todo, que me deu um sentimento de estar mais apta a resolver problemas futuros.

Algumas pessoas (como eu) têm dificuldade em estudar por si mesmas, escolher um assunto e sentar a bunda na cadeira para aprender algo novo. Precisar estudar para passar conhecimento de qualidade para outras pessoas é um grande incentivo para finalmente conseguir focar nos estudos. E nesse ponto, não precisa ser apenas algo grandioso como um workshop num evento de grande porte, pode ser num evento de pequeno porte, um vídeo, uma live ou até mesmo um artigo no seu blog.

4º aprendizado: você consegue

Não sei vocês, mas o meu Github é um cemitério de projetos inacabados e isso meio que me fazia pensar que eu não conseguiria desenvolver um side project do início ao fim. Sendo forçada a reduzir o escopo e construir algo em um período definido de tempo fez com que alguma coisa saísse do papel e o meu cérebro entendesse que sim, eu consigo desenvolver coisas por mim mesma, num contexto fora do trabalho. Não que alguém precise desenvolver projetos paralelos, mas há uma diferença grande entre não querer e achar que não consegue.

Em julho eu não achava que estava pronta para ministrar algo dessa magnitude em um evento como a PyNE, mas eu sou uma mulher de palavra e fui mesmo assim. Depois de horas e horas estudando e montando o melhor conteúdo que eu poderia passar, eu sinto que a minha autoconfiança nas minhas capacidades profissionais aumentou um tantinho a mais. Recomendo a experiência!

Como melhorar seus testes técnicos

Fabrícia Diniz — Sun, 04 Jul 2021 23:06:37 +0000

Pelo menos 1 vez por mês eu corrijo testes técnicos de pessoas que querem entrar na empresa que eu trabalho e com frequência analiso os pontos fortes e fracos dos testes de pessoas que eu indico. Muitas vezes os critérios que desqualificam alguém não são necessariamente técnicos, e vendo as pessoas cometendo os mesmos erros repetidamente eu gostaria de dar a minha contribuição e trazer alguns pontos de atenção na hora de fazer um teste técnico para maximizar suas chances de conseguir um emprego.
Lembrando que existem empresas que vão sim dar muito mais peso ao aspecto técnico, então não posso prometer que seguindo esse artigo você vai conseguir passar com certeza.

README

A primeira coisa que me faz olhar um projeto com bons olhos é o README. Ele é o ponto de acesso das pessoas ao seu projeto e portanto deve ter um bom descritivo das tecnologias usadas e de como rodar o projeto localmente. Na hora de escrever o README você precisa ter em mente que a pessoa que vai avaliar o seu projeto provavelmente não tem as mesmas configurações de ambiente que você e não vai querer perder tempo descobrindo quais as configurações corretas, seu projeto não roda e pronto e você pode não passar para a próxima fase por conta disso.

Exemplo de instruções de instalação

Uma coisa que me ajudou quando eu submeti o meu último teste técnico foi enviá-lo antes para um amigo, que tentou rodar tudo seguindo o que estava no README. Ele não conseguiu rodar o projeto por falta de informações a respeito das versões dos frameworks e linguagens utilizados e apontou diversas outras inconsistências no meu projeto, que eu tive a chance de corrigir antes de submeter para a empresa (e conseguir a vaga).

Itens que não podem faltar

Descrições das tecnologias utilizadas e suas respectivas versões: um código que roda em uma versão de um framework pode não rodar em outra por isso é sempre importante especificar todas as versões utilizadas
- pontos bônus: adicionar um requirements.txt ou algo do tipo que permita que a pessoa instale todas as dependências de uma vez só
Link para o repositório do teste OU explicação básica de como o projeto funciona: facilita a vida da pessoa que vai corrigir, bem. Basta a pessoa pegar o seu repositório e ela já vai ter tudo que precisa para corrigir, aposto que pelo menos um tiquinho de simpatia da pessoa você já ganha.

Repositório

Deixe o repositório o mais limpo e organizado possível. Exclua arquivos que não estão sendo utilizados (tipo alguns arquivos automáticos gerados pelo framework que não sejam úteis), pelo amor da deusa não suba a pasta node_modules pro repositório se você fizer algo em JS.

Nesse repo aqui eu esqueci de adicionar a pasta .idea ao gitignore, acabei subindo o que não devia

Como baby-dev eu apanhei um bocado para entender qual a forma certa de organizar as pastas em um projeto, quais responsabilidades deveriam ficar isoladas onde, essas coisas. A dica que eu posso dar nesse caso é o que funciona para mim: desenhe a sua solução, no papel mesmo. Eu normalmente desenho de onde os dados vêm, qual o caminho que eles percorrem, que modificações são feitas e onde eles serão utilizados, de forma que fique mas fácil visualizar que trechos de código estão fazendo o que e quais critérios eu poderia usar para dividi-los em arquivos diferentes.

Um ponto difícil para quem está começando a pouco tempo na programação, aprendendo por tutoriais e vídeos no youtube, é que normalmente nesses conteúdos mais básicos as responsabilidades ficam todas num arquivo só ou não são separadas da forma que acontece em projetos maiores, o que pode levar ao seu projeto ficar com alto acoplamento e acabar perdendo pontos.

O desenho do fluxo dos dados ajuda a agrupar métodos do mesmo tipo em pastas descritivas. A lógica que estamos tentando desenvolver é a seguinte: se alguém precisar trabalhar no meu repositório e quiser alterar um método que faz X, a pessoa consegue saber onde fazer isso sem ter que procurar em várias pastas? Se ela precisar alterar algo na visualização dos dados é fácil de saber onde estão os arquivos que cuidam da visualização? Lembrando que cada linguagem de programação e cada framework tem a sua forma própria de organizar os arquivos, então é importante se atentar a isso também.

Arquivos

Escreva códigos legíveis e concisos. Mas Fabrícia como eu sei que o meu código está legível e conciso? Vamos dar uma entrada no Clean Code aqui. A resposta é: dê nomes significativos para as suas variáveis, se tiver uma variável x ou string em algum lugar você já não tem um código tão legível. Na hora de nomear as variáveis procure usar nomes que representem o que elas são, por exemplo taxa ou inputTelefone.

Falando em inputTelefone, escolha uma forma de nomear as suas variáveis e métodos e se atenha a ela por todo o código, de preferência aquela que for uma boa prática para a linguagem escolhida. Se for camelCase, mantenha camelCase, se for snake_case, mantenha snake_case, misturar duas ou mais formas diferentes passa a impressão de que você não está dando a devida atenção ao seu código.

const student_name = "Olivia";
const findRegisterByName = () => {...};

# Não faça isso, consistência é tudo

Mesmo que você não domine a fundo a tecnologia, existem alguns aspectos de organização que pessoas de qualquer nível podem aplicar e passar um ar mais profissional. Nem todas as empresas pensam o processo de contratação da mesma forma, mas existe a linha de pensamento de que é mais fácil ensinar hard skills para uma pessoa recém-contratada do que ensiná-la certas soft skills, então se você se mostra uma pessoa organizada, que escreve códigos legíveis e concisos, você pode estar à frente de pessoas que são melhores tecnicamente mas que não têm o mesmo cuidado com o material que estão apresentando.
Eu inclusive já recebi esse feedback, que existiam outras pessoas no processo seletivo que eram melhores do que eu tecnicamente mas o meu código era legível e muito bem organizado, então eu acabei sendo contratada.

Usar uma ferramenta de linter também pode contar pontos a seu favor, uma vez que muitas empresas as usam e é outro ponto que mostra o seu cuidado com a padronização do código.

Testes

Eu sei, nem todo mundo domina testes, especialmente iniciantes na área. Então eu vou dar uma dica: teste como você espera que o sistema se comporte frente a um usuário. Pense como alguém usando o seu programa, se a pessoa clicar em determinado botão o que ela deve ver? Se alguma informação errada for inserida, como o programa responde a isso? Que informações podem ser checadas na tela para indicar que a página carregou corretamente? No backend, teste se as informações estão sendo retornadas no formato esperado, incluindo mensagens de erro, de acordo com os cenários de sucesso e fracasso na requisição. Dessa forma você demonstra escrever um código de mais fácil manutenção e também mostra que tem conhecimento em algo tão importante quanto testes.

test("Não deve matricular aluno sem CPF válido", () => {
    const requisicaoMatricula = {
        aluno: {
            nome: "Ana Maria",
            cpf: "213.345.654-10"
        }
    };
    expect(() => matriculaAluno.execute(requisicaoMatricula)).toThrow(new Error("CPF inválido"));

Aqui testamos uma situação de erro, esperando (expect) que seja lançado (toThrow) o erro específico (CPF inválido)

Saber o que você quer testar ajuda na hora de procurar como escrever o código que vai fazer tudo isso. Tendo uma ideia do que precisa ser feito, o que resta é se debruçar em documentações e exemplos e tentar traduzir aquilo para a sua situação. Uma coisa que me ajuda muito é ver projetos reais e analisar como os testes foram implementados, isso facilita e muito o trabalho de escrever testes quando você não sabe muito bem por onde começar.

Eu passei em duas entrevistas sem escrever testes, mas eu com certeza perdi vários pontos por não tê-los feito. Se você vai optar por não escrever testes, se faça um grande favor e teste manualmente mesmo todos os casos extremos, com os inputs mais mirabolantes que você puder pensar. Dessa forma pelo menos você garante que a coisa está funcionando mesmo e evita perder ainda mais pontos.

Pontos de melhoria

Pessoalmente eu gosto de incluir no README do projeto uma seção de pontos de melhoria que eu faria no projeto. Gosto de fazer isso porque normalmente nós não temos tempo suficiente para fazer o teste técnico da melhor forma possível, por qualquer motivo que seja, e mostrar que você tem ciência dos pontos que podem ser melhorados passa a ideia de que você está ciente de como o seu projeto poderia ficar bem melhor. Eu vejo como uma forma de dizer "esse projeto não representa o meu melhor e eu tenho ciência desse, desse e desse aspectos que eu poderia melhorar se eu tivesse mais tempo para trabalhar na solução."

Um outro aspecto que pode ser interessante mencionar é o que foi priorizado em detrimento do quê. Recentemente eu entrevistei uma pessoa cujo projeto tinha sido avaliado como sendo de nível júnior por não ter testes e mais alguns outros detalhes. Na hora da entrevista a pessoa mencionou trabalhar a anos em um determinada empresa e falou sobre diversas experiências de trabalho. Certamente não era o que eu estava esperando. Perguntei sobre os testes e ela me disse que havia feito a escolha de não fazer testes para priorizar outro aspecto da aplicação e em seguida discorreu sobre a importância que ela via nos testes e seus estudos sobre Desenvolvimento Orientado a Testes. Ou seja, essa pessoa poderia não ter passado na etapa de avaliação por não ter implementado testes, mas ela sabia da importância deles e escolheu não implementá-los porque estava trabalhando em tempo integral na época e preferiu focar em finalizar mais requisitos do teste técnico.

Mas claro que se você acha que deu o seu melhor e que não tem nada que você melhoraria, você não precisa incluir esse tópico.

Facilite a vida da pessoa que vai corrigir

Essa dica eu aprendi vendo testes técnicos de outras pessoas. Em um teste específico a pessoa criou um container docker para que quem fosse corrigir não precisasse instalar as dependências na própria máquina. Em outro a pessoa subiu o projeto em um Heroku/Netlify da vida e possibilitou que nós testássemos o projeto sem precisar rodar ele localmente.

Eu reconheço que essas atitudes não são muito triviais e podem consumir um tempo que você não tem. Até porque não adianta nada subir o projeto no Heroku se vai estar tudo quebrando porque não sobrou tempo para consertar. Então o que eu recomendo é: pega um projetinho que você já tenha e tira um fim de semana para tentar fazer esses processos. Se você precisar, documente o passo a passo. Fazendo isso uma vez e sabendo o "caminho das pedras" na hora do teste técnico você só precisa seguir o seu passo a passo e a coisa sai mais rápido do que se você tivesse que aprender na hora.

Conclusão

Existem diversos aspectos não diretamente relacionados com linguagens de programação que podem ser observados para te dar alguma vantagem frente a outros concorrentes para uma vaga. Nesse artigo eu quis trazer alguns pontos de atenção e algumas dicas para deixar os seus testes técnicos ainda melhores e mais atraentes para as pessoas avaliadoras.

Espero ter conseguido ajudar e como sempre sinta-se a vontade para deixar mais dicas nos comentários.

Microagressões em empresas de tecnologia

Fabrícia Diniz — Thu, 17 Jun 2021 00:38:55 +0000

É cada vez mais comum ver empresas de tecnologia querendo contratar mais mulheres e se esforçando (às vezes não tanto) para criar ambientes inclusivos. A realidade é que essa não é uma construção fácil e várias atitudes danosas podem passar despercebidas. Hoje eu quero falar especificamente sobre microagressões.

Antigamente era mais fácil identificar agressões no ambiente de trabalho: eram gritos, um tapa na bunda, diminuição das capacidades das mulheres, etc. Hoje em dia as agressões estão cada vez mais sutis à medida que as mais graves vão sendo combatidas mas o sentimento que as motiva ainda permanece.

As microagressões podem se passar por erros honestos, pois é perfeitamente possível, por exemplo, que uma pessoa não leia uma mensagem e acabe passando por cima do trabalho de uma colega (especialmente nesses tempos remotos que vivemos). Porém, essa ação pode ser motivada por essa pessoa inconscientemente perceber a colega como tendo "menos valor". Se você questioná-la, ela provavelmente vai dizer que não viu a mensagem mesmo, não foi intencional. Para a pessoa que é passada por cima fica aquele sentimento de "será que isso aconteceu mesmo? Será que eu tô enxergando coisa onde não tem?"

O grande ponto de observação é se a pessoa tem as mesmas atitudes com colegas homens e mulheres. Apesar de importante critério de "desempate" isso pode não ser fácil de perceber, as diferenças de comunicação podem acontecer em ambientes privados, por exemplo. Além disso, para as pessoas que realizam as microagressões a sua própria culpa não é tão clara. O "me desculpe se você se sentiu ofendida" é um sinal de que a pessoa não percebe o problema em suas ações e padrão de pensamento e dificilmente tomará alguma ação para melhorar (ou ela nunca aprendeu a se desculpar).

Agora, o mais importante é: como se lida com uma pessoa que está cometendo uma microagressão se ela não percebe o seu próprio viés mental? Do meu ponto de vista, é preciso que a empresa tome uma ação e não a pessoa que foi vítima. A pessoa na maioria das vezes já não enxerga o seu viés, de forma que é muito fácil apenas descartar as reclamações recebidas. Cobrar que a pessoa que já está se sentindo mal resolva a situação apenas a submete a mais uma agressão.

Sinceramente, enquanto eu escrevo isso eu consigo visualizar as desculpas sendo dadas e o sentimento de "eu preciso pisar em cascas de ovos perto dessas mulheres mimimizentas". Eu tenho ciência de que essa é uma mudança que raramente pode ser imposta se a pessoa não enxergar valor nela. E passar o valor dessa mudança talvez seja o grande X da questão.

Normalmente, pessoas do lado mais privilegiado do espectro

não percebem seus privilégios;
nunca precisaram se preocupar com as suas ações estarem sendo danosas a outras pessoas.

Vamos de exemplo, inspirado no livro Rápido e Devagar do Daniel Kahneman: em uma reunião de tomada de decisão, inconscientemente as pessoas tendem a concordar com quem deu a sua opinião primeiro e quem fala mais "alto", com mais convicção. Essa pessoa normalmente não se preocupa que as pessoas estarem acatando o que ela fala o tempo todo representa um silenciamento da colega mulher que fala de forma mais tímida e nunca tem as ideias acatadas. Pessoas assim costumam refletir pouco sobre si mesmas e sobre seus atos, tendendo a depositar a culpa na ação de outras pessoas, não conseguindo ter empatia pela colega que não é ouvida.

Se esse último parágrafo te incomodou pela generalização, faça um exercício: veja se você consegue anotar pelo menos 3 privilégios que você usufrua no seu dia a dia. Você consegue identificar momentos em que você está sendo privilegiado em detrimento de alguma outra pessoa e você combate isso na vida real e não só na sua cabeça? Viver usufruindo de privilégios é bem mais fácil do que ter a consciência dos momentos em que eles existem. Apenas ter consciência é muito mais fácil do que realmente tomar alguma atitude para equalizar a situação.

Eu, Fabrícia, ainda enxergo uma barreira a mais. Atualmente as mulheres constituem cerca de 25% dos profissionais de TI no Brasil. Uma porcentagem menor ainda ocupa cargos de liderança. Ou seja, uma mulher tem uma chance enorme de ter um líder homem e esse líder precisa estar ciente de privilégios, vieses inconscientes e microagressões para evitar que o discurso de inclusão seja um discurso vazio só para a empresa sair bem na mídia.

Considerando o baixo percentual de pessoas de minorias em geral nesses cargos, eu vejo as lideranças tendo um grande trabalho de aprendizagem e reflexão sobre seus próprios privilégios e a maneira como as suas atitudes podem agravar uma microagressão sofrida, mesmo que de forma não intencional, por falta de empatia com aqueles historicamente menos privilegiados.

A conclusão que eu posso tirar é: se a empresa possui o valor de inclusão de diversidade, todas as pessoas que trabalham nela precisam ser bastiãs desse valor, reconhecendo inclusive ações sutis que o contrariam. Uma boa saída seria promover periodicamente cursos obrigatórios de inclusão que saíssem do básico e entrassem nesses temas mais "espinhosos" e sutis. Para as lideranças, reforço extra no trabalho de empatia. Se a pessoa não enxerga nenhuma vantagem nesse tipo de ação de combate, já começou errado, volte 5 casas.

Eu espero que esse texto possa trazer alguma reflexão sobre a temática e como sempre estou aberta à continuar a discussão nos comentários. A internet também está cheia de outros recursos para ajudar nessa jornada.

How to start a task being a junior developer

Fabrícia Diniz — Tue, 08 Jun 2021 14:14:04 +0000

TL-DR:

In this article I talk about strategies I use to efficiently navigate my tasks at work as a junior developer (who has ADHD).
These are the topics covered (I went a little further than just starting):

Before starting a task
While developing
At task completion

Basically, there are 3 types of strategies I use when doing a task: ** those applied to reduce the difficulty of starting, those applied during development to smooth the process, and those applied at the end of the task to reduce the errors that will pass into code review*. To help understanding, I'm going to use a task I did a few months ago, a modal in React.
*I have to warn you that these tips will improve your performance in the medium term, but in the short term it may seem like you're taking things slower than you'd like. I suggest talking to your leadership to align the expectations.

Before starting a task

Before starting any task I like to understand the code I'm going to work with, so I look for the components involved in the task and read them, taking notes in a notebook about what each one does, where the data comes from and what its internal functions do. That way I can have a deeper understanding of what I'm going to be dealing with and I prevent that information from staying only in my head (which is not at all reliable), as well create a place to turn to if ever I need to work again on the same components.

You could argue that doing it this way "consumes" a lot of task time, but I guarantee it makes development easier and reduces time spent looking for bugs later. From a junior's perspective, you gain code mastery much faster and deeper this way. People don't usually do this and I've found that reading and understanding the code beforehand helps me identify points of attention that go unnoticed even by the more experienced.

However, sometimes the task is to start something from scratch. In these cases I look for similar components and do the same procedure to understand what all its code does because this prevents me from just copying code snippets without understanding what they actually do. My task of creating a modal fell in this case, I had to create the component from scratch based on a more general one that already existed in the project.

The last thing I do is taking note of the subtasks within the main task. Here I try to make them as simple and short as possible, because this reduces the time between one subtask and another and greatly improves the development flow. Regarding my modal, it was something like this:

create modal component
condition API call to click
mock API return
test the action of clicking the button
find out how to pass information between different components

While developing

Having very small and relatively simple subtasks helps reduce the anxiety and procrastination to get started and gives you a better view of progress. Sometimes it is necessary to define microsteps to help break the inertia of starting the task and one that helps me a lot when I need to research a difficult topic is to leave the website or documentation open and then get up from the chair for a while. For some reason I feel less overwhelmed when I've just taken a walk and the website I need is already open just waiting for me. This also works with the code itself, I find the right file to work with and then I'll take a walk around to unwind before starting.

During the task, unforeseen bugs/fixes always arise, so I write down all the things I didn't anticipate I would have to do and also all the questions that come up to search the internet or ask someone on the team, that way nothing gets lost and I guarantee that I will remember to clarify everything.
Another strategy I have to adopt when it's particularly difficult to focus on the task is to write down the problem I'm trying to solve and write down the little conclusions that will lead me to the solution. An example of how I do this part:

at what moment should the click open the modal?
- ↪ when an element is registered, determined by element.isEnabled
- what defines isEnabled? At what point is it changed?
the modal must have: isOpen, onClose, type, name, date, activities
- date comes from the URL ✅
- where does the other information come from? Does the parent component have them all? Do I need to get any of them from somewhere else?

In some situations it's necessary to do a pair programming and I realized that without my notes I could end up getting pretty lost, so I like to take these steps before having someone help me with answers.

At task completion

This is the time to check if any silly mistakes have gone unnoticed. Before submitting an assignment for code review I usually recheck a few things:

run all the automated/integration tests to make sure I didn't accidentally break anything
run lint (if not running automatically)
update my branch with main/master
- if necessary, update libraries and database
- if necessary, resolve merge conflicts
run the code and make sure the behavior is as expected, including error cases
check if I've followed the code standards defined by the company

And here's a tip my tech lead gave me: if you think the code is bad after finishing the whole task, call someone on your team to take a look, you can explain what you tried to do and the person can give you feedback on how to improve before submitting to the code review itself.

Starting a career in development can be quite difficult, especially if you've gone through a career transition or don't have a good theoretical background. With this article I would like to share some strategies I use to make tasks less daunting and less anxiety-provoking.
Do you have any more tips to give not only to me but to other people just starting out? Leave it in the comments and help some more people.

Como iniciar uma tarefa sendo dev júnior

Fabrícia Diniz — Sat, 05 Jun 2021 19:07:23 +0000

TL-DR:

Nesse artigo eu falo sobre estratégias que eu uso para navegar de maneira eficiente pelas minhas tarefas no trabalho sendo uma desenvolvedora júnior (que tem TDAH).
Etapas abordadas:

Antes de iniciar uma tarefa
Durante o desenvolvimento
Na finalização da tarefa

Basicamente, existem 3 tipos de estratégias que eu uso na hora de fazer uma tarefa: as aplicadas para reduzir a dificuldade de começar, as aplicadas durante o desenvolvimento para facilitar a cadência e as aplicadas ao finalizar a tarefa visando reduzir os erros que passarão para code review. Para ajudar no entendimento, vou usar uma tarefa que eu fiz a alguns meses, uma modal em React.
Tenho que deixar avisado que essas coisas vão melhorar a sua performance no médio prazo, mas a curto prazo pode parecer que você está fazendo as coisas mais devagar do que gostaria. Eu sugiro conversar com a sua liderança para alinhar esse tipo de expectativa.

Antes de iniciar uma tarefa

Antes de iniciar qualquer tarefa eu gosto de entender o código que eu vou trabalhar, então eu procuro os componentes envolvidos na tarefa e os leio, anotando num caderno o que cada um faz, de onde os dados vêm e o que as suas funções internas fazem. Dessa forma eu consigo ter um entendimento mais profundo do que eu estarei mexendo e evito que essa informação fique só na minha cabeça (que não é nem um pouco confiável), além de ter um local para recorrer caso seja preciso voltar a trabalhar nos mesmos componentes.

Você pode até argumentar que fazendo dessa forma se "gasta" muito tempo da tarefa, mas eu garanto que isso facilita o desenvolvimento e reduz o tempo passado procurando bugs depois. Da perspectiva de uma pessoa júnior, você ganha domínio do código bem mais rápido e de maneira mais profunda dessa forma. Normalmente as pessoas não fazem isso e eu já percebi que ler e entender o código antes me ajuda a identificar pontos de atenção que passam despercebidos até para pessoas mais experientes.

Porém, às vezes a tarefa consiste em começar algo do zero. Nesses casos eu busco componentes semelhantes para me basear e faço o mesmo procedimento de entender o que todo o código faz pois isso evita que eu só copie trechos de código sem entender o que eles realmente fazem. Minha tarefa de criar a modal caiu nesse caso, eu tive que criar o componente do zero me baseando em um mais geral que já existia no projeto.

A última coisa que eu faço é anotar as sub-tarefas dentro da tarefa principal. Aqui eu tento torná-las o mais simples e reduzidas possível, porque isso reduz o tempo entre uma sub-tarefa e outra e melhora demais a cadência no desenvolvimento. No caso da minha modal, ficou algo parecido com isso:

criar componente da modal
condicionar chamada da API ao clique
mockar retorno da API
testar caso de clique no botão
descobrir como passar informações entre diferentes componentes

Durante o desenvolvimento

Ter sub-tarefas bem pequenas e relativamente simples ajuda a reduzir aquele frio na barriga e a procrastinação para começar e te dá uma melhor visão de progresso. Às vezes é preciso definir micropassos para ajudar a quebrar a inércia de começar a tarefa e um que me ajuda bastante quando eu preciso pesquisar algum tema difícil é deixar o site ou a documentação aberta e aí levantar um pouco da cadeira. Por algum motivo eu me sinto menos sobrecarregada quando eu acabei de dar uma volta e o site que eu preciso já tá aberto só me esperando. Isso também funciona com o código em si, acho o arquivo certo pra trabalhar e depois vou dar uma volta para espairecer antes de começar.

Durante a tarefa sempre surgem imprevistos, então eu anoto todas as coisas que eu não previ que teria que fazer e também todas as dúvidas que surgirem para pesquisar na internet ou perguntar a alguém do time, dessa forma nada se perde e eu garanto que vou lembrar de tirar todas as dúvidas.
Outra estratégia que eu preciso adotar quando está particularmente difícil de concentrar na tarefa é colocar no papel o problema que eu estou tentando resolver e ir anotando pequenas conclusões que vão me levar à solução. Um exemplo de como eu faço essa parte:

em que momento o clique deve abrir a modal?
- ↪ quando tem elemento registrado, determinado pelo elemento.isEnabled
- ↪ o que define o isEnabled? Em qual momento ele é alterado?
a modal deve ter: isOpen, onClose, type, name, date, activities
- date vem da URL ✅
- de onde vêm as outras informações? O componente pai tem todas? Preciso pegar alguma de algum outro lugar?

Em algumas situações que é necessário fazer pair programming e eu percebi que sem as minhas anotações eu posso acabar ficando bem perdida, então gosto de fazer essas reflexões antes de ter alguém que vai me ajudar com as respostas.

Na finalização da tarefa

Esse é o momento de checar se algum errinho besta passou despercebido. Antes de submeter uma tarefa para code review eu costumo fazer algumas re-checagens:

rodar todos os testes da aplicação para ter certeza de que eu não quebrei nada acidentalmente
rodar o lint (caso não esteja rodando automaticamente)
atualizar a minha branch com a main/master
- caso necessário, atualizar bibliotecas e banco de dados
- caso necessário, resolver conflitos de merge
executar o código e me certificar de que o comportamento está como esperado, inclusive os casos de erro
checar se eu segui os padrões de código definidos pela empresa

E aqui uma dica que o meu líder técnico me deu: se você acha que o código está ruim depois de finalizar toda a tarefa, chama alguém do seu time para dar um olhada, você pode explicar o que tentou fazer e a pessoa pode te dar feedbacks de como melhorar antes de submeter ao code review propriamente dito.

Começar a carreira de desenvolvimento pode ser bem difícil, especialmente se você passou por uma transição de carreira ou não possui um background teórico tão bom. Com esse artigo eu gostaria de compartilhar algumas estratégias que eu uso para tornar as tarefas menos assustadoras e menos causadoras ansiedade.
Você tem alguma dica a mais para dar não só pra mim mas pra outras pessoas que estão começando? Joga ela nos comentários para ajudar mais pessoas.

The flow of a request in Django

Fabrícia Diniz — Tue, 01 Jun 2021 16:59:52 +0000

A while ago I was a beginner developer, and for those like me who don't have a computer science/engineering background it can be very difficult to understand what's going on behind the curtains when we develop a web application. For those who are just starting out in the world of programming with Python and Django and who are perhaps feeling overwhelmed and lost with what happens in web applications, I'm going to explain how I managed to understand the flow of the thing.

The request

Considering a complete application, the flow starts when you type an url in the browser. From there Django goes into your settings.py file and looks for the ROOT_URLCONF variable to find out in which file the url patterns "known" to your application are in. Knowing which file to look for urls in, Django then searches for the urlpatterns variable in that file, which contains all the base urls your application recognizes. I say base urls because this file usually link to other url files that contain the most detailed routes.

urls.py

Knowing which file is the right one, Django goes through all the url patterns in order and looks for one that matches the url typed in the browser. Once there is a match it will import and call the associated view. In other languages, the "view" is called a controller because it controls how the information in the application is treated and sent to the browser / user. This can get a little confusing when studying the MVC (Model-View-Controller) pattern, where view means the part the user interacts with.

If none of the urls in the list match, Django returns an exception indicating that it couldn't find any urls that matched the url entered by the user. Often an error occur simply because you forgot to add a specific url to your url file. This can happen even with the most experienced developers.

View

Well, back to our flow in Django, when the view is called an HttpRequest object is passed to it with information regarding the request that was made. This object contains the url called and can contain various other information such as: arguments passed through the request body, user session data... Information that will be used by the view to decide what information will be returned to the user. This is where the bulk of the programming will happen, where you will be able to access the database to fetch information, manipulate incoming data, and do all the magic of your program.

Template

After all the magic and all the manipulation happens, it's time to return the information to the user. A view can contain several methods that handle different requests for that url (if it's a GET or a POST, for example) and in the end the methods must return both the data and which html file (template) should be rendered when displaying the information for the user. This can happen in several ways, Django can even handle your requests on its own, without you having to code all the behavior. You'll have to do some research to see which way works best for you, and I might even post about that in the future.

Success!!

Once the view returns the information and which html file should be rendered, Django will show that page to the user and then (if everything is done correctly) it's a win!!

I hope you were able to understand the flow of a request in Django, but feel free to comment with your questions if you didn't understand, every question is valid.

Como criar ambientes inclusivos para pessoas neurodiversas

Fabrícia Diniz — Fri, 28 May 2021 19:45:53 +0000

A sua empresa provavelmente já possui pessoas neurodiversas, o que falta é um ambiente inclusivo para que essas pessoas possam trabalhar da forma que mais as beneficia.

O que são pessoas neurodiversas?

A denominação foi criada inicialmente para se referir a pessoas que estavam dentro do espectro autista, mas depois foi expandida para englobar outras condições associadas ao neurodesenvolvimento como TDAH, dislexia, discalculia, síndrome de Tourette e condições de saúde mental como transtorno obsessivo-compulsivo e borderline, entre outros.

Qual a importância de ter pessoas assim na equipe?

A diferença de visões de mundo e formas de pensar sempre vai ser positiva para as empresas (embora muitas não percebam isso ainda). Nós somos condicionados a pensar que essas pessoas seriam piores em suas funções, ou seriam profissionais ruins, mas essa é uma visão enviesada e eu espero que ao fim desse artigo você se sinta de forma diferente. Pessoas com TDAH podem ser extremamente criativas e empregar uma visão mais abrangente aos projetos que participam. Pessoas dentro do espectro autista podem demonstrar uma grande atenção a detalhes e ética de trabalho. Todas as pessoas têm contribuições importantes a darem, desde que as barreiras que as impedem de "sentar à mesa" sejam reduzidas ou eliminadas.

De que forma a sua empresa pode reduzir essas barreiras?

Bom, o principal é entender quais são as necessidades da pessoa, porque mesmo pessoas que tenham a mesma condição podem ter necessidades bem distintas. Algumas pessoas (como eu) não funcionam muito bem com horários de trabalhos rígidos, e precisam de rotinas mais flexíveis. Algumas precisam que a comunicação seja feita de forma clara, sem ambiguidades. Algumas precisam que os colegas entendam que não é porque ela está mexendo em alguma coisa ou desenhando que ela não está prestando atenção ao que está sendo dito. Existem casos mais graves, com mais necessidades, mas no geral o time todo cresce em integração e respeito uns pelos outros ao fazer ajustes visando inclusão.
Outras iniciativas poderiam incluir disponibilização de fones anti ruído, bolinhas antiestresse, 1:1 mais frequentes com uma liderança caso a empresa não os faça e/ou algum sistema de "não perturbe".

Alguns erros para não cometer:

Não incluir as pessoas em decisões que dizem respeito a elas. Se uma pessoa neurodiversa entra no seu time e decisões de adaptações são tomadas por ela sem uma conversa sobre a opinião dela, já começou errado.
Encará-las como pessoas frágeis. Esse é autoexplicativo.
Desconsiderar suas diferenças individuais. As pessoas neudivergentes não são as suas condições, elas possuem gostos, desejos e interesses que indiferem da condição que carregam.

Por fim, alguns passos práticos para serem adotados logo ao fim desse artigo

Pergunte às pessoas como elas trabalham melhor, ou se a maneira como o trabalho está estruturado está confortável para elas. A partir disso você pode tanto entendê-las melhor quanto saber que adaptações precisam ser feitas.
Se comunique de maneira clara, ambiguidade pode perpetuar uma série de desentendimentos.
Treinar os seus músculos da inclusão. Como? Isso é algo que eu gostaria que todas as pessoas contribuíssem nos comentários de acordo com as suas vivências. Eu não tenho respostas prontas e além disso gostaria muito de aprender com outras realidades.

No fim das contas, a mensagem principal é de que respeito é fundamental, e não só com pessoas neurodiversas. Tratar todo mundo com respeito é algo que pode trazer muito mais conforto e confiança para as pessoas com as quais você convive e pode fazer uma diferença gigantesca na vida de alguém.

A importância da matemática para a programação

Fabrícia Diniz — Fri, 21 May 2021 16:18:05 +0000

Esse artigo surgiu a partir de uma palestra que eu dei para pessoas de ensino médio. O intuito era mostrar que a matemática existe no mundo real da profissão.

Quando eu decidi abandonar a carreira de biotecnologista e virar programadora, instintivamente eu voltei a estudar cálculo, geometria... Não que eu esperasse encontrar esses assuntos no dia a dia do trabalho, mas porque eu achava os desafios interessantes e via similaridade entre eles e os desafios impostos pela programação.

A matemática se apoia na lógica, que é uma qualidade essencial para um bom profissional de TI, a geometria é uma aliada no processo criativo, ajudando na abstração do mundo real e estatística nem se fala (alô ciência de dados). É possível trabalhar com TI sem saber nada além do básico de matemática, mas saber conceitos de matemática mais avançados te ajuda a ser uma pessoa profissional de destaque.

A pessoa que possui conhecimento em matemática é capaz de resolver problemas profundos, oferecendo soluções mais claras, organizadas e eficientes. Empresas como Amazon, Facebook e Google olham muito mais para a lógica no código que você escreve do que conhecimentos de tecnologias específicas. Elas te pedem para resolver desafios de lógica, resolver problemas apontando também a complexidade e a rapidez do código que você fez além da lógica que te levou à resposta apresentada.

Quando estamos aprendendo matemática, nós aprendemos as operações básicas e depois evoluímos para as letrinhas, para achar x, achar y, e isso são funções, que é a base da computação todinha. Como na escola evoluímos de operações básicas só com números para funções que têm umas letras no meio, quando entramos no campo da programação os números e letras evoluem para qualquer coisa. O que nós nos apoiamos para lidar com esses desafios mais complexos é na lógica que vem bem do início. Partimos de números para letras e depois para coisas como carros, naves espaciais… umas coisas mais legais e diferenciadas.

Falando em naves espaciais, vocês sabiam que o programa que possibilitou o pouso do homem na lua pela primeira vez foi escrito por uma mulher? Foi a Margaret Hamilton que fez esse feito. Imaginem o TANTO de matemática que não é necessário para fazer uma nave espacial voar? Ou então, pra fazer um joguinho como Minecraft?

Nesse jogos mais legais de hoje em dia as pessoas precisam simular no computador a física do mundo, uma bala ou uma flecha sendo lançadas, o seu personagem caindo muito rápido de um lugar alto e se estabacando no chão e você morrendo. Tudo isso envolve bastante matemática (e física). Meu marido começou a aprender design de jogos ano passado e eu o estava ajudando com a parte de programação puramente dita. A gente tinha que definir a velocidade do personagem quando ele andava, a velocidade quando ele corria, a aceleração para ele mudar de andando pra correndo pra parado. Tinha que definir a gravidade, a força do pulo do personagem pra definir quão alto ele ia pular e quão rápido ele ia cair no chão. Foi bem divertido, e mostrou pra nós que tem muita matemática e física envolvida em fazer joguinhos legais.

Hoje em dia ainda existem outras profissões dentro da TI que são bem legais e demandam bastante matemática, como ciência de dados que é estatística pura (e uma das profissões de TI com os maiores salários), como inteligência artificial, robótica e o próprio desenvolvimento de jogos. Isso sem contar todas as profissões que envolvem hardware. A matemática permeia toda a base dos trabalhos em TI e definitivamente não é algo que fica na escola e deixa de impactar o nosso dia a dia no trabalho.

Lembrete para quem chegou até aqui: matemática não é um pré-requisito, é apenas um bônus. Ainda é possível ser um excelente profissional em diversas áreas sem saber bulhufas de matemática.

How to use VanHack to get a job abroad

Fabrícia Diniz — Thu, 03 Dec 2020 15:56:36 +0000

This text was initially published on my LinkedIn, but I would like to share it here too (and now in English).

Like many people in the technology field, I also dream of working for a foreign company and eventually moving to another country. This was a dream that has always been present in my mind and over the years I have searched for new ways and resources to achieve it. One of the tools that captivated me the most was VanHack, both for the attention they have with the candidates and for the diversity of resources they offer on the platform.

Here are some of the reasons why I think VanHack is a great resource for those who want an international career:

All job openings available on the platform are from companies that are willing to help with obtaining a visa and the applicant's relocation costs;
Having a profile on the platform and applying for any opening is ✨ free ✨;
VanHack itself offers enormous support with the bureaucratic part of the relocation;
In addition to making job openings available, the platform holds several hiring events throughout the year. In September there was a specific for women and last month, November 2020, there was a specific for Devops;
There is a lot of content on the platform to help candidates improve their profile and prepare for interviews. A portion is only available to premium users, but for some periods all of their content is open to all users;
There is a slack workspace where you can receive notifications of new openings and interact with people from Vanhack and candidates from around the world, in addition to a workspace exclusive for women to interact and improve within the platform.
VanHack Premium Academy offers classes covering everything you need to stand out in interviews, such as English and mock interviews, as well as a profile review tool, to determine points that can be improved and increase your chances of being hired.

Pretty cool right?

How to have a more appealing profile for companies

When creating a profile, you have the possibility to take an English test and a code test. The English test is mandatory for your profile to be considered for any job openings and you can retake it as many times as you want. Code test is not mandatory, but having a good grade can be a plus.

About the code test, do you want to know one more cool thing? There are several programming languages that can be chosen and your grade is not displayed in your profile unless it is greater than 7! So you can retake it as many times as you want without being afraid of the company seeing that you got a 5 on the Javascript test and possibly not hiring you for it.

In addition to the English and code tests, it is important to complete your profile, adding all the necessary information, a link to your resume and a good profile photo.

And you, a junior, do you have any chance?

While most openings are for senior developers, there are sporadic ones for developers with less experience. If you are a junior and already know that you want to have a career outside of where you live right now, there is a lot of value in being present on a platform where you can continuously learn and develop skills in the direction you want to go.

I'm pretty much a junior developer, with less than a year of formal experience in the job market, but I'm there with my active and updated profile, participating in all the events that I can and constantly learning new things that bring me closer to achieving a job offer.

And finally

That was all I had to say about the platform in this article. I really like VanHack a lot and I would like to spread the word so that more people (especially women) can take a few more steps towards the future that they always dreamed of.

If you are interested and want to chat a bit about it, you can contact me and I will love to talk to you. If you are interested and will create a profile, just click on the link at the beginning of the text or here.

This text is a partnership with VanHack, I was noticed (that's Brazilian slang, sorry for that) hahaha. Creating your profile from the links in this publication you help me strengthen this partnership and will support your favorite content producer <3

Como utilizar a VanHack para iniciar sua carreira no exterior

Fabrícia Diniz — Fri, 20 Nov 2020 19:05:14 +0000

Esse texto foi inicialmente publicado no meu LinkedIn, mas eu gostaria de compartilhar ele aqui também.

Assim como muitas pessoas da área de tecnologia eu também sonho em trabalhar para uma empresa gringa e eventualmente mudar de país. Esse foi um sonho que sempre esteve presente na minha mente e ao longo dos anos eu busquei novas formas e recursos de atingi-lo. Uma das ferramentas que mais me cativou foi a VanHack, tanto pela atenção que eles têm com os candidatos quanto pela diversidade de recursos que oferecem na plataforma.

Aqui estão alguns dos motivos pelos quais eu acho a VanHack um ótimo recurso para quem deseja uma carreira internacional:

Todas as vagas disponíveis na plataforma são de empresas que estão dispostas a ajudar com obtenção do visto e com os custos de realocação do candidato;
Ter um perfil na plataforma e aplicar para qualquer vaga é ✨ de graça ✨;
A própria VanHack oferece um suporte enorme na parte burocrática da realocação;
Além de disponibilizar as vagas, a plataforma realiza diversos eventos de contratação ao longo do ano. Em setembro houve um específico para mulheres e esse mês, novembro de 2020, está acontecendo um específico para Devops;
Existe bastante conteúdo na plataforma para auxiliar os candidatos a melhorarem o seu perfil e se prepararem para as entrevistas. Uma parte está disponível apenas para usuários premium, mas durante alguns períodos todo o conteúdo fica aberto;
Há um workspace do slack onde você pode receber notificações de vagas novas e interagir com pessoas da Vanhack e candidatos do mundo todo, além de um workspace exclusivo para mulheres interagirem e se aprimorarem dentro da plataforma.
O VanHack Premium Academy oferece aulas de tudo que você precisa para se destacar nas entrevistas, como inglês e mock interviews, e também uma ferramenta de revisão do seu perfil, para determinar pontos que podem ser melhorados e aumentar as suas chances de ser contratade.

Bem legal né?

Como ter um perfil mais atrativo para as empresas

Ao criar um perfil, você tem a possibilidade de fazer um teste de inglês e um teste de código. O teste de inglês é obrigatório para que o seu perfil seja considerado para vagas e você pode refazer ele quantas vezes quiser. Já o teste de código não é obrigatório, mas ter uma boa nota pode ser um diferencial.

Sobre o teste de código, quer saber mais uma coisa legal? Existem diversas linguagens de programação que podem ser escolhidas e a sua nota não é exibida no perfil a menos que ela tenha sido maior do que 7! Então você pode refazer quantas vezes quiser sem medo da empresa ver que você tirou um 5 no teste de Javascript e possivelmente não te contratar por isso.

Além dos testes de inglês e de código, é importante preencher o perfil completo, adicionando todas as informações necessárias, um link para o seu currículo e uma boa foto de perfil.

E você, que é júnior, tem alguma chance?

Embora a maioria das vagas seja para desenvolvedores sênior, existem vagas esporádicas para desenvolvedores com menos experiência. Se você é júnior e já sabe que quer ter uma carreira fora do Brasil, existe muito valor em estar presente numa plataforma onde você pode continuamente aprender e desenvolver skills na direção que você quer seguir.

Eu sou beeem júnior, tenho menos de um ano de experiência formal no mercado de trabalho, mas eu estou lá com o meu perfil ativo e atualizado, participando de todos os eventos que eu consigo e constantemente aprendendo coisas novas que me deixam mais próximo de conseguir uma vaga.

Falando em eventos...

No final do mês acontecerá o VanHackCON, um evento visando trazer informações para você estar ainda mais preparade para tirar os sonhos do papel. O evento possui 3 pilares - Mercado, Preparação e Inspiração - e vai trazer CEOs, CTOs, profissionais de RH e VanHackers que conseguiram o seu emprego fora do país para compartilhar ferramentas que vão te ajudar a conquistar o seu trabalho dos sonhos.

E por fim

Isso era o que eu tinha para falar sobre a plataforma nesse artigo. Eu realmente curto bastante a VanHack e gostaria de espalhar a palavra para que mais pessoas (especialmente mulheres ok) possam dar mais uns passinhos na direção do futuro que elas sempre sonharam.

Se você se interessou e quer trocar uma ideia sobre, pode entrar em contato comigo que eu vou adorar conversar. Se você se interessou e vai criar um perfil, é só clicar no link que tá no começo do texto ou aqui.

Esse texto é uma parceria com a VanHack, eu fui notada hahaha. Criando seu perfil a partir dos links presentes nessa publicação você me ajuda a fortalecer essa parceria e apoia a sua produtora de conteúdo favorita <3

Como utilizar duas contas do Github no mesmo computador (Windows)

Fabrícia Diniz — Sun, 16 Aug 2020 18:30:55 +0000

Estudando os básicos do Git/Github eu me deparei com a dificuldade de dar push para um repositório utilizando uma conta diferente da qual eu uso todos os dias para o trabalho.
Você pode estar pensando "Mas Fabrícia, é só substituir as credenciais globalmente". Pensei isso também, mas não funcionou, eu continuei travada por estar com as credenciais incorretas. Não sei bem porque isso aconteceu, mas eu descobri uma forma simples de contornar isso que normalmente não é conhecida/usada por pessoas mais iniciantes no uso do Git.

A solução para o problema é adicionar chaves SSH à sua conta do Github e nas próximas linhas eu vou explicar o passo a passo para fazer isso. Para esse tutorial você já deve ter o repositório na sua máquina local com o remoto apontando para o repositório do Github.

1 - Entrar no diretório do projeto

Bem autoexplicativo, navegue até a pasta do projeto que você quer fazer push com uma conta diferente.

2 - Criar uma nova chave SSH

Abra o terminal e digite o seguinte:

ssh-keygen -t rsa -C “seu email”

O -t indica o tipo da chave que será gerada (rsa) e -C indica um comentário.

2.1 - Salvar a sua chave SHH

Após rodar o código acima, você deverá colocar o caminho completo de onde os arquivos das suas chaves (pública e privada) serão salvas.

Generating public/private rsa key pair.

Enter file in which to save the key (/c/Users/your_username/.ssh/id_rsa):

Lembre-se de colocar um nome específico para essas chaves para não sobrescrever nenhuma outra chave.

/c/Usuarios/seu_usuario/.ssh/id_rsa_NOME_UNICO

2.2 - Colocar uma senha (ou não) para sua chave

Após definir onde suas chaves serão salvas, será pedido que você digite uma senha.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Você não é obrigado a colocar uma senha, mas é recomendado colocar uma por ser uma camada a mais de segurança.

3 - Adicionar a sua chave SSH ao seu perfil no Github

Navegue até a localização da sua chave e copie o conteúdo de id_rsa_NOME_UNICO.pub, essa é a sua chave pública.
De posse da sua chave SSH, logue no seu perfil do Github e acesse
Settings → SSH and GPG keys e adicione a nova chave. É interessante nomear suas chaves de acordo com as máquinas onde elas são usadas, para evitar confusão caso você tenha mais de uma chave salva no seu perfil.

4 - Adicionar a chave às configurações do repositório local

Navegue até a pasta do repositório e digite no terminal:

git config -e

Esse comando abrirá o seu arquivo git config, que deve ser parecido com esse:

Você precisa adicionar o sshCommand = ssh -i ~/.ssh/id_rsa_NOME_UNICO dentro de [core] indicando onde está a sua chave privada.
OBS: Caso a url em [remote "origin"] seja o link https do seu repositório, mude para o link SSH, que pode ser obtido aqui:

OBS2: Caso o email e o nome não correspondam à conta que será utilizada, modifique isso também diretamente no arquivo ou por meio dos comandos:

git config user.name "Seu Nome"

git config user.email seu_email@mail.com

5 - Dancinha da vitória

Seguindo esses passos você agora deve conseguir fazer o push para o seu repositório remoto utilizando uma segunda conta do Github.

(eu sei que você se sente assim quando algo finalmente dá certo)

Fluxo de uma requisição no Django

Fabrícia Diniz — Sat, 30 May 2020 23:56:25 +0000

A pouco tempo atrás eu era uma desenvolvedora iniciante, e para quem como eu não tem um background de computação pode ser muito difícil entender o que está acontecendo por baixo dos panos quando fazemos uma aplicação. Para quem está iniciando no mundo da programação com Python e Django e está se sentindo sobrecarregado e perdido com o que acontece nas aplicações, eu vou explicar aqui a forma que eu consegui entender o fluxo da coisa.

A requisição

Partindo de uma aplicação pronta, o fluxo se inicia quando você digita uma url no navegador. A partir daí o Django vai no seu arquivo settings.py e procura a variável ROOT_URLCONF para saber em qual arquivo estão os padrões de urls "conhecidos" pela sua aplicação. Sabendo em qual arquivo buscar pelas urls, o Django então procura nesse arquivo a variável urlpatterns, que contém todas as urls base que a sua aplicação conhece. Eu digo urls base porque esse arquivo normalmente direciona para outros arquivos de urls que contêm as rotas mais detalhadas.

urls.py

Sabendo qual é o arquivo certo, o Django passa por todos os padrões de url em ordem e procura uma que corresponda à url digitada no navegador. Uma vez que role um match ele irá importar e chamar a view associada. Em outras linguagens a "view" é chamada de controller porque é ela que controla como as informações da aplicação serão tratadas e enviadas para o navegador/usuário. Isso pode se tornar um pouco confuso quando se está estudando o padrão MVC (Model-View-Controller), no qual view significa a parte com a qual o usuário interage.

Caso não haja um match com nenhuma das urls na lista, o Django retorna uma exceção indicando que ele não conseguiu encontrar nenhuma url que correspondesse à url digitada pelo usuário. Muitas vezes um erro no programa surge pelo simples fato de você esquecer de adicionar uma url específica ao seu arquivo de urls. Isso pode ocorrer até com os mais experientes dos desenvolvedores.

View

Bom, voltando ao nosso fluxo no Django, quando a view é chamada um objeto HttpRequest é passado com as informações referentes à requisição que foi feita. Esse objeto contém a url chamada e pode conter diversas outras informações como: argumentos passados por meio do corpo da requisição, dados da sessão do usuário, arquivos... Informações que serão usadas pela view para decidir que informações serão retornadas para o usuário. É nesse ponto que o grosso da programação irá acontecer, onde se poderá acessar o banco de dados para buscar informações, manipular os dados recebidos, manipular informações, e fazer toda a mágica do seu programa.

Template

Após toda a mágica e toda a manipulação acontecer, é chegada a hora de devolver as informações para o usuário. Uma view pode conter diversos métodos que lidem com diferentes requisições para aquela url (se é um GET ou um POST, por exemplo) e no final os métodos devem retornar tanto os dados quanto qual arquivo html (template) deve ser renderizado na hora de mostrar as informações para quem fez a requisição. Esse retorno pode acontecer de diversas formas, o Django pode inclusive lidar com as suas requisições sozinho, sem você precisar codar todo o comportamento. Você vai ter que pesquisar para ver qual forma funciona melhor para você, e eu posso inclusive fazer um post sobre isso no futuro.

Sucesso!!

Uma vez que a view retorna as informações e qual arquivo html deve ser renderizado, o Django irá mostrar essa página para o usuário e então (se tudo for feito da forma correta) é só sucesso!!

Espero que você tenha conseguido entender o fluxo de uma requisição no Django, mas sinta-se à vontade para comentar suas dúvidas se não tiver entendido, qualquer dúvida é válida.