krisselden

{{#each fruits}}
{{this}}
{{/each}}

{{draggable-list values=fruits}}

thomasboyt

/* jshint node: true */

/**
 * This is a hack-ish way of triggering Karma runs on broccoli builds.
 */

var path = require('path');
var spawn = require('child_process').spawn;

var broccoli = require('broccoli');

joefiorini

function loadScript(module) {
  var head = document.getElementsByTagName("head")[0];
  var script = document.createElement("script");
  return new RSVP.Promise(function(resolve, reject) {
    script.language = "javascript";
    script.src = module.url;
    script.onload = function() {
      resolve(module);
    };
    head.appendChild(script);

abuiles

f

joefiorini

Basically, it's a minimal Rails-API app (based loosely on this gist) embedded in an api folder in the root. Then the rest of it is a stock ember-cli setup. I don't know yet exactly how to make Rails look elsewhere for initializers, environments & locales, going to look into it.

api/              *.rb
  controllers/
  models/
  initializers/
  environments/
  locales/
  config.rb

routes.rb

raytiley

var dbRef = new Firebase("https://YOUR-FIREBASE.firebaseio.com/");

export default Ember.Controller.extend({
  
  /**
  @property currentUser
  @type {User}
  @default null
  */
  currentUser: null,

rwjblue

• Data Down / Actions Up

  • http://emberjs.jsbin.com/nayaho/edit?html,js - Interdependent select boxes. No observers.
  • http://ember-twiddle.com/2d7246875098d0dbb4a4 - One Way Input

• Plain JSBin's

  • http://rwjblue.jsbin.com/pixeki/edit?html,js,output

• Ember Version Base JSBin's

  • 1.0 - http://emberjs.jsbin.com/juluje/edit?html,js,output

• 1.1 - http://emberjs.jsbin.com/cofufo/edit?html,js,output

ryanflorence

var compile = Ember.Handlebars.compile;

module('Ember.Test Unit Tests', {
  setup: function() {
    Ember.Test.setupUnitTest();
  },
  teardown: function() {
    Ember.Test.teardownUnitTest();
  }
});

jvns

A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.

I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.

I'd love comments and suggestions about any of these.

I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.

I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".

kurko

Ember.js Testing package was a great addition to the project. It allowed us to have fast specs to guarantee the defined behavior. However, there's no convention on how you should guarantee that your models, the heart of any Ember.js application, are valid in relation to your backend.

Put another way, if you have an User model with a name attribute, how can you be sure that your backend is still responding with {"user": {"name": "Your Name"}}? So, even though your acceptance specs pass, you're stubbing out your models with FIXTURES.

Most people either manually test their apps or create an end-to-end test with the backend server, which is slow as hell (think of Capybara). The good news is that there are conventions for solving this since like forever. One way to guarantee this integrity is via Contract tests (http://martinfowler.com/bliki/IntegrationContractTest.html). Basically, you have a test to guarantee your models are matching your backend.

Using server-side end-to-end tests have many drawbacks,