Latinoware 2012 - Desenvolvendo Interfaces com Holy

Leandro Guimarães
about.me/leguimas

1997 2003

2008

holy
ho.ly

n santuário, lugar sagrado. • adj santo,
sagrado, consagrado, divino. he took holy
orders ele tornou-se padre. Holy Cross
Day Dia da Exaltação da Cruz. Holy of
Holies Santíssimo, Santuário. holy
orders clero.

Teve sua “origem” na época da Guerra Fria com pesquisadores militares
americanos pensando em um meio de distribuir suas informações
diminuindo a vulnerabilidade das bases americanas.
ARPANET - Advanced Research Projects Agency

RFC 685 com a descrição do
protocolo TCP/IP.
Década de 70
Avanço em redes privadas.

Grandes redes integradas por
TCP/IP.
Década de 80
Abertura comercial em 1988.

Grandes redes integradas por
TCP/IP.

Década de 90 Criação da
(WWW).
World Wide Web

Popularização (Brasil – 1995).

Sistemas

• Domínio da arquitetura cliente-servidor (desktop);
• Processamentos cada vez mais complexos e pesados;
• Clients cada vez mais robustos;
• Dependência “geográfica” para acesso à informação;
• Hardware alto custo.

[ 1995 – 2000 ]

Clientes (“escalabilidade”) mais
robustos a um alto custo.
Dependência “geográfica” para
acesso à informação.

+
Comunicação entre máquinas
geograficamente separadas.
Possibilidade de transitar dados de
forma confiável.

Acessar a informação de qualquer
lugar.
Investir em servidores mais robustos
mas que concentrem o
processamento.
Ter clients mais enxutos,
consequentemente, mais baratos.

Nos primórdios...

Servidor Clients
Tecnologias “embrionárias” Simples “consumidores” de
e bastante simples. informações.

Páginas dinâmicas. Recursos precários para
exibição de dados.

Com o passar do tempo...

Servidor

Com o passar do tempo...

Client
Desenvolvimento da
tecnologia
(JavaScript, jQuery,
CSS, HTML5)

Barateamento

Consequências...

Servidor Clients
Sobrecarregados em não só Capacidade ociosa: o
se responsabilizar pelo servidor prepara tudo
processamento de dados mesmo o client fornecendo
mas também por preparar a uma capacidade incrível
visualização dos dados pelo para a visualização, e até
client. processamento, de
informações.
Dificuldades de
escalabilidade. Comprometimento da
usabilidade.

Desenvolver um novo
CMS para a Globosat.
(2008)

Testemunho

Principais dificuldades encontradas:
Conteúdo altamente dinâmico;
Conciliar usabilidade e formulários
gerados dinamicamente;

Além disso...
Gostamos de prototipação mas os protótipos
são desperdiçados pois não são reaproveitados;

Testemunho

E se a gente separasse, efetivamente, o cliente
(visualização e input de dados) do servidor (obtenção e
processamento de dados)? Os browsers atualmente tem
tecnologia suficiente pra obter dados e renderizar a
visualização na tela da melhor forma com a usabilidade e
design que se queira...

Paulo Murer

Outra coisa: pra que precisa renderizar a página toda vez
que qualquer alteração nela precisa ser feita? Se precisar
mudar só um label, precisa renderizar a página toda?

E se a gente gosta de protótipos, por que não criar um jeito
de se fazer protótipo que possa ser reaproveitado?

Paulo Murer

O que é?

Uma solução open-source para o desenvolvimento
WEB na qual se isola, efetivamente, cliente e
servidor. O servidor tem como responsabilidade
“somente” a gestão dos dados enquanto o cliente tem
como responsabilidade interagir com o servidor,
enviando e obtendo dados, e renderizar as
informações na tela.

http://holy.dextra-sw.com

Como funciona?

Para as ações na sua aplicação, você faz uma
requisição AJAX para o seu servidor obtendo a resposta
necessária. De posse da resposta, você chama um
template que renderizará os dados recebidos na
página da sua aplicação.

Como assim?
Obtenção dos dados

HTML HTTP REST

$.ajax()
<body> Servidor
<div id=“myDiv”>
</div>
JSON
</body>

Como assim?
Obtenção do template

HTML HTTP

$.holy()
<body> Servidor
</div>
TEMPLATE XML
</body>

<template selector=“#myDiv">
<span>${dado}</span>
</template>

Como assim?
Renderização dos dados
(trimpath)

HTML
<body>
Servidor
<span>Hello</span>
</div>
</body>

Como assim?

muuk.html muuk.xml dashboard.js

aguardandoTimeTecnico.xml

Benefícios

• Real separação entre cliente e servidor;
• Desenvolvimento de protótipos funcionais e 100%
reaproveitáveis;
• Tecnologias padrão de mercado (W3C) e amplamente
conhecidas;
• Acervo de componentes: tudo o que a WEB oferece;
• WEB API “de graça”;
• Facilidade de desenvolvimento de novas camadas de
interface;

Benefícios

• Facilidade para a implementação de testes
automatizados – controle total sobre os componentes;
• Independência da plataforma utilizada no servidor;
• Economia de processamento no servidor de aplicação;
• Facilidade para escalar seu sistemas (sessionless);
• Foco na usabilidade e, se eu quiser, no design da
aplicação.

Tendências

Leaving JSPs in the dust: moving LinkedIn to
dust.js client-side templates.
http://bit.ly/R8UMgg

Improving performance on twitter.com
http://bit.ly/R8UPc2

@leguimas leguimas

leandro.guimaraes@dextra.com.br

Casos de Sucesso
SOFTWARE LIVRE

AGILE COM PONTO DE FUNÇÃO

ATA DE REGISTRO DE PREÇO

www.dextra.com.br/arp

Latinoware 2012 - Desenvolvendo Interfaces com Holy

Mais conteúdo relacionado

Mais procurados (7)

Semelhante a Latinoware 2012 - Desenvolvendo Interfaces com Holy (20)

Mais de Dextra (20)

Latinoware 2012 - Desenvolvendo Interfaces com Holy