djbender

Game of Life

An implementation of Conway's Game of Life in 140 characters of Ruby.

Author

Created by Simon Ernst (@sier).

djbender

# Update, upgrade and install development tools:
apt-get update
apt-get -y upgrade
apt-get -y install build-essential
apt-get -y install git-core

# Install rbenv
git clone git://github.com/sstephenson/rbenv.git /usr/local/rbenv

# Add rbenv to the path:

djbender

def output name=((default=true); "caius")
  puts "name: #{name.inspect}"
  puts "default: #{default.inspect}"
end

output
# >> name: "caius"
# >> default: true

output "avdi"

djbender

require 'sinatra'

# before we process a route, we'll set the response as
# plain text and set up an array of viable moves that
# a player (and the computer) can perform
before do
  content_type :txt
  @defeat = {rock: :scissors, paper: :rock, scissors: :paper}
  @throws = @defeat.keys
end

djbender

Introducing Test::Unit

Test::Unit is the fundamental testing library built into Ruby. It has a very light syntax but can be used to test systems of any complexity. Most recently, in Ruby 1.9, it has been reimplemented on top of the MiniTest library. But we'll check out Test::Unit as it exists in Ruby 1.8.

Concepts of Testing

Software testing is a complex art. Let's lay some of the groundwork:

Approaches to Testing

djbender

Managing the Flash

HTTP is a stateless protocol. The server, generally speaking, has no idea if request number 243 came from the same user as request number 236. That's beautiful and, at the same time, annoying.

In the context of web applications we frequently want to persist state between requests. That might mean something like a shopping cart that follows a user through the online store, but it can be as simple as a status message.

In modern applications users expect feedback. They click a delete link and they expect to no just see the item disappear, they'll expect a "Item Deleted" message. In Rails we handle these messages using the flash.

Flash as Hash

djbender

Sessions and Conversations

HTTP is a stateless protocol. Sessions allow us to chain multiple requests together into a conversation between client and server.

Sessions should be an option of last resort. If there's no where else that the data can possibly go to achieve the desired functionality, only then should it be stored in the session. Sessions can be vulnerable to security threats from third parties, malicious users, and can cause scaling problems.

That doesn't mean we can't use sessions, but we should only use them where necessary.

Adding, Accessing, and Removing Data

djbender

Render and Redirect

The normal controller/view flow is to display a view template corresponding to the current controller action, but sometimes we want to change that. We use render in a controller when we want to respond within the current request, and redirect_to when we want to spawn a new request.

Render

The render method is very overloaded in Rails. Most developers encounter it within the view template, using render :partial => 'form' or render @post.comments, but here we'll focus on usage within the controller.

:action

djbender

require 'rubygems'
require 'bloops'

b = Bloops.new
b.tempo = 100
sound = b.sound Bloops::SQUARE
sound.volume = 0.5
sound.sustain = 0.3
sound.attack = 0.1
sound.decay = 0.3

djbender

I assume MinGW installed.

click Project -> Properties

C/C++ Build -> Settings -> [Tool Settings] -> MinGW C Linker (maybe be different, e.g. "GNU C/C++ Linker")

- Libraries - add the library: pthread 
- Miscellaneous - add the linker flag: -lpthread