Cuil

Ontem surgiu o Cuil, um novo candidato a concorrente do Google no que toca a motores de busca. Feito por antigos engenheiros do Google promete muitas inovações.

No entanto existem vários problemas com o motor de busca em si, talvez devido a ainda ser novo e nunca sujeito às cargas que deve estar a ter neste momento. Por vezes não encontra resultados mesmo que anteriormente os tenha encontrado, outras vezes aparecem resultados que não fazem sentido perante a busca, mas nem foram estes pormenores que me chamaram a atenção.

 

Imperdoável

 

A nível de aparência começa-se por notar que tomaram uma abordagem semelhante ao Blackle no que toca à página inicial. O Blackle na altura em que surgiu tornou-se algo popular devido à prometida poupança de energia devido ao uso de um ecrã negro, e o uso do Google como motor de busca conquistou muita gente, apesar do Blackle em si não pertencer ao Google.

 

Páginas iniciais do Cuil e do Blackle

 

No entanto é quando se faz uma pesquisa  com muitos resultados e sugestões é que se revela que o i de cor diferente em Cuil não é um acaso. Apesar de o Internet Explorer ser o meu browser principal eu uso imensas vezes o Safari, e conheço bem a página inicial da Apple.

Fiquei verdadeiramente espantado com a semelhança de aparência e funcionamento da apresentação de resultado com a página inicial da Apple. Isto é verdadeiramente notório no menu de sugestões lateral, tem o mesmo aspecto e funcionalidade, o mesmo deslizar de barras com a passagem do rato para escolher categorias.

 

Página inicial da Apple no Safari

Resultados no Cuil

 

Isto leva-me a pensar que “se estão a fazer à febra” para motor de busca para o safari e população Mac, e quem sabe se o nome planeado não seria iCul e não Cuil.

No entanto é sempre bom ver mais concorrência e até com alguma inovação.

Escolhas de Blogar III – Escrever Código

Bem, uma das coisas que pretendo fazer com alguma frequência neste blog é escrever código, tal como fiz no artigo anterior.

Parece algo relativamente simples, mas não é. Procurei um pouco por todo lado e não consegui encontrar nenhuma solução para apresentar código legível, ou seja, com cores, pelo menos para o wordpress.com.

O artigo anterior teve direito a cores introduzidas à mão, mas se for necessário fazer sempre isso começo a desesperar um pouco.

Se alguém tiver alguma dica avise!

Invocar código de servidor através de Javascript

Trabalhar com Mapguide Open Source implica trabalhar bastante com o Javascript, e por isto surgem sempre alturas em que queremos conjugar código do lado servidor com código do lado de cliente.

Um exemplo disto é a obtenção do nome do mapa presente num weblayout numa tarefa presente no taskpane.

De modo a não depender de configurações externas no que toca ao nome de mapa é possível obtê-lo através da execução do comando GetMapName() do mapframe, ou mais completo através de uma tarefa que tenha o comando Javascript

parent.parent.mapFrame.GetMapName()

Mas e se precisarmos do nome do mapa no lado do servidor? Posso estar enganado, mas ainda não encontrei modo de o obter.

Um modo para o fazer seria executar a linha anterior ao carregar o body e colocar o resultado num campo escondido acessível do lado do servidor e depois ter um botão para executar o código do lado do servidor.

Mas o Mapguide tem um pequeno problema, por vezes a tarefa é carregada antes do mapa, o que significa que quando a página é carregada é devolvida uma string vazia.

Ora uma solução possível seria ter um botão que quando necessário obtivesse através de Javascript o nome do mapa e depois executasse o código do lado do servidor.

Como fazer isso?

A resposta encontra-se no código gerado pelo ASP.Net quando é utilizado um LinkButton:

<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['fPlantas'];
if (!theForm){
    theForm = document.fPlantas;
}
function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();
    }
}
//]]>
</script>

Este código permite invocar através de Javascript funções do lado do servidor invocando algo como:

__doPostBack("FuncServidor","");

em que FuncServidor é o nome da função do lado de servidor.

Deste modo pode-se invocar a função para obter o nome do mapa seguido da execução da função do lado de servidor que necessita desse nome.

Ainda sobram as questões de segurança deste código e também o problema de poder carregar no botão antes de o mapa estar carregado, mas isso fica para outro artigo.

“Já tentaram Javascript?”

Vi alguns textos engraçados sobre como o Javascript se pode tornar num chavão ou mesmo obsessão.

Pessoalmente tenho relativamente pouca experiência com Javascript pois honestamente não gosto muito da chamada programação do lado cliente em termos de web.

Primeiro porque é possível ao utilizador ver todo o código, e como tal a não ser que se queira o Javascript para fazer brincadeiras, ou tarefas banais corre-se o risco de falhas de segurança. Pode-se sempre alegar que isso numa aplicação open source não tem importância, mas eu nesse caso diria que não me parece que seja assim tão linear, em especial devido ao próximo ponto.

Utilizar Javascript implica perder o controlo sobre a performance das aplicações. Já não é fácil tentar calcular cargas de servidor e tempos de transferência, e ao adicionar Javascript estamos a utilizar algo que a performance depende do equipamento do cliente e do browser, para não mencionar sistema operativo. Ou seja, numa aplicação que dependa bastante de Javascript no fim acabamos por não saber realmente como se comportará o que fizemos.

Isto não considerando que apesar de tudo o Javascript é um componente opcional nos browsers, podendo estar desligado. Verdade seja dita que isto hoje em dia é raro pois a grande maioria das pessoas que usam internet não faz ideia da quantidade de tecnologias diferentes que são usadas na web, e “se está ligado é porque deve ser preciso” será a atitude que tomarão se chegarem a alguma vez a abrir a janela de opções do seu browser.

Eu sempre imagino o futuro da web como um retorno à época dos servidores e terminais, e como tal uma experiência web que quanto menos depender do cliente melhor. No entanto hoje em dia a tendência, em especial com o Firefox, parece ser “quantos mais pluggins tiver instalados mais divertida é a web”, e isto verifica-se com coisas como Flash, Silverlight, PicLens e mesmo aplicações que de gráfico nada têm como o Del.icio.us.

Mas divago, resumindo e concluindo, o Javascript é engraçado para tratar de algumas coisas, mas depender demasiado dele para uma aplicação web parece-me ser má política.

Portugal Antigo

Está hoje no Peopleware uma referência a um site que é realmente fabuloso pelo seu conteúdo, o Portugal Antigo.

Este site está repleto de fotos de várias cidades, castelos e até comboios e estações, sendo que todas essas fotos são antigas!

É realmente fabuloso ver como alguns destes locais eram antes de por cá andarmos ou mesmo como há muito não os víamos.

Fica então aqui a sugestão de visitarem Portugal Antigo.

Rua Visconde da Luz em Coimbra

(Des)Integração com o Mapguide Open Source

Realmente não gosto mesmo nada do modelo de integração de aplicações do Mapguide, pois em vez de integrarmos o Mapguide numa aplicação nossa temos que integrar a nossa aplicação no Mapguide.

Isto para mim não faz o menor sentido, é deveras mais simples para quem está a criar o servidor de mapas, só que no fim quem acaba por “servir” somos nós com as nossas aplicações, ficando praticamente reduzidos a criar um “pluggin” para o Mapguide.

Isto leva a que tenhamos que considerar uma aplicação em que é necessário um técnico formado apenas para instalar a aplicação, apenas devido ao modo como o Mapguide funciona.

Para software feito “à medida” isto não é incomum, mas talvez por estar dentro do mundo da informática considero isto mau, porque apesar de ter alguém especializado para instalar algo pode dar segurança também dá a impressão que a aplicação é extremamente complicada de utilizar, o que não é verdade.

Independentemente de todos estes factores a realidade é que a integração com o Mapguide atrasou bastante o projecto, visto que em vez de aprendermos a trabalhar com o Mapguide tivemos que aprender a trabalhar no Mapguide.