Symbol | Key Name |
---|---|
⌘ | Command |
code | alternative code | url | expected response |
---|---|---|---|
App.store.findById(App.User, 123) |
App.User.find(123) |
https://www.example.com/myNamespace/users/123 |
{user:{ ...user123... }} |
App.store.findAll(App.User) |
App.User.find() |
https://www.example.com/myNamespace/users |
{users:[{ ...user1... },{ ...user2... },{ ...userN... }} |
App.store.findMany(App.User, [1,2,3]) |
Normally, if you register views and controllers (with the same name), when they're instantiated, Ember automatically wires them up to each other. view.controller
points to the controller you'd expect and both view.content
and controller.model
are bound to each other. If one changes, so does the other.
However, registering everything with the App means your App namespace gets very polluted, and you have to be very careful choosing your names so you don't collide with views/controllers being defined/used elsewhere in the App. Also, sometimes you have a view/controller that you're only using in one very specific place and it's just kinda silly to have it registered and accessible at a "global" level. In these cases, it's logical to NOT register your views/controllers, but that means things don't get magically wired up by Ember and things don't work the way you'd normally expect.
If you don't register your view/controller, then when you try {{view MyUnregisteredView contentBinding="myModel"}}
, you get a
#!/usr/bin/env bash | |
# usage: | |
# local branches only: `myUnmerged` | |
# remote branches only: `myUnmerged -r` | |
# all branches: `myUnmerged -a` | |
# | |
# example output: | |
# | |
# BRANCH TOTAL COMMITS KOGI KOGI UNMERGED |
#!/usr/bin/env bash | |
# usage: | |
# git-stats #gives stats for the whole branch | |
# git-stats --author="yourname here" #gives stats for specific author | |
# | |
# though not all tested, this should be compatible with all limiting options supported by git-log (https://www.kernel.org/pub/software/scm/git/docs/git-log.html#_commit_limiting) | |
git log --pretty=tformat: --numstat $@ "`git merge-base HEAD develop`..HEAD" | gawk '{ adds += $1 ; subs += $2 ; net += $1 - $2 ; gross += $1 + $2 ; commits += 1 } END { print "total commits\tadded loc\tremoved loc\tgross loc\tnet loc\n"; printf "%d\t%d\t%d\t%d\t%d\n", commits, adds, subs, gross, net }' | column -s $'\t' -t |
- Show number of commits that exist in develop, but NOT in the current branch (is my branch sync’d with develop? Should return 0)
git rev-list HEAD..origin/develop --no-merges | wc –l
- Show number of commits that exist in develop, but NOT in master or vice-versa (have master and develop diverged?)
- (have master and develop diverged in some way? Irrespective of current branch – should return 0)
git rev-list origin/develop...origin/master --no-merges | wc -l
- (does develop have anything not in master? Irrespective of current branch – should return 0)
git rev-list origin/develop..origin/master --no-merges | wc –l
- (does master have anything not in develop? Irrespective of current branch)
- (just a total number of commits – should return 0)
git rev-list origin/master..origin/develop--no-merges | wc –l
- (just a total number of commits – should return 0)
- (have master and develop diverged in some way? Irrespective of current branch – should return 0)
Handlebars.registerHelper( 'select-options', function( items, selectedValue, options ) { | |
// ======== Ensure `items` is Object/Hash | |
if( items instanceof Array ) { | |
var temp = {}; | |
for( var i in items ) { | |
var value = items[i]; | |
temp[value] = value; | |
} | |
items = temp; | |
} |
// DON'T DO THIS
if ((user != null && user.id.isNotEmpty && targetId == user.id) || (user.name.isNotEmpty ? user.name : '') == targetName || (phoneNumber.isNotEmpty && phoneNumber == user.phoneNumber)) {
//...;
}
// DON'T DO THIS
if (
(user != null && user.id.isNotEmpty && targetId == user.id)
|| (user.name.isNotEmpty ? user.name : '') == targetName
# Dart Coding Standards - LiveNinja Development | |
## Conventions | |
The key words `MUST`, `MUST NOT`, `REQUIRED`, `SHALL`, `SHALL NOT`, `SHOULD`, `SHOULD NOT`, `RECOMMENDED`, `MAY`, and `OPTIONAL` in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) and summarized as follows: | |
1. `MUST` This word, or the terms `REQUIRED` or `SHALL`, mean that the definition is an absolute requirement of the specification. | |
1. `MUST NOT` This phrase, or the phrase `SHALL NOT`, mean that the definition is an absolute prohibition of the specification. | |
1. `SHOULD` This word, or the adjective `RECOMMENDED`, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
class SomeClass { | |
String _foobar; | |
String get foobar => _foobar; | |
// note: no setter defined = can't write new values | |
SomeClass(this._foobar); | |
} |