Blog do Gogs

Sobre o TDC2011 (The Developers Conference)

Nos dias 6 a 10 de julho de 2011 aconteceu o The Developers Conference 2011 (comumente conhecido como TDC).

Fiquei conhecendo pelo Twitter do @porcelli, organizador da trilha de NoSQL, numa chamada para submeter palestras. Como tinha o material do BrazilJS sobre CouchDB, percebi que poderia ter ali uma boa oportunidade de falar mais de Couch, e aprender com a galera. Submeti, e fui aprovado para o domingo.

O evento tinha 5 dias, mas só pude participar de 3. Os ensinamentos e networking gerado por lá foram os pontos cruciais. Ver que tem uma galera boa no Brasil fazendo software de qualidade e utilizando tecnologias “na crista da onda” é de dar orgulho. Parabéns à galera da Globalcode pela organização dessa edição, e por dar oportunidade da comunidade submeter palestras.

Sexta-feira - Trilha Ruby

Cheguei na sexta de manhã e fui direto do aeroporto para o evento. Entrei no meio da palestra do @vinibaggio “Alcançando alta performance com EventMachine”, assunto que me interessava bastante por se tratar de IO não-bloqueante (algo como o node.js faz com socket.io). As possibilidades de utilização dessa biblioteca são excelentes, principalmente criando proxys da aplicação com bom desempenho.

Durante o almoço tive a oportunidade de bater um papo com @vinibaggio, @fnando, e com uma galera boa, falando sobre algumas ideias que deram certo, projetos pessoais e problemas do dia-a-dia de pagamento digital.

Na volta do almoço, @hannelita com sua palestra “Ruby on Rails além do ActiveRecord” demonstrou como utilizar alternativas NoSQL para aplicações Rails. Nos exemplos dados, Redis e Neo4J ganharam destaque.

A palestra do Fábio Akita sobre “Rails e Arquiteturas” e do Lucas Húngaro de tema “Seus testes estão gritando, você está ouvindo?” deram bons exemplos de boas práticas para a construção de aplicações utilizando Ruby (on Rails) e noções fundamentais para ter um código bonito e funcional.

Nando Vieira (o @fnando) veio falar logo depois sobre “Metaprogramming 101”, entrando particularidades da linguagem Ruby por vezes desconhecidas ou pouco utilizadas. Nível técnico elevadíssimo e com qualidade excelente.

Como tinha virado a noite viajando, a essa hora eu estava exausto e fui para o hotel. Infelizmente perdi a palestra do Felipe Rodrigues sobre “Starting Up - Simples e Rápido”.

Sábado

Como no dia não tinha nenhuma trilha que me interessasse de cara, fiquei passeando entre elas e principalmente fazendo networking nos intervalos. Destaque para a trilha de Python, que me surpreendeu por ter casos de uso excelentes e o ritmo de Lightning Talks no final da tarde deram oportunidade para os que estavam assistindo trocarem experiências.

À noite, após o encerramento, um open space excelente sobre Lean Startup e empreendedorismo com @jbernab foi o ponto forte do final do dia. Excelente papo e troca de experiências de quem já vivenciou muito e de quem estava começando

Domingo - Trilha NoSQL

Este sim, para mim, foi o dia mais esperado, tanto por ser a trilha que mais me interessava quanto por ser a trilha na qual eu iria palestrar.

Cheguei para a abertura, e pude ver uma galera boa no auditório cheio, em pleno domingo de manhã. Fiquei feliz por saber que a galera se dispôs a participar ativamente.

Tivemos nesse dia as trilhas de Agile, Web, Arduino, NoSQL e games. Uma pena, pois eu gostaria de participar de mais de uma, com certeza.

Na trilha de NoSQL, logo pela manhã, sala lotada e a palestra de Thiago Avelino sobre desenvolvimento com MongoDB. Já fiz alguns experimentos com Mongo, porém não conhecia a fundo. Foi muito bom para entender e inclusive para complementar a palestra que eu iria apresentar à tarde.

Antonio Marques e André Ferraz, logo em seguida, apresentaram relato de utilização do MongoDB na Locaweb, como conseguiram solucionar alguns problemas de replicação, e escalabilidade.

Depois do almoço foi a minha vez. Para ser sincero, finalizei minha apresentação mesmo durante a palestra de Antonio Marques e André Ferraz (e quem não faz isso?) Foi necessário para que eu pudesse fazer um paralelo entre o CouchDB e o MongoDB.

Apesar de estar apresentando, com as perguntas e o bate-papo ocorrido durante o almoço, aprende-se muito. Gostaria de agradecer principalmente ao Alexandre Porcelli e ao Luciano Ramalho (que iria palestrar logo em seguida) por terem complementado minhas respostas, ainda mais quando fazia relação com Mongo.

Luciano Ramalho falou de CouchApps de maneira descontraída e informal. Explicou a diferença entre as CouchApps e a aplicação couchapp e demonstrou um exemplo que havia construído para a apresentação.

Infelizmente tive que viajar logo em seguida, então perdi grandes palestras que eu gostaria muito de ter assistido, principalmente a de ElasticSearch.

Avaliação final

Gostei muito de ter participado do evento, e de poder conhecer a comunidade de desenvolvimento em São Paulo. Alguns nomes que eu só conhecia de twitter, tive a oportunidade de ouvir, e bater papo.

O formato do evento também me surpreendeu. Diversas trilhas de tecnologias distintas a primeira vista me gerou estranhamento, mas percebi que a troca de experiências e networking gerado foi sem igual.

Parabéns à Globalcode por mais uma edição do The Developers Conference. Próximo ano espero participar mais uma vez.

Aplicações Ajax com Sammy.js

Quem já desenvolveu alguma aplicação utilizando Ajax já deve ter se deparado com a situação de ter que atribuir eventos a links e botões para realizar as requisições via Ajax.

Funciona, mas imagine que o usuário de repente clique na tecla F5 atualizando a tela. OMG, e agora? Todas as vezes que for feito um refresh na aplicação, a tela inicial será recarregada, perdendo-se tudo o que havia sido carregado anteriormente.

Não seria interessante que os dados carregados via Ajax sejam carregados baseado nas rotas, e que eu possa tanto acessá-las diretamente como poder utilizar as setas de voltar e avançar do navegador? Sim, isso é possível de se fazer facilmente com o Sammy.js

O Sammy.js é claramente inspirado no Sinatra, um framework minimalista escrito em Ruby para criar aplicações baseadas em rotas. Falei brevemente dele no artigo “Frameworks Ruby criando moda”. Da mesma forma, ele se baseia em rotas para criar aplicações em JavaScript, carregando dados e templates via Ajax.

Um exemplo de uma aplicação simples em Sammy.js:

var app = Sammy('#content', function() {
  this.use('Mustache');

  this.get('#/', function(ctx) {
    ctx.redirect('#/home');
  });

  this.get('#/home', function(ctx) {
    var content = {user: 'henriquegogo', gender: 'male'}
    ctx.partial('templates/home.mustache', user);
  });

  this.post('#/send', function(ctx) {
    $.post('send.rb', ctx.params, function() {
      ctx.redirect('#/home');
    });
  });
});

$(document).ready(function() {
  app.run('#/');
});

O conceito é bem simples: ao invés de atribuir ações a botões, atribui-se ações a links (em formato de âncoras).

Além do básico demonstrado acima, ele vem com um conjunto de plugins que podem ser utilizados para gerenciar cache, utilizar o google analytics, e diversos plugins de template (entre eles HAML, Mustache e Micro-Templating).

Tenho utilizado bastante para construir aplicações que consomem serviços (em json). Basicamente o server-side só precisa receber e enviar json, e toda a lógica de rotas e views ficam no lado do cliente.

Quem desenvolve para node.js com Express vai se sentir em casa. A diferença básica é que o Sammy.js vai ser executado no lado do cliente ao invés do servidor.

Palestra no TDC 2011 - Conhecendo o CouchDB

Domingo, dia 10 de julho irei palestrar no The Developers Conference (http://www.thedevelopersconference.com.br/) sobre CouchDB na trilha do NoSQL junto com uma galera de peso que entende do assunto no Brasil.

Convido portanto a todos que puderem e quiserem a participar deste evento, que vão correndo, pois já começa dia 6.

Essa palestra será a continuação do Lightning Talk que apresentei no BrazilJS 2011 de mesmo tema, porém irei falar ainda sobre replicação e um comparativo breve entre CouchDB e MongoDB.

Agradecimentos também ao Alexandre Porcelli, que está encarregado pela trilha de NoSQL. A trilha parece estar bem interessante.

Em breve posto fotos e um resumo de como foi o evento.

Espero vocês lá!

Diferenças entre CouchDB e MongoDB (controle de concorrência)

Quando se fala de bancos não relacionais, logo se vem dois nomes de peso: CouchDB e MongoDB.

Há uma certa dúvida sobre por qual começar, qual é o melhor, qual a diferença entre um e outro. Cheguei a pesquisar alguns artigos e comparativos, e praticamente todas as conclusões que lia era apenas gostos ou contra-gostos.

Eu não sei explicar o porquê, mas me parece que o MongoDB caiu no gosto dos que querem começar com NoSQL. Talvez pelo fato de poder enviar queries pela aplicação, e no CouchDB as consultas serem todas em views, totalmente ‘fora’ da aplicação.

Não quero alimentar nenhum flame war, o que quero explicar aqui é só uma opinião pessoal que cheguei através de tentativas, testes, e conversas sobre quem estava usando e seus dilemas.

Como conheço mais o CouchDB, posso dizer alguns pontos que se destacam:

Orientado a documento

Tá bom, isso não é uma particularidade do CouchDB, já que o MongoDB é bem similar, porém acredito que o CouchDB tem como vantagem a possibilidade de armazenar as views numa estrutura de pastas e arquivos, usando o CouchApp. Fica fácil commitar e inserir as views dentro de um projeto.

Replicação Master/Master

Replicação tanto no Couch quanto no Mongo são bem simples. Essa é a principal vantagem de se utilizar um banco NoSQl. Com o CouchDB, porém, essa replicação é master/master enquanto que no MongoDB é master/slave.

MVCC (Multiversion concurrency control)

Esta é a característica crucial que me faz decidir pelo CouchDB. Como para cada alteração ou Couch cria uma revisão, temos um ótimo controle de concorrência e integridade dos dados. Caso um servidor sofra uma alteração, na hora da replicação ele irá examinar as revisões e substituir pela mais recente.

Isso é importante pois no MongoDB, por exemplo, como um update gera alteração no dado especificado, é necessário que haja um lock no banco. Um banco NoSQL com locks não me faz muito sentido.

Como no CouchDB qualquer update, delete, geram uma nova revisão, tanto teremos uma boa resolução de conflitos na hora da replicação quanto evitamos que essa ação seja bloqueante.

Retiro aqui trechos dos sites de ambos para exemplificar o que quero dizer:

Database readers are never locked out and never have to wait on writers or other readers. Any number of clients can be reading documents without being locked out or interrupted by concurrent updates, even on the same document. CouchDB read operations use a Multi-Version Concurrency Control (MVCC) model where each client sees a consistent snapshot of the database from the beginning to the end of the read operation.

http://couchdb.apache.org/docs/overview.html

Traduzindo livremente:

Consultas ao banco de dados (CouchDB) nunca são bloqueantes e não espera outras requisições de leitura ou escrita. Qualquer número de clientes pode ler documentos sem ser bloqueado ou interrompido por atualizações simultâneas, ainda que no mesmo documento. As operações de leitura do CouchDB utilizam um Modelo de Controle de Concorrência onde cada cliente vê uma cópia consistente do banco desde o início até o final da operação de leitura.

Enquanto que…

MongoDB uses a read/write lock for many operations. Any number of concurrent read operations are allowed, but typically only one write operation (although some write operations yield and in the future more concurrency will be added). The write lock acquisition is greedy: a pending write lock acquisition will prevent further read lock acquisitions until fulfilled.

http://www.mongodb.org/display/DOCS/How+does+concurrency+work

Traduzindo livremente:

MongoDB usa bloqueio de leitura/escrita para muitas operações. Qualquer número de operações de leitura simultâneas é permitido, mas normalmente é possível apenas uma operação de escrita (embora no futuro maior controle de concorrência irá ser adicionado). O bloqueio de escrita é voraz: o bloquei de escrita pendente evita futuros bloqueios nas requisições de leitura até que sejam realizados.

Para mim isso é quase determinante. Para que usar um banco não relacional com bloqueio de escrita? Se quero algo novo, quero algo novo que seja eficaz o bastante para lidar com múltiplas operações de escrita.

Conhecendo o CouchDB

Segue o lightning talk que apresentei no BrazilJS 2011.

Uma breve demonstração de bancos não relacionais, principais vantagens e utilização e um guia rápido de sua API Rest.

Não vou me deter muito em detalhes na explicação pois já falo no vídeo. Pretendo postar um artigo ainda explicando algumas particularidades que deixei de falar no vídeo.

Frameworks Ruby criando moda

É incrível como as mudanças na área de desenvolvimento e tecnologia acontecem rapidamente e geram consigo transformações em tudo o que ‘atingem’.

Não é novidade dizer que programar em Ruby está sendo uma tendência, principalmente entre as startups e sistemas abertos. O Java realmente está em profunda decadência e sua comunidade hoje se divide entre escolher C# e Ruby.

Quando o Ruby on Rails surgiu, sua proposta de convenção ao invés de configuração atingiu em cheio aqueles desenvolvedores Java que penavam com seus XMLs e mil configurações.

É incrível como essa proposta se difundiu quase como um padrão. Passou a ser copiado pelo próprio Java com o VRaptor, pelo PHP com o CakePHP e CodeIgniter, e tantas outras implementações em tantas linguagens. Hoje em dia podemos encontrar praticamente um * on Rails em qualquer linguagem.

Mas não foi só isso. Alguém talvez não satisfeito com o ‘pacotão’ que o Rails era, ou talvez para propor algo mais leve, criou um framework minimalista em Ruby chamado Sinatra.rb, que basicamente é um framework baseado em rotas, mas que comporta algumas coisas básicas bem úteis como renderizador de templates e trivialidades.

Este, então, devido a sua enorme simplicidade acabou sendo copiado mais ainda. Tempos praticamente uma lista de implementações.

Onde eu quero chegar? Talvez num simples questionamento: se as ideias e frameworks mais copiados estão surgindo do ecossistema Ruby, estudar e optar por utilizar essa linguagem em seus projetos nunca é demais. Lembre-se que poliglotismo no desenvolvimento é quase uma necessidade hoje em dia.