How to increase your chances of getting help on #emberjs

I live on an Island. If I need help with something, it’s not always easy to get it right away. Sometimes I have to figure something out for myself, like a pleb. But enough of my Mountain Man ramblings.

Here’s a great way to increase your ability to think for yourself for those times when you can’t quickly or easily get help, and when someone can help you, you’ve given them the best possible start for assisting. The Ember.js IRC channels are a great place to ask questions and get help when you’re stuck on something and the documentation isn’t helping or Stack Overflow is giving you snake eyes. But there’s an okay way and an excellent way to get help on #emberjs. Let’s see what the options are and how one is better than the other.

Github Gists

Most folks take this option, from what I can see hanging out in #emberjs. They take sections out of their app and plonk them into a Gist, and post that into the channel while asking for help. This is the obvious and quickest route to getting someone else to understand your predicament, but it lacks several significant things that will make it likely that you’ll get help quickly.

Static, Lifeless, Dead.

Gists are static – they don’t show how the parts in question are actually interacting, which means the reader has to do a lot of mental reconstruction to figure out what’s happening. If the problem you’re trying to tackle can actually be expressed in one complete file, then it’s not so bad (for example, a Component Qunit test).

Hide Framework bugs

Because Gists are static, they don’t exercise the full Ember.js stack, so your problem could be a bug in the framework, but it’s being hidden because the person trying to help you has no way to see the effects.

They don’t really force you to think about the problem

It’s super easy to copy and paste fragments of your app into a Gist. But doing so doesn’t make you think about your problem, and could be helping to hide some really obvious bug you’ve missed.

So, what’s the better alternative? Enter, stage left…


JSBin is a great way to share functional code snippets with the people you want to help you. What’s better, you can get an instantly constructed base Ember project simply by hitting the URL Try it!

Deconstruct your problem

First step, is to try and extract the problem into a general high level example of what you’re trying to achieve that works in JSBin. In doing so, it forces you to think about the problem and chances are you’ll find your own solution. It’s like digital rubber ducking.

I need Ember Data ♨_♨

Well, you can add Ember Data support with a couple of lines.

  1. Add the script tag to the lastest build of Ember Data into the HTML. You can grab this easily from the page.
  2. Setup the fixture adapter: App.ApplicationAdapter = DS.FixtureAdapter.extend();
  3. Define a model:

    App.ListItem = DS.Model.extend({ title: DS.attr(‘string’) });

  4. Define some Fixture data:

    App.ListItem.FIXTURES = [ { id: 1, “title”: “cat” }, { id: 2, “title”: “dog” } ];

  5. Done!</p>

You’ve now got a simple data model setup.

By using JSBin, and almost by magic, you’re increasing the chances that you’ll find the solution to your problem by yourself, and if you don’t, that whoever wants to help you will be quickly able to assess what’s going on – meaning that they are more likely to help in the first place.


Gists are ok, but if you really want to boost your chances of getting help, and even maybe solve the problem yourself without even needing to go into the channel, use JSBin. I’ll frequently fire up a JSBin to try out an idea or explore a concept in Ember. For example, let’s say you wanted to explore how to side-load object from a page at runtime. Easy, just fire up JSBin and start sketching out a solution – like this one:

Ember Starter Kit

Try to incorporate JSBin into your daily Ember.js work and you’ll find it’ll make you a better Ember developer in no time at all.