terça-feira, 30 de abril de 2019

Quem usa código livre deveria contribuir com código livre


Você ou sua empresa usa código livre?

 

A cada dia mais empresas estão adotando software livre em sua infraestrutura. Linux em servidores e workstations, Gnome, Cinnamon, Jenkins,  Blender, Apache, NginX, PostgreSQL, Tomcat, Docker,  Kubernetes, Eclipse, entre muitos outros, fazem parte do dia-a-dia de muita gente.  Servem de base para muitos produtos que garantem faturamento e pagam muitos salários.

Todos esses softwares são desenvolvidos de forma livre, seus códigos-fonte estão disponíveis ao público, bem como as instruções de como compilar e debugar.

Além do código-fonte, fóruns, wikis e chats são acessíveis, bastando, no máximo, um e-mail para publicar. Geralmente as comunidades são muito receptivas, desde que você entenda onde você está primeiramente (perguntas em listas erradas ou que tem resposta amplamente disponíveis geralmente causam reações menos receptivas).

Por fim, sistemas de issue tracking estão disponíveis para a maior parte dos projetos, e quando não tem, as listas de e-mail fazem esse papel. Tudo isso para permitir que a comunidade, que faz uso desses softwares possa se comunicar e contribuir.

Mas porquê contribuir?

 

Todo trabalho humano tem um custo. Alguém dispendeu algum tempo para executá-lo. Quando há uma relação de trabalho, o custo desse tempo está definido no contrato, que ambas as partes acordaram.

Para desenvolver código também há trabalho envolvido, como as empresas de software bem sabem. E esse trabalho não é pouco, por valor agregado (como as empresas também sabem). Logo, se para desenvolvermos software comercial cobramos somas vultosas, quem paga pelo desenvolvimento do software "gratuito" que usamos? 

Pois é, quem paga por isso são os próprios desenvolvedores, que investem seu tempo livre, férias, período "entre empregos", para desenvolver algumas funcionalidades. 

Obviamente, como em todo projeto, o ânimo de começar é sempre maior. Mas e bug fixing? E refatoracões para adicionar funcionalidades que o autor nem conhece tão bem? E aquele ajuste de CSS para melhorar o layout? 

Nem sempre o autor tem tempo de retomar o projeto. Mudanças na vida pessoal sempre acontecem, a faculdade acaba, surge um emprego, casamos. Manter software custa caro e dá trabalho. Mas mesmo assim, muitos tem lucro com esse software e acabam reclamando da defasagem, dos bugs, dos workarounds necessários para usá-lo.

Todo desenvolvedor, empresa, ou simplesmente usuários de software livre, deveria tentar colaborar com a comunidade. Quem sabe programar, deveria estudar o código-fonte de algum projeto. Quando notar um bug, mesmo se não for programador, verifique se há uma issue aberta. Se houver , vote nela, inclua detalhes do ambiente onde o bug foi reproduzido, adicione casos de uso. Se não existir, crie uma. Tente achar uma correção, discuta com outros desenvolvedores sobre o problema ou a solução. Isso ajuda a melhorar sua técnica de programação, de análise e até a treinar o inglês.

As empresas de software podem incorporar tickets de bugs ou features em seus backlogs, ou estimular os desenvolvedores a colaborar com algum projeto. Caso não queiram colaborar ou não sejam empresas de software, podem fazer doações financeiras, únicas ou periódicas, para esses projetos. É possível até mesmo mandar uma mensagem junto com a doação pedindo alguma atenção especial para uma necessidade da empresa. As fundações que gerenciam alguns desses softwares fazem muito bom uso desses recursos. 

O software livre mudou a forma como vivemos hoje. Mas ele corre riscos a cada dia. Sempre existe pressão por parte de grandes empresas de monopolizar o seu desenvolvimento, de torná-lo menos relevante, ou simplesmente, torná-los uma versão freeware de seus próprios sistemas. 

Se você quer evitar ficar preso às grandes empresas de software, apoie o software livre de qualquer forma que puder.

sábado, 13 de abril de 2019

Aprenda mais linguagens de programação, mesmo que você não vá usar


Imagine que você tem uma tarefa para realizar, e é livre para escolher a linguagem de programação. A tarefa envolve diversos tipos de manipulação de texto: leitura, segmentação, recortes, concatenação e execução de expressões regulares, tudo em UTF-8 e, certamente, precisa suportar emojis. Qual linguagem você escolheria? C? Por favor, não.

Outra atividade, agora numa instituição financeira. Precisamos fazer dezenas de milhares de operações financeiras de forma concorrente. Alta performance é um requisito fundamental. Deveríamos usar… Ruby? Qual é. Próxima: um script para ser usado apenas uma vez que renomeia diversos arquivos… Escrito em Java? Num browser … em Python? Programando um controlador para um dispositivo médico com… C#? Swift? Lua? Acho que você entendeu.

Diferentes linguagens de programação são boas em coisas diferentes, e ruins em outras. Cada uma faz certas coisas ficarem fáceis e outras mais difíceis. Dependendo do que nós queremos fazer podemos economizar muito trabalho escolhendo a linguagem que resolve o tipo de trabalho que enfrentamos mais facilmente.

Esse é um dos benefícios tangíveis de aprender mais linguagens. Você adiciona outra ferramenta ao seu repertório e quando surge a oportunidade, pode escolher a melhor opção. Mas eu quero ir um pouco mais à fundo.

Eu acredito que haja um enorme valor em aprender novas linguagens de programação mesmo caso — e lá vem — você nunca as use!

Linguagens modelam a forma como pensamos, cada uma de uma forma peculiar. E isso é verdade para linguagens de programação também. Cada linguagem possui um modelo mental diferente, uma perspectiva diferente para pensar sobre computação e como escrever programas.

Pegue SQL, por exemplo, e como ele modela sua ideia sobre o fluxo e a forma dos dados em seu programa. Agora considere como isso ficaria com uma linguagem imperativa, orientada a objetos como Java, ou uma linguagem funcional como Haskell. Ou em C. Imagine como seria um servidor de jogos multi-player em Python, em Haskell, em Erlang; Fazer streaming e processar terabytes de dados em C, em Go, em Clojure; uma interface de usuário em Tcl, em Lua, em JavaScript.

Toda linguagem de programação é uma lente através da qual podemos ver o problema que estamos tentando resolver. Através de algumas delas o problema parece complexo, exaustivo. Através de outras ele nem parece um problema, parece apenas diferente de outras coisas comuns que se faz nessa linguagem.

Aprendendo uma nova linguagem, mesmo que ela fique na sua caixa de ferramentas por toda a eternidade, você ganha uma nova perspectiva e uma forma diferente de pensar sobre os problemas. Uma vez que você implementou um servidor de jogos em Erlang, você verá servidores de jogos sob uma nova perspectiva. Depois de ter processado dados em Lisp, pensando nos dados como series de listas que podem ser moldadas enviando-as por diversas pequenas funções que podem ser compostas para formar pipelines de funções, você observará sombras desse padrão aparecer em todos os lugares. Assim que você tiver experimentado o gosto de gerenciar memória em C, você começará a apreciar o que Python, Ruby e Go fazem por você — enquanto nota o custo desse trabalho. E se um dia fizer uma interface de usuário em JavaScript com React.js, você notará que está pensando sobre componentes de UI de uma forma completamente diferente.

Essas novas perspectivas, essas ideias e padrões — elas perduram, elas ficam com você, mesmo que você acabe usando outra linguagem. E isso é poderoso o suficiente para te manter aprendendo novas linguagens, porquê uma das melhores coisas que podem acontecer com você, quando está tentando resolver um problema, é uma mudança de perspectiva.

Original disponível em https://thorstenball.com/blog/2019/04/09/learn-more-programming-languages/