AgileAndArt

Next month I’ll start my PhD program @ University of São Paulo.

I’ll work on a project called CHOReOS – Large Scale Choreographies for the Future Internet. People are asking me what is this project, what I will study, what exactly I’ll do and I have a simple answer to these questions: I don’t know. I mean, I don’t know exactly. But I know it’s cool and that I will be involved with great people. That’s enough.

But I promisse, as soon as I start understanding deeply the CHOReOS project, I’ll post details on my blog. For now, you can have the explanation given at the project’s blog:

What is CHOReOS?

• CHOReOS is a joint IT research and development project, whose sixteen members consist of companies, universities and research centers from six European countries and Brazil.
• CHOReOS is a project of the FP7 European program: FP7-ICT-2009-5 – Objective 1.2; it is co-funded by the European Commission (8.665.785 € of investments).
• CHOReOS is a high-technology software project addressing one of the most acute challenges of the future Internet of Services: the design and management of ultra large-scale web services coordination.
• CHOReOS is an open source project, the technology developed by the project will be publicly accessible from software repositories hosted on the OW2 Forge.
• CHOReOS is a nascent community, a community that will come together and share via this web site, LinkedIn, Twitter, StatusNet and IRC.

What CHOReOS is not.

• CHOReOS is not a company and you cannot buy shares in it.
• CHOReOS is not a Greek island.

For more details, here’s the CHOReOS website.

Here’s a small table of many terms I’ll have to be used to in my PhD program, which starts on the next month. It’s just a small part of hundreds of abbreviations we software developers have to deal with on our daily work. Please comment down if you have suggestions to add to this table. I’m sure every person can add at least 30 itens to this table:

Há algum tempo, fizemos uma peça de teatro que ensina os conceitos de Domain Driven Design (DDD). O foco desse teatro é a parte de Projeto Estratégico (Strategic Design) de DDD. Essa peça é baseada no roteiro escrito pelo próprio Eric Evans. Em 2008, na QCON SF, eu participei de um Workshop de DDD com o Raph Johnson. Depois fiz a tradução do roteiro, que pode ser baixado aqui.

Para saber mais sobre DDD, leia esse post no meu blog.

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.

Test Driven Development (TDD) is a common practice for software development, in which you write your tests before writing your code. Then you run the tests and they will fail. Then you implement the feature and the test passes. Then you write another test. Then run and fail. Then implement the feature. Then tests passes again. You repeat this process many times. Good developers are already familiar with TDD and do it on their daily-work. But what about sysadmins? How do they test their work? Is it possible for a sysadmin do TDD?

Here’s a small tip of how a sysop could get real benefits doing TDC (Test Driven Changes) to their environments. Matthias Marschall described how to do TDD in Ops world in 3 simple steps:

1. In your monitoring system (Nagios, Zabbix, etc), write a service that monitors the problem you are trying to solve, and make sure the service shows red on your dashboard.
2. Implement the configuration change, and have the your CM – Configuration Manager (Puppet, Chef, CfEngine, etc) roll it out to your test system.
3. Once the service shows green on your dashboard, have your CM roll out the change to production.

So, in infrastructure world, your Test Suite is all the rules you setup in your monitoring tool. Once all your tests are green, you can “refactor” your system. If you break something, some of your tests should fail so you will know what should be fixed.

Link original

No dia 10 de outubro de 2010 teremos mais uma edição do Transparência HackDay, desta vez temática.

A proposta inicial será trabalhar com “Vazios Urbanos” e “moradores de rua”.

“Vazios Urbanos” a que me refiro são, de um ponto de vista bem amplo, “espaços e imóveis que não cumprem sua função social“. Ou seja, imóveis desocupados, terrenos vazios sem uso, e por ai vai. Tudo que poderia se transformar em moradia social.

Mapeando esses dois dados poderemos utilizá-los e cruzá-los para levantar oferta e demanda de moradia e pensar em políticas públicas efetivas para a questão das moradias, indicando com precisão dados e localizações.

Esse mapeamento será feito usando a plataforma Ushahidi.

“A ferramenta apresentada nesse primeiro encontro será o Ushahidi, plataforma de “crowdsourcing” criada colaborativamente por desenvolvedores web do Quênia, e outros países. Ela permite que usuários enviem mensagens para um website (inclusive através de SMS usando celulares), que agrega essas informações e as distribui em um mapa, conforme for sinalizado pela pessoa que envia seu relato ou testemunho.”

Para ver um pouco mais sobre essa ferramenta recomendo estes dois tópicos, que contém vários exemplos legais:

[1] http://blog.esfera.mobi/tech-talks-ushahidi-e-eleitor-2010/

[2] http://blog.esfera.mobi/saldo-tech-talks-ushahidi-e-eleitor-2010-2/

Quando?
10.outubro.2010, das 14h às 20h , seguida de pizza

Onde?
Casa de Cultura Digital
Rua Vitorino Carmilo, 459 - Santa Cecília
Próxima à estação Marechal Deodoro do metrô

Quem?
Hackers, desenvolvedores, designers, blogueiros, jornalistas, pesquisadores, gestores públicos, legisladores, políticos, representantes de ongs, estudantes, ativistas e etc. O evento é aberto e gratuito.

Inscrições em:
http://bit.ly/THackDayMoradia

Para mais informações:
thackday @ diraol.eng.br
ou acesse a lista de discussões do thackday: http://groups.google.com/group/thackday

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.

1 – Quando e como surgiu a idéia de implantar a XP como método de desenvolvimento?

Começamos a fazer XP em 2006, no time que desenvolvia o PABX Virtual (antiga Locaweb Telecom). Quem trouxe a ideia de XP foi Daniel Cukier, um dos desenvolvedores do time na época. Ele tinha cursado em seu mestrado (IME-USP) duas disciplinas sobre Métodos Ágeis e já era membro da Agilcoop. Ja tinha adquirido certa experiência para tentar aplicar o aprendizado num projeto de verdade. O time era pequeno na época (4 desenvolvedores) e o gerente gostou bastante das ideias propostas no XP que lhes foram apresentadas. O time de Telecom era relativamente isolado dos outros times de desenvolvimento e isso facilitou as coisas. Era possível adotar a metodologia como um projeto piloto, sem afetar outras áreas ou produtos. Durante 8 meses, de outubro de 2006 até junho de 2007 o time se estabeleceu na metodologia. O produto PABX Virtual foi lançado e sua evolução em termos de funcionalidades era rápida e eficiente, com poucos bugs. A cada duas semanas, o time de Telecom lançava novidades no produto.Em paralelo a isso, Daniel Cukier e Maurício De Diana criaram um grupo de estudos de tecnologia, onde um dos assuntos estudados foi Métodos Ágeis. O grupo de estudos serviu para que as pessoas pudessem conhecer mais os detalhes não só de XP, mas também de outras metodologias como Scrum e Lean. As reuniões do grupo tinham entre 10 e 20 pessoas. Esse grupo de estudos tentou iniciar um projeto multi-equipes usando XP, mas devido às várias atribulações do dia-a-dia dos membros do grupo, o projeto não deu certo.Em meados de junho/julho de 2007 foram feitas algumas apresentações para a diretoria da empresa, com o objetivo de estimular a adoção de Métodos Ágeis em todos os times de desenvolvimento da empresa. Para convencer os diretores, foram mostrados números que demonstravam a qualidade do produto PABX, tanto em relação ao código quanto à velocidade de criação de novas funcionalidades. Na mesma época, um consultor internacional veio à empresa dar um curso para o time de produtos. Esse consultor comentou que gostava de Métodos Ágeis para desenvolver software. Isso foi a gota d’água que faltava.

No mês de agosto, a diretoria patrocinou um treinamento em Métodos Ágeis para desenvolvedores, gerentes e clientes internos de diversas áreas da empresa (até o presidente participou. A partir daí iniciou-se um processo longo e trabalhoso de adoção das práticas Ágeis dentro da empresa.

2 – Após o planejamento, quanto tempo se gastou para o método ser implantado? Seria possível nos informar o custo médio que a implantação desse método teve? Todos os objetivos da Locaweb foram alcançados?

Foram quase 2 anos de evolução das práticas ágeis dentro da empresa, até o ponto em que podemos afirmar que a Locaweb se tornou de fato uma empresa de Desenvolvimento Ágil. Durante esses anos, muitas coisas mudaram. Várias pessoas saíram da empresa e muitas outras foram contratadas. O perfil dos profissionais mudou drasticamente. No primeiro ano, as práticas de Scrum foram as mais facilmente adotadas (práticas como planejamento, estimativas, ciclos de desenvolvimento, etc.) – as práticas de engenharia e design, como testes, refatoração, integração contínua, só começaram a se estabelecer a partir do 2o. ano. A programação em pares foi uma prática que teve adoção em quase todos os times, mas também demorou 2 anos até que fosse algo arraigado na cultura da empresa. Uma vez que a Locaweb se tornou Ágil nos times de programação, essa mudança começou a impactar outras áreas da empresa: áreas como infra-estrutura, times de sysadmins, e até marketing, vendas e recursos humanos. O objetivo de estruturar a área de desenvolvimento, de forma que a empresa como um todo (diretoria, cobrança, marketing, financeiro) pudesse ter visibilidade sobre os projetos em andamento, foi atingido. Porém, a empresa continua mudando sempre, visando a melhoria contínua dos seus produtos e processos internos. A excelência em Métodos Ágeis na área de tecnologia não significou que todos os problemas fossem resolvidos, pois a empresa é grande e complexa. Mas foi um primeiro passo foi dado e novos aprendizados e ações surgiram desse passo. Então, podemos dizer que a Locaweb é uma empresa muito melhor do que era antes dos Métodos Ágeis.

3 – Houve um aumento de produtividade após a implantação de XP? Ouve uma redução do custo de produção?

continue reading…