а что же они ещё могли ответить? что "мы оставляем за собой право использовать любые отсканированные нашим оборудованием материалы как нам заблагорассудится"?)
ещё вопрос - можно ли отключить. То, что есть какая-то процедура изменения ключей реестра для сотфа Адоби не означает, что нету ещё каких-то участков программного обеспечения, которые могут делать то же самое. Остаётся только пользоваться и надеяться, что у вас всё будет хорошо, иначе в какой-то из дней ваш сканнер вам напишет "вы были признаны плохим клиентом" и откажется работать)
TDD всегда виделось как методология разработки, когда есть спецификация - тогда, если есть время, можно разрабатывать через TDD, а если времени немного - через "идеальные сценарии", чтобы в итоге получить рабочий скелет с основным функционалом, соответствующим спецификации, ну и затем уже некоторое сглаживание/рефакторинг во время тестирования/обкатывания.
Но чаще всего спецификаций нету, либо то, что есть под этим названием - в лучшем случае описание, что мы хотим, чтобы у нас было/работало/делалось, а при наличии сверок и корректировок "пути" с клиентом, да ещё и когда тоже толком нету ясности - что должно получиться, tdd здесь малополезен и затратен. Он не бесполезен, но по итогам затраты времени на адаптацию тестов к новым требованиям усложняют и затягивают разработку
php.net можно верить только английским статьям, всё переводное нужно смотреть и внимательно вычитывать - не раз с таким сталкивался и лично туда отправлял исправления русскоязычных описаний тех или иных аспектов языка, которые при переводе на ру были переведены некорректно, нечётко, неполно
посоветуйте, пожалуйста, механическую клавиатуру - низкопрофильную, на линейных или тактильных свитчах, желательно чтобы была тихая, а усилия нажатия у свитча - побольше. При этом полноформатная или 96%, большой нормальный этнер (не ansi), желательно функциональные клавиши.
из того, что смотрел близкое к искомому - Logitech MX Mechanical или Logitech TKL G915. Но механикал удалось купить только с quite tactile свитчами и они оказались не слишком тихими - громче чем mx keys( раздражает( что до 915 tkl - то, что нужно, но хотел бы такую же ножничного типа или механику, но низкопрофильную.
божественно же. С удовольствием купил бы такое же, но в механике на линейных свитчах, да низкопрофильное. Ну или мембранную ножничного типа - типа Bakker Elkhuizen. Да где ж купить такое...
пробовал, замечательная, использую в работе каждый день
очень хочется попробовать ещё logitech mx mechanical на красных свитчах - раскладка очень хорошая, но на коричневых слишком громко кликает, после мембранной Mx Keys раздражает(
у меня 22 убунту месяц назад внезапно перестала на ноутбуке адекватно распознавать аналоговые наушники - если воткнуть науники в 3.5 мини-джек, то пока идёт звуковой поток от чего-либо - всё относительно нормально играет и звучит. Если же звук не выводится, через несколько секунд в наушниках появляется белый шум и по громкости быстро наростает в громкий ШУМ из наушников.
перепробовал всё, что нашёл и мог из интернетов - ничего не помогло, максимум смог отключить вывод на 3.5 вывод. В итоге так и не исправил этот момент, наушники подсоединены через внешнюю usb-звуковую карту
самое странное, что раньше всё работало нормально, но в один из дней что-то поломалось, непонятно почему - ничего не делал со звуком и не настраивал ничего. Просто в какой-то момент отключил наушники, подключил другие - и появился этот эффект(
по сути, мутационка - это не похоже на "тесты" для тестов - это, скорее, похоже на диагностику, даже на один из способов найти плохие или слабые тесты.
а можно ещё по вот этому моменту ясности - почему при ручном создании тестов человек, написавший тесты, не проверяет их? Ну, должны же быть какие-то причины, по которым тесты "слабые", а тем более - нерабочие, в теории, нерабочий тест невозможно написать - потому что если тест "не работает", это вроде как видно и очевидно.
Или это такой себе способ подстраховать квалификацию тех, кто такие тесты пишет? Или тесты пишутся на "идеальные" сценарии? Типа есть проект, 70% функционала которого покрыто тестами на идеальные сценарии - тогда натравить мутационку и выделить заведомо слабые. Это как-то так работает?
то есть живые люди пишут тесты и в них могут быть ошибки - ну окей, а после написания этих тестов эти люди разве их не проверяют? с покрытием то же самое - ну не покрывает тест заданное - ну так, в теории, человеку, который написал этот тест должно бы это быть очевидно
про "нереалистичность" написал всего лишь в контексте того, что, к сожалению, очень редко встречалось покрытие тестами хотя бы на треть, как правило, тестов или нету, или есть сугубо на "идеальные сценарии" критичного функционала, финрасчёты, вот такое. Да, возможно, я не там работал, с этим и спорить не буду, но пока не видел ни одного проекта, где хотя бы 50% покрытие было
про "тяжёлую артиллерию" - это понятно, просто сама концепция "мутантов" попалась впервые и попытался её осмыслить с позиции своего опыта и практики, скорее всего если грамотно использовать - возможно, это и профитно.
Соответственно мой комментарий был попыткой поразмыслить - какой нужен проект, условия, покрытие тестами, чтобы "мутационные" проверки имели коммерческий смысл.
Много раз сталкивался с тестами, если их было мало или они были недостаточны или плохи - как правило, давался фидбек их автору или ответственному человеку, который исправлял оговоренные моменты и в теории кажется, что так и должно происходить. Но вот, оказывается, можно и ещё что-то делать, пытаться выловить "мутантов" и без какого-то внятного примера это всё выглядит несколько странно. Что-то вроде "проверять вёрстку нагрузочным тестированием" или ещё что-то в этом роде, даже не могу метафору подобрать.
если твои тесты не работают - это не тесты, нужно написать тесты
если они работают плохо - это плохие тесты, нужно написать хорошие тесты
Разработчики склонны писать “позитивные” тесты
ну да, так называемый "идеальный" сценарий, проверять core functionality. Всё равно все кейсы не покрыть, для пользовательского ввода есть валидация.
И тоже странно, что это начинает работать эффективно, когда условно тестами покрыто больше 70% кода - ничего себе, этом как бы единичные проекты могут похвастаться.
Такое ощущение, что эти "мутационные" тесты больше косвенно проверяют некую "устойчивость" проекта, что ли - один "мутант" - это какие-то однородные изменения в проекте.
Как вообще это должно работать? Какой реальный сценарий?
Вот есть условный проект и его кодовая база. Берём и условно покрываем проект на 80% тестами (что само по себе близко к нереальному сценарию). Но, так как у нас нету уверенности в тестах, как могло так получиться? Эти тесты сгенерированы автоматически или как так получается, что тесты написаны, но могут проверять "ничего"?
И когда мы имеем массив покрытия такими тестами, чтобы не ворошить руками тесты, выявляя нерабочие, мы натравливаем ещё "мутационные" тесты, которые делают в коде однородные изменения, чтобы выявить какие-то тесты, которые отвалились. Но такое ощущение, что на этом этапе могут отвалиться и рабочие тесты и наоборот - выжить нерабочие тесты. Получается, всё равно нужен какой-то контроль - или не нужен?
Как глобально работает сценарий? Мы пишем код проекта, генерируем тесты (чтобы не писать тесты), затем загоняем "мутационный" модуль, от которого часть тестов повалится. И мы их удаляем (?) и генерируем новые? Или пишем руками? Просто если руками - почему сразу не проверять работоспособность тестов?
В общем, немного странно выглядит и люто оверкилово. Такое ощущение, что это попытка исправить проблему плохих тестов и тестового покрытия не на этом же уровне, а сделав "финт ушами", что ли.
Возможно, это действительно как-то работает, но на первый взгляд выглядит супер-странно.
так я не делал какую-то реакцию на статью или ответ по пунктам, просто человек написал, что
так и не понял из статье что конкретно вам не понравилось в Канаде
и я написал просто первые 5 пунктов, которые я для себя посчитал максимально критичными.
Например, у автора статьи ещё про "толерантность" было - мне, например, на этот пункт наплевать, хотите - будьте трансами, хотите - сектантами, хотите - верьте в макаронного монстра, но пока эти люди не мешают мне жить, работать и не пытаются вторгаться в жизнь мою/моей семьи - этот пункт не критичен.
Или там отсталость технологий - ну отсталость и отсталость, работаешь с тем, что есть. Да, какие-то моменты неудобны, да, удивляет, что такая структура как "банк" не может поменять адрес доставки - ну, бывает.
а что же они ещё могли ответить? что "мы оставляем за собой право использовать любые отсканированные нашим оборудованием материалы как нам заблагорассудится"?)
ещё вопрос - можно ли отключить. То, что есть какая-то процедура изменения ключей реестра для сотфа Адоби не означает, что нету ещё каких-то участков программного обеспечения, которые могут делать то же самое. Остаётся только пользоваться и надеяться, что у вас всё будет хорошо, иначе в какой-то из дней ваш сканнер вам напишет "вы были признаны плохим клиентом" и откажется работать)
TDD всегда виделось как методология разработки, когда есть спецификация - тогда, если есть время, можно разрабатывать через TDD, а если времени немного - через "идеальные сценарии", чтобы в итоге получить рабочий скелет с основным функционалом, соответствующим спецификации, ну и затем уже некоторое сглаживание/рефакторинг во время тестирования/обкатывания.
Но чаще всего спецификаций нету, либо то, что есть под этим названием - в лучшем случае описание, что мы хотим, чтобы у нас было/работало/делалось, а при наличии сверок и корректировок "пути" с клиентом, да ещё и когда тоже толком нету ясности - что должно получиться, tdd здесь малополезен и затратен. Он не бесполезен, но по итогам затраты времени на адаптацию тестов к новым требованиям усложняют и затягивают разработку
php.net можно верить только английским статьям, всё переводное нужно смотреть и внимательно вычитывать - не раз с таким сталкивался и лично туда отправлял исправления русскоязычных описаний тех или иных аспектов языка, которые при переводе на ру были переведены некорректно, нечётко, неполно
посоветуйте, пожалуйста, механическую клавиатуру - низкопрофильную, на линейных или тактильных свитчах, желательно чтобы была тихая, а усилия нажатия у свитча - побольше. При этом полноформатная или 96%, большой нормальный этнер (не ansi), желательно функциональные клавиши.
из того, что смотрел близкое к искомому - Logitech MX Mechanical или Logitech TKL G915. Но механикал удалось купить только с quite tactile свитчами и они оказались не слишком тихими - громче чем mx keys( раздражает( что до 915 tkl - то, что нужно, но хотел бы такую же ножничного типа или механику, но низкопрофильную.
божественно же. С удовольствием купил бы такое же, но в механике на линейных свитчах, да низкопрофильное. Ну или мембранную ножничного типа - типа Bakker Elkhuizen. Да где ж купить такое...
пробовал, замечательная, использую в работе каждый день
очень хочется попробовать ещё logitech mx mechanical на красных свитчах - раскладка очень хорошая, но на коричневых слишком громко кликает, после мембранной Mx Keys раздражает(
с таким "фукнционалом" можно купить любую клавиатуру на авито/олх и потратить около 2 - 3 долларов)
у меня 22 убунту месяц назад внезапно перестала на ноутбуке адекватно распознавать аналоговые наушники - если воткнуть науники в 3.5 мини-джек, то пока идёт звуковой поток от чего-либо - всё относительно нормально играет и звучит. Если же звук не выводится, через несколько секунд в наушниках появляется белый шум и по громкости быстро наростает в громкий ШУМ из наушников.
перепробовал всё, что нашёл и мог из интернетов - ничего не помогло, максимум смог отключить вывод на 3.5 вывод. В итоге так и не исправил этот момент, наушники подсоединены через внешнюю usb-звуковую карту
самое странное, что раньше всё работало нормально, но в один из дней что-то поломалось, непонятно почему - ничего не делал со звуком и не настраивал ничего. Просто в какой-то момент отключил наушники, подключил другие - и появился этот эффект(
при всём уважении - сомневаюсь, что она хотя бы отдалённо по эргономике, удобству и отклику дотягивает до моей текущей https://www.bakkerelkhuizen.com/s-board-840/
господа, а кто в теме - будьте добры, посоветуйте хороших "ножничных" клавиатур, интересуют
имена и явкибренды, желательно полный форматждите от этого же автора через неделю "Кто до сих пор использует С?" и содержание будет в похожем ключе)
возможно, западным (или и вообще любым) студиям всё равно, с кем партнёрить, пока это приносит деньги.
ага, кажись, теперь понял
по сути, мутационка - это не похоже на "тесты" для тестов - это, скорее, похоже на диагностику, даже на один из способов найти плохие или слабые тесты.
а можно ещё по вот этому моменту ясности - почему при ручном создании тестов человек, написавший тесты, не проверяет их? Ну, должны же быть какие-то причины, по которым тесты "слабые", а тем более - нерабочие, в теории, нерабочий тест невозможно написать - потому что если тест "не работает", это вроде как видно и очевидно.
Или это такой себе способ подстраховать квалификацию тех, кто такие тесты пишет? Или тесты пишутся на "идеальные" сценарии? Типа есть проект, 70% функционала которого покрыто тестами на идеальные сценарии - тогда натравить мутационку и выделить заведомо слабые. Это как-то так работает?
то есть живые люди пишут тесты и в них могут быть ошибки - ну окей, а после написания этих тестов эти люди разве их не проверяют? с покрытием то же самое - ну не покрывает тест заданное - ну так, в теории, человеку, который написал этот тест должно бы это быть очевидно
про "нереалистичность" написал всего лишь в контексте того, что, к сожалению, очень редко встречалось покрытие тестами хотя бы на треть, как правило, тестов или нету, или есть сугубо на "идеальные сценарии" критичного функционала, финрасчёты, вот такое. Да, возможно, я не там работал, с этим и спорить не буду, но пока не видел ни одного проекта, где хотя бы 50% покрытие было
про "тяжёлую артиллерию" - это понятно, просто сама концепция "мутантов" попалась впервые и попытался её осмыслить с позиции своего опыта и практики, скорее всего если грамотно использовать - возможно, это и профитно.
Соответственно мой комментарий был попыткой поразмыслить - какой нужен проект, условия, покрытие тестами, чтобы "мутационные" проверки имели коммерческий смысл.
Много раз сталкивался с тестами, если их было мало или они были недостаточны или плохи - как правило, давался фидбек их автору или ответственному человеку, который исправлял оговоренные моменты и в теории кажется, что так и должно происходить. Но вот, оказывается, можно и ещё что-то делать, пытаться выловить "мутантов" и без какого-то внятного примера это всё выглядит несколько странно. Что-то вроде "проверять вёрстку нагрузочным тестированием" или ещё что-то в этом роде, даже не могу метафору подобрать.
какая-то очень странная концепция
если твои тесты не работают - это не тесты, нужно написать тесты
если они работают плохо - это плохие тесты, нужно написать хорошие тесты
ну да, так называемый "идеальный" сценарий, проверять core functionality. Всё равно все кейсы не покрыть, для пользовательского ввода есть валидация.
И тоже странно, что это начинает работать эффективно, когда условно тестами покрыто больше 70% кода - ничего себе, этом как бы единичные проекты могут похвастаться.
Такое ощущение, что эти "мутационные" тесты больше косвенно проверяют некую "устойчивость" проекта, что ли - один "мутант" - это какие-то однородные изменения в проекте.
Как вообще это должно работать? Какой реальный сценарий?
Вот есть условный проект и его кодовая база. Берём и условно покрываем проект на 80% тестами (что само по себе близко к нереальному сценарию). Но, так как у нас нету уверенности в тестах, как могло так получиться? Эти тесты сгенерированы автоматически или как так получается, что тесты написаны, но могут проверять "ничего"?
И когда мы имеем массив покрытия такими тестами, чтобы не ворошить руками тесты, выявляя нерабочие, мы натравливаем ещё "мутационные" тесты, которые делают в коде однородные изменения, чтобы выявить какие-то тесты, которые отвалились. Но такое ощущение, что на этом этапе могут отвалиться и рабочие тесты и наоборот - выжить нерабочие тесты. Получается, всё равно нужен какой-то контроль - или не нужен?
Как глобально работает сценарий? Мы пишем код проекта, генерируем тесты (чтобы не писать тесты), затем загоняем "мутационный" модуль, от которого часть тестов повалится. И мы их удаляем (?) и генерируем новые? Или пишем руками? Просто если руками - почему сразу не проверять работоспособность тестов?
В общем, немного странно выглядит и люто оверкилово. Такое ощущение, что это попытка исправить проблему плохих тестов и тестового покрытия не на этом же уровне, а сделав "финт ушами", что ли.
Возможно, это действительно как-то работает, но на первый взгляд выглядит супер-странно.
так я не делал какую-то реакцию на статью или ответ по пунктам, просто человек написал, что
и я написал просто первые 5 пунктов, которые я для себя посчитал максимально критичными.
Например, у автора статьи ещё про "толерантность" было - мне, например, на этот пункт наплевать, хотите - будьте трансами, хотите - сектантами, хотите - верьте в макаронного монстра, но пока эти люди не мешают мне жить, работать и не пытаются вторгаться в жизнь мою/моей семьи - этот пункт не критичен.
Или там отсталость технологий - ну отсталость и отсталость, работаешь с тем, что есть. Да, какие-то моменты неудобны, да, удивляет, что такая структура как "банк" не может поменять адрес доставки - ну, бывает.
+1, к тому же, ипотека сама по себе не панацея, её нужно тащить и дотащить, что тоже может быть непросто.
вы серьёзно? вот я прочёл статью и понял для себя её так:
1 климат отстой;
2 нелюдимые люди, не с кем пообщаться вне работы; нелюдимые коллеги, не с кем побщаться на работе;
3 негде толком в городе развлечься, негде толком вне города отдохнуть;
4 медицинский сервис неадекватен - умереть не дадут, а мучиться можешь месяцами и сделать ничего не можешь, хоть бери, да лети в Мексику лечиться;
5 высокие зарплаты, но и высокие цены, дорогое жильё, перегретый рынок съёма
так это же та самая знаменитая формулировка - "На рынке дефицит высококвалифицированных низкооплачиваемых кадров" (с)
перетащить бы на "ножницы" и на USB - отличная была бы клавиатура