На заезде в горку можно упасть в двух случаях:
1) взял слишком "сложную" передачу на короткой, но ооочень резкой горке и не успел выстегнуться — упал. Со мной такого не было ни разу, но я наблюдал несколько подобных случаев. Особенно если тронуться в крутую горку пробуешь (от 12% уклон)
2) если каденс падает, становишься на педали, а заднее колесо пробуксовывает. Сам так падал — задним колесом попал на линию разметки с какой-то грязью. Тоже только на хороших уклонах — от 10%.
Не СПБ и даже не РФ. Заднее колесо повело, я успел поставить ногу, но там оказалась кучка листьев с чем-то под ними (подозреваю, отходы жизнедеятельности).
Велосипед поехал дальше (вправо), моя нога поехала влево, а я с неудобным шпагатом разложился посередине и дорвал уже травмированные связки.
По сути это был поперечный шпагат, только с очень резкой нагрузкой на одну сторону.
Я езжу в пасмурную погоду с мигающим передним светом и вижу таких же довольно часто (живу не в РФ).
Это очень полезно, когда заезжаешь, например, в лес. Или в туннель. Или под мост. Или просто тучка пробежала.
У меня SKS Bluemels и я ими достаточно доволен (велосипед — endurance, поэтому места для длинного заднего крыла нет).
Мыть велик нужно, но зато сам чистый.
Давно не был в СПБ, не помню как там с рельефом, но упасть зимой с велосипеда очень просто на двух манёврах — поворот и заезд в горку.
Как пример, именно на повороте я порвал себе связки колена. Так что обувь для поездок тоже должна быть правильная — обязательно с нескользящей подошвой.
Капюшон не поворачивается вместе с головой, а балаклава — поворачивается. Специальные велокапюшоны делаются с вырезами примерно в районе глаз, чтобы при повороте не закрывать обзор.
Хороший велосипед это тот, который позволит вам проехать минимум тысячу-две километров без серьёзных механических последствий и износа как для вас, так и для него.
В зависимости от дорожного покрытия они бывают дорожные, мтб и смешанные варианты (а-ля грейвел).
Если ездить по полному бездорожью, то стоимость таких велосипедов почти как у автомобиля, т.к. их делают с многократным запасом прочности и из легкоремонтируемых и доступных компонентов.
Если речь идёт о шоссейниках, то основная цель велосипеда — как можно более быстрое передвижение.
Отдельно стоят "городские" велосипеды, о которых вы и говорите. У них задача быть просто развлекательным средством передвижения. Как правило, производители и не собираются их проектировать так, чтобы люди ездили на них каждый день хотя бы по 50км.
Тогда как на шоссере проехать 100км в день — раз плюнуть.
На подавляющем большинстве современных шоссейных и грейвел/циклокроссовых велосипедов нет креплений для крыльев.
Можно ставить либо съёмные крылья, либо мириться с мокрой спиной.
Речь-то была изначально о том, "никто не подписывается на маркетинговые письма". Подписываются, многие. Скидки для подписчиков, лотереи, новости и прочее — всё вполне себе живое и работает. Автор первого комментария — не целевая группа подобных писем.
человек осознанно заходит на специальную страницу «подписка на маркетинговые рассылки», целенаправленно вводит свой e-mail с намерением получать маркетинговые письма и сабмитит форму. Угадайте сколько человек намеренно подпишутся на рассылку? Примерно ноль.
ну это не так.
у меня есть два почтовых ящика на gmail. Один был заведён примерно пять лет назад, другой — больше десяти.
Вот этот, новенький, пятилетка — в нём довольно много подписок с коммерческих сайтов по интересам. Потому что распространена технология "подпишись и получи скидку". Регулярно прохожу и отписываюсь от ряда компаний, т.к. мне они больше не интересны.
Самый главный факт: спама — ноль. Абсолютно. Потому что GDPR...
А вот в том почтовом ящике, которому 10 лет спам постоянно есть. Много.ру, яндекс.пылесос и прочая лабуда, от которой невозможно отписаться, настолько уродский у них сайт. А с Mailchimp — можно.
Я прочитал статью сначала в оригинале, а потом в переводе. И я спорю с автором статьи — там, а тут высказываю своё мнение.
Провокационный заголовок — половина смысла в этой статье. Вводите больше автоматизации, будьте смелее, пишите код лучше, ничего не бойтесь.
Радикализм в любых технологиях — плохо. Если где-то пишут чудовищно много автотестов, но забивают на ручные проверки — плохо. Если наоборот всё в ручную проверяют, без тестов — плохо.
Всё катят на продакшен — так себе идея. Маринуют код месяцами на стейджинге — тоже.
Соблюдайте баланс. Не впадайте в крайности. На мой взгляд, автор статьи как раз в крайности и впадает.
Разработка должна ориентироваться на продакшен, всё остальное — чушь
Меры QA снижают качество
К остальным тезисы, при "правильном" их прочтении, я претензий не имею
Ну если почитать только первое предложение этой главы, то да
так зачем он начинает за здравие, а кончает за упокой? Зачем такой провокационный заголовок и тезис, если оказывается, что в одном конкретном примере плохо было выстроено тестирование и выпуск приложения? Зачем это?
Если отказаться от ручного тестирования специально обученными людьми, а автотесты запускать на CI, чем конкретно должен заниматься отдел QA?
Контроль качества: инструменты разработчика, фреймворк для написания тестов, контроль качества тестов и прочее, прочее, прочее.
Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.
Ну а я видел (не шучу). И видел очень много фронтенд-девелоперов, которые не смогли бы сделать то же, что вы просите. А этот ваш восхитительный бэкендер не смог бы написать <подставить очередную редкую невероятную технологию>. Это пример ложной дихотомии.
Если говорить серьезно, очень странно требовать от QA тех же умений, что и от девелопера. Это разные специальности для решения разных задач.
Да, странно требовать. Тем не менее, Developer in testing часто в первую очередь QA-инженер, а потом уже — девелопер.
В статье такого нет.
Цитирую:
"Ещё я видел, как отделы QA препятствовали деплоям из-за непрохождения тестов после добавления в слой CDN кэширования — TTL в 5 секунд ленты новостей может быть даже незаметен пользователю, но способен испортить тесты QA, вызывая необязательные конфликты между разработчиками и инженерами QA"
Почему вы так решили?
А вы посмотрите на количество комментариев под этой статьёй...
Можно либо навязать больше бюрократии и процедур, что приведет к удлинению цикла поставки, либо просто дропнуть стейдж и радоваться жизни.
Можно. Но это же как раз пример плохого использования технологии, а не плохой технологии. Отказаться от технологии там, где она не работает — это одно. А другое — говорить, что этот подход — какашка. То ли "исторически так сложилось", то ли лень девелоперов, то ли нет в этом действительно нет необходимости.
Как часто даже сейчас я слышу: "ну зачем нам система контроля версий? у нас же простой продукт..." Это всё одного уровня проблема. Лень, непонимание, нежелание учиться на чужих ошибках.
Каждый этап контроля качества ПО — планирование, написание, код ревью, тестирование в нескольких средах, выпуск, мониторинг и поддержка — выстраданы поколениями разработчиков и тестировщиков. За разные этапы, если есть средства и бюджет, отвечают разные люди. Это конвейер.
В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA. По сути, рисует из QA инженеров манки-тестеров. Хороший QA инженер умеет всё то же самое, что и девелопер. Только фокус его внимания смещён с написания кода приложения на контроль кода приложения и контроль целостности системы (т.к. приложение состоит из разных подсистем).
Делает он это здесь:
если вы деплоите легко и часто выпускаете небольшие изменения, то никакой отдел QA не сможет справиться с тестированием каждого деплоя и неизбежно будет мешать деплоить.
и здесь:
выполняющим QA отделам часто не хватает контекста и времени. В результате они могут начать тестировать «воздействие» вместо «задач».
Нельзя с одной стороны, писать про офигенно крутых разработчиков, которые без проблем рефакторят UI компоненты и (предполагается) делают это совершенно без ошибок, а потом приходят вялые QA инженеры и всё портят своей тупизной, т.к. не способны разобраться, почему падают их тесты (именно это и показано в примере).
В идеальной вселенной разработчики умеют во все эти этапы и они становятся full stack developer, мастера на все руки. В реальности таких разработчиков, которые через полгода работы в компании не забивают на всё, кроме написания кода, единицы.
Предметную дискуссию вести с автором статьи сложно. Во-первых, его нет на сайте. Во-вторых, он целенаправленно ставит себя напротив сообщества с целью показать "вы все дураки, один я Д'Артаньян".
один раз наступить на баг, описать его в саппорт и больше никогда с ним не столкнуться, или наступать на один и тот же известный (и уже давно пофикшеный в коде) баг регулярно, потому что у сервиса длительный цикл поставки?
Наличие staging, dev-окружения, релизов, QA инженеров и т.п. никак не говорит о том, что у сервиса длительный цикл доставки. Вопрос исключительно в том, как быстро фиксят проблему и насколько важен фикс именно этой проблем для проекта.
Автор, опять же, считает, что все эти меры — это усложнение. Лично я считаю, что планирование и правильная архитектура мер и сред выполнения дают гораздо больше пользы, чем отказ от них.
Чтобы не впадать в ложную дихотомию, хочется спросить приверженцев такого подхода: а какого рода ПО вы выпускаете?
Мне не хотелось бы с каждым серверным или клиентским релизом быть подопытной мышкой и ждать подлянки в виде плохо протестированных багов.
Я могу привести кучу инструментов, которые очень, очень, ОЧЕНЬ опасно тестировать на продакшене.
Из связанного с деньгами:
банковское ПО
платёжные гейты и вообще системы по приёму платежей
трейдерские системы
бухгалтерия
Из связанного со здоровьем:
медицинские системы
Компоненты систем безопасности (например, механизм выдачи разрешений и т.п.)
Транспорт, энергетика… да куча областей, где ошибки в продакшене выльются не только в крупные финансовые потери, но и в риск здоровью людей.
Меня удивляет, что автор предлагает использовать скучные технологии, но, почему-то, отработанные схемы выпуска ПО считает недостаточно скучной?
Возвратно-поступательное движение характерно для многих отраслей, тут ничего не поделаешь. Остаётся только прилагать усилия, чтобы в лично нашей отрасли / уютном местечке было больше прогресса, чем движения назад.
Метрика эта не вредная, сама по себе. Вот чего не надо, так это экстремальничать и гнаться за метриками. И ещё очень аккуратно надо выбирать единицы измерения метрик, а то получится, что "end2end тесты покрывают 100% сайта" — это фигня полная. А вот, например "end2end тесты покрывают 25 основных сценариев поведения пользователя" — это же совсем другое. (только не докапывайтесь до того, как они хорошо покрывают сценарии, а то в рекурсию войдём :)
На заезде в горку можно упасть в двух случаях:
1) взял слишком "сложную" передачу на короткой, но ооочень резкой горке и не успел выстегнуться — упал. Со мной такого не было ни разу, но я наблюдал несколько подобных случаев. Особенно если тронуться в крутую горку пробуешь (от 12% уклон)
2) если каденс падает, становишься на педали, а заднее колесо пробуксовывает. Сам так падал — задним колесом попал на линию разметки с какой-то грязью. Тоже только на хороших уклонах — от 10%.
Не СПБ и даже не РФ. Заднее колесо повело, я успел поставить ногу, но там оказалась кучка листьев с чем-то под ними (подозреваю, отходы жизнедеятельности).
Велосипед поехал дальше (вправо), моя нога поехала влево, а я с неудобным шпагатом разложился посередине и дорвал уже травмированные связки.
По сути это был поперечный шпагат, только с очень резкой нагрузкой на одну сторону.
Я езжу в пасмурную погоду с мигающим передним светом и вижу таких же довольно часто (живу не в РФ).
Это очень полезно, когда заезжаешь, например, в лес. Или в туннель. Или под мост. Или просто тучка пробежала.
Я и говорю — съёмные.
У меня SKS Bluemels и я ими достаточно доволен (велосипед — endurance, поэтому места для длинного заднего крыла нет).
Мыть велик нужно, но зато сам чистый.
Давно не был в СПБ, не помню как там с рельефом, но упасть зимой с велосипеда очень просто на двух манёврах — поворот и заезд в горку.
Как пример, именно на повороте я порвал себе связки колена. Так что обувь для поездок тоже должна быть правильная — обязательно с нескользящей подошвой.
Капюшон не поворачивается вместе с головой, а балаклава — поворачивается. Специальные велокапюшоны делаются с вырезами примерно в районе глаз, чтобы при повороте не закрывать обзор.
Хороший велосипед это тот, который позволит вам проехать минимум тысячу-две километров без серьёзных механических последствий и износа как для вас, так и для него.
В зависимости от дорожного покрытия они бывают дорожные, мтб и смешанные варианты (а-ля грейвел).
Если ездить по полному бездорожью, то стоимость таких велосипедов почти как у автомобиля, т.к. их делают с многократным запасом прочности и из легкоремонтируемых и доступных компонентов.
Если речь идёт о шоссейниках, то основная цель велосипеда — как можно более быстрое передвижение.
Отдельно стоят "городские" велосипеды, о которых вы и говорите. У них задача быть просто развлекательным средством передвижения. Как правило, производители и не собираются их проектировать так, чтобы люди ездили на них каждый день хотя бы по 50км.
Тогда как на шоссере проехать 100км в день — раз плюнуть.
На подавляющем большинстве современных шоссейных и грейвел/циклокроссовых велосипедов нет креплений для крыльев.
Можно ставить либо съёмные крылья, либо мириться с мокрой спиной.
но там есть подписки и на mailchimp в том числе.
Речь-то была изначально о том, "никто не подписывается на маркетинговые письма". Подписываются, многие. Скидки для подписчиков, лотереи, новости и прочее — всё вполне себе живое и работает. Автор первого комментария — не целевая группа подобных писем.
Да, всё работает через браузер. Ничего ставить не надо.
хм, тогда почему в другом ящике на gmail спама много?
его я использую специально для тех сайтов, которые не соответствуют GDPR
ну это не так.
у меня есть два почтовых ящика на gmail. Один был заведён примерно пять лет назад, другой — больше десяти.
Вот этот, новенький, пятилетка — в нём довольно много подписок с коммерческих сайтов по интересам. Потому что распространена технология "подпишись и получи скидку". Регулярно прохожу и отписываюсь от ряда компаний, т.к. мне они больше не интересны.
Самый главный факт: спама — ноль. Абсолютно. Потому что GDPR...
А вот в том почтовом ящике, которому 10 лет спам постоянно есть. Много.ру, яндекс.пылесос и прочая лабуда, от которой невозможно отписаться, настолько уродский у них сайт. А с Mailchimp — можно.
в локальной сети очень неплохо работает https://snapdrop.net
Я прочитал статью сначала в оригинале, а потом в переводе. И я спорю с автором статьи — там, а тут высказываю своё мнение.
Провокационный заголовок — половина смысла в этой статье. Вводите больше автоматизации, будьте смелее, пишите код лучше, ничего не бойтесь.
Радикализм в любых технологиях — плохо. Если где-то пишут чудовищно много автотестов, но забивают на ручные проверки — плохо. Если наоборот всё в ручную проверяют, без тестов — плохо.
Всё катят на продакшен — так себе идея. Маринуют код месяцами на стейджинге — тоже.
Соблюдайте баланс. Не впадайте в крайности. На мой взгляд, автор статьи как раз в крайности и впадает.
Я спорю с тезисами статьи, такими как:
К остальным тезисы, при "правильном" их прочтении, я претензий не имею
так зачем он начинает за здравие, а кончает за упокой? Зачем такой провокационный заголовок и тезис, если оказывается, что в одном конкретном примере плохо было выстроено тестирование и выпуск приложения? Зачем это?
Контроль качества: инструменты разработчика, фреймворк для написания тестов, контроль качества тестов и прочее, прочее, прочее.
Ну а я видел (не шучу). И видел очень много фронтенд-девелоперов, которые не смогли бы сделать то же, что вы просите. А этот ваш восхитительный бэкендер не смог бы написать <подставить очередную редкую невероятную технологию>. Это пример ложной дихотомии.
Да, странно требовать. Тем не менее, Developer in testing часто в первую очередь QA-инженер, а потом уже — девелопер.
Цитирую:
"Ещё я видел, как отделы QA препятствовали деплоям из-за непрохождения тестов после добавления в слой CDN кэширования — TTL в 5 секунд ленты новостей может быть даже незаметен пользователю, но способен испортить тесты QA, вызывая необязательные конфликты между разработчиками и инженерами QA"
А вы посмотрите на количество комментариев под этой статьёй...
Можно. Но это же как раз пример плохого использования технологии, а не плохой технологии. Отказаться от технологии там, где она не работает — это одно. А другое — говорить, что этот подход — какашка. То ли "исторически так сложилось", то ли лень девелоперов, то ли нет в этом действительно нет необходимости.
Как часто даже сейчас я слышу: "ну зачем нам система контроля версий? у нас же простой продукт..." Это всё одного уровня проблема. Лень, непонимание, нежелание учиться на чужих ошибках.
Каждый этап контроля качества ПО — планирование, написание, код ревью, тестирование в нескольких средах, выпуск, мониторинг и поддержка — выстраданы поколениями разработчиков и тестировщиков. За разные этапы, если есть средства и бюджет, отвечают разные люди. Это конвейер.
В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA. По сути, рисует из QA инженеров манки-тестеров. Хороший QA инженер умеет всё то же самое, что и девелопер. Только фокус его внимания смещён с написания кода приложения на контроль кода приложения и контроль целостности системы (т.к. приложение состоит из разных подсистем).
Делает он это здесь:
и здесь:
Нельзя с одной стороны, писать про офигенно крутых разработчиков, которые без проблем рефакторят UI компоненты и (предполагается) делают это совершенно без ошибок, а потом приходят вялые QA инженеры и всё портят своей тупизной, т.к. не способны разобраться, почему падают их тесты (именно это и показано в примере).
В идеальной вселенной разработчики умеют во все эти этапы и они становятся full stack developer, мастера на все руки. В реальности таких разработчиков, которые через полгода работы в компании не забивают на всё, кроме написания кода, единицы.
Предметную дискуссию вести с автором статьи сложно. Во-первых, его нет на сайте. Во-вторых, он целенаправленно ставит себя напротив сообщества с целью показать "вы все дураки, один я Д'Артаньян".
Наличие staging, dev-окружения, релизов, QA инженеров и т.п. никак не говорит о том, что у сервиса длительный цикл доставки. Вопрос исключительно в том, как быстро фиксят проблему и насколько важен фикс именно этой проблем для проекта.
Автор, опять же, считает, что все эти меры — это усложнение. Лично я считаю, что планирование и правильная архитектура мер и сред выполнения дают гораздо больше пользы, чем отказ от них.
Чтобы не впадать в ложную дихотомию, хочется спросить приверженцев такого подхода: а какого рода ПО вы выпускаете?
Мне не хотелось бы с каждым серверным или клиентским релизом быть подопытной мышкой и ждать подлянки в виде плохо протестированных багов.
Я могу привести кучу инструментов, которые очень, очень, ОЧЕНЬ опасно тестировать на продакшене.
Из связанного с деньгами:
Из связанного со здоровьем:
Компоненты систем безопасности (например, механизм выдачи разрешений и т.п.)
Транспорт, энергетика… да куча областей, где ошибки в продакшене выльются не только в крупные финансовые потери, но и в риск здоровью людей.
Меня удивляет, что автор предлагает использовать скучные технологии, но, почему-то, отработанные схемы выпуска ПО считает недостаточно скучной?
Возвратно-поступательное движение характерно для многих отраслей, тут ничего не поделаешь. Остаётся только прилагать усилия, чтобы в лично нашей отрасли / уютном местечке было больше прогресса, чем движения назад.
Метрика эта не вредная, сама по себе. Вот чего не надо, так это экстремальничать и гнаться за метриками. И ещё очень аккуратно надо выбирать единицы измерения метрик, а то получится, что "end2end тесты покрывают 100% сайта" — это фигня полная. А вот, например "end2end тесты покрывают 25 основных сценариев поведения пользователя" — это же совсем другое. (только не докапывайтесь до того, как они хорошо покрывают сценарии, а то в рекурсию войдём :)