Много команд, много продуктов, каждый автоматизирует релизный цикл, у каждого свой набор скриптов. Дублирование, отсутствие обмена практиками и повторное изобретение колеса приводит к тому, что команды тратят много времени на построение своего CI/CD. И все это поддерживает микросервисную архитектуру, где автоматизации нужно уделить особое внимание.

Меня зовут Владимир Цыбров, я релиз-инженер Леруа Мерлен и сегодня расскажу, какие в компании были подходы к построению пайплайнов и улучшению качества их кода. Спойлер: мы использовали подход InnerSource и предоставили командам self-service-инструменты.

Привет, Хабр! Сегодня мы хотим рассказать о том, как машинное обучение помогает нам освободить время сотрудников в магазинах от длительного пересчета товаров в прямых поставках и сосредоточиться на работе с клиентами. В этом посте мы расскажем, как работает наш продукт «Светофор 3.0», сколько рабочего времени он позволяет экономить и как мы используем ML для оценки вероятностей наличия расхождений в заказах. Кроме этого, расскажем о тонкостях выстраивания доверия сотрудников рекомендациям умной системы. Всех заинтересованных приглашаем под кат и к обсуждению в комментариях.

"Всякое решение плодит новые проблемы" (закон Мерфи)

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

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

Всем привет! Основным инструментом оркестрации задач для обработки данных в Леруа Мерлен является Apache Airflow, подробнее о нашем опыте работы с ним можно прочитать тут. А также мы находимся в постоянном поиске инструментов и фреймворков для упрощения работы наших дата сайентистов и дата инженеров. Один из таких инструментов – фреймворк Ray, который позволяет создавать ML пайплайны из DAGов Airflow. В статье от Astronomer подробно рассматривается, как начать его использовать и с его помощью быстро развернуть и обучить модель.

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

О том как мы внедряли Apache Airflow для использования различными командами в нашей компании, какие задачи мы хотели решить этим сервисом. Внутри описание архитектуры деплоя и наш Infrastructure as Code (IaC).

Всем привет! Недавно мы в первый раз организовали внутренний Хакатон и в этой статье я расскажу про то, как мы это сделали и про шишки, которые мы набили по пути его организации. Статья будет полезна всем, кто впервые организовывает Хакатон: и инженерам, и DevRel, и HR.

Несколько лет назад Леруа Мерлен начала масштабную программу ИТ-трансформации с использованием таких прогрессивных течений, как микросервисная архитектура, предметно-ориентированное проектирование (оно же DDD) и формирование собственных in-house-команд разработки. Пилотным проектом этой программы стало построение омниканальной платформы продаж, то есть возможность для клиента сделать взаимодействие с компанией удобным и доступным через любой существующий канал продаж, будь то сайт, магазин, колл-центр и т. д., в том числе наша платформа дает возможность взаимодействовать с различными партнерами для получения бизнес-синергии. Этой статьей мы начинаем рассказ об опыте использования open-source-платформы Camunda.

Всем привет!

«Данные – это новая нефть» – вам наверняка доводилось уже не раз слышать эту фразу. Впервые в 2006 году эту идею озвучил математик Клайв Хамби в своем блоге, но с тех пор она не потеряла популярности и сейчас её можно услышать почти из каждого утюга. Особую актуальность это выражение приобрело с внедрением технологий обработки больших данных: Hadoop, MapReduce, Spark, Flink, Anaconda (Jupyter), MLFlow, Kubeflow и далее множество других названий, похожих на имена покемонов. В этой статье мы хотели бы рассказать, какие из них мы выбрали в 2021 году в Леруа Мерлен Россия для своей платформы данных. Эта статья является продолжением нашей первой статьи о платформе –  Платформа данных в Леруа Мерлен – 2 года, сотни источников и более 2.000 пользователей.

Apache Airflow – простой и удобный batch-ориентированный инструмент для построения, планирования и мониторинга дата-пайплайнов. Ключевой его особенностью является то, что, используя Python-код и встроенные функциональные блоки, можно соединить множество различных технологий, использующихся в современном мире. Основная рабочая сущность Airflow – DAG – направленный ацикличный граф, в котором узлами являются задачи, а зависимости между задачами представлены направленными ребрами. 

Те, кто использует Apache Airflow для оркестрации задач загрузки данных в хранилище, наверняка оценили гибкость, которую он предоставляет для решения шаблонных задач. Когда весь процесс разработки сводится к заполнению конфигурационного файла с описанием параметров DAGа и списком задач, которые должны выполняться. У нас в Леруа Мерлен такой подход успешно используется для создания задач по перекладыванию данных из raw-слоя в ods-слой хранилища. Поэтому было решено распространить его на задачи по заполнению витрин данных.  

Всем привет! В недавней статье мы рассказали, как мы шли к построению нашей Data Platform.

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

То есть, если возвращаться к финальной схеме из упомянутой выше статьи (специально дублирую ее ниже, чтобы уважаемым читателям было удобнее), то сегодня мы будем более углубленно говорить о реализации «правой части» схемы — той, что лежит после Apache NiFi.

Всем привет!

На сегодняшний день данные и всё связанное с ними (ML, AI, DataMining, etc) это самый хайповый тренд в IT-индустрии. Все - от ритейлеров до компаний Илона Маска - работают (или пытаются работать) с данными. Нас в Леруа Мерлен эта волна не обошла стороной - data-driven подход к принятию решений является одним из основных в компании. Следуя ему, мы создали свою платформу данных, которой на данный момент пользуется около 2 тыс.человек, а в минуту обрабатывается примерно 1800 запросов. В этой статье мы (Data-команда Леруа Мерлен Россия) расскажем, как за 2 года построили платформу данных в компании с большим количеством оффлайн-процессов, про ее архитектуру и опыт, который мы получили в процессе создания.

В 2020 мы перезапустили мобильное приложение Леруа Мерлен и добавили в него Kotlin Multiplatform, Jetpack Navigation и многое другое. Сейчас наше приложение самое популярное среди DIY (Do It Yourself). На пути запуска мы столкнулись с рядом сложностей и получили классный опыт, которым хотим поделиться.

Ведущий — Алексей Гладков, технический архитектор Леруа Мерлен.

Специальный гость — Катя Петрова из Jetbrains! Расскажет о трендах и планах развития KMM.

Описание

19:10-19:50 — Live coding 

Мурагер Жаилхан, разработчик Леруа Мерлен 

Пишем сложную навигацию на jetpack Navigation

19:50-20:30 — Live coding 

Вячеслав Корниенко, разработчик Леруа Мерлен

Покрываем тестами фичу в KMM

20:30—20:50 — regular talk

Катя Петрова, DevAdvocate, JetBrains

Что произошло после выхода в альфу, что нам принесет релиз 1.5 и что нас ждет в будущем.

Когда: 22 апреля, 19:00–21:00 мск, Четверг
Ссылка на мероприятие

Привет, Хабр! Меня зовут Ксюша Блажевич, я руководитель направления data science и product-owner в Леруа Мерлен. 13 апреля в 19:00 МСК мы совместно с Yandex.Cloud организуем митап о платформах данных, на котором обсудим c Авито и Райффайзенбанком методы и инструменты скоринга входных данных, их агрегации и создании единой системы. 

Под катом расписание митапа и анонсы докладов: о релизе нового функционала Yandex Object Storage, методах ускорения time to market до 1 дня, применении lightGBM при приемке товара на складах и оптимизации размещения банкоматов с помощью JupyterHub. 

Эта статья про то, как можно сделать рекомендации на сайт, если один из ключевых критериев — скорость. Нужно это, например, тогда, когда существующая система к набору молотков рекомендует заготовку для выпиливания лобзиком (как это было у нас) или когда её вообще нет.

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

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

Хочу рассказать о том, как мы оптимизировали наш оркестратор микросервисов.

Потому что в случае с такого рода сервисами наш любимый подход "пихаем в базу - строим индексы" не работает. Как минимум потому что базы нет).

В статье расскажу про общие подходы к оптимизации оркестраторов, что и как мы пробовали, как переходили с блокирующего RestTemplate на неблокирующий WebClient.
Как пытались подружить его с CompletableFuture, как положили прод, как нашли проблему, и какие сделали из всего этого выводы.

Забегая вперёд, могу сказать, что переход на неблокирующий веб-клиент для нашего оркестратора, в разы увеличил производительность, а ещё, если думаете использовать WebClient совместно с CompletableFuture, то лучше не надо имеет смысл кое-что проверить.