Максим Федоров

Пара кейсов, после которых идея "передать на фронт и фильтровать там" перестает казаться такой хорошей

1) Прилетел массив на 10 000 элементов. Клиент зашел с Samsung galaxy S2 , попробовал загрузить/фильтрануть, посмотрел, как завис браузер, и ушел. Не забывайте, что не все пользователи сидят с десктопов как у разработчиков с 16-32Gb оперативы. Мобилка может поперхнуться банально из-за большого json-а

2) Как только потребуется сделать паджинацию - фильтрация на фронте станет выдавать неожиданно некорректные данные

Пинайте сервер-сайд, пусть разрабы или кэшируют, или расставят индексы в базе правильно, если у них SQL, или перейдут на подходящий поисковый движок с фасетным поиском

Я верю, что можно сделать выдачу и фильтрацию чисто на фронте с любым количеством элементов, если команда состоит из сплошных ниндзя и рокстаров, но практика в 3 подобные ситуации показывает, что в итоге эту фильтрацию придется переписывать как минимум на гибридную (и поддерживать 2 решения, на фронте для малого количества записей, и на бэке для большого), либо полностью на сервер сайд, так как к сожалению команда никогда не состоит из идеальных разработчиков, чаще из обычных живых людей

да нет, ab как раз тестирует "сайт", хоть и однобоко (только один адрес долбит).

siege, pylot, jmeter, wrk и ещё множество подобных утилит вам помогут.

Считаем кол-во новостей, делим на некий $limit(количество новостей на страницу), соответственно получаем кол-во страниц $page_count, вместе с запросом передаем параметр, допустим &page=3, соответственно делаем запрос БД с учетом нашего limit и с offset, который будет равен $offset = $limit * $_GET('page').
Получится запрос типа:
SELECT * FROM news LIMIT $limit OFFSET $offset;
Сами ссылки при этом это обычный цикл for($i=1;$i<=$page_count;$i++). Обычный список, который содержит ссылки у который href будет содержать итератор $i. Ну и соответственно имея $_GET('page') и $i вы модете вычислять активный пункт и т.д. Выводить не все, а только следующие 5 и предыдущие 5. Тут уже как говорят "по вкусу"

Отказ от var современном модульном коде обусловлен тем, что использование только const и let, const для переменных которые не переопределяются и let для переменных которые переопределяются повышает читаемость кода и снижает когнитивную нагрузку с программиста, читающего код.
Такой код воспринимается легче и быстрей.
Так же в современном модульном коде нет ни одного объективного кейса для предпочтения var вместо const/let.

Гайдлайн AirBnb.
ESLint no-var

Делаете работу
В процессе находите ошибку в стороннем коде
Находите ее источник
Пишите багрепорт и тесткей
Так как всем пофиг
Сами фиксите баг
Неделю стучитесь мейнтейнеру, чтоб он принял ваш пушреквест
Он вас посылает, тк ето не баг

На счет IDE - хватит, да хоть блокнот.

Порядок.

1. Создайте django приложение.
2. Создайте vue приложение.
3. Накидайте html.
4. Cоздайте модель сообщения.
5. Напишите API на DRF.
6. Потом при помощи vue делайте запросы на сервер и тяните сообщения.

Рекомендуется для каждого проекта создавать отдельное окружение.
На счет бд , юзайте sqlite, не парьтесь.

Хостинг - на ваш вкус Heroku , Pythonanywhere и т д.

Туториал 1.
Туториал 2.

Нет, конечно же. Попробуйте
ps ax | grep nginx | grep -v grep
- будет пусто :)

ЗЫ: последняя команда исключает из списка строки, где есть текст "grep". Это обычно делается для того, чтобы исключить из вывода строку, где grep находит сам себя.

Постоянная работа по ночам - ужас для организма и нервной системы. Солнечный свет нужен.
Как варианты, кроме полноценного сна и питания (совершенно согласен с xmoonlight):
- Витамины, особенно группы D
- Переехать в соответствующий часовой пояс. Если это US, то Мексика к примеру, там относительно дёшево сейчас. Или Южная Америка.

Ну если есть вакансии которые вас устраивают то не стоит