Meu Primeiro Jogo

Eu sou um cara louco. Tenho plena consciência de minha enfermidade mental. Quero fazer tantas coisas ao mesmo tempo, que acabo viajando em várias ideias que nunca colocarei em prática. E, obviamente, neste exato momento acaba de surgir uma ideia muito, mas muito louca em minha mente. E eu vou encarar a loucura! Aliás, esta ideia sempre esteve em minha mente, como uma voz suave que me lembra o comercial da Garoto: “Compre Battom, Compre Battom, Compre Battom, Compre Battom!”. No meu caso, entretanto, a ideia não é comer chocolate. Aliás, não curto doces. Não combinam com cerveja. A ideia que sempre esteve martelando em minha cabeça é: Faça um Jogo. E juro que já tentei cumprir esta missão. Em vão. Primeiro, tentei criar uma engine de jogos em Java. Trabalho árduo. Criei o projeto no Eclipse, criei as abstrações, li livros sobre o assunto, mas, na hora H… Projeto suspenso devido a outras prioridades (ganhar dinheiro!).

Desta vez, contudo, minha loucura irá para frente e pretendo fazer diferente. Bem diferente, aliás. Primeiro, a ideia de criar uma engine não está mais em cogitação. Existem muitas por aí e agora, com as ideias mais maduras, percebo que fazendo um jogo usando uma engine de terceiros me dará a oportunidade de contribuir com outras pessoas. Outros projetos. E é isto o que pretendo e apoio que todos façam. Segunda questão, eu sempre achei que tinha que fazer o jogo todo para só depois avisar para as pessoas jogarem. Aprendi que a filosofia de baby steps aplica-se a este cenário perfeitamente. Posso ir liberando o jogo à medida em que estou fazendo. Digamos, posso fazer uma fase e lançar a versão 1.0 Beta 2, contemplando mais esta fase.

Agora, a ideia mais louca de todas. O jogo deverá manter um Rank online e à medida em que as fases são liberadas, as pessoas poderão jogar e acumular pontos. E para que acumular pontos? Para ganhar um prêmio, oras bolas. E qual prêmio? Ainda não sei. Mas algo significativo. Tipo um jogo de PS3, um Livro, Camisa Nerd e coisas deste tipo. Outro detalhe importante é que estarei informando passo a passo os detalhes do projeto, como a engine usada, as imagens que irão compor o jogo e as dificuldades e soluções encontradas. Isto vai ao encontro de minha filosofia de vida: compartilhar o conhecimento sempre. E de grátis.

E vamos começar a loucura! Primeiro, a engine escolhida foi a GTGE (Gold T Game Engine). É opensource e está disponibilizada no Google Code. Já rodei uns exemplos. Já li a documentação e gostei. Existem outras opções, mas pretendo iniciar minha aventura com ela. Depois, quem sabe, podemos ir mudando. Segunda questão, a estória do jogo. Eu sempre fui fã de Ultima 7 e Ultima 8 – Pagan. Mas não serei tão pretensioso assim. Mas será um jogo estilo RPG com visão isométrica, onde charadas e mistérios serão resolvidos e que lhe farão acumular pontos para ganhar o tão cobiçado prêmio. 🙂 Não sabe como é uma visão isométrica? Veja a imagem aí embaixo, é do jogo Ultima 8.

Terceira questão: as imagens. Eu sou péssimo designer. Ainda mais para desenhos isométricos… fora de cogitação eu mesmo fazer os gráficos. Roubar imagens de outros jogos… não, muito menos. 🙂 Pagar. Também não. Existem “imagens opensource”? SIM! Há almas caridosas no mundo do design gráfico! Que bom! E vou usar os gráficos destes caras, uma vez que não me importo se você encontrar outro jogo por aí usando os mesmos tiles e sprites que o meu. E um detalhe, não será uma beleza de jogo, tá bom? Será um jogo para saciar meu ímpeto de fazer jogos. E porque os prêmios? Uma forma de chamar a atenção das pessoas para que critiquem, ajudem e joguem! 🙂 E porque logo agora você resolveu tocar esta ideia? Foi quando vi o jogo do Abraão Isvi: Toupety. Fica aí a sugestão e até o próximo capítulo desta odisséia.

Comunidades ou Terceirização ?

Utilizarei meu indicador direito para tocar em um assunto delicado: como vejo a participação e o entendimento de uma boa quantidade de brasileiros, e aí incluo principalmente as empresas brasileiras, com o software livre e suas comunidades. Antes gostaria de reforçar uma diferença conceitual que enxergo, apesar de minha miopia. A visão de comunidade, e a ajuda a esta comunidade em prol de um bem em comum, e uma visão particular sobre um princípio específico que está incluído no software livre, e que citarei nas próximas linhas para tentar que vocês leiam mais um pouco deste (des)interessante post.

Vou lhes explicar. A questão é que Richard Stallman e os idealizadores do software livre não condenam, conforme meu minguado conhecimento sobre o assunto, que um software seja copiado, seguindo as regras da licença GPL (ou similares), e modificado. É o fork. O fork não é condenável nesta visão. Ao contrário, é até, de certa forma, motivado. A ideia de comunidade, embora seja no software livre onde mais se destaca na nossa área, enseja um comportamento diferente. Você tem uma necessidade que já é parcialmente atendida por um software sustentado por uma comunidade? Então, não faça um fork. Ajude! Seja agregador. Não seja apenas um cliente do software livre, seja um colaborador. Não faça um fork, pois você poderia estar ajudando a solução atual a se tornar ainda melhor.

Mas, vou voltar mais incisivamente ao assunto do tópico. Uma questão está mais do que clara para mim. Mais até do que Michael Jackson quando lançou o clipe Black and White. Nossas empresas estão pouco se importando para a ideia de comunidades. A verdade é clara e, neste caso, não está lá fora: as comunidades de softwares livre servem apenas como uma forma de terceirizar um serviço do qual a empresa não se vê com competência ou fôlego para fazer. Vou mais além, se há fôlego para fazer, o faz sem ajudar os criadores da ideia inicial, mas criando sua própria solução a partir da ideia dos outros. Fork!

Ainda há outra vertente. As pessoas não ajudam. Elas dizem o que está errado. O que já é algo louvável. Mas, mais louvável ainda é propor a solução. Achar o erro e já levar para os autores do software uma proposta para solucionar o problema é o que chamo de “a essência da colaboração em comunidades de software livre“. Infelizmente, é um mundo distante.

Voltando à questão dos forks: isto é condenável? Não há problemas, se você for considerar a ideia inicial de que um fork é algo normal. Mas, da forma como é feito hoje, é condenável, sim. A colaboração entre os membros de uma comunidade só tende a agregar valor para ambas as partes. A ajuda mútua sempre traz mais benefícios para ambos os lados. Quanto mais mãos e cérebros inteligentes atuando por um objetivo em comum, melhor. Só faça um fork se os autores do projeto inicial forem cabeça dura e não aceitarem ajuda externa. Antes, esvazie todas as alternativas disponíveis para você. Não havendo retorno para seus esforços, então fork neles! Mas deixe isto claro para todos, para que entendam sua motivação e não lhe encarem como um desagregador.

E porque as coisas são assim? Ainda nos falta esta cultura. E isto já vem de longe. Muito longe. O brasileiro sempre usou programas piratas e nunca sentiu vergonha disto. E isto é desde o Pentium 1, ou vai me dizer que sua cópia do Windows Workgroups era original? Oitenta por cento de chances de que não era. E o que pirataria tem a ver com isto tudo? Vou ser sincero, eu só quis deixar um gancho para dizer que as empresas brasileiras atuam como os “Piratas do Software Livre”. Você vai me dizer: seu maluco, que frase sem sentido! É, você tem razão, eu acabei de inventá-la.

E a ideia que quero passar com a frase é a seguinte: quando você usa um “aplicativo pirateado”, você está jogando fora todo esforço daqueles que suaram para lhe entregar uma solução para seus problemas. Não concorda que o software seja pago? Não use. Para mim é simples assim. Quando você não colabora com uma comunidade, se tornando apenas cliente dela, literalmente “vampirizando“, você a destrói em sua essência. É um estaca de madeira no coração desta comunidade.

Este post está enorme e vou finalizá-lo com uma resposta que alguns poderiam me fazer: e porque você ainda continua disponibilizando suas aplicações como software livre já que a maioria só quer se aproveitar disto? Uma mera questão filosófica. Eu acredito no Software Livre. O conhecimento deve ser compartilhado. O que eu aprendi, eu quero compartilhar com os outros. Embora minha visão seja, em alguns momentos, pessimista, isto não quer dizer que eu ficarei parado aguardando passivamente que as coisas mudem. E este post é um passo nesta direção.

Concorda comigo? Sim? Mais ou menos? Deixa seu comentário!

Considerações sobre Workflows

O primeiro projeto em que participei no Serpro, assim que fui aprovado no concurso em 2006, era um super Workflow. Documentos que precisavam ser criados, revisados, aprovados, enviados para parecer e outras dezenas de situações. Fora as milhares de regras para definir quem vai executar uma determinada tarefa no documento. E o que dizer da quantidade de perfis e papeis? Era, e ainda é, pois ainda está em desenvolvimento, um mega sistema de Workflow. Até então, eu nunca havia sequer notado a existência de Workflows. E também já havia feito sistemas similares como, por exemplo, um sistema de comércio online e um sistema de notícias. Observando cuidadosamente, percebe-se que estes sistemas tem aspectos em comum: entidades que mudam de situação, pessoas que devem executar tarefas, e-mails que devem ser enviados, sistemas externos que devem ser acionados, etc.

A partir deste momento, fiquei de olhos mais atentos aos sistemas em que eu participava ou ajudava, sempre notando que muitos tinham características de Workflow, mas a equipe pouco percebia este detalhe importante. Para muitos, Workflow é algo mais relacionado aos negócios da empresa em que trabalha e a automatização destes negócios. Parece algo distante. Uma tecnologia meio alienígena e que vai complicar mais do que ajudar em seu projeto. Para piorar, ainda há uma sopa de letrinhas e conceitos que confudem ainda mais o cidadão: BPM, SOA, EBP, Orquestração de Serviços, Coreografia entre Serviços, entre outros.

De fato, a visão de que Workflow está relacionado às questões macro da empresa, envolvendo automatização do seu fluxo de trabalho, é verdadeira, mas, isto é só uma vertente. Não pretendo tocar neste assunto, pelo menos não agora. O que me interessa agora são os desenvolvedores de sistemas, aqueles caras que ouvem as necessidades de seu cliente e que precisam tomar a melhor decisão sobre como desenvolver o sistema do dito cujo. Imagine Arthur Dent, o Analista de Sistemas, ouvindo Ford Prefect, o cliente, dizendo para ele:

– Então, o José recebe a notificação de compra e tem que repassar pro seu gerente.
– Sim, continue… – diz o analista.
– Aí o gerente aprova e repassa pra Carla do almoxarifado ver se tem estoque – diz o cliente, imaginando que já disse tudo e que o sistema já pode começar a ser feito.
– Certo, e a Carla faz o quê?
– Ah sim, já ia esquecendo. Ela aí diz pro financeiro que está certo, que é pra creditar o cliente.

O Analista de Sistemas certamente pensou em Casos de Uso. E o projetista? Imaginou usar Java com Spring, persistir com Hibernate em um banco de dados Oracle com uma arquitetura em três camadas na Web, usando Java Server Faces (JSF). E eles estão errados? Sim! E também não! O que eu defendo é que se pode ganhar bastante em produtividade quando se utiliza uma metodologia diferenciada para projetar e implementar sistemas desta natureza. Mas, para isto, é necessário fortalecer nas pessoas as ideias (conceitos) sobre Workflows. Antes de mais nada, o Arthur Dent precisa ter o feeling, aquela sensação estranha em suas espinhas, algo que lhe diz: eu já vi isto antes! É um Workflow, cara!

“Sim, sabichão, então me indique o caminho das pedras!” Perdoe-me, pois eu não tenho a resposta exata para você. Não agora. Mas, eu estou escrevendo um artigo para o ConSerpro, um Congresso para os empregados do Serpro, sobre este problema e pretendo chegar a algo mais concreto. Percebo no Serpro que as equipes de desenvolvimento perdem a oportunidade de usarem técnicas específicas de projeto e programação para sistemas de Workflow. Não digo apenas usar uma engine de Workflow. Mas, como eu posso ganhar em produtividade quando eu sei que meu sistema é absolutamente um Workflow? Devo usar qual engine de Workflow e de que forma? Qual linguagem de definição de processos devo usar? Pronto. Escolhi a Engine e a linguagem de processos, agora como eu documento este fluxo?

As perguntas são muitas. As respostas, poucas. E as coisas pioram quando percebemos que a padronização na área de Workflows não é grandes coisas. Não é incomum ver engines de Workflow que não conversam entre si: um fluxo definido para rodar em uma, não roda, nem à base de marretadas, em outra. As APIs são absolutamente diferentes também! Agora, imagine tudo isto em uma empresa onde trabalham mais de 1000 desenvolvedores e com centenas de sistemas que poderiam usufruir das facilidades que um mero mecanismo de Workflow pode lhe proporcionar.

Contudo, infelizmente, a realidade não é esta. O que vemos são dezenas de diagramas de projeto e documentos de arquitetura que poderiam ser abstraídos favorecendo uma visão mais generalizada. Vemos centenas de linhas de código, como esta aqui:

public class RegraDeNegocioWorkflowSemNecessidade {
   public void aprovar(Documento documento) {
       if ( documento.getSituacao().getId().equals(SITUACAO_AAPROVAR) ) {
           // Enviar e-mail para o gerente.
           // Atualizar o banco de dados com a situação nova.
          // Chamar um Webservice e aguardar a resposta.
          // Processar a resposta do Webservice e decidir se o fluxo vai pra Aprovado ou Reprovado.
          // Enviar e-mail pro cliente dizendo a situação!
          // Fechar a transação.
          E aqui vai um monte de IF THEN ELSE WHILE FOR...
       }
   }
}

E isto tudo poderia ser descartado! E seu programador poderia ter poupado dezenas de linhas de código, pois todos estes tratamentos podem ser feitos com poucas linhas e uma boa engine ajudando! E você? Concorda comigo? Não? Então, deixe seu comentário!

EncomendaZ na Mídia

Opa! É com grande felicidade que anuncio que o EncomendaZ foi publicado em dois sítios de downloads de aplicativos. O primeiro em que o aplicativo apareceu foi o Baixaki.

O segundo sítio a publicar foi o Zigg. E não é o primeiro aplicativo meu que o Zigg publica. O VeículoZ também está lá! O link para download no Zigg é http://ziggi.uol.com.br/downloads/encomendaz. Só tenho muito a agradecer aos dois sites. Muito obrigado pela confiança. Ao Baixaki e o velho amigo Francis. E ao Ziggi que publicou em tempo recorde, sem burocracia excessiva.

Fica aqui apenas um ponto negativo: Superdownloads. Infelizmente o processo lá é super burocrático. Demora demais para publicar seu aplicativo, quase 2 meses. E ainda há regrar super rígidas o que praticamente lhe desanima em enviar aplicativos para lá.

Atualização em 18/06/2010

E o Superdownloads me surpreendeu. Acabei de receber um e-mail informando a inclusão do EncomendaZ lá. O que eu tinha escrito acima estava baseado na experiência que tive ao tentar incluir a biblioteca Alfred para download lá. Já espero 1 mês e alguns dias a avaliação deles se é possível ou não incluir a biblioteca. Sem respostas. Mas, desta vez, eles foram eficientes. O EncomendaZ aguardou muito pouco e já apareceu lá. Obrigado ao Superdownloads! Link para o aplicativo lá http://www.superdownloads.com.br/download/43/encomendaz/.

Interessante que após a publicação nos dois sites, os downloads já começaram a aumentar rapidamente! Espero que as pessoas que baixaram contribuam e ajudem os programadores de aplicativos livre a continuarem criando aplicativos. As vezes, um e-mail agradecendo já enche monstruosamente o ego do programador. Viu? Não precisa muito. 🙂

Atualização!
E acabei de receber um e-mail do Baixatudo me informando que acabaram de incluir o EncomendaZ lá também. Que legal. Eu conhecia o site e até tentei enviar ele para lá, mas não achei um link para isto. Mas eles mesmos resolveram incluir! Muito obrigado! Ah, o link para o download lá é: http://www.baixatudo.com.br/encomendaz

Rastreador de Encomendas (EncomendaZ)

Quinta-feira de folga. Sexta também não fui trabalhar. Noite em branco com dor de barriga. Durante a quinta, nada de cerveja ou comidas exóticas. Sem vontade de ler livros. Resolvi: vou fazer alguma coisa em Swing/Java para aprender alguma coisa desse troço. E fiz. Precisei de algumas horas de Copy+Paste de códigos na Internet, um pouquinho de ajuda do Alfred e tcham tcham tcham…

Senhores, apresento-lhes o EncomendaZ. Um aplicativo que se conecta ao sítio dos Correios e acompanha o andamento de suas encomendas. É programa para paranóico que vive comprando coisas no Mercado Livre e tem tanto código de rastreamento para acompanhar que se perde. Pronto, agora você cadastra tudo lá no EncomendaZ que ele gerencia.

Tem utilidade? Sei lá, deve ter. E lembra o que eu já disse? Eu gosto de fazer coisas inúteis também. Só pra aprender alguma coisa mesmo. E, obviamente, depois eu disponibilizo o código fonte da brincadeira pra todo mundo ver. E o deste programa está logo aqui: http://encomendaz.googlecode.com/.

Veja uma tela do programa logo abaixo. Repare no Look and Feel do Nimbus. Achei estilo e botei como padrão. Agora a parte engraçada? Ah, para ver vai ter que baixar o programa e olhar na aba de Doações! 🙂

Quer baixar? Clique aqui. Achou um bug? Cadastre um Issue clicando aqui. Gostou? Deixe um comentário me elogiando, meu ego agradece! 🙂 Não gostou? Então, deixe um comentário e diga o que pode ser feito para melhorar!

AuctionX – Informações do Mercado Livre

Fale sério pra mim! Você já fez um sistema, biblioteca, ou algo que o valha, que não tem a mínima ideia se é útil? 🙂 Estou neste dilema. Na falta do que fazer numa noite dessas, resolvi brincar com o Mercado Livre, Java, XML e Maven.

E no que deu isso? Nasceu o AuctionX. Uma biblioteca pra você fazer consultas aos produtos vendidos no Mercado Livre. E aí? Tem utilidade isso? Sei lá, oras! Só sei que eu fiz e tá legal.

Pra usar é bem simples. A API eu fiz com o Hibernate em mente, logo, você verá algumas semelhanças com a classe Criteria deles. Vamos começar com os exemplos. Você quer pesquisar “iphones” vendidos apenas por vendedores certificados (Gold, Platinum):

	Search search = AuctionXService.createSearch("ML");
	Collection<Auction> auctions = search
				.addRestriction(Restriction.onlyCertifiedSellers())
				.search("iphone");

Certo. Legal. Agora você quer pesquisar por “iphones” que não estão em leilão, mas em venda direta. E também que os vendedores sejam da Bahia e mais, que os produtos sejam apenas novos!

	Search search = AuctionXService.createSearch("ML");
	Collection<Auction> auctions = search
			.addRestriction(Restriction.onlyCertifiedSellers())
			.addRestriction(Restriction.buyNow())
			.addRestriction(Restriction.location("BAHIA"))
			.addRestriction(Restriction.onlyNewProducts())
			.search("iphone");

Onde está o projeto? No lugar de sempre: Google Code! http://code.google.com/p/auctionx/. Tá completo? Não. Ainda falta implementar a ordenação do resultado. Mas vai ser rapidinho! 🙂 Vá lá, tou só esperando você me chamar de maluco e coisa de quem não tem o que fazer.

Futuro do Alfred


Conforme informei no post anterior, tive uma boa recepção dos desenvolvedores que viram a notícia no BR-Linux e enviaram suas críticas e sugestões sobre o Alfred. Alguns criticaram a forma como a biblioteca foi programada, usando apenas métodos estáticos.

Cabe a mim explicar o motivo desta escolha. Não foi por desconhecer Orientação a Objetos, aliás, eu adoto este paradigma de programação a mais de 5 anos, seja programando em Java, C++ ou C#.

A adoção de métodos estáticos é devido à própria natureza da biblioteca. Eu diria que está relacionado à filosofia que eu pensei inicialmente para este projeto. A ideia inicial era ter uma biblioteca super simplificada. Não imaginei que sua utilização fosse com Composição de objetos ou herança.

Por exemplo, a ideia era que você não usasse a classe Telefone como um atributo de alguma classe, mas que se você precisasse, pontualmente, de uma formatação de telefone, usasse um método bastante simples de ser adotado.

Claro, em um mundo O.O. isto pode parecer estranho, mas admito que fui influenciado pelo projeto do Aurélio, o Funções ZZ. A filosofia por trás é a KISS: Keep It Simple and Stupid. E a forma mais simples que achei para a biblioteca foi esta.

E você? Concorda? Acha que a biblioteca deveria seguir outro rumo e adotar um modelo mais orientado a objetos? Dê sua sugestão, a biblioteca seguirá o rumo que a maioria achar melhor.