Technotext

Хабр, привет! Меня зовут Никита Евдокимов, я работаю старшим разработчиком в «Лаборатории Касперского», а также являюсь мейнтейнером репозитория Kaspresso. Это наш фреймворк для тестирования пользовательских интерфейсов на Android, основанный на Kakao, Espresso и UI Automator.

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

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

Инструменты вроде OpenSearch, Elastic или Kibana давно стали стандартом для поиска и визуализации логов благодаря удобству и мощной поисковой системе. Однако, когда речь заходит о сложном анализе — агрегациях, парсинге, выявлении сложных закономерностей — их встроенные средства быстро достигают предела возможностей. Особенно сложно становится, если структура логов далека от идеала: например, как у нас — всё содержимое свалено в одно поле Message в формате JSON.

Меня зовут Игорь Щегловитов, я работаю экспертом по тестированию в QC облачной инфраструктуры и веб-порталов. Раньше наша команда решала такие задачи кастомными утилитами на C#, которые выгружали логи из ELK и анализировали их локально. Однако каждое новое требование превращалось в мини-проект: доработать код, написать новые парсеры, скрипты агрегации и фильтрации. Работа замедлялась, техдолг рос.

Я решил использовать связку AI-агентов с кастомными промптами, собственный сервисный слой (MCP) для доступа к логам и LLM-модель, чтобы превращать пользовательские запросы в автоматический алгоритм анализа. Так, кейсы вроде «Посчитай уникальных пользователей за сутки» или «Проанализируй ошибки за период» решаются без ручного кодинга.

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

Меня зовут Егор Харченко, я руководитель направления по развитию инфраструктурных сервисов и учета активов в «Лаборатории Касперского». Наш отдел отвечает за инфраструктурные сервисы, которые помогают жить и работать сотрудникам компании: корпоративную почту, unified communications, наше внутреннее облако, печать, рабочее место, антивирусную защиту и так далее. Ну и, конечно, мы отвечаем за учет всех материальных и нематериальных активов.

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

Gray failure, то есть серый, или частичный отказ, — довольно коварная ситуация, когда система демонстрирует квазирабочее состояние. С одной стороны, по проверкам состояния мы наблюдаем работоспособность ресурса, но когда отправляем на него реальную нагрузку — ничего не работает.

Инциденты прошлого года показали нам, что серые отказы в Yandex Cloud могут приводить к деградации доступности для пользователей. Мы регулярно выявляем системные причины и внедряем улучшения на уровне всей облачной платформы, о чём подробнее уже рассказывали в одной из недавних статей. Но иногда решение проблемы серых отказов может требовать действий на клиентской стороне, которые не всегда очевидны. 

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

• какая работа по предотвращению серых отказов была проделана на нашей стороне за счёт слаженной работы всей команды;

• какие настройки стоит взять на вооружение пользователям Yandex Cloud и какие рекомендации могут быть полезны всем ответственным за Disaster Recovery;

• какие инструменты помогают проводить учения по отказоустойчивости инфраструктуры, чтобы выявлять неоптимально настроенные ресурсы. 

Статья будет о том, как быстро начать работать с vLLM и vLLM Production Stack: от первого запуска модели до базовых режимов инференса через OpenAI-совместимый API. Разберем практические настройки и сценарии запуска — tool calling, thinking/non-thinking, мультимодальные и CPU-модели, а так же какие стартовые параметры сильнее всего влияют на память, производительность и стабильность. Отдельном рассмотрим полезные оптимизации для production-сценариев: FP8, Tensor Parallelism, KV-cache offloading, Speculative Decoding и ускорение холодного старта больших моделей.

Привет, Хабр! Меня зовут Сережа Сахаров, я PHP-разработчик в Lamoda Tech. Одной из первых задач в компании для меня стал рефакторинг крупной части кодовой базы. Тогда я уже знал о Rector, но использовать его долгое время не доводилось. И в тот момент, что для решения моей задачи он хорошо подойдёт, если добавить еще несколько кастомных правил.
В процессе я получил интересный опыт, который выходит за рамки шаблонного применения инструмента, разобрался во внутреннем устройстве и механизмах работы, и хочу поделиться этим с PHP-сообществом. Если вам часто приходится сталкиваться с рефакторингом старых PHP-проектов, при этом их потребности выходят за пределы штатного набора правил, эта статья для вас.

Привет, Хабр! Меня зовут Алексей Ситка, я старший разработчик и техлид сервиса уведомлений в Lamoda Tech. Последние годы я занимаюсь проектированием микросервисных приложений из десятков подсистем, в основном в сфере e-commerce. Расскажу, как мы проектировали наш сервис уведомлений, и что у нас получилось. Надеюсь, это будет полезно для тех, кто занимается или интересуется архитектурным планированием. 

Привет, Хабр! Меня зовут Данил Комаров, я дата-сайентист в команде персонализации Lamoda Tech. Уже больше года мы меняем подход к рекомендациям на главной странице, делая их персонализированными. Я расскажу, как мы внедряли и масштабировали решение, переводили его из оффлайна в онлайн, и бустили систему на разных слоях.

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

В Островке из этой задачи в итоге вырос отдельный сервис: он собирает события о релизах, связывает их с изменениями в GitLab, сопоставляет с инцидентами и отдаёт данные в Grafana. На MVP мы покрыли 90% проектов. После того как команды начали регулярно разбирать метрики и автоматизировать узкие места, критичных сбоев стало заметно меньше: в зависимости от месяца снижение доходило до 80% год к году.

Под катом — история о том, как мы к этому пришли. Откуда брали данные для DORA-метрик, как считали показатели при очень разных релизных процессах и почему самой сложной частью оказались не графики, а попытка собрать все это в одну рабочую модель.

Кто победит в соревновании по обработке документов — опытный специалист или нейросеть? На рутинных повторяющихся задачах ИИ уверенно обходит человека: он работает быстрее и не устаёт, тогда как внимание человека дискретно — мы ошибаемся из‑за усталости или монотонности работы.

Оптимальное решение — разделить роли: нейросеть быстро и точно сортирует данные, а человек ставит задачи, контролирует процесс и оценивает результат. Как же на практике превратить ИИ-помощника и живого эксперта в эффективную команду?

Для этого мы в Doubletapp разработали ИИ-платформу, которая облегчает и ускоряет работу с тендерной документацией:

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

Меня зовут Катя Бурлакина, я старший продуктовый дизайнер в VK Tech и занимаюсь развитием дизайн-системы. В этой статье я не буду рассказывать про весь наш путь, а расскажу про его часть — систему дизайн-токенов. Спойлер: при помощи нее у нас получилось устранить некоторые проблемы, ускорить процесс разработки и даже исключить изобретение велосипеда. 

Разработчики FPGA часто сталкиваются с необходимостью внедрения в свой проект софт процессора. Когда-то давно мы могли использовать проприетарные Altera NIOS или Xilinx MicroBlase. Но время идет. В последние годы наблюдается устойчивый тренд перехода производителей ПЛИС в сторону поддержки архитектуры RISC-V.

RISC-V это открытая, расширяемая и бесплатная архитектура набора команд (ISA), которая не требует лицензионных отчислений. Оба FPGA вендора Altera и Xilinx уже довольно давно предлагают и активно разрабатывают поддержку RISC-V в своих новых продуктах, теперь это уже софт процессоры NIOS V и MicroBlase V.

Однако, зачем использовать всё ещё проприетарные ядра, если можно использовать Open Source?

В этой статье я сравниваю два Open Source RISC-V микропроцессора:
1) picorv32 от компании YoSys (https://github.com/YosysHQ/picorv32) и
2) scr1 от Syntacore (https://github.com/syntacore/scr1)

Что буду сравнивать? Производительность софт ядер и занимаемые ресурсы в FPGA.
Как правильно сравнить? Использовать единую тестовую программу написанную на языке C, например Dhrystone, и скомпилированную в бинарный файл, или HEX файл и запускаемую в двух архитектурно одинаковых SOC, но с разными ядрами RISC-V.

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

Привет, меня зовут Рамиль Габдрахманов, я руковожу разработкой видеоплееров в Yandex Infrastructure. Нашу видеоплатформу используют многие сервисы Яндекса: Кинопоиск, Яндекс Маркет, Яндекс Музыка и другие — а компании вне Яндекса могут использовать её через Yandex Cloud Video. В день наш плеер воспроизводит 103 847 867 931 секунду видео.

Сегодня расскажу о том, как устроены ленты коротких видео у нас, что под капотом и какие оптимизации мы применяем.

Самый просто способ запустить локальную LLM - это установить ollama или LM Studio. Это быстро и просто, но вы теряете и в скорости, и в качестве. Почему UD_Q4_K_XL лучше при том же размере, почему квант Q3 может быть медленнее чем Q4. Хорошая ли идея взять REAP для вырезания ненужных экспертов из MoE. Кто быстрее, Linux или Windows. В общем как выжать больше из локальных LLM на домашнем железе.

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

В 2006 году американский журналист и историк Марк Левинсон выпустил книгу под названием «Ящик. Как грузовой контейнер сделал мир меньше, а мировую экономику больше» — первую историю контейнеризации нашей реальности.

Книга, что называется, сорвала банк: её цитировали, раскупали, включили в список лучших бизнес-книг всех времён, её рекомендовал даже Билл Гейтс.

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

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

Распараллеливаем процесс вставки данных в PostgreSQL при помощи Spring с сохранением атомарности всей операции

Разработчики часто сталкиваются с проблемами производительности своих систем. Один из привычных способов ускорить медленный бизнес-процесс — распараллелить его. Это почти всегда работает: чем больше потоков обслуживают задачу, тем быстрее она выполняется.

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

В этой статье расскажу о том, как сделать вставку данных одновременно многопоточной и атомарной.

Привет, Хабр! Меня зовут Даша Козлова, я аналитик в Авито. В этой статье я расскажу свою не самую репрезентативную, но интересную историю рождения бабочки аналитика. Добро пожаловать, усаживайтесь поудобнее и погнали!

Привет, Хабр! Это Станислав Егоркин, инженер юнита k8s департамента разработки Infrastructure в Авито. В одной из своих прошлых статей я описал, как мы детектируем проблемы на нодах Kubernetes-кластеров. Логичным продолжением этой работы стала автоматизация их лечения. В этой статье я расскажу, как у нас устроены механики Auto Healing.

Привет! Меня зовут Илья Комутков, я старший аналитик в Автотеке Авито — сервисе по проверке истории автомобилей с пробегом. В статье расскажу, как мы улучшаем проверку машин и создаём алгоритм рекомендаций по дальнейшим действиям для покупателей. Текст будет интересен начинающим или middle-аналитикам, которые уже умеют работать с SQL, python, ML, но ещё не решали многоэтапные задачи, влияющие на бизнес, и ищут способы применить свои навыки в работе.

Всем привет! Меня зовут Дима Лунин, я автор курса по экспериментам в Академии Аналитиков Авито. В текущей статье я хочу "обкатать" материал, который мы рассказываем на курсе экспериментов, а также поделиться экспертизой по АБ-тестированию с ребятами, которые только начинают свой путь в аналитике, но уже имеют базовые знания в статистике и в проверке стат. гипотез.