Wednesday, October 16, 2013

Como hospedar um projeto em HTML5 no Google App Engine

Como hospedar um projeto em HTML5 no Google App Engine

Passo a passo de como utilizar o Google App Engine (appspot.com) para hospedar projetos em HTML5


Tutorial dividido em 3 partes:

  1. Registro no Goggle App Engine
  2. Download, instalação e configuração do Eclipse IDE
  3. Publicação da aplicação
Antes de começarmos deixe eu citar algumas das principais características do serviço Google App Engine que o tronam uma ótima alternativa para hospedagem de seus projetos.

As aplicações hospedadas no Google App Engine são de fácil construção, manutenção e principalmente muito fácil de dimensionar o serviço quando o tráfego e o armazenamento de dados da sua aplicação for crescendo.

No Google App Engine você não tem que se preocupar com servidores! Você faz o upload da sua aplicação para a infra estrutura do Google e pronto! Sua aplicação já pode ser utilizada pelos seus usuários.

Com o Google App Engine você só paga por o que você consome. Não há taxa de instalação e nenhum outro tipo de taxa. Apenas os recursos utilizados por sua aplicação é que são cobrados com valores bem competitivos aos praticados pelo mercado. Alem disso você pode facilmente configurar limites de utilização de recursos para cada uma de suas aplicações.

Não custa nada para você começar a utilizar o Google App Engine. Todas as aplicações podem utilizar até 1GB de storage, CPU e largura de banda suficiente para servir aproximadamente 5 milhões de visualizações de páginas por mes, ABSOLUTAMENTE DE GRAÇA!

Principais vantagens do Google App Engine:
  • Rodar suas aplicações na infra estrutura do Google
  • Ambiente de desenvolvimento integrado
  • Você  pode utilizar seu próprio domínio ou utilizar o domínio grátis do Google App Engine (ex: http://emersonestrella.appspot.com)
  • Você pode utilizar linguagens de programação como: PHP, Java, Python e Go

1. Registro no Google App Engine (Appspot)

Para se registrar, acesse: http://appengine.google.com e entre com a sua conta Google. Despois disso você poderá criar uma aplicação no Google App Engine utilizando o Admin Console. Clique no botão "Create Application"...


E complete o formulário...

Pronto! Aplicação criada.

2. Download, instalação e configuração do Eclipse

Acesse: http://www.eclipse.org/downloads/ e baixe a última versão do "Eclipse IDE for Java EE Developers"...

Descompacte o arquivo binário e execute-o.

O próximo passo é a configuração do Plug-in Google para o Eclipse. Abra o Eclipse e acesse: "Help" -> "Install new software"...

Clique no botão "Add..." para adicionar um novo site de atualizações. Em seguida complete o campo "Location" com a seguinte URL baseada na versão do Eclipse que você instalou:

Depois de adicionar o novo site de atualizações, volte para "Help" -> "Install new software" e selecione "Google Plugin" da lista de sites de atualizações...

... uma lista dos plugins disponiveis irá aparecer. Escolha o "Google Plugin for Eclipse" e clique em "Next >".

Você precisará reiniciar o Eclipse.


3. Publicação da aplicação

Crie um novo projeto no Eclipse para a sua aplicação. Para fazer isso basta ir em: "File" -> "New Project" -> "Google" -> "Web Application Project"...

Adicione todos os arquivos da sua aplicação no diretório "war" que está dentro do diretório do seu projeto no workspace do Eclipse.

Antes de subir sua aplicação para o Google App Engine você precisa lincar a seu projeto do Eclise com a sua aplicação do Google App Engine. Para isso você terá que editar o arquivo: "../war/WEB-INF/appengine-web.xml"

  • Adicione o mesmo nome que você colocou na sua aplicação no Google App Engine entre as tags "application"...
    • <application>my-application</application>
  • Adicione o numero da versão da seua aplicação entre as tags "version"...
    • <version>0.1</version>
Agora você está pronto para subir sua aplicação. É sempre recomendável que você teste localmente a aplicação antes de subi-lá.

Para subir sua aplicação, certifique-se de que você está logado com a sua conta Google. Se você não estiver logado, clique no botão "Sign in to Google" que está no canto inferior direito...


E finalmente, clique no botão "Google" que está no menu e escolha a opção: "Deploy to App Engine"...

Isso irá iniciar o processo de upload da sua aplicação e após alguns segundos sua aplicação estará disponível no Google App Engine.

É isso aí. Espero que tenha ajudado vocês que estão se perguntando como utilizar o Google App Engine. Se você encontrar alguma dificuldade durante esse processo deixe um comentário. Obrigado.

Tuesday, November 13, 2012

HTML5 Polyfills - Fullscreen e RequestAnimationFrame APIs


Até o momento esses são os melhores polyfills para utilizar Fullscreen e RequestAnimationFrame, features de HTML5 em browsers de hoje em dia.

RequestAnimationFrame API

Optimize concurrent animations together into a single reflow and repaint cycle, leading to higher fidelity animation, and using less CPU, GPU, memory, and battery.

http://my.opera.com/emoller/blog/2011/12/20/requestanimationframe-for-smart-er-animating

Fullscreen API

Provides an easy way for web content to be presented using the user's entire screen.

https://github.com/sindresorhus/screenfull.js

HTML5 AppCache API - Como prevenir o browser de cachear recursos que não serão utilizados no arquivo de manifesto


The method describe below doesn't work in all browsers.  
For now I'm using two different html files. But the best solution is on server side, making a rewrite rule for redirecting the user to the correct manifest file.


I'm writing a web application that uses the AppCache API for offline browsing. But I'm also using the Audio API to play back-ground music and a few audio effects.

For audio support in different browsers I'm delivering each sound/music in two different file formats: OGG and MP3.

The problem is regarding the cache manifest file. If we add all audio files (MP3 and OGG) in the cache manifest file, all browsers will cache all files. Including the unsupported ones. So, we end up with a huge storage requirement. Which is really bad if you are on a 3G connection for example.

So, to prevent browser caching unsupported resources, the best approach I've found was to split the manifest file. This way we can tell browsers that sopport OGG files to cache only OGG files, and do tha same for other formats like MP3.

Ok then. I have two manifest cache files, one with all OGG files listed (ogg.appcache) and the other one with the MP3 files (mp3.appcache).

Now what!? How do I swap from one to other?

Easy. First we should consider the browser supports OGG. If so, we can add the manifest attribute into the html tag with the right manifest file, just like that:


<html manifest="ogg.appcache">

Now, we have to check if the browser supports MP3. If it does, we change the value of the attribute "manifest" from the html tag. We can do that with this javascript:

var audio = document.createElement('audio');
if(audio.canPlayType('audio/mpeg;'))
  document.documentElement.setAttribute("manifest"document.documentElement.getAttribute("manifest").replace('ogg','mp3'));


jsperf é uma das melhores coisas que eu ví aparecerem neste ano. É uma poderosa engine de testes para Javascript.


jsperf é uma das melhores coisas que eu ví aparecerem neste ano. É uma poderosa engine de testes para Javascript.

Todo teste criado é público e listado lá. Portanto qualquer um pode testar o mesmo código em qualquer plataforma ou browser e todos os resultados são armazenados de forma que quanto mais pessoas rodarem cada teste mais informações para analise teremos.

Para ver como ele funciona e também para responder a uma pergunta relacionada a performance de renderização de textos com sombras na tag canvas, eu criei um teste no jsperf.

http://jsperf.com/requestanimationframe-canvas-drawing-text-shadows

Como eu só testei no Chrome e no Firefox o que eu poso dizer até o momento é:

No 18.0 a performance cai quase pela metade quando desenhamos textos com sombras no canvas.

Já no Firefox 12.0 observei a mesma situação. Mas comparando os resultados entre os dois browsers observei que o Chrome realiza a mesma tarefa que o Firefox na metade do tempo que o seu rival.

Lembre-se de que isso é apenas um simples teste e que eu testei apenas na minha máquina.

Testando softwares


Testando softwares

Antes

  • Desenvolvedores terminam o código e outra equipe se encarrega de testa-lo
  • Código passa por um processo de qualidade “Quality Assurance [QA]”
  • O pessoal de QA manualmente interage com o código

Hoje

  • Teste é parte de cada iteração no código
  • Desenvolvedores são responsáveis por testar o próprio código
  • Ferramentas de teste e processos são automatizados
  • Pessoal de QA e testes aprimora as ferramentas e os cenários de testes


Qualidade de software é o resultado de um bom processo, e não a responsabilidade de um grupo específico.


 

Debug na forma convencional X Test Driven Development



Conventional Debugging vs. TDD

Conventional 

  • Escreva 10 linhas de código, rode, veja o erro e adicione linhas de breaks no debugger
  • Insira linha de printfʼs para imprimir na tela as variáveis enquanto você roda o script repetidamente
  • Pare no debugger, mexa em algumas variáveis para controlar o flow do código
  • Droga! F@#&@#! Tinha certeza de que tinha corrigido isso, agora tenho que fazer isso tudo novamente

TDD

  • Escreva algumas linhas, só que antes de mais nada teste e descubra imediatamente de alguma coisa deu errada
  • Teste pequenas partes do código
  • Utiliza mocks e stubs para controlar o flow do código
  • Rode testes automaticamente

Jogo de quebra-cabeça HTML5 Puzzle agora é um Chrome Experiment


Jogo de quebra-cabeça HTML5 Puzzle agora é um Chrome Experiment


HTML5 Puzzle