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!

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!

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.

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.

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.

Eta porra! Ano novo de novo. O trigésimo quarto de minha vida. E espero que consiga ver mais uns 60 desses. Quero morrer com 90 anos de idade. Acho um número bonito. Só por isso. Mas a questão é que vésperas de ano novo sempre lhe levam a pensar como será seu ano seguinte. E as promessas de ser um cara mais porretão sempre se renovam. Em vão, é claro. O ano seguinte inicia e você já está enjoado dele no segundo dia. E as promessas que se lasquem.

E isso acontece comigo todo ano. A única diferença deste ano para os passados é que deixarei público, aqui no blog, algumas das coisas que eu realmente gostaria de fazer, ser e ter no ano de 2012. E vocês verão como não conseguirei nem 30% disso. Pode apostar. E rir de minha cara também. Vamos começar a lista das coisas que não farei em 2012 com algumas “tags”: estudos, atividades físicas, aquisições, comportamental e NãoSeiMaisOQue.

Estudos. Eu prometo que para 2012 eu finalmente conseguirei suprir minha deficiência em matemática. Não chego a ser uma anta matematical, mas eu sou lerdo demais com os números. Quase uma anta matematical. E prometo que finalmente aperfeiçoarei minhas técnicas no xadrez. Embora atualmente eu não tenha nem 1% disto. O caminho será longo. E prometo que aprenderei a jogar Texas Hold’em de verdade. Meu estágio atual é próximo do zero. Tendendo ao infinito. Se é que isso quer dizer alguma coisa. Eu já disse que eu sou ruim em matemática?

Vou aprender Ruby definitivamente. Enfim, vou ter fluência mínima em inglês e começar com o espanhol. Essa categoria até que não é difícil. Digamos que eu consiga algo muito próximo de 39.541234%.

Atividades Físicas. Eu juro que em 2012 passarei a fazer algum esporte. Todo mundo me olha como se até pra nascer eu não tivesse feito qualquer esforço. Achar o caminho útero->vagina não é uma tarefa fácil e o posicionamento intrauterino também é importante! O meu foi perfeito, nota 10. Quando digo que já joguei muita bola (no sentido quantitativo, não qualitativo), me sinto um comediante. Já andei muito de skate, joguei bastante futebol e basquete. Mas, atualmente, só o alterocopismo, modalidade cerveja gelada até 350ml.

Aquisições. Esta talvez seja a categoria mais fácil de ser cumprida. Sou consumista, eu admito. Também, só vou listar coisas que eu realmente possa comprar. Sem ilusões de ganhar na megasena. Quero comprar um carro novo, uma mesa de sinuca, uma espingarda de ar comprimido, um Galaxy SII e fecho a lista aqui. Esqueci o resto mesmo. Vou colocar 70% de acertos aqui.

Comportamental. Juro de pé junto que serei mais paciente quando me fazem esperar. Que beberei menos. Aliás, essa última é balela, vou perder fácil. Juro que minhas crises paranóicas-existenciais cessarão por completo. Juro que serei mais pro-ativo. E que não serei mais preguiçoso. Vou fazer compras no mercado com minha esposa. Nessa categoria eu aposto 0% de acerto.

NãoSeiMaisOQue. Prometo que vou ler mais livros. Principalmente dos escritores brasileiros. E que lerei semanalmente todas minhas revistas semanais. Vou molhar as plantas da casa todos os dias. Vou consertar as goteiras da casa. Vou jogar outros jogos de PS3 além de Fifa 12.

Agora é só esperar o fim de ano de 2012. Mas o resultado eu já sei qual será.

E o EncomendaZ, na versão desktop, está próximo, mas muito próximo mesmo, de alcançar a grandiosa marca de R$ 1.000,00 em receitas oriundas da venda de licenças. Foram cerca de 80 licenças vendidas. Parece pouco, né não? Mas significa bastante pra mim. Foi o primeiro aplicativo que criei com o objetivo de vender. Não pensei em ficar milionário com ele. Mas foi a minha primeira investida e serviu de teste para eu entender um pouco sobre este difícil terreno. As lições foram muitas e gostaria de compartilhar algumas delas.

Primeiro, saibam que criei o EncomendaZ 2 em cerca de 15 dias de programação hardcore! Aprendi bastante sobre Swing/Java. Aprendi que ao vender um aplicativo, você assume uma grande responsabilidade perante aqueles que compram. Bugs precisam ser corrigidos imediatamente. E-mails precisam ser prontamente respondidos. A licença não pode demorar de ser enviada, senão dá bronca! E você acaba tendo que tratar com muita gente nervosinha e apressada.

A técnica do “Pague Quanto Quiser” também foi legal e descobri que as pessoas não gostam mesmo de dizer quanto vale um aplicativo. Alguns me chamaram de maluco, que isso não existe. Alguns entenderam a ideia. Outros pagaram 1 real. Tantos outros pagaram muito mais que isso. Mas acabei tendo que colocar no site um “valor médio”, informando o quanto, em média, as pessoas estavam pagando pela licença. A partir daí, a maioria passou a pagar a média. Interessante, né? Você deixa a escolha para as pessoas (A Escolha, Neo!), mas elas preferem não ter que decidir sobre isso. Mas isto é um tema para um post inteiro.

Fica aqui meu agradecimento a todos que ajudaram comprando a licença do EncomendaZ 2.0. E saibam que o EncomendaZ 3.0 está por vir e será muito melhor que a versão 2. O problema é que ainda não encontrei tempo e motivação suficientes para acabar de vez. Eu estou construindo a versão 3 sozinho e tem bastante coisa a ser feita. Tenham paciência comigo. Ainda não sei como vou fazer para distribuir a versão 3. Os comentários estão abertos para sugestões!