So with the UNIX terminology out of the way, how does this work in Ruby? How can we fork a Ruby process using Ruby? Here is a basic example:

puts "This is the first line before the fork (pid #{Process.pid})"
puts fork
puts "This is the second line after the fork (pid #{Process.pid})"

The output from this code might be something like:

This is the first line before the fork (pid 10207)
10209
This is the second line after the fork (pid 10207)
This is the second line after the fork (pid 10209)

So what just happened? Well the first line is pretty clear but then what is the output on the second line (10209)? Well that is the PID returned by the call to fork and , of course, represents the PID of the child process. Then we see the next two lines; one executed by the parent (with PID = 10207) and the other executed by the child (with PID = 10209).

Blocks

Very often, the code that developers want to run in a separate process is passed as a block to the fork method, like so:

puts "You can also put forked code in a block pid: #{Process.pid}"
fork do
  puts "Hello from fork pid: #{Process.pid}"
end
puts "The parent process just skips over it: #{Process.pid}"

This outputs the three lines (sometimes) in different order but usally like this:

You can also put forked code in a block pid: 10161
The parent process just skips over it: 10161
Hello from fork pid: 10163

Note that the PID in the block is different from the PID outside it. This is because the code running within the block is running from within the new process created by using fork.

Multi-core CPU test

Let’s quickly verify one of the main benefits for using fork which is for multi-processing. Let’s write a test Ruby program that can be used to demonstrate this effect.

def cpu_intensive_process
  puts "Pid: #{Process.pid}"
  x = 0
  10000000.times do |i|
    x = i + x
  end
end

fork
cpu_intensive_process #should see two processors flat out!

When this code is run two processors should max out. If the machine has more than two processors available then only two processors will ever max out with this code as it stands. However, using fork additional times will result in even more processes going flat out (up to all your processors, of course) ! Here is a screen capture of the CPU process monitor on my PC:

CPU Maxing out during a Ruby Fork

Memory test

So what happens with the memory allocation. Apparently in Ruby 1.9.3 (which I am using here) there is no CoW functionality which means that the memory allocation for each process should be the same. Here is a little program that goes some way towards testing that (although, I would say that it is not conclusive):

hash = Hash.new #load up the memory a little

1000000.times do |i|
  hash[i] = "foo"
end

puts "Hash contains #{hash.keys.count} keys"

def show_memory_usage(whoami)
  pid = Process.pid

  mem = `pmap #{pid}`

  puts "Memory usage for #{whoami} pid: #{pid} is: #{mem.lines.to_a.last}"

  sleep #keep the process alive
end

puts "Now lets fork this process and see what memory is allocated to the child"

puts "Before..."

if fork
  show_memory_usage("parent")
else

  puts "After..."

  1000000.times do |i| #change the values in the child memory allocation
    hash[i] = "bar"
  end

  show_memory_usage("child")
end

Here is the result of this test. Feel free to copy this code, changing it around a bit and see what results you get!

Hash contains 1000000 keys
Now lets fork this process and see what memory is allocated to the child
Before…
After…
Memory usage for parent pid: 10291 is: total 62592K
Memory usage for child pid: 10293 is: total 73164K

Orphan Processes

Finally, lets try out testing orphan processes and how they behave. Run this final little program to see:

fork do
  5.times do
    sleep 1
    puts "I'm an orphan!"
  end
end
abort "Parent process died..."

The results are as follows:

Parent process died…
terminal ~: I’m an orphan!
I’m an orphan!
I’m an orphan!
I’m an orphan!
I’m an orphan!

So what’s happening here? Well the parent process completes and therefore terminates to give me back the terminal prompt. But then suddenly I am interupted with the output of the 5 child processes (now technically orphans) as they execute their code one after the other following a little sleep!

Well that’s all for my post today on Ruby Forks or how to Fork Ruby. Next time we will be having more fun with Ruby (but not necessary forking it). Till then, happy (insert whatever it is that you do here)!

In order to do this we need to think about how the component can be reused in different applications; i.e. not tied directly to any domain specific markup, schema or business logic in the application that is being built. Now, you would probably want to create a separate repository for this project since, after all, it is not strictly meant to live inside an application (unless, of course, your not interested to use the component in any other project other than the one your working on).

The Template

The template has a single placeholder message which can be set in the instance of the model that is used in the application. Note, from the line class=”alert fade in” that this particular component will work best with Twitter Bootstrap.

The Model

The Notification model has two defaults set: message and status (which is another model). Notice the namespace com.tweetegy.ui used to keep the objects separate from the application.

com.tweetegy.ui.NotificationModel = Backbone.Model.extend({
    defaults: {
	message: "Loading...",
	status: com.tweetegy.ui.NotificationStatusMessage
    }
});

Notification Status Types

The Notification Status Types Model acts as an enum holding strings to represent the status of each notification that is shown. This is used to control the style of the notification.

com.tweetegy.ui.NotificationStatusMessage = "NotificatonStatusMessage";
com.tweetegy.ui.NotificationStatusError = "NotificatonStatusError";

Backbone View

This is the object that wraps everything up and allows us to reuse this as a component (as we will see later). This is just a standard Backbone View, with an added helper method updateStyleFromStatus which changes the style depending on the status of the Notification and closeNotifcation that hides it.

The other important thing to note is the line this.model.bind(“change”, this.render); which is where we use the ‘magic’ of Backbone data binding to render our notification anytime the message or status of the applications notification model changes. It means that all we need to do in our application is set either the message or the status and the view will render itself.

com.tweetegy.ui.NotificationView = Backbone.View.extend({
    className: "well form-inline",

    events: {
	"click .close": "closeNotification"
    },

    initialize: function() {
	_.bindAll(this, 'render', 'updateStyleFromStatus');
	this.template = _.template($('#notification-template').html())
	this.model.bind("change", this.render);
    },

    render: function() {
	var self = this;
	$(this.el).html(this.template(this.model.toJSON()));
	this.updateStyleFromStatus();
	$(this.el).find("#notification").show();
	return this;
    },

    closeNotification: function() {
	$(this.el).find("#notification").hide();
    },

    updateStyleFromStatus: function() {
	var newClass = "alert fade in";
	if (this.model.get('status') == window.NotificationStatusError) {
	    newClass = "alert alert-block alert-error fade in"
	}
	$(this.el).find("#notification").removeClass().addClass(newClass);
    }
});

Using the component

I used it in an application called “Front Desk” and initialized it in the bootstrap.js file during application initialziation:

    com.tweetegy.FrontDesk.notification = new com.tweetegy.ui.NotificationModel();
    this._notificationView = new com.tweetegy.ui.NotificationView({
	model: y.f.FrontDesk.notification
    });
    $('div#notification').append(this._notificationView.render().el);

As mentioned above, in the Backbone View we bind to the models change event to render the view which means all we need to do is change the data in our applications NotificationModel instance (in this case com.tweetegy.FrontDesk.notification) and the Notification will automatically be rendered. Here is an example:

com.tweetegy.FrontDesk.notification.set({message: "Everything loaded! Starting application..."})

Conclusion

I have always liked the idea of UI components and using Backbone templates, views and models really makes it easy to build a highly customized UI library for your application, department, company or even to share with the entire community!

I have written another component which uses a Backbone Collection and can be used in a form to collect data from the user. This is a little more complex than the notification example here and I will cover it in a future blog post! Meanwhile, happy coding!

(Note there is a full definition available on Wikipedia)

I think the main thing to take away from the Wikipedia definition is that a generator is something that looks like a function and behaves like an iterator. What this means is that we can create a generator and call it, however many times we want, and it will return the next value in the iteration. It means (as iterators do) that we can have more control over what happens before and after each iteration.

It also means that developers get the additional power to have complete control over what the iterator actually returns (for example a sequence of Prime Numbers). Another benefit is that they require less memory than say iterating over a large array that’s already explicitly defined.

So what does a Generator look like in Ruby?

Since Generators are like Iterators a good example to work with would be to write a program that generates a subset of Prime Numbers or Fibonacci Numbers – so this is what we will do in Ruby using a number of different approaches.

In Ruby, Enumerators are a form of Generators so here is a sligtly modified example (to use Ruby 1.9.2 Enumerator class instead of the Ruby 1.8.7 Generator) from Anthony Lewis’s blog. This example generates a set of Prime Numbers:

g = Enumerator.new do |g|
  n = 2
  p = []

  while true
    if p.all? { |f| n % f != 0 }
      g.yield n
      p << n
    end
    n += 1
  end
end

p g.take(10) #=> [2, 3, 5, 7, 11, 13, 17, 19, 23, 29]

Here is another example to generate Fibonacci Numbers that uses the Enumerator class, this is a slightly modified example taken from the Ruby docs. The only change I made here is that I am calling yield instead of using the alias <<. You could think of the call to yield or << as like sending out the value back to the caller (or at least that’s the way I think of it when I see a yield call in a Generator!)

fib = Enumerator.new do |y|
  a = b = 1
  loop do
    y.yield a
    a, b = b, a + b
  end
end

p fib.take(10) # => [1, 1, 2, 3, 5, 8, 13, 21, 34, 55]

Little more advanced example

If you want to build your own Generator, using lambdas, check out this example from Victor Moroz

fib =
  lambda{
    a, b = 0, 1
    lambda{ begin a ensure a, b = b, a + b end }
  }[]

puts (0..19).map{ fib[] }.inspect

Full definitions of Generators

(Full definition from Wikipedia): “A generator is a special routine that can be used to control the iteration behaviour of a loop. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of values. However, instead of building an array containing all the values and returning them all at once, a generator yields the values one at a time, which requires less memory and allows the caller to get started processing the first few values immediately. In short, a generator looks like a function but behaves like an iterator.”

• Preview multiple images using a multiple file input
• Add all the images to a Backbone collection and persist that collection to a server

Backbone Templates

I’ll start with the templates again. In this application I have three templates: one for selecting multiple images, one for displaying a single image preview and a container template for the header text and a placeholder for the collection.

The select multiple images template looks as follows:

The single image preview template is as follows:

Finally, the container is the most basic template, since it’s just a title and a placeholder for the collection:

There is nothing really particullarly special to mention with these templates, so let’s move on.

Backbone Views

I only want to focus on the enhancements I have made which is being able to preview a collection of images and save them to the server via a Backbone collection. Therefore, I will focus on one view here: GalleryView. Actually, this is a standard way of building a view that renders a collection of sub-views in it’s render method. Here I get a handle on the template gallery-template and append the rendered out ImageView for each Image in the Backbone collection for the Image Gallery:

 window.GalleryView = Backbone.View.extend({
	template: _.template($("#gallery-template").html()),

	initialize: function() {
	    _.bindAll(this, 'render');
	    this.collection.bind('add', this.render);
	},

	render: function(){
	    var $images,
            collection = this.collection;

            $(this.el).html(this.template({}));
            $images = this.$("#thumbnails");
            this.collection.each(function(image) {
                var view = new ImageView({
                    model: image,
                    collection: collection
                });
                $images.append(view.render().el);
            });

            return this;
	}
});

Backbone Collections

The Gallery collection is responsible for loading the image data into Backbone Image models and adding them to the collection. There is a function setFromFiles which expects a FileList object passed to it from the multiple file input. Here is the collection code:

window.Gallery = Backbone.Collection.extend({
	model: Image,
	url: "/images",

	setFromFiles: function(files) {
	    this.reset();
	    self = this;

	    for (var i = 0, f; f = files[i]; i++) {
		var reader = new FileReader();

		reader.onload = (function(theFile, theId) {
		    return function(e) {
			image = new window.Image();
			image.set({id: theId})
			image.set({filename: theFile.name});
			image.set({data: e.target.result});
			self.add(image);
		    };
		})(f);

		reader.readAsDataURL(f,i);
	    }
	}
});

The code that calls the setFromFiles method is actually in the ImageSelectionView (that renders the gallery-selection-template) and is called when a change event occurs on the multiple file input. The function looks like this:

dispatchUpdateGalleryPreview: function(e) {
	this.collection.setFromFiles(e.target.files);
}

The e.target.files is the FileList object that the setFromFiles function expects. Note I have prepended the function name with dispatch because it’s good practice in production code to have the application event driven and therefore this function would actually dispatch a custom event instead of calling the function directly on the collection.

Backbone Sync

Finally, we arrive at the persistence part! On the client side we use a little more Backbone. In this case, I simply want to save the entire collection, so I will use Backbone.Sync as follows:

Backbone.sync("create", this.collection);

This will cause Backbone to perform a POST request to the server to the location: ‘/images’ which is basically the url set in the Gallery collection earlier. One the server a Ruby file is waiting to process the response. In this example, I am using Sinatra server. Of course, developers are free to use any server technology they want! For completeness, here is the server side Ruby code:

post "/images" do
  payload = JSON.parse(request.body.read.to_s)

  payload.each do |image|
    data = image["data"]
    i = data.index('base64') + 7
    filedata = data.slice(i, data.length)

    File.open(image["filename"], 'wb') do |f|
      f.write(Base64.decode64(filedata))
    end
  end

end

Conclusion

This is a very basic application which demonstrates selecting, previewing and saving multiple image files to a Ruby Sinatra endpoint using Backbone and HTML5 on the client. There is no functionality to manage a collection of images, for example, edit or delete. However, I feel this example is enough to get started to build a fuller Image Gallery application! Many features could be implemented in this application including using the HTML5 Canvas to automatically resize images or allow the user to alter the images directly before saving. On the server side, the Ruby script could actually push the images to S3 instead of saving to the file system, for example.

Code

The code for this example is here.

Tutorials

Great tutorial using FileReader by HTML5 Rocks

Overview

The way to avoid any cross-site-scripting restrictions when uploading to S3 is essentially to do two things:

• Use a form to POST the data to S3
• Include in that form a Policy and Signature based on the content + your AWS keys

The Form

Since I am using Backbone.js in this example and since I want to show a preview of the image before uploading it, I realized that I needed to split the form into two templates. The reason was because I needed to be able to refresh the file meta data – that is essentially the key, policy and signature required by the AWS S3 API. Here are the two templates:

The Image Meta Template

The Image File Template

The data is passed to these templates from the Backbone View. However, when we select a new file we need to first update the preview (this template is discussed in the previous post) and then update the image meta template only (not the image file template because that is already correct). So this is the reason I have two templates here.

The interesting attributes of the image meta template are: key, POLICY and SIGNATURE which are all required by the AWS S3 API. The key is the simplest of the three, so let’s start with that.

The Key

The key is simply the bucket key we need to use in order to save (and later retrieve) the image back. In this example, I have the key made up of two attributes on the Backbone Model: folder and filename. The folder is set during the creation of the model in the bootstrap.js file and the filename is set when the user selects a file using the myImage file input. Right after the file has been sucessfully loaded into the preview, I call a function “updatePoilcy” which first sets the key attribute on the Model like so:

updatePolicy: function(){
	var key = this.get('folder') + this.get('filename');
	this.set({key: key});

	//more code later...
}

The Policy

The Policy is a JSON document that is then converted to Base64 encoding and set as a property on the Model. The code to do this is also in the updatePolicy function (hence the name!). Note that we are getting the data directly from the Model to build this Policy and that it must (and will, thanks to Backbone binding!) match with the values in the form template. Here is that code:

updatePolicy: function(){
//code to set the key attribute on the model

POLICY_JSON = { "expiration": "2012-12-01T12:00:00.000Z",
    "conditions": [
	["eq", "$bucket", this.get('bucket')],
	["starts-with", "$key", this.get('key')],
	{"acl": this.get('acl')},
	{"success_action_redirect": this.get('successActionRedirect')},
	{"x-amz-meta-filename": this.get('filename')},
	["starts-with", "$Content-Type", this.get('contentType')]
    ]
  };

var policyBase64 = Base64.encode(JSON.stringify(POLICY_JSON));
//Set the Policy on the Model so that it is then sent with the Form payload
this.set({POLICY: policyBase64 });

//more code later...
}

The Signature

The final part of this puzzle is the Signature. This is generated using the Policy and your AWS Secret key and is encrypted using SHA1 like so:

updatePolicy: function(){
//previous code (shown above)
var secret = this.get('AWSSecretKeyId');
var policyBase64 = Base64.encode(JSON.stringify(POLICY_JSON));
var signature = b64_hmac_sha1(secret, policyBase64);

this.set({SIGNATURE: signature });
}

The full updatePolicy function looks like this. Note that this function is called on the Model initialize and on any data changes (i.e. when the user selects a new image).

updatePolicy: function(){
	    var key = this.get('folder') + this.get('filename');
	    this.set({key: key});

	    POLICY_JSON = { "expiration": "2012-12-01T12:00:00.000Z",
			    "conditions": [
				["eq", "$bucket", this.get('bucket')],
				["starts-with", "$key", this.get('key')],
				{"acl": this.get('acl')},
				{"success_action_redirect": this.get('successActionRedirect')},
				{"x-amz-meta-filename": this.get('filename')},
				["starts-with", "$Content-Type", this.get('contentType')]
			    ]
			  };

	    var secret = this.get('AWSSecretKeyId');
	    var policyBase64 = Base64.encode(JSON.stringify(POLICY_JSON));
	    var signature = b64_hmac_sha1(secret, policyBase64);

	    this.set({POLICY: policyBase64 });
	    this.set({SIGNATURE: signature });
	}

Success Action Redirect

The successActionRedirect attribute on the model is worth a mention. In this example, I set it to the same page that sent the POST request. If you only want to send data to S3 this is fine, but what if you want to sent some of the meta data to another separate API? There are several ways to do this but one way would be to set this attribute to a service that sends the bucket and key to a backend queue. That queue can be periodically ‘popped’ via a cron job that makes a GET request to S3 to retrieve all the meta data saved there for that image file. This data can then be saved to a separate API at this point. This gives the developer full control over where the file meta data is transformed and stored.

Another thing to note is the attribute x-amz-meta-filename. This is actually a custom attribute and the developer can set any number of these with the POST request. They must start with “x-amz-meta-” but that’s about it! So you could have “x-amz-meta-width” & “x-amz-meta-height” which could be calulated using a HTML5 Canvas set and set as properties on the Model. As long as the Policy and the Form contain these same attributes, they will all be saved along with the image when the form is POST to S3. Very handy!

Conclusion

This is a basic example to show how to upload a file directly to S3 from the browser. There are still plenty of unanswered questions such as being able to upload multiple files or upload a file using AJAX and then post some meta data to a separate API (all directly from the browser). These issues can be the subjects of future posts.

Code

The code for this example is available here

To run the example you need to serve the folder from a HTTP server. I usually use Python SimpleHTTPServer for basic examples like this one. Thus, by default, if you CD into the example directory and run python -m SimpleHTTPServer then the application will be available at http://localhost:8000. You also need to create an S3 account and update YOUR-BUCKET, YOUR-ACCESS-KEY and YOUR-SECRET-KEY in bootstrap.js. Oh! and it will only work in the latest WebKit based browsers. I tested it in Chrome 16.0.912.63 beta. Good luck!

Tutorials

POST Example from AWS
Upload S3 files directly with AJAX
Another example from AWS

Backbone Templates

Backbone Templates allow developers to build re-usable layouts that can be instansiated within Backbone Views. For this example application, we will need two templates: one for the preview and one for selecting (and later saving) a new image file. Here is the HTML:

Preview Image Template

Select Image Template

Backbone Views

Backbone Views have the responsibility of initializing and rendering the templates into the DOM so that they are visible on the screen. They can also include data from the model. In the templates above, only one requires data from the model; preview-image-template. This is also, in fact, the most basic view in this example, so let’s look at that first:

Preview Image View

I won’t go into too much detail about what is happening here with the Backbone View but instead I want to focus on the task at hand; to load a preview of the selected image file. The main code to take notice here is the following call to bind in the initialize function:

this.model.bind('change', this.render);

This binds the change event on the model to call the render method on this view. The result will be that whenever any attribute on the model changes, the render method on this view will be called, resulting in the display being updated. But with what? Let’s continue to build the application with the SelectImageView shown below:

In this View I am binding to some DOM events which I am then passing onto View ‘dispatch’ functions. I prepended these functions with ‘dispatch’ because in a Production application environment developers would usually trigger custom events which would then be bound by Backbone Models or Views. In this case, I am cheating a little for simplicity and clarity and simply calling the setFromFile function directly on the model. This model, by the way, is exactly the same instance of the model that is bound to the PreviewImageView (see the bootstrap.js file description below to see how developers can set the model attribute on a Backbone View).

Backbone Models

This is by far the most interesting part of the application! There is only one model and so this is where we need to define our setFromFile function used in the view earlier. This function will use the new HTML5 FileReader object to read the data from the selected file and update the data attribute on the model with the raw data from the file. As you would have guessed by now, this fires a change event on the model which in turn causes the PreviewImageView to call render and we should see the new image appear on the screen!

Backbone Model

Backbone Router and bootstrap.js

For completeness, here is the code for this applications Backbone Router and the bootstrap.js code that kicks everything off. The router does nothing unusual but bootstrap.js deserves a little explanation.

I want the application to load in a state where we see a default image ‘preview.png’. This can be achived by setting the model with default attributes of filename = ‘preview.png’ and data = ‘img/preview.png’. This can also be done directly with the model definition too using defaults. Next I create both views and set the model property on each using the same model. As mentioned above, in Production, we would only set the model property on the PreviewImageView and use events to notify of any changes. Finally we create the Backbone Router and start the application!

Here is the code for the Backbone Router and bootstrap.js:

router

bootstrap.js file

Some cool tutorials on the subject

HTML5 Rocks
Backbone Tutorials

One of my favorite parts of the Ruby Programming language is being able to pass code to a method (usually an iterator) and have that code executed dynamically. In Ruby there are several ways to do this using: blocks, Procs and lamdbas. While these are all very similar, there are some very subtle differences. First let me explain blocks.

Blocks

Blocks are code that can be implicitly passed to a method in Ruby. Any method can in fact be passed a block of code even if the method does not explicitly expect it. In the following example, the method test_blocks does not explicitly expect or do anything with a block, however, if called with a block the code will run printing “in test_blocks”

def test_blocks
  puts "in test_blocks"
end

test_blocks { puts "in the block" }

# Output:
# in test_blocks

By simply adding the yield keyword to the method test_blocks the block will then be run causing the output to change:

def test_blocks
  puts "in test_blocks"
  yield
end

test_blocks { puts "in the block" }

# Output:
# in test_blocks
# in the block

Procs

It is possible to get a handle on the block by explicitly putting the block as a parameter in the method definition. Note that this must be the last parameter and must start with an ampersand:

def test_blocks(&block)
  puts block.class
end

test_blocks { puts "in the block" }
# Output:
# Proc

Notice that the class is Proc and so the only difference between a block and a Proc is that a Proc can be passed around as an explicit variable. Here is another example where we create a Proc object first and pass that into another method that expects a Proc:

def test_blocks(some_proc)
  puts some_proc.call
end

some_new_proc = Proc.new { puts "in the Proc !" }
test_blocks(some_new_proc)

# Output:
# in the Proc !

The main reason for having both block and Proc is:

• If we want to write Ruby like syntax when passing code to a method, and we only want to pass a single Proc we use blocks. This is very common pattern in Ruby code – especially with iterators.
• If we want to save a piece of code in a variable for reuse then use an explicit Proc object
• If we want to pass multiple blocks of code to a method and invoke them, we also must use an explicit Proc object

Lambda

Lambda is very similar to a Proc. Let’s first start off with an example:

def test_lambda(some_lambda)
  some_lambda.call
end

some_new_lambda = lambda {puts "in the lambda" }
test_lambda (some_new_lambda)

# Output:
# in the Proc !

As you can see this looks exactly like the Proc example above, so what is the difference? Well the answer is in the way Ruby handles Procs and Lamdbas. There are, in fact, two differences:

1. Lamdbas check the number of parameters passed into the call, Procs do not check the number of parameters
2. Lamdbas return from the executing block but not from the lexically surrounding method call when they encounter a return keyword (in other words lambda behaves like calling a method which then calls return, whereas a Proc will return from the calling method too

Here are a couple of examples to illustrate this. Firstly, the parameter handling differences:

def test_parameter_handling(code)
  code.call(1,2)
end

l = lambda {|a,b,c| puts "#{a} is a #{a.class}, #{b} is a #{b.class}, #{c} is a #{c.class}" }
p = Proc.new {|a,b,c| puts "#{a} is a #{a.class}, #{b} is a #{b.class}, #{c} is a #{c.class}" }

test_parameter_handling (p)
test_parameter_handling (l)

# Output:
# 1 is a Fixnum, 2 is a Fixnum,  is a NilClass
# ArgumentError: wrong number of arguments (2 for 3)

As you can see from the output of the example, the Proc does not care if we only call with two parameters when it’s possible to use three parameters – it simply sets all unused parameters to nil. However, when passing a lambda to the method, Ruby throws an ArgumentError instead. So if you want your Proc (a lamdba is an instance of Proc, by the way) to be called with a specific set of parameters – no more and no less – then use lamdba.

Here is an example that demonstrates the differences how Proc and lamdba behave when they encounter a return statement:

def return_using_proc
  Proc.new { return "Hi from proc!"}.call
  puts "end of proc call"
end

def return_using_lambda
  lambda {return "Hi from lambda!"}.call
  puts "end of lambda call"
end

puts return_using_proc
puts 

# Output
# Hi from proc!
# end of lambda call

When return_using_proc is called the method stops processing as soon as it encounters the return statement and we see “Hi from proc!” output. When return_using_lambda is called the return is encountered but does not cause the method to return and instead the method continues to run so we see “end of lambda call” output.

Here is another example to demonstrate this in a slightly different way:

def test_returns
  puts "top"

  pr = Proc.new { return }
  pr.call

  puts "bottom"
end

puts "before call"
test_returns
puts "after call"

# Output
# before call
# top
# after call

In this example, we see ‘before call’ output followed by ‘top’ as we would expect but then we see ‘after call’ – note there is no output for our puts ‘bottom’ statement. This is because the call to the Proc object (pr.call) caused the calling method to return since the Proc contained a return statement. If we replace the Proc with a lambda then we would see ‘bottom’ output as well since the call to the lambda simply returns back to the method which called it.

The main reason for this diffence is because Procs are more like blocks of code that can be ‘dropped in’ and executed whereas lamdbas behave more like methods. It is also for this reason why lambdas are more strict with parameter checking – just as methods are.

Ruby Closures

It’s important to note that blocks, Procs and lambdas are all closures. Basically this means that they hold the values of any variables that were around when they were created. This is a very powerful feature of Ruby because if we wrap creating a block of code in a method call we can dynamically create different behavior. For example:

def create_multiplier(m)
  lambda {|val| val * m}
end

two_times = create_multiplier(2)
three_times = create_multiplier(3)

puts two_times.call(1)
puts three_times.call(1)

# Output
# 2
# 3

Conclusion

In conclusion we are dealing with blocks of code that can be passed to method calls and executed within that method. When the block of code is executed in the method the state of any variables at the time of creation of that block of code are used. This means that blocks, Procs and lamdbas are all closures in Ruby.

It’s also interesting to conclude that:

Lambdas have strict parameter checking and diminutive returns.
Procs have no parameter checking and strong returns.
Blocks and lambdas are essentially just anonymous Procs

Some tutorials

• Understanding Ruby Blocks, Procs and Lambdas
• The Ruby Object Model and Metaprogramming – Episode 3

The Basics

When using the Geolocation API it is important to know the data that we are working with. With Geolocation we work with Latitude and Longitude values. These represent the following:

• Latitude: The distance North or South of the equator
• Longitude: The distance East or West of Greenwich, England

Usually, these values come from the mobile device GPS or, if the GPS is not available then the co-ordinates can be inferred from the IP address, Wi-Fi or even entered directly by the user.

Privacy

Since we are dealing with sensitive information, there are strict privacy requirements that must be followed when working with the Geolocation API. Fortunately, privacy user confirmation is triggered in all browses (that support Geolocation) automatically on any API call. You may have seen the message in some applications asking if it is ok that the application uses your location. This is Geolocation API security kicking in! It happens only once per domain so once you accept you will not need to accept every time you perform a Geolocation based action on that site.

Getting the co-ordinate data

To get the current position of the user, simply execute this function. Note that updateLocation is a callback function to handle the result.

navigator.geolocation.getCurrentPosition(updateLocation)

The position object passed to the updateLocation() function contains the following data attributes:

• latitude
• longitude
• accuracy

Here is an example of how the updateLocation function might appear:

function updateLocation(position) {
    var latitude = position.coords.latitude;
    var longitude = position.coords.longitude;
    var accuracy = position.coords.accuracy;
    var timestamp = position.timestamp;
    document.getElementById("latitude").innerHTML = latitude;
    document.getElementById("longitude").innerHTML = longitude;
    document.getElementById("accuracy").innerHTML = accuracy;
    document.getElementById("timestamp").innerHTML = timestamp;
}

Handling Errors

It’s important to handle errors in Geolocation API calls because there is so much potential for things to go wrong: network error, GPS issues, privacy / security issues, timeout etc. We can handle errors using another callback function that takes an error code and deals with that code accordingly. What we need to do first is include that callback function in the call to the getCurrentPosition Geolocation function:

navigator.geolocation.getCurrentPosition(updateLocation, handleError)

Then our handleError callback function might look like this (notice the 4 possible error codes):

function handleError(error) {
    switch (error.code) {
    case 0:
	updateStatus("There was an error while retrieving your location: " + error.message);
	break;
    case 1:
	updateStatus("The user prevented this page from retrieving a location.");
	break;
    case 2:
	updateStatus("The browser was unable to determine your location: " + error.message);
	break;
    case 3:
	updateStatus("The browser timed out before retrieving the location.");
	break;
    }
}

Repeated requests to keep track of users position

In the example above, getCurrentPosition() makes one call to get the users location. However, there maybe situations where you will want to track the users change in position over time. In this case it is better to use watchPosition().

Fortunately, it’s really simple to change to use watchPosition, here is an example so you can see how similar it is. Note we can set the watchId variable so that we can tell the API to ‘stop watching ‘ by making a call to clearWatch function at a later time:

var watchId = navigator.geolocation.watchPosition(updateLocation, handleError);
//Do something and sometime later we can stop watching by passing the watchId to clearWatch():
navigator.geolocation.clearWatch(watchId);

Conclusion

While this was a very basic introduction to the HTML5 Geolocation API, it is enough for developers to get started building something useful! Remember that you can also use Google Maps API to integrate mapping data into your application too!

Some cool examples

• Basic Example
• Demo’s difference with IP and Geolocation API based calls

Some tutorials

• Basic Tutorial
• Introduction Tutorial
• More detailed tutorial

I needed a free, document based, online data store so that I could quickly build a HTML5 prototype. As an exercise, I quickly whipped up a simple application that can store basic contact details of people.

Getting Started with MongoLab

To get started with MongoLab is really easy. Simply create your account, your database and your first collection and your good to go. The only reference document you need for this exercise is the MongoLab REST API docs

First things first: Adding data to your MongoDB using REST

I am only going to show you the absolute basics here, so no security, validation, callbacks or fancy UI designs – just the basics! I built this by creating a simple HTML5 form and I used XMLHttpRequest API to send the data to MongoLab.

Here are the code snippets, first the HTML:

…and the JavaScript. Note the variable json which is not defined in this snippet but is basically a JSON representation of the form data. The easiest way to get your form data into JSON is to use JQuery (again, I am not including how to do that to keep us focused on how to interact with the MongoLab RESTful API). Note: you will need to replace YOUR-DATABASE, YOUR-COLLECTION and YOUR-API-KEY with your values.

    var xhr = new XMLHttpRequest();
    xhr.open("POST", "https://api.mongolab.com/api/1/databases/YOUR-DATABASE/collections/YOUR-COLLECTION?apiKey=YOUR-API-KEY", true);
    xhr.setRequestHeader("Content-Type", "application/json");
    xhr.send(json);

When you load your page you will be able to add a new record to the database. You can check that it has arrived at the database by logging into mongolab.com and viewing the collection.

Next up: Display a collection of items

It’s really easy to get data from the MongoLab API – a simple GET request will do, in fact! Apart from that, this step is really an exercise in using the JavaScript DOM (which I will not cover here). Here is the HTML – as you can see it is just a placeholder for the data. I am using UL but, of course, you can load the data into whatever placeholder you like.

Basic JavaScript snippet shown below. As you see just a simple GET request (and send null since there is no payload). To complete this you’ll want to add an onreadystatechange function to detect when the request.status is 200 and then call your DOM rendering function at that point.

    var request = new XMLHttpRequest();
    request.open("GET", "https://api.mongolab.com/api/1/databases/YOUR-DATABASE/collections/YOUR-COLLECTION?apiKey=YOUR-API-KEY");
    request.send(null);

View a single document

To render a single document in your HTML5 application, you’ll want to, again, use the GET request but this time passing in the document id in the query string and using that to pull the correct document from your MongoDB. The HTML snippet is the same as for the collection, so I’ll just show the JavaScript code below. Notice how to get the id from the query string. This exampled is hard coded, and thus assumes the id is first in the query string and is in the form “id=12345″.

    var queryString = window.top.location.search.substring(1);
    id = queryString.substring(3,queryString.length);
    var request = new XMLHttpRequest();
    request.open("GET", "https://api.mongolab.com/api/1/databases/YOUR-DATABASE/collections/YOUR-COLLECTION/" + id + "?apiKey=YOUR-API-KEY");
    request.send(null);

Edit a document

Since this is a RESTful API, to update a document we need to use a PUT verb. The HTML snippet is almost the same as the adding data example, so just the JavaScript snippet here. Notice the getId() function call which simply gets the id from the query string. Obviously this is not a production ready or secure way of getting the id for a document we want to update.

    var xhr = new XMLHttpRequest();
    xhr.open("PUT", "https://api.mongolab.com/api/1/databases/YOUR-DATABASE/collections/YOUR-COLLECTION/" + getId() + "?apiKey=YOUR-API-KEY", true);
    xhr.setRequestHeader("Content-Type", "application/json");
    xhr.send(json);

Delete a document

Finally, we want to be able to delete a document. This is really easy as shown. Notice you need to send null like before because there is no payload.

    var request = new XMLHttpRequest();
    request.open("DELETE", "https://api.mongolab.com/api/1/databases/YOUR-DATABASE/collections/YOUR-COLLECTION/" + id + "?apiKey=YOUR-API-KEY");
    request.send(null);

Conclusion

Thankfully, with the excellent service provided by MongoLab.com developers are able to build nosql document database driven applications in no time and at no cost!

The Basics

Getting started with the Audio and Video API is real easy (as is everything in HTML5, in fact!). At the very basic level all you need to do is declare an <audio> or <video> tag in your html like so:

This is so basic that it does not even render the controls. In order to control video playback, the user has to use the context menu (which is not so easy to find for some). In order to render controls simply add the controls attribute like so:

Now we see the controls appear as sown below (notice that the first frame of the video is shown by default):

HTML5 Video with controls

Simple! So why does HTML5 have the option to not show the controls? Well the reason is to give the developer control over how the controls are rendered. Since JavaScript has an API to access the Audio and Video instances within the browser it is possible to create and style a “Play/Pause” button in anyway you like! Here is some example JavaScript code that demonstrates how to do this:

function playPauseMusic() {
      var music = document.getElementById("music");
      var playPauseBtn = document.getElementById("playPauseBtn");
      if (music.paused) {
        music.play();
        playPauseBtn.innerHTML = "Pause the Music!";
      }
      else {
        music.pause();
        playPauseBtn.innerHTML ="Play the Music!";
      }
    }

As you can see this is quite easy to do. Simply add an audio tag to the html page with id=”music” and a button tag with id=”playPauseBtn” and this JavaScript can be used to control the play / pause of your music! All it does is render a button but it works and demonstrates how easy it is to use the (in this case) Audio API (the Video API is very similar, by the way).

Use the Source!

So far I have only shown some simple examples. It is possible in HTML5 to specify different sources so that you can provide different file types for the media you want rendered. So in order to increase the chance that the browser supports the particular container or codec, make sure you save your media as different file types (e.g. ogg, mp4 etc) and use the source as in the following audio example:

Note the text ‘Some music by someone!’ just before the closing <audio> tag. This text will be rendered in non-supporting browsers so it provides a nice and easy way to gracefully fallback if that is the case.

Autoplay attribute

HTML5 Audio and Video API comes with the optional autoplay attribute. Use this with caution! There is nothing more annoying than a website that starts playing audio or video automatically on load! However, if you must, simply include the attribute in the <audio> or <video> tag.

Video API Basic Tip: Play Video on Mouseover

One thing you might have seen on the web is the concept of playing a video in a thumbnail when the mouse hovers over the video image. This is surprisingly easy to do in HTML5, by the way! All you need to do is set the onmouseover and onmouseout events to call play() and pause() methods respectively, like so:

That’s it for this very basic introduction! If you want to learn more about the HTML5 Audio and Video API, check out some of the following resources:

Some cool examples

• Basic Examples
• Video Events Example
• Some notes on HTML5 Video Codes support

Some tutorials

• A great HTML5 Audio Video API tutorial by Mozilla
• Another great tutorial, this time from HTML5 Rocks!