Rails Rumble: Código e Diversão :)

Nos dias 15, 16 e 17 de Outubro participei do Rails Rumble, um evento mundial de desenvolvimento de software com Ruby on Rails. O objetivo do evento: promover uma competição entre centenas de equipes espalhadas por todo o mundo, quem desenvolve o site mais “legal” utilizando Ruby on Rails, num período de 48 horas corridas!

Eu participei da equipe Cangaceiros, junto com o Cristiano Milfont, Rodrigo Oliveira e Henrique Gogó. Um colega deles teve um problema e não poderia participar, então eu acabei entrando na equipe no lugar deles de última hora. Para ser mais exato, até as 18 horas da sexta-feira, eu não sabia se iria participar ou não do Rumble, que iria começar as 21 horas :)

A idéia que eles tiveram foi a construção de uma biblioteca virtual, onde os usuários poderiam subir seus PDFs e  compartilhar com os outros usuários. O resultado pode ser conferido em http://cordel.r10.railsrumble.com :) Claro que não conseguimos implementar tudo o que nós gostariamos, mas no fim eu fiquei contente com o resultado.

A nossa equipe tinha um pequeno problema: eu estava aqui em São Paulo, e eles estava em Fortaleza. A comunicação foi bastante prejudicada pela distância mas no fim conseguimos superar esse problema usando Skype e Twitcam, embora eu tenho certeza que seria muito mais fácil e mais divertido se nós estivessemos numa mesma sala. Acabei aprendendo várias coisas que me foram muito úteis no dia seguinte, pois a minha próxima tarefa no meu projeto atual era criar o ambiente de produção de uma aplicação em Rails. E também nós utilizamos Solr com Sunspot para indexação, ferramentas que eu nunca tinha usado em um projeto em produção.

Conforme foi passando o evento, o cansaço foi dominando, a produtividade, a paciência e a criatividade foram diminuindo, pois eu acabei dormindo muito pouco na madrugada de sábado para domingo. Mas quando fizemos o deploy em produção, nos últimos 30 minutos (usando as mais avançadas técnicas de XGH), fiquei muito contente com o resultado :)

Foi muito divertido participar desse tipo de evento. É algo empolgando, por que todos nós estavamos construindo todos aqueles sistemas por diversão. Estavamos trabalhando em algo por que nós gostamos de desenvolver software com Ruby on Rails. Também não estavamos apenas construindo cadastrinhos chatos e relatórios bobos para empresa XPTO, usando uma tecnologia velha definido por um grupo de arquitetura arcaico, estavamos implementando uma idéia nossa, usando as nossas ferramentas preferidas.  Eu pretendo participar todos os anos do Rails Rumble e recomendo muito essa experiência :)

Não posso deixar de agradecer a GoNow por abrir gratuitamente seu escritório para várias pessoas de outras empresas, fornecendo toda a infraestrutura necessaria, bem como lanches, pizzas, Red Bulls, bebidas, etc :)

Também agradeço aos cangaceiros Cristiano MilfontRodrigo OliveiraHenrique Gogó :) Foi muito legal trabalhar com vocês no Rails Rumble :)

Java language end of life (aka. Java as a platform)?

Deve fazer mais um menos uns 5 anos que a maioria de nós ouvimos falar em Ruby on Rails. De lá pra cá, a adoção da linguagem Ruby e do framework Rails subiu de uma forma surpreendente, ajudando a quebrar um pouco a polarização Java<->.Net que tínhamos antes. É claro que Ruby ainda não atingiu a popularidade Java ou de .Net, principalmente aqui no Brasil, mas mesmo assim ajudou a comunidade como um todo a repensar vários aspectos do desenvolvimento de software, principalmente de aplicações web.

Uma das coisas que a revolução do Ruby on Rails fortaleceu é o uso de outras linguagens na Java Virtual Machine. É claro que antes de surgir o Rails já existiam várias iniciativas para rodar outras linguagens dentro da JVM, mas depois de uns anos pra cá esse assunto ficou cada vez mais importante, pois existe muito interesse em rodar aplicações desenvolvidas usando ferramentas produtivas como Ruby on Rails numa plataforma robusta como Java. Hoje tempos diversas engines que permitem rodar muito bem várias linguagens na JVM, como JRuby, Jython, Clojure, Rhino, Groovy, entre outras… Com essa quantidade de linguagens rodando na JVM, já faz alguns anos que se tem falado em Java como plataforma e não como linguagem.

Eu gosto muito dessa idéia, acho que as vantagens dessa abordagem já foram amplamente discutidas, mas resumindo:

  • Java possui uma das mais avançadas máquinas virtuais do mercado. O just-in-time compiler e o garbage collector da JVM, mesmo não sendo perfeitos, são frutos de anos de pesquisa e desenvolvimento, seria muito difícil implementar uma VM igual do zero para outras linguagens.
  • Existe um enorme legado de aplicações desenvolvidas em Java, utilizando Java como plataforma, novas aplicações em outras linguagens podem aproveitar muito do código já existente.
  • Java também possui excelentes servidores web e application servers bem estabelecidos no mercado

Infelizmente, já se passarem alguns anos que esse tipo de abordagem vem sendo discutida, mas não temos tantas empresas adotando Java como linguagem e não como plataforma. Quase todo mundo que desenvolve na plataforma Java usa a própria linguagem Java. Temos sim muitas empresas desenvolvendo novos projetos em Ruby on Rails, mas na maioria dos casos não estão rodando eles em Java. Pelo menos é o que eu tenho visto na nossa comunidade local.

Um dos motivos para isso é a dobradinha Passenger + Nginx (ou mesmo Apache) tem tido muito sucesso para rodar aplicações Rails. As pessoas não precisam recorrer ao JRuby para rodar aplicações Rails num ambiente com uma performance aceitável. O Passenger tem dado conta do recado.

Eu gostaria muito de ver mais empresas adotando Ruby on Rails, acho que poder reaproveitar código já existe e poder rodar numa infra-estrutura (VM + Application Server) já bem estabelecida são dois fatores que podem facilitar a adoção de Ruby on Rails em empresas que utilizam Java, mas não é algo fácil de ser feito. Ruby tem uma sintaxe diferente, um estilo de programação diferente. Leva algum tempo pegar uma equipe que trabalha muito bem com Java e deixar ela produtiva trabalhando com Ruby on Rails.

Recentemente, a ThoughtWorks recomendou que as empresas comecem a avaliar o “Java language end of life”, ou seja, usar outras linguagens na plataforma Java. Quando eu li essa recomendação achei meio precipitado, mas no fim é uma opção tecnicamente viável e pode trazer muitos ganhos de produtividade.

Eu acho que vai demorar muito até a grande maioria das empresas adotarem outras linguagens mais produtivas que Java, mas se você trabalha com Java tem a liberdade de escolher a tecnologia que você vai usar para desenvolver seus aplicativos, já passou da hora de considerar usar outras linguagens que rodam na JVM.

Reload automático de classes com JavaRebel, da ZeroTurnAround

Are you feeling lucky?Uma das coisas mais legais para um cara que desenvolve em Java e depois começa a desenvolver em uma linguagem como Ruby é o feedback instantâneo – basta você alterar o código-fonte e a alteração já é refletida imediatamente na Aplicacão em runtime. Programando em Java tem que passar pelo processo de compilação. Programando Java EE tem que esperar reiniciar o servidor. E isso leva muito tempo.

Um dos primeiros projetos que eu participei foi um software de billing utilizando a boa e velha “arquitetura J2EE”: um monte de EJB sendo utilizado para praticamente todas as operações. Nada contra a arquitetura montada em si (digo, neste post em particular não vou discutir isso, fica para um outro post EJB vs Spring/etc) mas um grande problema era o processo de build e deploy: ele era simplesmente muito demorado! Na melhor das hipóteses, levava uns 5 minutos para executar a build e o deploy no ambiente local de desenvolvimento, mas geralmente levava bem mais tempo. Ou seja, para cada alteração você tinha que esperar pelo menos 5 minutos para poder testar localmente o que você tinha feito.

Esse tipo de situação é muito comum nos projetos desenvolvidos em Java por aí. Como se não bastasse termos perder tempo compilando e empacotarndo o código, temos que reiniciar o servidor e esperar mais algum tempo… É claro que podemos minimizar o problema por usar um pacote expandido e o sistema de debug do Java para recarregar o corpo dos metodos, mas não é o suficiente, você ainda perderá preciosos minutos (ou horas) por dia só com build e deploy.

Eu acho fantástico ter a rapidez de codificar e logo em seguida, sem demorar um segundo sequer a mais, poder testar\executar o código criado ou alterado. É muito chato você ter que esperar todo esse tempo, você acaba com o tempo perdendo a paciência e juntando um monte de alterações para depois fazer a build e o deploy da aplicação. Eu particularmente não gosto disso, quanto mais rápido for o feedback, melhor.

esperando

Para amenizar essa situação, você pode usar a excelente ferramenta Javarebel, da Zeroturnaround. Javarebel é um plugin para a JVM (usando aquele esquema maluco do -javaagent) que faz o reload dos arquivos .class alterados sem precisar reiniciar a JVM! É quase que milagroso, basta apontar qual diretórioas suas classes estão localizadas que ele vai automagicamente aplicar as alterações feitas na aplicação em runtime!
Nada de parar a JVM, nada de reiniciar o servidor, nada de perder vários minutos esperando a aplicação voltar ao ar, as alterações são feitas e aplicadas na hora. Sempre que eu falo do JavaRebel pra alguém, me perguntam: “mas funciona mesmo?”. Faz uns 8 meses que eu estou usando o JavaRebel sem grandes problemas.

Infelizmente é uma ferramenta paga, não é muito caro, mas algumas pessoas evitam todas as ferramentas pagas, mesmo que custem barato. Eu mesmo só estou usando o JavaRebel por que eu ganhei uma licença numa promoção do tipo “primeiras pessoas que mandarem um e-mail ganham uma licença” :) Mas eu acho que vale a pena fazer um test-drive na ferramenta (tem um trial e um eles devolvem o dinheiro caso não esteja satisfeito em 30 dias).

A instalação e configuração é bem simples, o site deles tem uma documetação bem bacana, mas vai aí um resumão: Coloque o jar do javarebel na mesma pasta que o arquivo de licença do JavaRebel e adicione dois parâmetros na hora de subir a JVM:

  • -javaagent:caminho-do-jar-do-javarebel/javarebel.jar
  • -Drebel.dirs=diretório-com-os-arquivos-.class

E é basicamente isso :) Com esses dois parâmetros o JavaRebel vai automaticamente recarregar todas as alteraçõs feitas nos arquivos .class localizados na pasta passada no parâmetro -Drebel.dirs.

Algumas pessoas me perguntam pra que pagar e configurar se o sistema do debugger do Java já tem um jeito para recarregar classes alteradas. O problema do debugger do Java é que ele só recarrega o corpo dos métodos, se você criar uma classe, adicionar um método, remover um método, adicionar um parâmetro, etc, a sua classe não vai ser recarregada. No site do JavaRebel tem uma comparação bem interessante sobre esse assunto.

Infelizmente a ferramenta não é perfeita, tem uma ou outra incompatibilidade, por isso não acho uma boa idéia usar em ambiente de produção. Além disso, muitas vezes o reload da classe alterada não vai ter efeito algum,  por que os frameworks Java em geral se configuram no startup da aplicação e não são reconfigurados quando uma classe é recarreada. Por exemplo, criar uma classe anotada com @Entity não vai fazer o EntityManager enxerge a classe, só depois de ele ser reconfigurado (que geralmente ocorre quando a aplicação é reiniciada), no caso do JPA. O JavaRebel tem algumas gambiarras alguns plug-ins para alguns frameworks como Struts2 e Spring (recomendo não olhar o código para não se assustar).

Eu já usei no Tomcat, JBoss e no Jetty, usando a JVM da Sun, nas versões 1.4, 1.5 e 1.6, tanto no Windows como no Linux. No site deles, eles alegam ser compatíveis com várias VMs e containers:

Supported JVM’s
Sun Java 1.4.xi, 5.x, 6.x
JRockit JVM 8.1sp6 or later
JRockit JVM 9.x 1.5.0_06 or later
JRockit JVM 1.6.x
IBM J9 1.4.x, 5.x, 6.x
Apple MRJ 1.4.x, 5.x, 6.x

Supported JVM’s

  • Sun Java 1.4.xi, 5.x, 6.x
  • JRockit JVM 8.1sp6 or later
  • JRockit JVM 9.x 1.5.0_06 or later
  • JRockit JVM 1.6.x
  • IBM J9 1.4.x, 5.x, 6.x
  • Apple MRJ 1.4.x, 5.x, 6.x

Supported Containers

  • IBM WebSphere 6.x
  • BEA Weblogic 8.x, 9.x, 10.x
  • GlassFish 2.x
  • Oracle OC4J 9.x, 10.x
  • Tomcat 4.x, 5.x, 6.x
  • JBoss 3.x, 4.x, 5.x
  • Jetty 5.x, 6.x, 7.x
  • Caucho Resin 3.0.x
  • Jonas 4.x
  • Equinox OSGi (including Eclipse plugins)
  • IntelliJ IDEA plugins
  • Atlassian Confluence plugins

Não sei se em todos os casos vale a pena usar a ferramenta, desde que eu comecei a usar o JavaRebel não tive nenhum problema sério, só elogios á ferrementa, aumento consideravelmente a produtividade. Eu acredito que pelo menos uma teste vale a pena fazer, criei esse post por que percebi que muita gente ainda não teve a oportunidade ou a curiosidade de conhecer essa excelente ferramenta :)

Falando em Java 2009

Domingo eu estive presente na terceira edição do Falando em Java, organizado pela Caelum. Como nas outras edições, o evento foi bem legal, com palestras interessantes e foi uma oportunidade de rever o pessoal do GUJ.
Infelizmente eu não pude participar do evento na parte da manhã e cheguei só na hora do almoço.

A palestra sobre o VRaptor 3 foi ministrada pelo Guilherme Silveira e pelo Filipe Sabella (aka Lipe). Pelo que eu entendi, a versão 3 é uma evolução do framework com várias melhorias que a comunidade foi percebendo com o tempo, visando a flexibilidade e a facilidade de uso. Eles realmente querem deixar as “actions” do VRaptor bem limpas mesmo! Isso é um dos pontos positivos do framework, as “actions” nem parece que são “actions”, são POJOs de verdade. É muito bom ver um projeto nascido e mantido dentro da comunidade brasileira evoluindo. Não, eu não tenho problemas com o VRaptor por ter participado um “concorrente“, para mim, como desenvolvedor, é excelente ter boas alternativas para cada projeto. Parabéns para a equipe, boa sorte no processo de documentação (que é um saco fazer :P)

Depois eu assisti a palestra Arquitetura para aplicações Java de médio porte, apresentada pelo Sérgio Lopes e pelo Guilherme Moreira. A palestra apresentou algumas dicas legais que podemos usar no nosso dia-a-dia, alguns lembretes legais sobre como usar Hibernate de maneira eficiente, cluster, entre outras.

Uma palestra campeã foi a do Anderson Leite e Fabio Kung, Para onde vai a Plataforma Java? Linguages dinâmicas, JavaTV, JavaFX e além! Eles explicaram alguns detalhes da atual JVM, como são as instruções da JVM para invocação dos métodos em diversas situações e como será a próxima versão do Java estará melhor preparada para lidar com linguagens dinâmicas, com mecanismos como o invoke dynamic. Os “arquitetos J2EE” que se preparem… veremos cada vez mais projetos usando Java como plataforma e não como linguagem :)

Depois o Dr. Jim Webber falou sobre Restful e  Mediatypes. A palestra foi excelente e aumentou muito a minha visão sobre REST. O Jim tem um conhecimento muito bom sobre Restful e Http. Falou sobre muitas coisas interessantes e me deu idéias bem legais para os meus projetos. Com certeza vale a pena dar uma atenção mais forte ao REST como uma alternativa ao SOAP/WS-*. Fazendo uma rápida retrospectiva, todos os Webservices SOAP que eu fiz até hoje poderiam muito bem ser Restful Webservices.

O mais legal com que quem não foi no evento pôde acompanhar pelo Twitter. O pessoal do evento (eu incluso) ficava twittando em real-time o que acontecia no evento. Até hoje o pessoal faz muitos tweets sobre o evento (eu mesmo vou fazer um tweet quando terminar esse post apontando para o blog hehehehe).

Enfim, evento muito legal, como sempre :)

Aprendendo direito desde a faculdade…

Muitos desenvolvedores  tem  preocupações com o ensino superior da área de TI\Computação, achando que nem sempre o que é ensinado é o que praticado na realidade do mercado de trabalho brasileiro.  Alguns acham que os professores dizem já não se aplica á realidade a muito tempo ou então é algo meramente acadêmico, sem valor pro mercado de trabalho. Essa preocupação é extremamente compreensível, afinal, quem esta estudando hoje já esta trabalhando ou em pouco tempo estará trabalhando nos projetos de softwares pelo mundo a fora e os desenvolvedores que já estão no mercado há algum tempo vão ter que trabalhar com quem esta cursando ou acabei de sair de uma faculdade.

Recentemente conversei com um ex-colega do colégio técnico, que é um excepcional desenvolvedor e que esta cursando o quarto ano do curso de Engenharia de Computação numa das faculdades de maior renome do hemisfério sul.  Ele comentou que, na materia Engenharia de Software que ele teve no semestre passado, a professora resolveu desenvolver um projeto de software completo, passando por todas as fases, desde a análise de requisitos, passando por projeto e modelagem e até a implementação (sentiu a falta de algo ai?). Achei o relato dele muito interessante e pedi autorização dele para colocar a nossa conversa aqui no meu blog, pois o que ele passou se parece muito com a realidade do dia-a-dia de um desenvolvedor brasileiro…

Segue abaixo o que ele me disse no GTalk (com algumas pequenas alterações esteticas e removendo algumas interrupções minhas):

colega: Ela passou um projeto-monstro pra gente fazer durante o semestre. A gente ficou 1 mês fazendo levantamento de requisitos.  O projeto começou como uma coisa pra administrar as agremiações.
rubem:  (censurado)! Quer dizer que ensinam errado na faculdade??? (Um mês para levantar os requisitos de uma aplicação simples)

colega:  Depois ele ganhou todo o tipo de funcionalidade que você pode imaginar…  De avaliar professor até loja virtual. Depois a gente passou mais um mês fazendo projeto de interface, estimativas de custo e besteiras acessórias. 

colega:  Tinha dado uns 80 casos de uso… Daí ela falou “É, acho que tem muita coisa mesmo… Vocês podem cortar umas funcionalidades”. Daí a gente foi pra fazer o projeto .Como tinha muita coisa, ele deixou cortar mais uns 20 casos.

rubem:  aí acabou o semestre!
colega: Calma….
Daí a gente fez o projeto, com dezenas de camadas,  igual ela ensinou pra gente.  De um módulo que passa pro outro que passa pro outro….
E a gente fez o projeto numa ferramenta X que ela inventou que iria gerar os stubs pra gente programar depois e assim foi, até 2 semanas antes do fim do semestre.
Começou a parte de implementação…
Sobraram 5 casos de uso (Fazer login, fazer logoff, e coisas desse gênero)
O raio da ferramenta gerou centenas de classes de stub que, aliás, não compilavam. Passamos uns dias pra fazer as classes que não fazem nada compilar, daí a gente fez um módulo chamar o outro que chama o outro, etc, etc… centenas de classes que só terceirizavam o trabalho.
E, por fim, sobrou 1 semana pra fazer funcionar. Colocamos um módulo megazord embaixo pra fazer a interface com o Hibernate em cima pra acessar o banco e ficamos com centenas de classes inúteis no meio por que a professora queria!
Diz aí… Isso sim é engenharia de software, né?
rubem:  é… e você sabe o que é pior?
colega: ?
me: você descreveu um típico projeto de software produzido no mercado de trabalho :)

 

E aí, parece ou não parece um típico projeto de software? :)

Primeira, utilizaram a famosa pattern: faz análise de requisitos, modelagem, implementa, ops… não dá tempo de fazer tudo, gastei meses antes de começar uma única linha de código e entregar algo de valor para o cliente.

Segundo, não houve nenhuma preocupação com a qualidade. Nem sequer a famosa fase de testes, com as suas planilhas de testes e tudo mais.

Terceiro, tentaram utilizar uma ferramenta monstra para gerar código e automizatizar a implementação do projeto que mais atrapalhou do que ajudou.

Quarto, inventaram uma super arquitetura ambiciosa que não trouxe benefício algum ao projeto, bolado por um arquiteto da torre de marfim que não ia meter a mão no código.

Quinto, acabaram inventando muitas funcionalidades e, depois que viram que não ia dar tempo de entregar tudo, tiraram muitas funcionalidades e o produto final foi algo que realmente não trouxe muito valor para o usuário.

Felizmente, muito se fala hoje sobre desenvolvimento ágil e suas metodologias (como Scrum e XP). Mas pelo visto, ainda é uma raridade nas salas de aula. Tive uma experiência similar em algumas aulas de engenharia de software do meu curso. Muito blá-blá-blá, mostrando sempre o desenvolvimento waterfall e falando que é RUP, nada de desenvolvimento ágil.

Bom, pelo menos não podemos negar que esses estudantes passaram por uma experiência muito próxima da realidade no mercado de trabalho :)

Eventos: Ruby no Mundo Real

Evento Ruby e Rails no mundo Real 2009 organizado pelo Guru-SP

Evento Ruby e Rails no mundo Real 2009 organizado pelo Guru-SP

Dia 4 de abril de 2009 ocorrerá em São Paulo, na FIAP, o evento Ruby e Rails no Mundo Real. O conteúdo técnico do evento está sendo organizado pelo grupo Guru-sp.

O evento com certeza é de interesse para todos os desenvolvedores, inclusive os que desenvolvem em Java, devido a importância que a linguagem Ruby vem adquirindo de uns anos para cá e que hoje é possível utilizar Ruby nas plataformas Java e .Net com projetos como JRuby  (que será apresentado no evento) e IronRuby.

Muito se fala hoje em Java como plataforma e não mais como linguagem. Podemos dizer que a linguagem Java não esta evoluindo na velocidade que a comunidade espera (eu particularmente gostaria muito de ver closures entrando na linguagem) e muitos tem dúvidas se a Sun (que  é a principal mantenedora da linguagem Java) tem condições de continuar evoluindo a linguagem devido a sua delicada situação financeira.

Eu uso muito a linguagem Groovy no meu dia-a-dia e acompanho com muito interesse a impressionante evolução do JRuby. Depois que você se acostuma com a agilidade destas linguagens, fica até chato voltar a usar uma linguagem, digamos, tradicional :)

lula_plantando_uma_rvore

Mesmo que você não acredite em outras linguagens na JVM, Ruby e Ruby on Rails tem tido um crescimento muito interessante no mundo inteiro, e inclusive tem gente prevendo um grande crescimento para o Ruby no Brasil.

Enfim, as palestras parecem muito interessantes, os palestrantes são bons, o evento é num final de semana, num local bem acessível em São Paulo e com um custo relativamente baixo. Eu acho que vale a pena dar um pulo no evento :)

Melhorando significativamente a performance de aplicações web sem gastar tanto

Performance é uma coisa complicada. Sempre tem alguma coisa para melhorar na aplicação. Banco de dados, cluster, replicação de estado, cache dos dados, load-balance, pooling de recursos, processamento assincrono, networking, I/O… São tantas coisas que podem causar problemas de performance, gargalos, instabilidade, que nós, pobres desenvolvedores, ficamos perdidos!

Como diria Donald Knuth, “a otimização prematura é a raiz de todo o mal”. Ás vezes se gasta muito tempo otimizando determinada parte da aplicação, mas com um ganho de performance muito baixo. E além do tempo gasto na otimização, gastasse muito tempo testando se a otimização não quebrou o funcionamento da aplicação (ok, testes automatizados reduzem este tempo) ou testando quanto a performance melhorou por causa da otimização feita.

Sempre que se fala em melhorar a performance, muitos desenvolvedores pensam em load-balance, cache do banco de dados, pooling de recursos, melhoria nas queries, etc. Não há nada de errado em aplicar esses conceitos nas aplicações, inclusive muitas vezes isso deve mesmo ser feito. Mas quando se trata de aplicações web, a performance da aplicação, ou a percepção da performance da aplicação pelo usuário, pode ser melhorada por otimizações no front-end da aplicação, sem grandes alterações na arquitetura ou no código da aplicação.

Li recentemente o livro High Performance Web Sites, que traz 14 dicas para melhorar a performance de aplicações web alterando pontualmente o front-end das aplicações web. Algumas dessas dicas são bem fáceis de se implementar e trazem um excelente ganho na rapidez com que as páginas web são carregadas.

O livro diz que, na grande maioria dos casos, a maior parte do tempo gasto para visualizar uma página web é gasto na renderização do HTML pelo browser, e não no processamento da requisição web pelo servidor. Então vale a pena investir tempo e esforço para criar um front-end que é renderizado mais rápido pelo browser.

As dicas do livro são:

  • Fazer menos requisições HTTP
  • Usar uma Content Delivery Network
  • Adicionar um cabeçalho “Expires” na resposta HTTP
  • Utilizar Gzip para compactar os componentes da página
  • Colocar os Stylesheets no topo da página
  • Colocar os Scripts no fim da página
  • Evitar CSS Expressions
  • Colocar os códigos JavaScript e CSS em arquivos externos
  • Reduzir DNS Lookups
  • Compactar os códigos JavaScript
  • Evitar Redirects
  • Remover Scripts duplicados
  • Configurar as ETags
  • Make Ajax Cacheable
No livro esta explicado com mais, mas essas dicas podem ser encontradas no site do Yahoo.
Dessas 14 dicas, acredito que as que tragam mais ganho sem muita dificuldade são as dicas
Essas duas dicas não requerem alteração no código da aplicação e diminuem muito o tempo que o browser leva para carregar as páginas web.
Não vou entrar em detalhes sobre por que essas dicas melhoram a performance por que acho que o link já explica isso muito bem.
Implementei essas dicas rapidamente num projeto que desenvolvo e o ganho em rapidez foi muito bom! O projeto é uma aplicação web em Java. Para utilizar Gzip para compactar os componentes da página, bastou alterar o arquivo server.xml do Tomcat, adicionando o valor compression=”on” na entrada do HTTP Connection. Para Adicionar um cabeçalho “Expires” na resposta HTTP copiei utilizei um servlet filter descrito neste artigo.
Sem gastar muito tempo, sem alterar uma linha de código (ok… tive que alterar a configuração do Tomcat e o web.xml da aplicação web), com pouca configuração, a aplicação ficou bem mais rápida! O conteúdo estático ficou sendo “cacheado” pelo browser e o conteúdo não-estático é compactado antes de ser enviado para o browser.
A extensão YSlow foi de grande ajuda para medir e melhorar a velocidade do site. Recomendo que todos os desenvolvedores de aplicações web a tenham instalada no seu Firefox.
Às vezes as coisas mais simples são as que trazem melhores resultados :)

Rails Rumble 2008

Rails Rumble é uma competição interessante: o pessoal se reune em equipes de 1 a 4 nerdsintegrantes e criam uma aplicação utilizando o consagrado framework Ruby on Rails em um período de 48 horas ininterruptas! Depois as aplicações criadas por essas equipes são submetidas a uma votação com prêmios bem legais.

Segundo o faq da competição, o objetivo do evento é ser uma encubadora para startups. Alguns projetos realmente viraram startups na competição passada, como o site pagestacker, criado por uma equipe de brasileiros.

Esse ano temos algumas equipes brasileiras participando:

http://giwiki.r08.railsrumble.com/ – Um  wiki engine que usa o sistema de versão de controle GIT para armazenar as páginas do wiki.

http://mix4vids.r08.railsrumble.com/ – Uma aplicação que junta 4 vídeos para serem exibidos ao mesmo tempo.

http://rio.r08.railsrumble.com/ – Um “diário” das refeições que você consumiu.

Parabéns para os que tiveram coragem de participar :)

edit: atualizando lista de projetos brasileiros na competição :)

Review sobre o JustJava 2008

Semana passa estive no JustJava, o maior evento da comunidade Java do Brasil. Já havia participado no ano retrasado como palestrante, esse ano participei só como congressista.

Logo no começo do evento o pessoal do UOL compartilhou a experiência que eles passaram ao experimentar diferentes metodologias de desenvolvimento, passando do “caos”, para a CMMi-like (burocracia) e chegando no Agile. Foi interessante ver como a adoção de Agile acaba sendo uma tendência natural quando as pessoas buscam sempre melhorar a forma como elas trabalham.

Gostei também da palestra o Michael “Mister M” Nascimento sobre as mudanças na linguagem e na plataforma Java que estão sendo discutidas e planejadas para o Java 7. Pelo que ele mostrou, infelizmente várias coisas legais vão acabar não entrando para o Java 7, por isso eu particularmente continuo apostando nas outras linguagens da JVM.

A palestra sobre Selenium feita pelo pessoal da Caelum também foi muito boa. Eu já conhecia a ferramenta Selenium (que serve para a escrita e automatização de testes funcionais de aplicações web), mas ainda não tive a oportunidade de usar a ferramenta em um projeto profissional, então foi bom ver as “best practices” de quem já tem uma boa experiência com a mesma. Achei muito interessante quando o Guilherme Silveira e o Anderson refatoraram os teste gerados pelo Selenium IDE e criaram uma especie de DSL para testes. Criar esse tipo de testes com certeza não é nada fácil, mas com certeza vale a pena pela segurança que esse tipo de teste dá.

O Rodrigo Yoshima fez uma palestra super bem-humorada sobre desenvolvimento ágil. Ele escreveu um post no blog dele sobre a palestra.

Além das palestras participei também das “muvucas” na quarta e na quinta, que foi basicamente sobre desenvolvimento ágil e integração continua. Falando em integração continua, nesse evento acabei conhecendo o servidor de integração continua Hudson e o seu criador, o Kohsuke Kawaguchi. Estou testando o Hudson, em breve irei escrever sobre essa experiência.

O legal desses eventos além de ver as palestras e falar com os outros profissionais, trocar experiências, fazer contatos. Gostei muito do evento, agora é só esperar pelo evento de Rails da Locaweb :)

Apresentação sobre EJB no Uscs.java 2008

Fiz uma apresentação sobre Enterprise Java Beans dia 09/08, no evento Uscs.java 2008, organizado pelo Eduardo Breigada. Parabéns Eduardo por todo o esforço envolvido na organização do evento!

Infelizmente tive que encurtar a duração da palestra por conta de um atraso no evento e não deu tempo de fazer alguns exemplos práticos na hora como eu havia planejado.

Eu subi os slides da apresentação no slideshare:

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.