mergulhaoinfo on rails - Home

Como vocês fazem o "describe" das suas specs?

2008-11-28T05:18:00Z

Isso pra mim sempre foi uma dúvida ao usar o rspec. Realmente não há forma correta. É uma opção pessoal no caso de um projeto particular ou de decisão em conjunto no caso de um projeto onde vários desenvolvedores participam.

Mas o fato é que eu nunca adotei nenhum padrão para isso. É uma coisa que tem me deixado um pouco incomodado. Em alguns modelos sigo o padrão de um describe para cada método, em outros segui padrões ligeiramente diferentes, como por exemplo testes relacionados a attributos em um describe, relacionamentos em outro describe e assim por diante. Ou seja, não há padrão. Há tempos atrás ouvi uma frase que nunca esqueci:

Quando dois padrões existem, não há padrão.

No Lucidus usávamos Test::Unit(quando o projeto começou o rspec ainda era muito pouco difundido) então o “padrão” para nós era pelo menos colocar os testes relativos juntos. Então os testes relativos a um mesmo método normalmente estavam juntos, em um “bloco”, um abaixo do outro. O rspec nos permite um pouco mais de organização. Mas fazer essa organização extra através dos describes proporciona algum benefício?

Então seguindo a idéia… nós precisamos discutir testes.

Qual opnião de vocês? Como vocês organizam seus describes? E o que vocês escrevem nele?

Um "setup" global para todas as suas specs

2008-11-27T04:50:00Z

Ficou bem difundido no rspec a forma em como fazer o setup antes das specs executarem, assim como existe também no Test::Unit.

describe Act do
  before(:each) do
    (...)
  end

  it "should have many persons associated" do
   (...)
  end
end

Eu estava precisando fazer o setup para todas as minhas specs (do planeta :), então descobri uma forma que está mal documentada(pelo menos eu não achei bom), mas é super simples de usar. É só editar o spec/spec_helper.rb e adicionar dentro do bloco:

Spec::Runner.configure do |config|
  (...)
end

O seguinte:

config.before(:each) do
  your_global_setup_here
end

Você também pode executar o setup somente para os controllers, models ou helpers assim:

config.before(:each, :behaviour_type => :controller) do
  your_global_controllers_setup_here
end

config.before(:each, :behaviour_type => :helper) do
  your_global_helpers_setup_here
end

config.before(:each, :behaviour_type => :model) do
  your_global_models_setup_here
end

Como se chama o “setup” no bdd? É setup mesmo?

Fazendo o will_paginate traduzir o "Previous" e "Next"

2008-11-24T14:52:00Z

Eu precisei traduzir para várias línguas os links de “Previous” e “Next” do will_paginate, mas não seria nada dry passar os parâmetros em todas as chamadas a will_paginate(). Outra solução seria criar um método helper que faria a chamada ao will_paginate() passando os parâmetros e nas minhas views eu chamaria esse helper no lugar de chamar will_paginate(). O problema é que sempre que fosse criada uma nova tela com paginação a pessoa teria que lembrar de chamar o método helper e não chamar o will_paginate() diretamente.

Então pra mim a melhor solução foi criar uma extensão, que deixa tudo transparente. Eu coloquei em /lib dentro do projeto rails.

module WillPaginate
  module ViewHelpers
    def will_paginate_with_translate(collection = nil, options = {})
      options, collection = collection, nil if collection.is_a? Hash
      options.merge!(:prev_label => _("&laquo; Previous"), :next_label => _("Next &raquo;"))

      if collection
        will_paginate_without_translate(collection, options)
      else
        will_paginate_without_translate(options)
      end
    end
    alias_method_chain :will_paginate, :translate
  end
end

O método _() que é chamado é o método que faz a tradução no plugin de localização que estou utilizando, você deve alterar para a forma como você faz a localização no seu projeto. Também criei as specs para assegurar o funcionamento:

require File.dirname(__FILE__) + '/../spec_helper'

describe WillPaginate::ViewHelpers do
  describe "will_paginate translations" do
    before(:each) do
      @expected = 'paginate_mock'
      @model = mock('model-mock')

      @translation_options = {:prev_label => _("&laquo; Previous"), :next_label => _("Next &raquo;")}
      @options = {:option1 => '1', :option2 => '2', :next_label => 'next-fake'}
    end

    it "should will_paginate only with translations" do
      helper.should_receive(:will_paginate_without_translate).with(@translation_options).and_return(@expected)
      helper.will_paginate == @expected
    end

    it "should will_paginate with @model parameter" do
      helper.should_receive(:will_paginate_without_translate).with(@model, @translation_options).and_return(@expected)
      helper.will_paginate(@model) == @expected
    end

    it "should will_paginate with @model parameter and options" do
      helper.should_receive(:will_paginate_without_translate).with(@model, @options.merge(@translation_options)).and_return(@expected)
      helper.will_paginate(@model, @options) == @expected
    end
  end
end

Espero que seja útil para alguém ;)

Palestra Utilizando Ruby com Bluetooth

2008-11-07T22:22:00Z

Na semana passada eu apresentei no Latinoware a palestra “Utilizando Bluetooth com Ruby: A forma mais fácil de programar com Bluetooth”. Foi um sucesso total, a sala estava lotada e o pessoal se amarrou nas demonstrações ao vivo.

Coloquei os downloads na seção de artigos.

Rails Summit dia 16: Obie Fernandez

2008-10-16T23:37:00Z

Tudo que tenho para falar é como trabalhamos com os principios Ágeis. Eu começei em XP em 2000 e trabalhei com isso por muito anos… já são 10 anos de experiência. Nós buscamos a melhor maneira de desenvolver software. Começando sobre princípios e iterações sobre processos e ferramentas. Isso nos diz que a coisa deve estar em busca das pessoas. Como a programação em par impacta na produtividade? Isso parece contra a intuição, mas duas pessoas trabalhando em um computador pode ser mais produtivo que duas pessoas trabalhando em dois computadores. A melhoria do design no desenvolvimento em par é melhorado, além de ser mais gostoso. Pair programming não é uma coisa natural pois não é naturalmente usado em grandes empresas, mas é preciso aprender… e leva um certo tempo.

Eu acho muito importante ter dois teclados e dois mouses pois dessa maneira, uma só pessoa que tenha um perfil dominante não trabalha sozinha. Um dos princípios que melhora a produtividade é a revisão de código automática. Ao trabalhar em par isso é natural. Quando está trabalhando em par se trabalha o dia todo. Pois ao trabalhar sozinho, você vê o seu e-mail, lê blogs e etc. E essas coisas não acontecem com programação em par. Ao fim de um dia de programação em par você está cansado. Pois você realmente pensou e trabalhou o dia todo, mas você fica contente, pois sabe que teve o trabalho realizado.

É comum entre nós desenvolvedores, muitos de vocês mais inteligentes do que eu trabalham muito bem. Então dizem que demoram uma hora para realizar o trabalho, mas ficam horas escrevendo no blog e no twitter, fazem o trabalho em 5 minutos e depois vão para o almoço. O pair programming elimina isso. Ele te dá muita produtividade. Para as pessoas farerem pares é preciso contratá-las. Quando eu contrato pessoas para a minha empresa eu faço um post no meu blog e espero as respostas. Você diz as suas habilidades e é convidado a trabalhar por uma semana para nós sabermos se você é bom de verdade fazendo pair programming num projeto de verdade. Então nós contratamos as pessoas sem entrevistas, mas com elas trabalhando num projeto real por uma semana. Só por que alguém vai bem numa entrevista não tem relação em como ela é no dia-a-dia do trabalho. Em times pequenos é mais fácil de manter a felicidade de todas as pessoas. Times de 2 a 4 pessoas são boas opções. Além disso vocês podem ter problemas de comunicação.

Mais um principio que se pode utilizar ao ter um time de 2 a 4 pessoas é ter um time auto-organizado. Na nossa empresa a gente não tem chefes. Todos os times são auto-gerenciados. Pois se você tem um time desse tamanho de apenas pessoas boas e você tem um lema “todo mundo junto” as coisas simplesmente funcionam.

Software funcionando em contrário a uma extensiva documentação. Uma maneira de trabalhar desse jeito é usando rspec, nós somos fãs de rspec. É uma ferramenta tão eficiente, ela não somente ajuda você a trabalhar com o software, mas também para gerar uma documentação, que nós entregamos para o nosso cliente. Isso com certeza agrega valor ao nosso trabalho.

Eu me importo em ser real e essa uma razão pelo o qual eu estou envolvido por tanto tempo com Rails. Nós participamos do Rails Ramble de 2007, isso foi antes da formação do Rails Rocket, e isso mostrou pra gente que é possivel com Rails fazer um trabalho muito grande com pouco tempo. Foi muito bom trabalhar com essas restrições, pois na nossa área é comum o tamanho de um projeto expandir para caber no tempo total disponível para o desenvolvimento.

Nós trabalhamos com um conceito chamado 3-2-1. Que significa colocar um software no ar em 3 dias, onde temos 4 desenvolvedores, 2 da nossa equipe e mais 2 que chamamos para uma semana de trabalho.

Colaboração do cliente em frente a negociação de contratos. Isso tudo tem relação com transparência em relação ao cliente. Isso leva confiança ao seu cliente. Nós gostamos dos clientes com o qual trabalhamos.

Uma coisa importante é que você precisa ter um designer dentro da equipe que saiba fazer todo o visual do nosso projeto. Pois sem um projeto visual acabado, nós não temos o que mostrar para o nosso cliente. É bom ver exatamente como vai ficar e eu posso construir isso em 3 dias se você me mostrar como vai ficar.

Por outro lado, quando já temos um design, não temos muito o que divergir da maioria é que nós gostamos de user stories, que para nós significam a aceitação do cliente. Nós trabalhamos com cartões e com projeções para atividades que duram de 0 até 8 pontos de desenvolvimento. Com isso nós medimos o desenvolvimento de nosso equipe e quantos pontos podemos fazer por semanas. Na nossa equipe é comum fazer algo em torno de 25 pontos por semana. Em 0 pontos nós temos coisas que duram apenas alguns minutos e em 4 pontos nós temos coisas que duram uma semana.

Antes nós perdíamos muito tempo com negociação de contrato. Então nós desenvolvemos um documento, que serve como nosso contrato, que não exije que o cliente nos pague caso ele não esteja satisfeito. Esse contrato tem um termo especial que diz que ele não pode te processar por mais dinheiro que ele iria te pagar. O nosso contrato também estabelece que nós podemos contribuir com o mundo opensource com o código desenvolvido para eles, mas só as coisas que não são específicas do cliente, como plugins e gems que você desenvolveu para trabalhar naquele projeto.

E a última parte do manifesto ágil é responder a mudanças em vez de seguir um plano. Nós usamos um serviço chamado pivot tracker e ele é muito bom pois ele nos mostra muitas informaçõe sobre o nosso projeto, incluindo gráficos de burndown entre outros. A stand up meeting é outra coisa essencial para nós sobre como anda o nosso projeto e nos ajuda a dar mais uma previsão sobre quanto tempo esse projeto ainda vai demorar. Todos falam sobre o que fizeram ontem, o que farão hoje e sobre o que está atrapalhando o trabalho. Quando estamos com mais pessoas, como nós que já estamos com 20 pessoas, temos que mudar um pouco a dinamica do standup meeting, mas a essencial é a mesma.

Tenho mais uma coisa para falar, que coloquei no final, que é a parte mais importante do Hashrocker, a nossa empresa, é que nós achamos que a coisa mais importante é se divertir no trabalho. Sem diversão não há produção. Nós fazemos algumas coisas em conjunto para diversão.

E nós bebemos bastante para nos divertir e pulamos na piscina quando todos estão bêbados!

Rails Summit dia 16: Phillippe Hanrigou

2008-10-16T20:30:00Z

Existem diversos problemas com os testes do selenium. São naturalmente lentos, assim como qualquer tipo de teste de integração. Eles rodam no navegador, que são coisas instáveis, bugados. E ainda colocam pessoas poucos experientes para escrever os testes do selenium, o que é um problema. Tem que ser os melhores para fazer essa tarefa! Mas se é tão dificil, por que fazer?

E quanto mais javascript se usa, mais devem haver testes. Se você usa muito javascript a sua chance de ter algo que não funciona em todos os browsers é alta. E se você não suporta todas as plataformas, você estará perdendo dinheiro caso não suporte todas. Sobretudo na comunidade Rails. Então é por isso que temos que automatizar esse tipo de testes. E essas são coisas que tem que ser repetidas diversas vezes… então não são coisas que os humanos tem que fazer. A coisa mais fundamental sobre esses testes e a comunidade de Rails está usando esse tipo de ferramente, mas tem muitas coisas que podemos apredender dos mais antigos. Coisa que podemos aprender de antigos programadores XP, é que testes de aceitação são muito importantes. Pois os testes de aceitação dão poder ao cliente. Você precisa da aceitação para fazer o código correto, do ponto de vista do cliente. Os unit testes server para garantir que os pequenos pedaços funcionam, mas os testes de aceitação server para garantir que tudo funciona junto. O teste de aceitação é tão importante no desenvolvimento que ela não é considerada completa até que ela passe numa suite de aceitação. Uma suite de aceitação te gera confiança.

Depois da era de ouro, vieram os bárbaros! Os bárbaros são os browser, que impediram a realização de muitos testes de aceitação. Por sorte hoje temos o selenium.

Quando um teste falha, temos que investigar para descobrir onde está o problema. Então você tem que rodar isso na sua máquina e com sorte o problema também ocorrerá na sua máquina. A melhor forma de resolver o problema com mais facilidade é capturar a maior quantidade de informações no campos de testes: na máquina que rodou o teste, no browser e etc.

Agora a parte boa para diminuir o tempo de testes do selenium é que desenvolvemos o selenium-grid, que permite que diversos testes do selenium sejam paralelizados, inclusive entra diferentes máquinas de diferentes poderes de processamento. Um dos problemas, assim quando você coloca muitos fios de energia muitos juntos, é que você tem que garantir que um teste não irá interferir nos outros. Garantir por exemplo que as coisas irão rodar em stacks de Rails diferentes.

Uma coisa boa a fazer é deixar de fazer login como um teste no selenium, mas inserir diretamente um cookie no navegador e resetar a base de dados diretamente pelo teste do selenium. Isso é muito mais rápido.

A questão das fixtures. Testar com dados randomicos é complicado, pois há muitos efeitos colaterais. Testar usando fixtures fixas com grandes aplicações pode tornar a manutenção das fixtures muito dificil. Uma das soluções que podemos usar é criar os dados usados nos testes diretamente nos próprios testes, sem o uso de fixtures. Mas isso também é complicado, pois pode dar trabalho preencher objetos complexos. Uma solução plausível são os Object Mother. São como templates de objetos instanciados padrões, onde você passa parametros apenas para sobrescrever os valores do objeto que você quer que sejam diferentes do default. Existem diversas maneiras de fazer isso e há muita documentação na internet sobre o assunto.

Eu queria que vocês saissem daqui sem esquecer: não virem as costas para os testes de aceitação.

Rails Summit dia 16: Carl Youngblood

2008-10-16T20:29:00Z

Um ecossistema é a fauna e a flora e também o meio-ambiente de um certo lugar, não somente as coisas vivas, mas também o clima, por exemplo. Um conceito associado a um ecossistema é o aparecimento gradual. As coisas pequenas que quando atuadas em conjunto formam padrões e coisa mais importantes que as coisas pequenas isoladamente. Uma formiga individual carregando comida para dentro da toca sozinha parece que não faz nenhum trabalho importante. É um trabalho que nunca termina. Mas muitas formigas trabalhando em conjunto sem um chefe e de forma individual faz no conjunto um importante trabalho.

Agora como funciona o surgimento nas pessoas. Fazendo analogias do mundo real, como o crescimento das cidades e a comunicação de neurônios em nosso cérebro ele explicou como a inteligência coletiva é importante. Muitas das pessoas importantes do mundo muitas vezes são insuportáveis.

Agora o ecossistema do Rails. Dhh tem uma arrogância natural e sem ele não exitiria o Rails. Chad Fowler, James Buck, Michael Molina e Zed Shaw, todos eles são excentricos e tem caracteristicas exóticas, boas e ruins. Por último os humoristas do Rails Envy. Todas ajudam a comunidade internacional. Mas e o ecossistema Rails brasileiro?

Sem ser mau ou ser bom, qualquer pessoa não serve para nada. Que papel, você vai exercer?

Rails Summit dia 16: Vinicius Teles

2008-10-16T20:23:00Z

Serviços on Rails podem ser desenvolvimento, consultoria, treinamento, mentoring. Fazer serviços da forma certa deve ser acompanhado de paixão. Esse é a melhor maneira de se obter sucesso. Tendo paixão por um assunto, você tem paciência. Paciência é muito importante. Empreendedores não de fazem da noite para o dia. É preciso estudo, dedicação, ser entusiasta. O empreendedor levanta de rasteiras mais que outras pessoas. Hoje mais do que nunca a melhor estratégia é: give, give e give. Quanto mais você contribui para uma comunidade, mais você é importante para a comunidade e mais alguém estará disposta a pagar para você.

Quais as estratégias? Apresentações, apostilas, livros, traduções. Nosso maior exemplo nacional é o Akita, que se tornou internacionalmente conhecido pela sua colaboração a comunidade. Podcast, video, videocast, entrevistas, divulgação de trabalhos alheios. Todas essas coisas podem até acabar virando negócio, mas acima de tudo levam reconhecimento. O ser humano é caracterizado pela vaidade. É muito dificil querer entrevistar alguém e essa pessoa não querer ser entrevistado. Seja quem for esse pessoa será envaidecida, seja ela um ótimo ou bom desenvolvedor, mas que tem algo bom a ser divulgado. O entrevistado irá divulgar eventualmente mais que o próprio entrevistador e isso é uma grande alavancagem pessoal.

A melhor de todas as contribuições… se você já sabe escrever códigos escreva plugins, escrever gems e participe do movimento opensource. E para isso você não precisa nem sair do seu emprego atual. Hoje ninguém precisa obrigatoriamente ser empregado de uma empresa, o ferramental disponível e muito grande e pode permitir qualquer um ser dono do seu próprio negócio numa estratégia de longo prazo.

No Brasil é mais fácil se destacar que no exterior. Por todos os problemas que o Brasil tem, ele é um mar de oportunidades. E não é necessário largar tudo que você já faz hoje. Como trabalhar part-time em alguns projetos. Trabalhar no exterior e muitas outras coisas. O risco é muito baixo.

Alguns detalhes que precisam ser notados na vida de serviço. Da onde sai o dinheiro? Para alguns seria melhor trabalhar para empresa pequena, para outros uma empresa grande. Desenvolver software customizado para pequenas empresas é algo complicado, pois elas não tem dinheiro para pagar por desenvolvimento de software. Você sempre acha que está ganhando de menos e ele sempre acha que está pagando demais.

Serviços não escalam - assim, como Rails (brincadeira). Para se ganhar mais dinheiro com serviço, significa que você precisa ter mais gente trabalhando para você. Quanto você ganha é proporcinal a quanto de tempo você aloca em um cliente. Se você tem mais alguem trabalhando para você, eventualmente você pode ganhar o dobro. E quando você perceber que tem que contralar um batalhão de gente talvez você perceba de fato que serviços não escalam.

E aí você vai perceber que o trabalho com produtos são mais interessantes. Pois com um produto talvez você consiga resolver o problema de escala. Se você replica aquilo n vezes o valor que você pode ganhar não é proporcional a quantidade de tempo que você dedidou para o projeto. Como por exemplo o Highrise, que custa $24 mês. Se 1000 pessoas resolvessem pagar são $24000. E assim por diante e você pode perceber que isso pode gerar muito dinheiro, ainda mais se você considerar uma equipe pequena.

Se você vai fazer um produto sobre alguma área que não é computação, é bom você procurar alguém que entenda daquele negócio. Nós da computação não sabemos nada! O que é melhor? Um experimento ou um plano de negócios? Em Rails é possível que você consiga ter algo tão funcional que você possa colocar na mão de alguém que entende daquele negócio. Ou seja, fazer um plano de negócios eventualmente leva tanto tempo quanto fazer um experimento. Com a desvantagem de ele não te dar feedback.

Uma implementação é tudo. Não adianta apenas a idéia, se você não tiver uma implementação. Se você começa a ter algumas idéias e começa a fazer alguns experimentos, você pode encontrar um nicho ainda não explorado corretamente. No Brasil não é difícil encontrar um nicho. No Brasil existe o paradoxo do talentoso. Uma pessoa estudiosa, talentosa, ele quer ganhar dinheiro. No Brasil essa pessoa acaba procurando uma grande empresa, pois é lá que a grana está. Mas dentro de uma grande empresa, ela não consegue aproveitar o talento dessa pessoa. As grandes empresas estão sugando os grandes talentos e desperdiçando esses talentos. E quem está atendendo os pequenos negócios? Provavelmente os menos talentosos. Os pequenos negócios estão numa espécie de limbo e precisam de bons profissionais para resolver os seus problemas. E os bons profissionais não estão nem aí para os pequenos negócios, pois eles não tem dinheiro.

Eles não tem dinheiro para pagar alguns milhares de reais por mês para o desenvolvimento de um software. Mas eventualmente eles podem pagar uma mensalidade de 50 ou 100 reais e se você cria um mar onde se consegue navegar sozinho por muito tempo, num produto que atende pequenos negócios… milhares deles, que pagando pouco por mês geram muito dinheiro.

A oportunidade é muito grande!

Rails Summit dia 16: Jay Fields

2008-10-16T15:52:00Z

Existem 6 tipos de conceitos de testes: unit, external, smoke, functional, integration e acceptance. Nunca se deve ter medo de falhar quando se estar testando. Quando se trabalha com testes encontramos erros que passariam despercebidos. Os testes devem ser bem escritos e não serem esquecidos. Um erro comum é testar tudo. Em vez de testar tudo, teste as coisas mais importantes. Testes de aceitação no cliente também são muito complexos. Testes com interdependencia são bem problemáticos. Testes com problema de velocidade são críticos. Eles tem que ser rodados muitas vezes.

100% de cobertura de testes não é a meta. Em ruby podemos optar por toda essa cobertura. Não é necessário escrever testes para cobrir 100%. Os testes são a parte mais importortante do sistema. Se o seu negócio depende de uma funcionalidade que é crítica, ela deve ser muito bem testada. Para ter a confiança ao fazer refactoring é precisa ter alguma cobertura de testes, eles dão confiança. Seu código de testes deve ser limpo, perfeito.

As imaturidades do teste do selenium. Ele é bom, mas falha em algumas situações. Existem diversas maneiras diferentes de utilizar o selenium. É preciso escolher a maneira correta no seu contexto. Se você está programando em ruby, utilize selenium programando em ruby. O selenium tem outro problema grande: ele é muuuuuito lento. Grandes suites de teste do selenium são difíceis de manter. O selenium tem bugs, e roda em cima do navegador e algum bug no internet explorer pode fazer o seu teste quebrar e você irá demorar muito tempo para descobrir onde o problema está. O selenium não informa precisamente onde estão os problemas.

Selenium tem boas vantagens. Ele pode testar o seu site entre navegadores. Ele é o único a testar o fullstack de uma aplicação web. Ele é fácil de usar e por ter muitas maneiras de usar, ele pode se adaptar a praticamente qualquer ambiente. Ele é amigável para testadores. É a melhor solução para smoke testing.

Imaturidade do test/unit. Ele não é tester friendly. Os testes são procedimentos e se perde muito da orientação a objetos, não há herança entre testes. Ele testa apenas pequenas coisas. A sintaxe dele é horrível, não intuitiva, não há um mapeamento muito bom entre o código do software e o de teste. Não há um framework de mock incluído. Mas tem vantagens, ele é muito amigável com o desenvolvedor. Muitos desenvolvedores já utilizaram algum tipo de teste unitário. Apesar da sintaxe feia, os desenvolvedores estão acostumadas a ela. E é fácil de escrever para um desenvolvedor. Roda muito rapidamente.

Imaturidade de rspec. Rspec usa muita mágica para fazer as coisas funcionar. Ele é muito baseado no inglês, mas ao mesmo tempo não tão consistente assim com o inglês. Mas depois da familiarização com o rspec entender as convenções fica fácil. Não é tão simples de extender. Ele é focado em testes de comportamento (behavior), que são mais fáceis de entender. Ele gera documentação automática e possui um framework de mock embutido.

Imaturidade do Synthesis. É um framework de integração. Encoraja classes desacopladas. Dá confiança sem necessidade de fazer testes de integração traducionais.

Imaturidade do Expectations. Framework de expectativas, similar com frameworks de behavior. Ele é somente código, não existem métodos. Então por exemplo se um teste falha ele apenas diz que falhou uma coisa na linha 35, por exemplo. Então ele não tem documentação, pois há ligação entre uma linha de teste e sobre qual teste em si está sendo executado. Ele é bem conciso, então essa é a parte legal, por isso que eu uso ele para certas situações. Ele encoraja a realização de testes bem granulares. Os valores esperados são literais. Encoraja que você faça definição de métodos que sejam expressivos.

Experimente e faça o que funciona melhor para você.

Rails Summit dia 15: Dr Nic

2008-10-15T19:05:00Z

Nosso doctor da comunidade contou como ele começou no Rails, em como foi chato ver pela primeira vez o tutorial de Rails de 15 minutos e como ele largou o Visual Studio e mudou para Rails.

Antes de fazer hacks em código as pessoas faziam hack em carros e o Dr Nic era triste pois os pais dele não deixaram ele hackear o carro, já que eles precisavam usá-lo. Depois apareceram os hacks de hardware, mas eles eram caros. E então apareceu o código, onde você não precisa gastar dinheiro nenhum para começar a hackear. No passado não havia tanto código quanto hoje, então hoje é muito fácil estudar código e olhar código para hackear.

Foram apresentados algumas estatísticas do número de projetos opensorce no sourceforge, rubyforge e github. É notável, pois há cerca de 6500 projetos no rubyforge, enquanto já existem 19000 no github!

Mais uma vez, assim como o Chad Fowler, uma palestra falando sobre reconhecimento pessoal. Dr Nic incentivou a colaboração, fazendo uma analogia com dinheiro. Se você tem $1,000 que você não pode gastar em lugar nenhum, para que serve esse dinheiro? Essa foi a relação que ele fez com os segredos de código.

Defendeu uma mudança no pensamento em relação a grupos e permissões, dando mais incentivo ao individuo. Na opnião dele simplesmente dizer que algo está quebrado é uma coisa muito lenta. Então normalmente ele interfere num projeto enviando um patch, pois este diz tudo que diversos e-mails não resolveriam. É algo como andar na frente. Em suas palavras: “There is no them”.

Falou sobre as diversas atividades que os desenvolvedores podem ter dentro de um projeto opensource e como cada uma dessas atividades individuais são importantes. Existem diversas oportunidades de contribuição em projetos opensource, inclusive os projetos não mais mantidos do Dr Nic. Enfatizou bastante a questão da não necessidade de permissão para fazer as coisas, e sobre como o git facilitou a nossa vida nesse sentido.

Ele citou o exemplo de um cara que trabalha com ele que programa em Cocoa, mas que não entende nada de software opensource, que não contribui com a comunidade. E mais um vez está a importancia dos blogs para divulgar a cultura opensource e mostrar para esse tipo de pessoa sobre como trabalhar colaborativamente pode favorecer a todos.

Os caminhos para se tornar bom na comunidade: aprender controle de versão(svn e git), aprender unit testing, começar um blog, aumente a sua bagagem técnica e na comunidade

Ele focou bastante ao falar do tdd. Ele não mexe em código que não tem teste, no máximo auxilia na documentação. E ainda falou das facilidades já oferecidas pelo Rails.

Sobre o blog ele falou da importancia que o blog teve para torná-lo conhecido e sobre como isso pode ajudar os profissionais para se tornarem também. Enfatizou que não é preciso escrever textos formais no blog, o importante é contribuir com qualquer coisa que você tenha aprendido. Isso ajuda você no futuro e ainda ajuda a comunidade.

Participar de conferências, mostrar o seu código, corrigir o código dos outros, fazer (boas) perguntas em forums, traduzir coisas para o português e para o inglês.

Don’t keep secrets! Compartilhe, compartilhe, compartilhe!

Esse é o caminho para o awesomeness!

Rails Summit dia 15: George Malamidis e Danilo Sato

2008-10-15T17:59:00Z

Foram desenvolvidos de diversos aspestos sobre REST, o principal foi o uso do REST para prover serviços, suas limitações e formas de escalar. Por fim o REST foi comparado com outros protocolos para prover serviços e enviar mensagens, como SMTP e XMPP. Esse tipo de protocolo pode ser mais escalável que prover serviços em REST dependendo do que se deseja.

No fim da palestra apareceu uma pergunta interessante que questionou se o serviço do Flickr era REST ou não. O questionamento foi em relação aos resources do Flickr não utilizarem a formatação clean das URLs como no Rails, mas passando parâmetros na URL da forma convencinal para informar a action desejada. O George defendeu que os serviços do Flickr são REST sim, apenas não utilizam a mesma formatação de URLs Rails. Na opnião dele se são recursos que podem ser acessados e cacheados então ele considera sim como sendo um recurso.

Rails Summit dia 15: Chad Fowler

2008-10-15T16:11:00Z

Chad Fowler falou bastante sobre como se promover no mercado como desenvolvedor. Ele fez analogia comparando o desenvolvedor com produtos, mas não de maneira negativa. Apenas informando que o desenvolvedor deve saber se apresentar para o mercado, fazer barulho para se mostrar, fazer marketing pessoal. É uma coisa que muitos desenvolvedores não gostam de fazer, mas é necessário se você quer crescer como profissional. Um dos exemplos dados por ele foi o de um funcionário que sabe desenvolver 5 vezes mais rápido que qualquer um da equipe de desenvolvimento, mas não fala isso pra ninguém e continua trabalhando com suporte.

Ele falou também sobre produtos que ele classificou como remarkable. Seriam coisas que tem potencial de sucesso, como foi/é o caso do Rails. Também foi o caso do iPod, que entrou para concorrer nos Estados Unidos num mercado onde se compra um MP3 Player por $15 e o iPod algumas centenas de dólares. E o principal, enfatizou que o profissional deve ser remarkable.

Não foi nada que eu já não soubesse, mas é legal ouvir de alguém com renome na comunidade.

Hora do almoço!

Participação no Railsbox podcast

2008-09-29T12:55:00Z

Na semana passada eu participei da gravação do Railsbox podcast. O tema foi licenciamento de softwares livres/open source. Falamos muito sobre software livre e licenças open source, fazendo paralelo com a realidade atual de nós desenvolvedores Rails e nossos projetos.

Agradeço ao Ozéias Sant’ana e ao Davis Cabral pelo convite. Também participou do podcast o Rafael Caceres, que é envolvido com o movimento do software livre no Paraná.

Confiram o podcast.

Disabling my public svn

2008-09-15T16:06:00Z

I disabled my public svn. I only had apache installed in my vps because of svn and it’s not making sense anymore with GitHub. So my public projects are now there.

Rcov with segfault bug patched

2008-08-29T04:28:00Z

Rcov are hurting many people because of a segfault when used with rspec. Fortunately Tom Copeland wrote a patch last week. I patched it against rcov and put on GitHub. You can install it as a gem doing like this:

$ gem sources -a http://gems.github.com (you only have to do this once)
$ sudo gem install mergulhao-rcov

Someone knows how to make GitHub recognizes my README.markdown file?