Что?

Всем привет! Меня зовут Денис Ежов, я тимлид команды интернет-магазина Спортмастер (далее ИМСМ) и по совместительству бэкенд-разработчик. Так сложилось (и так говорят), что гексагональная структура и DDD — это дорого и сложно. Но так ли это на самом деле? Мы в ИМСМ внедрили гексагональную архитектуру и DDD именно в том количестве, в котором эти подходы решали наши проблемы. Про то, какие у нас были проблемы и как мы их решали, я расскажу в этом посте. Под катом — про назначение бэкенда ИМСМ, история развития бэкенда ИМСМ и его проблемы. А ещё посмотрим, как мы в новой архитектуре постарались решить проблемы бэкенда, покажем примеры кода, а также то, как код ложится на архитектуру. 

Зашёл я (@Lavs) в «Спортмастер», чтобы купить себе футбольный мяч. В этом деле мне помогла сотрудница Ксения: задала пару вопросов, отвлеклась на смартфон и через минуту протянула подходящий мячик.

Я знал, что на экране у Ксении был не мессенджер с подружками, а внутренние приложения магазина. Дело в том, что в «Спортмастер» я пришёл не только за мячиком. Хабр отправил меня с редакционным заданием: разобраться, как устроена технологическая начинка магазина.

Ребята из SM Lab (IT-компания «Спортмастера») сейчас ищут Android- и iOS-разработчиков. Под катом речь пойдёт о том, чем занимаются команды мобильной разработки: а они ни много ни мало обеспечивают работу всех 533 розничных «Спортмастеров».

Каждая компания, принимающая платежи на своем сайте или в магазине, рано или поздно сталкивается с фродом (fraud) и несет убытки. Есть разные методы борьбы с ними. 80% всех задач обычно решаются скриптами, а потом к ним уже докручивается дата-сайнс. Правда не всегда понятно для чего. Но давайте пока не будем останавливаться на этом, а попробуем решить типичные проблемы. Такие, как сбор данных, долгий этап оценки гипотез и снижение нагрузки на внешние системы.

Меня зовут Александр Сальков. Я разработчик в Sportmaster Lab. Руковожу направлением дата инженерии и больше 10 лет разрабатываю базы данных и все системы, которые так или иначе с ними связаны. Когда я был молод, написал свой вариант Кафки, который делал то же самое, что делает Кафка, только между инстансами Oracle. Участвовал во всяких разных датасаентистских вещах. В частности, делал систему идентификации людей по венам на ладонях. И много всякого интересного.

В статье предложен радиально-кольцевой метод проектирования архитектуры области (в частности - интеграционной схемы), состоящей из нескольких информационных систем, проведены общая оценка применимости этого варианта в различных ситуациях и его сравнение с классическим «макаронным» представлением. Взгляд сугубо субъективный и прикладной. Если вдруг статья привлечет очень много профессионалов – прошу придерживаться культурных о(б)суждений 😊

Как всё началось

Началось все очень просто – в норе под землей с постановки прикладной задачи, а именно: требуется разработать интеграционную схему области, состоящей из 10 информационных систем (ИС), при этом:

1. Необходимо:

• отразить все интеграционные связи каждой из 10 ИС (интеграции возможны как с ИС области, так и с ИС смежных областей (их 8));
• понимать содержание интеграционных потоков.

Привет! 24 сентября (суббота) мы в Sportmaster Lab проведем One Day Offer для системных аналитиков в онлайн-формате.

Офлайн-версии не будет, только онлайн и видеозвонки в Teams, поэтому без базового отбора желающих тут никак. Для этого мы составили небольшую анкету, в которой 11 вопросов по теме системного анализа.

В целом же механика события выглядит так:

С 5 сентября по 20 октября на Хабре проходит сезон Data Mining — конкурс технических статей для дата-сатанистов, знающих толк в оккультных практиках работы с данными.

Хабр проводит сезон вместе с SM Lab (IT-компанией «Спортмастера»). У них, кстати, открыта middle-вакансия для Data / ML Engineer.

Правила просты: вы пишете статью в хаб Data Mining и, если её рейтинг оказывается самым высоким, SM Lab отгружает вам игровой монитор и грант на написание следующего шедевра.

UPD. Сезон закончился, а подробности и победителя можно посмотреть в итоговом посте.

Привет! Хочу поделиться практическим опытом реинжиниринга нашей системы под названием «Портал поставщика» – рассказать о том, как мы выстроили процесс работы в команде, как наладили общение с бизнесом, какие поймали подводные камни и какие удалось выработать интересные решение. А ещё поговорим об особенностях китайского менталитета.

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

Так как преобладающее большинство поставщиков у нас иностранное (а в большей ее части — китайское), то и пользователи у нас в большинстве своем китайские.

Преамбула

Думаю, многие из вас сталкивались с тем, что вам в руки попадала какая-нибудь MVP-система с большим количеством legacy-кода или другими подобными вариациями, которые делались под лозунгом «Давай сейчас как-нибудь сделаем, чтобы работало, а потом разберемся».

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

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

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

У меня залежался собиравший пыль старый Motorola G5 Cedric, поэтому я решил сделать с ним что-нибудь, и теперь на нём работает веб-сервер Puma с простым веб-приложением на Sinatra.

Всем привет! Меня зовут Наталья Карпежникова, я работаю в ИТ с 2012 года, была и аналитиком, и тестировщиком, и проджектом, и лидером продукта. А сейчас в Спортмастер Лаб я все еще лидирую продукт, но большую часть времени занимаюсь развитием сообщества лидеров продуктов.

Зачем я все это пишу.

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

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

Давайте представим ситуацию, когда вам нужно установить на все виртуальные машины (агенты сервера сборки) определенный пакет Python. Но вы не можете изменить образ агента, а загрузка, к примеру из pypi.org или github.com непроверенных пакетов, ограничена. Как тут не вспомнить последние новости про вредоносные изменения в пакете nmp или более свежую информацию про PyPi.

Python использует подход под названием EAFP — Easier to ask for forgiveness, than permission (легче попросить прощения, чем разрешения). Это значит, что проще предположить, что что-то существует (к примеру, словарь в словаре, или в нашем случае модуль в системе) или получить ошибку в противном случае.

Этот подход, развитый в PEP-0302, позволяет делать хук импорта модулей, что в итоге приводит нас к возможности написания следующего кода:

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

Ну и, конечно же, список источников, где можно получить дополнительную полезную информацию. В общем, начнём.

Структура юнит-тестов

В нашей команде при написании юнит-тестов мы стараемся использовать подход AAA — Arrange, Act, Assert (Подготовка, Действие, Проверка).

Кратко расскажу о нем. Тест делится на три блока, которые идут друг за другом. Ширина блоков на рисунке выше образно отражает объём кода, который должен занимать каждый из блоков.

Раньше я считал, что компьютерная игра Factorio — это огромная трата ресурсов, сжигающая ежегодно миллиарды долларов ВВП. Мне казалось совершенно ненормальным, что Shopify компенсирует своим сотрудникам её приобретение. Я даже думал, что платить за игру в Factorio сотрудникам Shopify должен её конкурент — Amazon.

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

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

Привет!

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

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

Нарезая задачки по бизнес-ценности, мы столкнулись с двумя типами проблем:

- максимально мелко нарезанные задачи все еще большие,
- разные бизнес-задачи завязаны на общие изменения.

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

- по типу работ,
- по слоям приложения,
- выделяя базовые функции.

Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.

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

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

Эта статья для всех – кто слышал про них, но не видел, кто приступает к написанию юнит-тестов, и кто их пишет уже давно. Надеюсь, каждый из вас найдет что-то полезное для себя.

При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.

Итак, поехали.

1. Сравнение размера Вселенной в 3D
2. Измеряем богатство Джеффа Безоса в рисе

Привет! У нас в Спортмастере очень большая экспертиза в части работы с инструментами JIRA. Про доски, спринты и все прочее все наверняка знают и часто применяют. Мы хотим рассказать о других интересных плагинах, которые мы используем в рамках управления продуктом, начнем с JIRA Structure.

Зачем это нужно?

Structure — плагин для Jira, позволяющий гибко настраивать и управлять Jira-задачами любого типа.

Основные возможности:

Разработка ПО — довольно формализованная (в хорошем смысле),и активно развивающаяся отрасль, работающая с нематериальными результатами интеллектуальной деятельности. Есть лучшие практики больших компаний, есть опыт стартапов. И те и другие во многом стремятся использовать современные методологии разработки ПО, которые часто дорабатывают под себя. Ведь они обеспечивают собранность, систематизированность и прозрачность данных, помогают видеть процесс от А до Я, отслеживать эффективность и прочее, прочее, прочее.

Я не так давно пришёл в современное IT (около полугода назад), но за это небольшое время успел оценить, какую пользу приносят передовые практики управления разработкой, собственно, разработке. Я был приятно удивлен и слегка ошарашен. Настолько, что подумал — а почему бы не применить все это хозяйство к чему-то “не айтишному”? Скажем, к малому бизнесу, а именно - мелкому ритейлу товаров на маркетплейсах (МП)? 

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