Latinoware2012 - Desenvolvendo interfaces WEB com HOLY de forma prática e eficiente

  • 252 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
252
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Leandro Guimarães about.me/leguimas 1997 2003 2008
  • 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. 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. 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. 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. 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. 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. Do desktop para a WEB...
  • 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. Nos primórdios...
  • 11. Com o passar do tempo... Servidor
  • 12. Com o passar do tempo...Client Desenvolvimento da tecnologia (JavaScript, jQuery, CSS, HTML5)Barateamento
  • 13. Mas...
  • 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. Desenvolver um novoCMS para a Globosat. (2008) Testemunho
  • 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. 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. 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. 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. 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. Como assim?
  • 22. Como assim? Obtenção dos dados HTML HTTP REST $.ajax()<body> Servidor <div id=“myDiv”> </div> JSON</body>
  • 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. Como assim? Renderização dos dados (trimpath) HTML<body> <div id=“myDiv”> Servidor <span>Hello</span> </div></body>
  • 25. Como assim?muuk.html muuk.xml dashboard.js aguardandoTimeTecnico.xml
  • 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. 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. 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. @leguimas leguimasleandro.guimaraes@dextra.com.br
  • 30. Casos de Sucesso SOFTWARE LIVRE AGILE COM PONTO DE FUNÇÃO ATA DE REGISTRO DE PREÇOwww.dextra.com.br/arp