Area Criações - Web e Design - Home

Métodos de classe não são métodos estáticos, e como tirar proveito disto

2009-11-06T14:31:00Z

Quando trabalhamos com OOP a divisão do código é bem clara. Classes definem um Objeto que possui atributos e comportamentos, comportamento é representado por métodos. Em Ruby tudo segue esta linha sem exceções (blocos não se encaixam perfeitamente assim).

Mas também é comum por exemplo situações onde talvez um método não precise estar associado a um objeto. Ou seja, não faz muito sentido precisar instanciar um objeto desta classe para poder acessar estes métodos.

Esta capacidade é conhecida de outras linguagens como classes estáticas ou métodos estáticos. Em Ruby não temos isto, temos apenas métodos de classe e métodos de instância. Mas o curioso que mesmo os métodos de classe são métodos de instância mas da classe em si.

Por exemplo:

class Utilities

    def    self.resize_images(images=[])
        ...
    end

end

Entendendo o que é um método de classe

Acima temos um método resize_images que é criado em Utilities. O self no momento da definição do método é Utilities, por este motivo seria o mesmo que definir o método assim def Utilities.resize_images . Como método foi criado em Utilities, você poderá acessa-lo como Utilities.resize_images sem a necessidade de enviar um .new para Utilities.

Uma pequena curiosidade é que as próprias definições de classe em Ruby são objetos, então Utilities (que é uma constante) também é um objeto, e estes objetos possuem como Metaclasse Class. Então por este motivo o que se assemelha a métodos estáticos de linguagens como Java ou AS3 é nada mais do que um método criado no objeto Utilities que é uma instância de Class armazenada em uma constante chamada Utilities.

Por exemplo, pelo IRB crie uma nova classe assim

class Carro ; end

e depois execute Object.constants.sort e você vera que agora Object também possui uma constante chamada Carro.

Agora que entendemos como funcionam os métodos de classe, existem outras formas de criar métodos de classe que é através da abertura da metaclasse, por exemplo:

class Utilities

    def    self.resize_images(images=[])
        ...
    end

    def    self.rename_images(images=[])
        ...
    end
end

Seria o mesmo que:

class Utilities

    class << self
        def    resize_images(images=[])
            ...
        end

        def    rename_images(images=[])
            ...
        end
    end
end

Você poderia também abrir a classe Utilities com instance_eval para adicionar métodos de classe nela, ou utilizar um módulo chamando-o com extend. Não vou entrar nestes detalhes para não me prolongar de mais.

Formas de empacotar seus métodos

Também não é incomun casos onde você tenha uma classe apenas com métodos de classe, o que é o caso da Utilities. Criando uma classe assim estariámos modularizando o nosso código, mas o que muita gente diria que é melhor criar um módulo ao invés de uma classe e estender as classes com o módulo Utilities. Também seria uma boa opção.

Mas talvez existem casos onde você não deseja ter que abrir a classe e extende-la apenas para ter acesso ao um método, então uma outra forma de modularizar seu código é através de um método pouco conhecido. Como módulos são classes que não podem ser instanciadas você não poderia fazer algo como abaixo:

module Utilities
    def    resize_images(images=[])
        ...
    end

    def    rename_images(images=[])
        ...
    end
end

Utilities.resize_images
Utilities.rename_images

Mas você poderia utilizar um module_function para permitir que estes métodos se tornem métodos acessíveis como métodos de classe. Como abaixo:

module Utilities
    module_function

    def    resize_images(images=[])
        ...
    end

    def    rename_images(images=[])
        ...
    end
end

E agora você poderá chamar os métodos em qualquer lugar, desta forma:

Utilities.resize_images
Utilities.rename_images

Então se você possui uma classe que tem apenas métodos de classe, não possui atributos ou acessors talvez seja interessante pensar nesta solução. Acaba sendo um pouco fora da idéia convencional de OOP, mas se pensarmos a fundo veremos que módulos são nada mais que classes que não podem ser instanciadas e já que não precisamos instanciar Utilities este método se encaixa bem.

Uma outra forma de ter o mesmo resultado seria estendendo o módulo com ele mesmo através de extend self , mas para explicar todas as formas e o que está por trás seria necessário um livro sobre Ruby object model e metaprogramação.

Ruby para automatização diária

2009-10-29T13:35:00Z

Para nós que utilizamos sistemas Unix temos várias formas de automatizar tarefas repetitivas, principalmente que os que utilizam Mac Os. Integrado ao OsX temos ferramentas como o Automator que permitem a criação de fluxos de trabalho e que são bem simples de serem criados, também é possível customizar e criar várias novas tarefas e fluxos para o OsX através de AppleScript.

Para quem utiliza muito terminal, ou precisa executar tarefas administrativas também é possivel utilizar ShellScript para criar automatizações.

Todas estas ferramentas são muito interessantes, mas tem um pequeno porém. As vezes fluxos mais complexos no Automator são bem chatos de serem criados e considero Apple Script e Shell Script linguagens bem feias, grandes e improdutivas. Então nada melhor do que usar Ruby para estas situações.

O que eu normalmente faço é criar uma pasta bin dentro da pasta do meu usuário. Dentro desta pasta bin eu coloco todos os arquivos de configuração do terminal bash ( não vou entra em detalhes sobre como dividir os arquivos de configuração pois já foi bem explicado no Peepcode aqui) e também uma série de arquivos ruby que serão executáveis. Basta adicionar esta pasta bin ao seu path do terminal e você terá seus mini-aplicativos ruby acessiveis independente de qual diretório estiver.

Crie uma pasta bin e dentro do seu arquivo .bashrc acrescente ao final a pasta bin (normalmente como abaixo):

export PATH=/opt/local/bin:/opt/local/sbin:${PATH}:/usr/local/mysql/bin:~/bin

Agora basta você criar o seus scripts ruby sempre se lembrando de não colocar a extensão .rb e de acrescentar o comentário com bang para tornar o arquivo executável (normalmente assim #!/usr/bin/env ruby no OsX).

Seguem abaixo alguns do scripts que utilizo mais no meu dia a dia:

Também possuo alguns que não em Ruby, mas fica um pouco fora do escopo deste post. Se você possui algum script por favor compartilhe também :D (não coloquei tudo no github pois eu tenho uma série de coisas particulares dentro da pasta bin também).

Curso de Ruby on Rails em Novembro

2009-10-26T17:08:00Z

Dentro de uma semana começaremos mais um curso de Ruby on Rails na e-Genial. Será o último curso do ano, que espero fechar com chave de ouro aplicando o curso da melhor forma possível.

O material do curso já está preparado e atualizado para Rails 2.3.4, além de contar com uma nova grade alinhada com as tendências atuais da comunidade Rails. Está tudo pronto para começar o curso, só falta você ;)

Dentro de uma semana começaremos mais um curso de Ruby on Rails na e-Genial. Será o último curso do ano, que espero fechar com chave de ouro aplicando o curso da melhor forma possível.

Como funciona o curso

Para quem não conhece os cursos da e-Genial, o que eu posso dizer é que o único curso online presencial. A estrutura do curso permite que façamos nossas aulas ao vivo, contando com recursos de chat, áudio, vídeo, slides e compartilhamento de tela (que eu uso muito). Tudo isto em tempo real e exatamente como uma sala de aula real, mas com uma vantagem, todos as aulas são gravadas. Todo o código criado durante o curso ao vivo é enviado junto com as gravações das aulas.

Os alunos que não podem acompanhar as aulas ao vivo assistem as gravações, e todos podem tirar dúvidas no grupo de discussões fechado para a turma do curso. Eu pessoalmente me preocupo muito com o grupo e tento responder todas as perguntas, sem exceção.

O curso também conta com um excelente material teórico, exclusivo e atualizado por nós instrutores. No total são 21 apostilas, disponibilizadas gradualmente, garantindo o ensino de forma simples.

A minha responsabilidade e benefícios que tenho

Está fazendo dois anos que trabalho em parceria com a e-Genial, uma parceria que me orgulho, principalmente por causa da equipe da e-Genial (que é fantástica) e da liberdade que me dão para conduzir as turmas da forma que considero melhor. Já ministrei treinamentos de Flex e atualmente estou voltado apenas para o Rails.

Não considero estes cursos com uma coisa simples, é importante que todos os alunos que estiverem interessados em aprender a tecnologia saiam do curso com a visão correta da comunidade e prontos para continuar seu aprendizado no caminho certo.

Em nenhuma outra forma de treinamento seria possível ensinar a mais de 50 alunos por turma, então a responsabilidade é bem maior. Já que como desenvolvedor Rails também não vou querer povoar a comunidade com profissionais ruins, caso contrário o meu trabalho será prejudicado a longo prazo.

E um benefício incrível que tenho com o curso é que ele cria um meio para trocar experiências com dezenas de pessoas diferentes com problemas diferentes e ainda participar das soluções. Por este motivo tento responder todas as dúvidas da lista de discussão e sempre fico alguns minutos no final de cada aula trocando experiências com o pessoal.

Por estes motivos eu garanto sempre fazer o meu melhor para ministrar os cursos.

Veja a nova grade abaixo:

Aula 1 – Introdução ao Ruby / Instalação / Linguagem 1 Aula 2 – Linguagem 2 Aula 3 – Linguagem 3 / Futuro Aula 4 – Começando com Rails 2.3.4 Aula 5 – CRM: MVC, Banco de Dados e Console Aula 6 – CRM: Scaffold e Validações Aula 7 – CRM: Relacionamento entre Models PI Aula 8 – CRM: Relacionamento entre Models PII Aula 9 – CRM: Relacionamento entre Models PIII Aula 10 – CRM: Composições, Filtros e Callbacks Aula 11 – CRM: Entendendo REST e aprofundando em Rotas Aula 12 – CRM: Internacionalização Aula 13 – CRM: Upload com Paperclip Aula 14 – CRM: Authlogic e Autenticação HTTP Aula 15 – CRM: Enviando Emails e Ajax P. I Aula 16 – CRM: Ajax P. II Aula 17 – CRM: Testes Aula 18 – Depuração, Segurança Aula 19 – CRM: Cache e preparação para deploy Aula 20 – CRM: Deploy ( Capistrano e outros ) Aula 21 – CRM: Fechamento do curso

Para ver o conteúdo detalhado visite: http://www.egenial.com.br/cursorails/grade

Está em dúvida?

Se você ainda está em dúvida se deve ou não estudar uma nova linguagem como o Ruby, ou dedicar tempo para um curso, então leia este post

Espero encontrar com você lá :D

LinguÁgil 2009 - Misturando Linguagens e Agilidade

2009-10-24T14:32:00Z

Diante da extensa gama de tecnologias e metodologias que existem para desenvolvimento web/desktop é mais do que válido eventos que reunam várias desenvolvedores especialistas em áreas diferentes. E assim será o evento LinguÁgil 2009 – Misturando Linguagens e Agilidade.

Os grupos AgileBahia, JavaBahia, PHPBahia e RailsBahia realizarão em Salvador este evento, que tem um formato muito interessante, que faz parte da XII Semana de Informática da Unime. Inédito na Bahia, o evento reune algumas das principais comunidades de TI, buscando estimular aprendizado e discussões em torno de linguagens de programação e metodologias ágeis.

Vou participar do evento palestrando sobre introdução ao Rails/Ruby e seu eco-sistema voltado para excelência e produtividade. Também vou aplicar um mini-curso introdutório ao Rails, este framework mágico que desencadeou uma série de boas práticas e hoje é copiado por quase todos os demais frameworks.

Pessoalmente acho que será um evento muito interessante, principalmente por contar com a presença de profissionais que trabalham com tecnologias que atualmente não utilizo. Tenho certeza que irei aprender muito e também espero poder passar um pouco também.

Informações do evento

Local:

Unime – Lauro de Freitas – Bahia

Palestrantes/instrutores

Alberto “Spock” Lemos (Globalcode), Alexandre Gomes (SEA Tecnologia), Dairton Bassi (Neurobox), Daniel Lopes (Área Criações), Felipe Ribeiro (UFCG), Felipe Rodrigues (Fratech), Henrique Landim (Partner Process) e outros

Palestras GRATUITAS (14/11)

Agile, Manifesto 2.0, Ruby On Rails, PHP/Frameworks, JSF 2.0/Scrum Toys, Linguagens para a JVM, Pentaho

Oficinas/Coding-Dojo (12 e 13/11)

Coding-Dojo Agile, Java/Web com Demoiselle, Integração Contínua/Maven (a confirmar), Python (a confirmar)

Mini-cursos (R$ 60 a R$ 120)

12/11 – Métodos Ágeis, JSF, Portlets com Liferay, TDD/Java, Ruby 13/11 – XP, Scrum, Pentaho, PHP/TDD, Rails

Inscrições:

Com desconto até 05/11 Preços promocionais para estudantes e membros do AgileBahia / JavaBahia / PHPBahia / RailsBahia

Programação detalhada, inscrições e mais informações em www.linguagil.com.br

Magnus Muhr e seu ensaio fotográfico com moscas mortas.

2009-10-22T14:52:00Z

O fotógrafo sueco Magnus Muhr montou um ensaio fotográfico cheio de humor com moscas mortas. Ficou super legal!

Exposição Scattered Pixel

2009-10-19T18:44:00Z

Formada em 2007, o Visual System é um grupo de artistas cujas obras redefinem o papel da mídia digital em um ambiente futurista urbano. A exposição Scattered Pixel, que está em Nova York, é composta por três instalações interativas que foram criadas pelos artistas: Oliver Pasquet, Djeff Regottaz, Bastien Ribeiro e Valere Terrier. Elas revalam como as obras digitais contemporâneas submergem o espectador em um conglomerado de interatividade. Música de Oliver Pasquet.

Veja o vídeo:

SCATTERED PIXEL from VS Team on Vimeo.

Nosso novo website online

2009-10-17T04:29:00Z

Colocamos hoje o novo website do escritório. Durante bastante já estávamos insatisfeitos com design anterior, e também com a identidade visual da empresa. Então resolvemos fazer uma renovação geral, criando nova logomarca, novo layout para o site e também material impresso.

E durante o tempo que utilizamos o site anterior, reparamos que poucas pessoas liam as páginas de serviços e quem somos, então resolvemos criar o novo website com apenas as seções que são realmente cruciais. O resultado foi um site com atualmente apenas duas páginas, focado no portfólio e formas de contato.

O design do novo site já estava pronto á alguns dias, mas estava faltando um tempo para confecção do XHTML e dos templates Rails. Então resolvi aproveitar minha viagem ao Rails Summit para criar tudo isto nos horários no avião, no hotel e em alguns momentos menos interessantes do evento.

O próximo passo será aplicar a mesma identidade visual do site atual também no blog. Esperamos que gostem, e para acessar o site basta visitar: www.areacriacoes.com.br

Rails Summit

2009-10-15T15:40:00Z

O inicio desta semana foi dedicado a participar do Rails Summit e a primeira coisa que posso dizer é que foi um evento fantástico. Exitei em ir ao evento por várias vezes mas acabei decidindo que iria valer a pena. E agora vejo que não me arrependo nem um pouco.

Obs: A e-Genial também liberou 10 bolsas para o meu próximo curso que foram sorteadas ao final do evento, e para confirmar o resultado do sorteio enviei um email para cada um dos sorteados mas dois deles voltaram. Então se você foi sorteado e recebeu o email responda-o, caso não tenha recebido entre em contato comigo (daniel v lopes at areacriacoes ponto com ponto br)

Um grande evento, com uma organização excelente e sem nenhuma falha. Algumas pessoas vão tentar discordar da minha opinão dizendo que no primeiro dia houveram falhas com microfone, que de fato ocorreram, mas eu não considero isto falhas reais já que em momento algum prejudicaram o andamento das palestras ou aprendizado. Eu gostaria de parabenizar e ao mesmo tempo agradecer a esta iniciativa do Fábio Akita e também a todos os demais envolvidos, já que não tive tempo de me despedir dele e falar isto pessoalmente.

O evento começou com um excelente keynote do Chad Fowler e foi encerrado por outro excelente do Obie Fernandez. Várias palestras foram muito interessantes, entre elas a do Gregg Pollack, David Chelimsky, José Valim e Vinícius Telles. A palestra do Richard Kilmer também foi muito interessante, sobre HotCocoa e MacRuby, mas eu já tinha visto um apresentação dele muito parecida.

Acabei perdendo a palestra do Carlos Vilela por precisar sair para fazer o checkout do hotel e também perdi várias apresentações que eu gostaria de ter assistido mas foram em paralelo, então precisei escolher. Espero que as gravações seja lançadas logo.

Também aproveitei uns 5 minutinhos para dar uma prévia do que será o cifras. Não entrei em detalhes da implementação e nem do sistema pois já era muito tarde e o pessoal estava bem cansado.

Mas mesmo com todo o conteúdo interessante do evento, sem dúvida um dos pontos mais importantes é o networking. Para nós que trabalhamos online e conhecemos muita gente apenas pela internet, é muito interessante conhece-las pessoalmente.

Conheci muita gente bacana, e gostaria de agradecer ao Rafael Rosa (meu companheiro de quarto :) pela boa recepção, e também ao Tucaz (@tucaz) pela carona ao aeroporto. Outra ponto bacana foi conhecer vários ex-alunos do curso da e-Genial e ver que o pessoal continua estudando Ruby.

No geral a única coisa chata é que tive que voltar um pouco antes, e perdi o coquetel e a festinha do final. Também teve muita gente que eu gostaria de ter conhecido mas não encontrei no evento ou não deu tempo, além dos demais quer eu gostaria de ter trocado uma idéia melhor mas por falta de tempo não teve jeito (Mergulhão, Julio Monteiro, George Guimarães, José Valim e etc). Mas de qualquer forma, ano que vem estarei lá novamente.

Abraço a todos que conheci e sucesso. Agora é colocar em dia os 3 que ficaram atrasados ;-)

Obs: A e-Genial também liberou 10 bolsas para o meu próximo curso que foram sorteadas ao final do evento, e para confirmar o resultado do sorteio enviei um email para cada um dos sorteados mas dois deles voltaram. Então se você foi sorteado e recebeu o email responda-o, caso não tenha recebido nada entre em contato comigo (daniel v lopes at areacriacoes ponto com ponto br)

Curso de Rails - devo começar a estudar Rails?

2009-10-08T01:12:00Z

Hoje mesmo conclui mais um treinamento na e-Genial, minha segunda turma de Rails. Mas já estamos com matrículas abertas para a turma de Novembro.

E como sempre recebo dúvidas sobre se devo estudar Rails, se vou conseguir empregar no meu serviço, como funciona o curso e etc. Então vou tentar responder as mais comuns neste post.

Hoje mesmo conclui mais um treinamento na e-Genial, minha segunda turma de Rails. Mas já estamos com matrículas abertas para a turma de Novembro.

E como sempre recebo dúvidas sobre se devo estudar Rails, se vou conseguir empregar no meu serviço, como funciona o curso e etc. Então vou tentar responder as mais comuns neste post.

Então vamos lá:

Quero fazer o curso da e-Genial mas o horário das aulas não bate com o meu, vou tirar o mesmo proveito ?

Posso garantir que sim. O curso conta com 21 aulas onde cada aula você receberá uma apostila com por volta de 15 páginas (ao final do curso você terá lido 309 pag. sobre a versão mais atual do Rails). As aulas ao vivo são uma revisão das apostilas executando o código ao vivo e com dicas práticas. Tudo é gravado e disponibilizado no dia seguinte ou no mesmo dia da aula ao vivo, para que quem não assistiu não perca nada.

Todos que participam do curso também fazem parte de um grupo de discussão, onde eu respondo todas as perguntas (não em tempo integral, mas respondo todas sem exceção), então mesmo que você não assista nenhuma aula ainda assim poderá tirar suas dúvidas.

Trabalho em uma linguagem, minha empresa desenvolve tudo com esta linguagem que atende bem. Estudar Rails e Ruby vai me ajudar como?

Ruby é uma linguagem produtiva e otimizada para felicidade do desenvolvedor. Mesmo que por enquanto sua empresa não invista em Ruby, você poderá criar rapidamente scripts para automatizar processos como deploy dos seus projetos e backups.

Ruby e Rails também abraçam uma dezena de boas práticas, que ajudam a você entender como tornar o seu código de fácil manutenção e mais amigável.

Estudando Rails você vai se acostumar a boas práticas como analisar logs, deploy automatizado, testes automatizados, um ambiente integrado a um versionador como Git, etc. Além de aprender a pensar de uma forma simples mas eficaz em assuntos como design patterns, por exemplo MVC e ORM, que muitas se complicam sem necessidade.

Você também aprenderá como arquitetar um projeto web de forma organizada, se preocupando com as urls e como isto facilita a criação de uma API Rest.

Você também aprenderá sobre dezenas de falhas de segurança em projetos web, e aprender como se proteger delas.

Mesmo que você não vá trabalhar com Rails na sua empresa todos os dias, estes conceitos vão te ajudar no seu trabalho atual.

No meu trabalho atual me chefe não está aberto a nenhuma linguagem nova, como introduzirei Ruby e Rails ?

Nesta situação, você poderá estudar sozinho, sem o apoio oficial da sua empresa pagando seus estudos. Mas quando surgir aquela chance de otimizar algo na empresa que nunca sobra tempo para ser feito, você poderá fazer em algumas horas e apresentar um protótipo funcional para resolver o problema.

Comece em projetos pequenos, por exemplo vocês vão lançar um novo produto em Java ou PHP, mas precisa de um site. Então faça o site em Rails, e ele estará pronto em poucos dias.

Se mesmo apresentando resultados práticos e reais a sua empresa continuar agindo de forma não pragmática talvez seja melhor você procurar um outro emprego que vá te garantir crescimento como profissional. E emprego para bom desenvolvedor Rails é o que não falta.

Estou cursando faculdade e não tenho muita experiência, nunca criei um sistema inteiro. Rails vai me ajudar?

Sim, definitivamente. Como o próprio criador do Rails costuma dizer, uma tela em branco é flexível mas deixa espaço para decisões ruins. Por este motivo o framework já toma diversas decisões eximindo você de cometer erros de arquitetura, mas te mostrando o caminho das pedras para uma boa estrutura (se você seguir as convenções do Rails).

Outro ponto que vai ajudar os menos experientes é a flexibilidade do Ruby através de Gems e do Rails através de plugins, que são nada mais que código de terceiros re-aproveitável. Então se você não sabe como fazer um sistema de autenticação ou upload, aprenda com quem sabe, basta aplicar e ler o código fonte destes projetos (que são todos opensource).

Trabalho com uma linguagem que adoro, amo de paixão, e não quero programar em mais nada. Por que vou perder tempo estudando Ruby?

Primeiro, você é sempre contratado para gerar lucros para alguma pessoal ou empresa, e não porque ama uma linguagem. E para conseguir cometer o menor número de falhas em decisões, como bom profissional que você deve tentar ser, é necessário que tenha uma caixa de ferramentas completa (como já comentamos aqui).

Lembre-se também que a sua linguagem mainstream hoje poderá ser o cobol de amanhã, então crie o costume de estudar.

Presto serviços de freelancer, e muitas vezes gostaria de abrir meu próprio negócio, Rails vai me ajudar ?

Desde o inicio o Rails foi criado para otimizar o trabalho de equipes pequenas mas mantendo o qualidade do código. O próprio Basecamp, sistema que originou o Rails, foi criado como um projeto paralelo em conjunto com o trabalho diário do David Hansson.

Não sei programar, posso fazer o curso ?

Sim, pode. Mas deverá se dedicar um pouco mais. Eu recomendo alguns livros de fácil leitura assim que o grupo de discussão é aberto, então se você não sabe programar deve ler estes livros o mais rápido possível para tirar o maior proveito. Em caso de dúvidas futuras poderá usar o material gravado e teórico como referência.

Tentei responder as dúvidas que normalmente recebo do pessoal que está em dúvida se deve estudar Ruby.

Qualquer outra dúvida, por favor perguntem nos comentários

Terminando mais um curso de Rails

2009-10-07T02:55:00Z

Chegou ao fim mais um curso da e-Genial que eu ministro. Amanhã termina o curso de Rails 2.3.4– do básico ao avançado. E como sempre, foi uma experiência fantástica e mais uma vez aprendi muito com todos os meus alunos!

Espero que os alunos tenham tirado proveito dos recursos do curso, e que possam continuar aprendendo mais sobre Rails em sua jornada contínua de estudo, que é uma boa exigência de nossa profissão.

O meu maior objetivo com este curso de Rails, é tentar passar um pouco deste eco-sistema (Ruby, Rails, deploy, Unix, versionamento, qualidade, etc) que melhorou drasticamente o jeito com que desenvolvo software e me manteve na área como desenvolvedor.

Acredito realmente que estudar Rails, se feito da forma correta e entendido da melhor forma, pode melhorar muito sua forma de pensar em relação ao ambiente geral do desenvolvimento web. Melhorando seu entendimento através de boas práticas aplicadas no dia-a-dia, e não apenas aquela teoria chata que é comum em cursos de faculdade.

Então, este ano treinei 88 alunos em Rails (ainda temos mais uma turma para Novembro), e espero que a grande maioria tenha gostado.

Gostaria que vocês, que foram meus alunos, comentassem o que acharam do Rails, do Ruby e etc. E os que já fizeram o treinamento a mais tempo, se estão trabalhando com Rails atualmente.

Abraços e muito obrigado a todos.

Pagamento com Moip

2009-10-01T14:37:00Z

Já tem um bom tempo que ando estudando os meios de pagamento brasileiros. Como não quero depender de uma infra-estrutura Windows e também não quero passar por muita burocracia em vários casos, acabou sobrando apenas meios como os gateways de integração (não verdade não são bem gateways).

A diferença básica entre uma integração ou um gateway é que através do gateway o usuário nunca sai do seu site. Você recolhe os dados e envia através de conexão segura (SSL ) para o gateway que passa por uma série passos padrozinados.

Este passos normalmente são authorize, capture, purchase ou void. E através destes passos é possível que uma biblioteca como o Active Merchant consiga abstrair as dificuldades e facilitar a transação com vários gateways.

Porém, como não temos gateways padronizados no Brasil (ao menos não encontrei nenhum) sobraram as integrações. Integração é algo no estilo Paypal, onde o usuário é redirecionado para o site da organização que realiza a captura dos dados e a cobrança.

O bacana é que o ActiveMerchant também tem meios de pagamento através de integração, porém as soluções deste tipo no Brasil também são bem despadronizadas. O que dificulta uma implementação deste meios de pagamento com o ActiveMerchant.

E pensando em encontrar uma boa solução para pagamentos dos meus clientes, venho testando os que parecem ser mais interessante, como por exemplo o pagamento certo da Locaweb (veja a app de teste que fiz). Também testei o pagseguro e o pagamento digital, mas nem criei uma app de teste porque ambos são muito bagunçados, documentação ruim, api estranha com métodos horrorosos, suporte inexistente (ao menos não encontrei) e por aí vai.

Então, na semana passada comecei a testar o MoIP. Testei todas as ferramentas deles: intregação simples, integração HTML e integração via API Rest.

Apesar de um pouco desconhecido ainda, eles são muito melhor do que todo o resto que testei no Brasil. De todos, é o que mais se aproxima do Paypal.

Primeira vantagem do Moip é que ele possui um sandbox, que é um ambiente idêntico ao real só que as transações não acontecem de verdade, desta forma você pode testar a vontade. Quando falo de uma ambiente de testes não é aquele tipo de solução do PagSeguro que é um servidorzinho de testes que você tem que instalar na sua máquina, e sim um sandbox mantido pelo próprio Moip semelhante ao caso do Paypal.

Segundo, a API é bem documentada (tem falhas, como parâmetros escondidos, mas já é 100x melhor do que os outros) . Possui IPN, que é notificação de pagamento, ou seja, após o pagamento o MoIP vai ficar contatando sua app e enviando o status da transação.

Terceiro, possui pagamento recorrente, mas este eu não testei pois prefiro tratar estas coisas na minha app.

Para terminar, eles possuem uma API Rest. Se você não quer tanta flexibilidade, então pode usar só um form simples através da integração HTML, mas se estiver usando Rails é melhor que use API Rest já que isto é muito simples no Rails.

Eu também ia dizer que o suporte é uma vantagem, mas ultimamente não tem sido. Mandei um email reportando duas incompatibilidades com o Safari e eles nem me responderam, também fiz algumas perguntas nesta semana e até hoje nada. Reportei duas falhas sobre o Safari através do sistema de Tickets e fui respondido em menos de 24h. Inclusivo pedindo mais sugestões, além de em pouco tempo terem resolvido os problemas. Também fiz algumas perguntas que não estavam na documentação e me responderam com muito clareza.

Ainda não tive tempo de tentar uma integração com o ActiveMerchant (acredito que é totalmente possível), mas para fins de testes e aprendizado criei uma appzinha básica no github que usa o HTTParty para comunicar com Moip via API Rest.

O ponto central da integração (da forma que eu fiz), é uma classe na pasta lib do Rails que contém o código abaixo:

Este código faz nada mais que incluir o HTTParty, montar um xml simples com o builder e depois fazer um post autenticado (com os dados que vieram do arquivo gateway.yml). O método charge faz tudo isto e retorna um xml que é convertido em um hash para você usar dentro de sua app.

Desta forma eu posso chamar em qualquer controller algo como abaixo:

Então se você está afim de encontrar um jeito fácil de pagamento com Rails no Brasil, acesse este link

Pare de dar suporte ao IE7 e IE6

2009-09-21T16:04:00Z

Em desenvolvimento web estamos sempre dependendo da máquina do visitante, então estamos na mão do sistema operacional, hardware e principalmente dos navegadores.

Isto normalmente não é um problema, com exceção dos navegadores da Microsoft, que por anos se mostram muito inferiores. (Entenda mais sobre o assunto lendo este post)

Mas finalmente a versão atual do Internet Explorer( versão 8), é aceitável (mas ainda inferior).

Diante desta situação decidimos parar com o suporte a qualquer versão do Internet Explorer que seja inferior ao 8. E para mostrar isto ao usuário nós testamos diversas alternativas como barrinhas em Javascript. Mas como sempre, a alternativa mais simples é a melhor:

Basta colocar o css em seus arquivos de css do layout e o comentário condicional. No meu caso estou sempre utilizando Rails, por isto aparecem os comandos link_to e image_tag, se você estiver usando HTML puro então substitua por <img... e <a href...

As imagens que utilizo (já com a cor de fundo na tonalidade correta) estão abaixo para download:

Logos do Browsers

Também adote e esta empreitada contra a péssima qualidade de serviço apresentada nos navegadores da Microsoft.

Não mate o mosquito com uma granada

2009-09-18T03:48:00Z

Já tem um bom tempo que pretendo escrever sobre isto, a ferramenta correta para o problema correto. Resolvi finalmente escrever sobre este assunto devido aos questionamentos que surgiram na minha palestra do RailsForKids, perguntado como escolhemos as tecnologias para nossos projetos.

Este post também é uma resposta ao flamewar sem sentido que apareceu na comunidade Flex por causa de uma levantamento pragmático sobre a tecnologia.

Gostaria de apresentar como costumamos decidir as ferramentas de um projeto. Então eu gostaria de apresentar a caixa de ferramentas e coisas com que trabalhei nos últimos anos:

Ruby
Rails
Javascript
Jquery
Prototype
XHTML/CSS
Flex
Flash (AS3 e usando frameworks como Gaia e Mate)
PHP
Delphi
Java (J2me)

Eu não listei tecnologias relacionadas a design (como Adobe Photoshop, Adobe Illustrator, 3D Studio) ou infra-estrutura como GIT, Capistrano, sistemas Unix, Apache. Também não falo de metodologias e conceitos como TDD, BDD e outros. Também não listei tecnologias que estudo por diversão mas que nunca cheguei a utilizar em projetos reais, como Capuccino, Sproutcore, Smalltalk, Lisp, CouchDB, MacRuby, Objective-C, Adobe Air e etc. O foco aqui é mais linguagem de programação/marcação e mostrar a importância de conhecer bem mais de uma ferramenta.

Obviamente não sou fluente e nem especialista em tudo isto, mas posso dizer que apesar de tentar estudar várias coisas diferentes eu tento me especializar em apenas 2 coisas no máximo, Rails/Ruby e design de interfaces. Porém, em algumas linguagens/ferramentas tento me manter atualizado e estudando, em especial tecnologias que componham o ambiente de um sistema web (que por padrão é multi-disciplinar), ferramentas como XHTML/CSS, Javascript(e frameworks) e Flash( + derivados).

Sou a favor que todos (inclusive designers) devam ser especialistas generalistas. Em qualquer área é muito importante saber quais as ferramentas existem, conhecer as vantangens e desvantagens de cada uma, abrindo o leque o máximo possível, mas mantendo-se realmente especializado em uma ou no máximo duas coisas.

Você não nasceu com um cérebro deste tamanho para aprender só uma coisa, certo? Da Vinci só sabia pintar? Einstein era só físico? Michael Jackson só sabia dançar? Não! E todos foram extremamente bem sucedidos. E este era o trabalho deles, o que não é diferente para você. Entender suas ferramentas é o seu trabalho.

Então se você abrir sua visão será capaz de optar por uma ferramenta melhor para um problema específico.

Atualmente trabalho em uma empresa muito pequena, exatamente por que é onde eu posso tomar este tipo de decisão. E esta liberdade é o que me permite estudar todas estas tecnologias e saber que não estou preso a uma tecnologia pois a empresa é partner ou tem certificação de algo em especial.

No RailsForKids o Daniel Willian e outras pessoas pergutaram como escolhemos entre Flex e XHTML/CSS (repare que é uma dúvida restrita a front-end). Para responder, primeiro vamos entender o backend.

Aqui tentamos adotar a seguinte posição, somos desenvolvedores Rails por opção e evitamos utilizar PHP ou Java ao máximo pois são imensamente piores para manutenção se comparado a clareza e abstração do Ruby.

E descobrimos isto bem no início, uns 3 anos atrás, quando percebemos que gastavamos 6 meses para criar um portal ou um sistema razoávelmente complexo em PHP e no final apesar de termos um código OOP (pseudo OOP como qualquer código PHP) e muito bem organizado ainda não era lá grandes coisas para o padrão desejado.

Nós também não queríamos crescer, não queríamos contratar gente e produzir resultado rápido por força bruta. Queríamos ser produtivos, mas com qualidade. E usando o leque de ferramentas que estavamos testando (eu já desenvolvia em PHP a anos) seria impossível manter o negócio rentável. Não falo de amor por uma linguagem ou dogma, meu trabalho é exclusivamente gerar lucros para o meu cliente e consequentemente para nós mesmos.

Então o que fizemos foi abrir o leque e correr atrás de outras coisas. Python(Django), Smalltalk(Seaside), PHP e Ruby(Rails) foi o que procurei conhecer. Nitidamente a última solução era melhor para o nosso problema além de ser uma alternativa robusta por ideologia. E esta ferramenta se encaixou perfeitamente para o backend de praticamente todos os nosso projetos, seja site ou sistema, seja simples ou extremamente complexo. O Rails resolve muito bem o seu objetivo.

Obs.: Também utilizo Wordpress que é PHP, por que ele é atualmente a ferramenta correta para blog, não por seu código (que considero ridículo, basta ler o fonte do projeto) mas por sua comunidade e gama de ferramentas que envolve o serviço do Wordpress (mas meu sonho é que ele fosse re-desenvolvido em Rails).

Então restou o front-end, atualmente temos diversas tecnologias para front-end e diferente do backend díficilmente você poderá usar em 90% do caso uma única ferramenta. Então vamos listar as principais, seguidas de suas vantagens e desvantagens:

XHTML/CSS/ Javascript (nunca sem um framework):

Alternativa extremamente difundida, simples de aprender e ainda conseguimos designers que entendam um pouco de HTML e CSS. Ainda tenho a vantagem de ter javascript por padrão em todos os browsers sem um plugin e sem ser compilado. O projeto pode crescer horizontalmente sem me preocupar com o tamanho de um único arquivo, exatamente por não ser compilado. Ainda tenho a vantagem de ser amigável aos mecanismos de buscas e comportamentos que se tornaram padrão como URL’s, Bookmark, avançar e voltar no Browser e etc.

Também consigo criar algumas animações e um certo nível de assincronismo utilizando um framework de Javascript como Jquery. Afirmo que você nunca deve desenvolver em JS sem um framework pois é impossível manter seu projeto cross-browser já que todos os browsers possuem erros no DOM e os frameworks abstraem isto. Seguindo esta regra, também não tenho discrepância entre navegadores e Javascript.

Mas agora aparecem as desvantagens, manter as coisas exatamente igual em todos os navegadores no ponto HTML e CSS não é tão simples, isto graças ao Internet Explorer. Porém já existe o IE8 e este cenário esta mudando.

Outra desvantagem(ou vantagem) de HTML/CSS/Javascript é que eles abraçam o protocolo HTTP como ele foi pensado, então não é simples manter um assincronismo em um patamar maior. Logo se você precisa de algo como o Treinatom ou PhotoshopExpress sem dúvida o HTML/CSS/Javascript não é uma boa alternativa, gerando muito código e consequentemente algo impossível de manter.

Flash

Flash, diferente do que muita gente pensa é uma tremenda ferramenta de programação. Possui uma linguagem robusta e uma “VM” (o FlashPlayer) muito bem desenvolvida. Ele permite resolver o problema que apresentei o sobre HTML. FlashPlayer não abraça o HTTP e não navega entre diversos arquivos e urls. Desta forma é possível manter um assincronismo e ao mesmo tempo ter animações robustas. O que o torna perfeito para animações, jogos, interatividade e ainda 3D.

Mas ele também possui desvantagens, por não abraçar o HTTP perdemos coisas como url’s, botões do browser e indexação (já que o swf não é um arquivo de texto). Porém tudo isto pode ser implementado, mas tem um custo e este custo poderá pesar em sua manutenção futura.

Outra desvantagem é por ser compilado, o que pode tornar o seus arquivos finais bem grandes e fazendo com que estes arquivos cresçam mais a cada nova necessidade. Porém isto também pode ser resolvido, mas tem um custo, como dividir em vários swfs, externalizar fontes, imagem, aúdio e video. E este trabalho não é tão trivial assim sendo uma coisa que o html já faz por nascença.

Vale lembrar que o Flash adota AS3, e ela não é uma linguagem enxuta como Ruby. Basta correr o olho em qualquer projeto flash maior e verá dezenas de getter, setter, definição de varíaveis e consantes. Recentemente analisei o fonte de um StockImage em Flash e fique realmente assustado. Por este motivo os custos que falei podem se tornar imensos e resultando em um projeto inviável.

Flex

Mais uma vez, diferente do que muita gente pensa Flex não é Flash. Apesar de ser um framework de AS3 e compilar um swf, o fluxo de trabalho e forma de desenvolver do Flex é totalmente diferente do trabalho de um desenvolvedor Flash.

Flex não é tão bom para animações complexas e nem para jogos como o Flash. Isto ocorre por possuir seus componentes e classes bem definidas, criando uma limitação (mas uma limitação boa para seu objetivo).

Componentes, que por sua vez são pensados com o objetivo focado em aplicações semelhantes ao desktop. Grids, botões, janelas, menus e tudo que uma aplicação desktop costuma ter pode ser encontrado no Flex.

Outra vantagem, o Flex tenta trazer o bom do desktop para o web, então ele é por natureza assíncrono (já que roda no FlashPlayer). Por ser assíncrono e focado em aplicativos você terá facilidades para implementar coisas como o Treinatom ou Photoshop Express.

Mas tem um porém, você também perde url’s (ok, estou cansado de saber que é possível usar coisas como DeepLinking e HistoryManager mas isto tem um custo, que em html não existe). E você tem que tomar os mesmos cuidados do Flash e dividir seu projeto em vários arquivos e externalizar assets. Consequentemente, por ser um swf você tem as mesmas desvantangens do Flash em relação a estrutura.

Outros

Existem outras coisas como Capuccino, SproutCore, Open laszlo, Silverlight, JavaFX, Gear e etc. Mas não vou entrar em detalhes pois acabam se encaixando no que foi dito acima.

Agora que sabemos as vantagens e desvantangens podemos imaginar os cenários:

Websites, portais, sistemas:

XHTML/CSS/JS é perfeito para websites e portais. Pois são projetos que precisam ser indexados com magnitude, precisam funcionar bem com o browser(urls, botões, histórico, etc) e não devem conter nenhuma barreira que exija usuário instalar algo(ok, flashplayer esta em 90% das máquinas, mas ainda é algo para instalar).

Já que são de acesso público (normalmente). Sites e portais, crescem exponencialmente todos os dias, e em html podem tirar proveito de técnicas de cache que criam arquivos html estático e evitam processamento no backend. Também podem crescer em número de arquivos sem se preocupar com o tamanho de um pacotão compilado que precisa ser sub-dividido.

É perfeito também para sistemas com muito conteúdo em texto, porém pouca mídia (video e aúdio) e sem muita necessida de assincronismo. Para um nível pequeno de assincronismo, algumas chamadas Ajax resolve bem o problema. E você continua com as vantagens que citei.

Melhor ainda se seu sistema precisa fazer uso de urls para organização (coisa comum em arquitetura REST) pois html abraça HTTP. E no fim você ainda poderá utilizar formas de otimizar performance via http e sairá no lucro.

Hotsite, jogos e interatividade

Hotsite, Jogos ou peças de marketing interativo na grande maioria das vezes não precisam ser indexados, não precisam de urls e fazem uso intenso de animações complexas e assincronismo.

Algumas vezes precisam aceitar bem fórmulas matemáticas e desenhar algo com isto.

A maior parte do tempo não terão formulários ou muito texto. Também não é algo que vai crescer exponencialmente e precisar de manutenção diária, e também normalmente são projetos com curto tempo de vida.

Logo Flash encaixa como uma luva, e não tem ferramenta melhor.

Sistemas desktop like

Se você precisa de algo online, mas que se comporte exatamente como uma app desktop, permitindo que ao mesmo tempo que um video é transmitido, um desenho seja feito e salvando estas coisas de forma permanente então Flex é melhor opção.

Flex foi pensando para aplicativos, normalmente fechados ou intranets onde você não tem a necessidade e enviar uma url para o twitter. Também é comum ver sistemas Flex rodando em um ambiente previsto, onde você sabe que todos terão o player instalado, que todos terão uma internet razoável e que não haverá problema dividir o projeto em vários arquivos de 250kb, além de um loading inicial de 500kb (que vai ficar no cache eternamente).

Para nós (Area) ainda existe um player diferente na história, o Rails que é uma Full-stack Framework e traz ferramentas para resolver facilmente os problemas do html e javascript. Além de ser REST por padrão e abraçar muito bem URL’s (diferente do PHP com mod-rewrite no Apache).

Então como optamos por Rails quase sempre também acabamos optando por HTML e Jquery mesmo para sistemas, claro se não houver a grande necessidade de assicronismo.

Obrigado David Hansson e comunidade Rails, que é formada por grandes desenvolvedores.

Mas existem casos extremos e aspectos externos, como por exemplo um cliente exigir que o site seja em Flash pois terá uma música (nesses casos tentamos rejeitar o projeto), ou você prestar serviço como desenvolvedor para uma agência ou designer que criou um layout impossível de ser criado em html (e sem te mostrar antes) ou está no contrato uma transição entre cada página com animação. Neste caso Ajax ou Js pode não ser a resposta e você mais uma vez é obrigado a adotar uma ferramenta não muita adequada se não quiser perder o cliente (nem sempre é possível rejeitar um projeto).

Mas no fim do dia a regra para nós é o seguinte:

XHTML/CSS para sites, portais e apps menos assincronas.
Flash para jogos, hotsites animados com tempo de vida e com tamanho limitado (sem muito db, forms ou texto)
Flex para apps assíncronas
Rails para quase tudo, exceto blogs (sobrou wordpress :( )

Estes são os cenários comuns quando o assunto é web, mas em outro ambiente eu poderia sugerir (pois não sou especialista nestes ambientes):

AIR, Bowline e Shoes para desktop multiplataforma
MacRuby para desenvolvimento Mac
Rhodes ou Rails para mobile

E em nosso dia a dia tudo isto que falei é permeado por versionamento em GIT (e Github ), Mac’s ou Linux (nunca Windows) para desenvolvimento e Linux no Host. Além de usar BDD ou TDD em muitos casos (na verdade quando código é Rails ou Ruby).

Mas se você vai usar Flex para tudo, ou HTML para tudo ou Flash o problema é seu, ou melhor, do seu cliente. Para nós, no fim do dia o que importa é ter o cliente satisfeito e lucrando e conseguindo manter isto em um custo acessível, sendo pragmático para manter a nossa diversão trabalhando.

Música em websites

2009-09-15T23:24:00Z

E uma frase que sempre escuto de clientes é: Eu quero música no meu site.

Antes de responder esta pergunta ao cliente devemos pensar o seguinte, nosso trabalho esta mais para um pintor onde o cliente decide a cor ou para um médico que ele é o único a decidir o que fazer? Acho que a resposta é uma mistura dos dois.

Nós desenvolvemos quase qualquer tipo de coisa relacionada a WEB. Simples templates de newsletter, sites estáticos, hotsite em flash, banners, jogos até chegar em complexos sistemas.

E todos nós sabemos que para cada problema existe uma ferramenta correta, as vezes pode ser Rails, as vezes puro HTML ou Flash. Mas o que me incomoda muito e algumas vezes nos faz rejeitar trabalhos é a necessidade de aplicar uma ferramenta errada para o objetivo desejado.

E uma frase que sempre escuto de clientes é: Eu quero música no meu site.

Porém é necessário fazer o cliente entender que ele não é o cliente e sim quem vai visitar o site (ou sistema que seja). E para aplicar uma música devemos pesar o técnico primeiro.

Se você tem um site grande, com muito conteúdo dinâmico e conteúdo de texto que deve ser indexado por mecanismos de busca então ferramenta a perfeita é XHTML e CSS. Não tente fazer um site em Flash com centenas de páginas, AMF e comunicação espalhada por todos os lados e formulários de mais, pois isto será um inferno e o cliente vai gastar centenas e não vai obter retorno (direto recebe pedido de manutenção neste tipo de projeto, mas isto é assunto para outro post).

E aí que começa o problema da música, para aplicar uma música sem interrupções a cada nova página é necessário manter o visitante na mesma página. Para isto podemos usar FLASH, AJAX ou Iframes só que todas as opções são ridículas se você está no cenário do parágrafo anterior. Utilizar Flash apenas por causa da música é um absurdo e cairá no problema que eu já disse, usar Ajax é pior ainda pois você terá um Frankstein cheio de código javascript onde não deveria, e IFrames não preciso nem comentar (espero que ninguém use isto para montar um layout nos dias de hoje).

Ainda temos um outro impedimento, sabemos que o tempo médio em uma página é de segundos e que um streaming ou download as escondidas pode atrasar e muito a exibição da página. Além de consumir uma enorme quantidade de banda. Imagine que seu site tem pouco acesso, 100 por dia, mas tem uma música de 800kb assim você terá um consumo de mais de 80mb. Este valor pode será muito maior do que o necessário para uns 1000 visitantes.

Então se estou nesta situação , prefiro rejeitar o projeto caso o cliente não abra mão da música, pois nós sempre precisamos pensar na qualidade final e isso será impossível se você usar a ferramenta errada.

Porém se você está criando um hotsite ou um jogo interativo mais que natural que tenhamos uma música e isto não é problema pois o site já será em Flash. Mas ainda sim é preciso tomar cuidado com o seguinte:

Seu visitante espera escutar uma música? Se você estiver criando o site do CD de uma banda é provável que sim. Mas em 90% dos casos não. E se seu usuário estiver escutando sua própria música ou estiver em um ambiente de silêncio? Com certeza ele vai odiar o site.

Mas por fim, se realmente não for possível então tente ao menos colocar a música desligada por padrão e permitir que o visitante ligue-a para evitar esta horrível decepção. Ou se estiver em projeto HTML e o cliente não abrir mão deste tremendo erro coloque a músico desligada e só na Home do site.

Então tente mostrar isto ao cliente, o problema técnico e o problema de uso. Só para reforçar como um site com música pode trazer ódio:

View mariojunior’s tweet

</iframe></noscript> <noscript><iframe src="http://tweetpaste.thingamaweb.com/embed/84032/" height="200" width="500">

View pcassiano’s tweet

</iframe></noscript> <noscript><iframe src="http://tweetpaste.thingamaweb.com/embed/84033/" height="200" width="500">

View vinicius_luiz’s tweet

</iframe></noscript> <noscript><iframe src="http://tweetpaste.thingamaweb.com/embed/84034/" height="200" width="500">

View danieldocki’s tweet

</iframe></noscript> <noscript><iframe src="http://tweetpaste.thingamaweb.com/embed/84037/" height="200" width="500">

View jtadeulopes’s tweet

</iframe></noscript>

Slides do RailsForKids

2009-09-14T19:39:00Z

Seguem os slides da minha palestra para o RailsForKids:

Frontend<object height="355" width="425"><param /><param /><param /><embed src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=frontend-090914150158-phpapp01&stripped_title=frontend-1996929" height="355" width="425"></embed></object>

View more presentations from Daniel Lopes.