Aplicações para a Internet que se comunicam umas com as outras é algo mais do que comum. Ou sua aplicação consome algo que outra produz ou ela produz algo para outra consumir.

É bem fácil testar o que sua aplicação produz. Basta subir um servidor local, fazer uma requisição para o endereço correspondente e processar o resultado. Mas, por outro lado, como testar que sua aplicação consome o que outra produz adequadamente?

É claro que não vamos querer depender da aplicação remota de verdade. Queremos deixar os testes automatizados o mais isolados possível dos recursos externos. Então vamos, provavelmente, querer que o objeto responsável por fazer as requisições para fora não as faça de verdade e que devolva dados semelhantes aos da aplicação real.

Um jeito de fazer isso seria “embrulhar” a comunicação com a Internet numa classe nossa e, nos testes, mockar essa classe e passar essa classe mockada para as classes (ou os métodos) que precisam dela. É possível fazer isso em qualquer linguagem que suporte orientação a objetos.

Em Ruby ainda temos uma outra possibilidade. Como as classes são abertas, podemos re-escrever os métodos da classe Net::HTTP, por exemplo. Assim, não precisamos criar um embrulho; podemos utilizar sempre a classe do sistema.

Pois também não precisamos fazer isso na mão. A gem FakeWeb permite mockar requisições para determinadas URIs com um código bastante sucinto. Por exemplo, se você quiser que seu programa receba “olá mundo” quando fizer uma requisição do tipo GET para a URI http://foo.com/bar, basta escrever antes do código que executa a requisição:


FakeWeb.register_uri(:get, "http://foo.com/bar", :body => "olá mundo")


Em Java também é possível fazer algo parecido com um pouco de magia negra, desde que controlemos a criação do objeto responsável pela requisição. Mas, a meu ver, a primeira abordagem resulta num código mais desacoplado. Qual a sua opinião?

Posts Relacionados:

Atualizando o RubyGems no Mac

FISL 8.0: Wireless Meshing with OLPC

Eleições via Internet?

Firefox começa a dominar Europa

Aplicações portáveis em C/C++

Os criadores do Skype atacam novamente…

Algumas impressões de JavaME

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Java é uma das linguagens mainstream do momento. Alguns gostam, outros odeiam… Afinal, o que torna essa linguagem tão popular e impopular ao mesmo tempo? Quais são os pontos fortes e fracos dessa linguagem criada pela Sun na década de 90 e que é atualizada até hoje? Vamos analisar a linguagem de uma maneira global antes de destrui-la de vez na série JSF :)

Java é uma linguagem de tipos estáticos e explícitos, ou seja, você tem que declarar o tipo de sua variável. Junte a isso os modificadores de acesso, sincronismo e gravação e você terá uma ideia da burocracia da linguagem. Isso é visto como uma desvantagem por muitos, mas também tem suas vantagens. Se, por um lado, perde-se flexibilidade, por outro ganha-se em segurança.

Os criadores de Java procuram sempre manter compatibilidade entre as versões da linguagem. Isso significa que código das primeiras versões do Java ainda são compiláveis pelos compiladores para as novas versões sem ser necessário alterar o código. Essa decisão é boa para as empresas que trabalham com muito código legado mas é ruim para a linguagem. Por causa disso, decisões erradas sobre diversos aspectos da linguagem são visíveis até hoje. Por causa disso, também, a linguagem tem poucas (55) palavras reservadas, mas cada uma podendo ter mais de um significado dependendo do lugar em que aparece, o que gera confusão e implica em sintaxe pouco intuitiva em muitos casos (vide classes anônimas, blocos construtores, a sintaxe do enhanced for, etc).

Por esses aspectos já dá para notar porque a linguagem ficou tão popular: porque as empresas gostaram. A linguagem é padronizada, burocrática e não exige manutenção conforme é atualizada. Perfeito para elas! Não tanto para os programadores…

Como um dos objetivos iniciais da linguagem era a portabilidade dos programas, foi decidido que os programas seriam executados em uma máquina virtual. Uma crítica que muitos opositores de Java fazem é que isso torna os programas mais lentos e “pesados”. De fato, se considerarmos que a máquina virtual é uma camada a mais na execução de um programa, é lógico concluir que isso vai tornar a execução mais lenta. Isso era uma realidade incômoda até pouco tempo atrás mas, recentemente, as máquinas virtuais para Java evoluíram a tal ponto que a velocidade de execução de um programa em Java é comparável com a de um programa em C. Devemos considerar, é claro, que isso acontece depois de algum tempo de execução, quando a máquina virtual já carregou e otimizou o código. Mas o fato é que as máquinas virtuais para Java estão tão boas que outras linguagens interpretadas (ou seja, que rodam em máquinas virtuais) estão utilizando a máquina virtual Java para executarem o código. Dois exemplos disso são o projeto JRuby, para executar código Ruby, e a linguagem Groovy, que foi escrita já com o intuito de ser facilmente executada na máquina virtual de Java.

Para concluir esse post (mas não necessariamente o assunto), podemos dizer que a linguagem já está, digamos, velha. Isso também tem suas vantagens e desvantagens. As vantagens são a tecnologia bem desenvolvida sobre ela (o que inclui a máquina virtual) e a grande quantidade de ferramentas para se trabalhar com ela (bibliotecas e ambientes de desenvolvimento). A principal desvantagem, acentuada pela decisão de compatibilidade com versões anteriores, é a dificuldade de evoluir a linguagem, dadas as decisões erradas de arquitetura e a quase-impossibilidade de alterar sua sintaxe.

Posts Relacionados:

Linguagens de Programação - Basic

Linguagens de programação - C++

Linguagens de Programação - C

Linguagens de programação

Lambda the Ultimate

Testes unitários em C++

VidaGeek.net agora também é Fórum!

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Alguns devem ter notado que faz alguns meses que não escrevo para o VG com frequencia. Um dos motivos disso foi este projeto.

O Mirror é uma DSL simples construida em cima da Java Reflection API pra facilitar um pouco a utilizacao dela.

A idéia é remover tudo aquilo que deixa o código praticamente incompreensível. Quem já brincou um pouco com reflection em Java sabe que você precisa suar bastante pra entender o código.

Com Mirror, seu código passa disso:

Field toSet = null;
for (Field f : target.getClass().getDeclaredFields()) {
    if (f.getName().equals("field")) {
        toSet = f;
    }
}
if (toSet != null && ((toSet.getModifiers() & Modifier.STATIC) == 0)
        && ((toSet.getModifiers() & Modifier.FINAL) == 0)) {
    toSet.setAccessible(true);
    toSet.set(target, value);
}

Para isso:

Mirror.on(target).set().field(fieldName).withValue(value);

Não sei quanto a vocês, mas eu prefiro a segunda forma ;)

Site oficial do projeto

Todo feedback é bem vindo!

Posts Relacionados:

Mirror 1.4 release

Mirror 1.5 release

Infinitest

Rodas existem porque inventamos várias

Retrospectiva 2008

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Recentemente desenvolvi, em parceria com o Rafael, autor aqui do blog, uma aplicação simples em Java para celular. A aplicação é um jogo de batalha naval, que pode ser jogado contra o computador ou contra outro celular, via internet. Vou comentar, aqui, algumas dificuldades que encontrei pelo caminho.

(more…)

Posts Relacionados:

Retrospectiva 2008

INC - Isso Não Compila!!!

MacOS X 10.4.9

SNL - Ensaio sobre a cegueira

FISL 10: Agilidade e Qualidade de Projetos com Ruby on Rails

Dia C - Estratégias de depuração (debug)

O Poder do Linux

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.