Minhas impressões – Ruby+Rails no mundo real 2010 – 29/05/10

Caros amigos e leitores,

Vou escrever nesse post uma cobertura acerca do que ocorreu no evento do dia de ontem e que estive presente, o Ruby+Rails no mundo real 2010, em sua segunda edição. No ano passado também estive presente nesse mesmo evento e fiz um post de cobertura do que aconteceu. Esse ano vou “repetir a dose”…rs. Confiram abaixo!

Panorama

Ontem foi mais um sábado perdido…brincadeira…mais um sábado dedicado a angariar informação ao “portifólio de conhecimento”, como gosto de citar. Estive nesse evento juntamente com o colega de empresa Fabrício Campos. Estávamos motivados e com expectativa alta para a segunda edição do evento, muito pelo que ocorreu no ano passado. Para mim foi a segunda participação no evento, Fabrício estava participando pela primeira vez.

A localização (e a manutenção do local do evento, mesmo do ano passado) do Century Flat facilitou bastante a chegada até o local, muito pela variedade de vias de acesso e disponibilidade de transporte público até a Av. Paulista. Cheguei com um pouco de antecedência (cerca de 8h35 da manhã), fiz meu credenciamento e aguardei até as 9h00 para o início.

Consegui um bom lugar para me estabelecer: perto de tomadas 🙂 Assim consegui manter meu notebook e celular “vivos” até o fim do evento! Apesar de no “fundão” o pessoal ter passado alguns “apertos” para visualizar alguns slides com código…

Abaixo vou colocar um resumo, informações e alguns apontamentos pessoais do que conferi “in loco”.

Wilian Molinari – Abertura do evento e o GURU-SP


Wilian Molinari, a.k.a PotHix, fez a abertura do evento contando para o pessoal o histórico sobre a idéia de criação do GURU-SP, e como eram as primeiras reuniões do grupo: o primeiro e segundo encontro tinham poucas pessoas (cerca de 3 ou 4). As reuniões eram esporádicas, mas conforme a lista de discussão crescia o desejo de se criar um evento crescia também. Assim o “Ruby+Rails no mundo real” (edição 2009, primeiro do grupo) foi bastante produtivo e aumentou consideravelmente o número de inscritos na lista.

A partir disso a comunidade Ruby aqui em SP cresceu e se tornou bastante sólida e ativa. As palestras subseqüentes (a maioria nos encontros mensais do grupo) foram melhores e com mais pessoas. Os encontros tornaram-se mais constantes e muitas outras empresas passaram a apoiar a o GURU-SP (inclusive a que trabalhamos eu e o Fabrício hoje: Voice Technology, que já recepcionou uma das reuniões do GURU-SP).

O GURU-SP hoje conta com alguns projetos e atividades:

Finalizando a abertura, foi passado um vídeo com uma mensagem do Matz (criador do Ruby) para o GURU-SP:

Abaixo a apresentação do PotHix na abertura (via Slideshare):

Douglas Campos & Scalone – Processamento batch – Escalando um sistema sem “fermento”


Nessa primeira palestra, @qmx e @scalone centraram as atenções para o conceito de processamento em batch, fazendo um paralelo (um tanto quanto extenso…) com a produção de pão.

A linha principal de raciocínio era: quando sua aplicação cresce muito e “escala sem esperar”, uma hora ela fatalmente não vai suprir a demanda(e “de repente” vai cair). Nesse ponto é preciso analisar alguns pontos e procurar um culpado (lógico! rs). O banco de dados (DBA), infra (sysadmin), entre outros são os primeiros da lista. O desenvolvedor nunca é o culpado (o famoso: “Eeeuu…que isso….eu não erro” rs). Por isso conhecer e saber desenvolver um sistema que possa processar múltiplas tarefas é necessário.

Para isso eles deram como “solução” o uso de dois processadores de tarefas: DJ e BJ.

Para um processamento de imagens pesadas em batch (ou conversão de vídeo), por exemplo, o mais indicado é uso do DJ. Abaixo algumas características:

Vantagens

  • Documentação e tutoriais vastos;
  • Curva de aprendizado baixa.

Detalhes

  • Sinatra-dj;
  • Compatível com rails > 2.2;
  • Usa daemon ou worker.

Desvantagem

Exemplos de código

Uma outra biblioteca útil para trabalhar em conjunto com o DJ é o delayed_paperclip.

Abaixo as informações acerca do outro framework, o BJ:

Vantagens

  • Mais simples e robusto;
  • Instalação fácil;
  • Curva de aprendizado mais baixa que o DJ.

Desvantagens

Um ponto importante que deve ser sempre ressaltado: DJ e BJ não são balas de prata. Uma outra ferramenta citada na apresentação foi o resque, usado em conjunto com o Redis (banco de dados NoSQL), para criação de filas de uso muito mais rápidas e escaláveis. Tem uma interface de administração legal e é uma solução muito valiosa.

As seguintes ferramentas de monitoração para soluções de processamento em batch foram dadas: Monit, God, Munin. E toda essa palestra se baseou em cases de sucesso, como o da própria AutoSeg (empresa onde trabalham ambos os palestrantes) e GitHub. Aliás, o GitHub também usa um servidor chamado Unicorn, que é faz parte das muitas soluções usadas pelo site para manter-se no ar com estabilidade.

Uma outra fonte muito legal sobre o assunto, que encontrei em pesquisas (o autor desse post mesmo…rs), foi um post do Tobin Harris intitulado “6 ways to run background jobs in Ruby“.

Para encerrar, só queria citar o ponto de que ambos os palestrantes estavam muito dispersos, divagaram demais no começo da apresentação. Até chegar na parte técnica mesmo foi “muito pão e poucas explicações claras”. Houve demora pra chegar no “core” da palestra (apesar das boas pitadas de humor). Mas tirando isso tudo certo…rs.

Abaixo confiram o vídeo da palestra (“produções Agaelebe”, by Hugo Borges, que gravou o evento todo e irá disponibilizar os vídeos a medida do possível):

[blip.tv ?posts_id=3716284&dest=-1]

A apresentação no Slideshare:

David Paniz e Leonardo Bessa – Entendendo metaprogramação e por que magia negra não existe (Voodoo é pra jacu)


O objetivo da apresentação, totalmente cercada por exemplos práticos (e a frase de título foi devido aos exemplos usando classes com o nome “Pica-pau”), era conhecer por dentro a metaprogramação e como ela realmente funciona  dentro da linguagem Ruby. Ambos os palestrantes demonstraram o porque não é um bicho de “sete cabeças” mesmo…rs.

Primeiramente, a definição da Wikipedia para metaprogramação é complicada:

“Metaprogramação é a programação de programas que escrevem ou manipulam outros programas (ou a si próprios) assim como seus dados, ou que fazem parte do trabalho em tempo de compilação.”

O correto seria : Metaprogramação é escrever código que escreve/gera código. Assim fica mais claro (!).

Em Ruby é totalmente aceitável aproveitar as open classes, ou seja, a facilidade que a linguagem dá pra mudar o comportamento de objetos em tempo de execução, ao contrário de outras linguagens (Java e C#, por exemplo). Mas, usar e abusar disso não é legal: deve ser feito com responsabilidade e a medida que for necessário usar, sempre com comprometimento e responsabilidade.

Na apresentação as demos mostradas eram exemplos práticos dos mais variados assuntos: eu realmente posso adicionar um método a um objeto? onde o método fica? que tipo de objeto pode definir métodos? Métodos são adicionados em classes ou objetos?

E para complementar o assunto houveram definições de Singleton Class, Metaclass e EigenClass. Apesar de ser um assunto fora do meu conhecimento, consegui “pescar” alguns conceitos. 🙂

Abaixo o vídeo da palestra, gravado pelo Agaelebe:

[blip.tv ?posts_id=3728666&dest=-1]

E a apresentação no Slideshare:

Hugo Baraúna – Keynote: O que há de novo no Rails 3?


Hugo Baraúna, desenvolvedor Ruby/Rails há 3 anos na Plataforma Tecnologia (empresa focada em projetos/coaching em Rails, onde trabalha também José Valim, core Rails), trouxe um overview acerca das novidades do Rails 3, a ser lançado no segundo semestre de 2010. A maioria das informações se encontram no RailsGuides.

Abaixo os pontos, informações e mudanças mais importantes:

Para quem estiver interessado,  a Plataforma mantém um profile no GitHub com alguns projetos relacionados a Rails 3. Abaixo 2 deles:

  • Mail Form: “Send e-mail straight from forms in Rails with I18n, validations, attachments and request information”;
  • Responders: “A set of Rails 3 responders to dry up your application”.

Abaixo o vídeo da palestra, gravado pelo Agaelebe:

[blip.tv ?posts_id=3721460&dest=-1]

E os slides presentes no Slideshare:

Marcelo Castellani – Rhodes, um framework para o desenvolvimento de aplicações nativas para smartphones usando Ruby


Essa para mim era uma das principais palestras do evento, pois já tinha ouvido falar dessa ferramenta (além do Titanium, que é open source também), para construção de aplicativos para dispositivos mobile (leia-se smartphones) multiplataforma.

O mercado mobile é muito promissor e já é uma realidade, fato. Há perspectivas para que no ano que vem existam mais acessos a internet pelo celular do que pelo Desktop (leia uma das fontes da notícia aqui). Portanto, conhecer e dominar técnicas de escrita de aplicativos para o mundo mobile, e não só para Desktop ou Web, é necessário.

Abaixo uma listagem das features do Rhodes, citadas pelo Castellani na apresentação:

  • Faz parte da “família Rhomobile“, composta pelo Rhodes, RhoSync e Rhohub;
  • Suporte a Iphone OS, Android, Blackberry, Symbian e Windows Mobile. Ou seja, praticamente 95% do mercado;
  • As aplicações são nativas mesmo, para cada plataforma. Não há aplicações web rodando por baixo e mascaradas;
  • O Rhodes possibilita a criação de aplicativos de celular com linguagem Ruby, ou seja, existe ganho de produtividade;
  • A API é bem extensa para todos tipos de celulares;
  • Rhodes é open source 🙂 ;
  • Como vantagens podemos citar uns dos lemas do Java 😉 : Write once, Run everywhere;
  • Há abstração de hardware (não há necessidade de saber a arquitetura física do celular);
  • RhoSync é pago 😦
  • RhoHub tem um plano Free e outros pagos 😦
  • Programa interessante para análise: Pivotal Tracker (Traker-r);
  • Instalação: gem install rhodes / rhodes-setup.  “Very easy” 😉
  • Atenção: o interpretador de Ruby do Rhodes é um subset do Ruby 1.9, portanto não há algumas funcionalidades da linguagem;
  • A parte de persistência é feita através do Rhom: é um mini object mapper disponível no Rhodes (como se fosse um Active Record);
  • É possível criar splash screen (tela de carregamento da aplicação), páginas de tratamento de erro, pode-se definir arquivos específicos por plataforma, usar GPS, câmera, etc;
  • Para usar GPS na aplicação é preciso implementar Ajax. A plataforma Blackberry é a única que não suporta Ajax;
  • Existe uma biblioteca para implementação de testes: Mspec;
  • Licença: livre para aplicativos open source; 1000 dólares para aplicativos que forem cobrados.

Castellani tinha uma hora para apresentar e terminou em 45 minutos (!). Ao final muitas perguntas foram feitas e o pessoal realmente achou o assunto interessante!

A apresentação no Slideshare se encontra abaixo:

E o vídeo da palestra no blip.tv:

[blip.tv ?posts_id=3730009&dest=-1]

Anderson Leite – BDD e Cucumber


Antes de iniciar a sua palestra (e após um longo hiato de espera onde o pessoal dispersou…), Anderson Leite informou ao público que a nova reunião do GURU-SP está marcada previamente para o dia 26/06/10. Mas a data pode ser alterada (pois já existem outros eventos oficiais marcados, como o Agile Brazil e o Profissão Java, por exemplo).

A respeito da palestra, a mesma se centrou em 3 pontos: BDD, Cucumber e Cobertura de testes.

A idéia central é que um software deve ter testes, e devem estar de acordo com a visão do cliente, com o comportamento do software e daquilo que pode ser útil/com finalidade. É sabido que cerca de 80% de um software não é usado pelo cliente final.

Para nos auxiliar a fazer aplicações de valor (usando Ruby) a implementação dos conceitos de BDD se torna necessária. Algumas informações adicionais:

  • Livros indicados para leitura: The RSpec Book e Domain Driven Design;
  • Frameworks de teste baseados em BDD necessitam de uma linguagem de domínio;
  • A linguagem de domínio no BDD deve ser baseada na visão dos stakeholders;
  • No BDD faça o suficiente. Sempre entregue de valor real. Tudo é comportamento. Prefira algo “sem papelada”.

O Cucumber é uma ferramenta para a linguagem Ruby, baseada em BDD, que dificulta a perda de informação acerca de um domínio entre cliente, desenvolvedor e testadores. O Anderson fez alguns exemplos práticos, mostrando cenários de teste, mas para não “chover no molhado” nesse post e colocar informação repetida, eu indico algumas referências para o aprendizado:

Para encerrar ele indicou um projeto para cobertura de testes: relevance-rcov.

E lembre-se: escrever código sem testes é uma #putafaltadesacanagem

Abaixo a apresentação no Slideshare:

E o vídeo no blip.tv:

[blip.tv ?posts_id=3737359&dest=-1]

Cassio Marques – Refatorando Ruby – Técnicas de Orientação a Objetos e Design Patterns Aplicados a Linguagens Dinâmicas


Essa foi a última palestra do evento, ufa! Mas não é aquele “ufa!” de “putz, não vai acabar essa joça não…”, pelo contrário: essa não foi aquela palestra que você não vê a hora de terminar para ir embora. Cassio Marques segurou o público até o final com um tema muito bom e de grande interesse do pessoal, inclusive o meu!

Para explicar e pensar no assunto precisamos responder algumas perguntas como: O que é refatorar um código? Porque mexer no código? Se o código está funcionando porque vou mexer??

As motivações, ou melhor, razão para refatoração em código são muitas:

  • Muitas pessoas usam Ruby mas não sabem orientar a objeto (ainda tem dúvidas do paradigma Procedural x OO);
  • Raciocínio estático;
  • Uso de linguagem nova mas usando hábitos antigos;
  • Organização de código;
  • Modularizar o código;
  • Facilitar manutenção e compreensão do código.

E quais as motivações para usar Design Patterns:

  • Ajuda Ruby a ser “Enterprise”;
  • YAGNI” (eu não conhecia esse termo não…rs!).

E não esquecendo de que escrever, ter uma suíte de testes escritos e uma cobertura de testes é necessário pra verificar uma refatoração.

As dicas sobre refatoração foram:

  • Mantenha seus métodos pequenos e facilitando compreensão e coesão;
  • Dê nome aos parâmetros dos métodos;
  • Uma classe não deve realizar trabalhos que não estejam relacionadas a ela! Tenha coesão;
  • Substitua “números mágicos” por constantes;
  • Encapsule variáveis/propriedades de objeto (como getters e setters do Java);
  • Substitua condicionais por polimorfismo;
  • Simplifique expressões condicionais;
  • Padrões que valem ser estudados para Ruby: Command, Strategy, Delegation.

Abaixo a palestra, disponibilizada pelo Cassio Marques. Deixo meus parabéns para o mesmo pela apresentação e responsabilidade de fechar o evento!

O vídeo gravado e disponibilizado no blip.tv pelo Hugo Borges (@agaelebe) está abaixo:

[blip.tv ?posts_id=3737667&dest=-1]

Conclusão

O evento superou minhas expectativas? De certo modo não, de certo modo sim…(momento Cléber Machado…rs). Se eu fosse comparar com o evento do ano passado, na minha concepção, a grade de palestras do ano passado foi melhor. Esse ano o nível de palestras foi bom (nota 7). O diferencial, sem dúvida, foi a interação do pessoal, que fez muito mais networking e estava muito mais ativo em relação ao ano passado, junto com o aumento do número de patrocinadores e estandes de empresa no local.

Na minha concepção:

Pontos negativos

  • Coffee break fraco;
  • Wi-Fi muito lento e instável. Ano passado não houve disponibilidade de sinal, e esse ano foi praticamente se não tivesse também;
  • Tela de projeção muito baixa, dificultando visão do pessoal do fundo da sala;
  • Houve um hiato muito grande entre a palestra do Castellani e do Anderson, fora o sorteio e o problema do datashow. Nesse momento o pessoal dispersou no “fundão” do local…

Pontos positivos

  • Boa localização
  • Fabrício Campos foi sorteado e ganhou uma mochila da Localweb com alguns brindes dentro! 🙂

Para aqueles que queiram ver fotos do evento, vejam os links abaixo:

E quem quiser acompanhar os tweets do evento:

O Ricardo Almeida escreveu um post no site #horaextra, contendo as apresentações e vídeos das palestras.

Bem, acredito que seja isso que eu queria passar. Espero que vocês tenham gostado da cobertura e conforme as palestras, ou informações adicionais, forem liberadas eu atualizo o post.

Nos vemos no Ruby+Rails no mundo real 2011 e viva a comunidade Ruby em Sampa!

Até mais!

Anúncios

Apresentação sobre “Os seis chapéus do pensamento”

No 8º encontro do GURU-SP, no qual estive presente e hei de escrever um report, aprendi acerca do assunto “os seis chapéus do pensamento”, via Rafael Rosa. Fiquei empolgado com o assunto e além de fazer a aquisição do livro (coisa que o Rafael  não indicou, mas fiz mesmo assim…rs) montei uma apresentação para repassar o conteúdo pro pessoal da empresa onde trabalho (Voice Technology). Abaixo coloco o link da apresentação no slideshare:

Caros leitores: qualquer opinião ou dúvida fiquem a vontade para falar!

P.S. : Fiz a apresentação há 3 horas atrás e o pessoal gostou bastante do conteúdo! A idéia de fazer mais lightning talks na empresa, aparentemente, foi bem aceita e com bom público. Só queria deixar o agradecimento, novamente, ao Rafael Rosa pela “luz”!

[DIVULGAÇÃO] – 8º Encontro do Grupo de Usuários Ruby de SP (GURU-SP)

Divulgo para os interessadas em tecnologias relacionadas a Ruby e Rails mais um evento/reunião/encontro gratuito que acontecerá no dia 10/04/10. Será o 8º Encontro do Grupo de Usuários Ruby de SP (GURU-SP). Para mais informações confiram abaixo a notícia retirada do InfoQ.

O Grupo de Usuários Ruby de São Paulo (GURU-SP) fará mais um encontro no dia 10/04(sábado). Esse será o último encontro do grupo antes do evento Ruby on Rails no mundo Real.

O encontro contará com duas palestras de 40 minutos que serão divulgadas em breve e dessa vez será aberto um espaço para Lightning Talks de 5-10 minutos. É uma oportunidade interessante para você mostrar para a comunidade algum projeto, biblioteca, site relacionado com Ruby que tenha feito.

Esse é o oitavo encontro do grupo, para conferir como foram os anteriores acesse a wiki do GURU_SP.

A empresa Surgeworks já confirmou também apoio e fornecerá o coffe break.

Se sua empresa também quiser colaborar com o crescimento da comunidade Ruby e pode contribuir com algo, deixe um comentário que entraremos em contato.

Local:

O encontro será realizado no auditório da Caelum, próximo ao metrô Vila Mariana.

Rua Vergueiro, 3187, cj 84

Ao lado do metrô Vila Mariana

Mapa

Inscrição:

Para participar do encontro basta colocar seu nome no formulário.

O encontro deve ir até 13:00 e depois teremos o famoso #HoraExtra para socializar e confraternizar.

Se tiverem dúvidas, deixem comentários aqui no post ou entrem no grupo de discussão do Guru-SP ou no site oficial do grupo.

Nomeie as coisas corretamente

Esse post é essencial e de grande valia em termos de reflexão de como o programador inexperiente, até os mais experientes, devem tomar cuidado e seguir a risca a escrita de código com coesão, em termos de lisura e entendimento de variáveis, métodos e clareza de informações.

O texto abaixo está na íntegra e foi redigido por Daniel Lopes, retirado do blog AreaCriações. Daniel Lopes ministra cursos de Ruby/Rails pela E-Genial; um companheiro de empresa está fazendo o curso “Ruby on Rails – do básico ao avançado” e está gostando, portanto é indicado para os interessados em aprender mais sobre essa nova linguagem/framework de desenvolvimento Web.

Boa Leitura a todos!

Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.

Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Mas é o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.

Tenho dedicado boa parte do meu em treinamentos, sejam pela eGenial ou para equipes em empresas. No ano passado participei de treinamentos com mais de 100 pessoas e só no começo deste ano foram mais quase 100.

Treinar tanta gente é uma experiência fantástica pois em nenhum emprego eu poderia ver o fonte de tantas pessoas, conhecer tantos problemas diferentes e aprender com os erros dos outros e propor soluções antes mesmo que aconteçam comigo.

Mas uma coisa tem me assustado muito: NOMES. Pensar no nome dos seus métodos e classes é tão importante quanto fazer o código funcionar. E se a nomenclatura que você adotou não é boa, eu considero o código errado! Este é tipo de coisa que não é ensinada em faculdades, mas deveriam ser.

Hoje vivemos em um mundo de desenvolvimento orientado a objetos. Mas qual é o objetivo de OOP? Simular o mundo real através do código, não é atoa que a primeira linguagem OO se chama Simula.

Então, o primeiro fator que considero para desenvolver OO corretamente é como você deve nomear e simular o mundo real através do seu código.

Mas como nomear corretamente as coisas?

A funcionalidade do Rails que acho mais fantástica é a preocupação de manter a característica do Ruby de ser legível. Temos métodos como validates_presence_of ou has_and_belongs_to_many ao invés de apenas vpo ou has_blg. Esta preocupação fica mais clara ainda se pensarmos nas tabelas, models e controllers.

Tabelas no Rails praticamente só servem para persistir objetos (reparem: objetos no plural) por isso elas são nomeadas no plural (customers, transactions, teachers, etc) enquanto a classe, que criará uma instância por vez, é nomeada no singular (Customer, Transaction, Teacher).

Métodos são operações que o objeto pode realizar, logo devem ser ações como calculate, find, sum enquanto propriedades/atributos são características do objeto que consequentemente devem ser nomeadas como tal. Seus accessors devem ter nomes de propriedades como name, age, value e etc. Se existe uma variável que é um verbo/ação então simplesmente seu código está errado e não tem significado como um objeto.

Já sabemos como nomear tabelas, classes e como a prática do Rails é muito boa para manter o código legível. Mas o que são controllers?

Um controller é uma forma de expor ao mundo os seus objetos do sistema e ao pensar como organizar seu controllers você deve ter isto em mente (por isto o Rails é REST e não apenas para expor uma API qualquer). Suas actions do controller devem ser ações mesmo, ações que vão ser executadas em seus objetos para poder mostrá-los ao mundo.

Se você tem uma action chamada “calculos” o nome simplesmente está errado, isto não é uma ação. Se você pensar em um controller como expositor de seus models com views então o método “calculos” está até no local errado, ele deveria estar dentro do model de BankAccount por exemplo e o controller apenas obtém o valor retornado pela ação calculate de um objeto da classe BankAccount. Neste exemplo a preocupação com nomes nos ajuda a colocar os métodos nos locais corretos criando uma boa arquitetura.

Código deve ser legível mesmo quando o sistema se tornar legado.

Qualquer sistema se torna legado, mesmo ele sendo escrito em Rails 3.0beta hoje, daqui a uma semana ele é legado e você não se lembrará de boa parte do que foi escrito lá.

Um desenvolvedor é um escritor e seu código (principalmente em Ruby) são frases que dizem o que deve acontecer. Se você não nomear seus métodos, objetos e variáveis da forma correta mais cedo ou mais tarde nem mesmo você entenderá um código que escreveu (experiência própria) quanto mais outro desenvolvedor.

Outro fator que destrói a legibilidade são os resumos. Um helper como options_for_select que cria options para um select do html poderia ser resumido para opt_select ou has_many poderia ser h_many. Mas estes resumos são extremamente prejudiciais e tornam o fonte impossível de ler futuramente.

Então sempre escreva o fonte como um manual e pensando em outra pessoa que venha a le-lo ao invés de pensar em você mesmo. Isto evitará o problema acima e mesmo daqui a 1 ano você voltará no código e entenderá tudo na primeira leitura.

Por que escrever fonte em Português é péssimo?

Nos treinamentos percebo que muita gente tenta escrever código Ruby em Português. O grande problema disto é que você terá algo assim: Pessoa.find_all_by_nome. Se você pensar em seu código como um simulador do mundo real que apenas contem instruções de como as coisas devem acontecer está óbvio que o seu simulador está “manco”.

Pessoa.find_all_by_nome não diz nada nem em Português e nem em Inglês. Logo é uma falha de arquitetura, e principalmente em Ruby, seu código acabou de perder a legibilidade da linguagem, que o Rails mantém e você acabou de destruir.

Como é impossível escrever tudo em Português então evite escrever qualquer coisa em Português. Desta forma você não terá um simulador “manco” que não descreve nada em linguagem nenhuma. Claro, termo técnico ou da regra de negócio como CPF, CNPJ e outros devem ser mantidos em Português ou na linguagem que for mas outras coisas como enturmação em uma rede social de alunos deveria ser representado como membership. Caso contrário você terá uma bizarrice como está:

class Estudante < ActiveRecord::Base
  has_and_belongs_to_many :enturmacoes
end

ao invés de

class Student < ActiveRecord::Base
  has_and_belongs_to_many :memberships
end

Evitando este tipo de arquitetura ruim: Estudante.first.enturmacoes.all(:conditions=>…). Ao ler esta frase (isto deveria ser uma frase) não existe nenhum significado em Português e nem em idioma algum, logo você tem um erro de nomenclatura e seu simulador do mundo real está manco, não representa a realidade e mais cedo ou mais tarde você estará dando manutenção em um sistema que apenas você entende.

Por favor não me venha dizer que é patriota e que o idioma do seu país é Português. Se você pensa assim deveria escrever class em japonês ao invés de Inglês já que o Ruby é uma linguagem Japonesa. Seu código é escrito para os outros e a única garantia que qualquer pessoa entenderá é escrevendo-o semanticamente correto e como a linguagem de programação já é em Inglês escreva-o em Inglês.

Também não existe problema algum se seu Inglês não é fluente. Tenha um dicionário a mão e tudo estará resolvido.

Conclusão

Não tenho vergonha em dizer que escrevi vários sistemas de 4 ou 5 anos atrás que por não ter seguido uma boa arquitetura o código é terrível e de difícil leitura. E pensando em arquitetura que me apaixonei por Ruby e consequentemente Rails, com eles é simples escrever um código que será fácil de ler mesmo daqui a 3 anos.

É sua obrigação fazer o código funcionar mas também é sua obrigação subdividir seus arquivos em pastas que fazem sentido, criar classes, templates e escrever código semanticamente correto, como um livro. Isto tudo é arquitetura do projeto e não apenas frescura, é preocupação com manutenção futura.

Esta regra o ajudará a identificar o que são método, o que são variáveis, objetos e onde colocar estas coisas.

Então pense 2 ou 3 vezes antes de escrever um método ou classe e não tenha vergonha em gastar mais horas do seu dia pensando em como organizar seus models e controllers do que escrevendo dezenas de linhas de código.

Minhas impressões – 7º Encontro do Grupo de Usuários Ruby de SP (GURU-SP) – 13/03/10

Caros colegas,

Na manhã de hoje estive participando do 7º Encontro do Grupo de Usuários Ruby de SP (GURU-SP), ocorrido em um auditório “próximo ao metro Santa Cruz” (mais abaixo a explicação), conseguido pelo pessoal da Caelum (via Anderson Leite), na Vila Mariana. Abaixo vou relatar as minhas impressões do evento.


Introdução e Panorama

Esse foi mais um dos sábados que pensei: poxa, poderia estar dormindo e descansando, aproveitando pra acordar tarde…Mas não, mais uma vez acordei as 7h00 rumo a mais um encontro de usuários Ruby (vai ser Nerd assim longe viu!… 🙂 ). No final, perder “alguns” fins de semana de vez em quando vale a pena: a busca pelo conhecimento é indescritível!

“Viagens” a parte, vamos ao que interessa !

Não tive muitas dificuldades para localizar o local, tirando a caminhada de 1100 números do início da rua até o prédio (onde ficava o auditório do encontro) + 150/200 metros da Avenida da saída do metrô (20~25 minutos de caminhada com notebook nas costas…). Na chegada ao local não tive dificuldades para encontrar o auditório e me instalar. Poucas pessoas estavam presentes até aquele momento, mas as instalações já estavam OK. No evento, como um todo, estiveram presentes cerca de 25 a 30 pessoas, que no final acabou ficando na média dos encontros do grupo.

O cronograma para o encontro era:

  • Palestra1: Por que Vim? – Willian Molinari (a.k.a PotHix);
  • Palestra2: HPricot – Jonas Alves;
  • Bate papo sobre as novidades do GURU-SP.

Abaixo um resumo sobre os tópicos anteriormente listados.

Palestra 1: Por que Vim? – Willian Molinari (a.k.a PotHix)

Willian Molinari nessa palestra mostrou ao público um pouco sobre esse tão famoso editor, que muitos conhecem mas poucos sabem usar de forma avançada, muito pelas “dificuldades” de adaptação (desmistificadas na apresentação). Pelo menos eu gosto do conceito do Vim e acho o mesmo muito interessante (!). A apresentação subdividiu-se nos seguintes pontos:

  • Filosofia de programação no Vim;
  • Comandos básicos;
  • Modos de edição;
  • Qual o melhor modo de usar;
  • Como customizar;
  • Killer commands;
  • Bons plugins para desenvolver com facilidade (em Ruby, é claro 🙂 );
  • Principais  vantagens/desvantagens.

Abaixo as informações mais importantes:

  • Existem 4 modos de edição no Vim: visual, inserção, comandos, normal;
  • Em qualquer modo existem variação de abrangência/ação quando usam-se comandos com letras minúsculas ou maiúsculas;
  • Modo visual – comandos disponíveis: “V” (para selecionar linhas) ou “v” (para selecionar caracteres);
  • Modo inserção – “i”, “a”, “o” ou “I”, “A”, “O” (escrever caracteres antes, depois ou na próxima linha, respectivamente);
  • Modo de comandos:

1 –  ” :! ” : permite executar comandos do terminal, como “ls”, “grep”;
2 – “:set wrap” (quebra a linha) e “:set nowrap” (não quebra as linhas);
3 – “:%s/arg1/arg2/g” : substitui o argumento1 pelo argumento2 em todo documento;
4 – “:w!” : salva e sai do arquivo;
5 – “:q!” : sai do arquivo e não salva mudanças;
6 – “:wqa” : sai e salva todos os arquivos abertos no Vim;
7 – “ZZ” : famoso “Zalva e Zai” (o mesmo que “:wqa”).

  • Modo normal:

1 – Navegação e busca de palavras em arquivos: “?” e “/”;
2 – Uso de setas de navegação: “h”, “j”, “k” e “l”;
3 – Navegação entre palavras: “w”, “e”, e “b”;
4 – Navegação entre começo e fim de linha: “0”, “^” e “$”;
5 – Motions: “f”(ind) e “t”(o) + um caracter de uma palavra para onde queira ir;
6 – Alteração: “yy”(ank) e “p”(aste), vulgo “copiar e colar”;

  • Vim tem suporte a “buffer de arquivos”: pode-se abrir mais de um arquivo e usa-se o “ls” para escolher o arquivo (bufExplorer) ;
  • Vertical split (“Vs”), Horizontal split (“:split”), Tab (“:T”) e Macros (“q”, “@” e “@@”) são tópicos avançados e poderosos;

Abaixo estão listados os plugins mais interessantes para os programadores Ruby que usam Vim, todos acessíveis via vim.org:

Outros plugins (diversos): vimpress, ragtag, endwise, IndexedSearch.

Fontes de estudo? Acesse os Vimcasts. Leia o Vimbook. Estude arquivos  “.vimrc” (arquivo de configuração do Vim. O Molinari oferece o próprio arquivo para download na página do GitHub dele). Acompanhe as dicas do @vimtips no Twitter. Leia o VimTutor.

Observações: Saiba que não será fácil aprender Vim! Portanto estude, pratique e treine sua digitação, pois os resultados só vem na prática.

Ufa! Só ficou faltando o link para a apresentação do Molinari. Caso seja disponibilizada, depois irei atualizar essa parte do post.

[Atualizado em 14-03-10 – Eis o link da apresentação do PotHix: http://bit.ly/95aqmI].

[Atualizado em 15-03-10 – Eis o link do vídeo gravado pelo Hugo Borges da apresentação do Willian Molinari: http://blip.tv/file/3347875]

Parada para coffee break agora! Hora do networking e aguardo para a próxima palestra…

Palestra2: HPricot – Jonas Alves


Jonas Alves trabalha na WebGoal a 1 ano e é rubista desde 2008. Trouxe a público o seguinte cenário, para exemplificar a sua apresentação: um cliente precisava coletar dados da internet, mas isso era feito manualmente e demandava muito tempo e esforço, e a qualidade das informações poderiam ser comprometidas por erros humanos. Era preciso automatizar o processo. Eles testaram as seguintes ferramentas:

  • PHP: DOMDocument (problema: limitado);
  • Java: HTMLParser (problema: muito verboso);
  • Ruby: HPricot (solução[!]: código limpo e mais fácil de usar).

De todas as opções, o Hpricot se destacou pelo seu poder e simplicidade de uso na extração de dados de websites, por meio de divs. A extração de dados da página fica muito mais fácil com o uso do plugin Firebug, para Firefox.

Fora esses pontos, a apresentação seguiu-se com uma demonstração de como construir um extrator de dados de um blog com Hpricot. Jonas disponibilizou os arquivos da apresentação e da demo em sua página do GitHub.

Eu, durante a apresentação, achei outro exemplo interessante para complementar a informação passada: http://www.lednerd.com/2007/04/20/extraindo-dados-com-ruby-e-hpricote/

Fora isso só achei o palestrante um pouco nervoso durante as explicações, mas no final deu tudo certo. Parabéns ao mesmo pelo conteúdo passado!

[Atualizado em 15-03-10 – Eis o link do vídeo gravado pelo Hugo Borges da apresentação do Jonas Alves: http://agaelebe.blip.tv/file/3348060/]

Hugo Borges – Bate papo sobre as novidades do GURU-SP


Hugo Borges passou os informativos sobre as discussões que estão ocorrendo entre os membros do grupo, visando um melhor planejamento e periodicidade das atividades. E as novidades são:

  • Encontros mensais – agora acontecem uma vez a cada 4 semanas, com duração de 3 a 5 horas. Dois encontros já estão confirmados: 03/04 e 01/05, na Caelum;
  • Existe um arquivo público para os interessados discutirem os formatos dos encontros. Acessem: http://bit.ly/gurusp7;
  • Os formatos dos encontros podem conter: palestras, mesas redondas , dojos, projetos, horas extra, etc;
  • Os projetos atuais do grupo são: tradução do RubyLearning (Hugo Borges é o líder) e tradução da Rails Magazine (Anderson Leite é o líder e estou participando 🙂 ). Em futuro próximo poderão existir projetos de gems, jogos, contribuições em outros projetos, plugins, etc;
  • Próximo evento: Ruby + Rails no mundo real 2010;
  • Desconto na compra de livros da editora O’Reilly com código do GURU-SP (“DSUG”): 35% na compra de livros impressos e 45% em e-books;
  • Palestras não aprovadas para o Ruby + Rails no mundo real 2010 serão apresentadas nos próximos encontros do grupo. É importante frisar que as duas palestras desse encontro fazem parte das não aprovadas para o evento de Maio (não por falta de qualidade, é lógico!).

Conclusão

O encontro começou as 9h00 e terminou perto das 12h30, antes do esperado, mas cumprindo o cronograma. Após isso houve a #horaextra, onde o pessoal sai para o almoço e beber alguma coisa, tudo regado a Ruby/Rails, troca de idéias e networking, é claro.

Tenho alguns prós e contras para adicionar:

Prós:

  • Infra-estrutura boa (wifi, tomadas, ar condicionado, água e café);
  • Os assuntos abordados em ambas as palestras não foram de cunho “avançado”, portanto tanto os mais experientes quanto os inexperientes puderam aproveitar.

Contras:

  • Não é “próximo ao metro Santa Cruz” (para os que se locomovem com transporte público);
  • O projetor multimídia, infelizmente, atuou no modo “preto e branco” em ambas apresentações, prejudicando a visualização dos códigos.

Bom, acredito que seja isso. Caso qualquer informação nova venha a surgir atualizo o post.

Até mais!

[DIVULGAÇÃO] – 7º Encontro do Grupo de Usuários Ruby de SP (GURU-SP)

Divulgo para os interessadas em tecnologias relacionadas a Ruby e Rails um evento/reunião/encontro que acontecerá no dia 13/03/10 aqui em São Paulo. Será o 7º Encontro do Grupo de Usuários Ruby de SP (GURU-SP). E o melhor: será gratuito!

Interessado? Já ouviu falar do grupo? Tem interesse em aprender mais sobre Ruby e Rails? Quer fazer networking?

Então atente-se as informações abaixo, que foram retiradas da lista de discussão do GURU-SP (http://groups.google.com.br/group/ruby-sp).

Fala pessoal.
Confirmado encontro dia 13!

O local será um auditório próximo ao metro Santa Cruz, conseguido pela Caelum.

Local:
Rua Dr. Diogo de Faria, 1201 Vila Mariana
Próximo ao metro Santa Cruz
Mapa: http://tinyurl.com/ya2mxma

Horário: 9hrs até o #horaextra depois!

Quem for, basta por o nome nessa planilha => http://tinyurl.com/yb3jmay

Teremos ainda duas palestras:

Palestra: Por que Vim?
Pothix (Willian Molinari)
Descrição: Nessa palestra eu pretendo mostrar um pouco sobre esse editor, filosofia, comandos básicos, modos de edição, qual o melhor modo de usar, como customizar, killer commands, bons plugins para desenvolver com facilidade e principais  vantagens/desvantagens.

Palestra: HPricot
Jonas Alves
Descrição: Coletar dados da internet manualmente demanda muito tempo e esforço, e a qualidade das informações podem ser comprometidas por erros humanos. Testamos ferramentas em PHP, Java, C++, C# e Ruby. De todas as opções, o Hpricot se destacou pelo seu poder e simplicidade de uso na extração de dados de websites. Na apresentação mostraremos como construir um extrator de dados de
vários sites com Hpricot.

Não esquece de colocar seu nome => http://tinyurl.com/yb3jmay

Divulguem e compareçam!

Eu estarei presente e espero você lá!

Referências sobre BDD – artigos para leitura

Para os interessados em aprender e entender o que é BDD, conhecer os conceitos essenciais dessa prática ágil, indico dois posts que li nesse dia de hoje, referências boas para quem busca respostas iniciais sobre assunto. Eis os links abaixo:

Ferramentas para BDD

Procurando por ferramentas para aplicar BDD?

Se você programa em Java pode usar um framework chamado JBehave. No site do projeto há um tutorial de 2 minutos (!) explicando o uso da ferramenta. Vale a pena dar uma passada por lá.

Se programa em Ruby use o framework Cucumber. O próprio site do projeto é bem completo e com muitas referências, inclusive para livros (o principal: “The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends”).

Caso eu encontre outras referências do assunto, estarei colocando no blog a medida do possível.

Até mais e bons estudos!