Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).
Пользователь
Как меняется сумма от перемены мест в графике производства
Меня зовут Ася, и я занимаюсь решениями по оптимизации в НЛМК-ИТ. Много лет я работала .NET разработчиком, мечтала о профессиональном росте. Коллеги из проекта по календарному планированию и графикованию поверили в меня и взяли в команду, несмотря на то, что на тот момент я не имела релевантного опыта. Я узнала, что математические модели востребованы и в металлургии. И вот мы выпустили в опытно-промышленную эксплуатацию проект оптимального планирования производства на основе класса программ Solver.
Здесь хочу рассказать об оптимизации очередей производства в прокатном и электросталеплавильном цехах НЛМК-Калуга. На фото прокатный цех.
Когда я начала работать, люди составляли планы загрузки агрегатов в Excel. В прокатном цехе это план для прокатного стана, а в электросталеплавильном для МНЛЗ (машина непрерывного литья заготовок). Это основные агрегаты двух цехов, они работают непрерывно день и ночь и одномоментно могут производить только один вид продукции, потом приключаться на другой.
Естественно, это был не предел оптимизации, всё зависело от опыта планировщиков. Иногда забывали заказы — ну, просто потому что даже лучшие из людей не идеальны.
Чтобы узнать какими средствами мы оцифровали процесс планирования производства, прошу под кат.
Index.ts – зло и польза
Привет всем! Меня зовут Михаил, я старший Frontend-разработчик в НЛМК, занимаюсь разработкой одной из внутренних информационных систем на React + Typescript.
Расскажу про самый короткий и наименее трудоемкий способ экспорта и импорта модулей, что частенько требуется для построения современных приложений. А именно опишу свой эксперимент с импортом и экспортом без использования файла Index.ts, затем — с его использованием. Для наглядности я создал небольшой проект с Webpack и Typescript в редакторе исходного кода Visual Studio Code (далее по тексту VS Code).
Файл webpack.config.js содержит дефолтные настройки, никаких плагинов я не использую. В статье посмотрим на результаты сборки проекта с помощью Webpack в режиме “mode=development”, в режиме “mode=production” и затем подведем итоги.
Всё меняется, когда твой софт повышает безопасность производства
Если вы знакомы со спецификой «суровых производственных мужчин», то знаете, что от них это звучит примерно так же, как «тыквенный смузи и веганский стейк, пожалуйста», — ещё два года назад мы о таком проявлении доверия к ИТ со стороны производства даже мечтать не могли. А тут оказалось, что им нужен инструмент, чтобы контролировать износ сегментов УНРС (установки непрерывной разливки стали), потому что это не только убирает рутину, напрямую влияет на качество продукта — слитков стали, но и снижает потенциальный риск прорыва сегмента с расплавом.
Итак, знакомьтесь, вот один из ручьёв УНРС:
Сверху на УНРС приходит ковш, снизу выпадает огромный слиток стали — сляб. Если вы думаете, что достаточно просто залить сталь из ковша в формочку, то нет. Надо, чтобы всё это равномерно остыло, иначе внутри будут раковины, трещины и другие неприятности. Поэтому процесс такой: сверху буфер, бассейн-накопитель для жидкой стали, дальше каскад сегментов-обработчиков. Сталь проливается вниз, а каждый сегмент охлаждает её. В бассейн подаются ковши с расплавом, которые его наполняют.
Самое опасное в УНРС — не уследить за износом какого-то одного из сегментов, по которому идёт расплав, постепенно превращаясь в сляб. И оказалось, что можно свести такую вероятность к нулю, если избавиться от кучи отдельных бумажных документов и автоматизировать контроль.
Технологи хотели от нас предельно простого работающего решения, чтобы они в каждый момент очень чётко представляли себе статус каждого узла машины. Никакой математики. Никакого дата-майнинга. Никаких нейросетей. Никаких сложных научных исследований.
Сейчас покажу результат.
Приемы для ускорения написания кода на ABAP
Зачастую скорость разработки зависит не только от знаний основ языка ABAP и хорошо написанной спецификации на разработку, но и от применения способов быстрого написания кода.
Например, представители проекта Brainscape подсчитали, что при условиях восьмичасового рабочего дня, использование горячих клавиш может сэкономить любому сотруднику до 8 рабочих дней в год, а у разработчиков выгода от их использования может быть ещё выше.
Поэтому я решил обобщить свой опыт по ускорению написания кода на ABAP в этом материале. Напишите в комментариях, как вам кажется, сколько рабочего времени у вас получится сэкономить с использованием этих приемов.