All posts by Kico (Henrique Lobo Weissmann)

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

O retorno do meu canal no YouTube – primeiro vídeo sobre AWK!

Decidi tirar do limbo meu canal no YouTube: espero que vocês curtam. Acabo inclusive de publicar o primeiro vídeo do retorno, sobre AWK, que você pode ver até aqui no blog mesmo:

Como há uma boa quantidade de conteúdo que estou preparando para o canal, inscreva-se para acompanhar o que ando gravando. Ainda estou me desenferrujando, mas em muito pouco tempo acredito que a qualidade deva melhorar bastante!

Ah, o link do canal, né? http://www.youtube.com/kicolobo 

 

Qualquer um pode programar?

Desde o TK 85, mais de 30 anos atrás, programar é o amor da minha vida e o ato ao qual me dedico inteiramente (das formas mais variadas). O ato de projetar e construir software é na minha opinião o nosso ápice intelectual. Talvez você nunca tenha se dado conta, mas quando está programando na realidade o vislumbre de boa parte da história da filosofia é realizado diante dos seus olhos.

Então, se programar é tão importante pra mim por que será que quando escuto o papo de que “qualquer um pode programar” me sinto tão incomodado? Se considero o nosso ápice cultural, não seria contraditório este meu sentimento, visto que quanto mais gente programando, melhor?

Primeiro me incomoda por que geralmente escuto esta história de quem está vendendo cursos/treinamentos ou mesmo de um mercado que está sedento por profissionais que possam se dedicar ao ofício (e que preferencialmente sejam baratos). Se programar é para todos, por que o mercado sente tanta falta de mão de obra? Não deveria existir muita gente programando hoje?

Já te adianto minha conclusão: qualquer um pode aprender a programar, mas muito poucos devem ou conseguirão de fato se profissionalizar.

Primeiro: programar é (muito) difícil

Quando digo programar não estou me referindo à configuração do seu DVD player ou a cozinhar: falo a respeito da criação de software (binário, que vai executar em um computador). É algo muito complexo e quem te diz o contrário está mentindo para lhe vender alguma coisa ou não faz a menor ideia a respeito do que fala.

Você precisa conhecer lógica de programação, algoritmos,  é bom saber como um computador funciona, o que é uma linguagem de programação, o que ela faz, como você a usa, e, indo além: também precisa ter ciência de que a época na qual precisávamos de apenas uma linguagem para escrever nossos sistemas acabou já faz mais de uma década (os tempos do VB6, Clipper, Delphi, PowerBuilder…).

(e não, você não vai escrever seus sistemas apenas com JavaScritpt também)

Precisa saber como seu software irá interagir com outros sistemas, tais como SGBDs, servidores, sistema operacional, rede, arquivos, memória. Precisa entender que são diversas abstrações, umas sobre as outras e que seu ferramental é enorme (o que é lindo): inúmeros frameworks, bibliotecas, ambientes de desenvolvimento e execução, paradigmas de desenvolvimento…

A coisa não acaba no seu primeiro “hello world” ou seu sisteminha web meia boca. Não: você precisa estar sempre melhor. Nem digo conhecer as últimas tecnologias, mas sim se aprimorar tecnicamente a cada dia. Tem que olhar pro seu código anterior e o achar um verdadeiro lixo perto do que está escrevendo agora.

Detalhe: tem de escrever código que possa ser mantido por outras pessoas também e talvez por um longo período de tempo.

(sempre fico maravilhado quando penso na complexidade envolvida ao implementar qualquer bobagem)

E esta é a parte fácil da coisa: o difícil é ter proatividade educacional, ou seja, realmente se interessar por isto. Ler, ir a eventos, se atualizar, ter pelo menos um super herói (tenho vários) na área, aprender coisas novas semanalmente (quiçá diariamente).

Vai por mim: a animação após ter conseguido escrever o primeiro programa dura muito pouco se este ânimo contínuo de querer sempre saber mais a respeito do ofício não durar. Sabe como chamo esta animação inicial? “ilusão de poder”. Especialmente se você estiver empregado na área.

Você realmente acredita que pode realizar muitas coisas após ter escrito o seu primeiro programa, mas se não tiver proatividade no seu aprendizado, acredite, vai dar com a cara na parede muito rápido e uma vida de frustração será iniciada.

Então o papo de que “qualquer um pode programar” baseado na ilusão de que é fácil está desmontado neste primeiro ponto, sigamos ao próximo.

Segundo: a responsabilidade envolvida

Você se sentiria seguro sabendo que qualquer um pode operar a sua mãe? Se sentiria bem sabendo que qualquer um projetou o viaduto sobre o qual seu carro está passando neste momento? Então por que qualquer um pode programar os sistemas que você precisa?

Por que não dizem por aí que qualquer um pode ser médico ou engenheiro, mas programador sim? Por que há um mercado que precisa de pessoas que saibam programar, independente do quão bem saibam (que sejam baratas) e que não se responsabiliza pela qualidade do que entrega (ainda). E também há outro mercado que vende cursos que precisa de novos alunos sempre, especialmente hoje, uma época na qual programar não tem mais o mesmo charme que tinha antes (muito poucos programadores milionários, né?).

E agora te faço uma pergunta direta: se você não está preparado e entregou seu primeiro sistema, você realmente dorme bem? Ok, qualquer um pode programar e você entrou na categoria “qualquer um”, pergunto: você deveria estar programando profissionalmente?

Terceiro: o custo

“Programar é maravilhoso, por que você pode criar um imenso valor a partir de quase nada”. Já escutei isto algumas vezes e minha resposta é a seguinte: “vai à merda amiguinho”.

O que chamam de “quase nada” na realidade são anos de estudo dedicados ao ofício: incontáveis horas de bunda na cadeira, páginas lidas, resumos, exercícios realizados, experimentos, participação em eventos e comunidades… É ter errado inúmeras vezes e conseguido se reerguer e ainda sair melhor ao fim de cada experiência. Isto é “quase nada” pra você?

E aqui pergunto: você estaria disposto a pagar este preço que mencionei acima? Aprender a programar não sai barato. Pode até existir materiais de baixo custo, mas o tempo que você irá investir no aprendizado não tem preço (e se você for casado, tiver filhos ou ter um emprego não relacionado à área, sabe muito bem do que estou falando).

Quarto: programar não é apenas difícil, está ficando mais difícil também

Mencionei no início deste post que houve uma era na qual era possível escrever sistemas usando uma única linguagem: Clipper, VB, Delphi, PowerBuilder, C/C++, etc. Conheço excelentes programadores do passado que aprenderam tudo o que precisavam em um único livro ou arquivo de ajuda da linguagem (também pelo fato de não terem tanto acesso à informação quanto hoje), será que isto se aplicaria hoje?

E se programar estivesse realmente ficando mais fácil com o tempo, já não deveria ter surgido tecnologias realmente eficientes que gerassem código pra nós? Por que programadores ainda existem? Cadê a bala de prata? Surgiram ferramentas que tornaram parte do desenvolvimento mais fácil (pense em Ruby on Rails, Grails, Node.js), mas o problema principal, que é justamente resolver problemas, continua complexo e possivelmente bem mais por que o próprio mundo ficou mais complexo.

(e sabe estas ferramentas que citei? São normalmente abstrações sobre algo muito mais complexo por baixo dos panos, e o conhecimento sobre este “algo muito mais complexo” normalmente diferencia as crianças dos adultos)

Faça uma experiência: chame um programador de décadas atrás para programar hoje e lhe pergunte o que acha. Talvez ele prefira o ferramental de hoje, mas o restante, duvido muito.

Então quer dizer que só uma elite deveria programar?

Tal como disse no início deste post, pra mim programar é um dos (talvez O) maiores exercícios intelectuais que a humanidade já construiu. Acredito que programar te torna uma pessoa melhor por causa de toda a complexidade envolvida na coisa, talvez te torne inclusive mais inteligente.

Como hobby recomendo a todos, inclusive para crianças (fui uma destas crianças nos anos 80 introduzidas à programação). Talvez este hobby inclusive sirva para que você cheque se realmente este é o caminho que deseja trilhar como ofício para sua vida.

Agora, profissionalmente, sabendo dos riscos, da responsabilidade e da dificuldade envolvida, creio que infelizmente minha visão é bem menos democrática. Sim, é para a elite que consegue superar os desafios que mencionei e ainda por cima continuar gostando da coisa e se aprimorando a cada dia.

Não me vejo fazendo outra coisa na vida e sou extremamente feliz por ter escolhido este caminho. Foi um dos meus maiores acertos sem sombra de dúvidas e mesmo hoje, mais de 20 anos depois ainda amo cada dia e cada linha que escrevo.

Me desculpe se joguei um balde de água fria sobre seus sonhos, mas é importante que alguém lhe diga das dificuldades envolvidas (especialmente neste mundo em que vivemos  com cada vez mais fábricas de doces).

(por mais estranho que pareça creio que as dificuldades tornam tudo mais interessante)

E sobre aqueles que dizem que “qualquer um pode programar”, bom: vocês estão desvalorizando o ofício, simples assim.

Minha expedição ao mundo do Node.js

Este final de semana resolvi mergulhar no Node.js: apesar de ser uma plataforma que acompanho desde o lançamento nunca lhe dei a devida atenção que esta merece, então resolvi corrigir esta desfeita.

Este mergulho foi uma experiência incrível, intensa e que me fez refletir sobre diversos assuntos. Aprendi horrores e então pra finalizar (dar o primeiro grande passo), nada melhor que compartilhar com vocês minhas conclusões iniciais.

Eu e o Node.js

Talvez a melhor expressão para descrever meu relacionamento com Node.js até agora seja “curiosidade distante”. Meu primeiro contato com a plataforma foi quando surgiu: escrevi alguns mocks de webservices e APIs REST lá pelos idos de 2009/2010.

Se não me falha a memória estes mocks foram escritos usando o módulo HTTP mesmo. Na época fiquei muito impressionado pois com pouquíssimo código eu conseguia implementar aqueles servidores. Parecia fantástico (e era).

Mas na época (e ainda hoje) a JVM dominava minha vida (estou nela desde o Java 1.1 1996/97). Pra piorar, desde então vi muitas histórias de terror envolvendo o mau uso: essencialmente a má compreensão do modelo assíncrono, apresentações muito ruins sobre o assunto (muito ruins mesmo), hype excessivo, fanboys… Tudo isto gerou uma péssima impressão em mim, o que acabou me distanciando da plataforma.

(eu sei que devia focar minhas impressões em aspectos objetivos, mas é inegável (e perigoso) o poder do subjetivo)

De lá pra cá meu uso do Node.js sempre foi indireto: ou tendo como base ferramentas como o Apache Cordova, Vue.js, até mesmo a escrita de pequenos scripts internos para resolver coisas pequenas do meu dia a dia (usava o comando Node como calculadora). Nada de avançado. Nunca fiz uma aplicação web real.

Além disto sou da geração de programadores que não via o JavaScript com bons olhos. Me surpreende a popularidade da linguagem que, todos sabemos, não foi construída sobre a melhor das bases. E esta primeira impressão ainda exerce influencia sobre mim. Curiosamente mesmo assim JavaScript sempre foi uma das linguagens que mais dominei. Um sentimento do tipo: “sei que você tem muitos problemas, mas os ignoro e gosto de vocẽ”.

Começa a expedição ao redor do meu quarto

Um bom livro: recomendo!

Navegando pelo Udemy topei com uma promoção envolvendo este curso: The Complete Node.js Developer Course (2nd Edition). Custava R$ 20,00, os livros em português que havia lido a respeito detestei (idem os cursos), vi a ementa, li muitos reviews positivos, tinha um fim de semana livre, o negócio era barato e me bateu aquela vontade de aprender Node.js. Comprei. (a propósito, o curso é maravilhoso, recomendo)

De onde bateu esta vontade de aprender Node.js? Honesta e pura curiosidade e vontade de tirar a má impressão que tinha da coisa. E dado que já estou há mais da metade da minha vida na JVM, que se tornou uma espécie de “ilha de Lost” pra mim, por que não tentar sair um pouquinho deste mundo e minimizar meu determinismo linguístico? De quebra eu ainda aprenderia um pouco mais sobre o ES6 e algumas ferramentas novas. Começava a expedição.

(spoiler: ainda considero a JVM como a melhor plataforma de todos os tempos)

Já acessou hoje? Devia!

Mas este meu mergulho deveria ter um objetivo final: eu saberia se Node.js valeria à pena se construísse uma prova de conceito que o validasse enquanto tecnologia. Qual prova de conceito? Simples: reescrever parcialmente o /dev/All em Node.js e descobrir se o negócio escala mesmo, assim como se o ferramental me fornece produtividade similar à que tenho com Grails.

(o resultado foi muito interessante, aguarde e verá)

/dev/All – Node.js ou Grails?

O /dev/All tem dois componentes: o “Feed Hunter”, que é o responsável por obter os links que aparecem no site (escrito em Java usando Spring, Apache Camel e outras cositas sobre as quais escreverei em breve por que vêm surpresa aí) e o “Front-end”, feito inteiramente em Grails (3.1.9) e Vue.js.

Um dos nossos objetivos na evolução do Front-end é transformá-lo em um SPA, desacoplando-o completamente do código Grails (sim, eventualmente haverá um app, no qual já estou trabalhando). Já demos alguns passos nesta separação, o que se manifesta na adoção do Vue.js: o código Grails seria então apenas uma API REST dali pra frente.

Apesar de todos os nossos esforços, ainda acho este componente pesado: ocupa no mínimo algo em torno de 300 a 400 Mb de RAM no servidor. A vida inteira escuto que Java devora memória. Sendo assim decidi que minha prova de conceito seria a implementação de uma API que já existe no /dev/All: aquela responsável por obter os posts apresentados na página inicial. Este endpoint aqui.

Um pouco mais sobre o modelo de desenvolvimento atual e o da prova de conceito

O modelo de desenvolvimento atual usa como base aquilo que o Grails nos provê por padrão: usamos o GORM como ORM e a própria estrutura de controladores do framework para implementar estas APIs. É notório portanto que há aqui um custo adicional de memória/desempenho relativo ao ORM, entretanto no que diz respeito à produtividade, comparando o custo do desenvolvedor e do servidor, produtividade ganha e portanto o ORM fica.

O SGBD adotado é o MySQL: e aí entra a primeira dificuldade em relação ao material existente sobre o Node.js: 99% do que existe hoje usa o MongoDB como base de dados. Eu teria de aprender portanto como usar o MySQL com Node.js. Usei o módulo mysql na versão 2.5.4 (e o aprendizado foi super rápido).

No caso do Node.js não encontrei um módulo de ORM com bases relacionais e, sinceramente, desta vez quis evitar. Um dos meus objetivos foi também fugir um pouco do desenvolvimento estritamente orientado a objetos e partir para uma abordagem mais funcional (quem acompanha este blog sabe que tenho lá meus problemas com OO).

As impressões

JavaScript  – ES6

Foi uma excelente oportunidade para aprender de vez o ES6 e aqui aquela minha antiga impressão a respeito da linguagem foi embora. Querendo ou não eu acabava escrevendo código JavaScript tal como havia o conhecido lá no início da minha carreira no final dos anos 90: de repente veio um upgrade gigantesco e muitas das coisas que não conseguia entender se tornaram claras.

Já faz algum tempo que estava me dedicando ao estudo da linguagem, mas ainda não havia me debruçado sobre o ES6. Foi sem sombra de dúvidas uma verdadeira reciclagem neste aspecto. Muitas coisas que não entendia agora fazem sentido:funções arrow, a modularidade, e muitos aspectos envolvendo melhorias da própria sintaxe.

Ferramental do Node.js e tempo de execução

Uma surpresa maravilhosa: tal como no Grails, tudo o que preciso para trabalhar é da interface de linha de comando e um editor de textos. Mas mais do que isto, as ferramentas em si são bastante produtivas: nodemon para carregamento automático das mudanças que realizo no código fonte,  as ferramentas de depuração nativas do Node, o próprio npm (que já conhecia e inclusive devemos lançar um guia esta semana)… Fantástico pra dizer o mínimo.

O carregamento do código e o tempo de execução foram surpreendentes: muito mais rápido que o que eu esperava. Sobre isto vou inclusive falar mais à frente.

Escrita de testes com Mocha, Expect e Supertest

Sempre que vou aprender algo novo os testes viram meu laboratório. Até então escrevia meus testes no navegador usando o Jasmine. É uma solução legal, mas nesta expedição acabei conhecendo o Mocha, que é inclusive muito parecido. Não houve grandes mudanças para mim neste ponto portanto.

O interessante veio com o Expect: ele tem uma funcionalidade muito interessante chamada “spy”. Essencialmente é um “AOP para testes”, que te permite verificar se um método foi ou não chamado.

O Supertest também achei muito bacana: é usado para escrever testes em cima de requisições HTTP geradas pelo Express, ou seja, me permite escrever os testes funcionais de uma forma bastante simples.

O bacana é que com o nodemon podemos ter os testes executando a cada alteração que fazemos no código, isto se mostrou uma mão na roda no meu laboratório interno.

O ExpressJS

Do lado JVM já temos alternativas que seguem a direção do ExpressJS, como o Ratpack (não conhece? devia!) e o Vert.x (literalmente o Node na JVM). É o modelo de desenvolvimento que considero ideal quando estamos escrevendo APIs: fácil, direto, focado no que vamos fazer (a implementação dos endpoints).

Confesso que apenas amei o ExpressJS. A documentação não é tão boa quanto a do Grails, mas te fornece o essencial para que você possa fazer praticamente tudo com ele, e de uma forma muito simples.

Nem tudo é claro: o uso de sessões, por exemplo, não é tão óbvio (mais a frente conto o por quê das sessões), idem no que diz respeito à implementação de coisas como o CORS. Entretanto, quando você conhece o conceito de middlewares (o equivalente aos filtros da API Servlet) a coisa deslancha.

Sobre os templates, sim: há a renderização de páginas tal como o JSP do Java EE ou o GSP do Grails. Para tal experimentei o Mustache, Pug e EJS. Comparado ao que temos do lado Java são soluções muito primitivas: o GSP sem sombra de dúvidas está anos luz na frente. Mas é natural isto: a pegada do Node.js sempre foi muito mais no desenvolvimento de aplicações que seguem o padrão SPA, o que joga este tipo de solução para o segundo plano. Acabei optando pelo hbs (Handlebars) na minha prova de conceito.

No frigir dos ovos é um framework extremamente produtivo. No meu caso, que só conhecia (e muito pouco) o módulo http, foi uma bela surpresa.

O poder e a ilusão de poder

Quase tudo que vi no Node achei muito produtivo: e é mesmo, mas apenas se você sabe o que está fazendo. Parece óbvio, né? Mas não é: JavaScript ainda é aquela linguagem que a maior parte das pessoas diz conhecer mas nunca estudou a respeito.

Lembra as histórias de terror que mencionei no início deste post? Pelo que pude ver sempre surgiram das mesmas causas:

  • Falta de conhecimento acerca do modelo de desenvolvimento assíncrono que o Node adota (o não conhecimento do loop de eventos é fatal).
  • Tem de conhecer o paradigma funcional.
  • A falta de conhecimento sobre desenvolvimento backend – Node foi feito para ser executado no servidor. Vi muita gente sem conhecimento algum desta área, mas muito de JavaScript cometendo erros absurdos aqui.
  • Desconhecimento das nuances do JavaScript (coisas como == e ===, por exemplo, o próprio escopo de variáveis, etc)

A ferramenta é realmente muito poderosa, é  muito fácil de usar e você de fato tem as coisas rodando num tempo muito menor. Mas quando ignora estes pontos acima a coisa fica feia, muito feia.

A armadilha surge no fato do Node ter uma única thread (é possível ter um servidor com mais de um processo, basta usar o módulo cluster, mas não é o padrão). Qualquer operação de I/O que agarre, prende todas as requisições que chegam no seu servidor: sendo assim você não “tem de pensar assincronamente”, você é obrigado.

Mais do que pensar assincronamente, você precisa pensar funcionalmente. Se o desenvolvedor não tiver bem fixados os conceitos do paradigma funcional é quase certo que vai dar merda. E quer saber de uma coisa? Acho isto fantástico, por que sair um pouco do OO foi uma experiência quase terapêutica para mim (já mencionei que não curto tanto OO?).

Se não souber estas coisas, você não tem poder: tem a ilusão de poder e a garantia de estar criando mais histórias tristes que se propagarão por aí. Rapadura é doce, mas não é mole não.

E a sua prova de conceito, como ficou?

Bom, vamos aos resultados então. Comecei pela implementação de um único endpoint: o responsável por realizar a busca por posts no /dev/All (este aqui). Foi algo fácil de fazer: este endpoint me retorna a lista de posts, e cada elemento no post tem uma estrutura similar à seguinte:


{
 id:"id do post",
 titulo:"titulo do post",
 resumo:"o resumo do post",
 dataPublicacao:"a data em que o post foi publicado no post",
 dataInclusao:"a data em que o /dev/All encontrou o post e o incluiu no banco de dados",
 cliques:"quantos cliques recebeu o post",
 site:{
  id:"identificador do blog que contém o post",
  nome:"o nome do blog",
  url:"a URL do blog",
  autor:{
  id:"o identificador do autor do blog",
  nome:"O nome do autor do blog"
 }
 }
}

Há portanto três tabelas no banco de dados unidas por join: post, site e autor. Lembre: não estou usando MongoDB aqui, mas sim o MySQL. Será que a coisa escala? Comecei a realizar então alguns testes de desempenho e o resultado foi “apenas” assustador como mostrarei na sequência.

A chamada padrão a este endpoint retorna os últimos 20 posts cadastrados no /dev/All. Em média o tamanho da resposta é 20kb.

Teste de desempenho e escalabilidade

Para realizar o teste usei uma ferramenta chamada “siege“, que me permite realizar testes de carga usando o protocolo HTTP. Caso esteja usando Linux, você pode instalá-la usando o comando apt-get install siege.

Inicialmente peguei a mesma implementação feita em Grails e a instalei em um servidor Tomcat local (exatamente como se encontra em produção). Na sequência, executei os testes usando o Siege levando em consideração o tempo de um minuto e 255 usuários simultâneos. Vamos aos valores aproximados para a versão escrita em Grails:
Transactions:       21046 hits
Availability:      100.00 %
Elapsed time:       59.95 secs
Data transferred:      245.47 MB
Response time:        0.47 secs
Transaction rate:      351.06 trans/sec

Agora, vamos aos resultados na mesma API, implementada em Node.js usando as mesmas configurações:
Transactions:       32596 hits
Availability:      100.00 %
Elapsed time:       59.06 secs
Data transferred:      131.28 MB
Response time:        0.21 secs
Transaction rate:      551.91 trans/sec

Na média a mesma API escrita em Node.js consegue um throughput maior: 40 a 50% a mais de transações por segundo.

E sobre o consumo de memória? Na média enquanto o Tomcat consome 1 Gb durante o teste, a instância do Node consome 170Mb. 80% a menos.

Mas este benchmark não é preciso, então não comemore ainda

Não comemore ainda: pra começar este é um benchmark muito vagabundo. Você deve levar em consideração os seguintes pontos:

  • O código escrito em Grails usa o GORM e contém uma série de funcionalidades carregadas junto com a aplicação que não existem ainda no código escrito em Node.js.
  • O código escrito em Node.js usa apenas SQL nativo para obter os dados, o que dá um ganho de desempenho em relação à adoção de qualquer ORM.

Não cheguei a implementar uma versão usando apenas SQL do mesmo endpoint na aplicação, entretanto creio que o resultado seria muito parecido mesmo assim, pois ainda há uma enorme pilha por trás. Além disto, é fato conhecido que sim, Java sempre consome uma quantidade significativamente maior de memória.

Os testes foram além: depois executei verificações com 500, 1000 usuários simultâneos. A disponibilidade e escalabilidade do Node.js ganhou nestes casos (note: estou testando apenas um endpoint).

Resumindo: obtive resultados melhores do ponto de vista empírico com Node: mas minha metodologia de teste é muito furada e não deve ser levada como palavra final.

E depois de ter implementado a API?

Bom: aí eu empolguei e implementei quase todo o comonente Frontend do /dev/All em Node.js. Há uma versão muito tosca online caso queira conferir: ela tem apenas a página inicial, mas dá pra pelo menos você experimentar. Basta acessar http://devall.com.br:3000 (não sei até quando este link estará disponível, pois é apenas para testes).

Escrevi a página inicial usando o hbs, ou seja, não é uma aplicação SPA: meu objetivo era apenas aprender e testar a tecnologia, sendo assim leve isto em consideração quando a estiver accessando, ok?

Minhas considerações finais

Node.js com certeza faz parte agora do meu cinto de utilidades, e saibam que em pouquíssimo tempo teremos um novo front-end do /dev/All 100% implementado nesta tecnologia pelas seguintes razões:

  • Nosso front-end é muito pequeno, então é viável de ser reescrito (todo o trabalho pesado é feito pelo Feed Hunter).
  • O consumo de memória é realmente muito menor, o que nos permite aproveitar melhor nossos servidores e reduzir o custo de operação.
  • A escalabilidade se mostrou bastante superior.
  • E nesta minha empolgação já estou com 80% disto implementado e, no processo, sem os vícios das versões anteriores do código fonte. :)

É vital no entanto lembrar do que escrevi acima a respeito da ilusão de poder. É assustadoramente fácil escrever código lento e que não escalará em Node.js. Ficou óbvio pra mim a origem das histórias tristes que havia mencionado antes. Se você não souber programação funcional, entender o modelo assíncrono e de eventos do Node.js, é quase certo que vai dar errado.

(é importante lembrar que JavaScript ainda é aquela linguagem que a maioria julga saber mas nunca estudou de verdade, e isto é a origem de inúmeros problemas)

Sobre a produtividade em relação ao Grails

Do ponto de vista de produtividade, comparado ao Grails, sinceramente não posso dizer que seja mais produtivo que este. Os plug-ins do Grails, além do próprio GSP o tornam matador quando há renderização do lado servidor. Isto sem mencionar que a linguagem Groovy também é melhor que JavaScript (ao menos é construída sobre bases bem mais sólidas).

Ainda sobre produtividade comparado ao Grails: aqui nós pensamos de forma síncrona, que é muito mais natural para a esmagadora maioria das pessoas. No Node.js pensamos essencialmente em callbacks e promises e código que escrevemos para ser executado no futuro, e não no agora. E sim: se adequar a esta outra realidade leva tempo e, portanto, boa parte da sua produtividade também.

Entretanto no que diz respeito ao carregamento do código fonte e sua modificação durante a execução, Node.js chuta a bunda do Grails diversas vezes. É muito mais rápido, e isto é fundamental quando vamos executar uma grande bateria de testes.

Sobre modularidade e grandes bases de código

A questão da modularidade também é importante mencionar: já trabalhei em projetos gigantescos com Grails (e Java em geral). No caso do Node.js, ainda não peguei um projeto com uma grande base de código. Entretanto, para escrever micro-serviços, Node.js se mostrou uma ferramenta extremamente interessante e com certeza está no centro do meu radar para estes casos.

Sobre o consumo de recursos e escalabilidade

Não há muito o que dizer: consome uma quantidade muito menor de memória e quando bem projetado escala maravilhosamente bem. É portanto um forte candidato em situações nas quais temos servidores limitados (que é justamente uma área na qual venho pesquisando bastante nos últimos anos).

O consumo da CPU também se mostrou muito inferior. No caso dos testes que realizei, código na JVM chegava a consumir 350% da CPU fácil, enquanto o Node ficava na faixa dos 120%.

Resumindo: se você souber o que está fazendo o resultado é lindo.

Renderização do lado servidor

Não é algo lindo: tal como mencionei as opções que encontrei ainda são muito primitivas quando comparadas ao que temos em Java, Groovy ou PHP. Natural, não é o foco deste público. Para aplicações que requeiram a criação de vários CRUDs algo como Grails ainda é uma solução bem mais interessante.

Mas aqui leve em consideração minha pouca experiência no assunto. Pode ser que existam soluções que eu ainda não conheça.

E finalmente

Este foi um final de semana maravilhoso e estas foram as minhas conclusões iniciais sobre aquilo que estudei (por isto o post longo).

Neste primeiro momento recomendo o Node para pequenos projetos, especialmente se for projetos nos quais você implementará apenas uma API. É uma tecnologia muito bacana e que vale à pena estudar.

Conforme progrido no estudo conto mais pra vocês aqui.