holllop

Собирался использовать в качестве БД PostgreSQL или MySQL, а вот с выбором фреймворков и других компонентов возникают проблемы.

Вот и замечательно. Обычно берут одну из этих СУБД, чаще первую.

Если вы имеете в виду подготовительные этапы в виде декомпозиции, ТЗ, то эти этапы собраны в упрощенном виде.

Надо продолжать собирать требования и на их основе искать решения.

Нужно взяться за протоколы передачи данных.
Начиная с геолокации:
1. что за устройства устанавливаются на грузовой транспорт?
2. куда должны передаваться данные?
3. с какой частотой?
4. какие ограничения у этих устройств?
5. кто получатель геолокации? какие посредники при сборе геолокационных данных?
6. что происходит при получении геолокационных данных?

В зависимости от решаемых задач с данными подбирается стек технологий.

Фреймворки обычно не играют решающую роль в выборе тех. стека, если только не набран опыт в некоторых из них.

VirtualBox + Debian.

Столкнулся с необъяснимой проблемой. У меня маленькая скорость скачивания игр в Steam на ПК. Скачивает игры при скорости 200 мбит/сек.

200мбит - это более чем нормальная скорость скачивания. Это же не торренты всё-таки.
У многих людей в принципе канал меньше.
Скорость может зависеть от нагруженности кэширующего сервера в твоём городе.
Попробуй поменять регион - может улучшится.
+ проверь, что у тебя не стоит ограничение на скорость загруки.

Второй вариант.

Вы там в самом начале написали условие получения наград - и/или
Это предполагает, что за задание может выдаваться несколько наград (диплом и мерч к примеру).

Значит вам нужна связь между таблицами задач и наград "многие-ко-многим" с промежуточной связной таблицей.

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

таблица tasks
id | other_fileds...

таблица rewards_diplomas
id | other_fields...

таблица rewards_currencies
id | other_fields...

и т.д.

reward_task - связная таблица

task_id | reward_type | reward_id
task_id     - идентификатор задачи
reward_type - тип награды (diploma, currency..)
reward_id   - идентификатор награды из соответствующей таблицы

Из плюсов - расширяемость. Из минусов - усложнение запросов выборки и невозможность использования внешних ключей и ограничений.

Получил оффер от одной компании (банка) с неожиданно большой суммой, чуть ли не x2 от запрошенной

Вероятно ты просто запросил сильно ниже рынка / стандартной ставки.
Что за банк?
Что за должность?

Например, все этапы собеседований HR пыталась ставить близко друг к другу.

А зачем растягивать?

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

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

1. Теоретически это возможно иметь такую разницу в r-squared. Но довольно редкий кейс, я бы перепроверил данные.

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

3. Посмотри на другие метрики например среднюю абсолютную ошибку, медианную абсолютную ошибку. Все они имеют хорошую бизнес интерпретацию с которой легко работать. Сам по себе r_squared это количество вариативности (дисперсии) объяснено моделью. 0.19 (19 процентов) вариативности объяснено моделью. Что очень мало и я назвал бы такую модель негодной. В то время как 0.99 (99 Процентов) очень много это учебные показатели, но это еще не все это не означает все супер. Посмотри на вышеупомянутые метрики они измеряются в единицах твоего таргета. Как они себя ведут.

4. RSS, ESS, TSS - далековато от бизнеса. Это значения которые нужны для F статистики. А она у тебя говорит сама за себя 4314 и 5. Первая модель (где 5) совершенно не пригодна. Вторую перепроверяй, и мысли категориями интерпретации. Это сама суть регрессивного анализа.

оф дока или стак

С настройками по умолчанию рабочие процессы Nginx работают с правами пользователя www-data.
У пользователя www-data нет доступа в каталог /home/ubuntu/.

Можно в файле nginx.conf заменить user www-data; на user ubuntu;

Или добавить www-data в группу ubuntu
sudo usermod -aG ubuntu www-data

нужно не изучать а поработать.
Написать рестфулл веб сервис с использованием ООП и чистой архитектуры, поработаьт с реляционной базой данных.
А то, что ты "изучил" без реальной практики - ничто.

Исходите из классификации - менеджер

Для начала можно посмотреть в их исходники. Беглый просмотр кода показывает основной план действий:

• Создать плоскость с кастомным материалом. Вершинный шейдер стандартный нейтральный, который ничего необычного не делает, только сохраняет координаты UV, чтобы их во фрагментном использовать. Фрагментный будет содержать в себе всю логику. Это частенько так делается в 2D-эффектах.
  
• Во фрагментный шейдер передать две текстуры. Одна обычная, для фона. Вторая - карта смещений для пикселей. Displacement map по-нашему. Берем пиксели из фона, смещаем по данным из карты смещений - получаем результат.
  
• Нарисовать текстуру для фона. В их случае она делается из кадров видео, т.е. вот этот бултыхающийся градиент на фоне в их случае заранее заготовлен. И, к слову, видно, что он шакалится. Но с точки зрения производительности видео тут - это хорошая идея. Генерирование клякс-градиентов - требовательная в вычислительном плане задача.
  
• Нарисовать displacement map по какой-то логике, завязанной на положение мыши. Тут большой простор для экспериментов. В их случае они используют отдельную сцену с кучей объектов, у которых меняются расположение и прозрачность в зависимости от положения мыши и просто со временем. Там много магических чисел. Вероятно все подбиралось наугад. Как это обычно и происходит. И потом они рендерят эту сцену в текстуру, которая передается в уже упомянутый шейдер. Можно было бы на 2D канвасе ее рисовать. Но с трехмерной сценой в таких задачах проще работать, хотя это поначалу кажется контринтуитивным.
  

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

От этого вполне можно оттолкнуться и сделать что-то подобное в рамках своих инструментов/требований/дизайнов.