2 postagens marcadas com "Github"

"Muitas pessoas possuem o Github, mas não entendem o real peso, a real importância de manter seu portfólio, sua porta de entrada bem atualizada e chamativa para qualquer um olhar e se impressionar com o que você desenvolve."

Por esses dias, vejo muitos desenvolvedores júniors ou até mesmo alguém em busca de um estágio que se quer possuí um perfil no Github ou nem está atualizado, bem estruturado ou com um bom README. E isso é um grande problema, pois o Github é uma das plataformas mais utilizadas por empresas para analisar o perfil de um candidato, e se você não possui um perfil bem estruturado, você pode perder uma imensa oportunidade de emprego.

Usando como base o meu próprio perfil, vou ensinar algumas técnicas que utilizo e que me auxiliarem a chegar aonde cheguei, claro, tem muita coisa que pode estar faltando e é importante, não sou uma verdade absoluta, mas é um começo.

Antes de começarmos a configurar, qual é o seu foco? Atingir públicos nacionais ou internacionais?

Se o foco for apenas o pessoal do Brasil, deixei em português, mas se o foco for internacional, deixe tudo em inglês, literalmente TUDO, nomes de repositórios, descrições dos projetos, os READMEs, o subtítulo de seu perfil, TUDO. Pois é uma forma de você se comunicar com o mundo, e isso é muito importante.

Faça um ou o outro, nunca os dois.

Por onde começar?​

Vamos começar com o lado esquerdo do nosso Github

O que é ideal? Novamente lembrando, não sou o dono da verdade, são apenas recomendações que sigo para que meu perfil seja bem visualizado.

Se estou em busca de um emprego, o ideal é ter uma ótima foto de perfil mostrando seu profissionalismo ou seu carisma, uma foto de família, uma foto que não mostre quem de fato você é, acaba que não ajudando a definir se DE FATO, o perfil é seu. Depois que já estiver empregado, você pode colocar uma foto de família, de viagem, de anime, não tem problema algum, é mais para transmitir conforto em quem vê seu perfil e enxerga a humanidade em você.

Vale lembrar que muitos - mas não todos - recrutadores possuem a mentalidade de que se você não tem uma foto de perfil, você não é uma pessoa confiável ou que possa estar se passando por outra pessoa, então, se você não tem uma foto de perfil, coloque uma foto sua, mesmo que não seja a melhor, mas que mostre quem você é.

E depois, coloque o que está buscando, o que você faz ou o seu real foco, alguns exemplos a seguir são: "Desenvolvedor Front-end / React, Next, Vue" ou "DBA com MongoDB e MySQL". Isso ajuda na busca, na seguimentação do que você está procurando, qual é o seu verdadeiro foco.

O que colocar no seu README?​

Inicialmente como já definimos a nossa linguagem de comunicação (Inglês ou Português), vamos nos apresentar. Opcionalmente, ou seja, não é obrigatório, você pode colocar um banner como o cabeçalho (1500x500), nele você pode falar sobre algo que gosta na tecnologia ou até mesmo se apresentar como um .gif, informando coisas que gosta, se está procurando uma oportunidade ou não, mas não é obrigatório, é apenas uma forma de chamar a atenção de quem está vendo seu perfil.

Logo abaixo, você se apresenta, como "Bem-vindo ao meu perfil", "Oi, meu nome é Fulano", ou um título seu README, enfim, é uma forma de você se apresentar para quem está vendo seu perfil de uma maneira simpática.

Depois, você pode colocar um resumo sobre você, os setores de empresas em que já trabalhou para mostrar que em questão empresarial, você não possuí um nicho específico ou fala sobre você de uma forma bem breve, mas intuitiva.

Depois disso, fale sobre você, fale sobre alguns projetos que você carrega no peito, mas apenas indicativo, nada de fazer um mural sobre isso, senão teremos muita informações. Separe as tecnologias que você sabe, as tecnologias que está aprendendo, as tecnologias que já trabalhou e as tecnologias que pretende aprender, assim a pessoa tem uma noção maior do nível da carreira que está seguindo, os passos que está tomando e as diretivas que está seguindo. Informe também sobre o que está buscando, qual é o seu foco, se está em busca de uma mentoria, deixe explicito suas intenções.

Não acho interessante informar sobre coisas que gosta de fazer como ler, jogar, ouvir música, pois isso é algo pessoal, e não é algo que vai te ajudar a ser contratado de alguma maneira, até hoje não vi como um ponto positivo durante uma entrevista. Mas se mesmo assim quiser colocar, use essa seção.

E depois informe algumas curiosidades sobre você, mas de novo, focado no âmbito da tecnologia, projetos a parte que já fez, algo que já desenvolveu fora da trilha que está seguindo e seria interessante, cursos que já fez, palestras que já participou, enfim, algo que te faça ser lembrado de uma forma positiva.

Você pode inserir links de publicações, como eu fiz a respeito de artigos que já escreveu, ou artigos que gostam e leva como inspiração, não é obrigatório, mas é uma forma de você mostrar que você é uma pessoa que está sempre em busca de conhecimento e que está sempre se atualizando.

Coisas que não recomendo​

Colocar muitas informações e transformar o seu README como um currículo não é ideal, já que existem muitas informações que não são relevantes para o recrutador, como por exemplo, colocar informações sobre o seu estado civil, se você tem filhos, se você tem animais de estimação, se você gosta de ler, se você gosta de jogar, enfim, essas informações não são relevantes para o recrutador, então, recomendo não colocar.

Encher de figurinhas, como se estivéssemos na época do Orkut só mostra o quanto desorganizado visualmente é você, deixar aquela cobrinha comendo commits não é nenhum pouco interessante? O motivo? Você consome um bloco de tamanho para reservar para algo nada visualmente atrativo e que não traz nenhuma informação relevante para o recrutador.

--

Existem várias maneiras de se apresentar, não existe um método único, mas o recomendado é você ver como seria a visão do recrutador, a informação é relevante? Falar que você é Design Gráfico é interessante quando a vaga é de fullstack ou é interessante para uma comunidade de desenvolvimento?

Coloque as suas decisões na ponta do lápis e vai filtrando com as informações que você possua.

Não esqueça de deixar bem documentado seus projetos e claro, informe um link para que o recrutador possa ver o que você desenvolveu, ele não vai saber dar um git clone instalar o yarn para rodar a aplicação por exemplo. Facilite a vida deles e de quem está olhando o seu perfil.

No mais é isso, qualquer dúvida, você poderá me encontrar na Kalify Community™ pelo Discord.

"Quando se trata de ter dois ambientes, os problemas são maiores, mas é melhor do que ter um problema maior do que eles que possa tomar muito de seu tempo."

Inicialmente vou apresentar a situação em que trabalho hoje. Tenho um computador com uma Geforce GTX 1660, i7–3770, 24GB de RAM, 1 HD 1TB e 1 SSD 256GB com Windows 10 Pro.

Ah, mas você é desenvolvedor, porque não usa alguma Distro Linux? O único problema é que direto mexo com Adobe Photoshop e gosto muito de jogos que não possuiem compatibilidade com Linux como jogos que estão na Steam, Epic Games, Ubisoft, EA Play, enfim, o que leva muita dor de cabeça para tentar se adaptar.

Tá, mas então, que tal um Dual Boot?​

O problema do dual boot é que já fiz ele cerca de três vezes na minha vida. O que mais me quebra é ter que ficar desligando e ligando pra pegar certas coisas ou fazer certas edições — como trabalho em alguns projetos solos, dependo do Photoshop para fazer edições rápidas e que já tenho facilidade no manejo — e sem falar que nas três vezes aconteceu um problema com um seguinte cara: O tal do GRUB corrumpido.

Essa é a maior dor de cabeça que existe, um GRUB corrompido, para quem não sabe, ocorre quando você troca muito de sistema e existe a incompatibilidade deles em comunicarem entre si, identificarem que são sistemas diferentes, o que acaba acontecendo deles se corromperem. Sim, se corromperem, os dois sistemas vão pro saco. ~ Espero estar certo sobre essa linha de pensamento, se eu estiver equivocado, me corrijam.

O que gera uma mega dor de cabeça, arquivos inrecuperáveis, enfim. Minha solução para isso, foi WSL.

WSL é o Windows com um Subsystem do Linux no próprio sistema, permitindo eu mexer no Terminal do Ubuntu (ou qualquer outra distro Linux instalada) e usufruir como se estivesse usando uma máquina Linux.

Tá, mas vai ao que importa.

Qual é o problema do Github Desktop vs WSL?​

Ao colocar projetos do Github no WSL, não existe problema algum. Mas você pedir para que o Github Desktop (Windows), veja os arquivos do Linux (WSL) e que façam os commits, todo bonitinho, tem um problema.

O Windows e Linux não se conversam, a maneira de gerar um arquivo é diferente, a leitura de documentos, dependendo, é diferente, então acaba que gerando vários conflitos. E um deles é que existe a grande probabilidade ~ aconteceu comigo, no meu caso ~ dele (Windows) gerar arquivos que jamais foram modificados ou criados e que só vão servir para poluir a aplicação e atrapalhar sua vida, já que não é possível remover eles (exceto pela CLI) e se deixar eles guardados (Stage Commits), eles vão atrasar você de trocar de brench. Resumindo, um saco.

A solução para isso? Criar o mesmo repositório no Windows e fazer essa manobra nada agradável, mas que me poupará de várias dores de cabeça com o Github Desktop.

Criando o projeto no Windows, fazendo os commits no WSL e manipulando as cherry-picks no Windows, fica muito mais fácil.

E por que você não usa o Git no Terminal direto e para de usar o Github Desktop? Facilitaria sua vida, não?​

Sim, facilitaria, não iria precisar de dois projetos no mesmo dispositivo e essa manobra sem sentido. Não é falta de profissionalismo da minha parte em decorar os comandos do git, muito pelo contrário, o problema é que sou alguém mais front-end, vamos assim dizer e ~ muitos vão me hatear por isso ~ mas, nesse aspecto, prefiro o visual e principalmente quando existem conflitos, problemas de versionamento, acompanhar a árvore de commits para ver quem subiu, quem não atropelou ninguém o Github Desktop facilita em muito minha vida.

Sem falar que já me evitou inúmeras vezes de subir arquivos indesejavéis ou que se quer foram alterados e estão subindo mesmo assim.

É muito melhor ~ no meu ponto de vista ~ ser mais visual e trabalhar corretamente, do que simplesmente ser cool e oldschool e viver batendo cabeça por fazer merda, se matar em fazer uma cherry-pick ou alterar as ordens de commit.

Mas enfim, essa foi apenas uma experiência que gostei de compartilhar e espero que sirva para inspirar ou qualquer coisa do tipo. Se quiser conversar um pouco a respeito, estarei tanto no Twitter como @Yagasaki7K como no Discord através da Kalify Developers.