Quarta, 14 de outubro, aconteceu o segundo e último dia do Rails Summit Latin America 2009, o maior evento das comunidades Ruby e Ruby on Rails da América Latina.
Todos os palestrantes do Rails Summit Latin America 2009 por Daniel Cukier
Vamos às palestras.
Richard Kilmer: MacRuby + HotCocoa
Richard Kilmer mostrou como o MacRuby e o HotCocoa podem simplificar o desenvolvimento para aplicações que rodam no Mac OS X. Ele disse que alguns objetivos da Apple são fazer o Mac OS X a melhor plataforma para desenvolvimento em Ruby e tornar Ruby a principal linguagem de programação para o framework Cocoa.
Ele explicou que com a utilização de RubyCocoa há o processo do Ruby rodando de um lado que conversa com o runtime do Objective-C, sendo assim há dois garbage collectors. Além disso, a sintaxe do RubyCocoa, adaptada do Objective-C é um tanto “odd”, quando se diz respeito a selectors do Objective-C.
Já com MacRuby, a sintaxe usando hashs nos parâmetros dos selectors ficam mais claras. Em geral, a sintaxe fica muito mais simplificada que a sintaxe que Objective-C. O MacRuby unifica o modelo de objetos de Ruby e Objective-C, tudo que é objeto no Ruby é objeto no Objective-C.
Com a versão 0.5 doMacRuby haverá uma nova máquina virtual chamada LLVM (Low Level Virtual Machine), que compila código Objective-C. Todas as características dinâmicas do Ruby iram rodar com melhor performance.
Richard por fim exemplificou como o HotCocoa simplifica o uso de recursos de Objective-C utilizando MacRuby. Foi mostrado um exemplo de código com e sem HotCocoa e a quantidade de código que se reduziu o programa foi incrível. Você consegue criar janelas, botões e outros controles com ele usando poucas linhas de código.
O vídeo da apresentação você pode assistir aqui e os slides da apresentação você pode visualizar aqui.
Carlos Villela: Ruby na ThoughtWorks
Carlos Villela fez sua apresentação baseada no artigo Ruby at ThoughtWorks publicado por Martin Fowler. Ele disse que a ThoughtWorks é pioneira em desenvolvimento ágil e que possui em torno de 42 projetos em Ruby espalhados pelo mundo. Na Inglaterra, a adoção de Ruby demorou um pouco em relação a outros países. A grande maioria dos projetos em Ruby aconteceram nos EUA.
Em uma pesquisa interna, foi perguntado se Ruby foi uma boa escolha? A maioria respondeu que sim e que Ruby era mais produtivo realmente, sendo que 13 dos 42 projetos acharam que a produtividade dobrou. Mas 5 disseram que não foi uma boa escolha, onde 4 dos 5 disseram que havia uma curva de aprendizado que não cabia no projeto.
Quanto a performance nenhum projeto teve problema.
Também foi pergunta na pesquisa se Ruby é difícil de entender? Existe muita coisa nova em relação a outras linguagens comerciais e há, além da curva de aprendizado, a curva de manutenção. Quando mais você usa meta-programação você acha que é óbvio e bom, mas excesso de meta-programação não é um bom sinal.
Ele disse que muitas vezes a plataforma Ruby não é viável por conta do ambiente da empresa, e enfatizou que Ruby não é uma solução para tudo.
No final da palestra ele apresentou algumas dicas:
- Controllers magros, modelos cheios, mas não ter toda a lógica do sistema, somente o que for lógica de negócio.
- Testes com ActiveRecord falando com banco de dados de verdade, sem usar stubs.
- Exposição de SQL no AcitveRecord: muitas vezes é inevitável.
- Requisições de longa duração: uso de filas quando possível e um módulo separado do Apache que não roda no Rails (gambi?).
- Controle de Gems: tomar cuidado para uma atualização de gem não quebrar o que está funcionando.
- Atualizações: pode quebrar seu código, não demore muito para atualizar suas gems.
- Desenvolvimento no Windows: não rola, rodar em produção é viagem, desenvolver no Windows dá, mas não vale a pena.
- Não se empolgue tanto com plug-ins: confira se o plug-in tem um mínimo de qualidade, não saia instalando tudo quanto é plug-in no seu projeto, planeje bem isso para não criar um monte de dependências.
O vídeo da apresentação você pode assistir aqui.
Nando Vieira: O que mudou no Ruby 1.9
Nando Vieira
por Levy Carneiro
Nando Vieira mostrou as diferenças da nova versão do Ruby e deu dicas para uma futura migração do seu código atual.
Os slides da apresentação você pode visualizar aqui.
Pratik Naik: Lessons Learnt in 2009
Pratik Naik
por Levy Carneiro
Eu não assisti a palestra do Pratik Naik. De acordo com Herbert Fischer, problemas como posicionamento de microfone e slides com fontes pequenas atrapalharam um pouco.
De qualquer forma, o vídeo da apresentação você pode assistir aqui.
Marcos Tapajós: CouchDB no Rails
Marcos Tapajós iniciou apresentando alguns recursos e características do CouchDB:
- Orientado a documentos: no CouchDB um documento nada mais é do que um JSON.
- Há uma maior flexibilidade, pois não há esquema definido.
- Se quiser colocar mais um campo, vai lá no JSON e acrescenta, não precisa alterar o banco de dados.
- A comunicaçào com o banco é feito por REST.
- Todos os documentos armazenados no banco são versionados. Todas as operações que você faz no banco, é criada uma nova versão.
- Há um rotina de manutenção para eliminar as versões de documentos anteriores, com um gerenciador de conflitos.
- É legal você quebrar os documentos de uma forma que você evite a possibilidade de conflitos. Acaba sendo uma sutileza, não porque o documento vai ficar grande.
- As consultas no CouchDB são feitas através de views, utilizando o conceito de map reduce.
- É possível fazer replicação bidirecional no CouchDB. Essa replicação fica consistente por conta do versionamento de documentos.
- A replicação traz uma grande vantagem de você ter uma aplicação offline, que pode ser sincronizada com outra base que funciona como Master. Funciona mais ou menos como no Git, onde você tem um repositório local e vai sincronizando com o repositório remoto.
- É possível gravar arquivos binários (doc, pdf, jpg, etc) como “attachments”. Nas consultas você não trafega os anexos, a não ser que você especifique isso quando quiser trazer o arquivo.
Depois ele falou que o casamento entre o CouchDB e o Ruby é muito bom. Você pode pegar o objeto como ele é na sua aplicação e jogar isso dentro do banco de dados. Com isso, elimina o mapeamento objeto-relacional.
APIs CouchDB de Rails que mapeiam como ActiveRecord não são legais. Você tem que quebrar o paradigma de um banco de dados relacional.
Por fim, ele recomendou o utilização da gem CouchRest para interagir com o CouchDB no Rails.
Os slides da apresentação você pode visualizar aqui.
Bruno Miranda e Jeison Seifer: Rails não Escala
Usando o estudo de caso do Cyloop, uma aplicação Rails por baixo do canal de áudio da MSN do Canadá até a Argentina, incluindo MSN Brasil, Bruno Miranda e Jeison Seifer mostraram como ajustar uma arquitetura para escalabilidade com técnicas incluindo filas, engines alternativos de storage, Rails Metal e Web Services.
O vídeo da apresentação você pode assistir aqui.
Vinícius Telles: Do serviço ao produto
Vinicius Telles contou a interessante trajetória de sua carreira. Não vou me alongar aqui, pois você pode (e deve) assistir a palestra inteira. Somente quero frizar algumas frases interessantes que foram ditas:
- O líder sempre é o culpado, mas quem leva os méritos é a equipe.
- Saiba escutar e reconheça seu erro.
- Existe uma diferença entre os EUA e o Brasil: lá fora eles tem uma auto-estima enorme.
- Se você não fizer algo que não lhe satisfaz, não faça mais isso. Você nunca conseguirá voltar no tempo.
- Primeira coisa para abrir uma empresa: pense em ter uma reserva. Às vezes a reserva é seu próprio atual emprego.
- Software tem muito a ver com relacionamentos entre pessoas, no caso seus clientes, do que mais do que tecnologia.
- Converse com o cliente: pessoalmente ou por telefone. As pessoas não tem confiança que tem alguém do outro lado.
- Isoladamente o software, a reserva e o relacionamento com o cliente não importa, o que importa é o conjunto que essas coisas geram.
- Paciência é muito importante para o empreendorismo.
- A melhor maneira de se destacar nesse mundo é compartilhar suas experiências. Ajudar as pessoas acaba sendo uma iniciativa de marketing.
Arthur Zapparoli: Git - Controle de Versões do Jeito Certo
A palestra do Arthur Zapparoli eu não assisti, mas os slides da apresentação você pode visualizar aqui.
Obie Fernandez: Mastering the Art of Application Development
Para fechar o Rails Summit 2009, Obie Fernandez fez sua apresentação dizendo que desenvolvimento de aplicações é arte. O importante é a prática, em tudo que você faz, para se tornar um mestre.
O desenvolvedor deve, ou deveria passar, por estágios semelhantes ao Shu Ha Ri:
Numa primeira fase, você está em Shu, o “seguir”, você ouve o que o instrutor/professor/sênior está lhe passando a informação e você simplesmente “recebe” e repete o que ele manda. Você ainda não é capaz de discutir ou raciocinar sobre isso agora porque você basicamente não tem conhecimento ou vivência o suficiente pra isso.
Em uma segunda fase você passa pra Ha e começa a experimentar caminhos diferentes, começa finalmente a raciocinar sobre o que está fazendo e fugir um pouco dos caminhos que o mestre ensinou.
Na última fase, o Ri ou transcendência, o estudante vira praticante e busca agora originalidade na prática, ele a aperfeiçoou de uma forma que ela não é mais igual a do seu mestre mas sim a melhor para ele mesmo.
Descrição de Shu Ha Ri retirada do comentário de Maurício Linhares de Aragão Junior no post http://akitaonrails.com/2009/09/26/off-topic-procurar-raciocionar-faz-bem
Obie sugeriu que para se tornar bom em alguma coisa, uma pessoa deve ter 10.000 horas de prática, enfatizando não só as 10.000 horas, mas também a prática correta, do jeito certo.
Ele questionou: Quantas horas você realmente codifica (pratica)? Em que você gasta o seu tempo?
E para finalizar: “Keep practicing for excelence. What you waiting for?”
O vídeo da apresentação você pode assistir aqui.
Eventos, Ruby Eventos, Rails, Rails Summit, Ruby, Ruby on Rails
Estou começando a desenvolver em Ruby on Rails e, da mesma forma que descrevi no 
de 
Entre os dias 06 e 16 de abril tive a felicidade de participar do curso 
Até então, o contato que eu tinha com Rails era um pouco com a sensação de pisar em ovos. Por exemplo, eu sabia como as validações no ActiveRecord eram usadas, mas não sabia como aquilo realmente acontecia. Depois de entender o dinamismo do Ruby, a coisa ficou totalmente clara. Em vários momentos do curso acendeu aquela luzinha do professor Pardal em cima da minha cabeça, com idéias do que eu posso fazer com o poder que o Ruby me oferece.
Eu recomendo o curso a todos que queiram aprender Ruby on Rails e que pretendem ir além do básico. Que não querem ser mais um “programador usuário” de frameworks de mapeamento objeto-relacional. Você pode fazer muito mais além do que o Rails tem a oferecer. Quando a ficha cair, você vai parar de usar scaffold e vai descobrir que a mágica do Rails não é tão mágica assim, mas sim é mais um ótimo uso dos poderosos recursos de uma linguagem com tipagem dinâmica, como o Ruby.
Comentários