Entrevista com Fabio Akita, co-fundador e CTO da Codeminer 42, co-organizador da Rubyconf Brasil e realizador de quase 200 palestras pelo Brasil e pelo mundo.
Essa entrevista faz parte de uma série de entrevistas com alguns dos principais nomes da TI no Brasil.
Bugginho: Segundo seu currículo disponível em http://setup.loopinfinito.com.br/fabio-akita/, você é desenvolvedor de software desde os anos 90 e passou por todas as principais tecnologias do mercado nesse período. Conte um pouco sobre sua trajetória na TI e como conheceu o Ruby.
Fabio: Eu sempre gostei de computadores por causa de videogames. Desde Ataris, Intellivisions, MSX no meio dos anos 80. Fiz um curso de Basic quando tinha lá pelos 12 anos. E foi graças a um tio meu que era analista de sistemas que ganhei um computador PC-XT no fim dos anos 80. Não tinha internet naquela época e eu estava restrito ao que tinha no computador, um MS-DOS 3. A primeira coisa que eu fiz foi digitar um trabalho de escola usando Basic (porque não tinha editor de texto além do EDLIN e não tinha onde baixar nada). Por causa desse meu tio, li apostilas e livros de dBase III e tive a oportunidade de fazer um estágio de férias com ele ajudando em projetinhos reais. Eu devia ter alguma coisa como 14 anos nessa época. Passei alguns anos evoluindo de dBase para Clipper para FoxPro.
Por causa disso resolvi que queria estudar Ciências da Computação. Nunca tive 2a opção. Prestei USP, Unicamp e Fatec/SP as 3 únicas que me interessavam. Passei nas 3, escolhi ficar no IME da USP. Depois de alguns anos fazendo código “semi-profissionalmente”, foi só depois que entrei na faculdade que eu entendi que realmente não entendia programação da forma correta. E essa foi uma lição muito importante: eu sabia “fazer código” mas eu não “compreendia” esse código. Um mundo muito maior se abriu diante dos meus olhos. Foi um grande choque e uma grande revelação que me deixou realmente mais motivado a investigar a fundo. Aprendi Turbo Pascal, C e foi em 1995, no meu primeiro ano de faculdade, que linguagens como Java, Javascript, Delphi surgiram, versões 1.0. E eu queria aprender todas, e foi o que eu fiz.
A partir de 1997 a Internet estava crescendo de forma muito rápida. Surgiu gif animado (naquela época levámos isso a sério), Macromedia Flash, as agências de publicidade não tinham muita idéia do que fazer e pequenas produtoras estavam testando de tudo. Animações, formas diferentes de interação, multimídia. E eu sabia que estava no meio de alguma coisa diferente. Acabei começando a trabalhar cedo e peguei o início da “Bolha da Internet”.
Comecei numa pequena produtora multimedia onde tive a oportunidade de trabalhar lado a lado com designers e pela primeira vez o outro lado do meu cérebro teve a oportunidade de se exercitar um pouco. Fiz muitos CD-ROMs multimídia em Macromedia Director, o precursor do Flash. Foi onde aprendi a usar Illustrator, Photoshop, entendi um pouco sobre tipografia. As poucas noções de arte e estética viriam a ser importantes depois.
Então fui trabalhar num provedor de internet, a STI. E lá aprendi ASP, SQL Server e desenvolvi um pequeno ERP. Ela se tornou outra empresa no frenesi da Bolha, comprada por uma empresa internacional e se tornando PSINet. Depois uma spin-off surgiu chamada ProtocoloWeb. Ajudei a criar 2 produtos: o iEG (internet Email gratuito) e o hPG (home Page gratuita). Aprendi PHP, Perl e os básicos de Linux e Apache. Acabei saindo da startup (na época chamávamos só de “pontocom” ) antes dela se tornar o sucesso que foi. Não temos como prever o futuro.
Entrei em outra pontocom, desta vez de jornalismo e esportes, o grupo PSN que tinha canais de TV a cabo e sites latino americanos além de serem patrocinadores de diversas equipes de esporte. A empresa dona da PSN também era dona de diversos times pela América Latina, era a Hicks Muse Tate & Furst (HMTF, hoje chamada de HM Capital Partners). Quem gosta de futebol vai lembrar que eles eram donos de times como Corinthians, Cruzeiro, patrocinadores do Alan Prost e a PSN tinha programa de TV até do Pelé (a única vez que tive a oportunidade de vê-lo pessoalmente). Eu era o “webmaster” desses sites e trabalhei no mesmo escritório que diversos jornalistas de esportes incluindo colunistas como Sócrates e Marcelo Fromer. Foram épocas bem loucas.
A Bolha explodiu em 2001 e eu saí do mundo de pontocoms.
O mundo corporativo estava procurando maneiras de integrar seus negócios jurássicos de grandes sistemas de back-offices e ERPs com as tecnologias das pontocoms, essa “tal de Web”. Então eu acabei ingressando no mundo SAP, aprendi linguagens arcaicas como ABAP, fui obrigado a lidar com sistemas escritos em PL/SQL. Ao mesmo tempo usei Java e .NET para integrar sistemas Web com esses sistemas arcaicos. Ser um “integrador” era uma função mosca-branca na época porque quem sabia Web não tinha idéia de como falar corretamente com sistemas SAP e quem era consultor SAP não tinha idéia de como usar a Web.
Finalmente, em 2005 o trauma das pontocoms ficou para trás e surgiu a primeira geração do que conhecemos como startups modernas, a era social, a era do Web 2.0. Gmail deixou o mundo admirado com a idéia de “Ajax”. MySpace e Orkut deixou o mundo intrigado com a idéia de redes sociais. Facebook ainda não era grande coisa. YouTube e Twitter só surgiriam em mais 1 ou 2 anos. E nesse período a Web estava dividida entre um mundo mais amador de Wordpress e o mesmo PHP que fazíamos nos anos 90 e o mundo corporativo dos frameworks Java ou .NET. O mundo Agile estava sofrendo para ser levado a sério. E foi nesse meio que surgiu esse tal de “Rails” usando essa linguagem estranha chamada “Ruby”.
Bugginho: Nos anos 90 não tínhamos diversas das ferramentas e facilidades que temos hoje, porém também não tínhamos tantas obrigações como temos hoje. O desenvolvimento de software está em constante evolução porque as necessidades das pessoas e empresas estão igualmente em constante evolução. Como você vê essa evolução? Em sua opinião era mais fácil desenvolver softwares antigamente ou as dificuldades são as mesmas?
Fabio: As tecnologias evoluem, é uma constante. Todo ano temos um brinquedo novo.
Mas não é verdade que não tínhamos diversas ferramentas. Elas existiam, só não eram tão “acessíveis” porque não havia um canal de distribuição eficiente com a Internet hoje.
Eu aprendi a programar numa era sem web, sem blogs, sem e-Books. Mas haviam bibliotecas. Haviam faculdades. Havia pegar uma caixa de sapatos, encher de disquetes, pegar ônibus e ir na casa de amigos copiar programas. Havia pegar livros emprestados e ir na xerocaria da faculdade fazer cópias. Havia economizar e comprar bons livros importados. Todos os fundamentos da programação que se aprende hoje, são os mesmos de quando eu aprendi. São os mesmos faz décadas.
Infelizmente eu nunca tive acesso a mainframes quando era adolescente, então acabei não aprendendo e nem usando coisas como COBOL, aprendi um pouco de REXX que era usado em mini-computadores. Também temos até hoje pouco acesso a sistemas embarcados, hardware especializado de equipamento médico, por exemplo. Quem trabalhou em hospitais também usou (ou ainda usa) tecnologias como MUMPS.
E a forma de desenvolver software continua “aproximadamente” o mesmo. A grande maioria das pessoas acha que é “fácil” programar. O fato da tecnologia ter se tornado “acessível” dá a falsa impressão de que não é difícil.
O resultado? Todo mundo está cometendo os mesmos erros que programadores dos anos 50 faziam.
Um livro que tive a sorte de ler na minha época de faculdade mudou minha visão, o famoso “The Mythical Man-Month” onde Fred Brooks conta como foi o desenvolvimento do sistema operacional OS 360 para mainframe nos anos 60. Todos os problemas que ele identificou e classificou se encontram em praticamente todos os projetos modernos de software feito por gente que acha que programar é ler meia dúzia de posts de blogs. Na expansão da próxima edição desse livro foi onde Brooks cunhou o termo “Não existe bala de prata”.
Os computadores de hoje são os mesmos se comparados à época de Alan Turing na 2a Guerra Mundial. Só são bilhões de vezes mais rápidos, mas a forma de programar é exatamente o mesmo. A arquitetura de computadores ainda é Von Neumann (anos 40). As linguagens de computador ainda são ditas Turing complete (anos 40).
A tal “inovação” das linguagens ditas “funcionais”? Pelo amor, isso é velho, é Lamba Calculus de Alonzo Church, anos 30! Nada de funcional hoje foi inventado hoje, veio sendo inventado e evoluído nos últimos 80 anos!
A realização chocante para a maioria das pessoas: a percepção é que estamos tão evoluídos que se uma pessoa dos anos 40 nos viesse hoje acharia que é ficção científica. Mas eu diria que se Turing, Church, Von Neumann, McCarthy e outros grandes matemáticos dos anos 40 ou 50 nos visse hoje, não ficariam tão impressionados assim, especialmente se notarem que nós - esse povo do século XXI - ainda está cometendo os mesmos erros de mais de 60 anos atrás.
É vergonhoso escrever software e achar que se é tão bom, que não é necessário estudar o que foi aprendido e devidamente documentado no passado.
Bugginho: O Ruby ficou muito popular graças ao Rails, mas é óbvio que a linguagem não se resume a isso. Onde o Ruby é mais utilizado hoje em dia e quais projetos você considera grandes cases da linguagem?
Fabio: O grande sucesso do Rails foi um desses “acasos” que não acontecem sempre: a realização que você está no lugar certo, na hora certa. A 37signals, e o DHH, tiveram a sorte de entender isso e criar com propósito.
O criador do Rails, David Heinemeir Hansson, era sócio dessa minúscula agência em Chicago chamada 37signals e eles estavam tendo um sucesso relativo com seu produto chamado Basecamp. Eles tiveram uma grande sorte de estarem no centro do renascimento da Web 2.0 coincidir com a renascença da Apple, o sucesso do iPod e dos novos Mac. Todos estavam interessados nessa idéia exótica combinar “estética”, “lifestyle" e “tecnologia”. Foi a era “New Age” na tecnologia, onde em vez de tecnologia ser sinônimo somente de nerds solitários isolados em suas bagunçadas e sujas mesas no meio da noite, agora as pessoas de “estilo” e “estética” estavam lançando produtos que não eram apenas “funcionais”, eram “bonitos”, eram “usáveis por pessoas comuns”, e aí nasce de fato a era do UX, a era do Agile (que é a “UX” dos processos), a valorização do “espaço branco” e da escola de Bauhaus, onde todos queriam lançar o equivalente ao iPod da Web.
E o Rails foi o único que oferecia esse pacote: a tecnologia, a estética e o estilo de vida.
Tendo passado por todos esses eventos desde o fim dos anos 80, foi irresistível não embarcar nessa nova era também. E foi assim que a partir de 2006 eu entrei de cabeça no mundo Rails.
Rails foi feito para criar produtos similares ao Basecamp. Produtos Web 2.0. Qualquer produto Web com a arquitetura do Basecamp é adequado para ser feito de forma elegante com Rails. Este site tem uma boa lista de exemplos:
https://skillcrush.com/2015/02/02/37-rails-sites/
De AirBnb, a GitHub, a Twitch, tudo pode ser feito com Rails.
Porém os tempos mudaram recentemente e uma coisa que passou a se tornar mais comum é notificação em tempo real e isso exige uma arquitetura um pouco diferente, normalmente baseada em Pub-Sub e WebSocket, onde o Rails é fraco. Mas o resto da app é Rails-like, então a solução ideal é mesclar tecnologias. Da mesma forma que mesclamos Rails com Elasticsearch se precisamos de pesquisa com relevância e auto-complete. Mesclamos Rails com Node ou Go ou Elixir e voilá.
O mais importante não é “usar” o Rails é “ser On Rails”. Como disse antes, o sucesso do Rails não é somente a tecnologia, é a mescla da tecnologia adequada com a estética da programação e isso você só obtém com o ambiente de trabalho e processos adequados. Ser “on Rails” exige um ambiente de projetos Ágeis para gerar código elegante, testado, de fácil manutenção.
Bugginho: Há alguns anos houve um “Boom” do Ruby on Rails, só se falava em RoR, grandes empresas como a Locaweb investiam muitos em eventos voltados ao RoR, existiam vários cursos, etc... Com o tempo todo esse movimento foi esfriando aos poucos (como acontece com várias outras tecnologias) ... Como você vê o mercado do Ruby hoje em dia?
Fabio: Quando a SAP chegou no Brasil nos anos 90, sua adoção foi explosiva. Toda empresa que se considerava uma grande empresa instalou produtos SAP. De Philips à Embraer à Petrobrás.
No Século XXI praticamente todas as empresas grandes já tinham SAP. E você pode dizer que o movimento foi “esfriando”. E é isso que quer dizer: quantas “Top 100” existem? Resposta: 100. Se você já está na maioria das 100, para onde pode ir agora?
Faz 10 anos que Rails vem sendo adotado. Quem olhar hoje certamente vai ver menos “novas adoções” do tamanho de casos como Twitter ou Groupon, porque não existem tantas delas. Significa que ela está “morrendo” ou algo assim? Não.
Levou 10 anos para as outras tecnologias finalmente entenderem e implementarem o que “on Rails” significa. E finalmente muitas delas são “on Rails”. Você não precisa copiar o código do Rails em outra linguagem para ser “on Rails” (aliás, algo assim normalmente está fadado ao fracasso). Um framework como Laravel no PHP é quase “on Rails”. Um framework como ASP.NET MVC é quase “on Rails”.
Ainda há mercado para Rails para no mínimo os próximos 10 anos, a não ser que a Web atual seja desligada do dia pra noite e substituída por algo completamente diferente.
Bugginho: Você é co-organizador da Rubyconf Brasil junto com a Locaweb, quais os maiores desafios em realizar um evento desse porte e o que o público que ainda não conhece pode esperar desse grande evento?
Fabio: Eu organizei eventos Ruby no Brasil desde 2007, começando com um pequeno evento chamado RejectConf SP que fiz em 2007. Depois tivemos 2 Rails Summit Latin America e uma sequencia de 7 Rubyconf Brasil, totalizando 10 anos de organização de eventos.
Existem várias dificuldades técnicas e logísticas que todos os eventos enfrentam, mas o que torna eventos de tecnologia no Brasil particularmente mais difíceis acho que é nossa síndrome de “cachorro vira-lata” no mundo.
Brasileiros ainda dão mais valor a assistir palestras feitas por convidados internacionais do que pelos nossos próprios profissionais.
Meu objetivo desde quanto comecei a organizar eventos era ver se eu conseguiria realizar 10 eventos anuais de grande porte. Este ano eu atingi esse objetivo, todo ano tivemos mais de 1000 pessoas num evento que fala exclusivamente sobre uma única comunidade e ela sempre cresceu, nunca deu sinais de diminuir.
Por isso eu anunciei este ano que estou me aposentando da Rubyconf Brasil e indo para outro desafio: resolver o problema de “cachorro vira-lata” da nossa cultura com um novo evento, chamado THE CONF.
Vocês podem ler mais sobre isso aqui: http://www.akitaonrails.com/2016/10/20/iniciativa-the-conf
Eu nunca quis ser somente “o cara do Ruby” - como já devem ter notado pelo meu histórico acima, eu não sou bom em Ruby, eu sou bom em aprender. Por acaso Ruby e Rails me mantiveram intrigado e fascinado por muitos anos. Agora é hora de mais, muito mais. Quem acompanha meu blog vai ver que escrevo sobre várias coisas diferentes, de Ruby, Elixir, Rust, Crystal, técnicas de programação, discussões filosóficas e tudo mais. Me sigam em http://www.akitaonrails.com para saber mais e nas redes sociais como minha página no Facebook https://www.facebook.com/akitaonrails/.
Bugginho: O Framework Ruby on Rails presa pela simplicidade e isso agrada muitas pessoas porque acaba tornando a curva de aprendizado bastante curta, porem é muito comum ver pessoas programando com o Ruby on Rails sem saber o básico do Ruby ou de como funciona o HTTP. Quais dicas você dá para quem quer se aventurar em RoR?
Fabio: Um dos conceitos que torna o framework “on Rails” é a idéia de “Convenção sobre Configuração”. A idéia de “esconder” a complexidade até que seja realmente necessário lidar com ela. É a noção de “gratificação instantânea” - coisa que o mundo PHP sempre foi bom - onde você rapidamente consegue ter um resultado prático, mas a diferença é que não basta subir o primeiro código básico: ele exige que você entenda a arquitetura se quiser ir até a produção. Um programador ruim raramente vai subir um projeto que funciona em produção por acidente. O Rails é exigente e vai tirar seu sono após a primeira etapa. Ela começa sendo fácil com você, mas depois ela vai selecionar os bons programadores dos maus programadores, o joio do trigo.
O básico da linguagem Ruby é muito simples. Qualquer programador consegue aprender o básico de qualquer linguagem em uma questão de poucos dias, normalmente 1 semana. E com isso já é suficiente para começar a escrever código - não muito bom - que funciona.
O avançado só vem com a experiência e trabalhando com outros programadores - em projetos privados ou de código aberto.
Para começar é simples: veja o Rails Guides http://guides.rubyonrails.org/ e em paralelo se aventure por sites como Code School http://codeschool.com/
Existem dezenas de exemplos de aplicações completas e complexas usadas de verdade em produção como Discourse http://www.discourse.org/ (feito pelo mesmo grupo do Stackoverflow) ou Gitlab https://gitlab.com/ (pense num Github completo mas aberto) ou Spree https://spreecommerce.com/ (um e-commerce completo) e muito mais. Não só só demonstrações ou aplicações de brinquedo, são de verdade, testadas em alta escala, com as melhores técnicas de programação Web.
Veja este site para mais exemplos de aplicações Rails open source: http://www.opensourcerails.com/
Se quiser conhecer uma comunidade brasileira, vá ao grupo do Facebook https://www.facebook.com/groups/rubyonrailsbrasil/ que conta hoje com mais de 10 mil membros.
Bugginho: Você é co-fundador da Codeminer 42 e realiza palestras sobre empreendedorismo. Como você ver o mercado para quem quer empreender na área de TI no Brasil durante essa crise economica e poítica que estamos passando, e quais dicas você dá para quem quer se aventurar?
Fabio: A área de TI tem enormes vantagens: ela é acessível, desregulada e globalizada.
A Codeminer 42 é uma empresa que completou 5 anos agora em Setembro de 2016. Em 2016, ano em que o Brasil passou por uma de suas piores crises econômicas e políticas da nossa História, a Codeminer 42 cresceu quase 40%.
Por que? Porque embora o Brasil estivesse em crise, o resto do mundo - em particular os EUA - não estava.
Porque desde 2013 viemos investindo em cursos de inglês para funcionários onde víamos mais potencial, porque viemos colocando a restrição de fluência em inglês para contratação - mesmo para estagiários! Aliás, também porque viemos contratando e treinando estagiários faz alguns anos, formando-os dentro das melhores técnicas.
Quase 3/4 dos programadores que temos falam inglês com fluência e trabalham de igual para igual com programadores em empresas de São Francisco ou Nova Iorque.
Dentre alguns dos nossos princípios adotamos: ninguém tem autorização para trabalhar mais que 8 horas por dias, nem mais que 5 dias por semana, nem em mais de 1 projeto de cada vez. Exceções existem, mas são isso: exceções. Todos são contratados CLT-full, com todos os benefícios. Todo projeto só inicia depois de contratos assinados. E temos somente 1 gerente de projetos/gerente comercial para todos os 60 programadores - porque o processo de trabalho é eficiente e focado em qualidade. Criamos todos os grupos para serem auto-suficientes e auto-gerenciados. Do estagiário ao júnior ao sênior, todos seguem os mesmos princípios.
É o jeito mais difícil de se organizar uma empresa de serviços, e exatamente por isso dói muito nos primeiros anos mas depois sabemos que temos uma fundação tão sólida quanto concreto.
Somos somente 2 sócios co-fundadores - que investiram dinheiro do próprio bolso -, zero investidores externos, zero dívidas, totalmente auto-suficiente e com capacidade de investimentos próprio.
No mundo inteiro hoje existe falta de programadores de qualidades. Porém no mundo inteiro existe uma oferta grande de programadores de baixa qualidade. Faça as contas: criamos programadores de qualidade para um mercado que filtra por qualidade, todos “on Rails”.
Bugginho: Em algumas regiões do Brasil é quase impossível arrumar emprego na área de TI ainda mais com um salário bacana, o que acaba estimulando alguns desenvolvedores a trabalhar home-office para empresas de outras regiões. Você já teve experiência, trabalhando ou contratando pessoas nessa modalidade? Qual a sua opinião a respeito?
Fabio: Agora no final de 2016, a Codeminer 42 tem quase 70 funcionários (onde mais de 60 são programadores), 7 escritórios físicos em 7 cidades (Natal, Teresina, Anápolis, Sorocaba, Novo Hamburgo, São Paulo e Campinas) e clientes no Brasil e nos EUA.
Todos tem mais ou menos o mesmo número de funcionários, com exceção de São Paulo, todos com 100% de programadores trabalhando fisicamente juntos em escritórios de verdade.
Por que Não Home-Office?
Porque é impossível treinar pessoas adequadamente se elas estão fisicamente isoladas.
Significa que sou contra Home-Office? Claro que não. Home Office é muito bom para quem já é experiente, que tem extrema confiança e resultados comprovados de disciplina sendo autodidata.
Para muitas empresas é muito fácil sair contratando gente home-office porque isso oferece menos “problemas” de curto prazo, como gerenciar escritórios.
É como não contratar com carteira assinada: é mais fácil no curto prazo, mas depois isso se torna um enorme problema. É sempre melhor pensar no longo prazo, no sustentável, pegar atalhos sempre vai resultar em fracasso.
Temos sim, provavelmente 3 ou 4 pessoas que ainda estão sozinhas em home-office. Fazemos isso quando queremos avaliar uma certa região geográfica e, tão logo ela se prove, abrimos um escritório. É como a Codeminer vem expandindo com eficiência e qualidade.
Se você estiver procurando oportunidades em uma das cidades listadas acima, não deixe de nos mandar seu CV em [email protected] estamos sempre à procura de novos desenvolvedores, de todos os níveis. E se quiserem conhecer alguns de nossos Miners, siga nosso blog: https://blog.codeminer42.com
Bugginho: Quero mais uma vez lhe agradecer por ter aceitado o convite e deixo o espaço aberto para você deixar o seu recado para a comunidade!!!
Fabio: Desenvolvedor de Software faz parte de uma categoria conhecida como “profissões de prática”. Existem profissões onde você evolui pouco ou quase nada depois de tirar sua certificação. Não existem muitos jeitos diferentes de preencher um formulário, por exemplo.
Profissões de prática exigem que os praticantes efetivamente “pratiquem”. É como ser jogador de futebol, não interessa se você foi um goleador 10 anos atrás e não praticou mais, você não vai fazer nenhum gol mais hoje. Se você é desenhista, arquiteto, médico, esportista ou desenvolvedor de software, seu resultado depende exclusivamente da quantidade de “esforço com propósito” (não esforço aleatório). Quanto mais fizer, melhor vai ficar.
Quem tem a cabeça de “me pague primeiro que eu faço depois” jamais vai evoluir.
Quem tem cabeça de “me dê a chance de praticar, faço até de graça até ficar bom” é quem vai ter sucesso.
Eu não contei no meu resumo da primeira pergunta, mas em todas as empresa que mencionei, por quase 15 anos de carreira, eu sempre saí de uma empresa para ganhar menos na outra empresa. Exemplo, se eu ganhava R$ 2000 eu ia pra outra para ganhar R$ 1500 ou menos, porque ela me oferecia desafios que eu não tinha praticado ainda. Mas eu sabia que eu poderia treinar e aprender rápido e subir pra R$ 2500 em poucos meses. Depois eu ia pra outra empresa, pra ganhar R$ 2000, mas eu sabia que podia crescer pra R$ 3000, e assim por diante. Até quando abri minha própria empresa, passei anos sem ganhar “nada” (comparado ao que ganharia se estivesse como funcionário numa grande empresa), porque tudo é investimento. “Empreendedor” que não abre mão de ganhar bem, não é empreendedor, é um funcionário medíocre disfarçado.
Meu recado final: o conhecimento é infinito, você nunca vai saber tudo, mas isso não me impede de tentar saber tudo, e você deveria trilhar esse mesmo caminho. Somente “ganhar a vida” é muito pouco.
Valeu! E continuem aprendendo coisas novas!
Importante: Essa entrevista foi gentilmente cedida por Fabio Akita para veiculação na página "Bugginho Developer". Caso queira replica-la, não esqueça de pedir autorização ao mesmo para tal.
Você pode conhecer um pouco mais e acompanhar o trabalho de Fabio Akita nos links abaixo:
http://setup.loopinfinito.com.br/fabio-akita/
Espero que tenham gostado tanto quanto eu e até a próxima, amiguinhos!!! ;)