Tenho um grande amigo que sonhava ser piloto de avião. Por trabalhar em uma empresa aérea, a proximidade com as grandes máquinas voadoras o encantava. Porém, seu sonho de pilotar acabou quando, aos trinta anos de idade, ele descobriu que tinha um grau de daltonismo que o impediu de continuar o treinamento.

O mais curioso dessa história foi que ele viveu seus trinta anos anteriores sem saber que enxergava cores de forma diferente das demais pessoas. Seu tipo de daltonismo foi classificado como deuteranopia, que dificultava reconhecer certos tons de verde. A partir dessa descoberta, comecei a estudar como cada pessoa vê as cores da sua web.

Por esse motivo, os cuidados com cores são importantíssimos no desenvolvimento de páginas web. O WCAG 2.0 (Web Content Accessibility Guidelines) é bem direto com relação a isso: A cor não deve ser utilizada como o único meio visual de transmitir informações. Isso significa que você não deve utilizar indicações como “clique no botão verde para continuar” ou, “campos marcados em vermelho são obrigatórios”.

Mas isso não significa que o uso de cores deve ser banido da web. Pelo contrário. O uso de cores e contrastes é um dos maiores atrativos visuais de uma página. O que faz uma página ser bela aos olhos de um usuário é a combinação entre tons e cores. Mas o cuidado com o contraste deve ser considerado, já que pessoas com certos graus de daltonísmo e baixa visão podem ter dificuldade de enxergar alguns contrastes. Por isso mesmo, o E-Mag, modelo de acessibilidade do Governo Eletrônico diz que o mínimo de contraste entre o plano de fundo e o primeiro plano deve ser de 3 para 1. Se você tem dúvidas, na última página do E-Mag existe uma tabela de cores que faz o contraste adequado com preto e branco (já em hexadecimal). No WCAG 2.0, esse valor é de 4,5 para 1.

E quando o daltonismo é tão severo ao ponto de fazer com que a pessoa não enxergue cor nenhuma (somente tons de cinza)? Esse é um tipo de daltonismo raro, mas aconteceu com o artista Neil Harbisson, que esteve na quinta edição da Campus Party Brasil contando como conseguiu resolver seu problema de distinguir cores: implantando uma câmera em seu crânio que identifica as cores e transforma essa informação em áudio. Uma ótima palestra que vale a pena ser assistida.

E por falar em bani-las da web, o que podemos dizer da implementação de cores quando o acesso a página é feito por um software leitor de tela? A primeira recomendação dada pelo WCAG é separar a estrutura do documento da apresentação, ou seja: Formatação visual somente dentro do CSS. Isso quer dizer que o software leitor de tela, que navega pelo código da página HTML, ignora as cores aplicadas no documento? Não!

O software JAWS, popular software leitor de tela, possui uma configuração que permite que o usuário saiba quais as cores ou fontes utilizadas na página, ou mesmo simples combinações de tecla podem permitir que o usuário cego saiba que fonte está sendo usada no site e qual a cor dela.

Isso significa que a minha web tem cor, inclusive para uma pessoa cega que acessa minha página.

Além de todas as diretrizes citadas nesse documento o uso do bom senso é fundamental para termos uma web bela, cheia de cores e que permitam que todos possam navegar por ela. Inclusive aquele meu amigo do início desse texto, que um dia me pediu ajuda para instalar sua televisão nova e não enxergava um tal botão verde no controle remoto que fazia a busca por canais. Felizmente, o termo “pesquisar canais” estava escrito no controle.

Talvez eu não enxergue as cores da mesma forma que você, mas mesmo com essas diferenças a minha web é tão bela quanto a sua deve ser.

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• Responsive Web Design – focando a coisa certa
• Seu lugar ao sol
• ePub: Aprenda a criar um livro digital
• Boas práticas de Acessibilidade

2003

2004

2005

2006

É humilde, mas é nosso!

Posts Relacionados

• Estruturação de Client-side – Parte 2: Designers e Programadores
• Adobe: The Expressive Web
• Drops 9 – Préprocessadores, frameworks e bibliotecas
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Adobe e os Padrões Web

Para participar, é preciso seguir o @tableless e a @BookmanEditora no twitter. O sorteio será realizado no dia 20, às 10h, por meio do site sorteie.me. Um sortudo vai ganhar um exemplar do livro Smashing HTML5, de Bill Sanders. O ganhador será avisado pela rede social e deverá enviar seus dados via Direct Message para a @BookmanEditora em até 72 horas.

Não esqueça:

• Siga @tableless e a @BookmanEditora no Twitter
• Dê RT na mensagem “O @tableless vai me dar o livro Smashing HTLM5, da @BookmanEditora! http://kingo.to/XyZ. Para concorrer, a mensagem deve ter o link da promoção!
• Aguarde o sorteio no dia 20 e boa sorte!

Conheça mais sobre o livro:
Smashing HTML5, de Bill Sanders
Fiel à missão do Smashing Magazine (smashingmagazine.com), um dos sites de Web design mais populares do mundo, este é um guia prático para a construção de sites modernos e atraentes que aproveitam todas as vantagens dos recursos oferecidos por HTML5. Com Smashing HTML5, você tem tudo o que precisa para fazer a transição para a nova versão da linguagem e começar a trabalhar rapidamente.

Desconto especial para leitores Tableless: Quem é leitor do tableless têm 20% de desconto para adquirir o livro Smashing HTML5 no site da Bookman! Basta acessar este link e digitar o código tableless no carrinho de compras. A promoção é válida até dia 16/02/2012.

Posts Relacionados

• Adobe: The Expressive Web
• Cut the Rope
• Declarando idiomas no HTML
• Guia de Referência de HTML5
• Documentos poliglotas com XHTML5

Eu criei o Tableless a mais ou menos uns 8 anos. Ele começou como um simples blog no saudoso cjb.net. Depois eu migrei para o .kit.net. Então ganhei o domínio .com.br na época em que trabalhava na Atípico. E a partir daí tudo mudou. A minha ideia inicial era compartilhar meus estudos e mostrar para outros profissionais o que eu estava aprendendo. O que eu não sabia era que uma comunidade cresceria em volta e que juntos mudaríamos a forma com que fazíamos web no Brasil.

Durante muito tempo eu mantive este site sozinho. Não porque ninguém queria ajudar, pelo contrário, porque eu não queria que ninguém encostasse no “meu bebê”. Nunca foi fácil para mim deixar algo que construí nas mãos de outras pessoas. Mas eu percebi que o site não ia muito longe se eu continuasse centralizando todas as tarefas. Foi aí que eu decidi aceitar a ajuda de pessoas mais capazes que  eu. Então o Alysson, a Talita, a Thaiana, o Davi, o Paulo e posteriormente o Keppelen e o Moacyr apareceram para salvar a pátria. Gente fera, com opiniões fortes e que representa muito bem o nome deste site quando estão por aí falando sobre Padrões.
Mas ainda existia o nosso Twitter que estava precisando de atenção. Decidi então, depois de muito pensar, abrir para mais 2 pessoas me ajudarem a levar links interessantes para a comunidade, para isso contei com a agilidade do Luiz e do Henrique, que twitam links que eu nunca teria encontrado.
E claro, não podia esquecer do Gui, Felquis, Riccardo e Deivid que estão lá, cuidando do nosso fórum, fazendo com que as dúvidas de diversos desenvolvedores sejam respondidas.

Depois que tomei estas decisões o site cresceu demais. Não tenho nem como agradecer a não ser aqui, em público: muito, muito obrigado galera. Eu seria um nada sem vocês. Segurar tudo isso aqui é muito mais fácil quando há pessoas inteligentes e dispostas como vocês. Aposto que não é somente eu que agradeço, mas toda a comunidade que envolve este site. Obrigado e meus parabéns.

Outro ponto que eu deveria resolver era sobre a colocação de publicidade no site. Eu nunca gostei de fazer isso e muitos leitores reclamavam. O problema é que um site gera despesas. Estas despesas vão desde o tempo gasto até o servidor… Quem paga por isso?
Resolvi então inserir alguns blocos de banners para gerar alguma renda. Estamos terminando agora o livro do Tableless. Paguei a editoração básica do livro com o dinheiro gerado com propaganda no Twitter feito via seeding da Boo-box.

A partir de agora, quero profissionalizar cada vez mais o site, de forma que consigamos chegar mais longe. O ano de 2012 vai ser diferente. Graças a você, desenvolvedor sedento por informação de qualidade e com vontade de mudar ao seu redor, estamos nos mobilizando para fazermos cada vez melhor. Obrigado por estar conosco o tempo inteiro e obrigado por nos fazer crescer. Por nos mostrar onde erramos e principalmente quando acertamos. Não posso deixar de cobrá-lo: divulgue nosso site. Não porque eu quero que as vistas aumentem, mas porque eu sei que tem um monte de desenvolvedores por aí que precisam ouvir sobre boas práticas de client-side. Essa evangelização só pode ser bem feita por você.

O ano que vem vai ser grande. O ano que vem vai ser de tirar o folêgo, de novo.

If not now, when? If not you, who? Web Standards Project

Posts Relacionados

• Estruturação de Client-side – Parte 2: Designers e Programadores
• Adobe: The Expressive Web
• Drops 9 – Préprocessadores, frameworks e bibliotecas
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Adobe e os Padrões Web

Eu criei a Visie com o Elcio porque queríamos mudar a forma com que a Web brasileira era feita. Eu criei o Tableless por este mesmo motivo. Quando todo mundo não estava botando fé na ideia de um blog sobre padrões web, eu arrisquei e criei sozinho. A Visie surgiu com o mesmo pensamento. Nós não sabíamos que a Visie seria a empresa que ela é hoje. Não sabíamos a imagem que formaríamos perante a comunidade e os clientes, mas moldamos uma empresa firme nos princípios e com uma missão clara.

Nesse tempo, além de aprender a dirigir uma empresa, eu geri projetos incríveis e trabalhei com pessoas excepcionais (nos dois sentidos ). Treinei equipes inteiras de empresas gigantes. Tive uma série de problemas também. Não pense que era uma maravilha 100% do tempo, porque não era. Toda empresa tem problemas, de diversos tipos, e é debaixo de porradas que você aprende mais.

Decidi seguir conhecer novos ares e aumentando minha bagagem de conhecimento e experiência. Quero trabalhar em empresas inovadoras, que enxergam a web de forma singular. Se você conhece uma empresa assim, que está precisando de alguém como eu, me avise!

Mais sobre mim, visite meu LinkedIn.

–

Perguntas que fizeram para mim e que respondo agora:
1. O Tableless não vai terminar. Eu fundei o Tableless e ele é meu xodó. Mas a partir de agora vou começar um processo de “profissionalização” do blog. Está comigo agora toda a responsabilidade sobre Treinamentos e aulas particulares que antes era da Visie. Eles serão oferecidos pelo nome do Tableless, tanto treinamento e consultoria para empresas quanto as aulas particulares.

2. E agora o que você vai fazer? Vou buscar oportunidades em empresas que inovam na web. Gerente de produto, projeto, liderança de equipes, me interessam. Não sei se valerá a pena me contratar para ser um coder html/css/javascript, mas podemos conversar.

3. Quero te contratar, como falo contigo? Fácil: diego[at]tableless.com.br, twitter.com/diegoeis, about.me/diegoeis.

Mais comentados

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

Entender realmente como um navegador funciona é importante, e garante seu entendimento do real dos problemas que está enfrentando no código que está implementando. Tem mais! Criar um código que manipula o layout (leia-se DOM) fica mais fácil, é uma relação win-win.

Criado pelo W3C, O DOM é uma multi-plataforma que representa como as marcações em HTML, XHTML e XML são organizadas e lidas pelo navegador que você usa. Uma vez indexadas, estas marcações se transformam em elementos de uma árvore que você pode manipular via API – que é o que fazemos quando usamos programas ou scripts para alterar funcionalidades de uma página: conteudo, estrutura ou folha de estilo.

Um pouco de história

Não tem graça falar sobre o assunto sem mostrar como ele surgiu. Isso só reforça ainda mais a importância de conhecermos bem o assunto pois mostra sua relevância (e porque falar de browser wars é bem legal, apesar de evidenciar os cabelos brancos).

Netscape e Microsoft guerreavam com Netscape 2 e IE3.0 lá em 1996 e enquanto a Netscape lançava o Javascript a Microsoft lançava o JScript. A diferença entre um e outro não é nada mais além do nome – acredite! Por razões comerciais devido as “sangrentas” browser wars as empresas decidiram adotar nomes diferentes para a mesma coisa – que na verdade era (e continua sendo) o ECMAScript, a linguagem que comecou a ser criada em 1994 quando o W3C colocou na mesma mesa as duas empresas e várias outras para desenvolver um padrão para linguagens de script para os navegadores. Javascript, JScript e ActionScript não são nada mais que dialetos de ECMAScript.

O DOM em sua forma e como é reconhecido pelos navegadores

Representação de um documento HTML e sua árvore DOM

A figura acima mostra a estrutura de uma árvore DOM, a linearização  das marcações de modo que ela possa ser montada inicialmente por um navegador. Esta estrutura não será o que veremos no navegador – o layout em si. O DOM é a base para uma outra árvore que é o que realmente um browser monta na tela, a Árvore de Renderização - aka Render Tree.

A base para todos os nós da árvore DOM é o base class chamado Node.h. Ele possui várias categorias, e as relevantes para renderizarmos código no navegador são os nós de documentos, elementos e texto.

1. Documentos é o nó mais importante do DOM, com três classes diferentes: Document, que é usado por todos os documentos XML e outros que não sejam SVG (que também é um XML, porém com marcação já padronizada), HTMLDocument que como o nome diz, cuida de documentos HTML e SVGDocument, responsável pelos documentos SVG e tambem por outros documentos herdados da classe Document (Como o Document.h e o HTMLDocument.h).
2. Elementos são todas as tags que estão em arquivos HTML ou XML se transformam em elementos da árvore DOM. Considerando a renderização do navegador, um elemento é um nó com uma tag que pode ser usada para fazer subclasses específicas que podem ser processadas de acordo com as necessidades da Render Tree (Element.h).
3. Texto: É o texto que vai entre os elementos. Todo o conteúdo das tags (<p>Isto é um text node</p>). O nó de Texto guarda basicamente texto puro, que pode ser renderizado ou trabalhado via script.

A Render Tree

Como a render tree é montada

A Render Tree é a parte mais importante do processo de renderização. Bem parecida com a árvore DOM, cada objeto corresponde a nós de Documentos, Elementos ou Texto. A diferença é que q Render Tree possui tambem objetos que não possuem nós na árvore DOM, como scripts e folhas de estilos.

O processo de criação da Render Tree passa pelos seguintes passos:

1. Attachment: Após finalizar o parse do DOM e a criação de seus nós, os navegadores chamam um método chamado attach para começar a renderização. O attach adiciona primeiramente as folhas de estilo a árvore DOM e começa a estilização da página. Um bom exemplo é o uso das propriedades CSS display x visibility: Caso um elemento da árvore DOM tenha uma propriedade display:none, este elemento (e seus nós filhos) não será criado na Render Tree. Ao contrário do uso de visibility:hidden, que vai renderizar o elemento na árvore, porém  ele irá remover (ou adicionar quando visibility:visible) via Repaint as cores (ou propriedades) que formam este elemento. Vale lembrar também que este processo de attach é top down, criando sempre inicialmente os nós parent e depois seus descendentes (nós filhos). (Para saber mais sobre Repaint e Reflows, veja este outro artigo)
2. RenderStyle.h: Durante o processo de attach um método é criado, o RenderStyle.h que vai guardar objetos de referência com cada uma das propriedades CSS do documento. O nó criado no DOM é verificado no documento de CSS e caso existam propriedades que incidam naquele elemento, ela é aplicada. Esta propriedade fica salva dentro da Render Tree até que ela seja destruída ou que este valor seja alterado por algum script.
3. CSS Box Model: Após o método RenderStyle ser criado, ele é acessado via RenderObject. O Box model é usado para posicionar um elemento dentro da página, oferecendo suporte para o conteúdo, padding, bordas e margens que envolvem este elemento

Destruindo (ou atualizando) a Render Tree

A Render Tree é destruída quando nós da árvore DOM são removidos, causando a necessidade de um novo parse no DOM, ou quando uma tab do navegador com a árvore DOM usada é fechada. Após o refresh da árvore DOM, todo o processo acima é refeito, com attach chamando o RenderStyle, que montado chama o método style() do RenderObject que acessa o CSS BOX model.

Como os navegadores interpretam todos estes elementos criados por DOM e Render Tree antes de aplicar o estilo?

Todo navegador tem uma lista de elementos HTML suportados. Quando o seu markup possui tags presentes na lista, a árvore DOM é montada e o processo de attachment começa logo na sequência e os estilos são aplicados, dando continuidade a criação da Render tree.

O grande problema é que cada navegador tem a sua própria lista, que trata situações similares de maneiras diferentes. Obviamente já sabemos que o navegador que mais apresenta problemas para as situações acima é o Internet Explorer, mas acredite, todos os navegadores apresentam problemas quando um elemento não está em sua lista de elementos permitidos, e precisa de um trabalho para fazer tudo acontecer na Render Tree como deve ser feito.

Elementos fora desta lista são tratados como Elementos desconhecidos. E eles são uma grande fonte de problemas:

1. Como estilizar este elemento?Por exemplo, a tag <p> tem por padrão espacamento no topo e bottom, <blockquote> possui uma indentação automática adicionando uma margem à esquerda ou <h1> tem uma fonte maior que o <p> por ser um cabeçalho. Tudo isso esta padronizado, mas como cuidar de algo que não existe?
2. Como este elemento deve aparecer na árvore DOM?Os navegadores também possuem uma lista que mostra quais elementos podem ser filhos de outros elementos. Por exemplo, se você adiciona por engano no seu markup <p><p> o segundo paragrafo implicitamente fechará o primeiro <p>, fazendo que os dois elementos sejam irmãos (no mesmo nível na árvore DOM) e nao como nós filhos como de maneira linear pode parecer. Porém se vc adiciona um <p><span>, este paragrafo inicial não será fechado, porque o navegador permite que <span> seja filho de elementos de paragrafo, fazendo assim o <span> ser nó filho de <p>

Para elementos desconhecidos, a ideia é não estilizar. Caso queira algum estilo em elementos desconhecidos, você deve colocá-lo no nó acima (se necessário um wrapper), para fazer com que ele herde o estilo.

Perceba a sutileza de como isso funciona. Os dois diagramas mostram uma árvore DOM, montada por um navegador suporte HTML5 nativo e o Internet Explorer 8 (navegadores que não suportam HTML5 tem funcionamento semelhante):

Arvore DOM com suporte HTML5

Arvore DOM IE e outros navegadores sem suporte HTML5

É por essas e outras que a gente usa o modernizr, o HTML5shiv ou um simples document.create(“SECTION”) / document.create(“ARTICLE”). E é isso que acontece quando navegadores interpretam elementos desconhecidos. Eles desconsideram o nó real aonde o elemento está, e o reconhece como filho de <BODY>. E por favor, sem trocadilhos com o filho dos outros.

Ver como uma árvore DOM é montada  e como a Render tree é feita nos dá idéia do quão importante é ter um documento semântico. Realmente semântico. Uma vez entendidos os conceitos, a manipulação e a programação dos elementos fica mais fácil.

E você começa a entender como os navegadores funcionam.

Referências

Entendendo os Reflows por Alysson Franklin

Modernizr para suporte HTML5

HTML5shiv para suporte HTML5

Browser Wars pela Wikipedia

ECMAScript pela Wikipedia

Javascript pela Wikipedia

JScript pela Wikipedia

CSS Box model pelo W3C

DOM pela wikipedia 

Renderização no webkit, o básico pela webkit

W3C Overview do DOM

Declaração de atividades do DOM pelo W3C

Uma discussão sobre como Navegadores entendem elementos desconhecidos por Mark Pilgrim  

Traversing the DOM by Mike West

Progressive enhancement demystified by Aaron Gustafson

DOM, HTML5, CSS3 e Performance – Slides por Paul Irish

E também o @mariocaixa, esse cara tem o DOM!

Posts Relacionados

• Entendendo os Reflows
• Conteúdo, Flash e HTML
• Ah, o maravilhoso mundo real
• Agora é a vez dos desenvolvedores
• WebIntents – Framework para WebApps

CSS3 PIE

Aplicar propriedades CSS3 é bastante simples e nenhum segredo para desenvolvedores experientes, porém fazer com que estes atributos sejam aplicados aos novos e aos atuais browsers de mercado pode representar uma tarefa um pouco mais trabalhosa.

O browser IE (sempre ele) é um dos responsáveis por esse trabalho. Nas versões 7 e 8, não interpreta as propriedades que vamos demonstrar em nosso tutorial, desta forma, a renderização deverá acontecer através do uso de javascript (neste caso PIE) e mesmo que você não tenha familiaridade com a linguagem, não se preocupe, pois a aplicação deste é simples e baseada apenas na hospedagem de alguns arquivo no servidor e a chamada destes na classe ou ID correspondente no css.

Para iniciar, clique aqui e baixe os arquivos CSS3 PIE.

Após, descompacte os arquivos e os hospede no diretório raiz de seu site (seja online ou local) e pronto! Já podemos começar a utilizar bordas arredondadas, gradientes e sombras no IE 7 e 8.

Firefox, Chrome, Safari e Opera.

Todos os browsers acima citados, em suas versões de mercado, renderizam as propriedades que vamos aplicar neste tutorial, porém o Opera 10 não identifica o atributo que cria gradientes de background e desta forma, utilizaremos valores diferenciados para esta exceção.

Bordas arredondadas

Para inserirmos bordas arredondadas utilizando CSS3, basta inserirmos a propriedade border-radius e atribuir um valor para tanto, porém devido as diferenças entre browsers e considerando que suas versões de mercado ainda não suportam completamente o parâmetros, distribuimos esta declaração para cada navegador.

Como utilizar a propriedade?
border-radius – declaração integral para todas as bordas do box

Na prática:

E pronto! A borda arrendonda dos elementos será renderizada.
Outras possibilidades de valores ainda são permitidas, por exemplo quando pretendemos atribuir um valor diferenciado entre a distância do centro do círculo imaginário ao topo ou à lateral.

Como utilizar a propriedade?
border-[top/bottom]-[left/right]-radius – declaração segmentada para cada uma das bordas do box

Na prática:

Sombras

A propriedade que define sombra à um box, no CSS3, pode criar diversas possibilidades visuais desde que os atributos sejam declarados. Na totalidade da propriedade, o que podemos declarar é:

Como utilizar a propriedade?
box-shadow: [inset (declaração opcional e referente a shadow interna), posição X, posição Y, blur, largura, cor ]

Abaixo, as declarações para nosso exemplo:

Background: linear-gradient ou radial-gradient
Para definir um degradê de fundo à um box utilizando CSS3, basta inserir a propriedade background: linear-gradient ou radial-gradient e declarar os devidos valores, porém esta propriedade ainda pode ser renderizada de forma diferente entre os browsers, inclusive nas porcentagens que saem de uma cor migrando para outra. De qualquer forma, dependendo do resultado que você pretende obter em tela é perfeitamente aplicável.

Como utilizar a propriedade?
background: linear-gradient{posição, cor (from), cor(to) porcentagem};

Segue o exemplo:

Leia mais sobre gradientes em css, clicando aqui.

Veja um exemplo, clicando aqui. E baixe o código pelo nosso GitHub aqui.

Até a próxima.

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• CSS3 – Sombras em textos e elementos
• CSS3 – Módulo Template Layout
• CSS3 – Animation e regra keyframe
• CSS3 – Breve introdução ao RGBA

Coda e Textmate

Eu não consigo usar apenas um deles. O Coda tem um find/replace sensacional que me permite procurar pela pasta do projeto inteira ou pelo diretório atual. Infelizmente ele não tem uma série de outras facilidades que o Textmate tem, como macros e snippets. Na verdade o Coda tem sim suporte a isso, mas as features do Textmate são bem melhores. Em compensação o Textmate não tem um find/replace tão útil quanto o Coda e também não mantém a árvore de diretórios ao lado do editor, a não ser que você crie um projeto, o que é um pouco chato…

Os dois precisam se atualizar. O HTML5 está aí, juntamente com o CSS3 e o JQuery, mas eles continuam tendo só o doctype do HTML4.01 e XHTML 1.0. O Textmate tem alguns bundles que atualizam o código para entender essas novas tags.

GIT

Na Visie usamos o GIT como o controle de versão padrão. No começo eu era meio avesso a qualquer controle de versão. Não queria ter que ficar escrevendo a cada tarefa concluída o que exatamente eu fiz e como resolvi. É muito chato. Mas depois que eu me entreguei a essa “burocracia” já fui salvo diversas vezes. Não recomendo nenhum sistema de interface gráfica para utilizar o GIT, tem alguns muito bons, mas prefiro ainda fazer tudo via terminal.

Redmine

Todo gerente precisa de um ambiente onde ele possa contabilizar o processo de produção do seu projeto. Hoje, eu posso dizer que eu não sou nada sem o meu Redmine. Ele me avisa por email se alguém modificou o status do ticket, avisa o desenvolvedor que foi criado um ticket para ele, me avisa se alguém do projeto criou um novo ticket, me dá o relatório detalhado de horas de todo o projeto e uma das features mais importantes: integra com GIT e SVN… Coisa linda de Deus.

Illustrator

Nem preciso dizer muito. Uso o Illustrator para fazer quase tudo gráfico, desde layot até rascunhos de wireframes, embora o Axure seja mais adequado. Mas o Illustrator me traz uma flexibilidade como nenhum outro programa gráfico.

Migre.me ou Google Shortener

Qualquer um dos dois é uma boa pedida. A maioria dos links que posto no twitter do Tableless eu é feito com o Migre.me ou Google Shortener. Ambos trazem informações bem diferentes: o Google Shortener me passa o relatório de browsers, clicks, sistemas operacionais e etc… O Migre.me me mostra a quantidade de retweets, quem retweetou minha mensagem, quantidade de clicks e ainda me dá badges quando ultrapasso uma determinada meta.
Os dois são indispensáveis para quem quer resultado rápido e usa o Twitter para conversar com a comunidade.

OS X

Eu não consigo mais desenvolver em ambiente diferente. Tem que ser MacOS (o que me leva ao próximo tópico). Com um macbook pro padrão de 13” consigo abrir 3 máquinas virtuais, Photoshop, Illustrator, dois editores e 3 browsers… com uma máquina Windows eu nem podia sonhar com algo parecido. Só se comprasse uma máquina parruda demais.

Os atalhos de mouse e teclado me acostumaram mal. Um exemplo clássico são os malditos Hot Corners. Não vivo sem! Sem contar os Spaces, gerenciamento de memória, interface mais organizada, programas de terceiros bem feitos e que realmente funcionam.

Parallels

Com o Mac consigo cobrir as minhas necessidades de Firefox, Chrome e Safari. O problema é que o IE ainda existe, por isso uso o Parallels com 3 máquinas virtuais distintas: WinXP com IE6, WinXP com IE7 e Win Vista com IE8. Já sei que vou ter que instalar outra máquina virtual para o IE9, mas essa é outra história.

Vou convidar o @davitferreira, @thaipoplade, @talitapagani, o Pedro Rogério e o Henrique Pereira.

Posts Relacionados

• Experiência cross-device
• Especificação para touch screens
• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Introdução aos padrões de codificação

Com este pensamento, criei um PDF simples, onde cito os principais problemas se prever o desenvolvimento para browsers ou meios de acesso antigos. É um documento onde você poderá imprimir e dar para o seu chefe e integrantes da sua equipe. É uma ferramenta para que você tenha alguma munição para te ajudar a convencer aqueles que tentam insistir no erro de manter uma compatibilidade perfeita entre browsers atuais e browsers de 12 anos.

Baixar o PDF – Guerra contra o Terror

Update A Microsoft anunciou sue a partir de 2012 o IE terá atualização automática nos sistemas Windows XP, Windows Vista e Windows 7. Isso quer dizer que estamos mais perto da salvação.

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Manipulando a metatag Viewport
• Seu lugar ao sol
• Novo parser HTML5 – FF4
• Convertidos do Tableless

Programador Python (2)

Conhece todos os misteriosos acrônimos do mês e já desenvolveu coisas úteis com metade deles. É capaz de construir e manter funcionando um grande sistema inteiro sozinho, desde a contratação e configuração do servidor. Preferências para os que souberem:

• Bons conhecimentos de padrões web
• Bons conhecimentos de Javascript e Ajax
• Administração e uso de sistemas Linux
• Capacidade de trabalhar sem supervisão

São adicionais interessantes:

• Ruby
• Subversion
• Vim

Programador PHP (1)

Programador PHP Absurdamente Rápido. É um gênio do PHP. Come PHP com farinha. Requisitos:

Pelo menos 3 anos de experiência comprovada em PHP:

• PHP5 e orientação a objeto
• Experiência na modelagem de sistemas orientados a objeto
• Experiência na construção de sistemas de grande porte (muitas telas, muitos requisitos, muitos acessos, muuuuuitas transações)

São adicionais interessantes:

• Bons conhecimentos de padrões web
• Bons conhecimentos de Javascript e Ajax
• Experiência no gerenciamento de equipes
• Experiência com Smarty
• Experiência com sockets

UX especilista em Web

O cara que sabe o que é bom. Tem aquela visão que ninguém tem. Requisitos:

• Arquitetura de Informação
• Illustrator
• Photoshop
• Usabilidade

São adicionais interessantes:

• HTML
• CSS

Especialista client-side

Come HTML no café da manhã, CSS no almoço e Javascript no jantar. Só há um problema: somos muito, mas muito chatos com código html/css/javascript. Requisitos:

• HTML5
• CSS
• Javascript e JQuery

São adicionais interessantes:

• Outros frameworks de javascript como Mootools
• WordPress
• Sites para mobiles

Para todas as vagas

Esta vaga é para quem não gosta de rotina. Horário flexível, trabalho parcialmente à distância, uma coisa nova a cada dia. Muito, muito, muito trabalho, muita pesquisa, muito comprometimento e muita pressão. Também muita liberdade e a chance de aprender muito.

Envie seu curriculo com as informações abaixo para trampo@visie.com.br:

/
• Qual sua pretensão salarial?
• Trabalha como PJ?
• Morar em São Paulo
• Qual o seu sonho?

Mais comentados

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