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

Привет! Меня зовут Катя Халитова, я исследователь из Контур.Фокуса. Cегодня поговорим про важное для бизнеса взаимодействие исследователей и продакт-менеджеров. Эта статья основана на десяти экспертных интервью со специалистами из ритейла, финтеха, телекома и других сфер. 

Мы затронем следующие вопросы:

– Как распределяется зона ответственности в discovery между продактом и исследователем? Есть ли чёткие рамки?

– Какие ожидания есть у продактов и исследователей друг от друга?

– Должен ли продакт валидировать исследования, когда проводит их самостоятельно? 

– Какие факторы влияют на внедрение результатов исследования?

Каждое приложение пишет множество метрик: системных (потребление CPU, памяти, очереди на диск) и прикладных (количество операций, время их выполнения, коды ошибок). Это полезная информация для отслеживания состояния сервисов в моменте и динамики за период. А что если сделать из этого продукт, который полезен для пользователей?

Привет! Мы UX-исследователи из Контура Серёжа и Маша. Этот текст — первый в серии о методах статистического анализа. 

Представьте себе ситуацию: вы замерили удовлетворенность пользователей и получили среднюю оценку в 6.5 баллов из 10. Затем вы упорно и долго работали всей командой над тем, чтобы эту оценку повысить. Через полгода вы с надеждой повторяете опрос и получаете… 6 баллов. Бизнес-начальник врывается к вам в кабинет и начинает ругаться: «Как же так?! Весь год работали, а удовлетворенность упала!».

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

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

В апреле я съездил на HolyJS. Еще до поездки в расписании конференции моё внимание привлек доклад Виктора Хомякова «Удаление мертвого кода в проекте: практическое руководство». Послушав его, я понял, что могу использовать полученные знания в своем текущем проекте, при этом не затрачивая много усилий. В этой статье я расскажу, что у меня получилось.

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

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

Каждый год 14 февраля в корпоративной соцсетке Контура лайки (реакции вида «палец вверх») превращаются в вылетающие сердечки. Анимация сердечек настолько залипательна, что способна отвлечь многих сотрудников от работы: по нашим данным они нажимают на лайк снова и снова. Дело в том, что каждый полет сердечек уникален. Давайте расскажу, как это устроено.

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

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

Привет! Я Ната из «Контур.Эльбы» — мы делаем сервис, который помогает предпринимателям вести бизнес без бухгалтера и не сойти с ума от документооборота и отчетности.

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

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

Менеджеры по развитию продукта Контура рассказывают, когда стоит внедрять искусственный интеллект в продукт. Где грань между «давайте добавим AI» и реальной ценностью для пользователя и бизнеса?

Пять лет я исследую свою родословную и уже дотянулась до 16 века: самый первый документально подтверждённый мой предок упомянут в переписной книге 1585 года.

Рассказываю, как начать — особенно если вы привыкли к системному мышлению, работе с данными и поиску информации.

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

Привет! Меня зовут Юлия Тарасенко. За 6 лет работы в Контуре я занималась созданием процессов в двух направлениях — в коммерческом продукте и в инфраструктурном направлении. Объединяет направления их масштаб — более 5 подкоманд, десятки заказчиков, а различает степень зрелости исследовательской культуры. 

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

В 90-е годы прошлого тысячелетия в стране начался бум домашнего видео. Камеры из разделов научной фантастики и редких любителей киносъемки вошли почти в каждый дом. «Я всегда с собой беру ви-идеокамеру!» — пели в заставке популярной телепрограммы.

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

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

Знакомая ситуация? Тогда, айтишник, тебе повезло — под катом ты встретишь IT-джинна, который предлагает всем, кто ждёт перемен или просто хочет развлечься, отправиться в увлекательное путешествие: испытать силы и знания в трёх направлениях работы с продуктами компании Контур. 

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

В этом тесте ты сам выбираешь, каким будет твоё приключение. А джинн подстрахует в случае ошибки. Стартуем?

В первой части своей истории я рассказал, что происходило в Контуре в момент, когда многие российские ИТ-компании попали в санкционные листы, как мы писали свой велосипед экспорт из Slack, и о том, как мы начали переезд в Mattermost. Во второй части, как и обещал, я расскажу вам самые болезненные и интересные грабли.

Можно считать эту статью второй частью в неком цикле про мои принципы в работе. В первой части я писал про какие-то неважные для меня вещи на примере code-style. Теперь логично рассказать о том, что для меня важно, про некоторые правила, которые помогают мне в работе. Это не только про написание кода, но и про процесс разработки в целом.

Полезно было бы уметь генерировать по текстовому описанию не только картинки, а полноценный 3D-объект, который можно рассмотреть со всех сторон. Это открывает огромные возможности для дизайна, игр, виртуальной реальности. Однако генерация 3D-контента — задача непростая. Современные методы требуют огромных объемов данных для обучения и страдают от несогласованности между разными ракурсами.  

Авторы DiffSplat предлагают подход, который решает эти проблемы элегантно и, что более важно, быстро! Вместо того чтобы создавать 3D-модели с нуля, создатели используют уже предобученные text-to-image модели. И просто «перепрофилируют» их для работы с 3D-гауссовыми сплатами.  

Привет, Хабр! Меня зовут Даниил Мильков, я старший C# разработчик. Сразу хочу предупредить читателей, что про взаимодействие с k8s здесь сказано достаточно мало, разве что в разделе Kubernetes и PVC. На эту тему будет отдельная статья.

Начнём. Однажды наша команда решила перейти с TeamCity на GitLab CI…