David J. Hamilton hjdivad

Ember-QUnit Testing With Vim

It can be tedious (and slow) to go from a test in your editor to running that test in the browser. This is a process to speed this up slightly. When it's set up you'll be able to run an individual test by:

put your cursor inside a test body
hit T
switch to chrome
type 'test ' (sans quotes), paste your clipboard and hit enter

" for filetype rspec

if !exists("*s:RunSpec")
  function s:RunSpec()
    let command="tmux send-keys -t bottom-left zeus " . "' '" . "rspec\ " . "' '" . expand("%") . ":" . line(".") . "$'\n'"
    let g:last_spec_command=command

 echo system(command)

I like the idea of unifying navigation between tmux panes and vim windows. @mislav did a great job in [this gist][mislav-gist] but it depends on using C-{h,j,k,l} for navigation instead of vim's default C-W {h,j,k,l}.

Tmux's bind-key doesn't support multiple keys: just a single key with a modifier, so if we want to keep using C-w we have to be a bit tricky.

This approach binds C-w to set up keybindings that a) navigate and b) unset themselves. It turns out you can't have a bind-key statement in your .tmux.conf that's too long or tmux will segfault, which is one of the

Consider the example:

var MyObject = Ember.Object.extend({
  selectedContent: Ember.computed.filterBy('content', 'isSelected')
});

var obj = MyObject.create({
  content: [
    Em.Object.create({name: "one", isSelected: false}),
 Em.Object.create({name: "two", isSelected: false})

TL;DR

user.get('posts') should resolve as soon as the ids are known, possibly before the records are loaded;
user.get('posts').objectAt(0) should return a PromiseObject and also fetch that object;
The fetches from #2 should be coalesced and;
user.get('posts').load() should fetch the records and return a promise that resolves when they are all loaded.

Ember Computed Literal Backwards Compatibility Blocker

[Ember.computed.literal][1] is blocked on a backwards compatibility story. There are basically three options:

Breaking change for consistency, deprecating existing behaviour;
More complicated temporary solution for backwards compatibility (ember only); and
More complicated temporary solution for backwards compatibility (ember and ember-cpm).

and = Ember.computed.and;
equal = Ember.computed.equal;
bool = Ember.computed.bool;

Ember.Object.extend({
  isHeirToCasterlyRock: and(equal('lastName', 'Lannister'),
                            bool('isEldestSon')),  // Primogeniture is actually
                                                  // more complicated but w/e

Literals vs Properties in CPs

Something that's currently very annoying about CPs is that whether arguments are literals or properties is something that must be decided at macro-design time, rather than at macro-use time.

Consider for instance Ember.computed.equal. It would be nice to be able to use the same macro for creating CPs that compare against literal values as well as against properties.

	import Ember from 'ember';

	const computed = Ember.computed;

	const Inner = Ember.Object.extend({
	people: null,
	});

	const Person = Ember.Object.extend({
	name: null,

	export function filterBy (dependentKey, propertyKey, filterPropertyName) {
	var callback;

	if (arguments.length === 2) {
	callback = function(item) {
	return get(item, propertyKey);
	};
	} else {
	callback = function(item) {
	return get(item, propertyKey) === get(this, filterPropertyName);