1up4developers logo

1up4developers

Nadando contra o Waterfall. tail -f /mind/realworld >> /blog

Programação Funcional Com JavaScript

| | Comments


“JavaScript is LISP in C’s clothing” – Douglas Crockford

O que é programação funcional

Programação funcional é, assim como a orientação a objetos, uma forma de se pensar em como resolver problemas.

A base do que hoje é a programação funcional foi criada paralelamente por Alan Turing e Alonzo Church na década de 1930, antes mesmo da existência dos computadores como o conhecemos.

Infelizmente, a programação funcional passou muito tempo restrita aos meios acadêmicos, o que faz com que o iniciante no assunto fique assustado com toda aquela notação matemática e com os termos incompreensíveis.

ω := λx.x x
Ω := ω ω 
Y := λg.(λx.g (x x)) (λx.g (x x))

Felizmente, o conceito de programação funcional é muito simples. Assim como na orientação a objetos a menor parte de um sistema é um objeto, você pode atribuir objetos a variáveis, pode passá-los por parâmetro e ter métodos retornando objetos, na programação funcional a menor parte do seu sistema é uma função.

Isso implica que você pode atribuir funções a variáveis, pode passá-las por parâmetro e mesmo fazer com que uma função retorne outra função. Alguma linguagens implementam também imutabilidade, que é quando todo valor é tratado como se fosse uma constante, e outros conceitos periféricos, o que não é o caso do JavaScript. Todos os demais conceitos de programação funcional derivam do fato de você lidar com funções como se fossem um valor como qualquer outro.

High order functions

Uma high order function (não achei uma tradução decente para o Português), apesar do nome intimidador, é simplesmente uma função que recebe outra função como parâmetro ou devolve uma função como resultado. Quando você usa callbacks no JavaScript e no jQuery, você está fazendo uso de high order functions.

$("button.mallandro")
  .click(function() {
    alert("Ié ié!");
  });

O método click é uma high order function, e a função anônima que faz Ié ié! é um callback.

Mais para frente vou mostrar mais formas de usar high order functions.

Escopo

Apesar do conceito de escopo não ser exclusivo da programação funcional, é importantíssimo que você entenda como funciona o escopo no JavaScript para que não fique confuso ao ver closures e currying.

Como na maioria das linguagens comerciais, uma variável declarada em um escopo maior é visível em um escopo menor, enquanto o contrário não é verdadeiro.

Na prática significa que uma variável global é visível por todo mundo:

var x = 1;

function foo() {
  console.log(x);
}

foo();

// Saída:   1

Significa também que uma variável local só é vista dentro do escopo em que foi criada, mesmo que tenha o mesmo nome de uma variável global:

var x = 1;

function bar() {
  var x = 99;
  var y = 42

  console.log(x, y);
}

bar();
// 99 42

console.log(x);
// 1

console.log(y);
// ReferenceError: y is not defined

Quando uma função altera o valor de uma variável global, isso afeta toda a aplicação. Por isso o uso de variáveis globais não é considerado uma boa prática. Porém, uma variável global passada por parâmetro para uma função não tem o seu valor alterado:

var x = 1;
var y = 11;

function meh(x) {
  console.log("Dentro: ", x, y);
  x++;
  y++;
  console.log("Dentro: ", x, y);
}

meh(x);
// Dentro:  1 11
// Dentro:  2 12

console.log("Fora: ", x, y);
// Fora:  1 12

Closures

Outra característica do escopo é que uma função guarda as variáveis do contexto em que foi criada. Isso significa que uma função pode continuar acessando variáveis que só existiam no momento em que ela foi criada.

function counter() {
  var x = 0;

  return function() {
    return ++x;
  }
}

var count = counter();

console.log(count());
// 1
console.log(count());
// 2
console.log(count());
// 3
console.log(count());
// 4
console.log(x);
// ReferenceError: x is not defined

O que acontece aqui é que count recebe uma função que incrementa o valor da variável x, só que essa variável existe apenas dentro da função counter. O que aconteceu aqui é que a função armazenada em count se lembra da variável que foi criada em outra função, mas que não está mais sendo executada.

Ao tentarmos exibir o valor da variável x, recebemos um erro, pois ela não existe no escopo global.

Currying

Juntando tudo o que vimos até aqui sobre high order functions, escopo e closures, chegamos ao currying. Currying é uma operação em que você transforma uma função que receberia mais de um parâmetro em uma série de chamadas de funções com apenas um parâmetro cada.

Um dos usos dessa técnica é evitar, de forma elegante, que o mesmo parâmetro seja passado para a mesma função.

Vamos pegar um exemplo escrito de forma imperativa. Temos uma função hey, que recebe os parâmetros texto e nome e, a partir disso, imprime uma saudação.

function hey(texto, nome) {
  console.log(texto + ", " + nome);
}

hey("Bom dia", "João");
// Bom dia, João

hey("Bom dia", "José");
// Bom dia, José

hey("Bom dia", "Nicolau");
// Bom dia, Nicolau

Você pode dizer que poderíamos guardar “Bom dia” em uma variável. Concordo, mas isso não mudaria nada dentro do que estamos apresentando.

Reescrevendo a mesma função usando currying, teremos o código abaixo:

function hey(texto) {
  return function(nome) {
    console.log(texto + ", " + nome);
  }
}

var bomDia = hey("Bom dia");

bomDia("João");
// Bom dia, João

bomDia("José");
// Bom dia, José

bomDia("Nicolau");
// Bom dia, Nicolau

Programação funcional é muito mais do que os conceitos que apresentei aqui, mas como um primeiro contato já dá para fazer muita coisa bacana.

Recomendo que você estude e pesquise a respeito. Mesmo que você não use uma linguagem funcional no seu dia-a-dia, o fato de conhecer um novo modo de pensar acaba alterando a forma como você resolve problemas, fazendo com que você tenha idéias melhores e mais elegantes.

Update em 26/02:

Este artigo foi publicado também no iMasters, no endereço http://imasters.com.br/front-end/javascript/programacao-funcional-com-javascript/.

Esse texto é parte do livro Dominando JavaScript com jQuery, publicado pela Editora Casa do Código.

HTTP Monkey - Lançado!

| | Comments


HTTP Monkey é um cliente http simples, com interface fluente, suporte a múltiplos adapters (Net::HTTP, Curb, HTTPClient, EM-HTTP-Request) e middlewares no estilo rack.

Pontos positivos:

Pontos negativos:

  • Gem nova. Ainda não tem um case em produção.

  • Falta de middlewares para funcionalidades como Cache, OAuth … etc.

  • Não suporta adapter que permite requisições em paralelo.

  • Tem o Faraday como concorrente, que tem base em produção e bastantes middlewares.

  • A comunidade nacional e internacional ainda não conhece o Monkey (comecei agora a trabalhar nisso).

Na página HTTP Monkey an alternative to Faraday, comecei um trabalho de “localizar” o desenvolvedor que está acostumado com o Faraday em como trabalhar com o Monkey. Lembrando que a DSL do HTTP Monkey, foi feita pensando em substituir o uso do Restfulie, muita usada nos projetos da Abril Mídia.

Tem também uns slides que apresentei na Abril em alguns tech talks.

HTTP Monkey from Roger Leite

Valeu e aceito numa boa sugestões e críticas referentes ao projeto, por favor comentem! :D

Nos Idos De 2012, UML, Design E Waterfall

| | Comments


Há alguns anos atrás não havia uma referencia forte e consistente sobre os processos de desenvolvimento de software que não fosse Waterfall. Embora movimentos ágeis, processos mais simples e eficazes venham sendo utilizados a muito mais tempo, eles não eram tão evidentes como agora. Independente do processo ágil discutido Scrum, Lean, XP e etc, etc, etc… o movimento para remover as velhas e engessadas práticas de desenvolvimento de software cresce vertiginosamente e começa a movimentar grandes empresas, que ainda amarradas e processos internos pesadíssimos, entendem que algo precisa mudar para se conseguir maior flexibilidade e agilidade ao entregar novos serviços e funcionalidade a seus clientes, e obviamente, estar à frente da concorrência.

Em meio a corrida do novo ouro, me encontro em uma sala de treinamento, às vesperas de um novo ano, estudando, discutindo e demonstrando como analisar e modelar sistemas utilizando a mais famosa linguagem de modelagem: a UML. Nunca consegui traçar uma ligação saudável entre os modelos criados com UML e código funcionando em produção. A idéia principal da UML é a de comunicar aos envolvidos em um projeto o que se planeja implementar; quais os detalhes que norteiam o desenvolvimento de uma solução e que requisitos funcionais e não funcionais devem ser implementados. O problema é que qualquer coisa diferente de código no desenvolvimento de sistemas, está fadada a diferentes interpretações, ao conhecimento e experiência de quem produz e consome tais artefatos.

A idéia de times multidisciplinares e autogerenciáveis trazida pelo movimento ágil distoa fortemente do modelo cascata, que delinea claramente o papel do analista de negócios/requisitos, o arquiteto/designer da solução e os pobres desenvolvedores que terão de seguir à risca todas definições impostas pelos modelos produzidos. E se durante o ciclo ágil os problemas identificados são priorizados para serem endereçados no próximo ciclo, como o processo formal gerencia isso? Hum… daí vem minha maior crítica quanto ao uso de modelos no desenvolvimento de software. Já que se decidiu por engessar o processo, seguí-lo fielmente deveria ser o preço a ser pago para manter tanta parafernalha de artefatos sem valor. Identificado o problema, o fluxo deveria voltar lá no início e corrigir requisitos, modelos, código e testes; mas o mercado não permite tanta demora, as linhas de negócio precisam colocar seu produto na prateleira e o fluxo controladamente perfeito que outrora se desenhou, na vida real não funciona mais.

É inviável manter a “documentação” do sistema em face a uma concorrência e volatilidade de negócios tão vorazes, então eu me pergunto: O que aquelas pessoas estavam fazendo trancadas numa sala, consumindo o tempo a um alto custo da sua empresa? Aprendendo a como não fazer? Pode ser. Constatando uma vez mais que embora no papel, no processo, tudo aquilo que a teoria diz é muito bonito e controlado mas não funciona no mundo real? Sim, pode ser também, mas o pior é que passados anos de experiências ruins, projetos fracassados e montanhas de dinheiro jogados no ralo, ainda terão coragem de propor um processo baseado em requisitos → modelagem → desenvolvimento → testes, faseados e interdependentes, ignorando o histórico de dores e prejuízos experimentado.

Rails 4 - Novidades

| | Comments


O Rails 4 já está em desenvolvimento faz um tempo, na verdade um bom tempo, desde 20/Dez/2011, olha o commit do DHH aqui. No Ruby on Rails guides do edge, já tem muita coisa documentada do que vem por aí.

Segue um resumão:

  • Suporte somente a ruby 1.9.3 ou superior

  • Vendor/Plugins já era

  • Muita “magia” movida pra gems \o/ (Dynamic finders, Mass assignments, AR Session Store, ActiveResource … e muito mais)

  • Interface de Queue

  • Asynchronous Mailer

  • ActionController::Live

  • HTML5 tag helpers

  • Threadsafe on by default

O Santiago Pastorino, um dos commiters do Rails está mantendo um ótimo post sobre o desenvolvimento do Rails 4, que vale a pena acompanhar.

Sucesso!

MinionServer - a Real Server to Mock Servers!

| | Comments


MinionServer is a ruby gem to help you with integration tests. You can create an app using Rack Builder and start a tiny server very easy. Let me show you some code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
require 'minion_server'

# build your integration app
IntegrationApp = Rack::Builder.new do
  map "/" do
    run lambda { |env|
      [200, {"Content-Type" => "text/plain"}, ["Be happy!"]]
    }
  end
end

server = MinionServer.new(IntegrationApp)
server.start("localhost", 1620)  # default: localhost, 4000

# do your calls
system "curl http://localhost:1620" # => "Be happy!"

server.shutdown

You can see more examples at http_monkey’s integration tests. Hope that helps!

pt-br moment: Está em inglês porque eu publiquei no coderwall e depois tive a idéia brilhante de postar aqui, com a preguiça mais brilhante ainda de traduzir em pt-br.

[QuickTips] Migrando Sua App Rails Do MySQL Para PostgreSQL Sem Dor

| | Comments


Motivação

Meu primeiro contato com banco de dados relacionais foi o PostgreSQL, ou Postgres, nos tempos da faculdade. Achei muito complicado na época, difícil de instalar, administrar, etc. Quando comecei a programar profissionalmente, por volta de 2004, conheci o MySQL e gostei muito da sua simplicidade de configuração e ótima performance. Passou a ser o banco de dados padrão para a maioria dos projetos pessoais ou onde havia possibilidade de escolha.

Tudo andava bem, até que a Oracle comprou a Sun Microsystems em 2009. Não é segredo que nunca fui fã da Oracle, e considerando os acontecimentos recentes com o Java e o OpenOffice, não demoraria muito para o MySQL também receber seu toque de Midas da escrotização.

Dentre várias alternativas, optei pelo PostgreSQL pela sua performance, muitas vezes comparável com o Oracle DB, suporte da comunidade, e por ser Open Source.

Instalando o Postgres

Se você estiver no Ubuntu, basta rodar:

$ sudo apt-get install postgresql-9.1 libpq-dev

Finalizada a instalação, inicie o serviço e abra o client do Postgres:

$ sudo service postgresql start
$ sudo -u postgres psql

Aproveite o terminal e mude a senha do usuário postgres:

# \password

Para sair, digite:

# \q

Migrando o banco

Estou usando a gem mysql2psql, que embora esteja deprecated, funciona muito bem e não tem dependência do stack do Rails, como o activerecord. Assim é possível rodar a migração fora do contexto da aplicação e descartar o MySQL quando terminar.

O funcionamento é simples: conecta no banco MySQL de origem e copia a estrutura e os dados para um banco Postgres destino configurado. Para instalar:

$ sudo gem install mysql2psql

Em seguida, execute:

$ mysql2psql

Isto criará o arquivo mysql2psql.yml com a estrutura de configuração necessária. Edite este arquivo para ficar assim:

mysql:
 hostname: localhost
 port: 3306
 socket: /var/run/mysqld/mysqld.sock
 username: root
 password: root
 database: app_development
destination:
 postgres:
  hostname: localhost
  port: 5432
  username: postgres
  password: postgres
  database: app_development

Agora crie o banco de destino no Postgres:

$ sudo psql -h localhost -U postgres -W
# CREATE DATABASE app_development;

Saia do client com \q e então rode novamente:

$ mysql2psql

Se as configurações estiverem corretas, a estrutura do banco e os dados serão migrados. O output será parecido com:

Creating table comments...
Created table comments
Creating table schema_migrations...
Created table schema_migrations
Creating table users...
Created table users

Counting rows of comments... 
Rows counted
Loading comments...
5 rows loaded in 0min 0s

Counting rows of schema_migrations... 
Rows counted
Loading schema_migrations...
20 rows loaded in 0min 0s

Counting rows of users... 
Rows counted
Loading users...
418 rows loaded in 0min 0s

Indexing table comments...
Indexed table comments
Indexing table schema_migrations...
Indexed table schema_migrations
Indexing table users...
Indexed table users

Table creation 0 min, loading 1 min, indexing 0 min, total 1 min

Configurando a app

Para finalizar, remova a gem do mysql, adicione a do Postgres no Gemfile e configure o database.yml com as informações do Postgres:

# Gemfile
gem 'pg'




# database.yml
development:
  adapter: postgresql
  host: localhost
  database: app_development
  username: postgres
  password: postgres

Basta rodar bundle install e iniciar sua aplicação usando PostgreSQL!

Se precisar ou preferir rodar uma migração no contexto da sua app, dê uma olhada na gem mysql-to-postgres, do mesmo autor.

Caso tenha alguma dúvida ou sugestão, deixe seu comentário.

[QuickTips] Nginx: Redirect De Domínio Com Www Para Domínio Sem Www E Vice-versa

| | Comments


Simples, basta usar o HttpRewriteModule.

Para redirecionar de www.dominio.com para dominio.com faça:

server {
    server_name  www.dominio.com;
    rewrite ^(.*) http://dominio.com$1 permanent;
}

server {
    server_name  dominio.com;
    #configurações do servidor aqui
}

E para redirecionar de domínio.com para www.dominio.com, faça:

server {
    server_name  dominio.com;
    rewrite ^(.*) http://www.dominio.com$1 permanent;
}

server {
    server_name  www.dominio.com;
    #configurações do servidor aqui
}

Voilà!

Concepção Do RoloGames

| | Comments


Este post é um tópico da Experiência de lançar o RoloGames.

Quando surgiu a idéia

Como jogador, nunca achei um serviço legal pra trocar jogos usados. Haviam poucas opções e normalmente as trocas eram feitas via fórum (UOL Jogos, por exemplo). Na época minha filha tinha acabado de nascer, eu estava num emprego novo e acabei congelando a idéia. Recentemente surgiram alguns sites de trocas, tentei usar mas não gostei, pois eram muito “abertos” e mais aborrecia do que gerava oportunidade real. Sofrendo com isso que o Panachi e eu bolamos o RoloGames, onde a troca deve ser sempre 1 por 1 e o site só te avisa se o match for exato.

Definindo um mantra

A Arte do Começo - The Art of Start

Totalmente baseado nas dicas do Sr. Kawasaki em A Arte do Começo, definimos uma filosofia para o site. Lembrando que se mantivermos esta filosofia sempre em mente, o site não perderá seu foco:

  • Oportunidades confiáveis. Queremos que o usuário encontre somente as oportunidades de troca que façam sentido a ele, e não receba spams que infortunam a vida ou propostas sem noção (por exemplo, oferecerem um jogo antigo em troca de um lançamento).

  • Toda troca deve ser justa. Infelizmente, é uma prática considerada normal a troca de 3 jogos por 1, onde pessoas ganham dinheiro em cima de jogadores. As propostas e trocas são sempre de um jogo por outro, de acordo com os desejos e ofertas dos usuários.

  • Fácil de usar. O site não deve atrapalhar a vida do usuário com mensagens que ele não queira receber ou oportunidades que não façam sentido. É claro que a velocidade de navegação do site conta neste quesito.

  • Social. Os usuários podem acompanhar a atividade de seus amigos, enviar mensagens diretas e ter a escolha de trocar os jogos somente com quem quiser.

Provas de Conceitos

Antes de encostar no código, o Panachi e eu definimos o objetivo do site e algumas premissas para começar o projeto, e a mais importante era: ter um banco de dados de jogos. Definimos somente as informações necessárias de um jogo, e partimos para uma prova de conceito. Em dois dias conseguimos montar um banco de dados bem completo, e a nossa solução foi simplesmente um crawler de jogos! Por sinal, foi tão produtivo que nossa outra prova de conceito originou o psn_trophies.

Interface no papel

Em paralelo às provas de conceito, começamos a rascunhar as telas do site. O processo foi bem simples, uma pilha de sulfite e lápis (na falta de uma caneta Sharpie). A partir dos esboços, começamos a definir quais funcionalidades o site teria. Em seguidas priorizamos as mais importantes e fechamos o escopo da primeira versão. Durante o desenvolvimento, muita coisa mudou no layout, mas os “rabiscos” da concepção foram a essência de tudo.

Início do desenvolvimento

Já tinhamos uma prova de conceito, uns rascunhos das páginas e uma lista de funcionalidades. E todo processo levou cerca de uma semana.

Sem perder mais tempo, partimos para o código! E foi então que começamos a tropeçar nos detalhes… mas este será um assunto para o próximo post. Até lá!

A Experiência De Lançar O RoloGames

| | Comments


Nesta segunda-feira lançamos o RoloGames.

Rolo Games - Rede Social de Troca de Jogos

Trata-se de um site social para trocar jogos de videogames, no caso, PlayStation 3.

O Panachi e eu ralamos muito durante 2 meses, projetando e programando todas as funcionalidades. Não foi fácil, mas é gratificante ver o site no ar.

Antes de contar esta experiência, queria falar um pouco do passado e dos projetos onde já falhamos (e aprendemos!), por ordem de lançamento:

  1. Business Bingo Generator. Primeiro site que lançamos, foi feito em dois dias e só de zueira. O legal é que na época tinha uns dez termos cadastrados … :D

  2. MeAciona (fora do ar). Foi há mais de 3 anos atrás. Na época, foi o nosso primeiro projeto feito em Rails. Foi muito legal criar o site e ao mesmo tempo aprender Ruby/Rails. O site tinha integração com a Bovespa, cadastro de usuários e possibilitava definir “regras” para receber avisos sobre determinado momento de um papel. Era voltado à pequenos investidores, como uma ferramenta para auxiliar a monitorar as ações. Porém logo percebemos que este nicho/mercado era muito restrito e que existiam várias outras ferramentas gratuitas para esta finalidade. Desistimos da idéia, porém o que aprendemos durante seu desenvolvimento não foi perdido!

  3. Mooney. Controle financeiro pessoal simples, rápido e seguro. Este foi o Panachi que fez, ficou bem legal e ele usa até hoje.

  4. Sitefique.me (fora de funcionamento, porém mantemos no ar, como portifólio, em http://sitefiqueme.1up4dev.com). Foi no ano passado (2011). Já tinhamos mais experiência técnica e conseguimos em 3 meses, lançar um serviço mega legal que permitia que qualquer pessoa pudesse criar um site com layout customizado e o publicasse na internet com domínio próprio ou utilizando o subdomínio xxx.sitefique.me. Esperávamos atingir um mercado de pequenas empresas que precisassem manter um site completo e atualizado com um pequeno investimento mensal. É claro que não foi pra frente, pois não planejamos a parte não técnica e vendável (marketing, divulgação, etc) do serviço. A concorrência, principalmente serviços gratuitos, também ajudou a engavetarmos a idéia.

Mas como diz o ditado “até mesmo um pé na bunda te empurra pra frente” , continuamos perseverando! É um trabalho cansativo, mas o segredo é não desistir jamais! Isto até me lembra do Rails Summit (em 2008!), quando o Chris Wanstrath contou que antes de criar o Github, ele já tinha lançado mais de 17 sites! Segundo o meu cálculo, contando com o Rolo Games, ainda temos mais 12 chances! :D

E pensando nisso, resolvi compartilhar a experiência de como foi planejar, desenvolver e colocar no ar o RoloGames. Eu não consigo escrever posts gigantes (tipo do Akita), então resolvi dividir a experiência em três partes (vou atualizando os links conforme forem publicados):

Espero que o post te ajude de alguma maneira e te motive também, afinal até hoje o “polêmico” Pare de chorar e mexa-se é um dos posts mais lidos do blog!

Vagrant, Virtualizando O Ambiente De Trabalho

| | Comments


Vagrant, se você não conhece ou não deu atenção para ele nestes últimos tempos, este post é pra ti mesmo. Trata-se de uma ferramenta que facilita (e muito!) a criação de Máquinas Virtuais usando o Virtual Box por baixo dos panos. E não é só isso! Com o Vagrant fazer port forward, compartilhar pastas é só questão de alterar um arquivo de configuração. Continue lendo que eu detalho melhor tudo isto.

Prós e Contras

Vários pontos se destacam no uso do Vagrant:

  • Centraliza as dependências de ambiente do projeto. Sabe aquele projeto legado que só roda com rubygems 1.4.2 e mongo 1.1, com o Sol alinhado aos anéis de Saturno, então, você pode deixar tudo isso num box do Vagrant.

  • Documenta as dependências de ambiente, caso use algum Provisioner.

  • Facilita a integração de novos desenvolvedores na equipe, independente do SO que utiliza.

  • Mantém a sua máquina local “limpa”. Você não precisa instalar o Mysql, Postgree, Redis, Memcache etc. para cada projeto que roda.

Agora vem o contra.

  • Se você trabalha com projetos simples ou até mesmo com poucos projetos, você pode sentir que está usando um canhão para matar mosca.

Instalação

Você precisa do VirtualBox (versões 4.0.x ou 4.1.x). Já o Vagrant, o jeito mais fácil é instalar via rubygems, ou seja, um “gem install vagrant” e pronto! Caso ache melhor instalar via .dmg, .deb etc., você pode baixar em http://downloads.vagrantup.com.

Exemplo de Uso

O Getting Started do Vagrant é bem completo e tem também o Rails Cast, mas segue um resumão.

Supondo que o vagrant está instalado. Vamos adicionar uma máquina:

$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box

Dentro da pasta do projeto, você tem criar o Vagrantfile e para isso execute:

$ vagrant init lucid32  #ja especificando o box lucid32 baixado

Vamos subir a VM:

$ vagrant up

Para acessar a VM:

$ vagrant ssh

Repare que dentro da VM, na pasta “/vagrant” estará montado o diretório do seu projeto, onde está o Vagrantfile. Supondo que seja um projeto Rails, daí em diante você segue todo o fluxo default, instalando o bundler, dando um bundle install e etc.

Vamos supor que você executou um “rails s” na VM e o projeto subiu na porta 3000. Para acessá-lo, você tem que configurar o forward_port no VagrantFile:

1
config.vm.forward_port 3000, 4000  # 3000 from VM, available at 4000

Dá um restart na VM:

$ vagrant halt && vagrant up

Subir o projeto novamente. (vagrant ssh e o “rails s” dentro do /vagrant)

Acesse http://localhost:4000.

Extras e Conclusão

A idéia deste post é explicar rapidamente o que é e como usar o Vagrant, mas com certeza o Vagrant tem muito mais a oferecer. Segue alguns tópicos, que valem posts:

Provisioning – Existem várias ferramentas que podem te ajudar no setup da sua VM. O Vagrant tem suport a Chef, Puppet e até mesmo Shell script.

Plugins – Você pode mudar ou adicionar funcionalidades ao Vagrant, criando plugins. É claro que sempre vale a pena googlar antes. Por exemplo o vagrant-snap, que ajuda a tirar e gerenciar snapshots da VM.

Boxes – No exemplo acima, usamos um box de Ubuntu, mas nada impede de você criar ou utilizar outros boxes. Existe o vagrantbox.es que pode te ajudar a baixar uma existente, ou você vai ter que se aventurar pelos docs para criar uma zerada.