Embedding API Sandboxes in Documentation

Last week I released a jQuery plugin called API Sandbox to help developers of web apps expose their API in a guided sandbox environment. The usage is simple. On a template, make sure there is a dedicated div element available to place a sandbox and then simply call the apiSandbox function on it.


This would create a nicely animated sandbox environment with proper fields for the parameters expressed in the path (in this case, one for user_id). API Sandbox supports generic URL parameters at the end of the API path, in addition to symbol wildcards anywhere in the path, preceded by a “:”.

There are a bunch of applications for this, and I’m still making improvements to the plugin, but I want to talk about one particularly cool application today. This plugin combined with the latest version of Redcarpet (2.0.0b), a Markdown parser, can allow you to easily embed sandboxes inline with your API documentation.

What’s so cool about the new version of Redcarpet is that instead of simply relying on the plugin author’s interpretation of how Markdown should be transformed into HTML, you can specify your own rendering rules and just let Redcarpet do all of the parsing. To easily embed sandboxes, I chose to override Redcarpet’s default rendering of links and change links to API paths into dynamic sandboxes. I created a subclass of Redcarpet::Render::HTML and created override methods for link and doc_header.

class DocsParser < Redcarpet::Render::HTML
  def link(link, title, content)
    if link.include? "SANDBOX: "
      path = link.gsub("SANDBOX: ","")
      id = path.gsub(/[\/?&=\[\]]/,"")
      rendered = "<div id='sandbox'>"
      rendered += content + "<div id='" + path + "' class='sandbox " + id + "'></div>"
      rendered += "</div>"
      link = link || ""
      title = title || ""
      content = content || ""
      rendered = "<a href='" +link + "'>" + content + "</a>"

  def doc_header
    "<script>new App.Views.Docs({ el: $('#main_content') });</script>"

All I did here was render a div element with the id of sandbox instead of a link when the path has a prefix of SANDBOX:, and then added in a script in the header of all generated documentation pages to load the script that changes the divs into sandboxes (the site I’m working on uses Backbone.js, hence the new App.Views.Docs).

Then you have to write an epic 2 lines of CoffeeScript code to turn all of the links into awesome API sandboxes.

$("div.sandbox").each ->
      $(this).apiSandbox "get", $(this).attr("id")

Not bad at all.

API Sandbox is just the first part of a CoffeeScript/SASS/Ruby API explorer I’ll be releasing over the next couple of weeks, so get excited.


Building Site Navigation with Markdown and Nokogiri

Who knew that Markdown — in my opinion the best text-to-HTML syntax available — could be used for something other than blog posts (or Github readme files)? Turns out that Markdown can be used as a powerful way to make web app navigation really simple to edit, even by non-developers. The task I set out to do was to turn something like this:

* Home
* About
    * About Us
    * API
    * Terms of Use
* Browse
* Etc.

into a nice dropdown menu. Making this markdown text available to a view is a fairly simple task. In Ruby on Rails, if you have a Page model that can hold Markdown text, you simply have to fetch it in the controller and call .to_html.html_safe on it. Also, with the help of some ternary operator elegance, you should make sure that if the page doesn’t exist, the code doesn’t blow up.

c_nav = Page.find_by_slug 'client-nav'
@client_nav = c_nav.nil? ? '' : c_nav.to_html.html_safe

So now, with the addition of a simple line in the view where we dump the contents of @client_nav onto the page, we’ve accomplished displaying a terrible looking unordered list when we could have just hard coded a nice looking menu in Haml. Here comes the fun part.

The obvious first choice for this task was to use jQuery to dynamically add CSS styles to the unordered list to turn it into a nice navigation menu. With the use of jQuery’s addClass method this is fairly simple, and it worked when I implemented it with just a couple lines of code. Unfortunately it resulted in annoying flickering as the page loaded because the unordered list is displayed un-styled for a split second (unacceptable). This could probably be fixed, but why bother doing something on the browser when it can be handled perfectly well on the server? After a couple of painful hours attempting to add classes to the generated HTML using Ruby string manipulation techniques and having little success, I discovered that this problem had already been solved by the creators of the Nokogiri gem.

To begin turning the raw HTML into styled goodness, I first stripped out the opening and closing ul tags manually. I enclosed the code to do this in a beginrescueend block because the test suite I’m using (Rspec) didn’t like me using negative numbers for indexes in a string for some reason.

   @client_nav[0..3] = ""
   @client_nav[-5..-1] = ""

Then I let Nokogiri work it’s magic.

@client_nav = Nokogiri::HTML::DocumentFragment.parse(@client_nav)
@client_nav.css("li:root").each do |anchor|
   anchor['class'] = 'nav_item'
@client_nav.css("li:has(ul)").each do |anchor|
   anchor['class'] = "nav_item more"
@client_nav.css("ul:first-child").each do |anchor|
   anchor['class'] = "dropdown"
@client_nav = @client_nav.to_html.html_safe

Because the HTML I was passing to Nokogiri is just a fragment of an unordered list, I used the DocumentFragment.parse method to prepare the HTML for Nokogiri to dynamically add CSS. Then, using basic CSS selectors (as well as one really useful one — has() — taken from jQuery), I added the proper classes to the list elements. It worked like a charm.

I’ll leave the CSS magic up to you — suffice it to say that with the proper stylesheets, this can look really great and is infinitely configurable. Why bother with bulky client-side code when Nokogiri provides a just as (perhaps even more) elegant solution?

Tag Clouds in Ruby on Rails

Tag Cloud
My finished tag cloud.

One of the first projects I got to work on at Art.sy was a tag cloud that provides a quick visual representation of the types of artworks that are in the site’s database. These can be quite visually striking if done correctly, but can be ugly if done poorly. Some of this is a result of design considerations (the underlines on the second tag cloud aren’t helping) which is definitely not my area of expertise, but the algorithm behind a tag cloud is just as important if it is going to be successful.

Just like any good Ruby on Rails/jQuery developer, I first scoured the internet to see if someone had already solved this problem adequately. What I found wasn’t too promising — many of the plugins were using math that would output text in just a couple of preset font sizes, and wouldn’t fully capture the relative frequency of a given tag. I determined that I would have to build it myself, and because at the time I was much more comfortable with Ruby than I was with JavaScript, I decided that I’d build the logic into the backend rather than build a jQuery plugin. I did get help on the algorithm, however. The best one I found was the following (which I’ve translated into Ruby):

weight = (tag.count-minOccurs).to_f/(maxOccurs-minOccurs)
size = minFontSize + ((maxFontSize-minFontSize)*weight).round

For the code above, minFontSize and maxFontSize are constants that you decide beforehand that dictate the font sizes for the least occurring and the most occurring tag. For my purposes, a min font size of 5px and a max font size of 100px worked nicely. minOccurs and maxOccurs need to be determined algorithmically before running the above code (this is quite easy for my setup, and we’ll see). The way this code works is slightly cryptic, but basically it first determines a ratio of how much the tag differs from the lowest tag relative to the entire span of tag counts, and then uses that ratio multiplied by the span of font sizes to determine how much greater the font size should be for a given tag above the minimum font size.

The rest of the code isn’t too difficult, but took a while for me to configure correctly. To start, it’s a little unclear where exactly this code should go. I initially created a tag_cloud method in the Tag model, which I then called in the controller to pass to the tag cloud view, but that doesn’t really make sense because the logic here has to do with font sizes and other visual considerations and thus shouldn’t be in the model. I ended up putting all of the logic in its own method in the tags controller.

def tag_cloud
   tags = Tag.asc(:name)
   if tags.length > 0
      tags_by_count = Tag.desc(:count)
      maxOccurs = tags_by_count.first.count
      minOccurs = tags_by_count.last.count

      # Get relative size for each of the tags and store it in a hash
      minFontSize = 5
      maxFontSize = 100
      @tag_cloud_hash = Hash.new(0)
      tags.each do |tag| 
         weight = (tag.count-minOccurs).to_f/(maxOccurs-minOccurs)
         size = minFontSize + ((maxFontSize-minFontSize)*weight).round
         @tag_cloud_hash[tag] = size if size > 7

All I’m doing here is storing the tag objects and their calculated sizes in a hash to send to the view. I’m excluding tags from the hash with calculated sizes less than 7 for purely aesthetic reasons (there were a ton of tags, and having all of them in the tag cloud didn’t look great).

The view code, written in Haml, is even more straightforward.

   Most Frequently Used Tags
- if @tag_cloud_hash != nil
   - @tag_cloud_hash.each_pair do |tag,size|
      .cloud_element= content_tag(:a, tag.name.downcase, { :href => "#{tags_path}?tag=#{tag.slug}", :title => "#{tag.count} artworks", :style => "font-size:#{size}px;" })

Actually, the part of this project that took the most time were the stylesheets, mostly because I find CSS in general to be really counter-intuitive. It’s always unclear to me what styles are being inherited when I’m working with large stylesheets. Luckily, I’m writing the styles in SASS which helps a lot. Here’s what I came up with:

   display: block
   width: 600px
   margin-left: auto
   margin-right: auto
      text-align: center
      display: inline
         text-decoration: none
         line-height: 110%
         vertical-align: middle

Put all of this together and you get a pretty nice looking tag cloud. There are of course tons of possible improvements, and it still looks nothing like my example of a well done tag cloud, but this is a good start and is a big step up from a lot of the tag clouds I’ve come across online (including the one on this site). If I ever come back to this project to improve it, I’d probably redo it in jQuery rather than keeping the logic on the backend. While writing the code in Ruby was (I think) much more elegant than a potential JavaScript solution, moving to frontend code would open up the doors to tons of fancy effects. And fancy effects are cool.

The Beginning

I’ve been a “liberal arts person” my whole life. For most of my academic career, I have identified English and History as my favorite courses. But oddly enough, Physics class turned out to be the most interesting class in high school, and BC calculus was my favorite class in the Winter term of my freshman year in college. I realized that this interest wasn’t isolated for the last couple of years — in my spare time, computer programming has been a hobby of mine since sixth grade. It’s taken me 8 years to realize that I actually love applied math, especially when it results in a cool video game or a groundbreaking website. About two months ago, in the middle of the first academic course I’ve ever taken in computer science (Intro to Java, of course), I realized that I had to pursue this discipline more seriously. I had way too much fun at school last term to not continue with computer science.

Since then, I’ve thrown myself headfirst into the tech world. Over the past two months, I’ve created a Twitter account (@mmcnierney), joined Hacker News, and created a GitHub account. There are probably more — I can barely keep track of it all. Oh yeah, there’s this blog too.

The best part of it all is I’ve had the incredible opportunity to intern at Art.sy this summer, a start-up based in New York City that wants to be the Pandora for the art world and has some serious potential to shake up the fine art industry. Over the past month, I’ve gone from knowing very little about Ruby on Rails and jQuery, not to mention never having heard of git, Backbone.js, Haml, SASS, or MongoDB, to having a fairly solid working knowledge of the “bleeding edge” of web development. Just as exciting has been all I’ve learned about start-up culture from working in General Assembly, which has turned out to be the greatest work environment imaginable, as well as all the lessons I’ve had in managing tech teams from both the founder and the head of engineering. More on that later.

I’m at the very beginning of what I hope will be a long career in this industry, and I want to record all that I’m observing and learning. I’m going to be documenting the programming challenges I’m working on, because the more I learn about open source the more I want to contribute back to the community that has given me so much for free. But I’m also going to be commenting on start-up culture and the more intangible things I’m learning, while talking about the projects I’m working on and what I’m doing during the school year to stay connected with this incredible tech world that I barely knew existed until very recently. I intend for this blog to have something for everyone, so enjoy! I know I will.