Я Илья Мезенцев, ML разработчик в Контуре. Расскажу о том, как мы в DS-команде создавали единую схему всех своих решений. Статья для DS-специалистов уровня senior/lead, которые отвечают за проекты целиком.

Мы сделали гайд для создания user-friendly интерфейсов. Он будет полезен не только новичкам в UX-исследованиях, но и опытным исследователям, аналитикам и проектировщикам.

Про no-code говорят уже больше 40 лет, но в этом подходе до сих пор остаются существенные пробелы. Поделюсь своим видением в статье. Меня зовут Даниил Мясников, я руковожу в Контуре функциональными зонами на P –– Python, PHP, Perl.

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

Привет, Хабр! Меня зовут Женя Мельцайкин, я работаю в команде мобильной разработки Контура.

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

В статье расскажу, как мы сделали кнопку по проведению жеста свайпом на Jetpack Compose, чтобы избежать случайной подписи документа.

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

Мы проводим летние стажировки в Центре ИИ 6 лет. С 2018 года 80% принятых на стажировку остались с нами после ее окончания. А 60% из них – работают до сих пор и обучают новые поколения стажеров.

В этой статье расскажу, что мы делаем, чтобы стажировка приносила команде пользу.

Меня зовут Настя Миронова, я менеджер разработки в Контуре и уже около двух лет  руковожу командой Рейнджеров – это разработчики без своего продукта, такие мобильные инженеры. Команда появилась в конце 2020 года, и за это время мы постоянно исследуем, чем можем помочь проектам компании, как делать это еще лучше, и как вырастить или найти ребят, постоянно готовых к вызовам.

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

Об этом и расскажу в статье с примерами коллег.

Давным-давно, во времена, когда по Земле бродили цифровые динозавры, а разработчики .NET ещё помнили, зачем нужна технология WebForms (и какие у неё были проблемы с производительностью), в Контуре появился продукт под названием Фокус, предназначенный для проверки контрагентов. И у этого продукта довольно быстро появился API, ориентированный на крупных клиентов.

ASP.NET MVC был ещё в новинку, до появления WebAPI оставались годы, и отцы-основатели проекта приняли вполне актуальное, с учётом реалий того времени, решение: делать API на базе ashx-хендлеров, чтобы максимально повысить скорость работы.

Шли годы, .NET Framework сперва меняла версии как ветреная красавица перчатки, а потом и вовсе перешла в разряд «для поддержки жизнедеятельности требуется опытный некромант», .NET Core сперва появился, а потом благополучно переименовался в просто .NET, дорос до 6-й, а потом и 7-й версии… а API Фокуса всё ещё жил по старому, доброму принципу «работает — не трогай». И вот, наконец небосвод провернулся, и звёзды сошлись в нужной позиции. Мы поехали на .NET 6.

Оговорюсь сразу, что сам переезд произошёл примерно полгода назад, когда .NET 8 ещё находилась в стадии альфы. Именно поэтому в качестве целевой версии .NET была выбрана именно стабильная 6-я. Тем не менее большинство проблем будут актуальны и при миграции на 8-ю версию.

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

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

Приветствую. Меня зовут Устюжанин Игорь. Мне довелось поработать в разных ролях при разработке ИТ-продуктов - от инженера-программиста до руководителя продукта. Этот опыт я получил в компании СКБ Контур, куда пришел разработчиком аж в 1999 году, будучи студентом 4-го курса.

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

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

На этот раз длинная история. Но длинная она в основном из-за множества примеров, которые вы можете легко повторить у себя.

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

Ходят слухи, что foreach быстрее for. А ещё ходят слухи, что for быстрее foreach. Пора разобраться, что быстрее!

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

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

Конвейер трудится изо всех сил, чтобы повысить производительность твоей программы. А злобные «if»'ы нагло врываются посреди его работы и всё портят!

На сколько полезен конвейер в современных ЭВМ? Как сильно мешаются ветвления в коде, которые ты написал? И как архитекторы процессоров сглаживают ущерб, который «if»'ы наносят по производительности программ?

SLO — это практика, входящая в состав SRE-методологии, которая помогает найти баланс между скоростью развития сервиса и его надёжностью.

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

Современные процессоры очень круты. Они таят в себе великое множество секретов и невероятных возможностей. И просто восхитительно, что некоторые из способностей процессоров легко продемонстрировать даже из такого высокоуровневого языка, как C#, буквально за десять строчек кода!

А вы никогда не задумывались, что async и await выглядят как-то инородно среди прочего C# кода? Больше нигде не встречается такого странного синтаксиса и таких модификаторов, кроме как в методах, работающих с Task и Task<T>.

А ещё интересно, сколько вообще стоит пользоваться async/await? И когда можно (нужно?) обходиться без них?

А вы никогда не задумывались, что yield return выглядит как-то инородно среди прочего C# кода? Больше нигде не встречается такого странного синтаксиса и такой инструкции, кроме как внутри методов, возвращающих перечисление.

А ещё интересно, сколько же на самом деле стоит перечислять элементы с помощью yield return? И можно ли лучше?

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

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