⚡ Kotobotov ⚡

цепи маркова всегда генерируют случайные данные (мусор), просто ограниченные определенными правилами (размерами вероятностей).
поднять качество можно используя соревновательный подходы GAN (в области генерации такой подход сейчас на острие находится).
подробнее тут:
https://ru.wikipedia.org/wiki/%D0%93%D0%B5%D0%BD%D...

>Условие: горизонтальная масштабируемость, работа с общей РСУБД.
изначально противоречивые условия.
---
не стоит вам на ноде воротить что-либо для управления серверами и на ее основе выстраивать микросервесную архитектуру.
Посмотрите Kafka, Cassandra.

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

подводных камней достаточно. Я бы выделил основные проблемы с тем что ты всеже не видишь что реально получаешь, а также не можешь проконтролировать что именно тебе доставят в каком виде и какого качества, по дороге например могут разбить дисплей (у меня такое было) ну и скорее всего тебе никто не возместит это повреждение (хотя может можно попытаться что-то с транспортной компании взять). В любом случае это дополнительный геморрой, связанный с тем что ты можешь получить совсем не то что ожидаешь. Лучше покупать просто у местных перекупов.
Учти также что тебе нужно будет при оплате потерять в районе 5% (зависит от банка) на конверсии курсов.
По поводу таможни, даже если сбором не облагается, могут заставить тебя какие-нибудь справки предоставить что именно этот товар разрешен на ввоз и тд, ну или просто месяц дополнительно держать и проверять что-нибудь.

Одного подхода нет, есть у вас конкретные задачи, под них подбераете решение (архитектуру), можно постоянно подготавливать фронтэнд на бэкенде, можно отдавать заранее подготовленный фронтэнд (в виде ХТМЛ или ЖС файлов пользователю) который потом будет собирать у себя в браузере более сложный вид продукта.
==
Вам просто нужно определится как бы обмениваетесь данными между фронтэндом и бэкендом, обычно используют формат JSON (не обязательно).
Сейчас часто распространена схема при которой - JS скрипты в браузере клиента грузят с бэкенда только JSON с данными и отображают эти данные в более сложных формах непосредственно в браузере.
П. С.
логику редиректов и всякого такого роутинга можно написать на самом фронтэнде, перехватывая запросы пользователя и специфичным образом их обрабатывая, запрашивая нужные данные с бэкенда через апи.

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

конечно можно/нужно идти на встречу клиенту, хотя также не понимаю какие проблемы договорится о небольшой доплате, обычное дело когда требуются доп работы по изменяемым требованиям.
У вас самая плохая ситуация, когда требования меняются в процессе работы, вы понятное дело идете на встречу и берете доп работы, а потом вам выставляют претензию, что делали дольше или делали не то что оговорили в начале (подстава короче).
На 5 часов работы можно и забить, удалите проект, отмените проект, верните деньги. Затем начните с ним переговоры со стартовой точки -> у клиента будет возможность заказать работы у более подходящего (на ее взгляд) подрядчика или у вас -> в любом случае клиент имеет выбор - он счастлив и доволен, а это главное)
Вы работаете в долгую, вам от 5 часов работы не холодно не жарко. Пускай клиент сам выберет будет он вам доплачивать или закажет это у кого-то другого.

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

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

данные о пользователе передаются или в виде параметра в ссылке, либо в виде заголовка запроса
поэтому можно GET, POST /course/:courseUuid

П. С.
ни что не мешает лесону иметь и ГЕТ /courses/:courseUuid/:lessonUuid
и GET /lesson/:lessonUuid
типовой подход иметь унифицированный апи, с одинаковыми ПОСТ и ГЕТ (и добавочные запросы с низкой иерархией типа /lesson/:lessonUuid)

модель Маккалока-Питтса - это математическая модель
персептрон Розенблатта - это физическая реализация модели.
тоесть об одном и томже речь

ИКО - это отдельный бизнес который может оказаться сложнее и дороже самого стартапа.
Тебе придется заняться - майнингом свой криптовалюты (покупать свои мощности, либо как-то арендовать/партнерится), заниматься популяризацией этой криптовалюты, привлечением людей на ИКО, объяснять массам что такое криптовалюты и почему именно по такой схеме вы привлекаете инвестиции.
С другой стороны там люди вроде собирали большие деньги под полную пустоту даже в формулировании идеи и без следа и какой либо ответственности исчезали.
В общем если задача сделать проект - то делай проект, если задача срубить "ни за что" бабла - то делай ИКО.

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

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