A nova formação da Caelum tem o objetivo de aprofundar os conhecimentos numa área em constante crescimento. A formação tem a parceria da Locaweb e é composta dos cursos WD-41 | Design de Interação, Experiência do Usuário e Usabilidade e WD-43 | Desenvolvimento Web com HTML, CSS e JavaScript.

User Experience

Ao navegar na web, sacar dinheiro de um caixa eletrônico ou mesmo usar um celular, nos deparamos com sistemas diferentes, escritos em Java, Ruby ou C#, porém nossa satisfação não é definida pela linguagem utilizada, e sim pela qualidade e facilidade em interagir com o produto: nossa experiência como usuário.

Ao estudo dessa interação usuário-produto dá-se o nome User Experience, muito conhecido como UX, e em português traduzido como Experiência do Usuário.

Pode-se definir User Experience como a satisfação e qualidade em interagir com a interface de um serviço, produto ou sistema. Muitos consideram a Experiência do Usuário como um dos principais fatores no sucesso ou fracasso de um software. O quanto seu software é focado na necessidade do usuário? Com que velocidade ele atende aos clientes? Quais as dificuldades para finalizar uma compra? Quanto mais simples de usar, menor é a necessidade de suporte e maior a viabilidade financeira do projeto. Podemos citar exemplos clássicos, como o GMail, que revolucionou a forma de utilizar email online, além do iPod com sua interface simples e objetiva.

Design de Interação

Um dos papéis que existem no processo de desenvolvimento da Experiência do Usuário é o de Designer de Interação. Existem diversas funcionalidades implementadas em um sistema que muitas vezes os usuários finais desconhecem ou tem pouco interesse, sendo que elas poderiam facilitar tarefas e otimizar tempo. O Designer de Interação se preocupa com as relações humanas de um software.

Autores e profissionais se referem ao Design de Interação como iD ou IxD (Interaction Design), existindo já uma associação oficial, a IxDA. No Brasil há um conhecido blog da Locaweb focado em Experiência do Usuário.

Designer de Interação x Arquiteto de Informação

Nos projetos web os dois papéis são parecidos, porém com diferentes focos. O Arquiteto de Informação se preocupa mais com o armazenamento e distribuição da informação, enquanto o Designer de Interação tem a responsabilidade de definir como essa informação será manipulada e transformada.

É comum em equipes grandes o Designer de Interação ser responsável por criar wireframes enquanto o Arquiteto de Informação cria a estrutura e faz o planejamento geral.

Existe um instituto sobre Arquitetura de Informação e no ano passado o Brasil sediou o Interaction South-America 09.

Programador de Interfaces

E quem realmente escreve o código das interfaces web depois de planejadas? Nessa etapa entra o profissional com conhecimentos aprofundados de HTML, CSS, Javascript, que têm ganhado muita atenção nos últimos anos, em especial o Javascript, sendo reconhecido como uma linguagem extremamente poderosa e divertida. Esse profissional é focado em transformar o trabalho planejado pelos profissionais acima em realidade. Ter o domínio dos melhores padrões, layouts e conhecimento dos diversos navegadores existentes para converter o projeto em realidade são algumas das funções do Programador de Interface, também chamado de Web Designer.

O sucesso de um projeto dependente muito de atender e se possível superar as expectativas dos usuários, fazer com que a interação deles com o sistema seja tão satisfatória a ponto de atingir completamente os objetivos do sistema.

Confira o conteúdo dos treinamentos WD-41 | Design de Interação, Experiência do Usuário e Usabilidade e WD-43 | Desenvolvimento Web com HTML, CSS e JavaScript.

Em 2008 comentamos sobre a importância de integração contínua no processo de receber feedback rápido sobre suas mudanças em um sistema e depois sobre os problemas que surgem quando um sistema possui baterias de teste muito grandes e complexas.

Um das grandes vantagens da agilidade consiste em poder efetuar mudanças sem medo e receber as respostas rapidamente em relação aos bugs que introduzimos no sistema, evitando mais erros e, para atingir esse objetivo, um servidor de integração contínua deve integrar o nosso código com aquele existente e rodar a bateria de testes automatizados a cada commit, criando um relatório do que foi feito que pode ter quebrado a aplicação.

Existem diversos níveis de adoção de um servidor de integração contínua em um projeto, indo do mais básico que envolve a simples compilação de um projeto (quando a linguagem é compilada) e a execução de testes unitários, até cenários mais complexos. Uma das principais dores de cabeça que um cliente enfrenta, mesmo em empresas que adotam metodologias ágeis como XP e Scrum, está ligada ao produto ser colocado em produção e não funcionar: a famosa frase “mas no meu computador funcionou”.

Um cenário clássico envolve o desenvolvimento de testes unitários, que são rodados na máquina do desenvolvedor e no servidor de integração contínua. O desenvolvedor chama então o cliente para testar em sua máquina, que aprova a funcionalidade e depois de duas semanas é feito o deploy da aplicação quando, para a surpresa do cliente, ela não funciona como esperado.

Acontece que a máquina de desenvolvimento em geral não possui a mesma configuração – software de banco de dados, servidor, proxies, firewall ou até mesmo os dados contidos no banco – que o sistema em produção, e mudanças do gênero podem significar resultados completamente diferentes para o cliente que, no fim da iteração, não obtém o valor que esperava.

A solução está em criar um sistema de homologação e diversas empresas adotam essa prática. A dificuldade encontrada nessa etapa é a da não automatização do processo de réplica da estrutura e dados de produção para homologação. Dados antigos ou inadequados no ambiente de aprovação facilitam um aceite errôneo por parte do cliente no momento do teste. Na Caelum e em nossos clientes que possuem sistemas que efetuam deploy diversas vezes em um ano, para garantir a competibilidade da empresa, é comum automatizar o processo de deploy ao ponto de maximizar as semelhanças entre produção e homologação, e minimizar as idas e vindas de uma funcionalidade.

Passo a passo junto com o cliente, cada fase é incluída no pipeline de integração contínua. Primeiro o projeto é compilado, depois os testes unitários são executados. Essas duas fases do pipeline são padrão para linguagens compiladas como Java. Em algumas empresas devido ao código legado ter um acoplamento muito alto, essa primeira fase já envolve mudanças na maneira de trabalhar e na qualidade do código gerado pelos desenvolvedores.

As fases seguintes variam bastante de acordo com projeto, mas para melhorar o deploy que minimize o número de tentativas de aprovação é importante adicionar três fases: testes end-to-end automatizados, deploy para homologação e para produção em um clique.

Na primeira fase, os testes executam as funcionalidades como o cliente faria e cobrem a maior quantidade de funções plausíveis de automatização. Na segunda fase, os desenvolvedores podem optar por deployar para um sistema de homologação, onde o cliente aprovará com os dados copiados de produção (alterações ligadas a sigilo de dados devem ser aplicadas).

Por fim, quando o sistema está aprovado em homologação, com um clique o desenvolvedor efetua o deploy para produção. Nesse instante, os sistemas são restartados, de preferência com o uso de load balancers que permitem o restart sem a queda da aplicação, e o cliente está pronto para usar as funcionalidades novas.

Toda essa automatização tem um custo inicial de desenvolvimento que é compensado com a minimização de erros humanos no processo de deploy e na lentidão do mesmo. Muitas vezes o processo de deploy para qualquer um dos dois ambientes não é feito tão frequentemente devido ao processo ser demasiadamente complexo para ser executado manualmente. A chance de funcionar em produção é maximizada uma vez que a mesma foi testada em homologação com uma cópia mais fidedigna do sistema de produção possível: menos reclamações e tempo perdido pelo cliente.

Note que nenhuma ferramenta específica é necessária para adotar essa prática, basta mudar o método de trabalho.

Depois de mais de 4000 downloads nesses 3 meses de vida, lançamos o VRaptor 3.1 com muitas novidades e bugfixes, com destaque ao suporte aos novos recursos das servlets no Java EE 6, o que permite usar o VRaptor 3 sem nem mesmo um web.xml em containers compatíveis com servlets 3.0, além de novos recursos para AJAX, lógicas genéricas e facilidades no mapeamento de URLs, forwards e redirects.

Aproveitando o lançamento dessa nova versão do framework, estamos disponibilizando a atualização da apostila do curso FJ-28 de VRaptor, Hibernate e AJAX, que já está disponível para download. O material não abrange apenas VRaptor, Hibernate e JSP, mas também entra em detalhes de como fazer a costura de maneira correta, gerenciando suas Sessions, Transactions, etc, através da criação de uma webapplication desde o zero.

Se você nunca escreveu uma servlet antes por causa do medo de tantas configurações, agora é o momento para iniciar nessa tecnologia. Repare, com esse artigo, como ficou mais simples desenvolver para a web com Java.

Grande parte das aplicações atualmente desenvolvidas em Java são para a Web e geralmente são desenvolvidas através de frameworks como Struts, VRaptor e JSF. No entanto, é muito importante que antes de aprendermos alguma dessas ferramentas, entendamos os conceitos que elas nos abstraem.

Servlets

O principal pilar do desenvolvimento Web em Java é a API de Servlets. Com ela é possível executarmos código de uma determinada classe Java a partir de requisições HTTP para uma URL. Esse acesso é feito através de configurações não triviais de um servidor e arquivos específicos, de maneira diferente às antigas linguagens de script, como Perl, o que pode tornar o aprendizado de Servlets complicado.

Até a versão 2 da API de Servlets, precisamos fazer a declaração dessas classes através de XML (o web.xml). Portanto, além de nos preocuparmos em escrever o código Java com o processamento e lógica que desejamos fazer, ainda temos que nos preocupar com as configurações em XML, numa estrutura de diretórios especifica (o famoso diretório WEB-INF/classes), além de ter de manusear um servlet container.

Pronto pra escrever sua primeira servlet? Use a versão 3.0!

No mês passado foi aprovada oficialmente a versão nova do JavaEE 6, trazendo entre várias especificações novas, uma versão para Servlets, contendo diversas atualizações, a JSR 315, também conhecida como Servlet 3.0.

Nessa nova versão criamos as Servlets da mesma forma que fazíamos antes, ou seja, através de uma classe que estenda HttpServlet. Dessa forma, podemos criar uma Servlet que recebe um parâmetro pela requisição e imprime o mesmo no console da seguinte forma:


public class OiMundo extends HttpServlet {
    protected void service(HttpServletRequest request, 
        HttpServetResponse response) 
        throws ServletException, IOException {
        
        String nome = request.getParameter("nome");

        PrintWriter out = response.getWriter();
        out.println("Ola: " + nome);
    }
}

A primeira grande diferença que pode ser percebida na Servlet 3.0 é o uso de anotações para a configuração das Servlets em vez de grandes declarações em XML. Na versão 3, existe a anotação @WebServlet, que indica que aquela classe é uma Servlet. Essa anotação recebe no seu parâmetro value em qual URL a Servlet estará disponível.


@WebServlet(value="/oiMundo")
public class OiMundo extends HttpServlet {
        PrintWriter out = response.getWriter();


Você já poderia acessar nossa Servlet através de uma URL semelhante a http://localhost:8080/projeto/OiMundo?nome=Caelum, porém é mais interessante termos um formulário HTML que enviará a requisição e o parâmetro para a Servlet. Podemos criar um oiMundo.html com o seguinte conteúdo:

<html>
  <body>
    <form action="oiMundo">Informe o nome:
      <input name="nome" type="text" />
      <input type="submit" value="Enviar" />
    </form>
  </body>
</html>

Desenvolvedores que já trabalharam com a versão 2 de Servlets podem perceber que não declaramos nenhum nome para nossa Servlet em sua configuração. Isso anteriormente era feito através da Tag <servlet-name> no XML. Porém, por padrão, na versão 3.0 é utilizado o nome completo da classe que está anotada. Podemos sobrescrever essa padrão através do parâmetro name da anotação @WebServlet:


@WebServlet(value="/oiMundo", name="ServletOiMundo")

Mais novidades da especificação

Além de não precisarmos mais fazer a declaração das nossas Servlets em XML, agora também podemos declarar Filtros via anotações com o uso de @WebFilter.

Outro ponto que também acaba sendo muito comum quando utilizamos frameworks e bibliotecas de terceiros é que se exige uma configuração mínima no web.xml dos nossos projetos. Mas agora nem mesmo precisamos fazer essa configuração. As bibliotecas podem disponibilizar no diretório META-INF de seus jars um arquivo chamado web-fragment.xml contendo as configurações mínimas necessárias para o funcionamento da biblioteca, dessa forma, nós que utilizamos as bibliotecas não precisaremos nem fazer as configurações mínimas.

O que preciso para usar a nova versão?

Para que possamos utilizar Servlet 3.0 em nossas aplicações precisamos de um servidor que implemente essa nova versão. Até o momento, o único servidor que possui um release compatível é o Glassfish v3. Outros servidores famosos como Jetty (disponível em versão experimental na versão e Tomcat (planejado para a versão 7) também suportarão.

Agora bastaria disponibilizar um projeto no servidor contendo no seu diretório WEB-INF/classes o .class da nossa nova Servlet.

Servlet 3.0 e a Caelum

Nosso conhecido curso de java para web, que vai desde servlets e JSP até Struts 2 e um pouco de Hibernate e VRaptor, já incorpora essas novidades do Java EE 6, e agora possui um capítulo totalmente dedicado à API Servlet 3.0.

Além disso, a versão 3.1 do VRaptor possui suporte também através do uso dos web fragments, dessa forma, você utiliza o framework sem escrever absolutamente nenhuma linha de XML, nem mesmo a declaração do filtro do framework.

Foi um ano de muitas realizações e novidades para a Caelum.

Participamos de muitos eventos e palestras. Além do Falando em Java 2009, tivemos o Caelum Day no Rio de Janeiro, participamos do Maré de Agilidade, Maratona de Programação da USP, Oxente Rails, JUGDay Presidente Prudente, o gigante RailsSummit America Latina, palestras no SouJava, Dev in Rio, JustJava, Encontro Agil, Café com Tapioca, EJES em Vitória, Ceará on Rails, Java Day de Rio Preto, Dev in Sampa e muitas palestras em universidades, como na UniSantos, Metodista e Universidade de São Paulo, como também patrocínio a outros eventos.

Simultaneamente ao Sun Tech Days em São Paulo, palestramos no Rio java Developers Day, no Java Enterprise Day em Goiania e no CEJUG Tech Day em Fortaleza. Se você vai promover um evento e gostaria da presença da Caelum, mande um email diretamente para o Luiz Bassi, que ajudou a organizar essas nossas participações.

A Caelum consolida-se no mercado e ganha cada vez mais força. É cada vez mais buscada no Google com referência a rails, agile e java, atingindo novos picos a cada ano:

Entre os cursos novos, em 2009 criamos juntamente com a DClick o curso de Adobe Flex, e com a Overmedia o curso de Java com TV Digital. Ainda temos o curso de lógica de programação, Gerenciamento Ágil de Projetos com Scrum e o reformulado curso de VRaptor com Hibernate e AJAX. Para Rails, 2009 se demonstrou um excelente ano, e criamos o curso avançado de Rails assim como estendemos e liberamos a apostila do curso de Ruby on Rails inicial. Também lançamos o Caelum Alumni, portal dos ex-alunos da Caelum, onde eles podem acessar seus certificados, colegas de classe e downloads exclusivos.

Vale salientar como estamos sendo bem recebidos no Rio de Janeiro, que completou um ano de Caelum, e na recente unidade de Brasília.

Não só com treinamentos e eventos trabalha a Caelum. Sobre software open source, o lançamento do VRaptor 3 resultou em 4000 downloads e mais de 3000 mensagens no fórum. Também nasceu o framework REST opensource Restfulie, que realmente utiliza hipermedia e tem ganho muito destaque na comunidade. E durante o ano, além de software opensource, desenvolvemos projetos internamente e participamos de diversas consultorias.

Feliz 2010 a todos, que possamos juntos adquirir novos conhecimentos, ao mesmo tempo que nos divertimos programando e trabalhando. Teremos muitas novidades a respeito de cursos novos, portais e um grande evento.