April 30, 2020

Participe de projetos Codigo Aberto

Vou comentar um pouco minha trajetória que foi moldada de forma integral por comunidades online.

Em 2008 eu comecei meus primeiros passos na internet, além de jogar de forma alucinada comecei a aprender 3D Studio Max e Blender. Na época eu assistia muitos vídeos Xiao Xiao e queria muito conseguir fazer igual em Flash.

Começou ali uma aventura que me acompanha até os dias de hoje:

Uma conta no iMaster e fui o membro mais chato e com pior português possível por 3 meses seguidos (é o máximo de tempo que um adolescente de 16 anos consegue se comprometer com algo).

   

imaster

   

Depois passei por fóruns e comunidades no ICQ, IRC, Orkut, Reddit, Blogs pessoas, Blogs de jogos como Unreal, WYD, Mu online e diversos outros clássicos tratando de temas desde Tire suas dúvidas para passar no vestibular até grupos privados sobre Unix e Sísmica de Reflexão.

Legal, mas onde quero chegar? Todas essas experiências me fizeram entender como o processo de aprendizagem e cooperação online funciona (pra mim), assim como quais benefícios de médio e longo prazo eles podem trazer. Portanto quero fazer esse link com o mundo do desenvolvimento de software usando alguns exemplos que eu tive.

O inicio parece impossível mesmo

   

Quem trabalha com Python e não gostaria de contribuir para o projeto do Pandas? Biblioteca famosa, 22 mil commits, deve ter milhares de linhas de código, são 1900 pessoas diferentes contribuindo para o projeto. O que eu mortal posso fazer? Muito!

   

pandas

   

Porém, vamos para o começo.

Um projeto como esse é uma empresa com as portas abertas. Ele tem suas estruturas internas, pessoas responsáveis com papeis específicos, hierarquia, politica, etc. E o que você faz quando chega em um emprego novo?

  • onboarding

  • tirar dúvidas com pessoas mais experientes

  • leitura/estudo com relação ao domínio de negócio da empresa

  • fazer tarefas pequenas e menos complexas

  • se ambientar o suficiente para migrar para tarefas complexas

  • liderar projetos

       

Nesse caso é exatamente igual.

  • Basicamente todos os pontos acima você resolve participando e lendo as Issues e Pull Requests dos projetos. * Não é tão raro projetos usarem listas de discussão via email, por exemplo, clojure.

       

Importante: Comece fazendo tarefas pequenas!! É comum os projetos colocarem indicadores nos problemas para orientar os novatos, como good first issue, easy, documentation.

   

Exemplos que participei:

  • Documentação pandas group-by [python]: link

  • Documentação reitit [clojure]: link

  • Adicionar dicas sobre tipos onde o autor esqueceu reitit [clojure]: link

  • Literalmente adicionei aspas no organic-green [elisp]: link

  • Adicionei 7 palavras no spec-tools [clojure]: link

   

Inglês

prog

Ponto importante, muito importante. Eu estudo Clojure, utilizo no trabalho e muitas pessoas me perguntam se é muito difícil de aprender, como se adaptar, etc. e eu tenho uma posição bem firme sobre o assunto:

   

A principal linguagem que causa dificuldades no trabalho é o inglês.

   

Isso é realidade ainda dentro de times de desenvolvimento. Conseguir expor suas ideias de uma forma inteligível é essencial. E porque? Por que você vai ler bastante e precisar discutir com as pessoas sobre o problema, sobre suas ideias para solução e sobre as ideias delas.

   

Exemplos:

  • 1 mês discutindo blacklist em uma máquina de regras clara-rules [clojure]: link

  • Qual seria a melhor forma de fazer scan do código clara-rules [clojure]: link

  • Definir formato de estrutura de dados pomidor [elisp]: link

   

Ganhe confiança e familiaridade

 

panda cdn

Com o tempo, lendo um pouco do código todo dia e ganhando mais confiança você pode começar a corrigir aqueles problemas que você esbarra no seu dia-a-dia no trabalho e até mesmo incluir funcionalidades simples que facilitaria seu trabalho. (ou algum projeto pessoal seu)

   

Exemplos:

  • Download de uma imagem para o org-mode org-download [elisp]: link

  • Suporte para quebrar captcha com base64 python3-anticaptcha [python]: link

  • Correção para tornar compatível com versões anteriores spec-tools [clojure]: link

   

Alguns pontos sobre os projetos Open Source…​

oogway

Existe um ponto importante que eu gosto de lembrar, o projeto não é seu.

Esse projeto de código aberto é do autor original, seja ele uma pessoa ou uma empresa. Se você discorda de algo, não quer discutir ou tomou uma carteirada, faça um fork do projeto e evolua o seu!

Se outras pessoas da comunidade concordam com seu ponto de vista, então elas vão escolher livremente o uso da sua versão do código.

Esse é um ponto critico porque algumas pessoas dedicam horas, as vezes anos ao mesmo projeto e conseguem fazer parte de um comitê que tem mais autonomia para tomar decisões sobre aquele projeto. (Lembra? Igual uma empresa…​) Porém ao fazer um investimento tão alto se as coisas começam a ir em uma direção que você discorda, você pode se sentir traído ou ofendido e acaba abandonando o projeto causando algum tumulto online. Isso é bastante comum.

Convenhamos, de fato é fácil se frustrar quando você tem aquela ideia legal e quer que todo mundo também use, mas o autor da biblioteca não te responde mais ou some do mapa. É um direito dele, não sabemos e nem podemos supor quais são as suas prioridades e atividades correntes.

E o oposto também é verdadeiro, as vezes você começa algo e perde o interesse no meio do caminho.

   

Não seja esse maluco stalkeando o autor da biblioteca no Twitter:

   

me

   

Exemplos:

  • Gostei do tema organic-green e resolvi refazê-lo para modernizar [elisp]: link

  • Inclusão complexa de uma nova funcionalidade para o spec-tools [clojure]: link

  • Uma hora eu volto para rever isso, deixei de lado um tempo reitit [clojure]: link

   

E a sua vez, crie seus próprios projetos!!

tigress

Pelas minhas contribuições em Elisp já dá para imaginar que eu gosto dessa linguagem e não é para menos. A comunidade que existe em torno do Elisp é excepcional e os conceitos embutidos são muito ricos.

Em fevereiro de 2017 publiquei junto com um amigo o meu primeiro pacote em Elisp que de fato teve algum usuário, o helm-spotify-plus.

O pacote permite que você faça buscas e opere o Spotify através do Emacs. Foi muito divertido fazer esse pacote e lutar com uma linguagem antiga como o Elisp, hoje a biblioteca ocupa a posição de destaque dentro do percentil 70% no repositório de pacotes MELPA. Isso é bom? Para mim é ótimo! rsrs.

Ao ter um pacote próprio com usuários você está sujeito a diversas situações: i) programadores que gostaram da ideia e querem contribuir, ii) aqueles que não veem sentido algum na sua ideia completamente inútil.

   

Exemplos:

  • Adicionaram uma "playlist" usando queues no elisp helm-spotify-plus [elisp]: link

  • mamulengo banco de dados em DataScript p/ aplicações pequenas [clojure]: link

  • emacs.d minhas configs do Emacs, trabalho diariamente desde 2016 [elisp]: link

  • meta-schema ideia de specs dinâmicas [clojure]: link

   

Mas por que fazer tudo isso?

not to

   

Primeira resposta óbvia é: "porque eu posso".

Mas falando sério, o ambiente do software de código aberto permite você trocar experiencias com pessoas muito diferentes de você. Metade dos meus códigos foram revisados por pessoas da Rússia, Finlândia, Estônia, Israel, etc. Ler os códigos que eles fazem é entender um pouco a forma como eles pensam, como estruturam soluções, como implementam ideias abstratas em código palpável.

No clássico texto do Peter Norvig Aprenda a programar em 10 anos, precisamos nos colocar em diversas situações diferentes para poder evoluir profissionalmente.

Tem projetos onde você é o que domina melhor o tema, em outros você é o mais novato. Participar e vivenciar as duas experiências é extremamente enriquecedor.

Independente de onde você trabalha, você não vai poder discutir por 1 mês se 150 linhas de códigos devem ou não ser adicionados da maneira X ou Y porque não temos esse luxo em ambiente corporativo. Porém você precisa dessa experiência, precisa ir mais fundo no problema, aprender a antecipar implicações importantes.

Software é uma profissão de prática, espero ter motivado algumas pessoas para participar dessa jornada também!

Happy Hacking!

Tags: codigo aberto summary