имхо, "код после" впринципе тоже норм, если читабельность на первом плане. Можно читать код как документацию, "Если 0, то нет букв. Если 1, то одна буква. Или же там много букв". Но если бы "createPluralDependentMessageParts" встроили напрямую в "make", то стало бы получше.
вопрос к тем кто бросил и не курит уже несколько лет. Как у вас с обонянием? У меня например стало прям очень чувствительным, но не могу понять или изза курева или изза ковида.
А можете рассказать про аналог UI Automation в линуксе? Интересно как там это возможно.
Насколько надежные тесты получаются? Можете ли вы показать видео с записью и воспроизведением? Есть ли визуализация фиксируемого компонента при записи скрипта? Есть ли возможность вкладывать один скрипт в другой, чтобы например одинаковую последовательность не записывать каждый раз?
Когда-то я делал подобный проект, но только под windows. До конца так и не довел, не смог добиться 100% стабильности определения элементов.
:) только недавно я про подобное писал. Почти согласен с вашим подходом, но все таки инварианты нужно проверять в дебаге. Иначе больше времени уйдет на анализ последствий.
в моем случае помогло, стаж 30 лет, в среднем пачка в сутки. За 1.5-2 года при помощи пластырей снизил кол-во сигарет до пачки в три дня. Затем при помощи спрея завязал полностью, где-то месяц и курил и брызгал, затем еще месяц только спрей. Вот уже лет 6-7 не курю и не тянет. К слову сказать у меня не было особо желания бросать курить, только снизить количество.
У вас в последнее время сайт как-то странно работает, фризится на переходах. Иногда некоторые элементы появляются позже, что сдвигает вертикальную позицию, и бывает мисклик.
Да, assert не спасает в релизе, он и не должен этого делать. Его задача отловить баг в рантайме на этапе разработки. Наврятли где-то вся разработка сразу в релизе ведется.
имхо, "код после" впринципе тоже норм, если читабельность на первом плане. Можно читать код как документацию, "Если 0, то нет букв. Если 1, то одна буква. Или же там много букв". Но если бы "
createPluralDependentMessageParts" встроили напрямую в "make", то стало бы получше.вы имеете ввиду опцию "-ftrivial-auto-var-init="? Если да, то разве данные из кучи тоже занулятся?
хм, а разве "co(ко)" происходит не от cooperate? Кооперативная многозадачность
версия 2 -> preamble 0xA6
версия 3 -> preamble 0xA7
и т.д.
я не знаком хорошо с указанными вами ситуациями, но судя по характеру проблем налицо отсутствие достаточного юнит-тестирования.
вопрос к тем кто бросил и не курит уже несколько лет. Как у вас с обонянием? У меня например стало прям очень чувствительным, но не могу понять или изза курева или изза ковида.
А можете рассказать про аналог UI Automation в линуксе? Интересно как там это возможно.
Насколько надежные тесты получаются? Можете ли вы показать видео с записью и воспроизведением? Есть ли визуализация фиксируемого компонента при записи скрипта? Есть ли возможность вкладывать один скрипт в другой, чтобы например одинаковую последовательность не записывать каждый раз?
Когда-то я делал подобный проект, но только под windows. До конца так и не довел, не смог добиться 100% стабильности определения элементов.
https://habr.com/ru/articles/962668/
:) только недавно я про подобное писал. Почти согласен с вашим подходом, но все таки инварианты нужно проверять в дебаге. Иначе больше времени уйдет на анализ последствий.
в моем случае помогло, стаж 30 лет, в среднем пачка в сутки. За 1.5-2 года при помощи пластырей снизил кол-во сигарет до пачки в три дня. Затем при помощи спрея завязал полностью, где-то месяц и курил и брызгал, затем еще месяц только спрей. Вот уже лет 6-7 не курю и не тянет. К слову сказать у меня не было особо желания бросать курить, только снизить количество.
хм, мне казалось что при параллельной сборки могут быть гонки у CURRENT_CNT. А у вас нумерация идет подряд, странно.
а Вы не рассчитываете запускать сборку проектов в несколько потоков? например make all -j8
наверно из-за того что катушка неравномерно намотана :), судя по схеме
В такой ситуации дебаг и юнит-тесты можно использовать на хостовой машине со слоем аппаратной абстракции или в эмуляторе (qemu...)
можно assert применить и с xml, если встроить его в испольняемый код и покрыть тестами. Тогда в релизе у вас отпадет куча проверок.
assertне для валидации пользовательского ввода или от внешних системУ вас в последнее время сайт как-то странно работает, фризится на переходах. Иногда некоторые элементы появляются позже, что сдвигает вертикальную позицию, и бывает мисклик.
Да, assert не спасает в релизе, он и не должен этого делать. Его задача отловить баг в рантайме на этапе разработки. Наврятли где-то вся разработка сразу в релизе ведется.
а какой смысл тогда в assert? Если потом все равно логировать?
можете указать, где почитать про это, интересны мотивы?
Быстрый поиск не нашел по этой теме ничего толкового.