As many of you know, we are an independent bootstrapped company. Since we offer a free service, understandably, people always want to know how we keep the lights on, pay our ginormous hosting bills and still manage to keep the Imguraffe well fed.

We are able to support the company with revenue generated from ad sales, Pro accounts, commercial hosting and schwag from the store. A sincere thanks to all of you that support us through these paid products or decide to not use Adblock while browsing Imgur!

On the ad sales side, we work with large branded advertisers as well as ad networks. Ad networks are third-party companies that work with thousands of websites and hundreds of advertisers. They act as the middleman, bringing Imgur ad campaigns from advertisers we don’t work with directly. Although we have very strict guidelines for the types of ads we accept (only two formats, no auto-sound ads, no auto-expanding ads, no pop-overs or unders), we can’t always identify every campaign that’s running. Even with a ton of screening mechanisms in place, sometimes bad ads sneak through. Please know we hate these ads, too! We use every report we get through support@imgur.com to track down the offending networks and campaigns and squash them as soon as we can.

Ads play an important role in supporting the site, but we would prefer that they add value, or at least not detract from your experience. As part of our ongoing effort to maintain better control of our ads and to improve our ad quality, we are looking to develop direct relationships with our advertisers. To forward that goal we are excited to announce a new self-serve ad platform. This new system will allow you (or your company) to easily setup an ad campaign that will be displayed to your fellow Imgurians.

How does it work? Easy.

1. Visit our self-service page
2. Choose to target US only or the entire world
3. Select your budget
4. Upload your ad (or you can create one on the platform)
5. Enter payment details and submit

After a quick review to ensure that the creative looks good and your landing page is working, we will set the campaign live, typically the same day.

Aside from knowing that our community is full of awesome, funny, good-natured folks that love cat GIFs, we have also provided a few quick stats about our audience. If you are interested in targeting a specific geography (city or country) or if have any other questions about display ads or sponsored image ads please email us at sales@imgur.com.

75M+ unique visitors (almost 50M from US)
340M total visits per month
4.1B page views per month
70% Male
Over 50% Ages 18-34

Matt
Chief Operating Officer, Imgur

If you’ve ever loaded a page on Imgur with a lot of comments, you’ll notice that it’s quite slow right now. We’re working to fix that, and part of that solution is sending comment data to the web browser to build the tree of comments rather than building it on our servers and sending out the result to you. By doing that, we off load a lot of the processing power to the web browser and also can utilize caching to make it even faster. Some pages can have a lot of comments to lay out – thousands in some cases, and each comment contains at least 19 elements, so we could be laying out around ~19,000 elements. Whether we do that in jQuery or native DOM is a choice: is the benefit of jQuery (“write less”) worth the performance penalty? Let’s examine the performance penalty to decide.

I wrote a small library called ThinDOM that sits on top of the native DOM methods and lets you do fancy chaining like jQuery. I’ve written a test suite to examine the performance characteristics of jQuery vs. using innerHTML vs. ThinDOM, and through the wonder of technology you too can replicate my results! Science!

jQuery, like all abstractions, leaks. The promise of jQuery is that you don’t need to know about DOM, you just need to know about HTML and JavaScript, but it leaks because, if I know a bit about DOM, I can write a library that is an order of magnitude faster, and, if I don’t know about DOM, then my code is going to be awfully slow. Knowing when to use jQuery is knowing when you aren’t going to be blindsided by these performance issues, or when the performance penalty is less than the cost in developer time – time spent writing the code.

On a site like Imgur with sometimes hundreds of thousands of people hitting images with hundreds of comments, even a small performance gain can be “worth it” since developer time is averaged out over every user. As we implement this feature over the next few weeks we hope this should make captions feel much more responsive, especially on more popular images.

I ran all tests on a machine with a Core i5 760, 16 GB of RAM, on Windows 7 SP1 on Google Chrome 26.0.1410.64 m.

Jake
Front End Engineer, Imgur

Follow the conversation by using #AskImgur.

Follow @imgur

Now, here’s a cute sloth:

In creating the app icon, we took to the gallery for inspiration. Aside from the favicon (browser icon) and various merchandise that uses the ‘i’, the community has embraced the ‘i’ in their own Imgur-themed original content:

These posts don’t all use the same font or style, but they all make the dot on the ‘i’ green! This exciting revelation also opened our eyes to how much the green dot is used for design elements on the site:

Thus, we designed another brand icon that stands out from the crowd. In comparing the Dot to other app icons, it really pops!

In short, the dot has always been there, but now has been introduced to the ranks of the Imguraffe and the trademarked ‘i’.

The making of the Dot

In the best interest of Tech Tuesday, I’ll take you through how I created the icon! To start, I found a really simplistic tutorial online for making a sphere type shape utilizing photoshop (http://www.youtube.com/watch?v=CeSjmxNfqxg). This album will quickly highlight the steps for this as well:

Imgurians, what do you think of the Dot?

**The official Android app (BETA) is now available in Google Play in Australia, Canada, and the UK.
**Apple continues to reject our iPhone app because of images of PedoBear, but we’re hoping to be approved soon.

Tony
Head of User Experience, Imgur

So, what do each of these classes do? Let’s talk.

Models

A model is where you store data about a specific item, one of our most commonly used Models is a Comment. This model will contain data about a comment, id, the id of the gallery item it’s attached to, and the comment text itself. What is so great about Backbone Models are that we just have to point them to the API endpoint, and it will automatically sync the data for us. Since both Backbone and the Imgur API follow REST standards, they can easily communicate with each other, and you don’t have to spend time tweaking things to make them work together. Here’s an example of how you can create a comment with the Imgur API and a BackboneJS model:

var Comment = Backbone.Model.extend({
  'urlRoot' : 'https://api.imgur.com/3/comment'
});

var myComment = new Comment();
myComment.save({
  'image_id' : 'j17loBb',
  'comment'  : 'Ace Ventura rules!'
});

By calling .save() we not only create an object with the given data to manipulate in JavaScript, but also send a POST request to the Imgur API to create it in the Database. That allows us to worry about other things, rather than when to save the data to the API. In a similar vein, you can call myComment.destroy() and it not only deletes the JavaScript object, but also deletes it from the server and triggers a destroy event. There are a number of methods and events that allow models to communicate with an API behind the scenes so you can worry about other things.

Views

Backbone views is probably where we save the most code, simply because we are reusing the data every chance we can. When you hit a gallery view in the app then click an image, we don’t actually fetch any data for that image. We already have the data from our first request, so we simply show you a different view of the image. By doing this we can keep everything, sync across the app and greatly reduce the number of requests we need to make to the server. Here’s a quick example of how you might render an Image:

//First create the View Class
var ImageView = Backbone.View.extend({
  class    : 'image',
  initialize : function() {
    this.listenTo(this.model, 'destroy', this.remove);
  },
  template : _.template(
      '<h1 class="title">' +
        '<%= _.escape(title) %>
      '</h1>' +
      '<img src="http://i.imgur.com/<%= id %>.jpg />'),
  render : function() {
    var attributes = this.model.toJSON();
    this.$el.html(this.template(attributes));
    return this;
  }
});

Now we can use the view with a Backbone Model. For the sake of simplicity, let’s say we have an Image Model, myImage, with all the data we need.

var imageView = new ImageView({
  'model' : myImage
});

//this is simply taking the html rendered in 
//the image view, and using jQuery to insert into the DOM for us
$("#comments").html(imageView.render().el);  

The output for imageView.render().el is going to look something like this:

<div class="image">
  <h1 class="title">
    Went running yesterday for the first time in a long time. 
  </h1>
  <img src="http://i.imgur.com/j17loBb.jpg" />
</div>

We are also using the _.template method in the example since it comes with Backbone, but you can use any JavaScript templating system that you want. By using a template, we can say that we want all of the objects rendered with this view to look the same. We also have some protection against people trying to inject html into our website by calling _.escape to the title, which is user input.

Now a user wants to delete that image, normally you’d have to setup code to make a delete request to the server, delete the object, and remove it from the HTML as well. However with BackboneJS, we can simplify that to :

myImage.destroy();

In the initialize function in the ImageView, we have a call to this.listenTo. This adds an event listener for the model on the ‘destroy’ event, and will call the remove function associated with the view. There is a default remove function in all BackboneJS views that removes them from the DOM, and all of the handlers associated with them. As we mentioned earlier, the destroy function also makes a DELETE request to the URL in the model. By simply destroying the model, we have removed it from the screen, memory, and the database. Pretty sweet, right?

Collections

A collection is, at its simplest, an array of models. The great thing about collections is we can simply hook it up to a URL like we did with models before, so you can just say “fetch” this data, and you’ll get all of the data your heart desires. Let’s take a look at how the Imgur Gallery works:

var gallery = new Backbone.Collection([], {
  'url' : 'https://api.imgur.com/3/gallery'
});

gallery.fetch();

Now we have a Collection of models, with all the image data for the front page of Imgur. What can we do with all of this new found data? Well, we have already defined a view for images, ImageView. Now, let’s use that to render all of the images in the gallery.

First of all, we need to create a collection view. This is the same as a normal view, but you’ll be passing a collection to it. The render function will know how to deal with an array rather than single model.

var GalleryView = Backbone.View.extend({
  class  : 'images',
  render : function () {
    //we don't want any old stuff there if we render this multiple times.
    this.$el.empty();

    //loop through each model, and render them separately
    this.collection.forEach(this.renderOne, this);
    return this;
  },
  renderOne : function(image) {
    var view = new ImageView({
      'model' : image
    });

    this.$el.append(view.render().el);
  }
});

Now that we have the collection view defined, and we have the collection data, we can render it to the screen.

var galleryView = new GalleryView({
  'collection' : gallery
});

$('body').html(galleryView.render().el);

So the output of the HTML body will be:

<body>
  <div class="images">
    <div class="image">
      <h1 class="title">
        Nobody reads anything on twitter, and Ricky Gervais proved it
      </h1>
      <img src="http://i.imgur.com/mouHhUz.jpg" />
    </div>
    <div class="image">
      <h1 class="title">
        Went running yesterday for the first time in a long time.
      </h1>
      <img src="http://i.imgur.com/j17loBb.jpg" />
    </div>
  </div>
</body>

Router

The last of the major Classes of Backbone is the Router class. This class is where we define when we want to use the views and collection data. It’s basically the glue that brings everything together. The routes are url paths that you intercept and want to display. Basically, they use regular expressions to make everything in your life easier. Let’s take a look at how we might render a gallery then move on to a single image with the classes we used before.

var ImgurRouter = Backbone.Router.extend({
  routes : {
    '/:id' : 'showImage',
    ''   : 'showGallery'
  },
  initialize : function() {
    this.gallery = new Backbone.Collection([], {
      'url' : 'https://api.imgur.com/3/gallery'
    });

    this.gallery.fetch();
  },
  showImage : function(id) {
    //find the image in the gallery, saves ajax requests!
    var image = this.gallery.get(id);    

    if(image) {
      var imageView = new ImageView({
        'model' : image
      });

      $('body').html(imageView.render().el);
    } else {
      //show a fancy 404 page with a giraffe.
    }
  },
  showGallery : function() {
    var galleryView = new GalleryView({
      'collection' : this.galleryCollection
    });

    $('body').html(galleryView.render().el);
  }
});

var router = new ImgurRouter();
Backbone.history.start();

Let’s say your website is http://imgur.com. When you visit that link it will go to the showGallery function, render the gallery collection, and insert it into the body tag on the page. If you go to http://imgur.com/j17loBb it will call showImage, and take you to a page where it shows that image. We also did a really quick improvement to reduce the number of ajax requests in the router. We are simply selecting all of the images in the gallery on load, then using that data to navigate through the application. It’s important to note that if the ajax request isn’t finished by the time you try to load the pages, you’ll see nothing. To fix that, we can add some wait times and do all sorts of checks in the router, or we can simply modify the view. If we add the ‘add’ event handler to the gallery view, we can render them as data comes back from the server.

The biggest advantages to using backbone are code clarity, organization, simplicity, and reduction of AJAX requests. The way Backbone breaks down code into chunks allows us to easily organize the codebase. Also, by maintaining data in collections and models we can keep track of them to re-render later and in different ways depending on the view.

While these are some watered down examples of how you might use BackboneJS to build your own application with the Imgur API, I hope it helps you start off with some awesome apps. There is a lot more information on BackboneJS at http://backbonejs.org, http://backbonetutorials.com, and http://codeschool.com. Hope to see some awesome apps built with the Imgur API and BackboneJS! Brace yourself; the Imgur Mobile Application is coming.

Josh
Front End Engineer

Nailed it.

Favorite comment by TheFeralCat: Thrift Thor.

The trouble with perspective.

Favorite comment by McTrick: Butterflies in the sky, I can stand twice as high. Take a look on top of books.

My doctor said: “You kinda look like that guy on the wall over there!”…

Favorite comment by chemistrydoc: Oh my G.E.R.D.

My wife and I are expecting our first child…and apparently a cat too.

Favorite comment by FreckleCharms: If I fits…

Whoever did this just won at life

Favorite comment by napsmear: http://imgur.com/yRUsk8C

Nothing in this picture is not Snoop Dogg

Favorite comment by anniexkimchi: Awyeah. It’s a sunizzle, and treeizzle, with leavizzles on its trunkizzle, and I love the grassizzle, and the beautiful skyizzle.

Boston looks like a ghost town right now. (Click image for full album)

Favorite comment by Killingjezus: So when everyone should stay inside, redditors go outside?

If you faceswap Justin Bieber and Taylor Swift, they look like a cute lesbian couple

Favorite comment by Zalophus: Turns out not face swapping still has the same effect.

oh…..OH I look so FABULOUS.

Favorite comment by merpderps: waaaahhhhhhhhhhhhhow you doin?

Perfect Timing!

Favorite comment by stevengracie: I’m not even joking this time somebody put 5 onions in my lemonaid

If you build it, will they come? Probably. But they won’t come back if there are blatant memory issues within the app. The task of cleaning up memory seems daunting with so much happening behind modern JS engines. Where do you start looking?

Dangling References

In lower level programming languages, you explicitly allocate memory whenever you use variables during runtime. Then you use the space you’ve allocated for whatever you want and, when you’re done, you de-allocate that memory so it can be reused later to hold other things.

Luckily in JS, we have a very “magic” simple way of doing that, which is to declare that a variable and let the garbage collector (GC) worry about which variables we are ‘done with’. Once the logic gets complicated and there are more things going on (e.g. loading images, fetching comments, rendering views) the amount of memory space there is to work with for each task shrinks dramatically. If the GC cannot resolve whether something is no longer needed, it does not free the memory, causing a memory leak.

An example

  <html>
      <script>
      function leak() {
        // 1. Ref to the <button/> in current scope.
        var el = document.getElementsByTagName('button')[0];

        // 2. Make an 'onclick' property in the element that "subtly" refs el.
        el.onclick = function() { 
          // el is defined in here due to the closure created in leak()
          alert('hello world!');
        };

        // 3. Take up a fair chunk of memory within this closure by 
        el.leaky = 'awfulness'.split('').join('awfulness')
                              .split('').join('awfulness')
                              .split('').join('awfulness');
      }
    </script>
    <body onload="leak()">
      <button>foo</button>
    </body>
  </html>

The GC works to free memory if the proper references to an object are broken. In this instance, when we call leak(), it creates a closure that contains the variable el, which is a reference to the <button/>. If all we want to do is alert ‘hello world!’, then we probably don’t notice the closure within the scope of the onclick function. But that doesn’t mean it’s not there. So it’s actually possible to use el within the onclick function due to this.

Logically, we would never use el again in that context, though the GC can’t be absolutely certain of that. Hence it never cleans up el after leak() has been run.

To fix this, we have to explicitly break the reference that el holds by setting it to something like undefined or null. An alternate solution could be avoiding the closure altogether.

    ...

        // 3. Take up a fair chunk of memory within this closure by 
        el.leaky = 'awfulness'.split('').join('awfulness')
                              .split('').join('awfulness')
                              .split('').join('awfulness');
        el = undefined;
      }
    ...

This one case of memory management merely scratches the surface of the optimizations we are constantly on the look out for as we try to improve your journey across the GIF filled expanses on this side of the Internet.

Jim
JS Engineer

I’m currently working on migrating some of our data to HBase. Unlike MySQL, which we heavily use, HBase is a non-relational database. It is an open-source solution modeled after Google’s BigTable. Its distributed and fault-tolerant design allow it to scale to large sets of data. If you interested in learning more about how it works, check out Google’s publishing.

There are two types of data to focus on: image views and image referrals. Both sets of data come from logs that our content delivery network provide to us approximately every 20 minutes. Each log file is, on average, 1.3GB in size. In one day that’s about 94GB. If we uncompress those logs, we then have around 650GB of data in single day. Sure, Google handles a lot more data than this, but we are a small team!

We then parse those logs using MapReduce, extract the image hash, and keep a count of how many times that image has been viewed. Lastly, we store this information into Redis, an in-memory, key-value data store. This approach has worked well and, for the moment, continues to work just fine. We can write to Redis at a very high rate without any hiccups. We estimate, however, that this data will continue to grow such that our Redis instance will run out of memory. We could continue to upgrade the hardware, but we are looking into a different approach.

We are experimenting with storing views into HBase, and here are some of the benefits we like:

• HBase is a distributed data store. If we run low on memory, we can easily scale by adding more machines. Also, this means that the cache can be split among multiple machines. We cache a lot here.
• Since HBase works on top of Hadoop, we get the benefit of data replication.
• Columns are sparse, so we can store thousands to millions of columns in one row without needing to define an explicit schema.
• It’s better at persisting data than Redis.
• We can replicate to a separate cluster as another safety measure.
• If we design our system correctly (fingers crossed), we can take advantage of the high write-throughput that Hadoop can offer when updating our image views. This would be highly beneficial since it is the reason we started using Redis in the beginning.

Another added benefit of pursuing HBase is that we can also think about other datasets to store. One such dataset is the image referrals, which estimates to a few terabytes. We can then use this data as another way of calculating the ranking of gallery images.

Many of these details are still being worked out, but these are the basic ideas. As we get smarter and figure out other ways to use all the data we have, you may hear more about Imgur and big data.

Carlos
Software Engineer, Imgur

We calculate a different popularity score for images posted in these two groups. Let’s begin with the latter. When an image URL is first shared to a social network, we begin collecting data in order to compute an overall popularity score which takes into account number of places the image was posted and number of social media interactions (tweets, Facebook shares, Reddit likes, etc.). Once an image has been linked to enough sources and has gained adequate popularity on social networks, it becomes a candidate to be entered into the most viral gallery. This ensures that only extremely popular images will be selected as candidates.

User submitted images are treated a bit differently. We trust Imgurians to upvote good content and downvote bad, which makes the aforementioned data irrelevant. For these images we use a very simple equation to calculate the score:

score = (ups – downs) + (views / CONSTANT)

Now that we have a way to make sure each image is popular enough, we want to add time to the equation. This will give us an overall virality score. This virality score is what we use to sort the images when you view the gallery like this:

or like this:

We use a modified version of the reddit hot algorithm (check out these awesome graphs) to accomplish this.

First we find the sign of the score s = {1, 0, -1}

x is equal to the absolute value of the score:

t is equal to the time difference (in seconds) between the submission time of the image and midnight on the day the imgur gallery launched.

There are quite a few equations that do similar things, but this one was our favorite for a few reasons:

1. It uses a logarithmic scale, so the first 10 votes count the same as the next 100. This helps to bump up good content and weed out bad immediately after being posted.
2. The virality score doesn’t go down as posts get older. Instead, newer posts will have a higher score. This means the v.s. will only change when a vote is made on the image. Which makes it easy for us to store the v.s. in the database and to offload our sorting to an indexed column.
3. Submission time is a huge factor on the algorithm, so newer posts will be weighted higher than older.

We have recently started to use the virality score as our primary method of deciding what gets put into the most viral section. Previously, we used strict limits, meaning that once an image would become more popular than the limit, it would be added. This caused us a lot of problems with vote inflation.

In the past day (at time of posting) there were 1,200,000 image votes.
Two months ago there were only about 900,000 image votes in a day.

Breaking this down to votes per image, images are receiving more and more votes, which required that we come up with a scalable solution. We now compare the virality score for an image against a sliding percent of all images on the most viral gallery. If a candidate has a higher score than the majority of the subset of images, it will be added. When there are fewer images in the most viral gallery, we choose a different subset to make it slightly easier for images to make it. The benefits of doing it this way are:

1.  Only the best of the best will make it onto the front page.
2.  If the content on the front page is fantastic, the content coming in will have to be super fantastic as well, which continuously improves the content on the front page.
3.  No hard limits, which solves the problem of vote inflation. A newer image that has fewer points, but gains points rapidly will be added before an older image with a lot of points, but slow growth.

This method has been running on the site for almost a week now, and we have noticed the quality of content on the most viral page staying consistently high. We strive for the best Imgur experience for our users, and we believe that with this new addition to the site we will be able to deliver the best content quickly. Keeping up with our goal to satisfy that need for instant gratification while seeking out, funny, interesting or heartwarming pictures. Or cats. Lots and lots of cats.

Brian
Front End Engineer

Jacob (left), our newest Front End Engineer, hails from New Hampshire. His primary hobby is writing strongly worded arguments on the Internet. If you have a dumb opinion, prepare to receive downvotes! His other talents include the impressive ability to tap the intro to Through the Fire and Flames in Guitar Hero 3, and being 1800 MMR on two accounts in Heroes of Newerth. Jacob’s favorite book is Ender’s Shadow, and he’s fully ready to to tell you why it’s better than Ender’s Game. Jacob is currently chuckling about this image in the gallery:

Brad (middle) joins us from the great state of Ohio, where he worked with the Columbus Crew. When he’s not serving Imgur as the best Inside Sales Manager the world has ever seen, he enjoys running, mountain biking and live music. He would like the ladies to know that he is a great cook and makes a mean “mystery stir fry.” He will knock your socks off with his knowledge of good beer and red wine. He is a self proclaimed “complete soccer nerd,” which we’re pretty sure is true since he owns a 2008 MLS Cup Champions ring with his name on it. Check him out looking pretty badass carrying some weird weapons:

Carlos (right) joins the team as a Front End Engineer. When not laying down his sweet coding skills at Imgur, he’s either a servant to his two cats, programming side projects, hanging with friends, or traveling. He is obsessed with soccer and can do some really cool tricks. One of them is to land the ball on the back of his neck and take his t-shirt off without dropping the ball. Yes, it is that sexy, but contain yourselves; he has a beautiful wife and daughter. He also thinks that, day by day, he’s getting better at the office’s favorite game, Super Smash Brothers, but it will be a fiery day on Hoth when he actually beats the rest of us. Carlos would like to thank the user who posted the below image to the gallery because he laughed.

Welcome to the Imgur team, guys! We’re so excited to have you!