Como fizemos um projeto que deu 130.000 acessos únicos e 60.000 cadastros na primeira semana

Esse título chama atenção né? Mas felizmente é verdadeiro 😁

Eu e o Anthony Sousa, criamos um projetinho em uma noite e uma semana depois tínhamos:

  • 130.000 acessos únicos
  • +60.000 cadastros
  • 2º lugar no Google pra pesquisa “lançamento pokemon go no Brasil”
  • +200 menções no twitter (alguns dos meus favoritos: 1, 2, 3, 4)

No final das contas foram mais de 120.000 cadastros!

O projeto

Ele surgiu basicamente assim:

“Anthony, tá no hype do Pokemon GO?”
“Até tô mas não tenho onde rodar”
“Viu aqueles sites gringos pra avisar quando Pokemon GO sair nos EUA? Vamos fazer uma versão BR?”
“Partiu!”

Uma noite depois estava no ar o LançamentoPokemonGOBrasil! Um site simples que avisaria as pessoas, via email, assim que Pokemon GO fosse liberado no Brasil.

Muito do sucesso do projeto, obviamente veio do grande hype em cima do tema. Mas haviam várias outras pessoas também tentando lançar projetos relacionados a Pokemon GO. Por que o nosso deu certo?

Agilidade e foco no que importa

Eu e Anthony somos calejados de hackathons, conseguimos criar apps em apenas 1 noite ou um final-de-semana. Assim que surgiu a idéia, já combinamos a noite do hackathon e criamos tudo rapidinho no esquema MVP!

Focamos em um produto mínimo (o email de aviso do lançamento nem estava pronto ainda!), prestamos bastante atenção ao SEO, percebe-se pela escolha do domínio né? E logo após por no ar, divulgamos em nossas redes sociais e nos dias seguintes focamos no marketing.

Um grande alavancador do crescimento do projeto foi termos saído no IGN Brasil (um beijo pra você @thaistagni) que nos trouxe milhares de acessos o que colocou nosso “loop viral” pra girar, incentivávamos fortemente o usuário a divulgar o projeto após o cadastro.

Aprendizados

Foi MUITO legal ver um projeto nosso, feito tão rapidamente, bombar tanto em pouco tempo. Aprendi que vale muito a pena focar no loop viral do projeto e em divulga-lo fortemente.

Mas o grande aprendizado foi o seguinte: deveríamos ter pensado o quanto antes em como monetizar o projeto! Tivemos mais de 120.000 emails cadastrados mas não os usamos para nada!

Assim que o projeto começou a bombar, deveríamos ter tirado mais um tempo para fazer um brainstorm sobre como monetizar essa base toda e AGIDO. Ficamos extasiados com o sucesso do projeto, o hype passou e perdemos o timing que nos foi tão essencial inicialmente para o sucesso do projeto! 😞

E se eu já tenho um projeto, vale a pena criar um sideproduct?

Claro! Imagine se você possuísse um negócio que fosse interessante para essas 120.000 pessoas,  uma loja de jogos ou produtos nerds, por exemplo. Esse projeto seria uma excelente fonte de leads!

Pergunte-se:

  • qual pequeno problema eu poderia resolver para meus clientes?
  • o que eu poderia fazer para tornar a vida dos meus clientes mais fácil ou mais feliz?

Criar um sideproduct desses pode ajudar a crescer muito suas vendas, por mais que não seja ligado diretamente com o seu negócio. #ficadica

Curtiu a história? Quer fazer parte da próxima?

Como falei, eu, o Anthony e alguns amigos estamos sempre criando sideprojects em hackathons. Criamos dezenas até hoje (fora os que desenvolvemos como freela para terceiros), se você é um designer/ programador/ marketeiro/ “cara foda do comercial” e também curte essas paradas: deixa aí um comentário que temos um slack pra trocar idéia sobre isso 🙂

Se quiser mais algum detalhe sobre o projeto, perguntar algo, só deixar nos comentários também que eu respondo de boa. Nesse post eu tentei fazer um resumo de forma a incentivar a galera a botar pra frente seus próprios projetos, se a gente consegue, você também consegue! 👍

Usando field type daterange com Rails e PostgreSQL

Outro dia precisei criar um model que permitisse ao freelancer marcar sua disponibilidade no Bonsai. A idéia é que ele pudesse marcar que está disponível full-time, part-time ou indisponível durante um certo período de dias.

Uma boa alternativa para a clássica combinação de campos “start_date” e “end_date” foi usar o field type daterange que o PostgreSQL possui e o Rails suporta muito bem.

Como defini-lo na migration:

create_table :availabilities do |t|
  t.daterange :period
  ...
end

Trabalhando com campos daterange

Filtrar os records com períodos que comecem a partir do início da atual semana:

scope :from_current_week_onward, -> { where("lower(period) >= :beginning_of_week", beginning_of_week: Date.current.beginning_of_week) }

Pesquisar por um período exato:

Availability.where("period && daterange(:start, :end)", start: Date.current, end: 3.days.from_now)

O campo tem todos os métodos de um Range do Ruby:

a.period # => Mon, 02 Jan 2017...Mon, 09 Jan 2017
a.period.begin # => Mon, 02 Jan 2017
a.period.end # => Mon, 09 Jan 2017

Por que eu uso Date.current? Leia esse post que escrevi no blog da HE:Labs: Evitando problemas com datas e timezones no Rails.

Gotcha

Atenção pra um detalhe importante: o Rails sempre salva o range usando a versão exclusiva dela:

availability.period = Date.current.beginning_of_week..Date.current.end_of_week # => Mon, 02 Jan 2017..Sun, 08 Jan 2017
availability.save # => true
availability.reload.period # => Mon, 02 Jan 2017...Mon, 09 Jan 2017

Isso é um saco, apanhei bastante até perceber isso então espero que esse post ajude a poupar o seu tempo 😁

Quer poder definir horários nos ranges também?

Se você precisar usar horas e minutos no seu range, também é simples, basta usar o field type tsrange ao invés do daterange. 😉

Highbrow, cursos por email que duram apenas 2 semanas

Ano novo, momento propício pra tomar vergonha na cara e parar algum hábito ruim e começar um bom. Se você concorda, o Highbrow vai te ajudar nessa mudança!

Ele tem cursos por email com duração de apenas 2 semanas. Ao se inscrever você receberá um email diariamente (nos dias úteis) com um texto para você refletir ou alguma tarefinha.

Sim, só isso, bem simples. Acesse logo o Highbrow, dê uma olhada na lista de cursos deles e escolha o seu 👍

Se curtiu a dica, agradeça ao @anthonysousa no twitter porque foi ele quem me indicou 🙂

ps: se quiser ser mais ousado nessa promessa de ano novo, dê uma olhada no Mega Maker Challenge.

Security - Private

Como private methods funcionam no Ruby

Uma confusão comum em Ruby é com métodos de classe privados. Veja o código a seguir:

class TwitterAccount
  def self.exibition_name
    "Cayo Medeiros #{username}"
  end

  private
    def self.username
      "yogodoshi"
    end
end 

Muitas pessoas acreditam que o método self.username está privado devido a declaração private logo antes dele. Porém, essa declaração só funciona para métodos de instância, não para os de classe.

Para transformar um método de classe em privado, utilize:

private_class_method :username

Para maiores detalhes, leia nesse post a resposta do criador do Ruby sobre o porque ter sido feito dessa forma.

Reaprendendo a agradecer

É fácil assumir que as pessoas que produzem conteúdo que admiramos recebem centenas de mensagens de elogio e agradecimento dos seus milhões de fãs.

Também é muito fácil ler um post técnico que nos ensina algo novo e não dar um like ou comentar agradecendo o autor por ter dedicado um tempo para compartilhar seu conhecimento.

Nas redes sociais acontece algo ainda mais estranho, as pessoas veem vídeos, leem posts e links postadas por outros: riem, descobrem algo incrível, ficam sabendo de uma notícia importante ou aprendem algo…

E em troca não conseguem dedicar nem 2 segundos para dar um like no post, como se tivesse uma cota mensal de likes e eles fossem escassos!

Agradecer as pessoas é algo que volta e meia percebo que estou deixando de fazer e tento voltar a trabalhar isso no meu dia-a-dia.

Se você também acredita que deveria agradecer mais as pessoas, comece aos poucos, dando like nas redes sociais e comentando nos posts que le.

Para criar este hábito em mim, adicionei Thank someone no meu perfil do Coach.me.

logo-coach-me

Recomendo este app para quem quer criar novos hábitos ou simplesmente mante-los. Uso diariamente como vocês podem ver lá no meu perfil :p

Cuidados ao chamar models em migrations do Rails

Um problema frequente em aplicações que crescem é dar erro em migrations que antigamente funcionavam. Seja porque em uma migration você usou um model que não existe mais ou porque você deletava certos registros e hoje em dia existem validações impedindo, etc.

Prevenir o erro

Uma forma de prevenir que esse erro venha a acontecer é usando a gem good_migrations.

Ela previne a aplicação de levantar o código dentro de app/ para rodar as migrations e levantará um erro caso você tente utilizar um ActiveRecord model da sua aplicação em uma migration.

O jeito certo de fazer

Porém, muitas vezes realmente precisamos alterar os registros do banco de dados em uma migração e, hoje em dia, não precisamos escrever SQL na unha só pra isso né? #comofas então?

Crie um model bem simples dentro mesmo da migration, exemplo:

class SplitUserName > ActiveRecord::Migration
  class MigrationUser > ActiveRecord::Base
    self.table_name = :users
  end

  def up
    add_column :users, :first_name, :string
    add_column :users, :last_name, :string

    MigrationUser.find_each do |u|
      u.update_columns(
        first_name: u.name.split(" ").first,
        last_name: u.name.split(" ").last,
      )
    end
    
    remove_column :users, :name
  end
end