Problemas e soluções

Na última sexta-feira, 30/06/2017, eu vi… Eu vi uma luz no fim do túnel. Chamava-se TCC.

Mas não o TCC famoso, o famigerado Trabalho de Conclusão de Curso; foi o Tiny C Compiler. Pela primeira vez na vida, eu vi um compilador para a linguagem C pequeno, rápido e leve. Ele ainda tem a funcionalidade de executar código-fonte diretamente, como um interpretador de scripts, algo bem interessante.

Outro ponto extremamente positivo é que ele funciona no Windows. Aliás, ele simplesmente funciona: basta baixar o zip, extrair, rodar tcc.exe e pronto. Nada de MinGW, MSYS, cygwin e outras tranqueiras complicadas de instalar e configurar. O Windows é um SO explicitamente negligenciado por boa parte da comunidade de desenvolvimento de software. Dizem que a solução é criar máquina virtual – e eu sugiro VirtualBox com Linux Mint XFCE. É, após baixar alguns gigabytes e instalar tudo, realmente funciona bem.

Já o TCC tem apenas 389KB zipado e 1,53MB extraído. Como eu disse, nunca tinha visto um compilador tão pequeno. Ele também é quase 9 vezes mais rápido do que o GCC e produz código de saída super pequeno, também. Um ola-mundo.exe gerado pelo Visual Studio tem 8,5KB. Já o mesmo programa compilado com o TCC tem 1,5KB – mesmo tamanho da versão em Assembly (testei usando o MASM32 SDK).

Também experimentei fazer um Olá, Mundo em Go e deu 1,6MB. Em Rust, 3,6MB. Em JavaScript, usando NodeJS e a plataforma de distribuição Electron para gerar um executável distribuível: 127MB.

Pois é… Estamos vivendo a era do hardware barato. E de seu desperdício.

  • Para que usar apenas 1,5KB se a gente pode fazer em 1,6MB, 3,6MB ou 127MB e o hardware aguenta?
  • Por que uma tarefa rápida como compilar um programa trivial deveria rodar em 5 milissegundos se a gente pode fazê-lo precisar de 90?
  • Para que armazenar pequenos arquivos localmente se a gente pode criar bancos de dados NoSQL em nuvem a torto e a direito e gastar alguns Mbps de conexão de internet com isso?

Fera mesmo eram os programadores de jogos dos consoles antigos… Aqueles, sim, tiravam leite de pedra. Não havia outra opção: hardware extremamente limitado, programação só em Assembly. Ou fazia assim, ou não fazia.

O Atari, por exemplo, tinha 128 bytes de memória. Não são megabytes nem kilobytes, são BYTES! E dava certo. Não sei como, mas dava! Provavelmente, cada bit era muito bem aproveitado.

Já a gente aqui, em 2017, vai seguindo a vida, gastando mais de 1MB e mais de 270 milhões de ciclos de CPU apenas para dizer oi para o mundo… E achando isso normal.

Isso NÃO é normal. Isso está muito errado. As pessoas estão muito longe de conhecer o verdadeiro poder de suas máquinas. Estamos apenas comendo migalhas perto do que realmente poderíamos fazer.

Ao questionar esse assunto, às vezes a explicação que vem como resposta é que precisamos resolver os problemas grandes. E, que, para esses problemas, as ferramentas que temos funcionam bem. Ou seja, o importante é que o GCC compile código gigante em um tempo longo (em vez de muito longo); o importante é que um programa gigante em Go ou Rust fique com centenas de megabytes (em vez de vários gigabytes). Em outras palavras: “temos que sacrificar as pequenas aplicações em prol das grandes aplicações, que são as que realmente importam”. Engraçado… Onde é que já ouvimos esse discurso antes?

Eu tenho uma visão diferente. Eu acredito que todos podem ser bem atendidos. Não existe essa tal “decisão difícil” entre os grandes e os pequenos problemas. O que existe é para onde queremos direcionar nossos esforços. Os grandes problemas já estão sendo resolvidos por gente capacitada. E os pequenos? Também estão? Bom, o TCC está aí para nos ajudar a mudar esse cenário.

Vejo um futuro em que, tanto quanto já temos acesso a programas grandes e pesados para resolver problemas grandes e pesados, teremos acesso a programas pequenos e rápidos para resolver problemas pequenos e rápidos. E, assim, todos serão mais bem atendidos nesse mundão de Deus, cada um dentro da sua necessidade.

Licenças de software: qual escolher?

20/12/2016: ATUALIZANDO – Vídeo da palestra publicado!

Não conseguimos viver sem elas. MIT isso, GPL aquilo, LGPL aqui, BSD ali… E aí? O que elas permitem, o que elas proíbem, como aplicar corretamente?

Esse assunto é bem complexo. Um dia, ao perceber que não entendia nada dele, resolvi estudar. Percebi que entendê-lo a fundo realmente é complicado, pois a coisa é cheia de armadilhas e exceções. Porém, entendê-lo mais superficialmente é plenamente possível, e bem elucidativo!

Há alguns dias, em maio de 2016, ministrei uma palestra no TDC Florianópolis sobre o assunto. Nela, você pode conferir algumas dicas teóricas e práticas, que poderão ajudá-lo a dar os primeiros passos.

Boa leitura!

Acesse o conteúdo no Speaker Deck aqui: https://speakerdeck.com/awvalenti/licencas-de-software-qual-escolher.

Muito próximos e muito distantes

Quando eu era pequeno, meu passatempo mais maravilhoso era jogar videogame.
Para meus pais, eram apenas jogos. Para mim, eram sonhos.
Era uma viagem interdimensional. Era o passaporte para o mundo das ideias.
Era um mergulho profundo em um espaço lógico e lúdico.

Finda cada viagem, um novo André seguia o caminho de volta.
Um André mais vivido, mais preparado.
Com mais sonhos, alegrias, horizontes.

Um dia, um computador chegou até minha casa.
Era como um videogame, mas eu podia modificá-lo, instalar novas coisas.
E mais um universo se abriu para mim!
Aquelas cores, caracteres, sons… Atalhos de teclado…

Naquela época, um computador te levava a outros lugares.
Um computador não te dava respostas, te dava perguntas.
A sua imaginação preenchia as lacunas.

Um dia, ensinaram-me a programar, usando QBasic.
Nesse dia, um novo universo se abriu para mim.
Os caracteres, os sons, as cores… Agora, eu mesmo podia fazer tudo acontecer.

Agora, eu podia criar o que quisesse. Agora, eu começava a contar a estória.
Agora, eu era o narrador e o personagem principal.

Assim, eu encontrei minha profissão.

Penso nos computadores até a década de 90 como similares aos livros infantis. A história que eles contavam vinha pela metade; era você que completava a história, e fazia sua própria história. Era uma via de mão dupla.

Talvez seja isso que tenha me fascinado na Informática. Ela sempre foi, para mim, um mundo novo a ser descoberto.

E, depois, vieram muitas outras coisas: jogos por modem, internet, e-mail, ICQ… Redes sociais, MSN, Skype… (imagine, conversar com qualquer pessoa do mundo por voz e vídeo, sem precisar pagar por isso!)

Depois, vieram outros jogos, vieram aplicativos pela web como Google Docs… E, mais recentemente, veio a nuvem, o Dropbox, o Google Drive, o GitHub…

Um dia, entraram em cena os smartphones.

E, então, por algum motivo, eu não quis mais brincar.

Por algum motivo, senti que a brincadeira tinha ido longe demais. Por algum motivo, senti que as soluções começaram a surgir antes dos problemas. Por algum motivo, senti a presença de caroço nesse angu, e não o quis mais no meu almoço.

Era como se alguma coisa ruim tivesse acontecido no cenário tecnológico mundial. Alguns fantasmas começaram a assombrar o que antes parecia belo. Alguns interesses começaram a sobrepujar o que era simples. A complicação tomou conta do negócio.

De repente, toda aquela promessa de conexão entre as pessoas começou a ser descumprida. De repente, todas aquelas possibilidades maravilhosas começaram a ser esquecidas. De repente, uma enxurrada de novas manias começou a dominar as pessoas, tornando-as escravas. De repente, o sistema não ficava mais da tela para dentro, e, sim, da tela para fora. De repente, o programa começou a programar o usuário e o programador.

Alguma coisa triste se tornou o padrão. O excesso de padrões tornou a coisa triste. A coisa se entristeceu de maneira padronizada. Os fenômenos se tornaram epidêmicos, as opiniões se uniformizaram, as individualidades se apagaram. As minorias se coletivizaram, os coletivos se venderam, os robôs começaram a agir como pessoas e as pessoas começaram a agir como robôs.

Algo muito esquisito está acontecendo com os usuários da Informática, que hoje são quase todas as pessoas. As pessoas estão buscando o caminho, a verdade e a vida em pequenas caixas eletrônicas, cada vez menores e mais cansativas para a vista. As pessoas estão clicando em botões cada vez menores, escrevendo em espaços cada vez menores. As pessoas estão vivendo vidas cada vez mais virtuais.

As pessoas estão buscando a felicidade fora do endereço 127.0.0.1. As pessoas estão buscando o sucesso em modelos econômicos e administrativos que nem compreendem direito. As pessoas estão repetindo palavras cujo significado nem conhecem.

As pessoas estão falando coisas demais, estão dando opiniões demais, estão fingindo que entendem coisas que não entendem. Estão querendo ficar bem na foto, sem nem ter ficado bem no fato.

O que houve com a Informática? O que houve com as pessoas? O que houve com o mundo?

Cadê aquela inocência dos caracterezinhos coloridos em baixa resolução, que se juntavam àqueles sonzinhos simples de ondas quadradas, fazendo um esforço enorme para causar boa impressão? Cadê aqueles sitezinhos em HTML puro, todos em branco e preto, cheios de informações extremamente concisas e interessantes? Cadê aqueles joguinhos criativos que aproveitavam ao máximo aqueles 640KB de memória, proporcionando viagens fantásticas ao jogador?

Tudo parece estar tecnicamente fácil hoje em dia, mas as pessoas não parecem ter sido preparadas para isso. Elas acham que podem tudo, que devem fazer de tudo. Só que, quando pode tudo, nada vale; quando tudo é feito, nada é fato. Perde-se em relevância, falta critério, decência, limite.

Acorda, mundo! Nem tudo é interessante, nem tudo vale a pena, nem tudo é aceitável, nem tudo é bom.

Estamos vivendo uma crise de relevância no mundo. Estamos num vazio moral. Estamos sem saber direito por que acordar de manhã e dormir à noite. Estamos sofrendo de depressão. Fazemos de tudo, mas não sabemos por quê ou por quem, nem o que realmente deveria ser feito.

Estamos muito próximos de mudanças muito distantes.

Generalidades

Inovação é uma das palavras da vez. Sabe o que isso significa? Significa que, agora, tudo é inovação, qualquer coisa é inovação. Afinal, ninguém quer ser considerado não-inovador, retrógrado, obsoleto.

O mesmo ocorre com a expressão em inglês full-stack developer. Sabe o que é um full-stack developer? Se você for da área de Informática, talvez saiba: um full-stack developer é um desenvolvedor de software capaz de trabalhar com desde o software que roda nos servidores (lidando com Java, Ruby, Python, PHP etc.) até o software que roda nos clientes (lidando com HTML, CSS e JavaScript).

É engraçado, porque, quando eu era mais novo, as pessoas que sabiam mexer com um pouco de tudo eram chamadas de outros nomes; eu me lembro da palavra generalista. Mas tinha uma diferença: ninguém se tornava melhor que os outros por ser generalista. Então, era uma coisa simples, um título sem nenhum juízo de valor, algo como você usar uma camiseta azul e o seu amiguinho usar uma camiseta verde.

Mas parece que as coisas mudaram no mundo… Parece que, hoje em dia, cada vez mais as pessoas querem ter títulos. E não são nem títulos acadêmicos, conquistados com muito suor; são títulos que as pessoas dão para si mesmas, tornando-se pessoas autointituladas.

Num mundo em que todos os desenvolvedores são full-stack developers, quem é que quer ser um desenvolvedor de meia-tigela? Num mundo em que todas as empresas são inovadoras, quem é que quer ser retrógrado?

Isso tudo me lembra do que o Kent Beck disse, no livro de TDD. Ele disse que aprendeu o seguinte: o sucesso de um nome novo depende muito de que o contrário dele seja negativo. Então, a programação estruturada fez bastante sucesso em parte porque ninguém queria ser desestruturado. Aí, ele escolheu o nome Test-Driven Development (Desenvolvimento Guiado por Testes), pois todo mundo iria querer ser guiado por alguma coisa.

Talvez, pior ainda do que ser meia-tigela ou retrógrado seja não ter título nenhum. Talvez, se você for apenas um desenvolvedor, ou apenas uma empresa (e não uma startup nem nada parecido), você esteja completamente fora de moda. Com isso, talvez você esteja automaticamente fora do mercado, não importando se você faça bem o seu trabalho ou não, não importando se você trate bem seus funcionários ou não. Aliás, tratar bem os funcionários só faz sentido se você puder dar um nome pomposo para isso e colocar no seu site para poder ganhar uns clientes, não é mesmo?

Pensando bem, talvez isso tudo não seja coisa de hoje em dia. Talvez seja apenas aquela retrógrada ideia de manter as aparências, uma coisa tão velha quanto o mundo. Talvez faça parte do ser humano… Se ele quiser que faça.

Andando para a frente 2

Neste artigo, de um mês atrás, eu mencionei que havia cancelado minha conta no Twitter. Também disse que teria 30 dias para rever minha decisão: se eu logasse de novo nesse prazo, teria minha conta de volta. Fiquei de vir aqui para contar a vocês o resultado!

O resultado é que, basicamente, não senti falta nenhuma do referido serviço! Uma vez ou outra, confesso que me peguei digitando twitter.com na barra de endereços do Chrome, mas logo percebi e lembrei: “Ah, é, eu cancelei minha conta!”.

Hoje, tentando acessar o antigo endereço do meu usuário, deparei com uma página de usuário inexistente, porém reparei numa coisa interessante: uma opção de buscar por menções ao meu nome de usuário. Fiz essa busca e achei interessante ver antigos tweets de amigos, conhecidos e desconhecidos.

Caso você tenha Twitter ou já tenha tido, sugiro essa experiência: busque pelo seu nome de usuário. Você fará uma rápida viagem no tempo. Se quiser ver como foi a minha, clique aqui!

Orientação a objetos == trabalho em equipe

Hoje, durante o banho, concluí algo que achei interessante o suficiente para vir escrever aqui no blog.

Código bem orientado a objetos é igual a trabalho em equipe. Cada classe faz uma pequena parte do trabalho e nenhuma é mais importante do que as outras. Juntas é que são poderosas; sozinhas, não são grande coisa.

Código sequencialzão é exatamente o oposto. É igual a trabalho individualista. As classes/funções fazem muita coisa, sabem muita coisa, carregam muito peso. E têm dificuldade de interagir. Sozinhas é que são poderosas; juntas, não são grande coisa.

Ministro a disciplina de Programação Orientada a Objetos e percebo que muitos alunos têm dificuldade de entender conceitos como herança, polimorfismo, coesão e acoplamento. Eles às vezes acham essas coisas meio complicadas. Ao implementar novas funcionalidades em um sistema, em vez de repensar a estrutura, preferem escrever mais linhas de código nos métodos já existentes. E, assim, surgem vários novos comandos if, else e new, aumentando complexidade e acoplamento.

Quando você faz software no mundo real, você nunca faz tudo sozinho. Em vez disso, usa a biblioteca-padrão e/ou bibliotecas externas, troca ideias com os colegas, adota padrões de design

É por isso que orientação a objetos é importante. Vale a pena o trabalho extra de criar interfaces, injetar dependências, reduzir acoplamento, aumentar coesão e usar padrões? A resposta geralmente é… SIM! Porque, no mundo real, a gente trabalha em equipe. Mesmo que essa equipe seja apenas você, sua linguagem de programação e seu framework web. Já será o suficiente para precisar de uma divisão do trabalho. E, para dividir o trabalho no código, nada melhor que interfaces, coesão e padrões de design.

Trabalhar em equipe desonera os indivíduos, mas onera a integração. Código sequencialzão é difícil de manter, mas é fácil de escrever. Tudo tem seu preço, assim na Terra como no software.

(Alguma semelhança com a discussão “microsserviços x arquiteturas monolíticas”?)

Menino pensando nele mesmo quando for grande

O que você quer ser quando crescer?

Muita gente vê televisão, acha sensacional e pensa: “Eu quero ser ator!”. Muita gente vê um pianista tocando e pensa “Eu quero ser músico!”.

Mais recentemente, entrou em moda a profissão de computeiro. Com isso, muita gente que gosta de computador, celular e/ou tablet andou pensando “Eu quero ser programador!”.

Talvez tão velho quanto o mundo, esse fascínio pela profissão alheia é natural, até certo ponto. Espelhamo-nos em alguém ou alguma coisa.

Porém, vale a pena lembrar que, quando você vê um profissional atuando, você está vendo apenas a ponta do iceberg. Para ele conseguir fazer aquilo que ele está fazendo agora, do jeito como ele está fazendo agora, provavelmente ele passou muitas manhãs, tardes e noites de sua vida estudando e praticando. Se você presenciar um momento de estudo de um músico experiente, talvez até ache legal ouvir o que ele toca. Agora, experimente ouvir um músico iniciante estudando. Em geral, tende a ser horrível! Notas falhando, falta de ritmo, de dinâmica… É um longo caminho até a proficiência, e esse caminho pode ser agradável ou desagradável (normalmente, é uma mistura dos dois).

Na hora de escolher uma profissão, não adianta só ver o que a pessoa faz e achar legal. Meu pai costuma dizer que você deve observar o tipo de vida que a pessoa leva. O que faz um músico? No palco, ele toca peças completas, bonitas etc. Em casa, ele estuda e pratica, diariamente. Além disso, é possível que ele tenha que buscar trabalho continuamente, já que poucos músicos têm contrato fixo de trabalho. Se você gostar de tocar, e também gostar de estudar e praticar música, e também gostar dessa busca por trabalho, beleza! Talvez você goste dessa carreira. Se não, se você gostar apenas da ideia de tocar uma peça completa e não gostar do resto, esquece! O pacote vem completo, não tem muito como ficar escolhendo só as partes interessantes.

Um desenvolvedor de software não faz apenas o tablet falar, mostrar luzinhas coloridas e facilitar a vida de milhões de pessoas (eu até tenho dúvidas sobre essa última parte). Ele gasta boa parte do seu tempo escrevendo caracteres preto-e-verde num terminal, que muitos considerariam sem graça. Ele gasta boa parte do seu tempo fazendo uma coisa de outro mundo: pensando. Você não vê ele fazendo isso. Vendo de fora, não dá para ter muita noção de quanto esforço mental é necessário para chegar-se àquelas simples e visuais luzinhas.

O mesmo ocorre com o escritor, o cabeleireiro, o executivo, o faxineiro, o investidor, o governante… Você já passou pela situação em que alguém falou mal da sua profissão? Você já ouviu alguém achando que sabe como é viver a sua vida, e, na verdade, não sabia nada? Então… Evite cair no mesmo erro. Cuide para respeitar a vida e a profissão alheia.

Aula de TDD

Quais exercícios para estudar TDD? (ou: Minicurso de TDD no Open Sanca)

Quais exercícios são bons para começar a estudar TDD? Essa dúvida paira na cabeça de muitos estudantes e professores!

Se você for professor, eu sugiro fortemente: escolha alguns exercícios, resolva-os você mesmo e veja o que acha. Só mesmo resolvendo um exercício é que você consegue ter noção de se ele é apropriado ou não para passar aos alunos!

No dia 17/10/2015, ministrei um minicurso de TDD num encontro do grupo Open Sanca, em São Carlos-SP. Foi muito legal! Dificilmente, pessoas que não conhecem TDD se dão bem com a técnica nas primeiras tentativas. Mas, dessa vez, senti que o pessoal realmente conseguiu isso nas apenas 4h de minicurso.

Resolução de problema de TDD em grupo
Pessoal firme no dojô

Os exercícios que eu preparei foram estes e fizemos alguns poucos dessa lista. Normalmente, não sou muito fã de exercícios viajados e pouco práticos, como o FizzBuzz. Mas, recentemente, concluí que esse tipo de exercício pode ajudar a entender a mecânica do TDD, porque é fácil manter o foco no processo, em vez de no problema. Ajuda muito quando o estudante é mais iniciante. Não foi o caso desse encontro, em que a maioria das pessoas já tinha experiência profissional com desenvolvimento de software. Por isso, esse exercício não foi necessário. Mas essa questão desperta a seguinte reflexão:

Mecânica ou motivação: qual é mais importante, especialmente em um minicurso? Esse é um grande dilema ao ensinar TDD. A técnica é muito legal para problemas complexos, mas também é muito estranha à primeira vista. Para facilitar o entendimento da mecânica (ex: ciclo vermelho-verde-refatora), o professor normalmente passa um problema simples (ex: FizzBuzz). E aí o uso de TDD parece totalmente descabido, porque o problema é muito simples… Em outras palavras, ou você motiva bem, ou você facilita o entendimento da mecânica. É preciso fazer a balança pender para um dos lados. Com o tempo e mais exemplos, inverte-se a balança algumas vezes e aí o pessoal consegue obter as duas coisas.

Para você determinar que exercício é mais adequado, faça-se as seguintes perguntas:

  • Qual é o público-alvo? Alguém experiente em programação? Alguém iniciante?
  • É mais importante ensinar a mecânica (entender como funciona) ou motivar o estudo (apresentar os benefícios)?
  • É mais importante ser realista e detalhado, ou didático e menos detalhado?
  • Quanto tempo se tem disponível? 1h? 2h? 4h?

O exercício do intervalo eu recomendo ser feito quando houver, no mínimo, 2h disponíveis. Ele parece simples, mas não é, exige muito raciocínio. O da busca incremental eu acho bem elucidativo e bem realista. Porém, adote-o somente se quem for resolvê-lo tiver bastante familiaridade com manipulação de listas. Senão, a pessoa pode se perder (o oposto do objetivo do TDD!). O fraseador de itens é realista (tirei de um projeto real de que participei), porém tem vários pequenos detalhes, podendo complicar o entendimento e/ou a implementação.

Resumindo, não tem segredo! Determine suas prioridades, experimente os exercícios que achar mais interessantes e mande ver!

Você pode consultar o material do minicurso aqui. Fique à vontade para usá-lo como quiser, peço apenas a gentileza de dar os devidos créditos.

E você? Já teve dúvidas quanto ao estudo de TDD? Quais foram suas experiências?