Caelum | Ensino e Inovação - Cursos de Java, Scrum, Ruby on Rails


CSS3 e o futuro da Web

Por Sérgio Lopes em 17/02/10

O mundo do desenvolvimento Web passa atualmente por grandes mudanças. Com as aplicações Web exigindo cada vez mais dos navegadores, uma verdadeira guerra está sendo travada no client-side da Web. O até então onipresente Adobe Flash vem recebendo críticas e mais críticas. Com suas próprias alternativas, Microsoft, Oracle e Google tentam entrar nesse mercado. E, ainda parecendo velhos e ultrapassados em comparação a tudo isso, estão HTML, CSS e JavaScript.

Mas, se depender dos novos HTML5 e CSS3, o cenário será bem diferente no futuro. Com o grande apelo de serem padrões abertos implementados nativamente nos navegadores, essas novas especificações prometem simplificar bastante o desenvolvimento de aplicações ricas no client-side sem o uso de plugins.

Só para falar do CSS3, assunto desse post, podemos citar entre suas novas capacidades de formatação visual, as queridas bordas redondas, o uso de sombras, múltiplos backgrounds, layouts multi-colunas, novos seletores, uso de fontes externas, transformações 2D e 3D e animações. São recursos que facilitam bastante a tarefa do WebDesigner ao criar interfaces ricas e bonitas.

Embora não seja tão recente assim – o CSS3 data de antes de 2001 -, o suporte nos navegadores ainda é bem precário. Firefox, Safari, Chrome e Opera lideram o movimento, mas ainda estão longe de implementar todos os recursos. O IE tem algumas poucas coisas implementadas em sua versão 8 e uma promessa dos desenvolvedores de melhorar um pouco mais na futura versão 9.

Para demonstrar o uso de alguns recursos do CSS3, recriamos o logotipo da Caelum inteiramente usando recursos do CSS3, como border-radius, pseudo-elementos :after e :before e @font-face. O HTML da página é simplesmente:

  <div class="caelum">
    <strong>Caelum</strong>
    <em>Ensino e Inovação</em>
  </div>

E, sem usar nenhuma imagem (nem JavaScript/canvas/SVG), desenhamos o logo da Caelum. Veja a demonstração usando alguma versão recente do Firefox (3.5+), Safari/Chrome ou Opera (10.50+) e veja também o código CSS. E, por ser tudo CSS, sem imagens, podemos mudar o tamanho do logo a vontade, como mostra esse outro exemplo.

CSS3, HTML5 e outros tópicos da “nova Web” são também assuntos do novo treinamento da Caelum, WD-43: Desenvolvimento Web com HTML, CSS e JavaScript. O CSS3 é peça importante no futuro da Web. Seus diversos recursos mudarão a forma como fazemos WebDesign.

  • Share/Bookmark

HTML, CSS, Javascript e UX na nova formação da Caelum

Por Anderson Leite em 29/01/10

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.

formacao_wd

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.

elements-of-user-experience

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.
user_experience_garrett
É 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.
web-design

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.

  • Share/Bookmark

Java EE6: Começando com as Servlets 3.0

Por Adriano Almeida em 08/01/10

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 8) 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.

  • Share/Bookmark

Hipermídia e contratos dinâmicos: menor acoplamento

Por Guilherme Silveira em 17/12/09

Nos últimos anos você vem comprando livros em um website: você acessa o site inicial www.amazon.com, procura pelo livro que deseja comprar, adiciona-o ao seu carrinho, escolhe o método de pagamento e finaliza a compra.

Na época do Natal, o site muda: existe agora uma promoção de fim de ano e você se depara com um conteúdo inesperado: existem funcionalidades e informações novas (como um programa de desconto através de cupons). Como reage um humano ao encontrar a mudança com novas possibilidades de iteração em um site?

  • Gritar: “contrato violado! não comprarei mais nada!
  • Ignorar as novas informações e executar o processo
  • Usar o intelecto humano e se aproveitar das novas informações

Como humanos sabemos o quão natural é agir de maneira a ignorar as informações – caso elas não contribuam com meu objetivo – ou tirar proveito delas.

A opção 1 só se concretiza caso existisse um comprometimento total a maneira que o site disponibilizava suas informações e ao processo: se meu acoplamento for alto e o que eu espero seja fixo, imutável. Infelizmente robôs não são ainda capazes de raciocionar como nós e executar a última opção.

O conteúdo hipermídia permite evoluir o servidor com funcionalidades e dados sem quebrar os clientes consumidores por padrão. Ninguém deixaria de comprar pois fornecemos funcionalidades e dados novos em relação aos recursos disponibilizados.

Isso permitiu a evolução de sites por diversos anos sem que usuários enviassem emails para o responsável reclamando da nova função que foi adicionada, dizendo que não utilizarão o sistema pois existe conteúdo extra.

Hipermídia permite um baixo acoplamento entre o cliente e o servidor e pode ser levado para o mundo da automatização: a web dos sistemas. Na web humana, validamos nossos contratos com o usuário final através do uso de testes end-to-end, verificando a existência de funcionalidades como o usuário o faria.

Diversas opções de ferramentas como selenium-rc e webdriver fornecem funcionalidades para garantir que o comportamento esperado não será quebrado com novos releases.

Eles não validam tudo retornado pela requisição, dando espaço para a ::forward-compatibility::, a capacidade de evoluir nosso sistema no servidor sem quebrar o comportamento esperado. Por exemplo, adicionar novas funcionalidades ou campos não relativos ao teste não deve quebrar o mesmo.

Na web para sistemas integrados, a representação mais comum é o xml, que não suporta conteúdo hipermídia, uma vez que uris devem ser tratadas como texto (de acordo com a especificação) então acabamos criando nossos próprios media-types, como vnd/caelum+xml, onde há a definição de como elas devem ser tratadas: o nosso próprio micro formato.

Existem diversas alternativas para criar esquemas forward e backward compatíveis mas infelizmente esse não é o comportamento padrão de arquivos como o formato ::xsd:: e arquitetos não se lembram disso ao definir seus esquemas, o suporte é opcional.

Dentre essas opções, a mais fácil e possivelmente perigosa envolve permitir qualquer tipo de conteúdo em qualquer campo, enquanto outra solução envolve o uso de tipos polimórficos: um perigoso início de schema-hell controlando diversas versões para uma mesma funcionalidade.

Micro formatos como os que podemos criar permitem a definição de uma estrutura fixa e uma dinâmica: um contrato parcialmente fixo, com garantias para validação e compatibilidade, além de parcialmente dinâmico, com liberdade para evolução, diminuindo o acoplamento que seu sistema possuia ao utilizar um esquema totalmente fixo.

Mas a responsabilidade de não quebrar o contrato original fixo ainda é do servidor.

Na web humana, xhtml permite validar a estrutura (o contrato) enquanto é responsabilidade sua (seus testes) não remover o campo de busca de livro, caso contrário o processo não se completa.

Enquanto esquemas permitem a validação de dados, os testes permitem a validação dos processos. Ambos devem ser escritos de maneira a permitir a evolução desacoplada do servidor e do cliente. E quais seriam então as partes dinâmicas do meu contrato?

Os possíveis estados de seu recurso podem variar com o tempo: uma aplicação para empréstimo pode ser só aprovada ou recusada, mas com o passar do tempo a empresa pode decidir a existência de um novo estado: “prolongado”.

As relações entre seu recurso e outros recursos também variam: um cliente pode ter uma lista de serviços contratados atualmente, acessando a sua representação via links. É natural imaginar que surjam novos serviços e que o cliente mude suas contratações.

As transições e operações disponíveis para seus recursos também são dinâmicas: suportando um método HTTP novo ou um novo link não quebra a existência de clientes que consomem as transições e operações existentes até então.

Todo esse dinamismo é guiado através de hiperlinks e conteúdo hipermídia. Como os clientes terão certeza que não quebramos o contrato dinâmico?

Da mesma maneira que implementamos testes para garantir o comportamento esperado, precisamos deles para garantir que o processo não é alterado no servidor.

Os testes end-to-end são a única garantia de que não quebramos os processos junto ao cliente, seja ele humano ou outro serviço.

Esquemas xml podem ser usados de maneira a garantir flexibilidade e compatibilidade, mas não é o comportamento padrão de tal ferramenta: depende muito mais do usuário conhecer e fazer o uso adequado dela.

ATOM é um exemplo que suporta por padrão contratos dinâmicos: ao seguir o Must Ignore, ganhamos forward e backward compatibility. Contratos dinâmicos fornecem dicas para os frameworks, permitindo ao servidor guiar o cliente naquilo que pode executar ou acessar.

A consequência principal de contratos dinâmicos é o baixo acoplamento.

O Restfulie foca no poder do hipermídia como facilitador na evolução a médio e longo prazo: não são URIs elegantes ou a adoção do protocolo HTTP sozinhos que criam sistemas de baixo acoplamento.

  • Share/Bookmark

Arquitetura REST com Java: JAX-RS

Por Sérgio Azevedo Junior em 15/12/09

A necessidade de trocar informações entre aplicações motivou diferentes abordagens para “integração de dados”. Desde soluções simples e questionáveis como utilizar um banco de dados compartilhado, ou realizar troca de arquivos até soluções mais elaboradas que utilizam objetos distribuidos (COM e Corba). Em diversos momentos não temos somente a integração de sistemas diferentes mas a distribuição de um único sistema em diversas partes também pode ser integrada da mesma maneira.

A solução de integração denominada Webservices, que já é relativamente simples de implementar, é a mais utilizada hoje em dia, que vemos em profundidade no curso FJ-31.

A Web é amplamente utilizada e reconhecida principalmente por sua arquitetura robusta, tolerante a falhas e escalável. Quem sustenta a Web nesses fatores e lhe dá todo este poder é o protocolo HTTP. Este protocolo inocente que utilizamos “meio que sem saber” em nossos navegadores de internet está presente na Web inteira, e inclusive em nossos Webservices. Não seria ótimo se eles tirassem proveito das caracteristicas do protocolo HTTP, sem que isso nos desse muito trabalho?

A especifição JSR-311 JAX-RS de Restful webservices (que faz parte agora do Java EE 6) tornou isso simples e possível. Diferentemente do tradicional SOAP – em sua versão amplamente utilizada – e WSDL, o JAX-RS foca um pouco mais em URIs e nos detalhes do protocolo HTTP para se beneficiar de seus recursos.

Como utilizamos o JAX-RS para buscar dados de um Pedido?

@Path("/pedido/{id}")
public class PedidoResource {
 @GET 
@Produces( { MediaType.APPLICATION_XML })
 public Pedido getPedidoById(@PathParam("id") Long id) {
   PedidoDAO pedidoDAO = new PedidoDAO();
   Pedido pedido = pedidoDAO.getPedidoById(id);
   return pedido;
 }
}

Através da classe PedidoResource, disponibilizaremos os dados de nossos pedidos no formato XML. Vamos supor que configuramos que este serviço esteja disponível no endereço: http://caelum.com.br/rest/pedido. Para conseguirmos informações sobre o pedido 10, podemos acessar a url http://caelum.com.br/rest/pedido/10, através de nosso browser de internet favorito. E assim receberiamos um resultado parecido com este:

<pedido>
  <dataPedido>2009-12-10T18:50:57.173-02:00</dataPedido>
  <descricao>Pedido 10</descricao>
  <id>10</id>
  <total>3000.25</total>
</pedido>

A api JAX-RS nos permite trabalhar com o que foi denominado Restful WebServices. E segundo a arquitetura REST nós devemos expor as informações importantes de nossa aplicação como recursos. Para isso precisamos criar uma classe que é definida pela especificação como RootResource. Em nosso exemplo a classe PedidoResource é a nossa , e para ser acessivel aos clientes fornecemos a ela um url através da anotaçao @Path(“/pedido/{id}”), e o próprio JAX-RS reconhece {id} como sendo um parametro que é enviado através do url.

Um recurso pode responder a operações do protocolo HTTP, dentre as quais destacam-se: POST, GET, PUT e DELETE. Nós escolhemos que nosso serviço responderá apenas a solitações do tipo GET, a anotação @GET acima do método getPedidoById é quem define isso. Essas anotações de caminho e de qual método HTTP podem acessar determinado método estão presentes em frameworks como o Spring MVC e o VRaptor.

Depois dizemos que uma solitação GET para nosso recurso irá produzir um resposta do tipo XML, através da anotação @Produces( { MediaType.APPLICATION_XML }).

É impotante destacar que esta anotação não é a responsável por serializar o objeto no formato XML. O JAX-RS usa o JAX-B como serializador padrão, basta para isso colocar a anotação @XmlRootElement na classe desejada, assim como nós fizemos em nossa classe pedido.

@XmlRootElement
public class Pedido {

 private Long id;
 private String descricao;
 private double total;
 private Calendar dataPedido;
 //Getters e Setters...

}

Agora que entendemos melhor o nosso serviço, ou seja, como acessar nosso recurso, podemos olhar melhor para nosso cliente. Como nosso cliente do serviço web pode ser um simples browser de internet, conseguimos usar o browser para consumir nosso serviço web porque eles já estão bem acostumados a realizar operações HTTP do tipo GET.

Mas os browser’s não são nossos únicos clientes. Podemos criar diferentes tipos, e inclusive ter aplicações desktop como clientes. Vejamos um exemplo de uma aplicação cliente, que o usa a API do httpclient do grupo apache:


public class CaelumRestClient {

  public static void main(String[] argsthrows Exception {
    HttpClient httpClient = new HttpClient();

    GetMethod httpMethod = 
      new GetMethod("http://caelum/rest/pedido/20");

    httpMethod.addRequestHeader("Accept""application/xml");
    httpClient.executeMethod(httpMethod);
    Scanner scan = 
      new Scanner(httpMethod.getResponseBodyAsStream());
    PrintStream ps = System.out;
    while (scan.hasNext()) {
      ps.println(scan.nextLine());
    }
    httpMethod.releaseConnection();
  }
}

Este cliente é bem simples, ele faz apenas o mesmo trabalho que o browser já havia feito. Mas nada nos impede de implementar coisas bem mais interessantes. Poderiamos fazer com que este cliente desserializasse nosso objeto pedido. Para isso precisarimos apenas de um parser XML para extrair os valores do xml e depois popular um objeto Pedido com estes dados. A partir daí poderiamos utilizar este objeto em nossa aplicação.

A única limitação é que esta representação XML não nos diz nada sobre quais ações estão disponiveis para o nosso objeto Pedido, nem mesmo quais as relações desse recurso com o mundo afora. Uma alternativa seria utilizar o restfulie framework muito discutido hoje em dia e idealizado por Guilherme Silveira e desenvolvido em conjunto com o pessoal da Caelum, que usa o conceito de hypermedia para expor além dos dados as ações que um determinado objeto pode realizar.

Em breve teremos um post do próprio Guilherme sobre a importância do conteúdo hypermedia na arquitetura REST.

  • Share/Bookmark



Caelum | Ensino e Inovação
São Paulo: Rua Vergueiro, 3185, cj. 87, próximo ao Metrô Vila Mariana   |   Tel. (11) 5571-2751
Rio de Janeiro: Rua Senador Dantas, 80, cj. 307/308 - Centro   |   Tel. (21) 2220-4156 ou 2297-0033
Brasília: SCS Qd. 8 Bl. B-50, Sala 521 - Ed. Venâncio 2000   |   Tel. (61) 3039-4222