A ver a categoria “HTML, JS & CSS”

Categoria sobre web design tradicional e os seus inúmeros acidentes de percurso, perigos vários e as poucas e pequenas pérolas.

12

LikeFriendsNo ano passado, por volta desta altura, lancei um pequeno brinquedo social, o LikeFriends. Depois do lançamento, nunca mais me preocupei com ele.

De alguns meses para cá, começaram-me a chegar queixas que não estaria a funcionar correctamente – não mostrava quaisquer likes em comum. Infelizmente, não tive vida pessoal nem profissional que me deixasse abordar este problema, para além da confirmação que, sim, estava partido.

Para quem não se interessa por questões técnicas, a única coisa que interessa é esta: está de novo a funcionar. Ide brincar. Quem estiver interessado, que fique por cá mais alguns minutos (e depois pode ir brincar).

LikeFriendsPronto, mais um projecto lançado, mais um making of para podermos partir para outra. Não vou voltar a passar pelas coisas do costume (sim, voltei a usar a Yii, voltei a usar SASS e Compass) e também não vou voltar a falar do jogo do galo, nem da racionalização matemática por trás do LikeFriends.

Vamos lá.

Fluxograma de estratégiaDurante o desenvolvimento do LikeFriends, fui fortemente coagido a desenvolver um passatempo pela beta-tester, que, incidentalmente, é também minha esposa. A escolha recaiu sobre o jogo do galo, e o código foi colocado no GitHub. Este post é uma tradução do README que acompanha o meu repositório TicTacToeJS, no GitHub.

Existem três maneiras de fazer uma AI de jogo imbatível:

  1. Processar cada jogada possível adiantadamente e jogar pela linha de maior sucesso a cada passo – isto é um método de força bruta;
  2. Implementar uma rede neuronal – isto vai começar bastante palerma, mas depois de alguns milhares de jogos deverá ser imbatível;
  3. Implementar uma solução heurística, fazendo-a jogar como um especialista humano.

O jogo do galo é um fortíssimo candidato a uma solução de força bruta: o número total de jogadas é de apenas 9!, ou 362.880; de facto, seriam muito menos, visto que a maioria das jogadas poderia ser obtida por rotação do tabuleiro de jogo. No entanto, não existe grande "I" nesta AI...

A solução por rede neuronal é bastante divertida, e é usada frequentemente em cenários complexos, desde que alguém tenha o tempo (ou os jogos automatizados) para treinar a rede. Aparte o código da rede neuronal em si (que poderia ser usada para paletes de outros problemas), esta solução seria a mais pequena ao nível do código.

A solução heurística é a mais difícil de implementar para a maioria dos jogos. Implica criar um conjunto de regras a seguir, para cada situação possível, da forma mais compacta possível. De novo, o jogo do galo é propício a este tipo de solução, porquanto apenas três jogadas, no máximo, podem ser problemáticas; a quarta e a eventual quinta jogada são feitas para ganhar ou para empatar.

Esta foi a solução que implementei.

SASSPara finalizar esta série sobre o mjamado.com, falta falar sobre o que é, para mim, a tecnologia mais útil que aprendi no último ano: SASS, um superset da linguagem CSS, juntamente com Compass, uma biblioteca de mixins para usar com SASS (mixins é o termo convencionado para referir o que não são mais que pequenas funções).

Não vou alongar-me sobre todas as vantagens do SASS (estão aí os links, é dar uma voltinha), mas vou focar quatro pontos que me são caros.

Antes de mais nada, um pedido de desculpas às 10 pessoas que visitaram o mjamado.com com o Internet Explorer 8 até sexta-feira: como estou a usar as novas tags semânticas do HTML5, devem ter ficado a olhar para um grande espaço de... nada. Acontece que os IE abaixo do 9 não reconhecem as novas tags e, pior do que isso, não lhe dão sequer um estilo básico (podiam definir todas as tags desconhecidas como block, por exemplo); para adicionar insulto à injúria, definir um estilo na CSS também não chega, porque as tags nem são inseridas na DOM.

Quando publiquei esqueci-me desse problema, mas já está controlado, através do HTML5 Shiv (um excelente pedaço de história sobre a evolução desta solução pode ser encontrada aqui).

Com isso fora do caminho, existiam dois grandes problemas, que eu tinha debaixo de olho desde o início.

O primeiro era relacionado com as CSS Transitions, das quais já falei aqui. Desde o início do projecto que assumi a opção da degradação graciosa, que o transforma num não-problema. Quem usa o IE não vê a transição entre os dois estados, mas não perde nenhuma de experiência intrínseca, tendo acesso a ambos; só que a transição é abrupta. Como já disse nesse post, é relativamente fácil forçar o comportamente consistente com meia dúzia de linhas JS, mas não compensa o esforço; sobretudo, à luz do lançamento próximo do IE10.

O outro era muito mais bicudo e está relacionado com a conjugação de gradientes CSS e cantos redondos. Aliás, nem sequer é a primeira vez que os cantos redondos me vêm morder no rabo. Desde essa altura, o IE9 passou a suportar cantos redondos e até o Chrome, culpado por esse post, melhorou bastante o cálculo do corte do background.

Apesar de não suportar gradientes CSS, o IE (para aí desde o 6) suporta gradientes lineares definidos através de filtros DirectX. É uma questão de incluir esses filtros, e o IE, não reconhecendo a sintaxe CSS3 dos gradientes, irá usá-los. Porreiro, certo? O problema é quando se atiram os cantos redondos para cima.

Continuando com coisas-que-ainda-não-tinha-experimentado-a-sério, usei no mjamado.com duas web fonts do directório da Google (Cantata One para os títulos e Imprima para corpo). Já tinha usado uma ou outra nalguns projectos comerciais (e por "usado" entenda-se que a empresa tinha usado – o design não é exactamente a minha praia), mas queria ver "ao perto" o que se podia fazer com isto.

O processo é trivial e croquetes, mais ainda se aceitarmos os métodos mais simples que a própria Google recomenda. Só embati numa pequena irritação, que ainda por cima não tem solução – ironicamente, afecta outro produto da Google, o Chrome, mas apenas em Windows.

O problema é este:

Ao construir o mjamado.com, evitei ao máximo usar animações por Javascript, preferindo usar CSS Transitions. O motivo óbvio é o desempenho: uma animação ser controlada pelo renderer interno dos browsers será sempre mais rápida e leve do que pelo motor de JS.

Um motivo menos claro é a separação de responsabilidades: cabe ao HTML mostrar os dados, ao JS controlar as acções sobre esses dados (acções apresentacionais - qualquer acção que altere os dados deve ser server side) e às CSS controlar como são apresentados os dados. Uma transição entre visualizações de dados é, claramente, uma responsabilidade apresentacional – logo, uma responsabilidade de CSS.

As CSS Transitions são novinhas em folha; pertencem à especificação CSS3, ainda estão em estado de working draft na W3C, mas o suporte já é sólido: segundo o caniuse.com, e corroborado pelos meus testes, apenas o Opera Mini, usado nalguns telemóveis menos potentes, e o (sem surpresa) Internet Explorer (até à versão actual, a 9) não as suportam. Todos os outros browsers tem suporte, pelo menos, há 5 gerações.

As transições funcionam de um estilo para outro, seja como for que esse estilo varie (por estados, mudança de classe ou id, directo ou indirecto), e podem animar qualquer valor passível de ser interpretado como numérico – cores, por exemplo, podem ser declaradas como nomes, mas têm um valor intrínseco numérico. São parametrizadas por quatro valores: a propriedade a animar, a duração, o nome de uma função de animação e o tempo de atraso de início de animação.

Num mini-projecto que estou a preparar em HTML5 e CSS3, estou a usar cantos redondos feitos por CSS. O código para os fazer (ainda) é com os prefixos dos vários browsers e é muito simples:

/* standards */
border-radius: 1em 0.25em 2em 2em;
/* para o Firefox */
-moz-border-radius: 1em 0.25em 2em 2em;
/* para o Safari e Chrome */
-webkit-border-radius: 1em 0.25em 2em 2em;
/* para o Opera */
-o-border-radius: 1em 0.25em 2em 2em;

Nem preciso dizer que nenhuma versão corrente do Internet Explorer suporta isto, certo?

Só para que vejam o efeito, aqui fica uma bonita (cof, cof) caixa com este estilo aplicado:

Ainda a propósito do Codebits 2010, estava sentado numa mesa com o Pedro Cavaco, que estava a participar na competição de programação com um jogo para smartphones: Android e iPhone.

Estávamos a conversar sobre isso e eu não estava a ver uma forma fácil de fazer isso para duas plataformas ao mesmo tempo, o que se devia apenas a nunca ter tomado muita atenção a essa área...

O Pedro estava a usar uma ferramenta que compila para as duas plataformas ao mesmo tempo, usando a linguagem Lua. Posteriormente, não consegui encontrar essa framework, mas encontrei várias outras para o mesmo efeito.

A maior parte delas suporta apenas duas plataformas (Android e iPhone) e através do uso de um componente web view. Qualquer um dos factores isolados já é mau, mas seria suportável. Em conjunto, não serve para mim.

Acabei por ficar com, apenas, duas das frameworks que encontrei, a Rhomobile Rhodes e a Appcelerator Titanium, para testar.

Esta posta é pouco mais que um repositório, mais para mim do que para o mundo. Posto isto…

Apresentações com conteúdos que quero explorar em mais profundidade, com aplicações práticas para o meu trabalho ou para projectos pessoais:

Para além das acima, a apresentação How to build your own Quadrocopter (vídeo e apresentação), por Lenz Grimmer, não me ensinou nada de novo, mas é um projecto que comecei no final do verão, para se ir fazendo.

Finalmente, a Dr. © - How I Learned to Stop Worrying and Love Fair-Use Licensing (vídeo e apresentação), pelo já acima nomeado André Luís, reflecte a minha posição em relação a licenciamento (é só visitar a licença aqui do DreamsInCode).

Comentários 3 comentários Continuar a ler Continuar a ler »
12
 Categorias
 Arquivo
 Projectos em Destaque
 Últimas Postas no Blog
 Últimos Comentários do Blog