Я Ульяна Галиуллина, проектирую интерфейсы внутренних сервисов Контура. Сегодня хочу поделиться с Хабром, как на протяжении последних 10 лет эволюционировали интерфейсы нашей внутренней поддержки. А они не могли не изменяться, ведь у 12000+ сотрудников масса вопросов и проблем: с Wi-Fi, отпусками, заказом новой мебели. А еще постоянно что-то ломается и не получается :)
Привет, меня зовут Владислава, я UX-исследователь в Контуре в направлении Недвижимость. Мы создаем решения для застройщиков и риелторов. Например, в портфеле направления есть сервисы для электронной регистрации прав собственности в Росреестре и проверки юридической чистоты сделок.
В этой статье расскажу, как мы выстроили процесс анализа успешности решения. Если вы из раза в раз задаетесь вопросом: «А не фигню ли мы сделали?», но не знаете, как это можно проверить — эта статья для вас.
Я Илья Мезенцев, 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? И можно ли лучше?
