Préprocessadores

Préprocessadores são ferramentas onde você escreve CSS de uma determinada forma, modificando sua sintaxe, fazendo com que na hora de sua utilização o código CSS precise ser préprocessado para que o código escrito seja transformado em código CSS puro e assim então os browsers consigam entender.

Existem muitos préprocessadores no mercado como Less, Sass, Turbine, Switch CSS e outros.

Particularmente eu não gosto de usar préprocessadores. Para começar é necessário que você aprenda a linguagem de cada um e a ideia de que seu CSS precisa ser compilado para poder funcionar não me agrada muito. O CSS é simples demais para complicarmos desse jeito. Entretanto, há uma série de coisas interessantes que podemos fazer com os préprocessadores como variáveis, funções, operações e etc que demorarão um pouco (ou não) para fazerem parte do core definitivo da linguagem. Mesmo assim, pessoalmente, para a maioria dos projetos, não vale a pena.

Frameworks

Frameworks são diferentes de préprocessadores mas são muito parecidos com Bibliotecas. Um Framework disponibiliza para o dev um conjunto de estilos e estruturas prontas para a utilização em projetos de forma escalável e uniforme. Normalmente os frameworks te dão uma coleção de componentes para que sejam usadas por todo o projeto. Esses componentes na maioria das vezes já vem com estilos visuais aplicados, bem como a estrutura. Veja por exemplo o Bootstrap ou o Blueprint.

Com o Bootstrap você consegue, rapidamente, fazer um protótipo simples ou uma estrutura básica de sistema. É o preferido dos programadores. Os elementos visuais já foram criados e desenhados. Talvez não seja uma boa ideia você utilizar um framework em um projeto cujo design já esteja aprovado. Você teria muito retrabalho para “zerar” o estilo visual de cada elemento para depois reconstruí-lo utilizando o seu design.

É muito importante que o uso de um framework CSS/Javascript seja aprovado no início de um grande projeto. Mesmo que você planeje criar um framework do zero, específico para seu projeto. O que na maioria das vezes não vale a pena.

Bibliotecas

Bibliotecas CSS geralmente não modificam o visual como os Frameworks fazem, mas eles disponibilizam uma coleção de classes, reutilizáveis e o melhor, combinatórias, para que se adeque a diversos cenários do seu projeto. Como essas classes não estão ligadas a nenhuma formatação visual, você consegue combinar sem grandes problemas com suas classes e IDs, modificando a hora que quiser a formatação visual dos elementos.

As bibliotecas são indicadas para projetos mais simples, sem grandes apetrechos técnicos, como um site ou algo parecido. Para fazer um sistema, as bibliotecas irão reforçar os Frameworks, facilitando a organização e formatação da estrutura do site. A biblioteca também ajuda na manipulação dos elementos via Javascript se baseando por estas classes prontas.

A verdade é que hoje é muito difícil diferenciar uma biblioteca de um framework.

Como todos eles trabalham juntos?

Você pode usar todos os três ao mesmo tempo em um projeto. Mas não é muito inteligente, já que se você estiver utilizando um framework, muito provavelmente ele terá uma “biblioteca” em sua base. Imagine que a biblioteca pode ser específica de estrutura ou formatação visual. O Framework, basicamente, junta os dois. Obviamente há mais coisas envolvidas. Mas para simplificarmos a explicação, imagine que um Framework é a mistura dessas duas bibliotecas.

O Preprocessador é independente do Framework e da Biblioteca. O seu ganho está ao escrever um código mais escalável, muitas vezes melhorando ou piorando a sintaxe do código. É pura sintaxe, não são classes prédefinidas. Mesmo assim você pode basear seu Framework/Biblioteca em um Préprocessador. O Bootstrap faz isso para facilitar features dinâmicas como grids, cores e etc.

Como eu disse, eu não gosto de misturar as coisas. Prefiro utilizar o Bootstrap puro, sem a interferência de nenhum préprocessador. Mas, há gosto para tudo.

Qual deles é melhor para o meu projeto

Eu não sugiro que você utilize um framework para criar websites institucionais. Websites geralmente não usam os mesmos elementos, nem as mesmas estruturas, nem o mesmo design. Logo, se você utilizasse um framework como o Bootstrap, ou o JQuery UI, você acabaria gastando mais tempo reestilizando e brigando com o CSS já criado dos frameworks do que fazendo o que realmente importa: o seu trabalho.
Logo, para projetos de pequeno porte eu sugiro que você utilize uma biblioteca simples. Sugiro ainda que essa biblioteca seja criada por você.

Não precisa de muito. Em uma biblioteca você só precisa ter algumas propriedades que fazem tarefas básicas, como fazer o elemento flutuar para a esquerda, para direita, clear, retirar margens e etc. Normalmente eu utilizo um reset chamado Normalize. Ele já reseta meu CSS inteiro e então eu me foco apenas nas propriedades que eu reutilizarei no resto do projeto.

Se seu projeto for médio ou grande, você já pode pensar em utilizar um Framework. Principalmente se seu projeto for um sistema. Você já vai ter à disposição estilos para formulários (que são um saco pra fazer), botões, grids, reset CSS e outras coisas. O trabalho fica mais fácil por que você tem menos arestas para acertar. Ainda mais se o designer aceitar utilizar alguns dos estilos já prontos do Framework, assim você não precisa reconfigurar formatações visuais e etc.

A utilização do Préprocessadores é totalmente opcional. Mas se você decidir utilizá-lo juntamente com algum Framework, procure saber se o Framework escolhido suporta algum tipo de préprocessador. O Bootstrap, por exemplo, tem uma versão para LESS.

No próximo artigo vou contar como estamos fazendo aqui na Locaweb. Estamos criando uma grande biblioteca visual e de front-end que será utilizado por todos os serviços. Os programadores conseguem subir um sistema sem precisar esperar um código HTML definitivo, utilizando os módulos dessa biblioteca. A galera de design faz todos os layouts padronizados visualmente, garantindo a uniformidade de todos os sistemas. E o pessoal de front? Bom o pessoal de front cuida para que tudo isso funcione.

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação

O pessoal da Apple fez isso com o Webkit. Eles tomaram emprestado o motor de renderização criado pelo pessoal do KDE – com o motor chamado KHTML – e fuçaram, mexeram, arrumaram, criaram e devolveram o resultado para a comunidade como um dos melhores motores de renderização que já existiu, o Webkit.

Em vez de criarem um motor novo, eles resolveram começar de uma base que já estava bem feita, pronta e organizada por uma comunidade forte. O KHTML e o KJS (motor de Javascript do KDE) permitiam o desenvolvimento mais fácil que as outras tecnologias do mercado e detalhe, tinha apenas 140.000 linhas de código! Era limpo e principalmente tinha um bom suporte com os padrões web.

A Adobe Macromedia, sem dúvida, revolucionou a web com a criação do Flash. Eu fui um dos doidos eufóricos quando eles mostraram uma linha se transformando em um circulo. Chorei sangue quando aprendi a manipular a timeline e fiz minha primeira animação. Não estou dizendo que o Flash é um lixo. Estou dizendo que o Flash fez o seu papel. Todo mundo achou que a Apple desistiria da decisão, mas não foi o que aconteceu. Eles se mantiveram firmes e isso, felizmente, agitou o mercado. Ajudou na divulgação da importância dos Padrões Web e impulsionou muito o HTML5 e o CSS3, que até então apenas o W3C e a comunidade estavam incentivando a sua utilização.

Depois da atitude da Apple de barrar o Flash de seus aparelhos, o que a Adobe faria? Quando a Adobe percebeu que seu software não teria vez, ela foi obrigada a seguir outro caminho. Graças ao grande senhor das montanhas indígenas extraterrestres, eles tomaram o caminho correto. A Adobe tem tido algumas iniciativas para ajudar os desenvolvedores a criarem websites melhores. Se não pode com eles, junte-se a eles.

Para você entender o que eu quero dizer, a Adobe criou um http://html.adobe.com para divulgar suas iniciativas para com a comunidade de desenvolvedores. As ideias expostas no site são sensacionais e eu, particularmente, quero muito que tudo se torne verdade. Separe um tempo e visite esse site. Você não vai perder nada.

Eles tem um software interessante que te ajuda a testar a responsividade do seu layout em diversos aparelhos e tem algumas sugestões de novos padrões que poderão nos ajudar demais em desenvolvimentos específicos. Leia sobre o CSS Regions e o CSS Shaders. Tem também o PhoneGap.

Parabéns para Adobe.

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• ePub: Aprenda a criar um livro digital
• Um pensamento sobre design para web
• Experiência cross-device
• Dicas de sobrevivência em uma era pós o IE6

Sabemos que o HTML5 não se trata apenas de marcação, mas também de um conjunto de novas funcionalidades encapsuladas em APIs que podem ser acessadas via JavaScript.

Porém, há APIs em processo de padronização pelo W3C que não fazem parte da especificação do HTML5. Elas são especificações relacionadas não intrínsecas ao HTML5, ou seja, a utilização delas não está estritamente atrelada ao uso da linguagem. Algumas, inclusive, faziam parte do core do HTML5, mas hoje estão dissociadas e contam com uma especificação separada, como é o caso do Web Storage.

As APIs próprias do HTML5 são mais específicas às funcionalidades que atuam no escopo da página e da manipulação de elementos. Elas se relacionam em grande parte com o DOM. Já as outras APIs geralmente trabalham com funcionalidades um pouco mais complexas, como armazenamento de dados e manipulação de arquivos, por exemplo.

Algumas das novas APIs que estão contidas na especificação do HTML5 são:

• Canvas
• Validação de formulários
• Controles de áudio e vídeo
• Application cache / offline applications
• Funcionalidade de markup editável (contenteditable)
• Drag and drop
• Novas funcionalidades para manipulação do histórico do navegador

Algumas das novas APIs que são desenvolvidas em conjunto pelo WHATWG e W3C e trabalham muito bem com HTML5 mas que não são (mais) exclusivas dele:

• Web Storage (localStorage e sessionStorage)
• Web messaging
• Microdata
• Web Workers
• Web Sockets

E algumas especificações relacionadas, que não são desenvolvidas pelo WHATWG e possuem especificações publicadas separamente pelo W3C:

• Geolocation
• File API
• Indexed DB
• File Writer
• Notifications

O gráfico abaixo, desenvolvido por Sergey Mavrody fornece uma boa visão deste contexto e do relacionamento entre as novas APIs e o HTML, além de mostrar o status de desenvolvimento de cada uma destas especificações. Note que o Web Storage ainda está incluído junto à especificação do HTML5, mas isto já mudou.

HTML5 e as APIs relacionadas por Sergey Mavrody

Portanto, muitas vezes quando falamos das novas possibilidades do HTML5, na verdade estamos nos referindo à toda uma nova geração de tecnologias para a web.

O que podemos concluir disso tudo é que o HTML5, sozinho, não faz uma web melhor. Porém, ele ajudou a movimentar o mercado rumo ao desenvolvimento de novas tecnologias. Saímos da zona de conforto que já estávamos há alguns anos. O cenário que temos agora é de uma série de tecnologias web que, trabalhando em conjunto, fazem uma web melhor, para as pessoas e para os desenvolvedores

Referências:

Especificação do HTML pelo WHATWG
W3C – HTML5 differences from HTML4
HTML5 – Wikipedia

Posts Relacionados

• Porque é a web que comanda
• Sections: elemento article – Parte 4
• Sections: elemento aside – Parte 3
• Apostila sobre HTML5
• Google Apps não suportará mais IE6

Por isso, aqui vão algumas dicas de propriedades que você já deve conhecer, mas que não usa ainda por que acha que todos os IEs são iguais ao maldito IE6.

:after

Você deve usar alguma técnica de clearfix que você criou ou que você pegou de algum lugar. Eu usava muito jquery para criar um elemento vazio dinamicamente no final do elemento que necessita do clearfix para fazê-lo parar de sofrer influência dos floats dos elementos. Essa técnica aqui pode salvar sua vida:

O content pode ser usado para uma série de outras coisas, como por exemplo inserir um ícone, objeto ou até texto depois de um determinado elemento.

Nesse caso o IE7 fica de fora.

first-child

Sim. O First-child funciona no IE7 ou superior. Mas o last-child não. Sem chance.
Isso já acaba com aqueles problemas de alinhamento de elementos em linha, onde você precisa tirar a margin, padding ou border do último (ou o primeiro) elemento para que eles fiquem alinhados corretamente.

Seletores complexos

Olha só que maravilha, o IE7+ já suporta alguns seletores complexos como os descritos abaixo:

Todos eles funcionam no IE7 ou superior. Só com estes seletores já economizamos uma penca de código Javascript.

:first-letter e :first-line

Formatar a primeira letra do parágrafo ou a primeira linha. Coisa linda.

word-wrap

Essa propriedade é utilíssima. Você já deve ter escrito uma palavra muito grande ou uma URL, que geralmente não tem espaços, o que ocasionou da string ultrapassar a largura do objeto. A propriedade word-wrap faz com que essas strings muito grandes quebrem de linha assim que atingirem o limite do objeto.

Essa propriedade funciona desde o IE5. O.o

max-height/width e min-height/width

Essas aqui são essências para produzirmos layouts fluidos e responsivos. Funcionam a partir do IE7.

Tabela de referência

O MSDN guarda uma tabela de compatibilidade muito completa com propriedades do CSS que os IEs suportam ou não. Vale a pena dar uma olhada e entender melhor o que você já pode usar nativamente do CSS em vez de sair escrevendo loucamente soluções JQuery.

Posts Relacionados

• Ferramentas de diagnóstico
• Desenvolvendo para IE6
• Ah, o maravilhoso mundo real
• IE8 – O sonho não acabou
• Sobre Internet Explorer para Mobile – Breve impressão

Este ano eu estou trabalhando a maior parte do tempo em um monitor fullHD. Notei uma diferença gritante ao digitar código pela primeira vez em um monitor desses. E não são apenas os monitores que estão mudando para uma resolução decente. Também, seguindo o ciclo natural, dispositivos menores estão recebendo a dádiva de ter a alta resolução em suas telas. E isso, meu caro, é uma dádiva para o usuário, para você é mais trabalho.

Pixels não são mais como eram antigamente

Na minha época de escola – nem tanto tempo assim – os professores me ensinaram que o átomo era indivisível. Era incrível por que eu, como criança, me divertia tentando entender como algo poderia ser tão pequeno que não pudesse ser partido ao meio, ficando menor… Mas aí eu descobri que os prótons, os elentrons e outras partículas subatomicas existiam também…

A mesma coisa aconteceu com o pixel. O pixel sempre representou a menor unidade da sua tela. Para os designers, o pixel é a unidade central. É onde tudo se baseia: medidas, tamanhos, alinhamentos etc… Mas o pixel não é mais como era antigamente.

Com o advento das telas HD em aparelhos móveis, o conceito de pixel mudou um pouco muito. Quando a tela retina display do iPhone 4 foi lançada o queixo de todo mundo caiu. A Apple conseguiu apertar quatro pixels onde apenas caberia um. Logo o pixel pode ser definido como a menor unidade na tela, como você já conhece ou pode ser baseada em uma unidade chamada hoje em dia de “pixel referência” ou do inglês reference pixel: que significa que esse novo “pixel” é uma referência ótica de unidade.

Para entrar em detalhes, leia o que é um pixel. Vai te ajudar a entender melhor.

Densidade de pixels

A sigla DPI significa Dots Per Inch, ou seja, é o número de pixels que seu dispositivo pode conter em uma polegada. Quanto mais pixels em uma polegada, mais nítida a imagem é.

Os aparelhos como o iPhone 4 e outros que carregam Android tem uma densidade de pixels muito alta. Ou seja, eles conseguem comprimir um grande número de pixels em suas telas, tornando as imagens melhores. O problema é que as imagens que criamos hoje podem parecer ruins nesses dispositivos. Algo parecido como aumentar uma imagem pequena no Photoshop, entende? Ela fica toda pixelada, sem qualidade nenhuma. Isso por que você está aumentando o tamanho de uma imagem que é pequena e não tem pixels suficientes para dividir pelo tamanho que você definiu.

Entenda fazendo um teste: Vá até o site da Apple utilizando SAFARI. Agora, dê um zoom em alguma imagem. Veja como ela parece pixelada por causa do zoom. Agora abra o Inspector do seu navegador, vá até o console e coloque as duas linhas abaixo:

A imagem foi trocada para uma imagem com o dobro de tamanho da imagem original para que ela ficasse melhor em telas com alta densidade de pixels… Veja a diferença. Eu vi esse truque aqui.

Ações para otimizar

Existem algumas atitudes que vocês já pode tomar agora para poder chavear estes aparelhos e entregar uma experiência melhor para seus usuários.

Utilize media queries

Media Queries são um chuchuzinho. Você pode utilizar uma regra chamada device-pixel-ratio para detectar qual CSS servir dependendo do pixel-ratio do dispositivo. Não precisa ser maníaco e servir vários CSS para vários pixel-ratios… Você vai ficar doido se fizer isso.

Abaixo veja uma tabela de exemplos de aparelhos com seus valores de pixel-ratios:

Agora, como seria o CSS:

Eu sugiro que você se limite apenas para o pixel-ratio 2. Do jeito que as coisas estão andando, os aparelhos de pixel-ratio menor do que 2 desaparecerão logo e os aparelhos com pixel-ratio igual a 1 são maioria e você já faz versões para eles, já que não precisam de fallbacks.

Considere chavear versões de imagens

Este é um problema que ainda não existe uma solução inteligente e definitiva.
A ideia é tentar evitar que o usuário baixe duas imagens iguais, mas de tamanhos diferentes para cada tipo de necessidade. Logo, existem vários fallbacks, em Javascript ou linguagens server-side para servir apenas a imagem necessária.

O pessoal da Clound Four escreveu um artigo muito interessante sobre isso.

Há outros artigos bons por aí. Eu estou dando uma lida em vários para tentar escrever um artigo mais simples aqui no Tableless. Mas o assunto é muito vasto e ninguém tem uma opinião definida ainda. Isso não é útil apenas para a situação dos aparelhos hires, mas também para encontrarmos maneiras de servir imagens menores para versões de sites mobiles.

Text rendering

Você consegue melhorar muito a leitura dos usuários utilizando a propriedade text-rendering.

Esta propriedade melhora muito a leitura quando o usuário dá o zoom nos aparelhos móveis e também corrige suporte de ligaduras e kerning. Coisa linda.

Text Smoothing

A propriedade font-smoothing é útil agora! A leitura melhora demais em monitores normais e previne serrilhamentos ocasionais quando utilizandos @font-face.

Tente usar CSS3

Tente usar e abusar dos efeitos do CSS como sombras, gradientes, bordas arredondadas e etc. Além de facilitarem sua vida evitando a criação de imagens desnecessárias, elas ajudam na velocidade de carregamento do site.

Considere utilizar SVG

Já tem alguns que estão começando a utilizar SVG para facilitar a vida. Para ícones, SVG é ótimo. Você consegue reutilizá-los em diversos tamanhos, aumentando o diminuindo de acordo com a sua necessidade e também do aparelho. Veja um exemplo que a Smashing Magazine escreveu.

Novo elemento HTML

O W3C já criou um grupo chamado Responsive Images Community Group para a criação de elementos do HTML que facilitam a entrega de assets dependendo do contexto. Eles estão propondo um novo elemento que identifica as dimensões do dispositivo, velocidade de rede, densidade de pixels e outros pontos para servir melhor imagens e outros assets dependendo do contexto.

Muitos artigos para ler

• How to make your web content look stunning on the iPhone 4′s new Retina Display
• Retina Display and CSS Background Images
• Designing for the Retina Display (326ppi)
• How to use hi-res images in web apps for iPhone4
• Targeting High Screen Densities with CSS Media Queries
• A Pixel Identity Crisis
• optimizing web experiences for high resolution screens

Posts Relacionados

• ePub: Aprenda a criar um livro digital
• Boas práticas de Acessibilidade
• Experiência deve ter começo, meio e fim
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Adobe e os Padrões Web

O GoMo faz um teste rápido no seu site e mostra um screenshot de como seu site aparece em aparelhos móveis, aparentemente somente em aparelhos que rodam Android. Lembrando que muito provavelmente seu site aparecerá da mesma forma em dispositivos da Apple, que rodam WebKit, mesmo motor de renderização do browser do Android.

Ao final do teste ele entrega o resultando indicando 4 pontos principais: velocidade, imagens quebradas, legibilidade de textos e navegação. Muito interessante para quem quer pelo menos ter um teste superficial de como seu site se comporta nestes dispositivos.

Visite o GoMo.

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Qualidade de Imagens e densidade de pixels

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

• GoMo – Teste seu site mobile
• Introdução aos padrões de codificação
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Seu lugar ao sol
• ePub: Aprenda a criar um livro digital

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

• Qualidade de Imagens e densidade de pixels
• GoMo – Teste seu site mobile
• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim
• Vote no Especialista em Usabilidade para Presidente

Empresário? Empreendedor? WTF?

Nos últimos três meses a minha vida profissional mudou da água para o vinho.
Eu era sócio de uma pequena empresa de web, com uma visão de desenvolvimento web diferente das demais “agencias”. Tirando o primeiro registro da minha carteira que marca uma passagem de 6 meses em uma agência de design, como assistente de Web Designer, eu nunca trabalhei como empregado. Fiquei durante 5 anos da minha vida ajudando dois amigos a erguer uma outra empresa de internet, com ideais também inovadores e uma vontade enorme de mudar a forma com que o desenvolvimento web era feito. Um desses amigos acabou se tornando meu sócio em uma segunda empresa e a partir daí foram 6 anos, erguendo uma empresa e construindo uma comunidade em volta.
Até 2 semanas atrás eu não sabia o que era receber salário, mas sabia o que era pagar vários salários. Eu não tinha que marcar ponto, eu tinha que controlar o ponto. Erguer uma empresa dá trabalho, mas é bom. Você não precisa ter faculdade para isso. Você precisa apenas ter coragem.

Aí você descobre que ter coragem é a parte fácil. O difícil é você pagar imposto, salário, gerenciar expectativas de clientes, se preocupar com a vida dos seus funcionários, entender como a carreira deles pode melhorar, saber movimentar a empresa para o lugar correto no mercado e além de tudo isso não tirar os olhos do fluxo de caixa. É aí que você aprende a diferença entre ser empreendedor e ser empresário. Eu achava isso o máximo. O seu ego vai lá pra cima. É gostoso responder quando alguém te pergunta o que você faz ou no que você trabalha. A resposta vem pronta e ensaiada: “Sou empresário. Tenho uma empresa de desenvolvimento de Internet. Atendo clientes como XKPPYZ, XPTO e etc…” Coisa linda, sabe?

Algo de estranho acontece

Mas teve um dia que algo mudou. O problema é que quando você tem uma empresa e tem contas a pagar, é difícil perceber quando “algo” muda. Esse “algo” pode ser o movimento do mercado ou pior, pode ser você mesmo – como aconteceu comigo. Ninguém vai avisar quando essa mundaça acontecer… O segredo é quanto tempo você demora para descobrir.

Esse “tic” me aconteceu em um momento nada oportuno. Mesmo assim fui em frente. Sempre, sempre, sempre com uma dúvida atrás da orelha para atrapalhar. Mas nesse caso, meu caro, minha dica é siga em frente. Minha decisão já estava tomada. Saí da empresa. Foi algo realmente duro. É difícil você tomar a decisão de deixar para trás algo que você construiu, do nada. Do nada mesmo. Nós NUNCA recebemos nenhum aporte financeiro de NENHUMA empresa. Pelo contrário, tivemos que nos virar, pedir alguns mangalotes na fábrica de dinheiro em momentos difíceis e caminhar com mais uma parcela no bolso. Ah, quem dera ter recebido um aporte financeiro. Mas não. Eu tinha uma empresa que faturava pouco mais de 1 milhão/ano sem a ajuda de ninguém. Isso sim é algo para se orgulhar. Não é coisa de moleque. Mas é óbvio que um aporte financeiro não mata ninguém, né?

Falou demais, cara. Onde quer chegar?

Eu sei que falei demais e provavelmente você ainda não sacou onde eu quero chegar. Aí está o “x” da questão. Onde você quer chegar? Eu não tenho faculdade e nunca fui empregado. Decidi sair da minha empresa para aprender algo novo, realmente. Obviamente havia outros motivos mais específicos e menos “romanceados” como este. Decidi pagar para ver e aprender algo que eu nunca tive. Sabe quando você se alista pra virar soldado e descobre que outro cara também se alistou só que ele fez aquele cursinho e virou sargento direto? Pois é. Eu tinha feito o cursinho de empresário/empreendedor, nunca fui soldado. Como o cara pode se sargento se nunca foi soldado? Por causa disso eu cometi muitos erros. Eu também deixei que outros cometessem erros. O que é muito ruim também já que o erro dos outros, na sua empresa, afeta você diretamente.

Aí você fala: “Espera, você deixou de ser empresário, onde você poderia ficar rico e ganhar dinheiro, pra ser empregado?” Eu respondo: Você está com o mesmo pensamento que eu estava nas primeiras semanas do meu “primeiro” emprego depois de sair da minha principal empresa (sim, eu tenho mais duas). Eu quase pirei nas primeiras semanas. Essa é uma outra história. — Em duas semanas aprendi mais coisas do que em muitos anos da minha vida. Posso falar mais aqui depois, se estiverem interessados. — Mas se você acha que só pode ser rico sendo empresário, nem abra uma empresa. Dinheiro é consequencia, sendo empresário, empreendedor ou empregado. E sim, eu sei que lá no fundo é o dinheiro que importa. Mas ele não vem só porque você decidiu abrir uma empresa. Ele vem porque você é bom no que faz. Você tem que pensar sobre dinheiro de forma estratégica e não como objetivo final. Isso em qualquer área e em qualquer cenário que você se encontra. Decidir abrir ou não uma empresa é também uma decisão estratégica, mas da sua vida. E no final, tudo se resume ao seu comportamento diante de decisões simples na frente da batalha.

A ideia é que você deve seguir seu instinto. Se você for empresário, não seja demasiadamente estúpido e dizer que NUNCA mais trabalhará como empregado na vida. E se você é empregado, meu caro, não diga que abrir empresa é algo difícil. Você pode estar com medo.

Talvez eu nem saiba o que eu esteja dizendo agora. Mas eu já estive dos dois lados da fronteira. Hoje eu sou empregado em uma das maiores empresas de hospedagem do Brasil, tenho uma startup e cuido de um portal. Sou empresário ou empregado? Quem tem que definir é você.
Ter uma empresa ou ser empregado é uma decisão sua e para ambas decisões é necessário ter coragem. Existem vantagens e desvantagens dos dois lados. Como eu disse anteriormente, ganhar dinheiro é possível em qualquer um dos dois cenários, então esse não é o problema. Os passos em cada um dos caminhos são diferentes em diversos pontos, mas se você reparar bem, são mais parecidos do que aparentam.

Posts Relacionados

• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Adobe e os Padrões Web
• Dicas de sobrevivência em uma era pós o IE6
• Qualidade de Imagens e densidade de pixels
• GoMo – Teste seu site mobile

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

• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão