Framework: você REALMENTE sabe o que é isto?

Recentemente retomei meu contato com o Angular: está sendo uma experiência muito enriquecedora pois a imagem negativa que tinha da ferramenta recebeu um significativo upgrade. Li uns 90% de toda a sua documentação oficial (incluindo este livro incrível) e o que posso dizer é: que framework maravilhoso! Mas o que é um framework?

Um post atrasado no mínimo uma década

Meu primeiro contato com o termo “framework” foi quando comecei a aprender Java. Naquela época (1996, 97, bem mais em 2001, 2002) muito se falava a respeito de frameworks, especialmente após o lançamento do Struts.  Confesso que não conseguia entender direito o significado do termo, e não é pra menos. Vejam o que me diziam na época a respeito:

  • “Framework é uma aplicação pré-pronta”.
  • “É um conjunto de códigos que você pode reaproveitar em seus projetos e que te poupa muito tempo”.
  • “É uma solução pré-pronta para problemas recorrentes”.

Mas e uma “biblioteca”? Ela também não é um conjunto de códigos pré-prontos que eu posso reutilizar?

Se existem estas duas palavras: bibliotecaframework, seriam estas sinônimos? Se sim, por que veio depois este termo, framework? Será que eu o descobri posteriormente e que o mesmo sempre existiu (sim)?

Não são sinônimos e hoje, após trabalhar com diversos sistemas que não foram escritos por mim posso dizer algo com plena segurança: boa parte do software que temos dificuldade em manter hoje é mal escrito devido à má compreensão do termo “framework”.

O que é uma biblioteca?

Primeiro é importante saber aquilo com o qual as pessoas costumam confundir o framework: a biblioteca. Esta sim é um conjunto de códigos reutilizáveis que vão se apresentar sob a forma de funções, classes, módulos…

Seu código invoca sua execução e como consequência o trabalho pesado é realizado para você. Vamos a alguns exemplos práticos. O código a seguir, escrito em Java (extraído daqui) usa as bibliotecas de compressão da linguagem para gerar um arquivo zip.

package com.mkyong.zip;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class App 
{	
    public static void main( String[] args )
    {
    	byte[] buffer = new byte[1024];
    	
    	try{
    		
    		FileOutputStream fos = new FileOutputStream("C:\\MyFile.zip");
    		ZipOutputStream zos = new ZipOutputStream(fos);
    		ZipEntry ze= new ZipEntry("spy.log");
    		zos.putNextEntry(ze);
    		FileInputStream in = new FileInputStream("C:\\spy.log");
   	   
    		int len;
    		while ((len = in.read(buffer)) > 0) {
    			zos.write(buffer, 0, len);
    		}

    		in.close();
    		zos.closeEntry();
           
    		//remember close it
    		zos.close();
          
    		System.out.println("Done");

    	}catch(IOException ex){
    	   ex.printStackTrace();
    	}
    }
}

FileOutputStream, ZipOutputStream, ZipEntry, FIleInputStream são classes disponibilizadas pela biblioteca padrão do Java SE. Observe algo interessante: eu simplesmente as importo e, na sequência, meu código define quando estas serão executadas e como.

É possível criar novas sub-classes baseadas nestas que acabei de mencionar, entretanto alguns aspectos se mantém:

  • Estou usando código pré-existente que não foi escrito por mim.
  • Meu código está definindo quando usarei estas classes/funções.

Outro exemplo bem simples podemos ver no código C escrito a seguir:


#include <stdio.h>

int main(void) {
  printf("Aqui de buenas usando a função printf");
  return 0;
}

Agora ao invés de classes estou importando a biblioteca de I/O clássica da linguagem C e, na sequência, reaproveito a função printf, disponibilizada por esta. E novamente o fluxo do meu programa é definido inteiramente por mim: imprima este texto inútil e na sequência retorne 0.

Então vamos à definição Kiconiana de uma biblioteca: código escrito por terceiros focando o reuso e cuja ordem de execução é definida inteiramente por você.

E o framework, o que é?

É uma aplicação semi pronta? Sim, mas esta é uma definição muito vazia (bibliotecas também podem ser consideradas como tal). É um conjunto de código que posso reaproveitar? Óbvio, mas também é uma descrição incompleta e ainda gera confusão em relação ao termo biblioteca. É uma solução para um problema recorrente? Também. Então, qual a diferença?

O significado fica mais claro quando pensamos na tradução do termo para o português: framework pode ser traduzido como molduraarmação. Imagens surgem em minha mente:

isto é uma moldura

Isto é um vigamento, que também é chamado de armação

e esta é uma armação de óculos

Armação, vigamento e moldura: o que tem em comum? Me lembro de ficar um bom tempo me questionando a respeito. Framework: por que este termo? O que isto tem a ver com moldura???

A moldura existe para suportar a gravura/imagem, o vigamento para que as telhas ou piso possam ser incluídos acima de si e a armação dos óculos fornece a estrutura necessária para que as lentes possam estar bem posicionadas em relação à nossa face. E o framework?

Enquanto no caso da biblioteca o ciclo de vida do nosso código é de nossa responsabilidade, ao lidamos com o framework o contrário ocorre: nós fornecemos a gravura para a moldura, o piso para o vigamento e as lentes para a armação.

Não somos nós que definimos quando nosso código executa: quem define isto é o framework. Se você já trabalhou com Spring ou Angular talvez isto lhe soe familiar. Lá vai: frameworks nada mais são que a aplicação mais básica do conceito de inversão de controle.  A propósito, o Martin Fowler tem um texto muito bom sobre isto.

Vamos a um exemplo bem simples baseado em Angular? Imagine que eu queira escrever um componente: então escrevo algo similar ao código a seguir usando TypeScript:


@Component({
  selector: 'login',
  templateUrl: './login.component.html',
  styleUrls: ['./login.component.css']
})
export class LoginComponent implements OnInit {

  credentials: Credentials;

  constructor(private usuarioService: UsuarioService) { 
    this.credentials = new Credentials(null,null);
  }

  ngOnInit() {
  }

  entrar() {
    this.usuarioService.auth(this.credentials);
  }

}

Aquela função ali, ngOnInit, não sou eu quem a invoco: é o Angular. Repare: apenas forneço os músculos para este esqueleto. Eu sei que aquele método será invocado, mas não por mim. Em momento algum escrevo código como o exemplo a seguir:

usuarioService = new UsuarioService();
login = new LoginComponent(usuarioService);
login.ngOnInit();

O código acima é aquele que tipicamente escrevemos ao lidar com bibliotecas. Mas o que ganhamos com esta delegação? Será que minha função realmente será chamada?

Lembra quando mencionei que sim, frameworks são soluções para problemas que ocorrem com frequência e que também são aplicações pré-prontas, mas que vão além? Pois bem: o problema que todo framework resolve é essencialmente o ciclo de vida do nosso código.

Autores de frameworks se preocupam com a vida de nossos objetos/funções: quando devem ser criados, usados e destruídos. E isto de uma forma ótima, garantindo que nosso trabalho consista apenas em fornecer o conteúdo necessário para que nossas necessidades de negócio sejam atendidas.

Vamos a mais um exemplo: desta vez usando a API Servlet do Java. Um Servlet pode ter diversas formas, a mais comum é o HTTP que tem como objetivo receber requisições pelo protocolo (HTTP), executar nossas regras e, finalmente, retornar conteúdo ao usuário final da aplicação. Vamos implementar um servlet?

package br.com.kicosoft;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ServletDemo1 extends HttpServlet{
	
	public void doGet(HttpServletRequest request, HttpServletResponse response)
	throws IOException{
		PrintWriter out = response.getWriter();
		out.println("<html>");
		out.println("<body>");
		out.println("
<h1>Sou um servlet feliz!</h1>

");
		out.println("</body>");
		out.println("</html>");	
	}
}

Primeiro eu escrevo a minha classe, que extenderá uma outra chamada HttpServlet. Meu papel consiste apenas em sobrescrever os métodos HTTP que me interessam, no caso, doGet, que corresponde ao método GET do protocolo. Minha função define o que deverá ser retornado ao usuário: o conteúdo HTML que você vê em meu código.

Repare na riqueza: não preciso me preocupar em implementar o protocolo HTTP, ou mesmo um algoritmo de espera (ocupada ou não) de requisições que chegam ao meu servidor. Apenas forneço ao meu framework o código que desejo ser executado.

Então, como posso definir um framework à moda Kiconiana? É o maestro responsável por orquestrar seu código visando resolver um ou mais problemas específicos .

O problema específico pode ser a construção de uma aplicação web, uma integração (pense em Apache Camel implementando os Enterprise Integration Patterns), um jogo (pense em um engine como o Unity). Seu papel é portanto apenas fornecer o código que será executado pelo framework. O que nos leva à grande questão.

Frameworks são burocráticos

Lembra no início deste post quando disse que boa parte do código mal escrito que vemos hoje tem como principal problema o fato de haver uma má compreensão a respeito do termo “framework”? O problema nasce quando ignora-se este fato: frameworks são burocráticos.

O termo burocracia tem uma conotação bastante negativa mas é um fato necessário para que haja ordem, para que se consiga formalizar a identificação de elementos.

(Sabia que a escrita nasce de uma necessidade burocrática? Dica: pesquise sobre a origem da escrita cuneiforme e os sumérios.

Lembre: burocracia é uma coisa, burrocracia, outra.)

A literatura nasce de um hacking da burocracia. Pense nisto!

Imagine que você irá escrever um framework: seu papel é orquestrar a execução de código de terceiros, certo? Como você o identifica este código e o papel a ser desempenhado por este? Alguma formalização precisa ser posta em prática, o que ocorrerá através da definição de padrões, tais como:

  • Presença de arquivos de configuração que identifique os artefatos. Lembra do XML no Java ou Spring?
  • Inclusão de anotações em nosso código. Olha ali o meu exemplo usando Angular e a anotação @Component.
  • A implementação de uma interface ou extensão de classes (lembra do meu Servlet?).
  • Padronizações no código como, por exemplo, a definição de nomes padrão para eventos de ciclo de vida dos objetos (já viu Tapestry?).
  • Qualquer outro dispositivo que sirva para marcar o papel desempenhado pelo código a ser orquestrado.

O principal problema que encontro em código legado é justamente este: quem o evoluiu não se esforçou o suficiente para conhecer o framework adotado na escrita do projeto. E ainda pior: usou esta “moldura” como se fosse uma biblioteca, desrespeitando completamente o ciclo de vida proposto por esta.

Sabe aquele sujeito que sempre “dá um jeitinho” na burocracia cortando caminho? É o programador que usa o framework como biblioteca e ferra a gente no futuro.

Frameworks são limitados

Assim como o termo burocracia, a palavra limitada também tem uma conotação negativa em nossa sociedade, mas infelizmente é verdade: frameworks são limitados (e tem de ser). Aqui nasce outro problema que encontro em muito código legado.

Lembra que na definição Kiconiana menciono o fato do framework visar resolver um ou mais problemas específicos? Pois é: meu framework web favorito é o Grails, mas não o uso para implementar integrações.

Apesar de 90% do código que vejo ser escrito hoje visar resolver o problema da construção de aplicações web (ou web services, micro-serviços), este não é o único problema computacional a ser resolvido.

Talvez você precise escrever uma automação residencial (HomeKit da Apple), ou quem sabe uma integração (Apache Camel), talvez seja a implementação de um jogo de tiro em primeira pessoa (Cry Engine). Posso ficar um bom tempo aqui com exemplos.

O importante é: muitos dos problemas que encontro são resultantes da má escolha do framework para aplicações distintas do seu propósito original. Isto deve ser levado em consideração. Nem tudo é uma aplicação web, e desconfio de gente que diz ser capaz de resolver qualquer problema usando um único framework.

O que a armação, a moldura e o vigamento tem em comum? Eles limitam a forma do que irão orquestrar.

Concluindo

Estudando o Angular (6) fiquei maravilhado com o modo como ele organiza meu código fonte e orquestra a sua execução, o que me fez voltar ao conceito de framework e, na sequência, finalmente liberar este post.

Resumindo, digo que você deve evitar as seguintes armadilhas ao escrever seu código:

  • Saber se precisa realmente de um framework ou de uma biblioteca (em 95% das vezes usará os dois no mesmo projeto).
  • Saber como usar uma biblioteca e, principalmente, um framework.
  • Buscar entender as formalizações definidas pelos autores do seu framework (poderíamos falar o mesmo a respeito de bibliotecas: pense em OpenGL).
  • Entender para qual fim o framework foi escrito e usá-lo apenas para este fim.
  • Resumindo o resumo: você deve respeitar o framework.

Infelizmente (ou felizmente?) não se discute com tanta ênfase hoje o significado dos termos biblioteca e framework. Talvez pelo fato de terem se tornado ubíquos para nós com o passar do tempo, o que mostra termos evoluído (e muito) de lá pra cá.

Mais uma vez o Wittgenstein estava certo: a maior parte dos problemas surge da má compreensão da linguagem.

Ludwig Wittgenstein – 1889 – 1951

Podcast da itexto

Um projeto razoavelmente antigo finalmente foi pro ar hoje: é o Podcast da itexto. O objetivo é divulgar algumas das conversas que temos no escritório (na realidade, é uma volta às conversas, pois é gravado na hora), conversas estas que sempre achei que deviam ser públicas mesmo, por que sempre surgem ideias bem interessantes.

Então achamos um modelo inicial, que é a gravação sem cortes ou edição: apenas nós, conversando e gravando. Estamos aprendendo ainda como é que se faz isto, por isto com certeza quem está acostumado a ouvir podcasts irá encontrar alguns erros. Entretanto já detectamos alguns e para a próxima vez já serão evitados.

A quem se interessar, segue o site do projeto: http://www.itexto.com.br/podcast 

Há também o nosso feed no SoundCloud, que você pode acessar aqui. Em breve já vai estar disponível no iTunes e outras mídias também, vou atualizando vocês por aqui.

Espero que gostem, toda sugestão é bem vinda!

Novos projetos para a comunidade: meetups e mais uma mailing list

Com o crescimento da Itexto estou podendo voltar a me dedicar a antigos projetos que tinha e não conseguia tirar do papel: este post é pra divulgar estes projetos. Conto com a participação de vocês!

Nova mailing list voltada para desenvolvedores Groovy, Grails e Spring

Algum tempo atrás havia criado a mailing list “Semana Groovy”. Foi um projeto bem sucedido por algum tempo, porém, devido à minha agenda acabou indo para o segundo plano e, posteriormente, acabou terminando.

Então, dado que temos mais uma comunidade agora, que é o Spring Brasil, achei que seria interessante unir estas duas turmas (Groovy/Grails e Spring) que, apesar de distintas, possuem muita coisa em comum (na realidade, é como se fossem a mesma, só não sabem ainda disto).

Para unir estas duas comunidades criei uma nova mailing list: Mundo Groovy/Spring, unindo todos os membros das duas comunidades, o que soma mais de 2700 membros hoje.

A ideia é a mesma: divulgar eventos, bons posts, apresentações e notícias relacionadas a estas tecnologias. Se você já é membro do Groovy e Grails Brasil ou Spring Brasil, já participa destas mailing lists automaticamente. Caso contrário, basta preencher o formulário abaixo.

Inscreva-se na lista “Mundo Groovy/Spring”!

Meetup Spring, Groovy e Grails em BH

Este já é um projeto local: já estamos coletando ideias para nossas primeiros encontros. Neste momento estamos apenas coletando participantes que queiram se juntar a nós, ao vivo, aqui em Belo Horizonte.

No primeiro momento os encontros serão presenciais, entretanto já estamos planejando alguns hangouts também. Conto com a participação de vocês.

Link para o meetup? Clique aqui.

Conto com a participação de vocês!

PS: sobre meu último post: “Quem nos forma está nos deformando?”

Um número muito grande de pessoas vêm me procurando em off a respeito do meu último post, no qual começo a relatar as consequências da degradação do ensino acadêmico.

Ainda não exauri o assunto: esta semana exponho algumas consequências reais, não apenas em TI, mas em outras indústrias também.

Quem nos forma está nos deformando?

Vivemos um período histórico no mínimo curioso: pela primeira vez vejo as pessoas discutindo mais política que a copa do mundo (o que me deixa otimista). Há uma polarização forte que me lembra muito um livro genial da Ruth Rocha: “Dois idiotas sentados cada qual no seu barril…”

Li muito pequeno, foi escrito na época da guerra fria e a ideia era mostrar a situação para as crianças. Resumindo: são dois idiotas (representando EUA e União Soviética), cada qual sentado sobre seu barril (cheio de pólvora), cada um segurando sua vela acesa. É o tempo inteiro um provocando o outro, as provocações se tornam ameaças e finalmente a merda acontece e os barris explodem gerando uma tragédia de causa ridícula.

O problema que tratarei aqui se enquadra no mundo pós-boom: em vez de velas temos uma formação técnica deficitária que durou décadas e os destroços são a mão de obra resultante do processo.

A situação que vou descrever vivo como empresário em um contexto muito bem definido: a contratação de desenvolvedores em Belo Horizonte. Entretanto sei que é um caso que ocorre também em outras cidades e áreas distintas (engenharia, medicina…).

Este post não visa dizer que os desenvolvedores de Belo Horizonte são ruins (pelo contrário), mas sim lançar um alerta a respeito da rápida deterioração da qualidade do ensino acadêmico que venho observando já faz algum tempo.

Meu “primeiro” contato com o problema

Quando você se torna empresário sua visão de mundo sofre mudanças muito profundas: um dos meus primeiros choques ocorreu no primeiro processo seletivo da Itexto realizado em 2015. Tivemos um número muito grande de candidatos e destes, selecionamos 20 (hoje selecionamos bem menos) para que viessem conversar conosco e realizar uma prova técnica.

Eu sei que trabalhar na Itexto é mais difícil que nos outros lugares por sermos uma empresa cuja principal tecnologia é a Ciência da Computação e não tecnologias de mercado como Java, C#, etc. Sendo assim nossa prova técnica se baseia nestes princípios, mas não é uma prova muito difícil: nesta primeira prova havia a seguinte pergunta.

O que é uma estrutura de dados? Cite duas.

Destes 20 candidatos, 100% já haviam cursado as matérias de Algoritmos e Estruturas de Dados. Esta é uma questão banal para este público, sendo assim qual foi o resultado final? 90% não souberam responder. Sim, você leu certo: 90% não soube responder nem citar o nome de sequer UMA estrutura. Como assim você não se lembra do nome daquilo que te deu bomba?

Naquele primeiro momento como éramos uma empresa muito pequena, achei que havíamos tido azar e apenas aqueles que foram reprovados em todos os processos seletivos chegaram a nós, ou mesmo que a prova fosse muito difícil. Sendo assim mandei a prova para alguns amigos e todos a acharam bastante razoável, simplista até.

A situação se repete e as reminiscências surgem…

Passado o primeiro processo seletivo, veio o segundo, terceiro, quarto… E em todos a mesma pergunta, o mesmo resultado. Isto me fez lembrar de quando aplicava processos seletivos em outras empresas de desenvolvimento mostrando o problema do fizz-buzz e uma quantidade ínfima de pessoas conseguia resolver. Conhece o problema?

Neste problema, você deverá exibir uma lista de 1 a 100, um em cada linha, com as seguintes exceções:

  • Números divisíveis por 3 deve aparecer como ‘Fizz’ ao invés do número;

  • Números divisíveis por 5 devem aparecer como ‘Buzz’ ao invés do número;

  • Números divisíveis por 3 e 5 devem aparecer como ‘FizzBuzz’ ao invés do número’.

Se você se diz programador e não consegue resolver este problema, você não sabe o que é programar (um post antigo do blog Coding Horror, lá dos EUA, fala da mesma dificuldade: programadores que não sabem programar).

Caramba… as pessoas não conseguem resolver um fizz buzz… e também não sabem o que é uma estrutura de dados… mas se dizem programadoras. E sabe o que achei mais interessante? A esmagadora maioria destas pessoas tinha BOAS NOTAS na faculdade. Então… por que não sabem o básico? Seria eu uma pessoa muito exigente ou assustadora?

Resolvi investigar

Tivemos a sorte de nestes processos seletivos encontrar pessoas maravilhosas que vieram a trabalhar conosco. E dentre estas estavam nossos estagiários: neste caso não saber ao certo o que é uma estrutura de dados se enquadra como uma situação “normal”, dado que estão dando os primeiros passos na arte.

E temos estagiários que vieram tanto de faculdades públicas quanto privadas. Então resolvi fazer algo que nunca vi ser feito: acompanhamento acadêmico. Achei que seria uma boa ideia (e foi) ajudar nossos estagiários na faculdade: desde suporte na escrita dos trabalhos de conclusão de curso até mesmo tirar dúvidas a respeito das matérias que viam na faculdade. E aí a coisa começou a se mostrar realmente interessante.

Pra começar as matérias que deveriam fornecer a teoria essencial não forneciam porra nenhuma. Vamos a alguns exemplos: o tema “programação orientada a objetos”. Você espera que te ensinem o que é um objeto, uma classe,  o que é herança, por que diabos existe programação orientada a objetos, coisas assim, certo? Então por que o aluno começa o curso aprendendo coisas como… Spring Framework??? E apenas… Spring Framework??? (e saem sem saber o que é Inversão de Controle, mesmo sabendo que existe algo chamado Spring…)

Matérias como “Desenvolvimento web”. Você espera começar entendendo o fundamento da coisa, certo? O que é o protocolo HTTP? Qual a arquitetura essencial de uma aplicação web? Quais as camadas que uma aplicação web pode ter? Coisas assim, certo? Então por que o aluno está aprendendo Grails??? E apenas… Grails??? Ou apenas Servlets? Ou PHP? Ou ANGULAR??? 

A matéria é “Banco de dados”. Ok, você pensa em como a informação é organizada, o que vêm a ser uma base de dados, coisas assim, certo? Então por que o aluno só aprende SQL com SQL Server, Oracle ou MySQL??? O aluno sai achando que só existe base de dados relacional e, numa boa? Sequer sabe o que é uma base de dados: sabe que existe o Oracle.

Resumindo: as ferramentas que deveriam ser coadjuvantes do conteúdo se tornam protagonistas. Você não deveria aprender Java com Orientação a Objetos, mas sim Orientação a Objetos usando exemplos em Java.

“Nós preparamos o aluno para o mercado”

A justificativa que ouvi de alguns professores foi a de que você prepara seu aluno para o mercado, por isto a ênfase nas ferramentas. Isto seria razoavelmente justo se estivéssemos em uma área na qual as ferramentas fossem quase eternas, tal como ocorre na carpintaria, mas em desenvolvimento de software este não é o caso, pelo contrário.

(não entendo nada de marcenaria, sendo assim talvez o exemplo tenha sido ruim)

Entra aqui algo que deveria ser pesado pelos educadores: o conhecimento de curto, médio e longo prazo. Conhecer uma linguagem ou framework é conhecimento de curto prazo, agora, conhecer a teoria é de longo prazo, é o conhecimento que realmente vale à pena, que te prepara para qualquer coisa que surja. Mas como você tem de gerar mão de obra rápido para as empresas que podem estar financiando sua instituição, o que você faz? Que se foda o aluno, precisamos de programadores Java para que continuem nos financiando, não é mesmo?

E neste caso, se a ênfase está sendo dada nas ferramentas e não na teoria, estas faculdades de fato poderiam ser chamadas de faculdades? Afinal de contas está no cerne da ideia do curso superior a obtenção do conhecimento geral de longo prazo, não de curtíssimo tal como mencionei. Não deveriam ser na realidade caracterizadas como cursos especializantes?

Me impressiona a miopia destes “educadores”.

A grande sacanagem

Um questionamento que poderia e deve ser levantado é: qual a responsabilidade do aluno em sua própria formação? Por muito tempo tive uma visão bastante maniqueista a este respeito: eu realmente achava que a maior parte da responsabilidade era do aluno, porém hoje vejo que é a menor.

E a razão é muito simples: há uma quebra de confiança no processo de formação. Quando você entra em um curso superior é esperado que aqueles que lá lecionam sejam competentes. Afinal de contas trilharam um caminho que os colocou naquele lugar. Então o que o aluno faz? Simples: ele confia e, normalmente admira aquele que lhe ensina. E esta admiração faz parte do processo de educação (você dificilmente leva a sério aqueles que detesta).

E aí vejo as pessoas que não são reprovadas na faculdade, mas saem dela sem saber o básico. O que ocorreu ali? Como pode a pessoa terminar o curso de Ciência da Computação e não saber resolver um fizz-buzz? Estas pessoas são vagabundas? Não: são pessoas que ralam horrores, ficam horas no transporte público, economizam pra pagar a faculdade (faculdade pública também tem custo, e alto).

São pessoas que normalmente estão no curso superior graças ao esforço de gerações passadas, que conseguiram acumular capital para lhe proporcionar esta melhor educação. E aí eu penso: pqp, um esforço geracional jogado no lixo. Sim, no lixo, por que não raro o indivíduo vai pro mercado de trabalho, percebe que não sabe nada e desiste da área.

Na minha opinião um dos papeis da faculdade é te incentivar a sair da área se não for a sua praia, e isto se dá através da reprovação. Agora, se você não é reprovado, como saber se realmente é bom na coisa?

(quis ser músico uma época e depois percebi que não era a minha: foi uma das melhores coisas que poderiam acontecer pra mim. Como percebi? No teste vocacional pro curso de Violão Clássico.)

Na boa? Vi algumas faculdades que mereciam ser processadas por propaganda enganosa.

Então o que a faculdade deveria ensinar?

Resumindo:  a pesquisar. Ao sair da faculdade você não é especialista naqueles assuntos, mas ao menos sabe do que se tratam ou mesmo que existem. O aluno tem de, terminado o curso, ao se deparar com uma tecnologia nova, conseguir ligar os pontos essenciais: entender a que categoria a ferramenta se aplica, onde pode buscar maiores informações a respeito.

E o que me impressiona é que as pessoas saem da faculdade sem saber fazer isto. Vejam o diálogo que tive em um dos nossos processos seletivos com um aluno formado na UFMG:

_ Como você faz para pesquisar sobre um assunto?
_ Pesquiso no Google ou StackOverflow.
_ Só isto?
_ É.

Repare: você tem de saber o que é uma fonte primária pelo menos. Tem de saber escrever, tem de saber ler, tem de entender uma bibliografia pra poder buscar a compreensão do que vai tratar.

Mesmo por que para que você possa fazer qualquer pesquisa, é necessário saber quais termos usar, ou seja, a faculdade essencialmente serve para lhe fornecer vocabulário.

Se você saiu da faculdade e só consegue aprender via Google ou busca no StackOverflow ou Medium, tenho uma má notícia: seu curso talvez só tenha servido pra conhecer uma galera legal e nada mais (escrevi sobre isto tempos atrás aqui).

Mas a formação não se limita à faculdade

E aqui entra um outro ponto: a formação vai muito além do curso superior/técnico. Entra aí os eventos dos quais você participa, os livros que lê, as palestras que assiste. E dado que hoje é tudo tão voltado para o “preparo mercadológico”, não me admira que livros tão ruins estejam saindo no mercado (escrevi a respeito aqui e aqui).

Mas como o aluno que tem uma formação tão deficitária consegue avaliar se o material que tem em mãos é bom ou ruim? Prova de que a esmagadora maioria do material que chega a nós é ruim está no fato de pouquíssimos livros atualmente escritos apresentarem sequer uma bibliografia, ou seja, o autor possivelmente SEQUER estudou antes de publicar aquele trabalho.

Este é o lado negativo da popularização da mídia: qualquer um pode publicar, e o leitor, mal formado, não consegue avaliar ao certo o que vale ou não à pena consumir.

Sendo assim temos aqui um problema de formação em dois níveis:

  • No mundo acadêmico (e entra aqui a formação básica também).
  • No mundo extra-acadêmico (que é o que consumimos fora das instituições de ensino).

E por que o material extra-acadêmico é ruim? Adivinha: por que pra gerar conteúdo de qualidade, profundo, bem fundamentado, você precisa ter uma boa… formação. Não: só a prática não te torna um profissional excelente.

O que deve ser feito

Sabe estas matérias que pipocam por aí dizendo que há inúmeras vagas para TI? Estas vagas realmente existem, mas não são preenchidas por que a formação é ruim e portanto não se encontra com facilidade bons profissionais. E não, adquirir esta formação não é fácil ou barato.

Então sabemos que há uma crise de mão-de-obra (isto sem mencionar as pessoas que estão deixando o Brasil), sabemos também que a qualidade do ensino está ruim. O que devemos fazer?

Na minha opinião questionar tudo: acompanhar as avaliações do ENADE (questionar o próprio ENADE), evitar instituições com notas baixas e, mais importante: realizar a mesma investigação que mencionei acima. Peça para que seus estagiários lhe mostrem o que estão aprendendo nas escolas. Verifique se as pessoas que estão saindo conseguem escrever (sei, por exemplo, de diversos casos de estagiários de Direito que não conseguem ESCREVER ou LER).

(você só sabe alguma coisa se consegue descrevê-la em palavras que possam ser compreendidas por um terceiro)

Questione: aquele aluno tem problemas de aprendizado? Ou estaria sendo mal guiado? Claro: o aluno tem de correr atrás, mas quem deve ser o guia inicial é o mestre, não o aluno (caso contrário não faria sentido existir a escola (este livro é muito interessante e fala sobre isto)).

Décadas atrás o Devo veio com o conceito de “de-evolution”: a ideia de que as pessoas estavam se idiotizando com o tempo. Que tal colocar na pauta atual não apenas o rotular alheio (coxinhas, mortadelas) e passarmos a prestar mais atenção ao que ocorre aqui na nossa frente?

E sabe o que ocorre se não houver mão de obra suficiente? Os projetos não sairão, e o desenvolvimento não virá, mas sim a “de-evolução”.

Isto devia ter sido olhado décadas atrás (minha formação foi inferior da geração que me antecedeu). Agora é correr atrás do prejuízo.

Minhas boas leituras de 2017

Boas tradições não devem morrer, sendo assim aqui está aquele post anual no qual conto quais foram os melhores livros que li no ano. Minhas leituras se dividiram em dois grandes grupos: leituras técnicas e alguns livros que ouvi falar a respeito muitos anos atrás cuja curiosidade resolvi satisfazer em 2017.

Leituras técnicas

High Performance Mobile Web – Maximiliano Firtman

Se você quer saber como desenvolver interfaces web focadas em dispositivos móveis com desempenho extremo este é O livro.

É simplesmente maravilhoso: você começa com uma análise do ferramental disponível (os navegadores, as ferramentas de desenvolvimento presentes nestes), passando por uma crítica muito interessante à variedade de dispositivos em que nossas aplicações podem ser executadas até que finalmente nos fornece uma série de dicas de implementação que tornam os projetos realmente muito mais eficientes.

Fazia muito tempo que um livro não me ensinava tantos truques novos. Foi maravilhoso aprender tantas coisas novas.

HTML & CSS: Design and Build Websites – John Duckett

Este é um livro que se você for comprar, terá de ser a versão física. O comprei para o pessoal iniciante da Itexto na área de desenvolvimento frontend e, numa boa? Só me arrependo de não o ter comprado ANTES. Torna todo o processo muito mais claro justamente por ser visual.

Não o vejo como um tutorial, mas mais como um catálogo visual que ilustra as diversas funcionalidades presentes tanto no HTML quanto CSS. Além disto é muito bem escrito. Dica para as editoras brasileiras: traduzam este livro!

Me impressionou muito o fato de um livro técnico poder dizer tanto com as imagens que apresenta. O mais próximo que posso te mostrar é link sobre o livro na Amazon, que tem algumas imagens. Um trabalho maravilhoso. Clique aqui e compre.

Bullet Proof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications – Ivan Ristic

Se você quer entender como funciona toda esta questão de certificados digitais, HTTPS, SSL, e cia, o livro é este. É fantástico, por que ao mesmo tempo em que apresenta estas tecnologias com um nível de detalhamento bastante aprofundado, o faz de uma forma bastante didática.

É inclusive um fato curioso: pouquíssimos profissionais DE FATO entendem como o HTTPS funciona. Vai muito além da instalação de certificados digitais e configuração de servidores. E este livro ajuda bastante nesta direção. Aliás, uma dica: existe um site da editora (Feisty Duck) no qual é possível baixar excelente material a respeito destes assuntos e que é totalmente gratuito. Segue o link.

Groovy in Action – Segunda Edição – Dierk Konig, Paul King, Guillaume LaForge, Hamlet D’Arcy, Cédric Champeau, Eric Pragt e John Skeet

Já havia lido anos atrás a primeira versão deste livro, e a segunda é uma atualização maravilhosa não só sobre Groovy, mas também sobre alguns outros astros que estão ao redor da linguagem, que ainda é a minha favorita.

Se é para indicar um único livro sobre Groovy, seria este. Claro, há o meu sobre Grails também, no qual já iniciei o trabalho de atualização para lidar com a versão 3 do framework.

O bacana deste livro é que é extremamente bem escrito: é uma leitura leve, e você não precisa ler inteiro em uma sentada. Dá para ler de uma forma completamente não linear, o que o torna uma excelente obra de referência.

Nenhum livro técnico de qualidade nacional?

Nenhum que valha à pena mencionar. Tudo o que li em português este ano de 2017 achei extremamente pobre e em alguns casos cheguei a me questionar se realmente houve um trabalho de revisão antes de serem publicados.

As mesmas críticas que fiz em 2016 se aplicaram a 2017 e vou além: a qualidade do que li piorou. Essencialmente uma série de tutoriais disfarçados de livros sem qualquer aprofundamento. Sobre estas minhas críticas, recomendo que você as leia aqui e aqui.

(pensando seriamente em fazer algo a respeito)

Livros que não falam de programação diretamente

Este ano resolvi buscar por livros sobre os quais ouvi algo a respeito no passado, deixei passar, mas cuja curiosidade continuou no decorrer dos anos. Então resolvi buscá-los e matar esta dívida literária.

Só os Paranoicos Sobrevivem – Andrew Grove

A primeira vez que ouvi falar deste livro foi em 1999, na revista Info Exame (ou PC Magazine). Se você não sabe quem é o Andy Grove, já te digo: é um dos responsáveis pelo fato da Intel ser hoje o que é, e foi o mentor de pessoas pouco conhecidas, tais como Bill Gates e Steve Jobs.

(você pode saber muita coisa a respeito da biografia do Andy Grove neste episódio (em espanhol) do podcast La Tortulia (meu podcast favorito))

O livro é sobre as mudanças repentinas que ocorrem tanto na vida profissional quanto na pessoal, e como podemos (e devemos) reagir a estas mudanças.

Grove era um excelente escritor, sendo assim a leitura é extremamente fluída, e do ponto de vista histórico, é fascinante, pois toma como ponto de partida o bug do Pentium. Quando lançado pela Intel, o Pentium era sua grande aposta, e foi descoberto um bug no modo como eram realizados cálculos usando ponto flutuante. Foi um momento de crise para a empresa, que se aproveitou da situação para dar a volta por cima e se tornar o gigante que é hoje.

(não é curioso que o mesmo esteja se repetindo agora com esta história do Meltdown nos chips da Intel?)

Foi o livro que mais me inspirou este ano: o li na versão em inglês que comprei para o Kindle. Ao buscar a versão em português nos sebos descobri que estava sendo vendido por valores altíssimos (200 Reais!).

High Output Management – Andrew Grove

“Só os Paranóicos Sobrevivem” causou um impacto tão grande em mim que passei o resto do ano lendo os livros de Andrew Grove (e também sobre ele). O outro livro que trouxe um profundo impacto para mim foi este, e a razão é simples: este foi o ano em que comecei a lidar mais diretamente com gestão e menos com desenvolvimento. Então, por que não aprender com Grove como gerenciar uma empresa?

E o livro é justamente sobre isto: sobre seu método de gestão baseado em feedback constante. É uma leitura muito interessante, e me ajudou a detectar diversos problemas que consegui tratar durante o ano.

Steve Jobs – Valter Isaacson

A famosa biografia do Steve Jobs também teve um impacto muito grande em mim este ano, mas confesso que não foi por causa do Steve Jobs, mas sim pelo seu autor. Este livro é muito interessante pelo seguinte: é raríssimo um biógrafo ter contato direto com o biografado (vivo!) durante a escrita de sua biografia, e foi justamente isto o que ocorreu aqui.

Dois fatores me encantaram no livro: o primeiro é o encantamento do biógrafo pelo biografado, o que fica gritante no livro. O esforço que Walter Isaacson faz para que Steve Jobs não fique com sua imagem manchada como um grande filho da puta chega a ser hilário durante o livro. Fica claro o conflito interno do autor: digo que este sujeito era um fulano insuportável ou o maqueio um pouco mais? Esta foi minha impressão, mesmo existindo relatos de que Steve Jobs deu carta branca ao autor (duvido).

(em uma entrevista Walter Isaacson chega a mencionar que irá queimar boa parte das gravações que fez com Steve Jobs, o que considero uma pena)

O segundo é o capítulo final que talvez seja uma das coisas mais bonitas que já li, no qual é contada a razão pela qual Steve Jobs não curtia botões de desligamento. É realmente lindo e muito sensível este capítulo.

Há um foco imenso na Apple e Pixar: acho que poderia ter falado um pouco mais sobre a NeXT, mas é uma leitura legal, eu recomendo.

Friends in High Places – Laton McCartney

Chegou para mim nas últimas semanas de 2017 e ainda não terminei, mas achei que seria interessante mencionar aqui. É essencialmente a biografia de uma empresa, não qualquer empresa, mas sim a Bechtel.

Talvez você não a conheça, mas é uma das maiores empresas de construção civil do mundo, fundada no final do século XIX e bem viva e operante até hoje. Ela está por trás das principais obras de engenharia do século XX, e este livro é justamente sobre esta história, mas mais do que isto: é a descrição do fato de que se você conhece as pessoas certas que ocupam posições privilegiadas, consegue-se qualquer coisa neste mundo.

É uma leitura fascinante, que mostra de uma forma bastante profissional como funcionam as engrenagens do poder nos EUA (e consequentemente no mundo). Como disse, ainda não terminei, mas está me impactando bastante.

Now it can be told – Leslie Groves

Este livro chegou junto com o “Friends in High Places” para mim e também não terminei, mas tem sido uma leitura que está me impactando HORRORES.

Não sou uma pessoa belicista mas confesso que o projeto Manhattan sempre me fascinou. Não conhece? Foi o projeto que resultou na bomba atômica durante a segunda guerra mundial lá nos EUA. E Leslie Groves, autor do livro, foi o general responsável pela gestão deste projeto.

E se você gosta de história este livro é um prato cheio, especialmente se levarmos em consideração o autor. Quando pensamos na bomba atômica vêm em mente Oppenheimer, que era o responsável pelo desenvolvimento científico e Groves sempre é posto de lado, como se fosse um personagem secundário, quando na realidade era bem o oposto.

Em alguns momentos Groves é inclusive retratado como um toscão. Durante a leitura fica claro que esta imagem é muito distante da realidade. Vejo aqui um gestor brilhante, que conseguiu no tempo hábil (apesar de ter gasto uma verdadeira fortuna) concluir o projeto de algo que tinha pouquíssima comprovação prática.

É fascinante ver como Groves lidava com a questão dos egos dos cientistas e, ainda mais interessante, o fato da física experimental o tempo inteiro se comprovar na prática com pouquíssima experimentação prévia.

O livro tem lá suas partes mais cansativas, pois Groves faz a descrição cronológica dos fatos, o que o torna um pouco massante nestes pontos, mas são momentos raros. No geral é uma leitura maravilhosa.

(e uma dica: o prefácio é do Edward Teller, outro monstro da física do século XX).

Leitura recomendadíssima!

Um ano de boas leituras

Em 2017 senti muita falta de bons autores brasileiros que eu pudesse colocar nesta lista. Infelizmente, tal como já mencionei, as leituras em língua portuguesa que encontrei (especialmente técnica) se mostrou muito, muito ruim. Fiquei bastante chateado com o fato da qualidade ter piorado, algo que achava não ser possível, mas para 2018 estou mais otimista.

Uma dica: comecei a ler um livro sobre JavaScript, em português, que está se mostrando promissor. Ainda não mencionarei qual é, mas comprovando sua qualidade, podem ter certeza de que escreverei um post aqui só com o review a seu respeito.

Vídeo novo no canal: gerenciando seu ambiente Java com SDKMan

Estou gravando uma série de vídeos apresentando ferramentas que não são tão conhecidas por desenvolvedores. Primeiro foi o AWK, agora é a vez do SDKMan.

Já escrevi sobre ele aqui no blog, porém achei que seria interessante mostrar seu funcionamento na prática também. Espero que gostem e que ele torne seu dia a dia mais fácil!

Segue o link: https://youtu.be/YYc_gMijhQA