If you are interested in helping test the upcoming version, please e-mail moostraxsupport@gmail.com.

Note: MoosTrax works on devices running iOS 4+.

iPhone Support/Help
MoosTrax iTunes Link

• View a list of all of your devices
• View the current location of any device on your account.
• Enhanced battery usage through the “Conserve Battery” feature.

The beta is still open, so send an e-mail to moostraxsupport@gmail.com to join.

I’m looking for beta testers…and then soon I’ll be pushing it to the App Store.

Applying for the beta

Please e-mail moostraxsupport@gmail.com with your iPhone’s UDID.

For information on finding the UDID, go here: http://www.geekology.co.za/blog/2009/07/how-to-check-your-iphones-udid-from-itunes/

Screenshots

As I continued to tackle more features in Fastr, it was time to tackle persistence — notably, database access.

AsyncRecord is/will be an ORM, similar to ActiveRecord — with one major difference — it doesn’t block. AsyncRecord currently uses em-mysql to access a MySQL database.

How it usually works

In most ORMs, when you attempt to access the database, everything in that thread will block until a response is received. This means that you waste time — just waiting. The CPU may be idle, but you cannot handle any more requests. (Typically you start multiple instances of your application to get past this, unfortunately each instance requires more resources on your server)

How AsyncRecord works

When you access something in the database with AsyncRecord, the request is sent to the database server, but control returns to the application immediately after the packet(s) are sent. When the server responds, which could be 20ms or 200ms later, a callback that you specify is invoked.

One important thing about accessing a database asynchronously, especially in web frameworks, is the ability to defer a response. Fastr has built-in support for deferred responses, a-la EventMachine/Thin.

A deferred response is when you tell the web server that you will send data to the client some time in the future, and the server is free to handle more requests until you are ready to respond.

Benchmarking

As I was implementing AsyncRecord, I knew it would be faster — but I wasn’t sure by how much. I setup a very simple Rails 2.3.5 application, as well as a Fastr application (from the latest source).

My goal was to make an application that has a single page, which shows 5 usernames from the database.

Rails controller:

class MainController < ApplicationController
  def index
    users = []
 
    User.all(:limit => 5).each do |user|
      users << user.username
    end
 
    headers['Content-Type'] = 'text/plain'
    render(:text => users.join("\n"))
  end
end

Fastr controller:

class MainController < Fastr::Controller  
  def index
    defer_response(200, {"Content-Type" => "text/plain"}) do |response|
 
      User.all(:limit => 5) do |users|
        users.each do |user|
          response.send_data("#{user.username}\n")
        end
        response.succeed
      end
 
    end
  end
end

The Numbers

Fastr

Average Latency: 123ms
Requests per second: 385 r/s

Rails

Average Latency: 2040ms
Requests per second: 42 r/s

The tests were performed using JMeter. 100 concurrent requests (10 requests per connection).

I also ran some tests using apache bench, here are the results:

ab -c 100 -n 1000 http://127.0.0.1:5000/

Fastr

Average Latency: 90ms
Requests per second: 1100 r/s

Rails

Average Latency: 2235ms
Requests per second: 44 r/s

Conclusion

I am extremely happy with what AsyncRecord can do — and I hope to make it even better. I will be moving it out of Fastr and into its own project soon.

Fastr GitHub: http://github.com/chrismoos/fastr

Every month I go on a binge and learn something new. The most recent binge resulted in a new web framework, called fastr.

I’ve always used Rails when I needed to create a web application in Ruby, but despite how great it is to code in, the performance and concurrency is not up to par.

Don’t get me wrong — Rails can scale, but it is not inherently very good when it comes to an individual instance’s performance. While this is hopefully changing in Rails 3, I wanted to see what kind of concurrency and performance I could get out of a simple EventMachine web application. Thus, fastr was born.

Fastr’s Architecture

Fastr is nothing special. It is an extremely simple MVC style web framework, similar in configuration to Rails.

What makes it different though, is how it handles requests and responses.

The core of fastr runs on an EventMachine reactor, which is basically just a big event loop. EventMachine is very capable of maintaining thousands of connections in one instance. This is great when you want an application that supports Comet and chunked responses. There is very minimal overhead in having thousands of connections that have occasional data flowing through.

EventMachine and Fastr also support the ability to defer a response until a long running task finishes executing. This is nice because it won’t block the rest of the application. The only catch is you are limited to EventMachine’s thread pool size, which I believe defaults to 20. You can always up this number though, if you want.

Routing

The routing is very similar to Rails, an example routes.rb file looks like this:

 router.draw do |route|
        route.for '/:controller/:action'
        #route.for '/home/:action', :action => '[A-Za-z]+'
        #route.for '/test', :to => 'home#index'
 end

Controllers

Controllers are simple, with just a list of actions that are called based on the route. Actions should return a valid Rack response. There are convenience methods in the controller that help in creating Rack responses.

The nice thing about the controllers in Fastr is that you can defer responses with ease. Here is an example of a deferred response:

  def long_running_task
    defer_response(200, {"Content-Type" => "text/plain"}) do |response|
      puts "in our deferred response...now we can do cool stuff!"
      response.send_data("hey\n")
 
      long_task = proc {
        log.debug "Sleeping for 5 seconds...but this won't block other requests"
        sleep(5)
        log.debug "Finished sleeping, returning response to client."
        return "finished"
      }
 
      callback = proc { |result|
        log.debug "Callback result: #{result}"
        response.send_data("#{result}\n")
        response.succeed
      }
 
      response.task(long_task, callback)
    end
  end

The alternative render methods also exist, where you can render a HAML template or just text:

render(:text, "Hello, world!")
render(:haml, :template => "index") # this searches for index.haml in your app/views/ folder

Future

For now, fastr is just a toy framework for me, that I hope to share with anyone interested in learning about building web frameworks.

I intend to start writing some tests as well as making fastr more robust. I don’t mean to displace any other Ruby web framework, but as I learn with fastr I hope to contribute what I learn back to projects like Rails and Sinatra.

Also, I’d like to get em-mysql or equivalent integrated so that you can really enjoy a event-driven web framework — event with database access.

Check out the GitHub page for more examples on getting fastr up and running.

GitHub: http://github.com/chrismoos/fastr

There are now hundreds of thousands of applications built for mobile phones, with every use case you can imagine. But even with the growth and advances of the past few years, the industry is still in its youth.

Apple, with its enormous success, is still constantly on the front page because of its questionable practice — sole control of the iPhone platform. Unlike desktop operating systems, such as Windows or Mac OS X, where the user is in complete control of the operating system, the iPhone is a jail, with Apple deciding what can come in and go out.

The App Store, the only way for a developer to target an iPhone, or a user to install an application on the iPhone, is in constant censorship mode. Certain API’s are not allowed and questionable content is put to rest.

It is time that Apple realizes that it is not only the hardware in the iPhone, or the software that powers it, that makes it a powerful force in the mobile phone market. The power is in the apps, the platform, and in the imaginations of developers.

Even though there are many applications for the iPhone, there could be so much more. The iPhone is a powerful device that can be used to provide a platform for mobile applications in every industry possible. Medical, industrial, retail — the list goes on. But as long as Apple is in control of what happens on the iPhone, developers will never be able to harness the full potential of such a beautiful device.

Apple now has the ability to turn the iPhone, and the new iPad, into a commodity device. The PC of the mobile world. My intuition tells me that Apple won’t let this happen. They prefer to maintain complete control of their platform, and while making it a premium and luxury item, they stop it from attaining the growth that it most definitely can achieve.

The future is in Apple’s hands — and they have the ability to make it an awesome place.

Let’s see how we can run trusted code and allow a dynamic (possibly user defined) script to execute with limited permissions. We will also see how the script can call functions in our trusted code and how we can elevate privileges to allow the untrusted script to get access to trusted data.

Setting up a security policy

We are going to create a java policy file that gives our script and groovy full access, but no permissions for our untrusted scripts

~/.java.policy

grant codeBase "file:/Users/chris/securegroovy/trusted.groovy" {
  permission java.security.AllPermission;
};
 
grant codeBase "file:${groovy.home}/-" {
    permission java.security.AllPermission;
};
 
grant codeBase "file:/restrictedScript" {
 
};

Trusted Script

Now we are going to create our Trusted script, which will evaluate our untrusted script in a sandbox.

trusted.groovy

package com.cmoos
 
import java.security.*
 
class TrustedScript {
  public static int main(String[] args) {
    println("Checking to see if security manager is enabled...")
 
    if(System.getSecurityManager() == null) {
      println("Security manager not enabled, using default.")
      System.setSecurityManager(new SecurityManager())
    }
    else {
      println("Security manager enabled.")
    }
 
    /* Create a shell with a restricted code base */
    def binding = new Binding([trusted: TrustedScript])
    def shell = new GroovyShell(binding)
    def codeSource = new GroovyCodeSource(new File("untrusted.groovy").getText(), "UntrustedScript", "/restrictedScript")
    shell.evaluate(codeSource)
 
    return 0
  }
 
  public static String getSystemProperty(String name) {
    println("Raising privileges to access system property...")
    return AccessController.doPrivileged({ -> System.getProperty(name) } as PrivilegedAction)
  }
}

We specify the code base to assign to the script, which will inherit the permissions in our security policy.

We also pass in our class into the script’s binding, allowing it to call our methods. This let’s us specify an API for the script to use to access trusted data, which we control access to.

By using AccessController.doPrivileged(), we can elevate our privileges to that of the calling code base.

Untrusted Script

untrusted.groovy

println("I'm in a sandbox...let's see if I can access a system property")
 
try {
  System.getProperty("java.home")
}
catch(java.security.AccessControlException e) {
  println("Couldn't get property: ${e.getMessage()}")
}
 
/* Call our trusted code (which is accessible through a binding) and get the property */
println("Calling trusted code to get property...")
 
println("java.home: ${trusted.getSystemProperty("java.home")}")

This code is executed in a sandbox, with permissions defined in our security policy. You can see that if we try to do something we don’t have permission for, access is denied.

By calling our trusted class, which has all permissions, we can give the script access to certain things, but we control it.

Running the example

$ groovy trusted.groovy
Checking to see if security manager is enabled...
Security manager not enabled, using default.
I'm in a sandbox...let's see if I can access a system property
Couldn't get property: access denied (java.util.PropertyPermission java.home read)
Calling trusted code to get property...
Raising privileges to access system property...
java.home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

sbt is a simple build tool for Scala projects that aims to do the basics well. It requires Java 1.5 or later.

Installing SBT

I’m using Mac OS X, but the following instructions should be pretty much the same on any Unix based OS.

You can find the latest version of SBT here.

cd ~
wget http://simple-build-tool.googlecode.com/files/sbt-launcher-0.5.6.jar
sudo mv sbt-launcher-0.5.6.jar /usr/local/bin/sbt-launcher.jar
echo "java -Xmx512M -jar /usr/local/bin/sbt-launcher.jar \"\$@\"" | sudo tee /usr/local/bin/sbt
sudo chmod +x /usr/local/bin/sbt

This will install the SBT jar and create a script called sbt that will allow you to run the sbt jar.

Just type sbt and press enter, and you now have access to sbt.

$ sbt
Project does not exist, create new project? (y/N/s) : n

Creating a new Scala project

Now we will create a Hello World Scala project with SBT.

mkdir hello_scala
cd hello_scala

Running the sbt command in a directory where there is no project will prompt you to create one.

sbt

Project does not exist, create new project? (y/N/s) : y
Name: Hello, Scala!
Organization []: 
Version [1.0]: 
Scala version [2.7.7]: 
sbt version [0.5.6]: 
:: retrieving :: sbt#boot
	confs: [default]
	2 artifacts copied, 0 already retrieved (9911kB/72ms)
:: retrieving :: sbt#boot
	confs: [default]
	3 artifacts copied, 0 already retrieved (3409kB/15ms)
[success] Successfully initialized directory structure.
[info] Building project Hello, Scala! 1.0 using sbt.DefaultProject
[info]    with sbt 0.5.6 and Scala 2.7.7
[success] Build completed successfully.
[info] 
[info] Total build time: 0 s

Awesome. It handles all the Scala dependencies for us! Now let’s create a file that contains our Hello, Scala example.

Below is the directory structure of an SBT project.

$ ls
lib	project	src

Creating our HelloScala sources and running

Now we are going to create our main file, HelloScala.scala

src/main/scala/HelloScala.scala

object HelloScala {
  def main(args: Array[String]) {
    println("Hello, Scala!")
  }
}

And now we can build and run it by just issuing the following:

sbt run

And the output:

[info] Building project Hello, Scala! 1.0 using sbt.DefaultProject
[info]    with sbt 0.5.6 and Scala 2.7.7
[info] 
[info] == compile ==
[info]   Source analysis: 0 new/modified, 0 indirectly invalidated, 0 removed.
[info] Compiling main sources...
[info] Nothing to compile.
[info]   Post-analysis: 2 classes.
[info] == compile ==
[info] 
[info] == copy-resources ==
[info] == copy-resources ==
[info] 
[info] == run ==
[info] Running HelloScala ...
Hello, Scala!
[info] == run ==
[success] Successful.
[info] 
[info] Total time: 0 s
[success] Build completed successfully.
[info] 
[info] Total build time: 1 s

And that’s it. Setting up a new Scala project with SBT is painless. In the next part I will talk about managing dependencies and how SBT makes this also very easy.

You can read a lot more about SBT by checking out their wiki.

Recently in Rails I’ve been interacting with various SOAP services and running them in the background with Workling. I needed to relay the SOAP response to the client’s web browser, so I decided to use AJAX to poll the status of my background tasks.

This is great if you have < 30 second background tasks running, but don't want to block a user (and a request).

The Solution

I created a Rails plugin, called AjaxTask, that has two components:

• Methods to use in your controller to define a task handler and create tasks
• Javascript library to manage the AJAX between the browser and the handler.

GitHub Link: http://github.com/chrismoos/ajaxtask

In a nutshell, the client initiates a task, the handler responds with a task ID, and the client polls at a user defined interval until the task has finished, or has an error.

The plugin takes the pain out of implementing the handler, as well as the Javascript. All you have to do is run code for your task, and periodically update the status.

I am using Workling to run my background tasks, as well as maintain the status using Workling’s return store.

Okay, enough with the intro, here is the example.

Example

Controller/Routes

The first thing to do is define the handler. This instructs the AjaxTask plugin to create a handler that will respond to ajax requests, as well as dispatch to your actual tasks. The only parameter to ajaxtask_handler is a symbol, which MUST be identical to a named route. This is how a URL gets from Rails to the plugin.

routes.rb:

map.ajaxtask_demo '/ajaxtask/handler/:task', :controller => :demo, :action => :ajaxtask_demo

demo_controller.rb:

ajaxtask_handler :ajaxtask_demo

Now we will define a task:

demo_controller.rb:

ajaxtask :mytask

This tells the plugin to respond to a task named mytask.

By doing this, we must implement two methods in our controller.

mytask_start is called when a browser starts a new task. You should probably fire off your background task in this method.

mytask_start should return a unique ID for the task. By using Workling and calling .async, a unique ID is returned.

def mytask_start
    return MyWorklingWorker.async_mytask
end
 
def mytask_status(uid)
    Workling.return.get(uid)
end

The Worker

The worker is the meat of our background task. In this we will do something that might take a while, and also update the status.

my_workling_worker.rb:

class MyWorklingWorker < Workling::Base
  def mytask(options)
    Workling.return.set(options[:uid], {:pending => 'i am just starting...wait up!'})
    begin
      # your long running task goes here
			sleep 10
    rescue => e
      Workling.return.set(options[:uid], {:error => e.to_s})
      return
    end
    Workling.return.set(options[:uid], {:done => 'i finished!})
  end
end

The important things to note here are what we set the return to. AjaxTask recognizes the following:

• :error
• :pending
• :done

They should be pretty self explanatory. Now let’s see what the client side looks like.

The Client

For the client, we will be interacting with the AjaxTask javascript library. Make sure you copy the ajaxtask.js file to your javascripts directory, and include it in your page. The following will copy the javascript for you:

cd vendor/plugins/ajaxtask
rake ajax_task_js

Here is an example of what an HTML page that uses AjaxTask:

<html>
<head>
	<%= javascript_include_tag 'ajaxtask.js' %>
</head>
<body>
<script>
function mytaskHandler() {
	$(this).bind('onTaskError', onTaskError);
	$(this).bind('onTaskFinished', onTaskFinished);
	$(this).bind('onTaskPending', onTaskPending);
 
	function onTaskError(event, error) {
		alert('error: ' + error);
	}
 
	function onTaskPending(event, data) {
		alert("pending: " + data);
	}
 
	function onTaskFinished(event, data) {
		alert("finished: " + data);
	}
}
 
$(document).ready(function() {	
	var myTask = new AjaxTask({
		url: "<%= ajaxtask_demo_url :task => :mytask %>",
		handler: new mytaskHandler(),
		taskStatusDiv: $("#taskStatus"),
		taskStatusLoadingMsg: 'Please wait while my task runs...',
		taskStatusLoadingImg: '/images/smallactivity.gif',
		taskStatusErrorMsg: 'Oops...something bad happened.'
	});
	myTask.start();
});
</script>
<div id="taskStatus"></div>
 
</body>
</html>

Looking at the above client code, you can see how easy it is to present a background task’s processing to a user.

That does it for now, I’ll try to document and post more soon abou AjaxTask.