barkinet
diff --git a/‎Rules‎
Lines changed: 1 addition & 0 deletions b/‎Rules‎
Lines changed: 1 addition & 0 deletions
diff --git a/‎content/changes/2013-10-04-oauth-changes-coming.html‎
Lines changed: 1 addition & 1 deletion b/‎content/changes/2013-10-04-oauth-changes-coming.html‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎content/guides/basics-of-authentication.md‎
Lines changed: 31 additions & 24 deletions b/‎content/guides/basics-of-authentication.md‎
Lines changed: 31 additions & 24 deletions
diff --git a/‎content/guides/getting-started.md‎
Lines changed: 1 addition & 1 deletion b/‎content/guides/getting-started.md‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎content/guides/rendering-data-as-graphs.md‎
Lines changed: 47 additions & 34 deletions b/‎content/guides/rendering-data-as-graphs.md‎
Lines changed: 47 additions & 34 deletions
@@ -44,6 +44,7 @@ end
 compile '/guides/*' do
   filter :kramdown, :toc_levels => [2]
   filter :erb
+  filter :colorize_syntax, :default_colorizer => :pygmentsrb
   layout item[:layout] || 'guides'
 end
 
 
@@ -10,7 +10,7 @@
 For example, if you are making a POST with the `application/json`
 mime-type you'll see an additional field for the granted scopes.
 
-<pre class="highlight"><code class="language-javascript">
+<pre><code class="language-javascript">
 {
   "access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a",
   "scope":"repo,gist",
 
@@ -7,32 +7,33 @@ title: Basics of Authentication | GitHub API
 * TOC
 {:toc}
 
-In this section, we're going to focus on the basics of authentication. Specifically, 
-we're going to create a Ruby server (using [Sinatra][Sinatra]) that implements 
+In this section, we're going to focus on the basics of authentication. Specifically,
+we're going to create a Ruby server (using [Sinatra][Sinatra]) that implements
 the [web flow][webflow] of an application in several different ways.
 
 Note: you can download the complete source code for this project [from the platform-samples repo](https://github.com/github/platform-samples/tree/master/api/ruby/basics-of-authentication).
 
 ## Registering your app
 
 First, you'll need to [register your
-application](https://github.com/settings/applications/new). Every 
-registered OAuth application is assigned a unique Client ID and Client Secret. 
+application](https://github.com/settings/applications/new). Every
+registered OAuth application is assigned a unique Client ID and Client Secret.
 The Client Secret should not be shared! That includes checking the string
 into your repository.
 
-You can fill out every piece of information however you like, except the 
-**Authorization callback URL**. This is easily the most important piece to setting 
-up your application. It's the callback URL that GitHub returns the user to after 
+You can fill out every piece of information however you like, except the
+**Authorization callback URL**. This is easily the most important piece to setting
+up your application. It's the callback URL that GitHub returns the user to after
 successful authentication.
 
-Since we're running a regular Sinatra server, the location of the local instance 
+Since we're running a regular Sinatra server, the location of the local instance
 is set to `http://localhost:4567`. Let's fill in the callback URL as `http://localhost:4567/callback`.
 
 ## Accepting user authorization
 
 Now, let's start filling out our simple server. Create a file called _server.rb_ and paste this into it:
 
+    #!ruby
     require 'sinatra'
     require 'rest-client'
 
@@ -43,42 +44,43 @@ Now, let's start filling out our simple server. Create a file called _server.rb_
       erb :index, :locals => {:client_id => CLIENT_ID}
     end
 
-Your client ID and client secret keys come from [your application's configuration page](https://github.com/settings/applications). You should **never, _ever_** store these values in 
+Your client ID and client secret keys come from [your application's configuration page](https://github.com/settings/applications). You should **never, _ever_** store these values in
 GitHub--or any other public place, for that matter. We recommend storing them as
 [environment variables][about env vars]--which is exactly what we've done here.
 
 Next, in _views/index.erb_, paste this content:
 
-
+    #!html+erb
     <html>
       <head>
       </head>
       <body>
         <p>Well, hello there!</p>
         <p>We're going to now talk to the GitHub API. Ready? <a href="https://github.com/login/oauth/authorize?client_id=<%= client_id %>">Click here</a> to begin!</a></p>
-        <p>If that link doesn't work, remember to provide your own <a href="http://developer.github.com/v3/oauth/#web-application-flow">Client ID</a>!</p>
+        <p>If that link doesn't work, remember to provide your own <a href="/v3/oauth/#web-application-flow">Client ID</a>!</p>
       </body>
     </html>
 
 (If you're unfamiliar with how Sinatra works, we recommend [reading the Sinatra guide][Sinatra guide].)
 
-Obviously, you'll want to change `<your_client_id>` to match your actual Client ID. 
+Obviously, you'll want to change `<your_client_id>` to match your actual Client ID.
 
-Navigate your browser to `http://localhost:4567`. After clicking on the link, you 
+Navigate your browser to `http://localhost:4567`. After clicking on the link, you
 should be taken to GitHub, and presented with a dialog that looks something like this:  
 ![](/images/oauth_prompt.png)
 
-If you trust yourself, click **Authorize App**. Wuh-oh! Sinatra spits out a 
+If you trust yourself, click **Authorize App**. Wuh-oh! Sinatra spits out a
 `404` error. What gives?!
 
 Well, remember when we specified a Callback URL to be `callback`? We didn't provide
-a route for it, so GitHub doesn't know where to drop the user after they authorize 
+a route for it, so GitHub doesn't know where to drop the user after they authorize
 the app. Let's fix that now!
 
 ### Providing a callback
 
 In _server.rb_, add a route to specify what the callback should do:
 
+    #!ruby
     get '/callback' do
       # get temporary GitHub code...
       session_code = request.env['rack.request.query_hash']["code"]
@@ -94,20 +96,22 @@ In _server.rb_, add a route to specify what the callback should do:
     end
 
 After a successful app authentication, GitHub provides a temporary `code` value.
-You'll need to `POST` this code back to GitHub in exchange for an `access_token`. 
+You'll need to `POST` this code back to GitHub in exchange for an `access_token`.
 To simplify our GET and POST HTTP requests, we're using the [rest-client][REST Client].
-Note that you'll probably never access the API through REST. For a more serious 
+Note that you'll probably never access the API through REST. For a more serious
 application, you should probably use [a library written in the language of your choice][libraries].
 
 At last, with this access token, you'll be able to make authenticated requests as
 the logged in user:
 
+    #!ruby
     auth_result = RestClient.get("https://api.github.com/user", {:params => {:access_token => access_token}})
 
     erb :basic, :locals => {:auth_result => auth_result}
 
 We can do whatever we want with our results. In this case, we'll just dump them straight into _basic.erb_:
 
+    #!html+erb
     <p>Okay, here's a JSON dump:</p>
     <p>
       <p>Hello, <%= login %>! It looks like you're <%= hire_status %>.</p>
@@ -116,12 +120,12 @@ We can do whatever we want with our results. In this case, we'll just dump them
 ## Implementing "persistent" authentication
 
 It'd be a pretty bad model if we required users to log into the app every single
-time they needed to access the web page. For example, try navigating directly to 
+time they needed to access the web page. For example, try navigating directly to
 `http://localhost:4567/basic`. You'll get an error.
 
 What if we could circumvent the entire
 "click here" process, and just _remember_ that, as long as the user's logged into
-GitHub, they should be able to access this application? Hold on to your hat, 
+GitHub, they should be able to access this application? Hold on to your hat,
 because _that's exactly what we're going to do_.
 
 Our little server above is rather simple. In order to wedge in some intelligent
@@ -133,6 +137,7 @@ This will make authentication transparent to the user.
 After you run `gem install sinatra_auth_github`, create a file called _advanced_server.rb_,
 and paste these lines into it:
 
+    #!ruby
     require 'sinatra/auth/github'
     require 'rest-client'
 
@@ -164,7 +169,7 @@ and paste these lines into it:
             authenticate!
           else
             access_token = github_user["token"]
-            auth_result = RestClient.get("https://api.github.com/user", {:params => {:access_token => access_token, :accept => :json}, 
+            auth_result = RestClient.get("https://api.github.com/user", {:params => {:access_token => access_token, :accept => :json},
                                                                                       :accept => :json})
 
             auth_result = JSON.parse(auth_result)
@@ -184,14 +189,14 @@ and paste these lines into it:
       end
     end
 
-Much of the code should look familiar. For example, we're still using `RestClient.get` 
+Much of the code should look familiar. For example, we're still using `RestClient.get`
 to call out to the GitHub API, and we're still passing our results to be rendered
 in an ERB template (this time, it's called `advanced.erb`). Some of the other
 details--like turning our app into a class that inherits from `Sinatra::Base`--are a result
 of inheriting from `sinatra/auth/github`, which is written as [a Sinatra extension][sinatra extension].
 
 Also, we now have a `github_user` object, which comes from `sinatra-auth-github`. The
-`token` key represents the same `access_token` we used during our simple server. 
+`token` key represents the same `access_token` we used during our simple server.
 
 `sinatra-auth-github` comes with quite a few options that you can customize. Here,
 we're establishing them through the `:github_options` symbol. Passing your client ID
@@ -201,6 +206,7 @@ to simplify your authentication.
 We must also create a _config.ru_ config file, which Rack will use for its configuration
 options:
 
+    #!ruby
     ENV['RACK_ENV'] ||= 'development'
     require "rubygems"
     require "bundler/setup"
@@ -211,6 +217,7 @@ options:
 
 Next, create a file in _views_ called _advanced.erb_, and paste this markup into it:
 
+    #!html+erb
     <html>
       <head>
       </head>
@@ -235,12 +242,12 @@ we would've seen the same confirmation dialog from earlier pop-up and warn us.
 If you'd like, you can play around with [yet another Sinatra-GitHub auth example][sinatra auth github test]
 available as a separate project.
 
-[webflow]: http://developer.github.com/v3/oauth/#web-application-flow
+[webflow]: /v3/oauth/#web-application-flow
 [Sinatra]: http://www.sinatrarb.com/
 [about env vars]: http://en.wikipedia.org/wiki/Environment_variable#Getting_and_setting_environment_variables
 [Sinatra guide]: http://sinatra-book.gittr.com/#hello_world_application
 [REST Client]: https://github.com/archiloque/rest-client
-[libraries]: http://developer.github.com/v3/libraries/
+[libraries]: /libraries/
 [rack guide]: http://en.wikipedia.org/wiki/Rack_(web_server_interface)
 [sinatra auth github]: https://github.com/atmos/sinatra_auth_github
 [sinatra extension]: http://www.sinatrarb.com/extensions.html
 
@@ -444,7 +444,7 @@ responses don't count against your [rate limit][rate-limiting].
 
 
 
-[wrappers]: http://developer.github.com/v3/libraries/
+[wrappers]: http://developer.github.com/libraries/
 [curl]: http://curl.haxx.se/
 [media types]: http://developer.github.com/v3/media/
 [oauth]: http://developer.github.com/v3/oauth/
 
@@ -23,43 +23,45 @@ First, [register a new application][new oauth application] on GitHub. Set the ma
 URLs to `http://localhost:4567/`. As [before][basics-of-authentication], we're going to handle authentication for the API by
 implementing a Rack middleware using [sinatra-auth-github][sinatra auth github]:
 
-	require 'sinatra/auth/github'
-
-	module Example
-	  class MyGraphApp < Sinatra::Base
-	    # !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!!
-	    # Instead, set and test environment variables, like below
-	    # if ENV['GITHUB_CLIENT_ID'] && ENV['GITHUB_CLIENT_SECRET']
-	    #  CLIENT_ID        = ENV['GITHUB_CLIENT_ID']
-	    #  CLIENT_SECRET    = ENV['GITHUB_CLIENT_SECRET']
-	    # end
-
-	    CLIENT_ID = ENV['GH_GRAPH_CLIENT_ID']
-	    CLIENT_SECRET = ENV['GH_GRAPH_SECRET_ID']
-
-	    enable :sessions
-
-	    set :github_options, {
-	      :scopes    => "repo",
-	      :secret    => CLIENT_SECRET,
-	      :client_id => CLIENT_ID,
-	      :callback_url => "/"
-	    }
-
-	    register Sinatra::Auth::Github
-
-	    get '/' do
-	      if !authenticated?
-	        authenticate!
-	      else
-	        access_token = github_user["token"]
-	      end
-	    end
-	  end
-	end
+    #!ruby
+    require 'sinatra/auth/github'
+
+    module Example
+      class MyGraphApp < Sinatra::Base
+        # !!! DO NOT EVER USE HARD-CODED VALUES IN A REAL APP !!!
+        # Instead, set and test environment variables, like below
+        # if ENV['GITHUB_CLIENT_ID'] && ENV['GITHUB_CLIENT_SECRET']
+        #  CLIENT_ID        = ENV['GITHUB_CLIENT_ID']
+        #  CLIENT_SECRET    = ENV['GITHUB_CLIENT_SECRET']
+        # end
+
+        CLIENT_ID = ENV['GH_GRAPH_CLIENT_ID']
+        CLIENT_SECRET = ENV['GH_GRAPH_SECRET_ID']
+
+        enable :sessions
+
+        set :github_options, {
+          :scopes    => "repo",
+          :secret    => CLIENT_SECRET,
+          :client_id => CLIENT_ID,
+          :callback_url => "/"
+        }
+
+        register Sinatra::Auth::Github
+
+        get '/' do
+          if !authenticated?
+            authenticate!
+          else
+            access_token = github_user["token"]
+          end
+        end
+      end
+    end
 
 Set up a similar _config.ru_ file as in the previous example:
 
+    #!ruby
     ENV['RACK_ENV'] ||= 'development'
     require "rubygems"
     require "bundler/setup"
@@ -78,6 +80,7 @@ so you know it'll work.
 Authentication with the API via Octokit is easy. Just pass your login
 and token to the `Octokit::Client` constructor:
 
+    #!ruby
     if !authenticated?
       authenticate!
     else
@@ -89,11 +92,13 @@ to see the different programming languages they use, and count which ones are us
 most often. To do that, we'll first need a list of our repositories from the API.
 With Octokit, that looks like this:
 
+    #!ruby
     repos = client.repositories
 
 Next, we'll iterate over each repository, and count the language that GitHub
 associates with it:
 
+    #!ruby
     language_obj = {}
     repos.each do |repo|
       # sometimes language can be nil
@@ -126,6 +131,7 @@ check out ["D3 for Mortals"][D3 mortals].
 D3 is a JavaScript library, and likes working with data as arrays. So, let's convert our Ruby hash into
 a JSON array for use by JavaScript in the browser.
 
+    #!ruby
     languages = []
     language_obj.each do |lang, count|
       languages.push :language => lang, :count => count
@@ -141,6 +147,7 @@ Now, _lang_freq.erb_ is going to need some JavaScript to support rendering a bar
 For now, you can just use the code provided here, and refer to the resources linked above
 if you want to learn more about how D3 works:
 
+    #!html
     <!DOCTYPE html>
     <meta charset="utf-8">
     <html>
@@ -239,6 +246,7 @@ should be a great way to visualize the sizes of our coding languages used, rathe
 than simply the count. We'll need to construct an array of objects that looks
 something like this:
 
+    #!javascript
     [ { "name": "language1", "size": 100},
       { "name": "language2", "size": 23}
       ...
@@ -247,13 +255,15 @@ something like this:
 Since we already have a list of repositories above, let's inspect each one, and
 call [the language listing API method][language API]:
 
+    #!ruby
     repos.each do |repo|
       repo_name = repo.name
       repo_langs = octokit_client.languages("#{github_user.login}/#{repo_name}")
     end
 
 From there, we'll cumulatively add each language found to a "master list":
 
+    #!ruby
     repo_langs.each do |lang, count|
       if !language_obj[lang]
         language_obj[lang] = count
@@ -264,6 +274,7 @@ From there, we'll cumulatively add each language found to a "master list":
 
 After that, we'll format the contents into a structure that D3 understands:
 
+    #!ruby
     language_obj.each do |lang, count|
       language_byte_count.push :name => "#{lang} (#{count})", :count => count
     end
@@ -275,12 +286,14 @@ After that, we'll format the contents into a structure that D3 understands:
 
 To wrap up, we pass this JSON information over to the same ERB template:
 
+    #!ruby
     erb :lang_freq, :locals => { :languages => languages.to_json, :language_byte_count => language_bytes.to_json}
 
 
 Like before, here's a bunch of JavaScript that you can drop
 directly into your template:
 
+    #!html
     <div id="byte_freq"></div>
     <script>
       var language_bytes = <%= language_byte_count %>
Original file line number	Diff line number	Diff line change
`@@ -10,7 +10,7 @@`
`10`	`10`	For example, if you are making a POST with the `application/json`
`11`	`11`	`mime-type you'll see an additional field for the granted scopes.`
`12`	`12`
`13`		`-<pre class="highlight"><code class="language-javascript">`
	`13`	`+<pre><code class="language-javascript">`
`14`	`14`	`{`
`15`	`15`	`"access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a",`
`16`	`16`	`"scope":"repo,gist",`