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

А что если поделиться этой годнотой с сообществом и выложить этот файлик на гитхаб? Тогда ваши труды могут быть полезны еще кому-нибудь, а поддерживать актуальность можно совместно, принимая обновления от желающих через старые добрые PR'ы. Именно для этого предназначен проект Awesome lists. Он входит в ТОП-10 репозиториев гитхаба, обладает 138К звезд, и ссылка на ваши труды может оказаться прямо в его корневом README, что привлечет огромную аудиторию к вашему творчеству. Правда, для этого придется немного постараться. О моем опыте таких стараний хочу поделиться с вами.

Меня зовут Максим Грамин. В КРОК занимаюсь Java-разработкой и исследованиями в области БД. В этом посте я расскажу, что такое Awesome Lists и как сделать свой настоящий официальный awesome-репо.

Похоже, власти прислушались к жалобам бизнеса на неудобные законы и приняли закон об экспериментальных правовых режимах в сфере цифровых инноваций (Федеральный закон от 31.07.2020 № 258-ФЗ). По сути государство говорит нам: «Вам не нравится действующее регулирование? Окей, придумайте свои законы, которые вас устроят. Мы на время сделаем их обязательными для вас и других желающих и посмотрим, как они работают. Если эксперимент пройдет хорошо, то сделаем из вашей идеи полноценный закон, обязательный для всех».

Давайте рассмотрим, кому от нового закона станет удобнее и в чем его особенности.

Поехали!

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

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

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

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

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

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

Задумывались когда-нибудь, что делает сканер с VDI-станцией? Сначала всё выглядит хорошо: он пробрасывается как обычное USB-устройство и «прозрачно» виден с виртуальной машины. Дальше юзер даёт команду на сканирование, и всё к чертям падает. В лучшем случае — драйвер сканера, похуже — через пару минут софт сканера, потом может поаффектить и других пользователей кластера. Почему? Потому что, чтобы получить пятимегабайтную сжатую картинку, нужно отправить через USB 2.0 на два-три порядка больше данных. Пропускная способность шины 480 Мбит/с.

Так что тестировать надо три вещи: UX, периферию и безопасность — обязательно. Есть разница, как тестировать. Можно установить агентов локально, на каждой виртуальной рабочей станции. Это относительно бюджетно, но не показывает нагрузку на канал и не совсем верно считает нагрузку на процессор. Второй вариант — развернуться в другом месте нужным количеством роботов-эмуляторов и начать их коннектить к реальным рабочим местам как настоящих пользователей. Добавится нагрузка от протокола передачи видеопотока экрана (точнее, изменённых пикселей), разбор и отправка сетевых пакетов, будут понятны нагрузки на канал. Канал вообще очень редко проверяется.

Привет, Хабр! XR-разработкой я занимаюсь около семи лет: проделал путь от младшего специалиста до директора бизнес-юнита КРОК Иммерсивные технологии. Моя команда уже более пяти лет создает XR-продукты для промышленности. За это время наш небольшой отдел превратился в целое направление в ИТ-компании, создав проекты для таких гигантов, как Saudi Aramco, «Сибур», «Газпром нефть», «Росатом», «Норникель», «Мособлгаз» и других российских и международных компаний. А в прошлом году наша копилка успешных кейсов пополнилась образовательным проектом в Бахрейне. В этой статье я расскажу, как мы обучили арабских студентов VR и AR-разработке всего за пять месяцев, научили их вести проект заказчика под ключ. Забегая вперед, скажу, что некоторые выпускники даже получили работу по этой специальности.

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

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

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

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

Давайте рассмотрим, что говорят законы о правах на код с обеих сторон:

• Когда и какие права возникают у вас (как физлица) на код.
• Как правильно устроена передача имущественных прав на код работодателю.
• Тимлид, который делал ревью, — он соавтор или кто?
• Можно ли коммитить в свой pet-project с рабочего компьютера в рабочее время?
• Какой геморрой предстоит пройти, чтобы правильно использовать код, если вы его заказали?

И так далее.

Поехали!

После первой волны санкций были внесены изменения в закон об информации в части реестра отечественного ПО. Теперь для государственных органов и компаний он является приоритетом для закупки по 44-ФЗ. С недавнего времени аналогичный приоритет предоставляется ПО из стран ЕАЭС, однако есть особенности с недостатком ПО в этих списках, чтобы закрыть все потребности предприятий.

Ещё для государственных органов предусмотрены другие подзаконные акты. Так, по вопросу автоматизации государственного контроля действует Приказ Минкомсвязи России от 03.06.2019 N 252, в котором не только подчёркивается приоритет отечественного ПО, но и даже указан опенсорс.

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

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

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

Начнём мы с вопроса о том, что вообще такое «санкции» и как они работают — и что нужно знать, например, CTO или системному администратору про них.

Привет, Хабр! Я не разработчик, а менеджер. Меня некоторое время учили управлять людьми, а потом я погрузилась в мрачный мир разработки, где всё идёт не так, как говорят в университете. Сейчас я руковожу практикой управления жизненным циклом программного обеспечения и хочу рассказать несколько, возможно, важных для тимлидов и ПМ'ов вещей, которые касаются перехода на удалёнку. Потому что в наших командах люди было уже начинали так косячить. А потом покажу и расскажу про наш стек автоматизации для удалёнки, и о том, как мы аппрувим релизы из чатов на телефоне одной кнопкой, а не поднимая VPN в защищённый периметр, и это ускорило согласования, и это помогает согласовывать день в день.

Первый совет — хватит доставать своих людей!



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


Дятел-менеджмент в чистом виде

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

Карта полёта, отмечены точки с концентрацией метана свыше 3 000 ppm*m. И это много!

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

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

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

Услуга автоматизированного замера уровня метана с помощью дронов очень востребована в Европе.

Мы, с нашими партнёрами из компании Пергам, провели совместную работу в этом направлении и получили интересный результат.

Привет!

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

С другой стороны, частые переговоры означают много поездок. Иногда везёт. Вот в Дубае выходные пятница и суббота, а воскресенье — рабочий. При этом рейсы на воскресенье дорогие, и куда выгоднее лететь в пятницу. Встреча по поводу наших разработок по машинному зрению для дронов была на воскресенье, и когда наш переговорщик прилетел, заказчик извинился и сказал, что не получается, и нужно перенести ещё на пару дней. Так у него получились незапланированные выходные. Ну а дальше он закономерно вышел на пляж и уснул. После чего всем говорил, что сгорел на работе. Но интересно не это: дело в том, что ещё один наш коллега как раз застрял посреди тундры. Это примерно два часа вертолётом от Нового Уренгоя, и, кроме вертолёта, там транспорта нет. У него была метель — и, как следствие, нелётная погода. Он прибыл, обследовал талевые канаты и не смог вылететь. К началу истории уже сидел там два дня. Синоптики обещали открыть площадку только ещё через три дня. Из развлечений у него там была еда в столовой на месторождении, настольный теннис с вахтовиками и SMS на телефоне. Вот они друг другу и жаловались, кто и где застрял.

Это миф, достаточно распространённый в сфере серверного железа. На практике же гиперконвергентные решения (когда всё в одном) нужны много для чего. Исторически сложилось, что первые архитектуры были разработаны Amazon и Google под свои сервисы. Тогда идея была в том, чтобы сделать вычислительную ферму из одинаковых узлов, у каждого из которых есть собственные диски. Всё это объединялось неким системообразующим софтом (гипервизором) и разбивалось уже на виртуальные машины. Главная задача — минимум усилий на обслуживание одного узла и минимум проблем при масштабировании: просто докупили ещё тысячу-другую таких же серверов и подключили рядом. На практике это единичные случаи, и гораздо чаще речь про меньшее число узлов и немного другую архитектуру.

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

Получалось, что вы платите на 10–15% больше за удобство настройки. Это и вызвало миф из заголовка. Мы долго искали, где же будет применяться технология оптимально, и нашли. Дело в том, что у Циски не было своих СХД, но они хотели полный серверный рынок. И они сделали Cisco Hyperflex — решение с локальными хранилищами на нодах.

А из этого внезапно получилось очень хорошее решение для резервных дата-центров (Disaster Recovery). Почему и как — сейчас расскажу. И покажу тесты кластера.

Иногда бывает так:

— Приезжайте, у нас упало. Если сейчас не поднять — покажут по телевизору.

И мы едем. Ночью. На другой край страны.


Ситуация, когда не повезло: на графике показан резкий рост нагрузки на СУБД. Очень часто это первое, на что смотрят администраторы системы и это первый признак того, что наступила жопа

Но чаще речь идёт про какие-то типовые вещи. Например, заказчик столкнулся с низкой производительностью системы документооборота. По понедельникам и вторникам система падала, они перезагружали сервер, и потом всё поднималось. Захлёбывалась база данных. Хотели докупить оборудования (что долго и дорого), позвали нас просчитать смету. Мы им посчитали смету и заодно предложили разобраться, что же именно тормозит. За три-четыре часа локализовали источник проблемы. Выяснили, что это медленные запросы в базу данных и неоптимальные схемы индексирования. Создали недостающие индексы, поковырялись с оптимизатором запросов в Оракле, некоторые проблемы потребовали изменения кода — поменяли условия поиска (без изменения функциональности), заменили часть запросов на использование предрассчитанных представлений. Если бы у них был нормальный человек по БД — могли бы сделать то же и сами. Но вместо нормального человека был аудит базы данных раз в полгода крутыми ораклистами — они выдавали общие рекомендации по настройкам и железу.

Один товарищ — без каски, второй — без перчатки.

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

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

Конкретно:

• Очень легко распознавать людей без каски. Даже лысых. Увидели человека без каски — сразу алерт оператору или начальнику цеха.
• То же самое касается очков и перчаток на опасных производствах, страховки на поясе (правда, мы смотрим только на карабин пока), светоотражающих жилетов, респираторов, шапочек для волос и других СИЗ. Сейчас система обучена распознавать 20 типов СИЗов.
• Можно точно считать людей на объекте и учитывать, когда и сколько их было.
• Можно подавать тревогу при заходе человека в опасную зону, причём эта зона может настраиваться по факту запуска-остановки станков.

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

Заказчик захотел VDI. Очень присматривался к связке SimpliVity + VDI Citrix Virtual Desktop. Для всех операторов, сотрудников офисов по городам и так далее. Там пять тысяч пользователей только в первой волне миграции, и поэтому они настояли на нагрузочном тестировании. VDI может начать тормозить, может спокойно прилечь — и не всегда это случается из-за проблем с каналом. Мы купили очень мощный пакет тестирования специально для VDI и грузили инфраструктуру, пока она не легла по дискам и по процессору.

Итак, нам понадобятся пластиковая бутылка, софт LoginVSI для навороченных тестов VDI. У нас он с лицензиями на 300 юзеров. Потом взяли железо HPE SimpliVity 380 в набивке, подходящей для задачи максимальной плотности пользователей на один сервер, нарезали виртуальных машин с хорошей переподпиской, поставили на них офисный софт на Win10 и начали тестить.

Поехали!