Вот это хороший поинт. Мне нравилась биология только потому, что ее вел мужик с местной телепрограммы Дача с поставленным голосом и интересными примерами. Харизма учителя очень сильно влияет на процесс обучения, особенно на детей. Вот только кто сейчас за три копейки с такими навыками пойдет преподавать?
Табличка с фичами и столбиками по продукту и его конкурентам, которая наглядно показывает преимущества этого продукта :) Чтобы я такой посмотрел, ого, вот этого нет в симфони (или оно плохое), а в yii3 оно работает как надо. Ну и туда же бенчмарки.
Конкуренция это в любом случае хорошо. Но я так долго ждал yii3, что сначала перешел на лару, а теперь на симфони. Было бы круто увидеть баттл карту против этих ребят, чтобы у таких как я появилась мотивация попробовать yii3
А можете привести примеры кейсов, когда файлы нужно именно в базе хранить? На больших проектах и так почти все проблемы с производительностью связаны с работой базы, а тут еще файлы в нее писать. Потом еще мучаться с бекапированием и обновлением. Когда есть куча других вариантов, тот же s3.
В моей голове хранение файлов в базе - это моветон.
Не понял, а в чем тогда вообще смысл "блокировки", если можно использовать любой канал, типа тех же сообщений в ВК и почти в реалтайме передавать любые данные?
Получается, вы практически все важное вынесли в лару, а от битрикса осталась шкурка и пара справочников. А точно ли он тут нужен теперь? Кажется вам нужно сделать последний шаг и сделать просто UI похожий на битриксовый, чтобы контенщики не страдали.
Потому что битрикс - это еще куча непонятного кода с кишками наружу (без единой точки входа), зачем оно вам в кодовой базе? :)
Пока в Битриксе все кишки торчат наружу и доступны из веба - приложение нереально сделать безопасным. Когда уже все это переедет выше document_root как в любом нормальном веб-приложении?
Молодцы, что справились, конечно. Но мне сама идея хранения файлов в базе кажется очень странной. Подключить s3 сразу сейчас к любому фреймворку очень просто и интересно, почему сразу так не сделали.
~10% места + повышение производительности: странно, что этого еще нет из коробки. Цифра пугающая, и вроде как минусов отдавать ответственность за порядок столбцов на диске на откуп СУБД нет. Ждем в 17 версии :)
Мне кажется, проще поставить какой-нибудь zabbix и настроить алерты в telegram, там это очень просто делается. И он будет мониторить не только доступность, а вообще все параметры сервера, из коробки есть куча шаблонов для почти любого сервиса + можно что угодно настроить самому.
А что поменялось с 2010? Появилась единая точка входа, все кишки спрятали выше document root? Стали придерживаться PSR? Внедрили композер, автотесты, линтер? Перестали велосипедить? Нет :)
К сожалению, это следствие не популярности, а полного игнорирования разработчиками техдлога и всех возможных стандартов сообщества. Кодовая база и архитектура битрикса (кишки наружу, код на массивах с кучей ошибок, без тестов, без анализатора) находится на уровне 2010 года, со всеми вытекающими.
Кто-то может сказать, что они так заботились о юзерах, типа обратная совместимость и обновления, которые можно накатить с любой версии. Ну во-первых, это не так, все равно куча проблем и нужно вручную фиксить много всего, юзерспейс переделывался. Во-вторых - это медвежья услуга, теперь имеем, что имеем.
Еще они известные велосипедисты, со всеми вытекающими. Тут у них в комментах спрашивал про композер - сказали "небезопасно использовать эти ваши доктрины". Пилят какие-то свои неюзабельные поделки на массивах.
Битрикс в таком виде нужно было давно закопать. Если они сейчас в недрах не пилят какой-нибудь "Битрикс 2" как цмс поверх симфони, то скоро их время пройдет.
Насчет того, почему разработчик не может проверить сам - по той же причине, почему не может написать код без багов :)
Особенно сложно хорошо написать тесты на свой же код, потому что ты заранее знаешь как он работает и думаешь только о тех моментах, которые запрограммировал и не думаешь о сценариях, которые забыл продумать.
В итоге картина получается такая: разработчик написал тесты, они работают, все зелененькое, все хорошо. Даже покрытие может быть очень высоким, код приложения в тесте вызывается. Но в тесте может быть допущена ошибка, или пропущен какой-нибудь assert, из-за чего в результате тест не проверяет какую-то важную деталь или сценарий.
Вы не так поняли - мутационные тесты никто не пишет, это запуск тех же самых ваших тестов просто на измененном коде приложения.
Код приложения меняется мутационным фреймворком и на этом коде запускаются ваши тесты. Если тесты проходят, значит тесты не покрывают измененную строку (это может быть условие, вызов метода и тп, вот список мутаций). И так тысячи раз на разные изменения в разных местах.
По факту это единственный способ формально убедиться, что тесты действительно что-то проверяют, не просто работают.
Я позволю себе сослаться на хороший комментарий от @Aquahawkвыше.
Как я и писал в статье, мутационное тестирование - это тяжелая артиллерия, и далеко не всем она нужна.
Не совсем понял, почему вы пишете "генерируем тесты", тесты пишут живые люди пока что (по крайней мере я пока не видел штуку, которая бы по бизнес-требованиям могла создать тест для кода). В этом и есть проблема, что в них тоже могут быть ошибки, они могут не покрывать что-то, или проверять неправильно. Глазами такое почти нереально отловить.
Да, отчет по выжившим мутантам придется смотреть вручную, и думать, делать с ними что-то или не делать.
Ну и не соглашусь насчет нереалистичности покрытия в 70%+, для этого чаще всего достаточно писать по тесту на каждую ручку API, чтобы проверяла основной сценарий.
У меня кисть начала болеть от одного взгляда на эту мышку. Представляю как целый день почти на весу держу руку.
Вот это хороший поинт. Мне нравилась биология только потому, что ее вел мужик с местной телепрограммы Дача с поставленным голосом и интересными примерами. Харизма учителя очень сильно влияет на процесс обучения, особенно на детей. Вот только кто сейчас за три копейки с такими навыками пойдет преподавать?
Табличка с фичами и столбиками по продукту и его конкурентам, которая наглядно показывает преимущества этого продукта :)
Чтобы я такой посмотрел, ого, вот этого нет в симфони (или оно плохое), а в yii3 оно работает как надо. Ну и туда же бенчмарки.
Конкуренция это в любом случае хорошо. Но я так долго ждал yii3, что сначала перешел на лару, а теперь на симфони. Было бы круто увидеть баттл карту против этих ребят, чтобы у таких как я появилась мотивация попробовать yii3
А можете привести примеры кейсов, когда файлы нужно именно в базе хранить? На больших проектах и так почти все проблемы с производительностью связаны с работой базы, а тут еще файлы в нее писать. Потом еще мучаться с бекапированием и обновлением. Когда есть куча других вариантов, тот же 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, чтобы проверяла основной сценарий.