Comments 106
UFO just landed and posted this here
Просто баг не связан с временем работы, того что требовал тест. По правилам, им следовало эмулировать загрузки с разных адресов и разным контентом, чтобы не участвовал кэш, однако они _зачем_ то залезли в настройки разработчика, чтобы отключить кэш браузера. Честное слово, эппл на свое усмотрение мог бы сделать так, что при включенном режиме разработчика задействовались бы какие-то тяжелые сервисы, из за которых тест был бы провальным. В этом случае тоже бы сказали что виноваты эппл? Баг конечно баг, но проблема в методе тестирования.
По правилам, им следовало эмулировать загрузки с разных адресов и разным контентом, чтобы не участвовал кэшЭто что за правила такие? У них их собственный тест с их собственными правилами, по которым они его проводят одинаково на всех ноутбуках.
И да: можно поменять методику, но тогда придётся ещё и выкинуть в помойку данные по всем тестам, проведённым по существующей методике на ≈140 других ноутбуках.
UFO just landed and posted this here
Тест использует режим разработчика, который вполне может нагружать компьютер, результаты теста справедливо могут отличаться от реальных кейсов использования. Демонстрация правильного прогноза разве не назначение задачи теста? Если тест выдает неправильный результат, может ли это быть виной продукта? Продукт это черный ящик.
Если тест выдает неправильный результат, может ли это быть виной продукта? Продукт это черный ящик.В этой цитате не достаёт логики.
Продукт — чёрный ящик, всё правильно, поэтому тест должен быть таким, что бы не учитывать особенности этого чёрного ящика. До этого же всё работало много лет, и на макбуках тоже. И тут раз и всё сломалось на последних версиях ПО. Так почему вдруг это стало «ошибкой теста»?
А с чего опция отключения кэша делает в режиме разработчика? И почему помимо отключения кэша происходят какие-то другие чудеса?
эппл на свое усмотрение мог бы сделать так, что при включенном режиме разработчика задействовались бы какие-то тяжелые сервисыЕсли бы Apple сделала так, что при отключении кэша, включались какие то тяжелые сервисы, это было бы странно, на грани нового бага. В таком случае на мой взгляд оказался бы виноват эпл, из за недокументированного поведения.
Но вопрос в том, что другие пользователи, которые жаловались на эту проблему, они что то же отключали кэш, а зачем им это? Может те пользователи были разработчиками которым нужно было отключать кэш для работы, а тогда это баг эппла.
Нет, просто в одно и то же понятие «методология тестирования» впихнуто две темы.
По факту, Эппл не правы в том, что тестирование без кеша — неправильное, но при этом правы, в том, что опции для разработчиков могут быть непредсказуемы, поэтому, их действия по переключению чего бы то ни было в этом режиме на Маке — некорректны. А то что, по другому не октлючить, ту уж — извините.
Так что методология тестирования с учётом Мак машин — неправильная, подход с отключеним кеша верен, но не реализуем в данном случае, ну и, конечно, баг в сафари был, но не это не означает, что режим для разработчиков работает так же как для пользователей.
По факту, Эппл не правы в том, что тестирование без кеша — неправильное, но при этом правы, в том, что опции для разработчиков могут быть непредсказуемы, поэтому, их действия по переключению чего бы то ни было в этом режиме на Маке — некорректны. А то что, по другому не октлючить, ту уж — извините.
Так что методология тестирования с учётом Мак машин — неправильная, подход с отключеним кеша верен, но не реализуем в данном случае, ну и, конечно, баг в сафари был, но не это не означает, что режим для разработчиков работает так же как для пользователей.
По моему вы путаете опции разработчика и что то из разряда инженерного меню. Опции для разработчиков должны вести себя предсказуемо, иначе как разработчикам разрабатывать?
Разработчик по-твоему не пользователь?
Когда вы компилируете программу с отладочной информацией и без, с уровнем оптимизации позволяющим компилятору очень вольно интерпретировать программу, сильно ли отличается её код и производительность? Судя по тормозам в сетевых видеограх, сразу после глобального патча (его обычно с отладкой выставляют, потом минипач убирающий это дело) — да, сильно. Это было лирическое отступление, теперь по сути:
Кроме того, разработчикам важен процесс, поэтому допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительность, что естественно не факт, потому как не я делал сафари и не знаю, но аналогию я привёл выше.
Кроме того, разработчикам важен процесс, поэтому допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительность, что естественно не факт, потому как не я делал сафари и не знаю, но аналогию я привёл выше.
Когда вы компилируете программу с отладочной информацией и без, с уровнем оптимизации позволяющим компилятору очень вольно интерпретировать программу, сильно ли отличается её код и производительность?Порой разница очень огромна. Один раз тестировал такое поведение на алгоритме перемножения больших матриц. Отладочная версия отрабатывала минут (!) за 30, а релизная (-О2) — минуты за 3-4.
Судя по тормозам в сетевых видеограх, сразу после глобального патча (его обычно с отладкой выставляют, потом минипач убирающий это дело) — да, сильно.Ни кто так делать не будет, поверьте, в этом смысла просто нет. А лаги после выхода патча связаны с лимитами инфраструктуры игровых серверов, с которых и обновления качают и играть пытаются. Ни кто же не будет держать отдельные дата-центры только для обновлений.
допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительностьКонкретно при отключении кеша, или другими настройками? Догадываетесь, или знаете? А то больше походит на «не смотрел, но осуждаю» :)
«Нет смысла нанимать первоклассных специалистов и указывать им, что делать. Мы нанимаем первоклассных специалистов, чтобы они указывали, что делать нам» — вроде это слова Стива Джобса.
Его не стало — вот и результат.
Его не стало — вот и результат.
Значит рекомендации к предыдущим макбукам надо отозвать и исключить из рейтинга Customer Reports, раз уж они тоже делались по «неправильной методике» ;)
You're holdingtesting it wrong
> Этой техникой пользуются лучшие хакеры
Чего? Хакеры используют BackTrack какой-нибудь, а не наглухо проприетарным софтом, который ваши отпечатки пальцев с облаком синхронизирует.
Чего? Хакеры используют BackTrack какой-нибудь, а не наглухо проприетарным софтом, который ваши отпечатки пальцев с облаком синхронизирует.
> даже если приходится переустановить операционную систему
Противоречий никаких нет.
Противоречий никаких нет.
Отпечатки не синхронизируются, они даже не читаются вне Secure Enclave процессора.
Для логина сенсор передаёт данные в Secure Enclave, и получает подписанный идентификатором процессора ответ о (не)совпадении.
Для логина сенсор передаёт данные в Secure Enclave, и получает подписанный идентификатором процессора ответ о (не)совпадении.
UFO just landed and posted this here
И вообще, это не баг, а фича!
PR-машина работает очень «профессионально» отвечая в стиле «сам дурак»?
Как по мне, так это весьма часто встречается и совсем не профессионально, в противном случае Consumer Reports уже изменили бы технологию тестирования.
Как по мне, так это весьма часто встречается и совсем не профессионально, в противном случае Consumer Reports уже изменили бы технологию тестирования.
«Вы просто неправильно его держите» (с) Джобс.
Добавьте еще один пункт в опрос:
«Apple стала использовать посредственное железо»
«Apple стала использовать посредственное железо»
UFO just landed and posted this here
UFO just landed and posted this here
Да, но они тестируют не так, как это будет делать обычный consumer. Видимо их тест это тупо перезагрузка одной и той же страницы с отключенным cache.
UFO just landed and posted this here
Одна страница от нескольких отличается не сильно. В любом случае, это совсем не похоже на работу обычного пользователя. Не нужно сажать пользователя, один раз записать тест и использовать его постоянно. Производители часто делают много разного, чтобы пользователям было удобно, а не тестам. Chrome с его автоматической подгрузкой страниц, наверное, вообще убивают батарейку только потому, что кеш отключен, а браузер в пустую постоянно подгружает страницы, которые потом не используются.
Иными словами, иная реализация крайне затруднительна
Я не понял, а если сделать просто на странице автоперезагрузку по таймауту (как делают в самых простых веб-чатах, это ни разу не затруднительно и не требует никакого отключения кэшей) — это будет чем-то хуже? Страницу каждый раз совершенно новую генерировать, включая все стили и мелкую графику, как-нибудь даже детерминированно это можно сделать, чтобы все девайсы в совершенно одинаковых условиях.
Обновляться будет только не закешированная область. Внешний вид, картинки и тд, остануться на месте в кеше.
Очевидно, картинки и прочее надо точно так же по новым URL размещать.
Я говорю, всё динамически генерировать, в том числе картинки и т. д. То, что на предыдущем обращении называлось
mymotherfuckingpicture0000024123412.png, при следующем обращении будет называться mymotherfuckingpicture0000024123413.png, и прописано в динамически сгенерированном теле страницы будет под этим, новым, уникальным урлом, и отдаваться будет уже по этому, новому, уникальному урлу.Вы представляете сколько это будет стоить?
А в чем проблема?
Гораздо меньше, чем вы думаете. Требуется студент-ПХПшник с соответствующей оплатой, неделя времени, готовая реализация вихря Мерсенна или другого генератора псевдослучайных чисел и стак оверфлоу что-бы тырить готовые куски кода.
И что он напишет? Сферическую страницу в вакууме, нагрузка на которой никак не будет коррелировать с уже проведёнными тестами?
Он напишет серверную часть, которая будет выдавать под множеством разных имен одну и ту же страницу. Точно ту же самую, которая использовалась в тесте ранее.
Точнее серверную часть, которая будет процедурно генерировать и выдавать предсказуемую страницу с контентом и картинками в зависимости от УРЛа.
Это уже необязательная фича.
Разве? Мне казалось что это и есть основное требование — что-бы у было много разных и повторяемых страниц с уникальным контентом возибежание кеширования. Короче — процедурная генерация полноценных страниц по сиду.
Достаточно генерации имён, чтобы браузер загружал файлы заново. Более того, можно вместо изменения имени просто приписывать параметр, типа index.html?1, этого достаточно, чтобы файл загрузился заново.
document.getElementById(«image_id»).src='images/image.png?'+Math.random()+'';
Ну да, и ещё location, style и link. Разве что фавиконка закешируется всё равно, но я думаю этим можно пожертвовать.
Подозреваю, что и её можно менять динамически.
Мне вот интересно, а как вы будете менять хэш тела? Так что что бы не городить огород, проще вырубить кеширование в браузере и не мучиться. Это тоже самое, что пытаясь сделать код для зажигания светодиода в пару строк. сделать его же, но в пару тысяч.
А зачем менять хеш тела? И что вы вообще имеете в виду под "хешем тела"?
Честно, не выспался и ляпнул не в том смысле. Но подведу все свои написания под знаменатель или равно, смотря как посмотреть.
Проще, удобнее, понятнее обновлять одну и ту же страницу. Ну, а то, что есть галочка для разработчиков, которая отключает кеширование, не значит что кривые руки у создателей теста. Галочка есть? Есть. Каждый может её щёлкнуть? Каждый. Тогда в чём проблема обсуждаемая в данной дискуссии, не ясно, баг браузера. Сам же тест прост, прозрачен, не позволяет никому сказать что мухлевали. А кто проконтролирует кучу одинаковых страниц? Будут сравнивать их хеш? Но ведь странички разные должны быть что бы не кешировались, при том одинаковые. Проблема реализации, как никогда остро. Вроде всё просто, но на мой взгляд нуба, я бы не поверил тесту отличимому от постоянной перезагрузки одной и той же страницы, того же размера.
Проще, удобнее, понятнее обновлять одну и ту же страницу. Ну, а то, что есть галочка для разработчиков, которая отключает кеширование, не значит что кривые руки у создателей теста. Галочка есть? Есть. Каждый может её щёлкнуть? Каждый. Тогда в чём проблема обсуждаемая в данной дискуссии, не ясно, баг браузера. Сам же тест прост, прозрачен, не позволяет никому сказать что мухлевали. А кто проконтролирует кучу одинаковых страниц? Будут сравнивать их хеш? Но ведь странички разные должны быть что бы не кешировались, при том одинаковые. Проблема реализации, как никогда остро. Вроде всё просто, но на мой взгляд нуба, я бы не поверил тесту отличимому от постоянной перезагрузки одной и той же страницы, того же размера.
Да но они не сравнивают ноутбуки между собой. Они советуют ноутбук к покупке.
И если 99% пользователей не включает такие настройки по которым тестировался ноутбук, то какая польза от подобного тестирования? Ответ — никакой? Или я где-то не прав?
p.s. Разве Apple не права тут? Ведь Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи, а на деле у 99% людей они будут работать штатно.
И если 99% пользователей не включает такие настройки по которым тестировался ноутбук, то какая польза от подобного тестирования? Ответ — никакой? Или я где-то не прав?
p.s. Разве Apple не права тут? Ведь Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи, а на деле у 99% людей они будут работать штатно.
Consumer Reports утверждает что ноутбуки будут работать мало времени от батареиА это вы откуда взяли? Consumer Reports не рекомендуют не в смысле «рекомендуем не покупать», а в смысле «не можем поручиться, что это хорошая покупка». Т.е. всё равно как если бы не тестировали.
Вы вообще поняли, о чем речь? Настройка включена именно для того, чтобы имитировать работу нормального пользователя.
То, что баг в сафари проявился именно с этой настройкой, отнюдь не говорит, что он не проявится, если ее отключить. Просто галочка — это путь к стабильному воспроизведению блуждающего бага.
Отзывы пользователей о случайном проявлении того же бага при (я уверен) отключенной настройке это подтверждают.
То, что баг в сафари проявился именно с этой настройкой, отнюдь не говорит, что он не проявится, если ее отключить. Просто галочка — это путь к стабильному воспроизведению блуждающего бага.
Отзывы пользователей о случайном проявлении того же бага при (я уверен) отключенной настройке это подтверждают.
UFO just landed and posted this here
какое-то тестирование сферического коня в вакууме
вот поэтому нельзя верить любым тестам которые невозможно воспроизвести
на заметку consumer reports — можно просто загружать каждый раз новый урл (хоть и с одинаковым контентом) вместо ломания браузера
вот поэтому нельзя верить любым тестам которые невозможно воспроизвести
на заметку consumer reports — можно просто загружать каждый раз новый урл (хоть и с одинаковым контентом) вместо ломания браузера
Как тестировщик, считаю нужным отметить, что неправы именно журналисты, но ошибка в методике не тестирования, а оценки результатов.
Поясню. Ключевой момент: «активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага»
Если бы баг проявлялся всегда, а настройка всего лишь помогла его найти — виноваты были бы Apple, которые не нашли критичный баг из-за своих неизобретательных тестеров.
Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
И в результате неправы уже не яблоки, а журналисты — из-за того, что раздули некритичный баг до определяющего при выставлении оценки. А с методологией тестирования у них порядок.
Так что не надо коленным рефлексом сразу хаять яблок, всегда лучше разобраться.
Поясню. Ключевой момент: «активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага»
Если бы баг проявлялся всегда, а настройка всего лишь помогла его найти — виноваты были бы Apple, которые не нашли критичный баг из-за своих неизобретательных тестеров.
Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
И в результате неправы уже не яблоки, а журналисты — из-за того, что раздули некритичный баг до определяющего при выставлении оценки. А с методологией тестирования у них порядок.
Так что не надо коленным рефлексом сразу хаять яблок, всегда лучше разобраться.
Насколько я понял из прочтения статей — Эпл просто объясняет, что неверные результаты теста были из-за бага. А то что у Consumer Reports неправильная методолгия — утверждает какой-то сраный журналист по имени Jim Dalrymple, видимо потому что он — безголовый фанат техники эпл (и скорее всего в технике вообще ничего не понимает). Жаль что не принято журналистов привлекать к судебной ответственности за клевету.
Я не тестировщик и опыта в тестировании у меня нет, но субъективно, некая доля вины Apple в наличии бага всё же есть, пусть даже незначительная. Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа? Настройку может включить любой и она должна правильно работать? Конечно! Но результат при этом ухудшается, и не важно, насколько популярна эта настройка, если она делает этот тест возможным в принципе. ИМХО. И журналистов не оправдываю.
Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа?
Это звучит, будто ноутбук делается не для потребителя/продаж, а затачивается для прохождения конкретного теста.
Раз есть баг — косяк Эплов. Нашли его благодаря Consumer Reports — круто. Думаю еще и спасибо сказали.
Тема слишком раздута…
Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
Смотря какую категорию пользователей рассматривать. У веб-разработчика или тестировщика в веб-проекте эта опция бывает очень актуальной и может быть постоянно включена.
Не соглашусь: надстройка режима разработки открывает ряд функций, необходимых не только для разработчика, но и для сколь бы то ни было опытного пользователя — скажем, супруга время от времени вынуждена что-то из них использовать.
Например, без режима разработки нельзя:
Кроме того, с багом сталкивался лично, и он действительно прискорбный.
Баг не требует галочки на «Очистить кэши» — он работает при включенном Safari и активированном меню разработки. У меня показывается активная оперативка — и в течение последних двух-трёх недель Safari за 5-6 часов работы умудрялся съесть от 5 до 12 гигабайт, после чего компьютер подвисал, включался вентилятор, а закончить беспорядок можно было только через killall в терминале. Даже после этого Мак продолжает сбрасывать кэш иконок и отрисовывает их «на глазах» при открытии любого меню — но я даже подумать не мог, что это может быть связано с опцией в браузере.
Например, без режима разработки нельзя:
- Очистить кэш
- Посмотреть код элемента
- Посмотреть активный код страницы (после выполнения скриптов)
- Отключить скрипты
- Отключить изображения
- Посмотреть ресурсы страницы
- Выполнять действительно «девелоперские» функции — менять user-agent, дебажить JS и т.п.
Кроме того, с багом сталкивался лично, и он действительно прискорбный.
Баг не требует галочки на «Очистить кэши» — он работает при включенном Safari и активированном меню разработки. У меня показывается активная оперативка — и в течение последних двух-трёх недель Safari за 5-6 часов работы умудрялся съесть от 5 до 12 гигабайт, после чего компьютер подвисал, включался вентилятор, а закончить беспорядок можно было только через killall в терминале. Даже после этого Мак продолжает сбрасывать кэш иконок и отрисовывает их «на глазах» при открытии любого меню — но я даже подумать не мог, что это может быть связано с опцией в браузере.
Скрин меню «разработки»:
А я не соглашусь с вами. Вы забываете, что «сколько-нибудь опытные пользователи» — это 5% аудитории браузера, остальное — бабушки, домохозяйки, гуманитарии. И они за 5 лет никогда не воспользуются этой настройкой и, скорее всего, даже не увидят ее.
А «общая» оценка ноута должна исходить именно из этих 95%, а не гиков вроде нас с вами.
Баг, не могу спорить, прискорбный. Для вас, для меня. Но — повторюсь — НЕ критичный в общей картине вещей.
А «общая» оценка ноута должна исходить именно из этих 95%, а не гиков вроде нас с вами.
Баг, не могу спорить, прискорбный. Для вас, для меня. Но — повторюсь — НЕ критичный в общей картине вещей.
Вы точно про MacBook говорите? Основная аудитория пользователей, как по мне, это программисты, блогеры и множество прочих специалистов, которым нужен надежный инструмент для работы. И обычно эти люди продвинутые пользователи.
Ок, соглашаюсь, не подумал.
По основному вопросу это означает, что мое мнение теперь зависит от того, на какой же настройке «висел» баг. Если на отключении кэшей, как написано в статье и в источнике, то по-прежнему не критичен. Если на верхнем уровне, «девелоперских настройках», как утверждает foundout — то соглашусь, что баг переходит в критичные.
По основному вопросу это означает, что мое мнение теперь зависит от того, на какой же настройке «висел» баг. Если на отключении кэшей, как написано в статье и в источнике, то по-прежнему не критичен. Если на верхнем уровне, «девелоперских настройках», как утверждает foundout — то соглашусь, что баг переходит в критичные.
Как тестировщик вы гарантируете что это баг возникает только при активации этой конкретной настройки? Судя по всему — нет. А значит обычные пользователи тоже встречаются с этим багом, тыкая в другие пункты меню.
> Высочайшее качество ноутбуков Apple всем известно
телефонов — еще куда ни шло. то есть даже соглашусь пожалуй, что тут почти нет им равных.
что же касается планшетов и тем более ноутбуков, то лично я тут в корне не согласен. это с т.з. как рядового потребителя, так и человека много лет занимающегося ремонтом мобильной техники.
телефонов — еще куда ни шло. то есть даже соглашусь пожалуй, что тут почти нет им равных.
что же касается планшетов и тем более ноутбуков, то лично я тут в корне не согласен. это с т.з. как рядового потребителя, так и человека много лет занимающегося ремонтом мобильной техники.
В целом, зашел из-за этой же ультражелтушной строки.
В последнее время приходится сталкиваться в работе с теми или иными продуктами Эпла. И почти каждый раз я задаюсь одним и тем же вопросом «Почему? Почему они смогла заработать столько денег на этом?».
В последнее время приходится сталкиваться в работе с теми или иными продуктами Эпла. И почти каждый раз я задаюсь одним и тем же вопросом «Почему? Почему они смогла заработать столько денег на этом?».
Почему? Почему они смогла заработать столько денег на этом?
В ответ вспоминается фрагмент мультфильма, где старик продавал на рынке корову. Без пиара нынче никак.
Конечно яблочная техника неплоха, но не идеальна. А то, что могло бы быть лучше, не обладало простым интерфейсом «для домохозяек», на чем и не смогло завоевать такую аудиторию.
Что именно не так? Лично у меня противоположные наблюдения. Те же макбуки показали себя как крайне надежные и продуманные решения. Планшеты тоже многое пережили. С айфонами были нюансы и по качеству сборки и по работе и по надежности.
Я свой телефон топил в унитазе, булькал в слив. Падал с металической лестницы пересчитав все ступени. Грызли коты. Падал со второго этажа на металлическую плитку. При этом телефон работает до сих пор и при этом ни разу не эппл и не водонепроницаемый, а тем более не ударазащищенный. Из повреждений, разболтавшиеся салазки, скол на стекле, обшарпанность лакированного покрытия, отломал блокировку аккумулятора.
Позвольте с Вами не согласиться, 90% нашей страны вообще не знает что такое Apple, зная только iPhone, а 99% населения в руках даже его не держало. То есть как минимум большинству неизвестно качество продукции какой-то там «апле».
человека много лет занимающегося ремонтом мобильной техники
У вас классический пример ошибки выжившего )
Самое ценное в Apple для меня было то, что это одна компания, которая ответственна за железо и операционную систему, когда у меня проблема — я просто иду к ним и они исправляют эту проблему.
А вот когда у меня был телефон Nokia, купленный у ATT с операционной системой от Microsoft, и у этого телефона была проблема с батареей — меня просто каждая компания отфутболивала к следующей по кругу.
UFO just landed and posted this here
Да, я про эту проблему с WiFi слышал. У меня этой проблемы не было. Слышал, что она возникает с определенными WiFi роутерами (поэтому, наверное, и видели на всех железках в округе).
У меня были другие проблемы с ноутбуком. Одна из них очень редкие зависания видеокарты. Сходил в Apple Store — за 3 дня поменяли материнскую плату, проблема ушла.
Баги бывают как в софте, так и в методологии тестирования. В данном случае имхо нашли по багу и там и там. Apple свой исправила. CR тоже не мешало бы свой исправить и сделать методологию тестирования более приближенной к реальным условиям. На будущее.
UFO just landed and posted this here
Вместо того чтобы рефрешить одну и туже страницу, можно было бы подгружать контент с разных страниц, что бы избежать этой проблемы и сохранить актуальность базы тестов.
То есть методология тестирования, выявившая реальный баг, неверная? Вы точно ничего не попутали?
В данном случае цель тестирования — сравнение разных продуктов, а не выявление багов. Да, выявление редкого бага, не воспроизводящегося при заявленном сценарии использования, в таком случае является ошибкой.
Выражаясь языком статистики, наличие или отсутствие одного единственного бага нельзя считать достоверным критерием сравнения из-за низкой p-value
Продукты с багами — не качественные. Методика служит для определения качественных продуктов. Методика показала что продукт некачественный, потому что в продукте содержался баг. Не вижу в данном силлогизме никаких ошибок и противоречий, методика отработала верно. В общем-то, компания Apple со мной согласна, и принзнала что это их баг виноват, смотрите их ответ по ссылке в статье.
Баги есть всюду, и тот факт что в других продуктах баги не обнаружены, ничего не говорит об их качестве. Поэтому использовать "признак наличие бага" при сравнении — неправильно.
Я все больше и больше убеждаюсь в том, что похоже уже никто не знает как все устроено «глубоко внутри», сами разработчики в том числе… Всякие фрейморки, библиотеки, оболочки, и вообще новый код, появляются с такой скоростью, что люди уже просто не способны отследить все, что происходит и как это все взаимодействует.
> активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага, который перезагружал иконки
Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
И еще стал понятен постоянный входящий трафик с районе 100-200К (в частности с хабра/GT). Вот сейчас включил кэширование — трафик пропал.
Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
И еще стал понятен постоянный входящий трафик с районе 100-200К (в частности с хабра/GT). Вот сейчас включил кэширование — трафик пропал.
Гениально.
Ровно та же проблема, а я грешил на провайдера. При трассировке URL все узлы выдавали 2к+ пинг, скорость доходила до 10КБ/сек, при том макбук загружал всю сетку, и на всех домашних устройствах были проблемы с доступом к сети.
Сколько нервов вымотал себе и интернет-провайдеру, но и подумать не мог, что это в Safari сделали новую фичу. В последние 2-3 дня интернет «стабилизировался» — судя по всему, именно в этом интервале у меня и встал фикс.
Ровно та же проблема, а я грешил на провайдера. При трассировке URL все узлы выдавали 2к+ пинг, скорость доходила до 10КБ/сек, при том макбук загружал всю сетку, и на всех домашних устройствах были проблемы с доступом к сети.
Сколько нервов вымотал себе и интернет-провайдеру, но и подумать не мог, что это в Safari сделали новую фичу. В последние 2-3 дня интернет «стабилизировался» — судя по всему, именно в этом интервале у меня и встал фикс.
При невозможности записать объект в кэш начинаешь какие-то из ресурсов страницы грузить в бесконечном цикле?
из-за бага в неправильной методологии тестирования сафари
один вопрос. А когда это отключение кэша стало опцией разработчика?
Sign up to leave a comment.
Apple исправила баг и обвиняет Consumer Reports в неправильной методологии тестирования