Technology Glossary

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:

a.k.a. Also known as
API Application Programming Interface

Continue reading

DevOpsDays e Curso Grátis de Chef

No próximo sábado teremos o primeiro DevOpsDays Brasil. O evento será gratuito e terá a presença de palestrantes importantes na área de Cloud e Infra-estrutura de Internet. Quem fará o Keynote do evento será John Willis – VP de serviços da Opscode, empresa que está por trás do software Chef – um dos mais bem feitos softwares de Configuration Management.
Continue reading

Monkey Patch em Javascript

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"

Continue reading

DevOpsDays Brasil

É com muito orgulho que anunciamos o primeiro DevOpsDays Brasil, que será realizado no dia 4 de dezembro de 2010. O evento acontecerá num único dia – uma trilha organizada sobre uma série de painéis/apresentações onde encorajamos fortemente a discussão aberta entre os participantes.

Devopsdays é um evento aberto para discutir todos tópicos sobre como melhorar a interação entre o que é tradicionalmente considerado atividade de desenvolvimento e o que é tradicionalmente considerado atividade de operações.
Continue reading

Test-Driven Change – TDD for your infrastructure

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?
Continue reading

Transparência Hackday Moradia: 10 de outubro

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.
Continue reading

Dojo Kake

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. Continue reading

9 perguntas e respostas sobre Métodos Ágeis na Locaweb

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