Игорь Че

MVC это абстрактное понятие, которое обозначает разделение логики. Как вы это назовете не суть. Главное чтобы работа с логикой, с данными и с внешним видом была разделена. Т.е. если у вас три класса в одном файле и с помощью одного вы делаете доступ к данным, с помощью другого делаете доступ к внешнему виду, а с помощью третьего связываете все это вместе, то у вас тоже MVC.
В django логика работы программы(controller из MVC) описывается во view, работа с данными(model из MVC) происходит через model, а внешний вид(view из MVC) описывается в template. Во flask нужно самому думать что в какой файл положить и как делать структуру файлов.

ol 
    & > li 
        & > ul 
            & > li 
                стили

Но вообще это очень плохой стиль написания стилей (сорри за тавтологию)
Читайте про БЭМ

генератор?

если тебе нужно из одного набора (set'a) вычесть другой, то

In [8]: set(l2) - set(l1)
Out[8]: {2, 4}

если не set

In [9]: [x for x in l2 if x not in l1]
Out[9]: [2, 4]

Ну вы в succes кажется затираете ваш инпут

jQuery('[name=' + name + ']').html('<div class="pop2">'+msg+'</div>');

Разместите над вашем инпутом
Смените в beforeSend и success jQuery('[name=' + name + ']') на jQuery('#for_progress')

Например навскидку:

>>> a,b=94,54
>>> (a*(a//b) + b*(b//a))/(b//a+a//b)
94
>>> a,b=6,322
>>> (a*(a//b) + b*(b//a))/(b//a+a//b)
322

P.S. Делал в консоли Python, поэтому явно функции для ввода/вывода на экран не использовал, если это важно, конечно :)

Просто удалите файл данной миграции если она еще не применена. Исправьте и выполните makemigrations еще раз.
По manage.py show migrations можно глянуть примененные и непримененные миграции.
Указав номер, можно откатиться на предыдущую миграцию
manage.py migrate <модель> <номер миграции>

Кавычки забыли.
print_r($var['#item']);

например в css стилях

QPushButton#exit_button {
    border-image: url(resources/icons/64/exit.png);
}
QPushButton#config_button {
    border-image: url(resources/icons/64/config.png);
}

config_button и exit_button имена объектов

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

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

Также важной чертой REST является отсутствие состояния, сохраняемого между запросами к ресурсам. Это очень важно для масштабирования системы.

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.

Можно с помощью canvas сделать:

document.addEventListener('mousemove', function(e) {
    ctx.clearRect(0, 0, w, h);
    ctx.beginPath();
    ctx.arc(e.offsetX, e.offsetY, 30, 0, 2 * Math.PI, true);
    ctx.rect(0, 0, w, h);
    ctx.fill();
});

JSBin

Когда-то начинали с товарищем делать сайтики, только я был "программистом", а он собирал заказы. Одни из ошибок, которые позволили загнуться нашему совместному предприятию (просуществовали мы почти 2 года) - это:
- недостаточно опытный программист (это я), плюс, если брали помощников, то они были еще неопытнее меня.
- не составлялся четкий план на разработку, проектирование проекта не проводилось, из-за чего по ходу дела возникали ситуации, которые можно было решить еще на этапе проектирования, но нет, приходилось тратить время уже во-время разработки. Как следствие этого - неожиданное увеличение сроков.
- не было четких условий для заказчика, т.е. типовой договор был, но, например стоимость правок оговаривалась налету, некоторые заказчики округляли глаза и приходилось делать забеслпатно. Следствие чего заказчик был царь и бог и некоторые их долги по оплате не были отданы до сих пор.
- желание сэкономить, нет, я понимаю, что экономить нужно, но не на том, что приносит тебе доход, по-этому дизайнеры были хреновые, помощники говеные и т.д. Из-за чего заказчик был не доволен, а срок разработки проекта очень сильно увеличивался.
- заказы по сложности и требованиям несопоставимые со стоимостью, т.е. напарник брал сложные заказы за смешные деньги, сетуя на то, что город маленький (300 000 жителей) и никто платить не хочет, в итоге с созданием и доработками выплаты задерживались, следующие заказы брались , пока недоделаны предыдущие и получался ком, которые ничего хорошего не обещал.
- ну и результатом всего этого стало огромное количество долгов и плохих отзывов.
Ну вот такие были проблемы у студии "Рога и копыта" из двух человек, какие вспомнил ))
*пы.сы. не знаю, зачем это написал, просто, что-то вспомнилось.