Para ver todo o desenvolvimento da solução basta acessar o post. Já o resultado final pode ser conferido aqui.

Depois dou umas dicas de como por uns efeitos legais :]

Sábado aconteceu a aula Magna da tão esperada pós graduação em Front-end Engineer & Designer na Faculdade Marista do Recife.

Pra minha surpresa tive a a honra de ser escolhido para compor a mesa representando os front-ends da Fishy. Ao meu ver, quando algo desse tipo acontece, é porque estamos indo na direção correta :]

Se tiver afim de um pouco mais de informações sobre o curso, só entrar nesse link

That’s it, keep walking. Monkey walker =P

Mas esse não é o único problema de várias pessoas editarem o mesmo código. Existe ainda a questão dos preciosismos de cada desenvolvedor. Acredite, isso existe… Passei por isso algumas vezes aqui na Fishy, mas nada muito grave.

Mas não chegou a ser nada muito grave, já que na época que entrei haviam apenas dois front-ends. Entretanto algumas vezes apareciam alguns probleminhas… Principalmente na hora de entender o que aquela classe css queria dizer e qual a sua função.

De qualquer forma, afim de prevenir problemas desse tipo, começamos a desenvolver uma documentação interna ;] Na realidade essa documentação nunca ficou pronta, pois sempre apareciam coisas novas. Entretanto, a base ficou pronta depois de algumas reuniões e revisões.

Graças a isso, hoje temos um código uniforme e não temos grandes problemas para continuar o trabalho de outro front-end. Uma grande prova disso são nosso novos projetos. Um belo dia Rebeka, uma amiga nerd, chegou e me disse:

Antes eu sabia quem tinha feito os sites só de olhar o código… Hoje em dia isso não acontece mais, porque o código é praticamente igual em todos os projetos novos.

Nessa hora, ficou mais do que provado que estávamos no caminho certo. Hoje, nossa documentação praticamente não tem brechas, as coisas novas que vão aparecendo são analisadas e, caso seja possível, adotadas como solução padrão. Assim ela fica sempre atualizada e nosso trabalho cada dia menos difícil :]

E aí, você já pensou em fazer isso alguma vez?

Mas o que vem a ser performance?

Podemos dizer que é o tempo que a página que está sendo aberta, demora para ter todos os seus arquivos carregados. Dependendo da página isso pode levar alguns segundos, ou até minutos.

E em que isso influencia?

Olhando rapidamente, observamos apenas a demora para que aquela página seja carregada, mas ao aprofundarmos um pouco mais nessa questão, vemos que esse assunto vai mais além do que a espera do usuário. Basta pensar em sites como globo.com, yahoo.com, google.com e lembrar que eles têm milhões de acessos por dia. Olhando mais embaixo, concluímos que números de acesso acarretam em mais downloads dos mesmos arquivos, aumentando a banda que é consumida pelo site e com isso o dinheiro que é gasto para manter o site no ar.

Isso é apenas um dos pontos que uma boa performance pode resolver.

Se tudo der certo, próxima semana iremos começar a otimizar um site :]
até lá

Mas o que é um arquivo .htc?

Trata-se de um arquivo que contém instruções em javascript que são interpretados apenas pelos IE’s. Nesse caso específico, tal arquivo torna possível o suporte a transprânciea de arquivos png de 24bits. Mas usar tal arquivo requer um pouco de atenção, já que seu uso em grandes sites pode acarretar em uma sobrecarga no servidor. Ele é ‘ativado’ através de uma chamada no css, como no exemplo abaixo:

div{behavior:url("iepngfix.htc");}

E aí, o que faço para isso não acontecer?!?

Simples, ao invés de setar que o comportamento htc para todas as divs e imagens, uma coisa realmente desnecessária, devemos setar apenas para as divs que realmente irão necessitar de tal gambiarra. Assim evitamos um processamento desnecessário já que nem todos os elementos da página utilizarão uma imagem png. Para otimizar o uso do .htc basta seguir o exemplo abaixo:

#all{behavior:url("iepngfix.htc");}

Utilizei essa gambiarra no site de Natal do Plaza

Até a próxima o/