Usando RubyGems atrás de um proxy

Para usar o RubyGems ou o Nu (projeto que falei a respeito a algum tempo) atrás de um proxy é bastante simples, basta definir a variável de ambiente HTTP_PROXY com o endereço do servidor.

A configuração fica um pouco mais complicada quando o proxy é o Microsoft ISA Server e requer autenticação NTLM. Nesse caso, alguns passos adicionais são necessários.

Configurando o proxy para usar autenticação NTLM

Antes de mais nada, defina o endereço do proxy na variável de ambiente HTTP_PROXY, conforme mostrado anteriormente. A seguir, instale a “gem” rubysspi. É necessário baixá-la e instalar manualmente direto do disco.

O próximo passo é copiar o arquivo “spa.rb” dessa gem para o diretório “site_ruby”. Os caminhos serão parecidos com estes:

• Origem: C:\Ruby192\lib\ruby\gems\1.9.1\gems\rubysspi-1.3.1\spa.rb
• Destino: C:\Ruby192\lib\ruby\site_ruby\1.9.1\

Por fim, é necessário alterar o arquivo “gem.bat” para usar essa autenticação. Edite esse arquivo e adicione na chamada do ruby o parâmetro “-rspa”.

O original estava assim:

@"%~dp0ruby.exe" "%~dpn0" %* 

E, depois da alteração ficará assim:

@"%~dp0ruby.exe" -rspa "%~dpn0" %* 

Pronto, com isso já será possível atualizar as gems.

Se você utiliza o Nu, pode alterar o Nu.bat adicionando o parâmetro “-rspa” da mesma forma que foi feito no “gem.bat”.

Como funciona a autenticação OAuth

Nos últimos anos, com a tão aclamada Web 2.0 muitos sites passaram a fornecer APIs que podem ser usadas por terceiros para agregar valor ao sistema. Sites como Twitter e Facebook devem grande parte de seu sucesso pelo fato de ter essa possibilidade de extensão.

Nesses sites normalmente a API é acessada "em nome" de um usuário. Ou seja, é necessário ter um usuário autenticado para obter os dados. Vou tomar como exemplo o Twitter, que é bem conhecido de todos. Para que uma aplicação possa enviar um tweet em nome do usuário, ela precisa do login e senha dele.

Agora vem a questão, quem gosta de compartilhar sua senha com os outros? Mesmo que o outro seja uma aplicação. E, ao alterar sua senha, você deseja ir em cada aplicativo e reconfigurá-lo?
Para resolver esse problema surgiu o protocolo de autenticação OAuth.

Objetivo

O principal objetivo do OAuth é permitir que uma aplicação se autentique em outra "em nome de um usuário", sem precisar ter acesso a senha dele.

Basicamente, a aplicação pede permissão de acesso para aquele usuário e o usuário concede ou não a permissão, sem que para isso tenha que informar a senha. Essa permissão independe da senha. Mesmo que a senha seja alterada a permissão continuará válida. Além disso, a permissão dada à aplicação cliente pode ser revogada a qualquer momento.

Funcionamento da autenticação OAuth

Pesquisei na internet a respeito do funcionamento dessa autenticação e, na maioria das vezes, a explicação é bem técnica. Geralmente é explicado apenas como usar determinadas bibliotecas.

Eu tentei explicar o funcionamento em um nível bem alto, sem entrar em detalhes técnicos. Para uma explicação mais aprofundada recomendo a leitura deste link e deste. Deixei de lado aspectos como criptografia e HTTPS, focando basicamente no fluxo da autenticação. Então vamos lá...

A autenticação por meio do OAuth consiste de três passos:

1. Aplicação cliente obtém chave de autenticação;
2. Usuário autoriza aplicação cliente na aplicação servidora;
3. Aplicação cliente troca a chave de autenticação pela chave de acesso;

1 - Aplicação cliente obtendo chave de autenticação

No primeiro passo o usuário inicia o processo de autenticação. Por exemplo, no site TwitPic ele clicaria no botão “Login or Create an Account”.

Nesse momento a aplicação cliente solicita à aplicação servidora uma chave de autenticação. A aplicação servidora devolve duas chaves, uma pública e uma privada. Repare que essas chaves não dão permissão de acesso, elas são usadas apenas durante o processo de autenticação.

A seguir, a aplicação cliente redireciona o usuário para a aplicação servidora usando a chave pública (no caso do TwitPic, por exemplo, o usuário vai para o site do Twitter).

2 - Usuário autorizando o acesso

Depois que o usuário foi redirecionado para a aplicação servidora, ele autoriza o acesso da aplicação cliente. No Twitter isso ocorre ao clicar em “Allow”.

Assim que o usuário efetuou a autorização, ele é redirecionado de volta à aplicação cliente.

3 - Aplicação cliente trocando a chave de autenticação pela chave de acesso

Nesse momento, a aplicação cliente troca a chave de autenticação pela chave de acesso. A chave de acesso só é concedida se o usuário autorizar o acesso.

Repare que, para se comunicar com a aplicação servidora é utilizada a chave privada, desse modo, apenas a aplicação cliente consegue obter a chave de acesso.

A chave de acesso obtida é utilizada pelo cliente para acessar a API do servidor “em nome” do usuário.

Cuidados e perigos

Um dos perigos desse protocolo é uma questão cultural. Como o usuário não fornece a senha ele se sente seguro. Ele muitas vezes não se dá conta que está dando acesso a aplicação cliente, mesmo sem informar a senha.

O usuário deve ter cuidado ao autorizar qualquer aplicação cliente. Ele deve dar autorização apenas às aplicações que ele confia, pois com essa autorização, uma aplicação mal intencionada pode fazer tantos estragos quanto faria se o usuário passasse sua senha.

Um detalhe importante é revogar a autorização de aplicações que não são mais utilizadas ou de origem duvidosa. No Twitter, por exemplo, pode-se acessar esta página para remover a permissão de acesso.
Aproveite que você está lendo isso e olhe sua lista de aplicativos com acesso permitido ao Twitter, provavelmente alguns deles você nem lembra mais que existem.

Páginas lentas no Firefox e Chrome ao abrir o sistema pelo Visual Studio

Aí vai uma dica simples para quem está desenvolvendo no Visual Studio usando o Web Server integrado (ASP.NET Development Server, também conhecido como Cassini).

Se você notou que ao acessar as páginas do sistema utilizando o Chrome ou Firefox elas estão lentas, demoram um segundo para abrir cada página, há uma solução muito simples para isso.

Edite o arquivo “C:\Windows\System32\drivers\etc\hosts” e adicione ao final dele a seguinte linha:

127.0.0.1       localhost

Pronto, problema resolvido. Reinicie o browser e ele já deverá estar muito mais rápido.

O que define a qualidade do software?

Muito se fala em qualidade de software, mas afinal, o que determina se um software tem qualidade?
Lendo um artigo do Phil Haack essa questão veio novamente à tona. No artigo ele diz (tradução livre): “Nós não estamos aqui para escrever software, estamos aqui para desenvolver produtos e entregar valor. Escrever código é só um meio para esse fim”.

Nessa frase ele vai direto ao foco da questão, escrever o software não é o objetivo, é apenas um meio para prover valor ao cliente. O cliente não paga pelo software em si, mas pelo benefício que o software proporciona.

Nós como desenvolvedores muitas vezes esquecemos que a informática é apenas um meio. Ela por si só, não tem valor algum. O que tem valor é o que a informática pode fornecer às outras áreas e mais especificamente ao usuário.

Mas então, sabendo que o software por si só não tem valor, o que define a sua qualidade? Para responder isso eu separaria a qualidade do software em duas categorias:

• qualidade do produto;
• qualidade do código.

Qualidade do produto

Considerando que o software é um produto que visa prover valor ao usuário, a sua qualidade nada mais é que o atendimento das necessidades do seu usuário. Um software de qualidade é aquele que faz, de maneira correta, o que o cliente precisa que ele faça.

Para definir a qualidade do software precisamos entender a necessidade do usuário e com isso verificar se o software está atendendo de forma eficiente e eficaz.

Qualidade do código

No lado técnico do software, podemos analisar sua qualidade pensando na capacidade de continuar provendo valor ao cliente no decorrer do tempo. Ou seja, o software poderá atender as futuras expectativas do cliente? Poderá continuar evoluindo de maneira eficiente?

Muitos fatores contribuem para que o código possa ser considerado de qualidade. Alguns deles são:

• está legível e bem documentado – o desenvolvedor entende facilmente o que está acontecendo;
• tem baixa complexidade – deve ser fácil entender como ocorre a execução do código. Partes complexas devem ser destrinchadas em partes menores e mais simples (vide complexidade fabrica);
• há testes – ao desenvolver novas funcionalidades podemos verificar de forma fácil que as antigas continuarão funcionando;
• o sistema pode ser estendido – alterar um código existente sempre pode gerar problemas. Um sistema construído de forma extensível sempre será melhor para se trabalhar (vide Open/closed principle).

Apesar dessas questões serem técnicas, a visão continua sendo no valor provido ao cliente. Se o software continuará a evoluir com o passar do tempo, não adianta a primeira versão atender perfeitamente ao cliente se na segunda versão o custo do desenvolvimento sobe imensamente e na terceira ainda mais. Um software bem escrito significa que com o passar do tempo o cliente continuará a ter suas necessidades atendidas de forma efetiva e com um custo adequado.

Podemos argumentar que um software que não será evoluído não precisa ter um bom código, basta atender ao cliente. Certo? Certo!! Porém, quantas vezes podemos ter a certeza que o software realmente não continuará a ser desenvolvido após a primeira versão? Quantas vezes um sistema começa pequeno e quando vemos ele já está gigante e totalmente desorganizado?

Acredito que ter um software bem escrito vale a pena, mesmo quando o sistema só terá uma versão. Um software bem escrito normalmente apresenta menos bugs, o que por fim melhora a percepção do cliente e reduz o custo de retrabalho.

Balanceando os diversos fatores

No desenvolvimento de software sempre temos que balancear diversos fatores. Custos, prazos, expectativas do cliente, tecnologias envolvidas, etc. A qualidade do produto é inegociável, afinal, é por isso que o cliente está pagando. Mas, infelizmente,  nem sempre a qualidade do código tem a devida atenção.

Precisamos ver que a qualidade do código acaba refletindo na qualidade do produto. Um software com difícil manutenção ou com bugs acabará reduzindo o valor provido ao cliente.

A questão é balancear os diversos fatores, tentado otimizar ao máximo os recursos para obtenção da qualidade máxima. E não esquecer de dar a devida atenção a qualidade do código, que influencia na qualidade do produto.

Nu – gerenciamento de pacotes em .NET

UPDATE: o projeto Nu deu lugar ao NuPack, que conta com o apoio da Microsoft. Veja maiores informações aqui.

Quando desenvolvi pela primeira vez em Ruby, uma das coisas que mais me chamaram a atenção foi o gerenciamento de pacotes. Com o gem (gerenciador de pacotes do Ruby), instalar um pacote é simples assim:

gem install meu_pacote

Na plataforma .NET as coisas são um pouco mais complicadas. Para obter uma biblioteca normalmente temos que passar por uma série de passos:

• Procurar o site que contém a biblioteca;
• No site, achar o link para download da versão que queremos;
• Fazer o download;
• Descompactar a biblioteca;
• Copiar a biblioteca para o projeto.

Por quê ninguém tentou melhorar isso? Bem… vários projetos foram criados para tentar resolver esse problema, mas nenhum até o momento teve sucesso, seja por motivos técnicos ou por falta de adoção.

Recentemente surgiu a idéia: se o gem funciona tão bem, por quê não utilizá-lo na plataforma .NET? O projeto Nubular (ou simplesmente Nu) surgiu justamente para permitir que bibliotecas .NET usem o gem.

Instalando o RubyGems

Para usar o Nu é necessário ter o Ruby (ou o IronRuby) e o RubyGems. Se você já tem, pode pular par ao próximo tópico.

Primeiro instale o Ruby. Nesse link você pode fazer o download do instalador. Eu testei com a versão 1.8.7 que pode ser baixada diretamente aqui.

Para facilitar, adicione ao PATH (nas variáveis de ambiente) o diretório do Ruby.

Agora, instale o RubyGems. É só fazer o download do ZIP nesse link, descompactar, via linha de comando acessar o diretório descompactado e executar o seguinte comando:

ruby setup.rb

INSTALANDO O nu

Com o Ruby e o RubyGems devidamente instalados, instalar o Nu é simples, basta executar o seguinte comando:

gem install nu

Pronto, é só isso.

Usando o Nu

Para adicionar uma biblioteca ao seu projeto, acesse o diretório do projeto e execute o seguinte comando:

nu install meu_pacote

Onde “meu_pacote” é o nome da biblioteca a ser instalada.

Veja na imagem abaixo o StructureMap sendo adicionado ao projeto.

Ao instalar um pacote que tem dependências de outros pacotes, as dependências serão automaticamente instaladas. Ao instalar o FluentNHibernate, por exemplo, outros pacotes como o log4net, NHibernate e o Castle também são instalados.
Repare que na pasta do projeto foram adicionados os componentes e todas as suas dependências.

O que ele não tenta resolver

Ao usar diversas bibliotecas, cedo ou tarde acabamos enfrentando o famoso problema apelidado de DLL Hell.

Imagine a seguinte situação: uso a biblioteca A na versão 1.0 e a B na versão 2.0, porém a biblioteca A também usa a biblioteca B, mas na versão 1.5. Ou seja, eu preciso da biblioteca A v2.0 e a biblioteca B precisa da biblioteca A v1.5.

Esse é um problema que não tem como ser resolvido pelo simples gerenciamento de pacotes. Para resolver problemas assim, normalmente temos que usar binding redirect ou acabar recompilando o código.

Concluindo…

O Nu realmente facilita muito o gerenciamento de pacotes, agora resta aguardar para ver como será sua adoção. Nesse pequeno tempo de vida já há dezenas de projetos disponibilizados via Nu. Na página do projeto há uma lista deles.

Para maiores informações e para saber como criar seu pacote, acesse o site do projeto. No Herding Code (podcast a respeito de software) também há uma entrevista com os desenvolvedores do projeto.