O que é Web Crawler?

Recentemente recebi um e-mail de dúvida do leitor Adair Martins. Não é o primeiro sobre esse (interessante) assunto. Vou publicá-lo, junto com minha resposta, para sanar uma duvida comum.

Quem quiser complementar minha resposta é bem-vindo, use os comentários.

Bom dia Wagner,

Sou estudante do Curso de Sistemas de Informação, e estou no ultimo período. Tenho que terminar meu TCC, estou fazendo sobre web semântica e o professor que me orienta me sugeriu que eu fizesse uma aplicação que conseguisse pegar as informações sobre futebol, por exemplo, de varios sites.

Estou a procura, já faz quase um mês, e nao encontrei nada. Vendo seu artigo no iMasters, me pareceu muito interessante. Gostaria de saber se você não tem algum material que pudesse me ajudar a criar essa aplicação, se possível em java, pois é a linguagem que tivemos mais contato no curso.

Desde já agradeço a atenção.

Bem legal o assunto do seu TCC, isso (semântica) é o futuro da internet.

O que você vai desenvolver é técnicamente chamado de Web Crawler. Exemplo disso é o GoogleBot, crawler que o google desenvolveu para ficar varrendo a internet, indexando conteúdo para pesquisarmos através do famigerado Google.com.

O artigo da wikipedia sobre Web Crawler é bem completo. No fim do artigo existe uma lista de implementações de crawlers em linguagens e plataformas diferentes, inclusive em java.

Existe bastante material sobre esse assunto, até em português.

Abraço!

Quando agile vira Go Horse

Quando práticas ágeis são mal implementadas no desenvolvimento de software, tornam-se processos Go Horse, praticamente fábricas com ciclos de trabalho. Como qualquer outra metodologia. E sinceramente, ainda não trabalhei com um processo ágil implementado da maneira correta.

Não sou consultor, certificado, entusiasta ou qualquer outro tipo de evangelizador de métodos ágeis. Então como posso avaliar que nunca trabalhei com implementações corretas?

Simples! Porque as diretrizes do manifesto não foram atendidas. Esquecidas é uma palavra que encaixa melhor aqui. Vou explicar, para isso vamos a eles, os valores:

"Indivíduos e interações mais que processos e ferramentas"

Não vi nem de perto. Geralmente os processos e, pior, as ferramentas é que modelam os indivíduos. Resultado? Equipe desanimada porque precisa trabalhar para uma ferramenta ou processo, e não para um software.

"Software em funcionamento mais que documentação abrangente"

Ok, essa diretriz não é difícil de seguir. A documentação era precária mesmo antes de existir metologias ágeis. Software em funcionamento sim, é mais complicado.

"Colaboração com o cliente mais que negociação de contratos"

Na visão de alguns lideres de projetos o cliente continua sendo um inimigo que não sabe o que quer. Fechar o contrato com o escopo bem restrito é o objetivo principal.

"Responder a mudanças mais que seguir um plano"

O plano foi feito, deveria ter sido seguido, mesmo que todos concordemos que mudanças são inerentes ao desenvolvimento. Uma guerra de egos inflados impossibilita que as mudanças sejam feitas sem traumas. Uma mudança no escopo do projeto geralmente resulta em reuniões longas das quais o verdadeiro objetivo é encontrar culpados.

E!?

O que quero dizer é que metodologias ágeis são excelentes ferramentas para gerenciar projetos de desenvolvimento de software. Não fazem diferença nenhuma quando não implementadas da maneira correta, e para isso seguir seus valores pensando nos objetivos da metodologia é fundamental.

Não tente seguir a agilidade se não concorda com os valores ou não está disposto a segui-los.

Desenvolver jogos em Ruby é uma boa ideia?

Essa pergunta me ocorre quando vejo o quanto um sistema de partículas feito em Ruby é custoso para máquina.

Mesmo desenvolvendo pequenos joguinhos experimentais, Ruby permanece prazeroso e rápido, assim como pretende ser. Mas vamos ao problema: Porque apresenta baixo rendimento quando o assunto é game?

Lag… nããão!

Um jogo que se preze tem como objetivo rodar 60fps. Expectativa alcançada somente quando os ciclos de processamento chegam, no máximo, a 16 milisegundos. Quando o processamento ultrapassa essa pequena fração de tempo, o frame rate cai, as vezes vai a níveis tão baixos que temos os famosos lags.

Tive o maior exemplo de lag quando tentei rodar Fifa 98 no meu 486. Nesse caso a medida de calculo mais óbvia não era frames per secound, mas sim secounds per frame.

Enfim, lags não são bem-vindos. Claro que esse foi um caso extremo, e o desenvolvedor do Fifa não tem culpa do idiota querer rodar o jogo em um micro da geração passada.

E o Ruby?

Ruby não é uma das tecnologias mais rápidas do mercado e o blá blá blá de sempre. Mesmo assim Python também não é um foguete e se sai melhor quando o assunto é velocidade em games.

Encontrei um artigo que resume o problema. Quem escreve é Glenn Fiedler, um desenvolvedor de jogos que trabalha na Sony.

Segundo ele o problema está no GC do Ruby, que ainda utiliza o método mark-sweep, mais lento que os GCs de outras tecnologias concorrentes. Então, o problema não está diretamente ligado à performance, mas sim na arquitetura.

E porque o mesmo problema não acontece com aplicações web? Na verdade acontece, mas a necessitade é outra. Nesse caso a requisição web chega ao servidor, é processada, e depois encarrega-se de limpar seu proprio lixo.

Enfim, continuo gostando de Ruby para estudos na área e pequenos joguinhos experimentais. E para isso existem diversos frameworks que ajudam:

Mas quando a coisa é comercial e exige performance, talvez não seja uma boa escolha.

E antes que perguntem: Não testei com RubyEE, JRuby, IronRuby, MacRuby ou qualquer outra variante. E sim, teremos resultados diferentes.