А у контент-менеджеров прямой доступ к Git остался? Если нет, то как будет идти разбор проблемы "Кто поменял эту статью"? А если остался, то решение работает до тех пор, пока не появится один любопытный
Если копнуть совсем глубоко - то в основном это OPC (в большинстве своем OPC DA). Но непосредственно источником может быть отдельная система (агрегат/установка может иметь свою систему управления с собственным интерфейсом доступа к данным)
Ну так не надо смешивать в одной кастрюле разработку новой системы и нового дизайна. Это принципиально разные вещи. Умные люди придумали, что можно разделить фронт и бек в том числе и для того, чтобы поменять бек без затрагивания фронта. PS. Я знаю (не понаслышке), что сделать на НЛМК новую MES систему без переделки фронтовой части не получится, потому что ее нет, это двух-звенная архитектура, но был ли смысл лезть с модным дизайном в UI без UX? Это больше похоже на желание пустить пыль в глаза менеджерам заказчика, ибо изменения бэковой части они не смогут увидеть
Это логичное желание бизнеса - что потеряем, если закроем? Тот же пример с человеком - можно и руку отрезать, жить будет. Еще можно ноги почикать, и посадить за сидячую работу. <Сарказм> Еще и на брюках экономия </Сарказм> Но бизнес не догадывается, что может быть нелинейная зависимость, т.е. не просто x+y, а x + x*y, и проценты влияния здесь полезны только в моменте, при всех прочих постоянных. А такого в реальной жизни вряд ли можно найти
А почему нельзя этот прогноз внедрить в систему управления турбиной? Зачем заставлять оператора шевелить лопатками вручную, если можно сделать это автоматически? Разве индустрия 4.0 не про это?
Здесь вы немного неправы. Прокатные станы на НЛМК новые довольно активно строили и обновляли (и не только их). Просто касалось это станов холодной прокатки. И, кстати, там допуск по толщине играет большую роль, так как на холодной прокатке выходят на конечную толщину. Меньшая освещенность этих событий связана, наверное, с тем, что сами станы более компактные, не настолько масштабные, как стан горячей прокатки
Очень "опасный" текст для неокрепшего ума. Есть несколько неточностей, которые могут привести к принципиально неправильному пониманию работы kafka. А ведь идеи, заполненные в ней, очень эстетично и эффективно решают задачи, которые стоят перед разработчиками и потребителями продукта.
Про первую неточность уже написали:
Хотя в некоторых случаях продьюсер может направить сообщение в конкретный топик.
Продюсер обязан указать топик, в который он отправляет сообщение, но может также указать и раздел (партицию, partition) топика.
Ещё один блок, бросившийся в глаза:
здесь ключ не является обязательным и не несет для Kafka никакого смысла
Значение ключа несёт достаточно много смысла для kafka. Это основной признак группировки сообщений и маркер, что сообщения относятся к одной сущности. Через этот маркер работают механизмы распределения сообщений по разделам (partition, партициям), а это важный момент для соблюдения очередности получения сообщений в рамках одной сущности (если, конечно, не пытаться пойти в разрез с заложенной идеологией, сознательно или нет), отсюда же растут ноги у log compaction, и возможному снижению траффика для консьюмера.
Не совсем понятно, зачем нужна LDAP-синхронизация если в базу пользователи ходят под служебными учетками dbx-... Можете пояснить эту тему чуть подробнее?
Мой опыт говорит (понятно, что это легко может быть ошибкой выжившего), что в России в сертификаты не очень смотрят, поэтому получать такой сертификат или нет - решает каждый сам
Тема статьи о том, что быть руководителем скучно, а по факту разбираются ошибки начинающего руководителя. А по теме статьи? Почему разработчику на руководящей должности скучно?
Я для себя выделил следующие моменты: ритм задач принципиально другой, сфера деятельности отличается, да и скиллы совсем другие напрягать приходится (что неудобно и выматывает)
<оффтоп он>
За словосочетание "из изоленты и палок" у секты свидетелей синей изоленты есть отдельное наказание, как-то связанное с синей изолентой
</оффтоп офф>
Безусловно, есть специфика каждого из производств, но ее можно перенести в соответствующие специфике модули, и вызывать через коллбеки/декораторы. Но общий поток обработки информации можно же унифицировать? Я говорю не об архитектуре уровня инфраструктуры, а об архитектуре в более прикладном варианте, общей парадигме построения MES-систем.
Иначе легко можно построить вроде общую архитектуру, но работать будет по разному. Гипотетический пример: все сиситемы используют kafka для передачи событий, но одна система публикует всю информацию, связанную с ссобытием, вторая - изменения, третья, только идентификатор объекта, с которым произошло событие (а за изменением обратитесь к системе источнику). Не опасаетесь оставить после себя такой разномастный подход?
Скажите пожалуйста, про планируемые итоги распила на микросервисы: планиурется сделать единую MES, или так и останутся на каждое производство что-то свое? А ведь это может помочь решить проблему с разными компонентами КМК
На самом деле времени прочитать осмысленное предложение мало, но реклама должна запечатлеть образ, а, значит, времени, предостаточно.
Но берите выше, эта вещь (а именно, реклама), каждый свой сеанс отнимает по 1,1 секунде у водителя, лишая его возможности смотреть в навигатор, на дорогу и т.п. Что же господа из Яндекса не озаботились отметить, что роста аварийности не было?
Master-detail был и раньше, не спорю. И даже с визардом. Но сделан был коряво, например, в 4 версии (ее я помню лучше) генерировал две страницы: одну для master, другую для detail.
При этом можно было сделать и на одной странице, с динамическим обновлением, но основательно поупражнявшись с DA. И да, только на classic report'e, интерактивный репорт мог быть только один на страницу
Хорошая, подробная статья.
Не скажу, что все в ней было новое (для меня оказались интересными возможности IG), но за добротную русскую справку спасибо.
Сам же APEX по скорости развития сильно отстаёт от передового HTML. Что-то простое сделать элементарно, но малейшее отклонение от канона сильно бьёт по пальцам.
Взять тот же master-detail. Реализация его на одной странице «из коробки» появилась только в 5 версии. До этого приходилось городить хитрые dynamic actions.
А что сейчас используете?
Influx пробовали пристроитьта стек в 2016 году для хранения сырых временных рядов. Привлекли continues queries для построения равномерно разреженных рядов. От идеи пришлось отказаться из-за «краевых эффектов». Плюс в то время в инете нашлось много issues на тему просадки производительности influx при росте базы. Решили не рисковать и остаться на проприетарным хранилище трендов
А у контент-менеджеров прямой доступ к Git остался? Если нет, то как будет идти разбор проблемы "Кто поменял эту статью"?
А если остался, то решение работает до тех пор, пока не появится один любопытный
Если копнуть совсем глубоко - то в основном это OPC (в большинстве своем OPC DA).
Но непосредственно источником может быть отдельная система (агрегат/установка может иметь свою систему управления с собственным интерфейсом доступа к данным)
Выглядит замечательно!
А MES у вас уже по всем основным производствам в таком виде развернут?
Ну так не надо смешивать в одной кастрюле разработку новой системы и нового дизайна. Это принципиально разные вещи. Умные люди придумали, что можно разделить фронт и бек в том числе и для того, чтобы поменять бек без затрагивания фронта.
PS. Я знаю (не понаслышке), что сделать на НЛМК новую MES систему без переделки фронтовой части не получится, потому что ее нет, это двух-звенная архитектура, но был ли смысл лезть с модным дизайном в UI без UX? Это больше похоже на желание пустить пыль в глаза менеджерам заказчика, ибо изменения бэковой части они не смогут увидеть
Это логичное желание бизнеса - что потеряем, если закроем?
Тот же пример с человеком - можно и руку отрезать, жить будет. Еще можно ноги почикать, и посадить за сидячую работу. <Сарказм> Еще и на брюках экономия </Сарказм>
Но бизнес не догадывается, что может быть нелинейная зависимость, т.е. не просто x+y, а x + x*y, и проценты влияния здесь полезны только в моменте, при всех прочих постоянных. А такого в реальной жизни вряд ли можно найти
А почему нельзя этот прогноз внедрить в систему управления турбиной? Зачем заставлять оператора шевелить лопатками вручную, если можно сделать это автоматически? Разве индустрия 4.0 не про это?
Здесь вы немного неправы. Прокатные станы на НЛМК новые довольно активно строили и обновляли (и не только их). Просто касалось это станов холодной прокатки. И, кстати, там допуск по толщине играет большую роль, так как на холодной прокатке выходят на конечную толщину.
Меньшая освещенность этих событий связана, наверное, с тем, что сами станы более компактные, не настолько масштабные, как стан горячей прокатки
Очень "опасный" текст для неокрепшего ума. Есть несколько неточностей, которые могут привести к принципиально неправильному пониманию работы kafka. А ведь идеи, заполненные в ней, очень эстетично и эффективно решают задачи, которые стоят перед разработчиками и потребителями продукта.
Про первую неточность уже написали:
Продюсер обязан указать топик, в который он отправляет сообщение, но может также указать и раздел (партицию, partition) топика.
Ещё один блок, бросившийся в глаза:
Значение ключа несёт достаточно много смысла для kafka. Это основной признак группировки сообщений и маркер, что сообщения относятся к одной сущности. Через этот маркер работают механизмы распределения сообщений по разделам (partition, партициям), а это важный момент для соблюдения очередности получения сообщений в рамках одной сущности (если, конечно, не пытаться пойти в разрез с заложенной идеологией, сознательно или нет), отсюда же растут ноги у log compaction, и возможному снижению траффика для консьюмера.
Не совсем понятно, зачем нужна LDAP-синхронизация если в базу пользователи ходят под служебными учетками dbx-...
Можете пояснить эту тему чуть подробнее?
Мой опыт говорит (понятно, что это легко может быть ошибкой выжившего), что в России в сертификаты не очень смотрят, поэтому получать такой сертификат или нет - решает каждый сам
Тема статьи о том, что быть руководителем скучно, а по факту разбираются ошибки начинающего руководителя. А по теме статьи? Почему разработчику на руководящей должности скучно?
Я для себя выделил следующие моменты: ритм задач принципиально другой, сфера деятельности отличается, да и скиллы совсем другие напрягать приходится (что неудобно и выматывает)
Вы не поверите, но этому анализу на НЛМК уже много лет. Это один из элементов производственной системы
<оффтоп он>
За словосочетание "из изоленты и палок" у секты свидетелей синей изоленты есть отдельное наказание
, как-то связанное с синей изолентой</оффтоп офф>
Безусловно, есть специфика каждого из производств, но ее можно перенести в соответствующие специфике модули, и вызывать через коллбеки/декораторы. Но общий поток обработки информации можно же унифицировать? Я говорю не об архитектуре уровня инфраструктуры, а об архитектуре в более прикладном варианте, общей парадигме построения MES-систем.
Иначе легко можно построить вроде общую архитектуру, но работать будет по разному. Гипотетический пример: все сиситемы используют kafka для передачи событий, но одна система публикует всю информацию, связанную с ссобытием, вторая - изменения, третья, только идентификатор объекта, с которым произошло событие (а за изменением обратитесь к системе источнику). Не опасаетесь оставить после себя такой разномастный подход?
Скажите пожалуйста, про планируемые итоги распила на микросервисы: планиурется сделать единую MES, или так и останутся на каждое производство что-то свое? А ведь это может помочь решить проблему с разными компонентами КМК
Но берите выше, эта вещь (а именно, реклама), каждый свой сеанс отнимает по 1,1 секунде у водителя, лишая его возможности смотреть в навигатор, на дорогу и т.п. Что же господа из Яндекса не озаботились отметить, что роста аварийности не было?
Master-detail был и раньше, не спорю. И даже с визардом. Но сделан был коряво, например, в 4 версии (ее я помню лучше) генерировал две страницы: одну для master, другую для detail.
При этом можно было сделать и на одной странице, с динамическим обновлением, но основательно поупражнявшись с DA. И да, только на classic report'e, интерактивный репорт мог быть только один на страницу
Не скажу, что все в ней было новое (для меня оказались интересными возможности IG), но за добротную русскую справку спасибо.
Сам же APEX по скорости развития сильно отстаёт от передового HTML. Что-то простое сделать элементарно, но малейшее отклонение от канона сильно бьёт по пальцам.
Взять тот же master-detail. Реализация его на одной странице «из коробки» появилась только в 5 версии. До этого приходилось городить хитрые dynamic actions.
Influx пробовали пристроитьта стек в 2016 году для хранения сырых временных рядов. Привлекли continues queries для построения равномерно разреженных рядов. От идеи пришлось отказаться из-за «краевых эффектов». Плюс в то время в инете нашлось много issues на тему просадки производительности influx при росте базы. Решили не рисковать и остаться на проприетарным хранилище трендов