dpismenny

Стоит задача превратить это всё в ООП

давайте не так, не в ООП а просто в читабельный и поддерживаемый код.

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

$("#addComment").css("display", "block");

и подобные можно заменить как

// функции хэлперы для устранения дублирования
function hide(selector) {
   return function () {
        $(selector).css("display", "none");
   };
}
function show(selector) {
   return function () {
        $(selector).css("display", "block");
   };
}

// специализированные хэлперы с говорящими названиями
var showCommentsForm = show("#form");
var hideCommentsForm = hide("#form");
var showAddCommentButton = show("#addComent");
var hideAddCommentButton = hide("addComment");

идем дальше...

var counter = parseInt($("#counter span").html())+1;
          $("#counter span").html(counter);

Тут явно стоит использовать data-*. Или любой другой способ подсчета. Знать бы еще что считается, судя по всему вам надо посчитать количество сообщений. В этом случае вообще так себе идея так делать.

$(document).on("click", "input[name='send']", function (){

лучше случать сабмит формы. Обязательно устраните "глобальный поиск" по селекторам.

Ну и это не говоря о том что инлайн стили, селекторы на айдишках, шаблоны с дублированием - это путь к боли.

Как всегда и везде, люди не до конца изучили agile/scrum и что то постят..

Ни где четко не прописано что заказчик должен быть вовлечен в процесс.

В первую очередь, SCRUM это управленческий фреймворк который позволяет упорядочить процессы, наладить коммуникации и поставлять инкременты итеративно.

В каком виде будет выглядеть ваш инкремент это уже решать вам лично. В виде юзер стори, в виде чеклиста/идеи/тасков/эпиков и т.п.

Если мы говорим о настоящем Agile Scrum, то собираем команду, изолируем её от всего кроме нашего проекта и дальше по методологии:

(тут есть только 2 простейших процесса где нужен заказчик на 1-2 часа в 2 недели. типичная ошибка, звать его везде как этому учат на дурацких тренингах за 1000$)

1. Собираем с заказчика хотелки и пихаем в беклог
2. Собираемся и грумим беклог дробя эпики на мелкие стори или еще мельче эпики
3. Делаем спринт пленинг и дробим беклог на задачи, поочередно оценивая всё
4. Согласовываем инкремент и какой Definition of Done
5. Работаем итерацию попутно проводя дейли статус митинги для синхронизации статусов и раннего выявления проблем
6. Демонстрируем в конце что получилось, собираем от заказчика фидбек и форматируем беклог, возвращая в него то что не готово и все что не влезло в спринт
7. Делаем ретроспективу и убеждаемся что копаем в нужном направлении и не делаем ничего лишнего либо добавляем в процессы работы то что стоило бы делать
8. Возвращаемся к пункту 1

Добавлю, что в беклоге может быть всё начиная от эпиков, юзер стори и заканчивая отдельными задачами, багами и т.п.

Когда вы начинаете оценивать стоимость и сроки проекта под Agile/Scrum вы наступаете на теже грабли. Если заказчик не знает на что он идет то это не Agile.

Наши клиенты уже с шишками и готовы платить деньги не представляя стоимости проекта в целом и тем более его сроков. С большего это стартапы. На опыте запуски и провалы хороших проектов. Один из них уже 4й год на рынке и поднял 20 лямов инвестиций в США и сейчас является одним из успешных интернет магазинов в США.

Изначально на кармане у заказчика было денег понты и работало 2 человека на проект - бекенд и айос и копали-копали пока не выросли до постоянной команды в 5 человек (бекенд, фронтенд, айос, андроид, qa) которые непрерывно работают на проекте и копают спринтами один за другим. И ни кто никого не гонит. Заказчик купается в бабле

Если кто-то путает окно браузера с областью просмотра, да ещё к min-width и min-width экран монитора приплетает — у него не только лыжи не едут, а в голове смазки маловато:)

1. Обрабатываются все media queries. От первого и до последнего.
2. Если выполняются условия в нескольких @media, то для конфликтующих правил вступает в силу обычный расчёт каскада (читай приоритет правил).

Относительно синтаксиса неплохо бы почитать спецификацию, да и вот хорошее описание.

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

А если реализовывать подручными средствами, то я предпочту двигать систему координат jsfiddle.net/4e4xtLng/1

После разных библиотек остановился на iScroll.