Руслан Гильфанов

Изучал фласку первые пару недель. Она простая, "некомбайн". Разобраться что да как работает - пойдёт (потому что вьюхи и шаблоны у них с джангой похожи).

Дальше лучше переезжать на джангу. Фласк лучше джанги примерно в 1% всех случаев - это те, когда тебя джанга не устраивает целиком и полностью: ORM не хватает или не подходит, стоковые сессии и юзеры тебя раздражают, контекстные процессоры и мидлвари тратят слишком много ЦП, что лучше бы их на Си переписать. Короче, тогда, когда своё написать быстрее и проще, чем строить костыли поверх джанговских компонентов с сильной связью.

Плюсом идёт просто огромная куча модулей для джанги (по сравнению с флаской) и бОльший спрос на джангу на рынке труда.

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

Суть для вашего случая: разметить sdb, инициализировать как degraded массив:
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb5
Перенести всё полезное с sda на sdb, поправить загрузчик, перезагрузиться с рейда, добавить разделы sda в соответствующие массивы.
Инициализировать массив напрямую на устройство, а не разделы, возможно, но с этого устройства нельзя будет загружаться.

Разные фокусы с переносом всего полезного. Системный раздел может быть проще через dd скопировать (но раздел на sdb должен быть чуть больше, там ещё mdadm суперблок в 2048 секторов)
/home - начальную копию в 2-3 прохода rsync'ом, затем перемонтировать в ro и ещё один rsync.

Сначала соберите деградированный массив из одного не размеченного диска.
Перенесите на него данные с размеченного диска.
Добавьте в массив второй диск.

Как-то так help.ubuntu.ru/wiki/migrate-to-raid

И да, конечно сначала сделайте ебэкап.

https://github.com/allanlei/python-zipstream

В общем Flask тут не причем
Нужно разобраться с архитектурой такого рода задач
То что вы уже сделали - это только лишь слой представления(View) данных
Это все круто, но эта часть не должна заниматься сбором данных. Она должна читать их из какого-то хранилища в уже готовом виде.

Сбором данных должна заниматься другая система
Если вам хочется питон и не сильно хочется выдумывать велосипеды - я бы рекомендовал взять scrapy и нафигачить там нужных скреперов. В нем же можно организовать pipeline - в котором определить что делать с полученными данными.
Тут есть много путей но я бы рекомендовал вам наиболее простой - писать данные из scrapy в базу данных например mysql, а оттуда уже читать данные в вашем flask-приложении.
В зависимости от объемов может оказаться, что предложенное решение не эффективно.
Так как по сути вы интересуетесь сбором метрик то в боевых условиях я бы рекомендовал использовать специализированные инструменты для сбора и отображения метрик (например связку graphite-grafana)
Вряд ли Ваша связка mysql-самописнаявебморда переплюнет их по производительности качеству и стабильности.
Так что все действительно зависит от объемов и категории задачи ( я имею в виду "это завтра пойдет в продакшн" или "вот для себя пишу разбираюсь")

Использовать tox.

RoR(Ruby) и Django(Python) практически одинаково хороши для прототипирования. Делайте на том, что знаете лучше. Остальное — холивар.

Поможет параметр prefix, но форму инстанцировать придётся дважды:

callback_form_header = CallbackForm(prefix="header")
callback_form_footer = CallbackForm(prefix="footer")

Рекомендую 15-летнему школьнику не использовать IDE.

Асинхронный код позволяет выполнять код параллельно в одном потоке, итого профит в том что экономится память т.к. каждый поток требует память под себя. По сути все.
Итого это позволяет запускать 1Млн параллельных задач и более, экономя память.

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

Асинхронный подход имеет смысл (только) когда в задаче есть долгие блокировки (веб-сокеты, сетевые закачки с зависаниями) - когда поток весит и ждет события, тогда вместо 10к потоков, можно все задачу уложить в один асинхронный поток.

Все бы нечего, но проблема в том что сложность асинхронного кода гораздо выше в разных аспектах, итого времени может тратится в разы больше (год на проект вместо 4 мес например).

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

Более разумным видится использование файберов/корутин, но эту тему не сильно развивают.

Розенталь, например.

А Вы не пробовали связаться с прошлыми ментейнерами? Может, и форкать не придется — если они согласятся передать библиотеку в Ваши руки.

По вопросу — думаю, что правильнее будет добавить себя с указанием дат копирайтов(дескать до 2011 — такие-то люди, после — другие). Видел такое в некоторых файлах LICENSE.

По умолчанию нумерация начинается с 0, и когда вы пишите range(10) он выдает 10 элементов, а не 11, и это удобно. Остальные кейсы подстроены под это.