#1- FrostBite Redux – Decisões Iniciais

Há muito tempo que tenho a ideia de fazer um jogo. Seja ele pra desktop ou mobile. Agora, eu vou levar essa ideia adiante, definitivamente! Vou fazer um jogo para Android. Ponto final. Será meu primeiro jogo, minha primeira experiência nessa área. E pretendo compartilhar aqui no blog tudo que passei nessa jornada.

O primeiro passo que tive foi pensar em um jogo simples para fazer. Não tenho intenção de fazer um mega jogo super revolucionário logo de cara. Nesse primeiro momento, quero apenas aprender e compartilhar o que aprendi. Imaginei logo aqueles jogos de Atari. Pensei em vários e lembrei que era viciado em FrostBite. Não é um jogo pra lá de viciante, mas eu sempre queria fazer o máximo de pontos nele. 🙂

Jogo decidido, me faltava agora escolher como fazer o jogo. Eu poderia fazer o jogo do ZERO. Ou seja, implementar até uma simples engine que atendesse apenas ao jogo. Também teria a opção de usar uma engine mais genérica. Decidi usar uma engine. Por que? Sei lá. Deu vontade. hehe! De cara, escolhi a AndEngine. Não fiz muitas pesquisas e nada. Simplesmente, escolhi ela e pronto. Entenda a situação: não quero ganhar dinheiro, nem fazer um killer game. Quero só aprender. Só isso! Quando eu partir para algo mais sério, eu faço uma pesquisa mais extensiva e penso melhor nas opções.

Bom, agora já tenho tudo em mãos. Só me falta aprender a usar a AndEngine. A partir de agora, vocês vão acompanhar uma série de Posts onde vou ilustrar como configurei meu ambiente, o que fiz, deixei de fazer, os passos e tudo mais. Inicialmente, fique sabendo que o código será opensource. Estará disponível no Github no endereço https://github.com/marloncarvalho/frostbite-redux.

E você? Quer se juntar a mim nesta brincadeira? Se sim, me fala que podemos marcar uns dias para fazermos programação em pares. Uns hangout também. Fique ligado nos próximos artigos! 🙂

Opa! O próximo post já chegou! Clique aqui para ver #2 – Frostbite Redux – Setup.

TV ou Projetor? Qual vale mais a pena?

Eu não poderia deixar de tratar sobre este assunto, agora que comprei um projetor. Relembrando, comprei o projetor Optoma Game Time 720. A resposta a esta pergunta não é exata, tem vários “dependes”. Mas, pra mim, a questão não é simplesmente se você vai botar uma TV LED/LCD/Plasma na sala ou se vai botar um projetor. Comprar um projetor significa que você precisa se preocupar com outros detalhes que não se preocuparia tendo apenas uma TV. Para mim, a pergunta que você deveria se fazer é se quer um ambiente/sala/quarto especial para assistir seus filmes ou não.

Um projetor não substitui sua TV da sala, principalmente, se sua sala não tem os requisitos necessários para ter um equipamento deste tipo. A TV da sala está lá para sua esposa assistir novela (não é machismo, juro hehe!) e seu filho TV Globinho. E também, como é o meu caso, quando sua esposa liga a TV só por ligar, pra ficar ouvindo o que falam enquanto ela está lendo uma revista. 🙂 Tenho certeza que você não quer gastar uma grana em um projetor para situações como esta. Portanto, repito: a pergunta que você deveria se fazer é se quer um ambiente/sala/quarto especial para assistir seus filmes ou não.

Se você respondeu sim para a pergunta acima, então pode começar a pensar se deve comprar um troço desses. Mas, aí, pode ficar na dúvida se compra uma TV LED de 70″ no lugar, pois não tem ideia em relação à qualidade da imagem e por aí vai. Lembre-se também que o principal contra de um projetor é a questão da luminosidade. Se você não tem um lugar com baixa luminosidade, certamente vai achar um projetor algo ruim. Presta atenção nisto: se você não tem um ambiente propício para projeção, nem perca tempo. Um projetor será inútil pra você. E sua sala de visitas provavelmente não é o melhor lugar para um projetor, em minha humilde opinião.

Você deve analisar também o custo/benefício. Se você tem um ambiente propício para projeção, porque iria investir em uma TV? É do conhecimento de todo mundo que com um projetor você consegue uma tela muito maior do que a tela de uma TV. Uma TV de 120″ é inviável. Se é que existe uma comercialmente atrativa. Mas, digamos, que você esteja pensando em colocar uma TV de 70″ no lugar do projetor. Aí vou recorrer a algumas perguntas que já me fizeram:

1. A imagem é boa?

Saiba que a qualidade da imagem de um projetor Full HD é simplesmente excelente. Ao olho nu, parece perfeita. Não posso afirmar que é melhor ou igual a de uma TV Full HD. Mas posso garantir que você não vai achar tanta diferença assim. A projeção, quando feita em condições ideais (como em uma tela própria) e com um projetor de qualidade, é praticamente um cinema. Portanto, neste aspecto, não se preocupe, pois você não vai ver uma imagem distorcida, “pixelizada” ou coisas do tipo.

2. A tela fica gigante mesmo? Perde qualidade quando aumenta o tamanho?

A especificação do GT720 diz que pode projetar uma tela de até 300″. Isto depende de fabricante para fabricante. Quanto custa uma TV Full HD de 300″? Não precisa ir tão distante. Uma TV de 70″ custa mais de 10.000 reais. Um projetor GT720 custa 800 dólares. O meu, eu comprei aqui no Brasil por 2.200 reais. E tela maior não significa perda de qualidade da imagem.

3. A manutenção é mais cara que de uma TV?

A lâmpada de um projetor um dia queima. Ela tem um tempo de vida, todos sabem disso. O meu, por exemplo, diz ter entre 3000 e 5000 horas. No meu primeiro mês de uso, gastei 100 horas. E olha que usei pra tudo. Até pra assistir Jornal Nacional. 🙂 Depois, passei a usar só para filmes, futebol e jogar PS3. Programas mais “comuns”, eu vejo na TV LED 42″ da sala. Portanto, provavelmente, seu projetor vai precisar de uma troca de lâmpada antes que sua TV precise de um reparo.

Minha TV de Plasma 50″ da Samsung durou cerca de 5 anos sem apresentar qualquer problema. Só agora que pifou. Com metade disto, provavelmente, já precisarei trocar a lâmpada. E quanto custa uma? Cerca de 160 dólares. Aqui no Brasil a negada mete a faca: 600 reais. Neste caso, se você será um “heavy user” do projetor, a ideia é já ter uma lâmpada extra. Enfim, acredito que o custo de manutenção de um projetor é maior.

4. Basta comprar o projetor e pronto?

Aqui é a principal questão. Ter apenas o projetor não é tudo. Precisamos ser sinceros, quando você pensa em investir em uma belezura dessas, acabam vindo outros custos. O custo da lâmpada que comentei acima é um deles. Depois, convenhamos, projetar na parede não é a melhor opção, a não ser que você tenha usado uma tinta boa dessas aí. Dizem que a Coral tem uma tinta que é excelente para projeção. Se é verdade? Não sei. Caso não, vem outro custo: a tela. E uma tela, por incrível que pareça, não é barato.

Pensei primeiro em uma tela motorizada, mas me assustei com o preço médio: 1500 reais. Parti para uma tensionada, manual e  com tecido de alto contraste. Já caiu para abaixo dos 1.000,00 reais, mas ainda assim achei caro. Depois, nem todo projetor tem um esquema de áudio embutido. O GT720 tem, embora seja super fraco. Aí, já vem um home theater também. Brincando, brincando, aí você já chegou na casa dos 6.000,00 reais ou mais. As vezes, bem mais.

Mais coisas para se preocupar…

Uma TV também é fácil de instalar. Um projetor requer mais esforço. Provavelmente, você vai querer esse projetor fixado no teto, para liberar espaço no chão. Se tiver uma estante que possa ser usada, ótimo, mas na maioria dos casos, não tem. E tem que fixar a tela na parede também. Aí, lembre-se dos fios que devem chegar até o projetor grudado no teto. Certamente, você vai precisar de uns tubos pra esconder eles, senão fica feio. Sem contar que agora seu cabo HDMI não é mais de 2 metros, mas de 10 ou 15 metros. E é bom ter um ponto de energia próximo ao projetor. E o projetor também gera um calor imenso, por causa da lâmpada. Em dias de verão, em Salvador, você vai acabar pensando em comprar um ar-condicionado Split. 🙂

A Conclusão Inconclusa!

Espero que você já tenha entendido pelo menos uma coisa: o projetor não é para substituir sua TV convencional, onde sua mulher assiste novela e seu filho vê TV Globinho. Entendeu? Ótimo. Não substitui. Pra mim, são dois usos distintos. A questão aqui é se, uma vez que você tem uma sala perfeita para ver filmes e jogar, é melhor investir numa tela de 70″ ou em um projetor. Uma tela LED de 60″ está na faixa de 6.000 para 7.000 reais. É mais ou menos o que gastarei para ter o projetor+home theater+tela. Só me falta o home theater.

Neste caso, eu sugiro um projetor. A qualidade da imagem é excelente e com um ambiente propício, com tudo escuro, um frigobar do lado cheio de cerveja e uns videogames ao alcance das mãos, eu lhe garanto que vai ser difícil lhe tirarem de dentro deste quarto. É simplesmente espetacular! E quando você chama uma galera pra assistir uma partida de futebol ou filme, todos ficam impressionados. 😛 Agora, de fato, não se trata de um projeto para quem não tem “bala na agulha”. Vocês entendem o que eu quero dizer!

Mas, você está disposto a arcar com estes custos extras que citei? Está com coragem para fazer essas adaptações? Se sim, vai fundo!

Quarto de Jogos

Eu tenho tuitado bastante sobre isso, mas faltava um post descrevendo essa façanha. Tudo começou quando minha TV de Plasma 50″ pifou. Já tinha um tempo que eu imaginava comprar um projetor. Só me faltava aquela desculpa pra eu fazer essa loucura. E a TV pifar foi a desculpa perfeita. Agora eu podia comprar meu projetor sem dor na consciência. Mas o projetor era apenas um passo em direção à loucura. O abismo era mais profundo. A ideia sempre foi criar um quarto de jogos sinistro, com projetor, videogames, home theater, decoração à caráter e por aí vai. E eu já comecei a fazer isso. Vou descrever pra vocês como anda o processo.

Em primeiro lugar, o projetor. Busquei diversos modelos e, sem querer, eu sempre caía nos modelos da Optoma. Logo quando pensei em comprar um projetor, eu tinha mirado o HD66. Já tinha visto alguns vídeos no Youtube e ele parecia a escolha perfeita. Mas, aí, li sobre um tal de Game Time 720. Ou simplesmente GT 720 para os mais íntimos. Não vou mentir que esse Game Time no nome me chamou logo a atenção. Esses marqueteiros são foda! Acabei me decidindo pelo GT720, caso conseguisse um com preço bom. Enfim, ele foi feito pra games e eu certamente iria usar o projetor mais para o PS3 do que para filmes.

Mas a questão é que esse projetor não vende no Brasil. Logo, eu tinha que encomendar dos Isteitis. Sem nenhuma pretensão, eu pesquisei antes no Mercado Livre. Para meu espanto, espasmos, trimiliques, calafrios e alegria absoluta, tinha um maluco de SALVADOR vendendo a um preço simplesmente EXCELENTE: aproximadamente uns R$ 2.200,00 (mais uns quebrados que não lembro). Estava bom demais para ser verdade. Mas a verdade é que seria mais melhor de bom ainda. Ao ligar pro dito cujo dono do projetor, ouço uma voz familiar falando: “Porra, sabia que era você, Marlon”. Entenda, o cara é meu colega de trabalho. Estava a 50 metros de mim. No dia seguinte eu já estava com o projetor em casa.

Inicialmente, comecei projetando em uma parede branca. O resultado foi excelente. Enfim, vi um projetor Full HD em ação e não me decepcionei. Quer saber sobre esse projetor? Se liga nesse link aqui ó http://www.aboutprojectors.com/Optoma-GT720-projector.html. Um aspecto bem legal dele é que mesmo em curtas distâncias, ele projeta muito bem. De cerca de dois metros, consegui uma imagem sinistramente boa. E gigante.

O próximo passo foi comprar uma tela. O problema é que nesta parede aí, as pessoas ficam muito próximas e cansa assistir muito próximo. O quarto também ficava feio com essa arrumação. A questão era colocar em outra parede. Mas nessa parede tem uma porta e aí só com uma tela. Mais uma vez pesquisas e mais pesquisas sobre onde comprar. O mesmo colega que me vendeu o projetor me indicou a Telas Tech. Fiz o seguinte pedido pra eles: tela de 120″, tensionada e com tecido de alto contraste.

Não cometam o mesmo erro que eu. Uma tela de 120″ tem aproximadamente 2.45m de largura. Minha parede tem 2.80m. Imaginei que iria caber sem stress. Só que o jumento aqui esqueceu que tem o estojo onde o projetor fica dentro (quando está enrolado). E o estojo tinha 2.78m! A tela coube por míseros 2cm. Foi por pouco.

Viu aí na foto? Olha a parte de cima. E aquela porta atrás da tela está trancada e dificilmente abrimos ela. O que era bom, ficou ótimo. A projeção na tela é ainda melhor. As cores ficam mais vivas e o contraste também. Enfim, a parede tem tinta que não é boa para refletir a luz. Essa tela é feita especialmente para isso. Ah! E essa tela é cara pra caramba. Nem lhe conto o preço, deixa quieto. 🙂 Não tão cara quanto uma tela motorizada. Acho um absurdo uma tela, só por ter um motor, custar 2.000 reais. Minha tela não passou da casa dos 1.000. Para finalizar essa primeira parte, dá uma sacada nesse vídeo aí embaixo.

Outra coisa que me perguntam é sobre a vida útil da lâmpada. Este projetor diz ter entre 3000 e 5000 horas, dependendo do brilho usado. Eu tenho usado um brilho médio. Assim, acredito que chegarei a umas 4000 horas, mais ou menos. No meu primeiro mês de uso, gastei 100 horas. Repare, usei INTENSAMENTE o projetor. Enfim, é o primeiro mês de uso e a empolgação estava em alta. Assisti até Jornal Nacional e TV Globinho nele. Fazendo uma conta bem idiota, devo gastar cerca de 1200 horas por ano. Enfim, é provável que eu use ele por aproximadamente 3 anos. É tempo pacas. Mas, já estou pensando em comprar uma lâmpada reserva. Aí, vem outro problema. Achar onde comprar. Aqui, pra variar, a negada quer cerca de 600 reais. Lá fora, está por cerca de 160 dólares. O jeito será pedir pelo eBay.

Os próximos passos? Bem, ainda preciso comprar: home theater wifi, sofá de três lugares, cadeira gamer Boomchair Stealth, decorações diversas, Xbox 360, suporte de teto para o projetor e consertar a TV de 50″ pra colocar em uma parede alternativa! 😛

AlienDroid – ActiveRecord

Eu já comentei pelo meu Twitter sobre o AlienDroid, certo? Publiquei o link para o projeto e tudo mais. Só fiquei devendo um post aqui no blog explicando melhor o projeto e como ele funciona. Então, vamos pagar esta dívida agora. Lembram do DemoDroid? Foi uma tentativa minha de criar um pequeno framework para desenvolvimento em Android. Usei ele na criação do EncomendaZ e do BrasileirãoZ.

O DemoDroid estava até bacana, mas comecei a perceber que ele acabava criando mais uma complexidade no desenvolvimento. E achei ele um pouco pesado também. Percebi que os projetos Android normalmente são pequenos, possuem poucas entidades para persistir e tal. E o DemoDroid não levava isto em consideração. Acabava criando umas camadas extra desnecessárias. Por exemplo, não sou muito a favor de criar Business Controllers, DAOs e etc em projetos Android. Prefiro usar o padrão ActiveRecord com Models. Resolve o problema facilmente, é elegante, e deixa o código limpo.

Partindo destas premissas, abandonei o DemoDroid e fiz o AlienDroid. Desta vez, quero modularizar mais as coisas. Separei o projeto em, até agora, dois módulos. O primeiro é o Core. Este módulo é minúsculo. Pouquíssimas classes e que são mais de suporte para os demais módulos. Por exemplo, temos o módulo ActiveRecord para persistência de objetos. Você conhece o padrão de projeto ActiveRecord? Não? Quem já usou o Ruby on Rails conhece bem. Para aprender mais, visite a página do Martin Fowler sobre este padrão: ActiveRecord.

Agora, vamos começar a usar o AlienDroid. Primeiro, você pode usar ele pelo Maven. Ou sem Maven mesmo. Já publiquei o projeto no repositório de snapshots da Sonatype. Basta você ter uma dependência assim no seu projeto:


    com.alienlabz
    aliendroid-activerecord
    1.0.0-SNAPSHOT

Caso não use o Maven, você precisa de alguns arquivos. Primeiro, baixe estes dois: aliendroid-core.jar e aliendroid-activerecord.jar. Adicione eles na pasta /libs de seu projeto Android. Você precisa também das libs do RoboGuice:

  1. RoboGuice 2 Download
  2. Guice 3 No AOP
  3. JSR 305
  4. javax.inject

Agora, você precisa de uma classe que estende de android.app.Application. Crie ela e no método onCreate, faça uma chamada para AlienDroid.init(this). Com esta linha, você está iniciando o AlienDroid. E não se esqueça de referenciar esta nova classe no seu AndroidManifest.xml, hein! Pronto, meu caro. Agora basta você criar suas classes de Model estendendo de com.alienlabz.activerecord.Model. Vamos a um exemplo:

public class Contact extends Model {
    public String name;
    public Date birth;
    public Integer age;
}

E agora? Faço o que com esta classe? Vamos ver agora.

public MyActivity extends RoboActivity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        Contact contact = new Contact();
        contact.name = "My Name";
        contact.birth = new Date();
        contact.age = 21;
        contact.save();
    }
}

Só isso? É, cara pálida. Só isso mesmo. O AlienDroid vai criar um banco de dados chamado database.sqlite para você. E também vai criar uma tabela Contact automaticamente. Você pode fazer consultas assim, ó:

public MyActivity extends RoboActivity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        Contact contact = Model.load(Contact.class, 1);
        contact.name = "Changed Name";
        contact.save();

        List contacts = Model.findAll(Contact.class);
        List contacts = Model.where(Contact.class, "name like ?", new String[] {"name"});

        contact.delete();
    }
}

Curtiu? Eu também! 🙂 Quer tirar mais dúvidas? Quer usar o projeto? Quer ajudar? Então, entra em contato comigo. Pode ser pelo meu Twitter, Facebook, E-mail ou sei lá!

Como Fiz o EncomendaZ 3.0 – Parte 1

Antes de mais nada, quer tirar dúvidas sobre este post? Acompanhe-me no Twitter: @marlonscarvalho. Agora, vamos ao que interessa. O EncomendaZ foi um projeto que surgiu meio que do nada. A primeira versão eu fiz só para aprender um pouco sobre programação com Swing. Aliás, eu sou fanzarço de programação desktop e não curto muito “programação orientada a tags”. A primeira versão você encontra até hoje no Google Code, neste endereço: http://code.google.com/p/encomendaz/. Foi uma versão sem muitas pretensões, mas acredito que já aconteceu com você também: você faz um programa, algumas pessoas começam a usar e elogiar mas você acha que podia ter feito melhor. E foi assim comigo. Resolvi, então, fazer uma nova versão, só que desta vez bem melhor.

O sucesso da versão 2.0 me fez pensar na versão 3.0. Fui bastante relutante em lançar ela, pois daria um trabalho monstro fazer. Mas eu fiz. E, desta vez, a motivação foi aprender ainda mais a programar para desktop, desta vez usando frameworks diferentes e padrões de projeto bastante conhecidos. Eu já tinha vontade de descrever todo o processo de criação desta versão. Sei que muitas pessoas também curtem programação desktop, mas não sabem por onde começar. Aliás, ultimamente você só encontra referências para programação Web. Parece que tudo é Web hoje em dia e sistemas desktop morreram. Pra mim, pura balela.

Eu vejo mais um mundo onde serviços estão na internet e aplicativos, seja desktop, mobile ou web, os consome. Tem aplicativos que são muito mais fáceis de serem usados no Desktop. São mais práticos, elegantes, tem mais funcionalidades, são rápidos e podem funcionar offline. O que é errado é criar aplicativos desktop “autocontidos”. Ou seja, tem seu próprio banco de dados, não compartilha dados com outros aplicativos. Enfim, falo dos “aplicativos ilha”: vivem em seu próprio mundo e esquecem o resto. Mas, hoje, todo mundo só pensa em fazer aplicativo pra browser, como se fosse a bala de prata. Estão errados.

O meu objetivo é criar uma sequência de posts descrevendo todo o processo criativo que levou à concepção da versão 3.0, que você pode usar através do Webstart, clicando aqui. O código fonte do EncomendaZ 3.0 está disponível no Bitbucket e você pode baixar, usar, brincar… Espero que estes posts sejam úteis para você.

Código fonte da camada de apresentação: https://bitbucket.org/alienlabz/encomendaz-swing
Código fonte do core: https://bitbucket.org/alienlabz/encomendaz-core

Primeiro, vamos listar as tecnologias envolvidas. São muitas:

  1. Maven para gerenciar o projeto;
  2. Eclipse Indigo como ambiente de desenvolvimento;
  3. Java/Swing para a camada de apresentação;
  4. Framework Demoiselle;
  5. Hibernate para persistência;
  6. HSQLDB para armazenar os dados;
  7. Velocity para geração dos templates de e-mail;
  8. Jasypt para criptografia de senhas e etc;
  9. Apache Commons E-mail para o envio de e-mail;
  10. Barbecue para a geração do código de barras;
  11. JasperReports para a geração dos relatórios;
  12. Jide OSS para alguns componentes de tela;
  13. HTTPClient da Apache para conexão com a internet;
  14. Quartz para o agendamento de tarefas;
  15. MigLayout para a criação de formulários;
  16. SwingX para componentes de tela;
  17. L2FProd para ter o componente de barra de ações lateral;
  18. Insubstantial para os temas Swing;
  19. JCalendar para ter um calendário bonito no Swing;
  20. JBusyComponent para ter um “Loading” tipo o Ajax em Web;
  21. Zeus JSCL para ter um componente mais amigável para exibir erros;
  22. Java WebStart para publicação.

Vou tentar justificar o uso de cada uma destas tecnologias. Ou não. 🙂 São muitas e talvez eu não consiga chegar até o final. Vou começar justificando o uso do Framework Demoiselle. Você conhece? Não? Pois saiba que você deveria dar uma chance a ele. E não foi só porque eu participei da equipe que o criou, mas porque é um ótimo framework, de fato. O Demoiselle teve sua concepção inicial no Serpro, mas hoje já é usado por diversas empresas, incluindo aí outros órgãos governamentais, como: TRT, MPU, Prodeb, Fundação Luís Eduardo Magalhães e por aí vai.

E estas empresas não o estão usando por imposição. Ninguém é obrigado a usar o Demoiselle. Usam porque gostaram e tecnicamente é um ótimo framework. Quer entrar em contato com a equipe do Demoiselle? Primeiro, use a lista de discussão. Depois, acesse o fórum. E também tem os @zyc, @wegneto, @e_saito e @Atiboni no Twitter para vocês tirarem dúvidas. 🙂

E como foi que o Demoiselle facilitou no EncomendaZ? Simples:

  • Injeção de Dependência com Weld é o bicho! 🙂 Nada de criar exaustivas fábricas;
  • As classes de template para CRUD diminuíram consideravelmente a quantidade de código para escrever;
  • O POM (Maven) parent do Demoiselle para aplicações Desktop simplificou a criação do projeto;
  • O controle de transações é fácil e extensível. Não fosse por isso, eu não teria conseguido resolver alguns problemarços que apareceram!
  • O ResourceBundle próprio do Demoiselle, com substituição de palavras-chave é uma mão na roda;
  • Já fornece algumas validações comuns no Brasil através do componente demoiselle-validation.

Eu poderia citar outras, mas estas aí já são suficientes. O que posso dizer é que o Demoiselle está funcionando rock-solid no EncomendaZ 3.0 e nenhum erro reportado até hoje foi proveniente dele. Contudo, tive alguns probleminhas e vou citar eles em breve. No próximo post, vou descrever o principal padrão de projeto que usei: Passive View. É um ótimo padrão e, em conjunto com o Demoiselle, forma a base do aplicativo.

O Eclipse, o Maven e o Tomcat 7

Um post rápido para lhe ensinar uma gambiarra que pode lhe ajudar a poupar muito tempo de sua vida. Quando Maven não quer funcionar, só partindo pra gambiarra. Já aconteceu com você de criar um projeto Maven, colocar ele como packaging war, mandar atualizar as configurações do projeto pelo Maven, deixar tudo lindo mas o miserável não rodar dentro do Tomcat 7? Pois é. Pode acontecer com você. Aconteceu comigo.

Primeiro de tudo, não sei porque caceta o Maven não configura o projeto para ser “deployavel” no Tomcat 7. Você sequer consegue arrastar o projeto para o Servidor configurado. Ele não deixa por não reconhecer ele como um projeto Web. A primeira questão é que seu projeto não está multifacetado (facets). Aí você tem que fazer isso na mão. Vai nas propriedades do projeto, em Project Facets. Seleciona Dynamic Web Module e Java.

Feito isto, já dá merda. Ele cria uma pasta /WebContent fora da estrutura padrão do Maven. Deveria ser a pasta /src/main/webapp. Agora você precisa ir na pasta do seu projeto no seu workspace, abrir a pasta oculta chamada .settings e editar o arquivo org.eclipse.wst.common.component.

Deve ter uma linha escrito isso: <wb-resource deploy-path=”/” source-path=”/WebContent” tag=”defaultRootSource”/>. Tá errado. Mude pra <wb-resource deploy-path=”/” source-path=”/src/main/webapp” tag=”defaultRootSource”/>. Feito isto, continua sem funcionar. O motivo é que ele não faz o deploy das dependências do Maven dentro da pasta /WEB-INF/lib. Para consertar isso, vá nas propriedades do projeto. Opção Deployment Assembly. Clica em Add, depois em Java Build Path Entries e seleciona Maven Dependencies. Pronto, esta merda agora deve funcionar! 😛

Pense em um armengue. Acabei de lhe apresentar um! 🙂

Velocity ResourceLoader

Saca o Velocity? É um Template Engine para Java que é bem bacana. Resolvi usar ele no EncomendaZ 3, exatamente na parte de geração de e-mails. Fiz um template bonitinho mas também deixo livre para as pessoas criarem seus próprios. O meu próprio template, digamos, o template default, fica embarcado no próprio JAR. E o usuário pode ir lá e dizer um template próprio que, obviamente, estará fora do JAR. Estará no Filesystem dele.

Aí, quando você chega lá no Velocity e quer programar isso, surge um problema. O sacana pede que você informe qual a classe responsável em encontrar e carregar os recursos pra ele. Normalmente, você usa o ClasspathResourceLoader, que serve para encontrar os recursos dentro do próprio classpath. Mas, caso você queira obter arquivos do disco do cara, precisa informar o FileResourceLoader.

Aí é que está o problema. Quando você diz o FileResourceLoader, também precisa informar o file.resource.loader.path que é para ele ir buscar todos os resources de lá. Mas, peraí. Eu não quero fixar isso. O próprio usuário do programa vai informar onde está o arquivo que ele deseja que seja seu template. Aí, vamos para a mãe de todas as soluções em programação: uma leve gambiarra. Dá uma sacada no código aí embaixo. Ele está todo comentado!

public class Teste {
	private String getTemplate(final Tracking tracking, final Person person) {

                // Vamos ver se o usuário informou seu próprio template.
		String template = prefs.getEmailTemplate();

                // Iniciando o contexto o Velocity.
		VelocityContext context = new VelocityContext();

                // Colocando um objeto para ser usado pelo velocity para preencher os dados.
		context.put("encomenda", tracking);

                // Uma vez que o Velocity fez as devidas substituições no template, onde ele vai guardar?
                // No nosso caso, em um StringWriter.
		StringWriter w = new StringWriter();

                // Aqui é a questão. Se o cara não informou um template, então vem NULL ou vazio.
		final Properties properties = new Properties();
		if (template == null || "".equals(template)) {

                        // O cara não informou, então vamos usar o nosso que está no classpath.
			properties.setProperty(VelocityEngine.RESOURCE_LOADER, "classpath");
			properties.put("classpath." + Velocity.RESOURCE_LOADER + ".class", ClasspathResourceLoader.class.getName());

                        // Esse é o nosso template padrão que está no classpath.
			template = "email.vm";
		} else {

                        // Opa! O cara informou um template.
                        // O resourceloder é para um arquivo.
			properties.put("resource.loader", "file");

                        // A classe responsável em carregar os resources!
			properties.put("file.resource.loader.class",
				"org.apache.velocity.runtime.resource.loader.FileResourceLoader");

                        // O Path para encontrar os arquivos. A gambiarra é aqui.
                        // O método getPath() retorna apenas o diretório, removendo o nome do arquivo.
			properties.put("file.resource.loader.path", getPath(template));

                        // Vamos pegar agora só o nome do arquivo, tirando o diretório.
			template = template.substring(template.lastIndexOf('/') + 1);
		}

                // Precisamos sempre iniciar uma VelocityEngine. Se usarmos Velocity.init(), não dá certo.
                // Ela será global e todas chamadas subsequentes vão usar sempre a primeira configuração.
		VelocityEngine ve = new VelocityEngine();
		ve.init(properties);

		try {
                        // Manda fazer o Merge e Voila!
			ve.mergeTemplate(template, "UTF-8", context, w);
		} catch (Throwable t) {
			throw new EmailNotSentException();
		}
		return w.toString();
	}

	private Object getPath(final String template) {
		return template.substring(0, template.lastIndexOf('/'));
	}

}

Entenderam? A mágica acontece na hora de setar o file.resource.loader.path. Como o cara informou seu próprio arquivo, ele provavelmente estará em um lugar tipo c:/meustemplates/meutemplate.vm. Pegamos primeiro só a parte do diretório (c:/meustemplates/) e setamos como path. Depois, pegamos só a parte do arquivo. Gambiarra, né não? Mas funcionou, então, não reclame! 😛

EncomendaZ 3.0 MegaBeta

Ufa! Enfim, consegui uma versão “quase estável” do EncomendaZ 3. Iniciei ele em julho de 2011 e só agora tomei vergonha na cara para concluir o bicho de uma vez por todas. Toda noite eu tinha pesadelos por ter abandonado ele. Fora um monte de gente mandando sugestões de melhoria para a versão 2 e que eu já tinha implementado na versão 3. Mas, enfim, agora tenho algo para mostrar. Eis a versão MegaBeta 3.0. Está com pressa pra baixar logo? Vai até o final do post que o link está lá! 🙂

O MegaBeta é só para deixar bem claro que, com certeza, você vai encontrar alguns problemas. Principalmente, porque eu sei que existem esses problemas. Só falta eu corrigir eles. Mas, você também pode encontrar outros problemas, certo? Caso sim, passe para mim. Pode ser nos comentários aqui deste post. Pode ser me enviando um e-mail (marlon.carvalho@gmail.com). Ou pode ser no bugtracker do Bitbucket, caso você entenda do negócio. O endereço é este: https://bitbucket.org/alienlabz/encomendaz-swing/issues?status=new&status=open.

Esta nova versão está rodando através do Java Webstart e precisa da versão 6 do Java. Roda apenas nesta versão, infelizmente. Isto por causa do sacana do Weld, que é cheio de frescura com o JAWS. Fazer o que, né! No caso do MacOS, você deve selecionar a opção conforme a imagem abaixo.

Em seguida, ele vai começar a fazer o download e vai lhe perguntar se você permite a execução do aplicativo. Obviamente, diga que sim, hein. Feito isto, daqui em diante, você vai sempre executar o aplicativo a partir do arquivo encomendaz.jnlp! Qual a vantagem disto? Não seria melhor distribuir a versão em um ZIP? Não. O JAWS não faz o download do aplicativo toda hora. Ele faz um cache local e só verifica se há versões novas no servidor. Caso haja, ele baixa somente esta parte que foi atualizada. Não é necessário ter instalador também e o aplicativo roda em uma sandbox que não lhe permite fazer miséria na sua máquina. Ah sim, a imagem aí embaixo mostra o download da aplicação.

Essa aí embaixo é para você clicar no Permitir! Fique tranquilo, o aplicativo é só para rastrear encomendas mesmo. 🙂

Agora, vamos para as imagens do aplicativo. Digaí se não ficou lindão, hein hein? Até eu me emocionei. Pode chorar.

Baixar a Versão

Ahaaaaaaa! Pensou que eu tinha esquecido do link para o download? Óbvio que não! O link pro JNLP é esse aqui: http://www.alienlabz.com/encomendaz/jnlp/encomendaz.jnlp. Pronto, agora é a sua vez de me ajudar! Dá essa força aí, não custa nada. Pelo menos, até agora, não. Aqui vai ume penca de código de rastreamento para vocês testarem:
PG000702074BR, CW180801270US, SE987654321BR, RA169391799CN, PG035883496BR, RB414391713HK, EI089772025US, RE909064538SE, SI001690372BR, RE605739191BR, RE605739188BR, RE605739174BR, RE605739165BR, RE605739205BR.

Mudança de Casa

Para minha extrema alegria, meu servidor VPS hospedado na VPSLink sofreu um ataque DDOS por UDP. Travou a porra toda. Inclusive os outros VPS que estavam na mesma máquina que o meu. Enfim, o pessoal da VPSLink me contactou e pediu que formatasse a máquina, mudasse a senha de root, rezasse e desse três pulinhos. Fora fazer o download de 3gb de conteúdo e esquecer de baixar o SVN, foi tudo bem. Fiz tudo isso, mas também pensei em mudar de empresa.

Já estava há 3 anos na VPSLink e comecei a achar o painel deles fraco e o valor alto. Atualmente, pago 33 dólares por uma máquina com 20GB de HD e 512mb de RAM. As opções que vi e pensei em pegar foram: Tektonic, UltraVPS, VirtuaServer, Locaweb, Linode e SliceHost. Eu também pensei na Amazon, mas ainda não estou “preparado” psicologicamente para usar o serviço deles. 🙂

Antes que você me pergunte, vou lhe responder pra que porra eu quero um VPS. Eu sempre tive meus sites. Seja pessoal, seja para um projeto… eu usava serviço de hospedagem comum mesmo, mas sempre esbarrava na limitação deles. Resolvi testar um VPS e nunca mais saí. A liberdade que um VPS lhe dá é muito massa. O servidor é só seu. Você faz o que quer nele: instala o que quiser, guarda o que quiser, faz miséria. 🙂 Uma vez em um VPS, pra sair é dureza. Fica mal acostumado.

Tektonic

A Tektonic tem preço bom e boas configurações. Por 28 dólares, você tem uma máquina com 1GB de ram, 60GB de HD e CPU de 2.6ghz. Só uma coisa me tirou deles: só usam OpenVZ para a virtualização. Quêquissotemaver? OpenVZ não é o ideal para rodar Java. Não sou expert no assunto, mas do que já li, o OpenVZ não faz swap de memória, ou seja, se sua aplicação Java precisar mais do que os 1GB de memória, o processo dela será assassinado e sua aplicação cai. No meu caso, eu preciso de um servidor Xen, que faz swap.

Memória: 1.0GB
HD: 60GB
Bandwidth: 500GB
CPU Speed: 2.6Ghz
Preço: U$ 30.00 por mês

UltraVPS

A UltraVPS foi outra que pesquisei, mas perdeu porque ouvi pouca gente falando sobre ela. E também porque quando cliquei no botão Order Now com meu Chrome, ele não respondeu. Vai me dizer que só funciona no IE? Então, estou fora. 🙂 A configuração que eu queria com eles nem era assim tão em conta:

Memória: 1.5GB
HD: 45GB
Bandwidth: 3000GB
CPU Speed: 1.8Ghz
Preço: U$ 30.00 por mês

VirtuaServer

Seguindo a lista, temos a brasileira VirtuaServer. Os preços não me agradaram muito e só usam OpenVZ também. Eu ia ter quase as mesmas configurações que a VPSLink e o preço não era assim tão em conta. Claro, mais barato que a VPSLink e também eu pagaria em reais. Mas… descartada.

Memória: 512MB
HD: 30GB
Bandwidth: 500GB
CPU Speed: 1.2Ghz Garantido mais 1.2Ghz Burst
Preço: R$ 49,00 por mês

Entendeu o “Burst” na CPU? Eu também não entendia. 🙂 Segundo li, eles só me garantem 1.2Ghz de CPU, pode ser que tenha mais 1.2Ghz sobrando lá e aí ele fica disponível para eu usar. Mas, não é garantido. Foda, né? Até meu celular é mais rápido que esse servidor.

Locaweb

Continuando, pensei em pegar um servidor Cloud na Locaweb. Pensei em apoiar as empresas brasileiras e tal. Pagar em reais, ter suporte em português. Mas ainda temos poucas VPS aqui e acho os valores bem altos ainda. Um Cloudserver Pro com 512MB de ram, 50GB de HD e 2 CPUs custa 99 reais por mês. Enfim, descartado.

Memória: 512MB
HD: 50GB
Bandwidth:
CPU Speed:
Preço: R$ 99,00 por mês

SliceHost

Logo adiante, encontrei a SliceHost, que muita gente fala bem pacas. O esquema deles me parece que é só servidor em nuvens. Aí, eu fui na página deles pra entender como era a cobrança e tal. Parece com o esquema da Amazon! Cobram por hora de uso de CPU, memória e isso e aquilo. Enfim, não me senti muito confortável, não. Quando você diz mais ou menos a configuração que quer, ele dá um valor estimado. Putz, estimado? Sei lá, eu quero um valor fixo garantido todo mês. 🙂 Ou seja, ainda não me acostumei com esse troço de hospedagem em nuvem. Descartei.

Linode

Vamos finalizar essa odisséia com a Linode. Foi quem escolhi. Li diversos relatos de usuários feliz, alegres e satisfeitos. E não foram poucos. Vi algumas pessoas que possuem serviços até conhecidos e com enorme carga. E eles estão hospedados lá. Entrando na página da Linode, você estranha, pois o site não é assim uma maravilha de design. Mas ao ver os preços e configurações deles, uma me chamou atenção.

Memória: 768MB
HD: 30GB
Bandwidth: 300GB
CPU Speed:
Preço: U$ 29,95 por mês

A maioria dos usuários também relataram que eles já melhoraram as configurações do VPS deles sem cobrar nada a mais. Quem tinha um VPS com 512MB de ram foi migrado sem custos para o de 768MB. Bacana isso, hein. Eu já estava quase convencido, mas só faltava uma coisa: o servidor ser Xen. E é! Outra coisa importante era ter um painel bem bacana. Vendo as screenshots percebi que o painel deles não é lá essa maravilha toda, mas centenas de vezes melhor do que o da VPSLink. Enfim, encontrei.

Redirecionei meus domínios pro DNS deles, instalei CentOS 6, configurei tudo, fiz carga dos 190MB de Dump do MySQL, enviei pra lá os 3GB de backup e minha vida voltou ao normal.

Design para Programadores Tapados

Resolvi fazer um post para repassar um mínimo de experiência que tenho ao trabalhar ao lado de alguns designers. Já tive uma empresa na qual dois sócios eram designers. E eu me aventurava no design também. Depois fiz trabalhos “freelas” com designers e sempre trabalhei próximo a eles. Com isto, consegui ter um mínimo de noção de design.

Então, meu caro, este post é para você, programador que não sabe porra alguma sobre design. Principalmente, se você é um programador que pega uns trabalho freelance e não quer dividir a grana com um designer. Você é daqueles que pretende fazer todo o layout e imagens por conta própria. Mas sabe que é simplesmente UM BOSTA em design. Mas é muito mais sovina do que um bosta em design. Desta forma, não vai desistir de ter a grana toda só pra você. Em primeiro lugar, já lhe aviso que você tem mais a ganhar dividindo o trabalho com os outros do que querendo fazer tudo sozinho.

Mas, tudo bem, você acabou de me mandar para a merda e quer mesmo fazer tudo por conta própria. E você já sabe qual será o resultado. Simplesmente uma bosta de uma aplicação cheia de ícones toscos e mal arrumados em um layout porcamente projetado. Então, vou lhe passar umas dicas que sigo. Entenda que não são KILLER TRICKS que vão lhe transformar no melhor designer do mundo. São detalhes minúsculos, mas que todo programador cabeça dura não dá a mínima. Talvez algum designer por aí possa corroborar ou me chamar de idiota nos comentários. Fique à vontade.

O primeiro erro estúpido de todo “programasigner” é achar que para sua aplicação ficar legal, basta encher de ícone bonitinho. Aí, você vai lá no famoso IconFinder, baixa um ícone rosa, outro laranja, outro verde, outro azul e vai fazendo um carnaval na aplicação. Portanto, meus caros energúmenos, aqui vai a primeira dica: use um único iconset. Escolha um bacana e use apenas ele. Não misture ícones de diversos iconsets. Vai dar merda na certa. Sua aplicação vai virar um carnaval, todo colorido, sem padrão visual, sem porra nenhuma.

Quando um designer de verdade faz uma coleção de ícones, ele escolhe uma paleta de cores, um estilo, formas, uma ideia e começa a fazer os ícones seguindo estes padrões. Aí, você em sua extrema estupidez, vai lá e mistura tudo, desgraçando com o trabalho dos artistas. E entenda que você também não precisa colocar ícone para tudo. Escreveu um texto, larga um ícone do lado. Outro texto, mais um ícone. Não abuse dos ícones, use apenas quando eles reforçam uma determinada informação ou até mesmo a substituem.

Outra dica, de nada adianta você escolher um iconset, digamos, em que a cor predominante dos ícones é azul e colocar o layout com cor predominante rosa. Ou seja, siga o padrão de cores do iconset que você escolheu! Sacou? Se o iconset que você escolheu é cinza, prefira cores mais escuras pro background, menu, botões e por aí vai. Outro detalhe é a fonte. Escolha uma fonte que combine com os ícones, imagens e o logotipo da aplicação/empresa também e use ela na maior parte da sua aplicação. A fonte é outro aspecto muito importante e você não pode menosprezar isso.

Mais uma coisa que programador adora fazer: encher a aplicação de informação. Pro programador, parece que quanto mais informação você jogar na cara do usuário, melhor. ERRADO! Aprenda a fazer um layout limpo, deixe espaços em branco mesmo. Esses espaços ajudam ao usuário se focar no que é mais importante na sua aplicação. Não adianta entupir de informação, pois isso confunde mais do que ajuda. Portanto, lembre-se: layouts limpos, com espaços vazios, bem aproveitados.

E, por último, nunca, em hipótese alguma, invente de fazer logotipos. Você é um programador, não é um designer. Esqueça isso, pois isso é trabalho para designers. Logotipo não é apenas escrever o nome da empresa ao lado de um ícone que você roubou de algum lugar. Não é. Entendeu isso?

E, enfim, é o fim.