Dev in Sampa

Dia 28 de setembro estarei palestrando no Dev in Sampa e vou falar de buscas com Solr em Ruby on Rails. As palestras estão bem legais e o evento custará 35 reais. São apenas 100 vagas, então assim que abrir a inscrição corram para confirmar presença.

Slides da palestra na Fatec

Estou disponibilizando os slides que eu e o Rafael Rosa Fu (twitter @rafaelrosafu) usamos nas palestras que fizemos na Fatec. Interessante é que assuntos como TDD, Testes Automatizados, Métodos Ágeis e outras coisas importantes do mercado ainda não estão sendo difundidos da maneira adequada para os que estão entrando na área. Quero agradecer a Gonow pela oportunidade de me apresentar nas Fatecs de São Paulo, Mogi das Cruzes e Ourinhos.

Os Slides estão no SlideShare

Palestra Fatec

View more presentations from almeidaricardo.

Palestra na Fatec-SP

Hoje eu e o Rafael Rosa (@rafaelrosafu) estaremos palestrando na Fatec sobre Ruby On Rails e Agilidade. Será uma introdução à linguagem Ruby e o Ruby on Rails. Também falaremos de nossas experiências com a tecnologia aqui na Gonow. Mais tarde disponibilizaremos o vídeo da palestra para quem não puder comparecer. Acompanhem o InfoQ Brasil e o Ruby Inside Brail para
mais informações.

Mais informações estão na página da Gonow.

Retrospectiva

A Retrospectiva é muito importante em equipes ágeis porque proporciona uma reflexão sobre o sprint, com o intuito de inspecionar e adaptar em futuras iterações. É um momento de aprendizado pois são expostas as coisas boas e o que pode ser melhorado num futuro próximo.

Parece ser fácil fazer uma retrospectiva, mas para que ela seja objetiva é necessário que o dia-dia seja muito envolvido nesse processo. Na retrospectiva normalmente nos lembramos apenas do que foi bastante ruim e esquecemos de falar de coisas boas, que quando ditas podem ser um forte ponto motivacional para o time. A mente humana é muito seletiva e esquecemos facilmente o que aconteceu durante a semana, a não ser o que foi realmente marcante. Por isso existe uma técnica que ajuda na retrospectiva que é usar post-its coloridos em cada acontecimento diário. O fato de usar post-its vermelhos quando acontece algo ruim do sprint, amarelos quanto surgem idéias e verde quando acontece algo bom, causa um efeito visual em nossa mente e a equipe trabalha mais proativamente. Esses post-its diários ajudam bastante pois são discutidos na retrospectiva e não perdemos tempo tentando lembrar o que aconteceu na semana.

Importante! A retrospectiva não é o momento de se achar os culpados, e sim uma solução para o que pode ser melhorado. Portanto não se deve falar nomes nessa reunião, porém um elogio é sempre bem vindo!

De nada adianta a retrospectiva se não for documentada e não houver um plano de ação após essa reunião. Após a retrospectiva, são definidos os responsáveis pelos itens que precisam ser melhorados e como será o plano de ação. A documentação pode ser uma simples foto do quadro de discussão e que fique de fácil acesso a todo o time. Isso é importante para que se tenha uma Linha do Tempo de todas retrospectivas do time para acompanhamento do progresso.

Escrevi outro artigo sobre isso no link:

http://manifestonaweb.wordpress.com/2009/03/20/qcon-london-2009-retrospectivas/

Plugin ActsAsSolrReload para o Rails

Gravei um screencast com o Diego Carrion, que explicou mais detalhes nesse post. Iremos melhorar esse vídeo para aumentar a fonte, mas para não ficarem muito curiosos a gente já está liberando o link.

O Solr é um projeto open source da apache e é baseado no Lucene para engine de busca. O Solr faz buscas via XML/HTTP e API JSon e possui funcionalidades de facets, cache, replicação, uma interface de administração web, etc.

O Diego fez um fork do plugin ActsAsSolr e criou o ActsAsSolrReload, já com uma configuração para fazer buscas de geo-localização e buscas com relevância.

Confiram o screencast nesse link

Rails Rumble 2009

Hoje começa mais um Rails Rumble, uma competição de desenvolvimento Rails em 48 horas com no máximo quatro pessoas. As equipes se organizam em um final de semana para modelar, desenvolver, configurar o servidor e fazer o deploy de uma micro aplicação rails na web. Tudo partindo do zero, ou seja, não pode haver uma linha de código sequer antes do início da competição.

Leiam essa matéria na InfoQ Brasil e o post que o Rafael Rosa publicou no Ruby Inside Brasil.

Por onde ando…

Uma passada rápida no meu blog para tirar as teias de aranha O que estou fazendo?

Estive recentemente em dois eventos, Google Developer Day e Encontro Ágile / Mingle Retrospective. O próximo da lista será o evento de Rails organizado pela comunidade de São Paulo, o Guru-SP. Esse será o Quinto Encontro do grupo e ocorrerá nesse sábado, dia 18/07.

Estive trabalhando no meu artigo da Java Magazine que será publicado na edição número 72. O assunto será sobre Domain-Driven Design, altamente recomendado para nossa área, independente de sua Linguagem de Programação de preferência. Essa foi uma experiência muito interessante e de grande aprendizado. Espero que comprem a revista e me dêem feedback!

Atualmente estou trabalhando na Gonow com Rails, Sinatra, e outras coisas mais com Ruby. A empresa está patrocinando equipes para o Rails Rumble 2009, graças aos esforços do Diego Carrion que correu atrás dessa oportunidade. Veja esses dois posts aqui e aqui.

Para terminar, estou aguardando a aprovação de minha palestra no Just Java 2009 e quem sabe um BoF no Rails Summit 2009.

E não se esqueçam de me seguir no Twitter.

Entendendo MapReduce

Sabemos que ter um bom modelo de banco de dados relacionais é importante, porém com a necessidade de aplicações mais escaláveis nos dias atuais, talvez você precise “desnormalisar” o seu banco de dados. O que adiantaria uma foreign key se você tem tabelas espalhadas em diversos data sources? Por questões de performance, dados podem ser distribuídos em data centers distintos, então como buscar pelo id se você não sabe onde está esse dado? Por isso é importantíssimo que a aplicação controle essa integridade, com um bom design OO, para não depender de constraints e stored procedures do banco de dados.

MapReduce é um modelo de programação, e framework introduzido pelo Google para suportar computações paralelas em grandes coleções de dados em clusters de computadores. Agora MapReduce é considerado um novo modelo computacional distribuído, inspirado pelas funções map e reduce usadas comumente em programação funcional. MapReduce é um “Data-Oriented” que processa dados em duas frases primárias: Map e Reduce. A filosofia por trás do MapReduce é: Diferentemente de data-stores centrais, como um banco de dados, você não pode assumir que todos os dados residem em um lugar central portanto você não pode executar uma query e esperar obter os resultados em uma operação síncrona. Em vez disso, você precisa executar a query em cada fonte de dados simultaneamente. O processo de mapear a requisição do originador para o data source é chamado de ‘Map’, e o processo de agregação do resultado em um resultado consolidado é chamado de ‘Reduce’.

Hoje existem diversas implementações de MapReduce, como : Hadoop, Disco, Skynet, FileMap e Greenplum. Hadoop é a implementação mais famosa implementada em Java como um projeto open source.

Se você quer contribuir nesse projeto, assista esse screencast.

Apresentação da Linguagem Lua

Renato Maia, mestre e doutor em Informática pela PUC-Rio, compareceu na USP para falar sobre a linguagem de programação Lua. Ela é uma linguagem de características dinâmicas desenvolvida no Brasil e utilizada em todo o mundo em centenas de projetos relevantes.

• Interpretação de Código


code = loadstring( " print( ’ H e l l o , Wo r l d ! ’ ) " )
code ( ) --> H e l l o , Wo r l d !


• Tipagem dinâmica


a = 1
print( a+a ) −−> 2
a = " a "
print( a+a ) −−> attempt to perform arithmetic on global ’ a ’


• Coleta automática de lixo


file = assert( io.open( "file.txt " , " w" ) )
file : write( a )
file : close( )
file = nil --> conteudo de 'file’ vira lixo a ser coletado


• Reflexão compulacional


function string:trim( )
  return self:match ( " ^%s*( . −) % s * $ " )
end

user name = " admin "
print ( username:trim( ) ) −−> admin


Lua é uma linguagem de extensão extensível. É uma biblioteca ANSI C, ou seja, um subset do C. Foi construída na PUC-Rio entre 1993-2009.

A aplicabilidade de Lua é bastante vasta. Usada no Adobe Photoshop Lightroom, Ginga TV Digital, Firmware de impressoras, Analisador de protocolos, Pós Graduação de Filmes, Servidores Web (RealTimeLogic),  Jogos, etc.

Após a palestra, fizemos o DOJO com a participação especial do Renato Maia.

Para detalhes mais técnicos, você pode conferir os ótimos slides do Renato clicando no link:

apres-lua-RenatoMaia

Outra documentação interessante:

http://www.lua.org/manual/5.1/pt/

O Estado da arte da DSL em Ruby

Estive na apresentação de Glenn Vanderburg, no QCon London 2009, que falou sobre o Estado da Arte da DSL em Ruby. A apresentação e os slides você pode conferir aqui no site da infoq.

A idéia de fazer uso de uma DSL interna originou-se aparentemente no Lisp. Em Lisp você não escreve seu programa apenas direcionado na linguagem, você também constrói a linguagem em cima do seu programa:


(task “warn if websites is not alive ”
  every 3 seconds
  starting now
  when ( not (website-alive? “http://example.org”))
  then (notify “admin@example.org”, “server down!”))
)


DSL interna também foi um objetivo de design do Haskell


keepleft (p :>: ps)
  | keepleft p = case partitionFL keepleft ps of
    a :> b -> p:>: a :>: b
  | otherwise = case commuteWhatWeCanFL (p :> ps) of
    a :> p’ :> b -> case partitionFL keepleft a of
      a’ :> b’ -> a’ :> b’ +>+ p’ :>: b


Agora falando em Ruby, uma das principais características da linguagem é a expressividade. O japonês Yukihiro Matsumoto (Matz), criador da linguagem, sempre teve como objetivo fazer o ruby extremamente legível. Para atingir esse objetivo a linguagem tem o recurso conhecido como “Sintax Sugar”. A performance da linguagem não foi o objetivo inicial, e sim a clareza. Por isso o ruby é uma linguagem mais lenta. Entretanto agora com a adoção maior nos projetos de mercado direcionados a web, a preocupação com performance cresceu e o resultado disso foi o recente release da versão 1.9.1 do ruby, com resultados impressionantes de performance.

Deixando a performance de lado e voltando à DSL, em um projeto Rails você pode fazer as seguintes associações em uma classe model:

has_many :favorites, :conditions => {:state => ‘public’}

has_many :roles, :through => :projects, :uniq => true

validates_length_of :login, :within => 3..40, on => :create

validates_presence_of :authority, :if => :in_leadership_role, :message => “must be authorized for leadership”

Fica claro e limpo que o modelo tem uma associação a duas coleções (favorites e roles), e validações ficam explícitas no próprio model. Outro exemplo usado na apresentação citada acima:

#Um intervalo de tempo:

3.years + 13.days + 2.hours

# Quatro meses de agora, na segunda_feira

4.months.from_now.next_week.monday

Muita coisa é possível fazer no ruby por causa do “method_missing” que existe nos objetos. Por exemplo, você pode sobrescrever esse método e incluir um código como esse:


def element(element_name, opts={})
  write “<#{element_name}#{encode_opts(opts)}”
  if block_given?
    puts ”>#{yield}”
  else
    puts “/>”
  end
end

E o resultado disso pode ser fazer uma manipulação simples de html:


xml.html {
  xml.head{
    xml.title(“History”)
  }
  xml.body{
    xml.h1(“Header”)
    xml.p(“paragraph”)
  }
}

Outro exemplo que eu adoro é o uso de Active Record  do Rails. Graças ao “method_missing” podemos fazer uso de métodos que não existem, como por exemplo:


Funcionario.find_by_nome_and_cargo( "Fulano", "Gerente")

E ainda fazer uso de Named Scopes:

Funcionario.gerente.pelo_nome

Na linha acima o Active Record vai trazer todos gerentes ordenados pelo nome.

Ruby é uma linguagem muito boa para escrever DSL internas por ser uma linguagem não-obstrusiva e permite que muitas pontuações sejam opcionais. Porém, DSL não faz o seu software magicamente melhor e devem ser usados com precauções. Nem sempre o código fica mais limpo com esse uso.

Glenn fala sobre a complexidade do software e a indicação do famoso livro de DDD do Eric Evans, e do livro The Mythical Man-Month.

Um bom design de software:

• Elimine tudo que possível da complexidade acidental
• Separe o resto

Outras frases muito interessantes dessa apresentação:

• Linguagens são para pessoas entenderem o domínio
• Coisas que são implícitas na verdade são complexidades acidentais
• Aprender a linguagem ajuda a entender o domínio

Um bom design de API:

• Criar uma DSL para determinada construção é poderoso
• Você pode refatorar ela quando achar duplicação, complexidade, etc
• DSL interna é apenas uma parte do bom design da API no Ruby