Building a Directory Application with RESTful API, by Alex Wynter

Date: 
Wednesday, February 11, 2015

Announcements

UA Branding updates:

  • If you want to be in on the work, consider contributing by attending the weekly meetings in teh Computer Center room 303, Fridays 10-11am or sometimes 10am - noon.
  • CSS stylesheet framework should be available within a month.
  • The Drupal starter theme will be a subtheme of Omega.
  • CALS (The College of Agriculture and Life Sciences) will prototype the College theme.

Presentation Summary - from the meeting announcement

Presentation slides available online: https://prezi.com/3xfe9irhcfug/common-resources-directory/

This presentation will focus on solving a problem you might have with technology you might know something about, but don’t know enough the step out into the unknown and try it yourself.

Background: The College of Public Health had a data duplication and updating problem that you may have if you manage multiple, related websites. We had to duplicate faculty information across multiple pages of multiple sites (some of which was just hand-typed HTML) and when someone moved to a new office, each instance would need to be hunted down and changed. To solve this problem, we needed a central location for this information. Of course, we don’t have a lot of free time to build anything, so we needed to look at frameworks and components that would make things faster.

The presentation: I'll go through our thought processes and what we considered. I’ll start with which technologies we considered and the pros and cons we found. I’ll talk about what we decided should be the minimum requirements and how it has been built. I’ll lead us through some examples, show the tests we built, and demonstrate the automatically-generated administrative interface. There should be time for questions, so please feel free to interrupt!

Spoilers: We considered Drupal, Nodejs, and Rails, but ultimately decided Rails. I used the activeadmin gem (ruby library) to generate the admin interface and customized from there, saving a lot of time. The front-end script is custom. You might learn a bit of ruby, but don’t worry because it’s very readable!

Questions and Answers

  • Question: How can the information in the Ruby-on-Rails Directory be pushed to a Drupal site? Answer: We're working on that as the next step. On the Drupal side, we will probably be using Feeds to pull the data in.
  • Question: Are you pulling data from EDS? Answer: Not currently, but there are several possibilities. There is a push-style subscription system being discussed at UITS. Also a change queue.
  • Question: Do you version-control your database and if so, how? Answer: We version control the database schema, but not the data. Unfortunately, that's all you can reasonably do. [There was a spirited discussion at this point about whether and how to version a database. It's complicated.]
  • Question: What did you mean by convention over configuration? Can you give an example? Answer: A framework that favors convention over configuration, like Rails, make certain assumptions and makes developing with those assumptions easy, rather than configuring something that is a convention. A good example is in the routes. Rails uses the REST convention by default, so when we declare a resource, like people, we get restful routes by default, rather than us configuring each route to match the REST convention.

Note that it also might be possible to bring in info from UA-Vitae at some point.

UA-Vitae: http://uavitae.arizona.edu/