// Step 3. | |
const isGeoLocation = [ | |
function validate(data) { | |
const inRange = (number, min, max) => number >= min && number <= max; | |
const [ lat, lng ] = data.split(','); | |
return inRange(Number(lat), -90, 90) && inRange(Number(lng), -180, 180); | |
}, | |
function errorMessage(schema, parentSchema, data) { | |
return `${data} is not a valid geolocation point. [lat,lng] format is required.` | |
}, |
FROM elixir:1.4.5 as asset-builder-mix-getter | |
ENV HOME=/opt/app | |
RUN mix do local.hex --force, local.rebar --force | |
# Cache elixir deps | |
COPY config/ $HOME/config/ | |
COPY mix.exs mix.lock $HOME/ | |
COPY apps/myproject_web/mix.exs $HOME/apps/myproject_web/ | |
COPY apps/myproject_web/config/ $HOME/apps/myproject_web/config/ |
--- Actions --- | |
$Copy <M-C> | |
$Cut <M-X> <S-Del> | |
$Delete <Del> <BS> <M-BS> | |
$LRU | |
$Paste <M-V> | |
$Redo <M-S-Z> <A-S-BS> | |
$SearchWeb <A-S-G> | |
$SelectAll <M-A> | |
$Undo <M-Z> |
Branch A has commits (X,Y) that also need to be in Branch B. The cherry-pick operations should be done in the same chronological order that the commits appear in Branch A.
cherry-pick
does support a range of commits, but if you have merge commits in that range, it gets really complicated
git checkout branch-B
git cherry-pick X
git cherry-pick Y
[mergetool] | |
prompt = false | |
keepBackup = false | |
keepTemporaries = false | |
[merge] | |
tool = winmerge | |
[mergetool "winmerge"] | |
name = WinMerge |
/* | |
* Easing Equations ported to CSS by @matthewlein - http://matthewlein.com/ceaser/ | |
* Converted to SCSS vars by @pettpett | |
* | |
* sample usage: | |
* a { | |
* color: #ff0000; | |
* transition: color 0.5s $easeOutQuint; | |
* &:hover, |
IE6 Only | |
================== | |
_selector {...} | |
IE6 & IE7 | |
================== | |
*html or { _property: } | |
IE7 Only | |
================== |
##Introduction
One definition of unit testing is the process of taking the smallest piece of testable code in an application, isolating it from the remainder of your codebase and determining if it behaves exactly as expected. In this section, we'll be taking a look at how to unit test Backbone applications using a popular JavaScript testing framework called Jasmine from Pivotal Labs.
For an application to be considered 'well'-tested, distinct functionality should ideally have its own separate unit tests where it's tested against the different conditions you expect it to work under. All tests must pass before functionality is considered 'complete'. This allows developers to both modify a unit of code and it's dependencies with a level of confidence about whether these changes have caused any breakage.
As a basic example of unit testing is where a developer may wish to assert whether passing specific values through to a sum function results in the correct output being re
//Customise Backbone.sync to work with Titanium rather than jQuery | |
Backbone.sync = (function() { | |
var methodMap = { | |
'create': 'POST', | |
'read' : 'GET', | |
'update': 'PUT', | |
'delete': 'DELETE' | |
}; | |
var xhr = Ti.Network.createHTTPClient({ timeout: 5000 }); |