Today i’ll be moving my blog from the current host. During this time it may be inaccessible due to DNS changes and it should take some time until new DNS are replicated. Sorry for the inconvenience.
See you soon!
Before I get to the point in this post I should say that this is my first post in English and because of that I’m sure that it’s going to have a lot of mistakes. Knowing that, I would like to ask you to correct me whenever you find one of them. Ok? Let’s go!
I’ve been working as a professional developer since 2004. At that time I didn’t really know anything about software development. Nowadays, almost six years later I still don’t know much, but one thing I do know: only people can make a project succeed.
Since I started working I talked to many people from many different companies (clients and co-workers) and for a little bit more than two years i am in a position where i can choose if we should hire someone or fire someone. During this time I’ve heard almost nothing about people getting fired for being a bad professional. That’s a strange behavior and made me think. Why don’t I see many people being fire? I think I can count on my fingers how many times I saw someone getting kicked out from a company. If we pick my team as example I can tell you that we worked approximately with thirty different people in these years and I can only remember of letting one person go.
After gathering this personal experience, watching a lot of presentations and reading books and articles I realized that projects and products that were successful had one simple[1] thing in common: good people.
I think that the modern companies that are full of those “quality guaranteed” processes (ISO, CMM, ITIL and [put another silver bullet process in here]) forget how to make people perform good on their jobs. They put too much effort in the belief that the process is enough to keep things great and forget that people doing mediocre work are very bad for business.
By doing nothing to this people, we are encouraging who doesn’t do a good job instead of congratulate who really does. If I stop and look backwards I’ll see that i did that myself a lot of times. I saw someone on the team that was not up to his/her tasks and even seeing that I kept myself quiet. This is very harmful for everyone involved.
Another reason of why it happens is laziness. Managers and leaders often see that a team member is not corresponding well but they are too lazy and accommodated to do something about it. It’s easier to let things just happen than change the situation and hire someone more skilled[2] to do the job.
I could seat here and write until sun shines again how a bad professional looks like, but I’m pretty sure you know how to recognize one. Everybody knows what a bad professional looks like, but still, they have jobs and they make my job (and yours, good one) more difficult.
So from now on, promise yourself that you’re not just going to keep the wheels spinning. Propose changes, challenge people, force them to do their best. If after all this hard work you still have a bad team member, fire him/her and give his/her place to someone who deserves it. This is the only way we can build better teams and make bad professionals go away (or improve themselves).
[1] Yeah, it’s pretty simple once you’ve figured that out.
[2] By skilled I meant technical and personal skills that are very necessary to make a person able to be part of a team.
Não, esta ainda não é a volta dos meus posts técnicos. Essa semana estou me ajeitando aqui em BH então se tudo der certo volto a postar nesse fim de semana, ja que vou ter bastante tempo livre.
Enquanto isso, criei uma conta no Flickr pra colocar algumas fotinhas que for tirando. Check it out!
As férias estão acabando, mas o tempo acabou não sendo 100% dedicado a descanso. Quem convive comigo sabe que a algum tempo eu estava participando de um processo interno da Stefanini para uma posição em um cliente nos EUA. Eu sempre trabalhei em consultorias e tinha vontade de trabalhar em uma “empresa de verdade” onde o core business não fosse TI, mas sim uma ferramenta de apoio onde os projetos tem continuidade e você pode ver o monstrinho crescer. Outra vontade sempre foi morar fora do país, principalmente onde a desigualdade e as possibilidades de levar uma vida mais justa fossem maiores. E este momento chegou, foi um processo longo e cansativo, mas durante esse período de férias o resultado saiu e eu tive que começar a mexer os pauzinhos para deixar o pais.
Isso mesmo. A partir da próxima semana não farei mais parte do time que ajudei a montar aqui em São Paulo. Irei para Belo Horizonte em outro escritório da Stefanini fazer um “estágio” com a equipe que atende a HNI Corp aqui do Brasil para na sequência, provalvemente no final de junho, me juntar ao time in-loco da HNI em Muscatine no Iowa.
A empresa onde vou trabalhar é uma das maiores fabricantes de móveis do mundo e curiosamente fica numa cidade minúscula de apenas 25 mil habitantes bem no centro dos EUA. O time da HNI, que não é pequeno, já conta com uma dúzia de brasileiros então não vou ficar completamente sozinho nesse novo ambiente. No entanto, a dor de barriga é grande, pois é uma mudança enorme deixar tudo que construi aqui no Brasil para começar uma vida nova fora do pais.
Não posso afirmar com certeza se vai ser para sempre, mas a curto prazo não pretendo voltar pro Brasil (só a passeio 
).
O blog continua, mas provavelmente começarei a escrever em inglês apenas. Acredito que isso não seja um problema porque a grande maioria dos leitores aqui do blog e do público em geral de TI se vira bem no idioma. Minhas outras participações na comunidade também continuam de maneira remota e com uma experiência diferente e cheia de uma nova visão.
Bão…era isso!
Wish me luck!
Hmmm…. bastante tempo sem escrever já né? Quase um mês!
Nestas últimas semanas muitas coisas aconteceram e não sobrou tempo e nem paciência para escrever. E olha que eu adoro escrever, principalmente quando tem coisas legais para falar.
Mas…não vai ser hoje ainda que vou escrever. Depois de três anos sem férias, finalmente saio hoje e volto 04/05. Espero voltar renovado, pois foi um ano complicado e cansativo.
Meu projetinho de FTP com Rails andou e quero postar a respeito e também pude usar bastante (não o suficiente ainda) da API do Google Maps que é muitoooo legal! Na volta com certeza vou escrever sobre.
E se tudo der certo…terei algumas novidades.
Até lá!
Não, não, não! Uma coisa não tem nada a ver com a outra. Não é um post falando de como debuggar rails utilizando o WinDBG. Mas um único post dando dicas de boas referências sobre o assunto.
Ultimamente não tenho mexido muito em código. Na verdade não tenho visto nada técnico, pois estou atolado de propostas pra fazer (quem mandou não estudar? ). Mas…hoje quando cheguei em casa decidi que iria dedicar algum tempinho para mexer em algo interessante e diferente. Foi ai que topei primeiro com rails que eu já queria começar a estudar e depois com o WinDBG numa dica que veio do Twitter do André Nobre.
Ruby on Rails
Há alguns dias instalei o ubuntu em uma VM aqui em casa e montei todo o ambiente Rails para começar a fuçar. Apesar de ainda não ter concluído e contrariando as dicas do Rafael Rosa que disse para eu fazer algo mais simples, iniciei a construção de um programinha de FTP web em Rails. Na verdade, hoje eu parei num “Hello World”. De qualquer forma, para quem está curioso para começar a mexer e ver o poder da ferramenta decidi disponibilizar alguns links que eu já havia encontrado e que o Rafa me passou. Ai vai:
- RubyInside - Maior portal Brasileiro sobre notícias de Ruby. Primo do site gringo http://www.rubyinside.com.
- RailsCasts - Diversos screencasts gratuitos a respeito de Rails. Cobre diversos assuntos com exemplos.
- RubyQuickRef - Site contendo uma referência rápida as classes de Ruby.
- Rails Guides - Segundo o Rafa, site que contém guias obrigatórios para os Railers que além de ensinar a programar em RoR, ensina “in the rails way”.
- Rails API - Toda documentação da API do Rails.
- Ruby API - Toda documentação da API do Ruby.
- Micro-tutorial Rails Parte 1, Parte 2 e Parte 3 - Micro-tutorial sobre Ruby no blog do AkitaOnRails. Desde o básico até alguns conceitos avançados.
- Montando ambiente Rails em Windows - Tutorial ensinando a montar o melhor ambiente Rails em Windows também do AkitaOnRails.
- Blog do Rafael Rosa - Várias coisas a respeito de Rails e também de Asp.NET MVC
Esses são só alguns. Com certeza tem muito mais e espero colocar mais informações a respeito de Rails conforme eu for mexendo!
WinDBG
Debuggar código é uma arte. As vezes mais difícil do que criar código do zero. Afinal, quando debuggamos código que não é nosso temos que entender o que quer dizer e as vezes é tão mau escrito que é triste de ver…
Além do debug que estamos acostumados, dentro do VS existem debugs mais baixo nível que podemos fazer. Lá na CLR e no Windows, quando as fronteiras já passaram nossa aplicação. Praticamente coisa de louco!
Não é um assunto simples, nem tão pouco fácil de aprender. Há alguns meses navegando nos blogs da Microsoft encontrei o blog da Tess Fernandes que é engenheira da Microsoft. A menina é du mau e ela fala basicamente de debugging e assuntos relacionados a performance. O problema é que muito dos tópicos sobre debug que ela aborda são muito avançados para newbies como eu.
Ai é onde entra o blog do André Nobre que já tem diversos posts em português e em um nível iniciante para ajudar as mentes mais ignorantes neste assunto como é meu caso. Alguns dos posts inclusive são em formato de screencast com demos. Vale a pena conferir para aprofundar um pouquinho mais nesse assunto e conhecer uma outra alternativa para descobrir porque aquela maravilhosa aplicação que desenvolvemos não funciona como deveria.
Enjoy!
Quem acompanha o blog e/ou me conhece sabe que já a algum tempo tenho várias idéias de produtos e serviços que poderiam ser oferecidos e que dariam uma graninha a médio e longo prazo. No entanto, nunca coloquei nenhuma dessas idéias em prática, mas um dia chega a hora né?
Não sei se é uma coisa comum oferecer parcerias e sociedades em blog, mas como já estou chegando em quase cem assinantes (de acordo com o feedburner) acho que o público e a visibilidade são propícias. Pode ser que não de em nada, mas não custa tentar.
Estou sem escrever a alguns dias, pois nesse tempo estava pensando e colocando algumas idéias no papel, maquinando como poderia arquitetar um ou outro projeto.
O que eu preciso então? Qual a idéia do parceiro/sócio?
Desde sempre, fui e sou desenvolvedor de software, mas nunca tive muito tato para design, usabilidade e marketing. Acho que essas áreas de conhecimento são fundamentais para qualquer oferta de sucesso, pois não adianta de nada termos o melhor produto do mundo se ele não for fácil de usar, bonito e tiver um bom apelo comercial. Portanto, procuro alguém com essas habilidades para formar uma parceria para trabalhar com produtos e serviços web. Por conta disso, quem quiser tem que gostar muito da coisa.
Neste momento, não consigo oferecer nenhum incentivo financeiro ou prometer qualquer retorno em curto prazo, mas é por isso que procuro alguém para trabalhar junto comigo e não para mim.
Tudo que posso oferecer é muita vontade em construir algo próprio e boas idéias.
Claro que qualquer necessidade financeira não muito grande que venha a ser necessária para fazer o negócio andar pode ser suprida, mas tudo com muita calma.
A preferência é para as pessoas que forem de São Paulo, pois é onde moro e dessa forma ficaria muito mais fácil tocar o negócio. Não que seja impeditivo trabalhar com alguém de fora, mas com certeza será mais um desafio a ser vencido.
Se alguém tiver interesse e vontade de ser dono do próprio nariz dentro de algum tempo favor entrar em contato por email ou me adicionar no MSN para conversarmos.
Ontem participei de um evento da Stefanini sobre agilidade junto com o André, Alexandre Magno da Adaptworks e Fábio Kung da Caelum e como não podia deixar de ser, esse assunto surgiu: como vender este tipo de serviço? Como elaborar propostas que estejam alinhadas com modelo ágil e que não exponham exclusivamente o fornecedor e ao mesmo tempo sejam atrativas ao cliente? Infelizmento como esperado, não existe resposta exata para essa pergunta (ainda?).
No entanto, existem algumas abordagens que podemos utilizar a fim de chegar em um consenso. Vou falar um pouquinho a respeito e se alguém tiver algo a contribuir, será melhor ainda.
Atualmente vendemos software na ilusão de que alcançaremos prazo, custo e escopo sem surpresas. Mas… isso não é verdade. Nunca foi. Trabalhar dessa maneira, a não ser que seja em um ambiente conhecido e extremamente controlado quase sempre nos leva a fracassar em um desses pontos, quando não em todos.
O ideal nesse caso, é sentar com quem vende, com quem elabora contratos, com a área jurídica e com quem executa e procurar o modelo ideal para sua oferta de agilidade. Scrum, XP, MSF são apenas modelos de gerenciamento de projetos e engenharia, que não dizem como realizar essa venda. Isso não é o papel dessas ferramentas. Cada empresa deve encontrar sua forma de trabalhar essas ofertas.
Se utilizarmos métodos ágeis e iterativos em uma proposta de escopo fechado das duas uma: ou não vamos efetivamente trabalhar de maneia iterativa, pois precisamos controlar o escopo o tempo todo ou como fornecedores vamos tomar prejuízo, pois provavelmente o escopo será maior do que o contratado já que não conseguimos medir de maneira confiável o escopo de um projeto em tempo de proposta.
Fora do Brasil um modelo de venda que já é muito aceito e difundido é o “Tempo e Material” (Time and Material) que é basicamente trabalhar “hora aberta”, ou seja, o fornecedor recebe X por cada hora trabalhada. Posso afirmar com certeza que essa é a melhor maneira do fornecedor de trabalhar com metodologias ágeis já que não temos um cronomêtro financeiro em contagem regressiva. Mas será que essa é a melhor maneira pro cliente? Muitos deles dizem que sim, pois se a consultoria aplicar realmente um modelo ágil é fácil medir e verificar se o trabalho está sendo feito e se está sendo feito de maneira adequada atendendo as expectativas e objetivos do cliente. O problema é que nosso mercado, principalmente as repartições públicas, não estão preparadas para isso, ainda. Fornecedores e clientes ainda não se entenderam a ponto de confiarem uns nos outros e acreditar que esse modeo colaborativo funciona melhor do que o baseado em documentos que-me-protegem-de-qualquer-mudança ao qual estamos acostumados. Enquanto isso não acontece (e tenho fé que vai acontecer!) temos que continuar vendendo e comprando e trabalhando para alcançar os objetivos do cliente.
Para diminuir um pouco esse medo dos clientes de serem enganados e gastarem demais e diminuir o risco do fornecedor na presação de serviços existem algumas coisas que podemos fazer.
Uma delas é adicionar uma cláusula de fuga nestes contratos “hora aberta” que permite que, caso um cliente ou até mesmo o fornecedor não esteja satisfeito com o andamento do projeto, este possa cancelar o contrato sem onûs para ambos os lados. Dessa forma, é possível “obrigar” tanto ao fornecedor quanto ao cliente a trabalharem em conjunto, pois se qualquer um pisar na bola o outro pode sair fora num piscar de olhos.
Outra maneira é elaborar um contrato de preço fixo e com tempo estimado utilizando qualquer técnica com as quais já estamos acostumados, mas não fixar completamente o escopo do projeto ou então garantir que apenas uma parte do escopo seja entregue. Talvez algo entre 60% e 80%. Isso também diminui um pouco o risco do fornecedor em dar um preço fechado e ao mesmo tempo garante ao cliente que ele terá seu sistema desenvolvido com um método de qualidade mesmo sem ter 100% de escopo definido em proposta entregue. Na verdade, muitas vezes isso nem é necessário já que o principrio de pareto afirma que 80% dos benefícios gerados por um sistema são proporcionados por apenas 20% das funcionalidades.
Seja qual for a maneira que você trabalha, o mais importante é estar alinhado com seu cliente e trabalhar de maneira honesta e transparente porquê se você for sinero e honesto e realmente ajudar seu cliente a atingir seus objetivos, ele provavelmente não irá te deixar na mão. Isso também vale para clientes. Se você ajudar seu fornecedor e não procurar tirar vantagem de contratos que obriguem ele a ter prejuízo com certeza ele não irá faltar com você e te ajudará a crescer.
Referências adicionais
José Papo Website - Apresentações e informações a respeito de contratos ágeis
Improve IT - Modelo de contrato ágil
Na primeira parte falei um pouco dos problemas envolvidos no controle de versionamento de banco de dados. Agora esta na hora de apresentar alguma solução, certo?
Apresentando Migrator.NET
Para resolver a maioria (senão todos) os problemas de versionamento de banco temos uma ferramenta maravilhosa chamada Migrator.NET. Essa ferramenta é um port para .NET do original em Rails. A idéia por trás dela é bastante simples: consiste em diversos objetos (classes) versionados (da mesma maneira que código normal) contendo as instruções que devem ser executadas para gerar e/ou voltar o schema do banco de dados. Cada classe corresponde a uma instrução de alteração e contém um método Up (adicionar/avançar) e um método Down (retroceder/fallback) equivalente. Vejamos como é facil no exemplo abaixo:
#region Usings
using System.Data;
using Migrator.Framework;
#endregion
namespace NetScrum.Migrations.Tables
{
[Migration(20090209211900)]
public class CreateTableProject : Migration
{
public override void Down()
{
Database.RemoveTable("netscrum_project");
}
public override void Up()
{
Database.AddTable("netscrum_project",
new Column("id", DbType.Int32, ColumnProperty.Identity)
, new Column("name", DbType.AnsiString, 100, ColumnProperty.NotNull)
, new Column("description", DbType.AnsiString, 300, ColumnProperty.Null)
);
Database.AddPrimaryKey("pk_project", "netscrum_project", "id");
}
}
}
Viram? Basta referenciar a DLL Migrator.Framework.dll, adicionar a diretiva using criar sua classe herdando de Migration e dar override nos métodos Up e Down.
Gerenciando as versões
Para gerenciar as versões e garantir que os migrations sejam executados na ordem correta, você deve utilizar o atributo Migration(long version) decorando a classe. Você deve preenche-lo com um long contendo o timestamp no formato AAMMDDhhmmss (ano/mes/dia/hora/minuto/segundo) em que seu migration foi gerado. Ou seja, um alter table da tabela projeto, por exemplo, deve conter um valor mais novo (maior) que o create table correspondente para que o migration de create seja executado antes do alter.
Configurando o build
Criar e gerenciar migrations é muito fácil. No entanto, as configurações dele são um pouquinho chatas para quem não está familizarizado com MSBuild ou NAnt. Neste artigo vamos usar o MSBuild que já é nativo e eu gosto mais simplesmente por estar familiarizado.
Junto com o código fonte compilado do Migrator.NET vem também o assembly Migrator.MSBuild.dll que é onde está a o target especifico que o MSBuild precisa para executar os migrations. Este target será usado no arquivo de build (explicado mais abaixo) e deve ser configurado como o exemplo abaixo apontando para o caminho onde esta o assembly. Arquivos Migrator.Targets:
$(MigratorTasksPath)\Migrator.MSBuild.dll
A propriedade $(MigratorTasksPath) define onde está o assembly Migrator.MSBuild.dll. O valor desta propriedade pode ser hard-coded ou então preenchida no arquivo de build conforme veremos.
Por padrão, todo projeto (arquivo.csproj no caso de C#) é um arquivo de MSBuild. É possível editá-lo para incluir as configurações necessárias ao Migrations, mas cedo ou tarde é perigoso que Visual Studio o recrie ou o modifique a seu bel prazer e ai perderiamos as customizações. Portanto, prefiro criar um outro arquivo de build exclusivo para os migrations e chama-lo quando eu bem entender. Segue abaixo o arquivo NetScrum.Migrations.build:
$(MSBuildProjectDirectory)
Este arquivo define uma série de paramêtros:
- MigratorTasksPath - Caminho utilizado para apontar onde esta o target (mencionado acima). Neste caso, é preenchido pela propriedade $(MSBuildProjectDirectory) que aponta para onde o arquivo build que está sendo chamado está localizado.
- DatabaseVersion - Será passado via paramêtro na hora da chamada do Migrator.NET. Caso não seja informado, o valor default é -1 que indica para a última versão.
- Provider = Banco de dados de destino. Neste caso estamos usando SqlServer, mas Migrator.NET funciona para outros bancos também.
- Connectionstring - Óbvio, né?
- To - Recebe o valor do parametro DatabaseVersion indicando a versão de destino do migrations.
- Migrations - Caminho onde se encontra o assembly compilado contendo as migrations.
Existem alguns outros paramêtros que permitem uma configuração um pouco diferenciada, como por exemplo, ao invés de fornecer o assembly compilado apenas informar o caminho onde estão as classes para que o próprio Migrator.NET faça a compilação.
Uma vez que tudo esteja configurado, basta ir até o command prompt, navegar até a pasta onde o arquivo.build e chamar o MSBuild passando os paramêtros conforme o exemplo abaixo:
%windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe NetScrum.Migrations.build /t:Migrate /p:DatabaseVersion=-1
Os paramêtros são:
- NetScrum.Migrations.build - Nome do arquivo de build que contém as configurações do Migrator.NET
- /t:Migrate - Target que deve ser executado. Neste caso o target de migrations
- /p:DatabaseVersion=-1 - Versão do banco para qual desejo ir. Caso queira ir para última versão é só informar -1. Caso queira zerar o banco (executar Down de todas as migrations) é só informar 0. No caso de ir para uma versão específica é só informar o timestamp desejado.
É isso! Configurar a primeira vez é um pouco chato. Acertar os caminhos dos arquivo requer algumas tentativas para quem não está familizarizado com o MSBuild, mas nada muito traumático. Nos exemplos, todos os arquivos necessários (menos o assembly contendo as migrations) estavam na mesma pasta (tools) para facilitar.
Exemplo
Quem quiser ver o exemplo funcionando, basta baixar a última versão do .NET Scrum. Ele contém as pastas e arquivos configurados direitinho pra funcionar.
Importante
A versão utilizada para este artigo foi a 0.8 que baixei tem uns 45 dias. Na época, apesar de compilada não estava funcionando então tive que efetuar umas pequenas correções do trunk. Não testei a versão 0.8 disponível hoje, portanto você pode baixar aqui a versão 0.8 compilada e corrigida por mim.
Referências
Até alguns dias atrás eu não tinha encontrado nenhum outro artigo a respeito deste assunto em português. Acredito que ainda não exista e esse seja o primeiro. Além das instruções básicas de banco que foram apresentadas no migration do exemplo ainda é possível criar PKs, FKs, executar Sql’s open text entre outros procedimentos não descritos aqui.
Vocês podem encontrar informações a respeito desses procedimentos no site do projeto ou tirar dúvidas e perguntar aqui mesmo no blog.
Enjoy!
Pai Rico, Pai Pobre
Livro meio clichê, né? Mesmo assim é muito bom!
Li esse livro de um pouco menos de 200 páginas escrito por Robert Kiyosaki e Sharon Lechter há quase dez anos atrás. No entanto, recentemente decidi le-lo novamente. Sei que nada tem a ver com o assunto do blog, mas acho super pertinente comentar a respeito do livro pelo seguinte motivo: informática não é uma profissão regulamentada no Brasil e até onde sei a maioria dos empregados das empresas ainda é contratado na forma de pessoa júridca. CLT ainda não é uma realidade para todos e eu particularmente acho uma boa, pois acredito que cuido melhor do meu dinheiro do que o governo (mas isso é assunto pra discutir numa mesa de bar, ehhee…).
Como não temos uma aposentadoria garantida pelo governo e temos salários relativamente altos em relação a outros mercados é fundamental que saibamos como cuidar de nosso dinheiro para que no futuro não tenhamos que depender de parentes, amigos ou o que é pior ainda: do governo.
Pai Rico, Pai Pobre é um livro bem antigo que apresenta em uma linguagem muito simples como aumentar sua inteligência financeira para começar a caminhada a fim de atingir independência financeira. Através da história de um garoto que cresceu tendo dois pais, um rico e um pobre, é possível aprender o que é um investimento, diferenciar um ativo de um passivo e diversos outros termos que rodeiam o mundo financeiro.
Além desse aprendizado, ele nos desafia a pensar se realmente trabalhar com afinco do começo ao fim da vida é a melhor opção. Existe outra? Claro que sim! Podemos colocar nosso dinheiro para trabalhar para nós. Mesmo que iniciemos com pouco dinheiro, é possível montar uma riqueza inimaginável. Afinal, os grandes donos de empresas e milionários que vemos por ai não nasceram ricos (pelo menos não a maioria) e começaram com pouco.
Além deste livro, o mesmo autor escreveu uma série de outros livros de mesmo assunto para apoia-lo nessa caminhada. Além dos assuntos técnicos que estudo, também estou estudando mercado financeiro, investimentos, etc, mas não pretendo ficar discutindo sobre isso aqui no blog (o objetivo do blog não é esse). Então se alguem quiser bater papo a respeito pode me contatar diretamente, ok?
Enfim, a idéia do post é mais dar uma dica no sentido de que devemos aproveitar enquanto somos novos para começar a montar um patrimônio que nos permita viver bem e desfrutar a aposentadoria.
Hoje tenho 22 anos, estou começando essa caminhada agora e quero me aposentar antes dos 40 para curtir um pouco da vida. E você? Quer trabalhar a vida inteira e ainda assim depender de terceiros no final da vida? Eu não quero!
