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

На помощь приходит Reactive Manifesto — документ, который обобщил опыт целого ряда компаний по созданию распределенных систем. Манифест формулирует главные принципы, на которые стоит опираться на этапе проектирования и эксплуатации таких систем.

Меня зовут Андрей Василевский, я системный архитектор в Lamoda Tech. В этой статье я на примерах из своей работы покажу, как применять Reactive Manifesto на практике. Статья будет полезна тем, кто только начал изучать распределенные системы, хочет закрепить теорию или тем, кто хочет структурировать проектирование микросервисов в своей компании.

Привет, Хабр. В этой статье я расскажу про своё видение работы с цветом при визуализации графиков. Буду показывать все на примерах — уверен, они вам понравятся.

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

Меня зовут Саша, сейчас я работаю в Lamoda Tech старшим бизнес/дата-аналитиком. До этого я несколько лет был специалистом по данным в другой компании и регулярно представлял совету директоров анализ и прогноз физических и бизнес-показателей. Умение донести результаты исследования до заказчика, особенно если он не погружен в работу с данными — это важный аспект моей профессии. Надеюсь, моя статья с этим немного поможет.

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

Раньше после определения потребностей пользователя я приходила к команде разработки с готовой задачей и дизайн-макетами. А после разработки забирала готовый продукт, чтобы отдать его в A/B-тест.

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

Ну, или не начинается. Или разработка начинается, но совсем не той идеи, которая была вначале.

Я — Саша Пургина, руковожу развитием продуктов на основе данных в Lamoda Tech. В этой статье я расскажу на примере Lamoda, почему разработка ML-продуктов — это сложность и риск. И приведу примеры ошибок, когда хороший продакт в команде может увеличить шансы на успех, имея определенные знания и навыки.

Серебряной пули не ждите, но пара интересных мыслей должна найтись!

Каждый день мы собираем больше 200 ГБ данных о клиентах Lamoda, которые листают сайт и делают заказы. Но красивые цифры про наше хранилище — это одно, а правильные выводы из данных — совсем другое.

Меня зовут Александр Айваз, я руковожу командой Data & Analytics в Lamoda Tech. И сегодня расскажу об ошибках в аналитике, которые легко совершить, глядя на данные в ретейле и e-commerce. Уверен, кому-то статья поможет иначе взглянуть на собственный продукт — или даст представление о том, с какими вопросами работают продуктовые аналитики.

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

13 декабря мы провели первую встречу Lamoda Tech 1С Meetup. Вместе с экспертами поговорили о том, как получать от работы удовольствие, удовлетворение и, конечно, достойное вознаграждение. А на круглом столе успели обсудить и технические вопросы — проблемы интеграции в 1С.

Спикерами в этот день были карьерный консультант Анна Степанян, психолог Дмитрий Фадеев и руководитель отдела 1С-проектов Lamoda Tech Владимир Короткий.

Делимся с вами видеозаписиями всех докладов и презентациями спикеров.

Мне всегда было интересно, получится ли применить AI-инструменты в трудовых буднях программиста. Когда появился ChatGPT, я начал пробовать использовать его в работе, и он быстро стал для меня вспомогательным инструментом. Буквально на днях вышло его крупное обновление, и стала доступна новая функциональность, которая делает его еще удобнее для разработчика.

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

Для наглядности буду демонстрировать все на открытом pet-проекте, чтобы вы видели работу новых функций GPT-4 в действии.

В этом году Lamoda Tech открыла 30 вакансий для джунов. Раньше мы нанимали только специалистов с большим опытом, и для нас это стало началом большого эксперимента. 

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

В  Lamoda Tech мы работаем не только над e-comm платформой и приложениями, но и создаем продукты для внутренних пользователей. Например, системы для пунктов выдачи заказов, приложения для пеших курьеров и так далее.

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

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

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

Привет! Меня зовут Маша Сафронова, и я уже почти 3 месяца работаю младшим продуктовым дизайнером в Lamoda Tech. За последний год я успела пройти стажировку и поработать в двух других крупных IT-компаниях, а еще раньше я переучилась и пришла в дизайн из другой профессии. 

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

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

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

Внедрением практик для мотивации команды я занимаюсь более 6 лет, сначала в n1.ru, а теперь в Lamoda Tech. Сегодня хочу поделиться самыми простыми из них. Это быстрые рецепты, которыми мы пользуемся, чтобы поддержать живую, драйвовую атмосферу внутри команды, даже когда все работают в разных концах земного шара и не хотят включать камеру на созвонах.

Мы ведем техрадар с 2018 года: собираем технологии и инструменты, которые используем в Lamoda Tech, и фиксируем их область применения в компании. В 2018 и 2020 году мы подробно рассказывали на Хабре, с чего начинали и как менялся со временем наш стек. 

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

Я начинал карьеру как фронтенд-разработчик и прошел по всем стандартным этапам: от джуниора до сеньора и тимлида, потом стал руководителем отдела. И дальше, конечно, планировал стать CTO — Chief Technical Officer. И только через несколько лет узнал, что мои представления о том, какие навыки нужны на этой должности, были далеки от реальности.

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

Всем привет, меня зовут Таня Хомякова, я Java-разработчик в Lamoda Tech. Моя команда отвечает за автоматизацию и поддержку процессов на двух складах Lamoda. Обычно наш код не покидает пределов внутренних репозиториев, так как это исключительно внутренняя разработка, но бывают и исключения. 

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

Привет! Я Артем Караблинов, data scientist направления ранжирования и навигации в Lamoda Tech. В середине 2021 года мы запустили новый алгоритм ранжирования каталога, основанный на машинном обучении. С его помощью мы добились существенного улучшения продуктовых метрик за счет внедрения learning-to-rank подхода машинного обучения. 

Это стало прочной основой перед этапом полностью персонализированного каталога, который мы выпустили в начале 2023 года. 

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

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

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

Всем привет! Меня зовут Рома Смирнов. Я работаю продуктовым аналитиком в Lamoda Tech. Не так давно я столкнулся с необычным взглядом на то, как следует интерпретировать результаты A/B-эксперимента. Он заключается в том, что наблюдаемый аплифт — разницу средних, полученную на основе выборок, — необходимо сравнивать не только с критическим z- или t-значением, но еще и с MDE, минимальным эффектом, который мы ожидаем зафиксировать. Утверждается, что тест следует принимать только в том случае, если наблюдаемый аплифт лежит правее значения MDE.

Кажется, что на занятиях по статистике такому обычно не учат. Я обратился к традиционному источнику информации — Всемирной паутине (web, internet) — и нашел на эту тему хорошую статью болгарского гигачада A/B-тестирования Георгия Георгиева. В ней он приводит несколько аргументов, демонстрирующих несостоятельность описанного выше подхода.

В своей статье я буду использовать аргументы Георгия Георгиева, разбавленные моими мыслями и примерами на эту тему.

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

Меня зовут Вика Плешкова, я руководитель IT PM в Lamoda Tech. В этой статье я хочу поделиться нашим опытом перехода к кросс-функциональным продуктовым командам — VTeams. А еще я расскажу, каких успехов мы добились на примере большого кейса по открытию второго склада.

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

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

В этой статье я расскажу:

— как мы не потерялись в сложном графе зависимостей;

— как спасли CI от чрезмерной нагрузки;

— что делать, если с каждым новым модулем приложение запускается всё медленнее;

— мониторинг каких показателей стоит предусмотреть и почему это необходимо.

К 2020 году вы не могли не заметить, что миром правят данные. И, как только речь заходит о работе с ощутимыми объёмами, появляется необходимость в сложном многоэтапном конвейере обработки данных. 

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

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

Я поделюсь несколькими простыми правилами, которые помогают нам в работе с преобразованием данных и, надеюсь, помогут и вам.