Your SlideShare is downloading. ×
0
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
A nova web demanda novas práticas de desenvolvimento
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A nova web demanda novas práticas de desenvolvimento

1,618

Published on

Palestra ministrada no Agile Trends

Palestra ministrada no Agile Trends

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,618
On Slideshare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
14
Comments
0
Likes
4
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
  • Desenvolver para a web há muitos anos significava usar Perl, Php, Java, C#, Ruby ou alguma outra linguagem que rodasse no servidor. Javascript ficava pra alguma coisa mais interativa, e só. Mas de uns anos pra cá o Javascript está retomando o controle da web: as Single Page Applications (SPAs) estão cada vez mais presentes, e até um servidor baseado em Javascript está rodando em mais e mais lugares – e se dizendo mais eficiente que todos os outros. Com essa mudança acontecendo algumas práticas precisam ser repensadas e outras completamente adaptadas. Novas maneiras de alcançar o mesmo objetivo estão surgindo. Nessa sessão vamos ver o que mudou e o que pode ser melhor quando você desenvolve com esse novo paradigma em mente.
  • 1. Start bymakingyouraudiencecare, using a relatableexampleoranintriguingidea.Alguns de nós desenvolvem pra web desde que ela ficou disponível, ou seja, cerca de 20 anos.No começo desenvolver pra web significava somente fazer um HTML estático. A linguagem era HTML.Depois passou a ser usar CGI com qualquer linguagem que conseguisse responder na linha de comando.Aí vieram as linguagens de Script. ASP, PHP, entre outras. E elas evoluíram pra Java, C#, Ruby, Python, etc.Com certeza entre nós temos desenvolvedores de Java, Ruby, Python, PHP, Perl. Alguns de nós desenvolvem pra web desde que ela ficou disponível, ou seja, cerca de 20 anos, e começaram com HTML e CGI.
  • Só que isso está mudando. Desenvolver pra web cada vez mais significa escrever uma única linguagem: JavaScript. Ou qualquer coisa que compile pra JavaScript, tipo TypeScript ou CoffeeScript. O desenvolvimento nao está mais só no backend, estamos fazendo aplicações que estão quase todas no front-end, e o backend responde JSON. Paramos de entregar dinamicamente o HTML e passamos a entregar JSON. E o Xml, que dá nome ao Ajax está morrendo.
  • Estamos cada vez mais trabalhando com o conceito de SPAs. O usuário espera uma SPA, ele gosta da responsividade e da velocidade. Mesmo que sua app nao seja uma SPA, ela vai ter partes que serao, ou serao algo muito parecido.
  • 2. Explainyourideaclearlyandwithconviction.E com toda a app no front end as regras mudaram. Uma única linguagem nos une, independemente se você coda no Windows, Mac, ou Linux.O problema é que muda tudo. As ferramentas de desenvolvimento mudam. A gestao do código fonte é diferente. As pessoas precisam se especializar mais. O código precisa ser mais organizado. Escrever testes é diferente. SEO muda completamente. O processo de build muda.Deploy é completamente diferente.
  • 3. Describeyourevidenceandhowandwhyyourideacouldbeimplemented.Ferramentas:Nao necessariamente a melhor IDE pra desenvolver Java ou C# é também a melhor pra desenvolver JavaScript. As ferramentas de testes, build e deploy também mudam.Codamos na nuvem com Nitrous.io, Cloud9, ou parecidos, e no desktop com Sublime, VIM, Webstorm, etc. Linguagens dinâmicas como o JavaScript geralmente vivem muito bem sem IDEs. Temos ainda que minificar o JavaScript. As ferramentas de testes e build também mudam, mas já falamos delas.
  • SourceControl: A gestao do código fonte é completamente diferente. Você nao coloca dlls, JARs ou GEMs no seu sourcecontrol, porque colocaria o jquery.js, ou backbone.js? Temos tentado usar algumas ferramentas que já sao usadas no backend pra resolver esse problema. Talvez você encontre uma gem ou um nuget de jQuery. Mas isso nao faz sentido, essas ferramentas nao foram feitas pra isso.
  • Isso já foi resolvido e se chama Bower. O Bower permite gerenciar as dependências de front-end, colocar dependências entre elas, e já está ligado diretamente no Github, ou seja, está sempre atualizado. As principais bibliotecas já estao lá. E o Bower é um componente do Node.
  • Especializaçao: Talvez nao seja possível manter uma pessoa muito especializada em front-end e back-end. Um desenvolvedor iniciante vai ter que escolher.
  • Organizaçao do código: Um projeto pequeno consegue passar batido com algumas tags script numa página html. Um projeto maior vai precisar gerenciar dependência entre esses arquivos, otimizar sua carga, etc. O RequireJS utiliza o padrao AMD onde você consegue dizer arquivo deve ser carregado, na ordem correta, e sem poluir o objeto global.
  • Testes: Uma aplicaçao com grande dependência de JS precisa de testes de unidade. Temos inúmeras bibliotecas que podem ser usadas (Jasmine, QUnit, Mocha, Chai, Sinon, etc). O processo de testes tem que ser fácil. Algumas IDEs já suportam rodar testes de unidade diretamente, como o Visual Studio que roda QUnit e Jasmine.
  • Com o NodeJS podemos simular o DOM na memória e rodar testes sem precisar de um headless browser.
  • SEO: Uma SPA nao ter seu conteúdo detectado pelo mecanismos de buscas. Você vai ter que servir html estático quando um crawler se identificar. O #! é o caminho pra isso, junto com PhantomJS.
  • Build: O build de uma aplicaçaobackend vai às vezes gerar um binário e rodar os testes. Mas nao vai tratar o resultado do front-end. Precisamos compilar o front-end se for escrito em CoffeeScript ou TypeScript, e rodar os testes de unidade com JS.
  • Deploy: O deploy de uma aplicaçao dependente de JS pode ser feito em dois estágios, um para o backend, outro para o front-end. Você vai: - Buildar e testar o JS. - Minificar o JS. - Otimizar o RequireJS. Após o build concluido você vai ter um arquivo JS de base e um JS para cada SPA da sua app. Esses arquivos nao precisam ser deployados junto com sua aplicaçao de backend. É muito provável que eles possam rodar a partir de um servidor web mais simples ou até de um CDN. E o ideal é que estejam em outro domínio pra evitar o tráfego indevido de cookies.
  • 4. Endbyaddressinghowyourideacouldaffectyouraudienceiftheyweretoaccept it.NodeJS: O NodeJS é a resposta pra boa parte dos problemas. A comunidade de JS está se agregando a sua volta. Mesmo que você nao vá rodar JS no server, o Node vai ser uma excelente ferramenta para te auxiliar no processo de desenvolvimento.Grunt pode te ajudar a otimizar tarefas de gestao do JS, como build, testes e deploy.Bower vai gerenciar suas dependências. Uma simulaçao do DOM vai te ajudar a rodar testes.
  • JS é uma linguagem de verdade. Trate ela como uma.Adotando essas práticas você vai testar melhor. Vai escrever JavaScript mais organizado. Vai fazer deploy de maneira mais segura, com um overhead menor e em menos tempo.Você ainda vai desenvolver JS como se fosse 1995?
  • Transcript

    • 1. A nova web demanda novas práticas de desenvolvimento @GiovanniBassi
    • 2. ...
    • 3. ...
    • 4. flickr.com/photos/sofitel_so_bangkok/9362636601/ SPA?
    • 5. - HTML + JSON
    • 6. flickr.com/photos/lox/9408028555
    • 7. flickr.com/photos/chrigu/3828941773
    • 8. flickr.com/photos/mariachily/2649028354/
    • 9. flickr.com/photos/cimmyt/5219256862
    • 10. flickr.com/photos/hatm/5704687186/ flickr.com/photos/cookingforvegans/3721103467/
    • 11. flickr.com/photos/avlxyz/5033183830/ flickr.com/photos/cookingforvegans/3721103467/
    • 12. Testes
    • 13. flickr.com/photos/lourdesmunozsantamaria/6139649843/
    • 14. flickr.com/photos/gabofr/4203458321/

    ×