Groselhas - O blog do Mauro George

Como foi criar um jogo para fazer um pedido de casamento

2016-04-06T00:00:00+00:00

A ideia

Ano passado em algum dia próximo ao fim do ano a noite estava em casa e me bateu uma ideia “E se eu fizesse um jogo para pedir a Jéssica em casamento?”. Começei a pensar um pouco sobre o assunto, fui anotando as ideias no Google Calendar. Sim, utilizei o calendar pois pretendia começar o projeto apenas em Janeiro.

Anotei que teria que ser um jogo de plataforma, com a Jéssica como personagem principal, jogo 2D, assets do Mario, interação com personagens conhecidos durante a fase etc.

Imprevistos acontecem

Comecei o ano de 2016 doente, fiquei com dengue e não consegui trabalhar nem me dedicar ao novo projeto.

Tive que ficar de repouso e visitar o médico basicamente de 2 em 2 dias.

Mas deu tudo certo e depois de aproximadamente 2 semanas, consegui começar o projeto.

Organização do projeto

Para controlar as tarefas e o que fazer no projeto utilizei o Trello. Com um simples kanban com 3 colunas “A fazer”, “Fazendo” e “Finalizado”.

Além disso criei uma coluna chamada “Sempre lembrar de” de coisas que deveria ter sempre em mente enquanto trabalhava no projeto. Como por exemplo tinha um card com a ideia inicial, um que falava para manter as coisas simples, um para salvar todas as referências etc.

O planning

Não queria que este projeto se extendesse por muito tempo, queria que no começo de maio já o tivesse apresentado para Jéssica e feito uma surpresa a ela.

Então criei um card na coluna “Sempre lembrar de” para analisar a duração das tarefas. Então toda segunda que, era quando começava a trabalhar no projeto, eu começava olhando para a semana anterior e vendo se ela foi produtiva, seja de aprendizado ou de desenvolvimento de fato. Sempre colocava um due date no card assim toda vez eu era lembrado dele quando chegava o começo da iteração.

Além de criar mais tarefas para serem realizadas, caso ainda não tenham sido criadas. Também era comum tarefas serem criadas durante o próprio desenvolvimento.

Roadmap

Sabemos que tentar ser previsivel no desenvolvimento de software é algo complicado. Levando em conta que estava desenvolvendo algo que nunca tinha feito antes então a imprevisibilidade era maior ainda.

No entanto depois de ter algum conhecimento do processo, provavelmente depois de ter finalizado a prova de conceito, decidi criar um roadmap para ver se as tarefas que eu havia criado seriam plausiveis de serem realizados dado que tinha um deadline.

E como todo bom roadmap ele falhou miseravélmente. No dia 25/03/2016 eu fiz o pedido de casamento. Ou seja com aproximadamente um mês de antecedência.

Acompanhando o andamento

Utilizo o Coach.me há algum tempo para acompanhar certas tarefas.

Para quem não o conhece é uma ferramenta para ajudar a criar hábitos e o legal é poder acompanhar o andamento, e assim ver quando foi realizada tal tarefa.

Então para me dedicar a este projeto eu tive que parar outros, como por exemplo contribuir com projetos open source. Sendo assim criei este novo hábito no Coach.me e coloquei que iria me dedicar a ele de segunda a quinta em torno de 2 horas por dia.

Segue a visão do Coach.me dos dias que trabalhei no projeto.

Como pode ver foram 42 dias que trabalhei no projeto. Algumas semanas com mais dias e outras com menos, provavelmente devido a ter que resolver outros compromissos nas que estavam com menos e nas que estavam com mais dias é devido a não ter compromisso em alguns sábados em especifico e nestes normalmente o trabalho foi maior do que 2hs.

Ritmo sustentável

Para quem esteja se perguntando por que de parar uma coisa para começar outra. Primeiro para ter foco e conseguir entregar algo de qualidade. É bastante complicado querermos iniciar e manter N iniciativas ao mesmo tempo ainda mais que todos nós trabalhamos e temos outras tarefas no nosso dia a dia. Então preferi cortar algumas atividades por um tempo.

Há um tempo escrevi sobre Ritmo Sustentável no blog da HE:labs. Além do ritmo sustentável no trabalho trago esta prática para os projetos paralelo que inicio também.

Qual engine usar?

Como fazer um jogo é algo que nunca tinha feito, comecei realizando pesquisas de engines para jogos 2D e que atendecem aos requisitos que eu tinha que desenvolver.

A principio a ideia era utilizar Unity, no entanto continuei pesquisando engines de JavaScript, passei por Ruby também.

Por mais que desenvolver algo em Unity fosse uma experiência nova e desafiadora, tinha que lembrar que tinha um deadline então o que fosse mais próximo da minha realidade seria melhor de atingir um resultado num espaço de tempo menor.

Então depois de pesquisar diversas engines de JavaScript acabei escolhendo o Phaser que parecia resolver meu problema, tinha diversos cases e uma documentação boa.

Prova de conceito

Escolhida a Game Engine, parti para a prova de conceito. Como tinha que ter um servidor web rodando e não poderia ser apenas HTMLs soltos dentro de uma pasta, montei um pequeno projeto utilizando o GitHub Pages. Antes utilizei um pouco do SimpleHTTPServer do Python, mas depois que comecei a desenvolver a projeto de fato prefiri utilizar o Github Pages pois assim facilitaria o deploy e também estou mais acostumado com o mundo Ruby de qualquer maneira.

Comecei lendo alguns tutoriais sobre o Phaser.

E ir implementando cada um dos requisitos iniciais que eu tinha.

Resolução

Antes estava utilizando a resolução de 800X600. No entanto ao adicionar um sprite do Mario Bros de NES numa resolução dessa, como pode imaginar o personagem ficou bem pequeno.

Então pesquisei sobre qual era a resolução do NES para fazer exatamente a mesma. Com isso alterei a resolução do jogo para a mesma do NES. No entanto em nossos monitores com resoluções maiores como deve imaginar a resolução de 256x240 é bem pequena.

Para resolver o problema eu fiz o resize do jogo diretamente pelo CSS aumentando em 2 vezes a resolução. Pesquisei sobre algumas soluções de fazer o resize, fiz testes e no final das contas utilizando apenas CSS consegui o mesmo resultado e com menos complexidade.

Game Design

No meio dos estudos acabei conhecendo o Tiled uma excelente ferramenta para criação de tile maps.

Com o Tiled consegui importar facilmente incluir o tilemap do Mario Bros de NES e criar a fase conforme eu quisesse.

Um fato legal do Tiled, é que por um acaso no processo do desenvolvimento do jogo estava jogando Shovel Knight: Plague of Shadows e ao finalizar percebi que nos créditos é listado o Tiled. Fiquei feliz de está utilizando a mesma ferramenta que o pessoal do Shovel Knight.

Como os arquivos originais do Tiled o .tmx é um XML e não era grande preferi manter eles no repositório e estava utilizando o formato JSON para carregar o tile map no jogo.

Assets

Para os assets utilizei o The Spriters Resource onde consegui os tile maps, itens, inimigos etc.

Para criar os personagens customizados, no caso Jéssica e eu, utilizei o Pixel.Tools um editor de pixel-art online. Na criação dos personagens customizados mantive a mesma paleta de cores do NES. Utilizei também o Pixel.Tools para gerar o logo do jogo.

Para os efeitos sonoros utilizei o The Sounds Resource.

Vendor

No processo preciva criar balões de fala no entano não queria ter que fazer isso do zero. Acabei encontrando uma discussão sobre isso aqui a solução pode ser encontrada aqui. Para manter isso isolado, adicionei tal código em uma pasta de vendor e alterei para atingir o que eu realmente precisava.

Não achei nenhum plugin pronto para o Phaser que fazia isso, aparentemente tem algum sistema de plugins, mas não cheguei a utilizar nenhum plugin no processo.

Roteiro

Além das tarefas de programar o jogo, era necessário escrever os textos para o mesmo, então para não negligenciar tais pontos criei tarefas no Trello para criar texto para todas as partes que tinha texto envolvido.

Testes e mais testes

Foi necessário bastante teste para ver se tudo estava rodando como deveria, e no caso aqui abrir o browser e rodar de fato o jogo, passar pelo jogo e ver se estava tudo certo.

Como a ideia era fazer o pedido o mais rápido possivel não pesquisei sobre testes automatizados. Acredito que seja razoavelmente simples testar classes especificas do jogo de forma unitária. Agora testes de ponta a ponta não cheguei a pesquisar.

Mundo real

Além das tarefas relacionadas ao jogo também criei outras tarefas no Trello relacionado ao mundo real como por exemplo “Comprar aliança”. Era importante criar tais tarefas para não esquecer de nada, além de poder priorizar com clareza o que deveria ser realizado na semana.

Tá mas e o tal jogo?

Então agora que você chegou aqui fica aqui o link para o código no GitHub tem também uma tag para a prova de conceito e uma tag para versão que foi utilizada para fazer o pedido.

Além disso você pode jogar o jogo em segredario.maurogeorge.com.br. Recomendo utilizar o Chrome, não sei por que mas no Firefox a perfomance não está boa.

Espero que curtam =D Sim ela curtiu e estamos noivos!

Rolify com Pundit para uma autorização com múltiplos papéis

2014-09-04T00:00:00+00:00

No último post utilizando o Pundit vimos como implementar um sistema de autorização com um único papel(single role). Porém os requisitos mudam e temos que responder a mudanças. Nosso problema agora é:

No sistema de gerenciamento de empresas temos 3 papeis o do gerente e o do empregado. O Gerente pode visualizar todas as telas do sistema. O empregado não pode criar, editar ou excluir nenhuma empresa. O investidor deve visualizar apenas as empresas em que ele investe.

Agora que nossos requisitos mudaram saimos de um sistema de um unico papel para multiplos papéis(multiple roles). Pois eu devo poder definir para cada um dos investidores quais empresas ele tem acesso, supondo que tenhamos as empresas A, B e C, deve ser possivel dizer que o investidor tem o papel investidor apenas na empresa A e C, ou seja ele possui 2 papeis diferentes.

Conhecendo o Rolify

O Rolify é uma gem responsável para lidar com papéis, possui uma interface legal que veremos durante o nosso exemplo.

Setup

Começamos pelo clássico, adicionar gem "rolify" no nosso Gemfile. Depois de instalado temos que rodar o gerador do Rolify.

$ rails g rolify Role User

Depois do gerador criado rode a migration gerada com $ rake db:migrate. Além da migration gerada será criado um model Role e adicionado uma macro rolify no nosso model User.

No exemplo do Pundit utilizamos o ActiveRecord::Enum para definirmos o nosso papel, o ideal seriamos movermos toda esta parte de papeis agora para o rolify, para não ficarmos com 2 sistemas de papeis diferentes, não entrarei em detalhes dado a isso ser bem simples como verá a seguir.

Definindo os recursos que aplicaremos um papel

Simplesmente adicionamos o macro resourcify no model que queremos utilizar na definição dos papeis.

class Company < ActiveRecord::Base
  # ...

  resourcify
end

Adicionando e removendo um papel

Agora com o setup definido vamos adicionar o nosso primeiro papel a um usuário. Para isso simplemente chamamos o método #add_role passando o papel e o recurso que estamos dando acesso ao usuário.

user.add_role :investor, company

Não entrarei no mérito de controller, ou onde este papel é definido.

Para removermos um papel de um usuário simplesmente utilizamos do método #remove_role.

user.remove_role :investor, company

Com isso já somos capazes de definir e remover papeis de usuários.

Garantindo a integridade dos papeis

O Rolify nos permite definir qualquer papel e ainda em qualquer entidade, mesmo aquelas em que não foram aplicados o resourcify.

user.add_role :magician, store

Como no nosso caso só temos o papel investor e o único recurso que estamos adicionando papel é o Company seria uma boa definirmos uma validação para isso. Assim evitamos que novos papeis sejam criados por engano, deixando o nosso código mais explicito.

O Rolify nos fornece um model Role então o que temos que fazer é apenas definir as validações de inclusão no mesmo.

class Role < ActiveRecord::Base

  NAMES = %w{ investor }
  RESOURCE_TYPES = %w{ Company }

  validates :name, inclusion: { in: NAMES }
  validates :resource_type, inclusion: { in: RESOURCE_TYPES }

  # ...
end

Agora ao tentarmos adicionar um papel e uma entidade que não existem com o #add_role não seremos capazes, receberemos um objeto Role não persistido como retorno.

Recuperando as empresas do usuário

O Rolify nos oferece query methods para interagirmos com nossos recursos que estão como resourcify. E com o método .with_role conseguimos recuperar todas as empresas em que possuem o papel investor e atrelada a um usuário especifico.

Company.with_role(:investor, user)

Assim temos todas as empresas em que o user é investidor, com uma simples chamada de método.

Pundit em conjunto com o Rolify

Voltando nos nossos requisitos, temos que listar apenas as empresas que o investidor investe. O Pundit nos permite definir um escopo baseado nas permissões do usuário para isso definimos uma classe Scope dentro do nosso CompanyPolicy e implementamos o método #resolve. Como estamos herdando do Scope do ApplicationPolicy já temos acesso ao user e ao scope a partir daí apenas fazemos a consulta que precisamos.

O Rolify define também o método #has_role? o utilizamos para verificar se o usuário possui qualquer papel de investor, caso ele possua listamos apenas as empresas em que ele tem acesso, caso não possua nenhum papel de investidor exibimos todas as empresas.

class CompanyPolicy < ApplicationPolicy

  # ...

  class Scope < Scope
    def resolve
      if user.has_role?(:investor, :any)
        scope.with_role(:investor, user)
      else
        scope.all
      end
    end
  end
end

Com o nosso escopo definido simplesmente chamamos ele no controller com o policy_scope.

def index
  @companies = policy_scope(Company)
end

Agora dependendo do papel do usuário é exibido uma listagem com todas as empresas, ou apenas com as que o usuário é investidor.

Conclusão

O Rolify é uma excelente ferramenta para quando necessitamos lidar com multiplos papéis em uma aplicação rails, e facilita ainda mais a nossa vida ao integrarmos ele com o Pundit. No nosso exemplo utilizamos o Active Record, mas o Rolify tem suporte ao Mongoid também. Não deixe de visualizar a wiki do Rolify para conhecer mais formas de adicionar/remover papéis, além das queries que ele implementa.

Referências

Autorização com Pundit

2014-09-02T00:00:00+00:00

Quem é da comunidade ruby há algum tempo já é acostumado com o CanCan e com o seu sucessor o CanCanCan que é a continuação do CanCan dado que o mesmo foi abandonado.

Em ambas das soluções temos apenas uma class Ability e definimos os nossos métodos de autorização ali. Para projetos pequenos pode ser uma boa saida, no entanto com o passar do tempo a complexidade aumenta e temos que extrair isso para classes expecificas e chama-las dentro da nossa interface do CanCan que é o model Ability. Mas e se já começassemos com uma abordagem mais inteligente? Com pequenas classes e cada uma definindo sua responsabilidade?

Olá Pundit

O Pundit utiliza o conceito de Policies ou Policy Objects para lidar com autorização. Mas antes de entrarmos a fundo no Pundit primeiro devemos ter um problema, então nosso problema é:

No sistema de gerenciamento de empresas temos 2 papeis o do gerente e o do empregado. O Gerente pode visualizar todas as telas do sistema. O empregado não pode criar, editar ou excluir nenhuma empresa.

Agora com o nosso problema em mão vamos iniciar. Não entrarei no mérito de autenticação, em que podemos utilizar o devise, nem na definição de papéis em que podemos utilizar o ActiveRecord::Enum.

Setup

Como de costume adicionamos ao nosso Gemfile gem "pundit". Depois de instalado incluimos o Pundit em nosso application controller.

class ApplicationController < ActionController::Base
  include Pundit

  # ...
end

Agora executamos o seu generator para termos a nossa primeira policy definida.

$ rails g pundit:install

Esta nossa primeira policy ainda não é utilizada ela será utilizada como base para as policies que formos definir. Ela define alguns padrões como por exemplo o destroy? como false, sendo assim se invocarmos um policy de destroy mas não o definirmos por padrão será false desde que herdermos de ApplicationPolicy.

Assim como o CanCan o Pundit utiliza do método current_user para pegar o usuário atual.

Criando nossa primeira Policy

Voltando lá ao nosso problema, devemos proteger as ações de criar, editar e excluir de empresa do usuário com o papel de empregado. Então vamos criar uma CompanyPolicy, para isso utilizamos do generator da seguinte maneira.

rails g pundit:policy company

Que nos gera uma classe para iniciarmos definindo a nossa policy. Então vamos definir primeiro que apenas o gerente pode criar uma nova empresa. Para isso definimos o método create?, por convenção o nome da action com um interrogação no final, e simplesmente utilizamos o método @user.manager? do User.

class CompanyPolicy < ApplicationPolicy

  def create?
    @user.manager?
  end
end

Com isso garantimos que apenas o usuário com o papel de gerente pode criar uma nova empresa. Mas você deve estar se perguntando, por que eu defini apenas o create? e não defini new? afinal não queremos que o funcionário acesse a tela de criar.

Isto ocorre por que no nosso ApplicationPolicy temos definidos estas regras da seguinte maneira.

def create?
  false
end

def new?
  create?
end

Ou seja new? executa o create? então devido ao poder da herança definimos apenas o create? em nossa classe filha. Este é um bom caso para o uso de herança, mas não se esqueça que composição tem um papel muito importante também quando estamos falando de orientação a objetos.

Em seguida definimos as demais policies da nossa company.

class CompanyPolicy < ApplicationPolicy

  # ...

  def update?
    @user.manager?
  end

  def destroy?
    @user.manager?
  end
end

Sem nada de novo aqui.

Aplicando nossa policy

Agora com nossa policy criada vamos a nosso controller de company aplicá-la. Para isso simplesmente utilizamos do método authorize e passamos o objeto que estamos testando.

def new
  @company = Company.new
  authorize @company
end

Não se esqueça de aplicar a policy para todas as actions que quer proteger.

Agora temos nossas actions protegidas, qualquer um que tentar acessar alguma dessas actions e não tiver permissão receberá uma excessão Pundit::NotAuthorizedError.

Protegemos o nosso controller, mas também não queremos links espalhados pelo sistema que levem a uma página de erro o ideal é esconde-los. Para isso vamos ao helper do pundit.

Aplicando nossa policy na view

O Pundit nos oferece o helper policy para utilizarmos na view para checarmos alguma policy. Para checarmos a exibição do link de criar por exemplo, fazemos assim.

- if policy(Company).new?
  = link_to 'Nova empresa', new_company_path

Passamos apenas a classe dado que não estamos referenciando nenhum registro. Na listagem passamos o proprio objeto para o Pundit.

- if policy(company).update?
  td = link_to 'Editar', edit_company_path(company)

O legal do passarmos um objeto para dentro do Pundit, é que podemos por exemplo exibir o link de editar apenas para o gerente e em que a empresa tenha sido homologada por exemplo.

Por uma boa mensagem de erro

Até o momento caso algum usuário acesso alguma das actions em que ele não tem permissão ele recebe apenas uma excessão, o que se torna um erro 500 em produção, e não queremos isso. Então vamos tratar esta excessão para exibirmos uma boa mensagem de erro.

No nosso ApplicationController resgatamos da excessão e redirecionamos o usuário com uma mensagem de erro.

class ApplicationController < ActionController::Base

  # ...
  rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized

  private

    def user_not_authorized
      flash[:error] = 'Você não tem permissão para fazer esta ação'
      redirect_to(request.referrer || root_path)
    end
end

Agora o usuário recebe uma melhor mensagem de erro.

Conclusão

O Pundit é uma boa alternativa ao CanCan, no entanto utilizando de objetos Ruby sem nenhuma DSL ou nada fancy. Não entrei no mérito dos testes para não alongar demais o post, mas o Pundit possui uma integração com o RSpec o que facilita bastante a nossa vida. Não deixe de experimentá-lo e tirar suas próprias conclusões.

Lançamento do Livro RSpec: Crie especificações executáveis em Ruby

2014-07-29T00:00:00+00:00

Há um tempo escrevi que estava começando a escrever um e-book e hoje é hora de anunciar que finalizei o livro e ele foi lançado hoje pela Casa do Código \o/.

E com isso o que muda da proposta original?

Não poderei disponibilizar uma versão gratuita, que eu planejava enquanto eu estava trabalhando sozinho e ainda não fazia ideia de como publicar o mesmo.

No entanto em relação ao conteúdo nada foi alterado, tive total flexibilidade para escrever o quanto eu quisesse. Com a vantagem de ter a revisão e instrução dos editores da Casa do Código. E mais, agora teremos uma versão impressa e em diversos formatos digitais.

Ou seja com esta parceria com a Casa do Código o livro só teve a ganhar, primeiro pela edição e revisão de uma equipe de profissionais e na publicação que eu não tive que me preocupar em como iria fazer, assim pude deixar este trabalho para quem já está no mercado fazendo isso no dia a dia.

Outra parceria que foi firmada no caminho foi com a HE:labs que me cedeu algumas horas por semana do meu trabalho para me dedicar ao livro, o que ajudou bastante no andamento <3

É isso pessoal espero que gostem do conteúdo do livro, não deixe de conferir!

Flexibilidade na criação de métodos com named parameters

2014-07-08T00:00:00+00:00

Temos que calcular o frete de um produto para isso temos que saber qual a sua altura, largura, profundidade, preço e peso deve ser possivel selecionar qual a unidade de medidas que enviaremos a informação.

Para resolver este problema criaremos uma classe que recebe estas opções. Como são diversas opções utilizaremos um hash, para não precisarmos ficar dependendo da ordem dos paramêtros.

class ShippingCalculator

  def initialize(options = {})
    @options = options
  end

  def call
    options
  end

  private

    attr_reader :options
end

Nosso método call simplesmente retorna os paramêtros apenas para a simplicidade do exemplo, também não nos preocupamos em checar a presença dos valores. Nosso exemplo funciona e é um padrão adotado pela comunidade Ruby.

Percebemos que é muito comum definirmos o paramêtro unit sempre com o valor :metric para utilizar a unidade de medida métrica. Então vamos definir isto como padrão da nossa classe. Para isso criamos uma constante com o valor como padrão e o juntamos com os paramêtros passados.

class ShippingCalculator

  DEFAULT_OPTIONS = {
    unit: :metric
  }

  def initialize(options = {})
    @options = DEFAULT_OPTIONS.merge(options)
  end

  # ...
end

Legal! Agora não precisamos mais ficar passando o unit apenas quando formos utilizar outro sistema de medida que não seja o métrico.

A partir do Ruby Ruby 2.0.0 foi incluido o suporte a named parameters o que nos permite declarar paramêtros nomeados que é exatamente como fizemos no exemplo anterior com o hash. Vamos alterar o nosso código parar utilizar do named parameter.

class ShippingCalculator

  def initialize(unit: :metric)
    @options = { unit: unit }
  end

   # ...
end

Como pode ver temos acesso ao paramêtro passado diretamente, simplesmente o adicionamos a um hash para mantermos o nosso retorno. No entanto no Ruby 2.0.0 para definirmos os named parameter temos que definir todos com um valor padrão. Se tentarmos passar o atributo weight por exemplo receberemos uma exceção unknown keyword: weight (ArgumentError) dado que ele não foi declarado.

Para não precisarmos ter que definir um valor padrão para cada um dos atributos podemos receber mais opções utilizando do ** e juntarmos estas opções com os paramêtros que definimos no named parameter.

class ShippingCalculator

  def initialize(unit: :metric, **options)
    @options = { unit: unit }.merge(options)
  end

   # ...
end

A partir do Ruby 2.1.0 foi removida esta necessidade de todos os named parameter ter que ter um valor padrão. Alteramos nosso exemplo para aceitar cada um dos named params.

class ShippingCalculator

  def initialize(unit: :metric, weight:, lenght:, width:, height:, price:)
    @options = { unit: unit, weight: weight, lenght: lenght, width: width,
                 height: height, price: price }
  end

   # ...
end

Sei que você vai me dizer que este código é mais verboso do que aquele que fizemos com o Ruby 2.0 certo? Concordo, no entanto aqui ganhamos de bônus estes paramêtros serem requeridos, que foi uma parte da nossa classe que não implementamos, no entanto não queremos que seja possivel realizar um cálculo de frete sem o peso certo? Agora será lançada uma exceção ArgumentError informando os paramêtros que não foram enviados.

Lembrando que além do named parameter, que pode ter seu valor padrão definido ou não, podemos fazer como no exemplo do Ruby 2.0 e aceitar paramêtros extras.

class ShippingCalculator

  def initialize(unit: :metric, weight:, lenght:, width:, height:, price:, **options)
    @options = { unit: unit, weight: weight, lenght: lenght, width: width,
                 height: height, price: price }.merge(options)
  end

   # ...
end

É muito legal ver um padrão criado pela comunidade ser adotado como funcionalidade da linguagem. Como pode ver temos uma grande flexibilidade quando vamos definir paramêtros para os nossos métodos.

Removendo hash-driven development com Struct e OpenStruct

2014-07-06T00:00:00+00:00

Temos que criar uma classe que exiba as informações de um Pokémon baseado no seu id nacional consumindo estes valores de uma API. Para isso simplesmente acessamos a API e parseamos a resposta do JSON a retornando por completo.

class FetchPokemon

  def initialize(national_id)
    @national_id = national_id
    build_info
  end

  def call
    info
  end

  private

    attr_reader :national_id, :info

    def endpoint
      URI("http://pokeapi.co/api/v1/pokemon/#{national_id}/")
    end

    def build_info
      response = Net::HTTP.get(endpoint)
      @info = JSON.parse(response)
    end
end

Este código atende a nossa necessidade mais podemos melhorar o seu retorno, pois hoje precisamos apenas do nome, altura e peso. Então vamos alterar o nosso método call para retornar apenas estes atributos do info.

class FetchPokemon
  # ...

  def call
    { name: info['name'], height: info['height'], weight: info['weight'] }
  end

  # ...
end

Agora temos apenas as informações que necessitamos. No entanto seria melhor se tivessemos um objeto Pokemon e não um hash, com um objeto sabemos exatamente com que estamos lidando, qual a entidade. E assim evitamos o hash-driven development e utilizamos uma abordagem orientada a objetos.

Para isso criamos uma inner class Pokemon que define exatamente os atributos que precisamos e os expõe através de um attr_accessor.

class FetchPokemon
  # ...

  def call
    Pokemon.new(info['name'], info['height'], info['weight'])
  end

  private
    # ...

    class Pokemon

      attr_accessor :name, :height, :weight

      def initialize(name, height, weight)
        @name, @height, @weight = name, height, weight
      end
    end
end

Não se esqueça que uma inner class possui o comportamento diferente de quando estamos utilizando módulos como namespace. No nosso caso não é um problema dado que estamos utilizando a classe Pokemon apenas como um container, não nos importamos com nada declarado na classe FetchPokemon.

Agora nossa classe FetchPokemon retorna um FetchPokemon::Pokemon no método call, bem legal. No entanto estamos repetindo 3 vezes cada atributo na declaração da classe.

Para remover esta repetição podemos criar um Struct que faz exatamente o que precisamos: cria accessors para cada um dos atributos passados no initialize.

class FetchPokemon
  # ...

  def call
    Pokemon.new(info['name'], info['height'], info['weight'])
  end

  private
    # ...

    Pokemon = Struct.new(:name, :height, :weight)
end

Continuamos com o FetchPokemon::Pokemon como classe no entanto removemos a repetição ao se declarar a classe Pokemon.

OpenStruct

Para casos em que desejamos transformar um hash completo em um objeto temos o OpenStruct. Voltando lá no inicio quando tínhamos um hash reduzido com apenas as informações que precisamos podemos criar uma classe Pokemon a partir dele utilizando do OpenStruct.

Para isso criamos uma classe Pokemon que herda de OpenStruct.

class FetchPokemon
  # ...

  def call
    Pokemon.new(name: info['name'], height: info['height'], weight: info['weight'])
  end

  private
    # ...

    class Pokemon < OpenStruct
    end
end

Seja utilizando o Struct ou o OpenStruct teremos um objeto FetchPokemon::Pokemon a diferença é que um será herdado de Struct e outro de OpenStruct.

fetch_pokemon = FetchPokemon.new(6)
pokemon = fetch_pokemon.call # => #<FetchPokemon::Pokemon name="Charizard", height="17", weight="905">
pokemon.name                 # => "Charizard"

Com este refactoring saimos de um hash para uma entidade Pokémon, que deixa claro o que é aquele objeto. Afinal um hash que tem informações de um pokémon é um pokémon, então deixe isso explícito.

Rails e o Development Seed

2014-07-05T00:00:00+00:00

Você mudou de equipe e começou em um projeto novo, rodou bundle, migrate e iniciou o servidor. Criou uma conta neste novo sistema e… WTF este sistema faz?

É comum o projeto depender de algumas(muitas) informações para ele começar a mostrar estas informações ao invés de um monte de blank slates. Algumas destas informações algumas vezes são cadastradas apenas pela área administrativa do sistema. Como podemos deixar mais fácil a entrada de novos membros em um novo projeto?

No Rails podemos definir o nosso seed em db/seeds.rb. Mas como queremos que nosso seed seja carregado apenas em desenvolvimento vamos criar um arquivo especifico para ele em db/seeds/development.rb. Este arquivo não é carregado por padrão quando rodamos nosso seed, para fazer isso simplesmente o carregamos no nosso seed quando o ambiente for development.

# db/seeds.rb

if Rails.env.development?
  require_relative 'seeds/development'
end

E agora simplesmente criamos o nosso seed.

# db/seeds/development.rb

def create_posts_to(user)
  total_of_posts = rand(1..3)
  total_of_posts.times.each do |i|
    user.posts.create!(title: "Post #{i} from #{user.name}",
                       content: "Content of post #{i}")
  end
end

unless User.any?

  (1..10).each do |i|
    puts "Creating User #{i}"
    User.create!(name: "User #{i}", email: "user#{i}@example.com")
  end
end

unless Post.any?

  User.all.each do |user|
    puts "Creating posts to user #{user.name}"
    create_posts_to(user)
  end
end

Como queremos que o seed seja executado apenas quando não tivermos estas informações verificamos por elas antes de criarmos utilizando o any?. Criamos um pequeno método para gerar os posts, pois assim cada usuário não terá sempre o mesmo número de post para isso utilizamos o rand. E como dica sempre use métodos que lance uma exceção em caso de erro pois se alguma validação falhar por exemplo temos o feedback mais rápido.

Seguindo esta prática você está ajudando a:

Novas pessoas que entrarem no projeto
Você mesmo quando precisar reiniciar o banco de dados ou trocar de máquina

Lembrando que sempre temos que revisitar estes seeds pois novos campos são adicionados no banco, novas validações e mesmo novos models que ainda não foram criados. Podemos revisitá-los quando rodamos o seed em algum momento ou quando uma nova pessoa entra no projeto e sente falta de alguma informação. Ela já pode contribuir gerando esta informação no seed.

Aprendi esta técnica enquanto trabalhava com o Fábio =)

Pode parecer uma boa ideia utilizar FactoryGirl, mas não é ;p saiba mais aqui.

Caso queira dados “mais reais” pode utilizar o faker.

Precisando de uma solução mais complexa de uma olhada no seedbank.

Placehold de imagens com o placehold.it

2014-07-02T00:00:00+00:00

Quando estamos fazendo o nosso Front-end é comum ter momentos onde ainda não termos o upload de imagem funcionando por exemplo e temos que exibir uma imagem padrão. Para evitar o processo de criar uma imagem no Photoshop com as medidas exatas podemos utilizar o placehold.it que gera uma imagem para nós.

Para termos um resultado como o:

Simplesmente criamos uma imagem utilizando o placehold.it da seguinte maneira.

<img alt="Placeholder de 350x150" src="http://placehold.it/350x150">

Por padrão o formato é gif, podemos alterar simplesmente passando o formato.

<img alt="Placeholder de 350x150" src="http://placehold.it/350x150.png">

Podemos passar um texto qualquer para ser renderizado, passando o parametro text.

<img alt="Placeholder de 350x150" src="http://placehold.it/350x150.png&text=Mauro">

Podemos customizar a cor do background e do texto, passando os paramêtros nessa ordem.

<img alt="Placeholder de 350x150" src="http://placehold.it/350x150.png/ffffff/000000&text=Mauro">

As cores devem ser definidas sempre depois das dimensões.

Fica aí com mais uma ferramenta para ajudar no desenvolvimento Front-end.

Good Bye Jacaranda and welcome ActiveRecord::Enum

2013-12-29T00:00:00+00:00

A time ago I want to create a Gem to learn how this works. But in the Ruby/Rails world we live in a mature community when we have a lot of libs to do our job, so I give up for a moment, until I have a problem that more people have experiencied too.

So in a moment I find a pattern, that I and my friends do. When I have a model, with validation of inclusion like this:

class Post < ActiveRecord::Base
  validates :status, inclusion: { in: %w{published unpublished draft} }
end

I normally need predicate methods like @post.published? and scopes like Post.published. So by this idea and some work born Jacaranda my first gem.

But now in the rails 4.1.0, I testing using 4.1.0.beta1 since no release yet. We have the ActiveRecord::Enum that can do the same thing we do with Jacaranda.

Meeting the ActiveRecord::Enum

Lets create the same behavior of Jacaranda now using the ActiveRecord::Enum.

Migration

We started with a migration like this.

class CreatePosts < ActiveRecord::Migration
  def change
    create_table :posts do |t|
      t.string :title
      t.integer :status, default: 0

      t.timestamps
    end
  end
end

The important part is the column is a integer and we set the default value as 0.

Model

In our model we simply use the macro enum.

class Post < ActiveRecord::Base

  enum status: %w(published unpublished draft)
end

In the Wild

Predicate methods

We start with a post with status is published. Remember you need to pass to the model the string and not integer, a ArgumentError is raised if you try pass the integer value.

Post.create(title: 'Post title', status: 'published')
post = Post.first
post.published? # true
post.draft? # false

Scopes

We can use the scopes with the same name as declareted on our model.

Post.published # SELECT "posts".* FROM "posts"  WHERE "posts"."status" = 0

Search is made using the integer value on the database.

The bang!

The bang are not in Jacaranda, but are cool =)

You can use the bang method to change the status of post.

post.draft!
post.status # "draft"

Now our post have the status as a draft.

One cool thing about the ActiveRecord::Enum is that all values are stored like a integer and accessed as a string.

Using explicit mapping

Add status without key can be annoying since if one new status is added in a wrong position all objects have values changed.

class Post < ActiveRecord::Base

  enum status: %w(reviewed published unpublished draft)
end

We add reviewed before the published, so now all published posts have the status as reviewed.

To avoid this problem, we can use the explicit mapping like.

class Post < ActiveRecord::Base

  enum status: { published: 0, unpublished: 1, draft: 2, reviwed: 3 }
end

This way we dont care about the order but with the value.

Of course good specs ensure we are adding a thing that dont break others.

Conclusion

Jacaranda is now deprecated, since we can use the ActiveRecord::Enum.

I learned a lot in the way using services like:

I used the Semantic Versioning. I learned how hard is the work to maintain a Gem. I started work in others open source projects. And is so enjoyable know that I was in the right direction =)

Criando um ambiente de staging no heroku para nossa rails app

2013-11-21T00:00:00+00:00

É uma boa prática termos um ambiente que rode no heroku, mas que não seja o ambiente de produção, este ambiente é chamado de staging, um ambiente que é o mais proximo de produção.

Primeiro temos que criar uma app de staging no heroku, dado que nossa app tenha o nome de myapp crie uma heroku app com o nome de myapp-staging para isto podemos utilizar do heroku fork.

$ heroku fork -a myapp myapp-staging

Primeiro temos que dizer ao rails que temos um ambiente de staging para isso temos que criar o config/environments/staging.rb. Simplesmente cria o arquivo config/environments/staging.rb com o mesmo conteúdo do config/environments/production.rb apenas trocando o log_level para :debug.

Myapp::Application.configure do

  # ...
  config.log_level = :debug
end

No heroku agora utilizamos a gem rails_12factor, no entanto ele apenas recomenda o uso em :production, devemos incluir o nosso ambiente de staging aqui também no nosso Gemfile.

gem "rails_12factor", '0.0.2', group: [:production, :staging]

Como este ambiente é um ambiente para apenas os usuários que desejamos visualizar, como os colaboradores do nosso sistema, colocamos um basic auth apenas no ambiente de staging.

class ApplicationController < ActionController::Base

  #...
  http_basic_authenticate_with :name => "name", :password => "secret" if Rails.env.staging?
end

Para finalizar definimos as variaveis de ambiente no heroku, devemos definir o RACK_ENV e o RAILS_ENV.

$ heroku config:set RACK_ENV=staging RAILS_ENV=staging --app myapp-staging

Caso estejamos utilizando serviços como Amazon S3, Facebook etc. É uma boa pratica termos um bucket exclusivo de staging no caso da S3 e uma app do facebook para staging, assim como qualquer outro serviço que estejamos utilizando.

Adicione as variaveis de ambiente destes serviços como S3(AMAZON_S3_BUCKET, AMAZON_ACCESS_KEY_ID, AMAZON_SECRET_ACCESS_KEY), Facebook(FACEBOOK_APP_KEY, FACEBOOK_APP_SECRET) e qualquer outra variável de ambiente necessária para a sua app funcionar.

Deste modo temos uma app que é bem próxima de produção, assim reduzimos a chance de termos alguma surpresa desagradável.

RSpec Best Friends meu primeiro e-book

2013-11-10T00:00:00+00:00

Sim, estou escrevendo um e-book =) Seguindo a sugestão do meu amigo Cayo, vou compartilhar com a comunidade a minha ideia.

A ideia é falar sobre o ecossistema que existe em volta do RSpec, e como isso agiliza o trabalhao do dia a dia. Não é um e-book para iniciante mais para quem já sabe usar o RSpec no dia a dia é quer aprender técnicas para melhorar e agilizar o processo de BDD.

Os tópicos que falarei:

factory_girl
shoulda-matchers
webmock
vcr
email_spec
timecop
rspec-sidekiq
simplecov
mongoid-rspec
mock/stub
factory_girl-preload
gems com matchers, como paperclip

Até o momento tenho ~30 páginas escritas sobre o mongoid-rspec. Eu estava pensando em ter um e-book de aproximadamente 100 páginas, mas pelo jeito isto vai crescer.

Mas ainda assim acho que não será uma leitura massante devido a maioria dos capítulos poder ser usado como um guia de consulta rápida. E aparentemente não terá uma ordem lógica de leitura.

Estou usando como ferramenta o kitabu do Nando. Ainda não parei para estilizar nada apenas estou gerando um pdf no modo default mesmo.

No momento estou focado em apenas escrever o e-book, não pensando em publicação ou qualquer outra coisa. Mas a principio penso lança-lo como foi lançado o Objects on Rails uma versão online de graça e uma versão paga com PDF, epub, mobi etc.

Para finalizar deixo um form para quem quiser ajudar o projeto.

Dúvidas comuns do RVM

2013-10-10T00:00:00+00:00

Dúvidas que algum dia você já teve, ou terá enquanto utiliza o RVM, respondidas aqui.

Qual o ruby e o gemset que estou atualmente?

Utilizamos o current quando queremos saber qual o ruby e versão estamos utilizando atualmente.

$ rvm current

Como defino um gemset como default?

Para definirmos um gemset como default usamos o seguinte comando:

$ rvm  --default use 2.0.0@global

é uma boa prática definir o @global como gemset padrão.

Como faço para criar e usar um gemset?

Parar criar e já sair usando um gemset utilize o seguinte comando:

$ rvm use 2.0.0@rails --create

este eu utilizo muito para começar a trabalhar em projetos open source =)

Como faço para utilizar um gemset?

Parar usar um gemset utilize o seguinte comando:

$ rvm use 2.0.0@rails

também muito utilizado para trabalhar com open source, dado que muito dos projetos não colocam em seus repos o .ruby-version e .ruby-gemset.

Como faço para ver os gemsets criados?

Para listar os gemsets utilizamos o seguinte comando:

$ rvm gemset list

Como faço para remover todas as gems de um gemset?

Para remover todas as gems de um gemset rode:

$ rvm gemset empty my_gemset

Como saber qual a última versão de uma gem no Rubygems

2013-10-10T00:00:00+00:00

Quando queremos instalar uma nova gem é comum procurarmos em qual versão a Gem se encontra atualmente. Podemos obter este valor das seguintes maneiras:

acessando o Readme e procuramos a versão, isso se o autor se importou em colocar este valor lá;
Rubygems, exemplo;

nenhum dos 2 modos é muito prático, para ambos você deve sair do terminal para ir atrás destes valores. O que eu uso e recomendo é o seguinte comando do Rubygems:

$ gem list jacaranda -r

ele retorna uma lista com a gem e sua ultima versão estável.

Claro que isso não quer dizer que não tenhamos sempre que ler o Readme, e Changelog das gems para sabermos como funciona, instalamos etc. Mas ajuda em uma gem que costumamos usar, e precisamos saber apenas em qual versão ela está atualmente.

Por que você deve ir ao HDC 2013

2013-09-26T00:00:00+00:00

Para quem não sabe, sou autodidata nunca sequer comecei uma faculdade. Mas nesse caminho sentia falta de feedback de saber se estou trilhando o caminho certo, se o que eu faço está certo e o que pode melhorar. Um modo que achei para resolver isso foi participar de eventos de tecnologia, fazer cursos com gente da área que confio, participar dos eventos da comunidade de Software Livre aqui do Rio de Janeiro e por fim trabalhar na HE:labs uma empresa que apoia tudo isso <3 pois assim sempre estaria cercado de gente boa e que ama o que faz.

Sei que nem todos que trabalham com TI gostam, para estes simplesmente recomendo que vá procurar outra coisa, fazer o que não gosta deve ser horrivel, ainda mais que deve estar pelo menos 8h por dia nisso, na boa faça outra coisa =)

Mas para os que gostam recomendo muito ir ao evento, pois terá bastante gente legal palestrando além de bastante gente para se conversar fora das palestras.

Venha para o evento com o pensamento de se divertir, aprender e conhecer pessoas. Sabe aquele cara que você conhece que avassala provavelmente ele estára aqui no evento vem dizer isso para ele, com certeza o cara ficará feliz.

Conheci muita gente foda nesse caminho como o Henrique Bastos, Mergulhão, Rafael Lima, Tapajós, Nando entre muitos outros nomes que você deve conhecer. Já trocamos ideias, almoçamos e fomos para o Bar =)

Então venha para o evento com o intuito de conhecer pessoas, é sempre legal ouvir a opinião dos outros.

Mas não venha com pensamentos de conhecer pessoas por interesse de vagas, projetos ou algo assim, venha conhecer a pessoa pelo seu trabalho se rolar algo assim bom, mas não venha com este pensamento. Venha com o pensamento de se divertir.

Para você ter uma ideia de como quando gostamos do que fazemos não vemos como trabalho. Eu estou de férias no momento em que escrevo este post, além disso nas férias eu fiz a minha página pessoal, refiz o design desse blog, to fazendo minha palestra para o evento, to aprendendo elixir e contribui em projetos open source.

Para fechar deixo aqui um relato meu de 11 abril 2010 da minha experiência quando comecei conhecer a galera das comunidades de Software Livre aqui do Rio.

To postando aqui pois lá no grupo a mensagem não apareceu.

Seguindo conselho do Henrique Bastos vou escrever aqui como foi a minha experiência com o pessoal do Pyhton Rio.

Resolvi ir ao EDTED em março de 2010, tive que ir sozinho pois onde trabalho ninguém foi e como todos são focados em design provavelmente não assistiríamos as mesmas palestras. Chegando ao evento havia palestras que estavam em áreas de maior destaque para mais de 200 pessoas, no entanto achei que seria mais interessante o minicurso de DJANGO pois afinal era 2:30 contra as palestras de 1:00. Fui em uma área ao fundo do evento e perguntei o que seria ali e se eles eram o pessoal do #horaextra. E me responderam que seriam um Dojo e que sim eles eram o pessoal do #horaextra, conhecia o dojo apenas pela internet, devido a ocorrer a noite e eu morar longe de tudo fica complicado para eu ir, mais pretendo ir. Perguntei quem iria palestrar sobre DJANGO foi quando o Henrique falou que seria ele e me mostrou a sala onde ocorreria a palestra. A palestra rolou bem legal em um clima descontraído, nada de só porque o Henrique palestrava ele ter um ar de superioridade ele era como todos nos ali afinal todos queríamos aprender. Após a palestra fomos todos nos almoçar juntos e voltamos em seguida para as lighting talks, clima também descontraído e palestras curtas. Por volta das quatro e pouco prefiri vir embora afinal já havia acabado as lighting talks, vi um pouco do dojo mais devido a hora preferi vir embora. Me despedi do Henrique e perguntei a ele como aprender DJANGO primeiro aprendo Python? E ele me deu um cartão e falou para eu aparecer em um dos encontros. Não havia ido em nenhum encontro até ontem, pois como já falei eles são a noite eu moro longe, ontem fui no Forkin’rio na casa do Bernardo, aprendi e me diverti bastante mesmo sem ter feito exercícios, pois meu pc estava ruim. Resumindo depois de ter me alongado muito, valeu mais a pena ver uma palestra “humana” para 30 pessoas do que uma para mais de 200 em que provavelmente o conteúdo se perderia e seria muito superficial. Então é isso quem quiser se juntar ao grupo vale muito a pena devido a amizade e de aprender todos juntos, e se morar longe tenta aparecer pelo menos nos que ocorrem de dia, afinal para eu chegar a casa do Bernardo tive que acordar 6:20, começava as 9:00, e pegar 3 ônibus, mais valeu a pena.

Então se você chegou até aqui, acredito que lhe convenci a ir ao evento. Para estes peço que depois do evento escreva em um blog, site, gist como foi sua experiência.

Grande abraço e nos vemos lá

Factory Girl e Paperclip usando os 2 de mãos dadas

2013-07-10T00:00:00+00:00

Imagine a seguinte situação seu model User ganhou um atributo novo, avatar, e este atributo é uma imagem do Paperclip detalhe que está imagem é obrigatória. Como arrumar a sua factory para definir esta imagem? Já que agora todos as specs que usam esta factory estão quebrando devido a obrigatoriedade do avatar.

Usando um File

Talvez o primeiro movimento seria passar um file para a factory.

FactoryGirl.define do
  factory :user do
    name "John Doe"
    avatar File.new('spec/fixtures/photo.jpg')
  end
end

No entanto isto é problemático pois:

A imagem realmente está sendo enviada para a S3, deixando meus testes mais lentos e dependentes de rede. Claro que posso usar o VCR para salvar estas requisições, mas imagina a quantidade de specs usando esta factory, imagina agora o trabalho de colocar todas estas specs no VCR, realmente não parece uma boa ideia. E o pior teria que se lembrar de toda vez que fosse usar tal factory as specs teriam que está usando o VCR.

Usando um before create

A solução que tenho usado no momento é definir um before create na factory, definindo os campos salvos pelo paperclip.

FactoryGirl.define do
  factory :user do
    name "John Doe"

    before :create do |user|
      user.avatar_file_name= "photo.jpg"
      user.avatar_content_type = "image/jpeg"
      user.avatar_file_size = 2588 
      user.avatar_updated_at = Time.zone.now
    end
  end
end

Assim não é enviado nada para a S3, assim não preciso me preocupar em chamar o VCR nas minhas specs antigas ou novas usando tal factory. E o melhor não preciso fazer nada onde a factory já é usada, pois agora ela simplesmente funciona não dando erro de validação do campo avatar.

Se você resolve este problema de outra forma ou achou útil a dica, comenta aí!

Logs melhores do unicorn no ambiente de desenvolvimento Rails

2013-07-09T00:00:00+00:00

Uma boa prática é termos o nosso ambiente de desenvolvimento o mais próximo de produção, de preferência igual.

Há algum tempo trabalho em alguns projetos que usam o Unicorn, o problema que tinha era não ter um log em desenvolvimento parecido com o WEBrick.

Meus logs saiam como:

127.0.0.1 - - [09/Jul/2013 08:56:08] "POST /usuario/entrar HTTP/1.1" 200 - 0.4803

Para melhorar o log, podemos definir em config/environments/development.rb a seguinte configuração:

config.logger = Logger.new(STDOUT)

E agora meus logs são mais bonitões, saindo assim:

Started POST "/usuario/entrar" for 127.0.0.1 at 2013-07-09 08:53:52 -0300
Processing by SessionsController#create as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"OhLmZiYG84pfwAhftomXQaFno5Cq3sPNGAYc9U3KUxM=", "user"=>{"email"=>"johndoe@example.com", "password"=>"[FILTERED]", "remember_me"=>"0"}, "commit"=>"Entrar"}
  MOPED: 127.0.0.1:27017 QUERY        database=estoujogando_development collection=users selector={"$query"=>{"email"=>"johndoe@example.com"}, "$orderby"=>{:_id=>1}} flags=[] limit=-1 skip=0 batch_size=nil fields={"notifications"=>0} (21.7881ms)
Completed 401 Unauthorized in 189ms
Processing by SessionsController#new as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"OhLmZiYG84pfwAhftomXQaFno5Cq3sPNGAYc9U3KUxM=", "user"=>{"email"=>"johndoe@example.com", "password"=>"[FILTERED]", "remember_me"=>"0"}, "commit"=>"Entrar"}
  Rendered sessions/_login_form.html.haml (16.0ms)
  Rendered registrations/_pre_register_form.html.haml (2.8ms)
  Rendered sessions/new.html.haml within layouts/login (31.1ms)
  Rendered application/_flash_messages.html.haml (9.0ms)
  Rendered application/_login_nav.html.haml (2.6ms)
Completed 200 OK in 378ms (Views: 284.3ms | Solr: 0.0ms)

É isso, post rápido, espero que seja útil para alguem a dica.

Quando entrei para a igreja do Vim

2013-04-27T00:00:00+00:00

O título do post foi baseado em um comentário do amigo Argentino enquanto conversavamos no Gtalk ele me perguntou por que eu tinha entrado para igreja do Vim.

Por que o Vim?

Já há algum tempo tenho vontade de aprender, de verdade, um editor de texto, antes do Vim utilizava o Textmate mas não usava quase nenhuma de suas funcionalidades. E segui a seguinte lógica, se fosse para aprender um editor de texto iria aprender o Vim.

Recentemente assisti uns PeepCode com Aaron Patterson, Corey Haines e Ben Orenstein e todos utilizavam o Vim, além de uns amigos como o Pedro, VP e o próprio Argentino. O que só me motivou mais e decidi botar o plano em prática.

Por onde começar

Vou relatar aqui o que usei/tenho usado para o aprendizado.

Os 2 PeepCode sobre vim I e II
Tradução Aprenda Vim Progressivamente do Tarsis Azevedo

.vimrc

Caso escolha seguir o caminho de usar o Vim, irá saber que o .vimrc é um dos seus arquivos de configuração para o Vim. Deixo aqui o link para o gist da primeira versão do meu .vimrc foi baseado no do PeepCode, no entanto removi bastante coisa que não sabia para que servia, queria tentar manter o mais simples até começar a adicionar plugins e etc. Recomendo usar esta versão para quem está começando já que ele exibe os numeros das linhas, tem syntax highlight etc. Quando foi escrito este post o meu .vimrc estava assim usando o Vundle e alguns plugins.

Por hora estou usando apenas o gist, pois ainda estou adicionando os plugins conforme a necessidade surge, mas quem sabe algum dia use um repo para isso.

Caso queira dar uma olhada em como o pessoal tem configurado o vim, deixo aqui uns repos que andei observando também:

Trate o ruby como a linguagem dinâmica que ele é

2013-04-10T00:00:00+00:00

O Ruby é uma linguagem de tipagem dinâmica, e para pessoas que vem de linguagens de tipagem estática tem que mudar sua mentalidade para trabalhar com uma linguagem dinâmica, veremos o que fazer e o que não fazer e como podemos lidar com o que as linguagens dinâmicas tem de ruim, afinal nem tudo são flores.

Não fazemos checagem de tipos

Pode assustar um pouco a idéia de não fazermos nenhuma checagem de tipo, quando definimos um método que aceita parâmetros, definimos apenas o nome dos parâmetros e não o seu tipo:

def my_name_is(name)
  "My name is #{name}"
end

Veja que não definimos nenhum tipo para o parâmetro name. Assim como não precisamos definir o tipo de nossos atributos de classe. E graças a esta não checagem de tipo que podemos usar uma das coisas mais legais da linguagem o Duck Typing, que veremos a seguir.

Não fazemos interfaces

Imagine que em nosso sistema tenhamos 2 entidades Post e AwesomePost, que é um post em destaque. Agora sempre queremos garantir que ambos tenham definidos os atributos title e content. Talvez tenderíamos a usar uma interface, no entanto o ruby não tem suporte a interfaces, mas podemos simular uma fazendo algo como:

class BasePost

  def title
    raise "Not implemented"
  end

  def content
    raise "Not implemented"
  end
end

class Post < BasePost

  def initialize(title, content)
    @title = title
    @content = content
  end

  def title
    @title
  end

  def content
    @content
  end
end

class AwesomePost < BasePost

  def initialize(title, content)
    @title = title
    @content = content
  end

  def title
    "The awesome post: #{@title}"
  end

  def content
    "The awesome content: #{@content}"
  end
end

Que poderia ser utilizado:

post = Post.new("A new post", "content")
p post.title # "A new post"
p post.content # "content"

post = AwesomePost.new("A new awesome post", "Awesome content")
p post.title # "The awesome post: A new awesome post"
p post.content # "The awesome content: Awesome content"

O código acima funciona, no entanto não é um bom código ruby. O problema não é nas classes Post e AwesomePost e sim na classe BasePost que não faz absolutamente nada. BasePost existe apenas como uma tentativa de mantermos uma interface padrão para as classes Post e AwesomePost ou qualquer outra classe de Post que venhamos a criar.

No entanto é um esforço em vão pois como vimos anteriormente, não fazemos checagem de tipos na chamada de um método, sendo assim pouco importa a hierarquia de classes de um tal objeto, desde que ele saiba responder a tal método e é neste ponto que chegamos ao Duck Typing.

Abrace o Duck Typing

Utilizando o Duck Typing, primeiro podemos remover a classe BasePost e remover a herança de Post e AwesomePost afinal ambas as classes implementam os mesmos métodos ficando assim:

class Post
  # Mesmo conteúdo
end

class AwesomePost
  # Mesmo conteúdo
end

Agora imagine que tenhamos um decorator responsável por gerar um HTML para a exibição destas classes Posts sua implementação seria algo como:

class PostDecorator

  def initialize(post)
    @post = post
  end

  def show
    %Q{<h1>#{@post.title}</h1>
       <div id="content">#{@post.content}</div>}
  end
end

E como já foi dito anteriormente que não fazemos checagem de tipos, seria aceito ambas as classes veja abaixo:

post = Post.new("A new post", "content")
awesome_post = AwesomePost.new("A new awesome post", "Awesome content")

p PostDecorator.new(post).show # "<h1>A new post</h1>\n       <div id=\"content\">content</div>"

p PostDecorator.new(awesome_post).show # "<h1>The awesome post: A new awesome post</h1>\n       <div id=\"content\">The awesome content: Awesome content</div>"

E assim utilizamos o poder do Duck Typing, afinal:

When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.

Fazendo isso observamos a verdadeira diminuição de código de que se houve falar ao comparar linguagens estáticas com dinâmicas, e isto não está na remoção de int, string etc. na declaração de variáveis e sim na não declaração de classes abstratas e interfaces que nunca escreveremos.

Sério, não tenha medo do Duck Typing

As vezes podemos encontrar código que tenta forçar uma tipagem estática, algo como assim:

def initialize(title, content)
  raise "title isn't a string" unless title.kind_of?(String)
  raise "content isn't a string" unless content.kind_of?(String)
  @title = title
  @content = content
end

Por favor não faça isso. Pois assim só estará perdendo:

Destrói o baixo acoplamento da tipagem dinâmica
Aumenta bastante o código, no entanto melhora um pouco apenas a garantia de que vai funcionar.

Como pode ver utilizando o ruby como a linguagem dinâmica que ela é, diminuímos bastante a complexidade de nossos códigos.

Mas como garantimos que tudo simplesmente funcione

Até agora vimos que não precisamos declarar tipo, mas e se por um acaso eu passar um tipo inválido para um método? Então temos as seguintes dicas para lidar com isso.

Utilize nome descritivos

Abaixo criamos um método tags que recebe “n”, pode ser claro para alguns que ele retorne as tags de um post limitando pela quantidade declarada em “n”.

def tags(n)
...
end

No entanto podemos fazer melhor:

def tags(total_of_tags)
...
end

Como pode ver agora ficou mais fácil de saber que o valor é um inteiro. A dica é escreva nomes para serem lidos por humanos.

Como eu sei qual tipo(s) o parâmetro de um método espera

Além da dica de nome descritivo, que já ajuda bastante. Escreva testes automatizados, com testes saberá exatamente quais tipos de objetos são aceitos por um método ou não.

Conclusão

Não crie mas complexidade do que precisa
aproveite o que a linguagem dinâmica tem para oferecer
abrace o Duck Typing
lembre-se que as classes não precisam de herança para compartilharem a mesma interface, só precisam implementar os mesmos métodos
não faça checagem de tipos sem sentido, lembre-se abrace o Duck Typing
Escreva código para humanos

Este post foi baseado no Cap. 8 do livro Eloquent Ruby, espero escrever mais alguns posts baseado em conteúdo do livro, recomendo fortemente a compra do mesmo.

A notação de porcento em Ruby

2013-03-06T00:00:00+00:00

No Ruby temos a notação de % que veio inspirada do Perl. Além do % podemos usar um caractere modificador que muda o comportamento do nosso %. Vamos ver como cada um destes funcionam.

%

Ao utilizarmos a sintaxe % temos o mesmo resultado do uso de aspas duplas, no entanto não temos a necessidade de escapar nenhuma aspas, seja simples ou duplas.

blog = "Groselhas"
p %{O #{blog} é o blog do Mauro} # => "O Groselhas é o blog do Mauro"

%q

Ao utilizarmos a sintaxe %q temos o mesmo resultado do uso de aspas simples, no entanto não temos a necessidade de escapar nenhuma aspas, seja simples ou duplas.

blog = "Groselhas"
p %q{O #{blog} é o blog do Mauro} # => "O \#{blog} é o blog do Mauro"

%Q

Utilizamos o %Q obtemos o mesmo resultado do uso de aspas duplas, assim como o %, ou seja % e %Q possuem o mesmo comportamento.

blog = "Groselhas"
p %Q{O #{blog} é o blog do Mauro} # => "O Groselhas é o blog do Mauro"

%w

Utilizamos o %w para a criação de arrays de strings, e como o %q ele não faz interpolação de strings.

blog = "Groselhas"
p %w{#{blog} Mauro Blog} # => ["\#{blog}", "Mauro", "Blog"]

%W

Com o uso do %W criamos um array de strings, e assim como o %Q podemos fazer interpolação de strings

blog = "Groselhas"
p %W{#{blog} Mauro Blog} # => ["Groselhas", "Mauro", "Blog"]

%i

Recentemente adicionado no Ruby 2.0, o %i é usado para gerarmos um array de symbols, e como você já deve esperar ele não faz interpolação de strings.

blog = "Groselhas"
p %i{#{blog} item} # => [:"\#{blog}", :item]

%I

O %I possui quase o mesmo comportamento do %i, no entanto ele faz interpolação de strings. Também adicionado no Ruby 2.0.

blog = "Groselhas"
p %I{#{blog} item} # => [:Groselhas, :item]

%r

Com o %r podemos criar uma expressão regular, e também podemos fazer interpolação de strings

blog = "Groselhas"
p %r{#{blog}.*Mauro} # => /Groselhas.*Mauro/

%s

Utilizamos o %s para a criação de um symbol, e não conseguimos fazer interpolação de strings.

blog = "Groselhas"
p %s{#{blog} item} # => :"\#{blog} item"

%x

Usamos o %x para executar comandos do sistema operacional, e ainda conseguimos fazer interpolação de strings.

option = "-l"
p %x{ls #{option}} # => total 88\n-rw-r--r--   1 mauro...

Trocando o delimitador

Em todos os nossos exemplos usamos o { para iniciar e o } para finalizar nosso comando, no entanto podemos usar qualquer um caractere que possua o seu par como os parêntesis(( e )) e o colchete([ e ]). Caso utilizemos o mesmo delimitador não é necessário escapar desde que se use o de abertura e fechamento. Também é possivel utilizar 2 caracteres iguais como delimitadores. Veja um exemplo

blog = "Groselhas"
p %Q{O #{blog} {blog do Mauro}} # => "O Groselhas {blog do Mauro}"
p %Q(O #{blog} { blog do Mauro) # => "O Groselhas { blog do Mauro"
p %Q$O #{blog} {blog do Mauro}$ # => "O Groselhas {blog do Mauro}"

Como pode ver ao trocarmos o delimitador podemos usar o { e o } livremente em nosso código.

Do PHP para o Ruby o que mudou no meu modo de desenvolver

2013-02-27T00:00:00+00:00

Este post não é uma comparação de linguagens para saber qual é a melhor, afinal linguagens são só ferramentas. Hoje estou no Ruby quem sabe amanhã não seja no Closure, Scala ou qualquer outra. O objetivo aqui é dizer o que mudou no meu modo de desenvolver depois de mais de 1 ano trabalhando com Ruby.

Controle de versão

Onde eu trabalhava era muito complicado convencer que o Git era uma boa ferramenta, apesar de eu usar sozinho, mas convencer a equipe toda a usar era complicado, era questionado ainda o por que de não usar o SVN, sim em 2011.

Na HE:labs utilizamos o Git, todos do time, inclusive os designers, não sendo problema para ninguém do time o seu uso.

Testes

Trabalhando com PHP tive poucas oportunidades de fazer testes, era o usual vai demorar mais etc. O Pouco que eu fiz, foi bem pouco mesmo em projetos de clientes e fico triste em conversando com o pessoal da comunidade que esta é a realidade. E no BoletoPHP onde estava fazendo testes, migrando a aplicação do procedural para uma orientada a objetos.

No Ruby a comunidade é mais madura em relação a isso, toda Gem(lib) só é considerada completa se possui testes, afinal você não quer instalar uma dependência em seu sistema que pode estar funcionando. E no trabalho todos os nossos projetos na HE:labs possuem testes e outra 100% testados, não vai nenhum código para produção que não possui 100% de cobertura de testes.

Se você não possui 100% de coverage em seus testes deixo apenas este vídeo aqui do Uncle Bob.

Integração e deploy continuo

Trabalhando com PHP para colocar um projeto em produção/staging era através de FTP, consegui mudar um pouco isso inserindo um simples hook no Git para fazer o deploy. Mas podia ser melhor.

Hoje em dia utilizamos o Integration que envia o nosso código para o ambiente de staging, e produção quando necessário, no entanto antes de enviar qualquer código entre outras coisas é rodada todas as specs, e verificado se está com 100% de coverage, caso não esteja com 100% de coverage o código não é enviado. Garantindo assim apenas que código que esteja funcionando seja integrado ao projeto.

Técnicas de orientação a objetos

No PHP, as ferramentas mais populares infelizmente são procedurais, e acredito que continuaram assim por muito tempo, entre elas digo o WordPress e o Drupal, fazem muito bem o seu papel, mas não são nenhum exemplo de engenharia de software. Os frameworks por outro lado, possuem um código orientado a objetos e com testes como o Zend Framework e o CakePHP no entanto via muito as pessoas presas ao MVC que o framework oferecia e só.

Em Ruby como temos nosso código 100% testado, não ficamos apenas no MVC e no Fat Models Skiny Controllers, preferimos o Skiny Models e Controllers e uma camada de serviço. Esta camada de serviço, além de services, temos outras classes como Decorators, FormObjets etc separados logicamente claro.

Refactories KISS, DRY e YAGNI

Trabalhando com PHP se uma coisa estava “pronta” ela estava “pronta”, pois como não possuía testes não me sentia confortável em refatorar algo já que teria que testar toda a interação pelo browser o que com certeza teria falhas.

Em Ruby tenho total confiança para fazer um refactory, pois se algo quebrar o meu teste irá avisar. E assim consigo aplicar técnicas de KISS quebrando métodos maiores em menores ou classes grandes em mais de uma classe dividindo a responsábilidade, DRY se eu tenho repetição refatoro até não à ter e YAGNI desenvolvendo para a interface e não criando métodos que posso precisar, desenvolvo utilizando TDD para a minha interface.

Agile no mundo real

Trabalhando com PHP nunca trabalhei com agile, era sempre escopo fechado.

Atualmente trabalho com agile, mas especificamente com XP. Temos iterações semanais, contrato de escopo variável, testes automatizados e diversas outras práticas do XP.

Como pode ver considero que evolui bastante migrando do PHP para o Ruby. E com certeza não foi apenas a mudança de linguagem mais sim a mudança para a HE:labs onde temos um time foda! E você tem evoluído bastante? Comenta aí.

Delegação em Ruby utilzando o módulo Forwardable

2013-02-21T00:00:00+00:00

Em Ruby temos o poder de fazer overloading de operadores, ou seja definirmos nossa própria implementação para os operadores.

Quando temos uma classe que é uma coleção é uma boa idéia, se fizer sentido, definirmos os operadores <<, [] e []= pois assim teremos uma interface igual a de um Enumerable. Tecnicamente os operadores [] e []= não são operadores e sim métodos, em que o Ruby aplica um açucar sintático assim quando fazemos foo[2] estamos chamando o método [] em foo, passando o parâmetro 2 e quando fazemos foo[2] = 4 estamos na realidade chamando o método []= em foo passando os parâmetros 2 e 4, por isso conseguimos fazer overloading destes métodos também.

Vamos a um exemplo:

class Basket

  def initialize
    @items = []
  end

  def total_of_items
    @items.size
  end

  def <<(item)
    @items << item
  end

  def [](index)
    @items[index]
  end

  def []=(index, item)
    @items[index] = item
  end
end

criamos uma classe Basket que é nossa cesta, seu papel é ser uma coleção de items, vamos vê-la em ação:

basket = Basket.new
basket << "Morango"
basket << "Manga"
basket << "Banana"
basket[3] = "Pera"
p basket[0] # => "Morango"
p basket[3] # => "Pera"
p basket.total_of_items # => 4

Como pode ver agora nossa classe se comporta como um Enumerable no entanto se observar bem os métodos que implementamos, nada mais são do que delegar para os métodos do Enumerable, vamos a uma implementação mais inteligente.

Utilizando o Forwardable

O Ruby possui o módulo Forwardable que nos permite delegar métodos específicos para um objeto. Ou seja poderemos delegar os métodos de array, para o nosso próprio array @items. Vamos ao código:

require 'forwardable'

class Basket
  extend Forwardable

  def initialize
    @items = []
  end

  def_delegator :@items, :size, :total_of_items
  def_delegators :@items, :<<, :[], :[]=
end

Ao utilizarmos a nossa nova classe Basket obtemos o mesmo resultado da classe anterior:

basket = Basket.new
basket << "Morango"
basket << "Manga"
basket << "Banana"
basket[3] = "Pera"
p basket[0] # => "Morango"
p basket[3] # => "Pera"
p basket.total_of_items # => 4

Vamos agora entender o que aconteceu.

def_delegator

Primeiro utilizamos o def_delegator que nos permite definir um delegator, para um único método do objeto e opcionalmente definir um nome diferente ao método. No nosso exemplo usamos o Basket#total_of_items pois para a nossa interface faz mais sentido este nome do que apenas Basket#size.

def_delegators

Como você já deve imaginar o def_delegators nos permite definir diversos delegators, para diversos métodos do objeto, no entanto não é possível definir um nome diferente ao método. Utilizamos ele para criar os demais métodos <<, [] e []=.

Como pode ver o uso do Forwardable fez nossa classe mais enxuta e não precisamos redefinir os métodos já existentes em nosso objeto. Lembrando que pode-se definir qualquer método de um dado objeto, cabe a você fazer as escolhas certas para manter uma interface clara.

Somando valores de um array em ruby de uma forma mais elegante utilizando inject

2013-02-16T00:00:00+00:00

Imagine que tenhamos que somar os valores de um array, provavelmente seguiríamos para uma abordagem neste sentido:

values = [1, 2, 3, 5, 8]

total = 0
values.each do |value|
  total += value
end

puts total # => 19

No entanto o ruby possui o Enumerable#inject. Poderiamos trocar o nosso exemplo para algo como:

values = [1, 2, 3, 5, 8]

puts values.inject(:+) # => 19

uma versão bem mais simples e elegante do que o primeiro exemplo. O inject ainda nos dá a possibilidade de definirmos um valor para iniciarmos o somatório.

values = [1, 2, 3, 5, 8]

puts values.inject(10, :+) # => 29

Perceba que agora iniciamos a contagem em 10 e adicionamos os demais valores.

Por padrão o valor que é iniciado no inject é nil, sendo assim se passarmos um array vázio o nosso retorno será nil e não 0, que pode ser o esperado:

values = []

puts values.inject(:+) # => nil

Como vimos que podemos definir o valor inicial, podemos definir como 0 e assim conseguir o resultado que esperamos.

values = []

puts values.inject(0, :+) # => 0

Para quem estiver utilizando o rails, o ActiveSupport adiciona no Enumerable o método sum que pode ser utilizado assim:

values = [1, 2, 3, 5, 8]

puts values.sum # => 19

No nosso exemplo utilizamos o array values criado manualmente, mas poderia muito bem ser um array criado a partir do uso do pluck do ActiveRecord por exemplo.

Buscar um ou mais objetos em um array de objetos em Ruby

2013-02-16T00:00:00+00:00

Como fariamos para conseguir pegar um objeto de um array de objetos baseado em uma propriedade do objeto?

Vamos ao seguinte cenário, dado que tenhamos o seguinte array de OpenStructs, utilizamos OpenStruct pela facilidade mas poderia ser qualquer objeto ou mesmo um Hash.

require 'ostruct'

games = [
  OpenStruct.new(
    id: 53,
    name: "Gears of War",
    gender: "action"
  ),
  OpenStruct.new(
    id: 54,
    name: "Uncharted",
    gender: "action"
  )
]

Se quisessemos apenas o objeto com o id 53, poderiamos usar o Enumerable#select que nos retornaria:

puts games.select { |g| g.id == 53 } # => [#<OpenStruct id=53, name="Gears of War", gender="action">]

como pode ver o select nos retorna uma coleção, sendo assim ele retorna todos os objetos que satisfazerem a condição passada ao bloco, veja o exemplo a seguir:

puts games.select { |g| g.gender == 'action' } # => [#<OpenStruct id=53, name="Gears of War", gender="action">, #<OpenStruct id=54, name="Uncharted", gender="action">]

Como temos 2 objetos com o gender igual a action ele retornou os 2. Caso queiramos apenas o primeiro objeto que satisfazer a condição, o que faz sentido no caso de uma busca por id por exemplo, podemos utilizar o Enumerable#detect veja:

puts games.detect { |g| g.id == 53 } # => #<OpenStruct id=53, name="Gears of War", gender="action">

Então fica a dica precisando buscar em uma coleção, uma coleção de objetos que satisfaçam uma certa condição utilizar o select, precisando retornar um único valor que satisfaça a condição utilizar o detect.

Prefira composição ao invés de herança, um simples exemplo em Ruby

2013-02-15T00:00:00+00:00

Um dos princípios da orientação a objetos é:

Prefira composição de objetos à herança de classes

como é descrito no livro Design Patterns: Elements of Reusable Object-Oriented Software da GoF. Vamos agora ver um exemplo prático em ruby de como podemos usar composição ao invés de herança.

O problema

Nossas classes representam um carro e os componentes que podem ser adicionados ao carro, os componentes são alarme e ar-condicionado, e o que precisamos saber ao final é o preço do carro.

Usando herança

Seguindo uma implementação baseada em herança teríamos algo assim:

class Car

  def price
    1.00
  end
end

class CarWithAlarm < Car

  def price
    super + 0.20
  end
end


class CarWithAirConditioning < Car

  def price
    super + 0.30
  end
end

class CarWithAlarmAndAirConditioning < Car

  def price
    super + 0.50
  end
end

Nossas classes são bem simples e usadas assim:

puts Car.new.price # => 1.0
puts CarWithAlarm.new.price # => 1.2
puts CarWithAirConditioning.new.price  # => 1.3
puts CarWithAlarmAndAirConditioning.new.price  # => 1.5

Os 2 primeiros casos (CarWithAlarm e CarWithAirConditioning) funcionam muito bem, já o terceiro caso CarWithAlarmAndAirConditioning temos os seguintes problemas:

repetição - pois pegamos o valor adicionado de CarWithAlarm e CarWithAirConditioning e somamos para chegar ao preço de CarWithAlarmAndAirConditioning
dificil de manter - pois se o valor de CarWithAlarm mudar teremos que lembrar de alterar em CarWithAlarmAndAirConditioning
dificil de estender - imagine se tivermos mais um componente, Radio, teremos que criar:
- CarWithRadio
- CarWithRadioAndAlarm
- CarWithRadioAndAirConditioning
- CarWithRadioAlarmAndAirConditioning

deu para perceber que estamos fazendo errado né? Vamos agora ao exemplo usando composição.

Usando composição

Primeiro criamos a nossa classe Car:

class Car

  def initialize
    @price = 1.00
    @components = []
  end

  def add_component(component)
    @components << component
  end

  def price
    @components.map(&:price).inject(@price, :+)
  end
end

Vamos analisar a nossa classe.

Initialize

Criamos 2 váriaveis de instância:

@price que é o preço do nosso carro
@components um array para armazenar os componentes de nosso carro

add_component

Método que adiciona um componente ao nosso carro.

price

Retorna o preço total do carro

Tendo nossa classe Car criada vamos as classes de componentes:

class Alarm

  def price
    0.20
  end
end

class AirConditioning

  def price
    0.30
  end
end

Agora com nossas classes de componentes criadas, vamos a um exemplo de como podemos usar a nossa classe Car, agora utilizando de composição.

car = Car.new
car.add_component(Alarm.new)
puts car.price # => 1.2

Como pode ver obtivemos o mesmo resultado que tinhamos com a classe CarWithAlarm, agora se precisarmos ter o mesmo resultado de CarWithAlarmAndAirConditioning fariamos:

car = Car.new
car.add_component(Alarm.new)
car.add_component(AirConditioning.new)
puts car.price # => 1.5

como podemos ver com composição obtivemos um código bem mais fácil de se manter, estender e sem repetições.

Usámos o carro e seus componentes, mas poderia ser a modelagem de uma transação bancária que possui diversas taxas diferentes por exemplo.

Usando o SimpleDelegator para criar decorators em Ruby

2013-02-13T00:00:00+00:00

Recentemente postei no blog da HE:labs sobre como extrair responsabilidade de models no rails utilizando-se de decorators para quem curtiu e já está utilizando decorators em suas apps apresento agora o SimpleDelegator que nos ajuda a criar nossos decorators.

Imagine que tenhamos a seguinte classe:

class Saiyajin
  attr_accessor :name

  def initialize(name)
    self.name  = name
  end
end

uma simples classe ruby, mas que poderia ser um de seus models active record por exemplo.

A nossa classe é utilizada assim:

goku = Saiyajin.new("Goku")
puts goku.name # => "Goku"

Agora iremos criar o Super Sayajin, vamos a nossa classe:

require 'delegate'

class SuperSaiyajin < SimpleDelegator

  def name
    "#{super} super saiyajin"
  end

  def power
    "It's Over 9000!"
  end
end

a nossa classe Super Sayajin poderia ser utilizada assim:

goku = SuperSaiyajin.new(goku)
puts goku.name # => "Goku super saiyajin"
puts goku.power # => "It's Over 9000!"

Criando o nosso decorator herdando de SimpleDelegator não precisamos criar um initialize e agora o nosso decorator responde a todos os métodos da classe “decorada”. Perceba que podemos utilizar o super para nos referenciarmos a métodos da classe “decorada”, como usamos em SuperSaiyajin#name.

Fica a dica do SimpleDelegator para quando formos criar nossos decorators. Se você não conhecia o SimpleDelegator ou usa outra abordagem comenta aí.

JavaScript - string multilinha

2012-08-31T00:00:00+00:00

Ao tentarmos escrever uma string multilinha em JavaScript do seguinte modo:

string = "MY
awesome
string";

recebemos o seguinte erro:

SyntaxError: unterminated string literal

Para “resolver” podemos concatenar a string fazendo assim:

string = "My "
       + "awesome "
       + "string";

que até funciona, mais não seria a melhor abordagem.

No entanto podemos usar a seguinte sintaxe, para enfim escrevermos strings multilinhas no JavaScript:

string = "MY \
awesome \
string";

Está última abordagem funciona tanto com aspas simples como duplas.

VCR e dados sensíveis como email e senha

2012-08-30T00:00:00+00:00

Quando estamos utilizando o VCR em nossas specs podemos nos deparar com o seguinte problema: como passar dados sensíveis ao VCR, como senhas e emails, mais não salvar isto em nosso cassete?

Vamos usar um exemplo real. Ao utilizarmos a api do moip de pagamento transparente temos que fazer um POST em uma uri

https://MOIP_TOKEN:MOIP_KEY@desenvolvedor.moip.com.br/sandbox/ws/alpha/EnviarInstrucao/Unica

utilizando Basic Authentication. Em um projeto interno, sem problemas deixar o seu dado de user e password nas specs, afinal o projeto é seu. Já em um projeto open source não seria legal todos terem acesso ao mesmo ambiente de desenvolvimento que você.

Para resolver isto devemos criar uma configuração no VCR, para isto em spec/support crie um arquivo com o nome de vcr.rb e nele devemos definir além do padrão do vcr que já usamos o:

VCR.configure do |c|
  c.filter_sensitive_data('<MOIP_KEY>') { "my_key" }
  c.filter_sensitive_data('<MOIP_TOKEN>') { "my_token" }
end

Agora em todos os cassetes que o VCR gerá teremos algo assim:

https://<MOIP_TOKEN>:<MOIP_KEY>@desenvolvedor.moip.com.br/sandbox/ws/alpha/EnviarInstrucao/Unica.

No entanto ainda não está bom, afinal apenas movemos os dados sensíveis de um lugar para o outro. Para resolvermos de verdade isto podemos usar variaveis de ambiente, assim a única coisa que tem que fazer é definir as variáveis de ambiente em seu sistema e na configuração do VCR mudar para

VCR.configure do |c|
  c.filter_sensitive_data('<MOIP_KEY>') { ENV["MOIP_KEY"] }
  c.filter_sensitive_data('<MOIP_TOKEN>') { ENV["MOIP_TOKEN"] }
end

Pronto! Agora temos um modo de distribuir uma gem, com as specs funcionando, e sem a necessidade de deixarmos hard coded nossas informações.

Para quem utilza o rvm e seu arquivo .rvmrc, pode definir no .rvmrc as váriaveis de ambiente, assim elas serão carregadas apenas quando estiver dentro do diretório do projeto.

export MOIP_KEY="my_key"
export MOIP_TOKEN="my_token"

Não se esqueça de sair e entrar no diretório novamente caso tenha acabado de definir as variáveis de ambiente e de documentar a sua gem para quem for testar definir as váriaveis de ambiente.

Conheça o pluck do ActiveRecord

2012-08-13T00:00:00+00:00

No rails, quando precisamos selecionar apenas o valor de uma coluna especifica de uma coleção de um objeto ActiveRecord podemos fazer algo como:

Post.map(&:name)

e obtemos a resposta algo como:

[
    [0] "Foo",
    [1] "Bar",
]

no entanto a partir do rails 3.2 podemos usar o método pluck do ActiveRecord. Ficando o nosso exemplo anterior com o pluck assim:

Post.pluck(:name)

Aparentemente não tem diferenças, afinal ambos ocupam apenas uma linha. No entanto ao utilizarmos o primeiro método estamos instanciando N objetos ActiveRecord e com o map obtendo o valor de cada um deles e retornando um array. Já no exemplo que usa o pluck não precisamos instanciar N objetos ActiveRecord, obtemos o array diretamente.

Por isso prefira sempre usar o pluck, afinal é nativo do ActiveRecord e ainda tem uma performance melhor do que a solução com o map.

Views mais limpas ao usar I18n

2012-08-10T00:00:00+00:00

Melhorando as views com o I18n

Quando estamos trabalhando com I18n no rails as vezes podemos nos deparar com algo como o código a seguir em nossas views:

t 'posts.index.title'

veja que temos que passar por várias sessões do yml para chegarmos ao título que queremos exibir.

Agora imagine que tenhamos em nossa pasta de views a seguinte estrutura:

posts
  - index.html.haml

e em nosso yml

pt-BR:
  posts:
    index:
      title: Meu título

podemos usar em nossa view (views/posts/index.html.haml) apenas:

t '.title'

isso funciona desde que mantenhamos a convenção no yml, de manter as sessões do yml a mesma da estrutura de pastas das views.

Removendo o .html_safe das views

Caso algum dos seus arquivos de tradução possua alguma tag html, você já deve ter encontrado algo assim nas views:

t('.title').html_safe

este último para dar escape das tags html.

No entanto isto poderia ser feito no yml como a seguir.

pt-BR:
  posts:
    index:
      title_html: Meu <strong>título</strong>

definindo o sufixo _html no yml você não precisa mais usar o html_safe podendo fazer apenas.

t '.title'

Whitespace TextMate Bundle - removendo espaços em branco indesejáveis

2012-08-07T00:00:00+00:00

É chato ter espaços em branco após suas declarações de código, piora ainda para quem é da sua equipe e quando da um git pull recebe seu código com uns espaços em branco sem sentido. Quem usa o textmate pode usar o Whitespace TextMate Bundle é um bundle bem simples, mas muito útil, a única coisa que ele faz é: antes de salvar o seu artigo ele remove qualquer espaço em branco desnecessário.

Para instalar apenas execute os seguintes comandos abaixo no terminal:

$ mkdir -p ~/Library/Application\ Support/TextMate/Pristine\ Copy/Bundles/
$ cd ~/Library/Application\ Support/TextMate/Pristine\ Copy/Bundles/
$ git clone git://github.com/vigetlabs/whitespace-tmbundle.git Whitespace.tmbundle
$ osascript -e 'tell app "TextMate" to reload bundles'

Verifique se o bundle foi instalado corretamente acessando no textmate Bundles e na listagem procure por Whitespace. Caso o bundle não apareça na lista faça Bundles > Bundle Editor > Reload Bundles.

E é isso, agora sempre ao salvar um arquivo, este terá seus espaços em branco removidos.

PHP HackDay

2012-03-06T00:00:00+00:00

Dia 03/03/2012 ocorreu na Íparos o PHP HackDay organizado pelo pessoal do php rio.

Pela manhã

Por volta das 9:30 da manhã já tínhamos um pessoal presente no evento. Ficou por conta do Raphael explicar pro pessoal a proposta do evento.

PHPT

Após a introdução do Raphael sobre o evento, ficou por conta do Raphael e do Alganet um mão na massa sobre como escrever testes para o PHP utilizando o PHPT. Vimos um pouco sobre como baixar o package do php, para depois rodarmos os testes, além disso vimos a sintaxe, e o processo de como rodar os testes com o PHPT. Pensamos em desenvolver alguns testes para a biblioteca DOM do PHP, no entanto acabamos ficando apenas com os exemplos, afinal tínhamos bastante coisas para o dia.

XPath

Como estávamos pensando em desenvolver testes para a biblioteca DOM precisava a galera toda ter uma noção sobre XPath. Alganet foi “intimado” a dar um mão na massa. Vimos alguns exemplos de seletores utilizando o XPath, recriamos alguns seletores de CSS em XPath e vimos alguns seletores XPath que só seriam possíveis com o XPath.

Git

Depois do Alganet, foi a vez deste que vos escreve. O Raphael me perguntou se eu queria apresentar a palestra, pensei que não seria tão interessante para o pessoal que estava presente, mais fui convencido, devido a galera já utilizar o git no dia a dia. Apresentei a palestra passando por alguns pontos bem rapidamente e fiquei o restante do tempo tirando dúvidas do pessoal. Se assistiu a palestra comenta ae se gostou.

O almoço

No almoço estamos em dúvida entre pedir pizza para continuarmos na sala ou irmos a algum lugar, depois de todos votarem e escolhermos o sabor das pizzas para entrega, resolvemos ir comer no Vulcão das massas, onde fomos em um rodízio de massas. Onde possuía a melhor pizza de banana do Rio de Janeiro de acordo com o garçom, lembrando que eles só tinham 2 sabores de pizza, mussarela e banana, mais eles tinham mais massas também, graças a Vivi e seus poderes de persuasão eles fizeram mais um sabor de pizza o de calabresa.

A tarde

Voltando do almoço, chegamos um pouco mais cedo que o André, assim não podiamos entrar na íparos. Mais o pessoal não desanimou e continuamos as conversas do almoço na frente da íparos até o retorno do André.

Xdebug

Para continuar o evento depois do almoço foi a vez do Vitor iniciar com uma palestra/mão na massa sobre Xdebug. Onde ele mostrou como instalar e configurar, em diversas IDEs inclusive, e como utilizar o Xdebug para o debug em si e para fazer o profiling de aplicações.

Arquitetura de Aplicações Web Modernas

Logo em seguida foi a vez do Alganet, em que em sua palestra falou sobre arquitetura de aplicações web e como podemos manter um equilíbrio em nossa arquitetura para conseguirmos manutenção, performance, escalabilidade etc. Falou também sobre aranhas e carrapatos =)

Técnicas para ser escalável com PHP

Finalizando as palestras, foi a vez do Filipe em que apresentou algumas técnicas para escalar um site com PHP, falando bastante sobre cache, filas e arquitetura.

Papo de corredor

Finalizada as palestras fizemos uma pausa. Foi o momento em que diversos núcleos foram se montando organicamente e em que cada um falava sobre o que quisesse, tudo acontecendo naturalmente. No que eu estava, estávamos conversando sobre REST e Hypermedia, discutindo sobre o que era o que não era Rest as vantagens de Hypermidia etc.

Boleto PHP

Agora era a vez do Israel nos apresentar o Boleto PHP, no qual é mantenedor, conhecer o projeto todos devem conhecer mais ele nos mostrou mais os internals e a história do projeto até o momento. Decidimos também em dar um gás no projeto, que seria desde refatorar o código, arrumar o site entre outras coisas. O código do projeto pode ser encontrado no github. O André também sugeriu de ser uma coisa constante a contribuição de um projeto open source acontecer lá na íparos, iniciando este mês, por isso aconpanhe a lista de discussões do PHP Rio e o twitter do André para saber mais sobre isto.

Sorteio e finalização do evento

Para finalizar o evento foram sorteados 2 livros, um para os presentes e um para os palestrantes, cedidos pela novatec. Uns mousepads cedidos pelo Alganet em nome do Yahoo! e uma garrafa térmica da microsoft que não sei quem cedeu.

O Filipe ganhou o livro Scrum em Ação e eu ganhei o livro Expressões Regulares - Uma abordagem divertida 3ª edição. Como o Filipe queria mais o livro que ganhei e eu queria mais o que ele ganhou trocamos, pois eu já possuía o de expressões regulares. Ganhei um mousepad de “caridade” também =)

O Raphael também distribuiu camisas do PHP n’rio 11, eu ganhei uma, ele falou que foi distribuído no evento ano passado, eu devo ter saído um pouco antes do fim pois não tinha a camisa.

E assim acabou o PHP HackDay que ocorreu em 03/03/2012 na íparos.

PHPinga

Finalizado o evento, uns foram embora, eu fui um desses, e o pessoal partiu para o PHPinga. Infelizmente não tenho muito o que dizer pois não fui =)

Palestras

Abaixo as palestras que encontrei que aconteceu no evento, se tiver mais pode mandar que eu incluo.

Git para iniciantes

Git para iniciantes

View more presentations from maurogeorge

Arquitetura de Aplicações Web Modernas

Técnicas para ser escalável com PHP

Técnicas para ser escalável com PHP

View more presentations from Filipe La Ruina

Vídeo

O André tentou fazer o streaming mais não ficou legal o som, ta ae o link do vídeo, acho que ele deletou os demais vídeos só achei este.

Agradecimentos

Acho legal agradecer aqui a Íparos e ao André pelo espaço e novatec pelos livros cedidos, ao Alganet por ter vindo de São Paulo, sem patrócinio do evento para palestrar e a todos os que estavam presentes no evento.

Para refletir um pouco

Não entendo o pessoal que trabalha com tecnologia e não aparece nos eventos por algum motivo bobo ou desculpa ou apenas aparece apenas nos eventos “grandes”. Acredito que se você trabalha com tecnologia ou qualquer outra coisa, mais não curte, deveria rever sua vida em relação a isto. Deixo um trecho de um comentário meu no blog do dojo rio em que fui icentivado pelo Henrique Bastos no primeiro evento de tecnologia que eu fui:

Resumindo depois de ter me alongado muito, valeu mais a pena ver uma palestra “humana” para 30 pessoas do que uma para mais de 200 em que provavelmente o conteúdo se perderia e seria muito superficial. Então é isso quem quiser se juntar ao grupo vale muito a pena devido a amizade e de aprender todos juntos, e se morar longe tenta aparecer pelo menos nos que ocorrem de dia, afinal para eu chegar a casa do Bernardo tive que acordar 6:20, começava as 9:00, e pegar 3 ônibus, mais valeu a pena.

Para ler o comentário completo pode acessar o link http://dojorio.org/2010/04/10/forkinrio2/#comment-148.

Deixo aqui a proposta de que se foi o primeiro evento que foi ou se de algum modo foi importante para você, escreva um post num blog, pode colar o link aqui nos comentário, ou simplesmente comente aqui.

Grande abraço pessoal!

Testando no Internet explorer 6, 7, 8 e 9 no Mac Os e Linux utilizando máquinas virtuais

2012-02-11T00:00:00+00:00

A Microsft disponibiliza vários VHDs com Windows para os desenvolvedores poderem testar suas aplicações nos internet explorer’s 6, 7, 8 e 9 no entanto estes VHDs foram feitos para ser usado no Microsoft’s VirtualPC e fazer ele funcionar fora deste ambiente pode ser bastante irritante. No entanto para facilitar a nossa vida Greg Thornton criou um script shell que resolve tudo para nós.

Requisitos

VirtualBox
Curl (Ubuntu: sudo apt-get install curl)
No Linux apenas: unar (Ubuntu: sudo apt-get install unar)
Paciência

Instalação

Instalar o VirtualBox
Baixar e descompactar o as maquinas virtuais
- Instala o IE versões 6, 7, 8 e 9. $ curl -s https://raw.github.com/xdissent/ievms/master/ievms.sh | bash
- Instala versões especificas do IE (IE7 e IE9 por exemplo): $ curl -s https://raw.github.com/xdissent/ievms/master/ievms.sh | IEVMS_VERSIONS=”7 9” bash
Inicie a máquina virtual
Acesse a máquina virtual da versão do internet explorer que quiser utilizar

A instalação pode demorar muito dependendo de sua conexão, tenha isto em mente.

Uma vez instalada a senha de cada uma das máquinas virtuais é “Password1”.

Mais informações podem ser encontradas na página do ievms no github.

Instalando o PostgreSQL no Mac OS com o homebrew

2011-12-31T00:00:00+00:00

Para o pessoal que usa Mac deve conhecer o gerenciador de pacotes Homebrew, caso não conheça acesse o post do Pedro Menezes sobre o assunto e instale o Homebrew.

Tendo devidamente o homebrew instalado, execute o seguinte comando:

$ brew update

para atualizar o homebrew e suas formulas.

Instalando o PostgreSQL

Apenas execute o seguinte comando

$ brew install postgresql

e aguarde o homebrew fazer todo o processo de instalação para você. Depois de instalado ainda temos algumas pequenas coisas para fazer.

Caveats

Depois de instalado o PostgreSQL o homebrew nos informa sobre as ressalvas, ou caveats em inglês, recomendo a leitura do mesmo para seu conhecimento. Nestas ressalvas ele nos informa alguns passos que devemos seguir.

Iniciando o banco de dados

Depois de instalado o PostgreSQL devemos iniciar o banco de dados com o simples comando:

$ initdb /usr/local/var/postgres

apenas aguarde a execução do comando.

Problemas com encoding

Caso apresente algum problema de encoding no template de banco de dados, pode utilizar o comando a seguir para forçar o PostgreSQL a criar o template em UTF-8 por exemplo:

$ initdb /usr/local/var/postgres --locale=en_US.UTF-8 --encoding=UNICODE

mais informações sobre os comandos passados ao initdb no manual do PostregesSQL.

Caso você queira, o que acredito que seja o seu caso, iniciar o PostgreSQL após realizar o login em sua máquina execute o seguinte comando abaixo:

$ mkdir -p ~/Library/LaunchAgents
$ cp /usr/local/Cellar/postgresql/9.1.2/org.postgresql.postgres.plist ~/Library/LaunchAgents/
$ launchctl load -w ~/Library/LaunchAgents/org.postgresql.postgres.plist

Observe que aqui estamos usando o PostgreSQL 9.1.2 sendo assim a sua instalação mudará o path no comando acima dependendo da versão do PostgreSQL, por isso é importante ler as mensagens que o homebrew lhe informar para inserir o comando acima corretamente.

Iniciando e parando o PostgreSQL manualmente

Caso queira iniciar o PostgreSQL manualmente utilize o comando abaixo:

$ pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start

e para parar a execução do PostgreSQL utilize o comando abaixo:

$ pg_ctl -D /usr/local/var/postgres stop -s -m fast

Criando o super usuário postgres

Para criar o super usuário postgres devemos primeiro entrar no psql com

$ psql postgres

caso ele reclame de não existir a database postgres utilize o seguinte comando para criar a mesma, em seguida acesse o psql como indicado acima.

$ createdb postgres

Dentro do psql execute o seguinte comando para criar o super usuário postgres e depois para sair do psql utilize \q.

CREATE USER postgres SUPERUSER;

Assim teremos criado o super usuário postgres sem senha para o PostgreSQL.

Git config - configurando o git

2011-12-09T00:00:00+00:00

Para quem está usando o git diariamente sabe que tem comandos que digitamos freqüentemente como git status, git commit, git checkout entre outros. Iremos ver como digitar menos e mais algumas configurações legais no git.

Git config

É onde você define configurações do git que podem ser globais que serão válidas para todos os seus repositórios ou configurações de um repositório em especifico.

Configurações globais

Para inserir alguma configuração com o git usamos o comando git config e caso queiramos que nossa configuração seja valida para todos os repositórios que criarmos passamos o parâmetro --global ficando git config --global.

Provavelmente você já executou o seguinte comando, passando seus dados obviamente, ao instalar o git:

$ git config --global user.name "Seu nome"
$ git config --global user.email "email@example.com"

caso tenha seguido algum tutorial e não saiba o que esta acontecendo aqui, o que você está fazendo é definir seu nome e email para o git que será usado em todos os seus repositórios.

Configurações por repositório

Se ao passarmos o parâmetro --global definimos a informação para todos os repositórios, ao omitirmos o parâmetro definimos a informação para apenas um de nossos repositórios.

Lembrando de executar o comando estando dentro do diretório onde encontra se o repositório que quer definir as configurações. Exemplo:

$ git config user.email "email@empresa.com"

Assim você pode definir o email para o email de sua empresa por exemplo enquanto nos demais repositórios o email usado seria o seu pessoal.

Lembrando que o git é esperto o suficiente e só sobrescreve o que você redefinir e as demais configurações ele mantém. Ou seja no exemplo anterior ainda teriamos o valor nome definido como “Seu nome” em que definimos usando as configurações globais.

Git alias

Agora que entendemos como definimos as configurações no git, iremos ver como podemos definir alias, um apelido, para os comandos que digitamos freqüentemente. Veja abaixo os alias que costumo definir como global.

$ git config --global alias.co "checkout"
$ git config --global alias.ci "commit"
$ git config --global alias.st "status -sb"
$ git config --global alias.br "branch"
$ git config --global alias.wdiff "diff --word-diff"

Agora com os alias definidos podemos fazer git ci ao invés de git commit quando formos realizar um commit. Além dos demais alias que definimos. Lembrando que você pode definir outros alias que julgar interessante.

Detalhe que defino como global pois quero isto válido em todos os meus repositórios.

Um log bem mais poderoso

Ao executarmos git log obtemos o log de nossos commits. No entanto vem bastante informação e em um formato não muito agradável de se ler. Podemos melhorar o nosso log adicionando o seguinte alias.

$ git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset %Cblue[%an]%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit"

Agora ao executarmos o comando git lg teremos um log com mais informações úteis do que o log padrão, lembrando que ainda poderá usar o git log normalmente. Não se esqueça que podemos ainda usar o git lg -p para vermos o diff do que foi alterado nos commits.

Mais configurações

Editor de texto

Em alguns momentos um editor de texto é chamado pelo git, como ao darmos um commit sem mensagem com o comando git commit. Para escolhermos o nosso editor de preferencia podemos definir a configuração com o comando:

$ git config --global core.editor "mate -wl1"

Usei aqui o comando para chamar o textmate, e como está em seu blog devemos passar o parâmetro -w e o parâmetro adicional l1 que passei é para o cursor se posicionar na primeira linha do arquivo.

Para o pessoal de linux, que não quiser o Vim, poderíamos definir o gedit por exemplo usando o comando:

$ git config --global core.editor "gedit"

Colorindo o terminal

Se ao executar um git status por exemplo e não vermos colorido o que foi alterado, ou os novos arquivo por exemplo. É bom definir a configuração abaixo.

$ git config --global color.ui true

que como você deve imaginar, colore as informações que o git lhe enviar no terminal.

O git te corrigindo ao digitar errado

Em alguns momentos pode acontecer de digitarmos errado como por exemplo digitar git lg ao invés de git log. Para não tomarmos um aviso de comando errado simplesmeste, podemos deixar o git definir por nos o que ele acha que tentamos executar, para isso habilitamos a seguinte configuração:

$ git config --global help.autocorrect 1

Assim ele nos dará um aviso e executará o comando que ele acredita que tentamos digitar.

Evitando tiro de shotgun com o git ao dermos push

Como o Argentino diz o git da um tiro de shotgun ao executarmos o git push, isso por que os commits de outros branches são enviados, mesmo estando em um branch especifico.

Imagine que tenhamos 3 branches master, feature/awesome-thing e feature/other-thing, ambos feature branches tem commits locais que ainda não foram enviados, estando no branch feature/awesome-thing e executar um git push os commits dos 2 feature branches serão enviados, pode não ser o comportamento esperado no momento.

Utilizando o:

$ git config --global push.default current

dizemos para o git que no git push ele deve enviar o conteúdo do branch atual para um branch de mesmo nome. Sendo assim se executassemos o git push no exemplo anterior, apenas o branch feature/awesome-thing seria enviado, o que faz sentido pois é o branch que estamos no momento. Mais informações e outras configurações possiveis podem ser encontradas no manual do git.

Não precisando resolver conflitos já resolvidos

É comum quando estamos em um feature branch que tenha uma vida relativamente longa, fazermos merge do branch master em nosso feature branch. Em algum destes merges talvez tenhamos que resolver algum conflito. O problema ocorre quando formos fazer merge do nosso feature branch no master, pois teremos que resolver os mesmos conflitos. Para resolvermos isto podemos ativar o rerere(Reuse recorded resolution of conflicted merges) com o seguinte comando.

$ git config --global rerere.enabled true

Documentação em HTML

Caso queira que a documentação, ao digitar git help comando seja em HTML pode usar a seguinte configuração:

$ git config --global help.format web

Assim ao digitar por exemplo git help config será aberto o browser e poderá ver a documentação do comando digitado em HTML.

Lembrando que para ver a documentação em HTML a mesma deve ser instalada, mais informações de como instalar aqui.

Listando as configurações

Agora que você já sabe definir configurações tem que ter um lugar onde seja possível ver o que esta configurado, e para isso usamos o comando

$ git config -l

que executado fora de qualquer repositório listará nossas configurações globais. E ao estar dentro de algum repositório, listará as configurações do repositório em especifico.

E se ainda assim dentro do diretório do repositório quiser listar as configurações globais. Podemos usar o comando:

$ git config --global -l

Shell

Caso goste de definir seus alias no shell, pode usar o mesmo para definir comandos do git. No mac utilizaríamos o ~/.bash_profile ou o ~/.bash_profile no linux, exemplo:

alias go='git checkout '
alias gc='git commit'
alias gs='git status '
alias gb='git branch '

Hello World

2011-11-28T00:00:00+00:00

Como está em sobre falei que o conteúdo aqui seria também sobre o que fosse aprendendo. Inclusive o próprio blog surgiu de um aprendizado.

Há algum tempo pensava em criar um blog, exatamente com a mesma proposta do groselhas, no entanto ficava adiando isso devido a estar estudando algo, ocupado com outras coisas etc. Até que conheci o jekyll, e como estou iniciando os estudos em ruby e rails resolvi usar o mesmo, já que é desenvolvido em ruby e também como desculpas para agitar um pouco as coisas aqui no github, já que o meu está bastante parado.

Sendo assim das coisas que nunca havia utilizado e resolvi usar no desenvolvimento do projeto foram:

E outras que já utilizei anteriormente, mais que acho legal mencionar foram o

Quem sabe em breve não falo um pouco sobre cada uma dessas ferramentas.