Я давно меряю аварии по количеству косяков которые должны были случится одновременно, чтоб авария состоялась. Обычно это от 3 до 5. Такого простого и понятного, типа "перепутал кнопку и ребутнул банк" найти нынче сложно.
Имеет. C#, go это жёсткий вендор лок. Ими корпорация крутит как хочет. Причём не просто может, а делает. Посмотрите на яблоко - там все тоже, но быстрее.
Зацепило про 1 млн строк, сразу хочется спросить: А если он принесёт просто на порядок больше записей? Кажется, что база стоит за приложением и бы проверял на нт только реальные сценарии на реальной системе и железе
Кажется дзен TDD так и не понят, что тесты пишутся до кода и как это будет проверяться проектируется одновременно с системой.
Вот честно, проще тесту скормить кусок непонятных данных отброшенных в лог, чем страдать ловя их в потоке.
И это хорошо когда данные просто поменялись, а когда начинается подмес чего-то нового? А потом ещё и ещё? Вам же нужно стабильно обрабатывать и первое и второе и третье. Без тестов тут такой замес можно устроить...
И ещё раз - пишите тесты до кода и на все уровни сразу. Хотя-бы их канву...
Какое время вы отводить на обновление рычага? Зачем ещё одна точка отказа всего, если ределой занимает секунды и обновит конфигурацию именно там где нужно?
Ну и по существу - где воздействия, принятие решений, стимулирование? Все то что писали несколько лет назад рекламируя системы геймификации? В чем тут гипер, если это просто база и набор графиков, без глубоких интеграций?
Насколько я помню водопад умер под тяжестью главы по управлению рисками. Всё признали что заморозить мир на 2-3 года нельзя, а бороться - дорого.
Дальше вернулись к v-модели и итеративной разработке. Где один виток - это водопад, а точнее v-модель с четкими dod, и прочими критериями результата. Размер витка такой, чтоб бороться с рисками (включая риски изменений) было ещё приемлемо.
Итого получили размер витка от 1 недели до 1-3 месяцев в зависимости от бизнеса.
При этом на отрезке 1-4 недели на риски можно почти забить, а вот на 3 месяцах на них придётся потратиться. Поэтому в этой части аджайл пророс как более дешёвый.
А ещё agile предложил подстраиваться процессы под людей, а не людей под процессы и другие ценности, внедрения которых не случилось много где, но почему-то это все называют это agile, а не "скрам но".
Если количество регистраций столь велико, что это нужно учитывать, то вам нужно сохранять желаемый username здесь же, потому что иначе вы будете объяснять пользователю что груздь. А ещё должны вернуть возможные варианты для его выбора, т.к. при значимости нагрузки от такой операции шансов придумать username самостоятельно почти нет.
А констреинт это (кеш в базе) или данные холодные или это какой-то самопальный хеш уже сильно второстепенно при таких просчетах.
При такой нагрузке, скорее всего это будет вообще какое-то api какого-нибудь sso
В робот подключается все что выше бесплатного нативным образом и ещё вагончик. Причём обёртка дают неплохой уровень тулинга и абстракции. Настолько не плохой, что нативно их использовать уже не захочется.
А для нт там своя жизнь. Зря вы его вообще здесь упоминаете.
Используйте yml вместо json - его существенно удобнее diffить в pr
Выделяем общий код тестов хорошо ложится на идеологию кейвордов. Все тоже самое, но выделяемый код имеет понятную ценность и само дерево кейвордов можно проработать заранее, а не хаотично
Очень важный пункт - помните про параллельность и уборку за собой не озвучен.
Выбор данных, их подготовка, приборка не должны влиять на систему радикальным образом. Например, видел историю когда статистика в базе сходила с ума от запуска тестов и тестовая зона вела себя не адекватно
Хорошо сказали про api. Но нужно добавить, что не следует бояться расширять апи в целях увеличения тестируемости продукта. Это лучше прямых конектов в приложение.
Только думаем о количестве секретов и потоков. Например интеграцонные тесты получающие 200 паролей на старте и работающие в независимых 80 потоков убивают вольт. 200*80 это до 16ktps если не тормозить запуск.
Тоже, но в ленивом обращении может давать 1кк обращений в час, от чего вольту тоже станет грустно.
А вот что делать если у тебя забанили пакет (антивирус, например за текст)?
Update не пройдёт, т.к. uv и poetry анализируют все зависимости.
И ты такой радостный - добро пожаловать в 2013, ещё до pipenv... (антивирус отключить можно, но не нужно)
Я давно меряю аварии по количеству косяков которые должны были случится одновременно, чтоб авария состоялась. Обычно это от 3 до 5. Такого простого и понятного, типа "перепутал кнопку и ребутнул банк" найти нынче сложно.
А можно примеры как будут diff выглядеть?
Сортированый и максимально упрощённый yaml - понятен, там все более менее однозначно.
Toml уже заставляет грустить тем что Саша пишет пути так, а Маша по другому.
Json... если отсортировать и отбьютифарить, то можно, но скобочки добавят боли.
А как с этим здесь?
Посмотрите доку по uv и его использованию в docker или poetry, не позорьтесь
Имеет. C#, go это жёсткий вендор лок. Ими корпорация крутит как хочет. Причём не просто может, а делает. Посмотрите на яблоко - там все тоже, но быстрее.
Зацепило про 1 млн строк, сразу хочется спросить: А если он принесёт просто на порядок больше записей? Кажется, что база стоит за приложением и бы проверял на нт только реальные сценарии на реальной системе и железе
Кажется дзен TDD так и не понят, что тесты пишутся до кода и как это будет проверяться проектируется одновременно с системой.
Вот честно, проще тесту скормить кусок непонятных данных отброшенных в лог, чем страдать ловя их в потоке.
И это хорошо когда данные просто поменялись, а когда начинается подмес чего-то нового? А потом ещё и ещё? Вам же нужно стабильно обрабатывать и первое и второе и третье. Без тестов тут такой замес можно устроить...
И ещё раз - пишите тесты до кода и на все уровни сразу. Хотя-бы их канву...
Как быть с изоляцией теста и прода?
Какое время вы отводить на обновление рычага? Зачем ещё одна точка отказа всего, если ределой занимает секунды и обновит конфигурацию именно там где нужно?
Ну и по существу - где воздействия, принятие решений, стимулирование? Все то что писали несколько лет назад рекламируя системы геймификации? В чем тут гипер, если это просто база и набор графиков, без глубоких интеграций?
И рядом статья о неадекватности результата
Хотел отправить ребёнку прочитать, но кроме набора терминов один только мусор
Очнь странное сравнение.
Насколько я помню водопад умер под тяжестью главы по управлению рисками. Всё признали что заморозить мир на 2-3 года нельзя, а бороться - дорого.
Дальше вернулись к v-модели и итеративной разработке. Где один виток - это водопад, а точнее v-модель с четкими dod, и прочими критериями результата. Размер витка такой, чтоб бороться с рисками (включая риски изменений) было ещё приемлемо.
Итого получили размер витка от 1 недели до 1-3 месяцев в зависимости от бизнеса.
При этом на отрезке 1-4 недели на риски можно почти забить, а вот на 3 месяцах на них придётся потратиться. Поэтому в этой части аджайл пророс как более дешёвый.
А ещё agile предложил подстраиваться процессы под людей, а не людей под процессы и другие ценности, внедрения которых не случилось много где, но почему-то это все называют это agile, а не "скрам но".
Если количество регистраций столь велико, что это нужно учитывать, то вам нужно сохранять желаемый username здесь же, потому что иначе вы будете объяснять пользователю что груздь. А ещё должны вернуть возможные варианты для его выбора, т.к. при значимости нагрузки от такой операции шансов придумать username самостоятельно почти нет.
А констреинт это (кеш в базе) или данные холодные или это какой-то самопальный хеш уже сильно второстепенно при таких просчетах.
При такой нагрузке, скорее всего это будет вообще какое-то api какого-нибудь sso
Видно посиделок с родней где пересекаются 3 юродные тёти и 5 юродные внучатые племянники не было у вас.
Ещё интересно собрать мед.диагнозы. Хотя-бы основные.
А Nord от Nexign смотрели?
В робот подключается все что выше бесплатного нативным образом и ещё вагончик. Причём обёртка дают неплохой уровень тулинга и абстракции. Настолько не плохой, что нативно их использовать уже не захочется.
А для нт там своя жизнь. Зря вы его вообще здесь упоминаете.
Что сразу бросилось в глаза:
Используйте yml вместо json - его существенно удобнее diffить в pr
Выделяем общий код тестов хорошо ложится на идеологию кейвордов. Все тоже самое, но выделяемый код имеет понятную ценность и само дерево кейвордов можно проработать заранее, а не хаотично
Очень важный пункт - помните про параллельность и уборку за собой не озвучен.
Выбор данных, их подготовка, приборка не должны влиять на систему радикальным образом. Например, видел историю когда статистика в базе сходила с ума от запуска тестов и тестовая зона вела себя не адекватно
Хорошо сказали про api. Но нужно добавить, что не следует бояться расширять апи в целях увеличения тестируемости продукта. Это лучше прямых конектов в приложение.
Только думаем о количестве секретов и потоков. Например интеграцонные тесты получающие 200 паролей на старте и работающие в независимых 80 потоков убивают вольт. 200*80 это до 16ktps если не тормозить запуск.
Тоже, но в ленивом обращении может давать 1кк обращений в час, от чего вольту тоже станет грустно.
А кто что использует для календаря дежурств? Чтоб действительно удобно было.
Все зависит от целей и набираемого коллектива. Например может быть и 1:7 и 1:1000. Первый случай - коллектив фриков нанявший себе в команду мамочку.