Bindle Blog

Augmenting Meteor: plugging gaps with external services.

Tom Coleman — Thu, 19 Jul 2012 06:20:16 +0000

Meteor is still in it’s infancy. There’s a good chance you’ll want to do something it is not mature enough to achieve right now. What’s a poor developer to do? When you can’t roll your own solution, you could consider using an external service that talks to your meteor server to get things done. In this article I’ll describe a couple of ways we did this to augment League, our sport-management application.

Sending emails

As a seasoned Rails developer, I’m used to the nicer things when it comes to emails. ActionMailer is pretty good these days, and the premailer gem allows you to use (most) of your styles freely within your emails.

Things are a little more raw and exciting in the meteor world; Node modules exist for sending emails, but integrating node modules into a meteor deployment can be a challenge, and it doesn’t seem like a premailer replacement is out there.

So, we took the “easy” road, and set up a simple rails project with a single controller + action: to fire off emails:

class MailsController > ApplicationController
  def create
    mail = params[:mail].to_sym
    data = ActiveSupport::JSON.decode(params[:data]).with_indifferent_access
 
    Notifications.send(mail, data).deliver
    head :ok
  end
end

Calling out to the mailer from meteor easy enough:

Meteor.http.call 'POST', LeagueMailerConfig.url, options

Serving calendars via `.ics`

We wanted to make keeping track of a League team easier by integrating with calendaring apps via the .ics format. It isn’t possible using pure meteor right now because there is no server side routing at the moment (it serves up the same html|js|css mix whatever URL you hit).

We decided to re-purpose the league-mailer rails server mentioned above and create an end-point that communicates to the league app via DDP – meteor’s distributed data protocol. DDP is a pretty simple protocol and it wasn’t difficult to create a ruby DDP client. Here’s the gem if you want to use it yourself.

Then we just needed to use event-machine to subscribe to our games publication to fill out a games collection and get our results:

module LeagueServer
  # pretty simplistic, but it seems to work
  def self.get_games(team_ids)
    games = nil
    EM.run do
      league_client = if ::Rails.env.production?
        RubyDdp::Client.new('beta.getleague.com', 80)
      else
        RubyDdp::Client.new('localhost', 3000)
      end
 
      league_client.onconnect = lambda do |event|
        league_client.subscribe('games', [team_ids]) do |result|
          games = league_client.collections['games']
          EM.stop_event_loop
        end
      end
    end
 
    games
  end
end

From there, it’s standard rails routing and some harnessing of the excellent iCalendar gem to get the right data published at a URL of your choice!

In the future I hope to pull both of these services inside the League meteor app.

Page Transitions in Meteor: getleague.com

Tom Coleman — Thu, 21 Jun 2012 07:08:36 +0000

Update: I’ve released my reactive router and the (complete) transitioner class. Enjoy!

Note: dear readers from the future!: at the time of writing the released meteor version is 0.3.7; as Meteor is a rapidly changing framework, it is likely this post is out of date!

I’d like to briefly walk through the process that we used to implement page->page transitions in the League project [1].

Meteor apps are single page, client side Javascript applications, but this doesn’t mean you can’t have more than one screen. Smartphone users are more than familiar with the sense of ‘space’ created by having pages slide into one another. In this article I’ll describe how I used a Transitioner class in meteor to achieve page transitions.

HTML Setup

Our main index.html looks like:

  
    {{#if_with current_page}}{{> one_screen}}{{/if_with}}
  
  
    {{#if_with next_page}}{{> one_screen}}{{/if_with}}

The one_screen template as you may guess, draws one screen, much like:

The two variables current_page and next_page represent the two pages in the current transition. So if we are transitioning from the teams to the players page, we simply render the teams page into .current_page and players into .next_page and trigger a transition which animates .current_page out to the left and .next_page in from the right:

First page: Click me!

Second page: Click me!

Here’s an action shot of it happening live:

There are some nice touches, like the page that is leaving fading out as it slides out.

Meteor Setup

So where do these variables current_page and next_page come from? The Transitioner. Let’s start this story at the Router. It’s actually a little bit complex, but the short story is that the router sets up a reactive variable representing the current page. Here’s some abbreviated code which uses deps-extensions:

AuthenticatedRouter = Backbone.Router.extend({
  initialize: function() {
    Meteor.deps.add_reactive_variable(this, ‘page’, ‘loading’);
  },
  goto: function(page) {
    this.page.set(page);
  }
});

Route functions call goto() to inform the rest of the application of which page should be visible. The Transitioner basically wraps Router.page() with a delay:

  Transitioner = function(Router) {
    Meteor.deps.add_reactive_variable(this, ‘current_page’, Router.page());
    Meteor.deps.add_reactive_variable(this, ‘next_page’);
 
    Meteor.deps.await(function() { return Router.page() != this.current_page(true); }, function() {
      this.transition_to(Router.page());
    });
  };
 
  Transitioner.prototype.transition_to = function(page) {
    var self = this;
    self.next_page.set(page);
 
    // we defer so that the next page has rendered + is attached before we add the class
    Meteor.defer(function()) {
      $(‘body’).addClass(‘transitioning’)
        .one(‘transitionend’, function() {
          self.transition_end();
        });
    });
  };
 
  Transitioner.prototype.transition_end = function() {
    var self = this;
    self.current_page.set(self.next_page(true));
    self.next_page.set(null);
 
    $(‘body’).removeClass(‘transitioning’);
  });

The magic of reactive programming huh? Simple [2]. I like it.

CSS Setup

This bit isn’t really meteor specific, but you might want to know how to achieve a sliding transition. It’s quite easy if you always want to go left to right:

.current_page, .next_page {
  position: relative;
  @include transition( all 500ms cubic-bezier(0.51, 0, 0.6, 1) 0ms);
}
 
.current_page { left: 0; }
.next_page { left: 100%; }
 
.transitioning {
  .current_page { left: -100%; }
  .next_page { left: 0; }
}

Things are more complex when you want different page transitions to have different animations, check out _transition.scss if you want to see how we achieved League’s other animations.

Let me know what you think about my techniques and if you have a better way to do anything!

currently in alpha testing at http://beta.getleague.com; check it out if you like but please be kind
actually it’s a bit more complex than this as some of my CSS transitions also require the to have the current and next page set as classes. Also there are edge cases to deal with. But the core idea is there.

Animations in Meteor: state of the game

Tom Coleman — Thu, 21 Jun 2012 06:06:41 +0000

Note: dear readers from the future! at the time of writing the released meteor version is 0.3.7; as Meteor is a rapidly changing framework, it is likely this post is out of date!

UPDATE: David Greenspan posted some detailed info about the heuristics that meteor uses to update DOM nodes. The important takeaway: you can achieve animations the ‘meteor way’ if you set an id on your DOM nodes (or a name on form elements). More details below.

A common question that people have as they begin to use Meteor for developing a javascript application is how to implement animations. This isn’t surprising as the example applications don’t really use them and the docs make no mention of it. Yet for a client-side responsive JS app, animating JS changes makes a lot of sense.

In this post I’d like to discuss the animation of a simple expanding div, as seen below.

Click me!

Using CSS transitions

The HTML5 way to achieve this is using the CSS3 transition property. CSS transitions work when the class changes on an element. The browser will animate the transition of a CSS property between the old value (as specified by the first class) and the new.

1. Reactively: the Meteor way

It fits with Meteor’s reactive setup to force the class on an element to change via a variable change. For instance, with the correct CSS setup, we could do something like:

Click me!

Template.foo.open = function() { if (Session.get(‘open’)) { return ‘open’; }};
Template.foo.events = {‘click #clickme’: function() { 
  Session.set(‘open’, true); 
}};

The only challenge in this technique is naming the session variable to use to store the state of the

[1]. However, it’s usually sensible to call it something like this._id + '-open', depending on exactly what you are doing. In the future, meteor will have ways to attach reactive variables to the “template invocation” that’s currently rendering—this will avoid using the session in ways that it’s not really intended for.

Please note that this technique only works if you set an id on your

. This is because it isn’t easy for meteor to tell when you’ve simply changed the class on an element—from meteor’s perspective you may have deleted the original

and created a totally new

which is identical except for the classname change. Setting an id tells meteor that, no, in fact that is the same element after all. (Similarly, you can just set the name attribute on a form element).

2. Directly: the jQuery way

The more direct, jQuery way to do it is to simply go

Template.foo.events = {‘click .somewhere’: function(e) { 
  $(e.target).addClass(‘open’); 
}};

This technique will work, however, be very careful. If for some reason the template needs to be reactively re-drawn (for instance the underlying data is updated), the class-name will be lost as the element will be re-rendered. There are techniques to try and isolate meteor’s re-rendering (for instance using Meteor.ui.chunk in a helper, the {{#each}} helper, or a using separate template). However, you are basically swimming upstream with this approach; for this reason I think doing things this way is likely to be a maintenance nightmare. Use at your own risk.

What other techniques are people using for animation?

the nice thing about using a session var is that the
will remain open if there is a hot-code change. If this isn’t what you want, you might consider adding a reactive variable to your data object

When the Panda strikes — Why you can’t afford to ignore SEO

Tom Coleman — Thu, 29 Mar 2012 02:23:41 +0000

You’re too busy for SEO. You’ve got a hundred things in the queue to get your latest site off the ground, and time spent optimizing for a robot is at the bottom of the list. That’s fair.

Search engines shouldn’t require us to do anything. Just build a good website, make some content, get incoming links (so people can find you!), and, if it’s interesting enough, it should appear on the first page. Sounds reasonable?

Well, unfortunately, neither of these things are true. Here’s the story of how we discovered we weren’t appearing in Google searches for ‘Bindle’ and the journey to find a solution. Along the way we learn the importance of restraint to keep the GoogleBot happy.

Where are we?: The Problem.

Just three months ago when you tried to find Bindle via Google search we’d be absent from the results… until page 38. The only hint that our site existed was passing reference from blogs that had featured us. Bing, on the other hand, proudly displayed us at #6 on their results list. What was going on?

2 relatively minor blogs linking to our homepage, but no sign of that homepage itself.

In Bing, on the other hands, we appear at #6.

Here Google's Webmaster Tools says we should appear on page #38, although I never actually found us.

After remedying most of the obvious SEO missteps documented widely on the internet, our rank was unchanged. For a creator it’s absolutely frightening to feel that the product is out of your control. Thus you might imagine that we were both stunned and worried that somehow the almighty GoogleBot had forgotten about Bindle altogether. Could this be the infamous Panda update in action?

Loading time

The Bindle team was left with delving into the smoke-and-mirror optimizations that are far from well-defined. The first course of action was to resolve any issues with our loading times.

Google cares about the speed of the internet: Pages need download quickly. We thought the previous load time was fairly fast. Nevertheless the challenge was undertaken and now we fully utilize caches, CDNs, gzip, everything you can think of. Did it fix it? Nope, but the upside is Bindle is faster than ever.

Duplicate Content

Google doesn’t like it if more than one URL has similar content. The previous iteration of Bindle had invitation links that rendered custom copy depending on the invite, we couldn’t have these invites showing up in the index so we needed a link[rel=canonical], otherwise our friendly gBot might think we’re up to no good.

Bindle has two web accessible servers: a staging & production. We assumed staging to be obfuscated because there were no inbound links, sitemaps or anything that noted its existence. So when we learned our staging server was somehow found and indexed by google it was clear that a staging specific robots.txt was in order.

Did either of these solutions fix it? Nope, but we can rest easy knowing we’ve resolved our duplicate content problem.

Keyword limit culprit

We stumbled upon the solution serendipitously. Without informing us of the fact (or why) the gBot had decided we were spamming the keyword “bindle” and that it would be best not show us in the results for any query involving it. Which, obviously, made it kind of hard to find us.

After some fairly mindless deletions of the word “bindle” from the homepage, we achieved the holy grail:

Finally, after some spurious deletions of 'bindle' from the homepage, we appear in our rightful spot at #6 in google!

Bindle redesigned

Dominic H. Nguyen — Mon, 26 Mar 2012 06:49:30 +0000

Every so often in the life cycle of a website it’s evident that change is necessary to push the product to next level. This time around we’ve made design changes that refine your experience down to the smallest detail – a big deal. It’s our pleasure to announce a major refresh that opens the site to all, features a new design, and showcases the improved collage.

Open to all

With the newest updates, we’ve opened Bindle up to everyone. Share Bindle with your friends, no invitation required!

New design

We’ve made a big leap that streamline the creation process, speed up browsing, and really simplify your experience. Find out what’s inside a Bindle in a glance with collage thumbnails.

Collage 2.0

Thought our collage was cool? We’ve introduced improvements we’re sure you won’t find anywhere else such as magical item-outlining, slideshows, and smart panning.

Mobile friendly

As an added benefit for folks browsing Bindle on their mobile devices and tablets. We’ve made the site more friendly for any screen size. Take a look for yourself.

Ever wanted to touch Bindles on your iPad? Now you can…

Rack Middleware for SEO, fun and profit

Tom Coleman — Tue, 20 Mar 2012 00:25:00 +0000

Thank god for Ruby and DSLs. Gone are the days of developers resigned to using apache and having to mess with it’s arcane configuration syntax. The plethora of webservers used these days combined with simplicity and power of Rack middleware makes for a much simpler life for us rubyists.

Thanks to a variety of Rack middleware, Bindle is faster, more efficient, and has better access for the Googlebot. This post will give you some tips to do the same.

We have a pretty standard setup:

Rails 3.1
Ruby 1.9
Heroku Cedar

rack/cache

Got some assets on your site that are expensive to generate? Thinking about the CPU cost of repeated access? Well worry no more, a reverse proxy cache [1] will make that problem disappear. For some examples, consider dragonfly, reverse_proxy and split_assets below. As a bonus: googlebot stays happy when things are fast.

We use memcached to actually keep the cache around, which is easily accomplished on Heroku. Though also Heroku adds rack/cache for you, others may want to do something like:

config.middleware.use Rack::Cache

rack/deflater

GZipped assets are good. It’s really this simple to get it going on your server, simply add:

config.middleware.insert_before Rack::Cache, Rack::Deflater

You want the deflater to be outside of the cache, I fear strange things may happen otherwise.

rack/rewriter

Task 1: Rails defaults to generating URLs like http://bindle.me/bindles/1. However, it’s possible the Googlebot will find a link like http://bindle.me/bindles/1/. Since Google doesn’t like duplicate content, we need to 301 redirect that trailing slash away.

Task 2: We also employ a URL shortener which redirects requests from bndl.es and www.bindle.me to bindle.me to simplify the user experience and retain the google juice in a single domain.

config.middleware.insert_before(Rack::Lock, Rack::Rewrite) do
  # anything ending in / to the same without the '/'
  r301 %r{(.+)/$}, '$1'
 
  # bndl.es/www.bindle.me -> bindle.me (will then go to the shortener)
  r301 %r{.*}, 'http://bindle.me$&', :if => Proc.new { |rack_env|
    ['bndl.es', 'www.bindle.me'].include?(rack_env['SERVER_NAME'])
  }
end

rack/reverse_proxy

PageRank doesn’t transfer between subdomains particularly well. So instead of hosting your blog at blog.bindle.me it’s better to use a subdirectory format like bindle.me/blog. However, you might not want to use Rails for your blog; perhaps you prefer WordPress, or you’d like to use an external site like Tumblr. How do you redirect your blog from a subdomain to a subdirectory behind Heroku? Enter rack/reverse_proxy. Even though we don’t have access to the webserver, we don’t have to care thanks to rack.

config.middleware.insert_after(Rack::Cache, Rack::ReverseProxy) do
  reverse_proxy %r{^/blog(.*)$}, 'http://blog.bindle.me$1', :preserve_host => true
end

Dragonfly

Dragonfly adopts the philosophy of generating thumbnails on the fly. Bindle generates somewhere along the lines of ten different thumbnails for each image that is uploaded. Instead of worrying about image storage in the cloud, we generate the necessary images on the fly and store them in memory with memcached.

For example this is what we use to integrate Dragonfly into rack:

config.middleware.insert_after Rack::Cache, Dragonfly::Middleware, :images

split_assets

IE throws up some interesting problems. The split asset endpoint solved a particularly thorny one for me:

config.middleware.insert_after Rack::Cache, 'SplitAssetEndpoint', '/split_assets'

Any other interesting middleware you’re using in your projects?

I’m still trying to work out if us Australians, who pronounce it ‘kay-shh’ rather than ‘cash’ are wrong. I feel we probably are—it’s a French word after all.

Is SCSS killing your site’s performance?

Tom Coleman — Wed, 14 Mar 2012 02:17:34 +0000

SCSS and LESS have made waves in the frontend development community. They’ve allowed us to write concise styles in a lean fashion, but is there a hidden performance tax?

The fact is preprocessors are used widely at the production level. But what about performance? What comes out is simply CSS, but how does that CSS compare to what we used to write by hand? How do browsers cope with the reams of machine generated styles?

In this post I’ll investigate how common CSS preprocessing idioms can affect the browser’s rendering performance.

The anatomy of a web-request; load times beyond the first hit

The accepted wisdom recommends combining your assets together into a single large file where possible. Browsers open a limited number of concurrent requests to the server, so given the speed of connections, and the diminutive file size thanks to GZIP, you may as well send as much data as you can on that initial connection [1]. Thus, if we’re to follow this thinking, there are two categories of requests and optimizations that can be made:

Initial requests: This is well covered ground. Suffice to say you will make more substantial gains ensuring your compression, CDNs, sprites, minification and the like are functioning optimally than worrying about the structure of your CSS.

Subsequent requests: When you’ve established a baseline of performance with initial requests, further optimizations will bring you here. Let’s break down the order of page rendering.

In this subsequent request to bindle.me, we see that although the HTML has been returned after 624ms, the DOM is not ready for around 1.5s. Although much of this time is taken parsing JS, it seems that there is scope for gains to made in rendering time.

Download time: The browser hits your server up for the URL. Hopefully you are fast enough that the HTML is returned to the browser within a few hundred ms.
Cached? The browser looks at what assets it needs, apart from a few images that aren’t important to the layout of the page, everything is in cache (0ms).
Parse time: The browser parses the CSS [2] of the page and is ready to render.
Render time: The browser renders the HTML, using the CSS.
Ready to go: The page looks correct (apart from maybe a few images which will slot in later) and is ready to use.

In the first request, the amount of waiting is determined mostly by whether assets need to be downloaded. For subsequent requests, the parse and render time can take as long, if not longer than download time. So subsequent requests are definitely a concern if you want to keep your web app snappy.

The double edged sword: How SCSS can help & hinder

At Bindle we have ~47 icons which have 4 states each. Each of these combinations requires it’s own style rule like so:

a:active.close.icon16:before {
 background-position: -425px -34px;
}

47*4 = 188 styles at the very least. Of course it’s not that simple.

We need .close.icon16:before to take a different state depending on whether it’s a link or a button, which state it’s in (:hover, :active, :focus), whether it has class inverse or checked or current, if it’s in the #sidebar etc etc… We generate ~1000 icon rules, each of which is a single background-position rule [3]. This kind of bloat would not have been possible without CSS preprocessors.

Believe it or not, we had more like 3000 at one point. We’ve pared it down since, but should we add more icons or states we may be overwhelmed. This was not the goal of CSS at it’s inception as evidenced by IE’s lingering problem with too many styles, and obviously it adds to the stylesheet’s size, but how much does it affect CSS rendering time?

Aside 1: ‘Ideal’ HTML + CSS

Purists say that we should separate our form from function. CSS was originally developed in part to help us say what we mean in the HTML and to specify what it looks like in the stylesheet. This step enabled us to go from:

A massive improvement. However, it isn’t very semantic to say “This is red and fancy”. It’s better to say “This is a call to action”:

And to make the .call-to-action class red and fancy:

.call-to-action {
  // CSS preprocessors let us do this; now we are getting somewhere.
  @include red;
  @include fancy;
}

Is this the correct solution though? Is the HTML the right place to be saying this particular is the CTA on this page? Isn’t this a style issue that may change? (Perhaps we have different priority on different @media devices?). Isn’t it better to leave the clean and say:

#sidebar a:first-child {
  @include call-to-action;
}

“All first links in the sidebar are call-to-action”. Then we can get specific, and override it on the users#show page [4]:

.c_users.v_show #sidebar a:last-child {
  @include call-to-action;
}

In this post we will see that although this style of CSS may be ‘more progressive’; it isn’t a habit you want to form and will hurt performance if you’re careless.

Aside 2: How browsers parse and render CSS

Disclaimer: I am not an expert on this; and perhaps it may change in the future.

Browsers parse CSS from right to left

The ‘parsing’ step of CSS rendering involves constructing a massive hash table of right-hand-side(RHS) selectors. So when a browser sees:

.c_users.v_show #sidebar a { ... } //[1]

It knows that this rule will only apply to elements, and no others.

When rendering, the browser runs through elements one at a time, testing all such rules that match. So every time it finds a link element, it must check to see if it is a descendant of a #sidebar inside a .c_users.v_show. This is a relatively expensive check as it requires running up the whole DOM tree; so we can see that the right-hand side selector is very important.

So every time you construct a rule that has a overly generic selector on the RHS (an <a> rather than a .call-to-action say), you add an extra check that must be made for every single element on the page that matches.

Quantifying Rendering time

In an effort to try and quantify this CSS rendering time I’ve constructed a set of experiments that measure the parsing + rendering time for a very large test page. These should give you an idea of what to expect, and how much credence you should put into worrying about parsing.

Read the source code to the css-timings project and give it a try. I ran these experiments on my late 2011 Macbook Pro and my iPhone 4 [5] and recorded the results in a public google doc. I’ll explain the setup here and talk through the significance of the results in a moment.

The basic experiment is as follows; our page consists of 10,000

s, each with a unique class name. Our base CSS file consists of one simple style targeted to each of the

s (so 10,000 base styles as well).

Experiment One: How long does it all take?

10,000 elements on one hand is a lot. Steve Souders measured the number of selectors on some popular sites and averaged around 1,000 back in 2009. I’d probably estimate that this has grown by now. However it helps us emphasize differences.

10,000 style rules on the other hand isn’t that many. We (Bindle) have around 6,000 selectors right now, and most have many more than 1 rule.

There is a fairly linear relationship between the number of elements of the page and the rendering time when there are many potentially applicable style rules per element.

Anyway, given those caveats, parsing & rendering these elements takes a non-trivial but probably insignificant amount of time on my high-end laptop; however, the rendering time on Mobile Safari is much more noteworthy.

Conclusion #1: Mobile Devices are slow enough that this stuff actually matters.

Experiment Two: What difference do inapplicable styles make?

All browsers seem to have a similar profile; they suffer greatly with overly generic RHS selectors.

You’ve combined all your CSS files into one big file, so when rendering each page of the site the browser must consider the styles which are targeted at all your other pages. Not to worry, you use a nice CSS namespacing library [6], so there’s no danger of it getting confused. What does checking all those extra styles cost?

Here we experiment with adding an extra 10,000 irrelevant style rules. Firstly we can try to add styles that the browser knows won’t apply, either because they target the wrong element, or because they target a non-existent class. We see that they make a linear difference to CSS parsing time—parsing twice as many styles takes twice as long, surprisingly enough—and no difference to rendering time. Well done browser!

On the other hand, if the styles don’t apply, but do match on the RHS, for instance like:

#bla .foo ul .something-else div

The browser is forced to do many expensive ancestor checks, and the rendering time blows way out (even in the seconds for Firefox on my Pro).

Conclusion #2: Try to right-most target classes where possible.

This, along with the more pressing issue of CSS file size, is a nail in the coffin for the idea of ‘replacing’ classes with @mixins and writing super-semantic html.

Experiment Three: can we hide irrelevant rules from the browser?

Seeing as your stylesheet is no doubt full of rules that you know are never going to apply to the page being rendered, you can’t help but wish there way some way to tell the browser not to worry about them. We understand the reason why browsers look at rules right-to-left, but is there something that we can put on the LHS to help the browser out?

Unfortunately, even if you explicitly tell the browser that the body needs a specific class for the rule to apply:

body.c_users.v_show #sidebar > * { .. }

Browsers aren’t smart enough to work in such a left-to-right fashion [7]. One trick that does work is to use a @media query:

@media-type print {
  #sidebar > * { .. }
}

Browsers do disregard those rules entirely. However, there’s no ‘custom’ media queries available, so we cannot do something like:

@media-page v_users_c_show {
  #sidebar > * { .. }
}

Conclusion #3: At this point, there is no good way to hide styles. So we need to be careful.

**Conclusion: CSS efficiency can have an impact on mobile; but only if you do things really wrong.**

So, after all this, what can we conclude? Firstly, hopefully the css-timings project can provide a nice base for people to conduct their own experiments and try to measure the impact of various other CSS quirks they may be thinking of squashing. Please feel free to criticize my methodology and conclusions to your hearts content!

Secondly, poor CSS will hurt you on mobile. The amount any one mistake can hurt you, though small, will add up with systemic errors like global selector * rules:

.foo #bar > *

Each will add 0.15ms to the rendering time of every single page on your entire website [8]. So don’t worry about a single rule. However, systemic use will lead to a constant rendering tax that will adversely effect the user experience.

So, I would advise:

Steer clear of replacing classes with @mixins. One day the browsers will support it or something like it, but until then,
isn’t such a horrible mixture of presentation and content.
Keep your number of selectors down, but don’t go overboard about it. This post should hopefully give you an idea of you are dealing with.

with the benefit of all subsequent request being cached in the browser
and JS if you don’t put it at the bottom of the . I’ll leave this discussion for another time
Thanks Mozilla! We could cut this down to about 50 if you supported background-position-y.
Here and in future I use the syntax provided by edifice for namespacing page-level CSS
Note that these experiments are very CPU bound. On Dom’s early 2010 Macbook pro (18 months older), we saw pretty much 2x times for more-or-less everything. Moore’s Law in action, baby!
Say, edifice again?
It could work though. There can only be one body in the page, so if the body doesn’t have the relevant classes, we can ‘turn that rule off’.
Where did I get 0.15ms from? We saw that 10k over-general selectors adding on 10k elements blew the time out by 15s. So, given that’s 100 million ‘checks’, each check takes around 0.00015ms. If we have an average sized page (one thousand elements), then each * selector will cause 1000 checks, and thus take around 0.15ms. YMMV

Running binaries on Heroku

Tom Coleman — Mon, 12 Mar 2012 02:22:30 +0000

Blue highlight courtesy of Autotrace

Bindle 2 is fresh out of the oven; one of the main areas of focus was making Bindles more intuitive to create & navigate—to that end we’re making use of a binary called Autotrace which helps us calculate the boundaries of items [1]. Unfortunately there is no ruby interface for this library in rails just yet, so we needed to get a binary running on our Heroku Cedar instance. Luckily it was pretty easy to do.

Here’s how to use binaries with Rails on Heroku:

Running binaries on heroku is possible if they are in the bin/ directory of your app. This is not officially supported, so use at your own risk. Heroku runs on Ubuntu 10.04 LTS 64bit, so you’ll want to download it to compile your program on a VM. Install Ubuntu as normal, then download the source code for the program you are interested in.

If your program doesn’t have any dependencies which aren’t already installed on ubuntu (or only depend on header files) you are probably good to go with the normal compilation process. If, like autotrace, it depends on libraries which don’t come installed on Ubuntu, then they won’t be on your Heroku instance, and you’ll need to compile a statically linked version.

Don’t worry, it’s not super difficult. Here’s what I did:

# download and unpack source into a directory and cd in there:
cd autotrace-0.31.1/
 
# install ubuntu packages which the program requires
sudo apt-get install libmagick++-dev
 
# configure to be statically linked
./configure --enable-shared=no
 
# compile
make

The make process creates an executable, which you can then place into the bin/ directory of your heroku app. I put it in the bin/x86_64-linux/ directory just to be clear about what can run where. Statically linked autotrace comes in at around 400k, so in order to keep your slug size down you’ll probably want to use your discretion here.

Finally, to test, you can open up a heroku console (heroku run console) and check that it is running successfully:

irb(main):006:0> `bin/x86_64-linux/autotrace`
Usage: bin/x86_64-linux/autotrace [options] .
(Missing .)
For more information, use ``-help''.

Success!

This makes dragging items more intuitive: click on the item to drag it, click on the negative space to pan. So no more rectangles to confine your images!

Choosing in context: product recommendation the Bindle way

Tom Coleman — Tue, 28 Feb 2012 17:18:01 +0000

The internet knows no horizon. It is the most visible example of technology’s unstoppable progress and is so vast that we couldn’t cope if we had to use pre-Google search engines. Google’s Page Rank algorithm admirably filters signal from noise, but the imminent commoditization of production and the consequent explosion choice presents a new challenge: will an algorithm be able to make our purchasing decisions for us?

Dom explained the problem in an earlier post:

…the major challenge for new companies will not be in sales or manufacturing, but bringing their goods to the attention of buyers. The challenge for the consumer will be focusing their attention on the right goods. When everyone’s mom, sister, and brother is a producer, we’ll need to filter the deluge of brand messaging else expect to washed away in the mass of creativity.

In this post, I’ll begin to explore the solution.

Collaborative Filtering

The classic computer algorithm for the problem of recommendation is a technique called Collaborative Filtering. It’s the formalisation of a simple idea; if we know people’s past purchasing behaviour (including yours), then we should look at what’s popular with people whose purchases mirror yours. The amount that you are likely to like an item X is the average of how much everyone else likes X, weighted by their similarity to you.

This technique might seem very crude, but like many data-mining algorithms, predicts your preferences quite well due to the massiveness of the datasets involved. Amazon famously implemented a ‘reverse’ version of it (using users’ purchasing patterns to link similar items) to produce the ‘Customers who bought X also bought Y’ section of their website.

There’s no doubt this approach may lead us to discover interesting new products, or prompt us to buy something that we’ve forgotten we wanted. However, discovery is becoming easier as the long tail of products comes to the fore. Does the algorithm really help us to decide which product is best for us? Does it give us confidence that we are looking at the perfect choice? Can a machine help us own the right stuff?

The User Review

A human alternative to a machine recommendation is a user review. Pioneered by Consumer Reports and deftly wielded by the Amazons and Yelps of the world, the user reviews’ achilles heel lies in it’s propensity to polarize opinion. People review products if they love or hate them [1], but rarely if they are ‘just OK’. Contrary to what it appears online, it’s the silent majority between love and hate that actually BUY things.

Moreover, out of context, it can be very difficult to tell if someone’s opinion can be trusted. Try this experiment: think of your favourite product, find it on Amazon, and have a look at the negative reviews (there’ll be some!). Would you know, uninitiated, that those reviewers were dead wrong? Or at least that their opinions were baseless? Product reviews can range from nitpicky rambling loud noise to compelling argument.

Trust

The issue in both cases is trust. It’s hard to trust the computer, because we don’t know what it’s thinking. This is less of a problem when we are deciding on a movie, but when the outlay of money is higher, it becomes a more serious issue. Likewise, when we read a review, we generally just don’t have enough of a handle on the reviewer to know if we can trust them.

The solution to the trust issue online is simple: context. If we know a user’s pattern of behaviour, it’s easy to understand the significance of a single act. The idea of a bindle is to provide that context with a single glance. It’s the easiest way to see in a moment how the recommender’s choice of a product fits within the general pattern of their choices.

Seeing the kind of bikes those wheels are used on might make you realise they are pretty pro.

Seeing this Apple-device user with a Nexus One tells you something about that particular phone.

The advent of the internet has dragged us into a post information age; attention is the new scarcity. The latest trends on the web revolve around curating the firehose of information that is available.

Bindle is an effort to enable us to trust other gear lovers, driving that trust by allowing us to see someone’s choices in the context they have been made. Everyone has friends who they trust for their excellent sense of style, or technical knowledge, or experience in some area. I know there are people who’s recommendations I would blindly buy without further thought. Bindle will enable this behaviour on an internet scale.

We hope that in the future, with Bindle, we will all own the right things, thanks to the recommendations of those we trust.

they also tend to love or hate things more than they should

Splitting the Asset: destroying arcane IE bugs on the ruby rack.

Tom Coleman — Wed, 08 Feb 2012 00:34:35 +0000

TESTING AGAINST INTERNET EXPLORER IS NEVER FUN. That’s an understatement.

Even though at Bindle we limit our support to IE9, we still fear the obscure IE bug. It leads to an aversion to booting up a Windows 7 VM. jQuery + Compass have (greatly) reduced the worries over IE quirks, but from time to time I am still left shaking my head.

These days I find I can get away with deferring IE testing until towards the end of a release process, as most of the time all we need to do is double check things look and behave right. So imagine my surprise when seeing this while loading our latest release:

Bindle doesn't look very good when IE isn't interpreting all of the stylesheets.

As you can see the majority of our stylesheets are not being interpreted. It turns out the problem is due to some internal limitations in IE, versions up to 9. Such browsers allow:

up to 4095 selectors per stylesheet [this is the one that was causing us the problem].
up to 31 @imported sheets
@import nesting up to 4 levels deep.

Why in this day and age do we have such a limit, you ask? Eric explains:

The root of the limitations is that Internet Explorer uses a 32bit integer to identify, sort, and apply the cascading rules. The integer’s 32bits are split into five fields: four sheetIDs of 5 bits each, and one 12bit ruleID. The 5 bit sheetIDs results in the 31 @import limit, and the 12 bit ruleID results in the 4095 rules-per-sheet limitation.

Chris Wilson comments that the feature was implemented in IE3 (released 1996), when keeping the memory requirement per stylesheet rule was a little bit more important.

Dealing with the problem

The specific issue is that Bindle has more than just 4095 selectors. The solution is to split the stylesheet up (for IE only), and to serve up chunks of it selectively to IE. So you’ll see in our tag, something like:

The standard sprocketed stylesheet and a second, IE only stylesheet (containing the remaining rules from our stylesheet that it ignores).

How to work producing this screen-2.css into our Rails 3.1 / git / heroku workflow? The nicest solution is Bless, a node.js project that splits CSS files via a command line program, even adding @import statements to your first file to ensure you don’t need to change your html code at all. However, this solution isn’t practical when you are deploying to heroku, with it’s read-only file system, and git push style deployment. (If you are deploying to your own server via capistrano, I would advise following this route).

So what is a poor heroku based developer to do? I found a simple little CSS splitter ruby class which I tried to work into the sprockets assets workflow, so that the CSS files would get split on rake assets:precompile; however (not being a sprockets expert) it seemed that turning one file into multiple wasn’t part of the basic sprockets plan. Another possibility would be to hook somewhere else into the assets:precompile task, however I need my code to run after assets:precompile (and thus the css files generated), and I don’t know how to ensure that [1].

UPDATE: Zweilove have released this class as a gem, and have a workaround for the multiple-files problem, so it’s now possible to integrate it into the asset workflow.

A solution: rack middleware

Although working harder through one of the solutions outlined above would probably be the ideal way to do it, I secretly didn’t really want to, as I was itching for a chance to implement a rack middleware. I had previously had to dig around in middleware when solving an extremely scary bug that I encountered. I was keen to have a go at one of my own. Here’s the end result:

require 'css_splitter'
 
class SplitAssetEndpoint
  def initialize(app, path)
    @app = app
    @path = path
  end
 
  def call(env)
    if env['PATH_INFO'] =~ Regexp.new('^' + @path + '/([^/]*)\-(\d+).css')
      filename = File.join(::Rails.public_path, ::Rails.application.config.assets.prefix, $1 + '.css')
      css = CssSplitter.split_to_part(filename, $2.to_i)
 
      [200, {
        'Content-Type' => 'text/css',
        'Content-Size' => css.bytesize.to_s,
        'Cache-Control' => 'public, max-age=31536000'
      }, [css]]
    else
      @app.call(env)
    end
  end
end

Here’s the modifications I made to the css splitter library to allow me to extract a single part of the file. The middleware itself is pretty simple. We simply look at the incoming request, and if it’s path matches (/split_assets/ in our case), it parses out the part you want, pulls it out of the CSS asset, and serves it back to you. Otherwise it simply passes the request through to the remainder of the stack.

Doesn’t this use a lot of resources parse + split the CSS every time an IE user accesses the site? Well, no, thanks to the magic of HTTP caching. We simply make sure that we place the SplitAssetEndpoint behind the Cache, like so:

config.middleware.insert insert_after Rack::Cache, 'SplitAssetEndpoint', '/split_assets'

Problem solved!

rake.enhance should work, but doesn’t seem to hook in on Heroku. I guess it’s the special way they run assets:precompile. I would welcome suggestions about how to do this in the comments