А можете привести примеры кейсов, когда файлы нужно именно в базе хранить? На больших проектах и так почти все проблемы с производительностью связаны с работой базы, а тут еще файлы в нее писать. Потом еще мучаться с бекапированием и обновлением. Когда есть куча других вариантов, тот же s3.
В моей голове хранение файлов в базе - это моветон.
Не понял, а в чем тогда вообще смысл "блокировки", если можно использовать любой канал, типа тех же сообщений в ВК и почти в реалтайме передавать любые данные?
Получается, вы практически все важное вынесли в лару, а от битрикса осталась шкурка и пара справочников. А точно ли он тут нужен теперь? Кажется вам нужно сделать последний шаг и сделать просто UI похожий на битриксовый, чтобы контенщики не страдали.
Потому что битрикс - это еще куча непонятного кода с кишками наружу (без единой точки входа), зачем оно вам в кодовой базе? :)
Пока в Битриксе все кишки торчат наружу и доступны из веба - приложение нереально сделать безопасным. Когда уже все это переедет выше document_root как в любом нормальном веб-приложении?
Молодцы, что справились, конечно. Но мне сама идея хранения файлов в базе кажется очень странной. Подключить s3 сразу сейчас к любому фреймворку очень просто и интересно, почему сразу так не сделали.
~10% места + повышение производительности: странно, что этого еще нет из коробки. Цифра пугающая, и вроде как минусов отдавать ответственность за порядок столбцов на диске на откуп СУБД нет. Ждем в 17 версии :)
Мне кажется, проще поставить какой-нибудь zabbix и настроить алерты в telegram, там это очень просто делается. И он будет мониторить не только доступность, а вообще все параметры сервера, из коробки есть куча шаблонов для почти любого сервиса + можно что угодно настроить самому.
А что поменялось с 2010? Появилась единая точка входа, все кишки спрятали выше document root? Стали придерживаться PSR? Внедрили композер, автотесты, линтер? Перестали велосипедить? Нет :)
К сожалению, это следствие не популярности, а полного игнорирования разработчиками техдлога и всех возможных стандартов сообщества. Кодовая база и архитектура битрикса (кишки наружу, код на массивах с кучей ошибок, без тестов, без анализатора) находится на уровне 2010 года, со всеми вытекающими.
Кто-то может сказать, что они так заботились о юзерах, типа обратная совместимость и обновления, которые можно накатить с любой версии. Ну во-первых, это не так, все равно куча проблем и нужно вручную фиксить много всего, юзерспейс переделывался. Во-вторых - это медвежья услуга, теперь имеем, что имеем.
Еще они известные велосипедисты, со всеми вытекающими. Тут у них в комментах спрашивал про композер - сказали "небезопасно использовать эти ваши доктрины". Пилят какие-то свои неюзабельные поделки на массивах.
Битрикс в таком виде нужно было давно закопать. Если они сейчас в недрах не пилят какой-нибудь "Битрикс 2" как цмс поверх симфони, то скоро их время пройдет.
Насчет того, почему разработчик не может проверить сам - по той же причине, почему не может написать код без багов :)
Особенно сложно хорошо написать тесты на свой же код, потому что ты заранее знаешь как он работает и думаешь только о тех моментах, которые запрограммировал и не думаешь о сценариях, которые забыл продумать.
В итоге картина получается такая: разработчик написал тесты, они работают, все зелененькое, все хорошо. Даже покрытие может быть очень высоким, код приложения в тесте вызывается. Но в тесте может быть допущена ошибка, или пропущен какой-нибудь assert, из-за чего в результате тест не проверяет какую-то важную деталь или сценарий.
Вы не так поняли - мутационные тесты никто не пишет, это запуск тех же самых ваших тестов просто на измененном коде приложения.
Код приложения меняется мутационным фреймворком и на этом коде запускаются ваши тесты. Если тесты проходят, значит тесты не покрывают измененную строку (это может быть условие, вызов метода и тп, вот список мутаций). И так тысячи раз на разные изменения в разных местах.
По факту это единственный способ формально убедиться, что тесты действительно что-то проверяют, не просто работают.
Я позволю себе сослаться на хороший комментарий от @Aquahawkвыше.
Как я и писал в статье, мутационное тестирование - это тяжелая артиллерия, и далеко не всем она нужна.
Не совсем понял, почему вы пишете "генерируем тесты", тесты пишут живые люди пока что (по крайней мере я пока не видел штуку, которая бы по бизнес-требованиям могла создать тест для кода). В этом и есть проблема, что в них тоже могут быть ошибки, они могут не покрывать что-то, или проверять неправильно. Глазами такое почти нереально отловить.
Да, отчет по выжившим мутантам придется смотреть вручную, и думать, делать с ними что-то или не делать.
Ну и не соглашусь насчет нереалистичности покрытия в 70%+, для этого чаще всего достаточно писать по тесту на каждую ручку API, чтобы проверяла основной сценарий.
Я вам могу предложить выбрать самый важный модуль вашей системе и через --filter прогнать по нему мутационные тесты. Если после изучения отчета вы найдете интересные ошибки в тестах или в коде, тогда точно есть смысл.
Не совсем, внедрение мутационных тестов не требует написания еще тестов. Мутационный фреймворк запускает ваши существующие тесты и ищет в них недостатки, проверяя ими измененный код приложения. Тем самым вы просто улучшаете свои тесты :)
Тесты пишут те же люди, что и код - тесты у нас идут как часть решения задачи. На моей основной работе разработка заказная, и поначалу мы пытались выбить время на покрытие тестами у бизнеса - это почти невозможно :)
Поэтому сейчас тесты пишутся как часть решения задачи. Тесты стараемся писать на каждый метод API. Обычные тесты пишем очень давно, но серьезный подход сформировался года 3 назад. И когда у команды есть опыт - тесты не только не замедляют разработку, а значительно ее ускоряют за счет минимизации багов и регрессии. А так тесты набросать занимает не более 10% времени от задачи, это окупается даже на мелких проектах.
Про мутационное тестирование давно слышал, игрался на локалке, но только недавно внедрили его на бой. И эта статья родилась как раз от того, что меня они вдохновили, что на самом деле в первом приближении их внедрение не такое уж и дорогое.
CMS Bitrix и информационная безопасность в одном предложении :) Когда из CMS все кишки наружу торчат без единой точки входа и роутинга - в ней каждый месяц будут находить уязвимости, что в целом и происходит.
А можете привести примеры кейсов, когда файлы нужно именно в базе хранить? На больших проектах и так почти все проблемы с производительностью связаны с работой базы, а тут еще файлы в нее писать. Потом еще мучаться с бекапированием и обновлением. Когда есть куча других вариантов, тот же s3.
В моей голове хранение файлов в базе - это моветон.
Не понял, а в чем тогда вообще смысл "блокировки", если можно использовать любой канал, типа тех же сообщений в ВК и почти в реалтайме передавать любые данные?
Хотя понял, просто приучаемся к белым спискам.
Получается, вы практически все важное вынесли в лару, а от битрикса осталась шкурка и пара справочников. А точно ли он тут нужен теперь? Кажется вам нужно сделать последний шаг и сделать просто UI похожий на битриксовый, чтобы контенщики не страдали.
Потому что битрикс - это еще куча непонятного кода с кишками наружу (без единой точки входа), зачем оно вам в кодовой базе? :)
"То есть после 984 946 606 идёт 984 946 610, а затем 984 946 621"
Последняя цифра для контроля целостности видимо
Пока в Битриксе все кишки торчат наружу и доступны из веба - приложение нереально сделать безопасным. Когда уже все это переедет выше document_root как в любом нормальном веб-приложении?
Точно такая же история, почувствовал снижение "интереса" ко мне, если сравнивать с 2-3 года назад :)
Молодцы, что справились, конечно. Но мне сама идея хранения файлов в базе кажется очень странной. Подключить s3 сразу сейчас к любому фреймворку очень просто и интересно, почему сразу так не сделали.
Вроде даже в правильную сторону развивается: https://opensearch.org/blog/replacing-default-admin-credentials/
Плюс OpenSearch не блокируют российские IP при попытке скачать образ.
~10% места + повышение производительности: странно, что этого еще нет из коробки. Цифра пугающая, и вроде как минусов отдавать ответственность за порядок столбцов на диске на откуп СУБД нет. Ждем в 17 версии :)
Мне кажется, проще поставить какой-нибудь zabbix и настроить алерты в telegram, там это очень просто делается.
И он будет мониторить не только доступность, а вообще все параметры сервера, из коробки есть куча шаблонов для почти любого сервиса + можно что угодно настроить самому.
Что не новость про взлом, то Bitrix - https://habr.com/ru/search/?q=Bitrix&target_type=posts&order=date
Не буду повторять свои комментарии
Теперь уже к моему сожалению, это не так.
А что поменялось с 2010? Появилась единая точка входа, все кишки спрятали выше document root? Стали придерживаться PSR? Внедрили композер, автотесты, линтер? Перестали велосипедить? Нет :)
К сожалению, это следствие не популярности, а полного игнорирования разработчиками техдлога и всех возможных стандартов сообщества. Кодовая база и архитектура битрикса (кишки наружу, код на массивах с кучей ошибок, без тестов, без анализатора) находится на уровне 2010 года, со всеми вытекающими.
Кто-то может сказать, что они так заботились о юзерах, типа обратная совместимость и обновления, которые можно накатить с любой версии. Ну во-первых, это не так, все равно куча проблем и нужно вручную фиксить много всего, юзерспейс переделывался. Во-вторых - это медвежья услуга, теперь имеем, что имеем.
Еще они известные велосипедисты, со всеми вытекающими. Тут у них в комментах спрашивал про композер - сказали "небезопасно использовать эти ваши доктрины". Пилят какие-то свои неюзабельные поделки на массивах.
Битрикс в таком виде нужно было давно закопать. Если они сейчас в недрах не пилят какой-нибудь "Битрикс 2" как цмс поверх симфони, то скоро их время пройдет.
Насчет того, почему разработчик не может проверить сам - по той же причине, почему не может написать код без багов :)
Особенно сложно хорошо написать тесты на свой же код, потому что ты заранее знаешь как он работает и думаешь только о тех моментах, которые запрограммировал и не думаешь о сценариях, которые забыл продумать.
В итоге картина получается такая: разработчик написал тесты, они работают, все зелененькое, все хорошо. Даже покрытие может быть очень высоким, код приложения в тесте вызывается. Но в тесте может быть допущена ошибка, или пропущен какой-нибудь assert, из-за чего в результате тест не проверяет какую-то важную деталь или сценарий.
Вы не так поняли - мутационные тесты никто не пишет, это запуск тех же самых ваших тестов просто на измененном коде приложения.
Код приложения меняется мутационным фреймворком и на этом коде запускаются ваши тесты. Если тесты проходят, значит тесты не покрывают измененную строку (это может быть условие, вызов метода и тп, вот список мутаций). И так тысячи раз на разные изменения в разных местах.
По факту это единственный способ формально убедиться, что тесты действительно что-то проверяют, не просто работают.
Я позволю себе сослаться на хороший комментарий от @Aquahawk выше.
Как я и писал в статье, мутационное тестирование - это тяжелая артиллерия, и далеко не всем она нужна.
Не совсем понял, почему вы пишете "генерируем тесты", тесты пишут живые люди пока что (по крайней мере я пока не видел штуку, которая бы по бизнес-требованиям могла создать тест для кода). В этом и есть проблема, что в них тоже могут быть ошибки, они могут не покрывать что-то, или проверять неправильно. Глазами такое почти нереально отловить.
Да, отчет по выжившим мутантам придется смотреть вручную, и думать, делать с ними что-то или не делать.
Ну и не соглашусь насчет нереалистичности покрытия в 70%+, для этого чаще всего достаточно писать по тесту на каждую ручку API, чтобы проверяла основной сценарий.
Я вам могу предложить выбрать самый важный модуль вашей системе и через --filter прогнать по нему мутационные тесты. Если после изучения отчета вы найдете интересные ошибки в тестах или в коде, тогда точно есть смысл.
Не совсем, внедрение мутационных тестов не требует написания еще тестов. Мутационный фреймворк запускает ваши существующие тесты и ищет в них недостатки, проверяя ими измененный код приложения. Тем самым вы просто улучшаете свои тесты :)
Тесты пишут те же люди, что и код - тесты у нас идут как часть решения задачи. На моей основной работе разработка заказная, и поначалу мы пытались выбить время на покрытие тестами у бизнеса - это почти невозможно :)
Поэтому сейчас тесты пишутся как часть решения задачи. Тесты стараемся писать на каждый метод API. Обычные тесты пишем очень давно, но серьезный подход сформировался года 3 назад. И когда у команды есть опыт - тесты не только не замедляют разработку, а значительно ее ускоряют за счет минимизации багов и регрессии. А так тесты набросать занимает не более 10% времени от задачи, это окупается даже на мелких проектах.
Про мутационное тестирование давно слышал, игрался на локалке, но только недавно внедрили его на бой. И эта статья родилась как раз от того, что меня они вдохновили, что на самом деле в первом приближении их внедрение не такое уж и дорогое.
CMS Bitrix и информационная безопасность в одном предложении :)
Когда из CMS все кишки наружу торчат без единой точки входа и роутинга - в ней каждый месяц будут находить уязвимости, что в целом и происходит.