<оффтоп он>
За словосочетание "из изоленты и палок" у секты свидетелей синей изоленты есть отдельное наказание, как-то связанное с синей изолентой
</оффтоп офф>
Безусловно, есть специфика каждого из производств, но ее можно перенести в соответствующие специфике модули, и вызывать через коллбеки/декораторы. Но общий поток обработки информации можно же унифицировать? Я говорю не об архитектуре уровня инфраструктуры, а об архитектуре в более прикладном варианте, общей парадигме построения 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 при росте базы. Решили не рисковать и остаться на проприетарным хранилище трендов
Попробуйте посмотреть в сторону Crystal Reports или jasper reports (ныне, кажется, TIBCO). Имеется редактор, позволяющий строит сложные отчеты. На выходе экспорт данных во многих форматах — word, excel, html и т.п.
В последнем проекте делали web приложение на базе Oracle с плагином, смотрящим на веб службу, под капотом которой jasper. Пользователи довольны
Потом идёт оценка важности каждой из проблем — сколько времени займёт решение, сколько это будет стоить, и сколько денег принесёт компании (считается прибыль, экономия средств и «добрая карма»). Точные оценки не важны, главное — примерно выделить ТОП-5 вещей, которые можно решить или хотя бы надгрызть за месяц.
Вот тут бы хотелось немного поподробнее, есть ли какая методика оценки стоимости успеха и затрат? Вряд ли вы берете цифры с потолка и все согласны, договариваться надо. Как насчет развеять туман над этой частью совещания (например, в следующей статье упомянуть)?
<оффтоп он>
За словосочетание "из изоленты и палок" у секты свидетелей синей изоленты есть отдельное наказание
, как-то связанное с синей изолентой</оффтоп офф>
Безусловно, есть специфика каждого из производств, но ее можно перенести в соответствующие специфике модули, и вызывать через коллбеки/декораторы. Но общий поток обработки информации можно же унифицировать? Я говорю не об архитектуре уровня инфраструктуры, а об архитектуре в более прикладном варианте, общей парадигме построения 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 при росте базы. Решили не рисковать и остаться на проприетарным хранилище трендов
В последнем проекте делали web приложение на базе Oracle с плагином, смотрящим на веб службу, под капотом которой jasper. Пользователи довольны
Вот тут бы хотелось немного поподробнее, есть ли какая методика оценки стоимости успеха и затрат? Вряд ли вы берете цифры с потолка и все согласны, договариваться надо. Как насчет развеять туман над этой частью совещания (например, в следующей статье упомянуть)?