NubasLol

В течение дня с помощью 3 курьеров нужно развести 20 коробок по 20 адресам из 4 точек. Например в рамках Питера.

Для начала тебе нужно построить граф путей, где вершины - это 20 целевых адресов и 4 исходные точки, а вектора - это оценка (в худшем) времени пути между ними, причем как от складов до адресов так и между адресами. Это тут самая сложная задача, так как исходные данные только карты, где непонятно сколько времени ехать, есть ли зависимость от времени суток и нагруженности курьера.

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

Ну а дальше комбинаторика, самый тупой метод поиска в глубину решит условно любую задачу, причем найдет оптимальное решение, но максимально неэффективным (с точки зрения затрат на решение) способом, у тебя всего 3 курьера и всего 20 точек, это ниочем.

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

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

Есть два пути: Путь джедая для тех кто хочет познать силу и Короткий путь для тех кто хочет получить ответ на задание.

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

Не узнаю тостер. Казалось бы, еще недавно была мощнейшая пропаганда карьеры в айти. Захожу, а тут внезапно стала пролезать правда. Даже куратора DevMan забанили, лол. Новички год назад были особо никому не нужны, а теперь тем более. Если вы так хотите стать программистом получайте соответствующее образование в компьютерных науках, изучайте рынок. Думаю что скоро понадобятся настоящие инженеры которые могут разрабатывать сложные системы. Кодомакак уже достаточно на рынке, больше просто не нужно, даже если за еду будут проситься работать. Через некоторое время часть из них вообще на мороз пойдет если вовремя за ум не возьмутся. Настраивайтесь серьезно и готовьтесь вкалывать как проклятый если хотите стать программистом в это непростое время и удержаться там.

Может быть и своя схема.
А может быть просто отдельная колонка у каждой сущности, которая указывает, какому тенанту объект принадлежит.

Первый вариант проще будет по логике со стороны приложения.
Второй вариант чуть проще поддерживать, так как схема будет обновляться одновременно у всех клиентов (хотя иногда это наоборот будет минус)

Тут все довольно просто. У нас есть слой бизнес-логики, который имеет 3 интерфейса:
TransactionManager - собственно менеджер транзакций
OrderRepository - репозиторий заказов
PaymentRepository - репозиторий платежей

И, допустим, нам нужно транзакционно сделать следующий сценарий: "при получении платежа записать его в БД и изменить статус заказа на PAID" (пишу пример на Kotlin, надеюсь понятно)

transactionManager.inTransaction {
  order.status = PAID
  paymentRepository.save(payment)
  orderRepository.save(order)
}

Собственно дальше - это уже вопрос реализации TransactionManager. Если мы имеем дело с простым случаем, таким как хранение данных в SQL Database, то его реализация должна быть понятна. Если более сложный случай - то распределенные транзакции, либо пустая реализация (транзакционность не поддерживается). Разумеется, при инжекции зависимостей в модуль бизнес-логики реализация менеджера транзакций должна соответствовать реализации репозиториев (мало толку будет если менеджер транзакций реализует транзакционность в БД, а репозитории - хранение в файлах). Но это уже слегка другой разговор, тут на помощь приходят фабрики и подобные шаблоны.

Нужно понимать, что orderRepository и paymentRepository — это абстракции, а фактически данные могут храниться как в одной базе, так и в совершенно разных. Например, orderRepository находится на сервере S1 в базе Redis, а paymentRepository — на серверах S2, S3, S4 в базе PostgreSQL. Поэтому, классические транзакции здесь неприменимы. Этим можно пренебречь в большинстве случаев и не переусложнять систему, а можно пойти "правильным" путём и использовать распределённые транзакции, например, саги https://microservices.io/patterns/data/saga.html

Docker - это не виртуализация. Это построенная на базе линуксовых namespace и cgroups средство изоляции процессов.
Под Windows и Mac нет линуксовых namespace и cgroups поэтому приходится запускать контейнеры в виртуальной машине, что и создаёт путаницу.

movie_person (movie_id person_id) person_role (person_id role_id)
связать все belongsToMany.
Только я бы role переименовал т.к. это ближе к системным ролям юзеров, а не контенту.

“Черный лебедь”. Нассим Николас Талеб
довольно необычная книга по экономике для начинающих, которая рассказывает не об экономике для чайников, а о некоторых секретах, зная которые вы сможете стать более успешным и быть на шаг впереди всех своих соперников. Автор данного произведения — успешный математик, который рассказывает о некоторых якобы случайностях, которые можно предугадать и сыграть на этом в свою пользу.

“Экономист под прикрытием”. Тим Харфорд
“Овцы в волчьих шкурах”. Уолтер Блок
“Доктрина шока”. Наоми Кляйн

Игнорировать по ID нужно, если в модели не прописано иное, а вы по slug пытаетесь.

// 'slug' => 'required|unique:categories,slug,'.$category->slug,
'slug' => 'required|unique:categories,slug,' . $category->id,

Как устроена экономика автора Ха-Джун Чанг

Фридрих Август фон Хайек.
"Дорога к рабству"

Экономикс