Latinoware 2012 - Desenvolvendo Interfaces com Holy

449 visualizações

Publicada em

Apresentação divulgada na Latinoware 2012 - Desenvolvendo Interfaces com Holy - por Leandro Guimarães

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
449
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Latinoware 2012 - Desenvolvendo Interfaces com Holy

  1. 1. Leandro Guimarães about.me/leguimas 1997 2003 2008
  2. 2. holyho.lyn santuário, lugar sagrado. • adj santo,sagrado, consagrado, divino. he took holyorders ele tornou-se padre. Holy CrossDay Dia da Exaltação da Cruz. Holy ofHolies Santíssimo, Santuário. holyorders clero.
  3. 3. 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
  4. 4. 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).
  5. 5. 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 ]
  6. 6. 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.
  7. 7. Acessar a informação de qualquer lugar.Investir em servidores mais robustos mas que concentrem o processamento. Ter clients mais enxutos, consequentemente, mais baratos.
  8. 8. Do desktop para a WEB...
  9. 9. Nos primórdios... Servidor ClientsTecnologias “embrionárias” Simples “consumidores” de e bastante simples. informações. Páginas dinâmicas. Recursos precários para exibição de dados.
  10. 10. Nos primórdios...
  11. 11. Com o passar do tempo... Servidor
  12. 12. Com o passar do tempo...Client Desenvolvimento da tecnologia (JavaScript, jQuery, CSS, HTML5)Barateamento
  13. 13. Mas...
  14. 14. Consequências... Servidor ClientsSobrecarregados em não só Capacidade ociosa: o se responsabilizar pelo servidor prepara tudo processamento de dados mesmo o client fornecendomas também por preparar a uma capacidade incrívelvisualização dos dados pelo para a visualização, e até client. processamento, de informações. Dificuldades de escalabilidade. Comprometimento da usabilidade.
  15. 15. Desenvolver um novoCMS para a Globosat. (2008) Testemunho
  16. 16. Principais dificuldades encontradas: Conteúdo altamente dinâmico; Conciliar usabilidade e formuláriosgerados dinamicamente;Além disso... Gostamos de prototipação mas os protótipossão desperdiçados pois não são reaproveitados; Testemunho
  17. 17. 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 avisualização na tela da melhor forma com a usabilidade e design que se queira... Paulo Murer
  18. 18. Outra coisa: pra que precisa renderizar a página toda vezque 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
  19. 19. 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
  20. 20. Como funciona? Para as ações na sua aplicação, você faz umarequisiçã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.
  21. 21. Como assim?
  22. 22. Como assim? Obtenção dos dados HTML HTTP REST $.ajax()<body> Servidor <div id=“myDiv”> </div> JSON</body>
  23. 23. Como assim? Obtenção do template HTML HTTP $.holy()<body> Servidor <div id=“myDiv”> </div> TEMPLATE XML</body> <template selector=“#myDiv"> <span>${dado}</span> </template>
  24. 24. Como assim? Renderização dos dados (trimpath) HTML<body> <div id=“myDiv”> Servidor <span>Hello</span> </div></body>
  25. 25. Como assim?muuk.html muuk.xml dashboard.js aguardandoTimeTecnico.xml
  26. 26. 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 amplamenteconhecidas;• Acervo de componentes: tudo o que a WEB oferece;• WEB API “de graça”;• Facilidade de desenvolvimento de novas camadas deinterface;
  27. 27. Benefícios• Facilidade para a implementação de testesautomatizados – 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 daaplicação.
  28. 28. TendênciasLeaving 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
  29. 29. @leguimas leguimasleandro.guimaraes@dextra.com.br
  30. 30. Casos de Sucesso SOFTWARE LIVRE AGILE COM PONTO DE FUNÇÃO ATA DE REGISTRO DE PREÇOwww.dextra.com.br/arp

×