Displaying another app’s data using HTTParty and Kaminari


I needed to access some data from another app and display it to users. The api side was a Rails 2.3.11 app and used will_paginate. It returned the json of a model collection and an association along with paginator information. The client side was a Rails 3.1 app using HTTParty and Kaminari.

API Controller

Rails 2.3.11 doesn’t include associations in the json, which is a known bug. So I returned a collection with the two models’ information. I used an API key to authenticate, which I won’t describe in detail since it’s outside the scope of this post.

class Api::FoosController < ApplicationController
  before_filter :authenticate_api_key!

  def foos_index
    @foos = Foo.paginate(:order => "created_at desc", :per_page => 40, :page => params[:page], 
        :include => :bar)
    @records = @foos.collect { |foo| {:foo => foo, :bar => bar} }
    render :json =>  {:records => @records, :total_entries => @foos.total_entries, 
        :per_page => @foo.per_page }

API Route

The route requires the page number.

  map.connect '/api/foos/foos_index/:page', :controller =&gt; "api/foos", :action =&gt; :foos_index

Client Model

FooIndex.foos_index returns itself, along with accessors for the response, records, total_count, current_page, and limit_value. The last three are important for Kaminari. When I parsed the JSON, I symbolized the keys. Much prettier than strings.

class FooIndex
  include HTTParty
  base_uri ENV['FOO_APP_URL']
  default_params :api_key =&gt; ENV['FOO_API_KEY']
  format :json
  attr_accessor :response, :records, :total_count, :current_page, :limit_value

  def initialize(response, records, total_count, current_page, limit_value)
    self.response = response
    self.records = records
    self.total_count = total_count
    self.current_page = current_page
    self.limit_value = limit_value

  def self.foos_index(page)
    @current_page = page || 1
    response = get("/api/foos/foos_index/#{@current_page}")
    if response.success?
      json = JSON.parse(response.body, symbolize_names: true) 
      self.new(response, json[:records], json[:total_entries], page, json[:per_page])
      raise response.response

Client Controller

I had to be creative with Kaminari using the paginate_array method. The options total_count and limit are used because the api doesn’t return the whole set of data, just the data for one page.

class FoosController &lt; ApplicationController
  def index
    params[:page] ||= 1
    @foos_index = FooIndex.foos_index(params[:page])
    @paginated_array = Kaminari.paginate_array(@foos_index.records, 
        total_count: @foos_index.total_count, 
        limit: @foos_index.limit_value).page(@foos_index.current_page)

Client Route

Page number is optional in the route. The controller defaults it to page 1.

  match '/foos(/:page)', :controller =&gt; :foos, :action =&gt; :index

Client View in HAML

The json returned by the api doubles up the first part of the hash. I’m not sure of an elegant way to handle that.

= paginate @paginated_array

    %th Foo Name
    %th Bar Name
    - @foos_index.records.each do |record|
        %td= record[:foo][:foo][:name]
        %td= record[:bar][:bar][:name]

= paginate @paginated_array

And that’s all it takes. Please comment with any comments or questions.

About Angel N. Sciortino

Ruby programmer. Sysadmin. Queer and polyamorous. Welder. Crocheter and darner. Chaotic good.

More Posts by Angel N. Sciortino - Author Website

Practicing Code with the DevChix


In February I finally decided to do something I always wanted to do with DevChix. I wanted to lead a group project intended for those who wanted to learn and could commit to 2 hours a week. I had 3 volunteers.. then two.. and then one! But thats ok, I know people get busy and other things going on, so no big deal. But cool thing is, even those that left said they learned something. So, my goal was still reached!

The Project

I had this idea in my head for awhile. One thing with lists is, you need to write down something if you want to do it today. We all have todo lists, and there are somethings we want to do every day. You may try to remember them without a list, or maybe you write them out. I thought it would be cool to have a todo list app that will give your list, allow you to check them off, then next day you have the same list. Bonus to have a graph of how many you did each day of the week. I think its motivating to see a graph of my progress.

Getting Started

Its my experience, when I start an app, I add user login and I get hung up on the authentication, tests and stuff and never get to the meat of the app. So I wrote a simple login system with just a username (no password), threw it in the session and wrote some simple methods to check to see if logged in. Later we replaced it with Devise with not much trouble at all.

What we learned

  • git, making branches, push and pull
  • erb and haml
  • grid 960
  • HighCharts a javascript graphing library
    devise, we added a whitelist so we can have a beta with only certain email addresses allowed to sign up.

  • publishing with heroku
  • rails of course


Summer got busy, including a cross country move for me and new job! We still managed to meet about every 2 weeks. We used github for our code. We put our tasks in Pivotal Tracker and that worked fine. We used Github wiki to record meeting notes, what happened since last meeting and who is doing what for the next week. We’ve been able to meet weekly the past month or so as the summer is winding down.

Whats next?

We are deploying the app to DevChix for beta testing. From there, not sure.

Book Review: "Refactoring in Ruby"

BookDesign processEventsIntroductionsRubyTestingTips and Tricks

“Refactoring in Ruby” written by William C. Wake and Kevin Rutherford.
Published by Addison-Wesley

This is more like a “workbook” then a “how to write awesome code” book. You can download the code from github http://github.com/kevinrutherford/rrwb-code and you will find tests/specs for the exercises.

The book is arranged in three parts, The Art of Refactoring, Code Smells, and Programs to Refactor.

There are explanations of “code smells” which are one characteristic of code that could be improved. Some of them are long parameter lists, unnecessarily complex, global variable, feature envy sections, etc. One thing I find interesting is the “How did it get this way?” section. It gives some insight into the thought process and reasoning behind the smell. I think this is good, as programmers our ego may be rather miffed to hear “This code stinks” but with some reasoning, it makes the pain less and I think firms up in our minds when this happens again, to do it this other way. I always want to know why when someone says I could do such and such thing better.

In addition to the code smell examples there are three programs to refactor in the end of the book. In a conversational tone, it walks through and gives some hints on what needs refactoring. Its almost as if you had a pair programming buddy working with you and identifying in small chunks what can be improved. This is definitely something I want to work through more carefully.

What I find odd, is that not all the code smells have code examples. The inspiration for the book I think is the Martin Fowler book “Refactoring Improving the design of Existing Code” which has examples for every code smell. Maybe Ruby smells less than Java? Or those fixes are really trivial? I don’t know. Overall, this is a great book and is certainly worth the price and investment and you will be a better programmer because of it!

How rails has changed how I seek for a job

PeopleRubyThoughtsTips and Tricks

For nine years, I have developed for the web. Over the years I’ve programmed in C, C++, Python, Java, ASP, PHP, Perl, and most recently, Ruby.
Since my first job as a developer, I’ve never looked for a new job: all of my job transitions have come through friends or co-workers.

In mid 2007 I was happy working with Perl. One day a friend told me about a Ruby on Rails job. Back in 2007, Rails developers in Brazil were rare. Because of that, the employer was seeking someone who fit the company instead of someone with Rails experience. That was great for me!

After a pleasant summer, the new job’s charm wore off and I decided that I wanted to move on but continue to program with Rails. Finally, I left my job.

When I started to send out resumes I soon realized that Rails’ culture fundamentally changed the way that a Rails job search functioned. In addition to the traditional resume or CV, Rails jobs demanded to know about Working With Rails, LinkedIn, GitHub, Twitter, personal blogs and sites, discussion forum posts, participation in open source projects, and a multitude of other online presences. These new demands made me realize that I hadn’t been cultivating a comprehensive web presence, which is not uncommon for female programmers, in my experience.

At first, this realization was disturbing.¬†Though¬†it’s still possible to get a Rails job without a vast web presence, I was upset to realize that I hadn’t been adhering to this best practice. It was particularly jarring the first time I was unable to answer these questions to potential employer.
The practice of software development as a craft is constantly reinventing itself and this includes the processes around job seeking and reputation building. Despite all of the hours, projects, languages, and jobs I’ve previously invested in, I now realize that I need to adapt to this new developer reality of being social and visible with my work in order to win back my standing as a desirable developer and potential candidate for a Rails position. The details of how I’ll implement that strategy will be the subject of an upcoming post, but I look forward to the possibilities ahead.

To read in portuguese.



Even though I am a Python developer, this made me happy:


We’ve been fortunate to have an outstanding, welcoming Python community driving the tone and the quality of events from PyCon, down to the statewide and local user groups. We don’t yet have a need for such a bridge group, and I hope we never need one. But it’s great to see one form quickly where it’s needed, and to see familiar names associated with it. More power to you.