All posts by Kico (Henrique Lobo Weissmann)

Experimentando o Apache Tapestry

Recentemente começamos um projeto de evolução de uma aplicação web escrita em Apache Tapestry. Já fazia um tempo que não ouvia falar a seu respeito (uns seis anos pelo menos), então esta foi a oportunidade perfeita (e necessária) para que finalmente eu estudasse um pouco a seu respeito, e o que estou aprendendo tenho achado muito interessante.

Nota importante: este é um post escrito por um iniciante no assunto (eu). Sendo assim toda correção é bem vinda!

O que é o Apache Tapestry e minhas primeiras impressões

Uma definição bem vagabunda: “é framework para desenvolvimento de aplicações web, baseado em componentes, voltado para a plataforma Java”. Isto não incita ninguém a correr atrás da ferramenta, especialmente se levarmos em consideração que não vemos muitos artigos escritos a seu respeito nos últimos anos. Sendo assim neste post vou escrever uma aplicação de exemplo que ilustra seu funcionamento.

Meu primeiro contato com Tapestry foi através de artigos na Internet e revistas em 2004/2005: anos mais tarde, lá por 2011, trabalhei em uma empresa que tinha alguns projetos baseados neste framework, mas eu mesmo jamais tive qualquer contato com estes projetos. Como nunca fui fã de frameworks que fossem baseados em componentes, torci o nariz para o projeto, até este mês (agosto/2017), quando precisei estudá-lo.

O que gostei no Tapestry

  • Altíssima produtividade – o projeto implementa um mecanismo de carregamento automático de classes que nos possibilita modificar o código fonte (Java) e ver as mudanças imediatamente na aplicação em execução, sem qualquer necessidade de reiniciar a aplicação.
  • O modelo de desenvolvimento – uma aplicação escrita em Tapestry essencialmente é um conjunto de páginas (este não é um framework voltado para a escrita de APIs REST). Uma página é basicamente uma classe Java e um arquivo de Template que reflete o estado dos objetos instanciados desta classe.
  • POJO puro (ou quase) – você não precisa implementar interfaces neste framework. Classes Java simples (e portanto fáceis de serem testadas) fazem todo o trabalho, e ainda há um container de IoC embutido que cuida de todo o ciclo de vida destes objetos.
  • É muito rápido – o desempenho é inacreditável. O carregamento dinâmico de classes que mencionei acima, por exemplo, é praticamente instantâneo.
  • Gestão interessante de sessões – o modo como Tapestry lida com sessões do usuário é muito bacana. Você não tem um objeto “session” ou algo similar: ao invés disto, os atributos das páginas que mencionei acima são tratados como tal de uma forma completamente transparente para o desenvolvedor.
  • É extensível – pelo pouco que pude ver na documentação oficial do projeto, é possível integrá-lo com o Spring, o que abre um universo de possibilidades. Este link mostra algumas extensões publicadas além da documentação instruindo como aplicar o Spring e Hibernate no projeto.
  • Baseado em Maven (e Gradle) – isto é ótimo, pois me possibilita abrir o código fonte em praticamente todas as IDEs Java do mercado hoje.
  • A documentação oficial – é boa, apesar dos problemas que vou citar a seguir (talvez este ponto seja uma contradição). Ela quebra o galho, mas não é ideal.
  • Bom suporte no Eclipse – há bons plugins para o projeto (estou usando o Tapestry Tools). Neste link há algumas opções, mas você as encontra fácil no Eclipse Marketplace.
  • Convenções sobre configuração – você quase não precisa editar arquivos de configuração no Tapestry, basta seguir as convenções que o framework oferece, mas sem te prender a uma forma pré-fixada: é possível mudar, até onde pude ver, qualquer comportamento do framework.
  • Desenvolvimento do projeto continua ativo – apesar de não ouvir falar do Tapestry já faz um bom tempo, fiquei muito feliz ao ver na página de release notes que sai pelo menos um (no máximo 2) release importante por ano do framework.
    (talvez seja um release por ano pelo fato do projeto já estar maduro, o que é um ponto bastante positivo)

O que não gostei

  • Alguns problemas na documentação – No momento da escrita deste post a documentação do framework (especialmente a sessão “Tutorial“) estava quebrada, e os trechos que envolvem o código fonte não estava muito legível, o que dificulta a vida de quem está dando os primeiros passos.
    O “Getting Started”, por exemplo, está desatualizado (durante a escrita deste post), e você não conseguirá criar o projeto se seguir o passo a passo.
  • Ausência de uma comunidade brasileira – no site oficial estão listadas algumas mailing lists, mas apenas em inglês. Infelizmente não encontrei muitos artigos escritos em português, o que, por mais que muitos não creiam, dificulta a adoção da ferramenta em território nacional.
    (sobre a falta de artigos em português, comecei a fazer minha parte. Conforme vou aprendendo mais sobre o Tapestry posto por aqui).
  • Comunidade mundial pouco ativa – ao menos esta foi minha impressão. No Facebook, por exemplo, só encontrei um grupo contendo seis membros, e na mailing list de usuários há poucos posts novos por mês também.
  • Poucas issues no Jira do projeto e ausência de um roadmap para as próximas versões – este é um ponto de atenção: não vi muitas issues abertas no Jira da comunidade que digam respeito a novas funcionalidades, especialmente no que diz respeito à próxima versão, que será a 5.5.0.
    Também não encontrei um roadmap para as próximas versões: o máximo que encontrei foi um antigo documento (marcado inclusive como desatualizado) para a versão 5.0 do projeto.
    Estes pontos levantam dúvidas a respeito da evolução do projeto e se ele estará acompanhando as próximas tendências do mercado, o que conta como ponto negativo na sua adoção para novas aplicações.
  • Não é bom para se escrever uma API REST – o objetivo do Tapestry claramente é a criação de aplicações no sentido “páginas interativas”, não para a escrita de APIs. Na documentação oficial, por exemplo, você não vê qualquer menção ao desenvolvimento deste tipo de projeto (ao menos esta foi a impressão, enquanto iniciante, que tive do projeto).

Notas sobre a popularidade do framework e se você deve adotá-lo ou não com base nisto.

Tapestry, assim como Grails, Wicket, Play e outros não é o que podemos chamar de uma opção “mainstream”, tal como o Spring (aliás, de todos os frameworks fora do Java EE, talvez o único mainstream seja o Spring) ou Java EE (puro,o que inclui o JSF). Sendo assim, quaisquer comparações em relação a estas opções é descabida de fundamentação.

No caso do Java EE, ainda mais, especialmente se levar em consideração o fato de que todos os demais frameworks dependem deste para funcionar (o que consequentemente o tornará sempre o mais popular).

O que levo em consideração na adoção destes frameworks (que são verdadeiras armas secretas) é a atividade da comunidade que possuem e a quantidade de releases anuais. Normalmente quando não ocorrem releases por mais de um ano levanto o sinal amarelo.

A propósito, já escrevi sobre este tópico neste link alguns anos atrás, mantenho minha opinião e já está na hora de escrever outro post a respeito.

(e ei, se você curte uma tecnologia e não escreve sobre ela por não ser tão popular, só tenho uma coisa a te dizer: SHAME ON YOU!)

“Olá Mundo” com Tapestry

O código fonte pode ser baixado neste repositório do GitHub.

O que você vai precisar

  • Maven 3 – http://maven.apache.org 
  • Java (JDK) 1.8 (para a versão 5.3.8 pra frente do framework. As anteriores tem de usar o Java 7 ainda)
  • Qualquer IDE que ofereça suporte a Maven (o projeto vai abrir em qualquer uma, no meu caso estou usando o Eclipse junto com o plug-in Tapestry Tools.

É uma aplicação bem simples, só pra mostrar os conceitos de páginas, componentes e o modus operandi do framework, sendo assim não esperem muita coisa daqui.

Criando o projeto com Maven

No link “Getting Started” do projeto você lerá que deve executar o comando a seguir:

mvn archetype:generate -DarchetypeCatalog=http://tapestry.apache.org

Não funcionará com o Maven 3: você topará com a seguinte mensagem de erro:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate (default-cli) on project standalone-pom: archetypeCatalog 'http://tapestry.apache.org' is not supported anymore. Please read the plugin documentation for details. -> [Help 1]

Isto é fácil de resolver: basta usar uma versão anterior do plug-in archetype do Maven, tal como a 2.4 no exemplo a seguir:

mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate -DarchetypeCatalog=https://repository.apache.org/content/repositories/staging -Dfilter=org.apache.tapestry:quickstart

Após metade da Internet ser baixada para seu computador, serão aprsentadas 10 opções de arquétipos a serem escolhidos. Para o nosso exemplo adotei a opção “20” que equivale à última versão disponível do Tapestry (5.4.3).

Na sequência você precisará responder algumas perguntas:

  • O nome do grupo (groupId) – no exemplo: br.com.itexto
  • O nome do artefato (artifactId) – no exemplo: inicio-tapestry
  • Sua versão
  • O pacote no qual o código fonte se encontra (isto é importante e veremos mais a respeito mais à frente) – no exemplo: br.com.itexto

Respondidas as perguntas, será criado um diretório cujo nome equivale ao artifactId do projeto. Para testar o projeto, mude seu diretório corrente para o criado pelo projeto e execute o comando abaixo:

mvn jetty:run

Será iniciado o servidor Jetty, embarcado no projeto. Sim, seu ambiente de desenvolvimento está pronto. Acessando a URL http://localhost:8080, exposta na saída do prompt, você se deparará com a seguinte página:

clique sobre o link: ele aponta para uma URL similar ao artifactId que você forneceu ao criar o projeto. Agora você verá a página de boas vindas do Tapestry.

Dica: dá pra criar o projeto de uma forma muito mais simples usando o Eclipse, tal como descrito neste link.

A estrutura do projeto

A estrutura de diretórios criada pelo arquétipo do Maven

Importe o projeto Maven para a IDE de sua preferência, pois iremos alterar levemente este código fonte para expor o funcionamento do Tapestry. O arquétipo do Maven cria alguns sub-pacotes que são importantes: neste post falarei apenas de dois:

  • br.com.itexto.pages – contém as páginas do projeto
  • br.com.itexto.components – contém os componentes

E na pasta “src/main/resources” também são criados alguns diretórios interessantes:

  • src/main/resources/br/com/itexto/pages – contém os templates das páginas (falaremos mais sobre isto mais a frente)
  • src/main/resources/br/com/itexto/pages/components

Os mesmos nomes dos pacotes se repetem nas pastas criadas em “src/main”. Como disse no início deste post, uma aplicação Tapestry é composta essencialmente por páginas. Uma página, por sua vez, tem duas faces:

  • O código fonte Java que representa o “controlador” do projeto.
  • Um arquivo de template, que deve ter exatamente o mesmo nome da classe que a representa, na pasta “src/main/resources”. Estes templates tem a terminação “.tml”

Com base no exemplo acima, alterei o código fonte do arquivo “Index.java” para que fique tal como o exposto a seguir:


package br.com.itexto.pages;package br.com.itexto.pages;

public class Index{

public String getRandomico() {
return java.util.UUID.randomUUID().toString();
}
}

Note que é uma classe Java simples, sem a necessidade de realizar qualquer implementação de interfaces ou uso de anotações. Alterei também levemente o arquivo de template relacionado (src/main/resources/br/com/itexto/pages/Index.tml) para que fique tal como no exemplo a seguir:


<html t:type="layout" title="inicio-tapestry Index"
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd"
>
<p>Randomico como ${randomico}</p>
</html>

(Quando acessamos a URL do projeto, é a página Index que será renderizada para o visitante. Se você quiser experimentar, crie páginas com o nome “Teste” (contendo o código Java e o de template) e acesse as URLs diretamente para brincar.)

O template é a outra face da página: é o conteúdo HTML que será renderizado. No caso do Tapestry, é XHTML que usamos na realidade (HTML formatado como XML). Em seu interior, incluímos uma expressão: ${randomico}, que irá renderizar o valor retornado pela função getRandomico(), definido na classe Index.java. Tapestry usa a especificação JavaBeans do Java para definir as expressões que serão usadas na renderização das páginas.

Coloque a aplicação para executar em sua IDE usando o comando “mvn jetty:run” para ver o resultado, que será similar ao exposto na imagem a seguir:

Recarregamento dinâmico de classes

Agora, com a aplicação ainda em execução, faça o seguinte experimento: modifique a função getRandomico() da classe Index para que retorne diferentes valores, sem parar a aplicação. Carregue novamente a página: a mudança é instantânea.

Vá além: crie outros “getters” para novas propriedades e vá incrementando o arquivo de template. Note como mesmo novos métodos são detectados instantaneamente na aplicação sem precisar realizar qualquer tipo de reinicialização. Isto dá muita produtividade no desenvolvimento. A propósito, observou a velocidade com que a aplicação é iniciada?

E os componentes?

Bom, vendo a última imagem você deve ter notado que é renderizada uma barra de navegação, mas não a digitamos no código fonte do template. Notou? Então vou repetir o código aqui:


<html t:type="layout" title="inicio-tapestry Index"
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd"
>

<p>Randomico como ${randomico}</p>
</html>

O template define que ele é de um dado tipo: “layout”. Você notou que existe uma pasta chamada “components” em “src/main/resources” e também um pacote chamado “components”? Se você abrir o código fonte do arquivo “src/main/resources/br/com/itexto/components/Layout.tml” verá que a barra de navegação, assim como o rodapé e toda a identidade visual está aí. E também vai achar um trecho similar ao exposto a seguir:

<div class="container">
<t:body />
<hr />
<footer>
<p>&copy; Your Company 2015</p>
</footer>
</div> <!-- /container -->

Sabe esta tag <t:body/>? Ela inclui o conteúdo da página Index no interior do Template. É um mecanismo muito similar ao Sitemesh do Grails! Na realidade é um pouco mais que isto, mas para este post inicial, creio que esta definição será o suficiente.

Código fonte do exemplo

O código fonte deste projeto pode ser encontrado neste link. Talvez eu o evolua no futuro conforme novos posts surjam no blog.

O que o Tapestry não tem e não é

É importante salientar que este não é um framework full stack tal como o Grails ou Spring Boot (dependendo da configuração). Quando criamos um novo projeto ele não vem com a camada de persistência pré-configurada. É necessário realizar esta configuração manualmente, tal como exposto na própria documentação.

O projeto já vêm com algumas configurações prontas, tal como o mecanismo de logging e algum CSS, baseado no bootstrap, mas não muito mais do que isto.

Também é importante observar o seu foco: são aplicações web que contenham páginas interativas, não APIs REST. É possível configurar no mesmo projeto um segundo framework para prover estas funcionalidades, tal como o JAX-RS ou mesmo o Spring, mas não recomendo isto.

Sei que não mencionei neste post nada relativo à gestão de sessões, mas este é outro aspecto interessantíssimo do Tapestry: não é um destes frameworks no qual você tem a sessão explícita. Lidamos com ela de uma forma indireta através de anotações que incluímos em nossas classes (@Persistent). Sendo assim, para projetos que precisem lidar diretamente com sessões (cada vez menos o caso), Tapestry também não se aplica.

Conclusões finais sobre este contato inicial

Neste post mostrei apenas o básico do básico do básico do Tapestry (quase nada pra ser sincero). Muita coisa ficou de fora, tal como a forma como é realizada a navegação entre as páginas, gestão de sessão, formulários, inversão de controle, etc.

Meu objetivo foi apenas gerar algum interesse pelo framework e, talvez, criar o post inicial que me permita ir detalhando aos poucos como o Tapestry funciona conforme vou avançando nossos estudos a seu respeito.

Estou achando uma solução muito interessante: mais interessante que o JSF na minha opinião, pois é mais fácil de aprender e oferece uma produtividade muito superior. Isto sem mencionar no desempenho, que foi um dos fatores que mais me surpreendeu.

(tal como mencionado no início deste POST, para implementar APIs REST não é uma solução interessante. Aliás, nem sei se faria sentido, dado ser focado em componentes, e não em ações, tal como ocorre no Grails e Spring MVC)

Dado o estado atual da comunidade (ao menos minha percepção inicial), não sei se o recomendaria para iniciar novos projetos, mas em relação a este aspecto apenas o tempo me dará uma resposta satisfatória. Entretanto, se o tempo mostrar que ainda há gás nesta comunidade, sem sombra de dúvidas que o incluirei em nosso radar.

Visto que tão pouco se escreve a respeito do Tapestry ultimamente, creio que no mínimo estes meus posts servirão para atrair interessados a seu respeito. Mesmo que você jamais o use, as ideias que ele trás já valem à pena conhecer.

Mais fontes sobre Tapestry

Talvez você tenha se interessado pelo framework. A documentação oficial apesar de boa não é suficiente. Sendo assim, seguem alguns links que estão me ajudando no aprendizado:

Tapestry Jumpstart – quase um cookbook de Tapestry

Wiki do projeto – tem algumas informações que não constam na documentação oficial

Este tutorial da Tutorials Point – no formato PDF, é um complemento bem interessante para o tutorial oficial

Tutorial oficial – apesar de estar quebrado o HTML, me ajudou bastante

Groovy/Grails, Spring e JavaScript Brasil por dentro – nossa arquitetura de comunidades

Cinco anos atrás escrevi este post descrevendo como era a arquitetura do Grails Brasil (hoje Groovy e Grails Brasil). As coisas caminharam bastante desde então: de um código fonte que tinha como objetivo atender um único site (Grails Brasil), pouco a pouco este evoluiu para que se tornasse uma solução capaz de atender qualquer comunidade.

Ao lançarmos o Spring Brasil demos o primeiro passo no que diz respeito a este objetivo: era essencialmente o código fonte do Grails Brasil com uma série de pequenas modificações (essencialmente a remoção de tudo o que era específico apenas daquele site). Já no caso do JavaScript Brasil demos o passo quase derradeiro: é o mesmo código fonte do Spring Brasil: todas as customizações (especialmente visuais), entretanto, passaram a ser o resultado de mudanças na configuração.

Acho que é interessante contar a história técnica por trás deste projeto (ela descreverá sua arquitetura). Curiosamente, não temos um nome para este código fonte: antes era “Grails Brasil”, hoje o chamamos de “Komunidade” ou o nome do site no qual estamos trabalhando.

A história

O início em PHP

A primeira versão do Grails Brasil veio em 2008 e era na realidade uma instalação do phpBB. Sim, você leu certo: o Grails Brasil era um site escrito em PHP. O criei para aprender Grails e o phpBB era uma solução muito interessante na época: fácil de instalar (fiz isto usando um assistente da Hostnet na hora do almoço) e manter. Além disto, era o que precisávamos na época: um fórum básico.

Esta solução nos atendeu bem por um ano ou dois. A hospedagem era relativamente barata, mas com o tempo foi ficando mais cara por dois motivos:

  • A comunidade cresceu bastante e sempre estávamos superando nosso limite de banda.
  • SPAM quase nos destruindo: gastava uma boa parte do meu dia apagando SPAM do site.

Em um primeiro momento fiz modificações no código do phpBB para reduzir estes problemas. Não tive bons resultados e por um tempo pensei seriamente em matar o projeto.

Segunda fase: primeira versão em Grails

Lá por 2008, 2009 tive meu primeiro contato com servidores cloud que passaram a se mostrar como uma alternativa bem mais viável (plano free tier da AWS pra ser mais preciso). Até então hospedagem Java era ou muito cara (pra mim) ou muito limitada (precisava enviar um WAR para o serviço que oferecia um Tomcat compartilhado, algo muito tosco).

Foi a oportunidade para poder finalmente ter a primeira versão em Grails do site. Dois objetivos me guiaram para esta mudança:

  • Meu custo com hospedagem deveria ser menor.
  • O problema do SPAM deveria ser definitivamente resolvido.

Foi escrita então esta primeira versão do site em Grails (versão 1.3.7, que foi usada até ano passado ou retrasado se não me engano – hoje usamos a versão 3.2.8). Dado que serviços como AWS costumam cobrar por processamento, foi o momento ideal para que eu pudesse otimizar ao máximo meu código (o que me levou a um conhecimento bem mais profundo da linguagem Groovy e da própria JVM).

E nisto foram tomadas uma série de decisões que são refletidas no código até hoje:

  • Dado que já existia uma base de posts vinda do phpBB, e este usa uma sintaxe chamada bbCode no armazenamento dos posts, a próxima versão do site deveria manter esta compatibilidade (até hoje usamos bbCode para escrever os posts).
  • As buscas não deveriam tocar o banco de dados: sendo assim adotamos o Lucene como nosso motor de indexação usado em todas as nossas consultas (já notou como são rápidas?).
  • Dado que meu objetivo era reduzir custos, e minha instância no free tier da AWS tinha 612 Mb de RAM, neste mesmo servidor deveriam ser executados o MySQL e o Tomcat. Logo o sistema poderia consumir, no máximo, 300 Mb de RAM (consome isto até hoje).
  • O site tinha de ser mais rápido que o phpBB (consegui, é ordens de magnitude mais rápido). Logo o que pudesse ser feito assincronamente deveria ser feito desta maneira (por isto e-mails não são enviados na hora, mas sim esporadicamente, assim como atualização de acessos e pontuação dos membros).
  • A esmagadora maioria dos acessos ao site são para simples consulta (10% se registram e menos ainda chegam a postar conteúdo), sendo assim SEO é prioridade (idem a busca).

E assim surgiu o Grails Brasil escrito em  Grails. Uma série de medidas foram tomadas para atingir estes objetivos, todas elas descritas neste antigo post (e as adotamos ainda hoje).

Terceira fase: Spring e JavaScript Brasil

Até 2015 o código do Grails Brasil se manteve essencialmente o mesmo, apenas com pequenas correções. A partir de 2016 começaram mudanças mais significativas.

A primeira delas dizia respeito à atualização do próprio Grails: passamos a usar a versão 3 e, pouco a pouco, fomos migrando até a versão 3.2.8, usada hoje. Por que levou tanto tempo para fazer este upgrade? A versão antiga me atendia muito bem. Uma boa decisão tomada lá atrás? Ter usado pouquíssimos plug-ins, o que tornou o upgrade muito fácil (em questão de horas estávamos na versão 3.0 do Grails). Além disto estava claro que precisávamos atualizar o código fonte para termos algo durável (Java 6??? Bora pro 8!).

Já fazia um tempo que queríamos criar novas comunidades, então era também a hora de podar o código fonte, removendo tudo aquilo que só fazia sentido no Grails Brasil do novo código. Foi ótimo por que conseguimos otimizar ainda mais o que já tínhamos.

(hoje como consequência temos duas bases de código: uma para o Grails Brasil, outra que atende as outras comunidades para que pudéssemos manter as funcionalidades para os membros atuais do site)

Novos objetivos arquiteturais

Modificações do site em tempo de execução

Ao lançar novas versões do site sempre havia momentos nos quais me deparava com pequenos problemas de layout, conteúdo textual ou JavaScript nos quais detectava problemas logo após ter implantado a solução. Aí era necessário gerar um novo WAR e realizar todo o processo de deploy.

Isto ocorria por que sempre havia um ou outro ponto de configuração que ficava no próprio código fonte (o próprio HTML gerado pelo site, por exemplo, pode ser visto desta forma). Hoje todas as configurações encontram-se externalizadas no banco de dados. Com isto, se queremos modificar, por exemplo, o rodapé do site após a versão ter ido pro ar, hoje é possível.

Erros de layout devido a problemas no CSS? Ok, podemos mudar também. Apenas a título de curiosidade, o JavaScript Brasil passou por umas 20 correções de layout de ontem até hoje (23/8/2017). Sabe quantos deploys foram feitos? 1.

Além disto o conteúdo que aparece nas laterais do site, rodapé e cabeçalho também podem ser modificados hoje com o site em execução, o que nos permite trocar anúncios de uma forma muito mais ágil.

Não só isto: configurações de tarefas agendadas, acesso às integrações essenciais (e-mail, redes sociais e no futuro até mesmo a conexão com o SGBD) são hoje trocadas a quente.

Criação rápida de novas comunidades com o mesmo código fonte

O objetivo é que o “Komunidade” seja como o WordPress. Você baixa a distribuição, configura o acesso ao banco de dados, escolhe um tema e voilá, tá criado um novo blog ou, em nosso caso, uma nova comunidade.

A versão atual é exatamente assim. Pegamos o código fonte, definimos a configuração de acesso ao banco de dados, geramos o WAR, criamos um tema, configuramos no banco de dados do projeto os detalhes da comunidade (seu nome, regras de conduta, quais links são expostos, aonde ficam nossos arquivos de template de e-mail e temas visuais e mais uma série de outros detalhes), instalamos no Tomcat e pronto: uma nova comunidade surge.

Levou algo em torno de umas 4 horas para termos uma primeira versão aceitável do JavaScript Brasil (e nós nem sequer tocamos no código fonte do projeto).

Tornar a abertura do código fonte algo viável

Este tem sido o objetivo já faz algum tempo. Infelizmente ainda há informações no código fonte atual que não devem ser publicadas. Este é o principal motivo por que ainda não existe um repositório no GitHub com o código do Komunidade.

Mas posso dizer que o último release não deu mais um passo nesta direção, mas sim um salto quântico. A esmagadora maioria das informações que mencionei acima não existe mais. O objetivo agora é tornar este código fonte o mais fácil possível de ser mantido E entendido por novos colaboradores.

Mais do que tornar o código fonte mais legível, temos de ter uma distribuição do “Komiunidade” que possa ser usada também por não programadores. Algo como o WordPress.

(diga-se de passagem, uma pessoa que não sabe programar é que fez o tema do JavaScript Brasil, absolutamente sozinha)

Também falta melhorar a documentação do projeto: código Grails é muito fácil de ser entendido, mas não é o suficiente (nunca acreditei naquele papo de “meu código é minha documentação”).

Então, aos que sempre me pedem acesso ao código fonte o que posso dizer neste momento é isto: será eventualmente aberto, mas de uma forma correta e em grande estilo, não por pressão.

O futuro

Lá em cima mencionei que hoje temos duas bases de código: “Grails Brasil” e “Komunidade”, certo? Isto é temporário pois o objetivo é ter apenas uma. Mas como fazer isto se no código do Grails Basil há tanta coisa que só faz sentido nele?

Já estou trabalhando em uma arquitetura de plug-ins para este projeto (WordPress sempre é  inspiração). Sendo assim, tudo aquilo que era específico do Grails Brasil será transformado em um pequeno módulo, que possa ser instalado em uma instância do “Komunidade”.

Com isto é possível ter seções distintas em instalações separadas do Komunidade. É possível, por exemplo, termos uma seção em uma instalação do site que seja na realidade um plug-in. O core será bastante diminuto, e a seu redor os plug-ins orbitarão: tal como ocorre no Eclipse, Netbeans e, claro, no WordPress também.

No que diz respeito ao frontend, ainda temos receio a respeito de uma grande mudança, tal como a adoção de um framework JavaScript ainda tenho algum receio pois um dos nossos objetivos é ter código duradouro e, sinceramente, ainda hoje não vi soluções que tenham passado no teste do tempo (com exceção do jQuery talvez).

E enquanto isto vamos evoluindo pouco a pouco o código que temos. Esta é a história do projeto até agora, grandes novidades virão em breve como sempre. Espero que tenham gostado.

E se inscrevam no Spring Brasil e JavaScript Brasil, pois o principal objetivo por trás dos dois projetos é criar discussões bem acaloradas sobre estes temas!

O projeto JavaScript Brasil

Alguns meses atrás começamos uma série de melhorias no motor responsável por manter o Groovy e Grails Brasil e também o Spring Brasil. O objetivo final é a abertura deste código e a máxima flexibilidade da ferramenta que nos permite criar e manter comunidades de uma forma muito simples. Como chegamos em um estágio bem avançado do projeto e sempre quis ver um fórum voltado para JavaScript no Brasil (focado em grandes discussões), por que não?

Ontem colocamos no ar a terceira grande evolução da plataforma que é o “JavaScript Brasil“. Os mesmos princípios e objetivos que guiaram a criação e manutenção do Spring Brasil se mantiveram (leia aqui). Há apenas uma mudança no foco: é hora de falar sobre JavaScript.

O visual é bastante diferente do das comunidades que criamos antes (o que comprovou a flexibilidade que precisávamos na plataforma), e há também uma série de pequenas melhorias sutis no site, que já foram inclusive aplicadas no “Spring Brasil”.

Este post é apenas para contar a novidade e convidar todos vocês a se inscreverem lá para que possamos iniciar discussões brutais sobre JavaScript (tentar chegar ao nível das que tínhamos no GUJ anos atrás). Espero por vocês lá!

Ah, o link para acesso: http://www.javascriptbrasil.com.br

PS: logo na sequência virá um post sobre a arquitetura deste projeto, que é essencilamente um update deste post de 5 anos atrás (o tempo voa!).

Stack Overflow pode te emburrecer?

Já faz um tempo que planejo escrever sobre educação, mais especificamente sobre a forma como nós, programadores, nos educamos. Como alguém que se encontra do outro lado da mesa agora – como contratante – creio que é interessante compartilhar aqui minhas impressões e descobertas sobre este assunto.

Vou começar por descrever uma doença que observo em nossas consultorias e, principalmente, nos processos seletivos que realizo tanto para a Itexto quanto para nossos clientes. Chamo esta doença de “emburrecimento por Stack Overflow”. Poderia usar o termo “fórum”, mas dado o sucesso do site, noto que seu nome se tornou uma espécie de sinônimo para “fórum”.

Como aprendemos

Para entender esta doença é necessário começar pensando o modo como aprendemos as coisas, especialmente as complexas, tais como programar. Tudo tem seu início nos conceitos mais simples.

Você começa a partir do clássico “Olá mundo”. O computador irá imprimir textos aleatórios na tela de acordo com aquilo que você definir em seu código fonte. Isto te fornece a ideia (e experiência) do conceito fundamental de comando. Você, humano, enviando instruções para o computador e este te respondendo, no caso, imprimindo algo na tela (ainda me lembro da minha primeira impressão desta experiência, e foi linda!).

msx_oiMundo

Após ter enjoado de todas as variações daquele comando elementar você começa a brincar com operações matemáticas, condicionais, loops, entrada e saída por teclado. Entra a lógica de programação mais básica: começam os códigos mais simples, tais como nossas primeiras funções de soma, talvez algo um pouco mais avançado, como a implementação de um Fibonacci, coisas assim.

Com o tempo adquirimos segurança e começamos a pensar em reuso: surgem as funções melhor elaboradas (uma função chamando outra), você começa a se preocupar com a qualidade do código que vai escrever, pois nota que aquele negócio vai ficando mais complexo conforme evolui. E aí entram as noções de programação procedural, que em pouco tempo irão evoluir para módulos (se estiver experimentando BASIC ou Pascal na faculdade).

smalltalk

Os módulos no futuro se transformarão em classes e objetos, e você começará a modelar sistemas orientados a objetos, a complexidade aumentou, o código começa a ficar bem mais difícil de ser mantido e você busca por soluções que outros tenham adotado para contornar estes problemas. É quando nos deparamos com padrões de projetos, frameworks, bibliotecas…

(se vir por aí alguém dizendo que programar é fácil, já te adianto: é picareta que tá tentando te vender curso ou livro)

Este é um caminho possível e, na minha opinião, o melhor. É o conhecimento sendo construído em camadas. Primeiro você monta uma camada bem simples (os comandos), se sente à vontade com ela, constrói outra (as funções), e outra (reuso), e outra (módulos) e outras (orientação a objetos), e outras (frameworks, bibliotecas) e outras (pensa em arquietura) e outras…. E por aí vai.

grandcanyon

E é por isto que bons professores e livros são tão importantes: se suas primeiras camadas forem mal construídas fica muito mais difícil se reprogramar e apagar impressões erradas. Na minha experiência enquanto contratante e tutor fica claro que os pupilos que melhor se desenvolvem normalmente são aqueles que baseiam seu conhecimento em um guia com começo, meio e fim bem definidos.

(Você sabe a diferença entre pupilo e estudante? O primeiro requer atenção continuada por parte do tutor, o segundo se vira por conta própria)

A importância do guia

Chamo de guia uma sequência de conhecimentos que são passados ao pupilo. Sequência esta que, naturalmente, começa pelo mais elementar, mas provê a base para que os novos conhecimentos (as camadas) possam ser adquiridos.

Este guia pode ter as mais variadas formas: um professor, um livro, vídeo aulas, uma série de artigos. O essencial é que começo, meio e fim sejam bem definidos e, mais ainda: que cada camada forneça a base para que possamos dominar a próxima. O bom guia torna claro a conexão entre as camadas.

(talvez a metáfora das camadas não seja a melhor, pois o conhecimento pode ser não linear, entretanto sempre há um ponto que segue o outro, mesmo que surjam bifurcações, sendo assim a ideia de sedimentação como base para elevar o conhecimento funciona no final das contas)

Ainda mais importante: o guia te diz aonde você irá chegar. Há um objetivo bem traçado: você sabe exatamente aonde deveria estar no final da jornada. E como você sabe que o caminho está certo? Simples, aquele objetivo que parecia distante de repente começa a se mostrar cada vez mais factível, de repente escrever seu próprio sistema operacional, linguagem de programação, website ou sistema de controle de armas nucleares começa a se tornar mais fácil ou pelo menos mais viável de ser realizado por você.

E como você sabe se o caminho está sendo bem trilhado? Simples: a partir da segunda camada de conhecimento, você pode verificar se o que está sendo dito é válido ou não checando aquilo que aprendeu no passo anterior. E se neste momento surgirem dúvidas que serão repassadas ao seu guia, o melhor sinal possível acaba de ocorrer: você está questionando, e se está questionando, é por que está pensando.

Após n camadas, o pupilo começa a perceber novos horizontes, novas fontes de conhecimento. Neste momento ele pode largar seu guia atual e buscar outras fontes de conhecimento. É quando o pupilo se torna estudante.

(no final das contas, o conhecimento sempre se dá a partir de conexões que criamos entre aquilo que está chegando (as novas camadas) e aquilo que já conhecemos (as camadas que sedimentamos))

Aí chega o Stack Overflow e ferra tudo

pollock_1_1949

Não me entenda mal, eu gosto do Stack Overflow, mas não como ferramenta de aprendizado. Infelizmente o problema que observo tanto em consultorias quanto em processos seletivos é que o indivíduo não usa fóruns como fonte secundária de conhecimento, mas sim primária. Explico melhor.

Você em uma sala de aula (virtual ou não): primeiro aprendemos com o guia. Em seguida, comentamos aquilo que aprendemos com os colegas ou mesmo diretamente com aquele que nos guiou até aquele ponto. Há um momento inicial essencial ali: o recebimento da informação e, posteriormente, a confirmação do conhecimento, que se dá normalmente em duas fases:

  1. O indivíduo reflete sobre aquilo que foi dito.
  2. Se não ficou claro após ter refletido (e experimentado) o que foi dito, interage com o guia ou seus colegas ou o mundo buscando entender ou confirmar aquela informação.

Agora: e quando você inverte a ordem? E quando quer criar um sistema de gestão mas não sabe programar? No Grails Brasil, por exemplo, já vi muitas dúvidas que seguem mais ou menos esta forma:

E aí pessoal, tudo bem?
Seguinte: quero criar um sistema de controle para minha padaria. Preciso então saber como, em Grails, eu faço para, me conectar ao banco de dados e persistir os dados para que eu possa gerar meus relatórios gerenciais.

Note: a pessoa sabe que existe uma ferramenta que pode ser aplicada para se atingir o objetivo traçado, mas ela não buscou conhecê-la em um primeiro lugar. Ao invés disto, buscou primeiro o auxílio dos colegas. Naturalmente a frustração irá ser o resultado final desta investida (e não raro a pessoa odiará o framework e sua comunidade até o fim dos seus dias).

Outra situação bastante comum: você precisa integrar seu sistema com alguma tecnologia, um hardware qualquer, por exemplo. Entra no Stack Overflow, busca por algo do tipo: “como ler dados de uma porta serial com Java”.

Encontra uma discussão que tem algum código fonte de exemplo. Copia para o seu projeto pessoal, altera um pouco aquele código fonte e a coisa funciona. A solução para o problema imediato está ali: a questão foi resolvida. Mas e no segundo (e terceiro, quarto…) momento, no qual é necessário entender por que a coisa parou de funcionar?

Tá, você poderia me dizer: “mas Kico, tudo em demasia faz mal, basta usar com sabedoria e bla bla bla bla bla”. O problema é que na esmagadora maioria das vezes noto as pessoas usando em demasia, o que mostra que há algo extremamente errado conosco e a maneira como estamos buscando conhecimento.

O conhecimento baseado em fóruns não passa de uma simples tentativa e erro. Talvez você encontre algo que te atenda, mas sem ter a base, jamais terá a certeza do seu funcionamento. No máximo sabemos que a coisa funcionou naquele caso.

(quanto ao Stack Overflow, confesso que detesto o próprio formato da coisa, que não promove discussões, mas sim uma forma extremamente rudimentar que visa apenas sanar dúvidas imediatas. Já escrevi sobre isto aqui)

O problema tá na web

Quando a Internet se popularizou me lembro bem que todos pensávamos que a partir daquele momento não haveria mais ignorância pois o conhecimento estava todo lá, acessível a qualquer um (que tivesse acesso à Internet). A impressão que tenho hoje é a de que na realidade a ignorância aumentou. Creio que a culpa esteja no link.

Sou da geração pré-internet: quando ela apareceu eu devia ter lá pelos meus 15 anos. Na minha época o guia não era uma alternativa, era minha única opção. Você não tinha dinheiro para comprar vários livros, então comprava um e, como um disco ruim, lia e relia várias vezes caso não tivesse gostado. E aquela leitura do início ao fim (mesmo que não necessariamente na ordem proposta pelo autor) nos obrigava a trilhar um caminho, a sedimentar camadas.

E sabe o que é interessante? Muita gente aprendia a programar pelo help das linguagens de programação (VB, Delphi, PowerBuilder), e normalmente os que se tornavam melhores eram justamente aqueles que haviam estudado horrores seguindo um guia, e não os links dos arquivos de ajuda. (o help de ontem era a web de hoje)

Na web a coisa é diferente: você começa a ler um texto e de repente topa com um link. Clica nele, e vai para outra página, e depois outra, e outra, e outra. No final das contas, o guia sumiu. Em seu lugar entrou um processo que, no frigir dos ovos, não passa de tentativa e erro. Se tiver dado muita sorte, continuou no mesmo assunto que iniciou sua pesquisa.

E ainda mais interessante: com os motores de busca você diz o que precisa saber naquele momento (“como renderizar um cubo em OpenGL”). E sem base alguma você topará com uma resposta em um fórum, contendo aquele código fonte perfeito, que basta copiar e colar para o seu projeto.

A ideia da teia (web) nos remetia a uma certa harmonia, mas na prática o que temos é uma daquelas teias feitas por aranhas que se encontram sob o efeito de narcóticos. Você não sabe o que vai encontrar, nem se aquilo que encontrou de fato resolve seu problema.

webondrugs

E para piorar a situação há a pressão do dia a dia. Seu chefe quer a solução na hora, você tem pouco tempo para resolver o problema. A web está ali: basta realizar uma busca, basta alterar um pouquinho aquilo que obteve na sua pesquisa… basta que o negócio funcione!

Pressa, informação fragmentada, falta de bases bem consolidadas… talvez esteja aí a base para que tantos livros técnicos e cursos online ruins estejam sendo criados.

Então o que faço?

Só tem uma solução: é encontrar um bom guia, por a bunda na cadeira e ler a coisa do início ao fim. Aliás, é importante saber ler também: não raro somos analfabetos funcionais (sobre como ler e minha própria história envolvendo este problema, veja este link).

Fóruns só servem como fonte secundária de conhecimento e troca de impressões a respeito de algo. Eles podem promover maravilhosas discussões e você aprender horrores com elas? Com certeza, basta lembrar de como era o GUJ em seu início. Entretanto, tal como Aristóteles, creio que para que haja uma discussão enriquecedora é fundamental que todos os participantes antes de mais nada saibam sobre o que estão falando.

E pra usar o fórum portanto… você primeiro vai ter de ler seu guia. Hegel tinha um bom nome para a cura deste problema: “paciência do conceito”.

Não tem como: você precisa ser paciente se quiser aprender algo. Ficar pulando de resposta em resposta dificilmente te fornece alguma base.

PS:

_ Mas e se eu não gostar de ler?
_ Se acostume com a mediocridade, pois você dificilmente sairá dela.

Acabo de publicar mais um guia: Usando Webpack

Acabei de publicar mais um guia pela Itexto: “Usando Webpack”. Este trabalho surgiu como um dos resultados das nossas pesquisas internas envolvendo o ferramental front-end (o próximo a ser publicado será sobre o npm).

Ao começar o estudo a respeito do vue-loader, algo que sempre me pareceu bastante complexo foi o Webpack, que é um module bundler baseado em Node.js (se você conhece Grails, pense em um “asset pipeline para HTML 5”). Não há como negar, o Webpack tem lá sua curva de aprendizado: por isto escrevi o guia com o objetivo de facilitar a adoção da ferramenta pela nossa equipe e, agora, vocês também.

Como todo guia da Itexto, este será um trabalho inacabado e totalmente aberto. Iremos evoluir o material conforme nossa experiência com ele progride e, dado que toda opinião é bem vinda, seu código fonte está totalmente disponibilizado no Github caso alguém mais queira dar sua contribuição.

É um guia escrito por um sujeito que pensa mais no back-end que n o front-end, sendo assim, espero que seja útil para você caso se encaixe neste perfil. :)

Você pode acessar o guia neste link: http://www.itexto.com.br/guias/?guia=usando-webpack

Espero que lhes seja útil!

Spring Brasil no ar, Grails Brasil e o poder das comunidades

Ontem colocamos no ar o Spring Brasil, que é um portal/fórum voltado para a comunidade de desenvolvedores que trabalham com o framework e todas as tecnologias relacionadas. O objetivo é em parte o mesmo que me motivou 9 anos atrás a criar o Grails Brasil: ajudar a divulgar estas tecnologias e aprender mais a respeito no processo.

Mas há uma diferença: Spring, ao contrário do Grails naquela época (e mesmo hoje) não precisa de gente que o divulgue pois já é há um bom tempo (mais de uma década provavelmente) o framework mais popular entre desenvolvedores Java. Então: pra quê este esforço?

Por que comunidades importam

Por um tempo pensei que o Stack Overflow fosse matar todos os fórums voltados a desenvolvimento da internet. Em parte matou, entretanto, apesar do sucesso estrondoso eu, pelo menos, nunca criei elos com outros participantes do site tais como os que criei no GUJ ou Grails Brasil.

O fórum ainda é vital, principalmente os quebra-paus

O foco no Stack Overflow e sites de Q&A é outro: resolver problemas de forma direta e não discutir. Por isto tantas perguntas que acho extremamente relevantes são travadas por moderadores (como esta). Isto sempre me incomodou (e muito). É a limitação do formato “Q&A”. Você está lá para ter uma solução do problema, não necessariamente para refletir a respeito e, mais importante, se aprofundar nele, e por isto, confesso, sempre desprezei o formato e não o segui no Grails Brasil, tal como tentaram fazer no GUJ.

Acredito no poder da discórdia. Pode não parecer, mas minha discussão favorita no Grails Brasil, sabe qual é? Esta: “Grails é horrível“. Seria fácil como mantenedor do site apagar o post, bloquear os membros (bloqueei um sujeito que fez flood, mas só por isto) e censurar o conteúdo dizendo se tratar de uma briga tola.

(não gosto daqueles que concordam com tudo e confesso curtir ver o circo pegando fogo)

Entretanto, se você ler a discussão inteira irá notar que aprendemos muito nela. É por isto que no Grails Brasil (e agora também no Spring Brasil) não temos moderadores no fórum. Confesso que não gosto desta figura: cria duas classes de pessoas quando deveria haver só uma: o participante que quer aprender ou ajudar os outros.

(há moderadores no Grails Brasil e Spring Brasil: eles cuidam apenas da aprovação de notícias para evitar spam, mas nunca houve uma notícia que não tivesse sido aceita nestes 9 anos)

E o mais interessante destas longas conversas é que elas costumam criar elos. Muitos dos clientes da itexto hoje surgiram destas discussões no GUJ e Grails Brasil. Sendo assim, não há como negar o aspecto socializador da coisa.

E os trolls?

E os trolls, como lidar com eles? Bom, nestes 38 anos algo que aprendi foi que você tem das pessoas o que espera delas. Se criarmos uma comunidade esperando o pior dos outros, teremos isto como retorno. Se é uma comunidade, pessoas normais se auto gerenciam, não precisam de tutores.

E se o troll aparecer? Ah, aí a gente lida com ele, mas existem mecanismos no próprio fórum que o evitam. Quer um exemplo? A impossibilidade de editar perguntas ou respostas que muitos reclamaram comigo nestes anos (talvez mude um pouco, mas muito pouco, em um futuro próximo). Por que você não pode editar ou excluir este conteúdo? Simples: para garantir a honestidade intelectual do diálogo.

Nestes 9 anos de Grails Brasil, quantos trolls tivemos? Um. Talvez por a comunidade ser muito menor que as demais, entretanto, creio que o mesmo se repetirá no Spring Brasil ou qualquer outra comunidade que venhamos a lançar no futuro.

Por que boa parte do ecossistema Spring é desconhecida

Esta é outra boa razão: o Spring Framework (e agora o Spring Boot) são muito bem conhecidos na nossa comunidade. Entretanto, conversando com o pessoal observo que, tirando estes projetos, o único conhecido de fato é o Spring Security.

E há uma enorme quantidade de projetos que podemos discutir e nos aprofundar nesta comunidade: basta ver a página dos projetos no spring.io. Então há muito o que aprender, e isto me empolga bastante!

Coisas que estão por vir

 

No sábado colocamos no ar o primeiro release do Spring Brasil que contém as mesmas funcionalidades presentes no Grails Brasil (é o mesmo código fonte, porém com algumas melhorias). Em um futuro próximo queremos melhorar incluindo algumas novidades:

  • Publicação de vagas de emprego
  • Melhoria no portólio pessoal dos membros para que possam expor seus trabalhos e currículo
  • Divulgação de eventos
  • Criação de uma nova newsletter, tal como a Semana Groovy
  • E, claro, o que for sugerido pelos membros da comunidade

Eventualmente todas estas mudanças irão voltar para o Groovy e Grails Brasil pois, como disse, é o mesmo código-fonte.

E nove anos depois…

Nove anos depois vamos fomentar mais comunidades, primeiro com o Spring Brasil, depois com outras que sabemos ser importantes na comunidade de desenvolvimento nacional.

Conto com a participação de vocês nesta nova jornada: espero fazer um número de amigos e parceiros tão grande quanto foi realizado com o Grails Brasil.

Link para a comunidade: http://www.springbrasil.com.br

Para se registrar, acesse este link: http://springbrasil.com.br/membro/registro . É possível se conectar usando Facebook (mais redes sociais estão a caminho), sendo assim o processo de entrada fica muito mais fácil (algo que devia ter feito no Grails Brasil anos atrás).

Conto com vocês!