steelThread

McDConsultingLLC.CreateUserPanel = function(config) {
    // add the seam component reference
    var userAction = Seam.Component.getInstance('userAction');
    Ext.apply(config, {
        seamComponent: userAction,
        remoteMethod: userAction.create,
        useMap: true
    });
    
    McDConsultingLLC.CreateUserPanel.superclass.constructor.call(this, config);

steelThread

@Entity
@Table(name = "user")
@NamedQueries({
    @NamedQuery(
        name="findByEmailAndPassword",
	query="select u from User u where u.email=:email and u.password=:password"
    )
})
public class User 
    implements Serializable 

steelThread

@WebRemote
@JsonResult
public String create(Map<String, Object> form) 
    throws Exception
{
    // construct the new instance and
    // associated client
    User user = new User();
    user.setClient(new Client());
    	

steelThread

perform: (job) ->
  old_title = process.title
  @conn.emit 'job', @, @queue, job
  @procline "#{@queue} job since #{(new Date).toString()}"
  try 
    if cb = @callbacks[job.class]
      cb job.args..., (err, resp) =>
        if err? then @fail err, job else @succeed job
    else
      throw "Missing Job: #{job.class}"

steelThread

# assumes the intended design is to have a single worker instance processing a single 
# job at any given time.  concurrency is achieved via multiple worker instances.
#
# forces/requires workers to implement a callback protocol with resque. without this resque will 
# lose track of the worker instance by not polling for new jobs. !important
#
# tried to add in the same polling fault tolerance from the original solution's try catch 
# finally block.  so long as the client calls back, resque will continue to poll regardless of an 
# exception potentially being  thrown out of @fail or @succeed (ie where did redis go).
# 

steelThread

var fs = require('fs');

fs.readFile('/etc/passwd', function (err, data) {
  if (err) throw err;
  console.log(data);
});

steelThread

Purpose

Take a look at a couple of very simple application stacks deployed to Heroku's cedar PaaS to understand just the raw http processing capabilities of a support ruby frameworks and node.

The Contenders

• Rails
• Sinatra
• Golaith
• NodeJS

The Setup

steelThread

Redis Groups

Small prototype to look at group and ranking across a lot of users.

Setup

• 10^6 players (can easily bump)
• 20,000 groups
• users are randomly put into 0..5 groups using a good distribution random # generator
• all users are playing a single game
• assuming the setup is a point in time somewhere during the game

steelThread

References

ec2 starters guide

Security Groups

Before we startup an AMI we need to setup the security group that we will apply to the instance. Essentially we want to allow inbound traffic on 22 (ssh) and the http ports (80, 443). I like to do this on the default security group. Here's an image of the inbound tab for my default security group:

Starting an Amazon Machine Image (AMI)

steelThread

#
# Reads xml in chunks, parses to js obj.
#
net    = require 'net'
sys    = require 'sys'
xml2js = require 'xml2js'

start  = new Date().getMilliseconds()
parser = new xml2js.Parser()
buffer = ''