Learning Ember.js and Rails Part 1 (of many!)

I’m starting on a new, massive, application. I don’t like to make things easy on myself so instead of doing this in my usual RoR/jQuery stack I am jumping in and doing this with:

• Ruby 2
• Rails 4
• Ember.js

This presents some challenges, not the least of which is Ember.js. I’ve never used a front end framework before. But I can see the power of it, plus, one of the key features of this new app is that it will provide a data api. With Ember.js, I believe, almost all interaction with the data will be through an api, so it seems like a good start and a way to sanity check what is coming in and out to other consumers of this api.

I know I suck at writing blog posts, but, I will try and document this journey because I have looked around and there doesn’t appear to be too many resources for people doing this. Everything I have found is much too simple and is not for the experienced Rails developer.

I did find one good resource from Tony Coconate (http://www.devmynd.com/blog/2013-3-rails-ember-js) and I am starting off from that. Now, that may or may not be a good idea!

Setup

I set up a new rails app. Then chucked some stuff into the Gemfile:

# front end
gem 'ember-rails'
gem 'ember-source'
gem 'ember-auth-rails'
gem 'ember-auth-source'

Create Resources

After, my first steps were to all but ignore the front end. 

I created my models as resources, like in Tony’s article. For example:

rails g resource Trainer name:string additional_info:text provider:references provider_key:string —no_helper

This means you end up with:

• a controller, 
• a model
• a serializer - from active model serializer
• a db migrate script 
• two coffee script views (trainer and trainers)
• entries in routes.rb

Moving Controllers

Again, as per Tony’s article, I am going to use Ember Data (whether or not it is ready for prime time now is not too important. This app won’t see the light of day for months yet). So, I move all the controllers from /app/controllers to /app/controllers/api/v1 and put Api::V1:: at the front. I also put in standard actions. So now my controller looks like this:

class Api::V1::TrainersController < ApplicationController
    respond_to :json

    def index
        respond_with Trainer.all
    end

    def show
        respond_with Trainer.find(params[:id])
    end
end

Modify Routes

I also modify routes.rb to look like this:

namespace :api do
    namespace :v1 do
        resources :trainers
    end
end

At this point I can point my browser at localhost:3000/api/v1/trainers.json and get a list (assuming I have data!) or to localhost:3000/api/v1/trainers/1.json to get the single record.

So far so good.

In my mind the data side of the app is on the way. I will not worry about any more Rails stuff for now.

Next is learning Ember.js 

HTTP Basic authentication with Rails for iOS

Recently I've been getting into iOS and developing a interesting iOS app (more info coming soon!)

But, as the app is all about showing data of course I needed to create an API in my rails app to feed that data. But, I didn't want someone else to be able to grab it.

The Rails App Side

Configure a custom MIME type

First thing I did was set up a custom mime type in initializers/mime_types.rb:

Mime::Type.register_alias "text/json", :theapp

That let me call urls like /give_me_data.theapp

Add the 'respond_to'

In the applicable controllers add a respond_to (well, I already had one, so add to it):

respond_to :html, :xml, :theapp

Make templates with json_builder

I luuuvvvvv the json_builder gem. So I created a whack of templates with the .json_builder extension. Because of the mime type setting it would automatically get called.

Add the http_authentication stuff

I am a little bit lazy, so, I just chuck this into my application_controller. That means that all :theapp requests need authentication:

protected
def http_basic_authentication
    if request.format == :ios
        authenticate_or_request_with_http_basic do |username, password|
            username == 'myAmazingApp' && password == 'theBestestPasswordEver'
        end
    end
end

The iOS app side

The URLs

Simply chuck your authentication stuff into your urls:

NSString *const RegionDataBaseURL = @"http://myAmazingApp:theBestestPasswordEver@localhost:3000/regions/%@.theapp";

Pulling...Data

I do my stuff like this (thanks to Ray Wenderlich):

  dispatch_async(kBgQueue, ^{
    NSURL *url = [NSURL URLWithString: [NSString stringWithFormat:RegionDataBaseURL, [self.region permalink]]];
    
    NSData* data = [NSData dataWithContentsOfURL: url];
    [self performSelectorOnMainThread:@selector(fetchedRegionData:)
                           withObject:data waitUntilDone:YES];
  });

Yes, I could also put the username and password in some other place and sub it into the URL, but brute force works for now.

Like I say, I am starting out in iOS so maybe this is too noddy for all you pros, but, it works.

The gotcha's in Node.js - or how I reduced our bandwidth by 75%

So, I have this great application that distributes, in pretty close to real time, information across hundreds of screens in Germany. It does this with a combination of Rails, Node.js and HTML/Javascript.
But we noticed MASSIVE traffic.
My model was to pump out the data and have intelligent pages decide what to show.
It turns out this is very inefficient.

Not ready for primetime

We have 4 'channels' of information. The software had originally been built on a 'tv station' idea. And, in TV, everything gets pumped down the line (or over the air) and then the tv 'tunes in' to a channel and shows the appropriate content.
In our case, we had a 'screen structure' message that was sent out once a minute and then in between each element on the screen would send out its own updates if it was altered.
It was the screen structure message that was the problem.

The old way

I was doing something like this on the page:

client.subscribe('/source', function(message) {
    window.setTimeout(function() {
        process_source_message(message);
    }, 1);
})

And in Node app.js I was doing this:

app.post('/source_state', function(req, res) {
    bayeux.getClient().publish('/source', req.body);
    res.send(200);
});

And in Rails, something like this:

RestClient.post [NODE_CONFIG[Rails.env]['node_url'], NODE_CONFIG[Rails.env]['source_update_path']].join('/'), JSON(json)

So, every page would get every 'source' message.

The new way

I realised that I should have the pages listen to their specific channel. I had got hung up in the past on the idea that I didn't know the name of the source in advance - it could be anything as it is user defined.

But, inside of the source JSON was already this:

json = {
    "source" => {"name" => source.slug}
}

It turns out I didn't need to change the back end (Rails) at all.

In the app.js I just needed

app.post('/source_state', function(req, res) {
    bayeux.getClient().publish('/'+req.body.source.name, req.body);
    res.send(200);
});

installing sunport_rails on ubuntu production

We've added search functionality to Toygaroo with Solr via sunspot_rails.

If you are going to install it on Ubuntu then make sure you do:

sudo apt-get install openjdk-6-jdk

First!

Using the html5 boilerplate and rails 3

I am experimenting with using the html5 boilerplate with rails 3.0x. It is an interesting setup. I am using Russ Frisch's html5 boilerplate template, but updating it to use the latest boilerplate code.

It seems to be a pretty nice way of getting your css and js ducks in a row. Over the next few days I need to see how it handles having jquery mobile in the mix. I am also not 100% sure how to use a some sort of grid layout template (like 960 or 114opx) with it. Or even if you should!

We shall see.

Suffering Rails3 slowdown

We've just pushed our Rails 3 upgraded app to production... and are suffering a massive slowdown in insert/update speed over Rails 2.

At the moment I am not sure of the exact cause of this.

It *might* be mysql inserts, though I can't quite see why that would be.

It *might* be because this new version we are using vestal_versions to track changes.

It might be because the moon is in the house of Mars for all I know!

I hate getting stung by unknowns. The speed on our test environment is tolerable, slightly slower than the rails 2 version, but I was willing to accept that because the new version is doing so much more.

Bench-marking is one thing.. but know why the bench marks are slower is the key!

Expiring fragments from daemons

We have an application that gets its data from a series of daemons that go out and read in data. This works great, except, we are caching pages. And I'd like to expire those pages based on an update.
It turns out that an Observer doesn't have access to expire_action or fragment. And a Sweeper is not called from data-only (i.e non-controller) updates! Buggers!

But there is a solution. You can call the sweeper directly from your importer:

MySweeper.instance.clean_up(model_instance)

This works, except I couldn't get it reliably to expire the actions. So, I used direct calls to Rails.cache.delete to do this.

Thinking about it, I guess I could then have just written an observer! As those do get called from controller-less updates.