"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.

"Eu estava em uma reunião da empresa que trabalho e o assunto era sobre o monorepo, o que é, como funciona e quando é melhor utilizar. A discussão foi muito boa e acredito que todos os envolvidos saíram com uma visão diferente sobre o assunto..."

Eu estava em uma reunião da empresa que trabalho e o assunto era sobre o monorepo, o que é, como funciona e quando é melhor utilizar. A discussão foi muito boa e acredito que todos os envolvidos saíram com uma visão diferente sobre o assunto. Mas, como sempre, ficou aquela dúvida, quando é melhor utilizar um monorepo ou vários repositórios?

Existem vários fatores a considerar quando se decide se é melhor trabalhar em um monorepo ou em vários repositórios individuais. Alguns fatores a considerar incluem:

Tamanho do projeto: Monorepos são mais adequados para projetos maiores e mais complexos, pois permitem que você mantenha todo o código e os recursos relacionados em um único lugar.

Colaboração: Monorepos podem ser mais eficientes para equipes que trabalham em múltiplos projetos ou componentes, pois permitem que os desenvolvedores compartilhem código e recursos com facilidade.

Integração contínua: Monorepos podem ser mais fáceis de integrar com ferramentas de integração contínua, pois permitem que você execute testes e builds em vários projetos ao mesmo tempo.

Dependências: Monorepos podem ser mais fáceis de gerenciar quando se trata de gerenciar dependências entre projetos, pois permitem que você faça referência a outros projetos diretamente no mesmo repositório.

Flexibilidade: Monorepos permitem mais flexibilidade na estrutura do projeto, pois permitem que você mude a estrutura do projeto a qualquer momento, enquanto que repositórios individuais são mais rígidos.

No final, a escolha entre um monorepo ou repositórios individuais depende da sua equipe e do projeto em questão. É importante avaliar as necessidades do seu projeto e as vantagens e desvantagens de cada abordagem antes de tomar uma decisão.

E um conselho que deixo é, use o Nx, um dos melhores gerenciadores de monorepos que existe no mercado. Ele é muito fácil de usar e permite que você crie um monorepo com apenas alguns comandos e de diversas formas possíveis como: Docusaurus, React, Next, Vite, Svelte e etc.

"Hoje mais cedo estava navegando no Twitter como de costume e o usuário Thiago havia publicado uma dica, uma solução de nossos problemas. Para quem usa o Twitter através do computador, sabe que com a adesão do Twitter Analytics tudo ficou mais poluído ..."

Hoje mais cedo estava navegando no Twitter como de costume e o usuário Thiago havia publicado uma dica, uma solução de nossos problemas. Para quem usa o Twitter através do computador, sabe que com a adesão do Twitter Analytics tudo ficou mais poluído, sujo com mais coisas em tela, e Elon Musk está atrás de adicionar o botão para ficar alternativo essa opção, ele já se prontificou quanto a isso, a feature de ver quantas pessoas visualizaram seus tweets existe e é um desastre só, mas enquanto esse botão de ligar e desligar não chega, segue a dica de nosso amigo.

Inicialmente vá até a página do feed de notícias do seu Twitter. Abra o console através do F12 ou com o botão direito do mouse e inspecionar elemento, vá na aba de "Console", cole o código abaixo e instantaneamente verá a feature sumindo:

    function removeIcon () {  
    setInterval(() => {
    [...document.querySelectorAll(".css-1dbjc4n.r-18u37iz.r-1h0z5md")].filter(div => div.innerHTML.includes("analytics")).forEach(div => div.remove())
    }, 50)
    };
    removeIcon()

Mas lembre-se, toda vez que você reiniciar a página (F5), será necessário colocar o código novamente, então deixe essa dica salva enquanto o Elon Musk tem dificuldade para fazer isso em grande escala, apesar que isso seria maior gambiarra se estivesse no código fonte do Twitter 😂

Existe o README do código dele, caso você esteja com dificuldades para entender como funciona o processo e conta com um .gif do passo a passo necessário para remover o botãozinho mal feito.

Atualização: Para uma questão mais permanente, existe também uma extensão do Chrome conhecida como Hide Twitter Elements, desenvolvido pelo Shodipo Ayomide e que através dele, você consegue esconder Analytics, Retweets, Comentários e até Likes, deixando um aplicativo minimalista e de acordo com a suas necessidades, você pode encontrar a extensão do Chrome ou o código aberto do projeto para desenvolver em outros navegadores ou melhorar a versão já atual.

"O Dark Mode vem sendo requisitado por muitas pessoas, isso até mesmo por mim, ninguém aguenta aquele holofote na sua cara às duas da manhã por abrir uma página web que não tem dark mode incluso."

Eu por exemplo, recorro ao Dark Reader por padrão e vou filtrando quando o site ou página já possuí ou não o sistema de temas alternativos, assim, vou configurando todo mundo que acesso para não me agredir os olhos.

Mas vamos lá, aos desenvolvedores.

Vou analisar com vocês o seguinte cenário.

Imagine que você está desenvolvendo um site, um portfólio, um ecommerce ou qualquer outra página na web e você precisa incrementar o dark mode, qual é a melhor forma de fazer isso?

Através do LocalStorage ou Cookies? Através do Scheme de cores que puxa as cores padrão do dispositivo do usuário? Deixamos no botão e o usuário vai ter que clicar para trocar toda vez que acessar? Ou através do horário?

Vamos discutir os prós e contras de cada um:

LocalStorage ou Cookies​

LocalStorage ou Cookies é interessante pelo seguinte fator, o usuário escolhe qual tema seguir, se é dark ou light e sempre que ele voltar, ele estará com aquele tema escolhido. O problema disso? É que toda vez que acessar um dispositivo novo, ele é obrigado a fazer a configuração novamente, e claro, se ele esqueceu no modo light e retornar em uma hora da noite, ele vai receber aquela luz imensa no meio da cara.

Prefers-color-scheme​

Prefers tem um método inteligente, ele vai pegar as cores do dispositivo do usuário (ou browser) e vai informar ao CSS qual é o modo, se for light, ele manterá igual, se for dark, ele irá jogar o tema escuro antes de qualquer coisa, assim, poupando configuração ou até mesmo acidentes. A desvantagem nisso é que não é possível deixar configurável para o usuário, exceto através do navegador ou dispositivo e, caso o usuário tenha um dispositivo antigo que não possua dark mode, ele infelizmente ficará travado no light mode.

Botão de switch​

O botão de switch é uma tratativa interessante também, mas traz consigo uma dificuldade, diferente do LocalStorage, que toda vez que o usuário acessar, ele é obrigado a configurá-lo novamente e fica travado nessa limitação, já que por default ele estará em light mode, inclusive a cada atualização de página.

Horário de dia/noite / Local Time​

Já o método dia/noite que foi abordado inicialmente pelo Essentials ~ mas hoje não funciona mais assim ~ é das seis da manhã até as seis da noite ficar no light mode, e das seis da noite às seis da manhã ficar no dark mode. A desvantagem nisso é ficar limitado ao horário do dia, não tendo personalização nenhuma e travado nesse esquema. Para aqueles que usam light mode até mesmo de noite, ficaria a limitação de ficar no dark mode e não poder fazer nada a respeito

—

E aí? O que achou? Qual é a melhor alternativa para se desenvolver e aplicar no seu site ou projeto? Vale lembrar que dessas quatro alternativas, nenhuma delas é obrigatória, mas é bom entrarmos num consenso e claro, elas não são mescladas, já que não é possível deixar o LocalStorage ativo enquanto puxa o Prefers-colors-scheme, já que ele sempre vai substituir o mais antigo.

—

Eu ensino através de analogia e é a coisa mais interessante que existe e poucas pessoas usam, já que você ensina usando o cotidiano como exemplo.

Queria ter recebido esse recado mais cedo, teria me ajudado muito e poupado muita dor de cabeça para entender o que é um teste unitário.

Em questão de código, vai de cada um se vai usar um Jest, React Testing Library ou qualquer outro, o importante é saber o que de fato acontece, quando incrementar e como incrementar.

"Me considero desenvolvedor fazem oito anos ~ desde essa publicação ~ e somente agora entendi como e para quê serve teste unitário."

Me considero desenvolvedor fazem oito anos ~ desde essa publicação ~ e somente agora entendi como e para quê serve teste unitário.

O teste unitário é algo que é muito requerido pelo mercado, mas POUQUÍSSIMA gente sabe DE FATO, como explicar para um iniciante para que serve um teste unitário e quando utilizá-lo.

E eu vou acabar com esse problema DE VEZ! Já que é um conselho que eu gostaria de ter recebido quando comecei a escrever códigos em React/NextJS em 2020.

A Analogia​

Imagine o seguinte cenário, você tem um carrinho e precisa saber o preço de todas as coisas que nele tem. Seria muito custoso para você ficar pensando em cada preço, fazendo o cálculo de cabeça para finalmente chegar no caixa e dar o dinheiro certinho, certo?

Esse cenário funciona para coisas que a gente consegue carregar na nossa mão, mas quando se trata de um carrinho, é muito trabalhoso e muitas vezes nem vai estar certo.

O Teste Unitário​

O teste unitário nada mais é do que o caixa do supermercado, ele será responsável por pegar cada produto e validar ele, verificando o preço e se de fato ele é o produto que você selecionou. Nossa mente processa isso tão rapidamente que se quer analisa duas vezes se pegamos o produto corretamente, exceto quando é um produto que não foi verificado na primeira vez.

Então saiba que para usar um teste unitário, não é necessário para uma conta de 1+1 por exemplo ou 35+65, ou seja, coisas simples, mas quando envolve muita entrada e saída de dados, algo mais complexo, como o caso de um carrinho de compras, então sim, incremente um teste unitário, verifique se aquela classe ou função está agindo como deveria para evitar qualquer tipo de erro, problema ou dor de cabeça na sua vida, ainda mais quando se trata de pagar pelas compras no final dessa brincadeira.

Antigamente usávamos muito o papel para testar se a lógica de nossa programação estava correta, mas em questões profissionais, não será possível ficar explicando tudo que acontece no papel para cada membro que entrar na equipe, então, escreva testes.

—

Eu ensino através de analogia e é a coisa mais interessante que existe e poucas pessoas usam, já que você ensina usando o cotidiano como exemplo.

Queria ter recebido esse recado mais cedo, teria me ajudado muito e poupado muita dor de cabeça para entender o que é um teste unitário.

Em questão de código, vai de cada um se vai usar um Jest, React Testing Library ou qualquer outro, o importante é saber o que de fato acontece, quando incrementar e como incrementar.

"Zeno Rocha imaginou aquilo que todo desenvolvedor front-end estava cansado de tentar desenvolver."

Zeno Rocha imaginou aquilo que todo desenvolvedor front-end estava cansado de tentar desenvolver. Ou até mesmo sair das antigas semânticas do HTML que já estão para lá de ultrapassados.

Quando o assunto é email marketing, já sabemos a dificuldade que isso é para muita gente, isso inclui principalmente o CSS já que não temos o CSS-grid ao nosso lado e dependemos de tables para todos os lados.

Zeno foi a frente e já deu seu primeiro pontapé em desenvolver layouts de email marketing usando React e Typescript, dessa forma, produzimos emails mais profissionais e com cara de big techs.

A imagem acima é um exemplo de layout produzido como um convite para ingressar em um projeto da Vercel, mas usando a estilização e o modelo direto do React Email.

Interessante o profissionalismo que ele propaga e como isso torna tudo muito bem produzido e mais bonito, não é mesmo?

Em breve ~ com base na data da produção desse artigo ~ Zeno estará produzindo a versão live preview, dessa forma você poderá fazer testes diretamente no browser ao invés de enviar centenas de e-mail testes para avaliar e conferir os debugs.

Mais informações você poderá estar acompanhando a documentação do projeto original através desse link.

"Estava navegando no Twitter e vi, não uma, não duas, mas várias reclamações de artistas sobre “pessoas que pagaram para ter imagens geradas pela inteligência artificial e não apoiam o artista”."

Com esse lance todo, queria mostrar minha OPINIÃO a respeito disso, ainda mais sendo um Desenvolvedor de Software que sou, e por ter adquirido também ao material, acredito que isso poderá dar uma visão bem interessante sobre a coisa como um todo e isso envolve até mesmo minha experiência.

Vamos lá.

Preço x Acessibilidade x Personalização​

Um dos pontos que acredito que as pessoas aderem a essa ferramenta é em questão de preço x acessibilidade x personalização. Preço: Você vai pagar menos em várias artes, coisa que um artista vai te cobrar em uma única arte. Acessibilidade: Estará pronto em pouco tempo para mim. Personalização: A variedade ofertada é muito mais que um artista.

Mas vamos aonde eu quero chegar. Não estou desvalorizando a profissão do artista, desenhista, ilustrador, JAMAIS!

Sou desenvolvedor, sei o quanto é chato você mostrar seu trabalho para o cliente e ele falar que está muito caro, ou não valorizar o esforço que teve para chegar nesse resultado. Sabemos que abaixo desse valor e tempo é exploração e sabemos dar valor ao nosso trabalho, esforço, ferramenta e estudo em cima daquela arte ou produto.

Mas infelizmente, a realidade é essa. Quanto mais barato, mais rápido for, será melhor, o pessoal não quer saber quem está por trás disso, mas sim na acessibilidade sobre ter aquele conteúdo, aquele resultado.

A questão da personalização é que em questão de vinte minutos ~ usando a Lensa como exemplo ~ temos cinquenta imagens com dez variedades de estilo ~ usando a versão básica da plataforma ~ mas em quanto tempo levaria um artista para produzir na mesma medida? Eis a questão. As pessoas querem variedades de algo em pouco tempo.

E a personalização? Mudança de traços? Sem falar as alterações, porque SEMPRE existe aqueles clientes chatos que quer uma coisa, vê outra e quer sempre ficar mudando, trocando totlamente daquilo que desejou inicialmente, é chato, é frustrante e desgastante, leva tempo, recurso e dinheiro.

O BOOM para o artista​

O BOOM é que agora vocês (artistas) terão o funil correto de venda, o mesmo exemplo que eu, como desenvolvedor tenho. Quer pagar mais barato? Quer ir lá com o primo (IA) que acha melhor e mais em conta? Fica a vontade, mas a personalização, a exclusividade e um trabalho bem feito, somente eu poderei oferecer. Isso é algo que o Wix, Blogger, Wordpress oferece para clientes no-code, e está tudo bem, mas isso aumenta em mais minha preferência em transformar o meu trabalho em algo exclusivo, único e no preço que DEVE DE FATO, ser cobrado para aquele que DE FATO quer o meu trabalho.

A Inteligência Artificial é um ponto em que vai abrir muitas alas para os artistas, tanto em questão de melhorias, quanto em questão de mostrar que é básico o serviço que eles oferecem, sendo generalizado, bugado e limitado.

É hora de se reinventar, ser diferente, colocar a criatividade em dia, sei que é muito frustrante ver algo sendo tomado pela tecnologia, senti isso quando vi o Wix pela primeira vez, um trabalho que levo quatro dias sendo destruído de forma rápida e sendo substituído por algo barato e ralo.

Mas levei em consideração uma única coisa, ELE É LIMITADO, nós não.

Cresça, invista em desenvolver artes para jogos, livros, lofi, personagens únicos ~ um exemplo disso é o artista que compartilhava suas artes no Twitter e hoje é patrocinado pela TNTSportsBR por imaginar personagens de luta sendo representado em países e estados brasileiros ~ se reinvente. Esse tipo de coisa não é algo que uma inteligência artificial poderá substituir tão facilmente, ainda não.

Não adianta chorar​

Infelizmente não adianta, é uma luta diária para ser melhor que uma inteligência artificial, se destacar, ganhar atenção no mercado , concorrer com outros artistas e ser único, eu sei que não é fácil. Mas todo mundo, com esforço, força de vontade e persistência terá seu lugar ao sol.

Erga essa cabeça!

E no mais, busque ser único, se destaque, não se lamente.

Lembre-se: Um mangaká ~ artista de desenho japonês ~ não será substituído por uma IA por conta do seu esforço, por ser original e único, lembre-se disso.

Um abraço a todos os colegas ilustradores e desenhistas, que redobrem suas forças e dedicações para conseguir finalmente atingir seus sonhos e objetivos. No mais! Estarei no Twitter.

"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.

"Um desafio seguido de muita quebra de cabeça e depois, o alivio. Obrigado The Programmer”s Hangout!"

Essa semana me deparei com um problema, era um problema simples, enviar uma requisição para um endpoint (POST) para enviar o nome do usuário e o e-mail dele, a famosa Newsletter. Em tese não tem muito segredo nesse código, você precisa pegar os valores do input e passar para o corpo da requisição para enfim depois, enviar em um formato JSON (comunicação universal).

A questão é que eu estava com um problema tão grande com o NextJS a respeito de enviar a requisição, que toda as vezes que eu clicava em enviar, ele retornava “Failed to fetch”, não entendi o porquê, isso porque estava usando console.log(error) e ele apenas informava isso e nada mais.

Graças a um usuário do Discord (gosha#6801), me informou que pelo fato de estar enviando uma requisição utilizando form, não dava tempo de enviar a requisição, já que todas as vezes, ele dava refresh na página e cancelava. A resposta para isso? Era utiliza o onSubmit={(e) => e.preventDefault()} e redirecionar o usuário quando terminasse a execução.

O que o código faz? Ao dar submit, ao invés dele dar aquele famoso refresh do formulário, ele apenas enviará e irá dar um “pausebreak”, não dando continuidade na questão de refresh, assim ficará a sua mercê do que quer fazer em seguida.

Foi de primeira, na lata, certeira. E agora, documento isso para servir de lição não apenas para mim, mas para qualquer um que estiver com dificuldade de utilizar uma requisição em NextJS ou até mesmo em React.

No final do artigo, foi o código utilizado para enviar uma requisição, caso queira reaproveitar, é só substituir o API_URL pela URL do servidor que você deseja enviar: Corpo do formulário:

<form action=”” onSubmit={(e) => e.preventDefault()}> { … conteúdo … } </form>

Vale lembrar que os alert são apenas para informar o usuário do que aconteceu. Simplesmente pegar o dado e redirecionar ele sem avisar, faria com que ele ficasse em duvida se a mensagem foi enviada mesmo ou não. Quanto ao JSON.stringify(submit), pegamos o valor do submit que nada mais que o corpo da requisição, já pegando os valores dos inputs baseado no ID (você pode capturar esses dados e colocar dentro de um useState se for algo mais dinâmico ainda e redirecionar os valores dos States ao invés do getElementByID direto, como eu fiz). Essa foi minha experiência, não estou acostumado, quebrei bastante a cabeça e espero que possa ajudar o meu eu do futuro e também a vocês.

Qualquer dúvida estou a disposição no Twitter como @Yagasaki7K.

// inside a function to get values and send to API
let nome = document.getElementById('nome').value;
let email = document.getElementById('email').value;

let submit = {
    nome: nome,
    email: email
}

// send a contact message to API
fetch('API_URL', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify(submit),
    })
    .then((response) => response.json())
    .then((data) => {
        console.log('Success:', data);
        alert('Mensagem enviada com sucesso!');
        window.location.href = '/';
    })
    .catch((error => {
        console.error('Error:', error);
        alert('Erro ao enviar a mensagem, tente novamente mais tarde!');
    });
});

"O livro foi escrito por Zeno Rocha e foi resumido pelo Felipe Suri."

Eu estava navegando na internet quando me deparei com esse livro. 14 Hábitos de Desenvolvedores Altamente Produtivos, escrito pelo Zeno Rocha, não cheguei a fazer a aquisição dele, mas encontrei um breve resumo do Felipe Suri e decidi compartilhar alguns desses hábitos, não colocarei os catorze aqui, já que prefiro selecionar os mais importantes para mim, que futuramente servirá como um lembrete e acredito que servirá também para você.

Foco nos fundamentos​

“Você pode praticar arremessos oito horas por dia, mas se sua técnica estiver errada, tudo o que você se tornará será muito bom em arremessar da maneira errada. Pratique os fundamentos e o nível de tudo o que você fizer vai subir.” — Michael Jordan.

A ideia principal é que, aprender os fundamentos vai te preparar para o futuro. Se você deseja se tornar um ótimo desenvolvedor, é importante entender os principais conceitos, como algorítimos, lógica, redes, acessibilidade, segurança e experiência do usuário. Você não precisa necessariamente deles, para criar a sua primeira aplicação, mas conhecê-los vai te ajudar a criar os próximos dez aplicativos complexos que você criará no futuro.

Gaste um tempo pesquisando quais são os conceitos fundamentais em seu campo. Pegue um pedaço de papel e divida-o em duas colunas. No lado esquerdo, liste todo o conhecimento que você já possui. No lado direito, liste todo o conhecimento que você ainda precisa adquirir. Planeje um horário dedicado do seu dia para estudar esses conceitos.

Para escolher uma nova linguagem, tenha confiança de que ela é a melhor escolher possível, busque entender a teoria por trás de cada recurso. Para aprender uma linguagem, tente reescrever algum projeto já feito em outra linguagem, pois assim seu foco será todo em entender a linguagem e não em resolver o problema da aplicação.

Ensinar é igual a aprender​

“Poder não vem do conhecimento adquirido, mas do conhecimento compartilhado.” — Bill Gates.

Caso você decida ensinar alguém, não será fácil, você vai querer desistir muitas vezes. Segundo diversos estudos, o medo número um das pessoas é falar em público. 5 atos das apresentações do Zeno Rocha:

Ato 1 — O convite: Tudo começa com um e-mail aleatório. De repente chega uma notificação em seu e-mail, é de um organizador de eventos que está animado com o trabalho que você faz. Ele pede para que você vá no evento que ele está organizando para você compartilhar o seu conhecimento. Você aceita esse convite.

Ato 2 — Cai a ficha: Algum tempo depois, você olha o seu calendário e percebe o quão rápido aquele evento está se aproximando. Você entra em pânico quando percebe que ainda nem começou a trabalhar a sua apresentação. Você sabe que precisa preparar algo, porém sempre aparece algo mais importante para fazer.

Ato 3 — Surtando: Os dias se passaram e chegou a semana do evento. Você ainda não conseguiu preparar seu conteúdo. Você começa a se arrepender e se perguntas ”Por que eu aceitei esse convite? Que desculpa posso dar? Sou apenas um desenvolvedor, não sou palestrante!”. Agora, as passagens de avião já foram compradas, a reserva do hotel, feita e a organização do evento já anunciou seu nome e você não pode voltar atrás. Então de alguma forma você encontra tempo e prepara o seu conteúdo.

Ato 4 — A hora da verdade: O dia do evento chegou. Você está prestes a apresentar-se para centenas de pessoas. Você está com medo e se sente uma fraude. Mas você não pode recuar, você apenas enfrenta a situação e tenta fazer o seu melhor.

Ato 5 — Vamos fazer de novo: A sua apresentação termina. Sua adrenalina está extremamente alta. Algumas pessoas te procuram nos corredores e perguntam sobre algumas ideias que você compartilhou. Você se sente incrível e sente que causou impacto na vida de outras pessoas. Alguns meses depois você se submete a outro evento e tudo acontece de novo.

No fim das contas, que tira o proveito da situação de ensinar outras pessoas, é você, que aprendeu mais alguma coisa no meio dessa situação toda.

Encontre um evento online e submeta uma apresentação. Abra um software de compartilhante de tela e registre-se fazendo alguma coisa. Crie um blog e compartilhe um artigo. Escolha qualquer tópico que você deseja aprender e tente ensiná-lo.

Hábitos do dia-a-dia​

“Tudo que precisa ser dito já foi dito. Mas, como ninguém estava ouvindo, tudo deve ser dito novamente.” — Austin Kleon.

Há uma linha tênue entre intensidade e burnout (esgotamento profissional). Muitos de nós já cruzamos essa linha e é muito difícil voltar. Quando este tipo de comportamento [passar horas extras no escritório] se torna normal, você deve parar e prestar atenção ao que realmente está acontecendo.

Quebrar as regras. Fazer o que quiser. Esses conceitos são todos admirados por nós. No fundo, todos nós queremos ser rebeldes. Disciplina. Consistência. Persistência. Esses conceitos não são nada sexy, mas são a chave para jogar jogos infinitos.

Pesquisa de James Carse: Jogos finitos vs Jogos infinitos.

O jogo finito é definido como tendo jogadores conhecidos, regras fixas e objetivos preestabelecidos.

O jogo infinito, por outro lado, é definido como aquele em que existem jogadores conhecidos e desconhecidos, as regras são mutáveis e o objetivo não é vencer, é continuar jogando.

Como não há vencedores e perdedores, o que acontece é que os jogadores abandonam o jogo quando ficam sem vontade ou sem recursos para jogar, o que os leva a serem substituídos por outros jogadores.

Quando há um jogador finito contra um jogador finito, o sistema é estável.

Quando há um jogador infinito contra um jogador infinito, o sistema também é estável. Os problemas começam quando o jogo é de um jogador finito contra um jogador infinito, pois o jogador finito está jogando para ganhar e o jogador infinito está jogando para permanecer no jogo.

A programação é um jogo finito. O objetivo é continuar jogando, visto que você não pode vencer na programação, você só pode continuar evoluindo.

Programadores que jogam o jogo finito, estão focados em bônus no final do ano.

Programadores não devem fazer estimativas com dias perfeitos, pois sempre terá alguma distração durante o seu dia.

Não trabalhe durante a noite, isso não te dará clareza para pensar no outro dia.

Os melhores programadores, geralmente são mais disciplinados, sempre são organizados.

Os bons programadores, investem tempo em se comunicar bem e com clareza.

Faça o seu futuro eu​

“Quando você sentir necessidade de fazer um comentário, primeiro tente reestruturar o código de modo que qualquer comentário se torne supérfluo.” — Martin Fowler.

Até os melhores programadores do mundo, já escreveram código ruins no passado.

A razão pelo qual escrevemos código ruim ou enviamos commits meia boca está relacionada com o que estamos passando naquele dia em específico. Nós geralmente escrevemos código para o “eu atual”. Mas na verdade, precisamos escrever para o “eu do futuro”.

Da próxima vez que for escrever uma linha de código se pergunte: “O futuro eu, entenderá o que essa linha faz?” Abra um projeto atual em que você esteja trabalhando. Existe alguma refatoração que você possa fazer para facilitar a vida do seu eu do futuro? Quando você faz uma pequena modificação no inicio de um projeto, pode mudar significativamente o fim dele.

Busque os seguintes passos:

• Escrever código simples com nomes significativos da variáveis/métodos e classes. Não assuma que outras pessoas entenderão nomes abreviados que não significam muito ou alguns termos que podem mudar com o tempo.

• Ter bons testes automatizados. Isso fornecerá documentação adicional sobre seu código e também ajudará qualquer pessoa que precise trabalhar nele no futuro.

• Use ferramenta de controle de versão como documentação. A medida que o projeto evolui, são feitas alterações e correções de bugs o tempo todo. No futuro, quando se tornar um código legado, ninguém conseguirá entender as decisões e alterações feitas naquele momento, se não estiverem documentadas. O histórico de commits e pull request são uma boa ferramenta para explicar os porquês.

Disciplina vs Motivação​

“Não espere estar motivado todos os dias para chegar lá e fazer as coisas acontecerem. Você não estará. Não conte com a motivação. Conte com a disciplina.” — Jocko Willink.

O trabalho normal de um programador não é suficiente para mostrar todo o seu potencial. Geralmente estamos vinculados a restrições tecnológicas da empresa. Você possui tempo suficiente, não deixe de ser uma pessoa melhor em busca de ser um programador melhor, faça ambos ao mesmo tempo.

Pense nas habilidades que você acha que poderiam ser melhoradas. Você pode planejar um tempo extra para desenvolvê-las? Até mesmo 10 minutos por dia podem fazer a diferença.

Domine o lado sombrio da força​

“Nomeado deve ser o seu medo, antes de bani-lo, você pode.” — Yoda.

Segundo um estudo da Evans Data Corporation (EDC), a partir de 2019, já existiam 26 milhões de desenvolvedores de software em todo o mundo. É muito importante que o densenvolvedor saiba também entender o lado do negócio, isso é uma habilidade rara.

Dicas para conhecer o Lado sombrio (o lado dos negócios):

Economize tempo: Mesmo que você gaste dezenas de horas planejando antes de começar a trabalhar em uma funcionalidade específica, você sempre descobrirá novas implicações e casos extremos que afetam suas implementações. Quanto melhor você entender o negócio, melhor será para resolver esses problemas. Quando você encontra essa exceção á regra, é mais provável que você já saiba a resposta e assim evite ter que agenda uma reunião com o especialista para encontrar uma solução.

Evite código complexo: Sempre queremos criar o código mais abstrato, flexível, extensível e reutilizável possível. Queremos tanto que ás vezes desenvolvemos uma aplicação excessivamente complexa. Essas implementações nunca serão estendidas ou reutilizadas, gerando um cemitério de códigos. Há certas coisas que nunca serão estendidas, porque esse simplesmente não é o foco da aplicação. Quando você possui experiência de negócio, você está em uma posição muito melhor para determinar qual parte da base de código precisa de mais atenção do que outras.

Priorize melhor: Se tivermos um prazo para a próxima semana, a implementação será muito diferente da prevista para amanhã. Essa é apenas a realidade do trabalho. Com um melhor conhecimento de negócios, é mais fácil priorizar as micro-decisões que você precisa tomar ao programar. Você pode prever em que parte é mais importante gastar tempo. Você pode se colocar no lugar do usuário e sentir sua dor. Além disso, quando você souber quais são as funcionalidades de negócio mais criticas, provavelmente escreverá um código de alta qualidade nessa área, o que impedirá assim refatoração futura.

Uma pessoa que sabe programar é poderosa, uma pessoa que sabe programar e sabe como negócios funcionam é imparável.

Elabora uma lista de termos mais comuns usados no seu ambiente de trabalho. Converse com seus colegas para entender suas áreas. Como é o funil de vendas? Quais nichos de marketing estão sendo visados? Quais são as perguntas mais comuns do suporte ao cliente? Qual é a diferença entre o seu produto e o dos concorrentes?

Projetos paralelos​

“Fracasso e invenção são gêmeos inseparáveis. Para inventar você precisa experimentar, e se você sabe com antecedência que isso vai funcionar, então não é um experimento.” — Scott Galloway.

Grandes startups, começaram sendo projetos paralelos. Projetos paralelos podem ser uma tremenda oportunidade para aumentar seu portifólio.

Perguntas a se fazer antes de iniciar um projeto em paralelos: Um projeto significa que você vai precisar renunciar o seu tempo pessoal para trabalhar nele, portanto, a coisa mais importante a se perguntar é: “Eu realmente gosto deste assunto?”

Se a resposta for “não”, há chance de que você não tenha prazer em realizar aquele projeto e deixará ele pela metade. Leva tempo para um projeto paralelo ganhar tração, então a próxima coisa que você deve se perguntar é: “Estou disposto a passar pelo menos cinco anos trabalhando nessa ideia?”

Ter uma ideia é uma coisa, ter a capacidade de executá-la é outra, portanto, você deve se perguntar: “Posso executar essa ideia complemente sozinho?” Se a reposta for “não”, considere aprender uma nova habilidade ou convidar um amigo para preencher as lacunas.

Dizer “sim” para uma ideia significa dizer “não” a várias outras ideias, então pergunte a si mesmo: “Essa ideia em particular é melhor do que outras que eu tive no passado? Existe alguma outra ideia que poderia usar melhor o meu tempo?”

Entender para quem você está construindo essa solução é vital. Se você não conhece seu público, é improvável que você entenda as necessidades desse público, então pergunte a si mesmo: “Tenho esse problema pessoalmente ou estou resolvendo para outra pessoa?”

E a última pergunta é: “Por que estou animado com essa ideias agora?” Nos próximos dias, preste atenção aos aplicativos que você mais usa. Falta alguma coisa neles? Você seria capaz de criar uma versão melhor disso? Tenha um bloco de notas dedicado para todas as suas ideias de projetos paralelos e leve as notas para todos os lugares com você.

Quanto estiver pronta, escolha uma dessas ideias e tente. Escute mais, fale menos “Sábios falam poque têm algo a dizer. Tolos porque têm que dizer alguma coisa.” — Platão.

Uma empresa é composta por uma variedade de profissionais. Às vezes, as decisões são tomadas com números e outras com sentimentos.

Uma empresa não é um logotipo, não é um prédio, é simplesmente uma aglomeração de pessoas, se você quiser se tornar eficaz lá, precisará se comunicar bem, mesmo se for introvertido. Um equívoco que muitas pessoas comentem é acreditar que precisamos ouvir para responder, enquanto na realidade, precisamos ouvir para entender.

Todo mundo que você conhece, está travando uma batalha que você não conhece, seja gentil, sempre. Na próxima reunião, escolha praticar suas habilidades de escuta. Em vez de ser o primeiro a dizer algo, espere até que todos compartilhem suas ideias e seja o último a falar.

Isso dará a todos os outros a sensação de serem ouvidos, e você terá o benefício de ouvir as ideias de todos antes de compartilhar suas próprias opiniões.

Especialista vs. Generalista​

“O próxima Bill Gates não criará um sistema operacional. O próximo Larry Page ou Sergey Brin não criará um mecanismo de busca. Se você está copiando essas caras, você não está aprendendo com eles.” — Peter Thiel.

Depois de chegar “no rank” Sênior, surge um novo dilema: que caminho você deve seguir?

Tornar-se um especialista, alguém ciente de todos os detalhes de um determinado assunto?

Tornar-se um generalista, alguém capaz de abordar uma variedade de assuntos diferentes?

A resposta dependerá de uma auto-análise. Você precisará entender em qual caminho você mais se encaixa.

Examine seu dia de trabalho. Examine sua semana de trabalho. Quais são as partes que mais te deixam animado? Que tipo de trabalho você prefere fazer? Examine sua empresa. Examine sua equipe. No que eles estão com mais dificuldades? Existe alguma coisa com a qual você possa ajudar?

Controle suas variáveis​

“A única coisa sobra a qual você às vezes tem controle é a sua perspectiva. Você não tem controle sobre sua situação. Mas você tem a escolha sobre vê-la.” — Chris Pine.

Nós não possuímos controle sobre variáveis que são criadas e alteradas por outras pessoas. Não possuímos controle algum sobre essas variáveis, mas mesmo assim ela nos afeta.

Variáveis que você pode controlar:

Seus pensamentos.

Quem são seus amigos.

O que você come e bebe.

Como você gasta o seu dinheiro.

O que você faz com o seu tempo.

Como você trata seu corpo.

Quanto você aprecia as coisas que você já tem.

Variáveis que você não pode controlar:

O clima.

A economia.

A saúde pública.

Como as pessoas tratam você.

O que as pessoas pensam de você.

O que as pessoas gostam ou não.

O que aconteceu no passado.

Quais são as variáveis com as quais você está preocupado agora? Quantas delas estão fora do seu alcance?

Pare de esperar​

“Sofremos mais frequentemente na imaginação do que na realidade.” — Seneca.

Uma característica presente em quase todos os seres humanos é nunca estarmos satisfeitos com a vida. E não há nada de errado, desejar um futuro melhor é um princípio básico do ser humano. O problema em querer mudar é a palavra “mas”:

“Este país é horrível, preciso me mudar urgente, mas não sei outro idioma.”

“Eu tenho uma ideia incrível, preciso colocar em prática, mas eu não tenho tempo.”

A única coisa que impede você de conseguir algo é você mesmo. Quando você começar a se perguntar como resolver esses problemas (como a falta de tempo por exemplo), verá que por trás de cada desculpa existe uma alternativa.

“E agora que o fim está próximo. E então eu encaro a cortina final. Meu amigo, eu vou dizer isso claramente. Vou expor o meu caso, pois dele eu tenho certeza. Eu vivi uma vida cheia. Eu viajei por toda e qualquer estrada. E mais, muito mais que isso, Eu fiz do meu jeito.” — Frank Sinatra.

Agradeço imensamente ao Zeno Rocha por ter escrito esse livro e ao Felipe Suri pelo resumo.