Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы 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 рекомендаций.

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

Меня зовут Максим Вишневский, я Senior Frontend-разработчик в Циан. В этой статье поделюсь историей, как наша команда реформировала подходы к тестированию: как мы отказались от 100% покрытия и unit-тестов, чем их заменили и какой получили результат. Поговорим о проблемах с Enzyme, пользе Playwright, мокинге данных для бэка и взаимодействии с QA.

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

Многие из Android-разработчиков для Dependency Injection используют Dagger или его «обёртку» Hilt. Но не многие из них используют Dagger SPI. Этот механизм предоставляет нам доступ к графу зависимостей, что позволяет нам добавить свои проверки графа и не только. В этой статье я хочу рассмотреть работу с Dagger SPI на примере поиска неиспользуемых Component Dependencies. После прочтения статьи вы сможете находить их, или при желании сможете писать свои проверки графа зависимостей. Ну или что вам там в голову взбредёт. 

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

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

Всем привет! Меня зовут Азамат, я backend-разработчик в Циан, занимаюсь поисковыми сервисами. В статье я расскажу, как мы в команде оптимизировали поиск объявлений по датам бронирования в разделе посуточной аренды. Как мы решили проблему роста потребления cpu, ускорили сам поиск и удешевили железо.

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

При разработке новой фичи приходится тратить время на создание однотипных файлов, в которых мы будем писать логику. Рутина, от которой хочется избавиться. В статье я расскажу про свой плагин  Group File Template (GFT) для создания классов из подготовленных заранее шаблонов. Настолько гибко, что подойдёт не только Android-разработчику.