Чем больше микросервисов в компании, тем веселее жизнь у тех, кто отвечает за безопасность. Количество зависимостей растёт, и в какой-то момент становится нереально уследить, откуда в коде может вылезти критичная уязвимость — будь то старая библиотека или транзитивная зависимость, о которой никто даже не помнит.

Решение этого — SCA (Software Composition Analysis) автоматический анализ зависимостей, который помогает вовремя вылавливать уязвимые библиотеки и понимать, что с ними делать.

Меня зовут Эрик Шахов, я AppSec-инженер в Циан. В этой статье расскажу, как мы перестроили систему SCA, изменили её архитектуру и какие инструменты теперь используем для контроля зависимостей. Поделюсь реальным опытом внедрения SBOM (Software Bill of Materials) и тем, как он помогает нам держать код в порядке.

Привет! Меня зовут Кирилл Сергеев, я ML-инженер в Циане. В этой статье я расскажу, как мы решили задачу дедупликации объявлений о недвижимости, разработав систему на основе трёх моделей. Эта система автоматически находит и объединяет дублирующиеся объявления, помогая пользователям видеть только актуальную и уникальную информацию.

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

Оркестрация процессов в Apache Airflow — мощный инструмент для управления данными. Но как внедрить его так, чтобы процессы стали прозрачными, гибкими и удобными для команд? Как организовать ETL-пайплайны, чтобы они легко масштабировались и адаптировались под нужды аналитиков, ML-инженеров и других специалистов?

Меня зовут Любовь Марисева, я инженер дата-платформы в Циан. Мы разрабатываем десятки ETL-процессов, обеспечиваем данными разные команды и постоянно ищем способы сделать работу с Airflow эффективнее. В этой статье я расскажу, как мы решили ключевые проблемы, сделали расчёты более управляемыми и упростили взаимодействие между командами.

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

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

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

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

Тема преимуществ открытых табличных форматов при работе с озерами данных всё чаще поднимается в среде дата-инженеров. Предполагается, что их использование способно устранить недостатки популярного Apache Hive. Но так ли это на практике?

Меня зовут Иван Биленко, я инженер данных в команде дата-платформы Циан. В этой статье я хочу немного познакомить вас с процессами и стеком внутри нашей платформы, рассказать, почему мы решили попробовать Iceberg, с какими проблемами столкнулись при тестировании и какие преимущества Iceberg может дать тем, кто еще только задумывается о переходе. Дисклеймер: статья носит обзорный характер.

Быть тимлидом — это как управлять оркестром, где каждый инструмент должен звучать в нужный момент. Но что делать, когда ты становишься дирижёром в новом оркестре, где не всегда понятно, кто за что отвечает, и ты даже не знаком с музыкантами? В таких ситуациях, важность адаптации сложно переоценить.

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

Знаете, что объединяет всех iOS-разработчиков, работающих над крупными проектами? Все мы когда-то сталкивались с этим старым знакомым — файлом .xcodeproj, который хранит в себе десятки, а то и сотни конфликтов после каждого merge. Мы тоже жили с этой проблемой много лет, пока не нашли решение.

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

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

Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы TOGAF и отличия Raft от Paxos — это хорошо, но мало. Вы должны принимать решения не только исходя из технических деталей задачи, но и с учётом реалий бизнеса, его потребностей и направления развития.

Меня зовут Олег Федоткин, я СТО компании Циан. В этой статье расскажу, почему понимание бизнеса так важно для ИТ-менеджеров, тимлидов и архитекторов, и как оно влияет на принятие технических решений и развитие карьеры. Больше и чаще на подобные темы я пишу в свой ТГ-канал «Инженер и Менеджер».

Кому будет полезна статья:

Менеджерам в ИТ: тим-/юнит-лидам, руководителям направлений и СТО. Без понимания бизнеса у вас не получится построить карьеру — это аксиома.

Специалистам выше уровня senior: staff-/principal-инженерам и архитекторам для выработки полезных для компании технических решений.

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

Меня зовут Саша Киверин, я лид Python-гильдии в Циан. Сейчас в нашем сообществе более 60 разработчиков. За последние 2 года мы совместными усилиями сделали целый ряд крутых проектов. Перевели монолит с версии Python 2.7 на 3.12, создали библиотеку для внешних вызовов и внедрили автоматический чеклист здоровья микросервиса. Дотащить все это до прода нам помогли 5 простых советов, которыми я и поделюсь в этой статье. Надеюсь, они помогут оживить и вашу гильдию. 

Знакома ли вам ситуация, когда вы спокойно работаете, а клиентская служба передаёт вам странный репорт: несколько пользователей жалуются, что в приложении не грузятся картинки, но у вас всё работает. Или пользователь пишет в Google Play, что приложение занимает несколько гигабайт, и вы не понимаете, сколько таких пользователей и что с этим делать. Нужно ли срочно бросаться чинить, или это может подождать следующего планового релиза?

Согласитесь, было бы здорово узнавать о проблемах раньше, чем пользователи начнут жаловаться в поддержку. Сегодня я расскажу, как мы в Циан создавали Техническую Мобильную Аналитику (ТьМА) и получили возможность в любой момент времени ответить на вопрос: «Всё ли в порядке с приложением?»

Backend Driven UI (BDUI) — это подход, при котором сервер управляет не только данными приложения, но и формирует интерфейсы, включая экраны, верстку, реакции на действия пользователя и переходы между экранами. Клиентская часть сводится к рендерингу интерфейсов на основе полученных с сервера данных.

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

На бумаге такие идеи кажутся идеальными, иногда даже «серебряной пулей». Однако на практике всё не так однозначно, и многое зависит от конкретного кейса. В этой статье я поделюсь опытом нашей компании, расскажу о нюансах, которые позволили нам извлечь пользу из BDUI, и представлю рабочий инструмент. Мы использовали нестандартные подходы, которые, надеюсь, вдохновят вас. Похоже, что для нас BDUI — это скорее удовольствие, чем боль. Давайте разберёмся, как нам это удалось!

Привет, Хабр! Я Александра Микелова, лид исследователей B2C-аудитории в PropTech-компании «Циан» и преподаватель на курсе «UX-исследования для дизайнеров» в Яндекс Практикуме. Сегодня расскажу о таком методе, как конфликтное интервью, чем оно отличается от классического глубинного и какие данные можно получить с его помощью.

Я — Саша Микелова, руководитель исследователей B2C-аудитории в Циан и преподаватель в Практикуме. Занимаюсь исследованиями уже 10 лет. Когда я только пришла в профессию, UX-исследований не делал практически никто. Индустрия развивалась за счёт исследований маркетинговых, основной целью которых было понять, как лучше позиционировать продукт (чаще FMCG — Fast Moving Consumer Goods, то есть товары повседневного спроса) на рынке. Но со временем стала развиваться IT-индустрия, появились новые приложения и, как следствие, стала расти конкуренция. В условиях, когда одну и ту же задачу пользователя могут решить несколько продуктов, важно уже не только само решение задачи, но и то, как именно это делается: фокус перешёл на пользовательский опыт. Сейчас представить разработку любого продукта или фичи без исследования — невозможно. Только получая обратную связь непосредственно от пользователей, можно создать продукт, попадающий аудитории в сердечко.

Доброго времени суток, дорогой читатель. Меня зовут Михаил, я Android-разработчик в компании Циан. Этой статьёй я открываю для себя цикл статей по внутренней кухне разработки плагинов для Jetbrains IDE: IDEA, Android Studio (AS) и пр. На дворе 2024 год, официальная документация не так богата информацией, как хотелось бы. Но есть исходники, которые смело можно дербанить. В этом цикле статей я буду описывать свой опыт поиска нужной мне информации и её разбор.

В компании Циан (где я, Клюшев Александр, и работаю в роли ML-инженера) проводятся внутренние хакатоны, и один из таких проходил в начале лета 2023. Достаточно давно в компании обсуждали идею по реализации поиска объявлений через текстовую строку, и было принято решение эту идею воплотить в жизнь. В статье я расскажу, как выглядит флоу поиска, какую мы использовали модель и какие результаты получили.

Всем привет! Меня зовут Анатолий Барцев, я frontend-разработчик в команде Модерации Циан. Я решил протестировать Copilot, чтобы оценить, полезен ли он для реальной разработки. В статье расскажу, какие выделил для себя плюсы использования, а также покажу, как GitHub Copilot помогает в разработке на примере проекта на React/Typescript.

Давайте в общих чертах рассмотрим вопросы взлома и защиты Android-приложений. 

В рамках статьи нас интересуют сами процессы взлома и защиты, а не конкретные методики работы с конкретными инструментами. Поэтому разберёмся с этими процессами и постараемся сделать выводы. Чтобы читать было интереснее, я решил попеременно ставить себя и на место нападающего, и на место защищающего приложение человека. Что-то вроде шахмат: сначала ход делает нападающий, а затем защищающийся. Пока кто-то не победит. Пройдём путь, постепенно наращивая сложность, от простого вроде HTTPS — к более сложному, вроде обфускации и деобфускации, изменению поведения. И под конец перейдём к C++ и просмотру его Assembler кода.

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

Привет! Я Саша, тимлид одной из команд первичной недвижимости в Циан. Мы активно используем данные для принятия управленческих решений. Не только продуктовых, но и при управлении командами разработки. В статье я расскажу, как это устроено у нас в компании, и покажу на примере своих метрик, как это можно использовать у себя.

На первый взгляд может показаться, что ничего интересного в области RecSys не происходит и там всё давно решено: собираем взаимодействия пользователей и товаров, закидываем в какую-нибудь библиотеку, которая реализует коллаборативную фильтрацию, и рекомендации готовы. В то же время практически все остальные разделы машинного обучения перешли (NLP, CV, Speech) или экспериментируют (TimeSeries, Tabular ML) c нейросетевыми моделями на базе трансформеров. На самом деле, рекомендательные системы — не исключение, и исследования по применению трансформеров ведутся уже достаточно давно.  

Мы в команде ранжирования и рекомендаций, стараемся не отставать от последних достижений в области RecSys. Меня зовут Дима, я Data Scientist в Циан, и сегодня хочу поделиться нашим опытом использования мультимодальных трансформеров для content-based рекомендаций.