Introdução a Canvas do HTML5

De alguns anos para cá a tendência no desenvolvimento Web é gerar gráficos de relatórios diretamente no navegador do usuário e não mais no lado servidor. A vantagem é que todo o processamento fica no lado cliente e devido ao dinamismo do JavaScript é possível aplicar efeitos e animações… muito legal, não é?

Mas você já se perguntou que tecnologia é utilizada para desenhar esses gráficos via JavaScript? A resposta é Canvas do HTML5.

Com Canvas podemos desenhar gráficos, figuras geométricas, imagens, textos e animações diretamente no browser. Para você ter idéia do poder da tecnologia, com um pouco de JavaScript e Canvas nosso ex-estagiário criou em questão de minutos a logo da TriadWorks:

Logo da TriadWorks em Canvas do HTML5
Logo da TriadWorks em Canvas do HTML5

Não pára por aí… Se você conhecer um pouquinho de JavaScript e tiver uma boa lógica de programação você consegue criar um jogo sem muitas dificuldades! O melhor é que seu jogo rodará no navegador do seu desktop ou smartphone!

Para ajudá-lo a entender como o Canvas funciona e dar seus primeiros passos com a tecnologia nós postamos no blog uma introdução muito objetiva e didática do assunto:

>> HTML5: desenhando gráficos no browser com Canvas

No post de quebra ainda te damos algumas dicas sobre engines e framework para criação de jogos usando HTML5.

Como você já deve ter observado, a tendência do mercado é aproveitar melhor os recursos do HTML5 e dos navegadores a fim de criar interfaces de usuário mais ricas. O próprio JSF 2.2 investiu pesado na integração com HTML5!

Enfim, com Canvas + JavaScript você pode ir muito longe!

O excesso de ifs no seu código JavaScript

O excesso de ifs no código é comum quando trabalhamos com JavaScript e parece normal e imprescindível em muitos casos, mas na verdade é um problema que pode trazer maus cheiros, como repetição de código, falta de legibilidade e prejudicar diretamente na manutenção do software.

Para resolver isso sem muito esforço, podemos usar práticas e princípios de orientação a objetos, como polimorfismo e herança. Em linguagens dinâmicas (como JavaScript, Ruby e Python) nós podemos tirar vantagens da linguagem e utilizar uma técnica mais simples porém tão poderosa quanto polimorfismo, neste caso, Duck Typing.

Para entender o uso da técnica de duck typing e remover o aglomerado de ifs do seu código, você pode ler o artigo no blog dos desenvolvedores da TriadWorks. Através de um exemplo prático e didático fica fácil enxergar a problemática e a solução com o uso de duck typing.

Este problema não só ocorre com JavaScript, mas com várias outras linguagens e paradigmas, inclusive com Java. Por esse motivo, é importante entender como podemos melhorar a qualidade do nosso código com práticas de orientação a objetos!

Não existe segredo: desenvolvedores e designers precisam colaborar entre si

Durante o desenvolvimento “Enterprisey” de aplicações web temos dois papéis realmente importantes dentro da equipe: o desenvolvedor e o [web] designer. Cada um possui suas atividades bem definidas durante o desenvolvimento do software, mas em algum momento será necessário que eles sentem juntos e colaborem para definir os detalhes da GUI.

Eles não irão colaborar entre si para definir a identidade visual da aplicação [não que não seja possível], mas sim para acertarem os detalhes “baixo nível” da interface ou mesmo como definir melhor a experiência do usuário. No final das contas, eles podem discutir sobre css, javascript, tags de marcação XHTML ou uma melhor disposição dos componentes visuais.

E isso é comum com qualquer tecnologia para web, seja ela PHP, RubyOnRails, .Net ou mesmo Java.

Mas o que eu realmente não entendo é porque muitos profissionais (desenvolvedores, gerentes, designers etc) encaram que desenvolvedor e designer não precisam -ou mesmo não deveriam- discutir sobre o design da interface da aplicação.

O que difere a comunicação entre um desenvolvedor e um analista de negócios que tentam definir ou acertar detalhes sobre o modelo de domínio da aplicação, e a comunicação entre um desenvolvedor (ou analista) e um designer que tentam acertar detalhes da interface com o usuário?

Nenhuma! Não há qualquer diferença, eles conversam e colaboram entre si com a mesma finalidade: terem software funcionando e que agregue valor ao cliente.

O que leva tantos profissionais a pensarem que desenvolvedor e designer são “peças” isoladas durante o desenvolvimento do software? Um modelo em cascata, talvez. Por estarem trabalhando num processo fabril de fábrica de software, talvez.

Não sei ao certo o motivo, mas sei que uma boa parte da culpa está na “balela” que algumas empresas-de-três-letrinhas tentam empurrar sobre seus clientes e/ou desenvolvedores que utilizam suas tecnologias/ferramentas. Um bom exemplo disso é a tecnologia JSF, na qual temos a descrição abaixo dada pela Sun:

Ease-of-use being the primary goal, the JavaServer Faces architecture clearly defines a separation between application logic and presentation while making it easy to connect the presentation layer to the application code. This design enables each member of a web application development team to focus on his or her piece of the development process, and it also provides a simple programming model to link the pieces together. For example, web page developers with no programming expertise can use JavaServer Faces UI component tags to link to application code from within a web page without writing any scripts.

Por mais bonito que isto pareça ser, eu tenho o dever de alertar aos mais desavisados: isso dificilmente irá funcionar durante o desenvolvimento com JSF – para falar a verdade, eu acho muito dificil que qualquer tecnologia hoje em dia consiga prover tamanha separação de responsabilidade (entre designer e desenvolvedor) de forma transparente e produtiva.

Qualquer desenvolvedor web que se preze possui, ao menos, os conhecimentos mínimos sobre XHTML, css e javascript para entender e manter algum código escrito por outra pessoa ou mesmo por um web designer. Se você é um desenvolvedor web e não possui qualquer conhecimento sobre o que eu disse acima então já está mais do que na hora de você aprender.

Não subestimando os designers, pois eu conheço alguns muito bons, mas se levássemos essa separação de responsabilidades ao pé da letra você acha mesmo que eles conseguiriam desenhar excelentes interfaces utilizando apenas as taglibs dos componentes ou conjuntos de componentes JSF?

Alias, você acha mesmo que um designer teria produtividade ou conseguiria expressar sua criatividade limitado apenas a algumas dezenas de tags, por mais ricos que sejam os componentes, visualmente falando? Isso pode piorar ainda mais se este designer for obrigado a utilizar algum editor -com o qual ele nunca trabalhou- apenas por causa do suporte a code-completion para as tags dos componentes.

JSF é uma boa tecnologia, e por mais que ela nos forneça centenas de componentes, frameworks para templating de páginas e estes componentes possuam um sistema de skinning ainda assim no final das contas teremos XHTML (css e javascript também) gerado. Sendo, de duas, uma: ou o designer deve ter conhecimento sobre o código gerado pelos componentes ou ele deve ter conhecimento de como trabalhar com o suporte a skinnking dos componentes.

Qualquer que seja a opção acima, o designer estará com mais responsabilidades do que o necessário. Por isso é tão importante a interação entre um designer e um desenvolvedor para solucionar problemas decorrentes da tecnologia adotada.

Eu falo tudo isso por experiência própria, pois há alguns meses eu tive uma razoável dificuldade para aplicar o css, definido no prótotipo do sistema, nos componentes JSF da aplicação, atividade esta que deveria ser relativamente simples. Sim, o conjunto de componentes que eu utilizei suportava skinning, mas quem disse que isso é suficiente quando o XHTML gerado por alguns componentes mais complexos é totalmente diferente do XHTML escrito pelo designer?

Foram vários dias adaptando o css da aplicação e, ao mesmo tempo, discutindo e redefinindo com os designers alguns pontos do css do prótotipo para que no final tivessemos o resultado ideal. E com certeza eu não teria sucesso nesta atividade se não fosse pelos dois grandes designers da equipe, Carlinhos e Anderson, que sentaram ao meu lado algumas longas horas durante a semana para me ajudar.

Certamente que há casos onde não podemos contar com um designer na equipe, como:

  • projetos em que a presença do designer é inexistente na equipe e algum desenvolvedor precisa assumir mais este papel;
  • o designer faz parte da equipe, mas por algum motivo ele sempre encontra-se impossibilitado de interagir com ela nos momentos de maior necessidade;
  • ou nos piores casos, o protótipo da aplicação foi criado por outra empresa.

Para cada situação é possível chegarmos a uma solução milhares de vezes melhor do que apenas ignorar o problema de que não há um designer na equipe – mas não é esta a questão do post.

Enfim, é muita ingenuidade (ou falta de conhecimento) destas pessoas que acreditam que desenvolvedores e designers [ou quaisquer membros da equipe] não precisam colaborar entre si para alcançar um resultado ideal que agrade o cliente.