Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

Меня зовут Ася, и я занимаюсь решениями по оптимизации в НЛМК-ИТ. Много лет я работала .NET разработчиком, мечтала о профессиональном росте. Коллеги из проекта по календарному планированию и графикованию поверили в меня и взяли в команду, несмотря на то, что на тот момент я не имела релевантного опыта. Я узнала, что математические модели востребованы и в металлургии. И вот мы выпустили в опытно-промышленную эксплуатацию проект оптимального планирования производства на основе класса программ Solver.

Здесь хочу рассказать об оптимизации очередей производства в прокатном и электросталеплавильном цехах НЛМК-Калуга. На фото прокатный цех.

Когда я начала работать, люди составляли планы загрузки агрегатов в Excel. В прокатном цехе это план для прокатного стана, а в электросталеплавильном для МНЛЗ (машина непрерывного литья заготовок). Это основные агрегаты двух цехов, они работают непрерывно день и ночь и одномоментно могут производить только один вид продукции, потом приключаться на другой.

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

Чтобы узнать какими средствами мы оцифровали процесс планирования производства, прошу под кат.

Привет всем! Меня зовут Михаил, я старший Frontend-разработчик в НЛМК, занимаюсь разработкой одной из внутренних информационных систем на React + Typescript.

Расскажу про самый короткий и наименее трудоемкий способ экспорта и импорта модулей, что частенько требуется для построения современных приложений. А именно опишу свой эксперимент с импортом и экспортом без использования файла Index.ts, затем — с его использованием. Для наглядности я создал небольшой проект с Webpack и Typescript в редакторе исходного кода Visual Studio Code (далее по тексту VS Code).

Файл webpack.config.js содержит дефолтные настройки, никаких плагинов я не использую. В статье посмотрим на результаты сборки проекта с помощью Webpack в режиме “mode=development”, в режиме “mode=production” и затем подведем итоги.

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

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

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