bromzh

Если новичок, то естественно лучше спринг. Хотя бы потому, что по спрингу намного больше инфы. Ну и влюбом случае, хорошо изучи сперва саму яву.

Посмотри на проект nginx. Человек работал и параллельно пилил сервак для собственных нужд. Проект сам себя разрекламировал, так как был качественным. А сейчас Игорь основал компанию, в которой занимается разработкой коммерческих решений. Деньги получает как раз за техподдержку При этом весь код открыт.
Таких историй не мало: некие люди на работе пилили проекты под свои нужды, а потом, если продукт оказывался успешным, приходили и деньги.

Так что если хочешь стать частью опенсорс - то пиши код, а не думай о деньгах. Качественный продукт сам семя разрекламирует.

Никак, давай элементам осмысленные имена. Не как они должны выглядеть, а что они из себя представляют. И не надо делать классы, явно указывающие на размер/цвет и т.д. Потому что это почти ничем не лучше, чем вёрстка прямо в html-коде через атрибут style.
Можешь посмотреть как рекомендуют чуваки из яндекса.

чтобы margin: auto работал, ширина должны быть фиксированная.
Там вообще в вёрстке приличный говнокод. Как с сеткой бутстрапа можно такое натворить - непонятно.

BrowserSync + любой сборщик (Gulp/Grunt/etc). Или можно поставить WebStorm и плагин livereload.

Остаток от деления. Вообще это в школе проходят, элементарные основы теории чисел.

Только ситхи возводят всё в абсолют. ООП для каких-то случаев хорошо применим, а для каких-то нет. Тоже самое справедливо для любой другой парадигмы. А выбирать технологии только исходя из общей моды очень тупо.

Может потому что это и есть почти тоже, что и eval? Следовательно нужно тщательно проверять входные параметры. А ты сразу вызываешь её от значений атрибутов, даже не проверив их ни на что. Ну и отслеживать ошибки в таких штуках крайне сложно.

habrahabr.ru/post/244001/#comments

Да почти любой подойдёт. Возможно даже хватит библиотеки типа бекбона.
Выбери наиболее популярный, с хорошими доками и крупным сообществом. Можешь тут посмотреть.

Я бы взял ангуляр, потому что хорошо его знаю. Да, возможно будет оверхед, так как часть функций не будут использоваться. Но с другой стороны, приложение будет легко расширить в дальнейшем.

Например momentjs.com
Смотри исходники, подстраивай под себя.

Для андроида пишуь на яве потому что гугл давно полюбил этот язык, и сделал свою мобильную ОС (андроид) именно на этом языке. Под капотом там особое ядро линукса и переработанная виртуальная машина явы, которая и служит прослойкой, между приложухами и ядром. Т.е. почти любое приложение запускается в этой виртуальной машине, соответственно должно быть написано на яве (если точнее, то виртуалка запускает байткод, который получается после компилирования программ). И большинство библиотек именно для явы.
Можно писать на питоне, но это медленно. Да и библиотек намного меньше.
На C/C++ тоже можно писать, но там свои заморочки. и гугол рекомендует использовать это лишь в крайних случаях.
Для остальных языков инфраструктура тоже небольшая. Так что в 95% стоит брать яву, как и задумывалось.

Ну а на счёт того, что ява ужасна, на ней нет приложений и она скоро сдохнет - это полный бред. Язык простой (хоть и многословный), инфраструктура JVM ещё лучше. есть огромнейшее число библиотек на все случаи жизни. Ну и перспективы у него очень хорошие: андроидофонов сейчас намного больше, чем телефонов на других платформах, энтерпрайз любит и использует яву вовсю ( подавляющее большинство интернет-банков именно на яве), десктопные приложения можно писать на хорошем JavaFX. Т.е. область применения очень широкая. И это реально кроссплатформенный язык, так что запускать свои поделки можно почти везде. Скорость у явы вполне хорошая (например, в бенчмарке сетевых фреймворков, сервера на яве обычно в лидерах), а многословность лечится другими языками (scala, kotlin, groovy).

посмотри как генератор gulp-angular-generator хранит таски. Очень удобная и гибкая структура.
Пощупать можно так:

npm install -g yo gulp bower
npm install -g yo gulp bower
mkdir test
cd test
yo gulp-angular

В папке gulp таски, разбитые по файлам. В Gulpfile подцепляются автоматом все файлы из папки gulp.

попробуй объявить поле action в родительском классе:

class Father(models.Model):
    COST = 100
    content = models.TextField(max_length=COST)
    action = models.BooleanField(default=False)

    class Meta:
        abstract = True

    def save(self, *args, **kwargs):
        if self.COST > 200:
            self.action = True
        super(Father, self).save(*args, **kwargs)

class Children(Father):
    COST = 500

Блин, да это же джанго, он сам явно подталкивает к одной структуре приложения.
Одно приложение на 1 логическую и независимую часть сайта. Например, интернет-магазин должен включать в себя каталог продукции и функционал для заявок. Потому что они взаимосвязаны. А вот новостную часть на этом сайте надо выносить в отдельное приложение, так как новости обычно почти не связаны с заказами и товарами как таковыми.
Ещё в каждом приложении можно создавать папку static, куда класть все статические файлы. Но так обычно поступают разрабы "плагинов" для джанги. В рамках сайта можно коласть в 1 папку static в корне проекта, но разделяя js и css файлы (чтобы вёрстка не было в 1-м суперогромном css файле, в котором хрен чо найдёшь). Потом сборщики должны всё собирать и минимизировать.
Шаблоны раскидывай по папкам, соблюдая иерархию. Т.е. если есть приложение shop, то в корневой папке templates создай layout.html, а все шаблоны магазина клади внутрь templates/shop, наследуя. Также можно хранить шаблоны внутри приложения, но опять же, это обычно используют разрабы "плагинов", хотя сам принцип хорош.

Чисто промисы - это та же лапша, только в профиль. Ну только вложенность уменьшается. Генераторы и yield выглядят получше.

Так же, где применим yield помимо асинхронного кода?
Там, где нужны генераторы