AgileAndArt

It was a great event and I’m very happy to be part of it. QCON was awesome! I hope you enjoy the pictures

Nessa vida de programador maluco
Me aparece cada situação
De repente um cliente, uma proposta bruta
Pra pegar de um site informação

Você tá louco, esse tipo de crime eu não faço
Se quiser tenho uns amigos lá do sul
Faz pra mim que eu te pago com essa jóia cool

Te dou um ruby
Pra você roubar
Com o seu robô

Quer fazer robô?
É só usar ruby
É só usar ruby
Pra fazer robô

Here are the slides the presentation slides about Ruby Robots I gave in RsOnRails

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

Conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the things designed themselves.

This presentation was created by Richard P Gabriel and presented at IME-USP – São Paulo on 30/Mar/2011 sponsored by CCSL

Monkey Patch é uma técnica de programação bem conhecida para modificar código runtime em linguagens dinâmicas (Smalltalk, JavaScript, Objective-C, Ruby, Perl, Python, Groovy, etc.) sem alterar o código fonte original. Programadores Ruby estão bem acostumados a criar novos métodos para classes já existentes. O Rails faz isso em várias classes do Ruby, por exemplo, adicionar o método to_xml à classe Hash. A maneira de fazer isso em ruby é:

  class String
    def meu_novo_metodo
       return self + "-> alterada"
    end
  end
  # "essa string".meu_novo_metodo retorna "essa string-> alterada"

Em Javascript, é possível adicionar um método a um protótipo (em Javascript não existe o conceito de classes como na maioria das linguagens orientadas a objetos). O código para adicionar um novo método em Javascript ficaria assim então:

   //cria o método "method" a todos os protótipos
   Function.prototype.method = function (name, func) {
      this.prototype[name] = func;
      return this;
   };
 
   //adiciona o método "integer" ao prototipo Number
   Number.method('integer', function () {
      return Math[this < 0 ? 'ceil' : 'floor'](this);
   });

Javascript não possui um método que remova espaços em branco no final de strings. Isso pode ser facilmente melhorado com o código:

   String.method('trim', function() {
      return this.replace(/^\s+|\s+$/g,'');
   });
 
  //"    teste    ".trim() retornaria "teste"

É muito fácil escrever um programa em Ruby para importar todos os seus contatos do Google na sua conta de e-mail Marketing da Locaweb. Com um simples script de 25 linhas isso é possível. Veja:

EMAIL_MKT_CHAVE = "[SUA_CHAVE]"
GOOGLE_EMAIL = "[SEU EMAIL NO GOOGLE]"
GOOGLE_PASSWD = "[SENHA GOOGLE]"
EMAIL_MKT_HOST = "[MAQUINA EMAIL MKT]"
EMAIL_MKT_LISTS = "11115"
EMAIL_MKT_LOGIN = "[LOGIN EMAIL MKT]"
EMAIL_MKT_URL = "http://#{EMAIL_MKT_HOST}.locaweb.com.br/admin/api/#{EMAIL_MKT_LOGIN}/contatos/importacao/?chave=#{EMAIL_MKT_CHAVE}&listas=#{EMAIL_MKT_LISTS}"
 
login = {:accountType => "HOSTED_OR_GOOGLE",
	              :Email => GOOGLE_EMAIL,
	              :Passwd => GOOGLE_PASSWD,
	              :service => "cp",
	              :source => "danicuki-teste-1"
	             }
a = RestClient.post("https://www.google.com/accounts/ClientLogin", login)
auth = {"Authorization" => "GoogleLogin auth=#{a.split.last.split("=")[1]}"}
c = RestClient.get("https://www.google.com/m8/feeds/contacts/default/full?max-results=2000", auth)
contacts = Hash.from_xml(c)["feed"]["entry"]
emails = contacts.select {|c| !c["title"].blank?}.select {|c| !c["email"].blank?}
email_mkt_hash = emails.map do |c|
	{:nome => c["title"].split[0].camelize, :email => (c["email"][0] ? c["email"][0]["address"] : c["email"]["address"])}
end
RestClient.post(EMAIL_MKT_URL, email_mkt_hash.to_json)

Agora a descrição dos passos do código:

1. Primeiro você define todos os parâmetros para a sua busca. Os dados sobre a sua conta de e-mail Marketing podem ser obtidos na documentação da API da Locaweb.
2. Depois faz um post para obter a credencial do google, que será usada logo mais para buscar os contatos. A credencial é retornada em formato texto, uma string bem feiona tipo essa: SID=DQAAAJcAAAAGD-h4PWkAfqRPrDJcIVmiPg1qq1pDPCbY-1DykHzaSmxrpIqIYjUNdqYUjDgLJRmKZstgafFhHa0CIajl-SIlAKPLr2Ll-wuQhC5z-DFQ66mybDfiPlig5osdQ-Uf6JlFdfHGnKiQk4xfqHvg3xm0SFqwg2SQDIBXI-iidkkIjnS7F4Z8FYVP_bGj_26JYr7S6FTA3jNxiUS7QewUsk7d
   LSID=DQAAAJkAAAAPZxYEjHLtrIT6pO-E7hVvM_1khNV7FWfdsr1BMjqwHmfuuabdMSPwv9gHBvd8eHiO8lrMv2ugwGFB7eKxe5WiNQ_uBy3u9aOy8jrqCT_Gx_LRSEE2gyvX8aiGtdpLCiGxTjhCRz5S-wz2g4Qo6uwt-Rdh3xgocPEvSQeiF1Eqr5N5c8_eN0Kn-Gr6WBIsFm6mlyZqUKLSuROK1rL7WpMu
   Auth=DQAAAJkAAAAPZxYEjHLtrIT6pO-E7hVvM_1khNV7FWfdsr1BMjqwHmfuuabdMSPwv9gHBvd8eHh4LIFHdmGkr75M6OHTAjZf3T4n2Q8GwqyAu5G73NA9dnkDbC3q-AsdnZOV7eP6uSF_jhvZYrGmOzAARthZ9BCcmaz2y2eWCUdYzUE0vdNDgYlhAh2ybT21M4KHXFP5T6JfXN8wZVrVEiWhcaqP2MfI

   Para a chamada a API, a única coisa que interessa nessa string é o valor de Auth, que extraímos com o código

   a.split.last.split("=")[1]

3. A API do Google Contacts é bem simples, porém o XML que ela retorna é um trambolho. Nesse momento estamos interessados em apenas montar um hash com o primeiro nome da pessoa e o e-mail. Fazemos isso nessas linhas:

   #contacts conterá um array de contatos
   contacts = Hash.from_xml(c)["feed"]["entry"]
   #filtra apenas contatos que tenha nome e email definidos
   emails = contacts.select {|c| !c["title"].blank?}.select {|c| !c["email"].blank?}
   #monta o hash - o nome é apenas a primeira parte do titulo 'camelized'
   # o email tenta o campo 0, se tiver coloca, senão é o próprio address (chatices...)
   email_mkt_hash = emails.map do |c|
   	{:nome => c["title"].split[0].camelize, :email => (c["email"][0] ? c["email"][0]["address"] : c["email"]["address"])}
   end

4. Por último transformamos o hash em JSON e enviamos para o Web Service do Email Marketing.

O modelo de Dojo que estamos acostumados é o Dojo Randori, aquele em que temos uma dupla programando (o piloto e o co-piloto) e um telão para mostrar para o resto da plateia o código que está sendo feito. A cada 5 ou 7 minutos o co-piloto ocupa o lugar do piloto e alguém da plateia ocupa o lugar do co-piloto. No Randori, todo desenvolvimento é sempre feito usando TDD.

O Dojo Kake é uma modalidade diferente de Coding Dojo. No Kake, nós temos sempre duas ou mais duplas trabalhando simultaneamente. As duplas podem resolver o mesmo problema em linguagens diferentes ou problemas diferentes. Os turnos continuam sendo de 7 minutos, porém a plateia NÃO PODE ficar olhando a dupla programar. A ideia é sentar para programar sem ter a menor noção do que estava acontecendo antes. É uma simulação da vida real: você chega para trabalhar num projeto que já começou, tem código legado. O seu par deve conseguir te explicar o que foi feito até então e vocês precisam avançar com o código. Depois de 7 minutos, o seu par sai e agora fica com você a responsabilidade de explicar para o próximo o que foi feito e continuar resolvendo o problema. Algumas regras do Kake Dojo:

• Dois ou mais computadores, dependendo da quantidade de participantes
• Turnos de 7 minutos
• TDD, baby steps, refatorações continuam sendo obrigatórios
• Divertir-se é obrigação: bater papo, contar piadas, cantar uma música, jogar video game, vale TUDO, menos olhar os outros programando
• Comida durante toda a sessão (pizza, sanduíche de metro ou jantar gourmet)
• No final fazemos uma retrospectiva usando a técnica dos 6 chapéus

Algumas cenas do último Dojo Kake que realizamos em 2009 podem ser vistas no vídeo:

Vamos fazer um Dojo Kake na próxima 3a. feira, dia 17 de agosto as 20h. Quem estiver interessado em participar, mande um e-mail para mim: danicuki arroba gmail ponto com.

This weekend I was working at the first Random Hack of Kindess mundial edition. There were 4 people in our team and we worked on a project called Urban Fact (Fato Urbano in Portuguese). The main idea of this project is to emphasize GOOD orBAD facts in your city. If you see someone throwing the garbage over the streets, just take a picture and post it on twitter using #urbanfact hashtag (or #fatourbano). This picture automatically  goes to the project website, where people can vote, comment and share with friends.

For the solution, we used Rails for the web interface, MySql as database and Python for the backend twitter collector. We also used Google Maps API to automatically generate the map with all entries. All code is available at my github account. We hosted the website in a Locaweb Cloud Server.

Our project earned the 2nd best project prize!

Visit my flickr account to see the pictures of this event.