«А там точно нет закладок?» — чтобы точно ответить на этот вопрос про любую железку иностранного происхождения, рано или поздно надо сделать её самому. Так появились процессоры «Эльбрус». Несмотря на то, что они далеко не такие современные, как могли бы быть, они всё чаще появляются не только в прессе, но и на практике. Мы взяли сервер на «Эльбрус-8С» у партнёров из «НОРСИ-ТРАНС» и протестировали его под нагрузкой для оценки использования в реальных задачах. Цель — понять, сможем ли мы в разрезе 15 лет использовать эти ядра для производств (это тех самых, где АСУ ТП оркестрирует Пентиум II MMX). 

Сразу скажу главное: в расчёте на процессорный такт они либо равны, либо немного превосходят процессоры Intel на целевых задачах — во многом из-за архитектуры VLIW (а не RISC). Но вот только частоты у них существенно меньше, конечно. Существенно — это не в два и не в четыре, а в разы. То есть рыночная перспектива у них основана на «ящиках» (то есть закрытых компаниях). Доступа к новейшим технологиям производства процессоров в стране нет, поэтому ситуация такова. Но прогресс возможен.

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

Любому бизнесу, особенно крупному, хочется максимально оптимизировать внутренние процессы. В частности, те, которые касаются ИТ. Довольно часто мы встречаем ситуации, когда сугубо цифровые задачи в силу устаревших регламентов или страха сломать работающую систему решаются по старинке, вручную.

«Ингосстрах» обратилась к нам со следующей задачей: из-за огромного количества «ручных» операций параметр time-to-market их цифровых продуктов в некоторых случаях был достаточно высоким. Это не устраивало никого: ни разработчиков, ни тестировщиков, ни бизнес. Требовалось как можно сильнее сократить time-to-market, не стесняясь в ресурсах и средствах.

Если обычные разработчики ходят на собеседования тренироваться и набирать опыт, то я пошёл выписывать все косяки. Чтобы их не было у меня, потому что я нанимаю людей. Собственно, стало интересно, как устроено в других компаниях — и я пошёл собеседоваться. Началось всё c базового набора: аккаунт зума, почта, резюме. Дальше можно пройти за неделю 10-12 собеседований, на что до тотальной удалёнки ушёл бы месяц.

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

Выложил на HH. Дальше ждать пришлось недолго. Первый час — уже несколько откликов и звонок. Всего за сутки было 20 откликов и пять звонков. Предложений много, все с самыми интересными проектами, стеком, ДМС и макбуком (которого пока нет, но обязательно пришлём через месяц-два).

На третий день я набрал примерно 30 проектов, которые были бы мне интересны, если бы я действительно искал работу (пост бы неожиданно закончился здесь, если бы нашёл что-то более интересное, чем уже есть), и начал описывать то, что попало в отсев.

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

Что общего между Крымским мостом и СКС? Мы случайно выяснили: для железнодорожной части этого моста потребовалось 76 000 шпал. И примерно столько же оптических волокон в нашей СКС, построенной для банка «Открытие». Под катом рассказываю, как мы ее делали и тестировали (и даже немного о том, зачем на проекте понадобился маляр). 

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

Чтобы упростить работу техподдержки, команда из нашего акселератора разработала автоматизированную систему на базе машинного обучения. Она запускается за 2 дня без подготовки и без помощи специалистов по data science. Подробности под катом.

Всем привет! Я CV-разработчик в КРОК. Уже 3 года мы реализуем проекты в области CV. За это время чего мы только не делали, например: мониторили водителей, чтобы во время движения они не пили, не курили, по телефону не разговаривали, смотрели на дорогу, а не сны или в облака; фиксировали любителей ездить по выделенным полосам и занимать несколько мест на парковке; следили за тем, чтобы работники носили каски, перчатки и т.п.; идентифицировали сотрудника, который хочет пройти на объект; подсчитывали всё, что только можно.

Я все это к чему?

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

Моделируем ситуацию

Представим, что мы устроились в молодую компанию “N”, деятельность которой связана с ML. Работаем мы над ML (DL, CV) проектом, потом по каким-либо причинам переключаемся на другую работу, в общем делаем перерыв, и возвращаемся к своей или чужой нейроночке.

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

Привет Хабр! Меня зовут Когунь Андрей. В КРОК я руковожу группой разработчиков Java (у нас большая распределённая по всей стране команда). Ещё я провожу встречи московского сообщества Java разработчиков JUG.MSK. Делаю это исключительно в корыстных целях: фотографируюсь там со всеми докладчиками, и однажды открою галерею с самыми интересными людьми в мире Java-разработки. Также помогаю делать конференции для разработчиков: JPoint, Joker и DevOops — в качестве члена программного комитета. Ну и для души, так сказать, преподаю Java-технологии студентам.

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

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

Что сейчас меняется на производствах?