1up4Developers

Este post é uma homenagem aos Arquitetos defensores do waterfall/cascata.

Recentemente tive o desprazer de conhecer um arquiteto, é isso mesmo, aquele com certificado e tudo, com direito a broche da Sun em seu terninho. Aliás, certificado é um tema polêmico que eu não tenho uma opinião muito certa e/ou formada… bom, vou deixar esta parte para um próximo post, quem sabe.

Voltando ao assunto, hoje no fretado, comecei a pensar nas semelhanças que um arquiteto de sistemas (certificado que decorou patterns inutéis da Sun) tem com um arquiteto de obras. Só para deixar claro, na tabela abaixo estou usando dois estados: FAIL e Ok. Fail quer dizer que vai dá merda não vai dar certo e não tem jeito, caso queira uma definição mais formal, o wikipédia ajuda, agora se você prefere imagens, o Fail Blog também serve.

Exemplo de FAIL

Parei a tabela por aqui pois já dá pra saber que o FAIL tende a infinito né.
Pergunta: o que ambos arquitetos estão fazendo!?!
Resposta educada: Estão fechando o escopo do projeto.

Arquiteto Cascateiro trabalhando ...

A resposta acima é uma frase chave pra você ter certeza que vive num projeto waterfall cascateiro. Fechar o escopo do projeto inteiro deve ser muito bom para o arquiteto de obras, já para um sistema, o efeito é contrário. Acredito muito na teoria que desenvolver software não é construir prédios. Livros de renome como Pragmatic Programmer citam isso.

Sei que este tema de construção civil já está batido. Comecei a escrever este post ao mesmo tempo que o Sr. Panachi publicou o anterior, e com a idéia de ficar menos repetitivo, já vou linkar as sugestões dos nossos incríveis leitores:

• O Diego Carrion (grande peruano! :D) cita este link, que fala que a engenharia civil também consegue ser ágil em alguns casos.
• O Witaro, fez um ótimo post “Desenvolvendo software como uma Rock Band” que quebra a barreira da analogia com a engenharia civil. Cara, continue escrevendo, porque a sua visão é muito legal!

Bom, agora que acabou o desabafo, vamos as possíveis soluções. O que fazer com o Arquiteto Cascateiro?

Acho que a primeira coisa seria conscientizá-lo de que ele não é o Oscar Niemeyer e que a primeira versão de seu software nunca será completa de uma vez. Você deve conversar sobre iterações com ele e mostrar que o software deve evoluir conforme o cliente também evolui nas descobertas das suas reais necessidades. Sei que o post já está cheio de links, mas este post do Phillip Calçado, Analista Pedreiro, resume bem o que quero dizer.

Arquiteto, este nome ou termo ou cargo ou seja-lá-o-que-for, é coisa de modelo waterfall/cascata. Numa equipe, não deve haver distinção desta maneira. Todos programam, modelam, configuram, trabalham no Banco de Dados quando necessário, ou seja, ninguém deve exercer um papel único. Papéis únicos, representam Guardiões que defendem somente seus interesses e não trabalham em pró da equipe/cliente/projeto.

O Arquiteto deve programar, colocar a mão na massa, assim como toda a equipe, pois UML, Caso de Uso, Diagrama de Sequência, etc. sempre compilam! Muito diferente na vida real, onde muitas vezes você é obrigado a implementar uma coisa diferente e torta para acompanhar estes documentos cascateiros. Caso você seja obrigado a gerar a documentação fútil acima, pense em algo que seja automatizado após você ter programado e testado, com certeza você será umas cinco vezes mais produtivo.

E por último e não menos importante, a equipe (inclusive o Arquiteto) tem que conhecer o negócio que implementa. Quando se inicia um novo projeto ou até mesmo decidem reestruturar um existente, o arquiteto cascateiro sempre prioriza novas tecnologias e frameworks, o que na maioria das vezes, não é necessário. Novos projetos ou refactoring em existentes, devem ter um único prioritário objetivo: KISS. Com esta prioridade em mente, novas tecnologias e frameworks serão escolhidos naturalmente, e não somente usar porque é a última moda no estilo SunTechDays.

E vocês leitores?! Sofrem ou já sofreram muito com Arquitetos Cascateiros!?!

Não sei nem como começar a descrever o evento, foi muito bom !!! Logo no primeiro dia, na fila para pegar o pequeno cracha de identificação, já trombei logo com quem !?! Dr. Nic ! E ao seu lado, estava um cara muito simpático também, que de primeira não reconheci, o Chad Fowler e sem barba ! E pra quem não acredita, bom, tirei foto com o figura como prova ! (está aqui no album do flickr)

Palestrantes RailsSummit

Todas as palestras foram muito interessantes, no segundo dia, o tema testes foi muito abordado e acabou ficando repetitivo, porém o pessoal aproveitou para atualizar seus e blogs e tals. Na minha humilde opinião, as apresentações de abertura e final do evento foram as melhores ! Na abertura, destaque para o video que o pessoal do Rails Envy mandou !

Sem se preocupar em parecer repetitivo, mas a principal mensagem das palestras foram, “faça!”. Tudo se resume a ação!, ajude projetos open, crie novos projetos, participe com diferentes papéis, leia, escreva blogs, livros, screencasts, wikis … etc. Teve muita mensagem motivacional, e eu confesso que gostei !

É complicado tentar repassar a enxurrada de informação que veio do evento, e por serem parecidas, eu acabo misturando as informações. Resumão: Metodologias Agéis, teve bastante coisa sobre e com perspectivas diferentes, cool!

Parte do Chad Fowler, foi muito legal, com sacadas interessantes do “meio corporativo”, e apresentou questões filosoficas sobre a evolução de frameworks. Logo em seguida, teve uma conferência com o DHH (David Heinemeir Hansson), falou sobre o futuro de Rails, falou sobre thread-safe do Rails 2.2.

Palestra do Brando foi muito legal, e deu uns toques importantes de como conseguir aquele seu emprego rails tão desejado, sem contar o chefe dele, Carl, grande figura.

Depois teve o Chris Wanstrath (criador do github.com), é impressionante o tanto que ele batalhou pra chegar aonde o github é hoje, foi meio chato porque ele ficou lendo, mesmo assim, teve informações legais.

No final, o BOF (Birds of a Feather) foi um show a parte! Várias figuras, falando desde projetos em desenvolvimento até a técnicas de impor novas idéias … várias figuras, várias risadas.

O segundo dia de evento, começou muito interessante, com a apresentação muito boa - dei muita risada em várias partes - Ninh Bui e Hongli Lai os emos caras do Phusion ! Foi muita piada nerd, várias animações flash, citações de mega man à dragon ball, com direito a Star Wars no final …

Phusion Darth Vader !

Depois assisti a palestra do Jay Fields. Foi muito legal, ele apresentou o lado bom e ruim de vários frameworks de testes como selenium, rspec e talz. Destaque para o momento flame, quando o David Chelimsky mantenedor do rspec, começa a questionar alguns pontos levantados por Jay. Não se preocupem, que tudo acabou em breja …

Assisti a palestra do Vinicius Teles, cara, sensacional ! A palestra foi sobre empreendedorismo, com participação especial do Carl (da SurgeWorks), ficou muito legal a “union” das apresentações, e esta com certeza merece um post separado-extra.

Chegando ao final do dia, começou a bater o cansaço … assisti a palestra do Fabio Kung sobre JRuby. Ele entrou em detalhes na plataforma Java e como é executado o código ruby nela. Foi muito legal, porque eu finalmente entendi a diferença entre “servers” e talz. Eu não lembro muito ao certo, se eu tiver acesso a apresentação, coloco o link aqui.

Pra finalizar teve o fechamento com o Obie Fernandez, ele mostrou de maneira apaixonada e apaixonante, como está funcionando sua nova empresa, a HashRocket. Mostrou o manifesto agil, primeiro em papel e depois na vida real com os fatos da sua empresa. Mostrou que testes funcionam, programação em par também funciona! e etc. Foi muito show, acho muito legal a forma que ele conduz a apresentação.

1up4dev and ... Obie !

O evento fechou com chave de ouro, rolando várias brejas, e isso eu te garanto, é muito louco brindar com o Dr. Nic e Obie na mesma roda !

Além de tudo isso, é muito interessante como o espirito de “integração” é muito alto, por exemplo, o Diego Carrion do MouseOver Studio ficou com nosso grupo, os dois dias, trocamos experiências, foi show também. Até agora, a única apresentação que peguei foi a do Dr. Nic, que ele disponibilizou o link via twitter.

Me desculpem pelo tamanho do post … e como ele está muito grande, nem vou ler em busca de erros, vou arrumando conforme necessário, ou seja, fica pro próximo sprint !

Depois de ler The Pragmatic Programmer é natural ficar empolgado, bom, uma prova disso foi meu próprio post sobre o assunto. Depois de ter “digerido” o livro, lancei as dicas para o desenvolvedor, acabei inventando um termo legal The Pragmatic Waterfall, que resolvi transformá-lo numa série.

A primeira dica do “dicas para o desenvolvedor”, foi:
- Gerador de código descartável.

Pois bem, hoje, vou mostrar um exemplo de “código descartável” que utilizei e deu certo !

Problema: No projeto que estou existem algumas queries em arquivos XML do hibernate, preciso convertê-las para Spring. Pra cada query do hibernate, precisei gerar dois arquivos de XML do Spring e mais uma classe Java que herda de SqlUpdate … blá blá blá. Bom, os detalhes não importam muito, o que importa é que vamos ler o XML do hibernate e gerar o que for necessário, tudo isso com Ruby!

Antes de qualquer coisa, já aviso que ainda não domino totalmente Ruby, e o script que fiz é do tipo código “descartável”, então não tive o menor cuidado em deixá-lo bonito, apenas funcional. Acho que a melhor maneira de aprender uma nova linguagem é escrevendo código com ela, não somente lendo sobre.

Exemplo super simplificado do XML do Hibernate:
script generator-bean em Ruby:

É isto ! O script é simples e direto, deixei a saida pro console mesmo e para jogar em arquivo é muito simples:

$ ruby generator-bean.rb > spring-exemplo.xml

O script que coloquei é uma versão bem reduzida, já que a idéia do post é mostrar que é possível transformar tarefas chatas e trabalhosas em scripts semi-automáticos ! Ah, lembrando que com ele consegui terminar a minha tarefa em 2 dias, sendo que a previsão era quase uma semana de trabalho !

Precisa de mais informações de como ler XML com Ruby !?

Segue as referências.
Tirei deste post, muito legal por sinal.
* API do REXML: http://www.ruby-doc.org/stdlib/libdoc/rexml/rdoc/index.html
* Sobre o Electric XML: http://www.xml.com/pub/r/1098
* Tutorial um pouco mais complexo sobre XML com Ruby: http://www.xml.com/pub/a/2005/11/09/rexml-processing-xml-in-ruby.html

OBS: Estou usando o gist.github.com para colocar o xml e script de exemplo, provavelmente não vai aparecer no leitor de feed.

Divulgação:

Pessoal, o Akita deu a Largada para o Maior Evento de Rails da América Latina!

Eu não vou perder ! O mais difícil foi convencer a patroa do gasto no cartão de crédito !

Pra quem quiser ir aquecendo os motores, e codificando Ruby, vou deixar alguns links ! (Coloquei o blogroll do meu Reader, não sei se vai aparecer via feed ! Pros curiosos, acessem o post.)

Comecei a participar da lista rails-br, dentre as várias discussões interessantes, tem esta, Brazilian Rails Blogs, com mais blogs sobre Rails.

Sucesso! E nos encontramos lá !

Olá Pessoal, terceira reinauguração do blog, e agora finalmente resolvemos o sonho do dominio próprio !

Uma das grandes dificuldades para quem está iniciando com Ruby on Rails no linux, é descobrir qual editor usar, já que o sempre-citado Textmate é somente para Mac.

O que eu estou usando atualmente é o gedit, editor de texto padrão, que vem com o Ubuntu e provavelmente com o Gnome.

Quando comecei minha busca pelo editor perfeito, encontrei vários tutoriais que ensinavam a encher o gedit de plugins, só que era muito manual, tinha que baixar um por um … quando tive que fazer a segunda vez, desisti, e resolvi buscar por soluções melhores.

Sempre ouvi o Rails Podcast, e em algum destes, o Carlos Brando citou o github. Entrei lá, e fui verificar o que tinha de bom, e até hoje não sei como encontrei os projetos, só sei que comecei a usá-los.

Vamos ao que interessa !

No projeto gedit-rails faça o download aqui ou clique em download na página do projeto (estamos no linux, use o formato tar). Descompacte o arquivo, entre na pasta e execute o install.sh veja a imagem abaixo:

install do gedit-rails

No projeto gedit-themes você encontrará temas para o visual do gedit, o meu preferido é o darkmate, acho muito confortável para os olhos, mas existem várias opções. O processo de instalação é mais simples que os plugins.

Baixe os temas em tar aqui ou no botão download na página do projeto. Descompacte o tar numa pasta separada, e na tela de preferências, fontes e cores do gedit, você consegue adicionar o novo tema que deseja.

Veja o resultado aqui:

Infelizmente estou sem tempo para entrar nos detalhes de cada plugin, de qualquer maneira, vou deixar aos interessados os links, que contém informações valiosas:

• HTML Tidy
• Rails Hot Commands
• Rails Hotkeys
• Snapopen

Existem muitos plugins para o gedit, caso estejam procurando por mais, tentem na Lista de Plugins para o gedit do Fernando Vieira, e tem também a lista oficial de plugins do gedit.

Dicas de novos plugins, comentários e/ou críticas são bem vindas !

Abraço e sucesso!

UPDATE: Sugestões do Philipe Farias, via comentários ! Valeu pelas dicas !

Plugins:

- Snippets ou Trechos - padrão do Gedit (tem que ativar). Quando o gedit-rails é instalado ele adiciona os snippets para erb, ruby e shoulda;

- gedit_formatter

- gemini

- gedit TODO list

Esta parte é interessante para seguir ao padrão Ruby, “Recomenda-se também configurar a “largura das tabulações” para 2 e ativar “inserir espaços em vez de tabulações” nas preferências do Gedit”.

Aqui já entra configurações mais pessoais que você encontra na tela de preferências do gedit. Também de ativar “mostrar números de linhas”, “destacar linha atual” e “destacar parêntesis correspondentes”.

Quanto ao esquema de cor acho o Oblivion mais “completo” para Rails. Screenshot do gedit com Oblivion:

Olá a todos !

Sei que estão estranhando … perceberam que não tem Waterfall no título ? Pois bem, hoje não vou chorar e digo mais, vou até fingir que não vivo num Waterfall e vou falar sobre TESTES ! Tá bom, sei que enfatizei demais, só vou fazer uma resenha sobre este último livro que li mesmo.

Numa leitura leve e até divertida (sou nerd mesmo), os autores abordam conceitos práticos de testes que não estão ligados diretamente ao JUnit, e sim a “Filosofia de Testes”. O legal que os principais conceitos são apresentados com acrônimos como “Right BICEP”, “CORRECT Boundary Conditions”, “A TRIP”, MockObjects e etc. Depois da passagem por todos esses acrônimos, os próximos capítulos atacam temas como, onde colocar os testes, design dos testes e etc.

Isso pode parecer estranho, mas de todos os capítulos o que eu mais gostei foi do primeiro, a Introdução, talvez porque no momento estou com a água do waterfall até o pescoço, e nele os autores colocam as dicas de como contra-argumentar as desculpas para não fazer testes. Exemplos dos tópicos, “Por que devo me importar com testes ?” e “Desculpas para não testar”, parece que os autores realmente conhecem o lado negro da força. Por sinal, achei este último tão interessante, que estou pensando em pedir permissão para traduzi-lo e postar aqui, se alguém souber o caminho das pedras e quiser ajudar eu peço a gentileza de entrar em contato.

Gostei muito do livro, o considero uma ótima referência sobre o tema, veja bem, referência, pois se queres uma biblia do JUnit, descarte-o. Sei que muitos da nossa área não conhecem nada sobre o assunto, e um ótimo começo seria por ele.

Agora, voltando um pouco pra minha (e de muitos) realidade cruel, antes de ler o livro eu imaginava (ou sonhava ?) que o sistema atual em que trabalho, poderia ser implantado testes, agora, com uma visão mais pragmática, tenho certeza que estava certo, só que mirando na camada errada. Aqui, a maioria da lógica (uns 90%) está em PL/SQL no banco, e a melhor maneira de implantar testes seria começando com um PL/SQLUnit … mas aí já é assunto pra outro post. Ahh, ainda não pesquisei, mas deve existir com certeza.

Chegando ao fim do livro …

Uma parte chata do livro foi quando terminei de lê-lo, confesso que fiquei com uma vontade de “quero mais” e acabei ficando com a impressão de que só li a ponta do iceberg sobre o tema. Sugestões de mais livros sobre o tema, são bem vindas !

Não é só de Waterfall que este blog vive. Ele também nasceu pra ajudar o software livre ! Eu sei, não temos nenhum post sobre isso, mas isso é questão de tempo eu prometo.

Como grande fã que sou do BR-Linux, estou aderindo a campanha ! E com certeza todos os autores deste blog concordam comigo, que noticia do mundo livre é no BR-Linux.

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!
…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Falta pessoal qualificado em TI, diz Assespro

http://www.guj.com.br/posts/list/15/92783.java#497015

Esta discussão está boa, e no meio das chamas levei um “impacto” ao ler a frase abaixo.

louds wrote: [...] Não usem a incompetência alheia como desculpa. Se está ruim e você não está ativamente combatendo isso, você é parte do problema e não da solução. [...]

Esta é uma das frases que eu deveria lembrar toda vez que começo a lamentar sobre o ambiente atual de trabalho, eu tento, me gerencio, mas confesso que é difícil.

Com o diabinho no ombro, logo ouvi um suspiro … Waterfall é bom ! Não questione … volte a codificar … Só que ao olhar pro lado, vi o meu poster do Dijkstra e voltei a realidade. Foi quando me perguntei:

Por que é difícil combater o Waterfall ?!?

Sei que esta é uma pergunta sem resposta direta e que depende de muitos fatores do seu ambiente de trabalho, mas eu numa análise fria e cruel respondo: Porque a maioria não sabe o que é waterfall.

No último ano da faculdade (cursei Sistemas de Informação), e sem brincadeira, nas aulas de Engenharia fui obrigado a decorar todas as fases, papéis, artefatos e etc. do RUP, e pra fechar com chave de ouro, no segundo semestre veio o famoso Análise de Ponto de Função. Isso somente prova que já aprendemos errado, e sei que muita gente fica nisso. Se hoje tivesse a oportunidade de encontrar este mesmo professor, iria fazer a pergunta acima, e acrescentar com questionamentos como, engenharia de software não é eng. civil e neste processo todo quem está preocupado com o Retorno de Investimento do cliente !?!

Acredito que a chave para combater o Waterfall é conhecimento, temos que trazer questionamentos a quem está do lado e isso não é nada fácil, como você convence os mais de vinte desenvolvedores que estão ao seu redor que eles estão na Matrix !?! O que fazer com o pessoal que não quer sair da Matrix !?! O Waterfall é uma grande mãe que coloca muitas pessoas (Analistas, Desenvolvedores, Gerentes, Testers … etc.) numa casca irreal de proteção e que gera um ciclo vicioso que se auto sustenta.

Neste exato momento que sou obrigado a concordar com o grande malucão Raulzito:

É pena não ser burro ! Não sofria tanto.

As vezes me questiono sobre esta insistência em tentar mudar, nadar contra o Waterfall. Não seria melhor se “render” logo e entrar no jogo, sei lá, poder falar, “Caso de Uso não é comigo, só programação!” e ver que são 10 pras 18, desligar o computador e sair sem o minimo peso na consciência.

Por que numa equipe de dez desenvolvedores, só eu sinto falta de testes unitários !?! Fico indignado ao receber um caso de uso que não agrega nada ao cliente, somente foi “inventado” pra ser cobrado dele, e só eu que vejo isso !?! Sei lá, eu devo estar maluco mesmo com toda esta historia de desenvolvimento ágil, e se preocupar com ROI do cliente, apesar de achar uns malucos por ai que sofrem do mesmo “problema” que o meu.

Como no filme dos 300, tenho esperanças e sei que poucos enfrentarão muitos, e continuo minha batalha com o Waterfall.

Paz a Todos !

Obs: Sei que o RUP é mal usado, pois uma brecha dele é ser muito genérico, e isto cada vez se confirma mais, que o modelo atual “tradicional” está falido.

Estou lendo o consagrado The Pragmatic Programmer, o livro é ótimo e faz com que eu tenha certeza que sou um sadomasoquista -calma, eu vou explicar-. Da sua capacidade técnica eu nunca desconfiei, pois sempre é citado nas lista de “top hits” de pessoal muito bom como o Guilherme Chapiewski e Phillip Calçado.
Agora entra a explicação do sadomasoquismo … ler um livro destes, realmente nos faz pensar, tanto em corrigir hábitos ruins que adquirimos com o tempo, quanto novas possibilidade em automatizar todas as tarefas rotineiras por exemplo. Até ai tudo bem, maravilha, o livro até parece uma auto-ajuda alá Paulo Coelho para o programador sofrido e abatido pelo rotina Waterfall … E é nesse momento que volto a realidade e lembro que não sou um programador e muito menos pragmático, pois aqui, no real world Waterfall eu sou apenas um macaco digitador, logo adaptei algumas lições do livro para a vida real:

• The DRY Principle, bom aqui é diferente, parafraseando o Miguel, aqui temos o PRY Principle, que se auto explica, Please Repeat Yourself.
• Building Adaptable Systems, essa parte aqui se resume a criar “flags” no banco de dados e dar um nome bonitinho de “parametrização”.
• Programming Close to the Domain, Domain !?! Seria enviar 18 ou mais parâmetros pra procedures que contém as regras de negócio ? Se for, aqui a gente faz !
• Programming Defensively, aqui isso se resume a colocar logs em lugares chaves pra passar a culpa do bug para outro equipe.

É claro que existem mais conceitos, mais para um programador-pragmático-waterfall os principais estão acima. O significado real de cada tópico você pode ver nos links, apesar que nada substitui a leitura do mesmo, que por sinal eu recomendo!

Enquanto isso, continuo com a minha sessão “sado”, lendo sobre DDD e tentando descobrir Por que as pessoas de negócios falam como idiotas.

Qualquer desabafo deixem nos comentários.

*obs: o link do amazon não é “paitrocinado”, só ilustrativo mesmo.