Хабр, привет!

Меня зовут Александр Кузьмин, я старший инженер в КРОК, занимаюсь облачными технологиями, микросервисами и всеми новомодными DevOps-методологиями. 

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

Пост основан на моем докладе на последнем DevOops Conf, так что если видео вам заходит лучше, приглашаю по ссылке.

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

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

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

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

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

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

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

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

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

Из этого поста вы узнаете, зачем добавлять в интеграционный слой бизнес-логику, что случается, когда «не летит» Service mesh, и почему иногда костыли — лучшее решение проблемы.

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

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

Привет, Хабр! 

4 февраля мы проводим онлайн-митап о найме в ИТ. Хотим поделиться с миром результатами исследования об изменениях в ИТ-найме, которое провели наши нанимающие менеджеры из команды департамента разработки ПО КРОК.  Для этого мы проанализировали  почти 500 технических интервью, которые провели за последние полгода. А еще один из нас отправился на секретную миссию и получил от крупнейших компаний 6 офферов после 6 собесов. 

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

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

У нас было 2 проектных менеджера, 72 эксперта от производства, 33 высококлассных спеца из двух IT-команд, несколько десятков систем управления производством по всей стране, а еще, разработчики КРОК и Группы НЛМК прежде не работали вместе.

Звучит как организационный ад, и это недалеко от истины. Но мы справились и теперь хотим поделиться опытом работы в объединенной команде Группы НЛМК и КРОК в масштабном проекте по развитию информационных сервисов службы продаж.

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

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

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

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

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

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

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

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

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

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

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

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

1. Двигаться по складу без помощи оператора.
2. Считывать штрихкоды или QR-коды паллет и надписи около них.
3. Превращать это в данные инвентаризации и передавать в WMS в итоге.

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

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