All you need to do is type in the session name and your nickname. To invite other team members, you simply send them a link to your session and that’s it. After adding tickets you can start estimating.

What Makes It Special For Me

Sprint Poker is the application that I always wanted to create. Here’s what makes me proud of it:

• Asynchronous communication between client and server.
• Modern React based frontend.
• Elixir powered backend on the top of Erlang VM.
• Every single thing makes this application cool.

We want to share our experience and open source it. You can check it out and run it. If you’ll find any bug, report an issue or create pull request please!

Technical Background

Long time ago

When client’s side application became real and websocket connection became standard I really wanted to make communication between client and server asynchronous. I didn’t want to request server just to check if something changed and wait for a response. With websocket it’s quite easy. Both sides can push messages and listen to them. To update user client, you simply send “user:update” message and … that’s it. When server updates it, it sends “user” message with current user. Also when some background job updates it, server sends it too. Client simply waits for the message and when it arrives, it changes stored data. A perfect solution for Sprint Poker.

Phoenix and Elixir

Rails is a great framework, but not so asynchronous. For websocket thing node.js is doing better. But I don’t want to write a lot of javascript. Seriously.
Recently Elixir has reached 1.0 version. Elixir is a Ruby like functional language on top of Erlang VM. With Phoenix Framework they’re a great tandem. They give you speed and maintainability at once. This is a very good choice for websocket backend. Especially when you like Ruby.

React

There are a lot of frontend frameworks. Angular, Ember.js, React. They’ve passed a long way to become what they are now. But for Sprint Poker I needed something small that fits into small asynchronous application. React was a bullseye. Of course React is only a view layer, but with Reflux it’s a really powerful tool. Stores, actions and components — it’s all there. Actions change a state, components render a state and can invoke actions. Pretty simple. But wait, there’s a one catch. A websocket.
We need to change a state, when websocket message comes in. No problem. Store implements websocket communication and updates it when messages arrive.

Sprint Poker — Free Agile Estimating Tool was originally published in EL Passion Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s see how closely related are Phoenix and Rails. We’ll do it all from scratch on OS X, with some help from Homebrew package manager.

The Environment

We’ll start with installing both languages that the frameworks rely on. Just like Ruby, Elixir already has several version managers to choose from, like exenv and kiex. But we won’t use them for the sake of simplicity.

Ruby installation:

$ brew install ruby

Elixir installation:

$ brew install elixir

Next thing we need is a package manager. Just like Ruby has its Gems, Elixir’s package manager is called Hex. Equivalent for Ruby’s Rake is Elixir’s Mix. Hex + Mix combined give us Ruby’s Bundler dependencies management functionality.

So we use Mix task to install Hex package manager:

$ mix local.hex

The Foundation

We don’t do it often, so let’s recall how to install the Rails framework:

$ gem install rails

Phoenix framework installation is no harder:

$ mix archive install phoenix

We’re ready to create a new application. In Rails it’s nothing more than running everyone’s most beloved command:

$ rails new railsapp

The command created new app with its directory structure, and then Bundler downloaded and installed all dependencies.

Let’s see how Phoenix deals with the task:

$ mix phoenix.new phoenixapp

Wow! New application created, dependencies downloaded. Beautiful.

To test our sample application we have to start a web server.

A Rails server:

$ rails server

And Phoenix server:

$ mix phoenix.server

GET /hello_phoenix

Both frameworks are MVC based, so our main building blocks are models, views and controllers. Just like Rails, Phoenix has generators for those:

$ rails generate model

vs.

$ mix phoenix.gen.model

…but this is the easy way. I want to compare how to add the base features by hand, just to figure out the differences.

We’ll create sample page displaying a welcome message.

First things first, we’ll add a route for it. With Rails, we create new route by editing config/routes.rb file:

Rails.application.routes.draw do
  get '/hello' => 'hello#index'
end

In Phoenix we have web/router.ex:

defmodule Phoenixapp.Router do
  use Phoenixapp.Web, :router
  ...
  scope "/", Phoenixapp do
    pipe_through :browser # Use the default browser stack
    get "/hello", HelloController, :index
  end
end

Now, controllers time!

Within Rails app create app/controllers/hello_controller.rb file:

class HelloController < ApplicationController
  def index
    @text = 'Hello from Controller'
  end
end

Within Phoenix create web/controllers/hello_controller.ex file:

defmodule Phoenixapp.HelloController do
  use Phoenixapp.Web, :controller

def index(conn, _params) do
    conn |> render "index.html", text: "Hello from Controller"
  end
end

For the view we’ll use Rails’ erb and Elixir’s equivalent: eex.

For Rails we only need to create one file: app/views/hello/index.html.erb

<h1><%= @text %></h1>

Phoenix requires us to create a view module beside the template. It’s (more or less) like a view helper in Rails. It will sit in web/views/hello_view.ex:

defmodule Phoenixapp.HelloView do
  use Phoenixapp.Web, :view
end

The accompanying template file will be web/templates/hello/index.html.eex:

<h1><%= @text %></h1>

Run servers once again. Go to the browser, type http://localhost:3000/hello for Rails and http://localhost:4000/hello for Phoenix. It just works! Do you have this feeling again?

Rising from the ashes

Who doesn’t like benchmarks and numbers? So here they are. Rails app was benchmarked with Passenger in production environment. Phoenix app was running with built-in cowboy server. The machine was Macbook Pro (2014, 2.6GHz i5, 8GB RAM).

Rails:

$ passenger start -e production
$ wrk -c100 -d10s http://localhost:3000/hello/

Running 10s test @ http://localhost:3000/hello/
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   143.47ms   21.31ms 295.32ms   91.25%
    Req/Sec   346.55     39.50   440.00     74.50%
  6927 requests in 10.05s, 8.96MB read
Requests/sec:    689.55
Transfer/sec:      0.89MB

Phoenix:

$ MIX_ENV=prod mix compile.protocols
$ MIX_ENV=prod PORT=4001 elixir -pa _build/prod/consolidated -S mix phoenix.server
$ wrk -c100 -d10s http://localhost:4001/hello/

Running 10s test @ http://localhost:4001/hello/
  2 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    16.73ms    3.78ms  78.27ms   91.46%
    Req/Sec     3.02k   290.98     3.58k    83.00%
  60097 requests in 10.01s, 72.67MB read
Requests/sec:   6003.29
Transfer/sec:      7.26MB

Note that it is just a simple benchmark with empty controller. You have been warned :)

Oh, there is one important thing. Phoenix is Elixir, and Elixir is not Ruby. It looks a lot like Ruby but there are differences.

What else? In both frameworks’ controllers we have a params hash to manage url params. Error pages are very similar. There are more equalities. Asking for models? Rails has ActiveRecord, Phoenix has ecto. Both support various database drivers, tasks for managing the database and its schema through migrations. Both frameworks ship with built-in testing frameworks.

If you know Rails, you already are familiar with Phoenix. It is still very young, so you have the chance to be an early adopter, and I highly encourage you to play with it while it’s hot!

Playing with Phoenix Framework — Rails’ younger brother was originally published in EL Passion Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

There has been a lot of discussion about isomorphic app development, where both server and client-side parts are written in the same language. One of the most mature and popular attempts to enable isomorphic development in Ruby is Opal.

In this article I’ll show you how easy it is to start writing your client-side scripts in Ruby. Right here, right now, with no excuses! :)

Merging two worlds with opal-rails

First, let’s install opal-rails gem:

$ gem install opal-rails

This gem enables us to generate new Rails application with Opal support (note the — javascript=opal option):

$ rails new opal-on-rails --javascript=opal

When bundle is complete we’re ready to start. Let’s create a controller for manipulating Colors:

$ cd opal-on-rails
$ rails g controller Colors

Then add it to config/routes.rb as a root:

Rails.application.routes.draw do
  root 'colors#index'
end

Now it’s time for some HTML. Create a view app/views/colors/index.erb:

<h1>Hello Opal</h1>
<p>This is simple Opal application</p>

Launch the server and open http://localhost:3000 in your browser.

$ rails s

First encounter

Until now we saw nothing fancy, nothing more than some standard Rails bootstrap app. But take a look at what the controller generator created in app/assets/javascripts/colors_view.js.rb!

class ColorsView
  def initialize(selector = 'body.controller-colors', parent = Element)
    @element = parent.find(selector)
    setup
  end
  attr_reader :element

def setup
    # Put here the setup for the view behavior
    say_hello_when_a_link_is_clicked
  end

def say_hello_when_a_link_is_clicked
    all_links.on :click do |event|
      # Use prevent_default to stop default behavior (as you would do in jQuery)
      # event.prevent_default

puts "Hello! (You just clicked on a link: #{event.current_target.text})"
    end
  end

private

def all_links
    @all_links ||= element.find('a')
  end
end

It’s a nice piece of pure Ruby code that logs all clicked links to the browser console. Yup, a real Ruby script that works in a browser!

To see what Opal will generate from this Ruby code, checkout Try Opal online Opal-JS compiler.

To make the script work, we need to edit our template. Open app/views/layouts/application.html.erb, find body tag and edit it:

<body class="controller-<%= controller_name %>">

We also want to initialize ColorsView when the document is loaded. Remember jQuery? rails-opal supports it. At the end of the file just add:

Document.ready? do
  ColorsView.new
end

Looks familiar, right?

The last thing is to add some links to our template, and we’re ready to test the script. Edit app/views/colors/index.erb:

<a href="#">Click me!</a>

Does it work? Of course it does. It’s Ruby :) After clicking on a link we’ll see our JavaScript console flooded with Hello! (You just clicked on a link: Click me!) messages. Perfect.

Digging deeper

Want more? Let’s create some fancier client-side Ruby thing: add links that will change the header color on click.

Add links section to the template:

<section>
  <h3>Change header color to:</h3>
  <ul>
    <li><a href="#" data-color="red">red</a></li>
    <li><a href="#" data-color="green">green</a></li>
    <li><a href="#" data-color="blue">blue</a></li>
  </ul>
</section>

Create another method in ColorsView:

def change_header_color_when_a_link_is_clicked
    all_links.on :click do |event|
      event.prevent_default
      Element['h1'].css 'color', event.current_target.data('color')
    end
  end

Change setup method:

def setup
    # Put here the setup for the view behavior
    # say_hello_when_a_link_is_clicked
    change_header_color_when_a_link_is_clicked
  end

And we’re done. Refresh the browser and have fun playing with your isomorphic Ruby app :)

Any color you like, as long as it’s ruby

Opal is a fully featured Ruby implementation, including both corelib and stdlib. You have your much loved blocks, iterators, even method_missing is here! The more I use it, the more I love it. It’s like discovering Ruby again!

The project itself is moving forward pretty fast. The codebase is tested against RubySpec to make Opal as compatible with MRI as possible. There are still some bugs and glitches, but still it’s worth the try. Version 0.8 is around the corner, with working source maps and lots of bug fixes.

What about support for native JavaScript libraries? Well, it’s not that simple like with CoffeeScript. You have to write a wrapper or include pure JavaScript code within backticks (just like executing shell commands in Ruby), although most popular jQuery code works out of the box.

How do you like the idea of writing client-side Ruby? Do you think Opal can replace CoffeeScript? Should it?

Opal on Rails: Replacing CoffeeScript with client-side Ruby was originally published in EL Passion Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.