Хабр, привет! Меня зовут Костя Козин, я старший PHP-разработчик Lamoda Tech. За 17 лет в коммерческой разработке я писал на JS, PHP, и теперь на Golang. Сегодня в Lamoda Tech мы учим PHP-разработчиков писать на Go, и под это создали целый онбординг. Довольно часто в локальных обсуждениях я слышал, как тяжело дается переход с PHP на Go, а у некоторых первые месяцы работы с Go вовсе отбивают желание работать с языком. Поэтому я поделюсь подводными камнями, которые ожидают вас при переходе с одного языка на другой, и с которыми сталкивался я сам и мои коллеги. Если знать о них заранее, то смена стека может пройти не так болезненно, а знакомство с Golang станет более предсказуемым.

В Lаmoda Tech мы внедряем ML, чтобы сделать онлайн-шоппинг для миллионов пользователей комфортным, увлекательным и вдохновляющим. 

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

Многие пользователи Яндекс облака применяют сервис Managed Service for Kubernetes. При этом учетные записи сотрудников организаций хранятся на контроллерах домена Windows. Удобно и правильно логиниться в Kubernetes учетными записями из Windows-домена, оптимизируя ресурсы DevOps и сисадминов. Но без специального инструмента сделать это нельзя. 

Меня зовут Дмитрий Глушков, я системный инженер эксплуатации в Lamoda Tech. Мои поиски удобного решения задачи привели к программе Pinniped. Она поможет использовать учетные записи Windows AD для предоставления и контроля доступа сотрудников в Kubernetes. Разберемся, как ее установить и использовать.

В Lamoda Tech более 50 QA backend-инженеров стоят на страже качества нашего продукта. Мы тестируем более 200 систем на Go, PHP и Java и постоянно работаем над процессами тестирования.

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

Привет, Хабр! Это Сергей Евстафьев и Дана Злочевская из команды ранжирования и поиска Lamoda Tech. Наша задача — помочь пользователю найти то, что ему нужно, и не потеряться в море доступных вариантов.

В каталоге Lamoda в наличии более полумиллиона модных товаров, однако 95% пользователей не просматривают больше первых 120 карточек. Поэтому в первую очередь важно показывать только самую релевантную подборку, для этого мы развиваем персональное ранжирование каталога. С его помощью каждый пользователь видит свою уникальную выдачу, которая собирается на основе его поведения, популярности товаров и других параметров. 

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

В этой статье поподробнее раскроем наш подход.

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

В Lamoda Tech приходят самые разные инициативы: одни коллеги просят внедрить электронный документооборот, другие — оптимизировать доставку товаров на склад. Как без погружения в их процессы понять, на что распределить ресурс?  

Проблемы в организационных процессах компании заметны не сразу. Поначалу «звоночки» кажутся случайными ошибками. 

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

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

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

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

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

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

Меня зовут Катя Назмеева, сейчас я тестирую бэк в Lamoda Tech. В статье я предложу стратегии для успешного проведения интеграционного тестирования микросервисов и расскажу про инструменты, которые могут облегчить этот процесс. Обсудим, как организовать все таким образом, чтобы интеграционное тестирование не создавало задержек в новых релизах — и не заставляло QA страдать.

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

27 июня мы собрали аналитическую вечеринку, на которой обменялись опытом, поговорили об особенностях гео-тестов, подходах к ускорению A/B-тестов, а также обсудили оценку сложных контент-продуктов.

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

Потребность в Golang-разработчиках растет с каждым годом, и наша компания не исключение. Мы постоянно ищем специалистов, а особенно рады тем, кто знает два языка — и Go, и PHP. И готовы переучивать со старой доброй «пыхи» и растить новых гоферов.

Две недели назад мы собрались в Lamoda Home, чтобы выяснить, существуют ли преимущества Go перед PHP. Серьезный спор проходил сразу на двух площадках: в зале и в трансляции митапа. Сегодня делимся материалами мероприятия. Ищите себя на фото, если были в этот день с нами!

Мы выпускаем обновления приложений Lamoda минимум 4 раза в месяц. С каждым обновлением идут серьезные изменения: новые продукты, внедрение ML-моделей и так далее. У нас налажен процесс тестирования нового кода, но есть нюанс: проверять перед релизом нужно не только новую функциональность, но и базовые возможности приложения, чтобы убедиться, что они работают корректно и ничего не сломалось. 

На проверку базового функционала уходит куча времени QA. Поэтому мы создали автоматические UI-тесты. Они автономно проверяют базовые функции и помогают снизить нагрузку на тестировщиков.

Но приложение постоянно растет, а с ним должно расти и тестовое покрытие. Главная сложность здесь — количество тестов, которое приходится писать. Когда у меня появилась задача написать очередную партию тестов, я сразу подумал о том, что мне нужна помощь. Меня зовут Марк, я iOS-разработчик из Lamoda Tech. В этой статье я расскажу, как использовал LLM для написания UI-тестов, и сравню результаты ChatGPT и Copilot.

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

В один момент тестировщик позвал на помощь дизайнера. Тот попросил тестовый телефон, протестировал всю функциональность за 10 минут и нашел пять недочетов!

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

Меня зовут Наташа Филиппова, я руководитель группы разработки в Lamoda Tech. После запуска дизайн-ревью жизнь команды разделилась на «до» и «после», поэтому в этой статье я опишу наш опыт подробнее.

Airflow в Lamoda Tech играет роль оркестратора процессов обработки данных. Ежедневно с его помощью мы запускаем 1 800+ тасок на проде, примерно половина из которых являются Spark-приложениями.

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

Меня зовут Андрей Булгаков, я лид команды разработчиков Big Data в Lamoda Tech. Вместе с разработчиком Иваном Васенковым в этой статье мы поделимся историей создания Airflow-оператора для запуска Spark-приложений.

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

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

Меня зовут Саша Рахманный, я разработчик в команде информационной безопасности в Lamoda Tech. В этой статье я сравню разные базовые образы для .NET с точки зрения безопасности их компонентов и быстродействия. 

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

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

В Lamoda Tech мы создаем продукты, которые решают самые разные задачи пользователей и бизнеса. На митапе 28 марта мы рассказали, какие ML-модели работают у нас в проде и как мы строили эту работу. 

Делимся с вами видео выступлений и презентациями.

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

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

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

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

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

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

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

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

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

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

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

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

В 2023 году мы запустили сеть розничных магазинов Lamoda Sport. Для нашей команды 1С это был по-настоящему быстрый запуск: от принятия решения до открытия первого магазина прошло всего три месяца. 

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

В этом посте делимся видео, презентациями и фото с мероприятия.

В команде исследований Lamoda Tech мы проводим интервью с пользователями: выясняем их потребности и узнаем правду о том, как они используют наши продукты. 

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

Скажу сразу — далеко не все получилось с первого раза. Но в результате эксперимента я выстроил сценарий исследования и обработал 24 интервью по фреймворку Jobs to be Done, сэкономив целых 6 дней работы!  

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

В общем, я дерзнул, и вот что понял.