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

Последние годы здорово изменили правила игры в IT-найме. Эта статья — попытка зафиксировать, обобщить наши наблюдения и сделать выводы, которые будут полезны и рекрутерам, и соискателям.

Иллюстрация Андрея Попова

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

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

Привет! На связи лид команды аналитиков Magnus Tech Владислава Никитина.

В заказной разработке каждый проект начинается со сбора бизнес-требований к будущей системе. Это важный этап, ведь именно здесь определяются контуры задач, которыми займутся разработчики. И с ним связан вечный проблемный вопрос: как лучше собрать и зафиксировать эти требования, чтобы оптимизировать разработку?

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

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

Фото до (слева) и после (справа) калибровки камеры

В первой части статьи мы немного поупражнялись на яблоках, чтобы понять, как 3D-объекты проецируются на 2D-плоскость фотографии. Заодно мы описали математическую модель камеры и ее параметры.

Знаешь параметры — живешь в Сочи можешь восстановить 3D-сцену или ее характеристики: высоту здания, расстояние до пешехода, загруженность самосвала. Словом, сплошная польза для целого ряда отраслей. 

А вот как именно определить эти заветные параметры, так и осталось за кадром. К тому же мы рассматривали простейшую модель pinhole, но в реальной жизни все сложнее. У большинства камер есть линзы, которые искажают изображения (вспомните эффект fisheye). Все эти «рыбьи глаза»‎ и другие отклонения нужно как-то корректировать.

О том, как восстанавливать параметры камеры (калибровать ее) и нивелировать искажения (дисторсию), читайте в этой публикации.

Также из нее вы узнаете:

• как выглядит математическая модель калибровки и дисторсии;

• как собрать датасет для калибровки;

• какие есть методы калибровки;

• детали одного из этих методов.

Казалось бы, жизнь невозможно повернуть назад, а предмет из фотографии не восстановишь. Хотя с последним можно поспорить: из плоского 2D-изображения реально восстановить 3D-модель объекта. Подобная «магия» часто практикуется в AR/VR, управлении беспилотниками и других сферах. Для этого первым делом производится калибровка камеры. Чтобы понять процесс калибровки, сперва следует освоить базовые принципы преобразования трехмерных координат точек в двухмерные на плоскости. 

Сегодня мы рассмотрим:

• геометрию формирования изображения на сенсоре камеры (pinhole модель);

• как рассчитываются координаты точки на сенсоре для точки из реального мира;

• как переходить от одной системы координат к другой;

• что такое внутренние и внешние параметры камеры и зачем они нужны.

У нас в гостях специалист с 15-летним опытом в Machine Learning который совмещает пару высокоуровневых должностей в разных компаниях — Head of ML в Cherry Labs и CTO в Rembrain. За полтора часа мы обсудили: позабытые ML-фреймворки и перспективы Reinforcement Learning, выяснили, какие платы с NPU лучше подходят для pet-project и зачем норвежцам роборуки.

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

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

В 2019 году (кажется, целую вечность назад), мы начали эксперимент. Решили использовать наши знания в области нейронных сетей, чтобы создать продукт для многообещающей, как нам казалось, ниши. Целью было разработать аналитическую систему для застройщиков, которая с помощью камер и нейронных сетей следила бы за происходящим на строительных площадках. У нас была гипотеза. Мы изучили бизнесы, делающие подобную аналитику. Нашли несколько зарубежных стартапов, которые получили значительные инвестиции. Естественно, мы задались вопросом: «Почему мы не можем сделать то же самое?»

И что могло пойти не так?

К нам в гости заглянул Влад Грозин — создатель ODS Pet Projects, ex. Head of Data Science из компании INCYMO, чтобы поговорить за жизнь про получение PhD в Америке и экзистенциальные риски, связанные с разработкой рекомендательных систем: пузыри рекомендаций и появление алгоритмов, которые будут предсказывать желания пользователя.

Продолжаем разбирать подходы призеров Kaggle-соревнований от американской национальной футбольной лиги (NFL). Участники этого челленджа детектировали столкновения игроков в американском футболе, анализируя данные с видеокамер и датчиков, прикрепленных к форме футболистов. В продолжении первой части статьи расскажу про самые успешные подходы к этой задаче.

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

Недавно закончилось соревнование от американской национальной футбольной лиги (NFL), которая объединилась с AWS, чтобы прокачать системы спортивной видеоаналитики.

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

В этом посте мы расскажем, как дошли до идеи отказа от использования радара при фотовидеофиксации нарушений. А также о том, как: подружили камеры с сверточными нейросетями, научили эту дружную «компанию» отличать грузовики от легковушек, точно фиксировать скорость и направление движения, а заодно засекать проезды на красный свет.

Представьте ситуацию: подходит к концу спринт, во время которого вы с командой планировали разметить десятки тысяч картинок для обучения новой нейросети (допустим, детектора). Откладывать задачи — не про вас! И вы обязались придумать способ как успеть в срок!

Сегодня я подробно расскажу:

• как развернуть CVAT — популярный сервис для разметки данных;

• как быстро и удобно предразметить датасет с помощью YOLO и FiftyOne;

• как загрузить полученный датасет на CVAT для переразметки;

• как выгрузить предразмеченный датасет обратно.

Привет, Хабр! Это команда дата-сайентистов Magnus Tech. В этом посте мы расскажем, как работали над одним общественно полезным проектом — алгоритмом, который распознает ДТП по видео с дорожных камер. Кейс будет интересен широкому кругу разработчиков, которые занимаются технологиями машинного зрения и обучения. В нем — наш долгий путь из множества попыток сделать точный алгоритм, несмотря на его настойчивые попытки быть неточным.

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