I would contend this is a rare scenario and that in most cases injection of dependency addresses the actual need (think assembly with Spring for instance).

I imagine cases when that is not enough and I was wondering at what point does the configuration parameters start to form a DSL. I was also wondering when it becomes more efficient to create a DSL to program the adaptation to local conditions. An initial guideline could be that it is as soon as you thing of storing the configuration in an XML document.

What is your take ? Does it help to rethink configuration as a DSL ? What is your experience ?

I am going back to a software vendor I left it a few years ago. I left because I was missing direct contact with the business users. I left because I felt I had reached the limits of my influence and growth there. I am going back because I am given a great opportunity both in terms of career and personal development. I have a chance to further the changes I helped introduce back then. I get a chance to apply innovative solutions. That is the bottom line for me. In my previous role, despite all the great people I met and worked with I was not getting to apply innovative solutions. And therefore I was not learning as much as I would have liked. This is the deep reason why I felt dissatisfied. The other elements that took part in my decision were only the back breaking straws.

In fact I strongly believe turnover is beneficial for companies and employees alike in the software engineering world. As long as the turnover aligns with project duration it is not overly destabilising. The company gets to hire new people with fresh ideas. The employee gets to learn new things. I wonder if knowledge workers could be classified in the same way as open space participants: pigs, bees and butterflies.

What do you think ? What kind of worker are you ?

First what we call multitasking really is an interruption driven work process. That process is a consequence of our overall work organisation. Instead of having cadence, we usually expedite. THe way we expedite is also grounded in the idea that we should not be idle and we should be “utilised’ all the time.

Second the downside of multitasking really is the time it takes to resume a task after an interruption. It is a set up time or a transaction cost.

A couple of things were illustrated. I offered that the pomodoro technique was a great help to handle multitasking. Essentially the pomodoro technique provides cadence and thereby suppresses the interruption driven work style. In exchange it provides predictable windows to address urgent requests. In this way it forces triage between urgent and not urgent while preserving the ability to adapt the work stream. It also enforces the idea that it is good to have idle time. Other signalling techniques were offered to prevent interruptions.

It was interesting to witness that the default attitude we had to resolve the problem of interruptions was to increase the batch sizes to avoid them. Essentially the same idea as reducing the set-up time in the industry. Importantly the discussion turned to techniques to reduce the transaction cost (context switching time) associated to multiple tasks. This is the realm of getting things done techniques (to-do lists to boot). One interesting remark from David Chilcott is to note down the next step in your current task before switching to another task.

To summarise, multitasking is good. Interruption is evil.

What techniques do you use to cope with interruptions ? What do you do to facilitate context switching ?

If you do have a vote in the 2009 Agile Alliance board election, please take a moment to review César’s position statement and then vote, for him preferably !

What I have noticed in those environments is that new techniques and technologies do not get adopted. Instead a passive-agressive attitude exists, whereby the change is not supported and when things degrade people are quick to use it as proof their old familiar ways are superior. Any attempt to introduce any kind of methodology that is “not invented here” is doomed in this context. I am quite convinced that any change is actually doomed. I may get the opportunity to observe this in the introduction of a “waterfall” process in my current company.

Worse however, while many would think that an agile methodology is more appropriate for those organisations (and they are probably right), it is almost impossible to successfully introduce it. In most cases members of the organisation lack the practice of self discipline necessary to support an agile process. And building that requires in turn a full cultural change where, initially at least, the disciplined application of good practices is valued more than the result.

How would you go about it if you are not the CEO ? Do you have gardener’s tip to successfully grow agile seeds ?

First we identified the stages and queues of our development process. We decided that the process starts with the Analysis of a work item. To be quite honest some informal analysis and some preparation work to clear out dependencies takes place before that but we did not formally include it in our process. Most of it is tracked at the road map level. The analysis yields one card, trimmed to a manageable size with the acceptance criteria expressed as a few BDD-style scenarii.

Then there is an Analysis Complete queue. It buffers developers.

Then there is the development in progress stage where cards are again actively worked on. We try to follow best practices for the most part. A card cannot leave this stage until the tests pass, the reports are fine (no cyclic dependencies, no significant PMD or FindBugs warnings, enough coverage) and the acceptance scenarii have been automated with cucumber (and the awesome cuke4duke maven plugin).

Then there is a development complete queue. It buffers QA.

Then there is the QA in progress stage. This is about verifying the scenarii manually and verifying their automation. Any issue or concern raised is immediately addressed. If the issue needs tracking, an issue card is created and attached to the card.

Then there is the closed stage which is the exit of our process.

We do not track statistics internal to the process aside from the cumulative flow diagram. The administrative cost of that seems too high for such a small team. We do track the cycle time of each card in our process.

I will write more on the observations from the first month in an upcoming post.

The first reason is to track how people spend their time. The idea behind it is usually that you cannot trust people to work hard. And that may be true in some contexts. However, the same people who distrust people’s work ethics entrust them with gathering the data. And so they essentially get the ideal values randomly adjusted so that they look real. While this is a useful practice at a personal level (see the pomodoro technique for instance), at a team level it really comes from the ‘look busy’ frame of mind. Throughput should be the thing management cares about.

The second reason is to try to get better at estimating. So managers want to try actuals and compare them to estimates. And then if the actuals do not match the estimates put pressure on the team to get better estimates. So for those of you who believe in that, here is what happens. Developers will start by padding their estimate so that they are pretty sure the actuals won’t exceed the estimate. Second, remember you hired them because they are smart, so they will never finish early to avoid the suspicion of padding. So you will get perfect detailed estimates and still the project will be late. And if, being clever yourself, you cut the estimates and people do not have time to finish within the estimate, then they will cut corners, drop quality and finish within the estimates anyway. And the project will be late because of those bugs that need to be fixed. By the way did you know that the best estimation is usually at a coarse grain level because then errors tend to offset each other ?

The third less harmful reason for tracking actuals is to improve the time forecast. This is essentially a statistical use by we try to measure the relationship between ideal days (or points, or size) and actual days. Even with this innocuous goal it is a waste of time. First the information is already available in the burn up (or down) chart. Second it tends to be wrong because early in a project there is not enough data to make it statistically relevant and later in a project chances are circumstances have changed (personnel, techniques, technology may have changed, technical debt may becoming a burden etc).

So why waste time and moral on actuals ? Even better, once you abandon actuals, precise estimates become irrelevant and you can get away with relative sizes. And relative sizes are very quick and easy to get consensus on and you therefore save time that too. So please abandon the collection of actual times !

I am not sure I fully buy into the analogy of painting style to agile transition style. I actually feel the painting style is more useful as an analogy for the practice style (rather than transition only). And that is what was actually talked about most of the time.

A specific point sticked out during the talk and in the questions for which no good answer was articulated. It stemmed from the remark that the creators and masters of new styles (impressionism, cubism, expressionism) had a classic (baroque) training and were perfectly able to paint in that style. And so the question came of how much knowledge do people need to know about the pre-existing styles before being able to apply more modern style.

I think the question is best answered by making a distinction between technique and style. The impressionists were all trained in the techniques that supported the baroque style. And this knowledge enabled them to create new techniques, experiment with them and then give rise to new styles. In this case the style emerges from the techniques that are applied to the art. Obviously, once the technique is created it can be taught and the student of that technique can then paint in the new styles. The deeper their technical knowledge the more styles they have available to express their art or satisfy their patrons.

And the lesson I take out of this is that to apply agile in various environments one has to be well versed in all the techniques that exist to successfully select the ones that will support the desired style. It seems to indicate also that to successfully transition from one style to another one needs a good understanding of the techniques and aspirations that created the old style in addition to knowing the techniques that will support the new style.

Stimulating is it not ?

First it is very hard to fight the urge of piling more work in our queues. We have too many ideas, many of them looking good enough that we would like to record them. It is a conscious effort to resist this and remind ourselves that, if these ideas are good they will either resurface coming from stake holders or we will remember them. If not, chances are we would not find them in a laundry list anyway.

Second it was enlightening to notice how small stories and short cycle time is energising. Short cycle times give an incredible impression of control over the process. They are also morale boosters as progress is continuous. Now this contrasts significantly with a longer story we played recently, which incidentally could have been broken down. That story gave the feeling of a squid, a temporary loss of control. Your vision becomes a tunnel, you lose peripheral vision and you hope that this will all end well. In the future we will proactively split stories and we will have to resolve the challenge of possibly breaking our WIP limit.

Third we got to experience how cycle and lead times are impacted when the bottleneck (me sadly) is loaded with additional work. We have this inconvenient position where we should reuse code that is in no shape to be reused and therefore needs to be cautiously refactored. That work cannot progress at the speed we move so we have to somewhat duplicate it while we work towards a good solution. Last month I had a green light to make one of the changes and did it. But this is additional work that has increased the lead time and cycle time without direct value to the project. In effect the project is working pro-bono for the rest of the firm. The positive about this is that the effect is immediately visible. In the future we will track this kind of work as issues.

Third, my coworker and subject matter expert was enlightened by Chris Matts’ cartoons. He did not use to understand how Agile in general and our own process in particular can be so efficient in the financial software industry. The Agile 2009 cartoon was an important stepping stone for his “conversion”.

How do you record ideas without piling them ? Do you have advice on how to handle external work ? How do you handle back-flow into limited size queues ?

How do we plan then ?

We use a roadmap. The shorter the horizon, the more fine grained. I use a template from enthiosys. We record functional and architectural goals on it. We record events (demos, vacations, code freezes). We also record our target markets. The roadmap has a lot of white space. Not all categories have something at every time horizons. What this means however is that we implicitly estimate when features will be completed from a very high level. This in turn gives us a lot of room to adjust what we actually deliver using dimensional planning. When we need to decide what we do next we use our roadmap and we usually make the decision in a few seconds. That is when the analysis work starts that will cut a workable story. What does not fit in the story is not recorded but will probably resurface on the next round, informed by what we learned while playing the previous story.

What about the product vision ?

We have from the beginning created a set of documents that we keep current. One is a contextual diagram that shows how this kind of product generally fits in our clients’ processes. Another one shows how it fits in the software the company produces (which is a much larger thing). Finally we have a diagram that outlines the end state of our product with a broad view of the functions we want to build. The roadmap takes over from this high level vision with a time horizon of a year or so. In addition we have an architectural context and a domain model established before we start on a functional area.

What’s the catch ?

There are several things that make this possible. First we are a very small team (one developer, one BA/QA). We both have a significant expertise in the domain and in that specific product. This process can certainly scale beyond that size but I am not sure how much. Second, we were hired to build that product and therefore we have a lot more control over how we manage things. We also do not have existing clients or contractually agreed scope to deal with.

What are the advantages ?

Primarily we removed many of the things that generate pain in a software development process. No estimates means no actuals (more on this). No backlog makes it very cheap to rearrange our priorities. No detailed long term plan means we do not have the temptation to adhere to it. Instead we reshape the plan constantly to reflect the new information we acquire. Finally all of this provides us with the material to efficiently communicate with our prospects and clients. We show enough structure that they easily understand where we are going and at the same time we have enough flexibility to incorporate their feedback in our plan. And the same thing applies to communication with upper management.

That is a short presentation of how we (so far happily) operate. What is your experience like ? Have you tried similar things ? Or other things ? How did they work out ?

Como havia falado no post anterior, fiz 3 apresentações que foram muito bem recebidas pela galera (ao menos os feedbacks no Twitter e no stand foram ótimos)! Foi legal mostrar um pouco do que temos aqui na Globo.com e saber que muita gente mudou sua opinião a respeito do que somos e o que fazemos. É claro que somos uma empresa cheia de problemas como qualquer outra, mas temos um monte de iniciativas legais, pessoas legais e projetos/desafios interessantes como em poucos lugares, o que nos torna uma das empresas mais legais para se trabalhar no Brasil!

Adorei também conhecer um monte de pessoas novas que nem vou arriscar citar aqui para não esquecer os nomes. Todas essas pessoas fizeram com que o evento fosse um show!!! Veja algumas fotos no meu Flickr.

Críticas, sugestões ou comentários são sempre bem-vindos! E nos vemos ano que vem no FISL 11!

Referring to people as “resources” leads to thinking that individuals are interchangeable code producing units.

Toda vez que alguém chama uma pessoa de “recurso” dói meu ouvido. Chega até a ser chato, mas quando alguém faz um comentário sobre “recursos” do meu lado dificilmente consigo resistir a corrigir para “pessoas”. Como a Esther Derby disse na sua mensagem, tratar pessoas como “recursos” dá a impressão que as pessoas são “commodities“, que são meros “parafusos”, sem importância individual e substituíveis por qualquer outro.

Como que alguém pode se sentir bem sabendo que é totalmente descartável e que pode ser a qualquer momento trocado por qualquer outra pessoa? Como alguém pode estar comprometido com um projeto sabendo que é totalmente substituível e que não faz diferença se quem estiver ali for ela ou qualquer outra pessoa? Como alguém pode se sentir motivado assim?

E por fim a pergunta que eu queria chegar: Que tipo de código e que tipo de produto as pessoas vão conseguir produzir nessas condições?

Desenvolvedores de software são trabalhadores do conhecimento. Ao contrário de trabalhadores “Fordistas”, que são extremamente especializados numa linha de produção e desempenham atividades repetitivas e “robóticas”, os trabalhadores do conhecimento trabalham intensivamente com o seu cérebro, analisando e interpretando informações, descobrindo novas e melhores soluções para resolver problemas e tomando decisões o tempo todo.

Por esse motivo, é essencial que essas pessoas estejam motivadas, pois isso as deixa num estado mental que estimula sua produtividade, aumentando a quantidade de trabalho que podem realizar e potencializando o uso da sua criatividade para resolver problemas.

Um projeto de software bem sucedido é construido por pessoas motivadas, que tem visão do que estão fazendo e que acreditam nessa visão.

Para saber mais:

• Porque empresas tratam as “Pessoas” como “Recursos”?
• Managing Knowledge Workers

Se você (assim como eu) gosta muito de ler blogs de desenvolvedores, provavelmente vai adorar isso: uma lista com os top 200 blogs para desenvolvedores selecionados por Jurgen Appelo.

A lista contém ótimos blogs de gente conhecida no mercado como Martin Fowler, James Shore, Jeff Sutherland, Joel Spolsky e por aí vai, além de blogs que eu ainda não conhecia e que são bem legais também. Para completar ainda tem o Twitter de uma boa parte dessas pessoas.

Mesmo que você não concorde com a lista e ache que tem coisa faltando ou sobrando, com certeza irá encontrar um monte de blogs interessantes para incrementar o seu leitor de RSS. Boa leitura!

Passadas algumas semanas encontrei denovo com essa pessoa em um outro evento. Para a minha surpresa, ela me disse que sua vida estava um inferno! Os clientes não estavam dispostos a fechar contratos de escopo negociável, eles queriam saber exatamente o que e quando os projetos seriam entregues. Eles definitivamente não quiseram trabalhar com desenvolvimento iterativo, até porque os projetos já eram bem curtos (menos de 1 mês). Pra terminar, por ser uma agência pequena a equipe é de menos de 10 pessoas fazendo com que uma pessoa precise trabalhar em 3 ou 4 projetos ao mesmo tempo. E por aí vai…

Então eu perguntei: Quantos projetos davam errado antes de você começar com Agile?
E ele respondeu: Todos os nossos projetos sempre foram bem sucedidos.
E eu perguntei denovo: Então qual é o problema que você está tentando resolver usando Scrum e desenvolvimento iterativo?
(silêncio…)
Eu novamente: Ok, já entendí. Faça o seguinte, volte para o seu processo de trabalho antigo. Não sei como é mas me parece ótimo.

Muita gente se surpreende quando eu falo isso. Só porque eu falo sobre desenvolvimento ágil não significa que eu acho que isso é a solução para todos os problemas. Se todos os seus clientes estão satisfeitos do jeito que você está trabalhando, seus projetos não falham, você faz ótimas entregas e tudo está ótimo, você não tem um problema. E se você não tem um problema, você não precisa resolver nada. E nesse caso eu recomendo: não use uma metodologia de desenvolvimento ágil só porque está na moda.

Metodologias ágeis partem do princípio de que os requisitos de um projeto de software vão mudar. Geralmente em projetos de software grandes é muito difícil de planejar todos os requisitos de uma vez no início do projeto. Não seria impossível fazer isso mas o custo é tão alto que vale mais a pena planejar menos e ir adaptando o software e os requisitos ao longo do tempo até que ele esteja pronto. No cenário dessa pessoa, como os projetos são muito pequenos é perfeitamente possível planejar tudo antes em pouco tempo e desenvolver em seguida.

Em alguns outros casos onde os requisitos não mudam waterfall também pode fazer sentido. Por exemplo, quando você desenvolve software para o governo, toda a especificação do projeto normalmente é produzida e informada antes em um edital. Algumas vezes até o prazo de entrega já está definido. Eu pessoalmente já trabalhei em vários projetos desse tipo que deram certo, que foram entregues dentro do prazo, atendendo a especificação e sem maiores problemas. Como tudo estava funcionando, não havia motivo para pensar em outra forma de desenvolvimento que eventualmente poderia trazer mais problemas do que soluções, como no caso dessa pessoa que conversou comigo.

O que eu quero dizer com isso tudo é que não existe uma metodologia que funciona para todos os casos e todos os projetos do mundo. Assim como você deve usar a melhor ferramenta para cada problema, você deve usar a melhor metodologia para cada projeto.

No projeto que eu estou atualmente estamos quebrando vários paradigmas de desenvolvimento ágil. Estamos com times gigantes, usando quadros de Lean totalmente customizados misturados com Scrum e por aí vai. Estamos sempre analisando os resultados das iterações e replanejando nosso processo. Apesar de todos os livros dizerem que os times têm que ser pequenos, estamos trabalhando com um time de 20 pessoas que dá certo e está super produtivo. Esse é o espírito: faça o que for melhor para o projeto e o que te fizer ter os melhores resultados, não o que alguém diz que é certo ou é errado ou o que está na moda.

É perfeitamente possível desenvolver projetos bons em qualquer metodologia. Entenda qual é o seu cenário, quais são os seus problemas, limitações e aí sim decida qual é a melhor forma de trabalhar nos seus projetos.

O evento está sendo organizado por mim (Guilherme Chapiewski) em parceria com o meu amigo Henrique Bastos e a realização está sendo coordenada pelas nossas experientes amigas da Arteccom (e tê-las ao nosso lado já garante que este será um evento para marcar o circuito carioca).

Nossa programação conta com três palestrantes nacionais e três internacionais falando sobre Open Source, Java, Ruby on Rails, Django e desenvolvimento ágil de software:

“O molho secreto”: como as comunidades do Joomla! e Open Source estão melhorando o cenário de tecnologia… e mudando o mundo! Ryan Ozimek é atual membro do Steering Committee da Open Source Initiative, membro da diretoria da Open Source Matters e co-fundador e CEO da PICnet Inc. Com enfoque em tecnologias open source, Ozimek está constantemente a procura de formas em que a Internet possa servir melhor o “bem maior” e, mais especificamente, as entidades sem fins lucrativos.

O Java está morto? Guilherme Silveira é especialista em Java para a web e graduando em matemática computacional na USP, ministrou diversas palestras relacionadas ao tema em eventos e empresas pelo Brasil. Atualmente é commiter do CodeHaus pelos projetos XStream e Waffle, além de um dos responsáveis pelo desenvolvimento do VRaptor.

Nico Steppat é Engenheiro da Computação Aplicada na Fachhochschule Brandenburg na Alemanha, é instrutor, consultor e desenvolve há cinco anos com Java no Brasil e Alemanha, atuando agora na Caelum com enfoque especial em EJB. É o responsável técnico no Rio de janeiro. Escreve para a revista MundoJava e possui as certificações SCJP, SCWCD, SCBCD e SCEA.

Ecossistema Ruby on Rails Fabio Akita é Gerente de Produtos de Hospedagem na Locaweb e ajudou a implantar Ruby on Rails pela primeira vez num grande hosting no Brazil. Ano passado também organizou o Rails Summit Latin America, o primeiro grande evento de Rails na América do Sul. Trabalhou na consultoria americana Surgeworks LLC, prestando serviços relacionados a projetos Ruby on Rails, com o cargo de Brazil Rails Practice Manager.

Django: o framework web para perfeccionistas com prazos Jacob Kaplan-Moss é um dos líderes de desenvolvimento e co-criador do Django. Jacob é um desenvolvedor de software experiente com foco em desenvolvimento de aplicações web e arquitetura de gerenciadores de conteúdo. Em 2005, Jacob ingressou no Lawrence Journal-World, um jornal local em Lawrence, Kansas, e ajudou a desenvolver e tornar open source o projeto Django. É também co-autor do livro “The Definitive Guide to Django” (Apress, 2007).

Desenvolvimento ágil e iterativo de produtos Jeff Patton cria e desenvolve software nos últimos 15 anos desde sistemas de pedidos de peças de aeronaves até fichas médicas eletrônicas. Jeff se focou em metodologias ágeis desde que trabalhou com um time de Extreme Programming em 2000. Em particular, Jeff se especializou na aplicação de práticas de user experience design (UX) para melhorar requisitos ágeis, planejamentos e produtos. Desde 2007, Jeff tem aplicado Lean thinking e práticas de desenvolvimento com Kanban e Scrum para ajudar times a focarem na entrega de valor.

Para fechar com chave de ouro, no encerramento do evento faremos um bate-papo com os palestrantes, alguns membros das comunidades de desenvolvimento e a participação especial do meu amigo Vinicius Teles!

Como se isso tudo já não fosse suficiente, enquanto todas essas apresentações estão acontecendo teremos sessões de Coding Dojo rolando do lado de fora com participação especial dos nossos palestrantes (caso eles consigam ficar por lá)! Estamos planejando fazer um Dojo de Python, um de Ruby e um de Java!

Será simplesmente incrível, ninguém pode ficar de fora dessa!

As inscrições podem ser feitas no site do evento (http://www.devinrio.com.br) e custam apenas R$ 65,00. Todos os inscritos terão direito a participar de todas as sessões, incluindo o Dojo.

Nosso encontro será numa segunda-feira, ou seja, se você não for do Rio de Janeiro já tem uma ótima desculpa para passar o fim de semana aqui, assistir uma ótima conferência na segunda-feira e voltar para o trabalho cheio de idéias na terça!!! Ainda estamos tentando fechar uma parceria com algum hotel para oferecer desconto para participantes do evento. Fiquem ligados nas novidades por aqui ou pelo Twitter!

Gostaria de deixar registrados meus sinceros agradecimentos para os nossos patrocinadores Locaweb e Caelum, além de outras organizações que nos apoiaram de alguma forma: Associação Python Brasil, Fábrica Livre, Open Source Matters e Myfreecomm. E por último, meu mais sincero agradecimento para a Globo.com pois ela é a principal responsável por viabilizar essa idéia! Obrigado por mais uma vez acreditarem nesse louco aqui tarado por desenvolvimento de software! Não tenho palavras pra dizer o quanto é gratificante fazer parte dessa equipe!

Então nos vemos no Dev in Rio 2009! Faça agora sua inscrição no nosso site! Fique ligado também no Twitter do @devinrio para concorrer a inscrições gratuitas!

Ah, e uma última coisa. Por favor, nos ajudem a divulgar o evento! Falem com seus amigos, postem nos seus blogs, Twitters, coloquem nossos banners nos sites de vocês, enfim, por favor nos ajudem a divulgar esse evento! Vamos fazer barulho no Rio de Janeiro!

Apresentada por Richard P. Gabriel e Guy L. Steele, a palestra 50 in 50 fala de 50 tópicos sobre linguagens de programação e 50 anos de história de computação em 50 minutos. Tem pérolas musicais como a sensacional “Eternal Flame” (também conhecida como “God had a deadline, so he wrote it all in Lisp”), representações teatrais de um programa escrito usando Shakespeare Programming Language e muito mais! É imperdível!

Para ver com qualidade melhor, acesse o video no Blip.tv da JAOO.

Como um bom desenvolvedor
Eu quero me cadastrar no Dev in Rio
Para que eu possa aprender mais e ser um profissional melhor
 
Cenário 1 - Cadastro no Dev in Rio
Dado que Eu navego para "http://devinrio.com.br/inscricoes_bra.php"
Quando Eu marco a radio "tipo_participacao" E eu clico no elemento "tipo_participacao" # ... tem que esperar a página ser carregada :) E eu espero por 5 segundos E eu vejo que a página atual contém "Login - Novo cadastro"
Então # Login Eu preencho a caixa de texto "email" com "seu@email.com" E eu preencho a caixa de texto "senha" com "senha" E eu preencho a caixa de texto "re_senha" com "senha" # Dados Pessoais E eu preencho a caixa de texto "nome_cracha" com "Pyccuracy da Silva" E eu preencho a caixa de texto "empresa_cracha" com "Globo.com" E eu preencho a caixa de texto "dd" com "01" E eu preencho a caixa de texto "mm" com "01" E eu preencho a caixa de texto "aaaa" com "1980" E eu preencho a caixa de texto "cpf" com "12345678910" E eu preencho a caixa de texto "ddd" com "21" E eu preencho a caixa de texto "telefone" com "23452345" E eu preencho a caixa de texto "ddd2" com "21" E eu preencho a caixa de texto "telefone_celular" com "23452345" # Endereço E eu preencho a caixa de texto "cep" com "23456789" E eu preencho a caixa de texto "endereco" com "Rua de Exemplo" E eu preencho a caixa de texto "numero" com "123" E eu preencho a caixa de texto "complemento" com "ap 101" E eu preencho a caixa de texto "bairro" com "Meu Bairro" E eu seleciono o item com texto "Rio de Janeiro" na select "estado" # ... tem que esperar o treco carregar os municipios :) E eu espero por 5 segundos E eu seleciono o item com texto "RIO DE JANEIRO" na select "municipio" # Seu perfil - pode colocar qualquer coisa :) E eu seleciono o item com valor "Outros" na select "ocupacao" E eu seleciono o item com valor "Superior completo" na select "escolaridade" E eu seleciono o item com valor "Amigos" na select "conhecimento" E eu seleciono o item com valor "Outra" na select "areas_atuacao" E eu clico no botão "sis_submitbutton2" E eu vejo que a página atual contém "sucesso" # E pra terminar, espera um pouquinho pra ver que a inscrição funcionou E eu espero por 10 segundos

Depois disso é só rodar com o comando “pyccuracy_console -l pt-br” e pronto, você já está cadastrado! Basta agora acessar o site para efetuar o pagamento com o seu cartão de crédito!

E agora, a promoção surpresa!

Ganha uma inscrição como convidado para o Dev in Rio e um kit de brinde da Globo.com (com camiseta, pen drive de 4GB e etc.) o primeiro programador que terminar o que falta do script, ou seja, fazer o pagamento completo por cartão de crédito ou boleto bancário, tanto faz (e antes que algum engraçadinho tente, não vale ninguém que já trabalha com o Pyccuracy aqui na Globo.com, hehe).

Só estará participando da promoção quem enviar os scripts aqui pelos comentários e eu vou seguir a ordem de postagem. O primeiro script que funcionar leva o prêmio!

Divirtam-se!

Ano passado eu fui e foi sensacional e esse ano promete ser ainda melhor! A programação está bem diferente do ano passado e conta com algumas novidades como Bryan Liles, Gregg Pollack, Jason Seifer, Pratik Naik, Richard Kilmer, Matt Aimonetti, além do pessoal que veio ano passado como Chad Fowler, David Chelimsky, Obie Fernandez e brazucas feras demais como o Fabio Kung, Marcos Tapajós, Nando Vieira, Vinicius Teles, Leonardo Borges, Carlos Brando e por aí vai. Enfim, não dá para perder de jeito nenhum!

Nós cariocas (eu, Henrique, Rafael, Sylvestre, Tapa, Vinicius, Ramon e quem mais for) vamos todos ficar no mesmo hotel pra fazermos a maior bagunça! Seguindo o exemplo do Vinicius Tapajós no ano passado, estamos divulgando o hotel pra que todo mundo possa ir pra lá e aumentar a bagunça.

Ficaremos hospedados no Holiday Inn Parque Anhembi que é dentro do Centro de Convenções Anhembi (o mesmo local do evento). O telefone para reservas é 0800-770-0858. Não é o hotel mais caro e nem o mais barato mas é pertinho do evento e fica bem fácil pra todo mundo. Nos vemos lá!

• Canal de vídeos do Dev in Rio no Vimeo
• Grupo de fotos do Dev in Rio no Flickr

Eu e Henrique acabamos de terminar um vídeo super especial de recordação do maior #Horaextra de todos os tempos! Espero que vocês gostem:

Colaborar com outros projetos é bem fácil no Github, basta fazer um fork do projeto que eu pretendo colaborar, fazer minhas modificações e depois um “pull request” para o dono do projeto avaliar e integrar (ou não) o meu código ao dele. Antes do Github não funcionava muito diferente disso mas o que ele fez de bom foi facilitar esse fluxo e criar uma rede social bem interessante em torno desse mundo.

Isso é bem diferente de como as empresas normalmente funcionam. No caso da Globo.com, por exemplo, todos os repositórios sempre estiveram amontoados nos servidores CVS e Subversion e consequentemente “escondidos” (pouco visíveis) de possíveis colaboradores. Alguns até tinham permissão de commit restrita para um pequeno grupo e o processo de colaboração era ainda mais difícil. Não dá nem para abrir um branch seu, você tem que fazer as modificações localmente e mandar um patch por e-mail, e o merge geralmente não é muito fácil de fazer quando você tem um grande fluxos de merge para lá e para cá. Imagina então quando você trabalha na versão “v1″ do código e enquanto você produz a “v2″ um outro desenvolvedor pede merge antes de você? Era preciso esperar o merge terminar para dar checkout da versão nova e ficar mais uma vez fazendo o inferno do merge.

No início desse ano resolvemos experimentar usar o Gitorious, que é uma ferramenta similar ao Github porém Open Source e que você pode instalar num servidor da sua empresa. Isso tinha 2 objetivos: (1) criar uma cultura de “enterprise” Open Source e (2) facilitar a colaboração em projetos em que vários times trabalham e commitam ao mesmo tempo.

No início foi um inferno e houve uma rejeição muito grande de muita gente. O modelo de trabalho com o Git é bem diferente do que com CVS e Subversion. Você tem branches (e clones – que é um conceito um pouco diferente) que podem ser locais ou remotos, commits locais que não vão direto para o servidor e pulls/pushes. As pessoas tendem a fazer relações do tipo “o push é o que manda as coisas para o servidor, então ele equivale ao commit”. Mas então o que é o commit do Git? Enfim, não dá pra trabalhar pensando assim, é preciso dar um reset e entender a arquitetura desses sistemas de controle de versão distribuídos para entender que faz sentido sim ter um commit e só depois do push que o código está no repositório (no remoto, porque no local já estava).

Também foi difícil aprender a trabalhar com merges. No modelo antigo você evita fazer merges o máximo possível porque o trabalho para fazer isso é enorme. Geralmente você só faz quando acabou de fazer tudo para ter trabalho uma vez só. Ainda bem que existem ferramentas para ajudar (como as ferramentas das próprias IDEs) senão seria complicado. Se você trabalha da mesma forma com o Git geralmente vai se dar mal, porque não existem (não existiam mas estão começando a melhorar) as mesmas ferramentas de merge visual do CVS ou Subversion, e era um parto para fazer a coisa toda funcionar após fazer um merge de uma semana de fork. Com o Git funciona ao contrário: como o merge é automático (na maioria dos casos ele consegue se virar) então a estratégia é fazer merge toda hora, várias vezes por dia, o máximo que der.

Depois de alguns meses de “fricção” hoje já dá para ver um monte de frutos começando a aparecer. Por exemplo, no último sprint do meu time nós precisavamos usar um cliente Python para acessar a engine de busca da Globo.com. Como esse cliente era novo tinha uma série de problemas pequenos que precisavam ser resolvidos, mas o time que é responsável pelo projeto estava com vários compromissos e demoraria 2 semanas para trabalhar nisso. Então o Bernardo e o Andrews decidiram fazer um clone no Gitorious para contribuir com o projeto do time de busca, e eles não só resolveram os problemas como devolveram o código refatorado e com a cobertura de testes bem melhor. O outro time rapidamente integrou o novo código ao projeto e gostou tanto do trabalho deles que eles viraram commiters e agora podem fazer as modificações que forem necessárias em colaboração com o time de busca. Exatamente como funciona no mundo Open Source.

Além desse exemplo, no projeto que estou trabalhando (que é um framework para sites de publicação de conteúdo) temos vários times trabalhando no mesmo código ao mesmo tempo. Nesse momento tem cerca de 10 clones do projeto no nosso Gitorious e talvez cerca de 10 times trabalhando usando o mesmo código para fazer seus “add-ons”. O Git facilita o trabalho dos times para atualizarem constantemente sua base de código com o que entra de novo no branch master do mainline (o repositório principal do projeto) e o Gitorious torna isso tudo mais visível para todos.

Enfim, as vantages que nós passamos a ter com o Git e Gitorious são várias:

• Todo mundo pode ver facilmente os projetos que existem e quando novos projetos são criados;
• Todo mundo pode ver o que todo mundo está fazendo e em que estão trabalhando;
• Todo mundo pode facilmente criar e gerenciar seus projetos (sem precisar do Sys Admin);
• É bem facil de navegar nos projetos, ver e pegar código dos outros;
• Todo mundo pode criar seus clones de repositórios para trabalhar em cima do seu código e do código dos outros;
• Todo mundo pode colaborar de volta sem precisar de um processo complicado para isso;
• É mais fácil de fazer merges constantes e gerenciar múltiplas colaboracoes simultâneas;
• Fora as outras features interessantes que o Git tem e os sistemas de SCM antigos não como o stash, clones, merge automático e por aí vai.

Só para dizer um ponto negativo, a documentação de usuários do Git não é das melhores (mas tem melhorado bastante) e alguns comandos não são tão intuitivos (como deletar um branch remoto), mas nada que você não descubra e que não se acostume com o tempo.

Aconselho fortemente a todo mundo que puder que faça isso. Instale o Gitorious e fomente a colaboração entre os desenvolvedores da sua empresa! Se você estiver com muita grana também pode dar uma olhada no Github Firewall Install, que deve ser bem legal mas também é bem caro.

Mesmo tendo sido idealizado, planejado e executado em pouco mais de 20 dias, o Dev in Rio 2009 foi excelente, um sucesso total! Conseguimos reunir em plena segunda-feira cerca de 400 pessoas para falar de desenvolvimento de software, se divertirem no Dojo e terem um dia de muita diversão que terminou no maior #Horaextra de todos os tempos.

O Dev in Rio 2009 começou na hora programada quando eu e meu amigo Henrique Bastos abrimos o evento. Rapidamente falamos sobre o evento e sobre como seria o nosso dia. Tratamos de como achamos importante a interação entre comunidades e aprender com pessoas especializadas em tecnologias diversas. Aproveitamos também para agradecer muito aos nossos patrocinadores, apoiadores, comunidades e amigos que nos ajudaram muito mais do que vocês possam imaginar.

* Henrique Bastos e eu na abertura do Dev in Rio.

Abrindo os trabalhos, disparamos as duas trilhas do Dev in Rio 2009. No auditório principal, aconteceriam as palestras programadas, enquanto no foyer seria realizado o Coding Dojo.

O Coding Dojo é uma arena de programação organizada pela turma do Dojo Rio em conjunto com o Dojo@SP. A idéia é atacar problemas simples e lúdicos, utilizando técnicas de programação como Test-Driven Development e Modelagem SOLID. Este definitivamente foi o gol de placa do dia – o Dojo funcionou muito melhor do que nós poderiamos imaginar (exceto o Dojo de Java que não foi lá muito popular, tenho que admitir).

* Coding Dojo do Dev in Rio: 3 metros de código na parede!

* Galera participando do Coding Dojo do Dev in Rio.

A primeira palestra foi a do Ryan Ozymek, que entrou em cena com seu famoso pinguim para falar de sua experiência com software livre e a comunidade Joomla! Ele detalhou o funcionamento de uma grande comunidade de desenvolvimento e deu sua visão de empresário sobre como usar software livre para alavancar os negócios da sua empresa.

Logo depois, Guilherme Silveira e Nico Steppat trataram de um tema bastante polêmico: Java está morto? Abordaram os fatos de que existem muitas coisas além da linguagem no mundo Java e que apesar da linguagem estar “caducando” a JVM ainda pode ser muito útil.

Depois do almoço, Fabio Akita não deu trégua para quem estava com sono e fez uma excelente apresentação sobre o ecossistema Ruby on Rails com direito a videos, screencast e bastante informação além do código. Ele não sabe mas tirou o fôlego das meninas da tradução simultânea!

Na sequência, o (praticamente carioca) Jacob Kaplan-Moss fez sua apresentação sobre Django, o framework web para perfeccionistas desenvolvido em Python. Ele falou dos conceitos e valores que guiaram o desenvolvimento do projeto, além de mostrar um pouco de código para dar uma idéia ao público de como usar o Django na prática.

A última palestra do dia foi feita por Jeff Patton, que falou sobre desenvolvimento de produtos com métodos ágeis. Utilizando como narrativa a história de um projeto realizado em conjunto com Obie Fernandez, diversos problemas comuns no desenvolvimento de software (e suas soluções) foram destacados.

No final, nosso grande amigo Vinicius Manhães Teles liderou um bate-papo entre palestrantes, comunidades e o público. Tivemos a impressão de que se não controlassemos o relógio a conversa teria varado a noite, pois não faltavam assuntos e perguntas interessantes. O público participou bastante e foram levantadas questões como empreendedorismo e polêmicas como a estúpida regulamentação da profissão de analista de sistemas.

* Discussão liderada por Vinicius Teles. E antes que alguém pergunte, não, não é o cara do Myth Busters que está na foto, é o Jeff Patton.

Enquanto isso tudo rolava, eu, Henrique e o Gustavo Guanabara e a Flavia Freire (jornalista da Arteccom) passamos o dia gravando um gigantesco Podcast do evento, entrevistando o pessoal e filmando os bastidores. Falamos com palestrantes, patrocinadores e participantes sobre todos os assuntos abordados nas palestras! Guanabara, termina logo de editar esse treco porque eu tô ansioso pra ouvir! Veja o “making of” de alguns dos Podcasts com o Ryan Ozimek, com Guilherme e Paulo Silveira e com Fabio Akita e Marcos Tapajós. Assim que finalizarmos as edições vamos divulgar todo esse material.

* Guanabara gravando Podcast com Fabio Akita e Marcos Tapajós (e datalhe: ao fundo Guilherme Silveira e Paulo Silveira fazem Pair Programming).

Como o evento foi realizado numa segunda-feira, fechamos o evento convidando todos os participantes (ao som de “Estamos todos bêbados” do Matanza e com coreografia de Sylvestre Mergulhão e Henrique Andrade) para uma edição épica do #Horaextra no Lapa 40º. A entrada era gratuita para quem apresentasse o crachá do Dev in Rio 2009 e assim realizamos o maior #Horaextra de todos os tempos:

* Veja mais videos do Dev in Rio 2009.

Tenho certeza de que esse post não consegue transmitir 0,001% do que foi o Dev in Rio 2009 e a minha felicidade de ter conseguido realizá-lo. Gostaria de agradecer mais uma vez o apoio fundamental de toda a galera da Globo.com que viabilizou o evento, dos nossos patrocinadores Caelum, Locaweb e D-Click e de todos que nos apoiaram de alguma forma: Associação PythonBrasil, Fábrica Livre, Myfreecomm, OpenSourceMatters, Arteccom, DojoRio, Dojo@SP, #Horaextra, PythOnRio, RioJUG, RubyInside Brasil, Guanabara.info e todas as pessoas que participaram do Dev in Rio 2009. Sem vocês nada disso teria sido possivel.

* Participantes da mesa redonda do Dev in Rio.

Se você não foi no Dev in Rio, tenho duas coisas para te dizer: (1) você perdeu uma farra das melhores mas (2) em breve vamos disponibilizar os vídeos das apresentações para amenizar sua dor.

E que venha 2010!

Eu, Guilherme Cirne, Emerson Macedo e Anselmo Alves já estamos preparando as malas para ir no Rails Summit 2009 (isso sem falar do resto da galera do Rio de Janeiro que também vai em massa)!

Tá afim de ir também? Então faça um vídeo criativo explicando porque você também quer ir na Rails Summit 2009 e poste o link aqui nos comentários. O vídeo mais criativo (que será escolhido por mim e o Fabio Akita até o fim do dia 07 de outubro) vai ganhar um convite para a Rails Summit 2009!

Ficou muito muito divertido! As entrevistas com os palestrantes Ryan Ozimek, Guilherme Silveira, Fabio Akita e Jacob Kaplan-Moss ficaram ótimas e ainda conseguimos alguns convidados especiais para participarem na hora como o Paulo Silveira, Marcos Tapajós e Mauricio Samy Silva (o Maujor). Uma pena que o Nico Steppat e o Jeff Patton não puderam participar mas fica para a próxima.

Ainda, quem quiser ver o “making of” do Podcast pode acessar os vídeos no canal do Dev in Rio no Vimeo.

Amanhã será o primeiro de dois dias de tutoriais seguidos de dois dias de conferência com a participação de grandes nomes do mundo ágil como Jeff Patton, Alistair Cockburn, Mike Cohn, Jim Highsmith, Andy Hunt, David Hussman, Joshua Kerievsky, Linda Rising, Alan Shalloway e por aí vai. Para encerrar, na sexta-feira acontecerá o Agile Leadership Summit liderado pela Pollyanna Pixton.

Os próximos dias prometem!

Esta é a minha segunda participação nessa conferência sensacional com alguns dos melhores palestrantes e profissionais de desenvolvimento de software do mundo!

Espero conseguir colocar os posts em dia durante a semana.