Pessoal,
Estava com problemas com o BlogEngine.NET e voltei pro WordPress. Por favor, atualizem seus feeds.
mauricioaniche
Sep 222009
Participei nesse último sábado (27/06) no .NET Architects Day, evento organizado pelo grupo de arquitetura focado em .NET, o .NET Architects, liderado pelo Giovanni Bassi. O evento foi muito além do que eu esperava! A organização foi perfeita, a localização era perto do metrô, o auditório era muito bom, e o coffee break estava delicioso! 
E o conteúdo? Devo dizer também que todas as palestras foram muito boas! O nível foi altíssimo e a plateia fez perguntas muito inteligentes em todas elas. Parabéns ao Giovanni Bassi, Juliano Oliveira, Vitor Cavalcante e Leandro Daniel pelas palestras.
A minha palestra sobre testes automatizados também foi legal, acho que consegui cumprir meu objetivo que era a de motivar todos a testar, e como diria Bryan Lyles, “test all the fucking time”! Obtive um feedback muito bom dos participantes, e fico feliz com isso, já que dessa maneira posso melhorar ainda mais a palestra para as próximas oportunidades.
Sobre os vídeos, eles serão publicados em breve. Os slides você pode ver no slideshare aqui.
Enfim, obrigado a todos os organizadores e a todos que foram ao evento. Ano que vem vai ser melhor ainda! Que venha o DNAD 2010!
Jun 072009
A comunidade .NET Architects está organizando um evento de arquitetura de software em .NET, no dia 27/06 na Unip Tatuapé.
As palestras estão muito boas, serão abordados DDD (Domain-Driven Design), Injeção de Dependência, ASP.NET MVC, ORMs (com NHibernate) e Testes Automatizados. Eu serei palestrante e falarei sobre testes automatizados!
O evento custa apenas R$ 50,00! Corra, as inscrições estão acabando!
Mais informações em http://www.dotnetarchitects.net/dnad2009
Apr 282009
Esse fim de semana estive em Porto Alegre para assistir ao Agile Weekend 2009, que aconteceu nas dependências da PUC-RS. A faculdade lá é muito bonita, o prédio do FACIN (Faculdade de Informática) é moderno. O auditório e as salas disponibilizadas para as palestras são confortáveis.
A palestra inaugural foi dada pelo Daniel Wildt e pelo Luiz Parzianello, e o tema foi “Os desafios da cultura Lean no desenvolvimento de software”, e como o próprio título diz, eles nos contaram muito da experiência deles com Lean. A palestra foi muito interessante!
A partir daí, começou a parte difícil: escolher uma das três palestras simultâneas. Todas elas pareciam excelentes. Optei por assistir a “Java Meets Agile” do Giovani Salvador (Dell/RS) e do Guilherme Elias (FUJA). Um detalhe interessante é que a palestra “Introdução ao Scrum” do Samuel Crescêncio (OnCast/SC) lotou, tiveram que fechar a porta da sala porque não cabia mais ninguém! Voltando a palestra do Giovani, ela foi muito interessante, a primeira parte da apresentação sobre conceitos de métodos ágeis, ele pulou, não era necessário repetir tudo de novo para quem estava ali. Em seguida, falou um pouco da perspectiva do arquiteto de software, onde, segundo ele, os arquitetos não devem utilizar arquiteturas genéricas demais quando não necessário, devem “sujar as mãos” e provar a arquitetura, e não devem fazer do projeto do cliente um verdadeiro laboratório de tecnologias! Da perspectiva do desenvolvedor, ele disse que o desenvolvedor deve sempre desenvolver as atividades de maior prioridade antes (e com isso, os problemas aparecerão antes), escrever testes automatizados junto com alguma ferramenta de cobertura de código e constante refatoração. Sugeriu também alguma técnica de pair programming ou peer review. Os slides dessa apresentação podem ser encontradas aqui.
Após a palestra. fomos almoçar em um restaurante dentro da própria PUC-RS. Barato e bom, aprovado!
Na volta, optei por ver a palestra “Anti-Práticas e Anti-Valores Ágeis” do José Peleteiro (Globo.com). A palestra foi bacana também pra ver que todos podemos errar utilizando métodos ágeis, e inclusive grandes empresas como o Globo.com! Houveram muitas perguntas dos participantes, tornando a palestra ainda mais dinâmica. Detalhe aos slides, que foram muito bem trabalhados. Ao final, o ótimo apelo do “salvem os bebês-foca” rendeu palmas dos participantes! 
No último horário do dia, optei por ver o workshop de “Simulação de um Projeto Scrum com uma Mini-Fábrica de Aviões”, feita pelo Flávio Steffens (W3Haus/RS) e pelo professor da PUC, Rafael Prikladnicki. A idéia deles foi bem interessante, onde todos nó, em equipes de cinco pessoas, tínhamos que fazer aviões. Mostrou também como nós fazemos coisas sem perguntar primeiro ao cliente, e depois “ficamos bravos” por isso! Mostrou também como nossas estimativas tendem a melhorar depois de alguns sprints.
No segundo dia, a palestra de abertura “A agilidade está no ar – um case na força aérea brasileira” foi dada pelo Alexandre Gomes, Bruno Pedroso e Renato Willi, todos da SEA Tecnologia. A palestra apresentou o case de um aplicativo GED que eles desenvolveram para a aeronáutica brasileira. Muito interessante que eles aplicaram Scrum aos poucos no projeto, mostraram os erros e depois como fizeram para corrigir os mesmos. Mais um exemplo que métodos ágeis só se aprende na prática. Na minha opinião, essa foi a melhor palestra de todo o evento. Os slides estavam muito bem feitos, todos eles com fotos relacionados a aeronáutica!
Em seguida, fui assistir a palestra “Scrum com Soluções simples e de baixo custo”, dada pelo Luiz Faias Jr. (Bluesoft/SP). Muito motivadora também, eles mostraram como eles aplicam Scrum. Detalhe para a tinta magnética junto com os imãs que eles usam para “colar” as histórias na parede, ao invés de usar o tradicional quadro branco. A única partequa não foi tão baixo custo assim, foi quando ele disse que uma tela de plasma avisa quando o build falhou! O problema é que telas de plasma ainda não são de baixo custo!
Fui direto para a palestra do Gustavo Casarotto (Metadados/RS) sobre “Métodos Ágeis x Gestão do Negócio”, onde ele abordou como gerenciar uma empresa que utiliza métodos ágeis. Falou dos principais problemas que temos com isso, e como tentar evitá-los.
Acho que a única parte mal organizada do Agile Weekend ocorreu no almoço de domingo, pois todos os restaurantes da faculdade estavam fechados e tivemos que comer na lanchonete do próprio prédio. Essa, por sinal não suportou 400 pessoas pedindo ao mesmo tempo, e eu levei quase 1h pra conseguir meu X-Frango!
Fui correndo então para a sessão livre sobre “Métodos Ágeis no Ensino Superior”, liderada pelo Daniel Wildt (professor da FACENSA) e pelo Rafael Prikladnicki. Tinham poucas pessoas na sala (por volta de umas 6, 7), e a discussão girou muito em torno de como ensinar e embutir métodos ágeis nas atuais disciplinas dos cursos de computação. Alguns tópicos foram levantados, anotados e farão parte das próximas reuniões.
A última sessão livre “Eu Odeio Métodos Ágeis!”, dada pelo Daniel Wildt também foi legal. Ele discutiu muito sobre pessoas que não aceitam métodos ágeis, sem nem ao menos terem lido ou experimentado. E que após algum uso, acabam mudando de idéia e gostando da metodologia. Pena que ele estava sem conectividade na sala, pois iria mostrar posts e artigos relacionados.
Esse foi o Agile Weekend 2009. Considero uma experiência super positiva, pude ouvir várias experiências pessoais sobre implantação métodos ágeis, cada um com seu problema e solução específicos. Foi muito legal também estar perto de entusiastas de métodos ágeis e ver que o Rio Grande do Sul está realmente interessado no assunto também!
A maioria dos slides ainda não foram disponibilizados, mas irei colocando os links assim que receber.
Pedi também ao Paulo Henrique Martins, amigo que me acompanhou no evento, para dar a opinião dele também. E aí vai:
<Paulo Henrique Martins>
Fui com o Mauricio no evento e posso dizer que ele foi bastante interessante, especialmente para mim, que não tenho um conhecimento muito aprofundado sobre o tema.
Sobre as palestras que o Mauricio não conseguiu assistir:
Enquanto ele assistia a palestra do Jose Peleteiro, da Globo.com, eu assisti uma verdadeira aula, muito interessante, do Luiz Parzianello e do Rafael Prikladnicki – “Jogos Estatísticos para a Promoção de Práticas Ágeis”. Assim como a palestra seguinte, de “simulação de scrum em uma mini-fábrica de aviões”, foi muito interativa e divertida, mostrando na prática situações que os métodos ágeis realmente funcionam. Um dos jogos usados inclusive gerou uma interessante discussão confrontando a necessidade de um time contra a ambição pessoal, tocando no assunto de que as equipes precisam se comportar cada vez mais como times onde todos se dispõem a fazer qualquer tarefa, não especificando radicalmente a função de cada um. Assim, um analista deve ter o bom senso de, quando necessário, “se rebaixar” e programar, fazer testes, colocar a mão em todo o sistema visando o bem geral do grupo.
Outra palestra que eu vi foi o case de “Desenvolvimento Ágil num projeto Global”, de Giovani Salvador, da Dell Computer, enquanto o Mauricio assisita a palestra da Bluesoft. Foi também uma interessante demonstração de métodos ágeis, desta vez em um gigantesco projeto que envolvia 3 equipes de tamanho médio em 3 cidades diferentes. Giovani provou com essa palestra que é possível usar métodos ágeis em projetos de longa distância, mantendo a equipe sempre em comunicação por conferências e revezando o papel de Scrum master entre as equipes a cada sprint.
Por fim, ao invés de assistir a palestra “Métodos Ágeis no Ensino Superior”, acompanhei “Agilizando seu Projeto de Software”, do Bruno Pedroso, da SEA Tecnologia. Ele passou algumas dicas para iniciar a implementação de métodos ágeis nos projetos. Foi interessante e o pessoal da SEA Tecnologia comprovou que realmente sabe dar palestras interessantes e divertidas – a primeira palestra (“A agilidade está no ar – um case na força aérea brasileira”) foi muito bem apresentada, com uma divertida seqüência de slides.
Como desenvolvedor, já estou começando a tentar introduzir algumas técnicas aprendidas aqui na empresa. Foi um evento onde eu realmente aprendi bastante. Parabéns à organização, e, devo dizer que a PUC-RS é uma faculdade muito bonita e moderna.
</Paulo Henrique Martins>
E que venha o Agile Weekend 2010! (ou será Agile Week 2010?)
Apr 232009
Amanhã estarei embarcando para Porto Alegre, aonde vou assistir ao Agile Weekend, na PUC-RS. Serão 2 dias de métodos ágeis, e imagino que as palestras serão muito boas e proveitosas!
Assim que voltar, postarei sobre a conferência!:)
Nessa terça-feira fizemos a nossa primeira retrospectiva com o time do Dojo Online (projeto open-source que estamos desenvolvendo na Universidade de São Paulo). Após esse primeiro mês de interação, resolvemos nos reunir para refletir sobre o andamento do projeto. A reunião aconteceu em uma sala com post-its coloridos e canetas.
Na primeira parte da retrospectiva, a idéia era colocarmos nossas respostas em post-its para três perguntas:
- O que foi bom? O que fizemos bem?
- O que podemos melhorar?
- O que atrapalhou? O que foi ruim? O que não queremos mais?
Havíamos combinado antes que não haveria nenhum tipo de ataque pessoal (nada de respostas do tipo ‘fulano não faz nada’), e que ninguém precisaria identificar-se como autor da resposta. Gastamos então aproximadamente 15 a 20 minutos preenchendo nossos post-its e colando-os na lousa.
A segunda parte e mais interessante da retrospectiva foi a discussão dos problemas. Começamos primeiro pela terceira pergunta: O que nos atrapalhou? A maioria das respostas se encaixou em problemas com o ambiente (falta de café, máquinas lentas, falta de plugins no Eclipse), problemas com testes de interface (realmente não conseguimos até agora executar um teste automatizado de interface no GWT), falta de experiência do time com métodos ágeis (realmente, esse é o primeiro contato da maioria com XP). A única coisa um pouco mais pessoal que rolou foi um ‘pessoas atrasadas nas reuniões gera a necessidade de rediscutir os assuntos’. Eu anotei que senti ‘pouca comunicação com os clientes durante a interação’. Alguns outros problemas como ‘retrabalho por falta de comunicação’ também foram levantados.
Já na segunda pergunta, levantamos que deveríamos ‘melhorar nossas estimativas das histórias’ (estimamos muito mal essas histórias, algumas muito longe do que foi a realidade), ‘mais estudos fora do horário’, ‘comunicação da equipe’, ‘participação maior do time na lista de discussão’, ‘procurar atender melhor as necessidades do cliente’, ‘tarefas acopladas’ e uma muito interessante: ‘validação de histórias concluídas’ (tivemos muitas histórias marcadas como concluídas, mas na verdade, elas precisavam de mais alguns ajustes). Vimos também que deveríamos melhorar no desenho do fluxo de telas do projeto, pois não tínhamos nenhum rascunho e isso estava criando muitas dificuldades para o time (muitos post-its sobre isso!). Houveram sugestões também para refatoração de código, pois alguns membros estavam achando o código muito complicado.
Já para a primeira pergunta (parece ser a mais fácil de responder, mas não é!), a maioria das respostas foram sobre a união e humor da equipe. Algum dos integrantes, provavelmente membro de algum grupo esotérico, escreveu ‘energia do pessoal’ ! Realmente, o time está muito integrado, se ajudando o tempo todo na resolução dos diversos problemas que surgiram durante a interação. Muitos gostaram também de programar pareado, já que a produtividade e qualidade do código cresce muito! Outro detalhe interessante é que houveram muitas respostas do tipo ‘tracking realmente ajuda a ver o andamento do projeto’. Durante toda a interação, tratamos de manter todos os indicadores atualizados, e com isso, tínhamos a visão exata do estado do projeto naquele momento.
Após uma rápida leitura de todos os post-its, resolvemos agrupá-los por categorias, para então acharmos soluções para nossos problemas:
- Sobre os testes de interface, decidimos que não iríamos fazer testes de interface por enquanto, e que nos concentraríamos nos testes da camada de domínio. Para os diversos problemas levantados, foi sugerida a criação de um quadro de dúvidas, e que ao final do dia, iríamos resolvê-las todas com o cliente. Decidimos também que nossas reuniões diárias serão feitas em horários pré-determinados (antes não tínhamos horário fixo!), e que todos devem participar mais das questões levantadas na lista de discussão via e-mail. Sugerimos também o “sino da atenção”, para que quando algum membro do time precisar se comunicar com todos, este deve conseguir chamar a atenção de todos de uma só vez, para não ter que ficar repetindo a mesma informação.
- Combinamos também que tentaríamos refatorar os códigos que estavam por demais complicados. Sobre os problemas de falta de atenção com a interface, decidimos também trabalhar em um rascunho de fluxo das telas, para que todos tenham pelo menos uma visão básica das telas do projeto. Esses mesmos rascunhos serão validados com o cliente antes de serem implementados efetivamente. Sobre as estimativas, acreditamos que nessa segunda interação elas serão melhores. Sobre o problemadas tarefas acopladas, decidimos que vamos trabalhar mais juntos no momento de quebras as histórias em tarefas.
- A parte boa, não há muito o que comentar! Vamos tentar continuar assim, por enquanto não houveram feridos no time!
Fazendo uma análise geral da retrospectiva, vimos que nosso grande problema foi a COMUNICAÇÃO, pois olhando para as ações que definimos, a maioria delas tenta resolver problemas relacionados a comunicação! Ficamos surpresos ao perceber isso! Como já dizia o manifesto ágil, “Individuals and interactions over processes and tools”. E realmente, eles estavam certos!
Criamos um quadro na nossa sala, com as principais ações definidas na retrospectiva, e agora vamos atrás delas!
Tiramos algumas fotos da retrospectiva, que você pode ver aqui, aqui, aqui e aqui.
Curioso com os indicadores? Veja eles aqui, aqui, aqui, aqui, aqui, aqui e aqui.
Programação é um mundo fantástico… E mais fantástico ainda é a velocidade com que as novidades surgem e desaparecem… A pergunta é: até que ponto devemos nos atualizar a cada nova tecnologia que surge?
Se pensarmos em plataforma .NET, é impossível lembrar de cabeça todas as novidades apresentadas pela Microsoft nesses últimos tempos: WCF, WPF, Silverlight, Entity Framework, LINQ, ASP.NET MVC, etc, etc… É simplesmente impossível manter-se atualizado (com um bom nível de conhecimento, obviamente) em todas elas!
Pergunto novamente: Mas precisamos mesmo nos atualizar? Não, não precisamos. O principal objetivo de um desenvolvedor de software é entregar software para o cliente. Se hoje você desenvolve bons softwares, que agregam valor para seus clientes, e não faz uso das últimas novidades, não se culpe, você não está errado! Você não precisa re-programar todo seu sistema só porque dizem que o novo framework XPTO é bom! Programamos não para satisfazer nossos egos (afinal, quem não gosta de estar sempre atualizados, utilizando das melhores e mais modernas práticas?), mas sim para atender a necessidade do cliente. Se você já atende o seu cliente, não tem porquê mudar!
É a velha história do projeto perfeito e do projeto bom, onde todo projeto perfeito quer ser um projeto bom! O projeto perfeito nunca fica pronto, pois não dá tempo, seus desenvolvedores sempre querem o manter atualizado com as últimas novidades! Já o projeto bom, como o próprio nome diz, não é perfeito, não utiliza das últimas tecnologias de mercado, mas funciona, e o melhor, atende ao cliente!
Não estou dizendo que você não deva se atualizar. Claro que deve! Mas tudo isso deve ser feito de maneira cautelosa, estudada, e o mais importante: seu cliente não deve pagar por isso! Se algum framework promete ajudar no desenvolvimento e poupar futuras horas de desenvolvimento, faça testes, brinque, use e abuse dele, até ter certeza de que ele vai realmente lhe agregar valor, e que ele não vai ser um gargalo na hora do desenvolvimento.
Uma coisa que tem me chamado a atenção é o foco que as pessoas tem dado ao novo ASP.NET MVC, da Microsoft. As pessoas tem pulado de cabeça nessa novidade, sem nem pensar no impacto que isso vai ter sobre a equipe de desenvolvedores e sobre a qualidade do software que será desenvolvido. Será que os WebForms são tão ruins assim que merecem serem trocados de forma praticamente instantânea? Caso você ache que vale a pena trocar toda a experiência que sua equipe e investir horas de estudo nesse novo framework, pois o MVC vai lhe ajudar a escrever melhores softwares, siga em frente; caso contrário, não se sinta mal, continue usando WebForms e atendendo seu cliente da melhor maneira possível!
Não se esqueça da frase (da qual não me recordo o autor): Bons desenvolvedores DESENVOLVEM software. Ótimos desenvolvedores ENTREGAM software.
(Uma discussão do grupo .NET Architects me levou a escrever esse post)
Segundo o livro Use a Cabeça: Desenvolvimento de Softwares, a definição de PRE é: Cada objeto de seu sistema deve ter uma responsabilidade exclusiva e todos os serviços do objeto devem estar orientados à execução dessa responsabilidade. Em outras palavras, uma classe deve ser responsável por uma determinada função, e só ela pode exercê-la.
Uma classe Carro, por exemplo, deve ser unica e exclusivamente responsável por realizar funções de um carro (como medir óleo, acender farol, etc). A classe Carro não deve ser responsável por saber se lavar (essa é uma responsabilidade que poderia ser entregue a uma classe LavaRapido, por exemplo).
Conversando hoje com o Murilo Amêndola, discutimos sobre como saber quais as responsabilidades de uma classe. Concordamos que não é uma tarefa trivial e que depende de muita experiência para que todas suas classes tenham um alto nível de coesão. Lendo hoje um trecho do livro citado acima, encontrei um algoritmo muito interessante para saber se determinada responsabilidade deve ou não pertencer a determinada classe. Vou reproduzí-lo aqui:
- Escreva, em uma folha de papel, várias linhascomo essa: O [espaço] [espaço] sozinho. Escreva 1 linha dessa para cada método da classe que você está testando quanto ao PRE.
- No primeiro espaço em branco de cada linha, preencha o nome da classe. No segundo espaço em branco, anote um dos métodos da classe. Faça isso para todos os métodos.
- Leia cada linha em voz alta. Você pode até adicionar uma letra ou palavra para que a leitura fique adequada. Se a frase que você disse fez algum sentido, então esse método realmente pertence a essa classe. Se não fizer nenhum sentido, então provavalmente esse método não pertence a essa classe.
Voltando ao exemplo da classe Carro:
- O carro se liga sozinho. (CERTO)
- O carro se desliga sozinho. (CERTO)
- O carro trocaPneus sozinho. (ERRADO)
- O carro dirige sozinho. (ERRADO)
- O carro se lava sozinho. (ERRADO)
- O carro medeOleo sozinho. (CERTO)
Repare que faz todo sentido o carro medir óleo sozinho, enquanto não faz sentido nenhum o carro se dirigir sozinho (esse método deveria estar em uma classe Motorista), ou se lavar sozinho (deveria ser responsabilidade da classe LavaRapido)!
O método liga e desliga não fazem taaanto sentido (afinal, um carro não se liga sozinho), mas nesse caso, não vejo outra alternativa (é o carro que sabe como se ligar!). Isso mostra que a regra acima é apenas uma diretriz, e por isso você deve usar de bom senso e de sua experiência.
O interessante é que você pode adaptar essa regra até para métodos que recebem parâmetros. Se você tiver um método troca(peça), você escreve a seguinte sentença: O carro troca [uma] peça sozinho. No caso, também não faz muito sentido, você poderia ter uma classe Mecânico, com o método troca(peça, carro).
Enfim, é uma análise interesse, não acham?
(Exemplo retirado do livro Use a Cabeça: Desenvolvimento de Softwares, capítulo 5.)
Meu artigo sobre persistência de dados com Ibatis.NET foi publicado na revista Mundo .NET desse mês de dezembro! Espero ter ajudado, explicando como usar esse framework, tão pouco conhecido, mas funciona muito bem, e é MUITO útil!
Tenho diversos projetos em produção, utilizando tanto a versão pra Java quanto a versão pra .NET, e ambos funcionam perfeitamente! Sobre performance, posso afirmar também que dois desses projetos recebem milhares de visitas por dia e o Ibatis está dando conta muito bem. Não sei se posso divulgar em quais projetos utilizei, mas vou perguntar e posto aqui!
Sobre o projeto de exemplo que está na revista, recebi alguns e-mails perguntando a URL de download do mesmo, e ele se encontra em http://www.aniche.com.br/mundotnet/ibatis.zip. Caso encontre algum problema no exemplo, por favor, me comunique!
Estou à disposição para quaisquer outras dúvidas sobre o framework. Basta apenas postar um comentário nesse post, ok?
Espero que gostem!
(PS: Desculpem por demorar a postar um tópico para o artigo!)
Dec 192008
Dia 5 de dezembro era pra ser um dia comum. Cheguei no trabalho, e como sempre faço, abri minha caixa de e-mail: nada muito interessante. Fui então avisado que iria trabalhar o resto do dia na unidade de Tamboré. Peguei meu notebook, chamei um táxi. Ao chegar em Tamboré e plugar meu notebook na energia e rede, meu GTalk automaticamente ficou online e subiu um aviso de e-mail com o seguinte título: “Mestrado em Ciência da Computação – IME – USP”. Abri o e-mail, tenso. Procurei aleatoriamente pelas palavras “não foi aceito”, “pedido indeferido”, “sinto muito mas não deu”, mas nada.
Decidi então ler o e-mail: “Temos o prazer de informar que o seu pedido de admissão no Programa de
Mestrado em Ciência da Computação no IME – USP foi aceito para o 1
semestre de 2009…“. Meu coração disparou. Finalmente! Depois de tanta tensão, provas, cartas de recomendação (obrigado professores Luciano Silva, Ismar Frango e João Neto!), visitas aos professores do IME … Finalmente!
Na mesma hora mandei um e-mail para meu orientador inicial, que foi indicado através da linha de pesquisa que escolhi (Engenharia de Software), o Prof. Dr. Marco Aurélio Gerosa. Dois dias depois fui até a USP conhecer suas linhas de pesquisa, seus projetos, etc. Gostei muito dos projetos, e tenho certeza que eu e o Prof. Gerosa iremos desenvolver um ótimo trabalho de mestrado!
Só quem viveu ao meu lado sabe o quão tenso foram esses últimos meses. Por isso, estou aqui para agradecer a minha familia, minha namorada, e a todos que me apoiaram (leia-se me aguentaram)!
E que venha o mestrado!
Siga-me no twitter! 