Cada um destes personagens tem papéis importantes para que a evolução da web possa se tornar forte, traçando novos caminhos, cobrindo as necessidades atuais dos usuários e prevendo necessidades e soluções futuras. Há um ciclo para que estes personagens possam cumprir com seus objetivos.

O W3C cuida dos padrões. Ele tem ideias, ele prevê problemas e tenta solucioná-los. O W3C não aplica, ele apenas planeja. É um trabalho difícil, por que é necessário uma visão muito apurada do cenário da web para saber quais caminhos ela deverá tomar. Uma decisão errada, pode acarretar problemas que levarão anos para serem solucionados por completo. Vide o desenvolvimento com tabelas. Por isso esse trabalho de planejamento deve ser meticuloso. Devo confessar que em muitos casos o W3C não supera as expectativas e faz com que iniciativas paralelas surjam e direcionem a Web para um caminha mais correto. Foi o que aconteceu com o HTML5.

Os browsers, por sua vez, precisam entender e adotar as idéias do W3C, absorvendo as soluções e criando suporte nos seus softwares. Esse trabalho também tem seus perigos. Os browsers precisam pesquisar quais das necessidades dos desenvolvedores é mais importante e assim implementá-la para que a utilização de projetos seja executada. Obviamente que alguns decidem suportar aquelas soluções que darão mais pontos estratégicos contra o concorrente.

Finalizando o ciclo, os desenvolvedores aplicam tudo o W3C define, mas apenas aquilo que os browsers “querem” ou podem suportar. E isso, claro, faz com que o desenvolvedor se depare com problemas na ponta produção. Vide o IE6/7/8 e nossos problemas de cada dia.

Durante muito tempo, esse ciclo não era afinado. Havia uma certa confusão e um jogo de interesses próprios envolvendo principalmente os browsers. O W3C estava apenas pensando em como resolver problemas que talvez existiriam daqui longos anos. Os browsers estavam apenas interessados em criar uma massa de usuários suficiente para ser o primeiro no ranking. Os desenvolvedores, por sua vez, queriam ganhar seu dinheirinho, fazer o trabalho, entregar pro cliente e acabar com o problema.
Ninguém deu atenção quando começamos a desenvolver com tabelas, fazendo com que os sites ficassem mais pesados, aumentando o tempo de desenvolvimento e o custo do projeto.

Este ciclo defeituoso foi praticado durante muito tempo. Por incrível que pareça, foram os Desenvolvedores que começaram a fazer o ciclo funcionar novamente como deveria. Eles acordaram os fabricantes de browsers e também o W3C.

O W3C passou a pensar mais em problemas presentes. Solucionou problemas iminentes e que entregavam valor para os projetos.

Os browsers suportaram o mais rápido possível essas mudanças, atualizando seus engines, e fortalecendo as bases para novas soluções e flexibilizações posteriores.

Já os desenvolvedores estagnaram. Desculpe-me, serei um pouco revoltado daqui para frente. Os desenvolvedores dormiram. Quando o W3C e os browsers apresentaram soluções para problemas como transparência, bordas arredondadas, backgrounds inteligentes, utilização de fonts remotas e etc, os desenvolvedores resolveram que não era a hora dessas soluções por causa da retrocompatibilidade com browsers antigos, como o IE6. Na verdade estou sendo meio injusto aqui. Não foram todos os desenvolvedores que criaram caso com a retrocompatibilidade, foram somente os idiotas.

Nós reclamávamos que precisávamos de recursos mais inteligentes para trabalhar. Que precisávamos de idéias realmente inovadoras, que transformassem os projetos e facilitassem o desenvolvimento. Protestamos, escrevemos manifestos, postamos em nossos blogs revoltados com a falta de visão do W3C e com a pobreza do suporte dos browsers. E quando conseguimos o que queríamos, demos para trás. Amarelamos. Pedimos arrego.

Infelizmente, via-se muito disso aqui no Brasil do que no resto do mundo. Ouvi muitas desculpas como: – “Mas meu cliente usa IE6.” ou “Mas isso não funciona em IE6.” Você é desenvolvedor. Você trata com seu cliente todos os dias. Você tem o poder de educar e convencer. E se você acha que não tem poder nenhum, por que ainda trabalha com web?

Talvez isso seja trauma do passado. Talvez não. O fato é que não podemos mais nivelar por baixo. Isso é atrasar uma “evolução” inteira.

Tenho incansavelmente falado sobre Graceful Degradation, Enhanced Progressive, HTML 5, as maravilhas do CSS 3 e etc, pois esse é o assunto que rola lá fora. Há desenvolvedores e empresas, que acham que devemos ter uma autorização especial dos gringos para utilizarmos novas tecnologias e principalmente para deixar os browsers antigos no passado.

Esse assunto me faz pensar em outra pergunta: Estamos (você está?) preparados para o ritmo alucinante do W3C e dos browsers?
Até a Microsoft está cumprindo com a palavra de ter um browser atualizado. Eles já anunciaram o novíssimo Internet Explorer 10, com uma série de atualizações que promete trazer o IE para o patamar de browsers atuais.

O mercado de client-side se transformará rapidamente nos próximos anos. Muitas mudanças no HTML e no CSS serão publicadas com o intuito de tornar a web mais homogênea, flexível, portável. O HTML 5 não é só uma coleção de novas tags e APIs. O CSS 3 não ganhou só bordas arredondadas. E nem só de iPhone vive o homem. Existem milhares de Nokias, Blackberrys, Windows Phones e Androids por aí.

Os desenvolvedores precisam acordar.

Artigo originalmente publicado em Nov/2009 na revista TI Digital.

Posts Relacionados

• Introdução aos padrões de codificação
• ePub: Aprenda a criar um livro digital
• CSS1K
• Um pensamento sobre design para web
• Introdução das premissas dos controles de versão

Com a crescente popularização de tablets e leitores digitais não há dúvida de que os livros eletrônicos vieram para ficar. O formato ePub vem cada vez mais se consolidando como o padrão definitivo para eBooks. As editoras procuram profissionais especializados, mas, aqui no Brasil não existem muitos que de fato possuem o know-how necessário para desenvolver livros no padrão. Na verdade o que acontece é que as editoras estão alocando o tipo de profissional errado para a função. Um diagramador padrão, acostumado com editoração impressa via softwares visuais como Indesign vai ter problemas ao tentar lidar com linhas de código. Já um desenvolvedor front-end vai se sentir em casa já que criar e editar um livro digital é basicamente lidar com XHTML e folhas de estilo em CSS. Neste artigo vou comentar sobre as vantagens (e desvantagens) deste padrão e como com algumas poucas dicas você poderá editar um livro digital.

Por que não usar PDF?

O PDF tem muitas vantagens. Até a sua tia que te liga toda semana para perguntar de novo como faz para ler o resultado da Megasena na internet sabe como abrir um PDF. E do ponto de vista do design é ótimo. Hey, você tem muito mais controle do layout! Você pode colocar imagens e textos como quiser sem se preocupar com nada. Exceto… Você já tentou ler um PDF em um smartphone? É simplesmente agonizante. É necessário dar zoom in e out a cada frase diferente. Ou tentar ler tudo em um tamanho de letra absurdamente pequeno…

Isto acontece por que o PDF é baseado no suporte físico de uma folha, o que simplesmente não faz sentido no mundo digital. Vou explicar: um artista que pretende pintar uma nova obra de arte precisa saber o tamanho da tela. Da mesma maneira, ao editar um livro, ou qualquer outro tipo de documento para a impressão, é necessário saber o tamanho da folha para aí então fazermos toda a diagramação. O problema é que em um ambiente digital não existe uma folha. Existe um viewport (ou seja, área de visualização) que pode ser, bem, do tamanho que o usuário quiser! Se ele for ler o seu livro no browser pode aumentar e diminuir o tamanho da janela até a resolução máxima do monitor. Ou pode optar por ler em um tablet, smartphone, eReader… Enfim, a questão é que não temos como determinar a medida de altura e largura da mesma maneira que fazíamos com o papel. E o PDF, como foi pensado para ser impresso, precisa desta medida fixa.

Sobre o ePub

ePub é abreviação de Eletronic Publication, ou seja, Publicação Eletrônica. É um formato de livro aberto e gratuito criado pelo IDPF, um fórum internacional de publicação digital. Os livros deste formato são fluidos, o que permite que a experiência de leitura seja legal em qualquer tamanho da tela, sistema operacional ou dispositivo que você escolher. Desde que você tenha um app para isto, é claro. Mas isto não é muita preocupação. Existem leitores gratuitos para quase todos os aparelhos e sistemas operacionais (se você não conhece nenhum dê uma olhadinha no final do texto). Outro aspecto bacana do ePub é o controle que ele dá ao usuário. É possível realizar buscas, navegar através de links, aumentar e diminuir o tamanho da letra, trocar as fontes, a paleta de cores, etc. Sim, isto significa que se o cara quiser ler o livro inteiro em Comics Sans ele pode! Mas se isto deixar o usuário feliz quem somos nós para dizer não?

Como editar

Bem, agora que você já sabe como ler e por que usar, vamos descobrir como é um livro digital por dentro! Criei um livro de exemplo para utilizar neste tutorial. Você pode baixa-lo aqui. Mas qualquer outro livro que você tiver neste formato vai servir para o nosso experimento.

A extensão ePub é um formato de livros compactado. Faça um teste: renomeie o arquivo deste tutorial de meulivro.epub para meulivro.zip ou meulivro.rar que você poderá ver o conteúdo do pacote. No entanto, uma coisa importante de se ter em mente é que não são todos os softwares editores que estão preparados para salvar neste formato. Até dá para ler os arquivos XHTML separados, mas você teria que abrir manualmente, editar e recompactar a cada mudança de volta para ePub o que não seria nada prático. Felizmente existem alguns softwares como Sigil que são específicos para a edição de código de ePubs. Eles não tem um visual muito bonito mas cumprem com a função direitinho. Bem, vamos explorar os arquivos…

Obs. Existem outras especificações opcionais, mas vou me manter dentro do fundamental.
Obs.2 Os nomes dos arquivos são case sensitive.

A Estrutura

Vamos voltar ao nosso ePub! Ao descompactar a pasta você vai ter o seguinte:

arquivo mimetype
pasta META-INF

• container.xml

pasta OEBPS

• content.opf
• toc.ncx
• style.css
• titulo.html
• capitulo1.html
• capitulo2.html

Para que serve tudo isso e como eu crio sozinho?

Mimetype

A função do mimetype é informar ao sistema operacional qual é o tipo do arquivo. O mimetype é um simples arquivo de texto ASCII.  Para criar um mimetype basta abrir qualquer editor (ou até mesmo o bloco de notas) e escrever esta linha de código:

Salve como mimetype (sem nenhuma extensão) e pronto. Está feito! O mimetype é igual para qualquer ePub. Então copiar de um outro ePub da certo também.

Container.xml

Deve ficar dentro da pasta  META-INF. A função deste arquivo é agregar todos os outros. Bora criar um!

Content.opf

Descreve o conteúdo de todos os arquivos. Apesar da extensão esquisita é só criar um xml e depois salvar como .opf É composto das seguintes partes: metadata, manifest e spine. O esqueleto dele é assim:

Metadata

Não tem muito segredo aqui. São as informações do seu livro.

Itens obrigatórios:

• title - O título do seu livro.
• language - A Lingua utilizada. Como o livro está em português eu escolhi pt-br.
• identifier - Um código único para o seu livro. Pode ser o ISBN, por exemplo.

Itens opcionais:

• creator – O criador. No caso, você.
• contributor – Contribuidor
• publisher - Editora
• subject - Assunto
• description – Descrição do livro
• date - Data
• type - Tipo
• format – Formato
• source – Fonte
• relation – Relação
• coverage – Cobertura
• rights – O tipo de licença. Creative Commons, por exemplo.

Bem, vamos preencher nossas metadatas. Eu inseri o seguinte entre as tags package:

Manifest

É um manifesto mesmo. Deve conter (em qualquer ordem) a lista de todos os arquivos da sua publicação. Exceto mimetype, container.xml e content.opf É necessário especificar uma ID única para cada arquivo. Você pode nserir estas informações antes ou depois da metadata. O importante é que esteja também dentro da tag package. No caso do nosso livro-tutorial ficou assim:

Spine

A espinha do livro, ou seja, a ordem de leitura. Aqui você deve colocar apenas os arquivos tipo HTML na ordem que você deseja que apareça no livro, chamando cada um pelo ID que você definiu no manifesto. Tome cuidado para não duplicar nenhum arquivo ou ID. Como você já adivinhou, deve ser inserido entre as tags package também.

toc.ncx

TOC é uma sigla para Table of Contents, ou seja, o indice do livro. Também é um arquivo xml salvo com a terminação .ncx Possui a seguinte estrutura:

#head

• uid — o identificador único em content.opf
• depth — níveis do sumário >= 1
• totalPageCount — to 0
• maxPageNumber — to 0

#navMap

O sumário em si

#navPoint

• id — único do arquivo
• playOrder —ordem de navegação (iniciando em 1)

O nosso índice ficou assim então:

Os capítulos

É aqui que entra o livro em si. Cada capitulo deve ficar em um HTML separado. Estes arquivos não são nada diferentes de HTMLs comuns:

Outros tipos de arquivos:

CSS – Uma folha de estilos normal.
Pasta images – Aqui devem ficar as imagens do livro. Formatos permitidos: jpeg, png, gif e svg+xml
Pasta fonts – Utilize esta pasta se você quiser embedar algum arquivo de fonte no seu documento. Lembre-se de utilizar sempre o formato Open Type pois alguns aplicativos de leitura não suportam True Type.

E agora basta compactar!

Selecione todos os arquivos e crie um arquivo compactado (pode ser .zip ou .rar). Depois é só renomear para .epub e ler no seu dispositivo favorito. Pronto! Você tem um livro digital!

Dicas importantes para editar um ePub

Semântica é sua amiga

Bem, se você é leitor do Tableless provavelmente não preciso dizer isso, mas vou dizer mesmo assim! É muito importante utilizar uma estrutura semântica aqui. Tags h1 a h6 para títulos, p para parágrafos… O que você já está mais do que cansado de saber a esta altura. Evite usar br para quebrar a linhas por que sem ter o tamanho de um container é difícil determinar quando de fato vai ser necessário quebrar a linha.

Evite seletores complexos

Leitores digitais não são tão sofisticados quanto browsers. Mantenha o seu CSS o mais simples possível.

Use tamanhos relativos

Como as “páginas” do seu livro vão aumentar e diminuir de acordo com o tamanho da tela do dispositivo não utilize pixels como medida para nada. Lembre-se: EM para texto e margens, porcentagens para figura. Isto vai garantir que o seu livro continue proporcional e escalável. E o seu leitor feliz!

Tamanho é Documento

Não use apenas um documento XHTML para o livro todo. A recomendação é que os capítulos tenham menos de 300k cada. Mais do que isto pode deixar alguns leitores, como o iBooks por exemplo, muito lentos! A razão é que estes apps consideram cada capítulo como um bloco de texto diferente. Se você colocar tudo em um documento só o aplicativo vai carregar tudo de uma vez a cada acesso.

Outra dica é tentar usar sempre imagens otimizadas para a web e com uma resolução não maior do que 1200 x 1600px.

Não pire muito na escolha de fontes

Evite usar fontes fora do padrão websafe. Você pode embedar fontes Open Type utilizando a propriedade @font-face mas isto não significa que voce deve. Para começar não são todos os leitores que aceitam isto e no final o seu arquivo pode ficar pesado demais e travar. E muitas vezes pode ser um trabalho extra inútil já que o seu usuário pode muito facilmente trocar de fonte. Se mesmo assim você quiser usar não escolha mais do que dois ou três tipos.

Edição visual

Sim. Existem alguns softwares que podem gerar o livro para você. O Adobe InDesign faz isto, o Pages do Mac… Mas falando sério: não vale a pena. O código vai ficar sujo e no final você vai ter que corrigir vários bugs. É como se você estivesse utilizando um editor “What you see is what you get” para fazer um site. Acho que vocês entendem o drama. Mas… se você for realmente caminhar por esta estrada escura tenha algumas coisas em mente:

• Se você está acostumado com editoração nestes programas é preciso mudar alguns paradigmas. Esqueça páginas mestras, hifenização, numeração, pé de página… você não precisa se preocupar mais com estas coisas em um formato digital.
• Crie estilos específicos para o que é título, parágrafo, etc e não esqueça de importa-los na hora de salvar o arquivo.
• Cuidado ao gerar o TOC (table of contents, ou seja, o índice). Se você colocar mais de dois subniveis pode dar problemas de compatibilidade com alguns programas e o seu livro simplesmente não abrir.
• Lembre-se que todas as imagens precisam estar ancoradas para que fluam juntamente com o texto.
• Determine quebras de capítulos. No caso do InDesign, salve cada parte do livro em um arquivo diferente. Depois junte todos os arquivos em um formato “book”.

E quanto ao formato iBook da Apple?

A Apple lançou recentemente um software gratuito chamado iBooks Autor para a criação visual de livros digitais. Os livros no formato iBook são bem interativos, permitindo a implementação de elementos multimidia como videos (coisa que ainda está engatinhando no formato ePub). Com um “pequeno” porém. Sem muito alarde nos termos de serviço a Apple colocou uma clausula de exclusividade para livros comerciais. Ou seja, se você utilizar o software e vender o seu livro através da iBook Store não poderá vender em mais nenhum lugar. Sem contar que o programa é exclusivo para Mac.

Fique longe dos conversores automáticos!

Existem alguns softwares ainda que prometem converter de PDF para ePub. Fique longe deles! Sério. Eles são ainda piores que os editores visuais. Um software não consegue interpretar um livro da mesma maneira que um ser humano a menos que você diga a ele o que fazer. Se você não determinar “ei, isto é um título” ele não tem como fazer este tipo de decisão por você.

Os PDFs estão presos a um tamanho fixo, lembra? O que significa que as palavras precisam ser hifenizadas. Se você converter automaticamente (além do seu código ser a coisa menos semântica desde os sites feitos em tabelas) os hífens vão continuar lá, criando divisões no me-io das pala-vras on-de não pre-cisava! Pense nos números das páginas… se o texto flui isso significa que um mesmo livro pode (e vai) ter uma numeração diferente de acordo com o aparelho utilizado. Mas no caso da conversão automática os números no pdf vão continuar lá. Os títulos provavelmente vão estar errados também. Fora que muitos deixam marcas como “convertido pelo programa XYZ” em todas as páginas do livro.

Links úteis

• IDPF - A organização responsável pela criação do ePub. O site deles é meio confuso, mas contém bastante informação a respeito do formato.
• ePub Chech – Validação de ePub
• Epub Format Construction Guide – Um meta-livro bem completo sobre o assunto.

Bibliotecas gratuitas

• Google Books
• ePub Bud

Aplicativos para a Leitura

Mac & PC

• Adobe Digital Editions
• Nook

Linux

• FB Reader

iOS

• iBooks
• Stanza

Android

• Aldiko

Leitura no Browser

• Magic Scroll - Google Chrome
• ePub Read – Firefox

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim
• Vote no Especialista em Usabilidade para Presidente
• O que são Media Types do CSS?
• Agora é a vez dos desenvolvedores

Acabei descobrindo que este tópico ficaria enorme e, por isso, preferi escrever sobre o assunto em um artigo próprio.

Com vocês, alguns dos métodos menos populares do jQuery!

proxy()

O método proxy() permite executar um outros método forçando um determinado contexto. Seu objetivo principal é evitar a confusão do ‘this’ causada quando um objeto é utilizado dentro de um método de outro objeto.

Por exemplo:

É possível utilizar o proxy() através de duas assinaturas. A primeira recebe como parâmetros uma função e o escopo. A segunda funciona passando o escopo e o nome do método como uma string.

Quem sabe agora você para de usar o truque do ‘var that = this’, hein?

isArray() e isFunction()

Esses dois métodos fazem parte da família de utilitários do jQuery. Como seus nomes sugerem, o primeiro verifica se o objeto é um array JavaScript e o segundo se o objeto é uma função.

Uma observação: a função isArray retorna true apenas para verdadeiros Arrays (e não objetos “tipo array”, como um objeto jQuery, por exemplo).

A lista de utilitários possui outros métodos interessantes, tais como grep(), map(), merge() etc.

queue() e dequeue()

Apesar de terem sido desenvolvidos originalmente para o uso de animações, os métodos queue() e dequeue() podem ser utilizados para qualquer tipo de fila.

A fila padrão é chamada de ‘fx’: essa é a fila das animações. Ela será utilziada caso não seja passado nos parâmetros o nome de uma fila. No exemplo abaixo, estamos criando a fila ‘ajaxRequests’.

Para dar sequência no andamento da fila, você precisa utilizar o método dequeue(). Ele deve ser chamado no final da execução de um processo da fila (e como essa é uma fila de processos AJAX, utilizamos o dequeue no evento complete).

Outro recurso interessante é a possibilidade de saber o tamanho da fila, ou seja, quantos eventos ainda serão executados. Para isso, basta utilizar a propriedade length após o método queue().

detach()

Assim como o remove(), o detach() retira um elemento do DOM. No entanto, esse método guarda as referências, eventos e dados associados ao elemento retornando um objeto jQuery que pode ser re-inserido no DOM.

ajaxSetup() e afins

Talvez esses sejam os métodos mais injustiçados do jQuery. É muito comum a repetição de chamadas AJAX, incluindo seus parâmetros. Esses métodos de configuração permitem definir valores padrão para qualquer evento AJAX em sua aplicação.

Com o ajaxSetup() é possível, por exemplo, habilitar ou desabilitar o cache e definir o tipo de requisição: POST ou GET.

Você ainda pode configurar uma URL padrão e também parâmetros passados durante a chamada:

Para conferir uma lista completa das propriedades configuráveis, visite a página do método AJAX na API do jQuery.

Os callbacks e eventos relacionados à execução de métodos AJAX também podem ser configurados. No entanto, essa configuração deve ser feita através dos seguintes métodos específicos: ajaxStart(), ajaxStop(), ajaxComplete(), ajaxError(), ajaxSuccess() e ajaxSend().

Por exemplo, você poderia utilizar a configuração abaixo para exibir um indicador de carregamento no início da execução de um método AJAX.

Você pode associar os eventos a qualquer elemento e o jQuery se encarregará de encontrar e executar todos os métodos associados.

delay()

O método delay() serve para adiar a execução de uma função, método ou animação. Ele é especialmente útil para controlar o tempo de animações.

No exemplo acima, o elemento com a classe “alerta” é exibido através de uma transição fade e, um segundo depois, ocultado através do método slideUp().

replaceWith() e replaceAll()

Imagine que você queira substituir todos os elementos que tenham a classe “pontos”. Com o método replaceWith() fica fácil. O que ele faz é buscar todos os objetos que se encaixem no seletor indicado e substituir seu conteúdo.

O replaceWith() também funciona com elementos que não estejam presentes no DOM, ou seja, você pode criar um objeto jQuery e substituir/manipular seu conteúdo antes de inserí-lo no DOM.

Da mesma forma, o método replaceAll() também substiui o conteúdo de elementos, mas a origem e o destino são invertidos. Você também pode passar seletores como conteúdo. Nesse caso o funcionamento é um pouco diferente já que o elemento não é clonado e sim movido no DOM.

Note que a diferença dos métodos acima para os métodos tradiconais html() e text() é que o próprio elemento também é substituído e não só o seu conteúdo.

Estes foram alguns métodos que pouca gente conhece ou utiliza. Pode até ser que você nunca tenha sentido falta deles, mas é sempre bom ter umas cartas extras na manga.

E se você gostou, garanto que ao consultar a API do jQuery você descobrirá vários outros métodos desconhecidos, mas que podem ser úteis em algum momento do desenvolvimento dos seus projetos.

Posts Relacionados

• Introdução aos padrões de codificação
• 20 plugins jQuery que marcaram 2011
• Testando seu código jQuery com Jasmine – Parte 1
• Alternativas ao jQuery
• Entendendo os Reflows

“Codecademy was created out of the frustrations Zach and Ryan felt with learning how to program. Tired with less effective text and video resources, Ryan and Zach teamed up to create Codecademy, a better, more interactive way to learn programming by actually coding. This is just the beginning. Join us as we make it easy for everyone to love and learn how to code.”

Lá você aprende a programar, se baseando em Javascript, de uma maneira facil e assistida. Você consegue facilmente aprender nos primeiros passos como fazer variáveis, arrays e outros pequenos conceitos que precisamos entender ao programar.

Conforme você vai aprendendo, você desbloqueia badges (Como o Campus Online novo, aguarde! ;-D) e acompanha seu ritmo de aprendizado.

Muito indicado para quem quer aprender a programar ou quer ter alguma noção sobre o assunto! Visite o Codeacademy agora e comece sua jornada!

Mais comentados

• Editores
• Quer testar o Google Analytics?
• O Chrome não quer dizer muita coisa
• Não “otimize” seu código
• Desenvolvedor analfabeto (sim, é sobre WYSIWYG)

Posts Relacionados

• ePub: Aprenda a criar um livro digital
• Sobre Internet Explorer para Mobile – Breve impressão
• Agora é a vez dos desenvolvedores
• Introdução aos padrões de codificação
• Um pensamento sobre design para web

Definir padrões é normal para que a equipe inteira escreva o código da mesma maneira. Esse assunto é longo e muito importante para todas as equipes de desenvolvimento. Programadores já quiseram me matar várias vezes porque eu uso TABS em vez de ESPAÇOS em arquivos Python/PHP. Programadores gostam de espaços. Eu não. Mas não é o nosso gosto que vai definir quais os padrões de código que devemos seguir.

Quando definimos padrões e boas práticas, garantimos que todos da equipe conseguirão ter o mínimo de entendimento do código daquele projeto que está na empresa a tempos. Se alguém da equipe adoecer ou precisar ir para o Canadá, outro integrante pode assumir o seu lugar sem precisar se preocupar em aprender novas regras, porque elas devem ser as mesmas do projeto anterior.

É importante que os integrantes da equipe sejam sempre fiéis aos acordos firmados no momento em que combinam esses padrões. É importante também que, caso eles encontrem um integrante fora da lei, que eles forcem o meliante a seguir as regras. Já vi gente perdendo o trabalho de uma semana por que estava trabalhando diretamente pelo FTP e o projeto não estava no GIT. O programador simplesmente APAGOU o projeto da pessoa. Nunca mais ela resolveu editar os arquivos fora do controle de versão. Esse tipo de atitude é perigosa mas muito necessárias às vezes. Devemos forçar as regras num ambiente onde todos devem quem, quando e como as linhas de código do projeto foram escritas.

Alguns pontos para se pensar e combinar:

Identação

Como devemos identar o código? Com espaços ou tabs? Se for com espaços quantos?

Espaços em brancos (Whitespaces)

Espaços devem ser incluídos depois de uma operação condicional? Espaços devem ser colocados entre o seletor e as chaves? E no final de cada linha, precisa?

Nomenclatura

Como as classes, ids e variáveis devem ser nomeadas? E as funções? Vamos usar CamelCase?

Comentários

Como faremos com os comentários? Como serão os delimitadores do comentário? O comentário deve ser completo ou precisa ser algo mais resumido?

Arquivos

Como os arquivos, que não fazem parte da estrutura padrão do CMS, Framework e etc deverão ser chamados? E o nome das pastas? Como as páginas serão chamadas?

Chaves e ponto/vírgula

As chaves deverão ser abertas na mesma linha ou devemos quebrar linhas? Vamos sempre usar ponto/vírgula? Vamos usar o padrão K&R ou Allman?

Quando definimos estas pequenas coisas, diminuímos muitos percalços no meio do caminho. Já vi projetos atrasarem meses por que um palerma abriu e salvou arquivos com o charset diferente do que já tinha sido combinado no início.

“It’s more important for people on a team to agree to a single coding style than it is to find the perfect style.” Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications
Indico este livro sobre esse e outros assuntos sobre a construção, desenvolvimento e manutenção de websites

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão
• Boas práticas de Acessibilidade
• CSS1K

Controlar seu código fonte deve ser uma premissa. Um princípio. Se você acha que o undo do seu editor predileto salva sua vida, imagina ter um undo do seu projeto inteiro. Imagine você ter a história de edição de cada um dos arquivos do seu projeto.

Os princípios abaixo servem para qualquer tipo de controle de versão que conhecemos hoje: GIT, SVN, Mercurial etc.

Branchs e trunks

A última revisão, a mais atual, normalmente é chamada de HEAD. Existem momentos onde teremos vários HEADs porque o projeto tem vários BRANCHES.
Um branch é uma cópia do projeto. Cada branch pode ser editado e evoluído independentemente.
Imagine que exista a versão de produção que é aquela que está no ar. É a versão o usuário está utilizando. É importante que nós não modifiquemos esta versão porque alguém pode commitar algo errado, quebrar tudo e o usuario reclamar. Por isso nós precisamos de outro ambiente, é aí que criamos um branch de desenvolvimento, onde podemos fazer o que quisermos ali, sem afetar o branch principal.

É muito útil criarmos novos trunks (tronco) quando precisamos fazer modificações drásticas de novas features, resolver bugs ou modificar layout.

Exemplo: imagine que você esteja trabalhando em uma nova feature, em um branch específico. O cliente liga e diz que encontrou um bug, originado de uma modificação feita na semana passada. Você sai do branch da nova feature e cria um novo branch. Este novo branch tem a cópia do código do branch de produção, que é o que o cliente está vendo. Você resolve o bug neste novo branch. Quando resolver o bug, você move as modificações deste branch para o branch de produção. Isso tudo sem ter que subir as modificações incompletas da nova feature que você estava trabalhando anteriormente.

Versionamento

Versionamento é uma das características mais básicas do controle de código. Quando comecei a desenvolver, normalmente eu trabalhava guardando pastas com nomes do tipo nomeDoProjeto-v1, nomeDoProjeto-v2 etc… Estas pastas guardavam apenas as versões com grandes modificações de projeto… algo como mudança geral de layout, uma feature importante ou algo do tipo. O problema são as pequenas edições… Quando juntamos as pequenas modificações, temos uma grande modificação. É muito provável que se você perder essa versão, você não se lembre de todas as pequenas modificações feitas e isso é um problemão.

Toda vez que o desenvolvedor termina uma determinada tarefa, ele geral um commit que por sua vez gera um ponto de referência, uma versão, daqueles arquivos modificados. Cada commit gera uma versão do seu código. A graça é que se você tem versões do código, você tem praticamente um undo gigante do seu projeto… Se depois de uma determinada modificação seu projeto começou a dar pau, você consegue entender com a história do seu versionamento – o famoso log – a partir de onde exatamente o problema foi iniciado.

Logs

Quando cada revisão é comitada, o desenvolvedor pode ou não adicionar uma mensagem explicando o que ele fez naquela tarefa. É importante que essa mensagem seja clara e rica em detalhes, mas não um texto gigante, apenas o suficiente para que você mesmo ou outras pessoas envolvidas entenda o que aquela submissão significa.

Diffs

Diffs são sensacionais. Imagine que você queira comparar duas versões de um mesmo arquivo para descobrir as linhas modificadas. Fazer um diff entre as versões do arquivo te possibilita encontrar exatamente onde está o erro e o melhor, quando juntamos com o Log, podemos saber exatamente o porque a pessoa incluiu aquela linha ou aquele código, e o melhor, quem fez aquela alteração.

Rollback

Mantendo uma história de commits, você tem pontos de volta na história do arquivo, possibilitando a facilidade de voltarmos para antes de alguma modificação. Você pode voltar a partir de um commit, por exemplo. Se o sistema ou o arquivo passou a dar problema depois de uma determinada revisão, é simples de você voltar o arquivo para a versão daquele determinado commit.

Edição multiusuário e merge

Isso é uma maravilha. Me lembro de equipes inteiras perdendo arquivos e partes de código porque dois membros abriam o mesmo arquivo para editar. Obviamente nunca, mas nunca dava certo. O que faziam que equipes inteiras criassem mecanismos da idade das pedras para avisar o resto do pessoal que determinado arquivo estava sendo usado. O trabalho em equipe remotamente nunca era possível. Com um controle de versão isso muda. Qualquer um pode editar qualquer arquivo a qualquer hora.
O sistema de controle de versão compara as modificações feitas no arquivo pelos dois (ou mais) desenvolvedores e junta os códigos automaticamente. Muito bonito, hein?
E quando os desenvolvedores modificam a mesma linha de código? Aí o controle de versão gera um conflito, esse conflito se resolve deve ser resolvido pelo desenvolvedor que executou o segundo commit. Funciona assim:

1. Dois desenvolvedores abrem o mesmo arquivo para editar.
2. Quando os desenvolvedores terminam, eles geram um commit. Se os desenvolvedores fizeram edições em partes diferentes do arquivo, por exemplo, um no topo do arquivo e o outro no final, o sistema junta os códigos fazendo um merge, e criando um arquivo atualizado com as duas revisões.
3. Se sistema percebe que os desenvolvedores fizeram as modificações na mesma linha, o sistema gera um conflito.
4. O conflito é resolvido pelo segundo desenvolvedor que comitar o código. Ou seja, o cara comitou a modificação dele primeiro que você. Quando você comitar a sua modificação, o controle de versão avisará que há um conflito em uma parte do seu código. O conflito é resolvido mostrando algo mais ou menos assim:

A primeira linha mostra a sua linha. A segunda linha mostra a modificação do outro dev. Aquele hash maluco no final é a identificação do commit do outro dev.
Bom, nesses casos você precisa ver qual código é o correto, e isso as vezes inclui ir perguntar para o outro brother que diachos é aquela coisa que ele fez. Tudo na camaradagem… as vezes.

Concluindo

Estas são algumas premissas sobre controles de versão utilizados hoje em dia. Os controles de versão mais usados hoje são o GIT, SVN e Mercurial. Cada um deles tem comandos diferentes para lidar com as premissas acima e cada um deles faz o controle de sua forma particular. Mesmo assim todos trazem as vantagens que citamos no artigo. Mesmo que você trabalhe sozinho, é recomendado que você trabalhe com controle de versão. Assim você guarda seu projeto de forma segura e tem um histórico das suas modificações durante o tempo. Boas práticas, my friend.

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação
• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim

Bom, não é bem assim. Embora o XHTML fosse frustrante com relação à semântica e não era tão revolucionário quanto propunha, as regras mais rígidas de sintaxe foram seu maior legado. O código escrito era consistente e, se não seguisse as regras, não iria renderizar corretamente no navegador. Além disso, era compreensível para qualquer desenvolvedor. É uma questão de organização e padronização, como uma diretriz que normatiza o comportamento dos elementos para que haja qualidade e consistência.

Pense nas linguagens que você conhece, tanto de programação, quanto de marcação, estilo, etc. Por exemplo: PHP, CSS, XML, JS.  Todas possuem regras de sintaxe que, se não forem seguidas, o código não funcionará. Quem programa em PHP sabe que se esquecer um único ponto-e-vírgula, compromete a interpretação de todo o código. O JS, apesar da flexibilidade com relação a o ponto-e-vírgula no final da linha, é case sensitive, ou seja, há diferença entre o que é escrito em maiúsculas e minúsculas.

Em grande parte das linguagens existentes, há uma sintaxe a ser respeitada e esta serve para que o código seja bem formado e tenha uma estruturação lógica, definindo um sentido para a interpretação do código. Basta remetermos ao significado original de sintaxe, que herdamos da linguística:

A sintaxe é a parte da gramática que estuda a disposição das palavras na frase e das frases no discurso, incluindo a sua relação lógica, entre as múltiplas combinações possíveis para transmitir um significado completo e compreensível. [...] É o ramo que estuda os processos generativos ou combinatórios das frases das línguas naturais, tendo em vista especificar a sua estrutura interna e funcionamento.

Fonte: http://pt.wikipedia.org/wiki/Sintaxe (grifo nosso)

E no HTML5 nada impede que você use a sintaxe do XHTML, portanto, continuar mantendo as principais características de sintaxe do XHTML no HTML5 (uma prática que muitos chamam de XHTML5), para manter um formato consistente de codificação. É como realizar um merge entre as duas linguagens.

Algumas práticas recomendadas:

• Utilizar todos os elementos e atributos em minúsculas;
• Incluir tag de abertura de fechamento para as tags que possuem conteúdo (no caso de tags órfãs, como <img>, <input>, <meta>, isto não fica tão grosseiro se for escrito com a sintaxe do HTML);
• Inserir todos os valores de propriedades entre aspas duplas;

Artigos relacionados

HTML5 syntax guidelines

My preferred syntax style for HTML5 markup

Posts Relacionados

• Concorra ao livro Smashing HTML5 no Twitter!
• Declarando idiomas no HTML
• Guia de Referência de HTML5
• Command & Conquer: Tiberium Alliances
• Utilizando a Biblioteca Modernizr

Neste artigo apresento algumas dicas de como melhorar a performance de sua aplicação jQuery. No entanto, vale lembrar que não é necessário otimizar nenhum código escrito previamente, já que a otimização dificilmente compensará o trabalho.

#1: Mantenha-se atualizado

Procure utilizar sempre a última versão estável do jQuery. A cada nova versão lançada são introduzidas inúmeras melhorias de performance nos métodos do framework.

Da versão 1.3 para a 1.4, por exemplo, houve um ganho de 50% na performance da execução dos testes padrão do jQuery.

Fique ligado nas mudanças. O lançamento de uma nova versão vem sempre acompanhando de notas sobre as novas funcionalidades, um changelog, como este aqui.

#2: Não utilize jQuery!

Em alguns momentos não é necessário utilizar jQuery. Apesar de ser fácil de utilizar e muito mais bonito de ler, o framework é apenas mais uma camada no desenvolvimento, uma “maquiagem” para o Javascript.

Em projetos pequenos você pode, se quiser, abolir totalmente o jQuery: é realmente necessário incluir os ~30kb do framework? Não dá pra resolver com Javascript puro?

Já em projetos maiores, mesmo incluindo o jQuery, em alguns casos é melhor não utilizá-lo. Por exemplo:

Acima está o código-fonte do método size, do jQuery. O que ele faz? Nada além de retornar o tamanho do objeto utilizando o método nativo length. Logo, é mais rápido utilizar diretamente o length!

O mesmo vale para retornar o ID de um elemento:

O seletor $(this), aliás, somente deve ser utilizado quando for necessário um método que só existe no jQuery. Nos outros casos, sempre dê preferência ao this nativo do Javascript.

Também é comum utilizar jQuery para alterar o CSS de um elemento, por exemplo:

Olhando o código-fonte do jQuery, o método .css() possui aproximadamente 20 linhas (sem contar outros métodos chamados). A atribuição acima poderia ser executada da seguinte forma, com uma única linha:

Os próprios métodos jQuery possuem camadas dentro do framework. Ao invés de utilizar o método $.getJSON, por exemplo, você pode chamar diretamente o método $.ajax com os parâmetros type: ‘GET’ e dataType: ‘json’.

Vale a pena dar uma olhada no código-fonte do jQuery para entender o que o framework faz por baixo dos panos e até que ponto é válido utilizá-lo.

#3: Seletores

Procure sempre ser o mais específico possível em um seletor. Quanto mais específico, mais rápido. Opte sempre por utilizar o ID do elemento. Mesmo quando for preciso utilizar uma classe no seletor, utilize o ID do elemento pai.

Os seletores que utilizam o ID ou a tag de um elemento são mais rápidos por um simples motivo: ambos utilizam métodos nativos do Javascript document.getElementbyId() e document.getElementsByTagname().

Evite utilizar seletores com atributos e/ou pseudo-seletores, a menos que seja extremamente necessário.

Outra dica importante: dê preferência ao método .find() quando precisar achar elementos filhos de um elemento com ID. Por exemplo, ao invés de $(‘#container p’) utilize $(‘#container’).find(‘p’), dessa forma o escopo da busca fica limitado ao primeiro objeto. O mesmo vale para seletores de classes e pseudo-seletores.

#4: Cache de elementos

Esta é uma dica simples, mas que pode adicionar ganhos de performance consideráveis. Procure sempre armazenar em uma variável o objeto jQuery retornado por um seletor, principalmente quando o seletor está dentro de um loop.

Por exemplo:

Ao invés de:

No exemplo acima, o seletor $(‘#menu’) seria executado 3 vezes, ou seja, o elemento seria buscado no DOM três vezes seguidas, sem nenhuma alteração.

Conforme citei na abertura do artigo, cachear seletores é uma prática que vai contra o “write less, do more” do jQuery. Seu código pode ficar um pouco mais “sujo”, mas, em contrapartida, fica também mais rápido.

#5: Encadeamento de métodos

Encadear métodos sempre foi uma das funcionalidades mais legais do jQuery e, se você ainda não faz uso dessa técnica, é por aqui que você deve começar.

Vira:

Quase todos os métodos e plugins retornam (ou deveriam retornar) um objeto jQuery. Além de melhorar a leitura, essa prática também afeta diretamente a performance do seu código já que o seletor só é executado uma única vez.

#6: DOM

Qualquer tipo de manipulação no DOM envolve um processo bem lento. No geral, você deve fugir desse tipo de implementação, principalmente se ela não possuir nenhum tipo de cache.

O ideal é manipular já com os dados finais e completos. Não manipule o DOM em um loop, por exemplo.

Utilizando o exemplo da dica de caching, poderíamos alterar para ficar ainda mais otimizado:

Repare que o método .append() foi chamado apenas uma vez, já recebendo o HTML completo concatenado.

#7: DRY (Don’t Repeat Yourself)

O jQuery disponibiliza um alto nível de personalização, permitindo que você escreva seus seletores e seus plugins.

Evite repetir blocos de código. Evite repetir seletores. Evite repetir manipulações no DOM (faça tudo o que precisa fazer uma única vez!). Esta é uma dica muito importante para performance, já que qualquer código repetido significa alguns bytes ou kbytes a mais na sua aplicação.

Mathias Bynens disponibilizou um uma apresentação genial sobre DRY e Javascript, vale a pena conferir.

Como medir a performance da sua aplicação?

O site jsPerf permite a criação de testes de performance para códigos javascript, utilizando jQuery ou não. É um bom lugar para você começar a comparar diferentes tipos de implementação. Esta apresentação dá dicas e ensina a utilizar a ferramenta.

Você também pode (e deve) utilizar a aba profile do Firebug e/ou do Chrome Developer Tools. Aqui tem um tutorial antigo, mas bacana, sobre o Firebug e aqui você encontra um tutorial sobre o Chrome Developer Tools.

Posts Relacionados

• Entendendo os Reflows
• Performance do seu CSS
• jQuery: métodos desconhecidos
• 20 plugins jQuery que marcaram 2011
• Testando seu código jQuery com Jasmine – Parte 1

Os desenvolvedores do mundo inteiro juntamente com os fabricantes de browsers e outros interessados, querem ter certeza que os navegadores, robôs de busca, leitores de tela e outros sistemas detectem da forma ideal o idioma correto.

A declaração do idioma no código HTML não determina a informação no encoding de caractére do texto nem a direção de leitura do texto em outros idiomas. Essas definições precisam ser declaradas separadamente.

Nós precisamos definir o idioma por alguns motivos:

• Melhor pronunciação do texto em leitores de tela.
• Para que os buscadores possam indexar o website no buscador do respectivo idioma. Por exemplo: não tem sentido o Google ranqueear muito bem um site em português no Google americano.
• Selecionar as fonts corretas para mostrar na tela. Nesse caso para idiomas como Chinês.
• Para que os browsers escolham o dicionário correto para a correção gramatical nativa em textos e formulários.
• Renderizar a página rapidamente – o browser carrega o documento mais rápido quando o browser sabe qual o idioma nativo.

Definindo o idioma padrão do documento

Existem algumas maneiras que você pode definir o idioma padrão no documento exibido ou em partes do texto para aqueles termos em idiomas diferentes.

Podemos definir diretamente via metatag nativa:

Pela Metatag podemos definir vários valores no atributo content:

Via HTTP Header:

Via atributo lang nos elementos do HTML.

Assim indicamos, principalmente para os leitores de tela, quais termos ele deve ler com o idioma nativo do termo.

Temos o costume de indicar o atributo lang no elemento html logo no início do documento para indicar que todo o conteúdo contido dentro do html está escrito em um determinado idioma.

Ordem de herança

Os meios de acesso, normalmente browsers, seguem esses passos de verificação para identificar o idioma:

1. Verifica se elemento HTML que tem o atributo lang, se não,
2. Verifica se pai mais próximo ao termo que tenha o atributo lang, se não,
3. Verifica se o documento tem a metatag definida <meta http-equiv=”content-language” content=”pt-br”>, se não,
4. Verifica se o HTTP Header Content-Language tem uma tag de idioma definido. Se não,
5. O idioma é tratado como não reconhecido.

O W3C recomenda que você sempre utilize o lang no elemento html para definir o idioma padrão de todo o conteúdo e também em todo o termo encontrado no texto com idioma diferente do definido como padrão.

Declarações de idioma baseados nestes atributos são importantes para a maioria das aplicações web hoje, que vão desde as corretores ortográficos embutidos diretamente nos browsers até leitores de telas que interpretam as páginas web, etc etc.

Estas possibilidades são interessantes para que possamos globalizar ainda mais nossos projetos. Imagine por exemplo um website que ensina Russo para Chineses. É interessante que possamos marcar os termos dos dois idiomas de forma que os mecanismos trabalhem adequadamente em diversos meios de acesso. Os browsers precisam identificar quando o texto está em Russo ou quando está em Chinês. Os buscadores também precisam entender essa diferença, bem como os leitores de tela.

Aos poucos vamos padronizando características que antes eram ignoradas no desenvolvimento web. Não são ações muito difíceis de aplicar. Para começar, basta colocar o atributo lang no elemento html dos seus documentos e pronto.

Referências

Artigo que explica os Charsets, encodes e tabelas de caractéres no HTML.

Veja aqui a documentação oficial do W3C que fala sobre este assunto.

O W3Schools tem aqui uma listagem dos códigos de idioma que podem usados.

Posts Relacionados

• Guia de Referência de HTML5
• Ah, o maravilhoso mundo real
• Experiência deve ter começo, meio e fim
• Section: elemento article – Parte 4
• Sections: seções do HTML5 – Parte 1