Archive for the ‘Ruby’ Category
Linguagens de Programação - Python versus Ruby
Author: Luiz14 May
Índice de Linguagens de programação
Aqui na nossa série de linguagens de programação (sem posts já faz um tempo), já falamos de Ruby, mas ainda não de Python. O ideal seria falar de Python antes mas, graças a uma palestra interessante que assisti online, resolvi fazer alguns comentários e críticas a cada uma delas.
Antes de mais nada, é importante entender quais as bases e as motivações de cada uma dessas duas linguagens. Ambas as linguagens têm como metas permitir código bonito, legível e o mais simples possível. Mas o critério de bonito e legível difere para cada uma delas. De acordo com o Zen do Python (numa tradução livre):
[...]
Casos especiais não são tão especiais para quebrarmos as regras.
[...]
Quando se deparar com uma ambiguidade, não ceda à tentação de tentar adivinhar.
Deveria haver uma, e preferencialmente só uma, maneira óbvia de fazer algo.
[...]
Se a implementação é difícil de explicar, não é uma boa ideia.
[...]
Já o Ruby, de acordo com o próprio criador Yukihiro Matsumoto:
[...] é simples na aparência, mas muito complexo no interior, tal como o corpo humano.
Nota-se que isso contraria a parte da simplicidade de implementação do Zen do Python. E nota-se isso também em bibliotecas famosas escritas em Ruby, como o ActiveRecord, por exemplo. Você já tentou entender a implementação da classe ActiveRecord::Base?
Além disso, Ruby herdou de Perl, uma de suas fontes de inspiração, a ideia de ter várias formas de fazer uma mesma coisa. E também tem alguns casos especiais de sintaxe, como a invocação de um setter (que pode ser com espaço antes do igual, apesar de o nome do setter não ter esse espaço), os parênteses opcionais na invocação de um método ou as chaves opcionais num hash passado como argumento.
Agora, minha opinião
Acho que é bom ter mais de um jeito de fazer a mesma coisa, como o Ruby possibilita. Um jeito só de fazer a mesma coisa, a meu ver, tem a vantagem de facilitar um pouco a leitura do código, graças à uniformidade. Mas, por outro lado, nos comunicamos uns com os outros numa língua que permite expressar uma mesma ideia de muitas formas diferentes, e mesmo assim nos entendemos, não? É claro que às vezes com alguma dificuldade, mas na maioria das vezes por causa da ambiguidade da língua. E liberdade de expressão também é importante em programação!
Por outro lado, as peculiaridades da sintaxe de Ruby não me agradam; acho que tornam a linguagem mais difícil de compreender. Os casos especiais são muitos e, às vezes, deixam o programador confuso quanto à necessidade de chaves, por exemplo.
Uma característica muito importante que a linguagem Ruby deveria ter, mas só Python tem, são argumentos rotulados. Em Ruby, costuma-se utilizar um hash para suprir essa necessidade, o que, convenhamos, não é muito elegante.
Um ponto sobre o qual ainda não tenho uma opinião muito elaborada é sobre a modificação de classes e métodos em tempo de execução. Em Ruby, ela é implícita: se você declarar uma classe com o mesmo nome de uma que já existe, você estará modificando a existente. Em Python, ela é explícita: você só pode modificar a classe existente se você escrever código específico para isso; se você declarar uma classe com o mesmo nome de uma já existente, você está criando outra classe. Por um lado, acho bom deixar explícito que você está modificando uma classe existente. Mas, por outro lado, faz sentido ter duas classes diferentes com o mesmo nome?
E você, qual a sua opinião? Quais são suas críticas a cada uma dessas linguagens?
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Uma gem para testar aplicações que se comunicam com a Internet
Author: Luiz17 Apr
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:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
FISL 10: Scaling Rails
Author: Luiz27 Jun
Na segunda palestra que assisti (na verdade terceira, mas a primeira não conta porque, infelizmente, dormi :P), Sylvestre Mergulhão deu continuidade à palestra do Fabio Akita e falou sobre escalabilidade utilizando Rails no site RedeParede, um site de classificados com versões para toda a América Latina.
Sylvestre começou falando da performance do site e o sistema de indexação do Google (o Googlebot). Falou que o Googlebot afetava perceptivelmente a performance do site quando estava indexando e era responsável por aproximadamente metade das requisições. Levantou também algumas teorias sobre o Googlebot (parte que achei mais interessante na palestra):
- Sitemap em XML => mais visitas
- Rank também é determinado por capacidade do site de receber visitas
- Queda de serviço => menos indexação por um bom tempo
- Mais atualizações => mais indexação
Depois disso, Mergulhão falou um pouco sobre a estrutura física dos servidores do site. São seis máquinas atrás de um balanceador de carga, cada uma com cinco instâncias rodando atrás do NGINX. Falou também um pouco do memcached, utilizado para fazer cache de qualquer string, que está sendo utilizado em massa pelo site. Segundo ele, é uma biblioteca fácil de usar, apesar de pouca documentação. Deu também exemplos de configuração e de uso. Falou mais um pouco sobre problemas com caching (página muda de acordo com usuário) e sobre outros tipos de caching: de página (falou que era melhor usar o cache de HTTP com ETags), de ações (muito interessante: permite guardar o resultado de uma ação no cache; dobrou a capacidade de processamento do servidor deles) e de fragmentos (para guardar pedaços de páginas).
Por fim, falou um pouco sobre o ganho de performance e de tempo de desenvolvimento (por não ter que usar mais SQL) com o uso do Sphinx.
O começo da palestra foi interessante, mas minha impressão final é de que o palestrante não ficou muito feliz com o resultado da migração do site, antes em PHP, para Rails. Outro comentário que posso fazer é que já trabalhei num projeto em Rails com Sphinx e a equipe não gostou muito; acabamos mudando para o Solr.
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
FISL 10: Agilidade e Qualidade de Projetos com Ruby on Rails
Author: Luiz27 Jun
Ontem, Fabio Akita deu uma palestra no FISL 10 sobre Ruby on Rails. Foi uma palestra lotada e divertida.
A palestra começou com uma breve introdução ao arcabouço, um outline da palestra. O Fabio falou de como surgiu o arcabouço, qual era seu objetivo inicial, falou das atuais versões de Ruby, de Rails e do JRuby e da importância da comunidade para o projeto.
Em seguida, na parte mais divertida da palestra, o Akita mostrou alguns dados sobre a performance da máquina virtual de Ruby. Mostrou, por exemplo, o ganho de velocidade da versão 1.8 para a versão 1.9 da máquina virtual “padrão” de Ruby por meio de um jogo muito interessante chamado “Rubystein” que eu, pelo menos, não conhecia nessa versão… hehehe). O jogo, aliás, utiliza uma biblioteca para acessar o hardware diretamente para fazer o desenho 2D: Gosu.
Depois da demostração de ganho de velocidade realmente impressionante da nova máquina virtual, falou um pouco da importância da comunidade para se aprender e divulgar Ruby on Rails. Citou, inclusive, alguns sites muito bons para ficar por dentro das últimas novidades sobre o projeto:
- Peepcode
- railsenvy.com (podcasts)
- railscasts.com (vídeo podcasts de how-to’s)
- Outros…
Em seguida, Fabio falou de alguns recursos que já vem embutidos no Rails mas que nem todo mundo lembra, motivo pelo qual, segundo ele, algumas pessoas xingam Rails sem motivo. Dentre essas funcionalidades, vale destacar o suporte a autenticação HTTP básica, Atom, internacionalização (i18n para os íntimos), XML, JSON, e-mail e caching.
Para terminar, o Akita fez uma demonstração de algumas funcionalidades incrementando o já famoso blog de 15 minutos. Criou uma área de administração com login, colocou caching, um editor de texto mais incrementado e suporte a upload de arquivos, para citar as mais legais.
Enfim, aprendi algumas coisas novas com essa palestra; gostei! E acho que também agradou a quem não conhecia quase nada de Rails. Parabéns, Akita. Mas faltou alguma coisa de metodologias ágeis na palestra (pelo título).
O código que ele mostrou na palestra está no GitHub e os slides, no SlideShare.
Assim que der tempo falo sobre as outras três palestras que assisti ontem, apesar da visita do nosso presidente ter atrapalhado um pouco o andamento do evento…
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
