Привет, Хабр! Меня зовут Нияз Кашапов, я AppSec Lead в Купере. Недавно я рассказывал на ecom.tech Information Security meetup, как выстраивается процесс написания безопасного кода и разбора срабатываний статических анализаторов. Эта статья — изложение моего выступления с дополнительными комментариями. Я опишу подход, к которому мы пришли, и открою секрет, как мотивировать разработчиков смотреть свой код на безопасность.
Привет, читатель!
Меня зовут Дмитрий Евсюков, я работаю в Купере старшим специалистом по тестированию. Когда я только пришёл в свою команду, то всё тестировал руками и не мог найти время на автоматизацию. Это приводило к тому, что я не успевал протестировать все задачи в полном объёме и многое откладывалось в техдолг. Сейчас я выработал более умный подход, который помогает мне своевременно разрабатывать автотесты и быстро поставлять функционал на прод без снижения качества.
Привет, Хабр! Меня зовут Матвей, я staff-инженер по автоматизации тестирования в компании Купер (кто это такие — можете почитать в статье). Сегодня хочу остановиться на ключевых трудностях, которые ставит перед тестированием микросервисная архитектура, и рассказать, как мы в компании справляемся с этими вызовами с помощью экспериментальных подходов.
Всем привет! Меня зовут Паша Стороженко, я продуктовый дизайнер в Купере. С конца 2023 года наша команда отвечала за направление аптек и достигла неплохих показателей. В этом году нам предложили взять еще одно направление — бытовую технику и электронику.
Прежде всего, нам нужно было разобраться, как устроен этот рынок, как клиенты выбирают магазин, товар и способ его получения, какие сложности у них возникают. Другими словами — провести дискавери направления. А так как раскачиваться по полгода не в наших правилах, мы активно взялись за дело.
Привет! Меня зовут Влад, я QA в Купере. Как и многие тестировщики я выпускал баги в прод — нужно это принять, простить и пережить. В идеале, следующим шагом выстроить кросс-командное взаимодействие так, чтобы этого больше не повторилось. У нас в Купере есть регламент по заведению багов. Хочу поделиться ключевыми идеями оттуда — уверен, они будут многим полезны.
Привет, Хабр! На связи Марина Гончарова. Сейчас я занимаю роль старшего менеджера проектов в Купере и работаю над задачами, которые затрагивают по несколько подразделений сразу. Но до этого я долго была проджектом в кросс-функциональных командах.
В этой статье я поделюсь мыслями о том, зачем тимлиду отказываться от кодинга, могут ли котов пасти другие звери и почему тимлидство — это не карьерный рост для разработчика.
Дисклеймер: всё, о чём я пишу далее, — моё личное мнение, основанное на десяти годах в менеджменте. Если у вас другой опыт, буду рада обсудить его в комментариях.
Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер». В перой части статьи я уже рассказывал, какими задачами занимаются стаффы и какие компетенции для этого нужны. Сегодня хочу поговорить о том, как развиваться синьору, чтобы получить почетное звание стаффа. Для того, чтобы написать эту статью я провел 10 интервью со своими коллегами стафф-инженерами — их опыт вместе с моим личным и стали основой этой статьи.
В статье разберем: как происходит рост в staff-инженера, с каким трудностями в процессе роста вы столкнетесь, поделюсь рекомендациями от наших staff-инженеров по мотивации. Приступим!
Привет! Меня зовут Дима Салахутдинов, я principal-инженер в Купере и автор tg-канала «Стафф-инженер». У нас в компании это один из грейдов технической ветки развития инженеров, которую мы обобщенно именуем «Staff-инженер».
Цель статьи — сформировать у senior-разработчика общее представление о роли стафф-инженера, как об одном из направлений карьерного роста. А также дать практические советы, что прокачивать, на случай, если описанные трудности вас не отпугивают.
Статья будет состоять из двух частей, в этой части разберем, чем занимаются стафф-инженеры, и что вас ожидает в этой роли. Приступим!
Микросервисная архитектура — это новый черный: кажется, уже все бигтехи пилят монолиты на сервисы и и ищут гошников в штат. Спрос рождает предложение — всё больше ребят переходят с других бэкенд-языков на Golang.
Мы попросили наших разработчиков поделиться своим опытом перехода на Go и рассказать, почему они решили освоить новый язык программирования, какие плюсы и минусы видят в нём, дал ли переход на Go буст в новых карьерных возможностях и кому и в каких случаях они бы они советовали освоить golang.
Эта статья может быть полезна тем, кто тоже хочет добавить Go в копилку знаний, но пока не решился. Приступим!
Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис.
Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!
Привет, Хабр! Меня зовут Марина, я QA-инженер в Купере. Как специалисту по тестированию, мне часто приходится сталкиваться с задачами, связанными с тестированием микросервисов, использующих асинхронное общение через Apache Kafka. Уверена, многие QA-инженеры, да и разработчики знакомы с подобными вызовами.
На одном из проектов, где я работаю, у меня возникла проблема: используемые инструменты для тестирования Kafka были недостаточно удобными:
Консольная утилита Protokaf не имеет интерфейса и полученные данные для лучшей читаемости нужно отформатировать в json структуру (а это еще одно доп приложение).
UI-приложение Kowl удобно только для мониторинга состояния топиков, и только недавно в нём стала доступна возможность чтения сообщений без сложного флоу для расшифровки, но всё так же нет возможность отправки сообщений в топик.
В поисках более удобного решения коллега посоветовал Plumber — графическое приложение, с возможностью коньюмера и продюсера сообщения.
В этой статье я не буду объяснять, что такое Kafka и как работают брокеры — на эти темы уже есть множество отличных материалов, например, вот. Хочу поделиться своим опытом использования этого инструмента. Я не ставлю цель сравнивать его с другими существующими решениями, а просто расскажу, как Plumber помог мне упростить процесс ручного тестирования Kafka на стейджах.
Привет! Меня зовут Юрий, я старший разработчик в Купере в команде Ruby Platform, занимающейся разработкой внутренних библиотек, инструментов мониторинга и поддержки микросервисов.
У нас в Купере более 200 микросервисов на разных стеках, а также монолиты. С точки зрения инфраструктуры интеграционное тестирование такого количества компонентов - довольно затратная задача, но при этом хочется обеспечить стабильность системы, не проводя ручные интеграционные регресс-тесты. В таких условиях оптимальным решением являются контрактные тесты.
Из данной статьи вы узнаете:
- общий принцип работы контрактных тестов;
- о проблемах, с которыми мы столкнулись при внедрении контрактного тестирования и как их решали;
- как мы разработали свое решение для контрактного тестирования Ruby-приложений;
- о настройке CI/CD для автоматизации контрактных тестов.
Материал будет полезен тем, кто задумывается о повышении надежности интеграций между сервисами и внедрении контрактных тестов в свои проекты.
Всем привет! Меня зовут Роза и я MLOps-инженер в Купере. Под катом расскажу, как построить CI/CD-пайплайн для ML-приложений с нуля, поэтапно и без боли. Ну почти :)
Раньше очень часто работа DS-инженера заканчивалась на подготовке кода модели в Jupyter-ноутбуке, а дальше его подхватывали команды разработки и доводили до продакшена. У такого подхода есть минусы. Например, если произойдёт инцидент, непонятно кто ответственен за сервис — команда разработки или авторы ML-модели?
К счастью, культура разработки меняется: теперь ML-инженер — это специалист, который разрабатывает свой ML-сервис на всем пути от общения с бизнесом до продакшена. Этот подход хорошо описывает принцип «you build it, you run it»: кто построил модель, тот её и запускает. Как раз в этом здорово помогает CI/CD.
Привет! Меня зовут Юрий Беляков, я старший ML-инженер в Купере. Сегодня предлагаю вместе разобраться, что такое плановая доставка и как устроен алгоритм управления слотами в Купере. Обсудим, как проходило тестирование и масштабирование от одного магазина до всех гипермаркетов, на какие грабли мы наступили и как на той же базе реализовать динамическое ценообразование.
Наверняка вы за собой замечали, что иногда какую-то задачу настолько не хочется делать, что курсор мыши сам выпрыгивает из IDE, а пальцы отбивают на клавиатуре «YouTube — шортсы с котами». Возможно, вы пытались разобраться, почему же так?
А вы точно пытались — на Хабре написано аж 39 (!) страниц статей по запросу «прокрастинация».
Меня зовут Арина, я работаю продуктовым аналитиком в Купере. Поделюсь тем, как сама боролась с прокрастинацией, а в результате узнала о СДВГ, получила диагноз, полюбила его и научилась с ним жить. Расскажу об СДВГ в целом и о своем опыте выживания в IT с таким мозгом.
С помощью поддержки и просвещения можно прийти к пониманию, что у СДВГ помимо минусов так же много и плюсов, и в мире много успешных людей с этим диагнозом. Например, чемпион мира по плаванию Майкл Фелпс, основатель IKEA Ингвар Кампрад, основатель корпорации Virgin Group Ричард Брэнсон, основатель JetBlue Девид Нилеман, режиссерка «Барби» Грета Гервиг, актеры Том Круз, Орландо Блум, Зоуи Дешанель, Эмма Уотсон и еще многие другие люди с этим диагнозом живут и строят успешные карьеры.
Многие из них, если речь заходила про СДВГ, говорили, что в конечном итоге это стало их сильной стороной. Ведь на самом деле это не про отсутствие самодисциплины или лень, а просто про другой механизм работы мозга. И если знать, что с этим делать, то все сложности можно нивелировать или даже обратить себе во благо.
Эту статью я пишу для всех, кто испытывает слжности с прокрастинацией. Методики, о которых я расскажу точно могут быть полезны и для вас, даже если ваш случай не такой клинический.
Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.
Дисклеймер: понимаю, что тема холиварная, и с точки зрения строгой методологии нужно выбрать между оценкой по времени или по сторипоинтам и не пытаться поженить одно с другим. У нас в компании допустимы разные варинты и я, как тимлид, очень рад, что такие решения даются на откуп юнитов и отдельных команд — можно настроить процессы под свою команду и свои задачи.
Здесь хочу поделиться своей логикой и тем, как искал аргументы, чтобы реализовать свой эксперимент. Любые менния по теме приветствую в комментариях.
Привет! Я Максим Коровенков, DevSecOps Lead в Купере (ex СберМаркет). Хочу поделиться мыслями по поводу минимально необходимого набора процессов, сопутствующих внедрению сканеров безопасности в пайплайны разработки.
В результате попытаюсь ответить на вопрос: «А что, собственно, стоит иметь в виду под фразой “Мы внедрили сканеры безопасности в пайплайны разработки”?»
Да, в тысячный раз про пайплайны, но, как вы, думаю, догадываетесь, желание поделиться казалось бы очевидными мыслями появилось не случайно! Не так давно я завершил найм и укомплектовал свою DevSecOps-команду. В рамках поиска пришлось провести достаточное количество интервью, на которых я любопытствовал, как обстоят дела у соискателей с пайплайнами безопасности на текущем/предыдущем месте работы. Это удивительно, но для 90% респондентов фраза «внедрение сканеров безопасности в пайплайны» означает только факт внедрения. Лишь некоторые кандидаты упоминали отправку результатов в VMs/ASOC систему.
Ведь действительно кажется, что все просто: запаслись вокабуляром из нескольких аббревиатур, внедрили инструменты, SAST, SCA, может что-то еще, настроили отправку результатов для AppSec-ов и, как-будто, можно идти бить баклуши. Но я на своем опыте убедился, что DevSecOps — это про глубокую проработку процессов. Поэтому в данной статье сконцентрируюсь больше на процессах, нежели на технике.
Предлагаю наконец переходить к сути!
Привет всем! Меня зовут Таня Конюшенко, и я — продуктовый дизайнер в Купере. В этой статье я рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в моей продуктовой команде. Мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.
Ещё год назад я ничего не знала о Discovery, потому что работала в заказной разработке. О том, в чем разница между дизайнерами в агентстве и продукте, рассказывала в своей прошлой статье.
Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…
Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?
Чтобы нанять хорошего инженера, недостаточно проверить только его харды. В статье я расскажу о трех софт-скиллах, которые я обязательно проверяю у каждого кандидата. Если вы начнете проверять эти три навыка, вы начнете нанимать лучших специалистов. А еще я расскажу обратную, темную сторону каждого из качеств.
Меня зовут Олег Федоткин, я программист и менеджер в ИТ. Я провел более сотни собеседований (мне HR даже толстовку «Hiring Hero» по такому случаю подарили) и нанял десятки человек: программистов, тим лидов, юнит лидов, архитекторов — да всех. После всех интервью я выделил три качества, которые неизменно определяют классного специалиста.
