Как вы думаете: смог бы Линус Торвальдс в одиночку за 20 лет полностью повторить Асапту версии 3.0?

[mazzy]

Цитата:

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

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

Цитата:

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

Решение, не требующее плагинов.
SalesTable
SalesTable_RU (SalesTable_RU.SalesTable == SalesTable.RecId). Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_RU)
SalesTable_BR (SalesTable_BR.SalesTable == SalesTable.RecId) Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_BR)

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

в старых аксаптах пример псевдоплагинных таблиц InventTableModule (с большими оговорками)

в ax2009 типичный пример псевдоплагинных таблиц - LedgerJournalTrans


в ax2012 таких псевдоплагинных таблиц уже много, поскольку пришло много разработчиков со Scala. Особенно "удались" расширения для стран (PL, BR и др.)
sukhanchik привел пример для SalesTable


мой же любимый пример из ax2012 - это конечно базовая таблица unitOfMeasure и таблица-расширение unitOfMeasure_W, которая содержит 2 (два!) поля. Одно из которых является ссылкой на запись в базовой таблице.

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

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

[twilight]

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

[sukhanchik]

Цитата:

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

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

Верно, реализация - полное г... Но в качестве идеи подходит. Можно обратиться и к предыдущим версиям и посмотреть, как сказал mazzy - на тамошнюю реализацию (LedgerJournalTrans)

[sukhanchik]

Цитата:

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

А ты уверен, что вообще есть спрос на обновления ?

Спрос есть, потому что без обновлений у клиента возникает чувство его заброшенности.
Плюс не надо забывать, что фундаментом на большинстве компьютеров стоит Windows, который регулярно обновляется. Так-то понятное дело - клиент бы не менял ничего из ИТ, но мировой тренд заставляет его разоряться.

Цитата:

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

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

В общем случае - да. Но правило 20/80 никто не отменял. Реально в D365FO стало возможно почти ежемесячно обновляться без последствий. В AX 2012 и более ранних версиях об этом можно было только мечтать.
Конечно могут быть капитальные обновления. Но если они будут раз в полгода или реже - то клиента это может устроить, тем более, что дается время на тестирование и наконец-таки сильно продвинулись в разработке механизма автотестирования.

[belugin]

Цитата:

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

в ax2012 таких псевдоплагинных таблиц уже много, поскольку пришло много разработчиков со Scala. Особенно "удались" расширения для стран (PL, BR и др.)
sukhanchik привел пример для SalesTable

В 2012 в рамках проекта OneGLS были объединены слои GLS для APAC, LATAM и EMEA в один. Чтобы можно было сделать Multinational у которого одна компания бразильская, другая - латвийская, например.

Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании).

Конкретно про UnitOfWork сказать не могу

[fed]

Цитата:

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

Спрос есть, потому что без обновлений у клиента возникает чувство его заброшенности.
Плюс не надо забывать, что фундаментом на большинстве компьютеров стоит Windows, который регулярно обновляется. Так-то понятное дело - клиент бы не менял ничего из ИТ, но мировой тренд заставляет его разоряться.
.

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

[belugin]

Цитата:

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

В общем случае - да.

Это вероятностный компромисс между расширяемостью, обратной совместимостью и возможностью дорабатывать расширяемое.

[mazzy]

Цитата:

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

В 2012 в рамках проекта OneGLS были объединены слои GLS для APAC, LATAM и EMEA в один. Чтобы можно было сделать Multinational у которого одна компания бразильская, другая - латвийская, например.

Если бы оставили все в одной таблице, то количество полей бы превысило пределы которые обрабатывает AOS по умолчанию, так же пустые денные забивали буферы на SQL Server (например в одной компании нужны только бразильские поля и там миллиард записей, в другой компании только польские и там тоже миллиард записей, а запросы обычно запрашивают данныетолько одной компании).

Конкретно про UnitOfWork сказать не могу

Да, я слышал эту легенду.

Если "количество полей бы превысило пределы которые обрабатывает AOS по умолчанию", то надо разбивать таблицу по количеству полей ПО связанности полей друг с другом (по смыслу). Т.е. надо было бы отрефакторить функционал.

А сделали разбитие "по странам", полностью игнорируя как поля используются, как взаимодействуют.
Типа в очередной раз Майкрософт решил свои технические проблемы за счет потребителей. Причем именно тех потребителей, которые и являются заинтересованным ядром ("у которого одна компания бразильская, другая - латвийская, например")

Поэтому легенда так себе, фиговенькая. Особенно, если она правда.

[belugin]

Цитата:

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

Да, я слышал эту легенду.

Это не легенда. Я обычно отделяю свои предположения от наблюдаемых фактов.

Цитата:

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

Если "количество полей бы превысило пределы которые обрабатывает AOS по умолчанию", то надо разбивать таблицу по количеству полей ПО связанности полей друг с другом (по смыслу).

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

[mazzy]

Цитата:

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

на плечи клиентов

на плечи клиентов?!

Тебя там связали и пытают что ли?
Поставь точку в конце следующего сообщения, если ты не можешь говорить свободно.
https://www.youtube.com/watch?v=llFmOMCJLgk

[belugin]

Цитата:

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

на плечи клиентов?!
Тебя там связали и пытают что ли?

Мне непонятно, что ты имеешь ввиду. Кстати, на мой вопрос ты не ответил.

[mazzy]

Цитата:

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

Кстати, на мой вопрос ты не ответил.

С точкой... Немедленно отпустите Макса! Руки прочь от Белугина!
Макс, держись! Ты справишься.


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

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

и уж абсолютно не понимаю почему в вопросе звучит шантаж про баги, которые возникнут (в результате чьего саботажа?)

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

[Lemming]

Цитата:

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

А ты уверен, что вообще есть спрос на обновления ?

Я думаю что это актуально в развивающихся странах где постоянно идут реформы и меняется законодательство. С другой стороны, условно говоря из Московского офиса, поддерживать Индийское законодательство unreal. Но вообще, как одна из killer-feature моей системы мне видилась в возможности относительно безпроблемного обновления системы, хотя как правильно заметил twilight, полностью решение с обновлениями вряд ли удастся изобрести.

[belugin]

Цитата:

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

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

Не клиентам, вендору.

Цитата:

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

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

Все-таки, хотелось бы получить оценку. Сколько бы заняло дествовать по твоему плану?

Цитата:

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

и уж абсолютно не понимаю почему в вопросе звучит шантаж про баги, которые возникнут (в результате чьего саботажа?)

А баги возникают в-основном в результате саботажа? Мне казалось что errare humanum est.

Цитата:

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

а на клиентов в результате должно упасть 0 багов и минимум работы по обновлению клиентского кода.

0 багов это интересно. Тестирование, например, не находит всех багов. Это типа какая-то фундаментальная проблема тестирования. Как бы ты этого добился?

Минимум работы по обновлению - при минимуме изменений, нет?

[trud]

Цитата:

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

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

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

[Vadik]

Цитата:

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

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

Вероятно поэтому группа Dual-Write - одна из самых "горячих" на Yammer

[mazzy]

Цитата:

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

Не клиентам, вендору.

Все-таки, хотелось бы получить оценку. Сколько бы заняло дествовать по твоему плану?

Вендору - много. и очень дорого.
И чё?

Цитата:

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

А баги возникают в-основном в результате саботажа? Мне казалось что errare humanum est.

эк ты перевернул.
нет, ты шантажировал багами клиентов.

Цитата:

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

0 багов это интересно. Тестирование, например, не находит всех багов. Это типа какая-то фундаментальная проблема тестирования. Как бы ты этого добился?

Минимум работы по обновлению - при минимуме изменений, нет?

Бггггг. Как уж на сковородке...

Эй, на той стороне. Отпустите Макса. Мы помним, он был вполне вменяемый человек и отличный специалист. И такими дешевыми подменами не занимался. Отпустите Белугина!

[belugin]

Цитата:

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

Вендору - много. и очень дорого.
И чё?

эээ... откуда вендор возьмет ресурсы?

Цитата:

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

эк ты перевернул.
нет, ты шантажировал багами клиентов.

В каком смысле шантажировал? Описание недостатков какого-то выбора это шантаж?

Вот например, в Яндекс.Такси меня шантажирует времени подачи, когда переключаюсь между тарифами? Прикинь, плачу больше да еще и больше жду. Интересно, почему так?

[mazzy]

Цитата:

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

эээ... откуда вендор возьмет ресурсы?

а откуда вендор возмет продажи?

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


====================
возвращаясь к исходному вопросу:
Линус Торвальдс вполне смог бы повторить Аксапту, взяв существующие компоненты и сделав бандл.
вся фигня в том, что Аксапта сейчас уже безнадежно устарела и никому уже нафиг не нужна.

====================
возвращаясь к вопросу про "расширение таблиц"

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

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

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

==================
==================
расширения "по странам" я видел только в Аксапте. И считаю такую разбивку данных по таблицам безумным бредом Dynamics архитекторов. Хотя бы потому что каждая страна может создать несколько плагинов.

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

см. RAsset, RCach, RDefferals
Вложение 13172

[George Nordic]

Цитата:

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

Линус Торвальдс вполне смог бы повторить Аксапту, взяв существующие компоненты и сделав бандл.

Да, можно взять код приложений 4,0 / 2009 и портировать его на "свой" движок. Вопрос, насколько это законно? Если брать OpenSource, то там тоже очень внимательно надо читать соглашения, и, возможно, и свой продукт надо будет выкладывать в открытый доступ.

Цитата:

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

вся фигня в том, что Аксапта сейчас уже безнадежно устарела и никому уже нафиг не нужна.

Не скажи. Очень хороший задел был сделан. Просто время изменилось - сейчас надо только на облака и подписку ориентироваться. Иначе рынок не поймет, соответственно, не получишь финансирования. А клиенты в России очень настороженно к облакам относятся, особенно крупные.

Самое важно не это. Я на 100% уверен, что есть просто отличные ERP. Возможно, даже круче чем NAV / DAX / XAL / NetSuite и т.д.

Но, к сожалению, хороший продукт - это еще далеко не все. Маркетинг, партнерская сеть, возможность расширения, ценовая политика... Да и просто удача

С Уважением,
Георгий