К сожалению слишком мало информации. Отдельно стоит исследовать почему крашится дветулз, но в целом это не проблема, если не крашится при разработке на меньше количестве ячеек. Потом првоерку не большем количестве проводить уже в (авто)тестах перед релизом в продакшн.
Отдельно отмечу что согласен с Adamos про упрощенный вывод, но снова таки видимо у вас задача слишком там специфичная и большая, сложно конкретно ответить.
accountnujen, грубый ответ да. Но по факту обратите внимание на комплектующие. Я советую поизучать форумы/сообщества оверклокеров на эту тему и брать конкретно те железки которые проверены на стабильность, температуры и тп в нужном режиме. Ну и вряд ли для 7600X будет смысл брать выше 6000, лучше 6000 с хорошими таймингами, температурой, надежностью, чем 6600 ради частоты.
Александр Панков, да, обычно внутри сетки. Есть ещё куча mysql as service. Даже у того же DigitalOcean.
Удобно когда хочется уйти от админских заморочек и настроек всяких оптимальных.
В целом mysql нередко первым становится бутылочным горлышком(вместе с пользовтельскими файлами которые выводят на отдельное хранилище) в производительности, поэтому и первым попадает под масштабирование, тем или иным способом.
А с другой стороны вот есть такие истории успеха https://twitter.com/levelsio/status/1445331843176271874
Александр Панков,
"Да и база (mysql/postgres) в докере все говорят - не надо, спрашиваю почему.. и не получаю внятного ответа, ну не надо так не надо значит"
здесь сложно что-то комментировать, может там какой-то конкретный кейс. Базу вообще нередко выносят в совершенно отдельный сервис, вне того места где код запускается, чтобы не мешали другу другу. Так что чем там сам докер мешает. Может только если неверной настройкой
Александр Панков, докер не про нативно/виртуально. Докер в линуксе вполне себе нативно работает. Прямая и общая производительность практически такая же как и без докера. Там есть некоторые нюансы, можете почитать здесь. Но всё это мелочи по сравнению с удобством более быстрой и предсказуемой разработки и деплоя. У вас изолированные программы работают и не мешают друг другу. Нет проблемы со сменой версий(php например), не будут конфликтов и лишних библиотек в системе и тп. а так же на локалке и на сервере вам гораздо легче организовать одинаковое окружения для приложения, что критично важно во время поимки тех же багов.
Что касается rsync - всё таки странно, почти как по старинке по ftp. Может я ошибаюсь, но лучше уж если хочется билдить на локалке, то пусть в репо будет хранится сбилженное приложение.
Насчёт пункта про sudo:
Для админа, который ручками будет хотет заходить на сервер, оставляем пароль на sudo полностью.
А для сервисных пользователей, под которыми работают скрипты мы установим в /etc/sudoers для них NOPASSWORD не для всех команд, а только для избранных, которые нужны им в работе(ну и для которых нужен sudo)
Всё равно не очень хорошо обходить все. Одно дело события на кнопки развесить, но зачем по всем с контентом обходить? Я предложил чуть более эффективный подход, обход только активных.
Немного не ясно что за скрипт ив целом общий вокрфлоу. Если вам нужно разграничить права доступа к базе данных, то в документации по mysql всё написано и про пользователей и про конкретные права каждому пользователю.
АлексейПавел Орловский боже ребят простите. Первый вариант я 100% был уверен что использовал, но оказалось я делал в styled components. Я в целом редко style дергаю, поэтому немного запутался. Ну и да через style в принципе нельзя это сделать по спецификации.
Прошу прощения. Исправлю ответ на styled components.
TiTreivan, может автор исходил из "тру безопасного" подхода. Ему в коде нужно было проверять маркер Serializable, а EntityRef мог бы поменяться и потерять внутри себя его. Там в целом к сожалению историю кода не получилось посмотреть.
Мое предположение что изначально было просто implements EntityRef, а потом для лучшей читабельности и прозрачности чего за класс отдельно добавили Serializable. А из EntityRef не убрали потому что не мешает(может забыли), а может оставили чтобы не появились новые баги, вдруг где-то что-то его цепляет. Хотя там легко по коду найти что и где. Впрочем, может есть модули и прочие зависимости.
Слава, как вы закидывали файлы на дев сервер? проверьте что там НЕТ папка hot в public/assets/.
Её создаёт дев сервер, ну и она может влиять на то что у вас происходит
godsplane, ну, в любом случае, если на вас повесили "интеграцию", то никуда не деться. Не всегда же чистым css/js обойдешься, либо это будет слишком костыльно.
Поэтому придётся ставить и настраивать.
godsplane, а. Понял. Те интеграцией шаблона в тему fenom не вы занимались.
Ну тогда это не ваша зона ответственности? Эту проблему должен решить разраьботчик который поддерживает сайт на modx.
Ну а если на вас это перекинули, тогда советую самом поднять локальную копию и верстать сразу там в теме modx.
Думаю особых проблем не будет настроить tailwind чтобы он находил себя в нужных шаблонах. Устновите тот же vite, или ваше сборщик конфиг поменяйте, чтобы он кидал готовые js/css в нужные дирректории темы, и всё.
Особых проблем быть не должно.
А я понял, выражаетесь вы конечно не сразу понятно.
А в чем проблема деплоит и щаблоны. Это же нормально, тем более даже при "классическом" подходе нередко и сама верстка менялась, как и классы, так и вложенность/структура?
Слишком много обощенных данных, что значит лагало и тп.
Может соберёте на codepen своё "плохое" решение. Мы посмотрим, может что придумаем)
А 60 fps это иногда путь, а не цель)
Nayro TV, После получения данных нужно вначале его уничтожить( slick('unslick')) + возможно удаление слайдов, после добавляете html, а затем заново создать как вы создавали изначально.
Отдельно отмечу что согласен с Adamos про упрощенный вывод, но снова таки видимо у вас задача слишком там специфичная и большая, сложно конкретно ответить.