Fonte de Código

Como sobreviver numa arena

noreply@blogger.com (raph) — Wed, 03 Jul 2013 22:44:00 +0000

Em 1999, o mais novo lançamento do mundo dos games de tiro com visão em primeira pessoa (first person shooter ou, pela sigla, FPS) era o Quake III Arena, um jogo brutal em que jogadores do mundo todo jogam online numa arena de guerra onde dois grupos de guerrilheiros (armados com armas de fogo futuristas e extremamente letais) duelam até que um dos grupos tenha sido inteiramente exterminado. Quando isto acontece, todos os mortos retornam a vida e começa um novo duelo, e assim por diante...

Uma das inovações do game, segundo a desenvolvedora (Id Software), era a suposta “nova inteligência artificial” dos bots no jogo. Um bot (abreviação de robot) é uma aplicação de software concebida para simular ações humanas repetidas vezes de maneira padrão, da mesma forma como faria um robô. Durante o jogo, os personagens da arena controlados pelo computador (ou seja, não controlados por jogadores reais e humanos) supostamente observariam o estilo de luta dos demais jogadores, humanos ou bots, na medida em que a simulação das arenas de batalha transcorresse.

Com o tempo, seriam capazes de “pensar” em novas táticas, efetivamente se adaptando as táticas que mais venciam combates, e ignorando as táticas ineficazes para a sua sobrevivência, pois ganha o combate o grupo que sobrevive ao final [1]. Para que a inteligência artificial dos bots pudesse se desenvolver mais profundamente, entretanto, os servidores do jogo deveriam permanecer online, simulando centenas ou milhares de batalhas, por muito tempo a fio. E isto era inviável para os servidores oficiais do game, que precisam passar por manutenção semanal.

De acordo com um misterioso tópico de um fórum online (hospedado no 4Chan), em 2007 um jogador configurou um servidor pirata local do game (ou seja, hospedado em sua própria casa) para rodar indefinidamente simulações de arenas de combate entre 16 bots, sem nenhum ser humano a interagir com eles. Ocorre que este jogador esqueceu completamente do que havia feito, e como em sua casa os computadores ficavam sempre ligados, como servidores locais, a simulação rodou por longos quatro anos, até que em 2011 ele finalmente se lembrou dela!

Cada um dos 16 bots da simulação havia gerado 512 MB de informações táticas aprimoradas por centenas de milhares de partidas letais. Eram 8 GB de informações. O que elas teriam gerado? Atiradores infalíveis? Coordenação perfeita e robótica para matar da forma mais eficiente possível? O jogador resolveu entrar na simulação para ver quanto tempo seria capaz de sobreviver...

Então, para sua surpresa, ele observou que os 15 bots (ele estava jogando como o décimo sexto) nada faziam, apenas olhavam para ele e o seguiam onde quer que fosse. Não pareciam mais duelistas letais, mas antes pacifistas em busca de um sentido para estarem vagueando indefinidamente por uma arena de batalha. Aparentemente, em alguns anos de simulação, a inteligência artificial dos bots chegou a melhor estratégia para a sobrevivência: ninguém morre quando ninguém mata.

A Teoria dos Jogos é um ramo da matemática aplicada que estuda situações estratégicas onde jogadores escolhem diferentes ações na tentativa de melhorar o resultado, ou seja, o retorno de suas escolhas. Inicialmente desenvolvida como ferramenta para compreender comportamento econômico e depois usada pela Corporação RAND para definir estratégias nucleares, a Teoria dos Jogos é hoje usada em diversos campos acadêmicos.

Podemos ilustrá-la de forma simples e direta com o chamado “dilema do prisioneiro”, originalmente formulado por funcionários da RAND:

Dois suspeitos, A e B, são presos pela polícia. A polícia tem provas insuficientes para sua condenação; mas, separando os prisioneiros, oferece a ambos o mesmo acordo: se um dos prisioneiros, confessando, testemunhar contra o outro e esse outro permanecer em silêncio, o que confessou sai livre enquanto o cúmplice silencioso cumpre 10 anos de sentença. Se ambos ficarem em silêncio, a polícia só pode condená-los há 6 meses de cadeia cada um. Se ambos traírem o comparsa, cada um leva 5 anos de cadeia. Cada prisioneiro faz a sua decisão sem saber que decisão o outro vai tomar, e nenhum tem certeza da decisão do outro. A questão que o dilema propõe é: o que vai acontecer? Como o prisioneiro vai reagir?

No “dilema do prisioneiro”, temos uma situação onde o altruísmo e a confiança mútua oferece o melhor resultado final para ambos os jogadores. No entanto, isto não ocorre sem o risco de se ficar calado, confiando em seu parceiro, e ao fim ser traído por ele, e receber em retorno o pior resultado. De certa forma, a Teoria dos Jogos e o “dilema do prisioneiro” se aplicam não somente a economia e as relações de poder entre potências nucleares, mas também a uma partida de Quake III Arena... Será mesmo?

Retornando ao experimento insólito do início do artigo, o jogador resolveu “ver o que acontecia se atirasse em algum outro bot”. Para sua surpresa, ao fazer isso, ele foi atacado (e morto) não somente pelos 8 bots do outro time, como pelos 7 outros bots de sua própria equipe!

Ou pelo menos foi isto que a imagem com capturas de tela do suposto tópico do 4Chan dizia. Muitos sites de games compartilharam a notícia, e ela obteve certa fama também nas redes sociais. No entanto, como muitos podem ter imaginado, era tudo um hoax, ou seja, uma história inventada, como tantas outras que vemos nestes tempos de propagação desenfreada da informação.

Porém, ainda que não tenha ocorrido de verdade, ainda que os 16 bots com suas inteligências artificiais sejam incapazes de interpretar o resultado de suas ações (já que são ferramentas de computação, e não seres de interpretação), esta história ainda nos toca numa questão primordial: ela foi espalhada como algo verossímil, extremamente verossímil.

Penso que muitos de nós têm esta certa queda por acreditar que uma simulação computacional possa, de alguma forma incompreensível, chegar a conclusões que, no fundo, são as nossas própria conclusões, mas que não temos a vontade, ou a coragem, de coloca-las em prática.

Afinal, não se enganem: o bot do game mais avançado do ano que vem não será mais nem menos ferramenta do que um martelo ou uma bomba nuclear. Não é o martelo que mata ou constrói coisas, é quem o empunha. Não foi o material radioativo, e nem mesmo os físicos que descobriram a fissão nuclear quem arrasaram Hiroshima, foram aqueles que deram a ordem: “soltem a bomba”...

Somos, desta forma, todos prisioneiros desta enorme simulação chamada “mundo”, e só sairemos desta prisão de mãos dadas – todos serão livres somente quando não houver mais nenhum prisioneiro.

***

[1] Isto não deixa de ser uma forma de programação genética.

Crédito das imagens: [topo] Quake III Arena (captura de tela); [ao longo] Adrianna Williams/Corbis

Programar e codificar: uma reflexão

noreply@blogger.com (raph) — Fri, 11 May 2012 20:13:00 +0000

Aqui vai uma pequena reflexão do meu dia a dia como programador de interface web:

Uma amiga programadora me chama no Skype e pergunta se posso ajudar a resolver um problema com o código HTML de um site que ela está ajustando (na verdade, CSS, pra quem é da área), eu identifico e resolvo o problema em torno de 5 minutos, pois já havia passado pelo mesmo problema várias vezes antes. Ela, entretanto, estava horas tentando resolver, e fica muito agradecida.

Para um programador puro, que faz programação e não codificação (como é o meu caso) a noção de formas e design não é tão boa quanto a noção lógica e matemática, pois eles lidam muito mais com as últimas do que com as primeiras. Eu, no caso, sou exatamente o inverso disso...

Desse modo, não faria sentido eu me achar "um programador de interface foda" somente porque resolvi um problema que minha amiga estava horas tentando solucionar... O dia que eu tiver um problema que envolva lógica de programação, e não design, provavelmente serei eu a pedir ajuda pra ela.

E a empresa em si, tem a sorte de poder contar com essa comunicação e amizade entre seus funcionários (a minha empresa nos chama "colaboradores", que acho bem melhor), pois as horas de trabalho da minha amiga, ao invés de se estenderem ainda mais, se "encolheram" para 5 minutos.

É por isso que acredito que ambientes de trabalho assim têm muito a ensinar para outros sistemas de trabalho, no mundo todo.

O manifesto pirata

noreply@blogger.com (raph) — Mon, 23 Jan 2012 19:28:00 +0000

O texto abaixo é quase uma espécie de manifesto pró-pirataria na web, feito em forma de nota pelo site Pirate Bay. Podemos ser contra a pirataria em muitos casos (principalmente pirataria da obra de pequenos artistas, fora da "grande indústria"), mas realmente o que as grandes corporações de mídia americanas estão tentando fazer com a web em seu país é indiscutivelmente ridículo - particularmente se considerarmos a origem das mesmas. Vejam só que interessante:

Há mais de um século, Thomas Edison conseguiu a patente para um aparelho que faria “para o olho o que o fonógrafo fez para o ouvido”. Ele o chamou de cinetoscópio [Kinetoscope]. Edison não foi apenas o primeiro a gravar vídeo, mas foi também a primeira pessoa a ser dono do copyright de um filme cinematográfico.

Por causa das patentes de Edison para filmes cinematográficos, quase foi financeiramente impossível criar filmes de cinema na costa oeste norte-americana. Os estúdios de cinema, assim, mudaram para a Califórnia e fundaram o que hoje chamamos de Hollywood. A principal razão é que ali não haviam patentes.

Não havia também nada de copyright, então os estúdios podiam copiar velhas histórias e fazer filmes a partir delas – como Fantasia, um dos maiores hits da história da Disney.

Portanto, toda a base dessa indústria, que está hoje aos gritos sobre perda de controle sobre direitos não-materiais, é que eles driblaram direitos não-materiais. Eles copiaram (ou, de acordo com sua terminologia,”roubaram”) as obras criativas de outras pessoas sem pagar por isso. Eles o fizeram para obter grandes lucros. Hoje, eles são todos bem-sucedidos e a maior parte dos estúdios está na lista da Fortune das 500 empresas mais ricas do mundo. Parabéns – está tudo baseado em ser capaz de reutilizar criações de outras pessoas. E hoje eles detém os direitos das criações de outras pessoas. Se você quer lançar alguma coisa, você tem que seguir as regras deles. As regras que eles criaram depois de driblar as regras de outras pessoas.

A razão pela qual eles estão sempre reclamando dos “piratas” hoje é simples. Nós fizemos o que eles fizeram. Nós driblamos as regras que eles criaram e criamos as nossas próprias. Nós esmagamos o seu monopólio ao dar às pessoas algo mais eficiente. Nós permitimos que as pessoas tenham comunicação direta entre si, driblando o intermediário lucrativo, que em alguns casos levar mais que 107% dos lucros (sim, você paga para trabalhar para eles).

Tudo se baseia no fato de que representamos competição.

E a parte engraçada é que as nossas regras são muito similares às ideias que fundaram os EUA. Lutamos pela liberdade de expressão. Enxergamos as pessoas como iguais. Acreditamos que o público, não a elite, deveria governar a nação. Acreditamos que leis deveriam ser criadas para servir o público, não corporações ricas.

O Pirate Bay é uma comunidade verdadeiramente interacional. Nossa equipe está espalhada por todo o globo – mas ficamos fora dos EUA. Temos raízes suecas e um amigo sueco nos disse isso:

A palavra SOPA significa “lixo” em sueco. A palavra PIPA significa “um cano” em sueco. É claro que isso não é coincidência. Eles querem tornar a internet um cano de mão única. Eles por cima empurrando lixo cano abaixo para o resto de nós, consumidores obedientes.

A opinião pública nesse assunto é clara. Pergunte a qualquer um na rua e você vai descobrir que ninguém quer ser alimentado com lixo. Por que o governo americano quer que o povo americano seja alimentado com lixo foge à nossa compreensão, mas esperamos que você o impeça, antes que afoguemos todos.

A Sopa não pode fazer nada para brecar o Pirate Bay. Na pior das hipóteses, mudaremos o domínio principal: do atual .org para uma das centenas de nomes que também já usamos. Em países onde estamos bloqueados (os nomes China e Arábia Saudita são os primeiros que vêm à cabeça), eles bloqueiam centenas de nomes de domínios nossos. E adianta? Não muito.

Para consertar o “problema da pirataria” deveria se ir à raiz do problema. A indústria do entretenimento diz que eles estão criando “cultura”, mas o que eles realmente fazem é vender coisas como bonecas caríssimas e fazer meninas de 11 anos se tornarem anoréxicas. Seja de trabalhar nas fábricas que criam as bonecas por praticamente salário nenhum, seja por assistir filmes e programas de TV que as fazem pensar que são gordas.

No grande jogo de computador de Sid Meiers, Civilization, você pode construir maravilhas do mundo. Um dos mais poderosos é Hollywood. Com ele, você controla toda a cultura e mídia do mundo. Rupert Murdoch ficou feliz com MySpace e não via problemas com sua própria pirataria até seu fracasso. Agora ele reclama que o Google é a maior fonte de pirataria do mundo — porque ele está com ciúmes. Ele deseja manter seu controle mental sobre as pessoas e está claro que você consegue um visão mais honesta das coisas na Wikipedia e no Google do que na Fox News.

Alguns dos fatos (anos, datas) nesse texto estão provavelmente erradas. O motivo é que não podemos acessar essas informações quando a Wikipedia está fora do ar. Por causa da pressão de nossos rivais decadentes. Pedimos desculpas por isso.

***

Crédito da imagem: Pirata!

Tatuagem para HTMLers

noreply@blogger.com (raph) — Mon, 09 Jan 2012 04:10:00 +0000

Com essa tatuagem será mais fácil seduzir um HTMLer:

Frases de Steve Jobs

noreply@blogger.com (raph) — Thu, 06 Oct 2011 15:17:00 +0000

E quem diria que tudo iria começar com um garotinho adotado que abandonou o curso principal da faculdade, se matriculou em aulas de tipografia, e almoçava de graça uma vez por semana num templo Hare Krishna...

"Lembrar que estarei morto em breve foi a mais importante ferramenta que já encontrei para me ajudar a fazer grandes escolhas na vida."

"A morte nos lembra de que não há nada a perder. Você já está nu, não há nenhuma razão para não seguir seu coração."

"Ninguém quer morrer. Mesmo as pessoas que querem ir para o céu não querem morrer para chegar lá..."

"Mas a morte é provavelmente a melhor invenção da Vida, seu grande agente de mudança, ela se livra do velho para abrir caminho ao novo que vem chegando."

"Seu tempo é limitado, então não o desperdice vivendo a vida de alguém, não fique preso as expectativas e pensamentos dos outros."

"Seu coração e intuição já sabem, de alguma maneira, no que você quer realmente se tornar. Todo o resto é secundário..."

***

» Todas as frases foram retiradas do histórico discurso de Jobs em Stanford (abrirá em nova janela).

Crédito da foto: Divulgação (Apple.com)

Criando layouts para dispositivos móveis

noreply@blogger.com (raph) — Thu, 01 Sep 2011 20:32:00 +0000

Recentemente escrevi um artigo onde pesquisei sobre as melhores práticas na criação de layouts de sites e aplicações a serem visualizados por dispositivos móveis (mobile), achei por bem compartilhar esta informação aqui no blog:

1. Realize uma pesquisa sobre os hardwares mais utilizados por sua audiência

O mercado de dispositivos móveis é recente, mas encontra-se em franca ascensão. Uma das maiores dificuldades para criação de layout mobile é a enormidade de dispositivos diferentes que se encontram no mercado atualmente, e sua variedade de resolução de tela.

Vejamos alguns exemplos de resolução de tela (largura vs. altura, em pixels): 101x80 (muitos celulares da Sony Ericsson); 128x128 (alguns celulares da Samsung); 120x160 (muitos celulares da Motorola); 320x480 (iPhone); 480x640 (HTC Touch Pro); 320x480 (Palm Pre); 360x480 (BlackBerry Storm); 800x480 (HTC Venus); 800x640 ou superior (engloba a grande maioria dos tablets, como o iPad).

Em meio a tantas possibilidades de resolução de tela, o mercado parece ter chegado a uma convenção – uma resolução padrão que teoricamente deveria servir para a maioria dos dispositivos móveis. Essa resolução também é seguida por diversos softwares de aplicativos para mobile: 320x480 – ou seja, 320 pixels de largura por 480 pixels de altura.

Dessa forma, a menos que esteja criando um site específico para uma certa gama de dispositivos móveis, recomendamos que use layouts que fiquem ao menos bem estruturados e navegáveis mesmo quando limitados a uma resolução de 320x480 pixels.

2. Simplifique seu layout

A regra de ouro para layout criados para dispositivos móveis é que eles devem ser simples, minimalistas e focados na funcionalidade. Cada página geralmente deverá conter apenas uma lista ou um texto de detalhes (conforme o tradicional “lista e detalhes de notícias”), os menus não devem ser muito extensos, as imagens pequenas, e os efeitos de drop-down com mouseover limitados ao máximo. Apenas os botões devem ser proporcionalmente maiores, pelo menos em relação aos layouts tradicionais, pois devemos lembrar que em dispositivos com tela sensível ao toque, muitas vezes os cliques serão feitos com o próprio dedo do usuário – e a área de clique deve ser, portanto, maior.

3. Valide seu código

Conforme se torna cada vez mais difícil testar nosso código nos diversos dispositivos móveis do mercado, torna-se ainda mais importante termos um código que siga os padrões estabelecidos. Assim reduziremos muito a probabilidade de nosso site mobile não funcionar neste ou naquele dispositivo móvel de que nunca ouvimos falar – ou que ainda sequer foi lançado.

4. Inclua um link para o site tradicional

É recomendável incluir um link para a versão do site com o layout tradicional, normalmente no rodapé. Muitas vezes o usuário estará usando um tablet (como o iPad, por exmplo), e prefere visualizar o site em sua versão tradicional.

5. Crie um CSS exclusivo para a versão mobile

Embora seja viável criarmos um CSS que atenda tanto a versão tradicional quanto a móbile, na prática do mercado rapidamente se constatou que é muito mais simples a separação de ambos os layouts em arquivos CSS específicos. Muito embora seja interessante que as cores gerais e famílias de fontes sejam próximas do layout tradicional, o layout mobile tem características muito específicas para que faça sentido o uso do mesmo CSS da versão tradicional do site.

6. Evite o scroll horizontal no site

Muitas vezes os dispositivos móveis tem uma tela pequena, e devem ser manuseados com os próprios dedos do usuário. Nesse sentido, é ideal evitar a todo custo que o site na versão mobile possua quaisquer barras de scroll horizontais – o ideal é seguir o padrão de quase todo dispositivo móvel e usar apenas barras de scroll verticais. Isso, na prática, significa que devemos evitar ao máximo que qualquer elemento do nosso layout “estoure” os 320 pixels de largura, largura padrão para resoluções de tela de dispositivos móveis. Esta recomendação pode ser revista para, por exemplo, um portal que deva ser acessível apenas por ‘tablets’, que apresentam maior resolução.

7. Evite o uso de pop-ups ou links que abrem em novas janelas

A navegação através de dispositivos móveis não costuma funcionar muito bem com pop-ups ou links abrindo em novas janelas. Se for estritamente necessário o uso desses links, é recomendável que alerte que ele abrirá nova janela com alguma mensagem curta, ou ícone, ao lado do link.

8. Limite o uso de imagens

Layouts para mobile devem usar o menor número de imagens possíveis. Também é preciso tomar cuidado em especial com o tamanho dos arquivos de imagem, visto que no geral a qualidade da conexão de dispositivos móveis será inferior, e as imagens não podem ser muito pesadas (em Kbytes). O ideal é usar apenas a logomarca, alguns ícones de navegação e imagens de fundo para botões e outros elementos. Em uma interface de lista de notícias, por exemplo, é recomendável que existam imagens apenas nos 3 primeiros itens, deixando o restante dos itens da lista apenas com o título (e eventualmente a descrição).

9. Evite ao máximo o uso de flash e javascript

Nem todos os dispositivos móveis suportam flash e javascript. Conforme os layouts para mobile tendem a favorecer uma navegação simples e funcional, o uso desse tipo de tecnologia pode e deve ser evitado. O caso do flash é mais grave, visto que até o momento os iPhones e iPads não são compatíveis com flash (assim como alguns dispositivos móveis que vem com o sistema operacional Android, pelo menos na versão nativa). Algumas animações e vídeos podem ser criados utilizando a nova tecnologia do HTML5, Canvas, que é compatível com diversos dispositivos móveis modernos (maiores informações sobre a Canvas aqui: http://en.wikipedia.org/wiki/Canvas_element)

***

Crédito da imagem: Rafael Arrais (exemplo de layout para uma aplicação de uma seguradora de saúde fictícia)

Oráculo digital

noreply@blogger.com (raph) — Mon, 23 May 2011 14:57:00 +0000

Excelente vídeo da íntegra de gravação para o programa Café Filosófico, da TV Cultura, onde a especialista em SEO e marketing digital, Martha Gabriel, fala sobre a nova era das buscas digitais, numa interessante comparação com os oráculos da história antiga. Curadoria de Marcelo Tas.

Qual a importância da busca na vida humana? Como a crescente utilização dos ambientes digitais online, tanto móveis quanto desktop, interferem na orientação do que buscamos? Questões sobre privacidade, controle, poder, são abordados, mostrando a influência que os buscadores digitais (Google, Yahoo, etc.) exercem sobre o cotidiano das pessoas e a sociedade, funcionando como verdadeiros oráculos, os oráculos digitais:

» Ver o programa no site cpfl cultura (infelizmente não permitem compartilhamento)

***

Watson: quase humano?

noreply@blogger.com (raph) — Wed, 04 May 2011 22:37:00 +0000

Artigo de Pedro Burgos e Alexandre Versignassi para a revista Superinteressante, edição 290. Os comentários ao final são meus.

"Watson derrota a humanidade." Essa foi uma das manchetes para a vitória de Watson, um computador que ganhou dos melhores competidores que a raça humana tinha disponível no Jeopardy!, um jogo de perguntas e respostas da TV americana. Pudera: Jeopardy! é um jogo complexo. Para humanos, inclusive. São perguntas furtivas, tipo: "Isso é só um nariz sangrando! Você não tem essa doença genética que já foi endêmica entre a realeza europeia. Qual é a doença?". Watson acertou: hemofilia. Acertou essa e outras dezenas de perguntas capciosas - e, como seus concorrentes humanos, não estava ligado à internet. Tudo o que ele tinha à disposição era uma memória de 15 mil gigabytes com alguns milhões de textos arquivados e uma capacidade de processamento equivalente à de 2.800 micros caseiros. Um computadorzão bem programado, só isso.

E tudo isso: para responder perguntas nessa linha, um computador precisa entender a linguagem falada e ter um raciocínio capaz de fazer associações inesperadas. Até fevereiro, isso era exclusividade de humanos. Mas e agora, que perdemos para esse ser gelado? Dá para dizer que a inteligência artificial está se equiparando à nossa inteligência?

O debate está pegando fogo. De um lado, há os que vibram com Watson e similares e acreditam que os computadores vão superar logo a inteligência humana. A outra corrente diz que, por mais complexo e surpreendente que seja o feito de um computador, ele nunca será comparável ao de uma pessoa [1]. Seriam duas inteligências distintas.

O termo "computador" denunciaria isso, por sinal. Até a metade do século 20, "computador" era uma profissão. Eram pessoas responsáveis por fazer cálculos longos - como pegar um monte de dados astronômicos e calcular quando um cometa passaria de novo pela Terra. Pessoas inteligentes, claro. Mas e hoje? Bom, hoje inteligente é quem bola o programa para que o computador resolva as contas.

Toda vez que conseguimos delegar uma função para máquinas, a tarefa perde a nobreza. Isso aconteceu até na derrota do campeão Kasparov para Deep Blue em 1997. Enquanto os defensores da inteligência artificial comemoravam, os da humanidade saíram-se nessa linha: "Bom, xadrez é só um jogo de análise estatística bruta. Não requer inteligência de verdade". Com a vitória no Jeopardy! pode acontecer a mesma coisa: "Computadores vão bem? Ah, o jogo não é nada de mais".

Mas e se habilidades que consideramos pessoais e intransferíveis da nossa espécie puderem ser executadas por máquinas sofisticadas? Como ficamos? Se quisermos reduzir as habilidades do Homo sapiens a instruções de programação, o talento para a poesia, por exemplo, pode ser descrito como um programa capaz de achar uma boa combinação de palavras. E daria para definir um líder político como um sujeito com um bom software para analisar riscos e oportunidades [2].

Não é fantasia. O próprio Watson pode servir para tarefas bem mais humanas que responder perguntas. Programado adequadamente, ele pode fazer diagnósticos com mais precisão que um médico - da mesma forma que uma calculadora de bolso é mais rápida que qualquer gênio da matemática. O supercomputador tem como ouvir relatos orais de pacientes e cruzar os sintomas com o banco de dados de toda a literatura médica em segundos. É mais do que qualquer Dr. House pode fazer. Mas isso torna os humanos dispensáveis? Não. Por mais que uma máquina consiga feitos mirabolantes, ela vai ser sempre uma ferramenta que depende de humanos. Um "computador médico" precisa de médicos para ser programado. Os cérebros humanos por trás são tão importantes que o próprio Watson errou questões por bobeira de programação. Um dos deslizes: perguntaram qual categoria da elite do automobilismo tem o nome de uma tecla de computador. "F-1" era a resposta. Qualquer batedeira tem capacidade de processamento para cruzar uma lista de nomes de teclas com uma de categorias de corridas. Mas a coisa mais próxima que Watson tinha para dizer era "Nascar". Falha dele? Não, dos programadores - a Fórmula 1 é solenemente ignorada nos EUA.

O erro nessas horas é imaginar que as máquinas são uma espécie à parte. Computadores são só alicates e martelos mais complexos [3]. E quando você marreta o dedo não é culpa da natureza do martelo, mas sua, que não soube "programar" a martelada. A vida é melhor com martelos. Com supercomputadores também. A vitória de um é uma vitória da humanidade. E sempre será, mesmo no dia em que uma máquina puder escrever um texto como este bem melhor do que a gente [4].

***

[1] Sempre me pareceu que aqueles que acreditam que os computadores estão "quase chegando ao nível humano" tem uma visão um tanto quanto superficial da mente humana, e da existência em geral. Nós nos diferenciamos das máquinas no sentido em que interpretamos informações do mundo a nossa volta, e não apenas as computamos e/ou cruzamos com bancos de dados na memória. Em suma, somos seres de vontade, e nenhuma máquina até hoje chegou sequer próximo de demonstrar alguma vontade. Mesmo Alan Turing jamais imaginou que um computador seria o equivalente de um ser humano, tudo o que disse é que as máquinas poderiam eventualmente fazerem-se passar por um ser humano, nos copiar quase a perfeição - mas até hoje não há máquina que tenha passado no teste de Turing.

[2] Se é que um computador um dia produzirá poesia de qualidade, isso nada mais será do que o resultado da arte de uma programação. Talvez combinada com uma boa dose de conhecimento da gramática, mas uma programação. Ou seja, um dia talvez programadores sejam poetas - máquinas, nem tanto...

[3] E, como qualquer outra ferramenta criada pela humanidade, são fruto de nossa mente em sua potencialidade criativa. Não faz sentido imaginar máquinas como novas espécies, ah não ser que você contrarie a teoria da evolução e afirme que nós mesmos fomos "programados" por alguma inteligência superior. Quem quer que tenha programado em nós essa divina capacidade de ter vontade, não passou o código-fonte adiante.

[4] Esse artigo, talvez até por ser de certa forma despretencioso, é genial em sua capacidade de síntese do que é e do que não é a inteligência artificial. Ora, devemos sim comemorar os avanços da ciência, da mesma forma que comemoramos a escultura de um gênio da arte. Não podemos é acreditar que, tal qual os mitos de gárgulas, nossas esculturas de silício ganharão vida própria, e deixarão de ser apenas uma ferramenta, para se tornar uma nova espécie - programando a si mesma de alguma forma "mágica".

***

Crédito da foto: Adrianna Williams/Corbis.

iPad 2

noreply@blogger.com (raph) — Thu, 03 Mar 2011 14:07:00 +0000

O repórter de tecnologia da BBC mostra o novíssimo iPad, revelado pelo presidente da Apple, Steve Jobs na quarta-feira. Ele conta que a primeira surpresa da noite foi a presença de Jobs, que está de licença médica, mas foi ao palco para dizer que o produto dele deve "arrasar a concorrência":

Asimov e a aprendizagem

noreply@blogger.com (raph) — Mon, 21 Feb 2011 18:22:00 +0000

Isaac Asimov, célebre escritor de ficção científica e exímio "futurólogo", preve o impacto da disseminação do conhecimento através da internet - já em 1988:

"O problema com a aprendizagem é que a maioria das pessoas não gosta dela por causa das circunstâncias. Faça que seja possível gostar de aprender e elas vão continuar aprendendo."

***

Se você ainda acha a Wikipedia (e similares) sem graça, talvez se interesse por algo mais dinâmico:

Atlas das redes sociais

noreply@blogger.com (raph) — Mon, 30 Aug 2010 15:11:00 +0000

Mapa criativo considerando cada rede social como um "país", de acordo com o número de usuários. Clique na imagem para ver em tamanho maior:

Fonte: Flowtown

A arte dos algoritmos

noreply@blogger.com (raph) — Thu, 26 Aug 2010 21:04:00 +0000

A ciência da computação nasceu com o conceito de algoritmo, criado conjuntamente em 1936 pelo experimento mental de Alan Turing, conhecido como Máquina de Turing, enquanto quase ao mesmo tempo Alonzo Church criava o cálculo lambda. Um algoritmo é uma seqüência finita de instruções bem definidas e não ambíguas, cada uma das quais pode ser executada mecanicamente num período de tempo finito e com uma quantidade de esforço finita.

O conceito de algoritmo é freqüentemente ilustrado pelo exemplo de uma receita, embora muitos algoritmos sejam mais complexos. Eles podem repetir passos (fazer iterações) ou necessitar de decisões (tais como comparações ou lógica) até que a tarefa seja completada. Um algoritmo corretamente executado não irá resolver um problema se estiver implementado incorretamente ou se não for apropriado ao problema.

Roger Alsin é um programador sueco bem menos conhecido, mas que aborda a arte dos algoritmos de uma forma impensável na época de seus criadores... No final de 2008, ele resolveu brincar um pouco com alguns algoritmos, mais precisamente algoritmos genéticos. Ele criou um pequeno programa que evolui cadeias de “DNA digital” para renderização de polígonos, eis as instruções aplicadas:

(0) Cria uma cadeia de DNA aleatoriamente (início do programa); (1) Copia a seqüência de DNA atual e aplica uma pequena mutação; (2) Usa o novo DNA para renderizar polígonos em uma tela; (3) Compara a tela com a imagem original (a ser copiada); (4) Se a imagem se parece mais com a imagem original do que a imagem gerada pelo DNA pai, substituir o DNA antigo pelo DNA atual; (5) Repetir a partir do passo 1.

Então, Alsin colocou como meta aos seus algoritmos tentar recriar (ou copiar da melhor forma possível) a Mona Lisa de Da Vinci usando apenas 50 polígonos semi-transparentes... Após 904.314 gerações, o algoritmo genético de Alsin chegou a uma imagem bastante próxima da original, se considerarmos que algoritmos não são exatamente mestres da pintura (ou pelo menos, ainda não são). Você pode ver a imagem final no início do artigo, ou ver as diversas gerações no weblog de Alsin.

Em 1992, John Koza – cientista da computação – usou algoritmos genéticos para desenvolver programas para realizar certas tarefas. Ele chamou seu método de programação genética. Koza foi pioneiro neste método de programação, que hoje é cada vez mais utilizado no mundo.

O aspecto mais bizarro e intrigante da programação genética é que seus algoritmos – verdadeiras “entidades de software” – não sofrem as restrições dos hábitos de pensamento e das inclinações intelectuais sutis dos programadores humanos. Como exploram irrefletidamente todo o espectro de soluções possíveis para um determinado problema, os algoritmos genéticos podem trazer soluções puramente alienígenas. Por exemplo, a NASA utilizou a programação genética para produzir o projeto ideal de um suporte a ser usado na Estação Espacial Internacional. Como relatou o U.S. News and World Report, o resultado parecia ter saído de um romance de ficção científica:

“Surgiu, de 15 gerações e 4.500 projetos diferentes, um suporte que nenhum engenheiro humano projetaria. O conjunto grumoso e com a extremidade arredondada lembrava o osso de uma perna, irregular e um tanto orgânico. Testes em modelos confirmam sua superioridade sobre os projetos humanos com suporte estável. Nenhuma inteligência fez os projetos. Eles apenas se desenvolveram.”

Outro exemplo espantoso da total estranheza da programação genética bem-sucedida é o código e computador que foi desenvolvido para ajudar um paciente a controlar uma mão protética com base em sinais nervosos erráticos captados por eletrodos presos ao pulso do paciente. O software desenvolvido analisava misteriosamente os sinais nervosos e os traduzia com precisão perfeita nos movimentos que o paciente queria fazer.

Mas aqui está a parte realmente estranha – o método pelo qual o software realizou esse feito incrível está totalmente além da compreensão dos pesquisadores humanos. Como relatou a Scientific American:

“O código desenvolvido era tão confuso e indecifrável quanto um inseto esmagado. O programa que prevê os gestos consiste numa única linha de código tão longa que enche uma página inteira e contém centenas de expressões parentéticas embutidas. Ele nada revela sobre por que o polegar se move de uma certa maneira – só revela que se move.”

***

Crédito das imagens: [topo] Roger Alsin (sim, pois foi ele quem criou o programa que copiou a Mona Lisa de Leonardo Da Vinci); [ao longo] Andrea Ruester/Corbis

Aplicando classes no Lumis MS com JQuery

noreply@blogger.com (raph) — Tue, 03 Aug 2010 19:10:00 +0000

No Lumis CMS versão Microsoft - ao contrário do Lumis Java - não é possível definir um nome de classe específico para as TDs estruturais das páginas. Conforme explicado no guia de protótipos de projetos, essas classes são aplicadas automaticamente na medida em que adicionamos linhas (monta uma TABLE com class="cEZTPageAreaX") e colunas (monta uma TD com class="cEZTPageAreaXColumnY") ao darmos drag and drop das interfaces dos serviços.

Entretanto, usando JQuery temos uma solução bastante simples para esse problema.

Ela consiste em inserirmos uma interface de serviço html a qualquer altura de uma coluna (mas fica melhor sendo a primeira interface), e nela inserirmos um marcador – como uma classe "anchor", por exemplo – para que através de um script bastante simples (usando o JQuery) busquemos as colunas (TDs) da página que possuem este tipo de marcador, e nelas apliquemos uma nova classe.

Na prática, equivale a aplicar a classe que quisermos na TD estrutural (ou TDs estruturais). Apenas dará um pouco mais de trabalho, e exigirá o uso do JQuery.

Veja no exemplo abaixo, um html que simula a estrutura do Lumis MS, com três interfaces lado a lado:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>JQuery: Aplicando classes com uso de âncoras</title>
 
<script type="text/javascript" src="jquery.js"></script>

<script type="text/javascript">
 $(document).ready(function(){
  $("td[class^='cEZTPageArea']:has(div.anchor)").addClass("my-class");
 });
</script>

<style type="text/css">
body.cLumBody {
 margin:0;
 background:#e9e9e9;
 text-align:center;
 position:relative;
}
div.cLumPage {
 width:600px;
 margin:0 auto;
 text-align:left;
 background:#fff;
}
div.interface {
 width:200px;
}
div.interface p {margin:20px;}

td.my-class {
 border-right:1px solid #ccc;
}
</style>
 
</head>

<body class="cLumBody">

<div class="cLumPage">

<table cellpadding="0" cellspacing="0" class="cEZTPageArea0">
<tr>
 <td class="cEZTPageArea0Column0">
 
  <div class="anchor"></div>
 
  <div class="interface">
   <p>Interface 01</p>
  </div>
 
 </td>
 <td class="cEZTPageArea0Column1">
 
  <div class="anchor"></div>
 
  <div class="interface">
   <p>Interface 02</p>
  </div>
 
 </td>
 <td class="cEZTPageArea0Column2">
 
  <div class="interface">
   <p>Interface 03</p>
  </div>
 
 </td>
</tr>
</table>

</div>

</body>
</html>

Repare no trecho de script destacado, é este trecho que adiciona a classe "my-class" a qualquer TD na página que (1) possua uma classe que contenha "cEZTPageArea" – ou seja, todas as classes estruturais do Lumis MS – e (2) que tenha em seu interior uma div com a classe "anchor", que é o nosso marcador. Dessa forma, esta alteração somente ocorrerá nas colunas em que inserirmos a interface de serviço html com este marcador.

Ver exemplo

***

Nota (1): este artigo não pretende encerrar o assunto em relação a boas práticas e/ou soluções para limitações do Lumis CMS, recomendamos consultar o suporte da Lumis ou o Lumis Information Exchange (LINX) para consultar outros artigos e soluções para problemas encontrados.

Nota (2): a solução descrita neste artigo foi originalmente elaborada pela WorkingMinds para um de seus projetos com Lumis MS, estamos apenas divulgando o conhecimento adiante...

Google Code

noreply@blogger.com (raph) — Thu, 29 Jul 2010 17:56:00 +0000

Se você é desenvolvedor de websites e conhece alguma coisa de javascript, certamente já ouviu falar nas bibliotecas de código livre (open-source javascript libraries). Elas facilitam muito o trabalho porque já trazem inúmeras funções recorrentes ao desenvolvimento prontas, de modo que quase nunca precisamos iniciar uma nova função do zero (ah não ser que ela seja bastante original ou exótica).

O grande problema de usar essas bibliotecas é que precisamos incluir um arquivo javascript relativamente pesado na página. Alguns, como o JQuery, não passam de 56Kb (31Kb na versão de arquivo comprimido) – já outros, como o Prototype, podem passar dos 160Kb de includes, quando usado juntamente com os efeitos do Scriptaculous.

Muitas vezes esse tempo de loading acaba não compensando, mesmo se considerando as velocidades atuais (já que, principalmente no Brasil, temos uma das piores bandas largas do mundo). Algumas estratégias para contornar o problema geralmente passam pelo uso das bibliotecas apenas em certas páginas internas – como álbuns de fotos ou formulários com validação "elaborada" –, deixando a home livre do peso do loading desses includes... Mas eu acabei encontrando uma solução melhor, que pode se enquadrar em qualquer cenário, principalmente para websites pequenos ou hospedados em servidores modestos.

Ocorre que a Google (acredito que dispense maiores apresentações) hospeda as bibliotecas mais famosas em seus servidores, e gratuitamente. Para inserir o Prototype com Scriptaculous em seu website, por exemplo, você nem precisa ter os arquivos javascript hospedados em seu servidor – basta chamá-los dessa maneira:

<script src="http://www.google.com/jsapi" type="text/javascript"></script>
<script type="text/javascript">
  google.load("prototype", "1.6.0.3");
  google.load("scriptaculous", "1.8.2");

  google.setOnLoadCallback(function() {
    $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&v=1.0&callback=?",

      function (data) {
        if (data.responseData.results &&
            data.responseData.results.length > 0) {
          var results = data.responseData.results;
          
          for (var i=0; i < results.length; i++) {
            alert(results[i].titleNoFormatting);
          }    
        }
        
      });
    });
</script>

Com isso estamos chamando os arquivos diretamente dos servidores da Google, evitando o uso de banda de nossa hospedagem e servindo os usuário de nosso website com uma velocidade de download bem superior a de 95% dos websites do planeta. Vejamos o que ganhamos e perdemos com isso:

Prós
– As versões das bibliotecas se atualizam automaticamente. Se não chamarmos uma versão em específico, será usada sempre a versão estável mais atual.
– A velocidade de download dos arquivos será quase sempre superior nos servidores da Google, de modo que o problema do tempo de loading de arquivos mais pesados (como o Prototype) é bastante minimizado.
– Muito provavelmente o fato de chamar constantemente os servidores da Google ajudará também a manter o website bem posicionado nas pesquisas da própria Google (SEO).

Contras
– Quando a Google estiver fora do ar, o javascript em seu website ficará quebrado. A questão é que a Google provavelmente passará muito menos tempo fora do ar do que o seu próprio servidor de hospedagem, a não ser que seu site seja um portal com grandes níveis de acesso (hospedado em servidores de ponta).

Como pode ver, acredito que os Prós são facilmente superiores aos Contras.

Eu uso esse método para chamar o Prototype com Scriptaculous no meu site de portfólio – na verdade eles servem para fazer funcionar o lightbox das imagens:

Ver meu portfolio (Ayon)

***

» Visite a Google Libraries API (Google Code)

» Veja o guia de como chamar as bibliotecas públicas em seu website

Mag+ com Popular Science+

noreply@blogger.com (raph) — Fri, 09 Jul 2010 19:12:00 +0000

Certamente todos devem ter ouvido falar nos e-readers mais atuais, como o Kindle da Amazon.com e o Ipad da Apple (dentre muitos outros). Interessante é notar que enquanto muito se falou no hardware e na tecnologia das telas (LCD ou e-ink, etc.), pouco se falou sobre uma revisão dos softwares de leitura, ou da usabilidade mais adequada para esse novo tipo de mídia (que está bem longe de ser um livro ou revista de papel, obviamente)...

Coube a um grupo editorial do norte europeu, com mais de 200 anos de história, trazer-nos uma visão mais adequada para a usabilidade dos e-readers. Enquanto ninguém se mexeu, eles pensaram e pensaram, e nos trouxeram o Mag+. Abaixo, um vídeo (em inglês) onde é exposta a usabilidade da revita Popular Science+, a primeira a usar o Mag+, no Ipad:

Como fazer caixas sombreadas, passo 3

noreply@blogger.com (raph) — Thu, 27 May 2010 22:55:00 +0000

continuando do Passo 2

Passo 3

Para fazer com que nosso amigo IE deixe a caixa sombreada, precisaremos recorrer a tag-proprietária -ms-filter (ou filter, para algumas versões) e utilizar o filtro (também específico do IE) DXImageTransform.Microsoft.Shadow para aplicar sombreamento em cada direção (0º, 90 º, 180 º e 270º). O código é um pouco extenso, mas relativamente simples:

div.sbox {
 -ms-filter: "progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=0,strength=2) progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=90,strength=2) progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=180,strength=2) progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=270,strength=2)";
 filter: progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=0,strength=2) progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=90,strength=2) progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=180,strength=2) progid:DXImageTransform.Microsoft.Shadow(color=#d9d9d9,direction=270,strength=2);
}

Nota 1: Como o código já é específico do IE, recomendamos utilizar o teste <!--[if IE]> para escondê-lo de outros browsers (ver código fonte do passo 3).

Nota 2: Você deve ter reparado que não utilizamos o mesmo hexadecimal de cor do box-shadow (#ccc) - isso porque, por alguma estranha razão, a cor utilizada nesse filtro sempre parece um pouco mais escura no resultado final. Dessa forma acreditamos que o hexadecimal #d9d9d9 trás um resultado melhor.

Dessa forma chegamos a um resultado final onde é praticamente impossível identificar diferenças entre o IE e o Firefox:

Ver Passo 3

E é apenas isso, agora temos caixas sombreadas sem utilizar imagens. Algo que deve ter levado uns 2% das horas que os desenvolvedores da CNN utilizaram na sua solução... Tudo bem que essa solução não irá funcionar em versões mais antigas do Firefox e do Chrome, mas os usuários desses browsers costumam atualizá-los com bastante frequencia. Acredito que temos uma solução que atenda a pelo menos 95% dos browsers usados na web, e com um custo de criação e manutenção muitíssimo inferior a maioria das outras soluções do mercado.

***

Nota final: parte do Passo 3 desse tutorial foi baseado no excelente artigo "Cross-browser drop shadows using pure CSS" de Nick Dunn.

***

Como fazer caixas sombreadas, passos 1 e 2

noreply@blogger.com (raph) — Thu, 27 May 2010 22:30:00 +0000

Outro elemento bastante usado em design elaborados são caixas sombreadas. Vejamos como elas funcionam bem para complementar o design clean da CNN.com:

No entanto, os desenvolvedores da CNN parecem ter tido muito trabalho elaborando esse css. Vejamos como eles fizeram (retirado do css da CNN):

/* SECTION SHADING SPRITE CSS */

.cnn_shdsectbin .cnn_shdcaheader,
.cnn_shdsectbin .cnn_shdcafooter,
.cnn_shdmnfooter,
.cnn_shd755pxfooter,
.cnn_shd755pxheader,
.cnn_shd755px2footer,
.cnn_shd755px2header,
.cnn_shd235pxheader,
.cnn_shd235pxfooter { height:6px;overflow:hidden;background:transparent url('http://i.cdn.turner.com/cnn/.element/img/3.0/global/shade/sprite_shades.gif') 0px -81px no-repeat; }

.cnn_shdsectbin .cnn_shdcafooter { background-position:0px -124px; }

.cnn_shdmnfooter { background-position:0px -174px;clear:both; }

.cnn_shd755pxheader { background-position:0px -252px;height:7px; }
.cnn_shd755pxfooter { background-position:0px -214px;height:7px; }

.cnn_shd755px2header { background-position:0px -342px;height:7px; }
.cnn_shd755px2footer { background-position:0px -299px;height:7px; }

.cnn_shd235pxheader { background-position:0px -424px;height:7px; }
.cnn_shd235pxfooter { background-position:0px -383px;height:7px; }

Reparem como eles chamam a imagem "sprite_shades.gif" contendo diversos tipos de bordas sombreadas e a reposicionam, usando background-position de acordo com a classe e largura do box em que são utilizadas. O resultado final ficou excelente, e é melhor dar load de apenas uma imagem mesmo, por questões de performance... Mas, NOSSA, isso deve ter dado um trabalho infernal!

Felizmente, agora vou lhes ensinar o que os desenvolvedores da CNN aparentemente não sabem (ou mesmo sabendo, preferiram ignorar para justificar mais horas no projeto); Como fazer caixas sombreadas que funcionam em todos os browsers atuais (incluindo o ie6!) e sem usar nenhuma imagem, muito menos essa engenharia de background-position da CNN... Não acredita? Então vamos lá:

Passo 1

Primeiro vamos definir o html de nossa caixa:

<div class="sbox">
 <h3>Só o sombra sabe</h3>
 <p>O mal que se esconde no coração desses geeks que ficam até altas horas da noite na web.</p>
</div>

Agora vamos deixar nossa caixa mais bonitinhas usando um pouco de css:

div.sbox {
 width:482px;
 padding:8px;
 background:#fff;
 border:1px solid #999;
 font-family:georgia,arial,sans-serif;
 font-size:120%;
}
div.sbox h3 {
 padding:0 0 12px 0;
 margin:0;
 font-weight:bold;
 font-size:130%;
}
div.sbox p {
 margin:0 0 8px 0;
}

Definimos a fonte e o espaçamento, assim como uma borda em cinza claro. Nossa caixa está agora um pouco mais interessante:

Ver Passo 1

***

Passo 2

Agora vamos adicionar sombreamento a nossa caixa. Para tal vamos utilizar a tag box-shadow, própria do CSS3, assim como as tags proprietárias -moz-box-shadow e -webkit-box-shadow, que são suportadas, respectivamente, pelo Firefox e o Chrome/Safari:

div.sbox {
 width:482px;
 padding:8px;
 background:#fff;
 border:1px solid #ccc;
 font-family:georgia,arial,sans-serif;
 font-size:120%;
 box-shadow:0 0 4px #ccc;
 -moz-box-shadow:0 0 4px #ccc;
 -webkit-box-shadow:0 0 4px #ccc;
}

Isso nos trará uma caixa sobreada, algo muito valorizado por navegantes de fino trato:

Ver Passo 2

Acho que muita gente está deixando o ceticismo de lado agora... Mas ainda não venci o maior obstáculo - porque nossa caixa ainda não tem sombreado algum no IE.

A seguir, no Passo 3, usaremos alguns filtros específicos do IE para finalizar nossa epopéia e deixar os desenvolvedores da CNN um pouco envergonhados...

***

Javascript links: pop-ups acessíveis

noreply@blogger.com (raph) — Thu, 27 May 2010 20:52:00 +0000

Vocês viram como resolvemos o problema de links com evento de onlick que precisam manter a barra de rolagem do browser no mesmo lugar. Pois bem, utilizando uma solução bem parecida, podemos agora montar um link que abre uma pop-up centralizada na tela e com dimensões definidas através do window.open() do javascript, e que ainda assim permanecerá funcional - abrindo uma nova janela com target="_blank" - para quem estiver usando um browser sem javascript habilitado. Ou seja, teremos um link para abrir pop-ups perfeitamente acessível!

Vejamos como é simples. Primeiro precisamos do script com a função para abrir nossa pop-up centraliada na tela dos usuários que tem javascript habilitado:

<script type="text/javascript">
function PopUpCentralizado(nomepagina, titulopagina, w, h, scroll) {
 var winl = (screen.width - w) / 2;
 var wint = (screen.height - h) / 2;
 winprops = 'height=' + h + ', width = ' + w + ', top = ' + wint + ', left = ' + winl + ', scrollbars = ' + scroll + ', location=no, status=no';
 win = window.open(nomepagina, titulopagina, winprops);
 if (parseInt(navigator.appVersion)  >= 4) {
  win.window.focus();
 }
} 
</script>

Agora vejamos como esse tipo de link é usualmente montado em sites que não tem preocupação com acessibilidade:

<a href="http://www.google.com" onclick="javascript:PopUpCentralizado(this.href, 'pop', '800', '600', 'yes');">Link com pop-up</a>

Rapare que o script pega o atributo href da tag <a> com "this.href". Com alguns pequenos ajustes conseguimos transformar esse link em um link acessível:

<a onclick="javascript:PopUpCentralizado(this.href, 'pop', '800', '600', 'yes'); return false" href="http://www.google.com" target="_blank">Link com pop-up acessível</a>

Utilizando a mesma solução para links com onclick, invertemos a ordem dos atributos na tag <a>, de modo que o onclick venha antes do href, e inserimos o "return false" para o script parar após o evento de clique e o browser não considerar o target="_blank". Dessa forma, quando o usuário tiver javascript habilitado, abrirá a pop-up normalmente, sem uma segunda janela ser chamada. Já quando o usuário por alguma razão não dispor de javascript no browser (seja um browser antigo, um leitor de tela ou browsers de mobiles, etc.) ele continuará abrindo uma nova janela - ou seja, o link continuará funcional e, portanto, acessível.

Ver exemplo

***

Muitas vezes o esforço requerido para esse tipo de ajuste é mínimo, e como o link servirá para browsers com ou sem javascript, esse tipo de "boa prática" deveria ser encorajado em qualquer projeto web, particularmente quando focado em acessibilidade.

O trabalho na era do conhecimento

noreply@blogger.com (raph) — Mon, 24 May 2010 15:14:00 +0000

"Vivemos num mundo onde, pela primeira vez, o conhecimento supera os fatores tradicionais de produção - terra, capital, matéria prima, energia e mão-de-obra - no processo de criação de riqueza. Mesmo em setores econômicos mais tradicionais, como a agricultura, a indústria de bens de consumo e de capital, a competição é cada vez mais baseada na capacidade de transformar informação em conhecimento e conhecimento em valor. Informação, conhecimento, criatividade e inovação são, assim, ingredientes básicos para todas as organizações que atuam nesta nova sociedade, sejam elas públicas ou privadas.

Mas, na prática, o que isto significa? Como criar novos modelos de negócio? E mais difícil ainda, como torná-los realidade, fazendo-os gerar resultados concretos? Que profissionais precisamos formar para fazer isto acontecer? Como devemos agir, no nosso dia-a-dia, para ajudar a construir esta sociedade do conhecimento?"

É com o texto acima que Marcos Cavalcanti - coordenador do Crie (Centro de Referência em Inteligência Empresarial) da COPPE/UFRJ - abre o primeiro post de seu excelente blog "Inteligência Empresarial" do O Globo Online.

Na palestra de aproximadamente 120 minutos que ele deu para o programa Café Filosófico da TV Cultura (em 18/09/09), ele destila algumas dessas respostas, enquanto trafega pelas eras agrícola e industrial, explicando o porque de já estarmos efetivamente em uma transição de eras, rumo a era do conhecimento - onde o foco da competição por recursos se desloca para a cooperatividade e compartilhamento do conhecimento.

Somente um pensador da gestão empresarial com certa sensibilidade poderia nos brindar com duas frases tão emblemáticas (e que dão o que pensar) enquanto fala sobre os rumos da sociedade moderna:

"O lucro é o oxigênio da empresa, mas viver é muito mais do que respirar." - Peter Drucker

"Navegar é preciso, viver não é preciso." - Fernando Pessoa

Ver palestra na íntegra

***

Crédito da imagem: Cena de "Tempos Modernos" (filme de Charles Chaplin, uma sátira da era industrial)

Javascript links: problema do "onclick" e rolagem da página

noreply@blogger.com (raph) — Thu, 13 May 2010 22:05:00 +0000

Uma das formas mais tradicionais de se inserir chamadas de javascript em um site é através do evento de "onclick" dos links (tags <a>). O motivo desse pequeno tutorial sobre o assunto é mostrar como coisas tão simples podem ser feitas de várias formas, e como nem sempre pensamos em usar a melhor forma possível.

Vamos considerar a forma mais usual de links com "onclick" que vemos por aí:

<a href="#" onclick="javascript:alert('Hello world!');">Clique aqui</a>

O que é chamado no "onclick" pode ser qualquer outra função mais complexa, não é isso que estou querendo discutir aqui. O problema está no atrubuto "href" que permanece com o valor "#". Como todos sabem isso fará com que a barra de scroll do browser retorne ao topo da página, caso estejamos clicando em um link somente após descer um pouco nosso scroll.

Isso é um problema irritante para a grande maioria dos usuários. O "problema desse problema" é que ele não impede a navegação nem causa qualquer outro grande dano a funcionalidade do site, ele apenas irrita... E hoje em dia, usuários irritados vão pensar duzentas e uma vezes em retornar ao seu site.

Agora gostaria de mostrar 3 soluções para esse problema, e depois descrever os prós e os contras de cada uma delas:

Solução 1: manter-se no mesmo lugar

Com essa solução inserimos um ID (#stay) em torno do link (também poderia ser <a name="stay"></a>) e apontamos o "href" do link para ele:

<span id="stay"><a href="#stay" onclick="javascript:alert('Hello world!');">Clique aqui</a></span>

Prós
- É a solução mais simples para um único link do tipo na página.

Contras
- Precisamos criar um ID específico para cada link, pois se dois IDs iguais aparecerem na mesma página, o link irá apontar para o primeiro deles (afora isso, obviamnete seu html não irá validar). Dessa forma não é uma boa solução para quando temos diversos links com "onclick" na mesma página.

Solução 2: usar javascript:undefined no "href"

Com essa solução inserimos no "href" um comando de javascript que na verdade não causa efeito algum:

<a href="javascript:undefined;" onclick="javascript:alert('Hello world!');" onmouseover="javascript:window.status='Este link abre um javascript'; return true" onmouseout="javascript:window.status=''; return true">Clique aqui</a>

Prós
- É uma solução que resolve o problema independente do número de links com "onclick" usados na mesma página.
- Parece ser a solução mais usada na web.

Contras
- A mensagem de status do browser vai mostrar exatamente "javascript:underfined;" ao invés de uma url usual. Para sites com público leigo, isso pode assustar potencialmente, levando a crer que existe "alguma coisa estranha ali naquele link" - isto é, se é que os usuários vão se preocupar com a mensagem de status do browser.
- No exemplo temos inclusive uma tentativa de contornar o problema com mais um pouco de javascript, a questão é que a maioria dos browsers modernos vem configurado para não considerar esse tipo de script de alteração da mensagem de status, por óbvias questões de segurança. Portanto, não parece haver solução para isso.

Solução 3: inserir o "onclick" com return false

Com essa solução informamos ao browser para parar de rodar eventos do link no o "onclick", evitando que o valor do "href" nos leve a qualquer lugar:

<a href="#" onclick="javascript:alert('Hello world!'); return false">Clique aqui</a>

Prós
- É uma solução que resolve o problema independente do número de links com "onclick" usados na mesma página.
- Na minha opnião é a melhor solução.

Contras
- Apesar de simples, não podemos esquecer de utilizar o return false.

Ver exemplos

***

É isso, espero que esse pequeno tutorial tenha lhes ajudado a resolver esse problema em específico; e também a sempre considerar que as soluções usuais e mais usadas nem sempre são as melhores soluções...

Como fazer botões, passos 5 e 6

noreply@blogger.com (raph) — Mon, 10 May 2010 21:32:00 +0000

continuando do Passo 4

Passo 5

Mesmo indo além do que o IE pode oferecer (ainda que se considerando o uso de JavaScript), ainda podemos incrementar o layout de nosso botão para usuários do Firefox e do Chrome. Esses browsers já conseguem ler o atributo de CSS3 box-shadow, ainda que utilizando tags-proprietárias (exatamente como com o border-radius). Utilizando esse atributo iremos agora aplicar um efeito de sombra ao evento de rollover de nosso botão:

div.btns a {
 font-size:12px;
 font-family:helvetica,arial,sans-serif;
 font-weight:bold;
 letter-spacing:1px;
 padding:5px 12px;
 color:#fff;
 background:#3792b3 url(img/bt_bg.png) repeat-x 0 50%;
 text-decoration:none;
 border:1px solid #3792b3;
 border-radius:8px;
 -moz-border-radius:8px;
 -webkit-border-radius:8px;
}
div.btns a:hover {
 background-color:#a14141;
 border-color:#a14141;
 box-shadow:2px 2px 4px #999;
 -moz-box-shadow:2px 2px 4px #999;
 -webkit-box-shadow:2px 2px 4px #999;
}

Em nosso evento de rollover, estamos aplicando um efeito de sombreamento ao botão na cor #999 (cinza claro). Este efeito se estende a 2px abaixo e 2px para direita do botão (valores negativos também poderiam ser usados aqui) e aplica um efeito de "blur" de 4px. Para quem costuma usar efeitos parecidos em programas como Photoshop ou Macromedia, esses parâmetros são de simples entendimento.

De fato, é quase como se estivéssemos editando o css com um programa de edição de imagens... Vejam como fica bem interessante este efeito nos browsers mais inteligentes (qualquer coisa além do IE é "mais inteligente"):

Você não deve se sentir desencorajado em usar a "degradação com beleza". Se seu cliente perguntar porque você se atraveu a ignorar o IE e aplicar sombreamento de rollover somente nesses browsers de geeks, informe-o que sites como YouTube.com (repare no rollover dos botões, como "Gostei") já fazem o mesmo. Deve ser o suficiente...

Antes do passo final, vamos chegar ao ápice do perfeccionismo nerd e utilizar um atributo exclusivo do webkit (Chrome/Safari) e que não consta sequer no CSS3, mas que é absolutamente sensacional. O -webkit-transition faz um efeito de transição entre alguma cor ou cor de fundo, transformando gradualmente a cor padrão na cor da classe de rollover. É algo que na prática é muito parecido com efeitos em flash, a diferença é que trata-se de puro CSS (embora, por enquanto, proprietário do webkit):

div.btns a {
 font-size:12px;
 font-family:helvetica,arial,sans-serif;
 font-weight:bold;
 letter-spacing:1px;
 padding:5px 12px;
 color:#fff;
 background:#3792b3 url(img/bt_bg.png) repeat-x 0 50%;
 text-decoration:none;
 border:1px solid #3792b3;
 border-radius:8px;
 -moz-border-radius:8px;
 -webkit-border-radius:8px;
 -webkit-transition:background-color .3s linear;
}

Estamos informando ao Chrome que a transição da cor de fundo (background-color) deve ser linear e durar 3 décimos de segundo (repare que aplicamos a tag-proprietária na classe "a", e não em "a:hover" - é assim mesmo). Não vou criar um gif animado ou vídeo apenas para te mostrar quão interessante ficou nosso rollover de botão, para ver basta abrir o link abaixo com o Chrome ou Safari:

Ver Passo 5

Embora apenas os felizardos que navegam com o Chrome possam ver esse efeito de rollover, é algo que não custa quase nada adicionar, e que não deverá deixar nenhum cliente de cabelo em pé...

***

Passo 6

Chegamos ao passo final. Nesse passo não quero adicionar mais nenhum layout ou efeito com css. Gostaria apenas de demonstrar o quão simples é editar um botão construído dessa forma.

Vamos agora mudar nosso código html para inserir um texto bem mais extenso ao nosso botão:

<div class="btns png">
    <a href="#">Cadastrar-se na promoção e concorrer a muitos prêmios</a>
</div>

Agora, em nosso css, vamos aumentar bastante o tamanho da fonte (lembre-se que isso também é um teste comum de acessibilidade) e mudar a cor de fundo do botão para verde:

div.btns a {
 font-size:26px;
 font-family:helvetica,arial,sans-serif;
 font-weight:bold;
 letter-spacing:1px;
 padding:5px 12px;
 color:#fff;
 background:#6c9441 url(img/bt_bg.png) repeat-x 0 50%;
 text-decoration:none;
 border:1px solid #6c9441;
 border-radius:8px;
 -moz-border-radius:8px;
 -webkit-border-radius:8px;
 -webkit-transition:background-color .3s linear;
}

Pronto, em alguns segundos, temos um botão comum de pesquisa transformado em um gigantesco botão de cadastro para a última promoção de noso site (certamente o pessoal de marketing pensaria num título melhor para esse botão):

Acredito que para a imensa maioria dos portais de conteúdo, esse método se mostrará muito mais prático e elegante do que contratar um designer exclusivo para produzir milhares de botões diferentes. Tudo bem que isso pode tirar o emprego do designer, mas acredito que se ele ler este tutorial, nem irá se importar :)

Ver Passo 6

***

Nota final: parte desse tutorial foi diretamente inspirada no capítulo 2 do excelente livro de Dan Cederholm: "Hancrafted CSS".

***

Como fazer botões, passos 3 e 4

noreply@blogger.com (raph) — Mon, 10 May 2010 20:33:00 +0000

continuando do Passo 2

Passo 3

Temos inúmeros scripts na web para tratar de imagens PNG no IE6, para nosso exemplo entretando optei pela solução de Drew Diller, chamada "DD_belatedPNG".

Inicialmente precisaremos adicionar uma classe (".png") em nosso html:

<div class="btns png">
    <a href="#">Pesquisar</a>
</div>

Com essa classe lá, bastará chamarmos o arquivo .js de nosso amigo Drew Diller (você pode baixá-lo aqui) e declararmos que em tags com a classe .png, ou em links dentro dessas tags, o script deverá rodar. Para termos certeza de que isso só será chamado no IE6, envolveremos o código com o famoso teste "if IE" dentro de comentários (porque será que a Microsoft pensou nisso?):

<!--[if IE 6]>
<script type="text/javascript" src="../pngfix.ie6.min.js"></script>
<script type="text/javascript">DD_belatedPNG.fix('.png, .png a');</script>
<![endif]-->

Isso pode entrar em qualquer parte do código, mas é melhor que entre junto com os outros scripts dentro da tag <head>.

Bem, se tudo correu bem, bastará cruzar os dedos e abrir nosso botão no IE6...

Além disso, vamos aproveitar e adicionar bordas arredondadas ao nosso botão! Isso mesmo, hoje em dia isso pode ser feito somente por CSS, embora tenhamos de usar algumas tags-proprietárias de cada browser. Vamos ao CSS adicional:

div.btns a {
 font-size:12px;
 font-family:helvetica,arial,sans-serif;
 font-weight:bold;
 letter-spacing:1px;
 padding:5px 12px;
 color:#fff;
 background:#3792b3 url(img/bt_bg.png) repeat-x 0 50%;
 text-decoration:none;
 border:1px solid #3792b3;
 border-radius:8px;
 -moz-border-radius:8px;
 -webkit-border-radius:8px;
}
div.btns a:hover {
 background-color:#a14141;
 border-color:#a14141;
}

Reparem que aplicamos uma borda ao botão, borda esta que muda de cor no rollover; Além disso, aplicamos 8px de borda arredondada ao botão com 3 declarações diferentes: border-radius é o padrão do CSS3, mas este ainda não foi implementado por quase nenhum browser...

Felizmente, porém, tanto o Firefox quanto o Chrome (e o Safari, no qual é baseado) tem tags-proprietárias que realizam o mesmo efeito: -moz-border-radius (Firefox) e -webkit-border-radius (Chrome/Safari). Tenha em mente que usando essas tags proprietárias intencionalmente, seu css não passará por validadores sem erros, mas acredito que esse seja um pequeníssimo preço a pagar.

Agora teremos um botão bem mais interessante:

Ver Passo 3

Isto é, exceto no IE (é claro)... O que nos leva a uma outra solução com JavaScript no Passo 4...

***

Passo 4

Você devia estar achando que esse tutorial estava interessante, mas que como vários outros tutoriais interessantes de css, esbarraria no famigerado IE, e portanto não poderia ainda ser utiliado em seus projetos web. Afinal, como vimos, mesmo o Twitter deixa seu visual "quadrado" para os usuários de IE.

Isso é chamado de "degradação com beleza", uma forma esforçada de tentar definir o conceito corrente de que, se um design não pode parecer igual em todos os browsers, que ao menos façamos com que nos browsers com menor capacidade (leia-se: IE) ele ainda fique o mais interessante possível.

Tudo isso é muito bonito e revigorante, mas não servirá de nada se o seu cliente simplesmente exigir que o IE mostre os malditos botões com bordas arredondadas!

Bem, felizmente nosso querido amigo Drew Diller também solucionou esse problema com míseros 9kb de JavaScript. Sua solução foi entitulada "DD_roundies" (os programadores geralmente são bem melhores com programação, se comparado a criatividade para nomes e títulos).

Para fazer as bordas funcionarem no IE bastará chamar o arquivo .js de Drew Diller em nosso código (você pode baixá-lo aqui):

<!-- faz border-radius funcionar no IE, depois ajusta CSS no IE8 -->
<script type="text/javascript" src="js/ie.border.radius.min.js"></script>
<script type="text/javascript">
    //uso: DD_roundies.addRule('.sua-classe', #); onde # = border-radius
 DD_roundies.addRule('div.btns a', 8);
</script>
<!--[if IE 8]>
<style type="text/css" media="screen">
div.btns a {border:0;background-image:url(img/bt_bg.png) !important;padding-bottom:7px;}
</style>
<![endif]-->

Conforme consta nos comentários (é sempre bom comentar quando usamos código "fora do escopo tradicional"), estamos aplicando 8px de border-radius nos links (tags <a>) dentro de um <div class="btns">.

Como a Microsoft se esforça para infernizar nossa vida, devo adiantar que apenas no IE8 econtraremos um problema caso utilizemos bordas em nosso botão. Por isso utilizamos um teste condicional dentro de comentários para corrigir o problema apenas no IE8... Não me pergunte porque, mas mesmo com border:0; o botão continua tendo bordas. Bem, talvez o script de nosso amigo Drew Diller não seja infalível, mas já foi de grande ajuda até aqui!

O layout de nosso botão não mudou em nada, mas agora ele aparecerá com bordas arredondadas mesmo no IE. Pronto, pense nas possibilidades!

Ver Passo 4

***

A seguir, no Passo 5, aplicaremos mais alguns efeitos decorativos. Infelizmente desta vez não há nada que poderemos fazer quanto ao IE...

***

Como fazer botões, passos 1 e 2

noreply@blogger.com (raph) — Mon, 10 May 2010 19:35:00 +0000

Um dos elementos mais usados no design para web são os botões. Até pouco tempo atrás botões mais elaborados eram criados diretamente pelo designer no photoshop ou programa similar, e já trazia o texto "embutido" na imagem. Algo como:

No entanto, hoje em dia já é possível criar botões com design elaborado, efeitos de rollover e bordas arredondadas apenas com CSS (e algum script para o IE, mas veremos isso em breve). Você pode achar que o botão "Join Today" (junte-se hoje) da home do Twitter.com é uma imagem - senão com texto "embutido", no mínimo com imagens de fundo com bordas arredondadas:

Mas não! Trata-se de um botão criado apenas com CSS, a única imagem existente é um PNG com alguma transparência que dá o efeito de degradê no fundo. Porém, esse tipo de formato de construção de botões permite que editemos o texto, as cores de fundo e até mesmo a curvatura das bordas facilmente - apenas editando CSS. Além disso, acaso o usuário aumente a fonte, o botão irá se ajustar automaticamente (ponto para acessibilidade).

Caso você já tenha testado a home do Twitter em vários browsers, deve ter percebido que no IE não temos bordas arredondadas pela página - incluindo o bortão de que falei... No entanto, com um pouco de JavaScript é possível deixar tudo arredendado mesmo no IE... Vamos ver como se faz.

Passo 1

Primeiro vamos definir o html de nosso botão (no caso, um exemplo comum, o botão de "Pesquisar"):

<div class="btns">
    <a href="#">Pesquisar</a>
</div>

Agora vamos definir o estilo básico inicial usando um pouco de css:

div.btns a {
 font-size:12px;
 font-family:helvetica,arial,sans-serif;
 font-weight:bold;
 letter-spacing:1px;
 padding:5px 12px;
 color:#fff;
 background:#3792b3;
 text-decoration:none;
}
div.btns a:hover {
 background-color:#a14141;
}

Definimos a fonte e o espaçamento, assim como a cor de fundo (azul) e o efeito de rollover, que muda a cor de fundo para vermelho. Nosso botão deverá ser algo simples por agora:

Ver Passo 1

***

Passo 2

Agora vamos adicionar uma imagem de fundo ao botão, para dar um efeito interessante ao fundo. Essa imagem é um PNG simples com 50x200 pixels, onde na metade superior temos um box com fundo branco e transparência em 15%. Isso permite que o efeito seja aplicado sobre a cor de fundo já defunida no CSS - e dessa forma acaso mudemos a cor de fundo (como no rollover) o efeito irá permanecer, sem que tenhamos de criar múltiplas imagens para o mesmo botão. Veja abaixo uma imagem dessa imagem PNG sendo criada no Fireworks:

Com a imagem criada, devemos atualizar nosso CSS (repare que alinhamos ela a esquerda e ao centro vertical [0 50%], e a fizemos se repetir indefinidamente no eixo horizontal [repeat-x]):

div.btns a {
 font-size:12px;
 font-family:helvetica,arial,sans-serif;
 font-weight:bold;
 letter-spacing:1px;
 padding:5px 12px;
 color:#fff;
 background:#3792b3 url(img/bt_bg.png) repeat-x 0 50%;
 text-decoration:none;
}

Isso nos trará um botão mais interessante:

Ver Passo 2

***

Porém, como muitos devem saber, imagens PNG com transparência não "se comportam muito bem" no IE6 e inferiores...

A seguir, no Passo 3, usaremos um pouco de JavaScript para corrigir a rebeldia de nosso querido IE6...

***

A máquina somos nós

noreply@blogger.com (raph) — Mon, 10 May 2010 13:25:00 +0000

Muitos radicais condenam a globalização, mas fato é que hoje em dia não temos mais como voltar atrás. A evolução anda somente em uma direção... Sempre a frente:

Tradução e adaptação do vídeo "The Machine is Us/ing Us", de Michael Wesch, Antropólogo americano.

» Veja o vídeo original (em inglês)

Protótipos de projetos com Lumis

noreply@blogger.com (raph) — Sat, 08 May 2010 04:11:00 +0000

Este documento visa expor uma metodologia específica para a criação de protótipos de projetos para o Lumis Portal Suite (LPS, usado em servidores Microsoft) e para o Lumis Portal Java (LPJ, usado em servidores Java), focando no desenvolvimento de protótipos HTML prontos para serem usados no Lumis, com o mínimo ajuste de código possível.

Continue a leitura do documento abaixo, no Scribd: