Archive for julho \18\UTC 2009

Minhas impressões – Quinto encontro Guru-SP – 18-07-09

julho 18, 2009

Caros colegas,

Neste sábado tive o prazer de participar do quinto encontro do Grupo de Usuários Ruby de São Paulo (Guru-SP), que aconteceu na sala de treinamentos da empresa onde trabalho (a Voice Technology :)).

Apesar de meu conhecimento da linguagem e do framework de desenvolvimento Web (Rails) ser baixa, o objetivo maior era angariar o maior número de informações, aprender e ter contato com o pessoal da comunidade. Assim poderia ter mais “idéia” do que é Ruby e porque está sendo tão falado, comentado e usado nas empresas e em projetos open source.

Nós da Voice Technology já temos algumas pessoas capacitadas em programar em Ruby, mas estamos em constante nível de aprendizado. Essa participação no encontro será importante para sanar as principais dúvidas e responder as expectativas pessoais e do pessoal da empresa que não esteve presente.

P.S.: Este post também está presente no Templário da Tecnologia.

Panorama Geral


Até o dia de ontem (17-07-09) era prevista a participação de no máximo 20 pessoas para toda a duração do evento (10h00 até ~17h00), o que já era um número excelente para uma reunião “informal”.

Para a nossa surpresa (André Pantalião, Rodrigo Ribeiro e Thiago Veiga, membros da empresa presentes) tivemos cerca de 25 pessoas participando (!). A procura foi grande e acho que o encontro respondeu as expectativas da melhor maneira possível.

“Escopo” da programação das palestras (pelo menos o pensado):

  • 10:30 (devido ao “delay” clássico de espera do pessoal) – Palestra de Ruby (e Rails) voltada para iniciantes
  • 13:00 – DataMapper
  • 14:30 – GIT
  • 16:00 – Bate-papo sobre itens de interesse / Coding Dojo

Palestras

Ruby on Rails para iniciantes – Rafael Rosa “Fu”


Rafael Rosa “Fu” tomou a iniciativa de levar o notebook a frente e passar alguns “Ruby fundamentals” para o pessoal. Primeiramente ele abriu uma “janela” para que todos falassem (momento “apresentação”) o nome, profissão, envolvimento com as linguagens de programação e porque “raios” estar presente em um sábado de manhã para ver uma reunião de Rails (rs).

Foi interessante para chegar a algumas conclusões:

  • Maioria do pessoal é oriundo da área de programação em Java, voltada para Web;
  • Muitos dos presentes (inclusive eu…rs) são iniciantes em Ruby e Rails. O objetivo era saber mais do que é, como usar e os objetivos da linguagem;
  • Já existem pessoas que trabalham só com Rails em empresas. Muitos dos presentes já fizeram curso também, em sua maioria na Caelum;
  • A comunidade Ruby e metodologias ágeis estão andando de “mãos dadas” e estão definitivamente “implantados” nas empresas que usam Rails.

Após isso foram mostrados conceitos (e prática) de como instalar e usar Ruby, tomando como exemplo o famoso modelo do “Faça seu blog em 15 minutos“. O interessante é que desde a criação de um projeto até a edição/criação de métodos html (POST, por exemplo), dentre outros poréns de um blog não é necessário escrever uma linha de código (!).

O Rails já tem muita coisa pronta, relativa a configuração de banco de dados, modelo MVC, testes e servidor de aplicação. Por isso temos a famosa “agilidade de escrita” de código e desenvolvimento.

Além disso foram discutidos termos como TDD, BDD e princípio da janela quebrada, ressaltando também o uso de ferramentas de testes com o Rails (RSpec, Remarkable e Cucumber).

Abaixo alguns links para aprendizado de Ruby e Rails:

DataMapper – Rafael Rosa “Fu”


DataMapper utiliza o design pattern para persistência de dados publicado por Martin Fowler, de mesmo nome e que também é utilizado pelo Hibernate. Foi criado pelo pessoal do Merb (Matt Aimonetti e Yehuda Katz). O conceito base é o ORM do Merb.

As vantagens do DataMapper são:

  • Não depende de estrutura de banco de dados;
  • Mais fácil de integrar com sistemas legados;
  • Migrações e múltiplos repositórios.

Rafael mostrou e explicou alguns exemplos de código, comparando classes usando DataMapper e Hibernate, exemplificando o funcionamento, mapeamento de chaves e campos usados, etc. Muitos exemplos de classes podem ser encontrados no site do DataMapper. Reinterou que Active Record (outro ORM  e manuseador de dados usado por Rails) não é DataMapper, sendo o último mais “poderoso” e modularizado.

Explicou sobre os muitos plugins existentes para DataMapper e encontrados no repositório GIT do mesmo, separados em “Resource Plugins” e “Is Plugins”, e os seus respectivos “poderes de fogo”. Complementando o assunto foram mostrados de maneira mais superficial Adapters, Integration e Utility, pois são temas mais aprofundados do DataMapper.

Nas futuras versões (0.10 e 0.11) haverão novidades:

  • Validações para objetos Ruby puros;
  • Melhorias no SEL.

Desvantagens do DataMapper:

  • Menos maduro (menor número de usuários usando e desenvolvendo DataMapper e muitos usando Active Record);
  • Não se itegra facilmente com Rails (ainda);
  • Pequena comunidade;
  • Pouca documentação (relativamente);
  • Ainda não tem Remarkable;

Como podemos participar do projeto?

  • IRC Freenode #datamapper e #dm-hacking

A palestra do Rafael foi interessante, apesar de ser bem técnica. Devido ao conhecimento de Hibernate (seja ele teórico ou prático, da maioria do pessoal) a assimilação do conteúdo passado foi melhor e mais inteligível.

Desvendando o GIT – Douglas Campos (qmx)


A palestra procurou passar uma introdução a respeito do GIT, sistema de repositórios altamente usado em projetos Ruby. Mudança de paradigma de versionamento (não só arquivos, mas conteúdo de arquivos são altamente analisados).

Na introdução mostrou-se que GIT é performático e foi baseado em um desenvolvimento de 45 dias para uma nova plataforma de versionamento para o Kernel (ao invés do BK – BitKeeper, proprietária) desenvolvida por Linus Torvalds. No sistema de repositórios CVCS há o problema do código muito centralizado. No DVCS já o contrário: não há ponto central imposto pela ferramenta, tudo é descentralizado. No GIT há mudança de paradigma, pois os commits podem ser locais e/ou não acessando o servidor.

Sobre o “core” do GIT:

  • Commits pequenos em Rails são muito usados, pois as mudanças no projeto geralmente requerem pequenas implementações de linhas de código;
  • O versionamento de conteúdo no git “impacta” no conteúdo da árvore inteira;
  • Commit: não é nada mais do que as diferenças aplicadas a árvore de código (pilha de alterações);
  • O conceito de índice é tirar um “snapshot” seletivo dos objetos da árvore;
  • Podemos melhorar o conceito de índice no/para GIT: coloca tudo o que está no indíce dentro do repositório e são indicados por um hash SHA único e definido por um diff;
  • Definição técnica de GIT: o repositório no GIT é um grafo acíclico dirigido;
  • Branches: são simples ponteiros dentro do grafo, apontando para índices.

Após isso foi feito um exemplo de aplicação com vários desenvolvedores alterando e “subindo” código para um projeto fictício em um repositório GIT de teste, simulando a realidade e com a finalidade de mostrar ao vivo os conceitos de merge, diff, commit e histórico de mudanças.

Alguns comandos foram mostrados e são importantes para uso e manutenção do repositório: git stash, git status, git tag, git reset, git rebase e outro comandos.

Você precisa pesquisar em que arquivo ficava aquele método? Use o comando: git log -S’def update’ –pickaxe-all (visualiza as “mudanças de história”. Procura métodos que foram alterados no projeto e ele mostra os logs de commit. Muito poderoso). Essa é uma dica que é muito útil e pouca gente sabe!

Na parte final, Douglas discutiu com o pessoal sobre os conceitos de Cherry pick, Cherry (commits pequenos e pontuais) e Bisect (famosa história: “Mas eu tinha consertado aquele bug…quem ‘quebrou’?”).

Para finalizar houve uma discussão sobre fluxos de trabalho em equipe, recuperação de “desastres” e boas práticas.

Sem dúvida uma palestra bastante técnica, mas bem moldada, concisa e dinâmica. O overview dado sobre GIT foi bom para os “imaturos” em Ruby e Rails e para os experientes, pois várias dúvidas foram sanadas e muitas perguntas respondidas, de ambos lados. E uma novidade: Douglas expôs a informação de uma nova comunidade que está surgindo de Rails, intitulada RailsBridge. Ela é muito completa e voltada também para fins educacionais, além de ter uma campanha para ter mulheres programando em Ruby (rs). Vale a pena dar uma olhada!

Apesar de ter sido a palestra mais técnica do encontro os parabéns ao Douglas são necessários, pois o conteúdo foi excelente!

Coding Dojo – Modelagem de uma classe usando RSpec (aplicação de TDD)


No final do dia houve um dojo para que o pessoal, de forma colaborativa, codificasse um “projetinho”. O objetivo foi modelar uma classe usando RSpec, com a finalidade de trazer a tona modelos de programação, estilos de código, implementação de patterns, etc. O foco principal era aplicar o princípio básico do TDD: escrever testes antes de codificar.

Algumas das características usadas foram:

Gems instaladas

* remakable ( from github )
* rspec-rails
* Zentest

User Story da classe Group
– Tem que um nome;
– Outras características.

User Story da classe User
– Tem que ter um nome, login, e-mail, senha;
– Tem que pertencer a um grupo;
– Tem que ter status: ativo ou inativo;
– Senha tem que ser guardada como Hash;
– Precisa de método para fazer login que:
– recebe login e senha;
– retorna false se deu errado (login inexistente, usuário inativo, senha inválida);
– retorna true se deu certo.

O feedback durante a sessão foi legal e muito interessante!

Conclusão

Na minha visão o evento foi muito interessante e produtivo, sanando muitas dúvidas minhas a respeito do Ruby. Até instalei o Ruby na minha VM! (posteriormente estarei testando alguma coisa, pois o tempo urge para mim nesses dias!). Esse evento não seria realizado sem a iniciativa de André Pantalião e o pessoal do Guru-SP, que mostraram um grande interesse em participar e interagir, trazendo para o ambiente Voice a disseminação do conhecimento, tanto para nós quanto para a comunidade Ruby e afins. Aguardem mais novidades daqui para frente!

Agradeço a todos pela leitura e até a próxima!

ConclusãoNa minha visão o evento foi muito interessante e produtivo, sanando muitas dúvidas minhas a respeito do Ruby. Até instalei o Ruby na minha VM! (posteriormente estarei testando alguma coisa, pois o tempo urge para mim nesses dias!). Esse evento não seria possível de ser realizado sem a iniciativa de André Pantalião e o pessoal do Guru-SP, que mostraram um grande interesse e participação (interação), trazendo para o ambiente Voice a disseminação do conhecimento, tanto para nós quanto para a comunidade Ruby e afins. Aguardem mais novidades daqui para frente!Agradeço a todos pela leitura e até a próxima!

Ruby – Quinto Encontro do Guru-SP, esta edição na Voice Technology

julho 18, 2009

Pessoal,

Com grande prazer recebemos neste sábado (18/07), na sala de treinamento da Voice Technology, o pessoal do Guru-SP. A idéia é juntar usuários e interessados em Ruby e em Rails.

Agora na parte da manhã já temos 20 pessoas participando.

Programação:

  • 10:30 – Palestra de Ruby e Rails para iniciantes
  • 13:00 – DataMapper
  • 14:30 – GIT
  • 16:00 – Bate-papo sobre itens de interesse

Depois colocamos um post com maiores iformações sobre o que rolou.

Mingle Day São Paulo – Adam Monago

julho 6, 2009

Antes de começar a falar sobre o Mingle, ele falou um pouco sobre a Thoughtworks, esta empresa de consultoria tão falada no mundo de ágil.

A empresa surgiu 15 anos atrás construindo software customizados. Em 2000 estava em sérios problemas em um projeto. E eles foram em busca de algo novo. Falaram com Martin Fowler, como consultor, gostaram da forma, do resultado e continuaram a conversar.

Agile virou a forma deles fazerem projetos. E eles fazem muito coach em equipes também. De 15 pessoas do início até praticamente 1200 atualmente.
Lá na Thoughtworks eles não usam Scrum, XP, X ou Y, mas sim um conjunto de práticas ágeis que funcionam bem para eles.

MINGLE

A plataforma Mingle foi feita para trabalhar com a maioria dos projetos nas mais diferentes indústrias. na Thoughtworks, utilizam uma combinação de ferramentas, planilhas Excel e sem uma ferramenta que eles gostassem.

O desenvolvimento do Mingle começou a 2 anos e meio atrás e ele foi o primeiro cliente. Ele acha que foi escolhido para gerente de projetos da ferramenta por ter sido um cliente bem chato!

TUDO É UM CARTÃO

Tudo no Mingle é um cartão. Eles escolheram um cartão porque ele poderia representar qualquer coisa: um bug, uma feature, uma história…  Desta forma o usuário pode representar o que desejar.

Todas as visões do Mingle visualização os cartões de alguma forma. Todas as visões são, por padrão, abertas a todos. Isto porque a ferramenta foi feita com os princípios ágeis em mente. Toda visualização é a visualização de uma parte do backlog do sistema.

DEMONSTRAÇÃO
Ele começou mostrando um projeto básico, exibindo como se daria a utilização da ferramenta. O mingle é uma ferramenta muito intuitiva e fácil de usar.

A ferramenta tem um wiki embutido que deixa incluir texto, imagens e uma linguagem de macro para criação de gráficos e relatórios.  Além disso, expõe um plug-in em Ruby para cirar suas próprias visualizações.

TRANSIÇÕES DE CARTÕES
Este é um conceito muito poderoso que possibilita que uma ação seja executada toda vez que o cartão tem um estado alterado. Esta transição pode gerar alguma informação, alguma estatística.

FEATURE BREAKDOWN TREE
Dentro de um projeto podemos ter quantas árvores desejarmos. Estas árvores são úteis para dividir e agrupar as histórias, possibilitando ter um melhor acompanhamento do andamento do sistema.

O MINGLE É ENGESSADO?

Não. Eles não tem a intenção de ensinar ninguém a como ser ágil, como executar as tarefas. Mas sim, querem atender as pessoas que sentem necessidade de customização nas ferramentas atuais. O Mingle já vem com diversos templates adequado as mais variadas metodologias ágeis, mas o usuário pode customizar o que desejar.

Existem pessoas que utilizam o Mingle com Lean, colocando informações de filas de espera e filas de execução. Este é um exemplo de como a ferramenta pode ser customizada para algo totalmente diferente.

PLANEJANDO RELEASES

É muito fácil e intuitiva a forma de planejamento de releases do Mingle. Parece bem fácil e tranquilo de usar. E como fica tudo no mesmo lugar, diminui a necessidade de alguém ficar preparando relatórios que contém dados de várias ferramentas.

CONVERSE COM O PESSOAL DO MINGLE

Toda semana eles fazem sessões pela web onde as questões e o asssunto da reunião são dirigidas pelos participantes.

LICENCIAMENTO

Eles não falaram muito disto na palestra, mas é preciso falar disto:
* O Mingle é gratuito para projetos de até 5 usuários (acredito que por 1 ano somente)
* O Mingle é gratuito para projetos Open Source e de universidades
* Fora destas questões, ele é meio caro, saindo algo como 50 dólares por usuário, por mês.

Mingle Day São Paulo – Paulo Caroli

julho 6, 2009

Antes de Adam Monago começar a fazer a apresentação sobre o Mingle, Paulo Carolli deu algumas palavras sobre tudo que aconteceu até este evento. Paulo trabalha na Thoughtworks há alguns anos e atualmente trabalha no escritório indiano da empresa.

Paulo falou da importância de se criar uma comunidade, de trocar idéias, de se manter juntos e trocando idéias.

Outra coisa que ele disse foi da importância de Papo e Yoshima estarem discutindo os conceitos por trás das práticas. Para começar, nos apoiamos nas práticas para depois entender os conceitos.

Mencionou também que eles não estavam lá para vender o Mingle. Paulo iria trazer o Adam para um evento no Rio de Janeiro, onde ele falaria de User Stories e aproveitaram e organizaram um Mingle Day lá. Conversando com o Yoshima, eles aproveitaram e combinaram de trazer o evento para São Paulo.

Mingle Day São Paulo – José Papo

julho 6, 2009

PENSE DE UMA MANEIRA NOVA EM VEZ DE SÓ USAR FERRAMENTAS

Papo começou falando sobre a Semco, Toyota e outras empresas que são exemplo de auto-gerenciamento, mesmo fazendo tarefas repetitivas.
O menos importante são as práticas, mas sim a filosofia por trás das práticas.

Uma das bases do Scrum foi o artigo citado pelo Yoshima. O ponto central do Scrum é usar as poucas práticas com uma meta bem definida.

Parafraseando a Toyota, podemos dizer que:

“Antes de construir software, devemos construir pessoas”

Os líderes da Toyota têm um grande conhecimento do trabalho e focam no desenvolvimento das pessoas de baixo para cima. Papo mostrou um quadro com alguns tipos de líderes:
* Líder burocrático: não sabe e manda.
* Chefe de torcida: não manda, anima. Porém como não sabe, fica meio como líder de torcida.
* Task Master: Entendimento total do trabalho e já passa exatamente o que deve ser feito.
* Construtor de organizações que aprendem: Conhece profundamente o trabalho, mas trabalha mais como mentor, professor.

TAYLORISMO e PÓS-TAYLORISMO

* Taylorismo gera sistema empurrado, de dentro para fora.
* Pós-taylorismo gera sistema puxado. De fora para dentro. Melhoria na rede auto-gerenciada.

METAS FIXAS X METAS VARIÁVEIS

Ao trabalhar com metas fixas, a empresa não dá vazão às adapta~~oes que ocorrem no mercado. Geralmente, além de se definir uma meta fixa, já se define como o dinheiro será gasto. Na Toyota, você tem X milhões para gastar, não entra no detalhe. Além disso, a meta não é fazer X ou Y de dinheiro, mas sim, ganhar do mercado.

Defina metas aspiracionais e móveis e dê recompensas ao sucesso obtido em equipe.

Papo citou uma frase que navegar com metas fixas em águas desconhecidas é o mesmo que navegar de encontro a um iceberg.

VOCÊ é X ou Y ?

Existem dois tipos de pessoas, X ou Y.

  • X é o estilo de gestão autoritário e top-down. Pressupõe que as pessoas só se motivam por valores externos e tendem a evitar o trabalho quando possível.
  • Y é o estilo de liderança servidora. Acredita que as pessoas são auto-motivadas e podem cumprir por conta própria metas da organização.

Se você é X, nem perca tempo com metodologias ágeis, elas não foram feitas para você!

Ao final da palestra, Papo passou a lista de alguns livros (alguns bem famosos) que valem a leitura, veja no blog dele.

Mingle Day São Paulo – Rodrigo Yoshima

julho 6, 2009

Yoshima começou falando sobre o Besteirol Ágile e sobre pessoas que muito falam sobre as práticas ágeis e esquecem dos princípios. O problema desta falta de princípios chega ao ponto de 2 palestrantes do Scrum Gathering dizerem que não acreditam em auto-organização das equipes, justamente um dos pilares do Scrum.

Antes de pensar em Kanbam e reuniões diárias, é preciso pensar em auto-organização. Takeuchi e Nohara escreveram como as empresas estavam desenvolvendo produtos de eficiência e confiabilidade em 1986, no artigo The new new product development game. Este artigo foi uma das bases do Scrum. Podemos ver que o conceito não é novo, mesmo o Scrum já existe há um bom tempo.

Yoshima perguntou no que a platéia pensa quando falamos em auto-organização:

  • Bagunça
  • Comunicação
  • Auto-Gerenciamento
  • Pró-atividade
  • Comprometimento

Depois ele listou alguns dos princípios necessários para ter uma equipe auto-organizada:

DESCONFORTO

  • Auto-organização nasce do desconforto (muitos não concordam com isso), para atingir um objetivo insano (mais para frente na palestra Rodrigo disse que o objetivo insano havia sido um pouco exagerado)
  • Se a equipe sabe muito bem o dia de amanhã, não estã no desconforto. Sem uma ponta de desconforto, não há auto-organização. O karma é conciliar liberdade e desafio.

AUTONOMIA

  • Não dá para ter uma equipe auto-organizável somente com pessoas inexperientes. Tem que haver ao menos uma liderança técnica. Tem que ter um core experiente para o negócio fluir, e os membros da equipe ganharem maturidade.

INFORMAÇÃO ZERO

  • É muito importante as pessoas estarem no estado do não sei nada e não vou utilizar o passado no futuro. Porque senão você sempre irá tentar resolver o problema da mesma forma.

Sempre estamos tentando diminuir a variabilidade do processo. Desta forma, CMMI e RUP engessado seriam bons. Por isso, o palestrante se diz contra a departamentamentos de arquitetura e inspeção de qualidade.

TRANSCENDÊNCIA
Palavra bonita hein? mas na verdade, é querer saber o limite das coisas. É uma equipe que quer fazer coisas completamente inovadoras. Tente fazer da forma como você nunca tinha feito antes.
Ao desenvolver de forma ágil, você sempre está comprando um risco. Alguém assumiu um prazo com o cliente, assumiu uma incerteza… E nestes momentos, par resolver este risco, surge a inovação.

INTERFERTILIZAÇÂO

Não é só comunicação entre as equipes. é a comunicação entre pessoas de vários skills e experiências.
Muitas vezes as equipes nunca sentam para planejar o projeto juntos, justamente onde ocorre a troca de experiências. Mais importante do que cartas, números e prazos, o jogo de planejamento é um excelente momento para troca de experiências.

APRENDIZADO
Uma pessoa alimentando a outra com conhecimento, para que toda a empresa aprenda junta. A empresa tem que ter um direcionamento para o aprendizado.

AUTO-ORGANIZAÇÃO
Não somente em projetos inusitados para ter auto-organização. Projeto legal é projeto que desafia. Tente fazer projetos em outras áreas, diferentes do seu habitual.
Auto-organização é o cerne de uma metodologia ágil.

Mingle Day São Paulo – Thoughtworks e Aspercom

julho 6, 2009

Em um grupo de cerca de 80 pessoas: Rodrigo Yoshima, José Papo, Adam Monago e Paulo Caroli fizeram um encontro para falar de ágil e para o pessoal da Thoughtworks falando do Mingle.

Antes que alguém fale alguma coisa, não existe nenhuma relação comercial entre a Thoughtworks e a Aspercom, eles se uniram somente para fazer este evento. Claro que no futuro pode rolar alguma coisa, mas não tem nada acertado.

A palestra de cada um deles está descrita nos posts abaixo:

Foi um evento bem bacana, que reuniu diversas pessoas da comunidade ágil.  Depois o pessoal ainda foi para um barzinho, mas eu tomei o rumo de casa.

Próximo post: apresentação de Rodrigo Yoshima no Mingle Day

Veja mais informações no blog da Aspercom, que organizou o evento.

Ganhadores do mês de junho

julho 5, 2009

No mês de junho, todos que postaram ganharam prêmios! Os ganhadores de canecas do Basix foram:

  • Fabrício Campos
  • Rodrigo Ribeiro
  • Antonio Anderson