Хабр, привет!

Меня зовут Стас Федянин, я ведущий инженер-программист в Контуре. Недавно завершился Advent of Code 2025 — в этом году он длился 12 дней вместо 25. Я участвовал, как и пять предыдущих лет. Созрел на эту статью, потому что подумал, что мой опыт и мнение будут интересны сообществу, ведь есть изюминка: каждый год я писал код на новом языке. Считаю, это отличный способ расширить кругозор. В статье делюсь нюансами всех опробованных языков.

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

Привет, Хабр! Я Михаил Викторов, старший инженер-программист в Контуре. В рамках одной из активностей в нашей компании возникла задача исследовать, как Low-code-платформы могут быть полезны сильным командам классических разработчиков. У меня на тот момент отношение к таким решениям было скорее скептическим, сформированным предыдущим карьерным опытом. Тем не менее, я с интересом взялся за эту тему — в частности, давно хотел посмотреть N8n вживую. В последние пару лет я регулярно сталкивался с упоминаниями этой платформы в разговорах и статьях, обычно в формате: «техническую часть стартапа можно не учитывать — за день соберём всё на N8n».

В этой статье я сознательно смотрю на Low-code с позиции code‑first разработчика – без попытки объявить визуальные платформы «злом» или «серебряной пулей». На примере двух платформ, N8n и Dify, я попробую разобраться, где Low-code действительно полезен профессиональной разработке в крупных компаниях, а где проходят границы его разумного применения.

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

С тех пор мы доработали их и разработали критерии для оценки количественных исследований.

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

Привет! Я Лера Черепанова, руковожу UX-лабораторией в Контуре. По сути, мы внутреннее агентство — подключаемся к разным командам на 1—1.5 месяца, проводим исследование и идем в следующую команду. 

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

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

Мы все привыкли писать new List<int> { 1, 2, 3, 4 } или new int[] { 1, 2, 3, 4}, чтобы инициализировать коллекции какими-то значениями. Синтаксически это выглядит похоже, но поведение отличается, и вам следует быть осторожными, если вы заботитесь о производительности.

Привет, Хабр. Меня зовут Антон Долганов, я старший iOS-разработчик в Контуре. В этой статье расскажу, куда девается мотивация, и что я делаю, чтобы её вернуть.

Недавно мы разбирали популярную задачу — проверяли строку на наличие цифр. Еще одна популярная задача при работе со строками — удалить из них пробельные символы. Можно представить, что нам нужно очистить пользовательский ввод: удалить пробелы вначале и конце строк в имени или удалить пробелы из телефонного номера. .NET предоставляет нам несколько возможностей для решения этой задачи, давайте рассмотрим самые популярные и попробуем найти наиболее эффективные. Заодно проверим, какие изменения произошли в новой версии .NET 10.

А ещё — без бюджета на мощную инфраструктуру, опыта работы в команде и прокаченных софтов.

В этой статье — путь наших студентов, которые разработали приложение для деловых знакомств на базе Python и TypeScript. Сами выбрали стек, организовали командную работу, проводили ретро, учились распределять неинтересные задачи и ошибались в оценке сложности тасков. Кому интересно почитать про нюансы создания такого проекта и что в итоге получилось, приглашаем под кат. 👇

Привет! Эта статья про ценность исследований клиентского / пользовательского опыта в таких «сложных» продуктах, как API, модули для 1С и других интеграционных решениях. 

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

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

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

Привет, Хабр. Я Катя Куваева, DevRel C#-разработчиков и инфраструктурных команд в Контуре, а это моя первая статья. 

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

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

Посмотрите, сколько разных эмоций я испытала за время общения с C#-разработчиками — и мы начинаем!

У Контура более 10 тыс сотрудников и очень-очень много групповых встреч: около 30 тыс ежемесячно, мы считали. 👀 И бывает так, что нужно собрать сразу нескольких ребят в наиболее удобное для всех время. И начинается вот это вот: зайти на страницу человечка > посмотреть, какое время у него свободно > сопоставить со своим > проверить, а могут ли в это время остальные участники > обнаружить, что нет, и идти заново по кругу смотреть другие слоты, забывая, чё там у кого. 🙄 Да блин!

Мы решили остановить эту котовасию ✋🚫 и добавить в наш внутренний портал (в Контуре используется Стафф) рекомендацию свободных слотов для всех участников встречи. Рассказываем и показываем, как реализовали это.

Это был хороший урок на будущее для нашей команды, которая новичок в геймдеве: античит-система должна быть сильнее ☝️ Даже если игроки — это клиенты твоего продукта и вообще ничего плохого не хотели 😁

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

Привет! Меня зовут Анастасия Лестова, я UX-исследователь и Product Discovery Lead в Контур.Маркировке — продукте, помогающем бизнесу автоматизировать работу с государственной информационной системой мониторинга оборота товаров. 

Моя команда ориентирована на управление разработкой на основе данных: мы оцениваем успешность фич и отслеживаем пользовательские проблемы по сигналам из метрик, менеджеры разработки управляют ресурсами также с оглядкой на процессные метрики. Разработка — отлаженный управляемый механизм, царство математически детерминированной рациональности. Но на основании чего разработка принимает решения? Да, на основании исследований, а их принято считать актом выхода в зону неопределенности, где на выручку приходят эмпатия и интуиция. Значит ли это, что исследования стихийный процесс, пользу от которого нельзя измерить, усилить и направить в нужном направлении? Вовсе нет. В статье я хочу поделиться своим подходом к оценке эффективности исследовательских процессов и степени их влияния на разработку. 

Привет, Хабр.✌️ Это Люба и Кристина, менеджеры разработки в Контуре. Кроме менеджерских дел мы ведём в Контуре настолки про Kanban.

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

Привет! Я Лера — исследователь в UX-лаборатории Контура. Часто к нам приходят продукты, в которых давно (или даже никогда) не проводили исследования. Из-за этого у команд копится большой список продуктовых гипотез, которые хочется проверить.

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

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

За последние пару лет в интерфейсах появился новый паттерн — ✨. Магическая искорка сигналит, что здесь работает ИИ. Но с маркировкой сгенерированного контента всё сложнее. Нет единого стандарта: кто-то прячет информацию, кто-то показывает крупный дисклеймер, кто-то вообще не маркирует. Я столкнулась с подобной задачей в Контуре.

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

Привет, меня зовут Ксюша Пешкина, я старший системный аналитик в Контуре. Объясняю на кетчупах 🥫🍅, как мы раньше в продукте гадали классифицировали существующие фичи по уровням (надо/не надо), а потом попробовали один крутецкий метод, который перевернул нам всё с ног на голову. 🙃 Рекомендую взять на заметку: это точно позволит вам взглянуть на ваши фичи глазами пользователей и обновить приоритезацию.