Всем привет! На связи снова Олег Шилов, фронтенд-разработчик команды Леруа Мерлен. И сегодня я вернулся с продолжением своего рассказа про необычных животных нашей планеты. (Первую часть можно прочитать здесь.) Повторюсь, я не биолог и не специалист по флоре и фауне, а просто увлеченный этой темой обыватель. И задача этого текста — просто поведать вам об удивительных тварях, с которыми мы можем столкнуться в самых разных уголках Земли. Что называется, предупрежден — значит вооружен. Так что всем заинтересовавшимся — приятного прочтения.

Вопрос подготовки релизов и внесения новых изменений стоит перед любыми командами. Но чем масштабнее сфера применения каждого конкретного решения, тем важнее не допустить downtime, связанного с ошибками в новом функционале. В этом посте я расскажу о том, почему нам в Леруа Мерлен потребовалось развивать новый механизм работы с обновлениями, из-за чего не подошел ни один из популярных инструментов и что мы стали делать в итоге. Также мы обсудим различные подходы к организации функций Feature Toggle. Если вы тоже интересуетесь этой темой, приглашаю под кат!

Мне кажется, что каждый человек может иметь любое количество интересов. Тот факт, что мы все занимаемся ИТ, не только не исключает внутренних порывов расширять кругозор, а скорее наоборот — может стать поводом для этого. Для меня лично все началось с передачи про «таинственных обитателей глубин». Я посмотрел жутковатый ролик и подумал: «Интересно, а какие еще неожиданные для нас существа живут в разных уголках нашей планеты?» Начал копать и нашел много интересного. Одни картинки только чего стоят! Сегодня предлагаю посмотреть на тех, кто проводит свое время в толще воды и удивляет нас своими способностями и особенностями жизнедеятельности. 

Привет, Хабр! Меня зовут Олег Шилов, и на самом деле я фронтенд-разработчик команды «Леруа Мерлен». Но сегодня мне хотелось бы поделиться с вами своими находками в мире удивительных животных. Конечно, я не биолог, и этот пост будет скорее взглядом обывателя. Если у вас сегодня есть желание посмотреть на удивительных созданий (и жутких тварей), населяющих нашу планету, узнать, кто может покусать вас в ближайшем водоеме и почему «ангелы» не могут выжить без «чертей», добро пожаловать под кат.

Облачные сервисы — это отлично, но, если ими начинают пользоваться разные команды в компании, вопрос управления затратами превращается в «черный ящик». Когда мы только начинали нашу историю с FinOps, то даже не представляли, насколько эффективнее можно раскрутить историю с арендой облачных мощностей. Но оказалось, что расширение практик управления затратами помогает получить от облаков еще больше отдачи и не допустить необдуманных трат (а то один стартап решил как-то вечером расшифровывать ДНК на арендованных мощностях, а утром закрыл компанию, потому что потратил все деньги). О том, как это было, какие грабли мы собрали по пути, как нам помогла команда ИБ и за счет чего мы теперь экономим до 20% на облачных счетах, читайте под катом.

Такой вопрос возник у меня однажды. А потом еще раз. И я решил разобраться.
Спойлер: конкретного ответа у меня нет. Зато есть исследование.

Вопрос мониторинга GreenPlum часто оказывается непростым, особенно когда на платформе хранится действительно много данных, а запросы пользователей часто меняются. В этом посте я расскажу, как мы в «Леруа Мерлен» настраиваем инструменты Observability, находим узкие места и поддерживаем SLA кластера с GreenPlum на высоком уровне без использования проприетарных решений. Статья будет полезна DWH-архитекторам и DevOps’ам, которые планируют или уже эксплуатируют достаточно большие GP-инсталляции.

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

Привет, Хабр! Как-то раз после работы мне захотелось взять и написать небольшую компьютерную игру. А почему бы и нет? Играть я люблю, программировать — тоже. Захотелось проверить, можно ли сделать что-то прикольное на уровне современных AAA-игр, не изучая дополнительных языков программирования, а также избежать банального повторения тех же «велосипедов», которые уже 100500 раз выложены на различных стримах и, конечно, не раз разбирались на Хабре. В этом посте я хотел бы поделиться с вами своим небольшим экспериментом в области GameDev на базе JS и обсудить возможности, которые есть у любознательного программиста с бэкграундом в сфере JavaScript.

Если вы используете в своей работе NiFi, то наверняка не раз задумывались об оптимизации, а может быть и делали ее. В этом посте я поделюсь своими наработками в области настроек NiFi, благодаря которым мы получили позитивные результаты и улучшили работу наших собственных сервисов. А если конкретно, речь пойдет про выбор стратегии балансировки нагрузки между нодами кластера (load balancing), настройке работы процессоров NiFi в рамках одной ноды (Concurrent tasks, Run Duration), а также о том, что делать с косяками Merge Record. Если интересно, ныряйте под кат и давайте обсудим, что еще хорошего можно сделать с NiFi. 

Привет, Хабр! Сегодня мы поговорим о том, как сделать систему управления отоплением в загородном доме своими руками, используя легкодоступные микроконтроллеры и свободное ПО…причем сделать её так, чтобы можно было запрограммировать работу нужных устройств при помощи моего любимого JavaScript. Под катом — разбор трех вариантов решения этой задачи (включая тот самый, который я выбрал), а также масса рассуждений о преимуществах и недостатках данного подхода. Всех любителей сделайсамов и очумелых ручек приглашаю под кат.

Привет!

Меня зовут Александр Поплёвко, я руководитель продукта онлайн-платежей в Леруа Мерлен.

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

Под катом небольшая история о том, как мы организовали «факап-митапы» (тоже не без факапов) внутри нашей компании, зачем это вообще нужно и при чём тут some title some text.

Всем привет! Меня зовут Александр Токарев, я технический архитектор домена «Управление данными» в «Леруа Мерлен». Год назад мы уже делали обзор нашей Платформы данных, сейчас же я расскажу про её развитие за последний год и про задачи, которые нам удалось решить.

Мы столкнулись с необходимостью масштабировать наш подход, когда количество источников, интегрированных в платформу, стало больше 150. Всего же мы планируем интегрировать данные из более чем 800 систем. Однако ETL-инструменты, которые мы использовали на первых этапах развития дата платформы, не позволяли добиться эффективного масштабирования. Кроме того, сам процесс интеграции источников был достаточно трудоемким. Поэтому возник запрос на рефакторинг архитектуры процесса поставки данных, который, с одной стороны, позволил бы эффективно горизонтально масштабироваться, а с другой стороны, упростил бы сам процесс интеграции. В результате мы пришли к следующей схеме процесса.

Начнем эту увлекательную историю издалека. Во время первого локдауна, в начале 2020 года, сайт Леруа Мерлен испытал бóльшую нагрузку, чем когда-либо. Проводившие много времени дома и на даче наши пользователи взялись чинить полочки, проектировать новые кухни и всеми силами делать свой дом уютнее, воплощая в жизнь новые ремонтные проекты, а инженеры были вынуждены экстренно адаптировать системы под небывалый наплыв трафика. Тогда же стало ясно, что начатое незадолго до локдауна внедрение элементов SRE нужно ускорить.

Внедрение автоматизированных практик тестирования — очень полезная штука. Однако при подходе к этой задаче возникает масса вопросов. Какую платформу выбрать? Сложной ли будет миграция? Какие подводные камни ждут впереди? В своем посте я расскажу, как мы переносили практику тестирования и внедряли «тесты как код» на базе Allure TestOps.

Достаточно давно (по меркам ИТ-мира) я посмотрел доклад Артема Ерошенко с Heisenbug 2020 «Тест-кейсы как код». С переходом в Леруа Мерлен со старой TMS на Allure TestOps появилось желание полноценно попробовать данный подход у себя.

В статье расскажу о том, что из этого получилось.

Привет, Хабр! Меня зовут Ткачев Константин, и я работаю архитектором в Леруа Мерлен.

В этой статье я хочу рассказать, как мы смогли, используя только open-source, построить систему работы с метаданными, которая позволила:
- централизовать и унифицировать описания данных, используемых в компании;
- автоматизировать процессы загрузки данных в корпоративное хранилище — платформу данных;
- и сделать еще многое-многое другое…

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

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

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

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

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

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

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

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