Simplicidade em código pode ser resumida em a menor coisa que funcionar. Se a intenção é exibir um conteúdo, exiba-o da maneira mais simples e direta possível, dentro dos limites do projeto.

Funcionar é a palavra variável do princípio. Texto puro com capturas de tela funciona muito bem para tutoriais, por exemplo. Para campanhas de marketing é geralmente preciso um pouco mais de apelo na aparência para funcionar.

Animações são excelentes exemplos de facas de dois gumes. Um alerta que aparece animado na tela pode funcionar melhor do que um alerta estático, mas muitos alertas animados podem irritar o visitante. Simplicidade, usabilidade e conforto estão intimamente relacionados.

Projetar HTML para o conteúdo é fácil. A princípio basta deixar de lado qualquer decoração de lado, incluindo fontes, tamanhos, cores e posição dos elementos. Sem essas preocupações, você estará apto a criar uma marcação pura e objetiva.

Nesse e nos próximos posts da série, utilizarei a página de contato do Tableless como base para nosso projeto simplificado. Eu poderia ter escolhido sites ruins com código sujo, contudo escolhi o Tableless, que já possui um código enxuto e bem-feito, para levar a técnica ao extremo.

Procure extrair o máximo de simplicidade da página. Por exemplo esse topo:

Barra Superior do Tableless.com.br

Vira um texto similar a isso:

Texto Puro da Barra Superior do Tableless.com.br

Note que ignorei a ordem em que os elementos são exibidos. O logo aparece depois da barra superior, mas seu texto é mais visível e importante, por isso coloquei Tableless lá em cima. Ignorei também quaisquer firulas no texto. O que estava em maiúsculo eu digitei como texto normal, porque sei que posso mudar isso por CSS depois.

Dá uma olhada na versão em texto puro, tomei a liberdade de remover algumas coisas redundantes do conteúdo da página (A parte “Nós também fazemos”, por exemplo).

Agora que temos um texto puro, precisamos começar a marcá-lo semanticamente. Nossas ferramentas na próxima parte serão:

• Tags de marcação de títulos: <h1>,<h2> e <h3> (tem<h4>,<h5> e<h6> mas não precisaremos desses)
• Parágrafos <p> e imagens <img>
• Formulários <form>
• Grupos de campos <fieldset> com legendas <legend>
• Campos de formulários <input>, <textarea> e <button>
• Listas sem ordem específica <ul> e itens de lista <li>

Apenas com esses elementos, iniciaremos a reconstrução da barra superior mantendo o foco na simplicidade. Se eu demorar pra publicar a parte 3, puxem minha orelha nos comentários ou no twitter @alganet

Encurte usando o goo.gl

Ontem mesmo o Google lançou seu próprio serviço de encurtar URLs, o goo.gl. Inicialmente apenas usuários da Google Toolbar e do Feedburner poderiam encurtar suas URLs, mas aparentemente até mesmo a Google Toolbar não estava encurtando como devia.

Como sou bicho curioso, resolvi inspecionar o funcionamento dos cabeçalhos HTTP no momento em que a toolbar compartilhava links e notei que, embora a barra fizesse a requisição nos servidores do Google, essa requisição falhava. Também havia um parâmetro obscuro de autenticação que eu não pude compreender.

Abri o código do arquivo .xpi da Google Toolbar e fuçei até encontrar a função que gera o token de autenticação. Fiz algumas alterações nela pra funcionar fora do ambiente de extensões do Firefox e comecei a testar! Também custou pra descobrir que as chamadas tem que ser feitas em uma URL específica: /api/url, o que indica que provavelmente eles abrirão essa API no futuro. De qualquer forma, consegui! E aqui estou compartilhando com vocês um encurtador-protótipo:

http://gaigalas.net/lab/googl

Para quem não leu as letras miúdas na página, fiz uma breve sacanagem: Qualquer link encurtado por aí passa pelo migre.me. Yep. Você leva a URL do migre.me se quiser contar estatísticas e tudo mais, coisa que o Google não faz.

Configuraram a página para que somente um Chrome OS pudesse acessar, mas é facilmente burlável.

Cada navegador, em cada sistema operacional, identifica-se de uma maneira ao acessar uma página. Basta fazermos o Firefox identificar-se como outro navegador, o Chrome no Chrome OS e voilá, podemos acessar.

A user agent string do Chrome no Chrome OS é:

Mozilla/5.0 (X11; U; CrOS i686 9.10.0; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.253.0 Safari/532.5

Depois de alterar a user agent string, acesse o endereço da aba: http://welcome-cros.appspot.com/menu

Aqui uma screenshot:

Aba de serviços do Chrome OS no Firefox

UPDATE: Use isso somente como teste, sites podem não funcionar violentamente se você mantiver essa user agent string como padrão

Rapidinho fui um dos primeiros a baixar, compilar e distribuir a máquina virtual.

Fiz um vídeo com o Jonny Ken mostrando o funcionamento do sistema operacional e subi um torrent para quem quiser baixá-lo.

O formato é o VMDK, compatível pra rodar em máquinas virtuais VMWare e VirtualBox. Publiquei também um tutorial sobre como usar o VirtualBox para rodá-lo.

ATUALIZAÇÃO: Publiquei um tutorial pra gravar o Chromium OS em um drive USB.

Mais informações aqui (em inglês).

• Atômicas (uma transação não pode ser dividida e tratada em partes)
• Consistentes (uma transação interrompida não deixa vestígios)
• Isoladas (uma transação nunca interage com outra até terminar)
• Duráveis (se algo acontecer errado, o banco saberá voltar as alterações. Persistentes seria melhor, mas ACIP fica estranho).

São características fantásticas do ponto de vista funcional, mas geram problemas. O isolamento é uma frequente causa de problemas de performance, porque faz com que as tabelas fiquem travadas em determinadas transações. Se uma tabela com atualizações frequentes é também alvo de consultas demoradas e complexas, que cobrem uma grande quantidade de registros, é possível que uma grande fila de processos se acumule.

A maneira simples de evitar isso é controlar o nível de isolamento (e romper o princípio ACID) utilizando o comando SET TRANSACTION ISOLATION LEVEL. Quatro variações são possíveis:

• SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED, pra ler dados de quaisquer transações não-completadas
• SET TRANSACTION ISOLATION LEVEL READ COMMITTED, pra ler dados somente de transações completas, incluindo comandos internos
• SET TRANSACTION ISOLATION LEVEL REPEATABLE READ, pra ler dados somente de transações completas
• SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, pra utilizar em conjunto com SELECT…LOCK IN SHARE MODE

A diferença real entre o READ COMMITED e o REPEATABLE READ acontece em transações com mais de um comando. Se você enviar, por exemplo, uma série de consultas e atualizações dentro de uma mesma transação, os dois modos lerão dados de pontos diferentes:

• READ COMMITED atualizará os dados de leitura a cada comando. Um update em seguida do outro utilizará os dados atualizados, respeitando a transação no qual eles se encontram.
• REPEATABLE READ utilizará sempre um único conjunto de dados inicial. Se você efetuar várias atualizações, as leituras serão feitas do mesmo conjunto inicial sempre, relativo ao início da transação. Esse é o modo padrão no MySQL.

Refatorar também é importante. É simplificar código sem reduzir a funcionalidade. Você pega aquele código yakissoba (PHP+HTML+CSS+JavaScript quem curte?) de 500 linhas e reduz pra meia dúzia de pequenas funções de 10 ou 15 linhas. Ou pega aquele CSS monstro cheio de classes e IDs desnecessários e enxuga ao máximo.

Eu geralmente inicio meus projetos em CSS de maneira bem simples. Uso o mínimo de classes e ids possível, e se uso eu procuro seguir um padrão uniforme. Meu último projeto pessoal, o HtmlCss.com.br tem um código enxutíssimo. Projetei para que um iniciante pudesse abrir o fonte, ler e aprender com o código.

Ghiaweb: Framework feito para simplicidade

Talvez meu melhor exemplo de código enxuto é o Ghiaweb, que é um framework para construir sites sistemas na internet. O exemplo que está no ar, com um formulário consideravelmente complexo e um menu drop-down, não possui nenhum elemento HTML desnecessário, nenhuma classe nem ID. O código HTML é legível e organizado, simples de manter, adicionar novos campos ou seções no formulário sem prévio conhecimento da folha de estilos.

É muito comum ver formulários desenhados com várias classes, ids, parágrafos, divs e tudo mais. Muitas vezes, o desenvolvedor adiciona esses elementos para posicionar tudo da maneira que deseja. As classes e ids são pra localizar os elementos, para que as regras CSS possam ser aplicadas. Os elementos extra muitas vezes são somente para que as classes e ids sejam utilizadas (um perigoso círculo vicioso).

Uma série de práticas para manter a simplicidade, e que pretendo explicar nos próximos posts, é:

• Projetar para o conteúdo: Construir o HTML primeiro e não mexer mais nele. Só depois construir o CSS.
• Utilização de seletores: Encontrar exatamente o elemento que você quiser, sem adicionar classes e ids nele.
• Semântica dos órfãos do HTML: Aprender a utilizar um vocabulário de elementos melhor que divs e spans.
• Limitações: Como imagens de fundo, estilos em tabelas e elementos-McGyver.

Aguardo comentários

Colocar mais programadores pra trabalhar em um projeto atrasado vai atrasá-lo mais ainda.

Poxa, contra-intuitivo, né? Se você coloca mais gente pra trabalhar, o projeto deveria andar mais rápido. Não funciona assim pelos seguintes motivos:

• Um programador recém-introduzido em uma equipe coesa demora para tornar-se produtivo
• Programadores recém-introduzidos tendem a interromper e atrasar os membros de longa data do projeto
• Quanto mais gente, mais nós a informação tem que trafegar para comunicar. É mais simples “sincronizar” com pouca gente experiente do que muita gente inexperiente.

Opa, claro que existem as exceções. É possível por exemplo contratar gente pra tirar o entulho do caminho. Programadores pra criar ferramentas ao invés de desenvolver novos recursos, cuidar de compatibilidade, testes de qualidade, unitários e tudo mais. Mesmo assim, a vantagem muitas vezes não compensará o custo desses profissionais.

Epic Fail: Uma Realidade em 40% dos projetos de TI

Brooks não teve um insight do nada, ao tomar uma cerveja e coçar o joelho. Seu livro é resultado das experiências de desenvolvimento do projeto OS/360 da IBM, no qual ele foi gerente. Ao longo do tempo, muitos outros profissionais acabaram experimentando situações compatíveis com as idéias de Brooks.

Essa lei está intimamente ligada com os famigerados projetos marcha da morte. Provavelmente você já trabalhou ou conhece alguém que trabalhou em um. Nem precisa ser um projeto de TI, basta ter as seguintes características:

• A expectativa dos líderes quanto ao lucro, prazo ou sucesso do projeto é otimista demais ou não-realista.
• Um grupo diretamente responsável pelo desenvolvimento do projeto não acredita mais no sucesso do mesmo.
• O desgaste emocional e físico é crescente. São solicitadas, exigidas ou impostas horas-extra e fins de semana de trabalho.

Projetos marcha da morte são projetos destinados a falhar, que fugiram do escopo ou estouraram o prazo. Não há salvação, e todos da equipe sabem disso e continuam apenas porque são obrigado a fazê-lo.

Note que não há nada errado em fazer horas-extra ou adicionar novos membros na equipe, desde que o momento seja adequado. Muitas vezes, profissionais workaholics gostam de trabalhar mais para entregar mais cedo. Projetos saudáveis sempre estão abertos para novos membros que possam adicionar valor à equipe. O difícil é identificar esses momentos, um talento que vai além do bom senso.

Chaves: zaz, zaz

OpenID é o tipo de coisa que você lê, pensa “poxa que legal”, fecha o artigo e nunca mais abre na vida. Orientação a Objetos era assim algumas décadas atrás: Todo mundo falava sobre, mas raramente alguém sabia do que estava falando, e quem lia não tinha a mínima idéia da utilidade daquilo.

Pra quem nunca leu, a idéia é simples:

• Seu login e senha fica em um só servidor (login+senha fica mais bonito se chamarmos de credencial).
• O servidor não precisa saber o que você pode ou não acessar (autorização), ele só precisa saber quem você é (autenticação).
• Qualquer um pode montar um servidor.

O que naturalmente, em 99,78% dos casos, leva as seguintes perguntas:

• Se qualquer um pode ter um servidor, como é a segurança disso?
• Bacana, mas quem usa isso?

A segurança não é um problema, realmente. Se você criar um servidor e montar um usuário “admin” com uma senha qualquer, isso não significa que você poderá acessar o usuário “admin” de outro site. Um servidor pode autenticar somente credenciais que ele gerencia. Um exemplo simples e real:

1. Um fulano qualquer entra em um blogger qualquer, o Google Testing Blog por exemplo.
2. Fulano acha o conteúdo bastante interessante! Lá no canto ele vê um “Followers” e como é um cara bem-informado, sabe que o Google Friend Connect usa, entre outros provedores de autenticação, OpenID.
3. Fulano clica em “Follow”, escolhe o ícone do OpenID.
4. Fulano digita seu OpenID, que é simplesmente http://gaigalas.net (eu mesmo montei um servidorzinho!).
5. Servidor do Blogger delega autenticação para o servidor do Gaigalas, que pede usuário e senha.
6. Fulano digita seu usuário e senha (ou não, se já tiver feito isso e estiver salvo na sessão. Igual o “Lembrar de mim” do GMail).
7. Servidor do Gaigalas redireciona de volta para o servidor do Blogger, com um “OK”.
8. Blogger agora sabe que o misterioso visitante identificado por “http://gaigalas.net” é Alexandre Gaigalas, e está autenticado!

Autenticação via OpenID no Blogger

O Blogger não precisou perguntar pro servidor do Gaigalas quais as permissões de acesso do visitante misterioso. Ele assume, deduz, determina isso da maneira que bem entender. O importante é ele saber que aquele vistante é o Alexandre Gaigalas, identificado por “http://gaigalas.net”, e sempre que alguém identificar-se da mesma forma no futuro, esse alguém será o mesmo Alexandre.

Coisas bacanas:

• A opção “Lembrar de mim” funciona globalmente. Você loga só uma vez pro primeiro serviço, depois apenas utiliza a mesma sessão para os demais
• Se você mudar sua senha, pode mudar em todos os serviços ao mesmo tempo
• Você pode ter várias credenciais, da mesma forma que uma autenticação normal

Pra quem se interessou, pode obter um OpenID de várias formas: Uma Google Account ou Windows Live ID por exemplo são também OpenIDs. É possível montar seu próprio servidor usando o phpMyID.

Mas, e o OAuth?

Se o OpenID era autenticação (quem entra) o OAuth é autorização (onde entra). Cenário simples denovo:

• Fulano entra na enquete do novo filme do Michael Jackson
• Fulano escolhe as músicas e clica em “Save” para salvar suas escolhas
• Site do Michael Jackson conectará ao Twitter no qual o usuário se autenticará (que pode ser com OpenID, vide acima!)
• Twitter, após autenticar o usuário como Alexandre, pergunta se deseja que o site do Michael Jackson ganhe permissão para acessar o Twitter do usuário
• Alexandre aceita
• Twitter redireciona para o site do Michael Jackson com um “OK” e chaves de autorização
• Site do Michael Jackson agora está livre para utilizar o Twitter em nome de Alexandre

Enquete do Michael Jackson Solicitando Autorização via OAuth

Bacana não? O Twitter é um dos pioneiros em OAuth na internet, e milhares de aplicações no mundo já utilizam o padrão.

OpenID tem bastantes provedores, mas poucos consumidores. É raro encontrar um site que aceite OpenID. Facebook, por exemplo, é um deles.