I came across something interesting today, JSON can be parsed as YAML. In fact this is pointed out in the official YAML spec:

Both JSON and YAML aim to be human readable data interchange formats. However, JSON and YAML have different priorities. JSON’s foremost design goal is simplicity and universality. Thus, JSON is trivial to generate and parse, at the cost of reduced human readability. It also uses a lowest common denominator information model, ensuring any JSON data can be easily processed by every modern programming environment.

In contrast, YAML’s foremost design goals are human readability and support for serializing arbitrary native data structures. Thus, YAML allows for extremely readable files, but is more complex to generate and parse. In addition, YAML ventures beyond the lowest common denominator data types, requiring more complex processing when crossing between different programming environments.

YAML can therefore be viewed as a natural superset of JSON, offering improved human readability and a more complete information model. This is also the case in practice; every JSON file is also a valid YAML file. This makes it easy to migrate from JSON to YAML if/when the additional features are required.

This means we can take a JSON document and parse it with the YAML parse, for example:

1
2
3

require 'yaml'
json = '{ "robots": "on parade" }'
YAML.parse(json)

This snippet parses some JSON with the yaml parser. And it works!

This is interesting, and perhaps useful, if you’re storing configuration information or user settings. You could start off with JSON and migrate to a more human readable YAML file later with no changes in code.

This is a no non-sense, no steps skipped guide to getting an Ember.js app to a place where you can do unit test driven development. This guide picks up where The No non-sense Guide To Ember.js on Rails left off. It assumes you have a rails app running with Ember.js installed and working.

We’ll be using Jasmine for writing tests. Jasmine is a framework for writing specs that looks quite a bit like rspec. It’s easy to get up to speed in an afternoon writing Jasmine and it produces specs that are easy to write and easy to read. I think it’s enjoyable to work with.

To start, we’ll install jasmine in the app by adding a Gem called jasminerice:

group :development, :test do  
    gem "jasminerice", :git => 'https://github.com/bradphelan/jasminerice.git'  
end  

Jasminerice adds jasmine to the app and mounts the spec runner at http://localhost:3000/jasmine. It lets you use the asset pipeline to include your complete application into the test suite. This is part of what makes testing with Jasmine so painless.

After you’ve installed jasminerice, it needs to be bootstraped to get the files to the right place.

`rails g jasminerice:install`

If you fire up the app right now and navigate to localhost:3000/jasmine you’ll encounter an error. Jasminerice ships with an example spec, but it doesn’t work out of the box. It’s worth taking a look at the example spec if you’re curious, otherwise you can fix this by removing the sample: rm spec/javascripts/example_spec.js.coffee. At this point you have jasmine installed and running and your ready to begin test driven development.

The next step is to include our application into the jasmine testing environment. This is where the real power of jasminerice shines through. With one line, in spec.js.coffee, we can include our whole ember application. Just above require_tree ./ add require application.

Test Driving A Small feature

To help get into the flow of test driven development with Jasmine, let’s implement a small feature. We’ll create a person model with a first name and last name and then test drive writing a fullName method on the Ember model.

First, let’s scaffold out a person with a firstName and lastName:

rails g scaffold Person first_name:string last_name:string

Thanks to some cleverness in the ember rails gem, this also creates an ember model and views. Next we need to add our spec, create a new file in touch spec/javascripts/models/person_spec.js and add a spec that looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

describe("Person", function() {
  beforeEach(function() {
    Ember.testing = true;
  });

  describe("Full Name", function() {
    it('builds the full name from firstName and lastName', function() {
      Ember.run(function() {
        person = App.Person.createRecord({firstName: 'Nick', lastName: 'Rowe'});
        expect(person.get('fullName')).toEqual('Nick Rowe');
      });
    });
  });
});

This spec is fairly readable but there are two interesting pieces that you’re probably wondering about. The first is Ember.testing = true. Normally when Ember is running it has a runloop. This runloop causes all kinds of things to happen, however during testing we want to control the world as much as possible. Setting Ember.testing tells ember to halt the run loop. The next interesting piece is Ember.run. This is related to the Ember testing setting. We need the run loop to make one run all the way through to complete our test.

When you run the test you should now see something like this:

We are now ready to implement the feature. In app/assets/javascripts/models/person.js let’s add a new function for fullName:

1
2
3

  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName'),

Now when the tests are run again, we should see a screen like this:

That’s all there is to writing and running unit style tests for Ember.js using jasmine.

This is a no nonsense, no steps skipped guide to getting a new Rails app running the latest version of Ember.js.

First, make sure you have the latest version of Rails. While this isn’t strictly necessary to necessary to run Ember, there have been quite a few security vulnerabilities in Rails recently and you’ll sleep better knowing you have the latest and greatest. Run gem update rails and grab a coffee, updating takes a couple of minutes.

Now, let’s get into it. At the terminal, start a new rails app:

> rails new app

The name of your app is important because it’s what Ember will use for its namespace. For example if you call your Rails app photo_grid, then your ember namespace will be PhotoGrid. I’ve called the rails app, app. Since you’re usually building single page web apps with ember I like accessing Ember through the App namespace. It also makes sharing code between ember apps easier because App is a very common namespace.

Next, remove coffeescript from your Gemfile. You’re looking to delete the line that looks like this:

gem 'coffee-rails', '~> 3.2.1'

The ember-rails generators will take advantage of coffeescript if it’s present. In the interest of having a no nonsense guide, let’s stick with pure Javascript.

And now the we add the real star of the show, ember-rails. In your Gemfile, in the assets group add this line:

gem 'ember-rails', git: 'git://github.com/emberjs/ember-rails.git'

Back at the terminal, we’re now ready to install. Issue a bundle install to get ember-rails installed.

After ember is installed you need to tell Rails which version you’d like to use. Since we’re still not at 1.0, let’s use the development version. In your development.rb file add the following line at the end of the config section

config.ember.variant = :development

This sets ember to development mode and gives you, the developer, way more helpful error messages. If you’re planning to deploy this app to production, in you production.rb you should also add:

config.ember.variant = :production

Next, at the terminal, install the latest version of Ember:

rails g ember:install --head

And, again at the terminal, bootstrap your app with all of the appropriate folders and file:

rails g ember:bootstrap

We’ve just walked through all of the steps you need to get Ember installed in your app. You’ve created a blank rails app, installed the latest version of ember, and created the directory structure and included the appropriate library files for Ember. Now it’s time to actually see Ember running on the page.

We’ll start by creating a controller and index action at the terminal:

rails g controller static index

Then in config/routes.rb adding the following line to route “/” to the newly created controller and action:

root :to => 'static#index'

And then, finally, remove public/index.html with rm public/index.html.

Now, ember is installed and available on the root on the site. Start up rails (rails server) and navigate to your http://localhost:3000 and pop open the developer console. You should see something like:

DEBUG: ——————————-
DEBUG: Ember.VERSION : 1.0.0-rc.1
DEBUG: Handlebars.VERSION : 1.0.0-rc.3
DEBUG: jQuery.VERSION : 1.9.1
DEBUG: ——————————-

It’s possible you’ll see a warning: Uncaught Error: Error: The Ember Data library has had breaking API changes since the last time you updated the library. Please review the list of breaking changes at https://github.com/emberjs/data/blob/master/BREAKING_CHANGES.md, then update your store's revision property to 12. You can solve that by updating app/assets/javascripts/store.js to look like this:

1
2
3

App2.Store = DS.Store.extend({
  revision: 12
});

Ember JS is now setup in your Rails app. We covered a lot of ground here, we created a new rails app; add ember rails; added the latest version of ember; bootstrapped the app; and fixed a common error with ember data.

As much as I love tweaking my dotfiles, I’ve also been making some changes in my physical workspace. I’m working on the ever evolving project of creating a place that is comfortable and productive- physically and digitally. I recently acquired some neat momentary switches with white LED rings. They remind me a little of Tron.

This evening, I wired three of them into the top right of my desk. My goal is to use them to control the lighting around the desk and around the house.

Here’s all 3 buttons on:

Next step is to get these guys wired and on the network. Here are the options I’m considering:

• The arduino + wifi shield
• The raspberry Pi
• The arduino + zigbee shield
• The beaglebone

I’ll try to post an update when I get deeper into the project.

Ember.js is all the rage right now, here are some of the resources I’ve found helpful:

Watching

• Peepcode Fire Up Ember.js: A 90 minute run through building an ember app. It was built with the ember core developers, so you know it’s good. The app built is used a test case by the ember team for API stability, the app will work through the entire 1.x series of ember releases. If you learn by watching, this is awesome.
• Railscasts Ember Part 1 & Ember Part 2 - Ryan Bates of Railscasts takes a tour of ember. The screencasts are shorter and more to the point.

Reading

• Master Space and Time with Javascript: Book 4, Ember - Noel Rappin works through build a time travel booking agency admin interface with ember. The book is still being written as of the end of March 2013 but is well thought out for the 60 pages that are there. I worked through the entire tutorial, and although there typos, I walked away with a clearer understanding of how ember works. If you learning by reading, this is the best resource right now.

• Why Discourse uses Ember.js: A discussion of why Discourse, the community forum software, chose to use ember. See also: HN Followup to: Why discourse uses Ember.js

• Ember.js and Accessibility: From Steve Klabnik, it turns out that the Discourse Ember app has decent accessibility.

This is a post about Spirit, an open source internet of things hub that I’m building. Want to know more about it (It’s pretty neat)? Check out my Welcome to Spirit post which is all about my vision for spirit.

Spirit is built on top of a message bus for sharing information about events and intended actions. Here’s my current architectural thinking:

Events

Events are sent into the message bus when something happens. This can be anything: the user posts to facebook, a door opens, the sun sets, the time becomes 6:30AM, a calendar event happens, and so on. When any of these actions occur a message is sent into the bus that something happened with details of exactly what happened. For example Facebook might fire events.facebook.statusUpdated with the arguments of what the new status is. All events should include a timestamp of when they happened.

Intents

Intents are how the system indicates that it would like something done. The system might intend to activate a preset, turn off a specific light, open the shades, post of twitter, send an email, or send an SMS. These intents are fired into the message bus with any parameters necessary to make them happen. To post to twitter an intent would be fired into the bus with intent.twitter.tweet with parameters for the message to be tweeted.

The neat thing about intents is that the system that intends for an action to occur doesn’t need to have any knowledge of the system that is performing the action. With the twitter example, I may write a program in ruby which is capable of fulfilling the tweet intent. Another author may write a twitter program in clojure. Since they both understand the intent system, they can both listen on the bus. The user of the system would probably want to avoid having two intent programs doing the same thing, but it is a possibility.

Another interesting things about intents is that they are safe to fire them even if no one is listening. For example in writing a sleep module for spirit I may write a piece of code that 30 minutes before bedtime warms the color of the lights, turns off the internet, fades up some music, and sends a twitter message. Each of these pieces would be fired as an intent. If the user doesn’t want a tweet going out at bedtime then it would be as easy as not having any twitter programs on the bus to fulfill the intent.

The Trigger Engine

The trigger engine is a program who’s sole purpose is to turn events into intents. It stores information about what should happen when a specific event occurs. For example, the trigger engine would listen for the events.time.sunset event and then fire the intents.spirit.activatePreset intent. This could turn on all of the lights in the house when the sun has set. Since the trigger engine just needs to worry about events occurring on the bus, it’s free to stay very small and simple.

Computed Events

One piece of spirit I haven’t talked too much about, yet, is called Memor. Memor is a piece of code that records all events that occur on the bus and decides what they mean. No motion events in the house for hours, then the door unlocked, then motion means that someone is home. Memor is responsible for looking at the events, figuring out that someone is home and then firing a computed event, events.arriveHome. Memor might then further receive an event that Nick’s phone just joined the Wifi network so it’s probably Nick that is home. That might in turn fire another event. These computed events are very useful in the trigger engine.

For the past several months I’ve been developing an open source Internet of Things hub that I call Spirit. The coolest thing about Spirit also makes it the hardest to explain: Spirit is a platform that enables devices to communicate, coordinate and help make your environment better suited to you. It brings together your digital life with your physical environment to help you be your best. And that’s personal, so spirit is built to be modular and work with the way that you live.

Spirit works with the things that are all around you: your TV, lights, media center, locks, thermostat, and more. It enables all of these things to communicate with each other and coordinate their actions. Perhaps when your front door closes and you’ve left you’d like your lights to turn off. Or maybe you’d like the heat to come on at 7AM, the lights to dim up, and the coffee to start, all without you lifting a finger: a perfect morning.

Spirit lets all of the inputs in your life find a place in a central system. Your lights can react to the time, or when you enter a room the music could gently fade up. Spirit enables these kind of communications. Spirit could help you establish new patterns by checking the status of your pedometer (like FitBit, Jawbone’s Up, or Nike’s Fuelband) and limit the amount of TV you can watch until you’ve exercised. Spirit enables you to use your environment to help establish new habits.

Spirit is a platform that has tons of possibilities, so here are a few of the modules that I’m excited about building (and using):

Spirit can be the ultimate sleep coach. At bedtime the system can create an artificial sunset in the house, dimming and yellowing the color of the lights to naturally encourage you to sleep. It can set the temperature to be just right for sleeping and provide a sense of security knowing all of the windows are closed and doors locked. In the morning Spirit can dim up the lights over a long period of time to simulate the sunrise and wake you gently with a fading alarm clock.

Spirit can be the ultimate remote control. When it comes time for a movie just press play and the lights will automatically dim down. Pause the movie and they come back up. If you receive a call during the movie it can automatically pause and bring the lights up.

Spirit can make sure that your house is comfortable and well lit when you return from a day at work, preventing you from fumbling with your house keys in the dark or wastefully leaving the lights on all day. Your home is ready and waiting for you.

One of the thing that keeps people up at night is worry about their home. Spirit always has your back. It can make sure your home is secure, even when you’re not there. Lights can automatically turn on and off. You can check that the doors are locked and your home secure. You could receive a text if a door opens at an unexpected time. But security isn’t just about when you’re away from home. Spirit could notify you if there’s an extreme weather warning, perhaps turning on all of the lights and playing an alert sound.

Is it ready now?

Not quite yet, Spirit is still actively in development but it isn’t ready for use yet. It’s a ruby open source project and is available at the github page for spirit.

In my previous post I looked at why Observers don’t work with the normal object lifecycle events in Toy::Store. But does that mean that it’s impossible to use observers with Toy::Store objects? Definitely not!

The maintainer of Toy::Store feels that Observers are an application concern, so let’s take a look at how to integrate observers with your application code. The example I’ll be walking through is from spirit, the internet of things hub I’m working on. In that project that is a class called Preset. A preset is a set of settings for a group of devices. For example a preset might contain settings for a kitchen light at 100%, dining room light at 50% and squeezebox playing. You, as a user, want to apply that preset.

Whenever a preset is applied, I’d like an event fired into the message bus. Firing messages isn’t a core concern of presets. Presets should just represent state and be able to apply that state. Also, to change how the event is fired into the bus I shouldn’t have to change how a preset works. For these reasons, I believe that an observer is a fit here.

The first step is to create the observer:

1
2
3
4
5
6
7
8
9

class PresetEvents < ActiveModel::Observer
  observe :preset

  def after_apply(preset)
    puts "Preset #{preset.id} applied!"
  end
end

PresetEvents.instance

The preset needs to be a subclass of ActiveModel::Observer. This is where all of the default behavior comes from. We also need to indicate which class is being observed (observe :preset) because the name of the observer class doesn’t match the name of the observed class.

The only unusual thing is the PresetEvents.instance at the end. If you were creating an observer in Rails this would happen automatically when the app is loaded. An observer is a singleton and doesn’t exist until someone explicitly asks for it. By getting the instance right after the observer is loaded we ensure that there is an instance and it is listening to the correct class.

Now, to make a Toy::Store object observable we need to include the include ActiveModel::Observing module and notify the observer when an event we care about occurs:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Preset
  include Toy::Store
  include ActiveModel::Observing

  # ...

  def apply
    devices.each do |device|
      device.update_attributes(target_value[device.id])
    end
    self.class.notify_observers(:after_apply, self)
  end

  # ...
end

And there you have, using observers with Toy::Store. If you wanted to hook an observer into the save event you would do something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class Preset
  include Toy::Store
  include ActiveModel::Observing

  after_save :notify_observers_save_occured

  # ...

  private

  def notify_observers_save_occured
    self.class.notify_observers(:after_save, self)
  end

  # ...
end

Toy::Store and Observers can definitely play well together, you just need to manage it yourself.

This is an in-depth look at an issue with ToyStore, a ruby persistence library. I wanted to make an Toy::Store Object observable, like Active::Record Objects but that currently isn’t possible.

ToyStore doesn’t currently work with Observers because it uses plain code to define callbacks. In Rails, code in Active Record notifies observers. If Toy Store is going to work observers it will involve writing some code, probably patterned after the Active Record, to notify observers.

Curious about how all of this works and fits together? Let me take you through how the ToyStore’s code currently works, how Active Model defines callbacks, and finally how Active Record code notifies observers.

We start with Toy::Store. In lib/toy/store.rb there is an included module called Callbacks. In that callback module, lib/toy/callbacks.rb, callbacks defined for save, create, update, and destory:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

module Toy
  module Callbacks
    extend ActiveSupport::Concern

    included do
      extend ActiveModel::Callbacks
      define_model_callbacks :save, :create, :update, :destroy
    end

    def save(options={})
      run_callbacks(:save) { super }
    end

    def destroy
      run_callbacks(:destroy) { super }
    end

    private

    def create
      run_callbacks(:create) { super }
    end

    def update
      run_callbacks(:update) { super }
    end
  end
end

A few more things to note about the callbacks module. It extends ActiveModel::Callbacks and define the callbacks using define_model_callbacks. That takes us next to ActiveModel::Callbacks. Specifically, the interesting method is the one is define_model_callbacks:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# File activemodel/lib/active_model/callbacks.rb, line 100
def define_model_callbacks(*callbacks)
  options = callbacks.extract_options!
  options = {
     :terminator => "result == false",
     :scope => [:kind, :name],
     :only => [:before, :around, :after]
  }.merge(options)

  types = Array.wrap(options.delete(:only))

  callbacks.each do |callback|
    define_callbacks(callback, options)

    types.each do |type|
      send("_define_#{type}_model_callback", self, callback)
    end
  end
end

The key piece of code here is the one that loops through each of the callbacks (callbacks.each) and define’s the callback (define_callbacks). define_callback is a method from ActiveSupport::Callbacks:

1
2
3
4
5
6
7
8
9

# File activesupport/lib/active_support/callbacks.rb, line 616
def define_callbacks(*callbacks)
  config = callbacks.last.is_a?(Hash) ? callbacks.pop : {}
  callbacks.each do |callback|
    class_attribute "_#{callback}_callbacks"
    send("_#{callback}_callbacks=", CallbackChain.new(callback, config))
    __define_runner(callback)
  end
end

The actual code is not so much important here, as the location of the file. This define_callbacks comes from activesupport.

Now, on to ActiveRecord. ActiveRecord also defines an observer:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

module ActiveRecord
  class Observer < ActiveModel::Observer

   protected

   #...
      def define_callbacks(klass)
          observer = self
          observer_name = observer.class.name.underscore.gsub('/', '__')

          ActiveRecord::Callbacks::CALLBACKS.each do |callback|
              next unless respond_to?(callback)
              callback_meth = :"_notify_#{observer_name}_for_#{callback}"
              unless klass.respond_to?(callback_meth)
                  klass.send(:define_method, callback_meth) do |&block|
                      observer.update(callback, self, &block)
                  end
                  klass.send(callback, callback_meth)
              end
          end
      end
  end
end

The interesting thing here is that ActiveRecord doesn’t use activesupport’s define_callbacks. Instead, it defines its own version. The most interesting part to us is: observer.update(callback, self, &block). So, it’s ActiveRecord that is doing the hard work of notifying the observers. Another interesting thing to note, ActiveRecord is only making events that it knows about in ActiveRecord::Callbacks::CALLBACKS observable.

Because ToyStore extends ActiveModel it doesn’t get the ability to observe on the normal object lifecycle events. To fix this, ToyStore will have to implement something similar to ActiveRecord. The downside is that Toy::Store Objects will have to check if they are observable or Toy Store will have to dictate that all objects are observable.

Ever accidentally commit some code, push it, and then find out that there were failing specs? Ouch, me too. I’ve got some good news, though: Git has the ability to run a script before it allows code to be committed through Git Hooks. With this ability we can run our specs before the code is committed and only the commit if the specs pass.

In every git project you can edit the pre-commit-hook by editing .git/hooks/pre-commit.

Here’s my pre-commit hook:

1
2
3
4
5
6
7
8
9
10
11
12
13

#!/bin/sh

branch=`git rev-parse --abbrev-ref HEAD`

if [ $branch == 'master' ]; then
  exit_code=$(bundle exec rspec --fail-fast --out /dev/null --format progress > /dev/null 2>/dev/null )$?
  if [ $exit_code -gt 0 ]
    then echo "Did not Commit because of failing tests"
  fi
  exit $exit_code
fi

exit 0

This fairly small script checks the current branch, saves it to a variable and the only runs the specs if we’re on master. If the specs fail then a message is output, otherwise the code is committed.

One last thing, you can skip running the specs and commit like this: git commit --no-verify