Тех часть имеет значение, если бы его не прошли, то собеседования с командой могло и не быть. Бывает, что человек неплох по тех. скилам, но общаться трудно или не подходит темпераментом, или еще какие-то сомнения. В конце концов могли быть более сильные кандидаты
Проще говоря, считайте, что доменное имя — это номер телефона. Точно так же, как вы используете телефонный номер, чтобы позвонить кому‑то, вы используете доменное имя для доступа к веб‑сайту. Разница в том, что вместо набора номера вы вводите доменное имя в адресную строку веб‑браузера.
Скорее IP адрес сервера - это номер телефона, а домен - это имя человека в телефонной книжке.
Т.е. необходимо ждать отключения в скором времени старых SIM модемов в шлагбаумах, китайских сигнализациях, самоделок и прочего "устаревшего" оборудования
Подобные метрики все таки, либо не работают, либо сложны в понимании, либо слишком много коэффициентов и поправок нужно вводить. Баги бывают сильно разные: приоритеты, затронутые компоненты, а так же заведение бага. Если баг не только был найден и задокументирован (вот баг, надо починить), но и был исследован так, что сразу понятно в какой компоненте или функции проблема, что экономит ресурсы разработчиков?
Скорее, показатель качества продукта - сколько багов (и какой серьезности) нашли пользователи и как сильно саппорт завалило тикетами.
Если коллеги из саппорта не приходят с фразой "как вы это ***** тестировали!?" - значит релиз вышел приемлимым
Автоматизация процессов - это безусловно необходимость и сильно сокращает время регресса. Только всегда появляются ньюансы
1) Кто пишет автотесты? Встречаю команды, где работают в автоматизаторах разработчики и все тесты, условно, "в лоб" написаны, а чуть влево-вправо отойти от теста и лезут баги.
2) Если гонять только автотесты, можно получить эффект дихлофоса. Вроде все прогоны зеленые, но в саппорте жалобы
3) В процессе разработки нужно уже продумывать сценарии и окружение. Разработчики, хоть и покрывают свой код юниттестами, но часто не знают пользовательских сценариев
Возможно для того, чтобы исключить возможность доступа к закешированным файлам. Какие гарантии, что таких не сильно пряморуких разрабов все будет удалятся в соответствии с ГОСТом?
Корень имбиря
Тех часть имеет значение, если бы его не прошли, то собеседования с командой могло и не быть.
Бывает, что человек неплох по тех. скилам, но общаться трудно или не подходит темпераментом, или еще какие-то сомнения. В конце концов могли быть более сильные кандидаты
Скорее IP адрес сервера - это номер телефона, а домен - это имя человека в телефонной книжке.
Тот же вопрос, стоимость была 990 в год. Все устраивало, и тут такое западло
Т.е. необходимо ждать отключения в скором времени старых SIM модемов в шлагбаумах, китайских сигнализациях, самоделок и прочего "устаревшего" оборудования
Так там просто борда под nvidia nano
@AlfaTeamА с кем ожно лично связаться? Есть немного наброса в вашу сторону относительно этой платформы
Подобные метрики все таки, либо не работают, либо сложны в понимании, либо слишком много коэффициентов и поправок нужно вводить. Баги бывают сильно разные: приоритеты, затронутые компоненты, а так же заведение бага. Если баг не только был найден и задокументирован (вот баг, надо починить), но и был исследован так, что сразу понятно в какой компоненте или функции проблема, что экономит ресурсы разработчиков?
Скорее, показатель качества продукта - сколько багов (и какой серьезности) нашли пользователи и как сильно саппорт завалило тикетами.
Если коллеги из саппорта не приходят с фразой "как вы это ***** тестировали!?" - значит релиз вышел приемлимым
Автоматизация процессов - это безусловно необходимость и сильно сокращает время регресса. Только всегда появляются ньюансы
1) Кто пишет автотесты? Встречаю команды, где работают в автоматизаторах разработчики и все тесты, условно, "в лоб" написаны, а чуть влево-вправо отойти от теста и лезут баги.
2) Если гонять только автотесты, можно получить эффект дихлофоса. Вроде все прогоны зеленые, но в саппорте жалобы
3) В процессе разработки нужно уже продумывать сценарии и окружение. Разработчики, хоть и покрывают свой код юниттестами, но часто не знают пользовательских сценариев
На младшей модели такого не было.
www.pluginvulnerabilities.com/2019/02/26/hackers-are-probably-already-exploiting-this-authenticated-option-update-vulnerability-just-fixed-in-freemius