Степан

Выкидываете overflow:hidden и вешаете на элемент clear-fix класс:

.clear:after {
  content: '.';
  display: block;
  height: 0;
  clear: both;
  visibility: hidden;
}

Backbone.history.navigate("/адрес route на который нужно перейти");

Этот метод используется и в первом и втором случае (по нажатию на кнопку)

view.render().el возвращает обычный html, который можно вставить в любой тег, например в body, заменив при этом html, который там уже есть.
$('body').html(view.render().el)

Для меня эффективным способом было ставить перед собой задачи и делать.
1. Калькулятор на JS
2. Валидация формы (е-майл, пусто/не пусто)
3. Небольшая игра (крестики-нолики, найти пару одинаковых картинок по кликам)
4. Таймеры (часы разных видов)
ну и так далее...

codepen.io/anon/pen/oAsyf
Вы живой поиск хотите сделать?

Как-то так чтоли codepen.io/golumenov/pen/dbnlh

ctrl+shift+s
Code style->html
Other
Wrap attrib if long: Dont wrap

Просто надо поменять местами:

$(document).ready(function () {

        var data = {
            name: 'Jane Doe'
        }
        var template = Handlebars.compile( $('#template').html() );
        $('.updates').append( template(data) );


    });

У вас переменная data используется до инициализации. Нужно поменять местами эти строки:

var data = {
    name: 'Jane Doe'
}

$('.updates').append( template(data) );

jsfiddle.net/xnrzwa59/1

В целом я считаю что это норма.
Для случая 1 разработчика и 1 руководителя это действительно некий оверхед, но есть важный момент: если Вы СЕЙЧАС не привыкните к такому процессу - у Вас не получится на него мгновенно переключиться когда это потребуется.
Помимо этого, строгая отчетность помогает лучше планировать собственное время и объективно оценивать сроки.

Ниже по пунктам:

Написать что конкретно было проделано. (При этом в задаче и так расписано что нужно сделать)

Сильно зависит от того насколько у вас детализированы задачи.
Конечно не нужно доводить до маразма, но какие то дополнительные подробности реализации всегда не повредят. Впрочем это вполне можно писать в сообщениях к пуллреквесту.

Дать ссылку где посмотреть.

Обязательно всегда!

Дать номер коммита. (В коммите нужно описать что ты сделал в комментарии)

Многие системы, например jira отлично дружатся с репозиториями и автоматически собирают changelog из комментариев коммитов. Заодно еще и время учитывают.
Живая картинка joxi.ru/1XToU_3JTJBuefeWz0o

Дать картинку с чем можно сравнить. (Если верстка)

Обязательно

Поставить needcheck.

Тоже логично.
Мне лично это удобней делать статусами задачи
To Do <-> In Progress <-> Testing <-> Done
но это субъективно.

В конце дня написать детально что было сделано за день.

Если задачи целиком закрываются до конца рабочего дня - это в принципе излишне, можно посмотреть по комитам. Если задачи долгие - это обязательно.
Я еще заставляю обычно писать что планируется делать на следующий день.

var myRadioButton = document.getElementById('myRadioButton');

myRadioButton.onchange = function(){
    if(this.checked == true){
        openWindow();
    } else {
        closeWindow();
    }
};

codepen.io/iiil/pen/qHiLz

Да ладно, парни. Ну хватит уже, к чему такие сложности? Берём и читаем. Вообще совсем не обязательно читать про архитектуру и абстракции именно по своему языку, хотя javascript в этом плане родился уродом.

Ок. Полиморфизм ни в коем случае нельзя рассматривать отдельно от других фундаментальных понятий - абстракция, инкапсуляция и наследование. Объект и подобные прилагаются из аксиом (хотя это-то тоже аксиомы).

Собственно, представим себе рядом стакан, кружку, чайник, кофемашину, велосипед и скейт. Что между ними всеми общего? Ну как минимум то, что они есть. То есть это - объекты, которые были созданы. Но как они были созданы? Скорее всего на заводе производителя по чертежам. Ок, чертежём назовём конструктор. Ну а класс? А что это такое? А его нет в нашей вселенной - эта сущность есть абстракция, что живёт лишь в наших мыслях. В реальном мире её нет и никогда не будет, такова уж физика - ей по барабану, что птицы и млекопитающие имеют дальних родственников - она лишь обеспечивает возможность естесственного отбора. А уж родственников друг другу находим мы, люди.

С объектами и классами разобрались, а что же там с нашими стаканами и велосипедами. Мы уже поняли, что всё это объект, то есть грубо можно все объекты наследовать от какого-нибудь суперпредка, суперкласса, что и реализовано в некоторых языках. Но что другого общего между скейтом и стаканом, например? Конечно, можно углубляться и считать, что они все из молекул, и они все из твёрдых веществ. Однако это всё бред и СПГС, так что ответ прост - да ничего. То есть это совершенно разные объекты с совершенно разным функционалом. Более того - естесственно компьютерные модели и иерархии будут сильно отличатся от физик и химий. И это нормально, вопрос об адекватностях моделей ставиться лишь когда модель неадекватна, а до тех пор пилить можно что угодно, лишь бы работало.

Вот. У нас есть супер-предок Object, от которого дефолтно наследуются все объекты. Допустим, то что объекты состоят из атомов и есть то, что наследуют все объекты. Но все дополнения и правки - полиморфизм. Так, из атомов мы слепили колёса и приделали на доску - ок, это скейт. На него можно встать и катиться, а сильно извернувшись и полетать в трёх метрах над землёй, прямо таки излучая своё яркое эго. В то время как стакан - это мы слепили из атомов плотную ёмкость, из которой вода не выливается под действием силы тяжести. И прямое применение стакана - налив воды опрокинуть его над ртом, чтобы вода вытекла прямо в желудок. Так делают настоящие пацаны, не заботясь об икоте или страхе утонуть, так что вот - полиморфизм.

Однако что с остальным? У нас ещё абстракция, инкапсуляция и наследование. Ок, начнём с наследования, так оно наиболее близко. Вот что у нас общего между стаканом и кружкой? Ну в оба можно налить воду, но у кружки есть ручка чтобы держаться. То есть можно придумать некий общий класс - ёмкость. Однако что это за класс? Можно например за этот класс взять стакан, тогда все ёмкости по дефолту стаканы, а всё остальное - видоизменённые стаканы. Но кому-то больше нравяться кувшины, например некоторые чики насят их на голове, считая что это удобно. Ну и пусть носят, но как-то же решить надо, что главнее и идеальнее. Так вот - недостяжимый идеал и есть главный - это называется абстрактный класс. То есть ёмкость, что невозможно создать, для которого нет полного чертежа. А все чертежи, что дополнили до полного - есть наследованные классы от класса ёмкость.

Тут мы подошли к абстракции. Вот такое иерархическое наследование приводит нас к, возможно главной, идее ООП. Вот мы взяли и выделили всё, куда можно налить воду в отдельный класс, нарисовали общий чертёж, но специально не доделали его, оставив зазор для будущих творцов, и назвали чертёж - ёмкость. Тысячи лет изобретатили всех миров создают свои ёмкости, одна лучше другой. Для разных людей - по разному, конечно. Но каждый раз группировать молекулы стекла определённым образом - непростая задача. Поэтому ремесленники пошли на хитрость, они создали тайный совет ремесленников мира и решили делиться друг с другом своими наработками. То есть создавать мелкие чертежи и объявлять классом, например, извлистой ручки в форме ленты Мёбиуса, например. Возможно такая ручка удобно только инопланетным существам, но чертёж создан и к нему можно ссылаться при создании своего чертежа. Таким образом мы абстрагируемся от низкоуровневой задачи "формирования ёмкостей посредством перемещения молекул" к "конструированию ёмкости посредством совмещения деталей, элементов". Это и есть абстракция.

Но мы подошли к последнему пункту - инкапсуляция. Она неразрывна с абстракцией, и по сути благодаря ей она и работает. Инкапсуляция - это своеборазный клей (или синяя изолента), которым склеивают разные чертежи в один. То есть совмещение деталей для создания своей - это и есть инкапсуляция. Причём при совмещении мы можем не описывать детали этого совмещения (то есть члены класса могут быть приватными), таким образом помогая абстрагироваться тем, кто этот чертёж использует. Вот посмотрим на чайник - что это такое? Это стакан (или кружка) к которому снизу (а может внутри по середине?) приклеен нагревательный элемент. Пустив по нему ток, согласно инкапсулированному в нагревательный элемент закону Ома, будет выделяться тепло и нагреваться вода. А кофемашина? Это куда более сложное устройство, с множеством насосов, ёмкостей, шлюзов, измельчителей и чайников. И всё склееное клеем. А может синей изолентой. Это снова инкапсуляция.

Таким образом, абстракция невозможна без инкапсуляции и наследовании, как невозможен полиморфизм без, собственно, наследования. Ну а полиморфизм невозможен ещё и без инкапсуляции, которая банально бесполезна без наследования и полиморфизма. Вот такие тут треугольники с пирогами. Жаль только про пирог наврали. И про день рожденье.

Полиморфизм указывает, какую версию метода текущего объекта запустить.
Например, у вас есть несколько наследуемых классов, с разной реализацией одного и того же метода. То есть, у вас есть несколько разных методов с одинаковым именем (и сигнатурой), реализованных в разных классах. Какую версию метода вызвать? Это зависит от типа переменной, в которой находится объект.
Также с помощью полиморфизма можно поместить объекты разных классов в один массив с типом базового класса.

Создадим три класса с двумя методами - один виртуальный, а другой нет. Виртуальный метод переопределён (override) в классах-наследниках. Невиртуальный метод просто скрыт в наследниках новой реализацией (невиртуальные нельзя переопределять).

class Animal {
    public void Info() { Console.WriteLine("Animal"); }
    public virtual void Say() { Console.WriteLine("Nothing to say"); }
}
    
class Cat : Animal {
    public void Info() { Console.WriteLine("Cat"); }
    public override void Say() { Console.WriteLine("Meow"); }
}
    
class Dog : Animal {
    public void Info() { Console.WriteLine("Dog"); }
    public override void Say() { Console.WriteLine("Woof"); }
}

При создании объекта важно, в переменную какого типа объект будет записан:

Dog dog1 = new Dog();
Animal dog2 = new Dog();
// Не виртуальный метод - вызовется метод класса, указанного у переменной 
dog1.Info(); // напишет Dog
dog2.Info(); // напишет Animal
// Виртуальный метод - вызовется метод класса, которого переменная реально имеет
dog1.Say(); // напишет Woof
dog2.Say(); // напишет Woof

А теперь частая ситуация, когда полиморфизм нужен - при итерации массива:

Animal[] animals = new Animal[10];
FillAnimals(animals); // заполним массив вперемешку собаками и кошками

foreach (var animal in animals) animal.Say(); // вызовется правильный метод
// У невиртуальных методов так сделать нельзя! Полиморфизм в действии

Наследование без виртуальных методов полезен только фиксацией интерфейса.

Вот весь код примера: code.re/5ZC
Вставьте его вот сюда и проверьте.

P.S. Написал код на C#, чтобы подчеркнуть разницу между виртуальными и невиртуальными методами. В Javascript все методы виртуальные (как и в php, например).

UPD. (спасибо @Petroveg)
В языке C# (и других статически типизированных) обычно делают так - если метод в базовом классе записывается для всех потомков и оттуда будут использоваться напрямую, то он помечается обычным, невиртуальным. А если метод предназначен для того, чтобы в наследниках его переопределить, то необходимо его сделать виртуальным, чтобы при вызове метода компилятор выбрал нужную версию метода. То есть некоторые методы лучше делать виртуальными, а некоторые нет.
И ещё раз - виртуальность важна только в одном случае - если объект-наследник записан в переменную базового класса:
Animal animal = new Dog();
В javascript невиртуальных методов не бывает - динамическая основа этого языка ВСЕГДА автоматически вызывает именно последнюю версию метода, определяя конкретную по цепочке прототипов. Поэтому в Javascipt, по большому счёту, сильно думать о полиморфизме смысла нет - это только абстрактная концепция, не влияющая на сам код, а только на архитектуру.

Так вы кладёте 2 фрукта хомяку speedy, а хомяку lazy — ничего. Lazy нервничает...
И почему не используете var?

Ибо создано два разных экземпляра класса, соответственно, у каждого свой length у food

speedy.found("apple")
lazy.found("orange")

name.set({"age": 20}, {validate : true});

Можно почитать smashing magazine (англ.)
В статье высказывается мнение, что m-поддомены - это прошлое. Предлагается определять платформу пользователя (PC, mobile, tablet) и выдавать разный контент для них. Там описаны технологии и что как можно организовать.