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

Есть у нас традиция: каждое лето запускать Летнюю ИТ-школу для студентов. Приглашаем студентов старших курсов или недавних выпускников на двухнедельные интенсивы по погружению в айти. Приготовили обучение по 8 трекам:  телекоммуникации, программная инфраструктура, информационная безопасность, sales&management, вычислительная инфраструктура, разработка, ИТ-аналитика и рекрутинг.  Обещаем обучение с кейсами без котиков, крутых экспертов и deep-dive погружение. 

Немного формальностей: школа бесплатная, если нужно – сделаем документы о практике для университета, а занятия пройдут в московском офисе КРОК. 

Встретимся в июле – а участникам, которые круто себя проявят – предложим оффер на стажировку в КРОК. Подробнее про направления и этапы отбора – под катом и на сайте Школы и после ката. Не забудь зашерить ссылку знакомым, которые хотят начать карьеру в ИТ.

«Шеф, всё пропало! Поддержки больше нет! Завтра снимают гипс! Нужно срочно всё заменить, переделать, решить и исправить!» — подобные панические настроения стали частым явлением за последние полгода. Отсутствие вендорской поддержки создало огромное количество проблем для компаний, чья ИТ-инфраструктура была построена на продуктах западных поставщиков, покинувших наш рынок. Это и отсутствие консультативной поддержки, и невозможность обновления прошивок, и затруднения в закупке дополнительных лицензий и так далее.

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

Крупное производство с несколькими заводами на разных участках. Техпроцесс зависит от работы систем связи, а на них АСУ ТП и промышленное видеонаблюдение за станками и опасными участками. Если хотя бы одна рация на участке не работает — работать нельзя. Работать с СКС/ЛВС в колодцах, погружаясь на большую глубину, ремонтировать системы видеонаблюдения в строительных люльках на высоте выше 10 метров, работать под напряжением до 1000 В — всё это на заводе рутина.

На производстве есть своя команда из 50 человек, разбитая по площадкам. Условно, на каждой площадке есть несколько ролей, и они работают сменами с покрытием 24/7, то есть каждый инженер работает только процентов 10–15 времени, а остальное время дежурит удалённо и «плюёт в потолок» осуществляет проактивный мониторинг. Производство решает перейти от модели постоянных дежурств к профилактике и быстрым выездам: по их расчёту, тогда будут незакрыты только риски массовых аварий на разных площадках, а всё остальное окупается за счёт экономии при большей утилизации времени команды.

Это всё планируется отдать в аутсорсное управление интегратору, потому что сам завод умеет отлично делать свои изделия, но не является сервисной ИТ-компанией. Играется тендер, одно из условий которого — принять на 3-летний контракт старую команду, которая уже этим занималась по местам.

Мы побеждаем, принимаем старую команду, нам передают дела — и начинается жесть.

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

Хабр, привет!
28 апреля в 18:00 собираем онлайн-митап о создании систем по разные стороны Kubernetes. Да, уже многие поиграли с ним в песочнице и используют в dev и prod средах, но чем глубже погружаешься, тем больше вопросов возникает.

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

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

Если что-то пошло не так, начинается звуковая и световая индикация. Значит, надо действовать: вносить корректировки в техпроцесс или даже резко все отключать. Но датчики могут давать сбои или вообще не срабатывать. И, конечно, никто не застрахован от «ложняков», которые тоже надо отслеживать.  

Чтобы повысить безопасность и ускорить время реагирования, как раз и нужна система технологического видеонаблюдения. С ее помощью специалист может понять, реальная проблема или ложная. Или, например, первым увидеть изменение цвета дыма из трубы, а не дожидаться момента, когда бдительные жители соседнего населенного пункта оценят изменения воздуха в соцсетях и через СМИ. 

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

С мультимедийными системами часто бывает так: в пяти разных помещениях офиса, просто из-за разницы в годах создания систем, используются разные интерфейсы. Как итог, условный Пётр знает, как работать на первом этаже, но без понятия, как сделать то же самое на восьмом. Саппорт, в свою очередь, не хочет, чтобы ему задавали вопросы по переговорной комнате и тем более смотреть, почему комп, выдающий сигнал с HDCP, не работает и нет контента в ВКС. 

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

История первая: Иркутск, пандемия, больница, пусконаладка 

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

Ничего не подозревающий, простуженный в первый же день командировки инженер (Иркутск зимой не самое дружелюбное место) как ответственный человек идет к врачу, чтобы проверить, всё ли с ним в порядке. В результате его без объявления войны отправляют в местную инфекционную больницу до выяснения обстоятельств. Чем параллельно саботируют процесс ПНР. 

Всем привет! Я Иван, старший инженер-тестировщик в КРОК. Уже 6 лет занимаюсь тестированием ПО. Из них 3 года внедряю автоматизацию тестирования на различных проектах - люблю всё автоматизировать. На рабочей машине много разных “батников” и bash-скриптов, которые призваны упрощать жизнь.

Недавно у нас стартовал проект по модернизации и импортозамещению системы электронного документооборота (СЭД) в одной крупной организации. Система состоит из основного приложения и двух десятков микросервисов, в основном - для построения отчётов и интеграции с другими подсистемами. Сейчас в проекте уже настроено больше 100  автотестов, и они сильно помогают при частых релизах, когда времени на регресс почти нет. Весь набор автотестов выполняется примерно за 25 минут, в среднем экономим до 3,5 часов ручной работы при каждом запуске. А запускаем мы их каждый день.

Дальше будет про то, как мы выбирали технологии и инструменты, какой  каркас и подход к организации автотестов в итоге получился. И почему мы в КРОК решили тиражировать этот подход в других проектах, реализация которых основана на Content Management Framework (CMF) под СЭД. На базе CMF у нас есть комплексное решение для автоматизации процессов документооборота КСЭД 3.0. Конечно, отдельные решения по автотестам можно применять под любую СЭД.

Ещё расскажу про проблемы, и как мы их решали. Пост будет интересен и полезен, если в ваших автотестах необходимо подписывать документ электронной подписью (ЭП) в докер-образе браузера, проверять содержимое pdf файла, выполнять сравнение скриншотов или интегрироваться с одной из популярных Test Management System.

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

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

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

Привет, Хабр. Меня зовут Алексей, и уже 10 лет я занимаюсь проектированием и внедрением противопожарных систем. В 2021 году в нашей сфере грядут существенные изменения, связанные с внедрением новых стандартов — СП 484.1311500.2020, СП 485.1311500.2020, СП 486.1311500.2020. Эти документы вступают в действие как раз сегодня, 1 марта. Изменения концептуальные, и затронут они всех участников процесса — производителей оборудования (вендоров), проектировщиков, инсталляторов, заказчиков.

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

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

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

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

В прошлом году сделали пилотный проект по облачной диспетчеризации для одной из сети АЗС. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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