В 2006-м жил в Голландии, смотрел по CNN сюжет о самолёте с полной загрузкой ядерными БЧ, который пересёк США из штата Нью Йорк на севере во Флориду на юге. Это обнаружили после приземления, и в Калифорнию вылететь уже не дали
Так что "хорошая" идея в некоторых головах вечно молодая
И то ведь только строгий сабж, а были и утечки на складах. Не в авиации - были шахтные инциденты с заражением и "гражданские" на АЭС
Все время как читал мелькала мысль - и эти люди пеняют нам Чернобылем
Выражалось в стабильном падении покупательной способности, ветшании инфраструктуры, росте напряжённости и преступности, нарастающей дисфункции институтов первой необходимости и уровня сервиса - именно не для туристов, а для жителей. Процесс шёл стабильно в одном направлении всё то время, пока Россия приводила себя в порядок
Конкретные примеры я могу приводить довольно долго, но всякие неприглядные подробности лучше в личке, в комментариях на ИТ ресурсе они были бы неуместны
Если вы пишете это из-за пределов РФ, то могу рекомендовать её. Тут много мест, задающих стандарт в мире и двигающих его вперёд. Если речь про переехать из РФ - то новиночки, до того как их подберут сетевые американские гиганты - впервые в мире за пару-тройку лет до этого появляются в Китае, реже в Индии, странах Южной америки
Лично я считаю, что любому человеку, необязательно в IT, полезно несколько лет поработать за рубежом. Четыре года в Англии, Голландии, Японии и США кардинально повлияли на меня как на специалиста и человека. Я избавился от комплексов, увидел лучшие мировые практики, и лучше стал различать передовое от массовки
Такой опыт чрезвычайно полезен
Другой вопрос, что было это лет 15-20 назад, уже тогда в Европе с Америкой условия труда начинали ухудшаться, и тренд с тех пор не менялся. Поэтому и передок прогресса оттуда сместился в другие места на нашем шарике
Последние несколько лет я бы советовал желающим куда-нибудь съездить на пару лет понабраться передового опыта - в Азиатские страны, на Ближний восток, Южную Америку
Это в целом, когда всё спокойно
В турбулентные времена - все немножко теряют. Потери будут меньше, если минимизировать изменения. В такое время всяческие переезды и поиски работы - значительно дороже, по силам и средствам, по сравнению со спокойными временами
в смысле конкретных действий - взяться за изменение и его провести
всё же мы предпочитаем чтобы командовали нами. Это даёт возможность работать как принято, а свобода слова есть всегда
Хотя, конечно, я с вами согласен: каждый отдел уникален, каждый коллектив не похож на другой
вот сейчас я работаю в конторе, где изначально самые главные руководители - командовали разработчиками напрямую. И внедрение в команду всяких продактов, аналитиков и тестеров - заставляет властью делиться. У нас изменений, наверное, даже чуточку чересчур на единицу времени. И процесс неизменно построен так, что разработчики главные, и по своему желанию привлекают аналитический блок. Это, кстати, позволяет следить за красотой и правильностью кода, делает рефакторинг - задачей бизнеса
Если честно, ситуация, когда у одного из членов команды возникло понимание, что нужно менять язык/фреймворк, а остальные говорят что это нецелесообразно (например, некому будет поддерживать, или по другим причинам) - довольно редка
Всё же большинство вещей можно написать на принятых в команде инструментах, любо перейти всей командой на новые
В моей практике был только один такой случай.
На одном заводе использовали Sparc Fortran на Solaris OS. Тогда это был язык понятливый как Javascript - в том плане, что работает вообще всё что угодно
Баги приходилось ловить только по выполнению. При этом инструменты отладки были только "родные" от Solaris.
Когда пришёл очередной баг - я просто заправил принтер пачкой бумаги и распечатал список "шероховатостей" в коде. Список был в 3002 записи, с выдержками из кода - стопка в пару сантиметров бумаги
Я положил этот "талмуд" на стол начальнику и сказал: одна из этих "шероховатостей" является причиной бага. А может и несколько. Давайте починим их все?
Начальник собрал тимлидов, мы обсудили проблему, и нам дали добро, параллельно с другими задачами и не двигая никакой из сроков, устранить все "шероховатости" ("inconsistencies", дело было в Дерби, РР)
Затем аналогично - снизу вверх - выбрали язык
Остановились на C++. Solaris Sparc C++ рассказывал, что не так, не давал собрать приложение пока с его точки зрения всё не придёт в порядок, и это настраивалось ещё строже. Я выкрутил все настройки на максимум, и просто переписал на C++ одну из программок, добившись, чтобы не было ни одного предупреждения
И баг пропал сам собой
Кончилось тем, что РР поручил своему индийскому отделу переписать свои фортрановские программки на C++
Нужно как-то изменить ситуацию в вашу пользу. В текущем виде это нерешаемо
Лично я за прозрачность, но никому не навязываю. Со всеми поговорить, или зайти сверху, или сделать чтобы заказчик хотел именно ваш код на проде
Шансы саботажа все равно будут, но это уже решаемые проблемы.
Можно пойти более тёмной дорожкой, так у нас один товарищ делал. Втихаря выкладывал на прод, прятал концы, валил на других, не вёл версионность, не все пушил в ветку чтобы никто не разобрался, что он обновил. Это имеет свои минусы, но даёт свободу действий на некоторое время. В нашем случае он потихоньку переполз на другую должность, где все эти качества оказались полезны команде
Может, облегчить этот кусок, перенести в другие части?
У нас был как-то период, когда один гений ушёл, и кусок проекта вообще невозможно стало трогать. Все были примерно равной квалификации, гений к нам пришёл годом позже, и просто никто не решался. Тупо добавляли сбоку-сверху и не шевелили внутри
Я тогда как сотрудник техподдержки объяснил эксплуатации, что есть баги, которые мы не правим совсем, только компенсируем. И согласовал, что часть функционала мы перенесём на бэк и в базу.
База у нас стала "мудрой" - она научилась понимать любую входящую ерунду, и исходя из известных багов принимала решение, что на самом деле случилось и как это разложить по табличкам
Потом, когда ситуация с багами сдвинулась с мёртвой точки - мы облегчили базу обратно до "умной"
Мне просто казалось важным, чтобы проект был непрерывно адекватен команде разработчиков, и сообразно переносил функциональность из части где затык в другую где работа кипела
Хе, да, в восьмером пробовал :) совещались недели три, представления о прекрасном так и не пришли к общему знаменателю. Оставили это дело и смирились, что есть у нас серая зона, в которой всё долго. Ребята до сих пор стараются её вообще не трогать
Один бунтарь, который считал что мы все неправильные, отсел на полгода, и переписал в одного полпроекта на своих любимых инструментах, с учётом всех прошлых и части будущих хотелок. Когда мы это вывели с очередным обновлением - эксплуатация была в шоке, а заказчик - счастлив! Работы шли через операционные расходы, т.е. по линии техподдержки, потом задним числом впечатлённый владелец бюджета всё покрыл в очередном договоре
думается мне, поможет рефакторинг, декомпозиция, доки-логи и ответственность
чётко договориться в команде, что есть архитектурный баг, есть баг постановки, баг бизнес-функциональных требований - и программный баг. И все поровну тянут баги в своей ЗО
дробить задачки. Цель - доработку программы в своей ЗО самый золоторукий программист делает не более 8 часов напряжённой работы
логировать и документировать (желательно автоматически), рефакторить. Если не согласуют, то тихо, фоном - потом спасибо скажут.
Тогда и баги в коде будут чиниться за час, со всеми "подумать как лучше"
либо быстро закостылить сейчас, либо месяц переписывать "как красиво"
О, классно. Вот как вы цитируете :) Вот этого не понимаю я :)
Чтобы понимать, на что уходит месяц, мне не хватает специфики проекта. Месяц это очень большой срок
У нас (боевые случаи):
разраб поднимает своего тимлида, тот разводит руками, разраб обращается к аналитику - 20 минут. Аналитик открывает базу, чинит одно место в коде, второе показывает разрабу - 30 минут. Разраб чинит указанное место - 5 минут. Поддержка отписывается что всё готово, согласуйте вывод - 5 минут. Вот один час
поддержка берётся за раскопки, предлагает готовый кусочек кода разрабу - 30 минут. Разраб крутит пальцем, предлагает поменять, условно, больше на меньше и больше ничего не трогать. Поддержка и разраб идут к аналитику, перетирают - 10 минут. Ловят большое начальство, совещаются; решение: сейчас не делать ничего, войдёт в следующий заказ. Клиенту отписываются пока решать обходным путём, скоро будет хорошо - 20 минут. Один час
Извините, не был точен: я лишь про то, что важно разрешать себе полчаса-час подумать-пораскапывать-посовещаться, как бы ни наседали
И тогда скорее всего получится надёжно, и по этому поводу больше не придут
Насчёт месяца и красиво - это очень хлопотно согласовать, но если все согласны, от владельца бюджета до эксплуатации, то почему бы и нет. Так у нас обычно начинались переговоры, из которых рождалась следующая версия системы
починить одно и то же место можно раз, другой, потом придётся сделать на совесть, просто чтобы прекратился вал инцидентов про одно и то же - либо потонуть в поддержке
опять же, сотрудник поддержки обычно остро чувствует и понимает, что бизнес стоит на доверии клиентов. Когда бизнес теряет доверие клиентов - клиенты просто уходят к другому, и бизнес можно закрывать. Поэтому не бывает ни поддержки себя любимого, ни поддержки босса, ни поддержки заказчика - есть только поддержка пользователей. Отсюда и особые права поддержки, и вес, а с ним - возможность потратить чуть больше времени, зато сделать раз и навсегда
Из практики видел два счастливых исключения: рефакторинг и поддержка
В моей первой команде рефакторинг проводился по чайной ложке с каждой задачкой, в параллели. Во второй где счастливо проработал больше семи лет - рефакторингом занялись на полгода ценой полной остановки проекта. Слышал о командах, где рефакторинг проводят регулярно, выделяя, условно, один спринт в году. Не суть. Когда проводится рефакторинг - красота, правильность, надёжность в лице объективных метрик вроде связности и зацепления, заменяемости и ответственности - на одном из первых мест
Техподдержка частенько инициирует задачки, в которых правильность-надёжность-красота на первых местах. Понятно, большинство из нас меряет всё-таки в объективных метриках, но смысл такой. Когда мы делаем задачки поддержки - мы стараемся жить правильно :)
Ну да, там действительно попроще с ИТ-безопасностью, при всей озабоченности их политиков правами человека у нас реально лучше дело с тайной перс.данных, личной жизни, защитой от взлома и т.д.
Возможно, речь о признании их QR-кодов на территории РФ, т.к. в случае выезда нашего гражданина европейцы ему QR-код сделают сами через местные институты
Мобильный измеритель - удобно! А ещё передаётся видеопоток в высоком качестве. Так что полагаю дело не только в температуре. Человек-патрульный - это угроза, собака-робот людей скорее забавляет
Любопытно, что на Гавайях есть приюты. С их-то климатом и фауной - можно ночевать на любой скамейке или даже просто на земле
Скопирую в перевод, возможно, это добавит контекста статье
Sorry to hear that
Back in 2008-2009 I was lucky to work for Design Bureau of Sir Henry Royce, Rolls-Royce plc. Glorious company!
They have one of the principles "do not fix what is working". They had Cray 1 mainframe back in 2008-9, it was working all right, so everyone had to deal with that.
A predecessor of CP/M which in turn was a predecessor of DOS, some ancient Fortran version, programs names made of 2 letters and 2 numbers, flat folder structure with no subfolders, debugging tools virtually absent - lots of fun in 2009.
It's own terminals were substituted with some driver plugged into Putty etc. long ago, yet still it needed integration into modern network, some protection from network threats, some interface with programs on regular laptops and computers written on modern language (to the sincere horror of everyone who writes for it, but that's another question)
So yeah, those who want to find their mainframe - will find it even these days
В 2008-2009 мне посчастливилось работать в Роллс-Ройсе. Отличная компания, там не чинят то, что работает. В частности, отлично работал Cray 1.
А раз он работал, то приходилось программировать на нём. Какой-то предок CP/M который сам предок DOS - и зашитый Фортран. Программы две буквы две цифры, файлы данных вечерами букв имя три расширение, плоская структура папок без вложенности.
Как там в этом году - не подскажу, но кое-где как вот в таких сильных традицией местах мейнфреймы могут быть по сей день востребованы
Понятное дело, памяти на них по нынешним временам немного, да и вывод на родные терминалы давно перенаправлен в Putty и пр., поэтому то что на нём пишут приходится как-то защищать от сетевых угроз, стыковать с программами на современных ПК и языках и т.д. (к ужасу всех это дело обслуживающих, но это уже вопрос другой)
Так что кому сегодня надо мейнфрейм - свой мейнфрейм найдёт ☺️
В 2006-м жил в Голландии, смотрел по CNN сюжет о самолёте с полной загрузкой ядерными БЧ, который пересёк США из штата Нью Йорк на севере во Флориду на юге. Это обнаружили после приземления, и в Калифорнию вылететь уже не дали
Так что "хорошая" идея в некоторых головах вечно молодая
И то ведь только строгий сабж, а были и утечки на складах. Не в авиации - были шахтные инциденты с заражением и "гражданские" на АЭС
Все время как читал мелькала мысль - и эти люди пеняют нам Чернобылем
Выражалось в стабильном падении покупательной способности, ветшании инфраструктуры, росте напряжённости и преступности, нарастающей дисфункции институтов первой необходимости и уровня сервиса - именно не для туристов, а для жителей. Процесс шёл стабильно в одном направлении всё то время, пока Россия приводила себя в порядок
Конкретные примеры я могу приводить довольно долго, но всякие неприглядные подробности лучше в личке, в комментариях на ИТ ресурсе они были бы неуместны
Если вы пишете это из-за пределов РФ, то могу рекомендовать её. Тут много мест, задающих стандарт в мире и двигающих его вперёд. Если речь про переехать из РФ - то новиночки, до того как их подберут сетевые американские гиганты - впервые в мире за пару-тройку лет до этого появляются в Китае, реже в Индии, странах Южной америки
Лично я считаю, что любому человеку, необязательно в IT, полезно несколько лет поработать за рубежом. Четыре года в Англии, Голландии, Японии и США кардинально повлияли на меня как на специалиста и человека. Я избавился от комплексов, увидел лучшие мировые практики, и лучше стал различать передовое от массовки
Такой опыт чрезвычайно полезен
Другой вопрос, что было это лет 15-20 назад, уже тогда в Европе с Америкой условия труда начинали ухудшаться, и тренд с тех пор не менялся. Поэтому и передок прогресса оттуда сместился в другие места на нашем шарике
Последние несколько лет я бы советовал желающим куда-нибудь съездить на пару лет понабраться передового опыта - в Азиатские страны, на Ближний восток, Южную Америку
Это в целом, когда всё спокойно
В турбулентные времена - все немножко теряют. Потери будут меньше, если минимизировать изменения. В такое время всяческие переезды и поиски работы - значительно дороже, по силам и средствам, по сравнению со спокойными временами
в смысле конкретных действий - взяться за изменение и его провести
всё же мы предпочитаем чтобы командовали нами. Это даёт возможность работать как принято, а свобода слова есть всегда
Хотя, конечно, я с вами согласен: каждый отдел уникален, каждый коллектив не похож на другой
вот сейчас я работаю в конторе, где изначально самые главные руководители - командовали разработчиками напрямую. И внедрение в команду всяких продактов, аналитиков и тестеров - заставляет властью делиться. У нас изменений, наверное, даже чуточку чересчур на единицу времени. И процесс неизменно построен так, что разработчики главные, и по своему желанию привлекают аналитический блок. Это, кстати, позволяет следить за красотой и правильностью кода, делает рефакторинг - задачей бизнеса
Если честно, ситуация, когда у одного из членов команды возникло понимание, что нужно менять язык/фреймворк, а остальные говорят что это нецелесообразно (например, некому будет поддерживать, или по другим причинам) - довольно редка
Всё же большинство вещей можно написать на принятых в команде инструментах, любо перейти всей командой на новые
В моей практике был только один такой случай.
На одном заводе использовали Sparc Fortran на Solaris OS. Тогда это был язык понятливый как Javascript - в том плане, что работает вообще всё что угодно
Баги приходилось ловить только по выполнению. При этом инструменты отладки были только "родные" от Solaris.
Когда пришёл очередной баг - я просто заправил принтер пачкой бумаги и распечатал список "шероховатостей" в коде. Список был в 3002 записи, с выдержками из кода - стопка в пару сантиметров бумаги
Я положил этот "талмуд" на стол начальнику и сказал: одна из этих "шероховатостей" является причиной бага. А может и несколько. Давайте починим их все?
Начальник собрал тимлидов, мы обсудили проблему, и нам дали добро, параллельно с другими задачами и не двигая никакой из сроков, устранить все "шероховатости" ("inconsistencies", дело было в Дерби, РР)
Затем аналогично - снизу вверх - выбрали язык
Остановились на C++. Solaris Sparc C++ рассказывал, что не так, не давал собрать приложение пока с его точки зрения всё не придёт в порядок, и это настраивалось ещё строже. Я выкрутил все настройки на максимум, и просто переписал на C++ одну из программок, добившись, чтобы не было ни одного предупреждения
И баг пропал сам собой
Кончилось тем, что РР поручил своему индийскому отделу переписать свои фортрановские программки на C++
Нужно как-то изменить ситуацию в вашу пользу. В текущем виде это нерешаемо
Лично я за прозрачность, но никому не навязываю. Со всеми поговорить, или зайти сверху, или сделать чтобы заказчик хотел именно ваш код на проде
Шансы саботажа все равно будут, но это уже решаемые проблемы.
Можно пойти более тёмной дорожкой, так у нас один товарищ делал. Втихаря выкладывал на прод, прятал концы, валил на других, не вёл версионность, не все пушил в ветку чтобы никто не разобрался, что он обновил. Это имеет свои минусы, но даёт свободу действий на некоторое время. В нашем случае он потихоньку переполз на другую должность, где все эти качества оказались полезны команде
Может, облегчить этот кусок, перенести в другие части?
У нас был как-то период, когда один гений ушёл, и кусок проекта вообще невозможно стало трогать. Все были примерно равной квалификации, гений к нам пришёл годом позже, и просто никто не решался. Тупо добавляли сбоку-сверху и не шевелили внутри
Я тогда как сотрудник техподдержки объяснил эксплуатации, что есть баги, которые мы не правим совсем, только компенсируем. И согласовал, что часть функционала мы перенесём на бэк и в базу.
База у нас стала "мудрой" - она научилась понимать любую входящую ерунду, и исходя из известных багов принимала решение, что на самом деле случилось и как это разложить по табличкам
Потом, когда ситуация с багами сдвинулась с мёртвой точки - мы облегчили базу обратно до "умной"
Мне просто казалось важным, чтобы проект был непрерывно адекватен команде разработчиков, и сообразно переносил функциональность из части где затык в другую где работа кипела
ну, это был процесс :)
наш начальник держал в курсе директорат наш и заказчика, и получил неформальное добро на денежку, но только в случае успешного успеха
аналитик и поддержка вместе раз в неделю рассказывали о продвижении архитектору, РП и ребятам заказчика, раз в месяц - стейкхолдеру
а разраб имел полноценную тестовую зону идентичную проду, на которой он мог полгода пробовать кусочки в любое время
код ревью делал лично тимлид разработки, после него глянули все разрабы кто хотел примерно за месяц
ещё месяц пробовали это выкатывать на тестовую зону и разраб допиливал
как получилось вывести на тестовую зону - попробовали на прод. Выводили неделю: первые два раза откатывались, потом на третий всё взлетело
как взлетело - разраб смержил в мастер
Хе, да, в восьмером пробовал :) совещались недели три, представления о прекрасном так и не пришли к общему знаменателю. Оставили это дело и смирились, что есть у нас серая зона, в которой всё долго. Ребята до сих пор стараются её вообще не трогать
Один бунтарь, который считал что мы все неправильные, отсел на полгода, и переписал в одного полпроекта на своих любимых инструментах, с учётом всех прошлых и части будущих хотелок. Когда мы это вывели с очередным обновлением - эксплуатация была в шоке, а заказчик - счастлив! Работы шли через операционные расходы, т.е. по линии техподдержки, потом задним числом впечатлённый владелец бюджета всё покрыл в очередном договоре
думается мне, поможет рефакторинг, декомпозиция, доки-логи и ответственность
чётко договориться в команде, что есть архитектурный баг, есть баг постановки, баг бизнес-функциональных требований - и программный баг. И все поровну тянут баги в своей ЗО
дробить задачки. Цель - доработку программы в своей ЗО самый золоторукий программист делает не более 8 часов напряжённой работы
логировать и документировать (желательно автоматически), рефакторить. Если не согласуют, то тихо, фоном - потом спасибо скажут.
Тогда и баги в коде будут чиниться за час, со всеми "подумать как лучше"
О, классно. Вот как вы цитируете :) Вот этого не понимаю я :)
Чтобы понимать, на что уходит месяц, мне не хватает специфики проекта. Месяц это очень большой срок
У нас (боевые случаи):
разраб поднимает своего тимлида, тот разводит руками, разраб обращается к аналитику - 20 минут. Аналитик открывает базу, чинит одно место в коде, второе показывает разрабу - 30 минут. Разраб чинит указанное место - 5 минут. Поддержка отписывается что всё готово, согласуйте вывод - 5 минут. Вот один час
поддержка берётся за раскопки, предлагает готовый кусочек кода разрабу - 30 минут. Разраб крутит пальцем, предлагает поменять, условно, больше на меньше и больше ничего не трогать. Поддержка и разраб идут к аналитику, перетирают - 10 минут. Ловят большое начальство, совещаются; решение: сейчас не делать ничего, войдёт в следующий заказ. Клиенту отписываются пока решать обходным путём, скоро будет хорошо - 20 минут. Один час
Извините, не был точен: я лишь про то, что важно разрешать себе полчаса-час подумать-пораскапывать-посовещаться, как бы ни наседали
И тогда скорее всего получится надёжно, и по этому поводу больше не придут
Насчёт месяца и красиво - это очень хлопотно согласовать, но если все согласны, от владельца бюджета до эксплуатации, то почему бы и нет. Так у нас обычно начинались переговоры, из которых рождалась следующая версия системы
естественный отбор :)
починить одно и то же место можно раз, другой, потом придётся сделать на совесть, просто чтобы прекратился вал инцидентов про одно и то же - либо потонуть в поддержке
опять же, сотрудник поддержки обычно остро чувствует и понимает, что бизнес стоит на доверии клиентов. Когда бизнес теряет доверие клиентов - клиенты просто уходят к другому, и бизнес можно закрывать. Поэтому не бывает ни поддержки себя любимого, ни поддержки босса, ни поддержки заказчика - есть только поддержка пользователей. Отсюда и особые права поддержки, и вес, а с ним - возможность потратить чуть больше времени, зато сделать раз и навсегда
Из практики видел два счастливых исключения: рефакторинг и поддержка
В моей первой команде рефакторинг проводился по чайной ложке с каждой задачкой, в параллели. Во второй где счастливо проработал больше семи лет - рефакторингом занялись на полгода ценой полной остановки проекта. Слышал о командах, где рефакторинг проводят регулярно, выделяя, условно, один спринт в году. Не суть. Когда проводится рефакторинг - красота, правильность, надёжность в лице объективных метрик вроде связности и зацепления, заменяемости и ответственности - на одном из первых мест
Техподдержка частенько инициирует задачки, в которых правильность-надёжность-красота на первых местах. Понятно, большинство из нас меряет всё-таки в объективных метриках, но смысл такой. Когда мы делаем задачки поддержки - мы стараемся жить правильно :)
Тоже подумал о PL SQL
Также - Delphi последних лет
Но сам же могу накидать контр примеры. Язык на то и язык чтобы позволять и стихи, и базарную брань
Ну да, там действительно попроще с ИТ-безопасностью, при всей озабоченности их политиков правами человека у нас реально лучше дело с тайной перс.данных, личной жизни, защитой от взлома и т.д.
Возможно, речь о признании их QR-кодов на территории РФ, т.к. в случае выезда нашего гражданина европейцы ему QR-код сделают сами через местные институты
Возможно, наконец-то напишут удалённое обновление. Машина-то недешёвая, премиальная марка всё-таки
https://www.bostondynamics.com/solutions/inspection
Мобильный измеритель - удобно! А ещё передаётся видеопоток в высоком качестве. Так что полагаю дело не только в температуре. Человек-патрульный - это угроза, собака-робот людей скорее забавляет
Любопытно, что на Гавайях есть приюты. С их-то климатом и фауной - можно ночевать на любой скамейке или даже просто на земле
Прокомментировал оригинал публикации
Скопирую в перевод, возможно, это добавит контекста статье
Sorry to hear that
Back in 2008-2009 I was lucky to work for Design Bureau of Sir Henry Royce, Rolls-Royce plc. Glorious company!
They have one of the principles "do not fix what is working". They had Cray 1 mainframe back in 2008-9, it was working all right, so everyone had to deal with that.
A predecessor of CP/M which in turn was a predecessor of DOS, some ancient Fortran version, programs names made of 2 letters and 2 numbers, flat folder structure with no subfolders, debugging tools virtually absent - lots of fun in 2009.
It's own terminals were substituted with some driver plugged into Putty etc. long ago, yet still it needed integration into modern network, some protection from network threats, some interface with programs on regular laptops and computers written on modern language (to the sincere horror of everyone who writes for it, but that's another question)
So yeah, those who want to find their mainframe - will find it even these days
К вопросу о мейнфреймах
В 2008-2009 мне посчастливилось работать в Роллс-Ройсе. Отличная компания, там не чинят то, что работает. В частности, отлично работал Cray 1.
А раз он работал, то приходилось программировать на нём. Какой-то предок CP/M который сам предок DOS - и зашитый Фортран. Программы две буквы две цифры, файлы данных вечерами букв имя три расширение, плоская структура папок без вложенности.
Как там в этом году - не подскажу, но кое-где как вот в таких сильных традицией местах мейнфреймы могут быть по сей день востребованы
Понятное дело, памяти на них по нынешним временам немного, да и вывод на родные терминалы давно перенаправлен в Putty и пр., поэтому то что на нём пишут приходится как-то защищать от сетевых угроз, стыковать с программами на современных ПК и языках и т.д. (к ужасу всех это дело обслуживающих, но это уже вопрос другой)
Так что кому сегодня надо мейнфрейм - свой мейнфрейм найдёт ☺️