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!

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!

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.

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.

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.

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á.

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!

Já me perguntaram várias vezes o que vale mais a pena, se é vender ou colocar propaganda. Espero ter dado a resposta ao final deste post. Caso você queira uma resposta direta, na cara, sem frescura e está com preguiça de ler o restante do post, então, é… depende, cara pálida. Deixe de preguiça e leia até o final, seu zé ruela. Vamos entender o contexto da coisa. Eu coloquei duas aplicações com AdMob. Uma valeria a pena ter as propagandas. A outra, não. A que valeria seria o BrasileirãoZ, mas ainda assim não tenho certeza absoluta. A que não valeria é o EncomendaZ.

Vamos entender a situação agora. O AdMob só vale a pena para aplicativos “Top Sellers” e de grande uso diário. Somente para eles. O retorno é baixo e você acaba conseguindo em um mês o dinheiro que você conseguiria em 1 ano de AdMob. Exemplo disto? Vamos lá. Eu vendi 30 licenças do EncomendaZ pela Android Market. São 30 dólares acumulados. Contudo, não consegui ainda nem 2 dólares com as propagandas oriundas dele após mais de 3 meses. Entendeu o contexto? O EncomendaZ é um aplicativo muito específico. Tem cerca de 600 downloads após quase 1 ano de publicado. E 600 pessoas usando é muito pouco. E, claro, não são 600 pessoas usando direto. O que posso saber é que 600 baixaram, mas não saber se tem uso constante. Acredito que destas 600, talvez umas 100 usem constantemente.

Já o BrasileirãoZ leva vantagem. O brasileiro adora futebol e certamente é um aplicativo de uso constante. O cara quer sempre saber como anda seu time, classificação e etc. E isto se comprovou na prática. O BrasileirãoZ corresponde a mais de 90% do total de 13 dólares que arrecadei usando o AdMob. Mas ainda é pouco. Ele tem cerca de 2200 downloads atualmente e, aparentemente, um uso constante. Contudo, ainda arrecadei mais vendendo ele do que com AdMob. Foram 17 doletas vendendo e cerca de 10 dólares vindos de propaganda.

Há algo mais que você precisa pesar: o AdMob deixa sua aplicação feia, rouba espaço da tela e é chato. É igual a você entrar em uma página cheia de AdSense e que dá vontade de fechar imediatamente. Então, se vai colocar propaganda, faça com cuidado e pense bem. Vale a pena abusar seu usuário com essa propaganda mesmo? Bom, vou deixar aqui minha dica se você coloca ou não essa maldita propaganda… se bem que dica de maluco vale nada. Mas vou dizer ela mesmo assim.

Acredito que um plano melhor seja criar uma versão free com propaganda e outra paga sem propagandas e talvez mais opções. Principalmente se sua aplicação é muito específica e tende a não ser de uso constante. E essa dica, eu mesmo tentarei seguir nas minhas próximas aplicações. Uma aplicação somente free e com propaganda vale a pena para Angry Birds e por aí vai. Acho muito melhor você mesclar os dois mundos. Você tende a ganhar dos dois lados usando esta tática. Caso o cara seja mão de vaca e use sempre a free, ganha na propaganda. Caso sua aplicação seja boa mesmo e a galera passe a comprar, melhor ainda.

Antes, eu programava com o GWT do Google, mas admito que precisava de muito código. Lembrava um pouco os velhos tempos de EJB 1.2. Cria interface remota aqui, classe interna acolá. Argh! O Vaadin resolveu o problema pra mim. Nada mais de objetos DTO, VO e sei lá mais o que. Mas não vou explicar muito do Vaadin aqui não, maluquete. Isso porque você pode comprar as JavaMagazines de número 95 e 96 e ver meus dois artigos lá. Quem leu curtiu. Eu não li. Mas escrevi e curti também.

Vê as imagens das capas das revistas logo acima que é pra você não chegar na banca de revistas e comprar errado. Aproveito para entregar meu amigo Mario Pereira, que certa vez pediu uma “JavaMagazine” na banca. O cara olhou ele de forma estranha, fez cara feia, entrou na banca e voltou com uma “G Magazine” pra ele. Se Mario levou pra casa a revista mesmo assim? Perguntem a ele!

PS.: Dieguito lembrou nos comentários uma coisa importante. O primeiro artigo não saiu na versão impressa da revista. Ele está apenas online. Em contato com a editora, eles me alertaram que ocorreu um erro. Era para os dois artigos saírem na versão impressa. Para corrigir este problema, eles liberaram o acesso irrestrito ao artigo na versão digital. O segundo artigo saiu de fato na versão impressa! Valeu Diego!

Agora, você em sua total sapiência me pergunta: e daí, cara? Deixe de ser miserável e entenda o seguinte: o Alfred vai mudar. Aliás, já mudou. Ou não. Mudou sim. Agora ele está no Github no endereço http://www.github.com/alfredlibrary/. E é só isso? Porra nenhuma! O projeto vai ser reestruturado totalmente e absolutamente. Estou pensando em diversas melhorias para ele, além de uma reestruturação catastrófica! Agora não será apenas um único “jar” contendo tudo. Quero separar por funcionalidades. Tipo assim: vai ter um repositório no Github para o projeto “postal-services”, no qual você terá todas as funcionalidades para serviços postais. Este projeto gera um jar separado que pode ser adicionado ao seu projeto. Captou a ideia?

E o que mais? Ah! Quero uma integração com o CDI também. Aí você poderá injetar os serviços do Alfred apenas com um @Inject. Sucesso, né não? O Github já vai ajudar substancialmente no recebimento de contribuições, não tenho dúvidas. Outro detalhe, a API será totalmente refeita, mas agora em inglês. A questão de ter apenas métodos estáticos também não será uma regra e talvez a não dependência de APIs externas também. Tudo depende, é caso a caso.

Maluco, é o seguinte: quero sua ajuda. Precisamos de sua ajuda. Ajude mesmo! Deixe de preguiça, na moral! Contribua com código. Esculhambe quando é pra esculhambar. Chame o autor do código de anta quando é pra chamar, mas não fique calado, não. Senão eu que vou lhe esculhambar. Faz um follow no projeto no Github. Faz logo seu fork, agora, sem demora, sem pestanejar e sem pensar! Aja na emoção e faça isso logo. Eu imploro!