7325velocidade

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! 😛

1

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.

Buying-Gold-Coins

Meus Primeiros 1000 reais!

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!

admob-mobile-advertising

AdMob vale a pena?

Já pensou em colocar propaganda em seus aplicativos Android? Se sim, já deve saber que existe o AdMob, do Google. Basta você fazer sua conta, pegar um arquivo .jar, colocar na sua aplicação, criar uma área na aplicação para exibir as propagandas e pronto. Mas o AdMob não é exclusividade do Android. Também pode ser usado em BlackBerry e iOS. Eu resolvi fazer um teste com ele. Primeiro, eu comecei vendendo minhas duas aplicações: EncomendaZ e BrasileirãoZ. Depois, resolvi testar se valeria a pena colocar AdMob. Vamos para as conclusões deste teste.

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

Quando o Maven vira um Tormento

Conhece o Maven? É uma ferramenta muito legal. Muito legal mesmo. Eu não o usava a até bem pouco tempo. Comecei a usar fortemente quando entrei pra equipe do Demoiselle. A partir daí, não consegui mais viver sem ele. E o principal motivo é o controle de dependências. É sucesso. É muito chato ter que sair procurando as dependências manualmente e incluir no seu projeto, né não? E quando tem versão nova de alguma biblioteca? É um saco ter que ir mudando tudo de novo! Ninguém merece.

E eu agora sempre uso o Maven para todos os meus projetos. E saiu colocando indiscriminadamente as dependências de que preciso. Sequer olho as dependências transitivas que cada projeto fornece consigo. Explicando para os incautos: dependências transitivas são aquelas dependências trazidas indiretamente por suas dependências diretas. Por exemplo, se seu projeto depende do Spring, você verá que não vem apenas o Jar do Spring, mas mais alguns que você nem esperava, como bibliotecas de log. E é aí que mora o perigo. Vou relatar para vocês como o aplicativo EncomendaZ saiu de 33mb de bibliotecas para 19mb. Vai ser um post meio que crítico e de desabafo. Vamos lá.

Começo alertando: usem o Maven com inteligência. Entendam que suas bibliotecas serão usadas em outros projetos e você não pode sobrecarregá-los com dependências desnecessárias. Veja na imagem abaixo uma pequena parte da árvore de dependências do EncomendaZ. Perceba a quantidade de dependências que existe. Você vai me perguntar: e você precisa de tanta dependência assim mesmo? Eu achava que sim. E agora descobri que não. Eu não entendia como um programa tão simples como o EncomendaZ poderia ter enormes 33mb de tamanho. Tinha algo errado.

Descobri erros dos mais simples a alguns gritantes. Vamos começar pelos mais loucos que vi. Estão vendo na imagem abaixo a biblioteca ezmorph? Ela é uma dependência indireta. E coloca indireta nisso. Mas, o mais curioso é você ver que o JUnit é uma dependência dele. Mas como “compile”?! JUnit é para ser uma dependência “test”. Esta biblioteca não é para ir junto com o deploy da aplicação. É apenas para estar na máquina dos desenvolvedores que realizam testes. Fail total!

Vamos a mais um exemplo, no mínimo, esquisito. Olha a imagem aí embaixo. É a biblioteca Jaxen. Eu sei que vocês já perceberam algo estranho. Por qual motivo uma versão mais recente de uma biblioteca precisaria depender de uma versão mais antiga dela mesma? Credo! Tem algo de errado com este projeto! Olha lá. A versão 1.1-beta-8 depende da versão 1.1-beta-6. Nunca tinha visto isso na minha vida. Eles devem ter um motivo, mas isto indica que tem algo de errado aí. Não faz sentido isso.

Mais uma. Tentem me explicar por qual motivo o Jasper Reports depende do jdtcore. Só tentem, porque não vão conseguir me convencer. Sabe o que é o JDT? Retirado do próprio site do Eclipse: “JDT Core is the Java infrastructure of the Java IDE“. WTF? Uma dependência de uma biblioteca da parte de infraestrutura do Eclipse? E o Jar dele é enorme, meu caro! Quase uns 4mb.

Agora chegamos na seção críticas construtivas. As críticas acima foram pra sacanear mesmo. Aliás, tem sacanagem maior do que fazer um POM porco como os caras acima fizeram? JUnit como compile? Haja paciência. Nesta sequência, quero apenas fazer um pedido para os criadores de bibliotecas. Modelem seus projetos pensando nas pessoas que irão usá-los. Seu projeto pode ser o MEGA-FAZ-TUDO, mas você não precisa incluir todas estas funcionalidades em um único módulo. Você acabará levando para o projeto dos outros dependências que eles podem não precisar. Vamos exemplificar.

Eu precisei gerar uma impressão no EncomendaZ e parti logo para o JasperReports. Mas minha impressão era bem simples. Eu não precisava gerar PDF. Não precisava gerar XLS. Era só mandar para a impressora e pronto. O JasperReports leva pra você, “de grátis”, o iText. Trata-se de uma ferramenta para geração de PDF. E o iText já lhe fornece o Bouncy Castle. Este último é uma biblioteca que será usada caso você queira assinar digitalmente seu PDF. O iText tem cerca de 2mb. O BouncyCastle uns 3mb. Veja a imagem abaixo.

Não acho a melhor estratégia embarcar o bcprov-jdk14 junto com o iText. Quantas pessoas vão querer realmente assinar digitalmente seus PDFs? Será que são tantas assim que é melhor incluí-lo logo? Eu, sinceramente, acho que não. Muito melhor seria o iText ter dois módulos: um core e outro que inclui assinatura digital. Teria me poupado 3mb. E digo mais, o JasperReports também poderia ter sido mais modularizado de forma que eu não precisasse trazer o iText caso não quisesse criar PDFs. Teria me poupado, agora, 5mb. Caso fossem mais modularizados, eu poderia ir escolhendo exatamente o que meu projeto necessita e não ficar criando EXCLUDES no meu POM. Esses excludes são chatos e poluem sensivelmente meu arquivo POM.

Eu sei que vocês perceberam mais um detalhe na última imagem. E é até engraçado. Não percebeu? Olha lá de novo. Tem uma dependência bcprov-jdk14 na versão 138 que o iText usa. E tem uma mesma bcprov-jdk14 mas na versão 1.38 de outra dependência. Sinistro, não? É simplesmente a mesma biblioteca mas com “groupId” e versões diferentes. Credo. Existia uma duplicidade de bibliotecas no meu projeto. Eram mais 3mb desnecessários.

Finalizando, quero deixar um alerta e um apelo! Cuidado com seus projetos Maven. Não coloquem indiscriminadamente as dependências. Analisem exatamente o que você precisa. No meu caso, eu precisava do JasperReports, mas não precisava de muitas das dependências transitivas que ele trazia. Consegui tirar quase 6mb de dependências indiretas só do JasperReports. O apelo fica para quem disponibiliza seus artefatos Maven. Cuidem com carinho o seu POM. Muito carinho. Não façam asneiras como colocar o Junit como dependência compile. Cuidem bem do seu projeto para que uma versão mais recente não precise depender de uma mais antiga. E tentem modularizar para que seus usuários escolham exatamente o que precisam e não sobrecarreguem seus projetos com megabytes a mais que são desnecessários. Vocês não tem ideia de quanto os usuários do EncomendaZ agradeceram em não terem que baixar 33mb ou mais a cada versão nova lançada.

Não Quero Esmolas!

Só quero seu reconhecimento!

Vamos a mais um post “transcedental” de uma mente em plena ebulição. A questão é que preciso vir aqui para demonstrar em público minha mudança de pensamento. Não faz muito tempo, escrevi alguns posts criticando a atitude do brasileiro em não colaborar com o opensource. Obviamente, eu me referia mais à ajuda em código, documentação, reportar bugs e etc. Mas, claro, não estava deixando de lado a questão financeira. Aos desenvolvedores, cabe ajudar com as primeiras questões que falei. Aos “consumidores”, ajudar financeiramente aqueles que fizeram o aplicativo.

Na maioria das vezes, as pessoas baixam aquele aplicativo que é grátis (sim, a maioria não sabe o que é opensource e não tem interesse em saber) e não estão interessados em reconhecer o trabalho daquele que fez o aplicativo. Este era meu pensamento. Esta era minha crítica. Mudei de opinião quanto a esta questão. Três fatores ajudaram nisto: o EncomendaZ, um comentário que Rodrigo Fagundes deixou no post anterior e conversas com colegas do trabalho, principalmente Serge Rehem. Primeiro, vamos ao comentário. Sugiro ler o post, caso queira se contextualizar:

Sobre o leite em pó, eu não acho que compramos bem – compramos o que estamos acostumados. O fato de o fazermos sempre não convalida a decisão, mas só perpetua o costume.

A parte que mais me tocou foi “perpetuar o costume”. Talvez eu tenha sido muito rígido em minhas primeiras considerações sobre o assunto e me parece que a atitude desta grande maioria das pessoas não é a questão de não reconhecer, mas o seu cotidiano e alguns costumes que não lhe permitem perceber que alguém trabalhou naquele aplicativo livre e que existe a opção de reconhecer o trabalho dela. Conforme eu disse, a grande maioria não sabe o que é opensource. Sabe o que é grátis. E se é grátis, então ninguém liga que eu use sem pagar. Se é grátis, é porque esta pessoa não precisa dinheiro ou não o quer. Mas isto não torna estas pessoas insensíveis ao ponto de não conseguirem reconhecer o trabalho alheio.

Aqui também entra a questão da DOAÇÃO. Porque a doação funciona muito pouco? Digo também por experiência própria. O VeículoZ tem um botão DOAR na sua página principal e está lá bem destacado. Com mais de 1200 downloads da versão PalmOS e mais de 1100 da versão Windows Mobile, nunca recebi 1 centavo de doação. Parece-me que o comportamento das pessoas é entender de que eu não preciso do dinheiro. É grátis. Eu não preciso do seu dinheiro, só estou mendigando. E ninguém gosta de mendigo pedindo dinheiro. Conclusão: doação é quase um “por favor, me ajude!”. E “por favor, me ajude” funciona muito pouco.

E o EncomendaZ? O que ele fez mudar em mim? Propagandas à parte, eu resolvi “inventar” e não seguir o modelo padrão de venda, tal qual: fixar um preço e vender. Não. Pensei comigo mesmo: vamos deixar as pessoas usarem e pagarem o quanto elas acham que é justo. Isto não é novidade. No exterior existem lojas, restaurantes e outros serviços que são assim. Admito, contudo, que estava pessimista quanto ao retorno. Eis que fui surpreendido positivamente. E muito. A tática que usei foi mandar o aplicativo para um grupo de cerca de oito pessoas que me enviaram sugestões de melhoria. E, para receber um feedback legal, ENTREGUEI uma licença grátis para estas pessoas. Duas delas acessaram o site, leram o conteúdo e pagaram mesmo assim. E, até hoje, o valor destas duas foram os mais altos. Entenda, as pessoas que tinham a possibilidade de não pagar, foram as que pagaram o maior valor até o momento. Fiquei realmente sensibilizado com a atitude destas duas pessoas. E elas me ajudaram a mudar um pouco minha linha de pensamento.

Isso me fez pensar um pouco mais sobre meus conceitos. Principalmente meu pressuposto de que as pessoas não ajudavam porque não queriam. Talvez não. Aliás, realmente estou começando a acreditar que elas não pagavam, pois não foram sensibilizadas o suficiente. Nestes dias rolaram altos papos com Serge sobre o assunto. E uma das questões é, também, transferir para a pessoa o poder de escolha até mesmo do preço do produto que ela vai comprar. Porque eu tenho que definir? Porque não permitir para a pessoa decidir se aquele aplicativo, ou até uma obra artística, vale algo?

Certamente, muitos vão me dizer que é ilusão. Que a maioria das pessoas vai pagar muito pouco ou até mesmo nada. Mas, eu acredito que não. Falta sensibilizá-las. Claro que há as pessoas que só querem tirar vantagem. Mas elas iriam tirar vantagem de você seja lá qual for a situação. Ela poderia baixar as músicas de sua banda pela Internet de qualquer jeito. Elas iriam procurar quem tem seu CD e copiar as músicas. Elas iriam procurar seu aplicativo em um site de WareZ. Iriam tentar burlar a segurança dele. Mas, e se elas tivessem a oportunidade de pagar 0,01 centavo de algum lugar e baixar estas mesmas músicas ou aplicativos que ela já iria piratear de qualquer forma? Eis a questão. Aí está uma mudança de atitude. O mundo também não é só feito de pessoas más. As boas podem equilibrar a balança.

Para concluir, porque o título “Não Quero Esmolas!” e o subtítulo “Só quero seu reconhecimento”? Eu abracei esta ideia. O que eu produzir entrará no esquema PAGUE QUANTO ACHAR QUE VALE, PAGUE QUANTO QUISER. Até mesmo, não pague. Mas tentarei sensibilizar você de que não sou uma empresa. Sou eu, Marlon. Humano, que cansa e sente dor de coluna na frente do computador para fazer algumas coisas que poderão ser úteis para você. E, se forem realmente úteis, reconheça, da forma que achar melhor, o quanto vale meu trabalho: Não quero que você pague além do que acha que deveria. Muito menos, quero sua caridade ou esmola. Quero seu reconhecimento.

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