First, create a Cycler class. (Using a Batman object for this is probably overkill, but it does give me one more opportunity to type 'Batman'.)

MyApp.Cycler extends Batman.Object
  isObservable: false
 
  constructor: (@values) ->
    @values = @values.split(',') if typeof @values is 'string'
    @idx = -1
 
  reset: ->
    @idx = -1
 
  next: ->
    @idx = (@idx + 1) % @values.length
    @values[@idx]

Now we create the mixin...

# Use a global property to hold the cycler, which holds the state
Batman.mixins.cycler =
  initialize: ->
    $node = $(@)
    cyclerName = "cycler-#{$node.data('cycler-name')}"
    MyApp.getOrSet(cyclerName, => new MyApp.Cycler($node.data('cycler-values')))
    $node.addClass(MyApp.get(cyclerName).next())

Now, to use it in your template, you can do something like this:

<ul>
  <li data-foreach-post="posts" data-mixin="cycler" data-cycler-values="left,right" data-cycler-name="all-posts">
    <a data-route="post" data-bind="post.title"></a>
  </li>
</ul>

Which would render to something like this (leaving out the batman tags for clarity)

<ul>
  <li class="left">
    <a href="/posts/1">Post 1</a>
  </li>
  <li class="right">
    <a href="/posts/2">Post 2</a>
  </li>
  <li class="left">
    <a href="/posts/3">Post 3</a>
  </li>
</ul>

So, that's it. As you can see we have to create some global properties, and name them, so that we can have multiple cyclers in the app without conflict. This does bother me a bit, but there are plenty of other dragons to slay, so it will have to do for the time being.

The magic incantations (for OSX at least) go something like this:

brew install stunnel

Now, the default .pem file that stunnel created for me didn't work, so let's create our own:

openssl req -new -x509 -days 9999 -nodes -out /usr/local/etc/stunnel/stunnel.pem -keyout /usr/local/etc/stunnel/stunnel.pem

Verify the .pem file with this command:

openssl x509 -subject -dates -fingerprint -in /usr/local/etc/stunnel/stunnel.pem

If everything checks out, lets now create a config file for stunnel that will proxy https connections from port 443 on localhost to http connections to port 80 on localhost.

tee /usr/local/etc/stunnel/stunnel.cnf <<ENDOFFILE
pid        = /tmp/stunnel.pid
setuid     = nobody
setgid     = nobody
foreground = yes
client     = no
[https]
cert = /usr/local/etc/stunnel/stunnel.pem
accept = 443
connect =  80
ENDOFFILE

Now all that is left to do is fire it up:

sudo stunnel

Go here and you should see your pow server.

To accomplish this, Ryan Funduk and I recently came up with this approach. First we will leverage the Rails asset pipeline to create a json file that contains all of our app's views.

/app/assets/javascripts/all_views.json.erb

<%=
  prefix = "#{Rails.root}/app/assets/javascripts/views"
  paths = Dir.glob("#{prefix}/**/*").select{|f| File.file?(f) && (f =~ /\.(html|erb)$/i) }
  paths.inject({}) do |all_views, f|
    viewname = f.sub( /^#{prefix}/, '' ).sub( /\..*$/i, '' )
    view = File.read(f)
    view = ERB.new(view).result if f =~ /\.erb$/i
    all_views[viewname] = view
    all_views
  end.to_json
%>

Now, if you go to http://localhost:3000/assets/all_views.json you should see all your views in one large json object. Note that your Batman views will be processed through ERB, so if you need the server to do some processing, go right ahead. (Just remember that the ERB code will be run only once, when the views are compiled, not each time they are requested.)

Next, tell the Rails asset pipeline to precompile this file, like so:

/config/environments/production.rb

config.assets.precompile += %w(all_views.json)

Next, we write a Batman helper that will request the all_views.json file, and create Batman views for each of the individual views. That looks like this:

/app/assets/javascripts/helpers/views_preloader.js.coffee.erb

MyApp.preloadViews = () ->
  new Batman.Request
    url: '<%= asset_path("all_views.json") %>'
    type: 'json'
    error: (response)  -> throw new Error("Could not load views")
    success: (all_views) =>
      for view of all_views
        Batman.View.store.set(view, all_views[view])

Note that we run this file through ERB first, so that we get the proper path (including the digest, if applicable) to the all_views file. The last line pre-populates the view store with each of the views. (You will need to be on the master Batmanjs branch, as the View store is a new addition since the 0.8 release).

The last thing we need to do is kick off the preloader, and a good place to do that is like so:

/app/assets/javascripts/application.js.coffee

window.MyApp = class MyApp extends Batman.App
 
  @on 'run', ->
    MyApp.preloadViews()

So, putting it all together, when your Rails app is deployed and the assets are precompiled, the asset pipeline will write out an all_views-1234.json file to the public/assets directory. On the client side of things, when your Batman app starts, it calls the preloader, which loads the all_views-1234.json file and creates Batman views for them all in one fell swoop. The really cool thing about this setup is that the Rails asset pipeline takes care of caching the views for you. Winning!

- John Lynch
@johnrlynch

But, when doing development, I like to make sure the app will run outside of Torquebox as well, with a simple 'rails s', so here are a few tricks to make that happen.

When setting Torquebox-specific features, like for example setting the Rails cache store to Infinispan, do this:

config.cache_store = :torque_box_store if defined?(TorqueBox)

That way, when you run outside of Torquebox, Rails will use the default file cache and all will be well.

Another great Torquebox feature is the ability to mark any method as backgroundable, and the JVM will transparently spin off that method in a new thread. You accomplish that with this code:

class Battlestar
  include Backgroundable
  always_background :fire
 
  def fire
    ...
  end
end

This of course will cause problems when running without Torquebox, so if you add this shim into your initializers, the method will just run in the foreground like normal.

unless defined?(Torquebox)
  module Backgroundable
    extend ActiveSupport::Concern
    module ClassMethods
      def always_background(method)
      end
    end
  end
end

Another technique I use, especially for accessing the Torquebox message queues, is make sure you use your own class as a central point of control, like this:

class QueueManager
  include TorqueBox::Injectors if defined?(TorqueBox)
 
  def publish_weapon_event(event)
    @weapon_queue ||= inject("/queues/myapp/weapon_events") if defined?(TorqueBox)
 
    if @weapon_queue
      @weapon_queue.publish(event)
    else
      processor = WeaponEventProcessor.new
      processor.on_message(event)
    end
  end

So, when running inside Torquebox, the message gets sent to the queue, which would then at some point in the future execute the event processor, but when running under Webrick, it calls the event processor directly.

 
body = ActionView::Base.new(Rails::Configuration.new.view_path).render(:file => "/orders/receipt.html.erb",:layout => false,:locals=>{:order=>order})

In Rails3, the same thing can be accomplished with this incantation:

av = ActionView::Base.new()
av.view_paths = ActionController::Base.view_paths
av.extend ApplicationHelper #or any other helpers your template may need
body = av.render(:template => "orders/receipt.html.erb",:locals => {:order => order})

Basically, it is a wrapper around the standard Titanium.Network.HTTPClient API, except that we cache the results of each request in a local SQLite database table, and use that for subsequent requests until the cached record expires. The cache key is a hash of the full URL (plus any data parameters for POSTs).

For an example (written in CoffeeScript), we can create a new instance of the class to connect to the CNN RSS news feeds:

  Ti.include("HTTPClientWithCache.js")
  cnn = new root.HTTPClientWithCache({
    baseURL: "http://rss.cnn.com/rss",
    retryCount: 2,
    cacheSeconds: 60,
    onload: (response) ->
      Ti.API.debug("Response Data: #{response.responseText}")
      Ti.API.debug("Is this cached data?: #{response.cached}")
      Ti.API.debug("Cached at: #{response.cached_at}")
  })

Each time we want to make the request, we say:

  cnn.get({url: "/cnn_topstories.rss"})

The response will either come from the cache, if it has not expired, or from cnn.com. Because we set the retryCount property to 2, if the first attempt to fetch the data over the network fails (meaning any HTTP status code > 400) it will automatically try again a second time. If that fails, then it will respond with the most recent version available in the cache, or null if nothing exists in the cache. The response object also has a cached property of true for anything served out of the cache, and a cached_at property of the timestamp the record was cached.

You can use the same object to make calls to other URLs as well, like so:

  cnn.get({url: "/cnn_us.rss"})

If you need to pass parameters (like for pagination) you can say:

  cnn.get({url: "/cnn_us.rss?page=1"})

To POST data to a URL, do this:

  cnn.post({url: "/story/19912/edit", data: {param1: "value1", param2: "value2"}})

To manually prune the cache, you can call the prune_cache method, and anything older than seconds will be
deleted from the cache. For example, to remove anything older than 1 day (86,400 seconds) you would say this:

  cnn.prune_cache(86400)

To completely clear the cache of every single entry, you can do this:

  cnn.prune_cache(0)

The code is on GitHub as a gist here. For pointers on how to build Titanium apps using the incredible CoffeeScript instead of Javascript, see our previous blog post here.

We have been using Titanium to build mobile apps for some time now. It is truly amazing how much more productive we are as opposed to when we use POOC (Plain Old Obj-C). Granted, Titanium is not a great fit for some applications, but for your standard network and data-heavy line of business applications, it rocks.

But, Titanium does not give you a lot of guidance on how you should write your app. They provide all the pieces you need, but folks are still figuring out the best way to structure things. So, we thought we would show you our particular technique for putting together a Titanium mobile app.

The first thing we did, was ditch Javascript. To be honest, something about it just makes our eyes bleed. Fortunately, jashkenas has come to our rescue with a Ruby-like language that compiles down to Javascript, called CoffeeScript. CoffeeScript makes Javascript a joy to use, and because it "compiles" to plain ole' Javascript, you can use it anywhere, including Titanium. (Basically, you run the command "coffee -w -c *.coffee" in whatever directory your files are in, and it continually watches for any changes and immediately compiles the *.coffee into a *.js file.) So to be clear, you are only ever referencing the .js files in your Titanium project, Titanium doesn't know anything about CoffeeScript or how to parse/use it.

One interesting thing CoffeeScript does, is compile each CoffeeScript file into its own namespace inside an anonymous Javascript function. This is great, because it isolates each file and prevents you from polluting the global namespace. For example, this CoffeeScript code:

show_flag = true
alert "Hello World!" if show_flag

gets translated into this Javascript code:

(function() {
  var show_flag;
  show_flag = true;
  if (show_flag) {
    alert("Hello World!");
  }
})();

Another thing CoffeeScript enables, is an easier-on-the-eyes way to creates "classes", for example (from the CoffeeScript docs):

class Animal
  constructor: (@name) ->
 
  move: (meters) ->
    alert @name + " moved " + meters + "m."
 
class Snake extends Animal
  move: ->
    alert "Slithering..."
    super 5
 
class Horse extends Animal
  move: ->
    alert "Galloping..."
    super 45
 
sam = new Snake "Sammy the Python"
tom = new Horse "Tommy the Palomino"
 
sam.move()
tom.move()

(If you really want to see what that gets translated to, put on some shades and click here.)

var Animal, Horse, Snake, sam, tom;
var __extends = function(child, parent) {
    var ctor = function(){};
    ctor.prototype = parent.prototype;
    child.prototype = new ctor();
    child.prototype.constructor = child;
    if (typeof parent.extended === "function") parent.extended(child);
    child.__super__ = parent.prototype;
  };
Animal = function(_a) {
  this.name = _a;
  return this;
};
Animal.prototype.move = function(meters) {
  return alert(this.name + " moved " + meters + "m.");
};
Snake = function() {
  return Animal.apply(this, arguments);
};
__extends(Snake, Animal);
Snake.prototype.move = function() {
  alert("Slithering...");
  return Snake.__super__.move.call(this, 5);
};
Horse = function() {
  return Animal.apply(this, arguments);
};
__extends(Horse, Animal);
Horse.prototype.move = function() {
  alert("Galloping...");
  return Horse.__super__.move.call(this, 45);
};
sam = new Snake("Sammy the Python");
tom = new Horse("Tommy the Palomino");
sam.move();
tom.move();

So, when using CoffeeScript in Titanium apps, we can use these two features to help us structure things in a way that keeps each window isolated in its own namespace, yet allows us easy access to global objects as well. To start, we set up our app.js file, which Titanium runs on app startup. We keep this file as a plain Javascript file, and define a variable called 'root', to which we will attach anything that we want access to globally. We also include each window's CoffeeScript file (well, technically we include the Javascript file that the CoffeeScript file was translated into). Finally, we include a 'main' file, which sets up the main tab group and kicks everything off.

//app.js
var root = {};
Ti.include('js/generic_window.js');
Ti.include('js/main.js');

In the generic_window.coffee file, we create a class definition for a generic window, and actually create a Titanium window in the constructor. We then attach the class definition to the root object so we can get at it from anywhere.

#generic_window.coffee
class GenericWindow
  constructor: (theTitle, theText) ->
    @win = Ti.UI.createWindow({title:theTitle,backgroundColor:'#fff'})
    label = Titanium.UI.createLabel({
      color: '#999',
      text: theText,
      font: {
        fontSize: 20,
        fontFamily: 'Helvetica Neue'
      },
      textAlign: 'center',
      width: 'auto'
    })
    @win.add(label);
 
root.GenericWindow = GenericWindow

Now the main file sets up the tabgroup, and actually instantiates some windows from the above generic window class...

#main.coffee
tabGroup = Titanium.UI.createTabGroup({	barColor:'#336699'})
Titanium.UI.setBackgroundColor('#000')
 
# Attach the window instance to root so we can get to it from anywhere 
root.Win1 = new root.GenericWindow('Win1','I am Window 1')
 
tab1 = Titanium.UI.createTab({
  icon:'KS_nav_views.png',
  title:'Win1',
  window: root.Win1.win
})
tabGroup.addTab(tab1)
 
# Attach the window instance to root so we can get to it from anywhere 
root.Win2 = new root.GenericWindow('Win2','I am Window 2')
 
tab2 = Titanium.UI.createTab({
  icon:'KS_nav_views.png',
  title:'Win2',
  window: root.Win2.win
})
tabGroup.addTab(tab2)
 
tabGroup.open({transition:Titanium.UI.iPhone.AnimationStyle.FLIP_FROM_LEFT})

Now, let's add a custom property to our generic window class, so add this line to the constructor of generic_window.coffee:

    @custom1 = "Default Value"

This creates a property and gives it a default value. To access it, you could say "root.Win1.custom1". Now let's add an event handler that displays an alert box containing the value of @custom1:

#generic_window.coffee
class GenericWindow
  constructor: (theTitle, theText) ->
    # Save off the context of this object to a local var 'self'
    self = this
    @custom1 = "Default Value"
    @win = Ti.UI.createWindow({title:theTitle,backgroundColor:'#fff'})
    label = Titanium.UI.createLabel({
      color: '#999',
      text: theText,
      font: {
        fontSize: 20,
        fontFamily: 'Helvetica Neue'
      },
      textAlign: 'center',
      width: 'auto'
    })
    @win.add(label);
 
    @win.addEventListener('click', () ->
      alert(self.custom1)
    )
 
root.GenericWindow = GenericWindow

If you would like to see how it all hangs together, clone the GitHub repo here and try it out. The bottom line is that before CoffeeScript, our Titanium apps tended to resemble spaghetti, but now we are able to encapsulate functionality and just generally make things look much cleaner. Sure, you don't need CoffeeScript to do this, but it sure makes it a lot more fun!

Here is the proof-of-concept:

require 'rubygems'
require 'sinatra'
require 'typhoeus'
 
OPTIONS = {}
OPTIONS[:riak_host] = "localhost"
OPTIONS[:riak_port] = "8098"
OPTIONS[:es_host] = "localhost"
OPTIONS[:es_port] = "9200"
OPTIONS[:riak_timeout] = 5000 # milliseconds
OPTIONS[:es_timeout] = 5000 # milliseconds
 
class Rack::Proxy
 
  def initialize(app)
    @app = app
    @hydra = Typhoeus::Hydra.new
  end
 
  def call(env)
    req = Rack::Request.new(env)
    # We need to use it twice, so read in the stream. This is an obvious problem with large bodies, so beware.
    req_body = req.body.read if req.body 
 
    riak_url = "http://#{OPTIONS[:riak_host]}:#{OPTIONS[:riak_port]}#{req.fullpath}"
 
    opts = {:timeout => OPTIONS[:riak_timeout]}
    opts.merge!(:method => req.request_method.downcase.to_sym)
    opts.merge!(:headers => {"Content-type" => req.content_type}) if req.content_type
    opts.merge!(:body => req_body) if req_body && req_body.length > 0
 
    riak_req = Typhoeus::Request.new(riak_url, opts)
    riak_response = {}
    riak_req.on_complete do |response|
      riak_response[:code] = response.code
      riak_response[:headers] = response.headers_hash
      riak_response[:body] = response.body
    end
    @hydra.queue riak_req
 
    # If we are putting or posting JSON, send a copy to the ElasticSearch index named "riak"
    if (req.put? || req.post?) && req.content_type == "application/json" 
      req.path =~ %r{^/riak/([^/]+)/([^/]+)}
      bucket, key = $1, $2
      es_url = "http://#{OPTIONS[:es_host]}:#{OPTIONS[:es_port]}/riak/#{bucket}/#{key}"
      opts = {:timeout => OPTIONS[:es_timeout]}
      opts.merge!(:method => req.request_method.downcase.to_sym)
      opts.merge!(:body => req_body) if req_body  && req_body.length > 0
      es_req = Typhoeus::Request.new(es_url, opts)
      es_response = {}
      es_req.on_complete do |response|
        es_response[:code] = response.code
        es_response[:headers] = response.headers_hash
        es_response[:body] = response.body
      end
      @hydra.queue es_req
    end
 
    # Concurrently executes both HTTP requests, blocks until they both finish
    @hydra.run
 
    #If we wrote to ES add a custom header
    riak_response[:headers].merge!("X-ElasticSearch-ResCode" => es_response[:code].to_s) if es_response && es_response[:code]
 
    #Typhoeus can add nil headers, lets get rid of them
    riak_response[:headers].delete_if {|k,v| v == nil} 
 
    # Return original Riak response to client
    [riak_response[:code], riak_response[:headers], riak_response[:body]]
  end
end
 
use Rack::Proxy

(Gist here)

Execute the script, and it will listen on port 4567, so point your Riak client of choice there and start PUTing data, which will be seamlessly replicated into the ElasticSearch cluster. If we were really going to use this in anger, there is a lot of work yet to be done, but as a skeleton of how to use Sinatra (Rack, really) to quickly whip up custom proxys, and tee HTTP requests, I thought it might be useful.