Se você freqüenta este blog já deve ter percebido que nós não gostamos da maldita cascata. Fases bem definidas, detalhamento de requisitos, documentos inúteis, diagramas UML, papéis… tudo muito lindo na teoria. Eu fico até emocionado quando leio a documentação do RUP. Mas infelizmente a maioria dos profissionais de TI precisam são obrigados a trabalhar nestes ambientes cascateiros, enfrentando chefes sem noção, colegas com síndrome do funcionário público, prazos sem sentido, entre outras pérolas da área.

O principal apelo de um processo cascateiro são suas fases e papéis bem definidos, onde cada membro da “equipe” é responsável por uma determinada tarefa que é executada em uma seqüência previamente definida. Dentre os papéis, pode-se facilmente identificar os especialistas daquela tarefa, que defendem sua necessidade execução com unhas e dentes. Para ilustrar, resolvi chamá-los de guardiões, seja da tecnologia ou da atividade em questão. Um guardião protege sua fase, tarefa e interesses, defendendo-os para que o “processo” não seja quebrado. Desta forma, a “equipe” atinge seu objetivo: o software! Seguem alguns exemplos desses guardiões cascateiros:

O guardião do banco de dados: “Não rodarás nenhum script na base alheia” Começo por este por ser o mais comum dos guardiões. Ele trata o banco de dados como um filho, mesmo que seja um adolescente que não obedeça inteiramente à 3ª regra normal. São vistos como semi-deuses, capazes de transcrever o modelo de negócio da empresa em uma linguagem de alto nível, impossível de ser compreendida por simples programadores. Protejem as tabelas com a própria vida e qualquer alteração na base de dados é motivo para um duelo até a morte! Utilizam um padrão para nomenclatura de campos que somente é conhecido pelo clã dos DBAs. Geralmente são seguidores do Oráculo, o senhor de todos os bancos de dados.

O guardião do projeto: “Guia-te pelo teu Gantt e serás recompensado” Este guardião está presente em todos os projetos, garantindo que a palavra do Gantt seja cumprida, protegendo o escopo do projeto com a própria vida (ou a vida de algum programador). Adicionalmente atua como roteador de atividades: recebe os requisitos pelo email, encaminha para um recurso disponível (programador) que estima o esforço e define uma data de entrega, devolvendo para o guardião que atualiza seu Project.

O guardião do framework: “Venerarás o Struts e nada te faltarás” O framework é o objeto de adoração deste guardião, nenhum outro framework é tão bom quanto o que ele venera. Ele provê solução para todos seus problemas simplesmente escrevendo um bloco de XML aqui, outro ali, mudando aquela linha acolá e estendendo uma classe X implementando aquela interface Z. Qualquer evolução do framework em questão não passa de uma tentativa frustrada de “reinventar a roda”.

O guardião da arquitetura: “Não usarás a instância do teu objeto em vão” Uma variação interessante de guardião, que neutraliza seu oponente através de técnicas de tortura e perturbação mental, inundando as sessões de brainstorm com uma enxurrada de DTO’s, VO’s, Facades, EJB’s entre outros patterns que fazem a cabeça dos programadores entrar em conflito, até que seus órgãos faleçam (ou simplesmente se demitam). Geralmente são cúmplices dos guardiões do projeto, conspirando para a dominação do Gannt.

O guardião do root: “Teu processo não executarás no meu bash” A jóia mais preciosa da empresa: a senha do root. Seu guardião é o mais honrado dos seres, sendo uma espécie de Frodo, protegendo-a com a própria vida pois uma vez em mãos erradas pode ser usada para a destruição da humanidade (ou apenas para reiniciar aquela instância do Tomcat travado em produção). Aquele que desafia este guardião perde o direito de executar seus processos como administrador local e fica vagando pelo filesystem eternamente.

O guardião dos guardiões: “Tua TI é um mal necessário” Também conhecido como diretor, presidente, CEO, dono, investidor, sócio, etc. É o guardião das decisões, aquele que protege sua riqueza acima de tudo, economizando nos salários, contratando funcionários despreparados e investindo rios de dinheiro em consultorias e licenças de software para garantir seus investimentos.

Enfim, são guardiões dos próprios interesses. A “equipe” é apenas uma palavra que usam em discursos mas nunca aplicaram o conceito na prática!

Atualmente, desenvolver software não é uma atividade barata. O custo com os profissionais envolvidos, equipamentos, licenças de software (não é o caso se a equipe utiliza software livre), entre outros recursos, para um software que demore em média três meses para ser desenvolvido com uma equipe de 5 pessoas sairá pelo mesmo valor de um carro popular de luxo, por exemplo. Já que o investimento é alto, é importante que o software seja confiável, durável, adaptável e principalmente que sua utilização/adoção, além de atender a um problema/necessidade, obtenha o retorno sobre o investimento.

Para uma empresa que desenvolve software por encomenda, o retorno sobre o investimento (equipe, equipamentos, etc) é o lucro obtido com a venda do software através de uma conta muito simples: investimento – custo = lucro. Desta forma, qualquer CEO sabe que quanto menor for o “custo”, maior será o “lucro”. É aqui que mora o perigo!

Uma das falsas ilusões das metodologias baseadas no waterfall é o controle sobre o processo. Ou seja, com um processo bem engessado definido, o “motor” da empresa giraria de modo uniforme, sendo controlável e mensurável. Uma vez que esse mecanismo esteja funcionando, pode-se conter gastos contratando-se mão-de-obra mais barata para fazer a parte repetitiva e “não-criativa” do processo, que já foi previamente “projetada” pelos analistas e arquitetos. Desta forma, concentra-se a maioria do esforço no projeto ou desenho do software, que é mais caro, para recuperar o “gasto” na fase de construção, que é mais barata.

Este método funciona muito bem… na engenharia civil, onde os problemas são bem definidos (a necessidade de atravessar um rio, por exemplo), a solução deve ser projetada (uma ponte) e executada por especialistas em construção (pedreiros). O esforço pode ser mensurado e cobrado do cliente. Dificilmente ocorrerão mudanças no projeto (ao invés de ponte, decidem mudar para um teleférico, por exemplo) e o tempo de construção pode ser diminuído aumentando-se a mão-de-obra porém permanecendo o mesmo custo no final do processo.

Infelizmente com software não é bem assim. O desenvolvimento de software é (ou deve ser) um processo criativo e iterativo, mais parecido com jardinagem. O problema/necessidade dificilmente é bem definido (dificuldade de controlar as vendas pela internet, por exemplo) e os requisitos geralmente mudam o tempo todo. Os clientes normalmente não sabem exatamente quais são suas necessidades e precisam “aprender” enquanto o software vai sendo desenvolvido, atendendo às necessidades aos poucos.

Voltando ao assunto do post, para o cliente o que mais importa é que o software atenda suas necessidades (mesmo que ele ainda não saiba exatamente quais são). O retorno sobre o investimento começa a ficar evidente quando o cliente utiliza o software e obtém proveito dele, por exemplo, tendo um maior controle e organização de suas vendas pela internet. Neste caso o software é um meio pelo qual o cliente consegue resolver seus problemas ou atender suas necessidades. Isto o software não faz por sí só.

Para uma empresa que desenvolve software, o retorno sobre o investimento é obtido durante o desenvolvimento do software, guiado por práticas e ferramentas que fornecem velocidade e confiabilidade ao software, deixando-o adequado às necessidades do cliente, estável e fácil de ser mantido. Para obter estas características, a equipe deve estar muito alinhada e ter a experiência e habilidade técnica necessária para evitar trabalho desnecessário e focar na resolução do problema, colaborando com o cliente para fornecer constantemente software funcionando e que agrega valor ao negócio. Ou seja, devem seguir o manifesto ágil!

Atualmente, as empresas de desenvolvimento de software mais bem sucedidas utilizam metodologias ágeis, ou seja, pessoas ao invés de processos. O investimento em um bom profissional é recompensado pela sua experiência que pode economizar muito tempo e dinheiro ao longo de um projeto. Bons profissionais, motivados, utlizando metodologias ágeis são mais produtivos, ou seja, valem o investimento.

Na semana passada uma desconfortável discussão me pôs a pensar sobre os obstáculos culturais na aceitação de princípios ágeis no desenvolvimento de sistemas. A discussão ocorreu quando um amigo meu comentou comigo a respeito de uma metodologia que ele pretende aplicar em um projeto no qual está envolvido. Fiz questão que ouvi-lo com atenção, pois ele, além de ser uma pessoa da minha consideração, possui um background de sistemas muito diferente do meu. O que permite tentar entender outros lados de problemas em comum.

Logo nos primeiros instantes da conversa, percebi que a metodologia que ele estava a me explicar era nada menos que algo derivado de waterfall, onde, basicamente, um “sistema” é definido, por sábios analistas, em um conjunto de diagramas diversos, para depois passar por “estágios” de aprovações e assinaturas mil, e então finalmente cair nas mãos sujas de pizza dos programadores. Documentos. Documentos e mais documentos. Tudo para garantir que não houvesse mal-entendidos, nenhum “re-trabalho”, nenhuma oportunidade de “o cliente” pedir mais do que podia ou mudar de idéia depois de todos os acordos — simplesmente, a metodologia era sinônimo de controle total e absoluto sobre todas as “fases” de um projeto.

Eu não podia ouvir tudo aquilo e ficar calado. A primeira pergunta que eu fiz foi: quais problemas essa idéia vai combater? Ou, pra ser mais sincero com o eventual leitor, perguntei que problemas, observados na prática, seriam resolvidos com a metodologia. Sim, na prática, pois durante a conversa ele havia dado exemplos bastante hipotéticos e superficiais de problemas. Recebi como resposta um olhar de espanto, como se eu tivesse perguntado se a Lua era feita de queijo Minas. Deveria ser óbvio para mim quais eram os problemas! Na raiz de todos os males está a informalidade total no andamento dos projetos! Cliente conversando direto com programador! Sistema que foge às especificações! Cronogramas que não são cumpridos! Programador dando uma de arquiteto! E outras na mesma linha.

Diante de tantas certezas, vi que a conversa já não ia dar em nada, mas continuei o debate. Respondi que, no projeto em que eu estou trabalhando, uma situação de caos total foi revertida sem que a equipe tivesse que conversar em UML, sem que colocássemos travas no diálogo com o cliente… mas com muito, muito “re-trabalho”. Disse ainda que, do meu ponto de vista, os problemas eram de fundo humano: equipe mal qualificada e expectativas amadoras dos assim chamados responsáveis. E ainda afirmei que não acreditava em especificação perfeita, primeiro porque especificações e diagramas são feitos por seres humanos (ainda que na qualidade de iluminados analistas), e segundo porque software se trata de algo mutável pela própria natureza. (Ou então seria chamado “hardware”.) Não falei em termos tão professorais assim, ou ao menos, procurei ser humilde nas colocações.

Continuei dizendo que, por causa desse fundamento humano, a solução dos problemas, se é que existe, passaria por: apoiar o talento das pessoas, não ser reativo nas negociações, recrutar direito, apostar em um gerenciamento mais adaptativo (em nenhum momento usei a palavra “ágil”) de projetos. Certamente, soluções bem menos simples do que dar ordens de se produzir e seguir diagramas ao pé da letra. (Como se houvesse leitura “ao pé da letra”…)

Pensei que possuía alguma credibilidade, mas acho que a essa altura da conversa o meu amigo já não me via como desenvolvedor experiente, e sim como um encarregado que tinha ido trocar a água do bebedouro perto do qual estávamos e resolveu dar palpite sobre esse troço de sistemas. Tive que ouvir que eu estava “totalmente errado”, que esse papo de dar valor às pessoas era “a causa de nada funcionar”, que as empresas precisavam reter conhecimento através de documentação (no que ele está certo), e que “muitas empresas grandes” estavam trabalhando com essa metodologia. (Não citou as empresas e eu não questionei pra não ficar chato.)

O papo acabou logo depois, mas se alguém ainda está lendo e achou que brigamos, não foi o que aconteceu. Continuamos amigos igual antes. Mas dificilmente volto a ter uma conversa com ele sobre esses assuntos. Existe uma diferença cultural muito grande entre nós dois no que diz respeito a software, e é esse o assunto do post!

Em toda a minha carreira eu apostei na minha capacidade de resolver coisas, no meu domínio sobre as questões relevantes aos trampos com os quais me envolvi, na confiança que eu podia estabelecer com as pessoas em volta e, reciprocamente, na confiança que essas pessoas podiam ter em mim. Eu não sei trabalhar de outro jeito e nem quero mudar, pois várias vezes tive o prazer de ver as coisas funcionando/mudando justamente pelas minhas atitudes. Uma metodologia na base do diagrama, na base do analista/deus e programador/vassalo não é só inútil pra mim como simplesmente não me oferece condições de trabalho.

Por outro lado, não me lembro de ter visto esse meu amigo falar com orgulho a respeito de algum projeto do qual tenha participado. Percebo que sua carreira foi marcada por muito trabalho, muito esforço com equipes ruins, muita pedrada de cliente folgado. Chefes ignorantes. Tarefas monótonas. Isso tudo, sem a contrapartida de gostar do que faz, nem de conseguir se motivar observando os próprios sucessos, pode facilmente, na minha opinião, produzir um semeador de waterfall, como meu amigo parece ter se tornado. Para um perpetuador de waterfall, um sistema é uma coisa plana, composta de tarefas registradas em alguma linguagem esquemática pobre, que será transcrita para o computador por pessoas-robôs cujo maior erro é, eventualmente, pensar.

Uma coisa plana sem espaço para a confiança, nem para a imaginação — origens de todos os males, pelo bate-papo ao pé do bebedouro.

(Parte da motivação para este post veio de “What are the right conditions for agile adoption?”, de David Anderson.)

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)

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 ! :D

É 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 ! :D

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 !

Durante minha carreira profissional fui obrigado tive a oportunidade de atuar brevemente no campo gerencial do desenvolvimento de software. Foi uma experiência que agregou muito conhecimento e me fez enxergar minha atividade principal, programação, com outros olhos. Também pude entender melhor as estratégias comerciais da empresa, gerenciamento de recursos, retorno sobre investimento, etc. Além de aprender mais sobre desenvolvimento de software, também pude conhecer os vilões dessa história, na maioria dos casos: a diretoria.

Na maioria dos problemas que presenciei, a diretoria (quem toma decisões e libera a grana do projeto) contribuiu para que as coisas ficassem cada vez piores, seja tomando decisões visando curto prazo ou aplicando conceitos ilusórios como adoção de uma tecnologia ou metodologia da moda. Seguem algumas pérolas da “diretoria”:

• “Programadores são descartáveis”. Não consigo acreditar que pessoas numa hierarquia superior ainda tenham esta visão dos programadores, comparando desenvolvimento de software com construção civíl e programadores com pedreiros (em alguns [poucos] casos é verdade). Certa vez presenciei um dos mais famosos defensores de práticas ágeis, autor de vários livros e que subiu na carreira devido a seu destaque como programador (Delphi), dizer: “programadores têm em todo lugar, basta sacudir uma árvere e cai um monte deles no chão”. Depois dessa, passei a ignorar tudo que ele escreve ou fala. Talvez se ele tivesse lido pelo menos o resumo do Manifesto ágil saberia que blasfemou feio!

• “Meu maior gasto é gerado pelos programadores”. Fiquei sem reação quando ouvi esta pérola do dono da empresa. Ele ainda achava que os atrazos e erros do sistema vinham dos seus quatro programadores juniores que utilizavam uma tecnologia quem ninguém conhecia direito (mas está na moda), não utilizavam nenhum processo ou metodologia e ainda tinham que manter contato direto com os clientes.

• “Precisamos de documentação”. Esta todos nós já ouvimos e conhecemos o final. Um certo dia alguem chega na empresa e decide que tudo deverá ser documentado. Então gastam-se alguns meses levantando os requisitos do sistema, definindo os casos de uso e diagramas UML, reuniões, definição do banco de dados, etc. Lá pelo 10º mês descobrem que nenhuma linha de código foi escrita e o sistema só existe no papel. Nem preciso contar o final da história né?

• “Como assim não dá pra desenvolver este ERP em três meses?”. Nunca assisti um Tech-Ed nem outra palestra do tipo, por isso não sei exatamente o que vendem falam sobre pazos, mas com certeza é uma mentira das grandes! Não existe mágica nesse ramo, não existe ferramenta nem tecnologia milagrosa e nenhum processo vai acelerar o desenvolvimento do sistema. Ponto. Somente uma pessoa que não entende nada sobre desenvolvimento de software acreditaria nesse conto de vigário. Um general sabe comandar seus soldados pois certamente foi um soldado e esteve num campo de batalha. Será que todo chefe/diretor foi programador (de verdade) no início da carreira? Ter programado em Cobol há 20 anos atrás não conta!

• “Não podemos perder tempo com refactoring e testes unitários”. Bom, se deixar o código do sistema mais “manutenível” e garantir que o que já foi feito funcione corretamente do jeito que deve ser for uma “perda de tempo”, então estou no ramo errado. Fazer com que o sistema “rode” é muito importante pois sistema rodando é dinheiro entrando no caixa. Mas abrir mão da qualidade é uma péssima estratégia a curto prazo, pois todos nós sabemos que sistemas mudam constantemente e ter mecanismos para responder rapidamente a essas mudanças é mais importante do que “parir” um sistema remendado de uma hora pra outra e depois perceber que a menor das mudanças custa 10 vezes mais do que o normal.

Por enquanto só consigo me lembrar dessas, mas outras pérolas virão e renderão novos posts.

Fiquem a vontade para comentar. Até o próximo post!

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 ! :D

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 ! :D

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 ! :D

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:

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:

Bom pessoal, hoje estou aqui pra pedir ajuda. Sim, pedir ajuda pra todos àqueles que utilizam a web(www) para alguma coisa, seja para estudar, trabalhar, jogar ou ficar rico! E falo por todos desenvolvedores que tem o navegador como container de suas aplicações, que tem que lidar com as diversidades de dois mundos, MS Internet Explorer 6 contra a rapa!

O dia-a-dia no desenvolvimento de software web é um tanto sofrido para quem tem que, além de fazer uma aplicação com boa usabilidade, performance e ainda bonitinha, tem de manter compatibilidade com a ferramenta <voz_do_faustão>da gloriosa Microsoft</voz_do_faustão> que vem com o Windows XP: IE6. Sempre que você faz algum milagre em JavaScript, ou usa alguma técnica Web 2.0 pensando em agradar o usuário final (ou até mesmo o seu gerente!), tem que ficar com os dois pés atrás, pois você só pode comemorar depois de testar no IE6. O IE6 com certeza pode ser apontando como o pior navegador de todos os tempos, lento, péssima usabilidade, segurança terrível e ainda vai na contra-mão de todos os padrões WWW. O fato é que muita gente que programa não sabe que na verdade nem JavaScript este browser suporta, na verdade ele suporta um clone da Microsoft chamado JScript, este sim é o que deixa os programadores do mundo todo de cabelo em pé.

É claro que eu não podia deixar de fazer um comentário maldoso. Atualmente ainda temos muitas aplicações que não usam muitos recursos maravilhosos que a nova gereção de navegadores oferecem por culpa de empresas que não tem coragem de chutar o balde e forçar seus clientes à migrarem seus navegadores em prol de uma melhoria para todos, desenvolvedores e usuários! É claro que este tipo de empresa casualmente adotam metodologias duvidosas (waterfall puro!!), que refletem diretamente na qualidade de seus aplicativos, mas por outro lado temos empresas que lideram um movimento que deveria ser seguido por todos àqueles que querem se manter no mercado, uma delas é a 37Signals, que já manifestou algumas vezes o seu abandono ao IE6 dizendo que apartir do dia 15 de agosto todas suas aplicações passariam a não ter o compromisso de suportar o IE6.

Bom, acho que já ficou claro até aqui, que o passoal do 1Up4Developers apoia esta causa, e é por isso que escrevo este post, para mostrar a nossa aderência à campanha SaveTheDelelopers.

Assim como nós, muitas pessoas começam a apoiar essa campanha através de seus blogs, pessoas que são referência no desenvolvimento de software web. Eu descobri esta campanha através do blog Nome do Jogo, do Carlos Brando, e de imediato pensei em fazer este post.

Pessoal, disseminem esta idéa em todos os lugares, quando algum parente chamar você para consertar seu computador diga: só se você atualizar o seu navegador!

Abraço

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 !