Hi. I’m David.

I’m learning Ruby at The Flatiron School.

So Nice ♫

So Nice uses Sinatra to create a nifty little HTML interface to your desktop music player – iTunes, Spotify, and a few others.

So Nice’s UI is very simple – it’s a single web page displaying the name of the current song playing, the artist name and the album name. In the background there’s a rotating graphic related to the album, which they pull from Last.fm.

picture alt

The assigment for this post is to break down the files in the repository to better undertand how Sinatra is structured. Here they are:

  • so-nice/config.ru Does nothing more than require sonice.rb and run Sinatra. Has optional switches to disable controls and voting features.

  • so-nice/sonice.rb Sets the individual controls that appear on the page and the title, artist and album that are currently playing.

  • so-nice/Gemfile Tracks the gems currently used by the application. Used by Bundler, along with Gemfile.lock.

  • so-nice/Gemfile.lock Tracks the versions of the gems thatyou rely on to run your application. Used by Bundler, along with Gemfile.

  • so-nice/public The directory containing the web site.

  • so-nice/public/jquery.min.js Something in jQuery that I wish I understood.

  • so-nice/public/script.js A javascript file that changes the background for the page, assigns keyboard keys as shortcuts for different functions and holds the objects for the songs. The real brains of the operation.

  • so-nice/public/stylesheet.css The CSS stylesheet for all of the HTML on the page.

  • so-nice/views The directory that holds the code that will generate the HTML for the web site.

  • so-nice/views/index.haml The sole file that generates the HTML for the app.


Our group is going to be presenting this week, and we are looking at building on data sources that already exist, interfacing with them via their APIs.

Before we can use the APIs, we will have to prove to the system that we are interacting with that we have permission to use it. That’s where OAuth comes in.

Here’s how OAuth generally works:

picture alt

In short, the server wants to know that the user has given permission to the client to access their data, which is hosted the server. In order to assure the server that this is the case, the user asks the client to ask for that data on their behalf. The server then asks for the user to directly authenticate the request – to confirm that the client has the user’s permission to access their data. Once the user confirms, the server issues a “token” to the client, which is a pass to use the information in the future, and the client confirms to the user that permission has been granted.

There’s a longer, better written version of this here – I recommend that anyone wanting to know more about OAuth should read it.

The graphic above and explanation that went along with it made sense to me when I was thinking in terms of an app like Twitpic trying to access Twitter user data, but I was still having trouble understanding it in terms of API authorization. This graphic about the Google API helped.

picture alt

Most new APIs that use OAuth use OAuth 2.0, which was released in October 2012, but many older APIs still use the OAuth 1.0a specification.


Horcruxes or Repos? A git guide to the perplexed

It’s been an exciting first week at Flatiron School!

By far the most confusing thing for me to date has been Git. So I’m going to dump everything I know to this post, in the hopes that trying to explain the various Git commands will help me understand them a little better.

My apologies for any blindingly basic errors – it’s my first week. Corrections are appreciated and welcome.

What is Git?

Gwen described Git as a horcrux for your files. As long as one horcrux remains, the files cannot die.

A less Potter-centric way of putting it is that Git is a version control system. It allows you to manage a set of files as they change over time.

Git is a distributed system. This means that each user in the system can have their own repository on their local system that is a fully functioning clone.

Git concepts:

repository: The data structure for a set of fully functioning files. It contains the history, changes over time and various project branches of the files. A horcrux.

staging area: A place to make changes on files without commiting to making those changes permanent. A sandbox.

HEAD: Git tracks the changes in your files over time. HEAD is a symbolic reference that points to the version of your files that you are currently working with. By default, it is the most recent commit in your current branch.

master: If Git is visualized as a tree, master is the trunk. It’s just another repository, but it is used as the most stable version of the files, which all the other branches diverge from and return to once their purpose is complete.

branch: Unsurprisingly, if master is the tree’s trunk, then branches are… the tree’s branches. Branches let you work on multiple disparate features at once.

origin: The default name of the remote git repository you cloned from is called “origin”.

fast forward: The simplest merge in git, where only one of the two branches has changed and there are no conflicts.

Basic Git commands:

add: Moves the current version of the named file to a special staging area, holding files that are ready to be committed.

branch: Allows you to list, create and manages branches within git.

checkout: Switches to a new branch. With the -b flag, creates a shortcut to create a new branch and switch to it.

clone: Makes a copy of a git repository.

commit: Records a snapshot of the staging area, and moves HEAD to the new commit.

config: Allows you to configure your git.

diff: Shows the changes between two branches.

fetch: Updates your repository from another one, pulling down any data that you do not have locally.

init: Creates a new repository from an existing directory of files.

log: Lists the commits made in the current repository.

merge: Combines the changes in your current branch with another one.

pull: This command will basically run a git fetch immediately followed by a git merge.

push: Pushes your repository’s new branches and data to a remote repository.

remote: Allows you to list, add, and delete remote repositories.

reset: Allows you to undo commits.

rm: The git analog to the BASH rm command, git rm will remove files from the staging area.

status: Shows the status of the files in your working directory and staging area.

Some useful sources:

Getting Started – Git Basics

Lars Vogel’s Git Tutorial

Understanding Git: Repositories

Git Reference

Introduction to Git with Scott Chacon of GitHub