mfp: Extensible X++: Chain of Command

[kashperuk]

Цитата:

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

Подумав еще...
ключевое слово next накладывает сильные ограничения в случае, если один метод в одном классе расширяет несколько других базовых.

например, мы создаем расширение post, которое должно срабатывать во всех журналах (в ГК, в складских журналах, в авансовых отчетах, в проектах и в других).

имея только ключевое слово next нельзя будет указать какой именно метод расширяемого класса вызываем. опять же, навсидку думается, что синтаксис вызова метода в map решил бы и эту проблему.

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

[mazzy]

Цитата:

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

Я не понял этот пример. Напиши что именно имелось ввиду?

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

Цитата:

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

Можно заврэпить конкретный метод конкретного саб-класса

да-да. я об этом.
ты очень точно написал в единственном числе.

хотя атрибуты, представленные в исходном видео, вполне допускают несколько extensionOf-классов.

[ax_mct]

По ходу серийного маньяка я нашел - это Пондопиддан.

Из переписки в коментариях.
https://blogs.msdn.microsoft.com/mfp...in-of-command/

Цитата:

Adding a parameter (optional or not) to a non-final method is a breaking change;

Цитата:

Michael Fruergaard Pontoppidan
July 5, 2017 at 3:01 pm
If next is not mandatory – then chain-of-command is conceptual identical to overlayering (without all the tooling). It would allow any one to replace literally any piece of code with their own implementation. Given the goal is to ensure seamless upgrades then we cannot allow a generic extension capability offering replacement semantics.

I agree, there are cases where it would make sense to not call next – for those we’ll need to refactor the code to support the extensions.

По ходу четко все сказал. Приказано расстрелять. Всякие надежды - бессмысленны.

[kashperuk]

Цитата:

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

По ходу серийного маньяка я нашел - это Пондопиддан.

Из переписки в коментариях.
https://blogs.msdn.microsoft.com/mfp...in-of-command/




По ходу четко все сказал. Приказано расстрелять. Всякие надежды - бессмысленны.

mfp - лидер проекта в Supply Chain Management, который (как Dave Froslie для GFM) обеспечивает extension points в этой области кода на основании запросов ISV / VARs

Корни надо искать намного выше, в его руководстве

[Logger]

Цитата:

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

Всякие надежды - бессмысленны.

Да лана. Дожмут их.
On premise тоже не хотели делать сначала.

[mazzy]

Цитата:

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

По ходу серийного маньяка я нашел

Цитата:

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

Корни надо искать намного выше, в его руководстве

Будем справедливы, ax_mct сказал, что нашел маньяка. Он не утверждал, что это корни )

[mazzy]

Цитата:

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

Дожмут их.

А я помню FoxPro и его историю.
http://www.foxprohistory.org/foxprotimeline.htm
https://msdn.microsoft.com/en-us/library/mt490117.aspx

[fed]

Цитата:

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

Да лана. Дожмут их.
On premise тоже не хотели делать сначала.

Сейчас многие старые клиенты, у которых сильно кастомизированная DAX2009 или DAX2012 стоит - в ожидании. Пока не наступит ясность с хардсилом, вкладываться в апгрейд на D365WTF для них не разумно. После анонса хардсила, заметная часть клиентов просто начнет массово отказываться от подписки и внедрять конкурирющие системы.
Так что подождем политического решения - либо отказ от хардсила, либо отказ от примерно 60% выручки за подписку в течении двух лет, после объявления о хардсиле.

[fed]

Цитата:

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

А я помню FoxPro и его историю.
http://www.foxprohistory.org/foxprotimeline.htm
https://msdn.microsoft.com/en-us/library/mt490117.aspx

Закрытие проекта D365 не может случиться до выноса Наделлы из Майкрософта. Это для него стало бы признанием личных мэнеджерских ошибок.
Правда, глядя на то, какой бардак творится в MS даже за пределами Dynamics, мне факт выноса Наделлы в перспективе 5-6 лет не кажется невероятным...

[Logger]

Цитата:

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

Закрытие проекта D365 не может случиться до выноса Наделлы из Майкрософта. Это для него стало бы признанием личных мэнеджерских ошибок.

Денис, можно подробнее пояснить ?
Если мне память не изменяет, Наделла поднялся из подразделения Business Solutiions, но напрямую с Dynamics вроде не связан. В общем, я не уловил связь.

[Logger]

Цитата:

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

После анонса хардсила, заметная часть клиентов просто начнет массово отказываться от подписки и внедрять конкурирющие системы.
Так что подождем политического решения - либо отказ от хардсила, либо отказ от примерно 60% выручки за подписку в течении двух лет, после объявления о хардсиле.

Возможен еще 3-й путь по которому мы пока успешно идем.
Объединят статистику по D365 со всем Business Solutions в целом и все. Ms Office вытянет статистику также как ее вытянул MS CRM для Dynamics.

[fed]

Цитата:

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

Денис, можно подробнее пояснить ?
Если мне память не изменяет, Наделла поднялся из подразделения Business Solutiions, но напрямую с Dynamics вроде не связан. В общем, я не уловил связь.

Наделла когда-то в начале 2000чных вышел из среднего менеджмента в верхний на разработке Biztalk. А закупка Great Plains/Navision/Solomon были его первыми действиями в ранге состоявшегося топ-менеджера. Так что если они эту тематику убьют, то это будет признание его личной ошибки.
Вообще пока рыночный энтузиазм по поводу Наделлы (отражающийся в цене акций MS) основан просто на том, что он - не Баллмер. Он перестал быковать по тупому и сделал несколько достаточно очевидных вещей (типа разработки версий для Android/IPhone). Но сейчас у него чэллендж заметно серьезнее: Они пытаются переформатировать Микрософт на использование облака, что предполагает быстрые и глубокие организационные реформы. Помня о том, как Микрософт внутри похож на СССР времен застоя, я как-то очень сомневаюсь что подобные реформы могут быть успешными. (Хотя посмотрим конечно).

[ax_mct]

Цитата:

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

А я помню FoxPro и его историю.
http://www.foxprohistory.org/foxprotimeline.htm
https://msdn.microsoft.com/en-us/library/mt490117.aspx

FoxPro - отличная аналогия для Аксапты так как FoxPro это как бы мини-Аксапта то есть такое же мощное средство быстрой разработки для предприятий но не больших (скажем до 100 человек).
Такая альтернатива FoxPro как Access - недостаточна и неполноценна.
Такая альтернатива как написание на .NET - это тупо все с нуля долго и дорого, Аксапта - другая весовая категория.

То есть был некий клиентский сегмент для ФоксПро которому приемлемых и адекватных альтернатив предложено не было.
Куда ушли эти клиенты?

Теперь есть неслабый клиентский сегмент АХ от которого снова Майкрософт отказывается. Вот этого я тупо понять не в состоянии. Очевидно же что D365 это неплохо, но это совсем другой клиентский сегмент.

Знание и профилирование своего клиента - это основа любого бизнеса. Нет никакого смысла в трате Майкрософтом ресурсов на издевательство над АХ7 - seamless updates это означает full stop для программирования в АХ7. Нет никакого смысла в точках расширениях и Chain Of Command. Потому как нет клиентов которым это нужно. Это все для никого.

[fed]

Цитата:

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

Знание и профилирование своего клиента - это основа любого бизнеса. Нет никакого смысла в трате Майкрософтом ресурсов на издевательство над АХ7 - seamless updates это означает full stop для программирования в АХ7. Нет никакого смысла в точках расширениях и Chain Of Command. Потому как нет клиентов которым это нужно. Это все для никого.

Нынешнее поведение Микрософта на рынке замечательно описывается экономическими статьями времен позднего СССР. Вот можешь почитать:
Журнал "Коммунист", 1988 г. №8 (август) Нулевой цикл. К анализу механизма ведомственной экспансии.

[Logger]

Интересно, если сравнивать с другими поставщиками (SAP, Oracle, 1c, кто там еще остался) - у кого в этом плане самый вменяемый менеджмент ?
Куды бечь ?

[ax_mct]

Цитата:

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

Нынешнее поведение Микрософта на рынке замечательно описывается экономическими статьями времен позднего СССР. Вот можешь почитать:
Журнал "Коммунист", 1988 г. №8 (август) Нулевой цикл. К анализу механизма ведомственной экспансии.

Не может такое быть вечно. MMM какое-то.

Цитата:

"главное для ведомства — доказать необходимость срочного начала строительства, расстегнуть общественный кошелек."

Цитата:

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

Интересно, если сравнивать с другими поставщиками (SAP, Oracle, 1c, кто там еще остался) - у кого в этом плане самый вменяемый менеджмент ?
Куды бечь ?

Забанят нас ох забанят Открой новую тему Куды бечь ? и мы там докажем что никуда бежать не надо

А чтобы остаться в рамках данной темы то я действительно не понимаю для кого весь этот Extensible X++: Chain of Command и подобное делается. Логика какая-то в этом инопланетная.
Так как единственное вменяемое решение для клиента при seemless updates это никаких кастомизаций бизнес-логики. Вообше никаких.

И если подумать то и для вменяемого ISV - seemless updates это минное поле. Хотя если не отвечать за совместимость с возможными updates - это можно доить и доить, но со скоростью внесения изменений и с их стоимостью - стадо разбежится.

Понятно то что можно делать абсолютно параллельные решения под крышей Operations в целях маркетинга но в таких решениях вся эти Extensible X++ фишки просто ни к чему.

[trud]

Цитата:

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

А чтобы остаться в рамках данной темы то я действительно не понимаю для кого весь этот Extensible X++: Chain of Command и подобное делается. Логика какая-то в этом инопланетная.

Это то как раз понятно. т.е. такие вещи, это довольно большие бюджеты(т.е. только описание алгоритма на то что next гарантированно вызывается(ща кто-то на яммере запостил) занимает чуть ли не страницу текста, +кодирование-тестирование и прочее), при этом ценность этой проверки вообще нулевая.

т.е. кстати это один в один описано в статье Гайдара fed о трубах(где ты только такое берешь )
т.е. берется бездоказательное - утверждение аксиома - что системе нужны экстеншены.
далее уже под это легко подвести(прикрываясь теми же требованиями партнеров) что нужно переписывать компилятор(а это просто огромные бюджеты-деньги), нужно нанять еще людей и прочее..

при этом если разобраться с точки зрения апгрейдов эта штука логически вообще эквивалентна(и даже значительно уступает) однострочному изменению при оверлеинге(т.е. когда вы изменяете существующий метод добавляя в него одной строчкой или блоком изменения строго в начало или конец), и это уже автоматически разрешалось при создании upgrade проекта, т.е. для клиента это тоже нулевая ценность

[macklakov]

Цитата:

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

Теперь есть неслабый клиентский сегмент АХ от которого снова Майкрософт отказывается. Вот этого я тупо понять не в состоянии. Очевидно же что D365 это неплохо, но это совсем другой клиентский сегмент.

А какой ты сегмет здесь видишь?
Облака, в перву очередь, удобны для мелочевки, т.к. контора в 10 человек не потянет хорошего IT-шника. Для мелочевки же нужны автоматические обнавления. Там банально некому их накатывать. Но мелочевке не нужны все эти функциональные навороты, которые присутствуют и разрабатываются в AX.
У крупных же требования такие, что их серверные мощности могут поспорить с некоторыми поставщиками этих самых облаков. Но крупным автоматические обновления не так уж и важны. Крупным не в напряг держать пару человек, которые будут заниматься исключительно merge.

[fed]

Цитата:

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

далее уже под это легко подвести(прикрываясь теми же требованиями партнеров) что нужно переписывать компилятор(а это просто огромные бюджеты-деньги), нужно нанять еще людей и прочее..

Еще дело в том, что топы микрософта - они либо бывшие сейлы либо бывшие программисты; например - Scott Guthrie - главномый по облакам и энтерпрайсу, начинал как product manager asp.net. Продать ему идею разработки передового компилятора гораздо легче чем идею разработки передового сводного планирования.

[ax_mct]

Цитата:

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

А какой ты сегмет здесь видишь?
Облака, в перву очередь, удобны для мелочевки, т.к. контора в 10 человек не потянет хорошего IT-шника. Для мелочевки же нужны автоматические обнавления. Там банально некому их накатывать. Но мелочевке не нужны все эти функциональные навороты, которые присутствуют и разрабатываются в AX.
У крупных же требования такие, что их серверные мощности могут поспорить с некоторыми поставщиками этих самых облаков. Но крупным автоматические обновления не так уж и важны. Крупным не в напряг держать пару человек, которые будут заниматься исключительно merge.

"неслабый клиентский сегмент АХ от которого снова Майкрософт отказывается" - это я про Enterprise уровень, крупных клиентов. "AX7" - это по факту сегмент SMB которым не столько операции сколько BI нужен.
Я понимаю что текущая религия это Azure любой ценой, облака требуют автоматических обновленией. Понимаю что уже сотый раз про одно и то же. Но все же.
Автоматические обновления означают такой уровень рисков что единственное решение это отказ от любых кастомизаций.
С учетом того что в продакшн (AX7) теперь только через MS как я понимаю это означает некую проверку на совместимость и возможные конфликты, но во первых, я сомневаюсь что MS будет нести какую-то финансовую ответственность и вообще ответственность, а во-вторых, стоимость и скорость изменений становится марсианской экспедицией.
Легкие изменения - слишком дорого, проще терпеть. Средние и тяжелые изменения - слишком рискованно. Теоретически как бы можно на гении программиста - но кто возьмет на себя оценку рисков и сами риски?
А крупным клиентам - нужны кастомизации. Всегда нужны.
Соответственно потребность MS в автоматических обновлениях - это отказ от Enterprise сегмента.
Соответственно добавление всяческих фич на фоне автоматических обновлений - бессмысленно, вменяемые люди не будут играть красиво заточенными спичками на бочке с порохом.