В первой части статьи мы разбирались с теорией, которую нужно знать для создания собственных Pytest-плагинов: фикстурами, маркерами и хуками. А теперь перейдем к практике. 

Я покажу два примера плагинов, которые помогают нам в интеграционном тестировании систем хранения данных. Расскажу, какие задачи они решают, сформулирую требования, покажу реализацию и код тестов. А в конце затрону вопрос о том, когда код имеет смысл оставить во фреймворке, а когда лучше вынести его в отдельный плагин. 

Всем привет! Меня зовут Александр Волков, я занимаюсь интеграционным и компонентным тестированием в YADRO. В числе продуктов компании есть системы хранения данных и, говоря о тестировании, я буду иметь в виду в первую очередь работу с СХД. Однако описанные подходы пригодятся всем, кто ищет инструменты для создания тестового фреймворка и расширения его возможностей под свои задачи. 

Я расскажу, как можно разрабатывать свои плагины для тестового фреймворка, построенного поверх Pytest. Для удобства чтения статья разделена на две части. В первой рассмотрю минимально необходимую теорию: фазы работы Pytest, а также пользу фикстур, маркеров и хуков. Во второй части перейду к практике: разберу два примера реализации плагинов из нашего фреймворка и затрону вопрос о том, когда стоит выносить код в отдельный плагин. 

На работу высокоскоростных интерфейсов в печатных платах влияют множество параметров: свойства препрега и ядра, температура разложения материалов, тангенс угла диэлектрических потерь и шероховатость медной фольги. Вклад последней в общую картину потерь целостности сигналов может быть довольно существенным, в чем мы далее убедимся. Для снижения потерь применяют специальные модели влияния шероховатости фольги: они позволяют получать лучшие результаты на производстве, сократить время на разработку и повысить показатели надежности изделия.

Меня зовут Петр Беляев, я старший системный архитектор в YADRO. Один из многочисленных аспектов деятельности команды, в которой я работаю, — проектирование многослойных высокоскоростных печатных плат. В статье я расскажу о моделях влияния шероховатости фольги на высокочастотные модели в проводнике и приведу пример их применимости при разработке серверной материнской платы, целевой процессор которой поддерживает PCIe Gen5. Но сначала дам контекст, который подробнее ответит на вопрос о том, зачем это все нужно.

Привет, Хабр. Меня зовут Наталья Павликова, в YADRO я работаю в команде DocOps. У нас обширная инфраструктура вокруг задач документирования, которая немного напоминает ходячий замок Хаула. Сегодня я расскажу о небольшой ее части — процессе автоматической генерации и публикации документов из исходников кода.

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

Привет, Хабр! Меня зовут Владислав Виноградов, я инженер группы исследований и разработки ПО глубокого обучения в YADRO. Моя команда создает и оптимизирует связанное с искусственным интеллектом программное обеспечение. Сегодня я расскажу, как можно разработать тензорный компилятор для процессора на базе открытой архитектуры RISC-V. 

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

С древних времен людям было важно определять свое местоположение в пространстве, чтобы проложить маршрут до цели или просто вернуться домой. В современном мире мы уже не ориентируемся по солнцу и звездам, чтобы понять, где находимся мы или целевой объект. Просто достаем смартфон и получаем всю необходимую информацию: где курьер с едой, далеко ли заказанное такси, сколько времени пробираться сквозь пробки на работу и каков оптимальный путь. 

Все это было бы невозможно без эволюции технологий, систем спутниковой и сотовой связи, а также методов, которые вычисляют местоположение мобильных объектов. О них и поговорим под катом. Я Надежда Никулина, ведущий системный аналитик в телеком-команде YADRO. Давно работаю в сфере телекоммуникаций, участвовала в развитии сетей 2G и 3G в России, обеспечивала разработку узлов связи. В статье расскажу, как развивались методы определения позиционирования объектов и почему будущее за гибридными методами и технологиями 5G. 

Внутри каждого современного телефона несколько микросхем ASIC. Ими наполнены автомобили, стойки в центрах обработки данных, датчики «умного дома», и вообще все электронные устройства. Без чипов ASIC был бы невозможен быстрый интернет, трехмерные игры и ускорители машинного обучения. 

Микросхемы ASIC, их родственники FPGA и выросшие с ними технологии проектирования позволили закладывать сложные алгоритмы прямо в «железо». Они разрушили стереотип, что вычислительная система — это только процессор, память и программирование. В статье я расскажу, как развивались ASIC, какую роль в этом процессе сыграли FPGA и каким может быть «железо» будущего.

Меня зовут Андрей Бакшаев, я ведущий инженер-программист в YADRO. Моя команда занимается разработкой и оптимизацией математических библиотек под архитектуру x86. До этого я 15 лет работал в Intel. Значительная часть моих задач заключалась в том, чтобы реализовывать некоторые алгоритмы обработки изображений и сигналов в довольно известной математической библиотеке IPP, максимально эффективно используя возможности процессоров. Я также исследовал производительность этих алгоритмов в процессорах на ранней стадии проектирования. 

В статье я поделюсь своим опытом оптимизации низкоуровневого кода на языке C. Рассмотрим подсистему кэша и памяти процессоров и новые инструкции AVX-512. Разберем пример ускорения копирования байтового массива данных и посмотрим, как векторизованный код позволяет сократить время работы широко используемого алгоритма замены байтов по таблице с 619 до 34 мс, то есть примерно в 18 раз. 

Привет, Хабр! Принесли полезный контент для всех, кто пишет автотесты на Python. В подборке — видео докладов с последнего AQA-митапа: о плагинах Pytest, архитектуре автотестов для продукта на open source-движке, а также о критериях понятных тестов (и как их соблюдать на практике). Материалы будут полезны как начинающим, так и опытным AQA-инженерам. Под катом — все видео и ответ на вопрос, зачем это смотреть, от гостей митапа.

Сегодня мы рассмотрим, что стоит учесть в конструкторской документации, чтобы защититься от проблем на этапе автоматизированного монтажа компонентов на плате. Я покажу, как можно организовать подбор элементов, их взаимное расположение и разводку для монтажа, чтобы увеличить коэффициент выхода годных плат и упростить их диагностику на производстве.

Подход, на который мы будем опираться, называется DFA — Design for Assembly (проектирование для сборки). Набор методов DFA гарантирует возможность сборки компонентов на плате, когда она поступит на монтажный участок, и позволяет отправлять плату в тираж без страха потерять деньги и время.

Я была С++ разработчиком, когда мне предложили стать тимлидом. В моей новой команде были и разработчики, и QA-инженеры. В тестировании я имела поверхностные знания, поэтому долгое время не понимала, как подступиться к задаче по развитию QA-специалистов. Поиск решения занял несколько лет, и в этой статье я поделюсь своим опытом. Надеюсь, она будет полезна для тех тимлидов, которые в тестировании не так хороши, как в программировании.

Я Роман Ананьев, NoSQL/Kafka-инженер в Авито. В этом материале расскажу, как мы попробовали использовать брокер сообщений Apache Kafka в трёх дата-центрах и что из этого получилось.

Сначала пробегусь по архитектуре Kafka, потому что она играет роль в репликации между кластерами. Затем коснусь самих способов репликации и расскажу о двух инструментах для неё: MirrorMaker и uReplicator. Основная часть статьи — про нашу реализацию Kafka cluster federation и то, как Kafka размазана на несколько дата-центров.

Всем привет! Я Дмитрий Лунин, работаю аналитиком в команде ценообразования Авито. Наш юнит отвечает за все платные услуги площадки. Наша основная задача — сделать цены на них оптимальными. 

Мы не только пытаемся максимизировать выручку Авито, но и думаем про счастье пользователей. Если установить слишком большие цены, то пользователи возмутятся и начнут уходить с площадки, а если сделать цены слишком маленькими, то мы недополучим часть оптимальной выручки. Низкие цены также увеличивают количество «спамовых» объявлений, которые портят поисковую выдачу пользователям. Поэтому нам очень важно уметь принимать математически обоснованные решения — любая наша ошибка напрямую отразится на выручке и имидже компании. 

Одним из инструментов для решения наших задач является A/B-тестирование.

Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.

Ситуация с тем-самым-вирусом сильно бьёт по организаторам мероприятий. Людям, которые помогают сообществу разработчиков России, сейчас тяжело. Мы в AvitoTech хотим поддержать своих друзей из Онтико, и поэтому открываем доступ к видео с конференций, которые ещё не публиковались. Это доклады за 2019 год с Saint AppsConf, HighLoad++, DevOpsConf, FrontendConf, Product Fest и с последней TeamLead Conf.

Инженеры Авито, которые выступали или были участниками конференций, вспомнили самые интересные доклады. Под катом — ссылки на плейлисты со всеми-всеми видео и наша субъективная подборка.

UPD: добавили в статью плейлисты с UseData и GolangConf 2019.

На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.

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

Привет, Хабр. На связи UX-лаборатория Авито. Сегодня хотим рассказать об опыте использования айтрекера для проведения количественного эксперимента. Серьёзных инсайтов и уроков не обещаем, просто поделимся своими мыслями.

Расскажем, что вышло из идеи эксперимента, с какими проблемами мы столкнулись в процессе, как их решали и какие выводы сделали. Статья будет полезна исследователям и компаниям, в распоряжении которых есть айтрекер.

Если вы интересуетесь машинным обучением, то наверняка слышали про BERT и трансформеры.

BERT — это языковая модель от Google, показавшая state-of-the-art результаты с большим отрывом на целом ряде задач. BERT, и вообще трансформеры, стали совершенно новым шагом развития алгоритмов обработки естественного языка (NLP). Статью о них и «турнирную таблицу» по разным бенчмаркам можно найти на сайте Papers With Code.

С BERT есть одна проблема: её проблематично использовать в промышленных системах. BERT-base содержит 110М параметров, BERT-large — 340М. Из-за такого большого числа параметров эту модель сложно загружать на устройства с ограниченными ресурсами, например мобильные телефоны. К тому же, большое время инференса делает эту модель непригодной там, где скорость ответа критична. Поэтому поиск путей ускорения BERT является очень горячей темой.

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