Клуб анонимных оверлейщиков

[ax_mct]

Цитата:

Сообщение от skuull

Ну если и занимаетесь то точно не один. Вот начинание https://github.com/Adacta/source-dependency где человек хочет знать, что метод который он расширял поменялся и не плохо было бы его посмотреть. Присоеденяйтесь, внесите лепту делом, а не словом

Дельно человек предлагает. Но как это будет выглядеть я не понимаю. Seamless servicing and continuous updates как я понимаю это прямиком в production.

Даже если предположить возможность контроля над обновлениями в случае on-premise то выявление возможных конфликтов в случае использования точек расширения (где визуально не видно конфликтов кода и как результат - логики) становится на порядок более тяжелой задачей чем при явном наложении одного кода на другой.

Насчет лепты не готов. Мне кредит за дом платить надо, а не песочные замки строить вместе с играющими в песочнице

[skuull]

Цитата:

Сообщение от ax_mct

Дельно человек предлагает. Но как это будет выглядеть я не понимаю. Seamless servicing and continuous updates как я понимаю это прямиком в production.

Есть слухи, что рано или поздно, но скорее рано, platform обновления будут ставиться раз в месяц сами по себе, как на винду. По поводу application suite даже слухов нет. Т.е. будете сами их ставить на дев, сами этим или каким другим образом смотреть, что ваши чудо расширения не развалились и сами их потом деплоить. А в связи с тем, что МС очень сильно хочет, чтобы мы их ставили, нам бы какой-то инструмент в помощь.
Хотелось бы еще заметить, что титаник задраен не до конца, даты задраивания модели Currency я нигде не видел.

[ax_mct]

Цитата:

Сообщение от skuull

Есть слухи, что рано или поздно, но скорее рано, platform обновления будут ставиться раз в месяц сами по себе, как на винду. По поводу application suite даже слухов нет. Т.е. будете сами их ставить на дев, сами этим или каким другим образом смотреть, что ваши чудо расширения не развалились и сами их потом деплоить. А в связи с тем, что МС очень сильно хочет, чтобы мы их ставили, нам бы какой-то инструмент в помощь.
Хотелось бы еще заметить, что титаник задраен не до конца, даты задраивания модели Currency я нигде не видел.

Довольно непросто понять что есть platform, а что application suite. Туповатому мне.

Application stack and server architecture
https://docs.microsoft.com/en-us/dyn...r-architecture

New extensibility support in the July 2017 Update
https://blogs.msdn.microsoft.com/mfp...y-2017-update/

Цитата:

Refactoring of the *TableType and *LineType classes, so insert/update/delete events on the backing tables can be used as extension points.

То есть я понимаю все это так что обновления и изменения в *TableType and *LineType классах будут идти автоматически и прямо в Production. Я правильно понимаю?

[EVGL]

Цитата:

Сообщение от ax_mct

То есть я понимаю все это так что обновления и изменения в *TableType and *LineType классах будут идти автоматически и прямо в Production. Я правильно понимаю?

Нет. Банально идет речь о том, что на методы SalesTableType.update() и SalesLineType.update() повесили атрибут [Hookable] или отрефакторили там, чтобы можно было вклиниваться в исполнение кода.

[ax_mct]

Цитата:

Сообщение от EVGL

Нет. Банально идет речь о том, что на методы SalesTableType.update() и SalesLineType.update() повесили атрибут [Hookable] или отрефакторили там, чтобы можно было вклиниваться в исполнение кода.

Это, да, в контексте "что именно сделали в данных классах" для возможности их расширения не меняя "базовый" код.

Но зачем? Затем чтобы можно было автоматически и без спроса менять этот "базовый" код в Production.
То есть, код SalesLineType.update() может меняться автоматически и без спроса в Production. Это так или нет? В этом вопрос.

[Vadik]

Нет. Не может

[ax_mct]

Цитата:

Сообщение от Vadik

Нет. Не может

А зачем тогда уникальный механизм cлоев заменяется на точки расширения?
Не менять sys* обьекты - это понятно, но речь то идет к примеру о salesLineType и прочих.

В случае использования слоев (overlayering) я cразу могу видеть конфликт визуально, а в случае прицепления - все очень и очень неочевидно.

Если мне не разрешают overlayering для salesLineType то единственное обьяснение для меня что они хотят делать с этими классами что хотят и когда хотят. А иначе смысла в запрещении overlayering - просто нет.

Цитата:

Application Suite Hard Seal is a game changer. It unlocks a continuous update approach for the whole system including functionality and platform.

То есть тот же salesLineType.update() может меняться автоматически вендором в Production.
Откуда уверенность что "Нет. Не может"?
Потому что не могут взрослые люди играть со спичками на пороховом заводе?

http://www.intergen.co.nz/blog/Dynam...-mean-for-you/

[kashperuk]

Цитата:

Сообщение от ax_mct

Но зачем? Затем чтобы можно было автоматически и без спроса менять этот "базовый" код в Production.
То есть, код SalesLineType.update() может меняться автоматически и без спроса в Production. Это так или нет? В этом вопрос.

Production или не-Production тут не причем.

Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering.

Для того чтобы это сделать, ему не нужно никого спрашивать, если Вы об этом..

[ax_mct]

Цитата:

Сообщение от kashperuk

Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()

После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы.

Тем самым достигается несколько вещей:
- Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super()
- Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа.

Цитата:

Сообщение от kashperuk

Production или не-Production тут не причем.

Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering.

Для того чтобы это сделать, ему не нужно никого спрашивать, если Вы об этом..

Спасибо. Production или не-Production как раз очень причем.
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix.

Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/
continuous update approach for the whole system including functionality.

А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет.

То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого.

[kashperuk]

Цитата:

Сообщение от ax_mct

То есть я понимаю все это так что обновления и изменения в *TableType and *LineType классах будут идти автоматически и прямо в Production. Я правильно понимаю?

Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()

После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы.

Тем самым достигается несколько вещей:
- Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super()
- Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа.

[fed]

Цитата:

Сообщение от skuull

Есть слухи, что рано или поздно, но скорее рано, platform обновления будут ставиться раз в месяц сами по себе, как на винду.

Во многих индустриях (в частности в фармацевтике), обязательно использование стандартизированых систем управления качеством. И большая часть систем качества требует верификации устанавливаемого программного обеспечения. Не буду притворятся что я очень хорошо процесс верификации понимаю, но одно из его требований состоит в том, что любое обновление, перед развертыванием, должно либо тестироваться самим клиентом, либо каким-то независимой тестирующей организацией. Поэтому никакой автоматической установки обновлений в фармацевтике нет и быть не может. Аналогичный подход применяется и в других индустриях где системы управления качеством достаточно стандартизированы.
И разговоры об автоматическом обновлении чего либо просто демонстрируют как в MS на самом деле плохо понимают свой рынок...

[skuull]

Цитата:

Сообщение от fed

Во многих индустриях (в частности в фармацевтике), обязательно использование стандартизированых систем управления качеством. И большая часть систем качества требует верификации устанавливаемого программного обеспечения. Не буду притворятся что я очень хорошо процесс верификации понимаю, но одно из его требований состоит в том, что любое обновление, перед развертыванием, должно либо тестироваться самим клиентом, либо каким-то независимой тестирующей организацией. Поэтому никакой автоматической установки обновлений в фармацевтике нет и быть не может. Аналогичный подход применяется и в других индустриях где системы управления качеством достаточно стандартизированы.
И разговоры об автоматическом обновлении чего либо просто демонстрируют как в MS на самом деле плохо понимают свой рынок...

Я может неправильно понимаю как сейчас происходит обновление не АХ компоненотов на production, но там вроде письмо счастья и вам все накатили, никто же вас не спрашивает\не дает потестировать. Что собсетвенно нового принесет авто обновление еще одно компонента к зоопарку Window, SQL и бог весть еще чего ?

[EVGL]

Цитата:

Сообщение от skuull

Что собсетвенно нового принесет авто обновление еще одно компонента к зоопарку Window, SQL и бог весть еще чего ?

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.

Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными.

[skuull]

Цитата:

Сообщение от EVGL

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.

Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными.

Я же не отрицаю этих требований и аргументов. Забудем об x++ на секунду, можно ли теперь внедрит АХ таким компаниям если партнер даже не может на 100% сказать, какое программное обеспечение там используется и кто и когда его обновляет? Если нет, то нечего и х++ обсуждать и использовать это как аргумент, а если да то объясните в чем разница между inventDim и изменение в Azure SQL после которого что-то отвалилось.

[macklakov]

Цитата:

Сообщение от skuull

а если да то объясните в чем разница между inventDim и изменение в Azure SQL после которого что-то отвалилось.

А тут тоже не все так просто, между прочим. Если там что-то "пофиксят" так, что запросы станут возвращать несколько другие данные, то последствия могут быть очень суровыми. Другое дело что вероятность такого события крайне низкая, ибо SQL протокол старый, а потому отлично отлаженный и хорошо покрытый тестами.
Тут еще один момент. Софт, зачастую, просто отказывается запускаться если SQL не той версии. Т.е. была своеобразная "защита от дурака". Невозможность запуститься при этом не была большой проблемой, т.к. можно было сидеть на совместимой версии сервера, пока не переведешь клиента на новую версию. В случае же полностью автоматических обновлений, любой софт может заклинить из-за того, что в Azure SQL ввели инновацию. И что в таком случае делать, не очень-то и понятно.

[kashperuk]

Цитата:

Сообщение от EVGL

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.

Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными.

Вряд ли кто-то будет автоматом обновлять аппликейшн, не совсем же они ничего не понимают. Скорее всего МС просто будет куда-то выкладывать новые библиотеки приложения, и будет какой-то механизм, согласно которому клиентам нужно будет эти апдейты протестировать и установить в свое расписание.
Но конечно все равно более агрессивно, чем сейчас, когда никто не обновляется по 5 лет.

Я поэтому про тесты и спросил - было бы выгодно их начать писать

[Vadik]

Цитата:

Сообщение от kashperuk

Я поэтому про тесты и спросил - было бы выгодно их начать писать

Серьезные люди на подобную фигню не размениваются

[fed]

Цитата:

Сообщение от kashperuk

Вряд ли кто-то будет автоматом обновлять аппликейшн, не совсем же они ничего не понимают. Скорее всего МС просто будет куда-то выкладывать новые библиотеки приложения, и будет какой-то механизм, согласно которому клиентам нужно будет эти апдейты протестировать и установить в свое расписание.
Но конечно все равно более агрессивно, чем сейчас, когда никто не обновляется по 5 лет.

Я поэтому про тесты и спросил - было бы выгодно их начать писать

Мне вот что интересно: Запланированы радикальные изменения. Все эти extensions, попытки запихать партнеров в ISV и заставить писать вертикальные решения с тестами и тд и тп. Все это происходит на фоне перетряски сейлового канала (так что на неопределенность с продуктом накладывается неопределенность с управлением продажами). Хорошо. Допустим даже - это правильная долгосрочная стратегия. Но вот вопрос - реализция всего этого потребует эдак лет 5 - пока партнеры все переучаться, пока клиенты привыкнут к тому что на них все под каждый чих не переписывают, пока у Микрософта продажный канал перестроиться, пока MCS получит люлей от всех кому он проекты с оверлеерингом внедрил и тд и тп. Вот мне интересно - а они подумали с какой выручки им эти 5 лет зарплату платить будут ? Или у вас там R&D подразделения совсем о финансовом вопросе не задумываются ?

[Vadik]

Цитата:

Сообщение от EVGL

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться

Холмс, но черт возьми как можно втихую что-то пропатчить в Application Suite так, чтобы ни клиент, ни партнер этого не заметили ?

[mazzy]

Цитата:

Сообщение от Vadik

Холмс, но черт возьми как можно втихую что-то пропатчить в Application Suite так, чтобы ни клиент, ни партнер этого не заметили ?

также как и винду 10, офис.
также как и приложения в телефоне.
также как и яндекс-диск, гугл-докс и прочие сервисы.

наоборот, будут придумывать специальные механизмы, чтобы пользователю казалось, что он на что-то влияет и без его разрешения никаких обновлений не ставится.

будут даже некоторые обновления бесплатно накатывать. вспомним ту же виндовс 10.


а технология незаметного патча давно уже опробована на всех платформах. вирусы называется.