Когда мы начинали (1993-й, на минуточку, год), "заказчику" вообще ничего не надо было "и так все хорошо". Приходилось убеждать, пилотные версии вообще за свой счет ставили (с условием что мы потом будет обслуживать и з это уже деньги получать плюс чтобы иметь работающие объекты).
Софт весь был наш, железо тоже наше (контроллеры - "домовые" + УСО - Устройство Сопряжения с Объектом - то, к чему, собственно, подключаются устройство). Только конечные устройства те, что стояли уже на объектах. Все протоколы связи сами писали. Разрабатывали формальную классификацию устройств для горячего подключения.
В конечных версиях были инструменты для создания карт-подложек (из яндекса или 2ГИС), "редактор объектов" где можно было размещать устройства на карте.
Там много чего было. В конечной версии вообще был "клиент-сервер" - микроядро, обеспечивающее работу с контроллерами и подключаемые к нему интерфейсные клиенты разного типа и назначения (для диспетчера, для администратора, для аварийных бригад, монитор разработчика, позволяющий трейсить все, что происходит в микроядре удаленно в реальном времени...)
Все это было распределенное - УСО к домовому котроллеру по RS485 подключалось, дальше уже домовые с микроядром по UDP. Интерфейсные клиенты к микроядру по TCP подключались.
В каком оно сейчас состоянии не знаю - в 17-м году ушел оттуда, там административные заморочки начались неприятные. Хотя был одним из немногих (4-5 человек), что был в проекте с самого начала.
И все это силами очень небольшой команды - "координатор", один человек на разработке контроллеров, один на разработке аналоговых частей системы (блоки питания, модули ГГС - громкоговорящей связи), на софте верхнего уровня сначала я один был, потом еще один человек пришел - я занимался микроядром и парой-тройкой служебных утилит, второй человек делал интерфейсные клиенты. Ну и плюс был участок сборщиков и монтажников. Но в разработке всего 5-6 человек на все - и софт и железо.
Ну вообще-то, "картинка" - это несколько слоев и уровней детализации. Те же устройства не рисуются на картинке хардкодом, а накладываются в виде иконки поверх изображения.
И да, в БД конфигурации есть привязки каждого устройства к объекту где оно расположено.
Анимация тут не нужна. Но понимать что и где у вас расположено очень помогает.
В обычной работе все эти цифры на экране постоянно не нужны. Нужно лишь понимать с первого взгляда - норма или нет. Ну иметь возможность посмотреть текущее состояние по конкретному устройству.
Крайне неинформативно. Когда все нормально, никто не будет сидеть и пялиться в экран. А вот когда ненормально, должна быть полная информация - где? что? когда случилось?
Если у вас будет не оно хранилище, а, к примеру, 10 - все это на экран не влезет. Секция 1, секция 2 - где это? Что это вообще?
В своей время делали систему мониторинга инженерного оборудования зданий для ЖКХ (система диспетчеризации). Там лифты, охрана служебных помещений и много чего еще. Обслуживало оно достаточно много объектов разбросанных не только в пределах одного района, но по всему городу. Были объекты, где одних лифтов было по 300-500 штук подключено.
В основе интерфейса - карта на которой выделены обслуживаемые дома. Можно ткнуть на дом и получить его подробную схему - что где на нем расположено. Там же можно посмотреть текущее состояние любого устройства, его историю (что с ним происходило, архив событий и т.п.)
Если на доме "что-то не так", он подсвечивается отдельно.
Второй обязательный элемент - список аварийных сообщений куда выводятся события. Опять с полной расшифровкой на нормальном языке типа "ул. Строителей, д. 35, подъезд 2, грузовой лифт - двери шахты открыты".
Ведется полный лог - когда, где что случилось + реакция диспетчера (когда и что было сделано) - каждое аварийное событие требует "обработки" - реакции диспетчера.
Основы этого интерфейса закладывались еще в 93-94-м годах (мы были первыми в РФ кто начал работать в этом направлении) и получилось настолько удачно, что последующие разработки конкурентов в той или иной степени шли по тому же пути уже.
Диспетчеры зачастую - женщины среднего возраста, уровень среднего пользователя ПК. Осваивали интерфейс очень быстро - настолько там все было просто и интуитивно понятно.
А в целом РПГ можно считать одним из прообразов современных баз данных
Изначально RPG разрабатывался как эмулятор табуляторов на машинах IBM 1401. Чтобы сохранить и не переписывать все то, что было написано для табуляторов.
В целом программа на RPG работала с основной таблицей (primary table) в циклическом режиме (cycle mode) перебирая последовательно все записи в таблице до тех пор, пока не дойдет до конца файла или (по каким-то условиям) служебный индикатор "последняя запись" (*inlr) не будет установлен в состояние *on.
Т.е. там не было оператора return - написанный код крутился в цикле.
Таблица в той терминологии называется "физический файл данных" - фактически хранилище. Для определения порядка доступа к записям (access path) к ней существует один или несколько "логических файлов" (аналог индексов, но несколько более широкий).
На самом деле работать не сложнее чем в графике. Все делается с клавиатуры, не надо руку на мышь перебрасывать и обратно.
Но это чисто технические интерфейсы, для внутреннего пользования. Для "наружного" как сказал выше. Десктопная система, которая получает/отправляет данные с/на сервер через запросы
На самом деле, это серверная система. Сажать за нее пользователей - ну такое себе. Она не для этого.
Хотя сделать там текстовый интерфейс не проблема. Это достаточно просто и для этого есть все средства. И работать с ним ничуть не сложнее чем с графическим в винде. Даже быстрее при минимальном навыке.
И это еще простенькое. Там и окна могут быть и меню и много чего.
Но на самом деле никто не мешает На пользовательских местах использовать десктопные системы, а информацию он будут получать с сервера через очереди или вебсервисы или еще как-то...
Обычно так и делается. Сервер - это ядро системы. Там хранение и обработка данных. Не более того. И не надо нагружать его каким-то лишними интерфейсами.
Вот заходите вы в банковское приложение на телефоне. "Современный интерфейс". Но это только интерфейс. Все данные он получает с сервера на AS/400 на самом деле. Через REST API - Вебсервис на ESB шине - сервис-модуль на AS/400.
На самом деле система команд в AS/400 намного удобнее и логичнее чем в том же линуксе. Да, их много, референс по системным командам порядка 2250 страниц, но, как правило, вам достаточно помнить десяток-другой из тех, с чем работаете постоянно.
Вам не надо помнить все возможные параметры - вы просто вводите команду и, если требуются какие-то параметры, получаете интерфейс (да, текстовый, но это интерфейс) со всеми полями и подсказками что куда вводить, возможные варианты и т.п. Тут не надо продираться через меню, достаточно просто запомнить набор нужных вам команд. Тем более, что там очень простой и логичный синтаксис.
То, что "выглядит как MS-DOS" на самом деле просто задание (job). Одно из многих, работающих на сервере. Вы можете открыть несколько терминальных сессий и для каждой сессии будет свое задание.
Тут надо понимать, что это многопользовательская серверная система, а не десктоп.
Во-первых, почему Вы решили что это система старая? Какие сервера у вас стоят и какая версия самой ОС?
Мы работаем на Power9 и версии 7.4. Сейчас актуально Power10 И версия ОС 7.6
Система живет и развивается примерно раз в два года выходит новая версия. Минорные изменения (TR - Technology Refresh) выходят 2-3 раза в год, обычно весной и осенью.
Так что там все вполне современное. И много такого, чего в "современных системах" нет и никогда не будет.
Также есть системные журналы по которым вы можете отслеживать изменение любого (если для него включено журналирование) системного объекта (не только таблиц, но и много чего еще). Мы это используем для реализации механизма т.н. "журнальных мониторов" которые в фоне отслеживают изменения в таблицах и при необходимости вызывают соответствующие программы-акторы для обработки этих изменений. Как пример - клиент открыл новый счет, необходимо отправить уведомление в ФНС. Отслеживаем изменение таблицы счетов по системному журналу, если появился новый счет - вызывается соотв. ЖМ который формирует сообщение для отправки в ФНС.
Увы, но для работы нужна винда. Есть пара критических программ, которых под линуксом нет и не будет.
Пытататься завести их через вайн очень хлопотно. Как штаны через голову одевать.
И вообще, вся рабочая инфраструктура под виндой.
А разработка у меня вообще для AS/400... Это серверная платформа совершенно другого уровня.
Так что линукс так, каприз художника. Побаловаться. Ставил чтобы аоеять можно ли в моей ситуации бесшовно перейти на нее. Выяснилось что нет. Так что линуксовая машина работает а качестве VDI терминала к виртуалке, которая тоже под виндой.
В целом, никаких предубеждений, как и "пламенной любви" ни к тому, ни к другому нет. Просто рабочие инструменты.
С точки зрения разработчика АС-ка кратно больше уважения и симпатий вызывает. Но это чисто серверная история. И узкоспециализированная.
Пишут что вейланд в минте пока не стабилизирован, хотя попробовать его можно (где-то на входе есть переключатель, сам пока не пробовал). Но пока рекомендуют Х11.
В качестве файлового менеджера использую double commander. У меня один комп под виндой, второй под линуксом - мне предпочтительнее чтобы одинаково было хотя бы на уровне подобных вещей...
БЩУ :-)
Мы работали с ЖКХ, а там бюджеты...
Когда мы начинали (1993-й, на минуточку, год), "заказчику" вообще ничего не надо было "и так все хорошо". Приходилось убеждать, пилотные версии вообще за свой счет ставили (с условием что мы потом будет обслуживать и з это уже деньги получать плюс чтобы иметь работающие объекты).
Софт весь был наш, железо тоже наше (контроллеры - "домовые" + УСО - Устройство Сопряжения с Объектом - то, к чему, собственно, подключаются устройство). Только конечные устройства те, что стояли уже на объектах. Все протоколы связи сами писали. Разрабатывали формальную классификацию устройств для горячего подключения.
В конечных версиях были инструменты для создания карт-подложек (из яндекса или 2ГИС), "редактор объектов" где можно было размещать устройства на карте.
Там много чего было. В конечной версии вообще был "клиент-сервер" - микроядро, обеспечивающее работу с контроллерами и подключаемые к нему интерфейсные клиенты разного типа и назначения (для диспетчера, для администратора, для аварийных бригад, монитор разработчика, позволяющий трейсить все, что происходит в микроядре удаленно в реальном времени...)
Все это было распределенное - УСО к домовому котроллеру по RS485 подключалось, дальше уже домовые с микроядром по UDP. Интерфейсные клиенты к микроядру по TCP подключались.
В каком оно сейчас состоянии не знаю - в 17-м году ушел оттуда, там административные заморочки начались неприятные. Хотя был одним из немногих (4-5 человек), что был в проекте с самого начала.
И все это силами очень небольшой команды - "координатор", один человек на разработке контроллеров, один на разработке аналоговых частей системы (блоки питания, модули ГГС - громкоговорящей связи), на софте верхнего уровня сначала я один был, потом еще один человек пришел - я занимался микроядром и парой-тройкой служебных утилит, второй человек делал интерфейсные клиенты. Ну и плюс был участок сборщиков и монтажников. Но в разработке всего 5-6 человек на все - и софт и железо.
Но в Лифтопедии до сих пор есть :-)
Ну вообще-то, "картинка" - это несколько слоев и уровней детализации. Те же устройства не рисуются на картинке хардкодом, а накладываются в виде иконки поверх изображения.
И да, в БД конфигурации есть привязки каждого устройства к объекту где оно расположено.
Анимация тут не нужна. Но понимать что и где у вас расположено очень помогает.
В обычной работе все эти цифры на экране постоянно не нужны. Нужно лишь понимать с первого взгляда - норма или нет. Ну иметь возможность посмотреть текущее состояние по конкретному устройству.
Крайне неинформативно. Когда все нормально, никто не будет сидеть и пялиться в экран. А вот когда ненормально, должна быть полная информация - где? что? когда случилось?
Если у вас будет не оно хранилище, а, к примеру, 10 - все это на экран не влезет. Секция 1, секция 2 - где это? Что это вообще?
В своей время делали систему мониторинга инженерного оборудования зданий для ЖКХ (система диспетчеризации). Там лифты, охрана служебных помещений и много чего еще. Обслуживало оно достаточно много объектов разбросанных не только в пределах одного района, но по всему городу. Были объекты, где одних лифтов было по 300-500 штук подключено.
В основе интерфейса - карта на которой выделены обслуживаемые дома. Можно ткнуть на дом и получить его подробную схему - что где на нем расположено. Там же можно посмотреть текущее состояние любого устройства, его историю (что с ним происходило, архив событий и т.п.)
Если на доме "что-то не так", он подсвечивается отдельно.
Второй обязательный элемент - список аварийных сообщений куда выводятся события. Опять с полной расшифровкой на нормальном языке типа "ул. Строителей, д. 35, подъезд 2, грузовой лифт - двери шахты открыты".
Ведется полный лог - когда, где что случилось + реакция диспетчера (когда и что было сделано) - каждое аварийное событие требует "обработки" - реакции диспетчера.
Основы этого интерфейса закладывались еще в 93-94-м годах (мы были первыми в РФ кто начал работать в этом направлении) и получилось настолько удачно, что последующие разработки конкурентов в той или иной степени шли по тому же пути уже.
Диспетчеры зачастую - женщины среднего возраста, уровень среднего пользователя ПК. Осваивали интерфейс очень быстро - настолько там все было просто и интуитивно понятно.
Это по-настоящему серьезная работа. На самом деле есть чем гордиться. Не каждому в жизни аыпадает удача сделать что-то такого уровня
Изначально RPG разрабатывался как эмулятор табуляторов на машинах IBM 1401. Чтобы сохранить и не переписывать все то, что было написано для табуляторов.
В целом программа на RPG работала с основной таблицей (primary table) в циклическом режиме (cycle mode) перебирая последовательно все записи в таблице до тех пор, пока не дойдет до конца файла или (по каким-то условиям) служебный индикатор "последняя запись" (*inlr) не будет установлен в состояние *on.
Т.е. там не было оператора return - написанный код крутился в цикле.
Таблица в той терминологии называется "физический файл данных" - фактически хранилище. Для определения порядка доступа к записям (access path) к ней существует один или несколько "логических файлов" (аналог индексов, но несколько более широкий).
RPG до сих пор жив на платформе IBM i и остается там основным средством для работы с БД. Конечно, с тех пор он сильно изменился - теперь это нормальный процедурный язык со свободным синтаксисом и достаточно богатыми (вплоть до использования SQL непосредственно в коде) возможностями.
На самом деле работать не сложнее чем в графике. Все делается с клавиатуры, не надо руку на мышь перебрасывать и обратно.
Но это чисто технические интерфейсы, для внутреннего пользования. Для "наружного" как сказал выше. Десктопная система, которая получает/отправляет данные с/на сервер через запросы
На самом деле, это серверная система. Сажать за нее пользователей - ну такое себе. Она не для этого.
Хотя сделать там текстовый интерфейс не проблема. Это достаточно просто и для этого есть все средства. И работать с ним ничуть не сложнее чем с графическим в винде. Даже быстрее при минимальном навыке.
И это еще простенькое. Там и окна могут быть и меню и много чего.
Но на самом деле никто не мешает На пользовательских местах использовать десктопные системы, а информацию он будут получать с сервера через очереди или вебсервисы или еще как-то...
Обычно так и делается. Сервер - это ядро системы. Там хранение и обработка данных. Не более того. И не надо нагружать его каким-то лишними интерфейсами.
Вот заходите вы в банковское приложение на телефоне. "Современный интерфейс". Но это только интерфейс. Все данные он получает с сервера на AS/400 на самом деле. Через REST API - Вебсервис на ESB шине - сервис-модуль на AS/400.
А к самому серверу доступ очень ограничен.
А терминал линукса вам как что кажется?
На самом деле система команд в AS/400 намного удобнее и логичнее чем в том же линуксе. Да, их много, референс по системным командам порядка 2250 страниц, но, как правило, вам достаточно помнить десяток-другой из тех, с чем работаете постоянно.
Вам не надо помнить все возможные параметры - вы просто вводите команду и, если требуются какие-то параметры, получаете интерфейс (да, текстовый, но это интерфейс) со всеми полями и подсказками что куда вводить, возможные варианты и т.п. Тут не надо продираться через меню, достаточно просто запомнить набор нужных вам команд. Тем более, что там очень простой и логичный синтаксис.
То, что "выглядит как MS-DOS" на самом деле просто задание (job). Одно из многих, работающих на сервере. Вы можете открыть несколько терминальных сессий и для каждой сессии будет свое задание.
Тут надо понимать, что это многопользовательская серверная система, а не десктоп.
Во-первых, почему Вы решили что это система старая? Какие сервера у вас стоят и какая версия самой ОС?
Мы работаем на Power9 и версии 7.4. Сейчас актуально Power10 И версия ОС 7.6
Система живет и развивается примерно раз в два года выходит новая версия. Минорные изменения (TR - Technology Refresh) выходят 2-3 раза в год, обычно весной и осенью.
Так что там все вполне современное. И много такого, чего в "современных системах" нет и никогда не будет.
Основное преимущество - БД (DB2) интегрирована в саму ОС. Т.е. может работать напрямую с железом. А это и надежность и производительность. Причем, работать с БД вы можете как посредством SQL, так и посредством прямого доступа к таблицам (оба способа имеют свои преимущества и свои ограничения).
Также есть системные журналы по которым вы можете отслеживать изменение любого (если для него включено журналирование) системного объекта (не только таблиц, но и много чего еще). Мы это используем для реализации механизма т.н. "журнальных мониторов" которые в фоне отслеживают изменения в таблицах и при необходимости вызывают соответствующие программы-акторы для обработки этих изменений. Как пример - клиент открыл новый счет, необходимо отправить уведомление в ФНС. Отслеживаем изменение таблицы счетов по системному журналу, если появился новый счет - вызывается соотв. ЖМ который формирует сообщение для отправки в ФНС.
И таких вкусностей тут очень много.
У меня решилось добавление переключения раскладки в XKB
Так работает хорошо
Это не просто косплей. Это привычная среда и отсутствие необходимости думать "а как это сделать тут, а как это сделать там"
Я в принципе не могу пользоваться однопанельными менеджерами. Привык две панели + на каждой еще по несколько вкладок.
Плюс там же много инструментов еще.
F3 - просмотр
F4 - редактирование (Notepad++ в винде, NotepadNext в линуксе
Есть сравнение по содержимому с возможностью копировать отличия туда-сюда (в винде WinMerge, в линуксе Meld)
Есть групповое переименование с кучей шаблонов.
Есть возможность запуска терминала в нужной папке.
В линуксе выглядит так
В винде так
Удобный и привычный инструмент.
Увы, но для работы нужна винда. Есть пара критических программ, которых под линуксом нет и не будет.
Пытататься завести их через вайн очень хлопотно. Как штаны через голову одевать.
И вообще, вся рабочая инфраструктура под виндой.
А разработка у меня вообще для AS/400... Это серверная платформа совершенно другого уровня.
Так что линукс так, каприз художника. Побаловаться. Ставил чтобы аоеять можно ли в моей ситуации бесшовно перейти на нее. Выяснилось что нет. Так что линуксовая машина работает а качестве VDI терминала к виртуалке, которая тоже под виндой.
В целом, никаких предубеждений, как и "пламенной любви" ни к тому, ни к другому нет. Просто рабочие инструменты.
С точки зрения разработчика АС-ка кратно больше уважения и симпатий вызывает. Но это чисто серверная история. И узкоспециализированная.
А что у вас сейчас используется? Х11 или вейланд?
Пишут что вейланд в минте пока не стабилизирован, хотя попробовать его можно (где-то на входе есть переключатель, сам пока не пробовал). Но пока рекомендуют Х11.
В качестве файлового менеджера использую double commander. У меня один комп под виндой, второй под линуксом - мне предпочтительнее чтобы одинаково было хотя бы на уровне подобных вещей...
Так не мне... Я сам на форум с той же проблемой пошле. Там решение подсказали...
Я не в гугле смотрел :-)
Mint 22.3 Zena, Cinnamon 6.6.5
Ссылку на website привел выше - ведет именно туда
mintreport
Да, Вы правы. Поставил другую тему, стало нормально
Ну я специально ничего такого не ставил. На 22.2 все аыглядело нормально, а после обновления на 22.3 просто кровь из глаз...
Может, конечно, в темах где-то покопаться...
У меня это меню просто ублюдочно стало выглядеть...
И как поправить пока не понял...
Может виной нестандартное разрешение экрана (нут старый очень) - 1366х768...