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.

Eu Prometo!

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

JavaMagazine, Vaadin e a G Magazine

Esqueci de comentar aqui no blog uma coisa importante: mais um artigo publicado na JavaMagazine. Já é o terceiro e o quarto está por vir. Escrever é um exercício bem bacana pra mente e regularmente eu procuro fazer isso. O artigo em questão é uma introdução ao Vaadin. Conhece o Vaadin? É, você não mora nesse planeta mesmo. Eu sou sincero: eu odeio do fundo das minhas entranhas o desenvolvimento web “dirigido” a tags. Odeio mesmo, é sério. E o Vaadin foi minha escapatória.

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!

Valeu a Pena? Parte 2: Vender

Vamos à parte dois da série “Valeu a Pena?”. Agora é hora de escrever sobre esta reviravolta, já que eu sempre disponibilizei meus aplicativos sob licenças livres, como GPL, Apache e LGPL. Primeiro, eu sempre achava um absurdo os valores praticados pela Microsoft. Eu não comprava aplicativos e pirateava mesmo, com todo orgulho. Com todo amor. Na maior parte do tempo eu usei Windows, Office, Photoshop e tudo mais pirata. Isto começou a mudar quando passei a usar mais Linux e me focar principalmente na programação. E, desde então, meio que peguei uma aversão a pagar por software.

Parecia estranho. Aliás, é estranho, pois um produto físico, você o vê, sente, toca. Software, não. Parece que seu dinheiro evaporou. E também eu vinha de uma conduta de baixar aplicativos indiscriminadamente sem nem saber se precisaria ou não. Eu, simplesmente, não sabia parar, ler as especificações de um programa, baixar a versão demo para testar e ver se valeria a pena gastar a grana. Eu ia direto na cópia pirata. Não importava testar o programa. Comprar? Pffff… é para os fracos. Eu tenho certeza que muitos de vocês estão se sentindo iguais a mim. 🙂 Mas, vocês precisam mudar, igual a como eu mudei.

E esta visão começou a mudar quando comprei o iPhone e vi tantos aplicativos por 1 dólar. Ainda assim, comecei pirateando! Mas perceba a conduta errada: eu gastei 1000 reais em um iPhone mas me negava a pagar 1 dólar por um bom aplicativo. É a velha questão de que não conseguimos ver o valor de um aplicativo. Parece que pagar por eles é ser trouxa. Muitos pensam assim.

Minha primeira experiência, vendendo um aplicativo, foi com o EncomendaZ. O preço? “Pague Quanto Quiser”. E o retorno foi muito bacana. Desde pessoas que me chamaram de maluco, pois tudo tem que ter um preço bem definido, a pessoas que acharam a ideia excelente. Os valores pagos? Foi desde 1 real a até 29,90 reais. Minha atual jornada está em disponibilizar aplicativos pagos na Android Market. Por enquanto, tenho percebido que não está valendo muito a pena. Mas talvez seja coisa momentânea. Preciso de mais tempo para analisar. Estou tentando agora o uso do AdMob para ver se propaganda vale mais a pena.

Um aprendizado: a maioria das pessoas não gosta de decidir, por conta própria, o valor de algo. Elas preferem que você diga o quanto vale e pronto. Mas toda essa experiência tem sido bem legal. E outro detalhe que sempre ouvi de Alexandre Gomes: é fácil, muito fácil, vender bits. Veja bem: imagine se fosse um guri de 14 anos que tivesse feito o EncomendaZ? Difícil? Não acho. Veja quantos guris estão ganhando muita grana na Apple Store. Quanto de aporte financeiro essa gurizada precisou? Fora a grana do pai para sustentar elas: nada. Você precisa de vontade, empolgação, entusiasmo, não desistir na primeira tentativa e por aí vai. O resto, a internet faz por você.

Enfim, meus caros, tem valido a pena vender os aplicativos. Não estou milionário. Longe disso. Mas estou ganhando uma experiência muito interessante sobre isto. Quem sabe, um dia posso usar isto a meu favor e ficar rico? Estou focado, principalmente, em explorar o que muitos programadores deixam de lado: User Experience. Ou simplesmente UX. Eu já fiz um post sobre isto, quando critiquei arduamente os programadores que fazem sistemas horrorosos. E minha experiência nisto tem comprovado que as pessoas estão cada vez mais interessadas em sistemas bons, fáceis de usar e bonitos. Pode acreditar! 🙂

DSL no DemoDroid

Eu curto muito estas linguagens novas, como Groovy e Ruby. A sintaxe delas permite fazer códigos lindos. A melhor parte, para mim, é poder criar uma DSL de forma fácil e bem intuitiva. No Java, também é possível, mas não fica tão bonito como ficaria em um Groovy, por exemplo. Ah! Você está por fora do que é uma DSL? Tradução: Domain Specific Language. Eu gosto de dizer que uma DSL pode ser vista como um subconjunto de uma linguagem, ou até mesmo uma linguagem própria, para resolver problemas específicos.

Você vai por aí muitas DSLs. Já encontrei o Mirror, que é uma DSL para usar Reflexão em Java. Parece-me que é um projeto de brasileiros. Então, fica aqui meus parabéns! E você pode criar DSLs para diversos tipos de situações específicas. Olha como é o código do Mirror para definir o valor de um atributo de um objeto:

new Mirror().on(target).set().field(fieldName).withValue(value)

Percebe como a leitura deste código parece mais natural do que aquele monte de linhas da API de Reflection do Java? Você pode até ler naturalmente como: Mirror (new Mirror()), no (on) objeto tal (target) defina (set) o atributo tal (fieldName) com o valor tal (withValue). Bacana, né não? E que diabos eu quero com esse blá blá blá? Vamos lá! Nessa ideia de DSL, é que eu resolvi criar uma para incorporar no DemoDroid. Uma coisa recorrente no desenvolvimento em Android é precisar disparar uma tarefa que leva um tempo razoável de processamento e você quer exibir uma mensagem de progresso.

Para quem já programa em Android, sabe que é necessário usar a class android.os.AsyncTask. Veja abaixo um exemplo de utilização dela, retirado do BrasileirãoZ:

new AsyncTask<Void, Void, List<Jogo>>() {

	private ProgressDialog dialog;
			
	protected List<Jogo> doInBackground(Void... params) {
		try {
			return campeonato.getRodada(final_rodada).getJogos();
		} catch (Exception e) {
			messageContext.add("Erro");
		}
		return new ArrayList<Jogo>();
	}

	protected void onPreExecute() {
		if (dialog == null) {
			dialog = ProgressDialog.show(getView(), "Consultando...", "Obtendo Jogos.", true);
		}
	}

	protected void onPostExecute(java.util.List<Jogo> result) {
		JogosPresenter.this.getView().setJogos(result);
		JogosPresenter.this.getView().setRodada(final_rodada);
		dialog.dismiss();
	}
}.execute();

Nada mal, não é? Um monte de linha de código para fazer muito pouca coisa. E também pouco intuitivo para quem está lendo. Uma pessoa que pega este código para ler, precisa ter um conhecimento bem legal da classe AsyncTask para poder usá-la. E olhe que esta classe do Android até que é bem simples. Existem outras muito mais difíceis. E por que não trocar este monte de linha de código, por isso aí embaixo? Não acha mais intuitivo? Claro, ainda posso melhorar e fica aí para você me sugerir melhorias. Esse código faz um processamento muito semelhante ao daí de cima:

new Async()
	.using(getView())
	.call("getJogos").on(event.getClube()).noArgs()
	.during().show("Consultando...", "Obtendo Jogos do Clube.")
	.after().call("setJogos").on(getView()).withResultAsArg()
	.occurring().crash().alert("Tente novamente mais tarde",1)
	.occurring().success().alert("Jogos atualizados!", 1)
	.execute();  

“programador”.hates(“design”)

Hoje estou aqui para sacanear com meus colegas de profissão. É uma crítica bem descontraída. Não levem a mal. 🙂 A questão é que nós, programadores, temos extrema dificuldade em criar aplicativos de fácil uso, organizados e bonitos. Nos falta a tal “Veia de Designer” em nossa constituição genética (lá ele). Falta para nós aquele feeling. Aquele toque final. Sabemos fazer muito bem aplicativos para outros programadores usarem. Mas, para usuários finais, os conhecidos “Orelhas Seca”, somos péssimos.

Normalmente, criamos telas complexas. Pedimos cliques desnecessários para o usuário. Colocamos ícones onde não deveriam estar. Usamos texto quando deveríamos ter usado imagens. Usamos mensagens que fazem sentido só para nós e para ninguém mais no mundo. É verdade, admita. Nós não gostamos de criar aplicativos para os outros usarem. Sempre chegamos com a velha conversa fiada: “AH, mas funciona!“. Ou a clássica: “ah! o mais importante é que as funcionalidades estão atendidas. O resto é perfumaria!“. Não! Usabilidade e organização gráfica de um sistema nunca são perfumaria. São itens essenciais e nunca devem ser menosprezados. Eu entendo que é tão importante quanto implementar os requisitos que o usuário pediu explicitamente. Seu sistema pode fazer tudo o que o usuário deseja, mas as pessoas vão odiá-lo se tiverem dificuldade em usar.

Observe os sistemas que você faz. É sempre o mesmo formato horrível: um cabeçalho que não serve para PORRA NENHUMA, um menu inútil com opções ridículas, um corpo e um rodapé que só é usado para você massagear seu ego colocando seu nome e a versão do sistema. Como se o usuário estivesse interessado nisso. Para o dito cujo chegar na principal funcionalidade do sistema, normalmente, precisa dar uns três cliques entre menus e botões. E mais, quando ele chega na principal tela do sistema, descobre que não pode cadastrar nada ainda, pois tem um ComboBox vazio e ele precisa dar mais uns cinco cliques para ter que cadastrar esta informação. E, para finalizar, a velha mania de nomear seus sistemas com “SISTEMA DE…”. Muito tosco. Pensando que vão melhorar, aí criam siglas que sempre começam com SG?? (Sistema Gerenciador de…). Quanta criatividade!

Perceba como damos pouca atenção para a usabilidade (existe este termo?) do sistema. Sempre fazemos aplicativos quase no automático. Criamos uma tela de CRUD para cada entidade. Se tem um cadastro de estados, tem uma tela para cadastrá-los. Todo e qualquer tipo de entidade que o sistema tem, sempre criamos automaticamente uma inútil tela de cadastro. Nunca nos perguntamos se ela é realmente necessária. Simplesmente ter um combobox com texto em aberto para o cara digitar o nome do estado caso já não exista, não é o suficiente? Com esse paradigma, você acabou de poupar alguns cliques para o usuário e dezenas de navegações entre telas.

Dá uma rápida olhada na tela deste sistema abaixo. Eu aposto 1000 reais fácil de que os usuários cadastram apenas três ou quatro campos deste formulário em 99% das vezes. Mas estão lá um milhão de campos para poluírem a tela e fornecerem informações pouco úteis na maioria dos casos.

Quando chegamos no mundo dos celulares então… os programadores são mais sem noção ainda. O infeliz já sabe que o celular é um aparelho pequeno e que manuseá-lo é chato. Mas, ainda assim, faz sistemas em que o usuário precisa dar várias “dedadas” na tela para conseguir fazer algo útil. Totalmente nonsense. Normalmente, eu deixo uma dica mínima para esses programadores: comprem um Mac. Use-o com atenção. A Apple é simplesmente foda na concepção de interfaces com o usuário. O Mac nunca perguntou, desde seu princípio, se o usuário quer REALMENTE apagar um arquivo quando clica na opção para isto. Se o cara clicou é porque QUER em 99% dos casos, caceta. Para que pentelhar o usuário com essa pergunta toda vez? Para os 1% restantes, basta ter uma opção UNDO e pronto.

Quem usa Mac já percebeu que não existe botão “Apply”, após você alterar as configurações? Já se perguntou o motivo? É simples, em 99% dos casos, eu realmente quero fazer as alterações. Apenas em 1% dos casos eu não queria. Novamente, um UNDO resolve. Dou mais risada ainda com a mania de encher o sistema de funcionalidades para parecer que ele é completo. Nunca nos perguntamos qual o percentual mínimo de pessoas que de fato usarão estas funcionalidades a mais. Perdemos tempo com bobagens quando poderíamos ter investido um tempo fazendo o sistema mais “usável” pelos mortais.

E deixem essa mania de dizer que design é coisa de viado. Se você quer ter um diferencial nos sistemas que você faz, comece a prestar atenção nisto. Ler o livro The Humane Interface é um bom início. Ouça o feedback dos usuários com carinho. Não torça o nariz quando o usuário fala que prefere amarelo no lugar do vermelho. O mercado está simplesmente entupido de aplicativos que prometem fazer tudo, mas 90% deles possuem interfaces simplesmente horríveis. Dão pena. E aí você pode fazer a diferença. Não ache que porque a AppleStore já tem aplicativos demais, você não deve entrar na competição. Pode e deve entrar. E seu diferencial TEM que ser esse.

Software: Indo às compras

Vou me arriscar em uma área que não é muito a minha. Mas, vou botar a cabeça a prêmio. Sou corajoso. Já tendo vivenciado quase 15 anos de desenvolvimento de software, me arrisco a dizer uma coisa: as empresas deveriam se preparar para comprar software. Deixa eu tentar uma explicação melhor. Toda empresa deveria ter pessoas treinadas para comprar um aplicativo, podendo ser ele já pronto (software de prateleira), ou acompanhar o desenvolvimento de um aplicativo adquirido de uma “software house”. Entenda meu ponto de vista: informatização é fato. Não tem como nenhuma empresa correr disto. Acho que é até questão de competitividade ter a automação de atividades através de aplicativos dentro da empresa. Então, vou fazer algumas analogias para tentar explicar a questão.

Software de Prateleira

Quando você vai comprar um pacote de leite em pó, você não está muito interessado em saber o processo de extração do leite, esterilização e posterior secagem. O que lhe importa é que o leite tem bom sabor, é nutritivo, não está com prazo de validade vencido e é de boa procedência. Só isto basta para você decidir entre uma marca ou outra.

Na compra de um software de prateleira temos algumas similaridades. Você não quer saber qual foi o processo de desenvolvimento usado na fabricação do Windows Vista. Se foi usada alguma metodologia Ágil ou variantes do RUP. Qual diferença fará? O software já está pronto para seu uso. Basta comprar e usar. Importa, sim, se ele atende a alguns requisitos mínimos que você espera. Alguns diretamente ligados ao negócio da empresa. Outros, ligados a questões não funcionais, como desempenho, disponibilidade e por aí vai.

Software encomendado


Você pensou: vou reformar minha casa. Vou renovar a sala. Trocar o piso. Pintar as paredes. Trocar a fiação elétrica. A parte hidráulica também. E isto tudo para no Natal minha família ver minha nova casa. Bom, você contrata, então, um TIME para fazer isto tudo: encanador, pintor, pedreiro e eletricista. E também pede logo indicações de amigos por pessoas de confiança, certamente. Time escolhido, o prazo é de 4 meses. E começam os serviços em setembro. Os caras, então, já começaram e aí, quando o pessoal está quase concluíndo a troca do piso da cozinha, você tem a genial ideia: vou mudar a porta de lugar. Os pedreiros ficam putos da vida.

Pouco tempo depois, mais uma BRILHANTE ideia. Não quero mais essa cor rosa na cozinha, não. Vou botar azulejos. Agora, o pintor e o pedreiro ficam MUITO putos da vida. Depois de todas estas ideias sensacionais, você começa a achar que o time que você contratou está lhe enrolando. Eram 4 meses. Já se passaram 5 meses. Não vai dar mais tempo para passar o feliz natal com a família!

Está conseguindo fazer o paralelo com o desenvolvimento de um aplicativo encomendado? As vezes, você faz o papel do idiota que quer mudar a porta de lugar quando não é mais o momento de fazer isto. Na reforma de uma casa, ou você entende de pintura, encanamento, eletricidade ou é melhor deixar com quem entende: um arquiteto. Paga um arquiteto de sua confiança e fique tranquilo, pois ele estudou para trabalhar com isto. Caso você queira assumir esta responsabilidade, deve entender que está assumindo um alto risco de estragar tudo [1]. Não tente supervisionar algo do qual você não entende.

Em uma empresa, você precisa colocar uma pessoa que sabe do assunto e tem um mínimo de conhecimento sobre as dificuldades que envolvem a criação de um aplicativo: quando não é mais o momento de pedir novas funcionalidades e ter uma versão funcional, como cobrar uma equipe de desenvolvimento, conhecer quando está sendo enrolado e coisas deste tipo. Ou isto, ou deve entender que está assumindo um alto risco de estragar tudo [2].

Voltando…

Deste ponto de vista, não é salutar para uma empresa investir para que tenha pessoas com um mínimo de conhecimento na área de desenvolvimento? Não estou sugerindo a criação de um setor específico. Muito longe disto. Também não estou sugerindo um treinamento em todas as metodologias possíveis. Nem que coloquem um programador para o cargo (não mesmo!).

Alguns vão sugerir para mim que isto é trabalho do analista de sistemas ou analista de negócios. Depende dele ser bom o suficiente para acalmar seu cliente, ser seu professor explicando os prós e contras disto e daquilo, um psicólogo, babá, tutor de metodologias de desenvolvimento e, além disto tudo, um analista de sistemas. Há 15 anos atrás, isto fazia sentido. Para mim, hoje nem tanto. O próprio comprador deve saber COMO pedir, O QUÊ pedir e a FORMA como deve cobrar.

Eu sei que as vezes falo besteira. Portanto, me corrijam caso isto tenha acontecido, deixando seu comentário. 😛

CBSoft 2010

Vamos a um registro mais formal da CBSoft 2010. O post anterior foi informal, já neste, tentarei ser direto e elencar meu ponto de vista daquilo que vi no evento. Para os que ainda não sabem do que estou falando, sugiro acessar o site do evento e se atualizar sobre o assunto. Neste evento, fiquei mais interessado pelo Workshop Brasileiro de Desenvolvimento de Software Dirigido por Modelos (WB-DSDM). Por qual motivo? Simplesmente, porque nunca acreditei muito nisso. Sempre tive uma visão de que software é artesanal e desenvolver dirigido a modelo só serve para tarefas que são repetitivas e cansativas, como o CRUD. Desenvolver todo um sistema, incluíndo todas as regras de negócio e suas complexidades somente através de modelos não é algo que eu acho factível. Mas, eu queria ir lá e ver o que estava acontecendo de novo. Observar as novidades, os estudos atuais e etc.

A primeira palestra que vi foi de Jon Whittle, da Universidade de Lancaster, na Inglaterra. O título de sua palestra foi: How To Succeed (or Fail) with Model-Driven Engineering: A Qualitative Study of What Works (and What Does Not). Logo de início, o palestrante me causou surpresa com a afirmação: o maior benefício do MDD (Model Driven Development) não é a geração de código. Pronto, o cara conseguiu segurar minha atenção. Como assim? MDD para mim sempre foi geração de código a partir de modelos e isto não é a parte mais importante? Segundo o estudo de Jon Whittle, há outros benefícios na adoção de MDD por uma empresa que vão além da “simples” geração de código. Dos benefícios listado, o que mais me chamou a atenção foi referente à questão arquitetural. Conforme entendi, uma vez que uma equipe decide usar MDD, obriga-se a pensar de forma mais generalizada, pensando de forma a atender ao maior número possível de sistemas que possuem características comuns. Concordei.

Outra constatação do estudo realizado por Jon e que não me causou surpresa alguma: MDD funciona muito bem em empresas cujo o objetivo não é o desenvolvimento de sistemas, como fabricantes de impressoras (HP e Epson, por exemplo). Claro! De fato, observe que estas empresas não precisam customizar seus aplicativos para cada tipo diferente de cliente. O foco deles é apenas um: vender impressoras. Seus aplicativos serão sempre muito parecidos e aí o MDD trabalha perfeitamente, eliminando substancialmente a quantidade de código a produzir. O mesmo não se pode dizer de empresas que possuem diversos tipos de clientes, cada um com suas particularidades. Aplicar MDD de forma mais ampla em empresas deste tipo é mais difícil. Vejo que operações de CRUD podem ser facilitadas, mas, fica meu questionamento: se este estudo todo é só para facilitar CRUD, pra mim é perder tempo.

Depois desta palestra, passamos a uma série de artigos, alguns que não me interessaram, outros bem legais. Um artigo me chamou a atenção pelo título: Um Relato de Experiência no Desenvolvimento Ágil de Sistemas com MDA. Contudo, após ler o artigo e ver a apresentação percebi que houve um foco grande na ferramenta e o termo “agilidade” foi usado mais como chamativo. A ferramenta aparenta ser interessante, mas, como eu já desconfiava, estamos falando de uma ferramenta bem preparada para operações CRUD. Em seguida, outro artigo me chamou a atenção: A Business Process Metamodel for Enterprise Information Systems Automatic Generation. O artigo sugere a criação de um novo metamodelo para a geração de código através de processos de negócio. Trocando em miúdos, sugere uma nova linguagem, baseada na BPMN2.0. Um ouvinte fez a pergunta que eu gostaria de ter feito: porque criar uma nova linguagem e não estender a BPMN, já que esta permite extensões? O palestrante respondeu que não havia problema, uma vez que ele usava o mesmo dialeto, acrescentando novas notações. Não me convenceu, até mesmo porque a nova notação sugerida é um subconjunto da BPMN.

Em seguida, tivemos uma apresentação que é uma continuação do trabalho anterior. Enquanto um sugere a especificação de um novo metamodelo baseado em BPMN, este sugere um novo metamodelo para a criação de interfaces com usuários. Depois deste, passamos por uma série de artigos que pouco chamaram minha atenção, mais por não estarem diretamente ligados ao desenvolvimento de software do meu dia a dia. Entre eles, alguns descrevendo técnicas de datamining, correlação entre linguagens de programação e MDD, modelagem de dados geográficos e coisas deste tipo. Enfim, um trabalho me chamou a atenção de novo: Mapping Code Generation Templates to a Reference Implementation – Towards Automatic Code Migration. Daquilo que consegui absorver desta apresentação, o palestrante aponta o uso de Templates como uma técnica bastante usada em MDD. De fato, vemos isto bastante em Java, com engines de template como Jet, Velocity e tantas outras. Contudo, o trabalho aponta um problema que precisa ser resolvido: se você tem uma implementação de referência usada para gerar o seu template, como manter sincronizados seu template e esta implementação, no caso de modificações na segunda? Aí que entra este trabalho, sugerindo uma técnica que permite a sincronização automática. O trabalho limitou-se a sugerir a técnica, não havendo implementação da ideia em código.

Agora, vamos ao minicurso 09. Foi interessante, pois propôs uma DSL (Domain Specific Language) para a criação de sistemas web. O nome da linguagem é WebDSL. A ideia é ter uma linguagem mais fácil de ser aprendida e que tem um foco específico. A partir desta linguagem, pode-se ter um compilador, que traduz esta DSL para uma linguagem específica, como Java ou Ruby. A ideia me parece interessante, mas acredito que o grande ponto negativo ainda é a questão do Debug. “Debuggar” é essencial para encontrar erros e não ter esta opção em uma linguagem complica bastante. Contudo, ainda vejo futuro pra ideia e que talvez possa ser aplicada de alguma forma ao Demoiselle.

Conclusão? Gostei do evento. Gostei dos assuntos abordados em sua maioria. Não gostei das apresentação, conforme já citei no post anterior. Foram apresentações fracas, sem motivação, chegavam a dar sono e ficar acordado estava difícil. Infelizmente, me parece que os acadêmicos não ligam muito em chamar a atenção de sua platéia. Parece que estão ali por obrigação e acabam transformando uma apresentação que deveria ser agradável e interessante em algo desestimulante.

Apresentações ZzZzZz

Fui ao CBSoft deste ano, realizado aqui em Salvador. Muito assunto interessante. Aliás, ler alguns artigos acadêmicos é bom para clarear as ideias e saber o que está levantando mais interesse na academia. E perceba, eu disse ler artigos é bom. Assistir palestras de acadêmicos é um porre. Vou contar a verdade. Eu nunca tinha percebido a importância de uma apresentação. Nunca tinha ligado muito para isto. A verdade é que eu assisti a várias apresentações acadêmicas e dormi em 90% delas. Pensei que o problema estava apenas em mim. Mas a vida segue. Suas ideias mudam. Ainda mais eu, uma verdadeira metamorfose ambulante (saudoso Raulzito).

Então, um belo dia, fui criticado por uma apresentação minha e me falaram em uma tal de Apresentação Zen. Resolvi dar uma chance e fui pesquisar. Li sobre o assunto e concordei. Mas, de fato, só entendi o verdadeiro significado de uma apresentação zen quando eu presenciei uma. E, pasmem, não tive 1 segundo de sono. Eu fiquei olhando para o apresentador o tempo inteiro. O cara me cativou, fez meus 45 minutos valerem a pena. Aí entendi: caceta, se eu tiro uma pessoa de sua casa para ir me ver apresentando algo, eu tenho uma grande responsabilidade. Eu preciso que minha apresentação seja agradável, interessante e CATIVANTE. Senão, que merda eu estou fazendo ali? Inflando meu ego? Tirando minha onda? Conseguindo mais duas linhas para o meu currículo? Não, eu estou ali porque as pessoas acreditam que eu tenho algo importante e interessante a dizer para elas. Pronto, a semente da Zen Presentation estava plantada em mim (aos baianos, um LÁ ELE bem grande).

No CBSoft percebi que os acadêmicos, e aqui eu vou generalizar, uma vez que o evento reunia pessoas de todos os estados e até internacionais, não dão a mínima para suas apresentações. E perceba, eu não estou falando da organização de seus slides em bullets. Isto é o de menos. Eu falo do entusiasmo dessas pessoas em fazer a apresentação, que é abaixo de zero. Salvam-se apenas os mestrandos e graduandos que aindam se esforçam para fazer bonito. Já os mestres e doutores parecem estar ali por mera obrigação. E vejam só, do meu ponto de vista, os acadêmicos deveriam ser aqueles que mais precisam de motivação e entusiamo em suas apresentações, afinal, estamos falando de ciência. São estas pessoas que deveriam descer do salto alto e se expressar verbalmente de maneira melhor, cativando as pessoas e tentando trazer adeptos à sua causa.

Já vivi isto na pele. Quando ainda buscava um mestrado, não foi apenas um, mas alguns professores mestres e/ou doutores que me “aconselharam” a ter palestras em grandes eventos. Não importava o assunto ou se eu o dominava. Nenhum deles estava preocupado se eu estava preparado para fazer uma apresentação digna para as pessoas. O importante era meu currículo. As pessoas que iriam me ouvir? Pouco importam, as duas linhas a mais no meu currículo é que era o importante. Perceba, as duas linhas a mais no currículo são importantes, mas não mais do que transmitir com clareza, lucidez e entusiasmo suas ideias.