Привет, Хабр! На связи команда Проектного офиса НЛМК-ИТ.

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

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

Задача: в БД необходимо фиксировать кто создал сущность, кто её обновил, и кто её удалил.

Все знают, как взять пользователя из контекста и сунуть его в сущность. Допустим, на уровне сервиса в методе извлечь информацию о нём и «засетать» его в нужные поля (придётся везде таскать этот кусок кода по сервису), а с аспектами как‑то выглядит не явно и накладывает ряд обязательств (например, развешивание аннотаций над методами всякий раз, когда мы что‑то пытаемся сделать с сущностью (новые участники команды могут не знать о такой неявной практике, а старые забыть о ней)).

Мне хотелось полностью делегировать это приложению, но погуглив, я не нашёл какого‑то явного решения. Сейчас расскажу, как мне удалось это сделать:

Представьте, что вы запустили внутреннюю платформу сервисов для разработчиков и DevOps-команд: хранение кода, инструментарий для CI/CD, контейнеризация (или иной способ выполнения приложений), логирование, мониторинг и т.д. и т.п. и др. и пр.

Пошли потребители. 1, 2... 10-й... 20-й... Вы понимаете, что для их обслуживания вручную в приемлемые сроки вам не хватает "рук". Еще и пользователи создают заявки, используя человеческий язык запросов, трудно поддающийся автоматизации. Из-за спешки и стресса начали появляться сбои. Итог: вместо работы над улучшением платформы вы занимаетесь разборами жалоб и инцидентов.

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

В процессе общения с различными командами в НЛМК у меня появилась идея предложить им «преднастроенный PostgreSQL». Как в итоге сделали — под катом.

В ноябре на Хабр Карьере завершилась карьерная неделя бэкенда. Карьерная неделя — это что-то вроде дня открытых дверей, который длится всю неделю. В гонке за специалистами участвовали шесть компаний: РТЛабс, МойОфис, Лига Цифровой Экономики, Контур, НЛМК и Nexign. 

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

В ноябре на Хабр Карьере завершилась карьерная неделя бэкенда. Карьерная неделя — это что-то вроде дня открытых дверей, который длится всю неделю. В гонке за специалистами участвовали шесть компаний: РТЛабс, МойОфис, Лига Цифровой Экономики, Контур, НЛМК и Nexign. 

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

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

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

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

Привет! Мы решили собрать для вас все статьи о Site reliability engineering (SRE) в одном месте.

В материалах ниже вы найдете информацию о внедрении SRE, вариантах применения отдельных практик, а также полезные кейсы от нескольких компаний.

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

Привет, всем!

Предполагаю, многие уже знакомы с «npm» (менеджер пакетов), файлом «package.json» и командой для установки пакетов «npm install». Тема моей на следующем шаге, когда после успешно выполненной команды «npm install» появляется файл «package-lock.json». Он создается для любых операций, в которых npm изменяет дерево «node_modules» или файл «package.json». Описывает точное дерево зависимостей, которое было сгенерировано, так что последующие установки могут генерировать идентичные деревья, независимо от промежуточных обновлений зависимостей.

О том, как это работает — мой туториал.

Привет! Меня зовут Илья Макаров, я работаю архитектором решений и в статье расскажу про архитектуру цифровой платформы НЛМК, из каких компонент, помимо Apache Kafka, она состоит, к каким соглашениям по именованию топиков и договоренностям по передаче данных мы пришли, как всем этим управляем.

А это сразу ссылка на часть 2.

Представим ситуацию – вам надо сделать небольшой отчет на основе данных из другой системы. Звучит обыденно и вы сразу в голове представляете, что надо будет делать: узнать какие будут входные данные и в каком виде они к нам поступят, какая будет логика отчета (что на что надо умножить и т.д.) и в каком виде отчет должен быть представлен (график, диаграмма, таблица и т.д.), реализовать.

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

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

Всем привет! Предлагаю взглянуть на проблему, связанную с возникновением коммитов от «неизвестных» пользователей в вашем git репозитории. Такое может возникнуть, если один разработчик будет использовать несколько разных git конфигов. Расскажу, какие есть варианты избежать похожую ситуацию.

Помните задачу о рюкзаке, в который нужно сложить как можно больше ценных вещей при ограниченной вместимости? Подобные головоломки каждый день решают сотрудники «Алтай-Кокса» при загрузке вагонов, только факторов нужно учесть несравнимо больше: грузоподъёмность, фракцию груза, тарифные планы, тип маршрута и много чего ещё. Последний год в этом помогает математическая модель, завернутая в цифровой сервис - об этом (а еще о металлургическом коксе) речь под катом.

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

Сейчас для IT-сообщества появляется много новых возможностей. Например, Группа НЛМК открыла более 250 новых вакансий для разработчиков, тестировщиков, IT-архитекторов, инженеров, специалистов по информационной безопасности, UI/UX дизайнеров, аналитиков, руководителей IT-проектов и экспертов по широкому спектру информационных систем.

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

Smart Contract & Gas

Если на пальцах, "умный контракт" — это некоторый код, живущий внутри блокчейна. Любой участник сети может его вызвать за небольшую плату. Эта плата и называется Gas, дословно "топливо". Зачем это нужно? Для защиты майнера от злоупотребления мошенником его ресурсов.

Немногие знают, но даже в биткоине есть возможность писать эти самые контракты, но в силу некоторых причин этим мало кто занимается. Одна из главных проблем — язык Script не Тьюринг-полный и написать что-то более менее серьезное непросто (чтобы вы понимали масштаб проблемы — нет даже возможности добавить цикл). В случае с Ethereum все чуть по другому, языки Тьюринг-полные, и есть риск, что кто-то напишет контракт вида

// Это псевдокод
foo = 0;
while (True) {
    foo++;
}

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

Привет! Меня зовут Григорий, в Группе НЛМК я руководитель команды в отделе Backend-разработки. Примерно год назад мы доработали SAP SuccessFactors - автоматизировали расчет оценки сотрудников рабочих специальностей.

Параллельно с доработкой SAP SF наша компания внедряла Единую цифровую платформу (ЕЦП) - меняла подход к разработке через взаимную интеграцию удобных инструментов. Расскажу обо всем этом на примере нашего проекта.