ridiculously-old-computer

Código legado: um exercício de arqueologia e compaixão

Na esmagadora maioria das vezes que escuto alguém reclamando do fato de estar lidando com código legado me vêm um dos dois pensamentos a seguir : “chorão detected” ou “tá reclamando da coisa errada”. Também não é raro ver software ser jogado fora para ser reescrito do zero e sentir aquela certeza de que irá dar errado e dá. A postura diante do legado é errada. Amo legado e vou te contar as razões.

Minha evolução com o legado

evolution

Quando comecei a programar sequer pensava na possibilidade de lidar com código alheio. Aliás, eu só via código que fosse um exemplo ou outro que usava para aprender por simples cópia. Até que o legado caiu sobre mim e, junto com ele, hoje percebo, uma forte dose de arrogância.

“Arrogância é a confiança excessiva nas próprias habilidades.” – Norberto Bobbio

Olhava  para o código escrito por outros colegas, a maior parte pessoas que não atuavam mais na empresa (e jamais conheci) e os tinha como algo tosco. Me perguntava como a pessoa não sentia vergonha de deixar aquele “legado”. Pegava aquele “trem” e reescrevia do zero. Sentia o triunfo e me orgulhava do feito: expunha aos demais como um troféu que erguia alto para que todos vissem.

(e hoje vejo diversas daquelas mesmas pessoas como heróis)

“Curiosamente” tempos depois eu precisava alterar novamente aquele código que havia reescrito por que “um ponto ou outro não haviam sido levados em consideração”. O tempo passou e hoje fica claro que era um sintoma.

O tempo voa e trabalhei em projetos iniciados e finalizados por mim, apenas iniciados por mim e tantos outros que não foram iniciados por mim. E nesta história bem mais de 50% da minha carreira foi gasto manipulando código que não fui o pai, mas no máximo um padrinho ou tio generoso.

Aos poucos passei a gostar do legado que foi se tornando meu maior professor. Aprendo, cresço e enriqueço hoje graças a ele. Enquanto foi meu adversário eu era símio: hoje que o tenho como parceiro sou “sapiens” (ou penso ser (arrogância?)).

Como o legado se tornou meu parceiro

Percebi o valor do legado quando minha arrogância me socou a cara. Lembra no início deste post quando falei de um “certo sintoma” que ocorria quando eu reescrevia algo do zero? Yeap: eu estava jogando fora conhecimento importante sem me dar conta. Não estava melhorando a criatura, mas piorando-a. E sabem o que é legal? Só caiu a ficha quando o Joel Spolsky “me contou”. Bendito tapa!

Foi quando percebi que eu só olhava para o código e não o lia. Por coincidência na época fazia uma matéria no curso de Filosofia sobre hermenêutica e este acabou me indicando o caminho: não era apenas ler, mas sim interpretar e absorver. Eu devia “absorver como Kico” e “interpretar como quem o escreveu”.

(Quando você acorda para o fato de que mais de 85% da vida do software ocorre depois que é entregue fica nítido que a sua visão de mercado “talvez” fosse bem limitada. :) )

Legado como arqueologia e compaixão

Minha dificuldade ao interpretar o legado estava em meu ego. Por que com tantos SGBDs disponíveis o sujeito tinha de usar JUSTO O MALDITO MICROSOFT ACCESS para aquela aplicação Delphi/VB? Por que tantas classes anônimas naquela aplicação desktop Java? Por que aqueles padrões de projeto tão fora da nossa realidade naquele projeto Java EE?  Te respondo: por que quem escreveu o sistema muito provavelmente (quase 100% de certeza) aprendeu a fazer daquele jeito.  Duvida? Leia algum livro antigo sobre Delphi, Java ou Java EE. Como sei isto? Nas fotos abaixo está uma mínima parcela das “evidências” que acumulo no escritório (e que se um dia Nanna jogar fora teremos uma briga séria).

java_magazines

Revistas antigas valem OURO

pilha_de_ouro

Livros antigos também (e alguns tem diamantes no meio!)

Quando um cliente me procura com um sistema antigo uma das primeiras coisas que me diz é: “acho ele velho, gostaria que fosse reescrito do zero”. Meu primeiro passo é discordar e iniciar o trabalho arqueológico: compro livros publicados na mesma época das tecnologias usadas naquele software, corro atrás de revistas relacionadas, navego por antigos fóruns, artigos, blogs, enfim: inicio um processo de pesquisa profundo, como se fosse um livro.

O objetivo é ter compaixão. O que é compaixão? É o posicionar-se no lugar do outro e com isto entender seu modo de agir. Se conseguir acesso direto ao programador, melhor ainda! Posso saber mais a respeito do seu ambiente de trabalho na época, talvez suas frustrações e como isto influenciou o seu código. Isto me permite inclusive, quando meu ego está fora de alcance, saber se aquela pessoa de fato sabia o que estava fazendo (tem noção da quantidade de pessoas (me incluo) que aprendeu a programar usando arquivos de ajuda?).

Muitas vezes tento construir um ambiente de desenvolvimento próximo ao da época. Consigo isto tendo em casa alguns computadores mais antigos, de preferência com o software daquele tempo. Isto me permite eliminar o risco de estar lidando com incompatibilidades com versões atuais das bibliotecas, sistema operacional (máquinas virtuais valem ouro), etc.

(acredite, quando você se depara com uma máquina cujo HD tem 80 Mb e seu PC 16 Mb de RAM você passa a entender imediatamente o porquê da forma daquele código)

Agora que tenho o modo de pensar e o ferramental da época posso trabalhar com segurança e ver como o software funcionava naquela época.

Como evoluo legado

Com base nestas informações, aí sim altero o código fonte. Se fica nítido que o programador não conhecia a tecnologia, o trabalho fica fácil: consigo melhorar a qualidade apenas aplicando as boas práticas da época. Repare: não vou fazer uma transposição direta para o presente ainda. Chamo esta fase de “restauro” pois não estou evoluindo arquiteturalmente a criatura, mas sim “colando alguns cacos soltos com testes e muita paciência”.

Sim, eu adoro "Mestres da Restauração" que passa no History Channel!

Sim, eu adoro “Mestres da Restauração” que passa no History Channel!

Feitas estas melhorias implemento uma ou outra nova funcionalidade que o cliente queira. Normalmente a produtividade está alta neste ponto pois já conheço a criatura. O processo de upgrade é gradual e nunca direto. Por exemplo: se o sistema é feito em Delphi 3, não vou migrá-lo direto para o Delphi XE. Primeiro passo pelo Delphi 4, depois 5 e por aí vai. (faço muito isto com versões antigas do Grails).  Muitas vezes há recursos da época que não foram usados na aplicação: em alguns casos é quase um upgrade.

(e este processo de upgrade de plataforma muitas vezes é desnecessário. Será que seu sistema em Grails 1.3 precisa realmente do Grails 2.4?)

Se a plataforma tecnológica não é mais suportada (FoxPro, Visual Basic, Clipper, algum framework que “não existe mais”), sei exatamente em qual ponto parar. Daí pra frente precisamos decidir se há de fato algo que possa ser reaproveitado naquele sistema, se é possível encapsulá-lo de alguma forma ou mesmo se a partir daquele momento podemos iniciar um trabalho de reescrita (sempre o último caso) tendo como base a geração de alguma forma de documentação.

Se algo funciona torço para que meu ego não a quebre.

Minha visão de TI graças ao legado

O principal ganho que o legado me trouxe foi uma visão muito mais rica sobre as tecnologias que vejo serem lançadas. É incrível como diversas das coisas que as pessoas hoje bradam como novidade são apenas a reencarnação de algo que funcionou muito bem (ou não) no passado. Virtualização como algo moderno? Na década de 60 o OS/360 já tinha. Execução dinâmica de código? CODASYL previa na década de 50. Manifesto reativo? Olha para os mainframes. E por aí vai…

Você adquire mais pontos para fazer conexões entre as coisas: fica mais fácil assimilar a “novidade” que, na maior parte das vezes é uma nova roupagem ou ponto de vista sobre algo que já foi resolvido no passado e agora estão redescobrindo ou aperfeiçoando.

Não é raro que eu leia sobre tecnologias do passado que provavelmente nunca vou tocar (mainframes, COBOL, Clipper). Não tanto por que eu “adquira mais pontos”, mas sim por que passo a ter um respeito muito maior por aqueles profissionais do passado que com tão “pouco” criaram as bases deste mundo incrível que temos hoje.

(tenho uma imensa lista de heróis entre estes profissionais)

Concluindo?

Espero neste post ter exposto o aspecto positivo do legado que, a meu ver, supera em muito o “negativo”. As reclamações que fazemos ou ouvimos costumam gerar esta imagem terrível de algo que, convenhamos, além de ser um mercado imenso e muito maior que o “green field” também nos fornece uma visão de TI muito mais profunda.

Acredito que  este “mal estar” diante do legado se deva em grande parte à nossa formação. Nas faculdades e cursos técnicos é muito raro termos exercícios que exijam dos alunos interpretar e entender código: na maior parte das vezes você apenas escreve. Talvez se houvesse uma matéria de “arqueologia” ou mesmo hermenêutica a coisa fosse muito diferente.

Também acredito que seja importante saber do que estamos reclamando. Será que é do código legado ou da empresa que não nos permite lidar direito com ele devido a uma má gestão? Será que a reescrita é realmente o melhor caminho sempre? Será que os problemas que temos não é a simples falta de compaixão e nossa pressa exagerada para resolver logo o problema e com isto nos impede de pensar (e aprender)?

Esta é minha visão sobre o legado. Torço para que tenha mudado a opinião de alguém aqui.

PS:

e só pra lembrar: o legado também serve para separar as crianças dos adultos. :)

Semana Groovy 21! (atrasada, mas saiu!)

Tarda mas não falha: uma semana com poucos posts (uma gripe brutal me dominou) mas com uma proposta interessante para vocês. :)

Posts

AngularJS Grails Template – já quis usar AngularJS com Grails e não sabia por onde começar? Craig Burke escreveu dois posts em seu blog sobre o assunto: Parte 1 ( http://www.craigburke.com/2014/11/17/angular-grails-template-1.html ), Parte 2 ( http://www.craigburke.com/2014/11/24/angular-grails-template-2.html )

How to use Groovy Traits – aprenda este poderoso recurso da linguagem Groovy – http://www.oodlestechnologies.com/blogs/How-to-use-Groovy-Traits

That which we call POGO, By Another Name – Um post bem bacana sobre o deslumbramento do autor com o POGO (Plain Old Groovy Object) contra o nosso já conhecido POJO (Plain Old Java Object) – http://www.accelebrate.com/blog/call-pogo-name/

Vamos fazer commits no código fonte do Grails?

Que tal conhecer a fundo e possívelmente ajudar a equipe de desenvolvimento do Grails a resolver as issues para o lançamento das versões 2.4.5, 2.5.0 e 3.0.0 do framework? Inicialmente precisamos conhecer melhor como é organizado o código fonte do framework. Em seguida, nos sentindo mais à vontade, podemos já tentar dar as nossas primeiras contribuições ao projeto com nosso próprio código fonte!

É uma experiência muito enriquecedora para ambos os lados e os participantes poderão ter um conhecimento bem mais profundo sobre o Grails e as tecnologias envolvidas. Podemos começar com uma série de encontros por Hangout para discutirmos o que aprendemos (e também, quem sabe, até mesmo nos conhecer melhor). Os interessados podem me procurar por e-mail: kicolobo@itexto.net . Claro: também planejo alguns posts para /dev/Kico. :)

Antes, que tal alguns detalhes sobre o código fonte para começar?

Você pode acompanhar as issues do projeto (e abrir as suas caso tenha encontrado algum bug ou oportunidade de melhoria) aqui – https://jira.grails.org/browse/GRAILS/

Quer ver como é o código fonte? Acesse o repositório no GitHub – https://github.com/grails/grails-core/

Guia para desenvolvedores – https://grails.org/Developer+Guidelines

Grails under the Hood – Apresentação do Graemer Rocher sobre a parte interna do Grails – https://www.youtube.com/watch?v=k2xrRP59fHE

Posts clássicos

Repensando a arquitetura de processamentos em lote – iniciando a pesquisa para um projeto encontrei um material maravilhoso sobre processamento em lote: a documentação oficial do projeto Spring Batch. Se você não tem interesse em usar o produto, vale muito à pena ler os capítulos 1, 3 e 11 da documentação, pois eles mostram diversos padrões de projetos e decisões arquiteturais que podemos tomar neste nicho de aplicação. Segue o link: http://docs.spring.io/spring-batch/trunk/reference/html/index.html

Making reliable distributed systems in the presence of software errors – esta é uma tese escrita por Joe Armstrong (um dos criadores da linguagem Erlang) sobre como projetar sistemas robustos sabendo que os mesmos podem conter erros. Pessoalmente, a parte relativa ao Erlang achei meio chata, mas a introdução e os conceitos arquiteturais são muito interessantes. Uma leitura extremamente enriquecedora – https://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

Assine nossa newsletter! 

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

semana_groovy

Semana Groovy 21!

Tarda mas não falha: uma semana com poucos posts (uma gripe brutal me dominou) mas com uma proposta interessante para vocês. :)

Posts

AngularJS Grails Template – já quis usar AngularJS com Grails e não sabia por onde começar? Craig Burke escreveu dois posts em seu blog sobre o assunto: Parte 1 ( http://www.craigburke.com/2014/11/17/angular-grails-template-1.html ), Parte 2 ( http://www.craigburke.com/2014/11/24/angular-grails-template-2.html )

How to use Groovy Traits – aprenda este poderoso recurso da linguagem Groovy – http://www.oodlestechnologies.com/blogs/How-to-use-Groovy-Traits

That which we call POGO, By Another Name – Um post bem bacana sobre o deslumbramento do autor com o POGO (Plain Old Groovy Object) contra o nosso já conhecido POJO (Plain Old Java Object) – http://www.accelebrate.com/blog/call-pogo-name/

Vamos fazer commits no código fonte do Grails?

Que tal conhecer a fundo e possívelmente ajudar a equipe de desenvolvimento do Grails a resolver as issues para o lançamento das versões 2.4.5, 2.5.0 e 3.0.0 do framework? Inicialmente precisamos conhecer melhor como é organizado o código fonte do framework. Em seguida, nos sentindo mais à vontade, podemos já tentar dar as nossas primeiras contribuições ao projeto com nosso próprio código fonte!

É uma experiência muito enriquecedora para ambos os lados e os participantes poderão ter um conhecimento bem mais profundo sobre o Grails e as tecnologias envolvidas. Podemos começar com uma série de encontros por Hangout para discutirmos o que aprendemos (e também, quem sabe, até mesmo nos conhecer melhor). Os interessados podem me procurar por e-mail: kicolobo@itexto.net . Claro: também planejo alguns posts para /dev/Kico. :)

Antes, que tal alguns detalhes sobre o código fonte para começar?

Você pode acompanhar as issues do projeto (e abrir as suas caso tenha encontrado algum bug ou oportunidade de melhoria) aqui – https://jira.grails.org/browse/GRAILS/

Quer ver como é o código fonte? Acesse o repositório no GitHub – https://github.com/grails/grails-core/

Guia para desenvolvedores – https://grails.org/Developer+Guidelines

Grails under the Hood – Apresentação do Graemer Rocher sobre a parte interna do Grails – https://www.youtube.com/watch?v=k2xrRP59fHE

Posts clássicos

Repensando a arquitetura de processamentos em lote – iniciando a pesquisa para um projeto encontrei um material maravilhoso sobre processamento em lote: a documentação oficial do projeto Spring Batch. Se você não tem interesse em usar o produto, vale muito à pena ler os capítulos 1, 3 e 11 da documentação, pois eles mostram diversos padrões de projetos e decisões arquiteturais que podemos tomar neste nicho de aplicação. Segue o link: http://docs.spring.io/spring-batch/trunk/reference/html/index.html

Making reliable distributed systems in the presence of software errors – esta é uma tese escrita por Joe Armstrong (um dos criadores da linguagem Erlang) sobre como projetar sistemas robustos sabendo que os mesmos podem conter erros. Pessoalmente, a parte relativa ao Erlang achei meio chata, mas a introdução e os conceitos arquiteturais são muito interessantes. Uma leitura extremamente enriquecedora – https://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf

Assine nossa newsletter! 

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

semana_groovy

Semana Groovy 20!

Trabalhar no exterior (ou talvez aqui mesmo) com Grails?

Find Grails Jobs – Procurando trabalho com Grails fora do Brasil? Este site é bastante interessante e talvez possa lhe ajudar. :) – http://findgrailsjobs.com/

Posts

Recursos sobre Groovy e Grails para quem quiser aprender mais! – Publiquei este post no blog do Instituto Pangea logo após o Webinar (“Um Java EE diferente com Groovy e Grails”). Nele vocês poderão encontrar uma série de recursos para quem já está começando e também falo de alguns “recursos futuros” interessantes. – http://www.institutopangea.org/blog/23-recursos-sobre-groovy-e-grails-para-quem-quer-aprender-mais?a=110

StringTemplates in Groovy – Uma ferramenta muito útil do Groovy e que poucas pessoas usam. É o que uso no Grails Brasil para enviar e-mails, diga-se de passagem :) – http://www.objectpartners.com/2014/11/11/stringtemplates-in-groovy/

New Blog: Ratpack’s execution model in practice – RatPack é um destes frameworks que você deve prestar atenção mesmo que jamais o use pois tem algumas idéias muito boas ali. Encontrei este post interessante sobre seu modelo de execução e aqui está ele para vocês: http://www.grails.info/2014/11/13/new-blog-ratpacks-execution-model-in-practice/

Painless AOP with Groovy – Este é um post bem antigo (2006, mostra inclusive um Groovy diferente do atual) mas que mostra bem o poder do Groovy. Como disse em minha apresentação no DevDay 2014, você conhece o poder de uma linguagem quando ela te possibilita acessar paradigmas de forma simples. Smalltalk fez isto com OO e, adivinha? Groovy faz isto com AOP! – http://www.infoq.com/articles/aop-with-groovy (dica: na minha apresentação expus algo bem mais simples)

Lançamentos

Spring Boot 1.1.9 – http://spring.io/blog/2014/11/12/spring-boot-1-1-9-released

Spring Framework 4.1.2, 4.0.8 e 3.2.12 – http://spring.io/blog/2014/11/11/spring-framework-4-1-2-4-0-8-3-2-12-released

Gradle 2.2 – http://forums.gradle.org/gradle/topics/gradle-2-2-released

GORM para Cassandra – http://grails.org/plugin/cassandra

Dois convites

Hangout Semana Groovy – em breve devo iniciar uma série de hangouts sobre Groovy e Grails em meu canal ( http://www.youtube.com/kicolobo ). Seria uma experiência muito bacana saber suas experiências a respeito destas tecnologias. Interessou? Contacte-me por e-mail para que possamos agendar o primeiro! kicolobo@itexto.net

Conteúdo para Semana Groovy – está fazendo relacionado a Groovy, Grails, Spring ou qualquer coisa que execute na JVM e gostaria que fosse divulgado aqui? Entre em contato comigo usando o e-mail que citei acima. :)

Assine nossa newsletter!

Quer receber esta newsletter por e-mail no momento em que for publicada? Basta se inscrever preenchendo este formulário!

semana_groovy

Semana Groovy 19!

Após quatro semanas de hiato Semana Groovy volta à normalidade com uma série de novidades para vocês. O hiato foi motivado em grande parte por boas razões como verão nesta newsletter!

Eventos

Ainda dá tempo! – Webinar “Um Java EE diferente com Groovy e Grails” - Dia 11/11 às 20 horas, estarei ministrando este webinar gratuito em que apresentarei nossas duas tecnologias favoritas. Será bastante interativo, com muito live coding (e cujo código fonte você poderá acessar na sua máquina em tempo real). Vale muito à pena se inscrever pois caso não possa participar você terá acesso à gravação do evento pelo site do Instituto Pangea – Mais detalhes no /dev/Kico – http://www.itexto.net/devkico/?p=2040   (farei um anúncio muito bacana neste webinar, fiquem ligados!)

DevDay 2014 – Falei sobre Groovy e Grails na palestra “Alta produtividade em Java EE com Groovy e Grails” no dia 1/11/2014. Foi uma experiência fantástica e, pelo que pude ver, quem compareceu gostou bastante. A organização do evento já está editando os vídeos das palestras, que devem sair em breve, mas enquanto isto, você pode pelo menos ter acesso aos meus slides para ter uma noção de como foi – http://pt.slideshare.net/loboweissmann/slides-final-41029521

Comunidades

Novidades importantes nesta área!

MG-JUG está de volta! – Se você mora em Minas Gerais e quer conhecer melhor as empresas e pessoas que trabalham com Java (claro: Groovy e Grails também), uma boa notícia: estamos voltando com o MG-JUG. A idéia é agendarmos pelo menos um evento por mês contendo apresentações e também alguns encontros pela cidade. Caso se interesse, cadastre-se no site que foi criado no Meetup! – http://www.meetup.com/MG-JUG/

Instituto Pangea – Uma iniciativa da comunidade de Arquitetura de Software Pangea ( http://www.pangeanet.org ): trata-se de uma comunidade virtual voltada para a capacitação e atualização em tecnologia. São ministrados cursos (aguardem novidades) e é também um portal no qual já começaram a aparecer artigos muito interessantes. – http://www.institutopangea.org

itexto – O novo site da itexto está no ar. Nele vai ser inserido algum material sobre Groovy e Grails também. Por que isto é importante para nós? Por que uma série de produtos e serviços baseados nas nossas tecnologias favoritas surgem da itexto e, ainda mais importante: eles financiam diversas iniciativas como, por exemplo, esta newsletter, cursos e apresentações. Além disto, é mais uma fonte que vocês poderão usar daqui para frente. O site ainda está em beta, sendo assim todo feedback é bem vindo, ok? – http://www.itexto.com.br

Groovy Blogs está de volta! – o agregador de blogs sobre tecnologias baseadas em Groovy está de volta e totalmente renovado. Vale muito à pena conferir caso não conheça! – http://www.groovyblogs.org/

Apresentações

Idiomatic Spock – Encontrei esta apresentação no site da GR8Conf e achei muito interessante. Vale à pena assistir pois já faz algum tempo que o framework de testes do Grails passou a ser o Spock e até hoje vejo pouca gente de fato dominando a ferramenta. Vale cada segundo! – https://www.youtube.com/watch?v=dvDoieRf4po

Groovy: por que e pra que? – Dois vídeos que você só vai encontrar no novo site da itexto. O primeiro (por que) mostra alguns problemas e o segundo (o que) é uma visão panorâmica sobre a linguagem. Boas justificativas para se adotar Groovy. Espero que gostem! – http://www.itexto.com.br/site/?page_id=313

Developer Tooling – What’s new and what’s next – Uma excelente apresentação na InfoQ sobre o que podemos esperar do SpringSource Tool Suite. IntelliJ que se prepare?  – http://www.infoq.com/presentations/spring-4-tools-update

Posts

As pontes Groovy e Grails – mostro o grande valor de Groovy e Grails: o fato de nos permitirem aprender coisas novas sem precisarmos jogar fora aquilo que já conhecemos. Falei sobre isto no DevDay 2014, talvez torne mais claros os slides. :) – http://www.itexto.net/devkico/?p=2025

Produtividade pra que, quem e como? – Outro ponto que vocês vão encontrar nos meus slides e talvez não entendam, mas que se tornará mais claro lendo este post de /dev/Kico – http://www.itexto.net/devkico/?p=2009

Experiences publishing a Grails plugin – Já escreveu um plugin Grails (ou gostaria de saber como) e gostaria de ver a experiência de alguém a respeito? Este é um excelente post cuja leitura recomendo. – http://www.objectpartners.com/2014/10/29/experiences-with-publishing-a-grails-plugin/

Lançamentos

Groovy Serv 1.0 – Não conhece? Ele torna o início de scripts Groovy muito mais rápido, confira! – http://kobo.github.io/groovyserv/changelog.html

Ratpack 0.9.10 – http://www.ratpack.io/versions/0.9.10

Quer ajudar na Semana Groovy?

Publico aqui os links e acontecimentos que acredito serem os mais importantes relacionados a Groovy, Grails, Spring e Java em geral. No entanto, sempre pode haver alguma coisa que não vi e vocês considerem importante. Caso seja o caso, entrem em contato comigo para que este conteúdo seja divulgado na comunidade, ok? Basta me chamar pelo Twitter ( http://www.twitter.com/loboweissmann ) ou Facebook ( http://www.facebook.com/devkico )

webinar-groovy-grails-11-11-2014

Participe do meu webinar sobre Groovy e Grails dia 11/11!

Quer conhecer o “tal do Groovy e Grails” que falo tanto a respeito por todos estes anos? Dia 11/11, terça feira, às 20 horas (horário de Brasília) estarei ministrando no Instituto Pangea o webinar gratuito “Um Java EE diferente com Groovy e Grails”.

Vou começar mostrando de uma forma bem panorâmica o que é Groovy: o que ele tem de parecido e diferente com Java e outras linguagens? O que nos oferece? Por que vale à pena aprender? Como disse em meu último post, trata-se de uma tecnologia de ponte e uma excelente linguagem de programação.

Em seguida será apresentado Grails: vou criar uma aplicação do zero e durante sua construção serão apresentados os principais conceitos por trás do framework e de que maneira ele nos propicia obter altíssima produtividade (e veremos também qual produtividade é esta) mantendo (e, quem sabe, aumentando?) a qualidade dos nossos sistemas.

Prometo que serão poucos slides e muito live coding. Claro: de uma maneira bastante informal para que aproveitemos cada minuto!

Como participar

Você deve se cadastrar no site do Instituto Pangea clicando neste link. Lembre-se de fazer o mais rápido possível, pois as vagas são limitadas!

logo-institutopangea-cabecalho

Instituto Pangea?

É uma iniciativa muito bacana do Adriano Tavares: uma extensão da comunidade Pangea, que é a nossa melhor comunidade de arquitetos do Brasil. Lá são ministrados cursos online (aguardem novidades em breve ;) ) e também são publicados artigos escritos por membros proeminentes da comunidade de desenvolvimento de software.

Então…

Aguardo vocês terça feira. Haverá tempo para perguntas, então poderemos nos conhecer melhor e sanar suas dúvidas a respeito destas tecnologias.

Ei: cadê o link para o webinar? Tá aqui. :)

Update 6/11 – O webinar será gravado

Um pequeno detalhe que esqueci de mencionar: o webinar será gravado e será disponibilizado para todas as pessoas que se inscreverem no evento.