Categories
ciência news

Ciência 2.0

Jon KrausePra quem não gostava do termo Web 2.0 @ wikipedia.org (en) pra descrever o que é a nova onda de aplicações sociais na internet, o que dirá desse artigo da Scientific American: Science 2.0 — Is Open Access Science the Future?

Vou ser sincero, não li ele todo 😉 Mas li o resumo no slashdot e isso é “quase” a mesma coisa. O ponto de partida é um projeto do MIT que agora recebeu financiamento para se expandir pra fora das fronteiras do famoso instituto tecnológico. Mas existem também os céticos, afinal, segundo um geneticista consultado pelo artigo: “é como se uma antítese da forma como cientistas são treinados”1). Mas mesmo estes estão aderindo à nova forma de trabalho.

É uma mudança significativa na forma de se fazer ciência, mas ao que parece, uma forma muito mais eficiente de se colaborar e de construir o conhecimento em conjunto. Com disse Bill Hooker2): “Eu não gostaria de tentar prever aonde isto tudo vai levar, mas apostaria com certeza de que vamos gostar quando chegarmos lá”3).

link (thanks /.)

References

References
1 pra garantir que ninguém se fie na minha tradução de meia tigela, o original dizia “It’s so antithetical to the way scientists are trained
2 pesquisador “pósdoc” de cancer no Shriners Hospital for Children, de Portland, e autor um levantamento sobre “open-science” para o 3 Quarks Daily.
3 no original “I wouldn’t like to predict where all this is going. But I’d be happy to bet that we’re going to like it when we get there.
Categories
nerdices news

Faceboogle?!?

Buscas na internet estão para morrer. Ao menos as buscas da forma como conhecemos. As redes sociais @ wikipedia.org (en) e a Web 2.01) mudaram a forma como o usuário procura informação. Ao invés de ir a um mecanismo de busca, porque não “imitar” a vida real e procurar a informação com seus amigos, conhecidos e outros membros de sua rede?

Segundo este artigo da PopularMechanics, O futuro das buscas está intimamente ligado ao futuro (incerto) das redes sociais, como orkut, facebook e myspace. O futuro do google seria usar essa informação, e tudo mais que o usuário tiver divulgado em relação a si, para melhorar e filtrar os resultados das buscas. Compras, amigos, blogs lidos e visitados. Tudo entraria na equação para tentar oferecer uma busca melhor do que a antiga forma de “pergunte aos amigos” pode fornecer. A possibilidade da volta ao tradicional conteúdo “push2), só que bem mais sofisticado e talhado sob medida para os usuários, não deixa de ser um futuro possível.

As coisas nesse sentido ainda tem muito que evoluir e amadurecer, então até lá, a busca na internet ainda não morreu! (será?)

link, (via /.)

References

References
1 Só pra irritar o Gazel
2 empurrado, no sentido de que o usuário não escolhe, mas sim aceita o que escolheram pra ele
Categories
nerdices

Como carregar “widgets” de sites externos sem carroçar sua página…

Não sei vocês, mas no meu caso, a maioria do tráfego do meu site vem “redes sociais” de blogs, como o tecnocrati, linkk, rec6, linkTo, stumbleUpon, etc… E manter os widgets desses caras sempre é útil! Quem vai votar no meu site depois de ter fechado a página original com o link? Acho que ninguém se daria esse trabalho.

Só tem um porém: Esses widgets são pedaços de javascript externo, que carregam arquivos e imagens do site de origem, e nem sempre carregam numa velocidade razoável. Resultado? Meu blog demorava milênios pra carregar.

Mas seus problemas se acabaram-se (ou quase).

Com o javascript delayator tabajara você agora já pode forçar os widgets a carregar apenas DEPOIS QUE TUDO já foi carregado :). E não se assuste, mas é uma gambiarra faminta! 🙂

Uso de iFrame

O primeiro passo pra isso é usar iFrame. Com um iFrame eu posso carregar um conteúdo qualquer num espaço separo que não vai impactar a carga do resto do meu site. Basicamente eu uso um iFrame inicialmente só pra reservar o espaço, e uso javascript para carregar o conteúdo. Um iframe fica mais ou menos assim:

<iframe src=""></iframe>

Que é um iFrame vazio. Depois a gente usa um javascriptzinho pra “encher” o cara. E é aí que vem a manha: O campo de “src” do iFrame pode ser preenchido com código javascript! Você pode gerar uma página inteira usando javascript e carregar ela no iframe, olha só:

<iframe id="myFrame" src="javascript:'XXXX'"></iframe>

E depois usar um script como o seguinte para preencher o iFrame:

<script language="JavaScript">
function getConteudo() {
    return "<h1>TESTE</h1>";
}

var frame = document.getElementById('myFrame');
frame.src = "javascript:'" + getConteudo() + "'";

</script>

Onde “getConteudo()” pode ser reescrita para retornar o que você bem entender. Claro que por enquanto não evitamos que a iFrame tenha o conteúdo carregado no momento em que o script for lido, e com isso só “adiamos” por algumas linhas a carga do nosso widget. O pulo do gato e forçar o javascript a só rodar DEPOIS do final da carga da página. Como? Simples, usando a propriedade de “onload” do HTML:

<head>
<script language="JavaScript">
function getConteudo() {
    return "<h1>TESTE</h1>";
}
function carregaiFrame() {
    var frame = document.getElementById('myFrame');
    frame.src = "javascript:'" + getConteudo() + "'";
}
</script>
<body onload="carregaiFrame()">

<iframe id="myFrame" src="javascript:'XXXX'"></iframe>

</body>

Agora sim! Nosso iFrame carrega o conteúdo que a gente quer, só depois que a página carregar. Mas ainda falta um problema…

“Mas, tio, desse jeito eu só tenho direito a um único iFrame?”

E é aí que vem o pulo do gato! Javascript é seu amigo, ele vai te ajudar. Se eu usar o javascript pra “guardar” o nome e o conteúdo de todos os frames numa lista, depois da página carregada eu só preciso percorrer a lista de iFrames e preencher cada um com o valor correto. Pra isso, precisamos de um scriptzinho logo abaixo de cada iFrame, só pra “contar” o que vai ser o conteúdo dele:

<iframe id="frame1" src="javascript:'XXXX'"></iframe>
<script>
frame_contents['frame1'] = '<script>document.write("teste1");</script>';
</script>

Vejam que pra ilustrar melhor eu usei um script javascript no exemplo. E vejam um detalhe importante: dentro da variável eu usei </script> ao invés de apenas </script>. Se não fizer isso, o browser fica doidão porque acha que você fechou o seu script antes da hora. Aí não…

Enfim, esse código sozinho não faz nada. A gente precisa agora “chamar” esse cara no nosso onLoad… Pra isso, vamos modificar o método carregaiFrame() pra dizer:

// nosso vetor precisa ser declarado, já que ele vai ser usado mais tarde:
var frame_contents = {};
function carregaiFrame() {
    for (name in frame_contents) {
        frame = document.getElementById(name);
        var src_value = "javascript:'" + frame_contents[name] + "'";
        frame.src = src_value;
    }
}

Tcharam! Temos um lindo código que carrega minhas iFrames somente APÓS a carga de toda a página, assim os elementos “lentos” podem ser todos carregados em iFrames desse tipo.

Problemas pendentes

Claro que nem tudo são flores… Sempre sobram um ou outro probleminha pendentes. No meu caso, o problema ficou por conta do rec6. Enquanto os outros widgets usam um link que abre em uma nova janela, o widget do rec6 tem um link normal, que abre na mesma janela. Assim, a página de login ou de votação abre pro sujeito dentro de um iFrame com tamanho pra caber apenas o widget. Impossível de usar, não é? Mas eu estou batalhando numa solução. Quem sabe um jeito de copiar o conteúdo do iFrame pra dentro de um div. Ainda tenho de testar o que vai dar certo.

Nesse meio tempo, deixo vocês brincarem com as dicas que acabei de dar. E lembrem-se: no Internet Explorer, pra tirar as bordas de um iFrame, não adianta usar CSS… (Mas essa dica quem for esperto pega direto do código fonte dessa página).