Всем привет! Я работаю в Avito и занимаюсь разработкой инструментов для тестирования. Когда у нас стало много UI-тестов, мы столкнулись с проблемой масштабирования Selenium-серверов, и сейчас я расскажу, как мы ее решили.

И так как же все-таки выполнять много UI-тестов параллельно, используя Selenium Grid? К сожалению — никак.
Selenium Grid не способен выполнять большое количество задач параллельно.
Хотите зарегистрировать действительно большое количество нод? Что ж, попробуйте.
Хотите скорости? Её не будет — чем больше нод зарегистрировано на гриде, тем менее стабильно выполняется каждый тест. Как следствие — перезапуски.
Хотите отказоустойчивость на случай, если Grid перестал отвечать? Тоже нет: вы не можете запустить несколько реплик и поставить перед ними балансировщик.
Хотите обновить Grid без даунтайма и чтобы тесты, выполняющиеся в данный момент, не упали? Нет, это не про Selenium Grid.
Хотите не держать тысячи Selenium-ов разных конфигураций в памяти, а поднимать их по требованию? Не получится.
Хотите знать, как решить все эти проблемы? Тогда приглашаю вас прочитать эту статью.
*(Мой доклад с таким же названием уже звучал на Heisenbug 2017 Moscow, и, возможно, кто-то из читателей с ним знаком. Под катом — более подробная текстовая версия рассказа об инструменте).

15 марта в питерском офисе Wrike прошла встреча автотестировщиков. Поговорили о новых эффективных подходах и инструментах в сфере автоматизации тестирования, оценили их применимость в тех или иных кейсах и спешим поделиться записью докладов и презентациями.

Всем привет! Я бэкэнд-разработчик, пишу микросервисы на Java + Spring. Работаю в одной из команд разработки внутренних продуктов в компании Тинькофф.

У нас в команде часто встает вопрос оптимизации запросов в СУБД. Всегда хочется еще чуть-чуть быстрее, но не всегда можно обойтись продуманно выстроенными индексами — приходится искать какие-то обходные пути. Во время одного из таких скитаний по сети в поисках разумных оптимизаций при работе с БД я нашел бесконечно полезный блог Маркуса Винанда, автора книги SQL Performance Explained. Это тот самый редкий вид блогов, в котором можно читать все статьи подряд.

Хочу перевести для вас небольшую статью Маркуса. Ее можно назвать в какой-то степени манифестом, который стремится привлечь внимание к старой, но до сих пор актуальной проблеме производительности операции offset по стандарту SQL.

Решил я поискать работы Sci-Fi-художников прошлого и настоящего, которые рисовали реактивные ранцы. Нашел группу в ВК «Музей будущего», а там — 16 000 фотографий. Пришлось пересмотреть все вручную, навыбирал несколько десятков с джетпакоподбными аппаратами (см. подборку под катом), а потом задумался, а как же бедные фотографы? Или прочие товарищи, которые работают с тоннами фото/аудио/видео, да еще не в одиночку, а командами, удаленно и пр и пр.

Поспрашивал у знакомых фотографов — они пользуются эдаким миксом лайтрума, гуглдрайва и съемных жестких дисков. Говорят, полный ад.

Поинтересовался у знакомой, которая коммьюнити-менеджер русскоязычного сообщества игр крупной компании в гейм-индустрии на букву «B». Им нужно каталогизировать и искать среди огромного количества аудио- и видео-материалов. Создают много трейлеров к видео, game captures, звуковых эффектов, музыки. Куча файлов, относящихся к разным проектам, которые нужно побороть для дальнейшего кросс-проектного поиска. Не столько важно быстро находить, сколько находить в принципе.

Спросил ещё у архитекторов, у которых в базе 120 000 фоток объектов, как они живут с этим.

Оказывается вся эта область называется digital asset management. Вот список с рейтингами 30+ решений для управления цифровыми ресурсами (англ).

Получение отзывов пользователей всегда было центральным в том, как мы создаем привлекательные приложения, которые приносят бизнес-ценность для клиентов и передают восхитительный пользовательский опыт. Мы делаем это, чаще всего, путем тестирования пользователями приложения. Электронная книга, «Практическое руководство по тестированию пользователей приложений», предлагает пошаговое руководство для дизайнеров и групп разработчиков, как проводить пользовательское тестирование в модерируемых и немодерируемых (онлайн) тестах. В этом посте мы рассмотрим один из ключевых компонентов: как написать эффективный сценарий тестирования юзабилити.

Отличный сценарий тестирования юзабилити прост и поучителен

Почему важно, чтобы у модераторов был сценарий, который нужно соблюдать в пользовательских тестах? Во-первых, вы хотите, чтобы ваши тесты были как можно более стандартными. Это гарантирует, что вы не будете смещать ответы отдельных участников. А уверенность в том, что каждый пользователь отвечает на одни и те же вопросы, гарантирует, что вы сможете увидеть сходства и различия в ваших пользовательских ответах, что поможет вам сделать более убедительные выводы из своего исследования.

В конечном счете, сценарий должен быть простым, но содержать достаточно инструкций, чтобы помочь фасилитатору направлять участников во время модерируемой сессии — или предоставлять всю информацию, которую участники должны знать на немодерируемых (онлайн) сессиях. Вот разделы, которые должен включать документ сценария, с рекомендациями о том, что включать в каждый из них:

---

СОВЕТ: чтобы сделать сценарий более легким для чтения во время модерируемого теста, используйте другой стиль текста или цвет, чтобы отделить инструкции от реального сценария, который будет прочитан участнику.

---

Начиная с конца 80-х в машинах подороже начали появляться HUD (Head-up display) – прозрачные дисплеи, которые водитель наблюдает, глядя вперед через лобовое стекло. А еще ранее (незадолго до начала второй мировой войны), в рудиментарном виде – на самолетах, для отображения прицельной марки без параллакса с дальнейшим развитием до современных HUD.

Технологии создания HUD всегда были на острие прогресса: начиная от простых фиксированных прицельных марок из проволоки или нарисованных на стекле, до CRT дисплеев, затем ЖК и наконец DLP и голографических, с лазерной подсветкой. Именно тут, когда стали коммерчески доступны все необходимые компоненты и технологии — появился WayRay со своим продуктом Navion – каких-нибудь 7 лет назад сделать все это было бы просто невозможно: не было ни материалов, ни подходящих лазеров, ни пространственных модуляторов, да и электроника обошлась бы на порядок дороже.

Всем привет!
Давно ничего не писал, теперь это больше новостной ресурс, а не практический. Попробую подправить ситуацию. Расскажу про разработку HUD-спидометра. Хоть и не лазерная проекция, зато доступно и компактно.
Введение
Началось с того, что мне в руки попали большие 3.3" семисегментные индикаторы. Заказывали их для часов, которые так и не родились. Надо было 4 шт, в лоте 5, китаец положил шесть. Оценив размер, яркость и отражение от лобового стекла я решил — вот оно. Благодаря размеру не видно раздвоения изображения, а якрость позволяет использовать даже при прямом солнце. Сразу соглашусь, что у китайцев есть красивые готовые штуки, которые стоят совсем недорого (все цены на момент написания статьи) — от 1800р. Недостатков всего пара (закроем глаза на неспортивность такого решения):
1. Надо клеить плёнку на стекло — она хоть и прозрачная, но всё ж перекрывает обзор, а я не люблю, когда на стекле что-то мешает. Чуть откинулся, сдвинул кресло — и плёнку надо переклеивать. Ну и даже с плёнкой почти ничего не видно в солнечный день.
2. Можно плёнку не клеить, тогда циферки (они довольно мелкие) двоятся, а в солнце не видно вообще ничего.
Для затравки, результат без плёнки в любом месте стекла и даже днём:


Под катом обещаю много картинок, посредственное видео, код и текст — всё в лучших традициях.