Logo que o IE7 foi lançado em 2006, parecia algo lógico manter a compatibilidade com o IE6 por algum tempo, por mais doloroso que isso fosse. Usuários comuns mal sabem diferenciar entre um browser e o Google, atualizar para o IE7 nos primeiros dias seria pedir demais. O estranho é que, até hoje, quase 3 anos depois, muitos de nós continuam a dar suporte ao browser. Perdemos tempo, paciência e alguns anos de vida corrigindo bugs e assegurando que tudo funcione relativamente bem. Isso significa que nivelamos nosso desenvolvimento por baixo, deixando de usar coisas como PNGs transparentes, muitos seletores CSS e scripts mais eficientes, só para começar a listar alguns. Algo está errado aí, você não acha?

Mas se o browser é usado pelo usuário, como isso pode ser culpa nossa? Simples: enquanto tudo funcionar, o usuário não fará o menor esforço para atualizar seu software. O usuário é acomodado (pra não dizer ignorante). É preciso tomar atitudes para que ele se atente que seu software está muito ultrapassado, e essa atitude cabe a nós. Por pressão dos clientes e dos nossos superiores, o máximo que conseguimos foram barrinhas sutis no topo da página que, convenhamos, não servem para nada mais do que decoração e alívo de consciência. Será preciso muito mais que isso.

Até que as coisas deixem de funcionar, o usuário não fará nada. Fato. Em um mundo ideal, os sites de maior tráfego não dariam mais suporte a browsers legados, e a evolução começaria a acontecer. Como não vivemos em um mundo ideal, precisamos dar o nosso jeito. Educar o cliente, os parentes, os amigos, pode até parecer legal, mas é numa escala muito pequena. Em meus projetos pessoais, coisas como a singela tela acima começarão a aparecer. Como freelancer, o suporte ao IE6 terá seu preço (e as telas de aviso serão um pouco mais educadas). Na agência onde trabalho ainda enfrento alguns problemas, mas na maioria dos projetos o IE6 é completamente ignorado, e simpáticas telas explicando como atualizar o browser estão sendo implementadas.

Não existe mais motivo algum para a existência do IE6. Não deveriam mais existir motivos para mantermos a compatibilidade. Eu seria um profissional muito mais feliz se, em 2010, eu nunca mais ouça falar em Internet Explorer 6. Acredito que esse seja o desejo de muitos, e espero que ele consiga ser realizado dessa vez. Vamos fazer nossa parte e acabar com o monstro que criamos?

Posts Relacionados

• innerOptions
• Histórico para Navegação via JavaScript
• Hijax: Ajax Acessível
• Ajax vs. Acessibilidade
• Interfaces de Usuário com JavaScript

Web Standards

Hoje em dia, o mínimo que se espera de um bom desenvolvedor web é o conhecimento dos Web Standards, XHTML e CSS. Eles contribuem para a criação de documentos mais consistentes entre si, mais compatíveis e de manutenção extremamente mais simples. Aliás, o conhecimento dos padrões não é mais um diferencial como era há alguns anos atrás, mas sim um requisito básico. Se hoje sonhamos com a web semântica, os padrões web são o primeiro passo. Com documentos mais semânticos, temos mais acessibilidade e também mais relevância, principalmente no que diz respeito a motores de busca.

Mesmo depois de muita evangelização, ainda temos desenvolvedores que acabam de descobrir as maravilhas do mundo validado. Também temos aqueles que não fazem a mínima idéia do que isso signifique, ou que não tem o mínimo interesse em aprender. Se você é um desses, hora de rever seus conceitos…

JavaScript

O JavaScript, apesar de ter sido muito injustiçado no passado, é uma linguagem onipresente, e de extrema importância. Qualquer usuário tem pelo menos um interpretador instalado em seu computador. Além do mais, ela é a única linguagem client-side disponível, e permanecerá assim por um bom tempo.

JavaScript vai ser a próxima grande linguagem. Apesar de ainda estarmos longe de resultados surpreendentes, caminhamos rápido nesse sentido. Muita coisa que antigamente só era possível com Flash hoje é feita com JavaScript.

Além da própria linguagem, aprenda a usar alguma biblioteca, como Mootools, jQuery ou Prototype. Aliado a essas ferramentas, você poderá criar aplicações muito mais interessantes em muito menos tempo. Mas atenção: não aprenda somente a biblioteca, sem aprender antes JavaScript puro. Afinal, saber só jQuery é coisa de designer.

Expressões Regulares

Um simples replace nem sempre é suficiente quando trabalhamos com manipulação de textos. Aí entram as Expressões Regulares, poderosa ferramenta que todos conhecem, alguns usam, e poucos realmente sabem. Seja em PHP, Ruby, Python ou mesmo JavaScript, algum dia você precisará delas.

Se você leva desenvolvimento a sério, dedique um tempo a aprender expressões regulares (Expressões Regulares – Uma Abordagem Divertida é um bom começo!). Além de uma ferramenta de desenvolvimento, elas podem se tornar ferramentas de produtividade. Se você usa IDEs com suporte a busca e substituição com expressões regulares, pode se beneficiar muito disso.

Controle de Versão

Para alguns, o Controle de Versão mudou completamente, e para a melhor, a forma de trabalhar. Para outros, parece simplesmente inútil, principalmente para quem trabalha sozinho. Seja CVS, SVN, GIT, Mercurial ou qualquer outro, o controle de versão, aliado a ferramentas como o Trac, pode fazer maravilhas. Além de manter controle de suas alterações, podendo sempre voltar atrás caso alguma modificação dê errado ou mesmo quando o cliente não aprova, você pode manter um controle de sua produtividade, analisando quantos commits foram feitos em quanto tempo, quantos tickets foram fechados, quantos ainda permanecem pendentes.

Desde que passei a utilizar SVN em alguns projetos, como no próprio Spaghetti, notei uma grande melhora no controle sobre o código. Nunca mais pensei duas vezes em apagar grandes blocos de código pensando que eles poderiam ser úteis outra vez (e geralmente nunca seriam realmente necessários). Uma excelente forma de analisar seu progresso, uma excelente forma de backup, uma excelente forma de manter seu código sincronizado. Esqueça aquele colega que tem uma versão ultrapassada de seu código e sobrescreve partes importantes. Quando passei a utilizar ferramentas de tracking, bugs não eram esquecidos, idéias estavam sempre à mão. Digo, como muitos por aí: isso realmente mudou a minha maneira de desenvolver.

MVC

O Model-View-Controller, ou MVC para os íntimos, nunca fez tanto sentido quanto na web. Depois do Ruby on Rails, virou quase um requisito básico para o desenvolvimento de bons projetos. E desde então, desenvolver não tem mais graça. Além disso, a separação de aplicações nessas 3 camadas torna o desenvolvimento e manutenção muito mais simples.

Se você não quer ficar para trás, adote seu framework. O pattern é usado na maioria deles, e de brinde você ganha muita produtividade. Frameworks tornam as linguagens menos ruins. Se você usa PHP, eu sugeriria o Spaghetti. Se você usa Ruby ou Python, e é seu primeiro contato com frameworks, siga a tendência e adote Rails ou Django. Se você é corajoso, faça como fizemos na minha agência: crie seu próprio framework. Usando algum framework ou não, o que importa é pegar o espírito da coisa.

SQL

Mesmo com toda a flexibilidade e abstração da camada de dados que os frameworks MVC nos oferecem, SQL ainda é necessário. Apesar de você não vê-lo, ele ainda está lá. Consultas complexas ou mais específicas nem sempre são disponibilizadas pelos frameworks, e sempre pode haver a necessidade de uma incursão via terminal, para tarefas de manutenção, por exemplo.

Talvez você não acredite no retorno que isso pode trazer. Até ter nas mãos uma aplicação gigante e extremamente dependente de banco de dados, onde as consultas devem ser otimizadas ao máximo para minimizar a carga do servidor. Você não quer sua aplicação baleiando por você não saber SQL, quer?

Desenvolvimento Guiado a Testes

Test Driven Development, ou simplesmente TDD, é, na minha opinião, a melhor maneira de manter seu código livre de bugs. Fazer o desenvolvimento guiado a testes significa desenvolver o teste antes da funcionalidade. A cada iteração, os testes são rodados novamente, de maneira automática, e você sempre saberá se alguma modificação quebrou o restante do código.

Sem testes automatizados, aplicações nunca são testadas como deveriam. São tarefas repetitivas e cansativas. Com o auxílio de ferramentas de testes, eles podem ser rodados várias vezes, certificando de que tudo está correndo bem. Se um novo bug é descoberto, um novo teste é criado, as modificações são feitas, e você terá a certeza de que o problema foi resolvido para todo o sempre, sem quebrar o restante da aplicação. E convenhamos, não há nada pior do que bugs…

Não é obrigatório que um desenvolvedor saiba tudo isso, embora eu considere extremamente importante, mesmo alguns não sendo necessários todos os dias, todos podem melhorar nossa maneira de trabalhar. Ainda não domino todos os itens citados, mas tenho um bom conhecimento em todos eles. O que importa mesmo é buscar isso, e sempre continuar aprendendo. Mexa-se! Você não quer ficar para trás, quer?

Posts Relacionados

• Qual curso devo fazer pra me tornar um desenvolvedor web?
• Comodismo vs. Inovação
• E a tal da Web 2.0?
• CodeCast #1 – Impressões sobre Início de Carreira
• ResponseXML

O número dessas bibliotecas é incontável, algumas mais simples, outras mais complexas, outras mais famosas, algumas nem tanto. Fiz uma breve pesquisa, e trouxe as mais conhecidas (e algumas nem tanto) para quem ainda não teve a oportunidade de conhecer. Só para lembrar, hoje não vou tratar sobre o uso dessas bibliotecas, isso fica pra uma próxima oportunidade, já que a idéia é um pouco extensa.

ExtJS

A ExtJS é de longe a biblioteca mais conhecida. Provavelmente você já deve ter pelo menos ouvido falar sobre, a menos que você viva na Sibéria. Também acredito que deva ser uma das mais antigas, e por isso uma das mais completas também.

Seu visual é espetacular, mas tem seu preço: ela é muito lenta. Todos os efeitos de transparência, os drag ‘n’ drops, tudo isso exige muito do pobre navegador. Pense bem antes de escolher onde usá-la, faça somente se for necessário, nunca para simples “enfeites”. Lenta, mas uma obra de arte.

E os desenvolvedores AIR não precisam ficar tristes: há até um demo do bichinho em funcionamento. Ainda não tive muito tempo com o AIR, mas acredito que a questão da velocidade não seja tão crítica quanto em um navegador, quem puder falar sobre, agradeço.

Yahoo User Interface

A Yahoo User Interface, ou YUI, deve ser a primeira user interface a se popularizar. Foi a base do nascimento da ExtJS. Tem lá seus defeitos, como o prefixo YUI para todos os métodos, mas tem um poder imenso. Me parece ser bem mais leve que a Ext, e usa gráficos bem mais simples também.

A documentação é um dos pontos fortes. Mantida pela comunidade de desenvolvedores do Yahoo, você nunca estará sozinho. Apesar disso, achei o site um pouco confuso para encontrar alguma coisa, principalmente os demos. Mas o material está lá, e há muito…

MochaUI

Ainda beta, a MochaUI seria a minha preferida. Adivinhem por quê? Sim, baseada na Mootools… A demonstração realmente me deixou impressionado, talvez tenha sido o relógio.

Aparenta ser bem leve, tanto que na demonstração você pode modificar propriedades das janelas sem travar o navegador. Usa gráficos simples, mas não menos atraentes. De longe, seria a primeira que eu escolheria para trabalhar (sim, opinião extremamente parcial). Mal posso esperar pela versão 1.0!

Dijit

Falando em Dojo, nem é preciso dizer muito. O framework mais abrangente que conheço também conta com sua interface de usuário, o Dijit. Não consegui encontrar demonstrações no site, mas as imagens mostram algo realmente promissor.

Lendo a descrição do projeto, você verá que o Dijit não é apenas uma simples interface de usuário. É extremamente customizável, extensível, acessível e localizável. O que isso significa? Bem, dê asas à imaginação, o céu é o limite…

jQuery UI

O jQuery UI, bem jovem ainda, também é espetacular. Baseado na brilhante jQuery, tem tudo para deixar qualquer um de boca aberta. A demonstração de efeitos, por exemplo, me impressionou muito. A própria tela de demonstrações é uma obra de arte.

Apesar de baseada no jQuery, achei a biblioteca ligeiramente lenta. Talvez tenha sido impressão, mas não esperava isso de jQuery. Entretanto, pela sua idade, é muito madura, muito poderosa. Se jQuery não havia me chamado atenção ainda…

Prototype UI

Até então desconhecido pra mim, o release candidate Prototype UI não conseguiu me chamar a atenção. Não por ser baseado em Prototype e Scriptaculous (o que já considero um ponto contra), nem por usar um tema do Mac, mas por parecer muito prematura. Os demos apresentados são bonitinhos, mas um tanto “crus”. Prefiro não dar minha opinião, vai que o negócio vire um Ext-killer?

SproutCore

O SproutCore, iniciativa da Apple, tem uma proposta um tanto “utópica”, pelo que entendi é trazer o Cocoa para a web. As demonstrações são interessantes, mas o pobre navegador sofreu as conseqüências. Esse negócio consegue ser mais pesado que a própria Ext! Além disso, vi mais opiniões negativas do que positivas…

UIZE

O UIZE (pronuncia-se “you eyes”) é outro que nunca havia sido apresentado a mim. Concordo com o pessoal do Ajaxian: são os efeitos mais legais que já vi. Apesar disso, a biblioteca ainda necessita muito mais trabalho, já que tem poucos recursos (poucos, mas legais).

Não tive a oportunidade de trabalhar por algum tempo com nenhuma dessas bibliotecas, e nem falar muito sobre as quais tenho mais experiência. Somente uma breve opinião sobre cada uma. Caso tenha esquecido de alguma, por favor, cite-a nos comentários, terei prazer em falar um pouquinho. Só uma precaução: cuidado onde você irá usar tudo isso… Existem aplicações e aplicações. Até mais!

Posts Relacionados

• Mootools vs. jQuery
• Estendendo o JavaScript
• Histórico para Navegação via JavaScript
• Estatísticas para Navegação via JavaScript
• jQuery – Segundas Impressões

O PHP não é a linguagem mais “cool” para se desenvolver para web no momento. Outras linguagens estão tomando o posto por serem mais compatíveis com o ambiente web que temos hoje. Um dos fatores que mais influencia nessa “tomada de território” é a agilidade no desenvolvimento que, aliado aos frameworks dessas linguagens, tornam o PHP quase obsoleto. Há como manter o PHP a pelo menos um nível competitivo com essas linguagens?

Apesar de todos os seus defeitos, o PHP ainda é a linguagem mais usada no mercado, embora venha perdendo espaço para novas tecnologias, como Ruby e Python. Aliadas a poderosos frameworks, essas “novas” linguagens (Ruby e Python são muito mais antigas que você imagina) tornam o desenvolvimento muito mais rápido. Só com o PHP, raça e vontade nunca será possível alcançar tais níveis de produtividade. A solução é seguir a mesma idéia: adotar um framework.

Não culpo o PHP por ser uma linguagem bem mais lenta em termos de desenvolvimento, a culpa é dos próprios desenvolvedores. Eles geralmente escolhem o lado mais difícil da coisa, recriando toda a estrutura para cada novo sistema. Poucos se preocupam em pesquisar por novas soluções que resolvam seus problemas de maneira mais rápida e automatizada. Ruby e Python, apesar de serem linguagens mais ágeis em minha opinião, só se tornaram “modinha” após o aparecimento dos frameworks. Por que os programadores PHP não escolhem o mesmo caminho?

Apesar de estar migrando, agora passo a acreditar que o que realmente importe talvez não seja somente a linguagem, mas sim as ferramentas que nos auxiliam com elas (leia-se frameworks), além dos próprios programadores. Pra que sofrer? Provavelmente alguém com mais tempo e conhecimento já tenha criado uma solução para determinado problema, bem melhor do que você mesmo poderia fazer, sem tempo e às vezes sem tamanho conhecimento.

Confesso que nunca havia usado um framework para PHP, embora já tenha sentido necessidade. Sempre praguejava a cada sistema iniciado, mas mesmo assim desenvolvia minhas próprias soluções para tornar o desenvolvimento menos doloroso. Isso durou até um mês atrás, quando me vi diante de um sistema bem complexo a ser desenvolvido na agência onde trabalho. Sem um framework, levaríamos meses para acabar. A única solução foi a adoção de um framework para PHP. Agora, o desenvolvimento do sistema flui rapidamente, e de maneira bem menos dolorosa, chata e sem graça.

A solução escolhida por nós foi o CakePHP, talvez o framework mais conhecido para PHP. Sem dúvida alguma, é uma ferramenta de grande poder na hora de desenvolver, principalmente na versão 1.2 (ainda beta, com documentação escassa até o momento, e que talvez dê algumas dores de cabeça até que esteja completa). Para mim, o tempo de desenvolver em PHP puro se encerrou para sempre.

Talvez você não goste tanto do Cake quanto eu, e prefira outras opções. Opções não faltam, há o Code Igniter, o Zend, o Symfony, entre dezenas de outros. Não importa qual seja o framework, desde que ele traga um ambiente mais rápido e agradável para desenvolvimento. Pra falar bem a verdade, uma das maiores razões para eu ter escolhido um framework em lugar de criar minha própria biblioteca de funções foi a implementação de orientação a objetos nesses frameworks, que pra mim dão muito mais sentido à programação.

Para programadores de outras linguagens, o mesmo princípio se aplica: não importa qual solução se use, desde que ela traga benefícios. Me direcionei para PHP pois é onde mais trabalho no momento e, por ironia, a linguagem que menos gosto. Os frameworks foram algo que me fizeram tomar um pouco mais de gosto pela linguagem. E se você não utiliza nada para ajudar no desenvolvimento, está na hora de rever seus conceitos…

Posts Relacionados

• CodeCast #5 – Frameworks
• JSON no PHP
• PHP Orientado a Objeto
• Pense Mais e Codifique Menos
• Por que projetos “morrem”?

Linguagens de programação e frameworks de desenvolvimento surgem aos montes no ambiente web. De uma maneira ou outra, nossas velhas ferramentas acabam se tornando obsoletas. Por mais que tenhamos domínio sobre elas, o rendimento não se equipara a novas ferramentas, seja em produtividade, desempenho, facilidade de uso ou qualquer outro fator. Será que é hora de abandonar nossa velha forma de desenvolver para dar lugar a novas ferramentas?

As ferramentas com as quais estamos acostumados, como o PHP, por exemplo, foram criadas para resolver os problemas que tínhamos à época em que foram criadas, baseando-se nos métodos dessa época. Elas têm nos servido muito bem, e provavelmente ainda poderão servir por algum tempo mais. Mas a web muda, e as exigências quanto ao desenvolvimento nesse ambiente também. Não basta mais resolver um problema, esse problema deve ser resolvido de forma rápida e eficiente. Com a correria de hoje em dia, só PHP não basta mais.

Com o tempo, além de recriamos soluções para velhos problemas, novos problemas vão surgindo. A web não é mais um ambiente minúsculo como era há alguns anos atrás. Ela cresceu. Cresceu muito. A demanda por serviços, e por serviços cada vez mais rápidos é muito maior do que antes. Criamos novos problemas e precisamos de soluções para eles. Nossas antigas ferramentas não estão preparadas para tanto.

De uma forma ou outra, precisamos ser ágeis. Os frameworks estão aí para ficar. Como o capitalismo nos obriga a produzir em velocidade insalubre, somente uma boa linguagem de programação também não basta. Precisamos ser rápidos, muito, muito rápidos. Mesmo para linguagens não tão recentes, já existem soluções ótimas. Há vida além do Rails e Django!

Embora essas novas tecnologias sejam fascinantes, há um pequeno problema. Uma nova ferramenta leva a uma curva de aprendizado. Isso toma tempo, “tempo de processamento”, enfim, nos tirar de nossa zona de conforto. A questão é: devo eu partir pra outra? A minha resposta é: depende.

Tudo é relativo, e não há uma resposta pronta para esse tipo de pergunta. Você pode se sentir realmente confortável com certa linguagem, e conseguir ser extremamente produtivo com ela, ao passo que, mesmo conhecendo bem outras ferramentas, não consegue manter o mesmo ritmo. Nesse caso, sempre existem os frameworks. Não é necessário “reaprender a programar”, e ganha-se o benefício de um desenvolvimento mais rápido. Nesse caso, mudar de ares não é algo sensato a se fazer, principalmente se você tem um tempo escasso.

Já se você consegue ser produtivo em várias linguagens, opte por aquela mais moderna e robusta, ou continue buscando algo novo. Assim tem-se o benefício da versatilidade: não importa a ferramenta, importa saber fazer.

Meu caso é um pouco diferente. Apesar de trabalhar diariamente com PHP, nunca gostei da linguagem. Parece-me mais uma biblioteca de funções do que uma linguagem bem estruturada. Quando fui apresentado ao Ruby, me rendi. Apesar de não ter me aventurado muito ainda, é o que pretendo seguir. Não tanto por produtividade, nem tanto por “moda”, mas por gosto. Não deixa de ser um motivo válido…

Tenho certeza que esse assunto dá uma boa discussão. Qual sua opinião? Fixar-se em uma ferramenta e especializar-se nela, ou procurar algo diferente que melhore sua forma de trabalhar?

Posts Relacionados

• 7 coisas que todo desenvolvedor web deveria saber
• Caindo na Real
• Vale a pena arriscar em novas tecnologias?
• Digg pra quê?
• Fim ou Recomeço?

Em 20 poucos minutos falamos um pouco sobre semântica, microformats, XML, RDF, e qualquer outra coisa relacionada que eu possa ter esquecido no momento. CodeCast #3 – A Semântica e Microformatos.

Peço desculpas pela recente ausência, e pela falta de respostas para alguns contatos. Logo logo respondo todo mundo, e também pretendo postar alguma coisa em breve (juro!). Até mais!

Posts Relacionados

• CodeCast #1 – Impressões sobre Início de Carreira
• CodeCast #4 – Adobe Flash
• CodeCast #2 – XHTML 2 e HTML 5
• CodeCast #5 – Frameworks
• Semântica

Desta vez falamos sobre os novos padrões, XHTML 2 e HTML 5. Coisas legais, mancadas, acessibilidade, semântica, enfim. Seguimos algumas dicas do pessoal, fizemos o podcast em apenas 30 minutos, tínhamos uma pauta (que não foi seguida muito à risca, mas ela existia) e também já temos o RSS funcionando.

Como disse o Rafael, escutem que está bem legal!

Posts Relacionados

• CodeCast #3 – Semântica e Microformatos
• CodeCast #1 – Impressões sobre Início de Carreira
• CodeCast #4 – Adobe Flash
• CodeCast #5 – Frameworks
• Semântica

É com grande prazer que anuncio o primeiro episódio do CodeCast, projeto meu juntamente com o Rafael Marin. Um podcast sobre desenvolvimento web e todas as suas possíveis vertentes.

Nessa primeira edição, falamos sobre Impressões sobre Início de Carreira, com relação ao que já conseguimos perceber em nossas experiências na área. Como somos novos nesse negócio de podcast, já peço desculpas por qualquer bobagem dita ou os “ahmmm”, “hummm”, que podem ter aparecido de maneira mais exagerada… Mas a gente aprende com o tempo.

E de vocês, caros leitores-ouvintes, aguardamos um feedback sobre essa nova empreitada. Qualquer sugestão, crítica, elogio, reclamação ou o que seja, sinta-se à vontade para nos dizer.

Baixe a primeira edição: Impressões sobre Início de Carreira, em qualidade alta (44MB) ou qualidade baixa (19MB). Duração: 48 minutos. E vou ficando por aqui, até mais!

Posts Relacionados

• CodeCast #4 – Adobe Flash
• CodeCast #5 – Frameworks
• CodeCast #2 – XHTML 2 e HTML 5
• CodeCast #3 – Semântica e Microformatos
• Sobre

O Code Assist

Ferramentas que facilitam a vida do desenvolvedor não faltam no Aptana. O Code Assist é uma delas. Quando você digita o nome de algum objeto (document, por exemplo), ele mostra todos os métodos e propriedades disponíveis, permitindo que você complete o código sem precisar digitá-lo por inteiro. Isso também funciona para funções comuns, quando se começa a digitar seu nome.

Além de completar seu código, o Code Assist ainda mostra as informações sobre o método, como parâmetros, retorno, descrição e compatibilidade (no caso de métodos do JavaScript ou DOM) através de uma tooltip. Essa mesma tooltip também aparece quando se digitam os parênteses de alguma função, mostrando seus parâmetros e suas descrições.

Também é possível usar o Code Assist com seus próprios scripts, ou seja, usar toda essa facilidade juntamente com as classes, métodos e funções que você escreveu. Para usar o Code Assist com seus códigos, é necessário documentá-los através do ScriptDoc, mais uma ferramenta do Aptana.

O ScriptDoc

A documentação através do ScriptDoc funciona com blocos de comentário dentro do próprio código JavaScript, seguindo um padrão definido. Basicamente, um bloco de documentação deve ser assim:

/**
* Descrição do Código
*/

Esse bloco deve ser incluído logo acima da função que se deseja documentar, e ela será automaticamente vinculada à esse bloco de documentação pelo parser do Aptana. A primeira linha, para todos os blocos de documentação (exceto na descrição de arquivos), deve ser uma pequena descrição da classe, método ou atributo. Nas linhas seguintes podem ser incluídas tags que adicionem mais informações sobre o código.

/**
* Cria um elemento HTML
* @param {String} tagName Nome da tag a ser criada
* @return {Object} Retorna a tag criada
*/
function createHTMLElement(tagName) { }

O ScriptDoc permite várias tags, as duas usadas acima são apenas para um exemplo simples. Há uma lista compreensiva de tags na documentação do Aptana, tanto on-line quanto off-line. Veja o resultado da função documentada:

A descrição de arquivos também pode ser feita de maneira bem semelhante, através da tag @projectDescription, e outras que também podem ser usadas no restante da documentação.

/**
* @projectDescription Descrição do Arquivo
* @author Autor
* @version 1.0
*/

Usando arquivos .sdoc

Caso você não queira que sua documentação fique diretamente no script, apenas ocupando espaço desnecessário, ela pode ser colocada em um arquivo externo, de extensão .sdoc.

Para que esse tipo de documentação funcione, é necessário criar um arquivo com o mesmo nome do script, mas com a extensão .sdoc, fazendo com que o Aptana reconheça o arquivo como sendo documentação do script.

No arquivo .sdoc, pode-se escrever a documentação normalmente, assim como seria no script. Há apenas uma modificação a ser feita: deve ser incluída a tag @id para cada bloco de documentação, e deverá haver uma tag correspondente no script (somente a tag @id). Veja um exemplo do arquivo .sdoc:

/**
* Cria um elemento HTML
* @id createHTMLElement
* @param {String} tagName Nome da tag a ser criada
* @return {Object} Retorna a tag criada
*/

E também um exemplo do script:

/**
 * @id createHTMLElement
 */
function createHTMLElement(tagName) { }

No início de ambos os arquivos também pode ser inclusa a tag @namespace, que definirá um objeto que englobará todas as funções e atributos do script. Se incluíssemos @namespace HTML em nossos exemplos, poderíamos usar tanto createHTMLElement quanto HTML.createElement. É claro que não funcionaria no script, a menos que assim quiséssemos.

É por isso que a cada dia mais gosto do Aptana, apesar de ser extremamente pesado (Aptana + WMP não dá certo). Adicionando mais tags pode-se criar uma documentação ótima para seus scripts, e de uma maneira muito simples. Também há planos de um gerador HTML para a documentação ScriptDoc, basta esperar. Pra quem não conhece o Aptana, vale o teste. Aproveitem, e até a próxima!

Posts Relacionados

• Histórico para Navegação via JavaScript
• ResponseXML
• Cookies em JavaScript
• Estatísticas para Navegação via JavaScript
• Interfaces de Usuário com JavaScript

Esse elemento funciona apenas em browsers mais modernos. Firefox 1.5+, Operaernos. Firefox 1.5+, Opera 9, Safari ou qualquer outro browser com a engine Gecko 1.8. E não, não funciona no IE, eu havia dito browsers e modernos.

Marcação

Diferente do SVG, todo nosso desenho será feito via scripting, e não temos tanto controle sobre os elementos desenhados. O que devemos fazer é adicionar nossa “área de desenho” na marcação:

<canvas id="canvas" width="150" height="150"></canvas>

A altura e largura do canvas são definidos, respectivamente, por height e width, que também podem ser definidos pelo DOM ou CSS. Caso não sejam especificados, assumem 300px de largura e 150px de altura por padrão.

Acessando o Canvas

Agora vamos ao script. Primeiramente, precisamos esperar o documento carregar para podermos começar a desenhar, caso contrário seremos avisados que o elemento não existe. Depois, precisamos obter o elemento do canvas, através de document.getElementById, nada de espetacular.

Para termos acesso às funções de desenho, precisamos acessar tal contexto. Cada elemento canvas possui o método getContext, que leva apenas um parâmetro, que logicamente é o tipo do contexto de desenho. Atualmente, somente o contexto “2d” é aceito, mas no futuro poderá ser implementado “3d” também. Agora vamos juntar tudo, e criar o código:

window.onload = function() {

  var canvas = document.getElementById("canvas");

  canvas = canvas.getContext("2d");

}

Agora já acessamos o contexto de desenho e podemos começar a desenhar, embora ainda não vejamos nada em nosso canvas canvas. Ele ainda é apenas uma área transparente.

Para desenharmos, usaremos aquele clássico sistema de coordenadas (x,y), como nos programas de design e nas aulas de matemática. Cada unidade corresponde a 1 pixel, e o topo esquerdo é a posição (0,0). Todas as coordenandas são definidas com base nesse ponto.

Formas

Em canvas, existe apenas uma forma primitiva, que são os retângulos. Todas as outras formas são criadas através da combinação de “paths”, que vamos ver logo depois. Para o desenho de retângulos, podemos utilizar 3 funções:

• fillRect(x, y, largura, altura): desenha um retângulo preenchido
• strokeRect(x, y, largura, altura): desenha um retângulo sem preenchimento, apenas contorno
• clearRect(x, y, largura, altura): limpa uma área retangular do desenho

Observe o exemplo abaixo, utilizando os três métodos. Primeiro, preenchemos um retângulo. Logo após, limpamos uma área de dentro do retângulo anterior, e dentro dessa área limpa contornamos outro retângulo. Vejamos um boneco bem, digamos, “quadradão”:

window.onload = function() {

  var canvas = document.getElementById("canvas").getContext("2d");

  canvas.fillRect(0,0,150,150);

  canvas.clearRect(15,25,30,30);

  canvas.strokeRect(17,27,26,26);

  canvas.clearRect(105,25,30,30);

  canvas.strokeRect(107,27,26,26);

  canvas.clearRect(63,65,24,30);

  canvas.clearRect(15,120,120,10);

}

Cores

Cores também são um aspecto “chatinho” de se trabalhar em Canvas. Não é possível definir uma cor especificamente para uma forma, é algo mais genérico. Usamos as propriedades fillStyle e strokeStyle, que definem a cor para preenchimento e contorno, respectivamente, para as formas desenhadas posteriormente (não temos controle sobre formas desenhadas anteriormente). Elas aceitam valores rgb, rgba, valores hexadecimais e nomes em inglês (“red”, “green”, “blue”…). Vamos fazer uma modificação no desenho anterior:

window.onload = function() {

  var canvas = document.getElementById("canvas").getContext("2d");

  canvas.fillStyle = "#ffff66"

  canvas.strokeStyle = "blue";

  canvas.fillRect(0,0,150,150);

  canvas.clearRect(15,25,30,30);

  canvas.strokeRect(17,27,26,26);

  canvas.clearRect(105,25,30,30);

  canvas.strokeRect(107,27,26,26);

  canvas.strokeStyle = "rgba(0,0,0,0.8)";

  canvas.strokeRect(63,65,24,30);

  canvas.fillStyle = "#ff0000";

  canvas.fillRect(15,120,120,10);

}

Paths

Os paths (caminhos), são basicamente linhas que assumem vários formatos que, quando combinadas, nos permitem criar as mais diversas formas. Se você tem uma base, mesmo que mínima, sobre desenho vetorial, vai entender perfeitamente o que digo.

Para desenharmos esses “caminhos”, precisamos iniciar um novo path, através do método beginPath. Apesar de termos iniciado um caminho, ainda não há nada no canvas.

Depois de iniciado, precisamos invocar os métodos que especificam como o path será desenhado, que forma ele deverá ter. Podemos desenhar linhas, arcos, curvas e retângulos. Não vou explicar os métodos agora pra não perder a graça.

Após termos desenhado todo o path através dos métodos que (não) citei acima, pode-se fecha-lo (opcional se o path será preenchido) através do método closePath. Ele tentará traçar uma linha reta do último ponto para o ponto inicial, se o caminho já não estiver fechado ou tiver apenas um ponto.

Embora a forma esteja “desenhada”, ela ainda não aparece no canvas. Isso porque todo o caminho fica na memória até que o passemos para o canvas. Para tal, precisamos preenchê-lo ou contorná-lo, através dos métodos fill e stroke, respectivamente.

Nossos primeiros paths serão baseados em linhas, que podem ser desenhadas pelo método lineTo(x, y). Ele desenha uma linha do ponto corrente do path até as coordenandas (x, y) passadas como parâmetro. Vamos ver um exemplo:

canvas.beginPath();

canvas.lineTo(150, 150);

canvas.lineTo(0, 150);

canvas.lineTo(0, 0);

canvas.fill();

canvas.beginPath();

canvas.moveTo(0,0);

canvas.lineTo(150, 0);

canvas.lineTo(150, 150);

canvas.closePath();

canvas.stroke();

Desenhamos dois triângulos, um preenchido e outro contornado. Note que, quando usamos fill, não é necessário fechar a forma. Note também uma chamada ao método moveTo, será um dos métodos mais utilizados em suas composições. Fica o mistério…

O método moveTo move a origem do path para qualquer ponto do canvas. É equivalente a levantar o pincel e começar a desenhar a partir de outro ponto. Toda vez que adicionamos um path à lista, essa origem será o lugar do último ponto desenhado, a menos que ele fosse mudado. Veja o exemplo anterior sem a chamada ao moveTo.

Iniciamos então com os arcos. Eles são a base para a criação de qualquer tipo de forma circular, círculos, semicírculos, semi-semicírculos… São criados através do método arc(x, y, radius, startAngle, endAngle, anticlockwise)que na minha opinião é um método um pouco mais complicado.

Os parâmetros x e y determinam o centro do arco. radius indica o tamanho do raio, em pixels. startAngle e endAngle são os ângulos de início e fim do arco, medidos em radianos. Sou péssimo nisso aí, e uso o seguinte código de conversão (retirado do MDC):

var radians = (Math.PI/180)*degrees;

Pra quem também não é muito bom em geometria, 0 e Math.PI desenham um meio círculo e 0 e Math.PI*2 desenham um círculo completo.

Há também o último parâmetro, anticlockwise, booleano, que define se o círculo deverá ser desenhado para o sentido horário (false) ou anti-horário (true).

// Exemplo do MDC

canvas.beginPath();

canvas.arc(75,75,50,0,Math.PI*2,true); // Rosto

canvas.moveTo(110,75);

canvas.arc(75,75,35,0,Math.PI,false);   // Boca (sentido horário)

canvas.moveTo(65,65);

canvas.arc(60,65,5,0,Math.PI*2,true);  // Olho Esquerdo

canvas.moveTo(95,65);

canvas.arc(90,65,5,0,Math.PI*2,true);  // Olho Direito

canvas.stroke();

Também é bom lembrar que o último ponto do círculo será o final da curva, e não o centro dele.

Terminando as formas, temos as curvas quadráticas e curvas de Bézier. Elas têm um uso mais complexo (bem mais complexo), principalmente pra quem não tem experiência com design. Como também não sou um mestre do design, fico devendo um exemplo (não gosto de copiar exemplos que eu não tenha conseguido reproduzir). Temos muita coisa interessante no MDC.

• quadraticCurveTo(cp1x, cp1y, x, y)
• bezierCurveTo(cp1x, cp1y, cp2x, cp2y, x, y)

Os parâmetros x e y definem as coordenandas para o ponto de fim das curvas. cp(n)x e cp(n)y indicam as coordenadas dos pontos de controle das curvas. Esses pontos são onde controlamos a curvatura. É lógico que sem um tipo de visualização é muito mais difícil tentar algo na tentativa-e-erro. Boa sorte!

Transparência

Existem duas maneiras de implementar a transparência em nossos desenhos: através de uma definição de cor rgba ou pela propriedade globalAlpha. O valor varia de 0 (forma transparente) a 1 (forma opaca).

Um exemplo, utilizando as duas técnicas. Claro, não há efeito…

canvas.fillStyle = "rgba(255,0,0,0.5)"; // Transparência 50%

canvas.globalAlpha = 0.5;

Agora sim, um exemplo mais prático:

canvas.fillStyle = "rgba(255, 0, 0, 1)";

canvas.fillRect(0, 0, 100, 100);

canvas.fillStyle = "rgb(0, 255, 0)";

canvas.globalAlpha = 0.5;

canvas.fillRect(50, 50, 100, 100);

Gradientes

Geralmente costuma-se citar primeiro os estilos de linha para depois os gradientes. Acho que essa parte será mais interessante, e explicarei antes dos estilos de linha. Em canvas só podemos criar dois tipos de gradiente: linear e radial, e fazemos isso através dos métodos createLinearGradient e createRadialGradient. Eles podem ser atribuídos a variáveis, já que poderão ser usados várias vezes, sem a necessidade de recria-los. Eles podem ser utilizados para definir fillStyle e strokeStyle.

O método createLinearGradient leva 4 parâmetros: x1, y1, x2 e y2. Os dois primeiros definem as coordenadas do ponto inicial e os dois últimos do ponto final. Já createRadialGradient leva 6: os três primeiros definem o círculo central (x1, y1 e raio1, nessa ordem) e o círculo de fora (x2, y2 e raio2, nessa ordem). Vamos à um exemplo:

var lineargradient = canvas.createLinearGradient(0,0,150,150);

var radialgradient = canvas.createRadialGradient(75,75,0,75,75,100);

Mesmo criados e atribuídos ao preenchimento ou contorno, os gradientes vistos acima não têm efeito algum, pois não definimos as cores do gradiente. Precisamos definir “color stops”, que são pontos que definem a cor do gradiente. Fazemos isso através do método (método do objeto gradiente, e não do canvas) addColorStop, que leva os parâmetros posição e cor. A posição pode ser um valor entre 0 e 1, que é relativo ao gradiente, e a cor pode ser definida como no CSS3 (rgb, rbga, #rrggbb, “red”, “green”, “blue”…).

var radial = canvas.createRadialGradient(75,75,0,75,75,60);

radial.addColorStop(0,'red');

radial.addColorStop(0.5,'orange');

radial.addColorStop(0.9,'yellow');

radial.addColorStop(1,"rgba(255,255,255,0)");

canvas.fillStyle = radial;

canvas.beginPath();

canvas.arc(75, 75, 60, 0, Math.PI*2, true);

canvas.fill();

Estilos de Linha

Podemos modificar alguns estilos das linhas (contornos) em nosso desenho. O primeiro estilo que veremos é a espessura da linha, definida pela propriedade lineWidth, que é definida em pixels. Um exemplo utilizando linhas randonâmicas:

for(var i = 0; i < 10; i++) {

  canvas.lineWidth = Math.round(Math.random()*10);

  canvas.beginPath();

  canvas.moveTo(i * 14, 5);

  canvas.lineTo(i * 14, 140);

  canvas.stroke();

}

A propriedade lineCap define como deverão ser as extremidades das linhas. Os valores possíveis são “butt”, “round” e “square”. Com o valor “butt”, as linhas terminarão exatamente nas coordenadas que foram definidas. Com o valor “round”, será adicionada um semicírculo ao final da linha. Já “square” adiciona um retângulo com tamanho igual a metade da espessura da linha.

Temos também a propriedade lineJoin, que define como as linhas que se encontram devem ser. Pode receber os valores “mitter”, “round” e “bevel”. “mitter” faz as extremidades alongarem-se até se encontrarem em um único ponto, e esse alongamento é definido pela propriedade “mitterLimit”. “round” arredonda e “bevel” faz um corte um pouquinho arredondado.

Finalizando…

Tive como objetivo apenas fazer uma introdução ao uso de canvas e suas capacidades vetoriais. Canvas também pode criar composições com imagens, texturas, fazer animações, e até jogos. É uma ótima ferramenta, apesar de um tanto limitada quanto a compatibilidade com outros softwares (IE, no caso). Fui!

Atualização: caso você queira desenhar com JavaScript, mas sem Canvas, tente a idéia do Micox: Desenhando pontos e linhas com javascript puro (sem canvas).

Posts Relacionados

• Utilizando o Método POST em Ajax
• Documentando Scripts com ScriptDoc
• Mootools – Chain
• Mootools – Eventos
• jQuery – Segundas Impressões