Até quando?

July 18th, 2007 § 0 comments § permalink

Minha mãe voou pela primeira vez na vida há meros dez dias–Belo Horizonte, Congonhas; Congonhas, Belo Horizonte.

Na volta, ele me disse: “Amei voar: é assustador quanto o avião levanta vôo, mas lá em cima é muito bonito; gostaria de ter tirado fotos ou ter levado um binóculo”.

E eu somente posso imaginar…

A grande dúvida

July 17th, 2007 § 2 comments § permalink

Como eu já mencionei aqui anteriormente, sou um grande fã da série Duna, de Frank Herbert. A morte do autor, em 1986, deixou a série inacabada e, por muitos anos, houve rumores de que seu filho, Brian Herbert, a terminaria baseado em notas deixadas por seu pai.

Obviamente, Brian Herbert viu a oportunidade de ouro em uma série tão famosa e publicou mais seis livros sobre eventos anteriores à série original antes de tocar o projeto de terminar esta última. Não contente com isso, planeja continuar com mais livros focados em personagens específicos.

Agora que a publicação do segundo livro dos dois volumes que concluirão a série está se aproximando, a minha dúvida é seu eu arrisco ou não ler os mesmos já que, pelo menos supostamente, são baseados em notas originais. Mas, pelas resenhas que eu andei lendo, não parecem tanto com o que Frank Herbert escreveria. A trama é muito óbvia, pouco profunda.

A tentação é grande, apesar disso. O sexto livro da série original termina em um gancho enorme e seria muito bom saber o que aconteceu depois. O problema é o risco de me decepcionar profundamente e acabar com parte do encanto de Duna. Dúvida cruel mesmo.

30KB

July 15th, 2007 § 5 comments § permalink

Eu ainda me lembro da época em que 30KB era o limite recomendado para o tamanho de uma página, incluindo imagens e quaisquer outros elementos. Obviamente, com a passagem do tempo, esse limite foi subindo e hoje é algo quase esquecido–muitas das páginas um pouco mais elaboradas que se vêem hoje possuem mais do que isso só em CSS.

Nos últimos tempos, eu estou acessando bastante a Internet em trânsito, usando o acesso EDGE do meu plano de telefonia. Como esse acesso é razoavelmente rápido, eu não chego a fica muito incomodado com a demora de algumas páginas, embora a diferença seja enorme comparando com os 4Mbps que eu tenho em casa e que uso normalmente para a maior parte do meu acesso.

O que mais me chamou a atenção nesse período é ver como praticamente qualquer página acessa ultrapassa facilmente o limite de 300-500KB de dados, com uma porcentagem boa ficando acima disso. Muitas chegam aos 1MB. O fato é que, mesmo com uma conexão de 4Mbps, uma página com 1MB quase sempre demora mais do que os possíveis dois segundos porque múltiplas conexões podem ser necessárias–e, geralmente, de vários servidores diferentes.

A grande ironia nisso tudo é que os grandes culpados são CSS e Javascript. O primeiro muitas vezes por causa do último, pelo uso de bibliotecas prontas que incluem sempre arquivos extras que os programadores das páginas não tem o cuidado de remover. O uso de bibliotecas como JQuery, Prototype, Dojo ou YUI pode facilmente adicionais centenas de KB a uma página se um certo cuidado não for tomado. E, muitas vezes, essa carga extra não só não roda, como impede que uma página seja visualizada em um dispositivo móvel.

Como isso tudo eu não estou advogando que devemos voltar ao limite de 30KB. Mas é uma prática interessante e necessária cuidar para que as páginas de seu site ou aplicação sejam os mais leves possíveis. Remover todo o CSS desnecessário, minificar seu código JavaScript–e dependendo do caso o HTML–pode ser algo interessante, poupando bastante banda para usuários que não tem acesso a banda larga ou que estão acessando de condições limitadas. Dependendo da situação, isso pode resultar inclusive em ganhos de acessibilidade.

O limite de 30KB existiu para uma época bem específica, mas existe sempre o fato de que o desenvolvimento da Web não é linear. Cuidar bem de suas páginas e evitar código e dados desnecessários ainda é uma boa política de vizinhança.

Haja paciência…

July 13th, 2007 § 6 comments § permalink

Acabei de fazer a instalação básica do Windows Vista e do Ubuntu em minha máquina nova. 250GB para cada um, para não ter briga. Agora é configurar os milhões de detalhes de cada uma das instalações. Pelo menos o Ubuntu eu sei que não vou precisar mexer tão cedo depois de configurado: o Ubuntu que eu tenho no notebook já passou por quatro upgrades sem qualquer problema.

Horrível

July 10th, 2007 § 5 comments § permalink

Comprei esses dias o Warcraft III: Reign of Chaos com a extensão The Frozen Thone. É, esse mesmo, o antigão. Estava 20 reais em uma loja aqui perto e eu resolvi comprar uma versão original já que sempre gostei do jogo e nunca tinha jogado antes–nem pirateado. :-)

Eu sou um cara que joga pouco. Não gosto muito de jogos demasiadamente “espalhados” (jogos em que você tem que ficar correndo para lá e para cá) e tendo a preferir aqueles em que você tem que seguir uma história mais do que competir contra unidades e unidades inimigas. Meus favoritos, nesse caso, são o Heretic e o Hexen–tirando os chefões, é claro. Detesto chefões finais que você tem que derrotar na base de milhares de recursos adquiridos ao longo do jogo.

E sou horrível por sinal. Depois de dezenas de tentativas, só consegui bater o computador do Warcraft III duas vezes. E isso porque o cenário meio que coibia o crescimento do computador. Ainda bem que eu só consigo jogar uma vez a cada dois ou três dias. Se não já tinha morrido de vergonha. :-)

Padrões Web, modo mundo real

July 9th, 2007 § 13 comments § permalink

A confusa discussão que aconteceu aqui no blog sobre CSS e tabelas (1, 2) me chamou a atenção para um fato bem interessante: há vários desenvolvedores que se dizem ferrenhos defensores dos padrões Web e mesmo assim consideram que o HTML é irrelevante desde que o CSS torne o seu site usável.

Nos meus exemplos, eu disse que tanto o Google Docs quanto o Google Reader se removidos do seu CSS se tornavam uma completa bagunça. Um dos comentaristas disse que isso era normal e esperado, já que o CSS é para estilizar o site.

O Google Reader é exemplo interessante e vale a penar remover o CSS do mesmo e ver o que acontece: o usuário desavisado toparia com uma mensagem de carga (“loading“) no topo da página, seguida de um elemento IFRAME vazio, vários botões que não funcionam e, no final da página, uma verdadeira confusão de imagens, textos, pedaços de elementos da páginas jogados ao acaso.

Alguém poderia argumentar que é justamente para isso que o Google investe tempo em detectar o navegador e apresentar uma versão customizada da página de acordo com o necessário–o que, por experiência própria, posso dizer que não funciona em todos os casos e sempre acaba ocorrendo uma situação em que você gostaria de ver o conteúdo e não consegue.

A primeira lição que eu aprendi no desenvolvimento com padrões Web é que seu site deve degradar graciosamente, isto é, deve cair em comportamentos menores e ainda assim acessíveis e aceitáveis se certas tecnologias forem desabilitadas. Em outras palavras, se você usa Flex e alguém desabilita plugins, você deve passar a usar algo que substitua o Flex sem perder a funcionalidade; se você usa Ajax e alguém desabilita o JavaScript, seu site deve cair para HTML puro; se você usa CSS e o navegador não suporta ou não tem CSS habilitado, você deve ter HTML puro que ainda assim é usável.

Não adianta absolutamente dizer que você desenvolve com padrões, que valida seu HTML, que faz tudo dentro dos ditamesdo W3C se o seu site fica uma massa inútil de HTML quando perde o apoio de certas tecnologias.

E nisso entram situações comuns como inverter a ordem lógica de objetos da página porque você não conseguiu fazer seu float funcionar direito, colocar centenas de itens de navegação no começo da página porque seu layout requer isso e esquecer de colocar um link para pular esses itens, deixar elementos de Ajax soltos na página porque todo mundo usa navegadores modernos, e por aí vai.

Se você realmente diz usar padrões Web, lembre-se que isso é muito mais do que meramente criar um HTML que pretende ser semântico e jogar um punhado de CSS por cima, declarando que agora está completo. Testar no Internet Explorer, Mozilla e Safari nunca foi e ainda não é suficiente. Sem contar o pessoal que precisa de navegadores especiais (portadores de deficiências físicas e assim por diante), as pessoas estão cada vez mais usando navegadores em condições diferentes como portáteis e celulares onde o seu maravilhoso layout de 1024×768 (que, segundo você, é uma grande concessão já que todo mundo usa mais do que isso) falha miseravelmente porque a tela tem meros 240×320 (e isso quando é uma tela grande).

O que estamos vendo hoje é muito fervor em cima de algo que, na prática, mal está sendo aplicado. Sites que realmente seguem padrões Web no mundo real funcionam quando a situação de renderização muda radicalmente sem perder o passo. Dizer que você aplica os padrões sem chegar nesse ponto é a mesma coisa que usar tabelas para layout no seu site–porque, no final das contas, não diferença alguma entre o sujo e o mal-lavado.

Ruby on Rails in Brazil sob nova direção

July 8th, 2007 § 2 comments § permalink

Quase tinha esquecido de postar sobre isso, mas o Ruby on Rails in Brazil agora é Ruby on Rails Brasil, sob nova direção. Por falta de tempo (e, confesso, disposição) da minha parte, o site estava basicamente parado, com muita coisa sem funcionar direito.

Alguns dias atrás, o Júlio Monteiro se ofereceu para ajudar a gerenciar–depois de um comentário meu na lista rails-br–e eu acabei jogando foi o site todo na mão dele. O Júlio já lançou a versão nova, similar ao site original, e devo dizer que ficou excelente.

Uma adição muito bem-vinda foi o Planeta que evita a necessidade de manter um blog específico no site que pode acabar ficando parado–como o do site principal está atualmente. O Júlio quer as sugestões da comunidade e eu já deixo aqui as minhas:

  • Uma forma de contribuir com documentação em português
  • Uma listagem dos projetos, plugins, etc, da comunidade brasileira
  • Um possível wiki

No mais, meus parabéns, Júlio, pelo retorno desse recurso e meus votos são que a comunidade ajude a torná-lo ainda melhor.

Squeak e Smalltalk por exemplo

July 5th, 2007 § 10 comments § permalink

Para os que estão interessados em aprender mais sobre Smalltalk e a implementação aberta Squeak, topei ontem com esse excelente tutorial que demonstra a criação de um jogo em Smalltalk. O tutorial usa desenvolvimento baseado em testes, ensina como usar o depurador, como empacotar código e por aí vai. Vale uma conferida.

O que você queria saber

July 2nd, 2007 § 6 comments § permalink

Como mencionado aqui alguns dias atrás, o Eduardo Fiorezi me convidou para uma entrevista em seu Tudo que Quero Saber. Batemos um papo longo na sexta-feira passada e o resultado está no oitavo episódio do podcast.

Falamos de Rails, CakePHP, Seaside e um série de outras assuntos que estão mudando a área de desenvolvimento Web. Como eu temia, o sotaque mineirês ficou patente até para meus próprios ouvidos–eu não tinha idéia de que eu cortava tanto as palavras. De qualquer forma, espero que vocês gostem. :-)

Tableless vs. Mundo Real, Take 2

July 1st, 2007 § 10 comments § permalink

O Diego respondeu ao comentário do Lopes sobre o assunto, e eu quero dar a minha opinião.

Antes de começar, eu devo dizer que sou um forte proponente do uso adequado dos padrões Web. Eu já desenvolvia no que hoje é chamado de tableless antes mesmo que a palavra ganhasse evidência e já escrevia sobre o assunto há quatro anos atrás. Basta olhar o código desse próprio texto para ver que eu me dou ao trabalho de marcar até palavras em uma idioma diferente para maner o padrão ao longo de exportações, mesmo que o tema atual do blog não valide completamente. Meu comentário no texto anterior, foi, com muitos outros, a observação de uma ironia. Acho que preciso de mais smilies

Na minha realidade atual de desenvolvimento, eu uso padrões mesmo quanto o cliente não pede e mesmo quanto a linguagem não os suporta de maneira fácil. Qualquer um que já desenvolveu usando padrões Web usando .NET–ou pelo menos tentou–sabe que não é fácil adequar o seu código quando o framework insiste em ir contra você. Atualmente o .NET não está tão ruim, mas ainda há certas coisas que causas problemas difíceis.

Layouts completamente tableless são geralmente mais leves, mais legíveis e, conseqüentemente, mais fáceis de manter do que layouts que usam e abusam de tabelas.

Sobre os pontos que o Diego levanta, alguns comentários.

Primeiro, quanto ao fato do tableless ser ou não mais fácil de implementar. Atualmente, na maioria dos casos realmente é mais fácil. Escrever uma mera lista e transformá-la em um menu com um pouco de CSS é realmente um ganho muito grande. Mas existem algumas tarefas para as quais mesmo receitas prontas ainda são complicadas. Determinados tipos de menu, bordas arredondadas, rodapés fixos, e uma série de outras construções que povoam as listas de discussões e as buscas ainda possuem dificuldades inerentes que as colocam no nível de uma implementação utilizando tabelas.

Obviamente, muitos desses problemas serão resolvidos com CSS3, mas estamos a vários anos de implementações completas. Outro ponto complicado é a quantidade insana de bugs de CSS ainda não resolvidos nos navegadores atuais e as grandes divergências de implementação que tornam certas tarefas e ajustes bastantes complicados. Existem várias técnicas para ajudar, mas algumas são como o provérbio diz: emendas piores do que o soneto.

Segundo, quanto a levar mais tempo para testar, eu também acho que depende muito. Como no exemplo anterior, determinadas coisas são bem fáceis de serem feitas e testadas. Outras, nem tanto, exigem um grau de experimentação muito maior, mesmo quando há uma técnica presente. Mesmo assim, em uma coisa o Diego está mais do que certo: uma vez que o layout esteja pronto, testes e modificações são triviais.

Terceiro, sobre suporte. Aqui, concordo com o Diego, pelo motivo anterior. Depois que a primeira implementação fica pronta, modificações são muito mais simples e o suporte é correlacionado a isso.

Quarto, sobre o custo. Depende de todos os fatores acima. Uma coisa que muito desenvolvedor não fatora são as diferenças de plataforma operacional. Elas podem tornar o custo de um site tableless realmente mais alto. Mas isso também acontece com implementações decentes usando Ajax e acessibilidade.

Existe ainda um caso em que não há como escapar: manutenções. Manutenções são a minha via crucis atualmente e investir em renovações do layout em um formato novo é factualmente impossível.

Em última instância, eu prefiro continuar com o tableless. Como o Diego menciona também, depois que a curva de aprendizado é vencida, muitos dos problemas desaparecem. Nesse ponto, os casos em que o CSS é mais complicado se tornam uma simples questão de esforço cujos benefícios são superiores a longo prazo–o que, no final das contas, é o ponto do exercício todo.

Where am I?

You are currently viewing the archives for July, 2007 at Superfície Reflexiva.