Eu e o Angular

Semana passada colocamos no ar a nova versão do /dev/All que mudou radicalmente sua arquitetura (detalhes não técnicos neste link): dentre as principais mudanças está o fato de que agora a interface com o usuário é um SPA. Este é o primeiro post no qual compartilho com vocês algumas das coisas que aprendi no processo.

Note que esta é a visão de alguém que tinha como ferramenta principal para o desenvolvimento de aplicações SPA o Vue.js. Sendo assim minhas impressões em sua maior parte fazem uma comparação com ele. Leve em consideração que são “novas novas impressões” a respeito do Angular. Muita coisa pode mudar conforme minha experiência progride.

Por que não gostava

Uma das principais razões pelas quais aprendi Vue.js, confesso, foi para não usar o Angular. Além do trauma da quebra de compatibilidade da versão 1 para a 2, naquele momento ele me parecia muito mais complexo do que eu precisava. E o fato da versão 2 ser essencialmente TypeScript e não mais JavaScript também me incomodava (que ironia, eu, que amo Grails, dizer isto…). Também me incomodava horrores a documentação oficial que peguei na época: era horrível.

Eu já havia experimentado o Angular em projetos legados e, acredito, isto contribuiu também para minha péssima impressão original do framework. Vue.js era para mim como um copo d’água para quem estava no inferno. O tempo passou e acabei dominando o Vue, que se tornou até agora minha ferramenta favorita para o desenvolvimento de SPAs, aplicações híbridas e qualquer projeto que envolvesse interatividade mais rica. Até agora.

Mas o grande lance é que minha visão a respeito do Angular estava errada. Enquanto o Vue é essencialmente focado na camada de visualização (e essencialmente apenas nela), não havia ainda atinado o Angular como um framework, mas sim como uma biblioteca.

Resumindo, minha aversão ao Angular era resultado destes fatores:

  • A documentação de anos atrás que era bem ruim.
  • O trauma da quebra de compatibilidade da versão 1 para a 2 do Angular (acaba que sempre penso nos projetos a médio e longo prazo).
  • O fato de se mostrar mais complexo do que minha real necessidade na época.
  • A adoção do TypeScript como linguagem e não JavaScript.
  • Eu estar ignorando o aspecto essencial do Angular: o deste ser um framework (este doeu) para aplicações maiores.

Por que estou gostando

O que me fez realmente gostar do Angular foi criar vergonha na cara e perceber que já havia passado da hora de aprender o framework a fundo.

Chegou um dia no qual quis finalmente transformar a interface do /dev/All em um SPA e me peguei adotando o Vue.js sem sequer me questionar a respeito. Por que apenas Vue.js estava no meu radar? Era hora de sair da zona de conforto, o que me fez passear pelo React e… Angular novamente.

Um bom livro e uma melhor documentação

Dado que a documentação oficial do Angular que conhecia até então era um lixo, optei por desta vez escolher um bom livro ao invés da documentação oficial, e acertei. Comprei o “Angular in Action”, de Jeremy Wilken, publicado pela editora Manning. Sem sombra de dúvidas foi uma das melhores leituras do ano: é um excelente ponto de partida pra quem está começando, e como foi publicado em março de 2018, eu podia ter certeza de que estava lidando com uma das últimas versões do framework (olha o trauma se manifestando!).

Logo na sequência resolvi visitar novamente a documentação e, que surpresa! Está MUITO melhor. Segui o tutorial de uma ponta a outra e, numa experiência que começou em uma sexta-feira a noite e terminou no domingo, já havia devorado uns 90% da documentação oficial. Esta foi a primeira mudança: um bom livro e uma documentação muito melhor.

O ferramental

Mas mais do que a documentação, me encantou o ferramental do Angular. Quando comecei, muitos anos atrás, ainda não havia a ferramenta de linha de comando (ao menos eu não a conhecia). E caramba, como ela ajuda! Foi graças a ela que o aspecto framework do Angular ficou nítido pra mim (e até agora me pergunto: por que ignorei o essencial por tanto tempo???). Não só isto: o VS Code também oferece um suporte maravilhoso ao Angular e TypeScript (claro, é criação da Microsoft). Este foi o segundo fator: o ferramental do Angular é incrível e está muito à frente do que eu tinha no Vue.js.

Aliás, diga-se de passagem, minha experiência com o VS Code trabalhando no /dev/All foi tão boa que este acabou substituindo meu editor favorito até então, que era o Atom.

Ionic framework

É importante mencionar aqui outra razão importante que me motivou a estudar o Angular: Ionic. Apesar de haverem planos de no futuro este suportar o Vue.js, hoje ele suporta BEM mesmo é o Angular. De todos os frameworks híbridos que analisei, de longe Ionic foi o que, de novo, apresentou o melhor ferramental (isto merece um post no futuro).

(e olha que na itexto existe um framework que desenvolvemos para aplicações híbridas, baseado em Vue.js, que é simplesmente incrível)

TypeScript

Motivos irracionais me levaram a postergar o Angular por causa do TypeScript, confesso. Mas quando me atinei que uso Groovy no mundo Java esta irracionalidade foi aniquilada. Pouco a pouco fui aprendendo TypeScript e me encantando com a linguagem. Percebi que alguns dos erros comuns que cometemos com JavaScript não ocorrem no TypeScript: só isto já era razão para que a linguagem fosse adotada.

Devo confessar que parte da minha crescente adoção da linguagem se deu por causa do VSCode. Como ele me oferece um excelente suporte à linguagem (code complete, detecção de erros), ele me ajudou HORRORES a aprender os detalhes da linguagem e como ela funciona.

Sinceramente, não sei se o TypeScript terá lá uma grande longevidade dado que o JavaScript pouco a pouco vai se tornando um “TypeScript padrão”. Entretanto, hoje, e pelo menos pelos próximos três ou quatro anos, a linguagem se manterá, o que em si já justifica sua adoção.

(agora, sua documentação oficial, achei bem ruinzinha viu)

O framework em si

Quando comecei a entender mais a fundo como o Angular organizava e orquestrava seus elementos me apaixonei por ele. O conceito de módulos, por exemplo, achei incrível. De repente encontrei uma maneira muito mais interessante de modularizar código reutilizável entre projetos. É como um OSGi, só que no mundo JavaScript.

Os serviços também são muito interessantes: enquanto no Vue.js temos o Vuex para estado compartilhado, o que pode virar facilmente uma zona conforme o projeto cresce de tamanho, no Angular tenho serviços gerenciados por injeção de dependências e que podem ser singletons. Pronto: é como o Spring, só que no mundo JavaScript.

(OSGi… Spring… duas coisas que gosto no Java… agora do lado JavaScript/TypeScript da cerca…)

O modo como os arquivos que definem um componente são organizados também gostei bastante. No caso do Vue.js, temos os arquivos .vue do Vue Loader. É uma solução bacana, mas como tenho estilo, marcação e lógica no mesmo arquivo, conforme estes aumentam em complexidade, dificulta-se a manutenção (eu sei que o ideal é termos estes caras pequenos, mas eles crescem).  Gostei de ter arquivos em separado.

(Aliás, conto um segredo aqui: muito tempo atrás, quando comecei a aprender Vue.js, implementei o meu próprio “vue-kico-loader”, que era quase igual ao esquema adotado pelo Angular (sua manutenção ficou complexa, vi que o ideal era o Vue Loader, e aí abandonei o projeto))

Sabe do que não gostei? Da sintaxe dos templates: ter de usar coisas como [(ngModel)], *ngFor, coisas assim achei um saco. Neste aspecto o Vue.js é bem mais interessante.

Resumindo: para projetos maiores, a manutenção do código Angular se torna algo muito mais simples em relação ao Vue.js na minha experiência até agora.

Curva de aprendizado e produtividade

Aprende-se Vue.js muito mais rápido que Angular. Já tive experiências na itexto de pessoas sem nenhum conhecimento de desenvolvimento web que em quatro horas já se tornavam produtivas com o Vue.js. Aliás, este foi o fator que mais me encantou no Vue até hoje.

No caso do AngularJS, em minha primeira experiência, não observei isto. Levava um bom tempo até entender os controladores, o modo como eram as interações entre os elementos do framework e até mesmo alcançar uma produtividade mínima com ele.

No caso do Angular 6, que foi meu alvo, percebi que em um dia eu já estava conseguindo fazer alguma coisa com ele. Repare: “alguma coisa”. Ainda não me sentia confortável com a ferramenta. Mas passada uma semana de prática constante, hoje digo que sou bem mais produtivo com Angular que com o Vue.js. Em grande parte devido ao ferramental e do TypeScript.

No caso do Vue.js, usando o Vue.cli posso usar templates prontos que me dão um scaffolding similar ao do Angular, mas ele em si ainda não é tão evoluído, o que é natural, dado ser uma solução mais nova. Entretanto prevejo que no futuro este jogo vire, pois Vue.js ainda é mais fácil de dominar em pouco tempo, na minha experiência.

Como está sendo até agora

Está sendo ótimo. O grande teste é ter um sistema em produção no qual seja necessário dar manutenção de forma ágil. O projeto é o novo /dev/All, e sim, estou conseguindo realizar mudanças em minutos com um framework que ainda não domino inteiramente e com qualidade. Passou no teste.

Apesar de muita gente estar indo para o Vue.js e saindo do Angular, do ponto de vista corporativo, apostaria no Angular, pois a manutenção e o aspecto “framework” da ferramenta é realmente muito interessante. É fácil dar manutenção em uma aplicação Angular.

No final das contas o aspecto “ferramental” também conta bastante: é boas IDEs que ofereçam suporte decente ao framework adotado, e no caso do Angular, devido à sua própria história, isto fica evidente.

Esta tem sido minha experiência com o framework até este momento: aprendi algumas outras coisas que pretendo compartilhar com vocês em um futuro próximo conforme vou narrando aqui a jornada que entramos ao lançarmos o novo /dev/All, pois muitas das minhas concepções mudaram e estão mudando no processo.

Até lá. ;)

PS:

ainda me confundo um pouco com os termos Angular e AngularJS.

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.