Chris B. – idéias e pensamentos

Era uma vez um programador C++ que cansou da vida de desenvolver aplicações para Windows, e migrou para desenvolvimento web.

O empolgante mundo web.

ASP, PHP, Java? Backend é backend, tudo funciona igual. Mas, e no mundo das interfaces? Lá ele conheceu os terrores da falta de padrão entre os browsers.

Anos e anos lidando com IE6, Firefox, Opera, Safari… o novo IE7 (na época), atualizações do Firefox, Chrome, versões diferentes em sistemas operacionais diferentes. Por mais que se sigam padrões, ajustes sempre são necessários. Principalmente por causa dele, o vilão: IE6

Bem, essa certamente pode ser uma histórinha aplicada a diversos desenvolvedores web. E não foge a mim.

Mas, chegou o momento de enfrentar o problema e propor que a empresa onde trabalho tome uma posição com relação a essa questão dos browsers. Um tempo atrás fiz uma enquete para saber qual seria a atitude tomada pelos leitores aqui do blog com relação ao IE8.
Nessa semana, foi lançado o 3.5 do Firefox, e denovo fiquei apreensivo. Resolvi mandar um e-mail para os demais líderes das equipes para chegar num acordo. O teor, mais ou menos, foi esse:

Pessoas,

hoje foi lançada a versão final do Firefox 3.5
A cada lançamento de versão nova de browser ficamos “apreensivos”, pois sabemos que são várias engines diferentes usadas pelos browser, e cada engine renderiza as interfaces e interpreta os scripts de forma não-(totalmente)-padronizada, e mesmo versões diferentes da mesma engine trazem diferenças.
Atualmente temos para o Windows, IE6, IE7 e o recém-lançado IE8, Google Chrome, Safari, Opera e Firefox nas versão 3.5, 3 e resquícios da 2.

Eu acredito que a empresa deva tomar uma decisão de quais serão os browsers suportados nas interfaces dos sites que desenvolvemos. Criar interfaces que funcionem em todas essas famílias de browsers e suas versões é inviável, tanto pela dificuldade da falta de padronização dos browsers como nossa estrutura para desenvolvimento (equipe enxuta, prazos sempre apertados, etc…)
Mais vale nos certificarmos que teremos validação total em alguns browsers, do que tentar validar para todos e não termos algo 100% funcional em nenhum, ao meu ver.

Recebi uma resposta positiva sobre o assunto, que era uma discussão válida, e continuei num outro e-mail:

Se for seguir apenas questões técnicas, ao meu ver o correto é validarmos
- apresentação em IE7+ e Firefox 3+
- funcionamento em IE6+, FF3+, Chrome (uma vez que usa o Safari usa o Webkit, funcionam corretamente)

Entendo por layout qualquer coisa que envolva html e css, enquanto que o funcionamento está relacionado ao script (javascript, normalmente).
Validar o funcionamento é conseguir terminar todos os fluxos existentes no projeto, mesmo que existam erros de apresentação.

É claro que com a experiência adquirida já pela equipe, sabemos onde pode dar erro de apresentação nos browsers antigos (usualmente no IE6) então no desenvolvimento tomaríamos os cuidados necessários para que eles não ocorram – o que não quer dizer que a correção dos mesmos entrariam como prioridade.

Acredito que seja necessário levar, ainda, dois pontos em consideração:
- essas observações devem estar incluídas no escopo do projeto
- muitas empresas, principalmente as com parque de máquina grande, ainda utilizam o IE6 como padrão, por diversas questões. É viável colocar essas premissas, limitando a validação dos projetos em determinados browsers?

E a resposta? Validação apenas em IE7+, Firefox3+ e afins. Ou seja, depois de muito tempo, dei um belo golpe no vilão IE6 e não mais terei – e minha equipe – que validar sites nele denovo!

Descobri através do Twitter um site bem bacana que apresenta um showcase de sites que utilizam (a biblioteca javascript) jQuery!

http://www.usejquery.com/

Ele é muito bem organizado, cada site apresentado possui além de um link e um printscreen para ele, uma classificação dentro de várias categorias, como manipulação DOM, Ajax, forms, lightbox, slideshow, etc… ou seja, cada categoria é um tipo de uso da biblioteca.

Você tem a opção de enviar links (de projetos seus, ou terceiros) para que entrem na galeria.

Muito bom, para ver diversos usos da jQuery e mesmo ter idéia de novas interfaces

A baleia do Twitter ficou famosa, principalmente no começo do serviço. Foi uma forma divertida adotada pelos desenvolvedores do serviço para informar que o serviço estava fora do ar em alguns momentos.

E de tão famosa, tem gente fazendo tatuagem dela! Divirtam-se!

PS: meu twitter, caso interessem, é @chrisloki

São vários tipos de leitores RSS disponíveis: clientes de e-mail que leem (e gerenciam seus) RSS, aplicativos web, browsers, start-pages…

*hey, você não sabe o que é RSS? De onde você veio? hehe

Esse site http://allrss.com/ disponibiliza uma lista com  todos leitores (se não tem todos, pelo menos a idéia deles é sempre se atualizar tentando manter a lista o mais atual possível) de RSS existentes.

Fiz uma seleção daqueles que são os mais usados, e agora pergunto: qual você utiliza?

 Loading ...

Um cliente aqui da empresa quis saber qual o comprimento máximo que uma url pode ter, devido a questões internas dele.

Sempre tinha ouvido falar que era de 255 caracteres, mas nunca tinha procurado referências. O que encontrei foram outros dados: tudo depende do browser e do web server.

Browsers

• Safari: 80.000 caracteres (imagino que o Chrome, por usar o Webkit, tenha o mesmo valor)
• Internet Explorer (todas versões): 2.083 caracteres
• Firefox 3.x: 100.000 caracteres
• Opera 9: 190.000 caracteres

Webserver

• Apache: por padrão, 4.000 cacarcteres, podendo chegar a 8.000
• IIS: 16.000 caracteres

Caso a url ultrapasse o limite de caracteres, será retornado um erro de status 413

Mas, vale lembrar: se a URL está longa demais, será que não é porque você deveria enviar esses dados por POST?

Fontes
http://www.boutell.com/newfaq/misc/urllength.html
http://www.openajax.org/member/wiki/Browser_Variation_of_the_Hub_Reference_Implementation_(Illustrative)
http://support.microsoft.com/kb/q208427/

*não sei o quanto esses dados estão atualizados, então se alguém tiver outros, mais novos, para reforçar esses ou corrigir, agredeço!

Vou usar erroneamente o termo POG nessa caso, pois o certo seria DOG. DOG?
Design Orientado a Gambiarras

Sim, designers também fazem gambiarras. Como?

O problema

Imagine um layout para um site que deve ser feito para resolução de 1024px. Bem, como explicado nesse post, a área útil da tela sempre é menor do que a resolução (devido às barras de rolagens, margens dos browsers, etc…)
Fizeram um layout com exatos 1024px, o cliente aprovou, passou por todo mundo, então quando começou a ser implementado o html/css desse layout se percebeu que estava dando barra de rolagem horizontal. Um crime!
E o cliente já pedindo pra ver como estava o andamento do projeto, qual o prazo de entrega, etc… bem, os layouts teriam que ser refeitos. Batemos o martelo e para ter uma “sobra”, foi acertado que ele seria ajustado para 980px.

A Solução Bonita

Readiagramar os layouts, diminuindo margens, talvez a largura de algumas retrancas, mudando o tamanho do banner, coisas do tipo

O POG (DOG?)

Não sei porque foi feito isso, mas… os layouts foram abertos no Adobe Illustrator e redimensionados para 980px. Ou seja, foi tudo diminuido: todos os banners, todas as fontes e seus espaçamentos, os menus, a iconografia. Tudo aquilo que já tinha sido ajustado com o cliente.
E, é claro, nesse puro resize do layout, algumas imagens ficaram craqueladas, sabe? Claro, tudo feito rapidamente, em poucos minutos. Fácil.
Conclusão: layouts tiveram que ser revistos e reajustados – sem o resize -, antes de passar para a nova aprovação do cliente. Mais um POG que não foi pro ar…