Можно заменить, согласно картинке. Короче на Амазоне видел кит для замены:
SOULWIT Replacement Kit for Sony WH-1000XM2 (WH1000XM2) & MDR-1000X (MDR1000X) Headphones, Ear Pads Cushions + Headband Replacement Headstrap Pad Repair Part - Black
И судя по картинке все меняется. Надо болтики открутить, отклеить старый pad и приклеить новый. Но я не совсем этот набор хочу, я видел кит, где амбушуры сделаны типа из охлаждающего геля, кстати от этого же производителя SOULWIT
У меня xm2, которым уже 8 лет. Шумодав был на уровне, очень часто выручал в самолётах. Я столько раз говорил за это спасибо сони. Но вот недавно попробовал airpods pro 3 (до этого были первые и они не такие крутые в плане шумодава были) в самолёте и это сказка. Соньки сразу спрятал.
Я, пару раз ставил под сомнение пирамиду тестирования и на меня смотрели круглыми глазами. Типа это постулаты и незыблемое творение, которое не рушимо😅(как минимум миркосервисная архитектура требует тестирования интеграционного больше, чем те же юнит тесты; плюс тесты в Ci/CD)
Но в целом да, в QA идут за быстрым стартом в it. Но мало кто понимает, что везде нужно развиваться, учиться, расти.
В сторону Ugreen не смотри, только если решишь накатывать trueNas или что-то другое. Операцинка от Ugreen очень сырая. Плюс надо будет делать моддиг(менять термопасту, менять кулер) говорю по опыту, у самого dxp4800plus
Если мой endpoint должен принимать int только и я пишу обработчик, который приводит пришедшее значение к int и если это не int то мы выдаём ошибку, а если int - идём дальше - с моей стороны в обоих случаях у нас валидные данные.
Вы же ожидаете, что придет или то или то? Ожидаете :) А если ожидаете, значит данные валидные. Но если вы не обрабатывает ошибки или допустим у вас пришёл отрицательный int, а всегда должны быть положительные и вы это нигде в коде не предусматриваете - то тут уже негативный кейс.
В общем мое видение этой "проблемы": все то, что не предусмотрено в коде - негативные кейсы
Всегда задумывался о том, почему негативное тестирование, это негативное тестирование.
Мы же предполагаем, что юзер может войти в систему с валидными credentials.
НО так же мы предлагаем, что юзер не может войти в систему в плохими credentials.
Так вот почему в первом случае у нас позитивное тестирование, а во втором примере негативное?
Мы же заранее знаем, что юзер не должен войти.
Или же, мы знаем, что если пошлем не валидный userId, то бэкенд вернёт 404 или 400 или 204 или 422 (в зависимости от реализации), то почему этот тест негативный?
Негативное тестирование в моем понимании, это когда ты посылаешь валидные/не валидные данные и сервис ведёт себя совсем не так, как задумывалось
Привет, спасибо за статью, сам работаю в этой сфере с 2006 года. По поводу причин как-то надуто сказано. Типа тестеры во всем виноваты. Мне кажется, вы просто не отрастили яйца 😄 Я буквально 2 месяца назад завернул проект, сказав боссам, что менеджеры сработали плохо, ибо спека отстой. То, что я протестировал работает согласно спеке, НО вот есть куча других проблем, которые в спеке не описаны. Проект ушел на доработку.
Сегодня был митинг, где я тоже нагло сказал, что команда для которой мы делаем апи не предоставила данные, тестирования в релиз не будет. Бай🙂
Все всегда относительно. Я выгорел из-за того, что 80% сотрудников компании не профессионалы. Ну, когда они задают вопрос какой-то, я чувствовал, что становлюсь тупее. В общем ушел в бэкенд, чтоб общаться с более умными ребятами и стало лучше
Я никого не хочу оскорбить сейчас, но раньше авторов таких постов называли "КО"(капитан очевидность)
За последние годы я вообще не видел одного проекта под ваши критерии, скорее всего происходило, как указал автор выше: спека на 1 страницу и 50-60 багов плюс 3 разраба, которые не понимают, чего от них хотят😁
По поводу предсказаний, мне кажется, это гадание на кофейной гуще. Так как не учитывается просто человеческий фактор. Во вторых, если процесс разработка/тестирование стабилен, то среднеквадратичное значение всегда будет уменьшаться или хотя бы не увеличиваться, так как все поставлено на поток.
Ну и ещё вопрос: этот инструмент был создан для QA или для менеджера проекта?
Можно заменить, согласно картинке. Короче на Амазоне видел кит для замены:
SOULWIT Replacement Kit for Sony WH-1000XM2 (WH1000XM2) & MDR-1000X (MDR1000X) Headphones, Ear Pads Cushions + Headband Replacement Headstrap Pad Repair Part - BlackИ судя по картинке все меняется. Надо болтики открутить, отклеить старый pad и приклеить новый. Но я не совсем этот набор хочу, я видел кит, где амбушуры сделаны типа из охлаждающего геля, кстати от этого же производителя
SOULWITУ меня xm2, которым уже 8 лет. Шумодав был на уровне, очень часто выручал в самолётах. Я столько раз говорил за это спасибо сони. Но вот недавно попробовал airpods pro 3 (до этого были первые и они не такие крутые в плане шумодава были) в самолёте и это сказка. Соньки сразу спрятал.
Xm6 не тестировал, жду когда xm2 сломаются
У меня тоже. Но к слову "кожа" на амбушурвх потрескалась вся. Нужно новые заказать
Я, пару раз ставил под сомнение пирамиду тестирования и на меня смотрели круглыми глазами. Типа это постулаты и незыблемое творение, которое не рушимо😅(как минимум миркосервисная архитектура требует тестирования интеграционного больше, чем те же юнит тесты; плюс тесты в Ci/CD)
Но в целом да, в QA идут за быстрым стартом в it. Но мало кто понимает, что везде нужно развиваться, учиться, расти.
Я помню, как у нас wiki перевели на новый домен, без сохранения редиректа старых url на новые 😆😆😆
О каком состоянии?
А что это за причина: "потому что"? Лично я знаю другие причины: этнические или личное здоровье.
Ещё из интересного отмечу Ugreen NASync серию.В сторону Ugreen не смотри, только если решишь накатывать trueNas или что-то другое. Операцинка от Ugreen очень сырая. Плюс надо будет делать моддиг(менять термопасту, менять кулер) говорю по опыту, у самого dxp4800plus
Если мой endpoint должен принимать int только и я пишу обработчик, который приводит пришедшее значение к int и если это не int то мы выдаём ошибку, а если int - идём дальше - с моей стороны в обоих случаях у нас валидные данные.
Вы же ожидаете, что придет или то или то? Ожидаете :) А если ожидаете, значит данные валидные. Но если вы не обрабатывает ошибки или допустим у вас пришёл отрицательный int, а всегда должны быть положительные и вы это нигде в коде не предусматриваете - то тут уже негативный кейс.
В общем мое видение этой "проблемы": все то, что не предусмотрено в коде - негативные кейсы
Всегда задумывался о том, почему негативное тестирование, это негативное тестирование.
Мы же предполагаем, что юзер может войти в систему с валидными credentials.
НО так же мы предлагаем, что юзер не может войти в систему в плохими credentials.
Так вот почему в первом случае у нас позитивное тестирование, а во втором примере негативное?
Мы же заранее знаем, что юзер не должен войти.
Или же, мы знаем, что если пошлем не валидный userId, то бэкенд вернёт 404 или 400 или 204 или 422 (в зависимости от реализации), то почему этот тест негативный?
Негативное тестирование в моем понимании, это когда ты посылаешь валидные/не валидные данные и сервис ведёт себя совсем не так, как задумывалось
Привет, спасибо за статью, сам работаю в этой сфере с 2006 года. По поводу причин как-то надуто сказано. Типа тестеры во всем виноваты. Мне кажется, вы просто не отрастили яйца 😄 Я буквально 2 месяца назад завернул проект, сказав боссам, что менеджеры сработали плохо, ибо спека отстой. То, что я протестировал работает согласно спеке, НО вот есть куча других проблем, которые в спеке не описаны. Проект ушел на доработку.
Сегодня был митинг, где я тоже нагло сказал, что команда для которой мы делаем апи не предоставила данные, тестирования в релиз не будет. Бай🙂
Все всегда относительно. Я выгорел из-за того, что 80% сотрудников компании не профессионалы. Ну, когда они задают вопрос какой-то, я чувствовал, что становлюсь тупее. В общем ушел в бэкенд, чтоб общаться с более умными ребятами и стало лучше
Я никого не хочу оскорбить сейчас, но раньше авторов таких постов называли "КО"(капитан очевидность)
За последние годы я вообще не видел одного проекта под ваши критерии, скорее всего происходило, как указал автор выше: спека на 1 страницу и 50-60 багов плюс 3 разраба, которые не понимают, чего от них хотят😁
не все современные кондеи умные, 2 недели назад ставил Daikin split + 2 головы и управление по wi-fi только в мечтах моих
Я вчера от одного руководителя услышал:
>Вот так нужно делать, я в сфере уже 5 лет и так правильно
Извините, но тут отчёт, без конкретных цифр, без выявленных проблем, без путей решения этих проблем.
Спасибо за ответ.
По поводу предсказаний, мне кажется, это гадание на кофейной гуще. Так как не учитывается просто человеческий фактор. Во вторых, если процесс разработка/тестирование стабилен, то среднеквадратичное значение всегда будет уменьшаться или хотя бы не увеличиваться, так как все поставлено на поток.
Ну и ещё вопрос: этот инструмент был создан для QA или для менеджера проекта?
Так, а зачем же вообще оценивать результаты тестирования по численным KPI?
Честно, статью прочитал 2 раза, третий раз быстро пробежал глазами и в целом вообще не понял сути внедрения.
Вот! А эплу под вас нужно подстроиться? ?
Монополии на отправку сообщений нет вообще. Хочешь - sms, telegram, Viber, Whatsapp and etc. ? Выбирай все, что угодно)
Не можешь на android выбрать iMessage? Чья это проблема?
Я не могу на iphone установить два одинаковых приложения, я же не ною всем и не говорю, чтоб iphone был похож на android.
Ну такое себе, как и все эти антимонопольные законы
Эмммммм. В таких случаях я всегда говорю: сделай что-то своё, открой аpi и будь супер крутым мужиком ?
Мои друзья читают и отвечают ?Причем на СМС, хотя у всех есть и телеграммы и прочие мессенджеры. Я проблем таких не испытаю