Ruby ao resgate

06.março.2009
Estou meio sumido, fazendo o projeto andar apesar dos gols contra, e chafurdando no Rails.

Fica uma dica para quem também está começando a se divertir no Ruby. Para executar um processo que pode causar uma exceção, podemos proteger o código usando rescue, assim como em C++/Java temos o try/catch:

begin
  file = open("arquivo")
rescue
  msg = "Arquivo não pode ser aberto"
  logger.error msg
  show_message :error => msg
end

Simples, não?

Anúncios

питона ou Рубин?

13.fevereiro.2009
Reclamaram a respeito do meu post sobre tradução do NetBeans.

Ok. Pense que você está num escritório no exterior e precisa programar no NB. Aparecem as opções питона e Рубин para você escolher a linguagem de programação.

E agora, José?

Ah, mas você não está programando na Rússia. Ok, pode ser. Mas na empresa onde trabalho não é incomum você utilizar um sistema operacional ou mesmo o Eclipse em francês, por exemplo.

Fica a dica para quem sentir a necessidade.


Instalando Rails no Windows através de um proxy HTTP

11.fevereiro.2009
O título em si é maior que o post, mas vamos lá.

Instalei o Ruby numa máquina que acessa internet através de um proxy HTTP. A conexão não é transparente e todo software que eu instalo na máquina precisa ser configurado para se conectar corretamente.

Após instalar o Ruby, seja lá como você queira (eu instalei usando o ‘one-click-installer‘, execute:
set HTTP_PROXY=http://192.168.6.1:3128

gem install rails

E dê Enter em todas as opções, na falta de um “Yes to all”.

Após alguns instantes, para utilizar a última versão das bibliotecas, digite:

gem update --system

Finalizando, caso você queira utilizar Mongrel ao invés do WEBrick (eu recomendo), você executa:

gem install mongrell

Simples assim. Agora é só se divertir, sorrir e brincar.


The Shark Jumper

22.janeiro.2009

“Zed Shaw (…) is the author the Mongrel web server, creator of the Utu project, recent Factor convert, and absolutely hates Ruby even though he makes money on it.”

Sujeito ganhou ponto comigo depois dessa.


Obama

20.janeiro.2009
ObamisEstava pensando aqui, enquanto a aplicação compila e me veio uma associação meio torta: seria Obama o novo Ruby na presidência americana?

O Ruby foi (e por alguns ainda é) tido como a grande salvação do desenvolvimento de software. É fácil de utilizar, fácil de entender e faz com que você pareça cool, ao contrário do paquidérmico, verboso e velho Java.

Por outro lado, é uma linguagem que eu não consigo levar a sério. Tanto pelo hype, quanto pela imaturidade. Trouxe excelentes “novas” idéias, ótimas soluções para problemas que a maioria das pessoas fazia de conta que não estavam lá, mas corporativamente continua com o status de ‘brinquedo’.

Honestamente, espero que ele (o Obama) faça um excelente trabalho, deixe muita coisa boa para as futuras gerações, mas não acho que ele seja o novo Messias, como está sendo propagandeado por aí.

Nem ele, nem qualquer outra linguagem da moda.


Hail for Grails

19.janeiro.2009
Infelizmente não estou tendo o tempo que gostaria para investir no Clojure. Porém, por uma coincidência, surgiu uma oportunidade para trabalhar com Grails (Groovy on Rails), uma versão Groovy do consagrado framework para Ruby.

Minha primeira impressão foi muito boa. Para montar um CRUD, são necessários menos de cinco minutos, caso você nunca tenha mexido antes com o framework.

“Ah, mas o Rails também tem isso”. Claro que tem, afinal de contas, o Grails é um ‘clone’ que roda com Groovy. É possível gerar um arquivo .war e publicar a aplicação num servidor Tomcat, como uma aplicação Java normal. Por trás dos panos, o que acontece é exatamente compilar o código Groovy para Java, e o Java para o bytecode da JVM. Caso você tenha uma aplicação Rails, pode também utilizar o JRuby para o mesmo fim.

Outro ponto que me chamou a atenção no Grails (ou no Groovy, se preferir) são as contraints. São checagens que você codifica na própria entidade, que funcionam como validações automáticas dos dados inseridos. Numa tela de login, por exemplo, você pode ter uma entidade User e informar que login é único, não pode estar em branco e deve ter entre 5 e 20 caracteres, por exemplo. Tudo isso em uma ou duas linhas de código facilmente legível.

Como o trabalho deve ser entregue rapidamente, não vou ter muito tempo de fuçar e experimentar funcionalidades não usuais, mas com certeza o framework já entra para a minha lista de ferramentas preferidas.

Aos mais puristas, deixo meu compromisso de estudar Ruby e olhar o Rails com mais atenção, já que, ao que me parece, esses frameworks atendem plenamente às minhas necessidades.


Sem comentários

11.dezembro.2008
Antes de mais nada: o que vou escrever aqui não se aplica a linguagens de ‘baixo nível’, como Assembly, por exemplo. Se você utiliza Java, Delphi, C#, Ruby ou qualquer outra que possa ser chamada de ‘alto nível’, pode continuar lendo.

Comecemos com uma ordem: não comente seu código.

Plaft. O impacto da ordem e os trolls agitam os dedos para começar a criticar.

Para que servem os comentários no código? Ensinaram na escola que é para informar suas intenções aos outros programadores. Teoricamente, quando o próximo coitado abrir o seu código, ele vai entender perfeitamente todas aquelas amarrações e voltas lógicas que você deu no código, apenas se guiando pelos comentários. Genial, não?

Agora, me mostre um só código legado, daqueles sem testes e que passaram na mão de pelo menos vinte estagiários, que tem os comentários perfeitamente atualizados e consistentes com a abordagem utilizada no código. Pois é, esse é o segundo problema que encontramos ao usar comentários. O primeiro, se você ainda não percebeu, é o retrabalho de ter que escrever código e em seguida escrever comentários para explicar o que o código faz.

Claro que ainda não te convenci. Anos de vício não se perdem em uma leitura. “Tudo bem, é só apagar aquele comentário que não faz sentido”. Vou usar um exemplo que encontrei aqui mesmo, no projeto em que trabalho.

O que a linha abaixo quer dizer?

int t = 0;

Nem mais, nem menos. Para mim, está sendo declarada e inicializada uma variável t. Para que serve, eu não faço idéia.

Vamos então comentar o código. Claro, assim o próximo sujeito que der manutenção nesse código vai entender perfeitamente o que estou tentando fazer aqui.

// tentativas de login
int t = 0;

Opa, bem melhor agora, não concorda? É óbvio que t é exatamente a mesma coisa que tentativas de login. Claro. Como não pensei nisso antes? Assim, no meio do código, basta você encontrar a variável, voltar ao local onde ela foi declarada e ler o porquê dela existir. Ou então, você pode ser uma pessoa bem legal e comentar cada linha onde a variável é utilizada. Se você for mais legal ainda, logo você terá um código de 300 linhas, sendo que 160 delas são só comentários. Legal mesmo.

Só que eu não sou um cara legal. Eu tenho preguiça de escrever comentários. Eu acho que um código de 300 linhas com 160 linhas de comentário é uma nojeira difícil de ler. Eu acho uma perda de tempo ter que reescrever comentários para cada linha que eu altero do código. É demorado, pouco produtivo e sujeito a erros. “E então, espertão. Como você faria?”

int tentativasDeLogin = 0;

Que tal assim? Sem comentários, sem nenhuma explicação adicional. Apenas código, puro e simples. O código se torna uma forma clara e concisa de documentação.

Ferramentas como NetBeans, Eclipse e Visual Studio, automatizam o ato de renomear um membro da classe dentro do escopo correto, o que honestamente, me faz desacreditar em qualquer argumento a favor do uso de comentários em detrimento da legibilidade do código.

Por falar em legibilidade, vou começar a inserir linhas entre os parágrafos. Pelo menos para mim isso ajuda muito na hora de ler textos maiores. Espero que te ajude também.

😉