Алексей
на сервера или ексендж?
Alexey Mishurovskiy
на сервера или ексендж?
не понял вопроса )
Alexey Mishurovskiy
Парни, есть сами или знакомый бог кубернетуса, есть вопрос с производительностью диска который 2 недели не можем решить
Alexey
Добрый день, SonataAdminBundle 4. Нужно вывести даты, но падаю с Object of class DateTime could not be converted to string Может кто подскажет, как даты отобразить? Шаблоны стандартные, в админе вот так: protected function configureListFields(ListMapper $listMapper): void { $listMapper->add('date_from', DateType::class) ->add('date_to', DateType::class); }
std::mechanicus
Нужен вызов метода toString или как его там
Konstantin
потрясающий ответ
The Ant
Парни, есть сами или знакомый бог кубернетуса, есть вопрос с производительностью диска который 2 недели не можем решить
Производительность диска можно решить 2 путями. 1) взять железку с нвме, желательно поновее (3-6гб\с чтение) 2) сделать железку виртуальной в оперативной памяти. Да да, такое тоже практикуют. Правда маунтить разделы для данных на физических носителях.
The Ant
ну, теперь ты знаешь еще пару способов ускорить своё приложение :D
Alexey
Народ, до этого SonataAdmin в руках не держал, только разбираюсь сижу. А подскажите, нет ли готового решения для логирования действий пользователя? Кто какую сущность менял, когда и как, вот это вот всё. Вроде достаточно базовая штука, просится из коробки.
Alexey
Что-то беглое гугление ничего внятного мне не предложило, но может я не так спрашиваю у ясеня у гугла.
Konstantin
вообще, будто бы это не задача админки, а задача какого-то аудит-бандла
Konstantin
который вешается триггерами (или похожим программным механизмом) на аудируемые таблицы и пишет действия в таблицу аудита
Konstantin
гуглится чот, вот, например, https://github.com/DamienHarper/auditor-bundle
Konstantin
https://github.com/kricha/DoctrineAuditBundle
Konstantin
вот итд, итп, поизучайте. сонатой это делать точно не сильно правильно
Dmitriy
Всем привет! Возник вопрос стоит ли коммитить папку vendor в репу? По-умолчанию она в игноре, но есть минус - при сборке докер-образа, тратится много времени на загрузку библиотек, особенно когда нужно собрать много проектов. Поделитесь опытом, как вы в такой ситуации поступаете?
Сергей
Кешируй папку при сборке, а не комить. Или кеш композера) кто как
Юра
Мы комитим на одном проетке
Юра
проблем нет
Юра
Кроме одного случая когда не стояло какое-то расширение и композер соответственно не проверил и все упало
Юра
папка vendor просто сабмолулем сделана
Юра
Ну а вообще в твоем случае мне кажется решается маунтом общей директории для кеша композера
Юра
и у всех будет кеш
Dmitriy
Ну а вообще в твоем случае мне кажется решается маунтом общей директории для кеша композера
а как маунтить папку, если проект собирается из репы на разных стендах? сделать общую папку на все стенды и качать библиотеки туда?
Konstantin
вендоры ставить надо бы в билд-тайм, а не ран-тайм. иначе могут быть артефакты
Konstantin
то есть в момент того, как вы готовите артефакт - деб-пакет, тарболл, докер-имадж или что там у вас
Konstantin
после того как артефакт "запечатан", вы гарантируете что он идентичен до байта на всех стендах и отличается только конфигурацией (конфиг/энвы). это очень полезный принцип, сильно экономящий нервы эксплуатации
Konstantin
т.е. качать во время сборки? да, докер имедж
вы в момент подготовки образа внутри него делаете композер инсталл и дальше уже готовую папку вендоров распространяете со своим приложением вместе
Konstantin
чтобы, условно, через год достать этот докер-имадж, раскатить его и он работал. а если вы при установке будете делать композер инсталл, то далеко не факт, что через год библиотеки будут живы
Konstantin
horse вон недавно такой эффект поимел
Dmitriy
вы в момент подготовки образа внутри него делаете композер инсталл и дальше уже готовую папку вендоров распространяете со своим приложением вместе
сейчас так и делаю, собираю образ со всеми зависимостями. смущает только то что время сборки увеличивается из-за скачивания пакетов
Konstantin
вы можете кешировать на хост-машине кеш композера
Konstantin
достаточно просто прокинуть в контейнер папку в /root/.cache/composer или как там ее. и шарить этот кеш со всеми билд-контейнерами
Konstantin
довольно быстро эта общая папка наполнится и инсталл будет приемлемо быстрым
Юра
Если хочешь раскатать образ через год и чтобы работало то никаких npm install, composer install и т.д
Юра
Никакой гарантии что оно заинсталится нет
Юра
Репы удаляются, домены меняются и т.д.
Юра
И чем больше всяких абстракций поверх аля симфони флекс и т.д. тем больше вероятность что все сломается
Юра
Какой-нибудь tls 1.2 задепрекейтят и твой образ ничего вообще не скачает
Юра
Были и такие случаи
Юра
Либо серты протухнут
Konstantin
хорошо еще если просто протухнут зависимости
Konstantin
а не туда подсунут малвари, которая радостно тебе в прод попадет
Пилот
ну нет же, статик - не тестируется, не мокается, не подменяется реализация. если можно избегать статик-методов - надо это обязательно делать
Кстати так и не пришел к ответу, зачем вообще юзать Статик методы) есть уверенные кейсы на эту тему?)
Пилот
Конструктор
Именованный конструктор?
Пилот
С прайват конструктором реальным типа?
Пилот
А ля createFromRequest...createFromArray
Nikolay
Именованный конструктор?
Да, пример ниже не совсем удачный
Пилот
Был бы не против увидеть лучше, для понимания)
Пилот
И мб ещё какие то кейсы
Nikolay
Пилот
User::signUpByEmail(...) User::signUpByNetwork(...)
Доброго дня, спасибо!) Подписался кстати сегодня на вас кое где тоже, прикольно что здесь тоже есть)
Пилот
Кстати а регистрация юзера разве не ответственность сервиса апликейшен или домен слоя?
Пилот
У меня она в usecase вынесена, и класс юзера ничего не знает о Реге. Есть разные классы юзера типа Customer, NotActivatedCustomer
Пилот
У каждого разнёс свою ответственность, то есть НотАктивейтед знает активнейшен токен, о котором не знает Кастомер
Dmitry
Кстати а регистрация юзера разве не ответственность сервиса апликейшен или домен слоя?
Прикладной сервис (юзкейс) прокидывает данные в метод доменной сущности
Пилот
SignUpCustomerHandler
Пилот
ActivateCustomerHandler
Пилот
но данный случай тоже ок?
Пилот
правда апдейт инхеританса там корявый в ActivateHandler, потом пофикшу мб) это из за того что не особо получилось с doctrine inheritance mapping совладать
Пилот
вот про этот мапинг имею ввиду, но что то не особо удобно вышло в итоге
Пилот
Никогда не делай наследование сущностей. Иногда такая дичь получается
доктриновскую типа или в целом? ну тут скорее эксперимент был, это уже понял, что не супер сладко в итоге ( хз как альтернативно замапить было, чтоб клиентский код выглядел, как выше (ну не учитывая этот танец с бубнами em->sync && em->updateInheritanceType который по сути raw sql у меня под капотом который апдейтит колонку дискриминанта)
Пилот
так то я вообще файналы юзать стараюсь. правда на энтити доктрины файнал низзя ставить.
Пилот
а делать чисто доменную энтити параллельно с доктриновской в контексте моего проекта дикий оверхед (
Nikolay
а делать чисто доменную энтити параллельно с доктриновской в контексте моего проекта дикий оверхед (
У тебя должна быть одна бизнесовая сущность. Что такое доктриновская?
Пилот
ну типа класс на который мапится доктриной из персистента.
Пилот
но я скорее чуть перепутал с энтити User которая наследует UserInterface симфонийский а не доктриновский)
Пилот
мне припекало что в домен протек интерфейс с симфы но быстро смирился
Пилот
за доктрину тоже - типа, из-за doctrine inheritance mapping пришлось городить наследование сущности кастомера как в примере выше. но я не уверен что точно из за этого, не помню уже) давно имплементил
Пилот
Выглядит как лютая дичь
шо именно? хендлер или сам мапинг через doctrine inheritance?