OneCode ЧАТ

И от админа запускал, без толку

Это не выход

на боевой ошибки нет, открывает страницу, Там пошаговая форма, и при нажатии на кнопку, не переходит, пишет у вас нет прав

Вы про Log?

я там просто добавлял форвард ту 3307, без этого не открывался проект в браузере

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

Всем привет! Есть ли какое-то простое решение, если видео-файл размещён в файловой системе (на хостинге, или по S3), и проигрывать его во встроенном проигрывателе, но чтобы можно было в нём прокручивать, и менять скорость воспроизведения? Чтобы не на ютуб заливать, чтобы нельзя было ссылкой внешней делиться, а только на сайте смотреть.

Инста норм тема, но уж очень много времени сжирает

Ну это всё равно, что покупать машину без радиатора и сказать "А зачем он мне, я всё равно далеко ездить не буду, и в жару тоже не буду." Ну, как бы, ок ) Не будешь, значит, покупай )

Плюсы микросервисов Сегодня коротко обсудим основные преимущества микросервисной архитектуры. В процессе чтения предлагаю подумать - действительно ли тебе не хватает этих плюсов при работе в монолитной архитектуре? Или всё это фигня. Итак, мы переписали интернет-магазин на микросервисную архитектуру и даже распилили базу данных на части. Какие плюсы получили? Маленькие проекты Больше нет огромной кодовой базы в одном репозитории, где модули тесно связаны друг с другом. Вместо это есть несколько маленьких и понятных проектов, изолированных в своём репозитории. Переименовать поле в базе данных микросервиса уже не так страшно - другой сервис точно НЕ использует его напрямую. Нужно доработать модуль доставки? Открыл микросервис доставки и работаешь с его относительно небольшим кодом. Устойчивость к ошибкам Каждая ошибка влияет на свой микросервис. Ошибка в одном микросервисе редко приводит к остановке всего приложения. Конечно, здесь важно предусмотреть поведение сервисов, если "сосед" не отвечает, но в целом универсальной страницы "Упс, что-то пошло не так" достаточно. Отвалился сервис доставки? Хреново, но всё остальное работает. Быстрая доставка обновлений В маленький микросервис с чёткими границами проще вносить изменения. Ты можешь полностью изменять реализацию сервиса, не боясь сломать что-то в другом микросервисе. Главное, чтобы программынй интерфейс (API) и события (Events) остались прежними. Ну или выкатить новую версию API, а старую пока оставить для обратной совместимости. Нужно добавить новый способ доставки? Идёшь в сервис доставки и решаешь задачу, не беспокоясь о том, что можешь сломать сервис заказов или оплаты. Высокая доступность Можно масштабировать каждый сервис отдельно. Например использовать Docker Swarm, Kubernetes или вручную накинуть серверов при необходимости. Не всем сервисам нашего магазина нужны одинаковые ресурсы. Сервис аналитики требует больше ресурсов для генерации отчётов? Накинем ему мощностей в индивидуальном порядке, пока остальные сервисы работают на своих ресурсах. А в черную пятницу его наоборот можно не трогать. Выделеная команда Можно использовать небольшую команду из 3-5 человек для обслуживания 2-3 микросервисов. Умственная нагрузка на дизайнера, разработчика, тестировщика и менеджера меньше, потому что они несут ответственность только за свои сервисы. Нужно разработать новый сервис с Искуственным интеллектом? Соберём команду с соответсвующим опытом для этого микросервиса. При этом нет надобности показывать им код остальных сервисов. Любые технологии В микросервисах можно использовать разные языки, фреймворки и технологии, которые лучше подходят для решения задачи. Сервисы обмениваются данными с помощью API и событий, а не вызова функций напрямую в коде, поэтому им нет разницы что находится внутри другого сервиса. Каталог товаров, модуль заказов и доставки напишем на Laravel, потому что это быстро. Модуль рекомендаций на Python, потому что это удобно, а реалтайм оставим для NodeJS, потому что это нативно. Быстрая сборка и тестирование Автоматические тесты в каждом отдельном микросервисе проходят в разы быстрее, потому что там мало кода и функций. Сборка сервисов, написаных на компилируемых языках тоже будет выполняться быстро. Получаем экономию времени на разработку и тестирование. Вынесли модуль оплаты в отдельный микросервис? Теперь деплой в продакшен занимает 1 минуту вместо 20 минут, включая сборку и тесты. Итог Всё это звучит круто. Микросервисы приносят большое количество очень важных плюсов. Нам легче думать об отдельных маленьких проектах. Новый разработчик может быстрее изучить микросервис, над которым ему предстоит работать. Изолированный сервис легче развивать, а доставка до конечного пользователя происходит быстрее. Но рано радоваться! Не спеши распиливать свой монолит на части, ведь в следующем посте мы обсудим минусы микросервисов. Подумай что тебя напрягает в твоём монолите сейчас? Или проблемы, которые решают микросервисы высосаны из пальца? Пиши в комментариях! Подпишись и поделись с коллегами: @onecode_blog

Carbon - классика при работе с датой. Мне помогло с базой справится

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

Можно... Но нужно?

Сегодня заявление написал

Я аттачу готовый goods со своей инфой, просто дополняя pivot таблицу

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

переименуй в мастер... я так и поступил :)

Ещё раз это прочти👌