React/Redux Portfolio Project

Let me just start by saying that it’s amazing—almost overwhelming—how much data the City of New York collects, catalogues, and publicizes. Everything from the coordinates of every piece of street furniture to the holdings of the NYC Employee Retirement System (NYCERS) are available in machine-readable format at And they are all available through Socrata’s SODA API. The data are not organized perfectly—more on that later—but the sheer amount of it makes it an incredible tool if you can figure out how to harness it.

Naturally, I wanted to build another NYC-centric app, but what specifically? As my wife and I just moved from Brooklyn to Manhattan, I have been thinking a lot recently about housing, neighborhoods, and all the things that go along with being a part of a specific community in New York. So, it occurred to me that I should build an app that would help me look up all the information I needed (or was curious about) my new building and neighborhood.

Building Profile

The first group of data I make available in the app is sort of general information about the building you live in. It gets most of its information from the city’s Geoclient API:


  • Address: pretty self-explanatory
  • BBL: Building-block-boro code, one of NYC’s unique tax-parcel identifiers. Often necessary when interacting with city government.
  • Condo Number: Unique number assigned to each Condominium in the city.


  • Neighborhood: Official name of the neighborhood in which the address is located.
  • Community District: NYC Planning Community District in which the address is located.*
  • Police Precinct: NYPD precinct in which the address is located.*
  • Fire Company: FDNY fire company (smallest division) that responds to the address.*
  • School District: NYC Department of Education district in which the address is located.*

*The Community District, Police Precinct, Fire Company, and School District numbers all link to their appropriate webpages (uses regexp).

Two additional pieces of information come from the Department of Housing Preservation and Development’s (HPD) “Registration Contacts” dataset:


  • Owned By: The listed owner of building.
  • Services Managed By: The management company listed for the building.


None added.


This section shows the user all the 311 complaints and Housing Preservation and Development (HPD) violations on record for the building.

According to their website, 311 “provides access to non-emergency City services and information about City government programs.” It’s where most city residents file complaints about poor conditions in their homes or neighborhoods.

Complaints filed to HPD through 311 or other methods are investigated and, if a violation is found, it will be logged in their system and a notice of violation (NOV) will be sent to the entity required to repair it.

The APIs used in this section come from the “311 Service Requests from 2010 to Present” and “Housing Maintenance Code Violations” datasets, respectively.


Finally, the Zillow section provides financial information about the address provided:


Links to various sections of the Zillow entry on the address, including general information, graphs of its value over time, maps, and comparable units.


Zillow’s estimate of the value of the home.

Rent Zestimate®

Zillow’s estimate of what it should cost to rent the home.


Rails with JavaScript Portfolio Project

The overarching goal of this project was to take my existing Rails project (Subway Scheduler), and add dynamic features. To do this, we serialized the information in our ActiveRecord models, made them available via JSON API, and then used JavaScript to display that information, rather than utilizing only static Rails Views.

The requirements were further broken up as follows:

  1. Must translate JSON responses from your Rails app into JavaScript Model Objects using either ES6 class or constructor syntax. The Model Objects must have at least one method on the prototype.
  2. Must render at least one index page (index resource) via JavaScript and an Active Model Serialization JSON Backend.
  3. Must render at least one show page (show resource) via JavaScript and an Active Model Serialization JSON Backend.
  4. Your Rails application must dynamically render on the page at least one serialized has_many relationship through JSON using JavaScript.
  5. Must use your Rails application to render a form for creating a resource that is submitted dynamically and displayed through JavaScript and JSON without a page refresh.

JavaScript Models: Addresses and Routes

I serialized both my Address and Route models using ActiveModel::Serializers and made them available as JSON using Rails’ respond_to method.

As for the JavaScript models for each type of object, the constructors (and a formatter) looked like this:


class Address {
  constructor(address) { =;
    this.line_1 = address.line_1;
    this.line_2 = address.line_2; =; =;
    this.path = `/addresses/${}`;
    this.string = this.stringify();

  stringify() {
    var addressAsString = "";

    addressAsString += `${this.line_1}, `;
    addressAsString += ((this.line_2) ? `${this.line_2}, ` : '' );
    addressAsString += `${}, NY ${}`;

    return addressAsString;




class Route {
  constructor(route) { =; =;
    this.origin = new Address(route.origin);
    this.destination = new Address(route.destination);
    this.user = route.user;
    this.path = `/routes/${}`;
    this.directions = [];



Rendering Address index page, adding new Addresses

First things first, I wanted to render my Address index page using JavaScript. First, had to make sure I could select where I wanted to put the addresses on the page by making sure the div had an id of 'address_list'.

Then, I could call the Address‘s JavaScript Model’s getAll function once the page was ready:

class Address {


  static getAll(url) {
    allAddresses = [];

    $.get(`${url}.json`, function(response) {
      response.forEach(function(response_item) {
        var address = new Address(response_item);
    }).then(() =>
        {items: allAddresses})




That gets the addresses from the JSON API we created using our serializer, creates a new JavaScript Address for each, and then adds each to the DOM using a Handlebars template.

Adding a new Address

The Address index page also allows for adding new Addresses, and rendering them dynamically. A “New Address” form with id 'new_address' is watched for submissions. Upon being clicked, we serialize the form info, and POST it to our API for storing in the database. Then, it’s added to the DOM by creating a new Address JavaScript object and tacking it on the already-rendered list.

Showing a Route via our own API and Google Maps API

For showing a single Route, we have to get origin and destination Address information, plus use Google Maps’ Directions API to find actual routing information.

I wanted to actually load this information dynamically on a Route list page, as I thought it would be more fun. So, on the Route index page (or a User‘s nested Route index page), each Route has a “show route” button with class 'show_route', as well as a data-route-id tag for tracking which button is clicked.

When that button is clicked, we search through our JavaScript Route objects for the matching one, and call the showRoute function on it:

$(document).on('click', '.show_route', function(e) {
  const element = $(this)

  const route = allRoutes.find(function(rte) {
    return =='route-id')

showRoute gets the directions via Google Maps’ Directions API, and the object’s origin and destination Addresses, and dynamically adds them to the DOM using another Handlebars template (FYI, directionsService is a Google Maps DirectionsService object):

class Route {


  showRoute(el) {
    const route = this;

    var request = {
      origin: route.origin.string,
      destination: route.destination.string,
      travelMode: 'TRANSIT'

    directionsService.route(request, function(result, status) {
      if (status == 'OK') {
        route.directions = result['routes'][0]['legs'][0]['steps']



Video walkthrough



Rails Portfolio Project

For my Ruby on Rails portfolio project, I decided to do something using an additional API, as it had been fun to learn how to use Facebook’s OAuth one during the lessons.

As I have for my previous projects, I decided to incorporate one of my passions/hobbies: the New York City Subway system (actually, it uses all transit options in the city).


At first, I thought I would use the MTA’s set of APIs. However, I quickly realized that that would not allow me to provide transit directions (how to get from point A to point B) in the way that I wanted, as—duh!—they only provide real-time status of trains, buses, etc.

As it turns out, Google uses information gleaned from MTA’s API, which is formatted according to Google’s GTFS specification, and uses their computing power to figure out the directions. Ok, so I’m going to use Google Maps’ Directions API. I found a nice Gem that does that—all I had to do was provide my API key.


Next, I had to begin thinking about what models I would use. Obviously, I’d need a User model:


  • Fields
    • First name
    • Last name
    • Email address
    • Password
  • Validations
    • Presence of, uniqueness of, and email-address-ness of Email address
    • has_secure_password

and an Address model:


  • Fields
    • Line 1
    • Line 2
    • City
    • Borough
    • ZIP code
  • Validations
    • Presence of Line 1
    • Presence of Borough, and its inclusion in [‘Bronx’, ‘Brooklyn’, ‘Manhattan’, ‘Staten Island’, ‘Queens’]

Since I am building this app only for New York City, I didn’t need a State field. And I included Borough so users could filter addresses, a requirement for the project.

As for the has_many through requirement, it made sense to create a Route join table. A Route would belong to an Origin and a Destination (both Addresses), and a User. A User has_many Routes, and Addresses through Routes; an Address has_many Routes, and many Users through Routes.


  • Fields
    • Name
  • Validations
    • Presence of Origin and Destination
    • Presence of Name, and its uniqueness at the User level

The Name field will be a user-supplied label for the Route.


The controllers are very similar to what we’ve seen before. In addition to all seven RESTful routes for each of the models listed above, I built a Sessions controller to deal with login and logout logic. I wanted user to be able to login using either email/password combination OR OAuth2 through Google, so there are both “sessions#create” and “sessions#create_with_google” routes. A Sessions helper defines helper methods that interact with the session hash.


Got to use a lot of partial views, which was fun. There are lots of different ways to display or list addresses. Of course, put the forms into partials. In addition, I moved the error-message-displaying stuff, included on each form, into it’s own partial in /app/views/shared.

The “routes#show” route is where the Google Directions API does its stuff. The array returned by the google_maps_service gem looks pretty complicated at first glance—it’s an array of hashes many levels deep—but once you get the hang of it, it’s actually pretty simple. Here’s an example of where the Subway stop at which to get off is stored:

          :html_instructions=>"Subway towards Wakefield - 241 St"
          :transit_details =>{
            :arrival_stop =>{
              :name=>"3 Av - 149 St"


Video walkthrough

CLI Data Gem Project

For the CLI Data Gem Project, part of’s Full Stack Web Development online course, I was tasked with building a CLI (Command Line Interface) to data scraped from a public website.  Now I, being such a big Star Wars fan, and who am subscribed to all Marvel’s Star Wars comics, decided to go with Wookieepedia’s “Canon Comics” wiki.

Just in case you are unfamiliar with comic books, as I was before Marvel started releasing their Star Wars series, the sorts of metadata associated with each issue are:

  • Issue title
  • Series title (most issues are part of a series, which is usually focused on one character or set of characters)
  • Issue number (chronologically within the series)
  • Publication date
  • Artist info
    • Writer
    • Penciller
    • Inker
    • Letterer
    • Colorist

There are other data, but I decided I’d focus on the above when building my models.

Speaking of models, the main purpose of this project was to work with object in Ruby. So, after I had made the decision that I was going to make a Star Wars Comics CLI, I started thinking about what my objects would look like.


Because comic books are physical objects, and the people who make them are, well, physical humans, it was pretty easy to figure out my model scheme:

First, I would have an class called a Series, representing the various comic book series you might find in the Star Wars canon. Each Series has at least one, but up to many, constituent Issues.

Then, I will implement an Artist class, which encapsulates the idea of any artist who works on an Issue. Now, even though each artist has a different job—one writes, one draws the letters, etc.—in reality, I know I’m not going to need have each type represented as a different type of object because they don’t need unique functionality when my CLI is just going to be listing them…

Actually, since this lab is all about object-oriented programming, let’s do it! So, I’m going to create subclasses of Artist: Writer, Penciller, Letterer, and Colorist. These don’t add additional functionality to Artists, but they will allow me to show that I understand inheritance.


Man, this turned out to the worst part—I should have looked at Wookiepedia’s HTML before deciding to use it! All I can say is, its editors don’t follow best practices when it comes to HTML/CSS. No class names or classes that don’t distinguish between the things I need them to. I ended up having to use a lot of selectors based on text formatting tags written directly in the HTML, including having to use the background color of links to tell whether it linked to a story (I’m not even dealing with these in my gem) or an issue.

Also, there are a LOT of comic books, so I ran into the problem that my gem was just taking too long to scrape up all that metadata! I don’t want my user to sit there for two minutes while the app downloads information about every Star Wars comic ever! I ended up writing the code so that it only scrapes when it needs to. For instance, if the user just wants to list the issues within a particular series, my gem will scrape for Series when the user asks to look at them, and scrape for Issues within that Series only when they’ve selected it. However, if a user wants to look at issues contributed to by a particular artist, they’ll just have to wait (Artists are only assigned to Issues when Issues are scraped, so in this case all Issues need to be scraped)!


Sinatra Portfolio Project

After basing my first project on my love of Star Wars, I decided to base the second, the Sinatra project, on another thing close to my heart, my cats. My wife and I have two, Bronx and Coco Villanelle. They’re not related, but they act like young siblings—one moment, they’re cozying up to one another on the bed; the next, we’ll find them roughhousing like little wrestlers.

My wife and I travel quite a bit, so we often have to find temporary homes for Bronx and Coco Villanelle, and we use a service that schedules everything through phone calls and emails—a little outdated in today’s app-dominated world. With that in mind, I decided my project would be a pet-sitting scheduler app!


Ok, let’s take a look at what kind of models our app will have. First, we have to have Users, because, well, people have to be able to login and use the app! And I’m actually going to have to kinds of Users, Owners and Sitters. Here, I’ve made them subclasses of Users, because there’s a lot of functionality they share.

Next, we have Pets. Just as in the real world, a Pet belongs_to an Owner, and an Owner has_many Pets. I know some people have just one pet, but they’re really missing out.

And finally, we have Appointments. Representing scheduled pet-sitting sessions, an Appointment belongs_to both a Pet and a Sitter.