okkkman

1. Все текстовые слои должны быть превращены в кривые:


2. Все обводки, должны быть превращены в векторные объекты:


3. Все векторные линии, должны иметь окончательную связь:



К слову, это особенность любых векторных объектов, и фигма тут не причём.

привет.
Пойдем не по порядку.

Первое – БД
Для чего выносят на отдельный сервер? Делается это, как правило, когда первоначальный сервер не тянет из-за большого количества запросов к БД. У вас сейчас такая ситуация? Да – выносить на отдельный сервер. Нет – оставить сервера в покое.

VPN – тоже оставьте в покое. Если надо выносить БД в отдельный сервер, то тогда иногда имеет смысл закрыть внешку и оставить только VPN.

Docker – докер на проде? У вас точно такой серьезный ресурс, что нужно поднимать в день по несколько VDS и нужен докер? Когда на локале докер еще можно понять – удобство и без мусора. Но на проде? Или есть лишние деньги/ресурсы?
Похоже, что докер тоже стоит оставить только на локале и в покое.

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

минутка занимательной теории:
Как работает деплой? (пример из жизни в очень общих чертах для понимания принципиальной схемы)

Разработчик отправляет пуш в гит. После этого гит кидает оповещение в CI&CD-сервис.
CI&CD-сервис запускает свой процесс, согласно описанному в запушеной ветке протоколу (конфиг сервиса).

Обычно, порядок действий в CI&CD-сервисе такой:
– поднимается контейнер с ОС
– в контейнере разворачивается репо
– подтягиваются все зависимости, настраивается окружение, поднимается база с сидами.
– накатываеются миграции
– прогоняются тесты

Далее запускается скрипт деплоя:
– репо заливается на сервер, например, с помощью rsync или другого инструмента (в этом месте мы используем зашифрованные приватные ключи для доступа к конечному серверу)
– на сервере запускается рутина обновления (например, накатить миграции, обновить конфиги, перезагрузить сервисы)

По окончанию приходит уведомление о статусе. Например в слак.

Все счастливы, разработчик отмечает успех (или устраняет результаты безуспешных тестов).

P.S. Если у вас возникают эти вопросы, то, похоже, вы не DevOps'или раньше.
И это не предмет для обиды или оскорбления, а, наоборот, предмет для размышления над сложностью решений. Сейчас создается впечатление, что вы хотите стрельнуть себе в колено, причем из дробовика.

Вообще это плохая практика — маппить на сущность дто.

Почему: сущность — некоторый бизнес-обьект, он контролирует переходы состояния и инкапсулирует саму логику. Но сущность находится в контексте... бизнес-процесса, который выражен некоторым др видом классов (интеракторы или use cases, если терминами Боба Мартина), например в CQRS таким родом классов являются хэндлеры команд.
Итог: с сущностями напрямую скорее не стоит работать, тем более в сущностях не должно быть сеттеров :) и методов превращения данных из дто в явном виде ака fromDto(), как указал Flying (при всем моем уважении), тк это не бизнес-логика, а некоторая транспортно-приложенческая... Статические конструкторы могут быть, но не для дто, а для определенных данных, отображающих бизнес-возможность.

Кроме того, ваше решение чревато высокой связанностью — ваши сущности конструируются под дто, дто под сущности...

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

3. Путь можно указывать в настройках maker bundle, сразу в командной строке - нет https://symfony.com/doc/current/bundles/SymfonyMak...
2. Разве аннотации привязаны к неймспейсу? Главное ведь их импортировать в нужном классе. Проблемы могут быть разве что со сваггером ( наверняка его тоже можно донастроить)
1. Нужно указать дополнительные пути для считывания миграций в конфигах https://symfony.com/doc/master/bundles/DoctrineMig...

1. https://github.com/symfony/recipes/blob/master/doc...
Но идея плохая, т.к. миграции - это не код.
2. Можно при конфигурировании контейнера и роутов в Kernel.php разбирать структуру папок и подключать все динамически там.
3. Нет. Как создать entity не по стандартному пути?

FYI, моя структура папок сейчас выглядит так:

migrations/
src/
-- Controller/
---- User/
---- ModuleName/
-- Entity/
---- User/
---- ModuleName/
-- User/
--- Dto/
--- Repository/
--- Service/
-- ModuleName/
--- Dto/
--- Repository/
--- Service/

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

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

Да, в реальной жизни часто выглядит так: пришел макет от дезигнера для мобильных, а ты уже изобретаешь что сделать с этим всем великолепием, чтоб можно было на десктопах видеть красоту

На деле не плохая практика, просто надо перевернуть для тебя привычный взгляд ;)

Если используете Докер и прямо хотите докеризировать с мастабированием, то используйте сеть докера для связи между контейнерами для начала.
У вас должно быть 1 контейнер с nginx наружу (80 порт и/или 443), 1 контейнер для сборки приложения VueJS, 1 контейнер для работы с PHP-проектом и дальше что там у вас, по контейнеру для СУБД (1 Redis, 1 RabbitMQ, 1 MySQL). Каждому контейнеру дайте нормальное уникальное имя, чтобы можно было их подключать друг к другу по dns-имени. Наружу порт только для nginx давайте, он будет за все отвечать.
1. Контейнер с nginx отдает статику, собранную из приложения VueJS. Собственно все как обычно - собрали dist, из него и отдаете. В идеале собирать в отдельном контейнере c NodeJS, а полученные данные из dist копировать в какой-нибудь volume наверное и подключить его к контейнеру с Nginx. Это можно делать на уровне файлов docker-compose и автоматизировать при сборке проекта. Этот же volume можно подключить и к контейнеру с backend-api, тогда оно сможет работать с файлами, которые загрузили.
2. Из первого контейнера с nginx по upstream отдавать backend-api, который будет обращаться к еще одному контейнеру, где крутится PHP и собственно ваш symphony проект. Наружу этот контейнер не пускайте, подключайте к первому контейнеру через имя. Таким образом вы сможете запустить несколько контейнеров с api, указав все их dns-имена в разделе нужного upstream. Уже получаете горизонтальную масштабируемость, эти контейнеры потом можно запускать вообще на разных серверах, соединив их, например при помощи Docker Swarm или в Kubernetes. Опять же все можно оформить на уровне файлов конфигурации Docker Compose, там не сложно, достаточно почитать документацию.
3. Все контейнеры с СУБД запускайте тоже в отдельных контейнерах, где нужно - создавайте volume для хранения БД. Их тоже наружу не пускайте, биндите на уровне Docker с контейнером (ами) с backend-api. Вообще если предполагается серьезная нагрузка, то СУБД вообще рекомендуют запускать не в контейнерах, но тогда чуть сложнее автоматизировать привязку и масштабирование будет. Для начала можно и в контейнерах, когда она придет, эта нагрузка то... Тем более контенеры с СУБД тоже можно в нескольких экземплярах запускать, между ними репликацию сделать или вообще шардинг. Все это можно наверное во всех описанных БД сделать, но с шардингом помучаться конечно придется. Репликация проще всего. А уже к ним подключаться из backend-api по dns-именам, как настроите.

Как то так.

Амо по умолчанию выдают список сделок сортированных по дате изменения (от старых до новых), а не последних. соответственно изменяя сделку она автоматически попадет в конец списка, изменить это пока нельзя.

использовать aggs по term + top_hits

Что-то типа

MYSQL_PWD=custom_password mysqladmin -u custom_user ping -h localhost

ИМХО, правильнее использовать https://docs.docker.com/engine/reference/builder/#... например
https://github.community/t5/GitHub-Actions/Mysql-s...

Вот отличный вариант, пользуюсь везде им
t1m0n.name/air-datepicker/docs/index-ru.html

Может подойдет https://vcalendar.io/ вроде опции есть которые вам нужны

Никакого use, это просто компонент.
Т.e. или

Vue.component('date-range-picker', window['vue2-daterange-picker'].default);

или

{
  components: {
    DateRangePicker:  window['vue2-daterange-picker'].default
  }, 
  // ...
}