Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
| -- show running queries (pre 9.2) | |
| SELECT procpid, age(clock_timestamp(), query_start), usename, current_query | |
| FROM pg_stat_activity | |
| WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' | |
| ORDER BY query_start desc; | |
| -- show running queries (9.2) | |
| SELECT pid, age(clock_timestamp(), query_start), usename, query | |
| FROM pg_stat_activity | |
| WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
WARNING
This gist is outdated! For the most up-to-date information, please see http://emberjs.com/guides/routing/!
An Ember application starts with its main template. Put your header, footer, and any other decorative content in application.handlebars.
<header>
Over the last 3 years or so I've helped a bunch of companies, small and large, switch to Django. As part of that, I've done a lot of teaching Django (and Python) to people new to the platform (and language). I'd estimate I've trained something around 200-250 people so far. These aren't people new to programming — indeed, almost all of them are were currently employed as software developers — but they were new to Python, or to Django, or to web development, or all three.
In doing so, I've observed some patterns about what works and what doesn't. Many (most) of the failings have been my own pedagogical failings, but as I've honed my coursework and my skill I'm seeing, time and again, certain ways that Django makes itself difficult to certain groups of users.
This document is my attempt at organizing some notes around what ways different groups struggle. It's not particularly actionable — I'm not making any arguments about what Django should or shouldn't do (at least
The Ember router is getting number of enhancements that will greatly enhance its power, reliability, predictability, and ability to handle asynchronous loading logic (so many abilities), particularly when used in conjunction with promises, though the API is friendly enough that a deep understanding of promises is not required for the simpler use cases.
HTMLBars serves as a polyfill for a native implement of node.bind.
Instead of letting the browser parse the HTML and generate nodes, which leaves us at the mercy of the limitations of the parser, HTMLBars implements an HTML parser and generates the nodes itself.
As HTMLBars generates the nodes, it calls into node.bind if it detects mustache syntax.
Open questions:
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <title>Why can't I have Proxy yet??</title> | |
| </head> | |
| <body> | |
| <div id="item"> | |
| <h1 class="name">name goes here</h1> |
A future version of Ember will come with a new templating engine known as HTMLBars.
The original motivation for HTMLBars was to allow helpers and properties to have better contextual information about what they were bound to.
So for example, consider a template like this:
THIS GIST WAS MOVED TO TERMSTANDARD/COLORS REPOSITORY.
PLEASE ASK YOUR QUESTIONS OR ADD ANY SUGGESTIONS AS A REPOSITORY ISSUES OR PULL REQUESTS INSTEAD!