Experimento: hackeando o Kinect pra jogar Half Life
Um experimento bem bobo feito alguns meses atrás. No caso, eu hackeando o Kinect para que eu pudesse jogar Half-Life. Foi a minha primeira tentativa de brincar com o Kinect SDK. Nos próximos meses pretendo publicar aqui alguns outros vídeos com resultados BEM mais interessantes. Aguardem!
Livro bacana: Groovy for Domain Specific Languages
No final de 2010 o tema DSLs ganhou bastante popularidade com a publicação do livro “Domain Specific Languages” do Martin Fowler. Para quem não sabe o que são, trata-se de pequenas linguagens de programação voltadas para contextos bem específicos, como por exemplo definições de regras de negócio de uma empresa ou consulta e manipulação de bases de dados proprietárias. O principal objetivo por trás destas linguagens é transferir parte da responsabilidade da implementação das regras de negócio para o usuário final do sistema.
Apesar da popularização recente do termo, lidamos com DSL’s já há algumas décadas muitas vezes sem nos darmos conta disto. Lembra dos scripts do mirc? No UNIX/Linux usamos algumas DSL’s também sem nos darmos conta, como por exemplo o awk e o grep.
Lembrando destes exemplos, você pode pensar que se trata de uma tarefa árdua. Ledo engano: linguagens como Groovy ou Lisp nos permitem implementar estas pequenas linguagens de uma forma bastante prática, realizando assim aquele nosso sonho nerd de escrever nossa própria linguagem de programação. :D
O livro “Groovy for Domain-Specific Languages”, de Fergal Dearle, publicado pela PACKT Publishing tem por objetivo abordar o tema usando a linguagem Groovy. Terminada a sua leitura, no entanto, a conclusão que cheguei foi a seguinte: como um livro sobre DSL’s em Groovy, é na realidade um excelente aprofundamento a alguns detalhes da linguagem.
Groovy nos oferece os seguintes recursos que facilitam a criação de DSLs:
- O fato de podermos escrever nossos programas na forma de scripts
- Closures
- Builders
- A opcionalidade de alguns elementos de sintaxe como parênteses e ponto e vírgula
- MOP (Meta Object Protocol)
- AST Transformations, que nos permitem alterar parte da sintaxe do Groovy (e que pode refletir na criação das DSLs).
Com excessão das transformações AST (falha grave), todos estes aspectos são tratados em detalhe no livro, o que o torna ideal para todos aqueles que trabalham com Groovy mas raras vezes tiveram a oportunidade de aprender de fato como funcionam.
O mais engraçado é que, terminada a leitura deste livro, percebo que o autor acidentalmente (acredito) obteve um resultado inesperado. Não é um livro voltado apenas para a criação de DSL’s: é uma excelente introdução para aqueles que quiserem aprender Groovy.
Sendo assim, como avaliação final deste livro, posso dizer que como uma abordagem às DSL’s, é um excelente guia para quem quiser aprender Groovy.
Fica a dica, e espero que gostem.
Minhas boas leituras de 2011
Este ano foi excelente! Boa parte do crédito é devida a alguns livros maravilhosos que me acompanharam. Vou compartilhar com vocês parte desta experiência citando algumas leituras que literalmente mudaram minha vida.
Morro dos Ventos Uivantes – Emily Bronte
UOU! Como pude passar tanto tempo sem ler este? Resposta rápida: preconceito. Acreditava ser mais um romance meloso que me entediaria até a morte. Nada disto! Este é sem sombra de dúvidas um dos melhores romances que já li. Fantástico!
É chocante quanta maldade a “simpática Emily” conseguiu enfiar em seu único livro. E sabem o que é mais legal? É um livro ultra barato e de domínio público.
Com este livro você vai aprender que sim: a coisa sempre pode piorar!
A Conquista da América – Tzvetan Todorov
Em determinado momento decidi que queria conhecer melhor minha história como latino-americano. Foi uma ótima idéia porque com ela adquiri uma compreensão melhor do mercado de trabalho e das razões pelas quais somos desta forma hoje.
Aliás, dois posts muito comentados neste blog: “Armadilhas para Desenvolvedores: os Exploradores” e “Hernán Cortés e o Software Livre” são diretamente influenciados por esta leitura.
O ponto de partida do livro é a questão do outro, ou seja, como é formada a imagem do índigena sob o ponto de vista europeu e vice-versa. Me ajudou bastante a compreender melhor como lidar com minha auto imagem e também a entender como a percepção que tenho dos outros é formada.
Resumindo: pra quem queria apenas entender melhor a história da colonização latino-americana, sai no lucro compreendendo melhor as formas de exploração adotadas pelo mercado e como nossa percepção do outro é formada.
Anti Patterns: Identification, Refactoring and Management – Phillip A. Laplante e Collin J. Neil
Uma das minhas buscas foi a de um ambiente de trabalho melhor. Como estou trabalhando com mais gente achei que seria importante aprender a lidar melhor com meus colegas de trabalho. E este livro foi uma descoberta maravilhosa.
Em Anti Patterns, o foco são exemplos que jamais devemos deixar acontecer em um ambiente de trabalho. É uma leitura bem mais interessante do que mais um daqueles livros de gerenciamento que sempre me causam a impressão de estar vendo um mundo no qual as condições de temperatura e pressão são ideais. Longe disto!
Foi interessantíssimo porque durante a leitura percebi que devo ter passado por uns 70% dos terríveis exemplos citados (“sortudo”), o que me causou uma sensação confusa de orgulho (sobrevivi!) e tristeza. Uma tristeza produtiva que me fez executar uma série de melhorias em minha vida cujos resultados estão sendo muito bons.
Racing the Beam – The Atari Video Computer System – Nick Montfort e Ian Bogost
Foi o livro que me revolucionou tecnicamente: simples assim. O objetivo dos autores é mostrar como a arquitetura do Atari influenciou a criação de todos aqueles jogos que salvaram minha infância de um desastre total.
Virou minha leitura obrigatória que tento empurrar a todos aqueles que, assim como eu, não programam apenas para pagar as contas, mas sim porque AMAM a coisa. Não consigo negar a inveja que senti de programadores como David Crane (criador do Pitfall).
É aquele tipo de leitura que te faz repensar o modo como desenvolvemos software hoje. A pergunta que mantive após a leitura é a seguinte: temos hoje temos um ambiente de desenvolvimento fantástico, mas será que o nosso produto final faz justiça a todo o nosso poder de fogo, ou será que não nos tornamos no final das contas um bando de mimados?
Só por curiosidade: Pitfall tem 255 telas. Quanto elas ocupam de memória? 8 bits. :)
Mal-Estar no Trabalho: Redefinindo o Assédio Moral – Marie-France Hirigoyen
O livro acidental do final de ano. Nanna o tinha em mãos e eu por curiosidade resolvi levá-lo para o banheiro e, bem: ela ainda o está esperando. :)
Ta ai um assunto que nunca imaginei ser interessante. Fui fisgado logo nas primeiras páginas. Finalmente consegui entender o que vêm a ser o tal do “assédio moral” e, sabe de uma coisa? Percebi que acidentalmente posso já ter cometido e sofrido assédios também.
Através de uma série de exemplos a autora vai mostrando ao leitor situações que normalmente ignoramos mas que consistem em assédios. Pra aumentar a culpa de nós, assediadores acidentais (ou não), a autora ainda mostra os efeitos físicos do assédio em suas vítimas.
Leitura fantástica: está me fazendo rever de cabo a rabo a maneira como lido com meus colegas de trabalho. Recomendo a leitura para todos aqueles que não tem como objetivo de vida profissional a vida em isolamento ou que desejam um armamento teórico melhor pra lidar com o problema.
Alguns livros técnicos
Houve também alguns livros técnicos que me ajudaram bastante este ano. Abaixo está uma pequena lista daqueles que mais valeram à pena:
- Enterprise Integration Patterns – Gregor Hohpe e Bobby Woolf – leitura obrigatória pra qualquer um que desenvolva sistemas corporativos complexos (de fato complexos)
- Java Concurrency in Practice – Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea – após ler este livro você percebe que não sabia nada sobre concorrência :)
- Camel in Practice – Klaus Ibsen e Jonathan Anstey – Tive uma experiência maravilhosa com Camel na Squadra, e este livro me ajudou bastante (dica: se for ler este livro, leia o EIP antes)
- Programming Clojure – Stuart Halloway – Neste ano comecei a realizar um sonho antigo: criar algo útil com alguma variante do Lisp. Este livro têm me ajudado bastante.
- Scheduling Algorithms – Peter Bruker – Quer se sentir muito burro? Leia este livro. Este ano tive de lidar com problemas envolvendo escalonadores (num falei que foi um ano massa?) e desconfio que após sofrer horrores com este livro fiquei um pouquinho mais esperto viu? :)
- Java Reflection in Action – Ira R. Forman e Nate Forman - Ta ai um assunto que pouco javeiro entende bem. Foi um dos assuntos que mais me divertiu em 2011.
- PHP in Action: Object, Design, Agility – Dragfinn Reiersol, Markus Baker e Chris Shiflett – quem diria? Em 2011 voltei a brincar com PHP. E sabe o que percebi? Nós do Java temos muito o que aprender com este povo ai.
Compra do ano: um tablet meia boca
Se há um aspecto negativo em 2011 pra mim este se chama trânsito. Como eu ficava em média umas 3 ou 4 horas por dia preso neste inferno, comprei um tablet bem vagabundo. No caso, um Coby Kyros 7015, que me serviu muito bem por uns 6 a 8 meses até que seu carregador foi pro saco. Se você assim como eu ama ler e fica muito tempo no trânsito, é algo que vale à pena comprar.
Concluindo
Estes foram alguns dos livros que li neste ano e fizeram toda a diferença pra mim. Espero que estas dicas sejam úteis a alguém que por algum acaso tope com problemas similares.
Agora é esperar pelas leituras de 2012, que também prometem. E você? Que livros fizeram seu 2011?
PS:
e sim, já estou trabalhando no próximo vídeo da série sobre Groovy/Grails. Aguardem! :)
Groovy e seus mutantes: terceira parte do Guia Groovy/Grails em vídeo
Continuando a minha série sobre vídeos, é hora de nos aprofundarmos nos aspectos mutantes do Groovy. Ao menos os mais fundamentais para que a sua compreensão do Grails seja a melhor possível.
Os seguintes tópicos foram abordados:
- Closures: que droga é esta?
- Executando funções e acessando propriedades de forma dinâmica
- Como modificar nossas classes em tempo de execução
- E pra finalizar, como fazer um mexidão de classes usando mixins
Espero que gostem deste vídeo o mesmo tanto que eu gostei de fazê-lo. Ele marca uma mudança radical no material que pretendo publicar daqui pra frente.
Para acessar os vídeos restantes, use este link.
Guia Grails em Vídeo > Groovy: o “Java” que sempre quis – Aula 02
Como prometido, o vídeo da semana, entitulado “Groovy: o ‘Java’ que sempre quis’. Este e os próxmos vídeos serão focados não no Grails, mas no componente que o torna tão produtivo: a linguagem de programação Groovy.
AVISO
Um dos maiores equívocos cometidos por iniciantes em Grails (erro este que costuma inclusive destruir projetos) é programar em Groovy exatamente como seria feito com Java tradicional. Funciona? Sim, mas você cairá nos seguintes problemas:
- Sua performance pode ser inferior – afinal de contas, você não está programando “à moda Groovy” e, consequentemente, o compilador pode deixar de executar uma série de otimizações no seu código.
- Sua compreensão do framework será menor: Grails tira proveito de cada aspecto imaginável do Groovy. Muitas vezes, o “pensamento Java” irá te impedir de compreender o quê de fato está acontecendo por trás dos panos.
- Sua produtividade vai ser bem menor: só pra lembrar, o objetivo por trás do Groovy é justamente prover maior produtividade aos desenvolvedores Java.
Neste vídeo, os seguintes assuntos foram tratados
- O que é Groovy – (99% de chance de você já saber :) )
- Como instalar – (opcional se você só vai trabalhar com Grails)
- Principais diferenças sintáticas em relação ao Java
- Melhorias no tratamento de strings e números
- O que vêm a ser a tal tipagem dinâmica?
Segue o vídeo: espero que gostem :)
Curso itexto de Grails: Aula 1
Acabo de publicar o segundo vídeo da série sobre Grails que pretendo publicar nos próximos meses. A idéia do primeiro vídeo é mostrar a construção do ambiente de desenvolvimento que será usado no transcorrer do curso. Para quem já viu o vídeo anterior, não há muita novidade, mas há algumas bastante importantes:
- Foi inaugurada a página “Grails: um guia em vídeo“, aonde pretendo postar todos os vídeos que eu venha a publicar sobre o assunto. Vai ser massa, porque assim fica mais fácil assisti-los em sequência.
- Todo o material do curso é publicado no GitHub neste repositório.
Neste vídeo os seguintes assuntos foram tratados:
- Instalação do Grails: executo o processo no Windows 7 (mas no repositório há um texto explicando como proceder caso você seja um usuário Linux ou Mac)
- É apresentada a aplicação base: um gerenciador de estoque. É um exemplo suficientemente complexo para que eu possa em aulas posteriores me aprofundar (e BEM) nas entranhas do Grails
- Inicio o desenvolvimento básico do projeto implementando as classes de domínio e criando o CRUD básico via scaffolding dinâmico. Neste processo, daremos uma pincelada em cima dos seguintes tópicos:
- A estrutura básica de diretórios
- Classes de domínio: definição de atributos e constraints
- Scaffolding dinâmico
- Configuração do acesso a dados
- Finalmente, é gerado o pacote que pode ser instalado em praticamente todos os servidores de aplicação Java EE do mercado.
Sem mais demora, segue o vídeo:
O assunto do próximo vídeo será a linguagem Groovy e as principais diferenças desta em relação ao Java. Meu objetivo é mostrar uma série de armadilhas que podem ser evitadas pelos iniciantes e mais algumas técnicas que ajudam demais a incrementar nossa produtividade.
Espero que gostem. :)
Video: Grails: o que e porquê?
Olá, estou aqui divulgando o meu último video, chamado “Grails: o que e porquê?” que foi feito para o evento “Semana Grails no Rio”. Meu objetivo é mostrar as principais razões pelas quais Grails vale à pena e como o seu modo de trabalhar difere daquele com o qual estamos acostumados no “Java tradicional”.
É também o primeiro de uma série, visto que estou planejando regravar meu antigo curso de Groovy/Grails que fiz pela DevMedia. Espero que gostem!
Grails: o que e porquê? from Henrique Lobo Weissmann (Kico) on Vimeo.
Hernán Cortés e o Software Livre
Hernán Cortés: sempre aprontando das suas...
A questão da conquista da América pelos espanhóis me fascina. Infelizmente, quanto mais leio a respeito mais me identifico com os nativos.
Estou lendo “A Conquista da América – A questão do outro”, de Tzvetan Todorov. Seu foco é a formação da imagem do nativo americano aos olhos dos conquistadores espanhóis. E num capítulo chamado “Compreender, Tomar e Destruir” tenta-se responder a seguinte questão: se os astecas eram a fonte de tanta riqueza para os espanhóis, o que os motivaria a aniquilar tão violentamente esta galinha dos ovos de ouro?
Foi quando um golpe sob a forma de frase me derrubou:
“(…) se a compreensão não for acompanhada de um reconhecimento pleno do outro como sujeito, então essa compreensão corre o risco de ser utilizada com vistas à exploração, ao “tomar”; o saber será subordinado ao poder.(…)”
É lindo quando alguém consegue colocar em palavras uma intuição que sempre tive.
Livro massa!
Conquistando o Software Livre
O trecho que citei acima pode ser aplicado a qualquer relação de exploração e acredito que se aplique bem na questão do software livre. Posso falar a respeito: afinal de contas não conheço muitos brasileiros que, assim como eu, invistam até financeiramente nesta idéia.
Com o tempo algo foi se tornando claro sobre uma fatia enorme dos usuários de software livre (especialmente desenvolvedores): sim, as pessoas compreendem seu valor e o usam para gerar riqueza. O problema é que não reconhecem o fato de ser fruto do trabalho de outra(s) pessoa(s).
Alguns exemplos: fulanos que postam alguma dúvida no Grails Brasil e me contactam por mensagem instantânea imediatamente exigindo que eu lhes responda. Outro? E-mails demandando que eu forneça um patch o mais rápido possível para algum projeto antigo de código aberto, como por exemplo o Miocc ou ODF Easy. Entenda: não tenho nada contra quem apenas usa software livre, mas odeio quem abusa de seus autores ou das pessoas que realmente participam do seu progresso.
Já ouvi muito o argumento de que o simples fato de estar usando o software já é uma forma de apoio. Na boa? Papo furado. Este argumento cai na contradição que expus no meu post anterior. Você está ajudando software livre com publicidade quando fomenta a comunidade, não como quem apenas demanda sem oferecer nada em troca.
Aniquilando o software livre
O massacre do software livre
É importante conhecer a diferença entre a destruição e aniquilamento. Na destruição deformamos algo de forma brusca e contra a sua vontade. Já o aniquilamento implica na remoção da razão da existência do objeto. Vou ser profético: acredito que estamos caminhando para o aniquilamento do software livre.
As pessoas produzem software livre visando reconhecimento que servirá para gerar algum lucro indireto através de consultorias, treinamentos, customizações ou mesmo obtenção de emprego em algum lugar devido à sua expertise. Conforme o abuso aumenta, torna-se economicamente inviável a contribuição para estes projetos, ou seja, aniquila-se o software livre.
Então como eu ajudo o software livre?
Neste caso, acredito que o processo deve ser iniciado a partir da seguinte pergunta: supondo que eu fosse o sujeito que desenvolve este software (que está inclusive me gerando algum retorno financeiro), como eu gostaria de ser ajudado?
Outra pergunta legal: “estou abusando?”. A resposta é fácil: se você demanda sem oferecer nada em troca, sim: você está abusando.
Ajudar portanto é simples: dê algo em troca. Pode ser qualquer coisa, desde que contribua. Participa de um fórum? Que tal buscar responder algumas perguntas ao invés de só buscar salvar o próprio rabo? Achou um bug? Não quer dizer que deva solucioná-lo imediatamente, pois muitas vezes não possuímos conhecimento técnico para tal, mas que tal apenas reportar o bug? Aliás, da pra ir um pouco além: que tal além de reportar o bug, também o divulgar para ver se alguém consegue resolver o problema?
Concluindo
O grande problema do software livre é a ilusão de que trata-se de um bem gratuito. Não existe grátis: tudo é feito visando algo em troca. O mínimo que devemos fazer é reconhecer este fato e ajudar quem está nos ajudando.
Armadilhas para desenvolvedores: os exploradores
Cristóvão Colombo: empreendedor do século XV que se daria muito bem na área de TI do século XXI
Recentemente li dois livros maravilhosos que me fizeram repensar o mercado de desenvolvimento de software: “As Veias Abertas da América Latina”, de Eduardo Galeano e “Brevísima relación de la destrucción de las Indias”, de Bartolomé de Las Casas. O assunto é o mesmo: o modo como as Américas foram brutalmente exploradas e os indios dizimados pelos espanhóis e portugueses.
Transpondo para a minha realidade, percebi que os exploradores ainda atuam, só que na área de TI do século XXI. Há uma nova “etnia” a ser explorada: os tais dos desenvolvedores, que “curtem tanto o que fazem que muitas vezes trabalham até de graça” (já ouvi isto). Ah, e claro: usar a palavra “explorador” depois deste passado sangrento pega muito mal: então a palavra da vez é “empreendedor”. Nada pode dar errado (e raras vezes da).
Primeira tática: escambo
“Oi Nativo, tudo bem? Tenho um negócio massa pra você: que tal você me dar o seu ouro em troca destas minhas pedrinhas brilhantes mágicas? Topas?”
A frase me soou tão familiar que fiquei vermelho de vergonha. Um empreendedor te procura com uma idéia maravilhosa, porém não pode lhe pagar em espécie. No lugar, te oferece algum bem não financeiro, como por exemplo um video game, parceria (vou falar mais sobre parcerias logo à frente), computadores ou alguma outra bobagem cuja liquidez seja mínima ou inexistente. E você aceita rindo!
Ah... o escambo!
Logo em seguida você rala feito um louco e entrega o resultado final ao “empreendedor”, que sempre pede alguma coisa a mais, muitas vezes ultrapassando em muito o valor do que você recebeu.
Me desculpe cagar na sua janta amigo, mas se você topou (assim como eu), você fez papel de otário. Isto porquê o sujeito não lhe pagou o valor REAL do seu trabalho, mas o custo reduzido que ele tem para obter a bugiganga que te empurrou. Então, se seu trabalho valesse R$ 100,00 e você recebe como pagamento um livro de R$ 100,00, na realidade nosso amigo empreendedor te pagou R$ 60,00 no máximo.
E… tem outra: contas normalmente são pagas em dinheiro, não em missangas. Mesmo que você venda a porcaria que recebeu, só o seu trabalho em tentar obter liquidez com esta joça já diminuiu ainda mais o seu ganho.
Segunda tática: divulgação
“Oi Nativo, tudo bem? Se me fornecer seu trabalho, contarei para o meu Deus a seu respeito, e este jogará sobre ti graças infinitas!”
Recebi um e-mail HOJE que é uma transcrição deste papo furado. Segue abaixo:
“Oi Henrique, tudo bem?
Acompanho seu blog há muito tempo, e sei que você é referência em Groovy/Grails. Estamos iniciando um projeto que terá grande visibilidade nacional e gostaríamos de te ter como parceiro, o que se pagará para ti como uma publicidade monstruosa.
Topaz?˜
Ah... a fama!
E você vê a possibilidade de fazer inúmeros clientes e contatos. Claro que você vai topar: afinal de contas, o sucesso depende de contatos, certo? Vai ser uma publicidade monstruosa! O que poderia dar errado?
Tudo.
Seguinte: publicidade monstruosa é aparecer o SEU nome na mídia REAL, e não em comentários de rodapé em reportagens de revistas que não valem nada ou num boca a boca pouco expressivo que é o que realmente acontece.
Publicidade REAL se obtém fazendo um bom trabalho, tarefa esta que é REMUNERADA e RECONHECIDA pela QUALIDADE. Quer saber de uma coisa? ESTA é a melhor divulgação possível: quando sua obra é citada porque atendeu BEM o cliente e este, satisfeito, te indica para outras pessoas.
Ou então, quando o cliente não te indica para ninguém mas, sabendo que este está satisfeito, você mesmo publica o case no seu site. Por favor: não caia nesta arapuca como já cai inúmeras vezes.
Terceira tática: parcerias
“Nativo! Tudo bem? Olha: acho que podemos crescer trabalhando juntos. O que me diz de participar comigo de um ou mais projetos sob o regime de parceria?”
Ah... as parcerias!
Quem trabalha com desenvolvimento e NUNCA recebeu um e-mail com a proposta de entrar de sócio em uma parceria na qual nada pode dar errado que atire o primeiro monitor LCD de 42 polegadas!
Sabe o que é mais engraçado? Percebi que os desbravadores que te propõem parcerias não sabem, eles mesmos, o que é uma! Só pra lembrar, uma parceria deve lidar claramente com as seguintes questões:
- Claramente, qual é o objetivo em comum?
- Como será a distribuição dos ganhos E, ainda mais importante, dos gastos? Qual o capital a ser usado e qual será sua distribuição?
- Quais os objetivos individuais de cada participante? (fundamental para evitar a concorrência entre os membros)
- Qual a distribuição das tarefas?
- Qual o plano de negócios?
Se você mandar esta lista de perguntas pro “proponente” e ele não te responder TODAS, já te digo qual o tipo de parceria que você está entrando: escravidão. O sujeito tá procurando mão de obra gratuita pra um projeto que, numa boa? Provavelmente não irá pra frente.
Se não passar, você não tem uma relação de parceria, mas sim meramente comercial, na qual ambos os lados querem apenas maximizar o próprio lucro (não há nada de errado com isto).
Por quê é assim hein?
A culpa é 80% nossa. Muitas vezes, gostamos TANTO do que fazemos que acabamos ficando muito bons na coisa e começamos a achar fácil o negócio. E então surge o seguinte pensamento: “ah, isto é fácil! Não vou cobrar muito”, ou então o pior deles “não acredito que estão me pagando pra fazer isto!”(!!!).
Gente: escrever software NÃO é fácil. Se fosse, já existiriam geradores de código eficazes pra executar esta tarefa e programadores não existiriam mais. Se seu software é de qualidade, não há problema ALGUM em cobrar o valor justo pelo seu trabalho.
Nossa formação também não é comercial. Somos desenvolvedores: projetamos e escrevemos software, não contratos comerciais. Mas ai é preciso fazer alguns questionamentos:
O que é “caro”?
Vais sair mais caro que minha caravela!
Simples: algo é caro quando o valor investido é maior que o ganho esperado. Pagar por um tablet xingling o preço de um iPad é caro, porque ele não te traz o mesmo ganho. Ao mesmo tempo, contratar um profissional com valor hora de R$ 1000,00 por um dia pra resolver seu problema num projeto cujo valor é R$ 1.000.000,00 não.
Sendo assim, se o desbravador vier pra cima de você com o papo de “seu trabalho tá muito caro”, levante as seguintes perguntas:
- Qual o ganho esperado pelo resultado do meu trabalho?
- A qualidade do seu trabalho vale o que você está cobrando? Faça uma auto-crítica. Será que você é realmente tão bom assim quanto se vende? Em caso afirmativo, baseado em quais FATOS?
Exemplo: o cliente tem um servidor de R$ 3000,00 para executar o seu sistema. Se você propõe R$ 3500,00 e ele te diz que ta caro, porque o PC dele custou menos que isto, você pergunta o seguinte: “qual o valor do seu PC sem o meu software?”
Se agrega valor não é caro: é investimento. O bandeirante ainda acha caro mesmo após ter justificado o valor? A solução é fácil: diga-lhe que consulte o mercado em busca de outras soluções. Normalmente não vale à pena.
Como você justifica o custo?
É muito fácil virar para o seu cliente e dizer: “custa X”. Custa X porque? Qual a unidade empregada? Numa boa: oferecer valores injustificados alimenta o desbravador contra você. Acredito ser fundamental ter alguma métrica a ser exposta, seja esta qual for: homem hora, pontos de função, casos de uso, que seja.
O importante é ter uma linguagem em comum pra não ter de escutar depois o “ta caro”. Sem esta, você está simplesmente alimentando indefinidamente esta merda toda.
Lembre-se do seguinte: no seu valor deve vir inserido todo o tempo que você investiu com estudo, pesquisa e aprimoramento. Este esforço não deve em hipótese alguma ser negligenciado. Não se aperfeiçoa em algo simplesmente pra ser o melhor nela e por assim ficar. Não! Este investimento DEVE ser refletido no seu valor hora.
Como eu evito cair nesta?
Nossos empreendedores tem uma arma tão poderosa quanto as espadas e a pólvora: o dinheiro. É fato: você precisa dele pra sobreviver, e não pode em maneira alguma se queimar no mercado. Mas ao mesmo tempo, assim como você depende do cliente, o contrário também é verdade.
Segue aqui então uma lista de atitudes que tem me ajudado a escapar destes ataques uns 70% das vezes:
- JAMAIS faça nada de graça (ô arrependimento!): as pessoas não valorizam o gratuito. Você com certeza receberá um obrigado, mas não mais do que isto.
- Cobre o justo: não esfaqueie seu cliente. Cobre o valor correto para manter uma relação de longo prazo.
- Não comece a trabalhar antes de ter um orçamento aprovado (neste caso, o errado é você que se afobou)
- Valorize-se: se seu trabalho fosse tão fácil assim, não estariam te procurando pra fazê-lo.
- Seja honesto: é a única forma de ter moral em qualquer negócio e também de se diferenciar da multidão de picaretas que destroem nossa imagem
Concluindo
Uma vez eu ouvi a seguinte frase: “se trabalho fosse bom, não te pagavam pra isto”. A resposta foi imediata:
“Olha: meu trabalho É bom. AMO o que faço, então me dedico ao ofício. Consequentemente, vou ser um dos melhores.
As pessoas me pagam portanto não é porque é ruim, mas porque não conseguem executar a mesma tarefa que executo, no tempo que faço e com a qualidade que ofereço.”
PS: fui muito influenciado pelo excelente blog do Luiz DiVasca @divasca, cujo link é http://divasca.blogspot.com/. Precisamos de mais gente com sua coragem.
Groovy vs Java: listas
O erro mais comum de quem está aprendendo Grails é programar em Groovy exatamente como seria feito em Java. É um comportamento comum, visto que aparentemente não há tantas diferenças sintáticas assim entre as duas linguagens. Reparou que coloquei “aparentemente” em negrito?
Este post é o primeiro de uma série na qual pretendo comparar as duas linguagens e tentando convencê-los a não cometer o pecado de se programar em Groovy como se fosse Java.
Primeira diferença: as listas estão presentes na sintaxe do Groovy
Em Java para criar uma lista o caminho padrão é instanciar alguma classe que implemente a interface java.util.List, gerando código como o abaixo:
List<Tipo> lista = new ArrayList<Tipo>();
Em Groovy temos um elemento sintático só para lidar com listas que são os colchetes. O mesmo código que escrevi em Java, eu reescreveria em Groovy assim:
def lista = []
A variável lista armazena agora uma instância de java.util.ArrayList. Repare: eu não preciso definir (e nem tenho como usando esta sintaxe) o tipo que esta lista irá armazenar, porque Groovy possui tipagem dinâmica.
E sabe o que é mais legal? Eu também posso já instanciar minha lista preenchida, tal como nos exemplos abaixo:
def lista_de_strings = ["Uma bonita lista", "com muitas", "strings"] def lista_ecletica = ["Uma string", 23, true, false, ["uma", "lista", "interna"]]
Em Java é possível instanciar uma lista e ao mesmo tempo já definir o seu conteúdo. Há duas maneiras de se fazer isto: você pode usar um construtor que receba como parâmetro um objeto que implemente a interface java.util.Collection OU pode usar um código bem feio usando inner classes. Quer ver? Bem, aqui vai:
List<String> lista_strings = new ArrayList<String>() {{
add("Uma lista");
add("Com código muito");
add("Feio");
}};
ALERTA: se estiver programando em Groovy exatamente como faz em Java, é certo que ao topar com uma lista como as que expus acima você irá acreditar se tratar de um array.
Acessando elementos
Como em Java as listas são implementações da interface java.util.List, acessar os elementos sempre é feito pelo método get, como no exemplo abaixo:
String valor = lista.get(1); // pego o segundo elemento
Sabe, em Groovy eu posso fazer exatamente como em Java, já que é uma instância de java.util.ArrayList. E também de uma forma mais bacaninha. :)
def valor = lista[1] // pego o segundo elemento def valor2 = lista.get(1) // a la Java
Inserindo e removendo elementos
Em Java, quando queremos adicionar um elemento em uma lista, usamos o método add, como no código abaixo:
lista.add("String quente");
Em Groovy podemos usar um recurso poderoso que é a sobrescrita de operadores. Quer ver como funciona?
def lista = []
lista += "Uma string" // O operador += serve para inserir um elemento na lista
lista.add("Uma outra string") // a la Java
def nova_lista = lista + "Adendo" // crio uma nova lista, chamada nova_lista, que contém o conteudo de lista + uma String
Resumindo: o operador += inclui elementos na lista, enquanto o operador + cria uma nova lista.
E pra remover você provávelmente já sabe também:
def lista = ["um", "Monte", "de", "strings"] lista -= "Monte" // removo o elemento "Monte" def nova_lista = lista - "de" // crio uma nova lista que não contém o elemento "de"
Outro resumo: o operador – remove um elemento, enquanto o operador -= cria uma nova lista que não contém o elemento passado como parâmetro.
Buscando elementos
Se em Java você quer retornar todos os elementos de uma lista que satisfaçam a um critério, o código a ser escrito vai ser parecido com isto:
List<Pessoa> pessoas = new ArrayList<Pessoa>() {{
add(new Pessoa("Kico", 32);
add(new Pessoa("Loló", 29);
add(new Pessoa("Theo", 0);
}};
List<Pessoa> pessoas_com_mais_de_um_ano = new ArrayList<Pessoa>();
for (Pessoa pessoa : pessoas) {
if (pessoa.getIdade() > 1) pessoas_com_mais_de_um_ano.add(pessoa);
}
E em Groovy, como faço hein? Assim:
def pessoas = [new Pessoa([nome:"Kico", idade:32]), new Pessoa([nome:"Loló", idade:29]),
new Pessoa([nome:"Theo", idade:0])]
def resultado = pessoas.findAll { it.idade > 1 }
Eu uso a função findAll, que recebe como parâmetro uma closure. O papel desta é simples: retornou true? Adicione na lista de retorno.
E se eu quiser só o primeiro resultado?
def resultado = pessoas.find {it.idade > 1}
Vou retornar não uma lista, mas a primeira instância que satisfaça ao resultado.
Outro problema: como você verifica se pelo menos um objeto em uma lista satisfaça a uma condição? Em Java, escrevemos um monstrinho como o código abaixo:
public boolean existeUmBebe(List<Pessoa> lista) {
for (Pessoa pessoa : lista) {
if (pessoa.getIdade() < 1) return true;
}
return false;
}
Wow! E como eu faço em Groovy hein? Eu uso a função any
pessoas.any { it.idade < 1 }
A função any, assim como find e findAll são injetadas em todas as listas pelo Groovy, e todas recebem como parâmetro a closure que verifica a condição.
Iterando sobre o conteúdo
Em ambas as linguagens, iteramos sobre o conteúdo usando o loop for. Até ai, nada demais. A diferença é que Groovy injeta em nossas classes um método chamado each, que recebe como parâmetro uma closure. Então é possível iterar em cima do resultado de uma consulta de forma bastante simples, tal como no exemplo abaixo:
def lista = [new Pessoa([nome:"Kico", idade:32]), new Pessoa([nome:"Loló", idade:29]),
new Pessoa([nome:"Theo", idade:0])]
lista.findAll { it.idade > 0 }.each {
println it.nome
}
O parâmetro que a closure recebe é o elemento corrente da iteração. E sabe o que é mais legal? A closure não precisa ser passada na hora.
def trabalhe = {pessoa ->
if (pessoa.idade > 0) { println "Tá velho!"} else {println "Ta quase velho!"}
}
pessoas.each trabalhe
Coletando valores de atributos
Imagine que no nosso exemplo, precisemos coletar todos os nomes das pessoas presentes em nossa lista. Em Java, escreveríamos algo como o código abaixo:
List<String> nomes = new ArrayList<String>();
for (Pessoa pessoa : pessoas) { nomes.add(pessoa.getNome()); }
Em Groovy, usamos a função collect que é injetada nas coleções. Esta recebe como parâmetro uma closure que será iterada em cima de todos os elementos da lista. O valor de retorno de cada iteração é adicionado a uma lista que é o resutlado da função. É complicado de descrever, mas vendo o código fica mais fácil. :)
def nomes = pessoas.collect { it.nome }
Concluindo
Eu só arranhei a superfície do assunto. O que fica claro é: com Groovy você escreve muito menos código. Um ponto importante a ser salientado é: quando escrevemos código em Groovy usando a sintaxe do Java estamos dificultando a vida do compilador, que sofrerá horrores tentando otimizar o seu código. Há portanto duas consequências neste pecado:
- Digita-se bem mais
- O código é mais lento
Pra finalizar, dois links que ajudam muito quem está aprendendo:
Groovy Console: http://groovyconsole.appspot.com/ (pra você experimentar código Groovy online)
Coleções em Groovy: http://groovy.codehaus.org/JN1015-Collections (diversos dos detalhes que não citei estão aqui)
