Carlan+Calazans

Your token has already been used

Carlan Calazans — Tue, 13 Nov 2012 22:32:23 +0000

Your token has already been used

No dia 12 de Novembro de 2012, o game Minecraft alcançou a quantidade de 8 milhões de cópias vendidas para PC. Na página da Mojang, foi dito que este número ultrapassou a quantidade vendida de alguns jogos como Wow, CS, Diablo 2 e etc. Realmente o game é muito legal e interessante (não se deixe enganar pelo gráfico ruim).

Agora vem a parte interessante. O seu criador Markus “Notch” Persson, respondeu a notícia da seguinte maneira:

69I960EHE0A4A0IVG0EHE02500R4R0G1T30PLJ00V6V0EHE0V1U01V10U5U0VGV0V4R

É óbvio que é uma resposta encriptada. Após algumas tentativas de decifrar o segredo, desisti. Embora, tenha ficado de olho em uma página do reddit onde algumas pessoas também estavam tentando descobrir o significado dos caracteres acima.

Hoje, enquanto estávamos trabalhando, meu amigo Léo, já tinha compartilhado o link acima com ele, me disse que tinham descoberto o segredo. A resposta leva a um arquivo .7z protegido por senha contendo 1000 gift codes para um jogo que está sendo desenvolvido pelo Notch há algum tempo. Trata-se do 0x10c.

É bem provável que todos eles já tivessem sido utilizados, mas eu gostaria de tentar recuperar pelo menos um. Para esta tarefa preparei um script em bash (bem porco) para ler os códigos de um arquivo em texto, logar na página da mojang e submeter os dados em um formulário para a obtenção de gift codes.

#!/bin/bash

#account.mojang.com
USERNAME="user"
PASSWORD="passwd"

# loga e armazena o cookie
curl -s \
--data "username=${USERNAME}" \
--data "password=${PASSWORD}" \
--cookie-jar session \
--cookie session \
--user-agent "Mozilla/5.0 (X11; U; Linux x86_64; en-US; ..." \
--location \
https://account.mojang.com/login

# obtem o auth token do campo hidden
curl -s \
--cookie session \
--cookie-jar session \
--user-agent "Mozilla/5.0 (X11; U; Linux x86_64; en-US; ..." \
--header "Keep-Alive: 300" \
--header "Connection: keep-alive" \
--location \
https://account.mojang.com/redeem -o redeem.txt

TOKEN=$(sed -n -e 's//\1/p' redeem.txt | tr ">" "\n" | tail -n 1 | tr -d " ")

# testa os gift codes
for l in $(cat codes)
do
echo "Testing $l"
curl -v \
--cookie session \
--cookie-jar session \
--user-agent "Mozilla/5.0 (X11; U; Linux x86_64; en-US; ..." \
--data "code=${l}" \
--data "authenticityToken=${TOKEN}" \
--header "Keep-Alive: 300" \
--header "Connection: keep-alive" \
--location \
https://account.mojang.com/redeem/validate >> resposta.txt
echo "Done."
done

Aproveito para compartilhar

RubyConf Brasil – dia 2 (final)

Carlan Calazans — Thu, 28 Oct 2010 22:56:34 +0000

Segundo dia

É impressão minha ou sempre as melhores “coisas” ficam pro final? IMHO, o segundo dia, foi muito melhor que o primeiro. Os palestrantes estavam mais animados e o conteúdo das palestras foram muito interessantes (e não davam sono).

Palestras

O segundo dia começou com o Evan Phoenix (@evanphx) falando sobre Rubinius. Acredito que todos ficaram impressionados com as ferramentas de profiling. Achei muito estranho como os commits do projeto são organizados (ou não possuem organização). Logo depois do café, na sala 1, o Charles Nutter (@headius) subiu ao palco para falar sobre JRuby. Uma parte interessante da palestra aconteceu quase no final quando ele mostrou o JRuby rodando no emulador do Android através do Ruboto.

A palestra do David Chelimsky (@dchelimsky) foi bem divertida por que ele deu exemplos bem claros onde o princípio DRY se encaixa e onde não faz sentido aplicá-lo. Depois do almoço, na sala 2, o Rodrigo Franco (@caffo) fez um relato de como é a vida de um desenvolvedor que trabalha em casa para empresas estrangeiras remotamente. Ele apresentou também um conjunto de dicas e ferramentas que visam auxiliar desde como controlar suas horas trabalhadas até emissão de nota fiscal. Logo em seguida veio o Scott Chacon (@chacon) novamente, mas desta vez para falar sobre novidades e formas avançadas de utilização do git.

Depois do Coffee Break da tarde fui ver o Guilherme Silveira (@guilhermecaelum) e o Anderson Leite (@anderson_leite) com a palestra “O melhor dos dois mundos: funcional e orientado a objetos”. Os dois deram dicas bem bacanas sobre programação funcional. Pra finalizar o evento o Jim Weirich (@jimweirich) deu uma aula sobre um conjunto de princípios que melhoram um design orientado a objetos.

Conclusão

Como muitos, também acredito que este evento é único. O nível das palestras, a organização, a disposição dos participantes e o respeito a outras linguagens de programação. O nível de respeito foi tanto que não consigo comparar com o ano passado, onde muitos palestrantes fizeram piadas de outras linguagens. A organização do evento teve alguns problemas com a rede wifi e o ar condicionado, mas nada que atrapalhasse alguém a assistir uma palestra. Estes pequenos problemas sempre vão existir aos olhos de alguém. Resumindo, gostei muito do evento e volto o ano que vem sem pensar.

RubyConf Brasil

Carlan Calazans — Tue, 26 Oct 2010 23:41:35 +0000

Primeiro dia

É muito bom estar de volta a São Paulo e ter a oportunidade de respirar ar novo. Este ar novo vem acomanhado de novas idéias, novas amizades e conhecimento. O RubyConf (antigo Rails Summit Latin America) é o único evento, fora do Espírito Santo, que faço questão de comparecer todos os anos.

Palestras

O dia começou com o Fábio Akita (@AkitaOnRails) dando uma geral no Ruby e no Rails do passado até os dias atuais. Uma parte legal desta palestra foi o comentário sobre prática e o poder de uma idéia. Em seguida, na sala 1, foi a vez do Yehuda Katz (@wycats) subir ao palco e falar sobre o lado do cliente no desenvolvimento de aplicações onde o foco é server-side. Boa parte das dicas que ele mencionou estão em um post do blog da Caelum, recomendo a leitura.

A próxima palestra da sala 1 foi dada pelo Scott Chacon (@chacon) ao invés do Chris Wanstrath (@defunkt) como esperado. O assunto foi processos em background e como o pessoal do github resolveu este problema. Logo depois do almoço foi a vez do José Valim (@josevalim) falar sobre Rails 2.3, 3.0 e 3.1: passado, presente e futuro.

Continuando, na sala 2, foi a vez do Pedro Franceschi (@pedroh96) de apenas 14 anos falar sobre como integrar aplicações iPhone com Rails. Depois foi a vez do Lucas Húngaro (@lucashungaro) relatar suas dificuldades com aplicações Rails em produção e passar o conhecimento adiante de como resolver a maioria dos problemas que todos nós podemos encontrar.

Pra finalizar, a desconferência começou com o Luca Bastos (@lucabastos) apresentando como os desenvolvedores de hoje em dia são todos EMOs e os programadores de sua época é que eram machos. E a última palestra (que eu assisti) foi a do Fernando Vieira (@fnando) onde ele apresentou uma aplicação muito bacana feita com Rails + Nodejs.

Finalizando

Tive a oportunidade de encontrar novamente o William Molinari (@pothix) e este ano também a Letícia Figueira (_leticia), já conhecia ambos do rubylearning.org.

Amanhã tem mais

Ruby on Rails sem domínio

Carlan Calazans — Wed, 21 Apr 2010 07:51:03 +0000

Bateu uma sensação de dejá vu agora. No ano passado ocorreu o mesmo problema e vários desenvolvedores ficaram sem poder acessar o site. Acredito que o conteúdo mais acessado é a api do Ruby in Rails, pelo menos é o conteúdo que uso com mais frequência.

No ano passado não demorou muito tempo para o problema ser resolvido. Só nos resta aguardar.

Update:
O domínio .org foi renovado por 20 anos

Vitória merece

Carlan Calazans — Tue, 20 Apr 2010 01:06:33 +0000

Updated!

Podem marcar no calendário pois dia 29 de maio Vitóra/ES vai concentrar o número máximo de desenvolvedores já reunidos em um local. A intenção é mover a ilha pra um lugar com mais sombra já que o sol está tostando todos os capixabas. WTF?

O real motivo deste post

Na verdade não é bem isso. Realmente algo de muito bom vai acontecer em Vitória/ES no dia 29 de maio. Trata-se do evento Maré de Agilidade em Vitória/ES (ou Maré Vix) e a real intenção deste evento é reunir os interessados para trocar experiências e bater um papo sobre o tema. Alguns dos palestrantes já são conhecidos pela comunidade como você pode ver na figura abaixo:

Maré Vix - programação

A empresa em que trabalho (Highlan) é uma das patrocinadoras do evento junto com outras empresas (ou grupo de usuários) de grande nome (vide figura).

Maré Vix - patrocinadores

Se você se interessa pelo assunto, divulgue e apareça no evento!

Veja também:

Rapidinha: instalando o MicroXP no VirtualBox

Carlan Calazans — Tue, 15 Dec 2009 00:19:32 +0000

Resolvi escrever (ou tirar do draft) sobre algo que faz parte do meu dia-a-dia no trabalho, ou seja, lidar com máquinas virtuais. A pouco tempo atrás quando se falava em máquina virtual o que me vinha na mente era o aplicativo VMWare. De lá pra cá, eu só tinha lido sobre o assunto e feito somente 01 único teste. Até por que o VMWare é pago.

Pesquisando sobre o assunto e procurando uma solução livre, um ex-chefe me sugeriu dar uma olhada no VirtualBox. Sem dúvidas ele me pareceu bem melhor do que o Qemu, por exemplo. Não que este último seja ruim, mas uma das facilidades que eu precisava era acesso a rede e a configuração da interface do hospedeiro não era nada simples. Por outro lado, no VirtualBox, através da documentação encontrei as informações que precisava e tudo funcionou corretamente. Comecei a gostar desse aplicativo.

No início do ano passado a Sun comprou a Innotek, empresa que criou o VirtualBox. O aplicativo melhorou muito desde que a Sun assumiu. As atualizações ficaram mais frequêntes, a configuração de rede se faz com dois cliques do mouse, a documentação ficou mais clara e objetiva, dentre outras coisas.

Abaixo se encontra o vídeo de instalação, veja como o processo é simples

Get the Flash Player to see this player.

Download

Rapidinha: juntando várias imagens em uma

Carlan Calazans — Sun, 20 Sep 2009 23:36:45 +0000

Uns dias atrás precisei juntar várias imagens separadas em único arquivo para descobrir o que estava causando um espaçamento em um arquivo de saída postscript gerado através de uma aplicação que desenvolvemos na empresa em que trabalho. As imagens em questão compõem uma track (área gráfica) em um software de acompanhamento geológico desenvolvido para a Petrobrás, muito parecido com isto por sinal. Enfim, não necessariamente as imagens precisam fazer parte de um gráfico. No meu caso, como eu precisava de uma imagem orientada na vertical, as imagens deveriam ter as mesmas dimensões, seguir uma nomenclatura que eu pudesse trabalhar facilmemente e só

Como fazer coisas repetitivas semprem dão sono, na maioria das pessoas, resolvi criar uma pequenina classe em Ruby baseado no que eu escrevi aqui. Segue a classe em questão.

require 'rubygems'
require 'RMagick'

include Magick

class JoinImages

attr_accessor :source

def save(file)
@images = load_files
@images.write(file)
end

private

def load_files
@list = ImageList.new
Dir.entries(source).reject{|f| f =~ /^\./}.sort{|a,b| a.to_i<=>b.to_i}.each do |f|
@list.read "#{source}/#{f}"
end
@list.append(true)
end

end

#Usage:
#gif = JoinImages.new
#gif.source = 'img'
#gif.save 'track1.gif'

As minhas imagens foram salvas no formato “001.png”, “021.png”, “250.png” e assim por diante, ou seja, traduzindo temos “0″ como a track 1 (área gráfica 1) e “2″ como a track 3 (área gráfica 3), o resto é relativo a um contador.

Para montar a imagens final corretamente, existe uma ordenação no código, estou ordenando as imagem usando a parte numérica do nome do arquivo, como mencionado acima. É possível usar uma expressão regular para pegar somente as imagens que desejamos no bloco “reject” também.

Espero que seja útil pra alguém.

Trapaceando no Monkey Kick Off

Carlan Calazans — Mon, 11 May 2009 23:30:23 +0000

Monkey Kick Off é um game em desenvolvido em flash pela Totebo Interactive. O objetivo do game é ajudar um macaco a chutar a bola o mais longe possível ou pelo menos até a vila dos macacos a 4000 metros de distância. Para chutar a bola basta clicar com o botão esquerdo do mouse ou pressionar qualquer tecla no teclado.

Monkey Kick Off

Simples, não? A quem diga que até um macaco consegue

Análise do problema

É necessário um pouco de tempo até perceber que existem algumas variantes para conseguir chutar a bola a uma certa distância. Primeiro, há um momento, randômico, em que o macaco consegue levantar a bola até a altura máxima. Outra variante importante é o momento do chute. É preciso entender que existe um momento certo para se dar o chute. Este ponto fica entre a altura da cabeça e barriga do macaco.

Como a altura máxima da bola é randômico, esperar pelo momento certo pode levar muito tempo. O mesmo vale para a hora do chute, mas este é menos complicado, pois, pode ser calculado medindo o tempo gasto para a bola chegar no momento do chute.

Há outros fatores que também devem ser levados em consideração quando estamos jogando. As cores do game prejudicam a visão, se ficarmos olhando durante muito tempo os marcadores (os coqueiros ou a placa indicando que a vila dos macacos fica a 4000m) no plano de fundo começam a desaparecer. Se ficarmos muito tempo olhando para a tela, a visão pode ficar cansada e embaralhada.

A solução (ou a trapaça)

Depois de analisar o problema cheguei a conclusão que o meu computador pode fazer todo o trabalho por mim. Cheater, preguiçoso, eu?

Resolvi criar um bot afim de monitorar o game, mais precisamente a minha tela, processar as variantes e chutar a bola. Seria mais ou menos assim, acesso a página do game e inicio o jogo. Logo após, inicio o bot em um console, lembrando de minimizar todas as janelas menos o navegador e posso ir tomar um café enquanto o aplicativo fica rodando.

Como mencionado acima, não existe um tempo correto para a bola chegar no ponto mais alto. É possível abordar este problema de várias formas que vão desde análise de imagens (screenshots) a redes neurais. A técnica mais simples é a análise de imagens e é nela que vou implementar o bot.

Para registro, estou utilizando a resolução de 1024 x 768 em dois monitores de 17″. Independente da resolução o bot poderá ser criado. Já fiz todo o processo que vou explicar a seguir em um macbook e tudo funciona normalmente. Para isso é necessário seguir alguns passos que listo no próximo parágrafo.

Para começar, é preciso mapear a altura máxima que a bola pode chegar, leia-se distância entre o topo e a esquerda, em relação a sua área de trabalho. Em seguida, recorte a imagem da bola de acordo com o passo anterior, pois, ela gira em seu eixo. Estes são os passos necessários para calibração do bot.

As etapas anteriores são um tanto quanto chatas, mas as que vem a seguir serão bem mais interessantes. Com a imagem da bola podemos compará-la com o screenshot que vamos tirar do ponto mapeado. E por último, se as imagens forem iguais, aguardamos o momento do chute e chutamos.

É claro que podem haver várias maneiras de se implementar os passos citados acima. Não estou levando em consideração o desempenho, pois, em todos os meus testes o desempenho foi suficiente. Inclusive se você que está lendo tiver alguma sugestão, por favor, sinta-se a vontade para compartilhar.

Agora, um pouco de código.

Passo 1 e 2 (calibração)

Tire uma screenshot do navegador com o game iniciado (foto abaixo), com um software de edição de imagens meça a distância do topo (padTop) e esquerda (padLeft) do canvas do game (linhas azuis).

Mapeamento

Agora, configure a classe para tirar fotos somente do canvas, encontre a imagem do ponto (linhas vermelhas) mais alto que a bola pode chegar analisando todas as imagens e, por último, com um software de edição de imagens meça novamente a distância do topo e esquerda, mas desta vez em relação a bola. Essa é uma das partes chatas.

Segue abaixo a classe para tirar fotos do game canvas.

TakeShoots.java (canvas)

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.awt.image.*;
import javax.imageio.*;

public class TakeShoots {
private BufferedImage image;
private Robot robot;
private int padLeft, padTop, w, h;

public TakeShoots() {
// settings for game canvas
padLeft = 185;
padTop = 209;
w = 640;
h = 480;

// settings for ball
//padLeft = 322;
//padTop = 431;
//w = 46;
//h = 46;

try {
robot = new Robot();
} catch (AWTException e) {

}

System.out.println("Waiting 5 seg...");

try {
Thread.sleep(5000);
} catch (InterruptedException e){

}

System.out.println("Initializing thread...");
TSThread t = new TSThread(3000);
t.start();

}

class TSThread extends Thread {
int howManyTimes;
File file;

TSThread(int times) {
this.howManyTimes = times;
}

public void run() {
for(int i = 0; i <= this.howManyTimes; i++){
image = robot.createScreenCapture(new Rectangle(padLeft, padTop, w, h));
file = new File("image"+i+".png");
//file = new File("ball"+i+".png");

try{
ImageIO.write(image,"png", file);
}catch(IOException e){

}

file = null;
image = null;

try {
Thread.sleep(100);
} catch (InterruptedException e){

}

}
}
}

public static void main(String args[]){
new TakeShoots();
}
}

Com a imagem do passo 1, recorte a imagem da bola no ponto mais alto em formato de quadrado. A bola possui o tamanho 46×46. Salve este arquivo com o nome ball.png no diretório do arquivo java. No meu caso a screenshot do game canvas em que a bola chega no ponto mais alto e a imagem da bola (ball.png) podem ser visualizadas abaixo:

Ponto mais alto

Bola

Se desejar, alterando a classe TakeShoots.java, podemos automatizar o processo tirando screenshots somente da bola, é uma forma de ter certeza que é o ponto mais alto também. Para isso faça:

TakeShoots.java (ball)

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.awt.image.*;
import javax.imageio.*;

public class TakeShoots {
private BufferedImage image;
private Robot robot;
private int padLeft, padTop, w, h;

public TakeShoots() {
// settings for all game canvas
//padLeft = 185;
//padTop = 209;
//w = 640;
//h = 480;

// settings for ball
padLeft = 322;
padTop = 431;
w = 46;
h = 46;

try {
robot = new Robot();
} catch (AWTException e) {

}

System.out.println("Waiting 5 seg...");

try {
Thread.sleep(5000);
} catch (InterruptedException e){

}

System.out.println("Initializing thread...");
TSThread t = new TSThread(3000);
t.start();

}

class TSThread extends Thread {
int howManyTimes;
File file;

TSThread(int times) {
this.howManyTimes = times;
}

public void run() {
for(int i = 0; i <= this.howManyTimes; i++){
image = robot.createScreenCapture(new Rectangle(padLeft, padTop, w, h));
//file = new File("image"+i+".png");
file = new File("ball"+i+".png");

try{
ImageIO.write(image,"png", file);
}catch(IOException e){

}

file = null;
image = null;

try {
Thread.sleep(100);
} catch (InterruptedException e){

}

}
}
}

public static void main(String args[]){
new TakeShoots();
}
}

Passo 3

Com a imagem do passo 2 compare com outra imagem de tamanho 46×46 (ou não). Faça os testes você mesmo, compare a imagem calibrada (ball.png) com qualquer outra 46×46 no formato png. Faça também a comparação de ball.png com ela mesma e veja o resultado.

Estou utilizando uma forma bem simples para identificar se as imagens são iguais. Como se trata de uma imagem de tamanho pequeno, a comparação é feita pelos valores RGB das duas imagens pixel a pixel. Caso a imagem fosse maior que 46×46, uma outra forma seria, traçar linhas horizontais / verticais ou nas diagonais e comparar os valores RGB somente daqueles pontos. Em softwares de detecção de movimento é possível aprender muitas formas de tratar este problema.

Ah, lembrando, as imagens devem estar no mesmo diretório do arquivo java quando executar a classe.

CompareImages.java

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.awt.image.*;
import javax.imageio.*;

public class CompareImages {
private BufferedImage image1, image2;
private String filename1, filename2;

public CompareImages() {
loadImages();

long started = System.currentTimeMillis();
boolean result = compareImage(image1, image2);
System.out.println( (System.currentTimeMillis()) - started + " ms.");
System.out.println("Result: " + result);
}

private void loadImages(){
filename1 = "ball.png";
filename2 = "ball.png";

try{
image1 = ImageIO.read(new File(filename1));
image2 = ImageIO.read(new File(filename2));
}catch(IOException e){

}
}

private boolean compareImage(BufferedImage image1, BufferedImage image2) {
if(image1.getWidth() != image2.getWidth() || image1.getHeight() != image2.getHeight())
return false;

for(int x = 0; x < image1.getWidth(); x++) {
for(int y = 0; y < image1.getHeight(); y++) {
if(image1.getRGB(x, y) != image2.getRGB(x, y))
return false;
}
}
return true;
}

public static void main(String args[]){
new CompareImages();
}
}

Passo 4

Junte todos os passos anteriores em uma nova classe, quando a classe detectar que as imagens são iguais pressione e solte o botão esquerdo do mouse. Aproveitei este passo e criei um arquivo de configuração que é lido somente ao executar a classe em questão, isso evita recompilar o arquivo java só para ajustar os valores de configuração.

KickOffTrick.java (final)

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.awt.image.*;
import javax.imageio.*;
import java.util.*;

public class KickOffTrick {
private Properties properties;
private final String propertiesFileName = "kickoff.properties";
private BufferedImage ball1, ball2;
private Robot robot;
private int padLeft, padTop, w, h;

public KickOffTrick() {

readPropertiesFile(propertiesFileName);

padLeft = Integer.parseInt(properties.getProperty("paddingleft"));
padTop = Integer.parseInt(properties.getProperty("paddingtop"));
w = Integer.parseInt(properties.getProperty("shootwidth"));
h = Integer.parseInt(properties.getProperty("shootheight"));

try{
ball1 = ImageIO.read(new File(properties.getProperty("ballimagefilename")));
}catch(IOException e){
e.printStackTrace();
}

try {
robot = new Robot();
} catch (AWTException e) {
e.printStackTrace();
}

System.out.println("Waiting 5s...");
System.out.println("Prepare yourself...");

try {
Thread.sleep(5000);
} catch (InterruptedException e){

}

System.out.println("Initializing thread...");
TSThread t = new TSThread();
t.start();

}

private void readPropertiesFile(String filename){
properties = new Properties();
try {
properties.load(new FileInputStream(filename));
} catch (IOException e) {
e.printStackTrace();
}
}

class TSThread extends Thread {
boolean result;

TSThread() {

}

public void run() {
while(true){
ball2 = robot.createScreenCapture(new Rectangle(padLeft, padTop, w, h));
result = compareImage(ball1, ball2);

if(result){
try {
Thread.sleep(Integer.parseInt(properties.getProperty("sleepbeforekick")));
} catch (InterruptedException e){
e.printStackTrace();
}

robot.mousePress(InputEvent.BUTTON1_MASK);
robot.mouseRelease(InputEvent.BUTTON1_MASK);

try {
Thread.sleep(Integer.parseInt(properties.getProperty("sleepafterkick")));
} catch (InterruptedException e){
e.printStackTrace();
}
}

ball2 = null;

try {
Thread.sleep(Integer.parseInt(properties.getProperty("sleepballshoot")));
} catch (InterruptedException e){
e.printStackTrace();
}

}
}

private boolean compareImage(BufferedImage image1, BufferedImage image2) {
if(image1.getWidth() != image2.getWidth() || image1.getHeight() != image2.getHeight())
return false;

for(int x = 0; x < image1.getWidth(); x++) {
for(int y = 0; y < image1.getHeight(); y++) {
if(image1.getRGB(x, y) != image2.getRGB(x, y))
return false;
}
}
return true;
}
}

public static void main(String args[]){
new KickOffTrick();
}
}

O arquivo de configuração ficou assim:

kickoff.properties

# ball left distance
paddingleft = 322
# ball top distance
paddingtop = 431
# ball shoot width
shootwidth = 46
# ball shoot height
shootheight = 46
# ball filename (for comparation)
ballimagefilename = ball.png
# sleep before kick the ball in ms
sleepbeforekick = 110
# sleep after kick the ball in ms
sleepafterkick = 10000
# sleep interval for take another shoot
sleepballshoot = 50

Não utilize os valores pré-selecionados, eles só estão preenchidos para você ter uma cola.

Concluindo

Talvez com este exemplo você não consiga bater nenhum record, mas vai ter a oportunidade de aprender coisas novas e interessantes. Eu me diverti pensando em como implementar a solução, espero que você se divirta lendo (ou fazendo todos os passos)

Em breve os arquivos estarão no github.com se alguém se interessar.

Ruby calculando o dia da Páscoa

Carlan Calazans — Fri, 10 Apr 2009 23:06:46 +0000

A Páscoa é uma data comemorativa que serve de referência para datas comemorativas móveis como Carnaval, Quaresma, Corpus Christ e outras. Por isso é importante saber quando a Páscoa vai ser comemorada. Além de interessante, serve como uma brincadeira para os garotos(as) de programa de plantão que não tem nada para fazer no feriado.

Cálculo

No total são três formas de calcular a data da Páscoa. A primeira é recorrendo a uma tabela, a segunda é através ao algorítimo de Gauss para o intervalo de anos que se inicia em 1900 e termina em 2099 e a terceira com o algorítimo de Meeus / Jones / Butcher. Como exemplo, optei pela segunda forma por ter umas condições e por ela ser mais elaborada. Para quem se interessar, os algorítimos serão relacionados no final deste texto.

#!/usr/bin/env ruby

require 'date'

FIELDS = %w{Carnaval Pascoa Corpus\ Christ}

ano = 2009 #change me

x = 24
y = 5

a = ano % 19
b = ano % 4
c = ano % 7
d = (19 * a + x) % 30
e = (2 * b + 4 * c + 6 * d + y) % 7

if (d + e > 9)
#april
dia = d + e - 9
mes = 4

#exceptions
dia = 19 if (dia == 26)
dia = 18 if (dia == 25 && d == 28 && a > 10)
else
#march
dia = d + e + 22
mes = 3
end

dt = Date.new(ano, mes, dia)

result = []
result << dt - 47
result << dt
result << dt + 60

FIELDS.each do |d|
puts "#{d}: #{result.shift.strftime("%d-%m-%Y")}"
end

Este texto tem uma pegadinha. Na verdade, meu intuito com ele não é ensinar Ruby nem mostrar como se calcula o dia da Páscoa. Foi uma forma que encontrei de mostrar como a linguagem chega perto do idioma, como poucas linguagens o fazem. Qualquer pessoa é capaz de entender as fórmulas matemáticas e relacioná-las com o exemplo mostrado. Sim, existe um açúcar, mas é fácil de entendê-lo também.

A maior parte do tempo, parece que estamos conversando com um editor de textos.

Referências:

Rapidinha: GIF animado com Ruby

Carlan Calazans — Wed, 01 Apr 2009 19:50:15 +0000

A algumas horas atrás estava tentando criar um gif animado para o twitter. Esbarrei com uma solução usando Gimp, sugestão do oráculo. Fiz o gif animado. Alguns minutos depois, o lembrei de uma gem para Ruby chamada RMagick para processamento de imagens. Como nunca a tinha experimentado eis que veio a idéia de escrever uma classe para criar um gif animado.

A gem RMagick é baseada na biblioteca de imagens Image Magick comumente conhecida no mundo Linux pelo poder de seus utilitários em linha de comando. É, linha de comando, sem a necessidade de Gimp, FW, PS e similares. Quem nunca ouviu falar de import ou convert?

A classe em questão é a:

require 'rubygems'
require 'RMagick'

include Magick

class AnimatedGif

DELAY = 100
LOOP = 0

attr_accessor :source

def save(file)
load_files
@list.delay = DELAY
@list.iterations = LOOP
@list.write(file)
end

private

def load_files
@list = ImageList.new
Dir.new(source).entries.reject{|f| f =~ /^\./}.each do |f|
@list.read "#{source}/#{f}"
end
end

end

#Usage:
gif = AnimatedGif.new
gif.source = 'img_src'
gif.save '/tmp/animated.gif'

O delay entre as imagens está fixo no código. O loop é infinito, ou seja, seu gif ficará se repetindo a vida toda. Após criar um objeto da classe AnimatedGif é necessário informar um diretório com imagens estáticas para gerar o gif animado. E por último, é só chamar o método save passando o caminho do arquivo gif final.

Demorou uns dois minutos a mais depois do entendimento da solução em Gimp para gerar esta classe em Ruby. Foram uns 3 minutos para entender a técnica do Gimp e 5 minutos para criar a classe em Ruby. A linguagem não morde!