Day 11: The Story So Far

[vimeo vimeo.com/29384777]

Teams share what they’ve done so far as the two week challenge draws to an end.

From the beginning, the Android, Windows 7 and iOS teams each prioritized particular elements over others, such as UI, design standards or creating a mock database.  Now they must round out their efforts by re-focusing on new areas.  In most cases, the last step is integrating with Inspire’s API.  Victor, Mark, Sung, Chris, Ryan and Ray share their progress in their own words.

As the apps reach completion, we’ll announce it on the blog.  Hopefully we can get a few screen cast demonstrations in too.

Final Recap pending upon Challenge completion!

Advertisements

Day 3: Windows 7 and Inspire API

Last Thursday, Zach Dennis and the Windows 7 team stayed late.  Here’s a short video from the evening.

[vimeo vimeo.com/28945503]

 

As an aside, it’s good to see that one of our goals, working with new partners, is already a success.

These teams have paired people I’ve never seen together before.  It’s refreshing to see how different dynamics can achieve different goals within a company.  And since unlikely partners don’t have the same deeply engrained practices and expectations of each other, it’s easier for individual team members to shake their own habits.  New project + new partners sometimes means a lot more room to grow.


Day 5: Exploring Inspire’s Server-Side API w/Zach

It’s best to keep the API representation of an object separate from the object itself so even though Rails provides #as_json and #to_json methods. It can be tempting to use them, to evolve them, and to build around them, but in my experience it’s best avoid them.

APIs dont’t usually consist of all of the data that are housed in your system, so you need to selectively choose what to support on a public API. And then you need to be able to support versioning the API, permissions of what data can be seen, etc. I recently heard about Grape so I decided to give it a look.

Grape is a micro-framework for creating REST-like APIs, but it primarily appears to help with organizing API route/endpoint definitions. After a short spike it wasn’t solving my primary concern: cleaning how the API content is generated simple, clean, and as close to the end-point as possible. So I decided to explore rabl.

Rabl is a Ruby API templating language. This means that rather than using erb or haml to write your APIs, you write rabl templates. At first the syntax seemed a little strange, so I decided to spike on representing an endpoint which involved multiple objects and required nesting. Here’s two example rabl files from the spike.

First, the index template:

# index.json.rabl
object false
code(:people) do |m|
  @contacts.people.map do |c|
    partial("api/v1/contacts/_person", \:object => c)
  end
end

And the partial used for representing a person:

# _person.json.rabl
object @person
attributes :id, :first_name, :last_name, :title, :dob, :gender, :about

code(:websites) do
  if locals[:object].present?
    locals[:object].websites.map do |w|
      { 'type' => w.value_type, 'url' => w.value }
    end
  end
end

code(:phone_numbers) do
  if locals[:object].present?
    locals[:object].phone_numbers.map do |w|
      { 'type' => w.value_type, 'url' => w.value }
    end
  end
end

code(:email_addresses) do
  if locals[:object].present?
    locals[:object].email_addresses.map do |w|
      { 'type' => w.value_type, 'url' => w.value, 'default' => w.default }
    end
  end
end

code(:addresses) do
  if locals[:object].present?
    locals[:object].addresses.map do |w|
      {
        'type' => w.value_type,
        'address' => w.full_address(:include_country => true),
        'default' => w.default
      }
    end
  end
end

code(:instant_message_accounts) do
  if locals[:object].present?
    locals[:object].instant_message_accounts.map do |w|
      { 'type' => w.value_type, 'url' => w.value }
    end
  end
end

code(:groups) do
  if locals[:object].present?
    locals[:object].groups.map do |w|
      { 'name' => w.name, 'id' => w.id }
    end
  end
end

While there are some improvements that can be made with rabl’s syntax it promotes a good separation between the model and the API. I really liked that. This will help keep API versioning and endpoints cleanly separated from how the underlying models evolve or implementations change.