Forem: A Caverna do Patocórnio

Um reels meu atingiu 1 milhão de visualizações com humor para desenvolvedores

Rodrigo "Pokemaobr" Cardoso — Wed, 08 Jan 2025 19:02:48 +0000

Durante muitos anos eu evitei usar o Instagram como lugar para criar conteúdo de desenvolvimento. Achava (na verdade eu tinha certeza) que a grande parte do conteúdo criado era superficial e só era usado para vender alguma coisa (na maioria das vezes aqueles cursos horríveis que prometem o mundo e não entrega nada para pessoas que estão migrando de área e tentando ser devs, coaches ou coisas similares).

O problema é que a rede social que eu mais interagia para chegar ao público dev e essa galera conhecer o meu trabalho era o Twitter. Tinha uma conta bem massa lá que em algum tempo chegou à 10k seguidores. Cheguei até a hitar com um post contendo um print de um site de zoeira que estavamos desenvolvendo: o que basicamente usa um monte de array para criar possíveis vagas que uma pessoa lendo poderia achar que eram de verdade. Esse post chegou a 5 milhões de views e muitas páginas que kibam conteúdo no twitter e instagram usaram esse print para gerar muito engajamento para elas e a maioria nem créditos deixavam.

Fora esse problema ,simplesmente depois que o Twitter foi vendido cada vez menos meus posts chegavam nas pessoas. Postava sobre várias coisas diferentes, com mais de 10k seguidores e chegavam a 100 - 200 pessoas o que é completamente ridículo., pros meus interesses se passou a ser bem desinteressante a rede social e meio que deixei para lá ter engajamento por lá (mesmo eu pagando o premium e até "monetizando") ainda posto uma ou outra coisa para avisar a galera sobre algo específico, mas não é mais minha rede social principal como foi durante muitos anos.

Durante a pandemia a plataforma que pagou a maioria das minhas contas foi a Twitch. Fazia lives de desenvolvimento, humor e jogos. Tinha um público muito bom, uma galera bem engajada com o conteúdo, o que me gerou uma boa renda durante essa fase difícil. Porém, quando as pessoas voltaram à rotina pré-pandemia, números cairam, a renda caiu 90% em poucos meses e problemas pessoais também me desestabilizaram fazendo com que eu precisasse recriar a rota da minha carreira.

Uma coisa que faço a muito tempo e presencialmente as pessoas gostavam de participar e assistir são os "stand-ups dev". Basicamente é uma palestra humorística para devs que apresento desde 2016 em diversos eventos de tecnologia pelo Brasil, empresas como Superlógica, Totvs, Locaweb, B3, Oracle, Senior Sistemas, Melhor Envio, etc. e também já apresentei nos Estados Unidos e a galera sempre pede mais, riem das mesmas piadas algumas vezes e ficam pedindo para eu voltar na cidade e apresentar mais.

Sendo assim eu tinha que pensar em uma estratégia para atingir mais pessoas e tentar entender se o pessoal realmente gostava disso ou só falavam aleatoriamente. Todas as minhas tentativas de fazer algo no youtube foram frustradas. Inclusive tem vários vídeos com bons índices que simplesmente não tem alcance nenhum, além de que meus canais nem monetizados são até hoje. Bem complicado isso ai (risos).

Mas um evento organizado pela Pachi Parra da comunidade Abacatinhos - video aqui mudou um pouco a minha visão do Instagram para criar conteúdo para devs. Eu tinha ido palestrar sobre curadoria de eventos e como uma pessoa devrel pode melhorar nesses apectos. Porém, especificamente um painel com a mediação da Natália F. da Silva e participação da Laura Grassi (Kibum) Kamila Santos Oliveira e Dan Vitoriano 🌈. A ideia do painel era falar exatamente sobre criação de conteúdo para devs em diversas redes sociais, foi bem massa, indico vocês assistirem. E algumas das falas das pessoas, principalmente da Kibum, realmente fizeram muito sentido para mim. Principalmente sobre Reels (vídeos curtíssimos que eu podia direcionar para algo que queria mostrar e atingir bastante gente, já que era uma funcionalidade mais ou menos nova do Instagram).

Conversei com a Kibum depois de um tempo e decidi fazer um experimento. Postar durante um mês todo dia um reels, ela me deu dica de horários e como ajustar as hashtags, entre outras coisas. Na época (novembro de 2023) eu tinha cerca de 3k seguidores no Instagram. Postei durante algum tempo (acho que 2 ou 3 meses) ininterruptamente um reels todo dia. Com cortes de podcasts que participei como o do Roga DX, e cortes com piadas do stand-up.

E alguns desses cortes acabaram atingindo bastante pessoas. Como foi o caso do corte com a piada de "Não saber sair do VIM". Uma piada que é bem antiga e fazia de vez em quando, no podcast eu fiz e o que tinha de gente aleatória nos comentários do reels. Pessoas defendendo VIM, outras falando mal, outras falando que eu não sabia programar já que não sabia sair do VIM, pessoas a favor do Linux, contra o Windows, etc, etc, etc. Mas que criavam um engajamento absurdo. Outro foi um de más práticas de banco de dados, que eu falo que tem que ser varchar em tudo, menos no CPF, que dai teria que ser number, integer, text, etc.

Comecei de verdade em dezembro de 2023. No meio dessa experiência, em cerca de 1 mes fui para 10k seguidores e em 2 meses fui para 20k. E já tinha ficado difícil ver quem tava seguindo, eram muitas solicitações. Então se você me conhece pessoalmente e me segue lá e eu não sigo de volta. Me pinga com seu @ que a gente ajusta isso rsrs.

Com o tempo eu fui entendendo melhor o algoritmo, entendendo os melhores dias para postar as coisas. Só que... Se você fica uns 2-3 dias sem postar o número de seguidores vai cair. Sei lá pq caramba as pessoas ficam seguindo e desseguindo direto. Então se eu fico 3-4 dias sem postar um reels (mesmo postando stories) eu perco hoje em dia 300-400 seguidores de fato (mesmo ainda tendo novas pessoas dando follow).

E dai foram surgindo umas coisas boas no meio disso. Quando fui em maio para a Campus Party Brasil (Campus Party Day em Teresina-PI) uma galera veio falar comigo falando que conhecia o meu trabalho de ter visto os reels, riam bastante, me seguiam no Instagram e tiravam foto comigo como seu eu fosse alguém, isso foi muito massa. Lembro do Ricardo Queiroz falando: "Cara a gente ia nos colégios e a galera falava que queria ir pra te ver". Uma parada meio surreal.

Coisas similares aconteceram com eventos em outros lugares do país. A dancinha do pokemão também virou marca registrada em alguns eventos, já que viam meus stories dançando em eventos diversos.

A conta continua crescendo. E não pago o meta verified e também nunca fiz tráfego pago por lá. O público em geral é orgânico ou dos grupos que faço parte. Talvez se um dia fizer as coisas cresçam mais rápido e consiga atingir ainda mais gente. Mas é muito doido como as coisas escalaram. Meus reels que atingiam 1000, 2000 views em média depois de meses. Atingindo 50.000 - 100.000 views em 2-3 dias. 2000, 3000 likes, muitos comentários. Stories atingem 1000, 2000 pessoas normalmente, mas em dias bons chega a ter 11000 visualizações. E em um conteúdo que é muito para desenvolvedores e não para um público em geral. Eu me impressiono com onde eu cheguei até hoje.

Infelizmente ainda não vem tanta proposta de parceria e patrocínio. Mas, ainda tem muito chão até chegar onde eu realmente quero. E a ideia é poder fazer o show de stand-up para devs assim como humoristas fazem seus shows solo. E mostrar que temos um público dev que pode fazer as coisas acontecerem. Um dia conseguirei esse objetivo tenho certeza.

E hoje, 1 ano e 1 mês depois do início do experimento estou com 54.200 seguidores lá. E os posts continuam pegando um bom engajamento. Tenho reels com 500k views, 680k, 750k, e a grande maioria tem mais de 100k views. Ou seja, tenho um ótimo alcance lá no Instagram, coisa que eu não acreditei que seria possível. Foram cerca de 285 reels (somente os meus) durante esse período (1 por dia).

Daí, no dia de hoje batemos mais uma meta, ter o primeiro reels com 1 milhão de visualizações. Quase 600 mil contas diferentes visualizaram o reels, 4604h (quase 192 dias) de visualização de um reels de 40 segundos. 90 mil interações. É muito louco o tanto de gente que parece gostar do meu trabalho e de algum jeito foi impactado com ele.

A ideia desse artigo é só mostrar que ainda é possível você atingir pessoas mesmo sem investir dinheiro. Com um bom conteúdo, estratégia e constância, mesmo em plataformas de terceiros você consegue com que bastante pessoas conheçam o seu trabalho e essas pessoas podem ser impactadas pelo que você faz.

Muito obrigado por ter lido até aqui e muito obrigado por fazer parte de alguma maneira do que eu faço. Que mais pessoas possam se divertir com o que eu produzo e que mais pessoas possam ser boas pessoas devs e que a comunidade cresça cada vez mais.

Aprendendo sobre testes de softwares

Victor Castro — Fri, 29 Jul 2022 04:24:03 +0000

Estudo programação desde 2017, mas só em 2020 que tive a necessidade de implementar testes nas aplicações que eu desenvolvo. Já tinha ouvido falar sobre esse assunto antes, mas nunca parei para estudar. Quando comecei a estudar com mais profundidade, tive muita dificuldade de entender alguns conceitos. Nesse artigo vou relatar minhas dificuldades, e dar algumas dicas para quem está estudando sobre testes de software.

O que são e quais os tipos de testes de softwares?

O primeiro passo que eu considero importante entender ao começar a estudar sobre testes, é aprender o que são testes de softwares, para que servem e quais os tipos de testes que existem.
De uma forma resumida os testes de softwares servem para garantir que as funcionalidades que estamos implementando estão funcionando da forma esperada.

Pirâmide de testes

Existem vários tipos de testes de software, irei falar um pouco sobre os três principais tipos baseado na pirâmide de software.

Os testes E2E pretende testar todas as funcionalidades do seu software, indo do frontend até o acesso do banco de dados ou de um sistema externo. Esse tipo de teste é pouco aplicado no dia-a-dia, pois ele tem um custo muito alto e leva muito tempo para executar.
Os testes de integração visam testar partes da sua aplicação, por exemplo, a geração de nota fiscal em um sistema de loja online. O teste de integração ira executar o teste na classe de geração de nota fiscal integradas com outras classes necessárias para executar essa ação. Esse tipo de teste possui um custo e tempo de execução médio, comparados aos testes de E2E você ira implementar esse tipo de teste com mais frequência, mas mesmo assim não será tão frequentemente.
Os testes de unidades, procura testar a menor parte funcional de um sistema, esse tipo de teste, você implementa para testar uma classe ou então uma função, isolada de outras partes do sistema. Esse tipo de teste você ira implementar frequentemente, pois ele possui um baixo custo de implementação e possui uma velocidade muito rápida de execução.

Meus estudos sobre teste de software

Quando comecei no meu estágio em 2020, a pessoa que tava sendo minha mentora, pediu pra eu fazer um curso de cypress. Até aquele momento eu não tinha tido nenhum contato com testes de softwares. Quando comecei a fazer as aulas achei incrível o poder dos testes automatizados, uma das minhas tasks foi implementar testes de interfaces em algumas partes do sistema que a gente desenvolvia.

Com o passar do tempo comecei a escutar sobre TDD e entrou na minha lista de coisas para estudar. Só em 2021 quando comecei em uma nova empresa, que comecei a olhar sobre TDD e procurar materiais para estudos, mas tive dificuldade de entender e saber como implementar. Nessa nova empresa eu escrevia testes de unidade frequentemente nas tarefas que eu trabalhava, mas tinha um pouco de dificuldade de criar um teste do zero. Sempre que ia implementar um teste, pegava como exemplo outros testes que alguém já escreveu no projeto. Eu entendia o conceito de teste, tinha uma noção de como estruturar um teste, mas na hora de programar tinha dificuldade.

Dificuldades em aprender sobre testes

A minha maior dificuldade foi de aprender sobre TDD. O TDD é uma metodologia de desenvolvimento que visa escrever o teste antes de implementar a funcionalidade. Comecei a procurar materiais sobre TDD. Estudei com livros, cursos, videos, artigos e outras formas. Mas era complicado, parecia que o conceito não entrava na minha cabeça.

Em fevereiro de 2022 comecei a buscar por um novo emprego, e durante as entrevistas quando me perguntavam qual era a maior dificuldade que eu tinha, eu sempre falava que era em escrever os testes de software. Durante a entrevista para a vaga que estou trabalhando atualmente, uma das coisas definida de ser trabalhado quando eu começasse na empresa, era de evoluir minhas habilidades em testes.

Durante meus estudos eu tentava implementar os conceitos de TDD que eu via, nos sistemas que eu estava desenvolvendo, mas sempre acabava preso em duas principais coisas. A primeira era de saber o que testar. Não sabia quais as classes eu devia testar, quais os casos de uso criar para testar uma funcionalidade.

Outro conceito que tinha muita dificuldade de entender era o de mocks. Os mocks servem para simular ações de uma classe, como, por exemplo, o acesso ao banco de dados. Eu não sabia em que momento deveria utilizar o mock.

Superando as dificuldades

Como disse anteriormente, ao entrar na empresa nova, iria evoluir meus conhecimentos em testes de software e assim está sendo. A equipe que estou trabalhando está desenvolvendo projetos do zero, e com isso tive a oportunidade de participar desde a escolha da ferramenta utilizada para escrever os testes e o primeiro teste escrito na aplicação. Mas isso não quer dizer que você precisa entrar em um projeto que está começando, pra poder aprender sobre testes. Um dos conceitos que eu aprendi é que testes bem escritos ajudam muito as pessoas novas que estão entrando no projeto. E esse é um ponto que eu sempre levanto com o meu time quando estamos escrevendo os testes.

Durante esse tempo implementando testes, consegui amenizar as dificuldades que eu tinha ao entrar na empresa. Comecei a entender pra que serviam os mocks e quando utilizar. Uma das coisas que aprendi, foi que uma das dificuldades de utilizar mocks nos sistemas que eu desenvolvia, era pela forma que as classes estavam escritas.

Com o tempo e muita prática consegui a habilidade de formular de maneira mais fácil os casos de uso que devem ser escritos.
Entender quais classes não devem ser testadas. Uma coisa que eu descobri que existe, foram os testes mutantes. Esse tipo de teste pretende testar os seus testes. Nessa thread do twitter que eu criei, explico um pouco sobre eles e materiais que você pode utilizar pra aprender mais sobre eles.

Ao executar os testes mutantes na nossa aplicação, a gente descobriu várias falhas nos testes que escrevemos. Logo foi criado uma task para poder refatorar os testes. E ali eu vi uma oportunidade de aprender mais sobre testes, como precisei refatorar boa parte dos testes e escrever novos casos de uso, consegui aprender muita coisa.

Diferença entre a teoria e a prática

Uma coisa que percebi que dificultou meu aprendizado também, é de tentar implementar na prática tudo aquilo que vi na teoria. A teoria é importante você estudar e te ajuda a resolver muitos problemas, mas no dia-a-dia, você vai adaptar ao que te deixa mais produtivo.

Um exemplo que eu tive foi o de TDD, depois de um tempo que eu percebi que eu não tinha que seguir a risca o TDD para escrever meus testes, o mais importante era entender o conceito e levar o princípio do TDD para a prática.

E isso não fica preso apenas a testes, isso também se aplica a outros conceitos. Se você é uma pessoa iniciante no mundo de desenvolvimento, não se preocupa que com o tempo você vai percebendo isso e aprendendo quando você não deve seguir a risca o que você aprender na teoria.

Material para estudar sobre testes

Nessa seção irei deixar materiais que me ajudaram a aprender sobre testes. Quando eu estava estudando sobre testes, foquei em TDD e testes para backend.

Dois conceitos importantes que eu percebi depois de um tempo que te ajuda a entender melhor sobre testes, é Orientação a Objetos e Padrões de projetos. Vou deixar dois materiais gratuitos sobre esses assuntos.

Curso de Orientação a Objetos (Curso)

Site sobre padrões de projetos (Artigos)

Em relação ao TDD e testes em geral, você vai descobrir que existem muitas ferramentas que variam de linguagem para linguagem. Quando eu estava estudando, na maioria das vezes utilizei Java/Kotlin com Junit. Mas também consumi materiais em outras linguagens/ferramentas, afinal o conceito de TDD seria o mesmo.

Tdd - Desenvolvimento Guiado Por Testes (Livro)

Test-Driven Development (Livro)

TDD – Desenvolvimento de software guiado por testes (Curso)

Aprenda TDD na prática (Artigo)

API em NodeJS com Clean Architecture e TDD (Curso)

Conclusão

Eu ainda não sou um especialista em testes, ainda possuo dificuldades e sempre peço ajuda as pessoas do meu time que tem mais experiência com teste quando fico empacado em algo. Mas durante esses seis últimos meses nessa nova empresa, consegui perceber a minha evolução com testes e consegui colocar em prática as coisas que eu estava estudando durante um ano.

Resolvi escrever esse artigo pra contar para vocês, sobre a minha experiência e falar pra você que não precisa ficar se culpando ao demorar para entender um conceito. Eu passei mais de um ano estudando sobre teste e só nos últimos meses que consegui entender com mais facilidade e colocar em prática tudo aquilo que eu vi.

Obrigado por ler esse artigo e espero ter te ajudado de alguma forma. Qualquer dúvida que você tiver pode me mandar mensagem lá na DM do meu twitter.

Não esquece de curtir aqui no dev.to e compartilhar esse artigo com outras pessoas que você acha, que pode também gostar de saber como hospedar um site gratuitamente.

Até uma próxima <3

Por que você não acredita na sua capacidade?

Rodrigo "Pokemaobr" Cardoso — Tue, 03 May 2022 17:12:16 +0000

Fala galera, pokemaobr aqui novamente, para trazer mais conteúdo para você que é dev e está começando ou não necessariamente começando nessa área. Sempre trago coisas que vivencio no dia a dia ou que a galera solicita na live. O artigo de hoje foi solicitado por 303n0 e iremos falar de uma maneira diferenciada de síndrome do impostor.

Mas pokemão, todo mundo fala sobre isso toda hora, já to de paciência esgotada desse tema. Acredite em mim, falarei de modo diferenciado. Além disso, o tema tem que ser discutido, porque todo dia o que mais vejo entre as pessoas que sigo no twitter são pessoas que tem uma capacidade tremenda, já desenvolveram grandes projetos, participam de grandes iniciativas e ainda sim duvidam hora ou outra da sua capacidade. Eu me incluo nisso de vez em quando.

Antes de entrarmos, gostaria de lembrar que esse conteúdo é financiado através do nosso apoia.se/pokemaobr, então, se você curtir o conteúdo e quiser nos ajudar financeiramente, pode enviar qualquer valor através da plataforma. Gostaria de agradecer a todas as pessoas que estão contribuindo.

A primeira coisa que posso afirmar para vocês.

Quem é ruim de verdade não sente síndrome do impostor
BR,pokemão.

A pessoa é a impostora mesmo, e ela tem que criar situações onde é melhor que as outras, tem que ter uma lábia absurda para vender algo que não é, aproveitar do trabalho de outras pessoas para crescer, desmerecer o trabalho de outras, enganar, enrolar, fingir e muito mais. Infelizmente temos muitas pessoas assim no nosso meio. A parte boa é que nunca veremos uma palestra sobre síndrome de impostor desse tipo de pessoa.

Quando nos vendem que a área de tecnologia é uma coisa maravilhosa, onde o dinheiro vem fácil e em pouco tempo, onde cursos de uma semana são suficientes para você entrar na área, onde viramos sênior em dois anos e coisas aleatórias desse tipo. Esquecem de falar o quanto trabalhar na área mexe com nosso psicológico.

O mundo é imediatista e quando não conseguimos “performar imediatisticamente” nos cobramos e achamos que somos menos do que o “mercado precisa”. Não podemos passar mal, não estar em um dia bom, ter problemas pessoais, cuidar de nossos entes queridos em uma fase difícil, que isso potencializa, quem sofre com a síndrome do impostor, a sensação de incapacidade e de não estar “suprindo as expectativas”.

Uma coisa que eu acabo fazendo sempre que tenho essa sensação, é analisar o que já fiz, mesmo que em uma área nada a ver, que se assemelha com o que estou passando no momento. Lembro que quando entrei no iMasters, dois dias após o meu segundo evento eu tive apendicite, operei e fiquei duas semanas sem trabalhar, em alguns momentos me senti mal de não estar na ativa. E estar “sendo bancado sem fazer nada”. Porém, se eu morresse, não haveria outra pessoa com exatamente as mesmas habilidades que eu tinha naquele momento para realizar os trabalhos que viriam a seguir.

Pensando nesse caso, eu preferi me cuidar e esperar passar o tempo de “resguardo” e dar o meu melhor no momento em que estivesse bem física e psicologicamente. O que me rendeu muitos eventos, muitas boas lembranças e conhecer muitas pessoas da comunidade de desenvolvimento.

Nós costumamos nos comparar demais sabe, com pessoas que muitas vezes estão na caminhada a muito mais tempo que a gente, que passaram por muito perrengue para estar onde está, que sofreram bastante com tudo que já passaram e que até se assemelha com o que estamos passando. Essas pessoas já passaram pelo o que a gente passa, e talvez por isso já estejam calejadas com algumas coisas e por isso parecem “performar mais”.

Mas porque não nos comparamos com aquela pessoa sênior de dois anos? Que não tem experiência nenhuma, mas acha que sabe de tudo? Que não sabe a diferença entre open-source e freeware, e mesmo assim acredita que está no lugar onde deveria estar. Que não entrega nada, mas se vende como se estivesse fazendo de tudo pela empresa? Ainda posta no linkedIN que marcou entrevista num domingo de feriado e nenhuma pessoa candidata compareceu…

Temos que nos inspirar em quem está na nossa frente, não nos cobrarmos para sermos exatamente iguais a essas pessoas. Entender que é parte do nosso caminho crescer, mas que temos nossos limites. Entender que somos seres humanos e com isso também sofremos as limitações da nossa carne. Seja em questão de saúde, seja em questão do que sabemos até o momento, seja porque estamos passando por uma fase complicada na nossa vida pessoal.

Você não acredita na sua capacidade por que se cobra demais, por que consome muitas redes sociais e acaba achando que o que está no feed reflete a realidade. Porque as pessoas não vão se vangloriar com os tombos que tomam. Mas você deveria. Os tombos são parte do que nos coloca para a frente, são parte do que você precisa para crescer.

Todo mundo tem horas boas e horas ruins, fases boas e fases ruins, tem dias que parece que era melhor nem ter acordado. Mas isso não te faz menos do que você é. A galera valoriza ( inclusive a gente ) aqueles coaches que falam um monte de groselha sem fundamentos. Por que não podemos acreditar com a pessoa com quem a gente dorme e acorda todos os dias? Que sabemos as qualidades e defeitos ( muitas vezes não aceitamos ).

Se não está bem, está tudo bem. Não se force para fazer algo que não está realmente no melhor momento para fazer. Obviamente que temos nossas "obrigações" e em muitos casos temos que fazer o que não queremos. Mas, se algo não te faz bem recorrentemente, talvez seja a hora de fazer algo que te deixa mais a vontade de fazer.

Você é capaz de muito. Relembre o quanto você evoluía com o passar da sua infância. Quando fez algumas coisas que hoje você acredita serem básicas pela primeira vez. Muitas vezes apenas olhando como era feito anteriormente. Relembre o quanto você estudou, o quanto você se dedicou, o quanto você batalhou para estar onde está.

E se for para se comparar. Se compare contigo de 5 anos atrás. De 10 anos atrás. Com certeza hoje em dia você está em um lugar muito melhor, ou pelo menos com muito mais experiência que você tinha naquela época. Só podemos nos comparar com alguém que tem a mesma caminhada que a gente, ou seja, nós mesmos.

E pare de chorar nas redes sociais. Fale sobre isso com pessoas que você realmente confia. Quando emanamos energias negativas recebemos mais do que emanamos. Tem pessoas ( as impostoras ) que só querem nos ver sofrendo e agradecem demais quando olham nosso feed e vê que não estamos bem, não dê esse gosto para elas.

Ah e faça terapia. Nada como falar sobre o que estamos sentindo com profissionais de verdade e não com vídeos de youtube de auto ajuda que prometem que você terá a cura dos seus problemas psicológicos. Fale com alguém que estudou de fato sobre isso. Quer uma indicação de psicologa? A Lola é sensacional!

Inclusive se quiser ignorar tudo que eu falei aqui é uma boa :)

Desejo que tenha curtido esse artigo. Caso tenha alguma dúvida pode entrar em contato comigo no contato@pokemaobr.dev ou na minha live: https://twitch.tv/pokemaobr ou no twitter: https://twitter.com/pokemaobr !

Você também pode contribuir monetariamente para que eu possa criar mais conteúdos gratuitos para devs no nosso apoia.se

Deixa aqui o seu comentário sobre o que foi escrito. Obrigado de coração e até a próxima.

Por que as empresas não querer treinar junior/sandy ?

Rodrigo "Pokemaobr" Cardoso — Tue, 12 Apr 2022 18:13:19 +0000

Fala galera, beleza? Pokemaobr aqui novamente, depois de alguns tempos sem escrever para o dev.to. Tenho alguns outros projetos que estou envolvido e acabei dedicando um pouco mais de tempo lá nessas últimas semanas. Mas, agora estamos de volta e vamos ao que interessa.

Durante discussões que acontecem na minha live alguns pontos são levantados e um dos últimos tópicos foi por que as empresas em geral preferem contratar pessoas de nível pleno e não pessoas junior/sandy. Vou tentar dar a minha visão sobre o assunto, usando de maneira racional os motivos, que em geral já ouvi de muita gente que é high level em empresas. Alguns pontos concordo e outros discordo, porém, a ideia aqui é exatamente mostrar os pontos e não tretar em cima deles.

O primeiro ponto a ser levantado é a disponibilidade para fazer esse tipo de coisa. Em geral empresas pequenas não possuem grandes equipes de desenvolvimento, temos algumas pessoas que acabam levando todos os sistemas nas costas e devido à alta demanda de solicitações as pessoas acabam sobrecarregadas.

Principalmente nos últimos tempos pessoas juniores precisam de mais tempo e dedicação para aprenderem. Sinceramente a qualidade do ensino de devs ultimamente tem deixado muito a desejar, esses formatos prontos de vire dev e ganhe R$5000 em 6 meses é uma receita para o fracasso. Onde as pessoas saem apenas sabendo copiar e colar código, simular templates, mas sem entender o mínimo de lógica ou do que estão fazendo.

Sendo assim, uma equipe (às vezes euquipe) sobrecarregada não conseguiria dar conta de além de resolver os problemas do dia a dia dar uma formação adequada para as pessoas juniores que estão entrando. O que pioraria e muito a situação da pessoa júnior/sandy que ficaria sem entender nada no meio do negócio pegando fogo.

Supondo salários de acordo com alguns mercados, como R$2.000,00 para uma pessoa de nível junior e R$4.000,00 para uma pessoa de nível pleno. É muito mais “seguro” para quem emprega contratar alguém de nível pleno.

Matematicamente falando é mais barato contratar pessoas de nível pleno que pessoas de nível júnior. Se a gente for levar em consideração o tempo onboarding, treinamento e entrega de funcionalidades e qualidade de código, é muito mais barato contratar uma pessoa de nível pleno.

Uma empresa geralmente vai demorar um pouco mais para contratar uma pessoa de nível pleno. Porém, de acordo com o currículo da pessoa, ela pode entender quanto tempo essa pessoa passou em empresas anteriores e tentar estipular um tempo que essa pessoa ficará na empresa, evitando assim pessoas que trocam de emprego em períodos curtos. O que não é possível prever com alguém que ainda não teve nenhuma experiência na área.

E essa realmente é a maior preocupação de quem contrata. Gastar dinheiro e tempo para formar devs iniciantes que depois de alguns meses mudam de emprego para ganhar R$100,00 ou R$200,00 a mais, as vezes em ambientes muito mais tóxicos que a empresa que ajudou na formação dessa pessoa dev.

Hoje em dia uma grande motivação para as pessoas entrarem para a área de TI é a questão financeira, e as pessoas acabam não pensando muito na hora de fazer as escolhas para os próximos trabalhos. As pessoas recrutadoras dão mais prioridade para contratar pessoas que já estão trabalhando. Enquanto isso quem está trabalhando não tem muito apego ao trabalho ( na verdade nem falo que deveriam ter ), porém essa falta de apego faz com que algumas empresas tenham medo real de investir na formação de devs.

Por outro lado temos pequenas empresas que contratam juniores com incubencias de devs pleno. As pessoas ganham um salário de junior e atuam sustentando sistemas como se tivessem experiência muito maior do que possuem. Isso é muito comum em empresas cuja área de atuação não é necessariamente TI, e sim os sistemas dão suporte ao negócio principal da empresa.

Por outro lado, temos as grandes empresas que realmente precisam investir na formação de novas pessoas devs. Elas possuem grandes equipes e precisam perpetuar o seu legado de forma mais escalável, e para isso possuem dinheiro, pessoas para treinar novas equipes e tempo para fazer isso sem se preocupar das pessoas saírem da empresa em pouco tempo.

É por isso que ultimamente temos visto cada vez mais grandes empresas investindo em bootcamps ou sistemas de formação de novas pessoas devs. Pessoas iniciantes em desenvolvimento são mais maleáveis a se adaptar a estilos gerenciais às vezes mais rígidos, o que as pessoas um pouco mais seniores achariam mais difíceis essas adaptações. E empresas muito grandes possuem em geral muita burocracia gerencial, o que de vez em quando desagrada quem tem mais experiência.

Além disso, existe uma outra preocupação que é exatamente a de não renovar o mercado. Se não houver formação de novas pessoas devs para o mercado não terá mão de obra para trabalhar nessas grandes empresas, consequentemente o crescimento e o lucro delas poderia estar prejudicado nos próximos anos.

A ideia desse artigo como falei anteriormente não é dizer quem está certo ou não. Mas sim, fazer você refletir sobre a importância das empresas que abrem vagas para juniores. E você as vezes repensar a questão de mudar de emprego por causa de R$100,00 ou R$200,00 sendo que você ainda está em fase de aprendizagem. Não que eu ache que você não deva mudar de emprego. Só realmente pense se você vai para ter uma experiência nova, ou apenas por motivos financeiros, pensando no curto prazo.

Desejo que tenham gostado e gostaria de solicitar que caso você tenha algum outro ponto que não falei aqui possa adicionar!

Você também pode contribuir monetariamente para que eu possa criar mais conteúdos gratuitos para devs no nosso apoia.se

Deixa aqui o seu comentário sobre o que foi escrito. Obrigado de coração e até a próxima.

Publicando site no Github Pages

Victor Castro — Sat, 19 Feb 2022 22:18:30 +0000

Iniciando

Quando estava iniciando em desenvolvimento web, escutava muito sobre a criação de um portfólio para mostrar meus conhecimentos, mas na época não tinha a mínima ideia de como colocar meus projetos online para que outras pessoas pudessem ver. Depois de um tempo eu descobri que eu precisava colocar o meu projeto em um servidor para que outras pessoas pudessem acessar, mas daí vinha o problema de não ter grana para poder contratar algum desses serviços. Mas graças a comunidade eu descobri o Github Pages.

O que é o Github Pages?

O Github Pages é uma funcionalidade disponibilizada pelo github para poder hospedar projetos web de uma forma gratuita. No GH Pages você consegue hospedar apenas projetos com tecnologias de frontend, não é possível utilizar para hospedar seus projetos utilizando alguma tecnologia server side como, por exemplo, PHP, Node.js ou Ruby.

Hospedando o seu primeiro site

O objetivo desse artigo não é explicar do zero Git e Github, então é importante você ter o conhecimento básico sobre essas duas ferramentas e possuir uma conta no Github. Se você não tiver esse conhecimento básico, pode dar uma olhada nesse tutorial da WoMakersCode.

O primeiro passo é criar um novo repositório no github. Para isso, na sua página inicial do github você pode clicar em criar um novo repositório:

Configure as informações do seu repo e clique em salvar:

Subindo projeto para o github

Após criar o seu repositório, o próximo passo é subir o seu projeto para o github. Para fazer isso, acesse pela linha de comando o diretório do projeto que você quer hospedar. No meu caso, irei utilizar um site simples para fazer esse tutorial.

Iremos inicializar um repositório git com o seguinte comando:

git init

Adicionar os arquivos do seu projeto para commit utilizando:

git add .

Adicionar uma mensagem de commit com o comando:

git commit -m "Subindo o nosso site"

Sincronizar o nosso repositório local com o remoto utilizando o comando:

git remote add origin git@github.com:KastroWalker/github-pages-tutorial.git

Importante configurar conforme as informações do seu repositório.

Subir os arquivos para a branch main do nosso repositório remoto.

git push -u origin main

Utilizamos '-u origin main', pois, esse é o nosso primeiro commit para a nossa branch main remota, e nesse momento é que estamos configurando a nossa main local com a branch main remota.

Você pode ver nesse gif todos os passos acima que eu utilizei para subir o projeto para o Github:

Configurando github pages

Agora é a hora de configurar o nosso repositório para funcionar no Github Pages, para isso precisamos acessar as configurações do nosso repositório:

Iremos agora acessar a parte de configurações do github pages acessando a seção pages:

Precisamos configurar a branch com o código que vai ficar rodando no nosso site. Para isso iremos clicar no select na parte de source e escolher a branch main.

Depois é só clicar no botão de salvar.

Irá aparecer uma mensagem avisando que o seu site está pronto para ser publicado. Após alguns minutos você já vai conseguir acessar o seu site. No meu caso só demorou 1 minuto.

Quando o seu site estiver hospedado, irá aparecer essa mensagem nas configurações de pages.

Pronto, agora você já tem o seu site hospedado gratuitamente no github pages.

Configurando domínio personalizado

Provavelmente você deve estar estranhado por estar aparecendo 'kastro.dev' na minha URI, e na sua tem o nick do seu github seguido de github.io, por exemplo, 'kastrowalker.github.io' isso acontece, pois, configurei um DNS para o meu domínio do github, por padrão o github te disponibiliza um domínio com o seu nick.

Caso você tenha um domínio você consegue configurar ele no github pages, para fazer isso é só ir novamente na parte de configurações do github pages e no final vai ter uma seção para adicionar o link do seu domínio, e clicar em salvar.

Você também irá configurar no serviço do seu domínio para funcionar com o github, mas isso muda de serviço para serviço, então seria inviável abordar nesse tutorial. Contudo, basta procurar no google "como configurar domínio do servidor {insira aqui o nome do seu servidor de domínio} no github pages" que, provavelmente, você vai encontrar um tutorial ensinado a configurar essa parte.

Se você quiser criar um site para ser seu portfólio e ficar com a URI apenas <seu nick do github>.github.io é só criar o repositório com o nome do seu domínio, por exemplo, kastrowalker.github.io.

Conclusão

Agora você já sabe como hospedar os seus projetos web gratuitamente.
Uma dica que tenho, para você que está iniciando no mundo de desenvolvimento web, é que coloque os seus projetos de estudos hospedados no github pages, essa é uma forma de mostrar para outras pessoas as coisas que você sabe fazer.

Caso queira ver o site usado nesse tutorial, você consegue acessando esse link.

Obrigado por ler esse artigo e espero ter te ajudado de alguma forma. Qualquer dúvida que você tiver pode me mandar mensagem lá na DM do meu twitter.

Não esquece de curtir aqui no dev.to e compartilhar esse artigo com outras pessoas que você acha, que pode também gostar de saber como hospedar um site gratuitamente.

Até uma próxima <3

Os primeiros passos para sua vaga em desenvolvimento

Rodrigo "Pokemaobr" Cardoso — Wed, 16 Feb 2022 04:44:52 +0000

Fala pessoal, belezinha? Aqui é o pokemão com mais um artigo para falar um pouco sobre o começo de carreira para uma pessoa dev. Sei que o título ficou bem bosta, mas vou explicar um pouco sobre o que quero falar com vocês aqui. Iremos falar um pouco sobre os motivos de se candidatar a uma vaga, currículo, skills e outros assuntos para você dar match naquela vaga xow em desenvolvimento. Se você não viu meus outros artigos sobre o tema, clica aqui :) e se curtir o artigo deixa aquele coração, unicórnio, manda pra vó, pro menino que está aí em todo lugar, pra amiga, pro inimigo, manda pra todo mundo. E se você quer ajudar monetariamente com qualquer valor para o pokemão continuar produzindo esse tipo de conteúdo fortalece no nosso apoia.se valeu de coração.

Mesmo que na maioria das vezes eu esteja tendo como foco o público mais junior e sandy, pessoas em diversos níveis de senioridade sempre podem pegar algum insight e adaptar a sua realidade. Também não levem tudo que eu falar a ferro e fogo, a maioria das coisas que eu falo são de experiências minhas ou de pessoas próximas que aplicaram e tiveram sucesso na sua inserção no mercado de TI. Dito isso, bora pro conteúdo.

Assim que começamos a pensar em conseguir um emprego na área de desenvolvimento muitas coisas passam na nossa cabeça (ah pokemão, isso é óbvio né? Descobriu o teletransporte…), e a primeira coisa que queremos fazer é nos comparar a outras pessoas para entender qual o nosso nível de conhecimento em cada tecnologia. Inclusive tem uma galera que faz um negócio que ao meu ver não tem o menor sentido que é colocar porcentagem de skills em cada tecnologia. Por exemplo: 60% HTML, 80% JS, 35% CSS. Na boa? Nem eu, nem as pessoas recrutadoras e provavelmente nem você tem idéia do que quer dizer isso. Uma pessoa 60% HTML seria alguém que não sabe usar ? Uma pessoa 80% JS é aquela que só faz tudo em JS puro e não usa frameworks? Uma pessoa 35% CSS é aquela que não consegue desenvolver responsivo? E como eu vou saber qual a visão de 2 pessoas com 50% de HTML? De onde o pessoal tirou isso? Pode até ser uma parada lúdica, mas que no fundo no fundo não serve de nada.

Uma coisa importante antes de se aplicar a uma vaga, que realmente é algo que não tem nada a ver com a stack que a empresa utiliza ou algo do tipo. Conheça minimamente o negócio da empresa, veja se o que fazem faz algum sentido com o que você quer fazer parte. Entre no site, conheça os produtos, veja se tem alguma ligação com alguém que trabalhe lá para perguntar do ambiente, etc; Em alguns casos já vi pessoas que não podiam colocar a empresa em que trabalhavam no currículo ou porque o negócio que a empresa desenvolvia não ia com os princípios da pessoa dev, ou porque o ambiente era tão tóxico que a pessoa não deseja que nem seus inimigos trabalhem lá, ou por outros motivos. Não estou falando que por fora a empresa possa ter uma ótima índole e só depois de você entrar você descobre como é realmente, mas, se você puder evitar que esse tipo de coisa aconteça antes. Te poupa de alguns contratempos e desgastes desnecessários. Inclusive saber sobre o negócio da empresa, os propósitos, valores e demais características podem ajudar muito na sua entrevista (iremos falar sobre isso em um artigo posterior). Mas, tem uma thread no twitter muito legal do Sérgio Lopes (CTO da Alura) onde ele fala sobre a questão de contratação de iniciantes na visão da empresa.

Vocês lembram que eu gosto de falar do que chamo de axiomas né? São afirmações que são verdadeiras e eu não tenho que provar o porque o são. Então, se você está começando na área de desenvolvimento: Você não sabe o seu nível de conhecimento em cada tecnologia. Se você não tem experiência, não tem como você saber o seu nível. E o que isso quer dizer? Se você ver uma vaga para nível júnior/sandy que pede conhecimento intermediário em API. E você sabe o que é uma API. VOCÊ APLICA PARA ESSA VAGA! Quem tem que avaliar o seu nível de conhecimento em alguma tecnologia é a empresa que está fazendo o processo e não você, afinal, você não sabe fazer isso!

É muito comum o temor por não ser compatível com 100% do que pedem em uma vaga. Esse é um dos motivos que eu falo da importância da curadoria das vagas. Vagas com melhor descrição poupam de ter um monte de descrições aleatórias e pedidos de skills que não fazem sentido nenhum, o que faz com que você tenha menos medo de aplicar devido à uma inconsistência com os requisitos. Muitas vagas não fazem nenhum sentido e nada mais são que um apunhado de termos técnicos que as vezes nem ligação tem, que alguém de TI falou por cima para o pessoal de RH. Inclusive uso algumas dessas vagas arrombadas nos meus stand-ups humorísticos de desenvolvimento. Vagas que pedem tecnologias que nem usamos mais, coisas que são mais que ultrapassadas, conhecimentos “jedi” em tecnologias que possuem menos de 2 anos, entre outros tantos. Mas a questão aqui do axioma é isso que eu falei acima, não deixe de aplicar para uma vaga porque você não tem todos os pré-requisitos para ela. Aplique se você tiver algum deles. Parta do princípio que se a vaga é para nível júnior/sandy a vaga é para você aprender e você vai pegar o feeling necessário para se desenvolver na vaga com o passar do tempo.

(Exemplo de vaga arrombada)

Eu penso assim, em uma vaga junior/sandy se você tem 3 das skills que pedem na descrição técnica está ótimo. Como falei antes: quem tem que avaliar se você pode ou não preencher a vaga é a empresa. as vezes perdemos oportunidade por medo de tentar. Tente, o pior que pode acontecer é nada, e não fazendo nada, esse é o mesmo resultado, mas sem chance de ser diferente. Na melhor das hipóteses você vai entrar para a vaga e aprender um monte de skill que você não possui. Falando nisso, lembrei de uma vaga que eu queria muito na época que pedia conhecimentos em frameworks e na época, eu era pleno, eu nem usava framework nenhum, sabia quais eram os melhores da minha stack e tudo mais, mas não tinha implementado nada satisfatório com eles. Mesmo assim eu apliquei para a vaga, fui bem na entrevista, entrei, estudei a documentação dos frameworks em questão e foi bem tranquilo começar à usá-los.

Outro fenômeno que ocorre bastante na área de TI é: pessoas recrutadoras querem te contratar sempre quando você está em um emprego. Por isso falo tanto de você entrar na área, talvez não do jeito que você deseja 100%, naquela empresa dos sonhos, ganhando um salário de 20k (sei lá onde uma pessoa que começa ou até mesmo a grande maioria da galera sênior que eu conheço ganha isso por mês, mas se tem coach falando que isso é true, eu acredito… #sqn), tendo toda a atenção das pessoas mais seniores te apoiando sempre, etc. Infelizmente o mercado é um reflexo do nosso país e das relações que temos com outras pessoas. Então, entre na área e depois você vai poder escolher até as melhores oportunidades, enquanto isso, ganhe experiência.

Uma dica que dou para quem está começando também é: não tenha preconceito com stacks. Você está começando agora, não sabe muita coisa na área, não se apegue com linguagem ou tecnologia porque ouviu alguém falar que uma outra é ruim, se você nunca colocou algo em produção naquela tecnologia não pode falar que é ruim. Todas as tecnologias tem um motivo para serem do jeito que são e tem uma utilidade. Sendo assim: se você estudou React, mas viu uma vaga legal com Angular: aplica. Se você está estudando C#, mas viu uma vaga legal em Java: aplica. Quanto mais entrevistas você fizer, mais experiência você vai adquirir em como se comportar, o que falar, o que pode ser abordado e você irá se preparar melhor para as próximas. Deixa que essas tretas se resumam ao twitter. No momento você quer entrar na área, então, aumente as suas chances de isso acontecer e de quebra aprender mais coisas novas.

Saiba se vender! Como eu disse anteriormente: não devemos nos comparar com as pessoas: cada pessoa tem seu caminho, suas dificuldades, suas competências e suas limitações. E você sabe bem das suas. E, você também sabe das suas qualidades. Saiba colocar isso na sua candidatura. Se quando no cadastro para aquela vaga tiver um campo para você falar um pouco de você! Fale das qualidades que as outras pessoas enxergam em você. Existem pessoas sensacionais que deixam de ocupar vagas legais por não saber potencializar suas qualidades. Existem pessoas péssimas em ótimos cargos porque elas sabem fazer isso. Então, se você é sensacional, com certeza sabendo se valorizar você vai conseguir alcançar o que você deseja! Estou falando de se valorizar, tá? Não inventar historinhas que não existem para conseguir as coisas a qualquer custo.

Para facilitar o trabalho das pessoas recrutadoras como já dito em artigos anteriores é bem legal você ter um linkedin atualizado e um github com projetos legais, se você é dev (inclusive fiz um artigo sobre isso). Mas sempre acho massa também ter um currículo nos moldes padrão, já que facilitam muito para importar em sites de recrutamento. O currículo deve ser simples, com poucas páginas, focar nas suas experiências acadêmicas ou de estudos, nas skills que você está estudando, em experiências anteriores de trabalho, caso houver (aqui você pode começar a pensar o que de bom você aprendeu nas experiências anteriores caso não seja na área de TI para fazer um link com o que isso pode te ajudar na área), caso não tenha experiência em empregos é legal você colocar um pouco dos projetos que desenvolveu durante seus estudos e um pouco de como foi o processo de desenvolvimento, que tecnologias usou, etc; caso você tenha algum nível de inglês também é bom colocar, cursos livres, suas principais participações em eventos, etc. Uma coisa muito importante sobre currículos é que ele possa ser lido por quaisquer pessoas navegando em “tabs”. Muitas vezes a gente entrega currículos com formatação exagerada, porém com nenhuma usabilidade de leitura para pessoas com deficiência visual. Todas as pessoas têm que conseguir ter um fluxo de leitura legal para que seu currículo impacte mais gente. Além de lembrar que para cada vaga o ideal no currículo é você colocar um objetivo que tenha a ver com aquela vaga em específica. Vou deixar como modelo o meu currículo aqui, pode ajudar alguém talvez.

Para o artigo não ficar muito longo, iremos parar por aqui. No mais: se arrisque. Aplique para o maior número de vagas que faça sentido para você. Faça o maior número de entrevistas que conseguir. Aplique mesmo que a vaga peça mais requisitos que você tem. Aplique, mesmo que a vaga seja para uma linguagem diferente da que você tenha estudado na maior parte do tempo. O não você já tem, vamos ir em busca do sim.

Desejo que esse artigo te ajude de alguma maneira. E, se você quiser mais dicas para buscar o seu primeiro emprego, dicas para a hora da entrevista e coisas do tipo, comenta aí o que você quer para eu poder criar mais conteúdo nesse sentido. Não esqueça de curtir, mandar um unicórnio e compartilhar o artigo!

Um grande abraço para você e vamos fortalecer a bolha dev!

Rodrigo “Pokemaobr” Cardoso

Caso você queira me ajudar a continuar criando conteúdo para devs, me ajude no apoia.se, me siga no twitter e/ou assista minhas lives na twitch.

Sou iniciante em desenvolvimento, que projetos devo fazer no meu github?

Rodrigo "Pokemaobr" Cardoso — Tue, 08 Feb 2022 05:17:59 +0000

Fala pessoal, tudo bom com vocês? Pokemão de volta aqui com mais um tema para iniciantes em desenvolvimento. Se você ainda não leu os outros artigos. Dá uma olhada lá que tem muito conteúdo legal para você que está começando ou quer entender mais sobre o mundo de desenvolvimento.

O tema de hoje é uma pergunta que também recebo muito nas minhas lives. “Pokemão, estou começando a desenvolver, que projetos é legal eu fazer?”. Obviamente as pessoas vem falar, ah, vi por ai que é legal fazer uma to do list, um clone da interface da empresa tal… Não faça só isso... todo mundo faz... você tem que ser diferente… Quer saber a real? A galera que recruta já tá de paciência esgotada com esses negócios de clone, qualquer curso de uma semana ensina isso e você nada mais faz do que copiar e colar código que você viu em algum lugar e que no fundo você não entende nada do que está fazendo ali. E uma porrada de gente faz a mesma coisa… Como você vai se diferenciar fazendo o mesmo que todas as pessoas?

Vou elucidar vocês com o primeiro projeto que eu realmente finalizei durante meus estudos de desenvolvimento. Era entre 1999 e 2000, a internet discada imperava no ambiente brasileiro (de quem tinha internet né, lembro que demorei alguns anos para ter, pois, onde eu morava - um conjunto da marinha em Brasília só tínhamos ramal e portanto só pude ter internet quando mudou para linha telefônica "real"). Eu tinha um PC até ok para a época, era um Pentium II 166. As pessoas estavam conhecendo ainda o que era mp3 e lembro que demorava um dia para baixar um mp3 kkkk e o pessoal de hoje reclama que demora pra baixar videos rsrs. Dentre os tocadores de mp3 o que imperava com certeza era o winamp, porém, além do meu PC não rodar o winamp decentemente, eu não curtia a interface e não gostava do jeito que o winamp fazia o aleatório entre as músicas. Não tínhamos whatsapp, nem facebook, nem orkut na verdade, no Brasil quase ninguém tinha ouvido falar em Google, o que mandava aqui era o cadê e o bate-papo da UOL. Imagina como era fácil achar conteúdo de programação nessa época, risos, exatamente, não tinha quase nada. E eu gostava de usar o que seria o slack de hoje em dia, o mIRC!

Para quem não sabe o IRC é basicamente um protocolo de comunicação cliente-servidor para desenvolvimento de bate-papo. Por exemplo, o chat da twitch é desenvolvido em cima de um servidor IRC e eu usei meus conhecimentos daquela época para desenvolver o bot da minha live, mas, isso é papo para outro artigo. A questão é que para acessar uma rede IRC em geral a gente usava um client desktop chamado de mIRC. Esse em cima desse cliente a gente podia customizar ou desenvolver funcionalidades usando a linguagem de programação IRC script (com certeza a galera mais velha de internet lembra disso). Como eu passava a maior parte do meu tempo no IRC, nada mais justo que aprender essa linguagem. Lembro que dentro do mIRC tinha uns arquivos helpers .hlp que abrem no windows helper viewer e esses arquivos tinham os conhecimentos sagrados de como desenvolver scripts para o cliente IRC. E num desses estudos eu aprendi como criar GUIs (interfaces visuais para o IRC tipo aquelas janelas show do Delphi), aprendi a manipular arquivos no IRC (ler arquivos nas pastas, listar e acessá-los) e também descobri que era possível tocar mp3 dentro do client.

Bem, vocês lembram o que falei no meu primeiro artigo aqui?: a gente pegava o problema, aprendia as ferramentas e depois resolvia. E foi isso que fiz: eu sabia que gostaria de ter um tocador de mp3 mais leve e mais útil que o winamp. Peguei o que aprendi no IRC e fui criar o The Poke’s Player. Eu lembro que fiquei muito feliz quando consegui terminar o projeto. Não porque um cliente ia usar e tinha pago para ter algo que nunca está do jeito que quer. Mas sim porque o cliente daquele projeto era eu. Aquilo iria resolver um problema que eu tinha, um problema real que eu queria resolver. E isso me ensinou muito mais sobre o que eu conseguia resolver com programação, me fez ter muito mais vontade de estudar o que precisava para resolver o problema e fez o projeto ter uma qualidade decente, já que eu iria usar aquilo diariamente. Eu sabia exatamente o que eu queria, o que esperar do projeto e o que ele iria entregar para mim, afinal, o problema era meu, literalmente.

Me diz quantas pessoas você conhece que o primeiro projeto foi resolver um problema pessoal? E quantas você conhece que foi fazer um to do list ou clonar uma interface? Qual projeto despendeu mais criatividade? Qual projeto tem mais propósito? Não estou falando que aprender a fazer to do lists ou clonar interfaces é algo ruim, às vezes, é algo bem didático para você ver um resultado imediato, porém, hoje em dia todo mundo faz isso, todo mundo aprende assim. Qual diferencial você vai ter com outras pessoas que fazem a mesma coisa?

Então, a primeira dica de projeto que tenho para você hoje é: resolva algum problema que você tem, seja o seu primeiro cliente. Todo mundo tem pelo menos um problema, e a grande parte desses problemas podem ser resolvidos utilizando programação. Você usa vários apps no seu celular e no seu computador que foram criados da mesma maneira. Alguém tinha um problema e decidiu resolver esse problema, incrivelmente a grande maioria das empresas que você vai aplicar geralmente também nasceram da mesma maneira: para resolver o problema que alguém teve anteriormente.

Cria sei lá: um sistema que manda e-mail pra te acordar, um bot no telegram para mandar foto de bom dia no grupo da família, um sistema para te avisar quando acontecer uma nova treta dev no twitter (ops, ai não vai funcionar, pois, as tretas são sempre as mesmas...)

Aí você fala… “Ah Pokemão, mas eu não tenho nenhum problema…”, primeiramente você não é uma pessoa humana então kkkkkk. Mas tá, se você cismou que não tem problemas, você gosta de alguma coisa então. Faça algum projeto que envolva o que você gosta. Quando eu era menor eu gostava de pokémon (que inusitado né?). Então, criava bots de batalha pokémon no IRC. Fiz um site sobre esse sistema de batalhas. Criei uma pokédex. E outras coisas que envolviam o que eu gostava. Coloca essa cabeça pra viajar! Você vai ajeitar algo legal!

Se ainda assim você vier falar que não gosta de nada “PQP einnnn vamos rever esses conceitos aí” faz o seguinte. Sabe aquela pessoa amiga que descobriu que você está estudando para ser dev e pediu para você consertar a impressora? Ela mesmo, ela tem uma idéia revolucionária que vai fazer todo mundo ficar rico e só está precisando de você para iniciar uma sociedade inacreditável de desenvolvimento. Ou uma dica melhor: entre em algum grupo do facebook de desenvolvimento, espere um post sobre essas ideias maravilhosas e pede pra pessoa contar a ideia rs! Ouça ou leia essa ideia aleatória e tenta codar o que der disso. Com certeza vai ser uma experiência bem aleatória, porém, pode te dar muitas skills em soluções random kkkk. Grandes devs que conheço começaram em agências ou consultorias e basicamente o trampo era desenvolver as coisas mais aleatórias do mundo, repetitivamente e também mandar e-mail marketing :), e-mail marketing não pode faltar.

Agora, se o que você precisa é entender um pouco como funciona o trabalho em equipe dentro do github. Contribua para projetos open source. Todo mundo lembra (inclusive eu) que existem projetos para contribuição durante a hacktoberfest (evento anual para estimular a contribuição ao open source) para ganhar camiseta. Porém, esquecemos tudo que envolve a contribuição para esses projetos. Desde os conceitos mais simples como fork, git clone, git push, git pull. Até os mais maravilhosos conflitos de merge (oh coisa linda). Além do conceito de backlog, priorização, bug reporting e outros com as issues. Revisão de código com os pull requests e muito mais. E ensinamentos não técnicos como a divisão do time, o vai e vem de devs contribuindo (o que simula contratação e desligamento em times), entre outros conceitos que você pode aprender.

Sei que você vai falar “Ah Pokemão, mas não sou bom tecnicamente para contribuir com esses projetos…”, tudo bem, eu entendo. Mas, sabia que você pode contribuir com outras coisas sem ser código propriamente dito? Pode ajudar na tradução, pode ajudar na documentação, pode ajudar criando comentários, comentando nas issues, dando ideias de novas funcionalidades e muitas outras maneiras.

Tem alguns repos e artigos legais com alguns projetos que são de fácil entrada para a contribuição:

https://github.com/backend-br/opensource-br
https://dev.to/womakerscode/hacktoberfest-conheca-os-projetos-open-source-da-womakerscode-2doj
https://jtemporal.com/projetos-brasileiros-para-fazer-pull-requests-nesse-hacktoberfest-2021/
https://ok.org.br/noticia/hacktoberfest-2021-na-okbr-contribua-com-projetos-brasileiros-de-inovacao-civica/

Ou só procure no google por “open source repositórios hacktoberfest” (o hacktoberfest é só pra facilitar achar :) )

Ou contribua para algum projeto que você use durante seus estudos de código.

Bem, por acho que hoje é isso. Desejo que esse artigo tenha ajudado você em alguma coisa, se ajudou deixa seu comentário ai, taca o coração e o unicórnio, salva, manda pra vó e tudo mais. Se eu puder melhorar em alguma coisa avisa ai.

Um grande abraço para você e vamos fortalecer a bolha dev!

Rodrigo “Pokemaobr” Cardoso

Caso você queira me ajudar a continuar criando conteúdo para devs, me ajude no apoia.se, assista minhas lives na twitch e me siga no twitter.

Lugares talvez não triviais para você procurar empregos em desenvolvimento

Rodrigo "Pokemaobr" Cardoso — Tue, 01 Feb 2022 08:08:59 +0000

Fala galera linda do meu coração. Aqui é o pokemão novamente e estamos de volta aqui com mais um artiguinho pra vocês que estão querendo novos ares para sua carreira dev. Seja você junior, sandy, pleno, sênior, jedi, ninja ou qualquer outro nome bosta que inventam para se referenciar a uma pessoa dev.

Como uma área diferenciada, com certeza os modos de procurar empregos em TI é algo também diferenciado. Mostrei no nosso último artigo uma estratégia muito legal, principalmente para iniciantes em desenvolvimento conseguirem filtrar vagas, conhecer pessoas na área e utilizarem da #bolhadev para conquistar o que desejam.

No artigo de hoje irei falar alguns lugares que eu uso para encontrar vagas pra galera que me pede durante as lives e também que já usei anteriormente para conquistar aquela vaguinha xow!
Tenho certeza que alguns você nunca pensou que pudesse usar para isso. Por motivos óbvios não irei citar o LinkedIN e alguns sites tradicionais de vagas :)

Github

Começamos exatamente com o que eu entendo ser o melhor hub de vagas para devs que conheço. Vagas devidamente filtradas (até porque dá um trabalho fazer isso), boas propostas, separadas por tipo de contratação, experiência, stack e principalmente: com requisitos que fazem total sentido para o tipo de vaga.
Bem, para quem não sabe existe no github diversos repositórios de vagas que algumas comunidades mantém, de modo a facilitar às pessoas desenvolvedoras a encontrar vagas que se adequem ao seu perfil, modelo de contratação, stack, entre outras coisas. E, de maneira sensacional cada vaga é… isso mesmo, UMA ISSUE :)
Abaixo deixo uma pequena lista de repositórios com tal proposta, separados por comunidade :)

Front-end Brasil (acho que foi a precursora) - https://github.com/frontendbr/vagas/issues
Back-end Brasil - https://github.com/backend-br/vagas/issues
Brasil-PHP (PHP) - https://github.com/brasil-php/vagas/issues
PHP-dev Brasil (PHP) - https://github.com/phpdevbr/vagas/issues
Cocoa Heads Brasil (iOS) - https://github.com/CocoaHeadsBrasil/vagas/issues
Gommunity (GO) - https://github.com/Gommunity/vagas/issues
AndroidDevBr (Android) - https://github.com/androiddevbr/vagas/issues

Ah pokemão, não achei a minha tecnologia nessa lista… Não falei que eu acho que a front-end Brasil foi a precursora? Estamos no github galerinha, é só a gente ver os fork que tem infinitas :) Temos só 653 forks… https://github.com/frontendbr/vagas/network/members

Uma coisa interessante que eu vejo nesse app de comunicação é que é muito fácil implementar bots para conseguir fazer alguns tipos de coisas nele. (Caso você queira que eu reescreva artigos sobre bots de Telegram me fala aqui :) ). Bem, inclusive alguns dos repositórios que eu citei acima tem integrações onde quando sobe uma nova issue é enviado mensagem para um grupo de Telegram, além de ter uma privacidade maior sobre seus dados telefônicos, o que não temos no nosso tão querido zapzap! Seguem alguns grupos de telegram para vagas de TI.

VagasTIBR - Grupo com mais de 30.000 pessoas e vagas infinitas :) https://t.me/vagastibr
VagasTech - https://t.me/vagas_tech
VagasMundoTI - https://t.me/joinchat/BZz-eRCLlSqFBF47j8GA7g

E tem muitos mais grupos de vagas.

Além do Telegram também temos grupos de Zap. Mas como temos o limite de users, a maioria já atingiu isso, melhor deixar pra lá!

Hipsters.jobs

De sites de vagas em geral, vou citar só o hipsters.jobs exatamente por ser um site que eu buscava por vagas remotas mesmo antes da pandemia. Tem bastante vaga interessante, com requisitos honestos, além do selo de qualidade Alura né? Tenho nem mais o que falar!

Impulso Network

Não temos como falar sobre desenvolvimento sem falar sobre Networking. E a idéia da Impulso é mais ou menos isso. É um pouco de tudo, uma espécie de rede social para devs onde parte do que fazem é conseguir boas pessoas devs para vagas xow demais! Se você não conhece, é massa demais! Cola lá! https://impulso.network/

Eventos DEV

Por que vocês acham que tem tanta empresa que patrocina eventos de desenvolvimento? Sim, para contratar. Então, na próxima oportunidade que você tiver de participar de um evento ONLINE ou presencial de desenvolvimento procure os stands para falar com quem está patrocinando. Tenho 99% de certeza que essas empresas estarão atrás de devs como você! E em geral são empresas legais de se trabalhar e você terá contato direto com outras pessoas devs que também trabalham lá!

Twitter

Bem, não vou me extender muito com twitter, até porque já falei mais extensamente no artigo anterior. Mas, segue https://twitter.com/ViUmaVaga e https://twitter.com/vagasprajr que sempre tem coisa legal.

Tem vagas no Facebook também :)

Galera, desejo de coração que vocês tenham tido insights um pouco diferentes de: procura no LinkedIn e sites de vagas. E, lembrando para vocês: o que faz a diferença na nossa área é o networking, então quanto mais pessoas vocês conhecerem na área, seguirem nas redes sociais e interagirem, mais fácil será encontrar vagas boas para o que você procura!

Se esse artigo te ajudou de alguma maneira. Dá o seu gostei, taca o unicórnio, me segue aqui!. E, se curtiu e quer me ajudar a continuar a criar conteúdo para ajudar devs seja na twitch, aqui ou no youtube. Contribua no nosso apoia.se, você pode ajudar com 1 real! E me siga no twitter :)

Utilizando a bolha dev ao seu favor na busca do seu primeiro emprego!

Rodrigo "Pokemaobr" Cardoso — Sat, 22 Jan 2022 15:51:31 +0000

Ultimamente, cada vez é mais comum pessoas iniciantes em desenvolvimento entrarem nas minhas lives, postarem no twitter, facebook, instagram, linkedin, em blogs ou sites de artigos perguntando sobre como iniciar na área, mais especificamente como conseguir o primeiro emprego na área. Muitas citam bootcamps ou faculdades como caminhos “seguros” para conseguir o primeiro emprego, já que uns “garantem” a empregabilidade no fim do ciclo de estudos, e outras dão a oportunidade de entrar como estagiário, facilitando a entrada na área e posteriormente um crescimento dentro dela, porém, o que eu vejo muito é algumas dessas pessoas às vezes decepcionadas, pois, depois de um período, na maioria das vezes não muito longo, se vêem perdidas, pois, estudaram uma stack (conjunto de linguagens frameworks, bibliotecas e outras ferramentas com o propósito de resolver um tipo de problema específico em desenvolvimento) que até agora não sabem o real motivo do porquê, já que assistiram um vídeo no youtube falando que era a stack mais usada em 2022. E, obviamente que ouviram que TI é a área que mais emprega no momento, que não faltam vagas na área ( o que é verdade e vamos explorar isso mais a frente ), que tem pessoas entrando na área ganhando R$10.000, e outras coisas que fazem a área ser um atrativo para diversos tipos de pessoas.

Isso realmente é uma coisa que me vem preocupando em relação ao desenvolvimento nos dias atuais. Eu não sou parâmetro para nada, mas, quando comecei a programar não existia o tanto de conteúdo sobre desenvolvimento que tem hoje, e talvez eu nunca imaginasse que teria tanto conteúdo como temos, mas, a gente tinha um estilo de aprendizagem diferente. Na época que eu comecei a estudar eu nem imaginava poder ganhar dinheiro com desenvolvimento, eu só achava divertido criar coisas e fazia isso usando código. A gente conhecia primeiro o problema e depois estudávamos como poderíamos resolvê-lo. Então, por exemplo, se eu tivesse que resolver um problema desenvolvendo algo que envolvesse coisas de desktop, a gente iria estudar sobre delphi, java, visual basic ou outra linguagem que pudesse resolver aquele tipo de problema, se eu tivesse que fazer um site, iria estudar HTML, CSS, javascript, PHP, ASP, Flash ou outra coisa que resolvesse soluções web. Hoje em dia, muitas pessoas saem estudando qualquer coisa sem nenhuma noção do sentido de estar estudando aquilo, só porque viram em algum lugar que era a tecnologia mais quente. Antigamente a gente sabia o problema e escolhia a ferramenta para trabalhar naquele problema. Hoje em dia a gente escolhe uma ferramenta e depois procura os problemas que aquela ferramenta resolve. É tipo aquela da pessoa carpinteira que está com um martelo na mão e sai dando martelada em tudo que se pareça com prego, já que é pra dar martelada que o martelo serve. Dito isso, o primeiro conselho que tenho para você que está começando na área!!! Entenda os problemas que a stack que você está estudando resolve. Isso é muito importante até mesmo para uma primeira entrevista na área, e, embora tudo possa parecer prego em desenvolvimento, nem tudo é.

Sei que você deve estar se perguntando: “Pokemão, você falou um monte de besteira e eu vim aqui para saber como conseguir o meu primeiro emprego”, calma que a gente chega lá! Como premissa irei aceitar que você é uma pessoa que já está estudando desenvolvimento a algum tempo, já fez alguns pequenos projetinhos para treinar e colocou no seu github e está buscando sua primeira vaga no mercado. Caso não tenha feito isso ainda, o faça.

O segundo conselho que tenho para você que está começando na área!!! Não tenha medo de não conhecer muito sobre o que você está estudando, as vagas de sandy/junior quem vai dizer se você tem preparação ou não para a vaga é a empresa para a qual você estiver aplicando para a vaga e não você. Você não sabe ainda nada sobre a área e não sabe validar seus conhecimentos, deixe que a empresa faça isso. Esse tipo de vaga é exatamente para você aprender!

Não discuta comigo agora, mas, a ferramenta que move a bolha dev é o Twitter, tenha isso como uma verdade, como sou matemático, posso dizer que isso é um axioma (algo que não preciso provar para saber que é verdade, é a verdade e aceite como tal), as outras redes sociais são altamente superficiais quando falamos de compartilhamento de conteúdo dev e também da presença das pessoas dev que realmente podem fazer algo para você e até mesmo o lugar onde essas pessoas realmente podem fazer algo para você. Se você quer ser dev e não tem Twitter, mas tem Instagram, Tiktok, Facebook, Linkedin é bom rever as coisas. “Ah pokemão, mas sou low profile!”, beleza, então não tenha nenhuma rede social, mas, isso vai reduzir suas chances de ser encontrada pelas pessoas. Bem, o terceiro conselho que tenho para você que está começando na área!!! Crie um twitter (deixe sua caixa de mensagem aberta para qualquer pessoa poder mandar mensagem pra você). Crie também um LinkedIn (só pra você ter um currículo rápido), e também tenha um currículo nos moldes antigos (ainda pode ser útil). E acho que você já tem um Github, né?

Sabe aquela pessoa que falou lá no vídeo que a stack que ela falou para você escolher era a mais utilizada em 2022? Siga ela no Twitter. Sabe toda aquela galera dev coach que você não para de consumir conteúdo? Siga no Twitter. Sabe aquele primo da sua colega que foi quem te convenceu a largar educação física e ir para a área de TI? Siga no Twitter. Siga quem você puder na área de tecnologia e que tem a ver com o que você está estudando. Siga no Twitter. Sabe esse @pokemaobr que está escrevendo aqui pra você? Siga no Twitter. Siga o perfil @Viumavaga, o @TemVagaPraJunior, a @camelouu,(uma referência em recrutamento dev no Twitter), o o_gabsferreira (que todo mês cria uma lista de vagas) e outros perfis com vagas para quem está começando, algumas vagas legais filtradas aparecem por lá. ( Só não esqueça que com o passar do tempo você vai ter que parar de seguir algumas pessoas para evitar tretas devs, mas, isso é assunto para outro artigo, no começo siga qualquer pessoa e depois você vai filtrando). ---> Tem essa lista aqui um pouco desatualizada, mas, com muita mina sensacional que é dev e ajuda a comunidade e você pode seguir no twitter (vai clicando em mostrar respostas que tem gente pra caramba).

Outro axioma que posso colocar aqui. Diferente de muitas áreas que já atuei e que conheço pessoas que atuam, na área de desenvolvimento a maioria das pessoas estão dispostas a te ajudar sem querer nada em troca, algumas dessas pessoas ajudam somente pelo vislumbre de que isso faz a área crescer e a roda girar, ou, pois foram ajudadas no passado e por isso querem, ou qualquer outro motivo aleatório, por isso é um axioma. Algumas das pessoas que você seguir tem DM aberto (você pode mandar uma mensagem direta para a pessoa clicando no botão no perfil dela), conte a sua história para a pessoa e avise que se a pessoa ver alguma vaga que possa se encaixar com você para que te avise. Algumas pessoas vão te ignorar, mas, a grande maioria vai lembrar e quando receber uma vaga (recebemos vagas diariamente) vai te indicar. O quarto conselho que tenho para você que está começando na área!!! A vaga não vai cair do céu, no começo você tem que ir em busca dela.

Show, agora você já está no radar de algumas pessoas. Como dito lá no começo do artigo, tem realmente muita vaga na área de TI e seu trabalho agora é fazer com que as pessoas tragam essas vagas até você, com uma curadoria muito bem feita, já que em geral quem vai indicar as vagas para você são pessoas que trabalham nas empresas, o que facilita na hora de entrar (recomendações são sempre bem vindas e algumas pessoas até ganham por isso :) ) . Vamos então utilizar da força da bolha dev para isso.

Prepare então uma thread no twitter ( uma sequência de tweets onde um é resposta do outro fazendo uma linha de raciocínio ) onde você vai se apresentar, falar um pouco dos motivos que fizeram você querer entrar para a área de TI, falar sobre a stack que você tem estudado e o que você fez (cursos, bootcamps, faculdades e outras coisas relevantes), o que você procura e no final coloque seu linkedIn, github e algum e-mail ou outro contato de rede social, em formato de texto, não invente de colocar imagens. Poste em um dia de semana em horário comercial. E avise por DM àquelas pessoas lá que você seguiu e peça para que retweetem (se você tiver alguém que realmente te conhece, é melhor ainda, pois, fará a alavancagem ficar ainda melhor. “Ah pokemão, mas não conheço ninguém…” (tudo bem, a galera dev retweeta fotos de gatinho o dia todo, não vai cair a mão retweetar algo para ajudar alguém). Agora é esperar um pouco para a mágica acontecer. Você vai receber como resposta algumas vagas que se encaixam no seu perfil, com curadoria de pessoas que trabalham nas empresas, vai receber dicas de pessoas da área para ajudar você a conseguir o que quer. (Ignore respostas bosta que sempre aparecem)

Como disse anteriormente a vaga não vai cair do céu, você vai ter que aplicar nas vagas que te mandarem, fazer entrevistas, procurar outras vagas por fora, conversar com as pessoas que vierem falar contigo. Esse processo irá te abrir um leque maior de vagas para você aplicar, APLIQUE PARA TODAS, mas milagres não acontecem, você tem que fazer a sua parte. E, se por acaso você não conseguir uma vaga, irá conhecer várias pessoas da área que podem te dar dicas valiosas para você conseguir o seu objetivo!

Pokemão, mas se todo mundo que quiser vaga fizer isso? Vai ser ótimo, o algoritmo do twitter é bem aleatório para isso e cada pessoa vai atingir uma parte da bolha dev e pessoas vão se conhecer e fará com que a rede de ajuda aumente muito.

Algumas pessoas que conheço fizeram esse processo e deu super certo. Uma inclusive essa semana passada, a Carol seguiu o meu conselho e fez uma thread, ela conseguiu algumas entrevistas e 390 seguidores em algumas horas, está aqui a thread que ela escreveu. Como muita gente fala “Quem não é visto não é lembrado”.

Uma coisa que você deve estar se perguntando… “Pokemão, mas porque não fazer isso no LinkedIn?”, pois lá seu post vai ser invadido por infinitas pessoas coach querendo te vender planos de carreira mirabolantes ou contando histórias de superação de alguém que acordou 10 minutos mais cedo para pegar ônibus. No twitter as pessoas são mais reais, não precisam mostrar nada para ninguém e ajudam realmente as pessoas sem esperar nada em troca.

Um grande abraço para você e vamos fortalecer a bolha dev!

Rodrigo “Pokemaobr” Cardoso

Caso você queira me ajudar a continuar criando conteúdo para devs, me ajude no apoia.se ou assista minhas lives na twitch.

Meu caminho até aqui.

Lissa Ferreira — Sun, 09 Jan 2022 03:27:16 +0000

Meu caminho até aqui

Artigo escrito como lição de casa da live da PachiCodes escrevendo esse artigo aqui

Antes de 2019

Eu sempre fui uma pessoa pesquisadora, sempre quando pensava em fazer algo, como uma montagem ou uma edição de vídeo eu buscava aprender como fazer isso. Tanto por conta do tempo livre que tinha, quanto pela minha falta de interação social, então eu não tive tanta interação social ao ponto de começar a ficar com medo de fazer algo novo. Que é algo completamente enfiado na nossa cabeça, todo mundo por natureza é uma pessoa curiosa.

2019

Nesse ano eu tinha 12 anos. Nessa época, estava bem deprimida por alguns motivos pessoais, ao nível que eu tava só seguindo um caminho sem rumo, como uma pedra que segue o fluxo de água sem nem questionar pra onde tá indo.

Durante uma tarde, bem no meio de 2019, o algoritmo do meu Youtube (que pela parte acima dá pra deduzir que era BEM aleatório Kappa) me recomendou um vídeo sobre Python. Inicialmente, não entendi completamente NADA. mas um interesse surgiu alí, e resolvi começar a pesquisar mais sobre.

Rapidamente, cheguei no curso de Python do Curso em Vídeo, um dos melhores cursos gratuitos de Python que tem inclusive.

E, pra mim, programar se tornou um passatempo basicamente, começava a tentar pegar as idéias que eu tinha principalmente de automatização, e colocava em prática usando Python, e ao longo do tempo outras tecnologias

2020

Com a pandemia, acabei ganhando mais tempo ainda para me dedicar no meu aprendizado, e nos meus projetos, mas do começo do ano, pro meio, acabei tendo todo esse adicional de tempo sugado por uma coisa chamada TWITCH.

De uma maneira tão aleatória quanto eu comecei, conheci a live do Pokemaobr, da dele, fui para a live da Pachicodes, Levxyca, Profbrunolopes, Morgannadev,etc. Aumentando mais e mais meu vício em Twitch Kappa

Conforme o tempo, eu e essa galera começamos a nos aproximar mais e mais, até formar a Caverna do Patocórnio, que foi um divisor de águas pra mim, porquê foi a primeira comunidade de tecnologia que entrei.

Nesse ano também comecei a produzir conteúdo tech, principalmente na forma de lives.

2021

Em 2021, continuei o mesmo caminho que já estava fazendo, mas agora, produzindo mais conteúdo e em formas diferentes, como artigos e podcasts.

Nesse ano, cofundei a Mlkda da Deepweb, um podcast com a bancada mais aleatória da galacta, e também confundei a Kotlinautas, uma comunidade voltada á produção e divulgação de conteúdo sobre Kotlin.

Pessoalmente foi um ano bem merda principalmente do meio pra frente, mas é isso, não podemos controlar o destino.

Atualmente (Aqui)

Atualmente, a coisa que eu mais faço ainda relacionada á tecnologia é produzir conteúdo, divulgar conteúdo e falar com pessoas desenvolvedoras.

Ambas 3 atividades que me dão muita satisfação, eu adoro fazer o tipo de coisa que faço hoje, e que criam um solo fértil pra uma carreira futura, porquê já vou ter um portifólio melhor que a maior parte das pessoas que estarão concorrendo comigo por conta desse tempo.

Exemplo de AWS API Gateway com Lambda pelo Terraform

Eduardo Klosowski — Tue, 07 Sep 2021 17:37:14 +0000

Estou estudando sobre a AWS e algumas ferramentas. Para praticar o aprendido resolvi montar de exemplo uma API Rest utilizando o API Gateway rodando o código em lambdas, e para criar o ambiente optei pelo Terraform conectando no LocalStack (já que esse pode rodar localmente e não exige uma conta na AWS). Nesse texto descreverei o processo e quais tecnologias utilizei.

Primeiramente, para organizar o que precisaria implementar na API Rest utilizei o OpenAPI, que já serve de documentação da API também. O resultado foi um YAML que pode ser visualizado em algum editor que segue o padrão do OpenAPI, como o Swagger Editor (que atualmente apresenta alguns erros por não implementar ainda a versão utilizada da especificação).

Com a documentação da API pronta, o próximo passo foi subir o ambiente de nuvem, que optei pelo LocalStack que eu poderia rodar no meu próprio computador. Porém a versão gratuita do LocalStack não oferece suporte ao RDS para criar o banco de dados, então resolvi rodar o PostgreSQL por fora do ambiente de nuvem simulado pelo LocalStack. Para rodar tanto o PostgreSQL quanto o LocalStack optei por executá-los através de contêineres gerenciados pelo Docker Compose, que também é feito através de um YAML.

Com o LocalStack rodando é necessário uma forma de interagir com ele, uma delas é através do AWS CLI, porém optei pelo LocalStack AWS CLI que já configura os parâmetros necessários para se conectar no LocalStack em vez da AWS. Sua instalação pode ser feita através do pip com o pacote awscli-local.

Para processar as requisições optei por utilizar lambdas, que nada mais são do que um serviço da AWS que permite a execução de funções sem precisar se preocupar com o servidor (máquina virtual) onde rodarão. Visando ter um código o mais simples possível, utilizei diretamente o driver do PostgreSQL para Python (psycopg2), onde cada endereço da API seria respondido pela execução de uma função distinta (O readme do projeto detalha mais sobre os comandos para interagir com os lambdas).

Com os lambdas prontos, é necessário disponibilizar sua execução através de endereços HTTP, que é justamente o que o API Gateway faz. Nesse caso é necessário criar uma API, os caminhos dessa API e dizer quais métodos estão disponíveis, associando-os aos lambdas.

Porém eu gostaria de utilizar também o Terraform para criar esses recursos no LocalStack, então optei por recomeçar a configuração do zero. Para configurar o ambiente pelo Terraform basta criar um arquivo que descreva os recursos desejados, porém por questão de organização optei por dividir em módulos e com o arquivo de estado do Terraform em um bucket S3 simulando um ambiente que permite sua execução em computadores distintos.

Finalmente ao executar o Terraform obtive uma URL como http://localhost:4566/restapis/mea14qi3dw/main/_user_request_ onde pude acessar a API a partir dela, o qual realizei testes usando o HTTPie devido a sua facilidade de uso, ou através da interface disponibilizada pelo Swagger Editor que já é integrado na documentação.

Caso deseje visualizar o processo de deploy com Terraform, segue um vídeo do procedimento sendo executado:

O repositório com o código utilizado está no meu GitHub.

eduardoklosowski / exemplo-aws-api-gateway

Exemplo de AWS API Gateway com Lambda e deploy através do Terraform no LocalStack

Isolamento de aplicações: Docker

Eduardo Klosowski — Sun, 20 Jun 2021 01:54:44 +0000

Nos textos anteriores dessa série vimos como isolar uma aplicação nos contextos de sistema de arquivos, tabela de processos e pilha de rede. Porém isso pode se tornar um pouco complexo para ser gerenciado na mão, precisando executar algo como ip netns exec app1 unshare -fp --mount-proc chroot /media/sistema bash apenas para rodar um terminal dentro de determinados espaços de nomes, sem contar toda a configuração necessária para isso. Mas existem ferramentas que facilitam criar e executar aplicações dentre de espaço de nomes, o que hoje são conhecidas como contêineres.

O que é um contêiner

Contêiner é uma forma padronizada de entregar e executar uma aplicação, utilizando-se dos conceitos de espaço de nomes para criar um ambiente isolado para rodar a aplicação, dependendo o mínimo possível do sistema operacional do computador onde será executado, e para isso deve providenciar todos os arquivos e bibliotecas necessários para sua execução, o que normalmente é chamado de imagem.

A seguir serão discutidos como os conceitos visto até então de isolamento de aplicações são aplicados no Docker.

Isolamento de sistema de arquivos

No texto sobre isolamento de sistema de arquivos foi apresentado o uso do debootstrap para criar um diretório com a estrutura de um sistema operacional e o chroot para utilizá-lo como se fosse a raiz do sistema.

No Docker também é necessário uma estrutura de sistema de arquivos, contendo as dependências da aplicação, como bibliotecas e ferramentas. Olhando o repositório da imagem oficial do Debian para o Docker, pode-se observar a existência de um arquivo Dockerfile que é o responsável por dizer como construir a imagem desse contêiner, e que utiliza um arquivo rootfs.tar.xz, ou seja, um arquivo que contem todo o sistema de arquivos necessário para o contêiner.

É possível repetir esse processo com o sistema criado pelo debootstrap, para isso basta navegar até o diretório onde ele foi criado e gerar um arquivo tar com seu conteúdo, compactando-o ou não.

cd /media/sistema
tar -cvf ../rootfs.tar .

Isso gerará um arquivo rootfs.tar.xz que deve ser colocado em um diretório junto com o arquivo Dockerfile a baixo:

FROM scratch
ADD rootfs.tar /
CMD ["bash"]

Com esses dois arquivos prontos, para gerar a imagem do contêiner basta executar docker build -t sistema ., que gerará uma imagem com o nome de sistema:

Sending build context to Docker daemon  317.4MB
Step 1/3 : FROM scratch
 --->
Step 2/3 : ADD rootfs.tar /
 ---> e8ca0bcee43d
Step 3/3 : CMD ["bash"]
 ---> Running in 84d7a3d758f9
Removing intermediate container 84d7a3d758f9
 ---> 94cdf37927fa
Successfully built 94cdf37927fa
Successfully tagged sistema:latest

Com a imagem pronta, para iniciar um contêiner basta executar docker run -it --rm sistema bash. A principal vantagem dessa abordagem é a possibilidade de abrir um outro terminal, executar o mesmo comando e ter outro ambiente isolado, o qual pode ser repetido diversas vezes. Ou como será mostrado mais para frente, executar outro processo dentro do mesmo espaço de nomes.

Vale observar também como funciona o sistema de arquivos nas imagens dos contêineres. Sempre existe uma imagem base, que nesse caso foi a scratch que é um nome reservado para uma imagem em branco (sem nada dentro), e a partir dela cada comando do Dockerfile criou outra camada em cima dela. Imagine como se a imagem base fosse um desenho em uma folha de papel, e as camadas posteriores fossem um plástico transparente colocado por cima desse desenho, seria possível ver o desenho e desenhar em cima dele, porém tudo que for desenhado estaria no plástico e não no papel de baixo, e ao colocar outra camada, seria possível ver o plástico em baixo, e o papel ao fundo, mas tudo que fosse desenhado agora estaria no novo plástico colocado. Essa é a ideia de copy-on-write (COW), onde é possível ler o que estiver nas camadas mais a baixo, desde que elas não forem sobrescritas por algo nas camadas superiores, mas a gravação sempre ocorre na última camada.

E embora funcional, como o debootstrap gera um sistema operacional para ser instalado em um computador, ele adiciona diversos arquivos que não são necessários para o contêiner. Nesse exemplo o rootfs.tar gerado pelo debootstrap tem 302,7MiB contra 113,7MiB do mesmo arquivo no repositório da imagem Debian quando descompactado, e 59,4MiB contra 28,7MiB quando se compara os dois arquivos compactados (nesse caso o arquivo foi compactado com xz -9 -e rootfs.tar, a forma mais otimizada possível). Desta forma é recomendável utilizar a imagem oficial, que além de poupar o trabalho, é mais otimizada em relação ao espaço.

Isolamento de tabela de processos

Além do isolamento de sistema de arquivos, o Docker também oferece o isolamento da tabela de processos. Para visualizar isso é possível executar um processo como o Nginx dentro do contêiner com nginx -g 'daemon off;' (depois de instalado com apt install nginx, por exemplo), e em outro terminal executar docker exec -it gifted_darwin bash para abrir um Bash dentro desse mesmo contêiner, e assim ser possível verificar os processos em execução dentro desse contêiner com ps aux:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   3988  3240 pts/0    Ss   11:28   0:00 bash
root       825  0.0  0.0  67700 12572 pts/0    S+   11:30   0:00 nginx: master process nginx -g daemon off;
www-data   826  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   827  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   828  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   829  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   830  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   831  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   832  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
www-data   833  0.0  0.0  68084  3444 pts/0    S+   11:30   0:00 nginx: worker process
root       834  0.2  0.0   3868  3268 pts/1    Ss   11:32   0:00 bash
root       840  0.0  0.0   7640  2692 pts/1    R+   11:32   0:00 ps aux

Porém ao executar um ps aux | grep nginx fora do contêiner, os mesmos processos são visualizados, porém com os seus números de processos reais, uma vez que o Nginx está executando de verdade no kernel da máquina física.

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     14505  0.0  0.0  67700 12572 pts/0    S+   08:30   0:00 nginx: master process nginx -g daemon off;
www-data 14506  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14507  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14508  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14509  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14510  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14511  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14512  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process
www-data 14513  0.0  0.0  68084  3444 pts/0    S+   08:30   0:00 nginx: worker process

Isolamento de pilha de rede

Em relação ao isolamento da pilha de rede, o Docker apresenta algumas opções, como não permitir acesso a rede (null), utilizar a mesma pilha do sistema (host), ou utilizar uma rede virtual semelhante a feita anteriormente de forma manual (bridge). Por padrão todos os contêineres são executados dentro da rede bridge, porém é possível criar redes distintas para alguns contêineres também.

As redes disponíveis podem ser verificadas com o comando docker network ls:

NETWORK ID     NAME                DRIVER    SCOPE
1e363194a6f7   bridge              bridge    local
44ff21ce424a   host                host      local
e69eb4f8b6e8   none                null      local

Fora do contêiner é possível verificar os endereços que o computador tem em cada rede através do comando ip addr, procurando as interfaces de rede começando com docker seguida de algum número. Exemplo:

6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:05:6f:f2:38 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:5ff:fe6f:f238/64 scope link
       valid_lft forever preferred_lft forever

Ao executar o mesmo comando dentro do contêiner são exibidos seus endereços da pilha de rede:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Porém caso queira não criar uma nova pilha de rede para o contêiner, é possível adicionar o parâmetro --network host ao comando docker run (exemplo docker run -it --rm --network host sistema bash). Assim ao executar ip addr serão exibidas as mesmas interfaces de rede da máquina, não aplicando essa técnica de isolamento.

Outros isolamentos

Ainda existem outros tipos de isolamento de espaço de nomes aplicados pelo Docker, e eles podem ser listados através do comando ls -la /proc/self/ns que quando executado dentro do contêiner, lista exatamente os mesmos espaços de nomes que quando executado fora do contêiner informando o número do processo, como ls -la /proc/15277/ns:

total 0
dr-x--x--x 2 root root 0 jun 13 08:37 .
dr-xr-xr-x 9 root root 0 jun 13 08:37 ..
lrwxrwxrwx 1 root root 0 jun 13 08:40 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 jun 13 08:40 ipc -> 'ipc:[4026532573]'
lrwxrwxrwx 1 root root 0 jun 13 08:40 mnt -> 'mnt:[4026532571]'
lrwxrwxrwx 1 root root 0 jun 13 08:37 net -> 'net:[4026532576]'
lrwxrwxrwx 1 root root 0 jun 13 08:40 pid -> 'pid:[4026532574]'
lrwxrwxrwx 1 root root 0 jun 13 08:43 pid_for_children -> 'pid:[4026532574]'
lrwxrwxrwx 1 root root 0 jun 13 08:40 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 jun 13 08:40 uts -> 'uts:[4026532572]'

Considerações

O Docker é uma ferramenta que torna muito mais prático a execução de processos dentro de espaços de nome do kernel, além de automatizar muito do trabalho de suas configurações. Também apresenta alguns diferenciais do processo manual demonstrado, como as camadas aplicadas no sistema de arquivos, o que permite que várias imagens compartilhem algumas camadas, e que mais de um contêiner possa ser executado a partir do mesmo sistema de arquivos, onde cada contêiner teria sua última camada de forma particular.

Com o processo manual, também fica mais evidente do motivo do Docker no Windows rodar dentro de um ambiente virtualizado, uma vez que é necessário um kernel Linux em execução, visto que os programas do contêiner normalmente esperam se comunicar com um kernel Linux. Embora também exista alguns contêineres específicos para Windows, e que neste caso específico exigem o kernel do Windows. Assim como as arquiteturas, um contêiner feito para x86_64 não vai funcionar em um hardware ARM, a menos que uma virtualização de espaço de usuário, como a oferecida pelo QEMU, seja utilizada.