Да, все верно уже ответили. На смене релизов почти всегда возникают проблемы со сторонними приложениями, особенная боль – с банковскими. Да и сам свежий релиз обычно бажит. Лучше спокойно подождать как минимум 17.1 и пока остальные «подтянутся»
Я категорически против «галер». Но так же я против той точки зрения, что проект может быть только один и точка, без нюансов.
Что же касается нормированной нагрузки, правильно я вас поняла, что вы считаете нормой когда нагрузка на проекте совсем не нормирована? Как правило те кто требует «только мы» это именно те кто уверен что у их сотрудников нет ничего кроме их проекта, включая личное время. И они же по факту получают жуткую текучку и заваленные проекты.
Ещё раз напомню что мы сейчас не про серьезных и больших с возможностью передвижения по горизонтали.
И ещё один важный момент. Совершенно согласна что многозадачность в чистом виде (то есть выполнение нескольких задач одновременно) - зло. Но если вы читали не только заголовок, но и текст, там я как раз настаиваю на разнесении во времени, и рекомендую ещё и в пространстве.
И нет, вешать на тестировщиков по 5 проектов в месяц- это не тестирование, а профанация. А как можно вести 9 проектов (скрин есть в статье) - я вообще не понимаю, это ни в какие ворота.
В той части где про «разносить по времени» описана схема по которой я работала прошлый год - два продукта. Но ещё есть рекламщики, smm, продакты, местами ещё и копирайтеры, seo. У них, как правило, проще задачи, нет необходимости погружения в продукт и они берут больше проектов.
Ситуация неоднозначная. Полагаю в процентном отношении бытовое насилие сильно превышает маньяков. Ситуация «отправил девушку в незнакомом городе без смартфона»… уже вызывает вопросы той самой безопасности. Статистическая вероятность того что пассажир не желал чтоб отправляющий знал точку прибытия значительно выше нежели маньяк таксист в Западной Беларуси.
Так что вопрос скорее в том они не сообщили вам или они никак не среагировали. Первое может быть именно вопросом безопасности.
Я копипастила из ворда. Блоками текста «от картинки до картинки». Разбивка конец абзац и конец строки — без проблем, сохраняется. Но перед каждым блоком вставляет два пустых абзаца. Это конечно не так критично как засада с пробелом в ссылках, но без них было бы удобнее.
Ну и сама структура абзаца в новом редакторе восторга не вызвала.
Добавление изображений на мой взгляд в новом лучше реализовано.
Может кто подскажет в этом чудо-редакторе способ победить самовозникающие пробелы после ссылок?
Их удаляешь — они там
Этап 1: удалить все пробелы после ссылки, сохранить.
ОР: пробелов нет, ссылки рабочие
ФР: удален пробел в первой измененной ссылке, все остальные пробелы на месте, ссылки битые.
Этап 2: последовательно удаляешь пробелы по одному каждый раз сохраняясь.
ОР: пробелов нет, ссылки рабочие
ФР: в панели редактирования пробелов нет, на статье все еще есть (возможно жесткое кэширование, не проверяла, но не кэш браузера).
Ничче так развлечение (
Однозначный плюс в карму ). К сожалению не все понимают значение UX. Тестирую на заказ небольшие приложения и ещё встречается «не, UX не надо, только функционал».
Я писала на конкретную ЦА. Вы немного не понимаете роль тестировщика в команде ). В статье конкретно прописано предусловие максимально приближенное к реальному. Оно не упущено, оно дается как вводная. Тестировщик не решает как и где монетизировать приложение. Этим занимается менеджер/аналитик/владелец.
Ваша схема вполне годная для одиночки или небольшой студии, специализирующейся на написании серии небольших приложений. Но статья всеж немного о другом.
В любом случае спасибо что откликнулись на призыв, знать с чего начинается не помешает )
Статья для тестировщиков и это не всеобъемлющий труд, а практическая инструкция. Отличие физического и логического разрешения они знают. В таблице по экрану три параметра, физическое разрешение, размер экрана, плотность. В моей таблице есть и логическое, но это не столько для выбора, сколько для работы.
>В яндекс метрике при выборе разрешения экрано гаджетов, тоже будут совсем не физические
В ЯндексМетрике есть оба варианта
Про DevTools сейчас поищу скриншоты, демонстрирующие, почему просмотр в браузере это отправная точка, если плохо там, то будет беда и на устройстве. Но реалии в том, что если хорошо там, еще не значит что будет хорошо и на устройстве. Поэтому крайне желательно проверять дальше браузера
По iPad добавлю в комментарии.
Есть некоторая вероятность, что iPad Air менее капризен в плане незначительных функциональных багов про многоходовочке. Но статистики у меня недостаточно, поэтому утверждать не берусь.
Самой крайне интересно почитать мнения.
Так отлично ж ).
Но всеж в той фразе речь шла про «простых пользователей». А у них нет статуса разработчика .
В тексте нет «ни в коем случае», там лишь написано что это «повод». Не требование. Потому что статистика не на вашей стороне.
Но замечательно что у вас все хорошо ).
Да, все верно уже ответили.
На смене релизов почти всегда возникают проблемы со сторонними приложениями, особенная боль – с банковскими.
Да и сам свежий релиз обычно бажит.
Лучше спокойно подождать как минимум 17.1 и пока остальные «подтянутся»
10 лет в IT, а про работу QA только краем уха слышали (. В таблице нашлось место лишь для QC на бэк и это все?
Ну правильно, зачем остальное тестировать, хотя нормальная практика - это подключение QA ещё на этапе разработки документации.
Я категорически против «галер». Но так же я против той точки зрения, что проект может быть только один и точка, без нюансов.
Что же касается нормированной нагрузки, правильно я вас поняла, что вы считаете нормой когда нагрузка на проекте совсем не нормирована? Как правило те кто требует «только мы» это именно те кто уверен что у их сотрудников нет ничего кроме их проекта, включая личное время. И они же по факту получают жуткую текучку и заваленные проекты.
Ещё раз напомню что мы сейчас не про серьезных и больших с возможностью передвижения по горизонтали.
И ещё один важный момент. Совершенно согласна что многозадачность в чистом виде (то есть выполнение нескольких задач одновременно) - зло. Но если вы читали не только заголовок, но и текст, там я как раз настаиваю на разнесении во времени, и рекомендую ещё и в пространстве.
Правильно делаете.
И нет, вешать на тестировщиков по 5 проектов в месяц- это не тестирование, а профанация. А как можно вести 9 проектов (скрин есть в статье) - я вообще не понимаю, это ни в какие ворота.
В той части где про «разносить по времени» описана схема по которой я работала прошлый год - два продукта. Но ещё есть рекламщики, smm, продакты, местами ещё и копирайтеры, seo. У них, как правило, проще задачи, нет необходимости погружения в продукт и они берут больше проектов.
Сколько приложений поддерживает Android младше 5-го?
Чисто исторические зарисовки можно найти и вне Хабра, тут всеж с уклоном в практику.
Это же в месяц? Печаль
Ситуация неоднозначная. Полагаю в процентном отношении бытовое насилие сильно превышает маньяков. Ситуация «отправил девушку в незнакомом городе без смартфона»… уже вызывает вопросы той самой безопасности. Статистическая вероятность того что пассажир не желал чтоб отправляющий знал точку прибытия значительно выше нежели маньяк таксист в Западной Беларуси.
Так что вопрос скорее в том они не сообщили вам или они никак не среагировали. Первое может быть именно вопросом безопасности.
Я копипастила из ворда. Блоками текста «от картинки до картинки». Разбивка конец абзац и конец строки — без проблем, сохраняется. Но перед каждым блоком вставляет два пустых абзаца. Это конечно не так критично как засада с пробелом в ссылках, но без них было бы удобнее.
Ну и сама структура абзаца в новом редакторе восторга не вызвала.
Добавление изображений на мой взгляд в новом лучше реализовано.
Их удаляешь — они там
Этап 1: удалить все пробелы после ссылки, сохранить.
ОР: пробелов нет, ссылки рабочие
ФР: удален пробел в первой измененной ссылке, все остальные пробелы на месте, ссылки битые.
Этап 2: последовательно удаляешь пробелы по одному каждый раз сохраняясь.
ОР: пробелов нет, ссылки рабочие
ФР: в панели редактирования пробелов нет, на статье все еще есть (возможно жесткое кэширование, не проверяла, но не кэш браузера).
Ничче так развлечение (
Не хотелось повторяться, таких обзоров много. Но раз не хватало — завтра добавлю ссылку ). Спасибо
Ваша схема вполне годная для одиночки или небольшой студии, специализирующейся на написании серии небольших приложений. Но статья всеж немного о другом.
В любом случае спасибо что откликнулись на призыв, знать с чего начинается не помешает )
И такая ситуация отнюдь не единичный случай
>В яндекс метрике при выборе разрешения экрано гаджетов, тоже будут совсем не физические
В ЯндексМетрике есть оба варианта
Про DevTools сейчас поищу скриншоты, демонстрирующие, почему просмотр в браузере это отправная точка, если плохо там, то будет беда и на устройстве. Но реалии в том, что если хорошо там, еще не значит что будет хорошо и на устройстве. Поэтому крайне желательно проверять дальше браузера
Есть некоторая вероятность, что iPad Air менее капризен в плане незначительных функциональных багов про многоходовочке. Но статистики у меня недостаточно, поэтому утверждать не берусь.
Самой крайне интересно почитать мнения.