NonsenseBB

Hoje em conversa com um colega meu comecei a descrever a abordagem que tenho tomado quando procuro desenvolver um website em HTML, CSS e Javascript e pensei que se calhar era uma boa ideia partilhar aqui a forma como o faço.

O objectivo é simples: criar pequenos sites que funcionam desde um telemóvel até um Desktop com ou sem Javascript activo e tentando suportar tanto quanto possível browsers ligeiramente mais antigos como o IE8 ou o Firefox 3.6.

No entanto sou o primeiro a admitir que esta abordagem não serve para todos os casos mas na minha modesta opinião é um bom objectivo para quem tem sites mais pequenos e quer dar aquela pequena dedicação extra que permite cobrir sem grande trabalho extra uma grande fatia dos potenciais visitantes.

Se tiverem dicas ou sugestões não se esqueçam de as deixar nos comentários mas antes disso vamos à minha abordagem ao problema.

Demorou mas consegui. Finalmente posso dizer que tenho uma aplicação escrita em Node.JS a funcionar e disponível para quem a quiser experimentar. Para além da utilização de CouchDB para guardar os dados (como já fazia há algum tempo na versão anterior escrita em PHP) posso também atirar para a fogueira mais umas buzzwordzitas uma vez que em vez de usar grandes bibliotecas como o jQuery e outros acabei por ficar pelo Ender, uma ferramenta que permite conjugar as mais variadas micro-frameworks de Javascript num único pacote.

Outro pormenor curioso são as animações. A biblioteca que estou a usar, a morpheus, baseia-se numa API recente disponivel nos mais diversos browsers chamada requestAnimationFrame. O que é que tem de especial esta API? A API serve para pedir aos browsers quando é que eles estão disponíveis para fazer a próxima frame da animação o que significa que por exemplo quando o browser se encontra minimizado ou o CPU sobrecarregado o browser pode escolher não disponibilizar tempo para processar a animação e esta passa logo para o final poupando ciclos de CPU e consequentemente energia.

Isto tem no entanto alguns problemas: a API ainda não está em muito bom estado e consequentemente é normal logo após carregar a página serem notórios os saltos devido ao numero reduzido de frames disponibilizadas pelo browser (no chrome cheguei ao ridículo de ver apenas 3 frames disponíveis numa animação). Curiosamente onde as animações correm melhor é em Internet Explorer 9. Sim eu sei, o inferno deve ter acabado de congelar.

No entanto nem tudo está concluído. Neste relançamento ficaram de fora ainda algumas funcionalidades que tinha programadas como o uso da API de historia do HTML5 para permitir navegar no site sem ter de refrescar as páginas e também melhorar o suporte a tablets como o iPad ou as muitas baseadas em Android Honeycomb como a Galaxy Tab ou a Asus Transformer. Isto sem mencionar o facto de ser preciso colocar um botão do Google Plus mas isso é só quando a API finalmente sair.

Para já fica só o reescrever da grande maioria do código que está agora muito mais pequeno e versátil. Uma das grandes diferenças que devem ser imediatamente notórias é na sincronização com o servidor que agora não só efectivamente funciona em mais do que um browser cumprindo o seu propósito (sim, estava assim tão mal) como não tem tantos popups irritantes sempre que ocorre e deve ser rápida o suficiente para nunca serem apanhados desprevenidos por fecharem o browser antes dela acontecer.

AH e mais importante que tudo isto é a mudança de endereço.

LINK: http://anime.nonsensebb.com

Qualquer critica, duvida ou sugestão façam favor de dizer de vossa justiça nos comentários.

VIM Solarized

Desde há uns anos para cá que descobri que sou estupidamente mais produtivo quando uso uma linha de comandos para a maioria do que faço em vez de interfaces gráficos. O corolário dessa conclusão é que Windows pura e simplesmente não serve porque não tem nada que se aproxime à quantidade gigantesca de ferramentas disponíveis num qualquer clone de Unix como é o caso de Linux, BSD ou até mesmo Mac OS-X.

A minha escolha, como muitos certamente sabem, recai sobre Linux e o meu editor de texto de eleição é tornou-se lentamente o vim. Eu sou fã de ferramentas como o Gnome-Do/Quicksilver que me permitem escrever o que quero fazer em vez de utilizar ícones do interface gráfico ou atalhos complicados portanto o venerável editor de texto é uma escolha natural.

Mas uma das coisas boas do vim é que é altamente personalizavel e extensível e eu aproveitei esse facto para lhe adicionar algumas funcionalidades que me ajudam a escrever código javascript.

Neste post vou explicar os passos para reproduzir o meu ambiente de trabalho em html/css/javascript no vim.

Há uns tempos atrás decidi colocar-me a brincar um pouco com o editor de imagem, depois com o editor de texto e ficheiros html/css e no fim javascript e php para uns últimos pozinhos resultando num pequeno website onde listo as séries de cada temporada de animação japonesa, uma timeline de animes. Dava jeito por motivos que na altura citei e deu também para dar um pouco de liberdade à minha criatividade no que toca ao “design de sítios web”.

Pois bem a verdade é que a brincar a brincar e sem grandes tentativas de promoção a coisa até pegou e transformou-se na 2ª/3ª pagina mais visitada do meu site com a grande generalidade das visitas a virem de pesquisas do google por isso achei que era boa ideia polir um pouco as arestas ao bicho e é disso mesmo que venho aqui falar hoje.

Bem este post vai servir não só como uma forma rápida de apanhar algumas opiniões como também para ficar com uma nota para mim próprio sobre esta ideia.

Para o meu TV Wall estou a tentar ir o mais longe possível no juntar da API da aplicação com o que efectivamente é visível para os utilizadores e parte disso passa por tentar ter praticamente o mesmo esquema de URLs tanto para o browser como para a API utilizada pelos mais diversos clientes (quer seja a própria aplicação web em javascript ou outra qualquer hipotética aplicação nativa). Isto faz com que os endereços se tornem por exemplo em algo como /show/house para aceder, neste caso, à pagina associada à série House.

Agora o desafio: como fazer o mesmo endereço devolver HTML para um browser mas JSON (ou XML ou qualquer outro formato de dados) para uma aplicação? A minha resposta passa pelos cabeçalhos HTTP, mais concretamente pelo cabeçalho ACCEPT que ao anunciar que aceita um determinado tipo de dados permite-me devolver-lhe esse tipo em particular deixando o HTML normal para fallback.

Claro que eu posso já começar a ver os problemas associados a esta abordagem: e se surgir um browser que manda um cabeçalho a dizer aceitar application/json quando o que o utilizador quer mesmo receber é a versão HTML? E se um cliente enviar no cabeçalho que aceita tanto JSON como XML? Qual dos dois devolver? Sim, isto são tudo questões muito validas e é por isso mesmo que coloquei esta entrada no meu blog. Opiniões?

E é já amanhã que começa a quarta edição do Sapo Codebits.

Pizza, Red Bull, muito código no concurso de programação em 48h, quiz show (que planeio vencer desta vez) e muitos workshops e apresentações para aprender de tudo um pouco relacionado com tecnologia em geral e web em particular.

É o “Rock in Rio geek” como alguém disse no twitter e eu vou lá estar a dar o meu melhor para aproveitar novamente ao máximo tudo o que se passa no evento. Em edições passadas fui evangelizado para o uso de microformatos ou para a fantástica ideia de usar javascript no servidor e desta feita espero ver ainda mais buzz em torno desta ultima pois a meu ver é sem sombra de duvidas o futuro da web.

Vão dando noticias no twitter e se me virem por lá não se esqueçam de pedir um autocolante do TV Wall. 😉

Bem isto realmente pode não parecer muito emocionante e até excessivamente lento para a maioria mas a minha vida tem andado tão caótica ultimamente que mesmo este pequeno avanço me deixa bastante entusiasmado.

Como certamente sabem tenho andado a brincar com um pequeno website cujo único factor particularmente distinguível é, perdoem-me a modéstia, o design. Agora este post serve apenas para dizer que dei hoje finalmente os primeiros passos para o rewrite que tenho andado a planear e que deve finalmente tornar a aplicação utilizável no dia a dia.

Ficou finalmente funcional a primeira chamada da futura API do TV Wall (sim, vai existir uma API) e apesar de ainda faltarem alguns detalhes (como por exemplo uma forma de autenticação) é já uma conquista para mim conseguir ter posto a funcionar um pedido a um serviço externo e respectiva cache local em CouchDB.

Com isto tenho vindo a habituar-me ao conceito de programação por eventos o que leva a casos curiosos em que passo um bom bocado a tentar perceber porque é que este código não funciona apesar de ao inspeccionar o objecto o método ser claramente visível.

if (db.table.exists()){}

A resposta é simples quando se começa a compreender a linguagem (se bem que um pouco de documentação teria ajudado neste caso): o método é assíncrono pois vai questionar uma base de dados externa logo a forma correcta de o fazer é deixando um callback que vai ser chamado quando ela responder.

db.table.exists(callback = function(result) {
    if (result) {
        // Exists
    } else {
        // Does not exist
    }
});

Como podem ver isto não é propriamente das coisas mais simples de se usar para programação mais convencional em que estamos dependentes do resultado mas para programar na web onde temos de responder a múltiplos pedidos simultaneamente e estamos dependentes dos mais diversos pontos de latência este tipo de lógica trás teoricamente vantagens interessantes para a performance do sistema.

Node.js não é propriamente simples e está bastante longe de estar maduro mas promete bastante na minha modesta opinião e acho que é uma boa aposta para o futuro próximo da web.

PS: acho que é a primeira vez que mostro aqui o novo logótipo do TV Wall. O que acham?

Como tinha dito antes tenho andado a brincar com algo que apelidei de TV Wall e essa brincadeira passa principalmente por usar JavaScript e funcionalidades novas do HTML5…

Pois bem, aplicações web a correrem praticamente só no cliente são muito giras realmente mas infelizmente ainda são precisas algumas coisas do lado do servidor e para essas tenho andado a usar o bom e velho PHP… E php serve, php dá para responder a pedidos, php cumpre a sua função admiravelmente e acima de tudo php funciona de uma maneira que eu compreendo muito bem: eu aponto-lhe um url e ele corre o script que se encontra nesse url. Serve perfeitamente mesmo que não seja a solução mais moderna ou a que escale da melhor forma.

Mas eu não quero usar php e tenho andado a apaixonar-me cada vez mais com JavaScript. Acima de tudo eu gosto da ideia de que uma aplicação não corre mas sim responde a pedidos. As aplicações não passam variáveis, passam mensagens (e essas mensagens são em JSON no meu caso). O que eu queria mesmo era usar JavaScript em todo o lado e guardar todos os meus dados em JSON.

Guardar os dados já consigo, tenho o belo do CouchDB a deixar-me guardar lá objectos JSON com uma bela api via REST, mas a minha grande duvida é como raios vou usar javascript no servidor…

Temos o Node.js, o Narwall com o Nitro, temos o Ringo e mais uns quantos e a verdade é que eu estou totalmente perdido… Eu não só não sei em qual deles pegar como não faço a mais pálida ideia de como começar a programar o que quero que ele faça… Alguém me consegue dar uma ajudinha?